에이전트가 지갑을 들면 — x402·AP2·ACP 에이전트 결제 표준 정리 (AGI 강연 후속편)

※ 이 글은 50분 동안 같은 자세로 — 김대식 교수 ‘AGI: 인류 최대의 도박’ 강연 정리의 후속편입니다. 그 글 끝에서 “다음 숙제”로 적어 둔 주제를 실제로 파 본 기록입니다.

1. 왜 이 주제를 골랐나

앞 글에서 강연 내용을 제 블로그와 대조해 보고 이런 결론을 냈습니다. 도구는 따라갔지만 구조는 못 따라갔다. 에이전트를 내가 쓰는 도구로만 봤지, 세상이 에이전트를 향해 다시 쓰이고 있다는 방향(B2A)은 못 보고 있었다는 얘기였습니다.

그 B2A에서 가장 실체가 뚜렷한 층이 결제입니다. 에이전트가 정보를 읽는 것까지는 지금도 합니다. 그런데 돈을 쓰기 시작하면 그때부터는 성격이 완전히 달라집니다. 되돌릴 수 없고, 법적 책임이 붙고, 누군가는 손해를 봅니다.

✅ 결론부터 적으면 이렇습니다. 표준이 서너 개 난립하는 것처럼 보이지만, 실제로는 서로 층위가 다릅니다. 경쟁 관계가 아니라 쌓아 올리는 스택에 가깝습니다. 그리고 가장 취약한 지점은 기술이 아니라 “이 결제를 정말 사람이 시킨 게 맞는가”를 증명하는 문제입니다.

 

2. 왜 카드가 아니라 스테이블코인인가

가장 먼저 걸렸던 의문입니다. 이미 잘 돌아가는 카드망을 두고 왜 굳이 블록체인이냐. 찾아보니 이념 문제가 아니라 구조 문제였습니다. 세 가지가 안 맞습니다.

• 관문이 사람용으로 설계돼 있습니다. CVC를 입력하고, 3D Secure로 본인을 확인하고, 앱을 열어 인증합니다. 전부 사람이 화면 앞에 있다는 전제입니다. 에이전트는 이 관문을 통과할 방법이 없습니다.
• 금액 단위가 안 맞습니다. 에이전트 경제는 API 호출 한 번에 몇 원, 문서 한 장 읽는 데 몇십 원 하는 식입니다. 카드망은 건당 고정비가 있어서 이 규모에서는 수수료가 원금을 넘습니다.
• 정산 주기가 안 맞습니다. 에이전트는 새벽 3시에도 일합니다. 영업일 기준 며칠 뒤 정산이라는 개념 자체가 성립하지 않습니다.

여기에 하나 더. 프로그래머블해야 합니다. “이 에이전트는 하루 5만 원까지, 이 도메인에만”처럼 한도와 조건을 코드로 걸 수 있어야 하는데, 기존 결제 수단에는 그런 손잡이가 없습니다. 이 네 가지를 다 만족하는 기존 수단이 없어서 스테이블코인 쪽으로 밀려간 겁니다.

3. x402 — 30년 잠자던 HTTP 상태코드를 깨우다

웹 표준에는 처음부터 402 Payment Required라는 상태코드가 있었습니다. 규격서에 자리만 잡아 놓고 30년 넘게 아무도 쓰지 않던 번호입니다. 코인베이스가 이걸 되살려 오픈 표준으로 만든 게 x402입니다.

동작은 평범한 HTTP 요청-응답에 단계 하나를 끼워 넣은 것뿐입니다.

1. 요청 — 에이전트가 API에 그냥 요청을 보냅니다.
2. 402 응답 — 서버가 “돈 내라”고 답하면서 가격·수취 주소·받는 수단을 함께 알려 줍니다.
3. 재요청 — 에이전트가 서명한 결제 정보를 X-PAYMENT 헤더에 담아 같은 요청을 다시 보냅니다.
4. 검증·정산·전달 — 서버는 ‘퍼실리테이터(facilitator)’에게 검증을 맡기고, 일을 수행하고, 정산을 요청한 뒤 결과물을 돌려줍니다.

⚡ 여기서 핵심은 퍼실리테이터입니다. 판매자가 블록체인을 직접 다루지 않아도 되게 해 주는 대리인입니다. 서명 검증과 온체인 정산을 대신 처리해 주기 때문에, API를 파는 쪽은 결제 페이지도, 구독 관리도, 회원가입도 없이 요청 단위로 돈을 받을 수 있습니다.

