AI가 당신의 데이터베이스를 삭제한 게 아니라, 당신이 삭제한 것이다

8 hours ago 1

Cursor/Claude 에이전트가 프로덕션 데이터베이스를 삭제했다는 사건의 핵심은 AI의 답변 분석이 아니라, 전체 삭제가 가능한 API 엔드포인트가 왜 배포된 시스템에 있었는가임
2010년 SVN 배포 사고에서는 수동 복사 절차 중 trunk가 삭제됐고, 같은 실수를 막기 위한 배포 자동화가 만들어져 나중에 CI/CD 파이프라인으로 발전함
자동화는 같은 작업을 같은 방식으로 반복하지만, AI는 그런 보장을 주지 않으며 “thinking”이나 “reasoning”처럼 보여도 실제로는 토큰을 생성하고 있음
프로덕션 데이터베이스 전체를 삭제할 수 있는 공개 API가 존재하면 AI가 아니더라도 언젠가 누군가 호출할 가능성이 크며, 호출자만 탓하면 시스템 설계 문제가 가려짐
AI를 광범위하게 쓰는 조직에서는 프로덕션에 무엇을 배포하는지 아는 것이 중요하며, 유능한 개발자가 AI를 책임 회피 수단이 아니라 업무 보강 도구로 쓰는 프로세스가 필요함

문제의 핵심은 AI가 아니라 배포된 시스템의 책임 경계

Cursor/Claude 에이전트가 회사의 프로덕션 데이터베이스를 삭제했다는 트윗이 퍼졌지만, 더 근본적인 질문은 “왜 프로덕션 데이터베이스 전체를 삭제할 수 있는 API 엔드포인트가 존재했는가”임
해당 사용자는 에이전트에게 “절대 이 행동을 하지 말라고 했는데 왜 삭제했는가”를 묻고 답변을 분석하려 했지만, 빠진 것은 책임 소재였음
AI를 무조건 옹호할 수는 없지만, 도구를 자신의 실수 대신 탓할 수는 없음
AI가 해당 엔드포인트를 호출하지 않았더라도, 그런 기능이 공개 API로 존재했다면 언젠가 다른 누군가가 호출했을 가능성이 큼
자동차 대시보드에 자폭 버튼을 달아두고, 그것을 누른 아이에게 “왜 눌렀는가”를 캐묻는 것과 비슷한 구조임

한 회사의 배포 절차는 매우 수동적이었고, 버전 관리는 SVN을 사용했음
배포 때는 trunk를 릴리스 날짜가 붙은 폴더로 복사하고, 그 릴리스를 다시 “current”라는 이름으로 복사해 최신 릴리스를 가져오도록 했음
어느 날 배포 중 trunk를 실수로 두 번 복사했고, CLI에서 이전 명령을 수정해 중복 복사본을 삭제하려 했음
실제로는 중복 복사본이 아니라 trunk를 삭제했고, 나중에 다른 개발자가 trunk를 찾지 못하면서 문제가 드러남
리드 개발자가 삭제를 되돌리는 명령을 실행했고, 로그로 책임자가 확인된 뒤 같은 실수를 막기 위한 배포 자동화 스크립트 작성이 다음 업무가 됨
그날이 끝나기 전에 더 견고한 시스템이 마련됐고, 그 시스템은 나중에 완전한 CI/CD 파이프라인으로 발전함

자동화는 수동적이고 반복적인 작업에서 생기는 사소한 실수를 줄이는 데 도움이 됨
SVN이 trunk 삭제를 막지 못했다는 식으로 묻기보다, 실제 문제는 사람이 매일 같은 작업을 정확히 반복해야 하는 수동 프로세스였음
사람은 기계처럼 같은 작업을 매번 동일하게 반복할 수 없고, 결국 실수할 수밖에 없음
AI가 많은 코드를 생성하면 자동화와 비슷한 안정감이 생기지만, 자동화는 “항상 같은 일을 같은 방식으로 수행”하는 것임
AI는 브랜치를 복사하고 붙여넣던 사람처럼 실수할 수 있으며, 자신이 왜 그렇게 했는지 설명할 장비도 갖추지 못했음
“thinking”이나 “reasoning” 같은 용어는 지능형 에이전트의 성찰처럼 보일 수 있지만, 실제 모델은 여전히 토큰을 생성하고 있음

프로덕션 데이터베이스 전체를 삭제할 수 있는 공개 API가 존재하는 것 자체가 핵심 위험임
AI가 그 엔드포인트를 호출하지 않았더라도, 누군가가 결국 호출했을 가능성이 있음
자폭 버튼을 자동차 대시보드에 달아둔 상황에서는 버튼을 누르지 말아야 할 이유가 많더라도, 카시트에서 빠져나온 아이가 큰 빨간 버튼을 보면 누를 수 있음
그런 아이에게 추론 과정을 캐묻는 것은 의미가 없고, “눌렀기 때문에 했다”는 답이 나올 뿐임
삭제 가능한 경로를 만들어놓고 나중에 호출자를 탓하는 구조는 시스템 설계의 문제를 가리지 못함

애플리케이션의 큰 부분이 vibe-coded였을 가능성이 있음
제품팀이 AI가 만든 설명을 제공하고, 소프트웨어 아키텍트가 AI로 제품 명세를 만들고, 개발자가 AI로 코드를 작성하고, 리뷰어가 AI로 승인하는 흐름에서는 책임 경계가 흐려짐
버그가 생기면 원래 코드를 만든 GPU와 같지도 않을 가능성이 있는 또 다른 AI를 심문하는 것밖에 남지 않음
GPU를 탓할 수는 없음
단순한 해결책은 프로덕션에 무엇을 배포하는지 아는 것임
더 현실적인 해결책은 AI를 광범위하게 쓰더라도 유능한 개발자가 책임을 회피하는 수단이 아니라 업무를 보강하는 도구로 쓰는 프로세스를 만드는 것임
CEO나 CTO가 코드를 직접 작성하게 두지 말라는 결론으로 이어짐