웹어셈블리(Wasm)란 — 피그마 로딩을 3배 빠르게 한 기술이 서버에서 '남의 코드를 가두는 상자'가 된 이유
WebAssembly (Wasm) is a compact binary instruction format that runs at near-native speed inside a sandbox. It was announced in 2015 by browser makers, shipped in all major browsers in 2017 and became a W3C Recommendation in December 2019. Code written in C, C++, Rust, Go or C# can be compiled to Wasm; Figma said in 2017 that moving to Wasm cut its load time by 3x. Because a Wasm module can only touch its own linear memory and whatever the host explicitly grants through interfaces such as WASI, runtimes like Wasmtime are now used on servers, edge networks and plugin systems to run untrusted code safely. Its safety depends on the runtime compiler, which is why bugs like the October 2026 Wasmtime flaws matter.
웹어셈블리(Wasm)는 브라우저와 서버에서 거의 기계어 속도로 돌아가는 이진 실행 형식이다. C·C++·러스트·고·C# 같은 언어로 쓴 코드를 Wasm으로 바꿔 실행한다. 모듈은 자기 메모리 칸만 볼 수 있고 운영체제 기능은 실행기가 허락한 것만 쓸 수 있어서, 브라우저 밖 서버·엣지·플러그인에서 남이 만든 코드를 가둬 돌리는 상자로 쓰인다. 2019년 12월 W3C 표준이 됐다
3줄 요약
- 정의 — 언어 대신 '실행 형식', 여러 언어를 Wasm으로 바꿔 거의 기계어 속도로 실행
- 안전 — 모듈은 자기 메모리 칸만 보고, 파일·네트워크는 실행기가 허락한 것만
- 쓰임 — 브라우저 앱(피그마·포토샵 웹) → 서버·엣지·플러그인·AI 코드 샌드박스
핵심 질문
- 웹어셈블리란
- **여러 언어로 쓴 코드를 브라우저·서버에서 빠르고 안전하게 돌리는 이진 실행 형식이다.** | 항목 | 내용 | |---|---| | 영어 | WebAssembly, 줄여서 Wasm | | 발표 | 2015년(주요 브라우저 회사 공동) | | 브라우저 지원 | 2017년 주요 브라우저 모두 | | 표준 | 2019년 12월 W3C 권고안 | | 지원 언어 | C·C++·러스트·고·C# 등 |
- 웹어셈블리 자바스크립트 차이
- **자바스크립트는 사람이 쓰는 언어, Wasm은 컴파일러가 만드는 실행 형식이다.** | 항목 | 자바스크립트 | 웹어셈블리 | |---|---|---| | 형태 | 텍스트 소스 | 이진 코드 | | 작성 | 사람이 직접 | 다른 언어에서 컴파일 | | 속도 | 실행 중 최적화 | 미리 컴파일, 기계어에 가까움 | | 화면(DOM) 조작 | 직접 | 자바스크립트를 거쳐서 | | 관계 | 경쟁이 아니라 함께 쓴다 | 무거운 계산 담당 |
- Wasm 서버에서 쓰는 이유
- **작고 빨리 뜨면서 기본적으로 갇혀 있어서다.** | 항목 | 컨테이너 | Wasm 모듈 | |---|---|---| | 기본 권한 | 운영체제 기능 대부분 | 아무것도 없음(허락한 것만) | | 시작 시간 | 보통 수백 밀리초 이상 | 보통 밀리초 단위 | | 크기 | 수십~수백 MB | 보통 수 MB 이하 | | 격리 경계 | 운영체제 커널 | 실행기(런타임) |
웹어셈블리는 언어가 아니라 '실행 형식'이다. C·C++·러스트·고·C# 같은 언어로 쓴 코드를 컴파일러가 Wasm이라는 작은 이진 코드로 바꾸면, 브라우저나 서버의 실행기가 그것을 거의 기계어 속도로 돌린다. 핵심은 속도만이 아니다. Wasm 모듈은 자기 메모리 칸 밖을 볼 수 없고, 파일·네트워크 같은 운영체제 기능은 실행기가 허락한 것만 쓸 수 있다. 처음부터 갇힌 채로 태어난다.
이 성질 때문에 Wasm은 브라우저를 넘어 서버, 엣지 네트워크, 플러그인 시스템에서 남이 만든 코드를 안전하게 돌리는 상자로 쓰이게 됐다. 2026년 10월 Wasmtime 실행기에서 9.9점짜리 샌드박스 탈출 취약점이 나오자(「Wasmtime 취약점 패치 버전」) 업계가 긴장한 이유도 여기 있다. 상자가 많이 쓰일수록 상자의 결함은 커진다.
1. 어디서 왔나 — 브라우저 회사들이 함께 만든 표준
| 연도 | 사건 |
|---|---|
| 2013년 | 모질라의 asm.js — 자바스크립트의 빠른 부분만 골라 C++ 코드를 돌리는 실험 |
| 2015년 | 주요 브라우저 회사들이 W3C 커뮤니티 그룹에서 웹어셈블리 공동 발표 |
| 2017년 | 크롬·파이어폭스·사파리·엣지 모두 Wasm 지원 |
| 2017년 | 피그마, C++ 렌더링 엔진을 Wasm으로 옮겨 로딩 시간 3배 단축 발표 |
| 2019년 | 바이트코드 얼라이언스 결성, 브라우저 밖 실행용 시스템 인터페이스(WASI) 추진 |
| 2019년 12월 | W3C 정식 권고안(표준) |
| 2025년 9월 | Wasm 3.0 사양 완료 발표 — 가비지 컬렉션, 64비트 메모리, 예외 처리 등 |
브라우저에서는 오랫동안 자바스크립트만 돌릴 수 있었다. 무거운 그래픽 편집, 3D, 영상 처리는 느렸다. 브라우저 회사들이 경쟁 대신 표준 하나를 함께 만든 결과가 Wasm이다. 지금은 브라우저 네 곳이 모두 같은 형식을 돌린다.
2. 어떻게 작동하나
| 단계 | 내용 |
|---|---|
| ① 소스 코드 | C++·러스트·고 등으로 프로그램을 쓴다 |
| ② 컴파일 | 컴파일러가 .wasm 이진 파일을 만든다 |
| ③ 검증 | 실행기가 파일이 규칙을 지키는지 먼저 검사한다 |
| ④ 기계어 변환 | 실행기 안의 컴파일러(예: Wasmtime의 크레인리프트)가 CPU용 기계어로 바꾼다 |
| ⑤ 실행 | 모듈은 자기 '선형 메모리' 한 칸 안에서만 읽고 쓴다 |
| ⑥ 바깥 기능 | 파일·시계·네트워크는 실행기가 넘겨준 함수(WASI 등)로만 쓴다 |
안전은 두 겹이다. ③에서 규칙을 어기는 코드를 걸러 내고, ④에서 메모리 칸 밖으로 못 나가게 하는 기계어를 만든다. 2026년 10월 Wasmtime 취약점 두 건은 ④단계, 즉 번역 과정의 실수였다. 원본은 규칙을 지켰는데 기계어가 틀리게 나와서 벽에 구멍이 생겼다. 샌드박스 일반의 약점은 「샌드박스란」에서 정리했다.
3. 자바스크립트를 대체하나 — 아니다, 나눠 맡는다
| 항목 | 자바스크립트 | 웹어셈블리 |
|---|---|---|
| 형태 | 텍스트 소스 | 이진 코드 |
| 누가 쓰나 | 사람이 직접 | 다른 언어를 컴파일해서 |
| 잘하는 일 | 화면 조작, 이벤트 처리, 앱 흐름 | 이미지·영상·3D·암호·물리 계산 같은 무거운 계산 |
| 화면(DOM) 접근 | 직접 | 자바스크립트를 거쳐서 |
| 기존 코드 재사용 | 웹용으로 새로 작성 | 수십 년 된 C·C++ 라이브러리를 그대로 가져옴 |
웹 앱은 보통 화면과 흐름은 자바스크립트로, 무거운 엔진은 Wasm으로 짠다. 피그마의 디자인 렌더링, 웹판 포토샵, 웹판 오토캐드처럼 원래 데스크톱 프로그램이던 것이 브라우저에 들어온 배경에 Wasm이 있다.
4. 브라우저 밖으로 — 서버와 플러그인의 '가두는 상자'
| 쓰임 | 왜 Wasm인가 | 예 |
|---|---|---|
| 엣지·서버리스 함수 | 밀리초 단위로 뜨고, 고객 코드끼리 격리 | 패스틀리 컴퓨트(Wasmtime 기반), 클라우드플레어 워커스(Wasm 지원) |
| 프록시 확장 | 서버 프로그램에 남이 만든 필터를 안전하게 끼운다 | 엔보이 프록시의 Wasm 필터 |
| 앱 플러그인 | 사용자가 올린 확장 기능이 본체를 망가뜨리지 못하게 | 여러 편집기·SaaS의 플러그인 시스템 |
| AI가 만든 코드 실행 | 모델이 쓴 코드를 믿을 수 없을 때 가둬서 돌린다 | 에이전트 샌드박스 선택지로 거론 |
컨테이너와 비교하면 차이가 분명하다.
| 항목 | 컨테이너 | Wasm 모듈 |
|---|---|---|
| 기본 권한 | 운영체제 기능 대부분(제한을 걸어야 함) | 아무것도 없음(허락한 것만) |
| 시작 시간 | 보통 수백 밀리초 이상 | 보통 밀리초 단위 |
| 크기 | 수십~수백 MB | 보통 수 MB 이하 |
| 격리 경계 | 운영체제 커널 | Wasm 실행기 |
| 뚫리면 | 커널 취약점 | 실행기·컴파일러 취약점 |
마지막 줄이 핵심이다. 컨테이너의 벽은 운영체제 커널이고, Wasm의 벽은 실행기다. 그래서 Wasmtime 같은 실행기의 컴파일러 버그가 곧 '탈출 취약점'이 된다. 컨테이너에 가상머신을 한 겹 더 씌운 카타 컨테이너도 2026년 10월 오픈AI 레드팀 에이전트에게 뚫렸다(「오픈AI 레드팀 에이전트, CPU 캐시로 몰래 대화」). 어떤 상자든 벽을 만드는 소프트웨어가 곧 공격 대상이다.
5. 주요 실행기
| 실행기 | 만든 곳 | 주 용도 |
|---|---|---|
| V8·스파이더몽키·자바스크립트코어 | 구글·모질라·애플 | 각 브라우저 안 |
| Wasmtime | 바이트코드 얼라이언스 | 서버·임베디드, 표준 기능 선도 |
| Wasmer | Wasmer | 서버·데스크톱, 패키지 배포 |
| WasmEdge | CNCF 프로젝트 | 클라우드 네이티브·엣지 |
바이트코드 얼라이언스는 2019년 모질라·패스틀리·인텔·레드햇이 브라우저 밖 Wasm을 위해 세운 비영리 단체다. Wasmtime은 장기지원 계열(36.x 등)과 새로 나오는 계열에 함께 보안 패치를 낸다. 2026년 10월 패치가 36.0.19·48.0.7·49.0.4 세 갈래로 나온 이유다.
6. 자주 묻는 질문
Wasm은 무조건 안전한가? 설계상 갇혀 있지만, 실행기에 버그가 있으면 벽이 뚫린다. 실행기를 최신으로 유지하는 것이 전제다. 또 모듈에 파일·네트워크 권한을 넉넉히 주면 갇힌 의미가 줄어든다.
자바스크립트보다 항상 빠른가? 무거운 계산은 대체로 빠르지만, 화면 조작이 많은 일은 자바스크립트를 거쳐야 해서 이점이 작다.
배우려면 무엇부터? 새 언어를 배울 필요는 없다. 러스트나 C++, 고 같은 기존 언어의 컴파일 대상을 Wasm으로 바꾸는 것부터 시작한다.
악성코드에도 쓰이나? 브라우저에서 몰래 암호화폐를 채굴하는 스크립트에 Wasm이 쓰인 사례가 보고돼 왔다. 형식 자체가 선악을 가르지 않는다.
7. 남은 것과 확인되지 않은 것
- 성능 비교 수치: 컨테이너와 Wasm의 시작 시간·크기는 구성에 따라 크게 다르다. 표의 값은 일반적인 범위다.
- 새 사양 지원: Wasm 3.0 기능은 브라우저와 실행기마다 지원 시점이 다르다.