Google AP2·FIDO 기부가 연 에이전트 결제 표준 경쟁

오늘 한눈에 보는 핵심

• Google이 Agent Payments Protocol(AP2)을 FIDO Alliance에 기부하면서, AI 에이전트가 실제 결제까지 수행하는 시장이 단일 기업 실험에서 공개 표준 경쟁으로 이동했다.
• AP2 v0.2는 사용자가 그 순간 화면 앞에 없더라도 사전 지시를 바탕으로 결제를 실행하는 Human Not Present 흐름을 전면에 놓는다.
• Google Cloud의 AP2 설명은 Agent2Agent와 Model Context Protocol 위에서 결제 권한, 인증, 검증, 거래 전달을 다루는 결제 불가지론적 프레임워크를 지향한다고 밝힌다.
• Mastercard와 함께 언급된 Verifiable Intent는 사용자가 승인한 에이전트 행동을 변조하기 어려운 기록으로 남기는 신뢰 계층을 결제 생태계의 핵심 과제로 끌어올린다.
• VIBE 코딩 팀에는 “에이전트가 결제한다”는 데모보다 권한 범위, 감사 로그, 환불·분쟁 기준, 사용자 확인 UX를 먼저 설계해야 한다는 실무 신호다.

기준 날짜와 짧은 출처

기준 날짜는 2026년 4월 29일 UTC다. 아래 공식·1차 공개 자료에서 확인되는 사실을 바탕으로 AI 에이전트 결제 표준의 산업적 의미와 실무 리스크를 새로 해설했다.

• Google 발표
• Google Cloud AP2
• AP2 GitHub
• FIDO 발표
• Mastercard VI

확정 사실

Google은 Agent Payments Protocol, 즉 AP2를 FIDO Alliance에 기부한다고 발표했다. 발표의 핵심은 AI 쇼핑과 에이전트 기반 거래가 특정 플랫폼 안에 갇힌 기능으로 커지는 것이 아니라, 여러 결제사·상거래 사업자·에이전트 플랫폼이 함께 해석할 수 있는 공개 표준의 형태로 확장돼야 한다는 주장이다. Google은 FIDO Alliance를 공개 표준을 만드는 업계 단체로 설명하며, AP2의 소유권을 넘겨 더 넓은 산업 참여를 유도하겠다는 방향을 제시했다.

Google은 같은 날 AP2 v0.2도 GitHub에 공개한다고 밝혔다. 여기서 눈에 띄는 변화는 Human Not Present payments다. 이는 사용자가 결제 순간에 직접 버튼을 누르는 기존 전자상거래 가정과 다르다. 사용자가 사전에 조건과 범위를 정해 두면, AI 에이전트가 해당 조건을 만족하는 순간 결제를 실행할 수 있다는 흐름이다. 예를 들어 한정 수량 티켓이 열릴 때 사전 지시에 맞춰 구매를 시도하는 식의 시나리오가 가능해진다.

Google Cloud의 AP2 설명은 프로토콜이 Agent2Agent(A2A)와 Model Context Protocol(MCP)의 확장으로 쓰일 수 있다고 설명한다. 여기서 중요한 문장은 “AI agents are capable of transacting on behalf of users”라는 문제의식이다. 오늘의 결제 시스템은 대체로 사람이 신뢰된 화면에서 직접 구매 버튼을 누른다는 전제 위에 놓여 있다. 에이전트가 사용자를 대신해 검색, 비교, 주문, 결제를 수행하면 인증, 권한, 사용자 의도, 사후 책임을 새로 표현해야 한다.

AP2가 다루는 핵심 단위

AP2의 공개 저장소와 설명은 에이전트 주도 결제가 단순 결제 API 호출이 아니라 권한을 증명하고 전달하는 절차라는 점을 강조한다. 사용자가 무엇을 허용했는지, 에이전트가 어떤 조건에서 어떤 판매자에게 어떤 금액 범위로 행동할 수 있는지, 결제 사업자와 상인이 그 의도를 어떻게 검증할 수 있는지가 핵심이다. 그래서 AP2는 카드사나 특정 지갑에 종속된 방식보다, 결제 불가지론적 프레임워크라는 표현에 가깝다.

FIDO Alliance로 넘어가는 이유

FIDO Alliance는 패스키와 강한 인증 표준으로 알려져 있다. Google이 AP2를 FIDO Alliance에 넘긴다는 것은 에이전트 결제를 단순한 쇼핑 기능이 아니라 인증·신원·권한 위임 문제로 본다는 뜻이다. 에이전트가 결제 권한을 가진 순간, “누가 승인했는가”, “무엇까지 허용했는가”, “승인 이후 지시가 바뀌었는가”, “상인은 어떤 증거를 믿을 수 있는가”가 기술 표준의 중심으로 올라온다.

