송금 대사 배치로 원장·결제·큐 불일치 자동 감지

연락처 송금 대사 배치를 만들게 된 이유

운영 들어간 지 한 달쯤 됐을 때 파트너 한 곳에서 "어제 송금 건 합계가 안 맞는다"는 문의가 들어왔음. 큐에 쌓인 송금 요청, 결제대행사로 넘긴 실제 출금, 우리 원장 잔액 차감 — 이 셋이 따로 노는 순간이 가끔 있다는 걸 그제서야 발견함. 사람이 매일 아침 SQL 돌려서 맞추고 있었는데 이게 지속 가능하지 않다고 판단해서 일일 대사 배치를 박기로 했음.

배치 설계에서 제일 고민했던 부분

처음엔 단순하게 "전날 0시~24시 송금 큐 vs 출금 결과 조인" 으로 짜려다가 다음 케이스들 때문에 갈아엎었음.

• 자정 직전에 들어와서 새벽 1시에 처리된 건 (날짜 경계 문제)
• 결제대행사 응답 지연으로 우리는 SUCCESS 인데 상대는 PENDING
• 부분 환불로 원금이 쪼개진 건
• 같은 연락처에 같은 금액이 두 번 찍혀서 중복 의심으로 보류된 건

결국 큐 기준 시각이 아니라 "확정 시각" 으로 윈도우를 잡고, 미확정 건은 별도 버킷으로 빼서 N+1 일에 다시 검사하도록 바꿈. 이 한 줄 정책 바꾸는 데 반나절 날아갔음.

텔레그램 리포트 붙이기

운영자가 메일 안 봄. 슬랙도 채널 너무 많아서 묻힘. 결국 텔레그램 봇이 제일 빨리 눈에 들어온다는 결론. 매일 아침 06:05 에 요약 리포트 한 통, 불일치 발견 시 즉시 한 통, 두 종류로 분리했음.

[일일 대사] 2026-03-14
정합: 1,284건 / 4.2억원
미확정: 3건 (재검사 대기)
불일치: 0건

요약 메시지는 의도적으로 5줄 이내 로 제한함. 길어지면 안 읽음.

삽질했던 것 두 개

• 관리자 화면에서 수동으로 대사 재실행 버튼 만들었는데 권한 체크 빼먹어서 개발용 엔드포인트랑 권한 레벨이 똑같이 나가버림. 코드 리뷰에서 잡혀서 바로 분리. 운영 영향은 없었지만 식겁함.
• 텔레그램 토큰을 처음에 설정 파일에 박아둠. 당연히 안 되는 거 알면서 "일단 돌려보고 옮기자" 했다가 그대로 PR 올라갈 뻔함. 시크릿 매니저 경유로 정리.

회고

대사 자동화는 "있으면 좋은 것" 이 아니라 사고 터지기 전에 박아둬야 하는 것 이라는 걸 다시 확인함. 사람이 SQL 로 맞추는 동안에는 어차피 사람이 놓친 건 영원히 안 보임. 기준 시각 정의가 가장 어려웠고, 알림 채널은 "가장 거슬리는 곳" 에 박는 게 답이었음.

다음