🛒 03. Base·USDC가 Agent Commerce에 잘 맞는 이유

Agent Commerce를 실제로 붙여보면 금방 드러나는 사실이 있다. AI가 똑똑한 것만으로는 부족하고, 작은 금액을 빠르게 보내고 바로 결과를 받아오는 결제 레일이 같이 있어야 한다는 점이다. 이 관점에서 보면 Base와 USDC 조합이 자주 등장하는 이유가 꽤 명확해진다.

핵심은 세 가지다. 첫째, 소액 결제가 가능해야 한다. 둘째, 정산이 빨라야 한다. 셋째, 가격이 크게 흔들리지 않아야 한다. 이 세 조건을 동시에 놓고 보면 Agent Commerce 실험에서는 Base 같은 저비용 체인과 달러 기반 스테이블코인인 USDC가 꽤 자연스러운 선택이 된다.

flowchart LR
A[소액 결제] --> D[Base · USDC]
B[빠른 정산] --> D
C[가격 안정성] --> D
D --> E[요청형 결제 실험]

칠판 판서형 치트시트

• Agent Commerce에는 똑똑한 모델만큼 가벼운 결제 레일이 중요하다.
• Base는 저비용·빠른 처리, USDC는 달러 기준 안정성이 강점이다.
• 카드 결제는 범용성이 높지만 마이크로 결제에는 무거울 수 있다.
• 결국 핵심은 기술 우열보다 운영 마찰이 얼마나 적은가다.

왜 카드만으로는 아쉬운가

기존 카드 결제는 이미 강력한 인프라다. SaaS 구독, 광고비, 업무 도구 결제처럼 반복적이고 익숙한 지출에서는 여전히 매우 유용하다. 하지만 Agent Commerce가 겨냥하는 흐름은 조금 다르다. 요청이 들어올 때마다 소액으로 유료 리소스를 사 오고, 그 결과를 다음 액션에 연결해야 하는 구조가 많다.

이런 상황에서는 회원가입, 카드 등록, 정액제 선택, API 키 발급 같은 절차가 너무 무겁게 느껴질 수 있다. 한두 번 결제하는 데는 문제가 없어도, 수많은 작은 요청이 반복되는 환경에서는 그 마찰이 크게 보인다.

Base와 USDC가 주목받는 이유

Base는 상대적으로 저렴하고 빠른 처리 경험을 제공하는 체인으로 자주 언급된다. 여기에 USDC를 얹으면 “얼마를 썼는지”를 달러 감각으로 이해하기 쉽고, 가격 변동성 때문에 결제 판단이 흔들리는 문제도 줄어든다. 즉, 기술적으로도 편하지만 운영적으로도 설명이 쉽다.

이 조합이 특히 잘 맞는 장면은 요청형 결제다. 누군가 API 하나를 쓰기 위해 월 구독부터 여는 것이 아니라, 필요한 순간에 작은 금액만 결제하고 바로 결과를 가져오는 흐름이다. Agent Commerce에서 중요한 것은 “한 번 크게 결제하는 것”보다 “필요할 때 짧게 지불하고 다음 행동으로 이어가는 것”에 가깝다.

미니 사례로 보면 더 쉽다

첫 번째 사례는 유료 데이터 조회다. 에이전트가 특정 트윗이나 Article 전문이 필요할 때 소액 USDC로 접근권을 결제하고, 바로 결과를 회수하는 구조는 정액제형 API보다 훨씬 가볍다. 사람이 할 일은 카드 등록이 아니라 한도와 승인 기준을 정하는 쪽으로 옮겨간다.

두 번째 사례는 글로벌 소액 정산 실험이다. 여러 지역의 사용자나 파트너를 상대로 작은 금액을 자주 움직여야 하는 경우, 카드나 계좌보다 처리 흐름이 단순한 레일이 더 유리할 수 있다. 물론 모든 경우에 스테이블코인이 답은 아니지만, 적어도 Agent Commerce 초기 실험에서는 확실히 잘 맞는 조합으로 보인다.

