WebAssembly: 브라우저의 두 번째 언어

WebAssembly란

WebAssembly(Wasm)는 컴파일 대상으로 설계된 저수준 바이트코드 형식이다. 사람이 직접 쓰기보다 C·C++·Rust·Go·Kotlin 같은 언어를 컴파일해 만든다. 브라우저의 JavaScript 엔진 안에서 JavaScript와 같은 가상 머신, 같은 보안 모델(동일 출처·권한 정책) 으로 돌고, 거의 네이티브에 가까운 속도를 낸다.

JavaScript를 대체하지 않고 보완한다. 앱의 뼈대·UI·생태계는 JavaScript가, 무거운 계산(영상·이미지 처리, 3D, 물리, 압축, 암호화, 기존 C++ 엔진 이식)은 Wasm이 맡는 식이다. Wasm은 DOM에 직접 손대지 못하고, 웹 API는 JavaScript를 거쳐 부른다.

설계 목표

왜 빠른가: JavaScript와 시간 비교

JavaScript도 2008년 JIT 경쟁 이후 10배 넘게 빨라졌다. 엔진은 코드를 돌리며 타입을 관찰하고, 자주 도는(hot) 코드를 최적화 컴파일러에 넘긴다(JavaScript 엔진과 V8). Wasm은 그 과정의 여러 단계를 미리 해 두거나 건너뛴다.

단, JS ↔ Wasm 경계를 넘는 비용이 있다. 숫자만 넘나들 수 있었던 MVP에서는 문자열·객체를 선형 메모리에 복사해 옮겨야 했다. 작은 함수를 경계 너머로 자주 부르면 오히려 느려진다. 큰 일을 한 번에 넘기는 구조가 맞다.

네 가지 핵심 개념

// 서버는 .wasm을 Content-Type: application/wasm 으로 보내야 스트리밍 컴파일이 된다
const { instance } = await WebAssembly.instantiateStreaming(fetch('/add.wasm'), {
  env: { log: (n) => console.log(n) }, // Wasm이 import해서 동기로 부르는 JS 함수
})
instance.exports.add(2, 3) // export된 Wasm 함수는 평범한 JS 함수처럼 호출된다

Memory는 JS에서 new Uint8Array(instance.exports.memory.buffer)로 들여다본다(바이너리 데이터와 파일). 메모리가 늘어나면 기존 ArrayBuffer가 분리되므로 뷰를 다시 만든다.

만드는 방법

디버깅은 DWARF 정보를 넣어 DevTools에서 원래 C/C++·Rust 소스에 중단점을 건다(DevTools 디버깅).

MVP 이후: 기능이 붙어 온 순서

2017년 네 브라우저가 MVP(정수·부동소수 연산, 선형 메모리 하나, 함수 테이블)를 동시에 탑재했고, 2019년 W3C 표준(1.0)이 됐다. 그 뒤 기능은 독립 제안으로 하나씩 들어왔다. 버전 번호는 묶음에 붙인 이름일 뿐, 브라우저는 기능별로 지원한다.

기능별 브라우저 지원은 webassembly.org의 기능 표에서 확인한다. 스레드는 교차 출처 격리(COOP·COEP)가 된 페이지에서만 쓸 수 있다.

브라우저 밖의 Wasm

Wasm의 샌드박스와 이식성은 서버에서도 쓸모가 있다. WASI(WebAssembly System Interface)는 파일·소켓·시계 같은 시스템 기능을 권한 기반으로 노출하는 표준 인터페이스이고, 컴포넌트 모델은 언어가 다른 Wasm 모듈을 타입 있는 인터페이스로 조립한다. Wasmtime·WasmEdge 같은 독립 런타임, Node.js(node:wasi), 엣지 플랫폼(Cloudflare Workers, Fastly)이 Wasm을 실행한다. 컨테이너보다 시작이 빠르고 가벼워 플러그인·서버리스 함수에 쓰인다.

쓸 곳과 안 쓸 곳

실제 사례로 Figma의 렌더링 엔진, Photoshop 웹판, Google Sheets의 계산 엔진(WasmGC) 등이 Wasm으로 돈다. 브라우저 안 AI에서 Wasm은 WebGPU가 없을 때의 안전한 CPU 경로다(클라이언트 사이드 웹 AI).

역사

Wasm 이전에는 Mozilla의 asm.js(엔진이 알아보는 엄격한 JS 부분집합, Emscripten의 출력)와 Chrome의 (P)NaCl(샌드박스 네이티브 코드)이 같은 문제를 풀려 했다. asm.js는 텍스트라 파싱이 무겁고, NaCl은 Chrome 전용이었다. 두 진영이 2015년 함께 설계한 결과가 Wasm이다.

정리

• Wasm은 컴파일 대상 바이트코드다. JS와 같은 VM·같은 보안 모델에서 돌며 JS를 보완한다.
• 빠른 이유는 파싱 대신 디코딩, 미리 최적화된 타입 있는 코드, 재최적화가 없는 실행이다. 대신 JS 경계를 넘는 비용이 있다.
• 개념은 Module(코드) · Memory(선형 바이트) · Table(참조) · Instance(실행 상태) 넷이고, instantiateStreaming으로 싣는다.
• MVP 이후 SIMD·참조 타입(2.0), GC·예외·꼬리 호출·64비트 메모리(3.0)가 들어와 GC 언어와 큰 앱까지 컴파일 대상이 됐다.
• 기존 네이티브 라이브러리와 무거운 계산에 쓰고, UI는 JS에 맡긴다.

관련 노트: JavaScript 엔진과 V8, SharedArrayBuffer와 Atomics, Web Worker, 클라이언트 사이드 웹 AI, 브라우저 안 빌드·프리뷰 환경