연구 에이전트가 유용한 데이터셋을 찾아도 마지막 단계인 결제에서 멈출 수 있다. AWS와 Anchor Browser는 에이전트 내부에 범용 지갑을 넣지 않고 이 공백을 메우려 한다. 10월 13일 발표한 통합에서는 관리형 브라우저가 x402 결제 요청을 인식하고 Amazon Bedrock AgentCore Payments로 승인을 받은 뒤 원래 요청을 한 번 다시 보낸다.

핵심은 금융 권한의 분리다. 무엇을 요청할지는 에이전트가 선택하지만 설정된 결제 수단과 세션 예산으로 지출을 허용할지는 별도 서비스가 판단한다. 결제가 성공했다는 사실은 자료가 구매할 만했다거나 연구 결과가 정확하다는 증거가 아니다.

결제 요청이 브라우저 작업이 된다

Anchor Browser는 이미 Playwright, Puppeteer, Chrome DevTools Protocol 작업의 인증 상태, 탐색, 네트워크 이벤트와 상호작용 녹화를 관리한다. 개발자는 세션에 x402: true를 붙여 결제 기능을 활성화한다. 기본값이 false인 이유는 이를 켜면 모의 거래가 아니라 설정된 결제 수단에서 실제 지출을 승인하기 때문이다.

AWS 통합 절차에서 판매자는 먼저 금액, 결제 방식, 네트워크, 수신 주소를 담은 HTTP 402 Payment Required를 반환한다. AgentCore는 요청 데이터와 결제 수단을 검증하고 남은 예산을 확인한다. 승인되면 지갑 제공업체가 결제 증명에 서명한다. 브라우저는 이를 첨부해 원래 요청을 한 번 재전송하고 판매자는 검증과 정산 후 리소스를 제공한다.

x402 버전 2는 PAYMENT-SIGNATURE, 버전 1은 X-PAYMENT 헤더를 사용한다. 에이전트가 직접 헤더를 만들거나 지갑 SDK를 실행하거나 결제 재시도 로직을 관리하지 않는다. 페이지 탐색뿐 아니라 fetch와 XMLHttpRequest도 지원하며 브라우저 문맥의 유료 POST·PUT 호출도 포함한다.

형식이 잘못된 요청, 지원하지 않는 네트워크, 예산 소진은 원래 402를 일반 HTTP 오류로 남긴다. 한 번만 재시도하므로 단일 요청의 무한 자동 결제 순환은 막는다. 그러나 계획 에이전트가 서로 다른 요청을 계속 생성하는 것은 막지 못하므로 상위 통제가 필요하다.

AWS는 이 기능이 AWS Marketplace의 Anchor Browser에서 제공되며 Generative AI Innovation Center Partner Agent Factory와 개발됐다고 설명한다. 배포 가능한 통합이라는 의미이지 광범위한 판매자 채택이나 측정된 운영 신뢰성을 입증하는 것은 아니다.

지출 지시와 통제 계층은 다르다

AgentCore 구조는 여러 관리형 리소스로 책임을 나눈다. Payment Manager는 AWS 계정 경계를 정한다. PaymentConnector는 외부 지갑 인프라와 연결한다. PaymentCredentialProvider는 AgentCore Identity를 통해 제공업체 자격 증명을 처리하며 PaymentInstrument는 지갑 주소를 식별한다.

PaymentSession은 결제 수단을 특정 상호작용에 연결하면서 최대 금액, 통화, 만료 시각을 지정한다. 한도를 넘거나 세션이 만료되면 결제는 거부된다. 지갑 제공업체로 Coinbase Developer Platform과 Stripe Privy가 제시된다. 지갑 비밀과 승인 키는 에이전트 실행 환경이 아니라 관리형 신원·비밀 관리 인프라에 남는다.

이는 영구적인 계정 통제권 없이 제한된 작업을 허용하는 단기 클라우드 권한과 비슷하다. 프롬프트에 '돈을 신중히 쓰라'고 적는 것은 동등한 안전장치가 아니다. 같은 실행 프로세스가 임의 송금에 서명할 수 있다면 프롬프트 주입, 노출된 환경 변수, 침해된 의존성, 도구 오용의 위험이 커진다.

격리가 완전한 면역을 뜻하지는 않는다. 침해된 브라우저는 허용된 세션 안의 요청을 조작할 수 있다. 제공업체 비밀에 대한 IAM 권한이 지나치게 넓으면 예산과 감사 경로를 통째로 우회할 수도 있다. 역할, 커넥터 권한, 비밀 접근과 보관 기간도 보안 경계의 일부다.

CloudWatch에는 결제 시도, 승인, 거부, 정산이 기록된다. 브라우저 녹화와 네트워크 이력은 비용을 유발한 탐색 및 작업과 결제를 연결한다. 여러 구매를 수행하는 장시간 에이전트에서는 단독 거래 기록보다 이 결합된 증거가 더 유용하다.

건별 접근은 새로운 구매 문제를 만든다