VAN·PG사는 무엇을 준비해야 하나

여기서부터는 질문을 더 좁혀서 봐야 한다. 기존 VAN·PG사가 Agent Commerce 흐름까지 포함해 다음 제품을 만들고 싶다면, 단순히 “스테이블코인도 받는다” 수준으로는 부족하다. 진짜로 필요한 것은 에이전트가 안전하게 결제하고, 공급사가 안전하게 정산받고, 조직이 나중에 설명할 수 있게 만드는 운영 레이어다.

즉, 준비해야 할 것은 크게 여섯 가지다.

1) 에이전트 친화적 결제 API

기존 결제 API는 사람이 체크아웃 화면을 보고 클릭하는 흐름에 최적화돼 있다. Agent Commerce에서는 반대로 에이전트가 요청 단위로 승인 상태를 확인하고, 결제하고, 재시도하고, 결과를 회수하는 구조가 필요하다. VAN·PG 입장에서는 이 차이가 중요하다. 기존 온라인 결제를 그대로 붙이는 것이 아니라, 사용량 기반 호출이나 디지털 자산 접근에 맞는 API 레이어를 따로 준비해야 한다.

2) 정책 엔진과 승인 규칙

이 부분이 실제로 가장 중요하다. 에이전트 결제를 허용하려면 금액 한도, 공급사 allowlist, 카테고리 제한, 시간대 제한, 재시도 제한 같은 규칙이 먼저 있어야 한다. Stripe가 spending controls에서 merchant category, merchant ID, 국가, 건당 한도, 월 한도를 나누어 통제하는 것도 같은 맥락이다. (https://docs.stripe.com/issuing/controls/spending-controls)

VAN·PG가 여기서 제공해야 할 것은 단순 승인 버튼이 아니라, “어떤 요청은 자동 통과, 어떤 요청은 담당자 승인, 어떤 요청은 거절”을 기계가 읽을 수 있는 정책 구조다. Agent Commerce에서 경쟁력은 결제 처리 속도만이 아니라 이 정책 엔진의 정교함에서 나온다.

3) 소액·고빈도 결제에 맞는 과금 구조

기존 PG 수익 구조는 상대적으로 건당 금액이 큰 전자상거래, 반복 구독, 정산 중심으로 설계돼 있다. 하지만 Agent Commerce는 0.001달러, 0.01달러처럼 매우 작은 호출이 많이 발생할 수 있다. 이 구조에서는 기존 수수료 체계가 그대로 맞지 않을 수 있다.

그래서 VAN·PG는 “건당 승인 수수료”만 볼 것이 아니라,

• 호출 묶음 과금
• 월간 usage 정산
• 프리미엄 정책 엔진 요금
• 리스크 관리·감사 로그 부가 요금 같은 새로운 가격 구조까지 함께 설계해야 한다. 단순 결제사가 아니라 에이전트용 상거래 인프라 사업자로 포지셔닝이 바뀌는 셈이다.

4) 정산·원장·증빙 구조

Agent Commerce에서 무서운 건 승인보다 사후 처리다. 누가 얼마를 썼는지, 어떤 정책으로 통과됐는지, 어떤 공급사로 흘렀는지, 환불이나 실패는 어떻게 반영됐는지가 남아야 한다. 특히 VAN·PG가 이 시장에서 강점을 가질 수 있는 이유는 이미 정산, 원장, 증빙, 사후 처리 역량을 가지고 있기 때문이다.

즉, 앞으로 필요한 것은 단순 결제 승인 API가 아니라 다음을 함께 제공하는 구조다.

• 호출별 결제 로그
• 정책 판정 로그
• 공급사별 정산 내역
• 부서/프로젝트별 비용 태깅
• 환불·실패·중복 호출 처리 기록

이 다섯 가지가 붙어야 기업 고객은 안심하고 붙일 수 있다.

5) 지갑/스테이블코인 연결 역량

