반품과 배송 상태를 고려한 주문 이관

주문 데이터를 옮길 때는 오래된 주문부터 처리하면 될 것 같았습니다. 하지만 주문일만으로는 지금도 처리 중인 주문인지 알 수 없습니다. 오래전에 주문했어도 반품이나 환불이 남아 있을 수 있고, 배송이 끝나도 반품 접수가 가능할 수 있습니다.

그래서 이관 대상을 나눌 때 주문의 날짜와 운영 상태를 함께 봤습니다. 데이터를 새 시스템에 보여주는 것과 남은 업무를 이어서 처리하는 것은 준비할 내용이 달랐습니다.

이관과 조회의 범위

먼저 주문을 새 시스템으로 옮겨야 하는 이유와, 이전 시스템에서 조회를 유지해야 하는 이유를 나눴습니다. 이후 처리에 필요한 데이터의 이관과 과거 이력을 제공하는 일은 대상과 검증 기준이 달랐습니다.

오래된 주문을 모두 남기고 최근 주문을 모두 옮긴다는 규칙만으로는 부족했습니다. 날짜로 대상을 좁히더라도 배송·반품·환불이 남아 있는지 함께 확인해야 했습니다. 이관 대상에서 빠진 주문은 어느 경로에서 조회하고 처리할지도 정해야 했습니다.

처리가 끝난 주문부터 이관

배송과 후속 처리가 끝난 주문은 과거 이력을 조회할 수 있도록 옮기는 데 집중할 수 있었습니다. 이후에도 상태가 바뀌는 주문보다 먼저 처리하기 수월한 대상이었습니다.

그렇다고 종료 상태라는 이유로 검증이 필요 없는 것은 아닙니다. 주문과 상품, 결제 정보가 올바르게 연결됐는지와 금액·상태가 맞는지는 이관 후에도 확인해야 합니다. 다만 계속 바뀌는 데이터를 추적하는 부담을 줄일 수 있습니다.

반품이 가능한 주문의 처리 경로

배송 완료와 모든 업무의 종료는 같지 않았습니다. 반품을 접수할 수 있는 주문이라면 고객센터 조회, 반품 배송 확인, 환불 처리까지 이어져야 했습니다.

이때 중요한 것은 새 플랫폼에서 과거 주문이 보이는지뿐 아니라, 반품 요청을 어느 시스템이 받아 처리하는지였습니다. 두 시스템에서 조회할 수 있다고 해서 양쪽이 같은 주문을 독립적으로 수정해도 되는 것은 아닙니다. 접수와 상태 변경, 환불을 담당하는 경로를 구분해야 중복 처리나 누락을 줄일 수 있습니다.

반품 가능 여부도 단순히 주문일에서 일정 기간이 지났는지만으로 판단하기 어려웠습니다. 서비스 정책과 해당 주문의 배송·반품 상태를 기준으로 봐야 했습니다.

배송·반품이 진행 중인 주문

배송 중이거나 반품을 접수한 주문은 데이터만 복사해서 끝낼 수 없었습니다. 기존 물류 연동과 결제 처리, CS 도구가 남은 업무를 이어서 수행해야 했기 때문입니다.

이런 주문은 이관 시점의 상태와 이후 상태 변경을 어디서 처리할지 함께 확인해야 했습니다. 예를 들어 반품 접수 정보만 옮기고 반송 완료 결과를 받는 경로를 놓치면 환불 단계로 넘어가지 못할 수 있습니다.

이관 대상과 검증 기준

주문의 상태를 나눠 보면 확인할 내용도 달라집니다.

점진적으로 옮기는 동안에는 배치가 처리한 범위와 아직 남아 있는 주문을 구분해야 했습니다. 이관 완료 목록과 실제 운영 대상이 다르면, 문제가 생겼을 때 어느 쪽 데이터를 확인해야 하는지도 모호해집니다.

다음 글에서는 과거 주문이 해당 고객의 계정으로 조회되도록 기존 계정과 글로벌 계정을 연결한 방식을 다룹니다.