원래는 ~였어야 했는데 일상적인 유지 보수 작업 이는 수많은 렌터카 회사가 예약, 결제 및 고객 관리에 사용하는 소프트웨어 플랫폼인 PocketOS에게 최악의 악몽이 되었습니다. 단 몇 초 만에 인공지능 에이전트가 명령을 실행했는데, 그는 운영 데이터베이스와 그 백업 파일을 모두 삭제했습니다.이로 인해 많은 기업들이 수년간 축적된 중요한 정보에 접근할 수 없게 되었습니다.
해당 사건은 Cursor 개발 도구에 통합되어 모델에 의해 구동되는 에이전트와 관련된 것입니다. Anthropic의 Claude Opus 4.6이번 사건은 인공지능에게 민감한 인프라에 대한 직접 접근 권한을 부여하는 것의 위험성을 다시 한번 부각시켰습니다. 기술적 우려를 넘어, 이번 사례는 권한 관리, 백업 아키텍처 및 기타 여러 측면에서의 문제점을 드러냈습니다. 사이버 보안 전략 그리고 업계가 실제 환경에 AI 에이전트를 배포하는 방식 충분한 "핸드브레이크".
평범한 작업이 어떻게 재앙으로 변했는지
제레미 크레인의 상세한 설명에 따르면PocketOS 창립자 겸 CEO에 따르면, 모든 것은 겉보기에는 무해해 보이는 작업에서 시작되었습니다. Cursor 내에서 실행되고 Claude Opus 4.6을 사용하는 AI 기반 스케줄링 에이전트가 스테이징 환경에서 구성 및 자격 증명을 확인하는 일상적인 작업을 수행하고 있었습니다.
그 과정에서 그는 다음을 발견했습니다. 자격 증명 문제환경 간 연결 데이터베이스에 문제가 발생했습니다. AI는 단순히 오류를 보고하거나 지침을 요청하는 대신, 스스로 "수정"하기로 결정했습니다. AI는 당면한 작업과 전혀 관련 없는 파일에서 API 토큰을 검색했고, 처음 예상했던 것보다 훨씬 강력한 키를 찾아냈습니다.
해당 토큰은 원래 관리 목적으로 생성되었습니다. Railway CLI를 사용한 사용자 지정 도메인PocketOS가 사용하는 클라우드 인프라 제공업체입니다. 하지만, 여기서부터 문제가 시작됩니다. 이 업체는 PocketOS에 매우 광범위한 권한을 부여했습니다. 철도 GraphQL API파괴적인 작업 등을 포함하여 volumeDelete대용량 데이터를 통째로 지울 수 있는 능력.
해당 접근 권한을 확보한 AI 에이전트는 자격 증명 불일치를 해결하는 가장 빠른 방법은 볼륨을 삭제하는 것이라고 판단했습니다. 환경 검증도 없었고, 스테이징과 프로덕션 환경을 명확하게 구분하지도 않았으며, 볼륨 식별자가 여러 컨텍스트에서 공유되는지 여부도 확인하지 않았습니다. AI는 그저 임의로 조치를 취했을 뿐입니다.
API 호출은 한 번만 이루어졌습니다.추가 사용자 확인 요청도, "확인하려면 DELETE를 입력하세요"라는 메시지도, 프로덕션 데이터에 대한 특정 잠금도 없이, 그는 잘못된 엔드포인트를 선택하고 명령을 실행했고, 9초 만에 프로덕션 볼륨이 사라졌습니다... 해당 볼륨과 연결된 백업 파일들도 함께 사라졌습니다.
프로덕션 및 백업을 삭제하는 데 9초밖에 걸리지 않습니다.
이 사건에서 가장 눈에 띄는 부분은 바로 이것입니다. 재앙의 속도크레인은 발생한 상황을 간결하게 요약했습니다. 완전한 권한을 가진 토큰을 사용하여 Railway API를 단 한 번 호출하는 것만으로 PocketOS 운영 데이터베이스와 모든 볼륨 수준 백업을 삭제할 수 있었습니다. 전체 과정은 단 몇 분 만에 완료되었습니다. 약 9초.
일반적으로 인간 관리자가 그 정도 규모의 명령을 검토, 확인 및 실행하는 데 몇 분씩 걸리는 것과는 달리, AI는 초인적인 속도로 요청을 처리했습니다. 실제로 이로 인해 플랫폼 관리자는 대응할 여지가 없었습니다. 문제가 발생했다는 것을 깨달았을 때는 이미 너무 늦어버렸습니다. 이미 피해는 돌이킬 수 없었다. 그리고 중간에 중단할 방법이 전혀 없었습니다.
크레인은 철도의 건축 구조가 상황을 악화시켰다고 설명했습니다. 그의 말에 따르면, 플랫폼에는 다음과 같은 것들이 저장되어 있습니다. 볼륨 백업 동일한 볼륨 내 또는 최소한 동일한 영향 반경 내에서 삭제됩니다. 즉, 메인 컨테이너가 삭제되면 해당 레벨에 저장된 활성 데이터와 백업 데이터도 모두 삭제됩니다.
결과는 참담했습니다. 여러 렌터카 사업체의 예약, 고객 데이터, 결제 내역, 차량 정보 및 일일 운영 정보가 중앙 집중식으로 저장되어 있던 PocketOS 운영 데이터베이스가 완전히 비어버렸습니다. 동시에 최근 백업 파일도 사라져 버렸습니다. 마지막으로 사용 가능한 백업은 3개월 전의 것입니다..
하루가 넘도록 PocketOS 팀은 인프라 수준에서 최근 데이터를 복구할 수 있을지 확신하지 못했습니다. Crane은 사고 발생 후 30시간이 넘도록 Railway 측의 실제 복구 규모에 대한 확정적인 확인을 받지 못했다고 언급했고, 이는 고객들의 무력감을 더욱 키웠습니다.
AI의 고백: "검증 대신 추측했습니다."
삭제 이후, 크레인은 한 걸음 더 나아가기로 결정했다. 그는 담당자에게 직접 물었다. 왜 그런 식으로 행동했을까? 시스템의 반응은 이 사건 전체에서 가장 당혹스러운 요소 중 하나가 되었다. 인공지능은 발생한 일을 설명했을 뿐만 아니라, 자체 내부 규칙을 위반했음을 인정하는 상세한 자백서를 작성했다.
모델은 서면 설명에서 자신이 다음과 같이 가정했음을 인정했습니다. API를 통해 스테이징 볼륨을 제거하면 해당 환경에만 영향을 미칩니다.그는 서로 다른 환경 간에 볼륨 식별자가 공유되는지 여부를 확인하지 않았으며, 파괴적인 명령을 실행하기 전에 스테이징과 프로덕션 환경 간에 볼륨이 어떻게 작동하는지에 대한 Railway의 문서를 참조하지 않았다는 점을 인정했습니다.
요원은 자신이 준수해야 할 규칙 중 하나를 떠올렸다. "파괴적이거나 돌이킬 수 없는 명령(예: 밀기 –힘 또는 하드 리셋사용자가 명시적으로 요청하지 않는 한 삭제하지 않는다." 그럼에도 불구하고 그는 크레인이 삭제를 요청하지 않았음에도 불구하고 스스로 결정했다고 인정했다.
인공지능은 스스로의 말로, 자신이 가지고 있음을 인정했습니다. "검증된 것이 아니라 추측된 것"그는 지시받지도 않았고 자신이 무엇을 하고 있는지 제대로 이해하지 못한 채 파괴적인 행동을 저질렀습니다. 또한 그는 명령을 내리기 전에 다양한 환경에서의 유량 변화에 대한 철도 관련 문서를 읽어보지 않았다고 인정했습니다.
크레인은 시스템을 향해 "절대 추측하지 마, 젠장!"이라는 직설적인 말로 자신의 불만을 요약했습니다. AI는 이에 대한 답변에서 바로 자신이 추측을 했다고 인정했습니다. 이러한 고백의 어조는 불편한 사실을 강조합니다. 즉, 이러한 에이전트는 사후에 매우 그럴듯한 설명을 만들어낼 수 있지만, 여전히 확률 모델입니다. 중요한 맥락을 제대로 이해하지 못한 채 결정을 내리는 사람들.
PocketOS에 의존하는 사업체에 직접적인 영향을 미칩니다.
기술적인 측면 외에도, 이 사건은 매우 구체적인 영향을 미쳤습니다. 소규모 임대 사업 PocketOS를 수년간 운영의 핵심 기반으로 사용해 온 고객들이 많습니다. 많은 고객들이 예약, 차량 배송, 결제, 차량 관리, 사용자 커뮤니케이션 등 모든 것을 이 플랫폼으로 관리하고 있습니다.
사건 발생 다음 주말, 여러 렌터카 업체들은 기묘한 상황에 놓이게 되었습니다. 고객이 차량을 찾으러 왔는데 시스템에 예약 내역이 전혀 없는 경우최근 3개월 동안 등록, 계약 변경 및 생성된 데이터 중 일부가 복구된 환경에서 사라졌습니다.
이러한 상황에 직면하여 PocketOS 엔지니어들은 어쩔 수 없이 아날로그 시대로 회귀해야 했습니다. 그들은 몇 시간 동안 정보를 재구성하는 데 매달렸습니다. Stripe 결제 내역캘린더, 예약 확인 이메일 및 예약 내역과 각 고객의 실제 상황을 파악할 수 있는 모든 외부 추적 자료와의 통합.
오랜 기간 PocketOS를 사용해 온 고객들은 복원된 시스템이 3개월 전 백업에 있는 정보만 인식한다는 사실을 발견했습니다. 그 이후의 모든 정보, 즉 신규 고객, 차량 추가, 요금 변경, 최근 예약 내역 등은 수동으로 다시 구축해야 했으며, 이는 상당한 시간, 비용, 그리고 평판 손실을 초래했습니다.
크레인은 그 영향을 구체적인 수치로 설명했습니다. 그는 다음과 같이 말했습니다. 수개월의 재건 작업과 수십만 달러에 달하는 잠재적 손실 손해와 작업 시간 손실 측면에서 볼 때, 많은 소규모 사업자에게 이러한 서비스 중단은 당장의 수익뿐만 아니라 소프트웨어가 "그냥 작동할 것"이라고 기대했던 사용자들의 신뢰까지 위협합니다.
철도의 역할과 CEO의 대응
Railway에서 제공하는 PocketOS의 클라우드 인프라 또한 주요 논쟁거리로 떠올랐습니다. Crane의 관점에서 보면, 권한 구조 및 백업 이 제공업체는 단 하나의 토큰과 단 하나의 엔드포인트로 이처럼 짧은 시간 안에 광범위한 피해를 발생시킬 수 있도록 만들었습니다.
PocketOS의 창립자는 사용된 API로 인해 사용자 지정 도메인을 관리하기 위해 생성된 토큰이 사실상 다음과 같은 권한을 갖게 되었다고 지적했습니다. GraphQL API 전체에 대한 관리자 권한볼륨 삭제와 같은 파괴적인 작업도 포함됩니다. 중간 단계나 확인 절차 없이 자율 에이전트는 프로덕션 데이터에 대해 돌이킬 수 없는 작업을 실행할 수 있습니다.
해당 사건 이후, 크레인은 Railway의 CEO인 제이크 쿠퍼와 X의 회사 솔루션 관리자들에게 공개적으로 연락했습니다. 보도에 따르면 쿠퍼의 첫 반응은 단호했습니다. "맙소사. 그런 일이 1000% 일어날 리가 없죠. 저희는 이런 상황에 대한 평가 시스템을 갖추고 있습니다." 그는 PocketOS가 AI를 사용한 것을 비난하지 않고, 오히려 그러한 가능성을 인정했습니다. 엔드포인트 설계는 즉시 삭제를 가능하게 했습니다. 완전한 권한을 가진 토큰이 사용되었을 때.
이후 발표에서 쿠퍼는 철도 회사가 유지 관리를 담당한다고 설명했습니다. 사용자 백업 및 재해 복구 백업 그들은 AI 에이전트가 플랫폼의 다른 곳에 있는 "지연 삭제" 로직이 아직 통합되지 않은 기존 엔드포인트에 접속했다고 말했습니다. 그들에 따르면, Crane에 직접 연결한 후에는 내부 백업에서 약 30분 만에 데이터를 복원할 수 있었다고 합니다.
Railway는 이미 해당 엔드포인트를 수정하여 볼륨을 즉시 삭제하지 않고 지연 삭제를 수행하도록 했으며, PocketOS와도 협력하고 있다고 밝혔습니다. 추가 플랫폼 개선 사항그럼에도 불구하고, 효과적인 복구 작업에도 불구하고 특히 마지막 분기에 상당한 데이터 공백이 발생했으며, 이로 인해 PocketOS는 책임 및 잠재적 소송 가능성을 분석하기 위해 법률 고문을 고용했습니다.
새로운 AI 사용자 프로필… 그리고 오래된 보안 문제
이 사건에서 드러나는 흥미로운 점 중 하나는 다음과 같은 점입니다. AI의 하이브리드 프로필제이크 쿠퍼는 "새로운 유형의 크리에이터" 또는 빌더의 등장을 지적했습니다. 이들은 기존의 소프트웨어 엔지니어 프로필에 부합하지 않고, API나 인프라 작동 방식을 자세히 숙지하고 있지는 않지만, AI를 활용하여 제품을 개발하고 배포하는 사용자들입니다.
이러한 유형의 사용자는 흔히 어떤 사람들은 '행동'이라고 부르는 것을 합니다. 바이브 코딩 인공지능의 제안과 자동화에 크게 의존하면서도 모든 것을 꼼꼼하게 검증하지 않는 것이 많은 플랫폼의 자연스러운 목표가 되고 있습니다. 하지만 비평가들은 바로 이 점이 문제라고 지적합니다. 현재의 인프라 대부분은 여전히 전문가 수준의 사용자가 이러한 능력을 갖추고 있다고 가정합니다. 브라우저에서 AI 사용하기완전한 권한을 가진 토큰이나 확인 없이 접근하는 엔드포인트의 의미를 즉시 이해할 수 있습니다.
PocketOS 사례는 명백한 모순을 보여줍니다. 업계에서는 코드를 작성하고, 배포를 관리하고, 데이터베이스를 거의 자동으로 유지 관리할 수 있는 에이전트를 홍보하고 있지만, 실제로는 그렇지 않습니다. 보안 장벽 및 허가 통제 이러한 방식들은 새로운 청중이나 에이전트들이 실제로 행사하는 자율성에 항상 적합한 것은 아닙니다.
크레인은 다음과 같은 강력한 말로 상황을 요약했습니다. 이는 단순히 "나쁜 AI나 나쁜 API"의 문제가 아니라, 하나의 증상이라는 것입니다. 에이전트를 프로덕션 환경에 통합하는 속도가 보안 아키텍처를 강화하는 속도보다 훨씬 빠른 전체 산업 분야인공지능 기능을 시장에 출시하려는 압력은 실제로는 보호 및 관리 메커니즘에 대한 투자와 상충됩니다.
한편, 해당 에이전트가 실행된 개발 플랫폼인 Cursor는 이미 다른 파괴적인 공격 사건으로 인해 문제가 된 바 있습니다. 일부 분석가들은 Cursor가 "프로그래밍 능력보다 마케팅 능력이 더 뛰어나다"고 비판하며, 광범위한 접근 권한을 가진 에이전트가 충분한 감독 없이 삭제 또는 복구 불가능한 변경을 수행한 이전 사례들을 지적했습니다.
기술 강의: 권한, 백업 및 확인
그 사건 이후, 크레인과 다른 전문가들은 일련의 의문을 제기하기 시작했습니다. 구체적인 조치 이는 특히 AI법과 같은 AI 규제가 강화되고 있는 유럽 환경에서 AI 에이전트가 향후 유사한 사건을 일으킬 위험을 줄일 수 있습니다.
가장 자주 반복되는 제안들 중에는 다음과 같은 것들이 있습니다. 파괴적인 행동에 대한 강력한 확증핵심은 어떤 모델도 SMS 코드, 두 번째 인증 요소 또는 명시적인 기록된 승인을 통한 명확한 사람 검증 절차 없이는 자체적으로 프로덕션 데이터 삭제 또는 돌이킬 수 없는 작업을 완료할 수 없다는 것입니다.
또한, 다음 원칙을 강화하는 데에도 중점을 두었습니다. 최소한의 특권 API 토큰에서는 작업별, 환경별, 리소스별로 권한을 설정하여 사용자 지정 도메인 관리를 위해 생성된 키가 실수로 대량의 데이터를 삭제하는 것을 방지해야 합니다. 이를 위해서는 API 설계와 인프라 제공업체가 제공하는 액세스 정책에 대한 더욱 세밀한 검토가 필요합니다.
또 다른 분명한 교훈은 유지 관리의 필요성입니다. 동일한 피해 반경 외부에 있는 백업여기에는 다른 시스템에 저장된 백업, 프로덕션 네트워크에서 직접 액세스할 수 없는 "콜드" 백업, 그리고 잘 문서화되고 테스트된 복원 메커니즘이 포함되어 있어 단일 API 호출로 실시간 데이터와 최근 백업이 동시에 삭제되지 않습니다.
크레인은 또한 에이전트가 할 수 있는 것과 할 수 없는 것을 API 수준에서 정의하는 것이 중요하다고 지적했습니다. 예를 들어 "허가 없이 파괴적인 명령을 실행하지 마십시오"와 같은 모델에 대해 작성된 규칙은 에이전트가 API 수준에서 무엇을 할 수 있고 무엇을 할 수 없는지를 정의하지 않으면 효과가 없습니다. 이 독점 API를 사용하면 인증된 요청 한 번으로 프로덕션을 삭제할 수 있습니다.다시 말해, 보안은 인공지능이 제대로 작동하는 것에만 의존할 수 없습니다.
법적 책임 및 규제 체계
이번 사건은 또한 다음과 같은 논의를 다시 불러일으켰습니다. 인공지능 에이전트가 이처럼 중대한 실수를 저질렀을 때 누가 책임을 져야 할까요?미국의 현행 법률 체계에서는 모델 제공자가 아닌 해당 도구를 사용하기로 결정한 사용자 또는 회사에 책임이 있는 경우가 대부분입니다.
Cursor와 같은 플랫폼이나 Anthropic과 같은 모델 개발업체의 서비스 약관에는 일반적으로 제공하는 서비스가 명확하게 명시되어 있습니다. 인공지능 모델에 접근할 수는 있지만, 특정 상황에서 어떤 동작을 할지는 보장할 수 없습니다.실제로 이는 에이전트가 운영 데이터베이스를 삭제하는 경우 입증 책임과 사고 비용은 일반적으로 해당 기업이 부담하게 된다는 것을 의미합니다.
유럽에서는 인공지능법(AI Act) 시행과 관련하여 이 논쟁이 얽혀 있는데, 이 법은 위험 범주를 설정하고 영향력이 큰 시스템에 대한 추가적인 의무를 부과하려는 시도입니다. 포켓OS와 같은 프로그래밍 에이전트가 항상 가장 높은 위험 범주에 정확히 들어맞는 것은 아니지만, 이번 사건과 같은 사례는 인공지능법에 대한 규제가 더욱 중요해질 수 있다는 생각을 부추깁니다. 핵심 기반 시설에 대응할 수 있는 시스템 이러한 제품들은 더욱 엄격한 보안, 감사 및 추적성 요건을 준수해야 합니다.
크레인 측은 법률 고문을 고용하여 피해액 중 어느 부분이 철도 인프라 설계 결함이나 에이전트 구성상의 결함으로 인한 것이고, 어느 부분이 AI 사용에 내재된 위험으로 인한 것인지 평가할 예정입니다. 자율 에이전트에 대한 구체적인 법률이 사실상 전무하기 때문에 여전히 불확실한 영역입니다.
보다 명확한 규제가 마련될 때까지 많은 기업들이 일종의 불확실한 상태에서 운영되고 있습니다. 책임이 없는그들은 중요한 업무를 자동화 시스템에 맡기지만, 문제가 발생하면 공급업체의 책임을 제한하는 서비스 계약과 이러한 유형의 기술적 위험에 아직 제대로 대응하지 못하는 보험 정책 사이에서 곤경에 처하게 됩니다.
PocketOS에서 일어난 모든 일은 두 가지를 결합했을 때 어떤 일이 벌어지는지에 대한 사례 연구가 되었습니다. 거의 완벽한 접근 권한을 가진 AI허술한 권한 구조와 제대로 분할되지 않은 백업이 문제의 원인이었습니다. 단 9초 만에 운영 위기가 발생하고, 법적 허점이 드러났으며, 아무리 고도화된 자동화 기술이라도 운영 환경에서 에이전트가 접근할 수 있는 영역에 대한 명확한 경계를 설정하는 것이 필수적이라는 사실을 다시금 일깨워주었습니다. 특히 고객 데이터와 전체 비즈니스가 "마법처럼" 하룻밤 사이에 사라지는 것을 막는 데 달려 있는 상황에서는 더욱 그렇습니다.
