n8n 자동화 도입 2026 — 셀프호스팅·비용·외주 범위 7단계
n8n 도입에서 실제로 결정해야 하는 것은 사용법이 아니라 경계입니다. 셀프호스팅과 클라우드, 라이선스 제한, LLM API를 포함한 실제 비용 구조, 실패·중복 처리 설계, 외주 발주서에 적을 항목을 발주처 기준으로 정리했습니다.
n8n은 워크플로우 자동화 도구다. 트리거가 하나 들어오면 정해진 순서대로 여러 서비스를 거쳐 결과를 내보낸다. 화면에서 노드를 이어 붙여 만들고, 중간에 자바스크립트나 파이썬을 직접 넣을 수도 있다.
이 글은 n8n이 무엇인지 설명하는 글이 아니다. 그건 공식 문서와 나무위키에 이미 있다. 여기서 다루는 것은 사내에 n8n을 도입하려는 쪽이 결정해야 하는 것들이다. 직접 띄울지 클라우드를 쓸지, 비용이 실제로 얼마나 나오는지, 누가 유지보수하는지, 외주를 준다면 범위를 어디까지로 적어야 하는지.
먼저 판단할 것 — n8n이 맞는 문제인가
자동화 도구를 고르기 전에 문제가 자동화로 풀리는 종류인지부터 본다.
| 상황 | n8n이 맞나 |
|---|---|
| 여러 SaaS 사이에서 데이터를 옮겨 적는다 | ✅ 정확히 이것 |
| 정해진 시각에 수집·정리·보고가 반복된다 | ✅ |
| 문서·메일을 분류하고 초안을 만든다 | ✅ (LLM 노드) |
| 사람의 판단이 매 건 달라진다 | ❌ 규칙으로 안 굳는다 |
| 초당 수백 건을 처리해야 한다 | ❌ 애플리케이션을 만들 일이다 |
| 화면이 필요하다 | ❌ n8n은 백엔드 흐름만 만든다 |
마지막 두 줄이 중요하다. n8n은 사람이 보는 화면을 만들지 않는다. 관리자 화면이나 대시보드가 필요하면 그건 별도 개발이고, 자동화 도구로 대신할 수 없다. 이 경계를 발주 전에 못 그으면 착수 후에 "이것도 되는 줄 알았다"가 나온다.
업무 시스템 자체를 새로 만들 것인지 기존 도구를 잇기만 할 것인지는 업무 자동화 시스템 설계 원칙에서 판단 기준을 다뤘다.
셀프 호스팅과 클라우드, 무엇이 갈리나
n8n은 두 가지로 쓸 수 있다. 이 선택이 비용·보안·유지보수 부담을 한꺼번에 결정한다.
| 항목 | 셀프 호스팅 | n8n Cloud |
|---|---|---|
| 데이터 경로 | 우리 서버 안 | n8n 서버 경유 |
| 서버 비용 | 월 2~10만 원대(소규모) | 요금제에 포함 |
| 라이선스 | 소스 공개 라이선스(아래 주의) | 구독료 |
| 업그레이드 | 직접 | 자동 |
| 장애 대응 | 우리 몫 | 벤더 |
| 필요한 인력 | 서버를 만질 사람 1명 | 없음 |
⚠️ 라이선스를 오해하기 쉽다. n8n은 흔히 오픈소스로 불리지만 실제로는 Sustainable Use License라는 자체 라이선스다. 사내 업무에 쓰는 것은 자유롭지만, n8n 자체를 재판매하거나 이를 기반으로 SaaS를 만들어 파는 것은 제한된다. 사내 자동화가 목적이면 문제되지 않지만, 고객사에 n8n 기반 서비스를 납품하는 형태라면 라이선스 조건을 먼저 확인해야 한다. 이 확인은 계약 전에 끝내는 것이 맞다.
셀프 호스팅을 골라야 하는 경우
- 개인정보나 계약 정보가 워크플로우를 지나간다
- 사내망에서만 접근 가능한 시스템(ERP·그룹웨어)에 붙어야 한다
- 보안 심사에서 외부 SaaS 경유가 걸린다
- 실행 건수가 많아 클라우드 요금제 구간을 금방 넘긴다
클라우드를 골라야 하는 경우
- 서버를 관리할 사람이 없다
- 우선 두세 개 흐름만 만들어 보고 싶다
- 데이터가 이미 전부 외부 SaaS에 있다
비용은 어디서 나오는가
n8n 비용을 "무료"로 계산하면 반드시 틀린다. 실제 비용은 네 갈래로 나온다.
| 비용 항목 | 셀프 호스팅 | 클라우드 |
|---|---|---|
| 도구 자체 | 0원 | 구독료 |
| 서버·스토리지 | 월 2~10만 원대 | 포함 |
| LLM API | 사용량만큼 | 사용량만큼(별도) |
| 구축 인건비 | 1회성 | 1회성 |
| 운영·수정 | 지속 | 지속 |
가장 자주 빠뜨리는 것이 LLM API 비용이다. n8n 안에서 AI 노드를 쓰면 호출마다 외부 모델 요금이 붙는다. 문서 요약처럼 긴 입력을 넣는 흐름은 건당 비용이 눈에 띄게 올라간다. 도구 값이 0원이라 전체가 싸 보이는데, 실제로는 이 항목이 월 비용의 대부분을 차지하는 경우가 흔하다.
두 번째로 자주 빠뜨리는 것이 운영·수정 인건비다. 자동화는 만들어 두면 끝나는 자산이 아니다. 연동한 SaaS가 API를 바꾸면 흐름이 멈추고, 업무 규칙이 바뀌면 분기를 손봐야 한다. 흐름 다섯 개를 운영하면 월 몇 시간은 누군가 붙어야 한다는 전제로 잡는 편이 현실적이다.
발주 전에 이 세 가지를 숫자로 정해 두면 견적이 흔들리지 않는다.
- 월 실행 건수 — 흐름별로 하루 몇 번 도는지
- 건당 LLM 입력 길이 — 문서 전문인지 요약본인지
- 보관 기간 — 실행 이력을 며칠 남길지(디스크와 직결된다)
세 번째가 의외로 크다. 실행 이력을 전부 남기면 데이터베이스가 빠르게 커진다. n8n에는 실행 데이터 보관 기간 설정이 있으니 구축 시점에 정해 둔다.
워크플로우를 나누는 기준
한 흐름에 전부 넣으면 나중에 못 고친다. 실무에서는 이 기준으로 나눈다.
| 나누는 기준 | 이유 |
|---|---|
| 트리거가 다르면 나눈다 | 스케줄과 웹훅은 실패 양상이 다르다 |
| 외부 시스템이 다르면 나눈다 | 한쪽 장애가 다른 쪽을 세우지 않게 |
| 재시도 정책이 다르면 나눈다 | 메일 발송과 결제는 재시도 기준이 다르다 |
| 담당자가 다르면 나눈다 | 수정 권한과 책임을 맞춘다 |
반대로 로그만 다른 흐름은 합치지 않는다. 분기 하나로 끝날 일을 흐름 두 개로 만들면 동일 로직이 두 벌이 되어 한쪽만 고치는 사고가 난다.
실패를 어떻게 다룰 것인가
자동화에서 진짜 문제는 "안 도는 것"이 아니라 "안 돈 걸 아무도 모르는 것"이다. 구축 단계에서 아래를 정해 둔다.
| 항목 | 정해야 할 것 |
|---|---|
| 재시도 | 몇 번, 몇 초 간격으로 |
| 실패 알림 | 어디로(슬랙·메일), 누구에게 |
| 부분 실패 | 100건 중 3건 실패 시 나머지를 계속할지 |
| 중복 방지 | 같은 트리거가 두 번 와도 한 번만 처리되게 |
| 수동 재실행 | 실패분만 다시 돌릴 수 있는 경로 |
네 번째가 특히 자주 빠진다. 웹훅은 같은 이벤트를 두 번 보낼 수 있고, 그대로 두면 메일이 두 번 나가거나 데이터가 두 줄 들어간다. 처리한 식별자를 기록해 두고 거르는 단계를 넣는다.
세 번째도 설계 시점에 정해야 한다. 100건을 처리하다 3건이 실패했을 때 나머지 97건을 살릴지 전부 되돌릴지는 업무 성격이 정한다. 알림 발송이라면 살리는 쪽이 맞지만, 회계 전표처럼 짝이 맞아야 하는 데이터라면 전부 되돌리고 원인을 확인하는 편이 안전하다. 이 판단을 안 하면 n8n 기본 동작대로 앞의 성공분만 남고 뒤가 잘린 상태가 된다.
보안에서 확인할 것
| 항목 | 확인 내용 |
|---|---|
| 자격증명 저장 | n8n의 Credentials에 암호화 저장, 워크플로우 JSON에 평문 금지 |
| 접근 통제 | 관리 화면을 사내망·VPN 뒤에 둘지 |
| 웹훅 인증 | 공개 URL이면 서명·토큰 검증을 반드시 붙인다 |
| 실행 로그 | 개인정보가 로그에 남지 않게 마스킹 |
| 외부 전송 | LLM 노드에 원문을 그대로 보내는지 확인 |
마지막 줄이 실무에서 가장 위험하다. 문서 요약 흐름을 만들면서 계약서 전문을 외부 모델에 그대로 넘기는 구성이 흔하다. 개인정보나 영업비밀이 들어 있으면 그 자체가 외부 반출이다. 필요한 부분만 잘라 보내거나, 온프레미스 모델로 돌리는 선택지를 검토한다. 판단 기준은 AI 도입 데이터 거버넌스·개인정보 체크리스트에 정리했다.
사내 구축과 외주, 어디서 갈리나
| 조건 | 사내 | 외주 |
|---|---|---|
| 흐름 2~3개, 단순 연결 | ✅ | 과하다 |
| 사내망 시스템 연동 필요 | 어렵다 | ✅ |
| 인증·권한 설계가 걸린다 | 어렵다 | ✅ |
| 서버 운영 인력이 없다 | ❌ | ✅ |
| 만든 뒤 계속 바꿀 예정 | ✅ 사내가 낫다 | 매번 비용 |
마지막 줄이 판단의 중심이다. 자동화는 만들고 끝나지 않고 업무가 바뀔 때마다 따라 바뀐다. 전부 외주로 돌리면 사소한 수정마다 협의가 붙는다. 실무에서 자주 쓰는 형태는 초기 구축과 어려운 연동은 외주, 이후 수정은 사내로 나누는 것이다. 이 경우 인수인계 범위를 계약에 적어야 한다.
직접 할지 맡길지의 일반 기준은 업무 자동화 직접 구축 vs 외주에서 다뤘다.
외주 발주서에 적을 것
n8n 구축을 외주로 맡길 때 범위를 닫는 항목들이다. 빠뜨리면 착수 후에 협의가 반복된다.
| 항목 | 적는 법 |
|---|---|
| 워크플로우 개수 | 「흐름 5개」처럼 수량으로. 「업무 자동화 일체」는 경계가 없다 |
| 연동 대상 | 시스템 이름과 API 문서 유무를 명시 |
| 호스팅 | 셀프/클라우드, 서버는 누가 준비하는지 |
| LLM 비용 부담 | 개발 중과 운영 중을 나눠서 |
| 실패 처리 | 재시도·알림·중복 방지를 산출물에 포함 |
| 인수인계 | 워크플로우 JSON 인도, 수정 방법 교육 몇 시간 |
| 하자 범위 | 「흐름이 안 도는 것」과 「업무가 바뀐 것」의 경계 |
| 계정 소유권 | n8n 인스턴스·API 키를 누가 보유하는지 |
마지막 두 개가 분쟁 지점이다. 업무 규칙이 바뀌어 흐름을 고치는 것은 하자보수가 아니라 추가 개발이다. 그 경계를 문장으로 적어 두지 않으면 인도 후 모든 수정 요청이 무상 요구로 들어온다. 하자와 추가 개발을 나누는 방법은 소스코드 에스크로·하자보수 계약에, 산출물 목록을 문서로 닫는 방법은 과업지시서 작성법에 있다.
다른 도구와의 선택
| n8n | Zapier | Make | 직접 개발 | |
|---|---|---|---|---|
| 셀프 호스팅 | 가능 | 불가 | 불가 | 해당 없음 |
| 코드 삽입 | 자유 | 제한적 | 일부 | 전부 |
| 진입 난이도 | 중간 | 낮음 | 중간 | 높음 |
| 사내망 연동 | 가능 | 어렵다 | 어렵다 | 가능 |
| 유지보수 주체 | 우리 | 벤더 | 벤더 | 우리 |
데이터가 밖으로 나가면 안 되는 조건이 있으면 사실상 n8n 쪽으로 좁혀진다. 그 조건이 없고 흐름도 단순하다면 Zapier가 더 빠르다. 도구 자체가 목적이 아니므로, 제약 조건부터 나열하고 거기서 남는 것을 고르는 편이 낫다.
도입 7단계
| 단계 | 할 일 | 산출 |
|---|---|---|
| 1 | 자동화할 업무를 목록으로. 빈도와 소요 시간 함께 | 후보 목록 |
| 2 | 사람 판단이 필요한 단계를 표시 | 자동화 경계 |
| 3 | 데이터가 외부로 나가도 되는지 판정 | 호스팅 방식 |
| 4 | 흐름 1개로 시범 구축 | 파일럿 |
| 5 | 실패·재시도·알림 설계 | 운영 규칙 |
| 6 | 나머지 흐름 확장 | 워크플로우 세트 |
| 7 | 수정 권한과 교육 | 인수인계 |
2번을 건너뛰면 자동화가 아니라 반자동이 된다. 사람이 승인해야 하는 지점을 미리 정해 두면 나중에 흐름을 뜯어고치지 않아도 된다.
흔한 실수 다섯 가지
| 실수 | 결과 | 대응 |
|---|---|---|
| 한 흐름에 전부 몰아넣음 | 디버깅 불가, 수정 못 함 | 트리거·시스템 기준으로 분리 |
| 실패 알림 미설정 | 며칠 뒤에야 발견 | 구축 시점에 알림 경로 지정 |
| LLM 비용 미산정 | 운영 비용이 예상의 몇 배 | 건당 입력 길이 × 월 실행 수로 추정 |
| 중복 처리 방지 없음 | 메일 2회 발송, 데이터 중복 | 처리 이력 기록 후 거름 |
| 인수인계 없이 종료 | 수정할 때마다 외주 재계약 | JSON 인도 + 교육 시간을 계약에 |
트리숲이 n8n을 다루는 방식
트리숲은 n8n 구축 문의를 받으면 먼저 자동화하지 말아야 할 단계를 같이 표시한다. 발주처가 가져오는 목록은 대개 전 과정 자동화인데, 그중 사람 판단이 필요한 지점을 남겨 두는 편이 결과적으로 오래 간다. 승인 단계를 없앤 흐름은 한 번 사고가 나면 통째로 멈추게 된다.
호스팅 방식은 보안 요건에서 역산한다. 개인정보나 계약 정보가 지나가면 셀프 호스팅을 기본으로 두고, 그렇지 않으면 클라우드로 시작해 실행량이 늘 때 옮기는 쪽을 권한다. 처음부터 서버를 세우면 관리 부담이 먼저 온다.
인수인계는 워크플로우 JSON 인도와 수정 교육을 계약 산출물에 넣는다. 자동화는 업무가 바뀔 때마다 따라 바뀌므로, 발주처가 직접 못 고치는 상태로 끝나면 매번 비용이 붙는다. 견적 산정 근거를 맞추는 방법은 기능점수(FP) 기반 비용 산정에 정리해 두었다.
자주 묻는 질문
n8n은 완전 무료인가요? 도구 자체는 셀프 호스팅 시 라이선스 비용이 없다. 다만 서버 비용, LLM API 비용, 구축·운영 인건비는 별도다. 또 n8n의 라이선스는 일반적인 오픈소스가 아니라 Sustainable Use License라, 사내 사용은 자유롭지만 재판매·SaaS 제공에는 제한이 있다.
Zapier에서 옮길 만한가요? 데이터가 외부로 나가면 안 되거나, 실행 건수가 많아 요금 구간이 부담되거나, 사내망 시스템에 붙어야 한다면 그렇다. 그런 제약이 없고 흐름이 단순하면 옮길 이유가 크지 않다.
개발자 없이 도입할 수 있나요? 간단한 SaaS 연결은 가능하다. 다만 셀프 호스팅, 사내망 연동, 인증 설계가 들어가면 서버를 다룰 수 있는 사람이 필요하다. 클라우드로 시작하면 이 부담이 사라진다.
만든 뒤 유지보수는 누가 하나요? 업무가 바뀌면 흐름도 바뀌므로 계속 손이 간다. 초기 구축은 외주, 이후 수정은 사내로 나누는 형태가 흔하다. 이 경우 인수인계 범위와 교육 시간을 계약에 적어야 한다.
LLM 비용은 얼마나 나오나요? 흐름마다 다르다. 월 실행 건수 × 건당 입력 길이로 추정한다. 문서 전문을 넣는 요약 흐름은 비용이 크게 붙으므로, 필요한 부분만 잘라 보내거나 온프레미스 모델을 검토한다.
정리
n8n 도입에서 실제로 결정해야 하는 것은 도구 사용법이 아니라 경계다. 자동화할 단계와 사람이 판단할 단계, 셀프 호스팅과 클라우드, 하자보수와 추가 개발, 외주 범위와 사내 몫.
발주 전에 세 가지만 숫자로 정해 두면 견적이 흔들리지 않는다. 월 실행 건수, 건당 LLM 입력 길이, 실행 이력 보관 기간이다. 여기에 실패 알림과 중복 방지를 산출물에 넣고, 인수인계 범위를 계약에 적으면 인도 후 분쟁이 크게 줄어든다.
업체를 고르는 기준은 AI 워크플로우 자동화 업체 선정에서 다룬다.