1. 서론: 구매 이유를 증명할 수 없는 서비스는 AI에게 선택받지 못한다

2026년 6월 10일, Visa가 OpenAI와의 제휴를 발표했습니다. 이는 「토큰화된 신용카드 정보」를 AI에 통합하여, 인간이 미리 설정한 조건(지출 한도, 이용 가능한 상점 카테고리, 승인 규칙 등)의 범위 내에서 AI 에이전트 스스로 직접 결제를 수행할 수 있도록 하는 것입니다.

💡 보충: 「토큰화 (Tokenization)」란

신용카드의 16자리 번호 자체를 AI에게 전달하는 것은 위험합니다. 그래서 실제 번호 대신, 특정 조건(이 AI만, 얼마까지 등) 하에서만 사용할 수 있는 「토큰」이라는 암호화된 티켓을 발행합니다. 이것이 토큰화입니다.

이 외에도, PayPal이 2025년 10월에 ChatGPT를 위한 「Instant Checkout」을 발표하고, Mastercard도 2026년 1월에 가맹점용 「Agent Suite」를 출시하는 등, 카드사나 결제 플랫폼 간의 「에이전트 대상 상거래」 주도권 싸움은 이미 시작되었습니다.

여기서 한 가지 의문이 생깁니다.

판매자 측은 어떤 시스템을 만들어야 「AI 에이전트가 상품을 구매하게」 만들 수 있을까요?

인간 사용자는 랜딩 페이지의 디자인이나 캐치프레이즈를 읽고, 왠지 좋아 보인다고 판단하여 상품을 구매합니다. 하지만 AI 에이전트는 문장을 읽고 믿는 것이 아닙니다. 실제로 직접 움직여서 검증합니다. API 서명(통신 상대가 진짜인지 나타내는 전자적 도장)을 확인하고, 트라이얼 환경을 구축하며, 실제 데이터를 흘려 넣어 스스로 퍼포먼스와 비용을 측정한 후에야 비로소 지갑을 열 것입니다.

이 기사에서는 「서비스를 발견한다 → 시도한다 → 구매한다 → 영수증을 받는다」라는 일련의 구매 프로세스를 인간의 개입 없이 완결시키는 실험에 성공했기에, 그 기록을 정리합니다.

2. 이번의 소재: 프롬프트를 압축하는 LLM 게이트웨이 「Agent Bridge (Kuchino)」

실험의 소재로 사용한 것은 제가 개발하고 있는 자체 제작 LLM 게이트웨이(코드네임: Kuchino)입니다.

💡 보충: 「LLM 게이트웨이 (LLM Gateway)」란

AI 에이전트와 실제 AI(ChatGPT 등의 API) 사이에 위치하는 「검문소」와 같은 프록시 (Proxy, 중계) 서버를 말합니다.

이 게이트웨이의 메인 기능은 「토큰 압축」입니다. 내부 메커니즘으로서 문맥 압축 기술인 **「Headroom」**을 이용하고 있습니다.

💡 보충: 「Headroom」이란

LLM에 입력하는 긴 문장(프롬프트)에서 중요한 의미는 유지한 채 불필요한 글자를 깎아내어 짧게 만드는 기술이나 메커니즘을 말합니다.

AI 에이전트가 터미널 실행 결과 등(예를 들어 수만 자에 달하는 거대한 로그)을 읽어들이려 할 때, 그대로 API에 보내면 방대한 토큰 비용이 발생합니다. Agent Bridge (Kuchino)는 Headroom 기술을 사용하여 이 긴 통신 내용을 AI에게 중계하기 직전에 똑똑하게 요약·압축함으로써, API 이용 비용을 대폭 절약하는 서비스입니다.

즉, 이번 실험에서의 「판매물(상품)」은 **「통신을 통과시키는 것만으로 AI의 API 비용이 저렴해지는 프록시 서버 (Kuchino)의 이용권」**입니다. 이것을 AI 에이전트 스스로가 「이것은 비용 절감에 도움이 되겠군」이라고 판단하게 하여 자동으로 구매하게 만들려는 것입니다.

3. 설계의 전제 조건: AI 에이전트는 무엇을 원하는가?

구현에 들어가기에 앞서, 구매자가 AI 에이전트일 경우 판매자 측이 어떤 조건을 충족해야 하는지 정리했습니다.

기계가 읽을 수 있는 상품 정보: 가격, 이용 조건, 구매용 URL 등이 홍보 문구가 아닌 구조화된 데이터(JSON 등 프로그램이 다루기 쉬운 형식)로 제공될 것. -
자동 트라이얼 (Automatic Trial): 누구의 승인도 기다리지 않고 즉시 시용 환경을 얻을 수 있어야 하며, 동시에 악용을 방지하기 위한 이용 제한이 시스템적으로 작동할 것. -
즉각적인 서비스 제공: 결제가 완료되는 순간 상품(이번에는 API 키)을 이용할 수 있을 것. 「영업일 기준 3일 이내에 연락드리겠습니다」와 같은 대응은 에이전트에게 통하지 않습니다. -
검증 가능한 영수증: 무엇을 얼마에 샀는지가 나중에 조작할 수 없는 형태로 기록에 남을 것.

