운영 중인 DB의 문자열 상태를 새 코드 컬럼으로 옮기려 합니다. 구버전 서버가 남아 있고 쓰기가 계속될 때 어떻게 전환하나요?

운영 중 스키마 변경은 구버전과 신버전 서버가 같은 DB를 잠시 함께 사용한다는 전제로 설계해야 합니다. 문자열 status를 코드 컬럼으로 바꾼다면 새 컬럼 추가, 양쪽 버전의 읽기·쓰기 호환, 기존 행 백필, 읽기 전환, 불일치 검증, 이전 컬럼 제거를 분리하겠습니다. 코드와 컬럼을 한 번에 바꾸면 배포 순서나 롤백 순간에 구버전이 새 컬럼을 모르거나 신버전이 아직 채워지지 않은 값을 읽게 됩니다.

expand와 backfill을 동시 쓰기와 함께 설계합니다

paid를 status_code=2로 옮긴다고 할 때 먼저 새 컬럼을 nullable로 추가하고, 신버전은 기존 컬럼을 읽을 수 있어야 합니다. 신버전 쓰기가 두 컬럼을 함께 기록한다면 두 값의 매핑을 하나의 트랜잭션·제약·코드 모듈에서 관리합니다. 기존 행을 채우는 백필은 작은 배치와 재시작 키를 사용하겠습니다. 백필이 paid를 읽은 뒤 실제 요청이 cancelled로 바꾸었는데 백필이 무조건 2를 덮어쓰면 최신 상태를 잃습니다. 현재 값을 조건에 포함하거나 버전·updated_at을 비교해 충돌 행을 다시 처리해야 합니다.

PostgreSQL, MySQL, SQL Server의 DDL 잠금·온라인 인덱스·메타데이터 변경 범위는 다르고, 같은 ‘online’이라는 옵션도 시작·마무리 시 잠금과 로그·복제 부하를 없애지 않습니다. 대규모 테이블에서는 기본값·NOT NULL 추가가 기존 행을 실제로 다시 쓰는지, 메타데이터만 바꾸는지 버전별로 확인하고 사본에서 먼저 측정합니다. 백필은 DB CPU·I/O·로그·복제 지연을 함께 보며 서비스 트래픽의 상한을 넘지 않게 조절합니다.

읽기 전환 후에 수축합니다

새 컬럼을 읽는 비율을 단계적으로 늘리고, 두 표현을 함께 계산해 불일치 수와 원인을 관찰하겠습니다. 구버전 서버가 남아 있다면 그 서버가 새 컬럼을 무시해도 신버전의 기대를 깨지 않는지, 구버전 쓰기가 이전 컬럼만 바꿔도 동기화 경로가 있는지 확인해야 합니다. 데이터가 역사적 의미를 갖는다면 단순 코드 매핑이 아니라 당시 상태의 의미가 보존되는지 검토합니다.

전환 직후 이전 컬럼을 삭제하지 않습니다. 모든 쓰기 경로와 배치·관리 스크립트가 더 이상 이를 사용하지 않고, 복구 시점에도 구버전이 읽을 데이터가 필요한지 확인한 뒤 별도 배포에서 제거합니다. 롤백도 코드 되돌리기와 이미 진행된 데이터 변환 되돌리기가 다릅니다. 검증 기준은 배포 성공 메시지가 아니라 혼합 버전에서 읽기·쓰기가 안전하고, 백필이 재실행 가능하며, 불일치를 재현·복구할 수 있고, DDL과 백필이 허용된 지연·로그 예산 안에 있는지입니다.

전환 중에는 새 코드가 새 컬럼을 우선 읽더라도 누락 행에 대한 명확한 fallback을 둬야 합니다. fallback이 조용히 오래된 컬럼을 계속 사용하면 백필 누락을 숨길 수 있으므로 누락 수를 지표로 남기고 임계치를 넘으면 전환을 멈추겠습니다. 두 컬럼의 값이 다른 행을 단순히 최신 updated_at으로 덮지 말고 누가 어떤 버전에서 썼는지 조사합니다. 제거 단계의 사전 검사는 애플리케이션뿐 아니라 배치·관리 SQL·ETL까지 포함해야 합니다.