n8n으로 업무 자동화하는 법, 설치부터 실전까지

이메일 첨부파일을 매번 손으로 구글 드라이브에 옮기거나, 특정 상황이 생길 때마다 슬랙에 알림을 직접 보내는 반복 작업에 시간을 쓰고 있다면 자동화 도구를 써볼 시점입니다. n8n은 여러 앱과 API를 화면에서 선으로 연결해 워크플로우를 만드는 노코드·로우코드 자동화 도구입니다. 이 글에서는 맥에 직접 설치해 워크플로우 하나를 끝까지 돌려본 과정을 그대로 정리했습니다.

2026-07-25 업데이트: macOS에 n8n 2.31.6을 셀프호스팅으로 설치해 스케줄 트리거 + HTTP Request 워크플로우를 만들고 실행까지 마쳤습니다. 그 화면으로 전면 교체했고, 설치 중 실제로 막혔던 지점과 해결책도 아래에 넣었습니다.

노트북 화면으로 업무 자동화 워크플로우를 확인하는 모습 (무료 스톡 이미지)
n8n은 화면 위에서 노드를 연결해 워크플로우를 만드는 방식으로 작동합니다. (무료 스톡 이미지: Budka Damdinsuren, Unsplash)

📌 핵심 요약

  • n8n은 트리거(시작 조건)와 노드(동작 단계)를 연결해 앱·API를 잇는 자동화 도구로, 클라우드와 셀프호스팅 두 방식이 있습니다.
  • 셀프호스팅은 npm i -g n8n 한 줄이지만, Node 버전이 너무 최신이면 네이티브 모듈 컴파일에서 막힙니다.
  • 첫 실행 때 소유자 계정 생성을 건너뛸 수 없고, 테스트 실행과 활성화(Publish)는 서로 다른 동작입니다.

자동화 도구 구독료가 부담스러워 직접 띄워 쓰려는 사람에게 해당하는 이야기입니다.

셀프호스팅 설치에서 실제로 막힌 지점

n8n을 시작하는 방법은 두 가지입니다. n8n Cloud는 가입만 하면 바로 쓰는 완전관리형이고, 셀프호스팅은 내 컴퓨터나 서버에 직접 설치하는 방식입니다. 무료 커뮤니티 에디션으로 대부분의 핵심 기능을 비용 없이 쓸 수 있는 쪽이 셀프호스팅입니다.

문서에 적힌 설치 명령은 npm install -g n8n 한 줄인데, 이번에 맥에서 두 번 실패했습니다. 둘 다 n8n 자체 문제가 아니라 주변 환경 문제였습니다.

첫 번째는 ModuleNotFoundError: No module named 'distutils'였습니다. n8n이 쓰는 네이티브 모듈 isolated-vm을 빌드하려면 node-gyp가 필요한데, node-gyp가 파이썬의 distutils를 찾습니다. 이 모듈은 파이썬 3.12에서 제거됐고 시스템이 3.14를 잡고 있었습니다. npm_config_python으로 distutils가 남아 있는 3.11을 지정하니 이 단계는 통과했습니다.

두 번째는 fatal error: 'memory' file not found였습니다. C++ 표준 헤더를 못 찾는다는 뜻인데, #include <memory>만 있는 세 줄짜리 프로그램도 똑같이 실패해서 npm이 아니라 Command Line Tools 쪽 문제로 확인됐습니다.

여기서 정공법은 CLT 재설치지만 관리자 권한이 필요합니다. 대신 컴파일 자체를 피하는 우회로를 썼습니다. isolated-vm은 특정 Node ABI용으로 미리 빌드된 바이너리를 함께 배포하는데, 설치돼 있던 Node 26(ABI 147)용은 없고 Node 22(ABI 127)·24(ABI 137)용은 있었습니다. 그래서 Node 22를 따로 설치하고 그 npm으로 돌리니 컴파일 없이 통과했습니다.

brew install node@22
PATH=/opt/homebrew/opt/node@22/bin:$PATH npm install -g n8n

2,158개 패키지가 41초 만에 깔렸습니다. 실행도 같은 Node를 쓰게 PATH를 앞에 두고 n8n start를 하면 http://localhost:5678에서 편집기가 열립니다.

교훈은 이렇습니다. 셀프호스팅 설치가 막히면 대부분 n8n이 아니라 Node 버전·빌드 도구 문제입니다. 최신 Node를 쓰고 있다면 한 단계 낮은 LTS로 내리는 것이 가장 빠른 해결책일 때가 많습니다.

첫 실행: 소유자 계정은 건너뛸 수 없다

처음 localhost:5678에 접속하면 워크플로우 화면이 아니라 Set up owner account 폼이 뜹니다. 이메일·이름·비밀번호(8자 이상, 숫자 1개와 대문자 1개 포함)를 넣어야 다음으로 넘어갑니다. 예전에 쓰이던 N8N_USER_MANAGEMENT_DISABLED 환경변수로 이 단계를 건너뛰려 해봤지만 2.x에서는 먹히지 않았습니다. 로컬에서 혼자 쓸 목적이어도 계정은 만들어야 합니다.