Verifiable Intent의 위치

Google 발표는 Mastercard와 함께 개발한 Verifiable Intent도 AP2-compatible standard로 소개한다. 핵심은 사용자가 허가한 에이전트 행동의 변조 방지 기록이다. 이 개념이 중요한 이유는 에이전트 결제에서 신뢰가 한 번의 인증 화면으로 끝나지 않기 때문이다. 사용자의 사전 의도, 에이전트의 실제 행동, 상인과 결제 네트워크가 확인한 조건이 사후에 대조 가능해야 분쟁과 오남용을 줄일 수 있다.

업계 의미

AI 에이전트 시장은 이제 “대화를 잘한다”에서 “업무를 끝까지 수행한다”로 옮겨가고 있다. 업무를 끝까지 수행한다는 말은 예약, 주문, 결제, 취소, 환불, 정산 같은 경제적 행위까지 포함한다. AP2 기부는 이 전환점에서 나온 표준화 신호다. 모델 성능 경쟁만으로는 에이전트 경제가 열리지 않는다. 결제 네트워크, 상거래 플랫폼, 신원·인증 표준, 개발자 도구가 같은 언어로 사용자 의도와 권한을 읽어야 한다.

첫 번째 의미는 플랫폼 경쟁의 장이 모델 API에서 거래 인프라로 확장된다는 점이다. 개발자는 Gemini, OpenAI, Claude, 로컬 모델 중 무엇을 쓰느냐만 고르는 것이 아니라, 에이전트가 외부 서비스와 계약·결제·정산을 어떻게 수행할지 설계해야 한다. AP2가 공개 표준으로 확장되면 특정 모델 벤더보다 결제 승인 흐름, 지갑, 인증, 상거래 API를 잘 연결하는 생태계가 더 큰 영향력을 가질 수 있다.

두 번째 의미는 “에이전트 권한”이 제품의 경쟁력이 된다는 점이다. 지금까지 많은 AI 제품은 사용자가 직접 검토한 뒤 마지막 버튼을 누르는 보조 도구였다. Human Not Present 결제가 현실화되면 에이전트는 사용자가 자리를 비운 동안에도 조건부 행동을 수행한다. 이때 제품의 차이는 답변 품질보다 안전한 권한 범위, 사전 승인 UX, 실패 시 알림, 취소 가능성, 감사 로그, 분쟁 증거 제공 능력에서 드러난다.

세 번째 의미는 결제사와 인증 표준 단체가 AI 에이전트 시대의 중요한 플랫폼 사업자가 된다는 점이다. 에이전트가 아무리 똑똑해도 상인과 결제 네트워크가 그 의도를 믿지 못하면 거래는 막힌다. 반대로 검증 가능한 의도와 강한 인증이 표준화되면 작은 개발팀도 독자 결제 인프라를 새로 만들지 않고 안전한 에이전트 상거래 기능을 붙일 수 있다. 이는 VIBE 코딩으로 작은 서비스를 빠르게 만드는 팀에게도 진입 장벽을 낮추는 변화다.

개발 생태계의 새 추상화

A2A와 MCP가 에이전트 간 통신과 도구 연결의 언어를 만들고 있다면, AP2는 돈이 움직이는 순간의 언어를 맡는다. 세 프로토콜이 함께 언급되는 이유는 분명하다. 에이전트가 다른 에이전트에게 요청하고, 도구를 호출하고, 사용자가 허가한 조건 안에서 결제까지 진행하려면 각 단계의 증거가 이어져야 한다. 앞으로 에이전트 개발자는 프롬프트만이 아니라 권한 토큰, 정책 엔진, 사용자 동의 기록, 거래 이벤트를 함께 설계해야 한다.

실무자가 볼 체크포인트

개발자는 AP2 소식을 보고 바로 결제 자동화를 붙이기보다, 현재 제품에서 에이전트가 “권한을 위임받는 순간”이 어디인지부터 찾아야 한다. 가격 비교, 장바구니 생성, 예약 대기, 재고 알림, 구독 갱신, 환불 요청처럼 돈이나 계약에 가까운 행동은 모두 후보가 된다. 이 후보마다 사용자가 허용한 조건, 금액 상한, 시간 제한, 판매자 범위, 재확인 기준을 별도 데이터로 남겨야 한다.

운영자는 결제 승인과 실행 사이의 거리를 관측해야 한다. 사용자가 오전에 “10만원 이하이면 구매”라고 허용했는데 오후에 상품 조건이 바뀌었다면 에이전트는 그대로 결제해도 되는가. 환율, 배송비, 세금, 재고 상태, 판매자 평판, 쿠폰 조건이 바뀌면 재확인이 필요한가. 이런 질문은 모델 추론 문제가 아니라 정책과 감사 로그 문제다. AP2와 Verifiable Intent가 주목받는 이유도 이 지점을 표준 언어로 만들려는 데 있다.

