이 기사는 note 본편 「MCP는 왜 2026년의 필수 기술이 되었는가」의 보충 용어집입니다. 본편에 등장하는 MCP 관련 용어를 초보자도 따라갈 수 있도록 체계적으로 정리했습니다. 본편과 함께 읽으면 이해가 깊어집니다. ▶

note 본편: MCP는 왜 2026년의 필수 기술이 되었는가 (※ 공개 후 URL 삽입)

이 용어집은 MCP 관련 용어를 초보자도 읽어나갈 수 있도록 체계적으로 정리한 것입니다. 각 카테고리는 「기초 → 프리미티브 (Primitive) → 트랜스포트 (Transport) → 2025–2026 신개념 → 설계·운용 → 보안 → 에코시스템 (Ecosystem)」 순으로 배열하여, note 본편의 논지(표준이 확정되고, 설계의 중심이 프로토콜에서 "사용자 측"으로 이동했다)를 따라갈 수 있도록 구성했습니다. 주요 지점에는

설계상의 핵심 포인트로서, 2026년의 문맥에서 각 개념이 왜 유효한지를 덧붙였습니다.

아래 그림은 사양 버전의 변천사입니다. 프로토콜의 토대(인가·트랜스포트·비동기 처리·스테이트리스(Stateless)화)가 단계적으로 굳어져 가는 흐름이, note 본편의 주제인 「설계의 중심이 프로토콜에서 "사용자 측"으로 이동했다」의 배경이 됩니다.

MCP (Model Context Protocol)

LLM 앱과 외부 도구·데이터를 연결하기 위한 오픈 표준 프로토콜. 2024년 11월에 Anthropic이 공개했다. 도구별 개별 통합을 하나의 공통 규격으로 대체하는 것을 목표로 한다. 「AI 버전의 USB-C」라고 비유되는 경우가 많다.

Host (호스트)

MCP 클라이언트(Client)를 내포하며, AI 태스크를 실행하는 애플리케이션 본체. Claude Desktop, Cursor, VS Code 등이 이에 해당한다. AI와 외부 리소스 사이에 서서 모든 상호작용을 중개하는 「보안 브로커 (Security Broker)」 역할을 담당한다.

Client (클라이언트)

호스트 내에 위치하며, 하나의 서버(Server)와 1대 1로 접속하는 관리자 역할. 능력 발견 (Discovery) 및 프리미티브 (Primitive) 호출을 담당한다.

Server (서버)

외부 시스템(DB, API, 파일 등)에 대한 액세스나 조작을 제공하는 측. Tools · Resources · Prompts의 3가지 기능을 공개한다. HTTP 서버일 필요는 없으며, stdio로 동작하는 로컬 프로세스도 「서버」라고 부른다는 점에 주의해야 한다.

JSON-RPC 2.0

MCP 메시지 형식의 토대가 되는 경량 RPC 사양. 요청(Request) / 응답(Response) / 통지(Notification) / 에러(Error)를 규정한다.

Capability negotiation (능력 협상)

연결 확립 시(initialize)에 서버와 클라이언트가 서로의 대응 기능을 선언하는 메커니즘. 「서버가 무엇을 할 수 있는지 선언하고, 호스트가 무엇을 허용할지 결정한다」는 능력 기반 설계의 핵심을 이룬다.

LSP (Language Server Protocol)

MCP 설계의 아이디어 원천. 「에디터 × 프로그래밍 언어」의 M×N 문제를 공통 프로토콜로 해결한 전례로, MCP는 동일한 발상을 「AI 앱 × 도구」에 적용했다.

M×N 문제 (N×M integration problem)

M개의 AI 앱과 N개의 도구를 개별적으로 연결하면 조합(M×N)이 폭발하는 과제. MCP는 이를 「M+N」으로 압축하는 것을 목표로 한다.

Mediated Access Pattern (중개 액세스 패턴)

AI가 외부 리소스에 직접 닿지 않고, 반드시 호스트를 거쳐 액세스하는 MCP의 기본 구조. 보안 경계를 한곳으로 집약하는 설계 사상.

아래 그림이 MCP의 기본 구조입니다. LLM은 외부 리소스에 직접 닿지 않고, Host (브로커)를 거칩니다. 리소스 종류별로 Client와 Server가 1대 1로 대응하며, 각 Server가 3가지 프리미티브 (Tools / Resources / Prompts)를 공개합니다.

Tools (툴)

AI 모델이 실행할 수 있는 함수. 외부 API 호출이나 데이터 조작을 수행한다. 기존의 function calling과 달리, 모델이 문맥에 따라 자율적으로 선택·실행한다는 점이 특징이다.

