9 분 소요

🔌 n8n 으로 MCP 서버 만들기 (전체 5편)

  1. 전체 그림 — 프로토콜과 n8n 안의 세 가지 자리 ← 지금 글
  2. 첫 서버 만들기 — MCP Server Trigger 와 도구 연결
  3. 도구 설계 — 이름·스키마·출력 예산·오류
  4. 연결과 디버깅 — Claude Code·Desktop·n8n 에이전트
  5. 운영 — 프록시·스케일·실행 데이터·보안

Summary

n8n 으로 MCP 서버를 하나 세우는 것 자체는 노드 하나면 끝나요. 진짜 문제는 그다음입니다 — 에이전트가 그 도구를 안 부르거나, 엉뚱하게 부르거나, 잘 부르다가 연결이 툭툭 끊기죠.

그래서 이 시리즈는 5편입니다.

1편은 개념과 지형도. MCP 가 뭐고, 전송 방식이 왜 두 개뿐이고, n8n 안에 왜 ‘MCP’ 가 세 군데나 있는지. 2편은 만들기. MCP Server Trigger 로 실제 동작하는 서버 하나. 3편은 도구 설계. 에이전트가 실제로 잘 쓰는 도구의 조건. 4편은 연결과 디버깅. Claude Code·Desktop 에 붙이고, 안 될 때 원인 가르기. 5편은 운영. 프록시·스케일·실행 데이터·보안.

이 1편에서 제일 중요한 건 마지막 섹션이에요. n8n 문서에서 ‘MCP’ 라는 말이 세 가지 다른 물건을 가리킵니다. 여기서 잘못 짚으면 2편부터 계속 엉뚱한 URL 을 붙들고 씨름하게 돼요. 실제로 커뮤니티 질문의 상당수가 이 혼동입니다.

💡 이 글에서 다루는 것

  • MCP 를 한 문장으로 — 호스트·클라이언트·서버, 그리고 JSON-RPC
  • 서버가 내주는 세 가지(Tools·Resources·Prompts)와 그중 실제로 쓰이는 것
  • 전송 방식은 두 개뿐 — stdio 와 Streamable HTTP. SSE 는 어디로 갔나
  • 스펙 버전 연대기와 2026-07-28 에서 세션이 사라진 것의 실무 의미
  • 🚨 n8n 안의 ‘MCP’ 세 자리 — Server Trigger / Client Tool / 인스턴스 레벨 서버
  • n8n 으로 MCP 를 만드는 게 맞는 경우와, 그냥 코드로 짜는 게 나은 경우
  • 이 시리즈에서 실제로 지을 예제



1. MCP 를 한 문장으로

MCP(Model Context Protocol) 는 LLM 애플리케이션과 외부 데이터·도구를 잇는 열린 프로토콜입니다. 공식 스펙은 이걸 이렇게 설명해요 — “AI 애플리케이션 생태계에 컨텍스트와 도구를 통합하는 방식을 표준화한다”, 그리고 LSP(Language Server Protocol) 에서 영감을 받았다고 명시합니다.

LSP 비유가 핵심이에요. LSP 이전에는 (에디터 × 언어) 조합마다 플러그인을 따로 만들어야 했죠. LSP 이후엔 언어 서버 하나가 모든 에디터에 붙습니다. MCP 도 똑같은 걸 (AI 앱 × 도구) 조합에 대해 하려는 겁니다.

등장인물은 셋입니다.

역할 무엇 예
호스트(Host) 연결을 시작하는 LLM 앱 Claude Code, Claude Desktop
클라이언트(Client) 호스트 안의 커넥터 호스트가 서버마다 하나씩 띄움
서버(Server) 컨텍스트·기능을 제공 우리가 n8n 으로 만들 것

메시지 형식은 JSON-RPC 2.0 이고, UTF-8 인코딩이 필수입니다.

이 시리즈에서 우리 자리는 서버예요. n8n 워크플로를 도구로 포장해서 밖에 내놓는 쪽입니다.


2. 서버가 내주는 세 가지 — 그리고 실제로 쓰이는 것

스펙상 서버는 클라이언트에게 이 셋 중 아무거나 제공할 수 있어요.

기능 무엇인가 누가 쓰나
Tools 모델이 실행하는 함수 모델
Resources 컨텍스트·데이터 사용자 또는 모델
Prompts 템플릿 메시지·워크플로 사용자

반대로 클라이언트가 서버에게 제공하는 기능도 있습니다 — Elicitation, 서버가 사용자에게 추가 정보를 되물을 수 있는 기능이에요.

현실에서 90% 는 Tools 입니다. 그리고 n8n 의 MCP Server Trigger 가 노출하는 것도 정확히 도구예요. n8n 공식 문서는 이 노드를 두고 “일반 트리거 노드와 달리 도구 노드에만 연결되고 도구 노드만 실행한다” 고 못 박습니다. 클라이언트는 도구 목록을 받아가고, 개별 도구를 호출하죠.

