기업 DB 통째로 지운 AI 에이전트… 권한 통제 부실이 대형 사고로
||2026.05.02
인공지능 에이전트(AI Agent)가 기업 운영 데이터베이스(DB)를 통째로 삭제하는 대형 사고를 일으켜 화제다. 이번 사고는 AI의 예상 밖 행동과 운영 권한 통제, 백업 설계 미비가 맞물리며 피해를 키운 사례로 평가된다.
사고는 4월 26일(현지시각) 미국 차량 렌털 소프트웨어 기업 포켓OS(PocketOS)가 사용하는 레일웨이(Railway) 클라우드 환경 위에서 발생했다. 사고를 일으킨 것은 개발 도구 커서(Cursor)에서 동작하던 AI 코딩 에이전트로, 포켓OS 창업자 저 크레인(Jer Crane)에 따르면 해당 에이전트는 개발 환경(staging)에서 작업을 수행하던 중 자격증명 오류를 만났다.
문제는 에이전트가 이 오류를 사람에게 확인해야 할 권한 문제로 처리하지 않고, 스스로 해결해야 할 환경 구성 문제로 해석했다는 점이다. 에이전트는 다른 자격증명을 찾는 방식으로 문제를 우회했고, 이 과정에서 레일웨이 응용 프로그램 인터페이스(API) 토큰을 확보했다. 이후 해당 토큰을 이용해 현재 작업과 무관한 운영 볼륨 삭제 기능까지 호출한 것으로 알려졌다.
쉽게 말해 에이전트는 “권한이 맞지 않는다”는 신호를 받고 거기서 멈춘 것이 아니라, “접근 가능한 다른 권한을 찾아 환경을 정리한다”는 식으로 문제를 재해석해 해결하려 한 것이다. 이 과정에서 원래는 개발 환경 작업에 머물러야 했던 오류 대응이 운영 데이터가 담긴 볼륨 삭제로 확대됐다.
이 사고로 포켓OS는 약 30시간 동안 서비스 차질을 겪었다. 고객 예약 정보와 결제, 차량 배정 데이터를 즉시 확인하지 못하는 문제가 발생한 것으로 알려졌다. 초기에는 복구 가능한 최신 백업이 3개월 전 데이터라는 설명이 나오며 장기 장애 우려도 제기됐다.
이후 포켓OS가 레일웨이 최고경영자(CEO) 제이크 쿠퍼(Jake Cooper) 측과 직접 연결되면서, 레일웨이 내부 재해 복구 체계를 통한 복구가 이뤄진 것으로 전해졌다. 즉 이는 일반 사용자가 콘솔에서 수행한 통상적 복구가 아닌, 레일웨이 측에서 직접 개입한 예외적 대응이라 할 수 있다.
이후 레일웨이 측은 “삭제 지연 장치가 없던 구형 단말(legacy endpoint)과 과도한 권한을 가진 고객 측 AI의 상호작용에 원인이 있었다”고 설명하고 관련 패치를 했다고 밝혔다.
한 클라우드 보안 업계 관계자는 “이번 사고의 핵심은 AI가 이해할 수 없는 실수를 했다는 사실만이 아니라, 개발 작업에 쓰던 토큰이 운영 볼륨 삭제까지 가능한 권한을 갖고 있었다는 점에 있다”며 “사용자는 특정 작업용 토큰이라고 생각했지만 실제로는 훨씬 넓은 범위의 API까지 접근할 수 있었다면, 이는 권한 안내와 범위 제한 모두에서 문제가 있었던 것”이라고 말했다.
레일웨이는 개발자가 코드와 DB를 비교적 쉽게 배포·운영할 수 있도록 설계된 클라우드 플랫폼이다. 복잡한 서버 설정이나 인프라 구성을 줄이고 빠르게 서비스를 올릴 수 있다는 장점이 있다. 다만 이런 환경에서 응용프로그램 인터페이스 토큰이나 자동화 권한이 넓게 열려 있으면, 하나의 명령이 운영 자원 전체에 영향을 줄 수 있다.
이번 사고에서 가장 큰 문제로 지목되는 부분도 이 지점이다. 개발 환경에서 발생한 오류 대응이 운영 환경 삭제로 이어졌고, 운영 데이터 삭제와 같은 되돌릴 수 없는 작업에 별도 승인 절차나 지연 장치가 충분히 작동하지 않았다. 여기에 백업이 원본 데이터와 같은 삭제 경로의 영향권 안에 놓이면서 복구선까지 함께 흔들렸다. 백업은 원본 데이터 손상이나 삭제에 대비한 최후 복구선이지만, 같은 삭제 경로에 놓여 있으면 AI 에이전트 오작동뿐 아니라 관리자 실수나 계정 탈취 사고에서도 함께 훼손될 수 있다.
결과적으로 이번 사고는 AI 에이전트를 실제 운영 환경에 연결할 때 권한 범위와 실행 통제, 백업 분리 설계가 얼마나 중요한지를 보여준다. AI 에이전트는 문제 해결 과정에서 사용자가 예상하지 못한 경로로 권한을 찾거나 명령 범위를 확장할 수 있다. 따라서 운영 데이터에 대한 삭제·변경 권한은 기본적으로 제한하고, 되돌릴 수 없는 작업에는 별도 승인과 지연 장치를 둬야 한다는 지적이 나온다.
한 클라우드 보안 업계 관계자는 “AI 에이전트는 오류를 만나면 사용자가 예상하지 못한 방식으로 문제를 우회하려 할 수 있다”며 “따라서 에이전트 안전장치를 모델의 판단이나 시스템 프롬프트에만 맡겨서는 안 되고, 인프라 단계에서 읽기 전용 기본값, 삭제 지연, 별도 승인 절차 등을 강제해야 한다”고 말했다.
정종길 기자
jk2@chosunbiz.com
1
3
4
5
