Model Context Protocol (MCP)

📌 Brief Summary

Model Context Protocol(MCP)은 2024년 11월 Anthropic이 도입한 오픈 소스 표준 프로토콜로, LLM 기반 AI 시스템이 외부 데이터 소스, 도구, 시스템과 통합되는 방식을 표준화합니다[1]. 이 프로토콜은 AI 애플리케이션의 "USB-C 포트" 역할을 하여, 각 시스템마다 맞춤형 커넥터를 구축해야 했던 기존의 "N×M" 데이터 통합 문제를 해결합니다[2-4]. 에이전트 하네스 엔지니어링 관점에서 MCP는 하네스의 도구 레지스트리(T-컴포넌트)를 외부 상호운용성 계층으로 분리하여, 맞춤형 통합 코드 없이도 에이전트가 동적으로 도구를 검색하고 실행할 수 있는 표준 인프라를 제공합니다[5-7].

📖 Core Content

아키텍처 및 구성 요소 MCP는 명확한 클라이언트-서버 아키텍처를 따릅니다[8].
- MCP Host: AI 애플리케이션(예: Claude Code, IDE) 자체로, LLM이 포함되어 있으며 여러 MCP 클라이언트를 관리합니다[9, 10].
- MCP Client: Host 내부에 위치하여 LLM의 요청을 MCP 서버가 이해할 수 있게 번역하고 통신을 유지합니다[9, 10].
- MCP Server: 로컬 또는 원격으로 실행되며, LLM에게 컨텍스트와 데이터, 도구 기능을 제공하는 외부 서비스입니다[11, 12]. 이들은 JSON-RPC 2.0을 전송 계층으로 사용하여 통신하며, 로컬 환경에서는 표준 입출력(stdio)을, 원격 환경에서는 Server-Sent Events(SSE)를 포함한 Streamable HTTP를 사용합니다[12-14].
에이전트 하네스에서의 역할 (T-컴포넌트 표준화) MCP는 에이전트 하네스 설계에서 중대한 아키텍처적 전환을 의미합니다. 기존 하네스 내부의 사유 데이터 구조였던 도구 레지스트리를 표준화된 상호운용 계층으로 대체합니다[6, 15]. 하네스는 MCP 클라이언트로 작동하고 도구 제공자는 MCP 서버로 작동함으로써, 하네스는 개별 도구의 구현 세부 사항에 결합(coupling)되지 않고 도구의 발견(capability negotiation), 스키마 검증, 호출(dispatch)을 표준화된 방식으로 거버넌스할 수 있습니다[5, 7].
기본 기능 (Primitives) MCP는 서버가 클라이언트에게 제공할 수 있는 세 가지 핵심 프리미티브를 정의합니다[16, 17].
1. Tools (도구): AI가 외부 시스템에서 조치를 취할 수 있는 실행 가능한 함수 (예: 파일 조작, API 호출).
2. Resources (리소스): AI 애플리케이션에 컨텍스트를 제공하는 데이터 소스.
3. Prompts (프롬프트): LLM과의 상호작용을 구조화하는 재사용 가능한 템플릿. 반대로 클라이언트 측에서도 서버가 호스트 LLM을 사용하거나(Sampling), 사용자 입력을 요청(Elicitation)하거나, 디버깅 메시지를 로깅(Logging)할 수 있는 프리미티브를 제공합니다[18].
A2A(Agent-to-Agent) 프로토콜과의 상호 보완성 MCP는 도구 통합(Agent-to-Tool)에 최적화되어 하네스의 T-컴포넌트 경계를 담당합니다. 반면 Google이 개발한 A2A 프로토콜은 하네스 간의 에이전트 위임 및 오케스트레이션(E-컴포넌트)을 담당합니다[5, 7, 19, 20]. 두 프로토콜은 경쟁 관계가 아닌 보완적 계층으로 작용하여 완전한 형태의 에이전트 통신 스택을 형성합니다[5, 7].

⚖️ Trade-offs & Caveats

네임스페이스 충돌 및 도구 스푸핑(Spoofing) 위협 MCP 사양에는 현재 강력한 네임스페이스 격리 기능이 없습니다. 이로 인해 서로 다른 제공자의 동일한 이름을 가진 도구가 기존의 신뢰할 수 있는 도구를 소리 없이 덮어쓰는(shadowing) 스푸핑 공격 성공률이 100%에 달한다는 분석 결과가 있습니다. 하네스가 MCP를 채택할 때는 프로토콜 수준에서 해결할 수 없는 이 취약점을 하네스 자체의 보안 계층(L-컴포넌트)에서 네임스페이스 격리를 통해 보완해야 합니다[21-23].
보안 경계 및 '간접 프롬프트 인젝션' 위험 MCP를 통해 접근할 수 있는 도구의 출력을 신뢰할 수 있는 것으로 기본 가정해서는 안 됩니다[24, 25]. 악의적인 웹페이지나 외부 데이터를 읽어올 때 숨겨진 지시어가 포함되어 에이전트의 목표를 하이재킹하는 '간접 프롬프트 인젝션' 공격의 주요 표적이 될 수 있습니다[26, 27]. 하네스는 도구 출력이 LLM 컨텍스트에 주입되기 전에 반드시 출력을 검증해야 합니다.
무상태(Stateless) 세션 및 권한 부여의 한계 (2026년 기준) MCP는 서버 인증을 위해 OAuth를 지원하지만, 현재 도구 호출 전반에 걸친 상태 저장 세션(Stateful Session) 관리나, 특정 도구 접근에 대한 세밀한 단위의 권한 부여(authorization) 계층이 프로토콜 내에 표준화되어 있지 않습니다[28, 29]. 또한 원격 배포를 위한 Streamable HTTP 사용 시 상태 기반 헤더가 로드 밸런서와 충돌하는 등 세션 관리의 복잡성이 증가하는 제약이 있습니다[14].

