[번역] 웹어셈블리에 주목하라

25 min readFeb 24, 2022

원문: https://harshal.sheth.io/2022/01/31/webassembly.html

웹어셈블리는 중대한 전환점을 마주하고 있습니다. 앞으로 몇 년 동안 컨테이너화에서 플러그인 시스템, 서버리스 컴퓨팅 플랫폼에 이르기까지 기술 영역 전반에 걸쳐서 웹어셈블리의 채택은 증가할 것이라고 예상합니다. 이 글에서는 웹어셈블리가 무엇인지, 관련된 기술이 무엇이 있는지, 오늘날 어디에 사용되고 있는지에 대해 설명하려 합니다. 또, 잠재적으로 영향력이 큰 몇 가지 응용 프로그램에 대해서도 설명하고 그 미래에 대해서도 예측해보겠습니다.

웹어셈블리란?

웹어셈블리, 줄여서 Wasm은 다양한 프로그래밍 언어와 다양한 실행 환경 사이의 중간 계층입니다. 30개 이상의 다른 언어로 작성된 코드를 가져와서 .wasm 파일로 컴파일한 다음 브라우저, 서버 심지어 자동차에서도 해당 파일을 실행할 수 있습니다.

“웹어셈블리”라는 이름은 잘못 지어졌습니다. 초기에 웹상에서 코드를 빠르게 실행하기 위한 목적으로 설계되었지만, 현재는 브라우저 외에 다양한 환경에서 실행될 수 있습니다. 그리고 웹어셈블리는 어셈블리라고 볼 수 없습니다. 그보다 높은 수준의 바이트코드입니다.

웹어셈블리와 그 역사에 대해 설명하는 데 많은 자료가 있습니다. 그 중 몇 가지 좋은 입문서를 추천드립니다.

웹어셈블리의 강점

웹어셈블리는 아래의 5가지 면에 있어서 강점을 보입니다.

이식성(Portable): Wasm 바이트코드의 바이너리 형식은 표준화되어 있습니다. 이는 Wasm을 실행할 수 있는 모든 런타임이 어떤 Wasm 코드든 실행할 수 있음을 의미합니다.(1) 그리고 “한 번 작성하면 어디서나 실행 가능”(Write once, Run anywhere)이라는 자바의 약속과 유사합니다. 브라우저에서 95% 이상의 사용자들은 웹어셈블리를 실행할 수 있습니다. 나머지 사용자들은 wasm2js 컴파일러를 사용하여 실행할 수 있습니다. 서버에서는 Wasmtime, Wasmer 같은 런타임이 있습니다. 제한된 자원을 가진 IoT 장치에서도 WAMR을 이용하여 실행할 수 있습니다.(2)
범용성(Universal): 많은 언어들이 Wasm으로 컴파일 될 수 있습니다. C, C++ 및 Rust와 같은 시스템 언어를 비롯하여 Go, Python 및 Ruby와 같은 가비지 컬렉션 고수준 언어를 포함합니다.(3) Wasm으로 컴파일되는 전체 언어의 목록은 여기에서 찾아볼 수 있습니다.
“네이티브에 가까운 성능(Near-Native Performance)”: Wasm은 “네이티브에 가까운 성능”을 가진다고들 말합니다. 이는 컴퓨팅 집약적인 작업의 경우 웹어셈블리가 거의 항상 자바스크립트보다 빠르며, 네이티브 코드보다 평균 1.45에서 1.55배 정도 느리고 런타임에 따라서 결과는 달라질 수 있다는 것을 말합니다.
빠른 시작 시간(Fast Startup Time): Wasm의 콜드 스타트 시간은 그 자체로 하나의 큰 주제를 차지할 만큼 중요합니다. 서버에서 모든 컨테이너에 대해 새로운 OS 프로세스를 생성할 필요가 없기 때문에 Docker 컨테이너보다 10에서 100배 더 빠른 콜드 스타트 시간을 달성할 수 있습니다. 브라우저에서 Wasm을 디코딩하고 기계어로 번역하는 것은 JavaScript를 구문 분석, 해석 및 최적화하는 것보다 빠르므로 Wasm 코드는 JavaScript보다 더 빠르게 최고의 성능으로 실행될 수 있습니다.(4)
보안(Secure): 웹어셈블리는 웹을 염두에 두고 설계되었기 때문에 보안은 그 무엇보다 높은 우선순위에 있었습니다. Wasm 런타임에서 실행되는 코드는 샌드박스 안에서 메모리가 할당되고, 기능이 제한됩니다. 즉, 명시적으로 허용된 작업만 수행할 수 있습니다.(5) 샌드박스 안에서도 Wasm 코드는 여전히 시스템 수준 인터페이스 및 하드웨어 기능을 포함하여 기본 시스템에 액세스 할 수 있습니다.

