n8n을 MCP Hub로 쓰면 525개 서비스를 AI 에이전트에 단일 도구로 일괄 연결한다 — n8n as MCP Hub 아키텍처 패턴

AI 에이전트를 외부 서비스에 연결하다 보면 어느 순간 이런 벽에 부딪힙니다. Slack, GitHub, CRM, 결제 시스템… 연결해야 할 서비스가 늘어날수록 각각 MCP 서버를 따로 구현하고, 인증 설정을 따로 관리하고, 에이전트에게 노출할 도구 목록은 폭발적으로 커집니다. 저도 처음엔 "그냥 서비스마다 MCP 서버 하나씩 만들면 되지 않나" 싶었는데, GitHub MCP 서버 인증 키를 갱신하다가 Slack MCP 서버가 조용히 죽어있던 걸 다음 날 발견했을 때 생각이 달라졌습니다. 관리 지점이 분산되는 순간, 운영 비용은 서비스 수의 제곱으로 불어납니다.

n8n as MCP Hub는 이 문제를 정면으로 해결하는 아키텍처 패턴입니다. n8n은 525개 이상의 통합 노드를 품은 오픈소스 워크플로우 자동화 플랫폼인데, 개별 MCP 서버를 새로 구현하는 대신 이 플랫폼을 중앙 허브로 세워 모든 외부 서비스를 일괄 오케스트레이션하는 방식입니다. 이 글에서는 이 패턴이 어떤 구조로 동작하는지, 실제 어떤 시나리오에 써먹을 수 있는지, 그리고 어디서 넘어지기 쉬운지를 현업 시각에서 살펴봅니다.

MCP와 n8n을 이미 실무에서 쓰고 있다면 3절(실전 적용)로 바로 건너뛰어도 됩니다. 두 개념 중 하나가 낯설다면 아래 핵심 개념 섹션이 출발점이 될 겁니다.

핵심 개념

MCP가 뭔지 먼저 짚고 넘어가면

MCP(Model Context Protocol)는 Anthropic이 2024년 말 발표한 오픈 표준으로, AI 모델과 외부 도구·데이터 소스가 통신하는 방식을 표준화한 규격입니다.

MCP란? AI 모델(Claude, GPT 등)이 외부 도구를 호출할 때 쓰는 표준 인터페이스. USB-C가 다양한 기기를 하나의 케이블로 연결하듯, MCP는 다양한 AI 클라이언트와 외부 서비스를 하나의 규격으로 잇습니다. MCP 공식 사양에서 자세한 내용을 확인할 수 있습니다.

Claude Desktop, Cursor, Windsurf, VS Code 같은 클라이언트들이 현재 MCP를 지원하고 있고, 이 생태계는 2025년을 기점으로 빠르게 확산됐습니다. n8n은 2025년 2~4월 사이에 공식 MCP 노드를 출시하며 이 흐름에 합류했습니다.

n8n이 MCP의 양방향 역할을 동시에 한다는 게 핵심

n8n에서 새로 추가된 두 노드의 역할을 이해하면 패턴 전체가 보입니다.

노드	방향	역할
`MCP Server Trigger`	Outbound (서버 역할)	n8n 워크플로우를 MCP 도구로 외부에 노출
`MCP Client Tool`	Inbound (클라이언트 역할)	외부 MCP 서버를 n8n 에이전트의 도구로 소비

이 두 노드의 조합이 허브 패턴을 가능하게 합니다. 구조를 Mermaid 다이어그램으로 표현하면 이렇습니다.

mermaid

graph TD
    A["Claude / Cursor / Windsurf"] -->|MCP 호출| B
 
    subgraph n8n_hub["n8n Hub"]
        B["MCP Server Trigger (진입점)"]
        B --> C["AI Agent Node (오케스트레이터)"]
        C --> D["MCP Client Tool"]
        C --> E["MCP Client Tool"]
        C --> F["MCP Client Tool"]
    end
 
    D -->|MCP| G["CRM MCP 서버"]
    E -->|MCP| H["Finance MCP 서버"]
    F -->|MCP| I["Ticketing MCP 서버"]

외부 AI 에이전트 입장에서는 n8n 하나만 보입니다. 내부에서 CRM, 재무, 티켓팅 세 시스템을 연결해 처리하고 있다는 걸 알 필요가 없습니다.

인스턴스 레벨 MCP vs. 단일 워크플로우 MCP

나중에 실수 섹션에서도 나오는 개념이라 여기서 미리 짚어두는 게 좋을 것 같습니다. n8n에서 MCP를 노출하는 방법은 두 가지입니다.

