에이전트가 결제하는 시대 누가 실수의 비용을 떠안을까

2026년 10월 1일 기준

에이전트 커머스와 블록체인을 다루는 행사에 다녀왔다. 현장에서는 한국 시장이 아직 초기 단계이고, 규제와 사업자 요건 때문에 당장 서비스를 만들기 쉽지 않지만 인프라는 미리 준비해야 한다는 이야기가 나왔다.

이야기를 들으며 한 가지는 구분해서 봐야겠다고 생각했다. 에이전트가 대신 결제하는 것과 블록체인으로 결제하는 것은 서로 다른 문제다. 두 기술이 잘 맞는 영역은 있겠지만, 에이전트 경제가 커진다고 모든 결제가 블록체인으로 옮겨가는 것은 아니다.

그리고 결제 방식보다 먼저 풀어야 할 질문이 있었다. 에이전트가 내 의도를 잘못 이해한 채 돈을 썼을 때, 그 실수는 누가 책임질까. 결제 성공 기록만으로는 이 질문에 답하기 어렵다.

1 대신 판단하는 일과 돈을 보내는 일

에이전트 결제에는 적어도 두 가지 일이 섞여 있다. 하나는 사용자의 요청을 해석하고 무엇을 살지 판단하는 일이다. 다른 하나는 정해진 금액을 판매자에게 전달하는 일이다.

예를 들어 “다음 주 출장 숙소를 잡아줘”라는 요청에는 여러 판단이 들어간다. 출장 장소와 가까운지, 늦게 도착해도 체크인이 가능한지, 취소할 수 있는지, 예산에 세금이 포함되는지. 에이전트는 이런 조건을 확인하고 상품을 선택한다. 그다음 결제에는 카드나 계좌, 스테이블코인 등 여러 수단을 쓸 수 있다.

이미 미국에서는 이런 구분이 제품으로 나타나고 있다. Meta의 Muse는 Link에 연결한 결제수단을 이용해 구매할 때마다 총액에 대한 사용자의 승인을 받는다. (Stripe의 Muse 결제 발표)

Stripe는 2026년 9월 29일 Muse와 Instinct 등이 Link의 에이전트 지갑을 사용한다고 밝혔다. 같은 발표에서, 사용자가 예산을 정해두면 개별 거래마다 승인하지 않아도 되는 지출 통제 기능은 앞으로 도입할 계획이라고 설명했다. 현재 가능한 일과 앞으로 가능해질 일은 구분할 필요가 있다. (Stripe의 Link 업데이트 발표)

나도 ChatGPT에서 지갑 관련 화면을 보며 결제 기능이 더 가까워졌다고 느꼈다. 다만 화면에 지갑이 보인다는 사실만으로 자율 결제나 암호화폐 결제가 곧 모든 사용자에게 열린다고 단정할 수는 없다. OpenAI의 에이전트 커머스 문서에서도 판매자는 기존 결제대행사를 활용할 수 있다. 에이전트와 결제수단의 관계는 처음부터 하나로 고정돼 있지 않다. (OpenAI 에이전트 커머스 문서)

블록체인에는 별도의 장점이 있다. 소프트웨어가 지갑을 통해 자금을 보내고, 정해진 조건에 따라 거래하도록 구성하기 좋다. 하지만 지갑 주소를 만들 수 있다는 것과 그 지갑에 구매 권한을 줘도 된다는 것은 별개의 질문이다. 주소만으로 그 에이전트가 누구를 위해 움직이는지, 얼마까지 써도 되는지, 결과가 잘못됐을 때 누구에게 연락해야 하는지 알 수는 없다.

2 작은 API 거래가 먼저 열릴 수 있다

행사에서 흥미로웠던 부분은 API와 데이터의 단건 거래였다. 에이전트가 일하는 도중 필요한 데이터 하나를 사고, 특정 도구를 한 번 호출하고, 유료 자료 일부를 읽는 시장이다.

사람에게는 이런 거래가 번거롭다. 자료 하나를 보기 위해 회원가입을 하고, 결제수단을 등록하고, 한 달 구독까지 해야 한다면 그냥 다른 자료를 찾을 수 있다. 에이전트가 작업의 맥락 안에서 가격과 필요성을 판단하고 작은 비용을 지불할 수 있다면, 지금까지 거래를 성사시키는 수고가 더 컸던 자원에도 가격을 붙일 여지가 생긴다.

