하나의 루프(loop)로 충분할 때 - 그리고 팀이 필요할 때

이전 포스트는 루프(loop): 추론(reason), 행동(act), 관찰(observe), 반복(repeat)으로 끝났습니다. 단일 에이전트 (single agent) 내부에서 실행되는 이 루프는 놀라울 정도로 다양한 작업을 처리할 수 있습니다. 하지만 에이전트를 구축하는 데 충분한 시간을 쓰다 보면 벽에 부딪히게 됩니다. 작업이 하나의 컨텍스트 윈도우 (context window)에 담기에는 너무 길거나, 두 개의 하위 작업 (subtasks)이 동시에 실행되어야 하거나, 문제의 한 부분이 다른 곳에서는 노이즈가 될 수 있는 전문가를 필요로 하는 경우입니다. 이러한 벽에 부딪혔을 때, 당신에게는 선택권이 있습니다. 단일 에이전트를 더 강하게 밀어붙일 것인지, 아니면 작업을 여러 에이전트 (agents)로 나눌 것인지 말입니다. 무엇을 선택해야 하는지, 그리고 그 이유는 무엇인지 아는 것이 이 포스트의 주제입니다.

단일 에이전트 (single agent)란 실제로 무엇인가

비교하기 전에 정확히 짚고 넘어갈 가치가 있습니다. 단일 에이전트 (single agent)는 하나의 모델 (model), 하나의 컨텍스트 윈도우 (context window), 그리고 하나의 도구 세트 (tool set)를 가지고 하나의 루프 (loop)를 실행하는 것입니다. 해당 작업에 대해 학습한 모든 것은 사고(thoughts), 행동(actions), 관찰(observations)이 쌓여가는 히스토리에 존재합니다. 에이전트의 메모리 (memory)는 곧 컨텍스트 (context)입니다.

이러한 제약은 단순함의 원천인 동시에 한계의 원천이기도 합니다.

단일 에이전트가 뛰어난 경우:

• 하나의 컨텍스트 윈도우 (context window)에 여유롭게 들어가는 작업
• 각 단계가 이전 단계에 의존하는 선형적 워크플로우 (linear workflows)
• 속도보다 공유된 멘탈 모델 (mental model)을 유지하는 것이 더 중요한 문제
• 프로토타이핑 (Prototyping) - 하나의 루프 (loop)는 추적하고 디버깅하기가 매우 쉽습니다.

단일 에이전트가 한계에 부딪히는 경우:

• 실행 도중 컨텍스트 제한 (context limit)을 초과하는 긴 작업
• 병렬화 (parallelised)가 가능한 독립적인 하위 작업 (subtasks)이 있는 작업
• 단계마다 서로 다른 역량이 필요한 워크플로우 (workflows)
• 단일 에이전트의 조용한 실패가 전체 작업을 망치는 모든 상황

멀티 에이전트 시스템 (multi-agent system)이 추가하는 것

멀티 에이전트 시스템 (multi-agent system)은 두 개 이상의 에이전트 (agents)가 작업을 완료하기 위해 협력하는 것입니다. 협력 (Coordination)은 여러 가지를 의미할 수 있습니다. 한 에이전트가 다른 에이전트를 생성하거나, 에이전트들이 병렬로 실행되어 결과를 보고하거나, 각 에이전트의 출력이 다음 에이전트의 입력이 되는 파이프라인 (pipeline) 형태를 띨 수 있습니다. 공통점은 어떤 단일 에이전트도 전체 작업을 독점하지 않는다는 것입니다.

이를 통해 세 가지가 가능해집니다:

병렬성 (Parallelism). 만약 다섯 개의 회사를 동시에 조사해야 한다면, 단일 에이전트 (Single-agent)는 이를 순차적으로 수행합니다. 반면 멀티 에이전트 시스템 (Multi-agent system)은 다섯 개의 하위 에이전트 (Subagents)를 생성하여 다섯 가지 결과를 한 번에 얻습니다. 검색, API 호출, 또는 파일 읽기와 같이 I/O 바운드 (I/O-bound)인 작업의 경우, 이것이 가장 주요한 이점입니다.

