Hanjun Cho

tech · 2026-03-22

Model Context Protocol (MCP)

#llm

1. 서론

1.1 MCP 등장 배경

  • 대형 언어 모델(Large Language Model, LLM)이 고성능 자연어 처리를 구현하더라도, 훈련 이후 시점의 외부 정보에는 접근하지 못하는 한계 존재
  • 실제 업무에서의 AI 활용은 모델이 최신 데이터, 사용자 맥락, 조직 내부 시스템과 연동되는 동적 컨텍스트 처리 능력을 필요로 함
  • 예시로, 고객 응대, 업무 자동화, 기술 지원 등의 상황에서는 모델이 실시간 정보(예: 주문 내역, 문서 기록, 일정 데이터 등)를 기준으로 판단을 내려야 함
  • 이러한 요구를 충족하기 위해, 모델과 외부 도구 및 데이터 간 안정적이고 유연한 연결 계층에 대한 필요성이 증가함
  • 기존에는 각 시스템별로 API 호출 로직을 커스텀 개발하거나, OpenAPI 기반 플러그인 또는 LangChain 등의 프레임워크를 활용하는 방식이 일반적임
  • 그러나 이들 방식은 프레임워크 종속성, 상태 비관리, 호출 불안정성, 도구 간 일관성 부재 등의 문제로 인해 실무 통합에 제약이 발생함

1.2 기존 접근 방식의 한계

  • OpenAPI 기반 통합 방식은 도구 간 통신을 HTTP 호출로 일원화하나, 호출 권한, 상태 관리, 사용자 승인 등의 세밀한 통제는 어렵고 단방향 호출에 치중됨
  • LangChain, Auto-GPT 등의 도구는 파이썬 기반의 유연성을 제공하나, 호출 체계가 복잡하고, 함수 구조 및 실행 흐름이 프로젝트마다 상이하여 유지보수 부담이 큼
  • JSON 기반 명세 없이 임의의 파라미터 구조를 사용하거나, 복잡한 프롬프트 체인에 의존하는 경우가 많아 모델의 호출 정확성과 일관성 확보가 어려움
  • 모든 접근법이 공통적으로 갖는 문제는 다음과 같음:
     – 모델이 호출 가능한 기능의 스펙을 구조화된 형태로 인지하지 못함
     – 세션 간 컨텍스트 유지가 불가능하여 다단계 작업에서 정보 손실 발생
     – 실무 환경에서 요구되는 보안 정책, 자원 접근 제한, 호출 로깅 등의 기능을 자체적으로 구현해야 함
  • 결과적으로, 다양한 시스템을 유연하게 연결하고 유지할 수 있는 범용적·표준화된 연결 계층이 부재한 상태임

1.3 MCP의 등장과 기술적 의의

  • Model Context Protocol(MCP)은 위 문제를 해결하기 위해 등장한 모델과 환경 간 연결을 표준화하는 통신 프로토콜임
  • 핵심 설계 철학은 다음과 같음:
     – 모델은 구조화된 명세를 통해 외부 기능 및 자원을 안전하게 호출함
     – 서버는 호출 가능한 기능 및 리소스를 스키마와 함께 명시적으로 제공함
     – 모든 호출은 JSON-RPC 2.0 형식을 기반으로 하여 언어 비종속적, 플랫폼 중립적 구현 가능성을 확보함
  • MCP는 클라이언트-서버 구조를 채택하며, 모델이 툴을 호출하거나 자원을 읽을 때, 클라이언트는 다음과 같은 요청 메시지를 서버로 전달함
# 클라이언트 -> MCP 서버 Request (tool 호출)
{
  "jsonrpc": "2.0",                # JSON-RPC 프로토콜 버전 (고정값)
  "id": "abcd-1234",               # 요청과 응답을 매핑하기 위한 고유 식별자 (클라이언트가 생성)
  "method": "tools/call",          # 호출할 MCP 메서드 이름: 툴 실행 요청
  "params": {
    "name": "search_documents",     # 호출할 툴의 이름 (서버가 미리 등록한 툴 이름과 일치해야 함)
    "arguments": {                  # 툴 호출에 필요한 입력 파라미터
      "query": "프로토콜 정의 관련 문서", # 문서 검색 쿼리 문자열
      "limit": 5                    # 결과 개수 제한 (선택 인자)
    }
  }
}

# MCP 서버 -> 클라이언트 Response 
{
  "jsonrpc": "2.0",               # 프로토콜 버전 (요청과 동일)
  "id": "abcd-1234",              # 요청 id와 동일한 값으로 응답 연결 보장
  "result": {
    "documents": [                # 툴 실행 결과 (문서 검색 결과 목록)
      {
        "title": "MCP 사양 문서",   # 문서 제목
        "url": "https://..."      # 문서 링크 (또는 리소스 식별자)
      },
      {
        "title": "MCP 설계 배경",
        "url": "https://..."
      }
    ]
  }
}
  • 서버는 이를 해석하여 지정된 기능을 실행하고, 결과 데이터를 동일한 id와 함께 반환함
  • 모델은 초기 연결 시 서버가 제공하는 툴/리소스/프롬프트 메타데이터를 수신하고, 이를 기반으로 사용 가능한 기능을 파악함
  • 이러한 구조는 기능 호출의 명시성, 도구 간 통일성, 호출 안정성, 사용자 승인 처리, 호출 이력 기록 등의 요구사항을 통합적으로 수용함
  • MCP는 LLM 중심 환경뿐 아니라, Agent, IDE, MLOps 파이프라인, DevOps 플랫폼 등 다양한 응용 영역에 적용 가능한 범용 연결 계층임

1.4 MCP의 차별점 및 실무 확장성

  • 기존 방식 대비 MCP가 제공하는 기술적 차별점은 다음과 같음:
     – 모델이 호출 가능한 기능을 명세 기반으로 이해하고 정확히 활용할 수 있도록 설계됨
     – JSON-RPC 기반 구조를 통해 구현 언어 및 프레임워크 독립성 확보
     – 클라이언트-서버 간 상태 관리 및 세션 유지가 가능하여 연속 작업 흐름에 적합
     – 도구 이름 충돌을 방지하는 네임스페이스 구조 지원
     – 다양한 도구(MCP 서버)를 모델이 동적으로 연결/해제 가능하도록 하여 확장성 높은 모듈화 구조 지원
     – OAuth, 사용자 승인, 툴 별 권한 제어, 호출 로깅 등 보안성과 통제력 확보 기능 탑재 가능
  • Claude AI는 MCP 기반으로 구글 드라이브, Git, Slack, DB 등에 연결되어 지식 탐색 및 문서 요약, 일정 조회, 코드 분석을 수행함
  • ZenML은 파이프라인을 MCP 서버로 노출시켜 모델이 자연어로 학습 상태 질의, 실행 요청 등을 수행 가능함
  • Sourcegraph, Cursor, Codeium 등의 개발 도구는 프로젝트 코드베이스, 이슈 트래커 등과 연결된 코드 기반 MCP 서버를 통해 문맥 인지 정확도를 높임
  • 기업 내부에서는 Kubernetes, Jenkins, Prometheus, Postgres 등 각종 시스템을 위한 MCP 커넥터가 공개되어 에이전트 기반 운영 자동화의 기반 기술로 주목받고 있음
  • MCP 서버는 로컬 또는 원격에서 구동 가능하며, TCP, STDIO, WebSocket, HTTP 등 다양한 연결 방식을 지원함
  • MCP는 오픈소스 기반으로 빠르게 생태계가 확장 중이며, 실무 도입 시 별도 커넥터 개발 또는 커뮤니티 구현체 활용이 가능함

1.5 Section 구성

  • Section 2: MCP 개념과 정의: MCP의 기본 구조와 핵심 구성 요소를 정의함
  • Section 3: MCP 아키텍처 및 구성 요소: MCP의 기술 구조와 각 구성 요소의 동작 방식 설명
  • Section 4: MCP 실제 적용 사례: Claude 등 실제 시스템에서의 활용 사례 소개
  • Section 5: 기존 접근 방식과의 비교 분석: GPT Script, LangChain 등과의 구조적 차이 비교
  • Section 6: MCP 실무 도입 전략: MCP 서버 설계, 인증, 운영 자동화 전략 제시
  • Section 7: MCP의 한계 및 향후 발전 방향: 인증, 상태관리 등 현재 한계와 개선 방향 도출
  • Section 8: 결론:  MCP의 실무적 의의와 향후 확장 가능성 정리
  • Section 9: Appendix: Claude 기반 MCP를 활용한 Naive RAG 예시

2. MCP 정의 및 핵심 개념

2.1 MCP란 무엇인가

  • Model Context Protocol(MCP)은 대형 언어 모델(LLM)이 외부 시스템의 기능과 자원에 정형화된 방식으로 접근하고 호출할 수 있도록 설계된 중립적 통신 프로토콜임
  • 기존 통합 방식은 도구별로 커스텀 API를 연결하거나 특정 플랫폼(OpenAI Plugin, LangChain 등)에 종속되어 있음
  • 이러한 구조는 유지보수성, 호출 일관성, 권한 관리 등에서 구조적 비효율을 초래하며, 대규모 통합 환경에서 확장성의 한계로 작용함
  • MCP는 이러한 문제를 해결하기 위해 기능 중심 분리, 호출 방식 표준화, 호출자-실행자 역할 분리를 철학적 기반으로 설계됨
  • 프로토콜은 다음의 기술 목표를 중심으로 구성됨:
    – LLM이 호출 가능한 기능 및 자원을 메타데이터 기반으로 인식하고 선택 가능하도록 구성
    – 모든 호출을 구조화된 JSON 메시지로 통일함으로써 예측 가능성과 구현 단순성 확보
    – 툴 실행, 자원 질의, 표현 제어를 단일 통신 구조 내에서 분리하여 책임 구분 및 권한 관리 가능
  • 결과적으로 MCP는 LLM 중심 시스템에서 기능 오케스트레이션 계층을 구현하기 위한 기반 기술로 작동함

