저는 계속해서 똑같은 아키텍처 실수를 목격하고 있습니다:

한 팀이 보조자 한 명을 고용합니다.

그러고 나서 리서처 에이전트(researcher agent), 코더 에이전트(coder agent), 검증 에이전트(verifier agent), 비평가 에이전트(critic agent), 어쩌면 플래너 에이전트(planner agent)까지 추가합니다. 그러면 갑자기 GPT, Claude, Gemini, Codex, 그리고 로컬 Ollama 모델들이 고장 난 계주 경기처럼 긴 프롬프트(prompt)를 서로 주고받게 됩니다.

다이어그램으로 볼 때는 똑똑해 보입니다.

하지만 실제 운영 환경(production)에서는 대개 지연 시간(latency), 재시도(retries), 이상한 상태 버그(state bugs), 그리고 "왜 비용이 이렇게 많이 나왔지?"라는 질문이 쏟아지는 상황으로 변합니다.

이제 저의 견해는 간단합니다:

AI 에이전트 위임(AI agent delegation)을 하고 있다면, 채팅에서 토론하는 에이전트 의회가 아니라, 공유된 작업 큐(task queue), 하나의 오케스트레이터(orchestrator), 그리고 구조화된 출력(structured outputs)으로 시작하세요.

이 패턴은 디버깅이 더 쉽고, n8n/OpenClaw/커스텀 워커(custom workers)에 깔끔하게 매핑되며, 모든 하위 작업이 모델과 제공자(provider)를 건너뛸 때 발생하는 많은 비용과 컨텍스트 소모(context churn)를 방지할 수 있습니다.

계속해서 승리하는 아키텍처

실제 에이전트 시스템을 더 많이 살펴볼수록, 저는 '에이전트 연극(agent theater)'을 덜 믿게 됩니다.

만약 당신의 워크플로우가 주로 다음과 같다면:

• 무언가를 읽기
• 필드 추출하기
• 분류하기
• 응답 초안 작성하기
• 주장 검증하기
• 게시하거나 전달하기

...당신은 아마 서로 대화하는 다섯 명의 에이전트가 필요하지 않을 것입니다.

당신에게 필요한 것은 다음과 같습니다:

1. 하나의 오케스트레이터(orchestrator)
2. 내구성이 있는 큐(durable queue)
3. 좁은 책임 범위를 가진 워커(workers)
4. 타입이 지정된 출력(typed outputs)
5. 재시도(retries) 및 멱등성(idempotency)

이것이 바로 패턴입니다.

화려하지는 않지만, 매우 효과적입니다.

AI 에이전트 위임(AI agent delegation)이란 무엇인가

제가 "AI 에이전트 위임"이라고 말할 때, 각 에이전트에게 성격을 부여하고 자유롭게 행동하게 만드는 것을 의미하는 것이 아닙니다.

제가 의미하는 것은 이것입니다:

• 오케스트레이터가 다음 작업을 결정합니다.
• 작업이 큐(queue)에 들어갑니다.
• 워커가 작업을 가져갑니다.
• 워커가 구조화된 결과(structured result)를 반환합니다.
• 오케스트레이터가 다음에 일어날 일을 결정합니다.

이 과정에는 여전히 여러 모델이 포함될 수 있습니다.

하지만 조정(coordination)은 하나의 거대한 멀티 에이전트 채팅 트랜스크립트(chat transcript)를 통해서가 아니라, **아티팩트(artifacts)와 작업(jobs)**을 통해 이루어집니다.

큐 기반 오케스트레이션이 에이전트 채팅보다 나은 이유

가장 큰 장점은 제어(control)입니다.

큐(Queue)를 사용하면 모든 핸드오프(handoff)가 명시적입니다.

다음 사항들을 알 수 있습니다:

• 어떤 작업(task)이 생성되었는지
• 어떤 워커(worker)가 실행했는지
• 어떤 모델(model)이 처리했는지
• 어떤 스키마(schema)가 반환되었는지
• 실패했는지 여부
• 재시도(retry)를 했는지 여부
• 다음 전환(transition)이 무엇이었는지

덕분에 디버깅(debugging)이 합리적인 수준에서 가능해집니다.

채팅 기반의 멀티 에이전트(multi-agent) 설정에서는 상태(state)가 메시지 전반에 걸쳐 흐릿하게 퍼집니다. 잘못된 요약 하나나 형식이 잘못된 핸드오프 하나만 발생해도 전체 시스템이 순식간에 모호해집니다.

실용적인 작업 큐의 형태

다음과 같은 방식 대신:

