1. 글의 핵심 요약
-
Wasm(WebAssembly)은 웹 기술도, 어셈블리 언어도 아니다.
-
실제 정체는 바이트코드(bytecode)이며, JVM·.NET과 비슷한 가상머신(VM)을 위한 실행 포맷.
-
Wasm 런타임은 브라우저뿐 아니라 서버·임베디드·폰트 엔진(Harfbuzz)에서도 실행 가능.
-
Wasm의 핵심 특징은:
- 샌드박싱 보안 모델
- 결정적 실행(deterministic execution)
- 정적 타입 검증(Type validation)
- 구조적 제어 흐름(Structured control flow)
-
Wasm은 원래 “웹을 위한 저수준 런타임”이라는 명분으로 시작했으나, 실제 목표는 범용 VM용 포터블 바이트코드였다.
-
LLVM 기반 언어(C/Rust/Swift 등)를 Wasm으로 옮길 수 있지만, 장기적으로는 Wasm을 직접 타깃으로 하는 새 언어가 더 큰 이점을 얻는다.
-
GC 확장·예외처리·고차함수·continuations 같은 고수준 기능을 포함하며 컴파일러 백엔드로 사용하기 좋은 구조를 가진다.
-
Wasm 생태계는 wasmtime, bytecode alliance, binaryen, wasm-opt, WABT 등으로 매우 빠르게 확장 중.
2. Wasm에 대한 두 가지 큰 오해
오해 1) Wasm은 웹 기술이다
- 실제로 Wasm은 DOM 접근 기능이 아예 없다.
- 브라우저는 Wasm을 “실행 가능한 바이트코드”로만 읽고, DOM·네트워크 등은 호스트가 명시적으로 제공해야만 접근 가능.
- 웹은 Wasm이 실행되는 여러 장소 중 하나일 뿐.
→ Wasm은 “웹 기술”이 아니라 웹에서도 동작하는 범용 VM 포맷.
오해 2) Wasm은 어셈블리 언어다
- Wasm은 x86-64/ARM 같은 실제 CPU 명령집합이 아니다.
- 명령어 집합과 실행 모델은 JVM·.NET 바이트코드와 유사.
- “가상머신이 실행하는 포터블 코드”라는 점이 핵심.
→ Wasm은 “Assembly”라는 이름을 가졌지만, 진정한 의미의 CPU용 어셈블리가 아니라 고수준 바이트코드.
3. Wasm의 진짜 정체: VM용 바이트코드
Wasm은 독립 명세(스펙)로 규정되고, VM은 그 스펙을 완전히 준수해야 한다.
Wasm 런타임이 제공하는 것
- 가비지 컬렉션(표준화 진행 중)
- 예외 처리
- 고차 함수
- 구조적 제어 흐름
- sandbox 보안 모델
- 결정적 실행(determinism)
Wasm 런타임이 제공하지 않는 것
- 네트워크
- 파일 시스템
- DOM
- 운영체제 기능
이 모든 기능은 호스트가 import로 의도적으로 노출해야 한다.
그래서 Wasm은 폰트 엔진(Harfbuzz)·임베디드·서버에서도 “안전하게” 실행된다.
4. Wasm이 보안에 강한 이유: 샌드박스 모델
Wasm 스펙의 핵심 목적 중 하나가 호스트와 완벽히 분리된 실행 모델.
- 호스트가 허용하지 않는 기능은 Wasm 실행단에서 절대 호출 불가.
- Wasm 모듈은 “기본적으로 아무 것도 할 수 없음.”
- 이 모델 덕분에 Harfbuzz는 Wasm을 폰트 내부에 포함시켜도 “안전”하다고 판단.
이 특성은:
- 다중 테넌트 환경
- 클라우드 샌드박스
- 플러그인 시스템
- 사용자가 업로드한 실행 코드
같은 영역에서 매우 강력한 이점을 제공한다.
5. 이름은 WebAssembly지만, ‘웹 전용’이 아니었던 이유
5-1. 2015년 상황: JS를 대신할 브라우저 타깃 필요
2010년대 개발자들의 요구:
- “JS는 쓰고 싶지 않은데, 웹에서 돌아가야 한다.”
문제:
-
새 언어 추가? → 실패
-
JS transpile? → 기존 코드 재사용 불가
-
결국 컴파일 타깃으로 JS subset
asm.js등장- JS를 속여서 integer 최적화를 유도
- 기술적으로 기묘한 해킹
5-2. 해결책 → JS를 생략하고 VM에 직접 접근
- Wasm은 브라우저가 가진 VM에 바로 접근할 수 있는 새로운 통일된 인터페이스를 제공.
- 그래서 WebAssembly라는 이름이 나왔다.
5-3. 그러나 개발자들은 처음부터 범용 VM을 목표로 했다
창시자인 Andreas Rossberg의 발언:
- “WebAssembly라는 이름은 프로젝트 승인을 받기 위한 명분이었다.”
- 목표는 일반 목적 바이트코드였고, 웹은 그중 하나의 런타임일 뿐.
즉, 이름은 “정치적 이유”, 구조는 “범용 컴퓨팅 지향”.
6. LLVM → Wasm의 간극: Relooper 문제
Rust/C/Swift는 LLVM을 통해 Wasm을 타깃팅한다.
문제:
- LLVM IR = 비구조적 제어 흐름(Basic Blocks)
- Wasm = 구조적 제어 흐름(while/if/loop)
- 변환 필요 → Relooper 알고리즘 사용
- 구조를 깨고 복원하는 과정에서 오버헤드와 복잡성 증가
비효율적이나 “기존 언어를 옮기기 위한 필요악”.
반대로 새 언어는 Wasm을 직접 타깃팅 가능
- 고수준 기능을 그대로 Wasm으로 매핑
- 백엔드 복잡성을 크게 줄일 수 있음
- GC 표준화가 끝나면 더 많은 언어가 Wasm-first 구조를 채택할 가능성이 커짐
→ Wasm은 “새 언어 설계자”에게 가장 매력적인 타깃이 된다.
7. Wasm의 실전적 강점
7-1. 완전한 공식 명세 → 예측 가능성
- 스펙이 매우 명확하게 정의됨
- 비결정적 영역까지 문서화되어 있음
- 컴파일러 작성 시 “왜 출력이 달라졌는지” 디버깅이 쉬움
7-2. 결정적 실행(deterministic execution)
- Hash map seed 변화처럼 “예측 불가능한 결과”가 Wasm 단계에서는 발생하지 않음
- 멀티 테넌트·분산 실행 환경에 특히 유리
7-3. 정적 타입 검증
- 함수·모듈·명령어 모두 타입을 가짐
- 실행 전 타입 검증 → 런타임 오류 대폭 감소
7-4. VM 독립성
- 서버, 엣지, 임베디드, 브라우저 어디서나 동일하게 실행
8. Wasm 생태계: 지금 바로 쓸 수 있는 도구들
Rust 생태계
- wasmtime: 대표적 Wasm 런타임
- bytecode alliance: Wasm 도구 모음
- wasm-encoder: 타입 안전한 Wasm 바이너리 생성 API
기타 언어·도구
-
binaryen: 강력한 Wasm 트랜스폼/최적화 라이브러리
-
wasm-opt: Wasm 최적화 CLI
-
WABT (WebAssembly Binary Toolkit)
wasm2wat,wat2wasm제공- 텍스트 <-> 바이너리 변환에 필수
Wasm은 이미 “웹 기술”을 넘어서 범용 컴퓨팅 플랫폼으로 자리잡는 중.
9. 결론: 이름은 WebAssembly지만, 본질은 범용 바이트코드
- Wasm은 웹을 위한 기술이 아니다.
- Wasm은 어셈블리도 아니다.
- Wasm은 VM을 위한 안전한, 결정적, 고수준 바이트코드다.
웹은 Wasm이 활동하는 여러 무대 중 하나일 뿐이며, Wasm의 진짜 가치는:
- 범용성
- 보안 모델
- 결정적 실행
- 고수준 기능 지원
- 컴파일 타깃으로서의 매력
에 있다.
이제 Wasm의 이름이 주는 착각에서 벗어나,
Wasm을 새로운 범용 실행 포맷으로 바라볼 때다.
