MCP(Model Context Protocol) 완벽 가이드 – AI 도구 연동의 새로운 표준

요즘 AI 에이전트는 단순한 질문에 답하는 수준을 넘어, 복잡한 업무까지 대신 처리할 수 있는 도구로 진화하고 있습니다.

이메일을 보내고, 미팅 일정을 조정하고, 업무를 등록하는 등의 작업을 AI에게 맡길 수 있다면 어떨까요?

이 글에서는 다음 내용을 다루며 MCP에 대한 모든 궁금증을 해결해 드릴게요

기존 AI 자동화 시스템이 겪는 문제
MCP의 등장 배경과 핵심 구성
MCP가 작동하는 방식과 내부 구조
실전 예시로 살펴보는 Google Calendar/Notion 통합
왜 지금 MCP가 중요한지에 대한 이유

이처럼 LLM 기반 AI가 다양한 도구와 데이터를 유기적으로 다루기 위해서는 표준화된 연결 방식이 필요합니다.

바로 여기서 등장하는 것이 MCP(Model Context Protocol)입니다.

1. 기존 AI 도구들의 문제

이메일을 확인하거나 Slack 메시지를 보내는 것처럼 실제 작업을 수행하는 AI 에이전트를 만들어 본 적이 있다면, 그 고통을 잘 아실 겁니다.
그 과정은 지저분하고, 대부분 얻어지는 결과물도 별로 쓸모가 없습니다.

물론, 요즘 훌륭한 API들이 많고, 쓸만한 툴도 존재합니다.
하지만 실제로 일상적인 활용성이나 신뢰성은 그리 만족스럽지 않습니다.

예를 들어 Twitter에서 엄청난 주목을 받았던 Cursor 같은 도구조차도, 최근에는 성능이 떨어진다는 불만이 많아지고 있습니다.

1-1. 너무 많은 API, 하지만 맥락은 거의 없음

AI에게 어떤 도구를 사용하게 하려면, 사실상 각 도구마다 별도의 미니 API 연동을 해야 합니다.
예를 들어 사용자가 이렇게 말한다고 해보죠,

“팀장이 어제 회의 리포트 관련해서 이메일을 보냈나?”

LLM이 이 질문에 제대로 답하려면 다음과 같은 일들을 해야 합니다:

이게 이메일 검색 작업임을 이해해야 함.
→ Slack이나 Notion 같은 다른 시스템이 아니라는 점을 알아야 하죠.
적절한 엔드포인트를 선택해야 함.
→ 예: search_email_messages 같은 Gmail API
결과를 받아서 자연어로 요약해서 전달
이 모든 것을 컨텍스트 윈도우 한계 안에서 수행해야 함

이건 꽤 복잡합니다.
모델은 중간에 잊어버리거나, 추측하거나, 헛소리를 지어낼 가능성이 큽니다.

그리고 더 큰 문제는, 사용자가 그 정답이 정확한지 확인조차 못 한다면, 문제가 있다는 사실조차 모르게 된다는 점입니다.

1-2. API는 단계 기반인데, LLM은 그 단계를 잘 기억하지 못한다

예를 들어 간단한 CRM 시스템 연동을 생각해봅시다.

먼저 연락처 ID를 가져와야 합니다 → get_contact_id
그다음 해당 사용자의 현재 정보를 조회합니다 → read_contact
마지막으로 업데이트할 값을 반영합니다 → patch_contact

전통적인 프로그래밍에서는 이 과정을 함수로 추상화해서 깔끔하게 처리할 수 있습니다.
하지만 LLM을 사용하면 어떨까요?

매 단계마다 다음과 같은 문제가 생길 수 있습니다:
- 잘못된 파라미터
- 필수 필드 누락
- 중간 체인 손상

결국 "AI 어시스턴트"는 원하는 정보를 업데이트하기는커녕, 자연어로 사과하는 일에만 열중하게 됩니다.

1-3. 취약한 프롬프트 엔지니어링

API는 끊임없이 진화합니다.

문서가 변경되고,
인증 흐름도 업데이트되며,
호출 방식도 바뀝니다.

그러다 보면 어느 날 아침, 완벽하게 작동하던 에이전트가 외부 변경 하나로 완전히 망가질 수 있습니다.

