MCP(Model Context Protocol) 정리: AI가 도구를 쓰는 표준
이 블로그의 에이전트 관련 글에서 MCP가 여러 번 등장했지만, 정작 MCP 자체를 정리한 글이 없었습니다. 이번 글에서 정리합니다. 결론을 먼저 적으면, MCP(Model Context Protocol)는 LLM 애플리케이션과 외부 도구·데이터를 잇는 개방형 표준 프로토콜입니다. 2024년 11월 Anthropic이 공개했고, 2025년에 OpenAI, Google, Microsoft, AWS가 차례로 채택하면서 2026년 현재 이 영역의 사실상 표준이 됐습니다. 실제로 앱에서 쓰는 법은 LLM 앱 개발 #11에서, 서버를 직접 만드는 법은 AI 에이전트 개발 #6에서 다뤘고, 이 글은 두 글보다 먼저 읽어 두면 좋은 개념 정리입니다.
어떤 문제를 푸는가: N×M을 N+M으로 #
MCP 이전의 도구 연동은 전부 전용 구현이었습니다. 앱이 Slack, GitHub, 사내 DB에 접근하려면 각 연동을 그 앱 전용으로 코딩하고, 다른 앱을 만들면 같은 연동을 또 만들었습니다. 앱(호스트) N개 × 도구 M개만큼 통합 코드가 생기는 구조입니다.
MCP는 이 사이에 표준 인터페이스를 끼워 넣습니다. 도구 쪽은 MCP 서버를 한 번 만들면 MCP를 지원하는 모든 앱에서 재사용되고, 앱 쪽은 MCP 클라이언트를 한 번 구현하면 모든 MCP 서버에 연결됩니다. N×M이 N+M으로 줄어드는 것이 프로토콜의 존재 이유입니다.
함수 호출(function calling)과의 관계도 여기서 정리됩니다. 함수 호출은 “모델이 정해진 스키마로 도구 호출을 출력하는 능력"이고, MCP는 “그 도구를 누가 어떻게 제공하고 발견하는가"의 표준입니다. 경쟁 관계가 아니라 층이 다릅니다. 모델은 여전히 함수 호출로 도구를 부르고, MCP는 그 도구 목록을 표준 방식으로 공급합니다.
구조: 호스트, 클라이언트, 서버와 세 프리미티브 #
- 호스트: 사용자가 마주하는 LLM 앱입니다. 데스크톱 어시스턴트, IDE, 에이전트 런타임이 여기에 해당합니다.
- 클라이언트: 호스트 안에서 서버와의 연결 하나를 담당하는 부품입니다. 호스트가 서버 3개에 붙으면 클라이언트도 3개입니다.
- 서버: 도구와 데이터를 노출하는 쪽입니다. 파일시스템, GitHub, DB 조회, 사내 API 래퍼처럼 “모델이 쓸 수 있게 만들고 싶은 것"이 서버가 됩니다.
서버가 노출하는 것은 세 종류로 정리됩니다.
| 프리미티브 | 무엇 | 사용 주체 |
|---|---|---|
| tools | 모델이 호출하는 동작 (검색, 생성, 전송) | 모델이 판단해 호출 |
| resources | 읽기용 데이터 (파일, 스키마, 문서) | 앱이 컨텍스트로 공급 |
| prompts | 재사용 프롬프트 템플릿 | 사용자가 선택 |
전송 방식은 둘입니다. 같은 머신에서 프로세스로 띄우는 stdio(로컬 파일시스템, 개발 도구 연동의 기본)와, 원격 서버로 배포하는 streamable HTTP(조직 공유, SaaS 연동)입니다. 원격 서버의 인증은 OAuth 기반으로 표준화되어 있습니다.
2026년 현재: 사실상 표준이 된 과정 #
- 2024-11: Anthropic이 공개하고 오픈 소스로 전환했습니다.
- 2025: OpenAI(3월, Agents SDK), Google(4월, Gemini SDK), Microsoft(Copilot Studio·Windows), AWS(Bedrock)가 차례로 지원을 붙이면서 “특정 벤더의 프로토콜"이라는 꼬리표가 떨어졌습니다.
- 2026-01: Anthropic이 MCP를 Linux Foundation 산하 재단으로 이관했습니다. 거버넌스가 중립화되면서 기업 도입의 마지막 걸림돌이 정리된 셈입니다.
- 규모: 공식 레지스트리에 등록된 서버가 2026년 중반 기준 1만 개 규모이고, 커뮤니티 인덱스까지 합치면 그 몇 배입니다. 스펙은 날짜 기반 버전(예: 2025-06-18)으로 계속 개정되므로, SDK 업데이트 시 대상 버전 확인이 필요합니다.
보안: 편해진 만큼 공격면도 표준화됐습니다 #
MCP 도입 시 검토해야 할 위험은 도구 연동 일반의 위험과 같지만, 연결이 쉬워진 만큼 더 자주 밟게 됩니다.
- 서드파티 서버 신뢰: 레지스트리에 있다는 것이 안전하다는 뜻은 아닙니다. 서버는 모델에게 도구 설명을 공급하는데, 악의적 설명으로 모델 행동을 조종하는 공격(tool poisoning)이 실증되어 있습니다. 출처가 확인된 서버만 붙이고, 사내 표준 목록을 관리하는 것이 기본입니다.
- 프롬프트 인젝션: 도구가 가져온 결과(웹 페이지, 이슈 본문, 이메일)에 심긴 지시문을 모델이 따라가는 문제입니다. MCP 고유의 취약점이 아니라 도구를 쓰는 모든 에이전트의 문제이며, 민감한 동작(쓰기, 전송, 삭제)에 사람의 승인을 끼우는 것이 현실적인 방어선입니다.
- 권한 최소화: 서버에 주는 자격 증명은 읽기 전용, 범위 최소로 시작합니다. “일단 관리자 토큰"이 가장 흔한 사고 경로입니다.
- 컨텍스트 비대: 서버를 많이 붙일수록 도구 정의가 컨텍스트를 잠식해 비용과 정확도를 갉아먹습니다. 작업에 필요한 서버만 활성화하는 운영이 필요합니다.
도입 판단: 필요한 경우와 아닌 경우 #
앱 하나가 도구 서너 개를 쓰는 구조라면 MCP 없이 함수 호출로 직접 구현하는 것이 오히려 단순합니다. MCP가 값을 하는 것은 다음 경우입니다.
- 같은 도구를 여러 클라이언트에서 씁니다. IDE에서도, 데스크톱 어시스턴트에서도, 자체 에이전트에서도 같은 사내 도구를 쓰고 싶다면 서버 하나로 끝납니다.
- 조직 안에서 도구를 공유합니다. 팀마다 같은 연동을 다시 만드는 대신, 사내 MCP 서버 목록을 표준 자산으로 관리합니다.
- 서드파티 생태계를 활용합니다. 이미 만들어진 서버(GitHub, DB, 검색 등)를 붙여 개발 없이 도구를 확보합니다.
- 에이전트를 제품으로 만듭니다. 사용자가 자기 도구를 연결하게 하려면 표준 프로토콜 외의 선택지가 사실상 없습니다.
정리 #
- MCP는 LLM 앱과 도구·데이터를 잇는 개방형 표준입니다. 도구 연동의 N×M 문제를 서버 한 번, 클라이언트 한 번의 N+M으로 줄입니다.
- 함수 호출과 경쟁하지 않습니다. 함수 호출은 모델의 출력 능력이고, MCP는 도구 공급의 표준입니다.
- 구조는 호스트·클라이언트·서버, 서버가 노출하는 것은 tools·resources·prompts입니다. 로컬은 stdio, 원격은 streamable HTTP + OAuth입니다.
- 2025년 주요 벤더 채택과 2026년 초 재단 이관으로 사실상 표준이 됐습니다. 스펙은 날짜 버전으로 계속 개정됩니다.
- 서드파티 서버 신뢰, 프롬프트 인젝션, 권한 최소화가 보안 검토의 축입니다. 도구 몇 개짜리 단일 앱이라면 도입하지 않는 것도 정답입니다.