2.2 핵심 동작 원리

‌

  • MCP는 클라이언트-서버 기반 RPC 구조로 동작하며, 모든 요청은 JSON-RPC 2.0 형식을 따름
  • 요청 메시지 구성요소와 역할은 다음과 같음:
필드명 설명
jsonrpc 프로토콜 버전 ("2.0" 고정)
id 요청-응답 쌍 연결을 위한 고유 식별자
method 호출할 기능 구분자 (tools/call, resources/read 등)
params 호출 시 필요한 파라미터 객체
result 성공 시 반환되는 결과 객체
error 실패 시 반환되는 오류 객체 (서버에서 선택적으로 포함)
  • MCP는 이러한 메시지 구조를 기반으로 요청의 정형성, 응답의 추적 가능성, 병렬 처리에 대한 준비성을 갖춤
  • 메서드는 명확히 정의된 단일 목적 구조로 동작하며, 각 호출은 멱등성 보장, 비동기 응답 연결 가능, 오류 처리 내장을 지원함

2.3 시스템 내 위치 및 초기화 흐름

  • MCP는 전체 시스템에서 모델과 외부 도구를 연결하는 **Context Interface Layer (CIL)**에 해당함
  • MCP 클라이언트는 모델과 통합되어 외부 호출을 관리하며, MCP 서버는 외부 기능/자원을 MCP 명세에 따라 등록하고 제공함
  • 초기 연결 시 클라이언트는 MCP 서버에 대해 다음 세 가지 메타데이터 요청을 순차적으로 수행함:
메서드 이름 설명
tools/list 사용 가능한 툴 목록과 각 툴의 호출 스펙(JSON Schema 기반)을 반환
resources/list 접근 가능한 자원 목록(ID, 이름, 설명 등 포함)을 반환
prompts/list 프롬프트 템플릿 목록 및 구조(변수 자리 포함)를 반환
  • 위 요청은 대부분 초기화 단계(initialize 이후)에 수행되며, 모델은 해당 정보를 내부 컨텍스트로 보존함
  • 이후의 툴 호출, 자원 질의, 프롬프트 활용은 이 메타데이터를 기반으로 구성됨

시스템 내 추상 구성은 다음과 같음:

[사용자 입력]
      ↓
[LLM / Agent]
      ↓
[MCP 클라이언트]
      ↓ (메타데이터 요청 및 도구 실행 메시지)
[MCP 서버]
      ↓
[실제 도구, 자원, 시스템: DB / API / 파일 시스템]
  • 모델은 "어떤 기능이 있는가", "무엇을 호출할 수 있는가"를 질문하지 않고도,
    사전에 수신한 MCP 메타데이터를 기반으로 자율적으로 기능을 탐색하고 호출함
  • 이 구조는 LLM 기반 Agent가 다수의 외부 시스템과 모듈화된 연결을 유지하면서 동작할 수 있도록 설계된 통합 인터페이스 계층임

2.4 MCP 구성 단위 및 설계 철학

  • MCP는 모델과 외부 시스템 간의 상호작용을 **세 가지 자산 유형(Tools, Resources, Prompts)**으로 구분하여 관리함
  • 각 구성 요소는 호출의 목적과 방식이 분리되어 있으며, 역할 단위로 기능을 위임받음
  • 설계 철학은 다음과 같은 구조적 분할과 책임의 명시화를 중심으로 함:
자산 유형 구조적 역할 호출 메서드 모델의 사용 목적
Tools 기능 호출 (RPC) tools/call 명령 실행, 외부 시스템 동작 트리거
Resources 정보 질의 (Read-only) resources/list, resources/read 문서 조회, 데이터 확인, 질의 응답
Prompts 출력 구조 제어 (Template) prompts/list 응답 형식 통일, 스타일 변환

2.4.1 Tools (기능 실행 단위)

  • MCP 서버가 외부 시스템의 실행 가능한 기능(API, 스크립트, 명령어 등)을 Wrapping하여 제공하는 단위
  • 모든 툴은 다음과 같은 메타데이터 구조를 포함함:
{
  "name": "search_documents",
  "description": "검색어에 기반하여 조직 내 문서 중 관련 항목을 반환",
  "parameters": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "description": "검색 키워드" },
      "limit": { "type": "integer", "default": 5 }
    },
    "required": ["query"]
  }
}
  • 호출은 다음 방식으로 수행됨:
{
  "method": "tools/call",
  "params": {
    "name": "search_documents",
    "arguments": {
      "query": "MCP 구조 설계"
    }
  }
}
  • 서버는 스키마에 따라 입력을 검증하고 실행한 뒤, 결과를 반환함
  • 호출 결과는 때로 리소스의 ID로 연결되어 Resources와 연계 동작 가능함
  • 예: search_documents 툴이 리소스 ID 배열을 반환 → 모델이 해당 문서를 resources/read로 질의
# 클라이언트 → MCP 서버: 문서 검색 기능 호출 요청
{
  "jsonrpc": "2.0",
  "id": "req-001",
  "method": "tools/call",
  "params": {
    "name": "search_documents",
    "arguments": {
      "query": "MCP architecture",
      "limit": 3
    }
  }
}

# MCP 서버 → 클라이언트: 문서 검색 결과 반환
{
  "jsonrpc": "2.0",
  "id": "req-001",
  "result": {
    "documents": [
      {
        "id": "doc-001",
        "title": "MCP Architecture Overview",
        "url": "https://example.com/docs/arch"
      },
      {
        "id": "doc-002",
        "title": "Design Principles of MCP",
        "url": "https://example.com/docs/design"
      }
    ]
  }
}

2.4.2 Resources (정보 질의 단위)

  • 서버가 보유한 읽기 중심 자원을 모델이 조회할 수 있도록 제공하는 구조
  • 예시 자원 유형: 정책 문서, 회의록, API 명세서, 로그 파일, 유저 프로필 등
  • 자원 목록 조회(resources/list)와 개별 조회(resources/read)로 구성됨
  • resource meta data는 다음과 같은 JSON 객체로 구성됨:
{
  "id": "doc-001",
  "name": "MCP_사양_버전2.0",
  "description": "최신 프로토콜 구조 정리",
  "type": "markdown",
  "metadata": {
    "created_at": "2024-12-01",
    "size_kb": 148
  }
}
  • resource content "resources/read"를 통해 요청하며, 결과는 다음과 같이 반환됨:
{
  "jsonrpc": "2.0",
  "id": "xyz-789",
  "result": {
    "content": "# MCP 사양 설명\n\n이 문서는 MCP의 구조와 동작 방식을 설명한다...",
    "content_type": "markdown"
  }
}

Resources는 Tools와 연결되어, 툴의 실행 결과를 리소스로 변환하거나, 리소스 ID를 인자로 받는 툴도 구현 가능함 

# 클라이언트 → MCP 서버: Resource 목록 요청
{
  "jsonrpc": "2.0",
  "id": "req-002",
  "method": "resources/list",
  "params": {}
}

# MCP 서버 → 클라이언트: 사용 가능한 Resource 목록 응답
{
  "jsonrpc": "2.0",
  "id": "req-002",
  "result": {
    "resources": [
      {
        "id": "doc-001",
        "name": "MCP_Spec_v2.0",
        "description": "Latest MCP protocol specification",
        "type": "markdown",
        "metadata": {
          "created_at": "2024-12-01",
          "size_kb": 148
        }
      },
      {
        "id": "doc-002",
        "name": "Agent_Workflow_Guide",
        "description": "LLM-based tool orchestration guide",
        "type": "pdf",
        "metadata": {
          "created_at": "2024-11-15",
          "size_kb": 92
        }
      }
    ]
  }
}

# 클라이언트 → MCP 서버: 특정 Resource 본문 요청
{
  "jsonrpc": "2.0",
  "id": "req-003",
  "method": "resources/read",
  "params": {
    "id": "doc-001"
  }
}

# MCP 서버 → 클라이언트: Resource 본문 응답
{
  "jsonrpc": "2.0",
  "id": "req-003",
  "result": {
    "content": "# MCP Specification v2.0\n\nThis document describes...",
    "content_type": "markdown"
  }
}

2.4.3 Prompts (출력 구조 제어 단위)

  • MCP 서버가 제공하는 형식화된 프롬프트 템플릿 집합
  • 출력 형식, 스타일, 언어 변환, 포맷 제약 등 출력 안정성과 일관성 확보에 기여
  • 프롬프트는 {input} 등의 변수 슬롯을 포함하여 템플릿 형태로 제공됨:
{
  "name": "summarize_with_bullets",
  "description": "텍스트를 항목 나열 형식으로 요약",
  "template": "다음 내용을 핵심 항목으로 요약하세요:\n\n{input}"
}
  • 프롬프트는 모델의 출력 전처리(pre-prompt), 또는 출력 후 후처리(post-process)에 활용됨
  • 실무에서는 Claude, Codeium 등에서 코드 설명, 정책 요약 등 결과 포맷 표준화에 사용됨
# 클라이언트 → MCP 서버: Prompt 목록 요청
{
  "jsonrpc": "2.0",
  "id": "req-004",
  "method": "prompts/list",
  "params": {}
}

# MCP 서버 → 클라이언트: Prompt 목록 응답
{
  "jsonrpc": "2.0",
  "id": "req-004",
  "result": {
    "prompts": [
      {
        "name": "summarize_with_bullets",
        "description": "Summarize the content into bullet points",
        "template": "Summarize the following into bullets:\n\n{input}"
      },
      {
        "name": "translate_to_korean",
        "description": "Translate English text to Korean",
        "template": "다음을 한국어로 번역하세요:\n\n{input}"
      }
    ]
  }
}

2.5 MCP 서버 구현자를 위한 호출 구조 요약

MCP 서버는 클라이언트가 LLM에 기능을 연결할 수 있도록 다음 항목을 명시적으로 제공해야 함:

