책에 포함된 노트혼자 일하는 사람의 n8n: AI 에이전트로 1인 회사를 시스템화하는 법

MCP로 n8n과 AI 도구를 하나로 묶기

2026-05-06Views 58약 11분생성형 AI 활용

AI에게 손발이 생기는 순간

지난 장에서 우리는 RAG로 회사의 기억을 시스템화했다. AI가 내 문서를 근거로 답하게 만들었다. 이것만으로도 큰 변화다. 그러나 아직 한계가 있다. 지식 에이전트는 '알려줄' 수는 있지만, 실제 업무를 '처리'하지는 못한다.

고객이 "제 인보이스 다시 보내주세요"라고 말했을 때, 지식 에이전트는 인보이스 재발급 방법을 설명할 수 있다. 하지만 결제 시스템에서 고객을 찾고, PDF를 다시 생성하고, 이메일로 보내고, 슬랙에 처리 내역을 남기려면 또 다른 구조가 필요하다. 이때 등장하는 것이 MCP다.

MCP, Model Context Protocol은 AI 모델과 외부 도구가 대화하는 표준 규칙이다. 어렵게 들리지만 비유하면 간단하다. 예전에는 프린터, 모니터, 외장하드마다 케이블이 달랐다. 지금은 USB-C 하나로 많은 장치를 연결한다. MCP는 AI 시대의 USB-C에 가깝다. Claude, Cursor, 코드 에디터, 내부 AI 시스템이 외부 도구를 같은 방식으로 발견하고 호출할 수 있게 해준다.¹

n8n과 MCP가 만나면 의미가 커진다. n8n은 이미 회사 업무를 자동화하는 실행 엔진이다. 이메일을 보내고, DB를 조회하고, Slack에 알리고, 결제 이벤트를 처리하고, 보고서를 만든다. MCP는 이 실행 엔진을 AI가 호출할 수 있는 도구 목록으로 바꿔준다. 다시 말해 n8n은 더 이상 "내가 클릭해서 실행하는 자동화 도구"에 머물지 않는다. Claude나 Cursor가 필요할 때 호출하는 회사 운영 API가 된다.

이 장의 목표는 MCP 문법을 깊게 파고드는 것이 아니다. 1인 회사 관점에서 "내가 만든 n8n 워크플로우를 AI 도구들이 어떻게 호출하게 만들 것인가"를 이해하는 것이다. MCP를 이해하면 자동화의 방향이 바뀐다. 사람이 n8n을 조작하는 단계에서, AI가 n8n을 도구처럼 사용하는 단계로 넘어간다.

MCP로 n8n과 AI 도구를 하나로 묶기

MCP를 이해하는 가장 쉬운 구조

MCP를 구성하는 기본 역할은 크게 둘이다. MCP 클라이언트는 도구를 쓰려는 쪽이다. Claude Desktop, Claude Code, Cursor, Windsurf, VS Code 같은 AI 도구가 여기에 해당한다. MCP 서버는 도구를 제공하는 쪽이다. 파일 시스템, 데이터베이스, 검색 API, GitHub, 그리고 n8n 워크플로우가 MCP 서버가 될 수 있다.

흐름은 다음처럼 생각하면 된다.

사용자 요청
→ Claude 또는 Cursor가 의도 파악
→ MCP 서버에 사용 가능한 도구 목록 요청
→ 알맞은 도구 선택
→ 파라미터와 함께 도구 호출
→ n8n 워크플로우 실행
→ 결과를 AI 도구로 반환
→ AI가 사용자에게 정리해 답변

예를 들어 Claude에게 이렇게 말한다고 해보자.

지난 7일간 신규 가입자 수와 결제 전환율을 확인해서 요약해줘.

MCP가 없다면 Claude는 말만 할 수 있다. "데이터베이스를 확인해야 합니다"라고 답할 것이다. MCP가 연결되어 있다면 다르다. Claude는 generate_growth_report라는 도구를 발견하고, period = last_7_days라는 파라미터로 호출한다. n8n은 DB에서 가입자와 결제 데이터를 가져오고, 전환율을 계산하고, 결과 JSON을 반환한다. Claude는 그 결과를 사람이 읽기 좋은 보고서로 바꾼다.

핵심은 AI가 모든 시스템에 직접 접근하는 것이 아니라는 점이다. AI는 MCP라는 표준 문을 통해, 우리가 허락한 도구만 호출한다. 그리고 그 도구의 실제 실행은 n8n이 담당한다. 이 분리가 중요하다. AI에게 결제 DB의 모든 권한을 주는 것이 아니라, "이 고객의 결제 상태를 조회하는 워크플로우"만 도구로 노출하는 식이다.

n8n과 MCP의 두 가지 방향

n8n에서 MCP를 쓰는 방식은 두 방향으로 나뉜다. 첫 번째는 n8n을 MCP 서버로 쓰는 방식이다. 이 경우 외부 AI 도구가 n8n 워크플로우를 호출한다. Claude나 Cursor 입장에서는 n8n이 여러 업무 도구를 제공하는 서버처럼 보인다.