x402는 이런 흐름과 잘 맞는다. HTTP의 402 Payment Required 응답을 활용해 필요한 결제 조건을 알리고, 결제를 확인한 뒤 자원에 접근하게 하는 방식이다. Coinbase 문서는 API나 디지털 서비스를 요청하는 흐름 안에서 가격 확인과 결제, 접근을 이어갈 수 있다고 설명한다. 결제 검증과 정산은 facilitator 같은 인프라가 맡을 수 있다. 특정 결제 경로 하나만을 강제하는 구조도 아니다. 다만 프로토콜이 허용하는 선택지와 실제 서비스가 지원하는 네트워크·자산은 따로 확인해야 한다. (Coinbase x402 작동 방식)

콘텐츠 접근에서도 비슷한 시도가 있었다. Cloudflare가 2025년 7월 발표한 Pay per crawl은 콘텐츠 제공자가 AI 크롤러의 접근을 허용하거나 막는 데 더해, 요청당 요금을 부과하는 선택지를 제시했다. 당시 비공개 베타로 소개됐고, Cloudflare가 결제 주체인 Merchant of Record 역할과 기술 인프라를 맡는 구조였다. HTTP 402를 사용한다는 공통점만으로 이를 x402나 블록체인 결제와 같은 구현이라고 보면 안 된다. (Cloudflare Pay per crawl 발표)

여기서 새로워질 수 있는 것은 판매 단위다. 소프트웨어 구독 하나를 파는 대신 데이터 조회 한 번, 특정 결과물에 필요한 계산 한 번을 팔 수 있다. 에이전트는 작업 중 그 자원이 필요한지 판단하고 구매를 이어갈 수 있다. 저렴하고 빠른 결제 인프라에 실제로 자원을 소비하는 에이전트가 붙는다는 점에서, 오래된 마이크로페이먼트 논의를 다시 볼 이유가 생긴다.

물론 결제가 쉬워진다고 곧바로 시장이 생기는 것은 아니다. 무료 대안보다 나은 결과를 주는지, 정보를 사용할 권리가 있는지, 유료 호출이 작업의 가치를 얼마나 높이는지 확인해야 한다. 10원짜리 요청도 반복되면 큰 비용이 된다. 단건 가격만 낮추는 것과 전체 작업을 경제적으로 만드는 것은 다르다.

3 돈이 정확히 갔어도 잘못된 구매일 수 있다

결제 인프라가 처리하는 정확성과 사용자가 기대하는 정확성 사이에는 간격이 있다.

판매자에게 정확한 금액이 전달됐어도 에이전트가 잘못된 날짜의 항공권을 샀을 수 있다. 예산은 지켰지만 취소 불가능한 숙소를 예약했을 수도 있다. 시스템에는 정상 거래이고, 사용자에게는 명백한 실수다. 승인한 에이전트가 내 의도와 다르게 행동한 상황을 어디에 넣을지가 중요해진다.

이 문제는 이미 약관에 들어와 있다. 2026년 9월 30일 확인한 Link Agentic Terms는 사용자가 연결을 승인한 에이전트의 거래에 대해, 버그나 환각, 지시 오해로 발생했거나 사용자의 지시와 다른 거래도 사용자와 Stripe 사이에서는 사용자가 책임지는 것으로 규정한다. Stripe 자체의 기술적 실패나 오류에 따른 예외가 있고, 적용 법률이 보장하는 소비자 권리도 별도로 고려해야 한다. 해당 에이전트 거래는 약관상 미국 소비자 대상 무단 거래 보호의 Unauthorized Transactions로 보지 않는다고 명시돼 있다. (Link Agentic Terms)

그렇다고 에이전트가 산 물건은 전부 환불할 수 없다는 뜻은 아니다. 판매자의 반품·환불 절차와 Link의 환불 요청 경로는 존재한다. Stripe는 Muse를 통한 적격 구매에 구매 보호도 제공한다고 발표했다. 다만 이러한 보호의 대상과 조건을, 에이전트가 사용자의 의도를 잘못 이해했을 때 발생하는 모든 손실의 보상과 동일하게 볼 수는 없다. (Stripe의 Link 업데이트 발표) (Link Agentic Terms)

