1. MCP란 무엇인가?

Anthropic에서 처음 제안되었으며, MCP(Model Context Protocol)는 LLM 기반 에이전트 시스템에서 모델이 외부 세계와 상호작용할 수 있도록 컨텍스트를 주고받는 방식을 표준화한 프로토콜입니다.

그런데 이렇게 설명하면 어렵기만 할 것 입니다. 우리 MCP 단어부터 시작합시다!

세 단어 Model, Context, Protocol은 각각 MCP 구조에서 매우 중요한 역할을 상징합니다. 아래에 각 구성 요소가 실제 시스템에서 어떤 기능을 수행하며, 전체적으로 어떤 의미를 갖는지 상세히 설명드리겠습니다.

1. Model – "행동 주체"

• Model은 LLM (Large Language Model), GPT, Claude, LLaMA 같은 대규모 언어 모델.

• 사용자의 입력을 이해하고, 행동 계획을 세우며, 필요할 경우 도구를 호출하고, 최종적으로 응답을 생성하는 중앙 지능체.

• 기능 요약

기능	설명
사용자 입력 해석	자연어 입력을 분석하고, 의도를 파악합니다.
도구 사용 판단	이 요청을 자체 지식으로 처리할지, 외부 툴이 필요한지 판단합니다.
Tool 호출 계획	필요 시 MCP Server의 Tool을 어떤 순서와 파라미터로 호출할지 계획합니다.
응답 생성	툴 호출 결과를 받아 적절한 사용자 응답을 생성합니다.

2. Context – "행동 기반 정보"

• Context는 LLM(Model이)이 작업을 수행하는 데 필요한 배경 정보.

• 여기에는 툴 목록, 리소스(문서, 로그, DB 스키마), 대화 히스토리, 사용자 설정 등 모든 참조 가능한 데이터가 포함됨.

• LLM에게 "지금 너는 이런 툴을 쓸 수 있어", "이 문서를 참고할 수 있어", "응답은 이렇게 써야 해"라는 작업 환경을 알려줍니다. LLM은 이 Context를 바탕으로 정확한 행동을 설계.

• 구성 요소 요약

종류	설명	예시
Tool 목록	사용할 수 있는 외부 기능들	search_web, create_issue, send_email
Resource	읽기 전용 외부 정보	로그, 사내 정책 문서, FAQ, 메일 내역
Prompt Template	응답 형식이나 LLM에게 줄 규칙	"답변은 항상 표 형식으로"

3. Protocol – "행동 방식"

• Protocol은 LLM이 단순한 질문 응답을 넘어, 외부 API 호출, 데이터 조회, 툴 사용 등 복잡한 작업까지 수행할 수 있도록 지원하는 통신 규약.

• MCP는 이를 JSON-RPC 2.0 형식으로 설계.

• LLM이 단순히 "이 툴을 써줘"라고 하는 것이 아니라, 정해진 문법에 따라 정확한 명령 형식으로 요청을 전달하고, 응답을 받도록 함

• 이를 통해 툴 간 호환성, 보안성, 디버깅 가능성 확보

• 주요 기능 요약

항목	설명
요청(Request)	Model → Tool에 작업 요청 보내기 (예: method: "send_email")
응답(Response)	Tool → Model에 결과 반환 (예: result: "메일 전송 완료")
알림(Notification)	Tool → Model에게 상태 업데이트 전달
초기화(Handshake)	MCP Client와 Server 간 기능 목록, 버전 협상 등 수행

4. 요약 정리

구성 요소	의미	역할	비유
Model	LLM 자체	사용자 입력 해석, 행동 계획 및 응답 생성	두뇌
Context	외부 참조 정보	사용할 수 있는 툴, 문서, 프롬프트 등 작업 기반 정보	도구함 + 매뉴얼
Protocol	통신 규약	JSON-RPC 방식의 메시지 전달 방식	공통 언어/문법

📌 비유적 설명: MCP는 AI 모델과 도구를 연결하는 USB-C 포트와 같은 역할을 하며, 다양한 기능성 도구와 리소스를 손쉽게 연결할 수 있는 인터페이스를 제공합니다.

2. 탄생 배경

MCP가 등장하기 전까지는, LLM(대규모 언어 모델)을 기반으로 한 Agent를 만들 때 다음과 같은 심각한 문제가 있었습니다.

1. 각 프레임워크가 제각기 다른 방식으로 툴을 연동

LLM이 외부 작업(예: 검색, 이메일 전송, DB 조회 등)을 수행하려면 "Tool"이라는 외부 기능과 연결되어야 합니다.

그런데 프레임워크마다 이 Tool을 연결하는 방식이 다릅니다.

1. LangChain

# LangChain에서 @tool 데코레이터 사용 예시
from langchain.tools import tool