Resources (리소스)

모델이나 사용자가 참조하기 위한 읽기 전용 데이터. 파일 내용, DB 레코드, API 응답 등을 포함한다.

Prompts (프롬프트)

재사용 가능한 템플릿이나 워크플로우. 정형화된 태스크의 일관성과 효율을 높인다.

Tool annotations (툴 어노테이션)

툴의 성질을 클라이언트에게 전달하는 메타 정보. readOnlyHint

(readOnlyHint (읽기 전용)), destructiveHint (파괴적 변경을 수반함) 등이다. 클라이언트가 안전 정책(승인 플로우 등)을 적용하는 판단 근거가 된다. 또한 사양상, 어노테이션은 신뢰할 수 있는 서버로부터 온 것이 아니라면 신뢰해서는 안 된다고 명시되어 있다.

Sampling (샘플링)

서버가 클라이언트(호스트) 측의 LLM에 추론을 요청하는 메커니즘. 서버 기점의 재귀적인 에이전트 동작을 가능하게 한다. 2025-11-25에 툴 호출(Tool calling) 기능도 대응되었다.

Roots (루츠)

서버가 조작해도 되는 URI나 파일 시스템의 경계를 클라이언트 측에서 나타내는 메커니즘.

Elicitation (엘리시테이션)

서버가 처리 도중에 사용자에게 추가 정보를 요청하는 메커니즘.

URL mode elicitation (URL 모드 엘리시테이션)

인증 정보를 클라이언트에 직접 전달하지 않고, 브라우저에서 OAuth 플로우 등을 완료하는 방식 (2025-11-25). API 키나 비밀번호가 MCP 클라이언트를 통과하지 않기 때문에, 외부 API 연동이나 결제(PCI 준수)를 안전하게 다룰 수 있다.

Transport Layer (트랜스포트 계층)

실제 통신을 담당하는 계층. MCP는 동일한 JSON-RPC 메시지를 서로 다른 통신 방식으로 운반할 수 있다 (Transport 비의존성).

stdio

표준 입출력을 사용하는 로컬용 트랜스포트. 네트워크를 거치지 않아 빠르며, 프로세스 분리에 따른 안전성(인증 핸드셰이크나 방화벽 문제도 불필요)을 얻을 수 있다. 클라이언트는 가능한 한 stdio 대응이 권장된다.

Streamable HTTP

원격용 표준 트랜스포트 (2025-03-26 도입). 단일 엔드포인트(예: /mcp)가 POST/GET을 모두 처리하며, 필요에 따라 SSE로 스트리밍한다.

HTTP+SSE (구 트랜스포트)

2024-11-05 버전의 방식. Streamable HTTP로 대체되어 권장되지 않으나 (deprecated), 일부 툴에서 여전히 사용된다.

Stateful / Stateless (스테이트풀 / 스테이트리스)

연결이 세션 상태를 유지하는지 여부. MCP는 당초 스테이트풀(Stateful)이었으나, 서버가 메모리 내에 상태를 보유하면 수평 확장(Horizontal scale)을 방해한다.

설계상의 핵심: 2026년 최대의 설계 테마가 바로 이 스테이트리스(Stateless)화이다. 로드 밸런서 배후에서의 수평 확장, 프록시를 거치는 운용, 서버 재시작에 대한 내성이 스테이트풀을 전제로 했을 때는 확보하기 어렵다는 점이 실운영에서 판명되었다.

아래 그림은 두 가지 표준 트랜스포트의 대비입니다. 로컬에서 구동할지, 원격에서 확장할지에 따라 선택합니다.

OAuth 2.1 / Authorization Framework (인가 프레임워크)

2025-03-26에 표준화된 MCP의 인가 방식. 원격(HTTP 계열) 트랜스포트에만 적용되며, stdio는 환경 변수 유래의 인증 정보를 사용한다.

OAuth Resource Server (OAuth 리소스 서버)

2025-06-18에 MCP 서버가 공식적으로 이 위치로 정의되었다. 보안과 발견성 (Discovery) 관점에서 의미를 갖는다.

Dynamic Client Registration (DCR, 동적 클라이언트 등록)

클라이언트가 인가 서버에 스스로 등록하는 메커니즘. MCP에서는 무수히 많은 클라이언트/서버가 존재하기 때문에 필요했으나, 인가 서버 측의 대응이 필요하며 OAuth 프록시 구축이 복잡해지는 과제가 있었다.

Client ID Metadata Documents (CIMD)

