[작성자:] kevin

메일함을 열어서, 문의 내용을 복사해서, 업무 도구에 카드를 만들어 붙여넣는다. 하루에 열 번쯤. 이걸 3년째 하고 있는 사람이 회사마다 있다.

n8n은 그 열 번을 없애는 도구다. 개발자가 아니어도 쓸 수 있고, 실제로 내가 만든 자동화를 쓰는 사람 대부분은 개발자가 아니다.

이 글은 n8n이 뭐고, 나한테 필요한 물건인지 판단하는 것까지만 다룬다. 설치나 기능 이름은 나오지 않는다. 그건 다음 편이다.

한 줄로 말하면

“이 일이 생기면 저 일을 해라”를 사람 대신 기억하고 실행하는 프로그램이다.

• 문의 메일이 오면 → 업무 카드로 만들어라
• 매일 아침 9시가 되면 → 어제 매출을 표에 정리해라
• 결재 문서가 올라오면 → 금액이 증빙과 맞는지 확인하고 안 맞으면 알려라

사람이 하면 각각 5분, 20분, 3분이다. 자동화하면 0분이다. 정확히는 만드는 데 한 번 시간이 들고, 그 뒤로 0분이다.

코딩을 해야 하나

대부분은 아니다.

화면에 네모(블록)를 놓고 선으로 잇는다. “메일 받기” 네모와 “카드 만들기” 네모를 선으로 연결하면 그게 자동화다. 엑셀에서 함수를 조합해본 적 있다면 그 정도 난이도다.

코드가 필요해지는 건 데이터 모양을 특이하게 바꿔야 할 때인데, 그런 경우가 생각보다 적다. 그리고 그때도 대개 검색하면 나온다.

솔직하게 말하면 어려운 건 도구가 아니라 “무엇을 자동화할지 고르는 일” 이다. 그건 코딩 실력과 상관없고, 오히려 그 업무를 매일 하는 사람이 제일 잘 안다.

어떤 사람에게 필요한가

세 개 중 두 개 이상이면 쓸 만하다.

1. 같은 일을 주 1회 이상 반복한다. 월 1회짜리는 자동화하는 시간이 더 든다.

2. 그 일이 서비스 두 개 이상을 오간다. 메일에서 읽어 다른 도구에 넣는 식. 한 서비스 안에서 끝나는 일은 그 서비스 자체 기능이 대개 더 낫다.

3. 규칙으로 설명할 수 있다. “금액이 100만 원 넘으면 팀장한테” 처럼 말로 설명되면 된다. “느낌상 중요해 보이면” 은 안 된다.

반대로 이런 건 자동화하지 않는 게 낫다. 실제로 만들었다가 걷어낸 것들이다.

월 두세 번짜리. 만드는 데 반나절, 아끼는 건 연 30분이다. 계산이 안 맞는다.

매번 판단이 달라지는 일. “중요해 보이면 팀장한테” 같은 건 규칙이 아니다. 무리하게 조건을 넣어봤자 예외가 계속 나오고, 결국 사람이 다시 다 본다.

이미 쓰는 도구에 있는 기능. 이게 은근히 많다. 업무 도구 대부분에 규칙·알림 설정이 이미 있다. 자동화 도구를 알아보기 전에 지금 쓰는 도구의 설정 화면을 먼저 열어보는 게 빠를 때가 있다.

틀리면 돈이 나가는 일. 결제, 정산, 재고 차감. 자동화는 조용히 틀린다. 사람이 하면 “어 이상한데” 하고 멈추는 지점에서 기계는 그냥 계속 간다. 이런 건 알림까지만 자동으로 하고 실행은 사람이 누르는 게 맞다.

마지막이 제일 중요하다. 자동화를 잘 쓰는 사람과 사고 내는 사람의 차이가 대개 여기서 갈린다.

실제로 어떤 일들을 맡길 수 있나

내가 만들어 굴려본 것들 중 비개발 부서가 쓰는 유형이다.

문의 인입. 특정 주소로 들어온 메일을 5분마다 확인해서 업무 도구에 카드로 등록한다. 담당자 배정과 기한까지 자동으로 붙는다. 월 250건 정도인데, 이걸 손으로 하던 시간이 사라졌다.

