Monitor on-premises and multi-cloud AI agents with AgentCore Observability

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

ADOT 자동 계측과 IAM 기반 SigV4 인증을 이용해 온프레미스·멀티클라우드에서 실행되는 AI 에이전트의 텔레메트리를 CloudWatch로 전송하고 AgentCore Observability에서 통합 관찰하는 구성 및 검증 절차를 설명한다.

📌 핵심 요약

• AgentCore Observability는 AgentCore 런타임에 배포된 에이전트를 기본 지원하므로, 온프레미스나 GCP·Azure 등 외부 환경의 에이전트를 관찰하려면 별도의 텔레메트리 전송 구성이 필요하다.
• 제시된 구조는 에이전트 프로세스 내부에서 ADOT 자동 계측을 실행해 생성형 AI 의미 규약에 따른 스팬을 수집하고, IAM 자격 증명으로 서명한 뒤 CloudWatch OTLP 엔드포인트로 직접 전송한다.
• 구성에는 Amazon Bedrock 모델 접근 권한, CloudWatch Transaction Search 활성화, Python 3.10 이상, 필요한 로그·추적·지표 권한을 가진 IAM 자격 증명, AWS 엔드포인트로의 HTTPS 통신이 요구된다.
• 실습은 패키지 설치, AWS 자격 증명 설정, OpenTelemetry 환경 변수 지정, Strands 에이전트 작성, opentelemetry-instrument를 통한 실행, AgentCore Observability 대시보드 확인 순서로 진행된다.
• 정상 구성되면 에이전트 세션과 추적, 추론 및 도구·모델 호출 스팬, 지연 시간과 토큰 사용량을 확인할 수 있으며, 같은 접근을 Google Cloud Shell에서도 시험했다.

🧩 주요 포인트

1. 기본 지원 범위의 한계 → AgentCore 런타임 밖의 에이전트에는 ADOT와 명시적인 라우팅 설정을 추가해야 중앙 관찰이 가능하다.
2. 자동 계측과 SigV4 결합 → 애플리케이션 코드를 대폭 변경하지 않고도 외부 환경의 추적·로그·지표를 AWS 관찰 경로에 연결할 수 있다.
3. 생성형 AI 전용 텔레메트리 확보 → 추론 흐름, 모델 호출, 토큰 사용량과 응답 행동을 세션 단위로 분석해 품질·안전·비용 관리를 지원한다.

🧠 상세 정리

1. 관찰 범위와 해결 과제

Strands Agents, LangGraph, CrewAI 같은 프레임워크로 만든 AI 에이전트는 EKS, ECS, Lambda, 온프레미스, GCP, Azure 등 어디에서 실행되더라도 성능과 행동을 파악할 관찰 기능이 필요하다. AgentCore는 프레임워크나 모델에 관계없이 에이전트를 구축·연결·최적화하는 플랫폼이며, AgentCore Observability는 추적과 모니터링, 분석 기능을 제공한다. 다만 이 기능이 기본적으로 지원하는 대상은 AWS의 AgentCore 런타임에 배포된 에이전트이므로, 다른 위치에서 실행되는 에이전트는 대시보드로 텔레메트리를 보내기 위한 추가 구성이 필요하다. 글은 이러한 제약을 해결하기 위해 비AWS 환경에서 ADOT 자동 계측을 구성하고, 수집한 데이터를 AgentCore Observability로 전달한 뒤 전체 경로를 검증하는 방법을 단계별로 제시한다.

2. 교차 플랫폼 텔레메트리 아키텍처

해결 구조의 중심은 에이전트 애플리케이션과 같은 프로세스에서 실행되는 AWS Distro for OpenTelemetry, 즉 ADOT이다. ADOT는 에이전트 프레임워크를 자동 계측해 생성형 AI 의미 규약에 맞는 스팬을 수집하고, 텔레메트리를 Amazon CloudWatch의 OTLP 수집 엔드포인트로 직접 내보낸다. 이때 요청은 IAM 자격 증명을 이용한 SigV4 방식으로 인증되며, 별도의 중간 수집기보다 프로세스 내부 자동 계측과 직접 전송에 초점을 둔다. 전체 구성의 세 핵심 요소는 ADOT 자동 계측, CloudWatch 인증에 사용할 IAM 자격 증명, 라우팅과 인증 동작을 지정하는 OpenTelemetry 환경 변수다. CloudWatch는 텔레메트리 수집과 저장의 기반을 맡고, AgentCore Observability는 AI 에이전트 전용 대시보드를 제공하며, IAM은 외부 실행 환경과 AWS 사이의 인증을 보호한다.

