CS 조회, 반품, 배송 상태 동기화는 왜 같이 풀어야 했나

플랫폼 마이그레이션에서 기술적으로 가장 복잡한 영역은 개별 문제가 아니라, 서로 얽혀 있는 문제들을 동시에 풀어야 할 때 나타난다. CS(Customer Service) 주문 조회, 반품 처리, 배송 상태 동기화 — 이 세 가지는 각각 독립적인 문제처럼 보이지만, 실제로는 하나를 풀지 않으면 나머지도 풀 수 없는 관계다. 이 글은 왜 이 세 문제를 동시에 풀어야 했는지, 그 얽힘의 구조를 기록한다.

컷오버 전후의 과도기에, CS 상담원은 고객 문의에 대응해야 한다. 고객이 ‘주문한 상품이 안 왔어요’라고 하면 배송 상태를 확인해야 하고, ‘반품하고 싶어요’라고 하면 반품 가능 여부를 판단해야 한다. 이 모든 것이 주문 조회에서 시작된다. 주문을 찾지 못하면 배송 확인도, 반품 처리도 불가능하다.

컷오버 시점에 CS 상담원이 직면하는 상황은 다음과 같다: (1) 고객의 주문이 Breeze에서 처리된 것인지, 글로벌 플랫폼에서 처리된 것인지 모른다. (2) 배송 상태 정보가 Breeze의 물류 시스템에서 오는 것인지, 글로벌 플랫폼의 배송 추적 시스템에서 오는 것인지에 따라 조회 방법이 다르다. (3) 반품 요청을 처리하려면 해당 주문이 어느 시스템의 결제 수단으로 처리되었는지에 따라 환불 경로가 달라진다.

이 세 문제가 얽히는 핵심은 ‘주문이 어느 시스템에 있는가’라는 질문에 대한 답이 CS 조회, 배송 추적, 반품 처리 모두의 전제 조건이라는 점이다. 그리고 과도기에는 이 답이 명확하지 않다 — 같은 고객의 주문이 두 시스템에 나뉘어 있을 수 있다.

과도기 운영의 의존성 지도

CS 주문 조회: 두 시스템을 아우르는 통합 뷰

CS 상담원이 사용하는 조회 도구는 고객의 주문을 한 화면에서 볼 수 있어야 한다. Breeze 시절 주문과 글로벌 플랫폼 주문이 별도의 도구에서만 조회되면, 상담원은 고객이 언제 주문했는지에 따라 도구를 전환해야 하고, 이는 상담 시간을 늘리고 실수를 유발한다.

통합 CS 도구는 글로벌 주문 시스템과 BLOHA(또는 Breeze 레거시 시스템)에서 동시에 데이터를 조회하여 하나의 화면에 보여주는 구조가 필요했다. 이것은 앞 편에서 설명한 고객 향 주문 조회와 유사하지만, CS 도구에는 더 많은 정보(내부 주문 상태, 결제 상세, 배송 추적 번호, CS 메모 등)가 필요하다.

반품 처리: 결제 경로에 따른 분기

반품 처리의 핵심은 환불이다. 환불은 원래 결제 수단으로 이루어져야 한다. Breeze에서 처리된 주문의 결제는 한국 PG사(이니시스, KCP 등)를 통해 이루어졌다. 글로벌 플랫폼의 결제는 글로벌 결제 게이트웨이를 통해 처리된다. 컷오버 이전 주문의 반품 환불은 Breeze의 PG사 연동을 통해 처리되어야 하고, 컷오버 이후 주문의 환불은 글로벌 결제 시스템을 통해 처리되어야 한다.

이것은 컷오버 이후에도 Breeze의 PG사 연동 모듈을 일정 기간 유지해야 한다는 것을 의미한다. 최소한 반품 가능 기간(7일) 동안은 Breeze의 결제 환불 기능이 살아 있어야 한다. 이 모듈을 BLOHA 내에 포함시킬 것인지, 별도의 환불 전용 서비스로 운영할 것인지는 설계 결정이 필요했다.

배송 상태 동기화

배송 추적 정보는 물류 파트너(한진택배, CJ대한통운 등)로부터 제공된다. Breeze 시절에는 물류 파트너가 Breeze 시스템에 배송 상태를 업데이트했다. 컷오버 후에는 글로벌 플랫폼의 배송 추적 시스템으로 전환되어야 한다. 그러나 컷오버 시점에 이미 배송이 시작된 주문의 배송 정보는 Breeze 시스템에 있다.

과도기에 물류 파트너의 배송 상태 업데이트가 Breeze와 글로벌 플랫폼 중 어디로 가야 하는지가 명확해야 한다. 컷오버 전 발송된 상품의 배송 상태는 Breeze에 업데이트되고, 이 정보가 CS 도구에서도 조회 가능해야 한다. 컷오버 후 발송된 상품의 배송 상태는 글로벌 플랫폼에 업데이트된다. 물류 파트너와의 연동 전환 시점을 정확히 조율해야 했다.

세 문제의 얽힘

CS 조회에서 주문을 찾으면 → 배송 상태를 확인하고 → 필요 시 반품을 처리한다. 이 흐름이 끊기지 않으려면 세 문제가 동시에 해결되어야 한다. CS 조회가 가능해도 배송 상태가 보이지 않으면 ‘배송 중이에요’라고 답할 수 없다. 배송 상태가 보여도 반품 처리가 불가능하면 ‘반품해 드릴게요’라고 말할 수 없다.

이 세 문제를 별도의 프로젝트로 분리하여 독립적으로 해결하려 했다면, 각 프로젝트가 서로의 완료를 기다리는 교착 상태(deadlock)에 빠졌을 것이다. 따라서 이 세 문제를 하나의 작업 흐름(workstream)으로 묶어, 동일한 팀이 동시에 해결하는 접근을 취했다.

CS 처리 실전 순서

글로벌 전환은 단순한 데이터 이동이 아니라 경계와 책임을 다시 정의하는 작업이었다는 점이 이 시리즈의 중심에 있다. 다음 글에서는 2021 - 주문 이관 배치, 성능 테스트, 정합성 검증은 어떻게 준비했나를 통해 이 흐름을 계속 좁혀 본다.

아키텍처와 운영 트레이드오프

이 문제를 함께 푼 이유는 사용자 여정이 기술 경계를 모르기 때문이다. 조회, 배송, 반품이 각각 다른 시스템에 있더라도 고객은 하나의 주문 경험으로 인식한다. 그래서 내부 구현을 분리하더라도 운영 경로는 하나의 흐름으로 설계해야 했다.

단점은 통합 설계의 초기 비용이 크다는 점이다. 연동 경계와 책임선을 한 번에 맞추려면 팀 간 조율과 테스트 범위가 커진다. 하지만 이를 분리 배포하면 컷오버 이후 장애 전파 범위가 오히려 커질 수 있어서, 당시에는 통합 접근이 더 안전한 선택이었다.

기술 체크포인트

• 주문 상태, 배송 상태, 반품 상태를 동일 타임라인으로 정규화했다.
• CS 화면과 고객 화면의 상태 차이를 줄이기 위해 공통 상태 사전을 운영했다.
• 이벤트 지연/중복 전송에 대비해 최종 상태 우선 규칙을 적용했다.

통합 vs 분리 대응