MCP란 무엇일까요? AI 앱에 도구를 잇는 표준을 쉽게 풀어요

MCP(Model Context Protocol)란 AI 앱을 외부 시스템에 연결하기 위한 오픈소스 표준이에요. 공식 문서는 Claude나 ChatGPT 같은 AI 앱이 MCP로 로컬 파일과 데이터베이스, 검색 엔진과 계산기 같은 도구, 전용 프롬프트 같은 워크플로에 연결된다고 설명하고, 이것을 AI 앱의 USB-C 포트에 빗대요. 2026년 11월 2일 기준 현재 사양 버전은 2026-07-28이에요.

구조는 세 역할로 나뉘어요. 사람이 쓰는 AI 앱이 호스트이고, 데이터나 기능을 내주는 프로그램이 서버예요. 호스트는 연결하는 서버마다 클라이언트를 하나씩 만들어 따로 연결을 유지하고, 서버는 도구, 리소스, 프롬프트라는 세 가지 형태로 기능을 내놓아요. 공식 문서의 원격 서버 안내는 Claude의 커스텀 커넥터(Custom Connectors)를 Claude와 원격 MCP 서버를 잇는 다리라고 설명해요.

이 글은 2026년 11월 2일 오후 12시 48분부터 12시 51분(한국 시각) 사이에 받은 Model Context Protocol 공식 문서와 사양 페이지를 기준으로 썼어요. MCP 서버를 직접 설치하거나 앱에 연결해 보지는 않았고, 문서에 적힌 내용만 옮겼어요.

MCP란, 공식 문서의 정의부터

공식 소개 페이지의 첫 문장은 MCP를 "AI 애플리케이션을 외부 시스템에 연결하기 위한 오픈소스 표준"이라고 적어요. 이어서 AI 앱이 연결할 수 있는 대상을 세 묶음으로 나눠 예를 들었어요.

• 데이터 소스: 로컬 파일, 데이터베이스
• 도구: 검색 엔진, 계산기
• 워크플로: 전용 프롬프트

USB-C 비유도 이 페이지에 그대로 있어요. USB-C가 전자기기를 잇는 표준 방식을 주듯, MCP는 AI 앱을 외부 시스템에 잇는 표준 방식을 준다는 설명이에요. 앱마다 연결 방식을 따로 만들지 않고 한 가지 약속으로 맞춘다는 점이 핵심이에요.

페이지가 든 활용 예시는 네 가지예요. 에이전트가 구글 캘린더와 노션에 접근해 더 개인화된 비서처럼 움직이는 경우, Claude Code가 Figma 디자인으로 웹 앱 전체를 만드는 경우, 기업 챗봇이 조직 안의 여러 데이터베이스에 연결해 사용자가 채팅으로 데이터를 분석하는 경우, AI 모델이 Blender에서 3D 디자인을 만들고 3D 프린터로 출력하는 경우예요. 모두 문서가 든 예시이고, 이 글에서 직접 해 본 것은 아니에요.

누구에게 이로운지도 나눠 적었어요. 개발자에게는 AI 앱이나 에이전트를 만들거나 연동하는 시간과 복잡도를 줄여 주고, AI 앱에는 데이터 소스와 도구, 앱의 생태계를 열어 주며, 최종 사용자에게는 필요할 때 사용자 데이터에 접근하고 사용자를 대신해 행동하는 더 유능한 AI 앱을 준다는 설명이에요.

헷갈리기 쉬운 점도 하나 짚어 둘게요. 아키텍처 문서는 MCP가 맥락을 주고받는 프로토콜에만 집중하고, AI 앱이 언어 모델을 어떻게 쓰는지나 받은 맥락을 어떻게 다루는지는 정하지 않는다고 적었어요. 그러니 MCP는 AI 모델도, 특정 앱의 기능 이름도 아니에요. 앱과 외부 프로그램이 대화하는 약속이에요.

호스트, 클라이언트, 서버: 세 역할 구분하기

아키텍처 문서는 MCP가 클라이언트와 서버 구조를 따른다고 적어요. 세 역할의 정의를 표로 옮기면 이래요.

중요한 규칙은 하나예요. 호스트는 MCP 서버마다 MCP 클라이언트를 하나씩 만들고, 각 클라이언트는 자기 서버와 전용 연결을 유지해요. 사양의 아키텍처 문서도 클라이언트와 서버가 1:1 관계라고 적었어요.

문서가 든 예시는 Visual Studio Code예요. VS Code가 호스트가 되어 Sentry MCP 서버에 연결하면, VS Code 안에서 그 연결을 맡는 클라이언트 객체가 하나 생겨요. 이어서 로컬 파일 시스템 서버에 또 연결하면 클라이언트 객체가 하나 더 생겨요. 서버가 늘수록 클라이언트도 같은 수만큼 늘어나는 구조예요.

