2026년 봄, AWS는 Amazon Bedrock AgentCore에 두 가지 큰 기능을 추가했습니다. 4월 22일 Managed Harness 프리뷰, 그리고 5월 7일 AgentCore Payments 프리뷰입니다. 발표 간격은 보름 정도지만 두 기능을 떨어뜨려 보면 의미가 잘 안 잡힙니다. 하나는 에이전트를 어떻게 배포할지, 다른 하나는 에이전트가 일하면서 어떻게 돈을 낼지에 관한 이야기인데, 결국 같은 그림의 두 면이기 때문입니다.

이 글은 두 발표를 묶어서 정리합니다. Managed Harness가 풀어낸 인프라 숙제, Payments가 열어낸 agentic commerce 영역, 그리고 AWS Solutions Architect 관점에서 한국 고객에게 어떻게 설명하면 좋을지를 담았습니다.

1. AgentCore의 2026년 봄 2연타

AgentCore 구성 요소 맵

2026년 5월 기준 Amazon Bedrock AgentCore의 7개 모듈. Managed Harness와 Payments가 Preview로 추가되었습니다.

AgentCore 자체는 2025년 7월 AWS Summit New York에서 프리뷰로 처음 공개되었고, 같은 해 10월에 GA되었습니다. 처음 출시될 때부터 Runtime, Gateway, Memory, Identity, Observability 같은 구성 요소를 갖춘 종합 패키지였습니다. 그런데 막상 써보면 빠진 조각이 두 개 있었습니다.

첫째, 에이전트가 실제로 일하는 작업대(harness) 자체는 여전히 사용자 책임이었습니다. 컨테이너 빌드, 파일시스템 영속화, shell 명령 실행, 세션 격리 같은 것들을 직접 챙겨야 했습니다. 둘째, 에이전트가 외부 서비스에 돈을 지불하는 경로가 없었습니다. paid API에 접근하려면 사람이 카드로 결제해두고 에이전트는 그 자격으로 호출해야 했습니다.

4월 22일 발표는 첫 번째 빈 칸을, 5월 7일 발표는 두 번째 빈 칸을 채웠습니다. AWS의 의도는 분명합니다. 에이전트 실행 인프라와 에이전트 경제 인프라를 모두 managed로 가져가서, 개발자가 비즈니스 로직 외에는 신경 쓸 일이 없도록 만드는 것입니다.

이 글에서는 두 발표를 다음 순서로 다룹니다. 먼저 왜 “harness"라는 개념이 따로 필요했는지 짚고, Managed Harness의 동작 방식을 살펴봅니다. 그다음 Payments가 도입하는 x402 프로토콜과 micropayment 시나리오를 정리합니다. 마지막으로 한국 고객에게 어떻게 적용을 권할 수 있을지 체크리스트를 정리합니다.

2. Background: 왜 “harness"라는 개념이 따로 필요했나

에이전트와 관련해서 사람들은 보통 runtime이라는 단어를 씁니다. LLM이 호출되고 도구가 실행되는 실행 환경을 가리키는 말입니다. 그런데 실제 프로덕션에 에이전트를 올려본 팀이라면 runtime만으로는 설명이 부족하다는 것을 압니다.

에이전트는 모델 추론만 하지 않습니다. 파일을 만들고, shell 명령을 돌리고, 패키지를 설치하고, 임시 디렉토리에 결과물을 떨어뜨리고, 다음 세션에서 그 결과물을 다시 읽습니다. 이런 활동이 일어나는 환경 전체를 통칭해서 harness라고 부릅니다. 안전 벨트라는 의미가 아니라, 작업장 또는 작업대에 가까운 의미입니다.

기존 AgentCore에서 에이전트를 배포하려면 이 harness를 사용자가 직접 만들어야 했습니다. ECS/Fargate 기반 컨테이너 이미지를 빌드하고, 영속 볼륨을 EFS로 붙이고, 로그를 CloudWatch로 보내고, 비밀번호를 Secrets Manager로 다루고, 세션 ID 단위로 상태를 분리하는 수십 줄짜리 코드들이 필요했습니다.

기존 AgentCore의 Runtime, Gateway, Memory, Observability, Identity는 이 작업의 일부를 추상화해 주긴 했지만 harness 자체는 managed가 아니었습니다. 즉, 에이전트가 일할 작업대는 여전히 IaC와 Dockerfile로 직접 짜야 했습니다.

