막힌 게 정책일 수 있다

교환 철회 버튼을 누르면 실패 팝업이 뜬다는 문의가 장애로 접수됐다. 주문번호에서 시작해 항목 옵션과 반품 접수와 배송 클레임까지 다섯 단계를 순서대로 조회하며 상태를 적었다.

Open Table of contents

메시지까지 적어 두고 막는 코드

철회 로직을 찾으니 반품 상태가 수거 완료인 경우를 명시적으로 걸러 내고 있었다. 실패 사유 문구까지 코드 안에 적혀 있었으므로 예외 상황이 아니라 의도된 처리였다.

물건이 이미 회수된 뒤에 교환을 없던 일로 하면 재고가 맞지 않으므로 막는 것이 맞다. 즉 이것은 고쳐야 할 결함이 아니라 지켜야 할 정책이었다.

정책이라고 답하고 끝낼 수도 있었지만 요청자가 실제로 원하는 것을 다시 읽었다. 교환품을 받았는데 그것도 마음에 들지 않아 반품하고 싶다는 것이 본래 의도였다.

철회는 그 사람이 아는 버튼 이름일 뿐 목적 자체가 아니었다. 왜 막히느냐가 아니라 무엇을 하려는 것이냐를 물으면 다른 경로가 보인다.

교환 재출고 항목이 출고 완료 상태로 남아 있었으므로 그 항목에 대해 신규 반품을 접수하면 된다. 정책을 우회하는 것이 아니라 원래 그 상황을 위해 존재하는 정상 경로였다.

요청된 형태는 막혀 있지만 가능한 형태가 따로 있는 구조였다. 요청의 형태를 바꾸면 되는 일을 고칠 일로 받으면 없는 결함을 찾게 된다.

운영 쪽에는 철회가 정책상 불가하니 재출고 항목에 대해 반품을 새로 접수하는 방식으로 처리하면 된다고 회신했다. 여기까지가 요청자가 필요로 하는 답이다.

내부 기록에는 이 유형의 실패 문의가 장애가 아니므로 수정 대상이 아니라는 판정을 따로 남겼다. 남기지 않으면 같은 유형이 올 때마다 다섯 단계 체인을 다시 따라가게 된다.

조사하면서 알게 된 컬럼 위치와 교환 항목의 자기참조 관계도 함께 적었는데 여기서 하나를 조심했다. 차단 로직과 반품 테이블 구조는 직접 열어서 확인한 일차 소스였다.

반면 상태 코드 매핑은 탐색 결과의 요약에서 나온 값이라 일차 소스가 아니었다. 그래서 그 항목에는 사용 전에 상수 정의 파일로 재확인이 필요하다고 표시했고 이것을 나누지 않으면 다음 사람이 그대로 가져다 쓴다.