정산 주문 매칭 로직을 변경 축 기준으로 분리해 누락 추적 속도를 높임

매칭 로직을 다시 봐야 했던 이유

파트너별 정산 화면에서 주문 누락이 보고됐음. 입금 데이터를 받아 주문과 매칭하고, 그 결과로 파트너를 결정한 뒤 계좌를 조회하는 흐름인데, 단계마다 책임이 섞여 있어서 어느 단계에서 어긋난 건지 추적이 오래 걸림.

기존 컨트롤러는 다음을 한꺼번에 하고 있었음:

• 입금 식별자 파싱
• 주문 후보 조회
• 매칭 우선순위 판단
• 매칭된 주문에서 파트너 추출
• 파트너에 묶인 정산 계좌 조회
• 응답 DTO 조립

한 메서드에 분기가 6단 7단까지 들어가니, 새 결제대행사가 붙을 때마다 if 가지가 또 늘어남.

분리 기준을 뭘로 잡았는가

단순히 메서드를 쪼개는 게 아니라, "변경되는 축" 으로 갈랐음.

매칭 결과 → 파트너 → 계좌 순서 자체는 유지. 대신 각 단계가 자기 입력만 받고 자기 출력만 내도록 시그니처를 좁힘.

입금ID → [매칭] → 주문
주문   → [파트너 결정] → 파트너
파트너 → [계좌 조회] → 정산계좌

매칭 우선순위에서 뼈맞은 부분

기존엔 "금액 일치 + 시간대 근접" 을 한 메서드에서 동시에 봤는데, 실제로는 우선순위가 있었음.

1. 가상계좌 식별자 일치 (가장 신뢰도 높음)
2. 입금자명 + 금액 일치
3. 금액 + 시간 윈도우 매칭

이 순서를 명시적으로 코드에 박아두니까 "왜 이게 매칭됐지?" 질문에 답하기 쉬워짐. 이전엔 디버그 로그 켜야 알 수 있었음. 케이스별 테스트도 쪼개기 편해짐.

파트너 결정에서 가정 하나 깨짐

"매칭된 주문 = 단일 파트너" 라는 가정이 깨지는 케이스가 있었음. 환불/재발행으로 동일 입금이 두 파트너에 걸친 이력. 이번 리팩터에선 "최신 활성 주문 기준" 으로 결정하고, 다중 파트너 케이스는 경고 로그 + 운영 확인 큐로 빼둠. 한 번에 다 풀려고 하면 PR 이 끝없이 커짐.

계좌 조회 캐시는 일부러 안 넣음

파트너 → 계좌 매핑은 자주 안 바뀌니까 캐시 유혹이 있었는데, 정산 계좌가 잘못 캐시되면 돈이 엉뚱한 곳으로 감. 이번 범위 밖으로 미루고 호출 빈도 측정만 붙임. 측정 없이 캐시 넣지 않는다는 원칙 유지.

회고

• 메서드 분리보다 "변경 축" 분리가 본질이었음
• 우선순위는 코드 구조로 드러내야 디버깅이 빨라짐
• 한 PR 에서 다 풀려는 욕심 버리고 후속 작업 큐로 넘긴 결정이 결과적으로 머지 속도를 올림

다음