숨겨진 LLM 호출까지 추적하는 MCP Observability 구현 기록

Context

MCP Server의 Tool 호출은 트레이싱이 가능하나 내부 sampling 요청은 관찰 불가능한 구조. 서버가 클라이언트 LLM에 응답 생성을 요청하는 sampling 과정이 트레이스 상에서 누락됨. 전체 실행 시간 중 LLM 처리 비중을 파악하지 못해 엉뚱한 지점을 최적화하는 위험 존재.

Technical Solution

• 내부 메서드 호출인 requestSampling을 자동 가로채기 위해 traceSampling 수동 래퍼 도입
• OTel SpanKind.CLIENT 설정을 통해 서버가 클라이언트 LLM을 호출하는 방향성을 명시한 설계
• gen_ai.operation.name, gen_ai.request.model 등 표준 속성을 부여하여 LLM 모델 및 수행 시간 기록
• Prometheus 기반의 MCP Server 전용 Grafana 대시보드를 구축하여 Tool Call Rate와 Error Rate 시각화
• Tool별 p50, p95 Latency 히스토그램을 통해 성능 병목 지점을 즉각 식별하는 모니터링 체계 구축
• MCP_SESSION_ACTIVE UpDownCounter를 도입하여 다중 서버 환경의 활성 세션 수 추적

Impact

• 전체 2.1s 소요된 Tool 호출 중 LLM sampling에 1.8s, 실제 로직에 300ms가 사용됨을 정량적으로 분리 식별
• Tool Call Rate 12.4 req/s, 평균 지속 시간 45.2 ms, 에러율 2.3% 등의 실시간 메트릭 확보

Key Takeaway

분산 시스템에서 라이브러리 수준의 자동 인터셉트가 불가능한 내부 메서드 호출은 명시적 래퍼를 통한 추적 구간 설정이 필수적임. 인프라 메트릭뿐만 아니라 도메인 특화 메트릭(Tool별 성능)을 정의해야 정확한 성능 최적화 지점을 도출할 수 있음.