전문화 (Specialisation). Python 작성을 위해 프롬프트가 작성되고 도구가 갖춰진 코딩 에이전트는 범용 에이전트 (Generalist agent)보다 Python을 더 잘 작성합니다. 멀티 에이전트 시스템을 사용하면 하위 작업 (Subtasks)을 그에 맞게 구축된 에이전트들 — 플래너 (Planner), 리서처 (Researcher), 코더 (Coder), 크리틱 (Critic) — 에게 라우팅 (Routing)할 수 있으며, 각 에이전트는 적절한 시스템 프롬프트 (System prompt)와 적절한 도구 (Tools)를 가집니다.

컨텍스트 관리 (Context management). 각 하위 에이전트는 새롭고 집중된 컨텍스트 (Context)를 할당받습니다. 하나의 에이전트가 초기 단계에서 발생한 50,000 토큰의 노이즈 (Noise)를 축적하는 대신, 하위 에이전트는 자신의 업무를 수행하는 데 필요한 정보만을 전달받습니다. 오케스트레이터 (Orchestrator)는 요약 및 라우팅을 수행하고, 워커 (Workers)는 예리한 상태를 유지합니다.

오케스트레이터-워커 패턴 (The orchestrator–worker pattern)

가장 일반적인 멀티 에이전트 아키텍처 (Architecture)는 하나의 **오케스트레이터 (Orchestrator)**와 하나 이상의 **워커 (Workers)**로 구성된 2단계 계층 구조입니다.

오케스트레이터는 목표를 수신하고, 계획을 세우며, 하위 작업을 위임합니다. 오케스트레이터는 직접 작업을 수행하지 않습니다. 대신 작업이 무엇인지, 그리고 누가 수행할지를 결정합니다. 워커는 범위가 지정된 작업 (Scoped task)을 전달받아 자체적인 루프 (Loop)를 실행하고 결과를 반환합니다. 워커들은 서로의 존재나 전체적인 목표에 대해서는 알지 못합니다.

def orchestrator(goal, worker_agents):
    plan = llm(f"Break this goal into subtasks: {goal}")
    # plan = [{"task": "...", "agent": "researcher"}, ...]
...

각 worker.run()은 이전 포스트에서 다룬 것과 동일한 에이전트 루프 — 추론 (Reason), 행동 (Act), 관찰 (Observe), 반복 (Repeat) — 이지만, 단일 하위 작업에 범위가 제한되어 있습니다. 오케스트레이터는 스스로 도구를 사용하지 않으며, 계획을 읽고 라우팅만 합니다. 워커는 전체 그림을 보지 못하며, 단지 자신의 조각을 해결할 뿐입니다.

이러한 분리는 매우 중요합니다. 이를 통해 오케스트레이터의 컨텍스트를 가볍게 유지할 수 있고 (도구 노이즈가 아닌 계획과 결과 중심), 워커의 컨텍스트를 집중된 상태로 유지할 수 있습니다 (하나의 작업, 적절한 도구, 그 외 불필요한 정보 없음).

하위 에이전트를 통한 병렬화 (Parallelising with subagents)

하위 작업(subtasks)이 독립적인 경우, 워커(workers)를 동시에 실행하십시오. Python에서는 asyncio 또는 ThreadPoolExecutor가 일반적인 선택지입니다:

from concurrent.futures import ThreadPoolExecutor

def run_parallel(tasks, worker):
...

