결제 플랫폼 전환 완료, 출금·로그 강화

기존 결제 플랫폼에서 새로운 PG로 컷오버하는 작업을 마쳤다. 단순한 결제 모듈 교체가 아니라 파트너 정산, 출금, 잔액 계산, 청구 배치까지 연쇄적으로 영향받는 작업이었기 때문에 여러 모듈을 동시에 수정하고 안정성을 높였다.

왜 컷오버가 복잡한가

결제 시스템은 외부 PG에 의존하는 동시에 내부 모든 금전 흐름의 근간이다. 내부 정책상 한 번에 전환하는 게 맞다 판단했는데, 그 이유는:

• 거래 일관성: 한 거래가 여러 모듈(결제 기록 → 잔액 반영 → 파트너 정산 → 수수료 차감 → 지갑 반영)을 거친다. 중간에 플랫폼이 섞이면 추적이 불가능해진다.
• 정산 복잡도: 매일 배치가 결제 데이터를 읽어 수수료를 계산하고 파트너에게 배분한다. 구형 플랫폼과 신형을 동시에 지원하면 배치 로직이 이중으로 복잡해진다.
• 롤백 비용: 한번 시작하면 되돌아가기 어렵다. 출금 이력, 잔액 정산이 섞여 있으면 "어제로 돌려"라는 게 불가능에 가깝다.

결국 여러 팀과 함께 일정을 맞춰 "이 시점에 전 모듈이 동시에 전환"하는 방식으로 진행하게 됐다.

영향받은 모듈들

변경된 파일 6개 영역을 정리하면:

이렇게 보니 파편화돼 보이지만 실은 하나의 금전 흐름을 6개 지점에서 본 거다. 결제가 일어나면 결제 모듈이 이를 기록하고, 매일 배치가 거래를 읽어 잔액을 계산하고, 파트너 정산 배치가 수수료를 떼고, 출금 시스템이 실제 출금을 처리한다. 어느 한 곳이라도 기존 PG 데이터 형식을 알고 있으면 일관성이 깨진다.

출금·로그 보강의 의미

컷오버 과정에서 출금 안정성과 로그 추적성을 강화했다. 이건 기술적 이유와 운영 이유가 있다:

기술적으로:
- 새 플랫폼은 기존과 다른 응답 형식, 에러 코드, 한도 정책을 가지고 있다.
- 출금 요청이 "승인됐는데 실제로 처리 안 됨" 같은 경계 상황을 어떻게 처리할지 결정해야 한다.
- 이를 위해 출금 상태 머신(요청 → 진행중 → 완료/실패)을 명확히 하고 각 단계에서의 재시도 로직을 정의했다.

운영적으로:
- 컷오버 초기엔 버그가 나올 확률이 높다. "어제는 되고 오늘은 안 되네?"라는 신고가 들어올 때 빠르게 원인을 찾아야 한다.
- 출금 요청 ID, 새 PG의 응답 코드, 내부 상태 변화를 모두 기록하면 사후 분석이 수월하다.
- 파트너나 고객 지원팀이 "내 출금은 왜 안 들어왔나?"라고 물었을 때 로그를 보고 답변할 수 있다.

의사결정: 배치 전환 시점

잔액 배치와 청구 배치는 매일 밤 정해진 시간에 실행되는데, 이들을 언제 전환할지도 중요했다. 우리는:
- T-day 자정 이전 마지막 배치는 기존 플랫폼 데이터로 실행
- T-day 자정 이후 첫 배치부터 새 플랫폼 데이터를 읽도록

이렇게 하면 T-day 전일 잔액과 T-day 다음날 잔액 사이에 "간격"이 생지 않는다(또는 명확히 문서화된 간격이 생긴다).

배운 점

이 작업을 하면서 깨달은 건, 결제 시스템은 생각보다 많은 곳에 영향을 준다는 것. 단순히 "API 엔드포인트를 바꿨다"고 생각했다면 배치 로직 업데이트를 놓쳤을 거고, 그럼 매일 "정산 수치가 안 맞는다"는 민원이 들어왔을 거다.

그래서 컷오버는 "하나의 변경"이 아니라 "여러 팀이 일시에 맞춰 실행하는 조율"이어야 한다. 체크리스트 하나 빠지면 운영 고장이 난다. 이번엔 출금과 로그에 공을 들인 덕분에 그 이후 추적과 디버깅이 훨씬 수월했다.

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

• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →

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