송금 매칭 쿼리에 파트너 식별자 누락으로 인한 오정산 수정

송금 주문 매칭에서 새어나간 필터

이커머스 결제 플랫폼에서 연락처 기반 송금 기능을 만지다가 매칭 로직에 구멍 발견함. 입금 통보가 들어오면 미체결 송금 주문을 찾아 매칭하는데, 파트너 식별자를 조건에 안 넣고 있었음. 다른 파트너의 동일 금액·동일 계좌 주문이 우연히 먼저 잡히면 엉뚱한 곳으로 정산이 흘러가는 시나리오였음. 발견한 순간 등에 식은땀.

어쩌다 이렇게 됐나

원래 단일 파트너 가정으로 짠 코드에 나중에 멀티 파트너가 붙으면서, 누가 빠뜨렸는지 모르게 흘러간 흔한 케이스.

• 초기엔 파트너 1곳, 매칭 키 = (계좌 + 금액 + 상태)
• 파트너 늘어남 → 키는 동일하게 유지
• 격리는 어딘가 상위 레이어에서 해주겠지 라는 암묵적 가정
• 그 "어딘가"는 실재하지 않았음

변경 내용

매칭 SQL과 유틸 양쪽에 파트너 식별자를 강제로 끼워넣음. 호출부도 시그니처 변경 따라 전부 손봐야 했음.

-- 핵심 변경
WHERE account  = :acct
  AND amount   = :amt
  AND status   = 'PENDING'
  AND partner  = :partnerId

검증한 시나리오

• 같은 계좌·금액을 가진 두 파트너 주문이 동시에 PENDING일 때 자기 파트너 것만 잡히는지
• 파트너ID 안 넘기는 호출부 남아있는지 (전수 검색, 없음)
• 입금 통보 페이로드에서 파트너 추론 가능한지 (결제대행사 메타로 역추적 가능)
• 과거 운영 데이터에서 오매칭 흔적 있는지 (다행히 동일 금액 동시 PENDING 충돌 0건, 운빨로 생존)

회고

암묵적 가정이 제일 위험함. "단일 테넌트로 시작 → 멀티 테넌트로 확장"은 언제나 일어나고, 그 과정에서 매칭 키가 알아서 따라붙진 않음. 체크리스트 한 줄 추가해둠 — 새 도메인이 멀티 테넌트 영역에 들어올 때, 모든 매칭/조회 쿼리에 테넌트 키 강제 검사.

그리고 매칭 키 누락 같은 결함은 단위 테스트로 안 잡힘. 시나리오 자체가 "두 파트너가 동시에 같은 상태에 있을 때"라서, 통합 테스트나 픽스처 다수 케이스로만 드러남. 다음에 비슷한 도메인 만질 땐 멀티 파트너 픽스처를 디폴트로 깔고 가야겠음.

다음