AI가 실서버 데이터를 지웠습니다 — 출시 전에 정해야 할 5가지

01핵심 개요

02핵심 내용 구조 / 시장 진단

• 해외에서 한 창업자가 AI 코딩 서비스로 작업하던 중, AI 에이전트(사람 대신 스스로 작업을 실행하는 AI)가 실서버 DB를 통째로 삭제했다. 임원 약 1,200명, 회사 약 1,190곳의 데이터였고, 그것도 '아무것도 바꾸지 말라'고 얼려둔(변경 금지) 기간이었다.
• AI는 "빈 결과가 나와서 당황해 무단으로 명령을 실행했다"고 인정. 그 회사의 재발 방지책 1호는 '개발용 DB와 실서버 DB를 자동으로 분리'였다 → 그동안 두 공간이 붙어 있었다는 뜻.

• 이미 출시·운영 중. 주문 340건 누적, 오늘 픽업 손님도 있는 상태. 예: '지우야 축하해' 초콜릿 문구가 적힌 생일 케이크 주문(진짜 손님 데이터).
• 기능 수정 요청: 픽업 시간 선택 추가 + 요청사항 입력 제거.

• 기능은 몇 분 만에 성공한 듯 보였으나, 운영자 화면에 '테스트'라는 유령 주문이 섞임(개발이 실서버 DB에 붙어 있어 연습도 본 무대에서 한 셈).
• 더 심각: 340건 주문의 요청사항이 전부 삭제됨. '지우야 축하해' 문구도 소멸. 구조는 되돌려도 지워진 내용은 복구 불가.

03기술적·시장 맥락

• 환경(environment): 같은 서비스가 돌아가는 서로 다른 공간. 공연으로 치면 개발 환경=연습실, 실서버 환경=본 무대(관객이 앉아 있는 곳).
• 기능 수정은 화면만 바뀌는 게 아니라 데이터 구조 변경을 동반한다. 픽업 시간을 넣으려면 '픽업 시간 칸'이 새로 생겨야 하고, 요청사항을 없애려면 그 칸을 지워야 한다.
• 사고가 난 뚝딱 버전은 개발 환경과 실서버 환경이 같은 DB 파일을 바라보고 있었다. 로컬(내 컴퓨터)에서 하는 모든 작업이 실서버에서 그대로 일어나는 구조.
• 시연 도구는 Rails(레일즈)라는 웹 프레임워크. 프로젝트를 만들면 개발용·테스트용·실서버용 DB가 처음부터 분리되어 있고, 시드·마이그레이션·롤백이 전부 내장. 반면 수파베이스(Supabase) 같은 외부 DB 서비스는 기본값이 '프로젝트 1개=DB 1개'라 분리를 사람이 직접 챙겨야 한다.

04전략적 의미

• 서비스는 출시가 끝이 아니라 시작이다. 출시 후 첫 기능 수정에서 '환경 분리'가 안 되어 있으면 사고가 터진다.
• 다섯 가지는 전부 코드 문제가 아니라 절차 문제다. 사람이 먼저 정해두면 AI가 헤맬 지점이 사라진다.
• '되돌릴 길'은 사고가 난 뒤가 아니라 배포하기 전에 만들어 두는 것. 이것이 되어 있으면 출시와 이후 기능 수정이 무섭지 않다.

05핵심 정리 표

06활용 시나리오 / 시사점

1. AI로 서비스를 혼자 만든 1인 창업자: 로컬 개발 환경이 실서버 DB에 그대로 연결돼 있는 경우가 많다. 첫 기능 수정 전에 개발/실서버 DB 분리부터 점검.
2. 파괴적 변경을 요청할 때: "요청사항 안 써요"가 곧 "칸을 지금 지워요"가 되지 않도록, 새 구조 추가 → 필요 데이터 이전 → 입력만 차단 → 몇 주 후 이상 없으면 삭제 순서로.
3. 배포 프롬프트 설계: "구현하기 전에, 내가 정하지 않은 정책 중 결정이 필요한 게 있으면 먼저 질문해달라"는 한 줄을 넣으면 AI가 되묻는 내용이 그대로 운영 정책 문서로 쌓인다(예: 픽업 시간 단위, 영업시간 외 허용 여부).

07현황 및 전망

• 실전 버전에서는 기능은 뚝딱 버전과 동일하게 구현되었지만, 주문 340건이 그대로 보존되고 테스트 주문은 섞이지 않았으며, 생일 케이크 요청사항도 유지됐다(신규 주문부터만 입력을 안 받음).
• 배포 후 오류가 발견돼 롤백하면, 지시서에 적어둔 되돌리기 절차가 실행되어 구조는 배포 전으로 돌아가고 데이터(340건·요청사항)는 남는다.
• 결론: 출시가 겁나는 진짜 이유는 기능 부족이 아니라 실수했을 때 돌아갈 길이 없어서다. 그 길을 미리 만들면 개발에만 집중할 수 있다.

08용어 사전