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