클라이언트 개념 문서는 이 구분을 한 줄로 정리했어요. 호스트는 사용자가 상호작용하는 애플리케이션이고, 클라이언트는 서버 연결을 가능하게 하는 프로토콜 수준의 구성 요소라는 설명이에요. 일반 사용자 입장에서는 클라이언트를 따로 볼 일이 거의 없고, 앱(호스트)과 연결한 서버만 보면 돼요.

사양의 아키텍처 문서에는 설계 원칙도 적혀 있어요. 그중 세 번째 원칙은 서버가 대화 전체를 읽거나 다른 서버 안을 들여다볼 수 없어야 한다는 것이에요. 서버는 필요한 맥락만 받고, 대화 기록 전체는 호스트에 남으며, 서버 사이의 상호작용은 호스트가 통제한다고 적었어요. 이것은 사양의 아키텍처 문서가 정한 설계 원칙이고, 각 앱이 이를 어떻게 구현하는지는 앱마다 다를 수 있어요.

로컬 서버와 원격 서버는 전송 방식으로 갈려요

MCP 서버라는 말 때문에 인터넷 어딘가의 서버만 떠올리기 쉬운데, 공식 문서는 MCP 서버가 실행 위치와 상관없이 맥락 데이터를 내주는 프로그램을 가리킨다고 적었어요. 로컬에서도, 원격에서도 돌 수 있어요.

둘을 가르는 건 전송 방식이에요. 아키텍처 문서는 MCP가 두 가지 전송 방식을 지원한다고 적었어요.

연결 수도 다르게 적혀 있어요. STDIO를 쓰는 로컬 서버는 보통 클라이언트 하나를 상대하고, Streamable HTTP를 쓰는 원격 서버는 보통 여러 클라이언트를 상대한다고 해요.

원격 쪽 인증도 문서에 한 줄 있어요. Streamable HTTP는 베어러 토큰, API 키, 사용자 지정 헤더 같은 표준 HTTP 인증 방법을 지원하고, MCP는 인증 토큰을 받는 방법으로 OAuth를 권장한다고 적었어요.

원격 서버 연결 안내는 차이를 사용자 입장에서 설명해요. 로컬 서버는 기기마다 설치와 설정이 필요하지만, 원격 서버는 인터넷에 연결된 어떤 MCP 클라이언트에서도 쓸 수 있다는 설명이에요. 이 안내는 Claude의 Custom Connectors를 예로 들면서, 같은 개념이 다른 MCP 호환 클라이언트에도 넓게 적용된다고 적었어요. 같은 안내는 커스텀 커넥터로 서드파티 개발자가 제공하는 원격 MCP 서버에 Claude를 연결하거나, 원격 MCP 서버를 직접 만들어 연결할 수 있다고 적었어요.

사양의 전송 방식 문서는 프로토콜의 의미는 모든 전송 방식에서 같다고 적었어요. 로컬이든 원격이든 주고받는 메시지의 뜻은 같고, 전달하는 길만 다르다는 뜻이에요. 표준 두 가지 말고 직접 만든 전송 방식을 구현하는 것도 가능하다고 해요.

서버가 내놓는 세 가지: 도구, 리소스, 프롬프트

공식 문서의 아키텍처 개요는 이것을 MCP에서 가장 중요한 개념이라고 불러요. 서버가 내놓을 수 있는 핵심 기능은 세 가지이고, 서버 개념 문서는 각각을 누가 통제하는지까지 표로 나눴어요.

통제 주체가 다르다는 점을 기억해 두면 앱 화면이 덜 낯설어요. 도구는 모델이 알아서 찾아 부르는 쪽이라, 서버 개념 문서는 앱이 쓸 수 있는 사용자 통제 방법으로 도구 목록 표시, 실행마다 승인 창, 안전한 작업의 사전 허용 설정, 실행 기록을 들어요. 프롬프트는 사용자가 직접 불러야 하는 쪽이라 슬래시 명령(빗금을 입력하면 목록이 뜨는 방식)이나 명령 팔레트, 전용 버튼으로 보여 주는 경우가 많다고 적었어요.

문서가 든 데이터베이스 예시도 이해에 도움이 돼요. 데이터베이스 맥락을 주는 MCP 서버라면 질의를 실행하는 도구, 데이터베이스 스키마를 담은 리소스, 도구 쓰는 법을 보여 주는 예시가 든 프롬프트를 함께 내놓을 수 있다는 설명이에요.

