Model Context Protocol (MCP)

이승준·2025년 4월 15일

MCP 는 AI 계의 USB

다양한 기기를 표준화된 방식으로 연결하는 USB 처럼, OpenAI 에서 선보인 MCP는 LLM에 전달하는 외부 API의 규격화된 프로토콜을 제공한다. 이 프로토콜은 GitHub Repo 에 SDK 형태로 제공되어, 누구나 MCP 서버나 클라이언트를 쉽게 구현할 수 있다.

사실 LLM 과 외부 도구를 연결하는 방법은 이전에도 많았다. 하지만 각 서비스마다 API 구조가 다르고, 인증 방식이 달라 통합하는 과정이 복잡했다. MCP 는 규격화된 프로토콜을 통해 누구나 동일한 방식으로 API를 구현하고 연결할 수 있게 만들어 이 불편함을 해소한 것이다.

Function Call

LLM이 답변을 생성하기 위해 외부 함수(API) 를 직접 호출하도록 설계된 메커니즘을 말한다. LLM 자신만으로는 정확한 정보를 생성하기 어렵거나 외부 시스템에 접근이 필요한 질문에 대한 대답을 생성할 때 사용된다. 외부 시스템에는 데이터베이스, API 등이 있다.
이런 질문을 받았을 때 LLM 은 적절한 함수를 선택하고 필요한 파라미터를 추론한 뒤, 함수를 호출해 얻은 결과를 이용해 답변을 생성한다.
자세한 내용은 https://velog.io/@lsjdg/Function-Call 를 참고하면 된다.
MCP 는 결국 Function Call 을 가능하도록 하는 프로토콜을 정의하는 것이다. 이제 본격적으로 MCP 에 대해 알아보자.

MCP Server

MCP server는 사용할 수 있는 툴들의 API 명세서를 제공하고, 게이트웨이 역할을 한다. 모든 통신은 JSON-RPC 형식을 이용한다.

JSON-RPC

RPC는 네트워크를 통해 원격 시스템의 함수를 마치 로컬 함수처럼 호출할 수 있도록 해주는 개념이다. 함수를 호출하면 원격 서버에 요청이 가고, 응답으로 함수의 리턴값을 받는 것이다.
JSON-RPC 는 클라이언트가 서버에 JSON 형식의 요청을 보내고, 서버는 요청을 처리하고 마찬가지로 JSON 형태로 응답을 보내는 것이다.

