ai-agent-chat

n8n 사용법: Docker 셀프호스팅부터 AI 워크플로우까지

n8n 사용법 한 줄 요약

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

n8n 에디터 첫 실행 뒤 빈 캔버스가 보이는 화면
셀프호스팅 직후 확인해야 할 첫 화면 (출처: n8n 공식 문서 (Level One Course))

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 Cloud 요금 페이지 캡처 화면
n8n Cloud 가격 기준이에요. Zapier, Make는 위 표에서 비교했어요 (출처: n8n 공식 가격 페이지)

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 FieldsRespond 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 창만 한참 뒤졌거든요.

Schedule Trigger HTTP Request Output 노드가 연결된 첫 워크플로우 화면
처음엔 노드 수보다 데이터 흐름이 보이는지가 중요해요 (출처: n8n 공식 문서 (First Workflow Tutorial))

실행 버튼을 누르면 각 노드 아래에 초록 체크가 뜨고, 노드를 클릭하면 입력값과 출력값 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 자격증명에 붙인 뒤, 실제로 보이는 모델 중 하나를 고르면 돼요.

n8n AI Agent 워크플로우에서 Chat Trigger와 챗 모델, 메모리가 연결된 화면
n8n 공식 튜토리얼의 AI Agent 구성이에요. 모델만 Gemini로 바꾸면 같은 구조로 동작해요 (출처: n8n 공식 문서 (AI Tutorial))

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로 마크다운을 발행하는 파이프라인까지 붙여서 발행 자동화로 넘어가면 돼요.

Similar Posts

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다