coding agent가 package를 설치하고 설정을 바꾸며 Docker까지 실행해야 한다면, 허용 버튼을 계속 누르는 방식은 곧 병목이 된다. Docker Sandboxes는 반대쪽에서 문제를 푼다. agent 내부의 행동을 세밀하게 예측하기보다, 세션 전체를 전용 microVM에 넣고 filesystem·network·credential 경계를 바깥에서 정한다. 자유롭게 실행하되 host까지 닿지 못하게 만드는 구조다.

container 안의 container가 아니다

각 sandbox는 자체 kernel을 가진 microVM이며, 내부에 별도의 Docker daemon이 있다. agent가 docker build, docker run, docker compose를 사용해도 host의 Docker socket을 mount하거나 privileged container를 띄울 필요가 없다. sandbox 안에서 만든 image와 container는 그 세션의 daemon에만 보이고, sandbox를 지우면 함께 사라진다.

Docker는 Firecracker 대신 macOS의 Hypervisor.framework, Windows Hypervisor Platform, Linux KVM을 직접 사용하는 새 VMM을 만들었다고 설명한다. 개발자 노트북 세 운영체제에서 같은 실행 모델을 제공하려는 선택이다. host에서는 프로젝트 workspace만 mount하고, network 접근과 secret 전달 규칙은 실행 전에 정한다. agent가 보안 경계를 스스로 판단하도록 system prompt에 맡기지 않는다는 점이 중요하다.

강한 격리와 편의성 사이의 실제 비용

제품 페이지는 Claude Code, Gemini CLI, Copilot CLI, Codex, OpenCode, Kiro를 지원 대상으로 적고 있다. agent는 sandbox 안에서 package 설치, service 실행, config 수정, 추가 container 구동까지 할 수 있다. macOS와 Windows용 설치 명령이 제공되며 Docker Desktop 없이도 쓸 수 있다고 안내한다. 팀 단위의 중앙 network·filesystem·MCP 정책은 별도 AI Governance 제품으로 이어진다.

HN 토론은 488점과 299개 댓글을 기록하며 보안 모델의 구체성을 파고들었다. Docker 직원은 container 격리가 아니라 OS별 native hypervisor 위의 전용 microVM이며 Firecracker를 쓰지 않는다고 설명했다. 사용자들은 outbound firewall과 secret injection을 장점으로 꼽는 한편, 로그인 요구와 기존 VM·Incus·container 기반 구성보다 나은 점이 무엇인지 물었다. 일부는 실행 환경 격리만으로 충분하지 않으며 read-only 권한, PR 승인, 별도 자격 증명 같은 작업별 권한 모델도 함께 필요하다고 지적했다.

결론은 단순한 "agent를 믿어도 된다"가 아니다. Docker가 제안하는 답은 agent를 신뢰하지 않은 채 충분한 도구를 주는 실행 경계다. 다만 mount한 workspace의 변경은 여전히 host 작업물에 영향을 주고, 허용된 network와 secret의 범위가 넓으면 피해 범위도 커진다. microVM은 중요한 방어선이지만 정책 설계를 대신하지는 않는다. 제품 설명과 architecture 문서에서 세부 구조를 확인할 수 있다.

#microvm

Docker Sandboxes, container 아닌 microVM을 고른 이유