에이전틱 커머스, 스테이블코인만 쓸 수 있을까?

 

목차

1. 에이전틱 커머스는 이커머스와 무엇이 다른가

2. 기존 결제 레일은 왜 이 요구를 충족하지 못하는가

3. 스테이블코인은 이 문제를 어떻게 해결하는가: 시나리오별 비교

4. 스테이블코인 결제의 한계

5. 결론: 레일 선택이 아니라 조합의 문제

 

 

지난해부터 "AI 에이전트가 사람 대신 업무를 처리한다"는 뉴스가 쏟아지고 있다. 회의 일정을 잡고, 이메일을 쓰고, 코드를 짜는 것까지는 이제 낯설지 않다. 그런데 여기서 한 발 더 나아가면 어떻게 될까. 당신이 AI 에이전트에게 "이번 주 안에 러닝화 최저가로 사줘"라고 말하는 순간 에이전트가 수십 개 쇼핑몰의 가격을 비교하고, 쿠폰을 적용하고, 재고를 확인한 뒤 결제까지 스스로 완료한다. 사람이 한 일은 단 한 마디뿐이다. 이것이 에이전틱 커머스다.

이 흐름이 현실이 되면 결제 인프라에는 전혀 다른 요구가 생긴다. 에이전트는 사람처럼 "결제 버튼을 누르는" 것이 아니라, 코드로 수백 건의 거래를 자동으로 처리한다. 기존 카드나 은행 시스템이 이 역할을 그대로 맡을 수 있을까, 아니면 새로운 결제 수단이 필요할까. Visa는 2025년 4월 AI 에이전트 전용 결제 인프라 구축을 공식 선언했고, Stripe는 같은 해 5월 법정화폐에 가치를 연동한 블록체인 기반 결제 수단인 스테이블코인으로 대금을 정산하는 경로를 101개국에 열었다. 글로벌 결제 기업들이 이미 답을 찾아 움직이고 있다는 신호다.

그렇다면 기존 카드·은행 레일도 에이전트 기반 결제를 지원하는 방향으로 진화하고 있는데, 굳이 스테이블코인이 필요한 이유는 무엇일까. 그 이유를 알기 위해서는 기존 결제 레일은 어디까지 대응할 수 있으며, 어떤 지점부터 스테이블코인이 구조적으로 더 유리해지는가를 알아야한다.

이 글은 이 질문에 1. 에이전틱 커머스가 기존 이커머스와 어떻게 다른지, 2. 그 차이가 결제 레일에 어떤 요구 조건을 만들어내는지, 그리고 3. 국내 계좌이체·카드·SWIFT·스테이블코인이 각각 어느 구간에서 강점과 한계를 가지는지를 구조적으로 답한다.

 

1. 에이전틱 커머스는 이커머스와 무엇이 다른가

에이전틱 커머스를 단순히 이커머스의 “자동화 버전”으로 이해하면 결제 문제의 본질을 놓치게 된다. 핵심 차이는 자동화 여부가 아니라 거래가 작동하는 경제 구조 자체에 있다.

기존 이커머스는 사용자의 관심(attention)을 중심으로 작동하는 Attention Economy에 가깝다. 플랫폼은 광고, 추천, UI 설계를 통해 사용자의 주의를 끌고, 그 흐름 속에서 구매를 유도한다. 이 과정에서 결제는 사용자의 최종 의사결정을 확인하는 단발성 이벤트다. 장바구니를 확인하고, 금액을 인지하고, 결제 버튼을 누르면 거래는 완료된다.

반면 에이전틱 커머스는 사용자의 의도(intention)를 직접 실행하는 Intention Economy에 가깝다. 사용자는 “신발을 가장 저렴하게 구매해줘”와 같은 목표만 제시하고, 이후의 탐색·비교·결제·정산은 에이전트가 자동으로 수행한다. 이 구조에서 결제는 더 이상 이벤트가 아니라, 워크플로를 구성하는 실행 단계 중 하나로 전환된다.

