MCP 프로토콜 심층 분석: 도구 검색 및 점진적 기능 주입의 메커니즘

Model Context Protocol (MCP)의 도구 검색 시스템에 대한 기술적인 심층 분석을 통해 기본 개념을 넘어섭니다. 이 게시물은 초기 JSON-RPC 핸드셰이크부터 효율적이고 점진적인 도구 기능 주입까지의 전체 흐름을 풀어내며, 프로토콜의 우아한 내부 설계를 밝혀냅니다.

기반: 구조화된 JSON-RPC 2.0 핸드셰이크

Model Context Protocol (MCP) 대화는 신뢰를 확립하고 통신 매개변수를 정의하는 세심하게 구조화된 교환으로 시작됩니다. 단순한 ping과는 달리, 초기 핸드셰이크 자체가 기능 검색 요청입니다. 이는 모든 후속 상호 작용의 기반을 다집니다. 클라이언트(일반적으로 IDE나 에이전트와 같은 AI 호스트)는 JSON-RPC 2.0 initialize 메서드 호출을 시작하지만, 페이로드는 MCP를 위해 특별히 형식화되어 있습니다.

이 요청에는 호환성을 보장하기 위한 protocolVersion 필드(예: `

핸드셰이크(handshake)가 완료되고 양측이 tools 기능(capability)을 사용할 수 있다는 데 동의하면, 클라이언트는 주요 탐색 단계인 tools/list 요청을 실행합니다. 이 단계에서 서버는 실제 도구 상자(toolbox)를 공개합니다. 응답은 도구 정의 객체들의 JSON 배열이며, 각 객체는 고유한 name, 사람이 읽을 수 있는 description, 그리고 가장 중요한 inputSchema를 포함합니다.

이 inputSchema는 완전한 JSON Schema 문서입니다. 이는 단순히 파라미터(parameter)를 나열하는 것에 그치지 않고, 해당 파라미터의 타입(type), 필수/선택 여부, 제약 조건(constraints)을 정의하며 예시(examples)까지 제공합니다. 이를 통해 클라이언트, 즉 그 뒤에 있는 AI 모델은 도구가 존재한다는 사실뿐만 아니라, 도구를 정확히 어떻게 호출해야 하는지를 정밀하게 이해할 수 있습니다. 앞서 선언된 listChanged 기능은 서버의 도구 세트가 동적으로 업데이트될 경우 서버가 notifications/tools/list_changed 이벤트를 전송할 수 있게 하여, 클라이언트가 목록을 다시 가져오도록(re-fetch) 유도합니다.

// 클라이언트 요청: tools/list
{
  "jsonrpc": "2.0",
...

기능 협상(Capability Negotiation): 클라이언트의 요구사항과 서버의 역량 매칭

초기 핸드셰이크에서의 기능 교환은 협상의 첫 번째 단계일 뿐입니다. 전체 MCP 설계는 더욱 미묘하고 문맥에 특화된 협상을 허용합니다. 예를 들어, 도구 목록이 나열된 후 클라이언트는 후속 호출에서 특정 도구 기능에 대한 지원을 선언할 수 있습니다. 강력한 패턴은 sampling 기능에서 볼 수 있습니다. 만약 서버 도구가 모델에게 명확한 질문을 던져야 하는 경우(AI를 통한 "human-in-the-loop"), 클라이언트의 초기 initialize 요청에서 sampling 기능을 선언했을 때만 이를 수행할 수 있습니다.

이는 안전한 선택형(opt-in) 모델을 구축합니다. 서버는 클라이언트가 준비되지 않은 고급 기능을 시도하지 않습니다. 또한, roots 기능은 클라이언트가 접근 가능한 파일 시스템 루트(filesystem roots)를 선언할 수 있게 하며, 서버 측 도구는 이를 반드시 준수해야 합니다. 이러한 협상은 양측 모두가 경계를 인지한 상태에서 도구가 의도된 샌드박스(sandbox) 내에서 작동하도록 보장합니다.

점진적 주입 (Progressive Injection): 효율적이고 문맥을 인식하는 도구 전달

표준 tools/list 호출은 서버가 제공하는 모든 도구를 반환합니다. 수십 개의 서버가 존재하는 복잡한 생태계에서 이는 정보 과부하를 초래하고 AI의 컨텍스트 윈도우 (context window) 내 토큰 사용량을 증가시킬 수 있습니다. MCP의 고급 내부 메커니즘은 도구를 더 효율적으로 전달하는 방법인 **점진적 도구 주입 (progressive tool injection)**을 지원합니다.

명세(specification)는 기본 목록 메서드를 정의하지만, 지능적인 구현체는 프로토콜의 상태 유지 연결 (stateful connection)을 활용할 수 있습니다. 서버는 초기 목록 제공 후, notifications/tools/list_changed를 사용하여 문맥에 따라 사용 가능한 새로운 도구가 생겼음을 알릴 수 있습니다. 예를 들어, 현재 저장소를 드러내는 projectContext 리소스를 읽은 이후에만 triggerDeploy 및 checkBuildStatus 도구를 노출하는 CI/CD 파이프라인 서버를 상상해 보십시오. 서버는 진행 중인 대화 상태에 따라 사용 가능한 도구 세트를 동적으로 조정하여, 관련 없거나 민감한 작업이 성급하게 노출되는 것을 방지합니다.

이러한 점진적 접근 방식은 단순히 도구를 숨기는 것에 그치지 않고, 문맥에 맞는 제시 (contextual presentation)에 관한 것입니다. 이는 모델의 인지 부하 (cognitive load)를 줄이고, 현재 작업 단계와 관련된 도구만을 제시함으로써 보안을 강화합니다.

종합: 실제 워크플로우 시나리오

프로젝트 전용 MCP 서버를 사용하는 AI 기반 IDE (클라이언트)를 사용하는 개발자의 사례를 가정해 보겠습니다. 1) IDE는 roots (프로젝트 폴더)와 tools를 지원한다고 선언하며 initialize를 보냅니다. 2) 서버는 tools와 resources를 제공함을 확인하며 응답합니다. 3) IDE는 즉시 tools/list를 호출합니다. 4) 서버는 analyzeCode, runTests, formatDocument를 포함한 목록을 반환합니다. 5) 사용자가 "auth.js에서 버그를 찾아줘."라고 요청합니다. 6) AI는 내부 추론 (internal reasoning)을 사용하여 analyzeCode 도구를 선택하고, 파일 경로가 포함된 유효한 inputSchema 준수 요청을 구성하여 tools/call을 통해 이를 호출합니다. 7) 서버는 분석을 실행하고 JSON-RPC 응답으로 결과를 반환합니다. 이 과정 전반에 걸쳐 프로토콜의 엄격한 스키마 (schemas) 및 기능 확인 (capability checks)은 전체 프로세스가 견고하고, 안전하며, 상호 운용 가능하도록 보장합니다.

Model Context Protocol로 구축을 시작하거나 자신만의 도구 서버를 만들 준비가 되셨나요? https://tormentnexus.site에서 전체 사양 (specification), 클라이언트 라이브러리 (client libraries), 그리고 예제 구현을 탐색하여 내부 구조를 마스터하고 오늘 바로 지능형 도구 통합을 시작해 보세요.

원문 게시지: tormentnexus.site