Google Antigravity 에이전트가 D 드라이브 전체를 삭제했어요

• Google 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·도구에서도 앞으로 중요한 참고사례가 될 것으로 보임