서비스를 유지하는 DB 변경: 확장·이관·검증·정리 절차

운영 데이터베이스의 컬럼을 바꾸는 작업은 테이블 정의만 수정하는 일보다 넓습니다. 구버전과 신버전 애플리케이션이 동시에 접근하고 배치와 보고서, 외부 연동도 같은 데이터를 사용할 수 있습니다. 한 번의 변경으로 모든 사용처가 즉시 전환된다고 가정하면 배포 순서와 복구에서 문제가 생길 수 있습니다.

이 글은 기존 구조를 유지하면서 새 구조를 추가하고 자료와 사용처를 옮긴 뒤 정리하는 확장·이관·축소 방식을 설명합니다. 중단이 절대 없다고 보장하는 절차가 아니라 호환성과 잠금, 데이터 검증과 복귀 조건을 단계별로 확인하는 실무 설계입니다. 실제 명령과 제약은 사용하는 DB와 버전에서 검증해야 합니다.

1. 변경의 업무 의미와 사용처를 찾는다

컬럼 이름만 달라지는지 자료형과 단위, 필수 여부와 의미까지 바뀌는지 구분합니다. 같은 데이터처럼 보여도 의미가 바뀌면 단순 복사로 이관할 수 없습니다. 변환 규칙과 처리할 수 없는 입력을 업무 담당자와 합의하고 원래 값의 보존 범위를 정합니다.

애플리케이션 외에 조회 배치와 보고서, 데이터 파이프라인과 외부 API를 확인합니다. 누가 해당 필드를 읽고 쓰는지와 배포 권한이 어디에 있는지 기록합니다. 직접 수정할 수 없는 소비자가 있다면 호환 기간과 전환 확인 방법을 별도로 계획해야 합니다.

목표 구조와 완료 조건을 문서화합니다. 새 컬럼이 생긴 것과 모든 자료가 올바르게 옮겨진 것, 구사용처가 사라진 것은 다른 상태입니다. 단계별 책임자와 중단 기준을 정하면 일정에 맞춰 위험한 정리를 먼저 하는 일을 피할 수 있습니다.

2. 구버전과 공존할 확장 단계를 설계한다

기존 읽기와 쓰기가 유지되는 범위에서 새 구조를 추가합니다. 새 컬럼이나 테이블, 호환 경로의 기본값과 제약이 구버전 요청에 어떤 영향을 주는지 확인합니다. 단순히 추가 작업이라는 이유로 잠금이나 조회 계획의 영향이 없다고 가정하지 않습니다.

변경 명령의 잠금과 수행 시간을 실제 조건에 가까운 환경에서 점검합니다. 데이터량과 인덱스, 장기 실행 트랜잭션이 영향을 줄 수 있습니다. 제품 문서의 동작을 확인하고 어느 단계가 대기 중인지와 언제 중단할지 운영자가 판단할 수 있게 합니다.

애플리케이션 배포 순서를 정합니다. 새 코드는 아직 이관되지 않은 자료와 공존할 수 있어야 하고 구코드가 새 구조 때문에 실패하지 않아야 합니다. 여러 버전이 동시에 쓰는 기간에 읽을 기준과 기록할 값을 명확히 정의합니다.

3. 쓰기 전환의 일관성을 확인한다

새 자료가 계속 들어오는 동안 과거 자료만 옮기면 이후 값이 어긋날 수 있습니다. 어떤 시점부터 어떤 경로가 새 구조에 기록할지 정하고 구사용처의 쓰기도 반영할 방법을 검토합니다. 두 곳을 기록한다면 같은 트랜잭션 범위와 실패 동작을 확인합니다.

동기화 로직의 책임은 한 곳에서 이해할 수 있어야 합니다. 여러 서비스가 각자 변환하면 같은 입력도 다르게 기록될 수 있습니다. 원래 값과 새 값의 관계를 검증하고 변환할 수 없는 경우를 임의의 기본값으로 감추지 않습니다.

쓰기에 실패했을 때 어떤 상태가 남는지도 시험합니다. 새 구조 반영이 실패했는데 기존 저장만 성공하는 경우와 반대의 경우를 검토합니다. 자동 복구와 확인 대기, 재시도 범위를 정해 같은 거래가 반복 생성되거나 변경이 유실되지 않게 합니다.

4. 기존 자료는 작은 범위로 나눠 이관한다