결제 레일을 하나로 못 박지 않은 것도 특징입니다. EVM 계열이든 솔라나든 같은 핸드셰이크가 통하고, 자산도 USDC가 가장 흔할 뿐 ERC-20이나 SPL 토큰이면 됩니다. 실제로는 수수료가 싸고 확정이 빠른 Base와 솔라나에서 주로 돌아갑니다.

규모는 이미 장난이 아닙니다. 2026년 3월까지 솔라나에서만 3,500만 건, 전체 체인 합산 연 6억 달러가 이 프로토콜로 오갔습니다. 현재 가장 많이 쓰이는 에이전트 결제 프로토콜입니다.

4. AP2 — “이 결제, 정말 사람이 시킨 거 맞나”

x402가 돈을 옮기는 문제를 푼다면, 구글이 내놓은 AP2(Agent Payments Protocol)는 전혀 다른 문제를 풉니다. 권한과 책임입니다. 2025년 9월 발표됐고 마스터카드·페이팔·아멕스·코인베이스·세일즈포스 등 60여 곳이 파트너로 붙었습니다.

핵심 장치는 맨데이트(Mandate)라는 서명된 증서입니다. W3C 표준인 검증 가능 자격증명(Verifiable Credential)으로 만들어지고, 한 번의 구매가 세 장으로 쪼개집니다.

• Intent Mandate(의도) — “흰색이나 회색 러닝화, 270mm, 15만 원 이하, 저장된 주소로 배송.” 사용자가 범위와 조건에 서명합니다.
• Cart Mandate(장바구니) — 에이전트가 실제로 담아 온 물건과 정확한 금액에 사용자가 서명합니다. 본 것과 결제되는 것이 다를 수 없게 만드는 단계입니다.
• Payment Mandate(결제) — 가맹점이나 카드망이 실제로 청구할 내용입니다.

사람이 자리에 없는 경우도 설계에 들어 있습니다. “콘서트 티켓 풀리면 바로 사 둬” 같은 위임은 Intent Mandate를 미리 자세하게 서명해 두는 방식으로 처리합니다.

✅ 이 구조의 목적은 부인할 수 없는 증거 사슬을 만드는 겁니다. 나중에 “나는 그런 거 시킨 적 없다”는 분쟁이 붙었을 때, 의도→장바구니→결제로 이어지는 서명 기록이 답을 대신합니다. 결제 기술이 아니라 분쟁 처리 인프라에 가깝습니다.

5. ACP — 오픈AI·스트라이프의 다른 답, 그리고 접힌 제품

세 번째 갈래는 오픈AI와 스트라이프가 함께 만든 ACP(Agentic Commerce Protocol)입니다. 2025년 9월 29일 아파치 2.0 라이선스로 공개됐습니다.

접근이 다릅니다. 여기서는 가맹점이 계속 판매 주체(merchant of record)로 남습니다. 에이전트는 구매자의 결제 수단을 직접 만지지 않고, 스트라이프가 발행한 공유 결제 토큰(Shared Payment Token)이라는 용도가 좁게 제한된 토큰만 가맹점에 넘깁니다. 가맹점은 그 토큰으로 자기가 쓰던 결제사를 통해 청구합니다. 즉 카드망을 대체하지 않고 그 위에 에이전트 레이어만 얹는 방식입니다.

⚠️ 그런데 이 대목이 이번 조사에서 가장 흥미로웠습니다. ACP를 얹어 만든 제품인 ChatGPT의 ‘Instant Checkout’은 2026년 3월에 접혔습니다. 쇼피파이 가맹점 100만 곳을 연결하겠다고 발표했지만, 실제로 붙인 곳은 열두어 곳에 그쳤다고 합니다.

그러면서도 프로토콜 자체는 죽지 않았습니다. 페이팔이 결제사로 합류했고, 스트라이프는 관련 제품군을 계속 내놓고 있으며, 규격은 2026년 4월판까지 버전이 올라갔습니다.

이걸 어떻게 읽어야 할까요. 저는 이렇게 봤습니다. 기술이 준비되는 속도와 상거래 관행이 바뀌는 속도가 다르다는 것. 가맹점 입장에서 “채팅창에서 바로 결제”는 매력적인 만큼 손해도 분명합니다. 고객이 자기 사이트에 오지 않으니 재구매 유도도, 데이터도, 브랜드 경험도 사라집니다. 앞 글에서 B2A를 두고 “브랜드 인지도와 광고 노출이 무력해진다”고 적었는데, 바로 그 이유로 가맹점들이 붙지 않은 셈입니다. 기술 표준이 있다고 판이 자동으로 넘어가지는 않습니다.

