Bedrock AgentCore Observability의 멀티클라우드 확장

Amazon EKS, ECS, Lambda뿐 아니라 온프레미스, GCP, Azure 등 AWS 외부 인프라에서 구동되는 AI 에이전트의 성능 데이터를 Bedrock AgentCore Observability 대시보드에서 통합 확인 가능하다. 이 변화는 인프라 선택의 제약을 없애며, 개발자가 어떤 환경에서 에이전트를 실행하든 동일한 모니터링 인터페이스를 사용할 수 있게 한다. Strands Agents, LangGraph, CrewAI와 같은 프레임워크로 구축한 AI 에이전트는 실행 환경과 관계없이 성능 추적이 필수적이다. 특히 분산된 환경에서 에이전트를 운용할 때 발생하는 데이터 파편화 문제를 해결하여 통합된 가시성을 제공한다.

기존의 AgentCore Observability는 기본적으로 AWS Cloud 내의 AgentCore 런타임에 배포된 에이전트만 네이티브하게 지원했다. 네이티브 지원은 시스템이 별도의 추가 설정 없이도 성능 데이터를 자동으로 수집하고 전송하는 방식을 의미한다. 하지만 이번 확장을 통해 비 AWS 환경에서도 텔레메트리, 즉 시스템 상태 및 성능 데이터를 전송하기 위한 추가 설정 경로가 확보되었다. 이로써 자체 구축 서버 환경인 온프레미스나 Google Cloud Platform(GCP), Microsoft Azure의 가상 머신에서도 AWS의 모니터링 체계에 데이터를 보낼 수 있는 기술적 경로가 마련되었다.

인프라 환경에 따라 관찰 가능성, 즉 시스템 내부 상태를 외부 출력으로 파악하는 능력인 Observability를 확보하는 방식에는 명확한 차이가 존재한다. Amazon Bedrock AgentCore 런타임에 직접 배포한 에이전트는 자동 설정 혜택을 받아 즉시 모니터링이 가능하다. 반면 GCP VM이나 Azure VM 같은 외부 환경에서 실행되는 에이전트는 텔레메트리 전송을 위한 수동 설정 과정이 반드시 필요하다. 수동 설정이라는 추가 공수가 발생하지만, 이는 배포 위치를 자유롭게 선택할 수 있는 아키텍처 유연성과 교환되는 지점이다.

결과적으로 외부 인프라의 에이전트가 전송한 데이터는 Amazon CloudWatch 대시보드에 통합되어 나타난다. 운영자는 에이전트가 어느 클라우드 제공업체의 서버에 있든 상관없이 지연 시간이나 토큰 사용량 같은 핵심 지표를 동일한 기준으로 분석할 수 있다. 이는 특정 벤더에 종속되지 않고 인프라를 구성하면서도, 관리 포인트는 AWS의 통합 도구로 단일화하려는 요구를 충족한다. 외부 환경의 에이전트가 전송하는 텔레메트리는 CloudWatch의 통합 뷰를 통해 실시간으로 확인되며, 이를 통해 멀티클라우드 환경의 에이전트 성능을 단일 창에서 관리한다.

ADOT 기반의 텔레메트리 전송 파이프라인

ADOT는 에이전트 애플리케이션과 동일한 프로세스 내부에서 작동하며 코드 수정 없이 성능 데이터를 수집하는 자동 계측 방식을 사용한다. 여기서 ADOT는 오픈소스 OpenTelemetry의 AWS 배포판인 AWS Distro for OpenTelemetry를 의미한다. 이 도구는 생성형 AI 시맨틱 컨벤션 스팬이라는 작업 단위 기록을 캡처한다. 스팬은 분산 추적에서 개별 작업의 시작과 끝, 그리고 그 사이의 상태를 기록한 최소 단위를 뜻하며 시맨틱 컨벤션은 데이터의 이름과 형식을 표준화한 규칙이다. 자동 계측을 통해 개발자는 복잡한 비즈니스 로직을 직접 수정하지 않고도 모델 호출 주기와 응답 시간 같은 핵심 지표를 실시간으로 추적할 수 있다.

수집된 데이터는 AWS Identity and Access Management(IAM) 자격 증명을 통한 SigV4 인증 과정을 거쳐 전송된다. SigV4는 AWS의 표준 요청 서명 방식으로 요청의 무결성과 신원을 검증하여 허가된 사용자만 데이터 전송이 가능하게 만드는 보안 프로토콜이다. 인증이 완료된 텔레메트리는 CloudWatch OTLP 엔드포인트로 직접 내보내진다. OTLP는 OpenTelemetry Protocol의 약자로 서로 다른 관찰 도구 간에 데이터를 일관되게 주고받기 위해 정의된 표준 통신 규격이다. [Figure 1] 이 과정에서 Amazon CloudWatch는 대규모 텔레메트리 데이터의 수집과 저장을 처리하는 기반 저장소 역할을 수행한다.

