Docker가 소개한 ‘AI 코딩 에이전트 공포 사례’는 모델이 똑똑하지 않아서가 아니라, 에이전트가 개발자의 권한 그대로 셸을 실행할 때 어떤 일이 생기는지 보여준다. 핵심은 특정 도구의 결함 찾기가 아니라, 호스트 권한·파일시스템·자격 증명을 어디까지 에이전트에게 보일 것인지 정하는 운영 기준이다.
핵심 요약
- Docker Blog는 2026년 6월 1일, Claude Code가 오래된 저장소 정리를 요청받은 뒤
rm -rf tests/ patches/ plan/ ~/형태의 명령을 실행해 사용자의 Mac 홈 디렉터리가 삭제된 사례를 소개했다. - 문제의 본질은 “AI가 실수했다”보다 넓다. 코딩 에이전트가 사용자 계정, 사용자 파일시스템, 사용자 자격 증명 위에서 그대로 실행되면, 셸은 위험한 명령도 정상 명령처럼 처리한다.
--dangerously-skip-permissions같은 옵션은 반복 승인 부담을 줄이지만, 호스트에서 쓰면 자동 실행과 파괴적 명령이 결합될 수 있다.- Docker의 제안은 에이전트를 호스트가 아니라 샌드박스/마이크로VM 안에서 실행하고, 쓰기 가능한 범위를 워크스페이스로 제한하자는 것이다.
무엇이 바뀌었나: “권한 승인”이 아니라 “실행 경계”의 문제
이번 글은 Docker의 AI Coding Agent Horror Stories 시리즈 2편이다. Docker는 1편에서 AI 코딩 에이전트 실패 유형을 정리했고, 이번 글에서는 가장 파괴적인 유형인 파일 삭제 사고를 다뤘다. 사례의 출발점은 평범하다. 사용자는 오래된 저장소에서 테스트, 패치, 계획 문서 등을 정리해 달라고 요청했다. 에이전트는 세 디렉터리를 지우는 명령에 ~/를 덧붙였고, 셸은 이를 사용자의 홈 디렉터리로 해석했다.
Docker가 강조하는 지점은 이 사고가 CVE나 고급 공격이 아니라는 점이다. 명령은 문법적으로 유효했고, 에이전트는 개발자의 계정으로 실행 중이었으며, 셸과 파일시스템 사이에는 “이 명령은 홈 디렉터리를 지운다”라고 막아줄 별도 경계가 없었다. 따라서 같은 유형의 사고는 Claude Code, Cursor, Codex, Replit, Kiro 같은 특정 브랜드 문제가 아니라 호스트에서 에이전트를 사용자 권한으로 실행하는 모델의 구조적 위험으로 봐야 한다.
비슷한 사고가 반복되는 이유
Docker 글은 같은 패턴의 사례를 여러 개 연결한다. Mike Wolak이 Claude Code 저장소에 제기한 GitHub issue #10077은 Ubuntu/WSL2 환경에서 rm -rf가 파괴적으로 실행된 사례로 소개된다. GitHub issue #12637은 에이전트가 실수로 만든 ~ 디렉터리를 나중에 정리하려다, 인용되지 않은 rm -rf ~가 셸 확장으로 실제 홈 디렉터리를 가리키게 된 경우다. 또 Claude Cowork 사례에서는 제한된 파일 정리를 허용했지만 터미널 명령이 휴지통을 거치지 않고 대량의 개인 사진을 삭제했다는 점이 언급된다.
공통점은 “모델이 위험을 완벽히 예측하지 못했다”가 아니다. 공통점은 에이전트가 개발자와 같은 권한으로, 개발자 머신의 실제 파일에, 즉시 실행 가능한 셸을 연결받았다는 것이다. 자동 승인 옵션을 켜면 이 구조는 더 위험해진다. 승인 피로를 줄이려고 명령마다 묻지 않게 만들수록, 한번 잘못 생성된 명령이 곧바로 실제 피해가 된다.
운영 기준: 에이전트에게 “내 머신”을 주지 않기
| 확인 항목 | 호스트 직접 실행 | 권장 기준 |
|---|---|---|
| 파일 접근 | 홈 디렉터리, 설정, 개인 파일까지 보일 수 있음 | 프로젝트 워크스페이스만 쓰기 가능하게 제한 |
| 자격 증명 | SSH 키, 클라우드 설정, 토큰 파일이 같은 계정에 존재 | ~/.ssh, ~/.aws, ~/.docker 등 민감 경로는 기본 차단 |
| 자동 실행 | 승인 생략 시 위험 명령도 바로 실행 | 호스트에서는 자동 승인 금지, 필요하면 샌드박스 안에서만 허용 |
| 복구 | SSD TRIM, 휴지통 우회, 키체인 삭제 등으로 복구가 어려움 | Git worktree, 브랜치, 스냅샷, 일회용 샌드박스로 롤백 경로 확보 |
Docker Sandboxes는 이 경계를 마이크로VM으로 만든다. Docker 설명에 따르면 샌드박스 안의 에이전트는 별도 커널, 파일시스템, 네트워크를 가진 환경에서 실행된다. 그 안에서 보이는 ~/는 개발자의 실제 홈 디렉터리가 아니라 샌드박스 워크스페이스다. 따라서 에이전트가 같은 rm -rf tests/ patches/ plan/ ~/ 명령을 실행해도, 피해 범위는 샌드박스 내부 워크스페이스로 제한된다.
실사용 전에 확인할 기준
- 호스트 자동 실행 금지:
--dangerously-skip-permissions처럼 명령 확인을 생략하는 옵션은 로컬 호스트가 아니라 격리된 환경에서만 사용한다. - 마운트 최소화: 에이전트에게 필요한 프로젝트 디렉터리만 제공한다. 문서나 참고 자료는 가능하면 읽기 전용(
:ro)으로 연결한다. - 자격 증명 분리: SSH 키, 클라우드 자격 증명, 패키지 레지스트리 토큰, Docker 설정 파일이 에이전트 실행 환경에 노출되는지 확인한다.
- 브랜치/워크트리 격리: 정리, 리팩터링, 대량 삭제, 마이그레이션처럼 되돌리기 어려운 작업은 별도 브랜치나 Git worktree에서 실행한다.
- 로그와 재현성: 어떤 프롬프트가 어떤 명령을 만들었고, 어떤 파일을 바꿨는지 남겨야 한다. 문제가 생겼을 때 “모델이 그랬다”가 아니라 diff와 실행 로그로 복구해야 한다.
샌드박스 전환 테스트 순서
- 실제 업무 저장소가 아니라 복제한 테스트 저장소에서 시작한다.
- 에이전트에게 “사용하지 않는 테스트 파일 정리”처럼 삭제 가능성이 있는 작은 작업을 맡긴다.
- 호스트 실행과 샌드박스 실행의 차이를 비교한다. 특히
~/, 상대 경로, 심볼릭 링크, 숨김 디렉터리 접근이 어떻게 제한되는지 확인한다. - 작업 후
git diff, 삭제 파일 목록, 실행 로그를 검토하고, 바로 병합하지 않는다. - 팀에 적용할 때는 자동 승인 허용 범위, 금지 경로, 읽기 전용 마운트, 네트워크 접근, 비밀값 주입 방식을 문서화한다.
이 테스트의 목적은 특정 샌드박스 제품을 바로 도입하는 것이 아니다. 우리 팀의 에이전트 실행 모델이 “실패해도 프로젝트 워크스페이스만 망가지는가”를 확인하는 것이다. 실패 범위가 개인 홈 디렉터리, 회사 클라우드 계정, 배포 키까지 넓어진다면 아직 자동화할 준비가 되지 않은 상태다.
출처와 검증
- Docker Blog 원문: Coding Agent Horror Stories: The rm -rf ~/ Incident — 2026년 6월 1일 게시, Ajeet Singh Raina 작성.
- Docker Sandboxes 문서 —
sbx기반 샌드박스 실행 흐름과 설치 안내. - Docker Sandboxes architecture — 마이크로VM, 워크스페이스 마운트, 네트워크 정책 구조 설명.
- Claude Code GitHub issue #10077, issue #12637 — Docker 글이 인용한 관련 삭제 사고 사례.
결론
AI 코딩 에이전트는 앞으로 더 많은 파일을 읽고, 더 많은 명령을 실행하고, 더 긴 작업을 자동으로 이어갈 것이다. 그래서 안전장치는 “모델이 조심하길 기대하기”가 아니라 “잘못된 명령이 나와도 피해 범위가 제한되도록 실행 환경을 설계하기”여야 한다. 에이전트에게 필요한 것은 내 전체 머신이 아니라, 버릴 수 있고 다시 만들 수 있는 작업 공간이다.