인스턴스 레벨 MCP: n8n 인스턴스 전체를 단일 MCP 서버로 노출합니다. 활성화된 워크플로우 목록을 자동으로 도구로 등록하며, 인증 키를 한 곳에서 중앙 관리할 수 있습니다. 여러 팀이 공유하는 조직 단위 허브에 적합합니다.
단일 워크플로우 MCP: 특정 워크플로우 하나에 MCP Server Trigger 노드를 달아 해당 워크플로우만 MCP 도구로 노출합니다. 노출 범위를 세밀하게 제어하거나, 특정 도구의 동작을 커스터마이즈할 때 유리합니다.

Tool Context Reduction — 이게 진짜 핵심 가치입니다

솔직히 처음엔 "그냥 편의 패턴 아닌가" 싶었는데, Tool Context Reduction 개념을 이해하고 나서 생각이 바뀌었습니다.

LLM은 매 요청마다 주어진 도구 목록을 텍스트로 읽습니다. 이 도구 정의들이 모두 토큰으로 소비된다는 의미입니다. 연결된 MCP 서버가 10개고 각각 도구를 20개씩 노출한다면, 에이전트는 매 요청마다 200개 도구의 설명을 읽어야 합니다. 이건 토큰 낭비이기도 하지만, 에이전트가 "어떤 도구를 언제 써야 하는가"를 판단해야 하는 인지 부담도 커집니다. 컨텍스트 윈도우란 LLM이 한 번에 처리할 수 있는 텍스트의 총 길이 한계를 말하는데, 도구 목록이 커질수록 실제 대화 내용에 쓸 수 있는 공간이 줄어드는 문제도 있습니다.

n8n Hub 패턴에서는 내부의 복잡한 다단계 작업이 외부에는 단 하나의 추상 도구로 노출됩니다.

내부: CRM 조회 → 티켓 확인 → 지식베이스 검색 → 응답 초안 작성
외부에 노출되는 도구: resolve_customer_inquiry(customer_id, inquiry_text)

Tool Context Reduction 여러 시스템에 걸친 복잡한 작업을 단일 추상화 도구로 래핑해, 외부 AI 에이전트의 컨텍스트 윈도우 소비를 줄이는 설계 원칙. 토큰 절감과 에이전트 판단 단순화를 동시에 달성합니다.

실전 적용

예시 1: 고객 문의 통합 해결 에이전트

실무에서 가장 자주 맞닥뜨리는 시나리오입니다. 고객 문의가 들어오면 CRM에서 고객 정보를 찾고, 티켓팅 시스템에서 진행 중인 이슈를 확인하고, 지식베이스에서 해결책을 검색한 뒤 응답 초안을 만들어야 합니다. 보통 사람이 세 탭을 오가며 하던 일이죠.

n8n Hub로 구성하면 이렇게 됩니다. 아래 JSON은 MCP Server Trigger 노드에서 외부에 노출할 도구를 어떻게 정의하는지 보여주는 **의사코드(pseudocode)**입니다. 실제 n8n에서는 노드 UI에서 도구 이름과 파라미터를 설정하는 방식이라 이 JSON을 직접 붙여넣는 것이 아님을 참고해 주세요.

json

// MCP Server Trigger 노드 - 외부 AI에 노출할 도구 정의 (의사코드)
{
  "tool": "resolve_customer_inquiry",
  "description": "고객 ID를 받아 CRM, 티켓팅, 지식베이스를 종합해 응답 초안을 반환합니다",
  "parameters": {
    "customer_id": { "type": "string", "required": true },
    "inquiry_text": { "type": "string", "required": true }
  }
}

워크플로우 내부 흐름 (순차 처리):
 
MCP Server Trigger (resolve_customer_inquiry 수신)
  └→ AI Agent Node (오케스트레이터)
       ├→ [1단계] MCP Client Tool → CRM MCP   : get_customer_profile(customer_id)
       ├→ [2단계] MCP Client Tool → Ticketing : list_open_tickets(customer_id)
       └→ [3단계] MCP Client Tool → KB MCP    : search_solution(inquiry_text)
  └→ LLM으로 조회 결과를 종합해 응답 초안 생성
  └→ MCP 응답으로 반환

구성 요소	역할
`MCP Server Trigger`	Claude Desktop 또는 사내 AI가 호출하는 진입점
`AI Agent Node`	세 MCP 서버를 순서에 맞게 호출하는 오케스트레이터
`MCP Client Tool × 3`	각각 CRM, 티켓팅, 지식베이스 MCP 서버 연결

