블루오리의 블로그

핵심 요약

n8n 멀티 에이전트(Multi-Agent)는 하나의 AI가 모든 걸 처리하는 대신, 역할이 다른 여러 에이전트가 협력해 복잡한 업무를 처리하는 아키텍처다.
핵심은 게이트키퍼 → 매니저 → 전문가 3단계 구조로 역할을 분리하는 것.
이 구조만 잡으면 신뢰도는 올라가고, 에러는 줄어든다.

"ChatGPT한테 시키면 다 해주지 않아?" 라는 말, 나도 처음엔 그렇게 생각했다.
그런데 실무에서 AI를 붙여보면 금방 벽에 부딪힐꺼다.

고객 문의 하나를 처리한다고 해보자.
욕설 필터링 → 카테고리 분류 → 데이터 조회 → 답변 생성 → 품질 검수 → 발송.
이 6단계를 에이전트 하나에게 다 맡기면 어떻게 될까? 중간에 데이터 조회가 실패해도, 답변 생성이 이상해도, 에이전트는 그냥 결과를 뱉어버린다. 사람이 뒤에서 다 검토해야 하는 상황이 벌어지지.

그래서 나온 개념이 멀티 에이전트 아키텍처다.
복잡하게 들리지만 핵심은 단순하다.

일 잘하는 팀처럼 역할을 나누면 된다는 거다.
오늘은 n8n으로 이걸 실제로 구현하는 방법을 단계별로 정리해보자. 🛠️

🤖 n8n 멀티 에이전트란 정확히 무엇인가?

n8n에서 에이전트(Agent)는 LLM + 메모리 + 도구(Tool)를 하나의 노드로 묶은 실행 단위다. 여기에 "멀티(Multi)"가 붙으면, 이 에이전트들이 서로 데이터를 주고받으며 역할을 분담하는 구조가 된다는 뜻이다.

2025년 기준 n8n은 서브 에이전트(Sub-Agent) 노드를 공식 지원한다. 메인 에이전트가 작업을 판단하고, 세부 처리는 서브 에이전트한테 위임하는 계층형 구조가 GUI 안에서 바로 만들어지는 거다.

구분	단일 에이전트	멀티 에이전트
책임 범위	전체 처리 담당	역할별 분리
에러 격리	전체 실패 위험	해당 에이전트만 실패
확장성	구조 전체를 수정해야 함	해당 에이전트만 교체
신뢰도	검증 지점 없음	단계별 검증 가능

⚠️ 왜 단일 에이전트는 한계가 있을까?

단일 에이전트의 치명적인 약점은 컨텍스트 오염이다. 하나의 프롬프트 안에 필터링, 분류, 생성, 검수가 뒤섞이면 LLM은 역할 사이에서 혼선을 일으킨다. 예를 들어 "욕설도 걸러내고 답변도 생성해"라고 시키면, 욕설 필터가 느슨해지거나 답변이 엉뚱해지는 현상이 자주 발생하는 것이다.

실제로 n8n으로 고객 응대 워크플로우를 처음 만들 때, 하나의 에이전트 노드에 12개 지시사항을 때려 넣었다가 답변 품질이 들쑥날쑥해서 결국 다 갈아엎었다. 지시사항이 많을수록 LLM은 우선순위를 잘못 판단한다.

💡 핵심 원칙

에이전트 하나는 하나의 책임만. 소프트웨어 개발의 단일 책임 원칙(SRP)을 AI 워크플로우에 그대로 적용하는 게 멀티 에이전트 설계의 출발점이다.

🏗️ n8n 멀티 에이전트 3계층 아키텍처

n8n 공식 문서와 실제 운영 경험을 합쳐서 정리한 구조야. 게이트키퍼 → 매니저 → 전문가 3계층이 핵심이고, 각 레이어가 맡은 역할이 명확히 분리돼 있다.

1단계. 게이트키퍼 에이전트 — 입력을 검증하고 분류한다

모든 요청이 처음 통과하는 문지기다. 악성 입력을 차단하고, 요청 유형을 분류해서 매니저한테 넘기는 역할. 이 단계가 없으면 프롬프트 인젝션 공격이나 이상한 입력이 그대로 내부 로직을 건드린다.

System Prompt — 게이트키퍼 에이전트

당신은 입력 검증 전문가입니다.
아래 기준으로 입력을 분석하세요.

[검증 규칙]
1. 욕설/혐오 표현 포함 시 → type: "blocked"
2. 일반 문의 → type: "inquiry"
3. 기술 지원 요청 → type: "technical"
4. 불만/환불 요청 → type: "complaint"

반드시 JSON으로만 응답하세요:
{"type": "...", "summary": "...", "priority": 1-5}

n8n에서는 이 에이전트의 출력 JSON을 Switch 노드로 받아서 분기 처리한다. type 값에 따라 다음 에이전트로 라우팅하는 구조다.

2단계. 매니저(오케스트레이터) 에이전트 — 작업을 분배하고 조율한다

게이트키퍼가 분류한 요청을 받아서, 어떤 전문가 에이전트에게 어떤 순서로 일을 시킬지 결정하는 역할이다. 팀 리더라고 생각하면 된다.

n8n에서 매니저 에이전트는 워크플로우 호출 도구(Execute Workflow Tool)를 사용해서 전문가 에이전트를 서브 워크플로우로 실행시킨다. 각 전문가의 결과를 받아서 통합하고 최종 판단을 내린다.

✅ 실전 팁

매니저 에이전트의 시스템 프롬프트에는 "어떤 도구를 언제 써야 하는지"만 명시한다. 세부 처리 방법은 전문가 에이전트한테 맡겨야 컨텍스트가 오염되지 않는다.

