멀티 에이전트 오케스트레이션 설계하기

만능 직원 하나보다 작은 팀이 낫다

1인 회사에서 AI 에이전트를 처음 만들면 대개 같은 길을 걷는다. 처음에는 이메일 요약만 시킨다. 잘 된다. 그다음 고객 문의 분류를 붙인다. 이것도 된다. 여기에 콘텐츠 초안 작성, 경쟁사 조사, 데이터베이스 조회, 슬랙 알림, 결제 확인, 환불 정책 설명까지 얹는다. 어느 순간 에이전트는 아주 똑똑해 보이지만 믿기 어려운 직원이 된다.

문제는 모델의 지능이 부족해서만은 아니다. 구조가 잘못된 것이다. 사람 회사에서도 한 명에게 리서치, 영업, 회계, 고객지원, 편집, 법무 검토를 모두 맡기면 처음에는 비용이 아껴지는 것처럼 보인다. 하지만 일이 조금만 복잡해져도 병목이 생긴다. 무엇을 먼저 해야 하는지 헷갈리고, 실수가 나도 어느 단계에서 잘못됐는지 찾기 어렵다.

멀티 에이전트 오케스트레이션은 이 문제를 조직 설계의 관점으로 푸는 방식이다. 하나의 거대한 AI에게 모든 일을 맡기는 대신, 작은 역할을 가진 에이전트들이 명확한 순서와 인터페이스로 협업하게 만든다. n8n은 이 구조를 만들기에 좋은 무대다. AI Agent 노드, 조건 분기, 서브 워크플로우, 데이터베이스, HTTP Request, Code 노드, Slack이나 Gmail 같은 외부 서비스가 한 캔버스 안에서 연결되기 때문이다.

여기서 중요한 문장은 하나다. 좋은 AI 팀은 만능 에이전트 하나가 아니라, 작게 나뉜 역할들이 명확한 인터페이스로 협업하는 구조다.

n8n 공식 블로그에서도 멀티 에이전트 시스템을 여러 자율 에이전트가 공통 목표를 위해 상호작용하는 구조로 설명한다. 단일 에이전트는 하나의 모델과 하나의 시스템 프롬프트에 많은 역할을 담지만, 멀티 에이전트는 역할별 프롬프트, 도구, 모델, 메모리를 분리한다.¹

단일 에이전트가 무너지는 네 가지 이유

단일 에이전트는 나쁘지 않다. 오히려 대부분의 자동화는 단일 에이전트로 시작하는 편이 낫다. 일정한 입력을 요약하거나, 특정 형식으로 이메일 초안을 쓰거나, 간단한 고객 문의를 분류하는 일은 하나의 에이전트로 충분하다. 문제는 그 에이전트를 계속 키울 때 생긴다.

첫 번째 원인은 컨텍스트 과부하다. 에이전트에게 많은 규칙, 예외, 브랜드 가이드, 고객 정보, 과거 대화, 도구 설명을 한꺼번에 넣으면 입력창은 점점 무거워진다. 모델은 긴 컨텍스트를 읽을 수 있지만, 모든 내용을 같은 품질로 기억하고 적용하지는 못한다. 중요한 규칙이 뒤로 밀리고, 최근 대화가 과하게 반영되고, 앞에서 준 제약을 잊은 것처럼 행동한다.

두 번째 원인은 도구 목록의 과다다. 에이전트에게 Gmail, Notion, Slack, Airtable, Stripe, 결제 DB, 고객 DB, 웹 검색, 벡터 검색, 캘린더, 환불 API를 모두 쥐여 주면 선택지가 많아진다. 선택지가 많다는 것은 자유가 아니라 판단 비용이다. 실무 경험상 도구가 5개에서 7개를 넘어가면 잘못된 도구 선택, 느린 응답, 디버깅 난도가 크게 증가한다는 관찰이 많다.² 고객이 결제 영수증을 물었는데 정책 문서를 검색하거나, 단순 조회면 충분한데 수정 API를 호출하는 식의 사고가 여기서 나온다.

