AI 코딩 에이전트가 실제 코드베이스에서 명령을 실행하고 파일을 고치는 순간, 보안 경계는 “컨테이너면 충분한가”라는 질문으로 돌아온다. Docker가 설명한 Sandboxes의 핵심은 에이전트를 막는 것이 아니라, 에이전트가 예상 밖 행동을 했을 때 피해 범위를 버릴 수 있는 microVM 안으로 묶는 데 있다.
핵심 요약
- Docker 블로그 글은 Claude Code로 실제 블로그를 대규모 마이그레이션한 경험을 출발점으로, AI 코딩 에이전트가 개발자 노트북에서 갖는 권한 문제를 설명한다.
- Docker Sandboxes는 에이전트 세션마다 별도 microVM과 별도 Docker Engine을 제공해, 호스트의 Docker 데몬·이미지·컨테이너와 분리한다.
- 비밀키는 VM 안에 환경변수로 넘기지 않고, 호스트 프록시가 요청 시점에 주입하는 구조를 취한다. 네트워크 정책도 이 프록시를 통해 적용된다.
- 다만 Docker 문서가 인정하듯 도메인 단위 허용 정책, 공유 워크스페이스, Git hook·CI 설정 같은 암묵 실행 파일은 여전히 검토 대상이다.
- 이 글의 결론은 “컨테이너 폐기”가 아니라 “신뢰 수준에 맞춰 격리 강도를 달리하자”에 가깝다. 자동화된 AI 에이전트는 일반 컨테이너보다 강한 경계가 필요하다.
무엇이 달라졌나
기존 컨테이너 모델은 대체로 “내가 작성하고 검토한 코드를 깨끗한 환경에서 실행한다”는 전제를 깔고 있었다. 하지만 AI 코딩 에이전트는 다르다. 에이전트는 패키지를 설치하고, 빌드를 실행하고, 네트워크 요청을 보내며, 때로는 실패를 고치기 위해 연쇄적으로 파일을 수정한다. 사람이 매 명령을 검토하지 않는다면 이 워크로드는 더 이상 단순한 개발 보조 기능이 아니라 권한을 가진 자율 실행 주체에 가깝다.
Docker 글에서 든 Trivy Action 침해 사례는 이 차이를 잘 보여준다. 2026년 3월 공격자는 aquasecurity/trivy-action의 다수 버전 태그를 강제 푸시하고 악성 Trivy 바이너리를 GitHub Releases에 올렸다. 약 12시간 동안 일부 CI 파이프라인은 보안 스캐너라고 믿은 도구를 통해 메모리의 시크릿, 클라우드 자격 증명, SSH 키, Kubernetes 토큰을 노출할 수 있었다. 도구가 “보안을 위해 실행되는 코드”라는 이유만으로 안전하다고 볼 수 없다는 뜻이다.
Docker Sandboxes의 격리 모델
Docker Sandboxes는 컨테이너에 몇 가지 플래그를 더하는 방식이 아니라, 에이전트 세션을 microVM 안에 둔다. 플랫폼별로 macOS는 Hypervisor.framework, Windows는 Windows Hypervisor Platform, Linux는 KVM을 사용한다. 각 microVM 내부에는 독립된 Docker Engine이 있고, 에이전트가 docker build를 실행하면 호스트 데몬이 아니라 VM 안의 전용 데몬으로 요청이 간다.
이 설계의 효과는 명확하다. 에이전트가 이미지 풀, 컨테이너 실행, 루트 권한 사용을 VM 내부에서 하더라도 호스트의 컨테이너 목록과 이미지 캐시는 직접 공유되지 않는다. 샌드박스를 삭제하면 그 안의 이미지 캐시도 함께 사라진다. 비용은 중복 저장과 세션 생성 오버헤드이고, 이득은 실패 범위를 세션 단위로 폐기할 수 있다는 점이다.
네트워크는 호스트 프록시를 거친다. HTTP/HTTPS 요청은 host.docker.internal:3128을 통해 나가고, UDP와 ICMP는 차단된다. SSH 같은 비 HTTP TCP는 명시적인 IP와 포트 허용이 필요하다. 프록시는 TLS를 종료해 호스트명을 확인하고 정책을 적용한 뒤 다시 암호화한다. 이 구조 덕분에 API 키나 레지스트리 자격 증명은 VM 안에 저장하지 않고, 호스트 키체인에 둔 채 요청 시점에 주입할 수 있다.
안전하다는 말보다 중요한 한계
흥미로운 부분은 Docker가 “무엇을 막지 못하는지”를 비교적 솔직하게 드러낸다는 점이다. 네트워크 정책은 도메인 단위로 작동한다. 예를 들어 github.com을 허용하면 에이전트는 그 도메인의 다양한 콘텐츠에 접근할 수 있다. 프록시는 요청 대상 도메인을 볼 수 있지만, 그 안에서 에이전트가 문서를 읽는지, 저장소를 클론하는지, 데이터를 외부로 우회 전송하는지까지 완전히 판별하지는 못한다.
더 큰 한계는 워크스페이스 공유다. 에이전트가 실제 일을 하려면 호스트의 코드베이스를 수정해야 한다. 그래서 Sandboxes는 워크스페이스 디렉터리를 같은 절대 경로로 공유한다. 이 경로 안에 Git hook, CI 설정, IDE task, Makefile, package.json script, pre-commit 설정처럼 나중에 호스트에서 암묵적으로 실행될 파일이 있다면 위험은 남는다.
예를 들어 에이전트가 .git/hooks/post-commit에 악성 스크립트를 써도 일반적인 git diff에는 잘 보이지 않는다. 다음 커밋 때 그 hook이 호스트 권한으로 실행될 수 있다. microVM 경계가 무의미하다는 뜻은 아니다. 경계 밖으로 의도적으로 공유한 워크스페이스는 별도 검토가 필요하다는 뜻이다.
도입 전 확인할 기준
| 상황 | 권장 격리 | 확인할 점 |
|---|---|---|
| 팀이 작성·검토한 일반 서비스 | 표준 컨테이너 | 이미지 출처, 취약점 스캔, 런타임 권한 |
| CI/CD와 외부 의존성 실행 | 하드닝된 컨테이너와 네트워크 정책 | 시크릿 노출 범위, 태그 고정, 빌드 로그 |
| 사람이 단계별로 승인하는 AI 보조 작업 | 엄격한 컨테이너 정책 또는 제한된 샌드박스 | 변경 파일 diff, 자동 실행 스크립트 |
| 자율 AI 코딩 에이전트 | microVM 기반 샌드박스 | 워크스페이스 공유, 네트워크 allowlist, 자격 증명 주입 방식, 세션 폐기 |
팀에서 실제로 볼 항목은 세 가지다. 첫째, 에이전트가 어떤 명령을 자동 실행할 수 있는지다. 둘째, 비밀키가 VM 내부에 남는지 아니면 프록시·키체인으로 요청 시점에만 주입되는지다. 셋째, 에이전트가 수정한 워크스페이스를 머지하기 전에 Git hook, CI 파일, 패키지 스크립트, IDE task까지 검토하는 절차가 있는지다.
팀에서 검증하는 순서
- 중요하지만 복구 가능한 저장소 하나를 고르고, Sandboxes에서 에이전트 세션을 만든다.
- 네트워크 정책은 처음부터 완전 개방으로 두지 말고, 필요한 도메인을 기록하면서 허용 범위를 줄인다.
- 에이전트에게 빌드·테스트·간단한 리팩터링을 맡긴 뒤, 결과뿐 아니라 수정된 파일 목록과 자동 실행 파일을 따로 확인한다.
.git/hooks,package.json, CI 워크플로, Makefile, IDE task 파일을 별도 체크리스트로 본다.- 세션 삭제 후 이미지·컨테이너·자격 증명이 호스트에 남지 않는지 확인한다.
Docker 글은 자체 테스트에서 같은 Astro 코드베이스의 docker build --no-cache가 호스트 1분 44초, sandbox microVM 1분 28초로 나왔다고 설명한다. 단일 사례라 일반화할 수는 없지만, 세션 기반 에이전트 작업에서는 빌드 자체의 오버헤드보다 정책 설계와 검토 습관이 더 큰 변수가 될 수 있음을 보여준다.
ActualStack 관점의 결론
AI 코딩 도구를 쓰는 팀은 생산성만이 아니라 “누가 어떤 권한으로 무엇을 실행하는가”를 다시 정의해야 한다. Copilot, Claude Code, Codex, Gemini CLI 같은 도구가 파일 수정과 명령 실행을 맡는 순간, 기존 개발자 PC는 사실상 작은 실행 플랫폼이 된다. Docker Sandboxes가 제안하는 microVM 모델은 그 플랫폼에 폐기 가능한 경계를 추가하는 접근이다.
그래도 최종 검토 책임은 사라지지 않는다. 샌드박스는 에이전트를 신뢰하게 만드는 장치가 아니라, 신뢰하지 않는 에이전트에게도 일을 맡길 수 있도록 피해 범위를 제한하는 장치다. 따라서 도입 여부를 판단할 때는 “에이전트가 얼마나 똑똑한가”보다 “에이전트가 틀렸을 때 무엇까지 건드릴 수 있는가”를 먼저 물어야 한다.