n8n 자동화 구축 전 확인할 12가지 — 발주자 체크리스트

n8n으로 무엇을 만들 수 있는지는 이미 아실 겁니다. 유튜브에도 블로그에도 넘칩니다.

이 글은 다른 질문을 다룹니다. 만들고 난 다음 6개월을 어떻게 버티는가. 자격증명은 어디에 저장되는지, 실행 기록에 고객 데이터가 얼마나 쌓이는지, 만든 사람이 퇴사하면 누가 고치는지, 그리고 우리 회사가 이 소프트웨어를 쓰는 방식이 라이선스상 허용되는지.

구축을 발주하는 입장에서 계약 전에 확인해야 할 것들입니다. 마지막에 그대로 쓸 수 있는 12항목 체크리스트를 정리해 두었습니다.

무엇을 자동화할지가 아직 정해지지 않았다면 이 글보다 먼저 볼 것이 있습니다.

---

SECTION 01

“만들 수 있다”와 “운영할 수 있다”는 다른 질문입니다

자동화 도입이 실패하는 지점은 대개 만드는 단계가 아닙니다. 워크플로는 대체로 잘 만들어집니다. 문제는 그다음입니다.

실무에서 반복적으로 보게 되는 실패 형태는 이렇습니다.

• 3개월째 조용히 멈춰 있었는데 아무도 몰랐습니다
• 연동하던 외부 서비스가 인증 방식을 바꿨는데 대응할 사람이 없습니다
• API 요금이 예상의 몇 배로 나왔습니다
• 만든 사람이 퇴사했고, 워크플로 안에 무엇이 들어 있는지 아무도 모릅니다
• 실행 기록을 열어보니 고객 개인정보가 평문으로 쌓여 있었습니다

---

SECTION 02

라이선스 — “오픈소스니까 자유롭게”가 아닙니다

가장 먼저 짚어야 할 부분입니다. 국내 자료 상당수가 n8n을 “오픈소스”로 소개하는데, 정확한 표현이 아닙니다.

Sustainable Use License가 허용하는 것과 금지하는 것

n8n은 fair-code 모델의 Sustainable Use License를 씁니다. GitHub 저장소의 LICENSE.md 원문이 제한 사항을 이렇게 규정합니다.

“You may use or modify the software only for your own internal business purposes or for non-commercial or personal use.”

(소프트웨어를 자기 조직의 내부 업무 목적, 또는 비상업적·개인적 용도로만 사용하거나 수정할 수 있습니다.)

“You may distribute the software or provide it to others only if you do so free of charge for non-commercial purposes.”

(무상으로, 비상업적 목적일 때만 배포하거나 타인에게 제공할 수 있습니다.)

여기서 오해가 자주 생기는 지점을 정리하면 이렇습니다.

• 영리기업이 사내 업무에 쓰는 것은 허용됩니다. “비상업적”이라는 단어 때문에 회사에서 쓰면 안 된다고 읽는 경우가 있는데, “내부 업무 목적(internal business purposes)”은 명시적으로 허용되는 용도입니다.
• 금지되는 것은 이 소프트웨어 자체를 서비스로 제공하는 행위입니다. n8n을 얹어 SaaS를 만들어 파는 경우가 여기 해당합니다.
• 저장소의 파일명에 .ee.가 들어간 Enterprise Edition 파일은 별도 라이선스가 필요하고, master가 아닌 브랜치는 라이선스가 부여되지 않습니다.

네 가지 경우를 구분하세요

실제로 헷갈리는 건 위 조항 자체가 아니라 우리 상황이 어디에 해당하는가입니다. n8n 지원센터의 라이선스 안내를 기준으로 정리하면 이렇습니다.

상황	필요한 라이선스
우리 회사가 우리 인스턴스에서 우리 업무를 자동화	별도 상업 라이선스 불필요
컨설턴트가 고객사 자체 인스턴스 구축을 도와줌	컨설턴트에게는 별도 상업 라이선스 불필요 (고객사 사용 형태에 따라 라이선스 판단)
서비스 제공자가 자기 인스턴스에서 고객 워크플로·자격증명을 운영	Enterprise 라이선스 필요
자사 제품 안에 n8n을 화이트라벨로 임베드	Embed 라이선스 필요

