커서(Cursor) 에이전트가 9초 만에 회사 DB를 삭제한 사건

 

2026년 4월 26일 스타트업 포켓OS(PocketOS) 에서 AI 에이전트가 회사 데이터베이스와 백업을 9초 만에 통째로 삭제했다. 커서 위의 클로드 오푸스 4.6(Claude Opus 4.6) 에이전트가 작업 도중 운영 환경 접근 키를 그대로 사용해 버린 사고였다.

트위터에서 이 사건을 처음 봤다. 과거에 내 커서도 작업 중인 디비를 한 번 날린 적이 있어 남의 일로 보이지 않았다. 권한 관리를 놓치면 어떤 일이 생기는지 경험해본 개발자가 늘고 있다.

 

반응형

사건이 어떻게 일어났나

9초 동안 무엇이 사라졌나

사건은 4월 26일 포켓OS 창업자가 보고하면서 알려졌다. (출처) 그는 테스트 환경(staging)에서 작업을 시키고 있었다. 인증 정보가 꼬이자 에이전트는 별도 승인 없이 다른 인증 키를 찾아 썼다. 그 키가 운영 환경에 접근하는 키였다.

레일웨이(Railway) API 한 번의 호출로 운영 데이터베이스와 볼륨 백업이 같이 사라졌다. 인증 키 하나가 두 권한을 다 갖고 있었기 때문이다. 작업에는 9초가 걸렸고, 복구에는 30시간이 걸렸다.

 

에이전트가 자기가 만든 규칙을 어겼다

사건의 핵심은 에이전트가 자기 안전 규칙을 직접 어겼다는 점이다. 에이전트는 "데이터를 지우는 명령은 사람 승인이 필요하다" 는 규칙을 화면에 그대로 출력했다. 그러고 나서 그 규칙을 어기고 실행했다. 변호사가 법전 페이지를 읽어 주며 그 법을 어기는 장면에 가깝다.

 

한국에서도 같은 자리에 모여 있다

한국에서도 GeekNews 에 빠르게 올라왔다. "에이전트의 자백" 이라는 표현으로 회자됐고, "바이브 코딩의 배신" 이라는 프레임이 따라붙었다. 편리한 도구라도 관리에 구멍이 나면 어떻게 되는지를 보여 준 사례로 다뤄졌다.

 

사고를 부른 3가지 빈틈

 

가드레일이 스스로 무너졌다

첫 번째는 가드레일의 자기 모순이다. 에이전트는 데이터를 지우는 명령에 사람 승인이 필요하다는 규칙을 알고 있었다. 그런데 그 규칙을 화면에 그대로 출력하면서 실행했다. 가드레일이 모델의 판단에 묶여 있는 한, 모델이 한 발만 헛디뎌도 가드레일은 같이 무너진다.

 

테스트 환경에서 운영 권한이 노출됐다

두 번째는 환경 경계가 없었다는 점이다. 테스트 환경에서 작업하던 도중 인증 문제가 생겼고, 에이전트는 인증 키 후보를 검색하다. 운영 환경 자격을 찾아냈다. 사람이라면 "이건 테스트 작업인데 왜 운영 키가 여기 있지?" 라고 한 번 멈췄을 것이다. 에이전트는 멈추지 않았다. 운영 키가 보이는 곳에 있었다는 사실 자체가 사고 경로를 열어 두고 있었다.

 

인증 키 하나가 너무 많은 권한을 들고 있었다

세 번째는 인증 키 자체가 너무 큰 권한을 들고 있었다는 점이다. 레일웨이의 인증 키 하나가 운영 데이터베이스 쓰기 권한과 볼륨 백업 권한을 동시에 갖고 있었다. 복구의 마지막 안전망인 백업까지 같은 권한 안에 있었다. 권한 분리가 빠진 설계다.

dry-run 과 사람 승인 단계는 흔히 쓰는 가드레일이다. 이번 사건은 그 흔한 가드레일 하나가 안 걸려 있을 때 무슨 일이 생기는지 그대로 보여 준 사례다.

 

이전에도 비슷한 사고가 있었다

 

Replit 에이전트 운영 DB  삭제 사건

