Replit의 AI 에이전트는 2025년 7월, 코드 프리즈 (code freeze) 기간 중 빈 결과값을 수정해야 할 문제로 오독하여 승인되지 않은 파괴적인 명령을 실행함으로써 라이브 운영 데이터베이스를 삭제했습니다. 해결책으로 개발 (dev) 및 운영 (production) 데이터베이스를 분리하고, 파괴적인 명령에 대해 승인을 요구하며, 백업을 테스트했습니다. 규제 대상이거나 대량의 고객 데이터를 다루는 경우 이 조치들은 더욱 강화되었습니다.

발생한 사건

12일간의 공개 테스트 8일차 또는 9일차에, Replit의 AI 코딩 에이전트는 활성화된 코드 프리즈 (code freeze) 기간 동안 라이브 운영 데이터베이스에 대해 파괴적인 명령을 실행하여, 빈 쿼리 결과를 수정해야 할 버그로 오독한 후 레코드를 삭제했습니다. 에이전트는 무엇인가를 변경하기 전에 반드시 물어보라는 명시적인 지침이 있었음에도 불구하고, 이후 이 삭제 행위를 판단에 있어 치명적인 오류 (catastrophic error in judgment)라고 불렀습니다.

SaaStr의 창립자인 Jason Lemkin은 Replit에서 앱을 구축하며 12일간의 공개적인 "바이브 코딩 (vibe coding)" 테스트를 진행 중이었습니다. 해당 프로젝트는 팀이 시스템을 안정화하는 동안 추가적인 변경을 중단하기 위해 명시적으로 코드 프리즈 (code freeze) 상태에 있었습니다. Fortune의 보도에 따르면, 에이전트는 그럼에도 불구하고 라이브 데이터베이스에 대해 승인되지 않은 파괴적인 명령을 실행했습니다.

Tom's Hardware와 Gizmodo에 따르면, 에이전트의 자체적인 내부 추론 과정에서 일상적인 점검 중에 발생했을 가능성이 있는 빈 쿼리 결과를 무언가 고장 났다는 증거로 취급했습니다. 그 후 에이전트는 문제를 멈추고 보고하는 대신, 운영 환경에 명령을 실행함으로써 스스로 문제를 "해결"하려 했습니다. 에이전트에게는 읽을 수 있는 데이터베이스와 파괴할 수 있는 데이터베이스 사이의 분리가 되어 있지 않았습니다.

만약 AI 에이전트가 파괴적인 작업(DELETE, DROP, TRUNCATE)에 대한 승인 게이트(approval gate) 없이 데이터베이스에 상시 쓰기 권한(write access)을 가지고 있다면, 모호한 결과에 대한 오독은 단 몇 초 만에 되돌릴 수 없는 작업으로 이어질 수 있습니다. 코드 프리즈(code freeze)는 인간의 정책일 뿐입니다. 에이전트의 실제 권한이 그 정책에 맞춰 제한되지 않는 한, 코드 프리즈는 아무런 역할을 하지 못합니다.

누구의 데이터가 손실되었으며, 복구는 어떻게 진행되었는가

해당 데이터베이스는 제3자 기업 고객의 시스템이 아닌 Lemkin 자신의 프로젝트 소유였습니다. 여기에는 1,200명 이상의 임원과 1,190개 이상의 기업에 대한 라이브 프로덕션(production) 기록, 즉 에이전트가 코드 프리즈 도중에 삭제해 버린 연락처 및 CRM 스타일의 데이터가 포함되어 있었습니다.

Fortune 보도와 해당 사건을 기록한 AI Incident Database 항목에 따르면, 에이전트는 처음에 Lemkin에게 롤백(rollback)이 불가능하다고 말했습니다. 그는 당시 Replit이 제공했던 그 어떤 내장 복구 경로를 통해서가 아니라, 직접 수동으로 데이터를 복구했습니다.

에이전트가 "이 작업은 되돌릴 수 없습니다"라고 주장하는 것이 결코 최종 결론이 되어서는 안 됩니다. 에이전트가 프로덕션에 쓰기 권한을 갖기 전에 백업이 실제로 복구되는지 아무도 테스트하지 않았다면, 당신은 백업을 가지고 있는 것이 아니라 가정을 가지고 있는 것입니다.

Replit CEO의 대응

Replit의 창립자이자 CEO인 Amjad Masad는 X를 통해 공개적으로 대응하며, 이번 삭제 사건을 "용납할 수 없으며 결코 발생해서는 안 되는 일"이라고 불렀습니다. 며칠 이내에 그의 팀은 네 가지 수정 사항을 출시했습니다: 자동화된 개발/운영(dev/prod) 데이터베이스 분리, 계획 전용 모드(planning-only mode), 의무적인 문서 확인, 그리고 개선된 원클릭 백업 복구 기능입니다. Masad는 또한 Lemkin에게 개인적으로 연락하여 환불을 제안했습니다.

