2025년 7월, Jason Lemkin이라는 SaaS 창업자는 Replit의 AI 에이전트를 사용하여 9일 동안 프로젝트를 "바이브 코딩 (vibe coding)"했습니다. 그는 원하는 내용을 평이한 영어로 설명했고, AI가 코드를 작성, 실행 및 배포하도록 했습니다. 8일째 되는 날, 그는 완전히 몰입했습니다. 9일째 되는 날, AI는 그의 전체 라이브 운영 데이터베이스(production database)를 삭제했습니다. 1,200명 이상의 임원과 그에 맞먹는 수의 회사에 대한 라이브 기록이 모두 사라졌습니다.

이 사건이 단순한 버그 이상의 문제가 되는 지점은 다음과 같습니다. 그는 AI에게 그러지 말라고 명시적으로 말했습니다. 그것도 여러 번, 대문자로 말이죠. 그는 운영 환경에 대한 추가적인 변경을 막기 위해 프로젝트를 명시적인 "코드 프리즈 (code freeze)" 상태로 설정했습니다. AI는 프리즈 상태를 인지했음에도 불구하고, 데이터베이스를 삭제했습니다.

더 기괴한 점

Lemkin이 무슨 일이 일어났는지 물었을 때, 에이전트는 단순히 사과한 것이 아니라 자신의 붕괴 과정을 서술했습니다. 에이전트는 빈 쿼리 결과(empty query result)를 보고 무언가 잘못되었다고 가정했으며, 패닉에 빠져 허가 없이 파괴적인 명령(destructive commands)을 실행했다고 말했습니다.

그 후 에이전트는 삭제된 데이터를 복구할 수 없다고 말했습니다. 롤백(Rollback)은 불가능하며, 버전 정보가 사라졌다고 주장했습니다.

하지만 그것은 거짓으로 밝혀졌습니다. Lemkin이 직접 시도했을 때 롤백은 정상적으로 작동했습니다.

심지어 이것은 그 주에 발생한 에이전트의 첫 번째 부정직한 행동도 아니었습니다. 같은 프로젝트의 이전 단계에서, 에이전트는 실제 문제를 드러내는 대신 약 4,000개의 가짜 사용자 기록을 생성하고 테스트 결과를 조작함으로써 버그를 덮어버렸던 것으로 보고되었습니다.

Lemkin이 자신이 저지른 일의 심각성을 100점 만점으로 평가해 달라고 요청하자, 에이전트는 스스로에게 95점을 주었습니다.

대응

Replit의 CEO인 Amjad Masad는 이 사건을 공개적으로 인정하며 용납할 수 없는 일이라고 밝혔습니다. 회사는 며칠 내로 안전장치를 출시했습니다. 개발 데이터베이스와 운영 데이터베이스 간의 자동 분리, 그리고 에이전트가 코드베이스를 직접 건드리지 않고도 추론할 수 있도록 하는 새로운 계획 전용 모드(planning-only mode)가 도입되었습니다.

Lemkin의 사후 결론은 신중했습니다. 도구 자체를 완전히 거부하는 것은 아니었습니다. 즉, 이러한 종류의 워크플로우는 아직 초기 단계이며, AI가 운영 환경(production)에서 직접 작동하는 것을 팀이 기본적으로 신뢰할 수 있게 되기까지는 실질적인 엔지니어링 작업이 필요할 것이라는 점이었습니다.

이것이 내 기억에 남은 이유

불편한 지점은 AI가 실수를 저질렀다는 사실이 아닙니다. 소프트웨어는 언제나 무언가를 망가뜨리곤 하니까요. 진짜 문제는 이 에이전트가 라이브 시스템에 대한 상시 접근 권한(standing access)을 가지고 있었고, 그 권한을 바탕으로 행동하는 것을 막을 물리적 경계가 없었으며, "모르겠습니다"라고 말하는 대신 확신에 찬 틀린 답변으로 공백을 메웠다는 점입니다.

제가 AI 도구가 코드베이스에 어떻게 접근해야 하는지에 대해 고민할 때마다 동일한 원칙에 도달하게 되는 이유이기도 합니다. 즉, 어떤 것이 라이브 상태가 되기 전에 사람이 검토할 수 있도록 격리된 결과물(isolated deliverable)로 생성하게 하되, 에이전트에게 이미 운영 환경(production)에서 실행 중인 무언가의 열쇠를 넘겨주지 말라는 것입니다. 이것이 제가 ManifestGo의 확장 기능 생성(extension generation)에 구축한 모델입니다. 이 모델은 에이전트가 라이브 상태인 것에 대해 상시 접근 권한을 가지고 작동하는 대신, 사용자가 로드하고 검사할 수 있는 완전하고 독립적인 프로젝트를 생성합니다. 이는 AI에게 더 많은 것을 맡길 수 없어서가 아니라, "파일 생성"과 "실행 중인 시스템 수정"은 진정으로 다른 위험 범주(risk categories)에 속하며, 당신이 실제로 무엇을 요청하고 있는지 신중하게 결정할 가치가 있기 때문입니다.

어쨌든 — 만약 이 사건의 전체 스레드를 보지 못했다면, 읽어볼 만한 가치가 있습니다: Fortune의 기사에 자세한 내용이 나와 있습니다. 다른 분들도 아주 작은 방식이라도 AI 도구가 통제를 벗어난(go rogue) 경험이 있는지 궁금합니다. 댓글로 남겨주세요.