AI VIDEO BRIEFING

MCP 모델 컨텍스트 프로토콜 입문: 서버·클라이언트 구조와 직접 만드는 법

AI 에이전트가 외부 도구와 데이터에 연결되도록 돕는 표준인 MCP를 KodeKloud 핸즈온 강의를 바탕으로 정리했다. 왜 필요한지, 서버의 세 구성요소와 JSON-RPC 통신, 직접 구축까지 차근차근 짚는다.

MCP(모델 컨텍스트 프로토콜) 입문: AI 에이전트가 외부 도구와 연결되는 표준 영상 대표 이미지

핵심 메시지

  • LLM은 텍스트나 이미지를 생성할 뿐 스스로 행동하지 못한다. 실제로 항공편을 검색·예약하는 등의 행동은 'AI 에이전트'가 도구를 통해 수행한다.
  • 수많은 외부 서비스는 API 규격이 제각각이라, 에이전트가 모든 연동 코드를 직접 짜야 하는 문제가 있었다.
  • MCP(모델 컨텍스트 프로토콜)는 AI가 제3자 플랫폼과 상호작용하는 방식을 표준화한 규약으로, 규격만 지키면 누구나 서버를 만들고 어떤 클라이언트든 그 서버를 쓸 수 있다.
  • MCP 서버는 도구(tools)·리소스(resources)·프롬프트(prompts) 세 가지를 노출하고, 클라이언트와 JSON-RPC로 통신하며 전송은 표준 입출력(stdio)이나 HTTP를 쓴다.
  • 커서·클로드 코드 같은 도구는 MCP 설정 파일만 가리키면 곧바로 서버에 연결되며, 직접 에이전트를 만들 땐 SDK로 클라이언트를 구현한다.

쉽게 이해하기

강의는 'AI는 왜 스스로 행동하지 못하는가'에서 출발한다. ChatGPT 같은 LLM에 '런던행 항공편을 예약해줘'라고 해도, LLM은 생성된 텍스트로만 답할 뿐 실제 예약을 수행하지 못한다. 항공 서비스에서 정보를 끌어와 선호도와 비교하고 결정을 내려 예약까지 하는 '행동'은 AI 에이전트의 몫이다. 에이전트는 외부 도구를 호출하고, 과거 대화 기억을 활용하며, LLM과 주고받으며 작업을 완수한다.

에이전트는 '도구(tool)'를 통해 외부 플랫폼과 연결된다. 그런데 항공사마다 API 엔드포인트와 응답 형식이 다르다. 어떤 곳은 'API/flights', 다른 곳은 'flights/list' 식이다. 수백 개 항공사와 수백만 개 사이트마다 연동 코드를 직접 작성하는 것은 비현실적이다. 이 지점을 해결하려고 등장한 것이 MCP다. MCP는 에이전트가 올바른 API를 고르고 외부 플랫폼과 상호작용하도록 '맥락'을 제공하는 안내자 역할을 한다.

MCP는 클라이언트-서버 구조를 따른다. 에이전트는 MCP 클라이언트로 서버에 접속하는데, 이 클라이언트는 커서·윈드서프·클로드 데스크톱 같은 코딩 도구에 내장된 경우가 많다. 예컨대 브라우저 MCP 서버는 콘솔 로그와 HTML 요소에 접근해 프런트엔드 문제 해결을 돕고, 데이터 엔지니어링에서는 읽기 전용 권한으로 여러 소스를 결합해 누락 데이터의 원인을 추적할 수 있다.

MCP 서버는 세 가지를 노출한다. 첫째 도구(tools)는 항공편 검색·예약 같은 '행동'으로, 각 도구는 설명과 입출력 스키마를 갖는다. 둘째 리소스(resources)는 공항 정보·환불 정책·FAQ처럼 결정을 돕는 데이터로 URI·이름·설명을 갖는다. 셋째 프롬프트(prompts)는 서버 개발자가 가장 잘 아는 '좋은 지시문'을 미리 정의해 둔 것이다. 통신은 JSON-RPC 2.0 형식을 쓰며, 메서드·파라미터·ID를 보내고 결과나 오류를 돌려받는다.

사용은 기존 서버를 쓰는 것부터 배운다. 커서 같은 IDE는 mcp.json 설정 파일에 서버 목록을 적으면, stdio 모드로 서버 인스턴스를 띄워 도구 목록을 받아 대화로 활용한다. 직접 만들 땐 파이썬의 FastMCP 라이브러리로 서버를 초기화하고, 함수에 @mcp.resource·@mcp.tool·@mcp.prompt 데코레이터를 붙여 각 구성요소를 정의한 뒤 전송 방식을 지정해 실행한다. 클라이언트 역시 FastMCP 클라이언트로 도구를 나열하고 호출하며, roots·sampling·elicitation 같은 기능으로 파일 접근 범위 지정, LLM 호출 위임, 사용자 추가 확인 요청을 처리한다.

주요 인사이트

  • MCP의 본질은 'M·C·P' 그대로다. 모델(LLM)에게 제3자에 대한 컨텍스트를 표준(프로토콜)에 맞춰 제공하는 것이며, 규격 준수가 상호운용성의 핵심이다.
  • 도구·리소스·프롬프트의 분리는 역할 분담을 명확히 한다. 행동은 도구, 참고 데이터는 리소스, 좋은 지시문은 서버 개발자가 정의한 프롬프트가 담당한다.
  • JSON-RPC는 의도적으로 단순하고 상태를 두지 않으며, 전송 계층(stdio·HTTP 등)은 분리돼 있다. MCP는 그중 stdio와 HTTP를 표준 전송으로 채택했다.
  • 원격 MCP 서버에 연결할 때는 인증·인가·데이터 프라이버시·신뢰성을 반드시 챙겨야 한다. 외부에 데이터를 보내는 만큼 책임도 커진다.
  • 클라이언트 측 기능인 sampling은 LLM 선택·토큰 한도 같은 통제권을 클라이언트가 쥐게 해, 서버를 가볍고 인프라와 분리된 상태로 유지하는 설계 원칙을 보여준다.

자주 묻는 질문

MCP는 왜 필요한가요?

AI 에이전트가 수많은 외부 서비스와 연동하려면 서비스마다 제각각인 API에 맞춘 코드를 일일이 작성해야 했습니다. MCP는 AI가 제3자 플랫폼과 상호작용하는 방식을 표준화해, 규격만 지키면 누구나 서버를 만들고 어떤 클라이언트든 그 서버를 사용할 수 있게 합니다.

MCP 서버가 노출하는 세 가지 구성요소는 무엇인가요?

도구(tools)는 항공편 검색·예약 같은 실제 행동으로 설명과 입출력 스키마를 갖습니다. 리소스(resources)는 공항 정보·환불 정책 같은 참고 데이터로 URI와 설명을 갖습니다. 프롬프트(prompts)는 서버 개발자가 미리 정의해 둔 좋은 지시문입니다.

MCP 클라이언트와 서버는 어떻게 통신하나요?

JSON-RPC 2.0 형식을 사용합니다. 클라이언트는 호출할 메서드와 파라미터, ID를 담은 JSON을 보내고 서버는 결과와 ID, 필요 시 오류 정보를 돌려줍니다. JSON-RPC 자체는 전송 방식을 규정하지 않으며, MCP는 표준 입출력(stdio)과 HTTP를 전송 수단으로 채택했습니다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식