반품 정산을 보정하려고 returns.settlement_fee 를 두 배로 올렸는데 입점사 화면에는 여전히 옛 금액이 보였다. 새로고침과 다른 브라우저를 다 시도해도 그대로였고 데이터베이스를 다시 조회하니 값은 바뀐 대로였다.
Table of contents
Open Table of contents
판단 기준 — 갈림길이 된 API 응답
저장은 됐는데 화면이 다른 것을 보고 있다는 뜻이므로 화면이 무엇을 받는지부터 봤다. DevTools 의 Network 탭에서 그 팝업이 부르는 GET /api/returns/{id} 를 찾아 응답을 열었다.
응답의 return_fee 에 옛 금액이 들어 있었다. API 응답이 데이터베이스와 같으면 화면 문제이고 다르면 API 문제인데 이 확인을 건너뛰고 코드부터 뒤지면 훨씬 오래 걸린다.
원인 — 실시간으로 계산하는 API
그 API 의 ReturnResource 를 따라가니 settlement_fee 를 아예 읽지 않고 있었다. reason_type 에 따라 분기해서 shipping_policies.return_fee 나 returns 의 다른 컬럼을 골라 돌려주는 구조였다.
내가 고친 것은 settlement_fee 이고 화면이 보는 것은 shipping_policies.return_fee 였다. 둘은 아무 관계가 없었고 정산은 정산대로 돌고 화면은 화면대로 계산하고 있었다.
분리된 표시값과 정산값
이 시스템은 표시값을 정책 기반으로 실시간 계산하고 정산값은 저장된 컬럼으로 두고 있었다. 표시는 정책상 얼마인지를 보여 주고 정산은 실제 얼마인지를 담는 의도일 수 있다.
의도가 무엇이든 보정할 때는 둘 다 봐야 한다. 한쪽만 고치면 화면과 정산이 어긋난 채로 남고 어느 쪽이 맞는지도 알 수 없게 된다.
조치 — 무엇을 고칠지의 분기
화면에 보이는 것을 바꾸려면 계산의 입력을 고쳐야 하는데 그 입력이 reason_type 에 따라 갈렸다. buyer 귀책이면 정책 값을 보므로 정책을 고쳐야 한다.
두 가지 방법이 있었는데 shipping_policies 값을 고치는 것과 이 건의 returns 행에만 fee_override 를 두는 것이다. 뒤쪽을 골랐다. 이유는 정책을 고치면 그 정책을 쓰는 다른 건들도 전부 바뀌어서다. 대신 ReturnResource 분기에 fee_override 우선 조건을 한 줄 넣는 배포를 감수했다. 계산 분기를 읽어야 고칠 대상이 정해진다.
주의 — 우선순위가 있는 값들
조사 중에 하나를 더 알게 됐다. 마켓에서 수집한 배송비 값이 channel_return_fee 에 있는데 화면은 그것을 안 쓰고 정책 값을 우선한다.
마켓에서 다른 금액이 왔어도 우리 정책 값이 화면에 나온다는 뜻이다. 어느 쪽이 맞는지는 별개 문제이고 적어도 화면이 무엇을 보는지는 확정됐다. 역추적 순서는 데이터베이스 값과 API 응답과 ReturnResource 코드와 계산 입력 순이고 두 번째가 갈림길이다.
정리
- 화면 값이 저장된 컬럼이 아니라 실시간 계산 결과일 수 있다
- 그러면 그 컬럼을 고쳐도 화면은 안 바뀐다
- 표시값과 정산값이 분리돼 있을 수 있다
- 계산의 입력이 유형에 따라 갈리면 고칠 대상도 갈린다
- 정책 값을 고치면 그 정책을 쓰는 전부가 바뀐다
- 수집값과 정책값이 다를 때 어느 쪽을 우선하는지 확인한다
- 역추적은 데이터베이스와 API 응답과 코드와 계산 입력 순으로 한다
- API 응답 확인이 화면 문제와 API 문제를 가르는 갈림길이다