계정을 만들면 워크플로우를 만들라는 빈 화면이 나오고, 하나라도 만들고 나면 홈이 이렇게 바뀝니다.

n8n Overview 화면 — 실행 수, 실패율, 평균 실행 시간과 워크플로우 목록
홈의 Overview. 위쪽에 실행 수·실패 수·실패율·평균 실행 시간이 요약되고 아래에 워크플로우 목록이 놓입니다. 워크플로우가 하나도 없을 때는 이 자리에 ‘Build a workflow’ 버튼만 있습니다.

1단계: 트리거 고르기

워크플로우는 항상 트리거 하나에서 시작합니다. 편집기 오른쪽 위 +를 누르면 “What triggers this workflow?” 패널이 열리고, 여기서 시작 조건을 고릅니다.

트리거 선택 패널 — 수동 실행, 앱 이벤트, 스케줄, 웹훅, 폼 제출 등
고를 수 있는 트리거는 수동 실행, 앱 이벤트(Telegram·Notion·Airtable 등), 스케줄, 웹훅, 폼 제출, 다른 워크플로우의 호출, 챗 메시지입니다. 각각 한 줄 설명이 붙어 있어 처음이어도 고르기 어렵지 않습니다.

이번에는 정기 리포트 형태를 만들 생각이라 On a schedule을 골랐습니다. 기본값은 매일 자정 실행입니다. Trigger at Hour만 오전 9시로 바꿨습니다.

Schedule Trigger 설정 화면 — 하루 간격, 오전 9시 0분
Trigger Interval을 Days로 두고 Trigger at Hour만 9am으로 바꿨습니다. 화면 위 안내문이 짚어주듯, 여기 적은 일정은 워크플로우를 활성화한 뒤에야 실제로 돌기 시작합니다.

2단계: 동작 노드 붙이기

트리거 뒤에는 실제 일을 하는 노드를 잇습니다. 공식 지원 앱이 아니어도 HTTP Request 노드로 API를 직접 호출하면 대부분 연결됩니다. 이번에는 인증이 필요 없는 공개 API 하나를 불러봤습니다.

HTTP Request 노드 설정 — GET 방식, URL 입력, 인증 None
Method를 GET으로 두고 URL만 넣었습니다. 인증이 필요한 API라면 Authentication에서 방식을 고르고 자격 증명을 등록하면 됩니다.

3단계: 실행하고 데이터 확인하기

노드 설정 화면 오른쪽 위 Execute step을 누르면 그 자리에서 실행됩니다. 화면이 왼쪽 INPUT, 가운데 설정, 오른쪽 OUTPUT 셋으로 나뉘어 있어서 앞 노드가 뭘 넘겨줬고 이 노드가 뭘 돌려줬는지 나란히 볼 수 있습니다.

실행 후 화면 — 왼쪽에 트리거 출력, 오른쪽에 API 응답 표
왼쪽 INPUT은 스케줄 트리거가 넘긴 값입니다. timestamp뿐 아니라 Readable date, Day of week, Year, Month 같은 필드로 미리 쪼개져 있어 뒤 노드에서 바로 쓸 수 있습니다. 오른쪽 OUTPUT은 API 응답이고, Table·JSON·Schema 세 가지 보기를 오갈 수 있습니다. (타임존 값은 가렸습니다.)

이 화면이 중요한 이유가 있습니다. n8n에서 가장 자주 나는 오류가 “앞 노드의 출력 구조를 모른 채 뒤 노드를 설정해서 필드를 못 찾는 것”인데, 여기서 실제 키 이름을 눈으로 확인하고 다음 노드를 짜면 그 실수가 거의 사라집니다.

캔버스로 돌아오면 연결선 위에 통과한 데이터 개수가 표시됩니다.

두 노드가 연결되고 각 연결선에 1 item이 표시된 캔버스
실행에 성공한 노드는 초록 테두리와 체크 표시가 붙고, 연결선마다 ‘1 item’처럼 넘어간 항목 수가 나옵니다. 데이터가 어디서 끊겼는지 캔버스만 보고 짚을 수 있습니다.

Executions 탭에는 실행 기록이 남습니다. 이번 실행은 268ms가 걸렸고 결과 크기는 9KB였습니다.

Executions 탭의 실행 기록 — Succeeded in 268ms, 9KB, ID#1
소요 시간·데이터 크기·실행 ID가 함께 남습니다. 정기 실행으로 돌리기 시작하면 이 목록이 장애를 찾는 첫 단서가 됩니다.

테스트 실행과 활성화는 다르다