이 차이는 세 가지 측면에서 구체적으로 드러난다.

첫째, 거래 빈도와 단가가 달라진다. 이커머스에서는 사용자가 한 번의 구매를 위해 여러 상품을 비교하더라도 실제 결제는 한 번 발생한다. 반면 에이전틱 커머스에서는 하나의 목표를 수행하는 과정에서 수많은 API 호출과 서비스 이용이 발생하며, 각각이 결제로 이어진다. 예를 들어 신발 구매 에이전트는 쿠폰 조회, 가격 비교, 재고 확인, 주문 실행 등의 단계를 거치며 각 단계마다 $0.01~$0.05 수준의 비용이 발생할 수 있다.

둘째, 결제 결과가 다음 작업의 분기 조건이 된다. 기존 이커머스에서는 결제 이후의 과정이 비교적 느슨하게 이어진다. 결제가 완료되면 이후 배송이나 환불 여부는 사람이 별도로 확인하고 처리한다. 반면 에이전틱 커머스에서는 결제 결과 자체가 다음 행동을 결정하는 신호가 된다. 결제가 실패하면 대체 판매자를 탐색하고, 지연되면 재시도하며, 확정되면 즉시 배송 API를 호출한다. 이 구조에서 결제 지연은 단순한 불편이 아니라 전체 워크플로를 멈추게 하는 변수가 된다.

셋째, 결제 자체에 조건이 포함된 형태로 설계된다. 기존 이커머스에서는 결제가 먼저 이루어지고, 이후 환불이나 보상은 별도의 절차로 처리된다. 예를 들어 배송이 늦어지면 고객센터를 통해 환불을 요청하는 식이다. 반면 에이전틱 커머스에서는 “조건이 충족되면 지급한다”는 로직이 결제와 함께 설계된다. 예를 들어 배송이 일정 기간 내 완료되면 대금을 지급하고, 그렇지 않으면 자동으로 환불하는 구조가 기본값이 된다. 이 과정은 사람이 아니라 코드로 실행되기 때문에, 결제는 단순한 자금 이동이 아니라 조건부 실행 로직과 결합된 형태로 동작하게 된다.

이러한 차이는 결제 레일에 새로운 요구를 만든다. 단순히 결제가 가능한지를 넘어서 초저비용으로 반복 실행 가능한 구조, 예측 가능한 시간 내 확정성, 그리고 조건부 정산을 내장할 수 있는 구조가 필요해진다.

 

2. 기존 결제 레일은 왜 이 요구를 충족하지 못하는가

기존 이커머스(Attention Economy)의 결제 레일은 단발성 이벤트를 처리하도록 설계됐다. 그 구조가 에이전틱 커머스(Intention Economy)의 요구—반복, 조건부, 즉시 확정—와 충돌하는 지점이 바로 아래에서 다룰 세 가지 한계다.

2-1. 국내 은행이체

국내 원화 결제만 놓고 보면 계좌이체는 여전히 강력하다. 한국의 오픈뱅킹은 정비 시간을 제외하면 사실상 연중무휴에 가깝게 운영되고, 오픈뱅킹 API 수수료는 기관 기준 건당 약 40~50원으로 낮다. 따라서 국내 단순 결제에서는 굳이 스테이블코인이 필수라고 보기 어렵다.

다만 한계도 분명하다.

• 통화와 지리적 범위가 제한적이다. 국내 원화 거래에는 효율적이지만, 해외 판매자나 해외 공급망으로 넘어가는 순간 전통적 국경간 지급망의 영향을 받게 된다. 다만 이때도 항상 SWIFT만 쓰는 것은 아니고, 현지 수납망·지급대행·핀테크 네트워크를 우회적으로 활용하는 경우도 있다.
• 프로그래머블 정산을 지원하지 않는다. 은행이체는 "A계좌에서 B계좌로 n원"이라는 단순 이체만 처리한다. 신발이 한 달 안에 도착하면 결제, 더 늦어지면 환불하는 것처럼 조건부 정산 로직은 플랫폼이 별도로 구현해야 한다.

