AI 도구·자동화의 다음 단계는 모델 자체의 성능이 아니라, 그 모델이 닿을 수 있는 시스템의 넓이에서 갈린다. MCP 프로토콜(Model Context Protocol)은 그 연결을 표준화한 오픈 프로토콜이다. Anthropic이 2024년 11월 25일에 공개한 이후 약 1년 반 만에 200개가 넘는 MCP 서버가 공개되어 사실상의 업계 표준으로 자리잡고 있다. 이 글은 MCP의 구조·전송 방식·Claude Code 통합·생태계 현황·한계를 입문자 관점에서 분석 톤으로 정리한다.
MCP 프로토콜이 해결하는 문제
MCP가 등장하기 전, AI 도구가 외부 시스템과 연결되는 방식은 일관성이 낮았다. 모델 A와 도구 X를 잇는 통합 코드, 모델 B와 도구 X를 잇는 또 다른 통합 코드. 같은 도구라도 어떤 LLM 호스트와 연결하느냐에 따라 처음부터 다시 짜야 했다. 도구가 N개, 모델 호스트가 M개라면 통합 코드는 최악의 경우 N×M개가 필요했다.
MCP는 이 N×M 문제를 N+M으로 줄이는 표준화 계층이다. 모델 호스트는 MCP 클라이언트 인터페이스만 구현하면 되고, 외부 도구·데이터 제공자는 MCP 서버 인터페이스만 구현하면 된다. 그 사이의 연결은 표준 메시지로 처리된다.
Anthropic은 공식 발표에서 “모델은 데이터에 닿지 못하면 가치를 만들지 못한다“는 점을 강조한다. 그래서 MCP의 정체성을 “AI 애플리케이션 확장을 위한 보편 표준”으로 정의한다. 비유하자면 AI 시스템에 깔린 USB-C다. 어떤 모델이든, 어떤 도구든, 같은 포트를 꽂는 식의 단일 인터페이스를 지향한다. 기술적으로는 IDE 업계의 LSP(Language Server Protocol)가 LLM 영역으로 옮겨온 형태에 가깝다.
이 표준이 자리 잡으면, 사내 시스템·SaaS·데이터베이스·문서 저장소가 LLM과 연결되는 비용이 급격히 떨어진다. 매번 새로운 플러그인을 만드는 대신, MCP 서버 하나만 운영하면 여러 AI 호스트가 동시에 사용할 수 있다.
아키텍처 — Host·Client·Server
MCP의 아키텍처는 세 가지 역할로 구성된다. Anthropic 공식 사양의 정의를 그대로 따르면 다음과 같다.
| 역할 | 위치 | 책임 |
|---|---|---|
| Host | 사용자가 사용하는 앱 | Claude Desktop, Claude Code, Cursor 같은 LLM 통합 애플리케이션 |
| Client | Host 내부 컴포넌트 | 1개의 MCP 서버와 1:1 연결 관리. 인증·세션·요청 라우팅 담당 |
| Server | 외부 프로그램 | Tools·Resources·Prompts를 노출하는 도구·데이터 제공자 |
Host 하나는 여러 Client를 동시에 가질 수 있고, 각 Client는 정확히 하나의 Server에 연결된다. 이 구조 덕분에 Host는 모든 외부 시스템을 직접 관리할 필요 없이, Client 묶음만 관리하면 된다.
메시지 프로토콜은 JSON-RPC 2.0 위에 LSP(Language Server Protocol)에서 이미 검증된 메시지 패턴을 재활용한다. 요청·응답·알림(notification) 같은 메시지 형태가 그대로 들어왔다. LSP가 IDE와 언어 서버 사이에서 “코드 자동완성·정의로 이동·진단” 같은 표준 행동을 제공했듯, MCP는 LLM과 도구 사이에서 “도구 호출·데이터 읽기·프롬프트 적용” 같은 표준 행동을 제공한다.
세 계층을 분리한 효과는 운영 관점에서 분명하다. Host는 보안·UX에 집중하고, Server는 외부 시스템 통합에 집중한다. 한쪽이 망가져도 다른 쪽의 책임 경계가 흐려지지 않는다.
Tools·Resources·Prompts — 세 가지 기본 단위
MCP 서버가 클라이언트에게 노출하는 능력은 세 가지 유형으로 정리된다.
- Tools: LLM이 호출할 수 있는 함수. 실제 작업을 수행한다. 예: Slack 메시지 전송, GitHub 이슈 생성, 데이터베이스 INSERT.
- Resources: 데이터를 읽기 위한 엔드포인트. REST API의 GET 메서드와 유사한 위치다. 예: 디자인 문서 본문, 파일 시스템의 특정 디렉토리, 위키 페이지.
- Prompts: 도구와 자원을 잘 활용하기 위한 사전 정의 템플릿. 사용자가 매번 같은 지시를 길게 쓰지 않아도 되게 묶어둔다.
IBM Think의 정리는 이 셋의 의미를 분명히 구분한다. Tools는 “행동”, Resources는 “맥락”, Prompts는 “재사용 가능한 패턴”이라는 표현이다. 같은 데이터를 노출하더라도 Tool로 노출하면 LLM이 호출 시 부작용을 발생시키고, Resource로 노출하면 단순히 읽고 분석하는 컨텍스트가 된다. 권한 설계가 달라지는 지점이라 의도적인 분리가 중요하다.
실제 MCP 서버를 보면 세 가지가 모두 구현되는 경우가 많다. 예컨대 Google Drive MCP 서버는 파일 목록을 Resource로, 파일 생성·수정을 Tool로, 자주 쓰는 검색 패턴을 Prompt로 동시에 노출한다.
전송 방식과 SDK
MCP는 두 가지 전송 방식을 지원한다. Cloudflare 학습 자료의 정리에 따르면 다음과 같다.
- stdio (standard input/output): 로컬 프로세스 간 통신. Host가 Server를 자식 프로세스로 띄우고 표준 입출력으로 메시지를 주고받는다. 로컬 개발·개인 사용자 환경에 적합하다.
- HTTP + SSE (Server-Sent Events): 원격 서버와의 양방향 통신. 서버는 HTTP 엔드포인트를 노출하고, 클라이언트는 SSE로 푸시 메시지를 받는다. 팀·기업 단위 운영에 적합하다.
전송 방식이 두 가지인 이유는 단순하다. 같은 사양으로 노트북에 깔린 로컬 도구와 클라우드에 띄운 원격 서비스를 모두 다루기 위해서다. Stdio는 가볍지만 같은 머신 안에서만 작동하고, SSE는 운영 비용이 들지만 어디서든 접속 가능하다.
공식 SDK는 Python·TypeScript·C#·Java 네 가지 언어로 제공된다. SDK가 프로토콜의 복잡성을 감춰주기 때문에, 서버를 만드는 개발자는 핵심 비즈니스 로직에 집중할 수 있다. 사양 문서 자체는 modelcontextprotocol.io에서 2025-11-25 버전까지 공개되어 있고, 메시지 포맷·오류 코드·인증 흐름까지 명세된 상태다.
Claude Code와 MCP — 클라이언트이자 서버
Claude Code는 MCP 생태계에서 두 가지 역할을 동시에 한다. Claude Code 공식 한국어 문서는 이 이중 구조를 명확히 설명한다.
첫째, Claude Code는 MCP 클라이언트다. 사용자가 설정 파일에 외부 MCP 서버를 등록하면, Claude Code가 그 서버의 Tools·Resources·Prompts를 자기 컨텍스트로 가져온다. Slack 메시지를 직접 보내고, Notion 페이지를 읽어오고, Jira 티켓을 갱신하는 식이다.
둘째, Claude Code 자체가 MCP 서버로도 동작한다. claude mcp serve 명령을 실행하면 Claude Code의 핵심 기능(파일 편집·코드 생성·코드 분석)이 MCP 서버로 외부에 노출된다. 다른 MCP 클라이언트—Cursor·VSCode 확장·별도 AI 에이전트—가 그 능력을 호출할 수 있다. 결과적으로 Claude Code가 다른 AI 도구의 백엔드 역할까지 한다는 의미다.
설정은 두 단계로 나뉜다. 글로벌 설정(~/.claude/)은 모든 프로젝트에서 공유되는 MCP 서버를 등록하고, 프로젝트 설정(.claude/mcp.json 또는 프로젝트 루트의 설정 파일)은 해당 저장소에서만 쓰는 서버를 등록한다. 같은 Slack 통합이라도 회사 워크스페이스용 토큰은 프로젝트 단위로, 개인 학습용 통합은 글로벌로 두는 식이다.
대표적인 통합 사례를 묶어보면 다음과 같다.
| 분야 | MCP 서버 | 효과 |
|---|---|---|
| 협업 | Slack·Notion·Jira | 채널 메시지 전송, 문서 갱신, 티켓 흐름 자동화 |
| 디자인·문서 | Figma·Google Drive | 디자인 사양을 코드로, 문서를 컨텍스트로 |
| 개발 인프라 | GitHub·GitHub Actions | 이슈 생성, 워크플로 트리거, PR 코드 리뷰 |
| 데이터 | Postgres·SQLite·로컬 파일 | 데이터베이스 직접 조회, 로그 분석 |
이 표가 의미하는 바는 명확하다. Claude Code가 코드만 만지는 단계에서 업무 시스템 전반과 통합되는 단계로 옮겨가고 있다는 신호다.
200개+ 생태계 — 기존 서버 활용 vs 커스텀 개발
apidog의 한국어 정리에 따르면 2026년 3월 기준 공개된 MCP 서버는 200개를 넘는다. 대부분의 일상적인 통합 수요는 기존 서버를 가져다 쓰는 것으로 해결된다. Slack·Notion·GitHub·Figma·Postgres 같은 인기 도구는 이미 안정적인 공식 또는 커뮤니티 서버가 존재한다.
그렇다면 직접 MCP 서버를 만들어야 하는 경우는 언제일까. 세 가지 상황이 흔하다.
- 사내 시스템 통합: 외부에 공개되지 않은 사내 API·내부 도구를 LLM과 연결할 때
- 독자 API 통합: 회사가 자체적으로 운영하는 SaaS·B2B 제품의 기능을 AI 에이전트가 호출하게 만들 때
- 도메인 특화 도구: 의료·금융·법률처럼 일반 MCP 서버로는 권한·감사 요구를 못 맞추는 영역
이 경우에도 공식 SDK가 프로토콜 메시지 처리·오류 코드·세션 관리를 추상화해주기 때문에, 개발자는 핵심 비즈니스 로직만 신경 쓰면 된다. Python·TypeScript SDK 기준으로 가장 기본적인 MCP 서버는 100줄 안팎의 코드로도 구현 가능하다는 보고가 다수 있다.
생태계 규모와 SDK 성숙도를 함께 고려하면, MCP는 더 이상 “Anthropic이 띄운 실험”이 아니라 여러 AI 호스트와 도구 제공자가 공통으로 채택한 표준이라는 평가가 적절하다.
MCP 프로토콜의 한계와 진입 장벽
MCP의 강점이 분명한 만큼 한계도 명확하다.
- 인증·권한 설계 복잡성: MCP 서버가 외부 시스템 권한을 위임받아 동작하기 때문에, 토큰 관리·범위 제한·감사 로그가 필수다. 한 번 설정하면 끝이 아니라 지속적인 운영 부담이 따른다.
- 원격 SSE 전송의 운영 부담: HTTP+SSE 기반 원격 서버는 stdio 로컬 방식보다 안정성·확장성을 위한 인프라가 더 든다. 작은 팀이 처음부터 원격 운영을 도입하기엔 부담이 크다.
- 200개 서버의 품질 편차: 생태계가 빠르게 커진 만큼 활발히 관리되지 않는 서버, 보안 검토가 부족한 서버도 섞여 있다. 사내 도입 시 신뢰할 수 있는 서버 선별이 별도 작업이다.
- 신기술 표준 변화 위험: 사양 자체가 2024-11-25 첫 공개 이후 2025-11-25 버전까지 발전했다. 표준이 안정화되는 과정에서 호환성 문제가 발생할 수 있다.
어떤 환경에서 우선 도입할 가치가 가장 클까? 보안 요구가 비교적 낮은 개인 개발자·소규모 팀의 로컬 stdio 통합에서 효과가 가장 빠르게 드러난다. 기업 환경에서는 인증·감사 설계가 끝난 뒤 원격 SSE 서버로 단계적으로 확장하는 흐름이 안전하다.
정리 — MCP 프로토콜은 AI 운영 환경의 인프라가 되어가는 중
MCP는 더 이상 호기심의 영역이 아니다. Anthropic이 2024-11-25에 던진 표준안이 1년 반 만에 200개+ 서버·4개 공식 SDK·다수 호스트 채택으로 자리 잡았다. 표준 자체보다 중요한 것은 그 표준이 만들어내는 AI 운영 환경의 인프라 효과다. LLM이 닿을 수 있는 시스템 범위가 비용 없이 넓어진다는 점이다.
도입 단계는 환경에 따라 다르다. 일상 통합이 필요한 개인·소규모 팀이라면 Claude Desktop 또는 Claude Code의 MCP 설정에서 공식 한국어 docs의 기존 서버를 가져다 쓰는 것이 가장 빠른 시작이다. 한 단계 더 들어가 사내 시스템·내부 API를 AI 에이전트가 다루게 하고 싶다면, 공식 SDK로 커스텀 MCP 서버를 직접 만드는 단계에 들어선다.
남은 질문은 단순하다. 운영 환경 어디까지를 AI 에이전트가 직접 다루게 할 것인가? 다음 글에서는 코딩 영역에서 같은 질문을 던지는 ‘AI 코딩 에이전트 비교(Claude Code·Cursor·GitHub Copilot)’를 다룬다.