운영 중인 DB에 새 컬럼을 만들고 앱 코드를 동시에 바꾸면 잠깐 다른 버전의 앱이 공존하는 동안 오류가 날 수 있습니다. 무중단 스키마 변경은 한 번에 바꾸는 일이 아니라 옛 코드와 새 코드가 함께 살아도 되는 기간을 설계하는 일입니다.
먼저 확장한다
새 컬럼이나 테이블을 추가하되 기존 앱이 그대로 동작하게 둡니다. 필수 제약이나 기본값 때문에 큰 테이블이 잠기는지 DB별 동작을 확인합니다. 새 앱이 배포되기 전에 스키마가 준비돼 있어야 합니다.
읽기와 쓰기의 전환을 나눈다
새 앱이 옛 필드와 새 필드 중 무엇을 읽고 쓰는지 단계별로 정합니다. 양쪽에 쓰는 기간이 필요할 수 있지만 영구 이중 쓰기는 복잡합니다. 백필 작업은 작은 배치로 진행하고 중단·재개 가능하게 만듭니다.
옛 버전이 사라진 뒤 축소한다
모든 앱 인스턴스와 배치 작업이 새 스키마를 사용한다는 증거가 있어야 옛 컬럼을 제거할 수 있습니다. 롤백 가능 기간에는 옛 구조를 유지합니다. 스키마 삭제는 되돌리기 어려우므로 별도 배포로 분리합니다.
큰 인덱스는 잠금 특성을 확인한다
PostgreSQL처럼 동시 인덱스 생성 옵션이 있는 DB도 작업량과 제약이 있습니다. 사용 중인 DB의 버전과 DDL 잠금 동작을 확인해 트래픽이 낮은 시점과 실행 한도를 정합니다. '동시'라는 이름이 무부하를 뜻하지 않습니다.
마이그레이션 자체를 관찰한다
잠금 대기, 복제 지연, 백필 진행률, 앱 오류율을 함께 봅니다. 문제가 생기면 어디까지 되돌릴 수 있는지 절차를 적습니다. 배포가 끝났다는 판단은 SQL이 성공한 시점이 아니라 옛·새 코드 모두 정상 동작하는 시점입니다.
현장에 적용할 때의 순서
- 기존 코드와 호환되는 컬럼을 먼저 추가한다
- 읽기·쓰기 전환과 백필을 단계적으로 진행한다
- 옛 코드가 사라진 뒤 구 스키마를 제거한다
주의할 실패: 앱 코드와 컬럼 삭제를 같은 배포에 묶으면 버전 공존 중 오류가 생길 수 있다.
관찰할 지표: DDL 잠금 대기, 백필 진행률, 앱 오류와 복제 지연을 본다.
적용 전 체크리스트
- 옛 앱과 새 앱이 함께 동작하는 스키마인가
- 백필이 작은 단위로 중단·재개 가능한가
- 옛 컬럼 삭제를 별도 단계로 미뤘는가
참고 자료
GitLab Docs: Avoiding downtime in migrations. GitLab 문서는 컬럼 제거를 지연하고 큰 데이터 변경을 백그라운드 작업으로 나눠 무중단 배포를 유지하는 사례를 설명합니다. 구체적인 DDL 잠금은 사용하는 DB 제품과 버전별로 확인해야 합니다.
이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.
#DB마이그레이션 #무중단배포 #스키마변경 #PostgreSQL #역호환 #백필 #데이터베이스 #인덱스 #운영안정성 #SaaS개발
