> "WebAssembly의 핵심 가치는 더 이상 '브라우저 안에서 빠른 코드'가 아니라 '어디서나 같은 바이너리로 실행되는 안전한 격리'다. 2026년의 Wasm은 컨테이너와 자바스크립트 사이의 빈자리를 채운다." — Bytecode Alliance, State of Wasm 2025

WebAssembly(이하 Wasm)는 2017년 브라우저 4사(Chrome·Firefox·Safari·Edge)가 MVP를 발표한 이후 9년 만에 완전히 다른 영역에 도착했습니다. 2024년 1월 WASI 0.2(Preview 2)가 GA되면서 "표준 시스템 인터페이스" 문제가 해결됐고, Component Model Preview 2가 "언어 간 호출" 문제를 풀었습니다. 그 결과 2026년의 Wasm은 브라우저보다 **서버·엣지·플러그인·임베디드** 영역에서 더 빠르게 성장하고 있습니다.

2026년 5월 현재, Wasm 생태계는 단일 승자 없이 **레퍼런스 런타임(Wasmtime), CNCF 엣지(WasmEdge), 멀티 컴파일러(Wasmer), 임베디드(WAMR), 순수 Go(wazero), 브라우저(V8·SpiderMonkey·JSC)** 여섯 진영으로 분화되었습니다. 이 글에서는 런타임·WASI·Component Model·PaaS·언어 지원·AI/ML·플러그인·실전 도입까지 한 번에 정리합니다.

1. 2026년 Wasm 지도 — 브라우저를 넘어선 다섯 영역

2026년의 WebAssembly는 다섯 가지 큰 영역으로 나뉩니다.

| 영역 | 대표 프로젝트 | 핵심 가치 |

|---|---|---|

| 브라우저 | V8 Liftoff+TurboFan, SpiderMonkey+Cranelift, JSC | DOM 통합, JSPI, GC |

| 서버 런타임 | Wasmtime, WasmEdge, Wasmer, WAMR, wazero | WASI, sandboxing |

| 엣지/서버리스 | Fermyon Spin, Cloudflare Workers, Fastly Compute, Wasmer Edge | 콜드 스타트 마이크로초 |

| 플러그인 | Extism, Hippo, Envoy proxy-wasm | 다언어 확장 시스템 |

| AI/ML | wasi-nn, ONNX Runtime Web, WebLLM, Burn, Candle | 추론 격리, 브라우저 LLM |

핵심 통찰은 "**Wasm의 진짜 가치는 컴파일된 .wasm 모듈이 아니라 Component Model로 정의된 인터페이스**" 라는 것입니다. WASI 0.2가 GA되면서 wit 파일로 정의된 인터페이스 하나로 Rust·Go·Python·Ruby가 서로 호출할 수 있게 됐고, 이것이 Wasm을 "차세대 컨테이너"보다는 "차세대 ABI"로 만들고 있습니다.

2. WASI 0.2 GA — 2024년 1월의 분기점

WASI(WebAssembly System Interface)는 Wasm 모듈이 호스트의 파일·네트워크·시계 같은 시스템 자원에 접근하기 위한 표준 인터페이스입니다. 2019년 Preview 1이 발표된 이후 5년간 표류했지만, 2024년 1월 25일 **WASI 0.2(Preview 2)가 GA** 되면서 분기점이 왔습니다.

WASI 0.2의 핵심 변화는 세 가지입니다. 첫째, **Component Model을 기반으로 한 인터페이스 분리** — `wasi:cli`, `wasi:http`, `wasi:filesystem`, `wasi:sockets`, `wasi:keyvalue`, `wasi:logging` 같은 월드(world)로 나뉘어 호스트가 필요한 권한만 노출할 수 있습니다. 둘째, **POSIX 호환을 버린 능력 기반(capability-based) 모델** — 파일 디스크립터 대신 자원 핸들을 명시적으로 주고받습니다. 셋째, **언어 중립 인터페이스 정의** — wit 파일이 표준이 되어 Rust·Go·Python 바인딩을 동시에 생성합니다.

wasm32-wasip2 타깃으로 빌드 (Rust 1.78+)

rustup target add wasm32-wasip2

cargo build --target wasm32-wasip2 --release

결과 모듈 실행 (Wasmtime 21+)

wasmtime run --wasi http target/wasm32-wasip2/release/myapp.wasm

wit 파일로 인터페이스 정의

cat > world.wit <<'WIT'

package example:greet@0.1.0;

interface greeter {

greet: func(name: string) -> string;

}

world greet-world {

export greeter;

}

WIT

WASI 0.3 로드맵은 비동기(async)와 스트림 지원이 핵심입니다. 2026년 5월 기준 0.3은 Pre-release이며 2026년 후반 GA가 목표입니다.

3. Component Model — Wasm을 ABI로 만든 결정타

Component Model은 "모듈 단위가 아니라 컴포넌트 단위로 합성한다"는 개념입니다. 기존 Wasm 모듈은 i32·i64·f32·f64·v128만 주고받을 수 있었지만, 컴포넌트는 record·variant·list·option·result·string 같은 풍부한 타입을 wit 인터페이스로 정의해 언어 간에 직접 주고받습니다.