세 번째 원인은 루프와 지연이다. 만능 에이전트는 여러 목표를 동시에 해결하려고 한다. 검색하고, 다시 생각하고, 도구를 호출하고, 결과가 애매하면 또 검색한다. 사용자는 단순히 '이번 달 결제 내역 알려줘'라고 했는데, 내부에서는 추론과 도구 호출이 길게 이어진다. 응답 시간은 초 단위에서 분 단위로 늘어나고, 토큰 비용은 어디서 새는지 알기 어려워진다.

네 번째 원인은 검증 단계의 부재다. 단일 에이전트는 스스로 작성하고 스스로 확신한다. 리서치도 자신이 하고, 글도 자신이 쓰고, 검수도 자신이 한다. 사람이 보기에는 그럴듯하지만, 출처가 부정확하거나 브랜드 톤이 어긋나거나 고객에게 보내면 안 되는 약속을 포함할 수 있다. 작성자와 검수자가 같으면 놓치는 부분이 생긴다. AI도 마찬가지다.

멀티 에이전트는 이 문제를 역할 분리로 줄인다. 리서처는 근거를 모으고, 작가는 초안을 만들고, 편집자는 흐름과 톤을 다듬고, 검수자는 위험과 사실성을 확인한다. 각 에이전트가 보는 정보와 쓸 수 있는 도구를 제한하면 판단 범위가 좁아진다. 판단 범위가 좁아지면 품질이 올라가고, 실패 위치도 찾기 쉬워진다.

다만 대가는 있다. 멀티 에이전트는 공짜 성능 향상 장치가 아니다. Anthropic의 내부 실험을 인용한 n8n 글에서는 멀티 에이전트 시스템이 단일 에이전트보다 성능이 높게 나타난 사례가 있지만, 동시에 토큰 사용량이 크게 늘 수 있다고 설명한다. 해당 글은 90.2%의 성능 향상과 15배의 토큰 사용량 증가라는 수치를 함께 제시한다.¹ 숫자의 핵심은 단순하다. 더 잘하려면 더 많이 생각하고 더 많이 주고받는다.

그래서 우리는 멀티 에이전트를 '항상 좋은 구조'가 아니라 '복잡한 일을 안정적으로 처리하기 위한 투자'로 봐야 한다.

멀티 에이전트 도입 전 비용부터 계산하라

솔로프리너에게 자동화의 함정은 '멋있어서 만든다'이다. 멀티 에이전트는 특히 그렇다. 리서처, 작가, 편집자, 검수자라는 이름을 붙이면 마치 작은 출판사가 생긴 것 같다. 하지만 매번 네 번의 LLM 호출이 일어나고, 각 단계에서 검색과 도구 호출까지 붙으면 비용은 단일 에이전트보다 훨씬 빨리 오른다.

간단한 콘텐츠 파이프라인을 예로 들어보자. 단일 에이전트가 블로그 초안을 한 번에 만드는 데 입력 8,000토큰, 출력 2,000토큰을 쓴다고 하자. 총 10,000토큰이다. 멀티 에이전트 구조에서는 리서처가 8,000토큰, 작가가 10,000토큰, 편집자가 6,000토큰, 검수자가 5,000토큰을 쓸 수 있다. 여기에 각 단계의 요약, 브리프, 재시도까지 붙으면 한 편에 30,000토큰을 넘는 것은 어렵지 않다.

비용을 계산할 때는 다음 공식을 먼저 쓴다.

자동화 1회 비용 = 각 에이전트의 입력 토큰 비용 + 출력 토큰 비용 + 검색 API 비용 + 저장소 비용 + 재시도 비용

그리고 사업 관점의 계산을 덧붙인다.

자동화 가치 = 절약한 사람 시간 × 시간당 가치 + 품질 향상으로 늘어난 매출 가능성 - 자동화 운영 비용

