쿠버네티스에서 웹어셈블리(WebAssembly) 실행하기 — 2MB 컨테이너 실험과 런타임 관리의 위험

핵심 메시지

• 웹어셈블리는 2018년만 해도 브라우저 성능을 높이는 기술로 소개됐지만, 지금은 서버와 클라우드까지 포함하는 실행 방식으로 범위가 넓어졌다.
• 같은 러스트 소스로 세 가지 컨테이너를 만들어 비교한 결과, 네이티브 12MB, 런타임을 품은 이미지 8MB, 웹어셈블리만 담은 이미지는 2MB였다.
• 쿠버네티스는 컨테이너를 직접 실행하지 않고 중간 단계에 넘기는데, 이 중간 단계를 웹어셈블리 실행기로 바꾸면 2MB 이미지도 그대로 뜬다.
• 발표자는 웹어셈블리가 원래 못 한다고 알려진 포트 열기를 라이브러리를 손봐 가며 해냈고, 실제로 HTTP 요청에 응답하는 서버를 띄워 보였다.
• 그러나 선택한 실행기는 갱신이 멈춘 상태였고, 반년 전 잘 돌던 예제가 발표 준비 중 깨지는 일까지 겪었다.

쉽게 이해하기

발표자는 시작부터 선을 긋는다. 자신은 이 주제의 전문가가 아니며 탐색해 본 결과를 공유하는 것이니, 회사에 돌아가 "어떤 발표자가 이렇게 하라더라"고 옮기지는 말라는 것이다. 실제로 발표 내용은 성공담이 아니라 실험 기록에 가깝다.

그는 웹어셈블리를 장님과 코끼리 이야기에 빗댄다. 어느 부분을 만졌느냐에 따라 머릿속 그림이 전혀 달라지기 때문이다. 2018년 공식 사이트는 웹으로의 컴파일을 내세웠고, 자바스크립트가 감당하기 버거운 계산을 대신하는 용도로 소개됐다. 발표자가 예로 든 생명 게임 시연에서도 화면 갱신과 계산은 웹어셈블리가, 버튼 조작은 자바스크립트가 맡는다.

몇 해 지나지 않아 설명이 바뀌었다. 스택 기반 가상 머신이라는 표현이 등장하고, 클라이언트뿐 아니라 서버 애플리케이션까지 명시된다. 쓰임새도 달라졌다. 팀마다 다른 언어를 쓰면서 결과물은 하나로 모으는 다국어 개발, 사용자가 플랫폼을 안전하게 확장하도록 권한을 제한하면서 성능은 지키는 방식, 그리고 작은 실행 파일이 필요한 함수 단위 서비스가 대표적이다.

시연의 핵심은 컨테이너 크기다. 발표자는 같은 소스에서 컴파일 시점 표시만 바꿔 세 종류를 만들었다. 러스트 개발자들이 흔히 쓰는 아주 작은 기반 이미지로 만든 네이티브가 12MB, 웹어셈블리 실행기를 기반 이미지로 삼은 것이 8MB, 아무것도 없는 빈 이미지에 웹어셈블리 파일만 넣은 것이 2MB였다. 다만 이 2MB짜리는 도커에서 실행되지 않았다. 반년 전에는 됐는데 이제는 안 된다고 그는 담담히 말한다.

쿠버네티스에서는 이야기가 달라진다. 컨테이너 실행은 여러 단계를 거쳐 최종 실행기로 넘어가는데, 설정 파일에 두 줄을 더해 웹어셈블리 실행기로 넘기도록 지정하면 된다. 다만 그 실행기는 내려받을 수 있는 파일이 없어 노드에서 직접 빌드해야 했다. 이 과정을 마친 뒤 발표자는 2MB 컨테이너로 뜬 HTTP 서버가 네이티브와 똑같은 응답을 돌려주는 장면을 보여 준다.

주요 인사이트

• 웹어셈블리는 원래 포트를 열거나 네트워크를 다루지 않는다. 발표자는 이 제약을 우회하려고 사용하는 라이브러리의 소스를 받아 고쳐 쓰는 방식을 택했는데, 이는 러스트가 의존성을 소스로 받아 직접 컴파일하기 때문에 가능한 방법이었다.
• 비동기 처리를 지원하지 않아 모든 작업을 한 스레드에서 돌려야 했다는 점도 실제 서버를 얹을 때 걸림돌이 될 수 있는 제약이다.
• 용량 이야기와 성능 이야기는 다르다. 발표자는 2MB라는 숫자를 앞세우면서도 성능에 대해 말하는 것이 아니라 오직 용량 이야기라고 분명히 선을 그었다.
• 가장 뼈아픈 대목은 도구의 수명이다. 그가 고른 실행기는 마지막 변경이 한참 전에 멈춰 있었고, 손대지 않은 예제가 갑자기 깨져 라이브러리 판을 되돌려야 했다. 원인도 끝내 알아내지 못했다고 한다.
• 결론은 상황에 따라 갈린다. 이 기술로 경쟁 우위를 만들 수 있는 신생 기업이라면 뛰어들 만하지만, 전통적인 조직이라면 되돌리는 비용까지 감안했을 때 아직은 위험이 크다는 것이 발표자의 판단이다.

자주 묻는 질문

관련 AI 소식