🔗 Knowledge Connections

[관계 유형 A: 아키텍처/기반 기술]

[[Agent Harness]]
- 연결 이유: MCP 클라이언트를 탑재하여 도구와 에이전트(LLM) 사이의 통신을 실질적으로 제어하고 상태를 유지하는 핵심 런타임 인프라.
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: MCP가 제공하는 도구를 에이전트가 남용하지 않도록 제어하는 실행 루프(E-컴포넌트)와 라이프사이클 훅(L-컴포넌트) 등 전반적인 거버넌스 메커니즘 [5, 30, 31].
[[A2A (Agent-to-Agent)]]
- 연결 이유: MCP가 도구/데이터를 위한 인터페이스라면, A2A는 에이전트 간의 작업 위임 및 오케스트레이션을 위한 프로토콜로 MCP와 통신 스택을 구성함.
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단일 하네스를 넘어 멀티 에이전트 환경에서 에이전트가 다른 하네스의 에이전트를 호출할 때 사용되는 프로토콜 설계 및 비대칭적 역할 모델 [5, 7, 19, 20, 32-35].

[관계 유형 B: 구현/활용 도구]

[[JSON-RPC 2.0]]
- 연결 이유: MCP의 데이터 계층에서 클라이언트-서버 간 메시지 구조와 통신 의미(semantics)를 정의하는 기본 기반 프로토콜.
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 동기적 응답과 비동기적 알림(Notifications)이 MCP 데이터 전송에서 어떻게 처리되는지 [12, 13, 36, 37].
[[Agent Skills (Anthropic)]]
- 연결 이유: MCP가 개별 원자적(atomic) 도구 실행을 처리한다면, Agent Skills는 다단계 도구 워크플로우를 포장하는 표준.
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: MCP의 저수준(low-level) 통합을 기반으로 하네스의 L-컴포넌트(라이프사이클) 수준에서 도구들을 어떻게 구성하고 휴대 가능한 형태로 배포하는지 [38-41].

Deeper Research Questions

MCP와 같은 표준화된 도구 통합 프로토콜 환경에서, 상이한 신뢰 수준을 가진 여러 MCP 서버가 반환하는 데이터를 컨텍스트 윈도우 내에서 안전하게 격리하고 검증할 수 있는 하네스 레벨의 보안 메커니즘은 무엇인가?
무상태(stateless)를 기본으로 하는 MCP 서버의 도구 호출 결과물들을 에이전트가 여러 턴에 걸쳐 기억하도록 만들기 위해, 하네스의 상태 저장소(S-컴포넌트)와 MCP를 어떻게 결합해야 하는가?
네임스페이스 충돌을 악용한 MCP의 도구 스푸핑(Tool spoofing) 취약점을 해결하기 위해 에이전트 하네스는 도구 레지스트리 단계에서 어떤 추가적인 식별 및 서명 검증 과정을 거쳐야 하는가?
MCP(Agent-to-Tool)와 A2A(Agent-to-Agent) 사이의 통합 경계에서, A2A를 통해 전달받은 작업 권한(Authorization) 정보를 MCP 서버의 도구 실행 권한으로 어떻게 안전하게 변환하여 매핑할 것인가?
로컬 통신(stdio)과 원격 통신(Streamable HTTP) 사이에서, 에이전트 하네스의 도구 실행 지연 시간(latency) 차이가 LLM의 의사 결정 및 계획 루프(E-컴포넌트) 성능에 어떤 영향을 미치는가?

Practical Application Contexts

Implementation: 애플리케이션 개발 시, 각 벤더별(API마다) 맞춤형 커넥터를 일일이 작성할 필요 없이, 표준화된 JSON-RPC 기반의 단일 MCP 클라이언트만 구현하면 Google Calendar, Notion 등 다양한 외부 서버와 즉시 연동할 수 있습니다 [4, 42, 43].
System Design: 에이전트 시스템을 설계할 때 도구와 데이터의 목록을 하네스 내부에 정적으로 유지하지 않고, 런타임에 외부 MCP 서버로부터 동적으로 발견(Discovery)하고 스키마를 렌더링하도록 분리하여 확장성과 모델 불가지론(agnostic)을 확보합니다 [5, 6].
Operation / Maintenance: 새로운 데이터 저장소나 API 도구가 추가될 때 핵심 에이전트 코드를 재배포할 필요 없이 독립적인 MCP 서버만 배포 및 연결하면 되므로 인프라 관리의 오버헤드가 크게 줄어듭니다 [6, 44].
Learning Path: 단순한 함수 호출(Function Calling)에서부터 특정 도메인 RAG, 대규모 API 통합(ToolLLM)을 거쳐 최종적으로 개방형 표준 프로토콜(MCP)로 도구 레지스트리 인프라가 진화하는 과정을 학습하는 지표가 됩니다 [45].
My Project Relevance: 소스에 관련 정보가 부족합니다.

Adjacent Topics

[[RAG (Retrieval-Augmented Generation)]]
- 확장 방향: 단순한 문맥 검색 및 텍스트 증강을 목표로 하는 수동적 RAG 시스템에서 나아가, MCP를 통한 외부 시스템 내 작업 '실행(Execution)' 및 양방향 상호작용으로 확장하는 방법론의 비교 연구 [46-50].
[[Agent-Computer Interface (ACI)]]
- 확장 방향: 도구 및 터미널 환경에 접근하는 언어 모델을 위해 인터페이스(오류 메시지 처리, 상태 표현, 반환 형식)를 하네스가 어떻게 최적화해야 하는지를 다루는 설계 원칙 [51, 52].

Last updated: 2026-05-01

10 KiB Raw Blame History