예를 들어 매주 5개의 글을 만들고, 사람의 리서치와 초안 시간이 글당 2시간 줄어든다면 주 10시간을 절약한다. 당신의 시간당 가치가 5만 원이라면 주 50만 원, 월 200만 원의 여지가 생긴다. 이때 멀티 에이전트 비용이 월 10만 원이라면 충분히 좋은 투자일 수 있다. 반대로 한 달에 글 하나 만드는 사람에게 복잡한 멀티 에이전트 시스템은 과하다.

판단 기준은 명확하다. 업무가 여러 전문 영역을 포함하고, 단일 컨텍스트에 모든 정보를 담기 어렵고, 품질 검증이 중요하며, 반복 실행 빈도가 높을 때 멀티 에이전트가 의미 있다. 그 외에는 단일 에이전트나 단순 체인으로 시작하라.

네 가지 오케스트레이션 패턴

멀티 에이전트라고 해서 모두 같은 구조는 아니다. n8n에서 가장 자주 쓰는 패턴은 라우팅, 파이프라인, 병렬 실행, 감독자 구조다. 이 네 가지를 구분하면 설계가 훨씬 쉬워진다.

라우팅 패턴은 고객지원에 적합하다. 사용자의 메시지를 먼저 분류한다. 결제 문의면 결제 에이전트, 기술 문제면 기술지원 에이전트, 환불 요청이면 정책 에이전트로 보낸다. n8n에서는 AI 분류 노드나 Basic LLM Chain, Structured Output Parser, Switch 노드 조합으로 구현한다. 대량 요청을 처리할 때는 감독자 에이전트보다 비용이 낮고 흐름이 예측 가능하다.

파이프라인 패턴은 콘텐츠 제작에 적합하다. 리서처가 자료를 모으고, 작가가 초안을 쓰고, 편집자가 다듬고, 검수자가 승인 여부를 판단한다. 각 단계가 선형으로 이어지기 때문에 디버깅이 쉽고, 단계별 품질 기준을 넣기 좋다. 이 장의 실전 예제도 이 구조를 기본으로 한다.

병렬 실행은 여러 관점이 필요할 때 쓴다. 예를 들어 신제품 아이디어를 평가할 때 시장성 에이전트, 기술 난이도 에이전트, 고객 관점 에이전트를 동시에 실행할 수 있다. 마지막에는 Aggregator 또는 편집자 에이전트가 결과를 합친다. 속도는 빠르지만 모든 에이전트가 매번 실행되므로 비용은 높다.

감독자 구조는 가장 화려하지만 가장 위험하다. 중앙의 오케스트레이터 에이전트가 목표를 이해하고, 어떤 전문가에게 일을 맡길지 결정한다. n8n에서는 AI Agent Tool 노드를 이용해 다른 에이전트나 서브 워크플로우를 도구처럼 호출할 수 있다. 다만 감독자에게 너무 많은 권한을 주면 다시 만능 에이전트 문제가 생긴다. 감독자는 직접 일하는 사람이 아니라 일을 나누고 결과를 확인하는 관리자여야 한다.

콘텐츠 제작 에이전트 팀 설계하기

이제 실제로 1인 회사에서 바로 쓸 수 있는 콘텐츠 제작 팀을 설계해보자. 목표는 'AI가 글을 써준다'가 아니다. 목표는 재현 가능한 콘텐츠 생산 파이프라인이다. 같은 입력을 넣으면 비슷한 수준의 결과물이 나오고, 실패했을 때 어느 단계에서 고쳐야 하는지 보여야 한다.

예제 구조는 다음과 같다.

입력 → 리서처 → 작가 → 편집자 → 검수자 → 사람 승인 → 게시 또는 보류

각 에이전트는 이름보다 계약이 중요하다. 여기서 계약이란 입력값, 출력값, 성공 조건, 실패 시 처리를 말한다.