이 글에서 다룰 발표는 이 작업대 전체를 AWS가 가져가겠다는 선언입니다. 컨테이너, 파일시스템, 세션, 셸, 추적까지 한 번에 묶어서 제공한다는 점이 핵심입니다.

3. Managed Harness (Preview): 3 API 호출로 시작하는 에이전트

4월 22일자 발표 (AWS ML Blog)는 Managed Harness 프리뷰만이 아니라 네 가지를 동시에 풀었습니다.

  • Managed Harness (Preview): 에이전트 실행을 위한 관리형 작업대
  • AgentCore CLI: 로컬에서 클라우드 배포까지 이어지는 명령행 도구
  • Persistent agent filesystem: 세션 간 상태를 보존하는 파일시스템
  • AgentCore skills for coding assistants: Kiro, Claude Code 같은 코딩 도구가 AgentCore를 바로 다룰 수 있게 해주는 skill 패키지

네 가지가 함께 나온 이유는, 사람이 IDE에서 코드를 짜는 흐름과 에이전트를 운영하는 흐름이 결국 같은 도구로 합쳐진다는 메시지를 주려는 것으로 읽힙니다. 코딩 어시스턴트가 AgentCore CLI를 호출하고, CLI가 Managed Harness 위에 에이전트를 올리고, 그 에이전트는 persistent filesystem에 상태를 남깁니다.

3.1 Managed Harness가 가진 특징

Forbes 리뷰에서 헤드라인으로 잡은 표현은 “3 API 호출로 에이전트 배포"였습니다. 개념상 에이전트 생성, 배포, 호출 세 단계가 각각 한 번의 API로 정리된다는 뜻입니다. 실제 SDK 호출 수는 인증과 부속 작업 때문에 더 많을 수 있지만, 추상화의 단계 수가 셋이라는 점이 본질입니다.

Managed Harness가 기존 self-managed 컨테이너 환경과 차별화되는 지점은 다음과 같습니다.

첫째, shell 명령을 직접 실행할 수 있습니다. 이때 모델 추론을 거치지 않으므로 토큰 비용이 들지 않습니다. 환경 셋업, 아티팩트 추출, 디버깅 같이 결과가 결정적인 작업은 모델에 맡길 필요 없이 deterministic 스크립트로 해결합니다. 에이전트가 pip install이나 git clone을 직접 호출하는 흐름을 떠올리면 됩니다 (공식 docs).

둘째, 모든 액션이 AgentCore Observability에 자동 trace됩니다. 에이전트가 어떤 명령을 어떤 순서로 실행했는지, 어느 도구가 호출되었는지, 어느 단계에서 실패했는지가 별도 instrumentation 없이 남습니다. 디버깅과 컴플라이언스 관점에서 중요한 차이입니다.

셋째, 관리형 인프라입니다. 컨테이너 라이프사이클, 파일시스템, 세션 분리는 AWS가 책임집니다. 사용자는 어느 모델을 쓸지, 어떤 도구를 노출할지, 어떤 시스템 프롬프트를 줄지에만 집중하면 됩니다.

AgentCore harness 공식 아키텍처

AWS 공식 문서에 실린 AgentCore harness 아키텍처. 개발자가 넘기는 선언(모델·도구·지침)과 AgentCore가 책임지는 부분(microVM, 파일시스템, 도구, Memory, Identity, Observability)이 한 장에 정리되어 있습니다. 세션마다 격리된 microVM 위에서 shell·코드 실행이 가능하고, 모든 동작이 Observability로 자동 trace되는 구조입니다. 출처: AWS Bedrock AgentCore Developer Guide — Harness.

3.2 프리뷰 리전과 가용성

Managed Harness는 처음에 4개 리전에서 프리뷰로 시작했습니다.

  • US West (Oregon)
  • US East (N. Virginia)
  • Asia Pacific (Sydney)
  • Europe (Frankfurt)

서울 리전(ap-northeast-2)은 이번 라인업에 포함되지 않았습니다. 한국 고객 입장에서는 Sydney가 지리적으로 가장 가깝지만, latency와 데이터 거버넌스 양쪽을 따져서 Oregon을 쓸지 Sydney를 쓸지 결정해야 합니다. 도쿄 리전(ap-northeast-1)도 1차 프리뷰에서는 빠져 있어, 일본/한국 고객 모두 Sydney가 사실상 첫 후보가 됩니다.

