LabHub

블로그

Model Context Protocol(MCP) 레퍼런스 — AI를 외부 세계에 연결하는 열린 표준

2026-07-11 · 13 분 읽기 · #mcp#ai#agents#llm#protocol#integration

한국어English日本語中文

들어가며 — MCP는 무엇이고 무슨 문제를 푸는가

Model Context Protocol(MCP)은 공식 문서의 표현으로 "AI 애플리케이션을 외부 시스템에 연결하기 위한 오픈소스 표준"입니다. Claude나 ChatGPT 같은 애플리케이션이 로컬 파일·데이터베이스 같은 데이터 소스, 검색·계산기 같은 도구, 특화된 프롬프트 같은 워크플로에 붙도록 규격을 통일합니다. 문서는 이를 "AI 애플리케이션을 위한 USB-C 포트"에 비유합니다 — 케이블 규격이 하나로 통일되듯, 연결 방식을 하나로 통일한다는 뜻입니다.

왜 표준이 필요한가? 흔히 M×N 문제로 부릅니다. AI 애플리케이션이 M개, 붙이고 싶은 도구·데이터 소스가 N개면, 표준이 없을 때는 M×N개의 제각각인 통합을 손으로 만들어야 합니다. 공용 프로토콜이 하나 생기면 이 비용이 M+N으로 줄어듭니다 — 서버를 한 번 만들면 프로토콜을 지원하는 모든 클라이언트가 쓸 수 있고, 클라이언트도 프로토콜만 구현하면 모든 서버에 붙습니다. 문서의 표현으로 "한 번 만들어 어디에나 통합(build once, integrate everywhere)"입니다. MCP는 이 발상을 Language Server Protocol(LSP)에서 빌려왔다고 밝힙니다. LSP가 "에디터 × 언어" 조합을 표준 하나로 정리했듯, MCP는 "AI 앱 × 도구" 조합을 정리합니다.

MCP는 Anthropic이 2024년 11월에 공개·오픈소스화했고, 초기에 Python·TypeScript SDK와 Google Drive·Slack·GitHub·Git·Postgres·Puppeteer용 서버를 함께 냈습니다. 이후 OpenAI와 Google DeepMind도 채택하면서 사실상 업계 표준이 되었습니다.

아키텍처 — 호스트·클라이언트·서버, 그리고 전송

MCP는 클라이언트-서버 구조이고, 참여자는 셋으로 정의됩니다:

핵심 규칙은 서버 하나당 클라이언트 하나입니다. 호스트는 붙는 서버마다 전용 클라이언트를 만들어 각자 독립된 연결을 유지합니다. VS Code가 파일시스템 서버와 Sentry 서버에 붙으면 내부적으로 클라이언트 객체가 둘 생기는 식입니다.

프로토콜은 두 계층입니다. 데이터 계층(data layer)은 JSON-RPC 2.0 기반 교환 규격으로 생명주기 관리와 프리미티브(도구·리소스·프롬프트·알림)를 정의하고, 전송 계층(transport layer)은 실제 통신 채널과 인증을 다룹니다. 연결은 상태를 가지며(stateful), 클라이언트가 initialize 요청으로 protocolVersion과 서로의 능력(capabilities)을 협상한 뒤 notifications/initialized로 준비 완료를 알리며 시작합니다.

전송은 둘입니다:

같은 JSON-RPC 메시지가 어느 전송에서도 그대로 통하도록, 전송 계층은 통신 세부를 프로토콜에서 분리합니다.

세 가지 프리미티브 — 도구, 리소스, 프롬프트

프리미티브는 MCP에서 가장 중요한 개념이고, 서버가 노출하는 세 가지가 핵심입니다. 각각 "누가 주도하는가"가 다릅니다:

리소스 URI는 고정형(직접 리소스)과 파라미터형(템플릿) 두 갈래입니다(설명용):

file:///Users/me/notes.md          # 직접 리소스 (고정 URI)
calendar://events/2026             # 직접 리소스
weather://forecast/{city}/{date}   # 리소스 템플릿 (파라미터)

발견은 */list, 조회는 */get, 실행은 tools/call이라는 규칙적 패턴을 따릅니다. 목록은 동적이라, 서버의 도구가 바뀌면 notifications/tools/list_changed 같은 알림으로 클라이언트에 알릴 수 있습니다.

반대로 클라이언트가 서버에 노출하는 프리미티브도 있습니다:

서버를 어떻게 만들 것인가

서버 만들기의 본질은 "무엇을 도구로, 무엇을 리소스로, 무엇을 프롬프트로 노출할지"를 정하는 일입니다. 행동은 도구, 읽을 컨텍스트는 리소스, 정형 워크플로는 프롬프트로 나눕니다. 공식 SDK는 TypeScript·Python·C#·Go(Tier 1), Java·Rust(Tier 2), Swift·Ruby·PHP·Kotlin(Tier 3)이 있고, 모두 같은 기능을 언어 관용구에 맞춰 제공합니다. 세부 API는 SDK마다 다르니 언어별 문서를 봐야 합니다.

도구 정의는 이름·설명·입력 스키마로 이뤄집니다. 공식 문서의 예시 형태(설명용):

{
  "name": "searchFlights",
  "description": "Search for available flights",
  "inputSchema": {
    "type": "object",
    "properties": {
      "origin": { "type": "string", "description": "Departure city" },
      "destination": { "type": "string", "description": "Arrival city" }
    },
    "required": ["origin", "destination"]
  }
}

클라이언트는 먼저 tools/list로 이 정의를 받아 LLM에 등록하고, 모델이 도구를 고르면 tools/call로 실행합니다. 실제 오가는 JSON-RPC는 이런 모양입니다(설명용):

{ "jsonrpc": "2.0", "id": 3, "method": "tools/call",
  "params": { "name": "weather_current",
              "arguments": { "location": "San Francisco", "units": "imperial" } } }

응답은 content 배열로 돌아오며 텍스트·이미지·리소스 같은 여러 형식을 담을 수 있습니다. 개발·디버깅에는 공식 MCP Inspector와 레퍼런스 서버 모음이 출발점으로 좋습니다.

트레이드오프와 성숙도 — 솔직한 정리

MCP의 매력은 명확합니다. 통합을 한 번만 만들면 되고, LSP처럼 생태계 전체가 같은 규격을 공유합니다. 다만 냉정히 볼 지점도 있습니다.

마치며

MCP의 핵심은 화려한 신기술이 아니라 "지루한 표준화"이고, 바로 그 점이 가치입니다. 도구·리소스·프롬프트라는 세 프리미티브와 JSON-RPC라는 얇은 규격만 이해하면, 어떤 클라이언트든 어떤 서버든 같은 방식으로 붙습니다. 에이전트를 실제 시스템에 연결하려는 엔지니어라면, 프레임워크를 고르기 전에 이 프로토콜 한 겹을 이해해 두는 편이 오래 남습니다.

참고 자료

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다