이 표가 없으면 멀티 에이전트는 '챗봇 여러 개'가 된다. 반대로 이 표가 있으면 업무 시스템이 된다.

리서처는 글을 쓰지 않는다. 리서처의 출력은 문학적 문장이 아니라 재료다. 좋은 리서처 출력은 다음처럼 생겼다.

• 핵심 주장: 1인 회사의 자동화는 비용 절감보다 병목 제거 효과가 크다.

• 근거: 반복 업무가 줄어들면 창업자는 제품, 판매, 고객 이해에 시간을 더 쓸 수 있다.

• 출처: 관련 보고서 URL 또는 내부 데이터 링크.

• 불확실한 점: 한국 시장의 구체 수치는 추가 확인 필요.

작가는 리서처의 재료를 받아 독자가 읽을 수 있는 흐름으로 바꾼다. 작가에게 웹 검색 도구를 주지 않는 것이 좋다. 작가가 검색까지 하면 리서처와 역할이 겹친다. 작가의 도구는 브랜드 가이드 조회, 이전 글 샘플 조회, 문서 저장 정도면 충분하다.

편집자는 초안을 새로 쓰는 사람이 아니다. 구조, 중복, 논리 점프, 톤을 고친다. 편집자는 '왜 고쳤는지'를 남겨야 한다. 이 수정 이유는 나중에 브랜드 스타일을 개선하는 데이터가 된다.

검수자는 가장 보수적으로 설계한다. 검수자는 외부 게시, 이메일 발송, 광고 집행 같은 행동을 하지 않는다. 오직 판단한다. 사실 오류 가능성, 과장 표현, 민감한 주장, 출처 부족, 브랜드 리스크를 점검하고 점수를 준다.

n8n에서 구현하는 기본 캔버스

이 파이프라인을 n8n에서 구현하면 다음과 같은 흐름이 된다.

1. Form Trigger 또는 Webhook Trigger가 콘텐츠 요청을 받는다.

2. Set 노드가 입력값을 표준 JSON으로 정리한다.

3. 리서처 서브 워크플로우를 호출한다.

4. IF 노드가 리서치 품질 점수를 확인한다.

5. 작가 AI Agent 노드가 초안을 생성한다.

6. 편집자 AI Agent 노드가 수정본과 피드백을 생성한다.

7. 검수자 AI Agent 노드가 승인 여부와 신뢰도 점수를 낸다.

8. 점수에 따라 게시, 재시도, 사람 승인, 중단으로 분기한다.

n8n의 장점은 여기서 드러난다. AI가 판단해야 하는 부분과 규칙으로 고정해야 하는 부분을 섞을 수 있다. 리서처가 어떤 키워드를 검색할지 정하는 것은 AI에게 맡길 수 있다. 하지만 신뢰도 점수가 0.8 미만이면 게시하지 않는 규칙은 IF 노드로 고정하는 편이 낫다. n8n은 AI Agent 노드와 사전 정의된 로직, HITL 승인, 에러 처리, 비용 추적을 함께 제공한다는 점을 강조한다.³

핵심은 '모든 결정을 AI에게 맡기지 않는 것'이다. AI는 애매한 입력을 해석하고 초안을 만들고 대안을 제시하는 데 강하다. 반면 승인 기준, 비용 한도, 게시 여부, 환불 실행 같은 결정은 워크플로우의 명시적 조건으로 관리하는 편이 안전하다.

예를 들어 검수자 출력은 반드시 구조화한다.

status: approved | needs_revision | human_review | rejected
confidence: 0.0부터 1.0
risk_level: low | medium | high
issues: 문제 목록
required_changes: 수정 지시
final_summary: 사람이 빠르게 읽을 요약

이 출력이 있어야 Switch 노드가 다음 경로를 결정할 수 있다. status가 approved이고 confidence가 0.85 이상이며 risk_level이 low이면 게시 대기열로 보낸다. needs_revision이면 편집자 또는 작가에게 되돌린다. human_review이면 Slack 승인 메시지를 보낸다. rejected이면 Notion이나 데이터베이스에 실패 사유를 저장하고 종료한다.