3. 책임 있는 AI를 위한 중앙 관찰

글은 관찰 가능성을 책임 있는 AI 운영의 기반 요소로 규정한다. 텔레메트리를 AgentCore Observability로 모으면 에이전트의 추론 체인, 도구 호출, 모델 출력처럼 일반 애플리케이션 모니터링만으로는 파악하기 어려운 실행 맥락을 확인할 수 있다. 이 데이터는 환각을 식별하고, 유해하거나 주제에서 벗어난 응답을 감시하며, 토큰 사용량을 추적해 비용을 관리하고, 여러 환경에 분산된 에이전트 행동을 감사하는 데 활용된다. 특히 AWS 밖에서 실행되는 에이전트는 통합된 관찰 경로가 없을 경우 문제 출력이 발견되지 않을 수 있으므로, 실행 위치와 무관하게 같은 대시보드로 텔레메트리를 모으는 것이 중요하다. 따라서 제시된 구성은 단순한 인프라 성능 감시를 넘어 에이전트의 품질·안전·비용 관련 행동을 함께 살펴보기 위한 구조다.

4. 사전 요건과 Transaction Search 활성화

실습 전에는 Amazon Bedrock 모델 접근이 구성된 AWS 계정이 필요하며, 예제는 Claude Haiku 모델을 사용한다. 비AWS 실행 환경에는 Python 3.10 이상이 설치되어 있어야 하고, AWS 엔드포인트로 나가는 HTTPS 통신이 허용되어야 한다. IAM 사용자 자격 증명에는 모델 호출을 위한 bedrock:InvokeModel, 로그 그룹·스트림 생성과 이벤트 기록 권한, X-Ray 추적 세그먼트·텔레메트리·샘플링 관련 권한, CloudWatch 지표 기록 권한이 요구된다. 또한 CloudWatch Transaction Search를 계정에서 한 번 활성화해야 하며, us-east-1 기준으로 X-Ray 추적 세그먼트 목적지를 CloudWatch Logs로 변경하는 명령을 실행한다. 이후 조회 명령으로 목적지가 CloudWatchLogs이고 상태가 ACTIVE인지 확인해야 하며, 이 준비가 완료되어야 추적 데이터를 후속 대시보드에서 탐색할 수 있다.

5. ADOT 자동 계측과 SigV4 인증

aws-opentelemetry-distro가 제공하는 자동 계측은 비AWS 환경에서 CloudWatch로 텔레메트리를 내보내는 세부 작업을 처리한다. opentelemetry-instrument 명령은 Python 런타임에 ADOT를 주입하고, Amazon Bedrock 호출을 담당하는 boto3와 에이전트 추론 스팬을 내보내는 Strands 프레임워크를 자동으로 계측한다. aws_configurator는 boto3 자격 증명 체인을 사용해 OTLP 전송 요청에 SigV4 서명을 적용하며, 비AWS 환경에서는 AWS_ACCESS_KEY_ID와 AWS_SECRET_ACCESS_KEY 환경 변수를 통해 제공된 값을 사용한다. 추적과 로그는 CloudWatch의 기본 OTLP 수집 엔드포인트로 전달되고, 로그 헤더는 데이터를 특정 AgentCore 로그 그룹에 연결해 생성형 AI 관찰 대시보드에서 색인될 수 있도록 한다. Strands의 otel 확장은 추론 단계, 도구 호출, 모델 호출과 토큰 사용량을 포함하는 OpenTelemetry 생성형 AI 의미 규약 기반 스팬을 생성한다.

6. 패키지·자격 증명·환경 변수 구성

비AWS 환경에는 aws-opentelemetry-distro 0.10.0 이상, boto3, 그리고 otel 확장을 포함한 strands-agents 패키지를 설치한다. 이어 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION을 환경 변수로 지정하며, 예제 리전은 us-east-1이다. 글은 운영 환경에서 장기 액세스 키를 계속 사용하는 대신 X.509 인증서로 임시 자격 증명을 받을 수 있는 IAM Roles Anywhere를 고려하라는 보안 참고사항도 제시한다. OpenTelemetry 설정에서는 생성형 AI 텔레메트리 처리를 활성화하고, 배포판과 구성기를 각각 aws_distro와 aws_configurator로 선택하며, 전송 프로토콜을 HTTP와 Protocol Buffers 조합으로 지정한다. 특히 OTEL_RESOURCE_ATTRIBUTES의 서비스 이름과 aws.log.group.names가 AgentCore Observability 색인 위치를 결정하고, 로그 헤더의 로그 그룹·스트림 및 bedrock-agentcore 지표 네임스페이스가 데이터를 올바른 대시보드와 CloudWatch 네임스페이스로 전달한다. aws.log.group.names가 빠지면 추적이 일반 CloudWatch Logs로 이동하므로, 환경 변수는 단순 부가 설정이 아니라 관찰 화면으로의 라우팅을 결정하는 핵심 구성이다.

