n8n 사용법: Docker 셀프호스팅부터 AI 워크플로우까지
n8n 사용법 한 줄 요약
docker compose up -d로 먼저 띄우세요. 2026년 4월 14일 기준으로 n8n은 Cloud도 있지만, 셀프호스팅 Community Edition이면 도구 라이선스 비용 없이 시작할 수 있어요. 브라우저에서 에디터만 열리면Trigger → Action → Output3노드부터 만들고, 진짜로 외부 도구 호출이 필요할 때만 Gemini와 AI Agent를 붙이는 순서가 덜 꼬여요.

docker compose up -d 한 줄이면 끝날 줄 알았어요. 착각이었어요. n8n은 그다음부터가 시작이더라고요. 브라우저는 떴어요. 근데 웹훅이 안 받아요. 저장? 볼륨 권한이 꼬여 있었어요. AI Agent는 왜 같은 얘기를 두 번 하냐 싶었거든요. 처음 n8n 사용법을 찾는 사람도 대개 여기서 막혀요. 설치 자체가 어려운 건 아니에요. 어디서 틀렸는지 바로 안 보이니까 지치는 거죠.
그래서 이 글은 기능 카탈로그 대신 순서로 갑니다. n8n이 Zapier, Make와 뭐가 다른지 짧게 잡고, Docker로 인스턴스를 띄우고, 노드 3개짜리 첫 워크플로우를 끝낸 다음, Gemini를 붙여 n8n AI 자동화 흐름까지 올려볼 거예요. 공식 문서와 가격 페이지를 다시 보고 n8n 사용법을 정리했어요.
n8n이 Zapier, Make보다 먼저 손에 익는 이유
n8n 사용법을 볼 때는 기능보다 운영 방식을 먼저 봐야 해요. 같은 자동화 도구처럼 보여도 어디서 돌리고, 어떤 가격 단위로 과금되고, AI를 어디에 붙일 수 있는지가 꽤 다르거든요.
매달 태스크 요금부터 계산하고 싶은 건 아니죠?
Zapier는 웹에서 빨리 붙이는 쪽이 편하고, Make는 시각 편집이 직관적이에요. 근데 개발 감각이 조금이라도 있거나 비용 천장을 낮추고 싶으면 n8n 쪽으로 눈이 가요. 공식 문서 기준으로 쓸 수 있는 환경만 놓고 봐도 차이가 보여요. n8n은 Cloud와 셀프호스팅 Docker/npm, MCP(Model Context Protocol, AI가 외부 도구를 부르는 규격)까지 이어져요. Zapier는 웹 앱에 Chrome 확장, MCP, 개발자 플랫폼 UI/CLI(터미널용 개발 도구)까지 붙고요. Make는 웹 시나리오, AI Agents, Make MCP Server, 온프렘 에이전트까지 따로 봐야 해요.
| 항목 | n8n | Zapier | Make |
|---|---|---|---|
| 주력 운영 방식 | Cloud + 셀프호스팅 | Cloud 중심 | Cloud 중심 |
| 공식 시작 가격 | 셀프호스팅 Community Edition 무료 / Cloud Starter 20€/월(연간 결제) | Professional $19.99/월(연간 결제 시작가) | Core $9/월, 10k credits 기준 |
| 셀프호스팅 | 가능 | 공식 셀프호스팅 없음 | 전체 셀프호스트는 아니고 온프렘 에이전트 제공 |
| AI 관련 환경 | AI Agent, Gemini 노드, MCP server | Zapier AI, Agents, MCP | Make AI Agents, Make MCP Server |
| 확장 방식 | Docker, npm, API, MCP | Web, Chrome 확장, Platform UI/CLI, MCP | Web, API/Custom Apps, MCP, On-prem agent |
| 추천 상황 | 비용 민감, 커스터마이징, 개발 가능 | 비개발자, 앱 수 많음, 빠른 시작 | 중간 난이도, 시각 플로우 선호 |
처음엔 “기능 많은 게 좋은 거 아닌가?” 싶을 수 있어요. 근데 자동화는 결국 매일 돌려야 해요. 저는 Zapier에서 n8n으로 옮겼어요. 좋았던 건 태스크당 과금이 없어진 거예요. 귀찮았던 건? SSL 인증서랑 WEBHOOK_URL 세팅이에요. 코딩 조금이라도 가능하면 n8n이 오래 가요. 바로 붙여서 팀에 보여줘야 하면 Zapier나 Make가 덜 버거워요. AI가 툴을 부르는 흐름 자체가 낯설다면 MCP 서버 사용법: Claude Code 연결 가이드부터 같이 보면 왜 MCP 얘기가 계속 나오는지 금방 연결돼요.

n8n 셀프호스팅: Docker로 15분 안에 띄우기
n8n 사용법 중 셀프호스팅은 Docker로 시작하는 게 제일 안정적이에요. 공식 문서도 Docker를 권장하고, 버전 고정이 쉬워서 업데이트 사고를 줄이기 좋거든요.
브라우저만 뜨면 다 끝난 거라고 생각하면 오래 걸릴걸요?
처음 세팅할 때는 화려한 옵션보다 세 가지만 먼저 잡으세요. 영속 볼륨, 고정 버전 태그, 그리고 암호화 키예요. 웹훅까지 쓸 거면 공개 URL도 같이 맞춰야 하고요. 단계 나눠서 보는 습관은 AI 블로그 브리프 자동 생성: 실전 파이프라인 구축기처럼 자동화 파이프라인을 짤 때도 그대로 먹혀요. 입력, 처리, 출력이 섞이면 결국 디버깅 시간이 더 들어가거든요.
services:
n8n:
image: docker.n8n.io/n8nio/n8n:2.15.0
container_name: n8n
ports:
- "5678:5678"
environment:
# 한국 시간 기준으로 맞추기
TZ: "Asia/Seoul"
GENERIC_TIMEZONE: "Asia/Seoul"
# 나중에 자격증명 복호화에 쓰이니 고정 문자열로 두기
N8N_ENCRYPTION_KEY: "replace-this-with-a-long-random-string"
# 권한 경고를 줄이고 실행 환경을 맞추기
N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS: "true"
N8N_RUNNERS_ENABLED: "true"
volumes:
- n8n_data:/home/node/.n8n
restart: unless-stopped
volumes:
n8n_data:
외부 웹훅을 받을 거면 아래 값도 뒤에 붙이세요.
N8N_HOST=n8n.example.com
N8N_PROTOCOL=https
WEBHOOK_URL=https://n8n.example.com/
실행 순서는 단순해요.
# 컨테이너 올리기
docker compose up -d
# 상태 보기
docker compose ps
# 로그 보기
docker compose logs -f n8n
체크는 이렇게 해두면 돼요.
http://localhost:5678또는 도메인으로 접속이 되는지- 첫 관리자 계정 생성 화면이 뜨는지
- 컨테이너 재시작 뒤에도 워크플로우가 남아 있는지
- 외부 웹훅 테스트라면
WEBHOOK_URL오타가 없는지
셀프호스팅에서 초보가 많이 밟는 지뢰도 정리해둘게요.
| 지뢰 | 왜 터지나 | 바로 보는 포인트 |
|---|---|---|
| HTTPS 인증서 | 공개 웹훅을 HTTPS 없이 열려고 함 | 도메인과 인증서부터 맞추기 |
WEBHOOK_URL 오타 |
로컬 주소를 그대로 둠 | 외부에서 보이는 주소로 교체 |
| 볼륨 권한 | 저장 경로 권한이 꼬임 | /home/node/.n8n 매핑과 권한 다시 보기 |
참고로, 재시작 뒤에 워크플로우가 사라졌다면 볼륨 매핑이 안 된 거예요. docker compose down 했다가 up -d로 다시 올려보고, 워크플로우가 남아 있는지 확인하는 게 n8n 사용법 중 셀프호스팅 첫 체크 루틴이에요.
n8n 사용법 핵심: 노드 3개로 첫 워크플로우 만들기
n8n 사용법의 핵심이에요. 처음 워크플로우는 무조건 짧아야 해요. Trigger 하나. Action 하나. Output 하나. 이 세 개로 끝내야 데이터 흐름이 몸에 들어와요.
처음부터 15개 노드로 가면 왜 망하는지 이미 느낌 오죠?
실전감 있게 가려면 Schedule Trigger → HTTP Request → Slack이 좋아요. 다만 Slack 인증이 귀찮으면 마지막 Output 노드를 Edit Fields나 Respond to Webhook으로 바꿔도 흐름은 똑같아요. 응용 예시가 더 궁금하면 회의록 블로그 변환: 녹음 파일 하나로 초안까지 20분 파이프라인도 같이 보면 좋아요. 자동화는 결국 작은 플로우를 여러 번 잇는 작업이거든요.
| 노드 | 역할 | 처음에 자주 틀리는 점 |
|---|---|---|
| Schedule Trigger | 정해진 시간에 시작 | timezone 안 맞춤 |
| HTTP Request | 외부 API에서 데이터 받기 | 응답 형식을 JSON으로 안 봄 |
| Slack 또는 Output 노드 | 사람이 읽을 메시지로 내보내기 | 이전 노드 값을 제대로 참조 못 함 |
예시는 이렇게 시작하면 돼요.
1. Schedule Trigger
- 매일 오전 9시
2. HTTP Request
- GET https://jsonplaceholder.typicode.com/todos/1
3. Slack
- 메시지:
새 알림이 왔어요
- 제목: {{$json.title}}
- 완료 여부: {{$json.completed}}
여기서 많이 헷갈리는 게 데이터 구조예요. n8n은 아이템 배열을 넘겨요. 각 아이템에 json 필드가 있고요. title만 바로 찾으면 안 돼요. {{$json.title}}처럼 json 안에서 읽어야 해요.
[
{
"json": {
"title": "<가져온 제목>",
"completed": "<true-or-false>"
}
}
]
노드 이름도 꼭 바꾸세요. HTTP Request1, Set2 이런 이름으로 쌓기 시작하면 일주일 뒤에 본인도 못 읽어요. 일일 체크 시작, 할 일 데이터 가져오기, Slack 알림 보내기 정도만 붙여도 디버깅이 훨씬 편해져요. 저도 기본 이름으로 두고 돌렸다가 어디서 실패했는지 찾느라 JSON 창만 한참 뒤졌거든요.

