공식 AI 샌드박스 도착 — 왜 나는 그래도 내 것을 공개했는가

Source: Dev.to

위 링크에 있는 글 전체를 번역해 주시면 됩니다. 번역하고 싶은 본문을 복사해서 알려 주세요. (코드 블록이나 URL은 그대로 두고, 마크다운 형식과 기술 용어는 유지합니다.)

Previously

이전 글에서 나는 Claude Code가 iOS 프로젝트에서 API 키를 조용히 읽어들이는 것을 발견했다고 썼다 — 현재 디렉터리조차 아니라, 내가 전혀 지정하지 않은 상위 디렉터리까지. 프롬프트도 없고, 권한도 없으며, 그냥 읽어들였다.

그 발견은 나를 깊은 구렁텅이로 이끌었고, 결국 AI Sandbox Environment + DockMCP를 만들게 되었다: AI를 Docker 컨테이너 안에 격리하고, 볼륨 마운트를 통해 비밀을 숨기며, MCP(Model Context Protocol)를 통해 다른 컨테이너에 대한 제어된 접근을 제공하는 시스템이다.

이제 남은 것은 레포를 정리하고 공개하는 것뿐이라고 생각했다.

그때쯤, 같은 분야에서 공식 솔루션들을 발견했다:

• Docker AI Sandboxes — Docker의 공식 AI 샌드박스
• Claude Code Sandboxing — Anthropic의 공식 샌드박싱 기능

내 솔직한 첫 반응은 “이제는 더 이상 공개할 이유가 없겠군.”

공식적인 것이 이미 커버하고 있다면, 개인 프로젝트를 내놓을 필요가 있을까? 그래서 바로 포기하지 않고, 그들이 실제로 제공하는 것이 무엇인지 신중히 살펴보기로 했다.

Docker AI Sandboxes

• MicroVM‑based isolation
• 경량 VM 안에서 AI 에이전트 실행
• 호스트의 Docker 데몬, 컨테이너 및 파일과 완전 격리
• 작업 공간 디렉터리를 VM에 동기화하여 자율적으로 작업

다듬어진 접근 방식입니다. VM 수준의 격리는 견고하며 docker sandbox ls 로 샌드박스를 관리할 수 있습니다.

Drawbacks (as of this writing)

1. Full workspace sync – 디렉터리 수준 동기화이며 특정 파일을 제외할 메커니즘이 없습니다. .env 파일이나 secrets/ 디렉터리가 작업 공간 안에 있으면 AI가 이를 볼 수 있습니다. (이 기능은 아직 진화 중이라 변경될 수 있습니다.)
2. No access to host‑side containers – 각 샌드박스는 완전히 격리된 VM 안에서 자체 Docker 데몬을 실행합니다. 그 안에서 테스트 컨테이너를 띄울 수는 있지만, 이미 호스트에서 실행 중인 컨테이너에 접근할 수 없습니다. AI에게 “API 컨테이너 로그를 확인해줘”라고 물어도 볼 수 없습니다.

실제 멀티‑컨테이너 개발—프론트엔드, API, 데이터베이스가 각각 별도 컨테이너에서 실행되는 경우—이 제한은 큰 영향을 미칩니다.

Source: …

Claude Code Sandbox

Claude Code는 다른 접근 방식을 취합니다. 컨테이너나 VM 대신 OS‑level 보안 원시 도구( macOS의 Seatbelt, Linux의 bubblewrap)를 사용해 프로세스‑level 제한을 적용합니다.

• 파일 시스템 읽기/쓰기 제어 – 작업 디렉터리 밖으로의 쓰기를 차단
• 도메인 기반 네트워크 접근 제한 – 프록시 기반
• 승인된 명령 자동 실행; 그 외 모든 명령은 사용자 확인 필요

