개발 slecs

출금 채널 단순화로 결제 라우터 부채 정리

목차

결제 시스템에서 특정 결제사가 비활성화되면서 그에 맞춘 라우터 로직을 정리했다. 겨우 한 섹션 차단 같지만, 이 작업 뒤에는 다중 PG 지원으로 인한 복잡도 관리와 단계적 마이그레이션이라는 큰 그림이 있다.

웰컴 출금, 왜 지금 차단하는가

결제 산업은 본래 다변화(multi-PG 전략)가 기본이다. 가용성 확보, 거래 실패 시 폴백, 수수료 경쟁 등 여러 이유로 동시에 여러 결제사를 운영한다. 우리도 마찬가지였다. 그런데 웰컴 결제사의 비활성화 결정이 떨어졌다. 아마 계약 종료, 수익성 악화, 아니면 더 나은 대안으로의 전환일 수 있다. 어쨌든 비활성화 시점(2026-06)에 맞춰 코드를 정리해야 했다.

여기서 중요한 건 단순히 차단하는 게 아니라 출금 채널을 KP_PAY로 단일화했다는 점이다. 그러니까:
- 웰컴으로의 출금 요청이 들어와도, 이제는 KP_PAY로 자동 라우팅
- 고객은 출금 선택 인터페이스에서 웰컴을 볼 수 없음
- 백엔드는 웰컴 경로를 완전히 제거하지 않고, 일단 다른 채널로 흘려보냄

이 방식의 장점은 뒤로 빼기(fallback)가 안전하다는 것. 만약 갑자기 KP_PAY에 문제가 생기거나, 마이그레이션 기간 중 문제가 발견되면 빠르게 복원할 여지가 있다.

PgPaymentRouter에서 조건 정리

파일 이름만 봐도 알 수 있다. PgPaymentRouter는 결제 요청이 들어왔을 때 "어느 PG로 보낼 것인가"를 결정하는 핵심 라우터다. 보통 이런 라우터는 이렇게 생겼다:

if (paymentGateway == "WELCOME") {
    return welcomePaymentHandler();
} else if (paymentGateway == "KPPAY") {
    return kpPayHandler();
} else if (paymentGateway == "ANOTHER_PG") {
    return anotherPaymentHandler();
}

이번 작업은 첫 번째 조건(웰컴)을 제거하는 것. 단, 완전히 삭제하지 않고 웰컴 요청이 들어오면 KP_PAY로 강제 라우팅하는 식으로 처리했을 것이다:

if (paymentGateway == "WELCOME") {
    // 웰컴은 비활성, KP_PAY로 변경
    paymentGateway = "KPPAY";
}
// 이후 기존 라우팅 로직 계속

이렇게 하면:
- 웹에서 "웰컴으로 출금 원해"라는 요청이 들어도 시스템이 자동으로 KP_PAY로 변환
- 사용자는 에러를 보지 않고, 자신이 요청한 것처럼 처리됨
- 데이터 로그/통계는 KP_PAY로 기록되어 향후 분석 가능

다중 PG 관리, 여기서 배운 점

결제 영역에서 이런 작업이 반복되는 이유를 생각해보면:

첫째, 라우터 복잡도는 PG 개수에 정비례한다. 3개면 괜찮은데, 5개, 10개 가면 각 조건문, 예외 처리, 테스트 케이스가 기하급수적으로 늘어난다. 하나의 PG를 추가할 때마다 "새 조건 추가 → 기존 조건들과의 상호작용 테스트 → 배포"를 반복해야 한다.

둘째, 기술 부채 누적이 빠르다. 예를 들어 "웰컴은 환불은 지원하지만 부분환불은 안 되고, KP_PAY는 반대"라는 식의 예외 조건들이 쌓인다. 코드 리뷰할 때마다 "어, 이건 왜 웰컴인데 다르게 처리하고 있지?"라는 질문이 반복된다.

셋째, 마이그레이션은 단계적이어야 한다. 비활성화 공지 → 신규 사용자는 다른 채널로 안내 → 기존 사용자는 자동 전환 → 완전 폐기, 이렇게 여러 단계를 거친다. 급하게 한 번에 제거했다가는 고객 불만, 데이터 손실 같은 문제가 터진다. 그래서 이렇게 라우터에서 "웰컴 요청 → KP_PAY로 변환"하는 방식으로 중간 다리를 만드는 것.

팀 관점: "사용자 확정"의 의미

커밋 메시지 끝에 "(사용자 확정)"이라고 명시한 것이 중요하다. 이건 단순 기술 결정이 아니라, 이미 고객/운영팀과 의견을 맞춘 상태라는 신호다.

우리 팀에선 결제 변경 같은 민감한 작업을 할 땐:
1. 운영팀에 비활성화 일정 확인
2. 고객팀과 영향 범위 검토
3. 개발팀에서 기술 방안 제시
4. 모두가 OK 사인한 후에야 구현

이번 작업도 그 프로세스를 거쳤으니, 배포 후 "어? 내 출금이 왜 KP_PAY로 가?" 같은 문의가 와도 대답이 명확하다. "웰컴 비활성화에 따른 예정된 변경입니다" 이렇게.

결국 라우터 한 섹션 차단은 단순한 코드 정리가 아니라, 다중 PG 운영의 복잡도를 관리하고, 기술 부채를 걷어내고, 팀 전체의 결정을 코드로 구현하는 과정이다. 작은 변경 같지만 뒤에는 여러 레이어의 커뮤니케이션과 계획이 있다.

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

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

이어보기

댓글 0

첫 댓글 달아줘.