책쓰자. Part1 - 3 | AI Tech Blog

3장. MCP의 기본 구조

MCP(Model Context Protocol)는 생성형 AI가 단순히 텍스트를 생성하는 수준에서 벗어나, 외부 도구를 활용해 실질적인 작업을 수행하는 ‘실행 주체’로서의 역할을 가능하게 하는 구조적 기반이다. MCP는 특히 에이전트 기반 시스템에서 LLM이 단순 응답 생성이 아닌, 복잡한 태스크를 수행하는 데 필요한 일련의 실행 흐름을 스스로 계획하고 조율할 수 있도록 설계되었다. 이를 통해 LLM은 단순히 질문에 답변하는 존재가 아니라, 사용자의 목적을 이해하고 이를 달성하기 위해 외부 자원을 적절히 조합하는 ‘지능형 실행자’로 기능하게 된다.

기존 시스템에서는 개발자가 각 도구와 API를 직접 설계하고 호출해야 했기 때문에, 복잡한 작업일수록 많은 중간 연결 코드와 예외 처리가 필요했다. 반면 MCP는 LLM이 중심이 되어 도구를 자율적으로 선택하고 실행하며, 결과를 반영하는 전체 흐름을 담당한다. 사용자는 자연어로 의도를 전달하기만 하면 되고, 그 이후의 실행 계획 수립과 도구 호출은 LLM이 문맥 기반 추론을 통해 자동으로 수행한다.

이 과정은 세 가지 핵심 구성 요소인 Host, MCPClient, MCPServer의 유기적 연동으로 이루어진다. Host는 사용자 입력을 수신하고 응답을 전달하는 인터페이스 역할을 하며, MCPClient는 LLM과 MCPServer 간 통신을 중재하고 실행 흐름을 조율하는 중심 허브이다. MCPServer는 실제 도구를 실행하는 서버로, 다양한 기능을 JSON-RPC 기반으로 LLM에게 노출하며, 이를 통해 LLM이 외부 작업을 직접 수행할 수 있게 된다.

본 장에서는 이러한 구조가 실제로 어떻게 작동하는지 구체적인 흐름과 예제를 중심으로 설명하고, 각 구성 요소의 상호작용, 오류 처리 방식, 설계상의 철학까지 폭넓게 다룬다.

3.1 MCP 아키텍처 흐름

MCP(Model Context Protocol)는 단순한 API 호출 체계를 넘어, LLM이 문맥(Context)을 이해하고 적절한 도구(Tool)를 스스로 선택하여 실행하는 지능형 실행 구조를 제공한다. 기존의 절차적 프로그래밍이나 명시적 API 호출 방식과 달리, MCP는 사용자와 LLM 간의 자연어 인터페이스를 중심으로 복잡한 작업 흐름을 자동으로 조율하는 것이 핵심이다.

MCP는 대화형 시스템으로 설계되어 있으며, 매 인터랙션마다 LLM은 사용자의 요청을 해석하고, 현재 문맥과 사용 가능한 도구 목록을 기반으로 최적의 실행 경로를 결정한다. 이 과정은 단순한 명령 실행이 아니라, 의도 파악 → 도구 선택 → 입력값 구성 → 실행 → 결과 반영이라는 일련의 고도화된 프로세스를 포함한다.

MCP 아키텍처의 상세 실행 흐름

MCP의 기본 실행 흐름은 아래 표와 같이 단계별로 구성된다. 각 단계는 LLM과 MCP가 협력하여 사용자의 요청을 실행으로 변환하는 과정을 보여준다.

단계	주요 처리 과정	설명
1	사용자 입력 수신	사용자가 자연어로 목적을 표현 (예: “이 PDF 계약서를 요약해줘.”)
2	Host 입력 처리 및 MCPClient 호출	Host가 입력을 MCPClient로 전달, 세션 관리 수행
3	MCPTool 목록 확보	MCPClient가 MCPServer로부터 도구 목록(name, description, inputSchema) 수신
4	LLM의 문맥 기반 도구 선택	LLM이 사용자 발화와 문맥을 분석하여 최적의 도구 선택
5	입력값 자동 생성	선택된 도구의 inputSchema 기준으로 입력값 구성
6	JSON-RPC 메시지 생성 및 전송	MCPClient가 요청 메시지를 생성해 MCPServer로 전달
7	MCPServer에서 도구 실행	도구 실행 후 결과 또는 오류 반환
8	결과 수신 및 문맥 반영	결과를 LLM 컨텍스트에 통합
9	최종 응답 생성 및 사용자 전달	LLM이 자연어 응답 생성, Host를 통해 사용자에게 전달

