WebAssembly 서버 사이드 — WASI와 컴포넌트 모델이 여는 실행의 미래 | 뉴스

브라우저를 빠르게 만들려고 태어난 기술이, 이제 서버의 실행 모델을 다시 쓰고 있다. WebAssembly(Wasm) 이야기다. 처음엔 웹에서 C++ 게임을 돌리는 용도로 알려졌지만, 지금 가장 뜨거운 무대는 브라우저가 아니라 서버 사이드다. 그 전환의 중심에 WASI(WebAssembly System Interface)와 컴포넌트 모델(Component Model)이 있다.

핵심 질문은 이것이다. 컨테이너가 이미 배포 문제를 풀었는데, 왜 또 새로운 실행 단위가 필요한가? 답은 컨테이너가 여전히 무겁고, 느리게 뜨고, OS에 묶여 있기 때문이다. Wasm은 그 세 가지를 정면으로 겨냥한다.

서버 사이드 Wasm의 승부처는
밀리초 단위 콜드 스타트와 기본 격리다.

컨테이너가 초 단위로 뜨는 자리에서 Wasm 모듈은 순간적으로 뜬다. 게다가 기본이 샌드박스라 권한을 명시하지 않으면 아무것도 못 한다.

밀리초기동

컨테이너 대비
극단적 콜드스타트

기본샌드박스

권한 명시
능력 기반 보안

다중언어

Rust·Go·JS
하나의 타깃

이식성한번

CPU·OS 독립
어디서나 실행

WASI가 없으면 Wasm은 반쪽

순수한 Wasm 모듈은 계산만 할 줄 안다. 파일을 읽거나, 네트워크에 접속하거나, 시간을 조회하는 법을 모른다. 브라우저에서는 JavaScript가 그 다리를 놔줬지만, 서버에는 브라우저가 없다. WASI는 바로 그 "바깥세상과 대화하는 표준 규약"이다. 파일 시스템, 소켓, 시계, 무작위 수 같은 시스템 자원을 이식 가능한 방식으로 노출한다.

중요한 건 그 철학이다. WASI는 능력 기반 보안(capability-based security)을 택했다. 모듈은 명시적으로 건네받은 자원에만 접근할 수 있다. 어떤 디렉터리를 열어주지 않으면 그 디렉터리는 존재하지 않는 것과 같다. "일단 다 열어놓고 막는" 유닉스식 모델과 정반대다.

Preview 1에서 Preview 2로

초기 WASI(Preview 1)는 대체로 파일과 표준 입출력 수준에 머물렀다. 판을 바꾼 건 WASI Preview 2와 함께 온 컴포넌트 모델이다. 네트워킹, HTTP, 키-값 저장 같은 고수준 인터페이스가 표준 조각으로 정의되면서, Wasm이 실제 서버 애플리케이션을 담을 그릇이 됐다.

컴포넌트 모델 — 진짜 도약

컴포넌트 모델은 이 이야기에서 가장 저평가된, 그러나 가장 결정적인 조각이다. 지금까지 서로 다른 언어로 짠 코드를 합치려면 C ABI라는 좁고 원시적인 통로를 억지로 통과해야 했다. 문자열 하나, 리스트 하나 주고받는 데도 손이 많이 갔다.

컴포넌트 모델은 WIT(Wasm Interface Types)라는 언어 중립 인터페이스 정의로 이 문제를 푼다. Rust로 짠 컴포넌트가 Go로 짠 컴포넌트를 부르고, 그 결과를 JavaScript 컴포넌트가 받아 쓰는 일이 자연스러워진다. 각 조각은 자기 안에 완전히 격리된 채, 정의된 인터페이스로만 대화한다.

언어 장벽 붕괴 — 팀마다 다른 언어를 써도 컴포넌트 경계에서 매끄럽게 조립된다. 라이브러리를 "언어별로" 다시 짤 필요가 줄어든다.
플러그인 아키텍처 — 신뢰할 수 없는 서드파티 코드를 컴포넌트로 받아 안전하게 실행한다. 데이터베이스·프록시·SaaS의 확장 지점으로 이상적이다.
조립식 배포 — 애플리케이션을 재사용 가능한 컴포넌트의 조합으로 구성한다. 컨테이너 이미지 한 덩어리보다 훨씬 세밀하다.

