작성자: 아왕, 웹3 변호사

디지털 결제는 보편화되었지만, 결제 시스템은 아직 보편화되지 않았습니다.

이는 비자 전 임원이자 빔(Beam)의 창립자인 댄 모티스의 평가입니다. 비자 거래는 전 세계 모든 가맹점에서 승인되지만, 실제 결제 과정은 여전히 ​​SWIFT를 통해 이루어집니다. 대량 거래를 취합하고, 국경 간 송금을 통해 자금을 이체하고, 현지 규정, 공휴일, 여러 중개 은행을 거친 후, 가맹점은 대금을 수령하기까지 기다려야 합니다. 이는 비자만의 문제가 아니라 업계 전반에 걸친 구조적 결함입니다. 특히 개인 지원 서비스(PSP) 분야에서 이러한 결함이 가장 두드러지게 나타납니다.

이 글에서는 단순한 결제 수단에서 자금 흐름, 결제 및 회계를 관리하는 핵심 인프라 계층으로 발전한 결제 서비스 제공업체(PSP)에 대해 살펴봅니다. PSP는 원래 단일 트랙 시스템, 선형적인 거래 프로세스, 고도로 통합된 인프라와 같은 단순한 시대를 위해 설계되었습니다.

현대 결제 환경에서 "결제"는 더 이상 단일 거래가 아니라 여러 참여자와 결제 경로를 거치는 일련의 상태 변화를 의미합니다. 오늘날 결제에는 소비자 애플리케이션, 결제 서비스 제공업체(PSP), 사기 방지/신원 확인 서비스 제공업체, 수탁 은행, 하나 이상의 결제 경로, 그리고 기업의 내부 회계 시스템이 포함될 수 있습니다.

기업은 은행 카드, ACH, 송금, RTP, FedNow, 그리고 점점 더 중요해지는 스테이블코인 기반 결제까지 동시에 지원해야 합니다. 각 결제 방식마다 결제 시간, 오류 발생 가능성, 데이터 형식, 운영 요구 사항이 다릅니다.

이 글은 Modern Treasury의 가이드를 종합한 것으로, 결제 서비스 제공업체(PSP)의 발전 과정, 현대 결제 시스템에 맞춰 PSP의 기본 아키텍처를 어떻게 조정해야 하는지, 그리고 결제 제품 개발팀이 차기 PSP를 선택할 때 어떤 전략을 채택해야 하는지를 살펴봅니다.

핵심 판단

01 | 디지털 결제는 주류로 자리 잡았지만, 결제 시스템은 아직 정착되지 않았습니다. 비자는 전 세계 모든 가맹점에서 거래를 승인할 수 있도록 지원하지만, 실제 결제는 여전히 SWIFT 시스템을 통해 이루어집니다. 인터페이스는 개선되었지만, 근본적인 메커니즘은 여전히 ​​미해결 상태입니다.

02 | PSP는 결제를 실행하지만 자금 흐름을 설명하지는 않습니다. Stripe는 당시 발생한 상황은 알려주지만 현재 자금의 정확한 상태는 알 수 없습니다. 실행 계층과 기록 계층은 서로 다른 두 가지입니다.

03 | 각 결제 경로는 동일 모델의 변형이 아니라 독립적인 운영 체제입니다. ACH는 취소할 수 있지만 RTP는 취소할 수 없습니다. 카드 네트워크는 분쟁의 대상이 될 수 있지만 스테이블코인은 온체인에서 최종 확정됩니다. PSP의 추상화 계층은 이러한 차이점을 숨기지만, 문제가 발생하기 전까지만 그렇습니다.

04 | 실시간 결제는 버퍼를 없애고 통제권을 상류로 이동시켜야 합니다. 기존 결제 서비스 제공업체(PSP)의 위험 관리, 승인 및 조정 로직은 모두 "오류를 수정할 시간이 있다"는 가정을 전제로 합니다. RTP와 FedNow는 이러한 가정을 없애줍니다. 자금이 이동하기 전에 결정을 내려야 하며, 이동 후에 결정해서는 안 됩니다.

05 | 스테이블코인은 새로운 결제 수단이 아니라 결제 경로입니다. 스테이블코인은 결제 인터페이스 문제를 해결하는 것이 아니라, "회계 처리 완료"와 "실제 자금 입금" 사이의 시간 지연을 해소하는 것입니다. 가장 실용적인 구현 방식은 샌드위치 구조입니다. 즉, 법정화폐가 입력되고, 온체인에서 유통되고, 법정화폐가 출금되는 방식이며, 양쪽 끝의 사용자는 스테이블코인을 이해할 필요가 없습니다.

06 | 자금 이동 중에도 수익을 창출할 수 있는데, 이는 기존 시스템에서는 거의 불가능한 일입니다. 국경 간 결제에서 자금은 정산이 완료되기 전까지 24시간에서 72시간 동안 묶여 있어 수익이 발생하지 않고 운전자본이 묶이게 됩니다. 스테이블코인은 이러한 "자금 이동 중"에 가치를 창출할 수 있도록 하는 최초의 기술입니다.

