결제 컷오버 범위 확대, 충전 수수료 로직 재설계
목차
결제 시스템의 P6 단계 적용 범위를 14곳으로 확대하고, 동시에 충전 수수료 계산 로직 5곳을 재설계했다. 한 번에 여러 도메인을 건드리는 작업이었기에 그 의도와 과정을 정리해본다.
단계별 컷오버의 필요성
결제나 환불 같은 핵심 기능은 보통 한 번에 전체 시스템에 적용할 수 없다. 특히 레거시 코드가 섞여 있거나 외부 PG 연동이 여러 개면 더욱 그렇다. 우리의 접근은 P단계(Phase) 라는 단계적 롤아웃 구조를 사용해서, 먼저 작은 범위(P5)에서 검증한 후 점진적으로 확대하는 방식이었다. P6는 그 다음 단계인데, 이번에 14곳을 한 번에 확대한다는 건 꽤 큰 결정이었다.
왜 이런 확대가 필요했나? 결제와 환불은 고객에게 직결되는 거래 기능이라 안정성이 최우선이지만, 동시에 레거시 코드를 오래 유지하는 것도 운영 부담이다. 따라서 안정성과 운영 효율성의 균형을 맞추려면, 충분히 검증된 로직을 더 많은 지점에 빠르게 펼쳐야 한다. 14곳이라는 숫자는 "충분히 커서 임팩트가 있지만, 그래도 전체의 일부"라는 의식적 선택이었을 것 같다.
충전 수수료 재설계의 배경
흥미로운 부분은 컷오버 확대와 함께 충전 수수료 로직을 5곳에서 재설계했다는 것이다. 이건 단순히 "새로운 결제 시스템을 적용하는" 것을 넘어, 기존에 분산되어 있던 수수료 계산 방식을 정리하는 작업이었다.
일반적으로 결제 수수료는 여러 곳에서 다르게 계산되는 경우가 많다. 예를 들어:
- 일부 모듈에서는 결제 직후 즉시 계산
- 일부는 정산 시점에 계산
- 일부는 특정 정책에 따라 예외 처리
이렇게 분산되면 버그의 온상이 되고, 정산 맞춤 시에도 문제가 생긴다. 이번 재설계는 그런 혼재된 로직을 한 곳으로 수렴시키거나, 적어도 일관된 패턴으로 통일하는 것일 가능성이 높다.
변경 파일을 보면 coupon, member, order, partner, pay 등 결제와 관련된 여러 도메인이 함께 변경되었다. 이는 수수료 계산이 단순히 payment 모듈만의 문제가 아니라, 전체 거래 흐름의 여러 곳에서 터치된다는 뜻이다. 따라서 이 재설계는 팀 간 협업과 명확한 요구사항 정의가 필수였을 것이다.
P8 준비와 아키텍처 확장성
흥미롭게도 commit 메시지에 "P8 준비"가 들어있다. 이건 P6 적용과 동시에 이미 다음 단계를 염두에 두고 설계했다는 뜻이다. 실무에서 보면:
- P6 적용 범위 + 수수료 재설계 → 다음 확대를 위한 견고한 기반
- 문서(
jeju-welcome-removal-checklist.md) → 컷오버마다 점검할 표준 절차 정립
이런 식으로 진행하면, P8에서는 새로운 로직 개발이 아니라 기존 패턴 적용만으로도 빠르게 확대할 수 있다.
팀 리딩 관점에서의 교훈
이 작업을 보면서 느낀 점들:
1. 큰 작업은 여러 차원으로 나누기
- 단순히 "결제 시스템 통합" 이 아니라, "범위 확대(14곳)" + "로직 재설계(5곳)" + "다음 단계 준비" 로 나눔
- 각 차원을 독립적으로 추적하고 리뷰할 수 있게 함
2. 안정성과 속도의 트레이드오프
- P단계라는 구조로 단계적 확대 → 버그 발생 시 영향 범위 제한
- 재설계로 기술부채 정리 → 장기적 속도 향상
3. 도메인 간 명확한 인터페이스
- 결제, 회원, 주문, 파트너, 쿠폰이 모두 수수료 로직과 연관
- 이 복잡한 의존성을 어떻게 관리했는지가 성공의 열쇠일 것
이런 규모의 작업은 보통 한두 명이 아니라 팀 전체의 협조와 명확한 피드백 루프가 필요하다. 특히 결제 같은 도메인은 한 군데 실수하면 전체 거래에 영향을 미치기 때문에, 철저한 테스트와 리뷰 프로세스가 뒤따랐을 거다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.