⚡ 3줄 요약
- 여러 클라우드에 흩어진 에이전트를 한 화면에서 보는 건 가능하다 — 단 공짜도, 자동도 아니다.
- AgentCore Observability가 기본 지원하는 건 AWS AgentCore runtime 위의 에이전트뿐. 온프렘·GCP·Azure는 ADOT를 직접 붙여야 한다.
- 실행하면 대시보드에 뜨는 건 2~3분 뒤다. 즉시 뜬다고 가정하고 디버깅하면 헛짚는다.
“우리 에이전트는 온프레미스에서도, GCP에서도, Azure에서도 돌아가면서 전부 같은 대시보드로 보고한다.” AWS가 AgentCore Observability를 소개하며 내건 문장이다. 멀티 클라우드 운영자에겐 솔깃한 약속이다. 그런데 이 문장에는 조용히 생략된 조건이 하나 있다. AWS 밖에서 돌아가는 에이전트는 기본 지원 대상이 아니다. 대시보드에 그림을 채워 넣으려면 각 환경에 직접 계측 도구를 심고, 인증 정보를 발급하고, 비용까지 감수해야 한다. 편리함은 진짜지만, 그 편리함은 설정을 끝낸 사람에게만 온다.
한 화면의 진짜 값어치는 ‘비교’에서 나온다
에이전트가 환경마다 따로 로그를 뱉으면 문제가 생긴다. AWS 콘솔에서 지연 시간을 보고, GCP 로그에서 토큰 사용량을 뒤지고, 온프렘 서버에서 도구 호출 기록을 확인하는 식이면 — 같은 요청이 어디서 느려졌는지, 어느 환경이 토큰을 더 태우는지 나란히 놓고 볼 수가 없다.
AgentCore Observability의 핵심은 ‘멋진 화면’이 아니라 흩어진 실행 기록을 한 좌표계로 모으는 것이다. 세션, trace, span, 지연 시간, 토큰 사용량이 같은 형식으로 정렬되면 그때부터 환경 간 비교가 가능해진다. 반대로 말하면, 이 형식을 맞추는 설정 작업이 이 도구를 쓰는 값의 대부분이다.
기본 지원 vs 추가 설정, 이 선부터 긋자
가장 먼저 확인할 것은 내 에이전트가 어디서 도는가다. AWS는 이 도구가 “AWS 클라우드의 AgentCore runtime에 배포된 에이전트만 네이티브로 지원한다”고 못 박는다. 그 밖의 환경이면 telemetry를 대시보드로 보내는 추가 구성이 필요하다.
| 실행 환경 | 필요한 작업 |
|---|---|
| AWS AgentCore runtime | 추가 작업 거의 없음 (기본 지원) |
| 온프레미스 서버 | ADOT 계측 + IAM 인증 + HTTPS 아웃바운드 |
| GCP · Azure | 온프렘과 동일 (환경마다 반복) |
여기서 오해가 하나 생긴다. “멀티 클라우드 지원”이라는 말을 “어디서 돌리든 알아서 잡힌다”로 읽으면 안 된다. 실제로는 AWS 밖의 모든 환경에 계측 코드를 각각 심어야 한다. 환경이 셋이면 세 번 설정한다.
trace와 span — 답이 이상할 때 어디를 보나
대시보드를 열면 두 층위의 기록이 보인다. trace는 요청 하나의 처음부터 끝까지다. 사용자가 물어본 순간부터 최종 답변이 나올 때까지의 전체 흐름을 한 덩어리로 묶는다. span은 그 trace 안의 한 단계다. 모델 호출 하나, 도구 사용 하나가 각각 span이 된다. AWS 예시에선 invoke_agent, chat, execute_event_loop_cycle 같은 이름의 span이 등장한다.
이 구분이 실전에서 왜 중요한가. 답이 이상하게 나왔을 때, 결과만 보는 방식으론 원인을 못 찾는다. trace로 전체 흐름을 훑고 → 어느 span에서 시간이 튀었는지, 어느 도구 호출이 엉뚱한 값을 반환했는지 좁혀 들어간다. 지연 시간과 토큰 사용량이 span 단위로 붙어 있으니, “느린 단계”와 “비싼 단계”를 콕 집을 수 있다.
온프렘 에이전트를 대시보드에 연결하는 6단계
AWS 예시가 안내하는 실제 흐름은 이렇다.
| 단계 | 하는 일 |
|---|---|
| 1 | 온프렘·타 클라우드에서 에이전트를 실행한다 |
| 2 | AWS Distro for OpenTelemetry(ADOT)를 프로세스에 심는다 |
| 3 | 보낼 주소(CloudWatch OTLP endpoint)와 인증 정보를 환경변수로 등록한다 |
| 4 | ADOT가 모델 호출·도구 사용 기록을 수집한다 |
| 5 | SigV4 서명을 붙여 CloudWatch로 전송한다 |
| 6 | AgentCore Observability가 에이전트용 화면에 정리한다 |
인증은 IAM 자격 증명으로 신원을 확인하고, 요청마다 SigV4 서명을 붙이는 방식이다. 설정의 실체는 환경변수 몇 개다. AWS 예시 기준 OTEL_PYTHON_DISTRO=aws_distro, OTEL_PYTHON_CONFIGURATOR=aws_configurator, 그리고 x-aws-metric-namespace=bedrock-agentcore 같은 헤더를 지정한다.
계정 단위로 딱 한 번 켜야 하는 스위치도 있다 — CloudWatch Transaction Search다. 이걸 켜야 저장된 실행 기록을 검색할 수 있다.
aws xray update-trace-segment-destination --destination CloudWatchLogs --region us-east-1제대로 켜졌는지는 이 명령으로 확인한다.
aws xray get-trace-segment-destination --region us-east-1
# 기대값: {"Destination": "CloudWatchLogs", "Status": "ACTIVE"}⚠️ 실행하자마자 대시보드 새로고침하지 마라
AWS 예시는 telemetry가 “실행 후 2~3분 안에” 나타난다고 명시한다. 즉시 안 뜬다고 설정이 틀린 줄 알고 되짚기 시작하면 시간만 버린다. 잠깐 기다렸다가 확인하는 게 정상 동작이다.
편리함의 청구서 — 비용과 인증이라는 두 부담
중앙 대시보드는 공짜 기능이 아니다. AWS 문서가 직접 밝힌다 — 이 절차는 Amazon Bedrock, Amazon CloudWatch, AWS X-Ray를 쓰며, 각각 비용이 발생한다. 에이전트를 많이 굴릴수록 telemetry 양도 늘고, 그만큼 청구서도 커진다. “한 화면에서 본다”는 편의만 보고 이 비용을 빼먹으면 안 된다.
두 번째 부담은 인증 정보 관리다. 외부 환경이 AWS로 기록을 보내려면 장기 자격 증명을 그 환경에 둬야 하는데, 이 키를 어떻게 안전하게 보관할지는 AWS 예시가 깊이 다루지 않는다. 온프렘 서버에 AWS 키를 심는 순간 그건 조직 보안 검토 대상이 된다. 여기는 각자 알아서 채워야 하는 빈칸이다 — 흩어진 키를 게이트웨이 한 곳으로 모아 통제하는 방식이 하나의 답이 된다.
🎯 FEEDON의 선택 — 우리라면 이렇게 한다
먼저 에이전트 하나, 환경 하나로 작게 붙여본다. 온프렘 에이전트 한 대에 ADOT를 심고, trace가 뜨는지, 그 안에 모델 호출 span과 도구 사용 span이 갈라져 보이는지, 토큰 사용량이 찍히는지만 확인한다. 이게 되면 나머지 환경은 같은 절차의 반복이다.
주의할 지점은 “여러 팀의 운영 현황을 한눈에 비교하는 관제 화면”으로 곧장 확장하는 상상이다. 그건 조직의 로그 형식과 권한 체계가 먼저 맞아야 성립한다. 애초에 에이전트 설계의 핵심은 모델 고르기가 아니라 권한을 긋는 일이라는 점을 관측 도구를 붙이기 전에 짚어둘 값어치가 있다. 도구가 대시보드를 준다고 관제 체계가 저절로 생기지는 않는다. 그리고 마지막까지 놓지 말 것 — 기록은 문제를 찾는 재료일 뿐, 답변이 사실인지까지 자동으로 판별해주지 않는다.
적용 전 체크리스트
- 실행 환경이 AWS AgentCore runtime인지 먼저 확인 — 맞으면 절반은 끝
- 외부 환경이면 ADOT(aws-opentelemetry-distro) 계측 적용
- CloudWatch Transaction Search를 계정에 한 번 활성화
- IAM 권한(bedrock:InvokeModel, CloudWatch Logs, X-Ray 등)과 외부 HTTPS 아웃바운드 확보
- Python 3.10 이상 (예시는 3.12 권장)
- trace와 span이 둘 다 보이는지, 토큰·지연 시간이 찍히는지 확인
- Bedrock·CloudWatch·X-Ray 비용과 인증 정보 보관 방식 검토
붙이는 순서
📡 이 순서로 연결한다
- 에이전트가 AWS AgentCore runtime에서 도는지 먼저 확인한다 — 맞으면 기본 지원이라 절반은 끝이다.
- 외부 환경(온프렘·GCP·Azure)이면 프로세스에 ADOT를 심고, CloudWatch OTLP 주소와 IAM 인증 정보를 환경변수로 등록한다.
- 계정에 CloudWatch Transaction Search를 한 번 활성화하고,
get-trace-segment-destination으로ACTIVE인지 확인한다. - 실행 후 2~3분 기다렸다가 대시보드에서 trace와 그 안의 모델 호출·도구 사용 span, 토큰·지연 시간이 찍히는지 검증한다.
출처: AWS Machine Learning Blog 「Monitor on-premises and multi-cloud AI agents with AgentCore Observability」 · 사양·비용·설정 절차는 변동될 수 있음
이 글은 FEEDON이 공개 1차 자료를 바탕으로 작성·검증했습니다.
