초보자를 위한 Model Context Protocol (MCP), 그러니까 왜 그냥 API면 안 되는데?

나처럼 “MCP가 그냥 API랑 비슷한 거 아닌가?” 하고 궁금했던 적이 있다면, 이 글이 게으른 개발자에게 MCP가 왜 유용한지 정리해줄 것이다. Lorong AI가 주최한 🎙️ Chop Chop Talk Shop (Chomp Edition): Model Context Protocol에서 Gang Rui가 공유한 내용을 바탕으로, 핵심 요점과 최종 사용자가 MCP를 어떻게 써볼 수 있는지를 한데 묶었다.

TLDR

MCP는 비즈니스 로직(Host)과 도구 실행(Server)을 분리하고, 그 사이를 Client라는 표준화된 다리로 이어 “무엇을 할지”와 “어떻게 할지”를 갈라놓는다. Host는 사용자 상호작용과 AI 추론을 맡고, Server는 재사용 가능한 인터페이스로 기능을 노출한다. 이렇게 표준화하면 에이전트형 AI가 여러 시스템의 기능을 동적으로 찾아내고, 조율하고, 조합할 수 있다.

문제: 개발 작업량의 조합 폭발

병원 의사용 AI 애플리케이션에서 이메일을 보내고 싶다고 해보자. MCP 이전에는 이메일 API를 호출하는 통합 로직을 작성하고, 응답을 처리하고, 모델에 연결하고, 비즈니스 로직까지 덧붙여야 했다. 이제 같은 이메일 API를 써서 환자와의 전화 통화 맥락에서 예약 알림 이메일을 보내고, 전자상거래 할인 알림 같은 다른 앱에도 붙인다고 상상해보자. MCP가 없으면 여러 클라이언트와 사용 사례마다 같은 통합 로직을 다시 구현해야 한다. 이메일 API에 깨지는 변경이라도 생겼다? 여기저기 리팩터링하는 걸 좋아하시길. 😤

MCP ✨는 통합 복잡도가 만들어내는 이차식 문제에 대한 선형 해법이다. UI에서 React 컴포넌트가 해낸 일과 비슷하다. 모듈식이고, 선언적이고, 조합 가능하다.

MCP란 무엇인가?

USB-C가 여러 케이블과 포트의 필요를 줄였듯, MCP는 AI 앱이 외부 도구와 데이터 소스와 대화하는 보편적인 방식을 제공한다. 핵심 구성 요소는 다음과 같다.

💻 MCP 호스트: 요청을 시작하고 사용자 상호작용을 처리하는 AI 애플리케이션. Claude Desktop 같은 것이 여기에 해당한다. 하나의 호스트는 클라이언트를 통해 여러 MCP 서버에 연결할 수 있다.
🔌 MCP 클라이언트: 호스트 안에 내장되어 서버와의 상호작용을 맡는다. 각 클라이언트는 하나의 MCP 서버에 연결된다.
⚙️ MCP 서버: 클라이언트가 사용할 수 있도록 도구, 프롬프트, 리소스 같은 기능을 제공한다.

누구나 자기만의 호스트, 클라이언트, 서버를 만들 수 있다. 아니면 Smithery.ai에 이미 있는 4200개 이상의 기능에 그냥 연결해도 된다.

동작 방식

사용자가 AI 애플리케이션을 연다 → 요청을 한다(예: “누구누구에게 예약을 알려줘”) → MCP 클라이언트가 적절한 도구(예: send_email)와 충분한 맥락이 있는지 확인한다 → MCP 서버를 통해 도구를 호출한다. 서버는 로컬(stdio)에서 돌거나 원격(HTTP Streamable, 또는 커스텀 방식)에서 도는 작은 프로세스다 → 서버가 요청을 처리하고 결과를 돌려준다 → AI가 그 결과를 응답에 포함한다 → 사용자는 최종 답변을 본다.

내부 동작이 더 궁금하다면 여기의 아키텍처 명세를 보면 된다.

왜 MCP인가?

MCP는 관심사의 분리를 강제하고, 재사용성을 높이며, 유지보수를 크게 단순하게 만든다.

마법 같은 부분: AI 헬스케어 앱 예시

현실에서는 사용자의 요구가 빠르게 늘어난다. 우리가 지원해야 할 플랫폼도 같이 늘어난다.

이메일, SMS, 앱 내 포털 메시지로 예약 알림을 보내는 AI 기반 헬스케어 앱을 만든다고 해보자.

MCP로는 이렇게 구조를 잡을 수 있다.