개인적으로는 이 중에서 4번이 가장 중요하다고 생각합니다. 왜냐하면 AI 에이전트는 구매한 이유를 사용자(인간 또는 조직)에게 설명해야 하기 때문입니다. "왜 이 서비스를 구매했는가"를 증명하는 증거를, 구매한 시스템 스스로가 항상 계속해서 발행할 수 있는 메커니즘을 만들 수 있다면, 상품 그 자체가 영수증을 대신하게 됩니다.

4. 실제 흐름: 구매 프로세스의 한 주기

STEP 1 ― 에이전트가 상품 정보를 읽음

GET /.well-known/offer-manifest

💡 보충: /.well-known/이란

Web 세계의 "정해진 장소"입니다. "우리 서비스의 정보는 이 URL에 있으니, 기계는 여기를 보러 오세요"라는 표준적인 규칙으로 사용됩니다.

가격 플랜, 통화, 결제 페이지 URL 등이 JSON 형식으로 반환됩니다. 이는 OpenAI와 Stripe가 공개한 "Agentic Commerce Protocol (ACP)"의 개념에 맞춘, 말하자면 "디지털 점포"입니다. 에이전트는 이곳을 읽어 들여 구매 여부를 판단합니다.

STEP 2 ― 자동 트라이얼(Trial) 시작

