MCP가 정확히 뭐야

**Model Context Protocol의 약자로, 언어 모델이 바깥의 도구·파일·서비스에 접근하는 방식을 정해둔 개방형 표준**이다. 2024년에 처음 공개됐다. 구조는 세 조각으로 되어 있다 — 도구를 제공하는 **MCP 서버**, 모델 쪽에서 그 도구를 불러 쓰는 **MCP 클라이언트**, 그리고 둘이 주고받는 메시지 형식인 **프로토콜**이다. 여기서 자주 오해되는 지점이 있다. **MCP는 AI 모델이 아니고 제품도 아니다.** 규약일 뿐이라 그 자체로는 아무 일도 하지 않는다. 전기 콘센트 규격이 전기를 만들지 않는 것과 같다. 규격이 정해져 있으면 어느 회사가 만든 기기든 꽂힌다는 것이 요점이다.

왜 USB-C에 비유해

**연결의 가짓수를 곱셈에서 덧셈으로 바꾸기 때문이다.** MCP 이전에는 모델과 도구의 **조합마다** 연결 코드를 따로 만들어야 했다. 모델이 3종이고 붙이고 싶은 도구가 10개면 3 × 10 = **30개**의 연결을 각각 만들고 각각 유지보수해야 했다. 도구를 하나 더 추가하면 모델 수만큼 작업이 또 늘어난다. MCP는 양쪽이 같은 규약을 쓰게 만든다. 그러면 모델 쪽은 MCP 클라이언트를 한 번 구현하고, 도구 쪽은 MCP 서버를 한 번 구현한다 — 3 + 10 = **13개**로 끝난다. USB-C 이전에 기기마다 충전 단자가 달랐던 상황과, 하나로 통일된 이후를 비교하는 비유가 여기서 나온다. **어떤 도구든 규약만 맞으면 어떤 모델에든 꽂힌다.**

**모델 제공자와 개발 도구 양쪽에서 채택됐다.** 시점을 정리하면 이렇다 — **2025년 3월 26일** 오픈AI가 자사 에이전트 프레임워크에 MCP를 공식 채택했고, **2025년 4월 9일** 구글이 제미나이 에이전트 구조에 적용했다. 이 두 채택이 MCP를 사실상의 업계 표준 자리에 올려놨다. 개발 도구 쪽에서는 커서, 클라인 같은 AI 코딩 도구들이 쓰고 있다. 중요한 변화가 하나 더 있다 — **2025년 12월 앤스로픽이 오픈AI와 함께 리눅스 재단 산하에 에이전틱 AI 재단(AAIF)을 설립하고 MCP를 그쪽으로 이관**했다. 한 회사가 만든 표준이 그 회사 소유로 남아 있으면 경쟁사가 채택하기를 꺼린다. 중립 재단으로 옮긴 것은 그 문제를 푸는 통상적인 방법이다.

MCP 쓰면 AI가 내 파일을 마음대로 보는 거 아니야

**권한을 어떻게 설정하느냐의 문제이고, 이 부분이 MCP의 가장 실질적인 위험 영역이다.** MCP 서버는 자기가 제공할 도구와 접근 범위를 스스로 정의한다. 파일 시스템 서버라면 어느 디렉터리까지 열지, 읽기만 할지 쓰기도 할지를 설정한다. 즉 **모델이 볼 수 있는 범위는 서버가 허용한 범위까지**다. 문제는 그 설정을 사용자가 제대로 확인하지 않고 서버를 붙이는 경우다. 특히 출처가 불분명한 제3자 MCP 서버는 그 자체가 위험 요소가 된다 — 서버 코드가 무엇을 하는지 사용자가 보지 않기 때문이다. 관련 연구도 이 지점에 몰려 있다. 실무적으로는 **필요한 최소 범위만 여는 것**, **쓰기 권한은 따로 판단하는 것**, **출처가 확인되지 않은 서버는 붙이지 않는 것**이 기본이다.

테크 · 4분 · 에버그린

MCP란 — AI에게 도구를 연결하는 표준, 왜 USB-C에 비유되나