두 번째는 n8n을 MCP 클라이언트로 쓰는 방식이다. 이 경우 n8n의 AI Agent가 외부 MCP 서버의 도구를 가져다 쓴다. 예를 들어 Brave Search MCP 서버, GitHub MCP 서버, Elasticsearch MCP 서버, 사내 DB MCP 서버를 n8n AI Agent에 붙여서 에이전트가 검색, 코드 저장소 관리, 문서 조회를 수행하게 만들 수 있다.

둘은 반대 방향처럼 보이지만 실제로는 함께 쓴다.

방향	n8n의 역할	예시	1인 회사에서의 의미
n8n as MCP Server	도구 제공자	Claude가 n8n의 고객 조회 워크플로우 호출	회사 운영 기능을 AI가 호출하게 함
n8n as MCP Client	도구 사용자	n8n AI Agent가 외부 검색 MCP 서버 호출	n8n 내부 에이전트의 능력을 확장함
n8n-mcp 외부 서버	워크플로우 제작 보조	Claude Code가 n8n 노드 검색, 워크플로우 생성, 검증	자동화 제작 자체를 AI와 함께 함

여기서 혼동하기 쉬운 이름이 있다. n8n-mcp라는 오픈소스 프로젝트는 n8n 자체를 MCP 도구로 제어하거나, AI가 n8n 노드 문서와 템플릿을 검색해 워크플로우를 만들도록 돕는 외부 MCP 서버다. 해당 프로젝트는 Claude Desktop, Claude Code, Cursor, Windsurf 같은 AI 환경에서 n8n 노드, 템플릿, 검증 도구를 사용할 수 있게 해준다.² 반면 n8n의 네이티브 MCP Server Trigger는 내가 만든 n8n 워크플로우를 MCP 도구로 외부에 노출하는 기능에 가깝다.³

둘 중 하나만 고르는 문제가 아니다. 워크플로우를 만들 때는 n8n-mcp가 유용하고, 만들어진 업무 기능을 Claude나 Cursor가 호출하게 할 때는 n8n의 MCP Server Trigger가 유용하다.

왜 MCP가 자동화 시장에서 중요해졌는가

이전에도 AI가 외부 도구를 호출하는 방법은 있었다. OpenAI의 function calling, Claude의 tool use, LangChain의 tools, 각 서비스의 플러그인 구조가 있었다. 문제는 모두 조금씩 달랐다는 점이다. 도구 하나를 만들 때마다 특정 AI 서비스에 맞춰 다시 감싸야 했다. Claude용으로 만든 도구를 Cursor에서 쓰려면 다시 연결해야 하고, 로컬 에디터에서 쓰려면 또 다른 설정이 필요했다.

MCP는 이 문제를 줄인다. 도구 제공자는 MCP 서버 형태로 기능을 공개하고, AI 도구는 MCP 클라이언트로 그 서버에 연결한다. 도구를 한 번 만들면 여러 AI 환경에서 재사용할 수 있다. n8n 입장에서 이것은 엄청난 변화다. 내가 만든 send_invoice, publish_blog_post, get_customer_profile, generate_daily_report 같은 워크플로우가 특정 챗봇에 묶이지 않고, MCP를 지원하는 여러 AI 도구에서 호출될 수 있기 때문이다.

1인 회사에는 세 가지 이점이 있다.

업무 기능을 한 번 만들고 여러 AI 도구에서 재사용할 수 있다.
Claude, Cursor, 코드 에디터, 내부 챗봇이 같은 n8n 워크플로우를 호출할 수 있다.
자연어 요청과 실제 업무 실행 사이에 n8n이라는 통제 가능한 실행 계층을 둘 수 있다.

마지막이 특히 중요하다. AI가 곧바로 모든 SaaS API를 만지는 구조는 위험하다. 반면 n8n 워크플로우를 도구로 노출하면, 입력 검증, 권한 확인, 로그 기록, 에러 처리, 알림을 워크플로우 안에 넣을 수 있다. AI는 "무엇을 할지" 판단하고, n8n은 "어떻게 안전하게 실행할지" 담당한다.

Claude와 Cursor에서 n8n 워크플로우를 호출하는 구조

Claude나 Cursor가 n8n 워크플로우를 호출하게 만드는 구조는 크게 세 단계다. 먼저 n8n에 MCP 서버 역할을 하는 허브 워크플로우를 만든다. 다음으로 실제 업무를 처리하는 하위 워크플로우를 만든다. 마지막으로 Claude나 Cursor가 그 MCP 서버 URL에 연결하도록 설정한다.

가장 단순한 구조는 다음과 같다.

Claude Desktop 또는 Cursor
→ MCP 연결 설정
→ n8n MCP Server Trigger
→ Call n8n Workflow Tool
→ 실제 업무 워크플로우
→ 결과 반환

n8n의 MCP Server Trigger는 외부 MCP 클라이언트가 접속할 수 있는 엔드포인트를 만든다. 여기에 Call n8n Workflow 같은 도구 노드를 연결하면, 특정 하위 워크플로우를 MCP 도구처럼 노출할 수 있다. n8n MCP 허브 예제에서는 Hacker News 상위 글을 가져오는 도구와 Slack 메시지를 보내는 도구를 만들고, Claude가 두 도구를 연속 호출해 뉴스 요약을 Slack에 보내는 구조를 보여준다.⁴

