MCP 서버 평가하기

배포하기 전에 MCP 에이전트가 올바른 툴을 고르는지 평가해 봐요.

출처: 문서

본문

개요

Model Context Protocol (MCP)는 AI 모델을 외부 툴, 데이터 소스, 서비스에 연결하기 위한 오픈 표준이에요. MCP 구성에는 하나 이상의 MCP 서버에 대한 호출을 조율하는 호스트(여러분의 에이전트)가 있고, 각 서버는 툴 묶음을 노출해요.

graph LR
    U["User request"] --> H["Host<br/>your agent"]
    H --> S1["MCP Server A"]
    H --> S2["MCP Server B"]
    S1 --> T1["Tools<br/>search_docs"]
    S2 --> T2["Tools<br/>get_customer_context"]

    style H fill:#eef2ff,stroke:#6366f1
    style S1 fill:#eef2ff,stroke:#6366f1
    style S2 fill:#eef2ff,stroke:#6366f1

MCP 평가는 결국 한 가지 질문으로 귀결돼요: 좋은 결과를 내기 위해 에이전트가 올바른 툴을, 올바른 입력으로 호출했는가? 이 가이드는 배포 전에 에이전트를 벤치마킹하고, 그다음 테스트 런과 프로덕션 평가에 트레이싱을 추가하는 과정을 안내해요.

MCP 평가하기

배포 전에 MCP 에이전트를 golden 데이터셋 기준으로 벤치마킹해요. Confident AI는 각 입력을 AI Connection으로 보내고, 생성된 출력과 MCP 툴 상호작용을 캡처한 뒤, 여러분의 metric collection으로 런을 채점해요.

먼저 Confident AI에 두 가지를 설정해야 해요:

golden 데이터셋 — MCP 에이전트를 테스트할 대상이에요.
AI Connection — 배포된 MCP 호스트를 가리키게 해요. Confident AI가 에이전트를 실행하고 생성된 출력, 툴 호출, 툴 인자를 캡처하는 데 써요.

둘을 준비했으면 메트릭을 설정하고, MCP 서버를 연결하고, 평가를 실행해요:

metric collection 만들기

Project > Metrics > Collections에서 metric collection 을 만들어요 — 런마다 채점하는 메트릭 묶음이에요. MCP Use나 Argument Correctness부터 시작하고, 최종 답변 품질이 중요하면 출력 품질 메트릭을 추가해요.

동영상

MCP 평가용 metric collection 만들기

무엇을 추가할지 모르겠다면 메트릭 고르기를 보세요.

MCP 서버 연결하기

Project Settings > MCP Servers에서 Add server를 클릭하고 이름과 연결 정보를 입력해요. Confident AI가 해당 서버 버전의 툴 정의를 가져와서, 평가 중 매칭되는 MCP 툴을 라벨링하는 데 사용해요.

Project Settings에서 MCP 서버를 연결하세요 — 툴 목록을 펼쳐서 동기화된 것을 확인해 보세요

데이터셋에서 평가 실행하기

Project > Datasets로 이동해 데이터셋을 열고 Evaluate를 클릭해요. 만든 metric collection을 선택하고, 에이전트를 실행하는 AI Connection을 고르고, MCP Servers 아래에서 연결한 서버를 붙인 뒤 Run Evaluation을 클릭해요.

데이터셋에서 평가를 시작하세요 — AI Connection을 고르고 만든 MCP 서버를 붙이세요

AI Connection과 프롬프트처럼, 붙인 MCP 서버도 테스트 런 하이퍼파라미터로 저장돼요. Confident AI는 매칭되는 툴 호출을 MCP tools로 라벨링하므로, 직접 표시할 필요가 없어요.

MCP 평가 결과 보기

테스트 런을 열고 테스트 케이스를 선택해요. 툴 호출이 Tools Used 아래 나타나고, 매칭되는 호출은 입력·출력과 함께 인라인으로 MCP 태그가 붙어요. 메트릭 점수는 런이 어떻게 수행됐는지 보여줘요.

테스트 케이스를 살펴보세요 — MCP 툴 호출이 태그가 붙고 메트릭으로 채점됩니다

완료 ✅. 이제 MCP 에이전트에 대한 반복 가능한 배포 전 벤치마크가 생겼어요.

고급 사용법