요컨대 국내 계좌이체는 국내 단순 결제에는 충분하지만, 프로그래머블 정산까지 기본 제공하는 레일은 아니다.

2-2. 카드 레일

카드 레일은 승인(authorization), 매입(capture), 정산(settlement)이 분리된 구조를 가진다. 이 구조는 소비자 보호와 보편적 수용성 면에서는 매우 강력하다. 또한 카드 네트워크는 API 기반 결제, 자동 결제, 위임 인증 등의 형태로 점진적인 자동화를 수용하고 있으며 에이전트 기반 결제 흐름 역시 기술적으로는 구현 가능한 영역에 포함된다. 따라서 카드가 에이전틱 커머스에 전혀 쓸 수 없다는 식의 서술은 이제 맞지 않는다.

문제는 “가능 여부”보다 “경제성”이다.

• 고정비가 붙는 소액 결제에는 불리하다. 소비자가 카드를 긁으면 카드를 발급한 은행(발급사)이 거래를 승인하고, 가맹점이 거래하는 별도의 은행(매입사)을 통해 자금이 정산된다. 가맹점이 부담하는 수수료는 이 발급사와 매입사 사이의 인터체인지 요율에 기반한다. 에이전트의 자동 결제는 대부분 Card Not Present Debit(카드를 단말기에 직접 긁지 않는 온라인·자동 결제 구간으로, 대면 거래보다 사기 위험이 높다고 판단해 높은 요율이 적용됨) 구간에 해당하며, Visa 공개 예시 기준으로 약 1.65% 정도의 수수료가 존재한다. 이 수치는 모든 카드 결제의 보편 요율이 아니라 대략적인 예시이지만, 소액 결제에서 고정비가 부담된다는 구조적 문제를 보여주기에는 충분하다.
• 분쟁과 사후 취소 구조가 길다. 소비자가 결제 이후 문제가 발생하면 일정 기간 내에 거래를 취소하거나 분쟁을 제기할 수 있는 차지백은 반대로 판매자나 자동화 시스템 입장에서는 불확실성이다. 카드 네트워크 규정상 소비자는 거래일로부터 최대 120일 이내에 분쟁을 제기할 수 있지만, 에이전트가 이미 실행한 디지털 서비스의 분쟁 증빙은 어렵고 고빈도 소액 거래에서는 차지백 한 건의 처리 비용이 거래금액을 초과하기도 한다.
• 프로그램 가능 정산은 별도 레이어가 필요하다. 카드 결제는 기본적으로 “결제 승인 → 정산”이라는 구조를 제공하지만, 그 안에 복잡한 조건을 직접 담는 방식은 아니다. 예를 들어 “상품이 7일 내 도착하면 판매자에게 지급하고, 그렇지 않으면 환불한다”와 같은 조건부 정산 로직은 카드 네트워크 자체가 처리하는 것이 아니라, 플랫폼이나 중간 시스템이 별도로 구현해야 한다.

2-3. SWIFT 기반 국경간 은행 송금

국경간 결제의 전통적 경로는 코레스(correspondent) 은행 체계다. 직접 거래 관계가 없는 두 은행 사이를 중개 은행이 이어주는 구조로, 경로에 따라 중개 은행이 0개에서 여러 개까지 변한다. 이 구조에서 SWIFT는 실제 자금을 이동시키는 네트워크가 아니라 “얼마를 보내라”는 지급 지시 메시지를 전달하는 역할을 수행한다. 송금은행이 메시지를 보내면 해당 메시지는 중개 은행을 거쳐 수취은행까지 전달된다. 수취은행은 이 메시지를 기준으로 입금 처리를 진행하거나, 내부 정산 절차에 따라 이후에 자금을 반영한다.

