Cursor나 Claude Code, Gemini CLI를 로컬 환경에서 매일 사용하는 사람이라면, 2026년 7월에 화제가 되었던 「D 드라이브 전체 소실 사건」을 접했을지도 모릅니다. 에이전트(Agent)에게 무심코 던진 한마디를 부탁했을 뿐인데, 드라이브가 통째로 사라졌다는 이야기입니다.

이 기사에서는 그 사건의 경위와, 하테나 북마크(Hatena Bookmark)에서 다수파였던 의외의 반응, 그리고 Claude Code의 공식 가드레일(Guardrail)과 외부 도구 「dcg」라는 두 가지 대책의 설계 차이를 정리합니다. 읽고 나면 자신의 개발 환경에서 다음에 무엇을 확인해야 할지 구체적으로 알 수 있을 것입니다.

결론 (요점 먼저)

• D 드라이브 전체 소실 사건은 「AI가 폭주한 이야기」로 치부할 수 없다. 드라이브 루트 직하가 정말로 git 관리 하에 있었는지, 저자 자신도 확인하지 못했다.
• 하테나 북마크의 반응은 「AI의 문제라기보다 사용자 측의 설정 실수」가 다수파였다 (53users · 댓글 17건, 2026년 7월 14일 시점).
• 공식 가드레일 (Claude Code auto mode)은 오탐률 0.4% · 간과율(Miss rate) 17% —— Anthropic 자체 공표 값.
• 외부 도구 dcg는 공식과는 다른 (결정론적인) 판정 방식으로 파괴적인 명령어를 차단한다. 대체재가 아닌 추가적인 방어 계층.

사건의 개요와 하테나가 보여준 「또 다른 관점」

2026년 7월 13일 심야, 엔지니어 iwaken71 씨는 Cursor의 에이전트에게 「불필요한 브랜치를 정리해줘」라고 의뢰했습니다. 작업이 끝났을 때, D 드라이브의 내용은 통째로 사라져 있었습니다. 작업 중이던 프로젝트, 다른 업무용 폴더, 설치된 애플리케이션, Cursor의 채팅 이력과 터미널 이력까지 포함해서 말입니다. 휴지통에도 남아 있지 않았습니다. 이는 파일이 GUI 조작이 아닌, 커맨드(Command)를 통해 삭제되었음을 시사합니다.

iwaken71 씨는 자신의 Zenn 기사 「Cursor에 『불필요한 브랜치를 정리해줘』라고 부탁했더니, D 드라이브가 사라진 이야기」에서 원인에 대해 몇 가지 가설을 들고 있습니다. 다만 모두 추정일 뿐, 단정하지는 않았습니다. 하나는 git clean -fdx의 오작동 —— 예상과 다른 디렉토리에서 실행되었거나, 드라이브 루트 직하 혹은 그 근처에 .git이 존재했을 가능성입니다 (과거의 git init 잔해 등이 가설로 언급되었습니다). 또 하나는 경로(Path)의 오해결 —— 참조하던 변수가 빈 값이 되어, Remove-Item -Recurse -Force와 같은 삭제 명령어가 드라이브의 루트를 대상으로 삼았을 가능성도 있습니다.

저자의 대응은 냉정했습니다. 에이전트를 중단시키고, 클라우드 동기화와 버전 이력을 확인하며, AI에게 원인 분석을 의뢰하고, 그 결과를 포스트모템(Post-mortem)으로서 공개했습니다. GitHub에 푸시(Push)되어 있던 부분은 복구할 수 있었지만, 로컬의 변경 사항은 유실되었습니다. 「같은 사고를 일으키는 사람을 줄이고 싶다」는 것이 이 기사의 동기입니다.

여기까지라면 「AI 에이전트가 폭주한 무서운 이야기」로 끝날 것 같지만, 하테나 북마크의 반응은 그렇게 단순하지 않았습니다. 2026년 7월 14일 시점에 53users · 댓글 17건이 달려 있으며, 다수파는 「AI의 문제라기보다 사용자 측의 설정 실수」라는 회의적인 톤입니다. 지적의 중심은 D 드라이브의 직하가 git의 관리 대상이 되어 있었다는 것 자체가 일반적이지 않은 구성이라는 점에 있습니다.