7. Strands 에이전트 작성과 계측 실행

예제 애플리케이션은 agent_test.py 파일에 Strands Agent와 BedrockModel을 구성하는 방식으로 작성된다. 모델은 us-east-1의 Claude Haiku 식별자를 사용하고, 에이전트에는 여행 도우미 역할의 시스템 프롬프트를 부여한 뒤 도쿄에서 할 일 세 가지를 묻는다. 세션 추적을 위해 현재 시각을 포함한 external-session 형식의 식별자를 만들고, OpenTelemetry baggage의 session.id로 설정한 후 컨텍스트에 연결한다. attach 이후 실행되는 에이전트 호출들은 같은 세션 식별자를 공유할 수 있어 여러 요청과 응답을 하나의 세션 관점에서 추적할 수 있다. 애플리케이션은 일반 Python 명령이 아니라 opentelemetry-instrument로 감싸 실행하며, 터미널에는 에이전트 응답이 표시되는 동시에 ADOT가 백그라운드에서 추적·스팬·로그를 수집해 CloudWatch로 전송한다.

8. 대시보드 검증과 GCP 시험

실행 후 텔레메트리가 화면에 나타나기까지 약 2~3분이 걸리며, CloudWatch 콘솔의 GenAI Observability에서 Bedrock AgentCore 화면으로 이동해 결과를 확인한다. Agents 탭에서 환경 변수에 지정한 my-external-agent를 선택하면 최소 한 개의 세션과 추적 데이터를 볼 수 있다. 추적에는 에이전트 추론과 Amazon Bedrock 모델 호출이 포함되며, invoke_agent, chat, execute_event_loop_cycle, 모델별 chat 스팬에서 지연 시간과 토큰 지표를 확인할 수 있다. 제시된 화면 예시는 네 개 스팬과 모델 정보, 지연 시간, 토큰 세부 정보가 포함된 성공적인 추적을 보여준다. 글은 제3자 클라우드에서도 동작하는지 확인하기 위해 GCP 인프라에서 실행되는 Google Cloud Shell에 Python 가상 환경을 만들고 같은 패키지, AWS 자격 증명, ADOT 환경 변수를 설정해 동일한 접근을 시험했다고 설명한다.

🧾 핵심 주장 / 시사점

• 에이전트의 실행 위치보다 중요한 것은 생성형 AI 의미 규약에 맞는 텔레메트리를 만들고, 올바른 로그 그룹과 네임스페이스로 인증·라우팅하는 일이다.
• 자동 계측은 boto3 모델 호출과 Strands 추론 흐름을 함께 포착하므로, 인프라 수준의 로그를 넘어 세션·스팬·토큰 단위의 에이전트 분석을 가능하게 한다.
• 대시보드 연동은 패키지 설치만으로 완성되지 않으며, Transaction Search 활성화, IAM 권한, resource attributes와 OTLP 로그 헤더가 모두 정확히 구성되어야 한다.

✅ 액션 아이템

• AgentCore 런타임 밖의 온프레미스·GCP·Azure 에이전트에 ADOT 자동 계측과 라우팅 설정을 둘 범위를 정의한다.
• CloudWatch OTLP 엔드포인트 전송에 필요한 IAM 자격 증명, Bedrock 접근, Transaction Search, Python 3.10 요건을 점검한다.
• Strands 에이전트를 opentelemetry-instrument로 실행한 뒤 AgentCore Observability에서 세션·토큰 사용량을 확인한다.

❓ 열린 질문

• 온프레미스와 멀티클라우드 에이전트에서 ADOT 자동 계측만으로 생성형 AI 스팬 품질이 충분한가?
• SigV4 서명 후 CloudWatch OTLP 엔드포인트 직접 전송 시 지연 시간과 토큰 사용량 관측 공백은 어디인가?
• Google Cloud Shell에서 시험한 동일 접근을 Azure 환경에도 같은 기준으로 적용 가능한가?