실행 버튼을 누르면 각 노드 아래에 초록 체크가 뜨고, 노드를 클릭하면 입력값과 출력값 JSON을 바로 볼 수 있어요. 실패하면 빨간 X가 뜨는데, 에러 메시지가 좀 모호할 때가 있어요. 그럴 땐 노드 클릭해서 JSON 원본을 직접 보는 게 가장 빨라요.
n8n AI 자동화: Gemini로 AI Agent 붙이기
n8n 사용법에서 AI 자동화는 두 번째 단계예요. 첫 워크플로우를 만든 뒤에 붙여야 덜 헷갈려요. 기본 흐름 없이 AI Agent부터 가면 문제를 프롬프트 탓으로 오해하기 쉽거든요.
분기 한 번이면 될 일을 굳이 AI Agent에 던지고 있진 않죠?
AI Agent는 “외부 도구를 골라서 호출해야 할 때” 쓰는 쪽이 맞아요. 공식 문서 기준으로 AI Agent 노드는 최소 한 개 이상의 tool sub-node 연결이 필요해요. 반대로 단순 분기나 고정 텍스트 응답이면 IF 노드나 일반 워크플로우가 더 싸고 빨라요. 프롬프트 문장 자체를 어떻게 써야 할지 막히면 AI 프롬프트 엔지니어링: 블로거가 바로 쓸 수 있는 7가지 실전 기법을 먼저 보고 오는 편이 훨씬 낫더라고요.
추천 시작 구조는 이 정도예요.
Chat Trigger
-> AI Agent
-> Google Gemini Chat Model
-> Simple Memory
-> HTTP Request Tool
같은 질문을 또 해요. 왜? Simple Memory를 안 붙였더니 매번 새 대화처럼 처리하더라고요. 공식 문서도 Simple Memory를 채팅 이력 유지용으로 설명해요. 다만 운영을 queue mode로 바꾸면 이 노드는 active production workflow에서 맞지 않아요. 같은 요청이 항상 같은 워커로 간다는 보장이 없기 때문이죠.
체크리스트는 이걸로 충분해요.
- 외부 데이터 조회가 필요하면 AI Agent
- 이전 대화 맥락이 필요하면 Simple Memory
- 비용 없이 첫 테스트를 해보고 싶으면 Gemini free tier부터 연결
- 단순 조건 분기면 IF 노드로 끝내기
Gemini 쪽은 n8n이 계정에 보이는 모델 목록을 동적으로 불러와요. 그래서 누군가 블로그에서 본 모델명이 내 화면에 그대로 안 보여도 이상한 건 아니에요. 먼저 Google AI Studio에서 API 키를 만들고, n8n 자격증명에 붙인 뒤, 실제로 보이는 모델 중 하나를 고르면 돼요.

