송금 수취인 계좌 오매칭을 파트너 식별자 조회로 해결

파트너 식별자 기반 계좌 조회로 갈아탄 이유

연락처 송금 흐름 손볼 때 가장 거슬렸던 게 수취인 계좌 매칭 로직임. 기존엔 입력값(연락처 + 이름) 조합으로 계좌를 끌어왔는데, 동명이인이거나 같은 번호를 공유하는 파트너가 끼면 엉뚱한 잔액 계좌로 꽂힐 위험이 있었음. 이번에 파트너 식별자(partnerSn)를 1차 키로 잡고 계좌를 조회하도록 갈아엎음.

바뀐 부분 정리

핵심은 폼에서 식별자를 같이 넘기게 한 것. 화면에서 파트너 선택할 때 이미 식별자를 쥐고 있는데도 굳이 텍스트로 다시 매칭한 게 그동안 깨진 부분이었음.

컨트롤러에서 신경 쓴 포인트

• 식별자 누락 요청은 그냥 4xx 로 잘라냄. 과거 호환을 위해 fallback 두려다 "그건 새 결제 라인업에선 안 쓴다"고 결론 내고 제거.
• 유틸 시그니처도 한 줄 갈아끼움.

// before
Account acc = util.findByContact(name, phone);

// after
Account acc = util.findByPartnerSn(partnerSn)
        .orElseThrow(() -> new BizException("INVALID_PARTNER"));

• Optional 강제로 바꾸니 호출부에서 null 체크 빠뜨린 곳 두 군데 잡힘. 보너스.

매퍼/SQL 정리하면서 발견한 것

• 기존 LIKE 쿼리가 인덱스를 못 타고 있었음. 식별자 단일 조건으로 바꾸니 실행계획에서 PK 레인지 한 방.
• 같이 살펴본 김에 안 쓰는 컬럼 join 두 개 끊음. 송금 처리 평균 응답 50ms 이상 줄었음. 측정은 로컬 + 개발 환경 둘 다.

회고 메모

• 데이터 식별자가 이미 있으면 텍스트로 재매칭하지 말 것. 이게 매번 사고 친 패턴이라 이번 기회에 머리에 박았음.
• 폼 hidden 필드는 화면 작업자가 자주 빠뜨리는 부분이라, 컨트롤러에서 누락 시 명시 에러 던지는 쪽이 디버깅 빠름.
• fallback 욕심 줄이기. "혹시 모르니 옛날 방식도..." 가 결국 버그 온상이 됨. 지울 땐 깔끔하게.

다음