“메일이 오면 내용을 정리해서 시트에 적어 줘” 같은 일을 사람이 매번 하고 있다면 자동화 대상입니다. n8n은 이런 흐름을 코드 대신 화면에서 블록(노드)을 이어 만드는 도구입니다. 이 글은 n8n 공식 문서(2026년 10월 9일 기준)를 바탕으로, 시작 전에 정할 세 가지를 “클라우드냐 직접 설치냐”, “실패했을 때 어떻게 알 것이냐”, “실행 횟수가 요금에 어떻게 잡히냐”의 순서로 풀어 씁니다.
n8n은 어떻게 동작하나
구조는 단순합니다. 무엇이 시작시키는지(트리거)를 하나 정하고, 그다음에 할 일을 노드로 순서대로 이어 붙입니다. 자료를 가져오고, 조건에 따라 나누고, 결과를 어딘가로 보내는 식입니다. 여기에 AI 단계를 끼워 넣어 가져온 내용을 요약하거나 분류하게 한 뒤, 그 결과로 다음 동작을 정할 수도 있습니다.
공식 문서의 정의로 실행(execution)은 “워크플로가 한 번 돈 것”입니다. 이 정의가 뒤에서 요금과 실패 처리를 이해하는 열쇠입니다.
정할 것 ① 클라우드로 갈까, 직접 설치할까
공식 “Choose how to use n8n” 문서는 선택지를 n8n Cloud(제공사가 관리)와 Self-hosted(내 인프라에 설치) 두 가지로 나눕니다. 문서의 비교를 비개발자 기준으로 다시 정리하면 아래와 같습니다.
| 비교 항목 | n8n Cloud | 직접 설치(Self-hosted) |
|---|---|---|
| 설치 | 필요 없음 | npm, Docker 또는 서버 설정이 필요 |
| 기술 지식 | 필요 없음 | 설치·설정에 필요 |
| 호스팅·업데이트 | n8n이 관리 | 내가 직접 맡음 |
| 비용 | 14일 무료 체험 뒤 유료 플랜 | Community edition은 무료 |
| 맞춤 설정 | 제공되는 옵션 안에서만 | 배포·설정을 전부 직접 통제 |
| 빨리 시작 | 가장 빠름 | 설정 시간이 더 걸림 |
문서는 “바로 시작하고 싶다”, “기술 지식이 없다”, “인프라를 관리하기 싫다”는 경우 모두 Cloud를 권합니다. 반대로 “배포를 완전히 통제하고 싶다”, “무료로 돌리고 싶다”면 직접 설치를 권합니다. 운영(프로덕션) 용도는 둘 다 가능하다고 적혀 있습니다. 즉 “클라우드는 장난감, 직접 설치는 진짜”가 아닙니다.
직접 설치를 고른다면 터미널을 쓸 수 있는 환경이 필요합니다. 공식 호스팅 문서는 Docker를 쓸 수 있는 개인 컴퓨터나 서버 환경(Windows는 WSL을 통해)에서 한 줄 명령 curl -fsSL https://get.n8n.io | sh 로 로컬 설치를 시작하는 방법을 소개합니다. 이 한 줄이 무엇을 설치하는지는 실행 전에 공식 “one-line setup” 안내에서 읽어 보시기 바랍니다.
n8n 공식 GitHub 저장소의 README도 같은 한 줄 설치 명령을 안내하면서 Docker가 필요하다고 적고 있습니다. Docker를 직접 다루는 방법으로는 docker volume create n8n_data로 저장 공간을 만든 뒤 docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n을 실행하고, 편집기는 http://localhost:5678에서 여는 순서가 나옵니다. 같은 README는 n8n을 “fair-code” 방식, 즉 Sustainable Use License와 n8n Enterprise License 아래 배포되는 소스 공개(source available) 도구로 설명하며, 직접 설치해 쓰거나 클라우드로 쓸 수 있다고 안내합니다.
Windows에서 직접 설치를 시도한다면 WSL이 필요할 수 있습니다. Microsoft 공식 문서에 따르면 WSL은 별도의 가상 머신이나 이중 부팅 없이 Windows 안에서 개발용 명령줄 도구를 쓰게 해 주는 기능이며, Windows 10 버전 2004(빌드 19041) 이상 또는 Windows 11에서 관리자 권한 PowerShell로 wsl --install 한 줄을 실행한 뒤 컴퓨터를 다시 시작하면 설치됩니다.
정할 것 ② 무료 범위와 유료 기능의 경계
직접 설치는 라이선스 키가 없으면 자동으로 Community edition으로 돕니다. 공식 문서 표현으로 “거의 전체 기능”이 무료입니다. 이메일을 등록하면 무료 라이선스 키가 오고(Registered Community), 그때 폴더·에디터 안 디버그·사용자 지정 실행 데이터가 추가로 열립니다.
| 에디션 | 비용 | 열리는 것 |
|---|---|---|
| Community | 무료 | 거의 전체 기능 |
| Registered Community | 무료(이메일 등록) | 위 기능 + 폴더, 디버그 인 에디터, 사용자 지정 실행 데이터 |
| Business | 유료 | SSO, 환경 분리, 프로젝트 등 |
| Enterprise | 유료 | 가장 높은 수준의 보안·확장·거버넌스 |
Community에 없는 기능도 문서에 나열돼 있습니다: 사용자 지정 변수, 환경 분리, 외부 시크릿, 바이너리 데이터 외부 저장, 로그 스트리밍(기본 로깅은 포함), 다중 메인 모드(큐 모드는 포함), 프로젝트, SSO(SAML·LDAP), 워크플로·자격 증명 공유, Git 버전 관리. 특히 공유가 막혀 있다는 점이 중요합니다. Community에서는 인스턴스 소유자와 만든 사람만 워크플로와 자격 증명에 접근할 수 있으므로, 혼자 쓰는 용도에는 문제가 없지만 팀이 함께 쓰려면 유료 플랜을 따져야 합니다.
정할 것 ③ 실행 한 번이 요금에 어떻게 잡히나
유료 플랜(클라우드든 직접 설치든)에는 실행 횟수 한도가 있습니다. 공식 “Understand executions” 문서에 따르면 프로덕션 실행만 한도에 잡힙니다. 프로덕션 실행은 트리거·스케줄·폴링으로 자동 시작된 실행이고, 화면에서 “Execute Workflow”를 눌러 직접 돌린 수동 실행은 해당하지 않습니다.
| 트리거 종류 | 한도에 잡히는 방식 | 예 |
|---|---|---|
| Schedule Trigger | 작동할 때마다 1회, 결과와 상관없이 | 매일 아침 9시 실행 |
| 폴링 노드 | 새 데이터를 찾았을 때만 1회 | Google Drive Trigger |
계산 예를 들어 보겠습니다(가정 사례이며 실제 한도는 요금제 페이지에서 확인하세요). 스케줄을 5분마다 돌리면 하루 288번 작동하고, 모두 결과와 상관없이 288회로 셉니다. 같은 일을 폴링 노드로 처리하면 새 파일이 있을 때만 세므로, 하루에 새 파일이 3개 들어오는 상황에선 하루 3회로 셉니다. 반복 주기를 “필요한 만큼만” 늘리는 것이 한도 관리의 기본입니다.
정할 것 ④ 실패하면 어떻게 알 것인가
자동화의 진짜 위험은 실패가 조용히 지나가는 것입니다. n8n은 이를 위해 오류 워크플로(error workflow)를 제공합니다. 공식 문서의 순서를 그대로 옮기면 다음과 같습니다.
- 새 워크플로를 만들고 첫 노드를 Error Trigger로 정합니다.
- 이름을 붙입니다(예: Error Handler). 뒤에 메일·Slack 알림 노드를 이어 붙입니다.
- 저장(Save)합니다.
- 감시할 워크플로로 가서 Options > Settings > Error workflow에서 방금 만든 워크플로를 고릅니다.
- 저장합니다. 이제 그 워크플로가 실패하면 오류 워크플로가 대신 돕니다.
같은 오류 워크플로를 여러 워크플로에 함께 쓸 수 있습니다. 주의점은 세 가지입니다.
- 수동 실행에서는 테스트할 수 없습니다. Error Trigger는 자동으로 돈 워크플로가 실패할 때만 작동합니다.
- Error Trigger가 들어 있는 워크플로는 별도로 게시하지 않아도 됩니다.
- 실패한 실행 기록은 Executions 화면에서 보고, 이전 실행의 데이터를 현재 워크플로에 불러와 원인을 찾을 수 있습니다.
시작할 때 막히는 지점과 해결
| 막히는 지점 | 왜 생기나 | 해결 |
|---|---|---|
| 스케줄을 걸었는데 안 돈다 | Schedule Trigger는 워크플로를 저장하고 게시(publish)해야 작동 | 저장 뒤 게시 상태를 확인 |
| 실행 시각이 몇 시간 어긋난다 | 워크플로 시간대가 없으면 인스턴스 시간대를 따르고, 직접 설치의 기본값은 America/New_York | 워크플로 설정에서 시간대를 서울로 지정 |
| 오류 알림이 안 온다 | 수동으로 돌려서 시험했기 때문 | 자동 실행으로 실패를 일부러 만들어 확인 |
| 컴퓨터를 끄면 멈춘다 | 내 컴퓨터에 직접 설치한 경우 | 정기 실행이 필요하면 클라우드나 상시 켜진 서버를 고려 |
표의 시간대 항목은 공식 Schedule Trigger 문서에 있는 내용입니다. 클라우드는 가입자의 시간대를 감지하고, 못 찾으면 GMT를 기본값으로 쓴다고 적혀 있습니다. 그래서 “아침 9시”로 걸었는데 다른 시각에 도는 일이 생길 수 있습니다.
처음 만드는 순서 예시
아래는 공식 문서의 개념(트리거, 노드, 오류 워크플로, 수동·프로덕션 실행)을 한 줄로 이은 제안 순서입니다. 실제 메뉴 이름은 버전에 따라 조금 다를 수 있습니다.
| 순서 | 할 일 | 확인할 것 |
|---|---|---|
| 1 | 트리거 노드 하나를 고릅니다(스케줄·웹훅·폴링 중) | 이 트리거가 한도에 어떻게 잡히는지 |
| 2 | 예시 데이터로 수동 실행해 노드마다 결과를 봅니다 | 수동 실행은 한도에 안 잡힘 |
| 3 | 오류 워크플로를 만들어 알림 노드를 붙입니다 | 자동 실행에서만 시험 가능 |
| 4 | 저장하고 게시해 프로덕션으로 올립니다 | 시간대, 실행 기록(Executions) |
| 5 | 일주일 뒤 Executions에서 실패·성공 수를 봅니다 | 주기를 줄일 수 있는지 |
이런 사람에게 맞는다
반복되는 손작업이 분명히 있고, 연결할 서비스가 이미 정해져 있는 경우에 잘 맞습니다. 반대로 한 번만 할 일이거나 흐름이 자주 바뀌는 일이면 만드는 시간이 더 들 수 있습니다. 처음에는 실제 계정 대신 예시 데이터로 작은 흐름 하나(예: 폼 제출 → 시트 한 줄 추가)를 만들고, 오류 워크플로까지 붙여 본 뒤 범위를 넓히는 순서를 권합니다. 연결하는 서비스의 접근 권한은 읽기만 필요하면 쓰기 권한을 주지 않는 식으로 최소로 잡으세요.
확인 자료
- n8n Docs — Choose how to use n8n (클라우드·직접 설치·플랜 비교)
- n8n Docs — Understand executions (실행 횟수가 잡히는 방식)
- n8n Docs — Handle errors gracefully (오류 워크플로 설정)
- n8n Docs — Schedule Trigger (스케줄·시간대)
- n8n 공식 GitHub 저장소(README) (한 줄 설치, Docker 실행, 라이선스 방식)
- Microsoft Learn — Install WSL (Windows에서 WSL 설치 조건과 명령)
이 글의 기준일은 2026년 10월 18일입니다. 요금제와 기능 구분은 바뀔 수 있으니 구독 전에는 공식 요금 페이지에서 현재 내용을 다시 확인하시기 바랍니다.
함께 보면 좋은 글
자동화에 AI를 얹을 때 같이 알아 두면 좋은 글입니다.
- 클로드 코드 스킬과 서브에이전트: 뭐가 다르고 언제 어느 쪽을 쓰나 — 일을 나눠 맡길 때의 기준
- AI가 쓰라고 만든 브라우저: Cloudflare Kitesurf 3가지 — AI가 웹을 다루는 방식
- AI가 채워주는 것과 훈련이 채워주는 것은 달랐다: 학생 실험 결과 — AI에 맡길 일과 직접 할 일을 가르는 근거