MCP란 무엇인가: LLM Agent 동작 흐름으로 이해하는 MCP

요약

이 글은 LLM Agent 개발을 위한 표준 프로토콜인 MCP(Model Context Protocol)의 개념과 구조, 동작 방식을 자세히 다룹니다. 기존 에이전트 프레임워크의 파편화를 해결하고자 등장한 MCP는 Host, Client, Server로 구성되어 있으며, 다양한 외부 툴과 리소스를 연결해 에이전트의 유연성과 확장성을 높입니다. MCP를 통해 단순한 대화부터 복잡한 API 호출까지 다양한 작업을 자동화할 수 있으며, 글에서는 실제 예시와 함께 작동 흐름을 설명합니다. 또한 MCP의 현재 한계점과 향후 표준화, 생태계 확장 가능성에 대해서도 통찰을 제공합니다.

1. 개요

MCP(Model Context Protocol)는 2024년 11월 처음 공개된 이후 한동안 제한된 커뮤니티 내에서만 활용되어 왔으나, 최근 OpenAI의 Agents SDK가 이를 공식 지원하면서 주목도가 빠르게 높아지고 있습니다. 본 글에서는 MCP가 무엇인지, 그리고 어떤 방식으로 동작하는지를 자세히 살펴보겠습니다.

2. MCP의 탄생 배경

MCP는 LLM Agent 구축을 위한 규격 중 하나인데요. MCP를 이해하기 위해 먼저 LLM과 LLM Agent의 개념을 살펴보겠습니다. LLM과 LLM Agent 간의 차이는 다음과 같습니다.

2-1) LLM vs LLM Agent

항목	LLM	LLM Agent
주요 역할	단발성 언어 작업 수행 (요약, 번역, Q&A 등)	복잡한 태스크를 계획-실행-관찰 루프로 수행
Memory	없음 (컨텍스트 제한)	있음 (대화 기록, 작업 히스토리 기억 가능)
Tool 사용	불가능 (내부 모델 능력에만 의존)	가능 (API, 계산기, DB, 웹 브라우저 등 외부 리소스 활용)
Planner	없음	있음 (도구를 언제/어떻게 쓸지 판단하고 순서 계획)
실행 방식	정적인 응답 → 입력 1개 → 출력 1개	동적인 행동 → 입력 → 툴 호출 → 결과 해석 → 반복
유연성	낮음 (미리 학습된 지식만 활용 가능)	높음 (실시간 검색, 계산, API 활용 가능)
지속적 작업	어려움	가능 (여러 단계를 거치는 장기 과제 처리)

다음과 같이, 같은 “날씨 알려줘”의 사용자 쿼리에 대해 LLM과 LLM Agent의 응답은 차이가 있습니다.

📌 LLM 예시

사용자: “날씨 알려줘”

→ 응답: “죄송하지만, 현재 날씨 정보에는 접근할 수 없습니다. 일반적으로 봄철에는 따뜻하고 맑은 날씨가 많습니다.”

📌 LLM Agent 예시

사용자: “날씨 알려줘”

→ LLM이 파악: 사용자의 의도를 이해함

→ Tool 사용: 날씨 API 호출

→ 결과 종합: 응답 생성

→ 응답: “서울은 현재 18도이며, 맑은 날씨입니다.”

이처럼, 단순히 텍스트를 생성하는 LLM과 실제 툴을 사용해 사용자 요청을 해결하는 LLM Agent는 근본적인 차이가 있습니다. 최근에는 단순 응답을 넘어, 외부 도구를 능동적으로 활용하는 LLM Agent 개발이 주목받고 있습니다.

하지만 Agent를 만드는 과정은 아직까지 표준화되지 않아 여러 문제들이 발생하고 있으며, 이에 대한 논의는 다음과 같습니다.

2-2) LLM Agent 개발의 파편화와 표준화의 필요성

MCP가 등장하기 전까지, LLM Agent를 구축하는 방식은 프레임워크마다 제각각이었습니다.
각기 다른 방식으로 툴을 연결하고, 자체적인 구성 요소를 따로 구현하면서 다음과 같은 문제가 발생했습니다.

다양한 Agent 프레임워크가 난립하며 툴 연동 방식이 서로 달랐고,
툴과 컴포넌트의 재사용과 확장이 어려워졌으며,
커뮤니티 생태계도 분절되어 협업이 힘든 구조가 되었습니다.
동일한 기능의 툴조차 프레임워크마다 다시 구현해야 했고,
시스템 간 연동이 어려워 툴 생태계 전체가 고립되기 시작했습니다.

