가설을 전부 배제한 뒤의 확정

승인 상태가 막혀 있던 상품을 재조회로 교정했더니 일부가 승인 완료로 바뀌었다. 그런데 그중 열두 건에서 갱신 전송 작업이 만들어지지 않았다.

Open Table of contents

승인은 됐는데 작업이 안 생긴 건

승인 상태를 조회하니 완료로 바뀌어 있었다. 그러면 갱신 작업이 생겨야 하는데 작업 테이블에 아무것도 없었다.

작업 생성을 막는 조건이 무엇인지부터 후보를 세웠다. 옵션 추가금과 가격 상한과 입점사 활성 여부와 관련 플래그 넷이 그럴듯했다.

해당 상품들의 옵션 추가금을 조회하니 전부 0이라 그 조건에 안 걸렸다. 가격도 상한 이내였고 입점사는 활성이었으며 관련 플래그도 전부 정상이었다.

넷이 전부 배제되고 나서 작업 생성 차단 지점을 처음부터 다시 읽었다. 거기서 보는 것이 승인 상태가 아니라 상품 자체의 판매 상태였다.

열두 건의 판매 상태를 조회하니 전부 연동 해제이거나 판매 중지였다. 승인 상태와 판매 상태가 독립된 두 축이었던 것이다.

재조회는 승인 상태만 갱신하고 판매 상태는 건드리지 않는다. 한쪽이 정상으로 돌아왔다고 다른 쪽이 따라오지는 않는다.

처음에는 작업이 안 생기는 것을 결함으로 봤는데 연동 해제하거나 판매 중지한 상품을 밖으로 안 보내는 방어였다. 고칠 대상이 아니라 지켜야 할 동작이었다.

강제로 작업을 만들었으면 판매를 중지한 상품이 외부에서 되살아났을 것이다. 그래서 승인 상태가 정상인데 전송이 안 되면 판매 상태부터 확인한다는 순서를 절차에 적었다.

네 가설을 배제한 것의 값은 시간을 줄인 데 있지 않았다. 배제하지 않았으면 상품 상태 때문인 것 같다는 말까지만 할 수 있고 다른 원인이 섞였을 가능성이 남는다.

열두 건 중 열두 건이 전부 같은 조건에 걸린 것도 단일 원인의 근거가 됐다. 코드에서 차단 조건을 찾고 데이터에서 그 조건에 걸리는지를 확인하는 양쪽을 맞춰야 원인이라고 말할 수 있다.