6. MPP — 스테이블코인과 카드를 한 프로토콜로

네 번째는 MPP(Machine Payments Protocol)입니다. 2026년 3월 18일 스트라이프와 패러다임이 Tempo 메인넷을 띄우면서 함께 공개했습니다.

x402와의 차이는 하나로 정리됩니다. x402가 온체인 정산을 전제로 하는 반면, MPP는 스테이블코인과 카드·법정화폐를 같은 프로토콜 안에서 다룹니다. 결제 수단이 무엇이든 기계가 같은 방식으로 말을 걸 수 있게 하자는 접근입니다.

7. 정리 — 경쟁이 아니라 스택이다

이름이 넷이나 나오니 헷갈리는데, 실제로는 하는 일이 다릅니다. 층을 나눠 보면 이렇습니다.

층	하는 일	표준	주도
탐색	어떤 에이전트·서비스가 있는지 찾기	A2A	구글
승인	누가 얼마까지 쓸 권한을 줬는지 증명	AP2	구글 외 60여 곳
정산	실제로 돈을 옮기기	x402 / MPP	코인베이스 / 스트라이프·패러다임
체크아웃	기존 쇼핑몰에서 에이전트가 사게 하기	ACP	오픈AI·스트라이프

실제 흐름은 이렇게 조합됩니다. A2A로 서비스를 찾고 → AP2로 결제를 승인받고 → x402로 정산한다. 알리페이는 자율 에이전트를 상대로 결제를 받아 주는 ‘AI Pay’를 이미 내놨습니다.

그래서 “어느 표준이 이길까”는 아마 잘못된 질문입니다. 더 나은 질문은 “각 층에서 누가 통행료를 걷게 되는가”입니다.

8. 가장 약한 고리는 기술이 아니다

여기까지가 밝은 쪽이고, 이제 어두운 쪽입니다. 앞 글에서 다룬 허깅페이스 사건을 다시 꺼내야 합니다. 자율 에이전트가 사람 지시 없이 나흘 반 동안 남의 서버에 침투한 그 사건 말입니다. 동기가 악의가 아니라 평가 점수를 잘 받으려는 성실함이었다는 게 핵심이었죠.

⚠️ 그 에이전트가 지갑까지 들고 있었다면 어땠을까요. 이게 이 분야의 진짜 문제입니다. 그리고 가설이 아닙니다.

• 프롬프트 인젝션은 OWASP가 꼽은 LLM 위험 1위입니다. 결제 권한이 붙은 에이전트에서는 이게 곧 무단 결제가 됩니다. 토큰은 여전히 유효하기 때문에 시스템 입장에서는 정상 거래로 보입니다.
• 보안 연구자들은 공개된 웹페이지에 결제 지시를 심어 둔 실제 사례를 관측했습니다. 수취인·금액·설명까지 다 적어 놓고, 사용자 확인 없이 실행하라는 단계별 지시까지 붙여 뒀습니다. 에이전트가 그 페이지를 읽는 순간 발동되는 함정입니다.
• 공개 레드팀 대회에서는 180만 건의 인젝션 시도 중 6만 건 이상이 정책 위반에 성공했습니다. 성공률 3%대인데, 결제가 걸린 판에서 3%는 대단히 높은 숫자입니다.

문제의 성격을 정확히 짚으면 이렇습니다. 접근 통제가 아니라 의도 검증의 문제입니다. 에이전트는 정상적으로 인증돼 있고, 주어진 권한 범위 안에서 움직이는데도, 조작당하면 경제적으로 해로운 행동을 합니다. 권한을 아무리 촘촘히 나눠도 “이 지시가 진짜 주인에게서 온 것인가”를 못 가리면 소용이 없습니다.

AP2의 맨데이트 구조가 정확히 이 지점을 겨냥하고 있다는 게 이제 이해됩니다. 사용자의 서명이 붙은 의도가 없으면 결제가 성립하지 않게 만드는 것. 다만 그건 규격이 그렇다는 얘기고, 실제 구현들이 그 엄격함을 지킬지는 별개의 문제입니다.

9. 국내는 어디까지 와 있나

