WebAssembly 컴포넌트 모델 — 브라우저 밖으로 나온 WASM과 WASI | 뉴스

웹어셈블리(WebAssembly, WASM)는 처음 등장할 때 "브라우저에서 네이티브급 속도로 무거운 연산을 돌리는 기술"로 소개됐다. 그런데 요즘 WASM을 둘러싼 진짜 흥미로운 이야기는 브라우저 밖에서 벌어진다. 컴포넌트 모델과 WASI라는 두 축이 WASM을 범용 실행 포맷으로 밀어 올리는 중이다.

컴포넌트 모델은 서로 다른 언어로 짠 WASM 모듈들이 공통의 인터페이스로 안전하게 조립되도록 하는 규격이다. WASI는 그 WASM이 브라우저가 아닌 환경에서 파일이나 네트워크 같은 시스템 자원에 접근하는 표준 방식이다. 둘을 합치면, 언어를 가리지 않고 어디서나 돌아가는 이식 가능한 부품이라는 그림이 나온다.

WASM의 다음 장은 브라우저가 아니라 서버와 엣지에서 쓰이고 있다.
컴포넌트 모델은 언어의 장벽을 넘는 조립을 표준화한다.

"한 번 만들면 어디서나 돈다"는 오랜 약속을, 가볍고 안전한 샌드박스 위에서 다시 시도하는 흐름이다.

다언어

여러 언어를
한 규격으로

샌드박스

기본 격리
권한 명시

빠른시작

경량 인스턴스
즉시 기동

이식성

브라우저·서버
·엣지 공통

브라우저를 넘어선 이유

WASM에는 애초부터 매력적인 성질이 있었다. 안전한 샌드박스 안에서 돌고, 시작이 빠르며, 언어에 중립적이라는 점. 이 성질들은 사실 브라우저보다 서버와 엣지 환경에서 더 절실하다. 신뢰할 수 없는 코드를 안전하게 격리해 실행하고, 요청이 올 때마다 순식간에 인스턴스를 띄우고, 어떤 언어로 짰든 같은 방식으로 배포하고 싶은 곳이 바로 그런 환경이기 때문이다.

기존의 컨테이너는 이 요구를 어느 정도 채웠지만 무겁다. 운영체제 이미지를 통째로 싸 들고 다니고, 기동에 시간이 걸린다. WASM 모듈은 훨씬 작고 가벼워서, 수많은 작은 함수를 순식간에 띄웠다 내리는 엣지 시나리오에 잘 맞는다. 나는 이 지점에서 WASM이 컨테이너를 대체한다기보다, 컨테이너가 무거워서 못 가던 자리를 새로 채운다고 이해한다.

컴포넌트 모델이 푸는 문제

초기 WASM에는 결정적 불편이 있었다. 모듈끼리 주고받을 수 있는 게 숫자 같은 저수준 값뿐이라, 문자열이나 구조체처럼 복잡한 데이터를 넘기려면 양쪽이 메모리 배치를 손으로 맞춰야 했다. 서로 다른 언어로 짠 모듈을 엮는 건 특히 고통스러웠다.

공통 인터페이스

컴포넌트 모델은 이걸 해결한다. 각 컴포넌트가 자신이 제공하고 필요로 하는 것을 언어 중립적인 인터페이스 정의로 선언한다. 그러면 한 언어로 짠 컴포넌트가 노출한 기능을 전혀 다른 언어로 짠 컴포넌트가 자연스러운 타입으로 가져다 쓴다. 문자열, 리스트, 레코드 같은 고수준 타입이 경계를 넘어 오간다.

// 인터페이스를 선언하면 언어에 상관없이 조립된다
interface greeter {
  greet: func(name: string) -> string;
}

이게 왜 중요하냐면, 소프트웨어를 진짜 부품처럼 다루게 되기 때문이다. 이미지 처리는 한 언어의 강력한 라이브러리로, 암호화는 다른 언어의 검증된 구현으로 만들어 놓고, 그것들을 언어 걱정 없이 조립한다.

WASI: 바깥세상과의 연결

WASM은 기본적으로 아무것도 못 한다. 순수한 계산만 가능하고 파일도, 네트워크도, 시계도 스스로 건드릴 수 없다. 이 철저한 무능력이 역설적으로 보안의 원천이다. WASI는 이 격리된 코드에 시스템 자원으로 향하는 문을 표준화된 방식으로 열어 준다. 중요한 건, 그 문이 기본으로 닫혀 있고 필요한 권한만 명시적으로 열린다는 점이다. 코드가 접근할 수 있는 건 실행하는 쪽이 허락한 자원뿐이다.

항목	WASM 모듈	전통적 컨테이너
크기	가볍다	OS 이미지 포함
기동 속도	즉시에 가까움	상대적으로 느림
격리 방식	권한 명시(기본 차단)	네임스페이스 격리
이식성	아키텍처 무관	이미지 아키텍처 의존

아직 이른 곳과 유망한 곳

솔직히 아직 모든 게 매끈하지는 않다. 컴포넌트 모델과 WASI는 계속 다듬어지는 중이라, 언어별 지원 성숙도가 제각각이고 생태계도 컨테이너만큼 두텁지 않다. 무거운 기존 애플리케이션을 통째로 WASM으로 옮기는 건 아직 무리한 경우가 많다.

반대로 지금도 빛나는 자리가 있다. 플러그인 시스템이 대표적이다. 사용자가 올린 코드를 안전하게 격리해 실행해야 하는 확장 기능, 여러 언어로 작성한 확장을 한 호스트에 꽂는 구조에 WASM은 거의 맞춤이다. 엣지에서 짧게 실행되는 함수, 신뢰 경계를 넘나드는 코드 실행도 유망하다. 나는 WASM의 미래를 "모든 걸 대체하는 혁명"이 아니라 "컨테이너가 못 가던 틈을 정밀하게 채우는 확장"으로 본다. 그리고 그 틈은 생각보다 넓다.

자주 묻는 질문

WASM이 컨테이너를 대체하나요?

전면적 대체보다는 보완에 가깝다. 무겁고 복잡한 애플리케이션은 여전히 컨테이너가 낫고, WASM은 가볍고 빠른 기동이 필요한 엣지 함수나 플러그인 실행처럼 컨테이너가 부담스러운 자리를 채운다.

컴포넌트 모델이 기존 WASM과 뭐가 다른가요?

초기 WASM은 모듈 간에 저수준 값만 주고받을 수 있었다. 컴포넌트 모델은 문자열이나 구조체 같은 고수준 타입을 언어 중립적 인터페이스로 주고받게 해, 서로 다른 언어로 짠 부품의 조립을 실용적으로 만든다.

WASI는 왜 필요한가요?

WASM 코드는 기본적으로 파일이나 네트워크 같은 외부 자원에 접근할 수 없다. WASI는 이 접근을 표준화된 방식으로, 그것도 필요한 권한만 명시적으로 허용하며 제공해 브라우저 밖 실행을 가능하게 한다.

지금 실무에 도입할 만한가요?

플러그인 시스템, 신뢰할 수 없는 코드의 격리 실행, 짧게 도는 엣지 함수 같은 영역이라면 지금도 실용적이다. 반면 대규모 기존 앱의 전면 이식은 생태계 성숙도를 고려해 신중히 접근하는 편이 좋다.