Lab 05. MCP 이론 심화

• 왜 MCP 인가: LLM 의 한계와 USB-C 비유로 본 표준화의 가치
• 구성 요소: Host · Client · Server 의 역할과 비유
• 작동 원리: 모델이 도구를 부르고(tool call) 결과를 받아 답하기까지
• 통신 방식: JSON-RPC 와 전송(stdio / http)
• MCP vs 일반 API: 무엇이 다른가
• 활용 사례 · scope · 보안: 어디에 쓰고, 어디에 저장하고, 무엇을 조심하나

MCP(Model Context Protocol) 는 LLM 애플리케이션이 외부 시스템(데이터·도구)과 표준화된 방식으로 상호작용하도록 설계된 개방형 프로토콜입니다. Anthropic 이 2024년 11월 공개했고, 다양한 기기를 하나의 포트로 잇는 USB-C 에 비유됩니다.

왜 필요할까요? LLM 단독으로는 한계가 분명합니다.

플랫폼마다 제각각이던 플러그인 방식은 오히려 혼란을 키웠고, MCP 는 이를 하나의 표준으로 정리합니다. 연결할 도구가 늘수록 개별 통합은 폭발합니다 — 호스트 M개 × 서비스 N개 = M×N 개의 일회용 연결. MCP 는 그 사이에 표준 어댑터를 끼워 M+N 으로 줄입니다.

한 줄: MCP ≈ RAG(외부 지식 검색) + 도구 실행(API·DB·파일) + 표준화. 셋을 한 규격으로 묶은 것.

표준이 주는 가치는 네 가지로 요약됩니다.

MCP 는 세 역할로 구성됩니다. USB 에 빗대면 직관적입니다.

Host 는 서버마다 클라이언트를 하나씩 두고, 각 서버가 외부 시스템과 이야기합니다.

graph TD
H["Host — Claude Code (LLM + 오케스트레이터)"]
H --> C1["Client A"]
H --> C2["Client B"]
C1 --> S1["Server: Playwright"]
C2 --> S2["Server: PostgreSQL"]
S1 --> E1["브라우저"]
S2 --> E2["데이터베이스"]

한 문장으로 요약하면 이렇습니다.

Model generates ‘tool call’ → Host executes → Model receives result → Model answers 모델이 도구 호출을 만들고 → 호스트가 실행하고 → 모델이 결과를 받아 → 모델이 답한다.

기본 작동 흐름 5단계

1. 요청 생성 — 모델(호스트)이 특정 정보·기능에 대한 요청을 생성
2. 요청 전송 — MCP 클라이언트가 이 요청을 표준 형식으로 변환해 서버로 전송
3. 요청 처리 — 서버가 요청을 해석하고 필요한 외부 데이터·도구에 접근
4. 응답 반환 — 처리 결과를 서버가 표준 형식으로 클라이언트에 반환
5. 응답 활용 — 모델이 받은 정보를 종합해 사용자에게 최종 답변

시나리오: 실시간 날씨 질문

1. 사용자가 “이번 주 서울 날씨를 알려줘”라고 질문
2. LLM 이 입력을 해석하고 어떤 Tool 이 필요한지 판단
3. 그 Tool 을 어떻게 호출할지 결정 — 예: "이번 주 서울 날씨를 알려줘" → weather_api.getForecast(location="Seoul", range=7)
4. LLM 의 Tool 호출 요청이 오케스트레이션 레이어를 거쳐 MCP 클라이언트로 전달
5. 지정된 Tool(MCP Server)에 HTTP 등으로 요청 전달 (예: 기상청 API)
6. 서버 응답을 클라이언트가 받아 다시 LLM 으로 반환
7. LLM 이 종합해 “이번 주 서울 평균 기온은 24도이고, 수요일에 강한 비가 올 예정입니다” 라고 답변

sequenceDiagram
  participant User as 사용자
  participant Host as Host
  participant Client as Client
  participant Server as Server
  User->>Host: "이번 주 서울 날씨 알려줘"
  Note right of Host: 모델이 입력 해석 → Tool 선택 + Input 생성
  Host->>Client: tool 호출 전달 (weather_api.getForecast)
  Client->>Server: 표준 요청 전송 (HTTP 등)
  Server-->>Client: 날씨 데이터 응답
  Client-->>Host: Tool 응답 전달
  Host-->>User: 자연어로 종합 답변

MCP 메시지는 JSON-RPC 2.0 형식입니다. 클라이언트가 서버에 “어떤 도구가 있니”(tools/list), “이 도구 실행해”(tools/call) 같은 요청을 보내고 서버가 응답합니다. 대체로 JSON 으로 주고받아 웹 시스템과의 호환성이 높습니다.

요청

{
  "action": "get_weather",
  "parameters": { "location": "Seoul", "units": "metric" }
}

응답

{
  "status": "success",
  "data": { "temperature": 25, "conditions": "Sunny", "humidity": 60 }
}

전송 방식은 두 가지입니다.

서버가 노출하는 것은 크게 세 가지: Tools(실행 가능한 동작), Resources(읽을 수 있는 데이터), Prompts(미리 만든 프롬프트).

한 줄: API 가 “각자 말이 다른 외국어들” 이라면, MCP 는 “공용어” 입니다.

• 정보 검색·최신화 — 검색 엔진 통합, DB 쿼리, 뉴스·주가·날씨 같은 실시간 업데이트
• 외부 도구·서비스 — 코드 실행, 이미지 생성, 문서 변환(PDF 파싱·요약·번역), 수학 계산
• 기업 시스템 통합 — CRM·ERP 연동, 내부 지식베이스 접근, 이메일·일정 등 업무 자동화
• 개인화 서비스 — 일정 관리, 웨어러블 건강 데이터, 개인 금융 조언

공통점: 모델이 모르거나 시시각각 바뀌는 정보를, 표준 통로로 그때그때 가져온다는 것.

claude mcp add 로 붙인 서버는 scope 에 따라 저장 위치와 공유 범위가 다릅니다.

원칙: 자격증명이 들어가는 서버는 local 또는 user 로. project 의 .mcp.json 은 커밋되므로 비밀값을 넣으면 유출됩니다.

MCP 는 강력하지만, 프로토콜 자체에 기본 인증이 없습니다. 그래서 무엇을 연결하느냐만큼 어떤 권한으로 연결하느냐가 중요합니다.

• 읽기 전용 우선: 쓰기가 필요 없으면 읽기 전용으로 (DB 는 Lab 06 에서 이중 방어)
• 최소 권한: 노출하는 도구를 꼭 필요한 것만
• 신뢰된 서버만: archived · 취약 이력이 있는 서버는 금지
• 간접 프롬프트 인젝션 주의: 외부 콘텐츠(웹·문서)가 지시문처럼 작동할 수 있음
• 비밀값은 local/user scope: .mcp.json 커밋 금지