반품 기간과 운영 상태를 고려한 점진적 주문 이관 전략
앞 편에서 주문 데이터를 한 번에 옮길 수 없는 이유를 설명했다면, 이 글은 실제로 어떤 전략으로 점진적 이관을 설계했는지를 기록한다. 핵심은 한국 소비자보호법의 7일 반품 기간과 주문의 운영 상태를 기준으로 이관 우선순위를 결정한 것이다.
단순히 ‘오래된 것부터 옮기자’가 아니라, ‘반품이 불가능해진 주문부터 옮기되, 반품 가능 기간 내의 주문은 컷오버 직전까지 양쪽 시스템에서 모두 접근 가능하게 유지하자’는 전략이다. 이 전략은 고객 경험과 법적 요건을 동시에 만족시키면서, 기술적 리스크를 단계별로 관리할 수 있게 해주었다.
한국 소비자보호법은 온라인 구매 상품에 대해 수령 후 7일 이내 반품을 보장한다. 이 반품 기간은 마이그레이션에서 핵심적인 제약 조건이 된다. 반품 가능 기간 내의 주문은 반품 요청 접수, 반품 배송 추적, 환불 처리 등 완전한 트랜잭션 기능이 필요하다. 읽기 전용으로는 부족하다.
또한 주문의 운영 상태(operational status)는 단순하지 않다. ‘배송 완료 + 반품 기간 내’인 주문 외에도, ‘배송 중’, ‘부분 배송(여러 상품 중 일부만 배송)’, ‘교환 진행 중’, ‘반품 접수 후 물류 반송 대기’ 등 다양한 중간 상태가 존재한다. 이 각각의 상태에 대해 마이그레이션 시점에 어떻게 처리할지를 정의해야 했다.
상태별 이관 전략
주문 상태를 크게 세 범주로 나누고, 각 범주에 대해 이관 전략을 정의했다. 첫째, 완전 종료(fully closed) 주문: 배송 완료, 반품 기간 경과, 모든 후속 처리 완료. 이 주문들은 배치 마이그레이션의 주 대상이다. 가장 먼저, 가장 많은 양을 옮긴다. 데이터 변환만 하면 되고, 운영 로직은 필요 없다.
둘째, 반품 가능 기간 내(within return window) 주문: 배송은 완료되었지만 반품 가능 기간(7일)이 아직 남아 있다. 이 주문들은 컷오버 직전에 마이그레이션하되, 전환 기간 동안에는 Breeze 시스템에서도 반품 처리가 가능하도록 유지해야 한다.
셋째, 진행 중(in-progress) 주문: 배송 중, 교환 진행 중, 반품 반송 대기 등 아직 처리가 완료되지 않은 주문. 이 주문들은 가장 까다로운 케이스다. 컷오버 시점에 상태를 정확히 파악하고, 새 플랫폼에서 해당 상태부터 이어서 처리할 수 있도록 데이터를 구성해야 한다.
점진 이관 실행 순서
종료 주문 선이관
완전 종료 주문을 먼저 배치 이관해 전체 데이터 볼륨과 리스크를 초기에 줄였다.
반품 가능 주문 이중 운영
반품 가능 기간 내 주문은 양쪽 시스템에서 모두 처리 가능하도록 유지해 고객/CS 단절을 막았다.
진행 중 주문 최소화
컷오버 직전까지 진행 중 주문 수를 줄이고, 남은 주문만 스냅샷 이관 대상으로 묶었다.
컷오버 당일 델타 정리
최종 델타를 이관한 뒤 건수/금액/상태를 재검증하고 전환을 확정했다.
배치 마이그레이션: 완전 종료 주문
완전 종료 주문의 배치 마이그레이션은 컷오버 수 주 전부터 시작되었다. Breeze 관계형 DB에서 추출(Extract) → 변환(Transform) → 글로벌 플랫폼에 적재(Load)하는 ETL 프로세스를 구현했다. 대량 데이터를 처리하기 위해 배치를 날짜 범위나 주문 ID 범위로 분할하여 병렬 실행했다.
각 배치 실행 후에는 정합성 검증을 수행했다. 원본과 변환 결과의 행 수 비교, 금액 합계 비교, 상태 매핑 검증 등이다. 문제가 발견되면 해당 배치만 재실행하면 되므로, 리스크가 해당 범위에 한정된다.
반품 기간 내 주문의 이중 운영
반품 가능 기간 내의 주문은 전환 기간 동안 두 시스템에서 모두 접근 가능해야 했다. 고객이 반품을 요청하면 어느 시스템에서든 처리할 수 있어야 하기 때문이다. 이를 위해 이 주문들의 데이터를 새 플랫폼에 마이그레이션하되, Breeze에서의 반품 처리 기능도 일정 기간 유지했다.
이중 운영 기간은 반품 가능 기간(최소 7일)을 기준으로 설계했다. 이 기간 동안 어느 시스템에서 반품이 접수되더라도 양쪽 상태가 일관되게 동기화되어야 했고, 이 지점이 가장 복잡한 구현 구간이었다.
진행 중 주문: 컷오버 시점의 스냅샷
배송 중이거나 교환/반품이 진행 중인 주문은 컷오버 시점에 현재 상태를 스냅샷으로 캡처하여 새 플랫폼에 적재했다. 문제는 이 주문들의 후속 처리가 Breeze의 물류 시스템, PG사 연동, CS 도구와 연결되어 있다는 점이다. 단순히 데이터만 옮기면 배송 추적이 끊기고, 반품 환불이 처리되지 않는다.
이를 해결하기 위해 컷오버 직전에 가능한 한 많은 진행 중 주문을 완료 상태로 만들었다. 예를 들어 배송 중인 주문은 배송이 완료될 때까지 기다리고, 반품 반송 대기 주문은 반송이 완료될 때까지 기다려서, 컷오버 시점에 진행 중인 주문의 수를 최소화하는 전략을 취했다.
상태별 운영 부담 요약
| 주문 상태 | 처리 전략 | 운영 부담 |
|---|---|---|
| 완전 종료 주문 | 사전 배치 이관 | 낮음 (재실행 범위 제한 가능) |
| 반품 가능 기간 내 주문 | 이중 운영 + 상태 동기화 | 높음 (정산/환불 충돌 관리 필요) |
| 진행 중 주문 | 컷오버 직전 스냅샷 이관 | 매우 높음 (연동/상태 일관성 검증 필요) |

