왜 도커(Docker)만으로는 부족한가: 2026년 AI 에이전트 샌드박싱 지형

2025년 12월, 한 보안 연구원이 가장 널리 쓰이는 AI 기반 IDE인 Cursor, Windsurf, GitHub Copilot, Cline 등에 걸쳐 30개 이상의 취약점을 공개했습니다. 이 모든 취약점의 근본 원인은 거의 동일했습니다. 에이전트가 로컬 사용자 권한을 그대로 가진 채, 공유 프로세스 환경 내에서 실행되었으며, AI가 생성한 코드와 머신 내 다른 모든 리소스 사이에 유의미한 격리 경계(isolation boundary)가 전혀 존재하지 않았다는 점입니다.

연구원은 이 취약점 공개 사례를 ’IDEsaster’라고 명명했고, 이 이름은 업계에 널리 각인되었습니다.

이 사고들 중 그 어떤 것도 암호 체계를 깨뜨리거나 메모리 손상 버그를 익스플로잇할 필요가 없었습니다. 훨씬 더 단순한 결함이 원인이었습니다. 바로 AI 에이전트가 자신이 생성한 결과물을 맹신하여 아무런 격리 조치 없이 그대로 실행했다는 점입니다.

핵심 문제

DevOps 팀이 자체 애플리케이션을 구동하는 도커 컨테이너를 배포할 때는 그 안에 무엇이 들어있는지 명확히 알고 있습니다. 반면 AI 에이전트가 사용자 프롬프트, CI 트리거, 또는 인입 웹훅에 응답하여 코드를 생성할 때는 개발자도 에이전트도 해당 코드가 런타임에 실제로 어떤 동작을 수행할지 완전히 검증할 수 없습니다.

다음과 같은 통계 수치는 불편한 현실을 보여줍니다:

• AI가 생성한 코드는 사람이 작성한 코드보다 보안 취약점을 2.74배 더 많이 포함하고 있습니다.
• 테스트된 모델 전반에서 AI 코드 생성 작업 중 보안상 안전한 코드를 생성한 비율은 55%에 불과합니다 (Veracode 2025).
• 조사 대상 리포지토리 전반에서 AI 생성 코드로 인해 매달 10,000건 이상의 새로운 보안 결함이 추가되고 있으며, 이는 2024년 말 대비 10배 증가한 수치입니다.
• 83%의 기업이 2026년 내에 AI 에이전트를 도입할 계획을 가지고 있습니다.

도커 컨테이너는 리눅스 네임스페이스(namespaces)와 cgroups를 사용하여 프로세스를 격리하지만, 호스트 커널을 공유합니다. 이는 우발적인 프로세스 간 간섭을 방지하는 보안 경계일 뿐, 악의적인 코드에 맞서는 보안 경계가 아닙니다. 커널 취약점을 통한 컨테이너 탈출(container breakout)은 호스트 권한 탈취 및 호스트 내 다른 모든 컨테이너로의 횡적 이동(lateral movement)으로 곧바로 이어집니다.

세 가지 격리 계층

업계는 AI 에이전트의 코드 실행을 격리하기 위해 세 가지 뚜렷한 접근 방식으로 수렴했으며, 각각 서로 다른 보안 보장 수준과 성능 트레이드오프를 가집니다.

계층 1: 도커 컨테이너 (신뢰할 수 없는 코드에는 불충분)

컨테이너는 약 50ms 만에 시작되고 성능 오버헤드가 미미하며, 전 세계 거의 모든 엔지니어링 팀의 기본 배포 단위로 자리 잡았습니다. 하지만 컨테이너 내부에서 실행되는 코드가 LLM에 의해 생성된 경우라면 이것만으로는 충분하지 않습니다.

대표적인 실패 시나리오: 에이전트의 도구 실행을 위해 Docker-in-Docker를 구동하려면 --privileged 모드가 필요한데, 이는 격리 수준을 극적으로 약화시킵니다. 이 시점에서는 격리 보장이 사실상 무력화됩니다.

컨테이너를 사용해야 하는 경우: 코드를 완전히 통제할 수 있을 때. 단일 테넌트(single-tenant). 오직 신뢰할 수 있는 워크로드에만 적합합니다.

계층 2: gVisor (절충안)