서류 검증. 결재 문서가 올라오면 날짜·결재선·증빙 금액이 본문과 맞는지 확인한다. 어긋나면 담당자에게 메신저로 바로 알린다. 사람은 걸린 것만 본다.

정기 리마인드. 매주 정해진 시간에 담당자별로 해야 할 일을 만들어 알린다. 팀장이 매주 챙기던 걸 안 챙겨도 된다.

1차 진단. 문제 상황을 한 줄로 쓰면 관련 기록을 훑어서 “무엇이 문제고 다음에 뭘 하면 되는지” 요약해준다. 개발자에게 물어보기 전 단계가 짧아진다.

공통점이 있다. 어려운 판단을 대신하는 게 아니라, 뻔한 일을 대신한다. 판단은 여전히 사람이 한다.

얼마나 걸리고 얼마나 드나

만드는 시간 — 처음 한 개는 반나절쯤 잡는 게 맞다. 도구에 익숙해지는 시간이 대부분이다. 두 번째부터는 한두 시간이면 된다.

돈 — 두 가지 방식이 있다.

	클라우드(n8n이 운영)	직접 설치
시작 난이도	가입하면 끝	서버가 필요하다
비용	월 구독	서버 비용만
실행 횟수 제한	요금제에 따라 있음	없음
추천	처음이면 이쪽	자주 도는 자동화가 많아지면

처음부터 직접 설치하려다 서버 설정에서 막혀 포기하는 경우를 여러 번 봤다. 일단 클라우드로 하나 만들어보고, 쓸모가 확인되면 그때 옮기는 게 낫다.

회사에서 쓸 때 미리 확인할 것

계정 권한. 자동화가 메일을 읽고 문서를 만들려면 그 권한이 필요하다. 보안 정책상 외부 도구 연동이 막혀 있는 회사가 많으니 미리 물어보는 게 좋다.

개인정보. 고객 정보가 흐르는 자동화라면 그 데이터가 어디를 지나는지 확인해야 한다. 직접 설치하면 우리 서버 안에서만 돌지만, 클라우드는 그렇지 않다.

담당자. 만든 사람이 퇴사하면 아무도 못 고치는 자동화가 남는다. 최소한 뭘 하는 물건인지 적어두는 문서 한 장은 있어야 한다.

세 번째가 실제로 제일 자주 문제가 된다.

첫 자동화 고르는 법

욕심내지 않는 게 요령이다.

1. 이번 주에 손으로 한 일을 그냥 적어본다. 기억으로 하지 말고 캘린더나 보낸 메일함을 열어서. 머리로 떠올리면 인상 깊었던 일만 나오는데, 자동화 대상은 대개 기억에 안 남는 잔일이다.
2. 각 항목 옆에 세 가지를 적는다 — 주 몇 회 / 서비스 몇 개를 오가나 / 규칙으로 쓸 수 있나.
3. 셋 다 통과한 것 중 틀려도 크게 안 아픈 것을 하나 고른다. 알림이 한 번 안 가는 정도.
4. 그거 하나만 만들고 2주 굴려본다. 그동안 두 번째는 만들지 않는다.

2번을 실제로 적어보면 대부분 후보가 절반으로 준다. 머릿속에서는 다 자동화할 수 있을 것 같은데 적어보면 아니다.

3번에서 여러 개를 동시에 만들다 다 못 끝내는 게 가장 흔한 실패다. 하나가 실제로 굴러가는 걸 봐야 두 번째를 제대로 고를 수 있다.

그리고 하나 더. 잘 돌아가는지 확인할 방법을 같이 만들어야 한다. 자동화는 성공할 때가 아니라 조용히 멈췄을 때 문제가 된다. “실패하면 나한테 알림” 을 붙여두지 않으면, 두 달 뒤에 “그거 그동안 안 돌고 있었어” 를 듣게 된다.

정리

n8n은 뻔한 반복 작업을 대신하는 도구다. 코딩 없이 화면에서 블록을 이어 만든다.

주 1회 이상 반복 + 서비스 두 개 이상 + 규칙으로 설명 가능. 이 세 개 중 둘이면 시작해볼 만하다. 처음이면 클라우드로, 자동화 하나만, 실패 알림을 붙여서.

지금 단계에서 알아야 할 건 무엇을 자동화할지 고르는 것뿐이다. 그게 제일 어렵고, 도구를 배우는 것보다 중요하다.