실제로 이 구성을 처음 올렸을 때, Cloudflare 프록시 뒤에서 SSE 연결이 조용히 타임아웃되는 문제로 두 시간을 날렸습니다. SSE 경로에 프록시 타임아웃 예외를 설정하거나, Streamable HTTP로 전환하면 해결됩니다.

외부 AI는 resolve_customer_inquiry 하나만 알면 됩니다. CRM API 스펙이나 티켓 시스템의 인증 방식을 전혀 알 필요가 없습니다.

예시 2: 엔터프라이즈 도메인별 MCP 계층 구성

규모가 커지면 단일 n8n 허브 하나에 모든 걸 몰아넣기보다 도메인별로 MCP 서버를 분리하고, n8n이 이를 오케스트레이션하는 계층 구조가 권장됩니다. 대략 서비스 수가 15~20개를 넘거나, 팀이 둘 이상으로 나뉘어 각 도메인을 독립 운영하고 싶을 때 이 구조를 고려해보시면 좋습니다. 소규모 팀이나 초기 프로토타이핑 단계에서는 오히려 복잡도만 올라가니 단일 허브로 시작하는 것을 권장합니다.

yaml

# docker-compose 예시 — 도메인별 MCP 서버 분리 배포
services:
  finance-mcp:
    image: finance-mcp-server:latest
    environment:
      XERO_API_KEY: ${XERO_API_KEY}
      QUICKBOOKS_TOKEN: ${QUICKBOOKS_TOKEN}
    ports:
      - "3001:3000"
 
  crm-mcp:
    image: crm-mcp-server:latest
    environment:
      HUBSPOT_API_KEY: ${HUBSPOT_API_KEY}
      SALESFORCE_TOKEN: ${SALESFORCE_TOKEN}
    ports:
      - "3002:3000"
 
  workspace-mcp:
    image: workspace-mcp-server:latest
    environment:
      GOOGLE_SERVICE_ACCOUNT: ${GOOGLE_SA_JSON}
    ports:
      - "3003:3000"
 
  n8n:
    image: n8nio/n8n:latest
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=0.0.0.0
    # n8n이 위 MCP 서버들을 MCP Client Tool 노드로 소비
    # MCP Client Tool 노드의 엔드포인트 URL을
    # http://finance-mcp:3000, http://crm-mcp:3000 등으로 설정
    networks:
      - mcp-network
 
  # finance-mcp, crm-mcp, workspace-mcp 서비스도 동일 네트워크에 포함
networks:
  mcp-network:
    driver: bridge

권장 도메인 분리 구조:
 
Finance MCP   ──→ Xero / QuickBooks / NetSuite
CRM MCP       ──→ HubSpot / Salesforce / Dynamics
Internal MCP  ──→ 사내 REST/GraphQL API
Workspace MCP ──→ Google Workspace / Microsoft 365
Comms MCP     ──→ Slack / Teams / Discord
      ↑
   n8n이 이 다섯 서버를 MCP Client Tool로 묶어 오케스트레이션
      ↓
외부 AI 에이전트에게는 고수준 비즈니스 도구만 노출

각 MCP 서버는 독립 컨테이너로 배포되어 자체 인증과 배포 라이프사이클을 가집니다. n8n이 내려가도 각 도메인 MCP 서버는 살아있고, 반대도 마찬가지입니다.

예시 3: AI 코딩 어시스턴트에서 배포 워크플로우 직접 트리거

개발자라면 솔직히 이 시나리오가 제일 와닿을 겁니다. Cursor나 Claude에서 자연어로 배포 명령을 내리면, n8n에 노출된 CI/CD 워크플로우가 실행되는 구성입니다.

json

// Claude Desktop의 claude_desktop_config.json
{
  "mcpServers": {
    "n8n-hub": {
      "command": "npx",
      "args": ["n8n-mcp", "--n8n-url", "https://your-n8n.domain.com"],
      "env": {
        "N8N_API_KEY": "your-api-key"
      }
    }
  }
}

이 설정 하나로 Claude Desktop이 n8n에 노출된 모든 워크플로우를 MCP 도구로 인식합니다. 워크플로우 내부에서는 MCP Server Trigger → HTTP Request (GitHub Actions, Jenkins 등 CI/CD API 호출) → Slack 알림 순으로 노드가 연결됩니다. "스테이징 배포해줘"라는 메시지 한 줄이 이 워크플로우를 트리거하고, 결과를 대화 창에 돌려주는 식입니다.

장단점 분석

장점

