앤트로픽 MCP(Model Context Protocol) 가이드: LLM 연동의 패러다임 변화

MCP 란 Model Context Protocol의 준말로 LLM에 외부에서 사용되는 Context를 쉽게 제공하기 위해 제안된 통신 프로토콜입니다.

최근 LLM(거대언어모델) 응용 프로그램 개발 분야에서 가장 뜨거운 화두는 “모델이 어떻게 외부 시스템의 데이터와 실시간으로 상호작용할 것인가”입니다.

오늘 리뷰할 Anthropic의 MCP 교육 과정은 이 난제를 해결할 혁신적인 표준 규격을 다루고 있습니다.

본 포스팅에서는 강의 내용을 바탕으로 MCP의 계층적 구조부터 실제 동작 매커니즘까지 전반적인 내용을 다루어 보도록 하겠습니다. 큰 그림을 이해하는 것이 중요합니다.

MCP의 본질: 왜 ‘통신 계층’의 프로토콜인가?

강의의 서두에서 강조하는 핵심은 MCP가 단순한 API 라이브러리가 아니라 통신 계층(Communication Layer)의 프로토콜 이라는 점입니다.
일반적으로 우리가 만드는 응용 프로그램은 애플리케이션 계층에서 비즈니스 로직을 처리합니다.

하지만 MCP는 그보다 아래 단계인 통신 계층에서 작동합니다.

이는 응용 프로그램이 직접 모든 데이터를 가공하는 것이 아니라, 정보를 제공하는 측과 받는 측 사이의 규격화된 약속을 통해 효율적으로 데이터를 주고받는다는 것을 의미합니다.

데이터와 교환과 가공이 같은 몸에 있는 소프트웨어 구조는 데이터 교환이 추가되는 경우 쉽게 확장되기 어렵습니다.

우리가 이야기하는 프로토콜(Protocol)은 중요합니다. 통신이 정확하게 이루어지기 위해서는 메세지의 형식과 순서가 약속되어 있기 때문입니다.

프로토콜은 상호 연동성을 가능하게 하여 손쉬운 기능확장을 가능하게 합니다.

MCP는 LLM과 외부 리소스 사이의 이 약속을 표준화하여 개발 효율성을 극대화합니다.

MCP의 3대 핵심 구성 요소와 역할

강의에 등장하는 구조도를 보면 시스템은 크게 세 가지 영역으로 구분됩니다. 각자의 역할을 명확히 이해하는 것이 MCP 학습의 첫걸음입니다.

Our Server (응용 프로그램 서버)

우리가 실제로 구현하고자 하는 메인 서비스입니다. LLM의 지능을 빌려 사용자에게 최종적인 가치를 제공하는 주체입니다. 이 서버 내부에는 MCP 서버와 대화하기 위한 MCP Client가 탑재됩니다.

MCP Client

LLM에게 현재 문제 해결에 필요한 문맥(Context)과 정보 접근 도구를 제공하는 역할을 합니다.

기존에는 이러한 도구들을 프롬프트에 일일이 수동으로 집어넣어야 했지만, MCP Client는 이를 자동화하고 표준화된 방식으로 처리합니다.

MCP Server

실질적인 데이터와 기능을 보유한 “보관소”입니다. MCP Server는 다음 세 가지 핵심 요소를 관리합니다.

Tool (도구): 외부 시스템에서 실행할 수 있는 구체적인 기능.
- 주로 다른 시스템에서 제공하는 서비스에 접근을 하기 위한 API라고 보시면 됩니다.
Resource (자원): 텍스트나 로그 등 모델이 참조할 수 있는 데이터.
- 이해를 쉽게하기 위하여 일반적인 문서라고 생각하는 것이 편합니다.
Prompt (프롬프트): 서버가 수행해야 할 특정 작업에 최적화된 사전 정의된 지시문.
- 이 부분이 MCP server개발에 가장 중요한 부분입니다.

기존 방식 vs MCP 방식: GitHub 연동 사례 분석

