MCP란 무엇인가? Model Context Protocol, JSON-RPC, AI Agent와 도구 호출 완전 가이드

MCP란: 모델이 아니라 도구 연결 프로토콜

최소 정의는 셋이다. Host(편집기 또는 Agent 프로세스), Client(Host 안에서 Server와 말하는 쪽), Server(도구·리소스·프롬프트를 내놓는 프로세스 또는 HTTPS 끝점). Client는 Server에 목록을 묻고 name, description, inputSchema를 모델 문맥에 넣은 뒤, 모델이 호출을 정하면 tools/call을 보낸다. MCP는 발견과 호출 모양을 맡는다. 모델이 어떻게 생각하는지는 보지 않는다.

「AI 플러그인」은 절반만 맞다. 브라우저 플러그인은 한 숙주에 매달린다. MCP Server는 여러 Client가 재사용할 수 있다. 같은 청구서 검색을 Cursor, Claude Desktop, 자체 편성기에 줄 수 있다. 차이는 「함수를 부를 수 있나」가 아니라 목록과 호출 봉투가 표준인가이다. 자체 OpenAPI 어댑터로도 HTTP는 부를 수 있다. Client가 늘면 어댑터를 다시 쓴다. MCP는 그 층을 프로토콜로 접는다. 공식 개념과 명세는Model Context Protocol 문서.

시간선에서는 Anthropic이 2024년에 MCP를 오픈소스화했고, 2025년 말 Linux Foundation의 Agentic AI Foundation(AAIF)으로 들어갔다. 2026년 Host들은 데모가 아니라 기본 원격 도구 통로로 다룬다. 프로토콜 버전은 요청 _meta에 나온다. 2026-07-28은 「양쪽이 이 의미에 합의했다」이지 「모델이 똑똑해졌다」가 아니다. 챗봇·예약 워크플로와의 차이는AI Agent란 무엇인가에 있다. 루프도 검증 가능한 인자 모양도 없으면 채팅이다. 루프가 있어도 도구가 로컬 함수면 Agent일 수는 있으나 표준 원격 목록은 없다.

JSON-RPC 2.0: 왜 이 봉투인가

MCP는 새 RPC를 만들지 않았다. 각 프로토콜 동작을 JSON-RPC 2.0 봉투에 넣는다. jsonrpc, id, method, params, 또는 error. 요청과 응답은 같은 id로 맞춘다. 알림은 id가 없어도 된다. 게이트웨이와 로그에는 맞춤 스트림 프레임보다 분해하기 쉽다. 먼저 method, 다음 업무. 필드 약속은JSON-RPC 2.0 명세.

method는 프로토콜 동사지 업무 함수 이름이 아니다. tools/list가 목록, tools/call이 호출, resources/read가 자원이다. 업무 이름은 params.name, 인자는 params.arguments. searchInvoices를 method에 쓰는 것은 흔한 오독이다. 그것은 자체 JSON-RPC 서비스이지 MCP가 아니다. 표준 목록 요청은 아래와 같다.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

봉투가 푸는 것은 셋이다. 다중화(여러 id 병렬), 오류 분류(parse 실패, 없는 메서드, 업무 거부), 전송 교체(stdio 자식 프로세스와 Streamable HTTP가 같은 JSON). arguments가 맞는지는 풀지 않는다. 적법한 JSON-RPC여도 필드가 빠진 arguments를 Server에 넘길 수 있다. Server는 스스로 parse하고 inputSchema로 검증해야 한다.

AI Agent가 MCP를 쓰는 흐름: 발견 → 선택 → 호출

데모 영상의 「지능」을 벗기면 MCP를 붙인 Agent 루프는 여전히 다섯 단계다. 바뀌는 것은 2단계와 4단계가 로컬 함수에 묶이지 않는다는 점이다.

1. 사용자 목표가 문맥에 들어간다(자연어 + 선택적 시스템 제약).
2. Client가 연결된 MCP Server에 tools/list를 보내고, 돌아온 목록을 모델이 읽을 tools / functions로 바꾼다.
3. 모델이 tool_calls(함수와 arguments) 또는 최종 텍스트 / Structured Output을 반환한다.
4. 런타임이 arguments를 JSON.parse한 뒤 MCP tools/call을 보내고 result를 메시지에 쓴다.
5. 모델이 결과를 보고 다음 도구 또는 종료를 고른다. maxSteps, 사용자 취소, Schema 실패도 멈춘다.

4단계 MCP 요청은 아래와 같다. params.arguments는 이미 객체이지 문자열이 아니다. 프로토콜 버전은 _meta에 걸어 무상태 라우팅이 읽을 수 있게 한다.

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "searchInvoices",
    "arguments": {
      "startDate": "2026-01-01",
      "endDate": "2026-01-31",
      "status": "paid"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28"
    }
  }
}

Agent 정의는 MCP에 의존하지 않는다. 로컬 함수, OpenAPI, 자체 HTTP도 도구가 된다. MCP의 가치는 한 Server를 여러 Host가 발견하고, 원격에서도 목록과 호출 모양이 같다는 것이다. 도입 기준은 「두 번째 Client가 이 도구 묶음을 재사용할까」이지 「2026처럼 보이는가」가 아니다. 루프의 공학 정의는AI Agent 동작 원리.