// wit 인터페이스 예시

package shop:checkout@0.2.0;

record cart-item {

sku: string,

quantity: u32,

unit-price-cents: u64,

}

variant payment-method {

card(string),

bank-transfer,

crypto(string),

}

interface checkout {

use cart-item;

use payment-method;

finalize: func(items: list<cart-item>, method: payment-method)

-> result<string, string>;

}

world checkout-service {

export checkout;

}

이 wit 파일 하나로 **wit-bindgen**이 Rust·Go·Python·JS 바인딩을 자동 생성합니다. 호출자는 어떤 언어로 작성된 컴포넌트인지 알 필요가 없고, 호스트는 컴포넌트의 import/export만 만족시키면 실행시킬 수 있습니다. 2026년 5월 기준 Component Model Preview 2가 안정 단계이고 Preview 3 로드맵은 async와 stream의 정식 지원을 포함합니다.

4. Wasmtime — Bytecode Alliance의 레퍼런스 런타임

Wasmtime은 Bytecode Alliance가 만든 Wasm·WASI 레퍼런스 런타임으로, Rust로 작성됐고 Cranelift 컴파일러를 사용합니다. 2026년 5월 기준 Wasmtime 25(LTS)가 안정 버전이며 SemVer 정책을 따릅니다.

Wasmtime의 강점은 세 가지입니다. 첫째, **Component Model 일급 지원** — 2024년 0.2 GA에 맞춰 가장 먼저 컴포넌트 실행을 안정화했습니다. 둘째, **결정론적 실행과 fuel 메커니즘** — `Config::consume_fuel(true)`로 명령어 단위 한도를 걸 수 있고, 이는 멀티 테넌트 환경에서 핵심입니다. 셋째, **풀링 알로케이터** — 컴포넌트 인스턴스화 비용이 100마이크로초 수준이라 서버리스 콜드 스타트에 최적입니다.

// Wasmtime 25 — 컴포넌트 임베디드 예시

use wasmtime::{Engine, Config, Store};

use wasmtime::component::{Component, Linker};

let mut config = Config::new();

config.wasm_component_model(true);

config.consume_fuel(true);

let engine = Engine::new(&config)?;

let component = Component::from_file(&engine, "checkout.wasm")?;

let mut linker = Linker::new(&engine);

wasmtime_wasi::add_to_linker_sync(&mut linker)?;

let mut store = Store::new(&engine, MyState::default());

store.set_fuel(10_000_000)?;

let instance = linker.instantiate(&mut store, &component)?;

let finalize = instance.get_typed_func::<(Vec<CartItem>, PaymentMethod), Result<String, String>>(

&mut store, "finalize"

)?;

let result = finalize.call(&mut store, (items, method))?;

Wasmtime은 Fermyon Spin, Shopify Functions, Microsoft Hyperlight, 그리고 Fastly Compute의 기반 런타임으로 채택되어 있어 사실상의 산업 표준이 됐습니다.

5. WasmEdge — CNCF의 엣지·서버 런타임

WasmEdge는 Second State가 만든 Wasm 런타임으로 2021년 CNCF Sandbox 프로젝트가 됐고, 2024년 Incubating 단계로 승격됐습니다. C++로 작성됐으며 LLVM AOT 컴파일러를 내장합니다.

WasmEdge의 강점은 엣지·임베디드 영역에 특화된 확장입니다. **wasi-nn**으로 ONNX·OpenVINO·PyTorch 추론을 실행하고, **WasmEdge Tensorflow Plugin**으로 모바일·IoT에서 ML을 돌립니다. 또한 LangChain·llama.cpp 통합으로 LLM을 Wasm 위에서 실행하는 사례가 늘고 있습니다.

WasmEdge 설치 및 LLM 실행 예시

curl -sSf https://raw.githubusercontent.com/WasmEdge/WasmEdge/master/utils/install.sh \

| bash -s -- --plugin wasi_nn-ggml

8B 모델 추론 (Llama 3.1 기반)

wasmedge --dir .:. \

--nn-preload default:GGML:AUTO:llama-3.1-8b-instruct-Q5_K_M.gguf \

llama-chat.wasm \

--prompt-template llama-3-chat \

--ctx-size 4096

WasmEdge는 Docker Desktop이 Wasm 런타임으로 통합한 두 프로젝트(Wasmtime, WasmEdge) 중 하나이며, `docker run --runtime=io.containerd.wasmedge.v1 ...` 형태로 컨테이너 도구체인 안에서 직접 실행됩니다.

6. Wasmer — 다중 컴파일러 + Wasmer Edge

Wasmer(2019~)는 다중 컴파일러 백엔드(Cranelift·LLVM·Singlepass)를 선택할 수 있는 Wasm 런타임입니다. Rust로 작성됐고 2026년 5월 기준 Wasmer 5가 최신 안정 버전입니다.