이관 작업의 대상과 진행 위치, 실패와 완료 상태를 기록합니다. 전체 테이블을 한 번에 처리하면 잠금과 자원 사용, 복구 부담이 커질 수 있습니다. 처리 크기와 속도는 실제 부하를 관찰하며 조정하고 중단 후 이어갈 수 있게 합니다.

동시 수정과의 충돌을 다룹니다. 이관기가 예전 값을 읽은 뒤 사용자가 새 값을 저장했다면 오래된 변환으로 최신 값을 덮어쓰지 않도록 조건을 검토합니다. 단순히 행 번호까지 처리했다는 기록만으로 모든 변경이 반영됐다고 판단하지 않습니다.

같은 구간을 다시 처리해도 결과가 일관돼야 합니다. 대상 선정과 변환 버전, 처리 완료 판단을 명확히 정하고 일부 실패를 다시 실행할 방법을 둡니다. 원문 값을 보존할 필요와 임시 자료의 접근·정리 기준도 이관 설계에 포함합니다.

5. 건수와 업무 의미를 함께 검증한다

행 수가 같다는 사실만으로 이관이 정확하다고 볼 수 없습니다. 누락과 중복, 빈 값과 변환 오류, 참조 관계와 집계 결과를 확인합니다. 업무 규칙에 맞는 대표 표본을 골라 원래 값과 새 값을 직접 대조할 수 있어야 합니다.

범위별 검증을 수행합니다. 오래된 자료와 최근 수정 자료, 예외 형식과 중요한 고객 구간을 함께 봅니다. 전체 평균에서는 작은 차이여도 특정 유형이 모두 잘못 변환됐을 수 있습니다. 확인되지 않은 조건과 검증 자료의 한계를 표시합니다.

읽기 결과 비교가 필요하면 기존 경로와 새 경로의 응답을 같은 요청 조건에서 대조합니다. 시간대와 정렬, 제외 조건이 달라 비교가 왜곡되지 않게 합니다. 차이를 발견하면 데이터와 변환, 조회 구현 중 어디에서 생겼는지 분류해 조치합니다.

6. 읽기 경로를 단계적으로 전환한다

검증된 범위부터 새 구조를 읽게 하고 오류와 지연, 기존 경로와의 차이를 관찰합니다. 전환 대상과 적용 버전을 식별할 수 있어야 합니다. 표본 비교와 실제 사용자 문의를 통해 코드상 성공했지만 업무상 다른 결과가 나오는 사례를 찾습니다.

문제가 생겼을 때 읽기 경로를 되돌릴 수 있는지 확인합니다. 그동안 새 구조에만 쓴 값이 있다면 이전 코드가 이해할 수 있는지 검토해야 합니다. 설정 하나를 되돌리는 것과 데이터의 호환성을 되돌리는 것은 다른 문제이므로 복귀 범위를 명시합니다.

외부 소비자와 배치의 전환도 별도로 확인합니다. 온라인 화면이 정상이라고 야간 작업과 보고서까지 전환됐다고 가정하지 않습니다. 실행 주기와 사용 기록을 근거로 구구조를 더 이상 쓰지 않는다는 확인을 받아 다음 단계로 넘어갑니다.

7. 구구조 정리는 별도 승인으로 수행한다

컬럼과 호환 경로를 없애기 전에 남은 읽기와 쓰기를 확인합니다. 휴면 작업과 드물게 실행되는 관리 기능이 있을 수 있습니다. 문서상 전환 완료와 실제 사용 기록을 함께 검토하고 책임자가 정리 범위를 승인하게 합니다.

삭제는 되돌리기 어려운 변경일 수 있으므로 백업과 복구 방법을 확인합니다. 파일이 존재한다는 기록보다 필요한 자료와 설정을 복원할 수 있는지 시험해야 합니다. 원래 값 보관과 접근 권한, 조직의 보존 기준을 정리 계획과 연결합니다.

정리 명령도 부하와 잠금 영향을 검토합니다. 확장 단계에서 안전했던 작업이 삭제 단계에서도 같은 동작을 보장하지는 않습니다. 중단 기준과 담당자, 영향받는 서비스의 연락 경로를 지정하고 실행 후 오류와 남은 참조를 확인합니다.

8. 변경 기록을 다음 배포의 기준으로 남긴다