여기서 내가 주목하게 된 것은 ‘승인’의 범위다. 나는 에이전트에게 일을 맡겼다. 그런데 서비스는 그 연결을 어디까지 허락한 것으로 해석하는가. 사용자가 이해한 위임과 시스템에 기록된 권한이 다르면, 문제는 결제 이후에야 드러난다.

4 동의는 버튼 하나로 끝나지 않는다

HCI 관점에서 에이전트 결제를 보면, 사용자가 무엇을 이해하고 무엇을 맡겼는지 확인하는 과정이 핵심이 된다. “구매하시겠습니까?”라는 질문을 한 번 보여줬다고 충분할까.

사용자가 직접 쇼핑할 때는 상품 페이지와 장바구니, 배송 조건을 차례로 보게 된다. 에이전트가 이 과정을 대신하면 사용자는 중간 정보를 훨씬 적게 본다. 시간을 아낄 수 있지만, 잘못된 선택을 발견할 기회도 줄어든다. 편리해진 만큼 무엇을 요약해서 보여주고, 어떤 순간에 다시 물을지 더 세심하게 설계해야 한다.

먼저, 위임하는 목적과 허용 조건을 함께 보여줘야 한다. 가령 출장 숙소를 예약한다면 “20만 원 이하”만으로는 부족하다. 1박 기준인지 전체 숙박 기준인지, 세금과 수수료를 포함하는지, 무료 취소가 필요한지, 장소가 바뀌어도 되는지까지 합의해야 한다. 사용자가 모든 조건을 처음부터 알아서 적기를 기대하는 대신, 에이전트가 빠진 조건을 확인하는 흐름이 필요하다.

다음은 실제로 강제되는 한도다. 프롬프트에 “예산을 넘기지 마”라고 쓰는 것만으로 돈이 보호되는 것은 아니다. 거래별 한도와 작업 전체의 한도, 허용된 판매자, 사용 기한 등을 결제를 실행하는 쪽에서도 확인해야 한다. 스마트 어카운트나 제한된 결제 자격증명 같은 수단을 활용할 수 있지만, 어떤 기술을 쓰든 핵심은 에이전트의 판단과 별개로 제한이 작동하는지다.

그리고 조건이 달라질 때 다시 동의를 받아야 한다. 배송비가 추가되거나, 일회성 구매가 구독으로 바뀌거나, 예약이 환불 불가로 바뀌는 상황은 처음 허락한 거래와 다르다. 이런 변경을 작은 글씨에 넣어두는 대신, 무엇이 달라졌고 왜 다시 판단해야 하는지 보여줘야 한다. 모든 클릭마다 묻는 방식과 아무것도 묻지 않는 방식 사이에 설계할 공간이 많다.

마지막으로 사고 이후의 흐름이 있어야 한다. 사용자는 에이전트를 멈추고 남은 권한을 회수할 수 있어야 한다. 어떤 요청과 승인으로 이 거래가 일어났는지 확인하고, 누구에게 취소나 환불을 요청할지 알아야 한다. 나중에 로그 파일을 찾아보라는 방식으로는 일상적인 구매 경험을 만들기 어렵다.

예를 들어 자료 조사에 5천 원을 허용했다면, 에이전트가 산 자료와 남은 예산을 한눈에 볼 수 있어야 한다. 같은 요청이 실패하면서 반복 결제될 때는 멈추고 알려줘야 한다. 비용을 쓴 뒤에도 근거가 부족했다면, 그 사실 역시 결과물과 함께 전달해야 한다. 결제 영수증과 작업의 성과를 사용자가 연결해 이해할 수 있어야 한다.

5 에이전트의 신원보다 더 많은 것이 필요하다

현장에서는 KYA, Know Your Agent라는 말도 나왔다. 이 에이전트가 무엇인지 아는 것에 더해, 누구에게 어떤 권한을 받았고 어디까지 행동할 수 있는지 알아야 한다는 문제의식으로 들었다.

이때 여러 질문을 하나로 묶지 않는 것이 중요하다. 뒤에 실제 사람이 있는지, 특정 사용자가 이 에이전트를 승인했는지, 이번 거래가 승인 범위 안인지, 이전에도 일을 잘했는지는 서로 다른 정보다. 사람임을 증명하거나 좋은 평판을 쌓았다는 사실만으로 특정 구매의 권한이 생기지는 않는다.

