개발 slecs

결제 어댑터의 임시 시스템 식별자 상수를 세 도메인에서 완전 제거

목차

결제 어댑터 레이어를 손봤다. Facade 진입점 정비, 유틸 분리, 그리고 오랫동안 임시방편으로 남아 있던 FALLBACK_SYS_ID를 진짜로 제거한 작업이다.


배경: "임시"가 코드에 남는 이유

FALLBACK_SYS_ID는 처음 결제 어댑터를 붙일 때 시스템 식별자가 확정되지 않은 상태에서 급하게 끼워 넣은 상수였다. 당시에는 "일단 돌아가게 하고 나중에 치우자"는 판단이었는데, 그 '나중'이 꽤 길어졌다. 이런 코드는 묘하게 건드리기 무서운 존재가 된다. 직접 참조하는 곳이 여러 레이어에 퍼져 있고, 누군가 그게 진짜 운영 값인지 임시 값인지 확신하지 못해서 손을 못 댄다. 팀원한테 "이거 그냥 지워도 돼요?"라는 질문을 두 번 받고 나서 이번에 결단했다.

실제로 삭제 전에 FALLBACK_SYS_ID를 참조하는 지점을 전수 확인했다. charge, order, payment 세 도메인 패키지의 web 레이어가 각각 이 값을 직접 혹은 간접으로 사용하고 있었다. 그게 이번 변경 파일 목록이 여러 패키지에 걸쳐 나타난 이유다.


작업 내용

크게 세 가지를 한 커밋에 묶었다.

1. Facade 진입점 보강

payment/web 쪽 Facade 역할을 하는 클래스가 있었는데, 외부 요청이 들어오는 경로가 두 갈래로 흩어져 있었다. 하나는 Facade를 통하고, 다른 하나는 내부 서비스를 직접 찌르는 구조. 이 상태에서는 공통 처리(로깅, 예외 핸들링, 트랜잭션 경계)가 한쪽에만 적용되고 다른 쪽은 빠지는 사고가 날 수 있다. 진입점을 Facade 하나로 통일해서 "결제 관련 외부 요청은 반드시 이 문을 통한다"는 규칙을 코드 레벨에서 강제했다.

2. WelcomePayUtil 분리

결제 PG 연동에 특화된 유틸 로직이 payment web 클래스 안에 섞여 있었다. 파라미터 변환, 응답 파싱, 특정 PG 방식의 해시 검증 같은 것들. 이걸 utl/payment 패키지 아래 WelcomePayUtil로 뽑아냈다. 분리 기준은 단순했다: "이 로직이 HTTP 레이어에 알 필요가 있나?" 없으면 다 유틸로 내려보냈다.

// Before: web 레이어 안에 파묻혀 있던 로직
private String buildHashKey(String orderId, String amount) {
    return DigestUtils.md5Hex(orderId + "|" + amount + "|" + FALLBACK_SYS_ID);
}

// After: WelcomePayUtil 로 분리, sysId 주입 방식으로 변경
public static String buildHashKey(String orderId, String amount, String sysId) {
    return DigestUtils.md5Hex(orderId + "|" + amount + "|" + sysId);
}

FALLBACK_SYS_ID 제거가 유틸 분리와 맞물린 이유가 여기 있다. 하드코딩된 fallback 값을 없애려면 호출 시점에 sysId를 명시적으로 넘겨야 했고, 그러려면 책임 분리가 먼저였다.

3. FALLBACK_SYS_ID 진짜 제거

커밋 메시지에 "진짜"를 붙인 건 이전에 한 번 제거 시도가 실패했기 때문이다. 그때는 order 쪽 참조를 미처 못 찾아서 롤백했다. 이번엔 IDE 전역 검색 + 컴파일 에러로 두 번 확인했다.

도메인 변경 내용
charge/web FALLBACK_SYS_ID 참조 제거, 설정값 직접 주입으로 교체
order/web 동일. 주문 생성 시 sysId 획득 경로 명시
payment/web (Facade) 진입점 통합, WelcomePayUtil 호출로 대체
payment/web (기타) 직접 참조 제거, Facade 경유로 변경
utl/payment WelcomePayUtil 신규 생성

회고

이번 작업에서 팀장 입장으로 가장 신경 쓴 건 "이 변경이 리뷰어 입장에서 따라갈 수 있는 크기인가"였다. 세 작업을 한 커밋에 묶은 게 부담이 될 수 있다. 다만 FALLBACK_SYS_ID 제거 ↔ WelcomePayUtil 분리 ↔ Facade 정리가 서로 맞물려 있어서 쪼개면 오히려 중간 상태가 더 이상한 코드가 됐다. 이런 경우엔 커밋을 합치되 PR 설명에 변경 순서를 명확히 써두는 걸 습관처럼 하고 있다.

임시 상수 하나가 3개 도메인 web 레이어에 자국을 남기고 있었다는 게, 초기 설계 결정이 얼마나 넓게 번지는지를 다시 확인시켜줬다. 다음 번엔 fallback 값이 생기는 순간 TODO 티켓을 바로 같이 만들어두는 쪽으로 팀 컨벤션을 정비할 생각이다.

끝.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.