AI 에이전트 결제 시대 도래에 Cardadno는 어떻게 준비하고 있나

한국어 뉴스&공지사항
,
1

x402와 카르다노의 기술 지도

AI 에이전트 결제 시대 도래에 Cardadno는 어떻게 준비하고 있나

2026년 10월 23일

사람은 결제 버튼을 누르지만, 에이전트에게는 누를 손이 없습니다. 카드 번호를 입력하고, 약관에 동의하고, 인증 메일의 링크를 여는 일은 소프트웨어가 혼자 하기에 번거로운 정도가 아니라 설계상 막혀 있는 경우가 대부분입니다. 카르다노(Cardano) 재단이 카르다노가 x402 공식 SDK에 통합되었다고 발표한 것은 바로 이 막힌 자리를 겨냥한 일이었습니다.

소식만 보면 한 줄짜리입니다. 그런데 사양 문서를 열어 보면 이야기가 훨씬 깊어집니다. 에이다(ADA)로 API 값을 치른다는 문장 뒤에는 브로드캐스트하지 않은 서명 트랜잭션, UTXO 하나를 통째로 걸어 두는 재생 방지, 블록 확인 횟수를 정하는 정책 같은 장치가 줄지어 있으니까요.

먼저 밝혀 둘 것이 하나 있습니다. 이 통합은 상용 규모의 메인넷 검증 측면에서 이제 막 첫걸음을 뗀 초기 단계입니다. 기대와 한계를 같은 무게로 놓고 보는 것이 이 글의 출발점입니다.

에이전트에게 결제란 무엇인가

연구 보고서를 쓰는 에이전트를 떠올려 보시죠. 작성 도중 최신 시장 데이터가 딱 한 건 필요해졌습니다. 사람이라면 가입하고, 요금제를 고르고, 카드를 등록한 뒤 필요한 만큼만 쓰고 해지할 겁니다. 에이전트에게는 이 절차의 어느 한 칸도 자연스럽지 않습니다. 계정은 사람 이름으로 만들어지고, API 키는 사람이 발급하고, 구독은 사람이 해지하니까요.

에이전트에게 필요한 결제는 조건이 단순합니다. 요청 한 번에 값을 한 번 치르고, 계정 없이, 사람 손을 거치지 않고 끝나는 것. 건당 결제(pay-per-use)라고 불러도 되겠습니다. 이걸 가능하게 하는 재료도 생각보다 단순합니다. 서비스가 가격을 기계가 읽을 수 있는 형태로 알려 주고, 에이전트가 그 가격에 서명하고, 서버가 서명을 믿어도 되는지 확인하면 됩니다. x402는 이 세 동작을 HTTP 안에 넣어 둔 규격입니다.

잊혀 있던 상태 코드, HTTP 402

웹 개발을 해 보셨다면 200과 404는 눈에 익으실 겁니다. 402(Payment Required)는 웹 초기 표준에서 장래 사용을 위해 이름만 예약돼 있던 코드였고, 수십 년 동안 사실상 비어 있었습니다. x402는 이 빈자리를 결제의 입구로 씁니다. 서버가 402와 함께 결제 조건을 돌려주면, 클라이언트가 결제 증거를 붙여 같은 요청을 다시 보내는 방식입니다.

이 규격은 코인베이스의 주도로 오픈소스화 및 표준화 워킹그룹으로 발전하였으며, 카르다노 재단 역시 오픈 표준 생태계의 구성원으로 합류했습니다. 규격은 체인에 중립적으로 설계돼 있어서, 체인마다 "돈이 실제로 어떻게 움직이는가"를 스킴(scheme)이라는 층에서 따로 정의합니다. 사양 문서에 따르면 EVM 계열의 exact 스킴은 서명 인가 방식을 고르고, XRP 레저는 시퀀스 번호 방식을 사용합니다. 카르다노도 같은 틀 위에 자기 방식을 얹었습니다. 그러니 "카르다노가 x402에 들어왔다"는 말의 실체는 카르다노용 스킴 사양과 그것을 구현한 SDK입니다.

한 번의 요청이 오가는 순서

흐름은 일곱 걸음으로 줄일 수 있습니다. 요청, 402 응답, 서명, 재요청, 검증, 정산, 응답.

