1.4멀티 에이전트 시스템과 오케스트레이션

멀티 에이전트는 기본 선택지가 아닙니다. Anthropic이 공개한 멀티 에이전트 리서치 시스템 사례는 이 구조가 일반 대화 대비 훨씬 많은 토큰을 소비한다고 밝히고 있습니다. 성능이 그만큼 개선되지 않으면 순손실입니다.

나누는 것이 값을 하는 조건은 두 가지로 정리됩니다.

첫째, 하위 작업이 서로 독립적이고 병렬 탐색이 이득일 때. 여러 출처를 동시에 조사하는 작업처럼, 하위 조사들이 서로의 결과를 필요로 하지 않으면 병렬로 돌린 만큼 시간이 줄어듭니다. 반대로 앞 결과가 있어야 뒤를 정할 수 있는 순차 의존 작업은 나눠도 시간이 줄지 않고 조율 비용만 붙습니다.

둘째, 컨텍스트 격리가 필요할 때. 한 에이전트가 대량의 중간 자료를 읽어야 하는데 그 자료가 최종 판단에는 필요 없는 경우, 그 읽기를 별도 워커에 격리하면 오케스트레이터의 컨텍스트가 깨끗하게 유지됩니다. 워커는 원문을 읽고 요약만 돌려줍니다.

두 조건 중 어느 것도 해당하지 않는데 "역할을 나누면 각자 잘할 것"이라는 이유로 쪼개는 것은 흔한 오해입니다. 역할 분담은 프롬프트로도 됩니다. 프로세스를 나누는 것은 컨텍스트와 병렬성을 위한 결정입니다.

시험에서는 순차 의존이 명백한 작업에 멀티 에이전트를 제안하는 선택지가 오답으로 자주 등장합니다.

표준 구조는 오케스트레이터-워커입니다. 중앙 에이전트가 작업을 쪼개 워커에게 위임하고 결과를 종합합니다. 이 구조의 설계 핵심은 조율 로직이 아니라 컨텍스트 경계입니다.

각 워커는 자기 작업에 필요한 최소한만 받습니다. 오케스트레이터의 전체 대화 이력을 그대로 넘기면 격리의 이점이 사라지고 토큰만 배로 듭니다.

async def orchestrate(goal):
    plan = await call_model(
        f"다음 목표를 독립적으로 수행 가능한 하위 조사로 나눠라: {goal}",
        model=MODEL,
    )
    # 워커는 각자 자기 지시문만 받는다. 오케스트레이터 이력은 넘기지 않는다
    results = await gather(*[
        run_worker(task.instruction, tools=task.tools)
        for task in plan.tasks
    ])
    return await call_model(
        synthesis_prompt(goal, [r.summary for r in results]),  # 요약만 종합
        model=MODEL,
    )

두 지점을 눈여겨보십시오. 워커에 넘기는 것은 task.instruction 하나이고, 돌려받는 것은 r.summary입니다. 워커가 읽은 원문 전체가 오케스트레이터로 올라오면 격리한 의미가 없습니다.

워커 지시문의 품질이 전체 성능을 좌우합니다. 모호한 지시를 받은 워커들은 서로 겹치는 작업을 하거나 아무도 다루지 않는 구멍을 남깁니다. 지시문에는 범위, 산출물 형식, 하지 말아야 할 것을 명시합니다. 특히 "다른 워커가 담당하는 영역은 다루지 마라"는 경계 표시가 중복 작업을 크게 줄입니다.

에이전트 사이의 인계는 정보 선택의 문제입니다. 전부 넘기면 컨텍스트가 부풀고, 너무 줄이면 다음 에이전트가 판단 근거를 잃습니다.

실무에서 쓰는 구분은 세 갈래입니다.

• 결론과 근거 요약 — 반드시 넘깁니다. 다음 판단의 입력입니다
• 원문과 중간 산출물 — 넘기지 않고 참조 가능한 저장소에 두고 식별자만 전달합니다. 다음 에이전트가 필요하면 도구로 가져옵니다
• 시행착오 기록 — 대개 버립니다. 다만 같은 실패를 반복할 위험이 있다면 "이미 시도했고 실패한 것" 목록만 짧게 넘깁니다

세 번째가 실무에서 가장 자주 잘못 처리됩니다. 실패한 시도까지 전부 넘기면 컨텍스트의 상당 부분이 쓸모없는 기록으로 차고, 아무것도 넘기지 않으면 다음 에이전트가 같은 벽에 다시 부딪칩니다.

interface Handoff {
  conclusion: string;              // 결론
  evidence: string[];              // 근거 요약
  artifactIds: string[];           // 원문은 식별자만
  attempted: string[];             // 실패한 접근의 짧은 목록
  openQuestions: string[];         // 해결하지 못한 것
}

openQuestions 항목을 두는 이유는 미해결 사항이 조용히 사라지는 것을 막기 위해서입니다. 에이전트가 답을 못 찾았는데 결론만 넘기면, 종합 단계에서 그 공백이 확신에 찬 문장으로 메워질 수 있습니다.

단일 에이전트에 없던 실패가 새로 생깁니다. 설계 단계에서 대비해야 하는 것들입니다.

중복 작업. 워커들의 범위가 겹치면 같은 자료를 여러 번 읽습니다. 비용이 늘 뿐 아니라 종합 단계에서 같은 근거가 여러 번 등장해 실제보다 강한 합의로 보입니다. 대응은 지시문의 경계 명시와, 종합 단계에서 출처 기준 중복 제거입니다.

부분 실패. 워커 다섯 중 하나가 실패했을 때 무엇을 반환할지 정해야 합니다. 조용히 넷의 결과만 종합하면 사용자는 완전한 조사로 오해합니다. 실패한 범위를 결과에 명시하거나, 필수 워커의 실패는 전체 실패로 올리는 정책이 필요합니다.

비용 폭주. 오케스트레이터가 워커를 동적으로 만들면 그 수가 예측되지 않습니다. 워커 수 상한, 총 토큰 예산, 깊이 제한을 코드 수준에서 겁니다. 프롬프트에 "너무 많이 만들지 마라"고 쓰는 것은 상한이 아닙니다.

책임 소재 불명. 결과가 틀렸을 때 어느 워커의 어느 판단에서 비롯되었는지 추적할 수 없으면 개선이 불가능합니다. 각 워커 실행에 식별자를 부여하고 입력·출력·소비 토큰을 함께 기록해, 종합 결과에서 근거를 역추적할 수 있게 만듭니다.

MAX_WORKERS = 8
if len(plan.tasks) > MAX_WORKERS:
    plan.tasks = plan.tasks[:MAX_WORKERS]
    log.warning("worker_cap_applied", requested=len(plan.tasks), cap=MAX_WORKERS)

상한을 적용했다는 사실을 로그로 남기는 것이 요점입니다. 조용히 잘라내면 부분 조사 결과가 완전한 것처럼 보고됩니다.