DEV Community에 소개된 n8n 멀티 에이전트 핸드오프 예제도 마스터 에이전트가 구조화된 JSON을 출력하고, Switch 노드가 agent_to_route_to 값에 따라 적절한 에이전트로 보내는 방식을 사용한다. 중요한 것은 마스터의 자연어 답변이 아니라, 다음 노드가 읽을 수 있는 구조화된 필드다.⁴

실행 순서를 오케스트레이션하는 방법

멀티 에이전트에서 오케스트레이션은 '누가 다음에 일할지 정하는 것'이다. n8n에서는 이 결정을 여러 방식으로 구현할 수 있다.

가장 단순한 방식은 조건 분기다. IF 노드나 Switch 노드가 특정 필드 값을 보고 다음 경로를 선택한다. 콘텐츠 검수 결과가 approved면 게시 예약으로, needs_revision이면 작가에게, human_review이면 승인 요청으로 보낸다. 이 방식은 예측 가능하고 비용이 낮다.

두 번째는 서브 워크플로우 호출이다. 리서처, 작가, 편집자, 검수자를 각각 별도 워크플로우로 만들고 Execute Workflow 노드로 호출한다. 이렇게 하면 각 에이전트를 독립적으로 테스트하고 수정할 수 있다. 리서처만 모델을 바꾸거나, 검수자만 프롬프트를 강화해도 전체 캔버스를 건드릴 필요가 없다.

세 번째는 이벤트 기반 트리거다. 어떤 에이전트가 결과를 데이터베이스에 저장하면, 다른 워크플로우가 그 상태 변화를 감지해 실행된다. 예를 들어 researcher_done 상태가 되면 writer_workflow가 실행되고, editor_done 상태가 되면 reviewer_workflow가 실행된다. 긴 작업이나 대량 작업에서는 이 방식이 유리하다. 하나의 실행 안에서 모든 것을 끝내려 하지 않아도 되기 때문이다.

네 번째는 AI Agent Tool 방식이다. 오케스트레이터 에이전트가 하위 에이전트를 도구처럼 호출한다. 예를 들어 감독자 에이전트가 '이 요청은 리서치와 편집이 모두 필요하다'고 판단하고 리서처 도구와 편집자 도구를 순서대로 부를 수 있다. 이 방식은 유연하지만, 감독자 판단이 틀리면 비용과 오류가 커진다.

외부 모델 연동도 자유롭게 섞을 수 있다. 분류는 저렴하고 빠른 모델을 쓰고, 최종 글 작성은 성능 좋은 모델을 쓰고, 긴 문서 검토는 컨텍스트가 넓은 모델을 쓰는 식이다. OpenAI, Claude, Gemini, LangChain 기반 노드, HTTP Request를 통한 외부 에이전트 API 호출을 조합하면 된다.

여기서 좋은 설계 원칙은 단순하다. 저위험·고빈도 판단에는 저렴한 모델과 규칙 기반 분기를 쓰고, 고가치·고난도 생성에는 좋은 모델을 쓴다. 모든 단계에 최고급 모델을 쓰는 것은 1인 회사의 자동화가 아니라 비용 폭주 실험이다.

핸드오프는 대화 기록 전달이 아니다

멀티 에이전트를 처음 만들 때 가장 흔한 실수는 앞 단계의 전체 대화 기록을 다음 에이전트에게 그대로 넘기는 것이다. 겉으로는 안전해 보인다. '혹시 모르니 다 넘기자'는 생각이다. 하지만 이것이 비용과 품질을 동시에 망친다.

전체 대화 기록에는 다음 에이전트에게 필요 없는 정보가 많다. 리서처가 검색 중에 버린 키워드, 작가가 고민한 문장, 편집자가 이미 해결한 중복, 이전 단계의 장황한 추론이 모두 들어간다. 다음 에이전트는 핵심을 찾기 위해 더 많은 토큰을 쓰고, 중요하지 않은 정보에 끌려갈 수 있다.

