무중단 DB 마이그레이션 가이드

개발팀이 가장 긴장하는 배포 중 하나가 데이터베이스 스키마 변경입니다. 애플리케이션 코드는 롤백이 비교적 쉽지만, 스키마와 데이터는 되돌리기 비용이 훨씬 큽니다. 특히 트래픽이 높은 서비스에서 컬럼 변경이나 인덱스 재구성 같은 작업을 급하게 진행하면 응답 지연, 락 경합, 데이터 불일치가 한 번에 터질 수 있습니다. 그래서 DB 마이그레이션은 "한 번에 끝내는 작업"이 아니라, 단계적으로 위험을 줄이는 운영 시나리오로 접근해야 합니다.

실무에서 가장 효과적인 원칙은 간단합니다. 호환성을 먼저 확보하고, 삭제는 가장 마지막에 한다. 이 원칙을 지키면 서비스 중단 없이도 구조를 바꿀 수 있습니다. 반대로 기존 컬럼을 바로 제거하거나 읽기 경로를 급격히 전환하면 장애 가능성이 급격히 올라갑니다.

1. Expand-Contract 패턴으로 단계 분리하기

무중단 마이그레이션의 기본은 Expand-Contract 패턴입니다. 먼저 스키마를 확장하고(Expand), 코드가 새 구조를 읽고 쓸 수 있게 만든 뒤, 충분한 검증 후에 오래된 구조를 정리(Contract)합니다. 이 방식의 핵심은 전환 기간 동안 구/신 구조가 동시에 동작하도록 유지하는 것입니다.

예를 들어 full_name 컬럼을 first_name, last_name으로 분리한다면, 1단계에서 새 컬럼을 추가하고, 2단계에서 이중 쓰기(dual write)를 적용하고, 3단계에서 읽기 경로를 신컬럼 우선으로 바꾼 뒤, 4단계에서 구컬럼을 제거합니다. 단계가 많아 보이지만 실제 장애 확률은 크게 줄어듭니다.

2. 백필 작업은 배치 안전성이 우선

기존 데이터를 새 구조로 옮기는 백필은 종종 야간 한 번에 처리하려고 시도합니다. 하지만 대규모 업데이트를 단일 트랜잭션으로 처리하면 락과 IO 부하가 집중되어 실시간 트래픽에 영향을 줄 수 있습니다. 안전한 방법은 작은 배치 단위로 나누고, 부하 지표를 보며 점진적으로 처리하는 것입니다.

저는 보통 배치 크기, 처리 간격, 최대 동시성 세 가지를 별도 설정으로 둡니다. 운영 중 지연이 올라가면 즉시 배치 속도를 낮출 수 있어야 합니다. 또한 백필 진행률뿐 아니라 데이터 정합성 검증 쿼리를 함께 돌려, "많이 옮겼다"가 아니라 "정확하게 옮겼다"를 확인해야 합니다.

3. 읽기 전환은 플래그로 제어하기

읽기 경로를 한 번에 바꾸는 것은 위험합니다. 전환 직후 특정 쿼리 계획이 바뀌어 성능 문제가 생길 수 있기 때문입니다. 따라서 읽기 전환은 feature flag로 제어해 점진적으로 확대하는 방식이 안전합니다. 초기에는 내부 트래픽이나 작은 사용자 그룹만 새 경로로 보낸 뒤 지표를 확인합니다.

이 과정에서 확인해야 할 지표는 평균 응답 시간보다 tail latency(p95/p99)와 에러율입니다. 평균값은 정상처럼 보여도 일부 요청이 크게 느려질 수 있습니다. 전환 단계에서 tail 지표를 놓치면 장애를 늦게 발견하는 경우가 많습니다.

4. 롤백 계획은 "실행 가능한 문서"로 준비

마이그레이션에서 롤백은 마음가짐이 아니라 실행 절차여야 합니다. 문제가 생겼을 때 어떤 설정을 되돌리고, 어떤 배치를 멈추고, 어떤 데이터는 보존할지 순서가 문서화되어 있어야 합니다. 이 문서가 없으면 팀은 회의부터 하게 되고, 그 사이 서비스 영향은 커집니다.

좋은 롤백 문서는 세 줄로 요약됩니다. 무엇을 멈출지, 어디로 되돌릴지, 데이터 손실 위험은 무엇인지. 간결하지만 구체적이어야 합니다. 그리고 실제로 한 번 리허설해 보는 것이 중요합니다. 리허설 없는 롤백 계획은 위기 상황에서 거의 작동하지 않습니다.

5. 마이그레이션 완료 기준을 명확히 정의하기

많은 팀이 컬럼 삭제까지 끝나면 작업 완료라고 생각하지만, 운영 관점의 완료 기준은 더 넓습니다. 정합성 검증 통과, 성능 회귀 없음, 경보 안정화, 관련 코드 정리까지 포함해야 진짜 완료입니다. 특히 이중 쓰기 로직을 오래 남겨두면 이후 개발에서 예외 처리가 꼬이기 쉽습니다.

결론적으로 무중단 마이그레이션은 고급 SQL 테크닉보다 운영 절차가 좌우합니다. 단계 분리, 점진 전환, 지표 모니터링, 롤백 리허설. 이 네 가지를 체계적으로 반복하면, 데이터 구조 변경도 서비스 가동률을 해치지 않고 진행할 수 있습니다.