송금 URL로 은행 자동 판별하는 구조 짜기

캡처된 송금 URL을 어떻게 받을지 고민함

스마트폰에서 연락처 송금을 누르면 은행 앱이 뜨는 게 일반적인데, 우리는 한 칸 앞에 끼어들어야 했음. 사용자가 송금 직전에 URL을 캡처해 넘겨주면, 그걸 보고 어느 은행인지 판별하고 후속 흐름을 잇는 구조.

문제는 은행마다 URL 포맷이 제각각이라는 점.

은행 판별을 어떻게 짰나

처음엔 정규식 한 줄로 끝낼 줄 알았음. 막상 캡처 샘플을 늘어놓으니 결이 다 달랐음.

세 갈래로 나누고, 각 은행을 enum 형태로 묶어 매칭 우선순위를 줬음.

1) host 매칭 → 가장 신뢰도 높음
2) path prefix → host 변경 대비
3) query 시그니처 → 마지막 보루

컨트롤러는 얇게, 유틸은 두껍게

URL 수신 엔드포인트는 문자열 하나 받고, 유틸에 위임하고, 판별 결과 + 정규화된 식별자만 응답하게 함. 컨트롤러에 분기 안 넣고 유틸이 전부 책임지게 함.

• 컨트롤러: 입출력 직렬화만
• 유틸: 정규화, 매칭, 결과 객체 생성
• 테스트: 유틸만 단위테스트로 후려치면 끝

이렇게 갈라두니 새 은행 추가될 때 컨트롤러는 안 건드리고 유틸 안에서만 끝남. 다음에 결제대행사 쪽에서 새 패턴 던져도 흡수 가능한 형태가 됨.

삽질 포인트

• 일부 URL이 표준 스킴이 아니라 앱 전용 스킴으로 떨어져서 URI 파서가 throw함. try-catch로 감싸고 raw string fallback 깔았음.
• URL 인코딩이 뒤섞여 있어서 동일 은행인데 매칭 못한 케이스가 있었음. decode 한 번 거친 뒤 재매칭.
• 파라미터 이름이 같은데 의미 다른 은행이 둘 있었음. host 우선순위 안 깔아뒀으면 오판할 뻔함.

회고

처음엔 "이거 30분컷이지" 했는데 캡처 샘플 모으다가 반나절 갔음. 결국 실데이터 확보가 절반이었고, 코드는 그 다음 정리 작업이었음. 외부 입력 다루는 일은 항상 실데이터 확보가 선행되어야 한다는 걸 다시 체감함.

판별 로직은 단순할수록 좋다는 결론도 같이 얻음. 화려한 정규식 한 방보다 host → path → query 순으로 내려가는 단조로운 사다리가 디버깅하기 편했음.

다음