어디에서 이미 쓰이나

가장 빠르게 자리 잡은 곳은 엣지 컴퓨팅이다. 전 세계 수백 개 지점에서 요청마다 함수를 띄워야 하는 엣지 플랫폼에게, 컨테이너의 콜드 스타트는 치명적이다. Wasm의 밀리초 기동은 여기서 결정적 무기가 된다. 사용자 요청이 도착한 지역에서 즉시 코드를 실행하고, 끝나면 흔적 없이 사라진다.

두 번째는 플러그인·확장 런타임이다. 프록시, 데이터베이스, 관측 도구들이 사용자 정의 로직을 안전하게 끼워 넣는 통로로 Wasm을 택하고 있다. 호스트 프로세스를 위협하지 않으면서 임의 코드를 돌릴 수 있다는 점이 핵심이다.

항목	서버 Wasm	컨테이너
기동 시간	밀리초 이하	수백 ms~초
격리 기본값	기본 샌드박스	커널 공유·설정 필요
이식성	CPU/OS 독립	아키텍처별 이미지
아티팩트 크기	수십 KB~MB	수십~수백 MB
생태계 성숙도	성장 중	성숙

현실적 한계

과열된 기대에는 냉정한 각주가 필요하다. Wasm은 컨테이너를 대체하기보다 보완한다. 무거운 상태 저장 서비스, 기존 시스템 콜에 깊이 의존하는 워크로드, 성숙한 컨테이너 생태계를 이미 활용하는 조직에게 전면 이주는 아직 무리다. 스레딩, 가비지 컬렉션 통합, 디버깅 도구 같은 부분도 계속 다듬는 중이다.

그럼에도 방향은 뚜렷하다. "한 번 빌드해서 어디서나, 즉시, 안전하게 실행한다"는 오래된 약속을 Wasm은 이전 어떤 기술보다 진지하게 실현하고 있다. 컨테이너가 배포의 표준이 됐듯, Wasm 컴포넌트는 세밀하고 안전한 실행 단위의 표준을 노린다.

자주 묻는 질문

서버 사이드 Wasm이 컨테이너를 대체하나요?

당장은 대체가 아니라 보완입니다. 밀리초 콜드 스타트와 강한 격리가 중요한 엣지 함수, 플러그인, 멀티테넌트 실행에는 Wasm이 유리하고, 무거운 상태 저장 서비스나 성숙한 오케스트레이션이 필요한 곳은 여전히 컨테이너가 강합니다. 둘을 섞어 쓰는 아키텍처가 현실적입니다.

WASI와 WebAssembly는 무엇이 다른가요?

WebAssembly는 이식 가능한 바이너리 실행 포맷 자체이고, WASI는 그 바이너리가 파일·네트워크·시계 같은 시스템 자원과 안전하게 대화하도록 정의한 표준 인터페이스입니다. 브라우저 밖에서 Wasm을 실용적으로 쓰려면 WASI가 반드시 필요합니다.

컴포넌트 모델이 왜 중요한가요?

서로 다른 언어로 짠 코드를 언어 중립 인터페이스(WIT)로 조립할 수 있게 해주기 때문입니다. Rust 컴포넌트와 Go 컴포넌트가 각자 격리된 채 정의된 규약으로만 대화하므로, 언어 장벽을 넘는 재사용과 안전한 플러그인 실행이 가능해집니다.

어떤 언어로 서버 Wasm을 짤 수 있나요?

Rust와 Go가 가장 성숙하고, C/C++, JavaScript, Python 등도 다양한 수준으로 지원됩니다. 언어에 따라 툴체인 성숙도와 지원 기능이 다르므로, 프로덕션에 넣기 전에 대상 언어의 WASI/컴포넌트 지원 현황을 확인하는 것이 좋습니다.