MCP, the Model Context Protocol, is an open standard introduced in 2024 that gives large language models a uniform way to reach external tools, files and services. Before it, every combination of model and tool needed its own custom integration, so adding one tool meant writing it again for every model. MCP replaces that with one protocol both sides speak. OpenAI adopted it for its agent framework in March 2025 and Google applied it to Gemini agent architecture in April 2025. In December 2025 it moved to the Agentic AI Foundation under the Linux Foundation, and the July 28, 2026 specification removed session state in favor of a stateless core

2026.08.28 06:00 출처 7건 대조

MCP는 Model Context Protocol의 약자로, 대형 언어 모델이 외부 도구와 파일과 서비스에 접근하는 방식을 통일한 개방형 표준이다. 2024년에 처음 나왔다. 이 표준이 없던 시절에는 모델과 도구의 조합마다 연결 코드를 따로 만들어야 했고, 도구 하나를 추가하려면 모델 수만큼 작업이 늘어났다. MCP는 양쪽이 같은 규약을 쓰게 해서 이 곱셈을 덧셈으로 바꾼다. 2025년 3월 오픈AI가 에이전트 프레임워크에 채택했고 4월에는 구글이 제미나이에 적용했다. 2025년 12월 리눅스 재단 산하 에이전틱 AI 재단으로 이관됐다

아침 햇살이 드는 밝은 책상 위에 가지런히 놓인 연결 케이블들과 작은 어댑터 허브, 옆의 초록 화분

3줄 요약

정의 — 언어 모델이 외부 도구·파일·서비스에 접근하는 방식을 통일한 개방형 표준
효과 — 모델 M개 × 도구 N개의 연결 작업이 M+N으로 줄어든다. USB-C 비유가 여기서 나온다
현황 — 오픈AI·구글이 채택. 2025년 12월 리눅스 재단 산하로 이관돼 중립성을 확보했다

핵심 질문

MCP가 정확히 뭐야: **Model Context Protocol의 약자로, 언어 모델이 바깥의 도구·파일·서비스에 접근하는 방식을 정해둔 개방형 표준**이다. 2024년에 처음 공개됐다. 구조는 세 조각으로 되어 있다 — 도구를 제공하는 **MCP 서버**, 모델 쪽에서 그 도구를 불러 쓰는 **MCP 클라이언트**, 그리고 둘이 주고받는 메시지 형식인 **프로토콜**이다. 여기서 자주 오해되는 지점이 있다. **MCP는 AI 모델이 아니고 제품도 아니다.** 규약일 뿐이라 그 자체로는 아무 일도 하지 않는다. 전기 콘센트 규격이 전기를 만들지 않는 것과 같다. 규격이 정해져 있으면 어느 회사가 만든 기기든 꽂힌다는 것이 요점이다.
왜 USB-C에 비유해: **연결의 가짓수를 곱셈에서 덧셈으로 바꾸기 때문이다.** MCP 이전에는 모델과 도구의 **조합마다** 연결 코드를 따로 만들어야 했다. 모델이 3종이고 붙이고 싶은 도구가 10개면 3 × 10 = **30개**의 연결을 각각 만들고 각각 유지보수해야 했다. 도구를 하나 더 추가하면 모델 수만큼 작업이 또 늘어난다. MCP는 양쪽이 같은 규약을 쓰게 만든다. 그러면 모델 쪽은 MCP 클라이언트를 한 번 구현하고, 도구 쪽은 MCP 서버를 한 번 구현한다 — 3 + 10 = **13개**로 끝난다. USB-C 이전에 기기마다 충전 단자가 달랐던 상황과, 하나로 통일된 이후를 비교하는 비유가 여기서 나온다. **어떤 도구든 규약만 맞으면 어떤 모델에든 꽂힌다.**
누가 쓰고 있어: **모델 제공자와 개발 도구 양쪽에서 채택됐다.** 시점을 정리하면 이렇다 — **2025년 3월 26일** 오픈AI가 자사 에이전트 프레임워크에 MCP를 공식 채택했고, **2025년 4월 9일** 구글이 제미나이 에이전트 구조에 적용했다. 이 두 채택이 MCP를 사실상의 업계 표준 자리에 올려놨다. 개발 도구 쪽에서는 커서, 클라인 같은 AI 코딩 도구들이 쓰고 있다. 중요한 변화가 하나 더 있다 — **2025년 12월 앤스로픽이 오픈AI와 함께 리눅스 재단 산하에 에이전틱 AI 재단(AAIF)을 설립하고 MCP를 그쪽으로 이관**했다. 한 회사가 만든 표준이 그 회사 소유로 남아 있으면 경쟁사가 채택하기를 꺼린다. 중립 재단으로 옮긴 것은 그 문제를 푸는 통상적인 방법이다.
MCP 쓰면 AI가 내 파일을 마음대로 보는 거 아니야: **권한을 어떻게 설정하느냐의 문제이고, 이 부분이 MCP의 가장 실질적인 위험 영역이다.** MCP 서버는 자기가 제공할 도구와 접근 범위를 스스로 정의한다. 파일 시스템 서버라면 어느 디렉터리까지 열지, 읽기만 할지 쓰기도 할지를 설정한다. 즉 **모델이 볼 수 있는 범위는 서버가 허용한 범위까지**다. 문제는 그 설정을 사용자가 제대로 확인하지 않고 서버를 붙이는 경우다. 특히 출처가 불분명한 제3자 MCP 서버는 그 자체가 위험 요소가 된다 — 서버 코드가 무엇을 하는지 사용자가 보지 않기 때문이다. 관련 연구도 이 지점에 몰려 있다. 실무적으로는 **필요한 최소 범위만 여는 것**, **쓰기 권한은 따로 판단하는 것**, **출처가 확인되지 않은 서버는 붙이지 않는 것**이 기본이다.

