에이전틱 AI(Agentic AI)의 관측성(Observability)
전통적인 마이크로서비스는 관측성 문제를 해결했습니다. 트레이스(Trace)는 경로를 보여주고, 메트릭(Metric)은 지연 시간을 보여주며, 로그(Log)는 상황을 설명합니다.
에이전틱 AI는 이 모델을 깨뜨립니다.
사용자의 질문 하나가 가드레일(guardrails), 세션 읽기, 다수의 LLM 호출, 웹 검색, 그리고 추론 루프(reasoning loops)를 트리거할 수 있습니다. 실패는 종종 미묘하게 나타납니다. 도구가 느려질 수도 있고, 컨텍스트 윈도우(context window)가 너무 커질 수도 있으며, 모델이 에러를 반환하지 않고도 부하 상황에서 성능이 저하될 수도 있습니다.
최근 저는 이러한 시스템을 어떻게 관측할 수 있는지 테스트하기 위해 OpenTelemetry NBA Agent 데모를 실행해 보았습니다. 신뢰할 수 있는 AI 에이전트를 구축하며 배운 점들을 공유합니다.
에이전트 관측성의 세 가지 기둥
• 트레이스는 유닛 테스트보다 가치 있습니다. 동일한 프롬프트라도 실행할 때마다 다른 답변이 나올 수 있습니다. 단순히 최종 텍스트만 보는 것이 아니라, 에이전트가 거쳐온 경로를 반드시 확인해야 합니다.
• 의도(intent)와 행동(action)을 연관시키세요. 날씨 질문에는 한 단어 답변이 적절할 수 있지만, 금융 조언에는 부적절합니다. 가드레일 결정과 도구 사용을 사용자의 의도와 연결해야 합니다.
• 조기에 베이스라인(baseline)을 설정하세요. 모델 업데이트와 API 변경은 동작을 변화시킵니다. 배포 전 메트릭을 확보해야 상황이 개선되었는지 악화되었는지 알 수 있습니다.
측정해야 할 항목
단순히 모델 호출만 모니터링해서는 안 됩니다. 전체 생태계에 계측(instrumentation)을 적용해야 합니다.
1. 모델 계층 (The Model Layer)
작업 이름, 제공자 상세 정보, 토큰 사용량을 추적하세요. 실행 시간과 종료 사유(finish reasons)를 모니터링하세요.
2. 도구 및 MCP 서버 (Tools and MCP Servers)
도구를 마이크로서비스처럼 취급하세요. 지연 시간, 성공률, 인자(arguments)를 추적하세요. 에이전트가 느리다면 LLM이 아니라 외부 API가 느린 경우가 많습니다.
3. 가드레일 (Guardrails)
가드레일이 얼마나 자주 작동하는지, 어떤 주제로 인해 작동하는지 측정하세요. 이는 경영진에게 안전 계층(safety layers) 도입 비용의 정당성을 설명하는 데 도움이 됩니다.
4. 메모리 및 세션 (Memory and Sessions)
컨텍스트 비대화(context bloat)를 주의 깊게 살펴보세요. 턴당 입력 토큰 수가 증가하면 비용이 급격히 상승할 수 있습니다.
대시보드를 위한 핵심 메트릭
• 지연 시간(Latency): 첫 번째 토큰 생성 시간(TTFT) 및 엔드 투 엔드(end-to-end) 턴 지연 시간. • 비용(Cost): 총 토큰 수 및 세션당 예상 지출액. • 신뢰성(Reliability): 스팬 종류(span kind)별 에러율 (LLM vs 도구 vs HTTP). • 동작(Behavior): 에이전트 루프 깊이 및 도구 호출 빈도.
에이전틱 AI는 플래너(planner)가 확률적으로 작동하는 분산 시스템입니다. 에이전트의 전체 루프를 볼 수 없다면, 이를 프로덕션 환경에서 운영할 수 없습니다.
Optional learning community: https://t.me/GyaanSetuAi