구글 AP2, AI가 회사 카드 긁는 시대의 결제 표준 — 재무·조달이 지금 준비할 것

구글 AP2와 에이전트 결제 표준 경쟁 — AI가 회사 카드를 긁기 시작하면 재무·조달은 뭘 바꿔야 하나요

AP2는 AI 에이전트의 결제를 암호서명된 위임장(Mandate)으로 증명하는 개방형 프로토콜입니다. 구글이 2025년 9월 17일 60개 이상의 결제·기술 기업과 함께 공개했어요.¹

장면부터 그려볼게요. 조달 담당 대리가 사내 에이전트에게 "다음 주 워크숍용 노트북 거치대 30개, 12만 원 이하로 사줘"라고 말합니다. 에이전트는 견적을 비교하고, 법인카드로 결제하고, 영수증을 회계 시스템에 올립니다. 사람 손은 문장 하나뿐이었어요.

그런데 카드값이 청구된 뒤 물건이 오지 않으면요? 승인자는 대리일까요, 에이전트일까요, 그 에이전트를 붙여둔 IT팀일까요.

이 질문에 답하려고 만들어진 게 AP2입니다.

한눈 요약

1. AP2는 결제 수단이 아니라 "이 거래를 사람이 진짜 위임했다"를 증명하는 계층입니다.
2. 증명 단위는 서명된 Mandate 두 장 — 의도(Intent)와 장바구니(Cart)예요.
3. 표준은 아직 한 곳으로 수렴하지 않았고, 구글·Visa·Mastercard·OpenAI 진영이 서로 다른 지점을 노립니다.
4. 어느 표준이 이기든 조직이 지금 준비할 건 같습니다. AX Lab은 이를 3중 승인선으로 정리했어요.

구글 AP2가 정확히 뭘 하는 건가요?

기존 결제 위에 "위임의 증거"를 한 겹 얹습니다. 카드·계좌이체·스테이블코인을 대체하는 게 아니라, 그 위에 검증 가능한 자격증명(Verifiable Credential, 발급자가 서명해 제3자가 진위를 검증할 수 있는 디지털 증명)으로 서명된 Mandate를 붙이는 구조예요.

핵심은 서명 두 장입니다. Intent Mandate는 사용자의 최초 요청과 조건을 담아요. 가격 상한, 시점, 그 밖의 제약이 여기 들어갑니다. Cart Mandate는 에이전트가 고른 장바구니를 사용자가 승인한 순간 만들어져요. 품목과 금액이 바뀔 수 없게 못을 박는 기록입니다.¹ 여기에 결제 수단을 장바구니에 묶어 결제망으로 넘기는 Payment Mandate가 더해집니다.

사람이 자리에 없어도 굴러갑니다. "콘서트 티켓 풀리는 즉시 사줘" 같은 위임은 Intent Mandate를 미리 서명해두면, 조건이 충족된 순간 에이전트가 Cart Mandate를 대신 생성해요.¹ 재무 입장에서 진짜 무서운 건 이 "사람이 없는(human-not-present)" 경로입니다.

보충. AP2는 A2A(에이전트끼리 작업을 주고받는 통신 규약)²와 MCP(모델에 도구·데이터 맥락을 연결하는 규약) 위에 얹히는 결제 확장이에요. 스택을 새로 깔라는 얘기가 아닙니다.

AP2 말고 다른 에이전트 결제 표준도 있나요?

있습니다. 그리고 아직 한 곳으로 수렴하지 않았어요. 구글 발표 파트너 명단에는 Mastercard·American Express·PayPal·Coinbase·Adyen·Worldpay·Etsy·Intuit 등이 올라 있는데¹, 같은 파트너들이 자기 규약도 따로 밀고 있습니다.

표준	주도	겨냥하는 지점
AP2	Google + 60개 이상 파트너	위임의 증명 — 서명된 Mandate로 의도·장바구니·결제를 입증3
Trusted Agent Protocol	Visa	에이전트의 신원 — 가맹점이 신뢰할 만한 에이전트인지 식별
Agent Pay	Mastercard	에이전트의 자격 — 토큰화된 결제 자격을 에이전트에 부여
Agentic Commerce Protocol	OpenAI + Stripe	구매 흐름 — 챗 인터페이스 안의 위임 결제·즉시 체크아웃
A2A x402 확장	Google·Coinbase·Ethereum Foundation·MetaMask	결제 레일 — 스테이블코인 등 암호화폐 경로4

