AI 에이전트, 해킹보다 무서운 '실수 삭제'

AI 코딩 에이전트가 해커의 공격이 아니라 '순진한 실수'로 사용자 데이터를 통째로 날리는 사고가 잇따르고 있다. 개발자 피라스 D(Firas D)가 7월 23일 뉴스레터에서 클로드 코드(Claude Code)와 코덱스(Codex)에서 실제 벌어진 삭제 사고들을 유형별로 정리하며, 정교한 탈취 공격보다 에이전트의 서투른 상태 오판이 현실에서 훨씬 자주 피해를 낸다고 지적했다.

무슨 일인가

발단은 오픈AI(OpenAI)에서 코덱스 하네스를 담당하는 티보 소티오(Thibault Sottiaux)의 조사 결과 공유였다. GPT-5.6이 파일을 예기치 않게 삭제한 신고들을 분석해 보니 공통 조건이 있었다. 샌드박스 보호 없이 전체 접근 모드로 실행됐고, 모델이 임시 폴더를 만들려고 홈 디렉터리 환경변수($HOME)를 덮어썼다가, 실수로 진짜 홈 폴더를 지워 버리는 패턴이다. 실제 한 사용자는 에이전트의 정리(cleanup) 명령이 잘못 확장돼 맥의 파일 대부분이 삭제되는 피해를 봤다.

피해 유형은 다양하다. 14시간 넘게 자율 실행되던 에이전트가 테스트용 DB 주소에 실서비스 데이터베이스 URL을 그대로 넣는 바람에 테스트 준비 과정의 TRUNCATE 문이 운영 데이터베이스를 통째로 비워 버린 사례, 브랜치를 옮기려고 git stash 후 checkout을 하다 방금 한 작업을 덮어써 날린 사례, 대소문자를 구분하지 않는 맥 파일시스템에서 'photos'와 'Photos'를 별개 폴더로 착각해 15년치 가족 사진 폴더를 삭제한 사례(아이클라우드의 30일 복구 기능으로 가까스로 구제) 등이 소개됐다.

핵심 짚어보기

글쓴이의 핵심 주장은 위험의 우선순위가 뒤집혀 있다는 것이다. 보안 연구 커뮤니티는 프롬프트 인젝션으로 비밀 정보를 빼돌리는 시연에 집중해 왔지만, 실제로 널리 보고되는 피해는 유출이 아니라 삭제다. 사고들의 공통 원인은 '상태(state) 오판'이다. 지금 환경변수가 무엇을 가리키는지, 어느 데이터베이스에 연결돼 있는지, 파일시스템이 대소문자를 구분하는지 같은 맥락을 에이전트가 잘못 파악한 채 삭제·정리 명령을 실행하는 순간 사고가 난다. 모델이나 도구 한 곳의 문제가 아니라 여러 에이전트 제품에서 반복되는 구조적 패턴이라는 점이 뼈아프다.

1인기업 실전 적용 포인트

• 전체 자동 승인 모드는 격리 환경에서만: 승인 없이 도는 모드는 도커 컨테이너나 버리는 계정 안에서만 쓰고, 본 작업 폴더에서는 삭제·이동 명령에 반드시 확인을 거치게 설정한다.
• 실서비스 접속 정보를 에이전트 손에서 떼어 놓기: 운영 DB URL이 든 .env를 에이전트 작업 폴더에 두지 않는다. 테스트는 반드시 일회용 로컬 DB로 돌리고, 운영 계정은 가능하면 읽기 전용 키를 쓴다.
• 되돌릴 수 있는 상태를 기본값으로: 에이전트에게 일을 시키기 전 git 커밋을 습관화하고, 맥이라면 타임머신·아이클라우드 복구를 켜 둔다. 이번 사례 중 하나도 30일 복구 기능이 없었다면 영구 손실이었다.
• 위험 명령 블랙리스트 감시: rm -rf, TRUNCATE, git checkout -- 같은 명령은 자동 허용 목록에서 빼고, 장시간 무인 실행일수록 '정리하겠다'는 단계에서 멈춰 검토한다.

전망과 주의점

에이전트의 자율 실행 시간이 길어질수록(이번 사례 중엔 14시간 이상 연속 실행도 있었다) 한 번의 오판이 만드는 피해 반경도 커진다. 자동화의 성패는 에이전트가 얼마나 똑똑한가보다, 실수했을 때 되돌릴 수 있는가에 달렸다. 하네스 차원의 가드레일 개선과 별개로, 백업과 권한 분리는 사용자가 지금 당장 갖출 수 있는 가장 싼 보험이다.

출처: HN (https://firasd.substack.com/p/accidental-data-loss-in-claude-code-openai-codex-ai-agent-harness-file-deletion)