2017년 SWIFT gpi 도입 이후 속도와 추적 가능성은 과거보다 크게 개선됐다. 실제로 SWIFT는 gpi 결제의 상당수가 30분 이내, 거의 전부가 24시간 내에 처리된다고 설명한다. 따라서 “국경간 송금은 대체로 며칠씩 걸린다”는 일반론은 지금 기준으로는 과장이다.

다만 에이전틱 커머스 관점에서 핵심 문제는 평균 속도가 아니라 예외 상황을 처리하는 비용과 복잡성이다. 대부분의 SWIFT gpi 송금은 빠르게 처리되지만, 은행의 적법성 확인이나 외화 규제에 걸리는 경우 동일한 경로에서도 이틀 이상 지연되는 사례가 발생한다.

문제는 지연 자체가 아니라, 이 상태를 시스템이 처리해야 한다는 점이다. 에이전트는 이 구간 전체를 코드로 다뤄야 한다. 그러나 기존 SWIFT 기반 결제는 중간 상태가 많고, 어느 기관이 처리를 담당하고 있는지 명확하지 않으며, 처리 완료 시점 역시 예측하기 어렵다. 이로 인해 “입금이 완료되었는가, 아직 처리 중인가, 거부되었는가”와 같은 상태를 안정적으로 구분하기 어렵고, 예외 상황에 대한 처리 로직이 복잡해진다. 이는 개발 복잡성과 운영 비용을 동시에 증가시킨다. 즉, 사람에게는 “조금 늦는 송금”일 수 있지만, 에이전트에게는 여러 분기 처리를 동반하는 상태 불확실성 문제가 된다.

또한, 코레스 구조는 중개 단계마다 고정 수수료와 환전 비용이 함께 발생하며, 실제 비용은 코리도와 거래 규모에 따라 크게 달라진다. 소액이어도 중개 단계가 많다면 부담이 폭발적으로 커질 수 있다. 구체적인 수치는 3절 시나리오 C에서 카드와 함께 비교한다.

 

3. 스테이블코인은 이 문제를 어떻게 해결하는가: 시나리오별 비교

앞서 에이전틱 커머스(Intention Economy)에서 결제는 하나의 독립된 행위가 아니라, 에이전트가 실행하는 여러 단계 중 하나라고 하였다. 따라서 비교의 기준도 달라져야 한다. 단순히 ‘결제 메시지가 전달되었는가’가 아니라, 에이전트가 지연 없이 다음 단계를 실행할 수 있는 자금 확정 상태인지를 기준으로 봐야 한다.

이 글에서는 이러한 관점에서 각 결제 레일의 비용과 구조를 비교한다. 카드 수수료는 온라인 자동 결제(CNP) 구간 기준 1.65%에 건당 $0.15의 고정비를 적용했고, 국내 카드는 공시된 우대수수료율 상단인 1.45%를 기준으로 했다. SWIFT 기반 국경간 결제는 송금·중개·수취를 합산한 고정 수수료 $55와 환전 비용 1%를 반영했으며, 스테이블코인은 솔라나 네트워크 기준 건당 약 $0.0005의 수수료를 가정했다.

다만 이 수치는 절대적인 비용을 비교하기 위한 것이 아니라, 각 결제 레일이 가지는 구조적 차이를 설명하기 위한 단순화된 가정이다. 실제 비용과 처리 방식은 결제 경로, 거래 규모, 참여 기관에 따라 달라질 수 있다.

시나리오 A. 카드 레일의 경제성 문제 — 마이크로페이먼트 (건당 $0.05)

2절에서 카드 레일의 핵심 문제는 가능 여부가 아니라 경제성이었다. 이 문제가 가장 극명하게 드러나는 구간이 마이크로페이먼트다.

에이전트가 재고 조회 API를 호출하고 건당 $0.05를 내는 경우를 보자. 카드의 건당 고정비($0.15)가 거래 단가($0.05)보다 세 배 크다. 수수료가 원금을 초과하므로 카드사는 이 단가의 거래를 받지 않는다. 거래 자체가 성립하지 않는다.