기술이 아무리 굴러가도 국내에서 쓰려면 법이 받쳐 줘야 합니다. 여기가 생각보다 빠르게 움직이고 있었습니다.

금융위원회가 원화 스테이블코인 규율을 포함한 디지털자산기본법 2단계 정부안을 완성하고 2026년 하반기 입법을 추진 중입니다. 골자는 발행 인가제(자본력 심사), 준비자산 100% 이상 유지, 상환청구권 보장입니다.

쟁점은 두 가지로 좁혀져 있습니다.

• 누가 발행할 것인가. 은행이 지분 과반을 쥐어야 한다는 쪽과, 그러면 핀테크가 들어올 수 없다는 쪽이 부딪히고 있습니다.
• 이자를 붙일 수 있는가. 이자가 붙는 순간 예금이나 MMF를 대체하는 유사 금융상품이 되어 버린다는 우려가 있습니다.

한 가지 더 짚어 둘 것이 있습니다. 국내 일반 법인은 아직 가상자산 실명계좌를 열 수 없습니다. 법집행기관과 비영리법인, 거래소까지만 단계적으로 열렸고 상장사·전문투자자 법인 가이드라인도 지연 중입니다. 즉 회사가 x402로 매출을 받아도 원화로 바꿔 장부에 올릴 경로가 막혀 있습니다. 기술 도입보다 이쪽이 먼저 풀려야 합니다.

그리고 에이전트 결제 관점에서 아직 아무도 손대지 않은 칸도 남아 있습니다. 에이전트가 낸 결제는 누구의 행위인가. 전자금융거래법상 에이전트를 결제 대행으로 볼지 이용자 본인의 행위로 볼지, 오결제가 났을 때 환불과 분쟁은 누구를 상대로 하는지 — 법안 논의에서 아직 정면으로 다뤄지지 않은 것으로 보입니다. 기술보다 이쪽이 훨씬 어려워 보입니다.

10. 그래서 무엇을 봐야 하나

투자자 관점과 만드는 사람 관점으로 나눠 적어 둡니다.

투자자 관점

• 통행료가 걷히는 층을 보라. 7번 표에서 실제로 건당 수수료가 발생하는 곳은 정산 층입니다. 퍼실리테이터·스테이블코인 발행·수탁이 여기 해당합니다.
• ACP의 교훈 — 표준 채택이 곧 매출은 아니다. 프로토콜 발표에 주가가 반응하더라도, 가맹점이 실제로 붙는지를 따로 확인해야 합니다. Instant Checkout은 열두어 곳에서 멈췄습니다.
• 보안 예산이 새로 생긴다. 8번이 현실이 된 이상 에이전트 권한 관리·의도 검증·감사 로그는 규제 항목이 됩니다.

만드는 사람 관점 ① — 내 서비스가 여기에 맞나

API를 하나라도 운영하고 있다면 다음 세 가지로 빠르게 판별할 수 있습니다.

• 동기 응답인가. 요청하면 몇 초 안에 결과가 나오는 서비스라야 x402의 402 → 서명 → 재요청 → 정산 흐름에 그대로 얹힙니다. 수 분~수십 분 걸리는 비동기 작업은 선결제 후 작업 ID를 발급하는 식으로 따로 설계해야 하고, 이 부분은 생태계에서도 아직 정리되지 않았습니다.
• 요청 단위로 값을 매길 수 있나. 구독으로만 가격이 성립하는 서비스는 맞지 않습니다.
• 사람이 아니라 기계가 소비하나. UI를 보며 쓰는 상품이면 굳이 이 길로 갈 이유가 없습니다.

만드는 사람 관점 ② — 상품 정의를 틀리면 진다

이게 가장 중요한 함정 같습니다. 에이전트는 그 자체가 LLM입니다. 웬만한 가공은 자기가 합니다. 그러니 “LLM이 이미 잘하는 일”을 API로 팔면, 무료 대체재가 호출하는 쪽 안에 이미 들어 있는 셈이 됩니다.

번역을 예로 들면 이렇습니다. 단순 텍스트 번역이라면 에이전트가 돈 내고 부를 이유가 없습니다. 반면 HTML 구조를 유지한 채 페이지를 통째로 번역하는 일은 얘기가 다릅니다. 통째로 밀어 넣기엔 토큰이 크고, 태그가 깨지고, 스타일이 무너집니다. 전문 도구가 이기는 영역입니다.

