분명 대단한 걸 돌린 것도 없는데, n8n Cloud의 월 실행(execution) 한도가 어느새 절반 넘게 차 있는 걸 보고 당황한 적 있으신가요? "워크플로우 몇 개 안 만들었는데 왜 이렇게 빨리 소진되지?" 하는 의문은 대부분 n8n 워크플로우의 과금 단위와 트리거 동작 방식을 오해하는 데서 옵니다. 이번 글에서는 실행 수가 어떻게 잡히는지, 그리고 어디서 새는지 짚어보고, 트리거 설계만 바꿔서 낭비를 줄이는 법을 정리합니다.
왜 실행 수가 금방 찰까 — 과금 단위부터 오해하기 쉽다
Zapier나 Make를 쓰다 n8n으로 넘어온 분들이 가장 먼저 헷갈리는 지점입니다. Zapier는 워크플로우 안의 각 단계(태스크)마다, Make는 각 모듈(오퍼레이션)마다 사용량을 셉니다. 그래서 노드가 많을수록 비용이 커진다고 생각하기 쉽죠.
하지만 n8n은 다릅니다. 워크플로우가 트리거부터 끝까지 한 번 도는 것을 통틀어 '실행 1건'으로 셉니다. 노드가 3개든 30개든, 한 번 실행되면 똑같이 1건입니다. n8n 공식 문서의 실행(executions) 설명에도 실행은 "워크플로우의 한 번의 실행"으로 정의되어 있습니다(본 글 작성 시점 기준). 즉 비용을 좌우하는 건 노드 개수가 아니라 워크플로우가 몇 번 도느냐입니다. 그래서 노드를 아무리 정리해도 '실행이 자주 도는' 구조라면 한도는 계속 빠르게 줄어듭니다.
트리거 종류마다 실행이 잡히는 방식이 다르다
실행 수의 진짜 열쇠는 트리거입니다. 어떤 트리거를 쓰느냐에 따라 '할 일이 없어도 실행이 잡히는지'가 달라집니다. 본 글 작성 시점 기준으로 대표적인 네 가지를 정리하면 다음과 같습니다.
1) 웹훅(Webhook) 트리거 — 이벤트가 있을 때만
외부 서비스가 요청을 보내올 때마다 워크플로우가 1건 실행됩니다. 실제 이벤트가 발생했을 때만 도는 구조라, 불필요한 실행이 거의 없습니다. 가능하다면 가장 효율적인 트리거입니다.
2) 앱 폴링(Polling) 트리거 — 새 데이터가 있을 때만
Gmail, Google Drive 같은 앱 트리거는 주기적으로 "새 게 있나?" 하고 확인합니다. 흔히 "확인할 때마다 실행이 소모되는 것 아니냐"고 걱정하는데, 공식 문서 기준으로는 새 데이터를 찾았을 때만 실행 1건으로 카운트되고, 결과가 없는 빈 확인은 카운트되지 않습니다. 생각보다 알뜰한 트리거인 셈입니다.
3) 스케줄(Schedule) 트리거 — 여기가 진짜 함정
정해진 시각마다 워크플로우 전체를 돌리는 트리거입니다. 문제는 처리할 일이 없어도 예약된 주기마다 매번 실행 1건이 잡힌다는 점입니다. 예를 들어 '1분마다' 도는 스케줄을 걸어두면, 하루에 1,440번 실행이 발생합니다. 정작 새 작업은 하루 몇 건뿐인데도 말이죠. 실행 한도가 왜 이렇게 빨리 주는지, 대부분의 원인이 여기 있습니다.
4) 서브워크플로우 — 자식은 따로 안 세어진다
큰 워크플로우를 Execute Sub-workflow 노드로 쪼개 부르는 구조에서는, 공식 문서 기준으로 최상위(부모) 실행만 카운트되고 호출된 자식 워크플로우는 별도로 세어지지 않습니다. 즉 로직을 서브워크플로우로 나눠도 실행 수 측면에서 손해가 아닙니다.
| 트리거 | 실행이 잡히는 시점 | 낭비 위험 |
|---|---|---|
| Webhook | 요청이 들어올 때마다 1건 | 낮음 |
| 앱 폴링(Gmail 등) | 새 데이터가 있을 때만 1건 | 낮음 |
| Schedule | 예약 주기마다 무조건 1건 | 높음 |
| 서브워크플로우 | 부모만 카운트, 자식은 제외 | 낮음 |
n8n 워크플로우 실행 수를 아끼는 실전 팁
원인을 알았으니 대응은 단순합니다. 핵심은 '얼마나 자주 도느냐'를 실제 업무 빈도에 맞추는 것입니다. 숫자로 간단히 그려보면 감이 옵니다. 어떤 스케줄 워크플로우를 '1분마다' 돌리면 하루 1,440건, 한 달이면 4만 건이 넘는 실행이 쌓입니다. 같은 워크플로우를 '15분마다'로만 바꿔도 하루 96건, 한 달 약 2,880건으로 줄어듭니다. 새 작업이 실제로는 하루 몇 건뿐이라면, 이 차이의 대부분은 '아무 일도 하지 않은 빈 실행'에 쓰인 셈입니다. 주기 하나만 손봐도 한도 체감이 확 달라지는 이유입니다.
- 스케줄 주기를 다시 따져보기. '1분마다'가 정말 필요한가요? 대부분의 업무는 15분·1시간·하루 한 번으로 충분합니다. 1분에서 15분으로만 늘려도 실행 수가 15분의 1로 줄어듭니다.
- 가능하면 스케줄 대신 이벤트 기반으로. 외부 서비스가 웹훅을 지원한다면 스케줄 폴링 대신 웹훅 트리거로 바꾸세요. '변화가 생겼을 때만' 도니 빈 실행이 사라집니다.
- 작은 워크플로우를 남발하지 않기. 관련 작업마다 트리거를 따로 두면 그만큼 실행 지점이 늘어납니다. 대신 하나의 진입점에서 서브워크플로우로 분기하면, 자식은 카운트되지 않으니 구조도 깔끔하고 실행 수도 아낍니다.
- Executions 탭을 정기적으로 열어보기. n8n에는 실행 이력을 보는 화면이 있습니다. 어떤 워크플로우가 유난히 자주 도는지 눈으로 확인하면, 손봐야 할 스케줄이 금방 드러납니다.
- 대량 데이터는 Loop Over Items로. 참고로 수백~수천 건을 한꺼번에 다룰 때 쓰는 Loop Over Items(옛 Split in Batches) 노드는 실행 '건수'를 줄여주는 도구는 아닙니다. 한 번의 실행 안에서 데이터를 나눠 처리해 API 속도 제한을 피하고, 메모리 부담과 오류 전파를 줄이는 '안정성' 장치입니다. 실행 수 절약과는 목적이 다르다는 점을 구분해 두세요.
한도가 계속 빠듯하다면 — 셀프호스팅이라는 선택지
트리거를 아무리 다듬어도 실행량 자체가 많은 자동화라면, 방향을 바꿔볼 수 있습니다. n8n은 소스가 공개된 도구라 직접 서버에 설치해 쓰는 셀프호스팅(커뮤니티 에디션)을 지원합니다. 이 경우 클라우드 요금제처럼 실행 건수로 한도가 걸리지 않습니다. 다만 서버 관리·업데이트·보안을 스스로 책임져야 하므로, 어느 정도 운영 부담을 감수할 수 있을 때 어울리는 선택입니다. '실행 수에 쫓기는' 단계라면 한 번쯤 저울질해볼 만합니다.
결론: 노드보다 '실행 빈도'를 먼저 보라
n8n의 실행 한도가 빨리 차는 건 워크플로우를 크게 만들어서가 아니라, 필요 이상으로 자주 도는 트리거 때문인 경우가 대부분입니다. 노드를 줄이는 것보다 스케줄 주기를 현실적으로 맞추고, 가능하면 이벤트 기반 트리거로 바꾸는 것이 훨씬 효과가 큽니다. 오늘 당장 Executions 탭을 열어 '가장 자주 도는 워크플로우' 하나만 찾아 주기를 손봐보세요. 그 한 번의 조정만으로도 이번 달 실행 여유가 눈에 띄게 달라질 겁니다.
※ 본 글의 실행 카운팅·요금제 정책은 작성 시점 기준이며, n8n의 정책은 변경될 수 있으니 실제 적용 전 공식 문서와 요금제 페이지를 확인하시기 바랍니다.
댓글 없음:
댓글 쓰기