WASM이 브라우저 밖으로 나온 이유 — WASI와 서버 사이드 런타임

WebAssembly는 처음부터 브라우저용이 아니었다고 보는 게 맞다. 설계 자체가 더 범용적이었고, 브라우저 밖에서 쓰기 시작한 건 시간문제였다.

## WASM이 브라우저에서 잘 된 이유

브라우저의 샌드박스 모델은 WASM에 딱 맞는 환경이다. WASM 모듈은 메모리를 선형 버퍼(linear memory)로만 접근하고, 호스트(브라우저 JS 엔진)가 허용한 import만 쓸 수 있다. 실행 전에 바이트코드 검증을 통과해야 하고, 네이티브에 가까운 속도로 돌아간다.

문제는 이 "호스트가 제공하는 API에 의존하는 구조"가 브라우저 밖에서 동작하려면 새로운 표준이 필요하다는 거다. 파일 시스템, 네트워크, 시스템 콜 — 브라우저 Web API 없이 어떻게 접근하나.

## WASI: WebAssembly System Interface

2019년 Mozilla, Fastly, Intel, Red Hat이 공동으로 WASI를 발표했다. WebAssembly System Interface — WASM 모듈이 OS 수준 기능에 접근할 수 있는 표준 인터페이스다.

핵심 개념은 **capability-based security**다. WASM 모듈은 명시적으로 허용받은 파일 경로, 소켓, 환경 변수에만 접근할 수 있다. Docker를 처음 만든 Solomon Hykes가 2019년 트위터에 쓴 글이 유명하다:

> "If WASM+WASI existed in 2008, we wouldn't have needed to create Docker."

한 문장으로 잘 정리된다. 컨테이너의 역할 중 "격리 + 이식성" 부분을 WASM이 더 가볍게 처리할 수 있다.

## 주요 런타임

브라우저 밖에서 WASM을 실행하는 주요 런타임들:

**Wasmtime** (Bytecode Alliance, Rust 구현)
공식 WASI 레퍼런스 구현이다. CLI, 라이브러리 임베딩 모두 지원.

```bash
wasmtime hello.wasm
```

**Wasmer**
크로스 컴파일, JIT/AOT 선택 가능. 여러 언어 바인딩 제공.

**WasmEdge**
클라우드 네이티브 포커스. 클라우드플레어 Workers나 Fastly Compute에서 쓰이는 계열.

## Node.js에서 WASM 사용

Node.js에는 V8 기반 WASM 지원이 내장돼 있다. WASI도 실험적으로 지원한다.

```javascript
import { readFile } from 'node:fs/promises';
import { WASI } from 'node:wasi';
import { argv, env } from 'node:process';

const wasi = new WASI({
  version: 'preview1',
  args: argv,
  env,
  preopens: {
    '/sandbox': '/some/real/path/that/wasm/can/access'
  }
});

const wasm = await WebAssembly.compile(
  await readFile('hello.wasm')
);

const instance = await WebAssembly.instantiate(wasm, wasi.getImportObject());
wasi.start(instance);
```

`preopens`가 capability-based security의 핵심이다. WASM 모듈은 `/sandbox` 경로만 볼 수 있고, 실제 경로 매핑은 호스트가 결정한다.

## 엣지 컴퓨팅에서 왜 주목받는가

Cloudflare Workers, Fastly Compute, Vercel Edge Functions — 이런 엣지 런타임들이 WASM을 좋아하는 이유가 있다.

컨테이너는 부팅 시간이 있다. 수백 ms ~ 수초. 엣지 환경에서 이건 쓸 수 없다. WASM 모듈은 콜드 스타트가 **수 밀리초** 수준이다. 모듈 인스턴스화 자체가 빠르기 때문이다.

거기다 언어에 독립적이다. Rust, C, C++, Go, Python, Ruby — WASM으로 컴파일되는 언어면 런타임 언어에 상관없이 동일한 환경에서 실행된다. Cloudflare Workers에서 Rust로 짠 WASM 모듈이 돌아가는 게 가능한 이유다.

## 아직 미성숙한 부분

WASI preview1이 안정적이지만 preview2(component model 기반)는 아직 진화 중이다. 특히:

- **스레딩**: WASM threads 표준이 있지만 WASI 레이어 지원은 불완전
- **네트워킹**: wasi-sockets가 일부 구현돼 있지만 제한적
- **비동기**: WASM은 본질적으로 동기 실행 모델 — async/await 패턴을 위한 별도 바인딩 필요

Docker + WASM 통합도 실험적 단계다. `docker run --runtime io.containerd.wasmedge.v1 ...` 식으로 쓸 수 있지만 프로덕션 쓰기엔 아직 이르다.

## 언제 쓸 만한가

지금 당장 쓸 만한 케이스:

1. **Cloudflare Workers에서 Rust 코드 실행** — Workers는 WASM을 기본 지원. Rust → WASM 빌드 파이프라인이 잘 정리돼 있다.
2. **플러그인 시스템** — 사용자가 임의 코드를 실행해야 하는데 샌드박스가 필요한 경우. Extism 같은 라이브러리가 이 패턴을 추상화한다.
3. **C/C++ 라이브러리를 Node.js/Python에서 사용** — 크로스 컴파일로 OS 의존성 제거.

컨테이너를 전부 WASM으로 대체하는 건 아직 아니다. 하지만 특정 유즈케이스에서 WASM이 더 나은 선택지가 되는 시점은 이미 지났다.

WASM이 브라우저 밖으로 나온 이유 — WASI와 서버 사이드 런타임

// COMMENTS

ON THIS PAGE