입금 알림 파싱 오류와 오매칭 정산 버그 수정

또 파싱이 깨졌다

은행 앱에서 메신저 알림으로 쏴주는 입금 메시지를 받아 파트너 잔액에 반영하는 로직이 있음. 알림 포맷이 어느 날 슬쩍 바뀌면서 파싱이 통째로 실패. 입금은 들어왔는데 시스템엔 아무 일도 안 일어남. 운영팀이 수동으로 메우다 빵 터졌고, 이번에 두 개를 한꺼번에 잡았음.

• 새 포맷의 줄바꿈/공백 차이로 정규식이 못 잡던 케이스
• 입금자명이 "No Name"으로 들어와서 엉뚱한 파트너에게 매칭되던 문제

포맷이 바뀐 걸 어떻게 알아

은행 쪽이 말 없이 템플릿을 손볼 거라곤 생각 못 했음. 기존 정규식은 한 줄짜리 문장을 가정했는데, 신규 포맷은 줄바꿈이 한 번 더 끼고 금액 앞 공백이 두 칸으로 늘어 있었음.

[기존] OO은행 입금 100,000원 홍길동
[변경] OO은행
       입금  100,000원
       홍길동

\s+ 한 방으로 풀던 걸 [\s\S]+?로 바꿔 멀티라인을 흡수하게 했음. 다만 너무 탐욕스러워지면 다른 줄까지 먹어버려서, 금액 토큰을 앵커로 잡고 앞뒤를 따로 캡처하도록 분리. 양쪽 포맷을 모두 픽스처로 박아두고 회귀 테스트도 추가.

No Name 필터

진짜 골 때리던 쪽은 입금자명이 빈 값일 때 외부 시스템이 "No Name"이라는 문자열을 그대로 꽂아 넣는 거였음. 파서는 이걸 정상 이름으로 인식했고, 우연히 같은 금액의 다른 파트너 매칭 룰에 걸려서 엉뚱한 계정에 입금이 꽂힘. 정산 끝난 다음에 발견되면 되돌리기 진짜 귀찮음.

보낸이 이름이 No Name / 공백 / null 중 하나면 자동 매칭을 끊고 미매칭 입금 큐로 흘려보냄. 운영팀이 수동으로 확인하고 라벨링하는 흐름으로 바꿈.

회고

• 외부 시스템 포맷은 계약이 아니라 관습. 언제든 깨진다고 가정해야 함
• 정규식 의존 로직은 실제 알림 샘플을 픽스처로 박아두고 회귀 돌리는 게 필수. 안 그러면 다음 변경 때 또 똑같이 당함
• 매칭 실패보다 매칭 오류가 훨씬 위험. 애매하면 미매칭 큐로 보내는 보수적 분기가 정답이었음. 잘못된 정산을 되돌리는 비용이 미매칭 큐 손작업보다 훨씬 큼

다음