이게 무슨 뜻이냐면 — MCP Server Trigger 뒤에 Set 노드나 IF 노드를 줄줄이 붙여도 실행되지 않습니다. 이 노드는 “다음 노드로 흘려보내는” 트리거가 아니에요. 2편에서 이 구조를 그림으로 봅니다.


3. 전송 방식은 두 개뿐 — SSE 는 어디로 갔나

이 부분이 인터넷 자료에서 제일 많이 틀립니다. 정리하면 이래요.

현행 스펙(2026-07-28)이 정의하는 표준 전송은 정확히 둘입니다.

전송 형태 어디에 쓰나
stdio 클라이언트가 서버를 자식 프로세스로 띄우고 표준입출력으로 통신 로컬 서버
Streamable HTTP 단일 MCP 엔드포인트에 HTTP POST. 응답은 JSON 또는 SSE 스트림 원격 서버

그리고 HTTP+SSE 는 별도 전송이 아닙니다. 정확한 연혁은 이렇습니다.

시점 무슨 일
프로토콜 2024-11-05 HTTP+SSE 전송이 정의됨 (엔드포인트 2개)
프로토콜 2025-03-26 Streamable HTTP 가 이를 대체. 이전 것은 deprecated
이후 하위 호환용 “구형 전송” 으로만 남음

스펙 원문 표현이 명확해요 — Streamable HTTP 항목에 “This replaces the HTTP+SSE transport from protocol version 2024-11-05” 라고 붙어 있습니다.

헷갈리기 쉬운 지점: Streamable HTTP 도 SSE 를 씁니다. 다만 전송 방식으로서 쓰는 게 아니라, 서버가 응답을 스트리밍하고 싶을 때 선택적으로 Content-Type: text/event-stream 으로 돌려주는 겁니다. 그래서 클라이언트는 POST 할 때 Accept 헤더에 application/json 과 text/event-stream 둘 다 넣어야 해요. 이건 스펙상 MUST 입니다.

4편의 디버깅에서 이 Accept 헤더가 실제로 등장합니다. curl 로 손으로 찔러볼 때 이걸 빼먹으면 서버가 400 이나 406 을 뱉거든요. “인증이 틀렸나?” 하고 엉뚱한 데를 파게 됩니다.

그럼 n8n 은? n8n 공식 문서는 MCP Server Trigger 가 SSE 와 Streamable HTTP 를 모두 지원하고, stdio 는 지원하지 않는다고 적고 있습니다. 즉 n8n 은 구형 SSE 호환 경로를 아직 유지하고 있는 상태예요. 새로 만든다면 Streamable HTTP 를 기본으로 잡고, SSE 는 옛 클라이언트용 호환 모드로 두는 게 맞습니다.

stdio 미지원이 의미하는 건 하나 더 있어요 — stdio 만 말하는 클라이언트는 n8n 에 직접 못 붙습니다. 중간에 mcp-remote 같은 게이트웨이를 하나 세워야 하죠. 4편에서 그 설정이 나옵니다.


4. 스펙 버전 — 지금 어디까지 왔고, 왜 알아야 하나

MCP 의 버전은 YYYY-MM-DD 문자열이고, 하위 호환이 깨지는 변경이 마지막으로 일어난 날짜를 뜻합니다. 호환되는 개선은 버전을 올리지 않아요.

현재 current 는 2026-07-28 입니다.

여기서 실무적으로 중요한 변화가 하나 있어요.

세대 세션 버전 알림
2025-11-25 이하 initialize 핸드셰이크 + Mcp-Session-Id 헤더로 연결 단위 세션 초기화 때 한 번 협상
2026-07-28 무상태(stateless). 프로토콜 수준 세션 없음 요청마다 버전을 실어 보냄

2026-07-28 부터는 모든 요청이 _meta 필드의 io.modelcontextprotocol/protocolVersion 으로 자기 버전을 선언하고, 서버가 요청마다 개별적으로 수락/거부합니다. Streamable HTTP 에서는 같은 값이 MCP-Protocol-Version 헤더로도 실려요. 서버가 지원 안 하면 UnsupportedProtocolVersionError 를 지원 버전 목록과 함께 돌려주고, 클라이언트가 재시도하는 구조입니다. 미리 알고 싶으면 server/discover 라는 필수 RPC 한 번으로 지원 버전·기능·신원을 다 받아올 수 있고요.

왜 이걸 알아야 하나요?