창업자는 “AI가 알아서 쇼핑해준다”는 문구보다 책임 경계를 먼저 제품화해야 한다. 사용자가 이해하기 쉬운 사전 승인 화면, 결제 직전 알림 옵션, 고위험 거래 차단, 즉시 취소 가능한 창, 분쟁 접수 흐름, 실패 시 대체 행동을 보여줘야 한다. 신뢰가 부족한 에이전트 결제는 편리함보다 두려움을 먼저 만든다. 반대로 안전장치가 명확하면 작은 팀도 신뢰를 자산으로 삼아 대형 플랫폼과 경쟁할 수 있다.

VIBE 코딩 팀의 구현 순서

VIBE 코딩으로 AP2형 기능을 실험한다면 첫 단계는 결제 API를 붙이는 일이 아니다. 먼저 “에이전트가 절대 해서는 안 되는 일”을 적고, 그다음 “사용자가 명시적으로 허용한 일”을 구조화해야 한다. 예를 들어 상품군, 최대 금액, 판매자 등급, 배송 지역, 시간 제한, 재시도 횟수, 알림 채널, 결제 승인 방식이 최소 단위가 된다. 이 조건을 테스트 데이터로 만들고, 에이전트가 조건 밖 행동을 요청할 때 반드시 거절하는 회귀 테스트를 둬야 한다.

두 번째 단계는 감사 로그 설계다. 로그에는 사용자의 pre-authorized 지시, 에이전트가 해석한 조건, 외부 서비스에서 받은 가격·재고·상태, 최종 결제 승인 판단, 사용자에게 보낸 알림, 실패·취소 이벤트가 연결돼야 한다. 나중에 분쟁이 생겼을 때 “모델이 그렇게 말했다”는 설명은 아무 도움이 되지 않는다. 누가 언제 무엇을 허용했고 시스템이 어떤 증거를 보고 행동했는지를 사람이 읽을 수 있어야 한다.

세 번째 단계는 사용자 경험이다. 에이전트 결제는 기술적으로 성공해도 사용자가 불안하면 실패한 제품이다. 승인 화면에는 자연어 요약과 구조화된 조건을 같이 보여주고, 고위험 조건은 다시 확인해야 한다. 자동 결제 성공 뒤에는 단순 영수증보다 “사용자 지시와 실제 거래가 어떻게 일치했는지”를 보여주는 설명이 필요하다. 이것이 Verifiable Intent가 실무 UX로 번역되는 지점이다.

리스크와 확인할 점

가장 큰 리스크는 과잉 자동화다. Human Not Present 결제는 편리하지만, 사용자가 맥락을 잊은 상태에서 돈이 움직인다는 뜻이기도 하다. 따라서 금액이 작거나 반복적이거나 취소가 쉬운 거래와, 고가·희소·환불 어려움·계약 의무가 있는 거래를 같은 정책으로 다루면 안 된다. 에이전트 결제 제품은 거래 위험도에 따라 자동 실행, 재확인, 보류, 금지 단계를 나눠야 한다.

두 번째 리스크는 책임 전가다. 에이전트가 잘못 구매했을 때 책임이 사용자, 에이전트 운영사, 판매자, 결제사 중 누구에게 있는지 불명확하면 시장은 커지기 어렵다. AP2나 FIDO 표준화가 모든 법적 문제를 즉시 해결하는 것은 아니다. 표준은 의도와 권한을 더 명확히 표현할 수 있게 해주지만, 환불 정책, 소비자 보호, 지역별 규제, 미성년자 보호, 금융 사기 대응은 별도 운영 체계가 필요하다.

세 번째 리스크는 보안과 프롬프트 조작이다. 에이전트가 웹페이지, 이메일, 메시지, 판매자 설명을 읽고 결제 판단을 내린다면 악의적 문구가 지시처럼 섞일 수 있다. 결제 권한을 가진 에이전트에는 일반 검색 에이전트보다 훨씬 엄격한 입력 격리, 도구 권한 제한, 판매자 검증, 이상 거래 탐지, 정책 기반 차단이 필요하다. 특히 결제 승인 조건은 모델의 자유 텍스트 해석에만 맡기지 말고 구조화된 규칙으로 검증해야 한다.

표준 발표와 실제 도입 사이