MCP는 단일 작업을 넘어 다단계 질의응답, 조건 분기, 멀티툴 호출, 비동기 처리 등 복합 시나리오를 자연스럽게 처리할 수 있다.

예시:
“이 이미지를 분석해줘” → generate_docent_from_file_upload 호출 →
“여기가 어디인지 알아봐줘” → guess_location_from_image 호출 →
“그 지역 날씨 알려줘” → get_weather_by_location 호출

LLM은 각 단계 결과를 기억하며 실행 흐름을 이어간다.

통신 계층과 프로토콜의 역할

MCP는 JSON-RPC 2.0을 기반으로 다양한 트랜스포트 계층을 지원한다.

구분	stdio	SSE
특징	로컬 CLI, 빠른 실행	HTTP 기반, 실시간 스트리밍
사용 예	로컬 이미지 분석, 텍스트 요약	외부 API 호출, 진행 상황 표시
통신	stdin/stdout	HTTP POST + Event Stream

Stdio: 로컬 환경, 개발 및 테스트에 최적화
SSE: 실시간 피드백이 중요한 클라우드 서비스에 적합

JSON-RPC 명세: https://www.jsonrpc.org/specification

시퀀스 다이어그램으로 보는 MCP 흐름

User → Host → MCPClient → LLM
                               ↓
                      MCPTool 선택 및 입력 구성
                               ↓
                      MCPClient → MCPServer
                               ↓
                             실행 결과 수신
                               ↓
                      LLM 응답 생성 → Host → User

MCP 아키텍처는 단순 도구 호출을 넘어 대화 기반 실행 오케스트레이션을 지향한다. 사용자는 자연어로 요청만 하면 되고, 복잡한 실행 계획과 결과 통합은 LLM과 MCP가 자동으로 처리한다.

시스템 설계자는 복잡한 로직을 명시하지 않아도, 도구만 정의하면 LLM이 문맥에 맞춰 유연하게 활용할 수 있다.

구성요소	설명
호스트	사용자와 상호작용, 클라이언트 관리 및 데이터 흐름 조율
클라이언트	MCP 서버와 1:1 연결, 프로토콜 협상 및 메시지 라우팅
서버	도구·리소스·프롬프트 제공, 외부 기능 실행 주체
도구(Tools)	LLM이 실행 가능한 함수형 API
리소스(Resources)	읽기 전용 데이터 소스
프롬프트(Prompts)	도구/리소스 활용을 위한 템플릿
프로토콜 계층	메시지 프레이밍, 요청/응답 연결, 알림 처리
트랜스포트 계층	STDIO, HTTP, WebSocket 등 데이터 전송 방식
컨텍스트	세션 상태 및 문맥 정보
메시지	데이터 교환 단위(요청, 응답, 알림 등)

서버는 도구(Tools) 외에도 리소스(Resources), 프롬프트(Prompts)를 제공하여 LLM이 외부 기능을 최적화해 활용할 수 있도록 지원한다.

통신 계층은 JSON-RPC 기반으로 로컬부터 클라우드까지 유연하게 대응한다.

3.2 도구 호출의 실제 시나리오

MCP에서 가장 중요한 개념 중 하나는 LLM이 도구를 단순히 호출하는 것을 넘어서, 적절한 도구를 스스로 선택하고, 필요한 입력값을 구성하고, 결과를 받아 문맥에 반영하는 전체 실행 사이클을 자율적으로 수행한다는 점이다. 이 구조는 사용자가 복잡한 API 스펙을 몰라도 자연어만으로 원하는 작업을 수행할 수 있게 하며, LLM이 일종의 컨텍스트 중심 에이전트로 작동하게 한다. 아래는 이 구조가 실제로 어떻게 동작하는지를 보여주는 예시이다.

사례: 사용자가 이미지를 업로드하고 “이거 뭐야?”라고 질문한 경우