@tool
def add_numbers(a: int, b: int) -> int:
    """두 수를 더합니다."""
    return a + b

• @tool 데코레이터가 Python 함수에 붙으면서, LangChain에서 해당 함수를 "툴"로 자동 인식/등록합니다.
• 함수 시그니처(type hint)와 docstring으로부터 입력/출력 스키마가 자동 생성됩니다.

2. AutoGen

# AutoGen에서 register_for_llm 사용 예시
def multiply(a: int, b: int) -> int:
    """두 수를 곱합니다."""
    return a * b

assistant.register_for_llm(name="multiply", description="곱셈 함수")(multiply)
# 또는 실행용으로
user_proxy.register_for_execution(name="multiply")(multiply)

• 데코레이터 대신 register_for_llm, register_for_execution 등 메서드를 통해 툴 등록.
• 함수의 시그니처 정보가 자동으로 스키마로 변환되어 내부에서 사용됩니다.

3. OpenAI Agents SDK

# OpenAI Agents SDK의 툴 등록 예시
from openai import AssistantBuilder, tool
from pydantic import BaseModel

class AddInput(BaseModel):
    a: int b: int

@tool(name="add_numbers", description="두 수를 더합니다.")
def add_numbers(input: AddInput) -> int:
    return input.a + input.b

assistant = AssistantBuilder(tools=[add_numbers])

def multiply(a: int, b: int) -> int:
    """두 수를 곱합니다."""
    return a * b

assistant = AssistantBuilder(tools=[multiply])

• @tool 데코레이터(또는 함수 기반 DSL)로 툴 지정.
• 함수 기반 DSL이란, OpenAI Agents SDK에서 툴을 딥하게 래핑하거나 별도의 명시적 스키마 없이, Python 함수 정의(시그니처/type hint/docstring)를 그대로 활용.
• 입력 파라미터는 일반적으로 Pydantic 모델로 schema가 정의되어 명확성이 높음.
• Agent(assistant)는 tools 파라미터로 함수 핸들러를 받습니다.

4. HuggingGPT

# HuggingGPT에서 YAML 파일로 툴 정의 예시
- name: text_summarizer
  description: 긴 문서를 요약하는 도구입니다.
  parameters:
    - name: text
      type: string
      description: 요약할 문장
  returns:
    type: string
    description: 요약된 결과

• Python 코드가 아니라 YAML 문서로 툴을 선언적으로 정의.
• 이름, 설명, 입력/출력 타입을 명시적으로 작성.
• HuggingGPT가 이 파일을 읽어서 자동으로 툴 등록.

5. ChatGPT Plugin

# OpenAPI 명세 예시 (openapi.yaml 일부)
paths:
  /add:
    post:
      summary: 두 수를 더합니다.
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                a:
                  type: integer
                b:
                  type: integer
      responses:
        '200':
          description: 결과
          content:
            application/json:
              schema:
                type: object
                properties:
                  result:
                    type: integer

• OpenAPI(YAML/JSON) 형식으로 REST API 엔드포인트 정의.
• ai-plugin.json 메타 정보와 함께 ChatGPT에서 플러그인으로 인식 및 사용.
• REST, 인증, 각 API 경로의 인풋/아웃풋 스키마 등 명확하게 문서화 필요.

프레임워크	툴 등록 방식	주요 특징
LangChain	@tool 데코레이터, .bind_tools()	Python 함수에 데코레이터 적용 타입 힌트 및 docstring 기반 schema 자동 생성
AutoGen	register_for_llm(), register_for_execution() register_function()	메서드 기반 등록 함수 시그니처에서 schema 자동 생성 콜러/익스큐터 역할 분리
OpenAI Agents SDK	함수 기반 DSL + tools 파라미터 전달	Python 함수 기반 Pydantic schema 또는 자동 추론 MCP, OpenAPI 연동 지원
HuggingGPT	YAML 파일 정의	YAML 형식으로 툴 스키마 명시 함수 호출 정의를 선언적으로 등록
ChatGPT Plugin	OpenAPI 명세 + ai-plugin.json 플러그인 메타데이터	REST API를 OpenAPI 스펙으로 문서화 ai-plugin.json에 이름/설명/URL 등 명시

→ 같은 "검색 툴"이라도 프레임워크마다 다르게 만들어야 합니다.

• 툴을 프레임워크 간 공유하거나 재사용하는 것이 사실상 불가능
• 개발자나 팀이 툴을 새로 만들 때마다 중복 구현 발생

2. API 재구현 및 협업 어려움

문제 설명:

에이전트를 개발하는 여러 팀/조직이 동일한 기능(API 연동, DB 조회 등)을 만들고 있지만,

• 툴 등록 방식이 달라 표준화된 공유가 불가능
• 어느 한쪽 API 스펙이 변경되면, 다른 로직도 재 수정 유지보수 비용이 기하급수적으로 증가

