WebAssembly — 2025년에도 왜 아직 "차세대" 소리를 듣는 걸까

2019년 12월 5일, W3C가 WebAssembly를 공식 권고안(Recommendation)으로 채택했다. 그게 5년 전 이야기인데, 지금도 업계에서 "WebAssembly가 드디어 본격적으로 쓰일 것 같다"는 말이 반복된다. 왜 그럴까.

답은 간단하다. WASM은 처음부터 용도가 두 갈래였다. 하나는 **브라우저 안에서의 성능 문제 해결**, 다른 하나는 **브라우저 밖에서의 범용 실행 환경**. 전자는 이미 상당히 성숙했고, 후자가 아직도 "차세대"다.

## 브라우저 안 WASM: 이미 여기에 있다

Figma를 써봤다면 WASM을 쓰고 있는 거다. 2015년부터 Figma는 C++ 렌더링 엔진을 WASM으로 컴파일해 브라우저에서 네이티브에 가까운 속도로 돌렸다. Adobe의 Photoshop 웹 버전도 2021년에 WASM 기반으로 출시됐다.

공통점은 둘 다 기존에 C/C++로 짜인 방대한 코드베이스를 **그대로 웹으로 가져왔다**는 점이다. 자바스크립트로 재작성하지 않고, Emscripten 같은 툴체인으로 WASM 바이너리로 컴파일했다. 이 방식은 이미 프로덕션에서 검증됐다.

게임 쪽도 마찬가지다. Unity WebGL은 WASM을 기반으로 한다. 브라우저에서 3D 게임이 그나마 돌아가는 게 WASM 덕분이다.

## 브라우저 밖 WASM: 아직 "차세대"인 이유

2019년, Mozilla의 엔지니어 Lin Clark이 한 말이 유명하다: *"WASM과 WASI가 2008년에 나왔더라면 Docker를 발명할 필요가 없었을 것이다."*

WASI(WebAssembly System Interface)는 WASM을 OS 수준에서 실행하기 위한 표준 인터페이스다. 아이디어는 매력적이다. WASM 바이너리를 한 번만 빌드하면 Linux든 macOS든 Windows든, 아키텍처가 x86이든 ARM이든 어디서나 그대로 실행된다. 컨테이너보다 훨씬 가볍고, 샌드박스 보안 모델도 기본 내장이다.

Wasmtime(Bytecode Alliance), Wasmer, WasmEdge 등 런타임들이 이 공간에 있다. AWS Lambda, Fastly, Cloudflare Workers 같은 엣지 컴퓨팅 플랫폼들도 WASM 실행을 지원하기 시작했다.

문제는 **언어 간 상호운용성**이다. Rust로 만든 WASM 모듈이 Python에서 부른 WASM 모듈과 데이터를 주고받으려면 표준 인터페이스가 필요한데, 이게 바로 **Component Model**이다. 2023년부터 Wasmtime에 실험적으로 구현됐고, 2024~2025년에 걸쳐 사양이 구체화되고 있다. 이 부분이 아직 완전히 굳지 않아서 "차세대"가 반복되는 것이다.

## 한계도 솔직히 봐야 한다

- **DOM 직접 접근 불가**: WASM은 DOM API를 직접 호출하지 못한다. JavaScript 바인딩을 거쳐야 한다. 브라우저 안에서 UI 중심 작업은 여전히 JS가 우위다.
- **디버깅**: WASM 소스맵은 점점 좋아지고 있지만, JavaScript 디버깅 경험과는 아직 격차가 있다.
- **바이너리 크기**: Hello World 수준도 수백 KB다. 스트리밍 컴파일이 완화해주지만 모바일 LTE 환경에서는 체감된다.

## 정리하자면

WASM은 이미 프로덕션에 있다. 대형 C++ 코드베이스를 웹으로 가져올 때, 엣지에서 샌드박스 환경이 필요할 때, 계산 집약적 작업을 브라우저 안에서 돌릴 때. 이 세 케이스에서 이미 쓸 이유가 명확하다.

"차세대"라는 말이 반복되는 건 가능성이 크기 때문이지 아직 미성숙하기 때문이 아니다. Component Model이 안정화되고 WASI 2.0이 굳으면 서버 쪽에서도 실제 도입 사례가 빠르게 늘어날 것이다.

지금 당장 써야 하는지는 팀 상황에 따라 다르다. 하지만 적어도 "이게 뭔지"는 알아두는 게 맞다.

WebAssembly — 2025년에도 왜 아직 "차세대" 소리를 듣는 걸까

// COMMENTS

ON THIS PAGE