Microsoft의 Foundry 팀이 에이전트 프레임워크에 OpenTelemetry 기반 트레이싱을 추가하여, 개발자가 이기종 LLM 기반 에이전트 간의 엔드 투 엔드(end-to-end) 실행 과정을 확인할 수 있는 방법을 제공합니다.

멀티 에이전트 시스템에 로그 파일 그 이상이 필요한 이유

전형적인 AI 기반 사고 대응 훈련에서는 여러 전문 에이전트를 조율하는 커맨더(commander) 에이전트를 사용합니다. 하나는 로그를 파싱하고, 다른 하나는 메트릭 이상 징후를 감지하며, 세 번째는 증상을 런북(runbook)과 매칭하고, 라우터는 각 하위 작업에 가장 적합한 언어 모델을 선택합니다. 각 전문 에이전트는 "gpt-5-mini" 변형 모델과 같이 서로 다른 모델을 호출하고 자체 도구를 실행할 수 있습니다. 문제가 발생하면 엔지니어들은 각 구성 요소가 무엇을 했는지는 보여주지만, 각 조각이 어떻게 맞물려 돌아가는지는 보여주지 못하는 개별적인 로그들만 살펴보게 됩니다.

통합된 트레이스(trace)가 없다면, 근본 원인은 에이전트 간의 데이터 전달 과정(hand-off) 속에 숨어버립니다. 커맨더가 보낸 요청을 로그 리더가 올바르게 처리했더라도, 메트릭 전문 에이전트가 데이터를 잘못 해석하여 잘못된 런북을 제안할 수 있습니다. 이러한 체인을 수동으로 디버깅하는 것은 시간이 많이 걸릴 뿐만 아니라 오류를 유발하기 쉽습니다.

OpenTelemetry가 워크플로우를 하나로 엮는 방법

OpenTelemetry는 trace와 span이라는 두 가지 핵심 개념을 정의합니다. Trace는 요청이 들어온 시점부터 최종 응답까지를 추적하는 고유 식별자입니다. Span은 해당 trace 내에서 언어 모델 호출이나 도구 실행과 같은 단일 작업을 기록합니다.

에이전트가 요청을 받으면 요청의 메타데이터에서 들어오는 Trace ID를 가져와 동일한 ID를 상속받는 자식 span을 생성합니다. 자식 span은 시작 시간, 지속 시간, 속성(모델 이름, 사용된 도구) 및 모든 오류를 기록합니다. 이 프로세스는 모든 하위(downstream) 에이전트에 대해 반복되며, 전체 작업의 논리적 흐름을 반영하는 트리 구조를 구축합니다.

OpenTelemetry는 또한 사용자 정의 키-값 쌍을 위한 경량 캐리어인 Baggage를 지원합니다. Trace의 최상단에서 Baggage에 "drill-id"나 기타 비즈니스 컨텍스트를 첨부하면, 모든 하위 span이 해당 식별자를 자동으로 상속받습니다. 그런 다음 span 프로세서가 Baggage를 일반 속성으로 승격시켜, 특정 사고 훈련에 속하는 모든 span을 쉽게 쿼리할 수 있게 해줍니다.

새로운 트레이싱 인터페이스의 모습

계측(instrumentation)이 완료되면, Azure Monitor(또는 기타 OpenTelemetry 호환 백엔드)는 다음과 같은 시각적 계층 구조를 렌더링합니다:

  • 에이전트 이름 / ID – 어떤 구성 요소가 작업을 수행했는지 보여줍니다.
  • 도구 사용 – 어떤 외부 서비스나 함수가 호출되었는지 기록합니다.
  • 모델 버전 – 사용된 정확한 LLM을 기록하며, 모델 업그레이드 후 성능 저하(regression)를 추적하는 데 유용합니다.
  • 토큰 소비량 – 모델로 전송되고 모델로부터 수신된 토큰 수를 캡처하여 팀의 비용 관리를 돕습니다.
  • 지연 시간 / 지속 시간 – 모델 추론이나 도구 I/O 중 어디에서 병목 현상이 발생하는지 강조합니다.

사고 훈련 예시에서 커맨더의 루트 span은 각 전문 에이전트를 위한 자식 span을 생성하고, 각 전문 에이전트는 모델 호출을 위한 추가 자식 span을 생성합니다. 노드를 클릭하면 전체 속성 세트가 표시되므로, 엔지니어는 각 작업의 세부 정보를 즉시 확인할 수 있습니다.

AI 중심 운영에서의 중요성

  • 근본 원인 분석 속도 – 팀은 오류를 발생시킨 정확한 span까지 실패를 추적하여 평균 복구 시간(MTTR)을 단축할 수 있습니다.
  • 비용 가시성 – 토큰 수가 지연 시간과 함께 표시되어, 재무 팀이 클라우드 비용이 급증하기 전에 과도한 사용량을 감지할 수 있습니다.
  • 성능 튜닝 – 에이전트 간의 높은 지연 시간을 보이는 span을 통해 캐싱, 모델 선택 또는 도구 재설계가 처리량을 높일 수 있는 지점을 파악할 수 있습니다.

향후 주목할 점

LangChain, OpenAI SDK 또는 기타 오케스트레이션 레이어를 기반으로 구축된 프로젝트는 GenAI를 위한 동일한 시맨틱 컨벤션(semantic conventions)을 채택할 수 있으며, 이는 클라우드 제공업체와 온프레미스 배포를 가로질러 흐르는 트레이스를 위한 길을 열어줍니다.

기업은 에이전트에서 OpenTelemetry SDK를 활성화하고 데이터를 Azure Monitor 또는 오픈 소스 수집기(collector)로 보내기만 하면 됩니다.

요약

OpenTelemetry는 흩어져 있는 로그를 일관된 이야기로 바꿔주는, 멀티 에이전트 AI 시스템에 꼭 필요했던 '접착제' 역할을 합니다. 이기종 LLM, 라우터 및 도구 호출 전반에 걸쳐 단일 Trace ID를 전파함으로써, 개발자는 트레이싱 인프라를 새로 구축할 필요 없이 실패 지점을 찾고, 비용을 모니터링하며, 성능을 최적화할 수 있습니다.