이 값이 어디서 오는지 몰랐다

화면에 나오는 배송비가 틀렸다는 문의를 받았다. 화면 코드를 보니 number_format 으로 변수 하나를 찍고 있었다.

<?= number_format($deliveryFee) ?>원

이 값이 어디서 오는지 따라가는 데 한 시간이 걸렸다.

Open Table of contents

거치는 곳이 많았다
출처를 값과 같이 넘겼다
판단 기준 — 대체 순서
계산 과정을 보이게 했다
정리

거치는 곳이 많았다

경로를 그려 봤다.

화면
 ← 컨트롤러가 view 에 넘김
   ← 주문 계산 서비스
     ← 배송 정책 조회
       ← 상품별 배송 설정 (있으면)
       ← 입점사 기본 정책 (없으면)
         ← 전역 기본값 (그것도 없으면)

세 단계 대체가 있다. 어느 단계에서 온 값인지 화면만 봐서는 모른다.

product.delivery_fee 가 NULL 이면 provider_delivery_policy.fee 로 가고 그것도 없으면 delivery.default_fee 로 간다. 같은 화면에 나온 값이 어떤 상품은 상품 설정에서 오고 어떤 상품은 전역 기본값에서 왔다. 고칠 자리를 찾으려면 그 단계를 먼저 알아야 했는데 조사할 때마다 코드를 처음부터 따라가고 있었다.

출처를 값과 같이 넘겼다

값과 함께 어디서 왔는지 넘기게 했다.

return [
    'fee'    => 3000,
    'source' => 'provider_default',   // product / provider_default / global
];

화면에서는 값만 쓰고 확인용으로만 source 를 볼 수 있게 했다.

<?= number_format($delivery['fee']) ?>원
<?php if ($this->auth->is_admin()): ?>
  <span class="debug">[<?= $delivery['source'] ?>]</span>
<?php endif; ?>

is_admin() 일 때만 source 를 덧붙이므로 관리자가 보면 어느 단계 값인지 나온다. 문의를 받았을 때 이것만 보면 어디를 봐야 하는지 정해진다.

주문이 만들어질 때 계산 근거도 남겼다.

log_message('info', sprintf(
    "배송비 계산 order=%d fee=%d source=%s (product=%s, provider=%s, global=%s)",
    $orderNo, $fee, $source,
    $productFee ?? 'null', $providerFee ?? 'null', $globalFee
));

배송비 계산 order=10231 fee=3000 source=provider_default (product=null, provider=3000, global=2500)

상품 설정이 없어서 입점사 값을 썼다는 것이 한 줄에 나온다.

log_message 에 계산 결과만 남기면 왜 그 값인지 모른다. 재료를 같이 남겨야 나중에 그 판단을 다시 볼 수 있다. 이 한 줄이 있고 없고가 조사 시간을 갈랐다.

판단 기준 — 대체 순서

경로가 세 단계라 그것을 적었다.

배송비 결정 순서

1. 상품별 설정 (product.delivery_fee)
   - NULL 이면 다음
2. 입점사 기본 정책 (provider_delivery_policy.fee)
   - 정책 자체가 없으면 다음
3. 전역 기본값 (config: delivery.default_fee)

주의
- 상품별 설정이 0이면 무료배송이다. NULL 과 다르다
- 입점사 정책의 조건부 무료는 금액 조건을 같이 본다

주의 항목이 실제 문제였다. 0과 NULL 을 같게 처리하는 코드가 있었다.

// 잘못
if (!$product->delivery_fee) { /* 다음 단계 */ }

// 고침
if ($product->delivery_fee === null) { /* 다음 단계 */ }

!$product->delivery_fee 는 empty() 와 같아서 0 도 빈 값으로 본다.

배송비를 0으로 지정한 무료배송 상품이 값이 없는 것으로 처리돼 입점사 기본값이 붙고 있었다. === null 이나 isset() 으로 갈라야 지정한 0이 산다. 받은 문의가 바로 이 경우였다. 지정하지 않은 것과 0으로 지정한 것은 뜻이 다른데 코드가 둘을 같게 보고 있었다.

계산 과정을 보이게 했다

관리자 화면에 계산 확인 기능을 넣었다.

상품 1204, 입점사 88, 주문금액 45,000

  1. 상품별 설정      없음 (NULL)
  2. 입점사 정책      조건부무료 (50,000원 이상)
                     주문금액 45,000 < 50,000 → 3,000원
  3. 전역 기본값      (사용 안 함)

  결과: 3,000원

각 단계와 그 판단이 보인다.

이걸 만든 뒤 문의가 크게 줄었다. 담당자가 직접 열어 보고 답할 수 있게 됐기 때문이다. 물어보는 쪽과 답하는 쪽이 같은 화면을 보게 된 것이 컸다.

대체 단계가 있는 값이 더 있는지도 봤다.

할인율      상품 → 분류 → 전체
배송 기간   상품 → 입점사 → 기본
반품 정책   입점사 → 기본

셋 다 같은 구조라 같은 방식으로 출처를 남기게 했다.

대체가 있으면 결과만으로는 판단 근거를 모른다. 이건 배송비라는 값의 성격이 아니라 대체 단계라는 구조에서 오는 문제였다. 구조가 같으면 같은 조치가 든다.

정리

값이 여러 단계를 거쳐 정해지면 결과만 봐서는 출처를 모른다
조사할 때마다 코드를 처음부터 따라가게 된다
값과 함께 source 를 넘긴다
관리자에게만 출처를 보이면 확인이 빨라진다
로그에 결과와 재료를 같이 남긴다. 결과만 남기면 왜 그런지 모른다
대체 순서를 문서로 적고 주의 사항을 넣는다
0과 NULL 을 같게 처리하면 지정한 0이 무시된다
계산 과정을 보여 주는 화면을 만들면 문의가 준다
대체 단계가 있는 다른 값도 같은 문제를 갖는다