에이전트를 구축하고 배포하면 새로운 문제가 시작됩니다. 에이전트가 검색 오류를 범하거나 비효율적인 경로를 택하면, 사용자를 혼란시키고, 레이턴시를 높이며, 비용을 급증시킬 수 있습니다. 그럼에도 대부분의 팀은 여전히 프롬프트를 수정하고 바로 배포하는 방식으로 에이전트를 관리하고 있습니다. 에이전트의 복잡도가 높아질수록, 내부를 체계적으로 관찰할 수 있는 수단이 필요해집니다.
이 글에서는 Arize AI의 'AI Agents & Assistants Handbook' 시리즈 중 Agent Observability and Tracing 편을 바탕으로, 에이전트 옵저버빌리티가 무엇이고, 트레이싱은 어떻게 작동하며, 멀티에이전트 환경에서의 관찰과 자기 개선 플로우까지 정리합니다.
☑️에이전트 옵저버빌리티(Agent Observability)란 무엇인가
에이전트 옵저버빌리티의 원칙은 다른 형태의 옵저버빌리티와 동일합니다. 에이전트의 내부 작동을 가시적이고, 추적 가능하며, 이해할 수 있는 상태로 만드는 것입니다. 목표는 에이전트를 "유리 상자(Glass Box)"로 만드는 것입니다.
에이전트 옵저버빌리티를 통해 확인할 수 있는 것은 다음과 같습니다.
이것이 왜 중요한지는 명확합니다. 미세한 실패가 눈덩이처럼 커질 수 있기 때문입니다. 검색 오류를 범하거나 비효율적인 경로를 택한 에이전트는 사용자를 혼란시키고, 레이턴시를 높이며, 프로덕션에서 비용을 급증시킬 수 있습니다. 에이전트 옵저버빌리티는 실제로 작동하는 에이전트를 만들기 위한 필수 요소입니다.
☑️에이전트 평가(Agent Evaluation)의 두 가지 접근법
에이전트가 무엇을 하고 있는지 볼 수 있게 되면, 다음 단계는 얼마나 잘 수행하고 있는지를 측정하는 것입니다. 에이전트는 여러 단계를 거치고 복잡한 경로를 따르기 때문에, 정적인 테스트 케이스만으로는 충분하지 않습니다.
Arize AI는 에이전트 평가를 위해 크게 두 가지 방법을 제시합니다.
LLM-as-a-Judge
별도의 LLM에게 프롬프트를 통해 에이전트의 출력과 경로를 평가하도록 하는 방식입니다. 인간 피드백이나 사용자 피드백은 비용이 높고 확보하기 어려운 경우가 많기 때문에, LLM-as-a-Judge는 효과적인 대안이 됩니다.
적용 과정은 다음과 같습니다. 먼저 측정하고자 하는 항목(정확성, 도구 사용 정확도 등)을 정의합니다. 다음으로, LLM이 에이전트의 다단계 출력을 어떻게 평가할지를 명확하게 지시하는 평가 프롬프트를 작성합니다. 그리고 이 평가를 에이전트 실행 결과 전체에 걸쳐 수행하여, 수동 라벨링 없이 성능을 테스트하고 개선합니다. 대표적인 예가 에이전트 경로 평가(Agent Trajectory Evaluation)입니다. LLM-as-a-Judge를 활용하여 에이전트가 작업을 해결하기 위해 수행한 도구 호출의 전체 시퀀스를 평가합니다. 이를 통해 비용과 레이턴시를 증가시키는 루프나 불필요한 단계를 포착하여, 에이전트가 기대되는 최적 경로("골든 패스")를 따르고 있는지 확인할 수 있습니다.
Arize AI는 경로 평가 외에도 사전 테스트된 LLM-as-a-Judge 평가 템플릿을 제공합니다. 에이전트 계획(Agent Planning), 도구 호출(Agent Tool Calling), 도구 선택(Agent Tool Selection), 매개변수 추출(Agent Parameter Extraction), 자기 반성(Agent Reflection) 등의 템플릿이 있습니다.
코드 기반 평가 (Code Evals)
평가 기준이 프로그래밍으로 검증할 수 있는 객관적 기준에 기반할 때는 코드 기반 평가가 적합합니다. 출력이 정확한 기준을 충족하는지 빠르고 안정적으로 확인하는 규칙 기반 테스트입니다.
코드 기반 평가의 대표적인 예가 에이전트의 경로 수렴도(Path Convergence) 측정입니다. 에이전트가 여러 단계를 거쳐 답에 도달할 때, 일관된 경로를 따르고 있는지, 불필요한 루프에 빠지지 않는지를 확인하는 것입니다. 수렴도를 측정하는 방법은 다음과 같습니다. 유사한 쿼리 세트에 에이전트를 실행하고, 각 실행에서 소요된 단계 수를 기록합니다. 그런 다음, 각 쿼리에 대한 최소 단계 수와 실제 실행 단계 수의 비율을 평균하여 수렴도 점수를 계산합니다. 이 점수는 0에서 1 사이의 값으로, 에이전트가 해당 유형의 쿼리에 대해 최적 경로를 얼마나 자주 따르는지, 그리고 차선 경로를 택할 때 얼마나 벗어나는지를 보여줍니다. 다만, 최적 경로는 에이전트의 가장 짧은 실행을 기준으로 계산되므로, 모든 실행이 차선 경로를 택하는 경우는 이 방법으로 감지되지 않습니다.
LLM-as-a-Judge가 전체적인 그림을, 코드 기반 평가가 세부적인 디테일을 담당합니다. 두 가지를 결합하면 에이전트의 실제 상태를 360도로 파악할 수 있습니다. 중요한 것은 평가 방법 자체가 실제 데이터(Ground Truth)에 대해 엄격하게 테스트되어, 프로덕션 환경에서도 일반화할 수 있어야 한다는 점입니다.
☑️멀티에이전트 시스템의 옵저버빌리티
멀티에이전트 트레이싱
멀티에이전트 트레이싱은 AI 시스템 내 여러 에이전트 간의 상호작용을 체계적으로 추적하고 시각화하는 것입니다. 기존의 단일 에이전트 디버깅과 달리, 멀티에이전트 트레이싱은 에이전트들이 어떻게 상호작용하고, 작업을 위임하며, 도구를 실시간으로 활용하는지를 보여줍니다. 인터랙티브 플로우차트를 통해 이러한 상호작용을 시각화하면, 엔지니어가 에이전트 간 커뮤니케이션과 의사결정을 단계별로 이해할 수 있습니다. 명확한 트레이싱을 통해 논리적 단절, 병목, 비효율적인 도구 사용을 식별하고, 더 효과적인 디버깅과 최적화가 가능해집니다.
프레임워크 간 통합 옵저버빌리티
멀티에이전트 시스템을 확장하려면, 서로 다른 에이전트 기술을 아우르는 통합 옵저버빌리티 프레임워크가 필요합니다. 옵저버빌리티 도구는 Agno, Autogen, CrewAI, LangGraph, SmolAgents 등의 프레임워크와 별도의 커스텀 구현 없이 원활하게 통합되어야 합니다. 표준화된 옵저버빌리티는 일관된 인사이트를 제공하고, 문제 해결을 가속화하며, 다양한 에이전트 구성과 아키텍처에 걸쳐 디버깅을 간소화합니다.
☑️세션 수준 옵저버빌리티: 컨텍스트가 핵심
왜 세션 수준이 중요한가
세션 수준 옵저버빌리티는 개별 상호작용을 넘어, 전체 대화 또는 작업 기반 세션에 걸쳐 에이전트의 성능을 평가합니다. 이 평가는 네 가지 측면을 다룹니다.
세션 수준 옵저버빌리티는 복잡한 멀티턴 작업을 수행하는 에이전트의 신뢰성과 컨텍스트 인식 능력을 보장합니다.
세션 수준 평가의 모범 사례
효과적인 세션 수준 평가를 위해서는 사전 계획이 필요합니다. 평가를 시작하기 전에 일관성, 컨텍스트 유지, 목표 달성, 대화 진행에 대한 기준을 먼저 정의해야 합니다. 평가 프롬프트는 모델이나 LLM이 이러한 측면을 어떻게 평가할지를 명확하게 지시해야 합니다. 자동화된 방법(예: LLM-as-a-Judge)과 타겟팅된 인간 리뷰를 결합하면 종합적인 평가가 가능합니다. 진화하는 상호작용과 에이전트 역량에 맞추어 평가 기준을 정기적으로 업데이트하는 것이 지속적인 개선을 유지하는 핵심입니다.
☑️고급 개념
MCP 클라이언트 및 서버 트레이싱
MCP는 Anthropic이 개발한 Model Context Protocol로, LLM을 외부 데이터 소스 및 도구에 안전하게 연결하기 위한 오픈 표준입니다.
기존의 가시성 문제: 이전에는 개발자가 클라이언트 측(LLM 호출과 도구 선택)이나 MCP 서버 측을 각각 별도로만 추적할 수 있었습니다. 클라이언트가 MCP 서버에 호출을 보내면, 그 이후에 무슨 일이 일어나는지에 대한 가시성이 사라졌습니다.
컨텍스트 전파(Context Propagation): openinference-instrumentation-mcp는 이 격차를 해소합니다. OpenTelemetry를 사용하여 클라이언트와 서버 양쪽을 자동으로 계측하고, MCP 클라이언트와 서버 간에 OpenTelemetry 컨텍스트를 전파하여 하나의 통합 트레이스로 만듭니다. 이를 통해 다음이 가능해집니다.
이는 MCP 트레이싱의 초기 사례 중 하나이며, 디버깅, 최적화, 가시성 확보를 크게 용이하게 만들 것으로 기대됩니다.
음성 / 멀티모달 옵저버빌리티
멀티모달은 에이전트 옵저버빌리티에 새로운 도전과 기회를 가져옵니다. 순수 텍스트 워크플로우와 달리, 이러한 에이전트는 음성, 이미지 등 다양한 유형의 데이터를 처리합니다. 멀티모달 에이전트를 트레이싱하면, 트랜스크립션(음성→텍스트 변환), 이미지 임베딩, 도구 호출을 통합된 뷰에서 정렬할 수 있어, 잘못된 트랜스크립션 같은 까다로운 오해석을 디버깅하기 쉬워집니다. 또한 트레이싱을 통해 모달리티별 레이턴시를 확인할 수 있는데, 음성과 이미지 처리는 사용자 경험을 빠르게 저하시킬 수 있는 숨겨진 병목을 만들 수 있기 때문에 이 점이 중요합니다. 멀티모달 에이전트의 평가는 에이전트가 입력을 올바르게 이해하고 응답했는지를 확인하는 데 중점을 둡니다. LLM-as-a-Judge를 활용하여 이미지 캡션이 업로드된 이미지와 일치하는지, 트랜스크립션된 음성 명령이 올바른 도구 호출을 트리거하는지를 평가할 수 있습니다. 코드 기반 검사는 생성된 캡션에서 필수 객체가 누락되었는지, 이미지에서 추출된 구조화 데이터와 응답이 일치하는지와 같은 결정적 이슈를 잡아내는 추가 레이어를 제공합니다.
☑️궁극적 목표: 자기 개선 플로우
옵저버빌리티의 역할은 문제를 포착하는 데 그치지 않습니다. 에이전트를 체계적으로, 시간이 지나면서 더 나아지도록 만드는 것이기도 합니다. 구조화된 트레이스와 평가가 갖춰지면, 실패의 패턴을 발견하고 어떤 프롬프트나 도구 전략이 가장 잘 작동하는지 식별할 수 있습니다.
먼저 이상치 트레이스와 낮은 점수의 평가 결과를 검토하여, 에이전트가 가장 어려움을 겪는 지점을 파악합니다. 그 실패의 원인을 파고듭니다. 관련 없는 청크를 반환하는 검색 오류인지, 프롬프트가 LLM을 혼란시키는 것인지. 이러한 인사이트를 활용하여 가장 중요한 지점에서 프롬프트를 개선하고, 도구 호출 로직을 조정하며, 데이터 파이프라인을 보완합니다. 개선이 이루어지면, 과거 데이터에 대해 평가를 다시 실행하여 실제 워크로드 전체에 걸쳐 변경 사항의 진정한 영향을 측정합니다. 이를 통해 진전을 확인하고, 수동 검사에서 빠져나가는 성능 회귀를 방지합니다. 개선 플로우는 자동화를 포함할 수도 있습니다. 자동화된 프롬프트 최적화를 통해, 라벨링된 데이터셋과 피드백 루프를 활용하여 새로운 프롬프트 버전을 자동으로 생성하고 테스트할 수 있습니다. 끝없는 시행착오 대신, 유스케이스와 데이터가 변화하면서 프롬프트가 함께 진화할 수 있습니다.
자기 개선 에이전트는 이를 한 단계 더 나아갑니다. 낮은 점수의 트레이스와 실패한 평가를 파이프라인에 다시 투입함으로써, 에이전트가 자신의 실수로부터 학습합니다. 에이전트가 정적인 시스템에 머무르지 않고, 사용자에 맞춰 적응하고, 확장될수록 더 정확해지는 살아 있는 시스템이 됩니다.
☑️마치며
에이전트 옵저버빌리티는 단순한 모니터링이 아닙니다. 에이전트의 내부를 유리 상자처럼 투명하게 만들어, 무엇을 보고, 무엇을 결정하고, 왜 그런 경로를 택했는지를 이해할 수 있게 하는 것입니다. 멀티에이전트 시스템, MCP 트레이싱, 세션 수준 관찰, 멀티모달 처리 등 에이전트의 복잡도가 증가할수록 옵저버빌리티의 중요성은 더욱 커집니다. 그런데 에이전트가 무엇을 하고 있는지 보는 것만으로는 충분하지 않습니다. 에이전트의 각 구성요소가 올바르게 작동하는지, 전체 경로가 효율적인지를 체계적으로 평가해야 합니다.
다음 편에서는 에이전트 평가 방법론을 상세히 다룹니다. 라우터 평가, 스킬 평가, 경로 평가, 테스트 케이스 구축, 그리고 개발과 프로덕션을 연결하는 순환적 평가 프로세스를 살펴보겠습니다.
