웹어셈블리에는 무슨 일이 있었나

• WebAssembly(Wasm) 은 여전히 다양한 실제 제품에서 핵심 기술로 사용되고 있으며, 게임 엔진·디자인 툴·웹 컨테이너 등에서 중요한 역할을 수행
• 언어 자체는 하드웨어에 효율적으로 매핑되는 구조를 가지며, 안전성과 이식성을 중심으로 설계되어 있음
• 보안 모델은 ‘기본 거부(deny-by-default)’ 구조로, 프로세스 수준의 격리와 빠른 실행 속도를 가능하게 함
• 플러그인 생태계와 크로스언어 지원을 통해 다양한 환경에서 활용되지만, 브라우저 전체를 대체하는 수준의 채택은 아직 없음
• 현재 WebAssembly는 라이브러리와 런타임 수준에서 깊이 통합되어 있으며, 표준화와 기능 확장이 빠르게 진행 중인 기술임

실제 활용 사례

• WebAssembly는 Godot, Figma, Stackblitz, Squoosh.app, Zellij, Ruffle 등에서 핵심 기능을 담당
  • Godot은 웹용 게임 빌드에, Figma는 C++ 코드를 브라우저에서 실행 가능한 형태로 변환하는 데 사용
  • Stackblitz는 웹 컨테이너, Ruffle은 Flash 에뮬레이터로 Wasm을 활용
• 그러나 웹 전체를 Wasm 기반으로 구축한 대규모 사이트는 드뭄, 대부분은 특정 기능 단위에서 사용

WebAssembly의 정의와 속도

• WebAssembly는 언어(language) 로, 자체적인 속도 개념이 아닌 엔진 성능에 의존
• JavaScript처럼 런타임 엔진(V8, SpiderMonkey 등) 이 실행 속도를 결정
• WebAssembly는 현대 하드웨어에 효율적으로 매핑되는 구조를 가지며, 컴파일 또는 인터프리트 방식 모두 가능

효율적 매핑 구조

• Wasm은 어셈블리 언어에 가까운 바이트코드로, 대부분의 하드웨어에 손실 없이 컴파일 가능
• WAT(WebAssembly Text) 는 Wasm의 텍스트 표현으로, 거의 1:1 변환 가능
• JVM 바이트코드와 유사하지만, API가 작고 안전성 보장이 강함
  • 메모리 접근은 명시적이며, 호스트 환경에서 허용된 자원만 사용 가능

컴파일 타깃으로서의 Wasm

• Rust, C, Zig, Go, Kotlin, Java, C# 등 다양한 언어가 Wasm으로 컴파일 가능
• Python, PHP, Ruby 같은 인터프리터 언어도 Wasm 빌드로 실행 가능
• 브라우저는 기본적으로 Wasm 엔진을 포함하며, Wasmtime, WasmEdge, Wasmer 등 독립 런타임도 존재
• 단일 Wasm 아티팩트는 하드웨어 비종속적 실행이 가능

보안 구조와 활용

• WebAssembly는 ‘deny-by-default’ 보안 모델을 채택, 외부 접근은 명시적 import만 허용
• 은닉된 제어 흐름 스택, 선형 메모리, 제한된 명령 집합으로 강력한 격리 보장
• Cloudflare는 V8 isolate를 이용해 Wasm 기반 코드 실행을 격리하며, Fermyon은 서브밀리초 수준의 기동 속도를 제공
• Ruffle은 Flash 콘텐츠를 안전하게 복원, Pyodide는 Python을 Wasm으로 실행, Figma는 Wasm 기반 QuickJS로 플러그인 실행

이식성과 임베딩

• Wasm 런타임은 가볍고, Zellij, Envoy, Lapce 등은 플러그인 시스템에 Wasm을 채택
• JavaScript 엔진이 있는 환경에서도 이미지 처리, OCR, 물리 엔진, 렌더링, 미디어 툴킷, 데이터베이스, 파서 등 다양한 Wasm 라이브러리 사용 가능
• 대부분의 경우 사용자는 Wasm 사용 여부를 인식하지 못함, 라이브러리 내부에서 투명하게 동작

속도와 크기 재검토

• 브라우저는 JS와 동일한 파이프라인으로 Wasm을 실행, 엔진 구조상 성능 한계 존재
• 언어의 타입 시스템과 컴파일러 최적화 수준에 따라 효율성 차이 발생
• 호스트-프로그램 경계 비용과 바이너리 부피 증가가 단점으로 지적
  • WASI 표준이 이를 완화하려 하지만, 문자열 타입 표준화는 아직 미완성
• Zig이 가장 작은 Wasm 바이너리를 생성
• 네이티브 환경에서는 스레딩·IO·메모리 사용량으로 인해 성능 저하 가능

언어 및 표준 개발 동향

• Wasm 표준화는 W3C 워킹그룹과 Bytecode Alliance가 병행 진행
  • 후자는 WIT, Component Model 등 도구 중심 개발을 주도
• 새 기능 제안이 빠르게 채택되고 있으며, 일부에서는 속도와 방향성에 대한 논쟁 존재
• Wasm은 JavaScript 대체보다는 내부 통합 기술로 확산
  • Blazor, Leptos 같은 프레임워크는 JS를 직접 다루지 않고 Wasm을 활용
• 현재 Wasm은 라이브러리 제작자 중심으로 채택, 일반 개발자는 내부 동작을 인식하지 않아도 사용 가능
• 교육 자료의 난해함이 학습 장벽으로 지적되며, ‘watlings’ 같은 학습 프로젝트가 소개됨