핸드오프는 '필요한 만큼만 넘기는 계약'이어야 한다. 목적에 따라 다음 다섯 가지 방식을 쓴다.

첫째, JSON 스키마를 사용한다. 라우팅, 승인, 점수, 상태처럼 다음 노드가 기계적으로 읽어야 하는 값은 JSON 또는 그에 준하는 구조화된 필드로 넘긴다. status, confidence, next_agent, reason 같은 필드가 대표적이다.

둘째, 요약된 작업 브리프를 사용한다. 작가에게는 리서처의 전체 검색 로그가 아니라 핵심 주장, 근거, 출처, 금지 사항, 대상 독자, 원하는 톤을 넘긴다. 편집자에게는 초안과 브랜드 가이드, 편집 기준을 넘긴다.

셋째, 데이터베이스 레코드를 사용한다. 긴 실행에서는 모든 정보를 프롬프트에 담지 말고 DB에 저장한 뒤 record_id만 넘긴다. 다음 에이전트는 필요한 필드만 조회한다. 이 방식은 실행 로그, 버전 관리, 재시도에도 유리하다.

넷째, 벡터 메모리 검색 결과를 사용한다. 브랜드 가이드나 과거 콘텐츠 전체를 매번 넣지 말고, 현재 주제와 관련 있는 몇 개의 조각만 검색해 넣는다. RAG 장에서 배운 방식이 여기서 다시 등장한다.

다섯째, 워크플로우 호출 파라미터를 사용한다. 서브 워크플로우를 호출할 때 입력 파라미터를 명확히 제한한다. 예를 들어 researcher_workflow에는 topic, audience, freshness_window, source_policy만 보낸다. writer_workflow에는 research_brief_id와 brand_guide_id만 보낸다.

컨텍스트 최적화의 목표는 단지 비용 절감이 아니다. 에이전트가 자기 일에 집중하게 만드는 것이다. 핸드오프가 깔끔하면 역할 경계가 선명해지고, 역할 경계가 선명하면 결과가 안정된다.

공유 메모리와 개별 메모리를 나누어라

멀티 에이전트에서 메모리는 회사의 문서함과 비슷하다. 모두가 알아야 할 공통 규칙도 있고, 특정 부서만 보면 되는 작업 기록도 있다. 이 둘을 섞으면 혼란이 생긴다.

공유 메모리에는 모든 에이전트가 알아야 하는 기준만 둔다. 프로젝트 목표, 브랜드 가이드, 금지 표현, 고객 세그먼트, 제품 설명, 가격 정책, 핵심 메시지 같은 것들이다. 공유 메모리는 적을수록 좋다. 회사의 헌법처럼 자주 바뀌지 않고, 모든 역할에 영향을 미치는 정보만 남긴다.

개별 메모리에는 각 역할의 작업 로그와 판단 근거를 저장한다. 리서처 메모리에는 검색한 키워드, 채택한 출처, 버린 출처, 불확실한 주장 목록을 남긴다. 작가 메모리에는 제목 후보, 구성 선택 이유, 초안 버전을 남긴다. 편집자 메모리에는 반복 수정 패턴과 톤 관련 피드백을 남긴다. 검수자 메모리에는 위험 판정, 승인 거절 사유, 사람이 최종 수정한 내용을 남긴다.

이렇게 나누면 에이전트는 필요한 정보만 참조한다. 리서처가 편집자의 문장 취향까지 알 필요는 없다. 편집자가 결제 DB 접근 기록을 볼 필요도 없다. 최소 권한 원칙은 보안에만 적용되는 것이 아니라 컨텍스트 설계에도 적용된다.

