도커 샌드박스: AI 코딩 에이전트를 격리하는 microVM 방식의 안전장치

AI 코딩 에이전트가 개발 현장에 빠르게 들어오면서, 편의성과 안전성 사이의 긴장도 함께 커지고 있다. 에이전트에게 자율성을 최대한 부여하면 작업 속도는 올라가지만, 그만큼 로컬 파일시스템과 네트워크가 통제되지 않은 실행에 노출된다. 도커가 공개한 '도커 샌드박스(Docker Sandboxes)'는 바로 이 지점을 겨냥한 제품으로, AI 에이전트를 microVM 기반의 격리 환경 안에서 실행해 호스트를 보호하는 것을 목표로 한다.

샌드박스는 그 자체로 하나의 격리된 microVM 환경이며, 그 안에서 돌아가는 에이전트로부터 사용자의 파일시스템과 네트워크를 분리해 보호하는 역할을 한다. 도커는 기본적으로 Claude Code, Gemini CLI, Copilot CLI, Codex, OpenCode, Kiro를 지원한다고 밝혔고, 이 목록에 없는 도구를 위해 직접 샌드박스를 만들어 쓸 수도 있다. 즉 특정 벤더의 에이전트에 종속되지 않고, 여러 코딩 에이전트를 같은 격리 방식으로 다룰 수 있도록 설계된 셈이다.

YOLO 모드의 위험을 격리로 상쇄하다

이 제품이 해결하려는 핵심 문제는 이른바 'YOLO 모드'다. Claude Code 등에서 제공하는 --dangerously-skip-permissions 옵션은 매 작업마다 뜨는 승인 프롬프트를 건너뛰고 에이전트에 완전한 자율성을 준다. 승인 절차가 사라지면 반복 작업이 훨씬 빨라지지만, 가드레일 없이 쓰면 그만큼 위험하다. 도커는 각 에이전트를 전용 microVM 안에 가두는 방식으로, 이 자율 실행을 상대적으로 안전하게 만든다고 설명한다. 승인 프롬프트를 없애도 실행 범위 자체가 격리돼 있으니 호스트로 피해가 번지지 않는다는 논리다.

격리 방식으로 컨테이너가 아닌 microVM을 택한 점도 눈여겨볼 만하다. 도커의 설명에 따르면 샌드박스는 완전히 격리된 microVM에서 동작하며, 전통적인 가상머신을 온전히 돌릴 때의 비용을 치르지 않으면서도 더 강한 격리 수준을 제공한다. 이 덕분에 더 많은 권한이 필요한 작업도 안전하게 수행할 수 있는데, 대표적인 예가 샌드박스 안에서 추가로 도커 컨테이너를 띄우는 것이다. 에이전트는 샌드박스 내부에서 패키지를 설치하고 서비스를 실행하며, 사람이 지켜보지 않는 상태로 무인 작업을 이어갈 수 있다.

개인 격리를 넘어 조직 차원의 통제로

실무 관점에서 보면 이 구조의 의미는 분명하다. 그동안 자동화된 에이전트에 넓은 권한을 주는 일은 로컬 환경 오염, 의도치 않은 네트워크 접근, 통제되지 않은 명령 실행 같은 리스크와 맞바꾸는 선택이었다. 샌드박스는 네트워크와 파일시스템에 대한 제어 규칙을 사용자가 직접 정의하도록 하고, 그 경계 안에서만 에이전트가 움직이게 함으로써 이 맞바꿈의 손실을 줄이려 한다. 컨테이너를 만들거나 서비스를 띄우는 것처럼 권한이 큰 동작을, 호스트를 위험에 빠뜨리지 않고 시도해 볼 수 있는 실험 공간이 생기는 셈이다.

다만 개인 개발자가 자신의 머신에서 규칙을 정의하는 것과, 팀 전체에 동일한 통제를 강제하는 것은 다른 문제다. 도커는 이를 위해 '도커 AI 거버넌스(Docker AI Governance)'라는 별도 계층을 제시한다. 네트워크 정책, 파일시스템 규칙, MCP 거버넌스 같은 통제를 한 번 정의해 모든 개발자의 머신에 조직 전반으로 적용하려면 이 거버넌스 기능이 필요하다는 것이 도커의 안내다. 바꿔 말하면 샌드박스 설치만으로는 핵심 기능, 즉 개별 격리 실행까지만 커버되고, 팀 단위의 중앙 집중식 통제는 상위 제품의 몫으로 나뉘어 있다.

도입 전 짚어둘 한계

현재 공개된 정보만으로는 판단을 유보해야 할 부분도 있다. 도커가 밝힌 내용은 지원 대상 도구, microVM 격리라는 방식, YOLO 모드와의 연계, 거버넌스로의 확장 정도이며, 구체적인 성능 오버헤드나 microVM 부팅 지연, 실제 격리의 강도를 검증할 수 있는 수치는 제시되지 않았다. microVM이 VM보다 가볍다고 하지만 순수 컨테이너 대비 어느 정도의 비용을 치르는지, 무인 작업이 길어질 때의 안정성은 어떤지는 실제 워크플로에 붙여 확인해 볼 문제다. 에이전트에 자율성을 주되 그 실행을 격리하겠다는 방향성 자체는 합리적이지만, 팀 표준으로 채택하기 전에는 자신들의 도구 구성과 보안 요구에 맞춰 격리 경계와 거버넌스 적용 범위를 직접 시험해 보는 편이 안전하다.