WebAssembly는 컨테이너를 대체할까? WASI·컴포넌트·격리의 경계

비교의 출발점은 배포 파일보다 실행 경계다

사용자가 만든 변환 함수를 서비스 안에서 실행하는 경우를 생각해 보자. 함수에는 입력 문서를 처리할 권한은 필요하지만 호스트의 모든 파일을 읽거나 임의의 네트워크로 전송할 권한까지 필요하지는 않다. 작은 실행 단위와 제한된 호스트 기능이 중요해지는 상황이다.

반대로 기존 리눅스 서비스가 여러 시스템 라이브러리, 셸 도구, 네이티브 확장과 운영 에이전트에 의존한다면 질문이 달라진다. 실행 파일을 작게 만드는 것보다 기존 프로그램의 동작과 관측 체계를 유지하는 일이 먼저일 수 있다.

이 두 사례를 “Wasm과 컨테이너 중 무엇이 더 빠른가”로 합치면 비교 조건이 사라진다. 어떤 코드를 실행하고, 어떤 기능을 허용하며, 어디에서 격리할 것인지부터 정해야 한다. 아래 분석은 특정 런타임의 성능 순위가 아니라 그 경계를 고르는 기준이다.

Wasm, WASI, 컴포넌트는 같은 이름의 다른 버전이 아니다

WebAssembly의 코어 모듈은 런타임이 검증하고 실행할 수 있는 코드와 타입·메모리 등의 구조를 담는다. 모듈이 외부 기능을 사용하려면 호스트가 제공하는 함수 등을 가져와야 한다. 브라우저 밖에서도 실행할 수 있지만, 그 사실만으로 모든 운영체제 기능이 기본 제공되는 것은 아니다.

WASI는 브라우저 밖의 Wasm 프로그램이 파일·입출력 등 외부 기능과 만나는 인터페이스 계열이다. 필요한 인터페이스가 컴파일 도구와 런타임에 구현돼 있어야 실제로 동작한다. “Wasm으로 컴파일된다”와 “배포 대상에서 필요한 기능이 모두 동작한다”는 별도의 확인 항목이다.

컴포넌트 모델은 서로 다른 언어로 만든 코드를 더 풍부한 인터페이스로 조합하려는 층이다. Bytecode Alliance의 설명은 코어 모듈의 낮은 수준 타입만으로 구성 요소를 연결할 때 생기는 부담을 다룬다. 컴포넌트는 그 위에 명시적인 계약을 둔다.

층	주로 정하는 것	자동으로 해결하지 않는 것
Wasm 코어	코드 실행과 메모리 접근의 규칙	운영체제 전체 API와 서비스 권한
WASI 인터페이스	프로그램과 호스트 기능의 접점	모든 리눅스 프로그램의 무수정 호환
컴포넌트·WIT	구성 요소가 주고받는 타입과 기능	제품의 업무 의미와 무비용 데이터 전달
런타임·운영 환경	실제 실행·자원 제한·호스트 구현	잘못 부여한 권한의 자동 교정

각 층의 지원 상태는 도구와 버전별로 확인해야 한다. 한 인터페이스를 지원한다는 설명을 전체 생태계의 완전한 호환성으로 넓히면 이식 단계에서 예상 밖의 작업이 생긴다.

WIT는 언어 사이의 계약을 드러낸다

정수 두 개를 더하는 함수는 쉽게 연결할 수 있다. 하지만 문자열, 레코드, 오류, 오래 유지되는 자원 핸들을 주고받기 시작하면 메모리 표현과 소유권을 합의해야 한다. 한 언어의 포인터를 다른 언어가 같은 뜻으로 읽을 수 있다고 가정할 수 없기 때문이다.

WIT 문서는 인터페이스와 world를 통해 가져오고 내보내는 기능을 정의한다. 예를 들어 문서 변환 플러그인은 “문서 바이트를 받아 변환 결과 또는 오류를 돌려준다”는 계약을 노출하고, 파일 읽기나 로그 기록은 별도 가져오기 기능으로 선언할 수 있다.

이렇게 경계를 표현하면 구현 언어를 바꾸더라도 무엇을 연결해야 하는지 볼 수 있다. 그러나 바이트를 문자열로 바꾸고 메모리를 옮기는 비용이 없어지는 것은 아니다. 호출 횟수가 많거나 큰 데이터를 반복해서 건네면 인터페이스 설계 자체가 성능 문제로 이어질 수 있다.

따라서 컴포넌트를 지나치게 잘게 나누기 전에 호출 빈도·데이터 크기·오류 처리·자원 수명을 함께 본다. 함수 이름과 타입이 같아도 “빈 결과가 정상인가”, “실패 후 다시 호출해도 되는가” 같은 업무 의미는 별도 계약으로 남는다. 이는 MCP의 도구 계약 분석과도 이어지는 문제다.

샌드박스는 허용한 기능의 바깥을 제한한다

WebAssembly의 보안 설명은 샌드박스 실행과 메모리 범위 검사를 설명한다. 코어의 선형 메모리 범위를 벗어난 접근을 제한하는 것은 중요한 보호다. 다만 선형 메모리 안의 서로 다른 데이터 객체까지 언어 수준에서 모두 안전해진다는 뜻은 아니다. 메모리 안전성이 없는 언어로 작성된 코드의 내부 오류가 자동으로 사라지지는 않는다.

외부 시스템에 대한 보호는 호스트가 무엇을 내주었는지에 달린다. 파일 읽기 함수를 가져오게 해 주면서 모든 경로를 허용했다면, 모듈이 그 함수를 호출하는 것은 샌드박스를 탈출하지 않고도 가능한 동작이다. 권한이 넓은 호스트 API를 제공해 놓고 실행 형식만으로 안전하다고 말할 수 없다.

