2nd/00_Raw/Model Context Protocol (MCP).md

# [[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

### Related Concepts

#### [관계 유형 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*