웹어셈블리는 어디에 유용한가?

자바스크립트 속도 향상

Wasm과 asm.js의 첫 시작은 웹에서 클라이언트 사이드 코드의 속도를 높이는 것이었습니다. Wasm이 뛰어난 효과를 보여준 사례 또한 많이 있습니다.

예를 들면, Figma 디자인 툴의 핵심 부분은 C++로 작성되어 있고 웹어셈블리로 컴파일됩니다. C++로 작성하고 WebAssembly로 컴파일하여 로드 시간을 3배 줄이고 다운로드 크기를 크게 줄임으로써 성능 및 유용성에 대한 이점을 확인했습니다.
암호 관리자 1Password는 Wasm으로 전환할 때 양식이 많은 사이트에서 최대 13에서 39배의 속도 향상을 보았습니다. 또한 Wasm의 성능은 자바스크립트보다 일관성이 있기 때문에 지연 시간에 민감한 애플리케이션에서 강점을 보입니다.(6)

프로그래밍 언어 상호 운용성

웹어셈블리를 사용하면 프로그래밍 언어 간의 경계를 더 쉽게 넘나들 수 있습니다. 라이브러리와 프레임워크는 일반적으로 단일 언어로 작성되므로 전체 재작성 없이는 다른 언어의 해당 코드를 사용하기 어렵습니다. 웹어셈블리를 사용하면 다른 언어로 작성된 코드를 보다 쉽게 실행할 수 있습니다. 이를 통해 처음부터 다시 작성하는 대신 기존 코드를 재사용할 수 있습니다.

현재 이것은 주로 애플리케이션을 웹으로 포팅하는 데 사용됩니다. 다음은 몇 가지 예입니다.

Figma는 자체적으로 만들거나 JavaScript로 포팅하는 대신 Skia라는 저수준 C++ 그래픽 알고리즘 라이브러리를 사용합니다.(7)
체스 서버인 lichess.org는 사용자 브라우저에서 세계적 수준의 Stockfish 체스 엔진을 실행하여 서버 측에서 실행해야 하는 계산 부담을 덜어줍니다.
Google Earth와 Adobe Photoshop은 Wasm을 사용하여 C++ 코드베이스를 웹으로 포팅했습니다.

애플리케이션을 웹으로 포팅하는 것이 가장 시작하기 쉬우며, 이러한 추세가 계속될 것입니다. Wasm의 상호 운용성은 브라우저에만 국한되지 않습니다. 플랫폼 및 기기 간에서도 코드가 작동하도록 할 수 있습니다.

Uno 플랫폼은 단일 애플리케이션을 작성하고 Windows, macOS, iOS, Android, Linux 및 브라우저에서 실행될 수 있는 UI 플랫폼입니다. 애플리케이션이 C# 및 XAML로 작성되었기 때문에 상당히 Windows 중심적인 것으로 보이며 많은 사용 사례가 레거시 애플리케이션을 새 플랫폼으로 포팅하는 데 필요한 노력을 줄이는 것을 기반으로 두고 있습니다.
Amazon Prime, Disney+, BBC는 모두 비디오 플랫폼에서 웹어셈블리를 사용합니다. 예를 들면, Amazon Prime은 새로운 기능을 다양한 종류의 기기에 만족할만한 성능으로 유지하면서 제공하는 것에 웹어셈블리를 사용합니다.

애플리케이션 이식성 외에도 웹어셈블리는 서버 측에서 언어 간 다리 역할을 할 수도 있습니다. 아쉽지만 운영 체제와 통신하는 데 사용되는 인터페이스(웹어셈블리 시스템 인터페이스, 약칭 WASI)와 언어 경계를 넘나드는 작업(Wasm 컴포넌트 모델)은 현재 개발중이고 기술적으로 성숙하지 않기 때문에, 아직은 이 기능을 마주하기 어렵습니다.

플러그인 시스템

대부분의 애플리케이션이 특정 수준에 도달하면 최종 사용자가 확장할 수 있어야 합니다. 역사적으로 애플리케이션은 방대한 구성 시스템에 도달했거나 복잡한 DSL을 구축했지만, 이는 항상 개발자가 익숙하지 않은 언어로 작업하거나 관리하는 데 매우 고통스러움을 주는 쪽으로 흘러갔습니다.

NGINX와 같은 시스템에서 요청을 필터링하는 규칙을 구성하는 예를 살펴보겠습니다. 시스템 관리자는 익숙하지 않은 커스텀 구성 언어로 원하는 논리를 선언적으로 구현해야 합니다. 그들은 NGINX 설계자가 예상한 매칭 및 필터링 연산자 유형에 의존하며, 이는 종종 원하는 동작을 구현하는 능력을 심각하게 제한합니다. 문제가 발생하면 사용 가능한 도구가 없기 때문에 디버깅에 어려움을 겪을 수 있습니다.

