Microsoft Foundry에서 첫 추적부터 프로덕션 모니터링까지 AI 에이전트 추적 및 평가 방법

Microsoft Foundry는 에이전트 관측 가능성(observability)을 세 가지 기능으로 분리하며, 각 기능은 서로 다른 질문에 답합니다. 트레이싱(Tracing)은 에이전트가 실행 중에 무엇을 했는지 보여주고, 평가(evaluation)는 사용자가 선택한 기준에 따라 답변의 품질이 얼마나 좋았는지 점수를 매기며, 모니터링(monitoring)은 에이전트가 사용자 앞에 놓인 후에도 이 두 가지 질문을 계속해서 던집니다. 본 게시물에서는 일반적으로 필요할 순서대로 공식 Python 샘플을 사용하여 이 세 가지 기능을 살펴보고, Microsoft가 어떤 부분을 일반 사용 가능(generally available)으로, 어떤 부분을 미리 보기(preview)로 분류했는지 알려줍니다. 왜냐하면 그 라벨이 각 구성 요소가 가질 수 있는 중요도를 결정하기 때문입니다.

일반 사용 가능 여부 및 현황

프롬프트 에이전트와 호스팅된 에이전트에 대해서는 트레이싱이 일반 사용 가능하지만, 워크플로우 에이전트(workflow agents)와 외부 에이전트(external agents)는 아직 미리 보기 상태입니다. Microsoft의 2026년 6월 3일 Build 발표에 따르면 트레이싱과 평가는 봄에 일반 사용 가능 단계에 도달했다고 하지만, 참고 페이지들에는 여전히 개별 요소들에 미리 보기 라벨이 붙어 있습니다. 에이전트 평가기(agent evaluators) 페이지에서 Task Adherence, Task Completion, Intent Resolution, Customer Satisfaction, Output Quality, Tool Use Quality는 미리 보기로 라벨링되어 있는 반면, Tool Call Accuracy와 같은 도구 평가기(tool evaluators)는 어떠한 라벨도 가지고 있지 않습니다. 모니터링 페이지에서는 에이전트 메트릭(agent metrics), 반복 평가(recurring evaluations), 레드팀 스캔(red team scans) 및 경고(alerts)가 미리 보기로 라벨링되어 있으며, 해당 페이지에는 Microsoft가 이 미리 보기 항목들을 프로덕션 워크로드에 권장하지 않는다고 명시되어 있습니다. 평가를 위한 GitHub Action 역시 미리 보기 상태입니다. 저는 2026년 10월 14일에 이러한 라벨을 확인했으며, 이들은 빠르게 변경되므로, 어떤 것을 기반으로 구축하기 전에 연결된 페이지들을 다시 열어보는 것이 좋습니다.

1단계: Application Insights 연결 및 첫 번째 트레이스 읽기

프롬프트 에이전트와 호스팅된 에이전트에 대한 추적은 서버 측에서 작동하므로 코드에 아무것도 변경할 필요가 없습니다. New Foundry 토글을 켠 후, 프로젝트를 열고 Agents로 이동하여 Traces를 선택한 다음 Connect를 선택하고 기존 Application Insights 리소스를 연결하거나 새로 만듭니다. 이 시점부터 Foundry에서 호스팅되는 에이전트의 실행은 OpenTelemetry를 통해 기록되며, 여기에는 모델 호출, 도구 호출(tool invocations), 에이전트가 내린 결정, 그리고 다른 서비스에 대한 의존성 등이 포함됩니다 ( 관측 가능성 개요 참조).

트레이스를 읽으려면 연결된 Application Insights 리소스에 대한 Log Analytics Reader 역할과, 기본 Log Analytics 테이블이 보호되는 경우 Privileged Monitoring Data Reader가 필요합니다. 에이전트를 한 번 실행한 후에는 Traces 탭에서 지난 90일간의 트레이스를 검색, 필터링 및 정렬할 수 있고, 하나를 열어 스팬(span)을 단계별로 추적하거나 Response ID 또는 Trace ID로 검색하여 대화 기록(Conversation ID)을 열고 히스토리, 토큰 카운트, 실행 단계, 도구 호출, 입력 및 출력을 확인할 수 있습니다. 아무것도 표시되지 않으면, 설정 페이지에서 몇 분 기다린 후 새로고침하는 것이 좋으며, 이후 문제 해결 섹션으로 이동하기 전에 확인해 보세요. 해당 페이지에는 또한 azure-core-tracing-opentelemetry를 사용한 클라이언트 측 트레이싱도 다루는데, 이는 선택 사항이며 자체 애플리케이션 코드용입니다.