배포 전 벤치마크가 갖춰지면, 전체 툴 경로를 볼 수 있도록 트레이싱을 추가해요. 트레이스는 테스트 런을 각 결과 뒤의 정확한 툴 경로와 연결하고 라이브 프로덕션 평가를 구동해요.

MCP 트레이싱

트레이싱은 데이터셋 평가에서 선택 사항이에요. AI Connection이 트레이스 없이도 생성된 출력과 tools_called를 돌려줄 수 있어요. 각 결과의 점수 뒤에 있는 트레이스를 열고 싶거나 프로덕션에서 온라인 평가를 실행하고 싶을 때 트레이싱을 추가하세요.

호스트는 MCP 클라이언트를 통해 MCP 서버를 호출해요. 대부분의 배포에서 각 서버는 별도 프로세스로 실행됩니다:

graph LR
    subgraph Host["Host · your agent process"]
        LLM2["LLM<br/>decides what to call"]
        CA["MCP client A<br/>calls one server"]
        CB["MCP client B<br/>calls one server"]
        LLM2 --> CA
        LLM2 --> CB
    end

    CA -->|"JSON-RPC · tools/call"| SA["Server A<br/>docs context"]
    CB -->|"JSON-RPC · tools/call"| SB["Server B<br/>customer context"]

    style CA fill:#eef2ff,stroke:#6366f1
    style CB fill:#eef2ff,stroke:#6366f1
    style SA fill:#eef2ff,stroke:#6366f1
    style SB fill:#eef2ff,stroke:#6366f1

트레이싱에서는 그 클라이언트/서버 경계가 중요해요: 호스트가 활성 트레이스를 소유하고, 각 서버에는 트레이스 컨텍스트를 명시적으로 전달해야 하거든요.

호스트와 각 서버는 JSON-RPC 2.0 으로 통신해요 — "어떤 매개변수로 이름 붙은 메서드를 호출하고 결과를 받는다" 같은 가벼운 프로토콜이죠. 툴을 호출하는 것은 tools/call 메서드를 쓰는 JSON-RPC 요청이에요:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "search_docs",
    "arguments": { "query": "refund policy for annual plans" }
  },
  "id": 1
}

여기서 method는 연산이고, params.name은 툴이며, params.arguments는 툴 입력이에요. 이 예시에서 호스트는 에이전트가 답하기 전에 docs MCP 서버에 컨텍스트를 요청해요. 최상위 id는 JSON-RPC 요청 ID일 뿐입니다 — 트레이스 ID가 아니에요.

이 메시지들은 transport를 통해 이동해요 — 로컬 서버는 stdio, 원격은 HTTP예요. 어느 쪽이든 호스트와 서버는 보통 다른 프로세스라서, 서버는 호스트의 활성 트레이스를 자동으로 볼 수 없어요. 호스트가 tools/call 요청과 함께 트레이스 컨텍스트를 보내야 해요.

단일 요청의 모든 툴 호출을 하나의 트레이스로 통합해서 보려면, 프로세스 경계를 넘어 트레이스 컨텍스트를 옮기는 분산 트레이싱이 필요해요.

높은 수준에서 보면, 호스트가 각 MCP 호출의 메타데이터에 W3C 트레이스 컨텍스트를 주입하고, 각 서버가 그걸 추출해 자식 스팬을 만들고, 모든 프로세스가 같은 CONFIDENT_API_KEY 로 Confident AI로 내보냅니다.

OTLP exporter 구성하기

호스트 그리고 모든 MCP 서버에 이 환경 변수들을 설정해서 모든 스팬이 같은 프로젝트로 내보내지게 해요:

export CONFIDENT_API_KEY="your-project-api-key"
export OTEL_EXPORTER_OTLP_ENDPOINT="https://otel.confident-ai.com"

모든 프로세스가 같은 CONFIDENT_API_KEY 를 공유해야 해요. 서버가 다른 키를 쓰면 스팬이 다른 프로젝트에 들어가고 분산 트레이스가 통합되지 않아요.

MCP 호출을 통해 트레이스 컨텍스트 전파하기

각 MCP 서버는 자기 프로세스에서 돌기 때문에, 그대로 두면 호출마다 새 트레이스를 시작해요. 서버 스팬을 호스트 트레이스에 붙이려면, 호스트가 서버에 이 호출이 어느 트레이스에 속하는지 알려줘야 해요.