메모리는 쌓는 것보다 정리하는 것이 더 중요하다. 오래된 정보, 충돌 정보, 중복 정보는 AI 팀을 서서히 망친다. 예전 가격 정책과 새 가격 정책이 함께 있으면 에이전트는 어느 쪽을 따라야 할지 헷갈린다. 같은 브랜드 가이드가 여러 버전으로 저장되어 있으면 글마다 톤이 달라진다.

실무에서는 다음 규칙을 둔다.

• 모든 공유 메모리에는 owner, updated_at, valid_until 필드를 둔다.

• 충돌하는 정보가 발견되면 최신 정보 하나만 active 상태로 둔다.

• 에이전트가 자주 참조하는 문서는 월 1회 요약본을 갱신한다.

• 검수자나 사람이 틀렸다고 표시한 정보는 deprecated 상태로 바꾼다.

• 최종 승인된 결과물만 장기 메모리에 반영한다.

n8n에서는 Postgres, Supabase, Airtable, Notion, Redis, 벡터 DB 등을 메모리 저장소로 쓸 수 있다. 중요한 것은 도구가 아니라 규칙이다. 아무 규칙 없이 쌓인 메모리는 지식이 아니라 잡음이다.

재시도 루프는 짧고 명확해야 한다

멀티 에이전트의 매력 중 하나는 반복 개선이다. 작가가 쓰고, 편집자가 고치고, 다시 작가가 반영하고, 편집자가 통과시킨다. n8n의 재귀형 writing-editing 템플릿도 작성 에이전트와 편집 에이전트가 상태값을 주고받으며 incomplete이면 다시 작성하고 complete이면 종료하는 구조를 보여준다.⁵

하지만 루프는 위험하다. 종료 조건이 약하면 비용이 무한히 늘어난다. 편집자가 매번 새로운 지적을 만들고, 작가가 매번 조금씩 바꾸고, 다시 편집자가 또 지적한다. 결과물은 좋아지는 듯하지만 실제로는 제자리에서 맴돈다.

그래서 재시도 루프에는 세 가지 제한이 필요하다. 최대 반복 횟수, 변경 기준, 중단 조건이다.

최대 반복 횟수는 보통 2회에서 3회면 충분하다. 3번 고쳐도 통과하지 못하는 콘텐츠는 AI끼리 더 돌린다고 좋아지기보다 사람의 판단이 필요한 경우가 많다.

변경 기준은 구체적이어야 한다. '더 좋게 고쳐라'가 아니라 '도입부를 대상 독자의 문제 상황으로 시작하라', '출처 없는 수치를 제거하라', '문단당 하나의 주장만 남겨라'처럼 수정 가능한 지시여야 한다.

중단 조건은 비용과 리스크를 막는다. confidence가 계속 낮거나, risk_level이 high이거나, required_changes가 비어 있는데도 incomplete가 반복되면 루프를 멈추고 human_review로 보낸다.

n8n에서는 반복 횟수를 item에 retry_count로 저장하고, IF 노드에서 3 이상이면 사람 승인으로 넘긴다. 단순하지만 이 장치 하나가 비용 폭주를 막는다.

Human-in-the-loop는 브레이크가 아니라 핸들이다

AI 자동화에서 사람 승인 단계를 넣으면 속도가 느려진다고 생각하기 쉽다. 반은 맞고 반은 틀리다. 모든 단계에 사람을 끼우면 자동화의 의미가 줄어든다. 하지만 되돌리기 어려운 지점에 사람을 배치하면 오히려 더 빠르게 움직일 수 있다. 시스템이 어디까지 자동으로 가도 안전한지 알기 때문이다.

사람 승인이 필요한 대표 지점은 외부 발송, 결제와 환불, 고객 응대, 브랜드 리스크가 있는 콘텐츠 게시다. 이 네 가지는 되돌리기 어렵거나 신뢰를 손상시킬 수 있다. AI가 초안, 추천, 근거, 위험 요약까지 준비하게 하고, 마지막 실행 버튼은 사람이 누르게 한다.