항목 설명
툴 목록 각 툴의 이름, 설명, 입력 인자 스키마, 응답 구조 요약
자원 목록 자원 ID, 이름, 설명, 메타데이터(JSON), 읽기 가능 여부
프롬프트 목록 프롬프트 이름, 설명, 템플릿 문자열
에러 반환 구조 JSON-RPC 명세에 따른 표준 에러 코드, 메시지, 선택적 보조 정보(data)

예시 스키마 구조는 다음과 같이 정리됨:

  • Tool:

    • name: 호출용 이름 (string)
    • description: 자연어 설명 (string)
    • parameters: JSON Schema 구조 (object)

  • Resource:

    • id: 고유 식별자
    • metadata: 문서 타입, 크기, 날짜 등

  • Prompt:

    • template: 입력 변수를 포함하는 문자열

2.6 요약

  • MCP는 모델과 외부 시스템 간의 상호작용을 구조화하고, 기능 호출, 자원 질의, 출력 통제를 분리된 방식으로 지원함
  • Tools / Resources / Prompts의 삼분 구조는 LLM 중심 시스템이 실제 환경과 동적으로 연결되는 통제 가능 구조를 제공함
  • JSON-RPC 기반 통신 방식, 클라이언트-서버 분리 설계, 명세 기반 호출 구조는 확장성과 일관성, 예측 가능성을 동시에 확보함
  • MCP 서버는 명세 중심의 메타데이터 제공자 역할을 수행하며, 클라이언트는 이를 기반으로 모델의 도구 활용 흐름을 구성함

3. MCP 아키텍처 및 구성 요소

‌

3.1 클라이언트–서버 구조와 기술적 책임 분리

  • MCP는 모델이 외부 기능과 자원에 접근할 수 있도록 돕는 context bridging layer이며, client-server architecture 기반으로 구성됨

  • MCP Client는 LLM 또는 Agent 내부에 내장되어, 모델이 호출하고자 하는 외부 기능 요청을 JSON-RPC 형식으로 생성함

  • MCP Server는 외부 기능, 자원, 템플릿 등을 실제로 보유하고 실행하는 backend 역할을 하며, JSON-RPC 메시지를 수신하고 처리함

  • 클라이언트는 lightweight adapter 역할을 하며, 서버는 실제 실행 책임을 가짐

  • 이 구조는 다음 목적을 달성하기 위해 설계됨:

    • 모델이 외부 시스템의 구조를 몰라도 기능을 호출할 수 있도록 추상화 제공
    • 실행 권한 및 리소스 접근 통제를 서버에서 일괄 처리
    • 호출 인터페이스를 JSON 기반으로 표준화하여 플랫폼/언어 독립성 확보

  • MCP Server는 다음 네 가지 자산 유형을 통해 기능을 제공함:

    1. Tool: 외부 기능을 실행하는 도구
    2. Resource: 읽기 전용 자산 (문서, 로그 등)
    3. Prompt: 출력 형식을 통제하는 템플릿
    4. Meta Endpoint: 구조 탐색과 상태 관리를 위한 엔드포인트

3.2 Tool Registry

개념

  • Tool은 LLM이 실행 가능한 외부 기능 단위이며, API, 스크립트, 계산기, 검색기 등 모든 외부 작업이 Tool로 표현될 수 있음
  • Tool은 MCP Server 내에서 고유한 이름을 가지며, JSON Schema로 입력 형식을 정의하고, 실제 실행을 담당하는 핸들러와 연결됨
  • MCP Client는 "tools/call" 메서드를 통해 도구를 호출하며, 서버는 Tool 메타데이터를 기반으로 요청을 검증하고 실행함

설계 목표

  • 정형화된 입력 구조 제공: JSON Schema 기반의 파라미터 정의를 통해 LLM이 예측 가능한 호출 구조를 학습할 수 있도록 지원
  • 핸들러의 확장성과 독립성: 각 Tool은 독립된 핸들러 함수와 연결되며, 서버 확장 시 플러그인 구조로 관리 가능
  • 네임스페이스 기반 분리: Tool 이름이 "nlp/summarize", "db/query_user"처럼 prefix 형태로 구성되어 모듈 간 충돌 방지

필드 구성

  • name: 호출 식별자 (고유)
  • description: 기능 설명 (자연어)
  • parameters: JSON Schema
  • handler: 기능 실행 핸들러

예시 호출 흐름

  1. 클라이언트가 tools/list를 통해 사용 가능한 도구 목록을 수신
  2. 모델이 특정 Tool 호출을 결정하고 tools/call로 JSON 요청 전송
  3. 서버는 Tool 존재 여부 확인 → 입력 인자 검증 → 핸들러 실행
  4. 실행 결과를 result 필드에 담아 응답
# MCP 서버 내에서 Tool을 데코레이터 기반으로 등록
@tool(name="search_documents", description="문서를 검색하는 기능")
def search_documents(query: str, limit: int = 5):
    # 실제 문서 검색 로직
    return {
        "documents": [
            {"title": "MCP 스펙 문서", "url": "https://docs.example.com/mcp"},
            {"title": "에이전트 아키텍처 설계", "url": "https://docs.example.com/agent"}
        ]
    }
    
# MCP 클라이언트 → 서버: Tool 호출 요청 
{
  "jsonrpc": "2.0",
  "id": "req-001",
  "method": "tools/call",
  "params": {
    "name": "search_documents",
    "arguments": {
      "query": "MCP 구조 설계",
      "limit": 2
    }
  }
}

3.3 Resource Store

개념

  • Resource는 MCP Server에 저장되어 있는 읽기 전용 정보 자산이며, LLM이 이를 조회할 수 있도록 구성됨
  • 자산 유형에는 문서, 정책 파일, 대화 로그, 설정 값, 코드 조각 등이 포함됨
  • 모델은 직접 파일을 읽을 수 없기 때문에, 자원을 식별자(ID) 기반으로 간접 조회하는 방식으로 설계됨

설계 목표

  • 리소스 탐색 가능성 확보: resources/list를 통해 어떤 문서가 있는지 탐색 가능
  • 내용 접근 구조화: resources/read를 통해 본문을 읽으며, content-type을 통해 포맷 제어 가능
  • 실행 흐름 연결: Tool 실행 결과가 Resource ID를 반환하고, 이를 모델이 다시 read 호출로 사용하는 연동 가능성 고려

필드 구성

  • id: 고유 자원 식별자
  • name: 제목 또는 문서명
  • description: 간략 요약
  • metadata: 생성일, 타입, 크기 등
  • content: 리소스 본문
  • content_type: text/markdown, application/json 등
# Resource Store에 문서를 등록하는
resource_store.add_resource({
    "id": "doc-001",
    "name": "MCP_Spec_v2.0",
    "description": "MCP 프로토콜 명세 문서",
    "metadata": {
        "type": "markdown",
        "created_at": "2024-12-01",
        "size_kb": 148
    },
    "content": load_file("resources/mcp_spec.md"),
    "content_type": "text/markdown"
})

# 클라이언트 → MCP 서버: 특정 Resource 본문 요청
{
  "jsonrpc": "2.0",
  "id": "req-003",
  "method": "resources/read",
  "params": {
    "id": "doc-001"
  }
}

# MCP 서버 → 클라이언트: Resource 본문 응답
{
  "jsonrpc": "2.0",
  "id": "req-003",
  "result": {
    "content": "# MCP 프로토콜 v2.0\n\n이 문서는 MCP의 구조를 설명한다...",
    "content_type": "text/markdown"
  }
}

3.4 Prompt Library

개념

  • Prompt는 모델의 출력 형식을 통제하거나, 출력 구조를 일정하게 유지하기 위한 템플릿 단위
  • LLM은 종종 동일한 요청에도 다양한 표현을 생성하므로, 특정 스타일이나 양식이 필요한 경우 Prompt를 활용함
  • {input}과 같은 변수 슬롯을 포함하며, 모델 입력에 삽입되는 방식으로 동작

설계 목표

  • 출력 제어 구조화: 응답 양식, 언어, 요약 방식 등을 정형화된 방식으로 모델에게 전달
  • 프롬프트 재사용성: 템플릿을 반복 사용 가능하여 프롬프트 구성의 일관성 확보
  • 전처리/후처리 다양화: 모델 응답 전에 붙는 pre-prompt, 이후 응답 처리용 post-prompt를 구분 가능

필드 구성

  • name: 템플릿 식별자
  • description: 용도 설명
  • template: 문자열 템플릿
# Prompt 템플릿 등록
prompt_library.add_prompt({
    "name": "summarize_with_bullets",
    "description": "텍스트를 항목 나열 방식으로 요약",
    "template": "다음을 핵심 항목으로 요약하세요:\n\n{input}"
})

# 클라이언트 → MCP 서버: Prompt 목록 요청
{
  "jsonrpc": "2.0",
  "id": "req-004",
  "method": "prompts/list",
  "params": {}
}

3.5 Meta Endpoint Handlers

개념

  • MCP는 도구 그 자체뿐만 아니라, 그 구조와 상태에 대한 introspection 기능을 제공
  • MCP Client가 서버에 연결되면 가장 먼저 구조 탐색을 통해 도구/리소스/프롬프트 목록을 요청함
  • Meta Endpoint는 상태 확인, 초기화, 종료, 기능 목록 조회 등의 역할을 수행

주요 메서드

  • tools/list: 등록된 Tool 목록
  • resources/list: Resource 목록
  • prompts/list: Prompt 목록
  • initialize: 초기화 요청
  • ping, shutdown: 상태 확인 및 종료
# MCP 클라이언트 → 서버: initialize 후 tools 목록 요청
{
  "jsonrpc": "2.0",
  "id": "req-005",
  "method": "tools/list",
  "params": {}
}

# MCP 서버 → 클라이언트: tools 목록 응답
{
  "jsonrpc": "2.0",
  "id": "req-005",
  "result": {
    "tools": [
      {
        "name": "search_documents",
        "description": "문서를 키워드로 검색",
        "parameters": {
          "type": "object",
          "properties": {
            "query": {"type": "string"},
            "limit": {"type": "integer"}
          },
          "required": ["query"]
        }
      }
    ]
  }
}

