결제 웹훅 원장·잔액 대조 배치로 정산 분쟁 추적 가능해짐

웹훅 원장 기록부터 깔았음

결제대행사 웹훅이 들어올 때 처리만 하고 흘려보내던 구조였는데, 정산 분쟁 한 번 터지고 나니 "그때 그 웹훅 진짜 왔었냐"는 질문에 답을 못 했음. 헤더, 페이로드, 서명검증 결과, 처리 결과까지 전부 원장으로 적재하기로 했음.

• 들어온 원본은 가공 없이 그대로 저장
• 처리 단계별 상태 코드 분리 (수신완료 / 검증완료 / 반영완료 / 실패)
• 실패 사유는 enum 으로 떨어뜨려서 집계 가능하게

이걸 깔고 나니 "웹훅 누락이냐 우리가 떨군 거냐"가 1분 안에 판가름 남. 이전엔 로그 grep 해서 한 시간씩 까봤음.

잔액 동기화 보정 알림

파트너 잔액이 결제대행사 측 잔액이랑 가끔 어긋남. 원인은 다양함 — 환불 처리 타이밍, 수수료 차감 라운딩, 멱등성 깨진 재처리 등. 매번 사람이 발견해서 보정 쿼리 돌리는 게 비효율이라 배치를 깔았음.

자동 보정은 일부러 안 넣었음. 차이만 잡고 사람한테 넘김. 데이터 무결성은 자동화하면 더 큰 사고로 번짐 — 이게 이번 설계 핵심이었음.

거래 대조 배치

매일 새벽 결제대행사 일별 명세를 받아서 내부 거래내역과 한 줄씩 매칭함.

[1] 양쪽 모두 존재 → OK
[2] 외부만 존재   → 누락 의심 (웹훅 유실?)
[3] 내부만 존재   → 미정산 또는 미반영
[4] 금액 불일치   → 즉시 에스컬레이션

[2]번이 생각보다 자주 나옴. 이때 웹훅 원장이랑 교차 조회하면 "웹훅은 왔는데 처리가 실패했음"인지 "웹훅 자체가 안 왔음"인지 깔끔하게 갈림. 원장 깔길 잘했다 싶었음. 두 작업이 한 사이클에서 같이 들어간 게 결과적으로 정답이었음.

회고

• 원장은 비싸 보여도 분쟁 터지면 가장 싼 자산임
• 자동 보정보다 자동 감지 가 먼저. 보정은 사람이.
• 대조 배치는 웹훅 원장이랑 짝일 때 위력이 두 배

내일은 알람 임계치 튜닝하고 [3]번 케이스 라벨링 룰 더 다듬어야 함. 끝