항목	내용
단일 진입점	수백 개 외부 서비스를 n8n 인스턴스 하나로 통합. 서비스마다 MCP 서버를 따로 구축할 필요가 없습니다
인증 중앙화	모든 서비스 인증 키가 n8n 한 곳에서 관리됩니다. 인스턴스 레벨 MCP에서는 특히 효과적입니다
Tool Context Reduction	복잡한 다단계 작업을 단일 추상 도구로 래핑해 LLM 토큰 소비를 절감합니다
빠른 프로토타이핑	525개 이상 내장 노드 덕분에 코드 한 줄 없이 MCP 도구를 즉시 구성할 수 있습니다
크로스 시스템 추론	단일 요청 안에서 여러 도메인 시스템을 연계 처리하는 에이전트를 쉽게 만들 수 있습니다
클라이언트 호환성	Claude Desktop, Cursor, Windsurf, VS Code Copilot 등 주요 MCP 클라이언트와 즉시 동작합니다
운영 단순성	n8n 인스턴스가 살아있으면 MCP 서버도 자동으로 동작합니다. 별도 서버 프로세스 관리가 필요 없습니다

단점 및 주의사항

표로만 봐서는 체감이 잘 안 되는 항목들입니다. 특히 SSE 타임아웃 이슈와 컨텍스트 지속성 문제는 직접 겪고 나서야 설계 단계에서 고려해야 한다는 걸 알게 되는 경우가 많습니다.

항목	내용	대응 방안
STDIO 불가	SSE, Streamable HTTP만 지원. STDIO 기반 MCP 서버와 직접 통합이 안 됩니다	Streamable HTTP로 마이그레이션 계획 수립
로드 밸런싱 복잡	SSE는 동일 서버 인스턴스에서 지속 연결 유지 필요. 다중 레플리카 환경에서 `/mcp*` 경로를 단일 레플리카로 라우팅해야 합니다	인그레스 또는 Nginx에서 sticky session 설정
컨텍스트 지속성 부재	기본적으로 워크플로우 단계 간 메모리가 없는 무상태 구조입니다	별도 메모리 노드(Postgres, Redis) 또는 외부 벡터 DB 연동
도구 정의 고정성	노출하는 도구의 스키마가 미리 고정되어야 합니다. 런타임 동적 도구 생성이 어렵습니다	범용 도구로 설계하거나 워크플로우 버전 분리로 대응
에이전트 성숙도	멀티 에이전트 플래닝이나 재시도 전략이 3단계 이상 중첩되는 복잡한 시나리오에서 커스텀 프레임워크 대비 한계가 있습니다	해당 복잡도부터는 MCP SDK 직접 구현 병행 고려
Cloudflare 프록시 이슈	SSE 연결이 역방향 프록시에서 타임아웃되거나 차단되는 사례가 보고됩니다	Cloudflare에서 SSE 경로 타임아웃 조정 또는 Streamable HTTP 전환

SSE와 Streamable HTTP의 차이 SSE(Server-Sent Events)는 서버→클라이언트 단방향 스트리밍 연결을 유지하는 HTTP 기반 프로토콜입니다. n8n의 MCP 전송 방식으로 현재 지원되지만, MCP 사양에서는 레거시 전송 방식으로 분류됐으며 신규 구현에는 Streamable HTTP가 권장됩니다. Streamable HTTP는 지속 연결 없이 요청마다 스트리밍을 처리해 프록시 환경에서 훨씬 안정적으로 동작합니다.

실무에서 가장 흔한 실수

모든 워크플로우를 단일 MCP Server Trigger 하나에 몰아넣기. 도구가 20개를 넘으면 에이전트의 도구 선택 정확도가 떨어지기 시작합니다. 인스턴스 레벨 MCP를 쓸 때는 특히, 활성화 워크플로우 수가 무제한으로 노출될 수 있으니 도메인 단위로 트리거를 분리하거나 노출 범위를 명시적으로 제어하는 것을 권장합니다.
인스턴스 레벨 MCP와 단일 워크플로우 방식의 차이를 모르고 선택하기. 인스턴스 레벨은 중앙화된 인증 관리와 활성화된 워크플로우를 일괄 노출할 때 유리하고, 단일 워크플로우 방식은 특정 도구의 동작을 세밀하게 제어할 때 유리합니다. 둘을 혼용하면 노출 범위가 의도치 않게 넓어질 수 있습니다. 첫 설계 때 이 선택을 명시적으로 하지 않으면 나중에 도구 목록이 왜 이렇게 많이 노출되는지 추적하기 어려워집니다.
프로토타이핑 구성 그대로 프로덕션에 올리기. n8n이 단일 장애점이 되는 구조인 만큼, 고가용성 구성 없이 프로덕션 트래픽을 받으면 n8n 재시작 한 번에 연결된 AI 에이전트 전체가 멈춥니다. 최소한 헬스체크와 재시작 정책은 미리 설정해두는 것을 권장합니다.

