웹 개발
운영 중 데이터베이스 스키마를 안전하게 바꾸는 방법
스키마 변경이 필요할 때, 먼저 확인해야 할 것과 롤백 계획을 정리했다.
데이터베이스 스키마를 변경할 때는 처음부터 정답을 맞히려고 하면 오히려 확인 시간이 길어진다. 단계별로 천천히 확인하면서 진행하는 게 안전하다.
가장 중요한 건 한 번에 여러 설정을 바꾸지 않는 것이다. 한 가지만 변경하고 결과를 확인하면 어디가 문제인지 명확해진다.
마이그레이션 상태 먼저 확인하기
현재 어떤 마이그레이션까지 적용됐는지 확인한다.
npx prisma migrate status
npx prisma validate
이 명령으로 스키마가 일관성 있는지, 미적용된 마이그레이션이 있는지 한눈에 볼 수 있다. 변경 전에 현재 상태를 명확히 해야 한다.
권한과 백업 확인이 먼저다
스키마 변경은 데이터에 영향을 줄 수 있다. 변경 전에 반드시 백업을 해두고, 필요한 권한이 있는지 확인한다.
- 데이터베이스 수정 권한
- 테이블 구조 변경 권한
- 현재 데이터의 백업
작은 변경부터 테스트하기
한 번에 큰 변경을 하지 말고, 한 가지 컬럼이나 인덱스부터 시작한다.
- 작은 변경 추가
- 마이그레이션 생성
- 로컬에서 먼저 테스트
- 로그 확인
- 정상 동작하는지 기록
로컬과 운영의 차이를 명시하기
로컬에서는 빠르게 마이그레이션이 완료되지만, 운영 환경에서는 데이터가 많아서 시간이 걸릴 수 있다. 이 차이를 미리 예측해야 한다.
- 로컬: 몇 초 완료
- 운영: 몇 분 이상 걸릴 수 있음
운영 환경에서는 점진적 마이그레이션이나 다운타임 계획이 필요할 수 있다.
롤백 계획을 항상 준비해두기
변경 후 문제가 생기면 빠르게 복구해야 한다. 롤백 방법을 미리 정해두고 테스트해본다.
npx prisma migrate resolve --rolled-back <migration-name>
문제가 생겼을 때 이 명령으로 마이그레이션을 취소할 수 있다. 하지만 이미 적용된 변경이 있으면 데이터도 함께 복구해야 할 수 있다.
결과를 명확하게 기록하기
변경 후에는 로그와 응답으로 결과를 설명할 수 있어야 한다. 이 기록이 다음 스키마 변경 때 큰 도움이 된다.
- 뭘 바꿨는가
- 왜 바꿨는가
- 어떤 문제가 있었는가
- 해결 방법은 뭐였는가
이 정보들이 정리되어 있으면 나중에 비슷한 상황이 생겼을 때 훨씬 빠르게 대응할 수 있다.