시리즈: MCP API 본질적 차이 연결표준 (총 7편) | 3회
MCP 기본 개념 완전 정리 — AI가 도구를 쓰는 표준 연결 방식, 플러그인/Function Calling과 뭐가 다를까
MCP(Model Context Protocol)는 AI 에이전트가 외부 도구와 데이터를 쓰는 방식을 표준화한 오픈 프로토콜이야. “AI용 USB-C”라는 비유가 자주 나오는 이유, 그리고 기존 플러그인이나 Function Calling과 뭐가 다른지 이 글에서 깔끔하게 정리해볼게.
Summary
- MCP는 LLM 기반 에이전트가 외부 도구/데이터와 상호작용하는 방식을 표준화한 오픈 프로토콜이야
- MCP가 표준화하는 핵심: 도구 발견(Discovery), 표준 설명서(메타데이터), 세션 기반 상호작용, 승인/통제 결합
- 플러그인/커넥터는 “특정 플랫폼의 구현체”, Function Calling은 “모델 종속 기능”, MCP는 “범용 연결 표준”이야
- MCP는 기존 API를 없애는 게 아니라, AI가 그 API를 쓰는 경로를 표준화하는 거야
이 글의 대상
- MCP가 뭔지 이름만 들어봤고, 정확히 뭘 하는 건지 알고 싶은 사람
- “플러그인이랑 뭐가 달라?”, “Function Calling 있는데 왜 MCP가 필요해?”라는 의문이 있는 사람
- 에이전트 시대의 핵심 프로토콜을 비개발자 눈높이에서 이해하고 싶은 사람
목차
- MCP란 뭐야? — 한 문장 정의
- MCP가 표준화하는 4가지
- 비유로 이해하기: AI용 USB-C 허브
- 또 다른 비유: 주방과 셰프
- MCP vs 플러그인/커넥터
- MCP vs Function Calling
- MCP와 봇/에이전트 플랫폼의 관계
MCP란 뭐야? — 한 문장 정의
한 줄 요약: MCP는 AI가 외부 도구와 데이터를 쓰는 방식을 정한 표준 규격이야.
MCP(Model Context Protocol)는 Anthropic이 2024년 11월에 공개한 오픈 프로토콜이야. 공식 정의를 풀어쓰면 이래:
“LLM 기반 애플리케이션(에이전트)이 외부 도구, 데이터, 워크플로와 상호작용하는 방식을 표준화한 오픈 프로토콜”
여기서 중요한 키워드를 하나씩 뜯어보면:
| 키워드 | 의미 |
|---|---|
| LLM 기반 애플리케이션 | ChatGPT, Claude, 사내 AI 도우미 같은 AI 도구들 |
| 외부 도구/데이터 | Jira, GitHub, Google Drive, 사내 DB 같은 시스템들 |
| 상호작용 방식 | 어떻게 연결하고, 뭘 호출하고, 결과를 어떻게 받을지 |
| 표준화 | 모두 같은 규칙으로 |
| 오픈 프로토콜 | 특정 회사 독점이 아니라 누구나 쓸 수 있는 공개 규격 |
2편에서 API가 “소프트웨어끼리의 대화 규칙”이라고 했지? MCP는 그 위에서 “AI가 도구를 쓸 때의 대화 규칙”을 정한 거야. API가 범용 소통 약속이라면, MCP는 AI 에이전트를 위한 특화된 연결 표준이지.
MCP가 표준화하는 4가지
한 줄 요약: MCP는 단순히 “호출”이 아니라, 발견부터 승인까지 전체 흐름을 표준화해.
API는 “이 엔드포인트를 호출하라”가 중심이잖아. MCP는 범위가 더 넓어. “AI가 도구를 쓰려면 어떤 정보와 절차가 필요한가”를 통째로 다뤄.
1. 도구 발견(Discovery)
AI가 “지금 쓸 수 있는 도구가 뭐가 있지?”를 자동으로 알아내는 거야.
MCP 서버에 접속하면, 서버가 제공하는 도구 목록과 각 도구의 입력/출력 형식(스키마)을 AI가 기계적으로 받아와. 마치 식당에 가면 메뉴판을 받는 것처럼, AI가 “여기서 뭘 할 수 있는지”를 먼저 파악하는 단계야.
2. 표준 설명서(메타데이터)
각 도구의 이름, 설명, 입력 구조, 출력 구조가 통일된 형식으로 제공돼.
이게 왜 중요하냐면, AI 모델은 도구의 설명을 읽고 “이 도구가 지금 내 상황에 맞는지” 판단해야 하거든. 설명 형식이 제각각이면 모델이 헷갈려. MCP는 이 설명 형식을 표준으로 고정해서, 어떤 MCP 서버의 도구든 모델이 같은 방식으로 이해할 수 있게 해줘.
3. 세션 기반 상호작용
한 번의 호출로 끝나는 게 아니라, 여러 도구 호출을 이어가며 목표를 달성하는 패턴을 지원해.
예를 들어, “지난주 미해결 버그 티켓을 정리해서 팀에 공유해줘”라는 요청이 들어오면:
1. Jira에서 미해결 티켓 조회 (도구 호출 1)
2. 조회 결과를 바탕으로 요약 정리 (처리)
3. Slack으로 팀에 메시지 전송 (도구 호출 2)
이렇게 여러 단계를 하나의 세션 안에서 이어가는 에이전트 패턴에 MCP가 맞춰져 있는 거야.
4. 승인/통제 결합
도구를 쓸 때 “이거 실행해도 되는지”를 확인하는 절차가 프로토콜에 포함돼 있어.
예를 들어 OpenAI의 MCP 가이드에는 이런 운영 포인트가 명시돼 있어:
- require_approval: 특정 도구 실행 전에 사용자 승인을 요구
- allowed_tools: 사용할 수 있는 도구를 제한
이건 MCP가 단순히 “기술 규격”에서 끝나는 게 아니라, 운영 설계의 언어로도 작동하기 시작했다는 의미야.
비유로 이해하기: AI용 USB-C 허브
한 줄 요약: 기기마다 다른 케이블을 하나의 규격으로 통일하는 거야.
1편에서 잠깐 언급했던 비유를 좀 더 풀어볼게.
USB-C 이전 상황을 생각해봐:
- 아이폰은 Lightning
- 안드로이드 폰은 Micro USB
- 노트북은 USB-A
- 카메라는 Mini USB
- 모니터는 HDMI
기기마다 케이블이 다르니까, 여행 갈 때 케이블 뭉치를 들고 다녀야 했지.
USB-C가 나오면서:
- 충전도 USB-C
- 데이터 전송도 USB-C
- 모니터 연결도 USB-C
- 다 같은 규격!
MCP가 하려는 것도 정확히 이거야:
| USB-C 이전 | MCP 이전 |
|---|---|
| 기기마다 다른 케이블 | AI 도구마다 다른 연결 방식 |
| 케이블을 여러 개 챙겨야 함 | 시스템마다 커넥터를 따로 만들어야 함 |
| 새 기기 = 새 케이블 | 새 시스템 = 새 커넥터 개발 |
| USB-C 도입 후 | MCP 도입 후 |
|---|---|
| 하나의 규격으로 통일 | 하나의 프로토콜로 표준화 |
| 기기 내부 회로는 그대로 | 기존 API/시스템은 그대로 |
| 연결 방식만 표준화 | AI가 쓰는 경로만 표준화 |
중요한 포인트: USB-C가 스마트폰 내부의 CPU를 바꾸지 않듯, MCP도 기존 API나 시스템을 없애거나 바꾸지 않아. 연결하는 방식만 하나로 맞추는 거야.
또 다른 비유: 주방과 셰프
한 줄 요약: 셰프(에이전트)가 주방(MCP 서버)에서 도구와 재료를 표준 방식으로 찾아 쓰는 구조야.
좀 더 디테일한 비유를 원한다면, 주방과 셰프 비유가 좋아:
- 셰프 = AI 에이전트: 요리(업무)의 목표를 정하고, 무슨 도구와 재료가 필요한지 판단해
- 주방 = MCP 서버: “여기에 어떤 도구(칼, 오븐, 믹서)와 재료(채소, 고기, 양념)가 있고, 각각 어떻게 쓰는지” 설명서를 제공해
- 표준 설명서 = MCP 메타데이터: 모든 주방이 동일한 형식으로 도구/재료 목록을 제공하니까, 셰프가 처음 가는 주방에서도 바로 일할 수 있어
기존 방식(MCP 없이):
셰프가 새 주방에 가면, 주방마다 설명서 형식이 달라서 매번 배우는 시간이 필요했어.
MCP 도입 후:
어떤 주방에 가든 같은 형식의 설명서가 있으니까, 셰프는 바로 “아, 여기 이런 도구가 있구나” 파악하고 요리를 시작할 수 있어.
MCP vs 플러그인/커넥터
한 줄 요약: 플러그인은 “특정 제품용 구현체”, MCP는 “범용 연결 표준”이야.
MCP 얘기가 나오면 제일 먼저 드는 의문이 “그거 플러그인이랑 뭐가 달라?”야. 차이를 정리하면:
| 비교 항목 | 플러그인/커넥터 | MCP |
|---|---|---|
| 정체 | 특정 플랫폼이 특정 서비스와 연결되도록 만든 구현체(제품) | 연결 방식을 정의한 프로토콜(규격) |
| 범위 | 특정 플랫폼 전용 | 플랫폼 독립적 |
| 재사용 | 다른 플랫폼에서 못 씀 | 어떤 MCP 클라이언트에서든 재사용 가능 |
| 예시 | ChatGPT 플러그인, Notion 커넥터 | MCP 서버 (여러 AI 도구가 같은 서버를 공유) |
쉽게 말하면, 플러그인은 “이 TV에 맞는 이 리모컨”이고, MCP는 “모든 TV에서 쓸 수 있는 리모컨 규격”이야.
실무에서 이게 왜 중요하냐면, 플러그인 방식으로는 같은 연결을 여러 번 만드는 비용이 조직 규모가 커질수록 부담이 되거든. “Slack 연동”을 ChatGPT용으로 한 번, Claude용으로 한 번, 사내 챗봇용으로 또 한 번 만드는 건 비효율적이잖아.
MCP vs Function Calling
한 줄 요약: Function Calling은 “모델이 함수를 부르는 기능”, MCP는 “도구 발견부터 승인까지의 전체 표준”이야.
이것도 자주 혼동되는 부분이야. 2편에서 “Function Calling ≠ API”라고 했는데, MCP와의 차이도 명확하게 잡아보자.
Function Calling이란?
모델한테 “이런 함수들이 있어”라고 스키마를 알려주면, 모델이 대화 중에 “이 함수를 이 파라미터로 호출해야겠다”고 판단하는 기능이야. 강력하지만:
- 벤더 종속: OpenAI의 Function Calling과 Anthropic의 Tool Use는 구현이 달라
- 재사용 어려움: 한 플랫폼에서 정의한 함수를 다른 플랫폼에서 그대로 쓰기 어려워
- 운영 표준 부재: 승인/권한/감사 같은 운영 요소는 별도로 구현해야 해
MCP는 뭐가 다를까?
| 비교 항목 | Function Calling | MCP |
|---|---|---|
| 범위 | 함수 정의 → 모델 판단 → 호출 | 도구 발견 → 호출 → 승인 → 결과 반환 → 다음 행동 |
| 종속성 | 특정 모델/플랫폼 종속 | 플랫폼 독립적 표준 |
| 재사용 | 플랫폼 간 재사용 어려움 | MCP 서버 하나로 여러 클라이언트가 공유 |
| 운영 통제 | 별도 구현 필요 | 프로토콜에 승인/권한 흐름 포함 |
정리하면, Function Calling은 MCP 흐름의 일부분(모델이 도구를 호출하는 순간)에 해당하는 거야. MCP는 그 앞뒤로 “어떤 도구가 있는지 발견하고”, “호출해도 되는지 승인받고”, “결과를 다음 행동에 연결하는” 전체 라이프사이클을 표준으로 잡아.
MCP와 봇/에이전트 플랫폼의 관계
한 줄 요약: MCP는 에이전트 플랫폼이 외부 도구를 확장하는 “표준 연결부” 역할을 해.
에이전트 플랫폼(예: OpenAI Agents SDK, LangChain 등)은 AI가 복잡한 업무를 수행하도록 도와주는 프레임워크야. 이런 플랫폼에서 MCP가 어떤 역할을 하는지 정리하면:
- 에이전트 플랫폼: “AI가 계획을 세우고, 도구를 쓰고, 결과를 종합하는” 전체 프레임워크
- MCP: 그 프레임워크에서 “외부 도구를 연결하는 부분”의 표준 규격
비유하자면, 에이전트 플랫폼이 “공장 전체 운영 시스템”이라면, MCP는 “공장에 부품을 공급하는 표준 물류 규격”이야.
OpenAI도 Agents SDK에서 MCP 서버를 다루는 가이드를 별도로 제공하고 있어. Anthropic이 만든 프로토콜을 OpenAI도 지원한다는 건, MCP가 특정 회사의 전유물이 아니라 업계 공통 표준으로 자리잡아가고 있다는 신호야.
핵심 정리
1. MCP = AI 에이전트가 외부 도구/데이터를 쓰는 방식의 오픈 표준.
2. 표준화 대상: 도구 발견 → 표준 설명 → 세션 기반 호출 → 승인/통제.
3. 플러그인은 "제품", MCP는 "규격". 재사용성에서 차원이 달라.
4. Function Calling은 MCP의 "일부분"에 해당. MCP가 더 넓은 범위를 커버해.
5. MCP는 기존 API를 없애지 않아. AI가 API를 쓰는 경로를 표준화하는 거야.
FAQ
Q. MCP를 한 문장으로 설명하면?
A. AI가 외부 도구와 데이터를 쓸 때 따르는 표준 연결 규격이야. 어떤 AI 도구든, 어떤 시스템이든 같은 방식으로 연결할 수 있게 해주는 프로토콜이지.
Q. MCP는 Anthropic 전용이야?
A. 아니야. 오픈 프로토콜이라 누구나 쓸 수 있어. 실제로 OpenAI도 MCP를 지원하는 가이드를 공개했고, Zed, Sourcegraph 같은 다양한 도구들이 MCP를 채택하고 있어.
Q. 우리 회사에서 쓰는 ChatGPT 플러그인이랑 MCP는 뭐가 달라?
A. ChatGPT 플러그인은 ChatGPT에서만 돌아가는 “구현체”야. MCP는 ChatGPT, Claude, 사내 AI 도구 어디서든 같은 방식으로 쓸 수 있는 “규격”이지. 한 번 MCP 서버를 만들면 여러 AI 도구가 재사용할 수 있어.
Q. Function Calling만으로 충분하지 않아?
A. 단일 모델에서 단순한 함수 호출만 한다면 충분할 수 있어. 하지만 여러 모델/앱이 여러 도구를 재사용하고, 승인/권한/감사까지 표준화하려면 MCP 같은 프로토콜 레벨의 표준이 필요해져.
Q. MCP 서버는 누가 만들어?
A. 도구를 제공하는 쪽에서 만들어. 예를 들어 GitHub용 MCP 서버는 GitHub API를 MCP 표준 형식으로 감싸서 제공하는 거야. 커뮤니티에서 만든 오픈소스 MCP 서버도 많아.
Q. MCP를 도입하면 기존 API는 버려야 해?
A. 전혀. MCP 서버 내부에서 기존 API를 그대로 호출해. MCP는 기존 API 위에 “AI 친화적 레이어”를 올리는 거지, 기존 걸 대체하는 게 아니야.
참고 자료
| 출처 | 내용 | 링크 |
|---|---|---|
| Anthropic | MCP 공식 발표 | anthropic.com |
| MCP 공식 문서 | MCP 시작 가이드 | modelcontextprotocol.io |
| MCP 스펙 | 도구(Tools) 명세 | modelcontextprotocol.io |
| Vercel | MCP 설명 블로그 | vercel.com |
| OpenAI | MCP 도구 가이드 | developers.openai.com |
| Descope | Function Calling vs MCP 비교 | descope.com |
| Codilime | MCP 개념 설명 | codilime.com |
“MCP is an open protocol that standardizes how applications provide context to LLMs.” — Anthropic
다음 편 예고
4편: MCP vs API 구조적 비교 — 같은 선상에서 비교하면 안 되는 이유에서는 목적(Why), 사용자(Who), 통합 단위(What), 확장 방식(How), 운영(보안/권한)까지 5가지 축으로 MCP와 API를 구조적으로 비교할 거야. “MCP가 API보다 좋은 거야?”라는 잘못된 질문에서 벗어나는 프레임을 잡아줄게.