Base·USDC가 자주 언급되는 이유는 기술 취향이 아니라 운영 마찰이 낮기 때문이다. 따라서 VAN·PG가 이 영역에 들어오려면 최소한 스테이블코인 수납/정산을 기존 결제 체계와 어떻게 연결할지에 대한 전략이 있어야 한다. 모든 회사를 직접 수탁 사업자로 만들 필요는 없겠지만, 적어도 다음 중 하나는 준비해야 한다.

• 외부 지갑/수탁사와 연동하는 방식
• 스테이블코인 정산을 현행 원장과 연결하는 방식
• 법무·컴플라이언스 검토를 거친 제한적 파일럿 구조

핵심은 “온체인 결제를 받는다”가 아니라, 온체인 결제를 기존 결제·정산 세계에 어떻게 무리 없이 붙일 것인가다.

6) 공급사 온보딩 구조

Agent Commerce는 구매자 측만 중요한 게 아니다. 결국 공급사도 이 흐름을 이해하고 붙어야 한다. 유료 API 사업자, 데이터 공급사, SaaS 사업자, 콘텐츠 판매자가 “우리 엔드포인트를 에이전트가 안전하게 살 수 있다”는 형태로 온보딩돼야 한다. 그래서 VAN·PG는 가맹점 onboarding을 하던 경험을 Agent Commerce용으로 다시 써야 한다.

예를 들면 공급사 onboarding 시 아래 항목이 필요해질 수 있다.

• 이 자원은 어떤 단위로 팔 것인가
• 환불이 가능한가
• 일별/월별 한도를 둘 것인가
• 어떤 결과를 응답으로 돌려줄 것인가
• 정책 위반 시 즉시 차단 가능한가

결국 VAN·PG의 역할은 승인 네트워크 운영에서 끝나는 게 아니라, 에이전트가 살 수 있는 공급사 네트워크를 만드는 쪽으로 넓어진다.

그럼 누가 움직여야 하나

여기서 말하는 “실무자”를 더 뾰족하게 잡아보면 다음 사람들이다.

1) PG/VAN 프로덕트 매니저

무엇을 먼저 상품화할지 정하는 사람이다. 기존 결제 API 확장으로 갈지, Agent Commerce 전용 승인/정책 상품으로 갈지, 어떤 고객군부터 열지 결정해야 한다. 이 역할이 중심축이다.

2) 결제 플랫폼/정산 엔지니어

기존 승인·정산·원장 시스템과 에이전트용 호출 구조를 연결해야 한다. 이 사람들은 단순 API 개발자가 아니라, 결제 흐름과 실패 처리까지 이해하는 엔지니어여야 한다.

3) 리스크·부정거래·승인정책 담당자

Agent Commerce에서는 fraud보다도 오사용과 과다지출 통제가 먼저 중요할 수 있다. 카드 부정거래 감각을 갖고 있는 리스크 팀이 spending policy 설계에 들어와야 한다.

4) 재무/정산 운영 담당자

결제 자체보다 나중에 더 많이 보게 되는 사람이 이쪽이다. 비용 귀속, 정산, 환불, 증빙, 월말 마감에 문제 없도록 구조를 미리 확인해야 한다.

5) 법무/컴플라이언스 담당자

특히 스테이블코인, 해외 정산, 지갑 연동이 들어오면 법무와 컴플라이언스 검토가 초반부터 같이 붙어야 한다. 이 파트가 뒤늦게 들어오면 파일럿은 거의 멈춘다.

6) 세일즈/파트너십 담당자

결국 공급사와 고객사를 온보딩해야 하므로, 실제 어떤 산업군이 가장 빨리 붙는지 보는 사람도 필요하다. 특히 데이터 사업자, API 사업자, SaaS 사업자와의 파트너십 감각이 중요해진다.

즉, 이 일은 “블록체인팀” 하나가 하는 프로젝트가 아니라, 결제 PM + 플랫폼 엔지니어 + 리스크/재무/법무 + 파트너십이 함께 들어와야 돌아간다.

