n8n 2.29가 배포되면서 '워크플로우에 AI를 어떻게 끼워 넣을까'라는 질문은 사실상 답이 정해졌습니다. 트리거 다음 칸에 AI Agent 노드를 놓고, 도구를 붙이고, 결과를 구조화된 JSON으로 받는다. 2026년 상반기 템플릿 통계가 말해주는 결론입니다.
숫자로 보는 변화
2026년 6월 기준 커뮤니티에 새로 등록된 워크플로우 템플릿 중 약 78%가 AI Agent 노드를 포함합니다. 1년 전 같은 시점의 41%에서 두 배 가까이 뛰었습니다. 특히 4월부터 6월 사이, 두 개 이상의 에이전트가 협력하는 멀티 에이전트 패턴은 8주 만에 정확히 두 배로 늘었습니다.
무엇이 달라졌나
1.x 시대의 AI 노드는 '프롬프트 하나 넣고 문자열 하나 받는' 구조였습니다. 이제는 다릅니다. Agent 노드는 자체적으로 도구를 호출하고, 결과를 판단하고, 필요하면 자기 자신을 다시 호출합니다. 여기에 Structured Output이 표준으로 자리 잡으면서, 후속 노드에 안전하게 값을 넘길 수 있게 됐습니다.
- AI Agent 노드 — LLM이 HTTP Request, Postgres, Google Sheets 같은 도구를 직접 호출
- Structured Output — Zod 스키마로 응답 형식을 강제, JSON 파싱 실패가 사라짐
- Vector Store 통합 — Qdrant, pgvector, Pinecone을 노드 하나로 붙임
- Sub-workflow as Tool — 기존 워크플로우를 에이전트가 호출 가능한 도구로 등록
- Human-in-the-loop 노드 — 신뢰도 낮은 판단은 자동으로 사람에게 넘김
실제 워크플로우는 이렇게 생겼다
위 4개 노드가 지금 가장 흔한 조합입니다. 웹훅으로 들어온 원문을 Agent가 읽고, 도구를 호출해 추가 정보를 붙이고, Structured Output으로 정형화한 뒤, 신뢰도 점수에 따라 자동 처리하거나 사람에게 넘깁니다.
코드로 보는 Structured Output
가장 큰 변화는 이 한 조각입니다. 프롬프트 옆에 스키마를 붙이면 응답이 항상 그 형태로 들어옵니다.
// AI Agent 노드 · Output Parser 설정
const schema = z.object({
intent: z.enum(['demo_request', 'pricing', 'support', 'other']),
confidence: z.number().min(0).max(1),
company_size: z.enum(['smb', 'mid', 'enterprise']).nullable(),
next_action: z.string(),
});
// 후속 IF 노드
if ($json.confidence < 0.75) {
return { route: 'human_review' };
}
return { route: 'auto_process' };지금 마이그레이션해야 할 3가지
- 기존 OpenAI Chat 노드 → AI Agent 노드로 교체하고 프롬프트를 시스템 메시지로 이동
- 문자열 파싱하던 후속 노드를 Structured Output 스키마로 대체 (JSON.parse try/catch 제거)
- Human-in-the-loop 분기 추가 — 신뢰도 낮은 건 슬랙으로 넘기고 승인 후 재개
멀티 에이전트, 유행인가 필요인가
커뮤니티에서 두 배로 늘어난 멀티 에이전트 패턴은 대부분 두 가지 형태입니다. 하나는 '리서처 + 작성자' 쌍으로 리서처가 도구를 써서 자료를 모으고 작성자가 정리하는 구조. 다른 하나는 '분류 에이전트가 라우팅하고 전문 에이전트가 처리'하는 구조. 후자는 예전 IF/Switch 노드의 상위 호환이라고 볼 수 있습니다.
하지만 모든 문제가 멀티 에이전트를 필요로 하지는 않습니다. 단일 Agent + 잘 정의된 도구 집합이 대부분의 실무 문제에 더 나은 답입니다. 에이전트가 늘어날수록 디버깅 비용은 지수적으로 늘어납니다.
AI를 워크플로우에 넣는 일의 절반은 '언제 사람에게 넘길지'를 정하는 일입니다. 나머지 절반은 그 판단 근거를 로그에 남기는 일이고요.— 김하영 · SynAct.ai 자동화 컨설턴트
비용은 어떻게 관리하나
- Agent 노드에 max_iterations를 5 이하로 걸어 무한 루프 차단
- 도구 호출 로그를 Postgres에 남기고 주 1회 리뷰 — 불필요한 호출 패턴을 잘라냄
- 저비용 모델(Haiku, mini)로 분류만 하고, 실제 생성은 고비용 모델로 분리
- 캐시 가능한 프롬프트는 프롬프트 캐싱 옵션 활성화
자주 묻는 질문
- Q. 기존 OpenAI Chat 노드에서 AI Agent 노드로 어떻게 마이그레이션하나요? A. 프롬프트를 시스템 메시지로 옮기고, JSON.parse try/catch 대신 Structured Output Parser에 스키마를 붙이고, 하위 노드에서 참조하던 필드명이 스키마와 일치하는지 확인하면 대부분 끝납니다. 위 '지금 마이그레이션해야 할 3가지' 섹션 참고.
- Q. 단일 에이전트와 멀티 에이전트, 언제 어떤 걸 써야 하나요? A. 문제가 하나의 도구 집합으로 풀리면 단일 에이전트가 낫습니다. 리서치→작성처럼 성격이 다른 단계가 필요하거나, 라우터가 여러 전문 에이전트로 나눠 보내야 하는 경우에만 멀티. 에이전트 하나 늘리면 디버깅 비용이 지수적으로 증가합니다.
- Q. Structured Output이 파싱 실패로 워크플로우가 멈추는 경우엔 어떻게 하나요? A. n8n 2.29의
Structured Output Parser는 자동 재시도 옵션이 내장되어 있어 대부분 재시도로 해결됩니다. 3회 재시도 후에도 실패하면 원본 응답을 로그에 남기고 사람에게 넘기는 fallback IF 노드를 추가하세요. - Q. 에이전트에 도구 20개 붙이면 왜 성능이 나빠지나요? A. LLM의 context window 안에서 도구 설명이 차지하는 비중이 커지고, 어느 도구를 부를지 결정하는 데 토큰이 낭비됩니다. 하나의 에이전트에는 3-5개가 실무 상한선. 그 이상이면 라우터-전문 에이전트 구조로 나누는 게 정답.
- Q. 신뢰도 임계값(confidence threshold)은 어떻게 정하나요? A. 처음엔 0.85처럼 높게 시작하고, 자동 처리 비율이 낮아 답답하더라도 2주 동안 로그를 쌓습니다. 실제 정답률을 사후 검증한 뒤 조금씩 내리세요. 반대로 낮게 시작해 올리는 방식은 이미 잘못 자동 처리된 케이스가 프로덕션에 남아 위험합니다.
- Q. AI Agent 노드를 프로덕션에 붙이기 전 최소 조건은? A. 네 가지 — Structured Output, 신뢰도 임계값, 승인 게이트(Wait 노드 + Slack), 감사 로그(Postgres 테이블). 이 넷 없이 프로덕션에 붙이면 첫 사고가 마지막 사고가 됩니다.
정리
2026년의 n8n은 더 이상 '규칙 기반 워크플로우 도구에 AI를 얹은 것'이 아닙니다. 워크플로우 자체가 판단과 실행을 오가는 에이전트의 실행 환경이 됐습니다. 새 워크플로우를 만들 때 '이걸 규칙으로 짤까 판단으로 맡길까'를 먼저 결정하세요. 그다음이 노드 선택입니다.