같은 증상의 네 가지 모양

한 입점사에서 취소 요청이 292건 쌓여 있었고 화면에는 취소 대기나 마켓 처리 실패로 뜨고 있었다. 취소 테이블만 보지 않고 그 주문들의 상태부터 확인했다.

Open Table of contents

이미 완료된 주문

주문 상태를 세니 대부분이 취소 완료였고 실제 취소와 환불은 외부에서 이미 처리된 상태였다. 취소 테이블의 상태 컬럼만 전환되지 않은 것이었다.

입점사가 신고한 처리 실패가 실제 실패가 아니었다. 밖에서 보이는 표현과 실제 상태가 다를 수 있으므로 신고 문구를 그대로 증상으로 삼으면 안 된다.

292건을 한 덩어리로 보면 미처리 292건이지만 채널과 주문별로 분해하니 모양이 갈렸다. 한 주문에서 엿새 동안 20분 간격으로 요청이 233건 생겼고 마지막에 완료가 하나 생겼는데 앞선 것들이 안 정리된 상태였다.

다른 주문 둘은 외부 클레임 수집이 성공인데 우리 취소 상태만 안 바뀌었다. 또 다른 주문은 클레임이 아예 안 만들어졌는데도 주문은 취소 완료였다.

넷 다 주문 상태는 같았지만 원인은 셋이었다. 폭주 후 미정리와 상태 미전환과 클레임 부재다.

원인이 다르면 대응도 달라서 첫째는 중복 정리와 폭주 원인 조사가 필요하고 둘째는 전환 로직 확인이며 셋째는 왜 클레임이 안 생겼는지에 대한 별도 조사다. 한 덩어리로 292건을 정리하면 세 문제가 전부 그대로 남는다.

당장의 대응을 둘로 나눴는데 잔존을 정리해 입점사가 보는 화면을 해소하는 것과 전환 로직을 점검하는 것이다. 앞의 것은 즉시 할 수 있고 뒤의 것은 안 하면 또 쌓인다.

다만 근본 원인은 아직 미규명이라고 적었는데 뒤쪽을 하려면 코드를 봐야 하고 그것이 이번 조사 범위 밖이었기 때문이다. 진단 순서로는 취소 테이블만 보지 않고 주문 상태와 클레임을 확인한 뒤 채널과 주문별로 분해하는 것을 남겼다.

이 조사에서 배운 것은 같은 증상의 건들을 분해하면 유형이 갈린다는 점이다. 292건이라는 한 숫자가 233건과 두 건과 한 건 등으로 나뉜다.

각각 대응이 완전히 다르고 가장 큰 덩어리가 무엇인지도 함께 나온다. 비중을 알면 어디부터 잡을지가 정해지고 한 덩어리로 세면 원인이 여럿이라는 것 자체를 못 본다.