n8n에서 프로덕션급 멀티 에이전트 워크플로우 구축하기: 50번의 배포를 통해 배운 점

대부분의 n8n AI 워크플로우 튜토리얼은 "테스트에서 작동했습니다" 단계에서 끝납니다. 데모와 실제 돈이 걸린 상황에서 하루 10,000개의 항목을 처리하는 프로덕션 시스템(Production system) 사이의 간극에는 흥미로운 문제들이 존재합니다.

Chronexa에서 우리는 핀테크 컴플라이언스 팀, 법률 문서 처리, AI SDR 엔진, 그리고 RAG 기반 연구 보조를 위해 50개 이상의 멀티 에이전트 (Multi-agent) 워크플로우를 구축했습니다. 이들을 신뢰할 수 있게 만드는 과정에서 우리가 배운 점은 다음과 같습니다.

1. 설계 실패를 최우선 고려 사항으로 다루기

대부분의 n8n 튜토리얼은 main[0]만 연결합니다. 하지만 프로덕션 워크플로우는 main[0] 그리고 main[1]을 모두 연결합니다.

n8n의 모든 HTTP Request 노드와 AI 노드는 두 개의 출력(Output)을 가집니다: 성공(main[0])과 에러(main[1]). 에러 브랜치(Error branch)를 연결하지 않은 채로 두는 것은 실패가 조용히 사라짐을 의미합니다. 즉, 고객이 사흘 뒤에 무언가 잘못되었다는 것을 알아차릴 때까지 문제를 알 수 없게 됩니다.

우리가 모든 배포에서 사용하는 패턴:

HTTP Request → main[0] → 워크플로우 계속 진행 → main[1] → DLQ 시트 + Slack 알림

모든 AI 및 HTTP 노드에 onError: 'continueErrorOutput'을 설정하십시오. main[1]을 다음 항목들에 연결하십시오:

실패한 항목, 타임스탬프(Timestamp), 에러 메시지가 포함된 데드 레터 큐 (Dead Letter Queue, DLQ) Google 시트 또는 Baserow 테이블
항목 ID와 DLQ 행으로 연결되는 링크가 포함된 운영 채널용 Slack 알림

노드 수준의 에러 라우팅(Error routing)을 대신하여 워크플로우 전체 수준의 글로벌 에러 트리거(Global error trigger)에 의존하지 마십시오. 글로벌 트리거는 워크플로우 전체가 충돌할 때 발생하지만, 여러분이 원하는 것은 전체 배치를 잃는 것이 아니라 항목별로 부분적인 실패를 포착하는 것입니다.

이것이 중요한 이유: 한 핀테크 고객의 AML(자금세탁방지) 모니터링 워크플로우에서, 우리는 첫 주에 조용히 누락되었을 847건의 데이터 보강(Enrichment) 호출 실패를 잡아냈습니다. DLQ 덕분에 모든 실패를 가시화하고 복구할 수 있었습니다.

2. HITL — AI 출력을 신뢰할 수 있게 만드는 패턴

중요도가 높은 맥락에서 완전히 자동화된 AI 워크플로우는 소리 없이 실패합니다. Claude는 때때로 잘못된 회사 이름, 부정확한 수치 또는 조작된 URL을 생성합니다. 인간의 체크포인트(checkpoint)가 없다면, 이러한 오류들은 고객에게 그대로 전달됩니다.

HITL (Human-in-the-Loop) 패턴:

\ AI 노드 → 검토 시트에 추가 (상태: "Pending") → Webhook 대기 → [사람이 검토 후 상태를 "Approved" 또는 "Rejected"로 설정] → Approved: 워크플로우 계속 진행 → Rejected: 수정 서브 워크플로우(sub-workflow)로 라우팅 \ `

n8n에서의 구현 방법:

AI 생성 후, 출력 내용을 "Status" 컬럼이 "Pending Review"로 설정된 Google Sheet 또는 Baserow 행에 기록합니다.
Webhook을 통해 재개되도록 구성된 Wait node를 사용합니다.
Status가 "Approved"로 변경될 때 실행되는 시트 트리거(sheet trigger) 또는 Webhook을 설정합니다.
24시간 타임아웃 체크를 추가합니다. 행이 너무 오래 "Pending" 상태로 머물러 있다면, 검토자에게 Slack 알림을 보냅니다.

HITL을 사용해야 하는 경우: AI 출력이 고객에게 노출되거나, 규제 관련이거나, 금융 관련인 모든 워크플로우. 오류의 위험도가 낮은 내부 데이터 변환 파이프라인(data transformation pipelines)에서는 생략해도 좋습니다.

저희의 AI SDR 엔진은 아웃바운드 이메일 검토를 위해 HITL을 사용합니다. SDR들은 이메일을 작성하는 데 6시간을 쓰는 대신, 하루 45분 동안 이메일을 승인하는 데 시간을 보냅니다. 워크플로우가 조사와 초안 작성을 수행하고, 사람은 최종 확인을 합니다. 그 결과 답장률(Reply rates)이 2.1%에서 6.8%로 상승했습니다.

3. 장기 실행 에이전트를 위한 메모리 관리 (Memory Management)

윈도우 버퍼 메모리 (Window Buffer Memory)

최신 정보가 중요한 대화형 에이전트(conversational agents)에 가장 적합합니다. 윈도우 크기를 10~20개의 메시지로 설정하세요. 20개를 초과하면 거의 도움이 되지 않는 컨텍스트(context)에 비용을 지불하게 됩니다.

정적 문서에 대한 RAG (RAG over Static Documents)

에이전트가 지식 베이스(계약서, 정책, 제품 문서)를 참조해야 할 때는, 매번 전체 문서를 컨텍스트에 주입하는 것보다 벡터 검색(vector retrieval)이 더 효율적입니다.

설정: Pinecone 또는 pgvector + n8n의 Embeddings 노드 + 정보 검색 체인(Information Retrieval chain). 규모가 커질 때의 비용 차이: 모든 쿼리에 50페이지 분량의 정책 문서를 전달하면 Claude Sonnet 가격 기준으로 쿼리당 약 $0.08가 소요됩니다. 관련 있는 3개의 청크(chunks)를 RAG로 검색하면 쿼리당 약 $0.004가 소요됩니다. 대량 처리 시 20배 더 저렴합니다.

멀티 사용자 배포를 위한 세션 키 (Session Keys)

이 부분은 사람들이 가장 자주 실수하는 지점입니다. 만약 기본 세션 ID (Session ID)를 사용하여 동일한 워크플로우가 여러 동시 사용자를 처리하게 되면, 사용자 A의 메모리가 사용자 B의 대화로 흘러 들어가는 현상이 발생합니다.

해결책 — 웹훅 페이로드 (Webhook payload)에서 사용자 식별자를 가져와 세션 ID의 범위를 지정하세요:

sessionId: {{ $('Webhook').item.json.userId }}

우리는 이러한 설정 오류로 인해 지원 봇이 한 사용자의 질문에 다른 사용자의 계정 정보로 답변하는 사례를 목격한 바 있습니다.

4. 속도 제한 (Rate Limiting), 백오프 (Backoff), 그리고 동시성 (Concurrency)

프로덕션 환경에서 여러분을 괴롭힐 세 가지 실패 모드입니다:

1. API 속도 제한 (OpenAI/Anthropic)

수백 개의 항목을 처리하는 대량 워크플로우(Bulk workflows)의 경우, 속도 제한(Rate limits)에 빠르게 도달합니다. n8n의 내장 기능인 **실패 시 재시도 (Retry on Fail)**를 사용하세요. 최대 재시도 횟수를 3회로 설정하고 지수 백오프 (Exponential backoff)를 적용하십시오. 지속적인 대량 처리를 위해서는 AI 호출 사이에 대기 (Wait) 노드를 추가하세요.

2. 웹훅 동시성 (Webhook Concurrency)

n8n의 기본 웹훅 동시성은 5개의 동시 실행입니다. 각 실행이 여러 번의 LLM 호출을 수행하는 AI 워크플로우의 경우, 5개의 동시 워크플로우는 순식간에 50개의 동시 API 호출로 급증할 수 있습니다.

해결책: AI 비중이 높은 워크플로우의 경우 웹훅 트리거에 maxConcurrency: 2를 설정하세요. 이렇게 하면 요청을 드롭(Drop)하는 대신 큐(Queue)를 생성합니다.

3. 다운스트림 API 타임아웃 (Downstream API Timeouts)

HTTP Request 노드는 기본적으로 30초의 타임아웃을 가집니다. 워크플로우가 느린 외부 API를 호출하는 경우, 유령 실패(Phantom failures) 현상이 나타날 수 있습니다. 느린 API 노드에는 명시적으로 "timeout": 60000을 설정하고, 타임아웃이 DLQ(Dead Letter Queue)로 가도록 에러 출력을 연결하세요.

5. 우리가 매 배포 전 사용하는 프로덕션 체크리스트

결론

n8n 데모와 프로덕션 시스템의 차이는 제대로 작동하지 않는 10%의 케이스를 어떻게 처리하느냐에 전적으로 달려 있습니다. 실패 처리를 최우선적인 아키텍처 설계 고려 사항으로 다루고, 신뢰를 위해 HITL을 추가하며, 메모리와 동시성 (Concurrency)을 신중하게 관리하는 것이 신뢰할 수 있는 자동화와 잠재적 위험 요소(Liability)를 가르는 기준입니다.

실제 비즈니스 사례를 위한 멀티 에이전트 워크플로우를 구축하고 있다면, 에러 출력부터 시작하세요. 그 외의 모든 것은 거기서부터 따라옵니다.

Ankit Dhiman은 중견 B2B 기업을 위해 맞춤형 n8n 워크플로우를 구축하는 AI 자동화 에이전시인 Chronexa의 설립자입니다. 저희는 워크플로우 템플릿을 github.com/Chronexa/chronexa-n8n-workflows에 오픈 소스로 공개했습니다.