결제 오케스트레이션 엔진 직접 구축하기: 멀티 PSP 라우팅과 장애 자동 복구 설계

커머스

결제결제 오케스트레이션PSPPG장애 복구

이 글은 누구를 위한 것인가

  • 특정 PG사에만 의존하다가 장애로 매출 손실을 겪어본 커머스 담당자
  • 결제 성공률을 높이고 싶은 서비스 기획자 및 개발팀
  • 멀티 PG 연동 구조를 고민 중인 결제/백엔드 엔지니어

들어가며

2022년 10월, 국내 주요 PG사 중 하나가 약 4시간 동안 결제 장애를 겪었다. 그 PG사 하나에만 의존하던 쇼핑몰들은 그 시간 동안 단 한 건의 결제도 처리하지 못했다. 블랙프라이데이 시즌에 이런 일이 생긴다면? 상상만 해도 아찔한 상황이다.

결제는 커머스의 심장이다. 상품이 아무리 좋고 UX가 훌륭해도 결제가 안 되면 그 모든 것이 무의미하다. 그런데 의외로 많은 커머스 서비스가 단 하나의 PG사에 모든 결제를 맡기고 있다.

**결제 오케스트레이션(Payment Orchestration)**은 이 문제의 해답이다. 여러 결제 서비스를 동시에 관리하고, 상황에 따라 최적의 결제 경로를 자동으로 선택하는 레이어를 만드는 것이다.

1. 결제 오케스트레이션이란

오케스트라를 생각해보자. 지휘자는 여러 악기 연주자를 조율해 최고의 음악을 만들어낸다. 결제 오케스트레이션도 마찬가지다. 여러 PG사를 지휘자처럼 조율해 최적의 결제 경험을 만든다.

[기존 단일 PG 구조]
고객 결제 요청 → PG사 A → 결제 완료 or 실패
  (PG사 A 장애 시 모든 결제 불가)

[오케스트레이션 구조]
고객 결제 요청 → 오케스트레이션 레이어 → PG사 A (기본)
                                         → PG사 B (장애 시 자동 전환)
                                         → PG사 C (국제 카드)
                                         → 간편결제 (카카오페이/토스페이)

이 중간 레이어가 바로 결제 오케스트레이션 엔진이다.

2. 단일 PG 의존의 실제 리스크

장애 리스크

국내 주요 PG사들도 연간 1~3회 정도의 크고 작은 장애를 경험한다. 글로벌 서비스라면 특정 국가의 결제 인프라 문제, 은행 점검 시간 등도 영향을 미친다.

장애 유형평균 지속 시간비즈니스 영향
PG사 시스템 장애1~4시간해당 시간 결제 전면 불가
카드사 연동 오류30분~2시간특정 카드사 결제 불가
네트워크 불안정간헐적타임아웃 증가, 사용자 재시도
API 변경 미대응무기한특정 기능 오작동

비용 최적화 기회 손실

PG사마다 수수료 구조가 다르다. 거래 금액, 결제 수단, 업종에 따라 최적의 PG사가 달라지는데, 단일 PG만 쓰면 이 최적화 기회를 놓친다.

예를 들어, 신용카드 결제는 A사가 유리하고, 계좌이체는 B사가 더 저렴할 수 있다. 해외 카드는 국내 PG보다 Stripe나 Adyen 같은 글로벌 PG가 승인율이 높다.

3. 결제 라우팅 전략

기본 라우팅 규칙

결제 요청이 들어왔을 때 라우팅 결정 요소:
1. 결제 수단 (신용카드 / 계좌이체 / 간편결제)
2. 카드사 (삼성/현대/KB/신한 등)
3. 거래 금액 (소액/중액/고액)
4. 사용자 국적 (내국인 / 외국인)
5. 시간대 (PG사별 점검 시간 회피)
6. PG사 현재 상태 (실시간 헬스체크 기반)

승인율 최대화 라우팅

같은 카드라도 PG사에 따라 승인율이 다를 수 있다. 특히 해외 발급 카드나 특수한 카드사 조합에서 차이가 크다.

// 라우팅 결정 로직 예시 (의사 코드)
function selectPaymentProvider(request) {
  const { amount, currency, cardIssuer, userCountry } = request;

  // 해외 카드는 글로벌 PG 우선
  if (currency !== 'KRW' || userCountry !== 'KR') {
    return providers.filter(p => p.supportsGlobal);
  }

  // 간편결제는 해당 서비스로
  if (request.method === 'KAKAO_PAY') return [KAKAO_PAY];
  if (request.method === 'TOSS_PAY') return [TOSS_PAYMENTS];

  // 카드 결제: 카드사별 최적 PG 선택
  const preferredProviders = cardIssuerRoutingTable[cardIssuer]
    || defaultProviders;

  // 현재 상태 체크 후 살아있는 PG만 반환
  return preferredProviders.filter(p => healthCheck(p).isHealthy);
}

