n8n MCP Client Tool로 멀티 에이전트 파이프라인 구축하기
AI 에이전트 자동화를 위한 표준 프로토콜 실전 가이드
AI 에이전트가 하나의 도구만 사용하던 시대는 지나가고 있습니다. 실제 비즈니스 문제를 해결하려면 CRM, 티켓팅 시스템, 지식베이스를 동시에 넘나드는 에이전트가 필요하고, 그 에이전트들이 서로 협력하는 파이프라인이 필요합니다. 그런데 각 시스템마다 다른 API 명세를 직접 구현하다 보면 통합 코드가 비즈니스 로직보다 많아지는 역설에 빠지게 됩니다.
Anthropic이 2024년 말 발표한 Model Context Protocol(MCP) 과 n8n의 MCP Client Tool 노드 조합은 이 문제를 정면으로 해결합니다. 기존 OpenAI Function Call 방식이 모델 프로바이더마다 다른 도구 스키마를 각각 구현해야 했다면, MCP는 한 번 구현한 서버를 어떤 MCP 클라이언트에도 그대로 연결할 수 있는 공통 표준을 제공합니다. 이 글에서는 MCP의 핵심 원리부터 오케스트레이터-워커 패턴 구성, 컨텍스트 최적화 전략, 운영 시 주의사항까지 한 번에 파악할 수 있습니다. MCP Client Tool과 MCP Server Trigger는 2025년 4월 n8n 기본 내장 노드로 출시되었으므로, 해당 버전 이상의 n8n 인스턴스가 전제 조건입니다.
n8n을 처음 사용하신다면 n8n 공식 퀵스타트로 기본 워크플로 생성 방법을 먼저 확인하시는 것을 권장합니다. n8n 사용 경험이 있다면 바로 실전 적용 섹션으로 넘어가셔도 됩니다.
핵심 개념
MCP란 무엇인가 — USB-C 비유로 이해하기
USB-C가 다양한 기기를 하나의 커넥터로 연결하듯, MCP는 LLM과 외부 시스템 사이의 공통 인터페이스 역할을 합니다. 기존에는 각 도구마다 다른 통합 방식을 구현해야 했지만, MCP를 사용하면 서버 측에서 표준 방식으로 도구를 노출하고 클라이언트 측에서 일관된 방식으로 호출할 수 있습니다.
MCP(Model Context Protocol): AI 모델이 외부 도구·데이터 소스와 상호작용하는 방식을 통일한 개방형 표준 프로토콜. 클라이언트(에이전트)가 서버(외부 시스템)에 어떤 도구가 있는지 탐색하고, 선택해서 호출하는 전 과정을 표준화합니다.
MCP의 도구 탐색(discovery)은 구체적으로 클라이언트가 서버의 POST /mcp 엔드포인트로 {"method": "tools/list"} 요청을 보내고, 서버가 사용 가능한 도구 목록과 각 도구의 JSON Schema를 반환하는 방식으로 작동합니다. 백엔드 개발자라면 REST API의 OpenAPI 스펙 자동 탐색과 유사한 개념으로 이해할 수 있습니다.
MCP는 크게 두 역할로 나뉩니다.
| 역할 | n8n 노드 | AI Agent와의 관계 | 설명 |
|---|---|---|---|
| MCP 클라이언트 | MCP Client Tool 노드 | AI Agent 노드의 서브노드로 연결 | 에이전트가 외부 MCP 서버의 도구를 호출하는 채널 |
| MCP 서버 | MCP Server Trigger 노드 | 독립적인 진입점 (별도 워크플로) | n8n 워크플로 자체를 외부에 MCP 서버로 노출 |
이 두 노드의 조합으로 n8n은 양방향 MCP 허브가 됩니다. 외부 도구를 소비하는 동시에, 자신을 외부 AI 클라이언트(Claude Desktop, Cursor 등)에 도구로 제공할 수 있습니다.
멀티 에이전트 오케스트레이션 아키텍처
n8n에서 멀티 에이전트 파이프라인을 구성하는 핵심 패턴은 오케스트레이터-워커 구조입니다. MCP Client Tool은 AI Agent 노드 하단에 서브노드로 연결되며, 오케스트레이터가 여러 외부 시스템을 직접 호출하는 구조입니다.
[파이프라인 내부 흐름]
[사용자 입력]
│
▼
[오케스트레이터 AI Agent]
├──[MCP Client Tool] → MCP Server A (CRM)
├──[MCP Client Tool] → MCP Server B (Ticketing)
└──[MCP Client Tool] → MCP Server C (Knowledge Base)
│
▼
[최종 결과 반환][외부 노출 — 별도 독립 워크플로]
[MCP Server Trigger] ← 외부 AI 클라이언트 (Claude Desktop, Cursor 등)
│
└──[위 파이프라인 워크플로 실행]MCP Server Trigger는 파이프라인의 출력이 아니라 독립적인 진입점입니다. 완성된 파이프라인 워크플로를 외부에 단일 도구로 노출하고 싶을 때 별도 워크플로에 MCP Server Trigger를 두고 해당 파이프라인을 호출하는 방식으로 구성합니다.
- 오케스트레이터 에이전트: 사용자 요청을 받아 전체 태스크를 분해하고 적절한 워커에 위임합니다.
- 워커 에이전트: 특정 도메인(검색, DB 조회, 이메일 발송 등)에 전문화된 에이전트로, 오케스트레이터가 도구처럼 호출합니다.
- MCP Client Tool 노드: AI Agent 노드의 서브노드로 연결되어 런타임에 MCP 서버의 도구 목록을 자동 탐색(discover)하고 호출합니다.
트랜스포트 방식 — HTTP Streamable vs SSE
2025년 3월 26일 MCP 스펙 업데이트(v2025-03-26)를 기점으로 트랜스포트 방식에 중요한 변화가 있었습니다.
| 방식 | 상태 | 비고 |
|---|---|---|
| HTTP Streamable | 공식 권장 | n8n PR #15454로 지원 추가 |
| SSE(Server-Sent Events) | Deprecated | 레거시 환경 호환용으로만 사용 |
| STDIO | 내장 미지원 | 커뮤니티 노드(n8n-nodes-mcp) 필요 |
HTTP Streamable(Streamable HTTP): 기존 SSE가 서버→클라이언트 단방향 스트리밍에 의존했던 한계를 개선해, 표준 HTTP 위에서 양방향 스트리밍을 지원하는 트랜스포트 방식입니다. 프록시·로드밸런서 환경에서 SSE보다 안정적으로 동작하며, 상태 유지(stateful) 연결이 불필요한 경우 무상태(stateless) 요청도 지원합니다.
실전 적용
예시 1: 고객 지원 자동화 파이프라인
이 예시의 핵심: 단일 AI Agent + 3개 MCP Client Tool로 여러 시스템을 자연어 하나로 처리하는 기본 패턴
세 개의 MCP Client Tool 노드가 서브노드로 연결된 단일 AI Agent가 자연어로 CRM, 티켓팅, 지식베이스를 동시에 처리합니다. 가장 빠르게 MCP 연동 효과를 체감할 수 있는 시작점입니다.
[고객 문의 웹훅]
│
▼
[AI Agent (GPT-4o)] ──── 서브노드 연결
├──[MCP Client Tool: CRM] → CRM MCP 서버 (고객 정보 조회)
├──[MCP Client Tool: Ticketing] → 티켓팅 MCP 서버 (오픈 이슈 확인)
└──[MCP Client Tool: KB] → 지식베이스 MCP 서버 (해결책 검색)
│
▼
[답변 초안 생성 → 슬랙 전송]MCP Client Tool 노드 설정 방법: n8n 캔버스에서 MCP Client Tool 노드를 열면 Parameters 탭에서 다음 항목을 입력합니다.
| 필드 경로 | 입력값 | 설명 |
|---|---|---|
Transport Type |
Streamable HTTP |
HTTP Streamable 권장 (SSE는 레거시) |
URL |
https://your-crm-mcp-server.com/mcp |
MCP 서버 엔드포인트 |
Authentication |
Credential 드롭다운에서 선택 | Bearer Token, Header Auth, OAuth2 중 사전 생성한 자격 증명을 선택 |
인증 정보(API 키, 토큰)는 n8n의 Credentials 관리 화면에서 별도 저장한 뒤 노드의 Authentication 드롭다운으로 연결하는 방식을 사용합니다. JSON에 직접 토큰 값을 작성하는 방식은 지원하지 않습니다.
설정을 마치면 n8n이 MCP 서버의 /tools/list를 자동 호출해 도구 목록을 탐색하고, AI Agent에 자동으로 노출합니다.
이렇게 구성된 워크플로 전체를 MCP Server Trigger로 노출하면(별도 워크플로), Claude Desktop이나 Cursor 같은 외부 AI 클라이언트에서 "고객 문의 해결"이라는 단일 도구로 이 파이프라인 전체를 호출할 수 있습니다.
단일 에이전트 구조는 도구가 3~5개 수준일 때 적합합니다. 도메인이 늘어나거나 각 도메인의 처리 로직이 복잡해진다면 다음 패턴이 더 효과적입니다.
예시 2: 멀티 에이전트 리서치 파이프라인
이 예시의 핵심: 오케스트레이터 + 전문화된 워커 에이전트 계층 구조 — 각 워커가 독립 컨텍스트를 가져 오케스트레이터 부하를 분산
계층적 에이전트 구조로 대규모 리서치 작업을 자동화하는 패턴입니다. 오케스트레이터가 모든 도구를 직접 관리하는 대신 전문화된 워커 에이전트에 위임합니다.
[리서치 주제 입력]
│
▼
[리서치 리더 Agent — 오케스트레이터]
│
├──[AI Agent Tool] ──▶ 리서치 어시스턴트 1 (웹 검색 전문)
│ └──[MCP Client Tool] → Brave Search MCP
│
├──[AI Agent Tool] ──▶ 리서치 어시스턴트 2 (기술 분석 전문)
│ └──[MCP Client Tool] → Elasticsearch MCP
│
└──[AI Agent Tool] ──▶ 에디터 Agent
└──[MCP Client Tool] → 이메일 발송 MCPAI Agent Tool 노드: 다른 AI Agent를 도구처럼 연결하는 노드. 오케스트레이터가 워커 에이전트를 일반 도구와 동일한 방식으로 호출할 수 있게 해줍니다. 웹훅 없이 MCP Trigger-Client 조합만으로 에이전트 간 통신을 구현할 수 있습니다.
오케스트레이터 AI Agent 노드의 핵심 설정 구조는 n8n 워크플로 JSON 상에서 다음과 같이 표현됩니다.
{
"nodes": [
{
"name": "리서치 리더 Agent",
"type": "@n8n/n8n-nodes-langchain.agent",
"parameters": {
"options": {
"systemMessage": "당신은 리서치 리더입니다. 주제를 분석하고 적절한 워커 에이전트에 작업을 위임하세요."
}
}
},
{
"name": "리서치 어시스턴트 1",
"type": "@n8n/n8n-nodes-langchain.agent",
"parameters": {
"options": {
"systemMessage": "웹 검색 전문 에이전트입니다. Brave Search를 활용해 최신 정보를 수집하세요."
}
}
}
],
"connections": {
"리서치 어시스턴트 1": {
"ai_tool": [[{"node": "리서치 리더 Agent", "type": "ai_tool", "index": 0}]]
}
}
}ai_tool 연결 타입이 워커 에이전트를 오케스트레이터의 서브노드(도구)로 등록한다는 점을 확인할 수 있습니다.
이 패턴의 핵심은 각 워커 에이전트가 독립적인 컨텍스트를 가진다는 점입니다. 오케스트레이터가 모든 도구의 컨텍스트를 직접 관리하지 않아도 됩니다. 그런데 워커 에이전트가 연결하는 MCP 서버 자체에 수십~수백 개의 도구가 포함되어 있다면 어떻게 될까요? 다음 패턴이 그 문제를 해결합니다.
예시 3: 컨텍스트 리듀서 패턴
이 예시의 핵심: 100개 이상의 도구를 가진 대형 MCP 서버 연결 시 컨텍스트 폭발을 방지하는 중간 레이어 패턴
LLM은 사용 가능한 도구 목록 전체를 프롬프트 컨텍스트에 포함한 채 응답을 생성합니다. 도구 1개의 설명과 JSON Schema는 평균 100
300토큰을 소모하므로, 100개 도구를 가진 Elasticsearch MCP 서버를 오케스트레이터에 직접 연결하면 도구 목록만으로 10,000
30,000토큰이 소모됩니다. 이는 GPT-4o의 128K 컨텍스트 중 약 10~25%를 도구 목록이 점유하는 셈이며, 실제로 도구 선택 정확도가 저하되고 응답 생성 비용이 상승하는 증상이 나타납니다.
n8n 워크플로 템플릿 #4475에서 소개된 컨텍스트 리듀서 패턴으로 이를 완화할 수 있습니다.
[오케스트레이터 Agent]
│ (워커에 "이런 정보가 필요해"라고 자연어 위임)
└──[AI Agent Tool] ──▶ 서브 에이전트 (컨텍스트 리듀서)
│ (대형 MCP 서버와 직접 상호작용)
└──[MCP Client Tool] → 대형 MCP 서버 (100+ 도구)
│
▼
[필요한 결과만 요약해 오케스트레이터에 반환]서브 에이전트가 중간 레이어로 대형 MCP 서버와 직접 상호작용하고, 오케스트레이터에는 압축된 결과만 전달하는 구조입니다. 오케스트레이터는 100개 도구의 존재를 알 필요 없이, 워커 에이전트라는 하나의 도구만 인식하면 됩니다.
MCP Server Trigger로 도구를 노출할 때 설명을 간결하게 작성하는 것도 컨텍스트 절약에 중요합니다. 도구 스키마를 작성할 때 다음과 같이 간결한 구조를 유지하시면 됩니다.
{
"name": "search_customer_issues",
"description": "고객 ID로 오픈 이슈를 검색합니다. 복잡한 필터 대신 자연어 쿼리를 입력하세요.",
"inputSchema": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "자연어 검색 쿼리 (예: '최근 30일 내 미해결 결제 오류')"
}
},
"required": ["query"]
}
}장단점 분석
장점
| 항목 | 내용 |
|---|---|
| 표준화 | MCP 프로토콜로 모든 외부 도구를 동일한 방식으로 연결 — 커스텀 통합 코드가 불필요합니다 |
| 모듈성 | 서브 에이전트를 도구처럼 추가·제거할 수 있어, 전체 워크플로 재설계 없이 기능 확장이 가능합니다 |
| 양방향성 | n8n이 소비자(Client)이자 제공자(Server)로 동시에 작동합니다 |
| 시각적 편집 | 코드 없이 GUI로 멀티 에이전트 파이프라인을 구성할 수 있습니다 |
| 600+ 템플릿 | 커뮤니티 템플릿으로 빠른 프로토타이핑이 가능합니다 |
| 유연한 인증 | Bearer Token, Generic Header, OAuth2를 모두 지원합니다 |
단점 및 주의사항
| 항목 | 내용 | 대응 방안 |
|---|---|---|
| STDIO 미지원 | 내장 MCP Client Tool은 HTTP/SSE 기반만 지원. 로컬 커맨드라인 MCP 서버 연결 불가 | 커뮤니티 노드 n8n-nodes-mcp 사용 |
| 환경변수 필수 | N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE=true 미설정 시 MCP Client Tool이 AI Agent 도구 목록에 노출되지 않음. n8n의 보안 정책상 툴 타입 노드 실행을 기본 차단하기 때문 |
Self-hosted 환경의 docker-compose.yml 환경변수 항목에 사전 추가 |
| SSE→HTTP Streamable 전환기 버그 | UI에서 HTTP Streamable 선택 시에도 SSE로 동작하는 버그 보고됨 (GitHub Issue #18938, #24967) | 임시 방편으로 서버와 클라이언트를 모두 SSE로 맞추는 폴백 적용 가능. 근본 해결은 해당 이슈가 닫힌 버전으로 업데이트 후 재확인 필요 |
| 컨텍스트 비용 | 대형 MCP 서버 연결 시 도구 목록이 LLM 컨텍스트를 10,000토큰 이상 소모 가능 | 컨텍스트 리듀서 패턴(템플릿 #4475) 활용 |
| 생태계 성숙도 | 서드파티 MCP 서버 품질·안정성 편차 존재 | 공식 지원 서버(GitHub, Gmail, Google Calendar 등) 우선 사용 |
STDIO(Standard Input/Output): 프로세스 간 통신 방식으로, 커맨드라인 도구처럼 로컬에서 실행되는 MCP 서버에서 주로 사용됩니다. HTTP 기반 MCP 서버와 달리 환경변수와 커맨드라인 인자를 통해 설정이 전달됩니다.
실무에서 가장 흔한 실수
- 환경변수 누락: Self-hosted n8n에서
N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE=true를 설정하지 않아 MCP Client Tool이 AI Agent의 도구 목록에 나타나지 않는 경우가 가장 빈번합니다. Cloud 사용자는 이 설정이 불필요합니다. - 트랜스포트 방식 불일치: MCP 서버는 SSE로 구동 중인데 클라이언트에서 HTTP Streamable로 연결을 시도하거나, 반대로 새 서버를 레거시 SSE로 구동하는 경우입니다. 서버와 클라이언트의 트랜스포트 방식이 반드시 일치해야 합니다.
- 오케스트레이터에 너무 많은 도구 직접 연결: 모든 MCP Client Tool을 단일 오케스트레이터에 직접 연결하면 컨텍스트가 폭발적으로 증가하고 도구 선택 정확도가 저하됩니다. 도메인별로 워커 에이전트를 두고, 오케스트레이터는 워커를 도구로 호출하는 계층 구조가 더 안정적입니다.
마치며
n8n MCP Client Tool 노드는 단순한 통합 커넥터가 아니라, AI 에이전트들이 표준 프로토콜로 협력하는 오케스트레이션 플랫폼의 핵심 부품입니다. 2025년 4월 내장 노드로 출시된 이후 진입 장벽이 크게 낮아졌으며, HTTP Streamable 표준이 자리를 잡아가면서 생태계 안정성도 빠르게 개선되고 있습니다.
지금 바로 시작할 수 있는 3단계가 있습니다.
- 환경변수를 추가합니다. Self-hosted 환경이라면
docker-compose.yml에N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE=true를 추가하고 컨테이너를 재시작하면 준비가 완료됩니다. n8n Cloud 사용자라면 이 단계를 건너뛰어도 됩니다. - n8n 워크플로 템플릿 #4475(MCP Server with AI Agent as a Tool — Context Reducer)를 불러와 구조를 살펴봅니다. 오케스트레이터-워커 패턴과 컨텍스트 리듀서 구조를 한 번에 확인할 수 있는 가장 빠른 방법입니다.
- 공식 지원 MCP 서버(Gmail, Google Calendar, GitHub) 중 하나를 MCP Client Tool 노드에 연결해 도구 탐색(discover)이 동작하는지 확인합니다. 에이전트가 런타임에 도구 목록을 자동으로 가져오는 과정을 직접 확인하고 나면, 이후 커스텀 MCP 서버 연결로 자연스럽게 확장할 수 있습니다.
3단계를 완료했다면 이번에는 예시 1의 CRM MCP 서버 URL을 자신의 내부 시스템으로 교체해보시기를 권장합니다. 도구 스키마 정의 → 연결 테스트 → 오케스트레이터 프롬프트 조정의 순서로 진행하면 실제 운영 파이프라인의 첫 버전을 만들 수 있습니다.
다음 글: n8n MCP Server Trigger로 나만의 커스텀 MCP 서버를 만들고 Claude Desktop에 연결하는 방법 — n8n 워크플로를 외부 AI 클라이언트의 도구로 노출하는 전 과정을 단계별로 안내합니다.
참고 자료
입문자라면 ★ 표시된 자료부터, 내부 구현까지 파악하고 싶다면 ▲ 표시 자료를 추가로 참고하시기를 권장합니다.
- ★ MCP Client Tool 노드 공식 문서 | n8n Docs — 노드 파라미터와 인증 방식 기준 자료
- ★ MCP Server Trigger 노드 공식 문서 | n8n Docs — 서버 노출 방법 기준 자료
- ★ MCP Server with AI Agent 워크플로 템플릿 #4475 | n8n.io — 컨텍스트 리듀서 패턴 실습 시작점
- n8n MCP 서버 설정 가이드 | n8n Docs — Self-hosted 환경변수 설정 포함
- n8n as Agentic MCP Hub | Infralovers — 양방향 허브 아키텍처 개요
- MCP Trigger·Client로 멀티 에이전트 패턴 구현 | n8n Community — 웹훅 없는 에이전트 간 통신 구현 사례
- Multi-agent system 튜토리얼 | n8n 공식 블로그 — 오케스트레이터-워커 패턴 공식 튜토리얼
- Orchestrating Agentic AI with n8n and MCP | Medium, Data Reply IT
- Supercharge AI Agents with n8n and MCP | Medium, Leandro Calado
- ▲ MCP Streamable HTTP 도입 배경 | fka.dev — SSE deprecated 이유와 HTTP Streamable 설계 철학
- ▲ MCP 공식 트랜스포트 스펙 | modelcontextprotocol.io — 트랜스포트 레이어 원문 스펙
- ▲ n8n + Elasticsearch MCP 에이전트 사례 | Elastic — 대형 MCP 서버 연동 실전 사례
- n8n-mcp GitHub (czlonkowski) — Claude Desktop에서 n8n 워크플로를 직접 빌드·실행하는 MCP 서버