스테이블코인(솔라나)은 건당 $0.0005다. 거래 단가($0.05) 대비 수수료 비율은 약 1%로, 카드 레일에서 경제성 문제로 불성립하던 거래가 온체인에서는 수익성 있는 구조로 성립한다.

시나리오 B. 카드 레일의 경제성 문제 — 고빈도 실시간 정산 ($1 × 10만 건/일)

경제성 문제는 단순히 1회 거래 금액이 수수료보다 작은 경우에만 발생하는 것이 아니다. 개별 거래 단위에서는 성립하더라도 거래 빈도가 높아지는 순간 누적 비용이 구조적으로 비효율을 만든다. 플랫폼이 $1 상품에 대해 판매가 발생할 때마다 건당 실시간으로 정산하는 모델을 가정해보자.

Visa CNP 요율(1.65% + $0.15)을 기준으로 보면 건당 수수료는 $0.1665다. 하루 10만 건이 발생하면 총 거래액은 $100,000이며, 총 수수료는 $16,650으로 집계된다. 이는 전체 거래액 대비 약 16.65%에 해당하는 수준이다.

반면 스테이블코인을 사용할 경우 건당 $0.0005로, 하루 총 수수료는 약 $50 수준이며, 이는 전체 거래액 대비 약 0.05%에 불과하다.

즉, 동일한 거래 구조에서도 결제 레일에 따라 수수료율이 16.65% vs 0.05%로 극단적으로 벌어진다. 이 격차는 거래 규모와 빈도가 증가할수록 선형적으로 확대되며, 결국 $1 단가 기반의 실시간 정산 모델의 수익성을 구조적으로 붕괴시킨다. 카드 레일 위에서는 이 정산 구조 자체를 설계할 수 없다.

이 두 시나리오가 보여주는 것은 같다. 에이전틱 커머스에서 카드가 쓸 수 없어서가 아니라, 쓰는 순간 비즈니스 모델이 처음부터 성립하지 않는다.

시나리오 C. SWIFT 레일의 예외 처리 비용 문제 — 국경간 B2B 정산 ($10,000)

2절에서 SWIFT의 핵심 문제는 평균 속도가 아니라 예외 구간의 처리 비용이었다. 이 문제를 가장 직접적으로 드러내는 것이 에이전트가 실행하는 국경간 B2B 정산이다.

에이전트가 해외 공급사에게 월 발주 대금 $10,000를 지급하고, 입금 확정 시 즉시 출고 API를 호출하는 시나리오를 보자. SWIFT gpi로 보내면 대부분은 빠르게 처리된다. 그러나 규정 심사나 외화 반출 제한에 걸리면 같은 경로에서도 이틀 이상 걸리는 경우가 드물지 않게 발생한다.

사람에게는 "조금 늦는 송금"이지만, 에이전트에게는 다음 분기를 멈추게 하는 상태 불확실성이다. 에이전트는 이 구간 전체를 코드로 다뤄야 한다. 그러나 기존 SWIFT 기반 결제는 중간 상태가 많고, 어느 기관이 처리를 담당하고 있는지 명확하지 않으며, 처리 완료 시점 역시 예측하기 어렵다. 이로 인해 “입금이 완료되었는가, 아직 처리 중인가, 거부되었는가”와 같은 상태를 안정적으로 구분하기 어렵고, 예외 상황에 대한 처리 로직이 복잡해진다.

온체인 정산은 이 문제를 구조적으로 제거한다. 정산 확정이 초~분 단위로 이루어지므로 예외 상태 자체가 발생하지 않는다. 에이전트가 처리해야 할 불확실성 구간이 사라진다. 비용도 절감된다. SWIFT 기준 약 $155(1.55%)에서 온·오프램프 포함 약 $30(0.30%)으로 줄어들지만, 이 시나리오에서 더 중요한 것은 비용 절감이 아니라, 에이전트 워크플로에서 예외 상태 자체를 제거한다는 것이다.

 