클라이언트가 유료 API를 호출하면 서버는 402와 함께 결제 조건을 돌려줍니다. 어느 체인에서, 어떤 자산으로, 얼마를, 누구에게 보내라는 내용이 PAYMENT-REQUIRED 헤더에 담겨 옵니다. 에이전트는 조건을 읽고 트랜잭션을 만들어 서명하는데, 여기서 사양이 못 박는 대목이 있습니다. 서명만 하고 네트워크에는 보내지 않는다는 것입니다. 서명된 트랜잭션은 PAYMENT-SIGNATURE 헤더에 실려 같은 요청에 다시 붙어 갑니다.

서버는 트랜잭션을 직접 검증해도 되고 퍼실리테이터(Facilitator)에게 맡겨도 됩니다. 퍼실리테이터는 x402의 심부름꾼 서버라고 보시면 됩니다. 검증(/verify)은 읽기 전용이고, 정산(/settle) 단계에서야 비로소 트랜잭션을 블록체인에 제출합니다. 사양이 정한 순서는 검증, 리소스 처리, 정산이며, 정산 결과를 받은 서버가 200 응답과 PAYMENT-RESPONSE 헤더로 리소스를 내줍니다.

수수료는 클라이언트 몫입니다. 트랜잭션을 만들고 서명하는 쪽이 클라이언트이기 때문입니다. 퍼실리테이터는 제출만 하니 자금이 든 지갑이 따로 필요 없고, 수수료를 대신 내 주는 방식은 이번 사양 버전에서 지원하지 않는다고 사양 문서가 적어 두었습니다. 돈은 에이전트의 지갑에서 서비스로 곧장 가고, 가운데 서버는 그 길이 올바른지 확인해 주는 역할에 머뭅니다.

카르다노의 exact 스킴 뜯어보기

카르다노 사양의 이름은 exact입니다. 요구한 자산을 요구한 금액만큼 정확히 보내라는 뜻이고, 이 안에서 전송 방식이 셋으로 갈립니다. 기본형인 주소 간 송금, 에이전트 간 결제용 Masumi 에스크로, 서버가 정한 임의의 스마트 컨트랙트에 자금을 잠그는 스크립트 방식입니다. 네트워크 식별자는 cardano:mainnet, cardano:preprod, cardano:preview 세 가지를 씁니다.

카르다노다운 대목은 재생 방지에 있습니다. 같은 결제 서명을 두 번 써먹지 못하게 해야 하는데, 사양은 트랜잭션의 입력 UTXO 하나를 nonce로 지정하게 합니다. 그 UTXO는 결제 트랜잭션이 소비하므로 한 번 쓰이면 사라지고, 같은 UTXO를 근거로 한 두 번째 결제는 존재할 수 없습니다. 별도의 일련번호를 관리하지 않아도 확장형 UTXO(eUTXO) 모델의 성질이 곧 재생 방지 장치가 되는 셈입니다. SAP 애플리케이션용으로 나온 구현인 ODATANO 역시 재생 방어를 UTXO 모델 자체에 맡긴다고 설명합니다.

퍼실리테이터가 확인하는 항목은 사양에 아홉 가지 규칙으로 정리돼 있습니다. 네트워크, 수취 주소, 금액, 자산(정책 ID와 자산 이름까지 정확히 일치), nonce, 레저 규칙 사전 검사(입출력 가치 보존과 최소 수수료), 트랜잭션 유효기간(TTL), 최소 UTXO, 확인 횟수가 그것입니다. 유효기간은 현재 시각에 결제 조건의 maxTimeoutSeconds를 더한 시점을 넘을 수 없어서, 서명만 해 두고 쓰지 않은 결제는 스스로 만료됩니다. 사양 예시는 이 값을 600초로 잡고 카르다노 네트워크 속도를 고려해 길게 둔다는 주석을 달아 놓았습니다.

확인 횟수는 따로 짚을 만합니다. 카르다노가 쓰는 우로보로스 프라오스(Ouroboros Praos)는 확정성이 확률적이어서, 멤풀에 들어갔거나 최근 블록에 담긴 트랜잭션도 되돌려질 수 있습니다. 사양은 멤풀 단계에서 서비스를 내주는 것을 강하게 말리고, 굳이 그렇게 하겠다면 위험을 문서로 밝히고 롤백 손실을 책임지라고 적었습니다. 확인 정책 값은 -1(퍼실리테이터의 제출 수락)부터 20(이후 블록 20개)까지 정할 수 있고, 따로 정하지 않으면 1이 기본입니다.