3 API 호출 흐름은 다음과 같이 단순화할 수 있습니다.

Managed Harness 3 API 호출 흐름

Create → Deploy → Invoke 3단계로 에이전트를 배포하고 호출합니다. 컨테이너·filesystem·관찰성은 자동 구성.

[1] CreateAgent      ── model + systemPrompt + tools 선언
       │
       ▼
[2] DeployAgent      ── managed harness에 컨테이너 배치
       │
       ▼
[3] InvokeAgent      ── 세션 단위 실행, persistent fs에 상태 저장

직접 실행한 결과는 아니라 AWS 블로그와 docs를 참고한 의사 흐름이지만, 추상화 수준 자체가 기존 ECS 기반 배포와 비교가 안 될 정도로 단순해진 것은 분명합니다.

4. Harness를 쓰는 실제 흐름: AgentCore CLI 기반

Managed Harness만 단독으로 쓰는 경우는 많지 않을 것입니다. 함께 발표된 AgentCore CLI와 persistent filesystem이 묶여야 진짜 가치가 나옵니다.

CLI는 로컬에서 시작해서 클라우드 배포로 이어지는 흐름을 그대로 명령행에 매핑합니다. 로컬에서 에이전트를 실행해 보고, 같은 정의를 클라우드에 그대로 올리고, 운영 중에 로그와 메트릭을 확인하는 사이클이 한 도구 안에서 끝납니다. 별도 IaC 템플릿을 작성하지 않아도 된다는 점이 작은 팀에는 특히 도움이 됩니다.

persistent filesystem은 stateless container의 한계를 푸는 장치입니다. 기존에는 세션 간에 상태를 유지하려면 S3, DynamoDB, EFS 같은 외부 스토리지를 직접 붙여야 했습니다. 결과적으로 “어디에 무엇을 저장할지"가 에이전트 설계의 중요한 의사결정이 됐습니다. Managed Harness에서는 이 결정 일부를 플랫폼에 위임할 수 있습니다. 에이전트가 임시 작업 결과물을 그냥 디스크에 쓰면 다음 세션에서도 같은 위치에서 읽을 수 있다는 보장이 생깁니다.

AgentCore skills for coding assistants는 다른 차원의 도구입니다. 이건 코딩 어시스턴트가 AgentCore의 사용법을 미리 학습된 형태로 받아쓰게 만드는 패키지입니다. Kiro, Claude Code 같은 도구가 “AgentCore에 에이전트를 배포해줘"라는 자연어 요청을 받았을 때, 어떤 API를 어떤 순서로 호출해야 하는지를 이미 알고 있다는 의미입니다. 이 글을 쓰는 환경에도 bedrock-agentcore, bedrock-agentcore-deployment, bedrock-agentcore-evaluations 같은 skill이 설치되어 있어, 에이전트 빌드 작업을 자연어로 시작해도 어시스턴트가 정확한 API 호출 시퀀스를 만들어 줍니다.

세 도구를 합치면 그림이 분명해집니다. 코딩 어시스턴트가 CLI를 호출하고, CLI가 Managed Harness에 에이전트를 올리고, 그 에이전트는 persistent filesystem에 상태를 남깁니다. 인프라 코드를 별도로 짜는 단계가 사라집니다.

5. AgentCore Payments (Preview): 에이전트가 스스로 결제한다

Managed Harness 발표로부터 보름 뒤인 5월 7일, AWS는 AgentCore Payments 프리뷰를 공개했습니다. 파트너는 Coinbase와 Stripe(Stripe 산하 Privy)이고, 처음부터 stablecoin과 fiat을 모두 다룬다는 점이 인상적입니다.

5.1 왜 지금 결제인가

API와 콘텐츠 시장이 pay-per-use로 빠르게 전환하고 있다는 것이 배경 중 하나입니다. 미디어 회사들은 AI 크롤러로부터 콘텐츠를 보호하기 위해 token 단위 또는 request 단위 과금을 도입하고 있고, MCP 서버 운영자들도 free tier 위에 paid feature를 얹는 흐름이 생기고 있습니다. 가격이 보통 1달러 미만, 많은 경우 센트 단위라는 점이 특이합니다.

