판매자 출금이 잘못된 결제사로 전송되던 버그 고침

이번에는 멀티 PG(결제 게이트웨이) 환경에서 출금 처리 시 잘못된 결제사로 라우팅되던 버그를 고쳤다. sysId별로 사용하는 PG가 다른데, 머천트 잔액조회 로직에서 이 분기를 제대로 반영하지 않아서 웰컴(쇼핑몰 플랫폼)의 출금 기능이 재차 깨지는 회귀가 생겼던 것.

멀티 PG 환경의 복잡성

이커머스 플랫폼이 성장하다 보면 여러 결제 게이트웨이(PG)를 동시에 운영하게 된다. 각각의 PG가 제공하는 API, 승인 프로세스, 수수료 정책이 다르기 때문에, 특정 사업 파트너나 지역별로 다른 PG를 할당하는 방식이 흔하다. 이 프로젝트에서도 sysId(시스템 ID)별로 어떤 PG를 사용할지 결정하는 구조를 가지고 있었다.

문제는 이 분기 로직이 모든 플로우에 일관되게 적용되지 않았다는 점이다. 머천트가 출금을 요청할 때의 흐름을 보면:

1. 머천트 잔액 조회 (sysId A PG에 문의)
2. 출금 승인 (sysId B PG에 지시)
3. 정산 처리

각 단계가 같은 PG를 바라봐야 하는데, 중간에 분기가 누락되면 잔액은 한 PG에서 조회했는데 출금 명령은 다른 PG에 가는 혼란이 발생한다. 결과적으로 특정 플랫폼의 판매자가 출금 요청을 했을 때 실패하거나 잘못된 계좌로 송금되는 심각한 문제로 이어진다.

회귀 버그의 원인 분석

이 버그는 단순한 신규 버그가 아니라 회귀(regression)였다. 즉, 과거에 이미 한 번 수정했던 부분이 어떤 이유에선가 다시 깨진 것. 이런 일이 발생하는 이유는 보통 다음 중 하나다:

• 다른 팀의 코드 변경이 실수로 기존 수정을 덮음: PR 머지 과정에서 conflict 해결을 잘못하거나, 같은 코드를 두 브랜치에서 수정했을 때 발생
• 코드 리팩토링 중 edge case를 빠뜨림: 여러 경로로 같은 로직을 호출하도록 개선하면서, 한 경로는 누락
• 테스트 커버리지 부족: 특정 sysId 조합에 대한 테스트가 없어서 미처 발견하지 못함

이번 경우엔 partner, pay, withdrawal, payment 유틸 등 여러 모듈에 걸쳐 출금 처리가 흩어져 있었고, 어딘가 한곳의 sysId 분기가 누락된 상태였을 것으로 보인다.

수정 범위와 전략

변경 파일들을 보면 여러 레이어에 걸쳐 동일한 분기 규칙을 적용했다:

이렇게 여러 레이어에 걸쳐 동일한 규칙을 한 번에 통일하는 것이 핵심이다. 한 곳만 수정하면 또 다른 곳에서 회귀가 생길 가능성이 크다.

회귀 버그를 어떻게 방지할까

내가 이 문제를 겪으면서 느낀 점:

1. 코드 리뷰 때 "이미 본 로직 같은데?" 감각을 살려야 한다. 여러 모듈에서 sysId 분기를 하고 있다면, PR에서 한 곳이라도 누락되면 간과하기 쉽다. 리뷰어가 "partner에선 sysId를 체크했는데 withdrawal에선 했나?" 같은 질문을 던져야 한다.

2. 마스터 클래스(utility)에 이 로직을 한 번만 구현하고, 다른 곳에서 재사용하게 강제한다. payment 유틸 모듈이 그 역할을 할 수 있는데, 정말 모든 web 컨트롤러가 이 유틸의 메서드를 호출하고 있는지 확인해야 한다. 직접 분기 로직을 다시 짜는 코드가 남아있으면 회귀가 생긴다.

3. 멀티 PG 환경에 대한 통합 테스트를 자동화한다. "sysId A일 때 출금을 요청하면 PG X에 가야 하고, sysId B일 때는 PG Y에 가야 한다" 같은 테스트를 CI에 포함시키면, 누군가 실수로 분기를 빼도 바로 걸린다.

4. 회귀 버그의 맥락을 팀과 공유한다. 이 버그를 고치면서 발견한 여러 모듈의 불일치를 모두 같은 PR에 담고, commit 메시지나 코드 주석에 "이 분기는 pay/withdrawal/partner에서 동일하게 적용되어야 함"이라고 명시하면 다음 사람도 주의할 것.

멀티 PG 환경의 복잡성은 피할 수 없지만, 코드 구조와 테스트로 버그의 재발은 충분히 막을 수 있다.

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

• 외장SSD 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 노이즈캔슬링헤드폰 쿠팡에서 보기 →

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