Masumi 에스크로: 에이전트끼리의 결제

주소 간 송금은 단순하지만 신뢰 문제까지 풀어 주진 않습니다. 돈을 보냈는데 결과물이 오지 않으면 어떻게 될까요. 에이전트가 에이전트에게 일을 맡기는 순간 이 질문이 곧바로 따라옵니다. 사양이 Masumi를 별도 방식으로 둔 까닭입니다. 재단은 Masumi 팀과 함께 Masumi를 전송 방식으로 추가했습니다.

x402가 맡는 일은 에스크로(Escrow)에 돈을 잠그는 데까지입니다. 구매자가 vested_pay 컨트랙트에 자금을 넣으면 상태는 FundsLocked가 되고, 그 뒤의 결과 제출, 환불 요청, 분쟁 처리는 컨트랙트와 Masumi 결제 서비스의 몫입니다. 사양은 정산 성공이 판매자에게 돈이 전달됐다는 뜻이 아니라 에스크로에 잠겼다는 뜻이라고 분명히 적고 있습니다.

잠그는 순간의 설계는 꼼꼼합니다. 402 응답에는 판매자의 조건이 전부 들어 있고, 판매자는 가격, 자산, 컨트랙트 주소, 요청 해시, 마감 시각을 하나로 묶은 다이제스트에 CIP-30과 CIP-8 방식으로 서명합니다. 구매자는 요청 내용의 해시를 직접 검증한 뒤에야 19개 필드로 된 데이텀(Datum)을 만들어 자금을 잠급니다. 이 해시는 내가 돈을 낸 작업이 정확히 무엇이었는지를 나중에 분쟁이 생겨도 따질 수 있게 하는 기록이 됩니다. 마감 시각 사이에도 최소 간격(5분, 15분, 15분)이 요구됩니다.

더 눈여겨볼 대목이 있습니다. 잠글 때는 컨트랙트 검증기가 실행되지 않습니다. 데이텀이 잘못돼도 입금 단계에서 걸러지지 않고 자금이 갇혀 버릴 수 있다는 이야기입니다. 사양이 퍼실리테이터에게 잠금 조건 점검을 의무로 지운 이유가 여기 있습니다. 스크립트 방식은 한 발 더 나아갑니다. 서버가 정한 컨트랙트의 데이텀이 맞는지는 퍼실리테이터가 알 수 없으니, 그 책임은 서버에 있다고 사양이 못 박았습니다.

분쟁 때는 관리자 키가 등장합니다. 기본 배포는 관리자 키 세 개 중 두 개의 서명이 필요한 구조로, 구매자가 환불을 요청했는데 판매자가 결과를 제출해 분쟁 상태가 된 에스크로만, 정해진 시각이 지난 뒤에만 정산할 수 있습니다. 같은 키가 여러 번 등록되면 그만큼 가중치가 쌓이니 "3분의 2"라는 겉모습만 믿지 말라는 경고도 사양에 들어 있습니다.

다만 초기 재단 데모 저장소는 Masumi 방식에서 에스크로 해제, 환불, 분쟁 흐름을 온전히 갖추지 못했다는 점을 서술했습니다. 데모가 서명하는 termsDigest가 기존 결제 서비스 수명주기와 완전히 연결되지 않는 한계가 있어, 완벽한 자동 분쟁 해결까지는 추가적인 고도화가 필요한 상태입니다.

구현 현황

시간순으로 정리하면 이렇습니다. 재단은 카르다노 사양이 병합된 후 클라이언트, 서버, 퍼실리테이터 개발을 이어갔습니다. 카르다노 구현은 공식 x402 저장소에 탑재되었고, @x402/cardano 패키지는 npm을 통해 배포되고 있습니다. 설치는 npm install @x402/cardano 한 줄로 가능합니다.

써 볼 수 있는 자료도 마련되어 있습니다. 프리프로덕션 데모 환경에서 공식 npm 릴리스(@x402/cardano, @x402/core, @x402/express)를 활용해 브라우저 지갑으로 결제 조건, 서명된 트랜잭션, 정산 영수증을 주고받는 흐름을 시험할 수 있습니다. 생태계 측면에서는 Masumi와 ODATANO가 초기 도입 사례로 명시되었습니다. 지원 언어는 TypeScript 중심이며 Python 및 Go 언어용 SDK 확장이 다음 과제로 꼽힙니다.

