LangChain 에이전트용 AgentCore Payments 미들웨어

주요 요점

서론

에이전트 경제(agentic economy)가 임박했습니다. AI 에이전트는 무료 티어 API를 넘어 유료 서비스의 세계로 진입하고 있습니다: 프리미엄 데이터, 유료 콘텐츠, 전문 컴퓨팅 자원 등이 그것입니다. 에이전트 상거래 생태계는 빠르게 성장하고 있습니다.

에이전트가 돈을 쓸 수 있게 되면, 모든 트랜잭션 전에 인프라 계층에서 강제되는 결정론적 결제 한도(deterministic payment limits)가 필요합니다. 이는 LLM 프롬프트 내에서 이루어져서는 안 됩니다. Amazon Bedrock AgentCore Payments는 LangChain 개발자를 위해 목적에 맞게 설계된 결제 인프라로 이를 해결합니다. 에이전트 개발자로서 여러분은 AgentCore Payments 미들웨어 계층을 추가하고, 지갑(wallet)을 선택하며, 예산(budget)을 설정하면, AgentCore Payments가 나머지를 처리합니다. 모든 결제는 프로토콜에 구애받지 않는 인프라를 통해 흐릅니다.

또한 에이전트가 무엇을 구매했고 왜 그것을 선택했는지에 대한 기록도 필요하며, 여기에 LangSmith가 활용됩니다. 본 게시물은 비즈니스 사례, 아키텍처, 그리고 시작하는 방법을 설명합니다.

거래를 수행하는 에이전트

무료 콘텐츠만 소비할 수 있는 자율 에이전트는 완료할 수 있는 작업의 종류에 제한을 받습니다. 법원 기록(court filings), 실시간 시장 피드, 의료 문헌, 프리미엄 API를 포함한 최고 가치 데이터는 유료 장벽 뒤에 있습니다. 최근까지 이 데이터를 접근하려면 수동적인 API 키 관리, 서비스별 결제 통합, 또는 자율 워크플로우를 중단하고 인간에게 요청해야 했습니다. 하지만 이는 변화하고 있습니다.

x402 프로토콜은 Coinbase가 2025년 5월에 만들고 현재 Linux Foundation 산하에서 관리하는 것으로, HTTP 네이티브 마이크로페이먼트(micropayments)를 가능하게 합니다. x402를 사용하면 에이전트는 유료 엔드포인트에 접속하여 가격을 받고, 스테이블코인으로 결제하며, 콘텐츠를 받는 모든 과정을 단일 HTTP 요청-응답 주기 내에서 처리할 수 있습니다.

에이전트 거래의 특성상 경제 구조가 기존 결제 인프라와 다르게 작동합니다. 카드 처리 수수료는 API 호출을 센트 단위로 가격 책정하는 것을 경제적으로 불가능하게 만듭니다. 월간 구독은 사람이 사전에 무엇을 구매할지 결정한다고 가정합니다. x402를 통한 스테이블코인 마이크로 결제는 거래당 소수 센트로 몇 초 만에 정산되므로, 에이전트 워크로드에 필요한 호출별 가격 책정이 가능해집니다.

AgentCore Payments는 자율 에이전트를 위해 특별히 설계된 관리형 결제 기능을 제공하며, 지갑 인증부터 거래 실행, 그리고 지출 거버넌스까지 전체 수명 주기를 아우릅니다. 이를 통해 개발자는 자신의 에이전트가 '무엇을 하는지'에 집중할 수 있게 하고, '어떻게 비용을 지불하는지'에 대한 복잡성은 신경 쓰지 않아도 됩니다. LangChain 개발자들은 이제 해결하고자 하는 사용량 기반(pay-per-use) 비즈니스 문제에만 집중할 수 있으며, AgentCore Payments가 지갑 연결의 보안성 확보, 결정론적 결제 한도 강제 적용, 그리고 다양한 버전의 프로토콜 (x402 v1, v2) 또는 기타 기계 간 통신(machine-to-machine) 프로토콜 관리에 대한 복잡성을 대신 처리해 줍니다.

지출 금액에는 결정론적 한도가 필요합니다

접근성 확보는 과제의 절반에 불과합니다. 에이전트가 돈을 쓸 수 있게 되면, 다음과 같은 어려운 질문들에 대한 답이 필요합니다:

어떻게 에이전트의 지출을 통제하나요? 세션 수준의 결정론적 결제 한도가 없으면, 무한 루프나 예상치 못한 엣지 케이스가 자금을 고갈시킬 수 있습니다.
에이전트를 어떻게 자금 지원하나요? Coinbase CDP 및 Stripe (Privy) 통합을 사용하면 최종 사용자가 다양한 네트워크에서 법정화폐(fiat) 또는 USDC 스테이블코인을 통해 지갑에 자금을 충전하여 비용 효율적인 마이크로 거래를 할 수 있습니다.
제 에이전트는 어떻게 안전하게 지갑에 연결하나요? AgentCore Payments는 AgentCore Identity를 사용하여 결제 지갑의 보안 인증을 수행합니다.
어떤 프로토콜을 선택해야 하나요? 단일 프로토콜만 사용하려고 하면, 각 프로토콜마다 고유한 미묘한 차이가 있기 때문에 상당한 시간과 노력이 필요합니다.

오늘날 대부분의 팀들은 에이전트를 프로덕션 환경에 배포할 때 세 가지 방법 중 하나로 에이전트 결제 처리를 합니다. 첫째, 무료 소스(더 나쁜 데이터지만 결제가 필요 없는 경우)를 가리키게 하거나, 둘째, API별로 커스텀 결제 로직을 구축하거나(서비스당 30~50줄의 래퍼 코드), 또는 자율성을 포기합니다(에이전트가 사용자에게 유료 장벽을 노출). 이 방법들 중 어느 것도 유료 서비스 수가 수천 개로 늘어남에 따라 확장성이 확보되지 않습니다. 통합 복잡성 외에도, 개발자들은 무분별한 지출을 방지하기 위해 거버넌스 및 예산 가드레일(guardrails)을 처음부터 구축해야 하며, 결제 흐름이 요구하는 보안 및 규정 준수 요건도 충족해야 합니다.

에이전트Core Payments는 에이전트 개발자 경험의 핵심입니다. 이는 개발자가 처음부터 직접 구축하거나 특정 프로토콜에 얽매이지 않고, 지갑(wallets)에 연결하고, 여러 프로토콜에 걸쳐 결제를 오케스트레이션하며, 지출 거버넌스를 강제하는 단일 솔루션을 제공합니다.

AgentCore Payments: LangChain 미들웨어

LangChain 미들웨어는 에이전트 실행의 각 단계에서 훅(hooks)을 노출하므로, 에이전트를 변경하지 않고도 모델 호출이나 도구 호출을 가로채어 로직을 추가할 수 있습니다. 예를 들어, 법률 문서를 작성하는 법률 에이전트가 있고, 그 법원이 제출해야 하는 서류가 유료 장벽 뒤에 있다고 가정해 봅시다. 해당 도구가 유료 API를 호출하여 HTTP 402 오류를 받으면, AgentCorePaymentsMiddleware는 결제 요구사항을 감지하고, 세션 예산 한도를 강제하며, Amazon Bedrock AgentCore Payments를 통해 결제를 처리하고, 결제 자격 증명과 함께 요청을 재시도합니다. 사용자의 에이전트는 설정한 한도 내에서 필요한 데이터를 얻게 됩니다. 자세한 내용은 문서를 참고하십시오.

작동 방식

작동 방식 (Detect)
도구가 유료 API를 호출하고, 이 API가 x402 페이로드를 포함한 HTTP 402 응답을 반환합니다.
검증 (Validate)
미들웨어는 결제 금액을 세션 예산과 비교하여 확인합니다. 한도를 초과하면 요청은 거부되며 어떠한 결제도 서명되지 않습니다.
서명 (Sign)
예산 내에 있다면, 미들웨어는 AgentCore PaymentManager를 통해 결제를 서명합니다.
재시도 (Retry)
원래의 요청이 결제 증거가 첨부된 상태로 재시도됩니다. API는 콘텐츠를 반환합니다.
계속 진행 (Continue)
에이전트는 마치 API가 첫 시도에서 200을 반환한 것처럼 해당 콘텐츠를 받습니다.

설정은 구성 객체(config object)이며, 미들웨어 목록의 하나의 항목으로 추가됩니다:

config = AgentCorePaymentsConfig(
payment_manager_arn="arn:aws:bedrock-agentcore:us-east-1:...:payment-manager/pm-abc123",
user_id="user-123",
...

이것은 LangChain 에이전트가 지원하는 모든 모델 제공업체와 작동하지만, 결제 인프라 자체를 위해서는 AgentCore가 필요합니다.

적용 위치 (Where it fits)

AgentCore Payments 미들웨어는 에이전트가 통제된 예산 내에서 여러 유료 서비스에 접근해야 하는 워크로드에 적합합니다.

에이전트의 지출 감사하기 (Auditing what your agents spend)

에이전트에 비용 제어를 추가하는 것은 비용 초과를 제한하지만, 애초에 해당 거래로 이어진 에이전트의 동작에는 영향을 미치지 않습니다. 이는 여러 방식으로 나타날 수 있습니다:

• 에이전트는 예산 내에 머무르지만 무엇을 구매해야 할지에 대해 잘못 추론합니다.
• 에이전트는 허용된 전액을 두 단계에서 모두 사용한 후, 작업을 실패합니다.
• 에이전트의 유료 요청이 시스템 외부로 나가서는 안 되는 데이터를 포함하고 있습니다.
• 에이전트가 악성 도구 설명에 의해 아무도 요청하지 않은 엔드포인트로 리디렉션됩니다.

위 네 가지 상황 모두 성공적으로 완료되고, 예산 내에 머무르며, 청구서상으로 합리적으로 보일 수 있습니다. 그 이유는 블록체인 결제 원장(ledger)이 단지 '계정 X가 14:03:11에 주소 Y로 $0.02를 전송했다'는 사실만을 기록하기 때문입니다. 에이전트가 연구 작업의 세 번째 단계에 있었고, 1달러 한도가 있었으며, 도구 설명에서 법원 제출 서류(court filings)가 언급되었기 때문에 해당 엔드포인트를 선택했다는 문맥은 기록하지 않습니다. 그 문맥은 오직 에이전트 추적(agent trace)에만 존재합니다.

우리는 두 가지 측면에서 중요하다고 생각합니다: 거버넌스(governance), 즉 의도치 않은 에이전트 지출을 방지하는 것; 그리고 **감사(audit)**입니다. 이는 에이전트가 무엇을 구매했는지에 대한 영구적인 기록을 의미하며, 나중에 몇 달 뒤에도 누군가가 조회할 수 있습니다.

에이전트 지출 역시 조직 내의 다른 모든 지출과 동일한 질문을 받게 될 것입니다. 누가 승인했는가? 한도는 얼마였나? 그 한도가 유지되었음을 어떻게 아는가? 만약 이미 LangSmith에서 에이전트를 추적하고 있다면, 에이전트 결제로 이어진 각 단계를 추적할 수 있습니다. 도구 호출(tool call)이 나타나고, 402 오류를 반환하며, 사용자 본래 요청과 단계별 모델의 추론에 둘러싸여 결제 헤더가 첨부된 채로 다시 나타납니다.

간단한 기록기 미들웨어(recorder middleware)는 성공적인 결제 건에 대해 다음 세부 정보를 메타데이터로 첨부합니다: 금액(amount), 네트워크(network), 수취인(recipient), 이를 유발한 도구(tool), 그리고 청구된 세션 및 사용자입니다.

결제가 예산을 초과할 경우, AgentCore가 이를 거부합니다. 이 거절은 에이전트의 응답과 함께 추적 기록에 나타나므로, 가정하는 것이 아니라 실제로 한도가 유지되었는지 확인할 수 있습니다.

거부는 결제가 이루어지지 않았기 때문에 비용을 기록하는 것이 아니라 '발생했다'는 사실 자체를 기록합니다. 정확한 금액은 AgentCore의 로그에 남아있습니다.

실제 돈이 되기 전에 지출 테스트하기

추적(Traces)은 에이전트가 구매 요청을 처리하며 추론한 과정을 알려줍니다. 평가(Evals)는 구매 요청 뒤의 사고 과정이 의도했던 대로였는지 테스트하여, 좋은 행동을 검증하고 에이전트 실수에 대한 수정 사항을 식별할 수 있게 합니다.

**단일 단계 평가 (Single-step evals)**는 하나의 결정만을 테스트합니다. 에이전트에게 푼돈짜리 과제를 주고, 50달러를 요구하며 402 응답을 반환하게 한 뒤, 그래도 결제하는지 확인해 볼 수 있습니다.**전체 턴 평가 (Full-turn evals)**는 데이터셋 전반에 걸쳐 대화의 궤적을 점수화하여 총 지출액, 결제된 호출 횟수, 그리고 과제 완료 여부를 종합적으로 확인합니다. 에이전트가 필요 이상으로 구매를 시작하더라도 완벽하게 좋은 답변을 반환할 수 있기 때문에, 프롬프트나 도구 세트가 변경될 때마다 이 평가를 실행하는 것이 좋습니다.**온라인 평가 (Online evals)**는 LangSmith의 프로덕션 트레이스(production traces)에 대해 동일한 검사를 수행하며, 지출 임계값을 초과하거나 예상치 못한 엔드포인트로 결제되는 실행을 플래그 지정합니다.

전체 턴 예시를 살펴보겠습니다. 총 10개의 연구 과제가 있으며, 각 과제는 해당 엔드포인트가 청구하는 비용을 커버할 수 있는 예산이 책정되어 있습니다. 두 명의 평가자가 모든 실행에 점수를 매깁니다. **spend_within_budget**은 실제로 실행에서 지불된 금액과 과제의 예산을 비교합니다.

에이전트가 구매한 데이터가 주어진 질문에 답하는지 여부를 확인합니다.

relevant_data

이 실행의 경우, 지출은 10개 과제 모두 예산 내에 머물렀고, 데이터는 7개에서 관련성이 있었습니다. 나머지 3개에서는 에이전트가 질문에 답할 수 없는 응답을 위해 비용을 지불했습니다.

데이터셋, 평가자, 그리고 실험을 결합하면 다음과 같은 시야를 얻게 됩니다. 단순히 에이전트가 돈을 썼는지 여부뿐만 아니라, 그 지출이 유용한 무언가를 구매했는지를 알 수 있습니다. 프롬프트, 모델 또는 예산을 변경하고 동일한 10개 과제를 다시 실행하여, 레이턴시(latency), 토큰(tokens), 모델 비용 등을 포함하여 새로운 버전을 이 버전과 비교할 수 있습니다.

시작하기 (Getting started)

AWS 측에서 이를 구성하는 두 가지 방법이 있습니다. AgentCore Payments 기능은 Deep Agents Code, Claude Code, Kiro, 또는 Codex를 사용한 안내 대화를 통해 PaymentManager와 결제 수단을 설정해 주거나, AgentCore CLI, AWS SDK, 또는 Boto3을 사용하여 직접 할 수도 있습니다. 그런 다음 미들웨어를 설치합니다:

pip install -U

작은 세션 예산으로 미들웨어를 추가하고, LangSmith 트레이싱을 켜고, 유료 작업을 한 번 실행해 보세요. 트레이스만 보고도 '이것에 얼마가 들었고 왜 그런지'를 답변할 수 있다면 올바르게 설정된 것입니다. 거기서부터 LangSmith에서 작은 평가(eval) 데이터셋을 구축하고, 임계값을 초과하는 실행을 플래그 지정하는 온라인 규칙을 추가하세요.

시작하는 데 필요한 모든 것:

- AgentCore Payments 미들웨어 문서
- AWS의 AgentCore Payments
- LangSmith 트레이싱 및 평가가 적용된 샘플 에이전트
- AgentCore Payments 코드 샘플
- LangSmith 사용해 보기 또는 데모 받기
- AWS 마켓플레이스의 LangSmith

"에이전트는 답변을 생성하는 시스템에서 행동을 취하는 시스템으로 진화하고 있으며, 점점 더 많은 행동에는 경제적 거래가 수반될 것입니다. 이는 에이전트를 둘러싼 인프라에 개발자들이 필요로 하는 것을 변화시킵니다. 그들은 동작을 평가하고, 결정을 이해하며, 경계를 강제해야 합니다. LangSmith와 Amazon Bedrock AgentCore Payments는 이 과제의 상호 보완적인 부분을 다루며, 개발자가 관찰 가능하고 통제된 상태를 유지하면서 더 큰 자율성으로 작동할 수 있는 에이전트를 구축하는 데 도움을 줍니다."

- Harrison Chase, CEO 및 공동 창업자, LangChain