모델 도구 호출: tool_calls와 tools/call

공학적으로 Tool Calling과 Function Calling은 같은 메커니즘이다. 모델은 데이터베이스를 건드리지 않고 「이 함수를 이 인자로 호출하라」는 구조화 요청을 낸다. MCP는 다음 홉이다. 런타임이 그 요청을 JSON-RPC tools/call로 옮긴다. 두 홉의 필드명은 자주 섞인다.

모델이 호출할 때 전형적인 tool_calls는 아래와 같다. arguments는 여전히 문자열이다. 런타임은 먼저 parse한 뒤 객체를 MCP params.arguments에 넣어야 한다. 문자열을 JSON-RPC에 그대로 넣지 마라. 「arguments라는 이름의 문자열 필드」가 되어 Server Schema 검증이 바로 실패한다.

{
  "id": "call_8f3a",
  "type": "function",
  "function": {
    "name": "searchInvoices",
    "arguments": "{\"startDate\":\"2026-01-01\",\"endDate\":\"2026-01-31\",\"status\":\"paid\"}"
  }
}

각사 껍질은 다르다. OpenAI는 tools[].function.parameters, Anthropic은 input_schema, Gemini는 function_declarations. MCP는 Tool.inputSchema. 이름은 달라도 canonical Schema는 하나여야 한다. 필드 맞추기와 strict에서 모든 property를 required에 넣는 이유는MCP와 JSON Schema. 최종 답은 Structured Output으로. 도구 입력과 파일을 공유하지 마라.

2026 지도: 로컬, 원격, 무상태, A2A

전송은 두 갈래다. 로컬 stdio는 Host가 자식 프로세스를 띄우고 표준 입출력으로 JSON-RPC를 실어 나른다. 로컬 파일·로컬 DB에 맞다. 원격 Streamable HTTP는 같은 봉투를 HTTPS 끝점에 POST한다. 공유 청구서, 티켓, 내부 API에 맞다. 원격은 더 이상 「먼저 핸드셰이크 후 Session ID」에 묶이지 않는다. 2026-07-28 무렵 요청은 되도록 자기 기술이고, 게이트웨이가 method로 제한할 수 있다.

무상태는 프로토콜 층이다. 아무 인스턴스나 아무 요청을 받을 수 있다. 앱 층에는 여전히 데이터베이스, 멱등 키, 사용자 신원이 있다. 「프로토콜이 무상태니 도구 검증은 필요 없다」는 반대다. 세션 캐시가 없으면 이전 턴 tools/list가 살아 있다고 가정하면 안 된다. 낡은 목록은 잘못된 모양을 tools/call에 쓴다. 프로토콜은무상태 MCP와 JSON-RPC.

MCP는 다중 Agent 프로토콜도 아니다. 기획자가 가격·컴플라이언스·물류 Agent에 넘기는 것은 A2A message/send이지 tools/call이 아니다. 각 전문 Agent 내부는 여전히 MCP로 자기 DB를 부를 수 있다. 프로토콜 전쟁이라는 틀은 대개 틀렸다. 한 층은 도구, 한 층은 Agent. 대조는A2A vs MCP. 명세와 구현은MCP GitHub에 있다. 버전 변경은 명세 저장소를 믿고, 한 Host 블로그만 베끼지 마라.

현장 검증과 JSONVue

각 홉은 세 단계. parse → Schema → 업무 규칙. MCP 봉투가 적법해도 arguments가 적법한 것은 아니다. 똑똑한 모델도 이 셋을 대체하지 않는다.

1. 모델 arguments 문자열 JSON.parse. 실패면 raw와 tool_call id를 남기고 재시도 가능한 오류 봉투를 반환. 아직 하류를 치지 마라.
2. inputSchema / parameters로 Draft 2020-12 검증. path와 keyword를 낸다.
3. 업무 게이트: 날짜 범위, 열거와 권한, 외래 키. 통과한 뒤에만 Server가 하류 API를 친다.

세 JSON을 나란히 둔다. 모델 arguments, MCP로 보낸 params.arguments, Server가 실제로 쓴 객체. 모양이 다르면 거의 어댑터 층. 브라우저에서JSON 포맷터로 parse 확인,JSON Schema 검증으로 arguments와 Schema,JSON Diff로 모델 arguments와 MCP / HTTP body를 비교. valid / missing-field / wrong-enum 픽스처를 CI와 수동 점검이 공유한다.

더 읽기: AI Agent란, MCP와 JSON Schema, 무상태 MCP, A2A vs MCP.

자주 묻는 질문

요약과 다음 단계

2026 MCP는 한 줄이다. JSON-RPC로 도구를 발견·호출하고 결과를 모델 문맥에 되돌린다. 모델이 아니고, Agent가 아니며, A2A도 아니다. Tool Calling은 모델이 함수를 고르는 층, MCP는 런타임이 원격 도구를 찾아 부르는 층, JSON Schema는 각 홉의 모양을 적는다.

다음은 구체적이다. 시스템의 세 JSON(모델 arguments, MCP params.arguments, 하류 body)이 같은 Schema인지 확인하고 JSONVue에서 valid / 필드 누락 / 잘못된 열거를 재생한다. 프로토콜은 무상태 MCP, 필드 맞춤은 Schema 글, 다중 Agent는 A2A 대조.