Gemini free tier는 분당 요청 수와 일별 토큰 한도가 있어요. 정확한 숫자는 Google AI Studio 대시보드에서 실시간으로 확인하는 게 좋아요. 무료 구간으로도 테스트 용도는 충분하더라고요.
셀프호스팅 운영 전 체크할 것
n8n이 뜨는 것과 운영 가능한 건 달라요. 완전히요. 하루에 한 번 돌리는 데모와 매일 돌아가는 워크플로우는 보는 포인트가 다르거든요.
조용히 실패하는 워크플로우를 며칠 뒤에 발견하고 싶진 않죠?
가장 먼저 할 건 버전 고정이에요. 2026년 4월 14일 기준 공식 Docker 설치 문서의 stable은 2.15.0이에요. latest로 띄우면? “어제까지 됐는데 왜 오늘 안 되지?”를 정면으로 맞아요. 진짜로요. 그다음은 백업, 에러 알림, 웹훅 주소 재확인이에요. 여기까지 잡아두면 작은 팀에서도 꽤 오래 버텨요. 발행 자동화까지 붙일 생각이면 워드프레스 자동 포스팅: REST API로 마크다운을 발행하는 파이프라인으로 바로 이어갈 수 있어요.
| 체크 항목 | 왜 필요한가 | 지금 할 일 |
|---|---|---|
| 버전 고정 | 업데이트 원인 추적 쉬움 | 이미지 태그를 2.15.0처럼 명시 |
| 백업 | 롤백 여지 확보 | 볼륨과 DB 백업 뒤 업그레이드 |
| 에러 워크플로우 | 조용한 실패 방지 | Error Trigger로 Slack 또는 메일 알림 |
| 웹훅 주소 | 외부 트리거 실패 예방 | 도메인, HTTPS, WEBHOOK_URL 다시 보기 |
| 데이터 저장소 | 운영 안정성 점검 | 작은 테스트는 기본값, 운영 후보면 PostgreSQL 경로 검토 |
업데이트 직전엔 최소 이 순서가 좋아요.
# 현재 버전 태그 확인
docker compose config
# 새 이미지 내려받기
docker compose pull
# 재기동
docker compose up -d
# 기동 로그 확인
docker compose logs -f n8n
볼륨 권한 문제도 미리 한 번 재현해두면 좋아요. 처음엔 저장 버튼만 안 먹는 줄 아는데, 나중에 보면 자격증명 저장이나 워크플로우 반영까지 다 꼬이거든요. n8n 사용법을 익히면서 가장 짜증났던 유형이에요. 겉은 조용한데 안쪽에서만 에러가 나거든요.
볼륨 권한 에러는 docker compose logs -f n8n으로 바로 보여요. 브라우저에서는 그냥 로딩만 안 되는데, 로그에는 EACCES 같은 권한 에러가 찍혀 있거든요. 운영 규모가 커지면 SQLite 대신 PostgreSQL로 바꾸는 게 좋아요. 공식 문서의 Docker Compose 가이드에 PostgreSQL 설정 예시가 있어요.
자주 묻는 질문
n8n 사용법을 찾다 보면 질문이 늘 비슷해요. 커뮤니티에서 반복되는 것만 뽑았어요.
Q1: n8n 셀프호스팅하면 진짜 무료인가요?
A: Community Edition은 무료예요. 근데 서버비랑 도메인은 따로 들어가요.
Q2: n8n vs Zapier vs Make, 뭐가 제일 낫나요?
A: 개발 감각이 있고 비용을 아끼고 싶으면 n8n이 유리해요. 비개발자 위주로 바로 붙여야 하면 Zapier가 편하고, 그 중간에서 시각 편집을 좋아하면 Make가 잘 맞아요. 셋 다 좋은데, 과금 단위와 운영 방식이 달라서 목적 없이 고르면 금방 갈아타게 돼요.
Q3: 코딩 못해도 n8n 쓸 수 있나요?
A: 아주 간단한 플로우는 가능해요. 근데 OAuth, JSON, 웹훅 같은 기본 개념은 조금 알아야 덜 막혀요. “노코드”라는 말만 믿고 들어가면 설치보다 디버깅에서 더 막히는 편이에요.
Q4: AI Agent가 전 대화를 기억 못 해요. 왜 그럴까요?
A: Simple Memory를 연결하지 않았을 가능성이 커요. 이 노드는 채팅 이력을 유지하는 역할을 하고, 연결 안 하면 매번 새 요청처럼 처리돼요. 운영을 queue mode로 바꿨다면 메모리 방식도 같이 다시 잡아야 해요.
Q5: Webhook URL이 로컬에서는 되는데 외부에서 안 돼요
A: 외부에서 접근 가능한 주소를 WEBHOOK_URL에 넣어야 해요. 로컬 주소나 오래된 테스트 주소가 남아 있으면 브라우저에선 보여도 외부 서비스는 못 불러요. 운영이면 도메인과 HTTPS부터 같이 맞추세요.
Q6: Docker 업데이트 후 워크플로우가 깨졌어요. 어디부터 봐야 하나요?
A: 순서대로요. 먼저 docker compose config로 이미지 태그가 바뀌었는지 보세요. 그다음 docker compose logs -f n8n으로 권한 에러가 없는지 확인하고요. latest로 올렸다면 버전 차이부터 확인해야 해요. 백업 없이 바로 업데이트했다면 docker compose down 전에 볼륨 백업부터 하세요. 이전 이미지 태그를 알면 docker compose pull 없이 그 태그로 되돌릴 수 있어요.
다음 단계
일단 docker compose up -d부터 치세요. 에디터가 열리면 노드 3개 워크플로우 하나 끝내고, 그다음엔 워드프레스 자동 포스팅: REST API로 마크다운을 발행하는 파이프라인까지 붙여서 발행 자동화로 넘어가면 돼요.