앱이 서버의 기능을 알아내는 방법도 정해져 있어요. 기능마다 목록을 받는 메서드(tools/list, resources/list, prompts/list)가 있고, 클라이언트는 먼저 목록을 받은 뒤 필요한 것을 써요. 도구는 tools/call로 실행하고, 리소스는 resources/read로 읽고, 프롬프트는 prompts/get으로 가져와요. 목록을 그때그때 받아 오는 구조라서 서버의 도구가 바뀌어도 앱이 따라갈 수 있어요.

서버 개념 문서가 꼽은 흔한 서버 예는 문서 접근용 파일 시스템 서버, 데이터 조회용 데이터베이스 서버, 코드 관리용 GitHub 서버, 팀 소통용 Slack 서버, 일정 관리용 캘린더 서버예요.

서버가 사용자에게 되묻는 기능도 있어요

반대 방향 기능도 있어요. 클라이언트 개념 문서는 서버가 작업 중에 사용자에게 필요한 정보를 요청하는 기능을 엘리시테이션(Elicitation)이라고 불러요. 여행 예약 서버가 예약을 마무리하려고 좌석 선호, 객실 종류, 연락처를 묻는 경우가 문서의 예시예요.

사용자는 요청받은 정보를 입력하거나, 이유를 달아 거절하거나, 작업 전체를 취소할 수 있다고 해요. 방식은 화면 안에서 입력하는 폼 방식과 외부 주소로 넘기는 URL 방식이 있어요. 클라이언트 개념 문서는 서버가 비밀번호, API 키, 액세스 토큰, 결제 정보 같은 민감한 정보를 폼 방식으로 요청하면 안 되고 URL 방식으로 넘겨야 한다고 적었어요. URL 방식에서는 클라이언트가 전체 주소를 보여 주고 명시적 동의를 받은 뒤에 열며, 주소를 자동으로 열지 않는다고 해요.

현재 사양에서 없어질 예정인 기능도 있어요. 2026-07-28 변경 사항 문서는 서버가 앱의 언어 모델에 답변 생성을 요청하는 샘플링(Sampling), 서버가 볼 폴더 범위를 알려 주는 루트(Roots), 로깅(Logging)을 폐기 예정(deprecated)으로 정했다고 적었어요. 이 기능들은 사양에 그대로 남아 있고 폐기 예정 기간에는 완전히 동작하지만, 새로 구현하는 쪽은 지원을 넣지 말라는 내용이에요. 폐기 예정 기능 목록은 가장 이른 삭제 시점을 2027-07-28 이후 처음 나오는 개정으로 적었고, 아직 삭제된 기능은 없다고 해요. 옛 자료에서 이 이름들을 보면 지금은 쓸 수 있지만 새 구현에는 권하지 않는 기능이라는 점을 함께 보세요.

사양 버전 2026-07-28, 날짜가 곧 버전이에요

MCP 버전은 숫자가 아니라 날짜예요. 버전 문서는 버전 식별자가 연-월-일 형식이고, 하위 호환이 깨지는 변경이 마지막으로 들어간 날짜를 뜻한다고 적었어요. 하위 호환을 지키는 수정은 버전 번호를 올리지 않는다고 해요.

2026년 11월 2일 오후 12시 48분에 연 이 문서는 현재(Current) 프로토콜 버전을 2026-07-28이라고 적었어요. 공식 문서의 버전 메뉴에는 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25, 2026-07-28 다섯 개가 있어요. 날짜 목록에서 가장 늦은 2026-07-28이 지금 작업 중인 초안(Draft)이 아니라 현재 버전이에요. 현재 버전은 쓸 준비가 된 버전이면서 하위 호환되는 변경을 계속 받을 수 있고, 지난 버전(Final)은 더 바뀌지 않는다고 해요.

2026-07-28 변경 사항 문서가 첫머리에 든 큰 변화는 MCP를 무상태로 바꾼 것이에요. 연결을 시작할 때 주고받던 초기화 절차를 없애고, 요청마다 프로토콜 버전과 클라이언트 기능 정보를 담게 했어요. 서버는 지원 버전과 기능을 알려 주는 server/discover를 반드시 구현해야 해요. 이 변경 사항 문서는 프로토콜을 구현하는 쪽, 곧 앱과 서버를 만드는 쪽의 요구 사항을 적은 문서예요. 내가 쓰는 앱이 어느 버전을 지원하는지는 앱마다 확인해야 하고, 이 글에서는 앱별로 확인하지 않았어요.

참고로 원격 연결에 쓰는 Streamable HTTP는 2025-03-26 개정에서 이전의 HTTP+SSE 전송 방식을 대체하며 들어왔다고 그 개정의 변경 사항 문서가 적고 있어요.