장애 시 자동 Fallback

핵심은 자동으로 이루어지는 것이다. 운영자가 새벽 2시에 장애를 발견하고 수동으로 전환할 수 없다.

결제 요청
  │
  ▼
PG사 A 시도 ──→ 성공 → 결제 완료
  │ 실패 (타임아웃/오류)
  ▼
PG사 B 재시도 ──→ 성공 → 결제 완료
  │ 실패
  ▼
PG사 C 최후 시도 ──→ 성공 → 결제 완료
  │ 실패
  ▼
결제 실패 안내 (가능한 대안 결제 수단 제안)

단, 재시도는 **멱등성(Idempotency)**이 보장되어야 한다. 같은 결제가 두 번 청구되면 안 되기 때문이다. 각 결제 요청에 고유한 idempotency_key를 부여하면 중복 청구를 방지할 수 있다.

4. 국내 주요 PG사 현황

국내 커머스에서 실질적으로 선택 가능한 주요 PG사와 특징이다.

PG사강점주요 고객사특이사항
토스페이먼츠개발자 친화적 API, 간편결제 강세다수 스타트업토스페이 직연동
KG이니시스업력 및 안정성, 대기업 선호대형 쇼핑몰간편결제 폭넓게 지원
나이스페이높은 승인율, 광범위한 은행 지원다양한 업종에스크로 서비스 강세
카카오페이카카오 생태계, UX 강점모바일 중심 서비스간편결제 전용
네이버페이검색 연동, 구매 리뷰네이버 스마트스토어타 플랫폼 연동 제한
Stripe글로벌 카드 지원, 개발자 경험글로벌 서비스원화 결제도 가능

이상적인 조합 예시: 토스페이먼츠(기본) + KG이니시스(Fallback) + Stripe(해외 카드)

5. 결제 성공률(Approval Rate) 관리

결제 오케스트레이션을 도입해도 지속적으로 모니터링하고 개선하지 않으면 의미가 없다.

핵심 지표

지표계산 방법목표
전체 승인율승인 건수 / 시도 건수95% 이상
PG사별 승인율PG사별 승인/시도개별 모니터링
카드사별 거절 비율카드사별 거절 건수 추적이상 패턴 탐지
Fallback 발동율Fallback 발동 / 전체 결제5% 이하 유지
결제 완료 시간시도부터 완료까지 ms3초 이내

실시간 알림 설정

특정 PG사의 승인율이 갑자기 떨어지면 즉시 알림이 가야 한다.

모니터링 규칙 예시:
- 특정 PG사 1분간 승인율 < 80% → Slack 경고
- 특정 PG사 5분간 승인율 < 60% → 자동 라우팅 비중 조정 + 담당자 호출
- 전체 승인율 < 90% → 즉시 긴급 대응

6. 실무 도입 방법

자체 구축 vs 오케스트레이션 SaaS

모든 팀이 직접 오케스트레이션 레이어를 구축할 수는 없다. 선택지를 보자.

방법장점단점추천 대상
자체 구축완전한 커스터마이징개발/운영 비용 높음연 거래액 500억+
Spreedly멀티 PG 연동 특화추가 비용중대형 커머스
Primer.io노코드 워크플로우국내 PG 지원 제한글로벌 서비스
국내 PG 복수 직연동비용 없음관리 복잡개발팀 있는 스타트업

국내에서 현실적인 시작점은 토스페이먼츠 + 하나 이상의 PG사 직접 연동이다. 토스페이먼츠의 API가 잘 설계되어 있어 Fallback 로직을 직접 구현하기 비교적 쉽다.

맺으며

결제는 커머스에서 가장 돈과 직결되는 기능이면서도, 역설적으로 가장 투자가 소홀한 영역 중 하나다. "지금 잘 되고 있으니까"라는 이유로 단일 PG에 의존하다가, 장애가 터지고 나서야 뒤늦게 대책을 마련하는 팀을 많이 봤다.

결제 오케스트레이션은 단순한 기술 개선이 아니라 비즈니스 연속성(Business Continuity) 투자다. 하루 결제 장애로 잃는 매출이 오케스트레이션 구축 비용보다 크다면, 지금이 바로 시작해야 할 때다.