n8n: 20만 스타 워크플로 자동화 프로젝트, 셀프 호스팅 전에 알아야 할 네 가지

n8n은 '워크플로 자동화'를 오픈소스 프로젝트로 만든 플랫폼이다. GitHub의 n8n-io 오거니제이션이 유지 관리하는 n8n 리포지토리는 20만 스타를 돌파하며 현재 가장 뜨거운 자동화 인프라 프로젝트 중 하나다. '오픈소스판 Zapier'로 이해하면 빠르지만, 플랫폼 전체를 자신의 서버에 올릴 수 있다는 점이 다르다. 데이터는 외부로 나가지 않으며, 셀프 호스팅에는 실행 횟수 제한이 없다.

n8n이란

한 줄 요약: 비주얼 캔버스와 코드 노드를 결합한 워크플로 자동화 플랫폼으로, AI 에이전트 오케스트레이션을 네이티브 지원한다.

캔버스에 노드를 드래그해 워크플로를 만든다. 스케줄 트리거, Webhook, API 호출, 데이터베이스 읽기/쓰기. 복잡한 로직은 Code 노드에 JavaScript나 Python으로 직접 작성하고 npm 패키지도 쓸 수 있다. 최근에는 AI로 무게중심을 옮겼다. LangChain 기반 AI 에이전트 노드로 워크플로에서 대규모 언어 모델을 직접 호출하고, 도구를 연결하고, 다단계 추론을 실행할 수 있다. 공식 템플릿 라이브러리에는 9,000개가 넘는 워크플로가 있다. n8n은 nodemation의 줄임말로 'n-eight-n'이라고 읽는다.

왜 이렇게 뜨거운가

첫째, AI 에이전트의 현장 적용에는 '오케스트레이션 계층'이 필요하기 때문이다. 생각하는 것은 대규모 언어 모델이지만, 실제로 일하는 것은 도구 호출, 분기 판단, 사람의 승인 같은 프로세스다. LangGraph 같은 에이전트 오케스트레이션이 푸는 문제와 같은 부류이며, n8n은 비개발 팀도 쓸 수 있는 비주얼 인터페이스를 제공한다. 둘째, 데이터 주권이다. 금융·의료 현장에서는 데이터를 서드파티 SaaS에 맡길 수 없다. 셋째, 요금 구조다. 공식 클라우드는 실행 횟수 과금, 셀프 호스팅은 서버 비용뿐이다. 실행량이 많은 팀은 계산해 보고 갈아탄다.

어울리는 사람, 어울리지 않는 사람

어울린다: 기본적인 운영 역량을 갖춘 개인 개발자와 작은 팀. 데이터를 외부로 내보낼 수 없는 회사. AI 에이전트를 기존 시스템에 붙여 내부 API와 데이터베이스를 자주 호출하는 경우. 실행량이 많아 SaaS 종량제에 민감한 팀.

어울리지 않는다: 서버를 전혀 만지고 싶지 않은 사람. 셀프 호스팅의 업데이트·백업·보안은 직접 챙겨야 한다. 자동화가 두세 개뿐이고 팀이 전부 비개발자라면 Zapier나 Make 같은 순수 SaaS가 편하다. 또 하나, n8n의 라이선스는 fair-code(Sustainable Use License)로, 소스는 공개되지만 OSI 인증 오픈소스 라이선스는 아니다. 법무가 라이선스에 엄격한 회사는 도입 전 라이선스 문서를 먼저 검토해야 한다.

배포 비용: 실제 돈 이야기

시작은 빠르다. Docker 명령어 한 줄이면 실행되고, 기본 SQLite, 브라우저에서 5678 포트를 열면 바로 쓸 수 있다. 이것이 '체험 비용'이다.

프로덕션은 장부가 다르다. 가벼운 체험은 1 vCPU·2GB 메모리부터, 실제 운영은 2 vCPU·4GB 이상에 PostgreSQL 전환을 권장한다. 동시 실행이 많거나 AI 실행 시간이 길면 큐 모드를 써서 Redis를 작업 큐로 두고 메인 프로세스와 워커를 분리한다. 요건을 만족하는 VPS는 월 4~10달러 수준. 실행 횟수 제한이 있는 공식 클라우드 스타터(월 24유로)와 비교하면 하드웨어 비용은 확실히 저렴하다. 모델도 로컬에서 돌리고 싶다면 Ollama 로컬 배포 비용 분석을 참고하자. 숨은 비용도 잊지 말자. 보안 패치, 버전 업그레이드, 백업, 새벽 알림 대응은 계속 들어가는 인건비다.

셀프 호스팅 전에 알아야 할 네 가지

첫째, 암호화 키를 잃으면 저장된 인증 정보는 전부 폐기된다. n8n은 서드파티 인증 정보를 모두 N8N_ENCRYPTION_KEY로 암호화하며, 키는 /home/node/.n8n 디렉터리에 있다. 공식 문서는 경고한다. 시작 시 이 디렉터리가 없으면 n8n이 새 키를 자동 생성하고, 기존 인증 정보는 다시는 복호화할 수 없다. 단일 구성에서 큐 모드로 옮기다 키를 잃어 하룻밤 사이에 모든 연결이 끊겼다는 커뮤니티 보고도 있다. 대책: 첫날부터 키를 명시적으로 설정해 서버 외부에 백업하고, 마이그레이션은 데이터보다 키를 먼저 옮긴다.

둘째, 메이저 업그레이드의 호환성 깨짐은 일상이다. n8n은 릴리스가 빠르고 메이저 버전 사이엔 호환성이 깨지는 변경이 흔하다. 2.0에서는 태스크 러너가 메인 이미지에서 분리되어 셀프 호스팅에 n8nio/runners 이미지를 따로 붙여야 한다. 2026년 10월 예정인 3.0에서는 셀프 호스팅에 Docker가 필수가 되고 npm 설치는 지원 종료, 레거시 노드도 정리된다. 데이터베이스 마이그레이션은 전진만 가능하고 공식 롤백 경로는 없다. 대책: 프로덕션은 이미지 버전을 고정하고, 업그레이드 전 데이터베이스를 백업한 뒤 공식 마이그레이션 리포트로 영향받는 워크플로를 먼저 점검한다.

셋째, 기본 구성은 동시 실행과 고부하를 버티지 못한다. 기본 SQLite+단일 프로세스에서는 동시 실행이 늘거나 단일 워크플로 데이터가 커지면 메모리 폭증·컨테이너 다운이 커뮤니티에서 가장 흔한 호소다. 프로덕션은 PostgreSQL 전환, 실행 기록 자동 정리, 버거우면 서브 워크플로 분리를. AI 에이전트 사용자는 특히 주의해야 한다. 장시간 실행·다단계 도구 호출은 기존 자동화보다 메모리를 훨씬 많이 먹는다. 큐 모드에서는 워커당 1~2GB로 계획하자.

넷째, 셀프 호스팅은 보안 책임의 전부 인수를 뜻한다. 2026년 9월 GitGuardian 조사에서 공개 Git 커밋을 스캔했더니 유출된 n8n API 토큰 4,576개가 발견됐고, 129대의 공개 인스턴스가 유출된 약한 암호화 키를 계속 쓰고 있었다. 포트 노출, 리버스 프록시, HTTPS, 패치 적용까지. SaaS 시대에 플랫폼이 대신해주던 일을 이제 전부 직접 해야 한다. 대책: 5678 포트를 공중에 직접 노출하지 말고, 토큰·키는 환경 변수와 시크릿 관리로 다루며, 프로덕션은 HTTPS 필수다.