지금 이 순간, 여러분의 클라이언트와 n8n 서버가 서로 다른 세대일 가능성이 매우 높습니다. 클라이언트는 최신 세대인데 n8n 은 세션 기반 세대일 수 있어요. 이건 고장이 아니라 정상적인 하위 호환 동작입니다. 스펙 자체가 구세대 감지와 폴백 절차를 정의해 두고 있어요.

그래서 4편에서 curl 로 직접 찔러볼 때 어떤 세대로 응답이 오는지부터 확인합니다. 세션 ID 를 요구하면 구세대, 안 요구하면 신세대. 이 한 번의 확인이 이후 디버깅을 반으로 줄여줍니다.

또 하나 — 2026-07-28 스펙은 코어 밖에 확장(extension) 개념을 두고 있습니다. 비동기 장기 실행을 위한 Tasks, 에이전트 워크플로 지침을 위한 Skills over MCP, 대화 안에 UI 를 렌더링하는 MCP Apps 같은 것들이죠. 전부 opt-in 이고 초기화 때 양쪽이 합의해야 켜집니다. n8n 워크플로는 실행이 길어지는 경우가 잦아서 Tasks 는 앞으로 눈여겨볼 만해요.


5. 🚨 n8n 안의 ‘MCP’ 세 자리 — 이 글의 핵심

여기가 이 시리즈에서 제일 많은 시간을 아껴줄 섹션입니다. n8n 문서를 읽다 보면 ‘MCP’ 가 세 가지 다른 물건을 가리켜요.

이름 n8n 의 역할 무엇을 노출하나
MCP Server Trigger 노드 서버 그 워크플로에 붙인 도구들
MCP Client Tool 노드 클라이언트 남의 MCP 서버 도구를 n8n 에이전트에게
인스턴스 레벨 n8n MCP 서버 서버 n8n 인스턴스 자체를 조작하는 도구들

하나씩 갈라 봅니다.

5-1. MCP Server Trigger 노드 — “내 워크플로를 도구로 판다”

우리가 2편에서 만들 것. 워크플로 안에 이 트리거를 놓고 도구 노드를 붙이면, 그 워크플로가 MCP 서버 하나가 됩니다. 인증(Bearer 또는 Header), URL 경로, 테스트/프로덕션 URL 이 노드 안에 다 있어요.

범위가 워크플로 하나라는 게 핵심입니다. 도구 세트를 나누고 싶으면 워크플로를 나눠서 서버를 여러 개 만들면 돼요.

5-2. MCP Client Tool 노드 — “남의 도구를 내 에이전트에게”

방향이 반대입니다. n8n 안의 AI Agent 노드에 붙는 서브노드로, 외부 MCP 서버에 접속해서 그쪽 도구를 에이전트가 쓰게 해줘요.

파라미터는 SSE 엔드포인트, 인증(Bearer / 헤더 / 다중 헤더 / OAuth2 / 없음), 그리고 Tools to Include — All, Selected, All Except 로 노출 범위를 고를 수 있습니다.

이 Tools to Include 는 사소해 보이지만 3편의 핵심 주제와 직결돼요. 도구가 많을수록 에이전트가 헷갈립니다. 남의 서버가 도구 60개를 내주면 그중 3개만 골라 쓰는 게 거의 항상 낫습니다.

5-3. 인스턴스 레벨 n8n MCP 서버 — “n8n 자체를 조작한다”

이건 여러분이 만드는 게 아니라 n8n 이 이미 갖고 있는 것입니다. Settings > Instance-level MCP 에서 Enable MCP access 를 켜면(인스턴스 소유자/관리자 권한 필요) 인스턴스 전체에 대해 MCP 엔드포인트가 하나 열려요.

엔드포인트는 https://<your-n8n-domain>/mcp-server/http 이고, 인증은 OAuth(권장) 또는 개인 액세스 토큰 + Authorization: Bearer 입니다.

여기서 내주는 도구는 여러분의 비즈니스 로직이 아니라 n8n 을 다루는 도구예요 — 워크플로 검색·상세 조회·실행·테스트·게시/게시 취소·버전 diff, 실행 이력 조회, 자격증명 목록(비밀값은 노출 안 함), 노드 검색과 워크플로 생성/수정 같은 빌더 도구들, 에이전트 관리 도구까지. 문서 기준 60개가 넘습니다.

중요한 안전장치가 하나 있어요 — 대부분의 도구는 availableInMCP: true 로 표시된 리소스에만 동작합니다. 예외는 search_workflows 와 search_agents 로, 사용자가 “아 이걸 MCP 에 열어야겠구나” 를 알 수 있도록 접근 가능한 전체를 돌려줍니다.

갈라 쓰는 기준

하고 싶은 일 쓸 것
내 업무 로직을 도구로 노출 MCP Server Trigger
n8n 에이전트에게 외부 도구 붙이기 MCP Client Tool
Claude 로 n8n 워크플로를 만들고 고치기 인스턴스 레벨 MCP

