컷오버 이후 주문·결제·CS 경로 확인

새 플랫폼으로 트래픽을 넘긴 뒤에는 고객과 운영자가 사용하는 기능을 이어서 확인했습니다. 데이터 이관 작업이 끝난 것과 실제 주문·결제·고객 문의가 정상적으로 처리되는 것은 다른 확인이었습니다.

우선 구매 흐름과 기존 주문 조회, CS 도구를 봤습니다. 이후에는 배치와 연동 결과, 응답 시간과 오류 추이를 확인하며 새 플랫폼의 동작을 살펴봤습니다.

구매와 결제 결과

상품을 담고 결제한 뒤 주문이 만들어지는 흐름을 확인했습니다. 테스트 결제로 기능을 확인하되, 결제 승인과 주문 반영, 화면의 결과가 이어지는지 봐야 했습니다.

외부 결제 처리와 내부 주문 상태가 다를 수도 있습니다. 문제가 생겼다면 결제 실패인지, 결과 전달이 늦은 것인지, 주문 반영에서 막힌 것인지 구분해야 했습니다. 사용자에게 보이는 화면만으로 처리 결과를 확정할 수는 없었습니다.

기존 주문 이력과 계정 연결

새 플랫폼에 로그인한 고객이 이전 Breeze 주문도 조회할 수 있어야 했습니다. 이 경로에서는 BLOHA가 글로벌 계정의 연결 키와 기존 주문 이력을 이어 주는 역할을 했습니다.

주문이 보이지 않으면 데이터의 존재 여부와 계정 매핑, 조회 요청에서 사용하는 식별자를 나눠 확인해야 했습니다. 데이터가 없어서인지 연결이 빠져서인지에 따라 조치할 대상이 달랐습니다.

이 부분은 기존 주문을 글로벌 계정으로 조회하기 위한 식별자 연결에서 더 자세히 설명했습니다. 과거 주문을 모두 새 플랫폼에 복사했다는 의미와는 구분해서 볼 필요가 있습니다.

CS 도구와 후속 처리

고객 화면 외에 CS 담당자가 주문과 배송 상태를 조회하고 반품·환불 업무를 이어갈 수 있는지도 확인했습니다. 전환 전 주문과 이후 주문의 조회·처리 경로가 다를 수 있어, 한쪽이 동작하는 것으로 전체 확인을 끝낼 수는 없었습니다.

새 도구의 사용법에 대한 문의와 실제 기능 오류도 구분해야 했습니다. 이전 도구와 화면이 다르다는 이유로 모두 오류인 것은 아니지만, 필요한 업무를 수행할 수 없다면 별도 확인이 필요했습니다.

응답 시간과 오류 추이

주요 화면과 API의 응답 시간, 반복되는 오류를 살펴봤습니다. 전체 수치만 보기보다 특정 경로·계정·주문 상태에서 문제가 생기는지 확인해야 원인을 좁힐 수 있었습니다.

배치나 외부 연동 문제는 전환 직후 바로 드러나지 않을 수도 있습니다. 정해진 작업 시각이 지난 뒤 결과가 반영됐는지, 이전 주문의 상태 변경이 이어지는지도 확인할 항목이었습니다.

이벤트 일정과 남은 작업

다가오는 The Draw·SNKRS 이벤트 일정도 고려했습니다. 평소 트래픽에서 기능이 동작하는 것 외에, 요청이 몰릴 때 확인할 항목과 담당자를 준비해야 했습니다.

안정화 중에는 즉시 완화할 문제와 추가 분석이 필요한 문제를 나눴습니다. 조치를 서두르더라도 해당 요청과 상태를 확인할 기록이 남아야 이후 원인을 다시 볼 수 있습니다.

기존 플랫폼과 달라진 동작을 설명하는 데에는 로컬 팀의 운영 경험도 필요했습니다. 고객이나 CS가 겪는 문제가 오류인지, 전환에 따른 의도된 변경인지 구분하고 남은 작업을 이어 가는 과정이었습니다.