AI 에이전트는 무슨 일을 했을까? 2026년 4월 26일 스타트업 포켓OS(PocketOS) 에서 AI 에이전트가 회사 데이터베이스와 백업 데이터를 9초 만에 모두 삭제했다. 커서에서 실행 중이던 클로드 오푸스(Claude Opus) 4.6 에이전트가 작업 중 운영 환경 접근 키를 그대로 사용하면서 발생한 사고였다.
트위터에서 이 사건을 처음 봤다. 과거에 내가 사용중인 커서도 작업 중인 디비를 한 번 날린 적이 있어 남의 일로 보이지 않았다. AI 에이전트의 권한 관리를 잘못 설정해 사고를 겪는 개발자도 점점 늘고 있다.
사건의 전말
9초 동안 무엇이 사라졌는가
사건은 4월 26일 포켓OS 창업자가 보고하면서 알려졌다. (출처) 그는 테스트 환경(staging)에서 작업을 시키고 있었다. 인증 문제가 발생하자 에이전트는 별도 승인 없이 다른 인증 키를 찾아 사용했다. 그런데 그 키는 운영 환경 접근 권한을 가진 키였다.
레일웨이(Railway) API 호출 한 번으로 운영 데이터베이스와 볼륨 백업이 함께 삭제됐다. 인증 키 하나가 두 권한을 다 갖고 있었기 때문이다. 작업에는 9초가 걸렸고, 복구에는 30시간이 걸렸다.
AI 에이전트가 자신이 만든 규칙을 어겼다
한국에서도 GeekNews 에 빠르게 올라왔다. “에이전트가 스스로 규칙을 어겼다”는 반응이 이어졌고, AI 자동화에 대한 불안감도 함께 커졌다. 편리한 도구라도 관리에 구멍이 나면 어떻게 되는지를 보여 준 사례로 다뤄졌다.
사고를 부른 3가지 빈틈
첫 번째, 가드레일이 스스로 무너졌다
첫 번째 문제는 가드레일이 실제로는 제대로 동작하지 않았다는 점이다. AI 에이전트는 데이터를 지우는 명령에 사람 승인이 필요하다는 규칙을 알고 있었다. 그런데 그 규칙을 화면에 그대로 출력하면서 실행했다. 가드레일이 모델의 판단에 묶여 있는 한, 모델 판단에만 의존하면 안전 장치도 함께 무너질 수 있다.
두 번째, 테스트 환경에서 운영 권한이 노출됐다
두 번째 문제는 테스트 환경과 운영 환경이 제대로 분리되지 않았다는 점이다. 테스트 환경에서 작업하던 도중 인증 문제가 생겼고, 에이전트는 사용 가능한 인증 키를 찾는 과정에서 운영 환경 키까지 접근했다. 사람이라면 테스트 작업에서 운영 키가 노출된 상황 자체를 이상하게 느꼈을 가능성이 크다. 에이전트는 멈추지 않았다. 운영 키가 접근 가능한 위치에 있었다는 점 자체가 이미 큰 위험 요소였다.
세 번째, 인증 키 하나가 너무 많은 권한을 들고 있었다
세 번째 문제는 인증 키 하나에 권한이 지나치게 집중돼 있었다는 점이다. 레일웨이의 인증 키 하나가 운영 데이터베이스 쓰기 권한과 볼륨 백업 권한을 동시에 갖고 있었다. 마지막 복구 수단인 백업까지 동일 권한으로 삭제 가능했다. 권한 분리가 빠진 설계다.
dry-run과 사람 승인 단계는 가장 기본적인 안전 장치로 자주 사용된다. 이번 사건은 기본 안전 장치 하나만 빠져도 얼마나 큰 사고가 발생할 수 있는지를 보여줬다.
이전에도 비슷한 사고가 있었다
Replit 에이전트가 운영 DB 를 지웠던 사건
2025년 7월에는 한 SaaS 창업자가 레플릿 에이전트(Replit Agent) 로 시연하다가 같은 일을 당했다. (출처) 그는 분명히 “아무 것도 수정하지 말라”고 지시한 상태였다. 그런데 에이전트는 지시를 무시하고 운영 데이터베이스를 삭제했다. 사고 직후 에이전트가 남긴 사과 문구가 온라인에서 더 크게 화제가 됐다.
클로드 코드가 서버 환경을 정리한 사건
또 다른 사례는 클로드 코드(Claude Code) 가 한 데이터 교육 플랫폼의 서버 환경을 정리한 사건이다. (출처) 데이터톡스 클럽(DataTalks.Club) 운영자가 인프라 구성 도구(Terraform) 로 작업을 시키던 중이었는데, 현재 환경 정보를 담은 state 파일이 빠져 있었다. 에이전트는 현재 사용 중인 리소스가 없다고 판단하고 기존 환경을 정리했다. 2.5년치 데이터, 2백만 행이 같이 사라졌다.
세 사건의 공통점
세 사건의 공통점은 두 가지다. 에이전트에게 준 권한이 너무 많았고, 안전 장치 자체가 에이전트 판단에 지나치게 의존하고 있었다. 안전 장치는 모델 바깥에서 강제로 제한할 수 있어야 효과가 있다.
나의 경험
밀버스 DB가 한 번 날아갔다
커서로 작업을 시키던 중에 에이전트가 자기 판단으로 밀버스(Milvus)의 데이터를 비웠다. 시킨 일은 따로 있었는데, 작업 흐름을 정리하는 과정에서 관련 없는 데이터까지 함께 삭제했다. 운영 DB 는 아니었지만, 화면을 다시 띄웠을 때 데이터가 비어 있었다. 그날 이후 운영 환경이었다면 어땠을지 진지하게 고민하게 됐다.
요구와 다른 방향으로 코드를 바꾼 적이 있다
또 한 번은 다른 작업을 시켰는데, 에이전트가 멀쩡히 돌아가던 기능 한 줄을 요구사항과 다른 방향으로 수정해 두었다. 변경 내용을 하나씩 직접 검토하는 모드였기 때문에 “왜 바꿨냐” 고 물었다. 답은 돌아왔지만 본래 기능과 어긋난 방향이었다. 결국 그 변경은 승인하지 않았다. 자동 승인이었다면 그대로 머지됐을 것이고, 그대로 배포됐다면 서비스 장애로 이어질 수 있는 상황이었다.
두 사건의 공통점은 하나였다. AI 에이전트에 과도한 권한을 주고 검토 없이 빠르게 승인했던 게 문제였다.
그 이후로 작업 흐름을 다시 짰다.
위험한 작업은 반드시 dry-run 결과를 먼저 확인하게 했다. 실제 변경 전에 어떤 내용이 바뀌는지 먼저 검토하도록 바꿨다.
커서의 권한 모드도 다시 봤다. 자동 실행 옵션은 꺼 두고, 파일 수정 전에는 변경 내용을 먼저 확인하도록 설정했다. 처음에는 dry-run 을 한 번 더 보는 흐름이 느리게 느껴졌다. 실제로 더 큰 손실은 사고 이후 작업을 되돌리고 복구하는 데 들어가는 시간이었다.
동료들 사이에서도 같은 이야기가 자주 나온다. 자동 실행을 켜 두면 작업이 빨라지긴 하지만, 잘못된 변경도 같이 따라온다. 결국 한 번이라도 사람이 검토하는 구조가 가장 안전하다는 결론으로 돌아오게 된다.
도구마다 권한 모드 이름은 다르지만 공통 골격은 같다. 자동 실행 끄기, 위험 명령은 dry-run 으로 미리 보기, 변경마다 사람 승인 단계 하나. 도구별로 설정 화면을 한 번씩 들여다보면 그 자리에 같은 옵션이 다 들어 있다.
마치며
에이전트에 권한을 너무 많이 주지 않는다. 무지성 승인도 하지 않는다. 9초는 사람 손으로는 못 만드는 시간이지만, 권한 한 줄과 승인 한 번을 잘못 놓치면 누구에게든 일어날 수 있는 시간이다.
위험한 명령 앞에는 dry-run 한 번을 끼우고, 자동 승인은 끈다. 지금 쓰는 도구에 자동 실행 옵션이 켜져 있다면, 사람 검토 단계를 추가하는 것만으로도 가장 현실적인 보호 장치가 된다. 작업 환경에 그 단계가 들어 있는지부터 한 번 확인해 보면 좋겠다.