강의에서는 이해를 돕기 위해 ‘GitHub 프로젝트의 Pull Request(PR) 상태 조회’ 시나리오를 제시합니다. 이 비교를 통해 MCP의 진가를 알 수 있습니다.

기존의 개발 방식

명세 제공: 개발자가 GitHub API의 상세 명세를 분석하여 LLM에게 프롬프트로 전달합니다.
함수 구현: 서버 내부에는 GitHub와 통신하여 데이터를 가져올 Callback 함수들이 일일이 구현되어 있어야 합니다.
LLM의 역할: LLM은 프롬프트를 분석해 어떤 파라미터로 어떤 함수를 호출할지 결정해 텍스트로 반환합니다.
후처리: 서버는 이 텍스트를 다시 파싱(Parsing)하여 실제 함수를 실행합니다.
단점: 코드가 복잡해지고, 새로운 기능을 추가할 때마다 서버를 대대적으로 수정해야 합니다.

MCP 도입 후의 변화

MCP를 도입하면 GitHub 연동 로직을 별도의 MCP Server로 완전히 분리할 수 있습니다.
재사용성: 한 번 만든 GitHub MCP 서버는 다른 프로젝트에서도 그대로 가져다 쓸 수 있습니다.
부하 분산: 실행 로직이 별도 인스턴스로 분리되어 메인 서버의 부담이 줄어들고 구조가 단순해집니다.
확장성: 새로운 외부 시스템을 연결하고 싶다면 해당 MCP 서버만 추가하면 됩니다.

예제로 보는 MCP 서비스 전체 플로우 (Step-by-Step)

교육 자료에서 설명하는 전체 실행 과정을 11단계로 세분화하여 정리했습니다. 이 흐름을 이해하는 것이 MCP 기술의 핵심입니다.

사용자 쿼리: 사용자가 우리 서버에 질문을 던집니다. (예: “내 PR 상태가 어때?”)
Tool 발견 요청: 서버는 MCP 클라이언트에게 “현재 사용 가능한 도구가 무엇인지” 묻습니다.
MCP 통신(목록 확인): 클라이언트가 MCP 서버에 ListToolsRequest 메세지를 보내고 결과(ListToolsResult)를 받습니다.
LLM 요청: 우리 서버는 사용자의 질문과 함께 위에서 받은 ‘도구 목록’을 LLM에게 보냅니다.
LLM 추론: LLM은 “이 질문에 답하려면 Get_PR_Status라는 도구가 필요하겠군”이라고 판단하고 필요한 파라미터를 결정합니다.
도구 실행 요청: 서버는 다시 MCP 클라이언트에게 해당 도구 실행을 지시합니다.
외부 API 호출: MCP 서버가 실제로 GitHub API 등을 호출하여 데이터를 가져옵니다 (CallToolRequest).
결과 전송: 외부 시스템의 응답이 MCP 서버를 거쳐 클라이언트로 전달됩니다 (CallToolResult).
LLM에 결과 전달: 이제 실제 데이터(PR 정보)를 얻었으므로, 이를 다시 LLM에게 보내 최종 답변 작성을 요청합니다.
최종 답변 생성: LLM이 데이터를 바탕으로 자연스러운 답변을 생성합니다.
사용자 응답: 완성된 답변이 사용자에게 전달됩니다.

결론: MCP가 가져올 미래

LLM 입장에서 MCP는 ‘안경’이자 ‘손’과 같습니다. 복잡한 텍스트 처리 과정 없이도 구조화된 프롬프트를 통해 맥락을 정확히 파악(안경)할 수 있게 해주고, 미리 정의된 도구를 통해 외부 세계에서 직접 행동(손)할 수 있게 해주기 때문입니다.
개발자는 더 이상 외부 API 연동을 위한 노가다성 코드에 매달릴 필요가 없습니다. MCP라는 표준 규격 위에서 더 창의적이고 강력한 AI 에이전트를 설계하는 데 집중할 수 있게 되었습니다.

앤트로픽 MCP(Model Context Protocol) 가이드: LLM 연동의 패러다임 변화