이처럼 Agent 개발의 파편화가 심화되자,
모든 Agent들이 공통으로 사용할 수 있는 ‘표준 프로토콜’의 필요성이 커졌고,
바로 그 해결책으로 MCP(Model Context Protocol)가 등장하게 된 것입니다.

3. MCP(Model Context Protocol) 란?

출처 : Introduction – Model Context Protocol

MCP는 애플리케이션이 LLM에 컨텍스트를 제공하는 방법을 표준화하는 개방형 프로토콜
Claude LLM을 제공하는 Anthropic 미국 스타트업에서 제안
MCP는 AI 애플리케이션을 위한 USB-C 포트와 같음. USB-C가 다양한 주변기기와 액세서리에 기기를 연결하는 표준화된 방법을 제공하는 것처럼, MCP는 AI 모델을 다양한 데이터 소스와 도구에 연결하는 표준화된 방법을 제공
JSON-RPC 방식으로 규격화 통신

USB-C 타입 통일과 같은 MCP(What is Model Context Protocol (MCP)? How it simplifies AI integrations compared to APIs | AI Agents That Work)

4. MCP의 기본 구조

MCP는 Host, Client, Server로 크게 3가지로 이루어져 있습니다.

4-1) Host

정의 :

Host는 LLM 애플리케이션 자체로, MCP 통신의 중심이며 여러 개의 Client를 포함하고 이들을 관리합니다.

주요 특징 :

LLM 기반의 인터페이스(ex. Claude Desktop, Cursor IDE)
내부에 MCP Client들을 여러 개 포함
사용자 인터페이스와 상호작용
각 Client와 연결된 Server들의 실행 결과와 context를 통합해 LLM에 전달

역할 요약 :

MCP Client들의 초기화 및 라이프사이클 관리
인증 및 권한 제어
여러 Client로부터 받은 정보를 Context로 통합
사용자와 LLM 사이의 브릿지

사례 :

Claude Desktop App과 Cursor AI는 사용자가 직접 마주하는 Host 인터페이스로서, Agent와 상호작용하는 프런트엔드 역할을 수행합니다. 이러한 앱들은 사용자에게 친숙한 환경을 제공하며, 에이전트에 쉽게 접근하고 활용할 수 있는 통로가 되어줍니다. 덕분에 사용자는 복잡한 설정 없이 자연어로 명령하고 다양한 Tool을 손쉽게 사용할 수 있습니다.

4-2) Client

정의 :

Client는 MCP Server 들과 연결되어 있으며, 양방향 메시지 교환, 기능 목록 관리, 초기 협상 등을 수행합니다.

주요 특징 :

하나의 MCP Client는 하나의 MCP Server와 연결
내부적으로 메시지를 주고받고, 서버 상태나 기능 목록을 파악함
각각의 클라이언트는 특정 목적(예: Linear 연동, Slack 연동)을 위해 존재

역할 요약 :

Server와 상태 기반 연결 유지 (stateful connection)
요청/응답/알림 등의 메시지 라우팅 처리
서버의 도구, 리소스, 템플릿 등 Capability 정보 관리
프로토콜 버전/기능에 대한 초기 협상 수행
Server 리소스에 대한 구독/알림 이벤트 관리

사례 :

출처 : OpenAI Agents SDK

OpenAI Agents SDK, mcp-agents, Langchain 등은 Client 단에서 에이전트를 손쉽게 생성하고 실행할 수 있도록 지원하는 도구들입니다. 이들 프레임워크는 LLM과 Tool, Memory, Planner 등을 연결하는 복잡한 과정을 추상화하여, 개발자가 보다 직관적으로 Agent를 설계하고 운영할 수 있도록 도와줍니다.

4-3) Server

정의 :

Server는 LLM이 외부 세계와 상호작용할 수 있도록 도와주는 기능적 확장제로, MCP의 하위 컴포넌트인 Tool, Resource, Prompt Template을 제공합니다.

제공 구성 요소 :

Tool (도구) :
외부 API 또는 기능을 실행하는 명령 단위. LLM이 호출 가능
예: 파일 목록 가져오기, 이메일 전송, 데이터베이스 조회 등
Resource (리소스) :
텍스트, 로그, DB 스키마 등 LLM이 참고할 수 있는 외부 컨텍스트
Prompt Template (프롬프트 템플릿) :
LLM이 따라야 할 지시문 혹은 형식

