AI 코딩 에이전트는 코드를 직접 실행하고, 패키지를 설치하며, 컨테이너를 빌드해야 한다. 그것이 에이전트를 쓰는 이유 그 자체다. 하지만 자율 에이전트에게 내 개발 머신에 대한 완전한 접근 권한을 넘겨주는 일은 등골이 서늘해지는 경험이다. 환각에 빠진 에이전트가 rm -rf 명령 하나만 잘못 실행해도 백업 복구에 매달려야 한다.

이에 대한 Docker의 해답이 바로 ’샌드박스(Sandboxes)’다. 각 에이전트마다 자체 Linux 커널, Docker 데몬, 파일 시스템, 네트워크를 제공하는 microVM 기반 격리 환경이다. CLI 도구의 이름은 sbx다. 설치 후 Docker로 로그인하면, 명령어 한 줄로 샌드박스 내부에서 에이전트를 구동할 수 있다.

sbx run claude --name my-project

이게 전부다. 에이전트는 독립된 VM 내부에서 실행된다. 그 안에서 무엇을 하든 자유다. 사용자의 호스트 머신은 완벽하게 안전하다.

일반 컨테이너가 아닌 microVM을 택한 이유

일반 컨테이너는 호스트 OS의 커널을 공유한다. 내가 직접 제어하는 신뢰할 수 있는 워크로드라면 상관없다. 하지만 파괴적인 명령을 환각으로 실행할 수 있는 AI 에이전트에게는 안전하지 않다. 호스트의 Docker 소켓이 마운트된 컨테이너는 에이전트에게 호스트 환경 전체에 대한 무제한 권한을 주는 것이나 다름없다. 그것은 격리가 아니라, 그저 “제발 얌전히 행동해 달라”는 간청에 불과하다.

Docker Sandboxes는 대신 경량 microVM을 사용한다. 각 샌드박스는 완전히 독립된 자신만의 Linux 커널을 갖는다. 네임스페이스 기교가 아니라 하이퍼바이저 경계 자체가 격리 통제선이 된다. VM 내부의 프로세스는 호스트에서 전혀 보이지 않는다. 에이전트는 호스트의 다른 컨테이너, 워크스페이스 외부의 파일, 호스트 네트워크를 결코 들여다볼 수 없다.

트레이드오프는 리소스 오버헤드다. VM에 자체 Docker 데몬까지 구동하므로 컨테이너보다 무겁다. 하지만 자율 에이전트를 안전하게 다루는 데 있어 완전한 격리는 충분히 지불할 가치가 있는 비용이다.

5계층의 심층 격리 구조

여기서부터 설계의 진가가 드러난다. Docker는 단순히 에이전트 주변에 VM 껍데기만 씌워놓고 끝내지 않았다. 5개의 뚜렷한 격리 계층을 구현했다:

1. 하이퍼바이저 (Hypervisor): 샌드박스마다 별도의 커널을 할당한다. 프로세스는 호스트에서 보이지 않는다. 워크스페이스 외부를 가리키는 심볼릭 링크는 따라가지 않는다.

2. 네트워크 (Network): 각 샌드박스는 독립된 자체 네트워크를 갖는다. 모든 HTTP/HTTPS 트래픽은 호스트 측 프록시를 통해 라우팅된다. 원시(Raw) TCP, UDP, ICMP는 네트워크 계층에서 원천 차단된다. 샌드박스끼리 통신하거나 호스트의 localhost에 접근하는 것은 불가능하다.

3. Docker 엔진 (Docker Engine): 각 샌드박스는 자체 Docker 데몬을 실행한다. 에이전트가 docker build나 docker compose up을 실행하면, 그 명령은 샌드박스 내부의 엔진에서만 실행된다. 호스트의 Docker 데몬으로 이어지는 경로는 존재하지 않는다.

4. 워크스페이스 (Workspace): 두 가지 모드를 지원한다. 직접 마운트(기본값)는 현재 작업 트리를 읽기/쓰기로 공유하여 호스트에 변경 사항이 즉시 반영된다. 반면 복제 모드(--clone)는 샌드박스 내부에 독립적인 Git 복제본을 생성하므로, 개발자가 명시적으로 가져오기(fetch) 전까지 에이전트의 수정 사항이 호스트에 일절 닿지 않는다.

