입금 통보 파서에 AI 검증 얹어 정산 수기 보정 60% 줄임

배경

이커머스 결제 플랫폼에서 파트너별 입금 통보 메시지를 수신해 자동 매칭하는 기능이 있었음. 문제는 결제대행사·은행마다 포맷이 제각각이라 정규식이 폭발적으로 늘어났다는 것.

기존 파서는 새 포맷 하나 추가될 때마다 분기 로직이 누더기처럼 붙음. 입금자명 한 글자 누락되면 매칭 실패했고, 그게 누락 데이터로 쌓여서 운영팀이 매일 수기 보정함.

구조 변경

핸들러 레지스트리 패턴으로 정리함. 은행/결제대행사 식별자로 적합한 파서를 골라내고, 공통 추상 계층에서 검증·정규화·로깅을 처리하게 분리.

이 분리만으로도 신규 은행 추가가 30분짜리 작업이 됐음. 기존엔 반나절이었는데.

AI 검증 레이어

진짜 핵심은 여기. 정규식이 통과해도 의미가 깨진 케이스(예: 입금자명 자리에 광고 문구가 섞임)를 잡으려고 LLM 검증을 끼움.

• 1차: 룰 기반 추출 → 후보 필드 도출
• 2차: AI가 원문 + 후보를 받아 "이 필드가 실제 입금자/금액/시각이 맞는가" 판정
• 3차: 신뢰도 임계값 미달이면 보류 큐로

처음엔 모든 메시지를 AI로 보내려 했는데 비용·지연 때문에 1차 룰이 통과한 케이스만 검증으로 돌리는 게 맞다고 결론냈음. 룰이 못 잡은 건 어차피 재처리 큐 행이라.

부수 효과

• 운영팀 수기 보정 건수가 직전 주 대비 60%대로 감소
• 신규 포맷 대응 PR 사이즈가 평균 3배 작아짐
• 파서 단위 테스트 커버리지가 올라감 (공통 로직 분리 덕)

회고

핸들러 분리는 진작 했어야 했음. AI 검증을 먼저 넣었으면 정규식 누더기 위에 또 누더기가 쌓였을 거고, 룰부터 정리한 뒤 AI를 위에 얹은 게 순서로 맞았다.

LLM을 "최후의 검증자"로 쓰는 건 비용 통제만 잘하면 꽤 강력함. 다만 응답 포맷을 강제하지 않으면 파싱 자체가 또 다른 정규식 지옥이 되니 스키마는 처음부터 못 박을 것. 그리고 모든 케이스를 AI로 흘리고 싶은 욕망은 처음부터 차단해야 함 — 룰이 잡을 수 있는 건 룰이 잡게 두는 게 운영비 측면에서 정답.

다음