ci: 마이그레이션 리플레이 검증 — 빈 DB 에서 스키마 재현 + 드리프트 감지

[seizeh]

무엇을

지금까지 CI 는 스키마 스냅샷(schema.sql 12,730줄) 복원으로 테스트 DB 를 만들었다.
2026-06-08 이전 기반 스키마가 저장소 밖에 있어 마이그레이션만으로는 빈 DB 를 채울 수
없었기 때문이다. 그 결과 이 저장소만 받아서 올려보는 게 불가능했고, 마이그레이션
없이 운영 DB 에 직접 친 DDL 도 아무도 몰랐다.

빠진 조각을 스냅샷에서 역산해 baseline.sql 로 복원하고, 등식이 성립하는지 CI 가
매번 검증하게 한다.

빈 DB ─ prelude → replay-stubs → baseline → 기본권한 → migrations(175건)
                                                        ↓ pg_dump
빈 DB ─ prelude → schema.sql ────────────────────────── ↓ pg_dump  → diff

양쪽 다 복원→덤프를 거치게 한 건 pg_dump 출력이 되먹였을 때 글자 그대로 재현되지
않기 때문이다(파서가 배열 캐스트를 접는 등). 남는 왕복 아티팩트는
scripts/normalize_schema.py 가 정규화한다.

이걸로 잡힌 것 — 실제 드리프트

20260729070000_capture_prod_drift.sql 로 포착했다. 정의는 전부 schema.sql
(= 운영 덤프)에서 그대로 가져왔으므로 운영 적용은 no-op 이다.

1. app.dispatch_engagement_notifications 의 얼굴 필터 유실
   and w.context = p.authored_as(같은 얼굴 팔로워만)를 20260718160000 이 넣었는데
   20260720090000 의 create or replace 가 조용히 지웠다. 운영에는 살아 있지만
   저장소만 보고 재생하면 업체 소식이 개인 팔로워에게도 나간다.

2. 간이 회원(status='lite') 관련이 통째로 저장소 밖
   users_status_check 의 'lite', add_facility_review 의 app.uid_lite() 와
   재인증 게이트, 후기 조회의 전화번호 마스킹 등. 함수 36개 + 권한만 다른 함수 8개.

검증

• replay 잡: 마이그레이션 175건 적용 → 덤프 9,668줄이 스냅샷과 완전 일치
• 재생된 DB 에서 pgTAP 16종도 통과(형태만 맞고 의미가 틀린 경우 방지)
• 기존 pgtap 잡은 그대로(빠른 회귀)

로컬 실행

docker run -d --name pm -e POSTGRES_PASSWORD=postgres -p 54323:5432 \
  supabase/postgres:17.6.1.121 postgres -c cron.database_name=pmdb_replay
./scripts/replay_check.sh "postgresql://postgres:postgres@localhost:54323/postgres"

앞으로 스냅샷을 갱신하면(./scripts/dump_schema.sh) 베이스라인도 함께 재생성된다.

🤖 Generated with Claude Code