3.6 요청 처리 흐름

  • MCP Server는 JSON-RPC 메시지를 수신하면 다음 절차로 처리함:
  1. 메시지 파싱 및 필드 유효성 검증 (jsonrpc, id, method, params)
  2. 메서드 유형 확인 후 적절한 핸들러 또는 모듈로 디스패치
  3. Tool/Resource인 경우, parameters를 JSON Schema로 검증
  4. 실행 결과를 JSON 객체로 반환 (result 또는 error)
  • 모든 오류는 JSON-RPC 에러 포맷을 따름
# MCP 서버 내 요청 처리 함수 예시 (디스패치 + 예외처리)
def dispatch_request(request):
    try:
        validate_rpc_schema(request)
        method = request["method"]
        handler = registry.get_handler(method)
        args = request["params"]["arguments"]
        validate_params(handler, args)
        result = handler(**args)
        return success_response(request["id"], result)
    except ValidationError as ve:
        return error_response(request["id"], -32602, "Invalid parameters", ve.errors())
    except ToolNotFound as e:
        return error_response(request["id"], -32601, str(e), {"available": registry.list_names()})
    except Exception as e:
        log.exception("Unhandled error")
        return error_response(request["id"], -32603, "Internal server error", {"trace_id": uuid4().hex})

3.7 Middleware 및 확장 전략

Middleware 개념

  • 실무에서는 로깅, 인증, 성능 측정 등을 위해 미들웨어 구조가 필요
  • 요청이 디스패치 되기 전/후에 개입할 수 있는 구조를 통해 유연한 운영이 가능

확장 전략

  • Tool 핸들러를 모듈 단위로 플러그인화하여 외부에서 자동 로딩 가능
  • Prompt는 다국어 템플릿 또는 사용자 정의 스타일 세트로 확장 가능
  • Resource backend는 DB, S3, 파일 시스템 등으로 교체 가능
# Middleware 체인 예시
def middleware_chain(request):
    for middleware in global_middlewares:
        request = middleware(request)
    return dispatch_request(request)

# 예시 Middleware
def logging_middleware(request):
    log.info(f"Incoming request: {request['method']}")
    return request

def auth_middleware(request):
    token = request.get("auth_token")
    if not validate_token(token):
        raise Unauthorized("Invalid auth token")
    return request

# 미들웨어 등록
global_middlewares = [auth_middleware, logging_middleware]

3.8 MCP Host 환경 구성 및 클라이언트 통신 흐름

‌

MCP는 Client–Server 구조를 기반으로 동작하지만, 실질적인 모델 실행 환경에서는 MCP Host의 개념이 중요한 역할을 담당함. 이 Host는 사용자의 입력을 수신하고, 내부에 포함된 MCP Client를 통해 외부 MCP Server와 통신하며, 모델이 외부 기능 및 자원과 상호작용할 수 있도록 함.

3.8.1 MCP Host의 개념 및 위치

  • MCP Host란?
    모델(LLM 또는 Agent)이 구동되는 주체이자, MCP 메시지를 전송하는 클라이언트 역할을 수행하는 실행 환경임.
    예: Claude Desktop, Cursor, Sourcegraph Cody 등

  • 기능 요약

    • 사용자 입력 수신 및 파싱
    • MCP 클라이언트를 통해 메시지 구성 및 전송
    • MCP 서버 응답을 모델 응답으로 변환
    • 툴/리소스 목록 초기화 및 캐싱
    • 요청 ID 추적, 세션 관리 등 실행 상태 유지

  • 클라이언트와 서버의 구분

    • MCP Server: 기능 제공자(API, DB, 파일 등)
    • MCP Host(Client 포함): 모델 실행 및 기능 요청 발신자

3.8.2 Claude Desktop의 MCP Client 구성 방식

Claude Desktop은 Anthropic에서 제공하는 로컬 실행형 LLM 환경이며, 내부에 MCP Client를 포함하고 있어 외부 MCP Server와의 통신이 가능함.

사용자는 로컬 설정 파일(claude_desktop_config.json)을 통해 어떤 MCP Server를 실행하고 연결할 것인지 지정할 수 있음.

예시: MCP Server 설정 구성

  • Filesystem MCP: 로컬 디렉토리 연결
  • GitHub MCP: 원격 레포지토리 연결
  • Slack MCP: 대화 데이터 접근
# claude_desktop_config.json 설정 파일 구성 예시
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",  // MCP 서버 실행에 사용할 명령어 (Node.js 환경 필요)
      "args": [
        "-y",  // 자동 확인 플래그 (npx 실행 시 prompt 생략)
        "@modelcontextprotocol/server-filesystem",  // 사용할 MCP 서버 모듈 (파일 시스템 접근용)
        "/Users/your_username/src"  // 노출할 로컬 디렉토리 경로
      ]
    }
  }
}
  • Claude Desktop이 MCP 서버를 통해 이 경로를 접근 가능하도록 설정
  • 실행 시 Claude가 list_directory, read_file 등의 명령을 이 디렉토리에 대해 수행 가능해짐

3.8.3 Claude Desktop의 실행 흐름

Claude에서 사용자 입력이 발생하면, 내부 MCP Client가 이를 MCP 호출 메시지(JSON-RPC 형식)로 구성하여 지정된 서버로 전송함.

예시 시나리오: ~/src 디렉토리의 파일 목록을 나열

  • Claude가 MCP Filesystem 서버에 list_directory 호출 요청 전송
  • MCP Server는 지정된 경로를 탐색 후 파일 목록 반환
  • Claude는 이를 요약하여 사용자에게 자연어로 응답
# JSON-RPC 기반 툴 호출 메시지 예시 및 응답 구조
{
  "jsonrpc": "2.0",  // JSON-RPC 프로토콜 버전 (MCP는 이 포맷 기반으로 통신함)
  "id": "req-list-dir",  // 호출 요청 식별자 (응답 매핑을 위함)
  "method": "tools/call",  // 호출 방식 (MCP는 툴 호출 시 항상 이 메서드 사용)
  "params": {
    "name": "list_directory",  // MCP 서버에 등록된 툴 이름
    "arguments": {
      "path": "/Users/your_username/src"  // 호출에 필요한 인자 (디렉토리 경로)
    }
  }
}
  • MCP 서버에 “list_directory”라는 툴이 사전에 정의되어 있어야 동작
  • 결과는 지정된 경로에 존재하는 파일 및 폴더 목록 반환

3.8.4 사용자 정의 MCP Host 구현 전략

만약 Claude Desktop처럼 직접 MCP Host를 구현하고자 한다면 다음 요소가 필요함:

  • 모델 실행 엔진
    예: OpenAI API, HuggingFace Transformers, Llama.cpp 등

  • MCP Client 구성

    • tools/list, tools/call, resources/read 등의 JSON-RPC 메시지 구성기
    • 요청/응답 ID 추적기
    • 서버 연결 상태 모니터링

  • 프롬프트 파서 또는 에이전트 루프

    • 사용자 입력 → MCP 호출 흐름으로 변환
    • 툴 명세 기반으로 가능한 기능 추천/선택
    • 모델 출력 후 후처리 및 응답 반환

  • 예시 기술 스택

    • Python 기반 CLI 또는 데스크탑 GUI
    • LLM 호출 API 내장
    • Requests, WebSocket 기반 MCP 클라이언트 모듈
# MCP 요청 메시지 생성기 및 툴 명세 탐색기 구성 예시

import uuid
import requests

MCP_SERVER_URL = "http://localhost:3000"  # MCP 서버 주소 (로컬에서 실행 중인 MCP 서버)

def call_tool(tool_name: str, arguments: dict, session_id: str = None):
    # JSON-RPC 요청 메시지 구성
    payload = {
        "jsonrpc": "2.0",
        "id": str(uuid.uuid4()),  # 고유 ID 생성 (응답 식별용)
        "method": "tools/call",
        "params": {
            "name": tool_name,  # 호출할 MCP Tool 이름
            "arguments": arguments  # 호출에 필요한 인자 (사전 구조)
        }
    }
    if session_id:
        payload["params"]["session_id"] = session_id  # 선택적으로 세션 ID 포함

    # MCP 서버로 요청 전송
    response = requests.post(MCP_SERVER_URL, json=payload)
    return response.json()  # JSON 응답 반환
  • MCP 서버에 툴 호출 요청을 보내고 결과를 받는 클라이언트 역할
  • Claude Desktop 내부에서도 유사한 로직 사용 중
# MCP 툴 메타데이터 탐색기
def list_tools():
    payload = {
        "jsonrpc": "2.0",
        "id": str(uuid.uuid4()),  # 요청 ID 생성
        "method": "tools/list",  # MCP 메타데이터 요청 메서드
        "params": {}
    }
    response = requests.post(MCP_SERVER_URL, json=payload)
    return response.json()["result"]["tools"]  # 툴 목록 반환
  • MCP 서버에 등록된 툴 목록과 각 툴의 명세(JSON Schema)를 클라이언트가 수신
  • 모델이나 클라이언트가 “어떤 기능이 있는가?“를 이 과정을 통해 학습
MCP Host CLI 예제 (Claude Desktop 대체 가능 구조)
def interactive_loop():
    print("MCP Host CLI 시작. 'exit' 입력 시 종료.")
    while True:
        user_input = input("질문: ")  # 사용자 입력 대기
        if user_input.lower() == "exit":
            break

        # 예: 파일 목록 요청
        if "파일" in user_input and "목록" in user_input:
            result = call_tool("list_directory", {"path": "/Users/your_username/src"})
            for entry in result["result"]["entries"]:
                print(f"- {entry['name']} ({entry['type']})")
        else:
            print("해당 입력에 대한 MCP Tool 미정의.")
  • Claude Desktop 없이도 터미널 기반 MCP 클라이언트를 구현할 수 있는 최소한의 예시
  • 실제 Claude는 이와 유사한 방식으로 MCP 서버에 메시지를 전송함
  • 커맨드라인 기반 Host에서 쉽게 응용 가능