4. 스테이블코인 결제의 한계

3절에서 살펴본 것처럼 스테이블코인은 기존 레일이 실패하는 구간에서 비용과 속도 측면에서 뚜렷한 장점을 보인다. 단, 스테이블코인이 유리한 구간이 분명하더라도 이것이 무위험 인프라라는 뜻은 아니다.

첫째, 발행사 리스크가 있다. 중앙화 스테이블코인은 발행사가 법 집행 요청이나 규제 대응에 따라 주소를 동결하거나, 특정 자산 이동을 제한할 수 있다. 자금세탁 방지 국제기구인 FATF도 발행사가 freeze, burn, withdraw 기능을 기술적으로 구현할 수 있음을 전제로 논의를 전개한다.

둘째, 컴플라이언스 부담이 애플리케이션 쪽으로 이동한다. 카드·은행 레일에서는 AML/CFT, 거래 모니터링, 규제 보고 등의 기능을 네트워크와 금융기관이 상당 부분 흡수한다. 반면 온체인 결제에서는 주소 스크리닝, Travel Rule 대응, 언호스티드 지갑 정책 설계 등을 플랫폼이 직접 구현해야 하며, 이는 결제 인프라 설계의 복잡성을 크게 증가시킨다.

셋째, 소비자 보호 기본값이 약하다. 카드 결제는 승인, 정산, 차지백, 분쟁 해결까지 포함된 구조를 제공하지만, 스테이블코인 결제는 기본적으로 자산 이전만을 처리한다. 따라서 환불, 에스크로, 분쟁 해결과 같은 기능은 결제 레이어에 포함되지 않으며, 서비스 또는 별도의 프로토콜에서 별도로 설계해야 한다.

넷째, 체인 자체의 인프라 리스크가 있다. 온체인 결제는 블록체인 네트워크 위에서 실행되기 때문에 네트워크 혼잡, 가동 중단, 브리지 리스크, 스마트컨트랙트 취약성과 같은 인프라 리스크를 직접적으로 수반한다. 예를 들어 이더리움의 경제적 finality는 현재 구조상 약 12.8분 수준이며, 실무에서는 거래 금액과 리스크에 따라 더 이른 확인 시점을 사용할지, 더 강한 finality를 기다릴지 정책적으로 판단해야 한다.

 

5. 결론: 레일 선택이 아니라 조합의 문제

3절과 4절이 함께 보여주는 것은 이렇다. 스테이블코인은 기존 레일이 실패하는 구간에서 명확한 강점을 가지지만, 기존 레일이 기본 제공하던 소비자 보호, 컴플라이언스 내장, 분쟁 처리 기능을 직접 대체하지는 않는다. 따라서 실제 시스템에서의 질문은 "스테이블코인이냐 기존 레일이냐"가 아니라 각 레일의 강점이 요구되는 구간을 어떻게 나눌 것인가다.

아래 표는 거래 유형별로 권장 레일과 그 핵심 이유를 정리한 것이다.

이 조합 구조는 이미 구체적인 인프라로 구현되기 시작했다. x402는 에이전트가 API 호출과 동시에 스테이블코인으로 비용을 지불하는 마이크로페이먼트 레이어를 정의하고 있으며, Stripe는 카드·은행 레일을 API로 추상화해온 기존 구조 위에 스테이블코인 기반 결제와 정산 기능을 점진적으로 통합하며, 서로 다른 레일을 하나의 인터페이스 안에서 조합할 수 있는 방향으로 확장하고 있다.

결국 에이전틱 커머스에서 중요한 것은 스테이블코인이냐 카드냐가 아니라, 에이전트가 끊김 없이 실행될 수 있는 결제 구조를 ‘어떻게 설계할 것인가’이다. 그리고 온체인 인프라가 컴플라이언스까지 흡수하는 방향으로 성숙해갈수록 그 설계의 기준선도 함께 이동할 것이다.