예를 들어 콘텐츠 파이프라인의 마지막 단계는 이렇게 설계한다.

검수자 에이전트가 최종 글, 요약, 주요 주장, 출처, 위험 점수, 게시 추천 여부를 만든다. n8n은 Slack으로 승인 메시지를 보낸다. 메시지에는 '승인', '수정 요청', '거절' 버튼을 둔다. 승인 버튼을 누르면 게시 예약 워크플로우가 실행된다. 수정 요청을 누르면 사람이 남긴 코멘트가 편집자에게 돌아간다. 거절을 누르면 해당 주제와 실패 사유가 DB에 저장된다.

고객지원도 마찬가지다. AI가 고객 문의를 분류하고 답변 초안을 만들 수는 있다. 하지만 환불 확정, 계약 조건 변경, 법적 책임이 걸린 답변은 사람 승인을 거친다. 승인 전 AI의 역할은 실행자가 아니라 준비자다.

이렇게 설계하면 자동화의 속도와 사업 통제력을 동시에 얻는다. AI는 밤새 초안을 만들고, 자료를 정리하고, 위험을 표시한다. 사람은 아침에 중요한 결정만 내린다. 이것이 1인 회사가 AI 팀을 쓰는 현실적인 방식이다.

1인 회사용 멀티 에이전트 설계 캔버스

복잡한 워크플로우를 만들기 전에 한 페이지로 먼저 설계하자. 아래 질문에 답하지 못하면 아직 n8n 캔버스를 열 때가 아니다.

이 캔버스는 귀찮아 보이지만, 나중의 디버깅 시간을 크게 줄인다. 멀티 에이전트의 실패는 대부분 모델 문제가 아니라 설계 누락에서 나온다. 누가 무엇을 책임지는지, 무엇을 넘겨야 하는지, 언제 멈춰야 하는지 정하지 않았기 때문에 무너진다.

작은 팀으로 시작하라

처음부터 8명의 에이전트를 만들 필요는 없다. 1인 회사에 가장 실용적인 시작점은 3명이다. 리서처, 작가, 검수자. 편집자는 처음에는 작가 프롬프트 안에 넣어도 된다. 운영하면서 초안 품질보다 톤과 구조 문제가 자주 발생하면 그때 편집자를 분리한다.

고객지원이라면 라우터, 정책 에이전트, 답변 검수자부터 시작한다. 제품 운영이라면 이벤트 분류자, 조치 추천자, 사람 승인 단계를 먼저 만든다. 인프라 모니터링이라면 로그 요약자, 원인 추정자, 알림 작성자를 분리할 수 있다.

중요한 것은 에이전트 수가 아니라 경계의 선명함이다. 에이전트가 많아도 역할이 겹치면 혼란스럽다. 에이전트가 적어도 입력과 출력이 분명하면 안정적이다.

멀티 에이전트 오케스트레이션의 최종 목표는 AI에게 회사를 통째로 맡기는 것이 아니다. 회사의 반복 가능한 판단과 실행을 작은 역할로 나누고, 그 사이를 n8n으로 연결하는 것이다. AI는 팀원이 되고, n8n은 운영 체계가 된다. 사람인 당신은 모든 일을 직접 처리하는 작업자가 아니라, 시스템을 설계하고 승인하고 개선하는 운영자가 된다.

그때부터 1인 회사는 더 이상 한 사람의 체력에만 의존하지 않는다. 작은 AI 팀이 각자의 자리에서 일하고, 당신은 가장 중요한 결정에 집중한다. 이것이 솔로프리너에게 멀티 에이전트가 주는 진짜 레버리지다.

참고

¹Multi-agent systems: Frameworks & step-by-step tutorial

²n8n Multi-Agent Orchestration: Coordinate AI Agent Teams That Actually Work

³n8n AI agent builder

⁴Optimizing Multi-Agent Workflows in n8n: A Context-Aware Approach to Agent Handoffs

⁵Generate written content with GPT Recursive Writing & Editing agents