배포 전에 데이터베이스 마이그레이션 검증하기

데이터베이스 스키마 변경은 돌이킬 수 없는 작업이 많다. 특히 프로덕션의 실제 데이터에 적용할 때는 더욱 조심해야 한다.

로컬에서 먼저 검증

npx prisma migrate dev
# 또는 현재 상태만 확인
npx prisma migrate status

Pending 마이그레이션이 있는지, 스키마 변경이 의도한 대로 생성되었는지 본다.

마이그레이션 파일 내용 검토

생성된 SQL을 직접 읽는다.

cat prisma/migrations/[timestamp]_[name]/migration.sql

Prisma가 자동 생성한 SQL이 예상과 다를 수 있다. 특히:

• 기존 데이터를 지우는 구문이 없는지
• NOT NULL 제약을 추가할 때 기본값 설정이 있는지
• 인덱스 이름이 명확한지

스키마 유효성 검사

npx prisma validate

Type 오류나 문법 오류가 있으면 이 단계에서 잡힌다.

백업 확인

프로덕션 배포 전에 데이터베이스 전체 백업을 받았는지 확인한다.

# PostgreSQL
pg_dump -Fc $DATABASE_URL > backup_$(date +%Y%m%d).dump

# MySQL
mysqldump -u user -p database > backup_$(date +%Y%m%d).sql

롤백이 필요하면 이 백업이 생명줄이다.

마이그레이션 적용 전 드라이런

실제 적용하지 않고, 마이그레이션이 어떤 변경을 할지만 본다.

npx prisma migrate deploy --preview-feature  # 미리보기

Prisma CLI에서 정식 지원이 안 되면, 데이터베이스 도구로 직접 SQL을 실행해본다.

데이터 영향도 평가

NOT NULL 컬럼 추가, 고유 제약 추가, 컬럼 삭제 등은 기존 데이터에 영향을 준다.

-- 기존 데이터 확인
SELECT COUNT(*) FROM users;
SELECT COUNT(*) FROM users WHERE new_column IS NULL;

충돌이 예상되면, 먼저 데이터를 정정하고 마이그레이션한다.

테이블 크기 확인

큰 테이블에 인덱스를 추가하거나 컬럼을 추가하면 시간이 오래 걸린다.

# PostgreSQL
SELECT
  schemaname,
  tablename,
  pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename)) AS size
FROM pg_tables
WHERE schemaname NOT IN ('pg_catalog', 'information_schema')
ORDER BY pg_total_relation_size(schemaname||'.'||tablename) DESC;

데이터가 수억 건이면, 마이그레이션 중에 테이블이 잠길 수 있으니, 트래픽이 적은 시간대에 진행해야 한다.

프로덕션 환경 변수 확인

# 프로덕션 DATABASE_URL이 정말 프로덕션 DB를 가리키는지
echo $DATABASE_URL

# 잘못된 URL이 설정되어 있으면 롤백할 수 없다

환경 변수가 올바른지 세 번 확인한다.

마이그레이션 적용

npx prisma migrate deploy

중단되지 않도록 SSH 세션을 유지한다. 만약 네트워크가 끊기면 부분 적용 상태가 될 수 있다.

적용 후 검증

npx prisma db push  # 스키마와 DB 동기화 재확인

# 또는 직접 쿼리
SELECT * FROM information_schema.tables WHERE table_schema = 'public';

새로 추가한 컬럼이 있는지, 인덱스가 생성되었는지 확인한다.

롤백 준비

Prisma는 자동 롤백이 없다. 문제가 생기면:

1. 백업에서 복구하기
2. 또는 역방향 마이그레이션 파일을 수동으로 작성해서 실행하기

그래서 배포 전에 백업과 롤백 계획이 필수다.