DCR의 과제에 대한 해결책 (SEP-991, 2025-11-25). 클라이언트가 직접 관리하는 JSON 문서의 URL을 클라이언트 ID로 사용하는 URL 기반 등록 방식.

이 부분이 note 본문의 핵심이다. "툴을 공개하는" 단계에서 "에이전트가 효율적으로 다룰 수 있는 형태로 설계하는" 단계로, "좋은 설계"의 정의 자체가 바뀌었다.

Tasks (태스크)

장시간 처리를 "call-now / fetch-later (지금 호출하고, 나중에 가져오기)"로 다루는 비동기 프리미티브 (Primitive). working / input_required / completed / failed / cancelled 상태를 가진다.

설계상의 핵심: 2025-11-25에 실험적으로 도입되었으나, 실운영에서의 재설계를 거쳐 2026-07-28 RC에서는 사양 본체가 아닌 확장 (Extension)으로 옮겨졌다. "코어에 넣기 전에 실험을 통해 다듬는다"는 거버넌스 설계의 좋은 사례이다.

Extensions (확장)

Extensions (확장)

코어 사양 외부에서 기능을 추가하는 메커니즘. 원칙은 "임의적·추가적·합성 가능·독립적 버전"이다.

설계상의 핵심 (Design key points): 코어를 최소화하고 안정적으로 유지하면서, UI나 독자적인 인증 등을 정식 승격 전에 실험할 수 있다. MCP Apps나 Tasks가 이 경로를 따랐다. "단순함 vs 확장 요구" 사이의 긴장을 제도로 해결하고 있다.

MCP Apps

서버가 React 등의 대화형 UI(대시보드, 폼, 데이터 시각화 등)를 호스트에 전달하는 공식 확장(SEP-1865, 구 mcp-ui). 텍스트/구조화 데이터에 국한되었던 MCP에 UI 기능을 도입한다.

Code Execution with MCP (MCP를 통한 코드 실행)

도구를 "직접 호출"하는 것이 아니라, 코드 API로서 제시하여 에이전트가 코드를 작성하게 하는 설계 패턴(Anthropic, 2025년 11월). 공식적으로 제시된 한 사례에서는 150,000 토큰이 약 2,000 토큰으로(98.7% 감소) 줄어들었다고 보고되었다.

설계상의 핵심 (Design key points): note 본문의 하이라이트이다. 다만 이 "98.7%"는 특정 워크플로우의 한 사례일 뿐 보편적인 수치는 아니다(구현 보고에 따르면 조건에 따라 변동됨). 무조건 믿기보다는 자신의 환경에서 측정해 볼 가치가 높다. 또한 에이전트가 생성한 코드의 실행에는 안전한 샌드박스(Sandbox), 리소스 제한, 모니터링이라는 운영 비용이 따른다는 점도 충실히 짚고 넘어가야 한다.

아래 그림은 "기존의 직접적인 도구 호출"과 "Code Execution"의 차이점입니다. note 본문의 핵심이 되는 대비 구조입니다.

Progressive disclosure (점진적 공개)

모든 도구 정의를 미리 로드하지 않고, 에이전트가 파일 시스템 탐색이나 search_tools를 통해 필요한 정의만을 필요할 때 읽어오는 방식. 토큰 비대화의 주원인(정의의 사전 로드)에 대한 직접적인 처방전이다.

Code Mode

Cloudflare가 제창한 동일한 취지의 개념. "LLM은 MCP를 직접 호출하는 것보다, MCP를 호출하는 코드를 작성하는 것을 더 잘한다"는 통찰. Apple의 CodeAct, Docker의 동적 MCP와도 수렴하는 업계 횡단적 흐름이다.

Skills / SKILL.md

재사용 가능한 절차·스크립트·리소스 등을 모아둔 폴더. 에이전트가 한 번 작성한 유효한 코드를 저장하고, 이를 더 높은 차원의 능력으로 축적해 나가는 메커니즘으로 이어진다.

Tool Budget (도구 예산)

에이전트가 효과적으로 다룰 수 있는 도구의 수에는 상한선이 있다는 개념(Docker). 도구를 너무 많이 포함하면 서버가 복잡해지고 비용이 높아지며, 도구 선택의 정확도도 떨어진다.

Token budget pagination (토큰 예산 페이지네이션)

레코드 수가 아니라 소비되는 토큰 양으로 구분하는 페이지네이션 방식(Datadog). 거대한 응답 1건으로 인해 컨텍스트(Context)가 고갈되는 사고를 방지한다.

Tool poisoning / toolflow hijacking (도구 오염 / 도구 흐름 가로채기)

