LLM, Agent, MCP까지 한눈에 이해하기: AI 도구 연동의 진화
LLM의 한계에서 출발해 Agent가 등장한 이유, 프레임워크별 Tool SDK의 파편화 문제, 그리고 이를 해결하는 MCP(Model Context Protocol)의 개념과 동작 원리를 정리합니다. 필수 MCP 서버 추천과 Claude Code에서의 설치 방법까지 실무 관점에서 다룹니다.
소개
ChatGPT, Claude 같은 LLM(Large Language Model)은 학습된 데이터를 기반으로 질문에 답하는 데 탁월합니다. 하지만 "최신 주가를 알려줘"나 "이 파일을 수정해줘" 같은 요청에는 한계가 있습니다. 학습 데이터 밖의 세계와 상호작용하는 능력이 없기 때문입니다.
이 간극을 메우기 위해 Agent라는 개념이 등장했고, Agent가 외부 Tool을 호출하는 방식도 빠르게 발전했습니다. 그리고 프레임워크마다 제각각이던 Tool 연동 방식을 하나로 통일하려는 시도가 바로 MCP(Model Context Protocol)입니다.
이 글에서 다루는 내용은 다음과 같습니다.
- LLM 단독으로는 왜 한계가 있는지
- Agent가 어떤 역할을 하고, 어떻게 Tool을 선택하는지
- 프레임워크별 Tool SDK 파편화 문제
- MCP의 개념과 동작 원리
- 실무에서 유용한 MCP 서버와 설치 방법
1. LLM의 한계: 학습된 데이터 안에서만 동작한다
LLM은 대규모 텍스트 데이터를 학습하여 언어를 이해하고 생성합니다. 질문을 하면 학습된 지식 범위 안에서 가장 적절한 답변을 생성하는 방식입니다.
하지만 이 구조에는 근본적인 한계가 있습니다.
| 가능한 것 | 불가능한 것 |
|---|---|
| 학습 데이터 기반 질의응답 | 실시간 데이터 조회 (주가, 날씨 등) |
| 코드 작성·설명 | 파일 시스템 접근·수정 |
| 번역·요약·분석 | 외부 API 호출 |
| 대화 기반 추론 | 데이터베이스 쿼리 실행 |
즉, LLM 단독으로는 "아는 것을 말하는 것"까지만 가능하고, "무언가를 하는 것"은 불가능합니다.
LLM은 학습 시점까지의 데이터만 알고 있습니다. 예를 들어 2024년 4월까지 학습된 모델은 그 이후의 사건이나 업데이트된 라이브러리 문서를 알지 못합니다. 이것이 실시간 데이터 연동이 필요한 가장 큰 이유입니다.
2. Agent: LLM에 행동 능력을 부여하다
Agent는 LLM이 외부 데이터 소스나 도구(Tool)와 상호작용할 수 있도록 해주는 오케스트레이션(Orchestration) 레이어입니다.
Agent의 핵심 역할은 다음과 같습니다.
- 사용자의 요청을 분석한다
- 요청을 수행하기 위해 어떤 Tool을 사용할지 결정한다
- 선택한 Tool을 호출하고 결과를 받는다
- 결과를 바탕으로 사용자에게 답변을 생성한다
사용자 질문
↓
┌─────────┐
│ Agent │ ← LLM + Tool 선택 로직
└─────────┘
↓ (Tool 호출)
┌─────────┐
│ Tool │ ← 웹 검색, DB 조회, 파일 접근 등
└─────────┘
↓ (결과 반환)
┌─────────┐
│ Agent │ ← 결과를 종합하여 답변 생성
└─────────┘
↓
최종 답변Agent는 단순한 API 래퍼가 아닙니다. 적절한 Tool을 선택하는 로직이 필요하며, 이 로직이 Agent의 핵심 가치입니다. "사용자가 날씨를 물어봤으니 날씨 API를 호출하고, 코드 수정을 요청했으니 파일 시스템 Tool을 사용한다"와 같은 판단 능력이 Agent를 단순 LLM과 구분짓습니다.
3. 프레임워크와 Tool SDK: 파편화의 시작
Agent를 구현하기 위한 프레임워크들이 여럿 등장했습니다. 대표적으로 LangChain, CrewAI, AutoGen 등이 있습니다.
이 프레임워크들은 Tool과 연결하기 위해 각자의 Tool SDK를 제공합니다. 프레임워크 제작자가 서비스 프로바이더(예: Slack, GitHub, Google 등)와 협업하여 연동 스펙을 맞추고, 해당 프레임워크 전용 SDK를 만드는 방식입니다.
┌──────────────┐ ┌──────────────────┐
│ LangChain │────▶│ LangChain SDK │──▶ Slack, GitHub, ...
└──────────────┘ └──────────────────┘
┌──────────────┐ ┌──────────────────┐
│ CrewAI │────▶│ CrewAI SDK │──▶ Slack, GitHub, ...
└──────────────┘ └──────────────────┘
┌──────────────┐ ┌──────────────────┐
│ AutoGen │────▶│ AutoGen SDK │──▶ Slack, GitHub, ...
└──────────────┘ └──────────────────┘여기서 문제가 발생합니다.
각 프레임워크마다 서로 다른 Tool SDK를 사용하기 때문에, Tool 제공자(서비스 프로바이더) 입장에서는 프레임워크 수만큼 SDK를 개발하고 유지보수해야 합니다. 프레임워크 사용자 입장에서도 프레임워크를 바꾸면 Tool 연동 코드를 전부 다시 작성해야 합니다.
예를 들어 Slack 연동 Tool을 만들었다면, LangChain용, CrewAI용, AutoGen용 SDK를 각각 따로 만들어야 합니다. 이는 개발·관리 부담을 크게 증가시킵니다.
4. MCP(Model Context Protocol): 표준화된 연동 프로토콜
MCP(Model Context Protocol)는 이 파편화 문제를 해결하기 위해 등장한 표준화된 프로토콜입니다. 어떤 프레임워크든, 어떤 Tool이든 하나의 프로토콜로 연동할 수 있게 합니다.
┌───── MCP Protocol ─────┐
│ │
┌──────────────┐ │ ┌───────────────┐ │
│ LangChain │────┼───▶│ │ │
└──────────────┘ │ │ MCP Server │ │
┌──────────────┐ │ │ (Tool 제공) │ │
│ CrewAI │────┼───▶│ │ │
└──────────────┘ │ │ Slack, GitHub │ │
┌──────────────┐ │ │ DB, 파일 등 │ │
│ Claude Code │────┼───▶│ │ │
└──────────────┘ │ └───────────────┘ │
└─────────────────────────┘핵심은 간단합니다. Tool 제공자는 MCP Server 하나만 구현하면 어떤 프레임워크에서든 해당 Tool을 사용할 수 있습니다.
4-1. MCP의 동작 원리
MCP는 말 그대로 프로토콜입니다. JSON-RPC 기반으로 LLM 애플리케이션(Client)과 Tool 서버(Server)가 어떻게 통신하는지를 정의한 규약입니다.
통신 흐름은 다음과 같습니다.
1. Tool 목록 요청
Client ──── list_tools ────▶ MCP Server
Client ◀─── 사용 가능한 Tool 목록 ── MCP Server
2. Tool 호출
Client ──── call_tool(name, args) ────▶ MCP Server
Client ◀─── 실행 결과 ──────────────── MCP Server구체적으로:
- Tool 목록 조회: LLM 앱 내부의 Agent가 MCP Server에
list_tools를 호출하여 사용 가능한 Tool 목록을 받아옵니다. - Tool 선택: Agent가 사용자의 요청을 분석하여 적절한 Tool을 선택합니다.
- Tool 실행: 선택한 Tool을
call_tool로 호출하고 결과를 반환받습니다. - 응답 생성: Tool의 실행 결과를 바탕으로 사용자에게 최종 답변을 생성합니다.
JSON-RPC는 JSON 포맷으로 원격 프로시저(함수)를 호출하는 경량 프로토콜입니다. HTTP나 WebSocket 위에서 동작하며, 요청과 응답이 모두 JSON 형태이므로 구현이 간단합니다.
4-2. MCP SDK
MCP 프로토콜을 직접 구현할 필요 없이, Server SDK와 Client SDK를 활용하면 됩니다.
| SDK 종류 | 역할 | 제공 주체 |
|---|---|---|
| Server SDK | MCP Server 구현 시 사용 | MCP 공식 |
| Client SDK | MCP Client(프레임워크) 연동 시 사용 | 각 프레임워크 |
Client SDK는 프레임워크들이 자체 SDK의 일부로 제공합니다. 예를 들어 LangChain은 langchain-mcp 패키지로 MCP Client를 지원하며, 이를 통해 다양한 LLM 모델을 Agent로 사용할 수 있습니다.
Tool 제공자는 MCP Server만 구현하면 모든 프레임워크에서 사용 가능합니다. 프레임워크 사용자는 MCP를 지원하는 어떤 Tool이든 동일한 방식으로 연동할 수 있습니다. N:M 연동 문제가 1:1로 단순화되는 것이 MCP의 핵심 가치입니다.
5. 실무에서 유용한 MCP 서버
5-1. 필수 MCP: context7
context7은 최신 라이브러리 문서와 정확한 코드 예제를 실시간으로 조회할 수 있게 해주는 MCP 서버입니다. LLM의 지식 컷오프 문제를 직접적으로 해결합니다.
예를 들어 "Next.js 15의 새로운 API는?"이라고 물으면, context7이 최신 공식 문서에서 관련 내용을 가져와 정확한 답변을 생성할 수 있습니다.
5-2. 필수 MCP: playwright
playwright MCP는 Playwright을 통한 브라우저 자동화, 탐색, 테스트 등을 수행할 수 있게 합니다. 웹 페이지를 열고, 요소를 클릭하고, 스크린샷을 찍는 등의 브라우저 작업을 LLM이 직접 수행할 수 있습니다.
5-3. 설치 방법
위 두 MCP는 프로젝트에 관계없이 항상 필요하므로, 글로벌(사용자 범위)로 설치하는 것을 권장합니다.
# Claude Code에서 MCP 설치 (글로벌 - user scope)
claude mcp add context7 --scope user -- npx @context7/mcp-server
claude mcp add playwright --scope user -- npx @anthropic-ai/mcp-playwright--scope user(또는 --scope global)로 설치하면 모든 프로젝트에서 사용할 수 있습니다. 반면 특정 프로젝트에서만 필요한 MCP는 --scope project로 설치하여 프로젝트 단위로 관리하는 것이 깔끔합니다.
그 외 MCP 서버들은 상황에 따라 프로젝트 단위로 설치합니다.
# 프로젝트 스코프 MCP 설치 예시
claude mcp add vercel --scope project -- npx @vercel/mcp
claude mcp add github --scope project -- npx @anthropic-ai/mcp-github| MCP 서버 | 용도 | 권장 스코프 |
|---|---|---|
| context7 | 최신 라이브러리 문서 조회 | 글로벌 |
| playwright | 브라우저 자동화·테스트 | 글로벌 |
| vercel | Vercel 배포 관리 | 프로젝트 |
| github | GitHub 이슈·PR 관리 | 프로젝트 |
| aws | AWS 리소스 관리 | 프로젝트 |
마무리
LLM에서 Agent로, 그리고 MCP로 이어지는 흐름을 정리하면 다음과 같습니다.
| 단계 | 개념 | 핵심 역할 |
|---|---|---|
| LLM | 학습 기반 언어 모델 | 지식 범위 안에서 답변 생성 |
| Agent | LLM + Tool 오케스트레이션 | 외부 데이터·서비스와 상호작용 |
| MCP | 표준화된 Tool 연동 프로토콜 | 프레임워크-Tool 간 연동 통일 |
LLM 단독으로는 "아는 것"만 말할 수 있었지만, Agent를 통해 "행동"이 가능해졌고, MCP 덕분에 그 행동의 연결 방식이 표준화되었습니다. 프레임워크마다 다른 SDK를 관리하던 시대에서, 하나의 프로토콜로 모든 Tool과 소통하는 시대로 전환되고 있습니다.
MCP는 아직 초기 단계이지만, Anthropic을 비롯한 주요 AI 기업들이 적극적으로 밀고 있는 만큼 앞으로 AI 도구 생태계의 중심축이 될 가능성이 높습니다.