일부 최신 애플리케이션은 다른 접근 방식을 선택했습니다. 표준 인터페이스 세트를 제공하고 Wasm 런타임을 포함하도록 합니다. 그리고 최종 사용자가 필요한 사용자 정의 논리를 구현하는 Wasm 바이너리를 제공하도록 합니다. 이는 최종 사용자에게 훨씬 더 유연하고 친숙한 인터페이스를 제공합니다. 사용자는 임의로 복잡한 비즈니스 로직을 구현할 수 있고 직접 선택한 언어로 수행할 수 있습니다. 이것은 보안 문제 때문에 다른 언어에서는 불가능했지만, Wasm은 런타임이 사용자가 제공한 코드를 샌드박싱할 수 있기 때문에 가능합니다.

실제로 사용중인 사례들이 있습니다.

원래 Lyft에서 개발했으며 현재 업계 전반에서 사용되는 Envoy 프록시를 사용하면 확장 기능을 Wasm으로 빌드하고 런타임에 동적으로 로드할 수 있습니다. Envoy 위에 구축된 Istio Service Mesh도 따라서 만들어졌습니다.
Kafka의 대체 기술인 Redpanda를 사용하면 사용자가 Wasm을 사용하여 인스트림 사용자 지정 데이터 변환을 작성할 수 있습니다.
Open Policy Agent를 사용하면 Wasm을 사용하여 정책을 정의할 수 있습니다.
Minecraft 서버 Feather는 웹어셈블리를 사용하여 샌드박스에서 플러그인을 실행합니다.

임베디드 샌드박싱

웹어셈블리를 다른 애플리케이션에 포함시키는 아이디어는 플러그인 시스템 그 이상의 가치를 갖습니다. 실제로, 써드파티 라이브러리 전체를 샌드박스 처리하거나 자사 코드에 대한 보안 계층을 구성하는 데 사용할 수 있습니다.

Firefox는 맞춤법 검사나 이미지 디코딩에 사용하는 것과 같은 써드파티 라이브러리의 버그로부터 스스로를 보호함으로써 이 분야에서 선두를 달리고 있습니다. 오염 계층을 제공하는 RLBox라는 도구와 함께 프로세스 격리에 의존하지 않고도 해당 라이브러리의 취약성으로부터 보호할 수 있습니다. Firefox의 경우 최종 릴리스에서 Wasm 바이너리를 제공하지도 않습니다. Wasm으로 컴파일한 다음 RLBox와 함께 다른 언어로 변환하는 프로세스는 그들이 필요로하는 보안을 보장합니다.

이 접근 방식은 일부 심각한 취약점이 악용되는 것을 방지할 수 있습니다. 공격자는 일반적으로 여러 취약점을 함께 연결하기 때문에 이러한 중간 보안 계층은 앞으로 매우 중요할 것입니다.

컨테이너화

자주 인용되는 트윗에서 Docker 설립자 Solomon Hykes는 웹어셈블리의 중요성을 강조했습니다.

2008년에 WASM+WASI가 있었다면 Docker를 만들 필요가 없었을 것입니다. 그만큼 중요합니다. 서버의 웹어셈블리는 컴퓨팅의 미래입니다.

Wasm이 컨테이너화의 미래를 대표한다고 믿을 만한 충분한 이유가 있습니다. Docker와 비교하여 콜드 스타트 시간이 10–100배 더 빠르고 설치 공간이 더 작으며 더 잘 제한된 기능 기반 보안 모델을 사용합니다. 컨테이너가 아닌 Wasm 모듈을 컴퓨팅 및 배포의 표준 단위로 만들면 확장성과 보안이 향상될 것입니다.

이러한 전환은 하룻밤 사이에 일어나지 않을 것이므로 Wasm 기반 컨테이너화는 Docker를 완전히 대체하기보다는 기존 오케스트레이션 시스템에 통합될 가능성이 높습니다.

저는 앞으로 몇 년 동안 이 분야에서 활발한 활동이 이어질 것으로 예상합니다. 몇 가지 프로젝트가 이미 진행되고 있습니다.

Microsoft Azure의 Deis Labs는 기존 Kubernetes 클러스터에서 Wasm 작업을 실행하는 방법인 Krustlet을 구축했습니다.
Deis Labs는 또한 Wasm 중심의 서비스로서의 플랫폼인 Hippo를 출시했습니다. Fermyon이 그 기술을 상용화하려고 하는 것 같습니다.
Cosmonic은 wasmCloud 프로젝트를 통해 Wasm 컨테이너화와 분산 시스템용 액터 모델을 결합하는 플랫폼 및 오케스트레이션 계층을 구축하고 있습니다.
Lunatic 플랫폼은 또한 액터 모델을 수용하며 단일 웹어셈블리 런타임 프로세스 위에 여러 개의 경량 컨테이너를 실행하는 것을 가장 잘 지원하는 것 같습니다.
Suborbital의 Atmo는 또 다른 플랫폼 및 오케스트레이션 시스템이지만 서버리스 작업에 더 중점을 둡니다.

