결제 송금 알림 메시지 빌더를 분리해 가독성 개선

왜 손댔나

연락처 송금 메시지 유틸이 너무 비대해졌음. 결제 플랫폼에서 파트너끼리 잔액을 옮길 때 알림 문구를 만드는 부분인데, 한 메서드 안에 분기가 켜켜이 쌓여 있었음.

• 송금 성공/실패/대기/취소 4종
• 파트너 등급별 호칭 표기 차이
• 결제대행사 결과코드에 따른 문구 분기
• 다국어 금액 포맷 분기

새 메시지 한 줄 추가하려고 200라인짜리 메서드를 위에서 아래로 다 읽어야 했음. 후배가 PR 리뷰에서 "이거 어디 끼워야 됨?" 물어보길래, 갈아엎기로 함.

어떻게 잘랐나

기준은 단순함. "메시지 종류" 와 "포맷팅" 을 분리. 타입별로 빌더를 따로 두고, 공통 컨텍스트만 주입하도록 바꿈.

[Before]
buildMessage(type, status, partner, result) {
  if (type == "SEND")    { ... 50줄 ... }
  else if (type == "RECV") { ... 50줄 ... }
  else if ...
}

[After]
MessageBuilder.of(type).render(ctx)

삽질 포인트

• 처음엔 enum 안에 템플릿을 다 박으려 했는데, 결제대행사별 결과코드를 상수로 표현하기 어려워서 포기. 빌더로 우회함.
• 금액 포맷이 파트너 지역에 따라 달랐음. 이건 별도 Formatter 로 빼서 빌더가 주입받도록 함.
• 호출부가 30곳 넘어서 한 번에 못 바꿈. 기존 시그니처를 어댑터로 남겨두고 호출부를 한 주에 5~6개씩 점진 전환했음.

회고

리팩터링 자체보다 "왜 200줄이 됐는지" 추적하는 게 더 오래 걸렸음. 커밋 로그 따라가 보니 메시지 한 줄 추가가 2년치 쌓인 결과였음. 처음 짠 사람이 잘못한 게 아니라, 매번 손쉽게 if 한 줄 더 넣을 수 있는 구조가 문제였음.

검증은 단위 테스트로 빌더별 출력 스냅샷을 떠서 비교했고, 스테이징에서 실제 송금 시나리오 4종을 돌렸음. 메시지 문구 자체가 바뀌면 안 되는 작업이라, 디프 0 을 목표로 잡고 끝까지 맞췄음.

다음엔 분기 5개 넘어가는 시점에 미리 잘라낼 것. 끝