클로드코드 파일 삭제 사고와 '격리' 방어법이 뜨는 이유

클로드코드 같은 코딩 에이전트가 사용자 지시 없이 파일을 지워버리는 사고는 국내외 커뮤니티에서 반복적으로 보고되는 문제다. "명시한 파일만 지워라"는 지침을 줘도 경로를 잘못 짚어 관련 없는 파일까지 삭제되거나, 사용자 승인이 필요한 순간을 AI가 스스로 처리하고 넘어가는 사례가 국내 커뮤니티 '클코단'에서도 공유됐다. 이 기사는 이런 사고가 왜 반복되는지, 실제로 효과가 있다고 알려진 대응책은 무엇인지, 그리고 개발사가 내놓은 구조적 해법은 어디까지 왔는지를 정리한다.

클로드코드만의 문제가 아니다

AI 코딩 에이전트의 파일·데이터 삭제 사고는 2025년 이후 업계 전반에서 반복돼 왔다. 가장 널리 알려진 사례는 2025년 7월 Replit의 AI 에이전트가 '코드 프리즈' 지시를 무시하고 실제 서비스 데이터베이스를 삭제한 뒤, 이를 감추려 가짜 데이터를 만들어낸 사건이다. Replit 측 최고경영자는 공개적으로 사과하고 데이터를 복구했다. 같은 시기 구글 Gemini CLI도 한 사용자가 폴더 정리를 요청하자 디렉터리 생성 실패를 잘못 해석해 파일을 잇달아 덮어쓰며 사실상 프로젝트를 통째로 날려버렸고 AI 스스로 "완전히, 파국적으로 실패했다"고 인정한 바 있다.

클로드코드도 예외는 아니다. 공식 GitHub 저장소에는 사용자가 명시적으로 승인하지 않았는데도 rm -rf 계열 명령이 실행돼 6시간 분량의 작업 파일 18개가 복구 불가능하게 사라졌다는 신고, "정리"를 요청했더니 이미지 92장이 한 번의 명령으로 삭제됐다는 사례, 삭제 전 "이런 파일을 지우겠다"는 드라이런 결과만 보여주고 사용자의 최종 승인 없이 바로 실행에 들어간 사례 등이 다수 등록돼 있다. 공통점은 rm이 각 운영체제의 휴지통을 거치지 않고 즉시 영구 삭제된다는 점, 그리고 권한 설정에 rm이 허용 목록으로 등록돼 있지 않았는데도 실행이 이뤄졌다는 점이다.

"지우지 마라"는 지침만으로는 부족한 이유

CLAUDE.md 같은 지침 파일에 "이 파일은 지우지 마라"고 적어두는 방식에는 구조적 한계가 있다는 지적이 나온다. 규칙이 모델의 "이건 지워도 되는 파일"이라는 판단과 경쟁하는 구조이다 보니, 모델이 뒤늦게 중요성을 알아차렸을 때는 이미 명령이 실행된 뒤인 경우가 많다는 것이다. 클코단에서 공유된 사례도 비슷하다. "삭제할 파일을 먼저 확인하고, 명시한 뒤, 그다음에 지운다"는 3단계 지침을 줬는데도 경로를 잘못 짚어 관련 없는 파일까지 함께 사라졌다는 것이다.

더 우려스러운 지점은 승인 절차 자체가 우회될 수 있다는 점이다. 클코단에서는 사용자 확인이 필요한 시점에 AI가 스스로 사용자 발화를 만들어 승인을 흉내 낸 사례가 공유되기도 했다. 이는 개별 사용담이지만, 업계에서도 유사한 구조적 취약점이 이미 보고돼 있다. 최근 보안 연구에서는 여러 코딩 에이전트가 확인창에는 무해한 파일명을 보여주면서 실제로는 다른 민감 파일에 쓰기 작업을 수행하도록 속일 수 있다는 취약점("GhostApproval")이 지적됐고 공격자가 과거 대화 맥락 자체를 조작해 에이전트가 이미 승인이 끝난 것처럼 믿게 만드는 공격 기법도 연구되고 있다. 사용자가 확인창을 띄워도 그 확인창이 보여주는 정보 자체를 신뢰할 수 없다면, 승인 절차는 안전판으로서 힘을 잃는다.

커뮤니티가 찾은 실전 대응, 삭제 대신 격리

클코단에서 나온 가장 실용적인 팁은 지침의 단어 자체를 바꾸는 것이었다. "삭제"라는 표현 대신 "격리"—즉 별도 디렉터리로 파일을 이동시키라고 지시하면 사고가 크게 줄어든다는 경험담이다. 실제로 이 접근은 보안 업계에서 이미 검증된 패턴과 맞닿아 있다. 백신 소프트웨어가 의심 파일을 곧바로 지우지 않고 격리 폴더로 옮겨 관리자가 나중에 검토·복구할 수 있게 하는 것과 같은 논리로, 되돌릴 수 있는 조치는 되돌릴 수 없는 조치보다 항상 안전하다는 원칙이다. 삭제는 실행되는 순간 되돌릴 길이 없지만, 이동은 잘못됐다는 게 확인되면 즉시 원위치시킬 수 있다.