MCP는 Model Context Protocol의 약자다.

언어 모델이 바깥의 도구·파일·서비스에 접근하는 방식을 정해둔 개방형 표준이고, 2024년에 처음 나왔다.

먼저 아닌 것부터 정리하면 이해가 빠르다. MCP는 AI 모델이 아니고 제품도 아니다. 규약일 뿐이라 그 자체로는 아무 일도 하지 않는다.

1. 구조 — 세 조각

조각	역할
MCP 서버	도구를 제공한다 (파일 접근, 검색, 데이터베이스 조회 등)
MCP 클라이언트	모델 쪽에서 그 도구를 불러 쓴다
프로토콜	둘이 주고받는 메시지 형식

전기 콘센트 규격이 전기를 만들지 않는 것과 같다. 규격이 정해져 있으면 어느 회사가 만든 기기든 꽂힌다는 것이 요점이다.

2. USB-C 비유가 나오는 이유 — 곱셈이 덧셈이 된다

MCP 이전에는 모델과 도구의 조합마다 연결 코드를 따로 만들어야 했다.

	MCP 이전	MCP 이후
모델 3종 × 도구 10개	30개 연결	13개 구현 (3 + 10)
도구 1개 추가	모델 수만큼(+3) 작업	1개
모델 1종 추가	도구 수만큼(+10) 작업	1개

모델 쪽은 MCP 클라이언트를 한 번 구현하고, 도구 쪽은 MCP 서버를 한 번 구현한다. 그 뒤로는 서로를 몰라도 붙는다.

USB-C 이전에 기기마다 충전 단자가 달랐던 상황과 통일된 이후를 비교하는 비유가 여기서 나온다.

차이가 큰 것은 유지보수 쪽이다. 30개의 개별 연결은 모델이 업데이트될 때마다 30번 점검해야 한다. 13개는 13번이면 된다.

3. 어디까지 채택됐나

시점	무슨 일
2024년	MCP 최초 공개
2025년 3월 26일	오픈AI, 에이전트 프레임워크에 공식 채택
2025년 4월 9일	구글, 제미나이 에이전트 구조에 적용
2025년 12월	리눅스 재단 산하 에이전틱 AI 재단(AAIF)으로 이관
2026년 7월 28일	사양 개정 — 상태 비저장 코어 도입

2025년 3~4월의 두 채택이 결정적이었다. 경쟁 관계인 회사들이 같은 규약을 쓰기 시작하면 그 규약은 사실상 표준이 된다.

개발 도구 쪽에서는 커서, 클라인 같은 AI 코딩 도구들이 채택했다.

4. 재단으로 옮긴 이유

2025년 12월, 앤스로픽이 오픈AI와 함께 리눅스 재단 산하에 에이전틱 AI 재단(AAIF)을 세우고 MCP를 그쪽으로 이관했다.

이유는 표준의 오래된 문제다.