실제로 Mastercard와 Google이 2026년 3월 공개한 Verifiable Intent는 사용자가 부여한 권한과 에이전트의 행동을 검증 가능한 기록으로 연결하려는 시도다. 그러나 공개된 보안 모델은 분쟁 처리 절차와 책임 배분, 중재까지 이 규격이 정하는 것은 아니라고 설명한다. 무엇을 승인했는지 증명하는 일은 중요하지만, 그 증거를 바탕으로 누가 어떻게 구제할지도 정해야 한다. (Mastercard Verifiable Intent 발표) (Verifiable Intent 보안 모델)

평판과 행동 이력을 쌓는다면 또 다른 설계 문제가 생긴다. 한 번의 실패를 어떤 맥락으로 기록할지, 잘못된 기록을 누가 정정할지, 사용자의 구매 내역을 얼마나 공개해야 할지다. 신뢰를 얻기 위해 모든 행동을 영구히 공개하는 방식이 적절한지도 따져봐야 한다. 필요한 거래 정보를 검증하는 것과 생활 전체를 노출하는 것은 구분할 수 있어야 한다.

6 한국에서 준비할 인프라의 범위

행사에서는 국내 규제와 가상자산사업자 신고의 어려움도 자주 언급됐다. 사업을 시작하려는 입장에서는 기술 구현 외에 확인해야 할 것이 많다는 뜻으로 들렸다.

다만 이 상황을 “한국은 에이전트 결제가 불가능하다”거나 “관련 법적 보호가 전혀 없다”로 정리하면 너무 넓은 결론이 된다. 카드로 구매를 대행하는 서비스와 고객의 가상자산을 보관·이전하는 서비스는 구조가 다르다. 어떤 자산을 다루고, 누가 통제하고, 어떤 행위를 대신하는지부터 나눠서 봐야 한다.

금융위원회가 2026년 8월 공개한 가상자산사업자 신고매뉴얼 개정 설명에서도 비수탁형 지갑의 신고 대상 여부를 이름만으로 판단하지 않는다. 사업자의 단독 자산 이전 가능성, 개인키에 대한 관리권한, 이용자가 실질적인 서명 주체인지 등을 종합적으로 본다고 설명한다. 에이전트가 붙었다고 모든 서비스에 같은 신고 요건이 적용되는 것도, 개인키를 직접 보관하지 않는다고 자동으로 검토가 끝나는 것도 아니다. (금융위원회 신고매뉴얼 개정 설명)

그렇다면 지금 준비할 수 있는 일도 더 구체적으로 보인다. 에이전트가 사용할 수 있는 API를 열고, 사용량과 가격을 명확히 하고, 위임 범위와 지출 한도를 기록하고, 사고가 났을 때 되돌아갈 경로를 만드는 일이다. 국제적으로 논의되는 규격과 연결하면서 국내의 결제·소비자 보호 체계에서 누가 어떤 역할을 맡을지도 확인해야 한다.

블록체인을 쓰는 팀과 카드 결제를 쓰는 팀 모두 이 과제를 만난다. 돈이 이동하는 경로는 달라도, 사용자가 이해할 수 있는 권한과 책임의 구조가 필요하기 때문이다.

7 어디까지 맡길 수 있는가

에이전트 경제가 언제 본격적으로 열릴지는 아직 알기 어렵다. API와 데이터처럼 작고 빠른 거래가 먼저 늘어날 수도 있고, 익숙한 쇼핑과 예약 안으로 에이전트가 들어올 수도 있다. 어느 쪽이든 실제 수요와 반복 사용을 확인해야 한다.

이번 행사에서 가져온 질문은 조금 더 구체적이다. 결제를 붙였을 때 기존에는 너무 번거로워 성립하지 않았던 거래가 생기는가. 사용자는 절약한 시간만큼 새로운 위험을 이해하고 있는가. 그리고 실수했을 때 감당할 비용이 정해져 있는가.

에이전트에게 돈을 쓸 수 있게 해주는 일은 빠르게 진행되고 있다. 이제 그 권한을 사용자가 이해하고 조절할 수 있게 만드는 일도 함께 진행돼야 한다. 얼마까지 쓸 수 있는지, 언제 다시 물어야 하는지, 잘못됐을 때 어디서 멈추고 어떻게 돌려받을지.

그 질문들에 답할 수 있을 때, 사용자는 비로소 에이전트에게 다음 일을 맡길 수 있을 것이다.