그 식별자가 W3C traceparent 입니다 — 트레이스 ID와 호스트의 현재 스팬 ID를 담은 간결한 문자열이에요. MCP는 _meta를 서버까지 그대로 전달하므로 호스트가 거기에 traceparent를 넣을 수 있어요:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "search_docs",
    "arguments": { "query": "refund policy for annual plans" },
    "_meta": {
      "traceparent": "00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01"
    }
  },
  "id": 1
}

반대편에서 MCP 서버는 _meta.traceparent를 읽어 부모로 채택해요 — 그래서 툴 스팬이 새 트레이스를 시작하는 대신 호스트 트레이스 아래에 중첩됩니다.

그 traceparent 문자열을 직접 만들지 마세요 — 호스트에서 주입하고 서버에서 추출하는 것은 표준 OpenTelemetry 컨텍스트 전파예요. Distributed Tracing 섹션이 양쪽 끝의 주입/추출 코드를 완전히 실행 가능한 MCP 예시(Python 호스트 + TypeScript·Python 서버)와 함께 안내해요.

각 툴 호출을 tool 스팬으로 기록하기

이 작업은 호스트에서 일어나요. 모든 툴 호출이 MCP 클라이언트의 call_tool을 거치거든요. 그 호출을 tool 스팬으로 감싸서 툴 이름·인자·결과가 트레이스에 들어가게 해요. 그리고 요청을 보내기 전에 트레이스 컨텍스트를 주입해요:

async def call_tool_with_tracing(session, tool_name: str, arguments: dict):
    with tracer.start_as_current_span(f"mcp-tool-{tool_name}") as span:
        span.set_attribute("confident.span.type", "tool")
        span.set_attribute("confident.tool.name", tool_name)
        span.set_attribute("confident.span.input", json.dumps(arguments))

        # Inject trace context so the MCP server joins this trace
        trace_meta = {}
        propagator.inject(trace_meta)

        result = await session.call_tool(tool_name, arguments=arguments, _meta=trace_meta)

        span.set_attribute("confident.span.output", json.dumps(result.content))
        return result

여기서 session은 한 서버용 MCP 클라이언트이고, propagator.inject(trace_meta)가 활성 스팬의 traceparent로 dict를 채워요 — 그 ID를 직접 만들 필요가 전혀 없어요.

완료 ✅. 이제 MCP 호스트와 서버가 모든 요청에 대해 통합된 트레이스를 내보내요.

호스트와 서버가 통합 트레이스를 내보내기 시작하면, AI Connection에 연결해요. 평가 중 생성된 각 테스트 케이스에는 그것을 만든 트레이스로 가는 링크를 넣을 수 있어서, 점수 뒤의 정확한 툴 경로를 살펴볼 수 있어요.

프로덕션에서 MCP 평가하기

배포 전 벤치마크는 배포 전에 회귀를 잡아 주지만, 실제 사용자는 테스트해 본 적 없는 입력을 보내요. 온라인 평가는 Confident AI가 MCP 트레이스를 수집할 때 점수를 매겨 이 루프를 닫아요. 그래서 툴 사용 품질이 프로덕션에서 계속 모니터링됩니다.

MCP 호스트와 서버가 Confident AI로 트레이싱하기 시작하면, tool 스팬에는 MCP Use 같은 메트릭을, 전체 트레이스에는 Task Completion 같은 메트릭을 켜요. 데이터셋 없이도 모든 프로덕션 런이 자동으로 채점되고, 툴 선택 품질이 떨어지면 임계값이 알려 줘요.

배포 전 벤치마크와 온라인 평가에 같은 MCP 메트릭을 사용하세요. 그래야 개발·배포 전·프로덕션에서 툴 사용을 일관되게 측정할 수 있어요.

개념

위 워크플로만으로 평가를 실행하기에 충분해요. 이 섹션은 MCP 평가가 왜 중요한지, 런이 끝에서 끝까지 어떻게 동작하는지, 어떤 메트릭을 고를지, 그리고 신뢰성을 유지하는 방법을 설명해요.

왜 MCP를 평가하나요

MCP는 에이전트를 툴 사용 시스템으로 만들어요. 모델이 여전히 최종 답변을 쓰지만, 답변 품질은 그것이 거친 경로 — 어느 툴을 골랐는지, 어떤 인자를 전달했는지, 반환된 데이터를 올바르게 사용했는지 — 에 달려 있어요.

