웹어셈블리가 컨테이너를 대체할 수 있을까?

웹의 네 번째 표준이라고 하는 웹어셈블리, 줄여서 와즘(Wasm)은 처음 만들어진 시점부터 논쟁을 불러일으켰다. 웹어셈블리는 어셈블리와 비슷한 프로그래밍 언어이자 컴팩트한 바이너리 형식이며 C, C++, C#, 고, 자바스크립트, 파이썬, 러스트 및 기타 언어의 컴파일 타겟으로 웹 브라우저에서 네이티브에 근접한 속도로 실행된다. 웹 개발에서 자리를 잡았고 브라우저를 벗어나 더 보편적인 사용에 조금씩 다가가는 중이다. 
 

ⓒ Getty Images Bank

개발자는 컴팩트함, 속도, 이식성, 보안을 갖춘 웹어셈블리가 클라이언트와 서버 영역에서 가진 잠재력에 주목했을 뿐만 아니라 리눅스 컨테이너를 대체할 가능성도 있다며 흥분했다. 과연 이 기술은 현재 확립된 컨테이너 생태계를 무너뜨리는 주류 플랫폼이 될 수 있을까? 

‘웹어셈블리 vs. 컨테이너’ 토론을 가까이 지켜봐온 사람들은 도커와 대거(Dagger)의 공동 설립자인 솔로몬 하이크스가 2019년에 올린 이후 온갖 자극적인 웹어셈블리에 대한 기사와 프레젠테이션 슬라이드에 인용된 이 트윗을 지겹도록 봤을 것이다. 
 

WASM+WASI가 2008년에 존재했다면 도커를 만들 필요가 없었을 것이다. 그만큼 중요한 기술이다. 서버의 웹어셈블리는 컴퓨팅의 미래다. 

그러나 악마는 디테일에 있다. 하이크스의 말은 그 당시 웹어셈블리가 있었더라면 도커와 같은 컨테이너의 필요성이 그다지 절실하지 않았을 것이란 의미다. 하지만 당시엔 웹어셈블리가 없었고 지금 우리는 도커 컨테이너가 지배하는 우주에 살고 있다. 미션 크리티컬 리눅스 기반 컨테이너를 대체하는 것은 간단한 일이 아니다. 하이크스는 다음과 같이 설명했다. 
 

저 트윗에 대해서 많은 사람이 오해했다. 이 말을 웹어셈블리가 도커 컨테이너를 대체할 것이라는 의미로 해석했다. 나는 그 당시 그렇게 될 것이라고 생각하지 않았다. 보다시피 그런 일은 일어나지 않았고 내 생각엔 앞으로도 일어나지 않을 것이다. 지금은 도커가 존재하고 표준이다. 웹어셈블리와 WASI는 훌륭하지만 매우 다르다. 도커의 대체재가 전혀 아니며 매우 다른 형태를 갖고 있다. 

웹어셈블리가 브라우저, 엣지 컴퓨팅 사용례, 샌드박스 플러그인과 특정 서버리스 기능에 있어 컨테이너보다 우수하다는 점에는 대부분 동의한다. 웹어셈블리가 갖게 될 혁신적인 잠재력에 대해 더 확신하는 사람도 있지만, 웹어셈블리가 장기적으로 서버측 컨테이너 또는 상태 유지(stateful) 장기 실행 서버 프로세스를 대체할 것이라는 데 대한 전망은 엇갈린다. 지금부터 더 깊이 들어가서 웹어셈블리가 컨테이너보다 우수한 부분과 그렇지 않은 부분을 정확히 비교해 보자. 
 

웹어셈블리가 컨테이너보다 우수한 부분 

일부 개발자는 웹어셈블리가 다양한 애플리케이션, 특히 컨테이너를 사용하기에 불편한 부분에서 폭넓게 사용되는 것으로 본다. 페르미온(Fermyon) CEO 맷 부처는 “웹어셈블리는 대규모 클라우드 인프라 못지않게 임베디드 IT에서도 뛰어나다. 웹어셈블리는 서버리스 기능, IoT, 엣지 컴퓨팅, 플러그인 스타일 확장 메커니즘에 매우 뛰어난 기술”이라고 말했다. 

