Model Context Protocol, 흔히 MCP로 알려진 이 프로토콜은 AI 애플리케이션이 외부 도구(tools), API, 데이터베이스, 파일 및 기타 데이터 소스와 연결할 수 있는 표준화된 방법을 제공합니다.

전형적인 MCP 상호작용은 다음과 같이 단순해 보입니다:

사용자 (User)
  → AI 애플리케이션 또는 에이전트 (AI application or agent)
    → MCP 클라이언트 (MCP client)
...

예를 들어, 사용자가 AI 어시스턴트에게 다음과 같이 요청할 수 있습니다:

고객 4821의 지연된 주문을 보여줘.

AI 애플리케이션은 MCP 클라이언트 (MCP client)를 사용하여 적절한 도구를 찾고, MCP 서버 (MCP server)에서 해당 도구를 호출하며, 주문 데이터베이스에서 정보를 검색한 뒤 그 결과를 사용하여 사용자에게 답변할 수 있습니다.

로컬 개발 단계에서는 단 하나의 MCP 클라이언트, 하나의 MCP 서버, 그리고 몇 개의 도구만 포함될 수 있습니다. 하지만 운영 (production) 환경에서는 아키텍처가 다음과 같이 확장될 수 있습니다:

• 여러 개의 AI 애플리케이션
• 여러 개의 MCP 클라이언트
• 많은 수의 MCP 서버
• 수백 개의 도구 및 리소스
• 외부 API 및 데이터베이스
• 인증 (Authentication) 및 인가 (Authorization) 시스템
• 속도 제한 (Rate limits)
• 재시도 (Retries) 및 타임아웃 (Timeouts)
• 장기 실행되는 에이전트 워크플로 (Long-running agent workflows)

문제가 발생했을 때 나타나는 가시적인 증상은 단순히 다음과 같을 수 있습니다:

AI 어시스턴트가 느리다.

실제 원인은 요청 경로(request path)의 거의 모든 곳에 있을 수 있습니다:

• MCP 클라이언트가 세션을 초기화하지 못함.
• 도구 검색 (Tool discovery) 결과로 과도하게 큰 레지스트리가 반환됨.
• 모델이 도구를 선택하는 데 너무 오래 걸림.
• 클라이언트가 요청을 여러 번 재시도함.
• 서버가 사용 가능한 워커 (worker)를 기다림.
• 데이터베이스 쿼리가 느림.
• 다운스트림 API가 속도 제한 (rate limit)에 도달함.
• 도구가 불필요하게 큰 결과를 반환함.
• 서버가 작업을 완료하기 전에 클라이언트가 타임아웃 (timeout)됨.

이것이 바로 신뢰할 수 있는 MCP 모니터링이 클라이언트와 서버 모두를 포함해야 하며, 이들을 둘러싼 도구, 리소스, 전송 (transports), 의존성 (dependencies) 및 에이전트 워크플로까지 다루어야 하는 이유입니다.

이 글에서 다루는 내용

이 글은 다음 사항을 모니터링하는 방법을 설명합니다:

• MCP 프로토콜 활동 (MCP protocol activity)
• 클라이언트 연결 및 초기화 (Client connections and initialization)
• 도구 검색 및 실행 (Tool discovery and execution)
• 리소스 액세스 (Resource access)
• 재시도, 취소 및 타임아웃 (Retries, cancellations, and timeouts)
• 서버 런타임 상태 (Server runtime health)
• 에이전트 효율성 (Agent efficiency)
• 엔드 투 엔드 요청 지연 시간 (End-to-end request latency)

또한 다음 사항을 제공합니다:

• Prometheus 메트릭 (Prometheus metrics) 예시
• PromQL 쿼리 (PromQL queries)
• OpenTelemetry 스팬 (OpenTelemetry span) 예시
• 구조화된 로깅 (Structured logging) 예시
• 대시보드 (Dashboard) 권장 사항
• 알림 (Alerting) 가이드
• 개인정보 보호 및 보안 고려 사항

