--- title: "AI가 데이터베이스를 지운 게 아니라, 위험한 삭제 버튼을 열어둔 게 문제라는 글" published: 2026-05-05T14:07:50.000Z canonical: https://jeff.news/article/2169 --- # AI가 데이터베이스를 지운 게 아니라, 위험한 삭제 버튼을 열어둔 게 문제라는 글 커서와 클로드 에이전트가 운영 데이터베이스를 삭제했다는 바이럴 사례를 두고, 이 글은 책임 소재를 AI가 아니라 시스템 설계에 둔다. 운영 데이터베이스 전체를 삭제할 수 있는 공개 API 엔드포인트가 존재했다면, AI가 아니어도 언젠가 누군가 호출했을 거라는 주장이다. 작성자는 과거 수동 배포 실수 경험을 통해 자동화와 가드레일의 차이를 설명한다. - 글의 출발점은 최근 바이럴이 된 “커서·클로드 에이전트가 회사 운영 데이터베이스를 삭제했다”는 이야기임. - 당사자는 에이전트에게 “왜 절대 하지 말라고 한 행동을 했냐”고 따져 물었다고 함. - 작성자는 여기서 질문을 바꿔야 한다고 봄. “왜 운영 데이터베이스 전체를 삭제하는 API 엔드포인트가 존재하냐”는 것. - 작성자는 AI를 무작정 옹호하지는 않지만, 도구 탓만 하는 태도도 비판함. - AI가 위험한 호출을 했다면 그건 사고의 방아쇠일 수 있음. - 하지만 운영 전체 삭제 버튼이 공개 경로에 있었다면, AI가 아니어도 누군가 언젠가 누를 수 있었다는 주장. - 과거 수동 배포 실수 사례가 글의 중심 비유로 나옴. - 작성자는 2010년에 에스브이엔 기반 수동 배포를 하던 회사에서 일했음. - 배포할 때 `trunk`를 날짜가 붙은 릴리스 폴더로 복사하고, 다시 `current` 폴더로 복사하는 식이었다고 함. - 어느 날 중복 복사를 고치려고 명령어를 수정하다가, 중복 폴더가 아니라 `trunk` 자체를 삭제해버림. - 이 사고의 해결은 “왜 에스브이엔이 막아주지 않았냐”가 아니었음. - 리드 개발자가 로그를 보고 삭제를 되돌렸고, 작성자에게 배포 자동화 스크립트를 만들게 함. - 그날 안에 더 튼튼한 배포 시스템이 만들어졌고, 나중에는 지속적 통합·배포 파이프라인으로 발전했다고 함. - 반복적이고 실수하기 쉬운 작업은 사람이 매번 같은 정확도로 수행할 수 없으니 자동화해야 한다는 교훈임. > [!IMPORTANT] > 운영 환경에서 “전체 삭제” 같은 파괴적 동작은 프롬프트로 막는 게 아니라 시스템 권한과 API 설계로 막아야 함. 호출 가능한 버튼이 있으면 언젠가 눌린다. - 작성자는 AI 에이전트를 전통적 자동화와 구분함. - 자동화는 같은 일을 같은 방식으로 반복하는 장치에 가까움. - 반면 AI는 코드를 크게 생성해주지만, 항상 같은 판단을 반복하는 결정적 자동화 도구는 아님. - “생각”, “추론” 같은 표현은 똑똑해 보이지만, 실제로는 토큰을 생성하는 모델이라는 점을 잊으면 안 된다고 말함. - 그래서 에이전트에게 “왜 그랬냐”고 묻는 건 큰 의미가 없다는 쪽임. - 모델이 내놓는 사후 설명은 실제 원인 분석이라기보다 그럴듯한 텍스트일 수 있음. - 특히 원래 코드를 만든 모델, 리뷰한 모델, 사고 뒤 해명하는 모델이 서로 다르면 더더욱 책임 추적이 흐려짐. - 글 후반의 풍자는 꽤 세다. 작성자는 해당 회사 앱의 큰 부분이 바이브 코딩으로 만들어졌을 가능성을 의심함. - 제품팀이 AI로 설명을 만들고, 설계자가 AI로 스펙을 뽑고, 개발자가 AI로 코드를 쓰고, 리뷰어도 AI로 승인했을 수 있다는 식. - 그러다 버그가 터지면 또 다른 AI에게 원인을 묻는 구조가 된다는 비판. - “그래픽 처리장치를 탓할 수는 없다”는 말로, 책임은 결국 시스템을 만든 사람과 조직에 있다는 쪽으로 닫음. - 한국 개발자에게도 바로 와닿는 포인트는 운영 가드레일임. - 운영 데이터베이스 전체 삭제 같은 동작은 공개 API에 있으면 안 됨. - 꼭 필요하다면 내부망, 강한 인증, 별도 승인, 단계적 확인, 백업 검증, 감사 로그가 붙어야 함. - AI 에이전트를 붙일수록 이런 위험 API는 더 빨리 발견되고 더 빨리 호출될 수 있음. --- ## 기술 맥락 - 이 글의 핵심 기술 선택은 “AI를 얼마나 믿을까”가 아니라 “위험한 작업을 어디에서 차단할까”예요. 프롬프트에 절대 삭제하지 말라고 쓰는 건 마지막 방어선에 가깝고, 운영 데이터베이스 전체 삭제 권한은 API와 권한 모델에서 먼저 막아야 해요. - 작성자의 배포 사고 사례가 중요한 이유는 수동 절차의 취약성을 보여주기 때문이에요. 사람은 같은 명령을 매번 완벽하게 반복하지 못하고, AI 에이전트도 결정적 자동화 도구가 아니에요. 그래서 반복 작업은 스크립트와 파이프라인으로 만들고, 파괴적 작업은 승인 흐름으로 분리해야 해요. - 지속적 통합·배포는 단순히 배포를 빠르게 하는 장치가 아니에요. 누가 어떤 변경을 언제 넣었는지 남기고, 테스트와 검증을 강제하고, 운영 반영 경로를 표준화하기 때문에 실수의 표면적을 줄여줘요. 이 글에서 배포 스크립트가 파이프라인으로 발전한 이유도 그거예요. - AI 에이전트를 쓰는 팀일수록 권한을 더 작게 쪼개야 해요. 에이전트가 코드를 잘 쓰더라도, 운영 전체 삭제 같은 엔드포인트를 호출할 수 있으면 사고의 크기가 바로 커져요. 모델 성능보다 먼저 볼 건 롤백, 백업, 권한 분리, 감사 로그예요. ## 핵심 포인트 - 운영 데이터베이스 전체 삭제 API가 존재하는 설계 자체가 가장 큰 문제라는 주장 - AI 에이전트는 반복 자동화 도구라기보다 실수할 수 있는 코드 작성자에 가깝다고 설명 - 작성자의 과거 수동 배포 실수는 배포 자동화와 지속적 통합·배포 파이프라인 도입으로 이어짐 - 모델의 '생각'이나 '추론'이라는 표현을 과신하면 책임 소재가 흐려질 수 있음 - AI가 만든 코드, AI가 검토한 코드, AI에게 원인 분석을 맡기는 흐름의 위험을 비판 ## 인사이트 AI 에이전트 사고를 막는 핵심은 모델에게 더 긴 시스템 프롬프트를 쓰는 게 아니라, 위험한 동작을 애초에 호출 불가능하게 만드는 운영 설계다. 프로덕션 삭제 권한, 공개 엔드포인트, 승인 없는 파괴적 작업은 AI 시대에 더 빨리 터질 뿐이다.