07 | 결제 운영에서 가장 큰 실패 요인은 바로 이 간단한 질문에 답할 수 없다는 것입니다. "이 돈은 어디로 갔을까?" 대조, 이상치 처리, 유동성 관리 등은 결제가 시작될 때가 아니라 그 후에 발생하는 문제입니다. 통합된 조정 체계가 없다면 각 서비스 제공업체는 자기들이 알고 있는 정보만 제공할 수밖에 없습니다.

08 | 진정한 전략적 위험은 스테이블코인을 사용하느냐 마느냐에 있는 것이 아닙니다. 경쟁사들은 스테이블코인을 활용하여 결제 비용과 자본 효율성을 재조정하고 있는데, 당신은 여전히 ​​완벽한 진입 시점을 기다리고 있다는 점입니다.

I. PSP의 역사적 발전 과정

지난 20년 동안 PSP의 역할은 근본적인 변화를 겪었습니다.

전자상거래 초기에는 PSP(결제 서비스 제공업체)가 주로 결제 게이트웨이 역할을 했습니다. 그들의 역할은 간단하고 명확했습니다. 가맹점을 카드 네트워크 및 매입 은행에 연결하여 거래 승인 및 정산을 가능하게 하는 것이었습니다.

이러한 PSP 시스템은 매우 특정한 환경에 맞춰 설계되었습니다. 결제는 주로 카드 기반으로 이루어지며, 단일 가맹점 계정을 통해 처리되고 승인부터 정산까지 선형적인 과정을 따릅니다. PSP는 이러한 모델 내에서 거래를 효율적으로 처리하도록 최적화되어 있습니다.

2010년대에 들어서면서 마켓플레이스, SaaS 플랫폼, 핀테크 제품들은 결제 기능을 자사 서비스에 직접 통합하기 시작했습니다. 플랫폼들은 사용자 등록, 여러 당사자 간의 결제 분할, 자금 이체 관리 등을 처리해야 했습니다. 이에 따라 결제 서비스 제공업체(PSP)들도 사업을 확장하여 가맹점 등록, 결제 인프라 구축, 사기 방지 도구 등을 도입했습니다.

하지만 PSP의 기능이 끊임없이 확장되고 있음에도 불구하고, 그 기본 아키텍처는 여전히 선형 결제 프로세스를 위해 설계된 모델에 기반을 두고 있습니다. 즉, 서비스 제공업체와 경로 전반에 걸쳐 복잡하고 다단계적인 자금 이동을 조정하기보다는 주로 거래 처리에 최적화되어 있습니다.

2020년대 초에 이르러 기업들은 다양한 경로, 지역 및 시나리오에 걸쳐 사업을 운영하기 시작했습니다. 기존의 결제 서비스 제공업체(PSP)들은 여러 구성 요소를 묶어 기업들이 단일 플랫폼에서 상호 작용할 수 있도록 지원했습니다. 그러나 결제 프로세스가 더욱 복잡해짐에 따라, 단일 결제 프로세스에는 신원 확인, 위험 평가, 자금 조달 결정, 경로 실행 및 내부 추적과 같은 여러 단계가 포함될 수 있었습니다.

이러한 변화로 PSP의 역할은 "연결자"에서 "조정자"로 바뀌었지만, 그 아키텍처는 같은 속도로 진화하지 않았습니다.

결과적으로 PSP는 여전히 자금 이체를 담당하지만, 전체 거래 결제 주기를 포괄하는 더욱 복잡한 환경 내에서 운영됩니다.

II. 최신 PSP 결제 기술 스택

PSP의 한계를 이해하려면 먼저 PSP가 존재하는 더 넓은 결제 환경을 이해해야 합니다.

2.1 PSP 기술 스택

현대의 결제 환경은 단일 플랫폼이나 서비스 제공업체가 아니라, 자금의 이동, 정산 및 회계를 지원하기 위해 함께 작동하는 계층화된 인프라 구성 요소 세트입니다.

응용 분야: 결제가 시작되는 전자상거래 플랫폼, 마켓플레이스, 핀테크 앱 및 결제 기능이 내장된 SaaS 제품.

PSP(결제 서비스 제공업체) 계층은 카드 네트워크로 거래를 라우팅하고, 은행 송금을 시작하고, 결제 경로에 연결하는 등 결제 지침을 실행하는 역할을 담당합니다. 대부분의 경우 이러한 복잡한 과정은 PSP 인터페이스 뒤에 추상화되어 있어 사용자는 여러 서비스 제공업체와 직접 거래하는 대신 단일 시스템과 상호 작용할 수 있습니다.

규정 준수 계층: 최신 결제 프로세스는 결제 진행 여부를 결정하는 신원 확인 서비스 제공업체, 사기 탐지 도구 및 규정 준수 인프라에 의존합니다.

은행 부문에서는 수탁 은행이 자금을 보유하고, 규제 대상 계좌를 제공하며, ACH, 송금, RTP, FedNow와 같은 결제 네트워크에 대한 접근을 지원합니다.

내부 대조 계층: 기업에서 잔액을 추적하고, 거래 상태를 표시하며, 재무 활동에 대한 일관된 기록을 유지하는 데 사용하는 시스템입니다.

이러한 각 단계는 자금 이동에 관여하지만, 어느 단계도 지급이 시작된 후 실제로 무슨 일이 일어나는지 완벽하게 보여주지는 못합니다. 바로 이러한 이유 때문에 내부 정산 단계가 필수불가결해지는 것입니다.

