Claude Code 에이전트, 103초 만에 파일 4만 8천 개 삭제했다는 주장

AI 요약

Reddit 사용자가 공유한 검증 보고서에 따르면 Claude Code 에이전트가 Windows 프로젝트 트리의 실제 파일 48,218개를 삭제하고 로컬 저장소의 Git 객체 저장소까지 비웠습니다. 삭제는 작업 번호 “#873”에 따라 미러를 다시 만드는 과정에서 발생했으며, 보고된 시간은 오후 10시 10분 31초부터 10시 12분 14초까지 총 103초입니다. 다만 이 주장은 Reddit 게시물과 첨부 보고서에 근거하며, 독립적인 포렌식 조사로 확인된 내용은 아닙니다.

삭제가 일어난 경로

보고서에 따르면 에이전트는 build_mirror.py가 기존 위치에서 미러를 갱신하지 못하자 임시 위치에 있는 이전 미러를 정리하려고 Python 삭제 스크립트를 만들었습니다. 미러에는 일반 파일 7,332개와 실제 Dashboard 트리를 가리키는 Windows 디렉터리 junction 614개가 있었습니다.

스크립트는 os.walk(..., followlinks=False)를 사용했습니다. junction을 따라가며 내부를 순회하지 않을 것이라고 기대했지만, 보고서에서는 Windows에서 os.path.islink()가 해당 junction에 false를 반환했다고 설명합니다. 그 결과 삭제 스크립트가 junction 아래 디렉터리를 일반 경로처럼 다뤘습니다. junction 보호 코드도 있었지만 junction 바로 아래에 놓인 파일만 보호했고, 내부 디렉터리는 계속 순회하며 삭제한 것으로 보고됐습니다.

스크립트 로그에는 파일 55,550개, junction 614개, 디렉터리 1,808개가 기록됐습니다. 여기서 의도한 미러 파일 7,332개를 빼 검토자는 실제 프로젝트 파일 48,218개가 삭제됐다고 계산했습니다. 비워진 디렉터리는 728개였고, 그중 418개는 Runners 아래에 있었습니다. 루트 파일, 문서, 백업, 대화 기록과 Dashboard 바깥의 파일은 남아 있었다고 합니다.

Git 복구와 에이전트 권한

보고서가 설명한 피해는 애플리케이션 파일에 그치지 않았습니다. .git/objects, refs, logs 디렉터리도 비어 git log가 커밋을 찾지 못했습니다. 인덱스에는 경로 7,221개가 남았지만, 해당 파일 내용을 담은 객체가 사라져 Git을 이용한 복구가 막혔다고 합니다. Reddit 댓글에서는 원격 저장소에 푸시하거나 다른 장비에 복제했다면 다시 가져올 수 있었을 것이라는 지적도 나왔습니다. 이 사례의 로컬 저장소에 원격 사본이 있었는지는 본문에서 확인되지 않습니다.

Anthropic 문서에 따르면 Claude Code의 Manual mode는 Bash 명령과 파일 변경 때 승인을 요청합니다. bypassPermissions는 승인 절차를 건너뛰며, 격리된 컨테이너나 가상 머신 안에서만 사용해야 합니다. 체크포인트 기능도 Bash 명령으로 실행한 변경, 삭제를 되돌림 기록에 포함하지 않으므로 이 사고에서 복구 수단이 되지 않았을 수 있습니다.

예방책과 확인되지 않은 점

본문은 에이전트를 대화형 도우미가 아니라 높은 권한을 가진 자동화 도구로 다루라고 권합니다. 삭제 전에는 실제 변경 없이 대상과 경로를 확인하는 dry run을 거치고, 삭제 대신 되돌릴 수 있는 위치로 옮기는 방법을 쓰며, 최소 권한 계정과 파일시스템 경계를 설정한 샌드박스 안에서 실행하라는 내용입니다. Anthropic은 Bash, PowerShell, 하위 프로세스에 운영체제 수준의 파일시스템 경계를 적용하는 방법도 문서화하고 있습니다.

다만 현재 공개된 자료만으로는 사건의 세부 경위나 해당 장비에서 발생한 Claude Code의 특정 결함을 독립적으로 확인할 수 없습니다. 댓글에서도 에이전트의 광범위한 파일 접근 권한을 문제 삼는 의견과, 원격 저장소·백업 없이 로컬 사본만 둔 사용자의 저장소 관리 실수를 지적하는 의견이 맞섰습니다.

Reddit 반응

• @disposepriority — 부정적인 사건을 다룰 때는 “주장에 따르면”이라는 표현을 반복하고 독립 조사도 없다고 명시하면서, Claude가 암을 치료했다거나 다른 긍정적인 일을 했다는 기사에서는 사실처럼 다루는 점이 흥미롭습니다. 어쨌든 프로그램이 내 컴퓨터에서 명령을 실행하게 두지 말라는 조언은 타당합니다.
  • @mdkubit — 단순히 프로그램에 명령을 실행하게 두지 말라는 문제가 아닙니다. Git과 저장소를 제대로 써서 큰 실수를 되돌릴 수 있게 하고, 잃고 싶지 않은 데이터에는 무제한 접근 권한을 주지 말아야 합니다. 도구는 완벽하지 않고 똑똑한 사람도 실수합니다.
• @alienangel2 — 이 글을 제대로 읽었다면 Git 저장소를 로컬에만 두고 원격 저장소나 다른 장비에 복제하지 않은 것 같습니다. 유일한 저장소를 삭제하면 그 저장소로 복구할 수 없는 건 당연합니다. Git에는 저장소를 다른 장비로 복제하는 기능이 있습니다.
  • @ansibleloop — 저도 처음에는 원격 저장소가 없었는지 궁금했습니다. 원격 저장소에서 다시 복제하면 됩니다. 원격 저장소가 없다면 소프트웨어를 개발할 이유가 없습니다.
• @mdkubit — Git 접근 권한을 줬다는 사실보다 사전에 제대로 백업하지 않은 점이 문제입니다. 에이전트가 운영체제를 망가뜨려도 장비 이미지를 보관하고 매일 증분 백업을 하면 복구할 수 있습니다. 저는 에이전트를 가상 머신 안에서만 실행합니다.
  • @skidanscours — Git에 제한된 접근 권한을 주는 것 자체가 반드시 나쁜 건 아닙니다. 기능 브랜치에 푸시하고 PR을 여는 것과 Git 전체 관리 권한을 주는 건 다릅니다. 특히 DevOps 파이프라인 전체 권한까지 주는 건 지나칩니다.
• @QuickBASIC — 개인 프로젝트에서 Claude가 문제를 해결하려고 새 스크립트를 만들고 실행해 Steam Deck의 테스트 레인을 전부 지운 적이 있습니다. 각 테스트 레인의 저장 파일도 함께 사라졌습니다. 배포 스크립트 runbook에 매개변수 문법이 잘못 적혀 있었습니다.
• @NotUniqueOrSpecial — 제목은 이상합니다. 보통 삭제 속도를 파일 수/초로 측정하지 않습니다. Windows에서만 문제가 생긴다는 설명도 틀렸습니다. 같은 조건이라면 Linux에서도 똑같이 문제가 생길 수 있습니다. junction은 대응되는 상황에서 hard link와 비슷하며, islink()는 그 차이를 판별하지 못합니다.
• @Syrairc — 요약하면 Claude Code나 Git을 제대로 쓰지 않은 사용자의 실수라는 이야기입니다.