Agent Factory Recap: 내 쇼핑을 해줄 수 있나요?

발행: 5일 전 (2025년 12월 20일 오전 04:44 GMT+9)

13 min read

I’m happy to translate the article for you, but I need the text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line, formatting, markdown, and any code blocks exactly as they are while translating the rest into Korean.

빠른 시작 가이드

아래 타임스탬프를 사용하여 관심 있는 섹션으로 바로 이동하세요. 각 구간에는 짧은 요약과 쇼 노트의 관련 부분으로 연결되는 링크가 포함되어 있습니다.

Timestamp	Segment	Summary
[01:43]	The Trust Problem	AI 티켓 구매 에이전트가 여러분의 금전 및 개인 데이터를 신뢰받아야 하는 이유.
[02:29]	Why the Current Payment Stack Fails Agents	권한 부여, 에이전트 오류, 책임성이라는 세 가지 핵심 문제와 Agent Payment Protocol (AP2)이 이를 해결하는 방법.
[04:33]	Roles & Separation of Concerns	AP2 생태계의 네 가지 전문 참여자와 쇼핑 에이전트가 원시 카드 데이터를 절대 다루지 않는 이유.
[06:15]	Verifiable Credentials (VCs)	합의의 암호학적 증거 역할을 하는 세 가지 위임 유형(카트, 인텐트, 결제).
[08:03]	Contractual Conversational Model	인간이 직접 참여하는 구매 흐름을 단계별로 살펴보며, 위임부터 최종 승인까지 진행.
[13:07]	Q&A – Trust & Registries	허용 목록, 탈중앙화 레지스트리, 웹 표준 신원 검증이 단기·장기 로드맵에 어떻게 들어가는지.
[14:42]	Payments‑Grade Security	A2A와 MCP 위에 추가된 AP2의 “결제 등급” 보안 보장.
[16:03]	Chargeback Protection	잘못된 제품이 승인될 경우, 서명된 카트 위임이 상인과 사용자를 보호하는 방법.
[18:04]	Live Demo	인간이 직접 참여하는 흐름을 단계별로 시연한 데모 (영상 링크).

1️⃣ 신뢰 문제 (01:43)

“에이전트가 티켓이 판매되는 순간 바로 콘서트 티켓을 구매해줄 수 있다면 어떨까요? 당신은 티켓 두 장, 최대 지출 $200, 좋은 좌석을 원합니다. 에이전트를 티켓 구매자로 지정하려면 전체 요청 과 신용카드 정보를 넘겨줘야 합니다. 에이전트가 200장을 사거나 평생 동안 고무 오리 물품을 청구하지 않을지 어떻게 확신할 수 있을까요?”

이 시나리오는 에이전트 기반 상거래를 저해하는 신뢰 위기를 보여줍니다.

솔루션 미리보기: 구글의 Agent Payment Protocol (AP2) – 기존 결제 인프라 위에 놓이는 개방형 “신뢰‑레이어” 표준.

2️⃣ 왜 기존 결제 방식은 에이전트에게 맞지 않을까 (02:29)

Challenge	Human‑Centric System	Agent‑Centric Gap
Authorization	브라우저와 UI가 사용자에게 직접 제어권을 제공합니다.	에이전트는 프로그래밍 방식의 사전 승인된 권한이 필요합니다.
Agent Error	UI 오류는 눈에 보이며 사용자가 취소할 수 있습니다.	무음 실패는 원치 않는 구매를 초래할 수 있습니다.
Accountability	청구 취소는 사람에게 추적됩니다.	자율적인 행동에 대한 명확한 감사 추적이 없습니다.

AP2는 에이전트, 상인 및 결제 파트너 간에 안전하고 검증 가능한 통신 채널을 제공함으로써 이러한 문제를 해결합니다. 현재는 A2A (Agent‑to‑Agent) 프로토콜의 확장 형태로 제공되며, 에이전트가 **Model Context Protocol (MCP)**을 사용하도록 요구합니다.

👉 자세히 알아보기: AP2 technical overview (PDF)

3️⃣ Roles & Separation of Concerns (04:33)

프로토콜은 책임을 네 가지 전문 역할로 나눕니다:

Shopping Agent – 제품을 찾아내고 구매를 조정하는 AI.
Merchant Endpoint – 장바구니 데이터와 최종 주문을 받는 판매자 API.
Credential Provider – 결제 자격 증명을 저장하는 안전한 디지털 지갑(예: PayPal, Google Pay).
Merchant Payment Processor – 결제 네트워크를 위한 최종 인증 토큰을 생성합니다.

Critical: 쇼핑 에이전트는 절대 원시 신용카드 번호를 보지 않으므로 PCI 준수가 필요하지 않습니다. 결제 데이터는 Credential Provider와 Processor 내에 머무릅니다.

4️⃣ 검증 가능한 자격증명 (VCs) (06:15)

VCs는 암호학적으로 서명된 디지털 영수증으로, 합의된 내용을 증명합니다. AP2는 세 가지 위임 유형을 정의합니다:

VC 유형	사용 사례	증명 내용
Cart Mandate	Human‑present (사용자가 장바구니 검토)	사용자가 정확한 장바구니 내용을 승인했습니다.
Intent Mandate	Human‑not‑present (예: 티켓‑buying 에이전트)	사용자가 제한 조건과 함께 의도를 승인합니다 (예: “spend ≤ $200”).
Payment Mandate	모든 결제	결제 네트워크는 AI 에이전트가 참여했음을 확인하여 규정 준수 요구를 충족합니다.

