DevOwen
웹 어셈블리(Wasm) 3.0
Wasm 3.0 은 *마이너 패치* 가 아니라 고수준 언어를 진짜로 컴파일할 수 있게 만드는 도약 — GC/예외/테일콜/64비트 주소가 한꺼번에 들어왔다.
핵심 요약
3.0 의 핵심 추가:
| 기능 | 의미 | 영향 |
|---|---|---|
| 64비트 주소 공간(memory64) | i64 메모리, 4GB→이론상 16EB | 큰 데이터셋, 비-웹 워크로드 |
| 다중 메모리 | 한 모듈 안 여러 메모리 | wasm-merge 정적 링킹, 격리 |
| 가비지 컬렉션 | struct/array, tagged int, runtime 관리 | Java/Kotlin/Dart/OCaml/Scala 일급 |
| 타입 레퍼런스 | 정확한 힙 형태, subtype/recursive | 안전한 간접 호출, 런타임 검사 감소 |
| 테일 콜 | 함수 종료 + 호출 통합 | 함수형 언어 효율 |
| 예외 처리 | 네이티브 exception throw/catch | JS 우회 없이 효율적 예외 |
| relaxed SIMD | 플랫폼별 약간 다른 의미론 허용 | 추가 SIMD 성능 |
| 결정론 프로파일 | NaN/relaxed 의 결정적 기본 | 블록체인/재현 가능 시스템 |
| 어노테이션 구문 | 텍스트 포맷의 메타데이터 | 도구 친화 |
| JS 문자열 빌트인 | externref 문자열 직접 조작 | JS↔Wasm 통신 효율 |
주요 브라우저는 이미 대부분 지원, Wasmtime 같은 독립 엔진도 거의 완료.
Wasm 1.x/2.0 은 'C/Rust 같은 수동 메모리 언어' 를 위한 무대였다. 3.0 은 GC/예외/테일콜/64비트 를 통해 Java, Kotlin, OCaml, Dart, Scheme 같은 자동 메모리 + 고수준 제어 흐름 언어 를 자연스럽게 컴파일할 수 있는 무대로 바뀐다. 즉 'Wasm 이 빨라졌다' 가 아니라 '어떤 언어가 1급으로 들어올 수 있는가' 의 경계가 바뀐 것이다.
프런트엔드 면접에서 Wasm 은 "왜 도입하는가" 같은 표면적 질문이 많지만, 3.0 은 답을 한 단계 깊게 만든다.
- 기존: "C++/Rust 라이브러리를 브라우저에서 빠르게"
- 3.0 이후: "Java/Kotlin/Dart 도 일급 시민, GC 가 호스트에 의존하지 않음"
Figma 가 C++ 로 빠른 것을 예외 가 아닌 흔한 패턴 으로 만든다. 또한 결정론 프로파일 같은 추가 명세는 블록체인/재현 빌드 같은 비-웹 사용처를 늘린다 — 면접에서 "비웹 Wasm" 토픽이 등장하기 시작한 이유다.
학습 포인트
면접 답변으로 연결할 학습 포인트입니다.
GC 는 "엔진이 바뀐" 게 아니라 "새 저장소가 추가된" 것
Wasm GC 는 기존 선형 메모리 를 대체하지 않는다. 별개의 런타임 관리 저장소 가 추가된 것이다.
[ Linear Memory ] ← C/Rust 등 수동 관리, malloc/free
[ Wasm GC Heap ] ← struct / array / tagged int
← 런타임이 할당/회수
중요한 건 얼마나 저수준 이냐다 — Wasm GC 는 메서드 테이블 같은 "객체 시스템" 을 제공하지 않는다. 그건 컴파일러(Java/Kotlin) 의 책임으로 남긴다. 즉 메모리 관리만 표준화, 그 위 ABI 는 언어가 정의. 이래야 다양한 언어가 한 무대에 올 수 있다.
"이제 모든 언어가 같은 GC 를 공유" 라는 인식. 실제로는 공통 빌딩 블록 만 표준화돼 있어 언어 간 객체 호환은 여전히 별개 문제다.
예외/테일콜 — 컴파일러가 *우회 코드* 를 안 만들어도 되는 자유
이전엔 다음과 같은 우회가 흔했다.
- 예외 → JS try/catch 로 이스케이프 (포터블 X, 느림)
- 테일콜 → 트램펄린(트램폴린 함수)으로 흉내 (스택 더 차거나 느림)
3.0 은 둘 다 네이티브화한다.
예외 throw + catch_all/catch_tag → 패턴 매칭 분기
테일콜 return_call / return_call_indirect → 스택 안 늘어남
결과:
- Java/Kotlin 의 예외가 효율적
- OCaml/Scheme 같은 함수형 언어의 무한 재귀가 안전
- 컴파일러가 호스트 의존성 을 줄여 비웹 환경에서도 동일하게 작동
"우리 프로젝트는 자바스크립트라 상관없다" 는 인식. 실제로는 Wasm 으로 컴파일되는 라이브러리 가 사용하는 패턴이라 간접 영향 이 크다 (예: Dart Web 의 Flutter).
결정론 프로파일 — 비웹 Wasm 의 사실상 새 시장
Wasm 표준은 NaN/부동 소수/relaxed SIMD 같은 비결정적 영역에 결정론적 기본 동작 을 명시했다. 이를 채택하는 Deterministic Profile 안에서는 Wasm 이 완전히 결정적·재현 가능·이식 가능 하다.
실용 의미:
- 블록체인 스마트 컨트랙트: 노드 간 동일 결과 보장
- 재현 가능 빌드/CI: 부동 소수 결과가 OS/CPU 에 따라 달라지는 사고 방지
- 검증/감사 시스템: 같은 입력에 같은 출력
웹 외부에서 Wasm 채택을 가속하는 조용한 변화다.
"Wasm = 브라우저" 라는 인식. 실제로는 Wasmtime, Wasmer, WASI 등 런타임 분야 가 빠르게 자라고 있고 결정론 프로파일이 그 성장의 발판이다.
읽는 순서
- 1이론
WebAssembly 3.0 발표문과 GC/Exception Handling/Tail Calls RFC 를 훑고, 각 기능이 어떤 언어를 일급으로 만드는가 를 한 줄씩 적어 표로 정리.
- 2구현
Dart/Flutter Web 또는 Kotlin/Wasm 데모 하나를 빌드해 번들 사이즈/콜드 시작 을 측정. Wasm 3.0 GC 활성/비활성 차이를 비교(가능한 빌드 옵션 한정).
- 3실무
현재 프로젝트의 Wasm 의존 라이브러리를 모두 나열하고, 3.0 기능 사용 여부와 사용자 영향(메모리/지연)을 매핑. 도입 후보 한 곳을 정해 PoC 계획.
- 4설명
팀에 10분 발표 — 'Wasm 3.0 이 우리 사용자에게 간접 으로 어떤 변화가 있는가'. 빌드 사이즈 / 메모리 한계 / 예외 안정성 세 축으로.
면접 연결 질문
[감점 답변] '기존을 대체한다'. [좋은 답변] 공존. 선형 메모리는 수동 관리 (C/Rust), GC heap 은 런타임 관리 (Java/Kotlin/Dart)로 별개 영역이다. 컴파일러는 둘을 동시에 활용한다 — 예: 파서는 GC 객체로, 큰 버퍼는 선형 메모리로.
[감점 답변] '나하곤 상관없다'. [좋은 답변] 두 경로. (1) Flutter Web/Dart 같이 Wasm 로 컴파일되는 프레임워크가 호스트 우회 비용 을 잃어 성능이 향상된다. (2) 함수형 라이브러리(이미지 처리/엔진) 가 무한 재귀를 안전하게 표현 가능 → JS 측에서 호출하는 라이브러리의 안정성/속도 동시 개선.
[감점 답변] 'CI 가 안정됨'. [좋은 답변] 세 가지. (1) 블록체인 컨트랙트 — 노드 간 동일 결과. (2) 재현 가능 빌드/캐시 — 부동 소수 결과 차이로 인한 캐시 미스 제거. (3) 공증/감사 — 입력→출력 매핑이 검증 가능. 이 분야들은 결정성 자체 가 핵심 가치라 이전 Wasm 으론 진입이 어려웠다.
자기 점검
"FE 와 무관" 이라는 인식. 실제로는 번들 크기/가용 메모리/예외 처리 등으로 사용자 경험이 직접 바뀐다.
"GC 만 있으면 충분" — 정확한 타입 정보가 없으면 매 호출마다 런타임 타입 검사 가 필요해 GC 의 이득을 깎는다.
결정성이 항상 더 좋다는 가정. 결정성을 강제하면 상한 성능 을 내기 어렵기 때문에 프로파일 단위로 옵트인 한다.