비활성화된 버튼을 우회하지 않는다

교환을 반품으로 바꿔 달라는 문의가 왔는데 관리 화면에 그 버튼이 없었다. API를 찾아보니 살아 있어서 직접 부르면 되겠다고 생각했다.

Open Table of contents

이력이 알려 준 의도

부르기 전에 왜 버튼이 없는지부터 봤다. 화면 파일의 이력을 뒤지니 클레임 변경 버튼을 비활성화했다는 커밋이 나왔다.

실수로 빠진 것이 아니라 의도적으로 주석 처리한 것이었다. 화면에 기능이 없으면 왜 없는지를 이력이 알려 주고 커밋 메시지 한 줄이 그 판단을 바꾼다.

그러면 왜 껐는지를 백엔드 코드로 확인했다. 그 처리는 원주문 상태를 바꾸고 유형을 변경하며 상위 상태를 재계산하고 이력을 남기는 넷만 하고 있었다.

교환을 반품으로 바꾸려면 교환 재출고 주문 항목과 환불 레코드 생성과 마켓 연동 알림과 재출고 주문 취소가 더 필요한데 그 넷이 전부 빠져 있었다.

더 나쁜 것은 교환이 완료됐는지를 확인하는 가드가 없다는 점이었다. 재출고까지 나간 교환도 그대로 전환된다.

고객이 물건을 받았는데 반품 처리가 되고 환불은 생기지 않으며 재출고 주문이 방치된다. 처리 범위가 좁고 가드가 없어서 잘못 쓰면 정합성이 깨지므로 고칠 시간이 없는 동안 못 쓰게 막아 둔 것이었다.

내가 하려던 것이 정확히 그 위험이었다. API를 직접 부르면 가드 없이 그 로직이 돈다.

버튼이 막은 것을 API로 뚫는 셈이고 비활성화된 화면 요소를 우회하는 것은 그 비활성화의 이유를 무시하는 것이다. 이 판단을 하기 전에 우회부터 했으면 데이터가 깨졌을 것이다.

그러면 이 건을 어떻게 처리할지도 정했다. 빠진 넷을 전부 손으로 처리하는 방법과 최소 단계만 직접 만들고 나머지는 정상 화면 기능으로 태우는 방법 둘이었다.

뒤쪽이 나은데 화면을 거치면 연관 처리가 같이 돌기 때문이다. 이 조사에서 기록 시스템을 못 써서 소스와 이력만으로 판단했고 근거가 커밋 메시지와 코드 본문 둘이라는 것을 밝혀 뒀다.