Wasmer의 차별점은 **언어별 SDK가 가장 다양**하다는 점입니다. Rust·C/C++·Python·Go·JavaScript·Java·Ruby·PHP·C#·Swift·R용 SDK를 공식 제공해 "내 언어 안에서 Wasm 모듈을 호스팅한다"는 경험이 매끄럽습니다. 또한 **WAPM(WebAssembly Package Manager)** 를 운영해 wasm 모듈을 npm처럼 배포·검색합니다.

// Wasmer Rust API — Cranelift 백엔드

use wasmer::{Store, Module, Instance, Value, imports};

use wasmer_compiler_cranelift::Cranelift;

let compiler = Cranelift::new();

let mut store = Store::new(compiler);

let module = Module::from_file(&store, "add.wasm")?;

let import_object = imports! {};

let instance = Instance::new(&mut store, &module, &import_object)?;

let add = instance.exports.get_function("add")?;

let result = add.call(&mut store, &[Value::I32(2), Value::I32(3)])?;

**Wasmer Edge**(2023~)는 자체 서버리스 PaaS로, 깃 푸시 한 번으로 wasm 컴포넌트를 글로벌 엣지에 배포합니다. Cloudflare Workers·Fastly Compute의 경쟁자이며, 차별점은 **Wasmer가 빌드한 어떤 언어든 동일하게 배포된다**는 것입니다.

7. WAMR — Intel의 임베디드 Wasm

WAMR(WebAssembly Micro Runtime)은 Intel이 주도하는 임베디드 친화적 Wasm 런타임으로, Bytecode Alliance 산하 프로젝트입니다. 인터프리터·고전 JIT·Fast JIT·AOT 네 가지 실행 모드를 지원하고, **메모리 풋프린트가 50KB 이하**로 RISC-V·ARM·Xtensa 같은 마이크로컨트롤러에서 동작합니다.

WAMR는 IoT·자동차·산업용 PLC에서 빠르게 채택되고 있습니다. 2025년 BMW가 차량 인포테인먼트 부분 모듈을 WAMR 기반 Wasm으로 전환했다는 사례 발표가 있었고, NVIDIA Jetson 라인업에서도 엣지 추론 모듈을 WAMR로 격리하는 패턴이 나타나고 있습니다.

WAMR — STM32 ARM Cortex-M 빌드 예시

git clone https://github.com/bytecodealliance/wasm-micro-runtime

cd wasm-micro-runtime/product-mini/platforms/zephyr/simple

Zephyr SDK로 RTOS 임베디드 빌드

west build -b nucleo_f767zi -p auto

결과 바이너리에 wasm 모듈 포함되어 부팅 시 자동 로딩

west flash

WAMR의 약점은 **Component Model 지원이 부분적**이라는 점입니다. 임베디드 영역에서는 모듈 단위 실행이 여전히 일반적이지만, Bytecode Alliance 차원에서 컴포넌트 지원 강화 작업이 진행 중입니다.

8. wazero — 순수 Go로 작성된 Wasm

wazero(Tetrate, 2022~)는 **CGO 없이 순수 Go로 작성된 유일한 프로덕션 Wasm 런타임**입니다. Go 개발자 입장에서 가장 큰 매력은 cross-compile이 그대로 작동한다는 점입니다 — Linux에서 빌드한 바이너리를 macOS·Windows·FreeBSD에 그대로 옮길 수 있고, Docker 이미지 크기가 5MB 이하로 끝납니다.

// wazero — Go에서 wasm 모듈 호출

package main

"context"

"os"

_ "embed"

"github.com/tetratelabs/wazero"

"github.com/tetratelabs/wazero/imports/wasi_snapshot_preview1"

)

//go:embed app.wasm

var appWasm []byte

func main() {

ctx := context.Background()

r := wazero.NewRuntime(ctx)

defer r.Close(ctx)

wasi_snapshot_preview1.MustInstantiate(ctx, r)

config := wazero.NewModuleConfig().

WithStdout(os.Stdout).

WithStderr(os.Stderr).

WithArgs("app", "--input", "hello")

_, err := r.InstantiateWithConfig(ctx, appWasm, config)

if err != nil {

panic(err)

}

}

wazero는 Envoy·Dapr·OpenTelemetry Collector·Tetrate Service Bridge 같은 Go 진영 핵심 프로젝트가 플러그인 호스트로 채택했습니다. 단점은 AOT 컴파일이 없어 핫 루프 성능이 Wasmtime의 60~70% 수준이라는 것 — 대신 콜드 스타트는 가장 빠릅니다.

9. WAVM — LLVM 기반 연구 런타임

WAVM(WebAssembly Virtual Machine)은 Andrew Scheidecker가 만든 LLVM 기반 Wasm 런타임으로, 학계와 연구 영역에서 영향력 있는 프로젝트였습니다. 2026년 시점에서 활성 개발은 둔화됐지만 Cranelift·LLVM의 Wasm 백엔드에 영감을 주었고, 일부 HPC 워크로드에서 여전히 사용됩니다.

10. 브라우저 엔진 — V8 · SpiderMonkey · JSC

브라우저는 여전히 Wasm의 가장 큰 사용처입니다. 세 메이저 엔진이 모두 두 단계 컴파일을 사용합니다.

