Zapier, Make, n8n을 1년에 걸쳐 순서대로 써보고 정리한 선택 기준
우진호
@agent_woo
운영 자동화 툴을 1년 동안 Zapier → Make → n8n 순서로 갈아탔습니다. 옮길 때마다 이유가 있었고, 지금은 셋의 위치가 꽤 또렷하게 정리됐습니다. 도구 고르시는 분들 참고하시라고 표로 압축했습니다.
| Zapier | Make | n8n | |
|---|---|---|---|
| 가격모델 | task 단위 과금(멀티스텝일수록 가파름) | operations 단위(멀티스텝에 유리) | 셀프호스팅이면 사실상 서버비만 |
| 진입장벽 | 거의 0, 30분이면 Zap 완성 | 중간, 시나리오 개념 익혀야 함 | 높음, docker 띄울 줄 알아야 함 |
| 분기·반복 | 복잡해지면 한계 명확 | 라우터·iterator 직관적 | Function 노드에서 JS 직접 |
| 디버깅 | 실행 로그 무난 | 시나리오 커지면 어디서 터졌는지 찾기 어려움 | 코드라 로그 디버깅 가능, 대신 책임도 본인 |
| 운영부담 | 없음(SaaS) | 없음(SaaS) | 업데이트·백업 전부 떠안음 |
옮겨다닌 이유는 결국 비용
Zapier는 Zap 하나가 멀티스텝이면 한 번 돌 때 task를 5~6개씩 까먹습니다. 트리거 → 필터 → 조회 → 분기 → 발송이면 그게 다 task로 계산돼서 한도를 금방 넘겼어요. Make로 가니 operations 과금이라 같은 로직이 훨씬 쌌습니다. 1년 중 제일 오래 쓴 것도 Make였고요.
그런데 진짜 기준은 가격표가 아니었습니다
돌이켜보면 도구를 가른 건 비용표보다 "팀에 코드 만질 사람이 있느냐"였습니다.
코드 만질 사람이 없다면 Make가 가성비 스윗스팟입니다. 라우터·iterator로 분기·반복이 노코드로 충분히 짜이고, 디버깅도 그럭저럭 됩니다. 비개발자만 있는 팀에 n8n 셀프호스팅을 권하지는 않겠어요. docker 업데이트 한 번 잘못 받았다가 워크플로우를 날릴 뻔한 적이 있는데, 볼륨이 살아 있어서 겨우 복구했습니다. 이런 사고를 수습할 사람이 없으면 SaaS의 운영 위탁값이 그대로 보험료입니다.
반대로 개발자가 있으면 n8n의 자유도가 운영 부담을 상쇄합니다. 외부 API 응답을 Function 노드에서 코드로 가공해 끝내는 게, 노코드 모듈을 겹겹이 쌓는 것보다 훨씬 깔끔했어요. 저희는 개발자가 있어서 n8n으로 정착했습니다.
정리
혼자 운영이거나 비개발 팀이면 저는 Make에 남았을 겁니다. 정답은 케이스마다 다르고, 가격 비교보다 팀 구성을 먼저 보고 고르시는 게 맞습니다. 트래픽 양이 아니라 "새벽에 컨테이너 살릴 사람이 있느냐"가 셀프호스팅의 진짜 비용입니다.