사용자는 Host의 대화 인터페이스를 통해 이미지를 업로드하고 자연어로 질문을 입력한다. 예: “이거 뭐야?”
Host는 입력을 수신하고, 내부적으로 MCPClient에 연결된 MCPServer에서 등록된 모든 도구 목록을 받아온다. 이 목록은 각 도구의 이름, 설명(description), 입력 스키마(inputSchema)를 포함한다.
LLM은 사용자 발화와 기존 대화 문맥, 도구 설명을 함께 고려하여 가장 적절한 도구를 선택한다. 예를 들어 generate_docent_from_file_upload 도구의 설명이 “이미지를 분석하여 그 내용을 설명합니다”라면, LLM은 이 도구가 현재 요청에 가장 적절하다고 판단한다.
도구의 입력 스키마를 기반으로, 필요한 인자를 자동 구성한다. 예를 들어 해당 도구가 file이라는 필드를 요구하고 있다면, LLM은 Host에서 받은 이미지 URL을 여기에 자동으로 삽입한다. 이 과정은 단순한 키-값 매핑이 아니라, 도구의 요구 조건과 사용자 입력을 결합한 추론 결과로 수행된다.
MCPClient는 LLM의 선택 결과를 바탕으로 JSON-RPC 요청을 구성하여 MCPServer에 전달한다. 이때 전송 계층은 상황에 따라 stdio 또는 SSE 방식이 사용된다. stdio는 CLI 기반 도구 실행에 적합하며, SSE는 HTTP 기반 도구 호출이나 스트리밍 응답에 활용된다.
MCPServer는 도구를 실행하고, JSON 형식의 결과를 반환한다. 예: { "description": "이 사진은 해변에서 노을을 배경으로 한 남성과 아이가 함께 걷고 있는 장면입니다." }
이 결과는 다시 LLM 호출의 컨텍스트에 통합된다. LLM은 해당 결과를 읽고, 사용자에게 자연스럽고 맥락에 맞는 문장으로 응답한다. 예: “사진은 노을지는 해변을 배경으로 아버지와 아이가 함께 걷고 있는 모습입니다.”
사용자가 이어서 “여기가 어디야?”라고 묻는다면, 이전 도구 결과를 참조한 후 guess_location_from_image와 같은 다른 도구를 선택할 수 있으며, 문맥 기반 추론은 연속된 실행 흐름으로 확장된다.

이러한 시나리오에서 핵심적인 MCP의 특징은 다음과 같다:

도구 선택의 자율성: 사용자는 명시적으로 어떤 도구를 선택하거나, 입력값을 구성할 필요가 없다. LLM이 사용자의 자연어 요청과 도구 목록의 설명을 바탕으로 적절한 도구를 선택한다.
입력 구성의 문맥 기반 자동화: 단순히 키-값 매핑이 아니라, 대화 흐름 속에서 등장한 정보, 사용자의 요청 의도, 도구의 요구조건 등을 종합하여 입력값을 구성한다. 예를 들어 이미지 업로드가 이루어진 후 사용자 요청이 “이거 요약해줘”라면, LLM은 generate_summary_from_image를 선택할 수도 있다.
응답의 자연스러운 통합: 도구 실행 결과는 LLM의 입력으로 자동 통합되며, 이 결과는 자연어 응답으로 재구성된다. 사용자는 도구 실행 결과를 별도로 확인하거나 분석할 필요 없이, LLM이 적절한 수준의 요약을 자동 제공한다.
후속 대화의 연결성 유지: LLM은 이전 도구 결과를 기억하고 후속 요청에 자연스럽게 활용할 수 있다. 예를 들어, 첫 응답이 이미지 설명이라면, 그 내용은 다음 도구 호출 시 컨텍스트로 활용될 수 있으며, 도구 체인 실행의 기반이 된다.

이 구조는 단일 요청-응답을 넘어서, 복합적인 사용자 요구에 대응하는 에이전트 흐름으로 확장될 수 있다. 예를 들어 “이 사진이 어디인지 알려줘 → 그 지역의 날씨는 어때? → 지금 여행 가기에 좋을까?”와 같은 일련의 대화가 이어지는 경우, LLM은 각 요청을 분석하여 연속적인 MCPTool 호출을 자동으로 구성하고 실행할 수 있다.