2단계: 소규모 데이터셋으로 에이전트 평가하기

트레이스(trace)는 무엇이 일어났는지 알려주지만, 그 답변이 좋았는지 여부는 알려주지 못하며, 이것이 바로 평가(evaluation)의 역할입니다. 아래 샘플은 AI 에이전트 평가 방법에 있는 공식 페이지를 따르지만, 루브릭 생성(rubric generation) 단계는 제거하여 Foundry와 함께 제공되는 평가기만 사용합니다. 프로젝트에서 Foundry 사용자 역할(Foundry User role)이 필요하며, 이는 Microsoft가 역할 ID를 변경하지 않고 Azure AI 사용자(Azure AI User)로 이름을 바꾼 것입니다. 또한 모델을 사용하는 평가기의 심판 역할을 하는 채팅 완료 모델 배포(chat completion model deployment)가 필요합니다.

해당 페이지는 azure-ai-projects 2.4.0 이상을 요청하지만, 동일한 문서의 다른 페이지들은 더 낮은 최소 버전을 나열하고 있으므로 최신 릴리스를 설치하는 것이 안전합니다.

pip install "azure-ai-projects>=2.4.0" azure-identity

환경 변수 AZURE_AI_PROJECT_ENDPOINT와 AZURE_AI_MODEL_DEPLOYMENT_NAME을 설정한 다음, 각 줄에 query 필드를 포함하는 test-queries.jsonl이라는 JSONL 파일을 생성합니다. 이 세 줄은 예시 질문일 뿐이므로, 에이전트가 받게 될 질문으로 교체해야 합니다.

{"query": "Azure 리전과 가용 영역(availability zone)의 차이점은 무엇인가요?"}
{"query": "가상 머신 대신 Azure Functions를 사용해야 하는 경우는 언제인가요?"}
{"query": "스토리지 계정이 공개적으로 접근 가능한 것을 막으려면 어떻게 해야 하나요?"}

스크립트의 첫 번째 부분은 클라이언트를 생성하고 데이터셋을 프로젝트에 업로드합니다.

import os
import time

...

두 번째 부분은 측정할 내용을 정의하고 평가를 생성합니다. 일관성(Coherence)은 심판 배포(judge deployment)에 의해 점수가 매겨지며, 폭력성(Violence)은 위험 및 안전 그룹(risk and safety group)에서 제공되는데, 공식 샘플에서는 이 부분이 심판 배포 없이 실행됩니다.

from azure.ai.projects.models import TestingCriterionAzureAIEvaluator
from openai.types.eval_create_params import DataSourceConfigCustom

...

세 번째 부분은 실행을 시작합니다. azure_ai_target_completions 소스를 사용하면 Foundry는 대상에 지정된 에이전트에게 모든 쿼리를 보내고, 그 결과로 받은 답변들을 평가합니다. 그래서 위의 매핑들이 sample.output_text에서 읽어오는 것입니다.