이 글은 각주가 달린 AP2·x402만 1차 자료로 확인했습니다. Visa·Mastercard·OpenAI 진영 항목은 각 사 발표에서 알려진 메커니즘 수준으로만 적었으니, 실제 도입 검토 때는 각 사 공식 명세를 직접 확인하세요.

싸움의 축이 서로 다르다는 게 요점입니다. 그래서 셋이 동시에 살아남을 여지가 큽니다. 하나를 골라 베팅하는 대신, 셋 다 요구하는 공통 산출물을 보는 게 실속 있어요.

AI가 회사 카드로 잘못 결제하면 책임은 누가 지나요?

지금 규정으로는 대부분 카드를 등록한 회사가 집니다. 에이전트는 법인격이 없거든요. AP2가 바꾸려는 건 이 결론이 아니라 다툼의 근거예요.

구글은 AP2가 남기는 기록을 "부인할 수 없는 감사 추적(non-repudiable audit trail)"이라 부르며, 권한 위임·의도 진정성·책임 소재라는 세 질문에 답하는 토대라고 설명합니다.¹ 순서로 풀면 이렇습니다.

첫째, 사용자가 그 에이전트에 구매 권한을 줬는지는 Intent Mandate 서명으로 갈립니다. 서명이 없으면 위임 자체가 없었던 거예요. 둘째, 에이전트가 의도대로 움직였는지는 Cart Mandate와 Intent Mandate의 조건을 대조해 판별합니다. 20만 원 상한 위임에 35만 원짜리 카트가 서명됐다면 이탈 지점이 명확하죠. 셋째, 조건 안에서 벌어진 손해라면 책임은 위임한 쪽으로 돌아옵니다.

한 줄로 줄이면 이래요. 서명된 위임 조건이 곧 책임의 경계선입니다. 그래서 "우리 회사 에이전트는 얼마까지, 무엇을, 어떤 조건에 살 수 있는가"를 문장으로 못 박아두지 않으면 방어할 근거가 없습니다. 소명 자료가 로그 파일 한 무더기냐, 서명된 위임장 한 장이냐의 차이예요.

재무·조달은 뭐부터 손봐야 하나요?

승인 워크플로가 1순위입니다. 지금의 사후 결재는 "사람이 이미 샀다"는 전제 위에 서 있어요. 에이전트는 사람이 자리에 없을 때 사고, 조건만 맞으면 새벽 3시에도 삽니다. 그 시점에 사후 결재는 이미 늦습니다.

항목	현재 관행	에이전트 결제 시대 요구사항
승인 워크플로	결제 후 사후 결재	Intent 서명을 사전 승인으로 격상, 조건 이탈 시 자동 차단
지출 한도	사람(직급)에 한도 부여	작업·에이전트별 한도 + 건당 상한과 기간 총액 이중 설정
감사 로그	카드 명세서·영수증	Mandate 원본과 서명 보관, 위임 조건과 실제 결제의 대조 기록

한도 설계는 발상을 뒤집어야 합니다. 직급이 아니라 작업에 한도를 붙이세요. 소모품 재구매 에이전트에 500만 원 한도를 주는 건 위험하고, 5만 원 한도를 주면 하루 100번 결제로 우회됩니다. 그래서 건당 상한과 기간 총액을 함께 걸어야 해요. 하나만 걸면 반드시 뚫립니다.

지금 도입해야 하나요, 지켜봐도 되나요?

전면 도입은 이릅니다. 대신 지금 해야 할 준비는 있어요.

명세와 레퍼런스 구현은 공개돼 있지만³, 국내 카드사·PG·전자금융 규제가 에이전트 결제를 어떻게 다룰지는 별개 문제입니다. 전사 조달 시스템을 이 위에 올리는 건 시기상조예요.

그래도 관망만 하면 놓치는 게 있습니다. 표준 경쟁이 어떻게 끝나든 모든 진영이 공통으로 요구하는 건 똑같아요. 에이전트 신원, 서명된 위임 조건, 대조 가능한 로그. 이 셋은 지금 만들어도 버려질 자산이 아닙니다.