마치며

직접 MCP 서버를 구현할 때와 n8n Hub를 택할 때의 분기점은 결국 오케스트레이션 복잡도와 운영 부담의 트레이드오프입니다. 통합 노드가 이미 있고, 빠르게 연결하는 것이 목표라면 n8n Hub가 압도적으로 효율적입니다. 반대로 멀티 에이전트 플래닝이나 정교한 상태 관리가 핵심인 시나리오라면, n8n을 프로토타이핑 레이어로 쓰면서 MCP SDK 직접 구현을 병행하는 게 현실적인 선택입니다.

아직 n8n Hub가 모든 상황의 정답은 아닙니다. 하지만 서비스 연결의 반복적인 인프라 비용을 줄이고, AI 에이전트가 실제 비즈니스 로직에 집중하게 만드는 실용적인 출발점으로는 충분히 검증된 패턴입니다.

지금 바로 시작해볼 수 있는 3단계:

docker run -it --rm -p 5678:5678 n8nio/n8n 으로 로컬 n8n 인스턴스를 띄운 뒤, 새 워크플로우에 MCP Server Trigger 노드를 추가해 첫 MCP 도구를 노출해볼 수 있습니다.
Claude Desktop의 claude_desktop_config.json에 n8n MCP 서버를 등록해 AI 클라이언트에서 실제로 도구가 인식되는지 확인해볼 수 있습니다. czlonkowski/n8n-mcp 패키지를 npx로 실행하면 별도 서버 없이 n8n 워크플로우 목록을 자동으로 도구로 인식합니다.
n8n 공식 템플릿 #4475(MCP server with AI agent as a tool context reducer)를 불러와 Tool Context Reduction 패턴이 실제로 어떻게 구성되는지 뜯어보는 것을 권장합니다. 좋은 출발점이 됩니다.

참고 자료

입문

공식

심화

#n8n#MCP#AIAgent#WorkflowAutomation#ToolContextReduction#LLM#오케스트레이션#Docker#SSE#StreamableHTTP

n8n을 MCP Hub로 쓰면 525개 서비스를 AI 에이전트에 단일 도구로 일괄 연결한다 — n8n as MCP Hub 아키텍처 패턴 | DEV BAK - 기술블로그

n8n을 MCP Hub로 쓰면 525개 서비스를 AI 에이전트에 단일 도구로 일괄 연결한다 — n8n as MCP Hub 아키텍처 패턴

핵심 개념

MCP가 뭔지 먼저 짚고 넘어가면

MCP(Model Context Protocol)는 Anthropic이 2024년 말 발표한 오픈 표준으로, AI 모델과 외부 도구·데이터 소스가 통신하는 방식을 표준화한 규격입니다.

MCP란? AI 모델(Claude, GPT 등)이 외부 도구를 호출할 때 쓰는 표준 인터페이스. USB-C가 다양한 기기를 하나의 케이블로 연결하듯, MCP는 다양한 AI 클라이언트와 외부 서비스를 하나의 규격으로 잇습니다. MCP 공식 사양에서 자세한 내용을 확인할 수 있습니다.

n8n이 MCP의 양방향 역할을 동시에 한다는 게 핵심

n8n에서 새로 추가된 두 노드의 역할을 이해하면 패턴 전체가 보입니다.

노드	방향	역할
`MCP Server Trigger`	Outbound (서버 역할)	n8n 워크플로우를 MCP 도구로 외부에 노출
`MCP Client Tool`	Inbound (클라이언트 역할)	외부 MCP 서버를 n8n 에이전트의 도구로 소비

이 두 노드의 조합이 허브 패턴을 가능하게 합니다. 구조를 Mermaid 다이어그램으로 표현하면 이렇습니다.

mermaid

graph TD
    A["Claude / Cursor / Windsurf"] -->|MCP 호출| B
 
    subgraph n8n_hub["n8n Hub"]
        B["MCP Server Trigger (진입점)"]
        B --> C["AI Agent Node (오케스트레이터)"]
        C --> D["MCP Client Tool"]
        C --> E["MCP Client Tool"]
        C --> F["MCP Client Tool"]
    end
 
    D -->|MCP| G["CRM MCP 서버"]
    E -->|MCP| H["Finance MCP 서버"]
    F -->|MCP| I["Ticketing MCP 서버"]