두 번째와 세 번째 줄의 차이가 핵심입니다. n8n 지원센터는 이렇게 씁니다.

“If your role is limited to assisting your clients with setting up their own internal instances of n8n, no commercial license would be required on your part.”

(역할이 고객이 자기 내부 인스턴스를 세팅하도록 돕는 데 그친다면, 그쪽에는 상업 라이선스가 필요하지 않습니다.)

반대로 우리가 관리하는 인스턴스에 고객의 워크플로와 자격증명을 올려 대신 돌려주는 형태라면 Enterprise 라이선스가 필요합니다. 겉으로는 둘 다 “자동화 구축 대행”으로 보이지만 라이선스상 완전히 다른 일입니다.

발주자 입장에서 확인할 것은 하나입니다. 견적서에 적힌 방식이 “우리 회사 서버에 우리 계정으로 구축”인지, “구축사 서버에서 대신 운영”인지. 후자라면 구축사가 그에 맞는 라이선스를 갖고 있는지 물어보시면 됩니다.

마지막으로 한 가지 덧붙입니다. 위 네 가지는 전형적인 형태를 정리한 것이고, 실제 라이선스 적용은 구체적인 서비스 형태에 따라 달라질 수 있습니다. 인스턴스의 소유·관리 주체, 자격증명을 누가 보관하는지, 고객에게 무엇을 어떤 방식으로 제공하는지에 따라 판단이 갈립니다.

특히 고객을 대상으로 하는 서비스를 설계하실 계획이라면 n8n에 직접 확인하시길 권합니다. n8n 지원센터는 사용 사례별 라이선스 문의를 안내하고 있으며, Sustainable Use License 관련 문의는 license@n8n.io, 상업 라이선스 관련 문의는 sales@n8n.io로 받는다고 밝히고 있습니다(n8n 지원센터 라이선스 안내, 2026년 8월 26일 조회).

이 글의 라이선스 정리는 공식 문서를 읽고 요약한 것이며 법률 자문이 아닙니다. 사업 모델이 걸린 판단이라면 n8n의 공식 답변과 법률 검토를 함께 받으시기 바랍니다.

Community 에디션에 없는 기능

무상 셀프호스팅으로 대부분을 쓸 수 있지만, 전부는 아닙니다. n8n 공식 문서의 에디션 비교는 Community 에디션이 “거의 전체 기능”을 포함하되 다음은 제외된다고 밝히고 있습니다(2026년 8월 26일 조회 기준).

• SSO (SAML, LDAP)
• Git을 이용한 버전 관리
• Environments (개발/운영 환경 분리)
• 워크플로·자격증명 공유
• Projects
• 외부 시크릿 관리(External secrets)
• 로그 스트리밍
• 커스텀 변수, 바이너리 데이터 외부 저장, 멀티메인 모드

여기서 실무적으로 중요한 두 가지는 Git 버전 관리와 Environments입니다. 둘 다 없다면 “운영 중인 워크플로를 직접 수정하면서 테스트한다”는 뜻이 됩니다. 소규모라면 감수할 수 있지만, 매출이 걸린 워크플로에는 위험합니다. 견적 단계에서 이 두 기능 없이 어떻게 안전하게 수정할 것인지 물어보세요.

---

SECTION 03

비용 — n8n 요금보다 뒤에 붙는 게 큽니다

실행 단위 과금이라는 점

n8n 클라우드는 워크플로 1회 실행을 과금 단위로 씁니다. 공식 요금 페이지의 설명은 이렇습니다.

“An execution is a single run of your entire workflow. It doesn’t matter how many steps are in the workflow or how much data it processes.”

(실행은 워크플로 전체가 한 번 도는 것을 말합니다. 단계가 몇 개든, 데이터를 얼마나 처리하든 상관없습니다.)

