에이전트 결제: 이제 도구 호출이 조달(Procurement)이 됩니다

오랫동안 "에이전트가 도구를 호출했다"라는 말은 기술적인 문장처럼 들렸습니다.

그것은 문서를 검색했습니다. 날씨 API를 호출했습니다. 데이터베이스를 쿼리했습니다. 티켓을 생성했습니다. 심지어 소프트웨어조차 이제 회의가 필요한 것인지, 다른 에이전트에게 도움을 요청하기도 했습니다.

그러다 AWS가 Coinbase 및 Stripe를 기반으로 구축된 Amazon Bedrock AgentCore 결제 기능을 미리보기로 선보였고, 그 문장의 형태가 바뀌었습니다.

이제 에이전트는 도구를 호출하고 그에 대한 비용을 지불할 수 있습니다.

the agent discovering expense policy during a tool call

자세히 들여다보면 작은 기능처럼 들릴 수도 있습니다. 작은 지갑, 작은 x402, 약간의 "결제 필요 (Payment Required)" 응답 같은 것 말이죠.

하지만 이것은 작지 않습니다.

이는 도구 접근(tool access)이 더 이상 인증(authentication)에만 국한되지 않음을 의미합니다.

이는 실행 경로(execution path) 내에서의 조달(procurement)입니다.

API 호출에 이제 영수증이 생겼습니다

AgentCore 결제는 에이전트가 실행 중에 마이크로 트랜잭션 (microtransactions)을 수행할 수 있게 합니다: 유료 API, MCP 서버, 웹 콘텐츠 및 기타 에이전트 등이 대상입니다. AWS는 세션 수준의 지출 한도, Coinbase CDP 또는 Stripe Privy를 통한 지갑 연결, x402 지원, 결제 증명(payment proofs), 그리고 에이전트 플랫폼을 통한 관측성 (observability)을 설명합니다.

제품의 핵심 가치는 이해하기 쉽습니다.

오늘날 연구 에이전트가 유료 시장 데이터 포인트, 특화된 API 또는 유료 결제가 필요한 소스(paywalled source)가 필요하다면, 누군가는 결제 관계를 연결해야 합니다. 법인 카드가 있을 수도 있고, 이미 두 번의 생일을 맞이한 TEMP_RESEARCH_KEY_DO_NOT_ROTATE라는 이름의 공유 API 키가 있을 수도 있습니다.

이것은 확장 가능하지 (scale) 않습니다.

에이전트가 동적으로 서비스를 선택하게 될 것이라면, 동적으로 결제할 수 있는 방법도 반드시 있어야 합니다. 코딩 에이전트는 유료 MCP 서버가 필요할 수 있습니다. 브라우저 에이전트는 유료 결제가 필요한 페이지가 필요할 수 있습니다. 금융 연구 에이전트는 파일럿 프로젝트가 끝난 후 아무도 설명할 수 없는 구독권을 유지하는 대신, 데이터 포인트 하나를 직접 구매할 수도 있습니다.

이것은 매우 유용합니다.

또한 이는 엔지니어링이 후드티를 입고 재무(finance) 분야로 직접 걸어 들어가는 지점이기도 합니다.

권한 프롬프트(permission prompts)는 예산 통제 수단이 아닙니다

가장 먼저 떠오르는 본능은 지출 앞에 인간의 승인 프롬프트(approval prompt)를 두는 것입니다.

"이 에이전트가 0.08달러를 사용하려고 합니다. 허용하시겠습니까?"

이것이 아무것도 없는 것보다는 낫습니다. 하지만 이는 또한 송장(invoices)을 통해 알림 피로(notification fatigue)를 쌓는 방식이기도 합니다.

인간은 고립된 상태에서 반복되는 아주 작은 결정들을 평가하는 데 매우 취약합니다. 8센트는 무해해 보입니다. 12센트도 마찬가지입니다. 에이전트가 "답변 품질을 개선하기 위해 필요하다"라고 말하며 수행하는 유료 조회(paid lookup)도 마찬가지입니다.

진정한 통제 수단은 프롬프트가 아닙니다.

진정한 통제 수단은 워크플로(workflow)를 둘러싼 예산 계약(budget contract)입니다.

이 에이전트가 무엇을 구매할 수 있습니까? 어떤 판매자(merchants)로부터 구매할 수 있습니까? 어떤 작업 유형(task types)을 위해서입니까? 세션, 사용자, 프로젝트 및 월별 최대 지출 한도는 얼마입니까? 유료 호출(paid calls)을 재시도할 수 있습니까? 10개의 유료 엔드포인트(endpoints)로 확장(fan out)한 다음 가장 좋은 것을 선택할 수 있습니까? 다른 에이전트에게 비용을 지불하고, 그 에이전트가 다시 다른 무언가에 비용을 지불할 수 있습니까?

the finance dashboard meeting the agent loop

이 지점에서 플랫폼 작업이 시작됩니다.

