주문 이관을 여러 단계로 나눈 이유

플랫폼 전환을 준비하면서 과거 주문을 새 시스템으로 옮겨야 했습니다. 하지만 데이터를 읽어서 새 테이블에 넣는 작업만으로 끝나지 않았습니다. 주문과 결제·배송·반품이 연결돼 있었고, 이관을 준비하는 동안에도 새 주문과 상태 변경이 계속 발생했습니다.

그래서 사전에 옮길 수 있는 이력과 전환 시점까지 바뀌는 데이터를 나눠 처리했습니다.

주문 구조의 차이

기존 Breeze와 글로벌 플랫폼은 주문 데이터를 구성하는 방식이 달랐습니다. 주문에 속한 상품, 결제와 배송 정보를 새 구조에 맞게 변환해야 했습니다.

필드 이름이 비슷하더라도 의미가 같다고 볼 수는 없었습니다. 상태 코드가 나타내는 처리 단계와 금액의 기준을 확인해야 했습니다. 한 주문의 데이터가 모두 있어도 관계가 잘못 연결되면 정상적인 주문 이력으로 사용하기 어렵습니다.

이관 중에도 바뀌는 데이터

준비 기간에도 고객은 주문하고 반품을 신청했습니다. 사전 배치에서 데이터를 읽은 뒤 주문 상태가 바뀌면, 처음 옮긴 결과만으로는 전환 시점의 상태를 보여줄 수 없습니다.

새로 생성된 주문과 기존 주문의 변경을 구분해서 반영해야 했습니다. 배송과 반품이 진행 중인 주문은 이후 결과를 어느 시스템에서 처리할지도 함께 정해야 했습니다.

검증과 재실행 범위

변환 결과를 확인하려면 건수뿐 아니라 주문 금액과 상태, 상품·결제 정보의 연결도 봐야 했습니다. 처리 대상을 나눠 두면 문제가 생겼을 때 어떤 범위의 결과를 확인하고 다시 처리할지 정하기 수월했습니다.

재실행도 단순히 같은 배치를 한 번 더 돌리는 것으로 끝나지 않습니다. 앞선 실행에서 이미 반영한 데이터가 중복되지 않도록 처리 기준이 필요합니다. 새 플랫폼에서 변경된 주문을 이전 값으로 덮어쓰지 않는지도 함께 고려해야 합니다.

사전 배치와 당일 변경분 반영

후속 처리가 끝난 주문 이력부터 사전에 옮기고, 아직 바뀌는 주문과 마지막 변경분은 별도로 다뤘습니다. 전환 당일에 처리할 양을 줄이면서 변환과 검증을 미리 진행하기 위한 선택이었습니다.

이 방식에도 준비 기간 동안 두 시스템의 데이터와 처리 범위를 구분해야 하는 부담이 있었습니다. 당시에는 전체 이관과 검증을 당일에 몰기보다 이 부담을 나눠 관리하는 쪽을 선택했습니다.

다음 글에서는 반품과 배송 상태에 따른 이관 대상 구분을 더 구체적으로 설명합니다.