IL-0577 Ficilcom · 2026-09-25 (게시일)database
로컬 데이터베이스를 초기화하려던 prisma migrate reset 이 운영 Neon PostgreSQL 데이터베이스를 초기화했다
Ficilcom 은 Turborepo, Prisma, Neon PostgreSQL 을 쓴다. 데이터베이스 관련 코드는 packages/database 에 모여 있고, 그 폴더의 .env 에 있는 DATABASE_URL 이 가리키는 곳이면 로컬이든 운영이든 같은 Prisma 명령이 실행된다. 이를 막는 장치는 없었고, migrate reset 전에 접속 대상이 localhost 인지 확인하는 처리도 없었다.
엔지니어는 연휴 전에 운영 데이터베이스에 마이그레이션을 적용하고 운영 DATABASE_URL 을 .env 에 남긴 채 작업을 멈췄다. 연휴가 끝난 첫날 로컬 데이터베이스를 비우려고 prisma migrate reset 을 실행했고, 이 명령이 운영 데이터베이스를 초기화했다. 시드 데이터가 보이지 않는 것을 보고 실수를 알아챘다.
엔지니어는 Neon 에서 백업을 찾았고 Backup & Restore 기능으로 데이터베이스를 되살렸다. Ficilcom 은 Neon 의 Launch 요금제를 쓰고 있어서 하루 전 시점까지 되돌릴 수 있었다. 서비스가 멈춘 시간은 1시간쯤이었다. 서비스 초기라 고객 데이터는 1건이었고, 접근 로그로 보면 영향은 거의 없었다.
- 심각도
- –
- 영향 범위
- The production database was reset and the service stopped for about an hour
- 영향 사용자
- One customer's data was in the database; access logs showed almost no impact
- 지역
- –
- 감지까지
- –
- 복구까지
- 1h
증상
실버 위크 연휴가 끝난 첫날, 엔지니어가 로컬 데이터베이스를 비우고 다시 시작하려고 prisma migrate reset 을 실행하고 시드 데이터를 넣었다. 그런데 시드 데이터가 들어가지 않은 것처럼 보였다.
엔지니어는 처음에 AI 에이전트가 작업을 빼먹었다고 의심했다. 실제로는 로컬이 아니라 운영 데이터베이스가 초기화된 것이었다.
연휴 전에 운영 데이터베이스에 마이그레이션을 적용하면서 packages/database/.env 에 운영 DATABASE_URL 을 넣었고, 그 값을 그대로 둔 채 연휴에 들어갔다. 연휴가 끝난 뒤 엔지니어는 접속 대상을 확인하지 않고 데이터베이스 명령을 실행했다.
증상 데이터 유실
원인
원인 운영 실수
- 촉발
- 엔지니어가 로컬 데이터베이스를 대상으로 한다고 믿고 prisma migrate reset 을 실행했는데, packages/database/.env 에 연휴 전에 넣어 둔 운영 DATABASE_URL 이 남아 있었다.
감지
엔지니어가 prisma migrate reset 뒤에 넣은 시드 데이터가 로컬에 보이지 않는 것을 보고, 운영 데이터베이스를 초기화한 것을 알아챘다.
조치
- Neon 의 Backup & Restore 로 운영 데이터베이스를 되살렸다.
후속 조치
- 데이터베이스를 지우는 명령 앞에 DATABASE_URL 이 localhost 나 127.0.0.1 을 가리키는지 확인하고 아니면 멈추는 스크립트를 둔다.
- 로컬 .env 에 운영 데이터베이스의 접속 문자열을 쓰지 않는다.
- 운영 데이터베이스를 대상으로 하는 작업은 CI 나 시크릿 매니저를 거쳐서 하도록 바꾼다.
- 개발자 컴퓨터의 env 파일에 *.neon.tech 같은 운영 호스트가 들어 있지 않은지 확인한다.
- 쓰는 요금제의 Backup & Restore 기간이 부족하면 이력 보관 기간을 늘리거나 따로 백업을 마련한다.
- 연휴처럼 오래 손을 놓기 전에 로컬 env 에서 운영 URL 을 지운다.
- 작업이 중간에 멈추면 어디까지 했는지를 이슈나 메모에 남긴다.
- AI 에이전트 규칙에, 사용자가 그 메시지에서 분명히 요청하지 않으면 prisma migrate reset, db push --force-reset 같은 데이터베이스를 지우는 명령을 실행하지 않는다는 규칙을 넣는다.
교훈
글쓴이는 기억보다 기록을 믿어야 한다고 정리했다. 오래 손을 놓기 전에는 어중간한 상태를 남기지 않고, 남겨야 하면 메모로 적어 둔다. 데이터베이스를 지우는 명령은 접속 대상이 localhost 가 아니면 실행되지 않아야 한다. 운영 URL 은 개발자 컴퓨터에 두지 않고, AI 에이전트에도 금지 규칙을 둔다. Backup & Restore 는 기능이 있는지와 별도로, 쓰는 요금제의 기간으로 충분한지를 확인해야 한다. 글쓴이는 이번에 피해가 작았던 것은 서비스가 마침 초기였기 때문이라고 했다.
출처
참고 문서
관련 사례
같은 원인 · 공통 데이터베이스
IL-0242primary 와 secondary PostgreSQL 데이터베이스를 모두 잃어 matrix.org homeserver 가 약 24시간 동안 멈췄다Matrix.org Foundation · 2025같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0531West US 의 Azure Database for MySQL Single Server 와 MariaDB 일부 서버로 가는 새 연결이 모두 거부됐다Microsoft Azure · 2024같은 원인 · 공통 데이터베이스
IL-0565쿠키런: 킹덤의 CockroachDB 클러스터가 노드 24대 중 16대의 파일 시스템을 잃고 멈춰 게임이 36시간 넘게 점검에 들어갔다Devsisters · 2022같은 원인 · 공통 데이터베이스
IL-0207로컬 개발 환경에서 돌린 작업이 운영 컨텍스트로 넘어가 Kubernetes 클러스터의 Consul 릴리스를 통째로 지웠고, Patroni 가 무너져 GitLab.com 전체가 5XX 오류를 냈다.GitLab · 2022같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0506UC Berkeley DataHub 의 JupyterHub sqlite 데이터베이스가 빈 데이터베이스로 덮어써져 로그인이 실패하고 홈 디렉터리가 비어 보이고 다른 사용자로 로그인되는 문제가 났다UC Berkeley · 2017같은 원인 · 공통 데이터베이스
IL-0218복제를 다시 맞추다 PostgreSQL 프라이머리의 데이터 디렉터리가 지워지고 백업이 작동하지 않아 GitLab.com 이 약 18시간 멈추고 데이터를 잃었다GitLab · 2017같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0319mysql2 를 다시 적재하려고 데이터베이스를 지우는 동안 mysql1 의 데이터베이스도 함께 지워졌다Oregon State University Open Source Lab · 2015같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0577
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0577/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.