상품 검증 화면에 상태 불일치가 3만 7천 건 넘게 떠 있었다. 우리는 판매중지인데 마켓 수집값은 판매중이라는 것이라 전부 밀린 작업으로 보였다.
Table of contents
Open Table of contents
코드 자체가 없는 마켓
한 덩어리로 보면 3만 건이 넘으므로 채널별로 나눴고 세 채널이 대부분을 차지했다. 첫 번째 마켓의 판매 상태 값을 확인하니 판매 진행과 품절과 영구 중단 셋뿐이었다.
우리가 말하는 판매중지에 해당하는 코드가 없었다. 품절은 재고 개념이고 영구 중단은 되돌릴 수 없으므로 매핑을 아무리 추가해도 안 맞는 영구 불일치였다.
상태가 아니라 기간인 마켓
두 번째 마켓은 판매 종료 일시를 현재 시각으로 설정하는 기간 만료 방식이었다. 상태 코드를 바꾸는 것이 아니다.
수집해 오는 상태값은 따로 있고 그것은 매핑이 완벽했다. 매핑은 문제가 없는데 중지라는 행위 자체가 상태로 표현되지 않는 구조였다.
입도가 다른 마켓
세 번째 마켓은 중지가 옵션 단위였다. 옵션마다 따로 중지 요청을 보낸다.
그런데 우리가 수집하는 스냅숏은 상품 단위의 승인 상태축만 담고 옵션 상태는 안 들어온다. 옵션이 실제로 중지됐어도 상품 상태로는 감지되지 않으며 전체 불일치의 85퍼센트가 여기서 나왔다.
매핑 누락 0건
세 채널의 스냅숏 실분포를 전부 뽑아 매핑 테이블과 대조했다. 매핑 누락이 0건이었다.
처음 가설이 매핑이 빠져서 불일치로 잡힌다는 것이었는데 아니었다. 매핑을 추가해서 해결되는 채널이 하나도 없었고 원인이 셋 다 달랐다.
백로그가 아닌 수치
그래서 결론은 이 불일치 수치를 처리해야 할 백로그로 읽으면 안 된다는 것이었다. 특히 세 번째 채널의 3만여 건은 실제로는 옵션이 중지돼 있고 우리 수집이 못 볼 뿐이라 정상 상태이며 조치가 필요 없다.
이것을 백로그로 세면 3만 건짜리 없는 일이 생긴다. 실제로 할 일은 정말 중지 요청을 안 보낸 건을 찾아 다시 보내는 것인데 그것은 상태 불일치로는 안 찾아지고 작업 이력으로 찾아야 하므로 지표 자체를 바꿔야 했다.
이 결론은 각 마켓 클라이언트 코드가 중지를 어떻게 보내는지 읽고 수집 스냅숏의 실분포를 뽑아 둘을 교차 확인해서 냈다. 코드만 보면 이렇게 보내니 이렇게 되겠거니 하고 데이터만 보면 왜 안 맞는지를 모른다. 감사 결과는 정본 경로를 명시해 남겼는데 이런 것은 나중에 왜 안 고치느냐고 다시 물어보게 되기 때문이다.
정리
- 같은 개념을 마켓마다 다르게 표현한다
- 그 상태 코드가 아예 없는 마켓이 있다
- 상태가 아니라 기간으로 표현하는 마켓이 있다
- 입도가 다르면 감지 자체가 안 된다
- 불일치 수치를 백로그로 읽지 말고 채널별 원인을 분리한다
- 원인이 다르면 일부는 조치가 필요 없다
- 검증은 클라이언트 코드와 수집 실분포를 교차 확인한다
- 감사 결과는 정본 경로를 명시해 남긴다