엣지 
웹어셈블리가 빛을 발하는 영역 중 하나는 엣지 컴퓨팅이다. 여기서는 특히 웹어셈블리의 가볍고 샌드박스적인 특성이 돋보인다. 세컨드 스테이트(Second State)와 클라우드 네이티브 컴퓨팅 재단의 와즘엣지(WasmEdge) 프로젝트를 처음 시작한 마이클 J. 유안은 “엣지에 소프트웨어 격리가 필요하지만 컨테이너는 리소스를 과도하게 소비한다. 컨테이너가 ‘너무 무거워서’ 적합하지 않은 소프트웨어를 격리하고 관리하는 데 웹어셈블리를 사용할 수 있다”라고 말했다. 

컨테이너가 메가바이트 또는 기가바이트 단위의 공간을 점유하는 반면, 웹어셈블리 모듈은 킬로바이트 또는 메가바이트 단위의 공간만 점유한다. 코스모닉(Cosmonic)의 CTO 베일리 헤이즈는 .wasm 파일이 컨테이너에 비해 작고 런타임을 가리지 않는다면서 “웹어셈블리는 이식성이 있어 클라우드, 엣지는 물론 리소스가 제한된 디바이스와 같은 여러 이질적 환경에 걸쳐 워크로드를 실행할 수 있다”라고 설명했다. 

이런 특성 덕분에 웹어셈블리는 소형 임베디드 디바이스와 같은 제약이 있는 사용례에 적합하다. 특히 잘 맞는 시나리오 중 하나는 제조 IoT다. 예를 들어 머신메트릭스(MachineMetrics)는 공장에 와즘클라우드(wasmCloud)를 설치해서 장비 데이터를 더 안전하고 효율적으로 처리한다. 

성능이 중요한 워크로드 
웹어셈블리는 서버리스 기능 및 특정 AI 애플리케이션을 포함한 성능이 중요한 워크로드에서 명확한 역할이 있다. 패스틀리(Fastly)의 엔지니어 루크 와그너는 “웹어셈블리가 가장 적합하거나 컨테이너보다 유리한 애플리케이션이 있다. 웹어셈블리는 서버리스 스타일의 워크로드에서 비용을 절감하고 콜드 스타트 성능을 개선한다. 웹어셈블리는 현재의 사유 서버리스 솔루션에 종속되기를 원하지 않는 기업에 매력적일 것”이라고 말했다. 

AI 영역에서 웹어셈블리는 이기종 디바이스에서의 크로스 플랫폼 추론에 이상적이다. 유안은 컨테이너는 매우 무겁고 GPU 간 이식이 불가능하기 때문에 LLM을 위한 웹어셈블리 기반 로컬 런타임 및 API 서버인 라마엣지(LlamaEdge)와 같은 애플리케이션에는 적합하지 않다고 말했다. 

컴포넌트 기반 아키텍처 
바이트코드 얼라이언스(ByteCode Alliance)에서 제안한 사양인 WASI(WebAssembly System Interface)를 모듈형 컴포넌트 생태계를 위한 기반으로 보는 시각도 있다. 코스모닉의 헤이즈는 “크기와 속도 측면에서 웹어셈블리 컴포넌트의 강점을 활용하는 새로운 유형의 아키텍처가 발전하게 될 것”이라고 말했다. 헤이즈는 웹어셈블리의 작은 리소스 사용량, 런타임 독립성, 그리고 컨테이너에 비해 대기 시간을 훨씬 줄여주는 빠른 콜드 스타트를 강점으로 꼽았다. 

여기에 웹어셈블리의 기본 보안 설정까지 추가되면 컨테이너보다 훨씬 더 유리해진다. 헤이즈는 “안전한 샌드박싱과 임의의 사용자 코드 격리 측면에서 컨테이너는 일반적으로 적절한 선택으로 간주되지 않는다”라고 언급했다. 

패스틀리의 와그너는 “앞으로 많은 워크로드가 컨테이너에서 웹어셈블리로 마이그레이션될 것”이라고 예상했다. 이 현상은 특히 그린필드 워크로드에 해당하는데, 이미 일부에서 실제로 일어나고 있다. 와그너는 “웹어셈블리 컴포넌트 모델을 중심으로 한 현재의 표준화 노력에 따라 기업은 서비스를 모듈화하고 기존 마이크로서비스 아키텍처의 오버헤드를 피하기 위한 방편으로 웹어셈블리를 선택할 것”이라고 전망했다. 