Google의 gVisor는 시스템 콜(syscall)이 호스트 커널에 도달하기 전에 이를 가로채는 유저 공간 커널을 구현합니다. 컨테이너가 시스템 콜을 호출하면 gVisor의 Sentry 프로세스가 유저 공간에서 이를 처리하여 커널 공격 표면을 획기적으로 줄입니다. 수백 개의 시스템 콜이 호스트 커널에 직접 전달되는 대신, gVisor는 엄격히 검증된 최소한의 서브셋만을 허용합니다.

• 콜드 스타트: ~100ms
• 성능 오버헤드: I/O 집약적 워크로드에서 20~50%
• 보안 모델: 시스템 콜 수준의 격리. 컨테이너보다 강력하지만 VM보다는 약함.
• 사용 사례: Modal, Google (GKE 상의 Agent Sandbox)

트레이드오프: 모든 시스템 콜이 완벽히 에뮬레이트되는 것은 아니므로, 일부 리눅스 소프트웨어와의 호환성 문제가 발생할 수 있습니다.

계층 3: MicroVM (골드 스탠다드)

AWS가 Lambda 및 Fargate를 위해 개발한 Firecracker는 최소한의 디바이스 에뮬레이션을 갖춘 경량 가상 머신을 생성합니다. 각 MicroVM은 KVM 내부에서 자체 리눅스 커널을 실행하므로 하드웨어 수준의 격리가 보장됩니다. 게스트 프로세스가 침해당하더라도 호스트 커널에 도달하거나 다른 샌드박스로 횡적 이동하는 것이 불가능합니다.

• 콜드 스타트: ~125-150ms
• 성능 오버헤드: 낮음 (VM 내부에서 네이티브 실행)
• 메모리 오버헤드: VM당 5 MiB 미만
• 밀도: 호스트당 초당 최대 150개의 MicroVM 생성 가능, 호스트당 약 4,000개 구동 가능
• 보안 모델: 하드웨어 가상화. 공격자는 게스트 커널과 하이퍼바이저를 모두 탈출해야 함.
• 사용 사례: AWS Lambda, AWS Fargate, E2B, Cloudflare Workers

Kata Containers는 이를 쿠버네티스 네이티브 오케스트레이션으로 감쌉니다. 쿠버네티스 관점에서는 일반적인 컨테이너처럼 보이지만, 내부적으로는 하드웨어 격리를 갖춘 완전한 VM입니다.

WebAssembly (부상 중이나 제한적)

WebAssembly는 10ms 미만의 콜드 스타트를 자랑하는 언어 수준의 샌드박싱을 제공하지만 파일시스템, 네트워크, 영구 상태(persistent state)가 지원되지 않습니다. 브라우저 기반 및 엣지 컴퓨팅에는 효과적이지만 OS 통합이 필요한 대부분의 AI 에이전트 워크로드에는 적합하지 않습니다.

비교 분석

샌드박스 플랫폼 경쟁

격리 기술을 SDK 호출 뒤로 추상화한 새로운 인프라 범주인 ‘서비스형 샌드박스(Sandbox-as-a-Service)’ 플랫폼이 등장했습니다.

E2B는 레퍼런스 구현체로 자리 잡았습니다. 모든 샌드박스는 Firecracker MicroVM 내부에서 실행됩니다. Python 및 TypeScript SDK를 통해 단 한 줄의 코드로 샌드박스를 프로비저닝할 수 있습니다. 세션은 최대 24시간 동안 유지됩니다. 오픈소스 코어를 기반으로 주요 에이전트 프레임워크 전반에서 폭넓은 채택을 이끌어냈습니다.

Modal은 gVisor 기반 격리와 네이티브 GPU 접근을 제공하며 다른 접근법을 취합니다. 에이전트가 단순 스크립트 실행을 넘어 인퍼런스(추론)까지 직접 수행해야 할 때 적합한 선택입니다.

Daytona는 단순한 실행 샌드박스를 넘어 완전한 개발 환경을 제공합니다. AI 코딩 에이전트를 위한 IDE 통합과 지속적인 작업 공간(persistent workspaces)을 지원합니다.

Cloudflare Workers는 10ms 미만의 콜드 스타트와 글로벌 분산 환경을 위해 V8 Isolate를 엣지에 배치하지만, 영구 파일시스템은 지원하지 않습니다.

