개인 프로젝트에서 로컬 DB를 바꿀 때 안전하게 하는 법

개인 프로젝트에서는 로컬 데이터베이스를 마음대로 변경할 수 있다. 하지만 무작정 바꾸면 나중에 뭘 어떻게 했는지 까먹고, 같은 작업을 여러 번 반복하게 된다.

마이그레이션 파일로 변경 이력 남기기

매번 손으로 SQL을 실행하지 말고, 마이그레이션 파일로 관리한다:

# Prisma를 쓴다면
npx prisma migrate dev --name add_user_email

# 또는 직접 SQL 마이그레이션을 만들 때
cat > migrations/001_add_user_email.sql << 'EOF'
ALTER TABLE users ADD COLUMN email VARCHAR(255) UNIQUE;
EOF

이렇게 하면 어떤 변경을 했는지 파일로 기록이 남는다. Git에 커밋하면 팀과도 공유할 수 있다.

현재 상태 파악하기

# Prisma 마이그레이션 상태 확인
npx prisma migrate status

# 스키마 확인
npx prisma db push --preview-only

# SQL 직접 확인
sqlite3 dev.db ".schema users"

현재 로컬 DB가 어떤 상태인지 알아야, 다음 변경을 안전하게 할 수 있다.

한 번에 하나씩 변경하기

여러 테이블을 한 번에 수정하고 싶어도 참는다. 한 번에 하나만:

# users 테이블에만 email 컬럼 추가
npx prisma migrate dev --name add_user_email

# 테스트해보고
npm test

# 그다음에 posts 테이블 변경
npx prisma migrate dev --name add_post_status

이렇게 하면 어느 마이그레이션에서 문제가 생겼는지 바로 알 수 있다.

변경 후 백업 만들기

# 변경 전에 백업
cp dev.db dev.db.backup.$(date +%s)

# 또는 자동 백업 설정 (cron)
0 * * * * cp /path/to/dev.db /path/to/backups/dev.db.$(date +\%s)

설정을 잘못 바꿔서 데이터가 깨져도 백업에서 복구할 수 있다.

스키마 검증 명령어들

# Prisma 스키마 검증
npx prisma validate

# 실제로 마이그레이션을 시뮬레이션
npx prisma migrate resolve --rolled-back add_user_email
npx prisma migrate resolve --applied add_user_email

# 또는 SQL이라면 미리 실행해보기
sqlite3 test.db < migrations/001_add_user_email.sql

마이그레이션을 실제로 적용하기 전에 시뮬레이션으로 테스트하면 실수를 줄일 수 있다.

로컬과 배포 환경 맞추기

로컬에서 DB를 바꿨다면, 배포 환경도 같이 변경해야 한다:

# 마이그레이션 파일 확인
git status migrations/

# 커밋해서 배포 환경에도 반영
git add migrations/
git commit -m "chore: add user email column"
git push

# 배포 환경에서
git pull
npx prisma migrate deploy

마이그레이션 파일로 관리하면 로컬과 배포 환경을 동기화하기가 훨씬 쉬워진다.