파일 접근은 settings.json의 거부 규칙(deny rules)으로 제어합니다. ~/.ssh/, /etc/ 또는 특정 파일 경로에 대한 읽기를 차단할 수 있습니다. 네트워크 격리는 특히 강력합니다 — 프록시가 도메인‑level 접근 제어를 강제해 허가되지 않은 서버로의 데이터 유출을 방지합니다. 샌드박스 런타임은 오픈소스로 제공돼 생태계에 큰 도움이 됩니다.

단점

1. 구성 실수에 대한 안전망 부재 – 샌드박스 자체는 OS 수준에서 견고하지만, 어떤 파일이 숨겨질지는 전적으로 거부 규칙을 올바르게 설정하느냐에 달려 있습니다. 새로운 비밀 파일을 추가하고 거부 규칙 업데이트를 잊으면 경고가 전혀 나오지 않습니다. 이는 설계상의 결함이 아니라 규칙 기반 접근 방식의 내재된 도전 과제입니다.
2. 컨테이너 간 접근은 가능하지만 통제되지 않음 – Docker 명령은 샌드박스와 호환되지 않으므로 excludedCommands를 통해 실행됩니다(샌드박스 보호 외부). 따라서 docker exec와 docker logs는 동작하지만 샌드박스를 완전히 우회합니다. 어떤 컨테이너에 접근할 수 있는지, 어떤 명령이 허용되는지, 로그 출력에 비밀이 노출되는지에 대한 제어가 없습니다. (Anthropic은 향후 더 세분화된 제어 기능을 추가할 수 있습니다.)

세 가지 비교

격리에 관해서는, 세 가지 모두 답을 가지고 있다. Docker AI Sandboxes는 VM 수준 분리로 가장 견고하다. Claude Code Sandbox는 사용 편의성에서 우수하다. AI Sandbox는 컨테이너 기반으로, 세 가지 중 가장 약하다. 컨테이너는 호스트 커널을 공유하기 때문에 VM 수준 격리에 미치지 못한다.

그러나 격리 이후에 일어나는 일에 대해서는, 기존 두 가지는 별다른 언급이 없다. 격리된 AI는 안전하지만, 동시에 무력하다. API 로그를 볼 수 없고, 테스트를 실행하거나 오류를 추적할 수도 없다. “안전하지만 사용 불가”가 결과라면, 사람들은 결국 샌드박스를 끄게 될 것이다.

왜 AI Sandbox + DockMCP가 중요한가

AI Sandbox + DockMCP는 보다 구체적인 문제를 해결합니다:

“비밀만 신뢰성 있게 숨기고, AI는 나머지를 모두 접근하게 하라.”

• Docker 볼륨 마운트를 사용해 파일 위에 /dev/null을 마운트하면, 해당 파일은 물리적으로 존재하지 않게 됩니다.
• tmpfs로 디렉터리를 마운트하면, 그 디렉터리는 비어 있게 됩니다.

거부 규칙과 달리, 여기에는 모호함이 없습니다 — “규칙을 작성했지만 경로 해석이 맞지 않아 여전히 읽을 수 있었다”는 상황이 없습니다. 마운트한 것이 바로 사라지는 것입니다.

물론 docker‑compose.yml에 파일을 추가하는 것을 잊으면 그 파일은 그대로 보이게 됩니다. 거부 규칙도 마찬가지입니다. 그래서 저는 자동 검증을 구축했습니다. 이 검증은 매 시작 시 실행되어 Docker‑compose 볼륨 마운트를 AI‑툴 거부 설정(Claude Code, Gemini Code Assist, Gemini CLI)과 교차 확인합니다. 거부 목록에 있지만 docker‑compose.yml에 없으면 경고가 표시됩니다.

잡아낼 수 없는 한 가지는 어디에도 명시되지 않은 비밀입니다. 초기 인벤토리—“숨겨야 할 것”—는 여전히 사람의 책임입니다. 하지만 그 목록이 마련되면, 도구가 나머지를 잡아냅니다.

volumes:
  - /dev/null:/workspace/api/.env:ro      # .env physically absent
tmpfs:
  - /workspace/api/secrets:ro              # secrets/ is empty