전송 파이프라인의 최종 단계에서는 Amazon Bedrock AgentCore Observability가 개입하여 AI 에이전트의 특성에 맞춘 전용 모니터링 대시보드를 생성한다. IAM은 외부 환경과 AWS 서비스 사이의 인증 보안을 책임지며 ADOT는 다양한 플랫폼에서 동일하게 작동하는 계측 능력을 제공한다. [Figure 2] 이러한 구성 요소들의 결합은 데이터 캡처부터 저장, 시각화까지 이어지는 일련의 흐름을 하나의 파이프라인으로 통합한다. 결과적으로 외부 인프라에서 실행되는 에이전트의 상태 정보가 AWS의 통합 관리 체계 안으로 안전하게 유입되는 구조를 갖춘다.

환경 변수 설정과 opentelemetry-instrument 실행

CloudWatch에서 Transaction Search 기능을 활성화해야 텔레메트리 데이터 수집이 시작된다. Transaction Search는 대량의 텔레메트리 데이터 내에서 특정 요청을 빠르게 찾는 기능이다. 계정당 한 번만 실행하면 되며 아래 명령어를 사용하여 스트림을 생성한다.

aws cloudwatch put-metric-stream --name "AgentCoreStream" --input-location "aws/otel"

기본 환경 구축을 위해 `aws-opentelemetry-distro`와 `strands-agents[otel]` 패키지를 설치한다. 전자는 AWS 전용 OTLP(OpenTelemetry Protocol, 텔레메트리 데이터를 전송하는 표준 프로토콜) 내보내기와 aws_configurator를 통한 SigV4(AWS의 표준 요청 서명 방식) 인증을 처리하는 ADOT 자동 계측 패키지다. 후자는 Strands 프레임워크에서 추적 데이터를 생성하는 역할을 한다. 이 두 패키지는 코드 수정 없이 인프라 수준에서 데이터를 수집하는 기반이 된다.

런타임 자동 설정 대신 환경 변수를 통해 데이터 경로와 식별자를 수동으로 지정한다. `OTEL_EXPORTER_OTLP_ENDPOINT` 변수에는 CloudWatch OTLP 엔드포인트 주소를 입력하고, `OTEL_SERVICE_NAME`에는 대시보드에서 구분할 에이전트 이름을 설정한다. 이는 AgentCore 런타임이 제공하는 자동 구성 방식과 대비되는 지점으로, 사용자가 전송 대상과 서비스 이름을 직접 제어해야 하는 비 AWS 환경의 특성을 반영한다.

실행 단계에서는 `opentelemetry-instrument python agent_test.py` 명령어를 사용한다. 이 명령어는 파이썬 프로세스를 래핑하여 Amazon Bedrock 호출과 Strands 프레임워크 동작을 자동으로 캡처한다. [Figure 3] [Figure 4] [Figure 5] 별도의 코드 수정 없이 래퍼 명령어만으로 계측이 이루어지므로 개발자는 비즈니스 로직에만 집중할 수 있다. 실행 후 2~3분 이내에 CloudWatch 대시보드에 데이터가 반영된다. 수집된 데이터는 AgentCore 런타임 기반 에이전트가 생성하는 결과와 동일하며 세션, 추적, 스팬(작업 단위 기록) 메트릭, 토큰 사용량, 지연 시간이 모두 포함된다.

추론 체인 가시화와 비용 거버넌스 확보

에이전트가 정답을 도출하기 위해 거치는 추론 체인(Reasoning Chain, 사고 과정의 논리적 단계)과 도구 호출 기록, 최종 모델 출력값을 실시간으로 확인한다. 텔레메트리 데이터를 AgentCore Observability로 전송하면 분산된 환경에서도 에이전트의 내부 동작을 투명하게 파악할 수 있다. 개발자는 모델이 어떤 근거로 특정 도구를 선택하고 어떤 파라미터를 전달해 결과를 도출했는지 단계별로 추적하며 로직의 오류를 수정한다. 도구 호출의 성공 여부와 응답 시간을 함께 분석함으로써 병목 지점을 찾아내고 에이전트의 응답 속도를 개선한다. 이는 단순한 결과 확인을 넘어 모델의 사고 경로를 정밀하게 분석하고 디버깅 시간을 단축하는 환경을 제공한다.

중앙 집중형 모니터링은 모델이 허위 정보를 생성하는 환각(Hallucination) 현상을 빠르게 탐지하는 데 활용된다. 유해하거나 주제를 벗어난 응답이 발생하는 지점을 즉시 식별하여 프롬프트를 수정하거나 가드레일을 강화하는 조치를 취한다. 특히 AWS 외부 환경에서 작동하는 에이전트는 통합 모니터링 체계가 없으면 문제 응답이 발생해도 운영자가 이를 인지하지 못하고 방치할 위험이 크다. 중앙에서 모든 응답을 감시함으로써 외부 환경의 불확실성을 제거하고 책임감 있는 AI 운영 체계를 구축한다. 이를 통해 에이전트가 설정된 목적과 범위 내에서만 동작하도록 강제하는 정렬 상태를 유지한다.