어디서부터 시작하는 게 현실적인가

처음부터 소비자 결제 전체를 Agent Commerce로 바꾸려 하면 거의 항상 무리다. VAN·PG 입장에서는 아래 순서가 훨씬 현실적이다.

1단계: 폐쇄형 B2B 파일럿

가장 먼저는 승인된 고객과 승인된 공급사만 있는 좁은 환경에서 시작하는 게 좋다. 예를 들면 유료 데이터 API, 로그/관측 툴, 클라우드 크레딧, SaaS add-on 구매처럼 목적이 분명한 분야가 적합하다.

2단계: 정책 콘솔 제공

그다음은 자동 허용, 담당자 승인, 월 한도, 공급사 allowlist를 설정할 수 있는 Agent Spend Console을 붙여야 한다. 이게 없으면 기술 데모를 넘어 상품으로 가기 어렵다.

3단계: 정산/증빙 자동화

호출별 비용을 부서, 프로젝트, 공급사 기준으로 태깅하고, 정산/환불/이상징후 리포트를 자동으로 뽑아줄 수 있어야 한다. 여기서부터 고객은 “실험”이 아니라 “운영 가능”으로 보기 시작한다.

4단계: 온체인·오프체인 혼합 정산

마지막에는 Base·USDC 같은 온체인 레일과 기존 카드/계좌 기반 정산을 함께 운영하는 혼합 구조가 필요해질 가능성이 높다. 모든 결제가 스테이블코인으로 가는 게 아니라, 에이전트 친화적인 구간에서 먼저 온체인이 쓰이고 나머지는 기존 레일이 유지되는 구조가 더 현실적이다.

미니 사례로 보면 더 선명하다

미니 사례 1: PG사의 데이터 API 결제 파일럿

기존 PG사가 콘텐츠/데이터 공급사와 손잡고, 승인된 기업 고객만 접근 가능한 유료 API 마켓을 연다고 가정해 보자. 여기서 필요한 것은 단순 결제창이 아니라 호출당 과금, 월 한도, 공급사 allowlist, 부서별 정산 태그다. 이건 기존 PG 역량 위에 Agent Commerce 레이어를 얹는 방식이다.

미니 사례 2: VAN사의 기업 지출 라우팅 확장

VAN사가 오프라인 승인 네트워크 경험을 살려, 기업 내부 에이전트가 요청한 유료 API 호출을 공급사별로 라우팅하고 승인 규칙에 따라 자동 통과/보류/거절을 나누는 구조를 만든다고 생각해 보자. 이 경우 강점은 결제 실행보다 정책 라우팅과 정산 신뢰 쪽에서 나온다.

이 편에서 꼭 남겨야 할 판단 기준

이 글을 읽고 나서 남아야 할 질문은 이 세 가지다.

1. 우리는 단순히 스테이블코인 수납을 붙이려는가, 아니면 에이전트용 상거래 레이어를 만들려는가
2. 우리 조직 안에 PM, 결제 엔지니어, 리스크, 재무, 법무, 파트너십이 같이 움직일 준비가 돼 있는가
3. 소비자 전체 시장보다 먼저 폐쇄형 B2B 파일럿으로 시작할 수 있는가

세 질문에 답이 잡히면, VAN·PG도 Agent Commerce를 막연한 트렌드가 아니라 실제 제품 전략으로 다룰 수 있다.

다음 글

다음 글에서는 기술보다 더 중요한 운영 설계, 즉 자동 결제 전에 필요한 승인 규칙과 spend policy를 다룬다. 실제 도입은 결국 여기서 갈린다.

다음 읽기

• 🛒 02. x402를 쉬운 그림으로 이해하기
• 🛒 00. Agent Commerce 로드맵
• 🛒 Agent Commerce 허브

이 문서는 AI를 활용해 초안을 구성했으며, 공식 문서와 실험 사례를 기준으로 계속 보강한다.