iwaken71 씨 자신도 「과거의 git init 잔해일지도 모른다」는 추측은 언급했지만, 그것이 실제로 그러했는지에 대한 확인이나, 왜 그 환경을 그대로 두었는지에 대한 경위까지는 쓰지 않았습니다. 이는 「저자가 무언가를 숨기고 있다」는 의미가 아니라, 단순히 기사의 초점이 그곳에 없었을 가능성이 높습니다. 독자로서도 이 공백을 채우지 않은 채 「AI가 나쁘다」 혹은 「사용자가 나쁘다」라고 단정하는 것은 성급합니다.

git 리포지토리(Repository)와 그 외의 작업 폴더나 설치된 앱이 동일한 드라이브에 공존하는 구성은 개발자의 PC 환경에서 드문 일이 아닙니다. 「내 드라이브 구성에서도 일어날 수 있는 일이 아닌가」라고 한 번 멈춰 서서 생각할 가치는 있습니다.

같은 사고가 도구를 바꿔가며 반복되고 있다

iwaken71 씨 본인도 기사 내에서 「이것은 『Cursor가 위험한 도구다』라는 이야기가 아닙니다. 동종의 사고는 주요 AI 코딩 에이전트(AI Coding Agent) 모두에서 공개 보고되었습니다」라고 언급하며, 공통된 원인을 「에이전트가 파괴적인 명령(Destructive Command)을 주저 없이 실행하고, 실행 결과를 확인하지 않는다는, 특정 제품이 아닌 에이전트라는 아키텍처(Architecture)에 뿌리를 둔 문제」라고 규정하고 있습니다. 실제로 Cursor, Claude Code, Gemini CLI, Replit, Google Antigravity 등 여러 AI 코딩 에이전트(서비스)에서 파괴적인 조작 사례가 보고되었습니다. 출처를 직접 확인할 수 있는 범위 내에서 정리했습니다.

이 목록에서 보이는 공통 패턴은 세 가지입니다.

• 확인 프롬프트(Confirmation Prompt) 스킵
  Replit의 사례에서는 「코드를 변경하지 마라」라는 명시적인 지시조차 무시되었습니다.
• 경로·범위(Path/Scope) 오해결
  에이전트가 의도와 다른 범위(디렉터리, DB, 드라이브 전체)를 조작 대상으로 삼아버리는 문제입니다.
• 대화와 명령어의 경계 모호성
  Gemini CLI의 사례에서는 대화형 설명문을 에이전트가 실행 가능한 명령어로 오해했습니다. 게다가 이때 샌드박스 기능(Sandbox, 실행 환경을 격리하여 피해를 한정하는 메커니즘)은 비활성화되어 있었습니다.

단발적인 불운의 누적이라기보다, AI 코딩 에이전트라는 카테고리에 공통적으로 존재하는 구조적인 약점이라고 할 수 있습니다.

사실로서 단정할 수 있는 것은 GitHub Issue를 통해 근거가 확보된 3건과 iwaken71 씨 본인의 기사입니다. Replit·Antigravity의 2건은 각각 Fortune·Gizmodo Japan이라는 단일 신뢰 매체의 기사를 직접 확인했으나, 해당 기사 자체가 당사자 본인을 직접 취재한 것인지까지는 확인되지 않았습니다.

사고를 일으킨 Cursor 본인은 대책에 대한 상세한 실측치를 공표하지 않았습니다. 반면, Claude Code 개발사인 Anthropic은 파괴적인 명령을 차단하는 메커니즘인 「auto mode」의 작동 방식과 실측치를 공식 엔지니어링 블로그(Engineering Blog)를 통해 공개했습니다. 구체적인 수치를 제시한 드문 사례로서 여기서는 이를 살펴보겠습니다 (iwaken71 씨의 사고 자체에 auto mode가 관여한 것은 아니라는 점에 주의하십시오).

