Liability Shift: AI 쇼핑 에이전트가 잘못 산 결제를 누가 떠안을지 갈리는 카드사·은행
AI 쇼핑 에이전트 결제는 빠르게 늘고 있지만 에이전트가 잘못 샀을 때 누가 책임지는지 정한 업계 공통 규칙은 아직 없습니다. 기사에 나온 소비자 보호 정책은 Amex의 등록 에이전트·purchase intent 문서와 Stripe Link 구매 보호 두 가지이고, 은행들은 업계 공통 규칙과 기술 기업의 책임 분담을 요구합니다.
AI 에이전트가 구매자 뜻과 다르게 결제했을 때 손실을 누가 떠안는지는 아직 카드사, 지갑, 은행이 저마다 정한 조건에 달려 있습니다. 업계 공통 규칙이 나오기 전까지 에이전트 주문을 받거나 내보내는 기업은 거래마다 어떤 에이전트가 누구의 지시로 무엇을 샀는지 남겨 두어야 분쟁 때 설명할 근거가 생깁니다.
요약
Payments Dive의 Justin Bachman 기자는 2026년 10월 28일 기사에서 agentic commerce(AI 에이전트가 구매자 대신 상품을 고르고 결제하는 거래)가 책임 규칙 없이 앞서 나갔다는 은행·결제 업계의 걱정을 모았습니다. 재료는 10월 19~20일 Money20/20 행사 발언과 업계 인사 인터뷰입니다. 배경에는 9월의 급증이 있습니다. Meta는 9월 미국과 캐나다에 Muse 에이전트를 내놨고 초기 사용자 1,000만 명이 Muse에 가장 많이 맡긴 일이 쇼핑이었습니다. Amazon은 9월 21일 자사 쇼핑몰에서 Muse를 막았습니다(Bloomberg 보도). Stripe의 John Collison 사장은 10월 팟캐스트에서 에이전트 거래가 9월부터 수직으로 치솟기 시작했다고 말했습니다.
기사에 소비자 보호 정책으로 나온 것은 두 가지뿐입니다. Amex는 카드 소지자의 에이전트를 회사에 등록하게 하고 구매가 잘못되면 구매자가 purchase intent(구매 의도) 문서로 거래가 의도와 달랐음을 보여 주게 합니다. Stripe는 Link 지갑으로 산 미국 내 구매를 보호하되 약관에 에이전트 활동을 지켜보라는 조건을 붙였습니다. Visa는 상세한 audit trail(거래 기록)과 생태계가 맥락 데이터를 나누는 trust layer를 강조했고 Mastercard Agent Pay는 승인 절차를 거쳐 에이전트용 결제 정보를 토큰으로 바꿉니다. 은행 쪽 반응은 더 조심스럽습니다. Wells Fargo는 10월 2일 고객 이메일에서 계정 접속 정보를 공유하면 AI 오류 책임을 고객이 질 수 있다고 알렸습니다. PNC의 Bill Demchak CEO는 기술 기업이 위험을 떠안으려면 “massive liability shift”가 있어야 한다고 했습니다. Stripe의 John Piazza는 아직 판례가 없고 표준도 만드는 중이라고 했습니다. 기사에는 규제 당국의 조치가 나오지 않습니다. 아래에서는 책임을 가르는 장치 네 가지를 풀고 에이전트 주문을 다루는 기업이 무엇을 남기고 누가 언제 준비할지 덧붙였습니다. Agent Pay와 Verifiable Intent의 작동 방식은 Mastercard 3분기 콜 노트에서 다뤘고, 이 노트는 책임 배분에 집중합니다.
핵심 메커니즘
Agent Registration: 거래한 에이전트가 누구인지 먼저 확정하기
책임을 따지려면 먼저 그 거래를 누가 했는지가 분명해야 합니다. Amex는 카드 소지자가 쓰는 에이전트를 회사에 등록하게 합니다. Visa의 Trusted Agent 프로토콜은 알려진 에이전트 목록(directory)을 두고 그 목록으로 에이전트를 가립니다. Mastercard Agent Pay는 승인 절차를 거친 에이전트에게 결제 정보를 토큰으로 내줍니다. 세 방식 모두 결제 전에 카드사가 에이전트를 알아보게 하는 구조입니다. 반대편 사례가 Wells Fargo의 경고입니다. 구매자가 에이전트에게 계정 접속 정보를 넘기면 AI 오류의 책임을 고객이 질 수 있다고 알렸습니다. 정리하면 등록은 에이전트에게 결제를 맡기는 단계에서 쓰는 장치입니다. 에이전트가 상품을 찾아보기만 하는 단계에는 필요하지 않습니다. 가상 예시로, 회사 출장 담당이 항공권 예약 에이전트를 카드사에 등록해 두면 잘못된 예약이 나왔을 때 어느 에이전트가 낸 거래인지 다툴 일이 줄어듭니다.
Purchase Intent: 구매자가 의도와 달랐음을 보여 주는 문서
Amex 방식에서 구매가 잘못되면 구매자가 purchase intent 문서를 내서 거래가 자기 의도에서 벗어났음을 보여야 합니다. 구매자가 먼저 근거를 내야 하는 구조입니다. 그래서 구매자가 무엇을 시켰는지가 거래 시점에 남아 있어야 이 문서가 힘을 가집니다. Visa는 상세한 audit trail이 매우 중요하다고 했고 거래 맥락과 데이터를 생태계 전체가 함께 보는 trust layer를 원한다고 했습니다. 의도를 남기는 일은 구매자 혼자 할 수 없고 에이전트, 지갑, 카드사가 같은 기록을 볼 수 있어야 한다는 말입니다. 이 장치는 에이전트가 정해진 조건 안에서 혼자 결제하는 거래에 씁니다. 구매자가 결제 직전에 화면에서 직접 확인하는 거래라면 기존 결제와 크게 다르지 않습니다. 가상 예시로, “토너 2개, 개당 5만 원 이하”라고 시켰는데 에이전트가 고급형 3개를 샀다면 지시 기록과 주문 내역의 차이가 곧 이의 제기의 근거가 됩니다.
Platform Terms: 지갑 약관과 은행 경고가 정하는 고객 몫
공통 규칙이 없는 동안 책임의 경계는 각 회사 약관이 긋습니다. Stripe는 Link 지갑으로 결제한 미국 내 구매를 보호합니다. Link는 Meta Muse 에이전트의 결제를 돕는 지갑이기도 합니다. 다만 Link 이용 약관에는 사용자가 에이전트 활동을 지켜봐야 한다는 단서가 붙습니다. Wells Fargo의 이메일은 반대 방향에서 같은 원리를 보여 줍니다. 접속 정보를 넘기는 순간 책임이 고객 쪽으로 기울 수 있다는 경고입니다. 두 사례 모두 보호와 고객 의무를 짝으로 묶었습니다. 따라 할 때는 우리 회사가 에이전트 주문을 받는 쪽인지 내보내는 쪽인지에 따라 약관에서 고객에게 요구할 조건과 우리가 질 보호 범위를 함께 정합니다.
Interchange·Chargeback: 책임을 옮기는 경제적 지렛대
기존 카드 결제에서는 카드 네트워크가 interchange(카드 결제 수수료) 수준과 chargeback(구매자가 이의를 제기해 결제를 되돌리는 절차) 규칙으로 참여자 행동을 이끕니다. 기사에서 이 구조는 네 당사자 모델로 불립니다. Cross River Bank의 Andrew Lambert는 에이전트 플랫폼이 이 네 당사자 구조 밖에 있어서 지금의 수수료·차지백 규칙이 잘 맞지 않는다고 했습니다. 그래서 참여자가 지켜야 할 기본 규칙을 카드 네트워크가 더 분명히 알려 줘야 한다고 봤습니다. 그가 든 지렛대는 데이터입니다. 거래 데이터를 더 많이 나누고 보안이 더 단단하다는 것을 보여 주는 가맹점은 수수료를 낮추거나 책임을 다른 쪽으로 옮길 수 있다고 했습니다. 은행 쪽에서 Demchak은 기술 기업이 위험을 떠안으려면 책임 구조가 크게 옮겨 가야 한다고 했습니다. 지금 단계에서 이 지렛대는 협상 방향이고 정해진 규칙이 아닙니다.
통념과 다른 주장
흔히 이렇게 봅니다카드로 결제했다면 에이전트가 산 물건도 기존 카드 분쟁 절차로 소비자가 보호받는다.
기사 속 업계 인사들은 이렇게 봅니다에이전트 플랫폼은 기존 수수료·차지백 규칙이 닿지 않는 자리에 있고, 지금 있는 보호 정책은 두 회사 것뿐이다. 업계 전체가 같이 쓰는 규칙이 필요하다.
근거Early Warning Services의 Cameron Fowler CEO는 두 회사의 제한된 규칙으로는 모자라고 몇몇 회사가 아닌 업계 전체 규칙이 있어야 한다고 했습니다. 연방 법과 기업 정책이 에이전트 기술을 따라가지 못했다고 봤고 거래 규모가 수조 단위, 소비자가 수억 명에 이를 수 있다고 했습니다. Piazza는 판례가 아직 없다고 했습니다.
저자가 든 사례
| 사례 | 상황 | 한 일 | 책임이 놓이는 곳 | 연결 |
|---|---|---|---|---|
| Amex | 에이전트가 카드로 결제 | 에이전트 등록 요구, purchase intent 문서 제출 절차 | 구매자가 의도와 다름을 먼저 입증 | Agent Registration, Purchase Intent |
| Stripe Link·Meta Muse | Muse가 Link로 결제, Muse 초기 사용자 1,000만 명 중 쇼핑이 1순위 | 미국 내 Link 구매 보호 | 약관상 사용자가 에이전트 활동을 감시 | Platform Terms |
| Visa | 에이전트 거래 확산 | Trusted Agent 프로토콜(알려진 에이전트 목록), audit trail 강조 | 생태계가 맥락 데이터를 나누는 trust layer 구상 | Agent Registration, Purchase Intent |
| Wells Fargo | 고객이 AI에 계정을 맡기는 경우 | 10월 2일 고객 이메일 경고 | 접속 정보를 공유한 고객이 책임질 수 있음 | Platform Terms |
| PNC·EWS | Money20/20 발언(10월 19일) | 업계 공통 규칙과 책임 이전 요구 | 기술 기업이 위험을 나눠 질 것을 요구 | Interchange·Chargeback |
| Amazon | Muse가 쇼핑몰에 접근 | 9월 21일 Muse 차단(Bloomberg 보도) | 원문에서 밝히지 않음 | 시장 배경 |
기술 디테일: 책임을 설명할 근거를 남기는 법
아래 필드, 규칙, 설정값은 실제로 돌릴 때 필요한 것을 가상 예시로 적은 것입니다. Amex, Stripe, Visa가 밝힌 사양이 아니고 법률 판단도 아닙니다. 실제 제출 양식과 연동 규격은 카드사·지갑 문서와 법무 검토를 따릅니다.
Agent Registration을 반영하려면 주문마다 결제 정보가 어떤 경로로 에이전트에게 갔는지를 먼저 분류합니다. credential_type 칸에 network_token(카드사가 발급한 에이전트용 토큰), registered_agent(카드사·지갑에 등록된 에이전트), shared_login(구매자가 아이디·비밀번호를 넘긴 경우), unknown 네 값 중 하나를 넣습니다. Wells Fargo 경고처럼 shared_login은 책임이 고객에게 넘어갈 수 있는 경로이니 이 값이 찍힌 주문은 따로 세어 둡니다. agent_registry에는 등록처(예: amex, visa_trusted_agent, none)를 적습니다. 등록처가 none인 주문은 바로 거절하지 말고 사람 검토 대기열로 보내 첫 4주 비율을 봅니다.
Purchase Intent 근거를 남기려면 구매자가 에이전트에게 일을 맡기는 순간의 지시를 mandate 레코드로 저장합니다. 품목 조건, 최대 금액, 허용 가맹점, 수량, 만료 시각, 동의 채널을 담습니다. 주문이 들어오면 규칙 엔진이 mandate와 주문을 칸마다 대조합니다. 금액, 수량, 가맹점, 만료 시각은 숫자·목록 비교로 끝나니 LLM을 쓰지 않습니다. 품목 일치(예: “토너”와 “고급형 토너 세트”)처럼 말로 판단할 부분만 LLM에 맡깁니다. 이때는 구조화 출력(match, reason, confidence)으로 받고 temperature 0으로 3회 돌려 2회 이상 같은 답을 채택하며, 세 번이 갈리면 사람에게 넘깁니다.
{
"order_id": "ORD-2026-118204",
"agent_id": "agt-travel-07",
"agent_registry": "visa_trusted_agent",
"credential_type": "network_token",
"mandate": {
"mandate_id": "MDT-55021",
"item_rule": "레이저 토너, 표준형",
"max_unit_price": 50000,
"max_qty": 2,
"allowed_merchants": ["MCH-0192", "MCH-0440"],
"expires_at": "2026-11-08T23:59:00+09:00",
"consent_channel": "app_confirm"
},
"check": {
"price_ok": true,
"qty_ok": false,
"merchant_ok": true,
"item_match": { "match": false, "reason": "고급형 세트", "votes": "3/3" }
},
"decision": "hold_for_buyer",
"evidence_hash": "sha256:9f2c...e41a",
"recorded_at": "2026-11-03T10:14:22+09:00"
}분쟁에 쓸 근거 묶음은 mandate, 대조 결과, 에이전트 활동 기록, 구매자에게 보낸 알림을 한 묶음으로 저장하고 해시와 기록 시각을 붙여 나중에 고쳐지지 않았음을 보일 수 있게 합니다. 보관 기간은 카드사 이의 제기 기한과 회사 기록 보존 규정 중 긴 쪽에 맞춥니다.
Platform Terms의 감시 조건을 지키려면 에이전트가 결제할 때마다 구매자에게 즉시 알림을 보내고 알림 발송과 열람 시각을 근거 묶음에 넣습니다. Stripe Link처럼 약관이 사용자의 감시를 요구하는 경우, 우리 서비스가 감시할 수단을 줬다는 기록이 남아야 보호 범위를 설명할 수 있습니다.
| 막히는 경우 | 증상 | 대응 |
|---|---|---|
| 지시가 대화로만 남음 | mandate 칸이 비어 대조 불가 | 위임 시점에 금액·수량·기한을 화면에서 한 번 확인받아 구조화 저장 |
| 결제 경로를 모름 | credential_type이 unknown으로 쌓임 | 결제 대행사에 에이전트 거래 표시와 토큰 여부 전달을 요청 |
| 품목 판단이 갈림 | LLM 3회 답이 엇갈림 | 사람 검토로 넘기고 사례를 모아 품목 규칙을 보강 |
| 근거 묶음이 흩어짐 | 분쟁 때 주문·알림·로그를 따로 찾음 | 주문 ID 하나로 묶어 저장, 해시로 변경 여부 확인 |
| 약관과 실제 기능이 다름 | 약관은 감시를 요구하는데 알림 기능이 없음 | 약관 개정 전에 알림·중지 버튼부터 출시 |
현업 실행 디테일: 누가, 언제, 무엇을
아래 역할, 일정, 기준은 가상 예시입니다. 책임 조항과 고객 안내 문구는 법무 검토를 거쳐 확정합니다.
| 역할 | 맡는 일 |
|---|---|
| 법무 | 책임 지도 작성 주도, 결제 대행사·에이전트 플랫폼 계약과 고객 약관의 책임 조항 검토 |
| 결제·PM | 에이전트 주문 유입 경로 파악, 카드사·지갑 등록 절차와 토큰 전달 방식 확인 |
| 보안(CISO) | 접속 정보 공유 경로 차단 방안, credential_type 분류 기준 승인 |
| 고객센터·분쟁 담당 | 에이전트 주문 이의 제기 절차, 근거 묶음 사용법 정리 |
| 재무 | 에이전트 주문 손실 추정, 분쟁 손실을 누가 부담하는지 계정 처리 기준 |
준비물. 결제 대행사·지갑 계약서, 현재 고객 약관과 환불 규정, 최근 3개월 분쟁 기록, 에이전트 주문으로 보이는 거래 표본, 카드사·지갑의 에이전트 등록 안내 문서가 필요합니다.
책임 지도부터 만듭니다. 에이전트 주문이 들어오는 채널마다 다섯 칸을 채웁니다. 어느 에이전트가, 어떤 결제 경로(토큰·등록·로그인 공유)로, 어느 약관 아래에서 결제했고, 잘못되면 지금 계약상 누가 먼저 손실을 지며, 그때 우리가 낼 근거는 무엇인지입니다. 빈칸이 곧 협상하거나 고칠 목록이 됩니다.
| 기간 | 할 일 | 산출물 | 담당 |
|---|---|---|---|
| 1~2주 | 채널·결제 경로별 책임 지도 작성, 계약·약관의 책임 조항 목록화 | 책임 지도, 조항 목록 | 법무, 결제·PM |
| 3~4주 | credential_type·mandate 필드와 대조 규칙 추가, 계약 수정안 협의 시작, 고객 안내문 초안 | 필드 정의서, 수정안, 안내문 초안 | 결제·PM, 보안, 법무 |
| 5~6주 | 고객 안내 발송과 FAQ 게시, 가상 분쟁 5건 모의 처리 | 모의 처리 기록, 개선 목록 | 고객센터, 재무 |
현업에 물을 것.
- 지금 우리 주문 중 에이전트가 낸 주문을 가려낼 수 있나요? 결제 대행사가 그 표시를 넘겨주나요?
- 고객이 에이전트에게 계정 아이디·비밀번호를 넘기는 경로가 있나요? 있다면 약관은 그 경우를 어떻게 다루나요?
- 에이전트가 잘못 산 주문에 이의가 들어오면 지금 계약상 누가 먼저 손실을 지나요? 우리, 결제 대행사, 에이전트 플랫폼 중 어디인가요?
- 구매자가 에이전트에게 무엇을 시켰는지 거래 시점에 남는 기록이 있나요?
- 우리 약관이 고객에게 에이전트 감시를 요구한다면 감시할 수단(알림, 중지 버튼)을 실제로 주고 있나요?
진행 판정 기준(예시). 4주 운영 뒤 에이전트 주문의 90% 이상에 credential_type과 mandate가 붙고 모의 분쟁 5건 모두 근거 묶음만으로 경위를 설명할 수 있으며, 책임 지도의 빈칸이 계약 협의 목록으로 모두 넘어갔다면 대상 채널을 넓힙니다. 하나라도 못 채우면 그 항목만 2주 더 봅니다.
AX 적용 제언. 에이전트 결제를 받으려는 유통·이커머스 기업, 에이전트 결제를 붙이려는 카드사·결제 대행사 모두 기능 개발보다 책임 지도를 먼저 그리는 편이 낫습니다. 기사가 보여 주듯 지금 책임의 경계는 공통 규칙이 아니라 회사마다 다른 약관이 정하고, 공통 규칙이 나오면 지도를 고치면 됩니다. 순서는 책임 지도, 결제 경로 분류, 의도 기록, 고객 안내입니다. Lambert가 말한 것처럼 데이터를 더 내고 보안을 보여 주는 쪽이 협상에서 유리할 수 있으니, 근거 묶음은 분쟁 대비이면서 카드사·결제 대행사와 조건을 협의할 때 꺼낼 자료도 됩니다. 국내 법과 약관에 어떻게 적용되는지는 법무 검토로 따로 확인합니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 기사 | Payments Dive, Justin Bachman(선임 기자), 2026.10.28 |
| 핵심 주장 | agentic commerce가 분명한 책임 규칙 없이 앞서 나갔다는 은행·결제 업계의 우려 |
| 발언 출처 | Money20/20(10월 19~20일), 인터뷰, Collison 팟캐스트(10월) |
| 등장 인물 | Cameron Fowler(EWS CEO), Bill Demchak(PNC CEO), Kaitlan Moran(Visa), John Piazza(Stripe), Andrew Lambert(Cross River Bank), Stavan Parikh(Google), John Collison(Stripe 사장) |
| 기사에 나온 보호 정책 | Amex 등록 에이전트·purchase intent 문서, Stripe Link 미국 구매 보호(약관상 감시 조건) |
| 네트워크 장치 | Visa Trusted Agent(알려진 에이전트 목록)·audit trail·trust layer, Mastercard Agent Pay(승인 후 토큰화) |
| 은행 입장 | Wells Fargo 10월 2일 고객 경고(미국 자산 기준 4위 은행), PNC 책임 이전 요구, EWS(Zelle·Paze 소유사, 미국 대형 은행 7곳 공동 소유) 업계 공통 규칙 요구 |
| 생태계가 네트워크의 장치를 아직 쓰지 않음, 표준화된 기반이 몇 주·몇 달 안에 나올 것으로 봄, Stripe·결제 처리사와 에이전트 프로토콜 발표 | |
| 시장 | Meta Muse 9월 미국·캐나다 출시, 초기 사용자 1,000만 명의 1순위 작업은 쇼핑, Amazon 9월 21일 Muse 차단 |
| 법·규제 | 판례 없음(Piazza), 연방 법·기업 정책이 기술보다 뒤처짐(Fowler), 기사에 규제 당국 조치 없음 |
핵심 개념
- liability shift
- 결제 사고의 손실 부담을 한 당사자에서 다른 당사자로 옮기는 일입니다. 기사에서는 은행이 기술 기업에 요구하는 방향으로 쓰였습니다.
- four-party model
- 카드 네트워크가 수수료와 차지백 규칙으로 참여자 행동을 이끄는 기존 카드 결제 구조입니다. 기사에서는 에이전트 플랫폼이 이 구조 밖에 있다고 봅니다.
- trust layer
- Visa가 원하는 구조로, 에이전트 거래의 맥락과 데이터를 생태계 참여자가 함께 볼 수 있게 하는 층입니다.
- Trusted Agent
- Visa의 에이전트 프로토콜. 알려진 에이전트 목록을 두고 결제하는 에이전트를 가립니다.
- Link
- Stripe의 결제 지갑. Meta Muse의 결제를 돕고 미국 내 Link 구매에 보호를 제공합니다.
- banking-as-a-service
- 은행 기능을 다른 회사가 자기 서비스에 붙여 쓰게 내주는 사업 방식입니다. 기사 속 Cross River Bank가 이 사업을 합니다.
내 메모
TODO: 내 생각 추가
원문은 Payments Dive에 실린 Justin Bachman의 「Liability looms over AI shopping」(2026.10.28)입니다. 요약, 핵심 메커니즘의 기사 내용, 통념과 다른 주장, 저자가 든 사례, 원문 사례 표는 기사에 나온 발언과 사실을 AX Review가 다시 정리했으며, 각 회사의 정책과 전망은 해당 회사·인물의 설명입니다. 기술·현업 실행 디테일, JSON 예시, 책임 지도, 일정과 판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 이 노트는 법률 자문이 아니며, 실제 책임 배분은 계약·약관과 법무 검토로 확인해야 합니다. 기사 전문은 원문 페이지에서 볼 수 있습니다.