개발 slecs

은행명 표기 불일치로 매일 누락되던 정산 30건 해결

목차

은행명 매칭이 깨진 사연

결제대행사에서 내려주는 은행명 표기가 우리 내부 표준이랑 미묘하게 달라서 정산이 한 건씩 누락되던 이슈. 지역 농축협·새마을 계열에서 특히 자주 터졌음. 같은 은행인데 "새마을", "MG새마을", "새마을금고" 이렇게 세 가지 표기로 들어오는 게 발단.

문제의 코드

기존 매칭이 완전 일치 기반이라 한 글자라도 어긋나면 미매칭 큐로 빠지는 구조. 정산 담당자가 매일 아침 수동으로 30건 정도를 손으로 매핑하고 있었음. 핸들러 한 줄짜리 비교 로직이 사람 시간을 매일 잡아먹고 있었던 셈.

// 기존: 한 글자만 달라도 미매칭
if (incoming.equals(STANDARD_NAME)) { ... }

어떻게 풀었나

세 단계로 정리함.

  • 정규화 우선: 공백·특수문자·접두 브랜드코드 제거 후 비교
  • 별칭 테이블: 자주 들어오는 표기 변형을 사전 매핑
  • 키워드 fallback: 둘 다 안 맞으면 핵심 키워드 부분일치로 마지막 시도
단계 들어온 값 매칭 방식
1 MG 새마을금고 정규화 매칭
2 새마을 별칭 테이블
3 OO새마을지점 키워드 fallback

운영 결과

배포 다음 날부터 미매칭 큐가 하루 평균 30건에서 2~3건으로 떨어졌음. 남은 2~3건은 진짜 오타거나 신설 점포라 수동 처리가 맞는 케이스. 정산팀 업무 시간이 체감으로 30분 이상 줄었다는 피드백.

회고

처음엔 별칭 테이블만 추가하면 끝날 줄 알았는데, 결제대행사가 표기를 또 바꿀 여지가 있어서 정규화 + fallback 까지 같이 넣어야 흔들리지 않음. "한 글자 차이로 매일 30건 누락"이라는 사실 자체가 더 충격이었음. 작은 핸들러 한 줄이 운영 비용을 만들고 있다는 걸 수치로 본 게 이번 수확.

추가로 별칭 테이블은 코드가 아니라 설정으로 분리해 둬서, 다음에 새 표기가 발견되면 배포 없이 운영자가 추가할 수 있게 해놨음. 같은 클래스 다시 안 건드리는 게 목표.

댓글 0

첫 댓글 달아줘.