예시:

• 팀 A는 LangChain 기반으로 호출 툴을 만들고,
• 팀 B는 AutoGen 기반으로 호출 툴을 만들었지만, 포맷이 맞지 않아 서로의 로직이 공유 불가능.

결과:

• 협업 시 “우리 방식에 맞게 다시 만들어주세요”가 빈번
• 에이전트 개발 생태계가 조직 단위로 고립

3. 생태계 단절 (툴 생태계가 고립됨)

문제 설명:

툴을 공유하고 유통할 수 있는 공통 플랫폼(마켓플레이스)가 없었기 때문에, 모든 팀과 기업이 자신만의 툴 생태계를 만들고 고립됨 (MCP 마켓플레이스: https://smithery.ai/)

예시:

• ChatGPT Plugin 생태계는 OpenAPI를 기반
• LangChain은 Python 함수 @tool 데코레이터, 함수에서 schema 추론 및 등록
• AutoGen은 데코레이터 없이 메서드로 함수 등록 ( register_for_llm/execution/tool )

결과:

• 하나의 툴을 만들고도 범용적으로 배포하거나 연결할 수 없음
• LLM 기반 에이전트 시스템의 생태계가 “너는 너, 나는 나” 식으로 단절

4. 이러한 문제를 해결하기 위한 해법: MCP

이러한 문제를 해결하고, 플러그형 Tool 연동과 에이전트 재사용을 가능하게 하는 공통 프로토콜로 MCP가 등장했습니다.

MCP가 하는 일	의미
Tool 등록 방식 통일	툴을 JSON-RPC 방식으로 정의하면, 어떤 플랫폼에서도 동일하게 사용 가능
Agent와 Tool 분리	Agent는 Tool의 존재만 알면 되고, Tool 구현 방식에는 관심 없음
Plug-and-Play	툴을 마치 플러그인처럼 끼워 넣고 바로 쓸 수 있음
툴 마켓플레이스화	Smithery를 통해 툴을 유통하거나 가져다 쓸 수 있음

각 나라가 다른 전기 콘센트를 쓰던 시절, 기기마다 어댑터가 필요했음
→ MCP는 모든 툴을 USB-C 규격으로 통일해주는 역할
→ 어떤 Agent든, MCP Tool이라면 그냥 "꽂아서" 쓸 수 있음

3. MCP의 구조: Host – Client – Server

MCP는 위 그림과 같이 세 가지 핵심 구성요소로 이루어집니다.

3-1. Host

정의: 사용자 인터페이스와 상호작용하는 LLM 애플리케이션
기능:

• 여러 MCP Client를 관리
• 사용자 입력 → LLM → Tool 호출 결과 → 최종 응답 생성
• 예: Claude Desktop, Cursor IDE

3-2. Client

정의: MCP Server와의 연결을 담당하며, 메시지 라우팅과 상태 관리를 수행하는 중간 계층

• “메시지 라우팅”이란?
  LLM이 "Tool을 써야겠다!"고 판단했을 때, MCP Client는 이 요청을 적절한 MCP Server에게 "어디로 보내야 할지 결정하고 전달"합니다.

  • 작동 예시
    → LLM → Client: "method": "send_email"
    → Client는 tool 목록(capabilities) 중에서 "send_email"을 제공하는 MCP Server A를 찾음
    → 이 메시지를 Server A에 JSON-RPC 포맷으로 전달
    → 비유: 네트워크 라우터처럼, 목적지에 따라 요청을 적절한 서버에 “라우팅(전달)”합니다.

• “상태 관리(Stateful Connection)”란? :
  MCP Client는 각 MCP Server와 단순히 요청-응답만 주고받는 게 아니라, 지속적인 연결과 문맥 정보를 유지하며 작동합니다.

  • 작동 예시
    → Server와의 연결 시, Tool 목록을 기억
    → Tool 사용 중 에러가 났을 때 상태 추적 가능
    → 여러 Tool을 연속 호출할 때, 앞에서 받은 응답을 다음 요청에 연결 가능
    → 비유: 통역사가 단순히 말만 번역하는 게 아니라, 상대방이 이전에 무슨 말을 했는지 기억하면서 상황에 맞게 연결해주는 것과 같음

기능:

• 단일 MCP Server와 stateful 연결
• 요청/응답 처리, capability 협상
• 예: OpenAI Agents SDK, mcp-agents, LangChain MCP Client
• 요약

기능	쉽게 말하면	역할
단일 Server와 상태 연결	"계속 연결 유지하며 기억도 함"	인증, 기능 목록, 이전 상태 저장
요청/응답 처리	"툴 요청 보내고 응답 받는 택배사"	메시지를 포맷팅해 전송하고 결과 받기
capability 협상	"서로 가능한 기능 주고받기"	MCP Server가 어떤 Tool을 제공하는지 알아내기

3-3. Server

정의: LLM이 호출 가능한 도구(Tool), 데이터 리소스(Resource), 프롬프트 템플릿을 제공

• 도구(Tools)
  툴은 MCP 서버가 외부 기능을 실행할 수 있도록 제공하는 인터페이스입니다. 사용자의 요청(prompt)을 MCP 클라이언트가 해석하여 특정 기능이 필요하다고 판단될 경우, 해당 툴을 호출하게 됩니다.

  • 동작 방식
    1. tools/list: MCP 서버가 제공할 수 있는 툴들의 목록을 조회.
    2. tools/call: 특정 툴을 호출하고 실행 결과를 반환.

• 데이터 리소스(Resources)
  MCP 서버가 제공 파일, DB, 코드 등 외부 참조 가능한 데이터를 제공하고, 클라이언트는 MCP 서버의 리소스에 접근하여 정보를 수집하고, 이를 사용자 응답에 활용할 수 있습니다.

  • 동작 방식
    1. resources/list: MCP 클라이언트는 먼저 MCP 서버에 리소스 목록을 요청.
    2. 이후 특정 리소스를 조회하는 resource fetch API를 통해 필요한 데이터를 가져옵니다. (ex: repo://openai/gpt4/contents/utils/file.py)

• 프롬프트 템플릿(Prompt Templates)
  프롬프트 템플릿은 LLM(Large Language Model)이 목적에 맞는 응답을 생성할 수 있도록 하는 지침 입력 양식입니다. MCP 서버에서는 클라이언트가 구조화된 방식으로 질문을 생성, 특정 작업에 최적화된 프롬프트를 재사용하기 위해 템플릿을 정의하고 제공합니다. 프롬프트 템플릿은 도구 호출이나 리소스 활용과 마찬가지로, LLM이 보다 정확한 인텐트 추론과 행동 유도(Action Induction)를 하도록 돕습니다.

기능:

• API 호출 도구 실행
• 외부 참조 데이터 제공
• 행동을 유도하는 프롬프트 템플릿 제공

4. MCP 동작 방식

MCP는 요청 유형에 따라 다음 두 가지 흐름으로 작동합니다.

4-1. 툴 호출 없이 LLM 응답

• 특징

  • 간단한 요약, 번역, Q&A 등에 해당
  • 별도의 외부 API 호출이나 서버 연동이 필요 없음

• 동작 흐름

  • 사용자 입력 → Host 수신 → LLM 자체 응답 생성 → 사용자에게 전달

4-2. 툴 호출 포함 – 외부 연동 기반 복잡 요청

• 특징

  • 외부 시스템, API, DB 등과 연동이 필요한 요청
  • 복잡한 파라미터 추출 및 처리 흐름 필요
  • LLM이 “툴 호출”을 통해 작업 위임

• 동작 흐름

1. 사용자 입력 → Host 수신

• 사용자의 요청(예: “이슈 생성해줘”)을 Host 애플리케이션이 수신

2. LLM → 툴 필요 판단 및 파라미터 추출

• LLM은 입력을 분석해 툴 사용 필요성을 판단
• 필요한 함수명 (예: github.create_issue)과 파라미터(JSON 형태)를 생성

3. Client → MCP Server에 JSON-RPC 요청

• LLM이 생성한 툴 명령을 바탕으로 MCP Client가 MCP Server에 JSON-RPC 호출
• 예: {"method": "github.create_issue", "params": {...}}

4. Server → 외부 API 실행 및 응답 반환

• MCP Server는 해당 method에 연결된 외부 API 실행
• 결과(예: issue URL, 상태 등)를 클라이언트에 반환

5. Client → Host → LLM → 사용자 응답 생성

• 받은 응답을 다시 LLM에게 전달하여 자연어 응답 생성
• 최종 응답을 사용자에게 전달

• 예시

1. “GitHub에 버그 수정 요청 이슈를 생성해줘”

2. LLM: github.create_issue(title="버그 수정 요청") 명령 생성

3. Client: MCP Server에 JSON-RPC 요청

4. Server: GitHub API 호출 → 이슈 생성

5. LLM: “이슈가 성공적으로 생성되었습니다” 응답 생성

4-3. 요약

구분	4-1. LLM 단독 응답	4-2. 툴 호출 기반 응답
대상	간단한 Q&A, 번역, 요약	외부 시스템 연동이 필요한 요청
흐름	사용자 → LLM → 응답	사용자 → LLM → MCP → 외부 API → LLM → 응답
장점	빠름, 간단함	복잡한 작업 처리 가능

5. reference

https://modelcontextprotocol.io/introduction
https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained/
https://www.workato.com/the-connector/what-is-mcp/