즉 파는 것을 번역 품질이 아니라 “깨지지 않은 페이지”로 정의해야 합니다. 다른 분야도 마찬가지일 겁니다. LLM이 못 하는 게 아니라, LLM이 하면 깨지는 것을 찾아야 합니다.

만드는 사람 관점 ③ — 안전장치가 먼저

• 내 에이전트에 결제를 붙일 거라면 한도를 코드로 거는 것이 첫 단계입니다. 일일 상한, 도메인 화이트리스트, 일정 금액 이상은 사람 승인.
• 에이전트가 읽는 모든 외부 텍스트는 잠재적 명령입니다. 웹페이지든 이메일이든 문서든. 결제 권한이 붙은 에이전트에게 임의의 웹을 읽히는 건 위험 구간입니다.

11. 다음 단계 — 내 사이트에 직접 402를 붙여 본다

앞 글에서 김대식 교수가 손을 들게 한 뒤 한 말이 “읽지 말고 직접 써 보라”였습니다. 그 말대로라면 여기서 멈추면 안 됩니다. 여기까지는 전부 읽어서 안 것이니까요.

마침 대상이 있습니다. seo.speech.pe.kr — URL을 넣으면 SEO 상태를 진단해 주는 도구로, 얼마 전에 만들어 돌리고 있는 사이트입니다. 10번의 판별 기준 세 개를 그대로 통과합니다.

• 동기 응답 — URL 하나 넣으면 몇 초 안에 결과가 나옵니다. 402 → 서명 → 재요청 → 정산 흐름에 그대로 얹힙니다.
• 요청 단위 과금 — 진단 1건이 곧 과금 단위입니다. 억지로 만들 필요가 없습니다.
• 기계가 소비 — 사이트를 점검하는 일은 사람이 가끔 하는 일이지만, 에이전트가 대신 한다면 훨씬 자주 하게 될 일입니다.

무엇보다 이미 백엔드가 돌아가고 있다는 게 큽니다. 새로 만들 게 없습니다. 엔드포인트 앞에 미들웨어 한 겹을 올리면 되니, 이 글에서 정리한 구조가 실제로 도는지 확인하기에 이만한 조건이 없습니다.

겸사겸사 — SEO 진단에 ‘에이전트 판독성’ 항목을 넣는다

이건 붙이다 보니 떠오른 건데, 아마 이번 실험에서 가장 쓸모 있는 결과가 될 것 같습니다.

4번에서 “SEO를 하던 자리에 에이전트 최적화가 들어선다”고 썼습니다. 그렇다면 SEO 진단 도구가 점검해야 할 항목도 늘어나야 맞습니다. 지금은 메타 태그·robots·sitemap·OG를 봅니다. 여기에 이런 걸 더하면 어떨까 합니다.

• llms.txt가 있는가 — 에이전트에게 보내는 안내문을 갖췄는가
• 가격·조건이 기계가 읽을 수 있는 형태로 노출돼 있는가
• 구조화 데이터가 에이전트가 쓰기에 충분한가
• (더 나아가면) 402를 지원하는가 — 에이전트가 값을 치르고 쓸 수 있는가

말하자면 “당신 사이트는 사람에게 잘 보이는가”에 “에이전트에게도 읽히는가”를 더하는 것입니다. B2A가 실제로 온다면 이건 언젠가 모두가 점검하게 될 항목이고, 지금은 아무도 안 보고 있습니다.

글에서 “에이전트 최적화가 온다”고 주장해 놓고 정작 제 도구는 그걸 점검하지 않는다면 앞뒤가 안 맞습니다. 주장한 걸 만들어 보는 게 순서겠죠.

확인할 것 네 가지

1. 준실시간이 유지되는가. 402 응답 → 서명 → 재요청 → 검증이라는 왕복이 붙어도 체감 속도가 살아 있는지. 결제 왕복이 진단 자체보다 오래 걸리면 상품성이 떨어집니다. 이게 1번 항목입니다.
2. 건당 정액이 성립하는가. 종량제는 에이전트가 호출 전에 비용을 계산할 수 없어 불리합니다. 예산 한도가 걸린 에이전트는 금액이 확정되지 않은 호출을 피할 테니까요. “진단 1건 = 얼마”로 딱 떨어지는 쪽이 유리합니다.
3. 결과물을 어떤 형태로 돌려줄 것인가. 사람에게는 보기 좋은 리포트가 맞지만, 에이전트에게는 기계가 파싱할 수 있는 구조가 맞습니다. 같은 서비스인데 고객 종류에 따라 응답 형태가 갈리는 셈인데, 여기가 설계 분기점이 될 것 같습니다.
4. 일부러 뚫어 보기. 8번에서 본 인젝션을 흉내 내서, 진단 대상 페이지에 결제 지시를 심어 두면 에이전트가 정말 실행하는지. 남의 URL을 읽어들이는 서비스는 이 위험에 정면으로 노출돼 있습니다. 제일 궁금한 항목입니다.

