이미 빠진 것의 이중 차감

수집한 마켓 데이터에 판매자 할인 필드가 새로 생겼고 그것을 가격에서 빼서 실제 판매가를 만들자는 제안이 나왔다. 필드 이름만 보면 맞는 식처럼 보였지만 넣기 전에 확인하기로 했다.

Open Table of contents

이미 쓰고 있는 값과의 대조

우리 저장소에는 마켓 가격을 담는 컬럼과 그것이 할인가인지 표시하는 플래그가 이미 있었다. 수집 응답의 가격 필드와 우리 값을 나란히 놓고 몇 건을 비교했다.

세 건 모두 정확히 일치했고 플래그도 할인가로 서 있었다. 즉 응답의 가격은 이미 할인이 반영된 값이었고 판매자 할인 필드는 뺄 금액이 아니라 프로모션 정보를 알려 주는 별도 레이어였다.

제안된 식을 그대로 넣었으면 이미 반영된 할인을 한 번 더 빼는 이중 차감이 된다. 어디서도 예외가 나지 않고 계산 결과만 조용히 낮아진다.

적용 대상이 수십만 건 규모였고 가격이 틀리면 정산이 틀리며 정산이 틀리면 돈 문제가 된다. 새 필드를 받았다고 반드시 써야 하는 것은 아니므로 그 컬럼은 손대지 않고 원가와 동일하게 유지하기로 했다.

세 건으로 판단해도 되느냐는 물음이 남는데 이 경우에는 충분했다. 확인하려는 것이 이미 반영됐는가라는 이분법이기 때문이다.

이미 반영됐으면 응답 값이 우리 할인가와 같고 아니면 우리 정가와 같아지므로 세 건이 모두 전자면 후자 가설은 서기 어렵다. 숫자를 확정하는 조사와 가설 둘 중 하나를 고르는 조사는 필요한 표본이 다르다.

별개로 기존 데이터에 새 필드를 채우려면 백필이 필요해 스크립트의 지원 채널 목록을 봤는데 이번 채널이 없었다. 스크립트가 추출기를 이름으로 찾는 경로만 쓰고 이 채널은 다른 방식으로 붙어 있어 대상에서 빠진다.

즉 스크립트를 확장하지 않으면 백필이 되지 않는 상태였다. 확장을 검토하기 전에 그 작업이 정말 필요한지부터 확인하기로 했다.

수집 설정을 보니 이 채널의 재수집 주기가 하루였다. 기존 데이터도 하루 안에 새 필드가 채워지므로 자연 재수집으로 해결되는 상황이었다.

주기적으로 갱신되는 데이터는 백필 자체가 불필요할 수 있으므로 주기부터 확인하는 것이 순서다. 스크립트를 확장했다면 결과가 같은 작업에 시간을 쓴 셈이 된다.