은행명 표기 불일치로 매일 누락되던 정산 30건 해결
목차
은행명 매칭이 깨진 사연
결제대행사에서 내려주는 은행명 표기가 우리 내부 표준이랑 미묘하게 달라서 정산이 한 건씩 누락되던 이슈. 지역 농축협·새마을 계열에서 특히 자주 터졌음. 같은 은행인데 "새마을", "MG새마을", "새마을금고" 이렇게 세 가지 표기로 들어오는 게 발단.
문제의 코드
기존 매칭이 완전 일치 기반이라 한 글자라도 어긋나면 미매칭 큐로 빠지는 구조. 정산 담당자가 매일 아침 수동으로 30건 정도를 손으로 매핑하고 있었음. 핸들러 한 줄짜리 비교 로직이 사람 시간을 매일 잡아먹고 있었던 셈.
// 기존: 한 글자만 달라도 미매칭
if (incoming.equals(STANDARD_NAME)) { ... }
어떻게 풀었나
세 단계로 정리함.
- 정규화 우선: 공백·특수문자·접두 브랜드코드 제거 후 비교
- 별칭 테이블: 자주 들어오는 표기 변형을 사전 매핑
- 키워드 fallback: 둘 다 안 맞으면 핵심 키워드 부분일치로 마지막 시도
| 단계 | 들어온 값 | 매칭 방식 |
|---|---|---|
| 1 | MG 새마을금고 |
정규화 매칭 |
| 2 | 새마을 |
별칭 테이블 |
| 3 | OO새마을지점 |
키워드 fallback |
운영 결과
배포 다음 날부터 미매칭 큐가 하루 평균 30건에서 2~3건으로 떨어졌음. 남은 2~3건은 진짜 오타거나 신설 점포라 수동 처리가 맞는 케이스. 정산팀 업무 시간이 체감으로 30분 이상 줄었다는 피드백.
회고
처음엔 별칭 테이블만 추가하면 끝날 줄 알았는데, 결제대행사가 표기를 또 바꿀 여지가 있어서 정규화 + fallback 까지 같이 넣어야 흔들리지 않음. "한 글자 차이로 매일 30건 누락"이라는 사실 자체가 더 충격이었음. 작은 핸들러 한 줄이 운영 비용을 만들고 있다는 걸 수치로 본 게 이번 수확.
추가로 별칭 테이블은 코드가 아니라 설정으로 분리해 둬서, 다음에 새 표기가 발견되면 배포 없이 운영자가 추가할 수 있게 해놨음. 같은 클래스 다시 안 건드리는 게 목표.
끝
댓글 0
첫 댓글 달아줘.