입금 계좌 로테이션과 AI 입금자명 자동 매칭 도입

한 계좌만 쓰던 시절의 한계

파트너가 늘어나면서 단일 입금 계좌 구조가 슬슬 깨지기 시작함. 일 거래량이 일정 수준을 넘어가니 은행 쪽에서 거래 패턴을 의심하기도 하고, 한도에 막혀서 오후 늦게 입금이 튕기는 사고도 종종 났음. 파트너 입장에서는 한 번 튕긴 경험이 재충전 의욕을 꺾어버려서, 단순한 운영 이슈로 끝나지 않고 매출 직격타로 돌아왔음.

그래서 이번 스프린트에 파트너별 복수 계좌 로테이션을 도입했음. 동시에 입금자명 매칭에 AI를 끼워 넣었음. 두 기능이 별개처럼 보이지만 실은 한 묶음이라, 같이 풀어야 깔끔하게 떨어졌음.

로테이션 전략 정하기

후보 전략을 깔아두고 비교했음.

결국 잔여 한도 가중치 + 시간대별 폴백으로 갔음. 같은 계좌가 연속 선택되지 않도록 최근 N분 사용 이력을 빼는 쿨다운도 넣었음. 운영자가 특정 계좌를 임시 비활성화할 수 있는 토글도 같이 만들었음. 은행 점검 시간대 버틸 수 있어야 하니까.

• 선택 로직은 한 곳으로 모으고, 컨트롤러는 결과만 받아쓰게 분리함
• 계좌 풀 변경은 캐시 무효화 이벤트로 즉시 반영되게 함
• 로테이션 결정 근거를 로그로 남겨서, 사후에 왜 이 계좌가 뽑혔는지 추적 가능하게 함

입금자명 매칭, 사람 손에서 떼어내기

기존에는 입금자명이 주문자명과 다를 때(가족 명의, 회사 명의, 별명, 오타) 운영자가 눈으로 보고 매칭했음. 하루 수천 건 쌓이면 누가 봐도 지속 가능한 구조가 아님.

입력: 김민수 / 입금자: 김민쑤
입력: ㈜더블유에이 / 입금자: 더블유에이
입력: 이정훈(부) / 입금자: 이정훈

규칙 기반으로는 이런 변형을 다 못 잡음. 그래서 LLM에게 후보 주문 N개와 입금 메시지 1건을 던져서 가장 그럴듯한 매칭 + 확신도를 받아오게 했음. 확신도 임계치 위는 자동 매칭, 아래는 운영자 큐로 보냈음.

설계할 때 중요했던 포인트:

• 결정론적 규칙을 먼저 통과시키고, 남은 모호한 건만 LLM으로 보냄. 비용도 줄고 응답 시간도 줄음
• 프롬프트에 입금 시각·금액 일치 여부를 같이 넣어줘야 환각이 줄어듬
• 매칭 결과는 항상 사람이 되돌릴 수 있게 보존. AI가 틀렸을 때 원복 비용이 곧 신뢰도임

배포 후 며칠

자동 매칭률이 운영 큐 도착 기준으로 70%대 후반까지 올라왔음. 처음 며칠은 임계치를 보수적으로 잡고 운영자 피드백으로 천천히 올렸음. 로테이션 쪽은 한도 막힘이 거의 사라졌고, 특정 계좌에 이상 거래로 의심되는 패턴이 잡혔을 때 그 계좌만 잠시 빼고 돌릴 수 있어서 운영팀 만족도가 올라감.

남은 숙제는 LLM 비용 곡선을 어디서 꺾을지, 그리고 매칭 실패 케이스를 학습 데이터로 다시 환류시키는 파이프라인 정도. 다음