영상 링크: The State of MCP observability: Observable.tools — Alex Volkov and Benjamin Eckel, W&B and Dylibso
채널명: AI Engineer
MCP 관측성의 현주소: Observable.tools — Alex Volkov와 Benjamin Eckel (W&B & Dylibso) 핵심 요약
- MCP(Machine Control Protocol) 에이전트 및 서버의 사용이 증가하며 시스템 내에서 관측성이 약화되는 ‘블라인드 스팟’ 문제가 나타나고 있음
- 기존 소프트웨어 관측 도구(예: Datadog)처럼 MCP 기반 에이전트의 흐름을 효과적으로 추적할 수 있는 방법이 부족하여 생산환경에서 문제가 발생할 때 신속한 진단이 어려움
- 대기업 엔지니어링 팀은 관측성이 충분히 확보되지 않는 시스템을 절대 배포하지 않으며, MCP 역시 기존 관측 플랫폼과의 통합이 필수적임
- Weights & Biases의 Weave는 MCP 지원을 시작하여, 단순 환경변수 세팅만으로 MCP 트레이스와 툴 호출의 시간정보 조회를 지원 (현재 Python SDK 지원)
- 하지만 이는 특정 벤더에 종속된 방식이며, 오픈 프로토콜 기반의 베더 중립적이고 표준화된 관측성 방식이 필요하다는 문제의식이 제기됨
- 오픈 텔레메트리(OpenTelemetry, 줄여서 otel)가 분산 시스템 관측성의 사실상 글로벌 표준으로 부상; MCP 생태계에도 otel 기반 통합이 시도되고 있음
- otel의 핵심 메커니즘(트레이스, 스팬, 싱크) 및 MCP의 클라이언트-서버 구조에 맞춘 트레이스 컨텍스트 전달 방법이 구체적으로 시연됨
- TypeScript와 Python 등 언어 독립적으로 MCP 에이전트에서 otel 트레이스를 보내 Weave처럼 다양한 싱크에서 통합가능함을 실증
- MCP 서버 내부 트레이스 연결을 위한 언더도큐먼트 방식의 구현 사례 및, 추후 이를 쉽게 해줄 고수준 툴링 필요성 강조
- MCP 에이전트 간 메타적 협업 사례(OPUS 4 활용), MCP Run의 otel 지원 예고, 생태계 내 컨벤션 및 공동 표준 확립의 필요성 등 커뮤니티 액션 촉구
세부 요약 - 주제별 정리
MCP의 도입 확대로 개발자들이 엔드-투-엔드 관측성을 잃고 있음
- MCP(Machine Control Protocol) 기반의 에이전트 및 툴이 활성화되며, 기존에는 직접 코드 전체를 감시·관찰할 수 있었던 영역이 불투명해짐
- Alex(Weights & Biases)와 Ben(Dylibso)은 실제 생산환경에서 MCP 서버와 클라이언트 운영 경험을 공유하며, “내부에서 일어나는 일”을 기존 방식으로는 볼 수 없다는 점을 지적
- 각 기업·개발자가 고유하게 관측성 작업을 ‘비공개적으로’ 임의로 구축하고 있어, 커뮤니티 전체의 공통 해결방안 논의 필요
관측성이 부족하면 생산환경에서 문제 원인 파악과 대응이 심각하게 저하됨
- 관측 가능성이 없으면, 문제가 “왜”, “어디서”, “어떻게” 발생했는지 신속하게 파악할 수 없음
- 엔터프라이즈(대기업) 개발팀은 배포전에 반드시 충분한 관측성 확보가 필요하며, 이는 막대한 예산을 들여 진행됨
- MCP도 이런 환경에 배포되기 위해서는 기존 오브저버빌리티 플랫폼과의 연동이 핵심
Weights & Biases Weave에서 MCP 관측성 지원이 공식적으로 시작됨
- Weights & Biases의 관측성 툴 Weave는 MCP 트레이싱을 정식 지원
- MCP 트레이스 활성화는 환경변수(
MCP_TRACE_LIST_OPERATION) 한 줄 설정만으로 가능 (클라이언트와 서버 모두 동일 적용), Python SDK와 연동 - 예시로 BMI 계산 툴 같은 MCP 툴 호출의 트레이스가 시각화된 화면이 소개됨: 빨간 화살표는 클라이언트 트레이스, 파란 화살표는 MCP 툴 호출 지점 표시
Weave의 MCP 관측성은 특정 벤더에 종속되어 표준화와 중립성이 부족함
- 현 MCP 트레이스 기능은 Weave와 그 SDK에 통합된 독점적 통합(베스포크, bespoke) 방식임
- MCP의 본질인 “개방성”의 정신에 맞춰, 오픈 인프라/공통 프로토콜에 맞는 더 중립적·표준적 관측성 솔루션 요구
- 이를 위해 Observable.tools라는 커뮤니티 이니셔티브를 발표, Manifesto(선언문)로 문제 인식 확산 목표
오픈텔레메트리(OpenTelemetry, otel)가 분산 시스템 관측성의 글로벌 표준으로 부상함
- MCP 기반 분산 시스템 역시, 기존 분산 시스템과 유사하게 오픈텔레메트리를 적용할 수 있음
- otel의 주요 개념:
- 트레이스(trace): 트리구조로 이뤄진 시스템 내 원자적 연산 흐름
- 스팬(span): 각 단계의 소요시간 및 메타데이터를 담는 단위(HTTP 요청, 함수호출 등 다양함)
- 싱크(sync): 여러 트레이스/스팬을 수집·통합하는 플랫폼(데이터베이스, 대시보드, 모니터링 포함)
- otel 프로토콜로 인해, 개발자가 표준 방식으로 계측만 하면 다양한 싱크로 쉽게 호환/교체 가능
otel을 활용하면 MCP 클라이언트와 서버가 언어·플랫폼 상관없이 트레이스 연동이 가능함
- Weave 등 주요 관측성 플랫폼이 otel(OpenTelemetry) 지원을 공식화
- 클라이언트·서버가 서로 다른 환경(언어, 플랫폼)이더라도 동일 otel 싱크로 트레이스를 통합 가능
- 예시에서 TypeScript 기반 MCP 에이전트의 트레이스가 Weave에 연동되며, Python SDK와 완벽하게 통합됨
도메인(관리 권한) 경계에 따라 트레이스 연계 가능성이 달라짐
- 클라이언트/서버가 동일 도메인(관리·제어 범위) 내에 있으면 전체 트레이스 연동 및 디테일 관찰 가능
- 외부 도메인(예: GitHub, Stripe 등 타사가 운영하는 MCP 서버) 호출시에는 단일 스팬(블랙박스)처럼 보이고 내부 세부정보는 관측 불가
- 자기 소유 MCP 서버라면, 컨텍스트 프로퍼게이션(문맥 전달) 구현으로 싱크가 전체 연산 과정을 실시간으로 연계함
실제 프로토콜 레벨에서는 메타 페이로드를 통해 트레이스 컨텍스트를 전달하여 트레이스 연동을 실현함
- TypeScript 예시로, 툴 호출 시 클라이언트에서 현재 스팬 정보(트레이스 컨텍스트)를 추출하여 MCP 프로토콜의 메타데이터에 실어 서버로 전달
- 서버는 받은 트레이스 컨텍스트를 상속하여 자체 스팬 생성 및 싱크로 전송, 최종 트레이스가 한 번에 완성됨
- 현재는 공식 문서화된 고수준 메커니즘이 아니라 프로토콜 하위 레벨 인터페이스를 임시로 “우회” 사용했음
- 앞으로는 개발자가 쉽게 쓸 수 있도록 공식화·툴링 제공 필요
이식성 높은 otel 기반 방식을 통해 다양한 언어·환경의 MCP 에이전트가 손쉽게 트레이스 연동 가능함을 실증함
- Weave MCP의 경우 기존은 Python SDK에만 강하게 종속되어 있었으나, otel 지원 이후 Typescript 기반 MCP 에이전트도 큰 변경 없이 손쉽게 통합 가능함이 시연됨
- 방법: Weave를 OTLP 엔드포인트로 지정하고, 권한 헤더/프로젝트 지정해 트레이스 전송만 하면 끝
- 예시: 클라이언트(녹색)와 서버(다른 색)의 트레이스가 각각 하나의 싱크에서 통합적으로 조회됨
MCP 에이전트 간 메타 협업(Agent-to-Agent)과 실시간 문제해결 자동화 사례가 등장함
- Opus 4 에이전트를 이용하여, Weave MCP, MCP Server, 지원 봇(support bot)이 서로 대화하며 버그·오류 수정 흐름이 완전히 자동화된 예시 소개
- 에이전트가 자체적으로 코드 실행 → 트레이스 결과 진단 → 지원 봇에 쿼리 작성 및 문의 → 정보 습득 후 자가 문제 해결 및 재확인 일련과정을 모두 수행
- 휴먼 인터벤션 없이 ‘에이전트가 다른 에이전트의 도움을 발견하고 활용’하는 메타적 상호작용이 실시간으로 이뤄지는 장면
MCP Run 등 플랫폼도 otel 지원 예정이며, 생태계 표준 확립을 위한 공동 노력이 시급함
- MCP Run은 곧 otel 싱크로 직접 텔레메트리(관측정보) 내보내기 기능 도입; “프로필” 개념으로 복수 MCP 서버를 하나의 가상 서버처럼 관리
- MCP Run의 클라이언트(task): URL·스케줄 등 다양한 방식으로 단일 프롬프트 에이전트 실행 가능, otel 연계 예정
- 현재 MCP 내 관측성 기능은 부분적으로만 분포되어 있음 → 누구나 손쉽게 엔드-투-엔드 관측성 구현 가능하도록 더 많은 공동 툴·컨벤션(semantic conventions) 논의 필요
- 오픈 인퍼런스(공개 추론), GenAI semantic conventions, 고수준 SDK 등 표준 논의 품앗이 권장
- 컨퍼런스, 오프라인 트랙 등에서 실제 구현자들 간의 지식 교류가 매우 활발
MCP 생태계 발전을 위해 개발자, 툴 제공자, 플랫폼 구축자 모두 관측성 논의에 적극적으로 참여해야 함
- AI 엔지니어 및 MCP 툴 빌더는 자신의 툴이 end-to-end 관측성을 충분히 제공하고 있는지 점검 필요
- 벤더/플랫폼 제공자들은 고수준 SDK, 컨벤션 정의, 오픈 소스화 등으로 참조구현 확산에 기여 권장
- MCP Run, Weights & Biases Weave MCP, Observable.tools 등 주요 플랫폼·이니셔티브 참여 독려
- 세션 마지막에는 각자의 부스/채널(로봇 개 시연, 팟캐스트 등) 방문 및 직접 논의/협력 제안