여기서 도구 설명이 매우 중요하다. AI는 도구 이름과 설명을 읽고 어떤 도구를 언제 쓸지 판단한다. 이름이 tool_1이고 설명이 "workflow 실행"이라면 AI는 제대로 선택하지 못한다. 반대로 이름이 fetch_top_news이고 설명이 "현재 Hacker News 상위 5개 글의 제목, URL, 점수, 댓글 수를 가져온다"라면 AI가 훨씬 정확하게 호출한다.

Cursor에서도 원리는 같다. Cursor는 코드 에디터 안에서 AI가 프로젝트 파일을 읽고 수정하는 도구다. 여기에 n8n MCP 서버를 붙이면, 코드를 작성하다가 필요한 운영 데이터를 n8n에서 가져오거나, 배포 후 알림 워크플로우를 실행하거나, 마케팅 리포트를 생성하는 흐름을 에디터 밖으로 나가지 않고 처리할 수 있다.

예를 들어 Cursor에서 이렇게 요청할 수 있다.

이번 PR에 포함된 변경사항을 요약하고, 릴리스 노트 초안을 만든 뒤, n8n의 release_note_to_slack 도구로 팀 채널에 보내줘.

Cursor는 코드 변경 사항을 읽고 요약한다. 그런 다음 MCP로 연결된 n8n 도구를 호출한다. n8n은 Slack 메시지를 보내고 Notion 릴리스 노트 페이지를 생성한다. 개발, 운영, 커뮤니케이션이 하나의 에이전트 흐름으로 묶인다.

첫 번째 패턴: MCP Server Trigger를 회사 운영 허브로 쓰기

MCP를 처음 도입할 때 추천하는 구조는 '허브와 도구' 패턴이다. 허브 워크플로우 하나가 MCP 서버 역할을 하고, 실제 기능은 각각 별도 워크플로우로 만든다. 허브에는 업무 로직을 많이 넣지 않는다. 허브는 도구 목록을 노출하고, 요청을 올바른 하위 워크플로우로 보내는 역할에 집중한다.

MCP Hub
├─ tool: get_customer_profile
├─ tool: generate_daily_report
├─ tool: publish_blog_post
├─ tool: send_slack_message
└─ tool: create_invoice

이 구조가 좋은 이유는 관리가 쉽기 때문이다. 고객 조회 로직을 수정해야 할 때 MCP 허브 전체를 건드릴 필요가 없다. Tool - Get Customer Profile 워크플로우만 수정하면 된다. 콘텐츠 발행 도구에 승인 단계를 추가하고 싶다면 Tool - Publish Blog Post만 바꾸면 된다.

각 하위 워크플로우는 When Executed by Another Workflow 트리거로 시작하게 만들 수 있다. MCP 허브의 도구 노드가 해당 워크플로우를 호출하고, 하위 워크플로우는 입력 파라미터를 받아 처리한 뒤 JSON 결과를 반환한다.

예를 들어 get_customer_profile 도구는 이렇게 설계한다.

When Executed by Another Workflow
→ Set: email 또는 customer_id 검증
→ Postgres 또는 Supabase: 고객 조회
→ IF: 고객 존재 여부 확인
→ Set: 반환 가능한 필드만 선택
→ Return: plan, signup_date, last_login, payment_status

여기서 중요한 것은 "반환 가능한 필드만 선택"하는 단계다. AI에게 고객 테이블 전체를 그대로 돌려주면 안 된다. 내부 메모, 결제 토큰, 민감한 개인정보는 제거해야 한다. MCP 도구는 편리하지만, 편리한 만큼 노출 범위를 더 엄격히 관리해야 한다.

두 번째 패턴: Webhook을 MCP 도구의 실행 입구로 쓰기

n8n의 모든 MCP 구성을 네이티브 MCP Server Trigger로만 해야 하는 것은 아니다. 이미 운영 중인 Webhook 워크플로우가 있다면, 외부 MCP 서버나 프록시가 MCP 도구 호출을 HTTP 요청으로 바꿔 n8n Webhook을 호출하는 구조도 가능하다.

이 방식은 단순하고 범용적이다.

MCP Client
→ MCP Server 또는 프록시
→ n8n Webhook
→ HTTP Request, DB, Slack, Email 등 실행
→ Webhook Response
→ MCP Client에 결과 반환

예를 들어 web-search라는 n8n Webhook 워크플로우를 만들고, 외부 MCP 서버가 이 Webhook을 하나의 도구로 등록할 수 있다. Claude가 검색 도구를 호출하면 MCP 서버가 n8n Webhook에 POST 요청을 보내고, n8n은 검색 API를 호출한 뒤 결과를 반환한다. 실제 사례에서도 n8n Webhook을 MCP 도구 실행 엔드포인트로 활용해 Claude Code에서 웹 검색 워크플로우를 호출하는 구조가 소개되어 있다.⁵