상태	문제
한 회사 소유	경쟁사가 채택을 꺼린다. 규약이 언제 그 회사에 유리하게 바뀔지 모른다
중립 재단 소유	누구도 혼자 바꿀 수 없다. 채택 부담이 사라진다

중립 재단으로 옮기는 것은 이 문제를 푸는 통상적인 방법이다. 표준을 만든 쪽이 소유권을 내려놓는 대신 채택 범위를 얻는 거래다.

5. 2026년 7월 사양 — 상태를 버렸다

2026년 7월 28일 사양 개정의 핵심은 세션 상태 제거다.

	이전	개정 이후
연결	세션 상태를 유지	상태 비저장 코어
확장	같은 서버로 계속 붙어야 함	수평 확장 가능
라우팅	별도 처리 필요	HTTP 표준 라우팅 사용

상태를 들고 있으면 같은 서버로 계속 붙어야 한다. 상태를 버리면 요청을 아무 서버로나 보낼 수 있고, 서버를 늘리는 것만으로 처리량이 늘어난다.

개인 개발자용 도구에서 대규모 서비스 인프라로 넘어가기 위한 변경이라고 읽으면 정확하다.

6. 위험은 어디에 있나

MCP의 가장 실질적인 위험은 성능이 아니라 권한이다.

MCP 서버는 자기가 제공할 도구와 접근 범위를 스스로 정의한다. 파일 시스템 서버라면 어느 디렉터리까지 열지, 읽기만 할지 쓰기도 할지를 설정한다.

즉 모델이 볼 수 있는 범위는 서버가 허용한 범위까지다.

문제는 그 설정을 확인하지 않고 서버를 붙이는 경우다.

위험	내용
출처 불명 서버	서버 코드가 무엇을 하는지 사용자가 보지 않는다
과도한 권한	편의를 위해 넓게 열어두고 잊는다
쓰기 권한	읽기와 달리 되돌릴 수 없는 동작이 가능해진다

실무 원칙은 셋이다.

필요한 최소 범위만 연다
쓰기 권한은 읽기와 따로 판단한다
출처가 확인되지 않은 서버는 붙이지 않는다

이 주제는 학계에서도 다뤄지고 있다. 오픈소스 MCP 서버의 위험을 평가하는 프레임워크나 MCP 생태계의 데이터 흐름 위험을 다룬 연구들이 나와 있다.

7. 왜 지금 중요해졌나 — 에이전트 때문이다

챗봇에게는 도구가 크게 필요하지 않다. 질문에 답만 하면 된다.

에이전트는 다르다. 파일을 읽고, 코드를 실행하고, 외부 서비스를 호출해야 일이 된다. 이 지면은 「AI 에이전트란 — 도구를 쥐여주면 무엇이 달라지나」에서 그 차이를 다뤘다.

도구를 쥐여주는 것이 에이전트의 전제라면, 도구를 어떻게 쥐여줄 것인가가 곧바로 다음 문제가 된다. MCP가 답하려는 것이 그 질문이다.

8. 관련해서 이 지면이 다룬 것

「AI 에이전트란 — 도구를 쥐여주면 무엇이 달라지나」 — 에이전트와 챗봇의 차이
「클로드 코드란 — 챗봇에 물어보는 것과 뭐가 다른가」 — 도구를 쓰는 AI의 실제 동작
「오픈라우터란 — 400개 AI 모델을 열쇠 하나로 여는 중개소」 — 모델 쪽 표준화
「오픈소스 AI 모델이란 — 공개의 등급과 MoE 읽는 법」 — 개방의 등급

9. 확인하지 못한 것

채택 날짜 — 오픈AI 2025년 3월 26일, 구글 2025년 4월 9일은 위키형 자료 기준이며 각 사 공식 발표로 대조하지 못했다.
재단 이관 — AAIF 설립과 MCP 이관은 한 소스로만 확인했다. 정확한 명칭과 참여 기관을 원문으로 확인하지 못했다.
호환성 — 2026년 7월 28일 사양의 상태 비저장 전환이 기존 구현에 주는 영향을 확인하지 못했다.
생태계 규모 — 채택 도구 수나 공개된 MCP 서버 수를 확인하지 못했다.
보안 권고의 출처 — 본문의 원칙은 통용되는 내용이며 특정 기관 가이드라인을 인용한 것이 아니다.