eval_run = client.evals.runs.create(
    eval_id=evaluation.id,
    name="Agent Evaluation Run",
...

응답에서, result_counts는 전체, 통과(passed), 실패(failed), 오류(errored) 행의 수를 제공하고, per_testing_criteria_results는 동일한 숫자를 평가자별로 세분화합니다. 그리고 각 행은 모든 평가자에 대해 score, label, reason, threshold, passed 플래그를 가지고 있습니다. report_url을 열면 Foundry 포털에서 동일한 결과를 볼 수 있으며, 여기서는 또한 'Evaluations' 탭 아래에 표시됩니다. 그리고 reason 필드는 행이 실패했을 때 제가 읽기 시작할 곳입니다.

만약 에이전트가 도구(tools)를 호출한다면, 도구 사용 평가자들(tool use evaluators)을 다음에 추가할 가치가 있습니다. Tool Call Accuracy는 에이전트가 올바른 매개변수와 중복 없이 정확한 호출을 했는지 확인하고, Tool Selection은 필요한 도구를 선택했고 불필요한 도구는 선택하지 않았는지 확인하며, Tool Input Accuracy는 매개변수를 확인하고, Tool Output Utilization은 에이전트가 결과를 올바르게 사용했는지 확인하며, Tool Call Success는 호출이 기술적 오류 없이 끝났는지 확인합니다. 이 중 네 가지는 tool_definitions를 입력으로 받으며, Tool Call Accuracy는 1부터 5까지의 척도로 점수를 매긴 후 임계값(threshold)을 통과 또는 실패로 만듭니다.

비용 및 제한 사항

위에서 사용된 Violence 평가기(evaluator)를 포함하는 위험 및 안전 평가(Risk and safety evaluations), 그리고 에이전트 플레이그라운드 평가(agents playground evaluations)는 사용량 기반으로 청구되며, 플레이그라운드 평가는 모든 Foundry 프로젝트에 기본적으로 활성화되어 있습니다. 이를 끄려면 플레이그라운드의 메트릭 선택기에서 모든 평가기를 지우십시오. 또한 일부 기능은 지역 제한이 있으므로, 루브릭 생성(rubric generation), 합성 및 트레이스 기반 데이터셋 생성(synthetic and trace based dataset creation), 그리고 위험 및 안전 평가기(risk and safety evaluators)의 경우, 프로젝트에 샘플을 실행하기 전에 지원되는 지역을 확인하십시오. 모니터링 데이터 자체는 연결된 Application Insights 리소스에 저장되므로, 그 보존 및 청구는 해당 리소스를 구성한 방식에 따릅니다.

3단계: 출시 후에도 평가 유지하기

모니터링 페이지는 에이전트가 사용자에게 서비스를 제공하는 동안 샘플 트래픽에 대해 평가를 실행하는 지속적인 평가(continuous evaluation)를 설명합니다. 아래 코드는 azure_ai_source로 평가를 생성하고, 이름 지정된 에이전트의 응답이 완료될 때마다 해당 평가를 실행하는 규칙을 첨부합니다. 지속적인 평가 규칙이 실행되려면 프로젝트 관리 ID에 Foundry 사용자 역할(Foundry User role)이 필요하며, 이 규칙은 max_hourly_runs로 제한됩니다. 샘플에서는 이를 100으로 설정했으며, Microsoft는 이것을 시간당 기본 제한으로 문서화하고 있습니다. 한도에 도달하면 다음 시간이 되거나 값을 높일 때까지 추가 실행은 건너뜁니다.

import os

from azure.identity import DefaultAzureCredential
...

결과를 확인하려면 Foundry 포털에서 에이전트를 열고 'Monitor(모니터링)'를 선택하십시오. 대시보드는 사용자가 지정한 시간 범위에 대한 토큰 사용량, 지연 시간(latency), 실행 성공률, 평가 메트릭 및 레드팀(red teaming) 결과를 보여주며, 문서에는 이를 해석하기 위한 두 가지 시작점을 제공합니다. 10초가 넘는 지연 시간은 모델 스로틀링(model throttling), 복잡한 도구 호출 또는 네트워크 문제를 나타낼 수 있으며, 실행 성공률이 95% 미만인 경우 실패한 실행에 대한 조사가 필요합니다.

모든 커밋에서 동일한 평가 실행하기

또한 microsoft/ai-agent-evals@v3-beta GitHub Action을 사용하여 파이프라인의 2단계(Step 2)에서 평가를 실행할 수도 있습니다. 이 액션은 문서에서 미리 보기(preview)로 표시합니다. 아래 단계는 체크아웃 및 OpenID Connect를 사용하는 Azure 로그인 단계 다음에 오므로, 워크플로우는 id-token: write 권한과 GitHub Actions 변수로 저장된 클라이언트 ID, 테넌트 ID 및 구독 ID도 필요합니다.

      - name: Run Evaluation
        uses: microsoft/ai-agent-evals@v3-beta
        with:
...

agent-ids 입력은 my-agent:1,my-agent:2와 같은 값을 받으며, 선택적인 baseline-agent-id는 비교에 사용되는 버전을 설정합니다. 결과는 워크플로우 실행 요약에 각 메트릭의 점수, 신뢰 구간(confidence intervals)과 함께 표시되며, 여러 에이전트를 비교할 경우 차이가 의미 있는 것인지 아니면 단순히 무작위 변동인지를 알려주는 쌍별 통계 비교(pairwise statistical comparison)가 제공됩니다. 따라서 동일한 데이터셋을 두 버전 모두에 실행하기 때문에 에이전트의 지침이나 모델 변경 사항에 대한 합리적인 품질 게이트 역할을 합니다.

세 가지 기능이 함께 작동하는 것을 먼저 보고 싶다면, Azure Friday 에피소드 Microsoft Foundry에서 품질 및 안전을 위한 에이전트 관찰 및 평가에서 Foundry 포털과 Visual Studio Code를 사용한 라이브 데모로 평가, 추적 및 모니터링 과정을 안내합니다.

오늘날 여러분의 에이전트에 대해 답변하기 가장 어려운 세 가지 질문은 무엇인가요? 그들이 무엇을 했는지, 그들의 답변이 얼마나 좋았는지, 아니면 배포 후에도 여전히 좋은 상태를 유지하는지 말입니다.