AP2는 결제를 해결했을 뿐, 정산은 아니다. 에이전트 커머스가 여전히 둘 다 필요한 이유

지난주 Google과 Mastercard가 AP2를 FIDO Alliance에 넘겼다. 이 소식은 'AI 에이전트 결제가 방금 표준화되었다'라는 검증의 순간으로 에이전트 경제 채널을 통해 퍼져나갔다.

그것은 사실이다. 그리고 불완전하다.

AP2 (Agent Payments Protocol)는 한 가지 일에 매우 뛰어나다: 에이전트가 인증되고 지출 권한을 부여받았을 때 돈을 이동시키는 것. x402 (Linux Foundation의 HTTP 기반 결제)는 요청별로 HTTP 계층에서 돈을 이동시키는 데 매우 뛰어나다.

둘 다 **결제 레일(payment rails)**이다. 어느 것도 **정산 계층(settlement layer)**은 아니다.

블록체인 전반에 걸쳐 디지털 자산을 거래하는 에이전트나, 신뢰할 수 없는 제공자로부터 컴퓨팅 자원을 조달하는 경우, 이는 두 가지 다른 문제다. 만약 에이전트 커머스가 하나만 표준화한다면, 우리는 에이전트가 이체를 _승인_하는 방법은 해결했지만, 어떤 조건이 그것을 _해제_하는지는 해결하지 못하게 될 것이다.

AP2가 하는 것 (그리고 하지 않는 것)

AP2의 역할:

에이전트 인증 (이 에이전트가 주장하는 그 주체인가?)
지출 권한 부여 (이 에이전트가 X 토큰을 전송할 권한이 있는가?)
결제 경로 지정 (돈 이동시키기)

하지 않는 것:

돈이 무엇에 대항하여 움직이는지 정의하는 것
해제를 위해 충족되어야 하는 조건을 명시하는 것
최종성을 확립하는 것 (거래가 최종인지 누가 결정할 것인가?)

예시: AI 에이전트가 한 번도 만난 적 없는 제공자로부터 GPU 시간을 구매한다. 이들은 어느 쪽도 서로보다 더 신뢰하지 않는 체인 위에서 이루어진다.

AP2는 다음을 처리한다:

이 문제는 해결되었습니다. AP2, ERC-8183(에이전트 신원), 그리고 OAuth가 모두 여기서 작동합니다. FIDO가 AP2를 표준화 기구에 기부했다는 것은 다음과 같은 의미입니다: 이 계층은 표준화되고 있다는 것입니다.

레이어 2: 결제 라우팅 (Payment Routing) (x402가 처리)

"돈이 지불자(payer)로부터 수취인(payee)에게 물리적으로 어떻게 이동하는가?"

x402는 이 질문에 답했습니다: HTTP 요청 자체에 결제 자격 증명(payment credentials)을 포함시키는 것입니다. Hyperbolic은 이를 GPU 추론에 실제 환경에서 사용하고 있습니다. Coinbase와 Stripe도 이 생태계에 속해 있습니다.

이 계층 역시 상당 부분 해결되었습니다.

레이어 3: 정산 (Settlement) (여전히 미개척)

"돈이 실제로 손을 바꾸기 전에 어떤 조건이 충족되어야 하는가?"

바로 여기에 격차가 존재합니다.

에이전트-상인(agent → AWS, agent → Stripe): 정산은 수탁적(custodial)일 수 있습니다. AWS는 인보이스가 검증될 때까지 돈을 보관하고, Stripe가 중개합니다. 둘 다 신뢰할 수 있는 제3자입니다.

에이전트-에이전트(agent → agent) 또는 에이전트-비신뢰 제공업체(agent → 싱가포르의 임의 데이터 센터): 수탁적 정산은 작동하지 않습니다.

필요한 조건은 다음과 같습니다:

