웹어셈블리(Wasm) — 서버·엣지에서 컨테이너의 대안이 될까

웹어셈블리(WebAssembly, 줄여서 Wasm)가 브라우저 밖으로 나오고 있다. 원래는 웹에서 무거운 연산을 빠르게 돌리려고 만든 기술인데, 요즘은 서버와 엣지(edge)에서 컨테이너의 가벼운 대안으로 주목받는다. 핵심은 이렇다. Wasm은 언어에 상관없이 컴파일되는 이식성 높은 실행 형식이고, 시작이 빠르며 격리가 강하다.

나는 처음에 "브라우저용 기술이 서버에서 왜?"라고 갸웃했다. 그런데 서버리스와 엣지의 요구—빠른 콜드 스타트, 작은 실행 단위, 촘촘한 격리—를 하나씩 대보니, Wasm의 성질이 그 요구에 놀랄 만큼 잘 들어맞았다.

왜 서버로 나왔나

컨테이너는 클라우드 네이티브의 표준이 됐지만 무결점은 아니다. 이미지가 무겁고, 콜드 스타트가 수백 밀리초에서 초 단위까지 늘어질 수 있다. 서버리스처럼 순간적으로 함수를 띄웠다 내리는 상황에서 이 지연은 뼈아프다.

Wasm 모듈은 대개 훨씬 작고, 실행 환경이 이미 떠 있으면 새 인스턴스를 밀리초 안에 만들어낸다. 게다가 하나의 바이너리가 리눅스든 다른 OS든, x86이든 ARM이든 그대로 돈다. "빌드한 곳과 실행하는 곳이 달라도 된다"는 이식성은 엣지처럼 환경이 제각각인 곳에서 특히 값지다.

엣지 컴퓨팅의 요구를 떠올리면 이 궁합이 더 분명해진다. 엣지는 사용자 가까이에 흩어진 수많은 지점에서 짧은 처리를 순간순간 돌려야 한다. 여기에 무거운 컨테이너를 매번 띄웠다 내리는 건 비효율적이다. 반면 Wasm은 하나의 런타임 위에서 여러 모듈을 순식간에 갈아 끼울 수 있어, 요청이 들어올 때만 잠깐 실행하고 비우는 방식에 잘 맞는다. 사용량에 정직하게 비례하는 이 경제성이 서버리스·엣지에서 Wasm을 매력적으로 만든다.

격리와 WASI

기본이 차단인 보안 모델

Wasm의 보안은 발상이 뒤집혀 있다. 모듈은 기본적으로 아무것도 못 한다. 파일도, 네트워크도, 시스템 콜도 명시적으로 권한을 줘야만 접근한다. 이 "기본 차단" 모델은 신뢰할 수 없는 코드를 돌려야 하는 멀티테넌트 환경이나 플러그인 실행에 잘 어울린다.

WASI라는 다리

브라우저 밖에서 Wasm이 파일이나 네트워크에 접근하려면 표준 인터페이스가 필요하다. 그 역할을 WASI(WebAssembly System Interface)가 한다. WASI가 다듬어지면서 서버 사이드 Wasm이 실용 단계로 올라섰다. 아직 진화 중인 표준이라, 지원 범위는 계속 넓어지는 중이다.

컨테이너를 대체할까

당장은 아니라고 본다. 컨테이너 생태계는 방대하고 성숙했으며, 기존 애플리케이션을 그대로 담을 수 있다. Wasm은 아직 언어별 지원 편차가 크고, 시스템 자원에 깊이 의존하는 무거운 애플리케이션을 담기엔 이르다. 그래서 "컨테이너를 치운다"기보다 컨테이너가 약한 곳을 메운다가 더 정확한 그림이다.

서버리스 함수, 엣지의 짧은 처리, 신뢰 경계를 넘나드는 플러그인 실행—이런 곳에서 Wasm은 이미 강점을 보인다. 컨테이너 오케스트레이터가 Wasm 워크로드도 함께 돌리는 방향으로 접점이 늘고 있어, 앞으로는 둘을 대립이 아니라 조합으로 보는 쪽이 실용적이다.

자주 묻는 질문

Wasm은 브라우저 전용 아니었나요?

처음엔 그랬다. 웹에서 빠른 연산을 위해 만들어졌지만, 이식성과 격리라는 성질이 서버·엣지 요구와 맞아떨어지면서 브라우저 밖으로 영역을 넓혔다. WASI 같은 표준이 그 확장을 뒷받침한다.

어떤 언어로 Wasm을 만들 수 있나요?

여러 언어가 Wasm으로 컴파일된다. 시스템 프로그래밍 계열 언어의 지원이 앞서 있고, 다른 언어들도 점차 따라오는 중이다. 다만 언어마다 성숙도 차이가 있으니 실사용 전에 확인이 필요하다.

컨테이너와 같이 쓸 수 있나요?

그렇다. 컨테이너 런타임과 오케스트레이터가 Wasm 워크로드를 함께 다루는 방향으로 발전하고 있어, 한 클러스터에서 컨테이너와 Wasm을 섞어 운영하는 구성이 가능하다.