n8n v2.10.0 ~ v2.13.2 기준
IT/AI
n8n 3월 업데이트, 쓰던 워크플로 먼저 확인하세요
2026년 3월, n8n은 네 번의 마이너 버전(v2.10.0 → v2.13.0)을 연속으로 냈습니다. 멀티 에이전트 채팅 통합, MCP Tools 확장, 1Password 연동, SSRF 보호 강화까지 한 달에 이렇게 많은 변화가 쏟아진 건 올 들어 처음입니다. 그런데 꼼꼼히 살펴보면 “좋아졌다”는 말이 전부가 아닙니다. 내부 API를 호출하는 워크플로를 운영 중이라면, 이번 업데이트가 오히려 기존 플로우를 끊어버릴 수 있습니다.
멀티 에이전트 채팅 통합 — Ask와 Build가 하나가 됐습니다
v2.10.0(2026.02.23 릴리즈)의 핵심은 Ask + Build 채팅 통합입니다. 기존에는 “질문하는 창(Ask)”과 “워크플로를 만드는 창(Build)”이 별도로 존재했습니다. 이번 업데이트로 이 두 인터페이스가 하나의 채팅 창으로 합쳐졌고, 대화 흐름 안에서 자연스럽게 질의와 빌드를 오갈 수 있게 됐습니다. (출처: n8n 공식 릴리즈노트, 2026.02.23)
💡 공식 발표문과 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다 — 통합 채팅은 “브라우저를 닫아도 세션이 유지”된다고 명시됩니다. 이 말은 이전까지 브라우저 새로고침 한 번으로 작업 맥락이 날아가던 문제가 해결됐다는 뜻입니다. 복잡한 에이전트 워크플로를 여러 세션에 걸쳐 작업하는 상황에서 체감 차이가 큽니다.
핵심 변경 사항 한눈에 보기
| 기능 | 이전 | v2.10.0 이후 |
|---|---|---|
| 질의/빌드 인터페이스 | Ask / Build 분리 | 하나의 채팅 창으로 통합 |
| 세션 유지 | 새로고침 시 초기화 | 새로고침 후에도 유지 |
| 코드 변경 확인 | 별도 창에서 확인 | 채팅 안에서 diff 바로 확인 |
| AI 응답 방식 | 응답 완성 후 표시 | 실시간 스트리밍 |
솔직히 말하면, 이 변화가 비개발자에게 가장 큰 혜택입니다. 코드를 몰라도 채팅으로 워크플로를 만들고 바로 diff를 승인할 수 있는 흐름이 완성됐습니다.
MCP Tools 확장 — 에이전트가 워크플로를 직접 켜고 끕니다
v2.12.0과 v2.13.0에 걸쳐 Model Context Protocol(MCP) 기반 도구가 한층 세분화됐습니다. 가장 달라진 부분은 AI 에이전트가 워크플로를 프로그래밍 방식으로 활성화·비활성화할 수 있게 됐다는 점입니다. (출처: n8n GitHub 릴리즈, v2.12.0, 2026.03.09)
기존에는 에이전트가 워크플로를 실행하는 것까지만 가능했습니다. 이번 업데이트로 워크플로 발행(publish)과 취소(unpublish)가 별도 MCP 도구로 분리되어, 에이전트가 “언제 이 플로우를 켜고 끌지”를 스스로 판단할 수 있는 구조가 됐습니다. 실행 데이터 조회를 위한 전용 인터페이스도 추가됐고요.
💡 워크플로 라이프사이클 제어권을 AI 에이전트에 위임하는 구조는, n8n을 단순 자동화 도구에서 “스스로 자동화를 관리하는 플랫폼”으로 바꾸는 첫 번째 단추입니다. 이 흐름을 릴리즈노트와 나란히 놓으니 방향이 더 선명하게 보였습니다.
주의할 점도 있습니다
v2.14.0(2026.03.24, 프리릴리즈)에서 “AI Agent Node에서 MCP 도구 호출 시 도구 이름을 올바르게 추출하지 못하는” 버그가 발견되어 즉시 수정됐습니다. (출처: n8n GitHub Release v2.14.0, 2026.03.24) MCP 기반 에이전트를 운영 중이라면 이 버그가 v2.13.x 이하에서도 간헐적으로 나타났을 수 있으니 동작을 한번 점검해 보는 게 좋습니다.
1Password 연동, 생각보다 조건이 많습니다
v2.12.0에서 1Password가 External Secrets 프로바이더로 추가됐다는 소식이 눈에 띕니다. 이미 1Password를 쓰고 있다면 “이제 n8n에도 바로 연결할 수 있겠다”는 생각이 드실 텐데, 막상 해보면 다릅니다.
⚠️ 이 조건을 먼저 확인하세요
- Enterprise 전용: External Secrets 기능 자체가 Enterprise Self-hosted 또는 Enterprise Cloud 플랜에서만 사용 가능합니다. Community Edition에서는 접근이 안 됩니다. (출처: n8n 공식 문서 External Secrets, 2026.03 기준)
- Connect Server 별도 설치 필수: 개인 1Password 계정이나 팀 플랜에 직접 연결하는 게 아닙니다. 1Password Connect Server를 별도로 배포하고 운영해야 합니다. 이 서버를 직접 호스팅해야 한다는 뜻입니다.
- JSON 값은 미지원: n8n은 평문(plaintext) 형식의 시크릿 값만 지원합니다. JSON 오브젝트 형태의 시크릿은 쓸 수 없습니다.
이 세 가지 조건이 다 맞아떨어질 때만 실제로 쓸 수 있습니다. 조직에서 이미 HashiCorp Vault나 AWS Secrets Manager를 쓰고 있다면, 1Password 연동보다 기존 프로바이더를 그대로 쓰는 게 훨씬 간단합니다. 기존에 Infisical을 연동해 쓴 경우라면 v2.10.0부터 신규 연결이 막혔으니 마이그레이션 계획을 세워야 합니다.
💡 v2.13.0부터 역할 기반 External Secrets 접근 제어가 기본 활성화됩니다. 기존에 프로젝트 에디터 권한으로 시크릿을 참조하던 워크플로가 있다면, 업그레이드 후 시크릿 해석이 안 되는 상황이 발생할 수 있습니다. 업그레이드 전에 Settings → External Secrets에서 “Enable external secrets for project roles” 토글을 확인해 두세요.
SSRF 보호가 켜지면 내부 API 워크플로가 멈출 수 있습니다
이게 이번 3월 업데이트에서 가장 주의해야 할 부분입니다. v2.12.0의 SSRF(서버 측 요청 위조) 보호 기능은 Request Helper에 통합되어, RFC 1918 대역(10.x.x.x, 172.16.x.x~172.31.x.x, 192.168.x.x) 등 내부 네트워크 주소로 향하는 요청을 차단합니다. (출처: n8n GitHub Release v2.12.0, 2026.03.09)
보안 측면에서는 당연히 좋은 변화입니다. 그런데 실제로는 많은 팀이 n8n에서 내부 마이크로서비스 API나 개발 서버를 HTTP Request 노드로 직접 호출하는 워크플로를 운영합니다. 이런 경우 SSRF 보호가 켜지면 해당 요청이 차단되어 기존 플로우가 예고 없이 멈출 수 있습니다.
⚠️ 영향을 받는 경우
- HTTP Request 노드로 192.168.x.x 또는 10.x.x.x 대역의 내부 서버를 직접 호출하는 워크플로
- Docker 컨테이너 간 통신을 위해 172.17.x.x 같은 Docker 브리지 IP를 사용하는 경우
- localhost 또는 127.0.0.1로 자기 자신을 호출하는 워크플로
대응 방법
n8n 공식 문서는 내부 네트워크를 호출하는 워크플로가 있다면 허용 목록(whitelist) 설정이 필요할 수 있다고 명시합니다. 업그레이드 전에 HTTP Request 노드를 사용하는 워크플로를 전수 확인하고, 내부 IP를 호출하는 케이스가 있으면 환경 변수 설정을 검토하는 게 순서입니다. v2.13.0에서는 SSRF로 차단됐을 때 오류 메시지가 구체적으로 바뀌어 디버깅이 이전보다 쉬워졌습니다.
💡 2026년 3월 기준, n8n에는 CVSS 9.4~9.5짜리 RCE 취약점이 4건 연속 발견됐습니다. SSRF 보호가 이 시점에 함께 추가된 건 우연이 아닙니다. 보안 강화 조치가 연달아 나오는 배경을 같이 보면 업데이트의 무게감이 다르게 느껴집니다.
보안 CVE 4건 — 이미 패치됐지만 버전 확인이 필요합니다
3월에는 n8n 보안 이슈가 집중적으로 공개됐습니다. The Hacker News(2026.03.11)가 보도한 두 건의 CVE가 대표적입니다.
| CVE | CVSS | 내용 | 패치 버전 |
|---|---|---|---|
| CVE-2026-27577 | 9.4 | 표현식 컴파일러 샌드박스 탈출 → RCE | v2.10.1, v2.9.3, v1.123.22 |
| CVE-2026-27493 | 9.5 | Form 노드 비인증 표현식 평가 → 제로클릭 RCE | v2.10.1, v2.9.3, v1.123.22 |
| CVE-2026-27495 | 9.4 | JavaScript Task Runner 샌드박스 코드 인젝션 | v2.10.1, v2.9.3, v1.123.22 |
| CVE-2026-27497 | 9.4 | Merge 노드 SQL 쿼리 모드 코드 실행 | v2.10.1, v2.9.3, v1.123.22 |
특히 CVE-2026-27493은 n8n 계정도 필요 없는 제로클릭 공격입니다. “Contact Us” 폼의 이름 필드에 페이로드를 넣는 것만으로 서버에서 임의 명령을 실행할 수 있었습니다. (출처: The Hacker News, 2026.03.11 / Pillar Security 보고서) 현재 현재 stable 버전은 v2.12.3이고, beta는 v2.13.2이므로 이 버전 이상을 쓰고 있다면 이미 패치된 상태입니다.
자체 호스팅 인스턴스를 운영 중이면서 아직 v2.9.x 이하를 쓰고 있다면, 지금 바로 업그레이드가 필요합니다.
성능 수치로 보면 달라 보이는 게 있습니다
v2.10.0의 릴리즈노트에는 눈에 띄는 수치가 하나 있습니다. 대규모 인스턴스에서 워크플로·크레덴셜 목록 페이지의 로딩 시간이 30%~80% 단축됐다는 내용입니다. (출처: n8n 공식 릴리즈노트 v2.10.0, 2026.02.23)
30%와 80%는 차이가 큽니다. 직접 따라할 수 있는 기준으로 풀면 이렇습니다 — 워크플로 수가 많을수록 개선 폭이 커집니다. 워크플로가 수십 개 수준인 소규모 인스턴스는 체감이 거의 없을 수 있고, 수백~수천 개 이상인 엔터프라이즈 환경에서 80% 쪽에 가까운 개선을 경험할 가능성이 높습니다. 30%~80%라는 범위 자체가 인스턴스 규모에 따른 편차를 반영합니다.
💡 같은 버전에서 “대규모 실행 데이터 스트리밍 JSON 파싱”도 함께 개선됐습니다. 큰 실행 데이터를 처리할 때 스트리밍 파싱으로 메모리 사용을 줄인 건데, 이 두 변화를 나란히 보면 n8n이 이번 3월에 특히 “대용량 인스턴스 성능”에 공을 들였다는 게 보입니다.
그 외 실용적인 변경들
v2.11.0에서는 워크플로 버전 히스토리 비교 기능이 추가됐고, v2.13.0에서는 이 diff 뷰에서 버전을 오가며 검토할 수 있게 됐습니다. 복잡한 워크플로를 팀 단위로 관리할 때 유용합니다. Cloud Pro 이상 플랜에서 사용 가능합니다. 또 v2.11.0부터 Cloud에서 Slack, GitHub, Google Calendar 등 지원 서비스에 대해 OAuth 버튼 하나로 크레덴셜 설정이 끝나는 “Managed OAuth” 기능도 들어왔습니다.
운영 환경 적용 전 체크리스트
이번 3월 업데이트를 운영 인스턴스에 적용하기 전, 아래 항목을 순서대로 확인하면 예상치 못한 장애를 막을 수 있습니다.
현재 버전 확인
v2.9.x 이하라면 CVE 4건에 노출된 상태입니다. v2.12.3(stable) 이상으로 즉시 업그레이드하세요.
내부 IP 호출 워크플로 점검
HTTP Request 노드에서 RFC 1918 대역 IP를 직접 호출하는 워크플로가 있으면 SSRF 보호 설정을 미리 확인하세요.
External Secrets 역할 접근 정책 검토
v2.13.0부터 역할 기반 접근 제어가 기본 활성화됩니다. 프로젝트 에디터가 시크릿을 참조하는 크레덴셜이 있다면 업그레이드 후 동작을 반드시 확인하세요.
Infisical 사용 여부 확인
v2.10.0부터 Infisical 신규 연결이 막혔습니다. 대체 프로바이더(AWS Secrets Manager, HashiCorp Vault 등)로 마이그레이션 계획을 세우세요.
ARM64 + Docker 환경 점검
v2.13.0에서 ARM64 세그폴트가 수정됐습니다. 해당 환경이라면 업그레이드 후 안정성이 개선됐는지 확인하세요.
Customer.io 연동 워크플로 확인
v2.12.0에서 Customer.io 노드가 beta API에서 App API로 전환됐습니다. 연동 워크플로가 있다면 정상 동작 여부를 확인하세요.
Q&A
마치며
n8n 3월 업데이트는 분명 좋은 변화가 많습니다. Ask+Build 통합으로 진입 장벽이 낮아졌고, MCP Tools 확장으로 AI 에이전트가 워크플로 라이프사이클까지 다룰 수 있게 됐습니다. 성능도 개선됐고요.
그런데 SSRF 보호와 역할 기반 시크릿 접근 제어가 기본값으로 켜지는 건, 기존 운영 환경에서 생각지 못한 충격이 될 수 있습니다. 업그레이드 전에 내부 API 호출 워크플로와 External Secrets 설정을 먼저 점검하는 게 맞는 순서입니다. 이 부분이 준비됐다면, 이번 3월 릴리즈는 충분히 올릴 만합니다.
보안 CVE 4건이 한 달 안에 쏟아진 건 이 부분이 좀 아쉬웠습니다. 패치가 빠르게 이뤄진 건 맞지만, 자체 호스팅 인스턴스를 운영하는 팀이라면 앞으로 릴리즈 주기를 더 주의 깊게 챙길 필요가 있습니다.
본 포스팅 참고 자료
- n8n 공식 릴리즈노트 (v2.10.0~v2.14.0) — https://docs.n8n.io/release-notes/
- n8n GitHub Releases — https://github.com/n8n-io/n8n/releases
- n8n External Secrets 공식 문서 — https://docs.n8n.io/external-secrets/
- The Hacker News — Critical n8n Flaws Allow Remote Code Execution (2026.03.11) — https://thehackernews.com/2026/03/critical-n8n-flaws-allow-remote-code.html
- 인포그랩 인사이트 — 2026년 3월 n8n 최신 버전 주요 업데이트 (2026.03.19) — https://insight.infograb.net/release/2026/03/19/n8n-release/
본 포스팅은 n8n 공식 릴리즈노트 및 공식 문서를 기반으로 2026.03.25 기준으로 작성됐습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 최신 정보는 docs.n8n.io에서 확인하세요.
댓글 남기기