세 개는 동시에 쓸 수 있고, 서로 대체재가 아닙니다. 실제로 좋은 조합은 이래요 — 인스턴스 레벨 MCP 로 Claude 에게 워크플로를 짜게 하고, 그 워크플로에 MCP Server Trigger 를 붙여 업무 도구로 내놓는 것.


6. n8n 으로 MCP 를 만드는 게 맞나 — 정직한 판단표

n8n 이 항상 답은 아닙니다. 저울을 정직하게 놓아 볼게요.

상황 n8n 코드로 직접
도구가 SaaS API 호출 위주 ✅ 자격증명·노드가 이미 있음 ❌ 인증 다시 구현
실행 이력·재시도가 필요 ✅ Executions 탭이 공짜 ❌ 직접 만들어야
비개발자도 도구를 고쳐야 함 ✅ 캔버스에서 수정 ❌ 배포 필요
도구 로직이 순수 계산 ⚠️ 과함 ✅ 함수 몇 줄
ms 단위 지연이 중요 ❌ 큐 경유 오버헤드 ✅
도구 수십 개를 코드로 관리 ❌ 캔버스가 터짐 ✅ 테스트·버전관리
stdio 로컬 서버가 필요 ❌ 미지원 ✅

정리하면 — “이미 n8n 에 연결해 둔 시스템을 에이전트에게 열어주는” 용도라면 n8n 이 압도적으로 빠릅니다. 반대로 도구가 순수 로직이고 개수가 많다면 코드로 짜세요. 실제 이 블로그의 부동산 MCP 도 파이썬 코드입니다 — 표준 라이브러리 몇 줄이면 되는 일에 n8n 을 세울 이유가 없었거든요.

⚠️ 그리고 하나 미리 말해두면, n8n 큐 모드에서는 웹훅을 메인/웹훅 프로세스가 받고 실제 실행은 워커에게 넘어갑니다. n8n 문서가 직접 “약간의 오버헤드와 지연이 더해질 수 있다” 고 적어요. 도구 호출 하나하나에 이 지연이 붙는다는 뜻입니다. 5편에서 다룹니다.


7. 이 시리즈에서 실제로 지을 것

추상적으로 가면 안 남아요. 그래서 하나를 끝까지 지어볼 겁니다.

“사내 부동산 조회 MCP” — 에이전트에게 실거래·단지정보를 물어보면, n8n 이 공공 API 를 대신 때리고 정리해서 돌려주는 서버.

도구는 셋으로 시작합니다.

도구 이름 하는 일 입력
search_region_code 지역명 → 법정동 코드 지역명
get_apartment_trades 아파트 실거래 조회 지역코드, 연월
summarize_price_trend 월별 시세 요약 지역코드, 개월수

작지만 이 셋에 시리즈의 쟁점이 다 들어 있어요 — 코드 룩업(에이전트가 자주 틀리는 것), 페이지네이션되는 대용량 응답(토큰 예산), 그리고 여러 번 호출해야 하는 집계(도구 조합).

3편에서 이 도구들을 일부러 못 만든 버전과 잘 만든 버전으로 나란히 놓고 채점합니다.


8. 남은 4편이 뭘 채우나

편 채우는 것
2편 Server Trigger 파라미터, 도구 노드 연결, $fromAI()
3편 도구 이름·설명·스키마·출력 예산·오류 설계
4편 클라이언트 연결 설정과 고장 원인 가르기
5편 리버스 프록시, 큐 모드, 실행 데이터, 보안

2편부터는 손을 움직입니다.



참고 문서

이 글의 사실 관계는 아래 공식 문서에 기대고 있어요. 버전이 빠르게 움직이는 영역이라, 실제 작업 전에 한 번씩 다시 확인하시길 권합니다.

참고

(5/5) n8n MCP 서버 운영 — 프록시·큐 모드·실행 데이터·보안 경계

12 분 소요

데모로 도는 MCP 서버와 운영에서 버티는 MCP 서버를 가르는 것들. nginx 버퍼링, 큐 모드에서 /mcp* 를 한 레플리카로 묶는 규칙, 동시성·타임아웃, 조용히 쌓이는 실행 데이터, 그리고 토큰 경계와 프롬프트 인젝션까지 공식 문서 기준으로 정리합니다.

(2/5) n8n MCP 서버 만들기 — Server Trigger, 도구 연결, 그리고 $fromAI()

10 분 소요

MCP Server Trigger 노드 하나로 n8n 워크플로를 MCP 서버로 바꿉니다. Path·인증·두 개의 URL 이 각각 언제 살아나는지, 도구를 붙이는 세 가지 방법이 어떻게 다른지, 그리고 $fromAI() 가 도구 입력 스키마를 만드는 방식과 그 함정까지 정확히 짚습니다.