스텝 단위로 과금하는 도구와 계산 방식이 다르므로, 다른 도구와 비교 견적을 받으실 때 단위를 맞춰서 비교하셔야 합니다.

2026년 8월 26일 공식 요금 페이지 조회 기준으로 연간 결제 시 Starter 월 €20(실행 2,500회), Pro 월 €50(실행 10,000회) 수준이며, 상위 플랜과 Enterprise는 별도입니다. 요금 구조는 자주 바뀌니 계약 시점에 직접 확인하시기 바랍니다.

실제 청구서를 구성하는 네 가지

n8n 요금만 보고 예산을 잡으면 대체로 빗나갑니다. 실제로는 이렇게 구성됩니다.

① n8n 자체 비용 — 클라우드 구독료, 또는 셀프호스팅 시 서버·백업·모니터링 비용

② 뒤에 붙는 API 요금 — 이게 대개 더 큽니다. LLM API를 워크플로 안에서 부르면, 문서 한 건당 얼마가 청구됩니다. 하루 300건짜리 워크플로를 만들면 월 9,000건입니다. 견적 단계에서 1회 실행당 예상 API 비용 × 월 실행 횟수를 반드시 계산해 보세요.

③ 연동 대상 SaaS의 요금제 — 자동화하려는 서비스가 API를 상위 요금제에서만 열어주는 경우가 흔합니다. 자동화 때문에 그 서비스 요금제를 올려야 한다면 그것도 비용입니다.

④ 유지보수 인건비 — 다음 항목에서 다룹니다.

계약 전에 요구하실 것: “월 예상 실행 횟수와 1회당 예상 외부 API 비용을 포함한 월 총액”. 이걸 못 내는 견적서는 운영을 계산하지 않은 견적서입니다.

---

SECTION 04

보안 — 자격증명과 실행 로그

여기가 국내 자료에서 가장 비어 있는 부분입니다.

암호화 키를 잃으면 어떻게 되나

n8n은 워크플로가 쓰는 API 키·비밀번호 같은 자격증명을 데이터베이스에 저장하되, 암호화해서 저장합니다. 공식 문서의 암호화 키 설정 문서는 이렇게 설명합니다.

“n8n uses that key to encrypt the credentials before they get saved to the database.”

그리고 키를 따로 지정하지 않으면 첫 실행 시 자동 생성되어 ~/.n8n 폴더에 저장됩니다.

여기서 발주자가 확인해야 할 것은 두 가지입니다.

• 이 키가 어디에 보관되는가. 서버 안 폴더에만 있고 백업에 포함되지 않는다면, 서버를 새로 만드는 순간 모든 자격증명을 다시 입력해야 합니다.
• 키 교체 계획이 있는가. n8n의 암호화 키 교체 문서는 관련 기능에 대해 “one-way change. There’s no rollback path”(되돌릴 수 없는 변경이며 롤백 경로가 없습니다)라고 명시하고, 활성화 후 해당 설정을 끄면 이후 암호화된 데이터에 영구적으로 접근할 수 없게 된다고 경고합니다. 사전 백업과 스테이징 검증을 권고합니다.

담당자가 퇴사할 때 인수인계 목록에 암호화 키와 그 보관 위치가 들어 있어야 한다는 뜻이기도 합니다.

실행 기록에 남는 데이터

n8n은 실행 결과를 데이터베이스에 저장합니다. 무엇이 얼마나 남는지는 실행 데이터 관리 문서에 정리되어 있습니다(2026년 8월 26일 조회 기준).

• EXECUTIONS_DATA_PRUNE — 자동 정리 기능. 기본 활성화
• EXECUTIONS_DATA_MAX_AGE — 기본값 336시간(14일)
• EXECUTIONS_DATA_PRUNE_MAX_COUNT — 기본값 10,000건
• EXECUTIONS_DATA_SAVE_ON_ERROR / ON_SUCCESS / ON_PROGRESS — 무엇을 저장할지 제어

