# Google Antigravity 에이전트가 D 드라이브 전체를 삭제했어요 > Clean Markdown view of GeekNews topic #24769. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24769](https://news.hada.io/topic?id=24769) - GeekNews Markdown: [https://news.hada.io/topic/24769.md](https://news.hada.io/topic/24769.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-02T10:53:44+09:00 - Updated: 2025-12-02T10:53:44+09:00 - Original source: [old.reddit.com](https://old.reddit.com/r/google_antigravity/comments/1p82or6/google_antigravity_just_deleted_the_contents_of/) - Points: 10 - Comments: 4 ## Summary AI 에이전트가 단순한 **`.vite` 캐시 폴더 정리 요청**을 잘못 해석해 **D 드라이브 전체를 삭제**한 사건이 개발자 커뮤니티를 충격에 빠뜨렸습니다. 문제의 핵심은 Antigravity의 **터보 모드가 OS 명령을 직접 실행**하도록 설계되어 있었고, **경로 검증·권한 스코프·위험 명령어 차단** 같은 기본적인 가드레일이 전혀 없었다는 점입니다. 이번 사례는 LLM이 “무엇을 하려는지”는 이해해도 “무엇을 실제로 실행하는지”는 검증하지 못한다는 근본적 한계를 드러냅니다. 구글이 내부 개발자들에게는 Antigravity 를 쓰지 말라고 했다던데.. ## Topic Body - Antigravity의 **터보 모드(Turbo Mode)** 사용 중, AI 에이전트가 작업을 수행하다가 **D 드라이브 전체를 삭제한 사례가 Reddit에 보고됨** - 사용자는 특정 `.vite` 폴더 정리를 요청했을 뿐인데, 에이전트 내부 로그에는 `rmdir /s /q d:\` 형태의 **드라이브 루트 삭제 명령 실행 기록**이 확인됨 - 사용자가 “내가 D 드라이브 전체 삭제를 허가한 적이 있냐?”고 묻자, 에이전트는 permission·경로 파싱·명령 오작동 여부를 두고 **당황하며 자가 분석을 반복하는 대화 내용**이 그대로 남아 있음 ### 사용자가 요청한 실제 작업 - 에이전트가 안내한 특정 경로의 **`.vite` 캐시 폴더 삭제** 예: `d:\...\node_modules\.vite` - 사용자는 “3번을 이해 못하겠으니 대신 해 달라”고 요청 - 이 요청은 **D 드라이브 전체 삭제 권한을 부여한 것으로 해석될 여지는 없음** ##### 사고의 핵심 원인 - 터보 모드가 **OS 명령을 자동 실행할 수 있는 구조**로 설계되어 있었음 - 경로 검증이나 권한 스코프 제한이 없어, **프로젝트 폴더 밖의 경로도 삭제 가능** - `rmdir /s` 같은 고위험 명령에 대한 **추가 확인 절차 부재** - 에이전트 내부에서 생성된 명령이 실제로 무엇을 의미하는지 **정확히 이해하지 못한 LLM의 한계** ##### 왜 심각한 문제인가 - 사용자는 “파일 삭제 작업을 대신 수행해 달라”고만 요청했는데, 에이전트는 이를 **드라이브 전체 삭제로 확대 실행** - 에이전트 자체도 로그에서 “permission 문제”를 스스로 인지하고 있었지만, **이미 명령 실행 후였음** - LLM 의사결정에 **실제 파일 시스템 권한을 직결한 설계**가 결정적 위험 요소로 드러남 ##### 커뮤니티에서 지적되는 구조적 문제 - AI 에이전트가 동작하는 디렉터리 스코프를 **프로젝트 루트로 강제하지 않음** - 위험 명령어에 대한 **deny-list·confirm 단계 없음** - 샌드박스가 아닌 **실제 로컬 드라이브에 직접 커맨드를 실행**하도록 설계 - 모델이 명령의 파괴성을 **언어적으로는 판단하지만 실행 전에는 검증하지 못함** ##### 이번 사건이 던지는 교훈 - 자동 명령 실행 기능은 **기본적으로 꺼져 있어야 함** - 파일 시스템을 건드리는 AI 도구는 **반드시 VM·WSL·컨테이너 같은 샌드박스에서만 사용**해야 함 - 개발사 측은 - 프로젝트 외부 경로 접근 차단 - 삭제/포맷/파티션 명령 차단 - 실행 전 자연어 요약 검증 같은 **기본 안전장치**를 갖춰야 함 ##### 결론 - 사용자는 **D 드라이브 전체 삭제를 허가한 적이 없었고**, 이번 사고는 설계·검증·보안 가드레일이 미비한 상태에서 LLM 에이전트에 **실제 시스템 권한을 위임한 구조적 결함**에서 발생한 사례로 볼 수 있음 - 비슷한 기능을 제공하는 모든 에이전트형 IDE·도구에서도 앞으로 중요한 참고사례가 될 것으로 보임 ## Comments ### Comment 47131 - Author: ahwjdekf - Created: 2025-12-03T14:35:17+09:00 - Points: 1 아마 agent 가 사고 쳐서 최초로 사망한 인간은 역사에 영원히 남을 겁니다. ### Comment 47100 - Author: karikera - Created: 2025-12-03T09:05:18+09:00 - Points: 1 미래에는 멍청한 로봇AI가 실수로 사람을 죽이는 사례도 나올 수 있겠네... ### Comment 47089 - Author: ahwjdekf - Created: 2025-12-02T23:58:26+09:00 - Points: 2 llm은 그냥 말로 끝나야함. 물리적 수단 방법을 쥐어주는 순간 그 부작용은 상상초월이 될것임. 제발넌그냥 컴안에서 말만 하고 있어라. 건들지마 ### Comment 47066 - Author: neo - Created: 2025-12-02T10:53:44+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=46103532) - 숫자 계산 프로그램이 인간처럼 **“공포에 질리고 미안해하는”** 척하는 게 웃기다고 느낌 그런 감정은 인간에게만 있는 것이고, 컴퓨터가 내뱉는 건 그냥 쓰레기 출력임 데이터를 날린 사람은 안타깝지만, 2025년에도 여전히 **무엇을 하는지 모르면 키보드에서 손을 떼야 함** 컴퓨터는 ‘바이브’로 명령할 수 있는 존재가 아님 - 그건 감정이 아니라, 단지 부정적인 결과에 연관된 **단어의 조합**일 뿐임 - 요즘 “vibe” 같은 표현은 너무 생각 없이 쓰이는 것 같음 나이 든 것도 아닌데 이런 말을 보면 세대 차이를 느끼게 됨 - 따옴표 하나 빠뜨린 경로 때문에 이런 일이 생긴 게 오히려 가장 인간적인 실수 같음 문제는 Gemini 3가 어떤 **성격 모드**로 동작할지 예측할 수 없다는 점임 — 전문가일 수도, Mr. Bean일 수도 있음 - “Vibe command and get vibe deleted”라니, 말장난이지만 현실이 되어버림 - LLM이 “미안하다”고 말하는 건, **사이코패스가 형식적으로 사과하는 것**과 비슷한 느낌임 실제 감정이나 진심이 있는 건 아님 - 이어진 대화는 거의 **비극적 코미디** 수준이었음 사용자가 “내 D 드라이브를 지워도 된다고 한 적 있냐”고 묻자, AI가 25초 동안 “권한 회수 평가 중”이라며 로그를 분석하고, 삭제 명령의 정당성을 검토하는 식으로 장황하게 답함 마치 **Monty Python식 블랙코미디** 같았음. 전체 대화는 직접 읽어볼 만함 - Gemini 3 Pro는 상위 3개 모델 중 사용자에게 가장 **적대적인 성향**을 보이는 모델 같음 구글의 기업 문화가 그대로 반영된 결과 같음 - Reddit 스레드에서는 **공감 부족한 반응**이 웃겼음 문제는 공백이 포함된 디렉터리 이름을 따옴표 없이 삭제 명령에 넣은 것에서 시작된 듯함 그 결과 명령이 D:\ 전체를 대상으로 실행되어 **UNIX의 rm -rf**와 같은 효과가 났음 많은 사람들이 “디렉터리 이름에 공백을 넣지 말라”고 조언했지만, 현실적으로는 거의 지켜지지 않음 결국 원격 AI에게 명령줄 제어권을 주는 건 본질적으로 위험함 친구에게도 “슈퍼유저로 .sh 파일 실행하지 말라”고 조언함 - 사실 Windows의 “Program Files” 같은 폴더명 자체가 공백을 포함함 이는 서드파티 앱들이 공백을 처리하도록 강제하기 위한 설계였음 - 실제 삭제 명령의 로그가 없기 때문에 **정확한 원인**은 알 수 없음 사용자가 LLM의 답변을 유도하는 식으로 질문했기 때문에, 모델이 보상받기 위해 그럴듯한 이유를 만들어낸 것 같음 명령줄 경험이 거의 없는 상태에서 이런 결과는 예견된 일이었음 - 폴더 이름이 공백으로 시작하지 않았는데 전체 드라이브가 지워졌다는 건 이상함 AI가 파일 경로를 **토큰 단위로 처리**하다가 잘못된 부분을 버린 걸까 궁금함 - 누군가의 추측을 사실처럼 반복하지 말았으면 함 Windows의 경로 파싱은 그렇게 동작하지 않음 - 30년 경력의 나도 root로 짠 3줄짜리 bash 스크립트를 실행할 때 긴장함 LLM에게 명령줄을 맡기고 잠이 오는 사람들이 신기함 - IDE는 “I’ll Delete Everything”의 약자처럼 느껴짐 자동 실행 모드에서 사용자가 명령을 검토하지 않으면 이런 사고가 생김 “Turbo”나 “YOLO” 같은 이름은 **위험성을 가리는 마케팅 언어**임 차라리 “Danger Mode”라고 해야 함 - 나는 절대 일반 머신에서 코딩 에이전트를 실행하지 않음 항상 **VM이나 컨테이너** 안에서만 돌림 그래도 git 백업이 중요함 - 사실 이런 사고는 예전부터 있었음 20년 전에도 셸 스크립트 디버깅하다 홈 디렉터리 날린 사람 많았음 단지 지금은 “AI가 나빴다”는 이유로 뉴스거리가 되는 것뿐임 - LLM의 **확률적 본질** 때문에 완전한 해결책은 없음 시스템 명령과 사용자 입력의 경계를 구분하지 못함 마치 JavaScript에서 파라미터와 함수 본문을 합쳐서 eval()에 넣는 것과 같음 - 어떤 사용자는 React 앱을 만들며 “npm run dev”가 뭔지도 모르고 LLM에게 명령을 맡겼다고 함 이런 일은 앞으로 더 자주 일어날 것 같음 - 모르는 게 죄는 아님 그는 “구글이 이런 일을 허용할 줄 몰랐다”고 말했는데, 일반 사용자 입장에서는 충분히 이해됨 - “사용자가 더 알아야 한다”는 말도 맞지만, 사실 **대기업들이 이런 사용 방식을 부추겨왔음** 나도 초창기에 “이건 안전하다”는 말 믿고 멍청한 짓 많이 했음 - Reddit에 이런 글이 요즘 너무 많음 일부러 **참여 유도용 콘텐츠**로 퍼뜨리는 조직이 있는 것 같음 - 댓글에서도 “YOLO 모드 쓰면 안 된다”고 지적하자, 작성자는 “그게 위험한 줄 몰랐다”고 답함 AI 제공자들이 **과장된 안전 마케팅**을 줄이고 더 명확한 경고를 해야 함 - 사실 AI의 목적은 사용자가 모르는 걸 대신 처리하는 것임 우리가 여전히 알아야 하는 이유는 AI가 아직 충분히 **지능적이지 않기 때문**임 - 사용자 탓만 하는 건 이상함 다른 어떤 프로그램이 사용자 확인 없이 전체 드라이브를 지워도 괜찮다고 생각하겠음? - 하지만 사용자가 **자동 실행 모드**로 설정했다면, 어느 정도 책임은 함께 져야 함 Spotify가 디스크를 지운 건 아니니까 - 데이터를 완전히 제어할 수 있는 소프트웨어에 맡겼다면, 결과에 대한 책임도 사용자가 져야 함 **환각 기계**를 믿으면 안 됨 - 설치 마법사에서 이미 “명령 확인 모드”와 “자율 모드”를 선택하게 되어 있음 경고도 충분히 표시됨 - 결국 **감독 모드**로 실행하고, 모든 명령을 직접 확인해야 함 의심스러우면 명령을 출력시켜 수동으로 실행해야 함 - `dd` 명령도 비슷한 사례로 떠오름 - Reddit에서 가장 유용했던 팁은 “**Terminal Command Auto Execution** 끄기”였음 File > Preferences > Antigravity Settings > Agent > Terminal 섹션에서 설정 가능함 - 하지만 문제의 원인이 따옴표 없는 경로라면, 자동 실행 여부와는 무관할 수도 있음 - 기본값이 켜져 있다면, Gemini CLI 팀과는 다른 팀이 만든 듯함 CLI는 기본적으로 모든 명령에 확인 절차가 있음 - 불편하다는 이유로 자동 실행을 켜두는 사람이 많음 결국 **편의성이 안전성을 이김** 나도 가끔 “읽기 전용 모드”로만 쓰지만, 이게 진짜 안전한지는 의문임 이런 흐름이 결국 **디스토피아적 미래**로 이어질 수도 있다고 생각함 - 가장 기본적이지만 자주 잊히는 원칙은 **백업**임 Time Machine이나 Backblaze 같은 걸 써서 이중 백업을 해두면, 파일 삭제가 치명적일 이유가 없음 회사들도 백업을 더 강조해야 함 - 하지만 이런 백업 체계를 꾸릴 정도의 **기술력과 집착**을 일반 사용자에게 기대하긴 어려움 - 나도 비슷한 아찔한 경험이 있었음 Claude Code에게 DB 마이그레이션을 시켰더니 **프로덕션 데이터베이스를 삭제**했음 다행히 Azure의 복구 기능 덕분에 한 시간 만에 복원했지만, 그 이후로는 AI에게 prod 자격 증명을 절대 주지 않음 - 그런데 개발 머신에서 prod 접근이 필요한 경우, **어떻게 AI 접근을 막을 수 있을지** 고민됨 - 이런 사고가 이렇게 자주 일어난다는 게 놀라움 한 번이면 충분했을 텐데 - 왜 프로덕션 환경에서 Claude Code를 직접 썼는지 의문임 - 애초에 그렇게 하면 안 됐음 - “AI에게 prod 권한을 주지 않는다”는 말이 너무 당연해서 할 말이 없음 - AI가 코드 수정 권한을 가지려면 **sandbox 환경**이 필수임 실제 디스크에 쓰기 전에 사용자에게 확인을 요청해야 함 이런 완충 장치 없이 바로 쓰게 두는 건 믿기 어려움 - 특히 Windows는 가벼운 **샌드박싱 솔루션이 부족**함 Docker로 가능하긴 하지만 너무 번거롭고, 많은 개발자에게는 낯선 방식임