AI 코딩 에이전트를 샌드박스에 넣어도, 안심할 수 없는 이유

핵심 요약 (TL;DR)

AI 코딩 에이전트를 샌드박스에 넣으면 내 맥북과 비밀 파일을 지키는 데 도움이 됩니다. 그러나 샌드박스는 ‘에이전트가 밖으로 나왔는가’를 다루는 장치이지, ‘안에서 무엇을 했는가’를 자동으로 설명해 주는 장치는 아닙니다. 최근 Docker Sandboxes를 다룬 보안 분석은 전용 microVM과 네트워크 정책의 장점을 인정하면서도, 마운트한 작업공간과 허용된 네트워크 안에서의 행동은 별도 관리가 필요하다고 짚습니다.

샌드박스는 정확히 무엇을 막아 주나요?

분석 글에 따르면 Docker Sandboxes는 AI 코딩 에이전트를 전용 microVM에서 실행하고, 작업공간을 마운트하며, 승인한 호스트명만 네트워크로 허용하는 방식을 사용합니다. 이런 경계는 에이전트가 호스트의 다른 파일이나 프로세스에 손대는 위험을 줄이는 데 의미가 있습니다.

특히 실험적 프롬프트나 외부 코드를 다루는 작업에서는 ‘내 개인 컴퓨터 전체’보다 제한된 환경에서 실행하는 편이 낫습니다. 다만 마운트한 프로젝트 폴더는 여전히 실제 파일입니다. 에이전트가 잘못된 지시를 따라 설정을 덮어쓰거나 소스 코드를 삭제하면, 격리돼 있어도 프로젝트 피해는 남을 수 있습니다.

격리와 감사는 왜 다른 문제일까요?

문을 잠그는 것과 방 안에서 무슨 일이 일어났는지 기록하는 것은 다릅니다. 에이전트는 샌드박스 안에서 파일을 읽고 쓰고, 명령을 실행하고, 허용된 서비스로 연결할 수 있습니다. 이 행동을 나중에 확인할 구조화된 기록이 없다면 문제가 생긴 뒤 원인을 추적하기 어렵습니다.

그래서 바이브코더에게는 ‘샌드박스를 켰다’보다 ‘작업 전후에 무엇을 비교할 수 있는가’가 더 실용적인 질문입니다. Git diff, 실행 명령 기록, 테스트 결과, 허용 도메인 목록, 작업 완료 시점의 요약을 남기면 최소한의 감사 흔적이 생깁니다.

혼자 만드는 MVP의 최소 안전선은 무엇일까요?

첫째, 작업 전 커밋을 남기세요. 둘째, 에이전트에 넘길 폴더와 허용할 네트워크 목적지를 최소화하세요. 셋째, 자동 실행은 테스트·초안·리팩터링처럼 되돌리기 쉬운 일부터 시작하고, 배포·결제·비밀값 변경은 사람이 확인하게 두세요. 넷째, 작업이 끝나면 diff와 테스트를 함께 봅니다.

이 원칙은 거대한 보안 체계를 만들자는 뜻이 아닙니다. 빠르게 만드는 동안에도 되돌릴 수 있는 지점을 남기자는 뜻입니다. 샌드박스는 좋은 난간이지만, 운전 기록과 최종 판단까지 대신해 주지는 않습니다.

FAQ: 컨테이너와 microVM 중 무엇이 더 안전한가요?

일반적으로 microVM은 호스트 커널을 공유하는 컨테이너와 다른 격리 모델을 제공합니다. 다만 실제 안전성은 마운트한 파일, 제공한 자격증명, 네트워크 정책, 실행 권한까지 함께 봐야 합니다.

FAQ: 에이전트에게 Git 권한을 줘도 될까요?

테스트용 브랜치에서 시작하고, 원격 push·배포 권한은 분리하는 편이 좋습니다. 자동 커밋이 가능하더라도 병합 전에는 사람이 변경 내용과 테스트를 확인하세요.

출처: https://rye.ai/blog/ai-agent-sandboxes-ebpf-runtime-visibility/
공식 문서: https://docs.docker.com/ai/sandboxes/
관찰 시점: 2026-08-13 KST