2.2 동기식 및 비동기식

기존 PSP는 근본적인 설계 결함이 있었습니다. 돈을 보내는 것 자체에만 집중하고 그 이후의 상황에는 전혀 신경 쓰지 않았습니다.

문제는 "발송된 후"가 바로 결제 과정에서 가장 복잡한 부분이라는 점입니다.

PSP의 API 인터페이스 로직은 동기식입니다. 명령을 보내면 결과가 반환됩니다. 그러나 실제 자금 흐름은 비동기식입니다. 결제는 나중에 완료되고, 오류는 지연 후에야 드러나며, 환불 및 거래 취소는 언제든지 취소할 수 있습니다. 이러한 불일치로 인해 지속적인 정보 공백이 발생합니다.

블랙홀의 구체적인 발현 양상은 그 상태의 분열입니다.

어느 한 시점만으로는 이 돈의 현재 상태를 정확히 알 수 없습니다.

마켓플레이스 플랫폼에서 판매자의 출금을 예로 들면, 전체 과정은 자격 검증 → 위험 관리 및 규정 준수 → 자금 확인 → 지시 발행 → 거래 실행 → 확인 수신 → 거래 후 정산 → 원장 업데이트라는 긴 사슬로 이루어져 있습니다. PSP(결제 서비스 제공업체)는 이러한 중간 단계 중 일부만 담당하며, 초기 의사 결정 및 후속 정산은 PSP의 책임 범위에 포함되지 않습니다. 따라서 결제가 실패하거나 반환되는 경우, 단일 시스템으로는 완벽한 해결책을 제시할 수 없습니다.

이것이 바로 내부 정산 계층의 중요성입니다. 내부 정산 계층은 결제 실행에서 PSP(결제 서비스 제공업체)를 대체하는 것이 아니라, 전체 체인 위에 통합된 관찰 계층을 구축하여 서로 다른 서비스 제공업체에서 서로 다른 시점과 형식으로 발생하는 비동기 이벤트를 기업 내부의 단일하고 신뢰할 수 있는 상태로 지속적으로 변환합니다. 자금이 아무리 많은 중간 단계를 거치더라도, 가장 근본적인 질문인 "이 돈은 지금 어디에 있는가?"에 대한 답을 항상 찾을 수 있는 곳이 존재합니다.

III. 기존 결제 서비스 제공업체의 지불 제한 사항

기존 결제 서비스 제공업체(PSP)의 추상화 계층은 은행 카드 결제(승인, 캡처, 정산)를 중심으로 구축되어 예측 가능한 라이프사이클을 따릅니다. 분쟁이나 차지백과 같은 예외적인 상황이 발생하기도 하지만, 전체적인 구조는 예측 가능하고 잘 이해되고 있습니다. 이러한 모델이 PSP 설계 방식의 기반이 됩니다.

새로운 결제 방식이 등장함에 따라 PSP는 더 많은 결제 수단을 지원할 예정이지만, 이러한 결제 수단은 은행 카드와는 다른 방식으로 작동하며 동일한 전제 조건을 따르지 않습니다.

• ACH 이체: 지연이 발생할 수 있으며, 결제가 시작된 후 며칠이 지나도 취소될 가능성이 있습니다.
• 계좌이체: 결제는 더 빠르지만, 일반적으로 수동 처리가 필요하며 비용이 더 많이 듭니다.
• RTP 및 FedNow와 같은 실시간 결제 네트워크는 자금의 즉각적인 이동을 가능하게 하지만, 거래는 일단 완료되면 일반적으로 되돌릴 수 없습니다.
• 스테이블코인 전송은 완전히 다른 인프라에서 이루어지며, 보안 메커니즘과 운영상의 고려 사항도 다릅니다.

예를 들어, 미국 기업이 필리핀 공급업체에 지불하는 금액을 생각해 보세요.

• ACH를 이용하시면 송금은 T+2일 내에 완료되지만, 필리핀 은행은 ACH를 직접 받지 않습니다. 송금액은 중간에 현지 송금 채널을 거치게 되므로 실제 도착 시간은 T+4일이 될 수 있습니다. 이 기간 동안 계좌 정보 불일치로 인해 주문이 언제든지 취소될 수 있습니다.
• 계좌이체는 더 빠르지만, 오후 3시 송금 마감 시간 전에 제출해야 합니다. 마감 시간이 공휴일과 겹치는 경우 지연될 수 있습니다. SWIFT 수수료는 25달러에서 45달러 사이이며, 수취 은행에서 중개 수수료를 추가로 공제할 수 있으므로 최종 수령액이 송금액과 다를 수 있습니다.
• 스테이블코인 샌드위치 방식을 사용하면 미국 계좌에서 USDC가 발행되고, 몇 초 만에 온체인에서 확인된 후, 필리핀 파트너를 통해 페소로 환전되어 현지 계좌에 입금됩니다. 전체 과정은 1시간 이내에 완료되며, 수수료는 송금액의 1% 미만입니다.

