BLOHA로 유지한 과거 주문 조회
글로벌 플랫폼으로 전환한 뒤에도 Breeze에서 생성된 주문을 조회할 수 있어야 했습니다. 고객이 이전 주문을 확인하고, CS 담당자가 문의에 대응할 때 필요한 정보였기 때문입니다.
이 역할을 맡은 서비스가 BLOHA였습니다. 새 플랫폼의 주문과 기존 주문의 조회 경로를 연결해, 과거 주문을 모두 새 주문 시스템으로 옮기지 않아도 이력을 확인할 수 있게 했습니다.
이력 조회를 남긴 이유
주문 이관에서는 이후 처리가 필요한 데이터와 과거 조회를 위한 데이터를 함께 고려했습니다. 기존 주문을 모두 새 구조로 변환하면 검증할 대상도 늘어납니다. 그렇다고 기존 플랫폼의 기능을 전부 유지할 필요도 없었습니다.
BLOHA는 과거 주문의 조회 기능을 별도로 유지하는 선택이었습니다. 조회 API가 있다고 해서 원본 데이터의 보존이나 장애 복구까지 자동으로 해결되는 것은 아닙니다. 필요한 데이터와 접근 경로, 백업과 운영 관리가 함께 남아 있어야 합니다.
거래 기록의 보존과 서비스 수명
과거 거래 기록은 법에서 정한 기간 동안 보관해야 합니다. 전자상거래법 시행령 제6조는 계약·청약철회와 대금결제·재화 공급에 관한 기록의 보존 기간을 각각 5년으로 정하고 있습니다. 모든 종류의 기록에 같은 기간이 적용되는 것은 아닙니다.
이 기록의 보존 기간과 특정 API를 같은 구성으로 운영할 기간도 같지는 않습니다. 컷오버 날짜에 일괄적으로 5년을 더해 서비스 종료일을 정할 수는 없습니다. 어떤 기록을 언제까지 보존·열람할 수 있어야 하는지 확인하고, 대체 조회 경로가 준비됐는지도 함께 판단해야 합니다.
글로벌 계정과 기존 주문의 연결
전환 뒤에는 글로벌 계정으로 로그인하므로 기존 Breeze 계정의 주문을 찾을 연결 정보가 필요했습니다. 계정 연결 키를 기준으로 기존 계정과 주문을 조회하는 방식입니다.
인증된 사용자와 조회할 계정의 관계를 확인하는 일도 중요합니다. 클라이언트가 보낸 식별자만 믿고 다른 사용자의 주문을 조회할 수 있게 해서는 안 됩니다. 계정 매핑이 빠진 경우와 잘못 연결된 경우를 나눠 확인해야 했습니다.
두 주문 조회 경로의 차이
새 플랫폼과 Breeze의 주문은 구조와 상태 표현이 달랐습니다. 과거 주문을 화면에 표시하려면 날짜, 금액, 상품과 배송 정보가 어떤 의미인지 맞춰야 했습니다. 필드 이름을 바꾸는 것만으로 같은 주문 상태가 되는 것은 아니었습니다.
금액 역시 원화라는 이유로 무조건 정수로 변환할 수는 없습니다. 각 응답의 통화와 단위, 소수점 표현 규칙을 확인해야 합니다. 날짜는 원본의 시간대와 화면에서 사용할 시간대를 구분해야 합니다.
두 소스의 목록을 함께 제공한다면 정렬과 페이지 처리도 검토해야 합니다. 각 목록에서 첫 페이지를 가져와 단순히 합치는 방식으로는 전체 주문의 다음 페이지를 정확히 만들지 못할 수 있습니다.
조회 실패와 빈 결과의 구분
과거 주문이 없는 경우와 BLOHA 조회가 실패한 경우는 다릅니다. 실패를 빈 목록으로 처리하면 고객이나 CS 담당자가 실제 주문이 없다고 오해할 수 있습니다.
새 플랫폼의 주문 조회를 계속 제공할지, 과거 주문의 일시적인 조회 불가를 어떻게 표시할지는 서비스가 정할 정책입니다. 호출 시간을 제한하거나 장애 시 호출을 줄이는 방법도 검토할 수 있습니다. 병렬 조회를 택하더라도 각 호출의 시간 제한과 실패 처리를 따로 정해야 합니다. 조회 순서만 바꾸는 것으로 한쪽 장애의 영향을 막을 수는 없습니다.
전환 이후의 유지보수
조회 중심의 서비스라도 런타임과 의존성, 모니터링은 계속 관리해야 했습니다. 이후 진행한 업그레이드와 캐시 관련 작업은 레거시 주문 이력 서비스 현대화에 따로 정리했습니다.
이어지는 글에서는 과거 주문 조회와 함께 준비한 CS 조회·반품·배송 상태 확인을 다룹니다.