WebAssembly 서버리스 — 콜드스타트 없는 엣지 컴퓨팅의 다음 단계

서버리스의 마지막 병목은 코드가 아니라 '시작'이다. WebAssembly는 이 시작 비용을 밀리초에서 마이크로초로 끌어내린다.

컨테이너 기반 함수(Function-as-a-Service)는 콜드스타트라는 구조적 세금을 안고 산다. Wasm은 무거운 OS·언어 런타임을 건너뛰고 격리된 선형 메모리 인스턴스를 거의 즉시 만들어낸다. 2026년 현재 Fastly, Cloudflare Workers, wasmCloud, Spin 같은 런타임이 이 모델을 프로덕션으로 밀어붙이고 있다. 무엇이 실제로 달라지고, 어디서 컨테이너를 대체할 수 없는지 짚는다.

Wasm은 왜 즉시 켜지는가

WebAssembly는 이식 가능한 바이너리 명령 포맷이다. 원래 브라우저용으로 설계됐지만, 서버 관점에서 중요한 건 실행 모델이다. Wasm 모듈은 선형 메모리(linear memory) 하나와 검증된 바이트코드로 구성된다. 런타임(Wasmtime, V8, Wizer 등)은 이 모듈을 미리 컴파일(AOT)해두었다가, 요청이 오면 새 인스턴스 = 새 선형 메모리 + 실행 스택만 할당한다. OS 프로세스도, 컨테이너 네임스페이스도, 언어 VM 부팅도 없다.

그래서 인스턴스화가 마이크로초 단위다. 격리는 프로세스 경계가 아니라 Wasm 샌드박스 자체가 제공한다. 모듈은 자기 선형 메모리 밖을 건드릴 수 없고, 명시적으로 임포트(import)한 함수 외에는 어떤 시스템 콜도 호출할 수 없다. 기본이 '아무것도 못 함'이고, 능력(capability)을 하나씩 주입받는 구조라 멀티테넌트 환경에 잘 맞는다.

Cloudflare Workers는 여기에 V8 isolate를 결합한다. 하나의 프로세스 안에서 수천 개의 isolate가 각자 격리된 힙을 갖고, 요청 사이에 컨텍스트만 스위칭한다. 이것이 '콜드스타트 없는 서버리스'라는 마케팅 문구의 실체다 — 프로세스가 아니라 힙 하나를 초기화하니까.

WASI와 컴포넌트 모델

순수 Wasm은 파일도, 소켓도, 시간도 모른다. 서버에서 쓸모가 있으려면 표준화된 시스템 인터페이스가 필요하고, 그게 WASI(WebAssembly System Interface)다. WASI Preview 1은 POSIX 유사 파일·시계·랜덤을 제공했지만 한계가 뚜렷했다. 2024년 이후 표준화된 WASI 0.2(Preview 2)는 컴포넌트 모델(Component Model) 위에서 재설계됐다.

컴포넌트 모델의 핵심은 WIT(Wasm Interface Type)로 기술한 타입 있는 인터페이스다. 모듈이 선형 메모리에 숫자만 주고받던 저수준 ABI 위에, 문자열·레코드·리스트·리소스 같은 고수준 타입을 언어 중립적으로 정의한다. 그 결과 Rust로 만든 컴포넌트와 Go로 만든 컴포넌트가, 서로의 메모리 레이아웃을 몰라도 함수 호출로 조립된다. 이것이 'Wasm의 진짜 이식성'을 완성하는 조각이다.

// world.wit — 컴포넌트가 무엇을 임포트/익스포트하는지 선언
package example:greeter@0.1.0;

interface greetings {
  // 이름을 받아 인사말을 돌려주는 익스포트 함수
  greet: func(name: string) -> string;
}

world app {
  // 호스트가 제공하는 능력(로깅)만 임포트
  import wasi:logging/logging@0.1.0;
  export greetings;
}

위 WIT는 언어와 무관한 '계약'이다. 호스트는 greet를 호출할 수 있고, 컴포넌트는 wasi:logging 외에는 아무 능력도 갖지 못한다. 능력 기반 보안(capability-based security)이 인터페이스 수준에서 강제되는 것이다.

언어 지원 — Rust, Go, JS

Rust는 사실상 1급 시민이다. wasm32-wasip2 타깃이 안정적이고, cargo component와 wit-bindgen이 WIT에서 타입 안전한 바인딩을 생성한다. 런타임(GC·리플렉션)이 없어 아티팩트가 작고 시작이 빠르다.

// lib.rs — 위 WIT를 구현하는 Rust 컴포넌트
wit_bindgen::generate!({ world: "app" });

use exports::example::greeter::greetings::Guest;

struct Component;

impl Guest for Component {
    fn greet(name: String) -> String {
        // 임포트한 로깅 능력 사용
        wasi::logging::logging::log(
            wasi::logging::logging::Level::Info,
            "greeter",
            &format!("greeting {name}"),
        );
        format!("안녕하세요, {name}님!")
    }
}

export!(Component);

Go는 두 갈래다. 표준 Go 컴파일러는 GC와 런타임이 무거워 Wasm 아티팩트가 크고 컴포넌트 모델 지원이 늦었다. 그래서 임베디드용 TinyGo가 오랫동안 실질적 경로였고, wasip2와 컴포넌트 지원도 TinyGo 쪽이 앞섰다. 2026년 현재 표준 Go도 WASI 지원을 넓히고 있지만, 최소 아티팩트가 필요하면 여전히 TinyGo가 유리하다.

JavaScript는 접근이 다르다. JS는 인터프리터 언어라 그냥 컴파일되지 않는다. 대신 엔진을 Wasm 안에 넣는다. StarlingMonkey(SpiderMonkey 기반)나 QuickJS를 Wasm으로 빌드하고, 그 안에서 사용자 JS를 실행한 뒤 wizer로 힙 스냅샷을 미리 떠 시작을 앞당긴다. Cloudflare Workers는 아예 V8 isolate를 직접 쓰므로 이 계층이 다르지만, Fastly Compute나 Spin의 JS SDK는 이 '엔진 임베딩' 방식을 쓴다.

# Spin 앱 스캐폴딩부터 배포까지 (예시 흐름)
spin new -t http-rust hello-edge
cd hello-edge

# 컴포넌트 빌드 (wasm32-wasip2 타깃)
spin build

# 로컬 실행 — 콜드스타트 없이 즉시 응답
spin up

# Fermyon Cloud / 셀프호스트로 배포
spin deploy

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: wasmtime
handler: wasmtime   # containerd shim이 이 핸들러로 Wasm 실행
---
apiVersion: v1
kind: Pod
metadata:
  name: greeter
spec:
  runtimeClassName: wasmtime   # 이 파드만 Wasm 런타임에
  containers:
    - name: app
      image: registry.example.com/greeter:0.1.0  # .wasm 아티팩트