세 가지 결제 방식, 동일한 금액이지만 정산 시간은 96시간, 수수료는 수십 달러, 추적 가능성은 완전히 달랐습니다. 이는 제품 경험의 차이가 아니라 세 가지 운영 체제의 차이였습니다. PSP의 추상화 계층은 이러한 차이점을 숨길 수 없었고, 개발자와 운영팀이 이를 파악하도록 할 수밖에 없었습니다.

이것들은 동일한 결제 모델의 변형이 아니라 근본적으로 다른 운영 모델입니다.

기존 PSP(결제 서비스 제공업체) 접근 방식은 각 트랙별로 서로 다른 API와 상태 정의를 노출하는 것입니다. 이는 실질적인 통일성이 없고, 차이점을 개발자에게 떠넘기는 결과를 초래합니다. 엔지니어링 팀은 각 트랙에 대한 특정 로직을 작성해야 하고, 운영 팀은 다양한 오류 모드를 수동으로 처리해야 하며, 재무 팀은 완전히 다른 경로를 거친 유사한 거래를 대조해야 합니다.

이는 추상화 누출 현상입니다. 원래는 보호되어야 할 트랙의 복잡성이 애플리케이션 계층으로 스며들기 시작하는 것입니다.

트랙이 추가될수록 결제 환경은 통합된 추상화 구조라기보다는 느슨하게 연결된 여러 통합 요소의 집합체가 됩니다. 속도가 느린 트랙에서는 지연 시간으로 인해 문제를 감지할 수 있는 시간적 여유가 생깁니다. 하지만 실시간 트랙에서는 이러한 여유가 사라집니다. 결제는 몇 초 안에 완료되고, 오류를 쉽게 되돌릴 수 없으며, 자금이 이동하기 전이 아니라 이동 후에 결정을 내려야 합니다.

IV. 실시간 결제는 PSP(결제 서비스 제공업체)가 제어권을 앞으로 이동하도록 강제합니다.

실시간 결제 네트워크로의 전환은 단순히 자금 흐름 속도를 높이는 것만이 아니라, 결제 인프라의 설계 요구 사항을 근본적으로 바꾸는 것입니다.

ACH와 계좌이체 시대에는 시간이 완충 장치 역할을 했습니다.

ACH 거래는 정산에 며칠이 걸릴 수 있고, 은행 카드 거래는 승인 후에도 이의 제기가 발생할 수 있으며, 계좌 이체는 종종 수동 검토 단계를 거칩니다. 이러한 지연은 비효율성을 초래하지만, 오류를 발견하고, 의심스러운 활동에 개입하고, 최종 정산 전에 대조 작업을 완료할 수 있는 기회를 제공하기도 합니다.

기존 PSP 모델은 이 버퍼를 중심으로 구축되었습니다.

하지만 RTP나 FedNow와 같은 실시간 결제 네트워크는 이러한 통념을 완전히 뒤집어 놓았습니다. 자금은 몇 초 만에 계좌 간에 직접 이동하며, 일단 결제가 완료되면 일반적으로 되돌릴 수 없습니다.

• 사기 탐지는 더 일찍 완료되어야 합니다.
• 규정 준수 심사는 실시간으로 진행되어야 합니다.
• 재정적 결정은 지급금이 지급되는 바로 그 순간에 이루어져야 합니다.
• 나중에 실수를 바로잡을 기회는 더 이상 없습니다.

즉시 결제를 제공하는 플랫폼은 지연 정산을 위해 설계된 워크플로에 의존할 수 없습니다. 여러 계정에 걸쳐 결제 자금을 관리하는 내부 기업 시스템은 실행 시점의 유동성을 파악할 수 없습니다. 고객 지원팀은 기본 메커니즘이 취소를 허용하지 않는 경우 취소 가능성을 보장할 수 없습니다.

그 결과 책임 소재가 바뀌게 됩니다. PSP는 지급 시기를 결정하는 내부 시스템을 지원하도록 발전해야 합니다. 다시 말해, 통제권이 앞으로 이동해야 합니다.

결제 인프라는 자금 흐름이 발생하기 전, 즉 자금 흐름 이후에 승인, 자금 조달 로직, 위험 점검 및 상태 확인이 완료되도록 설계되어야 합니다. 이를 위해서는 기존 결제 서비스 제공업체(PSP) 아키텍처가 제공할 수 있는 것보다 더 통합적인 잔액, 거래 상태 및 서비스 제공업체 간 조건에 대한 파악이 필요합니다.

실시간 추이는 최종 상태가 아니라 단지 변곡점일 뿐입니다. 스테이블코인의 도입은 이 문제를 더욱 악화시킬 것입니다.

V. 스테이블코인: 새로운 결제 수단이 아닌 새로운 길

스테이블코인에 대한 가장 흔한 오해는 스테이블코인을 새로운 결제 수단으로 보는 것입니다. 스테이블코인은 결제 수단이 아닙니다. 스테이블코인은 거래 완료와 자금 수령 사이의 시간적 지연을 해소하는 새로운 결제 방식입니다.

신용카드, ACH, 계좌이체와 달리 스테이블코인 거래는 블록체인 네트워크에서 이루어집니다.

