새 결제 경로 추가, 구 webhook 5개 정리

웰컴 카드 온보딩과 정기 결제 빌링 경로를 지원하면서, 동시에 기존 webhook 5개를 비활성화했다. 결제 플랫폼을 점진적으로 개선하는 과정에서 마주하는 전형적인 마이그레이션 작업이었다.

왜 이 시점에 이 변경을 했나

결제 시스템은 시간이 지나면서 여러 경로가 누적된다. 초기엔 기본 결제만 지원했겠지만, 비즈니스 요구사항이 늘어나면서 신규 카드 타입(웰컴 카드)과 구독 결제(빌링)가 필요해진 거다. 이전엔 이 흐름들을 webhook으로 처리했겠지만, 구 방식이 늘어나고 복잡해지면서 일관된 경로로 통합하려는 의도로 보인다.

특히 중요한 건 이게 단순한 "새 기능 추가"가 아니라, "기존 처리 방식을 재설계하면서 동시에 새 경로를 연결"하는 작업이란 점이다. webhook 5개를 그냥 끄는 게 아니라 대체 로직이 먼저 준비되고, 그 위에 새로운 payment 경로와 wallet 경로를 올렸다는 뜻이다.

파일별 변경이 의미하는 것

PgPaymentRouter가 핵심이다. 요청이 들어오면 카드 종류나 결제 유형에 따라 어느 게이트웨이로 보낼지 결정하는 곳인데, 여기에 "웰컴 카드면 → A경로", "빌링이면 → B경로" 같은 새로운 분기를 추가한 셈이다.

webhook 비활성화가 단순하지 않은 이유

webhook을 비활성화하는 건 간단해 보이지만, 실제론 여러 레이어를 확인해야 한다:

• 이벤트 누락 방지: webhook이 담당하던 결제 완료/실패 이벤트를 누가 처리하나?
• 재시도 로직: 기존 webhook 재시도 메커니즘 대체
• 모니터링: 비활성화된 webhook에 대한 알림 설정
• 데이터 일관성: 과도기에 두 경로가 동시에 움직이진 않나?

이번에 webhook 5개를 동시에 끈 건, 아마 새 경로들이 충분히 검증되었고, 기존 이벤트 처리를 완전히 대체했다는 신호일 것이다. 즉, 단순히 "삭제"한 게 아니라 "더 이상 필요 없음을 확인하고 정리"한 것이다.

팀 리딩 관점에서의 고려사항

비슷한 작업을 여러 번 진행하면서 배운 체크리스트:

1. 대체 로직 검증 기간: webhook 비활성화 전에 새 경로가 충분히 트래픽을 받았나? (보통 1-2주)
2. 모니터링 대시보드: webhook 지표와 새 경로 지표를 함께 추적, 급격한 변화 감시
3. 롤백 계획: 만약 문제 발생 시 webhook을 빠르게 복구할 수 있나?
4. 로그 보관: 비활성화된 webhook의 과거 로그를 어디까지 보관할 것인가?

특히 "jeju Step 2-3" 표기로 봐선 이미 1단계에서 기초를 다졌고, 이제 2-3단계에서 점진적으로 확장 중인 것 같다. 큰 시스템 변경을 한 번에 하지 않고, 단계별로 나누는 건 결제 시스템 같은 민감한 영역에선 필수다.

다음으로 주의할 점

이후 코드리뷰나 결제 경로 추가가 있을 땐:

• 라우팅 로직 테스트: PgPaymentRouter의 모든 분기가 테스트되었나?
• 엣지 케이스: 웰컴 카드인데 빌링이기도 한 경우 같은 특수 상황은?
• 과도기 처리: 혹시 두 경로가 동시에 처리되는 경우 없나?

결제 시스템은 "거의 맞음"이 아니라 "정확함"이 99.9%여야 하는 영역이다. 이번처럼 구 방식을 정리하면서 새 경로를 더할 땐, 그 과정 자체가 곧 팀의 학습 기록이 된다.

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

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

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