FaaS/서버리스 플랫폼

FaaS(Function-as-a-service) 플랫폼은 사용자가 제공한 코드를 빠르고 안전하게 실행해야 합니다. 서버리스 플랫폼은 종종 짧은 기간 동안 코드를 실행하는 데 사용되기 때문에 시작 시간은 특히 중요한 지표입니다. 초고속 콜드 스타트와 광범위한 언어 지원으로 Wasm은 서버리스 작업에 적합한 선택입니다.(8)

Cloudflare Workers 및 Fastly Compute@Edge에서 제공하는 CDN 에지 컴퓨팅 플랫폼은 이미 웹어셈블리를 실행할 수 있는 기능을 제공합니다. Fastly는 시장의 다른 제품보다 시작 시간이 100배 더 빠르다고 주장하며 이러한 속도 향상은 웹어셈블리 기반 컴파일러 및 런타임 덕분입니다. Netlify와 Vercel도 여기서 서비스를 제공하고 있습니다.

주요 클라우드 제공업체가 구축한 서버리스 플랫폼 또한 크게 뒤처지지 않습니다. AWS Lambda는 몇 달 전에 웹어셈블리 서버리스 기능을 출시했으며 GCP와 Azure도 이를 따를 것으로 예상합니다.

블록체인

Ethereum 및 Solana와 같은 플랫폼은 사용자가 블록체인에서 실행할 수 있는 “스마트 계약(Smart Contracts)”이라고 하는 코드를 작성할 수 있는 메커니즘을 제공합니다. 이더리움은 컴파일된 바이트코드를 위한 바이너리 형식인 솔리디티(Solidity)라는 언어와 샌드박스 실행을 위한 이더리움 가상 머신을 만들어 완전한 맞춤형 시스템을 구축했습니다. Solana는 LLVM 컴파일러 인프라를 활용하여 C, C++ 또는 Rust 코드를 Berkeley Packet Filter에서 영감을 받은 바이너리 바이트코드 형식으로 컴파일하는 기존 혁신을 재사용하기로 결정했지만 Sealevel이라는 자체 런타임을 구축했습니다.

웹어셈블리는 이미 다음과 같은 많은 기반 기능을 제공합니다. 사용자가 선택한 언어로 코드를 작성할 수 있고, Wasm 바이트코드를 생성하기 위한 컴파일러 인프라를 제공하고, 수많은 고성능 런타임이 있습니다.

그러나 Ethereum과 Solana도 이미 위와 같은 기반 기능을 제공한다면 웹어셈블리가 제공하는 가치는 무엇일까요? 주요 부가가치는 실제로 생태계 주변에 있습니다. 예를 들어 이더리움에는 스마트 계약을 작성하기 위한 자체 언어가 있습니다. 즉, 다른 언어로 작성된 모든 라이브러리와 공통 기능을 활용할 수 없습니다. Solana는 Rust 생태계를 사용할 수 있기 때문에 조금 더 좋긴합니다. 기술적인 문제를 극복할 수 있다고 가정하면 웹어셈블리는 훨씬 더 많은 사람들에게 스마트 계약 개발을 제공하고 그들에게 이미 익숙한 라이브러리와 도구를 사용할 수 있도록 합니다.

저는 이것을 처음으로 현실화 한 사람은 아닙니다. 예를 들면, Polkadot 네트워크는 웹어셈블리 기반 가상 머신을 런타임으로 사용합니다. EOS 가상 머신도 웹어셈블리를 기반으로 합니다. CosmWasm은 이를 사용하여 여러 블록체인에서 작동하는 스마트 계약을 구축합니다. 이더리움 가상 머신을 웹어셈블리의 제한된 하위 집합으로 대체하는 eWASM이라는 제안도 있었지만 그 이후로 그 노력은 물거품이 된 것 같습니다. Wasmer 런타임은 블록체인을 위해 명시적으로 구축된 “단일 패스” 컴파일러 모드를 제공하는 반면 WasmEdge는 이더리움 호환 스마트 계약 실행 엔진이 있다고 주장합니다.

예측 및 기회

새로운 애플리케이션 구조