x402는 페이지, 파일, API 또는 MCP 도구 접근을 요청·결제 요구·증명의 교환으로 바꾼다. 선택적인 중개 서비스가 거래를 검증하고 전파한다. 계정 생성이나 구독 대신 특정 자료 한 건을 구매할 수 있다.

실행 도중 알지 못했던 유료 서비스를 발견하는 동적 탐색에 적합하다. 연구 작업이 라이선스 시장 데이터, 공시 분석, 기업 기록을 차례로 구매할 수 있다. 각각 합리적인 구매라도 중복 조회나 가치가 낮은 추가 자료가 전체 예산을 소진할 수 있다.

예산 상한은 최대 노출을 줄일 뿐 한도 안의 낭비를 막지는 않는다. 정상적인 결제 요구는 정확성, 최신성, 공정한 가격이나 필요성을 입증하지 않는다. 판매자 허용 목록, 건별 한도, 품목 규칙, 반복 결제 탐지와 사람의 승인 기준을 세션 한도에 더해야 한다.

구매한 증거에도 출처, 보관, 접근 통제가 필요하다. 이미 라이선스를 받은 결과를 캐시하면 이중 지출을 줄일 수 있지만 재사용은 제공업체 약관을 지켜야 한다. 거래 계층이 정보 관리 문제까지 해결하지는 않는다.

AWS는 Anchor가 제삼자 x402 비용을 브라우저 청구와 합쳐 작업마다 별도 암호자산 잔액을 관리할 필요를 줄인다고 설명한다. 이는 Anchor 서비스 계약이지 x402의 보편적인 성질이 아니다. 영수증, 세금, 회계, 환불 처리는 여전히 확인해야 한다. 온체인 정산은 취소 및 분쟁에서 카드와 다른 특성을 가질 수 있다.

하나의 범용 계산대가 아닌 여러 프로토콜

시장은 여러 경로를 택한다. Stripe·Tempo의 Machine Payments Protocol은 HTTP 인증 요구를 사용하며 판매자 보고, 환불, 부정 거래 통제와 기존 잔액으로의 정산을 강조한다. Google AP2는 60개 넘는 참여 조직과 발표됐고 사용자, 에이전트, 판매자, 결제 제공업체 사이의 위임 관계를 다룬다.

이 설계들은 겹치지만 서로 대체할 수는 없다. x402는 HTTP 리소스와 종량제 API에 직접 대응하고 AP2는 여러 수단을 쓰는 더 넓은 위임 구매를 다룬다. 상거래 프로토콜은 상품 목록, 결제, 주문 이행과 판매자 관계까지 포함한다. AgentCore가 x402와 MPP를 지원한다는 점은 표준의 공존을 인정하는 것이다.

여러 프로토콜을 지원한다고 보호 수준이 같아지는 것은 아니다. 스테이블코인과 토큰화 카드는 정산, 개인정보, 사기, 규제 영향이 다르다. 기업에는 각 결제를 기술적으로 연결하는 어댑터뿐 아니라 모든 경로에 일관된 정책이 필요하다.

관리형 설계는 의존성도 추가한다. Anchor Browser, AgentCore, 지갑 제공업체, 판매자와 정산 네트워크가 협력해야 한다. AWS 고유의 Payment Manager 리소스, Identity, IAM, CloudWatch는 이전 시 정책과 관측 체계를 다시 구축하게 만들 수 있다.

부족한 것은 아키텍처보다 운영 증거다

AWS 문서는 구조를 설명하지만 결제 성공률이나 판매자별 지연의 비교 벤치마크를 공개하지 않는다. Cloudflare·Coinbase 지원과 선별된 Bazaar 탐색 연결도 유용한 리소스가 얼마나 있는지 입증하지 못한다. 디렉터리 크기보다 엔드포인트 품질이 중요하다.

실제 브라우징에는 인증, 리디렉션, JavaScript, 네트워크 장애와 지연된 정산이 포함된다. 좁은 평가에서는 승인된 유료 API 하나와 짧은 세션을 사용하고 브라우저 증거, 결제 로그, 출력 품질과 총비용을 대조해야 한다. 성공 결제뿐 아니라 재구매, 거부, 지연과 수동 개입도 결과에 넣어야 한다.

알려진 판매자의 저액 요청은 사전 승인이 적절할 수 있다. 새 판매자, 이례적 금액, 계약 의무, 개인정보나 규제 데이터는 프롬프트 밖에서 강제되는 명시적 검토가 필요할 수 있다. 통합의 기여는 의도와 금융 권한을 분리하는 데 있다. 자율 작업의 개선 여부는 무엇을 샀고 어떤 증거를 받았으며 실패를 어떻게 처리하는지에 달려 있다.

작업 맥락을 정리하고 보존하는 데 관한 관련 읽을거리: 기술 문서 지식 기반 ; AI 지원 주간 보고 흐름.

관련 글
출처

도구 디렉터리 둘러보기 →