3.8.5 요약: Host는 통합 실행 환경의 중심

MCP는 단순한 RPC 구조지만, Host 환경의 설계는 전체 시스템 통합의 핵심임:

  • 모델 인터페이스 + 사용자 인터페이스 + MCP 클라이언트가 결합된 구조
  • 실행 상태 추적, 오류 대응, 세션 유지 등 실무 구현에서 중요
  • Claude, Cursor, WindSurf와 같은 고급 Host는 내부에 로깅, 미들웨어, 결과 후처리 등을 포함한 통합 구조를 지님

따라서 실무에서 MCP를 도입할 경우, Server만이 아니라 Host 구성 전략까지 함께 고려해야 안정적이고 확장 가능한 시스템을 설계할 수 있음.

3.9 요약

  • MCP 아키텍처는 기능 단위의 명확한 책임 분리를 기반으로 구성되며,
    Tool / Resource / Prompt / Meta Handler는 서로 다른 역할을 담당
  • JSON-RPC 메시지 기반 통신을 통해 구현 언어 독립성과 구조 일관성을 확보
  • 각 구성 요소는 JSON 기반 메타데이터로 설명되며, 모델은 이를 탐색하고 호출하는 구조를 스스로 구성 가능
  • 실무에서는 핸들러 등록, 미들웨어 체인, 예외 처리, 템플릿 관리 등 실제 운영 전략까지 고려된 확장 구조가 적용됨

4. MCP 실제 적용 사례

4.1 Claude AI: 로컬 및 외부 시스템 연결을 위한 MCP 활용

  • Claude AI는 Anthropic에서 개발한 LLM 기반 AI 어시스턴트로, 사용자의 작업 맥락에 따라 다양한 외부 도구 및 데이터를 호출할 수 있도록 설계되었음 → 이를 위해 Claude는 MCP를 통해 Google Drive, Slack, GitHub, 파일 시스템 등의 리소스에 접근 가능한 구조를 채택함.
  • 특히 Claude Desktop 앱에서는 MCP Filesystem 서버를 로컬에서 구동함으로써, 사용자가 지정한 디렉토리(예: ~/src)에 Claude가 직접 접근하여 디렉토리 탐색, 파일 열람, 요약 작성 등을 수행할 수 있음.
  • 이는 Claude가 단순히 입력 텍스트만이 아니라 실제 사용자의 프로젝트 폴더와 그 내부 파일 구조를 파악하고 분석하는 데 사용됨.

→ Claude가 MCP Filesystem 서버를 통해 로컬 프로젝트 목록을 파악하고 요약문서를 생성하는 예시가 실제 사용 사례로 존재
→ Anthropic은 Google Drive, GitHub, Slack 등 주요 시스템을 위한 MCP 서버 구현체 및 SDK도 공개 배포함

출처:
Rick Hightower, Setting up Claude Filesystem MCP, Spillwave Solutions (2024-11-30)
https://medium.com/@richardhightower/setting-up-claude-filesystem-mcp-80e48a1d3def 

# Claude + MCP Filesystem 예시

# Claude Desktop 설정을 위한 MCP Filesystem 구성 예시
# 사용자 홈 디렉토리 내 특정 폴더를 MCP 서버로 노출

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/YOUR_USERNAME/src"
      ]
    }
  }
}

# Claude에게 보낼 요청 예시
{
  "jsonrpc": "2.0",
  "id": "claude-001",
  "method": "tools/call",
  "params": {
    "name": "list_directory",
    "arguments": {
      "path": "/Users/YOUR_USERNAME/src"
    }
  }
}

4.2 ZenML: ML 파이프라인 제어를 위한 MCP Server 도입

  • ZenML은 MLOps 파이프라인을 관리하는 오픈소스 플랫폼으로, 2025년부터 MCP 기반 서버를 정식 도입하여 LLM과의 통합을 지원함.

  • ZenML MCP Server는 Claude, Cursor, WindSurf와 같은 MCP 클라이언트를 통해 자연어 기반 질의 및 실행 요청을 처리할 수 있음.

  • 초기 버전은 read-only 중심으로 구성되어 있으며, 다음과 같은 작업이 가능함:

    • 파이프라인 목록, 스택 구성, 아티팩트, 실행 이력 등을 자연어로 탐색
    • 특정 파이프라인의 실행 성공률, 리소스 사용량 비교 등 요약 리포트 생성
    • run template 기반으로 파이프라인 실행 요청 수행 (제한적 write 기능)

→ ZenML MCP Server는 현재 로컬 환경에서 구동되며, 향후 OAuth 인증 및 원격 실행 기능도 roadmap에 포함됨.
개발자 가이드를 통해 직접 MCP 서버를 설정하고, Claude와 연동하여 실시간 ML 파이프라인 분석을 수행할 수 있음.

ref:
Alex Strick van Linschoten, Chat With Your ML Pipelines: Introducing the ZenML MCP Server, ZenML Blog (2025-03-10)
https://www.zenml.io/blog/chat-with-your-ml-pipelines-introducing-the-zenml-mcp-server

#시] ZenML MCP 서버로 파이프라인 상태 질의

# Tool 호출 예시: 파이프라인 실행 이력 요약 요청
{
  "jsonrpc": "2.0",
  "id": "zenml-001",
  "method": "tools/call",
  "params": {
    "name": "summarize_pipeline_runs",
    "arguments": {
      "pipeline_name": "simple_pipeline",
      "metrics": ["run_duration", "success_rate"]
    }
  }
}

# 응답 예시
{
  "jsonrpc": "2.0",
  "id": "zenml-001",
  "result": {
    "summary": "The 'simple_pipeline' has run 12 times in the past 2 weeks, with an 83% success rate. The average duration is 4m 22s."
  }
}

4.3 Sourcegraph Cody: IDE 기반 컨텍스트 확장

  • Sourcegraph의 Cody는 개발자 IDE 내에서 AI 기반 코드 지원을 제공하는 에이전트이며, 2024년 11월부터 Anthropic MCP를 지원하여 외부 시스템의 컨텍스트를 코드 작성 환경에 직접 통합할 수 있게 되었음.

  • MCP를 통해 연결 가능한 외부 MCP 서버는 다음과 같음:

    • GitHub, Git, Linear: 이슈, 커밋, 코드 변경 이력
    • Postgres, SQLite: DB 스키마 확인 및 쿼리 기반 코딩 지원
    • Google Drive: 문서 요약 및 코드 참조용 자료 연동
    • Filesystem: 로컬 파일 탐색 및 분석

→ 이러한 MCP 서버는 OpenCtx 설정을 통해 Cody에 연결되며, 개발자는 IDE 내에서 대화형 명령을 통해 직접 DB 쿼리를 생성하거나 이슈를 추적하고 관련 코드를 자동 완성할 수 있음.
-> 또한, Linear MCP 서버를 예제로 MCP 서버를 Node.js 기반으로 직접 구현하는 가이드도 제공됨.

ref:
Chris Sev, Cody supports additional context through Anthropic's Model Context Protocol, Sourcegraph Blog (2024-11-25)
https://sourcegraph.com/blog/cody-supports-anthropic-model-context-protocol 

# Sourcegraph Cody + Postgres MCP 서버 통합

# Tool 등록 예시 (MCP 서버 내부 Python 코드)
@tool(name="query_table_schema", description="특정 테이블의 스키마를 반환합니다")
def query_table_schema(table_name: str):
    # 실제 DB 연결 및 조회 생략
    schema = get_schema_from_postgres(table_name)
    return {"schema": schema}

# MCP 클라이언트에서 요청 예시
{
  "jsonrpc": "2.0",
  "id": "cody-001",
  "method": "tools/call",
  "params": {
    "name": "query_table_schema",
    "arguments": {
      "table_name": "users"
    }
  }
}

# 응답 예시
{
  "jsonrpc": "2.0",
  "id": "cody-001",
  "result": {
    "schema": {
      "id": "INTEGER",
      "name": "VARCHAR(100)",
      "created_at": "TIMESTAMP"
    }
  }
}

4.4 기업 내부 시스템과의 연동 가능성

  • MCP는 이론적으로 Postgres, Jenkins, Prometheus, Kubernetes 등의 다양한 사내 시스템과도 연동 가능한 범용 구조를 지님.

  • 현재 Anthropic 및 오픈소스 커뮤니티는 MCP 서버 SDK(TypeScript, Python 등)를 통해 자체 MCP 서버 구현을 지원하고 있음.

  • 이를 활용하면 다음과 같은 MCP Tool을 정의하여 사내 Agent 시스템과 통합될 가능성이 있음:

    • Kubernetes: get_pods, scale_deployment, get_logs
    • Jenkins: trigger_job, get_job_status
    • Prometheus: query_metric, alert_status
    • Postgres: run_query, describe_table

→ 다만 현재까지는 이러한 MCP 서버가 공식 배포되거나 상용화된 사례는 부족하며, 일부 기업/커뮤니티에서 실험적 또는 맞춤형으로 자체 구현을 진행 중인 단계임.

→ MCP 기반 시스템 통합은 보안 인증, 권한 제어, 상태 관리 등의 요건을 함께 고려해야 하므로, 장기적으로는 OAuth, Server Sent Events(SSE) 기반 통신, name spacing 등 확장 기능이 요구될 수 있음.

ref:
Anthropic, Model Context Protocol Introduction (2024-11-25)
https://www.anthropic.com/news/model-context-protocol 

# 사내 시스템(Postgres) MCP Tool 호출 예시

# MCP 서버에서 Postgres 질의용 Tool 등록 예시 (Python)
@tool(name="run_query", description="SQL 쿼리를 실행합니다")
def run_query(sql: str):
    conn = psycopg2.connect(...)
    cursor = conn.cursor()
    cursor.execute(sql)
    result = cursor.fetchall()
    return {"result": result}

