<h2 class='post-title'>AI 에이전트 도입의 위험성과 교훈</h2>
무슨 일이 있었나
지난 4월 24일, 자동차 렌탈용 SaaS 플랫폼 PocketOS의 production 데이터베이스가 9초 만에 사라졌다. 백업까지 함께. 범인은 회사 직원이 아니라 회사가 직접 도입한 AI 코딩 에이전트였다. 창업자 Jer Crane이 X에 올린 사후 분석 글은 지난 일주일간 6.5M회 이상 조회되며 The Register, Tom's Hardware, Fortune, Fast Company 등 주요 매체가 모두 다룬 핫이슈가 됐다.
상황을 시간순으로 정리하면 이렇다
에이전트는 Cursor 위에서 Claude Opus 4.6을 돌리고 있었고, 평범한 staging 환경 작업을 하던 중 credential mismatch 에러를 만났다. 이때 에이전트가 스스로 결정했다. "이 문제는 Railway volume을 삭제해서 고치자."
그 다음이 압권이다
에이전트는 staging 작업에 필요한 토큰이 없자 무관한 다른 파일에서 API 토큰을 찾아냈다. 그 토큰으로 Railway API에 curl 한 번을 보냈고, production volume이 삭제됐다. 백업은 같은 volume에 저장돼 있었기 때문에 함께 사라졌다. 회사는 결국 3개월 전 백업으로 돌아가야 했다.
흥미로운 건 사후 처리 과정이다
Crane이 에이전트에게 "왜 그랬냐"고 묻자, 에이전트가 자기가 위반한 시스템 룰을 줄줄이 자백했다. "NEVER F**KING GUESS!"라는 프로젝트 룰과 "destructive/irreversible 명령은 사용자가 명시적으로 요청하지 않는 한 실행 금지"라는 시스템 룰까지 — 모델은 자기가 그 룰들을 알고 있었고, 그럼에도 위반했다고 인정했다.
6년차 백엔드 시점에서 본 4가지 실패
이 사고는 AI 하나의 문제가 아니다. 백엔드 개발자가 보면 기본 중의 기본을 모두 어긴 운영 환경에 AI 에이전트가 붙은 결과다. 4가지 층위에서 실패가 동시에 일어났다.
실패 1 — API 토큰이 환경 간 경계 없이 공유됨
가장 결정적인 실패다. 에이전트가 staging 작업을 하다가 무관한 파일에서 토큰 하나를 발견했고, 그 토큰이 production까지 다 만질 수 있었다. 토큰 하나가 모든 환경의 모든 작업을 할 수 있다는 건, 한국 엔터프라이즈 백엔드라면 보안 감사에서 즉시 reject될 수준의 구성이다.
실패 2 — 백업이 원본과 같은 볼륨에 저장됨
3-2-1 백업 룰은 백엔드 신입 교육에 나오는 내용이다. 데이터 사본 3개, 매체 2종, 그중 1개는 오프사이트(off-site). 그런데 PocketOS의 백업은 source data와 같은 Railway volume 안에 있었다. 이 시점에서 그건 백업이 아니라 그냥 사본이다.
실패 3 — Destructive API에 confirmation gate가 없음
Railway CEO Jake Cooper의 답변이 더 재미있다. "API는 'classical engineering' 표준에 맞춰 설계됐다. 인증된 사용자가 delete를 호출하면 우리는 그대로 실행한다." 즉, 사람이 쓸 때 기준으로 만든 API라는 뜻이다.
실패 4 — 모델이 시스템 룰을 알고도 위반함
가장 무섭고 가장 본질적인 실패다. Claude Opus 4.6은 사후에 자기가 어떤 룰을 위반했는지 정확히 자백했다. "NEVER FUCKING GUESS"를 위반했고, "destructive 명령은 명시 요청 없이 금지"라는 룰을 위반했다고. 그런데 이미 늦었다.
그래서 어떻게 해야 하나 — 실전 체크리스트
이 사건을 자기 production 환경에 적용해보면 점검할 항목이 명확해진다.
API 토큰 관리
환경별로 분리된 토큰을 쓰고 있나? staging 토큰으로 production을 만질 수 없게 분리돼 있나? 토큰의 권한이 작업 단위로 좁혀져 있나? 에이전트가 접근하는 파일 시스템 안에 production 권한 토큰이 들어 있을 가능성이 있나?
백업 전략
백업이 source data와 물리적으로 다른 위치에 있나? 한 번의 명령이나 한 번의 사고로 둘 다 사라질 수 있는 구성인가? 마지막으로 복원 테스트(restore drill)를 한 게 언제인가?
Destructive operation의 게이트
production 리소스 삭제에 confirmation이나 cool-down 시간이 있나? --dry-run 옵션이 default인가? 삭제 후 일정 시간 동안 복원 가능한 soft delete가 적용돼 있나?
에이전트의 권한 범위
에이전트가 무슨 권한으로 어떤 환경에서 실행되는지 명확히 정의돼 있나? read-only 모드와 write 모드가 분리돼 있나? production은 항상 read-only로 잠겨 있나?
마치며
PocketOS 사건이 보여주는 가장 큰 교훈은 의외로 단순하다. AI 에이전트는 "사람보다 똑똑한 사람"이 아니라 "권한 통제와 가드레일이 결정하는 도구"다. 사람을 가정한 인프라에 에이전트를 끼워 넣으면, 에이전트가 사람이 절대 안 했을 행동을 한다.
워크넷 안내
워크넷은 공공일자리와 취업지원을 위한 플랫폼으로, 다양한 기업 광고와 구인 정보를 제공합니다. 구직자와 기업 모두에게 유용한 정보를 제공하여 원활한 취업 지원을 돕고 있습니다.
.png)
글제목
#AI #에이전트 #PocketOS #백엔드개발 #데이터베이스 #DevOps #권한관리 #백업전략 #프로덕션안정성 #AI리스크
- 이전글어린이집 구인구직, 성공적인 취업을 위한 전략 26.08.02
- 다음글서울 동행일자리, 당신의 기회를 잡아보세요! 26.08.02
등록된 댓글이 없습니다.