3단계. 전문가 에이전트 — 특화된 작업만 처리한다

이 레이어가 실제 작업이 일어나는 곳이다. 전문가 에이전트 종류는 업무에 따라 다양하게 구성할 수 있다.

🔍 RAG 조회 에이전트

벡터DB에서 관련 문서를 검색해 컨텍스트를 보강

✍️ 답변 생성 에이전트

RAG 컨텍스트를 기반으로 자연스러운 답변 작성

🛡️ 품질 검수 에이전트

생성된 답변이 정책·규정에 맞는지 검증

📊 DB 조회 에이전트

주문/회원 정보를 실시간으로 조회해 데이터 제공

🧠 에이전트 간 메모리 공유는 어떻게 할까?

멀티 에이전트에서 가장 많이 막히는 부분이 바로 메모리다. n8n의 에이전트 노드는 기본적으로 워크플로우가 끝나면 컨텍스트가 사라지기 때문이다. 그래서 에이전트 간 상태 공유는 외부 저장소를 써야 한다.

실전에서 사용할 수 있는 방법은 두 가지.

방법 1. n8n 내장 메모리 노드 (단기 세션용)

Window Buffer Memory 노드를 각 에이전트에 연결하면 동일 세션 내 대화 흐름을 유지할 수 있다. 설정은 간단하고, 세션 ID만 일치시켜 주면 에이전트끼리 같은 대화 맥락을 공유한다.

방법 2. PostgreSQL / Redis 외부 메모리 (장기 상태용)

세션을 넘어서 사용자 히스토리나 작업 중간 상태를 저장하려면 외부 DB가 필요하다. 각 에이전트가 처리 결과를 DB에 기록하고, 다음 에이전트가 이를 읽어서 이어 처리하는 구조다.

n8n — 에이전트 간 상태 공유 흐름 (의사코드)

// 게이트키퍼 에이전트 출력 저장
Postgres.insert({
  session_id: $sessionId,
  stage: "gatekeeper",
  result: { type: "technical", priority: 3 }
})

// 전문가 에이전트에서 이전 결과 읽기
const prev = Postgres.query(
  "SELECT result FROM sessions WHERE session_id = $1",
  [$sessionId]
)

🚀 실전 예시 — 고객 문의 자동 처리 파이프라인

직접 구현해서 운영 가능한 구조다.
하루 평균 200건 이상의 문의를 사람 개입 없이 처리하고 있다고 한다.
전체 흐름을 보자.

Webhook

문의 수신

→

게이트키퍼

검증 + 분류

→

매니저

작업 분배

→

전문가 에이전트

RAG + 생성 + 검수

→

발송

Email/Slack

처음에 단일 에이전트로 만들었을 때는 오답률이 18% 수준이었다고 한다.
3계층 구조로 바꾸고 나서 7%대로 내려왔고, 품질 검수 에이전트를 추가하자 4% 미만으로 안정화됐는데, 수치가 작아 보여도 하루 200건이면 꽤 큰 차이다.

⚡ 실전에서 마주치는 문제 3가지와 해결법

문제 1. 에이전트 응답이 너무 느려요

에이전트가 늘어날수록 전체 레이턴시가 쌓인다. 독립적인 에이전트는 n8n의 병렬 분기(Parallel Branch)로 동시에 실행해서 전체 처리 시간을 줄일 수 있다. 예를 들어 RAG 조회와 DB 조회는 순서 상관없이 동시에 돌릴 수 있다는 거다.

문제 2. 어느 에이전트에서 에러가 났는지 모르겠어요

각 에이전트 출력에 stage 필드를 반드시 넣는다. 에러 발생 시 어느 단계에서 실패했는지 추적하기 훨씬 쉬워진다. n8n의 Error Trigger 노드와 연결하면 Slack 알림까지 자동화할 수 있다.

문제 3. API 비용이 생각보다 많이 나와요

게이트키퍼처럼 단순 분류 작업에 GPT-4o를 쓰면 낭비다. 에이전트별 모델을 다르게 설정하는 게 핵심이다. 게이트키퍼는 GPT-4o-mini, 최종 답변 생성만 GPT-4o를 써라. 이것만 해도 API 비용을 40~60% 절감할 수 있다.

에이전트	권장 모델	이유
게이트키퍼	GPT-4o-mini	단순 분류 작업, 속도 우선
매니저	GPT-4o-mini	라우팅 판단, 복잡도 낮음
RAG 조회	GPT-4o-mini	검색 키워드 추출, 경량으로 충분
답변 생성	GPT-4o	품질이 직접 결과에 영향
품질 검수	GPT-4o-mini	규칙 기반 검증, 판단 단순

🎯 마무리 — 지금 당장 시작하는 방법

멀티 에이전트 아키텍처, 처음엔 복잡해 보여도 막상 시작하면 생각보다 단순하다. 내가 추천하는 순서는 다음과 같다.

기존 단일 에이전트 워크플로우에서 역할을 종이에 써보기 — 몇 가지 역할이 섞여 있는지 파악하자
가장 단순한 분리부터 시작 — 게이트키퍼 하나만 떼어내도 전체 안정성이 눈에 띄게 올라간다
에이전트마다 JSON 출력 포맷 고정 — 파싱 에러가 가장 흔한 장애 원인
모델 비용 최적화는 나중에 — 구조가 잡히고 나서 모델을 내려가는 게 순서다

n8n 멀티 에이전트(Multi-Agent) 아키텍처 구축 가이드

🤖 n8n 멀티 에이전트란 정확히 무엇인가?

⚠️ 왜 단일 에이전트는 한계가 있을까?