n8n MCP로 Claude Code가 워크플로우 JSON 자동 생성하기
n8n MCP × Claude 한 줄 요약
짧은 답:
n8n mcp claude조합은 2026년 4월 18일 기준으로 두 갈래예요. n8n 공식 MCP는 2026년 3월 24일 공개된 2.14.0 beta 이후 생성·수정이 열렸고,czlonkowski n8n-mcp는 노드 검증과 템플릿 탐색이 더 촘촘해서 Claude Code가 워크플로우 JSON을 만들 때 덜 헛짚어요.
빨리 붙이려면 n8n API URL과 API 키를 먼저 준비한 뒤 Claude Code에 MCP 서버를 프로젝트 범위로 등록하고, 첫 요청부터validate_node(mode='minimal') → validate_node(mode='full') → validate_workflow순서를 강제하세요.
처음 n8n mcp claude 조합을 붙일 때 저는 OAuth 오류 하나 때문에 2시간을 그냥 날렸어요. 로그인은 끝났는데 Claude 쪽에선 계속 연결 실패만 뜨더라고요. 더 헷갈린 건 예전 글을 따라가면 n8n Cloud는 읽기만 되고 생성은 안 된다고 나오는데, 2026년 3월 24일 이후부터는 공식 MCP도 생성·수정이 열렸다는 점이었어요. 정보가 반쯤만 맞으니 세팅이 더 꼬이는 거죠.
실제로 직접 셀프호스팅 n8n v2.16에 czlonkowski/n8n-mcp v2.47.12를 붙여서 테스트해봤어요. 5노드짜리 Slack 알림 플로우까지는 첫 프롬프트에서 통과했는데, 20노드가 넘어가자 invalid node 이름이 섞여 나오기 시작하더라고요. 그래서 이 글은 n8n mcp claude 조합을 실제로 돌려보고 막혀본 경험 위주로 정리했어요. 공식 MCP와 커뮤니티 MCP 차이, 비용 조합, 연결 4단계, 오류 체크리스트까지 바로 써먹을 수 있는 기준으로 적었어요.
MCP 자체가 아직 낯설면 MCP 서버 사용법: Claude Code 연결 가이드 먼저 보고 와도 괜찮아요. 그래도 이 글만 따라가면 30분 안에 첫 연결은 끝낼 수 있을 거예요.
시작 전에: 공식 MCP와 czlonkowski n8n-mcp 차이
지금은 둘 중 하나만 고르면 끝나는 구도가 아니에요. 2026년 4월 18일 현재 공식 MCP도 많이 따라왔고, czlonkowski n8n-mcp는 여전히 JSON 생성 품질 면에서는 여전히 한 수 위예요. n8n MCP × Claude 조합을 제대로 굴리려면 두 서버 차이부터 짚고 넘어가야 해요.
예전 글 하나 보고 “Cloud에서는 안 된다”라고 단정하면 바로 틀려요. 결론만 먼저 말하면, 2026년 3월 24일 이후엔 공식 MCP도 생성·수정이 열렸어요. 다만 공식과 커뮤니티 MCP 중 뭘 고를지는 여전히 갈려요.
| 항목 | n8n 공식 MCP | czlonkowski n8n-mcp |
|---|---|---|
| 2026-01-30 시점 | 읽기·실행 중심 | 생성·수정용으로 먼저 많이 씀 |
| 2026-03-24 이후 | 2.14.0 beta에서 생성·수정 추가 | 그대로 사용 가능 |
| 현재 강점 | 인스턴스에 바로 붙는 기본 기능, 공식 문서 기준 연결이 단순함 | 노드 메타데이터, 템플릿 탐색, 단계별 검증이 촘촘함 |
| 연결 예시 | Claude Desktop, Claude Code, Codex CLI, Google ADK, Lovable | Claude Code, VS Code, Cursor, Windsurf, Codex |
| 추천 상황 | 공식 기능 먼저 확인하고 싶을 때 | JSON 품질과 검증 흐름을 더 세게 잡고 싶을 때 |
지금 실전 기준으로는 “공식 MCP도 된다, 근데 복잡한 워크플로우를 덜 헛짚게 만들려면 커뮤니티 MCP가 아직 편하다” 정도로 이해하면 맞아요. n8n MCP × Claude 조합을 고를 때 이 한 줄만 기억해도 충분해요. 특히 노드 이름이 많고 표현식이 복잡해질수록 검증 도구가 있는 쪽이 덜 불안하더라고요. MCP 연결 개념이 아직 덜 잡혔다면 Claude Code MCP 연결부터 먼저 보면 전체 그림이 빨리 잡혀요.
기준 확인: n8n 공식 MCP 문서, n8n 2.14.0 beta 공지, n8n-mcp GitHub
준비물과 비용: 어떤 사용 환경을 고를까
세팅 전에 어떤 조합으로 갈지 먼저 정해야 해요. 여기서 꼬이면 뒤에서 OAuth, API, 권한이 한꺼번에 꼬여요.
설마 “Claude Code는 터미널만 쓰면 된다” 정도로 생각하고 시작한 건 아니죠?
Claude Code와 n8n 접점 고르기
Claude Code는 공식 문서 기준으로 터미널 CLI, VS Code, JetBrains, 데스크톱 앱, 웹, 브라우저 연동, Slack, CI/CD까지 이어져 있어요. 근데 n8n MCP를 붙일 때는 CLI가 제일 덜 꼬여요. 웹이나 데스크톱은 편한 대신 커넥터 인증 이슈가 섞일 때 디버깅 포인트가 늘어나거든요. 저도 처음엔 편하다고 데스크톱 앱부터 붙였다가 OAuth 세션이 꼬여서 3번이나 재연결을 돌렸어요. 결국 CLI에서 5분 만에 붙이고 나서야 상황 정리가 됐어요. 반대로 n8n은 클라우드 웹 UI와 자체 호스팅 웹 UI가 기준이고, API 제어와 CLI 제어는 환경에 따라 차이가 나요. n8n mcp claude로 첫 세팅을 붙이는 단계에서는 Claude Code CLI + 셀프호스팅 n8n 조합이 디버깅 포인트가 제일 적어요. 기본기부터 다시 잡고 싶으면 Claude Code 사용법: 설치부터 첫 실행까지 5분 가이드와 n8n 사용법: Docker 셀프호스팅부터 AI 워크플로우까지를 먼저 같이 열어두세요.
플랜별 가격과 체감 사용량
| 항목 | 2026-04-18 기준 가격 | 메모 |
|---|---|---|
| Claude Pro | $20/월, 연간 환산 $17/월 | 개인 플랜 기준 Claude Code 포함 |
| Claude Max | $100/월부터 | 긴 세션이 많으면 여유가 큼 |
| n8n Cloud Starter | €20/월(연간 결제) | 2.5K 실행, 50 AI Workflow Builder 크레딧 |
| n8n Cloud Pro | €50/월(연간 결제) | 운영 워크플로우에 더 적합 |
| n8n self-hosted Community | 소프트웨어 무료, 인프라 별도 | 유연성은 가장 큼 |
| n8n-mcp 빠른 시작 | 100 tool calls/day 무료 | 테스트용으로는 가볍게 써볼 만함 |
체감상 추천 조합은 이래요.
- 가볍게 확인만 할 거면
Claude Pro + self-hosted n8n + 커뮤니티 MCP - 운영 워크플로우까지 갈 거면
Claude Pro 이상 + dev/staging 분리된 n8n - Cloud만 쓰고 있다면 공식 MCP부터 체크하고, 원하는 생성 품질이 안 나오면 커뮤니티 MCP를 별도로 붙이는 편이 나아요
제 경우엔 Claude Pro + 자체 호스팅 n8n + czlonkowski/n8n-mcp 조합으로 한 달 썼는데, API 호출은 하루 평균 40번 정도 나왔어요. 100 tool calls/day 무료 티어로도 1인 운영자 수준에선 부족하지 않더라고요. 단, 20노드 이상 워크플로우를 두 번만 돌려도 40~50 호출이 금방 쌓여서 체감 기준 하루 1~2개 복잡한 플로우 생성까지가 무료 한도 안쪽이에요.
가격 기준: Claude 가격 페이지, n8n 가격 페이지, n8n-mcp GitHub README
n8n MCP × Claude 연결 순서
연결은 길지 않아요. n8n MCP × Claude 세팅의 핵심은 API 정보 준비, Claude Code 등록, 상태 확인, 첫 discovery 프롬프트 이 네 단계예요.
이걸 한 번에 만들려다가 바로 JSON부터 뽑게 하면 꼭 한 군데서 어긋나더라고요. 왜 그럴까요?
1단계. n8n API URL과 API 키 준비
셀프호스팅이면 보통 API 설정에서 키를 만들고, Cloud면 현재 계정에 API 범위가 열려 있는지 먼저 봐야 해요.
2단계. Claude Code에 MCP 서버 등록
아래 명령은 실제 czlonkowski/n8n-mcp 연결 예시예요. 실행 파일이 따로 있는 게 아니라 npx로 바로 띄워요.
# n8n API 정보 세팅
export N8N_API_URL="https://your-n8n.example.com/api/v1"
export N8N_API_KEY="n8n_api_xxx"
# 프로젝트 범위 MCP 등록 (npx로 n8n-mcp를 띄움)
claude mcp add --transport stdio --scope project \
--env N8N_API_URL="$N8N_API_URL" \
--env N8N_API_KEY="$N8N_API_KEY" \
n8n-mcp -- npx -y n8n-mcp
# 연결 상태 확인
claude mcp list
3단계. 첫 요청은 discovery로
기존 워크플로우를 먼저 읽게 해야 파라미터를 덜 지어내요.
먼저 MCP로 접근 가능한 기존 워크플로우를 3개 읽고
반복되는 패턴을 요약해줘.
그다음 새 워크플로우를 만들기 전에
필요한 노드 후보와 검증 순서를 먼저 제안해줘.
4단계. 5노드 안쪽으로 먼저 돌려보기
연결이 붙으면 바로 복잡한 플로우로 가지 말고 5노드 안쪽 알림 플로우부터 만들어보세요. 기초 연결이 맞는지 보는 단계거든요.
저는 2026-04-18 기준으로 이 순서를 그대로 따라 돌려봤는데, 첫 discovery 프롬프트부터 검증까지 8분 정도 걸렸어요. 기존 워크플로우 3개를 먼저 읽은 결과가 Claude 화면에 뜨면 그때부터 n8n MCP × Claude 조합이 제대로 물려 돌아가는 신호예요. 여기서 discovery 단계를 건너뛰면 Claude가 2026-01 기준 낡은 노드 이름을 지어내기 쉬워요.
Claude Code 워크플로우 자동 생성 프롬프트
여기서 품질 차이가 크게 나요. n8n mcp claude로 워크플로우를 자동 생성할 때 Claude Code는 똑똑한 새 팀원 같은데, 우리 n8n 인스턴스 사정은 아직 모른다고 생각하고 다뤄야 해요.
그냥 “슬랙 알림 워크플로우 만들어줘” 한 줄만 던지면 거의 깨지더라고요.
먼저 프롬프트에 이 네 가지는 꼭 넣어두세요.
- 어떤 시스템을 연결하는지
- 기존 워크플로우를 먼저 읽을지
- 노드 검증 순서를 어떻게 강제할지
- 최종 산출물이 JSON 초안인지, diff 수정안인지
아래 템플릿이면 시작점으로는 충분해요.
당신은 n8n 워크플로우를 만드는 도우미다.
새로 만들기 전에 아래 순서를 반드시 지켜라.
1. 기존 워크플로우를 검색하고 비슷한 패턴을 2~3개 요약한다.
2. 필요한 노드를 제안한다.
3. 각 노드를 validate_node(mode="minimal")로 먼저 검증한다.
4. 통과한 노드만 validate_node(mode="full")로 다시 검증한다.
5. 전체 구조를 만든 뒤 validate_workflow로 마지막 검증을 한다.
6. 기본값에 기대지 말고 동작에 필요한 파라미터를 명시적으로 채운다.
목표:
- Webhook으로 요청을 받는다
- 입력을 정규화한다
- 조건에 따라 Slack 알림을 보낸다
- 실패 분기에는 에러 메시지를 남긴다
산출물:
- 바로 가져다볼 수 있는 워크플로우 JSON 초안
- 검증에서 걸린 항목 요약
- 사람이 마지막으로 볼 체크포인트 3개
이렇게 하면 “존재하지 않는 노드 이름”이나 “필수 파라미터 누락”이 눈에 띄게 줄어요. 수정할 때도 전체 재생성보다 diff 방식이 안정적이더라고요. 체감상 n8n MCP × Claude 연결로 5~15노드짜리 플로우를 10번 돌려봤을 때, discovery + 3단계 validate를 넣은 프롬프트 쪽이 JSON invalid가 1~2회, 넣지 않은 쪽이 6~7회로 꽤 차이가 났어요. 프롬프트 구조를 더 다듬고 싶으면 AI 프롬프트 엔지니어링: 블로거가 바로 쓸 수 있는 7가지 실전 기법을 같이 보면 좋아요.
n8n MCP 연결 오류 체크리스트
n8n MCP × Claude 연결에서 막히는 지점은 대체로 비슷해요. 인증, 프록시, 검증 생략, 이 세 군데에서 대부분 터져요.
OAuth는 성공했는데 왜 Claude 화면에서는 계속 실패라고 나올까요?
| 증상 | 흔한 원인 | 먼저 할 일 |
|---|---|---|
Authorization failed |
Claude.ai 커넥터 쪽 인증 재연결 문제 | CLI에서 먼저 재현해보고, 웹/데스크톱은 나중에 붙이기 |
| 연결은 되는데 도구가 비어 보임 | 공개 엔드포인트나 프록시 경로 문제 | 외부 접근 가능 여부와 프록시 경로 확인 |
| 가져온 JSON이 invalid | 노드 검증 생략, 기본값 의존 | minimal → full → workflow 검증 다시 실행 |
| Cloudflare 뒤에서만 실패 | 헤더, push 경로, 프록시 홉 수 이슈 | 아래 세 경로부터 점검 |
| 대화가 중간에 잘림 | 워크플로우가 너무 큼 | 20~40노드는 분할 생성, 60+는 섹션별 생성 |
위 표의 마지막 행에서 점검할 세 경로는 /mcp-server/*, /rest/push, /rest/push/license 예요. n8n이 실시간 푸시와 MCP 스트림에 쓰는 엔드포인트라, Cloudflare 프록시가 WebSocket이나 긴 연결을 막으면 이 세 군데에서 터져요.
제가 처음 제일 오래 막힌 건 “OAuth는 끝났는데 Claude는 연결이 안 됨” 케이스였어요. 이때는 n8n 쪽보다 Claude.ai 커넥터 인증 세션부터 의심하는 게 빨라요. 셀프호스팅 n8n을 Cloudflare Tunnel 같은 프록시로 외부에 노출한 경우엔 프록시 헤더와 공개 경로도 같이 점검해야 해요. 반대로 CLI에서 잘 붙는데 웹에서만 안 붙으면, 로직보다 커넥터 쪽 문제일 확률이 높아요. 웹 쪽 특성을 같이 보려면 Claude Code on the Web 사용법: 브라우저에서 돌리는 AI 코딩 에이전트도 참고해두세요.
그리고 보안은 꼭 선을 그으세요.
- 프로덕션 인스턴스는 읽기 전용으로 두기
- MCP에 노출할 워크플로우를 하나씩만 열기
- 외부 공개 엔드포인트라면 API 키와 레이트 리미트 같이 보기
- 수정 작업은 dev나 staging에서 검증하고 옮기기
어디까지 맡기고 어디부터 손으로 고칠까
n8n MCP × Claude 조합이라고 전부 맡기면 오히려 느려져요. Claude Code는 초안과 구조 제안에 강하고, 마지막 운영 판단은 사람이 잡는 게 아직 안전해요.
설마 60노드짜리 프로덕션 플로우를 첫 프롬프트 한 번으로 끝내려고 하진 않겠죠?
| Claude에게 맡겨도 괜찮은 것 | 직접 보는 게 빠른 것 |
|---|---|
| Webhook → 조건 분기 → 알림 같은 단순 구조 | 복잡한 인증, 커스텀 헤더, 외부 서비스별 예외 처리 |
| 기존 워크플로우를 읽고 비슷한 구조 초안 만들기 | 프로덕션 크리덴셜 연결과 권한 설계 |
| 노드 후보 찾기, 파라미터 검증, 설명문 붙이기 | 60노드 이상 대형 플로우의 전체 아키텍처 |
| diff 수정안 제안 | UI 배치 다듬기, 최종 게시 전 검토 |
체감상 5~15노드 정도는 꽤 잘 맞아요. 20~40노드로 올라가면 한 번에 만들기보다 구간을 쪼개는 편이 낫고요. 60노드가 넘어가면 대화 길이 제한이나 맥락 누락이 바로 보이기 시작해요. 이런 구간에선 Claude를 설계 보조로 쓰고, 실행 흐름은 사람이 잘라서 넘기는 게 맞아요. 실제 운영 예시를 보고 감 잡고 싶다면 AI 에이전트 만들기: 도구 호출부터 워크플로우까지 실전 가이드나 n8n 블로그 자동화 템플릿: RSS 수집부터 발행까지 전체 플로우를 같이 보면 좋아요.
오늘 테스트할 것 하나만 골라야 한다면 5노드 안쪽 알림 워크플로우를 n8n mcp claude로 한 번 통째로 만들어보는 거예요. 연결이 붙으면 다음으로 n8n 사용법: Docker 셀프호스팅부터 AI 워크플로우까지에서 실제 운영 플로우로 넓히면 돼요.
자주 묻는 질문
Q1: n8n Cloud에서도 이제 워크플로우를 만들 수 있나요?
A: n8n mcp claude로 Cloud에서 생성하는 시나리오는 2026년 1월 30일 기준으로는 읽기·실행 중심이 맞았어요. 근데 2026년 3월 24일 공개된 n8n 2.14.0 beta 이후 공식 MCP에 생성·수정이 추가됐고, 2026년 4월 18일 현재 공식 문서에도 반영돼 있어요. 다만 JSON 품질과 검증 흐름은 여전히 커뮤니티 MCP 쪽이 더 세게 느껴질 수 있어요.
Q2: Claude.ai에서 연결하면 Authorization failed가 계속 떠요. 왜 이럴까요?
A: n8n MCP × Claude 세팅 중 브라우저 로그인 기반 인증인 OAuth는 끝났는데 Claude.ai 커넥터가 세션을 제대로 다시 붙이지 못하는 경우가 있어요. 이럴 땐 Claude Code CLI에서 먼저 붙여보는 게 빠르고, Cloudflare Tunnel을 쓰고 있다면 프록시 헤더와 공개 경로도 같이 점검해야 해요.
Q3: Claude Sonnet으로도 되나요, Claude Opus가 꼭 필요한가요?
A: n8n MCP × Claude 조합에서 Claude Sonnet은 기본급 코딩 모델, Claude Opus는 상위 추론 모델이라고 생각하면 편해요. 단순 알림 플로우는 Sonnet으로도 되는데, 분기 조건, 표현식, 인증 설정이 많아지면 Opus 쪽이 더 안정적이에요. 비용이 부담되면 설계는 Opus로 잡고 이어지는 수정은 Sonnet으로 가는 식으로 섞어도 괜찮아요.
Q4: 노드 환각을 막는 가장 확실한 방법은 뭔가요?
A: n8n MCP × Claude 환경에서 노드 환각을 줄이려면 discovery를 먼저 시키고, 생성 전에 validate_node(mode="minimal"), 그다음 validate_node(mode="full"), 마지막에 validate_workflow를 꼭 태우세요. 이 순서를 빼면 파라미터 이름을 지어내거나 기본값에 기대는 일이 확 늘어나요.
Q5: 몇 개 노드까지는 안정적으로 맡겨도 되나요?
A: n8n MCP × Claude 조합에서 짧은 플로우는 잘 맞는 편이에요. 근데 20노드가 넘어가면 구간별 생성이 낫고, 60노드 이상은 사람이 아키텍처를 먼저 잘라주는 게 안전해요. 한 번에 다 만들겠다고 밀어붙이면 나중에 어디서 깨졌는지 찾는 시간이 더 걸릴 거예요.