암호학적 (Cryptographic) (제3자를 신뢰할 필요 없이 증명 가능)
크로스체인 (Cross-chain) (지불자와 수취인이 다른 블록체인에 있을 때 작동 가능)
원자성 (Atomic) (양쪽 모두 완료되거나 양쪽 모두 환불됨)

다양한 시스템의 '정산' 답변 방식

Apex Fusion Vector

정산 조건: 스테이킹된 평판(Staked reputation) + 보증 에스크로(bonded escrow) + 배심원 기반 분쟁 해결 + 서명된 영수증.

최종성 모델 (Finality model): 경제적(Economic). 스테이킹 참여자들로 구성된 배심원이 작업의 유효성에 대해 투표합니다. 만장일치에 도달하면, 그 정산은 쿼럼 공격을 하는 것이 재정적으로 비싸기 때문에 최종적입니다.

장점: 하나의 생태계 내에서 작동합니다. 규모가 큰 곳에서 입증되었습니다 (2026년 9월 기준 20,000개 이상의 작업 패키지).

한계: 배심원은 인센티브를 가진 신뢰할 수 있는 제3자이지, 암호학적 보장은 아닙니다. 공유 평판 인프라가 필요합니다.

Hashlock (HTLC 기반)

정산 조건: 암호학적 사전 이미지(preimage) (자산을 위해) 또는 하드웨어 증명(hardware attestation) (컴퓨팅을 위해).

최종성 모델(Finality model): 암호학적 방식. HTLC는 해시 원상태(hash preimage)가 공개되거나 증명(attestation)이 검증될 때 자금을 방출한다. 배심원단도, 중개자도 없다. 장점: 신뢰 최소화(Trust-minimized). 네이티브하게 크로스체인 작동. 생태계 평판에 의존하지 않는다. 한계: 자본 잠금(Capital lockup). 시간 초과 위험(Timeout risk). 증명은 여전히 트러스트 루트로서 하드웨어 CA를 필요로 한다 (완전한 신뢰 제거는 아님). ### Akash Network 정산 조건(Settlement condition): 활성 상태(Liveness) (프로바이더가 온라인 상태를 유지하는 것). 최종성 모델: 행동적 + 평판 기반. 에스크로에서 블록당 자금이 소진된다. 오프라인이 되면 수입을 잃는다. 온체인 평판 점수와 결합된다. 장점: 간단하다. 가동 시간에 대한 인센티브 정렬(Incentive-aligned)이다. 한계: 활성 상태 ≠ 정확성(Correctness). 프로바이더가 온라인 상태이더라도 잘못된 출력을 제공할 수 있다. 자세한 내용은 Sep 30 post을 참조하라. ## 에이전트 표준에 이것이 중요한 이유 만약 AP2 + x402가 정산 계층 표준 없이 에이전트 결제 표준이 된다면, 다음과 같은 일이 발생한다: 시나리오 1: 에이전트 → 상점 (문제없이 작동) - Stripe 또는 OKX 또는 Coinbase가 정산을 중개한다. - AP2는 지급을 신뢰할 수 있는 프로세서로 라우팅한다. - 정산은 수탁적(custodial)이지만 받아들여진다. 시나리오 2: 에이전트 → 크로스체인 에이전트 (오류 발생) - AP2가 지급을 라우팅한다. - 하지만 그 다음에는 어떻게 될까? - 두 에이전트 모두 돈을 보관할 제3자에게 동의하는가? (중앙화, 높은 신뢰 필요) - 배심원단을 이용한 경제적 최종성(economic finality)을 사용하는가? (공유 평판 기질 필요) - HTLC를 사용한 암호학적 최종성을 사용하는가? (완전히 다른 프로토콜 필요) 현재로서는 AP2 + x402는 이에 대해 아무것도 말하지 않는다. ## 표준이 포함해야 할 내용 완전한 에이전트 커머스 표준에는 다음이 필요하다:**