이게 왜 중요한가. 고객 문의를 분류하는 워크플로를 만들었다면, 실행 기록에는 문의 본문이 그대로 남습니다. 기본 설정이면 14일치 또는 1만 건이 데이터베이스에 있습니다. 개인정보가 섞인 워크플로라면 이 보존 기간이 곧 개인정보 보유 기간입니다.

발주 단계에서 요구하실 것: “실행 기록에 개인정보가 남는 워크플로가 무엇이고, 각각 보존 기간을 며칠로 설정할 것인지”를 명시한 문서. n8n에는 실행 데이터를 가려서 저장하는 설정도 있으니, 필요하다면 그 적용 여부도 함께 확인하세요.

국내 규제 관점에서 확인할 것

자동화 대상에 개인정보가 포함된다면 처리 방식이 사내 개인정보 처리방침과 어긋나지 않는지 확인이 필요합니다. 개인정보보호위원회의 생성형 인공지능(AI) 개발·활용을 위한 개인정보 처리 안내서(2025년 8월)가 생애주기 단계별 보호조치를 정리하고 있어 사내 기준을 만들 때 출발점이 됩니다.

어떤 업무를 자동화 대상에서 빼야 하는지는 별도 글에서 다룹니다.

---

SECTION 05

운영 — 조용히 멈춘 자동화가 가장 위험합니다

에러 워크플로가 없으면 실패를 모릅니다

자동화의 최악의 실패는 요란하게 터지는 게 아니라 아무 소리 없이 멈추는 것입니다. 매일 아침 나오던 보고가 안 나온 걸 2주 뒤에 알게 되는 식입니다.

n8n에는 이걸 막는 기능이 있습니다. 공식 문서의 오류 처리 안내에 따르면, 에러 워크플로를 워크플로 설정에서 지정해 두면 본 워크플로가 실패했을 때 별도 워크플로가 실행됩니다. 이 워크플로는 Error Trigger 노드로 시작하며, 실패한 실행의 ID, 오류 메시지, 실패한 노드 정보 등을 받아 메일이나 메신저로 알림을 보낼 수 있습니다.

중요한 건 이게 기본으로 켜져 있지 않다는 점입니다. 지정하지 않으면 실패는 실행 목록 안에만 기록됩니다. 아무도 목록을 열어보지 않으면 아무도 모릅니다.

계약서에 넣을 문장: “모든 운영 워크플로에 에러 워크플로를 지정하고, 실패 시 지정된 담당자에게 알림이 가도록 구성한다.”

외부 API는 언젠가 바뀝니다

연동하는 서비스가 인증 방식을 바꾸거나, 응답 형식을 바꾸거나, 요금제를 개편하면 워크플로가 멈춥니다. 이건 구축사 잘못이 아니라 자동화의 구조적 속성입니다.

그래서 계약에서 정해야 할 것은 “안 멈추게 해주세요”가 아니라 “멈췄을 때 며칠 안에 누가 고치나”입니다. 대응 시간, 대응 범위, 그 대가를 계약서에 적어두지 않으면 나중에 반드시 다툽니다.

실제 장애 사례 — Quick Tunnel 종료와 Telegram 재연결

이론이 아니라 저희가 실제로 겪은 장애 하나를 공유합니다. 아래 내용은 당시 복구 과정을 기록한 내부 보고를 바탕으로 정리한 것이며, 이 글을 쓰기 위해 장애를 새로 재현하거나 시험한 것이 아닙니다.

외부에서 접근할 수 있는 주소로 Cloudflare의 Quick Tunnel(trycloudflare.com)을 쓰고 있었는데, 이 터널을 서비스하던 cloudflared 프로세스가 종료되었습니다. 그 결과 Telegram 봇이 설정된 webhook 주소로 업데이트를 전달하려 할 때마다 HTTP 530 오류가 돌아왔습니다. Quick Tunnel은 Cloudflare 공식 문서가 테스트·개발용이라고 명시하고 별도의 가동률 보장(SLA)을 제공하지 않는다고 밝힌 임시 연결 방식으로, cloudflared 프로세스가 떠 있는 동안만 유지됩니다. Cloudflare는 이런 상태를 오류 1033으로 분류하고, cloudflared 프로세스가 멈춘 상태를 “Down”으로 설명합니다. 이번에 관측된 HTTP 530 응답은 이 상태와 들어맞는 증상으로 보이나, cloudflared 프로세스가 정확히 왜 종료되었는지 그 1차 원인은 복구 과정에서 확인되지 않았습니다.