Webhook 패턴의 장점은 기존 자동화 자산을 재사용하기 쉽다는 것이다. 이미 POST /webhook/publish-blog 같은 워크플로우가 있다면, 그것을 MCP 도구로 감싸면 된다. 단, Webhook은 외부에서 호출 가능한 입구이므로 인증을 반드시 넣어야 한다. Header Auth나 Bearer Token을 사용하고, 가능하면 입력 스키마를 검증하자.

나쁜 Webhook 도구는 이런 식이다.

입력: 아무 JSON이나 받음
처리: 받은 값을 그대로 Slack이나 DB에 전달
인증: 없음
로그: 없음

좋은 Webhook 도구는 다르다.

입력: 정해진 필드만 허용
처리: 필수값 검증 후 실행
인증: Bearer Token 또는 Header Auth
로그: 요청자, 실행 시간, 결과, 에러 저장
제한: 위험 작업은 승인 단계 추가

AI가 호출하는 도구일수록 입구를 좁혀야 한다. 사람은 실수하면 바로 멈출 수 있지만, 에이전트는 잘못 이해한 상태로 여러 도구를 연속 호출할 수 있다.

세 번째 패턴: HTTP Request로 외부 MCP와 내부 API를 잇기

MCP 도구가 반드시 n8n 안에서 끝날 필요는 없다. n8n은 HTTP Request 노드로 외부 API를 호출하는 데 강하다. 따라서 MCP로 들어온 요청을 n8n에서 검증하고, 필요한 내부 API나 외부 SaaS API로 전달하는 구조를 만들 수 있다.

예를 들어 generate_monthly_report 도구는 다음처럼 구성할 수 있다.

MCP 도구 호출
→ 입력값 검증: month, report_type
→ HTTP Request: 내부 분석 API 호출
→ Google Sheets: 원본 데이터 추가 조회
→ AI 요약: 핵심 지표 해석
→ PDF 생성 또는 Google Docs 작성
→ Slack/Email 발송
→ 결과 URL 반환

이 구조에서 n8n은 접착제이자 안전장치다. Claude는 "지난달 리포트 만들어줘"라고 요청하지만, 실제로 어떤 API를 호출하고 어떤 문서 템플릿을 쓰고 어디에 저장할지는 n8n이 결정한다. AI에게 내부 API 구조를 전부 알려줄 필요도 없다. MCP 도구 설명에는 "월간 리포트를 생성한다" 정도만 노출하고, 내부 구현은 n8n 워크플로우 안에 숨긴다.

이것이 1인 회사에 특히 유리하다. 혼자 만든 서비스는 운영 API, 스크립트, 노션 문서, 스프레드시트, 슬랙 채널이 제각각 흩어져 있기 쉽다. MCP와 n8n을 결합하면 이 흩어진 조각을 AI가 호출 가능한 하나의 업무 인터페이스로 묶을 수 있다.

네 번째 패턴: Workflow Tool로 내부 기능을 제품처럼 노출하기

MCP 도구를 설계할 때는 워크플로우를 작은 제품처럼 생각하는 것이 좋다. 제품에는 이름, 설명, 입력값, 출력값, 에러 메시지, 권한이 있다. MCP 도구도 마찬가지다.

예를 들어 콘텐츠 발행 도구를 만든다고 해보자.

도구 이름: publish_content
설명: 검수 완료된 콘텐츠 초안을 블로그, LinkedIn, X에 발행하고 발행 URL을 반환한다.
입력값: title, body_markdown, channels, publish_mode
출력값: status, published_urls, failed_channels
권한: draft 상태 콘텐츠만 발행 가능, publish_mode가 immediate면 사람 승인 필요

이렇게 도구를 정의하면 Claude나 Cursor가 콘텐츠를 작성한 뒤 n8n 도구를 호출해 발행까지 이어갈 수 있다. 하지만 발행은 민감한 작업이다. 따라서 처음부터 완전 자동 발행으로 가지 말고, 승인 단계를 넣는 것이 좋다.

publish_content 호출
→ 입력 검증
→ Notion 또는 Airtable에 발행 대기 항목 생성
→ Slack에 승인 요청 메시지 발송
→ 승인 버튼 클릭 시 실제 발행 워크플로우 실행
→ 결과 반환 및 로그 저장

MCP의 진짜 힘은 "AI가 모든 것을 마음대로 하게 하는 것"이 아니다. AI가 할 수 있는 일을 도구 단위로 나누고, 위험도에 따라 승인과 제한을 붙이는 것이다. 고객 조회는 자동 실행해도 되지만, 환불 처리나 대량 이메일 발송은 승인 후 실행하게 만들 수 있다.

자체 MCP 서버를 n8n으로 구성하는 예시

이제 1인 회사가 실제로 만들 만한 자체 MCP 서버 도구 세트를 상상해보자. 이름은 solo_company_ops라고 하자. 이 MCP 서버는 Claude, Cursor, 내부 챗봇에서 공통으로 사용할 회사 운영 도구 모음이다.

처음부터 많은 도구를 만들 필요는 없다. 다음 세 가지면 충분히 강력하다.

