미리보기가 다른 테이블을 안 셌다

배송비 6,000원을 반영해 달라는 요청이 와서 화면에서 재계산을 누르니 6,000원이 나왔다.

Open Table of contents

증상 — 회수 방법에 따라 갈린 금액

먼저 이상한 것이 하나 있었다.

직접 발송   3,000
자동 회수   6,000

직접 발송 과 자동 회수 사이에서 금액이 두 배로 달라졌다.

화면 관측으로는 이렇게 보였다.

직접 발송   회수 편도만                3,000
자동 회수   초기 배송 + 회수 왕복      3,000 + 3,000

이 해석은 추정이고 배송비 산식을 코드로 확인하지는 않았다.

같은 값이 여러 경로로 나올 수 있으면 지금 보는 것이 어느 경로인지 모른다는 뜻이다. 그래서 눈으로 관측한 값과 내가 추정한 해석을 구분해 적어 뒀다.

저장하기 전에 이 건의 메모를 봤다.

admin_memo: 빠른환불 건으로 보상요청완료

admin_memo 에 보상이 이미 있다고 적혀 있어서 그 금액을 확인해 봤다.

SELECT claim_reward_fee FROM order_returns WHERE id = ?;

claim_reward_fee 로 이미 6,000이 승인돼 있었다.

그런데 재계산 화면에는 6,000 하나만 보이고 이미 승인된 claim_reward_fee 는 그 화면 어디에도 안 나오고 있었다.

claim_reward_fee 가 사는 자리가 달랐다.

[재계산 대상]  이번 반품의 배송비
[보상]         다른 테이블 — 집계에 안 잡힘

미리보기의 집계가 order_returns 이번 건에 한정돼 있었다.

미리보기라는 이름 때문에 최종 결과로 읽었던 것이 문제였다. 그 화면이 무엇을 더하고 무엇을 안 넣는지는 코드를 봐야 나왔다.

그대로 저장했으면 이렇게 된다.

보상        6,000  (이미 승인)
배송비      6,000  (새로 얹음)
────────────────────
실제 정산   12,000

화면에는 6,000인데 실제로는 12,000이 나간다.

저장 시점에는 오류가 안 나므로 정산이 나가고 나서야 드러난다. 되돌리려면 정산 쪽까지 손대야 해서 저장 전에 확인하는 것이 훨씬 싸다.

순서를 정했다.

① 기존 보상 보류를 미승인으로 먼저 닫는다
   (환불은 손 안 대고 보상만 0으로)
② 그다음 재계산
③ 미리보기가 단일 금액으로 나오는지 확인
④ 저장

보상 을 먼저 닫고 나서 재계산하니 미리보기 금액이 실제 총액과 같아졌다.

다만 닫지 않고 그대로 저장하는 경로가 화면에서 막혀 있지는 않았다. 사람이 순서를 지켜야 하는 자리는 적어 두지 않으면 언젠가 어긋난다.

저장하고 끝내지 않고 둘을 더 봤다.

SELECT COUNT(*) FROM ... WHERE order_return_id = ? AND type IN (...);

order_return_id 로 세어 같은 성격의 정산 중복이 0건인지 본다.

SELECT * FROM distribution_jobs WHERE ... AND created_at > '<저장 시각>';

자동 회수로 두면 이미 수거된 건에 재수거가 나갈 수 있어 distribution_jobs 도 0건인지 본다.

저장이 성공했다는 것과 의도한 상태가 됐다는 것은 다른 말이다. 같은 대상에 금액이 붙는 표가 여럿이면 화면 하나가 그 전부를 보여 주지 못한다.