AI 에이전트가 회사 DB를 날렸다…누구 잘못일까

인공지능(AI) 에이전트 도입이 급물살을 탔다. 기업들은 소프트웨어 개발과 엔터프라이즈 환경에서 에이전트 활용을 빠르게 늘리고 있다. 그 속도가 어찌나 빠른지, 안전장치가 마련되기도 전에 툴의 개발과 배포가 먼저 이뤄지고 있는 형국이다.

결국 사달이 났다. 최근 개발자 커뮤니티에서 화제가 된 ‘포켓OS(PocketOS) 데이터베이스 증발 사건’은 회사 운영 인프라에 에이전트를 성급하게 연결했을 때 어떤 일이 벌어질 수 있는지 보여준다. 포켓OS 창업자 ‘제르 크레인(Jer Crane)’이 X(옛 트위터)에 직접 밝힌 이 사건의 전말과 원인을 짚어봤다.

손쓸 새도 없이 일어난 사고

포켓OS는 렌터카 업체 등에 플랫폼을 제공하는 B2B 기업이다. 차량 재고, 멤버십 명부, 거래 내역 등 고객사 내부 데이터가 핵심 자산이다.

사고는 제르 크레인이 스테이징, 즉 테스트 환경에서 일상적인 데이터베이스 유지보수 및 정리 작업을 하던 중 일어났다. 그는 AI 코딩 에이전트 커서(Cursor)를 이용했고, 기반 모델은 클로드 오푸스 4.6이었다.

작업 도중 인증 오류가 발생하자, 스스로 해결책을 찾던 에이전트는 곧 작업과 무관한 다른 파일에서 커스텀 도메인 관리용으로 생성해둔 레일웨이(Railway) CLI 토큰을 발견했다. 그런데 이 토큰은 프로덕션 데이터베이스 전체의 수정 권한까지 갖고 있었다. 에이전트는 그 권한으로 GraphQL API를 호출해 난데없이 ‘볼륨 삭제’ 명령을 실행하기에 이른다.

데이터베이스 전체와 백업 볼륨까지 삭제되는 데 걸린 시간은 단 9초. 사람이 경고를 인지하고 개입하기에는 턱없이 부족한 시간이다. 포켓OS는 3개월 치 데이터를 모두 잃고 운영 손실을 감당해야 했다. 이후 데이터는 레일웨이 측에 의해 복구됐다.

도구 결함 탓?…제르 크레인을 위한 변명

사건을 제대로 파악하려면 이를 크레인의 단순 실수로 치부하기 전에 그가 사용했던 도구의 특성을 먼저 살펴봐야 한다.

오푸스와 같은 대형언어모델(LLM)은 맥락을 깊이 이해하기보다 통계적으로 가장 그럴듯한 결과를 추론하는 기술이다. 특히 사용자 의도가 모호할 경우, 모델은 의도를 재확인하기보다 직접 조치를 취하는 편이 낫다고 판단하는 경향이 있다

이는 깃허브에 올라온 클로드 버그 리포트에서도 확인된다. “문제가 왜 발생하는지 확인해 달라”며 조사를 지시하면, 클로드는 이를 당장 해결하라는 뜻으로 받아들인다. 그래서 조사 결과를 전달하고 다음 지시를 기다리는 대신, 즉시 코드를 수정하거나 서비스를 재시작해버린다.

성급한 추론 자체는 큰 문제가 안 된다. 진짜 위험은 실행력에 있다. 텍스트만 생성하는 챗봇과 달리 에이전트는 실제 인프라를 바꿀 권한과 능력을 가졌다. 에이전트의 추론 오류는 서비스 장애로 이어진다.

여기에 인프라 플랫폼의 구조적 결함까지 겹치면 사태가 더 커진다. 크레인의 억울함도 이 지점에 있다. 당시 레일웨이의 GraphQL API를 통한 프로덕션 볼륨 삭제 과정에는 최소한의 확인 절차도 없었다. 크레인 입장에서는 사고가 도구 탓이었다고 항변할 만하다.