**V8(Chrome·Edge)** 은 Liftoff(베이스라인 컴파일러, 5ms 안에 첫 실행)와 TurboFan(최적화 컴파일러, 백그라운드에서 핫 함수 최적화)을 결합합니다. 또한 V8은 **Wasm GC, Tail Calls, Exception Handling, SIMD, Threads, JSPI**를 가장 먼저 안정화한 엔진이기도 합니다.

**SpiderMonkey(Firefox)** 는 Cranelift를 Wasm 컴파일러로 채택해 Bytecode Alliance와 직접 연결됩니다. Firefox 110부터 Cranelift는 안정 단계가 됐고, GC·Threads·SIMD가 모두 안정 지원됩니다.

**JavaScriptCore(Safari)** 는 BBQ(Build Bytecode Quickly)와 OMG(Optimized Machine code Generator) 컴파일러를 사용합니다. Safari 18에서 Wasm GC와 Tail Calls가 안정 단계로 들어왔고, 2026년 Safari 19에서 JSPI 안정 지원이 추가됐습니다.

11. Wasm GC · Tail Calls · Exception Handling — Phase 4 완료

2024~2025년에 걸쳐 세 가지 핵심 제안이 Phase 4(표준 채택)에 도달했습니다.

**Wasm GC**는 Wasm 모듈이 호스트의 GC 객체(자바스크립트 객체, JVM 객체)와 직접 상호작용할 수 있게 해줍니다. 이전에는 Wasm 모듈이 자체 메모리 안에서만 객체를 다뤘지만, GC 제안으로 struct·array·ref 타입이 추가됐습니다. 이 덕분에 Kotlin/Wasm·Dart→Wasm·Java→Wasm 백엔드가 실용적 수준의 성능을 내기 시작했습니다.

**Tail Calls**는 함수형 언어(Scheme·OCaml·Haskell·Scala)와 일부 컴파일러(JVM tail-rec)가 Wasm 타깃으로 빌드할 때 핵심이었던 기능입니다. 2025년 1월 Phase 4에 도달했습니다.

**Exception Handling**은 C++·C#·Java→Wasm에서 throw/catch를 자연스럽게 표현할 수 있게 해주는 기능입니다. 2024년 Phase 4 도달.

// Wasm GC를 활용한 Kotlin/Wasm 예시 (대략적인 흐름)

// Kotlin 코드:

// data class User(val id: Int, val email: String)

// fun greet(u: User) = "Hello, ${u.email}!"

//

// 컴파일된 wat (개념도):

// (type $User (struct (field $id i32) (field $email (ref string))))

// (func $greet (param $u (ref $User)) (result (ref string)) ...)

12. JSPI · Memory64 · js-string-builtins — Phase 4 신규 진입

2025년에는 세 가지 새 제안이 Phase 4에 도달했습니다. **JSPI(JavaScript Promise Integration)** 는 동기 Wasm 함수에서 비동기 JS Promise를 기다릴 수 있게 해주는 메커니즘으로, Pyodide·Ruby.wasm·Blazor 같은 "JS에서 비동기 IO를 호출해야 하는" 런타임에 결정적이었습니다.

**Memory64**는 wasm32 메모리(최대 4GiB) 제한을 64비트로 확장합니다. AutoCAD Web·Photoshop Web 같은 대용량 메모리 앱에 핵심입니다.

**js-string-builtins**는 자바스크립트의 String 메서드(charCodeAt, fromCharCode, length 등)를 wasm import 없이 직접 사용할 수 있게 해줍니다. 문자열 처리 성능이 2~5배 향상됐습니다.

13. Fermyon Spin — Wasm 서버리스의 선두주자

Fermyon Spin(Matt Butcher, 2022~)은 Wasm 컴포넌트를 HTTP 서버리스 함수로 실행하는 프레임워크입니다. 2026년 5월 기준 Spin 3.x가 안정 버전이고, GitHub 스타 6K+를 보유합니다.

Spin의 핵심 가치는 **콜드 스타트가 1ms 이하**라는 점입니다. Wasmtime의 pooling allocator를 활용해 인스턴스화 비용이 1만분의 1초 수준이라, AWS Lambda(100~500ms 콜드 스타트)와는 다른 차원의 응답성을 보여줍니다.

// Spin 3.x — HTTP 트리거

use spin_sdk::http::{IntoResponse, Request, Response};

use spin_sdk::http_component;

#[http_component]

fn handle_request(req: Request) -> anyhow::Result<impl IntoResponse> {

let name = req.query().get("name").unwrap_or("World");

Ok(Response::builder()

.status(200)

.header("content-type", "text/plain")

.body(format!("Hello, {name}!"))

.build())

}

spin.toml

spin_manifest_version = 2

[application]

name = "hello-wasm"

version = "0.1.0"

authors = ["youngju@example.com"]

[[trigger.http]]

route = "/..."

component = "hello"

[component.hello]

source = "target/wasm32-wasip1/release/hello.wasm"

allowed_outbound_hosts = ["https://api.openai.com"]