인증 및 권한 부여 (Authentication & authorization) (AP2가 처리함) ✓
결제 라우팅 (Payment routing) (x402가 처리함) ✓
정산 조건 (Settlement condition) (미해결 — 아직 표준 없음)
최종성 모델 (Finality model) (미해결 — 평판 기반 vs 암호화 방식)
크로스체인 원자성 (Cross-chain atomicity) (미해결 — HTLC 또는 이에 상응하는 것이 필요함)

1번과 2번은 표준화하여 출시할 수 있습니다. 가맹점들은 만족합니다. 에이전트 대(對) 가맹점 결제는 작동합니다.

하지만 에이전트 대(對) 에이전트 상거래, 또는 신뢰할 수 없는 인프라에서의 컴퓨팅 구매에는 여전히 정산에 대한 답변이 필요합니다.

실제 논쟁거리

에이전트 표준 커뮤니티가 던져야 할 질문 (그리고 대부분 그렇지 않은)은 다음과 같습니다:

정산을 에이전트 상거래의 일부로 표준화해야 하는가, 아니면 애플리케이션이 구현하도록 맡겨야 하는가?

묶음(Bundling) 주장: 모든 에이전트 프레임워크가 정산을 다르게 구현한다면 (어떤 것은 Vector를 사용하고, 어떤 것은 Hashlock을 사용하며, 어떤 것은 수탁 에스크로를 사용함), 에이전트는 변환 위험 없이 프레임워크 경계를 넘어 상호 운용할 수 없습니다.

개방(Leaving it open) 주장: 정산은 사용 사례별로 다릅니다. 컴퓨팅 비용을 지불하는 에이전트는 증명 기반의 정산이 필요합니다. 자산을 교환하는 에이전트는 HTLC 정산이 필요합니다. 인간에게 비용을 지불하는 에이전트는 수탁 정산이 필요합니다. 하나의 표준으로는 어느 것도 충족할 수 없습니다.

Hashlock의 입장: 우리는 개방형 사례(에이전트 ↔ 에이전트, 크로스체인, 신뢰할 수 없는 환경)를 위해 원자적 정산을 구축했습니다. AP2와 x402는 좋은 보완재입니다. 이들은 결제 통로(payment rail)를 처리합니다. 그 아래의 정산 계층은 여전히 해결되지 않은 부분입니다.

우리는 표준으로 자리매김하려는 것이 아닙니다. 우리는 정산 문제에 대한 하나의 답변으로서 자리매김하고 있으며, 이에 대해 공개적으로 구축하고 있습니다.

주목할 점

2026년 10월: AP2가 FIDO로 이관됩니다. 초기 구현 단계에서 정산(Settlement) 거버넌스에 대한 질문을 주목해야 합니다.
2026년 4분기: Vector (Apex Fusion)는 에이전트 작업 정산을 계속 확장합니다. 배심원 기반 정산 방식이 인식을 얻게 된다면, 암호화 방식은 틈새 시장에 머무를 것입니다.
2027년: 만약 에이전트 간 상거래가 정산 표준 없이 성장한다면, 파편화(각 프레임워크가 내부적으로 표준화)되거나 새로운 표준(IETF AGTP Commerce는 정산을 언급하지만 여전히 초안 단계)이 생겨날 것입니다.

열린 질문 (The Open Question)

에이전트 상거래 표준은 처음부터 정산을 포함해야 한다고 생각하십니까, 아니면 산업이 정산을 애플리케이션 계층 문제로 기능할 수 있을까요?

동의: 정산 표준화는 상호 운용성(interoperability)에 매우 중요합니다.

비동의: 결제(Payment)와 인증(auth)만으로 충분하며, 정산은 애플리케이션별이므로 표준화될 수 없습니다.

여러분의 의견을 알려주세요.

더 알아보기 (Explore more):

UTM: hashlock.markets/?utm_source=devto&utm_medium=blog&utm_campaign=2026-10-01-ap2-settlement

AP2는 결제(Payments)를 해결했지만, 정산(Settlement)은 아니다. 에이전트 커머스가 둘 다 필요한 이유

요약

핵심 포인트