“컨테이너만으론 부족했다”: AI 에이전트 격리에서 Wasm와 마이크로VM이 뜨는 이유

Bro's Insights
1

도입

도구 호출형 AI 에이전트가 패키지를 설치하고, 서버를 띄우고, 파일시스템을 건드리는 코드를 대규모로 실행하기 시작하면서 “에이전트 코드를 어디서 돌릴 것인가?”가 인프라의 핵심 질문이 됐습니다. 이 글에서는 컨테이너 격리의 한계 위에서 Wasm(+WASI), gVisor, 마이크로VM(Kata/Firecracker) 이 각각 어떤 해법을 주는지, 그리고 무엇을 기본 표준으로 삼는 게 합리적인지 정리합니다.

왜 ‘컨테이너만으로는’ AI 에이전트 격리가 부족한가

컨테이너는 프로세스 격리(Namespaces, cgroups)와 정책(seccomp, AppArmor/SELinux)을 통해 꽤 강한 격리를 제공합니다. 하지만 보안 모델의 본질은 “커널 공유” 입니다. 즉, 컨테이너는 편리한 배포/격리 단위이지, 본질적으로 강한 보안 경계(security boundary) 로 설계된 것은 아니라는 지적이 반복됩니다(컨테이너 escape CVE가 꾸준히 나오는 이유이기도 합니다).

AI 에이전트 시나리오에서는 위협모델이 더 빡빡해집니다.

  • 실행 코드의 신뢰도가 낮습니다(에이전트 생성 코드, 외부 플러그인, 사용자 제공 스크립트 등).
  • 파일시스템/네트워크/비밀(Secrets)/호스트 리소스에 대한 접근 요구가 실제로 발생합니다.
  • “세션”이 짧고 대량일 수 있습니다(하루 수백만 실행 같은 그림).

그래서 결론이 “컨테이너를 더 하드닝하자”만으로 끝나지 않고, 격리 경계를 바꾸는 선택지(Wasm, 마이크로VM) 가 빠르게 부상합니다.

선택지 1: Wasm(+WASI) — ‘비즈니스 로직만’ 안전하게, 아주 작게

Wasm은 컨테이너처럼 “리눅스 유저랜드 전체”를 싣는 대신, 런타임이 제공하는 샌드박스 위에서 바이트코드를 실행합니다. 특히 WASI가 붙으면(정확히는 “호스트 기능을 어떤 인터페이스로 열어줄지”를 표준화하려는 흐름) 서버/엣지에서 쓸 수 있는 현실성이 올라갑니다.

대화에서 인상 깊었던 포인트는 이거였습니다.

  • Wasm(+WASI)은 “비즈니스 로직만” 담아 10MB 이하 단위로 배포할 수 있다.
  • CNCF 설문에선 조직의 31%가 특정 워크로드에서 Wasm을 컨테이너 대안으로 검토 중이다.

여기서 중요한 전제는 “플랫폼 관심사(관측, 네트워크, 스토리지, 권한)는 호스트/런타임이 안전하게 제공한다”입니다. 이 전제가 깨지는 순간(예: 복잡한 네이티브 의존성, 특정 커널 기능, GPU/드라이버 접근) Wasm은 급격히 불리해집니다.

제가 정리하는 Wasm의 강세 영역은 다음과 같습니다.

  • 서버리스/함수형 요청 처리: 빠른 cold start, 작은 아티팩트, 안전한 샌드박스
  • 엣지 컴퓨팅: 이식성, 작은 배포 단위
  • 플러그인 시스템: “사용자 코드”를 안전하게 실행해야 하는 구조(확장 기능, 정책 엔진, 필터 등)

반대로 대화에서도 짚었듯, “Wasm이 OCI/Docker/Kubernetes를 곧바로 대체한다”는 식의 주장에는 현실적인 반론이 있습니다. 예를 들어 vLLM 같은 무거운 AI 서빙은 GPU, 드라이버, 네이티브 라이브러리 의존성 때문에 당장 Wasm로 자연스럽게 옮기기 어렵습니다. 그래서 저는 “대체”라는 말을 플랫폼 전체가 아니라 특정 실행 경로/핫패스 일부를 Wasm이 가져간다로 이해하는 편이 더 생산적이라고 봅니다.

선택지 2: gVisor — 컨테이너와 VM 사이의 ‘중간 해법’

gVisor는 컨테이너의 시스템 콜을 “그대로 커널에 전달”하지 않고, 유저스페이스 커널(호환 계층) 로 한 번 더 감싸 공격면을 줄이는 방향의 샌드박싱으로 자주 묶입니다. 보안 강도/성능/호환성에서 마이크로VM과 컨테이너의 중간 지점을 노립니다.

  • 장점: 컨테이너 워크플로(이미지, K8s)와 결합이 상대적으로 자연스럽고, VM보다 가볍게 “추가 경계”를 세울 수 있습니다.
  • 한계: 완전한 하드웨어 가상화 경계는 아니며, 호환성과 성능 비용이 워크로드에 따라 튈 수 있습니다.

실무적으로는 “기본은 컨테이너, 하지만 비신뢰 코드라서 커널 공격면을 더 줄이고 싶다” 같은 경우에 후보로 올라오기 쉽습니다.

