주문 마이그레이션에서 가장 먼저 정의해야 했던 데이터 경계

대규모 플랫폼 마이그레이션에서 가장 먼저 답해야 할 질문은 ‘무엇을 옮기고, 무엇을 남길 것인가’다. 모든 데이터를 옮기면 좋겠지만, 수년간 축적된 수백만 건의 주문 데이터를 새로운 스키마로 전부 변환하는 것은 기술적으로도, 운영적으로도 비현실적이다. 이 글은 Nike 마이그레이션에서 주문 데이터의 경계를 어떻게 정의했는지, 그 기준이 왜 단순한 날짜가 아니라 주문의 ‘상태’에 의존해야 했는지를 기록한다.

데이터 경계 정의는 마이그레이션의 모든 후속 작업 — 배치 설계, 정합성 검증, BLOHA 구축, CS 운영 방안 — 의 출발점이 된다. 경계가 모호하면 모든 후속 작업이 흔들린다. 이 글은 그 출발점에서의 판단 과정을 기록한다.

Nike의 Breeze 시스템에는 약 천만 명의 사용자와 수년간의 주문 데이터가 축적되어 있었다. 글로벌 플랫폼으로 전환할 때, 이 모든 주문을 새 플랫폼의 데이터 구조로 변환하여 옮기는 것은 여러 이유로 불가능했다. 스키마가 근본적으로 다르고, 변환 과정에서 데이터 손실이나 변형의 위험이 있으며, 전환 기간 동안 라이브 운영을 멈출 수 없다.

따라서 ‘경계’를 정의해야 했다. 어떤 주문은 반드시 새 플랫폼에서 접근 가능해야 하고, 어떤 주문은 레거시 시스템에서 조회만 가능하면 충분하다. 이 구분의 핵심 기준은 ‘주문이 아직 활성 상태인가’ — 즉, 반품이나 교환 등의 후속 조치가 가능한 상태인가 — 였다.

활성 주문 vs 이력 주문

주문을 두 범주로 나누었다. 활성 주문(Active Orders)은 반품 가능 기간 내에 있거나, 배송 중이거나, 교환이 진행 중인 주문이다. 이 주문들은 새 플랫폼에서 완전한 기능(조회, 반품 요청, 배송 추적)이 작동해야 한다. 이력 주문(Historical Orders)은 반품 기간이 지났고, 모든 처리가 완료된 주문이다. 이 주문들은 조회만 가능하면 충분하다.

이 구분이 중요한 이유는 마이그레이션 전략이 완전히 달라지기 때문이다. 활성 주문은 새 플랫폼의 주문 시스템에 실제로 데이터를 넣어야 한다 — 반품 처리, 배송 상태 업데이트 등의 트랜잭션이 새 플랫폼에서 발생해야 하므로. 이력 주문은 읽기 전용 API(BLOHA)를 통해 제공하면 된다 — 데이터를 글로벌 주문 시스템에 넣을 필요가 없다.

경계 판정 기준 요약

날짜가 아닌 상태 기반 경계

처음에는 ‘특정 날짜 이후의 주문만 옮기자’는 접근이 직관적으로 보였다. 예를 들어 ‘최근 6개월 주문만 마이그레이션’하는 식이다. 그러나 이 접근은 주문의 상태를 고려하지 않는다. 8개월 전 주문이지만 아직 반품 처리가 진행 중인 경우가 있을 수 있고, 반대로 2주 전 주문이지만 이미 수령 확인이 완료되어 활성 조치가 불가능한 경우도 있다.

경계는 날짜가 아니라 주문의 상태에 의존해야 했다. 구체적으로는 다음 상태들을 고려했다: 배송 완료(delivered) → 반품 가능 기간(7일) 경과 여부, 반품 진행 중(return in progress), 교환 진행 중(exchange in progress), 배송 중(in transit), 주문 확인 대기(pending confirmation). 상태가 ‘최종 완료(closed)‘인 주문만 이력 주문으로 분류하고, 나머지는 모두 활성 주문으로 간주했다.

경계 정의의 실무적 어려움

이론적으로는 깔끔하지만, 실제 데이터에는 예외가 가득했다. Breeze의 주문 상태 코드는 수십 가지가 있었고, 일부 상태는 문서화되지 않은 레거시 코드였다. ‘부분 반품’이 진행 중인 주문은 어떤 범주에 넣어야 하는가? 하나의 주문에 여러 상품이 포함된 경우, 일부 상품만 반품된 주문의 상태는 무엇인가?

또한 Breeze의 주문 상태가 글로벌 플랫폼의 주문 상태와 1:1로 매핑되지 않는 문제가 있었다. Breeze에서는 ‘결제 확인 대기(payment pending)‘라는 상태가 있지만, 글로벌 플랫폼에서는 이 상태가 존재하지 않을 수 있다. 상태 매핑 테이블을 만들어야 했고, 매핑할 수 없는 상태의 주문은 별도로 처리해야 했다.

경계가 후속 작업에 미치는 영향

데이터 경계가 정의되면, 이후 모든 작업이 이 경계를 기준으로 설계된다. 마이그레이션 배치는 활성 주문만을 대상으로 변환 로직을 구현한다. BLOHA는 이력 주문을 서빙하기 위한 읽기 전용 API로 설계된다. CS 운영 매뉴얼은 ‘이 주문은 어느 시스템에서 처리해야 하는가’를 판단하는 기준으로 이 경계를 사용한다.

경계가 잘못 정의되면 연쇄적 문제가 발생한다. 활성 주문이 이력으로 잘못 분류되면 고객이 반품을 할 수 없고, 이력 주문이 활성으로 잘못 분류되면 불필요한 데이터 변환 비용이 발생한다. 이 경계의 정확성은 마이그레이션 성공의 전제 조건이다.

글로벌 전환은 단순한 데이터 이동이 아니라 경계와 책임을 다시 정의하는 작업이었다는 점이 이 시리즈의 중심에 있다. 다음 글에서는 2021 - 왜 주문 데이터는 한 번에 전부 옮길 수 없었나를 통해 이 흐름을 계속 좁혀 본다.

경계 설계의 기술적 의미

상태 기반 경계의 장점은 운영 의도를 데이터 규칙으로 고정할 수 있다는 점이다. 날짜 기준처럼 단순해 보이는 규칙은 예외 주문을 놓치기 쉽지만, 상태 기준은 반품·교환·배송 같은 실제 업무 흐름을 더 정확하게 반영한다.

단점은 상태 매핑 테이블과 예외 처리 로직이 복잡해진다는 점이다. 그러나 이 복잡도는 마이그레이션 이후 고객 영향과 수동 보정 비용을 줄이는 데 직접 기여한다. 전환기 데이터 경계는 “단순성”보다 “정확성”이 우선이었다.

데이터 경계 정의 체크포인트

• 이관 대상은 법적 보관 기간, 반품 가능 기간, 운영 참조 빈도로 분리했다.
• 주문 상태는 원천 코드 보존 + 표준 코드 매핑의 이중 구조로 관리했다.
• 경계 밖 데이터는 별도 조회 경로(BLOHA)로 분리해 컷오버 리스크를 낮췄다.

경계 설계 대안 비교