교환 두 건이 auto_reship 플래그가 켜져 있는데도 재배송이 진행되지 않았다. 플래그가 켜져 있으면 도는 것 아니냐는 데서 조사가 시작됐다.
Table of contents
Open Table of contents
원인 1 — 본문이 없는 매퍼
상태를 변환하는 ExchangeStatusMapper::map() 을 열어 보니 본문 없이 그냥 return null; 이었다. 두 채널 다 그랬다.
인터페이스를 구현하느라 만들어 놓고 내용을 안 채운 것인데 그래도 컴파일은 된다. exchanges.status 를 조회하니 created_at 과 updated_at 이 같아서 만들어진 뒤로 한 번도 안 바뀐 상태였다. 값이 있긴 하지만 초기값에서 멈춰 있으므로 그 채널들은 이 컬럼을 신뢰해 판단하면 안 된다.
원인 2 — 더 근본에 있던 부재
여기서 멈추려다 AutoCompleteClaims 커맨드를 봤다. 대상 조건이 WHERE type = 'return' 만으로 걸려 있어서 교환은 아예 들어오지 않았다.
즉 교환은 수거 완료 이후 재배송까지 잇는 자동화가 애초에 없었다. 매퍼가 제대로 있어도 교환은 자동으로 안 가므로 두 문제 중 이쪽이 더 근본이고 매퍼만 고쳐도 교환은 안 된다. 한 원인을 찾았다고 멈췄으면 매퍼만 고치면 된다고 보고했을 것이다.
수백 건이라는 규모
얼마나 쌓였는지를 COUNT(*) 로 셌더니 수백 건이었고 그중 그해 건이 백 건 남짓이었다. 몇 년에 걸쳐 쌓였고 지금도 계속 쌓이고 있다는 뜻이다.
건수를 세면 가끔 있는 일인지 구조적인 것인지가 갈리는데 수백 건이면 후자다. 같은 유형의 문의가 계속 들어와 그때마다 개별로 처리하고 있었다. 구조적으로 수동 개입이 필요하니 반복되는 것이 당연했다.
조치 — 세 단계로 나눈 해결
두 가지 방법이 있었는데 매퍼와 자동화를 한 번에 만들어 배포할 때까지 기다리는 것과 단기와 중기와 장기로 단계를 나누는 것이다. 뒤쪽을 골랐다. 이유는 자동화가 나올 때까지 몇 주 동안 같은 문의가 계속 쌓여서다. 대신 단기 절차가 자리 잡으면 장기 자동화의 우선순위가 밀릴 수 있다는 것을 감수했다. 단기로는 재배송 처리 경로 RESHIP.md 를 배포해 문의가 오면 무엇을 해야 하는지 알게 했고 코드 변경은 없다.
중기로는 교환 관리 화면에 재배송이 필요하다는 표시와 송장 입력을 개선한다. 운영자가 화면에서 발견하고 처리하게 하는 것이다. 장기로는 map() 을 구현하고 수거 완료에서 재배송으로 잇는 자동화를 만든다. 자동화가 답이라고만 보고하면 그때까지 아무것도 안 바뀌므로 지금 할 수 있는 것부터 순서를 매겼다.
주의 — 사실과 추론의 구분
보고할 때 근거의 강도를 나눴다. map() 이 null 을 반환한다는 것과 자동 완료가 return 만 대상이라는 것은 소스로 확인했고 수백 건은 집계로 확인한 사실이다.
map() 이 null 이라 수집에서 건너뛰고 다른 계층이 처리해 상태가 초기값에서 영구 정체한다는 연결 고리는 코드 정황에 기반한 추론이다. 실행 흐름을 따라가 보지는 않았다. 그래서 그 연결은 정황 추론이며 별도 검증이 필요하다고 적었는데 같은 보고 안에서도 근거의 강도가 다르고 안 나누면 추론이 사실로 굳는다.
정리
- 인터페이스만 구현하고 항상
null을 돌려주는 메서드가 있을 수 있다 created_at과updated_at이 같으면 그 뒤로 아무도 안 건드린 것이다- 한 원인을 찾았다고 멈추지 않는다
- 건수를 세면 가끔인지 구조적인지 갈린다
- 구조적으로 수동 개입이 필요하면 같은 문의가 반복되는 것이 당연하다
- 해결을 단기와 중기와 장기로 나눈다
- 근본 해결만 말하면 그때까지 아무것도 안 바뀐다
- 소스로 확인한 것과 추론을 나눠 적는다