MCP(Model Context Protocol) - AI에 표준 연결 단자 달기
함수 호출로 도구를 연결하고 에이전트까지 만들다 보면 곧 새로운 고민이 생깁니다. "이 도구 연결을 매번, 앱마다, 모델마다 다시 짜야 하나?" 이 파편화 문제를 표준으로 풀려는 시도가 MCP(Model Context Protocol) 입니다.
이 글에서는 MCP가 왜 나왔고, 어떤 구조이며, 개발자에게 어떤 의미인지를 제가 아는 범위에서 개념 중심으로 정리합니다.
1. 왜 MCP가 나왔나 - 연결의 파편화
LLM 앱에 도구·데이터를 붙이는 일은 지금까지 제각각이었습니다.
- 앱마다 GitHub, Slack, DB, 파일시스템 연동을 자기 방식대로 구현합니다.
- 모델/프레임워크가 바뀌면 그 연동을 또 새로 짭니다.
- 같은 "Slack 연결"을 회사마다, 앱마다 중복 개발합니다.
이건 전형적인 M×N 문제입니다. M개의 AI 앱과 N개의 데이터/도구를 붙이려면 최악의 경우 M×N개의 커넥터가 필요합니다.
[MCP 이전] 앱마다 도구마다 개별 연동 (M × N)
앱A ──╳──▶ GitHub
앱A ──╳──▶ Slack
앱B ──╳──▶ GitHub ← 같은 연결을 또 구현
앱B ──╳──▶ DB
...끝없이 중복
MCP의 목표는 이걸 M + N으로 바꾸는 것입니다. 연결 방식을 표준화해서, 도구 쪽은 표준 서버 하나만 만들고 앱 쪽은 표준 방식으로 그 서버들에 붙습니다.
2. "USB-C 같은 표준" 비유
MCP를 설명할 때 흔히 쓰는 비유가 USB-C입니다.
예전엔 기기마다 충전 단자가 제각각이라 케이블을 잔뜩 들고 다녔습니다. USB-C는 하나의 표준 단자로 이걸 정리했죠. 노트북이든 폰이든, USB-C 구멍만 있으면 어떤 USB-C 주변기기든 꽂힙니다.
MCP가 노리는 것도 같습니다.
AI 애플리케이션과 외부 도구/데이터 사이에 "표준 연결 단자"를 만든다.
한 번 MCP 서버로 만들어 둔 도구는, MCP를 지원하는 어떤 AI 앱에서든 그대로 쓸 수 있습니다. 반대로 MCP를 지원하는 앱은 새로운 도구가 나와도 연동 코드를 새로 짜지 않고 꽂기만 하면 됩니다.
[MCP 이후] 표준 단자로 통일
┌─▶ [MCP 서버] GitHub
AI 앱 ─MCP─┼─▶ [MCP 서버] Slack
(클라이언트)└─▶ [MCP 서버] 사내 DB
서버는 한 번만 만들면 여러 앱이 공유
3. 클라이언트-서버 구조
MCP는 클라이언트-서버 구조입니다. 역할을 나눠 보면 이렇습니다.
- 호스트(Host): 사용자가 쓰는 AI 애플리케이션(예: AI IDE, 데스크톱 어시스턴트, 챗봇). LLM이 여기서 돕니다.
- 클라이언트(Client): 호스트 안에서 특정 MCP 서버 하나와 연결을 맡는 부분. 서버당 하나씩 붙습니다.
- 서버(Server): 실제 도구·데이터를 표준 형식으로 노출하는 쪽. 예) 파일시스템 서버, GitHub 서버, DB 서버.
┌───────── 호스트(AI 앱) ─────────┐
│ LLM │
│ ├─ 클라이언트 ──▶ MCP 서버(파일) │
│ ├─ 클라이언트 ──▶ MCP 서버(GitHub)│
│ └─ 클라이언트 ──▶ MCP 서버(DB) │
└─────────────────────────────────┘
호스트와 서버는 정해진 메시지 규격(프로토콜) 으로 대화합니다. 서버는 로컬 프로세스로 돌 수도, 원격에 있을 수도 있습니다. 중요한 건 양쪽이 같은 약속을 따르기 때문에 서로를 몰라도 붙는다는 점입니다.
4. 리소스·툴·프롬프트 - 서버가 제공하는 것
MCP 서버가 호스트에 노출하는 것은 크게 세 종류입니다. 이 구분이 MCP 이해의 핵심입니다.