AI 에이전트를 실제 업무에 붙이기 전, 격리 환경부터 필요한 이유 (Docker Sandboxes)

AI 에이전트에게 “테스트를 고치고, 필요한 패키지를 설치하고, 컨테이너를 띄운 뒤 결과를 알려 달라”고 맡기는 순간부터 문제는 모델의 답변 품질만이 아니다. 그 에이전트가 실제로 어떤 파일을 읽고, 어떤 명령을 실행하며, 어디로 통신하는지가 업무 권한이 된다. Docker는 2026년 Docker Sandboxes를 공개해 Claude Code, Gemini CLI, Copilot CLI, Codex 같은 코딩 에이전트를 전용 마이크로VM에서 실행하는 방식을 제시했다. 핵심은 승인 창을 더 자주 띄우는 대신, 에이전트가 자유롭게 실행할 자리를 호스트와 분리하는 데 있다.

샌드박스 하나에는 자체 파일시스템, Docker 데몬, 네트워크가 생긴다. 에이전트는 그 안에서 패키지를 설치하고 컨테이너를 만들며 sudo 권한으로 작업할 수 있다. 호스트의 Docker 데몬, localhost, 호스트 파일시스템은 기본적으로 이 경계 밖에 있다. Docker가 강조하는 ‘무인 실행’은 권한을 없애는 말이 아니라, 호스트에 닿는 면을 명시적으로 제한한 상태에서 실행 권한을 안쪽에 주는 구조다.

호스트에서 바로 실행하는 방식과 Docker Sandboxes의 분리된 마이크로VM 실행 방식을 비교한 도식 — 실행 권한을 좁히는 대신 에이전트가 작업할 환경을 호스트와 분리하는 방식.

격리됐어도 프로젝트 작업 공간은 실제로 바뀐다

여기서 가장 중요한 경계는 작업 공간이다. Docker Sandboxes는 기본값으로 호스트의 프로젝트 디렉터리를 같은 절대 경로에 읽기·쓰기 마운트한다. 에이전트가 만든 수정은 동기화 과정 없이 현재 작업 트리에 즉시 나타난다. 샌드박스를 지우면 내부에 설치한 패키지, Docker 이미지와 컨테이너, VM 상태는 사라지지만, 공유 작업 공간에 쓴 코드와 설정은 남는다.

그래서 ‘호스트를 건드리지 않는다’는 설명을 프로젝트 원본까지 보호된다는 뜻으로 읽으면 안 된다. Docker 문서도 기본 직접 마운트에서 Git 훅, CI 설정, IDE 작업 설정, Makefile, package.json 스크립트처럼 나중에 암묵적으로 실행될 수 있는 파일을 함께 검토하라고 안내한다. 여러 에이전트에게 같은 저장소를 병렬로 맡기거나 원본 작업 트리를 보존해야 한다면 --clone 모드가 더 맞다. 이 모드에서는 저장소 원본을 읽기 전용으로 마운트하고 에이전트가 VM 안의 개인 복제본에서 작업한다.

Docker Sandboxes에서 AI 에이전트와 전용 Docker 데몬은 마이크로VM 안에 있고 프로젝트 작업 공간과 호스트 프록시만 명시적으로 연결되는 구조를 보여 주는 도식 — 마이크로VM이 막는 대상과, 작업 공간·프록시처럼 의도적으로 넘겨 주는 경로.

네트워크와 자격증명은 ‘연결 가능’보다 ‘어디까지 연결할지’가 핵심이다

Sandboxes의 모든 외부 HTTP·HTTPS 통신은 호스트 쪽 프록시를 지난다. 이 프록시는 허용 도메인 규칙을 적용하고, 등록한 자격증명은 요청 헤더에 주입한다. 원시 자격증명 값은 VM 안으로 들어가지 않는다. 원시 TCP·UDP·ICMP 통신은 네트워크 계층에서 막히며, 허용 목록에 없는 도메인과 호스트 network·localhost에도 직접 닿지 못한다.

그러나 허용 목록 자체가 업무 권한이다. Docker는 기본 허용 도메인에 넓은 와일드카드가 포함될 수 있다고 밝히며 sbx policy ls로 활성 규칙을 확인하고 불필요한 항목을 제거하라고 안내한다. 로컬 stdio MCP 서버도 마이크로VM 밖의 호스트에서 동작한다. 에이전트는 MCP 게이트웨이를 통해 그 도구를 호출할 수 있으므로, 로컬 MCP는 일반적인 샌드박스 내부 프로그램이 아니라 신뢰한 호스트 연동으로 다뤄야 한다.

Docker Sandboxes의 에이전트 작업 공간을 보여 주는 Docker 공식 화면 — Docker가 공개한 Sandboxes 작업 공간 화면. 에이전트 실행과 프로젝트 파일 변경이 같은 흐름에서 보인다.

처음부터 ‘권한 없이 자동 실행’을 목표로 삼지 않는 방법

도입 순서는 작게 잡는 편이 낫다. 먼저 검증용 저장소나 clone 모드에서 변경 대상 파일을 좁히고, 다음으로 필요한 패키지 저장소·소스 관리·배포 API만 네트워크 규칙에 넣는다. 그 뒤 작은 테스트 수정, 의존성 갱신, 문서 생성처럼 결과를 Git diff와 테스트로 쉽게 읽을 수 있는 작업을 맡긴다. 운영 배포, 비밀값 회전, 고객 데이터 접근처럼 영향 범위가 큰 도구 연결은 별도 정책과 검토 경로로 남긴다.

이 순서가 필요한 이유는 격리가 에이전트의 모든 결과를 무해하게 만들지는 않기 때문이다. 직접 마운트의 프로젝트 파일, 프록시가 허용한 외부 요청, 공유한 에이전트 스킬 저장소, MCP 도구는 경계를 넘는 통로다. Sandboxes는 이 통로를 없애기보다 목록으로 드러낸다. 실제 업무에서 자동화를 늘리려면 에이전트에게 매번 “해도 되는가”를 묻는 방식보다, 어떤 파일·도메인·도구가 업무에 필요한지 먼저 정하고 그 밖을 막는 방식이 더 오래 유지된다.

AI 에이전트 실무 도입 시 작업 공간 분리, 네트워크 규칙 확인, 실행 경로 검토 순서로 진행하는 방법을 보여 주는 도식 — 격리 환경을 실제 업무에 연결할 때 작업 범위, 통신 범위, 배포 전 검토를 순서대로 좁히는 방법.

출처: Docker, “Docker Sandboxes”; Docker Docs, “Docker Sandboxes”; Docker Docs, “Security model”; Docker Docs, “Architecture” (2026-08-10 확인)