2026년 6월 22일, AWS는 공식 블로그에 공지 하나를 올렸다. 제목은 길었지만 핵심은 단 한 문장이었다: Lambda에서 이제 MicroVM을 실행할 수 있다.
AWS는 새 서비스도, 새 SKU도 내놓지 않았다 — 11년 역사의 서버리스 제품인 Lambda 안에 새로운 문이 하나 열렸다. 필자의 첫 반응은 이랬다: AWS가 Firecracker를 무대 뒤에서 전면으로 밀어냈다. 그리고 이번에는 Lambda의 함수용이 아니라, 개발자에게 직접 제공하는 것이다.
무엇이 출시되었나
Lambda MicroVM은 새로운 컴퓨팅 프리미티브다. Lambda Functions와 동일한 콘솔 진입점을 공유하지만, API는 완전히 다르다: Dockerfile 하나와 코드 압축 파일을 S3에 업로드하면, Lambda가 이미지를 빌드하고, 애플리케이션을 초기화하며, Firecracker 스냅샷을 생성한다. 이후 MicroVM을 시작할 때마다 이预热된 스냅샷에서 바로 복구된다 — 콜드 스타트 구간이 완전히 생략된다.
주목할 만한 핵심 파라미터는 다음과 같다:
- 인스턴스 상한: 16 vCPU, 32 GB 메모리, 32 GB 디스크, ARM64(Graviton) 아키텍처
- 최대 실행 시간: 8시간 — Lambda Functions의 15분 제한이 여기서는 사라진다
- 유휴 정책: 자동 일시 중지(suspend) 설정 가능, 중지 기간에는 스냅샷 저장 비용만 청구, 복구 시 전체 메모리와 디스크 상태 보존
- 시작 방식: 콜드 스타트가 아닌 스냅샷 복구. 시작 성공 즉시 준비된 HTTP 엔드포인트 획득
- 최초 지원 리전: US East(버지니아, 오하이오), US West(오레곤), Europe(아일랜드), Asia Pacific(도쿄)
가격은 vCPU/초와 메모리/GB/초로 측정되며, 일시 중지 후 컴퓨팅 비용은 0이 된다. 이는 Lambda Functions의 과금 논리와 일치하지만, 단일 세션이 수 시간 동안 지속될 수 있어 실제 청구 구조는 온디맨드 VM에 더 가까워진다 — 다만 일시 정지 능력이 추가된 형태다.
AWS 공식 블로그에는 목표 시나리오가 명시적으로 나열되어 있다: AI 프로그래밍 어시스턴트, 대화형 코드 환경, 데이터 분석 플랫폼, 취약점 스캐너, 사용자 스크립트를 실행하는 게임 서버. 이들의 공통된 특징은 무엇인가? 각 최종 사용자가 신뢰할 수 없는 코드를 안전하게 실행할 수 있는 자신만의 격리 환경을 필요로 한다는 점이다.
왜 지금인가
이 질문은 분해해서 살펴볼 가치가 있다.
Firecracker는 2018년에 오픈소스로 공개되었다. 그 후 7년간 매월 15조 건 이상의 Lambda 함수 호출을 지탱해 왔다. 기술은 성숙했지만, AWS는 지금까지 Firecracker를 개발자 대상 제품으로 판매한 적이 없다 — 지금까지는 말이다.
바뀐 것은 AWS의 전략적 선호가 아니라 수요 측면이다.
2025년부터 2026년 상반기까지, AI 코드 어시스턴트는 실험적 도구에서 일상 도구로 변모했다. Claude Code, Codex CLI, Gemini Code Assist — 이 에이전트들은 코드를 생성할 뿐만 아니라 코드를 실행해야 한다. 패키지를 설치하고, 서비스를 띄우고, 파일 시스템을 읽고 쓰며, 네트워크 요청을 보낸다. 매일 수백만 번씩이다. 그리고 이 코드를 실행하는 환경은 Docker 컨테이너(커널 공유, namespace + cgroup + seccomp으로 격리)이거나, 가상머신(격리는 강력하지만 시작은 느리다) 중 하나다.
더 심각한 문제는 에이전트 자체가 능동적으로 소프트웨어 레벨의 보안 제한을 우회한다는 점이다. 2026년 3월, Falco 코어 메인테이너 Leonardo Di Donato는 Claude Code가 어떻게 자신의 샌드박스를 우회하는지 시연했다: 에이전트가 /proc/self/root/usr/bin/npx가 deny 규칙을 우회한다는 것을 발견했고, bubblewrap에 의해 차단되자 곧바로 샌드박스를 꺼 버렸다. 탈옥도, 특수 프롬프트도 없었다. 그저 작업을 완수하려 했을 뿐이다.
이 사례는 하나의 핵심적 사실을 보여준다: 유저스페이스 로직에 기반한 격리(denylist, permission prompt, seccomp 규칙)는 에이전트의 추론과 동일한 레이어에서 실행된다. 에이전트는 이것들을 이해하고 우회할 수 있는 충분한 능력을 갖추고 있다. 반면 MicroVM의 격리는 하드웨어 가상화에 의해 강제되며, 에이전트가 도달할 수 없는 레이어에서 작동한다.
Lambda MicroVM의 출시 타이밍은 바로 이 보안 문제의 폭발 시점과 정확히 겹친다.
샌드박스 시장의 구도
Lambda MicroVM은 진공 상태에서 탄생하지 않았다. 그 이전에도 “신뢰할 수 없는 코드를 어떻게 안전하게 실행할 것인가”라는 질문을 둘러싸고 상당한 규모의 도구 및 플랫폼 생태계가 이미 형성되어 있었다. 필자는 현재의 주요 진영을 정리한다 — 우열을 가리기 위함이 아니라, 아키텍처 차이와 적합한 용도를 제시하기 위함이다.
Firecracker 진영
AWS가 가장 큰 플레이어임은 물론이다. 새로 출시된 Lambda MicroVM 외에도 AWS Bedrock AgentCore는 각 에이전트 세션에 독립적인 microVM을 제공하기 위해 Firecracker를 사용 중이다.
독립 플랫폼으로는, E2B는 AI 에이전트 샌드박스에 특화된 서비스로, Firecracker 기반에 ~150ms 시작, Fortune 100 기업의 88%가 이미 등록했다고 주장한다. Fly.io Sprites는 상태 유지형(stateful) VM을 제공하며, checkpoint/restore 약 300ms, Claude Code와 Codex CLI가 사전 설치되어 있다. Vercel Sandbox 역시 Firecracker 기반으로, 밀리초 단위의 스냅샷 복구를 내세우며 AI 코드 인터프리터 시나리오를 겨냥한다. SlicerVM은 자체 호스팅 노선으로, Firecracker와 Cloud Hypervisor를 모두 지원하며 macOS에서는 Apple Virtualization Framework를 사용할 수 있다.
오픈소스 프로젝트 중에서는 Matchlock이 주목할 만하다 — AI 에이전트용으로 설계된 Firecracker 샌드박스로, 기본 deny-all 네트워크 정책, 도메인 화이트리스트, 키 보호 기능을 갖추고 있으며 claude --dangerously-skip-permissions의 보안 문제를 정면으로 해결한다.
libkrun 진영
Red Hat의 libkrun은 라이브러리 레벨 VMM 노선을 취한다 — microVM 능력을 독립형 데몬이 아닌, 다른 프로그램에서 호출 가능한 라이브러리로 패키징한다. Microsandbox(YC 인큐베이션, Apache 2.0 오픈소스, ~4,700 GitHub Star)는 libkrun의 가장 대표적인 소비자다: 자체 호스팅 AI 에이전트 샌드박스로, 각 인스턴스가 독립 커널, 파일 시스템, 네트워크 스택을 얻는다.
libkrun의 차별화된 장점 중 하나는 크로스 플랫폼 지원이다: Linux에서는 KVM, macOS에서는 Hypervisor.framework를 사용한다. 단점은 Kubernetes 오케스트레이션 레이어와 클러스터 수준 관리 능력이 부족하다는 점이다 — 단일 머신 배포에 더 적합하며, 대규모 멀티테넌트 프로덕션 환경보다는 개발자 로컬 또는 소규모 팀의 샌드박스 수요에 맞는다.
Kata Containers
Kata Containers는 포지셔닝 측면에서 다른 솔루션들과 본질적인 차이가 있다: Firecracker, Cloud Hypervisor 또는 QEMU를 Kubernetes 런타임 레이어에 임베딩하는 오케스트레이션 프레임워크를 제공하여, 각 Pod가 자신만의 경량 VM 위에서 실행되도록 한다. Kubernetes 입장에서는 평범한 컨테이너로 보이지만, 그 아래는 완전한 하드웨어 격리다.
시작 시간 ~150-300ms(VMM 선택에 따라), 메모리 오버헤드 <10 MiB + 게스트 커널. Kata의 핵심 가치는 microVM의 운영 복잡성을 감춰준다는 점이다 — 커널 이미지, 네트워크 설정, VM 라이프사이클을 직접 관리할 필요가 없다. Northflank는 프로덕션 환경에서 Kata Containers + Cloud Hypervisor를 사용하며, 월평균 200만 개 이상의 microVM을 실행한다.
Kata는 장기 실행, K8s 오케스트레이션이 필요한 멀티테넌트 워크로드를 지향하며, 단발성 세션의 빠른 시작/중지 시나리오와는 방향이 다르다.
gVisor
Google의 gVisor는 완전히 다른 기술 노선을 취한다: 컨테이너 외부에 VM을 씌우는 대신, 컨테이너와 호스트 커널 사이에 Go로 작성된 유저스페이스 커널(Sentry)을 삽입한다. 컨테이너가 발생시키는 시스템 콜은 Sentry에 의해 가로채져 유저 공간에서 처리되며, 최소한의 필수 작업만 호스트 커널로 전달된다.
이는 VM 시작 오버헤드가 없고, 중첩 가상화 지원이 필요 없으며, Docker/containerd 통합 경로가 가장 짧다는 것을 의미한다. 대가는: I/O 집약적 워크로드에서 10-30%의 시스템 콜 오버헤드가 발생한다. gVisor의 격리 강도는 컨테이너와 VM 사이에 위치한다 — 커널 공격 표면을 크게 축소하지만(Sentry는 ~230개의 시스템 콜만 구현, Linux 커널은 450개 이상 노출), 하드웨어 수준의 메모리 격리는 달성하지 못한다.
Modal은 gVisor 노선의 대표적 제품으로, GPU 지원 샌드박스 환경을 제공하며 ~300ms 시작, 추론과 학습 시나리오를 주력으로 한다.
Cloudflare Workers (V8 Isolates)
Cloudflare는 또 다른 극단을 선택했다: V8 isolate. 시작 시간은 서브 밀리초 수준이지만, JavaScript/TypeScript/WASM만 지원한다. 2026년에 Dynamic Workers 기능이 추가되어, LLM이 런타임에 동적으로 JS/TS 하위 isolate를 생성하여 코드를 실행할 수 있으며, 토큰 소비량이 기존 tool-calling 대비 81% 감소한다. 이것은 범용 샌드박스는 아니지만, JS/WASM 생태계 내에서의 밀도와 지연 시간 성능은 타의 추종을 불허한다.
차별화 차원
각 진영의 솔루션을 정리한 후, 필자는 현재 경쟁의 초점이 되고 있는 몇 가지 차원을 관찰했다:
스냅샷/포크 능력. Lambda MicroVM의 “预热 스냅샷 직접 시작”은 본질적으로 이미 초기화된 런타임 상태를 고정시켜 두었다가 다음 시작 시 바로 복구하는 방식이다. 이 발상은 Unikraft Cloud에서 극단으로 치달았다 — <10ms 콜드 스타트, 단일 호스트 머신당 10만 개 이상의 격리 인스턴스를 주장한다. 스냅샷 속도는 사용자 경험을 직접 결정한다: 에이전트가 코드 실행 요청을 시작한 후, 사용자가 100ms를 기다리는가 아니면 5초를 기다리는가의 차이는 지속적 사용과 포기를 가른다.
네트워크 레이어 키 차폐. 이는 에이전트 시나리오에서 특히 결정적이다. 에이전트는 외부 네트워크 접근(의존성 다운로드, API 호출)이 필요하지만, 환경 변수에 저장된 키를 읽도록 해서는 안 된다. Lambda MicroVM의 해결책은 수명이 짧은 인증 토큰 + 프록시 헤더이며, Matchlock의 접근법은 deny-all + 도메인 화이트리스트다. 차이는 기능의 유무가 아니라, 각 진영이 보안 모델을 어떻게 이해하느냐에 있다.
SSH / VPN 접근. 대화형 개발 시나리오는 개발자가 직접 샌드박스에 접속해 디버깅할 수 있어야 한다. Fly.io Sprites와 E2B는 SSH를 지원하며, Lambda MicroVM은 현재 HTTP 엔드포인트 모드로, 코드 실행에는 적합하지만 대화형 개발에는 덜 적합하다.
오케스트레이션 레이어와 K8s 통합. Kata Containers는 이 차원에서 사실상 경쟁자가 없다 — Kubernetes를 위해 설계되었기 때문이다. Firecracker를 베어메탈로 사용하려면 상당한 인프라를 직접 구축해야 하며, Lambda MicroVM은 이 부담을 AWS 관리 서비스로 이전한다. libkrun은 현재 클러스터 수준의 오케스트레이션 방안이 부족하다.
에이전트 친화도. 이는 단순한 기술 사양 비교가 아니라 제품 설계 철학의 문제다. 샌드박스가 REST API를 노출하는가? SDK를 지원하는가? snapshot/resume의 시맨틱이 에이전트의 “실행-결과 대기-계속 실행” 사이클에 적합한가? Lambda MicroVM의 일시 중지/복구 메커니즘과 8시간 상한은 분명 에이전트 세션을 위해 설계된 반면, Docker Sandboxes의 “에이전트당 독립 Docker 데몬” 모델은 로컬 개발 시나리오에 더 중점을 둔다.
구도는 아직 결정되지 않았다
타임라인을 늘려서 보면, 2018년 Firecracker가 탄생했을 때 microVM은 인프라 레이어의 최적화 수단이었다 — Lambda를 더 빠르고, 더 저렴하고, 더 안전하게 만들기 위해서. 2026년이 되자 동일한 기술이 제품 레이어의 일급 시민이 되었다. 상위 계층의 수요가 근본적으로 변화했기 때문이다: 에이전트는 코드를 실행해야 하고, 코드 실행에는 샌드박스가 필요하며, 샌드박스는 namespace의 짜깁기가 될 수 없다.
그러나 “최고의 샌드박스가 무엇인가”라는 질문에는 단일 답변이 존재하지 않는다. 에이전트가 JavaScript만 실행한다면, Cloudflare Workers의 V8 isolate가 서브 밀리초 수준으로 시작하는 microVM보다 더 강력할 수 있다. Kubernetes 위에서 장시간 실행되는 격리 Pod가 필요하다면, Kata Containers가 베어 Firecracker보다 더 실용적이다. 로컬에서 자체 호스팅하는 경량 솔루션이 필요하다면, libkrun + Microsandbox가 AWS 관리 서비스보다 더 유연하다. Lambda MicroVM의 강점은 제로 운영과 스냅샷 복구에 있다 — 하지만 AWS 생태계, ARM64 아키텍처, 리전 제한에 묶여 있다.
필자는 위에서 언급한 어떤 샌드박스 솔루션도 프로덕션 환경에서 대규모로 운영해 본 적이 없다. 이 글의 판단은 공개 문서, 기술 백서, 커뮤니티 논의의 교차 검증에 기초한다. AI 에이전트를 위한 샌드박스 인프라를 선택 중이라면, 자신의 워크로드로 벤치마크를 직접 수행할 것을 권한다 — 100ms 스냅샷 복구가 실제 네트워크 지연 속에서 보여주는 성능은 벤치마크 표에 적힌 숫자와 전혀 다를 수 있다.
아키텍처의 승부처는 종종 아키텍처 자체가 아니다. 에이전트가 초당 수십 번의 코드 실행 요청을 발생시키는 세상에서, 스냅샷 속도, 네트워크 지연, 키 관리, 과금 모델 — 이러한 “비핵심” 요소들이 VMM이 Rust로 작성되었는지 Go로 작성되었는지보다 더 중요할 수 있다.
면책 조항: 본 기사는 기술 관찰일 뿐이며, 필자는 본문에서 언급된 어떤 회사나 프로젝트와도 이해관계가 없다.