AWS 기술 블로그
Amazon Bedrock AgentCore로 구축하는 AgentOps (2): 관측성, 평가, 그리고 AgentOps 라이프사이클
본 사례는 AWS 3A(Agentic AI Acceleration) 프로그램에서 재사용 가능한 레퍼런스 asset으로 개발되었습니다.
이 글은 프로덕션 환경에서 에이전틱 AI를 운영하기 위한 2부작 시리즈입니다. 파운데이션을 세우는 것에서 시작해, 이를 안정적으로 운영하는 AgentOps까지 다루며, 이번 글은 그 두 번째 편입니다.
Part 1: Amazon Bedrock AgentCore로 구축하는 AgentOps (1): 파운데이션과 게이트웨이
Part 2: Amazon Bedrock AgentCore로 구축하는 AgentOps (2): 관측성, 평가, 그리고 AgentOps (이번 글)
Part 1에서는 에이전틱 AI를 프로덕션으로 올리기 위한 파운데이션의 필요성을 살펴보고, 그 핵심 요소인 게이트웨이(LLM Gateway, Tool Gateway, Agent Gateway)가 흩어진 모델·도구·에이전트 접근을 어떻게 하나로 통합하는지 확인했습니다.
이번 Part 2에서는 그 파운데이션 위에서 에이전트의 품질과 안전성을 지속적으로 보장하기 위한 관측성(Observability)과 평가(Evaluation), 최적화(Optimization)를 다루고, 이 모든 것을 하나의 운영 프로세스로 통합하는 AgentOps 라이프사이클을 살펴봅니다. 마지막으로 실전 데모를 통해 관측성과 평가, 최적화가 실제로 어떻게 동작하는지 확인합니다.
관측성을 넘어, 평가와 최적화까지 연결
기존 소프트웨어 애플리케이션에서 관측성(Observability)의 초점이 시스템을 살아있게 유지하는 것이었다면, 에이전트에서 말하는 관측성은 차원이 다릅니다. 에이전트가 서버 에러 없이 응답했더라도, 그 응답이 환각(hallucination)일 수 있고, 편향된 정보일 수 있으며, 안전하지 않은 행동을 했을 수도 있습니다.
| 관점 | 기존 소프트웨어 관측성 | 에이전트 관측성 |
| 핵심 질문 | “시스템이 잘 작동하는가?” | “에이전트가 정확하고, 안전하고, 유용한가?” |
| 관측 대상 | 인프라 상태 (CPU, 메모리, 네트워크) | 추론의 품질 (정확도, 환각, 편향, 안전성) |
| 실패의 의미 | 서버 다운, 타임아웃, 5xx 에러 | 잘못된 판단, 부적절한 행동, 환각 응답 |
| 지표 유형 | 처리량, 가용성, 에러율 | 목표 달성률, 가드레일 위반 빈도, 도구 선택 정확도 |
| 모니터링 본질 | 인프라를 모니터링 | 지능을 모니터링 |
이 전환은 에이전틱 루프에서 관측해야 할 대상을 근본적으로 바꿉니다. 프로덕션에서 에이전트를 운영하려면, 시스템이 아래와 같은 모든 질문에 답할 수 있도록 설계되어 있어야 합니다.
Figure 1. 에이전틱 루프에서 관측해야 할 핵심 질문
구체적으로는 사용자의 인증과 권한, 도구 호출의 적절성, 올바른 컨텍스트 접근, 행동의 허용 범위, 그리고 최종 결과가 목표 및 정책과 일치하는지를 실시간으로 확인할 수 있어야 합니다.
에이전트 관측성의 세 가지 신호
이 지능 모니터링을 구현하려면, 에이전트가 비결정적으로 행동하는 만큼 모든 추론 단계와 행동에 대한 완전한 가시성이 필요합니다. 같은 입력이라도 다른 경로로 다른 행동을 할 수 있기 때문입니다. 관측성은 전통적 소프트웨어와 동일하게 트레이스, 메트릭, 로그라는 세 신호로 구성되지만, 각 신호가 담는 내용이 에이전트에 맞게 확장됩니다.
① 트레이스 (Traces): 추론의 궤적을 기록
Figure 2. 에이전트 트레이스 구조 예시
트레이스는 에이전트의 실행 궤적을 단계별로 기록합니다. 사용자 요청에서 LLM 추론, 도구 선택 판단, 도구 호출, 결과 해석, 최종 응답 생성까지 이어지는 흐름이 하나의 트레이스로 묶이고, 각 단계는 span으로 표현되어 추론에 특화된 정보가 담깁니다.
각 단계(span)에는 다음이 기록됩니다.
- 시간 정보: 시작/종료 시간, 소요 시간, 전체 중 비중
- 입출력: 각 단계의 입력과 출력 (프롬프트, 도구 매개변수, 응답)
- 도구 정보: 호출된 도구 이름, 매개변수, 성공/실패 여부, 응답
② 메트릭 (Metrics): 지능의 건강 상태를 수치로
집계된 수치로 에이전트의 전반적 건강 상태를 파악합니다. 전통적 지표(성공/실패율, 평균 응답 시간과 P95/P99 레이턴시, 처리량)에 에이전트 고유 지표가 더해집니다.
- 목표 달성률 (Goal Success Rate): 사용자가 요청한 목표를 에이전트가 실제로 달성한 비율
- 도구 호출 정확도: 올바른 도구를 올바른 매개변수로 호출한 비율
- 가드레일 트리거 빈도: 안전성 정책이 에이전트 행동을 차단, 수정한 횟수. 너무 높으면 프롬프트 개선 필요, 너무 낮으면 가드레일 점검 필요
- 환각 탐지율: 제공된 컨텍스트에 없는 정보를 생성한 빈도
③ 로그 (Logs): 맥락이 있는 기록
개별 이벤트의 상세 정보를 구조화하여 기록하는 것으로, 트레이스, 메트릭만으로는 설명되지 않는 “그 순간 무슨 일이 있었나”를 메우는 가장 낮은 수준의 기록입니다.
- 에이전트의 추론 과정(chain-of-thought) 전문
- 가드레일 트리거 상세 (어떤 정책이 어떤 콘텐츠를 어떤 이유로 차단/수정했는지)
AgentCore Observability: 관리형 에이전트 관측성
AgentCore Observability는 Amazon CloudWatch 기반의 관리형 에이전트 모니터링 서비스로, 에이전트의 전체 궤적을 코드 변경 없이 모니터링할 수 있습니다.
Figure 3. AgentCore Observability 아키텍처
AgentCore Runtime에서 실행되는 에이전트는 AWS Distro for OpenTelemetry(ADOT) 자동 계측 덕에 코드 변경 없이 트레이스가 수집됩니다. 에이전트 코드에 계측 로직을 일일이 심을 필요 없이, 런타임이 프레임워크, 서비스 레벨의 트레이스를 자동으로 포착합니다.
- Step-by-step 실행 시각화: 에이전트의 추론 → 도구 호출 → 결과 해석 → 최종 응답까지 전체 궤적을 타임라인으로 시각화합니다
- 실시간 대시보드 + 알람: CloudWatch Dashboards에서 에이전트 특화 메트릭 실시간 모니터링, 이상 감지 시 알람을 발송합니다
- OpenTelemetry (OTEL) 호환: OTEL을 지원하여, 기존의 3rd party 관측성 서비스와 연동할 수 있습니다
평가(Evaluation): “좋은 에이전트”인지 판단하기
관측성이 트레이스를 수집해 두면, 평가는 그 트레이스를 입력으로 받아 에이전트의 품질을 검증합니다.
왜 에이전트 평가가 특별히 어려운가
단일 LLM 호출의 평가는 비교적 명확합니다. 입력과 출력이라는 한 쌍을 놓고 정확한가, 유용한가, 안전한가를 보면 됩니다. 하지만 에이전트의 평가는 그보다 복잡합니다.
- 궤적(Trajectory) 평가: 에이전트가 최종적으로 옳은 답을 냈더라도, 그 과정에서 불필요한 도구를 다섯 번 호출했다면 비효율적입니다. 반대로 답은 틀렸지만 추론 경로는 합리적이었을 수도 있습니다. 그래서 “정답을 맞혔는가”(결과 평가)와 “올바른 경로로 도달했는가”(궤적 평가)를 분리해서 측정해야 합니다.
- 다경로(Multi-path) 문제: 같은 목표에 이르는 도구 호출 순서가 여러 가지일 수 있어, 단순 문자열 일치로는 채점할 수 없습니다. 어떤 경로가 “더 좋은” 것인지의 기준 자체를 명시적으로 정의해야 합니다.
- 평가 기준의 다차원성: “좋은 에이전트”는 단일 지표로 정의되지 않습니다. 정확하지만 느린 에이전트, 빠르지만 가끔 환각이 발생하는 에이전트, 안전하지만 지나치게 보수적인 에이전트 등 어떤 것이 더 좋은 것인지는 비즈니스 맥락에 따라 다릅니다.
어떤 방식으로 평가할 것인가
계층마다 쓰는 채점 도구가 다릅니다.
- 규칙 기반, 코드 기반(deterministic): 정답이 명확한 경우에 씁니다. (도구 호출 성공 여부, 출력 스키마 준수, 특정 값과의 일치 등) 빠르고 저렴하며 재현 가능하지만, “응답이 자연스러운가” 같은 주관적 품질은 잴 수 없습니다.
- LLM-as-a-Judge: 성능이 뛰어난 LLM에게 평가 기준을 주고 에이전트의 응답, 궤적을 채점하게 하는 방식으로, 사람 평가와 상관관계가 높으면서 비용, 속도에서 유리합니다. 다만 판정자 LLM 자체의 편향, 프롬프트에 따른 점수 변동 같은 한계가 있어, 평가 기준을 명확히 고정하고 주기적으로 사람 평가와 교차 검증하는 것이 좋습니다.
- 골든 데이터셋 평가: 사람이 직접 정답, 이상적 궤적을 미리 만들어 둔 골든 데이터셋으로 평가함으로써, 평가의 기준선 역할을 합니다.
AgentCore Evaluation: 관리형 에이전트 평가
AgentCore Evaluation은 위 평가 프레임워크를 완전 관리형 서비스로 제공합니다.
- 빌트인 평가기(Built-in Evaluators): 정확성, 유해성, 환각, 충실성 등 에이전트 품질의 핵심 차원을 즉시 사용할 수 있는 사전 정의된 평가기로 제공합니다.
- 커스텀 평가기: 도메인 특화 평가 기준을 정의할 수 있습니다. 예: “의료 상담 에이전트가 진단 대신 의사 상담을 권유하는가?”, “금융 에이전트가 면책 조항을 포함하는가?”
- LLM-as-a-Judge: 강력한 LLM을 평가자로 사용하여 에이전트 응답의 품질을 자동 판정. 사람 평가와 높은 상관관계를 보이면서 비용, 속도, 확장성에서 유리. 평가 기준(rubric)을 자연어로 정의하면 됩니다.
- 관측성 → 평가 연결: AgentCore Observability에서 수집된 트레이스가 자동으로 평가 파이프라인에 유입. 관측과 평가가 하나의 데이터 흐름으로 연결됩니다.
최적화(Optimization): 평가 결과를 개선 행동으로 바꾸기
평가 후에는 실제 에이전트의 성능을 개선하기 위한 최적화 루프를 만들어야 합니다. 기존에 에이전트를 개선하려면, 엔지니어가 실패한 트레이스를 하나씩 읽고, 문제 패턴을 직접 분석한 뒤, 시스템 프롬프트나 도구 설명을 수동으로 수정하고, 다시 테스트해야 했습니다. 이 과정은 시간이 많이 걸리고, 결과가 주관적이며, 변경 이력 추적이 어렵습니다. AgentCore Optimization은 이 과정을 자동화합니다.
① Recommendations: 프로덕션에서 수집된 에이전트 트레이스와 평가(Evaluator) 결과를 분석하여, 최적화된 시스템 프롬프트와 도구 설명을 자동 생성하여 제안합니다.
② Configuration Bundles: 에이전트의 설정(시스템 프롬프트, 모델 ID, 도구 설명)을 버전 관리합니다.
③ A/B Testing: Recommendations로 생성된 개선안이 실제로 더 나은지를 통제된 실험으로 검증합니다.
연속 개선 루프 (Continuous Improvement Loop)
관측 → 평가 → 최적화가 하나의 파이프라인으로 연결되면 다음과 같이 자동화된 개선 루프가 만들어져, 에이전트가 반복적으로 개선되는 시스템이 완성됩니다.
Figure 4. 연속 개선 루프 (관측 → 평가 → 최적화)
이 사이클을 통해 한 번 만든 에이전트가 그대로 머무는 것이 아니라 지속적으로 개선됩니다. 엔지니어는 매 단계에서 검토, 승인 권한을 유지하면서도, 분석과 제안의 무거운 작업은 시스템이 수행합니다.
AgentOps: 에이전트를 운영하는 프로세스
위와 같은 파운데이션 요소들을 구성한 이후에는 AI 에이전트를 운영하기 위한 AgentOps가 필요합니다.
AgentOps의 필요성 및 정의
DevOps가 코드를 다뤘다면, AgentOps는 자율적으로 행동하는 에이전트 그 자체를 다룹니다. 기존 DevOps는 본질적으로 결정론적, 단일 응답 중심의 시스템을 전제하다 보니, 같은 코드, 같은 입력이면 같은 출력이 나옵니다. 테스트를 통과하면 배포할 수 있고, 문제가 생기면 이전 버전으로 롤백이 가능한 예측 가능한 환경을 바탕으로 합니다.
하지만 에이전트는 요청에 응답하는 것이 아니라 행동하는 시스템으로, 기존 운영 방식만으로는 통제할 수 없습니다. DevOps의 CI/CD, IaC, 모니터링, 로깅 등을 기반으로 에이전트의 자율성을 안전하게 통제하기 위한 영역을 추가한 것이 AgentOps입니다.
DevOps / MLOps / AgentOps 세 가지 Ops에 대한 비교를 보면 차이가 명확합니다.
| 관점 | DevOps | MLOps | AgentOps |
| 배포 대상 | 결정적 코드 | 비결정적 모델 | 비결정적 모델 + 도구 + 추론 로직 |
| 테스트 | 단위/통합/E2E | 정확도/공정성 벤치마크 | 궤적 평가, 다차원 품질, 안전성 |
| 모니터링 | 에러율, 레이턴시 | 데이터 드리프트, 모델 성능 | 행동 드리프트, 도구 실패, 가드레일 위반 |
| 롤백 | 이전 버전 재배포 | 이전 모델 재배포 | 프롬프트, 모델, 도구, 가드레일 각각 또는 조합 롤백 |
| 신뢰성 | 코드 리뷰 | 모델 카드, 바이어스 테스트 | 가드레일, human-in-the-loop, 행동 감사 |
한마디로 정의하면, AgentOps는 “AI 에이전트를 안전하고 효율적으로 운영하기 위한 종합적인 프로세스” 입니다.
AgentOps 라이프사이클: 6단계 운영 루프
AgentOps는 6단계로 구성되며 순환하는 구조입니다.
Figure 5. AgentOps 6단계 라이프사이클
1단계, 빌드(Build): 에이전트를 개발하고 도구를 연결하며 메모리를 설정합니다. 시스템 프롬프트로 역할, 목표를 정의하고, 필요한 도구를 Tool Gateway에 등록하며, 단기/장기 메모리 전략을 설계하고, 멀티 에이전트가 필요하면 위임 경로를 그립니다.
→ 활용 서비스: Strands Agents, AgentCore SDK, AgentCore Gateway, AgentCore Memory
2단계, 거버넌스(Govern): “해도 되는 것”과 “하면 안 되는 것”의 경계를 세웁니다. 입출력 가드레일을 정의, 적용하고, 에이전트별 도구 접근 권한을 최소 권한으로 설정하며, human-in-the-loop 규칙과 데이터 접근 정책을 정하고, Agent Registry에 등록, 승인합니다.
→ 활용 서비스: Bedrock Guardrails, AgentCore Identity, AWS IAM, Agent Registry
3단계, 관측(Observe): 모든 행동을 실시간으로 기록합니다. 트레이스, 메트릭, 로그 수집 파이프라인을 구성하고, 실시간 대시보드와 알람(에러율, 비용 급증, 레이턴시 저하), 감사 로그 보존 정책을 설정합니다.
→ 활용 서비스: AgentCore Observability, CloudWatch, ADOT, X-Ray
4단계, 평가(Evaluate): 수집된 데이터로 품질을 판단합니다. 오프라인용 골든 데이터셋과 온라인용 트래픽 샘플링 규칙을 통해, 에이전트를 프로덕션 배포 전/후로 성능을 평가합니다.
→ 활용 서비스: AgentCore Evaluation, Bedrock Model Evaluation, CloudWatch
5단계, 최적화(Optimize): 발견된 문제를 분석해 개선안을 도출합니다. 실패 패턴을 분석하고, 시스템 프롬프트, few-shot, 도구 설명을 개선하며, 더 적합한 모델을 비교 검토하고, 도구 에러 처리, 성능을 다듬고, 과하거나 느슨한 가드레일을 튜닝합니다.
→ 활용 서비스: Bedrock Prompt 관리, AgentCore Optimization
6단계, 적용(Apply): 최적화된 에이전트를 다시 배포하고, 다시 1단계로 돌아갑니다. 변경사항(프롬프트, 모델, 도구, 가드레일)을 패키징해 카나리/블루·그린으로 점진 릴리스하고, A/B 테스트로 기존 대비 품질을 확인하며, 문제 발견 시 즉시 롤백합니다.
→ 활용 서비스: AgentCore Runtime, CloudFormation/CDK, Agent Registry
예전에는 프롬프트를 일일이 바꿔 가며 직접 테스트해야 했지만, AgentOps를 구성해 두면 이 모든 과정이 자동화됩니다. 이를 통해 “한 번 만든 에이전트가 매주 더 좋아진다”는 개념을 실현합니다.
데모: e-커머스 데이터 분석 에이전트로 보는 관측성, 평가, 최적화
Part 1에서 소개한 e-커머스 데이터 분석 에이전트 데모의 연장선입니다. Part 1에서는 게이트웨이 구성까지(1~4단계)를 다뤘으며, 이번 Part 2에서는 그 위에 구축되는 관측성, 평가, 최적화가 실제로 어떻게 동작하는지 5단계부터 이어서 확인합니다.
5. Observability
Figure 6. 트레이스 목록 및 타임라인 뷰
Observability 화면에서는 각 트레이스에서 에이전트가 에이전틱 루프 중에 어떤 생각을 했고, 어떤 도구를 호출했으며, 어떤 결과를 만들었는지 모든 단계를 타임라인으로 확인할 수 있습니다.
Figure 7. 트레이스 상세 정보 (도구 호출, 토큰 사용량)
단계별로 사용한 모델, 토큰 수, 지연 시간은 물론, 도구 호출에 사용한 파라미터 값과 그 결과까지 들여다볼 수 있습니다. 최종적으로는 사용자–에이전트 간 턴별 대화를 보며, 최종 출력을 만들기까지 거친 중간 과정, 사용한 도구 목록, input/output 토큰 수 등 모든 단계를 확인할 수 있습니다.
Figure 8. 팀별·유저별 비용 추적 대시보드
게이트웨이와 관측성 시스템을 구축하고 나면 팀별, 유저별 비용 추적도 가능해집니다. Cognito 인증을 통해 사용자가 에이전트를 호출하면 세션별 토큰 수를 확인할 수 있고, 특정 기간 동안 한 유저가 얼마나 토큰을 썼는지, 팀별 예산을 잡아 통제하도록 구성할 수 있습니다.
6. Evaluation
Figure 9. 평가 결과 대시보드
관측 데이터를 토대로 LLM-as-a-Judge가 각 세션의 품질을 자동 채점하며, 평가 항목별 점수와 추이를 대시보드로 확인합니다.
7. Optimization
Figure 10. 최적화 및 A/B 테스트 화면
평가 점수를 기반으로 개선된 프롬프트를 추천받고, A/B 테스트로 기존 대비 성능 향상을 검증합니다.
데모 코드
발표에서 시연한 전체 데모는 오픈소스 레퍼런스 구현으로 공개되어 있습니다. AgentCore 기반으로 구현되어 있어, 각자의 목적에 맞게 AgentOps를 구축, 운영하는 데 참고하실 수 있습니다.
- AgentOps Kit (aws-samples): https://github.com/aws-samples/sample-agentic-ai-acceleration-kr/tree/main/projects/agentops-kit
마무리
지금까지 Part 1에서 다룬 게이트웨이 패턴에 이어, Part 2에서는 에이전트를 실제로 운영하기 위한 핵심 요소들을 살펴봤습니다. 정리하면 다음과 같습니다.
- 관측성으로 에이전트의 모든 행동을 파악: 트레이스, 메트릭, 로그라는 세 가지 신호로 에이전트의 추론 궤적과 행동을 빠짐없이 기록하고, 평가 루프로 연결해 품질과 안전성을 지속적으로 검증할 수 있습니다.
- AgentOps로 운영을 체계화: 빌드, 거버넌스, 관측, 평가, 최적화, 적용으로 이어지는 6단계 사이클을 반복하면, 한 번 배포하고 끝나는 에이전트가 아니라 시간이 갈수록 더 좋아지는 에이전트를 만들 수 있습니다.
- 파운데이션 위의 자동화된 개선 루프: Part 1의 게이트웨이와 Part 2의 관측성·평가·최적화가 결합되면, 엔지니어의 수동 분석 없이도 에이전트가 반복적으로 개선되는 시스템이 완성됩니다.
프로덕션은 목적지가 아니라 여정입니다. PoC에 머무르지 않고 에이전틱 AI를 프로덕션에서 제대로 활용하는 그 여정에, Amazon Bedrock과 Amazon Bedrock AgentCore가 든든한 파운데이션이 되어 줄 것입니다. 이번 시리즈에서 소개한 게이트웨이, 관측성, 평가, AgentOps 패턴이 여러분의 에이전틱 AI 프로덕션 여정에 실질적인 참고가 되길 바랍니다.