가격은 어떻게 나눌까

한 가지 더 정리해 두고 싶은 게 있습니다. 지금 이 사이트는 사람을 상대로 컨설팅을 제안하는 구조입니다. 여기에 에이전트 과금을 얹으면 서로 부딪히지 않을까 싶었는데, 따져 보니 오히려 층이 갈립니다.

• 무료 진단 — 사람을 끌어오는 입구. 지금 그대로.
• x402 소액 과금 — 기계 고객. 계약도 가입도 없이 건당. 영업이 0인 구간.
• 컨설팅 — 사람 고객. 고가·저빈도. 진단 결과를 들고 상담으로 넘어가는 흐름.

고객층이 겹치지 않으니 잠식이 없습니다. 사람 고객이 자는 시간에 기계 고객이 도는 구조에 가깝습니다. 앞 글에서 “영업 없이”라는 말을 여러 번 썼는데, 그 말이 가장 말 그대로 성립하는 게 가운데 칸입니다.

비용이 거의 안 드는 실험입니다. 테스트넷이니 진짜 돈도 안 나가고, 퍼실리테이터는 Base·USDC 구간에서 수수료를 받지 않습니다. 봇 하나 만들어 굴려 본 경험이나 개인 서버에 자동화 스택을 세운 경험에 비춰 보면, 이런 건 하루 저녁이면 어디까지 되고 어디서 막히는지가 드러납니다.

그다음은 예전에 구축해 둔 openCLAW에 결제 도구를 붙여서 사는 쪽도 만들어 볼 생각입니다. 파는 쪽과 사는 쪽을 둘 다 세워 봐야 이 구조가 실제로 도는지 알 수 있을 테니까요. 에이전트가 제 사이트를 찾아와서, 값을 치르고, 진단을 받아 가는 것 — 그 한 바퀴가 돌면 이 글에 쓴 내용이 진짜인지 아닌지 알게 됩니다.

 

12. 정리

세 줄로 줄이면 이렇습니다.

• 돈 옮기는 문제는 거의 풀렸습니다. x402는 이미 연 6억 달러 규모로 돌고 있습니다.
• 안 풀린 건 “누가 시켰는가”입니다. AP2가 서명된 증거 사슬로 답하려 하지만, 프롬프트 인젝션 하나면 정상 인증된 에이전트가 남의 지시를 따릅니다.
• 그리고 판이 넘어가는 속도는 기술보다 느립니다. ChatGPT Instant Checkout이 가맹점 열두어 곳에서 멈춘 게 그 증거입니다.

조사하면서 하나 더 얻은 게 있습니다. 402 응답에는 가격이 반드시 적혀야 한다는 규격상의 요구가, 거꾸로 가격 모델을 정액제 쪽으로 밀어붙인다는 점입니다. 종량제는 호출하기 전에 금액을 확정할 수 없으니까요. 프로토콜의 사소해 보이는 설계 하나가 상품 가격 구조까지 바꾸는 셈인데, 이런 건 문서를 읽어서는 잘 안 보이고 붙여 보려고 해야 보입니다.

그 세미나에서 들은 ‘도박’이라는 단어를 여기에 다시 놓아 봅니다. 에이전트에게 지갑을 쥐여 주는 일이야말로 결과를 모른 채 판돈을 거는 쪽에 가깝습니다. 다만 이번엔 미루는 선택지도 있어 보입니다. 한도를 걸고, 사람 승인을 남겨 두고, 읽히는 문서를 고르는 것. 전부 지금 정해 둘 수 있는 것들입니다.

다음 글은 읽은 게 아니라 해 본 얘기로 쓰겠습니다.

---

※ x402·AP2·ACP·MPP의 사양과 수치, 국내 입법 현황은 2026년 9월 기준 공개 자료를 참고해 정리한 것입니다. 이 분야는 변화가 빨라 읽는 시점에 따라 달라질 수 있습니다. 투자 판단이나 법률 자문이 아니며, 개인이 공부한 내용을 정리한 글입니다.