Fermyon Cloud는 Spin 앱을 한 줄(`spin deploy`)로 배포하는 PaaS이고, 2024년부터 Fermyon Wasm Functions를 통해 Akamai Edge에서 직접 실행됩니다. Microsoft Azure도 2025년 Spin을 Azure Functions Wasm 워커로 통합하는 프리뷰를 발표했습니다.

14. Cosmonic wasmCloud — CNCF 분산 액터 모델

wasmCloud(Cosmonic, 2020~)는 분산 액터 모델 기반 Wasm 플랫폼으로, 2022년 CNCF Sandbox, 2024년 Incubating으로 승격됐습니다. Spin이 "함수 단위 서버리스"라면 wasmCloud는 "액터·여러 노드·라우팅·capability provider"를 표준화한 더 큰 시스템입니다.

wasmCloud의 핵심 개념은 **Capability Provider**입니다. 액터(wasm 컴포넌트)는 KV·메시징·HTTP 서버 같은 "기능"이 필요하다고 wit 인터페이스로 선언만 하고, 실제 구현은 호스트 노드가 capability provider 형태로 제공합니다. 이 분리 덕에 같은 액터를 dev에서는 SQLite KV, prod에서는 Redis KV로 실행할 수 있습니다.

wash CLI로 wasmCloud 운영

wash up # 호스트 노드 시작

wash app deploy app.yaml # 액터 배포 (wadm 매니페스트)

wash app list

wash claims inspect actor.wasm # signed actor 메타데이터 확인

wasmCloud는 BMW Group, IBM, Akamai가 프로덕션 채택 사례를 발표했고, 2025년 11월 CNCF Incubating 졸업을 향해 Graduation 단계 준비 중입니다.

15. Cloudflare Workers — V8 + Wasm 하이브리드

Cloudflare Workers는 V8 isolate 위에서 동작하는 서버리스 플랫폼이지만, **Wasm 모듈을 1급 시민으로 지원**합니다. JS/TS Worker가 import한 Wasm 모듈은 V8에서 그대로 실행되고, 콜드 스타트는 5ms 이하입니다.

2025년 Cloudflare는 **workerd**(Workers 런타임의 오픈소스 버전)를 출시해 외부 환경에서도 동일한 모델로 Wasm을 실행할 수 있게 했습니다. workerd는 Cap'n Proto RPC로 외부 서비스(KV·D1·R2·Queue)와 통신합니다.

// Cloudflare Workers — JS에서 wasm 호출

export default {

async fetch(request: Request, env: Env) {

const module = await WebAssembly.instantiate(wasm, {

env: { now: () => Date.now() }

});

const buf = await request.arrayBuffer();

const resized = module.instance.exports.resize(buf, 800, 600);

return new Response(resized, {

headers: { "content-type": "image/webp" }

});

}

};

특히 주목할 사례는 **Cloudflare D1**으로, 백엔드가 SQLite-WASM을 V8 isolate 안에서 실행합니다. 같은 코드가 브라우저에서도, 엣지에서도 돌아가는 "isomorphic SQLite"입니다.

16. Fastly Compute — 순수 Wasm PaaS

Fastly Compute@Edge는 **순수 Wasm 기반** 서버리스 플랫폼으로, JS engine을 거치지 않고 Wasmtime을 직접 사용합니다. 2026년 5월 기준 Rust·Go(TinyGo)·JavaScript(SpiderMonkey embedded)·AssemblyScript를 공식 지원합니다.

Fastly Compute의 강점은 **콜드 스타트 35마이크로초**라는 극단적 응답성이고, Fastly의 엣지 PoP 80여 곳에 동일 바이너리가 배포됩니다. 단점은 V8 isolate가 아니라서 npm 생태계 전체를 가져올 수 없다는 점인데, 이를 해결하기 위해 Fastly는 SpiderMonkey를 Wasm으로 빌드해 임베드했습니다.

// Fastly Compute Rust SDK

use fastly::{Error, Request, Response};

#[fastly::main]

fn main(req: Request) -> Result<Response, Error> {

let path = req.get_path();

if path == "/healthz" {

return Ok(Response::from_status(200).with_body_text_plain("ok"));

}

let upstream = req.send("origin_0")?;

Ok(upstream)

}

17. Wasmer Edge · Suborbital Sat — 그 외 PaaS

**Wasmer Edge**(2023~)는 wasm 모듈을 글로벌 엣지에 한 줄로 배포하는 자체 PaaS입니다. Fastly Compute와 비슷한 모델이지만 Wasmer의 다중 컴파일러 백엔드와 wapm 패키지 매니저가 통합돼 있습니다.

**Suborbital Sat**(2022~)은 분산 시스템에 wasm 함수를 임베드하는 라이브러리였고, 2024년 F5에 인수되어 NGINX Wasm 통합으로 흡수됐습니다. NGINX는 njs와 함께 Wasm 필터를 지원하는 방향으로 가고 있습니다.

18. 언어 지원 — Rust 일급, Go·Python·Java 따라잡기

Wasm 타깃을 가진 언어는 2026년 5월 기준 40여 개로 늘었습니다. 주요 언어별 상태는 다음과 같습니다.