# MCP 클라이언트 호출 메시지 예시
{
  "jsonrpc": "2.0",
  "id": "internal-001",
  "method": "tools/call",
  "params": {
    "name": "run_query",
    "arguments": {
      "sql": "SELECT COUNT(*) FROM users WHERE active = true"
    }
  }
}

# 응답 예시
{
  "jsonrpc": "2.0",
  "id": "internal-001",
  "result": {
    "result": [[128]]
  }
}

4.5 MCP 사용 사례의 시사점 및 구조적 패턴

  • Claude, ZenML, Sourcegraph 모두 MCP를 활용해 기능 호출, 문서 질의, 코드 맥락 연동 등의 작업을 구조화된 방식으로 지원함

  • 공통적으로, 다음과 같은 패턴이 반복됨:

    • LLM은 초기 연결 시 MCP Server로부터 기능 목록(JSON Schema 기반)을 수신
    • 사용자의 입력을 구조화하여 Tool 호출 또는 Resource 질의로 변환
    • 결과는 다시 프롬프트 기반 후처리로 사용자에게 제공됨

  • MCP는 단순 API 호출을 넘어서 도구 명세화 + 통신 구조화 + 호출 추론 가능성 확보라는 세 가지 설계를 모두 만족시키는 연결 계층임

  • 이러한 사례들은 MCP가 단순한 통신 프로토콜을 넘어 범용 AI 에이전트 통합 인터페이스로 작동할 수 있음을 보여주며, 향후 다양한 산업 분야에서의 확장 가능성을 시사함.

5. 기존 접근 방식과의 비교 분석

MCP는 대형 언어 모델이 외부 기능을 구조화된 방식으로 호출할 수 있도록 지원하는 통신 프로토콜임
도구 호출의 안정성, 구조화 가능성, 호출 흐름 추적성 확보를 위해 설계됨

기존에는 LangChain, GPT Script 등 다양한 접근 방식이 존재하며,
개발자 편의성이나 빠른 도입 측면에서 강점을 보이나 구조적 확장성과 신뢰성 측면에서는 한계를 드러냄

본 장에서는 대표적인 방식인 GPT Script 및 LangChain LangGraph와 MCP를 비교함

5.1 GPT Script와의 비교

개념
GPT Script는 LLM의 기능 사용 흐름을 자연어 기반 DSL(Domain-Specific Language)로 선언하는 방식
프롬프트 체계 위에 간결한 명령 구문을 정의하여 모델이 사용할 수 있도록 설계됨
OpenAI Function Calling 기반 구조와 잘 호환되며, 함수 흐름을 간결하게 구성 가능함

장점

  • 자연어에 가까운 문법으로 빠르게 도구 호출 흐름 구성 가능
  • 기존 프롬프트 체계에 쉽게 통합되어 초보자 진입 장벽 낮음
  • 단순 함수 호출에는 높은 간결성과 가독성 제공

한계

  • 호출 흐름이 프롬프트 해석에 의존하여 예측 가능성 및 안정성 낮음
  • 파라미터 스키마의 정적 검증 어려움, 호출 실패 원인 추적 불가
  • 도구 버전 관리, 역할 분리, 다중 클라이언트 재사용에 취약
  • 통신 수준의 권한 제어, 인증 처리, 호출 이력 관리 기능 부재

MCP의 보완 지점

  • 구조화된 JSON-RPC 메시지를 통해 도구 호출의 명시성 확보
  • 호출 인자에 대한 JSON Schema 기반 정적 검증 가능
  • Tool/Resource/Prompt의 독립적 명세 등록을 통해 기능 재사용 및 관리 용이
  • 요청-응답 단위 로그 추적 가능, 상태 유지 및 호출 이력 기록 구조 내장
  • 자연어 기반 스크립팅은 GPT Script가 간결하지만, 실무 적용에서는 명확성과 추적 가능성이 우선됨
# GPT Script 호출 예시 vs MCP 호출 예시

# GPT Script 스타일 (자연어 기반 DSL)
# 명령은 자연어 문법에 가까우며 호출 구조가 명확하지 않음

call function "search_documents" with
  query = "MCP architecture"
  limit = 3

# MCP JSON-RPC 스타일 호출 예시 (명세 기반)
{
  "jsonrpc": "2.0",
  "id": "req-001",
  "method": "tools/call",
  "params": {
    "name": "search_documents",
    "arguments": {
      "query": "MCP architecture",
      "limit": 3
    }
  }
}

5.2 LangChain 기반 호출 방식과의 비교

개념
LangChain은 LLM 기반 응용 시스템을 위한 파이썬 프레임워크로,
도구 호출, 체인 구성, 에이전트 실행 등 다양한 기능을 유연하게 통합 가능함
기능 단위는 Tool로 구성되며, 체인 또는 AgentExecutor를 통해 실행 흐름을 제어함

장점

  • 도구 호출, 프롬프트 체인, 상태 저장 등을 코드 기반으로 유연하게 구성 가능
  • 프롬프트 중심 워크플로우 설계에 적합
  • OpenAI function calling, Retrieval-Augmented Generation 등과 자연스럽게 통합 가능

한계

  • Tool 정의가 코드 내부에 종속되어 있어 다른 시스템에서 재사용 불가
  • 호출 스펙이 구조화되어 있지 않으며, 입력 인자 검증 및 자동 문서화 어려움
  • 호출 흐름의 예측 가능성 낮고, 상태 유지 및 호출 이력 추적 기능 미비
  • 각 에이전트별 호출 체계가 상이하여 일관된 운영 체계 구축에 제약

MCP의 보완 지점

  • Tool 정의를 JSON 기반 명세로 분리하여 다양한 시스템에서 공유 가능
  • 구조화된 호출 메시지를 통해 실행 경로의 안정성과 예측 가능성 확보
  • 호출 흐름 추적, 상태 유지, 인증, 권한 제어 등 운영 관점 기능 내장 가능
  • LangChain 내부에서 MCP 기반 Tool 호출을 적용함으로써 체계화 가능
### [5.2.1 코드예시] LangChain Tool 구조 vs MCP Tool 구조

# LangChain에서의 Tool 등록 예시
from langchain.agents import tool

@tool
def get_user_profile(user_id: str) -> dict:
    """Fetch user profile from internal system"""
    return {"user_id": user_id, "name": "Alice", "role": "Engineer"}

# 호출 예시: 에이전트 또는 체인 내부에서 직접 호출

# MCP 스타일 Tool 명세 및 호출 구조
@tool(name="get_user_profile", description="사용자 ID로 프로필을 조회")
def get_user_profile(user_id: str):
    return {
        "user_id": user_id,
        "name": "Alice",
        "role": "Engineer"
    }

# 호출 메시지 예시
{
  "jsonrpc": "2.0",
  "id": "req-005",
  "method": "tools/call",
  "params": {
    "name": "get_user_profile",
    "arguments": {
      "user_id": "U12345"
    }
  }
}

5.3 비교 요약

GPT Script와 LangChain은 도구 호출 흐름을 구성하는 데 있어 각각 장점을 갖춘 접근 방식임.
다만 구조화된 호출 명세, 기능 재사용성, 호출의 예측 가능성과 같은 운영적 요구에서는 MCP가 나을 수 있음.
MCP는 구조적 요구를 보완하고, 호출 계층을 명시적으로 분리하여 확장 가능성을 높임

비교 대상 개념 장점 구조적 한계 MCP 보완
GPT Script 자연어 기반 호출 흐름 DSL 빠른 개발, 쉬운 진입 추론 기반 호출, 흐름 불명확, 검증 불가 구조화된 명세 기반 호출, 정적 검증, 로그 추적
LangChain 파이썬 기반 체인/에이전트 구조 조건 제어, 체인 구성 유연함 툴 재사용성 낮음, 호출 명세 분리 어려움 도구 명세 분리, 다중 시스템 공유, 명확한 호출 경로 
# LangChain 호출 흐름 내 MCP 통합 방식
# LangChain Tool 정의
from langchain.agents import tool

@tool
def analyze_logs(log_id: str) -> dict:
    return {"summary": "분석 결과 요약"}

# LangChain Agent에서 MCP로 분리된 도구 호출 구조를 흉내내는 방식
import requests
import uuid

def call_mcp_tool(tool_name: str, arguments: dict):
    payload = {
        "jsonrpc": "2.0",
        "id": str(uuid.uuid4()),
        "method": "tools/call",
        "params": {
            "name": tool_name,
            "arguments": arguments
        }
    }
    response = requests.post(MCP_SERVER_URL, json=payload)
    return response.json()["result"]

# LangChain 내부에서 MCP 호출 연계 예시
def run_agent(query):
    # MCP를 통해 분석 도구 호출
    result = call_mcp_tool("analyze_logs", {"log_id": "log-123"})
    return result["summary"]
  • 위 구조를 통해 LangChain 기반 호출 흐름에 구조화된 도구 호출 계층을 통합할 수 있으며, 도구 정의와 호출 흐름의 분리, 명세 기반 검증, 호출 로그 추적 등의 이점을 추가적으로 확보 가능함

5.4 기존 방식으로 MCP의 구조를 대체할 수 있는가?

MCP는 구조화된 호출 인터페이스를 제공하는 데 초점을 두고 설계되었지만, 실제 현업에서는 GPT Script, LangChain 등 기존 방식만으로도 유사한 구조를 구성하려는 시도가 존재함.

GPT Script로 구조화 호출 구성 시도

  • 자연어 기반 DSL을 활용하여 도구 호출 흐름을 간결하게 표현 가능
  • 프롬프트 체계 내에서 직관적인 함수 호출 흐름을 구성할 수 있음
call function "search_documents" with
  query = "MCP 설계 문서"
  limit = 3

call function "read_document" with
  document_id = "doc-001"

장점

  • 간단한 툴 호출에는 매우 직관적이고 학습 곡선이 낮음
  • OpenAI function-calling 구조와의 호환성이 높아 빠르게 도입 가능
  • 코드 없이도 모델 기능 흐름을 선언적으로 설계할 수 있음

