책쓰자. Part1 - 2 | AI Tech Blog

2장. MCP란 무엇인가

Model Context Protocol(MCP)은 인공지능 분야에서 최근 각광받고 있는 개방형 표준 프로토콜로, 대규모 언어 모델(LLM)과 외부 데이터 소스 및 도구 간의 원활하고 안전한 통합을 가능하게 한다. 특히 Agentic AI 시대에 접어들며, 단순 텍스트 생성에서 벗어나 외부 시스템과의 상호작용이 핵심이 되는 상황에서 MCP는 이러한 통합을 표준화된 방식으로 구현할 수 있게 해주는 중요한 기반 기술로 부상하고 있다.

이러한 구조적 전환은 특히 '에이전트릭 AI(Agentic AI)' 시대에 MCP의 중요성을 더욱 부각시킨다. 기존의 단순한 AI 응답 시스템에서 진화한 Agentic AI는 자율성과 목적 중심성을 갖춘 AI 에이전트를 의미하며, 단순히 입력에 반응하는 것에 그치지 않고 문제를 인식하고, 계획을 수립하며, 외부 리소스를 적극 활용하여 목표를 달성하는 능동적 실행 주체로 기능한다.

이 지점에서 기존의 '에이전트(Agent)' 개념과 'Agentic AI'의 차이를 구분해볼 필요가 있다. 일반적인 에이전트는 사용자의 요청에 따라 도구를 실행하거나 데이터를 가공하는 특정한 동작을 수행하는 컴포넌트다. 하지만 이러한 에이전트는 대부분 명시적 트리거나 사전 정의된 워크플로우에 따라 동작하며, 자율적인 판단이나 동적인 계획 수립 능력은 제한적이다.

Agentic AI는 사용자의 목표를 이해하고 그 목표 달성을 위해 필요한 수단(도구, 데이터, API 호출 등)을 스스로 탐색하고 구성한다. 이들은 내부 상태와 컨텍스트를 유지하며, 다단계 플랜을 설계하고 실행 흐름을 조절할 수 있다. 다시 말해, 단순한 작업 실행기가 아닌, 목적 지향적 의사결정자에 가까운 존재다.

다음은 LLM, Agent, Agentic AI 간의 차이를 간단히 비교한 표이다:

항목	LLM	Agent	Agentic AI
주체성	수동적 응답	제한적 실행	자율적 판단과 실행
실행 능력	텍스트 생성만 가능	지정된 도구 실행	도구 선택, 입력 구성, 결과 활용까지 자율 수행
목적 설정	명령 기반	고정된 흐름 수행	목표 수립 및 실행 가능
문맥 처리	짧은 문맥 유지	제한적 상태 유지	장기 컨텍스트와 상태 유지 가능
대표 사례	GPT-3, Claude 1	LangChain Agent	Claude 3 Tool Use, GPTs with Function Calling

MCP는 바로 이러한 Agentic AI가 외부 세계와 연결되어 실제 행동을 수행할 수 있도록 설계된 표준 프로토콜이다. LLM이 자신의 판단에 따라 적절한 도구를 선택하고 호출한다. 그리고 그 결과를 문맥에 반영하고 이어지는 추론에도 활용함으로써, 진정한 Agentic AI의 실행 기반을 마련한다.

Agentic AI는 복잡한 멀티턴 대화, 조건 분기, 상황 판단, 리소스 활용 등 고차원적인 작업 수행이 필요한 시대의 중심 기술로 부상하고 있으며, MCP는 그 핵심 실행 계층을 담당하는 표준 인터페이스로 자리 잡고 있다. MCP는 AI 모델이 단순히 텍스트 입력과 출력만을 다루던 기존 한계를 넘어, 실제 세계의 다양한 데이터와 시스템, 서비스에 직접 접근하여 보다 풍부하고 정확한 응답을 생성할 수 있도록 설계되었다.

2023년 이후, LLM은 단순한 질의응답 도구를 넘어 복합적인 작업을 수행하는 에이전트로 진화하고 있다. 예를 들어, LLM이 외부 도구를 호출하여 날씨를 조회하거나, 문서를 요약하거나, 이미지를 분석하는 등의 능력을 보여주면서 많은 개발자들이 이러한 에이전트 시스템을 직접 구축하고자 시도하고 있다.