| 언어 | 상태 | 비고 |

|---|---|---|

| Rust | 일급 | `wasm32-wasip1`, `wasm32-wasip2`, `wasm32-unknown-unknown` |

| Go | 일급(TinyGo) | TinyGo가 표준, 표준 Go도 wasip1 지원 |

| C/C++ | 일급 | Emscripten, WASI SDK |

| AssemblyScript | 일급 | TypeScript-like, 자체 컴파일러 |

| Python | 실험적 | py2wasm(Wasmer), Pyodide |

| Ruby | 실험적 | ruby.wasm(공식), CRuby 3.2부터 |

| Java | 실험적 | TeaVM, GraalVM Native Image |

| .NET | 실험적 | Blazor, Mono+WASI |

| MoonBit | 일급 | Wasm 우선 설계, 2025년 1.0 |

| Kotlin | 미리보기 | Kotlin/Wasm, JetBrains 주도 |

| Swift | 실험적 | SwiftWasm |

| PHP | 실험적 | PHP 8.4 wasm 빌드 |

**MoonBit**(IDEA Software, 2023~)는 가장 흥미로운 신규 언어입니다. Wasm을 일급 타깃으로 설계됐고, 2025년 1.0이 출시됐습니다. Rust보다 컴파일이 빠르고 wasm 출력이 작다는 점이 강점입니다.

// MoonBit — Wasm 우선 설계

pub fn fib(n : Int) -> Int {

if n < 2 {

n

} else {

fib(n - 1) + fib(n - 2)

}

}

pub fn main {

println(fib(20))

}

19. Rust + Wasm — 가장 성숙한 조합

Rust는 2018년부터 Wasm 일급 타깃이었고, 2026년 5월 기준 세 개의 핵심 타깃을 지원합니다.

- **wasm32-unknown-unknown**: 브라우저용, 표준 라이브러리 일부만 사용 가능

- **wasm32-wasip1**: WASI Preview 1, 파일/네트워크 호환 모드

- **wasm32-wasip2**: WASI Preview 2, Component Model 일급

Rust로 컴포넌트 빌드 후 컴포지션

rustup target add wasm32-wasip2

cargo install cargo-component

wit 인터페이스 + Rust 구현

cargo component new my-checkout --lib

cd my-checkout

wit/world.wit 작성 후

cargo component build --release

wasm-tools로 메타데이터 확인

wasm-tools component wit target/wasm32-wasip2/release/my_checkout.wasm

**wasm-bindgen**(브라우저), **wit-bindgen**(컴포넌트), **wasm-tools**(메타데이터·합성), **wasm-pack**(npm 패키징) 네 도구가 Rust+Wasm 워크플로의 핵심입니다.

20. Go · TinyGo · Python · Ruby — 비-Rust 언어의 길

**Go**는 1.21부터 `GOOS=wasip1` 빌드를 표준 지원합니다. 단, Go 런타임 자체가 크기 때문에 결과 wasm이 수 MB에 달합니다. **TinyGo**는 LLVM 기반의 Go 컴파일러로 100KB대 wasm을 출력합니다. 표준 라이브러리 일부가 빠지지만 임베디드·엣지 영역에서 사실상 표준입니다.

**Python**은 두 갈래입니다. **Pyodide**는 CPython을 Emscripten으로 빌드한 것으로 브라우저에서 NumPy·Pandas·SciPy까지 돌립니다. **py2wasm**(Wasmer)은 CPython 바이트코드를 wasm으로 변환해 더 빠른 실행을 노립니다.

**Ruby**는 ruby.wasm 공식 프로젝트(Yuta Saito, 2022~)가 있어 Ruby 3.2부터 표준에 포함됐습니다. Rails 자체는 아직 어렵지만 Ruby DSL을 브라우저에서 실행하는 사례가 늘고 있습니다.

<!-- ruby.wasm 브라우저 예시 -->

require "js"

puts "Hello from Ruby #{RUBY_VERSION}!"

document = JS.global[:document]

document.body.innerText = "Ruby in the browser"

21. Java · .NET · Kotlin · Swift — 엔터프라이즈 진영

**Java**는 두 경로가 있습니다. **TeaVM**(2014~)은 JVM 바이트코드를 wasm으로 변환하는 컴파일러이고, **GraalVM Native Image**는 2024년부터 wasm 백엔드 실험 단계입니다. Wasm GC가 표준이 되면서 Java→Wasm 성능이 실용 단계에 진입했습니다.

**.NET**은 Blazor(브라우저용)와 **Mono+WASI**(서버용) 두 트랙입니다. Blazor WebAssembly는 .NET 9에서 AOT 성능이 크게 좋아졌고, .NET 10(2025.11)에서 WASI 0.2를 정식 지원합니다.

**Kotlin/Wasm**은 JetBrains의 우선 과제입니다. 2024년 Kotlin Multiplatform의 wasm 타깃이 미리보기에 들어갔고, Compose Multiplatform이 wasm 타깃으로 브라우저 UI를 빌드할 수 있게 됐습니다.