Docker가 가상 머신을 완전히 대체할 수 없는 것처럼 Wasm은 Docker를 완전히 대체할 수 없습니다. 예를 들어 Docker 컨테이너는 사용자 지정 OS 커널을 실행할 수 없지만 가상 머신은 실행할 수 있습니다. 마찬가지로, Wasm 컨테이너는 x86의 256비트 AVX 명령어(9)와 같은 일부 특수 CPU 명령어를 사용할 수 없으므로 일부 애플리케이션에서는 Docker와 경쟁할 수 없습니다.

제 생각에는 Docker가 지원할 수 있지만 Wasm이 지원할 수 없는 작업은 현재 Docker와 가상 머신 간의 차이보다 큽니다. 그러나 Wasm은 여전히 개발 중인 기술이므로 점진적으로 더 많은 유형의 작업을 처리할 수 있습니다. Docker의 부상은 마이크로서비스 아키텍처의 부상과 밀접하게 연관되어 있습니다. 이는 가상 머신에 적합한 모놀리식(monolithic) 애플리케이션을 Docker 컨테이너에 적합한 마이크로서비스로 대체했습니다. 우리는 웹어셈블리의 고유한 기능을 활용하는 새로운 애플리케이션 아키텍처를 보게 될 것입니다.(10)

Conway의 법칙에 따라 애플리케이션의 아키텍처는 애플리케이션을 생산하는 조직의 커뮤니케이션 구조를 반영합니다. 컴퓨팅의 역사를 통틀어 모든 새로운 “참조 아키텍처”는 사람들 사이에 필요한 조정의 양을 줄였습니다. 메인프레임에서 가상 머신, Docker 컨테이너에 이르기까지 배포 가능한 유닛을 생성하는 데 필요한 인력의 수는 점진적으로 감소했습니다. 우리는 시스템을 점점 더 작은 구성 요소로 분해하고 이러한 구성 요소를 구축하는 사람들이 잘 정의된 인터페이스에 대해 독립적으로 작동할 수 있도록 함으로써 이를 달성했습니다. 마이크로서비스가 모놀리식 애플리케이션을 여러 개의 작은 독립 서비스로 분해했지만 웹어셈블리를 사용하면 마이크로서비스를 훨씬 더 작은 구성요소로 쉽게 분해할 수 있습니다.

다음과 같은 것들이 가능해질 것입니다.

애플리케이션을 핵심 비즈니스 로직과 다른 시스템과 함께 작동하는 데 필요한 글루 코드로 나눌 때 비즈니스 로직은 일반적으로 나머지에 비해 꽤 작은 것으로 밝혀졌습니다. 글루 코드의 인터페이스를 기능의 구현과 분리함으로써 비즈니스 로직 중심 애플리케이션을 구축하고 나머지를 외부 기능 제공자에게 위임하는 것이 가능해집니다. 긴 공백이 있는 액터 모델과 함께 이것이 wasmCloud 접근 방식의 핵심입니다.
또 다른 가능성은 서버리스 아키텍처가 마이크로서비스를 넘어선 다음 단계라는 것입니다. 대부분의 서비스는 상태 저장 및 상태 비저장 부분으로 나눌 수 있으며 상태 비저장 부분은 임의로 확장 가능한 서버리스 기능으로 실행할 수 있습니다. 이 경우 웹어셈블리는 이러한 서버리스 기능을 위한 편리하고 쉽게 확장 가능한 런타임 역할을 합니다.
웹어셈블리는 써드파티 종속성을 처리하는 방식을 변경할 수 있습니다. 최신 코드는 써드파티 라이브러리(11)에 크게 의존하며 이러한 종속성의 대부분은 완전히 또는 자주 검사되지 않습니다. 최근 Log4j 취약점과 같은 소프트웨어 공급망 문제가 밝혀지면서 사람들이 써드파티 라이브러리의 보안을 더 심각하게 받아들이기 시작할 것으로 예상합니다. 특정 라이브러리를 분리하기 위해 Firefox에서 Wasm 및 RLBox를 사용하는 것과 같은 접근 방식이 더 널리 보급될 것입니다. 성능 제한을 극복할 수 있다고 가정하면 써드파티 라이브러리를 동일한 Wasm 런타임 내에서 별도의 기능이 제한된 컨테이너로 격리하는 것이 가능할 수도 있습니다.(12)

브라운필드 배포

Wasm은 결국 어떤 식으로든 Docker와 상호 운용해야 합니다. Wasm은 이전 버전과의 호환성에 대한 요구 사항이 거의 없는 그린필드 배포(greenfield deployment)에 주로 사용될 것이기 때문에 향후 몇 년 동안 이것은 꼭 필요한 것은 아닙니다. 그러나 궁극적으로 Wasm이 특히 엔터프라이즈 환경에서 컨테이너화 경쟁에서 완전히 승리하려면 브라운필드 배포(brownfield deployment)가 쉬워야 합니다.

