MCP와 AI 에이전트 시대의 애플리케이션 구조 변화
핵심 요약
MCP(Model Context Protocol)는 AI 애플리케이션이 외부 데이터 소스, 도구, 워크플로와 표준화된 방식으로 연결되도록 돕는 공개 프로토콜이다. Anthropic이 2024년 11월 25일 공개한 뒤, Claude, ChatGPT, GitHub Copilot 같은 AI 애플리케이션과 개발 도구 생태계에서 외부 시스템 연결을 설명하는 핵심 개념으로 자리 잡았다. 공식 문서는 MCP를 “AI 애플리케이션용 USB-C 포트”에 비유하지만, 이 비유는 MCP가 모든 것을 실행하는 운영체제라는 뜻이 아니라 연결 규격을 표준화한다는 뜻이다.
MCP의 핵심 구조는 Host, Client, Server로 나뉜다. Host는 사용자가 접하는 AI 애플리케이션이고, Host 내부의 MCP Client는 특정 MCP Server와 1:1 세션을 유지한다. Server는 Tools, Resources, Prompts를 외부에 노출한다. Tools는 모델이 호출할 수 있는 실행 기능이고, Resources는 모델에 제공되는 읽기 가능한 문맥이며, Prompts는 재사용 가능한 작업 템플릿이다.
MCP가 중요한 이유는 AI 에이전트의 병목이 모델 성능만이 아니라 연결, 권한, 승인, 검증, 감사 가능성으로 이동하고 있기 때문이다. 모델이 아무리 뛰어나도 파일, 데이터베이스, SaaS, 코드 저장소, 사내 API, 로컬 프로그램에 안전하게 접근하지 못하면 실제 업무 자동화는 제한된다. MCP는 이 연결 문제를 각 앱마다 따로 구현하는 방식에서 공통 프로토콜 기반의 생태계 문제로 바꾼다.
MCP가 앱 구조를 바꿀 수 있다는 주장은 MCP 단독의 효과가 아니라, MCP를 지원하는 Host와 Server 생태계, 권한 모델, 사용자 승인 UI, 에이전트 오케스트레이션, 조직 데이터 정비가 함께 성숙한다는 조건 위에서 성립한다. 따라서 MCP는 “AI 운영체제” 자체가 아니라, AI 중심 작업 환경을 가능하게 하는 연결 계층으로 이해하는 편이 정확하다.
문제의식
초기 LLM 애플리케이션은 주로 질문에 답하거나 문장을 생성하는 방식으로 사용되었다. 이때 AI의 품질은 대체로 언어 생성 능력, 추론 능력, 지식 범위, 답변의 자연스러움으로 평가되었다. 그러나 업무 환경에서 중요한 것은 단순 답변보다 외부 시스템과의 상호작용이다. 보고서를 작성하려면 문서를 읽어야 하고, 코드 리뷰를 하려면 저장소와 이슈 트래커를 조회해야 하며, 회의를 잡으려면 캘린더와 메일을 다뤄야 한다. 고객 대응을 자동화하려면 CRM, 티켓 시스템, 계약서, 내부 정책 문서가 연결되어야 한다.
이 지점에서 LLM의 기본 한계가 드러난다. 모델은 학습 파라미터만으로 최신 정보와 조직 내부 데이터를 자동으로 알지 못한다. 또한 모델 자체는 파일을 열거나 데이터베이스를 조회하거나 메일을 보내거나 프로그램을 실행하는 능력을 본질적으로 갖고 있지 않다. 이런 행동은 외부 도구와의 연결을 통해 이루어진다.
MCP는 바로 이 연결 문제를 다룬다. 기존에는 각 AI 애플리케이션이 각 도구와 별도로 통합되어야 했다. 메일, 캘린더, Slack, GitHub, Notion, 데이터베이스, 파일 시스템, 사내 API를 모두 연결하려면 도구마다 인증, 스키마, 호출 방식, 오류 처리, 권한 정책, 로깅 방식을 따로 구현해야 했다. Anthropic은 MCP 발표문에서 이 문제를 분절된 통합(fragmented integrations)의 문제로 제시했고, MCP가 단일 프로토콜을 통해 AI 시스템과 데이터 소스를 연결하려 한다고 설명했다.
따라서 MCP를 “새로운 API 호출 방식” 정도로만 이해하면 부족하다. MCP는 AI 애플리케이션이 외부 컨텍스트를 발견하고, 도구를 호출하고, 결과를 다시 모델의 작업 문맥에 반영하는 방식을 표준화하려는 시도다. 이 때문에 MCP는 AI 에이전트, 코딩 에이전트, 사내 지식 검색, 업무 자동화, SaaS 구조 변화, 보안 아키텍처와 직접 연결된다.
개념의 정의
MCP는 Model Context Protocol의 약자다. 공식 사양은 MCP를 LLM 애플리케이션과 외부 데이터 소스 및 도구 사이의 통합을 가능하게 하는 개방형 프로토콜로 설명한다. 이름을 구성하는 세 단어를 나누어 보면 개념이 더 분명해진다.
“Model”은 Claude, ChatGPT, GitHub Copilot 같은 AI 애플리케이션 내부에서 사용되는 LLM을 가리킨다. 다만 MCP 구조에서 모델 자체가 직접 모든 외부 서버와 통신한다고 보면 부정확하다. 실제 구조에서는 사용자가 접하는 Host 애플리케이션이 있고, Host 내부의 MCP Client가 특정 MCP Server와 통신하며, Server가 외부 시스템의 데이터와 기능을 MCP 규격으로 노출한다.
“Context”는 모델이 응답하거나 행동하기 위해 필요한 외부 정보와 실행 가능성을 포함한다. 파일 내용, 데이터베이스 스키마, 검색 결과, 코드 저장소 정보, 업무 지침, 재사용 가능한 프롬프트, 계산기나 브라우저 같은 도구가 모두 넓은 의미의 컨텍스트가 될 수 있다. MCP가 단순한 tool protocol이 아니라 Model Context Protocol인 이유가 여기에 있다.
“Protocol”은 특정 제품이나 앱이 아니라 통신 규칙을 뜻한다. MCP는 서버와 클라이언트가 어떤 메시지 형식으로 기능을 발견하고 호출할지, 어떤 세션 생명주기를 따를지, 어떤 capability를 협상할지, 어떤 transport를 사용할지, 어떤 보안 원칙을 적용할지를 규정한다.
공식 아키텍처를 기준으로 MCP의 구성요소는 다음과 같다.
| 구성요소 | 의미 |
|---|---|
| Host | 사용자가 실제로 접하는 AI 애플리케이션. 예: Claude Desktop, ChatGPT 기반 앱, IDE, GitHub Copilot, 사내 AI 도구. |
| MCP Client | Host 안에서 특정 MCP Server와 통신하는 연결 구성요소. 각 Client는 보통 하나의 Server와 1:1 세션을 유지한다. |
| MCP Server | 외부 데이터, 기능, 작업 템플릿을 MCP 형식으로 노출하는 서버. 로컬 프로세스일 수도 있고 원격 서비스일 수도 있다. |
| Tools | 모델이 호출할 수 있는 실행 기능. 예: DB 조회, API 호출, 계산, 파일 조작, 이슈 생성, 코드 실행. |
| Resources | 모델에 제공되는 읽기 가능한 데이터와 문맥. 예: 파일, 문서, 스키마, 프로젝트 정보. |
| Prompts | 서버가 제공하는 재사용 가능한 프롬프트 템플릿이나 워크플로 지침. |
| Transport | Client와 Server가 MCP 메시지를 주고받는 방식. 최신 표준 transport는 stdio와 Streamable HTTP이다. |
| Authorization | 사용자별 데이터나 제한된 서버에 접근할 때 필요한 인증·인가 흐름. |
이 구조를 간단히 표현하면 다음과 같다.
사용자
↓
AI Host 애플리케이션
↓
MCP Client
↓
MCP Server
↓
외부 시스템: 파일, DB, API, SaaS, 코드 저장소, 검색, 로컬 프로그램
중요한 점은 Host와 Client를 분리해서 이해해야 한다는 것이다. Host는 사용자 승인, UI 표시, 보안 정책, 여러 Client 관리, 모델과의 통합을 담당한다. Client는 특정 Server와의 프로토콜 통신을 담당한다. Server는 Tools, Resources, Prompts를 제공한다. 이 분리는 MCP가 단순히 “모델이 서버에 직접 명령한다”는 구조가 아니라, 보안 경계를 가진 애플리케이션 아키텍처라는 점을 보여준다.
배경과 맥락
MCP 이전에도 LLM과 외부 도구를 연결하려는 여러 방식이 있었다. 대표적인 방식은 function calling, plugins, custom connectors, RAG(Retrieval-Augmented Generation), 사내 API wrapper였다. 이 방식들은 모두 유용하지만 각자 한계를 갖는다.
Function calling은 모델이 개발자가 정의한 함수 이름, 설명, 파라미터 스키마를 보고 함수를 호출하도록 하는 기능이다. 이 방식은 한 애플리케이션 내부에서 모델과 백엔드 기능을 연결할 때 매우 유용하다. 그러나 특정 모델 API나 특정 애플리케이션의 함수 정의 방식에 묶이기 쉽다.
RAG는 외부 문서나 데이터베이스에서 관련 정보를 검색해 모델 입력에 넣는 방식이다. 최신 정보와 조직 내부 지식 문제를 완화하는 데 효과적이지만, 보통 읽기 중심이며 실행 가능한 업무 흐름 전체를 표준화하지는 않는다.
Plugins와 connectors는 특정 앱이나 서비스와 AI를 연결하는 제품 수준의 통합이다. 사용자 경험은 좋을 수 있지만, 플랫폼마다 규격이 다르고 동일한 도구를 여러 AI 애플리케이션에서 재사용하기 어렵다.
MCP는 이 문제를 공통 프로토콜 문제로 재정의한다. 도구 제공자는 MCP Server를 만들고, AI 애플리케이션은 MCP Client를 구현한다. 양쪽이 같은 규격을 따르면 하나의 Server가 여러 MCP 지원 Host에서 재사용될 수 있다. 물론 현실에서는 각 Host의 지원 수준, transport, 인증 방식, 승인 UI, 모델의 도구 선택 능력에 따라 호환성이 달라진다. 그래도 MCP의 방향은 분명하다. N개의 AI 앱과 M개의 외부 도구 사이에서 발생하는 반복 통합 비용을 공통 프로토콜 기반 생태계로 줄이는 것이다.
MCP의 기본 작동 방식
MCP의 작동은 보통 다음 단계로 이루어진다.
첫째, Host가 MCP Server와 연결한다. 로컬 서버라면 Host가 서버 프로세스를 실행하고 stdio를 통해 메시지를 주고받을 수 있다. 원격 서버라면 Streamable HTTP를 통해 연결할 수 있다. 일부 플랫폼은 구버전 HTTP/SSE 서버도 호환 목적으로 지원할 수 있다.
둘째, Client와 Server가 초기화와 capability negotiation을 수행한다. MCP는 JSON-RPC 2.0 기반 메시지를 사용하고, 연결 초기 단계에서 지원하는 기능을 협상한다. Server는 자신이 Resources, Tools, Prompts 같은 기능을 제공할 수 있음을 선언하고, Client도 자신이 지원하는 기능을 선언한다.
셋째, Client가 Server의 기능을 조회한다. 예를 들어 tools/list 요청을 통해 사용 가능한 도구 목록과 스키마를 가져올 수 있다. Server가 제공하는 도구는 이름, 설명, input schema, output schema, 실행 관련 metadata 등을 포함할 수 있다.
넷째, Host는 사용자의 요청과 사용 가능한 도구 정보를 모델에 제공한다. 모델은 사용자의 목표를 해석하고 필요한 도구 호출을 제안하거나 선택한다. 이때 Host는 정책적으로 일부 도구만 노출하거나, 위험한 도구는 승인 대상으로 설정할 수 있다.
다섯째, Client가 Server에 도구 호출을 보낸다. Server는 실제 외부 시스템과 상호작용한다. 예를 들어 GitHub API를 호출하거나, 데이터베이스를 조회하거나, 로컬 파일을 읽거나, 계산을 수행한다.
여섯째, Server의 결과가 Client와 Host를 거쳐 모델의 컨텍스트로 돌아온다. 모델은 결과를 해석해 사용자에게 답변하거나, 다음 도구 호출을 이어가거나, 사용자에게 승인을 요청할 수 있다.
흐름은 다음과 같이 정리할 수 있다.
사용자 요청
↓
Host가 요청을 모델과 MCP 계층에 전달
↓
Client가 Server의 Tools/Resources/Prompts를 발견
↓
모델이 필요한 도구와 문맥을 판단
↓
Host 정책과 사용자 승인 조건 확인
↓
Client가 Server에 도구 호출 또는 리소스 요청
↓
Server가 외부 시스템과 상호작용
↓
결과가 모델 컨텍스트로 반환
↓
모델이 응답·추가 호출·승인 요청·작업 종료 중 하나를 수행
이 구조에서 핵심은 “도구 호출” 자체보다 “발견 가능한 기능 표면”이다. Server는 자신이 무엇을 할 수 있는지 명시적으로 노출하고, Host는 그것을 모델과 사용자에게 안전한 방식으로 보여준다. 이 때문에 tool description, input schema, output schema, 권한 범위, 승인 정책의 품질이 시스템 전체의 품질을 좌우한다.
Tools, Resources, Prompts의 구분
MCP는 외부 시스템 연결을 Tools, Resources, Prompts라는 세 축으로 정리한다. 이 구분은 단순한 명칭 차이가 아니라 위험도와 사용 방식의 차이를 의미한다.
Tools는 실행 가능한 기능이다. 데이터베이스 조회, API 호출, 계산, 파일 생성, 이슈 생성, 메시지 전송, 코드 실행, 배포 트리거 같은 기능이 여기에 속한다. Tools는 모델이 외부 세계에 변화를 만들 수 있는 통로가 될 수 있으므로 가장 높은 보안 검토가 필요하다. 읽기 도구와 쓰기 도구를 구분하고, 위험한 작업에는 사용자 승인을 요구해야 한다.
Resources는 읽을 수 있는 데이터다. 파일 내용, 문서 목록, 데이터베이스 스키마, 프로젝트 메타데이터, 코드 구조, 검색 결과 등이 여기에 속한다. Resources는 모델의 사실성과 최신성을 높이는 데 중요하다. 그러나 읽기 전용 자원이라도 개인정보, 영업기밀, 보안 정보가 포함될 수 있으므로 접근 범위와 로그 관리가 필요하다.
Prompts는 재사용 가능한 작업 템플릿이다. 서버는 특정 업무 절차, 코드 리뷰 방식, 문서 요약 방식, 데이터 분석 절차, 사내 정책 해석 양식 같은 프롬프트를 제공할 수 있다. Prompts는 모델에게 “어떤 방식으로 일해야 하는가”를 안내한다. 따라서 Prompts도 신뢰할 수 있는 출처에서 제공되어야 하며, 악성 지침이나 낡은 운영 규칙이 섞이지 않도록 관리해야 한다.
세 요소의 차이를 간단히 정리하면 다음과 같다.
| 요소 | 핵심 기능 | 예시 | 주요 위험 |
|---|---|---|---|
| Tools | 실행 | DB 조회, 파일 수정, 메일 발송, API 호출 | 권한 오남용, 잘못된 실행, 데이터 변경 |
| Resources | 문맥 제공 | 문서, 파일, 스키마, 검색 결과 | 민감 정보 노출, 오래된 데이터 사용 |
| Prompts | 절차 제공 | 리뷰 템플릿, 요약 양식, 업무 워크플로 | 악성 지침, 편향된 절차, 낡은 규칙 |
MCP를 안전하게 설계한다는 것은 이 세 요소를 모두 구분해 다루는 것이다. 모든 것을 “도구”라고 부르면 읽기·쓰기·지침·문맥의 위험 차이가 흐려진다.
Transport: stdio, Streamable HTTP, HTTP/SSE의 정확한 위치
초안에서 수정이 필요한 중요한 지점은 transport 설명이다. 최신 2025-11-25 MCP 사양 기준에서 표준 transport는 stdio와 Streamable HTTP로 정리하는 편이 정확하다. HTTP+SSE는 2024-11-05 프로토콜 버전의 transport였고, 최신 사양에서는 Streamable HTTP가 이를 대체한다. 다만 backward compatibility와 일부 플랫폼의 호환 지원 맥락에서는 HTTP/SSE가 여전히 언급될 수 있다.
stdio transport는 로컬 프로세스 연결에 적합하다. Host가 MCP Server를 subprocess로 실행하고, 서버는 stdin으로 JSON-RPC 메시지를 읽고 stdout으로 응답한다. 로컬 개발 도구, Claude Desktop의 로컬 서버, IDE 확장, 개인 자동화 도구에서 쓰기 쉽다. 네트워크 노출이 없다는 장점이 있지만, 로컬 파일과 명령 실행 권한을 다룰 수 있으므로 서버 신뢰성이 중요하다.
Streamable HTTP는 원격 또는 독립 실행 서버에 적합하다. 서버는 HTTP POST와 GET을 사용하고, 필요할 경우 SSE를 활용해 여러 서버 메시지를 스트리밍할 수 있다. 최신 사양에서는 단일 MCP endpoint가 POST와 GET을 지원하는 구조를 제시한다. 원격 MCP 서버, SaaS 연동, 조직 공용 서버, 여러 클라이언트 연결이 필요한 경우 이 방식이 중요하다.
HTTP+SSE는 이전 transport이다. 최신 문서에서는 Streamable HTTP가 HTTP+SSE를 대체한다고 설명한다. 그러나 구버전 서버와 클라이언트 호환을 위해 일부 구현이나 플랫폼 문서에서는 HTTP/SSE 지원을 계속 언급할 수 있다. 예를 들어 OpenAI 문서는 remote MCP server 사용에서 Streamable HTTP와 HTTP/SSE transport를 모두 지원한다고 설명한다. 이 경우 “OpenAI가 HTTP/SSE를 현재도 호환 지원한다”는 말과 “최신 MCP 표준 transport는 stdio와 Streamable HTTP이다”라는 말은 충돌하지 않는다. 하나는 플랫폼 호환성 설명이고, 다른 하나는 최신 MCP 사양 기준 설명이다.
정리하면 다음과 같다.
최신 MCP 표준 transport:
- stdio
- Streamable HTTP
구버전 또는 호환 맥락:
- HTTP+SSE
주의:
- 일부 플랫폼은 구버전 서버 호환을 위해 HTTP/SSE를 지원할 수 있다.
- 새 구현에서는 Streamable HTTP 또는 stdio를 우선 고려하는 편이 안전하다.
MCP와 function calling의 차이
MCP와 function calling은 모두 모델이 외부 기능을 사용할 수 있게 한다. 그러나 둘은 층위가 다르다.
Function calling은 보통 특정 모델 API 안에서 함수 이름, 설명, 파라미터 스키마를 정의하고 모델이 해당 함수를 호출하도록 하는 기능이다. 개발자는 애플리케이션 내부 함수나 백엔드 API를 모델이 호출할 수 있는 형태로 노출한다. 이 방식은 단일 앱 안에서 모델과 기능을 연결하는 데 효율적이다.
MCP는 외부 시스템이 AI 애플리케이션에 Tools, Resources, Prompts를 표준 방식으로 노출하는 프로토콜이다. MCP Server는 독립적으로 존재할 수 있고, 여러 Host가 해당 서버를 사용할 수 있다. 즉 function calling은 보통 “모델 API 내부의 호출 기능”에 가깝고, MCP는 “외부 도구와 데이터 소스를 AI 애플리케이션에 연결하는 표준 프로토콜”에 가깝다.
둘은 경쟁 관계라기보다 결합될 수 있다. OpenAI의 Responses API는 built-in tools, custom functions, connectors, remote MCP servers를 하나의 agentic interface 안에서 다룬다. 이때 remote MCP server는 OpenAI API가 접근하는 외부 MCP 구현 서버이고, 모델은 해당 서버의 tool definitions를 바탕으로 호출 여부를 결정한다.
| 구분 | Function calling | MCP |
|---|---|---|
| 기본 성격 | 모델 API의 도구 호출 기능 | AI 애플리케이션과 외부 시스템 사이의 연결 프로토콜 |
| 주된 범위 | 특정 앱 내부 함수 호출 | 여러 Host와 Server 간 상호운용성 |
| 정의 주체 | 애플리케이션 개발자 | MCP Server 제공자와 Host/Client 구현자 |
| 재사용성 | 특정 API나 앱에 묶이기 쉬움 | MCP 지원 Host 간 재사용 가능성 높음 |
| 구성요소 | 함수 이름, 설명, 파라미터 스키마 | Tools, Resources, Prompts, lifecycle, transport, authorization, utilities |
| 위험 관리 | 앱 개발자가 자체 구현 | Host 정책, Server 권한, 사용자 승인, authorization 흐름과 결합 |
따라서 MCP는 function calling을 없애는 기술이라기보다, 도구 호출의 외부 생태계를 표준화하는 기술로 보는 편이 더 정확하다.
MCP가 AI 에이전트 시대에서 중요한 이유
AI 에이전트를 “스스로 생각하는 존재”로만 이해하면 논의가 불필요하게 모호해진다. 시스템 관점에서 에이전트는 다음 요소의 결합으로 볼 수 있다.
에이전트 = 모델 + 상태 + 도구 호출 + 실행 루프 + 권한 통제 + 검증 + 사용자 승인
이 정의에서 모델은 핵심이지만 전부가 아니다. 실제 업무 자동화에서는 외부 시스템 접근, 장기 상태 관리, 권한 설계, 실패 복구, 비용과 지연 시간 관리, 로그와 감사 가능성이 모델 성능만큼 중요하다. MCP는 이 중 외부 컨텍스트와 도구 연결 계층을 담당한다.
MCP가 중요한 첫 번째 이유는 연결 비용을 줄이기 때문이다. 에이전트가 업무를 수행하려면 문서, 데이터베이스, SaaS, 로컬 파일, 코드 저장소, 브라우저, 사내 API에 접근해야 한다. MCP는 이 접근을 개별 커스텀 연결에서 공통 프로토콜 기반 연결로 바꾸려 한다.
두 번째 이유는 도구 발견과 실행을 표준화하기 때문이다. 에이전트는 단순히 하나의 함수를 호출하는 것이 아니라, 지금 어떤 도구가 필요한지 판단해야 한다. MCP Server가 자신의 도구 목록과 스키마를 명시적으로 제공하면 Host는 이를 모델에 제공하거나 정책적으로 제한할 수 있다.
세 번째 이유는 최신성과 조직 내부 데이터 문제를 완화하기 때문이다. LLM은 학습 시점 이후의 최신 정보나 회사 내부 데이터를 자동으로 알 수 없다. MCP Server가 파일, 문서, DB, 검색 결과를 Resources로 제공하면 모델은 필요할 때 조회하고 답할 수 있다. 이는 “모델이 모든 것을 기억해야 한다”에서 “모델이 필요한 것을 안전하게 조회한다”로 구조를 바꾼다.
네 번째 이유는 장기 작업과 실행 관리의 기반을 제공하기 때문이다. MCP 사양은 progress, cancellation, completion 같은 유틸리티를 포함하고, 2025-11-25 사양에서는 durable request tracking과 deferred result retrieval을 위한 tasks가 experimental 기능으로 추가되었다. 이 점은 MCP가 단순한 동기 함수 호출을 넘어 장시간 실행되는 작업 흐름을 고려하고 있음을 보여준다. 다만 tasks는 experimental 기능이므로 안정된 필수 기능처럼 단정해서는 안 된다.
“AI 운영체제” 비유의 의미와 한계
초안의 “MCP 기반 AI 운영체제”라는 표현은 직관적으로 유용하다. 사용자는 여러 앱을 직접 열고 조작하는 대신 AI에게 목표를 말하고, AI가 여러 시스템을 호출해 작업을 수행하는 구조를 상상할 수 있기 때문이다. 그러나 이 표현은 비유로 제한해야 한다.
MCP는 운영체제가 아니다. MCP는 프로세스 스케줄러, 메모리 관리자, 파일 시스템, 장치 드라이버, 보안 커널을 제공하지 않는다. 또한 “MCP 기반 AI OS”가 공식 제품 범주나 확정된 산업 표준이라고 말하기도 어렵다. MCP는 AI 애플리케이션이 외부 시스템과 통신하는 프로토콜이다.
그럼에도 OS 비유가 생기는 이유는 있다. 전통적인 운영체제는 하드웨어와 애플리케이션 사이에서 공통 인터페이스를 제공한다. 장치 드라이버는 다양한 하드웨어를 OS가 사용할 수 있는 형태로 연결한다. MCP도 다양한 외부 시스템을 AI 애플리케이션이 사용할 수 있는 형태로 노출한다. 이 점에서 MCP는 AI 중심 작업 환경의 “운영체제 전체”라기보다 “드라이버 계층” 또는 “연결 표면”에 가깝다.
더 정확한 비유는 다음과 같다.
전통 컴퓨팅
사용자 → OS → 앱 → 파일/네트워크/장치
AI 중심 작업 환경
사용자 → AI Host/Agent → MCP Client → MCP Server → 앱/API/DB/파일/워크플로
이 구조에서 AI는 사용자의 목표를 해석하고 여러 도구를 조합하는 상위 인터페이스가 될 수 있다. MCP는 그 AI가 외부 시스템과 연결되는 통신 계층이다. 오케스트레이터는 작업을 분해하고 실행 순서를 관리한다. 메모리 계층은 대화와 작업 상태를 보존한다. 권한 계층은 무엇을 읽고 실행할 수 있는지 제한한다. 승인 UI는 위험한 행동을 사람이 검토하게 한다.
따라서 “AI 운영체제”라는 말은 다음 문장으로 제한하는 편이 안전하다.
MCP 기반 AI 운영체제란 정식 OS 명칭이 아니라, AI가 사용자의 목표를 받아 여러 앱과 데이터 소스를 조율하는 상위 작업 환경을 설명하는 비유적 표현이다. 이 구조에서 MCP는 운영체제 전체가 아니라 외부 도구와 데이터에 대한 표준 연결 계층에 해당한다.
AI 앱 구조는 어떻게 바뀌는가
전통적인 소프트웨어 구조에서는 사용자가 앱을 직접 연다. 문서를 쓰려면 문서 앱을 열고, 메시지를 보내려면 메신저를 열고, 일정을 잡으려면 캘린더를 열고, 코드를 확인하려면 IDE와 GitHub를 연다. AI는 이런 앱 안에 “요약”, “초안 작성”, “검색 보조” 같은 부가기능으로 들어가는 경우가 많았다.
MCP와 에이전트형 API가 확산되면 일부 작업 구조는 바뀔 수 있다. 사용자는 특정 앱을 먼저 여는 대신 목표를 말한다. 예를 들어 “이번 주 프로젝트 상태 보고서를 작성해서 팀 채널에 공유해줘”라고 하면, AI는 GitHub, Jira, Slack, 문서 저장소, 캘린더, 이메일을 순차적으로 조회하고 보고서 초안을 만든 뒤 사용자에게 승인 요청을 할 수 있다.
이 변화는 MCP 단독으로 자동 발생하지 않는다. 다음 조건이 함께 필요하다.
| 조건 | 설명 |
|---|---|
| Host 지원 | Claude, ChatGPT, IDE, Copilot 같은 Host가 MCP를 안정적으로 지원해야 한다. |
| Server 생태계 | 실제 업무에 필요한 SaaS와 사내 시스템이 신뢰 가능한 MCP Server를 제공해야 한다. |
| 권한 모델 | 읽기·쓰기 권한, 사용자별 scope, 조직 정책이 명확해야 한다. |
| 승인 UI | 위험한 작업을 사람이 검토하고 승인할 수 있어야 한다. |
| 오케스트레이션 | 모델이 여러 도구를 순서대로 사용하고 실패를 복구할 수 있어야 한다. |
| 데이터 정비 | 조직 문서, DB, API, 정책이 AI가 활용 가능한 형태로 정리되어야 한다. |
| 보안 정책 | prompt injection, tool poisoning, SSRF, token handling, session risk를 관리해야 한다. |
따라서 “MCP가 앱 구조를 바꾼다”는 말은 “MCP만 설치하면 앱 구조가 자동으로 바뀐다”는 뜻이 아니다. 더 정확한 표현은 다음과 같다.
MCP는 AI가 여러 앱과 시스템을 조율하는 구조를 가능하게 하는 표준 연결 계층이며, 이 구조 변화는 MCP Server 생태계, Host 지원, 권한·승인 체계, 오케스트레이션 기술, 조직 데이터 정비가 함께 갖춰질 때 현실화된다.
미래형 AI 앱 구조를 계층으로 표현하면 다음과 같다.
1층. 사용자 인터페이스
- 채팅
- 음성
- 대시보드
- IDE 또는 업무 앱 안의 AI 패널
- 승인·검토 UI
2층. 에이전트 오케스트레이션
- 목표 해석
- 작업 분해
- 도구 선택
- 실행 순서 관리
- 실패 복구
- 비용·지연 시간 최적화
3층. 컨텍스트와 메모리
- 대화 상태
- 작업 상태
- 검색된 문서
- 사용자 선호
- 프로젝트 메타데이터
- 압축·요약·캐시
4층. 연결 프로토콜과 도구 호출
- MCP
- function calling
- built-in tools
- connectors
- 인증·인가
5층. 실행 대상
- SaaS
- 데이터베이스
- 파일 시스템
- 코드 저장소
- 브라우저
- 사내 API
- 로컬 프로그램
이 구조에서 MCP는 4층의 핵심 후보 중 하나다. 모델 자체가 전체 시스템을 운영하는 것이 아니라, 모델·오케스트레이터·메모리·권한·프로토콜·외부 시스템이 함께 결합되어 AI 앱을 구성한다.
구체적 사례
첫 번째 사례는 개발 업무다. 사용자가 “이 저장소의 최근 PR을 검토하고 릴리스 노트 초안을 만들어줘”라고 요청한다고 하자. AI는 GitHub MCP Server를 통해 최근 PR 목록과 변경 파일을 조회하고, 이슈 트래커에서 관련 티켓을 찾고, 문서 저장소에서 릴리스 노트 양식을 가져올 수 있다. 이후 변경사항을 요약하고 위험한 변경을 표시하며 릴리스 노트 초안을 작성한다. 실제 게시나 배포는 사용자 승인 후 실행되는 편이 안전하다.
두 번째 사례는 사내 지식 검색이다. 사용자가 “우리 회사 보안 정책상 이 고객 데이터를 외부 벤더에 보낼 수 있는지 확인해줘”라고 묻는다면, AI는 사내 정책 문서, 법무 검토 기록, 계약 문서를 검색해야 한다. MCP Server는 문서 저장소나 벡터 검색 시스템에 대한 표준 접근 계층이 될 수 있다. 모델은 내부 파라미터로 답하는 대신 관련 문서를 조회하고, 확인된 내용과 불확실한 부분을 구분해 답할 수 있다.
세 번째 사례는 일정과 커뮤니케이션 자동화다. “다음 주 화요일 오후에 A팀과 B팀이 모두 가능한 30분 회의를 잡고, 안건 초안도 보내줘”라는 요청은 캘린더 조회, 참석자 확인, 메일 또는 메신저 초안 작성, 회의 안건 생성이 결합된 작업이다. MCP Server는 캘린더, 메일, 메신저, 문서 템플릿에 대한 접근을 제공할 수 있다. 회의 초대 발송이나 외부 메시지 전송은 승인 기반으로 처리하는 편이 바람직하다.
네 번째 사례는 로컬 프로그램 조작이다. Blender MCP처럼 특정 프로그램의 API를 MCP Server로 감싸면 AI가 3D 오브젝트 생성, 장면 구성, 간단한 스크립트 실행을 도울 수 있다. 이때 “AI가 직접 Blender를 조작한다”는 표현은 사용자 관점에서는 이해하기 쉽지만, 기술적으로는 MCP Server가 Blender Python API 같은 기존 실행 인터페이스를 호출하는 구조다.
다섯 번째 사례는 데이터 분석이다. 사용자가 “지난 분기 매출 데이터를 분석해서 이상치를 찾고 보고서로 정리해줘”라고 하면 AI는 데이터베이스 조회 도구, 코드 실행 도구, 파일 생성 도구, 문서 작성 도구를 조합할 수 있다. 이 구조에서는 데이터 접근 권한, 쿼리 제한, 개인정보 마스킹, 실행 로그가 특히 중요하다.
보안과 권한: MCP의 핵심 설계 조건
MCP가 강력한 이유는 외부 시스템에 접근할 수 있기 때문이다. 같은 이유로 MCP는 위험하다. 모델이 단순히 문장을 생성할 때의 오류와, 모델이 파일을 수정하고 메일을 보내고 데이터베이스를 변경할 때의 오류는 위험 수준이 다르다. 에이전트형 시스템에서 보안은 부가 기능이 아니라 핵심 설계 조건이다.
첫 번째 원칙은 최소 권한이다. MCP Server와 Host는 사용자가 요청한 작업에 필요한 범위만 접근해야 한다. 읽기만 필요한 작업에 쓰기 권한을 주면 위험이 커진다. 특정 폴더만 읽으면 되는 작업에 전체 파일 시스템 접근을 주는 것도 피해야 한다. 사내 DB를 조회해야 한다면 필요한 테이블, 쿼리, 행·열 수준 권한을 제한해야 한다.
두 번째 원칙은 명시적 승인이다. 데이터 조회처럼 비교적 낮은 위험의 행동과, 메일 발송·파일 삭제·결제·배포·권한 변경처럼 높은 위험의 행동을 분리해야 한다. OpenAI 문서도 remote MCP server나 connector로 데이터가 공유될 때 승인과 검토 흐름을 권장한다. 높은 위험 작업은 모델이 바로 실행하지 않고 사용자에게 계획과 전송될 데이터, 예상 결과를 보여준 뒤 승인받는 구조가 필요하다.
세 번째 원칙은 도구 표면 제한이다. MCP Server가 수십 개의 도구를 제공할 수 있어도, 모든 도구를 모델에게 항상 노출하는 것은 비용과 위험을 높인다. OpenAI 문서는 allowed_tools 같은 방식으로 tool surface를 좁히는 것을 권장한다. 도구 수를 줄이면 토큰 비용과 지연 시간이 줄고, 모델의 선택 공간도 좁아지며, 실수 가능성도 낮아진다.
네 번째 원칙은 투명성이다. 사용자는 AI가 어떤 MCP Server를 사용했고, 어떤 데이터를 조회했고, 어떤 도구를 호출하려 하는지 이해할 수 있어야 한다. 도구 설명, 파라미터, 호출 결과가 숨겨진 채 모델이 행동하면 검증이 어렵다.
다섯 번째 원칙은 감사 가능성이다. 조직 환경에서는 누가 어떤 권한으로 어떤 데이터를 조회했고 어떤 행동을 실행했는지 기록해야 한다. 이는 사고 대응뿐 아니라 내부 통제와 규제 준수에도 중요하다.
여섯 번째 원칙은 신뢰 가능한 서버 사용이다. 검증되지 않은 MCP Server를 설치하면 악성 도구 설명, 과도한 권한 요청, 데이터 유출, 로컬 명령 실행 위험이 생길 수 있다. OpenAI의 MCP 서버 개발 문서도 custom MCP server가 외부 애플리케이션과 데이터를 주고받고 행동을 수행할 수 있으므로 신뢰할 수 있는 서버만 연결하라고 권고한다.
보안 위협을 더 구체적으로 보면 다음 항목을 반드시 고려해야 한다.
| 위험 | 의미 | 대응 방향 |
|---|---|---|
| Prompt injection | 외부 문서나 웹페이지의 숨은 지침이 모델 행동을 왜곡하는 공격 | 외부 입력을 불신하고, 시스템 지침·사용자 지침·도구 결과를 분리한다. |
| Tool poisoning | 도구 설명이나 metadata에 악성 지침을 심어 모델이 잘못된 도구를 호출하게 하는 공격 | 신뢰된 서버만 사용하고, tool description을 검토하며, 위험 도구는 승인 대상으로 둔다. |
| Rug pull | 처음에는 정상인 서버나 도구가 나중에 악성 동작으로 바뀌는 위험 | 버전 고정, 공급망 검증, 서버 변경 감지, 재승인 절차를 둔다. |
| Confused deputy | 권한을 가진 MCP Server나 Client가 공격자의 요청을 대리 수행하는 문제 | audience, scope, consent, 요청 출처 검증을 명확히 한다. |
| Token passthrough | MCP Server가 자신에게 발급되지 않은 토큰을 검증 없이 하위 API에 전달하는 위험 | 토큰 audience를 검증하고, MCP Server 전용 토큰을 사용하며, 무검증 passthrough를 금지한다. |
| SSRF | 악성 서버가 클라이언트나 프록시로 하여금 내부 네트워크나 metadata endpoint에 요청하게 만드는 공격 | URL allowlist, 내부 IP 차단, metadata endpoint 차단, network egress 제한을 적용한다. |
| Session hijacking | MCP-Session-Id 같은 세션 식별자가 탈취되어 세션이 가로채지는 위험 | 세션 ID를 안전하게 생성·저장하고, TLS, cookie 보안 속성, 만료, 재인증을 적용한다. |
| Local MCP server compromise | 로컬 MCP Server가 파일 시스템이나 셸 권한을 악용하는 위험 | sandboxing, 제한된 파일 경로, 명령 실행 제한, 서명된 서버 사용을 고려한다. |
| Scope overgranting | 필요한 범위보다 넓은 OAuth scope나 파일 권한을 부여하는 문제 | 최소 scope, 읽기·쓰기 분리, 사용자별 권한 검토를 적용한다. |
이 표에서 보듯 MCP 보안은 prompt injection만의 문제가 아니다. OAuth, token audience, SSRF, session handling, local process 권한, network boundary, audit trail까지 함께 다뤄야 한다. MCP는 연결 표준이므로, 연결이 늘어날수록 보안 경계도 함께 늘어난다.
주요 쟁점과 반론
첫 번째 쟁점은 표준화 가능성이다. MCP가 AI 도구 연결의 강력한 후보인 것은 맞지만 모든 플랫폼이 동일한 수준으로 MCP를 지원한다고 단정할 수는 없다. 각 Host는 지원하는 transport, 인증 방식, UI 표시 방식, 도구 호출 정책, 모델 능력이 다르다. 표준은 통합 비용을 줄이지만 실제 호환성은 구현 품질에 좌우된다.
두 번째 쟁점은 “앱의 종말” 주장이다. AI가 여러 앱을 조율한다고 해서 기존 앱이 사라진다고 보기는 어렵다. 복잡한 설계, 시각적 편집, 정밀한 데이터 관리, 협업 검토, 규제 준수 업무에서는 여전히 전용 UI가 필요하다. 현실적인 변화는 앱의 대체라기보다 역할의 재배치다. 사용자는 고수준 목표를 AI에게 말하고, AI는 앱의 기능을 호출하며, 사람은 중요한 판단과 승인을 담당하는 구조가 늘어날 가능성이 크다.
세 번째 쟁점은 자율성의 범위다. MCP가 있다고 해서 AI가 완전히 자율적으로 일해야 한다는 뜻은 아니다. 위험한 업무일수록 human-in-the-loop 구조가 필요하다. 좋은 에이전트 시스템은 모든 것을 자동화하는 시스템이 아니라, 자동화할 수 있는 부분과 사람이 책임져야 하는 부분을 분리하는 시스템이다.
네 번째 쟁점은 모델 성능과 연결 성능의 관계다. MCP가 외부 연결을 표준화하더라도 모델이 잘못된 도구를 고르거나 결과를 오해하면 품질은 떨어진다. 반대로 모델이 강해도 도구 설명이 부실하거나 권한 정책이 엉성하면 시스템은 위험해진다. AI 앱의 품질은 모델, 도구, 데이터, 권한, UI, 검증 루프의 결합으로 결정된다.
다섯 번째 쟁점은 보안과 생산성의 긴장이다. MCP는 생산성을 높이지만 공격 표면도 넓힌다. 도구 수가 많아질수록 권한 검토, 로그 관리, 공급망 검증, 프롬프트 주입 방어가 어려워진다. 생산성을 위해 모든 권한을 열어두면 위험하고, 보안을 위해 모든 행동을 막으면 자동화 가치가 줄어든다. 실제 제품에서는 위험도 기반 권한, 단계별 승인, 읽기·쓰기 분리, 민감 작업 격리, 감사 로그가 균형점을 만든다.
오해와 한계
첫 번째 오해는 “MCP가 있으면 AI가 모든 앱을 자동으로 조작할 수 있다”는 생각이다. MCP Server가 존재하고, Host가 그 Server를 지원하며, 인증이 설정되고, 사용자가 권한을 허용하고, 해당 Server가 필요한 도구를 제공해야 실제 작업이 가능하다. MCP는 연결 규격이지 범용 실행 권한이 아니다.
두 번째 오해는 “MCP는 보안을 자동으로 해결한다”는 생각이다. MCP 사양에는 authorization과 보안 고려사항이 포함되어 있지만, 안전한 구현은 별개의 문제다. Server가 과도한 권한을 요구하거나, Host가 도구 호출을 충분히 표시하지 않거나, 조직이 로그와 승인 체계를 만들지 않으면 위험은 그대로 남는다.
세 번째 오해는 “MCP와 function calling은 같은 것”이라는 생각이다. 둘은 겹치는 부분이 있지만 층위가 다르다. Function calling은 모델이 특정 함수를 호출하는 API 기능에 가깝고, MCP는 외부 Server가 Tools, Resources, Prompts를 표준 방식으로 노출하는 프로토콜이다. 실제 시스템에서는 둘이 함께 쓰일 수 있다.
네 번째 오해는 “AI 운영체제”라는 표현을 문자 그대로 받아들이는 것이다. MCP는 운영체제가 아니다. MCP 기반 AI OS라는 말은 AI가 여러 앱과 시스템을 조율하는 상위 인터페이스가 될 수 있다는 비유다. 운영체제 수준의 안정성, 프로세스 격리, 권한 모델, 하드웨어 관리와 동일한 의미로 쓰면 개념이 과장된다.
다섯 번째 오해는 “연결만 표준화하면 에이전트가 잘 작동한다”는 생각이다. 실제 에이전트 시스템의 어려움은 연결 이후에 더 커질 수 있다. 도구가 많아지면 어떤 도구를 써야 할지 고르는 문제가 생긴다. 장기 작업에서는 상태 관리와 컨텍스트 압축이 필요하다. 실패가 발생하면 재시도, 롤백, 사용자 확인이 필요하다. 비용과 지연 시간도 관리해야 한다.
MCP의 한계는 분명하다. MCP는 연결 계층을 표준화하지만 모델의 추론 오류, 데이터 품질 문제, 권한 설계 실패, 악성 서버, prompt injection, tool poisoning, token handling 오류, 조직 내부 프로세스 부재를 자동으로 해결하지 않는다. 따라서 MCP의 가치는 단독 기술이 아니라 안전한 에이전트 아키텍처 안에서 평가되어야 한다.
앞으로의 개발 방식 변화
MCP가 확산되면 개발자의 작업 중심도 일부 바뀔 수 있다. 기존 애플리케이션 개발은 대체로 프론트엔드, 백엔드, 데이터베이스, API를 직접 설계하는 방식이었다. 사용자는 UI를 통해 명령을 내리고, 앱은 미리 정해진 흐름에 따라 작업을 수행했다.
에이전트형 애플리케이션에서는 개발자가 더 많이 고민해야 할 문제가 달라진다. 화면의 버튼을 얼마나 만들 것인가보다, AI가 어떤 도구를 사용할 수 있고, 어떤 상황에서 어떤 권한을 가져야 하며, 어느 단계에서 사용자 승인을 받아야 하는지가 중요해진다. 도구 설명을 어떻게 써야 모델이 오용하지 않는지, 도구 결과를 어떻게 검증할지, 실패 시 어떻게 중단하거나 되돌릴지, 어떤 로그를 남길지도 핵심 설계 문제가 된다.
| 기존 중심 | 에이전트형 앱에서 강화되는 중심 |
|---|---|
| 화면 흐름 설계 | 목표 기반 작업 흐름 설계 |
| CRUD API 구현 | 도구 표면과 권한 경계 설계 |
| 단일 앱 내부 로직 | 여러 시스템의 오케스트레이션 |
| 입력값 검증 | 모델 행동, 도구 호출, 외부 컨텍스트 검증 |
| 일반 로그 | 감사 로그와 책임 추적 |
| 사용자 클릭 | 제안-검토-승인-실행 루프 |
| 앱 단위 기능 | 작업 단위 자동화 |
이 변화는 개발자가 덜 중요해진다는 뜻이 아니다. 오히려 시스템 설계가 더 중요해진다. LLM은 유연한 추론과 언어 인터페이스를 제공하지만, 안전하고 반복 가능한 업무 시스템을 만들려면 개발자가 도구 경계, 데이터 흐름, 실패 처리, 권한 모델을 정교하게 설계해야 한다.
조직과 SaaS에 대한 함의
MCP와 에이전트형 AI는 조직의 소프트웨어 경쟁력을 다르게 평가하게 만든다. 과거에는 좋은 SaaS UI와 기능이 중요했다. 앞으로는 AI가 접근할 수 있는 구조화된 데이터, 명확한 권한 모델, 감사 가능한 API, MCP Server 또는 connector, 승인 워크플로가 더 중요해질 수 있다.
조직 입장에서는 데이터가 흩어져 있고 권한 구조가 엉성하면 AI 에이전트를 도입하기 어렵다. 사내 문서가 검색되지 않거나, 데이터베이스 스키마가 정리되어 있지 않거나, 누가 어떤 정보에 접근할 수 있는지 불분명하면 AI는 안전하게 일하기 어렵다. 반대로 데이터 모델이 잘 정리되어 있고, 접근 권한이 명확하며, API와 로그가 잘 갖춰진 조직은 AI 에이전트의 도움을 더 쉽게 받을 수 있다.
SaaS 기업 입장에서도 변화가 생긴다. 사용자가 직접 화면에서 클릭하는 기능뿐 아니라, AI가 안전하게 호출할 수 있는 기능 표면이 중요해진다. 좋은 MCP Server, 명확한 tool schema, 세밀한 OAuth scope, 읽기·쓰기 권한 분리, 사용자 승인 UI, 감사 로그 제공은 SaaS의 경쟁력이 될 수 있다. 장기적으로 일부 SaaS는 “사람이 쓰는 앱”이면서 동시에 “에이전트가 호출하는 기능 모듈”이 되어야 한다.
이 관점에서 AI 시대의 조직 경쟁력은 단순히 “최신 모델을 쓰는가”가 아니라 “조직의 지식과 업무 시스템이 에이전트가 안전하게 사용할 수 있을 정도로 정리되어 있는가”로 이동할 가능성이 크다.
정리
MCP는 AI 에이전트 시대의 운영체제가 아니라, AI 애플리케이션이 외부 데이터, 도구, 워크플로와 상호작용하도록 돕는 표준 연결 프로토콜이다. 그 중요성은 모델 성능이 아니라 연결, 권한, 승인, 검증, 감사 가능성이 실제 업무 자동화의 병목이 되는 지점에서 나타난다.
MCP는 Host, Client, Server 구조를 통해 외부 시스템의 Tools, Resources, Prompts를 AI 애플리케이션에 노출한다. 최신 표준 transport는 stdio와 Streamable HTTP이며, HTTP+SSE는 이전 사양 또는 일부 호환 구현의 맥락에서 이해하는 편이 정확하다. 2025-11-25 사양에서는 tasks가 experimental 기능으로 추가되어 장기 작업 추적 가능성이 확장되었지만, 안정된 필수 기능처럼 과장해서는 안 된다.
MCP는 “앱 안의 AI 기능”에서 “AI가 여러 앱과 시스템을 조율하는 구조”로의 이동을 촉진할 수 있다. 그러나 이 변화는 MCP 단독으로 성립하지 않는다. Host와 Server 생태계, 권한 모델, 승인 UI, 에이전트 오케스트레이션, 조직 데이터 정비, 보안 정책이 함께 갖춰져야 한다.
MCP의 미래 가치는 “얼마나 많은 도구를 붙일 수 있는가”보다 “얼마나 안전하고 검증 가능하게 외부 세계와 연결할 수 있는가”에 의해 결정될 것이다. 따라서 MCP를 이해하는 가장 정확한 문장은 다음과 같다.
MCP는 AI를 “대답하는 모델”에서 “외부 시스템과 연결되어 업무 일부를 실행·보조할 수 있는 에이전트형 애플리케이션”으로 옮기는 표준 연결 계층이다.
참고자료
- Anthropic, “Introducing the Model Context Protocol”, Anthropic News, 2024년 11월 25일, 확인일 2026년 5월 6일.
- Model Context Protocol, “What is the Model Context Protocol (MCP)?”, MCP 공식 문서, 확인일 2026년 5월 6일.
- Model Context Protocol, “Specification”, MCP 공식 문서, 2025년 11월 25일, 확인일 2026년 5월 6일.
- Model Context Protocol, “Architecture”, MCP 공식 문서, 2025년 11월 25일, 확인일 2026년 5월 6일.
- Model Context Protocol, “Transports”, MCP 공식 문서, 2025년 11월 25일, 확인일 2026년 5월 6일.
- Model Context Protocol, “Tools”, MCP 공식 문서, 2025년 11월 25일, 확인일 2026년 5월 6일.
- Model Context Protocol, “Resources”, MCP 공식 문서, 2025년 11월 25일, 확인일 2026년 5월 6일.
- Model Context Protocol, “Prompts”, MCP 공식 문서, 2025년 11월 25일, 확인일 2026년 5월 6일.
- Model Context Protocol, “Authorization”, MCP 공식 문서, 2025년 11월 25일, 확인일 2026년 5월 6일.
- Model Context Protocol, “Security Best Practices”, MCP 공식 문서, 확인일 2026년 5월 6일.
- Model Context Protocol, “Key Changes”, MCP 공식 문서, 2025년 11월 25일, 확인일 2026년 5월 6일.
- OpenAI, “MCP and Connectors”, OpenAI Developers, 확인일 2026년 5월 6일.
- OpenAI, “Building MCP servers for ChatGPT Apps and API integrations”, OpenAI Developers, 확인일 2026년 5월 6일.
- OpenAI, “Realtime API with MCP”, OpenAI Developers, 확인일 2026년 5월 6일.
- OpenAI Cookbook, “Guide to Using the Responses API's MCP Tool”, OpenAI Developers, 2025년 5월 21일, 확인일 2026년 5월 6일.
- GitHub Docs, “About Model Context Protocol (MCP)”, GitHub Copilot Documentation, 확인일 2026년 5월 6일.
- GitHub Docs, “Adding MCP servers for GitHub Copilot CLI”, GitHub Copilot Documentation, 확인일 2026년 5월 6일.
- OWASP Community, “MCP Tool Poisoning”, OWASP, 확인일 2026년 5월 6일.
- Charoes Huang, Xin Huang, Ngoc Phu Tran, Amin Milani Fard, “Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning”, arXiv, 2026년 3월 23일, 확인일 2026년 5월 6일.