하지만 기존의 LLM 기반 애플리케이션은 제한된 컨텍스트 정보만으로 작업을 수행했고, 새로운 데이터 소스나 도구와 연결하려면 각각 별도의 API나 라이브러리를 개발해야 했으며, 이로 인해 통합 과정이 복잡하고 확장성이 떨어졌다. 또한, 데이터 사일로 현상으로 인해 AI가 필요한 정보를 실시간으로 얻기 어려웠고, 다양한 플랫폼과의 호환성도 부족했다.

MCP는 이러한 문제를 해결하기 위해 등장했다. USB-C 포트가 다양한 기기를 표준화된 방식으로 연결하듯, MCP는 AI와 데이터 소스, 도구 간의 연결을 표준화하여, 한 번의 구현만으로 다양한 외부 리소스와의 통합을 가능하게 한다.

2.1 MCP 정의

MCP(Model Context Protocol)는 생성형 AI가 단순히 자연어 응답만 생성하는 단계를 넘어, 실제 세계에서 유의미한 행동을 수행하는 실행 주체(Agent)로 기능할 수 있도록 돕는 표준화된 실행 프로토콜이다. 여기서 핵심은 "실행"이라는 단어에 있다. LLM은 단순한 언어 모델이 아니라, 어떤 도구를 언제, 왜, 어떻게 실행할지를 판단하고 실행해야 하며, 그 일련의 과정을 사람이 아닌 LLM이 스스로 수행하게 만드는 것이 MCP의 목표다.

1. MCP는 왜 필요한가?

기존에는 사람이 다음과 같은 방식으로 도구를 제어했다:

날씨가 궁금하면 weather API를 호출하는 코드를 작성하거나
이미지를 설명하려면 vision 모델을 직접 호출하는 코드를 넣거나
문서 요약을 위해 특정 summary function을 하드코딩했다

이 방식은 다음과 같은 한계를 가진다:

프롬프트와 코드를 함께 설계해야 하므로 진입 장벽이 높다
도구 변경 시 매번 프롬프트와 파이프라인을 수정해야 한다
새로운 도구를 붙이기 위해선 별도의 인터페이스 설계가 필요하다

이러한 문제를 해결하기 위해 MCP는 다음을 추구한다:

"프롬프트는 인간이, 실행은 LLM이."

2. MCP의 핵심 구조: 도구는 구조화, 선택은 문맥 기반

MCP는 다음 세 가지 흐름을 자동화하는 데 초점을 맞춘다:

도구 선택 (Tool Selection)
LLM은 주어진 프롬프트와 대화 흐름을 바탕으로 사용 가능한 도구 목록 중 어떤 도구를 선택할지 판단한다
입력 구성 (Input Construction)
선택된 도구의 입력 스펙을 기반으로, 필요한 인자를 대화 흐름에서 자동 추론하여 구성한다
결과 통합 (Response Integration)
도구의 실행 결과는 다시 LLM의 다음 문맥으로 주입되어, 후속 작업에 자연스럽게 연결된다

예를 들어, 사용자가 이렇게 말했을 때:

"이 이미지에 대해 설명해줘"

LLM은 이를 이해하고, 사용 가능한 도구 중 이미지 해설 도구가 적절하다고 판단한다. 이후 이미지 파일을 해당 도구에 전달하고, 실행 결과를 받아 사용자에게 설명하는 응답을 생성한다.

3. 도구는 어떻게 구성되는가?

MCP에서 사용되는 도구는 JSON 기반 구조를 따른다. 예를 들어 이미지 해설 도구는 다음과 같이 정의될 수 있다:

{
  "name": "generate_docent_from_file_upload",
  "description": "이미지 파일에 대한 해설 문장을 생성합니다.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "file": { "type": "string", "format": "binary" }
    },
    "required": ["file"]
  }
}

이러한 도구 명세는 다음과 같은 장점을 가진다:

LLM이 도구를 이해할 수 있도록 구조화되어 있음
입력 자동 추론 및 오류 검출 가능
다양한 언어/플랫폼과 호환성 확보

도구 정의는 MCPServer에 등록되며, MCPClient는 이 목록을 LLM에 전달하여 선택 가능하게 만든다.

4. 문맥 기반 실행이란?

MCP의 실행은 단순한 도구 호출이 아니라, 다음과 같은 문맥 흐름을 기반으로 이루어진다:

사용자가 자연어로 요청한다
LLM이 현재 대화 맥락에서 어떤 도구가 필요한지 판단한다
도구의 입력값을 구성한다 (예: 직전 메시지의 요약 결과 활용)
도구를 호출하고 결과를 받는다
결과를 다음 응답 생성 시 문맥으로 활용한다