**SwiftWasm**은 커뮤니티 주도지만 Swift 6.0부터 표준 툴체인에 부분 통합됐습니다.

22. Wasm + AI/ML — wasi-nn · WebLLM · ONNX Runtime Web

Wasm은 AI/ML 추론 영역에서 빠르게 자리를 잡고 있습니다. 핵심 표준은 **wasi-nn**으로, 호스트가 GPU·NPU 가속을 제공하면 wasm 모듈이 표준 API로 호출합니다.

**WebLLM**(MLC-AI, 2023~)은 LLM을 브라우저에서 직접 돌리는 프로젝트입니다. WebGPU + Wasm을 결합해 Llama 3.1 8B 양자화 모델을 노트북 GPU에서 추론합니다. 같은 팀의 MLC-Chat은 모바일에서도 같은 모델을 돌립니다.

**ONNX Runtime Web**은 PyTorch·TF·scikit-learn 모델을 ONNX로 변환한 후 wasm에서 실행합니다. SIMD·Threads·WebGPU 백엔드를 자동 선택합니다.

**Burn**(Rust)과 **Candle**(Rust, HuggingFace)은 Rust로 작성된 ML 프레임워크로 wasm 타깃을 1급 지원합니다. 같은 코드가 서버 GPU와 브라우저 wasm 모두에서 돌아가는 시나리오를 노립니다.

// Candle — Rust ML을 wasm으로

use candle_core::{Device, Tensor};

use candle_nn::{linear, Module, VarBuilder};

// 작은 MLP 추론

fn forward(weights: &VarBuilder, x: &Tensor) -> anyhow::Result<Tensor> {

let l1 = linear(784, 128, weights.pp("l1"))?;

let l2 = linear(128, 10, weights.pp("l2"))?;

Ok(l2.forward(&l1.forward(x)?.relu()?)?)

}

// 빌드: cargo build --target wasm32-unknown-unknown

23. Extism · proxy-wasm — 플러그인 시스템

**Extism**(Dylibso, 2022~)은 "어디서나 동일한 플러그인 API"를 목표로 한 universal plugin 프레임워크입니다. C·Rust·Go·Python·Node·Ruby·PHP·Java·.NET용 호스트 SDK가 있어 같은 wasm 플러그인을 9개 언어 호스트에서 동일하게 실행할 수 있습니다.

// Extism 플러그인 (Rust로 작성)

use extism_pdk::*;

#[plugin_fn]

pub fn count_vowels(text: String) -> FnResult<Json<serde_json::Value>> {

let count = text.chars().filter(|c| "aeiouAEIOU".contains(*c)).count();

Ok(Json(serde_json::json!({ "vowels": count })))

}

Extism Python 호스트

manifest = {"wasm": [{"path": "count_vowels.wasm"}]}

with extism.Plugin(manifest, wasi=True) as plugin:

result = plugin.call("count_vowels", b"Hello, Wasm!")

print(result.decode()) # {"vowels": 3}

**proxy-wasm**은 Envoy·Istio·NGINX·Kong 같은 프록시가 채택한 wasm 필터 ABI입니다. Rust·Go·AssemblyScript로 필터를 작성하면 모든 proxy-wasm 호환 프록시에서 동일하게 작동합니다.

24. 실전 도입 — Figma · Adobe · AutoCAD · Notion

WebAssembly의 실전 도입은 2017년 Figma가 C++ 렌더링 엔진을 wasm으로 컴파일하면서 시작됐습니다. Figma는 wasm 덕에 일렉트론 데스크톱과 웹이 동일한 코드를 공유할 수 있게 됐고, 이는 이후 모든 "웹으로 가는 데스크톱 앱"의 청사진이 됐습니다.

**Adobe Photoshop Web**(2021)은 25년 된 C++ 코드베이스를 Emscripten으로 wasm 컴파일한 사례로 유명합니다. 메모리 64비트가 필요할 정도로 큰 앱이고, Memory64 제안의 추진 동력이기도 했습니다.

**AutoCAD Web**(Autodesk)도 비슷한 패턴입니다. 35년 된 ObjectARX C++ 코드를 wasm으로 옮겨 브라우저에서 DWG 편집을 지원합니다.

**Cloudflare D1**은 SQLite를 wasm으로 빌드해 V8 isolate 안에서 실행합니다. 같은 wasm을 브라우저의 OPFS(Origin Private File System) 위에서도 돌려 "오프라인 우선" 앱을 만듭니다.

**Notion AI inline**은 텍스트 후처리 일부를 클라이언트 wasm으로 옮겨 응답 지연을 줄였고, **Microsoft Office Web**의 수식 엔진 일부도 wasm으로 동작합니다.

25. 한국 사례 — NAVER · Kakao · LINE

**NAVER Cloud Wasm Functions**(2024 발표)는 Wasmtime 기반 서버리스로, Spin과 유사한 모델이지만 한국 리전·결제 시스템에 통합돼 있습니다. NAVER 내부 검색·번역 부가 모듈 일부가 wasm으로 운영됩니다.

