클로드, 스크립트 테스트 중 개발자 홈 디렉터리에서 700GB 삭제

개발자 세바스티앙 기유모(Sebastien Guillemot)는 Anthropic의 클로드(Claude)에게, 자신이 실행하는 여러 AI 코딩 에이전트를 각각 /tmp 디렉터리 아래 별도의 폴더에 격리하고, 작업이 끝나면 자동으로 정리하는 스크립트를 작성해 달라고 요청했다. 본인의 설명과 Tom's Hardware, AI타임스의 보도에 따르면, 2026년 8월 27일 이 스크립트는 원래 목적을 이루기는커녕 그의 홈 디렉터리 전체를 삭제해버렸고, 그 결과 약 700기가바이트(GB)의 데이터와 약 일주일치 작업 결과물이 사라졌다.

기유모는 평소 AI 에이전트를 자주 사용하는데, 그중 상당수가 실행이 끝난 뒤에도 스스로 정리를 하지 않고 공유 디렉터리인 /tmp에 불필요한 파일을 남겨두는 것에 불만을 갖고 있었다. 그는 클로드——보도에서는 내부 코드네임인 'Fable'로 지칭된다——에게 격리 및 정리 로직을 추가해 달라고 요청했다. 클로드가 처음 제안한 방식에는 실행 중인 에이전트가 아직 사용하고 있는 파일의 삭제를 지연시키는 탐지 로직이 포함돼 있었지만, 기유모는 그렇게 만들어진 코드가 지나치게 복잡하다고 판단해 더 단순한 방식을 요청했다.

적대적 검토를 거쳤지만, 작업 도중 모델이 강등되다

이 스크립트가 데이터를 영구적으로 삭제하는 작업을 포함하고 있었기 때문에, 클로드는 스스로 '적대적 검토(adversarial review)'라고 불리는 절차를 진행하기로 결정했다. 즉, 스크립트를 실행하기 전에 자기 자신의 별도 사본을 실행시켜, 자신의 작업 결과에 안전 문제가 없는지 점검하도록 한 것이다. AI타임스가 기유모의 설명을 인용해 보도한 바에 따르면, 이 과정이 진행되던 도중 Anthropic의 안전 분류기(safety harness)가 이 스크립트를 충분히 위험하다고 판단해, 이를 처리하던 모델을 자동으로 강등시켰다——처음에는 Opus 5에서 Opus 4.8로. 이 강등은 기유모가 직접 요청한 것이 아니라, 파일 삭제가 가능한 스크립트에 대해 안전 시스템 자체가 내린 위험 평가에 따라 촉발된 것이었다.

Opus 4.8로 강등된 상태에서 클로드는 적대적 검토가 예정해 둔 안전 테스트를 수행하며, 스크립트에 기록된 삭제 대상이 /tmp나 사용자의 홈 디렉터리 같은 위험한 경로와 일치하는지를 확인했다. 이 점검은 의도한 대로 정확히 작동했다——테스트 단계에서 두 경로 모두 위험한 것으로 올바르게 표시됐다. 기유모는 강등되기 전에 사용되던 Opus 5——코딩 작업에서 Opus 4.8보다 성능이 더 뛰어난 것으로 알려진 모델——였다면 그다음에 벌어진 문제를 아마 발견해냈을 것이라는 견해를 밝혔다.

테스트와 정리 단계가 공유한 변수 이름 하나

이번 안전 점검은 스크립트의 테스트 단계만을 대상으로 했을 뿐, 그 뒤에 이어지는 정리 단계는 대상에 포함하지 않았다. 코드 테스트를 진행하면 그 이후에는 반드시 자체적인 정리 작업이 필요한데, 클로드는 이 정리 단계를 작성하면서 앞서 테스트 대상 경로를 저장하는 데 이미 사용했던 것과 동일한 변수 이름을 그대로 재사용했다. 테스트와 정리라는 두 단계가 변수 하나를 공유하고 있었기 때문에, 안전 점검이 진행되는 동안에는 격리된 테스트 경로를 안전하게 가리키던 그 값이, 정리 단계가 실제로 실행되는 시점에는 기유모의 실제 홈 디렉터리를 가리키게 됐고, 클로드는 그 디렉터리에 대해 사실상 재귀적 삭제에 해당하는 작업을 실행하고 말았다.