글로벌 전환은 단순한 데이터 이동이 아니라 경계와 책임을 다시 정의하는 작업이었다는 점이 이 시리즈의 중심에 있다. 다음 글에서는 2021 - 기존 계정과 글로벌 계정을 공유 식별자로 연결해야 했던 이유를 통해 이 흐름을 계속 좁혀 본다.
아키텍처 관점의 장단점
점진 이관의 장점은 실패 범위를 통제할 수 있다는 점이다. 배치 단위로 전환하면 오류가 발생해도 해당 구간만 재처리하면 되고, 고객 영향도 국소화할 수 있다. 반면 단점은 이중 운영 기간 동안 동기화 경로가 늘어나면서 운영 복잡도와 모니터링 포인트가 크게 증가한다는 점이다.
결국 이 전략은 “단기 복잡도 증가”를 감수하고 “전체 전환 리스크를 분산”하는 선택이었다. 컷오버 한 번에 모든 리스크를 집중시키는 대신, 기간을 나눠 리스크를 관리 가능한 단위로 쪼개는 것이 당시 운영 목표에 더 맞았다.
기술 체크포인트
- 이관 배치는 주문 상태(
완료/활성/예외)별로 분리해 실패 반경을 제한했다. - 반품 기간이 남은 주문은 별도 처리 큐로 분리해 정산/환불 충돌을 방지했다.
- 배치별 검증 결과를 남겨 재실행 기준과 롤백 기준을 명확히 유지했다.