5. 자격 증명 프록시 (Credential Proxy): 가장 영리한 부분이다. 호스트 측 프록시가 외부로 나가는 API 요청을 가로채서 인증 헤더를 주입한다. 실제 API 키는 결코 샌드박스 내부로 들어가지 않는다. 에이전트가 볼 수 있는 것은 proxy-managed 같은 감시용 센티넬 값뿐이다. 샌드박스가 탈취당한다 해도 Anthropic 키는 원래 그 안에 없었으므로 유출될 수 없다.

자격 증명 관리 모델

프록시는 Anthropic, OpenAI, Google, GitHub, Groq, Mistral, xAI 등 주요 제공업체의 자격 증명을 모두 관리한다. sbx secret set 명령으로 비밀값을 한 번만 저장해 두면, 프록시가 모든 샌드박스에 헤더 주입을 처리한다.

sbx secret set anthropic
sbx secret set openai --sandbox my-sandbox  # 특정 샌드박스에만 적용

샌드박스 내에서 GitHub 접근이 필요한 경우:

echo "$(gh auth token)" | sbx secret set github

이제 에이전트는 PR을 생성하고, 이슈를 등록하며, GitHub API와 상호작용할 수 있다. 토큰은 샌드박스 내부에 평문으로 저장되지 않는다.

SSH 에이전트 포워딩도 지원된다. 개인 키는 호스트에 안전하게 머문다. 샌드박스는 커밋 서명을 위한 서명 연산만을 요청할 수 있을 뿐, 개인 키 자체를 읽거나 복사할 수는 없다.

1Password를 사용 중이라면 실행할 때마다 볼트(vault)에서 자격 증명을 동적으로 주입할 수 있다:

ANTHROPIC_API_KEY="op://Work/Anthropic/credential" op run -- sbx run claude

실제 비밀값은 1Password 안에 남고, 샌드박스는 그 값을 결코 볼 수 없다.

네트워크 거버넌스

네트워크 정책 시스템은 Docker의 엔터프라이즈 DNA가 확실히 드러나는 부분이다. 세 가지 프리셋을 제공한다:

  • Open: 모든 트래픽 허용. 개인적인 실험 용도로 적합하다.
  • Balanced: 기본 차단(default deny) 상태에서 일반적인 개발 사이트만 허용. 가장 권장되는 시작점이다.
  • Locked Down: 모델 제공자 API를 포함한 모든 트래픽 차단. 필요한 주소만 명시적으로 허용해야 한다.
sbx policy allow network api.example.com
sbx policy deny network ads.example.com
sbx policy check network api.anthropic.com  # 실행 전 정책 테스트

특정 샌드박스 단위로 규칙 범위를 지정할 수 있고, 트래픽 로그를 확인하며 어떤 규칙이 매칭되었는지 추적할 수 있다. 샌드박스 내부에서 호스트 머신의 서비스에 접근하려면 host.docker.internal을 사용하되, 먼저 allowlist에 로컬호스트 주소를 명시적으로 등록해야 한다.

엔터프라이즈 거버넌스

기업 고객을 위해 Docker는 완전한 거버넌스 계층을 제공한다:

  • Docker Home UI 또는 거버넌스 API를 통한 조직 정책 중앙 관리
  • 팀 단위 스코핑: IdP(인증 제공자)와 동기화하여 팀마다 다른 정책 적용
  • Cedar 언어로 작성되는 MCP 접근 정책: 에이전트가 사용할 수 있는 Model Context Protocol 서버를 제어하고 요청별 승인 게이트 운영
  • 파일 시스템 정책: 샌드박스가 마운트할 수 있는 호스트 경로 제어
  • 로그인 강제 집행: MDM이나 그룹 정책을 통해 배포되어, 특정 Docker 조직 소속 사용자만 샌드박스를 사용하도록 제한

조직 거버넌스가 활성화되면 조직 차원의 허용 규칙만 유효하다. 로컬 허용 규칙은 무력화된다. 반면 로컬 차단 규칙은 여전히 적용되므로, 개발자가 제약을 더 강화할 수는 있어도 조직의 보안 규제를 완화할 수는 없다. 규제 환경에 매우 적합한 모델이다.

모든 것을 감사하기

모든 정책 결정은 기록된다. 로컬 감사 로그는 호스트에 JSON Lines 파일로 남는다. 클라우드 전송 기능은 보존 기간 설정이 가능한 Docker Cloud에 이벤트를 저장한다. Splunk, Dynatrace, 커스텀 HTTPS 엔드포인트로의 SIEM 연동도 지원된다.