AP2가 공개되고 FIDO Alliance가 표준화를 추진한다고 해서 모든 결제 환경에서 즉시 쓸 수 있는 것은 아니다. 상인, 지갑, 결제 네트워크, 에이전트 플랫폼, 규제 기관이 함께 채택해야 네트워크 효과가 생긴다. 초기에는 파일럿, 특정 파트너 연동, 제한된 거래 유형에서 시작될 가능성이 높다. 실무팀은 “언제 전면 도입할까”보다 “우리 서비스의 권한 위임 모델이 표준과 맞물릴 수 있는가”를 먼저 검토해야 한다.

제품 책임자가 바꿔야 할 지표

제품 책임자는 에이전트 결제를 활성 사용자 수나 자동화 성공률만으로 평가하면 안 된다. 사전 승인 조건을 사용자가 끝까지 이해했는지, 자동 결제 뒤 이의 제기 비율이 얼마인지, 알림을 받은 사용자가 취소·수정할 수 있었는지, 에이전트가 조건 밖 거래를 얼마나 자주 차단했는지를 봐야 한다. 특히 결제 실패보다 위험한 것은 잘못된 성공이다. 사용자는 결제가 성공했더라도 자신이 허락하지 않은 느낌을 받으면 제품 전체를 신뢰하지 않는다.

기술 조직도 같은 이유로 모델 평가셋을 바꿔야 한다. 일반적인 대화 품질 평가 대신, 가격 조건이 모호할 때 보류하는지, 판매자 설명 안의 조작 문구를 무시하는지, 세금·배송비 포함 금액이 상한을 넘을 때 거절하는지, 품절·대체 상품 제안 때 재승인을 요구하는지 같은 거래 시나리오가 필요하다. AP2형 흐름은 모델이 더 과감하게 행동하도록 만드는 것이 아니라, 안전하게 멈출 수 있게 만드는 설계까지 포함한다.

한국 서비스가 볼 현실적 적용 범위

국내 서비스 관점에서는 초기 적용 범위를 반복 결제와 예약 보조처럼 위험이 낮고 취소가 쉬운 영역으로 좁히는 편이 현실적이다. 예를 들어 소모품 재주문, 일정 조건의 좌석 알림, 사내 SaaS 라이선스 갱신 검토, 광고 예산 소진 알림처럼 사용자의 조건을 명확히 구조화할 수 있는 업무가 먼저다. 반대로 금융상품 가입, 고가 전자제품 구매, 환불이 어려운 티켓, 개인정보가 깊게 연결된 계약은 추가 인증과 사람 검토 없이 자동화하기 어렵다.

이 구분은 규제 회피가 아니라 사용자 신뢰 설계다. 에이전트가 결제 권한을 받는 순간 서비스는 단순 추천 엔진이 아니라 대리 행위 시스템이 된다. 대리 행위 시스템에는 권한 위임 계약, 기록 보존, 설명 가능성, 사용자 철회권이 붙어야 한다. AP2와 FIDO 논의가 커질수록 “AI가 대신 해줍니다”라는 간단한 문구보다 “어떤 조건에서만 대신하고, 언제 멈추며, 어떤 기록을 남기는가”가 더 중요한 마케팅 언어가 될 가능성이 높다.

전망

이번 AP2 기부는 AI 에이전트 상거래가 실험실 기능에서 산업 인프라 논의로 넘어갔다는 신호다. 지금까지 에이전트 뉴스는 모델 성능, 코딩 자동화, 브라우저 조작, 업무 자동화에 집중됐다. 그러나 실제 경제 활동으로 들어가면 결제 승인, 신원 확인, 사전 의도 증명, 감사 로그가 핵심 경쟁력이 된다. FIDO Alliance가 이 영역을 맡게 되면 패스키 이후의 인증 논의가 “사람 로그인”에서 “사람이 위임한 에이전트 행동”으로 확장될 수 있다.

다음 관전 포인트는 세 가지다. 첫째, AP2가 어느 결제사와 상거래 플랫폼에서 실제 파일럿으로 이어지는지 봐야 한다. 둘째, Verifiable Intent가 사용자에게 이해 가능한 UX로 구현되는지 확인해야 한다. 셋째, A2A, MCP, AP2가 각각 독립 표준으로 남을지, 에이전트 개발 프레임워크 안에서 하나의 운영 패턴으로 묶일지 지켜봐야 한다.

VIBE Coding 365 독자에게 이 뉴스의 행동 기준은 분명하다. 지금 당장 자동 결제 에이전트를 무리하게 만들기보다, 자신의 제품에서 AI가 권한을 위임받는 지점을 목록화하고, 결제·예약·구독·구매 같은 고위험 행동에는 사용자 의도 기록과 정책 검증을 먼저 붙여야 한다. 에이전트 시대의 좋은 제품은 빠른 실행만이 아니라, 사용자가 나중에 “왜 이 행동이 일어났는지”를 납득할 수 있게 만드는 제품이다.