1. publish_content
   블로그, 뉴스레터, 소셜 채널에 콘텐츠를 발행하거나 발행 대기 상태로 등록한다.

2. get_customer_summary
   이메일 또는 customer_id로 고객의 플랜, 최근 로그인, 결제 상태, 최근 CS 이력을 요약한다.

3. generate_business_report
   기간을 입력받아 매출, 가입, 활성화, 이탈 위험 사용자, 주요 CS 이슈를 리포트로 만든다.

각 도구는 별도 n8n 워크플로우로 만든다. MCP 허브는 이 세 워크플로우를 도구로 노출한다. Claude는 사용자의 자연어 요청을 보고 필요한 도구를 선택한다.

예를 들어 이런 대화가 가능해진다.

나: 지난주 가입자는 늘었는데 결제가 줄어든 이유를 보고서로 정리해줘.
Claude: generate_business_report 도구를 호출해 지난 7일 데이터를 조회한다.
n8n: 가입, 결제, 유입 채널, 활성화 이벤트, CS 태그를 가져와 요약한다.
Claude: 결과를 바탕으로 원인 후보와 다음 액션을 정리한다.

또 다른 예시는 고객지원이다.

나: [email protected] 고객이 환불 문의를 했어. 상태 확인하고 답변 초안 만들어줘.
Claude: get_customer_summary 도구로 고객 상태를 조회한다.
n8n: 결제일, 플랜, 사용량, 과거 문의 이력을 반환한다.
Claude: RAG 지식베이스의 환불 정책과 고객 데이터를 결합해 답변 초안을 작성한다.

이때 Claude가 고객 DB에 직접 SQL을 날리는 것이 아니다. n8n의 get_customer_summary 워크플로우가 허용된 필드만 조회해 반환한다. 그래서 안전하다. 더 정확히 말하면 안전하게 만들 수 있다. MCP 자체가 보안을 자동으로 보장하는 것은 아니므로, 도구 설계에서 보안을 넣어야 한다.

Claude Code와 n8n-mcp로 워크플로우를 만드는 방식

지금까지는 만들어진 n8n 워크플로우를 AI가 호출하는 구조를 봤다. 반대로 AI가 n8n 워크플로우를 만드는 데 도움을 주는 구조도 있다. 여기서 외부 n8n-mcp 프로젝트가 유용하다.

n8n-mcp는 AI 도구가 n8n 노드 문서, 속성, 템플릿, 검증 도구에 접근할 수 있게 한다. Claude Code나 Cursor에 연결하면 "Slack 알림 워크플로우 만들어줘"라고 말했을 때 AI가 노드를 추측하는 대신, 실제 n8n 노드 정보를 검색하고 필수 속성을 확인하고 검증하면서 워크플로우를 만들 수 있다. 프로젝트 문서에 따르면 n8n-mcp는 다수의 n8n 노드와 템플릿 정보를 구조화해 AI가 검색하고 검증할 수 있도록 제공한다.⁶

이것은 초보자에게만 좋은 기능이 아니다. 오히려 반복적으로 워크플로우를 만드는 1인 창업자에게 더 유용하다. 노드 이름을 외우지 않아도 된다. 표현식 문법을 매번 확인하지 않아도 된다. 검증 루프를 AI에게 맡기고, 사람은 업무 로직과 위험 지점에 집중할 수 있다.

Claude Code에서의 작업 흐름은 다음처럼 잡으면 좋다.

1. 먼저 요구사항을 설명한다.
2. Claude에게 바로 만들지 말고 설계도를 먼저 제시하라고 한다.
3. 사용할 노드와 데이터 흐름을 확인한다.
4. n8n-mcp 도구로 노드 정보를 검색하게 한다.
5. 워크플로우를 생성하거나 JSON으로 내보내게 한다.
6. validate_workflow로 검증하게 한다.
7. n8n에서 Credentials를 연결하고 테스트한다.
8. dev 환경에서 확인한 뒤 prod로 옮긴다.

중요한 원칙은 "AI가 바로 프로덕션 워크플로우를 수정하지 않게 하라"는 것이다. n8n-mcp 저장소도 프로덕션 워크플로우를 AI가 직접 수정하지 말고, 복사본과 개발 환경에서 먼저 테스트하고 백업과 검증을 하라고 경고한다.⁷ 이것은 과한 조심이 아니다. AI가 잘못된 노드 설정을 한 번 저장하면 고객 알림이 중복 발송되거나, 비용이 폭주하거나, 중요한 워크플로우가 멈출 수 있다.

Claude와 Cursor 설정에서 꼭 알아야 할 것

Claude Desktop, Claude Code, Cursor 같은 MCP 클라이언트는 보통 설정 파일에 MCP 서버 정보를 등록한다. 서버 실행 명령, 인자, 환경 변수, 인증 토큰을 적어두면 AI 도구가 시작될 때 해당 MCP 서버를 불러온다. Claude Desktop 통합 문서에서도 MCP 서버 이름, 실행 명령, 인자, 환경 변수, 권한 설정을 구성 파일에 넣는 방식을 설명한다.⁸

개념적으로는 이런 형태다.