graph LR
    Req["User request"] --> Sel["Agent picks<br/>a tool + arguments"]
    Sel --> Run["MCP tool runs"]
    Run --> Ans["Agent reasons<br/>& answers"]

    Sel -.-> TC["<b>Tool calling</b><br/>Tool Correctness"]
    Sel -.-> TU["<b>Tool usage</b><br/>Argument Correctness · MCP Use"]
    Ans -.-> WF["<b>Workflow</b><br/>Task Completion · Step Efficiency"]

    style TC fill:#eef2ff,stroke:#6366f1
    style TU fill:#eef2ff,stroke:#6366f1
    style WF fill:#eef2ff,stroke:#6366f1

MCP 평가는 "최종 답변이 좋았는가?"를 넘어 봐야 해요. 무엇을 측정할지는 MCP 에이전트가 얼마나 많은 일을 하느냐 — 단일 툴 호출부터 다단계 워크플로까지 — 에 따라 달라져요:

Tool calling — 에이전트가 올바른 툴을 호출했나요? Tool Correctness가 호출된 툴을 기대했던 툴과 비교해요. MCP가 본질적으로 툴 호출 인터페이스일 때 가장 적합해요.
Tool usage — LLM이 그 툴을 얼마나 잘 쓰나요. Argument Correctness는 각 호출의 입력이 요청에 맞는지 확인하고, MCP Use는 툴 선택과 인자 품질을 함께 채점해요 — 라벨이 필요 없어요. 대부분의 MCP 에이전트가 여기서 시작해요.
Workflow — 툴 호출을 감싸는 것 이상을 하는 MCP, 예컨대 요약기나 다단계 에이전트에요. Task Completion은 런이 사용자의 목표를 달성했는지 확인하고, Step Efficiency는 빙 돌지 않고 도달했는지 확인해요.

이게 무엇을 볼지예요 — 메트릭 고르기에서 이 범주들을 metric collection으로 바꾸는 방법을 보세요.

어떻게 동작하나요

데이터셋 런을 시작하면 Confident AI는 다음을 수행해요:

sequenceDiagram
    participant Dataset as Dataset
    participant Confident as Confident AI
    participant Connection as AI Connection
    participant Host as MCP Host
    participant Server as MCP Server
    participant Metrics as Metrics

    Confident->>Server: Fetch tool definitions
    Dataset->>Confident: Golden input
    Confident->>Connection: Send input
    Connection->>Host: Run MCP agent
    Host->>Server: tools/call
    Server-->>Host: Tool result
    Host-->>Connection: Output + tools_called
    Connection-->>Confident: Generated test case
    Confident->>Metrics: Score generated test case

MCP 평가는 최종 답변만 확인하지 않아요. 에이전트가 MCP 서버와 상호작용한 방식도 채점할 수 있어요:

연결된 MCP 서버가 Confident AI가 매칭 호출을 MCP 툴 호출로 라벨링하는 데 쓰는 툴 정의를 제공해요.
AI Connection이 에이전트를 실행하고 생성된 출력과 tools_called를 돌려줘요.
메트릭이 측정 대상(툴 선택, 인자, 최종 출력, 전체 워크플로)에 따라 생성된 테스트 케이스를 채점해요.

reference가 없는 MCP 메트릭은 모든 golden에 expected_tools를 라벨링할 필요가 없어요. 데이터셋이 입력을 제공하고, AI Connection이 출력과 툴 상호작용을 생성하며, 연결된 서버가 MCP 툴 정의를 제공해요.

메트릭 고르기

metric collection은 모든 런을 채점하는 메트릭 묶음이에요. MCP 에이전트에게 "좋음"이 무엇인지 정의하죠. 왜 MCP를 평가하나요 섹션이 메트릭을 무엇을 측정하는지로 묶었어요. 이제 collection에 무엇을 넣을지 고르는 방법이에요.

reference가 없는 MCP 네이티브 메트릭 하나로 시작하고, 실제 리스크를 커버할 때만 더 추가해요:

MCP Use — 기본값이에요. 연결된 서버의 툴 정의를 이용해 툴 선택과 인자 품질을 채점하고, 라벨이 필요 없어요.
Argument Correctness — 입력을 더 날카롭게 보는 렌즈예요: 각 호출이 요청에 맞는 인자를 전달했나요? 인자 품질이 주요 리스크라면 MCP Use와 함께 쓰세요.
Task Completion — 런이 사용자의 목표를 달성했나요? 에이전트가 여러 호출을 이어 붙일 때 결과를 채점하고 싶다면 추가해요.
Step Efficiency — 중복 호출이나 빙 둘러가지 않고 도달했나요? 비용이나 지연이 중요할 때 추가해요.
Answer Relevancy 같은 출력 품질 메트릭 — 최종 응답이 툴 경로만큼 중요할 때 유용해요.

