2026.03.25 기준
IT/자동화
n8n 2026년 3월 업데이트,
무료 플랜엔 없는 기능이 있습니다
v2.10.0부터 v2.13.3까지 한 달 사이 10개 이상의 릴리즈가 쏟아졌습니다. 멀티 에이전트 채팅 통합, 1Password 연동, SSRF 보호, 비주얼 diff까지 — 읽어보면 전부 내 것 같지만, 절반은 Enterprise 전용입니다. 업그레이드 전에 어느 기능이 어느 플랜에 묶여 있는지 먼저 확인하는 게 맞습니다.
한 달에 10개 릴리즈 — n8n이 이렇게 빠른 이유
결론부터 말씀드리면, n8n은 2026년 3월에만 마이너·패치 버전을 합쳐 10개 이상 릴리즈했습니다. v2.10.0(2월 23일)을 시작으로 v2.11.0(3월 2일), v2.12.0(3월 9일), v2.13.0(3월 16일), 그리고 v2.13.3·v2.14.0(3월 24~25일)까지 — 공식 릴리즈 노트에 그대로 나와 있습니다. (출처: n8n 공식 릴리즈 노트, docs.n8n.io/release-notes/, 2026.03.25 기준)
주 1회 마이너 배포가 n8n의 공식 방침입니다. 이 속도가 가능한 건 n8n이 워크플로 로직 실행과 에디터 UI를 분리한 아키텍처를 유지하고, 자동화 테스트 파이프라인을 적극 운영하기 때문입니다. 빠르다는 건 장점이지만, 그만큼 운영 중인 셀프호스팅 인스턴스를 자주 업그레이드해야 한다는 뜻이기도 합니다.
현재(2026.03.25 기준) 공식 채널이 권고하는 버전은 다음과 같습니다.
| 채널 | 버전 | 릴리즈일 | 권고 대상 |
|---|---|---|---|
| Stable | v2.13.3 | 2026.03.25 | 운영 환경 |
| Beta | v2.14.1 | 2026.03.25 | 테스트 환경 |
멀티 에이전트 채팅 통합 — Ask와 Build가 하나로
v2.10.0의 가장 큰 변화는 Ask(자연어 질의)와 Build(워크플로 구성)를 하나의 채팅 인터페이스로 합친 것입니다. 기존엔 AI에게 “슬랙 알림 자동화 만들어줘” 라고 물으면 답변만 나왔고, 실제 빌드는 별도 패널에서 해야 했습니다. 이제 채팅 창 안에서 AI가 제안한 코드 변경을 diff로 보고 바로 승인하거나 수정할 수 있습니다.
세션 영속성도 추가됐습니다. 브라우저를 닫았다 열어도 작업 맥락이 살아 있습니다. 이전엔 새로고침 한 번에 대화 흐름이 날아갔는데, 이 문제가 해결됐습니다. 비개발자도 AI와 대화하듯 워크플로를 만들 수 있는 환경이 점점 완성되고 있습니다.
캔버스 채팅 스트리밍도 이번에 들어왔습니다. AI 응답이 실시간으로 타이핑되듯 나타납니다. 작은 변화처럼 보이지만, 긴 워크플로를 생성할 때 응답 완료를 기다리는 체감 시간이 확연히 줄어듭니다.
신기능의 절반은 Enterprise 전용입니다
💡 공식 릴리즈 노트를 버전별로 나란히 놓고 보면 티어 구분이 훨씬 명확하게 보입니다.
3월 릴리즈 노트를 직접 펼쳐보면 주요 신기능마다 “(Enterprise)” 딱지가 붙어 있습니다. 아래 표로 정리했습니다.
| 기능 | 버전 | 티어 |
|---|---|---|
| Visual diff (버전 히스토리 비교) | v2.13.0 | Cloud Pro+ |
| Project-scoped External Secrets | v2.11.0 / v2.13.0 | Enterprise 전용 |
| 1Password External Secrets | v2.12.0 | Enterprise 전용 |
| Custom Roles Assignments 탭 | v2.11.0 | Enterprise 전용 |
| Folder 기반 Push/Pull 필터 (Source Control) | v2.13.0 | Enterprise 전용 |
| MCP Tools 워크플로 발행/취소 | v2.12.0 | 전 티어 |
| SSRF 보호 설정 | v2.12.0 | 전 티어 |
| 멀티 에이전트 채팅 통합(Ask+Build) | v2.10.0 | 전 티어 |
| Cloud 관리형 OAuth(원클릭 연결) | v2.11.0 | Cloud 전용 |
셀프호스팅 Community 버전을 쓰고 있다면 Visual diff, 1Password 연동, Project-scoped External Secrets은 쓸 수 없습니다. n8n 공식 릴리즈 노트에 각 기능마다 플랜 요건이 명시돼 있습니다. (출처: n8n 공식 릴리즈 노트, 2026.03.25 기준)
이 부분이 좀 아쉬웠습니다. 릴리즈 노트 헤드라인만 보면 기능이 쏟아지는 것 같은데, 막상 Community 플랜이나 Cloud Starter에서 확인해보면 잠겨 있는 기능이 많습니다. 업그레이드 전에 본인 플랜에서 실제로 활성화되는지 꼭 확인이 필요합니다.
“무료 셀프호스팅”의 실제 위험 — CVSS 10.0 취약점 있었습니다
💡 보안 리포트 수치와 릴리즈 노트 패치 내역을 같이 놓고 보면 이 취약점이 얼마나 심각했는지가 더 선명하게 드러납니다.
셀프호스팅 n8n이 “무료”라는 건 사실입니다. 하지만 2026년 1월, CVSS 10.0 만점짜리 취약점(CVE-2026-21858)이 공개됐습니다. Cyera Research Labs가 발견하고 ‘Ni8mare’라 이름 붙인 이 취약점은 인증 없이도 원격 코드 실행이 가능한 수준이었습니다. (출처: Aikido Security, aikido.dev/blog, 2026.01.08)
공격 흐름은 이렇습니다. Form Webhook 노드가 Content-Type 헤더를 제대로 검증하지 않아서, 공격자가 조작된 JSON 요청을 보내면 서버의 임의 파일을 읽을 수 있었습니다. 거기서 SQLite 데이터베이스를 꺼내고, 암호화 키를 복원해 관리자 세션을 위조하고, 최종적으로 임의 명령을 실행하는 체인이 완성됐습니다. 전 세계 약 10만 대 서버가 노출됐을 것으로 Cyera는 추산했습니다.
패치는 v1.121.0 이상에서 제공됩니다. 현재 v2.x 계열을 쓰고 있다면 이 취약점은 이미 해결된 버전입니다. 중요한 건 이 취약점이 Cloud 플랜에는 영향이 없었다는 점입니다. 내부 파일 시스템에 접근하는 경로 자체가 SaaS 환경에서는 차단돼 있기 때문입니다. 셀프호스팅의 자유와 보안 관리 책임은 항상 함께 따라옵니다.
⚠️ 셀프호스팅 운영 시 즉시 확인할 것
현재 버전이 v1.121.0 미만이라면 즉시 업그레이드하세요. Form/Webhook 노드를 인터넷에 열어뒀다면 접근 제한 설정을 점검하고, 워크플로에 저장된 API 키·OAuth 토큰을 모두 교체하는 것이 권고됩니다. (출처: Aikido Security, CVE-2026-21858 권고문)
v2.10의 성능 개선, 체감되는 조건이 따로 있습니다
v2.10.0 릴리즈 노트는 “워크플로·크레덴셜 목록 페이지 로딩 시간을 30~80% 줄였다”고 적고 있습니다. (출처: n8n 공식 릴리즈 노트, v2.10.0, 2026.02.23) 30~80% 차이면 2.5배 넘는 범위입니다. 어떤 경우에 80%가 되고 어떤 경우에 30%에 그치는지, 공식 문서에서 별도 이유를 밝히지 않았습니다.
커뮤니티 포럼 데이터를 보면 맥락이 보입니다. 개선 효과가 크게 나타나는 건 워크플로와 크레덴셜 수가 많은 대규모 인스턴스입니다. 반면 수십 개 이하의 소규모 인스턴스에서는 “느리다”는 체감 자체가 없었으니 개선폭도 작게 느껴질 수밖에 없습니다. (출처: n8n Community 포럼, “N8n is so slow”, 2026.02.03)
더 주목할 부분은 v2.x 업그레이드 이후 Queue Mode 안정성이 오히려 나빠진 사례 보고도 있다는 점입니다. (출처: n8n Community, “After Upgrading n8n self-hosted to v2.x, Queue Mode Reliability Much Worse”, 2026.01.08) 성능 개선과 안정성 회귀가 같은 버전에서 동시에 나타나는 상황이라, 대규모 환경에서 업그레이드할 때는 스테이징 환경 검증이 필수입니다.
SSRF 보호 추가가 말해주는 것 — AI 에이전트 시대의 새 위협
💡 멀티 에이전트 채팅 통합과 SSRF 보호가 같은 업데이트 사이클에 들어온 타이밍을 같이 보면 의도가 보입니다.
v2.12.0에서 Request Helper에 SSRF(Server-Side Request Forgery) 보호가 추가됐습니다. SSRF는 서버가 공격자 지시대로 내부 네트워크에 요청을 보내도록 유도하는 공격입니다. RFC 1918 대역(192.168.x.x, 10.x.x.x, 172.16~31.x.x)으로 향하는 요청이 차단됩니다.
흥미로운 건 타이밍입니다. n8n은 v2.10.0에서 AI 에이전트가 워크플로를 직접 구성하는 멀티 에이전트 채팅 통합을 출시했고, v2.12.0에서 바로 SSRF 보호를 넣었습니다. AI 에이전트가 HTTP Request 노드를 다루는 범위가 넓어질수록 내부 서비스를 외부에 노출할 가능성도 커집니다. n8n 스스로 이 위험을 인지하고 방어막을 빠르게 넣었습니다.
주의할 점이 있습니다. 내부 API를 호출하는 기존 워크플로가 있다면 SSRF 보호 설정이 켜진 후에 차단될 수 있습니다. v2.12.0으로 업그레이드할 때 내부 네트워크 대역을 호출하는 워크플로를 미리 확인하고 화이트리스트 설정을 잡아두는 것이 좋습니다.
Q&A
Q1. 셀프호스팅 Community 버전에서 이번 3월 업데이트 기능을 전부 쓸 수 있나요?
전부는 아닙니다. SSRF 보호, MCP Tools 확장, 멀티 에이전트 채팅 통합, Agent Node 커스텀 트레이싱은 Community 버전에서도 쓸 수 있습니다. 반면 Visual diff(버전 히스토리 비교), 1Password External Secrets, Project-scoped External Secrets, Folder 기반 Source Control 필터는 Enterprise 플랜에서만 활성화됩니다. 공식 릴리즈 노트에 각 기능마다 티어 표시가 있으니 직접 확인하는 것이 빠릅니다.
Q2. CVE-2026-21858 취약점이 지금도 위험한가요?
v1.121.0 이상 또는 v2.x 계열을 쓰고 있다면 이 취약점은 패치된 상태입니다. 위험한 경우는 아직 v1.121.0 미만 버전을 운영 중이고, Form/Webhook 노드가 인터넷에 열려 있는 경우입니다. Cloud 플랜은 영향을 받지 않았습니다.
Q3. SSRF 보호가 켜지면 기존 워크플로가 깨질 수 있나요?
내부 네트워크 대역(192.168.x.x, 10.x.x.x 등)을 직접 호출하는 HTTP Request 노드가 포함된 워크플로는 v2.12.0 업그레이드 후 차단될 수 있습니다. 업그레이드 전에 해당 워크플로를 파악하고, n8n SSRF 보호 화이트리스트 설정을 통해 허용 대역을 지정해두는 것이 좋습니다.
Q4. 1Password External Secrets를 쓰려면 어떤 준비가 필요한가요?
Enterprise 플랜이어야 하고, 자체 1Password Connect Server를 배포해야 합니다. 공식 절차는 1Password Connect Server를 먼저 세팅하고 접근 토큰을 발급받은 뒤, n8n Settings > External Secrets에서 1Password 프로바이더를 선택하고 URL과 토큰을 입력하는 순서입니다. 1Password SaaS 환경이 아닌 self-hosted Connect Server 기반에서만 작동합니다.
Q5. v2.14.0이 Beta인데 지금 올려도 괜찮을까요?
운영 환경이라면 현재 Stable 채널인 v2.13.3을 권장합니다. n8n은 Beta 버전을 “불안정할 수 있음”으로 분류하고 있습니다. v2.14.0은 2026.03.24에 Pre-release로 나왔고, 바로 다음 날 v2.14.1 버그 수정 패치가 나온 것을 보면 아직 안정화 작업이 진행 중입니다. 테스트 환경에서 먼저 검증한 뒤 Stable 업데이트를 기다리는 것이 안전합니다.
마치며 — 총평
2026년 3월 n8n 업데이트는 양이 많고 방향성이 분명합니다. AI 에이전트와 자동화의 경계를 허물고, 보안은 강화하고, 팀 협업 기능은 Enterprise 쪽에 집중하는 흐름이 v2.10~v2.13에 걸쳐 일관되게 나타납니다.
솔직히 말하면, 릴리즈 노트 헤드라인이 매력적으로 보이도록 구성돼 있어서 처음엔 모든 기능이 내 것인 것처럼 느껴집니다. 막상 파보면 핵심 기능의 상당수가 Enterprise 전용이고, 셀프호스팅 Community 사용자가 당장 체감할 수 있는 변화는 멀티 에이전트 채팅 통합, MCP Tools 확장, SSRF 보호 정도입니다.
업그레이드 시점은 v2.13.3 Stable을 쓰는 것이 지금 기준으로 가장 안전합니다. Queue Mode를 운영 중이라면 반드시 스테이징에서 먼저 확인하고, 내부 네트워크를 호출하는 워크플로가 있다면 SSRF 화이트리스트 설정부터 준비해두세요.
📎 본 포스팅 참고 자료
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. n8n은 매주 새 버전을 출시하는 플랫폼으로, 기능 가용 범위·티어 구분·보안 권고 내용은 언제든 달라질 수 있습니다. 최신 정보는 반드시 n8n 공식 문서에서 확인하세요.
댓글 남기기