다음 편은 개발자 편이다. 직접 서버에 설치하는 법, 실패했을 때 알림이 오게 만드는 설정, 그리고 이 도구를 자동화가 아니라 백엔드로 쓰는 방식까지 다룬다. 위 체크리스트로 후보를 골랐다면 그다음은 거기서 이어진다.

만약 “직접 설치는 안 하고 클라우드로 쓸 건데” 라면 다음 편은 건너뛰어도 된다. 화면에서 블록 잇는 건 이 글의 내용이면 충분하다.

이 글은 시리즈 2편이다. “n8n이 뭐고 나한테 필요한가” 는 비개발자 편에서 다뤘다. 여기서는 설치·구조·기능·운영을 다룬다.

n8n 워크플로를 4개월간 72개 만들었다. 그중 20여 개가 지금도 1~5분 주기로 돌고 8개 부서가 쓴다. 손으로 하던 기준으로 월 37시간쯤 줄었다.

그 과정에서 생각이 한 번 바뀌었다. 처음엔 “서비스끼리 연결하는 도구”로 봤는데, 지금은 백엔드로 쓴다. 서버도 DB 도 안 만들고 사내 앱 하나를 통째로 올린 적도 있다.

기능 카탈로그를 나열하는 글은 이미 많으니, 각 기능마다 언제 쓰고 언제 안 쓰는지를 붙인다. 마지막 절반은 실전 딥다이브다 — 백엔드로 쓸 때의 구조, 20개가 넘어가면서 겪은 것들, 그리고 쓰면 안 되는 곳.

n8n 이 뭔가

서로 다른 서비스를 연결해 “이 일이 생기면 저 일을 한다”를 만드는 도구다. 화면에서 노드를 선으로 잇고, 필요하면 중간에 JavaScript 나 Python 을 끼워 넣는다.

위치는 이렇다.

	직접 코드	n8n	Zapier 류 SaaS
자유도	높음	중간~높음	낮음
유지보수	전부 내가	화면에서 확인	거의 없음
실행 건수 비용	서버 비용만	자체 호스팅이면 서버 비용만	건당 과금
데이터 위치	내 서버	자체 호스팅이면 내 서버	외부

자체 호스팅에서 실행 건수 과금이 없다는 게 실질적인 차이다. 1분 주기로 도는 워크플로를 건당 과금으로 굴리면 금액이 금방 올라간다.

라이선스부터 짚고 간다

n8n 은 오픈소스가 아니다. 한국어 소개 글 상당수가 오픈소스라고 쓰는데 정확하지 않다.

2022년 3월에 Apache-2.0 + Commons Clause 에서 Sustainable Use License 로 바꿨다. fair-code 라 부르는 방식이고 OSI 인증 라이선스가 아니다. 실무에 걸리는 건 한 줄이다.

내부 업무 목적, 비영리, 개인 용도로만 자유롭게 쓸 수 있다.

• 우리 회사 업무를 자동화한다 → 무료
• 클라이언트 업무를 대신 자동화해준다 → 대체로 문제 없음
• n8n 을 호스팅해서 남에게 서비스로 판다 → 상용 라이선스 필요

대부분은 앞의 둘이라 그냥 쓰면 된다. 다만 “n8n 기반 자동화 SaaS” 를 구상 중이라면 여기서 멈춰야 한다. 제품을 다 만든 다음에 아는 게 제일 비싸다.

기본 구조: 트리거 · 노드 · 아이템

문서를 처음부터 읽을 필요 없다. 이 셋이 전부다.

트리거 — 워크플로가 언제 시작되는지. 앱 이벤트, 스케줄(cron), 웹훅, 챗 인터페이스가 있다. 워크플로 하나에 트리거는 하나다.

노드 — 하나의 동작. 400개가 넘는 서비스별 전용 노드가 있고, 없으면 HTTP Request 노드로 아무 API 나 부른다. curl 명령을 그대로 붙여넣어 노드로 바꾸는 기능도 있다.

아이템 — 노드 사이를 흐르는 데이터. 여기가 처음에 제일 많이 막힌다. n8n 은 아이템을 배열로 다룬다. 앞 노드가 10개를 내보내면 다음 노드는 10번 실행된다. 이걸 모르면 “왜 알림이 10번 왔지”가 된다.