역할 요약 :

LLM이 직접 호출할 수 있는 도구(Tool) 제공
Host/Client가 요청하는 리소스 정보 제공
LLM의 행동을 안내할 프롬프트 템플릿 제공
초기화 과정에서 프로토콜 협상 수행
Client로부터 받은 요청을 처리하고 응답 반환

사례 :

출처 : Smithery – Model Context Protocol Registry

Smithery는 MCP 기반 서버 레지스트리로, 이미 4,000개 이상의 MCP Server가 등록되어 있습니다. 사용자는 이들 서버를 자유롭게 선택하여 자신의 에이전트에 연동할 수 있으며, 마치 API 마켓 플레이스처럼 필요한 기능을 손쉽게 가져다 쓸 수 있는 환경이 제공됩니다.

5. MCP 기반 LLM Agent의 동작 흐름

MCP 기반 LLM Agent는 입력된 요청의 성격에 따라 두 가지 방식으로 동작합니다.
일반적인 대화나 단순 질의의 경우에는 LLM만으로 응답이 생성되며, 복잡한 작업이나 외부 정보가 필요한 경우에는 Tool을 호출해 작업을 수행합니다.
각 방식의 흐름을 예시와 함께 살펴보겠습니다.

Tool 없이 LLM만 응답하는 경우
Tool이 호출되는 경우

이제 각 경우의 실제 흐름을 구체적으로 살펴보겠습니다.

5-1) Tool 없이 LLM만 응답하는 경우

간단한 인사, 요약, 번역, Q&A 등은 LLM이 자체적으로 응답을 생성
별도의 외부 연동 없이 빠르게 결과 제공

사용자가 “안녕, 난 한컴이야.” 와 같은 단순한 자연어 메시지를 입력하면, MCP 시스템에서는 가장 기본적인 처리 흐름이 작동합니다. 이 경우, 툴 호출이 필요하지 않다고 판단되면 LLM은 직접 응답을 생성하고, 별도의 외부 리소스와의 연동 없이 대화를 마무리합니다.

사용자 입력이 MCP Host로 전달되면, Host는 이 메시지를 내부 LLM에게 그대로 전달합니다.
LLM은 메시지를 해석한 뒤, 도구(tool)가 필요 없다고 판단하고, 바로 응답을 생성합니다.
Host는 LLM의 응답을 받아 이를 MCP Client에 전달하며, Client는 해당 응답을 사용자에게 표시합니다.

예를 들어, 사용자 메시지가 “안녕, 난 한컴이야.” 일 경우,
LLM은 “안녕하세요, 한컴님! 만나서 반가워요 😊” 와 같은 응답을 생성하게 됩니다.

이와 같은 단순 흐름은 도구(tool) 없이 이루어지는 가장 전형적인 LLM 사용 방식이며, 실제 MCP 기반 대화에서 전체 요청의 50~70%가 이와 같은 형태로 처리됩니다.

5-2) Tool이 호출되는 경우

계산, 검색, 외부 API 호출 등 복잡한 요청은 LLM이 적절한 Tool을 선택
MCP Client가 Tool을 호출하고, 그 결과를 바탕으로 최종 응답 생성

사용자가 “이슈 제목은 ‘버그 수정 요청’, 내용은 ‘로그인 안 됨’으로 GitHub에 새 이슈를 생성해 줘.”라는 자연어 요청을 입력하면, MCP 기반 시스템은 Tool을 활용해 실제 작업을 수행하는 구조로 동작합니다.

사용자 입력이 MCP Host로 전달되면, Host는 이를 내부 LLM에게 전달합니다.
LLM은 입력된 내용을 분석한 뒤, 외부 Tool인 github.create_issue 호출이 필요하다고 판단하고, 적절한 파라미터(repo, title, body)를 추출합니다.
Host는 이를 tool-call 메시지로 변환해 MCP Client에 전달하고, Client는 해당 요청을 JSON-RPC 형식으로 변환합니다.
Client는 Tool Registry를 참조해 이 툴을 제공하는 MCP Server(GitHub 어댑터 서버)에 요청을 보냅니다.
MCP Server는 GitHub API에 맞춰 요청을 전달하고, 실제로 GitHub 저장소 hancom/techblogtestrepo에 이슈를 생성합니다.
GitHub는 생성된 이슈의 URL과 번호를 포함한 응답을 반환하며, MCP Server는 이를 JSON-RPC 응답 형식으로 Client에게 전달합니다.
Client는 응답을 다시 MCP 메시지 포맷으로 변환해 Host에 전달하고, LLM은 최종 사용자 응답을 생성합니다.

