n8n 멀티에이전트 채팅, 써보면 다른 것 3가지
2026년 2~3월, n8n은 v2.10.0~v2.15.0 사이에 멀티에이전트 채팅 통합(Ask+Build 합치기)을 포함한 대규모 업데이트를 배포했습니다. 그런데 막상 써보면 “채팅 하나로 다 된다”는 인상과 실제 동작 사이에 온도차가 있습니다. 이 포스팅에서는 공식 릴리즈 커밋 원문을 직접 뜯어보고, 기대와 다를 수 있는 부분을 솔직하게 짚어드립니다.
v2.12.0: 1Password 연동
v2.13.0: Agent 커스텀 트레이싱
130건+ 버그 수정
Ask+Build 통합 채팅, 실제로 뭐가 달라졌나요?
결론부터 말씀드리면, v2.10.0의 핵심은 창 두 개를 하나로 합친 것입니다. 기존에는 질의(Ask)와 워크플로 구성(Build) 화면이 따로 있었는데, 이 두 영역이 단일 채팅 인터페이스로 병합됐습니다. 공식 GitHub 커밋 메시지는 “Merge Ask and Build into unified multi-agent chat experience”이고, 커밋 해시는 #25692입니다. (출처: n8n GitHub 릴리즈, 2026.02.23)
이와 함께 세션 영속성이 들어갔습니다. 커밋 #25404가 “WFB session persistence across page refreshes”를 구현한 건데, 이전에는 브라우저 탭을 닫으면 작업 맥락이 날아갔습니다. 이제는 새로고침 후에도 세션이 유지됩니다. 실제로 긴 워크플로를 구성하다 실수로 탭을 닫아봤을 때의 낭패가 사라진 셈입니다.
세 번째 변화는 인터랙티브 코드 diff입니다. AI가 제안한 노드 변경사항을 채팅창 안에서 diff로 보고, 그 자리에서 승인하거나 거부할 수 있습니다. 커밋 #26119에 “Render interactive code diffs in builder chat”으로 들어간 기능입니다. 코드 변경을 바로 확인하고 결정할 수 있으니, 실수로 잘못된 노드가 적용되는 케이스가 줄어듭니다.
💡 공식 발표문과 실제 UI 변화를 함께 놓고 보니 이런 차이가 보였습니다.
n8n이 “멀티에이전트 채팅 통합”이라 부르는 기능의 본질은 UI 병합입니다. 에이전트끼리 자율 협업하는 구조적 변화가 아니라, 개발자 경험(DX) 관점의 통합입니다. 이 차이를 인지하고 쓰면 기대 관리가 훨씬 쉬워집니다.
“멀티에이전트”라는 말이 가려주는 것들
n8n 커뮤니티(Reddit r/n8n)에서 소프트웨어 경력 8년의 개발자가 직접 올린 글이 있습니다. 제목이 “Multi-Agent AI in n8n is a Total Scam. You’re Just Building Pipelines, Not Agents”입니다. 2025년 6월 게시 후 스코어 66, upvote ratio 91%를 기록한 글이고, 핵심 주장은 세 가지입니다.
- 공유 메모리 없음: 각 Agent Node는 기본적으로 독립 실행됩니다. 에이전트 간 공유 메모리를 쓰려면 Airtable이나 Supabase 같은 외부 DB를 직접 연결해야 합니다.
- 사전 정의된 실행 경로: 에이전트끼리 자율적으로 서로를 호출하지 못합니다. 개발자가 미리 연결해 놓은 노드 경로만 따릅니다.
- ReAct Agent의 메모리 제한: n8n 내 ReAct Agent 타입은 현재 Memory Node를 아예 사용하지 못하는 구조적 한계가 있습니다.
이 내용을 v2.10 업데이트와 교차해서 보면 흥미로운 지점이 나옵니다. n8n이 “멀티에이전트 채팅”이라 부르는 건 빌더(Builder) 레이어의 UX 개선이지, 에이전트 런타임 레이어에서 공유 상태나 자율 협업이 가능해진 게 아닙니다. 즉, “채팅 하나로 워크플로를 만드는 경험”이 좋아진 것이고, 완성된 워크플로 안에서 에이전트들이 자율적으로 소통하는 것과는 다른 얘기입니다.
💡 에이전트 플랫폼 비교 데이터를 n8n에 직접 대입해보니 이런 그림이 나왔습니다.
2026년 3월 Reddit에서 공유된 AI 에이전트 플랫폼 비교(출처: r/Entrepreneurs, 2026.03.15)에서 n8n은 신뢰도 스펙트럼 Level 2로 분류됐습니다. “대부분의 시간에는 동작하지만 사람의 확인이 필요”한 수준입니다. RAND 연구가 집계한 에이전트 프로덕션 실패율이 80~90%인 환경에서, Level 2는 결코 낮은 평가가 아닙니다. 단, “완전 자율” 기대는 접고 사용해야 합니다.
공식 수치로 보는 v2.10~v2.13 변경사항 총정리
인포그랩이 집계한 공식 릴리즈 분석(출처: insight.infograb.net, 2026.03.19)에 따르면, 이번 4개 버전에서 130건 이상의 버그가 수정됐습니다. 그냥 숫자로 보면 감이 안 오는데, 실제로 영향 받는 영역이 넓습니다. 아래 표가 요약입니다.
| 버전 | 출시일 | 핵심 변경 | 플랜 조건 |
|---|---|---|---|
| v2.10.0 | 2026.02.23 | Ask+Build 채팅 통합, 세션 영속성, 코드 diff | Cloud/Self-hosted 모두 |
| v2.11.0 | 2026.03.02 | 관리형 OAuth, 워크플로 히스토리 비교, Human-in-the-loop 확장 | Cloud/Self-hosted 모두 |
| v2.12.0 | 2026.03.09 | 1Password External Secrets, SSRF 보호, MCP Tools 확장 | 1Password: Enterprise |
| v2.13.0 | 2026.03.16 | Agent Node 커스텀 트레이싱, 역할 기반 시크릿 기본 활성화 | 시크릿 RBAC: Enterprise |
| v2.15.0 | 2026.03.30 | 버그 수정 (stable 현재: v2.13.4) | beta |
한 가지 짚어야 할 부분이 있습니다. v2.10.0 성능 개선 커밋(#25799)에는 “대규모 실행 데이터를 스트리밍 JSON 파싱으로 처리”가 들어갔는데, 이는 메모리 사용량을 줄이기 위한 조치입니다. 대규모 인스턴스를 운영하는 분들이라면 v2.10 이전과 이후 메모리 사용 패턴이 달라질 수 있다는 점을 인지해야 합니다. 공식 릴리즈 노트에는 “30~80% 로딩 속도 개선”이 명시돼 있습니다. (출처: n8n 공식 릴리즈 노트, docs.n8n.io)
클라우드 vs 셀프호스팅, 비용 계산을 직접 해봤습니다
n8n 요금제에서 자주 오해가 생기는 부분이 있습니다. “$20/월이면 저렴하다”고 생각하고 Cloud Starter를 쓰기 시작했다가 한 달 만에 한도를 소진하는 경우가 꽤 있습니다. Lindy 블로그(2026.01.08)가 분석한 내용을 직접 검증해봤습니다.
📊 실행 횟수 계산 예시
Starter 플랜 2,500 실행/월 ÷ 31일 = 하루 약 80회
이메일 자동 분류 1개 워크플로 × 하루 100통 = 하루 100 실행
→ 25일이면 한도 소진
하루 100통짜리 이메일 하나만으로도 Starter는 한 달을 못 버팁니다.
Pro 플랜($50/월, 10,000 실행)은 같은 조건이면 하루 323회까지 버팁니다. 실제 운영 단계에서는 Pro가 현실적인 최소 라인입니다. 반면 셀프호스팅은 Hostinger 기준 월 약 22,000원(₩22,059, 2년 약정, 출처: Hostinger 한국 페이지)으로 실행 횟수 무제한입니다. 워크플로가 3개 이상이고 하루 실행 횟수가 50회를 넘어간다면, 셀프호스팅 비용이 역전됩니다.
단, 셀프호스팅에는 Enterprise 전용 기능이 빠집니다. v2.12의 1Password 연동, v2.13의 역할 기반 External Secrets, 프로젝트 스코프 시크릿 관리는 모두 Enterprise 플랜 전용입니다. (출처: n8n 공식 릴리즈 노트, docs.n8n.io) 보안 요건이 높은 팀이라면 이 점을 먼저 확인해야 합니다.
SSRF 보호와 시크릿 관리, 실무에서 반드시 챙겨야 할 이유
v2.12.0에서 Request Helper에 SSRF 보호가 들어갔습니다. 서버 측 요청 위조(Server-Side Request Forgery)는 외부 사용자가 n8n의 HTTP Request 노드를 이용해 내부 네트워크에 요청을 보내는 공격입니다. 특히 내부 API가 연결된 자동화 워크플로를 운영 중이라면 이전 버전에서 취약했습니다. v2.12는 RFC 1918 내부 네트워크 대역(10.x.x.x, 172.16.x.x~172.31.x.x, 192.168.x.x)을 기본 차단합니다.
실무에서 주의할 점이 있습니다. SSRF 보호가 켜지면 내부 API를 호출하는 기존 워크플로가 갑자기 실패할 수 있습니다. 내부 서버 URL을 직접 호출하는 노드가 있다면, v2.12 업데이트 전에 화이트리스트를 먼저 잡아야 합니다. 공식 릴리즈 노트에 이 체크리스트가 명시돼 있습니다. (출처: n8n 공식 릴리즈 노트, docs.n8n.io, 2026.03.09)
💡 1Password 연동 흐름과 실제 운영 조건을 비교해보니 주의해야 할 순서가 있습니다.
1Password 연동 방식은 “시크릿을 n8n에 저장하지 않는” 구조입니다. 1Password Connect Server에서 런타임에 가져오는 방식이라 n8n DB에 시크릿 원문이 남지 않습니다. 하지만 이를 위해 자체 호스팅 1Password Connect Server가 필요하고, 이 서버 토큰을 Read-only로 범위 지정해야 합니다. “그냥 1Password 쓰면 연동된다”가 아닙니다.
n8n 멀티에이전트 채팅을 써도 되는 조건 vs 피해야 할 상황
솔직히 말하면, n8n v2.10의 멀티에이전트 채팅은 특정 유형의 작업에서는 정말 편리하고, 다른 유형에서는 오히려 복잡함만 늘어납니다. 아래에 조건을 정리했습니다.
✅ 이런 상황이면 잘 맞습니다
- 정해진 순서대로 실행되는 업무 자동화: 이메일 수신 → 분류 → 요약 → 슬랙 전송처럼 경로가 고정된 경우. n8n의 “코드 기반 오케스트레이션”이 가장 잘 동작하는 유형입니다.
- LLM 비용을 줄이고 싶은 경우: 하나의 에이전트에 모든 것을 맡기는 것보다, 역할을 나눠 각 단계에서 소형 모델을 쓰면 토큰 비용이 줄어듭니다. Reddit 커뮤니티에서도 “에이전트를 잘게 쪼갤수록 비용과 정확도 모두 개선된다”는 실사용 경험이 반복적으로 언급됩니다.
- 워크플로를 빠르게 반복 수정하는 팀: Ask+Build 통합 채팅과 인터랙티브 diff 덕분에, 코드 수정 → 확인 → 배포 사이클이 이전보다 훨씬 짧아졌습니다.
❌ 이런 기대라면 맞지 않습니다
- 에이전트끼리 자율적으로 대화하며 작업을 나눠 가져가는 구조: 앞서 설명한 것처럼, n8n의 에이전트는 공유 메모리 없이 독립 실행됩니다. LangGraph 같은 전용 에이전트 프레임워크와는 구조가 다릅니다.
- 사람 개입 없이 24시간 자율 실행이 필요한 중요한 업무: 위 비교 자료에서 n8n은 Level 2(대부분 작동하지만 사람 확인 필요)로 분류됐습니다. 데이터 삭제, 결제 처리, 대외 발송 같은 고임팩트 작업에는 v2.6.0에 들어간 Human-in-the-Loop 기능을 반드시 같이 붙여야 합니다.
💡 RAND 연구의 80~90% 실패율을 n8n 실제 운영 패턴에 대입해봤습니다.
실패한 에이전트 프로젝트의 공통점은 “에이전트에게 너무 많은 결정을 맡긴 것”입니다. n8n에서 실제로 운영에 올라간 워크플로의 패턴을 보면, 성공 케이스는 대부분 “게이트키퍼(조정 에이전트) + 단순 전문 서브에이전트” 구조입니다. 에이전트 수가 많을수록 더 똑똑해지는 게 아닙니다.
자주 묻는 질문
Q1. n8n v2.10 업데이트 이후 Ask와 Build가 통합됐다고 하는데, 이전 버전 워크플로에 영향이 있나요?
Q2. n8n Cloud Starter($20/월)로 시작해도 될까요?
Q3. v2.12의 SSRF 보호가 켜지면 기존 워크플로가 깨질 수 있다고 했는데, 어떻게 확인하나요?
Q4. n8n에서 에이전트 간 공유 메모리를 구현하려면 어떻게 해야 하나요?
Q5. 현재 stable 버전은 몇 번이고, 업데이트 주기는 어떻게 되나요?
마치며
n8n v2.10~v2.13은 단순한 마이너 업데이트가 아닙니다. Ask+Build 통합, 세션 영속성, 코드 diff, SSRF 보호, 1Password 연동, Agent 커스텀 트레이싱까지 실무에 직접 영향 주는 변화들이 연속으로 들어왔습니다.
개인적으로 이번 업데이트에서 가장 실질적이라고 느낀 부분은 “멀티에이전트 채팅”이라는 이름보다 세션 영속성과 인터랙티브 diff입니다. 워크플로 빌드 도중 맥락을 잃는 경험이 없어지고, AI가 제안한 변경을 바로 검토할 수 있게 된 것이 실제 생산성에 더 큰 차이를 만들어줍니다.
반면 “멀티에이전트”라는 이름에서 기대하는 자율 협업 AI 팀은 아직 n8n의 영역이 아닙니다. 공유 메모리, 자율 태스크 생성, 연속 자기실행은 LangGraph나 CrewAI 같은 프레임워크의 영역입니다. n8n은 “사람이 설계한 워크플로를 안정적으로 실행하는 오케스트레이터”로서의 역할에 충실하면서, 그 경험을 점점 더 편리하게 만들고 있습니다. 그 방향 자체는 맞습니다.
📚 본 포스팅 참고 자료
- n8n 공식 릴리즈 노트 — https://docs.n8n.io/release-notes/
- n8n GitHub 릴리즈 v2.10.0 — github.com/n8n-io/n8n/releases/tag/n8n@2.10.0
- 인포그랩 — 2026년 3월 n8n 릴리즈 분석 — insight.infograb.net
- Reddit r/n8n — “Multi-Agent AI in n8n is a Total Scam” — reddit.com/r/n8n/comments/1lm1y8d/
- Reddit r/Entrepreneurs — AI Agent platforms compared, March 2026 — reddit.com/r/Entrepreneurs/comments/1ru31gk/
- n8n 요금제 — https://n8n.io/pricing/
본 포스팅은 2026년 4월 1일 기준으로 작성됐습니다. n8n 서비스 정책·UI·기능·요금제는 업데이트로 내용이 달라질 수 있습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있으며, 중요한 의사결정 전에 n8n 공식 문서(docs.n8n.io)를 직접 확인하시기 바랍니다.
댓글 남기기