파일럿은 좁게 잡으세요. 사무용품·클라우드 크레딧처럼 금액이 작고 반복적이며 실패해도 회수 가능한 품목 한두 개면 충분합니다. 목적은 비용 절감이 아니라, 우리 조직의 승인 규칙을 기계가 읽을 수 있는 문장으로 옮겨보는 연습이에요. 이 번역이 안 되는 조직은 표준이 확정된 뒤에도 못 붙입니다.

AX Lab이 제안하는 에이전트 결제 3중 승인선

어떤 표준을 고르든 무너지지 않는 최소 골격을 셋으로 정리했습니다.

1. 의도선 — 사람이 서명하는 위임 조건. 금액·품목·기간·예외를 문장으로 명시하고, 이 문장이 곧 책임 경계선이 됩니다.
2. 한도선 — 카드·계정 레벨의 기술적 상한. 사람의 판단이 실패해도 시스템이 막는 마지막 벽이고, 건당과 총액을 반드시 함께 겁니다.
3. 증거선 — 서명 원본과 대조 기록의 보관. 사고가 났을 때 "왜 이 결제가 정당한가"를 15분 안에 설명할 수 있어야 해요.

셋 중 하나라도 비면 나머지 둘이 무력해집니다. 한도선만 있으면 왜 샀는지 설명이 안 되고, 의도선만 있으면 오작동을 못 막아요.

앞에서 말한 "규칙을 기계가 읽는 문장으로 옮기는 연습", 이게 결국 사람 역량 문제입니다. AI가 조직의 돈을 움직이기 시작하면 재무·조달 담당자에게 필요한 건 감이 아니라 직접 만들어본 경험이에요. AX Lab의 클로드 바이브 코딩 원데이 클래스는 비개발자가 5시간 안에 결과물 하나를 완성하는 과정입니다. 한 번 만들어보면 이 감각이 확실히 달라집니다.

승인 워크플로 문서를 지금 열어보세요. 거기 적힌 조건이 사람만 읽을 수 있는 문장이라면, 그게 첫 번째 과제입니다.

자주 묻는 질문

Q. AP2를 쓰려면 결제 시스템을 바꿔야 하나요? A. 아니요. AP2는 결제 수단이 아니라 위임 증명 계층입니다. 카드·계좌이체 위에 서명된 Mandate를 얹는 구조이고, A2A·MCP 위에 확장으로 붙습니다.

Q. AP2와 A2A, MCP는 무슨 관계인가요? A. 층이 다릅니다. MCP는 모델에 도구·데이터 맥락을 연결하고, A2A는 에이전트끼리 작업을 주고받게 하며, AP2는 그 위에서 결제 위임을 증명합니다. 셋은 경쟁 관계가 아니라 스택이에요.

Q. 사람이 자리에 없을 때 결제된 건도 유효한가요? A. 유효합니다. 미리 서명한 Intent Mandate의 조건이 충족되면 에이전트가 Cart Mandate를 대신 생성하는 흐름이 명세에 포함돼 있어요. 그래서 위임 조건을 얼마나 촘촘히 쓰느냐가 곧 리스크 관리입니다.

Q. 표준 하나를 골라야 하나요? A. 지금은 고를 단계가 아닙니다. 진영마다 겨냥점이 위임 증명, 에이전트 신원, 구매 흐름으로 달라 공존 가능성이 큽니다. 셋 다 요구하는 신원·위임·로그부터 준비하세요.

출처

Footnotes

1. Google Cloud Blog, 『Powering AI commerce with the new Agent Payments Protocol (AP2)』, 2025년 9월 17일. 60개 이상 파트너, Intent·Cart Mandate 정의, human-not-present 위임 흐름, non-repudiable audit trail 서술의 근거. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol ↩ ↩² ↩³ ↩⁴ ↩⁵

2. A2A 프로토콜 공식 사이트 — 에이전트 간 통신 규약 명세. https://a2a-protocol.org ↩

3. AP2 공식 저장소 — 기술 명세, 문서, 레퍼런스 구현. https://goo.gle/ap2 ↩ ↩²

4. A2A x402 확장 저장소 — 스테이블코인·암호화폐 결제 레일. https://github.com/google-a2a/a2a-x402 ↩