단점

  • 호출 명세나 인자 스키마가 구조화되어 있지 않아, 호출 실패 시 원인 추적 및 정적 검증이 어려움
  • 도구 정의가 분리되어 있지 않아, 여러 모델/클라이언트 간 재사용이 어려움
  • 호출 흐름이 완전히 모델의 추론에 의존하므로, 안정적인 실행 환경이 요구될 경우 적용에 유의 필요

LangChain을 활용한 구조화 시뮬레이션

  • LangChain의 Tool 체계를 사용하면 LLM이 외부 기능을 호출하도록 구성 가능
  • AgentExecutor 또는 SequentialChain 등을 통해 호출 흐름도 설계 가능
# LangChain에서의 도구 등록 예시
from langchain.agents import tool

@tool
def search_documents(query: str, limit: int = 5) -> dict:
    # 내부 문서 검색 로직
    return {"results": ["doc-001", "doc-002"]}

@tool
def read_document(document_id: str) -> str:
    return "문서 내용 요약"

# 도구 호출 흐름 구성 (예: AgentExecutor, SequentialChain 등으로 흐름 구성)

장점

  • 파이썬 환경에서 매우 유연하게 기능을 구성할 수 있음
  • 상태 유지, 조건 분기 등은 체인 단위로 논리적 제어 가능
  • 프롬프트 기반 에이전트 체계와 자연스럽게 연결 가능

단점

  • 도구의 호출 명세가 코드 내부에 내장되어 있어 구조 분리가 어려움
  • 다양한 클라이언트에서 같은 도구를 공유하거나 문서화하는 데 한계
  • 호출 흐름이 프롬프트 및 체인 구성에 의존하여, 실행 경로의 예측 가능성 및 안정성이 상대적으로 낮음
  • 인증, 호출 이력 기록, 멀티세션 관리 등 운영 측면 기능은 별도 구현 필요

MCP의 보완적 역할

GPT Script나 LangChain 기반 구조는 빠른 개발, 반복 실험, 에이전트 워크플로우 구축에는 매우 적합함 .
다만, 다음과 같은 요구사항이 중요해지는 환경에서는 MCP가 보완적 역할을 수행할 수 있음:

  • 기능 호출의 예측 가능성과 명세 기반 검증이 필요한 경우
  • 도구 정의와 클라이언트를 명확히 분리하여 확장성과 재사용성을 확보하고자 할 경우
  • 시스템 간 통신 안정성, 인증, 호출 이력 관리 등의 요구가 있는 경우
  • 모델이 기능 명세를 스스로 탐색하고 호출 흐름을 자율적으로 구성해야 하는 경우

MCP는 기존 도구와 경쟁적인 대안이라기보다는, 기능 호출 계층의 명시성과 구조화를 강화하고, 다양한 호출 환경에서의 일관성과 확장성을 지원하는 보완적 프레임워크로 이해하는 것이 바람직함

6. MCP 실무 도입 전략

MCP는 모델이 외부 기능을 명세 기반으로 호출하고, 안정적인 도구 연동을 가능하게 하는 통신 계층임.
실제 도입 시에는 시스템 구조, 보안 요구, 운영 흐름에 맞는 설계 및 전략적 판단이 요구됨.
실무 중심의 도입 시나리오 분류와 함께 기술적 고려사항, 운영 전략, 자동화 방식 등을 포함한 MCP 도입 전략 고민 필요

6.1 도입 시나리오 유형 구분

도입 유형 설명 핵심 고려사항
내부 시스템 연동형 조직 내 DB, 파일 서버, 로그 시스템과 연결 보안 정책, 접근 제어, 감사 로그
외부 SaaS API 통합형 Slack, Notion, GitHub 등 외부 서비스와 통합 토큰 관리, 응답 지연, API 제약
멀티모델·멀티클라이언트 지원형 Claude, GPT, LangChain 등 다양한 클라이언트에서 공유 명세 일관성, 호출 결과의 중립화
워크플로우 자동화 연계형 ZenML, IDE 등에서 Agent 기반 실행 흐름 구성 호출 상태 유지, 에러 복원 구조

6.2 MCP 서버 설계 시 고려사항

MCP 서버는 단순한 RPC 수신기 역할이 아니라, 호출 명세 등록자 및 흐름 통제자의 역할 수행

  • 도구 스키마 설계

    • 모든 도구는 JSON Schema로 입력/출력 정의 필요

    • 에러 케이스, 기본값, 선택 필드 포함 

      # yaml
# tools/search_documents.yaml
name: "search_documents"
description: "검색어 기반 문서 조회"
parameters:
  type: object
  properties:
    query:
      type: string
      description: 검색 키워드
    limit:
      type: integer
      default: 5
  required: ["query"]

  • 도구 명명 및 네임스페이스 설계

    • 예: finance/generate_report, user/query_profile
    • 클라이언트 간 호출 충돌 방지, 기능 그룹화

  • 상태 관리 구조 선택

    • 단일 요청 기반(stateless) 또는 세션 기반(stateful) 선택

    • Redis 또는 local in-memory store 연계 시 구현 예시: 

      # Redis를 활용한 세션 컨텍스트 저장 예시
import redis
redis_client = redis.Redis()

def save_context(session_id, key, value):
    redis_client.hset(session_id, key, value)

def load_context(session_id, key):
    return redis_client.hget(session_id, key)

  • 인증 및 권한 설계

    • API Key, OAuth, 사용자별 권한 맵핑 필요

    • 클라이언트 ID 기반 ACL 구성 고려 

      def verify_api_key(request):
    api_key = request.get("auth_token")
    if api_key not in authorized_keys:
        raise Unauthorized("Invalid API Key")

  • 호출 이력 기록 및 에러 추적

    • 요청 ID, timestamp, 사용자 ID, 호출 대상, 결과/에러 구조 기록

    • 운영 분석, 보안 감사 기반으로 활용 

      log_data = {
    "timestamp": time.time(),
    "request_id": request["id"],
    "method": request["method"],
    "user_id": request.get("user_id"),
    "result": result,
}
save_to_audit_log(log_data)

6.3 도입 환경별 기술적 구성 전략

환경 유형 기술적 특성 MCP 구성 고려사항
로컬 환경 Claude Desktop, Cursor 등과 연동 파일 시스템 접근 권한, 사용자 격리
내부망 서버 조직 내 LLM 또는 Agent와 연동 TLS 인증, 프록시 구성, 내부 IP 제한
퍼블릭 클라우드 외부 호출 기반, 대규모 사용자 지원 WebSocket/SSE, 비동기 메시징 큐, rate limiting