# request
{
  "jsonrpc": "2.0",
  "id": "unique-request-id",
  "method": "메서드 이름",
  "params": { # params }
}

# reply
{
  "jsonrpc": "2.0",
  "id": "unique-request-id",
  "result": { # results }
}

MCP 는 이 방식을 사용해 tools/list (사용 가능한 도구 목록 요청), tools/call (도구 실행의 결과 반환)등의 표준화된 메서드를 정의하고, 이를 통해 클라이언트와 서버는 일관된 방식으로 통신할 수 있다.
공식 SDK(https://modelcontextprotocol.io/introduction)를 사용하면 쉽게 구현할 수 있다.
MCP 의 대표적인 메서드들을 알아보자

tools/list
tools/list 는 MCP 서버에서 사용 가능한 도구 목록을 조회할 때 사용하는 메서드다. 여기서 말하는 도구 (tool) 은 Function Call 에서 등장한 것과 같은 개념이다. 요청과 응답 형식은 다음과 같다.

# request
{
  "jsonrpc": "2.0",
  "id": "request-123",
  "method": "tools/list"
}

# reply
{
  "jsonrpc": "2.0",
  "id": "request-123",
  "result": {
    "tools": [
      {
        "name": "readFile",
        "description": "파일 내용을 읽어옵니다",
        "inputSchema": {
          "type": "object",
          "properties": {
            "path": {
              "type": "string",
              "description": "파일 경로"
            }
          },
          "required": ["path"]
        }
      },
      {
        "name": "searchWeb",
        "description": "웹에서 정보를 검색합니다",
        "inputSchema": {
          "type": "object",
          "properties": {
            "query": {
              "type": "string",
              "description": "검색 쿼리"
            },
            "limit": {
              "type": "number",
              "description": "최대 결과 수",
              "default": 5
            }
          },
          "required": ["query"]
        }
      }
    ]
  }
}

tools/call
tools/call 은 특정 도구를 호출할 때 사용하는 메서드다. 요청과 응답 형식은 다음과 같다:

# request
{
  "jsonrpc": "2.0",
  "id": "request-456",
  "method": "tools/call",
  "params": {
    "name": "searchWeb",
    "arguments": {
      "query": "최신 AI 기술 동향",
      "limit": 3
    }
  }
}

# reply
{
  "jsonrpc": "2.0",
  "id": "request-456",
  "result": {
    "content": [
      {
        "type": "text",
        "text": "최신 AI 기술 동향에 관한 검색 결과:\n1. 생성형 AI의 발전과 윤리적 고려사항\n2. 자율주행 기술의 최신 동향\n3. 의료 분야에서의 AI 활용 사례"
      }
    ]
  }
}

Transport Interface

LLM 이 MCP 서버와 통신하기 위한 표준화된 HTTP 기반 통신 경로를 의미한다. LLM은 REST API의 주소나 형식을 잘 모르기 때문에 표준 통신 방식인 JSON-RPC 를 사용해야 한다. Transport Interface 는 이걸 받아서 진짜 API 요청으로 바꿔준다. 그리고 다시 결과를 LLM이 이해할 수 있는 방식으로 바꿔서 반환한다.

Transport Interface는 LLM과 기존 API 사이를 연결해주는 통역사다.

Transport Interface 는 아래와 같이 TypeScript 로 구현된다.

interface Transport {
  // 통신 시작
  start(): Promise<void>;
  
  // JSON-RPC 메시지 전송 (요청 또는 응답)
  send(message: JSONRPCMessage): Promise<void>;
  
  // 연결 종료
  close(): Promise<void>;
  
  // 연결 종료 시 콜백
  onclose?: () => void;
  
  // 오류 발생 시 콜백
  onerror?: (error: Error) => void;
  
  // 메시지 수신 시 콜백
  onmessage?: (message: JSONRPCMessage) => void;
  
  // 세션 ID
  sessionId?: string;
}

여기서 MCP 의 핵심 가치가 드러난다. 기존에 존재하는 API나, 로컬 서비스, 또는 새로 구현한 서버 등 어떤 도구나 리소스든 Transport layer만 구현해놓으면, MCP client에서 정해진 메서드로 LLM Function Call에 필요한 내용들을 호출할 수 있다. 즉, "규격화"를 통해 LLM이 외부 세계와 상호작용하는 방식을 일관되게 만들어 주는 것이다. 개발자는 각 서비스마다 다른 방식의 함수 정의를 작성할 필요 없이, MCP 프로토콜만 따르면 된다. Function Call 만을 사용할 때는 각 API마다 고유한 함수 정의를 작성해야 했지만, MCP를 사용하면 모든 도구와 리소스에 단일한 인터페이스로 접근할 수 있다.

LLM Workflow

MCP 는 LLM 과 외부 API 를 연결하는 프로토콜만 제공할 뿐, LLM 자체는 포함하고 있지 않다. 즉, LLM과의 연결, 대화 관리, 그리고 실제 도구 호출의 로직은 모두 호스트 앱에서 직접 구현해야 한다.
즉, MCP는 도구를 표준화된 방식으로 노출하는 방법을 제공하지만, 그 도구를 언제, 어떻게 사용할지는 호스트 앱의 책임이다. 호스트 앱에서 해야 할 일은 대략적으로 다음과 같다.

MCP 클라이언트와 LLM 클라이언트를 모두 관리

MCP에서 도구 목록을 가져와 LLM에 전달

LLM의 도구 호출 요청을 감지하고 MCP로 전달

도구 호출 결과를 다시 LLM에 전달

최종 응답을 사용자에게 제공

LLM의 진정한 능력을 끌어내기 위해서는 호스트 앱에서 효과적인 LLM 워크플로우 설계가 필수적이다.

Agent to Agent (A2A)

Agent가 다른 Agent에게 작업을 위임하고 결과를 받아볼 수 있도록 하는 통신 방식이다. 하나의 Agent로 모든 일을 수행하는 것은 비효율적이고, 다양한 역할의 Agent들이 협력해 모듈화된 작업 처리 가능하다는 장점이 있어 사용한다.
MCP와의 가장 큰 차이점은 소통의 대상과 목적이다. A2A는 task 위임 및 결과 송수신을 위한 Agent 간 소통을 하고, MCP는 외부 정보 이용을 위해 시스템이나 tool과 소통한다.
결국 A2A는 각 Agent가 톡립적인 추론 과정을 통해 적합한 다른 Agent와의 협력을 하고, MCP는 하나의 Agent가 외부 리소스를 보조 수단으로 활용해 문제를 해결하는 것이다.

MCP Agent 의 보안 이슈

MCP는 외부 도구와의 통신을 위한 표준을 제공한다는 강점이 있지만, 그만큼 새로운 보안 위협의 부분들(Attack Surface)이 생겨난다.

Tool 오용 및 악성 호출

MCP는 여러 메서드를 통해 외부 리소스를 호출하는데, 잘못된 파라미터를 이용하거나 악의적인 호출이 일어나면 시스템이 위험해줄 수 있다.
readFile과 같이 어떤 툴이 시스템의 파일 시스템에 접근할 수 있을 때, 경로 검증이 없다면 중요한 파일에 접근해 손상시킬 수도 있다.
이를 방지하기 위해서는 각 툴의 inputSchema에 대한 validation을 반드시 수행하고, 권한 기반 접근 제어(ACL) 적용이 필요하다.

Hallucination 기반 오작동

LLM의 잘못된 판단으로 인해 치명적인 파라미터를 담은 요청이 실행될 수 있다. 일부 파일만 삭제해야 하는 상황에서

{
  "method": "tools/call",
  "params": {"name": "deleteAllFiles"}
}

와 같은 잘못된 호출을 시도할 수 있다.
이를 방지하기 위해 MCP 서버는 등록된 툴 목록만 호출 가능하도록 제한해야고, 의심스러운 요청에 대한 logging과 sandboxing이 필수다.

Transport Layer의 보안

MCP는 JSON-RPC 기반의 메시지를 전송하므로, Man in the Middle Attack 등으로 인한 메시지의 탈취나, 위변조 위험이 존재한다.일반적인 Man in the Middle에 대응책과 같이, Signature를 통한 Message Authentication을 통한 무결성 검증이 중요하다. HTTPS와 WebSocker을 이용한 방식을 사용하는 것도 권장된다.