AWS가 자사 클라우드 밖에서 실행되는 AI 에이전트의 텔레메트리를 Amazon Bedrock AgentCore Observability로 전송하는 기술 안내를 공개했다. 이 접근 방식은 온프레미스 환경, 개발자용 로컬 머신, Google Cloud Platform, Microsoft Azure를 포괄하며, 에이전트 워크로드 자체를 AWS로 옮기지 않고도 AWS 대시보드를 활용할 수 있게 해준다.

이 가이드가 중요한 이유는 AgentCore Observability가 AWS AgentCore 런타임 외부에 배포된 에이전트를 기본적으로 모니터링하지 않기 때문이다. AWS가 문서화한 우회 방법은 AWS Distro for OpenTelemetry(ADOT), Amazon CloudWatch, AWS Identity and Access Management(IAM) 자격 증명을 결합해 외부 환경에서 트레이스, 메트릭, 로그를 수집한다.

AWS 호스팅 런타임을 넘어 AgentCore 확장하기

Amazon Bedrock AgentCore는 AWS가 다양한 프레임워크와 모델로 구축된 에이전트를 생성, 연결, 최적화하기 위한 플랫폼으로 제시한다. 이 관측성 기능은 에이전트 실행, 도구 호출, 모델 활동, 토큰 사용량 같은 세부 정보를 드러내도록 설계됐다.

AWS Machine Learning Blog에 따르면, 기본 지원은 AWS Cloud의 AgentCore 런타임에서 실행되는 에이전트에 초점을 맞춘다. Amazon Elastic Kubernetes Service, Amazon Elastic Container Service, AWS Lambda에 배포된 에이전트는 AWS 네이티브 통합 패턴을 사용할 수 있지만, AWS 밖의 워크로드는 추가 설정이 필요하다.

새로 문서화된 구성은 해당 워크로드를 옮기지 않는다. 대신 ADOT가 에이전트 애플리케이션과 함께 실행되며 지원되는 프레임워크와 모델 호출을 계측한다. 생성된 텔레메트리는 Amazon CloudWatch OpenTelemetry Protocol 엔드포인트로 내보내지고, 여기에서 AgentCore Observability 대시보드로 연결될 수 있다.

AWS의 예시는 Strands Agents, LangGraph, CrewAI로 구축된 에이전트를 참조한다. 이는 관측성을 하나의 애플리케이션 스택에 묶인 기능으로 보기보다, 서로 다른 에이전트 프레임워크를 표준화하는 팀에 이 가이드를 유용하게 만든다.

크로스클라우드 텔레메트리 파이프라인 작동 방식

구성은 세 가지 주요 부분으로 이뤄진다. 첫째, ADOT가 애플리케이션에 자동 계측을 제공한다. AWS는 OpenTelemetry 배포판이 Amazon Bedrock 호출을 위해 boto3를 패치하고, Strands 프레임워크를 계측해 추론 관련 span과 생성형 AI 시맨틱 컨벤션 데이터를 내보낼 수 있다고 말한다.

둘째, 외부 환경에는 AWS 서비스로 텔레메트리를 보낼 권한이 있는 IAM 자격 증명이 필요하다. 가이드에 나열된 권한에는 CloudWatch 메트릭, 로그 생성 및 수집, AWS X-Ray 트레이스 작업에 대한 액세스가 포함된다. 또한 설정에는 AWS 엔드포인트로의 아웃바운드 HTTPS 연결이 필요하다.

셋째, 환경 변수가 OpenTelemetry 라우팅 및 인증 설정을 정의한다. 텔레메트리는 CloudWatch 엔드포인트로 전송되기 전에 AWS Signature Version 4, 즉 SigV4로 인증된다. 그런 다음 CloudWatch가 수집 및 저장 계층을 제공하고, AgentCore Observability는 에이전트 활동에 맞춘 대시보드를 제공한다.

AWS는 또한 계정당 한 번 활성화해야 하는 사전 요구사항으로 CloudWatch Transaction Search를 언급한다. 가이드의 예시에서는 Amazon Bedrock 모델 액세스와 Claude Haiku를 사용하지만, 핵심 절차는 새 모델을 도입하는 것이 아니라 외부 에이전트의 텔레메트리를 내보내는 데 있다.

근거, 주장 및 남은 한계

이 개발의 주요 근거는 AWS 자체의 기술 블로그 게시물과 설정 지침이다. 제공된 보도 묶음의 별도 AWS 항목에는 추가 기사 본문, 고객 증언, 독립 검증이 없다. 따라서 대시보드의 가치, 프레임워크 지원 범위, 운영상의 이점에 대한 주장은 독립적으로 측정된 결과가 아니라 벤더가 제시한 안내로 봐야 한다.

AWS는 이 텔레메트리가 추론 체인, 도구 호출, 모델 출력을 보여준다고 설명한다. AWS는 이러한 가시성이 팀이 환각, 유해하거나 주제에서 벗어난 응답을 식별하고, 토큰 소비를 추적하며, 동작을 감사하는 데 도움이 될 수 있다고 말한다. 이는 그럴듯한 관측성 활용 사례지만, 게시물에는 탐지 정확도, 지연 오버헤드, 비용 절감, 또는 이 구성을 사용하는 배포 수를 보여주는 벤치마크 결과가 없다.