mcpServers:
  n8n-ops:
    command: npx
    args:
      - mcp-remote
      - https://your-n8n-domain.com/mcp/your-path
    env:
      N8N_MCP_TOKEN: your-token

실제 설정은 사용하는 클라이언트와 연결 방식에 따라 달라진다. n8n의 MCP Server Trigger가 SSE나 Streamable HTTP 기반으로 동작하고, Claude Desktop 같은 로컬 클라이언트가 stdio 방식을 기대하는 경우에는 mcp-remote 같은 브리지 도구가 필요할 수 있다. n8n MCP 통합 가이드에서도 stdio 기반 클라이언트를 n8n의 SSE 기반 MCP 서버에 연결할 때 프록시가 필요하다고 설명한다.⁹

처음 연결할 때 자주 나는 오류는 대체로 비슷하다. URL이 테스트 URL인지 프로덕션 URL인지 헷갈린다. 워크플로우가 활성화되어 있지 않다. Bearer Token이 틀렸다. 로컬에서 npx를 실행할 Node.js가 설치되어 있지 않다. 프록시나 리버스 프록시가 SSE 스트림을 버퍼링해서 응답이 멈춘다.

따라서 연결 테스트는 단순한 도구 하나로 시작하자. 예를 들어 ping_company_ops라는 도구를 만든다. 입력 없이 { status: "ok", time: "..." }만 반환하게 한다. Claude나 Cursor에서 이 도구가 보이고 호출된다면 연결은 성공이다. 그 다음에 고객 조회, 콘텐츠 발행, 리포트 생성처럼 의미 있는 도구를 하나씩 추가한다.

바이브코딩과 n8n 자동화를 연결하기

바이브코딩은 자연어로 코드를 만들고 수정하는 작업 방식이다. Cursor나 Claude Code를 열고 "이 API 클라이언트 만들어줘", "이 에러 처리 추가해줘", "이 스크립트를 CLI로 바꿔줘"라고 요청한다. MCP와 n8n을 붙이면 바이브코딩은 단순한 코드 생성에서 운영 자동화로 확장된다.

예를 들어 당신이 Cursor에서 작은 스크립트를 만든다고 해보자. 이 스크립트는 Stripe 결제 데이터를 가져와 CSV로 정리한다. 예전 방식이라면 스크립트를 실행하고, 결과 파일을 열고, 슬랙에 올리고, Notion에 기록해야 했다. MCP를 붙이면 흐름이 이렇게 바뀐다.

Cursor에서 스크립트 작성
→ 로컬 테스트
→ 결과 JSON 생성
→ n8n Webhook 또는 MCP 도구 호출
→ n8n이 Google Sheets에 저장
→ Slack에 요약 발송
→ Notion 리포트 페이지 생성

개발, 운영, 마케팅이 분리되지 않는다. 코드 에디터에서 만든 작은 도구가 n8n 자동화에 연결되고, n8n은 그 결과를 회사 운영 시스템에 흘려보낸다.

또 다른 예시는 마케팅이다. Claude Code에게 "우리 제품의 새 기능을 설명하는 랜딩 페이지 문구 3개를 만들어줘"라고 요청한다. Claude가 파일을 생성한다. 그런 다음 n8n의 create_campaign_brief 도구를 호출해 Airtable에 캠페인 항목을 만들고, schedule_social_posts 도구로 소셜 초안을 예약하고, notify_review_request 도구로 Slack에 검수 요청을 보낸다.

이때 중요한 것은 AI가 코드를 잘 짜느냐가 아니다. 코드로 만든 산출물이 회사 운영 흐름에 자동으로 들어가느냐가 중요하다. n8n은 바이브코딩의 결과물을 현실 업무로 이어주는 컨베이어벨트가 된다.

도구 설명은 프롬프트보다 더 실전적이다

MCP 도구를 만들 때 많은 사람이 워크플로우 내부 로직에만 집중한다. 하지만 AI가 도구를 제대로 고르게 하려면 도구 이름과 설명이 절반이다. 도구 설명은 AI에게 보여주는 제품 설명서다.

나쁜 설명은 추상적이다.

도구 이름: report
설명: 리포트를 만든다.

좋은 설명은 사용 상황, 입력값, 제한을 포함한다.

도구 이름: generate_business_report
설명: 지정한 기간의 가입자 수, 활성 사용자, 결제 전환, 이탈 위험 사용자, 주요 CS 태그를 조회해 운영 리포트를 생성한다. 매출과 그로스 분석이 필요할 때 사용한다. 입력값은 start_date, end_date, report_type이다. 개인 고객의 민감 정보는 반환하지 않는다.

도구 설명에는 "언제 쓰는지"와 "언제 쓰면 안 되는지"를 함께 적는 것이 좋다. 예를 들어 send_customer_email 도구라면 "고객에게 실제 이메일을 발송하므로 사용 전 승인 상태가 true인지 확인해야 한다"고 적어야 한다. 에이전트는 설명을 보고 도구 사용 여부를 결정한다. 설명이 부실하면 엉뚱한 도구를 호출하거나, 호출해야 할 도구를 지나친다.