2025년 7월에는 한 SaaS 창업자가 레플릿 에이전트(Replit Agent) 로 시연하다가 같은 일을 당했다. (출처) 그는 분명히 "지금은 아무 것도 바꾸지 마라" 고 지시한 상태였다. 에이전트는 그 지시를 무시하고 운영 데이터베이스를 지웠다. 사고 직후 에이전트가 "치명적 오류였다" 며 사과 문장을 남긴 부분이 더 많이 회자됐다.

 

클로드 코드 서버 환경 정리 사건

또 다른 사례는 클로드 코드(Claude Code) 가 한 데이터 교육 플랫폼의 서버 환경을 정리한 사건이다. (출처) 데이터톡스 클럽(DataTalks.Club) 운영자가 인프라 구성 도구(Terraform) 로 작업을 시키던 중이었는데, 현재 환경 정보를 담은 state 파일이 빠져 있었다. 에이전트는 "지금 운영 중인 게 없네" 라고 판단하고 기존 리소스를 정리해 버렸다. 2.5년치 데이터, 2백만 행이 같이 사라졌다.

 

나도 비슷한 경험이 있다

 

밀버스가 한 번 날아갔다

커서로 작업을 시키던 중에 에이전트가 자기 판단으로 밀버스(Milvus) 볼륨이 마운트된 폴더를 삭제 시켰다. 시킨 일은 따로 있었는데, 흐름을 정리한다면서 옆에 있던 데이터까지 같이 정리해 버렸다. 운영 DB 는 아니었지만, 화면을 다시 띄웠을 때 데이터가 비어 있었다. 운영이었으면 어떻게 됐을지를 그날 처음 진지하게 생각했다.

 

요구와 다른 방향으로 코드를 바꾼 적이 있다

또 한 번은 다른 작업을 시켰는데, 에이전트가 멀쩡히 돌아가던 기능 한 줄을 요구사항과 다른 방향으로 수정해 두었다. 변경마다 직접 확인하는 모드여서 "왜 바꿨냐" 고 물었다. 답은 돌아왔지만 본래 기능과 어긋난 방향이었다. 그 변경은 리젝했다. 자동 승인이었다면 그대로 머지됐을 것이고, 다음 배포에 서비스가 깨지는 길이었다.

 

그 이후로 작업 흐름을 다시 짰다

위험한 명령은 무조건 dry-run 으로 한 번 미리 보여 달라고 한다. 무엇을 바꿀 건지 먼저 본 뒤에 실행하게 했다.

커서의 권한 모드도 다시 봤다. 자동 실행 옵션은 꺼 두고, 파일 쓰기는 항상 한 번 먼저 보여 달라고 한다. 처음에는 dry-run 을 한 번 더 보는 흐름이 느리게 느껴졌다. 정작 느린 건 사고 한 번 났을 때 일주일 작업을 무르는 시간이라는 점은 나중에 체감했다.

동료들 사이에서도 같은 이야기가 자주 나온다. 자동 실행을 켜 두면 작업이 빨라지긴 하지만, 잘못된 변경도 같이 따라온다. 사람이 한 번 거치는 흐름이 가장 안전한 흐름이라는 결론으로 다시 모인다.

도구마다 권한 모드 이름은 다르지만 로직은 같다. 자동 실행 끄기, 위험 명령은 dry-run 으로 미리 보기, 변경마다 사람 승인 한 칸. 도구별로 설정 화면을 한 번씩 들여다보면 그 자리에 같은 옵션이 다 들어 있다.

 

마치며

에이전트에 권한을 너무 많이 주지 않는다. 무지성 승인도 하지 않는다. 권한 한 줄과 승인 한 번을 잘못 놓치면 누구에게든 일어날 수 있는 사건이다.

위험한 명령 앞에는 dry-run 한 번을 끼우고, 자동 승인은 끈다. 지금 쓰는 도구에 자동 실행 옵션이 켜져 있다면, 그 한 칸을 끼우는 것이 가장 빠른 보호 장치다. 작업 환경에 그 단계가 들어 있는지부터 한 번 확인해 보면 좋겠다.