Bytecode Alliance, WebAssembly Component Model 1.0 로드맵 공개

Bytecode Alliance 공식 블로그에 따르면 이 단체는 2026년 6월 8일 WebAssembly Component Model 1.0으로 가기 위한 로드맵을 공개했다. 이번 글은 WASI P3가 네이티브 비동기 지원을 앞둔 상황에서, 그 다음 이정표로 안정적이고 정식 명세화된 Component Model 1.0을 제시한 것이 핵심이다.

Component Model은 WebAssembly 바이너리가 서로 묶이고, 연결되고, 타입이 있는 값으로 통신하는 방식을 정의하는 사양이다. Bytecode Alliance는 이를 WebAssembly 위에 놓이는 기초 계층으로 설명한다. WASI는 파일, 소켓, 시계, 난수 같은 시스템 자원 접근 API를 이 계층 위에서 제공한다.

이번 로드맵에서 가장 먼저 제시된 과제는 ABI 개선이다. 현재 Component Model은 컴포넌트가 값을 주고받을 때 cabi_realloc 기반 호출 규약을 사용한다. Bytecode Alliance는 이 방식이 큰 값 처리, 메모리 단편화, 커스텀 할당자 사용에서 마찰을 만들 수 있다고 설명했다. 새 방향은 값을 즉시 복사하지 않고 지연 처리하는 lazy ABI를 선택 기능으로 도입한 뒤, 1.0 시점에는 기본값으로 삼는 방식이다.

성능도 주요 과제로 꼽혔다. 비동기 작업 인프라가 컴포넌트 경계에 들어오면서 순수 동기 호출에서도 오버헤드가 생겼고, 로드맵은 동기 호출 경로의 비용을 다시 낮추는 작업을 1.0 준비 항목에 포함했다. 목표는 컴파일러가 불필요한 작업 상태를 최적화해 컴포넌트 간 동기 호출 비용을 줄이는 것이다.

브라우저 구현은 1.0의 또 다른 조건으로 제시됐다. Bytecode Alliance는 Component Model이 정식 1.0에 도달하려면 적어도 두 개의 브라우저 엔진에서 네이티브 구현이 필요하다고 밝혔다. 현재 jco는 컴포넌트를 코어 Wasm과 JavaScript 접착 코드로 변환해 브라우저에서 실행할 수 있게 하지만, 네이티브 지원은 성능과 생태계 확산 측면에서 의미가 크다.

명세 단순화와 도구화도 함께 추진된다. 로드맵은 1.0 명세가 기존 P3 전체를 그대로 포함하기보다 안정적으로 가져갈 수 있는 부분을 중심으로 정리될 것이라고 설명했다. 또한 게스트와 호스트를 위한 C ABI, 컴포넌트를 단일 코어 Wasm 모듈처럼 낮추는 도구, WIT 기능 확장 등이 구현 부담을 줄이는 수단으로 제시됐다.

이번 발표는 WebAssembly가 브라우저 안의 실행 포맷을 넘어 서버, 플러그인, 샌드박스형 애플리케이션 런타임으로 확장되는 흐름을 보여준다. Component Model 1.0은 여러 언어로 작성된 컴포넌트를 표준 인터페이스로 조립하고 배포하는 기반이 될 수 있다. 다만 구체적인 1.0 확정 시점, 브라우저 엔진별 지원 일정, LLVM 멀티값 C ABI 지원 시기는 아직 후속 작업에 달려 있다.

출처: Bytecode Alliance https://bytecodealliance.org/articles/the-road-to-component-model-1-0
출처: WebAssembly Component Model Documentation https://component-model.bytecodealliance.org/
출처: WebAssembly Component Model GitHub https://github.com/webassembly/component-model