여기까지 해도 이 워크플로우는 아직 매일 아침에 돌지 않습니다. Execute workflow는 지금 한 번 돌려보는 것이고, 트리거 조건이 올 때마다 자동으로 돌게 하려면 오른쪽 위 Publish를 눌러 활성화해야 합니다. 저장했는데 왜 안 도느냐는 질문이 많이 나오는 지점이 정확히 여기입니다.

Zapier·Make와 무엇이 다른가

셀프호스팅이 가능하다는 점이 가장 큰 차이입니다. Zapier와 Make는 각 서비스 서버에서만 워크플로우가 돌지만, n8n은 커뮤니티 에디션을 직접 설치해 데이터를 밖으로 내보내지 않고 운영할 수 있습니다.

유연성도 더 높습니다. 노드 안에서 자바스크립트로 데이터를 가공할 수 있고, 지원 목록에 없는 서비스도 앞에서 본 HTTP Request로 붙일 수 있습니다. 대신 학습 곡선은 가파릅니다. 앞의 설치 과정에서 보셨듯 셀프호스팅은 Node·빌드 도구 지식이 조금 필요하고, 노드 사이를 오가는 JSON 구조도 눈에 익어야 원하는 대로 다룰 수 있습니다.

실전 활용 사례

이메일 첨부파일 자동으로 구글 드라이브에 저장하기: 이메일 트리거로 조건에 맞는 메일이 오면 첨부파일을 뽑아 구글 드라이브 노드로 지정 폴더에 올리는 흐름입니다.

특정 이벤트 발생 시 슬랙 알림 보내기: 웹훅 트리거로 외부 신호를 받고 If 노드로 조건을 나눠 슬랙 채널에 메시지를 보내는 구성입니다.

정기 리포트 자동 생성·발송: 이 글에서 만든 것과 같은 구조입니다. 스케줄 트리거로 정해진 시각에 실행해 데이터를 가져오고, 뒤에 이메일이나 슬랙 노드를 붙이면 주간 보고가 자동으로 나갑니다.

n8n 워크플로우의 뼈대는 언제나 “트리거 하나 + 그 뒤에 이어지는 노드들”입니다. 이 구조만 익히면 앱 조합만 바꿔 그대로 응용할 수 있습니다.
업무용 스프레드시트를 화면에 띄운 노트북 (무료 스톡 이미지)
정기 리포트처럼 반복되는 업무가 스케줄 트리거로 자동화하기 좋은 예입니다. (무료 스톡 이미지: Bluestonex, Unsplash)

자주 겪는 문제와 해결법

  • 설치가 컴파일 에러로 죽는다: 앞에서 다룬 distutils 없음과 C++ 헤더 없음이 대표적입니다. 파이썬 버전을 낮춰 지정하거나, 프리빌드 바이너리가 있는 Node LTS로 내려서 컴파일 자체를 피하는 쪽이 빠릅니다.
  • 노드 사이에 데이터가 이상하게 전달된다: 노드를 하나씩 실행해 OUTPUT 탭에서 실제 구조를 확인한 뒤 다음 노드를 설정하면 대부분 해결됩니다.
  • 워크플로우를 저장했는데 자동으로 실행되지 않는다: 테스트 실행과 Publish는 별개입니다. 활성화 상태로 바꿔야 트리거가 살아납니다.
  • 연결하려는 앱이 목록에 없다: HTTP Request 노드로 해당 서비스 API를 직접 호출하면 됩니다. 인증 방식은 직접 설정해야 해서 첫 시도에는 시간이 걸립니다.
키보드 앞에서 자동화 워크플로우 오류를 점검하는 모습 (무료 스톡 이미지)
노드별 출력 데이터를 하나씩 확인하는 습관이 초기 오류 대부분을 줄여줍니다. (무료 스톡 이미지: Erik Mclean, Pexels)

마무리

n8n은 트리거와 노드를 잇는 구조만 익히면 반복 업무를 코드 없이 자동화할 수 있는 도구입니다. 셀프호스팅 설치는 명령 한 줄이지만 Node 버전에 따라 네이티브 모듈에서 막힐 수 있고, 첫 실행 때 소유자 계정을 반드시 만들어야 하며, 저장과 활성화가 별개라는 세 가지만 미리 알면 초반에 헤맬 일이 크게 줄어듭니다.

콘텐츠 제작·자동화와 관련된 글도 함께 보면 흐름이 잘 잡힙니다.

이 글은 업무 자동화 묶음에 속합니다. 같은 주제의 글을 배우는 순서대로 묶어 두었으니 묶음 페이지에서 이어 보세요.


글쓴이 · K.Lee — 파티시에로 일하며 AI·자동화 도구를 실무에 매일 씁니다. 확인한 범위와 확인하지 못한 범위를 글 안에 밝힙니다. 운영자 소개 · 편집 원칙 · 수정 정책


코멘트

답글 남기기

It's all about AI에서 더 알아보기

지금 구독하여 계속 읽고 전체 아카이브에 액세스하세요.

계속 읽기