다른 컬럼에 있던 금액

MySQL 에서 반품 건의 배송비 정산을 검증하고 있었다. 이름이 가장 비슷한 return_delivery_fee 를 SELECT 하니 0.00 이 나와서 배송비 누락으로 보였는데 화면에는 「반품/교환 배송비 정산 6,000원」이 찍혀 있었다.

Open Table of contents

증상 — 화면의 금액과 조회한 0

누락이라고 결론 내기 전에 그 화면이 어느 값을 읽어서 보여 주는지를 grep 으로 코드에서 확인했다. 화면은 내가 조회한 컬럼이 아니라 다른 컬럼을 읽고 있었다.

같은 표의 다른 컬럼을 함께 뽑아 보니 금액은 다른 자리에 있었다.

return_delivery_fee        0.00
refund_price_to_provider   6000.00   ← 여기
refund_price_from_member   0.00
refund_price_to_member     0.00

자료가 없었던 것이 아니라 내가 다른 자리를 보고 있었던 것이다.

왜 컬럼이 여러 개인지 보려고 DESC 로 전부 뽑아 각각이 무엇인지 정리했다.

return_delivery_fee          계좌이체·택배동봉으로 따로 받을 금액
refund_price_to_provider     환불에서 차감해 공급사에 정산할 금액
refund_price_from/to_member  회원 결제 관련

이름이 비슷해도 채우는 시점과 주체가 서로 달랐다.

return_delivery_fee 는 계좌이체나 택배동봉으로 따로 받을 때만 채워지는 자리였다. 그 방식으로 처리되지 않은 건에서는 NULL 이 아니라 0으로 남으므로 미기입과 실제 0이 구분되지 않았다.

정리하다 보니 어떤 회수 방법을 고르느냐에 따라 계산되는 금액 자체가 달라진다는 것이 보였다. 실제 배송이 어떻게 됐는지와 무관하게 선택한 방법이 값을 정하고 있었다.

방법에 따라 판매자에게서 차감되는 것과 안 되는 것이 갈렸다. 그러면 실무에서 무엇을 고를지가 정산 결과를 직접 바꾸는 셈이었다.

이미 물건이 수거된 건이라도 뒤늦게 방법을 바꾸면 금액이 다시 계산되는 구조였다. 상황이 끝났으니 값이 굳어 있을 것으로 봤던 짐작이 틀렸다.

거기에 방법에 따라 회수 요청이 자동으로 나가는 것까지 있어서 선택지가 사실상 하나로 좁혀졌다. 차감이 없고 자동 요청도 안 나가는 방법을 고르는 것이 답이었다.

이 건에서 얻은 것은 0을 누락으로 바로 읽지 않는다는 순서였다. NULL 이면 안 채워진 것이 분명하지만 0은 정상값일 수 있고 그 판단은 그 컬럼이 언제 채워지는지를 봐야 나온다.

그래서 검증 규칙에 화면이 읽는 컬럼을 grep 으로 먼저 확인한다는 항목을 넣었다. 금액 구성을 함께 보면 왜 그 값이 나왔는지까지 설명되므로 검증이 한 번에 끝났다.