일부 주장대로 컴포넌트 기반 아키텍처가 지배적인 개발 패러다임이 된다면 컨테이너의 역할은 줄어들 수 있다. 페르미온의 부처는 “웹어셈블리는 각각 자체적인 샌드박스에 격리된 어셈블리 컴포넌트로 애플리케이션을 구축하는 새로운 방법을 제시한다. 웹어셈블리가 컨테이너의 기능을 모두 대체하지는 않겠지만, 컨테이너는 컴포넌트 기반 애플리케이션에 아무런 가치를 더하지 않기 때문에 기술의 성숙도가 높아짐에 따라 웹어셈블리가 컨테이너를 대체할 가능성은 확실히 있다”라고 설명했다.  

서버측 앱을 위한 플러그인 
유안은 기존 시스템을 위한 플러그인은 웹어셈블리의 또 다른 유력한 사용례라고 말했다. 하이크스 역시 서버측 애플리케이션을 위한 고도로 샌드박싱된 플러그인에 웹어셈블리가 잘 맞는다고 본다. 실제로 이스티오 WasmPlugins(Istio WasmPlugins), 쇼피파이 펑션(Shopify Functions), 엔보이(Envoy) 확장과 같은 플러그인 프레임워크의 개발자들은 이미 웹어셈블리를 채택했다. 또한 시장에는 이런 플러그인을 손쉽게 만들고 실행할 수 있게 해주는 몇몇 프레임워크가 나와 있다. 

웹 앱과 서비스 
물론 브라우저 기반 웹 애플리케이션은 웹어셈블리의 주 영역이다. 또한 컨테이너가 제대로 진입하지 못하는 영역이기도 하다. 브라우저의 웹어셈블리는 잘 정립돼 있고 지원도 잘 되므로 진입 장벽이 훨씬 더 낮고 따라서 이미 수많은 고성능 웹 앱이 웹어셈블리를 기반으로 실행되고 있다. 

예를 들어 어도비는 포토샵, 익스프레스, 라이트룸, 아크로뱃 및 기타 애플리케이션의 웹 기반 버전에 적극적으로 웹어셈블리를 통합하고 있다. 어도비의 선임 소프트웨어 엔지니어인 콜린 머피는 “웹어셈블리는 수명이 짧은 프로그램을 매우 빠르고 효율적으로, 안전하게 실행되도록 설계됐다. 성숙도가 높아짐에 따라 웹 서비스 등 다른 컴퓨팅 영역에서의 적용 가능성도 계속 확대될 것”이라고 설명했다. 

하이크스는 “브라우저의 웹어셈블리가 마침내 제대로 힘을 받고 있다. 결국 주류가 될 것이라고 생각한다”라고 예상했다. 하이크스는 대거의 백엔드 엔지니어가 고 언어로 프론트 엔드 코드를 작성해서 웹어셈블리로 컴파일하고 있다면서 “백엔드 엔지니어는 프론트 엔드 개발을 할 수 없기 때문에 일반적으로 영향력이 없다. 웹어셈블리는 백엔드 엔지니어에게 영향력을 부여하는 방법”이라고 말했다. 
 

컨테이너가 웹어셈블리보다 유리한 경우 

물론 컨테이너가 앞으로도 계속 우위를 점할 영역도 존재한다. 코스모닉의 헤이즈는 “상태 유지 장기 실행 컴퓨팅, 그리고 데이터베이스와 같은 어플라이언스는 웹어셈블리로 대체될 가능성이 낮다”라고 강조했다.

컨테이너가 가상 머신을 완전히 대체하지는 않은 것과 마찬가지로 웹어셈블리를 향한 진화도 적당한 선에서 균형을 이룰 것이다. 부처는 “웹어셈블리가 컨테이너를 완전히 몰아낼 것이라는 결론은 지나치게 단순화된 생각”이라고 말했다. 즉, 웹어셈블리 앱은 쿠버네티스의 컨테이너에서 이미 실행 중인 수많은 앱과 공존하게 될 가능성이 높다. 

