WASI 0.3 안정화…WebAssembly 컴포넌트에 네이티브 async 도입

Bytecode Alliance 공식 발표에 따르면 WASI Subgroup은 WASI 0.3.0을 비준했고, 0.3.0 사양은 안정 상태에 들어갔다. 이번 버전의 핵심은 WebAssembly Component Model의 비동기 원시 기능 위로 WASI를 다시 얹어, WebAssembly 컴포넌트에서 async가 네이티브 기능으로 동작하게 한 점이다.

WASI는 WebAssembly System Interface의 약자로, WebAssembly로 컴파일된 프로그램이 파일, 네트워크, 시계, 난수 같은 시스템 자원에 접근할 수 있도록 표준 API를 제공하는 사양 묶음이다. WASI.dev 문서는 WASI가 브라우저뿐 아니라 클라우드, 임베디드, 플러그인, 서버리스 환경에서 여러 언어로 작성된 소프트웨어를 조합하기 위한 기반이라고 설명한다.

WASI 0.3에서 가장 큰 변화는 비동기 작업의 책임이 개별 컴포넌트 내부 런타임에서 호스트와 Component Model 쪽으로 이동했다는 점이다. 이전 WASI 0.2에서는 각 컴포넌트가 자체 이벤트 루프나 비동기 런타임을 가져야 했고, 이 때문에 스트리밍이나 비동기 API를 쓰는 컴포넌트를 다른 컴포넌트와 자연스럽게 조합하기 어려웠다.

새 사양은 Component Model의 canonical ABI에 stream<T>, future<T>, async를 일급 구성요소로 넣는다. Bytecode Alliance는 런타임이 여러 컴포넌트 사이의 스케줄링을 맡고, 컴포넌트는 async 함수를 직접 가져오거나 내보낼 수 있게 된다고 설명했다. WASI 0.2에서 쓰이던 start-foo, finish-foo, subscribe 같은 우회 구조는 WASI 0.3에서 foo: async func(...) 형태로 단순화된다.

이 변화는 언어 바인딩에도 영향을 준다. Rust, Python, JavaScript, C#, C, Go 같은 언어의 바인딩 생성기는 각 언어에 맞는 비동기 호출 형태를 더 자연스럽게 만들 수 있다. 예를 들어 HTTP 핸들러 인터페이스는 async 함수로 표현되고, Rust에서는 async fn, Go에서는 고루틴과 런타임 경계의 일시 정지·재개 방식으로 연결될 수 있다.

wasi:http도 주요 변경 대상이다. 발표에 따르면 WASI 0.3은 단순히 기존 poll 기반 인터페이스를 비동기로 바꾸는 데 그치지 않고, HTTP 관련 world와 타입 구조를 재정리했다. 이는 WebAssembly 컴포넌트를 서버, 엣지, 플러그인 환경에서 HTTP 요청 처리 단위로 쓰려는 흐름과 맞닿아 있다.

개발자 생태계에서 이번 발표가 갖는 의미는 WebAssembly의 역할이 단일 모듈 실행을 넘어 조합 가능한 소프트웨어 단위로 확장되고 있다는 점이다. 서로 다른 언어로 작성된 컴포넌트가 표준 ABI를 통해 비동기 호출과 스트림을 주고받을 수 있다면, 서버리스 함수, 데이터베이스 확장, 엣지 런타임, 애플리케이션 플러그인 구조에서 Wasm의 활용 범위가 넓어질 수 있다.

다만 실제 도입은 런타임과 툴체인 지원 속도에 달려 있다. Bytecode Alliance는 런타임과 도구 지원이 이제 반영되는 단계라고 설명했으며, 개별 프로젝트들이 앞으로 몇 주 또는 몇 달에 걸쳐 WASI 0.3 지원을 발표할 것으로 내다봤다. 기존 WASI 0.2 기반 구성요소와의 호환, 언어별 바인딩 안정화, 배포 환경별 지원 여부는 후속 확인이 필요하다.

출처: Bytecode Alliance https://bytecodealliance.org/articles/WASI-0.3
출처: WASI.dev https://wasi.dev/