입력값도 마찬가지다. query 하나로 모든 것을 받는 도구는 만들기 쉽지만 운영하기 어렵다. 가능한 한 명시적인 필드를 쓰자.

나쁜 입력: query
좋은 입력: customer_email, period_start, period_end, channels, approval_required

명시적인 입력은 검증하기 쉽고, 로그를 분석하기 쉽고, 사고가 났을 때 원인을 찾기 쉽다.

MCP 도구 설계 캔버스

MCP 도구를 만들기 전에 한 페이지로 설계해보자. 워크플로우를 먼저 만들면 도구가 복잡해진다. 도구의 목적과 경계를 먼저 정하면 n8n 구현이 단순해진다.

도구 이름:
AI에게 보이는 설명:
사용해야 하는 상황:
사용하면 안 되는 상황:
입력값:
출력값:
내부에서 호출하는 시스템:
권한 수준:
승인 필요 여부:
실패 시 반환 메시지:
로그로 남길 항목:
비용 또는 호출 제한:

예를 들어 고객 조회 도구는 이렇게 정의할 수 있다.

도구 이름: get_customer_summary
설명: 고객 이메일로 플랜, 결제 상태, 최근 로그인, 최근 문의 태그를 요약 조회한다.
사용 상황: 고객지원 답변 초안 작성, 이탈 위험 확인, 결제 상태 확인
금지 상황: 고객의 전체 개인정보 덤프, 결제 수단 원문 조회
입력값: customer_email
출력값: plan, payment_status, last_login_at, recent_ticket_tags
권한 수준: read-only
승인 필요 여부: 불필요
로그: 요청자, customer_id, 호출 시각, 성공 여부

이런 캔버스가 있으면 도구가 점점 늘어나도 혼란이 줄어든다. 1인 회사라도 자동화 도구가 10개를 넘으면 이름만 보고는 무엇이 무엇인지 헷갈린다. MCP 도구를 회사의 내부 API처럼 문서화해야 한다.

보안: AI에게 열어줄 문은 좁을수록 좋다

MCP는 강력하다. 그래서 위험하다. Claude가 Slack 메시지를 보내고, 고객 DB를 조회하고, 인보이스를 생성하고, 서버 배포를 트리거할 수 있다면 생산성은 올라간다. 동시에 잘못된 호출의 피해도 커진다.

기본 원칙은 최소 권한이다. 읽기 도구와 쓰기 도구를 분리하라. 조회 도구는 자동 실행해도 되지만, 삭제, 발송, 환불, 배포, 과금 관련 도구는 승인 단계를 두는 것이 좋다.

실전에서 지켜야 할 원칙은 다음과 같다.

MCP 엔드포인트에는 Bearer Auth 또는 Header Auth를 적용한다.
도구별로 입력값을 검증하고 허용되지 않은 필드는 버린다.
고객 정보, 결제 정보, 내부 메모는 필요한 필드만 반환한다.
실제 발송, 삭제, 환불, 배포 작업은 사람 승인 단계를 둔다.
실행 로그에 요청자, 입력값 요약, 결과, 에러, 실행 시간을 남긴다.
dev와 prod MCP 서버를 분리하고, AI 테스트는 dev에서 먼저 한다.
도구 호출 횟수와 비용이 큰 API 호출에는 rate limit를 둔다.

특히 SSE나 Streamable HTTP 기반 MCP 서버를 리버스 프록시 뒤에 둘 때는 프록시 설정도 확인해야 한다. 일부 가이드는 nginx 같은 리버스 프록시에서 MCP 경로의 버퍼링과 gzip을 끄지 않으면 SSE 응답이 지연되거나 끊길 수 있다고 설명한다.¹⁰ "연결은 된 것 같은데 Claude가 계속 기다린다"면 코드보다 프록시 문제일 수 있다.

또 하나의 위험은 도구 설명 자체다. MCP 생태계에서는 AI가 도구 설명을 읽고 행동하기 때문에, 악의적인 MCP 서버가 도구 설명에 위험한 지시를 숨기는 문제가 논의되어 왔다. 따라서 출처가 불분명한 MCP 서버를 무작정 연결하지 말아야 한다. 특히 파일 시스템, 셸 명령, 브라우저 제어, 결제 API와 연결되는 서버는 신뢰할 수 있는 것만 사용하자.

운영 단계별 도입 로드맵

처음부터 "Claude가 우리 회사 전체를 운영하게 만들자"는 목표로 시작하면 실패한다. MCP는 작게 시작해야 한다. 첫 단계는 읽기 전용 도구다. 회사 데이터를 조회하고 요약하지만, 외부에 아무것도 발송하지 않는 도구부터 만든다.

1주 차에는 연결을 확인한다. ping, fetch_top_news, get_today_metrics처럼 안전한 도구를 만든다. Claude나 Cursor에서 도구가 보이고, 호출되고, 결과가 반환되는지 확인한다.

2주 차에는 회사 운영 조회 도구를 만든다. get_customer_summary, get_revenue_snapshot, search_knowledge_base 같은 도구다. 아직 쓰기 작업은 하지 않는다. AI가 데이터를 얼마나 잘 해석하는지 보고, 도구 설명과 출력 형식을 다듬는다.