이런 micropayment 시장에서 에이전트가 결제까지 책임지려면 세 가지가 풀려야 합니다. 첫째, 어떤 wallet을 쓸지. 둘째, 결제 권한을 누가 어떻게 부여할지. 셋째, 비정상 지출을 어떻게 막을지. 기존 방식으로 풀려면 서비스마다 billing 관계를 맺고, credential을 관리하고, spending governance를 직접 짜야 합니다. 엔지니어링 비용이 보통 수개월 단위입니다.

5.2 AgentCore Payments가 제공하는 것

AgentCore Payments는 위 세 가지를 모두 managed로 처리합니다.

  • Wallet authentication: 에이전트를 Coinbase wallet 또는 Stripe Privy wallet에 연결합니다. 사용자가 이 wallet 접근을 explicit하게 authorize한 뒤에야 에이전트가 결제를 실행할 수 있습니다.
  • Transaction execution: 결제 자체는 wallet 백엔드(Coinbase, Privy)가 수행합니다. AgentCore는 인증 토큰을 다루는 orchestration 레이어 역할입니다.
  • Spending governance: per-session spending limit을 둘 수 있습니다. 한 세션 안에서 특정 한도를 넘기면 더 이상 지출하지 못하도록 강제됩니다.
  • Observability 통합: 결제 이벤트가 기존 AgentCore 로그/메트릭/트레이스에 자동으로 들어옵니다. 비정상 지출 감지나 감사 추적을 별도 시스템 없이 수행할 수 있습니다.

wallet 연결 옵션은 두 가지입니다. Coinbase 지갑 또는 Stripe Privy 지갑 중에서 골라 붙입니다. 두 옵션 모두 end user가 stablecoin 또는 debit card 기반 fiat으로 지갑을 충전할 수 있다고 AWS 블로그는 밝히고 있습니다. 단, 첫 프리뷰의 실행 흐름 자체는 x402 + USDC 기반 stablecoin micropayment에 초점이 맞춰져 있고, 범용 fiat 결제는 AWS가 Stripe와 함께 micropayment 너머로 확장하는 단계에서 본격화될 것이라고 명시돼 있습니다 (AWS ML Blog, Stripe newsroom). 즉, wallet 인프라는 Coinbase와 Privy를 선택적으로 쓰고, 지금 당장 돌아가는 micropayment 경로는 stablecoin 쪽이라고 보면 정리가 쉽습니다.

5.3 사용자 플로우

공식 블로그가 묘사한 시나리오를 따라가면 다음과 같은 흐름이 됩니다.

  1. 개발자가 에이전트 정의에 wallet을 연결합니다 (Coinbase 또는 Privy).
  2. 사용자가 앱 UI에서 그 wallet 접근을 explicit하게 authorize합니다.
  3. 사용자가 per-session spending limit을 설정합니다. 예를 들어 한 세션에서 5달러 이상 쓰지 못하게 잠급니다.
  4. 에이전트가 작업을 진행하다가 paid API/MCP 서버/웹 콘텐츠를 만나면 HTTP 402 “Payment Required” 응답을 받습니다.
  5. AgentCore가 wallet 인증을 수행하고 payment를 실행한 다음, proof를 첨부해 다시 요청을 보냅니다. 콘텐츠가 반환되고 에이전트는 작업을 이어갑니다. 이 모든 단계가 에이전트의 execution loop 안에서 끝납니다.
  6. 콘솔에서 어떤 결제가 언제 어떤 리소스에 대해 일어났는지 trace로 확인할 수 있습니다.

첫 프리뷰가 겨냥하는 사용 사례는 명확합니다. API, MCP 서버, 웹 콘텐츠, 다른 에이전트에 대한 micropayment입니다. 보통 1달러 미만이고 센트 단위인 경우가 많다고 명시되어 있습니다. 이 가격대는 사람이 매번 결제 페이지를 거쳐야 한다면 UX 자체가 성립하지 않는 영역입니다. 에이전트가 자동으로 처리해야만 의미가 있는 시장입니다.

에이전트가 결제 가능한 리소스를 스스로 찾을 수 있도록, Coinbase x402 Bazaar MCP 서버가 AgentCore Gateway를 통해 함께 제공됩니다. Bazaar에는 10,000개 이상의 x402 엔드포인트가 인덱싱되어 있어, 에이전트가 작업 중 필요한 paid 서비스를 검색하고 발견해 결제까지 자율적으로 처리하는 경로가 열립니다 (AWS What’s New). 개발자가 paid 통합을 하드코딩하지 않아도 된다는 뜻입니다.

