[WebAssembly 실전] Day 5: 프로덕션 - 크기 최적화, 디버깅, 그리고 언제 쓸 것인가

서론: 작동하는 Wasm에서 프로덕션 Wasm으로

Day 1~4에서 Wasm의 구조·컴파일·보안·응용을 다뤘다. 마지막은 실전 운영이다. 다운로드·시작 속도를 좌우하는 바이너리 크기, 까다로운 Wasm 디버깅, 그리고 가장 중요한 질문 — “이 작업에 Wasm을 써야 하는가?”를 정리한다.

1. 바이너리 크기가 곧 성능이다

브라우저·엣지에서는 .wasm 크기가 다운로드·컴파일·시작 시간을 직접 좌우한다.

크기를 키우는 주범:
  - 언어 런타임 (Go 표준 컴파일러는 GC 포함 → MB 단위)
  - 표준 라이브러리의 안 쓰는 부분
  - 디버그 정보
  - panic/포매팅 메시지 (Rust)

전략:
  1. 적합한 툴체인: Go라면 TinyGo (Day 2), Rust/C는 본래 작음
  2. 릴리스 빌드 + 크기 최적화 플래그
  3. wasm-opt 후처리
  4. 트리 셰이킹 / 데드코드 제거

# Cargo.toml: Rust Wasm 크기 최적화
[profile.release]
opt-level = "z"     # 크기 우선 최적화
lto = true          # 링크 타임 최적화 (데드코드 제거)
codegen-units = 1
panic = "abort"     # panic 언와인딩 코드 제거
strip = true        # 심볼 제거

2. wasm-opt: 후처리 최적화

binaryen의 wasm-opt는 컴파일된 Wasm을 한 번 더 최적화한다.

# 크기와 속도를 동시에 최적화
wasm-opt -Oz input.wasm -o output.wasm    # -Oz: 크기 최우선
wasm-opt -O3 input.wasm -o output.wasm    # -O3: 속도 최우선

# 효과 확인
ls -la input.wasm output.wasm   # 보통 15~40% 감소

배포 전 wasm-opt를 빌드 파이프라인에 넣는 것은 거의 공짜 최적화다.

3. 추가 전송 최적화

# 1) 압축: Wasm은 gzip/brotli로 잘 압축됨 (서버에서 Content-Encoding)
brotli -q 11 app.wasm    # 추가 20~30% 감소

# 2) 스트리밍 컴파일: 다운로드와 컴파일을 동시에
#    instantiateStreaming은 .wasm을 받으면서 컴파일 시작

// ❌ 다운로드 완료 후 컴파일 시작
const bytes = await fetch('app.wasm').then(r => r.arrayBuffer());
await WebAssembly.instantiate(bytes);

// ✅ 다운로드하면서 컴파일 (더 빠른 시작)
//    단, 서버가 Content-Type: application/wasm 를 보내야 함
await WebAssembly.instantiateStreaming(fetch('app.wasm'));

4. 디버깅: 어려운 것이 사실이다

Wasm 디버깅은 네이티브보다 까다롭다. 솔직히 알고 대비해야 한다.

도구:
  - DWARF 디버그 정보 + 브라우저 DevTools: 소스 레벨 중단점·변수 확인
    (디버그 빌드에 한해, C/C++/Rust 소스 매핑 지원)
  - console 로그: import한 호스트 log 함수로 출력 (Day 2)
  - wasm2wat: 바이너리를 텍스트로 역어셈블해 명령어 수준 확인
  - 패닉 메시지: Rust는 console_error_panic_hook으로 패닉을 콘솔에

원칙: 가능한 로직을 네이티브에서 테스트하고,
      Wasm 고유 문제(경계 횡단·메모리)만 Wasm에서 디버깅

// Rust: panic을 브라우저 콘솔에 보이게 (개발용)
#[wasm_bindgen(start)]
pub fn init() {
    console_error_panic_hook::set_once();
}

5. 프로파일링과 함정

성능 측정:
  - 브라우저 Performance 탭에서 Wasm 함수도 프로파일됨
  - JS ↔ Wasm 경계 횡단 횟수를 센다 (Day 2의 주요 비용)

흔한 성능 함정:
  ❌ 작은 함수를 경계 너머로 수백만 번 호출 → 경계 비용이 연산을 압도
  ❌ 매 호출마다 큰 데이터를 메모리에 복사
  ✅ 데이터를 메모리에 한 번 올리고 Wasm 안에서 일괄 처리
  ✅ 무거운 루프 전체를 Wasm으로, 결과만 경계 너머로

6. 언제 Wasm을 쓰고, 언제 쓰지 말 것인가

가장 중요한 판단이다. Wasm은 만능이 아니다.

Wasm이 빛나는 경우:
  ✅ CPU 집약 연산: 이미지/비디오 처리, 암호화, 압축, 파싱, 물리·과학 계산
  ✅ 기존 C/C++/Rust 자산의 웹 포팅 (게임 엔진, 코덱)
  ✅ 신뢰할 수 없는 코드의 안전한 실행 (플러그인·멀티테넌시 — Day 4)
  ✅ 엣지의 빠른 콜드 스타트 서버리스 (Day 4)
  ✅ 언어 중립 모듈 배포 (컴포넌트 모델 — Day 3)

Wasm이 부적합한 경우:
  ❌ DOM을 많이 조작하는 UI 로직 (Wasm은 DOM 직접 접근 불가, JS 경유로 느림)
  ❌ 가벼운 I/O 위주 작업 (계산이 적으면 Wasm 이점 없음)
  ❌ 작은 스크립트 (JS로 충분, Wasm 빌드 복잡성만 추가)
  ❌ 경계를 자주 넘나드는 잦은 소형 호출

원칙: "무거운 계산 덩어리"를 Wasm으로, "조율·UI·I/O"는 JS/호스트로.
      둘은 경쟁이 아니라 역할 분담이다.

7. 시리즈 종합 체크리스트

1. 스택 머신·선형 메모리·모듈 구조로 Wasm의 동작 원리를 이해했다. (Day 1)
2. Rust/C/Go를 컴파일하고 JS와 데이터를 교환했다. (Day 2)
3. WASI와 능력 기반 보안으로 브라우저 밖에서 안전하게 실행했다. (Day 3)
4. 플러그인·멀티테넌시·엣지에 Wasm을 임베드했다. (Day 4)
5. 크기 최적화·디버깅·적용 판단으로 프로덕션 운영 기준을 세웠다. (Day 5)

시리즈 마무리

WebAssembly의 본질은 “휴대 가능하고, 안전하고, 빠른 실행“이라는 세 속성의 결합이다. 이 셋이 만나는 지점에서 브라우저의 고성능 연산, 신뢰 없는 코드의 안전한 실행, 언어 중립 플러그인, 콜드 스타트 없는 엣지 컴퓨팅이 모두 가능해진다.

기초(구조)→컴파일(언어 연동)→보안(WASI·능력)→응용(플러그인·엣지)→운영(최적화·판단) 다섯 단계를 거치면, Wasm을 “유행어”가 아니라 적재적소에 쓰는 도구로 다룰 수 있다. 핵심은 마지막 교훈이다 — Wasm은 JavaScript의 대체가 아니라, 무거운 계산을 맡기는 동반자다.