한 가지 잠재적인 결과는 Docker가 Wasm 런타임을 통합한다는 것입니다. 그럴듯하지만, 나는 Wasm이 완전히 분리된 툴링을 보증할 만큼 충분히 차별화될 것이라고 기대합니다. 대신 오케스트레이션 계층에서 Docker 및 Wasm 컨테이너의 통합이 이뤄질 것이라고 생각합니다.

Kubernetes가 Wasm 기반 실행을 효과적으로 통합할지 또는 새로운 오케스트레이션 시스템이 등장할지 여부는 명확하지 않습니다. 한편으로 Kubernetes는 현재 타의 추종을 불허하는 오케스트레이션의 왕입니다. Kubernetes는 놀라운 추진력을 가지고 있으며 Wasm 컨테이너화 운동은 Kubernetes를 이용하는 것이 현명할 것입니다. Microsoft는 Kubernetes에서 Wasm 작업을 실행할 수 있는 Krustlet을 구축하여 미래에 투자하고 있습니다. 반면에 Wasm 코드는 Docker 컨테이너와 요구 사항이 다르므로 Kubernetes가 적합하지 않을 수 있습니다. 예를 들어, 쿠버네티스로는 하기 힘든 Wasm 기반 써드파티 라이브러리 격리를 사용할 때 컨테이너 간 통신을 위해 공유 메모리를 설정하는 것이 유용할 것입니다. 이러한 Wasm 네이티브 오케스트레이터는 결국 Docker와의 마이그레이션 또는 통합을 용이하게 하는 브리지를 구축할 것입니다.

저는 다가오는 Wasm 오케스트레이터가 하나의 새로운 흐름이 될 것을 기대하고 있지만, Kubernetes는 확고히 자리 잡고 있기에 단기간에 물러나지 않을 것 입니다.

표준화된 서버리스/에지 프레임워크

대부분의 서버리스 공급자들은 라우팅과 람다 함수를 정의하기 위한 자체 프레임워크가 있습니다. 예를 들어 Cloudflare는 자체 “cf” 유형을 정의하고 코드 스캐폴딩을 설정하기 위한 wrangler라는 CLI 도구를 제공합니다. Fastly에는 캐시 및 로깅과 상호 작용하기 위한 자체 인터페이스 세트가 있으며 AWS Lambda에도 유사한 설정이 있습니다. Kubernetes용 Fission 프레임워크에는 다양한 언어와의 통합을 위한 자체 라이브러리 세트가 있습니다. 일부 플랫폼은 플랫폼이 실행만 처리하면 되도록 사용자가 Docker 컨테이너를 제공하도록 하여 이 문제를 우회하려고 합니다. Knative와 Fly.io는 모두 이 접근 방식을 따릅니다. 그러나 콜드 스타트 시간의 영향을 줄이기 위해서는 작업자의 “웜 풀(warm pool)”을 유지하거나 이 문제를 사용자에게 전달해야 합니다.

표준화된 서버리스 기능 정의 및 배포 사양을 구축할 기회가 있습니다. 인기 있는 서버리스 프레임워크는 배포를 추상화하는 데 적절한 작업을 수행하지만 여전히 공급자별 세부 정보를 함수 구현에 누출합니다. 이러한 세부 사항이 추상화되면 멀티 클라우드 배포가 훨씬 쉬워지고 따라서 프레임워크가 훨씬 더 강력해집니다. 결국 서버리스의 Terraform과 같을 수 있습니다.(13)

패키지 관리

모든 프로그래밍 언어에는 주변 생태계가 있습니다. 대부분의 현대 언어에는 중앙 집중식 패키지 레지스트리가 있습니다. Python에는 PyPI가, NodeJS에는 npm이, Rust에는 Crates.io가 있습니다. 이러한 레지스트리와 함께 제공되는 도구 및 워크플로는 고품질의 생태계를 개발하고 개발자의 삶을 훨씬 쉽게 만드는 데 중요합니다.

Wasm의 경우 WAPM(WebAssembly Package Manager)이 그 간극을 메우겠다고 약속합니다. 그러나 실제로 이 프로젝트는 대부분 휴면 상태로 보입니다. 이 글을 쓰는 시점에서 지난 두 달 동안 3개의 패키지만 업데이트되었습니다. 문제는 패키지가 서로를 기반으로 구축되어야 하지만 WAPM은 상호 종속성이 없는 독립 실행형 Wasm 바이너리에서만 잘 작동한다는 것입니다. 개발자를 위한 다른 옵션은 Wasm 모듈을 npm에 게시하는 것이지만, 물론 이는 언어 간 상호 운용성을 권장하지 않기 때문에 자바스크립트 또는 어셈블리스크립트(AssemblyScript)를 넘어 Wasm 생태계를 구축하는 데 이상적이지 않습니다.