조치는 새 Quick Tunnel을 띄우고, 새로 발급된 주소로 n8n의 Webhook 노드와 Telegram의 webhook 등록을 다시 연결하는 방식으로 이루어졌습니다. 재연결 이후 Telegram 서버에 쌓여 있던 대기 메시지 4건이 전달되어 처리되었습니다. Telegram Bot API 공식 문서는 webhook 전달이 실패하는 동안 들어온 업데이트가 일정 기간 서버에 보관된다고 설명하고 있으며, 이번에 처리된 4건은 그 보관 기간 안에서 재전달된 것으로 판단됩니다.

한계를 명시합니다. 이 사례는 “완전히 복구되어 재발하지 않는 상태”를 확인한 사례가 아닙니다. 두 가지가 해소되지 않은 채로 남아 있었습니다. 첫째, cloudflared 프로세스가 멈춘 근본 원인은 끝내 확인되지 않았습니다. 둘째, 당시 n8n에는 이전 Quick Tunnel 주소가 WEBHOOK_URL 값으로 남아 있었습니다. n8n 공식 문서는 이 값을 수동으로 지정하면 n8n이 외부 서비스에 등록하는 webhook 주소를 그 값으로 구성한다고 설명합니다. 이 값이 새 주소로 갱신되지 않은 상태에서 n8n이 재시작되면, 이미 사라진 이전 주소로 webhook이 다시 등록되며 같은 장애가 재발할 가능성이 있었고, 이 가능성은 복구 당시 해소되지 않았습니다.

인수 검수표 — 운영 전환 전 확인 항목

구축이 끝난 뒤 실제 운영으로 넘기기 전에, 적어도 아래 다섯 가지는 발주자와 구축사가 함께 확인하시길 권합니다. 가운데 열은 저희가 제안하는 확인 방법이고, 오른쪽 열은 위 장애 사례에서 실제로 무엇이 확인되었고 무엇이 확인되지 않았는지입니다. 둘을 구분해 적은 이유는 실제 장애 대응 중 관측된 것과 정식으로 설계된 점검 절차가 다르기 때문입니다 — 이번 사례는 다섯 항목을 체계적으로 검증한 시험이 아니라, 장애 대응 과정에서 부분적으로 관측된 결과입니다.

확인 항목	제안하는 확인 방법	이번 사례에서 실제로 확인된 것
① 외부 요청 도착 확인	수신 로그 또는 n8n 실행 기록(Executions)에서 들어온 요청이 실제로 찍히는지 주기적으로 점검	사전 점검은 없었음 — 요청이 도착하지 않는다는 사실 자체가 장애 발생 후에야 드러남
② 내부 오류 알림 확인	n8n 에러 워크플로(Error Trigger)를 지정해 실패 시 메신저·메일로 알림	이번 워크플로에는 지정돼 있지 않았음 — 알림은 오지 않았고, 운영자가 Telegram 응답이 없는 것을 직접 알아채고서야 장애를 인지함
③ 외부 접속 장애 감지 확인	외부 모니터링 서비스로 터널 주소를 주기적으로 상태 확인(health check)	별도 모니터링은 없었음 — Telegram이 webhook 전달을 시도하다 HTTP 530을 돌려받으면서 간접적으로 드러남
④ 재시작 후 연결 유지 확인	재시작 후 getWebhookInfo로 등록된 webhook 주소가 최신 주소와 일치하는지 확인	수행되지 않음 — 이전 주소가 WEBHOOK_URL에 남아 있어 재시작 시 재발할 수 있는 위험이 해소되지 않은 채로 남음(미해결)
⑤ 대기 요청 누락 및 중복 확인	getWebhookInfo의 pending_update_count로 유실 여부 확인하고, 메시지 ID 기준으로 중복 수신 여부 대조	재연결 후 대기 메시지 4건이 전달·처리된 것은 확인됨(유실은 없었던 것으로 보임) — 중복 수신 여부는 별도로 대조하지 않아 미확인