또한 발표에는 중요한 경계가 있다. 이 접근 방식은 크로스플랫폼 모니터링 경로를 만들지만, AgentCore Observability를 완전히 로컬이거나 클라우드 중립적인 서비스로 만들지는 않는다. 외부 에이전트는 여전히 텔레메트리를 AWS 서비스로 전송하며, 팀은 관련 IAM 권한, 네트워크 액세스, CloudWatch 구성, 데이터 처리 정책을 관리해야 한다.

이 차이는 데이터 상주 규정, 보안 아키텍처, 조달 전략 때문에 프롬프트, 출력, 트레이스 세부 정보를 제3자 클라우드로 보내는 것이 제한되는 조직에 중요하다. 이 가이드는 기술적 경로를 제시할 뿐, 모든 엔터프라이즈 요구사항이 해결되었다는 증거는 아니다.

AI 빌더와 엔터프라이즈 팀에 의미하는 것

개발자에게 가장 큰 장점은 운영 일관성이다. 팀은 개발 중에는 로컬 머신에서, 운영용으로는 프라이빗 데이터센터에서, 또는 다른 클라우드 제공업체에서 에이전트를 실행하면서 실행 데이터를 하나의 AWS 모니터링 화면으로 보낼 수 있다. 이는 배포 위치마다 별도 대시보드를 만드는 필요성을 줄일 수 있다.

이 데이터는 실질적인 디버깅에도 도움이 된다. 트레이스는 사용자 세션을 모델 호출, 도구 호출, 후속 단계와 연결해 단일 프롬프트-응답보다 복잡한 워크플로의 장애를 조사하기 쉽게 만든다. 토큰 사용량은 특히 에이전트가 모델이나 도구를 반복 호출할 때 비용 모니터링의 기반이 될 수 있다.

하지만 엔터프라이즈 구매자에게 중앙화는 절충을 의미한다. IAM 액세스 키와 모델 입력 또는 출력을 포함하는 텔레메트리는 보호, 범위 설정, 거버넌스가 필요하다. 팀은 어떤 필드를 안전하게 내보낼 수 있는지, 기록을 얼마나 오래 보관할지, CloudWatch와 AgentCore Observability가 규정 준수 경계에 맞는지 결정해야 한다.

이 설정은 컴퓨팅이 다른 곳에 남아 있어도 어느 정도 AWS 의존성을 만든다. GCP, Azure, 온프레미스 인프라를 사용하는 빌더는 배포 유연성을 유지할 수 있지만, AWS가 설명한 모니터링 제어 평면, 인증 모델, 저장 경로는 여전히 AWS 서비스에 묶여 있다. 이는 AWS 중심 조직에는 매력적일 수 있지만, 벤더 중립적인 OpenTelemetry 스택을 추구하는 기업에는 덜 설득력 있을 수 있다.

다음에 주목할 점

가장 즉각적인 신호는 AWS가 AgentCore 런타임을 넘어 AgentCore Observability의 기본 지원을 확장할지, 아니면 외부 워크로드에 대해 ADOT 기반 통합에 계속 의존할지 여부다. 추가 프레임워크 계측과 모델 제공자에 대한 문서는 이 패턴이 게시물의 예시를 넘어 얼마나 폭넓게 작동하는지를 보여줄 것이다.

이 접근 방식을 평가하는 팀은 텔레메트리 비용, 내보내기 지연, 샘플링 제어, 보존 옵션, 데이터 마스킹에 대한 구체적인 정보도 주시해야 한다. 독립적인 구현 보고서는 이 구성이 단지 가이드 예시로 재현 가능한 수준을 넘어, 실제 프로덕션 규모에서도 실용적인지 판단하는 데 도움이 될 것이다.

마지막으로 시장은 다른 클라우드 제공업체들이 유사한 크로스환경 에이전트 모니터링으로 대응할지 지켜볼 것이다. AI 에이전트가 프라이빗 인프라와 여러 클라우드로 분산됨에 따라, 관측성은 팀이 워크로드를 어디에서 실행할지 결정하는 요소가 될 수 있다.

Creati.ai 관점

AWS는 외부 에이전트가 이제 AgentCore Observability 내부에서 기본적으로 실행된다고 발표하는 것이 아니다. 대신 ADOT와 CloudWatch를 사용해 서비스의 가시성을 다른 곳에 배포된 워크로드로 확장하는 브리지를 문서화하고 있다. 이는 의미 있는 운영 개선이지만, 그 유용성은 팀이 AWS를 텔레메트리 제어 평면으로 받아들이는지에 달려 있다.

빌더에게 가장 강한 시사점은 아키텍처적이다. 에이전트 모니터링은 모델, 도구, 배포 환경 전반에서 워크플로를 따라가야 한다. AWS의 접근 방식은 이미 해당 서비스에 투자한 조직의 통합 노력을 줄여주지만, 필요한 자격 증명과 데이터 라우팅은 보안, 이식성, 비용 문제를 모든 프로덕션 롤아웃의 핵심에 놓는다.