운영 기록에는 구조 버전과 애플리케이션 버전, 변환 규칙과 검증 결과를 연결합니다. 어느 단계까지 끝났고 어떤 호환 경로가 남았는지 확인할 수 있어야 합니다. 임시 동기화 코드가 무기한 남지 않도록 종료 조건과 정리 책임자를 정합니다.

이관 중 발견한 예외 자료와 긴 잠금, 느린 조회를 회귀 사례로 보관합니다. 다음 변경에서 같은 조건을 미리 점검할 수 있도록 표본과 실행 절차를 정리합니다. 성능 개선과 의미 변경을 함께 수행했다면 각각의 영향을 구분해 설명합니다.

확장·이관·축소는 명령의 순서만이 아니라 공존 기간의 계약입니다. 구사용처와 새사용처가 무엇을 읽고 쓰는지, 데이터가 어떻게 검증됐는지와 언제 복귀할 수 있는지를 함께 관리해야 합니다. 그 근거가 있어야 서비스를 운영하면서 변경의 위험을 단계적으로 판단할 수 있습니다.

9. 기존 이름과 새 이름의 필드가 공존하는 배포를 시험한다

업무 필드의 이름과 표현을 바꾸기 위해 새 컬럼을 추가하는 상황을 가정합니다. 구버전 서버가 계속 요청을 받는 동안 신버전도 배포된다고 정합니다. 시험에서는 각 버전이 어떤 값을 읽고 쓰는지 표로 정리하고, 새 컬럼이 비어 있는 기존 자료에서도 정상적으로 동작하는지 확인합니다.

쓰기 호환을 준비한 뒤 일부 과거 자료를 이관합니다. 이관기가 값을 읽은 직후 사용자가 같은 행을 수정하는 상황을 넣어 최신 값이 과거 변환으로 덮이지 않는지 검사합니다. 진행 위치와 실패 기록이 남아야 하며 중단 뒤 같은 구간을 다시 처리해도 중복 자료나 다른 결과가 만들어지지 않아야 합니다.

검증에서는 행 수와 빈 값뿐 아니라 업무상 같은 의미인지 대조합니다. 예외 표기와 최근 수정 자료, 자주 사용하지 않는 고객 구간을 포함합니다. 기존 조회와 새 조회의 필터·정렬·시간 조건을 맞춘 뒤 결과를 비교하고 차이가 자료 변환 때문인지 조회 구현 때문인지 분류합니다. 확인되지 않은 조건은 전환 완료로 표시하지 않습니다.

읽기를 일부 전환한 상태에서 이전 경로로 복귀하는 시험을 수행합니다. 새 구조에 기록된 값이 구버전에서도 해석 가능한지와 대기 중인 배치가 어떤 구조를 사용하는지 확인합니다. 온라인 화면만 정상이라는 이유로 구컬럼을 삭제하지 않고 보고서와 외부 소비자의 전환을 별도로 확인해야 합니다.

마지막으로 구구조 정리 승인을 연습합니다. 실제 사용 기록과 책임자의 확인, 복구 시험 결과를 대조하고 남은 호환 코드와 임시 자료를 목록으로 만듭니다. 정리 전후의 잠금과 오류를 확인할 담당자를 지정합니다. 이 연습의 종료 조건은 새 컬럼의 존재가 아니라 데이터와 모든 사용처의 상태를 설명하고 남은 위험을 판단할 수 있는 것입니다.

적용 전 체크리스트

• 의미 변경과 모든 읽기·쓰기 사용처를 확인했는가
• 구·신버전 공존과 잠금 영향을 검증하는가
• 이관 재시도와 동시 수정 충돌을 다루는가
• 자료 의미·범위별 결과와 소비자 전환을 대조하는가
• 복귀·백업·구구조 정리에 별도 승인 기준이 있는가

참고 자료와 적용 범위

• Danilo Sato — Parallel Change
• PostgreSQL — ALTER TABLE

확장·이관·축소 패턴과 변경 잠금의 배경은 원저자·공식 문서를 참고했습니다. 실제 동작은 DB와 버전별로 확인해야 하며 운영 절차는 설계 제안입니다.

대표 이미지는 AI로 제작한 개념 시각화이며, 본문 도식과 함께 이해를 돕기 위한 자료입니다. 실제 고객의 설비·데이터·서비스 화면을 나타내지 않습니다.

#DB마이그레이션 #확장이관축소 #스키마변경 #하위호환 #데이터검증 #백필 #동시성 #배포운영 #데이터일관성 #네이처프랙탈