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