증상
통관 플래그를 켜는 PUT이 200 SUCCESS를 돌려준다. 재조회하면 값이 그대로다. 페이로드를 바꿔봐도, 상태를 바꿔봐도 같다. 수천 건 전량이 이 상태였다.
원인
그 항목의 배송방법 필드가 특정 값이면 통관 플래그가 무시된다. 통관 플래그 자체엔 아무 문제가 없다 — 다른 필드가 이 필드의 운명을 정한다. 그리고 배송방법 필드는 등록 시점 확정값이라 바꾸려 하면 400이다.
앞의 "등록 시점에만 정할 수 있는 필드"와 "일방통행 필드"는 자기 자신이 안 바뀌는 것이었다. 이건 자기가 안 바뀌면서 남까지 막는다. 새 형태다.
★ 안 먹는 필드를 보지 말고 그 필드를 지배하는 상위 설정을 찾는다. 안 먹는 필드를 아무리 들여다봐도 원인이 안 나온다. 범인이 다른 필드이기 때문이다.
두 번째 사례 — "누락" 400이 값을 요구하는 게 아니다
브랜드 상품 등록에 "제품 식별번호 누락" 400이 떴다. 값을 채웠더니 오히려 계속 거부됐다.
브랜드 필드에 값이 있으면 그 검증이 걸리고, 브랜드를 비우면 검증 자체가 사라진다. "누락"은 "값을 넣으라"가 아니라 "이 조합이 성립하지 않는다"는 뜻이었다.
★ 에러 메시지가 지목하는 필드가 원인인 경우가 오히려 드물다. 막히면 값을 채우는 방향만 보지 말고, 검증을 유발하는 필드를 끄는 방향도 본다. (브랜드는 일방통행이라 공란으로 시작하는 쪽이 선택지를 남긴다.)
앞 항목과 반대 처방이다 — 구분해야 한다
"등록 당시 통과했다고 지금도 통과하지 않는다"는 "삭제가 아니라 값 대체"다. 그건 필수 속성이라 빼면 다른 에러로 바뀌는 경우다. 여기는 검증을 유발하는 필드가 따로 있는 경우다. 메커니즘이 다르므로 처방도 반대다. 한 처방을 모든 400에 적용하지 않는다.
해법
검증
★ 정상 등록분 표본을 열어보는 것이 문서보다 빠르다. 두 번째 사례의 답은 추론이 아니라 잘 팔리고 있는 항목 4건을 그냥 열어봐서 나왔다 — 식별번호 속성 셋이 전부 빈 문자열이었다. 통과하는 페이로드가 이미 계정 안에 있다. 되는 것을 손에 넣고 나란히 놓는다.
그리고 한 층을 걷어내면 그 아래 층이 드러난다. 400을 없앤 뒤 "정상 처리 재개 2천여 건"을 기록했지만 허수였다 — 400이 사라졌을 뿐 값은 여전히 안 들어갔다. 거부가 사라진 것과 값이 반영된 것은 다른 사건이다.