외부 AI 에이전트 입장에서는 n8n 하나만 보입니다. 내부에서 CRM, 재무, 티켓팅 세 시스템을 연결해 처리하고 있다는 걸 알 필요가 없습니다.

인스턴스 레벨 MCP vs. 단일 워크플로우 MCP

나중에 실수 섹션에서도 나오는 개념이라 여기서 미리 짚어두는 게 좋을 것 같습니다. n8n에서 MCP를 노출하는 방법은 두 가지입니다.

인스턴스 레벨 MCP: n8n 인스턴스 전체를 단일 MCP 서버로 노출합니다. 활성화된 워크플로우 목록을 자동으로 도구로 등록하며, 인증 키를 한 곳에서 중앙 관리할 수 있습니다. 여러 팀이 공유하는 조직 단위 허브에 적합합니다.
단일 워크플로우 MCP: 특정 워크플로우 하나에 MCP Server Trigger 노드를 달아 해당 워크플로우만 MCP 도구로 노출합니다. 노출 범위를 세밀하게 제어하거나, 특정 도구의 동작을 커스터마이즈할 때 유리합니다.

Tool Context Reduction — 이게 진짜 핵심 가치입니다

솔직히 처음엔 "그냥 편의 패턴 아닌가" 싶었는데, Tool Context Reduction 개념을 이해하고 나서 생각이 바뀌었습니다.

n8n Hub 패턴에서는 내부의 복잡한 다단계 작업이 외부에는 단 하나의 추상 도구로 노출됩니다.

내부: CRM 조회 → 티켓 확인 → 지식베이스 검색 → 응답 초안 작성
외부에 노출되는 도구: resolve_customer_inquiry(customer_id, inquiry_text)

Tool Context Reduction 여러 시스템에 걸친 복잡한 작업을 단일 추상화 도구로 래핑해, 외부 AI 에이전트의 컨텍스트 윈도우 소비를 줄이는 설계 원칙. 토큰 절감과 에이전트 판단 단순화를 동시에 달성합니다.

실전 적용

예시 1: 고객 문의 통합 해결 에이전트

json

// MCP Server Trigger 노드 - 외부 AI에 노출할 도구 정의 (의사코드)
{
  "tool": "resolve_customer_inquiry",
  "description": "고객 ID를 받아 CRM, 티켓팅, 지식베이스를 종합해 응답 초안을 반환합니다",
  "parameters": {
    "customer_id": { "type": "string", "required": true },
    "inquiry_text": { "type": "string", "required": true }
  }
}

워크플로우 내부 흐름 (순차 처리):
 
MCP Server Trigger (resolve_customer_inquiry 수신)
  └→ AI Agent Node (오케스트레이터)
       ├→ [1단계] MCP Client Tool → CRM MCP   : get_customer_profile(customer_id)
       ├→ [2단계] MCP Client Tool → Ticketing : list_open_tickets(customer_id)
       └→ [3단계] MCP Client Tool → KB MCP    : search_solution(inquiry_text)
  └→ LLM으로 조회 결과를 종합해 응답 초안 생성
  └→ MCP 응답으로 반환

구성 요소	역할
`MCP Server Trigger`	Claude Desktop 또는 사내 AI가 호출하는 진입점
`AI Agent Node`	세 MCP 서버를 순서에 맞게 호출하는 오케스트레이터
`MCP Client Tool × 3`	각각 CRM, 티켓팅, 지식베이스 MCP 서버 연결

외부 AI는 resolve_customer_inquiry 하나만 알면 됩니다. CRM API 스펙이나 티켓 시스템의 인증 방식을 전혀 알 필요가 없습니다.

예시 2: 엔터프라이즈 도메인별 MCP 계층 구성

yaml

# docker-compose 예시 — 도메인별 MCP 서버 분리 배포
services:
  finance-mcp:
    image: finance-mcp-server:latest
    environment:
      XERO_API_KEY: ${XERO_API_KEY}
      QUICKBOOKS_TOKEN: ${QUICKBOOKS_TOKEN}
    ports:
      - "3001:3000"
 
  crm-mcp:
    image: crm-mcp-server:latest
    environment:
      HUBSPOT_API_KEY: ${HUBSPOT_API_KEY}
      SALESFORCE_TOKEN: ${SALESFORCE_TOKEN}
    ports:
      - "3002:3000"
 
  workspace-mcp:
    image: workspace-mcp-server:latest
    environment:
      GOOGLE_SERVICE_ACCOUNT: ${GOOGLE_SA_JSON}
    ports:
      - "3003:3000"
 
  n8n:
    image: n8nio/n8n:latest
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=0.0.0.0
    # n8n이 위 MCP 서버들을 MCP Client Tool 노드로 소비
    # MCP Client Tool 노드의 엔드포인트 URL을
    # http://finance-mcp:3000, http://crm-mcp:3000 등으로 설정
    networks:
      - mcp-network
 
  # finance-mcp, crm-mcp, workspace-mcp 서비스도 동일 네트워크에 포함