세 번째만 제대로 잡으면 나머지는 화면 보면서 익힌다.

알아두면 바로 쓰는 기능들

여기부터가 실제로 도움이 되는 부분이다.

데이터 변형 노드

Merge, Loop, Filter, Remove Duplicates, Split Out, Aggregate 가 기본 제공된다. API 응답을 가공하려고 Code 노드부터 여는 습관이 제일 흔한 낭비다. 중복 제거나 배열 펼치기는 전용 노드가 이미 있고, 그쪽이 화면에서 읽힌다.

Code 노드

JavaScript 와 Python 둘 다 쓸 수 있다. 자체 호스팅이면 npm 패키지도 불러올 수 있다. 전용 노드로 안 되는 변형이 있을 때만 여는 게 맞다.

표현식(Expressions)

파라미터에 {{ }} 로 값을 끼워 넣는다. 앞 노드 결과를 참조하거나 날짜를 계산할 때 쓴다. 노드 하나 추가할 걸 표현식 한 줄로 끝내는 경우가 많다.

오류 처리 — 여기가 핵심이다

자동화는 성공할 때가 아니라 조용히 실패할 때 아프다. n8n 은 두 층위로 나눠 다룬다.

노드 단위 설정 (노드 Settings 탭)

설정	동작
Retry On Fail	실패하면 성공할 때까지 재실행
On Error → Stop Workflow	워크플로 전체 중단 (기본)
On Error → Continue	오류를 무시하고 직전 유효 데이터로 진행
On Error → Continue (using error output)	오류 정보를 별도 출력선으로 흘려보냄
Always Output Data	결과가 없어도 빈 아이템을 내보냄
Execute Once	아이템이 여러 개여도 첫 번째로 한 번만 실행

Continue (using error output) 가 특히 쓸모 있다. 성공 흐름과 실패 흐름을 화면에서 갈라 놓을 수 있어서, 실패했을 때만 알림을 보내는 분기를 따로 만들 수 있다.

워크플로 단위 설정 — Workflow Settings 의 Error workflow

실행이 실패하면 지정한 다른 워크플로가 대신 실행된다. 그 워크플로는 Error Trigger 노드로 시작해야 한다. Error Trigger 는 이런 데이터를 받는다.

{
  "execution": {
    "id": "231",
    "url": "https://n8n.example.com/execution/231",
    "error": { "message": "Example Error Message", "stack": "Stacktrace" },
    "lastNodeExecuted": "Node With Error"
  },
  "workflow": { "id": "1", "name": "Example Workflow" }
}

lastNodeExecuted 와 url 이 들어 있어서, 알림에 “어느 워크플로의 어느 노드에서 터졌고 여기 링크” 까지 담을 수 있다. 에러 워크플로 하나를 만들어 전체 워크플로에 같은 걸 지정하면 된다. 20개가 넘어가면 이게 없으면 감당이 안 된다.

한 가지 주의. 트리거 노드 자체에서 실패하면 execution.id 와 url 이 안 들어온다. 실행이 시작되지도 않아서다. 알림 문구를 만들 때 이 필드가 없는 경우를 고려해야 한다.

서브 워크플로

워크플로가 다른 워크플로를 호출한다. 메신저 발송이나 알림 라우팅처럼 반복되는 조각을 별도 워크플로로 빼두면 채널이 바뀔 때 한 곳만 고치면 된다. 이름에 lib_ 같은 접두어를 붙여 두면 목록에서 구분된다.

AI 노드

LLM 을 노드로 붙일 수 있고, AI Agent 노드는 도구(tool)를 여러 개 물려주면 에이전트가 알아서 뭘 호출할지 정한다. 문서 요약처럼 규칙으로 못 짜는 판단을 끼워 넣을 때 쓴다.

실무에서 쓸 만한 조합은 기계 규칙으로 먼저 거르고 애매한 것만 LLM 에 넘기는 방식이다. 전부 LLM 에 태우면 비용도 지연도 올라가고, 규칙으로 확실히 판정되는 걸 굳이 확률에 맡기게 된다.

실행 이력과 디버깅