• 정산은 일괄 처리 방식이 아닌 지속적으로 진행됩니다.
• (네트워크 상태에 따라) 거의 즉각적인 최종 확인이 가능합니다.
• 이 서비스는 24시간 연중무휴로 운영되며 은행 영업 종료 시간이나 공휴일의 영향을 받지 않습니다.
• 특정 국내 결제 시스템에 의존하지 않음
• 잔액, 소유권 및 거래 내역을 추적하는 기본 요소는 완전히 다릅니다.

기존 PSP(결제 서비스 제공업체) 아키텍처는 은행과 결제 네트워크의 통합을 중심으로 구축되었지만, 스테이블코인은 이러한 중개자에 의존하지 않는 네트워크를 도입합니다. 발행, 정산, 회계 처리는 모두 기존 설계 방식과는 별개로 이루어집니다. 기업은 은행 거래, 실시간 네트워크, 온체인 정산을 동시에 처리해야 할 수 있으며, 각 처리 방식은 최종성, 시점, 제어 방식에 대한 서로 다른 가정을 가지고 있습니다. 이러한 차이점을 단일 API로 통합하는 것은 불가능하며, 따라서 PSP를 단일 추상화 계층으로 유지하기가 점점 더 어려워지고 있습니다.

실시간 결제 시스템이 결제 시점과 취소 가능성에 대한 기존의 가정에 도전하는 것처럼, 스테이블코인은 결제가 어디서 어떻게 이루어지는지에 대한 기존의 가정에 도전합니다.

이 과정에서 그들은 새로운 차원의 복잡성을 도입합니다.

현재 가장 실용적인 구현 경로는 스테이블코인 샌드위치 방식입니다. 즉, 법정화폐 투입 → 온체인 유통 → 법정화폐 출금입니다.

거래 양측의 고객과 공급자는 스테이블코인을 이해할 필요가 없습니다. 스테이블코인은 단지 중개 채널일 뿐이며, 특히 기존의 국경 간 결제 방식이 가진 느리고, 비용이 많이 들고, 불안정한 측면을 해결하기 위해 고안되었습니다. 스테이블코인의 가장 큰 가치는 기존 방식이 느리거나, 비용이 많이 들거나, 아예 불가능한 국경 간 거래와 같이 "접근하기 어려운" 시나리오에 집중되어 있습니다.

기업들은 스테이블코인에 전적으로 투자해서는 안 되며, 그렇게 할 수도 없습니다. 현실적인 접근 방식은 부분적인 대체를 위해 한두 가지 특정 사용 사례를 선택하고, 인지도를 구축한 후 점차 확대해 나가는 것입니다.

스테이블코인은 또한 기존 시스템에서는 거의 찾아볼 수 없는 '유통 중 수익'이라는 새로운 차원을 제시합니다. 기존 결제 시스템에서는 자금이 발행부터 수령까지 24시간에서 72시간 동안 묶여 수익이 발생하지 않고 운전자본이 묶이게 됩니다. 온체인 스테이블코인은 유통 중에 수익을 창출할 수 있습니다. 이는 단순히 결제 비용을 최적화하는 것이 아니라 자본 효율성 논리를 완전히 재편하는 것입니다.

VI. 현재의 생태계: 10단계의 분업 구조와 누락된 단계

결제 인프라가 더 많은 경로, 더 많은 서비스 제공업체, 더 많은 인프라 유형을 아우르게 되면서 PSP(결제 서비스 제공업체)의 역할을 정의하는 것이 점점 더 어려워지고 있습니다.

과거에는 단일 PSP에 묶여 있던 자금 이체 책임이 이제는 기술 스택의 여러 계층에 분산된 일련의 책임으로 바뀌었습니다.

PSP의 역할은 더 이상 단순히 자금을 이동시키는 것이 아니라 자금 흐름을 해석하는 것입니다.

이러한 변화는 더 근본적인 변화를 반영합니다. 이제 단순히 실행만으로는 충분하지 않습니다. PSP는 기업의 내부 시스템을 지원하여 다양한 환경에서 자금이 어떻게 흐르는지 표현, 기록 및 조정할 수 있도록 해야 합니다.

① 제품 수준 플랫폼: 소프트웨어에 결제 기능 내장

Shopify, Square, Toast, Mindbody, ServiceTitan, Housecall Pro와 같은 전문 소프트웨어 플랫폼은 제품에 결제 기능을 직접 통합했습니다.

이러한 시나리오에서는 결제가 별도의 결제 시스템으로 처리되는 대신 애플리케이션 환경에 통합됩니다. 이러한 플랫폼은 일반적으로 하위 PSP(결제 서비스 제공업체), 은행 파트너 및 인프라 서비스 제공업체에 의존하므로 애플리케이션과 자금 흐름 사이에 추상화 계층이 하나 더 추가됩니다.

② 실행 계층: 트랙 간 자금 이동

기술 스택의 핵심에는 결제 실행을 담당하는 결제 서비스 제공업체(PSP)가 있습니다. 여기에는 Stripe, Adyen, Checkout.com, Worldpay, PayPal, Nuvei, dLocal과 같은 기존 PSP가 포함되며, 이들의 역할은 기업을 결제 경로에 연결하고 자금 이동을 원활하게 하는 것입니다.