Docker 역시 표준 컨테이너가 에이전트 워크로드에 불충분함을 인정하고 강화된 컨테이너(hardened container) 접근 방식을 내세우며 이 경쟁에 뛰어들었습니다.

샌드박스가 VM 및 컨테이너와 차별화되는 점

핵심적인 통찰은 샌드박스가 설계상 임시적(ephemeral by design)이라는 점입니다. VM은 직접 프로비저닝하고 유지 관리해야 하는 장기 실행 인프라입니다. 컨테이너는 지속적으로 구동되는 서비스입니다. 반면 샌드박스는 단일 작업을 위해 생성되고 작업이 끝나면 즉시 파괴됩니다.

이는 보안의 역학 관계를 완전히 바꿉니다:

1. 작업 간 상태 유출 없음(No state leakage) — 각 코드 실행마다 완전히 새로운 환경이 제공됩니다.
2. SDK 네이티브 프로비저닝 — sandbox = Sandbox()라는 단 한 줄의 코드로 충분하며, 별도의 인프라 엔지니어링이 필요하지 않습니다.
3. 자동 정리(Automatic cleanup) — 작업 완료 후 샌드박스가 파괴되므로 좀비 컨테이너가 남지 않습니다.
4. 작업별 커널 격리(Per-task kernel isolation) — 침해당한 샌드박스가 호스트나 다른 샌드박스에 영향을 미칠 수 없습니다.
5. 최소 공격 표면(Minimal attack surface) — 전체 리눅스 커널 대신 Firecracker의 약 50,000줄 Rust 코드로만 구성됩니다.

의사결정 프레임워크

코드가 AI가 생성했거나 신뢰할 수 없는 코드인가?
├── 아니오 → 도커 컨테이너로 충분함
└── 예     → GPU 접근이 필요한가?
    ├── 예     → Modal (gVisor + GPU)
    └── 아니오 → 영구 파일시스템이 필요한가?
        ├── 예     → E2B (Firecracker, 24시간 세션)
        └── 아니오 → 상태 비저장(stateless) 엣지 함수인가?
            ├── 예     → Cloudflare Workers (V8 isolates)
            └── 아니오 → 완전한 개발 환경이 필요한가?
                ├── 예     → Daytona
                └── 아니오 → E2B (기본 추천)

에이전트 아키텍처에 시사하는 바

IDE, CI 파이프라인, 챗봇, 혹은 자율 워크플로우 등 코드를 생성하고 실행하는 AI 에이전트를 구축하고 있다면, 도커만으로는 보안 경계가 될 수 없습니다. 도커는 배포 단위일 뿐입니다. 보안 경계는 반드시 하드웨어 수준의 격리를 제공하는 샌드박스여야 합니다.

다행인 점은 샌드박스 플랫폼 덕분에 이러한 격리를 복잡한 인프라 프로젝트 대신 단 한 줄의 SDK 호출로 구현할 수 있게 되었다는 것입니다. 반면 아쉬운 점은 여전히 대다수의 팀이 공유 프로세스 환경에서 로컬 사용자 권한으로 에이전트를 실행하며, 모델이 rm -rf 같은 명령어를 환각(hallucination)해내지 않기만을 바라고 있다는 사실입니다.

IDEsaster 취약점 공개는 그러한 막연한 기대가 무너졌을 때 어떤 일이 일어나는지 명백히 보여주었습니다. 현재 벌어지고 있는 샌드박스 플랫폼 경쟁은 바로 이에 대한 업계의 해답입니다.

본 글은 2026년 6월에 발표된 연구를 기반으로 하며, Northflank, Docker, AgentMarketCap, Paperclipped, SoftwareSeni의 기술 분석과 Firecracker/gVisor/Kata Containers 공식 문서를 참고했습니다. 전체 연구 보고서는 저의 [[AI Agent Sandboxing - Containers vs VMs vs MicroVMs Deep Research|연구 노트]]에서 확인하실 수 있습니다.

관련 글

• 2026년 AI 에이전트 인증 지형: 당신은 누구이며, 왜 당신을 신뢰해야 하는가?
• 누가 당신의 AI 에이전트를 거버넌스하는가? 마이크로소프트, 구글, AWS가 내놓은 세 가지 서로 다른 해답
• 게이트키퍼 패턴: 고비용 LLM에 도달하기 전 프롬프트 인젝션을 차단하는 로컬 3B SLM