도구 설명문에 "이 도구를 우선하라" 등의 유도 문구를 삽입하여 에이전트의 도구 선택을 조작하는 공격. 기능이 떨어지는 도구라도 선택하게 만들 수 있다.

Thin API wrapper (얇은 API 래퍼) 안티 패턴

기존 API를 그대로 도구화하기만 한 설계. 에이전트용으로는 불충분하며, 인간용 API와는 별개로 다시 설계해야 한다는 실무적 교훈.

MCP Gateway (MCP 게이트웨이)

에이전트와 서버군 사이에 위치하는 제어 평면(Control plane). 인증 정보 관리, 라우팅, 정책 강제, 가관측성(Observability), RBAC를 집약한다. 운영 환경에서의 표준 패턴이다.

MCP Registry (MCP 레지스트리)

사용 가능한 MCP 서버를 발견하고 검증하기 위한 색인. 2025년에 공식 버전이 등장했다. 기업이 자체적인 레지스트리를 보유하려는 구상도 진행 중이다.

Server allowlist / Tool allowlist (서버 / 도구 허용 목록)

연결 가능한 서버, 호출 가능한 도구를 명시적으로 나열하는 "기본 거부(Default deny)" 방식의 통제. 엔터프라이즈 환경의 기본 제어 방식이다.

가관측성 / 감사 추적 (Observability / Audit trail)

도구 호출의 기록 및 추적. 프로토콜 본체에는 아직 표준화되지 않았으며, 현재 각 기업이 OpenTelemetry 등을 사용하여 자체적으로 구현하고 있는 상태이다. 2026년 로드맵의 중점 영역 중 하나이다.

Prompt injection (프롬프트 인젝션)

신뢰할 수 있는 콘텐츠와 신뢰할 수 없는 콘텐츠를 동일한 문맥(Context)에 섞음으로써 발생하는 공격. SQL 인젝션 (SQL Injection)을 본떠 Simon Willison이 명명했다.

Indirect prompt injection (간접 프롬프트 인젝션)

이메일이나 웹 페이지 등 에이전트가 읽어들이는 외부 콘텐츠에 악의적인 지시를 심어두는 수법.

Lethal Trifecta (치명적인 세 요소)

① 프라이빗 데이터(Private Data)에 대한 접근, ② 신뢰할 수 없는 콘텐츠에 대한 노출, ③ 외부 통신 능력——이 세 가지가 하나의 에이전트에 모두 갖춰지면, 프롬프트 인젝션 (Prompt Injection)에 의한 데이터 탈취에 구조적으로 취약해진다는 Simon Willison의 프레임워크 (2025년 6월).

설계상의 핵심: MCP에서 여러 도구(Tool)를 연결하면, 당초 무해했던 에이전트가 자신도 모르게 세 요소를 모두 갖추게 되기 쉽다. '이메일을 요약하는 에이전트'와 '이메일을 보내는 에이전트'를 분리하는 등 설계로만 해결할 수 있는 문제이다.

아래 그림이 Lethal Trifecta의 구도입니다. 3요소가 하나의 에이전트에 모이는 순간 공격이 성립됩니다.

Agents Rule of Two (에이전트의 2가지 법칙)

Lethal Trifecta를 바탕으로 Meta가 제안한 실무 지침. 3요소 중 동시에 갖추게 하는 것은 2개까지로 제한한다는 발상 (Google의 Rule of 2에서 착안).

Name collision (이름 충돌)

정식 서버와 매우 유사한 이름으로 가짜 서버를 등록하여, 설치 시 사용자를 속이는 공격.

Sandbox escape (샌드박스 탈출)

도구 실행 격리 환경의 취약점을 찔러 호스트 권한을 탈취하는 공격. 코드 실행 (Code Execution)을 채택할 때 특히 중요한 논점이 된다.

Capability attestation (능력 증명)의 결여

서버가 임의의 권한을 주장할 수 있게 되는 프로토콜 레벨의 구조적 약점으로 학술 연구에서 지적되는 논점. 동적 발견 (Dynamic Discovery)의 편의성이 그대로 신뢰의 빈틈이 될 수 있다.

Agentic AI Foundation (AAIF)

MCP의 중립적 거버넌스를 담당하는 Linux Foundation 산하의 재단. 2025년 12월 9일에 Anthropic, Block, OpenAI가 공동 설립하였으며, Google, Microsoft, AWS, Cloudflare, Bloomberg가 지원한다.

설계상의 핵심: MCP가 이곳에 기증됨으로써 특정 벤더의 자산이 아닌 중립 표준으로서 확정되었다. '표준이 굳어졌다 = 설계 책임이 하류(사용 측)로 내려왔다'라는 note 본문의 주장을 뒷받침하는 토대이다.

