DB 스키마 변경: 추가·이행·전환·정리 순서
이름 필드 분리를 예로 구버전 호환, 백필 재실행, 롤백 경계를 설계합니다.
DB 컬럼을 바꾸는 배포는 새 코드가 성공했는지만 확인해서는 부족합니다. 배포 중 구버전과 신버전이 동시에 실행될 수 있고, 일부 데이터만 이전된 상태가 생길 수 있습니다. 변경을 추가·이행·전환·정리로 나누면 되돌릴 수 있는 지점을 구분하기 쉽습니다.
예제: 이름 필드를 분리한다면
기존 display_name에서 새로운 given_name, family_name을 만들려 한다고 가정합니다. 이름은 언어와 문화에 따라 구조가 다르므로 공백 기준으로 기계적으로 분리해서는 안 됩니다. 이 예제에서는 새 필드를 선택적으로 입력받고 기존 표시 이름을 유지하는 것으로 범위를 정합니다.
- 새 필드를 추가하되 구버전 코드가 계속 동작하게 합니다.
- 새 코드에서 필요한 경우 새 필드에 쓰고, 기존 표시 경로도 유지합니다.
- 검증 가능한 데이터만 작은 배치로 이전합니다.
- 읽기 경로를 전환하고 누락을 관찰합니다.
- 구버전과 외부 사용자가 더 이상 쓰지 않는 것을 확인한 뒤 정리합니다.
백필은 다시 실행할 수 있어야 한다
이전 작업이 중간에 실패하면 처음부터 전체 데이터를 덮어쓰지 않고 이어갈 수 있어야 합니다. 처리 위치나 상태를 기록하고 이미 사용자가 수정한 값을 덮어쓰지 않는 조건을 둡니다.
배치 시작 ID 확인
→ 아직 이전되지 않은 행 선택
→ 변환 가능한지 검사
→ 결과 저장과 처리 상태 갱신
→ 처리 수·실패 수 기록
이는 절차 예제이며 실제 SQL은 스키마와 동시 쓰기 조건에 따라 달라집니다. 원본과 변환 결과를 샘플로 비교하고 전체 행 수, 누락 수, 중복 수를 확인합니다.
잠금과 롤백의 경계
컬럼 추가나 제약 변경이 얼마나 오래 잠금을 잡는지는 DB 버전과 작업 종류에 따라 다릅니다. 운영과 비슷한 데이터 규모의 격리 환경에서 확인합니다. 테이블이 작을 때 빠르다는 결과만으로 운영 작업 시간을 예상하지 않습니다.
새 컬럼을 읽기 시작한 뒤 앱만 구버전으로 되돌리면 데이터 의미가 달라질 수 있습니다. ‘코드 롤백 가능’과 ‘데이터 되돌리기 가능’을 나누고, 파괴적인 컬럼 삭제는 호환 기간이 끝난 뒤 진행합니다.
완료 기준
오래된 코드 경로가 남지 않았는지, 새 데이터가 누락 없이 생성되는지, 백업에서 필요한 상태를 복구할 수 있는지 확인합니다. 복구 리허설을 마이그레이션과 별개의 작업으로 미루지 않는 편이 좋습니다.