• 플래너 에이전트(planner agent)가 리서처 에이전트(researcher agent)에게 요청
• 리서처 에이전트가 크리틱 에이전트(critic agent)에게 요청
• 크리틱 에이전트가 코더 에이전트(coder agent)에게 요청
• 베리파이어 에이전트(verifier agent)가 모두를 검토

이렇게 하세요:

{
  "task_id": "task_4821",
  "type": "extract_pricing",
...

그런 다음 워커들이 다음과 같은 작업들을 소비(consume)하게 하세요:

• research_company (기업 조사)
• extract_pricing (가격 추출)
• classify_lead (리드 분류)
• draft_email (이메일 초안 작성)
• verify_claims (주장 검증)
• generate_patch (패치 생성)
• publish_result (결과 게시)

각 워커는 한 가지 일만 수행합니다.

각 워커는 하나의 스키마를 반환합니다.

오케스트레이터(orchestrator)가 흐름(flow)을 소유합니다.

이는 n8n 큐 모드(queue mode)와 직접적으로 매핑됩니다

이것이 제가 이 패턴을 매우 좋아하는 이유 중 하나입니다. 이미 자동화 시스템이 확장(scale)되는 방식과 일치하기 때문입니다.

n8n에서 큐 모드는 기본적으로 다음과 같은 아키텍처를 가집니다:

• 메인 인스턴스(main instance)가 트리거(trigger)를 수신
• Redis가 대기 중인 실행(executions)을 저장
• 워커 인스턴스(worker instances)가 독립적으로 작업(job)을 가져옴

다음 설정으로 활성화할 수 있습니다:

EXECUTIONS_MODE=queue

이것은 단순한 n8n의 구현 세부 사항이 아닙니다.

AI 오케스트레이션(orchestration)을 위한 견고한 멘탈 모델(mental model)입니다.

이미 n8n, Make, Zapier, OpenClaw 또는 커스텀 Python 워커를 사용하여 자동화를 구축하고 있다면, 큐 기반의 위임(delegation) 방식이 자연스럽게 맞아떨어질 것입니다.

구조화된 출력(Structured outputs)은 가짜 멀티 에이전트의 복잡성을 많이 제거합니다

많은 "멀티 에이전트 추론(multi-agent reasoning)"은 사실 신뢰할 수 없는 포맷팅(formatting)을 보완하기 위한 것에 불과합니다.

한 모델은 지저분한 텍스트를 반환하고,
다른 모델은 그것을 JSON으로 변환하며,
세 번째 모델은 그 JSON을 비판(critique)하고,
네 번째 모델은 필드(field)를 수정합니다.

그것은 종종 지능(intelligence)의 문제가 아닙니다.

그것은 스키마(schema)의 문제입니다.

만약 워커(worker)가 구조화된 출력(structured output)을 안정적으로 생성할 수 있다면, 놀라울 정도로 많은 양의 오케스트레이션(orchestration)을 삭제할 수 있습니다.

워커 계약(worker contract) 예시:

{
  "company_name": "Standard Compute",
  "pricing_model": "flat monthly",
...

출력이 타입화(typed)되면, 워커들은 서로 교체 가능한(interchangeable) 존재가 됩니다.

이것은 매우 중요한 문제입니다.

진정한 돌파구: 에이전트의 성격이 아닌 작업 유형(task type)에 따른 라우팅

이 지점에서 대부분의 팀이 상황을 지나치게 복잡하게 만듭니다.

모델 스위칭(Model switching)은 분명히 도움이 될 수 있습니다.

저는 서로 다른 모델을 사용하는 것에 반대하지 않습니다.

저는 모호한 이유로 서로 다른 모델을 사용하는 것에 반대합니다.

좋은 라우팅 로직은 다음과 같습니다:

나쁜 라우팅 로직은 다음과 같습니다:

• 모든 에이전트가 선호하는 모델이 따로 있음
• 동일한 8k-토큰 컨텍스트가 세 개의 제공업체(provider)로 중복 전송됨
• 깔끔한 아티팩트(artifact) 전달 없이 작업 도중에 모델이 바뀜
• 팀들이 "더 많은 관점"이 "더 나은 출력"을 의미한다고 가정함

대개 이는 더 많은 지연 시간(latency)을 의미합니다.

그리고 더 많은 비용을 의미합니다.

최소한의 오케스트레이터/워커 설계

복잡한 것을 건드리기 전에 제가 구축할 형태는 다음과 같습니다.

1. 오케스트레이터가 작업(task) 생성

from dataclasses import dataclass
from typing import Any

...

2. 워커가 큐(queue)에서 작업 소비

import json

def handle_task(task: Task) -> dict:
...

3. 수락하기 전에 출력 검증

from jsonschema import validate

PRICING_EXTRACTION_V1 = {
...

이것만으로도 향후 발생할 수 있는 수많은 혼란을 방지할 수 있습니다.

Ollama 덕분에 로컬 워커의 활용도가 훨씬 높아졌습니다

이 큐(queue) 패턴이 더 좋아진 이유 중 하나는, 로컬 모델이 구조화된 출력을 반환할 때 깔끔하게 참여할 수 있기 때문입니다.

즉, 로컬 추출(extraction) 워커와 클라우드 합성(synthesis) 워커가 동일한 계약(contract)을 공유할 수 있다는 뜻입니다.

Ollama를 사용한 예시:

curl -X POST http://localhost:11434/api/chat \
  -H "Content-Type: application/json" \
  -d '{
...

이것이 유용한 이유는 이제 다음과 같은 작업이 가능하기 때문입니다:

• 추출/분류를 위한 로컬 모델 (local model)
• 합성을 위한 더 강력한 호스팅 모델 (hosted model)
• 하나의 큐 (one queue)
• 하나의 스키마 계약 (one schema contract)
• 하나의 오케스트레이터 (one orchestrator)

에이전트 역할극 (agent roleplay)이 필요하지 않습니다.

모델 전환의 숨겨진 문제: 캐시 및 지연 시간 소모 (cache and latency churn)

이 부분은 사람들이 아키텍처 다이어그램에서 그냥 지나치는 부분입니다.

작업을 모델 간에 주고받을 때마다 다음과 같은 비용을 지불할 위험이 있습니다:

• 반복적인 컨텍스트 패킹 (context packing)
• 제공업체 왕복 지연 시간 (provider round-trip latency)
• 차가운 프롬프트 상태 (cold-ish prompt state)
• 중복된 롱 컨텍스트 처리 (long-context processing)
• 약해진 캐시 지역성 (cache locality)

만약 전달되는 결과물(handoff artifact)이 작고 잘 정의되어 있다면, 그 트레이드오프(trade)는 가치가 있을 수 있습니다.

하지만 거대한 전사 데이터(transcripts)를 주고받는 상황이라면, 대개 그렇지 않습니다.

이것이 바로 제가 채팅 기반의 협의체(chat-based councils) 대신 큐 기반의 위임(queue-based delegation)을 선호하는 정확한 이유입니다.

큐는 당신이 **작은 핸드오프 (small handoffs)**를 지향하도록 유도합니다.

그것이 좋은 시스템 설계입니다.

OpenClaw는 강력하지만, 과잉 구축의 유혹에 빠지게 할 수 있습니다

제가 많은 개발자와 마찬가지로 OpenClaw를 좋아하는 이유는 다음과 같습니다:

• 로컬 우선 제어 (local-first control)
• 모델 불가지론적 라우팅 (model-agnostic routing)
• 장애 조치 (failover) 옵션
• 사용 가능한 제공업체 및 워커(worker)에 대한 가시성

하지만 OpenClaw와 같은 도구들은 단지 할 수 있다는 이유만으로 6명의 에이전트가 출연하는 배역을 만들도록 쉽게 유혹합니다.

다음과 같은 명령어를 실행하면:

openclaw status --all

...갑자기 워크플로우(workflow)를 설계하는 대신 영화적 세계관(cinematic universe)을 설계하고 있는 자신을 발견하게 됩니다.

제 의견은 이렇습니다: OpenClaw를 자율적인 혼돈을 위한 변명이 아니라, **제어 평면 (control plane)**으로 사용하십시오.

OpenClaw는 다음과 같은 작업을 도와야 합니다:

• 워커 할당 (worker assignment)
• 라우팅 (routing)
• 장애 조치 (failover)
• 진단 (diagnostics)
• 모델 가용성 (model availability)

봇들 사이의 불필요한 대화를 만들어내는 용도가 아닙니다.

제가 계속 보고 있는 3가지 패턴, 순위별 정리

주관적인 버전입니다.

만약 단일 어시스턴트에서 다수의 어시스턴트로 넘어가고 있다면, 중간 행이 보통 올바른 선택입니다.

멀티 에이전트 팀이 실제로 의미 있는 경우

더 자율적인 에이전트 동작이 정당화되는 실제 사례들이 있습니다.

예시:

• 장기 실행되는 장애 대응 (long-running incident response)
• 익숙하지 않은 코드베이스를 탐색하는 소프트웨어 에이전트 (software agents)
• 모순된 증거를 다루는 적응형 연구 시스템 (adaptive research systems)
• 실행 도중 목표가 변경되어 모델의 재계획 (re-plan)이 필요한 환경

이것들은 실제 사용 사례(use cases)입니다.

하지만 그런 경우에도 저는 여전히 다음을 원합니다:

• 명시적인 산출물 (explicit artifacts)
• 작업 경계 (task boundaries)
• 채팅 로그 외부의 저장된 상태 (stored state)
• 중요한 출력을 위한 스키마 (schemas)
• 관찰 가능한 전환 (observable transitions)

따라서 자율성 (autonomy)은 유용할 수 있습니다.

하지만 명시적인 오케스트레이션 (explicit orchestration)이 여전히 승리합니다.

내가 내일 구축할 설정

만약 내가 내일 n8n, OpenClaw, 또는 커스텀 Python 스택으로 이것을 구축해야 한다면, 다음과 같이 할 것입니다:

1. 하나의 플래너 (planner) 유지

작업 분해 (task decomposition)가 실제로 필요할 때만 GPT 또는 Claude를 사용합니다.

2. 모든 작업을 내구성이 있는 큐 (durable queue)에 넣기

많은 시스템에서 Redis만으로도 충분합니다.

3. 모든 워커 (worker)가 타입이 지정된 출력 (typed output)을 반환하도록 강제하기

다음 단계가 정확한 필드에 의존한다면, 자유 형식의 핸드오프 (freeform handoffs)는 허용하지 않습니다.

4. 작업 유형별 라우팅 (Route by task type)

• code_patch -> Codex
• search_research -> Gemini
• classification -> Ollama
• final_synthesis -> GPT 또는 Claude

5. 모델 외부에서 상태 유지

요약, 산출물, 재시도, 승인 및 실행 이력을 앱 내에 저장하세요.
거대한 공유 대화 속에 두지 마세요.

대규모로 AI 비용을 지불할 때 이것이 훨씬 더 중요한 이유

에이전트 워크플로우 (agent workflows)가 24시간 7일 내내 실행되기 시작하면, 아키텍처 설계의 실수는 더 이상 귀여운 수준에 머물지 않습니다.

추가되는 모든 모델 홉 (model hop), 반복되는 모든 롱 컨텍스트 (long-context) 호출, 불필요한 모든 검증 에이전트 (verifier agent)는 운영상의 저항 (operational drag)으로 변합니다.

이것이 자동화와 에이전트를 구축하는 팀에게 예측 가능한 가격 책정 (predictable pricing)이 매우 중요한 이유이기도 합니다.

만약 n8n, Make, Zapier, OpenClaw 또는 커스텀 파이프라인에서 큐 기반의 AI 워커를 실행하고 있다면, 토큰당 과금 방식은 이상한 유인책을 만듭니다. 즉, 시스템의 명확성 대신 비용에 대한 두려움을 중심으로 설계를 시작하게 됩니다.

그것은 나쁜 거래입니다.

많은 팀은 하루 종일 토큰 미터기를 감시하는 대신, 워커(Worker) 설계, 라우팅(Routing), 그리고 신뢰성(Reliability)에 집중할 수 있도록 하나의 OpenAI 호환 엔드포인트(Endpoint)와 고정된 월간 가격 체계를 선호할 것입니다.

그것이 Standard Compute의 매력입니다. 예측 가능한 월간 가격으로 무제한 AI 컴퓨팅(Compute)을 제공하며, OpenAI 호환 API를 사용하여 토큰에 대한 불안감 없이 에이전트 워커(Agent workers)와 자동화(Automations)를 구축할 수 있습니다.

이 모델은 큐(Queue) 기반의 오케스트레이션(Orchestration)에 특히 잘 맞습니다.

왜냐하면 아키텍처(Architecture)가 깔끔해지고 나면, 그다음 병목 현상(Bottleneck)은 보통 예측 불가능한 비용이기 때문입니다.

최종 결론 (Final take)

만약 당신이 현재 생각하는 AI 에이전트 위임(Delegation)의 개념이 "수많은 에이전트가 서로 대화하는 것"이라면, 잘못된 지점에서 시작하고 있다고 생각합니다.

다음부터 시작하세요:

• 하나의 오케스트레이터 (Orchestrator)
• 하나의 큐 (Queue)
• 특화된 워커 (Specialized workers)
• 구조화된 출력 (Structured outputs)
• 명시적 라우팅 (Explicit routing)

그다음, 자율성(Autonomy)이 확실한 이득을 가져다주는 곳에만 추가하세요.

의회(Council)가 아니라,

큐(Queue)입니다.

지루한 아키텍처가 사람들이 인정하고 싶어 하는 것보다 훨씬 더 자주 승리합니다.