계산된 화면 값 | isdnetworks

반품 정산을 보정하려고 컬럼 값을 두 배로 올렸는데 입점사 화면에는 여전히 옛 금액이 보였다. 새로고침과 다른 브라우저를 다 시도해도 그대로였고 데이터베이스를 다시 조회하니 값은 바뀐 대로였다.

Open Table of contents

갈림길이 된 API 응답

저장은 됐는데 화면이 다른 것을 보고 있다는 뜻이므로 화면이 무엇을 받는지부터 봤다. 개발자 도구에서 그 팝업이 부르는 API를 찾아 응답을 열었다.

응답에 옛 금액이 들어 있었다. API 응답이 데이터베이스와 같으면 화면 문제이고 다르면 API 문제인데 이 확인을 건너뛰고 코드부터 뒤지면 훨씬 오래 걸린다.

그 API 코드를 따라가니 저장된 정산 컬럼을 아예 읽지 않고 있었다. 사유 유형에 따라 분기해서 배송 정책 테이블의 값이나 엔티티의 다른 컬럼을 골라 돌려주는 구조였다.

내가 고친 것은 정산용 컬럼이고 화면이 보는 것은 정책의 반품 배송비였다. 둘은 아무 관계가 없었고 정산은 정산대로 돌고 화면은 화면대로 계산하고 있었다.

이 시스템은 표시값을 정책 기반으로 실시간 계산하고 정산값은 저장된 컬럼으로 두고 있었다. 표시는 정책상 얼마인지를 보여 주고 정산은 실제 얼마인지를 담는 의도일 수 있다.

의도가 무엇이든 보정할 때는 둘 다 봐야 한다. 한쪽만 고치면 화면과 정산이 어긋난 채로 남고 어느 쪽이 맞는지도 알 수 없게 된다.

화면에 보이는 것을 바꾸려면 계산의 입력을 고쳐야 하는데 그 입력이 사유 유형에 따라 갈렸다. 구매자 귀책이면 정책 값을 보므로 정책을 고쳐야 한다.

그런데 정책을 고치면 그 정책을 쓰는 다른 건들도 전부 바뀐다. 한 건만 바꾸려면 엔티티 쪽을 고쳐야 하므로 계산 분기를 읽어야 고칠 대상이 정해진다.

조사 중에 하나를 더 알게 됐다. 마켓에서 수집한 배송비 값이 별도 컬럼에 있는데 화면은 그것을 안 쓰고 정책 값을 우선한다.

마켓에서 다른 금액이 왔어도 우리 정책 값이 화면에 나온다는 뜻이다. 어느 쪽이 맞는지는 별개 문제이고 적어도 화면이 무엇을 보는지는 확정됐다. 역추적 순서는 데이터베이스 값과 API 응답과 API 코드와 계산 입력 순이고 두 번째가 갈림길이다.