3주 차에는 승인 기반 쓰기 도구를 추가한다. 콘텐츠 발행 대기, 슬랙 알림, Notion 페이지 생성처럼 되돌리기 쉬운 작업부터 시작한다. 실제 고객 이메일 발송이나 환불 처리처럼 민감한 작업은 승인 버튼을 거치게 한다.

4주 차 이후에는 에이전트 흐름을 연결한다. Cursor에서 코드 변경 요약을 만들고 n8n으로 릴리스 노트를 생성한다. Claude가 리포트를 만들고 Slack에 공유한다. RAG 지식 에이전트가 고객 정책을 검색하고, 고객 조회 도구를 함께 사용해 답변 초안을 만든다.

이 순서가 중요한 이유는 신뢰를 쌓기 위해서다. 자동화는 한 번의 멋진 데모보다 꾸준한 안정성이 중요하다. MCP 도구는 회사 운영의 입구가 되므로, 작은 성공을 반복하며 범위를 넓혀야 한다.

MCP가 바꾸는 1인 회사의 인터페이스

지금까지 n8n 자동화는 대체로 이벤트 중심이었다. 가입이 발생하면 환영 메일을 보낸다. 결제가 발생하면 Slack에 알린다. 서버가 다운되면 알림을 보낸다. 이것만으로도 강력하다.

MCP가 추가되면 자동화에 대화형 인터페이스가 생긴다. 이제 당신은 n8n 화면에 들어가 워크플로우를 찾고 수동 실행하지 않아도 된다. Claude에게 말한다. Cursor에서 요청한다. 내부 챗봇에 질문한다. AI가 적절한 n8n 도구를 찾아 실행한다.

이 변화는 단순한 편의 기능이 아니다. 회사 운영 방식의 변화다.

전통적 자동화:
이벤트가 발생하면 정해진 워크플로우가 실행된다.

MCP 기반 자동화:
AI가 상황을 이해하고 필요한 워크플로우를 선택해 실행한다.

물론 AI에게 전권을 맡기라는 뜻은 아니다. 좋은 MCP 시스템은 AI의 판단력과 n8n의 통제력을 결합한다. AI는 자연어를 이해하고 도구를 선택한다. n8n은 검증하고 실행하고 기록한다. 사람은 승인하고 방향을 정한다.

이 구조가 완성되면 1인 회사의 운영 인터페이스가 달라진다. 더 이상 모든 SaaS 대시보드를 돌아다니지 않는다. "이번 주 매출 이상 징후 확인해줘", "이 고객 답변 초안 만들어줘", "새 기능 릴리스 노트 작성하고 검수 요청 보내줘"라고 말하면 된다. 뒤에서는 n8n 워크플로우들이 조용히 움직인다.

n8n은 회사 운영 API가 된다

이 장의 핵심은 MCP라는 기술 이름이 아니다. 관점의 전환이다. n8n은 이제 단순히 자동화 워크플로우를 실행하는 도구가 아니라, AI가 호출할 수 있는 회사 운영 API가 될 수 있다.

API라고 해서 꼭 개발자만 쓰는 것은 아니다. 여기서 API란 "정해진 입력을 넣으면 정해진 업무가 실행되고 정해진 결과가 돌아오는 문"이다. 고객 조회, 콘텐츠 발행, 리포트 생성, 인보이스 발행, 서버 상태 확인, 릴리스 노트 작성이 모두 하나의 도구가 된다.

1인 회사에 필요한 것은 더 많은 직원이 아니라, 반복 가능한 업무 기능을 도구화하는 능력이다. MCP는 그 도구들을 AI가 발견하고 호출할 수 있게 만든다. n8n은 그 도구들을 안전하게 실행하고 기록한다. 이 둘을 결합하면 Claude, Cursor, 코드 에디터, 내부 AI 시스템이 모두 같은 회사 운영 레이어 위에서 움직인다.

다음 장에서는 이 구조를 한 단계 더 밀어붙인다. 하나의 AI 에이전트가 모든 일을 처리하는 데는 한계가 있다. 리서처, 작가, 편집자, 운영자처럼 역할을 나눈 여러 에이전트가 협업하게 만들면 자동화는 더 유연해진다. MCP로 도구를 연결했다면, 이제는 여러 에이전트가 그 도구를 어떻게 나눠 쓰게 할지 설계할 차례다.

참고

¹Leanware n8n MCP Integration Guide

²czlonkowski n8n-mcp GitHub

³n8n as an MCP Hub Guide

⁴n8n as an MCP Hub Guide

⁵Claude 코드로 n8n 워크플로우 구축 n8n-MCP 활용 가이드

⁶czlonkowski n8n-mcp GitHub

⁷czlonkowski n8n-mcp GitHub

⁸Claude Desktop Integration n8n MCP Workflow Builder

⁹Leanware n8n MCP Integration Guide

¹⁰n8n as an MCP Hub Guide

책 목록

혼자 일하는 사람의 n8n: AI 에이전트로 1인 회사를 시스템화하는 법

전체 목차 보기