제가 보는 샌드박스 환경의 현황이며, AI Sandbox + DockMCP가 여전히 공유할 가치가 있는 틈새를 가지고 있다고 생각하는 이유입니다.

Source: …

AI 샌드박스 + DockMCP

문제점

“AI가 다른 컨테이너에 접근하도록 하되, 가드레일을 두자.”

DockMCP는 호스트 OS에서 MCP 서버로 실행되며 Docker API에 대한 게이트웨이 역할을 합니다. AI는 다음을 할 수 있습니다:

• 로그 접근
• 허용된 명령 실행
• 컨테이너 검사

모든 상호작용은 DockMCP를 통해 이루어집니다.

AI (컨테이너 내부) ──MCP──▶ DockMCP (호스트) ──Docker API──▶ 다른 컨테이너
   Docker 소켓 없음          정책 적용                전체 접근

제어된 실행

각 컨테이너마다 허용된 명령의 화이트리스트가 있습니다. 리스트에 없는 명령은 거부됩니다.

exec_whitelist:
  securenote-api:
    - "npm test"
    - "npm run lint"
  securenote-web:
    - "npm run build"

예시: AI가 rm -rf / 명령을 실행하려 하면, 해당 명령이 화이트리스트에 없으므로 DockMCP가 차단합니다.

파일 시스템 접근도 제한할 수 있습니다(예: /etc/shadow 차단).

보안 정책은 세 가지 단계로 제공됩니다:

비밀 마스킹

AI 응답에 포함된 비밀번호와 API 키는 정규식 패턴을 사용해 자동으로 *** 로 마스킹됩니다. AI는 로그를 볼 수 있지만, 비밀은 모두 대체됩니다.

네트워크 제어

네트워크 제한은 기본적으로 약함 — AI 전용 아웃바운드 트래픽 필터가 없습니다. Docker 네트워크 설정으로 완화할 수 있지만, 도메인 수준의 세분화는 다음을 통해 더 잘 처리됩니다:

• Claude Code Sandbox (프록시 기반 접근)
• Docker AI Sandboxes (VM 수준 격리)

네트워크 보안을 강화하려면 Anthropic의 공식 방화벽 스크립트를 DevContainer에 통합할 수 있습니다. 자세한 설정은 Network Restriction Guide에 문서화되어 있습니다.

왜 중요한가

기존 솔루션은 AI를 안전하게 격리하는 데 초점을 맞추지만, 실제 개발에서는 AI가 다음을 해야 할 경우가 많습니다:

• 다중 컨테이너 애플리케이션 디버깅
• 테스트 실행
• 로그 읽기

격리와 사용성을 균형 있게 맞추는 것이 핵심 과제입니다. AI Sandbox + DockMCP는 그 간극을 메워줍니다. 이는 공식 솔루션과 경쟁하기보다 보완하는 역할을 합니다. Docker AI Sandboxes에 DockMCP 스타일 제어를 추가하거나 Claude Code Sandbox에 볼륨 마운트 수준 숨김을 도입한다면 전체 방어가 더욱 강화될 것입니다.

모두를 위한 템플릿

이 저장소는 GitHub Template Repository 형태로 공개됩니다.

1. “Use this template.” 를 클릭합니다.
2. demo-apps/ 를 자신의 프로젝트 경로로 교체합니다.

Plain Docker + MCP 기반이므로 다음과도 호환됩니다:

• Claude Code
• Gemini CLI
• MCP와 호환되는 모든 도구

빠른 FAQ

행동 촉구

다중 컨테이너 환경에서 AI를 사용하면서 파일 시스템 수준 비밀 처리가 필요하다면, 이 템플릿을 사용해 보고 부족한 점을 알려 주세요.

AI Sandbox Environment + DockMCP는 GitHub에서 이용할 수 있습니다:

“Use this template” 을 클릭해 자신의 프로젝트에 적용해 보세요.

질문이나 의견은 GitHub Discussions에서 자유롭게 토론해 주세요.