n8n으로 AI 에이전트를 만들기 전에, 라이선스와 설치 방식과 승인 단계
n8n은 오픈소스가 아니라 공정 코드 라이선스다. 남에게 주는지, 서버를 누가 운영하는지, 실행이 얼마나 몰리는지, 에이전트에 승인을 걸지에 따라 판과 구성을 고르는 순서를 정리했다.
npx나 docker run 한 줄로 n8n을 띄우면 첫날은 매끄럽습니다. 막히는 곳은 몇 주 뒤에 세 군데로 나뉘어 찾아옵니다. 회사 일에 쓰다가 “이걸 고객사 서버에도 깔아 줘도 되나”라는 질문이 나오고, 실행 기록이 쌓인 SQLite 파일이 불어나고, 웹훅이 몰리는 시간대에는 편집 화면까지 느려집니다. 여기에 AI 에이전트를 얹으면 네 번째가 붙습니다. 모델이 고른 도구가 메일 발송처럼 되돌릴 수 없는 일을 하는 순간입니다. 이 넷을 설치 뒤에 하나씩 만나는 대신 처음에 한 번에 정하도록, 라이선스, 판(에디션), 구성, 승인 순서로 따라가는 글입니다. 수치와 버전은 2026-10-27 기준으로 공식 저장소, 문서, 가격 페이지를 다시 열어 확인한 값입니다. GitHub 저장소는 별 208.7k, 포크 61.3k이고, 안정판은 10월 26일에 나온 n8n@2.44.7입니다.
남에게 주는 순간 라이선스가 갈린다
README는 n8n을 “AI 에이전트와 워크플로를 만들고 배포하는 공정 코드(fair-code) 플랫폼”이라고 소개합니다. 이 이름은 오픈소스와 다릅니다. fair-code 운동의 사이트는 이를 라이선스가 아니라 모델로 설명하는데, 대체로 무료로 쓰고 배포할 수 있고 소스가 공개되며 누구나 확장할 수 있지만 저작자가 상업적 이용을 제한할 수 있는 소프트웨어를 가리킵니다. n8n의 LICENSE.md는 파일마다 적용이 다르다고 밝힙니다.
- master 브랜치의 일반 코드는 Sustainable Use License 1.0입니다.
- 파일 이름에
.ee.가 들어가거나 폴더 이름에ee가 든 코드는 이 라이선스 대상이 아니고, n8n Enterprise License가 따로 있어야 씁니다. - master가 아닌 브랜치의 내용은 라이선스가 부여되지 않습니다.
- 외부 구성 요소는 각자 원래 라이선스를 따릅니다.
Sustainable Use License의 제한 조항은 짧습니다. 소프트웨어는 자신의 내부 업무 목적이거나 비상업적·개인 용도로만 쓰고 수정할 수 있고, 다른 사람에게 배포하거나 제공하는 것은 무료이면서 비상업적일 때만 허용됩니다. 라이선스·저작권 표시는 바꾸거나 지우거나 가릴 수 없고, 상표는 관련 법에 맞게 써야 합니다. 위반하면 라이선스가 자동으로 끝나지만, 제공자의 통지를 받고 30일 안에 위반을 멈추면 소급해서 복구됩니다. 복구 뒤 다시 위반하면 영구히 끝납니다. 수정본에는 바꿨다는 표시를 눈에 띄게 넣어야 합니다.
같은 AI 워크플로 도구라도 라이선스의 모양은 제각각이라, 도구를 바꿀 때 조항부터 다시 읽어야 합니다.
| 도구 | 라이선스 모양 (각 저장소 라이선스 파일 기준) |
|---|---|
| n8n | Sustainable Use License 1.0. 내부 업무·비상업적 용도로 제한, 일부 코드는 별도 Enterprise License |
| Dify | 수정된 Apache 2.0. 서면 허락 없이 다중 테넌트(워크스페이스 하나가 테넌트 하나) 서비스 운영 불가, 프런트엔드 사용 시 로고·저작권 표시 유지 |
| Flowise | 대부분 Apache 2.0. 서버의 enterprise 폴더 등 일부 파일만 상업 라이선스 |
조항을 두 상황에 대 보면 선이 어디인지 보입니다. 아래는 편집부가 만든 가상의 상황입니다.
5명 마케팅 팀이 사내 서버에 설치하는 경우. 팀 안의 광고 보고서와 알림을 자동화하는 일은 내부 업무 용도라서 조항 그대로 읽으면 됩니다. 코드를 고쳐 내부에서 쓰는 것도 표시만 유지하면 같은 범위입니다.
웹 에이전시가 고객사마다 n8n을 설치해 주고 월 유지비를 받는 경우. 이때는 n8n을 다른 사람에게 제공하는 일이 들어갑니다. 조항은 제공을 무료이면서 비상업적일 때만 허용하므로, 이 구조는 원문을 직접 읽거나 n8n에 문의한 뒤에 정해야 합니다. 고객이 자기 계정으로 직접 설치하고 에이전시는 워크플로 제작만 맡는 구조가 같은 판단을 받는지도 원문 기준으로 따져야 합니다. 유료로 설치·운영을 대행하는 사업, 제품에 넣어 파는 일, 화면에서 라이선스 표시를 빼는 수정도 같은 쪽에 놓입니다.
판을 고르는 네 갈래
라이선스를 통과했다면 다음 질문은 서버를 누가 운영하느냐입니다. 문서의 “Choose how to use n8n”은 Cloud와 자체 호스팅을 먼저 가르고 그 안에서 플랜이나 에디션을 고르게 합니다. 아래 그림은 그 순서를 질문 세 개로 줄인 것입니다. 왼쪽 질문부터 답하다가 처음 맞는 상자에서 멈추면 됩니다.
그림 1. 첫 질문이 “예”면 라이선스 원문부터, 서버 운영이 어렵다면 Cloud로 간다
서버 운영이 가능한 쪽은 에디션이 셋입니다. Community는 무료이고 거의 전체 기능을 씁니다. Registered Community는 Community 설정의 Usage and plan에서 이메일을 등록해 무료 라이선스 키를 받으면 폴더, 에디터 안 디버그, 사용자 지정 실행 데이터가 열립니다. 유료 Business와 Enterprise는 라이선스 키로 나머지를 엽니다. 설치는 같은 제품이고 키가 기능을 여는 구조입니다. 문서가 유료 플랜이 필요하다고 꼽는 기능은 사용자 정의 변수, 환경, 외부 시크릿, 바이너리 데이터 외부 저장, 로그 스트리밍, 멀티 메인 모드, 프로젝트, SSO(SAML·LDAP), 워크플로·자격 증명 공유, Git 버전 관리입니다. 반대로 표준 로깅과 큐 모드는 유료 목록에 들지 않는다고 문서가 따로 적습니다.
Cloud 쪽은 14일 무료 체험(Pro 기능 포함) 뒤에 Starter, Pro, Enterprise 플랜으로 이어집니다. 가격 페이지에서 보면 Business는 자체 호스팅 전용이고 Cloud용 Business는 대기 목록입니다. 에이전트를 만드는 사람에게 Cloud와 자체 호스팅이 갈리는 지점은 기능보다 책임입니다. 자체 호스팅에서는 비밀 값 관리, 백업, 업그레이드, 그리고 뒤에서 다룰 보안 공지에 맞춘 버전 관리가 전부 내 일이 됩니다.
Cloud 요금을 실행 1,000회당 값으로 바꿔 보면
가격 페이지(2026-10-27 확인)는 Cloud 플랜을 연간 결제 기준 월 환산액으로 보여 줍니다. 표시된 할인은 “Save 17%“이고, 월 단위 결제 가격은 이 페이지에 따로 나오지 않습니다. 숫자를 읽는 열쇠는 “실행(execution)“의 정의입니다. 페이지의 FAQ는 실행을 워크플로 전체를 한 번 돌리는 것으로 정의합니다. 단계 수나 처리한 데이터 양은 횟수에 영향을 주지 않습니다. 월정액을 포함 횟수로 나누면 플랜을 같은 잣대로 놓을 수 있습니다.
그림 2. 실행 1,000회당 월정액(연간 결제 기준, 편집부 계산)
Pro는 Starter보다 실행 1,000회당 값이 낮습니다. 자체 호스팅 Business는 40K 실행이 포함된 월 €667이라 1,000회당 값은 가장 높지만, 이 칸이 사는 것은 실행 횟수가 아니라 SSO, 환경, 프로젝트 같은 기능이어서 같은 잣대로 비교할 대상이 아닙니다. 에이전트에게 더 중요한 것은 값이 아니라 한도입니다.
| 플랜 | 월 실행 | 동시 실행 | 실행 1회 최대 시간 | 공유 프로젝트 | 보관 실행 |
|---|---|---|---|---|---|
| Cloud Starter (€20/월) | 2.5K | 5 | 5분 | 1 | 2.5k |
| Cloud Pro (€50/월) | 10K | 20 / 50 | 40분 | 3 | 25k |
| Business, 자체 호스팅 (€667/월) | 40K | 가격 페이지에 표시 없음 | 표시 없음 | 6 | 표시 없음 |
| Enterprise | 문의 | 200+ | 40분 | 무제한 | 50k |
에이전트의 실행 한 번은 모델 호출이 여러 번 이어지는 일이라서, 실행 1회 최대 시간이 5분인지 40분인지가 만들 수 있는 에이전트의 모양을 정합니다. 횟수 면에서는 모델 호출이 몇 번이든 워크플로 한 번의 실행이므로 1회로 셉니다. 모델 사용료는 구독료와 별개로 모델 업체에 따로 냅니다.
가격 페이지와 문서가 다르게 적은 곳. 문서의 에디션 비교는 큐 모드를 Community에 포함된 기능으로, 멀티 메인 모드는 유료로 적습니다. 가격 페이지의 Business 칸에는 “Queue mode for scaling”이 나열됩니다. 문서도 기능 구성은 바뀔 수 있고 가격 페이지가 기준이라고 직접 밝히므로, 결제 전에는 가격 페이지의 해당 칸을 다시 열어 봅니다.
한 줄 설치가 해 주는 일과 시험용으로 남기는 일
자체 호스팅은 Docker 위주입니다. 문서의 한 줄 설치는 이 명령입니다.
curl -fsSL https://get.n8n.io | sh
이 방식은 예전의 npm install n8n과 npx n8n을 대신합니다. 문서는 n8n 3.0부터 npm 설치가 동작하지 않고 Docker로만 배포된다고 안내하며, 기존 npm 설치는 당분간 그대로 돕니다. 내려받은 스크립트를 바로 실행하는 형태라서 먼저 읽어 보는 방법도 문서가 직접 안내합니다.
curl -fsSL https://get.n8n.io -o get-n8n.sh
less get-n8n.sh # 내용 읽기
sh get-n8n.sh
성공하면 이런 화면이 나옵니다. 문서에 실린 예시 출력이고 버전 숫자는 예시 값입니다.
그림 3. 문서가 보여 주는 한 줄 설치의 성공 출력
출력에서 눈여겨볼 줄은 .env에 고유 비밀 값이 생성된다는 줄과 맨 아래 삭제 명령의 -v입니다. down -v는 볼륨, 곧 데이터까지 지웁니다. 같은 폴더에서 스크립트를 다시 실행하면 바꾸지 않고 “이미 있다”고만 알려 줘서 여러 번 실행해도 안전합니다. 업그레이드는 --upgrade로 합니다. .env의 N8N_VERSION과 N8N_SANDBOX_VERSION 두 줄만 바꾸고 데이터와 비밀 값, 다른 설정은 그대로 둡니다. 윈도우에서는 WSL에서 실행하라고 문서가 안내하고, Git Bash는 스크립트 전체를 n8n이 검증하지 않았습니다.
이 구성은 써 보기에 맞춘 판입니다. 기본 데이터베이스는 파일 하나짜리 SQLite이고, n8n Assistant가 코드를 돌리는 샌드박스와 검색 도구가 함께 뜹니다. 바깥에서 닿는 포트는 n8n의 5678뿐입니다. Assistant 자체는 AI 공급자 키를 넣기 전까지 꺼져 있습니다. 문서는 운영 환경에서는 번들 샌드박스 대신 Daytona를 권장한다고 따로 적습니다. 직접 쓰는 Docker Compose 구성이라면 RAM 4GB와 vCPU 2개가 최소이고, 비밀 값의 change-me 자리표시자를 모두 직접 만든 임의 값으로 바꾸며 .env는 버전 관리에서 뺍니다. 샌드박스 실행기(sandbox-runner)는 외부에 노출하면 안 되므로 방화벽에서는 n8n 포트만 엽니다.
실행이 몰리면 바뀌는 것: SQLite, Postgres, 큐 모드
규모에 따라 구성은 세 단계로 올라갑니다. 단계마다 바뀌는 것이 다르므로 한 표로 놓습니다.
| 단계 | 구성 | 올라가는 때 | 핵심 설정 |
|---|---|---|---|
| 1. 시험 | n8n 한 컨테이너 + SQLite | 혼자 써 보거나 몇 개 워크플로 | 한 줄 설치 기본값 |
| 2. 상시 운영 | n8n + Postgres | 사용자가 늘거나 24시간 도는 워크플로 | DB_TYPE=postgresdb, DB_POSTGRESDB_* |
| 3. 분산 | 메인 + Redis + 워커 + Postgres | 실행이 몰려 한 프로세스로 모자랄 때 | EXECUTIONS_MODE=queue, n8n worker |
2단계로 갈 때 알아 둘 것이 셋 있습니다. 기존 SQLite 데이터는 자동으로 옮겨지지 않아서, 새 인스턴스로 시작하는 용도로 안내됩니다. 옮겨야 한다면 문서의 내보내기·가져오기 명령이 있습니다. Docker Compose 예제에서 Postgres 18 이미지를 쓸 때는 PGDATA 줄을 지우면 안 됩니다. 문서가 직접 경고하는데, 이 줄이 없으면 Postgres 18이 볼륨이 덮지 않는 곳에 데이터를 써서 데이터베이스가 빈 채로 시작합니다. 암호화 키는 Postgres를 써도 .n8n 폴더에 남고 N8N_ENCRYPTION_KEY로 직접 지정할 수 있으니, 저장된 자격 증명을 읽을 열쇠로 보고 백업해 둡니다.
3단계의 큐 모드는 트리거와 웹훅을 받는 메인과 워크플로를 실제로 실행하는 워커를 나눕니다. 웹훅 한 건이 지나는 길은 이렇습니다.
그림 4. 메인은 접수만 하고 실행은 워커가 맡는다. 응답은 호출자가 열어 둔 연결로 돌아온다
메인이 만드는 것은 실행 기록이고 실행은 하지 않습니다. 실행 ID만 Redis에 올리고, 놀고 있는 워커가 그 ID로 데이터베이스에서 워크플로를 읽어 돌립니다. 설정은 메인과 모든 워커에 EXECUTIONS_MODE=queue를 주고, 모든 워커의 N8N_ENCRYPTION_KEY를 메인과 같게 맞추는 것이 핵심입니다. 워커는 n8n worker로 시작하고 워커당 동시 실행은 기본 10개이며 --concurrency로 바꿉니다. 문서는 5 이상을 권하는데, 작은 값에 워커를 많이 두면 데이터베이스 연결 풀이 바닥나 지연과 실패가 생기기 때문입니다. 큐 모드에서 SQLite는 권장하지 않고, Redis와 데이터베이스가 둘 다 있어야 합니다.
큐 모드로 가기 전에 쓸 수 있는 중간 장치도 있습니다. 일반 모드에서는 동시에 도는 프로덕션 실행에 제한이 없어서, 너무 많이 겹치면 이벤트 루프가 밀립니다. N8N_CONCURRENCY_PRODUCTION_LIMIT을 20처럼 정하면 웹훅·트리거로 시작한 실행이 그 수를 넘을 때 대기열에 선입선출로 기다립니다. 기본은 꺼져 있고, 수동 실행과 하위 워크플로 실행에는 적용되지 않습니다. 웹훅이 몰리는 것이 문제라면 웹훅만 받는 프로세스(n8n webhook)를 따로 늘릴 수 있고, 이때 메인은 로드밸런서에 넣지 말라고 문서가 적습니다. 메인이 요청을 받아 무거워지면 편집 화면이 느려지기 때문입니다. 메인을 여럿 두는 멀티 메인은 Enterprise에서만 열립니다.
여기에 에이전트 특유의 함정이 하나 있습니다. Simple Memory 노드는 워커가 여러 개일 때 매번 같은 워커로 간다는 보장이 없어서, 큐 모드로 도는 운영 워크플로에는 쓰지 말라고 문서가 경고합니다. 여러 워커에서도 대화 기억이 필요하면 다른 메모리 노드를 고르는 쪽으로 설계합니다.
실행 기록 14일, 1만 건 규칙
실행 데이터 정리(pruning)는 기본으로 켜져 있습니다. 끝난 지 336시간(14일)이 지났거나 전체가 10,000개를 넘으면 오래된 것부터 지웁니다. 실행 중이거나 대기 중인 것, 태그·평점이 붙은 것은 지우지 않고, 방금 끝난 기록이 사라지지 않도록 안전 버퍼 1시간을 둡니다. 기본 한도가 맞지 않으면 환경 변수로 바꿉니다.
export EXECUTIONS_DATA_PRUNE=true
export EXECUTIONS_DATA_MAX_AGE=168 # 시간 단위, 기본 336
export EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000 # 기본 10000
export EXECUTIONS_DATA_SAVE_ON_SUCCESS=none # 성공한 실행은 저장하지 않음
SQLite는 지워도 파일 크기가 줄지 않고 빈 공간을 다음 기록에 재사용할 뿐입니다. 용량을 되돌리려면 DB_SQLITE_VACUUM_ON_STARTUP을 켜거나 직접 VACUUM을 돌립니다. 성공한 실행을 저장하지 않으면 디스크는 아끼지만 에이전트가 어떤 도구를 어떤 값으로 불렀는지 되짚을 근거도 함께 사라지니, 승인이 걸린 워크플로에서는 실패와 성공을 모두 남기는 쪽이 낫습니다.
기본으로 외부와 통신하는 것들. 자체 호스팅 인스턴스는 기본값으로 업데이트 알림, 워크플로 템플릿, 진단 정보를 n8n 서버와 주고받습니다. 문서의 “Isolate n8n” 예시에 따르면 N8N_DIAGNOSTICS_ENABLED, N8N_VERSION_NOTIFICATIONS_ENABLED, N8N_TEMPLATES_ENABLED를 false로 두면 끌 수 있습니다. 폐쇄망 성격의 환경이라면 설치 직후에 정합니다.
에이전트 노드 하나가 부르는 모델 호출 횟수
n8n에서 에이전트는 노드 하나입니다. AI Agent 노드에 채팅 모델과 도구를 하나 이상 물리면 모델이 어떤 도구를 부를지 스스로 정합니다. 체인은 미리 정한 순서로 AI 구성 요소를 부르고 에이전트는 모델이 행동을 정한다는 것이 문서의 구분입니다. 공식 비교 예제는 채팅 입력에 “agent”가 들어 있으면 에이전트 노드로, “chain”이 들어 있으면 Basic LLM Chain으로 보내는데, 체인 쪽에는 모델만 있고 에이전트 쪽에는 Simple Memory와 Wikipedia 도구가 더 붙어 있습니다. 모든 AI Agent 노드는 1.82.0부터 Tools Agent로 동작하고, 이 방식은 LangChain의 도구 호출 규격을 따릅니다.
판을 고를 때 이 노드에서 챙길 숫자는 둘입니다. 하나는 Max Iterations로, 좋은 답을 만들려고 모델을 돌리는 최대 횟수이고 기본이 10입니다. 도구를 여러 번 거치는 작업에서는 이 값이 실행 한 번의 비용과 시간을 좌우하므로, 올리기 전에 작업을 몇 번 돌려 보고 정합니다. 위 가격표의 실행 시간 한도와 이어지는 값입니다. 다른 하나는 메모리의 범위입니다. 채팅 트리거에 메모리 노드를 붙이면 여러 번 이어지는 대화가 되지만 세션 사이에는 유지되지 않고, Simple Memory의 설정은 세션 키와 이전 몇 번의 상호작용을 볼지 정하는 컨텍스트 창 길이 두 가지입니다.
도구 파라미터를 모델이 채우게 하는 장치가 $fromAI()입니다. 수식 칸에 이렇게 적습니다.
{{ $fromAI('email') }}
{{ $fromAI('numItemsInStock', 'Number of items in stock', 'number', 5) }}
인자는 키(1~64자의 영문자·숫자·밑줄·하이픈), 설명, 타입(string·number·boolean·json), 기본값 순서입니다. 키는 이미 있는 데이터를 가리키는 참조가 아니라 모델에게 주는 힌트이고, 에이전트에 연결된 도구에서만 동작하며 Code 도구에서는 동작하지 않습니다. 이 값이 다음 절의 승인 화면에 그대로 나타납니다.
도구마다 승인을 거는 기준
에이전트에게 메일 발송, 레코드 수정, 데이터 삭제 같은 도구를 주면 모델이 잘못 판단했을 때의 비용이 커집니다. n8n 문서의 “도구용 사람 검토(Human-in-the-loop)“는 특정 도구를 부르기 직전에 워크플로를 멈추고 사람이 승인하거나 거부하게 합니다. 에이전트에 연결된 모든 도구에 걸 수도, 일부에만 걸 수도 있습니다.
- 에이전트가 검토가 걸린 도구를 부르기로 정한다.
- 워크플로가 멈추고 설정한 채널로 승인 요청이 간다.
- 검토자가 어떤 도구를 어떤 파라미터로 부르려는지 본다.
- 승인하면 모델이 정한 입력 그대로 도구가 실행되고, 거부하면 실행하지 않고 에이전트에게 거부 사실이 전달된다.
설정은 에이전트 노드의 도구 패널에서 Human review 항목을 열어 채널을 고르고, 검토를 걸 도구를 그 단계에 연결하는 식입니다. 채널은 Chat, Slack, Discord, Telegram, Microsoft Teams, Gmail, WhatsApp Business Cloud, Google Chat, Outlook, 아홉 가지입니다. 검토 채널은 사용자와 대화하는 채널과 달라도 되어서, 사용자는 n8n 채팅으로 에이전트와 말하고 승인 요청은 담당자의 Slack으로 보낼 수 있습니다. 검토 메시지에는 $tool.name과 $tool.parameters가 들어가 에이전트가 무엇을 하려는지 보여 줍니다.
The AI wants to use {{ $tool.name }} with the following parameters:
{{ JSON.stringify($tool.parameters, null, 2) }}
$fromAI()로 채운 값도 검토자 화면에 그대로 나오므로, 승인하는 사람은 모델이 정한 값을 눈으로 보고 결정합니다. 다른 에이전트의 도구로 쓰이는 하위 에이전트 안의 검토 단계도 올바르게 동작합니다. 문서가 권하는 대상은 되돌릴 수 없는 작업, 외부로 나가는 소통, 구매, 규정과 관련된 단계입니다. 처음에는 넓게 걸어 두고 신뢰가 쌓이면 줄이라는 것도 문서의 조언입니다.
거부 뒤의 동작은 시스템 프롬프트가 정합니다. 문서는 승인 대상 도구와 거부 시 응답을 시스템 프롬프트에 적어 두라고 경고하고, 그래야 에이전트가 거부를 조용히 넘기지 않고 사용자에게 알리거나 대안을 냅니다. 5명 팀의 공용 문의 메일함을 정리하는 가상의 에이전트로 보면 이런 모양이 됩니다. 아래는 편집부가 구성 방법을 보여 주려고 꾸민 예시이고 화면 문구는 실제와 다를 수 있습니다.
[시스템 메시지]
- 메일 조회·검색 도구는 승인 없이 쓴다.
- 답장 발송 도구는 사람 승인이 필요하다. 거부되면 메일을 보내지 말고,
사용자에게 거부됐다고 알린 뒤 초안만 보여 준다.
[흐름]
사용자 어제 들어온 환불 문의 중 답이 안 나간 것만 모아서 답장 초안 써 줘.
에이전트 (조회 도구 실행, 승인 없음) 3건이 대기 중입니다. 발송 도구를 호출합니다.
n8n 워크플로 정지, 담당자 Slack에 도구 이름·받는 사람·제목·본문 전달
담당자 (거부)
에이전트 발송이 거부되어 메일은 보내지 않았습니다. 초안은 아래에 남깁니다.
10월 보안 공지 두 묶음으로 정하는 업그레이드 규칙
공식 GitHub 보안 공지 목록을 보면 n8n은 공지가 잦은 제품입니다. 최근 두 묶음만 봐도 에이전트 운영과 직접 닿는 결함이 있습니다.
| 공지일 | 대표 결함 (GHSA 번호) | 수정된 버전 |
|---|---|---|
| 9월 30일 | MCP 워크플로 검증기의 공유 프로토타입 변조로 소유자 계정 탈취(GHSA-5jr4-xmvf-frmj, 높음, MFA 계정은 영향 없음) | 2.41.4, 2.42.1 이상 |
| 9월 30일 | Send-and-Wait 노드의 HMAC 우회로 대기 중인 실행을 무인증으로 승인(GHSA-728h-pmr2-7cgh, 높음) | 2.41.4, 2.42.1 이상 |
| 10월 14일 | 서명이 빠진 웹훅 응답 경로로 저장형 XSS(GHSA-mp7q-23hg-35cf, 높음) | 1.123.85, 2.43.5, 2.44.1 이상 |
목록 첫 페이지의 10건은 모두 10월 14일자이고 높음이 3건, 보통이 7건입니다. 현재 안정판인 2.44.7(10월 26일)은 위 수정 버전보다 위에 있고, 1.x 계열은 같은 날 1.123.88이 나왔습니다. 두 번째 줄의 Send-and-Wait는 사람에게 승인을 묻는 노드라서, 승인 단계를 쓰는 워크플로라면 이 노드 앞에 공개 트리거가 있는지부터 봅니다. 공지는 재개 토큰을 가진 쪽이 승인을 대신할 수 있었다고 설명하고, 임시 대책보다 업그레이드가 해결책이라고 적습니다. 첫 줄의 MCP는 인스턴스에 내장된 MCP 서버 기능이어서 쓰지 않으면 끌 수 있다고 공지가 임시 대책으로 안내합니다.
규칙은 단순합니다. 한 줄 설치로 시작했다면 .env의 N8N_VERSION이 안정판 쪽인지 정기적으로 보고, 올리기 전에 N8N_ENCRYPTION_KEY와 데이터베이스를 백업합니다. 업그레이드는 앞에서 본 --upgrade 한 줄입니다. 업그레이드를 미루는 동안에는 가림막이 필요합니다. 웹훅은 Basic, Header, JWT, n8n 사용자 인증(OAuth2) 중에서 인증을 고르고, IP 허용 목록을 비우면 어느 주소에서든 호출되며 허용 목록에 없는 주소는 403을 받습니다. 웹훅 본문 한도는 16MB이고 자체 호스팅은 N8N_PAYLOAD_SIZE_MAX로 바꿉니다.
바깥으로 나가는 쪽의 가림막은 SSRF 보호입니다. 2.12.0부터 N8N_SSRF_PROTECTION_ENABLED=true로 켜면 HTTP Request처럼 사용자가 다루는 노드의 요청을 차단 대역과 대조하고, 리다이렉트 대상과 DNS 해석 결과까지 검사합니다. 에이전트는 요청할 주소를 대화 중에 정하기 때문에 조작된 입력이 클라우드 메타데이터 주소나 내부 서비스로 향할 수 있어서 이 장치가 의미를 가집니다. 기본 차단 대역은 10.0.0.0/8·172.16.0.0/12·192.168.0.0/16 같은 사설 주소, 127.0.0.0/8 루프백, 169.254.0.0/16 링크 로컬 등입니다. 허용이 필요한 내부 서비스는 N8N_SSRF_ALLOWED_HOSTNAMES나 N8N_SSRF_ALLOWED_IP_RANGES로 열고, 호스트 이름 허용은 IP 차단 검사를 건너뛰므로 내가 관리하는 이름만 넣습니다. 문서는 이것을 추가 방어선으로 규정하고 방화벽·보안 그룹 같은 네트워크 통제를 먼저 두라고 말합니다.
읽기 전용 점검으로는 n8n audit이 있습니다. n8n이 도는 환경의 CLI에서 실행하고, API로 부를 때는 인스턴스 소유자로 인증합니다.
n8n audit
보고서는 다섯 범주로 나뉩니다. 자격 증명은 어느 워크플로에서도 안 쓰이거나 최근 활성 워크플로에 없는 것을, 데이터베이스는 SQL 노드의 쿼리 안 수식을, 파일 시스템은 파일을 만지는 노드를, 노드는 호스트에서 코드를 실행할 수 있는 위험 노드와 커뮤니티 노드를, 인스턴스는 보호되지 않은 웹훅과 오래된 버전 여부를 짚습니다.
설치한 주에 확인할 네 가지
설치를 마친 주에 아래 넷을 넘기면 앞에서 갈린 길이 설정에 반영됩니다.
- 라이선스 이 인스턴스가 내부 업무용인지, 누군가에게 제공하는 구조인지 한 줄로 적고, 제공이 들어 있다면 라이선스 원문이나 n8n 문의 결과를 같이 남겨 둔다
- 버전과 백업
.env의N8N_VERSION이 최신 안정판 계열인지 보고,N8N_ENCRYPTION_KEY와 데이터베이스를 업그레이드 전에 백업해 둔다 - 운영 구성 상시 운영이면 Postgres로 옮겼는지, 큐 모드라면 모든 워커의 암호화 키가 같고 Simple Memory를 쓰지 않는지, 실행 기록 보관 기간이 맞는지 본다
- 에이전트 가림막 읽기 도구부터 연결하고, 쓰기·삭제·발송 도구는 Human review를 걸고, 시스템 메시지에 거부 시 행동을 적고, Max Iterations와 웹훅 인증을 정했는지 본다