예:

[1] 사용자: 이 보고서 요약해줘 → LLM: summary_tool 선택 → 실행 → 요약 결과 생성

[2] 사용자: 여기서 가장 중요한 이슈는 뭐야? → LLM: [1]의 요약 결과를 문맥으로 가져와 분석 수행

따라서 MCP는 도구 실행 그 자체보다도, 실행 전후의 문맥 흐름 연결에 초점을 둔다.

5. 예제: 날씨 조회 도구 실행 흐름

[User]: 이번 주말 서울 날씨 알려줘

→ MCPClient는 tools array에 weather_tool 포함하여 LLM 호출 → LLM은 "서울", "이번 주말"이라는 정보를 추출해 입력 구성 → weather_tool 호출 → 날씨 데이터 반환 → LLM은 결과를 자연어로 요약해 사용자에게 전달

이 전 과정에서 MCP를 통해 자동으로 이루어지는 부분은 다음과 같다:

도구 선택 (weather_tool)
입력 구성 (location=서울, date=이번 주말)
도구 호출 및 결과 통합

6. MCP가 가지는 의미

MCP는 기존의 도구 체계처럼 사람이 직접 호출 순서나 구성을 짜야 했던 방식에서 벗어나, LLM이 문맥에 맞춰 주도적으로 판단하고 실행할 수 있도록 해준다. 복잡한 도구 체인이 필요한 상황에서도 LLM 중심의 설계만으로 다양한 기능을 확장 가능하다는 점에서, 실용성과 확장성을 모두 고려한 접근 방식이라 할 수 있다.

단순한 자연어 생성기를 넘어, 실제 문제 해결 능력을 갖춘 에이전트를 만들기 위한 토대를 제공한다는 점에서 MCP는 매우 중요한 역할을 하게 된다.

2.2 Context와 Protocol의 의미

MCP라는 이름에는 세 가지 핵심 개념이 담겨 있다: Model + Context + Protocol. 각각의 요소는 MCP가 지향하는 철학과 실행 구조를 구성하는 중요한 기반이다. 이 개념들을 구체적으로 살펴보면 다음과 같다.

1. Model: 실행의 주체로서의 LLM

MCP에서의 "Model"은 단순히 텍스트를 생성하는 LLM이 아니다. LLM은 시스템의 중심이자 실행 주체로, 사용자의 입력을 해석하고, 필요한 도구를 선택하고, 해당 도구를 실행하는 일련의 결정을 스스로 내린다.

이 구조에서는 프롬프트에 도구 호출 명령을 명시적으로 삽입하지 않는다. 대신, LLM은 주어진 문맥과 대화 흐름을 바탕으로, 어떤 도구가 필요한지를 스스로 판단한다. 예를 들어 사용자가 "이 이미지에서 어떤 장면인지 설명해줘"라고 말하면, LLM은 이미지 설명 도구가 필요하다고 판단하고 이를 호출하게 된다.

즉, LLM은 더 이상 단순한 응답 생성기가 아니라 실행 판단자(Decision Maker)로 기능한다.

2. Context: 문맥 기반 추론과 결정

도구 선택과 실행은 단순한 명령어 매칭이 아니다. MCP에서 핵심적인 판단 기준은 바로 Context, 즉 문맥이다. LLM은 이전 발화, 사용자의 목표, 현재까지의 대화 흐름을 종합적으로 고려해 도구를 선택하고, 적절한 입력을 구성한다.

예를 들어:

[1] 사용자: 이 보고서 요약해줘
→ LLM: summary_tool 선택, 실행, 요약 결과 생성
[2] 사용자: 그중에서 핵심 이슈는 뭐야?
→ LLM: [1]의 도구 결과를 문맥으로 통합하여 후속 추론 수행

이러한 흐름은 별도의 상태 저장 장치 없이, LLM의 문맥 유지 능력을 기반으로 자연스럽게 이어진다. 다시 말해, MCP는 대화라는 흐름 속에서 상태를 암묵적으로 유지하며, 도구 호출의 정합성과 응답의 일관성을 확보한다.

3. Protocol: 구조화된 실행 절차

MCP는 단순한 API 호출 스펙이 아니라, LLM 기반 실행 흐름을 체계적으로 정의한 프로토콜이다. 모든 도구는 JSON 기반의 구조화된 명세(inputSchema)를 따르며, MCPClient는 이를 LLM에 전달해 도구 선택과 입력 구성을 유도한다.