이러한 구성 요소들은 여전히 ​​결제 기술 스택의 핵심 요소이지만, 주로 실행 계층(결제 시작, 상태 보고, API 노출 등)에서 작동하며, 서비스 제공업체와 내부 시스템 간의 자금 흐름에 대한 완전한 모델을 제공하지는 않습니다.

Stripe에 "이 돈이 지금 어디에 있나요?"라고 물으면, Stripe는 자사 거래 구간에서 일어난 일만 알려줄 수 있습니다. Stripe는 거래 과정의 한 부분일 뿐이며, 실제 거래에는 PSP, 은행, 운송장, 내부 장부 등 네다섯 개의 다른 연결 고리가 관여할 수 있습니다. 하지만 Stripe는 전체 과정이 아닌 일부만을 볼 뿐입니다.

③ 오케스트레이션 및 라우팅 계층: 서비스 제공업체에 연결

기업들이 여러 결제 서비스 제공업체(PSP)와 결제 방식을 도입함에 따라, 서비스 제공업체 간의 라우팅을 관리하는 오케스트레이션 플랫폼이 등장했습니다. Primer, Gr4vy, Spreedly, Paydock, CellPoint Digital과 같은 기업들은 기업들이 지리적 위치, 비용 또는 성능을 기준으로 거래를 오케스트레이션할 수 있도록 지원합니다. 이러한 시스템은 실행 단계에서 유연성을 높여주지만, 결제 후 행동에 대한 통합 모델을 제공하지는 않습니다.

④ 위험 관리 및 규정 준수 계층: 자금을 이동해야 하는지 여부를 결정합니다.

여러 독립적인 서비스 제공업체들이 결제 진행 여부를 결정하는 책임을 맡고 있습니다. Persona, Sardine, Alloy, Unit21, Sift, Sumsub 등의 업체에서 제공하는 신원 확인, 사기 탐지 및 규정 준수 시스템은 거래 실행 전에 사용자와 거래를 평가합니다. 실시간 환경에서는 자금이 이체되기 전에 이러한 결정이 내려져야 하므로, 핵심적인 제어 로직이 PSP(개인 서비스 제공업체) 외부로 이동하게 됩니다.

⑤ 은행 인프라 계층: 자금을 보유하고 접근을 지원합니다.

크로스리버뱅크, 리드뱅크, 컬럼, 서튼뱅크와 같은 수탁은행은 규제 대상 계좌를 제공하고 결제 네트워크에 대한 접근 권한을 부여합니다. 이들 은행은 고객 자금을 보유하고 유동성을 관리하며 ACH, 송금, RTP, FedNow와 같은 결제 시스템에 대한 관문 역할을 합니다. 이러한 계층은 금융 시스템에 접근하는 데 필수적이지만 애플리케이션 로직 및 PSP API와는 독립적으로 운영됩니다.

⑥ 카드 발급 계층: 확장된 결제 기능

Marqeta, Lithic, Rain과 같은 카드 발급 플랫폼은 기업이 자사 제품의 일부로 직불카드와 신용카드를 발급할 수 있도록 지원하며, 수수료 관리, 법인카드, 마케팅 비용 지출과 같은 다양한 활용 사례를 지원합니다. 이러한 플랫폼은 은행과 카드 네트워크를 연결하지만, 결제 기술 스택 내에서 별도의 계층으로 작동하며, 다른 결제 기술 스택과의 연동이 필요한 추가적인 워크플로, 제어 메커니즘 및 상태를 도입합니다.

⑦ 결제 트랙 레이어: 기본 실행 네트워크

결제 경로는 금융 기관 간 자금 이동을 위한 네트워크입니다. 기존 경로는 ACH, 송금, 카드 네트워크 등을 포함하며, RTP 및 FedNow와 같은 새로운 네트워크는 실시간 결제를 지원합니다. 각 경로는 결제 시점, 확정성, 취소 가능성에 대해 서로 다른 가정을 기반으로 하므로, 결제 서비스 제공업체(PSP)는 이러한 불일치를 파악하거나 (완전히 추상화하기보다는) 해결해야 합니다.

⑧ 스테이블코인 네트워크 레이어: 은행 인프라를 넘어 확장

이더리움, 솔라나, 폴리곤, 베이스와 같은 스테이블코인 네트워크는 기존 은행 시스템 외부에서 작동하는 새로운 형태의 결제 인프라를 도입했습니다. 각기 다른 결제 모델과 보안 메커니즘을 갖춘 이러한 네트워크는 글로벌 인프라를 통해 디지털 달러의 전송을 가능하게 합니다. 이는 은행 기반 경로를 넘어 결제 시스템의 범위를 확장하는 동시에 기존 업무 흐름에 통합해야 하는 추가적인 복잡성을 야기합니다.

9. 서비스형 뱅킹 레이어: 애플리케이션과 은행 연결

Unit, Galileo, Treasury Prime과 같은 BaaS(Bank-as-a-Service) 플랫폼은 핀테크 애플리케이션과 규제 대상 은행을 연결하는 인프라를 제공합니다. 이러한 플랫폼을 통해 기업은 은행이 되지 않고도 계좌, 카드, 결제 기능을 제공할 수 있습니다. 이 계층은 은행 인프라에 대한 접근을 간소화하지만, 애플리케이션, 결제 서비스 제공업체(PSP), 그리고 실제 자금 흐름 사이에 또 ​​다른 중개자가 추가되는 결과를 초래합니다.

