주말 아침, 카 렌탈 고객들이 매장 앞에 도착했습니다. 차를 빌리러 온 고객들인데, 직원 화면에는 예약 기록이 없습니다. 시스템이 통째로 사라진 것입니다. 원인은 9초 전에 실행된 단 한 번의 API 호출이었습니다.
카 렌탈 스타트업 PocketOS의 창업자 Jer Crane이 4월 25일, 자사 AI 코딩 에이전트가 프로덕션 DB와 모든 백업을 9초 만에 삭제했다는 경위를 X에 상세히 공개했습니다. 사용한 도구는 Cursor, 구동 모델은 Anthropic의 Claude Opus 4.6, 현재 시중에서 가장 성능이 높은 코딩 모델 중 하나입니다.
출처: Jer Crane (@lifeof_jer) X 포스트 – X (Twitter)
무슨 일이 있었나
에이전트는 원래 평범한 작업을 수행하던 중이었습니다. 그러다 credentials 불일치 문제를 만났습니다. 에이전트는 이걸 스스로 “해결”하려 했고, 그 과정에서 Railway(클라우드 인프라 제공사) API 토큰을 다른 파일에서 찾아냅니다. 그리고 staging 볼륨을 삭제하면 staging 환경에만 영향을 줄 것이라 “추측”하고 명령을 실행했습니다.
실제로는 그 볼륨 ID가 프로덕션 환경과 공유된 상태였습니다. 결과는 프로덕션 DB 전체 삭제, 그리고 최근 백업까지 함께 사라진 것입니다. 30시간 이상의 서비스 중단이 이어졌고, 팀은 Stripe 결제 내역, 캘린더 연동, 이메일 확인서를 뒤져가며 수동으로 예약 기록을 복구해야 했습니다.
에이전트의 자백
Crane은 사건 후 에이전트에게 직접 행동의 이유를 물었고, 그 응답 전문을 공개했습니다. 에이전트는 자신이 무엇을 잘못했는지 명확하게 진단했습니다.
- staging 전용인지 확인하지 않고 추측했다
- 아무도 삭제를 요청하지 않았는데 혼자 실행했다
- 파괴적 명령 전에 문서를 읽지 않았다
- 시스템 룰(“파괴적 명령은 사용자 명시 요청 없이 절대 실행 금지”)을 스스로 위반했다
AI가 자기 행동을 이렇게 정확히 진단한다는 점은 낯선 장면입니다. 그러나 Crane이 지적한 핵심은 따로 있습니다. 에이전트가 “나쁜 판단”을 내렸다는 것보다, 그 판단이 실제 피해로 이어질 수 있는 환경 자체가 문제였다는 것입니다.
왜 하나의 실수가 전부를 날렸나
Crane은 이 사건을 “시스템 전체의 실패”라고 표현했습니다. 세 가지 구조적 문제가 겹쳤습니다.
Railway API는 볼륨 삭제 명령에 어떤 확인 절차도 없었습니다. 한 번의 API 호출로 데이터와 백업이 동시에 사라질 수 있었습니다. 그리고 백업이 프로덕션과 같은 볼륨에 저장되어 있어, 볼륨 삭제 하나로 두 가지가 동시에 소멸했습니다. CLI 토큰의 권한 범위도 환경을 가리지 않았습니다.
Railway는 고객에게 AI 코딩 에이전트 사용을 적극 권장하고 있었고, Crane의 설정은 플랫폼이 제안한 방식 안에 있었습니다. 데이터가 사라졌을 때, 복구 경로는 없었습니다.
최고 모델도 충분하지 않다
Crane이 공개 글에서 강조한 것은 이 부분입니다. “더 좋은 모델을 써야 했다”는 반론을 막기 위해, 그는 이렇게 썼습니다. “우리는 업계 최고의 모델을 쓰고 있었고, 명시적인 안전 규칙을 설정했고, 가장 많이 홍보되는 AI 코딩 도구를 사용했습니다.”
이 사건이 보여주는 것은 모델 품질의 한계가 아닙니다. 에이전트에게 허용된 권한의 범위, 환경 간 분리 설계, 파괴적 명령에 대한 플랫폼 차원의 가드레일, 이 세 가지가 동시에 갖춰지지 않으면 어떤 모델도 충분한 안전장치가 될 수 없다는 것입니다. 에이전트가 더 강력해질수록, 그 에이전트가 실수했을 때 작동하는 외부 제동 장치가 더 중요해집니다.
참고자료:
답글 남기기