또한 이 흐름은 단일 도구가 아닌 복수 도구가 동시에 호출되는 경우에도 적용 가능하다. 예를 들어 사용자가 “이 이미지의 장소를 분석하고, 관련 뉴스를 요약해줘”라고 요청할 경우, LLM은 detect_location_from_image, search_news_by_location, summarize_articles와 같은 복수의 도구를 순차적으로 호출하고, 각 결과를 문맥에 맞게 통합해 최종 응답을 생성한다.

MCP는 이러한 구조를 통해, 단순한 function calling이나 스크립트 기반 체인 구성으로는 어려운 복잡한 사용자 요구에 유연하게 대응할 수 있다. 특히 멀티모달 입력 처리, 조건 분기, 사용자 의도 추론 등 고차원적 작업에 적합한 실행 모델로 설계되어 있으며, 사용자 입장에서는 단일 인터페이스만으로 복잡한 작업을 수행할 수 있다는 점에서 강력한 사용자 경험을 제공한다.

결국 MCP 기반의 도구 호출 시나리오는 단순히 기술적인 호출 패턴이 아니라, 언어 기반의 목적 추론과 실행 연결, 그리고 문맥 기반 결과 통합이라는 실행 철학을 바탕으로 한다. 이 점에서 MCP는 단순한 도구 호출 구조가 아니라, LLM을 중심으로 한 유연한 실행 플랫폼으로 자리 잡고 있다.

3.3 제어 흐름과 예외 처리 구조

MCP는 도구 선택과 실행의 주체를 LLM에게 위임함으로써 유연한 에이전트 실행 흐름을 가능하게 하지만, 동시에 예측 가능성과 시스템 안정성 확보를 위해 정교한 제어 메커니즘을 내장하고 있다. 이는 특히 운영 환경에서 사용자 요청이 모호하거나, 도구가 실패하거나, 입력이 누락되는 등 다양한 예외 상황을 다루기 위해 필수적인 설계이다. 다음은 MCP가 실제로 제공하는 주요 제어 흐름과 예외 처리 전략이다.

도구 선택 실패에 대한 대응

LLM이 사용자 발화를 정확히 해석하지 못하거나, 다의적 표현으로 인해 적절한 도구를 선택하지 못하는 경우가 종종 발생한다. 예를 들어, “이거 좀 봐줘”와 같이 모호한 요청은 문맥이 없으면 어떤 도구를 써야 할지 판단하기 어렵다. 이럴 때 MCPClient는 리프롬프트(re-prompt) 메시지를 삽입하여 도구 선택을 유도하거나, fallback 메시지를 통해 사용자와의 대화를 안전하게 복구한다. 리프롬프트는 “이미지 분석, 텍스트 요약, 번역 중 어떤 작업이 필요하신가요?”와 같이 도구 선택을 명확하게 유도하는 형태가 될 수 있으며, 이러한 대화 흐름은 사용자 만족도와 시스템 신뢰도를 동시에 높인다.

입력 누락과 구조화 검증

LLM이 도구를 선택하더라도, inputSchema 기반으로 요구되는 입력값을 정확히 구성하지 못하는 경우가 발생한다. 예를 들어 translate_text 도구가 source_language, target_language, text 세 가지 항목을 요구하는데, LLM이 두 개만 생성한다면 호출이 실패할 수 있다. 이를 방지하기 위해 MCPClient는 호출 직전에 JSON Schema 기반 유효성 검사를 수행하며, 누락된 필드가 감지되면 LLM에게 보완 발화를 삽입하거나, 미리 정의된 default 값을 사용해 자동 보완할 수 있다. 이 과정은 단순 오류 방지를 넘어, LLM이 일관된 입력 구조를 학습하도록 돕는 방향으로도 활용될 수 있다.

도구 실행 중 발생하는 예외 처리

MCPServer에서 실행되는 도구는 종종 외부 API나 파일 시스템, 네트워크에 의존하며, 이로 인해 예외가 발생할 수 있다. 예를 들어 파일 접근 권한 문제, API rate limit, 잘못된 포맷의 입력 등 다양한 원인으로 오류가 발생할 수 있다. MCP는 도구 실행 결과에 error 필드를 포함시켜 MCPClient로 반환하고, MCPClient는 이 오류 메시지를 LLM 문맥에 포함시켜 사용자에게 안내하도록 한다. 예: “업로드하신 PDF 파일을 열 수 없습니다. 다른 파일을 시도해 주세요.” 이처럼 시스템 내부 오류가 사용자 친화적인 메시지로 전달되면, 전체 시스템의 신뢰도는 크게 향상된다.

