PG사 무중단 전환 경험
운영 중인 이커머스 서비스에서 PG사를 전환하는 마이그레이션을 수행한 경험이다. 결제 데이터의 정합성을 유지하면서 서비스 중단 없이 전환하는 과정의 핵심 포인트를 정리한다.
배경
오너클랜 재직 중 기존 PG사(KsNet)에서 다른 PG사(Toss PG, 페이온 등)로 전환하는 마이그레이션을 담당했다. 이미 거래 이력이 쌓인 운영 서비스에서 PG사를 바꾸는 작업은 단순한 API 교체를 넘어 데이터 정합성, 엣지케이스 대응, 무중단 배포 전략을 모두 고려해야 하는 복잡한 작업이다.
핵심 도전과제
거래 연속성
전환 시점에 진행 중인 결제가 있을 수 있다. 기존 PG사로 시작된 결제는 기존 PG사로 완결되어야 하고, 신규 PG사로 전환된 이후의 결제는 신규 PG사로 처리되어야 한다.
결제 URL 고정 이슈
일부 배포 환경은 partial deployment 구조로 여러 서버 인스턴스가 동시에 구버전과 신버전을 서빙하는 시점이 존재한다. 결제 시작 URL과 결제 완료 콜백 URL이 다른 버전의 서버로 전달되는 엣지케이스가 발생했다.
데이터 정합성
결제 완료 콜백 처리 시 DB에 기록되는 PG사 거래 번호, 승인 번호 등이 PG사별로 스키마가 다르다. 기존 데이터와 신규 데이터의 일관성을 유지해야 한다.
해결 전략
Strangler Fig 패턴 적용
기존 PG사와 신규 PG사를 동시에 운영하는 기간을 두었다.
- 신규 PG사 연동 코드 추가 (기존 코드는 유지)
- 신규 결제는 신규 PG사로 처리
- 기존 환불/취소는 기존 PG사로 계속 처리
- 기존 PG사 관련 결제가 모두 정산 완료되면 코드 제거
결제 상태 기반 라우팅
결제 완료 콜백을 처리할 때 해당 결제가 어느 PG사에서 시작됐는지를 DB에서 조회하여 적절한 핸들러로 라우팅했다.
콜백 수신 → 거래번호로 DB 조회 → PG사 구분 → 해당 PG사 핸들러 실행
버전 무관한 콜백 처리
partial deployment 환경의 URL 이슈를 해결하기 위해, 콜백 처리 로직을 버전에 무관하게 동작하도록 설계했다. 신구 버전 모두 동일한 결제 레코드를 기반으로 처리하여 어느 서버에 콜백이 도달해도 올바르게 처리된다.
핵심 교훈
- 결제는 가장 보수적으로 다루어야 한다: 다운타임을 감수하더라도 데이터 정합성이 우선
- 엣지케이스를 먼저 열거하라: 배포 환경·네트워크 지연·동시 요청 등 모든 케이스를 문서화한 뒤 코드를 작성
- 롤백 계획을 먼저 세워라: 전환 후 이슈 발생 시 즉시 복구할 수 있는 스위치(feature flag)를 사전에 구성
- 모니터링이 없으면 전환하지 말라: 전환 전후 결제 성공률, 에러 로그를 실시간 모니터링할 수 있어야 한다