어떤 앱이 MCP를 지원하나요

소개 페이지는 MCP를 여러 클라이언트와 서버가 지원하는 열린 프로토콜이라고 소개하면서 이름을 들어 적었어요. AI 비서로는 Claude와 ChatGPT, 개발 도구로는 Visual Studio Code, Cursor, MCPJam을 들고 "그 밖의 많은 곳"이 지원한다고 덧붙였어요. 목록은 닫혀 있지 않아요. 이 글에서는 이 다섯 이름 말고 다른 앱의 지원 여부는 각 앱 문서를 열어 확인하지 않았어요.

아키텍처 문서는 호스트의 예로 Claude Code와 Claude Desktop을, 클라이언트 개념 문서는 Claude.ai나 IDE 같은 호스트 애플리케이션을 들었어요. 결국 일반 사용자가 MCP를 만나는 자리는 이런 앱의 설정 화면이에요. 앱이 MCP를 지원하면 서버를 붙여 기능을 넓히고, 어떤 서버를 붙일지는 사용자가 고르는 구조예요.

MCP 서버가 얼마나 빠르게 늘고 있는지 궁금하다면, npm에 올라온 MCP 패키지를 직접 세어 본 npm MCP 패키지 집계 글을 함께 보세요. 실제 서버 하나를 앱에 붙이는 과정이 궁금하다면 n8n MCP를 Claude Desktop에 연결하는 글이 예가 돼요.

연결하기 전에 볼 것: 사양이 적은 보안 원칙

사양 본문의 보안 절은 MCP가 임의의 데이터 접근과 코드 실행 경로를 통해 강력한 기능을 주는 만큼, 구현하는 모든 쪽이 보안과 신뢰 문제를 신중히 다뤄야 한다고 적었어요. 핵심 원칙은 세 가지예요.

1. 사용자 동의와 통제: 사용자는 모든 데이터 접근과 작업에 명시적으로 동의하고 이해해야 하며, 어떤 데이터를 공유하고 어떤 행동을 할지 통제권을 가져야 해요.
2. 데이터 프라이버시: 호스트는 사용자 데이터를 서버에 노출하기 전에 명시적 동의를 받아야 하고, 사용자 동의 없이 리소스 데이터를 다른 곳으로 보내면 안 돼요.
3. 도구 안전: 도구는 임의의 코드 실행에 해당하므로 조심해서 다뤄야 해요. 신뢰할 수 있는 서버에서 받은 것이 아니면 도구 동작 설명도 믿을 수 없는 것으로 봐야 하고, 호스트는 도구를 실행하기 전에 사용자의 명시적 동의를 받아야 해요.

같은 절은 MCP 자체가 이 원칙을 프로토콜 수준에서 강제할 수는 없다고도 적었어요. 대신 구현하는 쪽이 동의와 승인 흐름을 앱에 넣고, 보안 영향을 문서로 알리고, 접근 통제를 갖추도록 권고해요. 그러니 실제로 얼마나 안전한지는 MCP라는 이름이 아니라 쓰는 앱과 붙이는 서버에 달려 있어요. 서버를 붙일 때 각 도구가 무엇을 하는지 먼저 이해하라는 것도 사양의 문장이에요.

정리하며

MCP란 AI 앱을 파일, 데이터베이스, 검색, 업무 도구 같은 외부 시스템에 잇는 오픈소스 표준이에요. 사람이 쓰는 앱이 호스트, 기능을 내주는 프로그램이 서버이고, 호스트는 서버마다 클라이언트를 하나씩 만들어 연결해요. 서버는 모델이 부르는 도구, 앱이 읽는 리소스, 사용자가 고르는 프롬프트를 내놓고, 로컬 서버는 STDIO로, 원격 서버는 Streamable HTTP로 연결돼요.

2026년 11월 2일 기준 현재 사양 버전은 2026-07-28이고, 이 버전부터 샘플링, 루트, 로깅은 폐기 예정(deprecated) 상태예요(지금은 동작하지만 새 구현에는 권하지 않아요). 지원 앱 목록은 공식 문서가 다섯 곳의 이름을 들고 열어 둔 목록이라, 쓰는 앱이 어느 버전과 어떤 기능을 지원하는지는 그 앱의 문서에서 확인하는 게 정확해요. MCP를 처음 누가 만들었고 지금 누가 관리하는지는 이번에 연 공식 페이지에서 확인하지 않아 이 글에 적지 않았어요.

함께 보면 좋은 글

• npm에서 MCP 패키지를 세어 본 집계
• n8n MCP를 Claude Desktop에 연결해 워크플로 만드는 법