1장: WebAssembly의 등장과 핵심 개념

학습 목표

• WebAssembly가 등장한 배경과 해결하려는 문제를 이해합니다
• 바이너리 포맷과 텍스트 포맷(WAT)의 차이를 설명할 수 있습니다
• 선형 메모리 모델과 샌드박스 보안의 원리를 파악합니다
• 2026년 현재 Wasm 생태계의 전체 그림을 조망합니다

WebAssembly란 무엇인가

**WebAssembly(웹어셈블리)**는 웹 브라우저에서 네이티브에 가까운 성능으로 코드를 실행하기 위해 설계된 바이너리 명령어 포맷입니다. 2017년 주요 브라우저들이 WebAssembly를 지원하기 시작했을 때, 많은 개발자들은 이것을 단순히 "브라우저에서 C++를 돌리는 기술" 정도로 인식했습니다. 하지만 2026년 현재, WebAssembly는 브라우저를 넘어 서버, 엣지, IoT에 이르기까지 소프트웨어 실행의 새로운 표준으로 자리 잡고 있습니다.

WebAssembly의 핵심 설계 목표는 다음과 같습니다.

• 이식성(Portability): 한 번 컴파일하면 어디서든 실행됩니다
• 성능(Performance): 네이티브 코드 대비 10~20% 이내의 성능을 달성합니다
• 보안(Security): 샌드박스 환경에서 격리되어 실행됩니다
• 언어 독립성(Language Agnostic): Rust, C, C++, Go, Python 등 다양한 언어에서 컴파일 가능합니다

왜 WebAssembly가 필요했는가

JavaScript는 웹의 유일한 프로그래밍 언어로서 놀라운 진화를 거듭해 왔습니다. V8 엔진의 JIT 컴파일러 덕분에 성능도 크게 향상되었습니다. 그럼에도 불구하고 JavaScript만으로는 해결하기 어려운 영역이 존재합니다.

성능 예측 가능성의 문제가 대표적입니다. JavaScript의 JIT 컴파일은 최적화와 탈최적화를 반복하면서 실행 시간이 들쭉날쭉해질 수 있습니다. 게임 엔진이나 오디오 처리처럼 일정한 프레임 레이트가 필요한 애플리케이션에서는 이러한 성능 변동이 치명적입니다.

기존 코드 자산의 활용도 중요한 동기였습니다. 수십 년간 C/C++로 작성된 코덱, 암호화 라이브러리, 물리 엔진 등을 웹에서 직접 사용할 수 있다면 바퀴를 다시 발명할 필요가 없습니다.

바이너리 포맷과 텍스트 포맷

WebAssembly는 두 가지 표현 형식을 가지고 있습니다.

바이너리 포맷 (.wasm)

실제로 런타임이 실행하는 포맷입니다. 컴팩트한 바이너리 인코딩으로, 전송 크기가 작고 파싱이 빠릅니다. 일반적인 Wasm 모듈의 크기는 수십 KB에서 수 MB 수준입니다.

텍스트 포맷 (.wat)

**WAT(WebAssembly Text Format)**는 바이너리 포맷의 사람이 읽을 수 있는 표현입니다. S-expression 문법을 사용하며, 디버깅이나 학습 목적으로 활용됩니다.

(module
  (func $add (param $a i32) (param $b i32) (result i32)
    local.get $a
    local.get $b
    i32.add
  )
  (export "add" (func $add))
)

위 코드는 두 개의 32비트 정수를 받아 더한 결과를 반환하는 함수를 정의합니다. local.get으로 파라미터를 스택에 올리고, i32.add로 더한 뒤 결과가 스택 최상단에 남습니다.

선형 메모리 모델

WebAssembly의 메모리 모델은 놀라울 정도로 단순합니다. Wasm 모듈은 **선형 메모리(Linear Memory)**라고 불리는 하나의 연속된 바이트 배열에 접근합니다. 이 메모리는 64KB 단위의 **페이지(Page)**로 관리되며, memory.grow 명령으로 동적으로 확장할 수 있습니다.

// JavaScript에서 Wasm 메모리 생성
const memory = new WebAssembly.Memory({
  initial: 1,  // 1페이지 = 64KB
  maximum: 10  // 최대 10페이지 = 640KB
});
 