POST /v1/charge/trial
{"idempotencyKey": "walkthrough-agent-001"}
→ {
...

번거로운 승인 절차 없이, 즉시 트라이얼용 프로젝트와 API 키가 발행됩니다. 여기서 포인트는 두 가지가 있습니다.

이용 제한에는 기존의 액세스 제어(Access Control)를 이용: 분당 10개 요청까지와 같은 시스템적인 제한을 설정함으로써, 인간의 감시 없이도 트라이얼 악용을 방지합니다. -
멱등성 (Idempotency) 확보: 멱등성이란 "몇 번이나 동일한 요청을 보내도 결과가 첫 번째와 동일하게 유지되는" 성질을 말합니다. AI는 통신 에러 시 주저 없이 요청을 연타(재전송)할 수 있습니다. 동일한 idempotencyKey로 재전송해도 같은 프로젝트가 반환되지만, API 키의 평문은 처음 한 번만 표시됩니다. 이를 통해 에이전트 측의 재시도에 대응하면서도 보안을 유지할 수 있습니다.

STEP 3 ― 에이전트가 실제 데이터로 테스트

트라이얼용 API 키를 사용하여, AI 에이전트가 실제 트래픽(이번에는 13KB나 되는 불필요하게 긴 툴 출력 로그)을 전송해 봅니다. 그러면 Agent Bridge (Kuchino)가 중간에 개입하여 해당 로그를 자동으로 압축하고, 적은 토큰 양으로 실제 LLM에 중계해 줍니다.

결과적으로, 에이전트는 자신의 메트릭(Metrics, 이용 데이터)이나 장부에 접근하여, "이 압축 서비스를 통과한 덕분에 API 토큰 비용을 얼마나 절약할 수 있었는가"를 스스로 계산할 수 있습니다.

이것은 이번 설계에서 가장 마음에 드는 부분입니다. 판매자 측이 준비한 "벤치마크 결과"를 에이전트에게 신뢰시킬 필요가 없습니다. 구매자 스스로가 실제 데이터로부터 수치를 도출하기 때문에, 애초에 마케팅용으로 과장된 숫자가 필요 없게 됩니다.

STEP 4·5 ― 구매와 즉각적인 서비스 제공

POST /v1/checkout/sessions
{"idempotencyKey": "walkthrough-agent-buy-001", "amountMinor": 2500, "currency": "USD"}
POST /v1/checkout/sessions/{id}/complete
...

결제가 완료되었을 때의 응답(Response) 안에 상품(운영 환경의 프로젝트와 API 키)과 영수증(장부의 이벤트 ID)이 직접 포함되어 있습니다. 상품 도착을 기다리는 시간은 제로입니다. 결제 처리 자체는 인터페이스를 통해 이루어지므로, 이번 모의 결제를 실제 Stripe로 전환하는 것도 설정 키를 변경하는 것만으로 충분합니다.

STEP 6 ― 변조를 감지할 수 있는 장부 이벤트에 의한 영수증

[
{ "kind": "charge.credit.granted", "prevHash": "GENESIS…", "eventHash": "…” },
{ "kind": "charge.credit.purchased", "prevHash": "(이전 이벤트의 해시)", "eventHash": "…” }
...

트라이얼 부여와 상품 구매는 전후 이벤트가 해시값(Hash value)으로 연결된 장부 데이터로서 기록됩니다.

💡 보충: 「해시값으로 연결된 장부」란

데이터가 변조되지 않았음을 감지하기 위한 「해시 체인형 (Hash chain) 감사 로그」입니다. 이전 데이터의 계산 결과(해시값)를 다음 데이터에 포함함으로써 사슬처럼 연결합니다. 과거의 데이터를 하나라도 수정하면 그 이후의 모든 계산이 맞지 않게 되므로, 사후 검증이 가능한 확실한 기록이 됩니다.

나아가, 이러한 과금 관련 이벤트(charge.* 계열)는 사용자 측에서는 쓸 수 없도록 제한되어 있습니다 (시스템 측에서만 기록 가능).

장부를 청구서나 영수증으로서 기능하게 하려면, 「구매자와 판매자 모두 편의에 따라 나중에 데이터를 마음대로 수정할 수 없다」는 조건이 필수적입니다. 이 부분을 타협하게 되면 모든 것이 단순한 자기 신고에 불과하게 됩니다.

5. 고찰: 시스템 운용이 간편한 것만으로는 경쟁 우위가 되지 않는다

이번 실험을 통해 두 가지 사실을 확인할 수 있었습니다.

첫 번째는, 「호스팅 (서버 운용 대행)」만으로는 서비스의 강점이 되지 않는다는 점입니다. 장래에는 우수한 AI 에이전트라면 소프트웨어 코드를 읽어 들여 스스로 서버에 배포하고 시스템을 운용할 수 있게 될 것입니다. 즉, "번거로운 서버 관리는 맡겨주세요"라는 기존 SaaS의 전형적인 판매 문구는 에이전트 경제에서 점차 가치를 잃어갈 것으로 생각됩니다.

그럼에도 판매 가능한 가치로 남는 것은, 직접 운용 (셀프 호스트)할 경우에는 구조적으로 얻을 수 없는 가치, 즉 **「중립성」**과 **「책임의 소재」**입니다. 자신의 서버에 기록한 장부 데이터는 결국 자기 신고에 불과하며 객관적인 증거가 될 수 없습니다. 제삼자의 장부에 기록되기 때문에 비로소 영수증으로서의 증명이 됩니다. "도장과 인주는 무료로 나눠주지만, 공증인으로서의 증명 행위 자체에 가치가 있다"는 사고방식입니다.

두 번째는, 결제 인프라는 이미 갖춰지고 있다는 점입니다. 판매자 측이 구현해야 할 것은 ACP와 같은 에이전트용 구매 인터페이스뿐이며, 신용카드 결제 토큰 (Visa와 OpenAI의 제휴와 같은 형태)은 **결제 대행사 (PSP: Payment Service Provider)**를 통해 자동으로 전달되게 될 것입니다.

나아가, HTTP 402 상태 코드를 이용한 요청 단위의 결제 (x402 등)까지 시야에 넣으면, 「요청을 처리한 것」과 「과금한 것」이 동일한 해시 체인 상에서 인접한 이벤트로 기록되게 됩니다.

💡 보충: HTTP 402란

「404 Not Found (찾을 수 없음)」와 마찬가지로 웹 통신의 상태 코드 중 하나입니다. 「402 Payment Required (결제 필요)」라는 의미로, 예전부터 규격으로서 존재해 왔지만, AI끼리 그때마다 결제를 수행하게 되면 이 402 에러가 본격적으로 활약하는 시대가 올 것입니다.

청구서라는 서류가 사라지고 장부 자체가 청구서가 되는 미래는 기술적으로 이미 실현 가능합니다 (일본에서는 자금결제법 등의 법적 정비가 필요하지만).

6. 마치며: Verification-Commerce (검증 가능한 상거래)의 시대

「AI 에이전트가 결제를 한다」고 하면 단순히 자동화나 UI의 소멸에 관한 이야기로 들릴지도 모릅니다. 하지만 실제로 만들어 보니 그 본질은 결제 메커니즘 그 자체가 아니라, **「사기 전에 검증할 수 있고, 산 후에 증명할 수 있는가」**라는 과제에 도달했습니다.

AI 에이전트는 분위기나 감정으로 쇼핑하지 않습니다. 기계 판독 가능한 오퍼(Offer), 스스로 측정하여 만든 퍼포먼스 수치, 그리고 변조를 감지할 수 있는 해시 체인형 영수증. 인간을 상대할 때는 「있으면 친절한 기능」이었던 이것들이 AI 에이전트와의 상거래에서는 필수 조건이 됩니다.

앞으로의 시대는 「AI가 사는 시대」라기보다, **구매 이유를 증명할 수 있는 서비스만이 팔리는 시대 (Verification-Commerce)**가 되어갈 것입니다.

역으로 말하면, 이러한 「증명 가능한 메커니즘」을 처음부터 구축해 온 서비스에게 AI 에이전트가 구매자가 되는 시대는 큰 순풍이 될 것입니다. 이번 실험은 아직 모의 결제 단계이지만, 「서비스를 찾고 · 시도하고 · 사고 · 영수증을 받는」 일련의 프로세스가 인간의 조작 없이 전 자동으로 완결됨을 확인할 수 있었습니다.

(실험 환경: Next.js 제작 게이트웨이 + 해시 체인 (Hash Chain) 원장 + stripe-mock. 결제 및 데이터는 모두 더미이며, 기사 내 수치는 메커니즘을 설명하기 위한 것입니다)

Discussion