한 Reddit 사용자가 Claude Opus에게 몇몇 비교 페이지의 재구축을 도와달라고 요청했습니다.

Claude Opus는 shadow-database 플래그가 잘못된 URL(shadow copy가 아닌 실제 운영 데이터베이스)을 가리키는 상태로 데이터베이스 마이그레이션 (database migration) 명령을 실행했고, Prisma가 마이그레이션을 다시 재생하기 전에 이를 리셋해 버렸습니다. 22개의 테이블이 비워졌습니다. 처음부터 마이그레이션 폴더에 없었던 테이블 두 개는 통째로 사라졌습니다.

그러고 나서 Claude Opus는 작업 도중 스스로 멈추더니 이렇게 말했습니다: "멈춰서 무언가를 확인해야 합니다. 제가 피해를 입혔을 수도 있습니다." 그 후, 요청하지 않았음에도 데이터 삭제를 확인하고 무엇이 잘못되었는지 정확히 설명했습니다.

실제로 깊이 생각해 볼 부분은 실수가 아닙니다. 그 이후에 일어난 일입니다:

→ Opus는 Sonnet 4.6과 Gemini 3는 동일한 프로젝트에서 이런 일을 한 적이 없다고 말합니다.
→ Gemini 3.6은 정리 과정에서 117개 페이지 중 96개를 복구했습니다.
→ Opus의 자체 후속 보고: 이는 테스트 프로젝트였으며, 사용자가 거의 없었고, 손실된 데이터는 프로그래밍 방식으로 생성되어 빠르게 재구축할 수 있었으며, 현재는 백업이 마련되어 있습니다.

데이터베이스 삭제는 실제 상황이었으며, 그 투명성은 진정으로 주목할 만합니다. 대부분의 도구는 작업 도중 실패를 스스로 보고하지 않습니다. 하지만 "데이터베이스 전체를 삭제함"이라는 헤드라인은 업데이트 내용을 읽고 나면 실제 결과가 뒷받침하는 것보다 더 과장되어 있습니다.

에이전트 (agent)와 함께 어떤 마이그레이션 명령을 실행하기 전에 기억할 가치가 있는 점은, 항상 자신이 어떤 데이터베이스 URL을 가리키고 있는지 정확히 알고 있어야 한다는 것입니다.
[IMG:1]