MCP 프로토콜 심층 분석: Function Call에서 범용 도구 호출 표준까지

Model Context Protocol(약칭 MCP)은 Anthropic이 2024년 말 오픈 소스로 공개한 프로토콜로, 'AI의 외부 도구 호출'을 각 기업의 커스텀 인터페이스에서 USB-C와 같은 하나의 표준으로 통합하는 것을 목표로 합니다. 본문은 프로토콜의 원리에서 출발하여, MCP와 Function Call의 본질적인 차이점, 그리고 IHUI-AI 프로젝트에서의 MCP 클라이언트(Client) + 서버(Server) 양방향 구현에 대해 설명합니다.

1. MCP는 Function Call의 '업그레이드 버전'이 아니라 '프로토콜 계층'이다

많은 사람들이 MCP를 'Function Call의 차세대 버전'으로 비유하곤 하는데, 이는 오해입니다. Function Call은 **모델의 능력(Model Capability)**입니다. 즉, LLM이 JSON 한 단락을 출력하면 애플리케이션 계층에서 이를 실행하는 방식입니다. 반면 MCP는 **프로토콜 계층(Protocol Layer)**입니다. 이는 '도구가 어떻게 발견되는지, 어떻게 기술되는지, 어떻게 호출되는지, 어떻게 등록 해제되는지'를 규정하며, 구체적인 모델과 디커플링(Decoupling)되어 있습니다.

비유하자면, Function Call은 '플러그의 모양'이고, MCP는 'USB-C 프로토콜'입니다. 전자는 제조사마다 제각각이지만, 후자는 어떤 장치든 연결할 수 있게 해줍니다.

MCP의 세 가지 핵심 프리미티브(Primitives)

이 세 가지는 동일한 MCP server를 통해 노출되며, 클라이언트는 연결 시 코드에 고정(Hard-coding)하는 대신 listTools / listResources / listPrompts를 통해 동적으로 발견합니다.

2. 프로토콜 전송 계층: JSON-RPC 2.0 + 양방향 통신

MCP의 하단은 JSON-RPC 2.0을 기반으로 하며, 두 가지 전송 방식을 지원합니다:

• stdio: 서브 프로세스 모드로, client가 server를 실행하고 표준 입출력을 통해 JSON-RPC 메시지를 교환합니다.
• HTTP+SSE: 원격 모드로, server가 HTTP 엔드포인트를 노출하고 client는 SSE를 통해 푸시를 수신합니다.

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

...

핵심 설계는 프로토콜이 양방향(Bidirectional)이라는 점입니다. 즉, server가 능동적으로 notifications/progress를 통해 진행 상황을 푸시할 수 있고, client는 sampling을 요청하여 server 측의 LLM이 콘텐츠 생성을 돕도록 할 수 있습니다. 이러한 양방향 능력 덕분에 MCP는 단방향인 Function Call보다 '에이전트 간 통신 프로토콜(Agent-to-Agent Communication Protocol)'에 더 가깝습니다.

3. MCP vs Function Call: 4차원 비교

가장 결정적인 차이는 **재사용성(Reusability)**입니다. 당신이 'GitHub Issue 조회'를 위한 MCP server를 작성하면, MCP를 지원하는 모든 클라이언트(Claude Desktop, Cursor, IHUI-AI)가 코드 한 줄 수정 없이 즉시 사용할 수 있습니다.

4. IHUI-AI의 양방향 MCP 구현

IHUI-AI는 apps/ai-service에서 클라이언트와 서버 양측을 모두 구현했습니다:

4.1 MCP 클라이언트: 외부 server를 Agent에 연결하기

apps/ai-service는 LangGraph를 기반으로 Agent를 오케스트레이션하며, 매 대화가 시작될 때 다음 과정을 거칩니다:

1. 사용자가 활성화한 MCP server 목록을 로드합니다 (PostgreSQL에 저장됨).
2. 각 server에 대해 JSON-RPC 연결을 수립하고, tools/list를 호출하여 도구 목록을 가져옵니다.
3. 모든 도구의 inputSchema를 병합하여 LLM에 전달하며, LLM은 어떤 도구를 호출할지 결정합니다.
4. tool_call을 받으면 해당 server로 전달하여 실행하고, 그 결과를 대화 컨텍스트에 다시 채워 넣습니다.

4.2 MCP 서버: IHUI의 능력을 외부로 노출하기

IHUI 또한 스스로를 MCP server로 캡슐화하여 Claude Desktop / Cursor 등 외부 클라이언트에서 사용할 수 있도록 노출합니다:

@mcp.tool()
def search_knowledge_base(query: str, top_k: int = 5) -> list[dict]:
    """IHUI 지식 베이스에서 관련 문서 조각을 검색합니다"""
...

이렇게 하면 사용자가 Claude Desktop에서 "IHUI의 Agent X를 사용해 이 문서를 요약해줘"라고 입력했을 때, Claude는 앱을 전환할 필요 없이 MCP를 통해 IHUI server를 호출하게 됩니다.

5. 실전 경험: 가장 빠지기 쉬운 세 가지 함정

1. 도구(Tool) 수의 폭발: 하나의 server가 50개의 도구를 노출하면, LLM이 선택에 어려움을 겪습니다. 시나리오별로 여러 개의 server를 분리하여, 매번 관련 있는 것만 로드하는 방식을 권장합니다.
2. 엄격하지 않은 inputSchema: JSON Schema에서 required 항목을 누락하면, LLM이 빈 객체를 전달할 수 있습니다. 반드시 server 측에서 Zod를 사용하여 2차 검증을 수행해야 합니다.
3. stdio 모드의 프로세스 누수(Process Leak): client가 충돌한 후 server 자식 프로세스가 회수되지 않는 문제입니다. stdio server에 하트비트(Heartbeat)를 추가하여, 30초 동안 응답이 없으면 kill 하도록 설정하는 것을 권장합니다.

6. MCP의 미래: '도구 프로토콜'에서 'Agent 인터넷'으로

현재 MCP는 주로 "LLM ↔ 도구" 간의 연결 문제를 해결합니다. 하지만 MCP의 양방향 통신 설계는 본질적으로 "Agent ↔ Agent"에 적합합니다. 즉, 한 Agent가 자신을 MCP server로 노출하면, 다른 Agent가 이를 호출할 수 있게 됩니다.

IHUI-AI는 이 길을 시도하고 있습니다. 각 사용자가 생성한 Agent를 자동으로 MCP server로 등록하고, ihui://agents/{id} 리소스 URI를 통해 다른 Agent가 이를 발견하고 호출할 수 있도록 하여 "Agent 네트워크"를 형성하는 것입니다.

만약 여러분도 AI Agent 제품을 만들고 있다면, 지금 바로 도구 계층을 MCP로 전환하는 것이 좋습니다. 프로토콜 생태계가 성숙한 뒤에 전환하려면 코드를 전부 다시 작성해야 할 수도 있습니다.

관련 링크

• 프로젝트 저장소: https://github.com/IHUI-INF-AI/IHUI-AI
• 공식 웹사이트: https://ihui.ai
• MCP 공식 문서: https://modelcontextprotocol.io

이 글이 도움이 되었다면, GitHub에서 IHUI-AI에 Star ⭐를 눌러주세요. 또한 공식 웹사이트에서 MCP로 연결된 우리의 Agent 워크플로우를 직접 체험해 보시기 바랍니다.

SEO 키워드:
MCP, Model Context Protocol, AI 도구 통합, Anthropic MCP, MCP server, Function Call 비교, JSON-RPC, Agent 프로토콜