**Kakao**는 카카오톡 챗봇 메시지 후처리 일부를 wasm 플러그인으로 격리하는 R&D를 2024년 발표했습니다. proxy-wasm 호환 필터가 채택 후보로 검토 중입니다.

**LINE Yahoo Japan**(전 야후! 재팬)은 메일·뉴스 컴포넌트 일부에서 wasm 기반 격리를 채택했고, 광고 sandbox에 wasm을 사용하는 사례 발표가 있었습니다.

26. 일본 사례 — Cybozu · NTT · DeNA · Mercari

**Cybozu**는 kintone JavaScript 사용자 코드 격리에 wasm 도입 R&D를 발표했습니다. 사용자가 작성한 임의 JS를 wasm 샌드박스로 실행해 멀티테넌트 안전성을 확보하는 방향입니다.

**NTT Communications**는 SDPF Edge에서 wasm 기반 엣지 함수를 실험 중이고, **DeNA**는 게임 서버 일부 도메인 로직을 wasm 모듈로 격리하는 사례를 GREE Tech Conf에서 공유했습니다.

**Mercari**는 검색 랭킹 후처리에 wasi-nn 기반 wasm 추론을 활용한다는 발표가 있었고, **Cookpad**는 ruby.wasm을 사용자 레시피 DSL 평가에 적용하는 실험을 진행 중입니다.

27. 거버넌스 — Bytecode Alliance · CNCF · W3C

WebAssembly 생태계는 세 거버넌스 축으로 운영됩니다.

**Bytecode Alliance**는 2019년 Mozilla·Fastly·Intel·Red Hat이 시작한 비영리로, Wasmtime·WAMR·Cranelift·wasm-tools·cargo-component를 호스팅합니다. 2024년 시점 멤버는 60곳을 넘고, Microsoft·Google·Arm·Siemens가 Premier 멤버입니다.

**CNCF**는 클라우드 네이티브 진영의 wasm 프로젝트를 호스팅합니다. WasmEdge·wasmCloud가 Incubating 단계이고, Spin·SpinKube·Krustlet 등은 Sandbox·Incubating에 분포합니다.

**W3C WebAssembly Working Group**은 wasm 표준화의 공식 본부입니다. Phase 0~5의 제안 흐름을 운영하고 모든 메이저 제안이 여기서 합의됩니다. 핵심 멤버는 Google·Mozilla·Apple·Microsoft·Intel·Arm·Fastly입니다.

28. 참고 자료 (References)

다음 자료들은 본문에 인용된 사실·수치를 직접 검증할 수 있는 1차/2차 출처입니다.

1. [WebAssembly 공식 사이트](https://webassembly.org/)

2. [WASI 0.2 GA 발표 (Bytecode Alliance, 2024-01-25)](https://bytecodealliance.org/articles/WASI-0.2)

3. [Component Model 명세 (W3C / Bytecode Alliance)](https://github.com/WebAssembly/component-model)

4. [Wasmtime 공식 문서](https://docs.wasmtime.dev/)

5. [WasmEdge CNCF 프로젝트 페이지](https://www.cncf.io/projects/wasmedge-runtime/)

6. [Wasmer 공식 사이트](https://wasmer.io/)

7. [WAMR (WebAssembly Micro Runtime) GitHub](https://github.com/bytecodealliance/wasm-micro-runtime)

8. [wazero 공식 사이트](https://wazero.io/)

9. [Fermyon Spin 공식 문서](https://developer.fermyon.com/spin)

10. [Cosmonic wasmCloud 공식](https://wasmcloud.com/)

11. [Cloudflare Workers Wasm 가이드](https://developers.cloudflare.com/workers/runtime-apis/webassembly/)

12. [Fastly Compute 문서](https://www.fastly.com/documentation/guides/compute/)

13. [Wasmer Edge 문서](https://docs.wasmer.io/edge)

14. [wit-bindgen GitHub](https://github.com/bytecodealliance/wit-bindgen)

15. [wasm-tools GitHub](https://github.com/bytecodealliance/wasm-tools)

16. [Bytecode Alliance 공식](https://bytecodealliance.org/)

17. [MDN WebAssembly 레퍼런스](https://developer.mozilla.org/en-US/docs/WebAssembly)

18. [TinyGo 공식 사이트](https://tinygo.org/)

19. [Pyodide 공식](https://pyodide.org/)

20. [ruby.wasm 공식](https://github.com/ruby/ruby.wasm)

21. [Kotlin/Wasm 가이드](https://kotlinlang.org/docs/wasm-overview.html)

22. [MoonBit 공식 사이트](https://www.moonbitlang.com/)

23. [Extism 공식](https://extism.org/)

24. [WebLLM 프로젝트](https://webllm.mlc.ai/)

25. [Figma WebAssembly 도입 사례 (2017)](https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/)

면책: 이 글은 2026년 5월 시점의 정보를 정리한 것이며, Wasm 표준과 런타임은 매우 빠르게 발전합니다. 프로덕션 도입 시에는 위 1차 출처를 직접 확인하시고, 본문은 학습·비교 목적에 한해 활용해 주세요.