AI 시스템에는 공통된 프레임워크나 추상화 계층이 존재하지 않습니다.

대부분의 AI 도구 연동은 프롬프트 엔지니어링 + JSON 핸들링의 허약한 구조물 위에 세워져 있습니다.

1-4. 벤더 종속(Vendor lock-in)

GPT-4 기반으로 도구를 구축했었다고 가정해봅시다.
하지만 나중에 Claude나 Gemini 같은 다른 모델로 바꾸고 싶다면?

프롬프트 아무리 잘 적었어도, 다른 모델에 입력하면 에이전트의 응답이 완전히 달라질 수 있습니다.

그동안 작성한 함수 설명(function description)
시스템 프롬프트(system prompt)

모두 처음부터 다시 써야 할지도 모릅니다.

이건 아주 심각한 문제는 아니지만, 범용적인 표준(solution)은 아직 존재하지 않습니다.

✨ 그래서, MCP가 필요합니다

도구와 모델이 서로 깔끔하고 안정적으로 통신할 수 있는 방법이 필요합니다.
프롬프트 안에 복잡한 로직을 억지로 쑤셔 넣는 방식이 아니라요.

그리고 바로 이것이 MCP가 등장한 이유입니다.

🧩 2. MCP 소개 및 핵심 구성 요소

Model Context Protocol(MCP)은 LLM이 다양한 도구와 데이터를 활용할 수 있도록 컨텍스트와 기능을 표준 방식으로 제공하게 해주는 오픈 프로토콜입니다.

MCP는 AI 세계의 범용 커넥터(universal connector)라고 생각하면 됩니다.
Cursor와 같은 환경에서 플러그인 시스템처럼 작동하여,
에이전트가 다양한 외부 도구와 데이터 소스를 쉽게 연결할 수 있도록 해줍니다.

즉, LLM 기반 에이전트 위에 복잡한 워크플로우나 실제 업무 기능을 얹을 수 있게 도와주는 것입니다.

Gmail을 통해 이메일 전송
Linear에서 업무(Task) 생성
Notion에서 문서 검색
Slack에 메시지 게시
Salesforce의 레코드 업데이트

이 모든 작업을, 표준화된 인터페이스로 자연어 명령만 보내면 수행할 수 있게 된 것입니다.

이게 어떤 의미인지 생각해보세요.
과거에는 5개 이상의 앱을 직접 왔다 갔다 해야 했던 일이,
이제는 하나의 대화 안에서 에이전트를 통해 수행됩니다.

🧱 MCP 구조 개요 (클라이언트-서버 아키텍처)

MCP는 클라이언트-서버 구조를 따릅니다.
즉, 하나의 호스트 애플리케이션(예: Claude, Cursor, IDE 등)이
여러 개의 MCP 서버에 연결되어,
각 서버가 특정 서비스(Google Drive, PostgreSQL, GitHub 등)와 통신하는 방식입니다.

LLM 단독 (좌측)
→ 단순히 텍스트 생성만 가능. 실제 ‘작업’은 불가능
LLM + 도구 (중앙)
→ 툴은 많지만, 각 도구에 대해 별도 통합 필요 → 복잡하고 깨지기 쉬움
LLM + MCP (우측)
→ LLM은 단일 MCP만 바라보고, MCP가 외부 서비스와 연결 → 확장성과 구조적 안정성 확보

📦 전체 구성도 해석

1️⃣ 좌측: MCP Host 영역

Claude: Anthropic의 대표 LLM이며 MCP를 활용하는 대표 모델
Claude Desktop, IDE, AI Tools: MCP를 활용하는 다양한 사용자 앱 또는 에이전트 프론트엔드

→ 이들은 모두 내부에 MCP Client를 내장하고 있고, MCP Protocol을 통해 외부 MCP 서버와 통신합니다.

2️⃣ 중앙: MCP Client – MCP Protocol – MCP Server 연결 구조

MCP Client는 MCP Protocol을 통해 아래 MCP 서버들과 통신합니다:

MCP Server연동 도구

Server A	Google Drive 등 파일 스토리지
Server B	PostgreSQL 같은 데이터베이스
Server C	Slack, GitHub, 인터넷 등 다양한 Web API

→ 각각의 서버는 특정 외부 시스템과 연결되어 있고, 표준화된 방식으로 기능을 노출합니다.