레퍼런스로 언급된 고객은 Cox Automotive, Thomson Reuters, PGA TOUR (기존 AgentCore 사용자), 그리고 검토 중인 Warner Bros. Discovery입니다 (Coindesk 보도). 미디어, 자동차, 스포츠 콘텐츠 같이 콘텐츠 라이선싱과 micropayment가 잘 맞는 산업이 먼저 들어왔다는 점이 눈에 띕니다.

6. x402 프로토콜과 agentic commerce 프로토콜 지형

AgentCore Payments가 첫 프리뷰에서 채택한 결제 프로토콜은 x402입니다. 이름이 낯설게 들리지만 사실 인터넷 프로토콜 표준의 잊혀진 한 줄을 부활시킨 것입니다.

6.1 HTTP 402가 다시 깨어나다

HTTP 1.1 스펙에는 1996년부터 HTTP 402 “Payment Required”라는 상태 코드가 정의되어 있었습니다. 그런데 30년 가까이 거의 쓰이지 않았습니다. 결제 흐름이 항상 별도 페이지와 별도 세션으로 빠져나갔기 때문입니다. 결제는 HTTP 위에서 일어나는 별도 워크플로우였고, HTTP 자체에는 결제 의미를 끼워 넣을 자리가 없었습니다.

stablecoin과 wallet 추상화가 생기면서 상황이 바뀌었습니다. 결제가 토큰 한 번의 서명으로 끝나는 시점이 오자, HTTP 응답 안에 결제 요구를 직접 박아넣는 게 의미를 갖기 시작했습니다. x402는 그 흐름을 표준화한 HTTP-native payment 규약입니다.

작동 원리는 단순합니다. 서버가 paid 리소스에 대해 402 응답을 보내고, 응답 헤더 또는 본문에 어떤 wallet/체인/금액이 필요한지 명시합니다. 클라이언트(에이전트)는 그 정보를 읽어 wallet에 서명을 요청하고, 결제 proof를 첨부해 같은 요청을 다시 보냅니다. 별도 결제 UI나 redirect가 없습니다. 모든 것이 HTTP 응답-요청 사이클 안에서 끝납니다.

이 디자인은 에이전트와 잘 맞습니다. 사람이 결제 페이지에서 카드를 입력하는 단계가 자체가 빠져 있기 때문입니다. 사람이 한 번 wallet 접근을 authorize해 두면, 에이전트는 이후의 micropayment를 stateless하게 자동 처리할 수 있습니다.

x402 프로토콜 공식 플로우

Coinbase CDP 문서에 실린 x402 프로토콜 공식 플로우. Client가 요청을 보내면 Server가 402 + PAYMENT-REQUIRED 헤더로 응답하고, Client가 PAYMENT-SIGNATURE를 붙여 재요청하면 Facilitator가 검증·온체인 결제를 수행한 뒤 Server가 리소스를 돌려주는 11단계가 한 번의 HTTP 왕복으로 포장됩니다. 출처: Coinbase CDP Docs — How x402 Works.

6.2 다른 프로토콜과의 관계

AWS 블로그는 x402 외에 ACP, MPP, AP2 같은 다른 agentic commerce 프로토콜도 언급합니다. 각 프로토콜은 강조점이 조금씩 다릅니다. ACP는 에이전트 간 협상에 가까운 그림을 그리고, MPP는 multiparty payment에 초점이 있고, AP2는 더 일반화된 결제-자율성 인터페이스를 지향합니다. 모두 아직 표준화 초기 단계이고 채택률은 낮습니다.

AWS의 공식 입장은 framework-agnostic, protocol-agnostic입니다. 첫 프리뷰는 x402로 시작하지만 다른 프로토콜도 로드맵에 들어 있습니다. 여러 프로토콜이 공존하는 시기를 가정하고 wallet과 governance 레이어만 안정적으로 잡아두겠다는 전략으로 읽힙니다.

7. 실무 시사점: AWS SA 관점의 적용 가이드

Agentic Commerce 레퍼런스 아키텍처

x402 기반 agentic commerce 플로우. 에이전트가 execution loop 내부에서 HTTP 402를 만나 즉시 결제합니다.

위 두 발표를 한국 고객에게 어떻게 설명하면 좋을지를 세 부분으로 나눠 정리합니다. Managed Harness 도입 판단, Payments 도입 체크리스트, 그리고 프리뷰 단계의 한계입니다.