문제는 실제로 WAPM 또는 npm의 잘못이 아니라 웹어셈블리 자체의 불완전함입니다.

런타임 또는 언어 경계를 넘어 상호 운용을 시도하는 웹어셈블리 애플리케이션을 작성하려면 오늘날 상당한 노력이 필요하며 문자열 또는 구조체같은 데이터 유형을 교환하려면 포인터 산술 및 저수준 메모리 조작이 필요합니다.
- Introduction to WebAssembly components | radu’s blog

이것이 바로 웹어셈블리 컴포넌트 모델(WebAssembly Component Model)이 해결할 문제입니다. Wasm 컴포넌트는 웹어셈블리 인터페이스 형식을 표준화하고 이러한 인터페이스를 구현하고 사용하기 위한 코드 생성기를 제공합니다. 즉, Wasm을 사용하여 런타임과 언어 경계를 쉽게 넘을 수 있습니다.

웹어셈블리용 고성능의 패키지 매니저를 구축할 수 있는 큰 기회가 있습니다. 다른 언어의 Wasm 모듈을 사용하기 위한 바인딩을 생성하려면 Wasm 컴포넌트 codegen을 사용해야 합니다. 도구가 충분히 좋다면 언어 간 개발을 쉽게 할 수 있으며 이는 서버 측 웹어셈블리 생태계의 진정한 열쇠가 될 것입니다. Wasm 패키지 레지스트리는 PyPI, npm 및 Crates.io에 적절하게 생성된 바인딩이 포함된 패키지를 자동으로 게시하여 다른 패키지 레지스트리 간에 신디케이트할 수도 있습니다.

결론

이 시점에서 당신은 아마도 웹어셈블리가 그렇게 좋은데 왜 더 널리 사용되지 않는지 생각하고 있을 것입니다. 제가 답변을 드리겠습니다.

웹어셈블리의 마케팅은 좋지 않았습니다. 웹이나 어셈블리에 국한되지 않기 때문에 이름도 잘못됐습니다. 웹어셈블리는 주로 웹 개발자를 대상으로 마케팅 및 추진되었지만 실제 잠재력은 브라우저를 넘어서 있습니다. 진정한 시작은 C++ 및 Rust 개발자가 Wasm이 보유하고 있는 잠재력을 인식하기 시작할 때 올 것입니다.
웹어셈블리 표준화는 아직 없습니다. 예를 들어 웹어셈블리 시스템 인터페이스(WebAssembly System Interface)에는 공식적으로 표준화되지 않은 수많은 확장이 있지만 다양한 런타임에서 이러한 확장을 선택하여 구현합니다. 보편적인 이식성에 대한 약속은 아직 완전히 실현되지 않았습니다.
언어 간 상호 작용이 형편없습니다. 사람들이 실제로 여러 언어에서 Wasm을 사용하기 시작하기 전에 중요한 언어에 대한 웹어셈블리 컴포넌트와 우수한 코드 생성기가 필요합니다.
개발자 경험이 많이 부족합니다. 특히 디버깅과 패키지 매니저, 빌드 시스템 및 IDE와의 통합과 관련된 도구 개선이 필요합니다.
이런 말은 하고 싶지 않지만 웹어셈블리의 라이브러리 격리 기능이 완전히 평가되기 전에 Log4Shell과 유사한 규모의 심각한 소프트웨어 공급망 사고가 몇 개 더 필요할 것입니다.

WebAssembly는 상당히 인상적인 장소 목록에 배포되어있으며 다양한 사용 사례를 제공하지만 이는 넓은 기술 세계 내에서 활동이 고립되어있음을 나타냅니다. 내 친구들 중에 웹어셈블리를 들어본 사람 중 일부는 원칙적으로 매우 흥미롭다고 생각하지만 아직 기술적으로 성숙하지 않았기때문에 시작하지 않고 있습니다. 그러나 이러한 문제 중 많은 부분이 적극적으로 작업 중이며 아마도 1~2년 내에 수용 가능한 상태에 도달할 것입니다. 따라서 웹어셈블리 활동, 생태계 및 커뮤니티가 폭발적으로 증가하기 직전인 것 같습니다.

Hacker News에서 토론하거나 생각을 보내주세요. 이 글의 초안에 피드백을 해준 Nihar Sheth, Mohak Jain, Andrew Sun, Michelle Fang에게 감사합니다.

참고