예를 들어, 사용자에게 다음과 같은 메시지가 출력됩니다 :
“GitHub에 이슈를 생성했습니다: https://github.com/hancom/techblogtestrepo/issues/42 “

이와 같이 MCP를 통해 LLM은 실제 API를 호출하고, 복잡한 작업을 자동화할 수 있게 됩니다.

6. MCP가 해결해야 할 문제점

MCP가 빠르게 확산되고 있는 추세이지만, 릴리즈 초기 단계인 만큼 여전히 보완이 필요한 부분들이 존재합니다.

문제점	설명
표준화 부족	현재 MCP는 특정 프로젝트(예: Smithery, AgentOps) 중심으로 구현되고 있어, 업계 전반의 합의된 명세나 표준이 없음
보안과 권한 관리 미흡	다양한 외부 도구와 모델이 연결되면서, 사용자 인증, 데이터 접근권한, API 보안 등에 대한 체계가 부족
복잡한 구성 및 러닝 커브	MCP의 컨셉(Host, Client, Server, Tool 등)이 기존 REST API 방식보다 복잡해, 초기 진입 장벽이 높음
성능 및 비용 문제	MCP 기반 에이전트는 일반적인 LLM 호출보다 더 많은 상호작용을 하므로, 지연(latency) 및 비용 부담이 큼
에코시스템 편중	MCP는 아직 소수 커뮤니티 중심으로 개발되고 있어, 다양한 언어나 플랫폼에 대한 지원 부족이라는 한계가 있음

※ 필자가 직접 MCP를 테스트하면서 가장 크게 체감한 부분은, 현재 대부분의 Agent SDK가 Claude, OpenAI 등 대형 LLM 과의 연동에만 최적화되어 있다는 점이었습니다.
사내에서 운영 중인 LLM이나 독립적인 사설 LLM 서버와 연결하려면, 직접 커스텀 구현을 해야 하는 불편함이 여전히 존재합니다.

7. MCP 전망

여전히 보완이 필요한 부분들이 존재함에도 불구하고, MCP의 전망은 긍정적입니다!

측면	전망
표준화	HTTP처럼 AI 상호작용의 기본 프로토콜로 자리잡을 가능성주요 기업(예: OpenAI, Meta, Google 등)의 채택 여부가 핵심
에이전트 생태계 확장	사용자가 직접 도구를 조합해 에이전트를 설계하고 운영하는 시대가 열릴 것B2B부터 개인 창작자까지 광범위한 활용 기대
비즈니스 기회	“Agent Development Platform”, “Tool Marketplace”, “MCP Compliance SaaS” 등 신규 산업군과 스타트업 기회 창출 예상
보안/규제 프레임워크	개인정보 보호, 기업용 에이전트의 감사 로그, AI 행동 책임성 등을 위한 보안 표준화 및 윤리 프레임워크 마련이 병행될 전망
멀티모델 통합 허브	텍스트, 음성, 비전, 로보틱스 등 다양한 모달리티를 연결하는 통합 인터페이스로 확장 가능특히 RAG 기반 AI 운영에 적합

마무리

※ 해당 내용은 개인적인 생각입니다.

2024년 11월 MCP가 처음 출시된 이후, 불과 몇 달 사이에 그 생태계는 급속히 확장되고 있습니다. MCP 서버 레지스트리인 smithery.ai는 2024년 12월에 불과 10개의 MCP 서버로 시작했지만, 2025년 4월 14일 기준으로 이미 4,533개의 MCP 서버가 등록되어 있으며, 매주 약 300~400개의 신규 서버가 꾸준히 추가되고 있습니다. 이러한 성장세를 볼 때 MCP가 에이전트 기반 플랫폼의 사실상 표준(de facto standard)으로 자리 잡을 가능성은 매우 높다고 판단됩니다.

한컴도 변화하는 MCP 생태계를 주의 깊게 지켜보며, 관련 기술 방향을 다각도로 검토하고 있습니다. 앞으로의 기술 발전과 확산이 더욱 기대됩니다.

Reference

Post Views: 681