교환을 반품으로 바꿔 달라는 문의가 왔는데 관리 화면에 그 버튼이 없었다. PATCH /claims/{id}/type 을 찾아보니 살아 있어서 직접 부르면 되겠다고 생각했다.
Table of contents
Open Table of contents
이력이 알려 준 의도
부르기 전에 왜 버튼이 없는지부터 봤다. claim-detail.blade.php 의 git log -p 를 뒤지니 클레임 변경 버튼을 비활성화했다는 커밋이 나왔다.
실수로 빠진 것이 아니라 의도적으로 주석 처리한 것이었다. 화면에 기능이 없으면 왜 없는지를 이력이 알려 주고 커밋 메시지 한 줄이 그 판단을 바꾼다.
좁았던 처리 범위
그러면 왜 껐는지를 ClaimService::changeType 으로 확인했다. 그 처리는 원주문 status 를 바꾸고 claim_type 을 변경하며 상위 상태를 재계산하고 claim_histories 에 남기는 넷만 하고 있었다.
교환을 반품으로 바꾸려면 교환 재출고 주문 항목과 refunds 레코드 생성과 채널 연동 알림과 재출고 주문 취소가 더 필요한데 그 넷이 전부 빠져 있었다.
가드가 없는 전환
더 나쁜 것은 교환이 완료됐는지를 확인하는 가드가 없다는 점이었다. 재출고까지 나간 교환도 그대로 전환된다.
고객이 물건을 받았는데 반품 처리가 되고 환불은 생기지 않으며 재출고 주문이 방치된다. 처리 범위가 좁고 가드가 없어서 잘못 쓰면 정합성이 깨지므로 고칠 시간이 없는 동안 못 쓰게 막아 둔 것이었다.
우회가 뚫는 것
내가 하려던 것이 정확히 그 위험이었다. curl 로 API 를 직접 부르면 가드 없이 그 로직이 돈다.
버튼이 막은 것을 API로 뚫는 셈이고 비활성화된 화면 요소를 우회하는 것은 그 비활성화의 이유를 무시하는 것이다. 이 판단을 하기 전에 우회부터 했으면 데이터가 깨졌을 것이다.
대안과 근거의 범위
그러면 이 건을 어떻게 처리할지도 정했다. 두 가지 방법이 있었는데 빠진 넷을 전부 UPDATE 로 손으로 처리하는 것과 최소 단계만 직접 만들고 나머지는 정상 화면 기능으로 태우는 것이다.
뒤쪽을 골랐다. 이유는 화면을 거치면 연관 처리가 같이 돌아서다. 대신 정상 화면이 요구하는 순서대로 단계를 밟느라 한 건 처리에 시간이 더 드는 것을 감수했다. 이 조사에서 기록 시스템을 못 써서 소스와 이력만으로 판단했고 근거가 커밋 메시지와 코드 본문 둘이라는 것을 밝혀 뒀다.
정리
- 화면에 기능이 없으면 왜 없는지 이력부터 본다
- 의도적 비활성화일 수 있고 커밋 메시지가 알려 준다
- 백엔드가 살아 있어도 처리 범위가 좁을 수 있다
- 가드가 없으면 잘못된 상태에서도 그대로 돈다
- 비활성화된 화면을 API로 우회하면 그 이유를 무시하는 것이다
- 대안은 최소 단계만 직접 처리하고 나머지는 화면으로 태우는 것이다
- 기록이 없으면 어디까지가 근거인지 밝힌다