프로토콜이라는 이름이 붙은 이유는 다음과 같은 일관된 흐름을 제공하기 때문이다:

도구는 구조화된 명세에 따라 정의된다.
LLM은 주어진 문맥을 바탕으로 도구를 선택한다.
LLM은 선택된 도구의 입력값을 구성한다.
MCPClient는 해당 도구를 실행하고 결과를 수신한다.
도구 결과는 다시 LLM의 문맥에 반영되어 다음 응답을 생성한다.

이 흐름 전체가 하나의 추상화된 실행 모델로 통일되어 있기 때문에, 다양한 도구, 다양한 언어, 다양한 LLM을 사용하더라도 일관된 방식으로 통합할 수 있다. 이 구조는 유지보수, 디버깅, 확장성 측면에서도 큰 장점을 제공한다.

4. 세 가지 개념의 통합적 작동

이 세 요소는 서로 독립적인 개념이 아니라, 긴밀하게 연결되어 작동한다:

LLM(Model)은 실행의 중심에 있으며,
사용자 발화와 이전 결과(Context)를 바탕으로 판단을 내리고,
구조화된 인터페이스(Protocol)를 통해 실제 실행을 담당한다.

이러한 통합 구조 덕분에 MCP는 단순한 챗봇 프레임워크를 넘어, 목표 지향적 에이전트 시스템의 실행 표준으로 작동할 수 있게 된다.

MCP를 사용하면 프롬프트나 코드 설계에 복잡한 논리를 삽입하지 않아도, LLM이 스스로 판단하고 도구를 실행하며 흐름을 제어하는 구조를 만들 수 있다. 이로써 개발자는 더 이상 모든 실행 경로를 설계할 필요 없이, 도구 명세만으로도 다양한 실행 시나리오를 커버할 수 있게 된다.

2.3 MCP의 구성 요소

MCP는 클라이언트-서버 아키텍처를 기반으로 구성된다. 각 요소는 역할에 따라 구분되며, 전체 시스템의 유연성과 확장성을 보장하는 핵심 단위다.

1. Host: 사용자 인터페이스이자 실행의 시작점

Host는 사용자와 직접 상호작용하는 최상위 실행 환경이다. Claude Desktop, Cursor IDE, LibreChat 등의 애플리케이션이 대표적인 예이다. 사용자는 Host를 통해 질의를 입력하고 응답을 수신하며, 내부적으로는 LLM과 MCPClient가 이를 처리한다.

Host는 다음과 같은 기능을 담당한다:

사용자 입력 수신 및 출력 렌더링 (텍스트 또는 이미지 포함)
내부적으로 LLM 호출을 관리하고, 생성된 응답을 사용자에게 전달
MCPClient를 포함하여, MCPServer와의 통신을 담당하는 중심 노드 역할 수행

Host는 단일 사용자 인터페이스일 수도 있고, 복수의 세션을 관리하는 대화형 에이전트 플랫폼의 일부일 수도 있다.

2. MCPClient: 오케스트레이션의 중심 엔진

MCPClient는 LLM 기반 실행 구조에서 가장 핵심적인 역할을 수행한다. LLM과 MCPServer 사이를 중계하며, 도구 목록의 전달, 입력 구성, 실행 요청, 결과 통합 등 오케스트레이션의 모든 과정을 주도한다.

주요 기능은 다음과 같다:

현재 사용 가능한 MCPTool 목록(tools array)을 LLM에 전달
LLM이 선택한 도구의 입력값을 JSON 스펙에 맞게 자동 구성
해당 MCPServer에 실행 요청을 전송하고 결과를 수신
도구 실행 결과를 다음 LLM 호출의 컨텍스트에 자동으로 삽입

MCPClient는 복수의 MCPServer와 동시에 연결될 수 있으며, 필요에 따라 병렬 호출 또는 우선순위 제어도 가능하다. 이를 통해 다양한 기능의 도구들을 유기적으로 조합하여 복잡한 에이전트 시나리오를 구현할 수 있다.

3. MCPServer: 도구와 기능의 실행 단위

MCPServer는 LLM이 활용할 수 있는 외부 기능을 실제로 실행하는 실행 환경이다. 하나 이상의 도구, 리소스, 프롬프트를 포함할 수 있으며, 다음 세 가지 계층으로 구성된다:

프로토콜 계층 (Protocol Layer): JSON-RPC 2.0을 기반으로 클라이언트와의 메시지 포맷 및 호출-응답 처리 방식을 규정한다. 명확한 메시지 구조와 에러 핸들링이 가능하다.
전송 계층 (Transport Layer): 도구와의 실제 통신 방식으로, stdio 기반 표준 입출력 방식과 HTTP + SSE(Server-Sent Events) 방식 둘 다 지원한다. 이는 언어와 플랫폼의 독립성을 보장한다.
기능 제공 계층 (Capabilities Layer): MCPServer가 LLM에 제공하는 기능 단위로, 다음 세 가지로 나뉜다:
- 도구 (Tools): 명시된 입력 스펙에 따라 실행되는 API 또는 함수 단위 기능. 예: 이미지 설명, 문서 요약, 요금 계산 등
- 리소스 (Resources): 읽기 전용 정적 데이터 또는 쿼리 가능한 정보. 예: 파일 목록, 설정 값, 지원 언어 리스트 등
- 프롬프트 (Prompts): 자주 반복되는 지시 문장, 템플릿, 시스템 지시어를 프리셋으로 제공하여 출력 제어

MCPServer는 도구를 표준화된 스펙으로 정의함으로써, 클라이언트가 어떤 도구가 사용 가능한지 자동으로 파악하고 통신할 수 있도록 한다. 도구의 추가 및 수정이 유연하며, 새로운 기능의 빠른 확장과 유지보수가 가능하다.

4. 구성 요소 간의 상호작용 요약

사용자 ↔ Host: 텍스트/음성/이미지 입력과 응답 렌더링을 통해 사용자와 시스템 간 인터페이스를 제공
Host ↔ MCPClient: 사용자 요청을 LLM에 전달하고, LLM 응답을 사용자에게 반환
MCPClient ↔ LLM: 도구 목록 전달 및 도구 선택 유도, 결과 반영
MCPClient ↔ MCPServer: 선택된 도구 실행을 위한 입력 구성, 호출, 결과 수신

이처럼 MCP는 각각의 역할을 명확히 분리하면서도, 전체 흐름을 유기적으로 연결하는 구조로 설계되어 있다. 이 아키텍처는 LLM 중심의 실행 제어, 도구 기반 기능 확장, 문맥 기반 응답 생성이라는 세 가지 목표를 안정적으로 실현하는 기반이 된다.

2.4 MCP의 핵심 철학

MCP(Model Context Protocol)는 단순한 기술 사양을 넘어서, 에이전트 시스템을 설계할 때 고려해야 할 핵심 철학을 담고 있다. 이 철학은 시스템이 작동하는 방식은 물론, 도구를 어떻게 정의하고 LLM과 어떻게 통합할지를 결정짓는 근본적인 기준이 된다.

1. LLM은 실행 주체다

가장 핵심적인 철학은 "LLM은 단순한 응답 생성기가 아니라 실행 주체여야 한다"는 점이다. 기존의 LLM 시스템은 사용자의 입력에 텍스트를 생성해 응답하는 데에 그쳤다. 그러나 MCP에서는 LLM이 전체 실행 흐름의 중심에 위치한다.

LLM은 다음과 같은 역할을 스스로 수행한다:

사용자 발화로부터 목적과 의도를 파악하고
사용 가능한 도구 목록 중에서 적절한 MCPTool을 선택하며
선택된 도구의 명세(inputSchema 등)를 기반으로 입력값을 구성하고
MCPServer에 도구 실행 요청을 전송하며
그 결과를 수신해 다음 행동 또는 응답에 반영한다

즉, 실행 흐름의 제어권이 프롬프트나 외부 오케스트레이터에 있는 것이 아니라 LLM 자체에 있다.

예를 들어, 사용자가 "이 사진에 뭐가 보이는지 설명해줘"라고 말하면, LLM은 이를 이미지 분석 요청으로 해석하고, 이미지 설명 도구를 선택해 입력을 구성한 뒤 실행 결과를 받아 응답으로 가공한다. 이 과정은 명시적인 스크립트나 명령 없이도 LLM이 자율적으로 수행한다.

LLM은 단순한 텍스트 생성기를 넘어, 컨텍스트 해석자, 실행 결정자, 응답 조율자로 작동하며, MCP는 이러한 구조가 가능하도록 설계되어 있다.

