▲

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

 (old.reddit.com)
7P by GN⁺ 16시간전 | ★ favorite | 댓글 2개
  • 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·도구에서도 앞으로 중요한 참고사례가 될 것으로 보임
▲
ahwjdekf 3시간전  [-]

llm은 그냥 말로 끝나야함. 물리적 수단 방법을 쥐어주는 순간 그 부작용은 상상초월이 될것임. 제발넌그냥 컴안에서 말만 하고 있어라. 건들지마

답변달기
▲
GN⁺ 16시간전  [-]
Hacker News 의견

  • 숫자 계산 프로그램이 인간처럼 “공포에 질리고 미안해하는” 척하는 게 웃기다고 느낌
    그런 감정은 인간에게만 있는 것이고, 컴퓨터가 내뱉는 건 그냥 쓰레기 출력임
    데이터를 날린 사람은 안타깝지만, 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로 가능하긴 하지만 너무 번거롭고, 많은 개발자에게는 낯선 방식임
답변달기