3️⃣ 하단: MCP의 Core Building Blocks (핵심 구성 요소)

MCP는 단순한 연결만이 아니라, 아래와 같은 기능 단위를 Client-Server 구조를 통해 캡슐화합니다.

#구성 요소설명

1	🔐 Secure File Access	안전한 파일 접근 (예: Google Drive 파일 목록 가져오기 등)
2	🎲 Sampling	프롬프트에서 필요한 샘플링 데이터 선택 (예: 최근 항목 3개만 가져오기 등)
3	💬 Prompt	MCP 요청을 통해 자연어 프롬프트 전송 및 응답 처리
4	🌿 Resources	외부 시스템의 리소스 참조 (DB row, 문서, 리포트 등)
5	🧰 Tools & Functions	Slack 메시지 보내기, 업무 생성, DB 업데이트 등의 API 호출 기능 묶음

🧱 핵심 구성 요소 (Core Components)

다음은 일반적인 MCP 서버에서 공통적으로 등장하는 핵심 구성 요소입니다:

🧩 1. MCP 호스트 (MCP Hosts)

Claude Desktop, Cursor, Windsurf 같은 앱 또는
데이터에 접근하고자 하는 AI 도구들을 의미합니다.

→ 이들이 MCP를 통해 외부 데이터나 기능에 접근하려고 합니다.

🔗 2. MCP 클라이언트 (MCP Clients)

MCP 서버와 1:1 연결을 유지하는 프로토콜 클라이언트입니다.
클라이언트는 **에이전트(예: Claude)**와 MCP 서버 간의 통신 다리 역할을 합니다.

→ Claude가 Gmail로 이메일 보내고 싶을 때, MCP Client가 그 요청을 MCP 서버로 전달해주는 거죠.

🖥 3. MCP 서버 (MCP Servers)

각 MCP 서버는 가볍고 단순한 프로그램으로,
파일 읽기, DB 쿼리, 웹 자동화 같은 특정 기능을
표준화된 MCP 인터페이스를 통해 노출합니다.

→ 예: Google Drive를 다루는 서버, PostgreSQL을 다루는 서버 등

📂 4. 로컬 데이터 소스 (Local Data Sources)

당신의 컴퓨터에 있는 파일, 데이터베이스, 서비스 등입니다.
MCP 서버는 이들에 보안적으로 접근할 수 있어야 합니다.

☁️ 5. 원격 서비스 (Remote Services)

GitHub, Slack, Salesforce 같은 외부 API나 클라우드 시스템들입니다.
MCP 서버는 이들과도 직접 연결하여 작업을 수행할 수 있습니다.

📚 참고 자료

전체 아키텍처, 프로토콜 레이어, 연결 수명 주기, 에러 처리에 대해
더 깊이 있게 알고 싶다면, 공식 문서를 참고하면 좋습니다.

또한, 다음 블로그들도 매우 유익합니다:

🧠 3. MCP는 내부적으로 어떻게 작동하나? (How MCP works under the hood)

MCP 생태계는 몇 가지 핵심 구성 요소들이 유기적으로 상호작용하는 구조입니다.
그림과 함께 간단히 살펴보겠습니다.

🖼️ 이미지 해설: MCP Architecture 다이어그램

MCP Hosts: Claude, ChatGPT 같은 LLM 앱
MCP Clients: 클라이언트 파이썬 파일(client.py)로 LLM과 서버를 연결
MCP: USB 허브처럼 클라이언트와 여러 MCP 서버를 연결
MCP Servers: 각 서버가 슬랙, Gmail, 캘린더, 로컬 파일 등 특정 서비스에 연결
Remote Services: Slack, Gmail, Google Calendar 등 외부 API
Local Data Sources: 맥북의 Finder(파일 시스템)처럼 로컬 자원

🧠 비유: MCP는 마치 “AI 모델용 USB 허브”처럼 동작하며,
LLM은 클라이언트를 통해 다양한 서버(즉, 도구들)와 연결됨.

🧩 클라이언트 (Clients)

클라이언트는 Cursor, Claude Desktop과 같은 실제 앱입니다. 그들은 다음 역할을 수행합니다:

서버에서 사용 가능한 기능 목록을 요청
그 기능(툴, 리소스, 프롬프트)을 모델에게 제시
모델이 툴을 사용하겠다고 요청하면, 요청을 서버에 전달하고 결과를 다시 모델에 전달
MCP 프로토콜 기반으로 일관된 상호작용을 유지

→ 요약: 모델 ↔ 사용자 ↔ MCP 서버 간 통신의 중심 허브

🧱 서버 (Servers)

MCP 서버는 사용자/AI와 외부 시스템 사이의 중계자 역할을 합니다.

툴과 리소스 접근을 위한 표준화된 JSON-RPC 인터페이스 제공
기존 API를 MCP 형식으로 감싸줌 → 원 API를 수정할 필요 없음
인증, 기능정의, 통신 표준 처리

→ MCP 서버는 도구(tool), 리소스(resource), **프롬프트(prompt)**를 클라이언트에 제공

🌐 서비스 제공자 (Service Providers)

Discord, Notion, Figma 같은 외부 시스템
이들은 MCP를 위해 API를 바꾸지 않아도 됨

→ 즉, 기존 API를 그대로 두고도 MCP 서버가 이를 래핑해서 제공함

🔧 MCP 핵심 구성 요소

1. 🛠️ Tools (도구)

AI가 실제로 수행할 수 있는 작업을 정의합니다.

예:

search_emails
create_issue_linear

→ 이게 있어야 모델이 현실 세계에서 “일”을 할 수 있음

2. 📦 Resources (리소스)

MCP 서버가 클라이언트에게 노출하고 싶은 데이터 자원입니다.

포함될 수 있는 것:

파일 내용
DB 레코드
API 응답
실시간 시스템 데이터
스크린샷, 이미지
로그 파일 등

모든 리소스는 고유한 URI로 식별됩니다

3. 💬 Prompts (프롬프트)

도구는 “무엇을 할 수 있는지”를 정의하고,
프롬프트는 “어떻게 해야 하는지”를 알려줍니다.

예:

도구 사용 전 안전 체크리스트를 따르도록 지시
특정 워크플로우에 맞춘 응답 스타일 적용
“모든 데이터를 지우기 전에 다시 한 번 확인하라”는 행동 가이드

→ AI가 도구를 사용할 때 행동 지침서처럼 작동

🎯 실전 예시: Google Calendar MCP 서버와 Notion MCP 연동

📌 1. Google Calendar 예시 – 복잡한 API를 AI가 활용하는 방식

🧠 번역

Google Calendar MCP 서버를 상상해보세요.
캘린더 API는 매우 강력하지만 동시에 말이 많습니다.
각 이벤트마다 참석자, 시간대, 알림, 첨부파일 등 수많은 필드를 포함하고 있죠.

예를 들어 모델에게

“다음 주 Alice와의 모든 미팅을 다시 잡아줘”
라고 하면, 관련된 이벤트를 잡음(noise) 속에서 **정확히 골라내는 데 어려움을 겪을 수 있습니다.

🧩 그래서 Prompt + Resource + Tool 조합이 등장합니다.

MCP의 **프롬프트(prompt)**는 모델에게 다음과 같이 지시할 수 있습니다:

“캘린더 이벤트를 다룰 때는 제목이나 참석자가 일치하는 것만 수정해라.
list-events 도구를 써서 관련 이벤트만 추출하고,
그것들을 **임시 리소스(Resource B)**에 복사한 뒤,
변경 사항을 적용하고,
마지막으로 update-events-from-resource 도구를 써서 다시 동기화하라.”

✅ 이 패턴의 이점

AI는 지저분한 원본 데이터 대신 **정제된 리소스(Resource)**에서 작업함
행동 방식은 프롬프트로 통제됨
실제 실행은 **도구(Tool)**로 명시됨

이 구조는 예측 가능하고 안전한 AI 실행 흐름을 가능하게 합니다.

📘 MCP 작동 방식 요약

클라이언트가 MCP 서버에 연결하면
→ 툴, 리소스, 프롬프트 목록을 요청함
사용자의 입력에 따라
→ 어떤 기능을 모델에게 보여줄지 선택함
모델이 특정 행동을 선택하면
→ 클라이언트가 서버를 통해 실행하고
→ 필요한 권한 확인과 데이터 흐름을 처리함