7.1 Managed Harness 도입 판단

먼저 언제 Managed로 가야 하는가입니다.

  • 운영해야 하는 에이전트 개수가 많아지고 있을 때
  • filesystem과 세션 상태 관리가 부담스러워 외부 스토리지에 매번 코드를 짜고 있을 때
  • CLI나 CI 파이프라인 기반으로 빠른 배포가 필요할 때
  • 코딩 어시스턴트(Kiro, Claude Code 등)를 통해 에이전트를 자연어로 빌드하는 워크플로우를 시도하고 있을 때

반대로 self-managed가 더 맞는 경우도 있습니다.

  • 컨테이너 환경이 고도로 커스텀되어 있어 base image나 시스템 콜에 특수 요건이 있는 경우
  • VPC 내부 서비스 메시 구성, PrivateLink, security group 등 세밀한 네트워크 제어가 필요한 경우
  • 특정 컴플라이언스 요건(예: 한국 금융권 망분리, 의료 데이터)으로 인해 managed 추상화 안에 들어갈 수 없는 경우
  • 프리뷰 4개 리전 외에서 운영해야 하는 경우 (현재 서울/도쿄 리전 미지원)

기존 Agents for Bedrock과의 관계도 짚을 만합니다. Agents for Bedrock은 AWS 전용 패러다임에 가깝고, AgentCore는 LangGraph, CrewAI, Strands 같은 오픈소스 프레임워크를 모두 받아들이는 더 범용적인 플랫폼입니다. 두 제품이 일부 겹치지만 AgentCore 쪽이 점차 중심으로 이동하고 있습니다. 신규 프로젝트라면 AgentCore를 기본 후보로 두고, 기존 Agents for Bedrock 자산이 있다면 단계적 마이그레이션을 검토하는 게 자연스럽습니다.

7.2 AgentCore Payments 도입 체크리스트

Payments는 기술 도입 외에도 회사 안의 여러 부서가 같이 검토해야 하는 주제입니다.

거버넌스 설계

per-session spending limit만으로는 부족할 가능성이 높습니다. 한 사용자가 여러 세션을 띄울 수 있고, 한 에이전트가 잘못된 API를 반복 호출해 의도치 않은 비용을 만들 수도 있습니다. 다음과 같은 다층 제어를 같이 설계하는 것이 안전합니다.

  • per-user per-day 한도
  • per-resource 화이트리스트 (어떤 도메인/엔드포인트에만 결제 가능)
  • 비정상 지출 패턴에 대한 anomaly detection 알람
  • 결제 이벤트에 대한 감사 로그 보존 정책

reward hacking과 비슷한 시나리오, 즉 에이전트가 비용 지표를 무시하고 paid 리소스를 과도하게 호출하는 경우도 가정해 두어야 합니다.

관측성 통합

결제 이벤트가 AgentCore Observability에 자동으로 들어오는 점을 활용해서, CloudWatch 메트릭과 알람, 그리고 SIEM 연동을 같이 설계하는 것이 권장됩니다. 비정상 지출 패턴 감지에는 다음 같은 신호를 트리거로 잡을 수 있습니다.

  • 단위 시간당 결제 횟수가 평소의 N배를 초과
  • 처음 보는 도메인에 대한 결제
  • 한도 근접 또는 초과 직전 상태가 일정 시간 지속
  • 같은 리소스에 대한 반복 결제 (캐싱 부재 의심)

사용자 UX

사용자가 wallet 접근을 authorize하는 단계가 새로 생깁니다. 앱 UI에서 이 단계를 어떻게 자연스럽게 보여줄지, 한도 초과 상황에서 에이전트가 어떻게 행동할지를 사전에 정해야 합니다. 예를 들어 한도 초과 시 사용자에게 재확인을 요청할지, 아니면 사용 가능한 무료 fallback 경로로 우회할지를 결정해 두는 것이 좋습니다. 이 결정은 product team과 함께 잡아야 하는 영역입니다.

7.3 Preview 상태의 한계

