입금 유틸을 은행별 전용 핸들러로 분리해 확장성 개선

왜 손댔나

공용 입금 유틸 한 파일에 모든 은행 HTTP 호출이 쌓여있었음. 새 은행 붙일 때마다 같은 파일 열어서 if 분기 추가하는 구조. 이번엔 한 은행 케이스를 전용 핸들러로 떼어냈음.

변경 요약

핵심은 공통 인터페이스 하나 깔고, 한 은행만 먼저 옮긴 점. 한꺼번에 다 옮기면 PR 리뷰가 죽음.

옮긴 모양 (의사코드)

// before
if (bankCode == "특정은행") {
    val res = httpClient.post(...)
    // 파싱 로직 30줄
}

// after
val handler = bankHandlerFactory.resolve(bankCode)
handler.deposit(request)

호출부는 두 줄로 끝남. 전용 핸들러 안에서 HTTP 송신, 인증 헤더 구성, 응답 파싱까지 다 책임짐.

작업 중 걸린 것

• 기존 유틸 시그니처를 그대로 둬야 했음. 호출하는 쪽이 너무 많아 한 번에 못 갈아엎음 → 어댑터 한 겹 추가
• 응답 코드 매핑 테이블이 유틸 상수로 박혀있었음. 일단 핸들러로 복사만 해두고 통합은 다음 PR로 미룸
• 핸들러 등록 방식 고민: 자동 스캔 vs 수동 등록. 범위 욕심 안 내고 수동 유지로 결정함

회고

• 좋았던 점: 새 은행 추가할 때 공용 파일 안 건드려도 됨. diff 깔끔해짐
• 아쉬운 점: 응답 파싱 공통 부분이 아직 핸들러마다 중복. 추상클래스로 끌어올리는 게 다음 단계
• 배운 점: 리팩터링은 한 케이스 먼저 옮기고 검증한 다음 나머지 따라오게 하는 게 안전함. 한꺼번에 옮기려다 롤백한 경험이 또 떠올랐음

다음 PR에서 두 번째 은행 옮기면서 응답 파싱 공통화까지 같이 손볼 예정.

다음