선택지 3: 마이크로VM(Kata, Firecracker) — 가장 강한 경계, 그런데 ‘Pod처럼’ 쓰고 싶다

마이크로VM 계열은 한 문장으로 요약하면 이겁니다.

컨테이너의 운영 경험(OCI/K8s)을 유지하면서, 격리 경계는 VM(하드웨어 가상화)으로 올리자.

Kata Containers: OCI 호환성을 유지한 채 “컨테이너를 microVM으로 감싸기”

Kata Containers는 컨테이너를 그대로 쓰는 것처럼 보이게 하되, 내부적으로는 각 워크로드를 microVM으로 감싸 커널 공유를 피합니다. 그래서 멀티테넌시, 규제 환경, AI 에이전트 실행처럼 “탈출이 치명적”인 시나리오에서 매력적입니다.

  • 좋은 점: 이미지/레지스트리/쿠버 워크플로를 유지(팀의 학습 비용과 마이그레이션 비용을 낮춤)
  • 트레이드오프: 운영/관측/디버깅 복잡도 증가, 네트워크·스토리지 경로가 달라져 성능 튜닝 포인트가 늘어남
    (그리고 공격면이 “사라지는” 게 아니라 hypervisor/virtio/런타임 쪽으로 이동합니다)

Firecracker: “독립 커널 + 빠른 생성”으로 대량 샌드박스를 가능하게

대화에서 인용된 수치가 흐름을 상징합니다.

  • microVM 부팅 약 125ms
  • VM당 오버헤드 5MiB 미만
  • 호스트당 초당 150개 수준 생성 가능

이런 특성이 “하루 수백만 세션” 같은 AI 에이전트 샌드박스 수요와 딱 맞습니다. 다만 실전에서는 부팅 시간만이 전체 지연을 대표하지 않습니다. 이미지 준비, 네트워크/스토리지 연결, 런타임 워밍업(특히 모델 로딩 같은 것)이 end-to-end 비용의 주범이 되기 쉽습니다.

그럼 기본 표준은 Wasm? 마이크로VM? — 저는 “기본 microVM + 핫패스 Wasm”이 합리적이라고 봅니다

처음 질문으로 돌아가면, 조직의 위협모델에서 “Wasm 런타임”과 “마이크로VM(Kata)” 중 무엇을 기본 격리 표준으로 삼을지가 핵심이었습니다. 제 결론은 다음과 같습니다.

  • ‘비신뢰 코드 실행’이 제품의 핵심 기능이고, 파일/네트워크/툴 설치 같은 OS 기능이 실제로 필요하다면
    → 기본 격리 표준은 마이크로VM(Kata/Firecracker 계열) 이 더 합리적입니다.
    이유는 단순합니다. 컨테이너의 “커널 공유” 리스크를 설계 레벨에서 제거하는 편이, 정책을 계속 덧대는 것보다 예측 가능하기 때문입니다.
  • 워크로드가 “작은 비즈니스 로직”, “플러그인”, “정책/필터”, “엣지 함수”처럼 OS 의존성이 낮고, 인터페이스를 엄격히 통제할 수 있다면
    → 기본은 Wasm(+WASI) 가 더 강력합니다(작은 배포 단위, 빠른 시작, 샌드박스 모델).

그래서 현실적인 아키텍처는 “승자독식”이 아니라 혼합형이 되기 쉽습니다.

  • 헤비패스(모델 서빙, GPU/드라이버, 복잡한 시스템 의존성): 컨테이너/VM(혹은 마이크로VM)
  • 핫패스(가벼운 로직, 플러그인, 정책, 엣지 실행): Wasm

“하이퍼바이저 기반의 시대가 다시 온다”는 말도, 제가 보기엔 VM이 다시 메인이 된다기보다 ‘Pod처럼 보이는 VM’이 K8s 위에서 표준 옵션으로 자리잡는 방향에 가깝습니다.

(간단 예시) 의사결정 매트릭스

요구사항 추천 격리
사용자/에이전트가 임의 패키지 설치, 빌드툴 실행, 파일 조작 마이크로VM(Kata/Firecracker)
멀티테넌시에서 “탈출=대형 사고” 마이크로VM 우선
작은 플러그인/정책 모듈, 배포 단위 10MB 이하 선호 Wasm(+WASI)
컨테이너 워크플로 유지하면서 리스크만 낮추고 싶음 Kata 또는 gVisor
성능/밀도가 최우선이고 코드 신뢰도가 높음 하드닝 컨테이너

마무리

AI 에이전트 시대의 격리는 “컨테이너냐 VM이냐” 같은 종교전이 아니라, 신뢰 수준이 낮은 코드를 얼마나 자주/크게/어떤 권한으로 실행할 것인가를 먼저 정한 뒤, 그 위협모델에 맞는 경계를 고르는 문제입니다. 저는 “기본은 마이크로VM으로 강한 경계를 만들고, 통제 가능한 로직은 Wasm으로 가볍게 태운다”가 가장 현실적인 출발점이라고 생각합니다.

참고 자료

3 Likes
2

VM과 컨테이너만 알고 있었는데, WASM, 마이크로 VM에 대해서도 알게 되었습니다.
좋은 글 감사드립니다.

2 Likes