마지막으로 두 기능 모두 프리뷰라는 점을 분명히 짚어두는 것이 좋습니다.

  • 리전 제약: Managed Harness는 4개 리전(Oregon, N. Virginia, Sydney, Frankfurt)에서만 시작했습니다. 서울과 도쿄 리전은 빠져 있습니다. 한국 고객은 Sydney를 1차 후보로 검토하되, 데이터 거버넌스가 엄격한 워크로드는 GA를 기다리는 편이 안전합니다.
  • 프로토콜 제약: Payments는 x402 프로토콜만 지원합니다. ACP, MPP, AP2는 로드맵에 있지만 일정은 공개되지 않았습니다. 특정 프로토콜에 락인되어 있는 파트너 생태계를 가진 고객이라면 미리 확인해야 합니다.
  • SLA와 계약: 프리뷰 단계에서는 GA 수준의 SLA, 가격, 리전 가용성 보장이 없습니다. 엔터프라이즈 계약과 운영 SLA를 강하게 묶어야 하는 워크로드는 GA 후 도입이 합리적입니다.

한국 고객 관점에서 정리하면, 두 기능 모두 즉시 프로덕션에 올리기보다는 다음 6~12개월 동안 PoC와 거버넌스 모델 설계에 쓰는 것이 좋습니다. 특히 Payments는 기술 검증보다 법무/회계/보안 라인 사전 정렬이 더 시간이 걸리는 영역입니다. PoC 단계에서 이 정렬을 미리 끝내두는 팀이 GA 시점에 빠르게 움직일 수 있습니다.

마무리

2026년 봄의 두 발표는 묶어서 보면 “에이전트 실행 인프라"와 “에이전트 경제 인프라"를 동시에 managed로 내놓은 사건에 가깝습니다. 한쪽은 에이전트가 어떻게 일할지를, 다른 한쪽은 그 일이 비용으로 정산되는 경로를 정리합니다. AgentCore 자체가 처음 출시된 2025년 여름에는 두 영역 모두 사용자 책임이었다는 점을 떠올리면 진척 속도가 가볍지 않습니다.

국내 시장에는 agent payments라는 개념이 아직 낯선 편입니다. SaaS 가격 모델이 여전히 월 단위 구독에 묶여 있는 곳이 많기 때문입니다. 그러나 x402 기반 micropayment는 콘텐츠 라이선싱, API 시장, MCP 서버 운영자 사이에서 점점 더 많이 시도될 것이고, 1~2년 안에 한국 SaaS 가격 모델에도 흔적을 남길 가능성이 큽니다. AWS Solutions Architect 입장에서는 고객이 “왜 우리 에이전트에 결제 기능이 필요한가"라는 질문부터 함께 설계해야 하는 새로운 대화 토픽이 하나 생긴 셈입니다.

Managed Harness는 인프라 plumbing을 깎고, Payments는 결제 plumbing을 깎습니다. 둘 다 본질은 같습니다. 에이전트 개발자가 비즈니스 로직 외의 일에 시간을 적게 쓰도록 만든다는 것입니다. 프리뷰 동안에는 PoC와 거버넌스 설계, GA 이후에는 본격적인 적용으로 나누어 접근하는 것을 권합니다.

References

  1. AWS Machine Learning Blog. “Get to your first working agent in minutes — Announcing new features in Amazon Bedrock AgentCore.” AWS Blog, April 22, 2026. Link
  2. AWS Machine Learning Blog. “Agents that transact: Introducing Amazon Bedrock AgentCore Payments built with Coinbase and Stripe.” AWS Blog, May 7, 2026. Link
  3. AWS What’s New. “Amazon Bedrock AgentCore — new features to build agents faster.” AWS What’s New, April 22, 2026. Link
  4. AWS What’s New. “Amazon Bedrock AgentCore Payments now available in preview.” AWS What’s New, April 2026. Link
  5. AWS Documentation. “AgentCore Harness — Developer Guide.” AWS Docs. Link
  6. Stripe Newsroom. “AWS, Stripe, and Privy collaborate on AgentCore Payments.” Stripe Newsroom, May 7, 2026. Link
  7. Janakiram MSV. “AWS Cuts AI Agent Setup To 3 API Calls In AgentCore Update.” Forbes, April 26, 2026. Link
  8. CoinDesk. “Amazon Rolls Out AI Agent Stablecoin Payments Platform With Coinbase and Stripe.” CoinDesk, May 7, 2026. Link
  9. Coinbase Developer Platform Documentation. “How x402 Works.” CDP Docs. Link
  10. Coinbase. “Introducing x402 — a new standard for internet-native payments.” Coinbase Developer Platform, May 6, 2025. Link