대규모 서버 프로세스 
부처는 “웹어셈블리는 장기 실행 서버 프로세스에는 적합하지 않다. 컨테이너가 가장 적합한 분야는 기존 장기 실행 서버(예 : 포스트그레스, 워드프레스, 또는 엔터프라이즈 자바 앱)의 패키징과 실행인데, 웹어셈블리가 향후 10년 이내에 이 분야에 도전하게 될 가능성은 높지 않다”면서 그 이유로 스레드의 부재, 빈약한 소켓 지원, 지원되는 언어 중 다수가 웹어셈블리에 최적화되지 않았다는 점을 들었다. 

패스틀리의 와그너는 아직 웹어셈블리에서 지원하지 않는 특정 OS 또는 CPU의 기능에 의존하는 컨테이너화된 워크로드는 웹어셈블리로 쉽게 대체할 수 없다고 말했다. 워크로드가 웹어셈블리를 완전히 지원하지 않는 언어를 사용하는 경우도 마찬가지다. 다만 와그너는 웹어셈블리 생태계가 성숙해짐에 따라 이런 우려는 사라질 것으로 봤다. 

이 부분에 대한 전망은 엇갈린다. 부처는 “웹어셈블리의 보안 모델은 서버 애플리케이션이 액세스하는 많은 저수준 운영체제 프리미티브에 대한 액세스를 허용하지 않는다. 향후 이런 특성이 바뀔 것이라고 기대할 이유도 없다. 대규모 코드 베이스 대부분은 웹어셈블리로 컴파일할 수 없기 때문에 코드를 다시 써야 한다. 이를 일시적 상황으로 보는 시각도 있지만 나는 그렇게 생각하지 않는다”라고 역설했다. 

컨테이너를 대체할 것이라는 차세대 클라우드 플랫폼의 대표 주자인 클라우드플레어(Cloudflare)조차 자체 워커(Workers) 플랫폼의 중심에 컨테이너를 사용한다. 클라우드플레어는 블로그에서 “워커 AI로 GPU에서 AI 추론을 사용하거나 브라우저 렌더링(Browser Rendering)으로 헤드리스 브라우저를 구동하거나 새로운 워커 빌드(Workers Builds)로 빌드 작업을 큐에 추가한 적이 있다면 본인도 모르는 사이에 이미 네트워크에서 컨테이너를 실행한 것”이라고 설명했다. 

핵심은 컨테이너가 다른 개발 접근 방식을 보완하면서 공존한다는 것이다. 아마 앞으로도 마찬가지일 것이다. 

리눅스 기반 클라우드 네이티브 시스템 
리눅스는 광범위하게 사용되며, 컨테이너는 이 리눅스의 본질적인 요소다. 즉, 대체하기가 거의 불가능하다. 하이크스는 “컨테이너 대체를 논하려면 리눅스 대체에 대해 논해야 한다”라고 언급했다. 

하이크스는 “현재 컨테이너는 리눅스의 핵심 기능이다. 커널뿐만 아니라 OS 계층, 이를 둘러싼 표준 스택, 클라우드의 데이터센터에서 리눅스를 실행하는 표준 방식도 마찬가지다. 컨테이너는 앞으로도 존재할 것이다. 유일한 질문은 그 위에 계층을 추가할 것인지 여부”라고 말했다. 

물론 컨테이너에서 웹어셈블리 컴포넌트를 호스팅할 수는 있지만 웹어셈블리가 지금의 리눅스처럼 서버를 지배하는 범용 플랫폼이 되는 모습을 상상하기는 어렵다. 하이크스는 “현재로서는 그렇게 될 가능성이 없다. 새로운 플랫폼으로 대대적으로 전환할 만한 확실한 이유가 없기 때문”이라고 강조했다. 

다른 사람도 현재의 컨테이너 스택을 전면적으로 대체할 만한 가치가 없다는 데 동의했다. 세컨드 스테이트의 유안은 “현재 대부분 클라우드 네이티브 애플리케이션에서는 리눅스 컨테이너가 적합한 툴이며, 이를 대체해서는 안 된다고 생각한다. 웹어셈블리는 격리가 필요하지만 컨테이너로는 처리할 수 없는 새로운 사용례를 위한 것”이라고 설명했다. 