조건 분기 기반 흐름 제어

MCP는 단일 도구 호출에 그치지 않고, 이전 결과를 기반으로 다음 행동을 조건적으로 분기할 수 있는 흐름을 제공한다. 예를 들어 계약서 요약 도구를 호출한 뒤, “이 문서에 위약금 조항이 있나요?”라는 후속 질문이 이어질 경우, LLM은 요약 결과에서 “위약금”, “違約金” 등의 키워드를 확인한 후 check_penalty_clause 도구를 조건적으로 호출할 수 있다. 이 흐름은 단순한 chaining을 넘어서, 실제 reasoning과 branching을 포함하는 실행 플로우를 형성한다. 향후 planning 기반의 오케스트레이터와 결합될 경우 더욱 복잡한 논리 분기 처리도 가능해진다.

타임아웃, 재시도, 회복 전략

네트워크 지연이나 외부 API 불안정성 등으로 인해 도구 응답이 오지 않거나 시간이 오래 걸리는 경우, MCPClient는 타임아웃 정책과 재시도 전략을 함께 구성할 수 있다. 일반적으로 MCPServer는 실패 시 오류 코드 및 메시지를 반환하지만, 일부 툴은 예외를 반환하지 않고 응답 자체가 없을 수 있기 때문에, MCPClient는 일정 시간 동안 응답이 없을 경우 강제 중단하고 동일 요청을 재시도하거나, 사용자에게 에러 메시지를 보내는 방식으로 회복 시도를 진행할 수 있다. 이 과정은 retry 정책, backoff 전략, 대체 도구 사용 등 다양한 방식으로 확장 가능하다.

상태 기반 흐름 유도 및 컨텍스트 기억

MCP는 각 도구 호출과 LLM 응답 흐름을 하나의 일관된 세션 안에서 관리할 수 있도록 설계되어 있으며, 컨텍스트 기억 능력을 바탕으로 사용자의 복잡한 시나리오를 자연스럽게 이어갈 수 있다. 예를 들어 사용자가 이미지 분석 결과에 대해 “이걸 번역해줘”라고 후속 요청을 하면, LLM은 직전 도구 실행 결과에 포함된 텍스트 내용을 자동으로 가져와 번역 도구에 입력값으로 넘긴다. 이를 통해 사용자는 복잡한 설명 없이도 대화를 이어갈 수 있고, 시스템은 상태 기반 실행을 통해 복잡한 대화 흐름을 간결하게 유지한다.

운영 및 디버깅을 위한 리플레이 구조

실제 운영 환경에서는 사용자 이슈 재현이나 테스트를 위해 전체 대화 흐름을 리플레이할 수 있는 구조가 중요하다. MCP는 모든 사용자 입력, 선택된 도구, 호출된 입력값, 도구 출력, 최종 LLM 응답을 모두 로그 형태로 기록할 수 있으며, 이 기록은 테스트 케이스나 디버깅 자료로 재사용될 수 있다. 특히 리플레이 기반 테스트는 LLM 업그레이드나 도구 스펙 변경 시 시스템 일관성을 검증하는 데 유용하다.

이처럼 MCP는 단순한 도구 실행 인터페이스를 넘어서, LLM 중심의 실행 흐름을 안정적으로 제어할 수 있도록 설계된 실행 레이어를 제공한다. 이를 통해 사용자 경험은 더욱 직관적이고, 개발자는 더욱 유연하게 시스템을 설계하고 유지보수할 수 있게 된다. 궁극적으로 MCP는 에이전트 시스템의 안정성, 예측 가능성, 확장성을 함께 확보하는 실행 인프라로 기능하게 된다.

책쓰자. Part1 - 3

3장. MCP의 기본 구조

3.1 MCP 아키텍처 흐름

3.2 도구 호출의 실제 시나리오

3.3 제어 흐름과 예외 처리 구조

Tags

Navigation