[요약] Part 3. 실전 무중단 데이터베이스 마이그레이션

컬럼 이름을 직접 변경하면 안 되는 이유

개발 환경과 달리 운영 환경에서 파괴적 변경(Destructive Change)은 치명적인 결과를 낳습니다. 핵심 원인은 시스템 간의 타이밍 불일치입니다.

• 데이터베이스 스키마 변경 시점과 애플리케이션 배포 시점은 완벽하게 일치할 수 없습니다.
• 무중단 배포 중에는 항상 구버전 앱과 신버전 앱이 동시에 실행됩니다.
• `ALTER TABLE RENAME COLUMN` 또는 `DROP COLUMN`을 실행하는 즉시, 변경 전 이름을 참조하던 한쪽 버전의 애플리케이션은 100% 에러를 발생시킵니다.
• 이를 해결하려면 한 번에 구조를 바꾸는 대신, 하위 호환성(Backward Compatibility)을 철저히 유지하며 여러 단계로 나누어 점진적으로 변경해야 합니다.

무중단 스키마 변경 5단계 (Expand and Contract 패턴)

안전한 마이그레이션을 위한 만능 열쇠인 팽창과 수축(Expand and Contract) 전략의 구체적인 순서는 다음과 같습니다.

• 1단계: 신규 컬럼 추가 (DB 팽창)
• 기존 컬럼은 그대로 둔 채 새로운 이름의 공간을 추가합니다.
• 구버전 앱의 에러 방지를 위해 반드시 `Nullable`을 허용하거나 `Default` 값을 설정해야 합니다.
• 2단계: 양방향 쓰기 배포 (App 수정)
• 앱에서 데이터 저장 시 구 컬럼과 신 컬럼 양쪽에 동일한 데이터를 기록(`Dual Writing`)하도록 배포합니다.
• 3단계: 기존 데이터 백필 (DB 이관)
• 과거부터 쌓여있던 기존 데이터를 별도의 스크립트로 백그라운드에서 천천히 신규 컬럼으로 복사합니다.
• 테이블 Lock 방지를 위해 묶음 단위(Chunk)로 나누어 실행합니다.
• 4단계: 읽기 전환 배포 (App 수정)
• 데이터 동기화가 완료되면, 앱이 오직 신규 컬럼에서만 데이터를 읽고 쓰도록 코드를 전환하여 배포합니다.
• 5단계: 구 컬럼 삭제 (DB 수축)
• 안정화 기간을 거친 후 아무도 참조하지 않는 잉여 자원이 된 구버전 컬럼을 안전하게 삭제(`DROP`)합니다.

AI 마이그레이션 스크립트 리뷰 체크리스트

AI가 즉석에서 짜주는 최적화된 마이그레이션 코드는 종종 운영 안정성을 고려하지 못합니다. 리뷰(Review) 단계에서 사람이 직접 걸러내야 할 3가지 지뢰밭은 다음과 같습니다.

• 파괴적인 명령어 검출: 스크립트 내에 `DROP`, `RENAME`, `ALTER TYPE` 구문이 존재하는지 최우선으로 확인하고 우회 패턴을 지시합니다.
• 하위 호환성 위협 점검: 새로 추가되는 컬럼에 구버전 앱을 고장 낼 수 있는 가혹한 `NOT NULL` 제약조건이나 무리한 `UNIQUE` 제약이 추가되지 않았는지 살핍니다.
• 테이블 Lock 유발 여부: 인덱스 생성처럼 테이블 전체 쓰기 작업을 장시간 멈추게 하는 쿼리가 없는지 확인하고, 비동기 옵션(`CONCURRENTLY`) 사용을 강제합니다.