WebAssembly, 웹에서 1급 시민으로 거듭날 수 있을까?

저자는 WebAssembly(Wasm)이 2017년 출시 이후 공유 메모리(Shared Memories), SIMD, 예외 처리(Exception Handling) 등 다양한 기능을 추가하며 발전해 왔다고 언급한다. 하지만, Wasm은 여전히 웹에서 JavaScript와 같은 1급 언어(First-Class Language)로 취급받지 못하며, 이는 Wasm의 광범위한 채택을 가로막는 주요 원인으로 작용한다. 특히, Web API 접근과 컴파일러 지원 부족은 개발자 경험을 저해하는 요소로 지적된다.

WebAssembly에서 Web API를 사용하기 위해서는 JavaScript glue code가 필수적이다. 이 코드는 Wasm 데이터를 JavaScript 데이터로, 또는 그 반대로 변환하는 역할을 수행하며, 개발 과정에서 상당한 복잡성을 야기한다. 또한, glue code는 런타임 오버헤드를 발생시켜 성능 저하를 유발한다. 저자는 DOM API 호출 시 glue code로 인해 45%의 성능 저하가 발생할 수 있다는 실험 결과를 제시하며, 이러한 오버헤드가 WebAssembly의 활용을 제한하는 요인임을 강조한다.

저자는 WebAssembly Component Model을 통해 Wasm의 웹 플랫폼 통합을 시도한다. 이 모델은 표준화된 실행 파일(Standardized Executable Artifact)을 생성하여 여러 언어와 툴체인에서 지원받을 수 있도록 설계되었다. Component Model은 Web API 직접 호출을 지원하여 JavaScript glue code의 필요성을 없애고, 개발자 경험을 개선하는 것을 목표로 한다. Mozilla는 이 모델의 설계를 주도하고 있으며, Google도 평가 중에 있다.

WebAssembly Component Model은 WIT(Web Interface Type)라는 IDL을 사용하여 Web API를 정의한다. 이를 통해 개발자는 JavaScript 없이도 Wasm 컴포넌트 내에서 Web API를 직접 호출할 수 있다. 예를 들어, `std:web/console` 인터페이스를 정의하고, Rust 코드를 사용하여 `console::log` 함수를 호출하는 방식으로 구현할 수 있다. 또한, Component Model은 cross-language interoperability를 지원하여 JavaScript 코드와 Wasm 컴포넌트 간의 상호 작용을 용이하게 한다.

댓글에서는 Wasm 바이너리를 JavaScript glue code 없이 부팅하는 것에 대한 긍정적인 반응이 나타났다. 하지만, reference type passing에 대한 지원 부족과 비 웹 런타임(non-web runtimes)에 대한 지향성에 대한 우려도 제기되었다. 다른 댓글에서는 기존의 component model과 IDL이 호환성 문제를 해결하지 못했다는 점을 지적하며, 새로운 모델의 성공에 대한 회의적인 시각을 보이기도 했다.