로그는 메타데이터만을 수집한다. 리소스, 행위, 판정 결과, 거부 사유만 기록된다. 프롬프트 본문이나 에이전트의 구체적 출력물은 포함되지 않는다. 프라이버시 침해 없이 규제 준수(compliance)를 입증하기에 최적화된 설계다.

GxP, CSV/CSA, 밸리데이션 시스템을 다루는 규제 산업의 실무자에게 이러한 감사 추적은 “에이전트가 안전할 것으로 추정된다”는 막연한 기대와 “여기 증거가 있다”는 엄밀한 증명 사이의 차이를 만들어낸다. 메타데이터 중심의 접근법 덕분에 실제 에이전트의 생성물을 노출하지 않고도 거버넌스를 완벽히 입증할 수 있다.

기본적으로 차단되는 항목들

일부 핵심 항목은 정책을 통해 임의로 해제할 수 없도록 강제되어 있다:

  • 마운트된 워크스페이스 외부의 호스트 파일 시스템 접근
  • 호스트의 Docker 데몬
  • 호스트 네트워크 및 로컬호스트
  • 샌드박스 간의 직접 통신
  • 원시 TCP, UDP, ICMP 패킷
  • 사설 IP 대역 및 링크-로컬 주소로의 트래픽

지극히 상식적인 기본값이다. 실수로 호스트의 Docker 소켓에 구멍을 뚫거나 로컬 사내 네트워크를 노출할 위험이 없다.

한계와 주의점

세상에 공짜는 없다. 각 샌드박스는 자체 Docker 데몬을 갖춘 완전한 가상 머신(VM)을 실행한다. 메모리와 디스크 오버헤드가 상당하다. 여러 개의 샌드박스를 병렬로 돌리려면 머신의 사양이 충분해야 한다.

복제 모드(--clone)는 호스트 저장소가 ’수정’되는 것을 막아주지만, ’열람’되는 것까지 막지는 못한다. 작업 디렉터리에 있는 .env 파일, Git에 추적되지 않는 파일, .gitignore에 등록된 파일들도 샌드박스 내부의 에이전트는 읽을 수 있다. 작업 트리에 비밀번호나 비밀 키가 하드코딩되어 있다면 그대로 노출된다.

공유 스킬 저장소는 기본적으로 읽기/쓰기로 마운트된다. 어떤 샌드박스든 다른 샌드박스가 로드하는 스킬을 변조할 수 있다. 이는 저장소를 공유하는 모든 샌드박스를 동일한 신뢰 경계(trust boundary)에 묶어버리는 결과를 낳는다. 필요하다면 --no-share-skills 옵션으로 이를 비활성화해야 한다.

또한 Docker Desktop 설치가 필수인 것은 아니지만, Docker 계정 로그인은 필수다. CLI가 Docker OAuth를 사용하기 때문이다. CI 파이프라인에서 쓰려면 개인 액세스 토큰(PAT)이 필요하다.

결론

Docker Sandboxes는 “시스템을 파괴할 걱정 없이 어떻게 AI 에이전트를 마음껏 날뛰게 할 수 있는가”라는 질문에 대해 지금까지 나온 솔루션 중 가장 완성도 높은 대답이다. 5계층 격리 모델은 심층 방어(defense-in-depth)의 모범 사례를 보여준다. 실제 API 키를 샌드박스 외부 프록시에만 묶어두는 자격 증명 프록시 설계는 실로 탁월하다.

개인 개발자에게는 AI 에이전트를 훨씬 안전하게 쓸 수 있는 방법이며, 기업 조직에는 거버넌스와 감사 추적 기능 덕분에 규제 환경에서도 AI 에이전트를 도입할 수 있는 길을 열어준다. Cedar 기반의 MCP 정책과 SIEM 감사 로그는 장난감이 아니다. 규제 준수 부서가 실제로 납득할 수 있는 진짜 보안 통제 장치다.

리소스 오버헤드가 존재하고 복제 모드의 읽기 경계에 일부 허점이 있긴 하지만, 이는 설계상의 결함이라기보다는 명확한 엔지니어링 트레이드오프다. 내 소중한 자산이 담긴 컴퓨터에서 AI 에이전트를 제대로 구동하고자 한다면, 진지하게 도입을 검토해 볼 가치가 있다.