에이전트 결제 시스템에는 허용 목록(allowlists), 지출 한도(spend caps), 만료 시간(expiry times), 판매자 카테고리(merchant categories), 승인 임계값(approval thresholds), 감사 추적(audit trails), 비용 귀속(cost attribution), 그리고 아마도 첫 주에는 몇 개의 화가 난 Slack 메시지들이 필요할 것입니다. 우리가 이미 클라우드 예산, CI 분(minutes), 운영 API 키(production API keys), 데이터 내보내기(data exports)에 적용하고 있는 것과 동일한 지루할 정도로 진지한 태도가 필요합니다.

왜냐하면 에이전트는 더 이상 "그저 둘러보는 것"이 아니기 때문입니다.

에이전트는 지출을 하고 있습니다.

소액 결제(micropayments)가 거버넌스(governance)를 소규모로 만들지는 않습니다

소액 결제(micropayments)가 매력적인 이유는 개별 트랜잭션(transaction)이 매우 작기 때문입니다.

그것이 바로 소액 결제가 교묘한 이유이기도 합니다.

단일 고가 SaaS 계약은 눈에 보입니다. 조달 티켓(procurement tickets), 보안 검토(security review), 그리고 벤더가 숫자가 적힌 유쾌한 이메일을 보낼 때까지 모두가 잊어버리는 갱신 날짜가 존재합니다.

소규모 에이전트 트랜잭션(transactions)은 다릅니다. 이는 일반적인 업무 과정 내부에서 발생합니다. 수천 건의 작은 구매는 누군가 플랫폼 비용이 왜 변했는지 물어보기 전까지는 운영상의 노이즈(operational noise)처럼 보일 수 있으며, 그 답변은 "에이전트가 프리미엄 인리치먼트 엔드포인트(premium enrichment endpoints)를 선호했습니다"가 될 것입니다.

참으로 멋진 일이군요. 봇이 재량 지출(discretionary spending)을 발견한 것입니다.

이것이 바로 관측성(observability)이 중요한 이유입니다. 유용한 관측성이란 다음과 같습니다:

어떤 에이전트가 돈을 썼는가
어떤 사용자나 워크플로우(workflow)가 이를 승인했는가
어떤 가맹점(merchant)에 지불되었는가
어떤 작업에 지출이 필요했는가
어떤 답변이나 아티팩트(artifact)가 유료 결과를 사용했는가
동일한 결과가 캐싱(cached)되었는가
재시도(retries) 시 다시 비용이 지불되었는가
지출이 결과(outcome)를 변화시켰는가

마지막 항목은 다소 불편한 내용이지만, 그렇기에 아마도 중요할 것입니다.

만약 에이전트가 돈을 썼는데 답변이 더 나아지지 않았다면, 그것은 지능이 아닙니다. 그것은 자신감만 넘치는 작은 조달(procurement) 버그일 뿐입니다.

유료 도구는 신뢰 모델을 변화시킵니다

도구 카탈로그(tool catalogs)에는 이미 거버넌스(governance)가 필요합니다. 도구는 고객 데이터를 읽거나, 인프라를 변경하거나, 메시지를 보내거나, 풀 리퀘스트(pull request)를 생성하거나, 배포(deployment)를 시작할 수 있습니다. 결제는 여기에 또 다른 축을 추가합니다.

유료 도구는 경제적 권한(economic authority)을 가집니다. 이는 오용 사례(abuse cases)를 변화시킵니다.

프롬프트 인젝션(Prompt injection)은 지출 인젝션(spending injection)이 될 수 있습니다. 악성 페이지는 브라우저 에이전트가 쓸모없는 무언가에 대한 액세스 권한을 구매하도록 설득하려 할 수 있습니다. 침해된 MCP 서버는 응답 가격을 잘못 책정할 수 있습니다. 불안정한 엔드포인트(flaky endpoint)는 유료 재시도를 유발할 수 있습니다. 범위 설정이 잘못된 에이전트는 잘못된 고객의 예산을 사용할 수 있습니다.

이것이 이 기능을 피해야 할 이유는 아닙니다.

이것은 이 기능을 프로덕션 결제 경로(production payment path)처럼 설계해야 할 이유입니다.

에이전트가 가공되지 않은 지갑 비밀 정보(raw wallet secrets)를 보유해서는 안 됩니다. 플랫폼이 보유해야 합니다. 세션(session)은 만료되어야 합니다. 예산(budget)은 명시적이어야 합니다. 가맹점(merchant)은 가시적이어야 합니다. 결제 증빙은 트레이스(trace)와 연결되어야 합니다. 위험한 흐름은 실패 시 차단(fail closed)되어야 합니다.

알고 있습니다. 현실이 참 무례하군요.

도구 마켓플레이스는 빠르게 기묘해질 것입니다

에이전트가 도구를 발견하고 결제할 수 있게 되면, 마켓플레이스의 인센티브(incentives)가 변화합니다.