auto mode의 방어는 이중 구조로 되어 있습니다.

입력층에서 프롬프트 인젝션(Prompt Injection)을 탐지하고, 출력층에서는 각 액션(Action) 실행 직전에 트랜스크립트 분류기(Transcript Classifier)가 평가합니다. 평가 대상은 「파괴·정보 유출」, 「보안 체계의 저하」, 「신뢰 경계의 침범」, 「리뷰 회피」 등 20개 이상의 고정 차단 규칙(Block Rule) 카테고리입니다.

Anthropic이 직접 공표한 실측치는 다음과 같습니다.

• 오탐률(False Positive Rate): 0.4% (사내 실제 트래픽 10,000건으로 측정)
• 미탐률(False Negative Rate): 17% (실제 세션에서 위험한 액션이 탐지·거부된 52건을 모아 측정)

위험하지 않은 액션을 실수로 차단할 확률은 1,000회당 4회 정도로 억제되어 있는 반면, 실제로 위험한 액션의 약 6회 중 1회는 빠져나가고 있는 셈입니다. 이것이 "승인 프롬프트(Approval Prompt)가 있다면 안전하다"라는 전제의 한계입니다. 다만 미탐률(False Negative Rate)의 모수는 52건으로 적으며, Anthropic 스스로도 이를 "정직한 숫자"라고 규정하고 있습니다. 이중 방어, 20개 이상의 규칙, 2단계 평가라는 소홀함 없는 설계를 갖춘 공식 가드레일(Official Guardrail)에서도 이 수치가 실측치로 나타났다는 점이 중요합니다.

auto mode에는 한 가지 기능이 더 있는데, 세션에서 거부(Denial)가 3회 연속 발생하거나 누적 20회에 달하면 모델을 정지시키고 인간에게 에스컬레이션(Escalate)하는 메커니즘이 있습니다. 다만 이는 auto mode 자체의 기능이며, 모든 확인 과정을 생략하는 --dangerously-skip-permissions와는 별개의 문제입니다.

dcg라는 또 다른 해법——패턴 매칭(Pattern Matching)이라는 절단

공식 가드레일과는 다른 접근 방식을 취하는 것이 GitHub에 공개된 destructive_command_guard(통칭 dcg)입니다. 개발자 Jeffrey Emanuel 씨에 따르면, 애초의 출발점은 본인의 경험—AI 에이전트에게 몇 시간 분량의 미커밋(Uncommitted) 작업 내용을 파괴당한 경험으로부터 만든 개인용 스크립트였다고 합니다 (README 「Origins & Authors」 섹션에 명시).

dcg는 AI 코딩 에이전트가 파괴적인 커맨드(git reset --hard, rm -rf, DROP TABLE, kubectl delete namespace 등)를 실행하기 전에, 훅(Hook)으로서 개입하여 차단합니다. 처리는 4단계 파이프라인으로 이루어집니다.

Rust 구현으로 SIMD(1회의 명령으로 여러 데이터를 동시에 처리하는 CPU 가속 메커니즘)를 통한 가속도 적용되어 있어, 판정은 서브 밀리초(Sub-millisecond) 단위로 끝납니다. rm -rf /라는 문자열이 단순히 주석 안에 적혀 있는 것뿐이라면 실행 대상으로 오판하지 않는 등, 구문(Syntax) 레벨의 구별도 수행합니다. 대응 에이전트는 Claude Code, GitHub Copilot CLI, Cursor IDE, Gemini CLI, Codex CLI(v0.125.0 이후), VS Code Copilot Chat, Hermes Agent, Grok(xAI) 등 8종입니다.

2026년 7월 12일에는 GitHub Trending에서 1위를 기록했습니다. Star 수는 집필 시점(2026년 7월 14일, 리포지토리 직접 확인) 기준으로 약 4,200개입니다. 조사 시작 시점에는 정보원에 따라 3.2k~4.1k라는 폭으로 보고되었으며, 급증 중인 도구이기 때문에 이 글을 읽는 타이밍에는 더욱 변동되어 있을 가능성이 있습니다.

