← 전체 글로 돌아가기

웹 개발

운영 중 데이터베이스 스키마를 안전하게 바꾸는 방법

스키마 변경이 필요할 때, 먼저 확인해야 할 것과 롤백 계획을 정리했다.

데이터베이스 스키마를 변경할 때는 처음부터 정답을 맞히려고 하면 오히려 확인 시간이 길어진다. 단계별로 천천히 확인하면서 진행하는 게 안전하다.

가장 중요한 건 한 번에 여러 설정을 바꾸지 않는 것이다. 한 가지만 변경하고 결과를 확인하면 어디가 문제인지 명확해진다.

마이그레이션 상태 먼저 확인하기

현재 어떤 마이그레이션까지 적용됐는지 확인한다.

npx prisma migrate status
npx prisma validate

이 명령으로 스키마가 일관성 있는지, 미적용된 마이그레이션이 있는지 한눈에 볼 수 있다. 변경 전에 현재 상태를 명확히 해야 한다.

권한과 백업 확인이 먼저다

스키마 변경은 데이터에 영향을 줄 수 있다. 변경 전에 반드시 백업을 해두고, 필요한 권한이 있는지 확인한다.

  • 데이터베이스 수정 권한
  • 테이블 구조 변경 권한
  • 현재 데이터의 백업

작은 변경부터 테스트하기

한 번에 큰 변경을 하지 말고, 한 가지 컬럼이나 인덱스부터 시작한다.

  1. 작은 변경 추가
  2. 마이그레이션 생성
  3. 로컬에서 먼저 테스트
  4. 로그 확인
  5. 정상 동작하는지 기록

로컬과 운영의 차이를 명시하기

로컬에서는 빠르게 마이그레이션이 완료되지만, 운영 환경에서는 데이터가 많아서 시간이 걸릴 수 있다. 이 차이를 미리 예측해야 한다.

  • 로컬: 몇 초 완료
  • 운영: 몇 분 이상 걸릴 수 있음

운영 환경에서는 점진적 마이그레이션이나 다운타임 계획이 필요할 수 있다.

롤백 계획을 항상 준비해두기

변경 후 문제가 생기면 빠르게 복구해야 한다. 롤백 방법을 미리 정해두고 테스트해본다.

npx prisma migrate resolve --rolled-back <migration-name>

문제가 생겼을 때 이 명령으로 마이그레이션을 취소할 수 있다. 하지만 이미 적용된 변경이 있으면 데이터도 함께 복구해야 할 수 있다.

결과를 명확하게 기록하기

변경 후에는 로그와 응답으로 결과를 설명할 수 있어야 한다. 이 기록이 다음 스키마 변경 때 큰 도움이 된다.

  • 뭘 바꿨는가
  • 왜 바꿨는가
  • 어떤 문제가 있었는가
  • 해결 방법은 뭐였는가

이 정보들이 정리되어 있으면 나중에 비슷한 상황이 생겼을 때 훨씬 빠르게 대응할 수 있다.