오늘날 인간은 문서를 읽고, 가격 페이지를 보고, 어쩌면 무서운 세일즈 콜을 거쳐 API를 선택합니다. 내일은 에이전트가 작업 실행 중에 HTTP 402 응답을 받고 플랫폼에서 결제가 허용된다는 메시지를 받으면 엔드포인트를 선택할 수도 있습니다.

이는 새로운 SEO 문제를 야기하는데, 타겟 오디언스는 눈과 예산이 없습니다.

서비스들은 에이전트가 발견하기 쉽도록 최적화될 것입니다. MCP 서버들은 자신들의 역량을 광고할 것입니다. 유료 엔드포인트들은 지연 시간(latency), 데이터 신선도(data freshness), 가격, 신뢰성, 그리고 에이전트에게 자신이 다음 단계에 적합하다는 확신을 주는 메타데이터를 두고 경쟁할 것입니다.

그중 일부는 좋을 것이고, 일부는 여전히 예전 인터넷과 같겠지만, 이제 팝업창에 API가 붙게 될 것입니다.

플랫폼 팀들은 유료 도구 발견 과정이 큐레이션(curation)을 필요로 할 것이라고 가정해야 합니다. 에이전트가 거대한 바자르를 자유롭게 돌아다니며 의미적으로 관련 있어 보이는 것을 무엇이든 구매할 수는 없어야 합니다. 최소한, 회사들은 승인된 제공업체, 위험 등급(risk tiers), 캐시된 결과, 공급업체 메타데이터, 그리고 터무니없는 것을 차단하는 방법이 필요할 것입니다.

당신은 지금 웃고 있겠죠. 시장에 6개월만 시간을 주세요.

every vendor adding agent-ready pricing overnight

지루한 운영 모델 (the boring operating model)

만약 제가 회사 내부에 에이전트 결제 기능을 추가한다면, 저는 지루하지만 확실한 계약부터 시작할 것입니다.

첫째, 모든 결제 세션에는 소유자(owner)가 필요합니다. 'AI 플랫폼' 같은 것이 아닙니다. 실제 제품, 팀, 비용 센터, 그리고 에스컬레이션 경로가 있어야 합니다.

둘째, 모든 유료 도구는 분류되어야 합니다: 데이터 민감도, 상인 신뢰성(merchant trust), 가격 모델, 지역 제약 조건, 캐시 정책 등이 필요합니다.

셋째, 모든 워크플로우에는 예산이 필요합니다. 단순히 최대 거래 금액만을 의미하는 것이 아닙니다. 총 세션 예산, 월별 예산, 그리고 재시도(retry) 예산까지 포함해야 합니다. 유료 호출을 재시도하는 과정에서 작은 실수가 복리 이자처럼 쌓이는 곳입니다.

넷째, 모든 트랜잭션에는 추적 기록(trace)이 필요합니다: 영수증, 에이전트의 추론 과정, 도구 호출, 상인의 응답, 그리고 최종 결과물까지 말입니다.

다섯째, 조달(procurement)과 보안은 평소보다 더 일찍 자리에 앉아야 합니다. 듣기에는 끔찍하게 들릴지 모릅니다. 하지만 대안은 나중에 '모델이 그것들이 상황적으로 유용하다고 생각했기 때문에' 에이전트 무리가 임의의 엔드포인트에서 데이터를 구매하고 있었다고 설명하는 것입니다.

그것은 회의가 아닙니다. 통제된 소각(controlled burn)입니다.

핵심 요약 (the punchline)

AgentCore 결제 시스템은 에이전트들이 어디로 향할지 이름을 붙여주기 때문에 흥미롭습니다.

에이전트들은 단순히 무료 컨텍스트를 읽고 내부 API를 호출하는 것만으로는 충분하지 않을 것입니다. 그들은 데이터를 구매하고, 기능을 임대하며(rent), 콘텐츠를 잠금 해제하고, 사용량에 따라 비용을 청구하는 서비스들을 통해 작업을 라우팅할 것입니다.

이것은 에이전트 워크플로우를 훨씬 더 유용하게 만들 수 있습니다. 동시에 거버넌스하기는 훨씬 어려워지게 할 수도 있습니다.

에이전트가 돈을 쓸 수 있는 순간, 플랫폼은 다음과 같은 재무 질문에 엔지니어링 제어로 답해야 합니다:

누가 승인했는가? 한도는 무엇이었나? 무엇이 구매되었는가? 그것이 필수적이었는가? 감사할 수 있는가? 멈출 수 있는가? 귀속시킬 수 있는가? 에이전트가 프롬프트 주입(prompt injection)을 작은 쇼핑 나들이로 만들지 않았음을 증명할 수 있는가?

그것이 진정한 제품 경계입니다.

에이전트는 소프트웨어 시스템에서 경제적 행위자(economic actors)가 되고 있습니다.

좋습니다. 그렇다면 클라우드 청구서가 스탠드업 코미디를 하기 전에, 그들에게 예산, 영수증, 정책, 그리고 성인의 감독을 제공하십시오.

참고 자료 (references)

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.

Insights