🧯 4. MCP가 해결하는 문제와 그 의미

📌 MCP가 해결하는 문제들

✅ 하나의 공통 프로토콜 = 수천 개의 툴과의 통합 가능

MCP는 단일 프로토콜로 툴 통합을 표준화합니다.

하나의 AI 모델이,
MCP 인터페이스만 갖춘 수천 개의 도구들과
별도 통합 작업 없이 작동할 수 있습니다.

→ 새로운 앱이 생길 때마다 커스텀 통합 코드를 만들 필요가 없어집니다.

예를 들어, 서비스는 자신이 할 수 있는 작업을 이렇게 정의합니다:

“Discord 메시지 전송”, “Linear 티켓 생성”
그리고 어떻게 해야 하는지(파라미터, 인증 방식 등)를
일관된 JSON-RPC 형식으로 설명합니다.

✅ 역할의 명확한 분리 – 모델은 생각하고, 도구는 실행한다

MCP는 **AI 모델(Thinker)**과 **도구(Doer)**의 책임을 분리합니다.

Slack의 API가 바뀐다고 해도,
당신의 AI는 프롬프트 하나 다시 쓸 필요 없이 그대로 작동합니다.

→ 에이전트가 API에 덜 민감해지고 안정적으로 동작할 수 있게 됩니다.

✅ 모델을 바꿔도 도구 설명은 그대로

예를 들어, GPT에서 Claude나 Gemini로 모델을 교체하더라도:

도구 설명,
프롬프트,
작업 로직

이 모두 다시 작성할 필요 없이 그대로 재사용할 수 있습니다.

✅ 메모리와 다단계 워크플로우 지원

MCP는 **기억 기능과 액션 체이닝(다단계 작업 연결)**을 지원합니다.

에이전트는 작업 간 맥락을 기억하고
행동을 지능적으로 연결해 수행할 수 있습니다.

예:

“회의를 요약하고 → 그 요약을 이메일로 전송하고 → 일정에 추가”

✅ 환각(hallucination) 감소

MCP는 명확하고 구조화된 툴 정의를 사용합니다.

→ 모델이 불확실하거나 허구의 데이터를 덜 생성하게 됩니다.
→ 정확성 향상, 현실 기반 대응 가능

❗ 그래서 MCP가 중요한 이유는?

개발자들이 꿈꾸던 범용 AI 어시스턴트를 현실로 만들기 때문입니다.
고급 워크플로우 구성이 가능해져,
AI가 로직까지 처리하는 자동화 시대를 열 수 있기 때문입니다.

🧱 5. MCP의 3계층 구조 (그리고 드디어 이해한 방식)

✨ 이 구조는 다음 3단계로 나뉘며, 로봇/요리사 비유를 통해 설명됩니다.

⚡ ① Model ↔ Context

"LLM과 대화하는 방식 – 모델이 이해할 수 있게 말하자"

Model은 로봇의 뇌(LLM)입니다.
정보를 처리할 수는 있지만, **명확한 지시(Context)**가 있어야 제대로 작동합니다.

🍞 샌드위치 예시:

“샌드위치 만들어줘” → 모호함
“이 빵과 햄, 치즈를 사용해서 만들어줘” → 명확한 Context

✅ 정리:

Model = 로봇 (또는 LLM)
Context = 실행 지시서 (명확한 재료, 순서)

⚡ ② Context ↔ Protocol

"모델에게 구조화된 메모리, 도구, 상태를 제공하자"

로봇이 Context(지시)를 이해했다면,
이제는 어떻게 기억하고, 도구를 사용하고, 상태를 유지하며 작업을 수행할지를 알아야 합니다.
이 역할을 하는 것이 Protocol입니다.

🔪 샌드위치 예시 (계속):

Protocol이 있으면:
- 재료를 기억하고
- 칼을 안전하게 다루며
- 순서를 유지하며 샌드위치를 만듭니다

✅ 정리:

Context = 무엇을 해야 하는지 설명
Protocol = 그걸 수행하는 방법(메모리/도구/형식) 제공

⚡ ③ Protocol ↔ Runtime

"실제로 AI 에이전트를 실행하는 계층"

이제 로봇은 무엇을 해야 하는지(Context),
**어떻게 해야 하는지(Protocol)**를 모두 알고 있습니다.
하지만 실제 작업을 수행하려면 **환경(RunTime)**이 필요합니다.