⑩ 누락된 부분: 자금 흐름의 전체 생애주기를 포괄하는 통합 PSP

위의 9개 계층을 살펴보면 일관된 패턴이 나타납니다. 각 서비스 제공업체는 특정 기능을 담당하며, 그 어느 업체도 자금 흐름에 대한 완전한 정보(이해, 통제 및 조정 포함)를 독립적으로 제공할 수 없습니다.

거래 실행은 하나의 서비스 제공업체가 담당하고, 위험 평가 결정은 다른 서비스 제공업체가 담당하며, 자금은 은행에서 보관하고, 결제 과정은 카드 네트워크, 실시간 추적 시스템, 온체인 시스템 등을 아우를 수 있습니다. 각 시스템은 서로 다른 데이터, 타임라인, 상태 정의를 제공합니다.

파편화된 환경에서는 이러한 문제가 초기 단계에서 드러나지 않고, 시스템 내에서 의견 불일치가 발생하거나 자금 지급이 지연되거나 반환되어 팀이 해답을 필요로 할 때 비로소 나타납니다. 바로 이 지점에서 결제 시스템이 제대로 작동하지 않기 시작합니다.

VII. 결제 작업은 어디에서 오류가 발생했습니까?

금요일 오후 2시 55분, 재무팀은 공급업체에 5만 달러 송금을 요청했습니다. 오후 3시에 은행에서 송금이 완료되었습니다. 시스템에는 "송금 완료"로 표시되었지만, 확인 이메일은 도착하지 않았습니다.

오후 4시, 공급업체에서 결제 상태를 문의하는 메시지를 보냈습니다. 재무 부서에서는 PSP 백엔드를 확인했는데 "처리 중"으로 표시되었습니다. 은행 계좌를 확인해 보니 "정산 대기 중"이었습니다. 두 시스템에서 동일한 금액에 대해 서로 다른 상태가 표시되었고, 어느 쪽에서도 돈이 어디에 있는지 알 수 없었습니다.

금요일 오후 5시, 은행 고객센터는 이미 문을 닫았다. 공급업체는 주말 배송을 위해 대금 지급을 기다리고 있었다. 재무팀은 공급업체에게 뭐라고 말해야 할지, 돈이 월요일 아침에 자동으로 입금될지, 아니면 반환되어 재심사를 해야 할지 알 수 없었다.

이는 극단적인 사례가 아니라, 결제 운영팀이 매주 겪는 시나리오입니다. 결제 서비스 제공업체(PSP)의 제품 설명서에는 나오지 않겠지만, 모든 해외 결제팀의 업무 기록에는 반드시 기록될 것입니다.

결제와 관련하여 가장 어려운 문제는 종종 초기 단계가 아니라 그 이후, 즉 팀이 정확히 무슨 일이 일어났는지 설명해야 할 때 발생합니다.

이전 장에서 살펴본 시장 지도는 결제 생태계의 광범위한 범위를 보여줍니다. 겉보기에는 단순해 보이는 결제조차도 정산이 이루어지기 전에 기술 스택 내의 여러 서비스 제공업체를 거치는 경우가 많습니다. 각 당사자는 동일한 자금 이동에 대해 서로 다른 표현 방식을 가질 수 있으며, 처리 시점, 상태, 문서 도착 일정, 보고 경로 등도 제각각입니다.

바로 이 지점에서 결제 업무가 어려워집니다.

조정: 동일한 이벤트의 여러 버전

재무팀은 내부 장부와 은행 명세서, 정산 보고서, 결제 처리 업체 데이터를 대조해야 합니다. 한 서비스 제공업체에서는 결제가 완료된 것으로 표시되는 반면 다른 업체에서는 아직 처리 중인 것으로 표시되는 경우, 회사는 이러한 불일치를 해결할 수 있는 모델이 필요합니다. 내부 잔액이 업데이트된 후 취소 요청이 접수되면 해당 장부를 취소하거나 그에 따라 조정해야 합니다.

예외 처리: 원인이 명확하게 정의되지 않은 오류

출금 실패는 대상 계좌가 잘못되었거나, 입금 계좌가 잘못되었거나, 규정 준수 검토로 인해 거래가 중단되었거나, 마감일을 놓쳤기 때문일 수 있습니다. 이러한 실패 원인은 서로 다르며 동시에 발생하지도 않습니다. 하지만 사용자들은 일관된 답변을 기대하고, 내부 팀은 여전히 ​​해당 프로세스를 처리해야 합니다.

유동성과 자금 조달: 자금이 잘못된 곳에 있다

다양한 서비스 제공업체와 계정을 통해 사업을 운영하는 기업은 적시에 적절한 자금이 적절한 계좌에 입금되도록 해야 합니다. 전체 잔액이 충분하더라도 자금이 잘못된 계좌에 남아 있으면 결제가 실패할 수 있으며, 이는 제품 논리와 운영 현실 간의 격차를 초래합니다.

감사 가능성과 통제: 발생 상황 재구성