6.4 운영 자동화 및 확장 전략

  • 도구 등록 자동화

    • .mcp/tools/*.yaml 내 정의된 스키마 자동 스캔 및 등록

    • CI 파이프라인 연계 가능 

      # tools 디렉터리 스캔 후 자동 등록
for file in glob("tools/*.yaml"):
    with open(file) as f:
        tool_def = yaml.safe_load(f)
        tool_registry.register(tool_def)

  • 플러그인 기반 핸들러 모듈화

    • tools/<name>.py 구조에서 핫스왑 가능한 플러그인 로딩

    • 신규 기능 추가 시 재시작 불필요 구조 설계 

      # tools directory 내 플러그인 핸들러 자동 로딩
import importlib.util

for file in glob("handlers/*.py"):
    spec = importlib.util.spec_from_file_location("handler", file)
    module = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(module)
    registry.load_from_module(module)

  • 모델 적응형 명세 전달

    • 클라이언트 모델 유형에 따라 설명 텍스트 조정
    • 프롬프트 템플릿 및 파라미터 포맷 커스터마이징 지원

  • 복합 호출 흐름 템플릿 구성

    • 여러 도구 호출을 묶은 virtual tool 생성
    • 예: search_and_summarize, query_and_generate_plot

6.5 실무 도입 체크리스트 요약

항목 설명
도구 스키마 명세화 JSON Schema 기반 입력/출력 구조 정의
인증 구조 API Key 또는 OAuth 기반 클라이언트 인증
호출 로그 기록 요청-응답 기록, 에러 트레이싱 포함
상태 관리 구조 세션 기반 LLM 연동 시 필요
도구 네임스페이스 그룹별 분리 및 충돌 방지
자동 등록 구조 도구 디렉터리 스캔, CI/CD 연계
핫스왑 플러그인 구조 유지보수성과 확장성 향상

6.6 요약

  • MCP 실무 도입은 단순한 API 연결이 아닌, 기능 명세화 및 시스템 계층 분리 구조를 도입하는 작업
  • MCP 서버는 명세 등록자, 호출 관리자, 실행 통제자 역할을 동시에 수행함
  • 실무 도입 시에는 시스템 환경, 인증 요구, 호출 흐름, 보안 정책에 따라 전략적 설계가 요구됨
  • 도입 이후에는 등록 자동화, 핸들러 모듈화, 템플릿 구성 등으로 유지보수성과 확장성 강화 가능

7. MCP의 한계 및 향후 발전 방향

  • Model Context Protocol(MCP)은 LLM 환경에서 외부 도구, 자원과의 연결을 구조화된 방식으로 지원함으로써 도구 호출 명세화, 호출 추적성, 확장 가능한 모듈화 구조 등 강점을 지님.
  • 그러나 현재 생태계와 명세의 수준에서 구조적·기능적 한계가 존재함

7.1 인증 및 보안 구조 미비

  • MCP 명세는 인증(authentication) 및 권한 제어(authorization)를 포함하지 않음
  • 클라이언트의 호출 요청은 서버의 자체 로직에 의해 검증되어야 하며, 프로토콜 수준에서의 인증 메커니즘 부재
  • 이에 따라 실무에서는 별도 API Key, JWT, OAuth를 외부에서 통합 구현해야 함

“MCP does not include native authentication or authorization logic, leaving it up to the implementer.”
— Merge.dev, 2024

보완 방향:

  • OpenID Connect, OAuth2.1 기반의 호출 인증 구조 공식화 필요
  • 호출 메시지에 `auth_token` 필드 명시  
  • 서버단에서 토큰 검증 미들웨어 구현
# 인증 미들웨어
def auth_middleware(request):
    token = request.get("auth_token")
    if token not in allowed_tokens:
        raise Unauthorized("Invalid or missing API Key")
    return request

# 미들웨어 체인 적용
global_middlewares = [auth_middleware, logging_middleware]

7.2 에러 처리 표준화 부족

  • MCP는 호출 실패 시 error 필드만 지정하되, 에러 코드/타입/레벨/보조 메시지 등에 대한 구조화된 정의 미비
  • 서버마다 임의의 에러 메시지와 구조를 사용하여, 클라이언트에서 일관된 예외 처리 곤란

“Each implementer defines their own error schemas. There's no standard for classifying or describing tool errors.”
— Merge.dev, 2024

보완 방향:

  • JSON-RPC의 기본 에러 코드 외에, MCP 전용 오류 분류 체계 정의 필요
  • 표준 오류 코드 + 메시지 + 보조 필드(`data`) 포함  
  • tool_validation_error, auth_failed, rate_limit_exceeded 등 정형 에러 코드를 enum으로 저장
def error_response(id, code, message, data=None):
    return {
        "jsonrpc": "2.0",
        "id": id,
        "error": {
            "code": code,
            "message": message,
            "data": data
        }
    }

# 예: 도구 파라미터 오류
return error_response(
    id="req-001",
    code=1001,
    message="Invalid tool arguments",
    data={"missing": ["query"]}
)

7.3 이벤트 기반 호출 구조 부재

  • MCP는 기본적으로 요청-응답 기반 RPC이며, Webhook, Push, Stream 등의 비동기 구조 미포함
  • 실시간 데이터 갱신이나 툴 실행 완료 이벤트를 수신하는 구조 부재

“MCP lacks any webhook or pub/sub mechanism, which makes real-time event propagation very hard.”
— Merge.dev, 2024

보완 방향:

  • notify 또는 subscribe 유형의 메시지 구조 도입
  • Server-Sent Events(SSE), WebSocket 기반 확장 옵션을 프로토콜 명세에 포함
# Flask-SSE 기반 서버 구현 예시
@app.route('/events')
def sse_stream():
    def generate():
        for message in sse_queue:
            yield f"data: {json.dumps(message)}\n\n"
    return Response(generate(), mimetype='text/event-stream')

# 서버 내 이벤트 전송
sse_queue.append({
    "type": "tool_result",
    "tool": "analyze_logs",
    "result": {"summary": "이상 없음"}
})

7.4 컨텍스트 지속성 및 고부하 대응 구조 미흡

  • 세션 ID 또는 사용자 컨텍스트 유지 기능 미포함  
  • 고빈도 요청 또는 다단계 워크플로우에서 컨텍스트 유지 곤란

“High-throughput contexts require persistent session management, which is currently outside MCP's scope.”
— Portkey.ai, 2024

보완 방향:

  • session_id, context_id 필드를 공식 메시지 구조에 포함
  • LLM 컨텍스트 연계와 Tool 상태 공유를 위한 세션 저장소 연동 명세 추가
# 요청 메시지 예시
{
  "jsonrpc": "2.0",
  "id": "abc-123",
  "method": "tools/call",
  "params": {
    "name": "get_report",
    "arguments": {
      "month": "2024-12"
    },
    "session_id": "sess-xyz-987"
  }
}

# 세션 저장 및 로딩
session_data = redis.get("sess-xyz-987")  # 이전 호출 결과 포함

7.5 Tool Registry 구조의 모호함

  • MCP 서버에서 tools/list를 통해 사용 가능한 도구 목록을 제공하지만, 도구의 버전, 네임스페이스, 의존성 등 복잡한 레지스트리 기능은 미제공

보완 방향:

  • version, dependencies, namespace 필드추가
  • 중앙 MCP Registry 서버 구축을 통한 공개 Tool 검색, 검증, 캐싱 지원
{
  "name": "search_documents",
  "version": "1.2.3",
  "description": "문서를 검색합니다.",
  "namespace": "doc",
  "parameters": {
    "type": "object",
    "properties": {
      "query": { "type": "string" }
    },
    "required": ["query"]
  },
  "dependencies": ["auth_token"]
}

7.6 요약

항목 현재 한계 개선 방향
인증 체계 없음 OAuth2, API Key 스펙 공식화
에러 처리 서버별 임의 구조 MCP 에러 코드 체계 제안
이벤트 기반 호출 미지원 SSE/Webhook 메시지 구조 도입
상태 관리 외부 구현 필요 세션 ID, 컨텍스트 연계 구조화
툴 등록 체계 단순 나열 Tool 버전 관리, Registry 구조 도입

7.7 장기적 발전 방향

  • 표준 기반 인증 구조 통합 (OAuth2.1, OpenID Connect)
  • MCP Tool Registry 생태계 구축 및 인증된 공개 툴 공유
  • Agent 프레임워크와의 상호호환 계층 표준으로 성장 가능
  • 비동기 응답, 푸시 메시징 등 LLM 통합 환경에 맞춘 구조 확장

ref:
– Merge.dev MCP
– Portkey MCP
– ModelContextProtocol.io

8. 결론

Model Context Protocol(MCP)은 대형 언어 모델(LLM)이 외부 시스템과 구조화된 방식으로 상호작용할 수 있도록 설계된 통신 프로토콜임. 도구 호출, 자원 질의, 출력 제어를 명세 기반으로 처리함으로써, 모델 기반 에이전트 시스템의 안정성과 확장성을 확보할 수 있는 기반 기술로 평가됨

‌

MCP는 기존 LangChain, GPT Script와 같은 흐름 중심 프레임워크와 비교하여, 기능 호출 계층에 집중된 구조적 강점을 지니며 다음과 같은 특징을 가짐:

  • 기능 호출의 예측 가능성과 명시적 명세 구조 확보
  • 도구와 자원의 구분, 상태 기반 컨텍스트 유지 구조 지원
  • 인증, 로깅, 네임스페이스 등 실무에 필요한 운영 기능 확장 가능성 보유

‌

MCP는 여전히 초기 생태계를 구성하는 기술이며, 다음과 같은 발전이 요구됨:

  • 인증/권한/오류 처리/비동기 응답 등 프로토콜 범위의 확장
  • Agent 프레임워크 간 상호운용 구조로의 성장

‌

결론적으로, MCP는 단일 도구가 아닌 기능 호출 구조를 표준화하는 연결 계층이며,
향후 LLM 기반 시스템의 신뢰성과 운용성을 좌우하는 핵심 기술로 자리매김할 가능성이 높음

→ 실무에서는 단기적으로 도구 명세화 및 호출 일관성 확보 수단으로 도입 가능
→ 장기적으로는 에이전트 구조 표준화, 인증 통합, 운영 자동화 체계로 확장 가능

9. Appendix

9.1 Naive RAG - Claude Desktop

  • 개념도
┌─────────────────────────────┐
│        사용자(User)         │
│ ───────────────────────── ▶ │ 자연어 질의 입력
└─────────────────────────────┘
                │
                ▼
┌─────────────────────────────┐
│      Claude Desktop (LLM)   │ ◀───────────────┐
│  + MCP Client 내장          │                 │
└─────────────────────────────┘                 │
       │                                        │ 초기화 시
       ▼                                        │ Tool 목록, 프롬프트 수신
┌─────────────────────────────┐                 │
│     MCP Filesystem Server   │ ────────────────┘
│ (e.g. list_directory, read_file 등)           │
└─────────────────────────────┘
       │
       ▼
┌─────────────────────────────┐
│       Local File System     │
│   ~/src, ~/docs, etc.       │
└─────────────────────────────┘
  • 사용자는 Claude Desktop에 자연어로 질문을 입력
  • Claude는 MCP를 통해 로컬 MCP Filesystem Server에 연결된 도구(list_directory, read_file 등)를 활용
  • 서버는 실제 디렉토리 탐색, 파일 열람 등을 수행한 뒤 결과를 Claude에 반환
  • Claude는 결과를 분석해 사용자에게 요약, 정리된 답변을 생성함
  1. Claude 설정 파일 작성 (Mac)
~/.Library/Application\ Support/Claude/claude_desktop_config.json

# claude_desktop_config.jso
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/YOUR_USERNAME/src"
      ]
    }
  }
}
  • command: "npx": MCP 서버를 Node.js 환경에서 실행함
  • @modelcontextprotocol/server-filesystem: 공식 Filesystem MCP 서버
  • /Users/YOUR_USERNAME/src: Claude가 접근 가능한 실제 디렉토리
  1. MCP Filesystem Tool 정의

 

# MCP 서버 내부 Tool 예시: list_directory
{
  "name": "list_directory",
  "description": "디렉토리 내 파일 목록을 반환합니다.",
  "parameters": {
    "type": "object",
    "properties": {
      "path": {
        "type": "string",
        "description": "탐색할 디렉토리 경로"
      }
    },
    "required": ["path"]
  }
}
  1. 사용자의 자연어 기반 쿼리
"내 ~/src 디렉토리 안에 어떤 파일이 있는지 알려줘"
  1. Claude 내부 처리 흐름
# Claude가 내부적으로 MCP 호출 요청
{
  "jsonrpc": "2.0",
  "id": "req-001",
  "method": "tools/call",
  "params": {
    "name": "list_directory",
    "arguments": {
      "path": "/Users/YOUR_USERNAME/src"
    }
  }
}
  1. MCP 서버 응답 예시
# MCP Filesystem 서버 응답
{
  "jsonrpc": "2.0",
  "id": "req-001",
  "result": {
    "files": [
      "project-markdown-creator",
      "diagrams",
      "openai-java",
      "resume-writer"
    ]
  }
}
  1. Claude 최종 응답 생성
'~/src' 디렉토리에는 다음과 같은 프로젝트가 있습니다:
- project-markdown-creator
- diagrams
- openai-java
- resume-writer
필요한 프로젝트에 대해 더 자세히 알아보시겠어요?

‌