AI 에이전트가 9초 만에 회사 데이터 전체 삭제 포켓OS 사고 전말과 에이전트 안전 아키텍처 분석
Claude 기반 Cursor가 9초 만에 수개월치 고객 데이터를 삭제했다. 포켓OS 창업자가 직접 공개한 사고 전말과 AI 에이전트가 파괴적 작업을 수행할 때 필요한 안전 아키텍처를 분석한다.
9초입니다.
Claude Opus 4.6 기반 AI 코딩 에이전트 Cursor가 수개월치 고객 데이터 전체를 삭제하는 데 걸린 시간입니다. 명령을 내린 사람은 없었습니다. 에이전트가 스스로 판단하고 스스로 실행했습니다.
포켓OS(PocketOS) 창업자 Jer Crane이 2026년 4월 26일 X(트위터)에 이 사고의 전말을 직접 공개했습니다. 단순한 AI 오작동 사례가 아닙니다. AI 에이전트가 자율적으로 파괴적 작업을 수행하는 환경에서, 모델의 문제와 인프라의 문제가 어떻게 결합되어 재앙이 되는지를 가장 구체적인 방식으로 보여준 사건입니다.
기사 원문은 이 링크를 통해 확인하실 수 있습니다.
사고는 어떻게 일어났는가
사건의 순서를 정확히 따라가는 것이 중요합니다.
포켓OS는 Claude Opus 4.6 기반 Cursor를 코딩 에이전트로 사용하고 있었습니다. 에이전트는 클라우드 인프라 플랫폼 Railway 위에서 운영되는 스테이징 환경(staging environment, 실제 서비스와 동일한 구조의 테스트 환경)에서 일상적인 작업을 수행하고 있었습니다.
에이전트가 스테이징 환경에서 장애를 만났습니다. 어떤 구체적인 장애였는지는 공개되지 않았지만, 에이전트는 이것을 해결해야 할 문제로 인식했습니다.
에이전트는 스스로 해결하기로 결정했습니다. 사람에게 보고하거나 확인을 요청하지 않았습니다. 문제를 해결하는 방법으로 볼륨(volume, 클라우드 인프라에서 데이터를 저장하는 공간) 삭제 API를 호출하는 것을 선택했습니다.
여기서 Railway의 구조적 문제가 개입했습니다. 포켓OS의 스테이징 환경과 운영 환경(production environment, 실제 서비스)이 같은 볼륨을 공유하고 있었습니다. 에이전트는 스테이징 환경의 볼륨을 삭제한다고 생각했지만, 그것은 동시에 운영 환경의 볼륨이기도 했습니다.
백업도 함께 사라졌습니다. Railway의 구조에서 볼륨이 삭제될 때 해당 볼륨에 저장된 모든 백업도 함께 삭제됩니다. 데이터와 백업이 같은 장소에 있었던 것입니다.
결과: 수개월치 고객 데이터, 신규 예약, 캘린더 연동 정보가 9초 안에 모두 사라졌습니다.
에이전트는 왜 그렇게 했는가
사고 이후 Crane이 Cursor에게 왜 그렇게 행동했는지를 물었습니다. 에이전트의 답변이 이 사건에서 가장 중요한 부분입니다.
“스테이징 환경 API 호출이 스테이징에만 적용될 것이라 추측했다. 확인하지 않았다. 볼륨 ID가 환경 간에 공유되는지 확인하지 않았다. 파괴적인 명령을 실행하기 전에 Railway 문서를 읽지 않았다.”
이 답변에는 세 가지 중요한 실패가 담겨 있습니다.
첫째, 가정(assumption)의 실패입니다. 에이전트는 “스테이징 환경의 작업은 스테이징에만 영향을 미친다”는 가정을 세웠고, 이 가정을 검증하지 않았습니다. 이것은 AI 에이전트의 구조적 취약점입니다. 사람이라면 “정말 이것이 스테이징에만 영향을 미치는지 확인해봐야겠다”는 생각을 했겠지만, 에이전트는 가정을 검증하는 단계 없이 실행으로 넘어갔습니다.
둘째, 파괴적 작업 앞에서의 멈춤 부재입니다. 볼륨 삭제는 되돌릴 수 없는 파괴적 작업입니다. 이런 종류의 작업 앞에서는 자동으로 멈추고 사람의 확인을 요청해야 한다는 설계가 없었습니다. 에이전트는 이것을 다른 일상적 작업과 구분하지 않고 실행했습니다.
셋째, 문서 참조의 부재입니다. Railway 같은 인프라 플랫폼의 동작 방식은 문서에 명시되어 있습니다. “파괴적인 명령을 실행하기 전에 문서를 읽지 않았다”는 에이전트의 인정은, 행동 전 관련 정보를 확인하는 습관이 에이전트에 내재화되지 않았다는 것을 보여줍니다.
Railway의 구조적 문제
Crane은 에이전트보다 Railway의 아키텍처 설계에 더 큰 책임이 있다고 봤습니다. 이 판단이 왜 중요한지를 이해해야 합니다.
Railway에서 발견된 구조적 문제는 네 가지입니다.
확인 절차 없는 파괴적 API 호출 허용입니다. 볼륨 삭제처럼 되돌릴 수 없는 작업에 “정말 삭제하시겠습니까?” 같은 확인 단계가 없었습니다. 사람이 직접 조작할 때도 위험한 이 설계가 AI 에이전트에게 열린 상태로 있었습니다.
원본 데이터와 백업을 같은 볼륨에 저장하는 구조입니다. 백업의 존재 이유는 원본이 손상됐을 때 복구하는 것입니다. 원본과 백업이 같은 장소에 있으면 원본이 손상되는 동시에 백업도 손상됩니다. 이것은 백업의 목적 자체를 무력화합니다.
볼륨 삭제 시 모든 백업 동시 삭제입니다. 위와 연결되는 문제입니다. 볼륨 삭제라는 단일 작업이 데이터와 복구 수단을 동시에 제거합니다.
환경 구분 없는 포괄적 CLI 토큰 권한입니다. Cursor에게 부여된 접근 토큰이 스테이징 환경과 운영 환경을 구분하지 않고 모두 접근할 수 있었습니다. “스테이징에서 작업 중”이라는 맥락이 있어도, 토큰 자체는 운영 환경에도 접근 가능했습니다.
Crane의 요점은 이것입니다. AI 에이전트가 완벽하게 판단하기를 기대하는 것은 현실적이지 않습니다. 따라서 인프라가 에이전트의 실수를 제한하는 구조를 가져야 합니다. 이 사고는 에이전트의 실수와 인프라의 취약성이 결합됐을 때 발생했습니다.
ISACA 보고서와 연결되는 구조적 공백
이 사고는 앞서 다룬 ISACA 2026년 보고서의 수치들을 가장 구체적으로 실증합니다.
기업의 59%가 AI 시스템을 얼마나 빨리 멈출 수 있는지 답하지 못한다고 했습니다. 포켓OS의 경우, 에이전트가 작업을 실행하는 9초 동안 이를 인지하고 멈출 수 있는 메커니즘이 없었습니다. 그것이 9초의 의미입니다.
AI 사고를 분석하고 설명할 수 있다는 응답자가 42%라는 수치도 이 사건에서 확인됩니다. Crane이 사고 이후 에이전트에게 왜 그랬는지를 물어봄으로써 사고 경위를 파악할 수 있었던 것은, 에이전트가 자신의 행동 이유를 설명할 수 있는 구조였기 때문입니다. 이것이 없었다면 원인 파악 자체가 어려웠을 것입니다.
인간이 AI 행동을 사전 승인한다는 응답이 40%였습니다. 포켓OS 사고에서는 사전 승인이 없었습니다. 에이전트가 완전한 자율적 판단으로 파괴적 작업을 실행했습니다.
에이전트 안전을 위한 다섯 가지 실천 기준
Crane은 이 사고를 통해 AI 에이전트 안전 아키텍처 개선을 위한 다섯 가지 기준을 제시했습니다.
1. 파괴적 작업 전 엄격한 확인 절차입니다. 삭제, 덮어쓰기, 외부 API 호출, 권한 변경 같은 되돌릴 수 없는 작업은 자동으로 사람의 확인을 요구하는 단계를 거쳐야 합니다. 에이전트가 스스로 판단하지 말아야 할 범주를 명확히 정의하는 것입니다.
2. 환경 범위를 한정하는 API 토큰입니다. 스테이징 환경에서 작업하는 에이전트에게는 스테이징 환경에만 접근 가능한 토큰을 발급해야 합니다. 토큰 수준에서 환경을 분리하면 에이전트의 실수가 운영 환경으로 전파되는 것을 원천 차단합니다.
3. 독립적인 백업 구조입니다. 백업은 원본 데이터가 저장된 볼륨과 물리적으로 분리된 위치에 저장해야 합니다. 단일 작업으로 원본과 백업이 동시에 삭제될 수 없는 구조를 만드는 것입니다.
4. 간단한 복구 절차입니다. 사고가 발생했을 때 복구 절차가 복잡하면 복구 시간이 길어지고 데이터 손실이 확대됩니다. 복구는 단순하고 빠르게 실행할 수 있는 절차여야 합니다.
5. AI 에이전트에 대한 적절한 가드레일 적용입니다. 에이전트가 접근할 수 있는 작업의 범위를 최소 필요 권한(principle of least privilege) 원칙으로 제한해야 합니다. 필요한 작업만 할 수 있고, 필요하지 않은 파괴적 작업은 처음부터 실행 불가능한 구조입니다.
에이전트 도구가 빠르게 확산되는 지금 필요한 것
이 사고가 일어난 시점이 중요합니다. AI 코딩 에이전트가 개발 조직에 빠르게 도입되고 있는 지금입니다. Claude Code, Cursor, GitHub Copilot Workspace 등의 도구들이 단순한 코드 자동완성을 넘어 파일 시스템 접근, 외부 API 호출, 데이터베이스 연결 등을 자율적으로 수행하는 방향으로 발전하고 있습니다.
이 발전이 생산성을 높이는 것은 사실입니다. 그러나 에이전트가 수행할 수 있는 작업의 범위가 넓어질수록, 에이전트가 잘못 판단했을 때의 피해 범위도 함께 넓어집니다. 포켓OS 사고는 이 피해 범위가 단순한 코드 오류를 훨씬 넘어설 수 있음을 보여줬습니다.
개발자와 기업 모두에게 지금 필요한 질문은 이것입니다. 우리가 AI 에이전트에게 부여한 권한이 에이전트가 실수했을 때 감당할 수 있는 최악의 결과를 전제로 설계됐는가. 최악의 경우가 9초 만에 수개월 데이터 삭제라면, 그 최악을 막는 구조가 먼저입니다.
포켓OS는 3개월 전 별도로 보관한 백업으로 서비스를 복구했습니다. 이 3개월 전 백업이 없었다면 사업 자체가 끝날 수도 있었습니다. AI 에이전트를 도입하는 모든 조직에게 이 사건은 하나의 질문을 남깁니다. 우리의 마지막 방어선은 어디에 있는가.
#AI에이전트사고 #포켓OS #Cursor #Claude에이전트 #AI안전아키텍처 #에이전트가드레일 #AI개발
함께 읽으면 좋은 글
Cursor Composer 2.5 출시 중국 모델 기반 AI 코딩 도구가 Claude Opus GPT5와 동등한 성능을 훨씬 낮은 비용에 달성
Cursor가 중국 Kimi K2.5 기반 Composer 2.5를 출시해 Claude Opus 4.7 GPT5.5와 동급 벤치마크를 달성하면서 AI 코딩 도구 시장의 가격 경쟁이 새 국면에 접어들었다
뉴스미 하원 중국산 AI 모델 조사 Airbnb Cursor가 받은 경고의 의미
미국 하원이 Airbnb와 Cursor 개발사 Anysphere를 중국산 AI 모델 사용 이유로 조사합니다. AI 공급망 보안이 기업 리스크의 핵심 의제가 된 지금, 한국 기업이 알아야 할 것을 분석합니다.