networks:
  mcp-network:
    driver: bridge

권장 도메인 분리 구조:
 
Finance MCP   ──→ Xero / QuickBooks / NetSuite
CRM MCP       ──→ HubSpot / Salesforce / Dynamics
Internal MCP  ──→ 사내 REST/GraphQL API
Workspace MCP ──→ Google Workspace / Microsoft 365
Comms MCP     ──→ Slack / Teams / Discord
      ↑
   n8n이 이 다섯 서버를 MCP Client Tool로 묶어 오케스트레이션
      ↓
외부 AI 에이전트에게는 고수준 비즈니스 도구만 노출

예시 3: AI 코딩 어시스턴트에서 배포 워크플로우 직접 트리거

json

// Claude Desktop의 claude_desktop_config.json
{
  "mcpServers": {
    "n8n-hub": {
      "command": "npx",
      "args": ["n8n-mcp", "--n8n-url", "https://your-n8n.domain.com"],
      "env": {
        "N8N_API_KEY": "your-api-key"
      }
    }
  }
}

장단점 분석

장점

항목	내용
단일 진입점	수백 개 외부 서비스를 n8n 인스턴스 하나로 통합. 서비스마다 MCP 서버를 따로 구축할 필요가 없습니다
인증 중앙화	모든 서비스 인증 키가 n8n 한 곳에서 관리됩니다. 인스턴스 레벨 MCP에서는 특히 효과적입니다
Tool Context Reduction	복잡한 다단계 작업을 단일 추상 도구로 래핑해 LLM 토큰 소비를 절감합니다
빠른 프로토타이핑	525개 이상 내장 노드 덕분에 코드 한 줄 없이 MCP 도구를 즉시 구성할 수 있습니다
크로스 시스템 추론	단일 요청 안에서 여러 도메인 시스템을 연계 처리하는 에이전트를 쉽게 만들 수 있습니다
클라이언트 호환성	Claude Desktop, Cursor, Windsurf, VS Code Copilot 등 주요 MCP 클라이언트와 즉시 동작합니다
운영 단순성	n8n 인스턴스가 살아있으면 MCP 서버도 자동으로 동작합니다. 별도 서버 프로세스 관리가 필요 없습니다

단점 및 주의사항

항목	내용	대응 방안
STDIO 불가	SSE, Streamable HTTP만 지원. STDIO 기반 MCP 서버와 직접 통합이 안 됩니다	Streamable HTTP로 마이그레이션 계획 수립
로드 밸런싱 복잡	SSE는 동일 서버 인스턴스에서 지속 연결 유지 필요. 다중 레플리카 환경에서 `/mcp*` 경로를 단일 레플리카로 라우팅해야 합니다	인그레스 또는 Nginx에서 sticky session 설정
컨텍스트 지속성 부재	기본적으로 워크플로우 단계 간 메모리가 없는 무상태 구조입니다	별도 메모리 노드(Postgres, Redis) 또는 외부 벡터 DB 연동
도구 정의 고정성	노출하는 도구의 스키마가 미리 고정되어야 합니다. 런타임 동적 도구 생성이 어렵습니다	범용 도구로 설계하거나 워크플로우 버전 분리로 대응
에이전트 성숙도	멀티 에이전트 플래닝이나 재시도 전략이 3단계 이상 중첩되는 복잡한 시나리오에서 커스텀 프레임워크 대비 한계가 있습니다	해당 복잡도부터는 MCP SDK 직접 구현 병행 고려
Cloudflare 프록시 이슈	SSE 연결이 역방향 프록시에서 타임아웃되거나 차단되는 사례가 보고됩니다	Cloudflare에서 SSE 경로 타임아웃 조정 또는 Streamable HTTP 전환

SSE와 Streamable HTTP의 차이 SSE(Server-Sent Events)는 서버→클라이언트 단방향 스트리밍 연결을 유지하는 HTTP 기반 프로토콜입니다. n8n의 MCP 전송 방식으로 현재 지원되지만, MCP 사양에서는 레거시 전송 방식으로 분류됐으며 신규 구현에는 Streamable HTTP가 권장됩니다. Streamable HTTP는 지속 연결 없이 요청마다 스트리밍을 처리해 프록시 환경에서 훨씬 안정적으로 동작합니다.

