n8n MCP 셀프호스팅 연동: AI가 자연어로 워크플로우를 설계하고 배포하는 구조 (71노드 프로덕션 사례 포함)
자동화 도구를 쓸 때 가장 번거로운 순간이 언제냐고 물어보면 대부분 이렇게 답한다. "노드 하나 추가하려고 문서 뒤지다 30분 날렸어요." 솔직히 저도 그랬다. n8n을 처음 도입했을 때 노드 1,650개라는 숫자가 강점인지 약점인지 헷갈렸을 정도다.
그런데 MCP가 등장하면서 구조가 달라졌다. AI가 그 문서를 대신 읽고, 워크플로우를 직접 짜서 배포해주는 게 현실이 됐다. 오늘 다루는 건 두 가지다. n8n-MCP 통합이 어떤 원리로 동작하는지, 그리고 실제로 어떤 자동화를 만들어주는지. Claude Desktop이나 Cursor(AI 코드 에디터) 같은 도구를 이미 쓰고 있다면 오늘 설정만으로 바로 연결해볼 수 있다. 프로덕션에 71개 노드짜리 워크플로우를 배포한 팀이 이미 있는데, 어떻게 가능했는지 같이 들여다보자.
n8n-MCP의 핵심은 "AI가 자연어로 자동화를 설계·실행하고, n8n이 그 실행 엔진이 된다"는 한 문장으로 요약된다.
핵심 개념
n8n이 뭔지 잠깐 짚고 가자면
n8n은 Zapier나 Make의 셀프호스팅 대안으로 시작했지만 지금은 그 이상이다. 1,650개 이상의 노드, 2,352개 워크플로우 템플릿, Docker로 5분이면 띄울 수 있는 구조. 무엇보다 데이터가 내 서버 밖으로 나가지 않는다는 점이 엔터프라이즈 팀들이 선호하는 이유다.
2025년 하반기에 나온 n8n 2.0부터는 멀티에이전트 오케스트레이션(여러 AI 에이전트가 태스크를 분담하고 결과를 서로 전달하며 협력하는 아키텍처)을 위한 전용 AI Agent 노드와 MCP 네이티브 지원이 공식으로 들어왔다(n8n 공식 블로그). 단순한 트리거-액션 자동화 도구에서 AI 에이전트 실행 플랫폼으로 포지셔닝이 완전히 달라진 거다.
MCP가 무엇이고 왜 중요한가
MCP(Model Context Protocol): Anthropic이 설계하고 오픈 표준으로 공개한 프로토콜로, LLM이 외부 도구·파일·API에 표준화된 방식으로 접근할 수 있게 한다. USB-C처럼 "AI와 도구를 연결하는 공통 규격"이라고 이해하면 된다.
MCP 이전에는 AI가 외부 도구를 쓰려면 각 도구마다 다른 방식의 함수 호출 코드를 작성해야 했다. MCP는 이걸 표준화했다. 도구를 만드는 쪽(MCP Server)과 도구를 쓰는 쪽(MCP Client)이 같은 언어로 대화한다.
MCP 통신에서 사용하는 전송 계층은 **SSE(Server-Sent Events)**다. HTTP 기반 단방향 스트림으로, 서버가 클라이언트에 실시간으로 이벤트를 밀어보내는 방식이다. WebSocket보다 단순하고, MCP 표준에서 권장하는 방식이다.
Claude Desktop, Claude Code, Cursor, Windsurf(AI 코드 에디터) 같은 AI 클라이언트들이 MCP Client 역할을 하고, n8n-mcp 서버가 1,650개 노드 문서를 MCP Server로 노출하는 구조다.
n8n-MCP 통합의 두 갈래
통합 방식이 두 가지라서 처음엔 헷갈릴 수 있다.
| 방식 | 설명 | 주 사용 케이스 |
|---|---|---|
| czlonkowski/n8n-mcp | Claude·Cursor가 n8n 노드 파라미터 스키마를 직접 쿼리해 워크플로우를 생성·배포하는 MCP 서버 | 개발자가 AI로 워크플로우를 자동 생성할 때 |
| n8n 네이티브 MCP 지원 | n8n 내부에 MCP Server Trigger / MCP Client Tool 노드가 내장되어 n8n 자체가 MCP 허브로 동작 | n8n 워크플로우가 외부 MCP 서버 도구를 쓰거나 자신을 MCP 서버로 노출할 때 |
첫 번째가 "AI → n8n" 방향이라면, 두 번째는 "n8n ↔ MCP 생태계" 양방향이다.
czlonkowski/n8n-mcp가 1,650개 노드를 AI에 제공하는 방식은 RAG나 임베딩이 아니다. n8n 노드마다 정의된 파라미터 스키마 JSON을 인덱싱해 MCP 도구로 노출한다. AI는 필요한 노드 이름을 쿼리하면 해당 노드의 파라미터 목록·타입·필수값을 정확히 받아볼 수 있다. 추측 없이 실제 스키마를 참조하기 때문에 잘못된 파라미터가 들어갈 확률이 크게 떨어진다.
설치 및 연결 설정
n8n 셀프호스팅 띄우기
Docker Compose로 올리는 게 가장 일반적인 방법이다.
# docker-compose.yml — n8n 셀프호스팅 기본 설정
services:
n8n:
image: n8nio/n8n:latest
ports:
- "5678:5678"
environment:
- N8N_BASIC_AUTH_ACTIVE=true
- N8N_BASIC_AUTH_USER=admin
- N8N_BASIC_AUTH_PASSWORD=your_password
- WEBHOOK_URL=https://your-domain.com/
volumes:
- n8n_data:/home/node/.n8n
volumes:
n8n_data:docker compose up -d로 올리면 localhost:5678에서 바로 확인할 수 있다.
Claude Desktop에 n8n-mcp 연결하기
claude_desktop_config.json에 MCP 서버 설정을 추가하면 된다.
{
"mcpServers": {
"n8n": {
"command": "npx",
"args": ["-y", "n8n-mcp"],
"env": {
"N8N_API_URL": "https://your-n8n-instance.com/api/v1",
"N8N_API_KEY": "your_api_key_here"
}
}
}
}N8N_API_KEY 발급: n8n 대시보드 → Settings → API → Create API Key에서 받을 수 있다. 이 키가 있어야 AI가 워크플로우를 생성·수정·배포하는 권한을 갖는다.
Claude를 재시작하면 n8n_ 접두사가 붙은 도구들이 활성화된다. 이제부터 자연어로 워크플로우를 요청하면 AI가 노드 스키마를 참조해 JSON을 생성하고 직접 배포한다.
실전 적용
예시 1: Slack 메시지를 AI가 요약해 Notion에 저장하기
가장 먼저 해보기 좋은 케이스다. Claude Desktop에서 이렇게 입력하면 된다.
"#general 채널에 올라오는 메시지를 webhook으로 받아서
GPT-4o로 3줄 요약하고, Notion 데이터베이스에 날짜·원문·요약을 저장하는
n8n 워크플로우를 만들어줘"n8n-mcp는 내부적으로 이런 과정을 거친다.
1. n8n 노드 스키마 쿼리: Slack Trigger, OpenAI, Notion 노드 파라미터 확인
2. 워크플로우 JSON 생성: 노드 연결 구조 + 파라미터 매핑
3. n8n API 호출: POST /api/v1/workflows 로 워크플로우 생성
4. (선택) 워크플로우 활성화: PATCH /api/v1/workflows/{id}/activateAI가 만들어주는 워크플로우 JSON은 대략 이런 구조다.
{
"name": "Slack to Notion Summary",
"nodes": [
{
"id": "1",
"name": "Slack Trigger",
"type": "n8n-nodes-base.slackTrigger",
"position": [240, 300],
"parameters": {
"channel": "general",
"events": ["message"]
}
},
{
"id": "2",
"name": "Summarize with GPT-4o",
"type": "@n8n/n8n-nodes-langchain.openAi",
"position": [460, 300],
"parameters": {
"model": "gpt-4o",
"prompt": "다음 메시지를 3줄로 요약해줘:\n\n{{ $json.text }}"
}
},
{
"id": "3",
"name": "Save to Notion",
"type": "n8n-nodes-base.notion",
"position": [680, 300],
"parameters": {
"operation": "create",
"databaseId": "your-database-id",
"properties": {
"날짜": "{{ $now }}",
"원문": "{{ $('Slack Trigger').item.json.text }}",
"요약": "{{ $json.text }}"
}
}
}
],
"connections": {
"Slack Trigger": {
"main": [[{ "node": "Summarize with GPT-4o", "type": "main", "index": 0 }]]
},
"Summarize with GPT-4o": {
"main": [[{ "node": "Save to Notion", "type": "main", "index": 0 }]]
}
}
}{{ $json.text }}와 {{ $('Slack Trigger').item.json.text }}가 섞여 나오는데, 이건 의도된 차이다. Summarize with GPT-4o 노드에서 {{ $json.text }}는 바로 이전 노드(Slack Trigger)의 출력을 가리킨다. 반면 Save to Notion 노드에서 {{ $('Slack Trigger').item.json.text }}는 체인을 건너뛰어 원본 메시지를 명시적으로 다시 꺼내는 방식이고, 같은 노드의 {{ $json.text }}는 바로 앞 OpenAI 노드가 반환한 요약문이다. 같은 이름처럼 보여도 실행 컨텍스트에서 가리키는 값이 다르다.
예시 2: AI 기반 지원 티켓 자동 분류 (MCP Server Trigger 활용)
이건 n8n 네이티브 MCP 지원을 쓰는 케이스다. n8n 워크플로우 자체를 MCP 서버로 노출해서 외부 AI 에이전트가 호출하는 구조다. 실무에서 자주 맞닥뜨리는 상황인데, Slack의 특정 이모지 반응이 트리거가 되어 AI가 메시지 본문을 분석하고 Linear에 구조화된 티켓을 만드는 패턴이다.
n8n 캔버스에서 MCP Server Trigger 노드를 추가한 뒤 아래 설정을 입력하면 이 워크플로우가 외부에서 MCP 프로토콜로 호출 가능한 도구가 된다.
{
"toolName": "create_support_ticket",
"toolDescription": "Slack 메시지를 분석해 Linear에 지원 티켓을 생성합니다",
"inputSchema": {
"type": "object",
"properties": {
"message": { "type": "string", "description": "Slack 메시지 본문" },
"author": { "type": "string", "description": "메시지 작성자" }
},
"required": ["message"]
}
}이후 워크플로우 흐름은 이렇다.
{
"name": "Support Ticket Classifier",
"nodes": [
{
"id": "1",
"name": "MCP Server Trigger",
"type": "n8n-nodes-base.mcpTrigger",
"position": [240, 300]
},
{
"id": "2",
"name": "AI Agent",
"type": "@n8n/n8n-nodes-langchain.agent",
"position": [460, 300],
"parameters": {
"model": "claude-sonnet-4-5"
}
},
{
"id": "3",
"name": "Switch",
"type": "n8n-nodes-base.switch",
"position": [680, 300]
},
{
"id": "4",
"name": "Linear API",
"type": "n8n-nodes-base.linear",
"position": [900, 300]
}
],
"connections": {
"MCP Server Trigger": {
"main": [[{ "node": "AI Agent", "type": "main", "index": 0 }]]
},
"AI Agent": {
"main": [[{ "node": "Switch", "type": "main", "index": 0 }]]
},
"Switch": {
"main": [
[{ "node": "Linear API", "type": "main", "index": 0 }],
[{ "node": "Linear API", "type": "main", "index": 1 }],
[{ "node": "Linear API", "type": "main", "index": 2 }]
]
}
}
}AI Agent 노드의 모델로 Claude Sonnet을 선택했는데, 이건 고정값이 아니다. GPT-4o, Gemini, Ollama 로컬 모델도 지원된다. 분류 정확도와 API 비용의 균형을 보면서 골라볼 수 있다.
예시 3: 프로덕션 규모 — 71노드 데이터 파이프라인
이건 실제로 있었던 사례다(DEV.to 원문). 멀티브랜드 리테일 운영사가 Claude Opus를 셀프호스팅 n8n에 MCP로 연결해 만든 워크플로우인데, 규모가 남다르다.
- 735개 브랜드, 321,000개 이상의 바코드 데이터 처리
- 7개 AI 추출 파이프라인이 병렬로 동작
- Oracle EBS(Oracle의 엔터프라이즈 ERP 시스템) 호환 레코드로 변환해 적재
- 노드 수: 71개
저도 처음엔 "71노드를 AI가 설계한다고?" 했는데, 핵심은 AI가 한 번에 다 만든 게 아니라는 점이다. 개발자와 AI가 대화하면서 단계적으로 쌓아갔다. 실행 로그를 AI가 조회해서 에러를 찾아 수정하는 루프가 반복됐는데, 이게 생각보다 실용적이다. n8n-mcp는 최근 실행 로그 조회 기능을 제공하기 때문에, AI가 전체 JSON을 다시 보는 게 아니라 에러 난 부분만 타깃해서 수정한다. 토큰 효율 면에서도 훨씬 낫다. 이 루프를 직접 경험해보면 "AI가 만든다"는 표현의 실체가 얼마나 다른지 느낌이 달라진다.
장단점 분석
장점
| 항목 | 내용 |
|---|---|
| AI 오류율 감소 | 추측 대신 실제 노드 스키마를 참조하므로 잘못된 파라미터 생성이 크게 줄어든다 |
| 자연어 워크플로우 설계 | 비기술 인력도 자연어로 복잡한 자동화를 설계할 수 있다 |
| 양방향 MCP 허브 | n8n이 도구 소비자이자 공급자로 동작해 유연한 에이전트 아키텍처 구성이 가능하다 |
| 데이터 주권 | 워크플로우·자격증명·데이터가 외부 SaaS에 노출되지 않는다 |
| 실시간 에러 수정 | AI가 실행 로그를 조회해 타깃 수정이 가능하다 |
| 풍부한 생태계 | 1,650개 노드, 2,352개 템플릿, 커뮤니티 노드를 활용할 수 있다 |
단점 및 주의사항
| 항목 | 내용 | 대응 방안 |
|---|---|---|
| MCP 생태계 범위 | MCP 서버를 구현한 도구만 연동 가능하다 | Webhook 노드로 비MCP 도구를 브릿지할 수 있다 |
| n8n MCP 기능 제한 | 네이티브 MCP 지원은 Tools만 지원하고 Resources·Prompts는 미지원이다 | czlonkowski/n8n-mcp 같은 별도 MCP 서버를 조합해 커버할 수 있다 |
| 셀프호스팅 운영 부담 | 서버 관리·보안·업데이트를 직접 책임져야 한다 | n8n Cloud 플랜 또는 Kubernetes + Helm으로 관리형 인프라를 활용할 수 있다 |
| 학습 곡선 | MCP 프로토콜, n8n 노드 구조, AI 에이전트 설계를 동시에 이해해야 한다 | n8n 먼저, MCP 연결은 나중에 — 순서가 있다 |
| 공급자 의존성 | 외부 MCP 서버 장애가 워크플로우에 직접 영향을 준다 | 핵심 워크플로우는 MCP 없이도 동작하도록 fallback을 두는 것이 안전하다 |
실무에서 가장 흔한 실수
-
API Key를 워크플로우 JSON에 직접 하드코딩하는 경우 — 저도 초기에 API Key를 JSON에 그냥 넣었다가 낭패를 본 적이 있다. n8n의 Credentials 기능을 쓰면 자격증명이 암호화되어 저장되고, AI가 생성한 워크플로우에서도 안전하게 참조할 수 있다. Credentials를 먼저 만들어두면 이후 AI가 자동으로 참조한다.
-
MCP Server Trigger 노드를 활성화하지 않고 테스트하는 경우 — 워크플로우가 "활성" 상태여야 외부에서 MCP 호출이 들어온다. 개발 중에는
npx @modelcontextprotocol/inspector로 MCP 서버를 직접 디버깅해볼 수 있다. -
n8n 표현식 문법을 AI가 틀리게 쓰는 경우 —
{{ $json.field }}대신 구버전 문법인{{$node["NodeName"].json["field"]}}를 쓰거나, 존재하지 않는 필드를 참조하는 경우가 생긴다. 워크플로우 생성 후 n8n 캔버스에서 실행 결과를 한 번 확인해보는 것을 권장한다.
마치며
n8n-MCP는 "자동화를 자동화한다"는 말이 과장이 아닌 구조를 현실로 만들어준다. 2026년 5월 기준 n8n 고객의 75%가 AI 기능을 활성 사용 중이고(n8n 공식 블로그), czlonkowski/n8n-mcp는 AI 개발자 커뮤니티에서 빠르게 스타를 쌓으며 퍼져나가고 있다. MCP 생태계가 아직 모든 SaaS를 커버하지는 않지만, 방향은 분명하다.
지금 바로 시작해볼 수 있는 3단계가 있다.
-
n8n을 로컬에 띄우는 것부터 시작할 수 있다.
docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n n8nio/n8n한 줄로 로컬 인스턴스가 올라온다.localhost:5678에서 바로 확인할 수 있다. -
Claude Desktop의
claude_desktop_config.json에 n8n-mcp 서버를 추가해볼 수 있다. n8n에서 API 키를 발급받고, 위에서 소개한 설정 JSON을 붙여넣은 뒤 Claude를 재시작하면n8n_도구들이 활성화된다. -
"Slack 메시지를 받아서 Notion에 저장하는 워크플로우를 만들어줘"처럼 간단한 요청부터 시도해볼 수 있다. AI가 생성한 워크플로우 JSON을 n8n 캔버스에서 확인하고, 실행 로그로 동작을 검증하는 루프를 한 번 경험하고 나면 이후 복잡한 파이프라인도 같은 방식으로 접근할 수 있게 된다.