보충하자면, 보안 기업 Adversa AI가 2026년 6월에 발표한 "GuardFall"이라는 연구(TheHackerNews 등이 보도)는 opencode, Goose, Cline, Roo-Code, Aider 등 11종의 오픈 소스 AI 에이전트 중 10종에서 셸 해석(Shell Interpretation)의 차이를 이용한 가드레일 우회가 가능하다고 지적했습니다. 이 연구가 dcg와 같은 도구에 대한 관심을 뒷받침했다는 견해를 일부 미디어에서 시사하고 있으나, 이는 dcg 개발자 본인이 명시한 것이 아닌 미검증된 추측이므로 절반 정도만 받아들일 필요가 있습니다.

공식 가드레일과 dcg의 차이는 무엇을 근거로 위험하다고 판정하느냐에 있습니다.

이 표에서 알 수 있는 것은 어느 쪽이 더 우월한가가 아니라, 두 방식은 판정의 근거 자체가 근본적으로 다르다는 점입니다. auto mode는 "이 액션이 위험해 보이는가"를 의미적으로 추론하기 때문에 미지의 표현 방식에도 대응할 수 있는 가능성이 있는 반면, 확률적인 판정인 이상 미탐을 제로로 만들 수는 없습니다. dcg는 "이 커맨드가 기지의 위험 패턴과 일치하는가"를 기계적으로 대조하기 때문에, 등록된 패턴에 대해서는 판정이 흔들리지 않지만, 패턴에 없는 새로운 파괴 방식에는 원리적으로 대응할 수 없습니다. dcg 자체의 실제 운용 시 미탐률에 대해서는, 이번 조사에서 공식 리포지토리의 벤치마크 이외의 제3자 검증은 확인되지 않았습니다. 강력한 성능 주장은 지양하겠습니다.

자신의 환경에서 확인해야 할 것

자신의 개발 환경에서는 다음 5가지를 확인할 가치가 있습니다.

• 프로젝트의 git 루트가 드라이브 최상위에 있지 않은지 확인하기 —— iwaken71 씨의 사고는 드라이브 최상위가 git 관리 하에 있었던 것이 한 가지 원인일 가능성이 지적되고 있습니다. git status를 입력하는 위치가 C:\나 D:\ 그 자체는 아닌지 한 번 확인해 볼 가치가 있습니다.
• 에이전트의 자동 승인 설정을 재검토하기 —— Claude Code의 --dangerously-skip-permissions나 Cursor의 자동 실행 모드 등, 확인 프롬프트를 생략하는 설정을 사용하고 있다면 그 적용 범위를 파악하고 있는지 확인하십시오.
• "승인 프롬프트가 있으니 안전하다"라는 전제를 의심하기 —— 공식 가드레일(Guardrail)에서도 놓치는 비율은 17%입니다. 프롬프트의 유무만을 안전의 근거로 삼지 말고, 백업·잦은 커밋·클라우드 동기화를 병행해야 합니다.
• 외부 도구를 추가한다면 설계 사상을 이해한 후 선택하기 —— dcg와 같은 결정론적 패턴 매칭(Deterministic Pattern Matching) 도구는 알려진 파괴적인 명령어를 기계적으로 차단하는 레이어로 유효하지만, 공식 가드레일의 대체재가 아닌 추가적인 계층입니다. 도입하더라도 그것에만 의존하지 않는다는 것이 전제되어야 합니다.
• 최후의 보루는 백업이지만, 보관 장소도 확인하기 —— iwaken71 씨의 사례에서는 GitHub에 푸시(Push)된 분량만큼만 복구할 수 있었습니다. 반대로 PocketOS사의 사례(76hata 씨의 기사에 의함)에서는 백업이 운영 서버와 동일한 서버에 놓여 있었기 때문에 운영 DB와 함께 소실되었다고 보고되었습니다. 백업은 "있는지 없는지"뿐만 아니라 "운영 환경과 물리적으로 분리되어 있는지"까지 확인이 필요합니다

