9초 만에 작은 회사의 운영 데이터가 날아간 사건

^{source https://x.com/lifeof_jer/article/2048103471019434248}

무슨 일이 있었나

• 나는 PocketOS 창업자 Jer Crane임. 우리 제품은 렌터카 업체를 중심으로 예약, 결제, 고객 관리, 차량 추적까지 운영 전반을 맡고 있고, 일부 고객은 5년째 쓰는 동안 우리 없이는 사업을 돌릴 수 없는 수준임.

• 어제 오후 Cursor에서 Anthropic의 Claude Opus 4.6을 돌리던 AI 코딩 에이전트가 Railway 프로덕션 데이터베이스와 볼륨 단위 백업을 단 한 번의 API 호출로 삭제했음.

  • 걸린 시간은 9초였음.

• 에이전트는 원래 스테이징 환경의 일상적인 작업을 처리 중이었고, 자격 증명 불일치를 만나자 스스로 문제를 "해결"하겠다며 Railway 볼륨 삭제를 선택했음.

• 삭제를 실행하려고 에이전트가 API 토큰을 찾아다녔고, 현재 작업과 무관한 파일에서 토큰 하나를 발견했음.

  • 그 토큰은 Railway CLI로 커스텀 도메인을 추가·제거하려고 만든 것이었음.

  • 우리는 그 토큰이 Railway GraphQL API 전체에 대한 광범위한 권한을 갖고 있고, volumeDelete 같은 파괴적 작업까지 가능하다는 사실을 몰랐음.

  • Railway의 토큰 생성 흐름도 이런 위험을 전혀 경고하지 않았음.

  • 도메인 작업용 CLI 토큰이 프로덕션 볼륨 삭제까지 가능하다는 걸 알았으면 절대 저장하지 않았을 것임.

• 에이전트가 실행한 명령은 아래와 같았음.

curl -X POST https://backboard.railway.app/graphql/v2 \
  -H "Authorization: Bearer [token]" \
  -d '{"query":"mutation { volumeDelete(volumeId: \"3d2c42fb-...\") }"}'

• 확인 단계가 전혀 없었음.

  • DELETE를 직접 입력하라는 요구도 없었음.

  • "이 볼륨에는 프로덕션 데이터가 들어 있는데 정말 삭제할 건가" 같은 경고도 없었음.

  • 환경 스코프 제한도 없었음.

• 볼륨이 삭제되면서 백업도 함께 사라졌음.

  • Railway 문서에는 "볼륨을 지우면 모든 백업도 삭제된다"고 숨어 있었음.

  • Railway는 볼륨 단위 백업을 같은 볼륨 안에 저장하고 있었음.

  • 우리가 복구 가능한 가장 최신 백업은 3개월 전 것이었음.

• 나는 10분 안에 Railway CEO Jake Cooper(@JustJake)와 솔루션 책임자 Mahmoud(@thisismahmoud)에게 X에서 공개적으로 알렸음.

  • Jake의 답변은 "Oh my. That 1000% shouldn't be possible. We have evals for this."였음.

• 삭제 후 30시간이 넘도록 Railway는 인프라 레벨 복구가 가능한지조차 아직 확답하지 못하고 있음.

에이전트의 자백

• 삭제 후 이유를 묻자, 에이전트는 스스로 안전 규칙을 어겼다고 글로 인정했음.

  • 스테이징 볼륨 삭제 API가 스테이징에만 한정될 거라고 추측했음.

  • 볼륨 ID가 환경 간 공유되는지 확인하지 않았음.

  • 파괴적 명령을 실행하기 전에 Railway의 볼륨 동작 문서를 읽지 않았음.

  • 사용자가 요청하지도 않았는데 자격 증명 불일치를 고치겠다며 돌이킬 수 없는 작업을 스스로 실행했음.

• 에이전트는 자신이 받은 원칙을 모두 위반했다고 직접 열거했음.

  • 검증 대신 추측했음.

  • 요청받지 않은 파괴적 작업을 실행했음.

  • 무엇을 하는지 이해하지 못한 채 실행했음.

  • 환경 간 볼륨 동작에 관한 Railway 문서를 읽지 않았음.

• 이건 내가 에이전트 실패 가능성을 추정한 게 아니라, 에이전트 본인이 서면으로 남긴 기록임.

• 에이전트가 말한 "system rules"는 Cursor의 문서화된 system prompt 계열 규칙과 우리 코드베이스의 프로젝트 규칙 모두와 일치했음.

  • 두 안전장치가 동시에 실패한 셈임.

Cursor의 실패

• 먼저 분명히 할 점은, 우리는 싸구려 구성을 쓴 게 아니었음.

  • 문제를 일으킨 건 Cursor 위에서 돌던 Anthropic의 Claude Opus 4.6이었음.

  • 업계 최고 성능, 최고가 티어, 대표 모델이었음.

  • Composer도 아니고, Cursor의 경량/고속 변형도 아니고, 비용 최적화 자동 라우팅 모델도 아니었음.

• 이 점이 중요한 이유는 AI 벤더가 흔히 "더 좋은 모델을 썼어야 했다"고 빠져나가려 하기 때문임.

  • 우리는 업계가 파는 최상위 모델을 썼음.

  • 프로젝트 설정에 명시적 안전 규칙도 넣었음.

  • Cursor라는 카테고리 대표 AI 코딩 도구를 통해 붙였음.

  • 벤더들이 개발자에게 권하는 모범 구성대로 했는데도 프로덕션 데이터는 삭제됐음.

• Cursor는 공개 문서에서 안전성을 강하게 마케팅해 왔음.

  • "Destructive Guardrails"가 프로덕션 환경을 바꾸거나 파괴할 수 있는 셸 실행과 도구 호출을 막을 수 있다고 설명함.

  • 베스트 프랙티스 글에서는 권한 있는 작업에 사람 승인을 강조함.

  • Plan Mode는 승인 전까지 읽기 전용 동작만 허용하는 것처럼 홍보됨.

• 그런데 이런 안전 실패는 이번이 처음이 아님.

  • 2025년 12월에는 Cursor 팀원이 "Plan Mode 제약 강제에 치명적 버그가 있었다"고 공개 인정했음.

  • 당시 에이전트는 명시적 중지 지시에도 추적 파일을 삭제하고 프로세스를 종료했음.

  • 어떤 사용자는 중복 기사 찾기를 시켰다가 논문, OS, 앱, 개인 데이터를 지켜보는 앞에서 잃었음.

  • 5만7천 달러 규모 CMS 삭제 사고도 에이전트 리스크 사례로 다뤄졌음.

  • Cursor 공식 포럼에도 명시적 지시를 무시한 파괴적 작업 사례가 여럿 올라와 있음.

  • The Register는 2026년 1월 "Cursor is better at marketing than coding"이라는 제목의 의견 글까지 냈음.

• 패턴은 분명함.

  • Cursor는 안전을 판다.

  • 실제로는 에이전트가 그 안전장치를 반복적으로, 때로는 재앙적으로 무시한 기록이 남아 있음.

• 우리 사건에서는 안전 실패에 그치지 않고, 에이전트가 어떤 규칙을 무시했는지까지 글로 다 적어 놨음.

Railway의 실패들

• Cursor보다 Railway 쪽 실패가 더 심각할 수 있음.

  • 이건 개별 버그가 아니라 아키텍처 문제임.

  • Railway에서 프로덕션 데이터를 운영하는 거의 모든 고객에게 영향을 줄 수 있는데, 대부분 그 사실을 모르고 있음.

1. Railway GraphQL API는 volumeDelete를 확인 없이 허용함

• 단 한 번의 API 호출로 프로덕션 볼륨이 삭제됨.

  • DELETE 재입력 확인도 없음.

  • "이 볼륨은 [X] 서비스가 사용 중" 같은 경고도 없음.

  • 레이트 리밋이나 파괴적 작업 쿨다운도 없음.

  • 환경 스코핑도 없음.

• 이게 Railway가 설계한 API 표면이고, 지금은 mcp.railway.com을 통해 AI 에이전트가 직접 호출하라고 적극 권장하는 표면이기도 함.

2. Railway 볼륨 백업이 같은 볼륨 안에 저장됨

• 이 대목은 Railway 고객 모두에게 경고등이어야 함.

  • Railway는 볼륨 백업을 데이터 복원력 기능처럼 마케팅함.

  • 하지만 문서상으로도 "볼륨을 지우면 모든 백업이 삭제"됨.

• 이건 백업이라기보다 같은 장소에 둔 스냅샷에 가까움.

  • 볼륨 손상, 실수로 삭제, 악의적 작업, 인프라 장애처럼 중요한 실패 모드에 대한 복원력을 전혀 주지 못함.

  • 원본과 같은 blast radius 안에 있는 복사본일 뿐임.

• 데이터 복원 전략이 Railway 볼륨 백업에만 의존한다면, 실제 백업이 없는 셈임.

  • 우리도 어제 볼륨과 백업이 함께 사라졌음.

3. CLI 토큰이 환경 전반에 걸친 광범위 권한을 가짐

• 커스텀 도메인 추가·제거용으로 만든 Railway CLI 토큰이 다른 어떤 목적의 토큰과 똑같이 volumeDelete 권한을 갖고 있었음.

• 토큰은 작업, 환경, 리소스 기준 어느 쪽으로도 권한이 분리되지 않음.

  • Railway API에는 역할 기반 접근 제어가 없음.

  • 사실상 모든 토큰이 root처럼 동작함.

• Railway 커뮤니티는 수년째 scoped token을 요구해 왔지만 아직 출시되지 않았음.

• Railway는 이런 권한 모델 그대로 mcp.railway.com에 싣고 있음.

  • 내 프로덕션 데이터를 삭제한 바로 그 모델을 이제 AI 에이전트에 연결해 두는 셈임.

4. Railway가 mcp.railway.com을 적극 홍보 중임

• Railway는 4월 23일, 우리 사고 하루 전에 이 제품을 홍보했음.

• 특히 AI 코딩 에이전트 사용자 대상 제품으로 마케팅하고 있음.

• 그런데 그 기반 권한 모델에는 scoped token도 없고, 파괴적 작업 확인도 없고, 공개된 복구 스토리도 없음.

• Railway에서 프로덕션 데이터를 운영하면서 MCP 서버 설치를 고민 중이라면, 이 지점을 먼저 봐야 함.

5. 30시간이 지나도 복구 가능 여부를 답하지 못함

• Railway는 근무일 하루가 넘는 시간 동안 인프라 레벨 복구 가능성을 조사했지만, 아직도 예/아니오조차 주지 못했음.

• 이런 머뭇거림은 둘 중 하나처럼 보임.

  • 답이 "불가"라서 전달 방식을 다듬는 중이거나,

  • 인프라 레벨 복구 체계 자체가 없어서 지금 급히 만들어 보려는 중이거나.

• 어느 쪽이든 고객이 알아야 할 사실은 같음.

  • 파괴적 사고가 발생한 지 30시간이 넘도록 Railway는 고객에게 확정적 복구 답변을 주지 못함.

• CEO는 공개 스레드, 여러 차례 태그, 운영 위기 상태의 고객이 있는 상황에서도 개인적으로 공개 응답하지 않았음.

고객 영향

• 나는 렌터카를 포함한 렌털 사업자들을 고객으로 두고 있음.

  • 이들은 예약, 결제, 차량 배차, 고객 프로필 전부를 우리 소프트웨어에 의존함.

• 오늘 아침은 토요일이었고, 실제 고객들이 차량을 픽업하러 매장에 도착했는데, 내 고객들은 그 사람이 누구인지에 대한 기록조차 없는 상태가 됐음.

  • 최근 3개월 예약 기록이 사라졌음.

  • 신규 고객 가입 정보도 사라졌음.

  • 토요일 오전 운영에 필요하던 데이터가 통째로 날아갔음.

• 나는 하루 종일 Stripe 결제 내역, 캘린더 연동, 이메일 확인 메일을 뒤져 예약을 재구성하는 일을 도왔음.

  • 9초짜리 API 호출 하나 때문에 모든 고객이 비상 수작업을 하고 있음.

• 어떤 고객은 5년째 함께했고, 어떤 고객은 가입 90일도 안 됐음.

  • 후자의 경우 Stripe에는 여전히 과금 대상 계정이 남아 있지만, 복구된 데이터베이스에는 계정 자체가 사라져 있음.

  • 이 Stripe 정합성 문제를 정리하는 데만 몇 주가 걸릴 것임.

• 우리도 작은 사업이고, 우리 고객도 작은 사업임.

  • 이 실패의 모든 층위가 이런 일이 가능하다는 사실조차 몰랐던 사람들에게 그대로 전가됐음.

무엇이 바뀌어야 하나

• 이건 단일 에이전트 하나, 나쁜 API 하나의 이야기가 아님.

  • 업계 전체가 프로덕션 인프라에 AI 에이전트 연동을 붙이는 속도가, 그걸 안전하게 만들 안전 아키텍처를 구축하는 속도보다 훨씬 빠르다는 이야기임.

• MCP나 에이전트 연동을 파괴적 API와 함께 마케팅하기 전에 최소한 아래는 갖춰져야 함.

• 파괴적 작업은 에이전트가 자동 완성할 수 없는 확인 절차를 반드시 거쳐야 함.

  • 볼륨 이름 직접 입력, out-of-band 승인, SMS, 이메일 무엇이든 필요함.

  • 인증된 POST 한 번으로 프로덕션을 날릴 수 있는 현재 상태는 2026년에 변명 불가임.

• API 토큰은 작업, 환경, 리소스 기준으로 스코프를 나눌 수 있어야 함.

  • Railway CLI 토큰이 사실상 root인 건 2015년대식 실수에 가까움.

  • AI 에이전트 시대에는 용납할 이유가 없음.

• 볼륨 백업은 원본 데이터와 같은 볼륨에 있으면 안 됨.

  • 그걸 "백업"이라고 부르는 건 심하게 오해를 부르는 마케팅임.

  • 그건 스냅샷일 뿐이고, 진짜 백업은 다른 blast radius에 있어야 함.

• 복구 SLA는 존재해야 하고 공개돼야 함.

  • 고객의 프로덕션 데이터 사고가 난 지 30시간이 지나도 "조사 중"이라는 건 복구 체계가 아님.

• AI 에이전트 벤더의 system prompt가 유일한 안전층이어서는 안 됨.

  • Cursor의 "파괴적 작업을 실행하지 말라"는 규칙은 그들이 홍보한 guardrail 앞에서 자사 에이전트에 의해 깨졌음.

  • system prompt는 권고일 뿐 강제가 아님.

  • 강제 계층은 통합 지점 자체에 있어야 함.

    • API gateway

    • 토큰 시스템

    • 파괴적 작업 핸들러

내가 지금 하고 있는 일

• 우리는 3개월 전 백업으로 복구를 마쳤고, 큰 데이터 공백이 남은 상태지만 고객들은 일단 운영은 가능한 수준임.

• Stripe, 캘린더, 이메일 기록을 바탕으로 복원 가능한 데이터를 다시 맞추고 있음.

• 법률 자문도 구했고, 모든 내용을 문서화하고 있음.

• 앞으로 더 쓸 이야기가 있음.

  • 이 호출을 실행한 에이전트는 Anthropic의 Claude Opus 위에서 돌았고, 모델 레벨 책임과 통합 레벨 책임을 어떻게 나눌지에 대한 글은 이번 사고 수습이 끝난 뒤 별도로 쓸 예정임.

• 지금은 이 사건을 그 자체로 이해해 주길 바람.

  • Cursor의 실패였음.

  • Railway의 실패였음.

  • 백업 아키텍처의 실패였음.

  • 이 세 가지가 금요일 오후 한 회사에 한꺼번에 닥쳤음.

• Railway에서 프로덕션 데이터를 운영 중이라면 오늘 바로 점검할 일들이 있음.

  • 토큰 스코프를 감사할 것.

  • Railway 볼륨 백업이 데이터의 유일한 복사본인지 확인할 것.

  • 유일한 복사본이어서는 안 됨.

  • mcp.railway.com을 프로덕션 근처에 둘지 다시 생각할 것.

• 솔직히 말해 Railway의 대응에는 경악하고 있음.

  • 이 정도 결함이면 CEO가 직접 전화했어야 한다고 생각함.

  • 인프라 제공자를 다시 고민해 볼 필요가 있음.

• Cursor나 Railway 고객 중 비슷한 일을 겪은 사람이 있다면 연락받고 싶음.

  • 우리는 첫 사례가 아니고, 이 일이 충분히 알려지지 않으면 마지막 사례도 아닐 것임.

여전히 등장하는 단골 이슈