# 서버 사이드 WebAssembly가 가져올 변화
서버 사이드 WebAssembly는 컨테이너의 무거운 가상화를 샌드박싱으로 대체하며 배포와 실행의 근본 구조를 바꾸고 있다. Docker가 OS 수준의 격리를 통해 이식성을 확보했다면, Wasm은 바이트코드 수준의 보안과 밀리초 단위 시작 시간으로 서버리스와 엣지 컴퓨팅의 한계를 돌파한다.
## 컨테이너 패러다임의 한계
Docker는 2013년 등장 이후 배포 환경의 표준이 되었다. "Build once, run anywhere"라는 명제는 개발자를 OS 종속성에서 해방시켰고, 마이크로서비스 아키텍처의 물리적 기반이 되었다.
그러나 컨테이너는 본질적으로 OS 수준의 가상화다. 각 컨테이너는 독립된 파일시스템과 네트워크 스택, 프로세스 공간을 갖는다. 격리는 보장되지만, 수백 메가바이트의 이미지 크기와 수 초의 시작 시간이라는 오버헤드가 따라온다. Alpine Linux 기반 이미지가 인기를 얻은 이유는 이 무게를 견디기 어려웠기 때문이다.
더 근본적인 문제는 격리의 단위에 있다. Docker는 애플리케이션을 격리하기 위해 OS 커널의 네임스페이스와 cgroup을 사용한다. 이는 프로세스 간 격리에는 효과적이지만, 함수 수준이나 요청 수준의 세밀한 격리에는 과도하다. AWS Lambda가 warm start와 cold start의 딜레마를 겪는 것도 이 구조적 한계 때문이다.
보안 측면에서도 완전하지 않다. 커널을 공유하는 구조상 커널 취약점은 모든 컨테이너에 영향을 미친다. gVisor나 Kata Containers 같은 샌드박싱 기술이 등장한 것은 이 불안을 해소하기 위함이다. 그러나 이들 솔루션은 다시 성능 오버헤드를 증가시킨다.
## WebAssembly의 설계 철학
WebAssembly는 2015년 브라우저에서 네이티브 수준의 성능을 구현하기 위해 설계되었다. 초기 목표는 명확했다. JavaScript의 성능 한계를 넘어서되, 브라우저의 보안 모델을 훼손하지 않는 것. 이를 위해 Wasm은 능력 기반 보안 모델을 채택했다.
Wasm 모듈은 기본적으로 아무것도 할 수 없다. 파일시스템 접근도, 네트워크 호출도, 심지어 난수 생성도 불가능하다. 모든 권한은 명시적으로 부여되어야 한다. Docker가 "기본적으로 모든 것을 허용하되, 명시적으로 제한"하는 방식이라면, Wasm은 "기본적으로 모든 것을 차단하되, 명시적으로 허용"하는 방식이다.
이 철학은 WASI(WebAssembly System Interface)의 설계에서 구체화된다. WASI는 Wasm 모듈이 OS 자원에 접근하기 위한 표준 인터페이스다. 중요한 것은 이 인터페이스가 OS에 독립적이라는 점이다. POSIX나 Win32 API처럼 특정 OS의 구조를 반영하지 않는다.
결과적으로 Wasm 바이너리는 진정한 의미의 이식성을 획득한다. x86 리눅스에서 컴파일된 Wasm 모듈은 ARM macOS에서, Windows에서, 심지어 브라우저에서도 동일하게 실행된다. 재컴파일이나 재빌드 없이. JVM이라는 거대한 런타임도, 플랫폼별 네이티브 라이브러리 의존성도 필요 없다.
## 서버 환경에서의 기술적 우위
서버 환경에서 Wasm의 강점은 세 가지로 수렴한다. 시작 시간, 자원 효율성, 보안 격리.
Wasmtime이나 WasmEdge 같은 런타임은 Wasm 모듈을 1밀리초 이하로 시작할 수 있다. Docker 컨테이너의 수 초와 비교하면 세 자릿수 차이다. 이는 단순한 속도 개선이 아니다. 컨테이너는 장시간 실행되는 프로세스를 전제하지만, Wasm은 요청당 인스턴스를 띄우고 버리는 것이 가능하다. 상태를 공유하지 않는 순수한 함수형 실행 모델이 현실화된다.
메모리 오버헤드도 극적으로 줄어든다. 전형적인 Node.js Docker 이미지가 수백 메가바이트라면, 동일한 로직의 Wasm 모듈은 수 메가바이트에 불과하다. OS 레이어가 없고, 런타임 라이브러리가 정적으로 링크되기 때문이다. Fastly의 Compute@Edge는 이를 활용해 엣지 노드에서 수천 개의 Wasm 인스턴스를 동시 실행한다.
보안 격리는 하드웨어 수준에서 보장된다. Wasm은 선형 메모리 모델을 사용하며, 모든 메모리 접근은 경계 검사를 거친다. 버퍼 오버플로우나 메모리 손상 공격이 원천적으로 차단된다. Cloudflare Workers는 단일 프로세스에서 수백만 사용자의 코드를 격리 실행한다. Docker로는 불가능한 밀도다.
## 개발 워크플로우의 변화
Docker 중심의 개발 패턴은 표준화되었지만 복잡하다. Dockerfile 작성, 이미지 빌드, 레지스트리 푸시, 오케스트레이션 배포. 멀티스테이지 빌드, 레이어 캐싱, 이미지 최적화 등 Docker 자체를 이해하는 데 상당한 학습 비용이 든다.
Wasm 기반 워크플로우는 이를 단순화한다. 소스 코드를 Wasm 타겟으로 컴파일하면 끝이다. Rust라면 `cargo build --target wasm32-wasi`, Go는 `GOOS=wasip1 GOARCH=wasm go build`. 생성된 `.wasm` 파일 하나가 배포 단위다.
로컬 개발 환경도 간결해진다. Docker Desktop을 설치하고 Docker Compose를 구성하는 대신, Wasmtime 바이너리 하나면 충분하다. `wasmtime run app.wasm` 명령으로 즉시 실행된다. 개발자가 macOS에서 작성한 코드가 리눅스 서버에서 동일하게 작동한다는 것은 이제 약속이 아닌 설계적 필연이다.
디버깅도 달라진다. Wasm은 명확한 인터페이스 경계를 갖는다. 모듈이 호출할 수 있는 함수, 접근할 수 있는 메모리가 명시적이다. 컨테이너 내부에 접속해 로그를 뒤지는 대신, 런타임 레벨에서 모든 호출을 추적할 수 있다.
다만 Wasm 생태계는 아직 성숙하지 않았다. 모든 언어가 Wasm 타겟을 완전히 지원하지 않으며, 특히 동적 언어의 지원은 제한적이다. Python의 경우 CPython을 Wasm으로 컴파일할 수 있지만, C 확장 모듈은 대부분 작동하지 않는다.
## 엣지 컴퓨팅과 서버리스의 새로운 가능성
Wasm의 진가는 엣지와 서버리스 환경에서 드러난다. CDN 노드에서 동적 로직을 실행하는 엣지 컴퓨팅은 지연 시간을 극소화하지만, 자원 제약이 심하다. Docker 컨테이너는 이 환경에 적합하지 않다.
Cloudflare Workers는 V8 엔진 위에서 Wasm을 실행한다. 전 세계 수백 개 데이터센터에서 사용자 요청을 5밀리초 이내에 처리한다. cold start가 없다. 모든 요청이 새로운 격리 환경에서 실행되지만, 시작 시간이 1밀리초 이하이기에 문제가 되지 않는다.
Fastly의 Compute@Edge는 더 나아간다. Wasm 모듈을 150개 이상의 엣지 노드에 즉시 배포하며, 각 노드는 수만 개의 동시 요청을 처리한다. 배포 시간은 수 초다. 이미지를 빌드하고 레지스트리에 푸시하고 클러스터에 전파하는 과정이 사라졌기 때문이다.
서버리스 플랫폼도 Wasm으로 재설계되고 있다. Fermyon의 Spin은 Wasm 기반 서버리스 프레임워크다. 함수를 Wasm으로 컴파일하면, Spin 런타임이 HTTP 트리거, 데이터베이스 연결, 메시지 큐 등을 자동 처리한다. 개발자는 비즈니스 로직만 작성한다.
이는 서버리스의 원래 약속을 실현한다. "서버를 생각하지 말라"는 명제는 Docker 시대에도 완전히 달성되지 못했다. 컨테이너 이미지를 최적화하고, cold start를 줄이고, 메모리 제한을 조정하는 것은 여전히 서버를 생각하는 행위다. Wasm은 이 레이어를 추상화한다.
## 전환의 시점
Wasm이 모든 것을 대체하지는 않는다. 장시간 실행되는 상태 유지 애플리케이션, 복잡한 OS 의존성을 갖는 레거시 시스템, 고도로 최적화된 네이티브 성능이 필요한 영역에서는 Docker나 베어메탈이 여전히 유효하다.
그러나 마이크로서비스의 상당 부분, 특히 API 게이트웨이, 인증 레이어, 데이터 변환 함수, 비즈니스 로직 처리 등 상태 없는 요청-응답 패턴은 Wasm으로 전환 가능하다. 이들은 전체 워크로드의 70% 이상을 차지한다.
언어 생태계도 빠르게 성숙하고 있다. Rust는 Wasm 퍼스트 클래스 타겟이며, Go 1.21부터 WASI 지원이 공식화되었다. C/C++는 Emscripten을 통해 안정적으로 컴파일되고, .NET도 Blazor WebAssembly로 Wasm을 지원한다.
도구 체인도 정비되고 있다. `wasm-pack`은 Rust Wasm 프로젝트를 패키징하고, `wasmtime`과 `wasmer`는 프로덕션급 런타임을 제공한다. Kubernetes도 Wasm을 인식하기 시작했다. runwasi 프로젝트는 containerd에서 Wasm 컨테이너를 실행 가능하게 한다. Docker와 Wasm이 공존하는 과도기적 아키텍처가 가능해진다.
## 설계의 본질로
Docker는 "서버를 코드로 관리한다"는 Infrastructure as Code의 물리적 구현이었다. Dockerfile은 서버 설정의 버전 관리를 가능하게 했고, 이미지는 불변 배포의 기반이 되었다. 그러나 이 과정에서 우리는 새로운 복잡성을 받아들였다.
Wasm은 더 근본적인 질문을 던진다. 애플리케이션을 실행하기 위해 정말 OS가 필요한가? 격리를 위해 커널 네임스페이스가 필수인가? 배포 단위는 왜 수백 메가바이트여야 하는가?
이 질문들은 기술적 효율성을 넘어선다. 필요한 것만 남기고, 불필요한 레이어를 제거하고, 인터페이스를 명확히 하는 것. Wasm의 능력 기반 보안 모델, 선형 메모리 구조, 명시적 인터페이스 정의는 이 철학의 구체화다.
개발자는 이제 선택할 수 있다. 무거운 가상화와 완전한 OS 환경이 필요한 워크로드에는 Docker를, 순수한 계산과 빠른 시작이 중요한 워크로드에는 Wasm을. 이 선택은 도구의 선호가 아닌, 문제의 본질에 대한 이해에서 비롯되어야 한다.
서버 사이드 WebAssembly는 아직 완성되지 않았다. 그러나 방향은 명확하다. Docker가 가져온 이식성의 약속을 바이트코드 수준에서 완성하는 것. 배포와 실행에 대한 사유의 근본적 전환은 이미 시작되었다.
2
조회수
0
좋아요