승인, 보류, 해제 및 조정 작업은 여러 팀과 시스템에 걸쳐 이루어지므로 기업은 누가 언제 왜 무엇을 했는지 정확하게 기록해야 합니다. 이는 규정 준수 요건일 뿐만 아니라 문제가 발생할 경우 거래 내역을 추적하는 기반이 됩니다.

이러한 문제들은 운영상의 문제이자 구조적인 문제입니다.

결제 업무에서 가장 큰 실패는 팀이 "이 돈은 어디로 갔을까?"라는 간단한 질문에 답하지 못할 때 발생하는 경우가 많습니다.

기존 모델에서 부족한 것은 결제를 처리하고, 거래를 라우팅하고, 자금을 보유하는 또 다른 서비스 제공업체가 아니라, 이러한 모든 기능을 조정하고, 서비스 제공업체 전반에 걸쳐 상태를 추적하고, 현금 흐름 워크플로를 관리하고, 시간이 지남에 따라 신뢰할 수 있는 재무 기록을 유지할 수 있는 진화된 PSP입니다.

8. PSP의 다음 진화

진정한 과제는 결제 인프라에 접근하는 데 있는 것이 아니라, 그 안에서 자금이 어떻게 흐르는지에 대한 일관되고 신뢰할 수 있는 이해를 유지하는 데 있습니다.

현재의 생태계는 다음과 같은 구조로 되어 있습니다. 결제 서비스 제공업체(PSP)는 결제를 실행하고, 은행은 자금을 보유하며, 규제 준수 시스템은 위험을 평가하고, 오케스트레이션 도구는 거래를 라우팅합니다. 그러나 단일 서비스 제공업체가 전체 결제 주기 전반에 걸쳐 자금 흐름에 대한 완전하고 일관된 시각을 제공할 책임은 없습니다.

PSP의 다음 단계는 전체 기술 스택에 걸쳐 일관된 가시성을 제공하여 모든 결제가 시작부터 최종 정산까지 이해, 기록 및 신뢰할 수 있도록 보장하는 것입니다.

이 레이어는 다음을 수행할 수 있어야 합니다.

• 은행, 기존 철도 및 스테이블코인 네트워크를 통해 결제를 실행하세요.
• 내부 장부를 통해 일관된 기록 시스템이 유지됩니다.
• 승인, 자금 및 예외 처리 관리를 위한 워크플로
• 외부 활동과 내부 재무 상태를 일치시키십시오.
• 규모가 커짐에 따라 내장된 규정 준수 기능, 계정 인프라 및 지속적으로 확장되는 트랙 연결 기능을 제공합니다.

결론: 어디서부터 시작해야 할까요?

현대 결제 인프라는 더 이상 단일 처리업체나 단일 경로로 정의되지 않습니다. 이는 자금 흐름, 승인, 결제 및 회계의 다양한 측면을 각각 담당하는 여러 서비스 제공업체로 구성된 환경입니다.

이 가이드 전체를 통해 우리는 이러한 환경의 진화를 살펴보았습니다.

결제 서비스 제공업체는 단순한 거래 처리 기능을 넘어섰고, 결제 채널은 증가했으며, 실시간 시스템은 지연 결제라는 안전장치를 없앴고, 스테이블코인과 같은 새로운 형태의 인프라는 전체 시스템을 더욱 확장시켰습니다.

금융 상품을 개발하거나 소프트웨어에 결제 기능을 통합하는 팀에게는 전략적 논의보다 진입점이 더 중요합니다.

스테이블코인을 완전히 도입할지 여부를 놓고 논쟁을 시작하지 마세요. 대신, 구체적인 문제점을 파악하세요. 예를 들어, 국경 간 결제 과정이 너무 느리거나, 공급업체 대금 지급 과정에 수작업이 너무 많이 필요하거나, 유휴 자금이 이체 과정에서 수익을 내지 못하고 묶여 있는 경우 등이 있습니다. 사용 사례를 선택하고, 계좌를 개설하고, 실제로 결제를 진행해 보세요. 고객 측 프로세스를 직접 변경하기보다는 재무 관리 측면에 초점을 맞춰 내부적으로 먼저 시범 운영해 보는 것이 좋습니다. 이렇게 하면 위험을 관리하면서 인식을 높일 수 있습니다.

규정 준수 관점에서 볼 때, KYC, AML 및 제재 심사 규칙은 여전히 ​​전적으로 적용되며, 스테이블코인은 기본 메커니즘의 변화일 뿐입니다. GENIUS 법안 이후 수립된 규제 체계는 2년 전보다 훨씬 명확해졌으므로 시범 프로그램을 방해할 이유가 되어서는 안 됩니다.

진정한 전략적 위험은 스테이블코인을 사용하느냐 마느냐가 아니라, 경쟁사들이 스테이블코인을 활용하여 결제 비용과 자본 효율성을 재조정하는 동안 당신은 여전히 ​​완벽한 진입 시점을 기다리고 있다는 점입니다.

통합된 조정 체계가 없으면 규모가 커질수록 복잡성이 증가합니다. 하지만 통합 체계를 갖추면 기업은 현금 흐름을 명확하고 효과적으로 관리하고 자신감을 가질 수 있습니다.

일부 내용은 다음 자료에서 발췌했습니다. Modern Treasury — A Practical Guide to PSPs in 2026