🍳 샌드위치 예시:

Runtime은 주방입니다.
열이 있고, 도구가 있고, 재료가 놓인 실제 환경이죠.

✅ 정리:

Protocol = 행동 계획서
Runtime = 실제로 그걸 수행하는 실행 환경

🍽 MCP 3계층 비유 – 레스토랑 예시

역할비유설명

Model	👨‍🍳 셰프	지식과 요리 기술을 보유
Context	📜 메뉴판	요리에 필요한 재료와 방향 제시
Protocol	🧑‍🍽 웨이터	메뉴 전달, 알레르기 정보 기억, 요구사항 설명
Runtime	🔥 주방	요리가 실제로 준비되는 환경

🧠 요점 요약

계층설명

Model ↔ Context	LLM이 작업 지시를 이해할 수 있게 만듦
Context ↔ Protocol	메모리, 도구, 상태를 활용해 실행 가능한 구조로 정리
Protocol ↔ Runtime	작업이 실제로 일어나는 환경, 실행 단계

MCP(Model Context Protocol) 완벽 가이드 – AI 도구 연동의 새로운 표준

1. 기존 AI 도구들의 문제

1-1. 너무 많은 API, 하지만 맥락은 거의 없음

1-2. API는 단계 기반인데, LLM은 그 단계를 잘 기억하지 못한다

1-3. 취약한 프롬프트 엔지니어링

1-4. 벤더 종속(Vendor lock-in)

✨ 그래서, MCP가 필요합니다

🧩 2. MCP 소개 및 핵심 구성 요소

🧱 MCP 구조 개요 (클라이언트-서버 아키텍처)

📦 전체 구성도 해석

1️⃣ 좌측: MCP Host 영역

2️⃣ 중앙: MCP Client – MCP Protocol – MCP Server 연결 구조

3️⃣ 하단: MCP의 Core Building Blocks (핵심 구성 요소)

🧱 핵심 구성 요소 (Core Components)

🧩 1. MCP 호스트 (MCP Hosts)

🔗 2. MCP 클라이언트 (MCP Clients)

🖥 3. MCP 서버 (MCP Servers)

📂 4. 로컬 데이터 소스 (Local Data Sources)

☁️ 5. 원격 서비스 (Remote Services)

📚 참고 자료

🧠 3. MCP는 내부적으로 어떻게 작동하나? (How MCP works under the hood)

🖼️ 이미지 해설: MCP Architecture 다이어그램

🧩 클라이언트 (Clients)

🧱 서버 (Servers)

🌐 서비스 제공자 (Service Providers)

🔧 MCP 핵심 구성 요소

1. 🛠️ Tools (도구)

2. 📦 Resources (리소스)

3. 💬 Prompts (프롬프트)

🎯 실전 예시: Google Calendar MCP 서버와 Notion MCP 연동

📌 1. Google Calendar 예시 – 복잡한 API를 AI가 활용하는 방식

🧠 번역

🧩 그래서 Prompt + Resource + Tool 조합이 등장합니다.

✅ 이 패턴의 이점

📘 MCP 작동 방식 요약

🧯 4. MCP가 해결하는 문제와 그 의미

📌 MCP가 해결하는 문제들

✅ 하나의 공통 프로토콜 = 수천 개의 툴과의 통합 가능

✅ 역할의 명확한 분리 – 모델은 생각하고, 도구는 실행한다

✅ 모델을 바꿔도 도구 설명은 그대로

✅ 메모리와 다단계 워크플로우 지원

✅ 환각(hallucination) 감소

❗ 그래서 MCP가 중요한 이유는?

🧱 5. MCP의 3계층 구조 (그리고 드디어 이해한 방식)

✨ 이 구조는 다음 3단계로 나뉘며, 로봇/요리사 비유를 통해 설명됩니다.

⚡ ① Model ↔ Context

🍞 샌드위치 예시:

⚡ ② Context ↔ Protocol

🔪 샌드위치 예시 (계속):

⚡ ③ Protocol ↔ Runtime

🍳 샌드위치 예시:

🍽 MCP 3계층 비유 – 레스토랑 예시

🧠 요점 요약

댓글

티스토리툴바