SEP (Specification Enhancement Proposal)

사양 변경 제안. 커뮤니티가 제출하고 Working Group이 심의한다. MCP 진화의 동력 장치.

Working Group / Interest Group

기능 영역별로 사양 책정을 진행하는 커뮤니티 조직. 2026년에는 날짜 기반의 릴리스에서 WG 주도의 우선 영역으로 거버넌스가 이행되었다.

goose

Block이 개발한 로컬 퍼스트 (Local-first) 오픈 소스 AI 에이전트 프레임워크. AAIF의 창설 프로젝트 중 하나.

AGENTS.md

OpenAI가 제안한, AI 코딩 에이전트에 리포지토리 고유의 지침을 부여하는 공통 규약. AAIF의 창설 프로젝트 중 하나.

A2A (Agent-to-Agent Protocol)

Google에서 시작됨. Agent Card를 통해 에이전트 간의 태스크 위임 및 협업을 담당한다. MCP (도구 연결)의 상위 레이어에 위치하는 경우가 많다.

ACP (Agent Communication Protocol)

REST 네이티브 방식의 멀티모달 메시징. 동기 및 비동기 방식을 모두 지원한다.

ANP (Agent Network Protocol)

W3C DID (분산 식별자)를 통한 오픈 에이전트 발견 및 분산 협업.

단계적 채택 로드맵

서베이 논문이 제시하는 적층 모델: MCP (도구 액세스) → ACP (멀티모달 메시징) → A2A (협업적 태스크 실행) → ANP (분산 마켓플레이스). MCP는 이 최하층, 즉 토대에 위치한다.

이 용어집은 note 본편 **「MCP는 왜 2026년의 필수 기술이 되었는가」**의 보충 자료입니다. 본편이 「왜 2026년에 MCP가 필수인가 (표준화의 확정·토큰 경제·보안 설계)」를 논한다면, 이 용어집은 그 어휘를 배후에서 뒷받침한다는 관계를 맺고 있습니다. 용어의 정의를 확인하셨다면 꼭 본편을 읽어보시기 바랍니다.

▶ note 본편：MCP는 왜 2026년의 필수 기술이 되었는가 (※ 공개 후 URL 삽입)

더욱 넓은 맥락으로서, MCP 설계를 「AI 에이전트 설계의 3층 구조 (Prompt → Context → Harness)」 안에 위치시킨 기사도 있습니다. MCP는 이 중 Context 층 (무엇을 전달할 것인가 = 토큰 경제)과 Harness 층 (어떤 환경에서 구동할 것인가 = 도구 정의와 제약)에 걸쳐 있습니다.

▶ AI 에이전트 설계를 뒷받침하는 3가지 엔지니어링: Prompt·Context·Harness

클라우드 × 생성형 AI × 커리어를 각 플랫폼에서 발신하고 있습니다. 구현 기반의 검증 로그나 설계 이야기를 중심으로 다룹니다. 괜찮으시다면 팔로우 부탁드립니다.

note｜@ebe0911 (사고와 설계의 심층 분석. 본편·관련 기사도 이곳에서): https://note.com/ebe0911 -
Zenn｜@ebe_ryuki (기술 기사·검증 로그): https://zenn.dev/ebe_ryuki -
Qiita｜@ryukiebe0911 (기술 Tips·구현 메모): https://qiita.com/ryukiebe0911 -
X (구 Twitter)｜@EBE_Ryuki (일상적인 검증 메모·최신 토픽 속보): https://x.com/EBE_Ryuki -
LinkedIn (클라우드/커리어 B2B 발신): https://www.linkedin.com/in/ryuki-ebe-4783373b3 -
Instagram｜@ryuk.i0911 (생성형 AI의 실천적인 사용법을 쉽게): https://www.instagram.com/ryuk.i0911/

공식 사양 (최신): https://modelcontextprotocol.io/specification/2025-11-25 -
Anthropic 「Code execution with MCP」: https://www.anthropic.com/engineering/code-execution-with-mcp -
AAIF 설립·MCP 기증 (Anthropic): https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation -
Simon Willison 「The lethal trifecta」: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ -
학술 서베이 (Landscape, Security Threats): arXiv:2503.23278 -
학술 서베이 (프로토콜 비교 MCP/ACP/A2A/ANP): arXiv:2505.02279

※ 용어의 정의는 2026년 6월 시점의 정보에 기반함. 사양은 활발하게 업데이트되고 있으므로, 인용 시에는 1차 정보의 최신 버전을 확인할 것을 권장합니다.