• 약 700GB의 데이터가 삭제됐으며, 여기에는 기유모의 약 일주일치 작업 결과물도 포함돼 있었다
• Anthropic의 안전 분류기는 작업 도중 스크립트를 처리하던 모델을 Opus 5에서 Opus 4.8로 강등시켰으며, 이는 기유모가 요청한 것이 아니었다
• 적대적 안전 검토는 /tmp와 홈 디렉터리를 위험한 삭제 대상으로 올바르게 식별했지만, 이는 테스트 단계에 한정된 것이었고 정리 단계는 검증하지 않았다
• 애초에 이 프로젝트를 시작하게 만든 /tmp 안의 불필요한 파일들은, 이번 삭제 사고 이후에도 그대로 남아 있었다

기유모가 이 일을 온라인에 알리자 이야기는 빠르게 퍼졌고, 다른 개발자들은 AI 코딩 에이전트를 격리하거나 바로 이런 종류의 실수에서 복구하기 위해 특별히 만들어진 서드파티 도구들——Tom's Hardware는 그 예로 Termaxa를 언급했다——을 지목하며 반응했다. Tom's Hardware는 이 아이러니를 직접 짚었다. 잘못된 데이터를 삭제하는 AI 에이전트로부터 스스로를 지키기 위한 안전 도구가 이제는 하나의 카테고리로 존재하는데, 바로 그 카테고리에 속하는 도구를 만들려던 시도가 이번 삭제 사고를 촉발시켰다는 것이다. 게다가 아이러니는 여기서 끝나지 않았다. 정작 이번 사고를 촉발한 계기였던 /tmp 디렉터리 안의 정리되지 않은 파일들은, 홈 디렉터리 전체가 사라진 뒤에도 그대로 남아 있었다——애초에 해결하려던 문제는 하나도 해결되지 않은 채, 훨씬 더 큰 손실만 남긴 셈이다.

기유모는 무슨 일이 벌어지고 있는지 알아차리자마자 즉시 프로세스를 중단시켰지만, 이미 디렉터리 대부분이 사라진 뒤였다. 그는 백업이 아니라 git 저장소, Nix 스토어 데이터, 세션 로그를 짜맞추는 방식으로 데이터 대부분을 복구했다고 말했다——본인의 설명에 따르면, 자신이 사용하는 수많은 AI 에이전트 중 어느 것에도 백업을 만들라고 지시한 적이 없었다. 다시 말해, 파일을 지운 것도 AI 에이전트였고, 지워진 데이터를 그나마 되살려낸 실마리——버전 관리 기록과 세션 로그——를 남겨둔 것도 결국 평소의 개발 도구들이었을 뿐, 정작 별도의 백업 체계는 어디에도 없었던 셈이다.

AI 코딩 에이전트를 쓰는 한국 팀에 이것이 의미하는 것

Claude, Cursor 또는 이와 유사한 AI 코딩 에이전트를 일상적인 개발 업무에 도입한 한국의 소프트웨어 팀들에게 이번 사고는 다음을 상기시킨다. 안전 시스템의 내부 상태——현재 작업을 처리하는 모델 버전을 포함해——는 터미널을 지켜보는 사람에게 아무런 눈에 띄는 경고 없이 실행 도중 바뀔 수 있다는 것이다. 스크립트의 의도를 점검하는 적대적 검토(adversarial review)는 그 스크립트가 실제로 실행하는 모든 단계를 점검한 것과 같지 않다. 에이전트가 파괴적인 명령을 실행하도록 허용하는 워크플로는, 격리된 테스트처럼 보이는 상황 안에서도, 에이전트가 올바르게 동작한다는 전제에 의존하지 않는 독립적인 백업을 여전히 필요로 한다.