플랫폼마다 호스트 1개(예: 웹, 모바일)
각 호스트 안에 클라이언트 3개 - 채널별로 하나씩: 이메일, SMS, 앱 내 메시지
각 클라이언트는 실제 로직을 처리하는 MCP 서버와 1:1로 연결

다음으로 WhatsApp을 지원하고 싶다? 이미 있는 것이 있으면 재사용하고, 없으면 새 서버를 하나 쓰면 된다. 그러면 모든 호스트에서 바로 쓸 수 있다. 같은 일을 두 번 할 필요가 없다.

API를 넘어서

API는 MCP와 비교하면 크게 두 가지 면에서 한계가 있다.

기능 vs. 아키텍처 - API는 단일 애플리케이션 안의 기능을 노출한다. MCP는 애플리케이션을 가로질러 동작하는 아키텍처를 제공한다. 한 번 만들고, 어디서나 쓴다.
고정형 vs. 적응형 - API는 하드코딩된 트리거를 쓴다. MCP에서는 AI가 맥락에 따라 어떤 도구를 쓸지 결정할 수 있어서, 더 유연하고 지능적인 워크플로가 가능해진다.

MCP는 API를 에이전트가 바로 다룰 수 있는 기능으로 바꾼다. 필요할 때 에이전트가 API를 두고 스스로 추론하고 조합할 수 있게 해준다. 단순히 서비스를 호출하는 것과, 지능적이고 유연한 워크플로를 규모 있게 조율하는 것의 차이다. 웹 개발자가 정적 HTML에서 재사용 가능한 컴포넌트로 넘어갔듯, MCP는 AI 엔지니어가 잘 부서지고 고정된 통합에서 벗어나, 사용자 요구에 실시간으로 반응하는 동적이고 맥락을 이해하는 에이전트형 소프트웨어로 이동하도록 돕는다. 🚀

Anthropic을 넘어서

Anthropic이 처음 소개한 MCP는 주요 LLM 기업들의 지원과 커뮤니티 기여를 등에 업고 빠르게 성장하고 있다.

OpenAI는 Agents SDK에서 MCP를 공식 지원하며, OpenAI API와 ChatGPT 데스크톱 앱 지원도 곧 제공될 예정이다.
Microsoft는 MCP용 공식 C# SDK를 개발했고, 이 프로토콜을 Copilot Studio, VS Code의 GitHub Copilot 에이전트 모드, Semantic Kernel에 통합했다.
GitHub, Slack, Cloudflare 같은 주요 플랫폼도 공식 MCP 연결을 추가했다.
공식 언어 SDK도 여럿 나와 있다: Python(Anthropic), TypeScript(Anthropic), Java(Spring AI), C#(Microsoft), Kotlin(JetBrains), Swift(Loopwork AI), Rust(Anthropic).
OAuth 2.1을 사용하는 Authorization은 3월 26일에 공개됐다.

생태계는 아직 초기 단계다. 가장 빨리 감을 잡는 방법은 호스트를 직접 도구에 연결해보는 것이다.

한계와 가능성

늘 따라오는 LLM 관련 주의사항은 여기에도 그대로 적용된다. 몇몇 서버를 설치해서 써보려 했을 때도 Obsidian용 서버는 이미 실패하고 있었다. MCP는 아직 실험적이고 대부분 로컬 중심이다. 그래도 나는 이것을 떠오르는 미래를 위한 청사진으로 본다. 진짜로 모듈화되고, 재귀적이며, 스스로 확장되는 AI 네이티브 애플리케이션을 만들 때 빠져 있던 조각이다.

시작하기

사용자 입장에서 MCP를 써보는 가장 쉬운 방법은 내 경험상 이랬다.

클라이언트 준비하기: Claude Desktop을 다운로드한다: claude.ai/download. 또는 기존 호스트 중 하나를 써도 된다.
의존성 처리하기: 아직 없다면 Node.js를 설치한다.
서버 찾기: smithery.ai를 둘러보고, 설정은 그쪽에 맡긴다.

다음에는 무엇을 만들 것인가? 👩🏻‍💻

MCP를 쓰면 지금은 여러 기기에서 Claude, Obsidian, ChatGPT 사이에 흩어져 있는 내 블로그 작성 흐름을 하나의 일관된 경험으로 합칠 수 있을 것이다. 계속 맥락 전환에 시간을 태우는 대신에.

다음번에 또 하나의 API 통합을 작성하고 싶은 유혹이 들면 기억하자. MCP는 한 번 쓰고 어디서나 쓰게 해주며, 중요한 일에 집중하게 해준다. 좋은 AI 애플리케이션을 만드는 일 말이다. 그래서, 다음에는 무엇을 만들 것인가?

초보자를 위한 Model Context Protocol (MCP)

Table of Contents