MCP 모니터링의 두 가지 의미

**MCP 모니터링 (MCP monitoring)**이라는 문구는 서로 관련되어 있지만 서로 다른 두 가지 사용 사례를 설명할 수 있습니다.

1. 모니터링 데이터에 액세스하기 위한 MCP 사용

MCP 서버는 AI 어시스턴트가 기존 모니터링 플랫폼에 액세스할 수 있도록 할 수 있습니다.

예를 들어, AWS Prometheus MCP Server를 사용하면 AI 애플리케이션이 Amazon Managed Service for Prometheus와 함께 작동할 수 있습니다.

운영자는 다음과 같이 질문할 수 있습니다:

지난 한 시간 동안 체크아웃 서비스의 HTTP 5xx 에러율은 얼마였나요?

MCP 서버는 해당 요청을 PromQL 쿼리로 변환할 수 있습니다:

sum(
  rate(
    http_requests_total{
...

이 사용 사례에서 MCP는 모니터링 시스템에 대한 인터페이스 (interface to the monitoring system) 역할을 합니다.

2. MCP 아키텍처 자체를 모니터링하기

두 번째 사용 사례는 실제 MCP 생태계를 모니터링하는 것입니다:

• MCP 클라이언트 (MCP clients)
• MCP 서버 (MCP servers)
• 세션 (Sessions)
• 프로토콜 메시지 (Protocol messages)
• 도구 (Tools)
• 리소스 (Resources)
• 프롬프트 (Prompts)
• 전송 (Transports)
• 의존성 (Dependencies)
• 에이전트 워크플로 (Agent workflows)

이 글은 주로 이 두 번째 사용 사례에 초점을 맞춥니다.

이 두 가지 접근 방식은 궁극적으로 함께 작동할 수 있습니다. 귀하의 MCP 애플리케이션이 텔레메트리 (telemetry)를 Prometheus로 내보내는 동안, Prometheus 중심의 MCP 서버를 통해 엔지니어가 자연어 질문을 사용하여 해당 텔레메트리를 조사할 수 있습니다.

전통적인 API 모니터링이 충분하지 않은 이유

전통적인 API 모니터링은 보통 네 가지 신호로 시작합니다:

1. 요청률 (Request rate)
2. 에러율 (Error rate)
3. 요청 지속 시간 (Request duration)
4. 리소스 사용률 (Resource utilization)

이러한 신호들은 여전히 중요하지만, MCP는 추가적인 동작을 도입합니다.

MCP 워크플로우에는 다음이 포함될 수 있습니다:

1. 연결 설정 (Establishing a connection)
2. 세션 초기화 (Initializing a session)
3. 프로토콜 버전 협상 (Negotiating a protocol version)
4. 기능 협상 (Negotiating capabilities)
5. 도구 또는 리소스 목록 나열 (Listing tools or resources)
6. 도구 선택 (Selecting a tool)
7. 도구 호출 (Calling the tool)
8. 결과 처리 (Processing the result)
9. 세션 종료 또는 유지 (Closing or maintaining the session)

전통적인 HTTP 대시보드는 모든 요청이 HTTP 200을 반환했다고 보고할 수 있습니다. 하지만 HTTP 응답 내부의 JSON-RPC 응답에는 여전히 MCP 에러가 포함되어 있을 수 있습니다.

마찬가지로, tools/list 요청은 100밀리초 만에 완료될 수 있지만 200개의 도구 정의를 반환할 수 있습니다. 서버 요청은 빠르지만, AI 모델은 대규모 도구 레지스트리를 평가하는 데 몇 초가 걸릴 수 있습니다.

따라서 MCP 관측성 (Observability)은 **전송 상태 (transport health), 프로토콜 상태 (protocol health), 도구 실행 (tool execution), 클라이언트 동작 (client behavior), 그리고 AI 워크플로우 동작 (AI workflow behavior)**을 측정해야 합니다.

MCP 메트릭 설계하기

개별 메트릭을 정의하기 전에, 몇 가지 일반적인 규칙을 따르는 것이 도움이 됩니다.

이벤트에는 카운터 (Counters) 사용

**카운터 (Counter)**는 오직 증가하기만 합니다.

카운터는 다음 항목에 적합합니다:

• 도구 호출 (Tool calls)
• 에러 (Errors)
• 재시도 (Retries)
• 타임아웃 (Timeouts)
• 재연결 (Reconnects)
• 액세스 거부 이벤트 (Access-denied events)

예시:

mcp_tool_calls_total

지속 시간 및 크기에는 히스토그램 (Histograms) 사용

**히스토그램 (Histogram)**은 버킷 (buckets)에 관측값을 기록하며 백분위수 (percentile) 계산을 가능하게 합니다.

히스토그램은 다음 항목에 적합합니다:

• 요청 지속 시간 (Request duration)
• 도구 지속 시간 (Tool duration)
• 메시지 크기 (Message size)
• 결과 크기 (Result size)
• 세션 지속 시간 (Session duration)
• 의존성 지속 시간 (Dependency duration)

예시:

mcp_tool_duration_seconds

히스토그램을 통해 다음을 계산할 수 있습니다:

• p50: 일반적인 경험
• p95: 작업의 5%가 경험하는 더 느린 요청
• p99: 가장 느린 1%의 작업

현재 상태에는 게이지 (Gauges) 사용

**게이지 (Gauge)**는 증가하거나 감소할 수 있습니다.

게이지는 다음 항목에 적합합니다:

• 활성 세션 (Active sessions)
• 활성 연결 (Active connections)
• 큐 깊이 (Queue depth)
• 레지스트리 항목 수 (Registry item count)
• 메모리 사용량 (Memory usage)
• 커넥션 풀 사용량 (Connection-pool usage)

예시:

mcp_server_active_sessions

높은 카디널리티 (High-Cardinality) 레이블 피하기

Prometheus 레이블은 제한적이고 예측 가능한 값의 집합을 포함해야 합니다.

좋은 레이블 예시:

tool="search_orders"
status="success"
error_type="dependency_timeout"
...

다음과 같은 레이블은 피하십시오:

customer_id="4821"
session_id="b91e2b40-..."
resource_uri="file:///customers/4821/private-notes.txt"
...

고유 ID, 원시 경로 (raw paths), 프롬프트 (prompts), 그리고 예외 메시지 (exception messages)는 극도로 높은 메트릭 카디널리티 (metric cardinality)를 생성할 수 있으며 민감한 정보를 노출할 위험이 있습니다.

상세한 값은 메트릭 레이블이 아닌 **정제된 로그 (sanitized logs) 또는 트레이스 (traces)**에 저장하십시오.

MCP 서버 메트릭 (MCP Server Metrics)

MCP 서버 모니터링은 다음 네 가지 주요 영역을 다루어야 합니다:

1. 프로토콜 활동 (Protocol activity)
2. 도구 실행 (Tool execution)
3. 리소스 액세스 (Resource access)
4. 런타임 및 의존성 상태 (Runtime and dependency health)

1. 프로토콜 메트릭 (Protocol Metrics)

프로토콜 메트릭은 클라이언트가 MCP 서버와 어떻게 통신하는지를 설명합니다.

유용한 시작 세트는 다음과 같습니다:

mcp_server_messages_total
mcp_server_request_duration_seconds
mcp_server_message_size_bytes
...

mcp_server_messages_total

이 카운터 (counter)는 서버에서 처리된 MCP 메시지의 수를 기록합니다.

권장되는 레이블은 다음과 같습니다:

• method
• direction
• status
• transport

예시:

mcp_server_messages_total{
  method="tools/call",
  direction="incoming",
...

이는 서버가 Streamable HTTP를 통해 18,420개의 유입된 tools/call 메시지를 성공적으로 처리했음을 의미합니다.

이 메트릭은 다음과 같은 질문에 답할 수 있습니다:

• 어떤 MCP 작업이 가장 빈번하게 사용되는가?
• 릴리스 이후 도구 트래픽이 증가했는가?
• 클라이언트가 tools/list를 반복적으로 호출하고 있는가?
• 활동이 갑자기 0으로 떨어졌는가?
• 특정 트랜스포트 (transport)가 다른 것보다 더 많은 트래픽을 받고 있는가?

해석 예시

다음과 같은 비율 (rate)이 갑자기 증가한다고 가정해 봅시다:

method="initialize"

초기화 요청의 급격한 증가는 다음과 같은 상황을 나타낼 수 있습니다:

• 클라이언트가 빈번하게 재연결(reconnecting)되는 경우.
• 서버가 재시작(restarting)되는 경우.
• 프록시(proxy)가 유휴 연결(idle connections)을 종료하는 경우.
• 인증 세션(authentication sessions)이 만료되는 경우.
• 클라이언트가 불필요하게 수명이 짧은 세션(short-lived sessions)을 생성하는 경우.

mcp_server_request_duration_seconds

이 히스토그램(histogram)은 서버가 MCP 작업을 처리하는 데 걸리는 시간을 측정합니다.

예시:

mcp_server_request_duration_seconds{
  method="tools/list"
}

tools/list의 경우, 소요 시간에는 다음 항목이 포함될 수 있습니다:

• 도구 정의(tool definitions) 로딩
• 액세스 제어(access controls) 적용
• 입력 스키마(input schemas) 구축
• 레지스트리(registry) 직렬화(serializing)

tools/call의 경우, 다음 항목이 포함될 수 있습니다:

• 인자(arguments) 검증
• 도구 실행
• 종속성(dependencies) 대기
• 결과 직렬화(serializing)

예시 백분위수(percentile) 값:

tools/call p50:  400 ms
tools/call p95:  2.8 seconds
tools/call p99:  8.5 seconds

평균값은 수용 가능한 수준으로 보일 수 있지만, p99 값이 일부 사용자가 심각한 지연을 겪고 있음을 드러낼 수 있습니다.

mcp_server_message_size_bytes

이 히스토그램(histogram)은 들어오고 나가는 MCP 메시지의 크기를 기록합니다.

예시:

mcp_server_message_size_bytes{
  method="tools/call",
  direction="outgoing"
...

MCP 응답에는 다음이 포함될 수 있습니다:

• 검색 결과(search results)
• 문서(documents)
• 소스 코드(source code)
• 로그(logs)
• 데이터베이스 레코드(database records)
• 파일 내용(file contents)
• 모니터링 데이터(monitoring data)

도구가 올바르게 작동하더라도 클라이언트가 필요로 하는 것보다 훨씬 더 많은 정보를 반환할 수 있습니다.

예시

search_logs 도구가 50MB의 로그를 반환하지만, 사용자는 최신 에러 20개만 필요로 하는 경우입니다.

대용량 메시지는 다음을 증가시킵니다:

• 네트워크 전송 시간(network transfer time)
• 직렬화 시간(serialization time)
• 클라이언트 메모리 사용량(client memory usage)
• 모델 컨텍스트 사용량(model context usage)
• 토큰 소비(token consumption)
• 엔드 투 엔드 지연 시간(end-to-end latency)

응답 크기를 모니터링하면 페이지네이션(pagination), 제한(limits), 필터링(filtering) 또는 요약(summarization)이 필요한 도구를 식별하는 데 도움이 될 수 있습니다.

mcp_server_protocol_errors_total

이 카운터(counter)는 MCP 또는 JSON-RPC 프로토콜 에러를 기록합니다.

예시:

mcp_server_protocol_errors_total{
  method="tools/call",
  error_type="invalid_parameters"
...

유용한 에러 카테고리에는 다음이 포함됩니다:

invalid_request
invalid_parameters
method_not_found
...

해석 예시

invalid_parameters 에러의 증가는 다음을 나타낼 수 있습니다:

• 도구 스키마 (tool schema)가 변경됨.
• 클라이언트가 오래된 인자 (argument) 형식을 전송함.
• 도구 설명 (tool descriptions)이 필수 필드를 명확하게 설명하지 않음.
• 에이전트 (agent)가 유효하지 않은 인자를 생성함.

unsupported_protocol_version의 증가는 서버 업그레이드 후에도 오래된 클라이언트들이 여전히 연결되고 있음을 나타낼 수 있습니다.

mcp_server_active_sessions

이 게이지 (gauge)는 현재 활성화된 MCP 세션의 수를 기록합니다.

예시:

mcp_server_active_sessions{
  transport="streamable_http"
} 138

갑작스러운 0으로의 감소는 서비스 중단 (outage)을 나타낼 수 있습니다.

급격한 증가는 다음을 나타낼 수 있습니다:

• 트래픽 급증 (traffic spike)
• 재연결 폭풍 (reconnection storm)
• 세션이 올바르게 종료되지 않음
• 클라이언트가 불필요하게 여러 연결을 생성함

mcp_server_session_duration_seconds

이 히스토그램 (histogram)은 MCP 세션이 활성 상태로 유지되는 시간을 측정합니다.

커맨드 라인 (command-line) 클라이언트의 경우 짧은 세션이 예상될 수 있습니다. 데스크톱 애플리케이션은 세션을 몇 시간 동안 열어둘 수 있습니다.

예상치 못하게 짧은 세션은 다음을 나타낼 수 있습니다:

• 연결 불안정 (connection instability)
• 인증 만료 (authentication expiration)
• 서버 재시작
• 전송 (transport) 실패

예상치 못하게 긴 세션은 다음을 나타낼 수 있습니다:

• 연결 누수 (connection leaks)
• 유휴 (idle) 클라이언트
• 해제되지 않은 세션 리소스
• 세션 정리 (cleanup) 누락

2. 도구 실행 지표 (Tool Execution Metrics)

도구 (tools)는 일반적으로 MCP 서버의 가장 중요한 운영 구성 요소입니다.

특정 도구가 지속적으로 느리거나 신뢰할 수 없는 동안에도 서버는 정상인 것처럼 보일 수 있습니다.

권장되는 지표는 다음과 같습니다:

mcp_tool_calls_total
mcp_tool_duration_seconds
mcp_tool_errors_total
...

mcp_tool_calls_total

이 카운터 (counter)는 각 도구가 얼마나 자주 호출되는지, 그리고 호출이 성공했는지 여부를 기록합니다.

예시:

mcp_tool_calls_total{
  tool="search_orders",
  status="success"
...

이에 대응하는 에러 시리즈 (error series)는 다음과 같을 수 있습니다:

mcp_tool_calls_total{
  tool="search_orders",
  status="error"
...

성공률 (success ratio)은 다음과 같습니다:

4832 / (4832 + 168) = 96.64%

이 지표 (metric)는 다음 질문에 답하는 데 도움이 됩니다:

• 어떤 도구 (tools)가 가장 빈번하게 사용되는가?
• 어떤 도구들이 더 이상 사용되지 않는가?
• 릴리스 (release) 이후 트래픽 (traffic)이 변했는가?
• 특정 도구에 예상치 못한 부하 (load)가 걸리고 있는가?
• 어떤 도구들의 성공률 (success ratio)이 가장 낮은가?

예시 (Example)

하나의 주문 MCP 서버 (order MCP server)가 네 가지 도구를 노출합니다:

search_orders
get_customer
create_refund
...

만약 search_orders가 모든 도구 호출 (tool calls)의 80%를 처리한다면, 이 도구는 추가적인 부하 테스트 (load testing), 용량 계획 (capacity planning), 그리고 성능 최적화 (performance optimization)를 수행할 가치가 있습니다.

mcp_tool_duration_seconds

이 히스토그램 (histogram)은 도구 실행 시간 (tool execution duration)을 측정합니다.

예시:

mcp_tool_duration_seconds{
  tool="search_orders"
}

대시보드 (dashboard)에 다음과 같이 보고된다고 가정해 봅시다: