n8n 셀프호스팅이 정말 더 쌀까: 큐·로그·메모리 비용 계산법

n8n 셀프호스팅은 실행량이 많고 운영 역량이 있을 때 SaaS 자동화 비용을 낮출 수 있지만, “실행 무제한”이 곧 무료라는 뜻은 아닙니다. Redis·워커·데이터베이스와 장애 대응 비용까지 포함해 계산해야 이관 가치가 생깁니다.

먼저 실행료와 운영비를 같은 표에 놓는다

SaaS 도구는 작업 수나 연산 수에 따라 비용이 커지고 인프라 운영은 공급자가 맡습니다. n8n을 직접 호스팅하면 실행량에 따른 외부 요금 대신 서버, DB, 백업, 모니터링과 담당자의 시간이 듭니다. 월 실행 수가 적거나 자동화 담당자가 없다면 셀프호스팅이 더 비쌀 수 있습니다.

비교할 때는 한 달의 평균·최대 실행 수, 워크플로당 단계 수, 저장할 로그 크기, 장애 허용 시간을 먼저 적습니다. 개인정보를 외부 SaaS로 보낼 수 없는 경우에는 비용 외에 사내망 배치와 감사 가능성이 중요한 선택 기준이 됩니다.

JSON과 Item 모델을 이해해야 예상 실행 수가 맞는다

n8n 저장소의 워크플로는 노드와 연결을 JSON으로 내보내고 가져올 수 있습니다. Git에 저장하면 변경 이력을 남길 수 있지만, 캔버스 위치까지 포함된 큰 JSON diff가 사람이 읽기 쉬운 코드 리뷰를 자동으로 만들어 주지는 않습니다. 비밀 값과 환경별 자격 증명도 워크플로 정의와 분리해야 합니다.

노드가 여러 Item을 반환하면 다음 노드는 각 Item을 대상으로 묵시적으로 처리합니다. 반복문이 화면에 보이지 않아도 입력 다섯 건이 후속 API 호출 다섯 번으로 늘 수 있습니다. 데이터 건수, 노드 실행 횟수와 외부 API 요청 수를 따로 측정하지 않으면 비용과 부하를 과소평가하기 쉽습니다.

Queue mode는 확장 지점이지 자동 확장 버튼이 아니다

기본 main 모드에서는 한 Node.js 프로세스가 트리거와 실행을 담당합니다. Queue mode는 메인 인스턴스가 웹훅과 라우팅을 맡고 실제 작업을 Redis 큐에 넣으며 여러 worker가 소비하게 합니다. 트래픽이 몰릴 때 worker 수를 조정할 수 있다는 것이 장점입니다.

하지만 Redis 가용성, 중복 처리, 재시도와 작업의 멱등성을 운영팀이 책임져야 합니다. worker가 늘어도 한 실행이 거대한 JSON 배열을 메모리에 올리면 OOM은 그대로 발생합니다. 대량 조회는 페이지 단위로 가져오고 Loop 계열 노드로 나누며, 같은 이벤트가 다시 처리돼도 결과가 중복되지 않게 설계해야 합니다.

실행 이력이 DB를 먼저 막을 수 있다

n8n은 디버깅을 위해 노드의 입력과 출력을 실행 이력에 저장할 수 있습니다. 트래픽이 커지면 성공 실행의 큰 페이로드가 Postgres나 SQLite의 용량과 I/O를 빠르게 소비합니다. 원문은 프로덕션에서 성공 로그 저장을 줄이는 설정을 예로 들지만, 버전 없는 환경 변수 하나를 그대로 복사하기보다 Queue mode 문서의 현재 설정과 보존 정책을 확인해야 합니다.

실패 로그에 고객 정보나 토큰이 남는지도 살펴야 합니다. 보존 일수, 마스킹, 삭제와 백업 복구를 워크플로 배포 전에 정하고 DB 용량·큐 지연·worker 실패를 경보로 만듭니다. 노드가 50개 이상 얽히기 전에 하위 워크플로로 분리해야 브라우저와 운영자 모두 흐름을 읽을 수 있습니다.

작은 이관으로 손익분기점을 검증한다

변경이 잦고 실패해도 되돌릴 수 있는 내부 알림이나 데이터 동기화 한두 개부터 옮깁니다. 기존 SaaS와 한 달 병행해 성공률, 처리 시간, 사람 개입, 인프라 비용과 로그 증가량을 비교합니다. 결제처럼 밀리초 지연과 엄격한 트랜잭션이 필요한 핵심 로직은 전용 서비스에 남기는 편이 낫습니다.

n8n의 강점은 모든 백엔드를 대체하는 데 있지 않고, 반복되는 연결 로직을 팀이 통제할 수 있는 워크플로로 옮기는 데 있습니다. 절감액이 운영 인력과 장애 비용보다 큰지 수치로 확인된 뒤 확대해야 합니다.