5️⃣ 계약형 대화 모델 (08:03)

인간‑참여 흐름 (단계별)

위임 – 에이전트에게 “콘서트 티켓 두 장을 구매해 주세요.” 라고 말합니다.
탐색 및 협상 – 에이전트가 가맹점 엔드포인트에 연락해 임시 장바구니를 구성합니다.
장바구니 최종 확정 – 에이전트가 귀하의 Credential Provider에 결제 수단을 요청합니다. 귀하는 마스크된 참조(예: 마지막 4자리)만 확인합니다.
위임을 통한 승인 – 에이전트가 최종 장바구니를 귀하에게 제시합니다.
서명 – 귀하는 Cart Mandate에 암호화 서명을 합니다 → 부인할 수 없는 계약.
구매 – 에이전트가 서명된 위임을 가맹점에 전달합니다.
결제 처리기 – 위임을 사용해 Credential Provider에서 결제 토큰을 가져와 거래를 완료합니다.

신뢰 메커니즘 (단기): 승인된 에이전트/가맹점의 수동 허용 목록.
장기 비전: 자동화된 신원 검증을 위해 오픈 웹 표준(HTTPS, DNS 소유권)을 활용합니다.

6️⃣ Q&A – Trust & Registries (13:07‑14:42)

Higher‑level trust for payments – AP2는 기본 A2A/MCP 프로토콜 위에 “payments‑grade security”를 추가합니다.
Decentralized registries – 단기적으로 허용 목록을 사용하고, 향후에는 분산 신뢰 레지스트리와 DNS 기반 검증에 의존합니다.
Industry alignment – 모든 역할(merchant, credential provider, processor)은 이미 존재하며, Shopping Agent만이 새로운 참여자입니다.

7️⃣ 청구 취소 보호 (16:03)

시나리오: 에이전트가 파란색 신발을 보여주었지만, 당신은 청록색을 원했으며, “Approve”를 클릭했습니다.

해결책: 서명된 Cart Mandate는 당신이 승인한 내용(파란 신발)을 정확히 기록합니다. 이제 가맹점은 암호화된 증거를 보유하게 되어 사기성 청구 취소로부터 보호받으며, 동시에 당신도 무단 에이전트 행동으로부터 보호됩니다.

8️⃣ Live Demo – Human‑Present Flow (18:04)

Watch the demo: [YouTube 링크 – Human‑Present AP2 Flow]

데모는 섹션 5에 설명된 각 단계를 순서대로 진행하며 UI 프롬프트, 자격 증명 제공자 상호 작용 및 최종 권한 부여를 보여줍니다.

📚 추가 읽을거리 및 자료

Agent Payment Protocol (AP2) Specification – [GitHub repo]
A2A (Agent‑to‑Agent) Protocol Overview – [Link]
Model Context Protocol (MCP) Docs – [Link]
Verifiable Credentials Data Model 1.0 – [W3C Recommendation]

토론 요약

시연된 시나리오
- 사용자는 제품을 탐색하는 에이전트와 상호작용했습니다.
- **자격 증명 제공자 (PayPal)**가 개입했습니다.
- 사용자는 PayPal을 통해 배송 및 결제 정보를 선택했으며, 에이전트는 해당 정보를 참조만 보았습니다.
- 사용자는 Cart Mandate에 서명하여 구매를 완료했습니다.
타임스탬프: [19:43]

기존 프레임워크와의 호환성

핵심 질문: LangGraph나 CrewAI와 같은 프레임워크와 호환되나요?
답변: 예.
- Prateek은 **Agent Payment Protocol (AP2)**가 프레임워크에 구애받지 않는다고 확인했습니다.
- 에이전트가 A2A(Agent‑to‑Agent) 또는 MCP(Merchant‑Credential Provider)와 통신할 수만 하면 AP2를 사용할 수 있습니다.
타임스탬프: [21:13]

시작하기

GitHub 저장소 방문 (Prateek이 제공한 링크).
역할 선택 – merchant, credentials provider 등.
선택한 역할에 대한 샘플 코드 탐색.

앞으로 나아가기: 동적 협상

“재고가 없는 빨간 드레스가 필요해. 내일까지 받아야 하고… 30 % 더 지불할게.”

상인의 에이전트가 이 의도를 해석할 수 있다.
드레스가 입고되면 에이전트가 자동으로 판매를 완료한다.
결과:
- 놓친 판매가 마크업이 포함된 완료 주문으로 전환된다.
- 사용자는 원하는 정확한 아이템을 받는다.

이 비전은 보안 결제 인프라가 진정으로 유용한 실세계 작업을 수행할 수 있는 에이전트를 위한 기본 단계임을 보여준다. 우리는 단순한 프로그래밍 웹에서 대화형, 계약형 웹으로 전환하고 있으며, AP2가 필요한 프레임워크를 제공한다.

행동 촉구

Agent Payment Protocol GitHub 저장소를 확인하세요.
역할을 식별하세요 이 새로운 생태계에서 당신이 수행할 수 있는 역할을.
구축을 시작하세요 오늘!

기여자

Shir Meir Lador → LinkedIn | X
Ivan Nardini → LinkedIn | X
Prateek Dudeja → LinkedIn