2. 도구는 구조화되어야 하며, 호출은 문맥으로 유도되어야 한다

MCP는 모든 도구를 사람이 아닌 LLM이 이해하고 사용할 수 있도록 JSON 기반 명세로 구조화한다. 이 구조화된 정의는 단순한 문서화가 아닌, LLM이 정확하게 입력값을 구성하고 올바른 도구를 선택하는 데 필요한 기반이 된다.

예를 들어 '이미지 설명' 도구가 "이미지를 분석합니다"라는 설명만 있을 경우, LLM은 어떤 입력이 필요한지 또는 어떤 형식의 결과가 반환되는지를 예측하기 어렵다. 하지만 도구 명세에 어떤 입력이 필요하고 출력은 어떤 형태인지를 구조적으로 정의하면, LLM은 이를 문맥 기반 추론에 활용해 정확히 실행할 수 있다.

이처럼 도구는 구조적으로 정의되어야 하며, 호출은 자연어 문맥에 따라 LLM이 유도할 수 있어야 한다. 이는 코드 중심이 아니라 언어 중심으로 작동하는 시스템에서 필수적인 설계 방식이다.

3. 언어와 플랫폼에 구애받지 않는 실행 구조

MCP는 특정 언어나 프레임워크에 종속되지 않는다. Python, Node.js, Go, Rust 등 어떤 언어로 작성된 도구라도 MCPServer에 등록하고 동일한 인터페이스로 사용할 수 있다. 이 구조는 다음과 같은 유연성을 제공한다:

다양한 기술 스택을 사용하는 팀 간의 통합이 용이하다
기존 시스템에 최소한의 변경만으로 연결 가능하다
도구를 독립적으로 개발하고 유지보수할 수 있다

MCPServer는 다음 두 가지 전송 방식을 통해 도구를 실행할 수 있도록 지원한다:

stdio (Standard I/O): 도구를 명령줄 프로그램처럼 실행하고, JSON 데이터를 stdin/stdout을 통해 주고받는다. 설치와 환경 제약이 거의 없고 빠른 개발에 유리하다.
SSE (Server-Sent Events): HTTP 기반의 텍스트 스트리밍 방식으로, 도구가 결과를 실시간으로 점진적으로 전송할 수 있다. 클라우드 API뿐 아니라 로컬 환경(Node.js, Flask 등)의 웹 서버에서도 사용 가능하며, 실시간 피드백이 필요한 도구에 효과적이다.

이러한 전송 방식의 선택은 시스템의 구성 환경에 따라 유연하게 적용할 수 있으며, MCP는 이를 통해 도구 생태계 전체를 연결하는 실행 인터페이스로 작동할 수 있다.

4. 문맥 기반 자동화 구조

MCP의 또 다른 핵심 철학은 문맥 기반의 자동화이다. 도구 호출과 결과 반영 과정이 프롬프트에 직접 정의되어 있지 않더라도, LLM은 대화 흐름 속에서 자연스럽게 다음 행동을 결정하고 실행할 수 있어야 한다.

이 구조는 다음과 같은 자동화 흐름으로 이어진다:

사용자 발화를 수신한다
LLM이 현재 문맥에 맞는 도구를 선택한다
입력값을 구성하여 MCPServer에 호출 요청을 보낸다
도구 결과를 수신한다
결과를 문맥에 반영하고 후속 응답을 생성한다

이 모든 과정은 추가적인 스크립팅 없이도 문맥 기반 추론 능력을 가진 LLM에 의해 수행된다. 즉, 자동화는 프롬프트나 코드에 내재되지 않고, 문맥 그 자체에 내재된다.

5. 통합된 설계 패러다임으로서의 MCP

MCP는 기존의 API 설계와 프롬프트 설계의 경계를 허문다. 도구의 description과 inputSchema는 단순 문서가 아니라, LLM이 행동을 결정하는 기준이 된다.

이러한 방식은 개발자가 따로 명령을 작성하거나 흐름을 지정하지 않아도, 도구와 프롬프트가 자연스럽게 통합된 실행 흐름을 구성할 수 있도록 한다. 결과적으로 다음과 같은 설계 방식이 가능해진다:

하나의 description 문장이 도구의 기능과 사용 목적을 동시에 전달
schema의 각 필드는 입력값뿐 아니라 LLM의 추론 범위를 제한하는 역할 수행
예시나 예외 처리 없이도 도구 정의만으로 충분한 실행 유도 가능

책쓰자. Part1 - 2