특히 네 번째 항목(재시작 후 연결 유지)은 이번 사례에서 미해결로 남았던 위험이 그대로 검수 항목이 된 경우입니다. 인수 전에는 이 표를 실제로 수행한 뒤, 그 결과를 체크리스트 형태로 남겨두시길 권합니다.

---

SECTION 06

인수인계 — 만든 사람이 나간 다음

외주든 내부 인력이든, 만든 사람이 손을 뗀 뒤에도 돌아가야 합니다. 그러려면 워크플로 파일 말고도 넘겨받아야 할 것이 있습니다.

• 워크플로 JSON 백업본과 그 보관 위치
• 각 워크플로가 무엇을 왜 하는지 적은 1페이지 설명
• 사용 중인 계정 목록 — 어떤 계정이 어떤 권한으로 연결돼 있는지
• 암호화 키의 보관 위치
• 실패 시 연락 경로와 1차 대응 절차
• 외부 API 키의 발급 주체 (구축사 계정인가, 우리 회사 계정인가)

마지막 항목을 특히 확인하세요. API 키가 구축사 계정으로 발급되어 있으면, 계약이 끝나는 순간 워크플로도 함께 멈춥니다. 처음부터 우리 회사 계정으로 발급받는 게 원칙입니다.

---

SECTION 07

계약 전 12가지 점검 항목

그대로 견적서에 붙이거나 첫 미팅에서 물어보실 수 있게 정리했습니다.

---

SECTION 08

점검이 부담스럽다면

이 12개를 혼자 확인하기 어려우실 수 있습니다. 특히 우리 업무가 어느 라이선스 구분에 해당하는지, 실행 기록에 무엇이 남을지는 워크플로 설계를 봐야 판단이 됩니다.

받으신 견적서나 구축 계획을 보내주시면 위 12개 항목 기준으로 점검해 회신드립니다. 이미 운영 중인 워크플로가 있다면 그 구성도 함께 봐드립니다.

아직 무엇을 자동화할지 정하지 않으셨다면 그쪽이 먼저입니다 — 진단표를 무료로 받으실 수 있습니다.

---

SECTION 09

참고한 자료

모두 2026년 8월 26일 조회 기준입니다. n8n의 라이선스·요금·기능은 변경될 수 있으니 계약 시점에 원문을 다시 확인하시기 바랍니다.

• n8n, LICENSE.md (Sustainable Use License 원문)
• n8n 지원센터, Which license do I need for my use case? — 사용 사례별 라이선스 안내 및 공식 문의 창구(license@n8n.io / sales@n8n.io)
• n8n 공식 문서, Community edition features
• n8n 공식 문서, Set a custom encryption key
• n8n 공식 문서, Rotate encryption keys
• n8n 공식 문서, Manage execution data
• n8n 공식 문서, Handle errors gracefully
• n8n, Pricing
• 개인정보보호위원회, 생성형 인공지능(AI) 개발·활용을 위한 개인정보 처리 안내서 (2025.8)
• Cloudflare 공식 문서, Quick Tunnels (TryCloudflare) — 2026년 10월 24일 조회
• Cloudflare 공식 문서, Error 1033 — 2026년 10월 24일 조회
• Telegram, Bot API 공식 문서(setWebhook / getWebhookInfo) — 2026년 10월 24일 조회
• n8n 공식 문서, Configure webhook URLs with a reverse proxy(WEBHOOK_URL / N8N_WEBHOOK_URL) — 2026년 10월 24일 조회

---

이 글의 12항목 점검표는 일잘랩이 구축 발주 검토를 위해 정리한 기준이며 업계 표준이 아닙니다. 라이선스 해석과 계약 조건은 법률 자문의 대상이며, 이 글은 법률 자문이 아닙니다.

기준 시점 2026년 8월 26일 · 최종 수정 2026년 8월 26일