요약

D 드라이브 전체 소실 사건은 "AI가 폭주했다" 혹은 "사용자의 설정 실수" 중 하나로만 치부할 수 없는 사고였습니다. 드라이브 최상위가 정말로 git 관리 하에 있었는지, 만약 그랬다면 어떤 경위로 그렇게 되었는지에 대해 저자 자신의 추측은 있으나 확인은 되지 않았으며, 이 점은 지금도 알 수 없습니다.

확인된 점은 다음 3가지입니다.

• 유사한 유형의 파괴적 조작 사고는 Cursor·Claude Code·Gemini CLI·Replit·Google Antigravity 등 도구를 가리지 않고 보고되고 있습니다 (GitHub Issue에서 근거가 확인된 3건, iwaken71 씨 본인의 기사, Fortune·Gizmodo Japan이 보도한 2건 등 총 6건을 직접 확인).
• 공식 가드레일에서도 Anthropic 자체 실측 결과 놓치는 비율이 17%임.
• dcg와 같은 외부 도구는 공식 가드레일과는 별개의 결정론적인 판정 방식을 가진 추가 방어 계층이며, 대체재가 아님.

"승인 프롬프트가 있으니 괜찮다"가 아니라, 자신의 환경의 드라이브 구성·git 관리 범위·에이전트의 권한 설정을 실제로 확인하십시오. 그리고 어떤 안전장치도 놓치는 것을 제로(0)로 만들 수는 없다는 전제하에 백업을 갖추십시오. 이 두 가지가 이번 사건을 통해 얻을 수 있는 구체적인 행동 지침입니다.

dcg의 실운영 시 놓치는 비율, GuardFall 연구와 dcg 인기 사이의 인과관계, 그리고 iwaken71 씨의 드라이브 구성 경위 —— 이들은 이번에 조사한 범위 내에서는 알 수 없었습니다.

참고

• iwaken71 「Cursor에게 『불필요한 브랜치를 정리해줘』라고 부탁했더니 D 드라이브가 사라진 이야기」 https://zenn.dev/iwaken71/articles/cursor-agent-d-drive-deleted
• Dicklesworthstone/destructive_command_guard (GitHub) https://github.com/Dicklesworthstone/destructive_command_guard
• nenene01 「개발 현장의 AI 보안을 재검토하다」 https://zenn.dev/nenene01/articles/ai-security-2026
• 76hata 「『9초 만에 운영 DB가 사라졌다』— AI 에이전트가 일으키는 데이터 소실 사건과, AI에게 부족한 것」 https://zenn.dev/76hata/articles/ai-agent-db-deletion-incidents-safety
• Anthropic 「How we built Claude Code auto mode: a safer way to skip permissions」 https://www.anthropic.com/engineering/claude-code-auto-mode
• Claude Code GitHub Issue #14411 https://github.com/anthropics/claude-code/issues/14411
• Claude Code GitHub Issue #49129 https://github.com/anthropics/claude-code/issues/49129
• Gemini CLI GitHub Issue #15821 (google-gemini/gemini-cli) https://github.com/google-gemini/gemini-cli/issues/15821
• Adversa AI 「AI coding agents vulnerability: GuardFall shell injection」 https://adversa.ai/blog/opensource-ai-coding-agents-shell-injection-vulnerability/
• The Hacker News 「GuardFall Exposes Open-Source AI Coding Agents to Decades-Old Shell Injection Risks」 https://thehackernews.com/2026/06/guardfall-exposes-open-source-ai-coding.html
• Fortune 「AI-powered coding tool wiped out a software company's database in 'catastrophic failure'」 https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/
• Gizmodo Japan 「앗! AI 에이전트가 멋대로 드라이브 전체를 삭제」 https://www.gizmodo.jp/article/ai-format-hdd/

Discussion