주의해야 할 두 가지 사항이 있습니다. 첫째, **속도 제한 (rate limits)**입니다. 다섯 명의 에이전트가 동시에 동일한 API에 접속하면, 한 명의 에이전트가 순차적으로 수행할 때보다 할당량(quotas)을 더 빠르게 소진하게 됩니다. 오케스트레이터(orchestrator) 수준뿐만 아니라 워커(worker) 수준에서도 백오프(back-off) 로직을 구축하십시오. 둘째, **결과 병합 (result merging)**입니다. 병렬로 처리된 결과는 순서가 뒤섞여 도착하며 충돌이 발생할 수 있습니다. 오케스트레이터의 합성(synthesis) 단계는 결과가 깨끗하고 균일할 것이라고 가정하지 말고, 공백과 모순을 처리할 수 있어야 합니다.

멀티 에이전트가 정답이 아닌 경우

멀티 에이전트 시스템(Multi-agent systems)에는 실제 비용이 따르며, 너무 일찍 이를 도입하려는 시도는 에이전트 엔지니어링에서 가장 흔히 발생하는 실수 중 하나입니다.

복잡성이 가중됩니다. 단일 에이전트가 실패하면 트레이스(trace)를 읽어 진단하기 쉽습니다. 하지만 여러 에이전트가 실패하는 것은 분산 시스템(distributed systems)의 문제입니다. 어떤 에이전트가 실패했습니까? 오케스트레이터가 결과를 잘못 파싱(misparse)했습니까? 워커가 잘못된 작업을 받았습니까? 모든 단계(hop)가 새로운 실패 표면(failure surface)이 됩니다.

지연 시간(Latency)이 개선되지 않고 오히려 악화될 수 있습니다. 병렬 처리는 I/O 바운드(I/O-bound) 작업에는 도움이 됩니다. 하지만 CPU 바운드(CPU-bound) 작업이나 모델 호출 바운드(model-call-bound) 작업의 경우, 에이전트를 생성하고, 결과를 병합하며, 추가적인 오케스트레이션 호출을 수행하는 오버헤드가 집중된 단일 에이전트가 소요했을 시간보다 더 커질 수 있습니다.

컨텍스트 전달(Context hand-offs) 과정에서 정보가 손실됩니다. 오케스트레이터가 다음 단계로 전달하기 위해 워커의 결과를 요약할 때, 무엇을 남길지에 대한 결정을 내리게 됩니다. 이러한 결정은 정보 손실(lossy)을 수반합니다. 전체 작업을 수행한 단일 에이전트는 스스로를 요약할 필요가 없었습니다.

솔직한 기본 원칙은 다음과 같습니다: 단일 에이전트로 시작하십시오. 컨텍스트 오버플로(context overflow), 측정 가능한 병렬화 이점, 또는 더 나은 프롬프트와 도구로 해결할 수 없는 역량 불일치(capability mismatch)와 같은 구체적인 병목 현상이 발생했을 때 두 번째 에이전트를 추가하십시오.

실질적인 의사결정 프레임워크

싱글 에이전트 (Single agent)는 멀티 에이전트 (Multi-agent)로 가기 위한 디딤돌이 아닙니다. 이는 매우 광범위한 작업에 적합한 아키텍처 (Architecture)이며, 작업을 분할해야 할 구체적인 이유가 생기기 전까지는 기본값 (Default)으로 선택해야 하는 방식입니다. 멀티 에이전트 시스템 (Multi-agent systems)은 작업이 하나의 컨텍스트 윈도우 (Context window)가 수용할 수 있는 범위를 진정으로 초과할 때, 병렬 처리 (Parallelism)를 통해 실질적인 속도 이득을 얻을 수 있을 때, 또는 전문화된 에이전트 (Specialist agents)가 정의된 하위 작업 (Subtask)에서 범용 에이전트 (Generalist)보다 유의미하게 뛰어난 성능을 보일 때 그 복잡성을 감수할 가치가 있습니다.

루프 (Loop) 자체는 변하지 않습니다. 변하는 것은 루프의 어느 부분을 누가 소유하는지, 그리고 각 구성 요소가 어떻게 결과를 보고하는지입니다.