라벨된 데이터가 있나요? Tool Correctness 를 추가해요. 호출된 툴을 golden별 expected_tools 리스트와 비교해요. 위 항목은 모두 reference가 없으므로, 대부분의 팀은 거기서 시작하고 라벨이 생기면 Tool Correctness를 그 위에 얹어요.

어디서 시작할지 모르겠다면 MCP Use를 추가하고 한 번 돌려서 각 점수 뒤의 근거를 읽어 보세요. 약점이 툴 선택인지, 인자인지, 최종 답변인지 보여 줄 거예요.

모범 사례

에이전트·툴·서버가 진화해도 MCP 평가를 신뢰할 수 있게 유지하는 몇 가지 습관이에요:

평가를 실제 부작용에서 격리하세요. MCP 툴은 실제 행동을 해요 — 데이터베이스에 쓰기, 이메일 보내기, 돈 옮기기. 평가 런을 샌드박스 서버, 모의 툴, 읽기 전용 자격 증명에 돌려서 벤치마킹이 프로덕션 시스템을 절대 변경하지 않게 해요.
서버 버전을 고정하고 업그레이드마다 재벤치마킹하세요. 새 MCP 서버 릴리스가 툴 이름을 바꾸거나 스키마를 바꿀 수 있어요. 고정 버전으로 평가하고, 서버 업그레이드를 코드 변경처럼 취급해요: 프로덕션에 도달하기 전에 벤치마크를 다시 돌리세요.
데이터셋을 프로덕션 트레이스에서 심어요. 손으로 쓴 golden은 사용자가 실제로 행동하는 방식을 놓치기 쉬워요. 트레이스에서 실제 엣지 케이스와 과거 실패를 데이터셋으로 승격해서 고쳐진 회귀가 고쳐진 채로 남게 해요.
각 입력을 여러 번 샘플링하세요. 에이전트는 같은 입력에서도 다른 툴 경로를 타요. multi-generation을 쓰고, 단 한 번의 운 좋은 — 또는 나쁜 — 런이 아니라 통과율로 판단하세요.
벤치마크로 릴리스를 게이트하세요. 메트릭에 임계값을 붙이고 CI에서 벤치마크를 돌려 툴 선택 품질 하락이 배포를 막게 해요.
정확성만이 아니라 비용과 지연도 추적하세요. 스무 번의 중복 툴 호출로 올바른 답에 도달한 에이전트도 여전히 프로덕션 문제예요. 품질과 함께 단계 수와 지연을 지켜보세요.

FAQ

호스트와 MCP 서버가 같은 프로세스에서 돌면 분산 트레이싱이 필요한가요?

모든 것이 한 프로세스에서 돌면 표준 트레이싱이 컨텍스트 전파 없이도 툴 스팬을 잡아요. 분산 트레이싱은 툴 호출이 프로세스나 네트워크 경계를 넘는 순간부터 중요해요 — 서버가 호스트와 분리되어 도는 흔한 MCP 구성이죠.

접지 진리(ground truth) 없이 툴 사용을 측정할 수 있나요?

네. MCP Use는 연결된 서버의 툴 정의로 툴 선택과 인자 정확성을 채점하고, Argument Correctness는 각 호출의 인자가 입력에 맞는지 확인하며, Task Completion은 에이전트가 사용자의 목표를 달성했는지 판단해요 — 이 셋 모두 reference가 없어서 라벨된 expected_tools 리스트가 필요 없어요. 접지 진리가 필요한 건 Tool Correctness뿐이에요.

tools_called는 자동으로 어떻게 캡처되나요?

일부 통합이 MCP 툴 스팬을 대신 캡처해요. 예를 들어 OpenAI Agents 통합은 MCP 툴 호출을 자동으로 기록해요. 그 외에는 트레이스에 tools_called를 직접 설정하거나 AI Connection 응답에서 반환하면 돼요.

다음 단계

배포 전에 MCP 에이전트를 벤치마킹하고, 테스트 런과 프로덕션 평가용 트레이싱 방법을 봤어요. 더 들어가 보려면:

MCP 서버 평가하기