실행마다 각 노드의 입출력이 남아서 어디서 틀어졌는지 화면에서 본다. 이전 실행 데이터를 현재 워크플로로 불러와 재현할 수도 있어서, 외부 이벤트를 다시 발생시키지 않고 디버깅할 수 있다.

주의할 게 있다. 실행 이력은 설정에 따라 며칠 지나면 정리된다. “지난달에 몇 건 처리했지” 를 나중에 세려면 데이터가 없을 수 있다. 건수를 근거로 써야 한다면 처음부터 따로 적재해 두는 게 낫다.

버전 관리와 확장

Git 기반 버전 관리를 지원한다(환경 간 push-pull). 그리고 queue 모드로 워커를 분리해 확장할 수 있다. 다만 이건 워크플로가 상당히 늘어난 뒤의 얘기고, 처음부터 고민할 건 아니다.

설치

Docker 가 있으면 한 줄이다.

docker run -it --rm -p 5678:5678 -v n8n_data:/home/node/.n8n n8nio/n8n

localhost:5678 로 들어가면 끝. 볼륨을 안 붙이면 워크플로가 컨테이너와 함께 사라지니 -v 는 빼지 말 것.

실제로 굴릴 거면 두 가지를 더 본다.

웹훅을 쓸 거면 외부에서 닿는 주소가 필요하다. 시간 트리거만 쓸 거면 상관없지만, 외부 서비스가 호출해야 하면 도메인과 인증서가 붙는다.

기본 SQLite 는 개인용이다. 실행 이력이 쌓이면 느려진다. 워크플로가 늘어날 것 같으면 처음부터 PostgreSQL 로 가는 게 싸다.

n8n 을 백엔드로 쓴다는 것

사내 앱을 하나 만들어야 했다. 원래대로면 서버를 띄우고 API 를 짜고 DB 스키마를 잡아야 한다. 그러지 않고 웹훅 30개를 엔드포인트로 놓고 끝냈다. 별도 서버도 DB 도 없다.

대응은 이렇게 된다.

보통의 백엔드	n8n
REST 엔드포인트	Webhook 노드
비즈니스 로직	Code 노드
cron / 스케줄러	Schedule 트리거
외부 API 호출	HTTP Request 노드
인증	Credential + 헤더 검증

얻은 건 배포가 없다는 점이다. 로직을 고치고 저장하면 그게 배포다. 요구가 자주 바뀌는 사내 도구에서 이게 크다.

공짜는 아니다. 타입도 테스트도 없고 로직이 커지면 화면에서 읽기 어려워진다. 판단 기준은 “6개월 뒤에도 이 모양일 것 같은가” 다. 계속 바뀔 것 같으면 n8n, 굳을 것 같으면 코드로 옮긴다.

어떤 업무에 맞나

실제로 붙여서 남은 유형 넷이다.

1. 인입 처리. 문의 메일을 5분 주기로 읽어 업무 도구에 카드로 등록한다. 월 250건 규모에서 수기 등록이 사라졌고 월 5시간쯤 줄었다. 쓰는 기능은 메일 트리거 + 전용 노드 + 중복 제거.

2. 정기 검증. 결재 문서를 5분 주기로 훑어 규칙 위반을 찾는다. 날짜·합의자·증빙 금액이 본문과 맞는지를 기계 규칙으로 거르고 애매한 건 LLM 에 넘긴다. 월 55건 기준으로 문서당 3분씩 줄었다.

3. 1차 진단. 비개발자가 한 줄 쓰면 로그와 지표를 훑어 요약과 다음 행동을 돌려준다. 건당 30분~3시간이 20분이 됐다. 월 130건이면 21시간쯤이다.

4. 반복 작업 대체. 패턴이 정해진 수기 작업을 자동 진단하고 결과를 제시한다. 사람은 검토만 한다. 케이스당 30분~2시간이 10분으로 줄었고 누적 242건 처리했다.

공통점이 보인다. 로직이 복잡한 게 아니라 연결이 많고, 그 연결이 자주 바뀌는 일이다.

어디엔 쓰지 마라

코드 몇 줄이면 되는 일. cron 에 스크립트 하나 걸면 끝날 걸 노드로 만들면 관리 대상만 는다. 안 바뀔 로직이면 코드가 낫다.

대량 처리. 실행마다 이력이 쌓이는 구조다. 초당 수백 건 도는 파이프라인에 쓰면 그게 먼저 무너진다.

