무통장 입금 미매칭을 주문번호 기준으로 자동 보정

배경

무통장 입금 매칭에서 파트너를 잘못 잡거나 계좌 정보가 비어있는 케이스가 누적됨. 운영팀이 손으로 일일이 보정하던 흐름을 주문 데이터 기준으로 자동화함. 결제 플랫폼 쪽 미매칭 건이 월말마다 쌓여서 더 미룰 수 없었음.

무엇을 바꿨나

주문번호를 키로 파트너 ID 역추적
입금자명·금액 일치 외에 주문 메타데이터로 보강
관리자 화면에서 미매칭 건 일괄 재처리 버튼 추가
보정 이력 남겨서 누가 언제 어떤 키로 매칭했는지 추적 가능

신뢰 우선순위가 핵심이었음. 입금자명은 사람이 바꿔치기 가능 → 주문번호 > 금액+시간 윈도우 > 입금자명 순으로 점수화함.

브라우저 풀 손본 이유

외부 결제대행사 콘솔에서 명세를 긁어와 내부 데이터랑 대조하는 잡(job)이 있는데, 매번 새 컨텍스트 띄우니 느렸음. 풀로 바꿔서 재사용.

이전: 요청마다 launch → close  (느림, 메모리 튐)
이후: 풀에서 borrow → release   (warm context 유지)

영역	전	후
미매칭 보정	수기	주문 기준 자동
외부 콘솔 크롤링	매번 launch	풀 재사용
관리자 조회	풀스캔	인덱스 활용

시행착오

풀 사이즈 크게 잡으니 좀비 컨텍스트가 누적돼서 메모리 야금야금 차오름. idle timeout + max-borrow 두니 안정화.
관리자 쿼리에서 OR 두 개가 인덱스를 안 타서 풀스캔 났음. UNION ALL로 쪼개서 각각 인덱스 태우는 식으로 정리.
보정 로직 첫 버전은 "이름 비슷하면 매칭"으로 짰다가 동명이인 두 건 잘못 묶음. 즉시 롤백하고 주문번호 우선으로 재설계.

회고

결국 "어떤 키를 신뢰하느냐" 싸움이었음. 사람이 입력한 문자열은 못 믿고, 시스템이 부여한 식별자만 신뢰 대상이라는 걸 다시 확인. 자동화의 90%는 알고리즘이 아니라 신뢰 모델 정의라는 생각이 굳어짐. 환불·취소 케이스도 같은 패턴으로 묶을 수 있을 것 같아 다음 스프린트 후보로 적어둠.