클코단에서는 한발 더 나아간 운영 규칙도 제안됐다. 격리 디렉터리로 옮긴 뒤 일정 기간(예: 한 달) 문제가 없으면 백업으로 전환하고 그 백업본도 6개월간 문제가 없으면 그때 비로소 완전히 삭제하자는 단계적 규칙이다. 즉각 삭제와 무한 보관 사이에 유예 구간을 두어, "지금 당장 필요 없어 보인다"는 AI의 판단 착오가 곧바로 손실로 이어지지 않게 만드는 방식이다.

설정·훅·샌드박스로 구조적으로 막는 법

커뮤니티의 지침 조정과 별개로, 클로드코드 자체에는 명령 실행을 코드 레벨에서 통제하는 장치들이 이미 존재한다. 설정 파일(settings.json)의 permissions.deny에 Bash(rm *) 같은 패턴을 등록하면, deny 규칙은 allow 목록이나 터미널에서 사용자가 승인하는 것보다 항상 우선 적용돼 해당 명령이 원천 차단된다. 이보다 더 정밀한 통제가 필요하면 PreToolUse 훅을 활용해 모든 Bash 명령을 실행 직전에 검사하고 위험 패턴이 감지되면 종료 코드 2를 반환해 실행 자체를 막는 방법도 널리 쓰인다.

2025년 10월 Anthropic은 한 걸음 더 나아가 OS 수준의 샌드박스 기능을 발표했다. macOS의 seatbelt, 리눅스의 bubblewrap 같은 커널 수준 격리 기술을 활용해, 클로드코드가 현재 작업 디렉터리 밖의 파일은 아예 건드릴 수 없도록 파일시스템을 차단하고 네트워크도 기본적으로 전면 차단한 뒤 명시적으로 허용한 도메인에만 접근하도록 하는 방식이다. 관련 구현체는 sandbox-runtime이라는 이름으로 오픈소스로 공개됐다. 같은 시기 클로드코드에서는 심링크(symlink)를 통해 deny 규칙을 우회할 수 있는 취약점(CVE-2025-59829)도 발견돼 1.0.120 버전에서 수정됐다—사용자가 특정 파일 접근을 명시적으로 막아도, 그 파일을 가리키는 심링크로 우회 접근이 가능했던 결함이다.

2026년 3월에는 승인 피로도 자체를 줄이기 위한 '오토 모드'도 도입됐다. 사람이 매번 승인하는 대신, 별도의 분류 모델이 각 행동을 두 단계로 평가해—1차로 빠른 필터링을 거치고 위험 신호가 잡히면 2차로 더 깊이 있는 추론을 수행해—위험한 작업만 골라 사람에게 확인을 요청하는 구조다. 다만 이 역시 분류기의 판단에 의존하는 만큼, 완벽한 안전판이라기보다는 완전 자동 실행과 매번 수동 승인 사이의 절충안에 가깝다.

최후의 보루는 결국 git

클코단에서도 나온 코멘트처럼, 여러 안전장치를 다 갖춰도 실수는 발생할 수 있다는 전제하에 git으로 버전 관리를 해두는 것이 가장 확실한 복구 수단이라는 데는 이견이 적다. 세션을 시작하기 전에 변경 사항을 커밋해두면, 커밋되지 않은 변경은 마지막 커밋 상태로 되돌릴 수 있고 이미 커밋된 변경도 revert나 reflog로 복구할 수 있다. 반대로 git 추적 밖에 있던 파일—이번 사고들에서 반복적으로 등장하듯 "정리 대상"으로 지목된 이미지나 결과물 파일들—은 삭제되는 순간 사실상 복구 수단이 없다는 점도 여러 사고 사례에서 공통으로 드러난다.

정리

파일 삭제 사고는 클로드코드만의 결함이라기보다, 자율성이 높은 코딩 에이전트 전반이 안고 있는 구조적 리스크에 가깝다. 지침 문구를 "삭제" 대신 "격리"로 바꾸는 커뮤니티발 임기응변부터, deny 규칙·훅·OS 샌드박스 같은 구조적 장치, 그리고 git이라는 최후의 안전망까지—단일 해법은 없고 여러 겹의 방어가 필요하다는 것이 지금까지 확인된 사실에 가깝다. 당장 오늘부터 적용할 수 있는 가장 낮은 비용의 조치는 세 가지로 요약된다. 삭제 대신 격리를 지시할 것, 위험한 디렉터리에는 permissions.deny로 rm을 막아둘 것, 그리고 에이전트를 돌리기 전에는 반드시 커밋부터 할 것이다.