틀리면 돈이 나가는 일. 결제, 정산 실행, 재고 차감. 트랜잭션과 테스트가 필요한 영역이다. 정산 건도 진단과 결과 제시까지만 n8n 이 하고 적용은 사람이 했다. 그 선은 넘지 않는 게 맞다.

이미 다른 게 하고 있는 일. CI 가 배포 알림을 보내는데 한 겹 더 얹으면, 알림이 두 번 오거나 CI 가 조용히 죽었을 때 아무도 모른다.

20개가 넘어가면서 겪은 것들

여기부터는 워크플로가 늘어난 뒤에야 보이는 것들이다. 하나 만들 때는 안 보인다.

공통 조각을 빼두지 않으면 채널 교체가 지옥이 된다

메신저 발송, 알림 라우팅, 담당자 조회. 이런 조각이 워크플로마다 복사돼 있으면 알림 채널을 바꿀 때 20군데를 고쳐야 한다. 그리고 반드시 두세 개를 빠뜨린다.

별도 워크플로로 빼서 서브 워크플로로 호출하게 했다. 이름에 lib_ 접두어를 붙여 목록에서 구분되게 했다. 10개쯤 넘어갈 때 하는 게 아니라 3개째에 하는 게 맞다 — 그때는 5분이고 20개일 때는 하루다.

잡 큐를 새로 만들지 마라

여러 건을 순차 처리해야 할 때 큐가 필요해진다. 여기서 DB 테이블을 만들고 상태 컬럼을 넣고 싶어지는데, 그러면 상태를 볼 화면도 만들어야 한다.

이미 쓰는 업무 도구의 칸반 보드를 그대로 큐로 썼다. 카드가 특정 컬럼으로 옮겨지면 처리하고, 결과를 카드에 코멘트로 남긴다. 진행 상황은 담당자가 원래 보던 화면에서 그대로 보인다. 큐를 따로 만들었으면 그 화면을 새로 만들어야 했다.

프롬프트를 워크플로 안에 박지 마라

LLM 노드 파라미터에 프롬프트를 직접 쓰면, 문구 한 줄 고칠 때마다 워크플로를 열고 노드를 찾아 들어가야 한다. 39개 노드짜리 파이프라인에서는 그 자체가 일이 된다.

프롬프트를 밖으로 빼고 워크플로는 그걸 읽어오게 했다. 문구 수정과 파이프라인 수정이 분리되고, 프롬프트만 버전을 따로 관리할 수 있다.

실행 이력은 근거로 못 쓴다

앞에서도 짚었지만 한 번 더 강조할 만하다. “지난달 몇 건 처리했나” 를 나중에 세려고 하면 데이터가 없다.

성과를 보고해야 하거나 개선 전후를 비교해야 한다면, 처음부터 별도 저장소에 적재해야 한다. 나중에 아쉬워도 복구할 방법이 없다. 이건 설정으로 보존 기간을 늘려도 근본 해결이 아니다 — DB 가 그만큼 커진다.

실패 알림이 없으면 그건 완성이 아니다

가장 많이 빠지고 가장 아픈 항목이다. 자동화는 성공할 때가 아니라 조용히 멈췄을 때 문제가 된다.

앞의 Error workflow 절이 그 답이다. 하나 만들어서 전 워크플로에 같은 걸 지정하면 되고, 5분이면 끝난다. 이걸 안 하면 두 달 뒤에 “그거 그동안 안 돌고 있었어” 를 듣게 된다.

순서를 정하자면 이렇다. 워크플로를 만들고 → Error workflow 를 붙이고 → 그다음에 활성화한다. 활성화부터 하면 붙이는 걸 잊는다.

정리

n8n 은 연결이 많고 자주 바뀌는 업무에 맞다. 로직이 복잡하거나 정확성이 생명인 일은 코드가 낫다.

72개를 만들어보고 남은 기준은 하나다. 6개월 뒤에도 이 로직이 그대로일 것 같으면 코드로, 계속 바뀔 것 같으면 n8n 으로. 그 판단만 맞으면 나머지는 화면 보면서 배운다.

그리고 세 개는 처음부터 해두는 게 싸다 — Error workflow, 공통 조각 분리, 건수 별도 적재. 셋 다 나중에 하면 몇 배가 든다.