증상
크라우드펀딩 출신 제품군을 소싱 정책에서 전량 제외하고 있었다. 근거는 명확해 보였다 — "발송기한 7일을 구조적으로 맞출 수 없다." 배송이 1~3개월 뒤인 상품이니 당연했다. 그 판단으로 의심 41건 / 11개 도메인과 편집숍 하나 전체가 카탈로그에 못 들어왔다.
원인
7일은 플랫폼의 상한이 아니었다. 우리 등록 파이프라인의 정본값 표에 이렇게 박혀 있던 숫자다.
| dispatch_deadline_days | 7 |상품별로 보내는 설정값이다. 20으로 올리면 그만이었다. "구조적으로 불가능"이 아니라 "한 필드를 안 바꿨을 뿐"이었다.
★★★ 기본값은 제약처럼 생긴다. 코드에 상수로 한 번 박히고 나면, 그 값을 매번 보면서도 "이건 바꿀 수 있는 값인가"를 아무도 다시 묻지 않는다. 오히려 정본값 표에 정리되어 있다는 사실이 확정된 사양이라는 인상을 준다.
★★★ 제약을 근거로 정책을 만들 때는 그 제약의 출처를 확인하라 — 플랫폼 문서인가, 우리 코드인가. 후자면 그것은 제약이 아니라 우리가 한 선택이다. 이 컬렉션의 404를 "그런 기능이 없다"로 읽지 마라와 같은 형태다 — 찾지 않은 것을 없는 것으로 읽었다.
해법
감지 로직은 그대로 두고 감지 후의 행동만 바꿨다 — 배제에서 경고 삽입 + 발송기한 상향으로. 정책의 골격이 아니라 한 분기의 방향이 문제였다.
★ 남은 정직한 한계: 20도 우리가 정한 숫자다. 1~3개월 뒤 발송이면 20일도 못 맞춘다. 감지만으로는 부족하고 실제 발송예정일을 읽어 그 값으로 설정해야 한다. 그게 안 되면 상품명과 상세의 명시적 고지가 실질 방어다.
검증 방법
★★ 정책 문서의 "불가능"마다 근거 링크를 요구하라. 플랫폼 문서 URL이 없는 불가능 주장은 우리 코드의 상수일 가능성을 의심한다. grep으로 그 숫자를 코드에서 찾아보는 데 1분 걸린다 — 우리는 그걸 안 하고 열흘 넘게 상품군 하나를 배제했다.
★★★ 같은 날 두 번째 사례가 나왔다 — 이번엔 추정값이었다
같은 정책 문서의 다른 조항이 "고정 배송비 때문에 저가 상품은 구조적으로 마진이 안 난다"며 가격대 하나를 통째로 배제하고 있었다. 실측해 보니 공급처별로 $0, $4, $11, $32였다. 무료배송인 곳에서는 그 가격대가 그대로 열린다.
| 근거로 쓰인 숫자 | 실체 | |
|---|---|---|
| 조항 A | 발송기한 7일 | 우리 코드의 기본값 |
| 조항 B | 배송비 고정 2만원대 | 우리 추정값 |
★★★ 둘 다 "구조적으로 불가능"이라는 말로 상품군을 배제했고, 둘 다 우리가 정한 숫자였다. 그리고 둘 다 한 번도 실측되지 않았다.
★★★ 가정값이 정책의 근거로 올라가면 가정이라는 꼬리표가 떨어진다. 숫자만 남고, 정책 문서에 적혀 있다는 사실이 그 숫자에 권위를 부여한다. 코드의 상수는 그래도 grep으로 찾을 수 있지만, 문서에 서술문으로 녹아든 추정값은 찾을 수조차 없다.
★★ 해법 — 추정값에는 해제 조건을 붙여라
같은 시스템에 제대로 쓰인 노트가 하나 있었다. 같은 추정 배송비를 쓰면서 이렇게 적어둔 것이다.
"이 배송비는 가정값이고, 실배송비 데이터를 확보하면 재산정한다."
★★★ 조건을 적어둔 쪽만이 조건 충족을 알아볼 수 있었다. 실측 데이터가 생긴 날, 그 항목은 즉시 해제 가능해졌고 나머지는 여전히 사실처럼 서술된 채 남아 있었다.
★ 규약: 추정값을 문서에 쓸 때는 세 가지를 같이 쓴다 — ① 추정임을 명시 ② 출처(어디서 나온 숫자인가) ③ 해제 조건(무엇이 생기면 다시 계산하는가). 셋 중 하나라도 빠지면 그 숫자는 머지않아 사실이 된다.
★ 그리고 전제가 깨져도 논리가 다 무효인 건 아니다. "고정비가 크면 저가 구간은 재가격으로 못 고친다"는 추론은 여전히 맞다. 틀린 것은 "모든 공급처가 그렇다"는 전제 하나였다. 정책을 버리지 말고 전역 조건을 개별 조건으로 바꿔라.