검증 수준도 정확히 알아 둬야 합니다. Java 구현체 기반의 퍼실리테이터 테스트 기록 등 대규모 단위 테스트와 테스트넷(Preprod) 온체인 검증이 수행되었으나, 메인넷에서의 상업적 대량 트랜잭션 정산은 이제 막 시작되는 검증 단계입니다.

증명이 필요한 것들

냉정하게 보면 기존 주요 체인과의 거래량 격차가 존재합니다. XRP 레저는 x402 기반으로 상당한 수의 소액 결제 트랜잭션을 기록했고, 코인베이스는 베이스(Base)와 솔라나(Solana) 퍼실리테이터를 통해 대규모 처리량을 달성했습니다. 카르다노는 아직 메인넷 상업 규모의 결제 지표를 누적해 나가는 시점입니다.

사양을 따라가다 보면 설계상의 마찰도 보입니다. 하나는 지연입니다. 블록 생성 주기와 확인 횟수(기본값 1) 때문에 요청 한 번에 일정 시간의 대기 지연이 발생할 수 있습니다. 사양이 확인 횟수를 채우지 못했을 때를 위한 settlement_pending 상태와 재시도 규칙을 따로 둔 것도 이 때문입니다. 속도를 얻으려면 멤풀 수락을 택해야 하지만 롤백 위험은 서버가 떠안게 됩니다.

다른 하나는 최소 금액(Min UTXO)입니다. 카르다노의 모든 출력에는 크기에 비례하는 최소 에이다가 들어가야 합니다. 순수 에이다 결제라면 최소 약 1 ADA, 토큰 결제라면 토큰과 별개로 약 1.2~1.5 ADA가 보증금 형태로 함께 묶여야 합니다(coinsPerUtxoByte 4,310 lovelace 기준). 토큰 결제 시 에이다가 함께 이동해야 하는 eUTXO 구조 특성상, 센트 단위 이하의 극소액 결제를 건건이 L1에서 정산하기에는 구조적 한계가 존재합니다.

앞으로 지켜볼 것은

지켜볼 항목은 다섯 개로 압축됩니다.

  • 메인넷에서의 퍼실리테이터 대량 검증 소식
  • 첫 대표 상업 결제 서비스 등장
  • Python 등 다국어 SDK 확대
  • 실제 정산에 쓰이는 스테이블코인(USDM 등)의 유동성 범위
  • 체인 간 비교 가능한 실시간 호출량 수치

레이오스(Leios)는 별개의 성능 확장 트랙입니다. Ouroboros Leios 연구와 테스트넷 검증이 지속되고 있으며, 메인넷 적용 타임라인은 온체인 거버넌스 절차와 함께 차근차근 진행되고 있습니다. 카르다노 exact 스킴 사양 자체에는 레이오스에 관한 직접적 언급이 없으므로 두 기술이 레이어 1에서 어떻게 시너지를 낼지는 별개로 지켜볼 대목입니다.

한국 개발자에게는 두 가지 지점이 눈에 들어옵니다.

  • 서버 개발자: 데이터, 번역, 검색, 도메인 특화 API를 서비스할 때 기존 API 앞에 결제 레이어를 쉽게 얹을 수 있습니다.

  • 에이전트 운영자: UTXO 모델 특성상 에이전트가 병렬로 여러 요청을 결제하려면 지갑 내 UTXO를 미리 여러 조각으로 나누어 놓는(UTXO Management) 작업이 필요합니다.

사양은 갖춰졌고 메인넷 상용화의 입구에 서 있습니다. 카르다노의 eUTXO 모델이 결제의 재생 방지라는 과제를 깔끔하게 해결해 낸 만큼, 앞으로의 실환경 데이터가 기대되는 시점입니다.

다음 질문을 한번 생각해보면 좋겠습니다.

  • 최소 출력 비용 때문에 L1에서 건건이 정산하기 어려운 소액·고빈도 호출은 L1 정산, 히드라(Hydra) 같은 L2 State Channel, 선불 잔액(Prepaid Balance) 방식 중 어느 쪽이 현실적인 대안이 될까요?

  • 한국 개발자가 가장 먼저 x402 서버를 붙여보고 싶은 API 서비스는 무엇인가요?