실무에서 가장 흔한 실수

모든 워크플로우를 단일 MCP Server Trigger 하나에 몰아넣기. 도구가 20개를 넘으면 에이전트의 도구 선택 정확도가 떨어지기 시작합니다. 인스턴스 레벨 MCP를 쓸 때는 특히, 활성화 워크플로우 수가 무제한으로 노출될 수 있으니 도메인 단위로 트리거를 분리하거나 노출 범위를 명시적으로 제어하는 것을 권장합니다.
인스턴스 레벨 MCP와 단일 워크플로우 방식의 차이를 모르고 선택하기. 인스턴스 레벨은 중앙화된 인증 관리와 활성화된 워크플로우를 일괄 노출할 때 유리하고, 단일 워크플로우 방식은 특정 도구의 동작을 세밀하게 제어할 때 유리합니다. 둘을 혼용하면 노출 범위가 의도치 않게 넓어질 수 있습니다. 첫 설계 때 이 선택을 명시적으로 하지 않으면 나중에 도구 목록이 왜 이렇게 많이 노출되는지 추적하기 어려워집니다.
프로토타이핑 구성 그대로 프로덕션에 올리기. n8n이 단일 장애점이 되는 구조인 만큼, 고가용성 구성 없이 프로덕션 트래픽을 받으면 n8n 재시작 한 번에 연결된 AI 에이전트 전체가 멈춥니다. 최소한 헬스체크와 재시작 정책은 미리 설정해두는 것을 권장합니다.

마치며

지금 바로 시작해볼 수 있는 3단계:

docker run -it --rm -p 5678:5678 n8nio/n8n 으로 로컬 n8n 인스턴스를 띄운 뒤, 새 워크플로우에 MCP Server Trigger 노드를 추가해 첫 MCP 도구를 노출해볼 수 있습니다.
Claude Desktop의 claude_desktop_config.json에 n8n MCP 서버를 등록해 AI 클라이언트에서 실제로 도구가 인식되는지 확인해볼 수 있습니다. czlonkowski/n8n-mcp 패키지를 npx로 실행하면 별도 서버 없이 n8n 워크플로우 목록을 자동으로 도구로 인식합니다.
n8n 공식 템플릿 #4475(MCP server with AI agent as a tool context reducer)를 불러와 Tool Context Reduction 패턴이 실제로 어떻게 구성되는지 뜯어보는 것을 권장합니다. 좋은 출발점이 됩니다.

참고 자료

입문

공식

심화

#n8n#MCP#AIAgent#WorkflowAutomation#ToolContextReduction#LLM#오케스트레이션#Docker#SSE#StreamableHTTP

핵심 개념

MCP가 뭔지 먼저 짚고 넘어가면

n8n이 MCP의 양방향 역할을 동시에 한다는 게 핵심

인스턴스 레벨 MCP vs. 단일 워크플로우 MCP

Tool Context Reduction — 이게 진짜 핵심 가치입니다

실전 적용

예시 1: 고객 문의 통합 해결 에이전트

예시 2: 엔터프라이즈 도메인별 MCP 계층 구성

예시 3: AI 코딩 어시스턴트에서 배포 워크플로우 직접 트리거

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

핵심 개념

MCP가 뭔지 먼저 짚고 넘어가면

n8n이 MCP의 양방향 역할을 동시에 한다는 게 핵심

인스턴스 레벨 MCP vs. 단일 워크플로우 MCP

Tool Context Reduction — 이게 진짜 핵심 가치입니다

실전 적용

예시 1: 고객 문의 통합 해결 에이전트

예시 2: 엔터프라이즈 도메인별 MCP 계층 구성

예시 3: AI 코딩 어시스턴트에서 배포 워크플로우 직접 트리거

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

추천 포스트

로컬 LLM 벤치마크 해석법 — 양자화·런타임별 실측 비교로 내 VRAM에 맞는 모델 고르기 (2026)

Ollama vLLM 전환은 언제? — 동시 사용자 수로 결정하는 LLM 서빙 선택 기준

Ollama + MCP tool calling 연결 (2026): 로컬 LLM이 파일·Git·DB를 직접 다루는 에이전트 구성

Claude Desktop × n8n: 자연어 한 마디로 워크플로를 직접 실행하는 MCP 역방향 연동

n8n AI Agent + MCP로 멀티에이전트 오케스트레이션 설계하기 — 계층화 아키텍처와 실무 함정

n8n MCP 셀프호스팅 연동: AI가 자연어로 워크플로우를 설계하고 배포하는 구조 (71노드 프로덕션 사례 포함)