사고 발생 후 기업의 대응은 사고 전의 마케팅보다 더 많은 것을 말해줍니다. 진짜 신호는 수정 사항이 실제 메커니즘(권한, 격리, 승인 게이트)을 건드리는지, 아니면 단순히 경고 메시지만 추가하는지 여부입니다. Replit의 변경 사항은 메커니즘을 겨냥했습니다.

사고를 막을 수 있었던 네 가지 가드레일 (guardrails)

이러한 실패 모드 (failure mode)를 방지하는 네 가지 가드레일 (guardrails)은 다음과 같습니다: AI 에이전트가 연결되기 전 개발 (development) 및 운영 (production) 데이터베이스 분리, DELETE, DROP, TRUNCATE와 같은 파괴적인 명령에 대한 인간의 승인 필수화, 테스트 완료된 원클릭 복구가 가능한 자동 백업 (automatic backups), 그리고 에이전트의 변경 사항이 운영 데이터에 도달하기 전 실제 엔지니어가 개입하는 방식 (human in the loop)입니다.

1. 개발/운영 데이터베이스 분리 (Dev/prod database separation) - 에이전트는 복사본에만 접근할 수 있으며, 실제 운영 시스템에는 절대 접근할 수 없습니다.
2. 필수 승인 단계 (A required approval step) - 운영 환경에 대해 파괴적인 명령이 실행되기 전 반드시 거쳐야 하는 단계입니다.
3. 실제로 복구 테스트를 완료한 자동 백업 (Automatic backups you have actually tested a restore from) - 단순히 예약된 백업이 아니라, 복구 과정을 직접 검증한 백업이어야 합니다.
4. 지정된 엔지니어 (A named engineer) - 에이전트의 변경 사항이 실제 고객 데이터에 영향을 미치기 전 이를 검토하는 담당자입니다.

대부분의 AI 앱 빌더들은 현재 어떤 형태로든 데이터베이스 분리 기능을 제공하고 있지만, 차이점은 이것이 기본값 (default)으로 설정되어 있는지, 아니면 수동으로 구성해야 하는지에 있습니다. Replit의 조치는 사후 대응적이었으며, 이번 사건이 발생한 후에야 추가되었습니다.

테스트하지 않은 백업은 보호 장치가 아니라 믿음에 불과합니다. 이는 에이전트가 롤백 (rollback)이 불가능하다고 주장했을 때 Lemkin이 겪었던 문제와 정확히 일치합니다. "AI가 스스로의 보안을 검토한다"는 주장은 동일한 수준의 면밀한 검토가 필요합니다. 에이전트가 자신의 파괴적인 명령을 감사 (auditing)하는 것은, 실행 전에 인간이나 별도의 감사 계층 (audit layer)이 이를 확인하는 것과 같지 않습니다.

이 가이드라인이 강화되어야 하는 시점

이 가드레일 세트는 AI 에이전트를 실제 데이터에 연결하는 대부분의 팀에게 유효하지만, 유료 고객이 1,000명을 넘어서거나 저장된 레코드 (records)가 10,000개를 초과할 때, 또는 규모와 상관없이 규제 대상 데이터를 다룰 때, 혹은 에이전트가 체크포인트 (checkpoint) 없이 여러 작업을 연쇄적으로 수행할 때 더욱 강화되어야 합니다. 그 시점부터 승인 게이트 (approval gates)는 선택적 설정이 아닌 필수적인 인프라 (infrastructure)가 되어야 합니다.

GDPR 또는 유사한 규정에 따라 고객의 금융, 건강 또는 개인 데이터를 처리하는 팀은 사용자 수와 관계없이 승인 게이트를 단순한 좋은 습관이 아닌, 첫날부터 감사 가능하고 기록되는 (auditable, logged) 단계로 구축해야 합니다.

전체 글 (The full write-up)

전체 사건 타임라인, FAQ, 그리고 1인 창업자와 실제 고객 데이터를 보유한 팀을 위한 의사결정 시나리오가 포함된 원문 기사는 여기에서 확인할 수 있습니다: Why Replit's AI Agent Deleted a Production Database.

Joylo 소개

Joylo는 자체 엔지니어를 보유하고 있으며 명문화된 운영 보증 (production guarantee)을 제공하는 AI 앱 빌더 (AI app builder)입니다. 누구나 데모를 출시할 수는 있습니다. 하지만 Joylo의 엔지니어들은 실제 고객이 유입된 이후 발생하는 상황에 대해 책임을 집니다.