브라우저 밖으로 나온 WebAssembly, 이제 런타임 고르는 게 진짜 고민이에요
WebAssembly(이하 Wasm)가 처음 나왔을 때는 '브라우저에서 C++ 게임 돌리는 기술' 정도로 알려졌는데요. 지금은 상황이 많이 달라졌어요. 서버리스 엣지 함수, 애플리케이션 플러그인 시스템, 데이터베이스 안에서 도는 사용자 정의 함수, 심지어 임베디드 기기까지 Wasm이 들어가고 있거든요. 브라우저 밖에서 Wasm을 실행하려면 '런타임'이 필요한데, 이게 뭐냐면 Wasm 바이트코드를 읽어서 실제 CPU 명령어로 바꿔 실행해주는 엔진이에요. Java의 JVM이나 파이썬 인터프리터 같은 역할이라고 보시면 돼요.
문제는 이 런타임이 한두 개가 아니라는 점이에요. Wasmtime, Wasmer, WasmEdge, WAMR, wazero, wasmi, wasm3... 이름만 나열해도 헷갈리죠. 그래서 libsodium이라는 암호화 라이브러리를 만든 Frank Denis가 몇 년째 주기적으로 이 런타임들을 한자리에 모아 성능을 재는 벤치마크를 공개하고 있는데요. 이번에 2026년 버전이 나왔어요. 저는 이 시리즈를 볼 때마다 '올해는 지형이 어떻게 바뀌었나'를 확인하는 재미가 있더라고요.
어떻게 측정하냐면, 암호 라이브러리를 통째로 돌려요
이 벤치마크의 특징은 자기가 만든 libsodium의 테스트 스위트를 Wasm으로 컴파일해서 각 런타임에서 돌린다는 거예요. 암호 연산은 정수 연산, 비트 시프트, 메모리 접근이 빽빽하게 들어가는 CPU 집약적인 작업이라서 런타임의 '순수 실행 성능'을 보기에 좋은 재료거든요. 반대로 말하면 파일 I/O나 네트워크 성능은 이 벤치마크로 알 수 없다는 점도 기억해 두셔야 해요.
런타임은 크게 두 부류로 나눠서 보면 이해가 쉬워요.
- 컴파일러형(JIT/AOT): Wasm 바이트코드를 네이티브 기계어로 번역한 다음 실행해요. 번역 비용이 들지만 실행 속도는 네이티브에 가까워져요. Wasmtime(Cranelift 백엔드), Wasmer, WasmEdge, WAMR의 AOT 모드가 여기 속해요. AOT가 뭐냐면 'Ahead-Of-Time', 즉 실행 전에 미리 컴파일해 두는 방식이고, JIT는 실행하면서 그때그때 컴파일하는 방식이에요.
- 인터프리터형: 기계어로 바꾸지 않고 바이트코드를 한 줄씩 읽어서 해석해요. 실행은 느리지만 시작이 거의 즉시고, 메모리를 적게 쓰고, JIT를 허용하지 않는 환경(iOS나 일부 임베디드 기기)에서도 돌아가요. wasm3, wasmi, WAMR의 인터프리터 모드가 대표적이에요.
순위표만 보면 놓치는 것들
지난 몇 년간의 결과를 보면 Wasmtime, Wasmer, WAMR AOT 같은 컴파일러형 런타임이 꾸준히 상위권을 형성해 왔고, 인터프리터형은 수 배에서 수십 배 느린 게 일반적이었어요. 그런데 이 시리즈에서 제가 항상 흥미롭게 보는 부분은 '누가 1등이냐'보다 '누가 얼마나 좋아졌냐'예요. 예를 들어 Rust로 짠 인터프리터인 wasmi는 몇 년 전 스택 기반 설계를 레지스터 기반으로 갈아엎으면서 인터프리터답지 않은 속도를 내기 시작했고, Go로만 짜여서 cgo 의존성이 없는 wazero는 초기에 느리다는 평을 들었지만 컴파일러 백엔드를 계속 개선해 왔거든요. 올해 그래프에서 이런 프로젝트들이 어디까지 올라왔는지 확인해 보시면 좋아요.
그리고 벤치마크를 읽을 때 꼭 같이 봐야 하는 축이 세 가지 있어요. 첫째는 컴파일 시간이에요. 실행이 빠른 대신 첫 요청 전에 몇백 밀리초를 컴파일에 쓰는 런타임은 서버리스처럼 짧게 자주 뜨는 환경에선 오히려 손해일 수 있거든요. 둘째는 SIMD 지원 여부예요. Wasm SIMD(한 번에 여러 데이터를 처리하는 벡터 명령어)를 제대로 네이티브 명령어로 매핑하느냐에 따라 암호나 미디어 처리 성능이 몇 배 갈려요. 셋째는 플랫폼 커버리지예요. ARM64, RISC-V, JIT 금지 환경에서도 돌아가느냐가 실무에선 속도만큼 중요할 때가 많아요.
업계 흐름에서 이 벤치마크의 위치
지금 Wasm 생태계는 Bytecode Alliance가 주도하는 Wasmtime과 WASI(시스템 인터페이스 표준) 진영, 독자 노선을 걷는 Wasmer, 클라우드 네이티브 쪽에 집중하는 WasmEdge, 임베디드에 강한 WAMR로 큰 흐름이 갈려 있어요. 실제 제품에서는 Cloudflare Workers, Fastly Compute, Fermyon Spin 같은 서버리스 플랫폼이 Wasm을 실행 단위로 쓰고 있고, Envoy 프록시나 Istio는 필터를 Wasm 플러그인으로 받아요. Extism 같은 프로젝트는 '어떤 언어로 짠 앱이든 Wasm 플러그인을 붙일 수 있게' 해주고요. 즉, 런타임 성능은 더 이상 학술적 호기심이 아니라 이런 플랫폼들의 응답 시간과 비용에 직결되는 숫자가 된 거예요.
한국 개발자에게는 어떤 의미일까요
당장 실무에서 Wasm 런타임을 고를 일이 있다면 이렇게 접근해 보세요. Go 서비스에 플러그인 시스템을 넣고 싶다면 cgo 없이 붙는 wazero가 배포 편의성 면에서 유리하고, Rust 기반이거나 최고 성능이 필요하다면 Wasmtime이 무난한 기본 선택이에요. 모바일이나 임베디드처럼 JIT가 막힌 환경이면 WAMR 인터프리터나 wasmi를 봐야 하고요. 그리고 어떤 런타임을 고르든, 벤치마크의 워크로드가 여러분 워크로드와 다르다는 걸 잊지 마세요. 암호 연산에서 빠른 런타임이 문자열 처리 위주의 플러그인에서도 빠르리란 보장은 없거든요. 직접 작은 벤치마크를 돌려보는 게 가장 확실해요.
정리하자면
Wasm 런타임은 '컴파일러형은 빠르고 인터프리터형은 가볍다'는 큰 틀은 유지되지만, 매년 격차가 좁혀지고 있고 프로젝트별 부침이 꽤 커요. 여러분은 브라우저 밖에서 Wasm을 써보신 적 있나요? 플러그인 시스템이나 엣지 함수에 도입을 고민 중이라면, 어떤 기준으로 런타임을 고르셨는지 댓글로 이야기 나눠봐요.
🔗 출처: Hacker News