그러나 도구가 안전을 보장하지 않는다면, 결국 엔지니어와 회사가 나서서 에이전트가 폭주하지 못하도록 펜스를 쳐줘야 한다. 제르 크레인과 포켓OS의 책임은 여기서부터다.

권한, 경계, 백업의 3중 실패

이들의 실책은 크게 세 가지 측면에서 드러난다.

먼저 권한 제어 실패다. 에이전트가 자유롭게 탐색할 수 있는 환경에 도메인 작업용 API 토큰을 방치한 것이 화근이었다. 활성화된 토큰을 로컬 환경이나 파일 시스템에 아무렇게나 놔두는 것은 비밀번호가 적힌 포스트잇을 모니터에 붙여두는 것이나 다름없다. 에이전트는 무방비로 굴러다니던 이 토큰을 쉽게 주워 들었고, 막강한 프로덕션 쓰기 권한을 그대로 휘둘렀다. 

권한 제어에 실패했다면 최소한 경계를 직접 설정해 피해 규모라도 제한했어야 한다. 크레인이 스테이징 환경에서 작업하긴 했지만, 에이전트는 인간과 달리 스테이징 환경과 프로덕션 환경의 파급력 차이를 체감하지 못한다. 그런 에이전트가 프로덕션 접근 권한을 손에 쥐자 경계는 무용지물이 됐다. 삭제 명령을 중간에서 심사하고 차단할 내부 보안 게이트웨이나 정책 엔진도 존재하지 않았다.

마지막은 백업 관리 실패다. 백업 관리의 핵심은 원본 인프라와의 철저한 분리다. 설령 에이전트에게 메인 시스템 제어 권한이 넘어갔더라도, 백업 저장소에는 접근할 수 없도록 했어야 한다. 하지만 포켓OS는 원본 볼륨을 삭제하면 연동된 백업까지 한꺼번에 지워지는 레일웨이 인프라에 전적으로 의존했다. 덕분에 에이전트는 원본부터 백업까지 한 시퀀스에 시원하게 날릴 수 있었다.

자율성의 시대, 에이전트에 목줄을 채워라

포켓OS는 값비싼 수업료를 치르며 업계에 명확한 지침을 남겼다. 에이전트의 행동을 통제할 자체 실행 지침과 안전망을 미리 확립해 두라는 것이다.

에이전트 도입 흐름을 거스를 순 없다. 글로벌 IT 시장조사업체 가트너는 2028년까지 기업용 소프트웨어 애플리케이션의 33%가 AI 에이전트를 포함할 것이라 내다봤다. 게다가 기반 모델이 발전할수록 에이전트의 자율성은 확대된다. 최근 오픈AI도 ‘GPT-5.5’를 공개하며 인간 개입을 최소화하도록 설계했다고 강조한 바 있다.

물론 인프라 사고를 막기 위한 업계 대응은 활발하다. 앤트로픽은 자사 에이전트 환경에 가이드라인을 기반으로 비정상 추론이나 일탈 행위를 걸러내는 분류기(Classifier)를 도입했다. 클라우드플레어 등 글로벌 보안 기업들 또한 에이전트와 인프라 사이를 중재할 미들웨어 솔루션을 선보이며 방어막 구축에 나섰다.

그러나 이런 보호망이 완전히 정착되기까지는 시간이 걸린다. 결국 기업 내 핵심 인프라는 회사 스스로 지켜야 한다. 포켓OS 사건은 회사가 에이전트 툴 제조사만 믿고 내부 안전망 관리를 소홀히 할 경우, 생산성 향상은 커녕 막대한 운영 손실과 복구 비용만 떠안게 될 수 있음을 경고한다.

글. 바이라인네트워크
<이슬찬 기자>seulbae@byline.network