MCP란 무엇인가
AI에 도구를 연결하는 표준, 5분 만에 쉽게 이해하기
- MCP란 앤트로픽이 2024년 11월 공개한 오픈 표준으로, AI가 외부 도구·데이터에 접근하는 방식을 통일한다.
- MCP가 없던 시절에는 AI 도구마다 연동 코드를 따로 짜야 했다(이른바 M×N 문제).
- 호스트-클라이언트-서버 3단 구조로 동작하며, 핵심 기능은 도구·리소스·프롬프트 3가지다.
- 2026년 7월 28일 새 스펙이 확정되며 상태 비저장(stateless) 구조로 크게 바뀌었다.
- 코딩을 몰라도 이미 만들어진 MCP 서버를 연결해서 쓸 수 있다.
업무용 챗봇에 회사 데이터베이스를 연결하려는데, AI 도구마다 연동 방식이 제각각이라 매번 새로 개발해야 한다면 어떨까요.
이런 반복 작업을 없애기 위해 나온 표준이 바로 MCP입니다. MCP란 AI 모델이 외부 도구와 데이터에 접근하는 방법을 하나로 통일한 개방형 프로토콜입니다.
이 글에서는 MCP란 정확히 무엇인지, 왜 등장했는지, 실제로 어떻게 작동하는지를 예시와 함께 차근차근 풀어드립니다. 개발자가 아니어도 이해할 수 있게 비유부터 시작하겠습니다.
1. MCP란 무엇인가 — 정의와 등장 배경
MCP란 Model Context Protocol의 줄임말입니다. 우리말로는 ‘모델 문맥 프로토콜’ 정도로 옮길 수 있습니다.
2024년 11월, AI 기업 앤트로픽이 이 프로토콜을 오픈소스로 공개했습니다. 목적은 단순합니다. AI 모델이 파일, 데이터베이스, 웹 API 같은 외부 시스템과 대화할 때 쓰는 ‘공용어’를 만드는 것입니다.
MCP란 특정 회사만 쓰는 폐쇄적 기술이 아닙니다. 리눅스 재단 산하 오픈소스 프로젝트로 운영되며, 클로드뿐 아니라 다양한 AI 클라이언트와 IDE에서 채택하고 있습니다.
MCP를 처음 접한다면 “AI용 USB-C 포트”라고 생각하면 쉽습니다. USB-C 하나로 노트북에 마우스든 모니터든 다 꽂을 수 있듯, MCP란 AI가 어떤 도구든 같은 방식으로 꽂아 쓸 수 있게 해주는 표준 연결 규격입니다.
2. MCP가 필요한 이유 — 기존 방식의 한계
MCP 이전에도 AI에 외부 도구를 연결하는 방법은 있었습니다. 문제는 방식이 도구마다, 회사마다 달랐다는 점입니다.
슬랙 연동 코드를 짜고, 구글 드라이브 연동 코드를 또 따로 짜고, 사내 데이터베이스 연동은 또 다른 방식으로 짜야 했습니다. 개발자 입장에서는 AI 애플리케이션 N개와 도구 M개가 있으면 최악의 경우 N×M개의 연동 코드가 필요했습니다.
MCP란 이 문제를 표준화로 풀어냅니다. 도구를 만드는 쪽은 MCP 서버 하나만 만들면 되고, AI 애플리케이션을 만드는 쪽은 MCP 클라이언트 기능만 갖추면 됩니다. N×M이 N+M으로 줄어드는 셈입니다.
이걸 흔히 ‘M×N 문제’라고 부릅니다. AI 모델 M개, 외부 도구 N개가 있을 때 조합마다 개별 연동을 만들면 유지보수 비용이 기하급수적으로 늘어납니다. MCP란 이 조합 폭발을 표준 프로토콜 하나로 억제하는 장치입니다. 도구를 새로 하나 추가해도 기존 AI 애플리케이션들이 코드 수정 없이 바로 그 도구를 인식할 수 있습니다.
실무에서는 이런 장면으로 나타납니다. 개발 도구에 깃허브·데이터베이스·파일시스템 MCP 서버를 한 번씩만 연결해두면, 이후로는 새 프로젝트마다 반복 설정할 필요가 없습니다.
결과적으로 개발자는 매번 연동 코드를 새로 짜는 대신, 이미 존재하는 MCP 서버를 가져다 붙이기만 하면 됩니다.
3. MCP 작동 원리 — 호스트·클라이언트·서버 구조
MCP란 구조적으로 세 요소로 이뤄집니다. 호스트, 클라이언트, 서버입니다.
호스트는 사용자가 실제로 쓰는 AI 애플리케이션입니다. 클로드 데스크톱이나 AI 코딩 도구가 여기 해당합니다.
클라이언트는 호스트 안에서 서버 하나와 1대1로 연결을 관리하는 부분입니다. 서버가 여러 개면 클라이언트도 그만큼 여러 개 생깁니다.
서버는 실제 기능을 제공하는 쪽입니다. 파일시스템에 접근하거나, 깃허브 API를 호출하거나, 사내 데이터베이스를 조회하는 역할을 합니다.
통신은 JSON-RPC 2.0이라는 메시지 규격을 씁니다. 요청과 응답을 정해진 형식으로 주고받는다는 뜻입니다.
3-1. 로컬 연결과 원격 연결, 두 가지 통로
MCP는 상황에 따라 두 가지 통신 방식(트랜스포트)을 씁니다.
stdio 방식은 클라이언트가 서버 프로그램을 자기 컴퓨터에서 직접 실행시켜 표준 입출력으로 대화하는 방식입니다. 네트워크를 안 타서 빠르고 설정도 단순합니다. 로컬 파일 접근이나 데스크톱 도구 연동에 주로 씁니다.
스트리머블 HTTP 방식은 서버가 원격 웹 서비스로 떠 있고, 클라이언트가 HTTP로 접속하는 방식입니다. 여러 사용자가 하나의 서버를 공유하거나 팀 단위로 배포할 때 적합합니다. 예전에 쓰이던 HTTP+SSE 방식은 2025년 스펙부터 사실상 대체되었습니다.
두 방식을 고르는 기준은 간단합니다. “이 서버가 내 컴퓨터에서만 도는가, 아니면 여러 사람이 같이 쓰는가”입니다. 개인 노트북에서 파일이나 로컬 도구를 다룬다면 stdio, 팀 전체가 접속하는 사내 API 서버라면 스트리머블 HTTP를 선택하는 식입니다.
구조가 이렇게 나뉘어 있는 덕분에, 같은 서버 코드를 로컬 개발 단계에서는 stdio로 테스트하고 운영 단계에서는 원격 서비스로 그대로 옮겨 배포하는 것도 가능합니다.
4. MCP의 핵심 기능 3가지 — 도구·리소스·프롬프트
MCP 서버가 클라이언트에 제공하는 기능은 크게 세 가지로 나뉩니다. 이 세 가지가 MCP란 개념의 실제 알맹이입니다.
도구는 AI가 능동적으로 “실행”하는 함수입니다. 이름·설명·입력 형식(JSON Schema)이 정의돼 있어서, AI 모델이 상황에 맞는 도구를 스스로 골라 호출합니다.
리소스는 AI가 “읽는” 데이터입니다. 도구처럼 실행하는 게 아니라 파일이나 레코드처럼 URI로 식별되는 콘텐츠를 그대로 가져옵니다.
프롬프트는 서버 쪽에서 미리 짜둔 질문 틀입니다. 사용자가 매번 똑같은 지시문을 새로 쓰지 않아도 되게 해줍니다.
실무에서 가장 자주 쓰는 건 도구입니다. “이 파일을 읽어줘”처럼 리소스로 끝나는 요청보다 “이 파일을 고쳐서 저장해줘”처럼 실행이 필요한 요청이 많기 때문입니다. MCP 서버를 처음 고를 때는 어떤 도구 목록을 제공하는지부터 확인하는 게 실용적입니다.
여기에 더해 서버가 클라이언트(AI 모델)에게 거꾸로 요청할 수 있는 기능도 있었습니다. 샘플링·엘리시테이션·루트 같은 기능인데, 2026년 새 스펙에서 상당수가 축소·정리되었습니다. 자세한 내용은 이어지는 섹션에서 다룹니다.
5. MCP와 기존 함수 호출 방식 비교
“이거 그냥 함수 호출(Function Calling) 아닌가요?”라는 질문을 자주 받습니다. 비슷해 보이지만 해결하는 층위가 다릅니다.
함수 호출은 AI 모델이 “어떤 함수를 어떤 인자로 부를지” 결정하는 능력 자체를 가리킵니다. 반면 MCP란 그 함수(도구)를 서버가 어떻게 정의하고, 클라이언트가 어떻게 발견하고, 둘 사이에서 어떤 형식으로 데이터를 주고받는지를 정한 통신 표준입니다.
즉 함수 호출이 “AI의 능력”이라면, MCP는 “그 능력을 실제 도구에 연결하는 배관”에 가깝습니다.
MCP란 함수 호출을 대체하는 기술이 아닙니다. AI 모델의 함수 호출 능력은 그대로 필요하고, MCP는 그 위에서 도구를 표준화된 방식으로 공급하는 역할만 합니다. 둘을 경쟁 관계로 오해하면 설계가 꼬일 수 있습니다.
6. 2026년 MCP 스펙 업데이트, 뭐가 달라졌나
MCP는 2024년 11월 첫 공개 이후 2025년 3월, 6월, 11월 세 차례 개정을 거쳤고, 2026년 7월 28일에는 출시 이래 가장 큰 규모의 개정판이 확정됐습니다.
가장 큰 변화는 프로토콜이 ‘상태 비저장(stateless)’ 구조로 바뀐 것입니다. 예전에는 클라이언트와 서버가 세션을 유지해야 했는데, 이 때문에 서버를 여러 대로 늘려 운영하기가 까다로웠습니다.
새 스펙에서는 세션 유지 부담을 없애고, 일반적인 로드밸런서 뒤에서도 서버를 자유롭게 늘리고 줄일 수 있게 됐습니다.
이 외에도 장시간 걸리는 작업을 관리하는 ‘태스크’ 기능이 별도 확장 모듈로 분리됐고, 인증 방식이 OAuth·OpenID Connect 표준에 더 가깝게 강화됐습니다. 샘플링·루트·로깅 같은 일부 기능은 지원 종료(deprecated) 예고가 붙었습니다.
지원 종료 예고가 붙은 기능도 최소 12개월은 그대로 작동합니다. 당장 쓰던 MCP 서버가 멈추는 건 아니라는 뜻입니다. 다만 새로 서버를 만든다면 지원 종료 예정 기능은 처음부터 피하는 편이 낫습니다. SDK를 최신 버전으로 유지하고 있었다면 새 스펙으로의 전환도 크게 어렵지 않다고 개발팀은 설명합니다.
정리하면, MCP란 처음에는 로컬 도구 연결용 프로토콜로 출발했지만 지금은 원격·대규모 서비스까지 아우르는 방향으로 계속 진화하고 있습니다. 표준이 안정화될수록 사용자 입장에서는 신경 쓸 게 오히려 줄어듭니다.
AI 기업 앤트로픽이 2024년 11월 처음 공개했습니다. 현재는 리눅스 재단 산하 오픈소스 프로젝트로 운영되며 여러 기업과 개발자 커뮤니티가 함께 표준을 다듬고 있습니다.
직접 서버를 만들 때는 코딩이 필요하지만, 이미 만들어진 MCP 서버를 연결해 쓰는 것만이라면 코딩 없이도 가능합니다. 설정 파일에 서버 실행 명령어나 주소만 넣으면 됩니다.
공식 저장소와 각종 MCP 서버 디렉터리에서 파일시스템, 깃허브, 슬랙 등 다양한 서버를 찾을 수 있습니다. 필요하면 직접 만들어 배포할 수도 있습니다.
REST API는 각 서비스가 자기만의 규격으로 만드는 반면, MCP는 AI가 도구를 발견하고 호출하는 방식 자체를 표준화합니다. AI 입장에서 새 도구를 배우는 학습 비용이 크게 줄어듭니다.
아닙니다. 개방형 표준이라 다양한 AI 클라이언트와 개발 도구가 채택하고 있으며, 특정 회사 제품에 종속되지 않습니다.
📚 함께 보면 좋은 글
MCP 개념을 잡았다면 이제 직접 연결하고, 만들고, 자동화까지 이어가 보세요.
🔗 공식 자료
📖 출처
- Model Context Protocol 공식 홈페이지, modelcontextprotocol.io
- Model Context Protocol 공식 스펙 문서, 2025-11-25 및 2026-07-28 개정판
- Model Context Protocol Blog, “The 2026 MCP Roadmap”
- Model Context Protocol Blog, “The 2026-07-28 Specification”
- The Register, “Model Context Protocol prepares to break with its stateful past”
MCP란 AI가 외부 도구·데이터에 접근하는 방식을 표준화한 오픈 프로토콜입니다. 호스트-클라이언트-서버 구조로 동작하며, 도구를 매번 새로 연동할 필요 없이 서버 하나만 연결하면 여러 AI 애플리케이션에서 재사용할 수 있습니다.