Wasmtime의 보안 문서는 WASI 파일시스템 접근에서 부여된 권한을 중심으로 경계를 다룬다. 실제 서비스에서는 허용 디렉터리뿐 아니라 네트워크 목적지, CPU 시간, 메모리 한도, 취소·시간 초과, 로그 노출도 함께 설계해야 한다. 이 가운데 지원 방식은 런타임별로 다르다.

런타임 자체의 취약점과 호스트 구현 오류도 신뢰 경계에 남는다. 강한 적대적 멀티테넌트 격리가 필요한 상황에서는 프로세스·컨테이너·가상머신을 함께 검토할 수 있다. 보호 수단을 여러 층으로 두는 선택과 Wasm의 실행 경계는 양립한다.

컨테이너가 제공하는 것은 다른 종류의 호환성이다

Docker의 컨테이너 개요는 컨테이너를 호스트 커널을 공유하는 격리된 프로세스로 설명한다. 애플리케이션과 사용자 공간 의존성을 묶어 배포할 수 있지만, 각 컨테이너에 독립된 운영체제 커널이 포함되는 것은 아니다.

기존 리눅스 실행 파일과 라이브러리를 유지해야 한다면 이 경계가 실용적일 수 있다. Wasm으로 옮기는 경우에는 사용 언어의 도구 지원뿐 아니라 시스템 호출, 동적 라이브러리, 스레드, 장치 접근, 디버깅 도구까지 필요한 범위를 확인해야 한다. 특정 기능이 지원돼도 배포 대상 모두에서 같은 조합으로 지원되는지는 다시 확인한다.

판단 축	Wasm을 먼저 검토할 조건	컨테이너를 먼저 검토할 조건
실행 단위	제한된 함수·플러그인·정의된 인터페이스	기존 서비스와 여러 OS 의존성
호스트 기능	작고 명시적인 기능 집합	넓은 리눅스 사용자 공간 호환
배포 대상	여러 호스트에서 같은 인터페이스 제공	이미 갖춘 컨테이너 운영 기반
운영 비용	런타임·언어 지원의 공통분모가 맞음	로그·진단·네이티브 도구 유지가 중요
검증 과제	호스트 권한·호출 경계·자원 한도	커널 공유·권한·이미지와 의존성 관리

이 표는 보편적인 우열표가 아니다. 컨테이너 안에서 Wasm 런타임을 실행하고, 그 안에 플러그인을 제한적으로 올리는 구성도 가능하다. 서비스 배포 경계와 플러그인 실행 경계를 다른 층에 두는 선택이다.

작은 파일이 짧은 첫 응답 시간을 보장하지는 않는다

콜드 스타트는 한 숫자로 말하기 쉽지만 여러 단계로 나뉜다. 아티팩트 내려받기, 검증과 컴파일, 인스턴스 초기화, 애플리케이션 데이터 준비, 외부 연결 수립, 실제 첫 요청 처리까지 무엇을 포함했는지 확인해야 한다.

컴파일된 코드가 캐시에 있는 경우와 처음 받는 경우, 빈 함수와 큰 데이터를 초기화하는 함수는 다르다. 네트워크 연결이나 외부 데이터베이스 응답이 대부분의 시간을 차지하면 실행 환경 초기화만 줄여도 사용자 체감 개선은 작을 수 있다.

메모리 사용량도 모듈 하나의 선형 메모리만 세면 비교가 어긋난다. 런타임, 컴파일 결과, 공유 캐시, 호스트 데이터와 동시 인스턴스까지 같은 범위로 측정해야 한다. 서로 다른 범위를 재고 “몇 배 가볍다”고 표현하면 운영 용량 계획에 쓸 수 없는 숫자가 된다.

도입 실험은 기능 호환성에서 시작한다

첫 실험으로 전체 서비스를 이식하기보다 경계가 분명한 한 기능을 고를 수 있다. 예를 들어 문서 형식 변환이나 사용자 정의 검증 함수는 입력·출력·허용 기능을 적기 쉽다. 반대로 기존 라이브러리와 호스트 기능이 얽힌 부분을 첫 사례로 삼으면 실행 모델과 이식 작업의 영향을 분리하기 어렵다.

1. 필요한 호스트 기능과 현재 의존성을 목록으로 만든다. 지원되지 않는 기능과 대체 비용을 먼저 찾는다.
2. 같은 입력·출력·오류 조건을 기존 구현과 Wasm 구현에 적용한다. 정상 결과뿐 아니라 큰 입력과 잘못된 입력도 확인한다.
3. 허용하지 않은 파일·네트워크 접근, 시간 초과, 메모리 소진에서 호스트가 어떻게 복구하는지 확인한다.
4. 캐시가 있는 경우와 없는 경우를 나눠 시작 지연·처리 지연·전체 메모리를 측정한다.
5. 배포·롤백·추적·장애 분석에 필요한 도구와 운영 작업 시간을 비교한다.

위 절차는 실행 결과가 아닌 평가 설계다. 통과 기준은 해당 서비스의 지연 목표와 보안 경계에 맞춰 정해야 한다. 이식 성공만으로 운영 전환을 결정하거나, 작은 벤치마크의 승리를 전체 서비스의 비용 절감으로 확대해서는 안 된다.

WebAssembly의 가능성은 모든 프로그램을 같은 형식으로 바꾸는 데만 있지 않다. 외부 코드가 실행되는 지점의 계약과 권한을 더 작고 명확하게 만들 수 있는지가 핵심 질문이다. 그 이득이 호환성·운영 비용보다 큰 구간부터 적용하면 컨테이너와의 관계도 경쟁 구호가 아닌 구체적인 설계 선택으로 바뀐다.