결제 매칭과 파트너 귀속 로직을 단계별로 분리해 동명이인 버그 해결

시작점

주문 매칭과 파트너 결정 로직이 한 유틸 안에 뒤엉켜 있었음. 입금 들어오면 어떤 주문에 매칭할지, 그 주문이 어떤 파트너 소속인지, 수수료를 누가 부담하는지 한 메서드 안에서 다 처리했음. 이번 리팩토링은 이걸 떼어내는 작업.

기존 흐름에서 가장 골치 아팠던 부분:

• 매칭 후보가 여러 개일 때 우선순위 결정 분기가 6단계 넘게 중첩
• 파트너 결정 로직이 매칭 로직 중간에 끼어들어가 있어 단위 테스트 분리 불가
• 동명이인·동일 금액 케이스에서 잘못된 파트너로 귀속되는 버그가 간헐적으로 발생

분리한 책임

매칭과 파트너 결정을 독립 단계로 쪼갰음.

이렇게 끊고 나니 각 단계를 별도로 테스트 가능해졌음. 특히 우선순위 정렬은 순수 함수로 떨어졌고, 파트너 결정은 계층 구조 조회만 남아서 모킹 부담이 확 줄었음.

이전: 입금 → [매칭 + 정렬 + 파트너 + 수수료] 한 덩어리
이후: 입금 → 매칭 → 정렬 → 파트너 → 수수료(별도 단계)

회고 포인트

• 버그 고치기 전에 구조부터 바꾼 게 정답이었음. 처음엔 동명이인 케이스만 핀포인트로 패치하려 했는데 분기 추가할 자리가 마땅치 않았음. 결국 분리 안 하면 또 새 버그 생길 구조였음.
• 표로 정리하니 빠진 케이스가 보였음. 매칭·정렬·귀속을 표로 그려보고 나서 "환불 후 재입금 케이스에서 정렬 기준이 모호하다"는 걸 발견. 코드만 보고 있을 땐 안 보였던 구멍.
• 파트너 결정에서 상위 계층 마진 계산을 분리한 게 컸음. 수수료 차액이 상위 에이전트 수익으로 가는 구조라 매칭 단계랑 섞여 있으면 영원히 못 풀 뻔했음. 매칭은 "어떤 주문인가"만 답하고, 귀속·마진은 그 뒤 단계에서 처리하는 게 자연스러움.

다음에 또 만나면

• 후보 정렬 우선순위를 코드가 아닌 설정 테이블로 빼고 싶음. 영업 정책 바뀔 때마다 코드 푸시하는 건 비효율적.
• 매칭 실패 사유의 코드화. 지금은 "매칭 안 됨"으로 뭉뚱그려져 있어서 운영팀이 원인을 못 봄. 사유 enum 만 추가해도 운영 문의가 절반은 줄 듯.
• 정렬 단계 입력·출력에 스냅샷 테스트를 박아두기. 후일 누가 분기 끼워넣어도 회귀가 즉시 잡히게.

다음