실행 시간을 최소화해야 하는 상황에서는 웹어셈블리가 적합하지 않다. 패스틀리의 와그너는 “또한 일반적으로 웹어셈블리는 네이티브 코드에 비해 얼마간의 런타임 오버헤드가 있는데, 경우에 따라 오버헤드가 전혀 허용되지 않는 워크로드도 있다. 이와 같은 상황에서는 웹어셈블리가 컨테이너를 대체하지 않을 것”이라고 덧붙였다. 
 

웹어셈블리와 컨테이너의 역할 분담

쿠버네티스는 클라우드 인프라의 미래와 불가분의 관계에 있는 것으로 보인다. 웹어셈블리가 2030년까지 컨테이너 기반 런타임을 대체할 수 있다는 예측도 일부 있지만, 이에 동의하지 않는 사람이 많다. 이들은 웹어셈블리가 현재의 컨테이너 패러다임을 대체하는 것이 아니라 이 구조 안으로 들어가고 있다고 본다. 

유안은 웹어셈블리가 컨테이너를 대체하기는 어려우며 웹어셈블리는 보완 기술이라는 입장이다. 실제로 바이트코드 얼라이언스와 CNCF는 예를 들어 컨테이너와 웹어셈블리 모듈을 동일한 클러스터에서 함께 실행할 수 있게 해주는 프로젝트를 개발함으로써 웹어셈블리가 쿠버네티스를 보완하도록 하는 부분에서 성과를 내고 있다. 

미래에는 도커가 리눅스 컨테이너, 윈도우 컨테이너, 웹어셈블리 컨테이너를 나란히 실행하게 될 것이라는 예상도 있다. 하이크스는 이것이 현실성 있는 모델이라고 생각하지만 수요가 낮다는 점은 인정했다. 하이크스는 그 이유 중 하나로 서버에서 웹어셈블리가 폭넓게 채택되지 않은 점을 지적했다. 즉, 여전히 틈새 사용례에 머물러 있다. 

하이크스는 “대대적인 확산을 위해서는 주류 사용례, 모든 사람이 서버에서 이를 사용할 만한 이유, 그리고 손쉽게 사용할 수 있는 방법이 필요하다. 새로운 플랫폼을 채택하도록 하는 것은 정말 어려운 일이다. 사용례가 있어야 한다”라고 강조했다.
 

새로운 시장과 혁신의 가능성 

장기적으로는 웹어셈블리를 통해 완전히 새로운 시장과 컴퓨팅 패러다임이 가능해질 가능성이 높다. 어도비의 머피는 “WASI를 통해 실현되는 이식성과 구성 가능성의 혁신에 따라 데이터센터와 엣지 컴퓨팅, 모바일, IoT 간의 많은 사일로가 허물어질 것”이라고 말했다. 

웹어셈블리는 여기서 다룬 애플리케이션 외에도 많은 분야에 사용된다. 코스모닉의 헤이즈는 “은행, 제조, 통신, 디지털 서비스, 게임을 비롯한 광범위한 사용례에서 와즘클라우드가 도입되고 있다”라고 말했다. 예를 들어 TM 포럼(TM Forum)의 웹어셈블리 캔버스 카탈리스트(WebAssembly Canvas Catalyst) 팀은 와즘클라우드를 사용해서 쿠버네티스를 대체해 개방형 API를 관리하는 개념 증명을 시연했다. 

리팩터링에는 작업이 필요하겠지만 컨테이너 시대에는 필요하지 않았던 효율성 향상을 이룰 수 있다. 머피는 “도커와 쿠버네티스는 많은 측면에서 혁신적이었다. 이를 활용하도록 애플리케이션을 리팩터링한다면 아주 좋을 것이다. 그러나 대부분 경우 애플리케이션은 최소한의 리팩터링으로 단순히 컨테이너화되었을 뿐”이라고 말했다. 이는 일반적으로 느린 시작 시간과 높은 메모리 요구사항으로 이어진다. 

미래는 어떻게 될까? 점점 더 많은 그린필드 애플리케이션에서 더 작고 더 빠른 웹어셈블리가 컨테이너를 밀어내게 될 것이다. 그러나 기존 컨테이너 생태계를 전면적으로 대체한다는 것은 현실적이지 않은 생각이다. 웹어셈블리와 컨테이너 모두 클라우드와 엔터프라이즈 컴퓨팅에서 앞으로도 계속 중요한 역할을 할 것이다. 
editor@itworld.co.kr