// ArrayBuffer를 통해 메모리 접근
const buffer = new Uint8Array(memory.buffer);
buffer[0] = 42;

이 단순한 메모리 모델은 중요한 보안상의 이점을 제공합니다. Wasm 모듈은 자신에게 할당된 선형 메모리 범위 밖의 메모리에 접근할 수 없습니다. 포인터 연산이 메모리 범위를 벗어나면 **트랩(Trap)**이 발생하여 실행이 중단됩니다.

샌드박스 보안 모델

WebAssembly의 보안은 "기본적으로 아무것도 할 수 없다"는 원칙에서 출발합니다.

Wasm 모듈은 다음과 같은 제약 속에서 실행됩니다.

1. 파일 시스템 접근 불가: 호스트가 명시적으로 허용하지 않는 한, 파일을 읽거나 쓸 수 없습니다
2. 네트워크 접근 불가: 소켓을 열거나 HTTP 요청을 보낼 수 없습니다
3. 시스템 호출 불가: OS 커널과 직접 상호작용할 수 없습니다
4. 다른 모듈의 메모리 접근 불가: 각 모듈은 자신의 선형 메모리만 볼 수 있습니다

이러한 격리는 **호스트 함수(Host Functions)**를 통해 선택적으로 완화됩니다. 호스트 환경(브라우저, 서버 런타임 등)이 특정 기능을 함수로 제공하면, Wasm 모듈은 그 함수를 임포트하여 사용할 수 있습니다.

2026년 Wasm 생태계 전체 지도

WebAssembly 생태계는 크게 네 가지 영역으로 나눌 수 있습니다.

브라우저 영역

Wasm의 원래 영역입니다. 게임(Unity, Unreal Engine), 미디어 처리(FFmpeg), CAD 도구(AutoCAD), AI 추론(ONNX Runtime) 등 고성능이 필요한 웹 애플리케이션에서 활발히 사용되고 있습니다.

서버사이드 영역

2026년 가장 빠르게 성장하는 영역입니다. Fermyon의 Spin 프레임워크가 대표적이며, Akamai가 Fermyon을 인수하면서 4,000개 이상의 글로벌 PoP에서 Wasm 워크로드를 실행할 수 있게 되었습니다. 콜드 스타트가 약 0.5ms에 불과하여 서버리스 컴퓨팅의 판도를 바꾸고 있습니다.

엣지 컴퓨팅 영역

Cloudflare Workers(330개 이상 로케이션), Fastly Compute, Akamai Edge 등이 Wasm을 핵심 실행 엔진으로 채택하고 있습니다. 사용자와 가장 가까운 곳에서 코드를 실행하여 지연 시간을 최소화합니다.

플러그인/확장 영역

Envoy Proxy, Zed 에디터, Figma 등이 Wasm을 플러그인 시스템으로 사용합니다. 안전하게 서드파티 코드를 실행할 수 있기 때문입니다.

Docker 공동 창업자 Solomon Hykes의 유명한 발언이 Wasm의 잠재력을 잘 요약합니다.

"2008년에 WASI가 존재했다면, 우리는 Docker를 만들 필요가 없었을 것입니다."

물론 이 발언은 다소 과장된 측면이 있지만, Wasm이 컨테이너의 핵심 가치인 이식성과 격리를 더 가벼운 방식으로 제공한다는 점은 부인하기 어렵습니다.

정리

이번 장에서는 WebAssembly의 핵심 개념을 살펴보았습니다.

• WebAssembly는 이식 가능하고 안전한 바이너리 명령어 포맷입니다
• 바이너리 포맷(.wasm)과 텍스트 포맷(.wat) 두 가지 표현이 존재합니다
• 선형 메모리 모델은 단순하면서도 안전한 메모리 관리를 제공합니다
• 샌드박스 보안 모델은 "기본 거부, 명시적 허용" 원칙을 따릅니다
• 2026년 현재, Wasm은 브라우저를 넘어 서버, 엣지, 플러그인 영역으로 확장되었습니다

다음 장 미리보기

2장에서는 WebAssembly의 실행 모델인 **스택 머신(Stack Machine)**의 동작 원리를 깊이 있게 분석합니다. Wasmtime, Wasmer, WasmEdge 등 주요 런타임의 아키텍처를 비교하고, AOT 컴파일과 JIT 컴파일의 차이를 알아봅니다.