실제로 여기에 약간의 뉘앙스가 있습니다. Wasm에는 웹 API와 WASI(WebAssembly System Interface) API라는 두 가지 표준 API가 있습니다. WebAssembly도 빠르게 발전하고 있으므로 스레딩과 같이 널리 구현되었지만 공식적으로 표준화되지 않은 실험적인 기능이 많이 있습니다. 이 외에도 Wasm이 다른 애플리케이션에 포함되어 있으면 해당 애플리케이션이 자체 API를 제공할 수도 있습니다. Wasm 코드는 런타임에서 제공하는 API와 기능만 사용하는 경우 실행되어야 하며 이는 상당히 합리적인 가정입니다.
어떤 이유에서인지 모든 웹어셈블리 런타임 이름이 “wa”로 시작하는 것 같습니다. WasmEdge, WAVM 및 wasm3도 있습니다. 몇 안 되는 예외 중 하나는 Fizzy이지만 해당 프로젝트도 wasmx라는 조직에서 호스팅합니다.
그러나 Python 및 Ruby와 같은 인터프리트 언어 또는 Go와 같은 복잡한 런타임이 있는 언어를 Wasm에서 실행하면 아마도 좋은 성능을 내지 못할 것입니다.
Firefox에서 Wasm 컴파일은 실제로 네트워크가 패킷을 전달하는 것보다 빠릅니다. WebAssembly.instantiateStreaming 메서드를 사용하면 파일 다운로드를 완료하기도 전에 컴파일 프로세스를 시작할 수 있으므로 Wasm 코드 실행이 시작하기 전에 추가 대기 시간이 최소화됩니다.
맞습니다. 여기에는 여전히 불완전한 점이 있습니다. 기능 기반 권한 시스템은 아직 매우 세분화되지 않았으며 대부분의 Wasm 런타임은 Spectre와 같은 부채널 공격으로부터 보호하지 않으므로 몇 가지 추가 전략이 필요합니다. Cloudflare의 Kenton Varda는 위협 모델과 구현한 완화 방법에 대한 자세한 글을 작성했습니다.
Wasm은 자바스크립트의 “빠른 경로”에서 벗어날 때 발생하는 최적화 해제 문제를 피할 수 있기 때문에 자바스크립트의 최고 성능과 일치하거나 초과하는 동안 안정적으로 빠르게 실행됩니다. 재미있게도 자바스크립트를 WebAssembly로 컴파일하고 대신 실행하면 브라우저에서 자바스크립트를 더 빠르게 실행할 수 있습니다. Lin Clark은 이것이 어떻게 그리고 왜 작동하는지에 대해 훌륭한 이야기를 했습니다.
몇 년 전 Figma의 기술 리더와의 개인적인 대화를 나눴습니다. Google Chrome 및 Firefox를 포함한 많은 브라우저는 이미 내부적으로 Skia를 사용합니다. 그러나 Skia API를 직접 노출하지 않으므로 애플리케이션은 더 느린 브라우저 DOM 또는 SVG 인터페이스를 사용해야 합니다. Figma는 이러한 느린 레이어를 우회하여 브라우저 캔버스 요소에 직접 그립니다. 그러나 여전히 애플리케이션에 포함하여 일부 Skia 기능을 사용합니다.
다른 대안이 있다는 점은 주목할 가치가 있습니다. 예를 들어 AWS Lambda는 경량 Firecracker MicroVM을 사용합니다. 일대일에서 웹어셈블리는 몇 가지 성능 이점이 있습니다.
128비트 유형에 대한 웹어셈블리 SIMD 지원은 현재 실험적이지만 많은 브라우저 및 런타임에서 구현됩니다. “긴 SIMD” 지원은 향후 작업을 위해 남아 있습니다.
이 주장에 대한 반론은 “우리가 마이크로서비스를 분해할 수 있다고 해서 분해할 것이다를 의미하지 않는다”입니다. 이것은 확실히 타당한 비판이며 실제로 마이크로서비스의 맥락에서 모놀리스에도 적용된 비판입니다. 예를 들어, “프로덕션에서 마이크로서비스로 시작하지 마십시오. 모놀리스는 친구입니다”라는 제목의 최근 글은 많은 토론을 일으켰습니다. 그럼에도 불구하고 마이크로서비스 아키텍처는 적절한 환경에 배포될 때 엄청나게 효과적이고 생산적이며 웹어셈블리 중심 아키텍처에서도 마찬가지일 것으로 예상합니다. 웹어셈블리의 환경에서 얼마나 많은 적절한 상황이 존재하는지는 명확하지 않습니다.
이 문제는 밈이 있을 정도로 잘 알려져 있습니다.
누군가는 아마도 이것을 하는 회사를 세워야 할 것입니다. 최근 Log4j 취약점을 고려할 때 소프트웨어 공급망이 가장 중요하며, 대부분의 기존 회사는 종속성을 분리하는 대신 종속성을 확인하는 데 초점을 맞추고 있는 것 같습니다.
Terraform은 배포 및 클라우드 제공자와의 상호 작용만 추상화하는 반면 이 프레임워크는 코드 계층에서도 작동하기 때문에 이것이 최상의 비교가 아닐 수도 있습니다.