Claude Desktop × n8n: 자연어 한 마디로 워크플로를 직접 실행하는 MCP 역방향 연동
n8n을 한 번이라도 써봤다면 이런 생각을 해봤을 겁니다. "이미 만들어둔 워크플로가 수십 개인데, Claude한테 말 한 마디로 실행시킬 수 없을까?" 저도 처음엔 Webhook 방식부터 떠올렸는데, 금방 한계에 부딪혔습니다. Webhook은 URL 구조와 파라미터를 호출하는 쪽에서 미리 알고 있어야 하지만, MCP는 Claude가 "어떤 도구가 있는지" 먼저 발견(discovery)하고 상황에 맞게 알아서 선택해서 호출합니다. 이 차이 하나가 사용 경험을 완전히 바꿔놓습니다.
이 글은 n8n 워크플로를 한 번이라도 만들어본 개발자를 대상으로, n8n의 MCP Server Trigger 노드로 워크플로를 AI 도구로 노출하고 Claude Desktop이 자연어 지시만으로 그 워크플로를 직접 트리거하는 역방향 통합 구조를 로컬 환경에서 구성하는 방법을 다룹니다. 원리 설명부터 실제 설정 파일, 운영 환경 nginx 설정, 자주 터지는 함정까지 한 번에 살펴볼 예정입니다.
n8n을 MCP 서버로 전환하면 이미 구축해둔 모든 자동화 워크플로가 Claude의 네이티브 도구가 되어, 코드 한 줄 없이 자연어만으로 복잡한 업무 자동화를 실행할 수 있습니다. 다만 Claude Desktop과 n8n 사이에 트랜스포트 브릿지가 필요하고, 로컬 환경에서는 ngrok 같은 터널링 도구가 필수라는 점은 미리 알아두시면 좋습니다.
핵심 개념
MCP가 뭔지 먼저 짚고 가기
MCP(Model Context Protocol)는 Anthropic이 2024년 11월에 공개한 오픈 표준입니다. AI 모델과 외부 시스템 사이의 공통 통신 규약인데, USB-C 비유가 딱 맞습니다. 디바이스마다 다른 케이블을 쓰는 게 아니라 USB-C 하나로 다 연결하듯, MCP를 지원하는 클라이언트라면 어떤 AI든 동일한 방식으로 외부 도구를 호출할 수 있습니다.
MCP 3요소: Host (Claude Desktop 같은 AI 앱), Client (Host 내부에서 MCP 연결을 관리하는 컴포넌트), Server (도구를 노출하는 외부 프로세스). n8n은 이 구조에서 Server 역할을 맡습니다.
n8n MCP Server Trigger가 하는 일
MCP Server Trigger는 2025년 4월 n8n 공식 코어에 추가된 노드입니다. 워크플로 최상단에 이 노드를 올려두면, 그 워크플로 전체가 MCP 서버의 도구(tool) 하나로 외부에 노출됩니다. 노드를 저장하는 순간 고유 엔드포인트 URL이 발급되는 구조입니다.
/mcp/{unique-id} ← SSE 방식 (Server-Sent Events)
/mcp/{unique-id}/messages ← Streamable HTTP 방식두 URL은 같은 워크플로에 대한 서로 다른 트랜스포트 방식입니다. Claude Desktop 설정에서 어떤 URL을 쓰느냐에 따라 트랜스포트가 결정됩니다. 현재 n8n 공식 문서는 SSE 엔드포인트(/mcp/{id})를 기준으로 안내하고 있어서, 이 글의 예시도 SSE 기반으로 진행합니다. Streamable HTTP를 사용하려면 /messages 경로가 붙은 URL을 설정에 넣으면 됩니다.
솔직히 처음 이 노드를 봤을 때 "이게 뭐가 다른 거지?" 싶었는데, 핵심은 워크플로를 API가 아닌 MCP 도구로 노출한다는 점입니다. API는 클라이언트가 URL 구조를 알아야 호출할 수 있지만, MCP 도구는 Claude가 어떤 도구가 있는지 자동으로 발견하고 상황에 맞게 알아서 선택해서 호출합니다.
역방향 통합의 아키텍처
기존 n8n 사용 패턴은 "n8n이 외부 API를 호출"하는 단방향입니다. 역방향 통합은 그 반대, 외부 AI 에이전트가 n8n 워크플로를 실행합니다.
사용자 (자연어 지시)
↓
Claude Desktop (MCP 클라이언트)
↓ MCP 프로토콜 (SSE / Streamable HTTP)
n8n MCP Server Trigger 노드
↓
n8n 워크플로 실행 (이메일 발송, DB 조회, API 호출 등)
↓ 결과 반환
Claude Desktop (응답 표시)여기서 한 가지 캐치가 있습니다. Claude Desktop은 내부적으로 stdio(표준 입출력) 기반으로 MCP와 통신하는데, n8n은 SSE 또는 Streamable HTTP 기반입니다. 두 트랜스포트가 달라서 직접 연결이 안 됩니다. 이 간극을 mcp-remote라는 브릿지 패키지가 메워줍니다.
mcp-remote: Claude Desktop의 stdio 요청을 받아 n8n의 HTTP/SSE 엔드포인트로 중계해주는 얇은 프록시 패키지입니다.
npx mcp-remote <URL>형태로 실행되며, Node.js 18 이상이 필요합니다.
실전 적용
예시 1: 로컬 n8n ↔ Claude Desktop 기본 연결
가장 먼저 해야 할 일은 n8n을 로컬에서 띄우는 겁니다. Docker를 쓰는 쪽이 환경 격리 측면에서 더 깔끔합니다.
# Docker로 n8n 실행
docker run -it --rm \
--name n8n \
-p 5678:5678 \
-v ~/.n8n:/home/node/.n8n \
docker.n8n.io/n8nio/n8n
# 또는 npx로 빠르게 띄우기 (Node.js 18+ 필요)
npx n8n| 플래그 | 역할 |
|---|---|
--rm |
컨테이너 종료 시 컨테이너 자체를 자동 삭제. 단, -v로 볼륨이 마운트되어 있어 워크플로 데이터는 호스트의 ~/.n8n에 그대로 유지됩니다 |
-p 5678:5678 |
호스트의 5678 포트를 컨테이너의 5678 포트에 연결 |
-v ~/.n8n:/home/node/.n8n |
워크플로 데이터를 호스트에 영구 보존 |
n8n이 localhost:5678에서 올라오면, 새 워크플로를 만들고 MCP Server Trigger 노드를 최상단에 배치합니다. 노드를 활성화하면 이런 URL이 생성됩니다.
http://localhost:5678/mcp/abc123def456Claude Desktop은 로컬호스트에 직접 접근하지 못하기 때문에, ngrok으로 퍼블릭 URL을 만들어야 합니다.
# ngrok 설치 후 터널 오픈
ngrok http 5678
# 출력 예시:
# Forwarding https://xxxx-xx-xx-xx-xx.ngrok-free.app -> http://localhost:5678n8n API 토큰 발급: Claude Desktop에서 인증하려면 Bearer 토큰이 필요합니다. n8n 웹 UI에서 Settings → API → Personal API Token 경로로 들어가면 발급할 수 있습니다. 여기서 받은 토큰을 아래 설정 파일에 넣으면 됩니다.
이제 Claude Desktop 설정 파일을 편집합니다. Mac 기준 경로는 아래입니다.
~/Library/Application Support/Claude/claude_desktop_config.json{
"mcpServers": {
"n8n-workflows": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://xxxx-xx-xx-xx-xx.ngrok-free.app/mcp/abc123def456",
"--header",
"Authorization: Bearer YOUR_N8N_API_TOKEN"
]
}
}
}| 항목 | 설명 |
|---|---|
mcpServers 키 |
Claude Desktop이 인식하는 MCP 서버 목록 |
command: "npx" |
mcp-remote를 노드 프로세스로 실행 |
-y |
설치 확인 없이 자동 진행 |
--header + Authorization: ... |
배열의 별개 원소로 넣으면 mcp-remote CLI가 --header "Authorization: Bearer ..." 형태로 해석합니다 |
설정 저장 후 Claude Desktop을 완전히 종료했다가 다시 시작하면, 채팅 입력창 근처에 n8n 워크플로가 도구로 인식된 표시가 나타납니다.
예시 2: 실제 워크플로 연결 — Slack 보고 자동화
이 패턴은 제가 실무에서 가장 자주 활용하는 시나리오입니다. 예전에 매주 월요일 아침마다 직접 DB 쿼리를 돌리고 결과를 슬랙에 복붙하던 작업을, 이 구조로 바꾸고 나서 "지난주 판매 데이터 #report 채널에 올려줘" 한 마디로 끝낼 수 있었습니다. 처음엔 진짜 되나 싶어서 반신반의하며 설정했는데, 실제로 돌아가는 순간 꽤 감동이었습니다.
이 예시는 Slack 봇 연동과 PostgreSQL 연결이 n8n에 이미 설정되어 있다는 가정 하에 진행합니다.
n8n 워크플로는 이렇게 구성합니다.
[MCP Server Trigger]
↓
[PostgreSQL — 지난주 데이터 조회]
↓
[Code 노드 — 집계 및 포맷팅]
↓
[Slack — 채널에 메시지 발송]
↓
[Respond to MCP — Claude에게 결과 반환]여기서 마지막 Respond to MCP 노드가 매우 중요합니다. 이 노드가 없으면 n8n이 워크플로를 실행하고도 Claude에게 결과를 돌려보내지 않아서, Claude Desktop은 응답을 무한정 기다리게 됩니다. Slack 발송이 완료됐다는 사실도, 어떤 데이터가 처리됐는지도 Claude는 알 수 없는 상태가 되죠. 워크플로 마지막 노드로 Respond to MCP를 반드시 달아두어야 하는 이유입니다.
MCP Server Trigger 노드의 도구 설명(Tool Description) 필드를 잘 써두는 것도 핵심입니다. Claude는 이 설명을 읽고 어떤 상황에 이 도구를 호출할지 판단하기 때문입니다.
도구 이름: weekly-sales-report
도구 설명: 지난주 판매 데이터를 PostgreSQL에서 조회하고
집계한 결과를 지정된 Slack 채널로 발송합니다.
채널명을 파라미터로 받을 수 있습니다.설정이 완료되면 Claude Desktop에서 이렇게 입력해볼 수 있습니다.
지난주 판매 데이터 #general 채널에 보내줘Claude가 도구 목록을 훑어보고 weekly-sales-report가 적합하다고 판단하면, MCP 프로토콜로 n8n에 호출 요청을 보내고 워크플로가 실행됩니다.
운영 환경 고려사항
nginx 리버스 프록시에서 SSE 설정하기
로컬을 벗어나 팀 서버에 n8n을 올리고 nginx를 앞에 두는 경우, SSE 스트림 관련 설정을 반드시 추가해야 합니다. 솔직히 이 부분은 저도 처음에 그냥 지나쳤다가 "왜 Claude가 응답을 안 받지?" 하고 두 시간 넘게 헤맸습니다. nginx 기본 설정은 응답을 버퍼링하는데, SSE는 스트리밍 방식이라 버퍼링이 걸리면 Claude가 이벤트를 전달받지 못하고 무한 대기 상태에 빠집니다.
location /mcp/ {
proxy_pass http://localhost:5678;
proxy_http_version 1.1;
# SSE 스트리밍을 위해 버퍼링 비활성화
proxy_buffering off;
proxy_cache off;
# gzip 압축 비활성화 (SSE 이벤트 스트림이 압축되면 청크 단위 전달이 깨짐)
gzip off;
# HTTP/1.1 hop-by-hop Connection 헤더를 비워서
# nginx가 업스트림 연결을 임의로 끊지 않게 함
# 이 설정이 없으면 keep-alive 협상이 방해받아 SSE 스트림이 중단될 수 있음
proxy_set_header Connection '';
proxy_set_header X-Accel-Buffering no;
proxy_read_timeout 86400s;
proxy_send_timeout 86400s;
}proxy_set_header Connection ''의 역할이 처음엔 직관적으로 이해가 안 될 수 있습니다. HTTP/1.1에서 Connection 헤더는 hop-by-hop 헤더 목록을 지정하는 역할을 하는데, 이를 비워두지 않으면 nginx가 업스트림 서버와의 연결 협상을 방해해서 SSE 스트림이 중간에 끊길 수 있습니다. 이 한 줄이 없어서 SSE가 예상대로 동작하지 않는 경우가 꽤 흔하니 빠뜨리지 않도록 주의가 필요합니다.
장단점 분석
장점
| 항목 | 내용 |
|---|---|
| 자연어 제어 | "이메일 보내줘", "DB 조회해줘" 한 마디로 복잡한 워크플로가 실행됨 |
| 기존 자산 재활용 | 이미 만들어둔 n8n 워크플로를 코드 변경 없이 AI 도구로 즉시 전환 가능 |
| 세밀한 권한 제어 | 노출할 워크플로를 명시적으로 지정, 불필요한 워크플로는 비활성화로 차단 |
| 멀티 클라이언트 호환 | Claude Desktop, Cursor, Windsurf, VS Code Copilot 등 MCP를 지원하는 어떤 클라이언트에서도 동일하게 동작 |
| 벤더 독립성 | 오픈 표준 프로토콜이라 특정 AI 서비스에 종속되지 않음 |
단점 및 주의사항
| 항목 | 내용 | 대응 방안 |
|---|---|---|
| 트랜스포트 브릿지 필수 | Claude Desktop(stdio)과 n8n(SSE/HTTP) 간 직접 연결 불가 | mcp-remote 패키지를 중간 프록시로 사용 |
| ngrok 의존성 | 로컬 n8n에 Claude Desktop이 직접 접근 불가 | ngrok 상시 실행 또는 팀 서버에 n8n 배포 |
| SSE 세션 고착 | 큐 모드(멀티 레플리카) 운영 시 로드밸런서 설정이 복잡해짐 | Streamable HTTP 트랜스포트로 전환 권장 |
| 리버스 프록시 설정 | nginx 기본 설정이면 SSE 버퍼링으로 무한 대기 발생 | proxy_buffering off 및 gzip 비활성화 필수 |
| 보안 관리 | Bearer 토큰이 설정 파일에 평문으로 들어감 | 환경변수 분리, 개발/운영 토큰 별도 관리, .gitignore 등록 |
Streamable HTTP란?: SSE를 대체하는 MCP 최신 트랜스포트 방식입니다. SSE는 서버→클라이언트 단방향 스트림이라 멀티 레플리카 환경에서 세션 관리가 복잡한 반면, Streamable HTTP는 단일 HTTP 연결로 양방향 스트리밍을 처리해 로드밸런서 환경에서 훨씬 안정적입니다. n8n의 Streamable HTTP 지원은 커뮤니티에서 활발히 논의 중이니 신규 프로젝트라면 업데이트를 주기적으로 확인해보시는 것이 좋습니다.
트러블슈팅
실제로 설정하면서 가장 많이 걸리는 지점 세 가지입니다. 검색해도 잘 안 나오는 내용인데, 직접 겪어보니 이 세 가지가 시간을 가장 많이 잡아먹었습니다.
1. Claude Desktop 재시작을 빠뜨리는 경우
설정 파일을 수정했는데 도구가 나타나지 않는다면, 거의 대부분 재시작 문제입니다. Claude Desktop을 그냥 창만 닫는 게 아니라 트레이 아이콘까지 완전히 종료하고 다시 열어야 변경이 반영됩니다. 저도 이거 때문에 한 시간을 날렸습니다. 설정은 맞는데 왜 안 되지 싶다면 재시작부터 확인해보시면 좋습니다.
2. ngrok URL이 재시작 때마다 바뀌는 경우
무료 플랜 ngrok은 재시작할 때마다 URL이 달라집니다. claude_desktop_config.json의 URL도 매번 업데이트해야 하는데, 이걸 잊어버리고 "왜 안 되지?" 하는 경우가 많습니다. 안정적인 운영을 원한다면 ngrok 유료 플랜의 고정 도메인을 사용하거나, 아예 팀 서버에 n8n을 배포해두는 쪽이 낫습니다.
3. 도구 설명(Tool Description)을 대충 써두는 경우
MCP Server Trigger 노드의 도구 설명이 빈약하면 Claude가 어떤 상황에 이 도구를 써야 할지 판단을 못합니다. "이 도구가 무엇을 하는지, 어떤 파라미터를 받는지, 어떤 상황에 쓰면 되는지"를 구체적으로 적어두는 것이 핵심입니다. 짧고 모호한 설명은 Claude가 도구를 발견하더라도 제대로 활용하지 못하는 결과로 이어집니다.
마치며
n8n MCP Server Trigger는 수십 개의 자동화 워크플로를 단번에 AI 도구로 전환해주는 가장 실용적인 방법 중 하나입니다. 이미 n8n 워크플로를 운영하고 있다면 추가 개발 비용 없이 Claude Desktop 연동만으로 자연어 기반 자동화 환경을 만들 수 있습니다.
시작해볼 수 있는 3단계를 정리해보면:
-
최소 동작부터 확인 —
npx n8n으로 로컬에 올리고, 결과가 눈에 바로 보이는 간단한 워크플로(Slack 알림, Google Sheets 쓰기 등)에 MCP Server Trigger와 Respond to MCP를 붙여서 Claude Desktop과 연결이 되는지 확인해보시면 좋습니다. 처음 연결이 성공하는 순간 감이 많이 옵니다. -
보안 설정 잡기 — Bearer 토큰을 환경변수로 분리하고
.gitignore에 등록해두는 것은 빠를수록 좋습니다. 개발 단계부터 이 습관을 들여두면 나중에 팀 서버로 옮길 때 훨씬 수월합니다. -
클라이언트 범위 넓히기 — 기본 연동이 안정되면 Cursor나 Windsurf 같은 IDE 클라이언트에도 동일한 n8n 엔드포인트를 등록해볼 수 있습니다. 코딩 중에 자연어로 DB를 조회하거나 슬랙 알림을 보내는 경험이 꽤 새롭습니다. 더 나아가 n8n의 MCP Client Tool 노드를 활용하면 n8n이 다른 MCP 서버의 도구를 소비하는 양방향 구조도 가능합니다.
참고 자료
- MCP Server Trigger node documentation | n8n 공식 문서
- Set up and use n8n MCP server | n8n 공식 문서
- n8n MCP server tools reference | n8n 공식 문서
- Connect Claude Desktop App to MCP Server Trigger node | n8n Community Forum
- n8n MCP Server Trigger with Claude: Complete Setup Guide | Synta
- n8n as an MCP Hub — Give Claude Control Over Your Entire Workflow Stack 2026 | Nerd Level Tech
- n8n as Agentic MCP Hub: When Workflow Automation Learns to Think | Infralovers
- How to Start Your Own MCP Server with n8n | DEV Community
- mcp n8n: ultimate guide to connect Claude to your workflows | Agence Scroll
- Supercharge AI Agents with n8n and MCP: A Developer's Guide | Medium
- Bridging MCP Transports: Turning an STDIO Server into SSE | Medium
- Monitor & debug n8n workflows with Claude AI assistant and MCP server | n8n 워크플로 템플릿
- GitHub - czlonkowski/n8n-mcp
- GitHub - ahmadsoliman/mcp-n8n-server