WebAssembly Component Model은 여러 WebAssembly 조각을 명시적인 인터페이스로 연결하기 위한 계층입니다. Core WebAssembly module의 실행 규칙과, component가 언어 간 경계에서 주고받을 함수·타입 계약을 구분해야 합니다. WIT 정의는 interface와 world를 설명하고, WebAssembly 3.0 안내는 Core 기능의 현재 범위를 설명합니다.

Core module과 component는 같은 형식의 층이 아니다

Core module은 함수, 메모리, 테이블, import/export 등 낮은 수준의 실행 구조를 정의합니다. Core 3.0에는 한 module 안의 다중 메모리와 더 풍부한 참조 타입도 포함됩니다. 따라서 Wasm을 “항상 메모리 하나와 숫자 타입만 있는 코드”라고 설명하면 현재 표준을 놓칩니다. 다만 표준에 기능이 있다는 사실이 사용하는 모든 브라우저·서버 runtime에서 같은 버전으로 지원된다는 뜻은 아닙니다.

Component Model은 Core module이나 다른 component를 더 높은 수준의 계약으로 묶습니다. WIT에서 interface는 함수와 타입을 모으고, world는 component가 가져오는(import) 기능과 외부로 제공하는(export) 기능 전체를 나타냅니다. component를 연결하는 쪽은 이름만 맞추는 것이 아니라 타입과 필요한 import가 서로 호환되는지 확인합니다.

플러그인 경계를 WIT로 먼저 설계하기

로그 정규화 플러그인을 만든다고 가정해 보세요. host가 log.write(message) 같은 기능을 import로 제공하고, 플러그인은 normalize(record)를 export하는 세계를 정의할 수 있습니다. 플러그인 구현은 지원하는 언어로 만들되, 호출자는 WIT 계약을 기준으로 연결합니다. 이 계약은 “모든 host 기능이 자동 제공된다”는 의미가 아닙니다. 파일·네트워크·시간 같은 외부 접근도 host가 명시적으로 연결하고 runtime이 허용해야 사용할 수 있습니다.

인터페이스를 나누면 플러그인이 실제로 필요한 기능을 검토하기 쉽습니다. 단, import 목록이 있다고 보안이 자동 완성되는 것은 아닙니다. host가 너무 강한 기능을 제공하거나 입력을 검증하지 않으면 위험은 남습니다. 호출 권한, 데이터 크기, 오류 처리, 비용 한도를 host 애플리케이션에서 설계하세요.

실제 호출 전 확인할 호환성

Component Model 바이너리와 WIT를 처리하는 도구 지원은 Core .wasm module 지원과 같은 질문이 아닙니다. build toolchain, component linker, 실행 runtime이 필요한 Model/WASI 버전과 타입을 지원하는지 확인하고, 실제 배포 대상에서 import/export 연결 테스트를 해야 합니다. WebAssembly 프로젝트의 기능 표는 popular engines와 tools의 구현 현황을 추적하므로, 명세만 읽고 지원을 추정하지 말고 대상 버전을 확인하세요.

또한 Component Model은 별도의 실행 성능이나 완전한 보안 격리를 보장하는 표어가 아닙니다. 경계 변환·호출 비용은 실제 workload로 측정하고, sandbox와 capability 정책은 선택한 runtime과 host 설정에서 검토해야 합니다.

작은 검증 시나리오

플러그인을 연결하기 전에 다음 흐름을 시험합니다. 먼저 WIT world의 각 import와 export를 읽고 예상 기능을 목록화합니다. 그다음 host가 필요한 import만 연결하는지 확인합니다. 정상 입력, 잘못된 레코드, 크기가 큰 입력, import 실패를 각각 실행해 반환값과 오류가 계약대로 나오는지 봅니다. 마지막으로 실제 배포 runtime에서 같은 component를 로드해 개발 환경과의 기능 차이를 확인합니다.

참고 자료