파트너 정산 계좌 등록의 은행명 파싱 오류와 증권사 무한 로딩 수정

무슨 일이 있었음

파트너 정산용 계좌 등록 흐름에서 은행 응답 파싱이 들쭉날쭉해서 고치는 작업.

같은 은행이라도 응답 페이로드 표기가 케이스마다 달라서 매칭이 깨지는 문제였음. 거기에 한 파트너가 증권사 CMA를 등록하려다 무한 로딩에 빠졌다는 제보까지 들어옴. 핸들러가 증권사를 은행처럼 해석하다가 멍 때리는 동선.

깨졌던 표기 케이스

원인은 단순했음. 비교 직전에 trim/대소문자/괄호 메타를 정리하지 않고 그대로 equals 때리는 핸들러가 셋이나 굴러다님.

적용한 정규화

핸들러 3종에 동일한 정규화 함수를 끼웠음.

String normalize(String raw) {
    if (raw == null) return "";
    return raw.trim()
              .replaceAll("\\(.*?\\)", "")
              .replaceAll("\\s+", "")
              .replaceAll("(?i)bank", "은행")
              .toUpperCase();
}

• 공백 제거: 꼬리/중간 공백 동시 처리
• 괄호 메타: (주), (舊 ...) 같은 부가 문자열 잘라냄
• 영문 BANK 표기: 한글로 통일
• 대소문자: 비교 키 일관성 확보

핸들러마다 자기 식대로 트림하던 코드가 다 떨어져 나갔음. 한 군데서 책임지면 되는 일을 셋이서 따로 해먹고 있었던 셈.

증권사 계좌 차단

증권사 계좌는 애초에 정산 출금 대상이 아닌데 입력단에서 안 걸러져서 핸들러까지 흘러 들어옴.

미지원 응답은 이렇게 끊었음.

{
  "code": "UNSUPPORTED_ACCOUNT_TYPE",
  "message": "정산 출금이 지원되지 않는 계좌입니다"
}

별도 코드로 빼둬야 운영 대시보드에서 카운트가 잡히고, 영업이 사전 안내하기 편함. 일반 검증 실패에 묻혀버리면 추적이 안 됨.

회고

• 같은 책임을 핸들러 N개가 각자 들고 있으면 결국 N군데에서 동시에 깨짐. 공통 유틸로 뽑는 시점이 늦었음
• 외부 응답은 "표기 흔들림"이 디폴트라고 가정하고 매칭 키를 짜야 함. equals 한 줄을 못 믿는 게 맞음
• 입력 검증을 핸들러까지 미루지 말 것. 조기 차단이 항상 옳음

다음