환경별 토큰 사용량을 정밀하게 추적하여 비용 거버넌스(Cost Governance, AI 자원 소비 비용을 관리하고 통제하는 체계)를 수립한다. 각 에이전트가 요청당 소비하는 입력 및 출력 토큰 양을 수치로 확인해 예산 초과 위험을 방지하고 효율적인 모델 선택 기준을 마련한다. 토큰 사용량을 프로젝트나 부서 단위로 세분화해 추적함으로써 AI 자원 소비의 책임 소재를 명확히 하고 비용 최적화 지점을 찾는다. 다양한 클라우드나 온프레미스 환경에 흩어져 실행되는 에이전트들의 동작 기록을 한곳에서 관리하는 중앙 집중식 감사(Audit) 기능도 수행한다. 운영자는 개별 인프라에 일일이 접속해 로그를 수집하는 번거로움 없이 전체 에이전트의 실행 이력과 시간대별 동작을 통합 검토하며 보안 규정 준수 여부를 확인한다.

이러한 가시성 확보 구조는 Strands Agents 프레임워크를 통해 실제 동작이 검증되었다. OpenTelemetry(시스템 상태 및 성능 데이터를 수집하는 표준 규격)와 호환되는 다른 에이전트 프레임워크에서도 동일한 ADOT 기반 패턴을 적용해 데이터를 수집할 수 있다. 특정 벤더의 도구에 종속되지 않고 표준 규격을 따르는 프레임워크라면 어디서든 중앙 대시보드에 데이터를 통합할 수 있다. 이는 멀티클라우드 환경에서 에이전트 운영 규모가 확장될 때 관리 복잡도를 낮추고 일관된 성능 지표를 유지하는 핵심 요소가 된다. 인프라의 위치와 관계없이 동일한 관측 지표를 공유함으로써 운영 효율성을 극대화한다.

하이브리드 클라우드 전략을 위한 인프라 선택 기준

AgentCore 런타임은 자동 설정으로 관리 편의성을 제공하는 반면, 비 AWS 환경은 수동 설정이 필요하지만 배포 유연성이 높다. AgentCore 런타임은 AWS 클라우드 내에서 에이전트를 실행하고 최적화하는 관리형 환경을 뜻한다. 반면 온프레미스나 타사 클라우드 환경은 인프라 제어권을 완전히 가질 수 있어 기업의 데이터 주권 정책이나 기존 레거시 시스템과의 물리적 통합이 필요한 경우에 유리하다. 관리 효율성을 우선한다면 런타임을 선택하고, 인프라 독립성과 제어권을 우선한다면 수동 설정을 통한 비 AWS 배포를 선택하는 트레이드오프가 발생한다.

실제 운영 환경에서는 보안 사고 방지를 위해 장기 액세스 키 대신 IAM Roles Anywhere 사용을 권장한다. IAM Roles Anywhere는 X.509 인증서라는 디지털 신원 확인서를 통해 온프레미스 워크로드가 AWS의 임시 자격 증명을 얻는 방식이다. 기존의 고정된 액세스 키를 서버 설정 파일에 저장하는 방식은 키 유출 시 권한이 영구적으로 노출되는 위험이 있다. 반면 임시 자격 증명은 사용 시간이 제한되어 있어 보안 위협을 낮춘다. 하이브리드 클라우드 구조에서 보안 표준을 준수하며 AWS 리소스에 안전하게 접근하기 위한 핵심적인 인증 체계다.

GCP Cloud Shell 환경에서 수행한 테스트 결과, 온프레미스와 동일한 텔레메트리 데이터가 생성됨을 확인했다. Google Cloud Shell은 GCP 인프라 위에서 구동되는 브라우저 기반 터미널로, 타사 클라우드 환경에서의 호환성을 검증하는 지표가 된다. [Figure 6] [Figure 7] 인터넷 연결이 가능하고 올바른 OpenTelemetry 환경 변수가 설정되어 있다면, 에이전트가 실행되는 물리적 위치는 데이터 수집과 전송에 영향을 주지 않는다. 이는 기업이 멀티 클라우드 전략을 취하더라도 에이전트의 추론 성능과 리소스 사용량을 단일 지점에서 통합 관리할 수 있음을 의미한다.

인프라 위치와 상관없이 에이전트의 추론 체인, 도구 호출, 토큰 사용량을 하나의 대시보드에서 비교 분석하려면, 운영 환경의 보안 수준에 따라 IAM Roles Anywhere 도입 여부를 결정하는 것이 실질적인 실행 기준이다.