멀티에이전트 토폴로지, 오케스트레이터-워커 / 파이프라인 / 디베이트 중 뭘 언제 써야 하나요?

답변 1개

• 채택된 답변에디터 검증

  결론부터, 의사결정 트리:

  • 작업이 분해 가능하고 디버깅이 중요 → 오케스트레이터-워커(supervisor)
  • 단계마다 게이트(검증)를 강제하고 순서가 고정 → 파이프라인
  • 하나의 정답이 없는 판단(설계 선택, 평가)에서 품질을 더 짜내야 하고 비용을 감당 → 디베이트(단, judge 필수)
  • 작업이 초대형이라 한 오케스트레이터가 다 못 봄 → 계층형(단, 3단계 넘기지 말 것)

  각각 "언제 안 쓰는가"까지 박아서 정리한다.

  1) 오케스트레이터-워커 (supervisor)

  언제: 작업을 독립 하위작업으로 쪼갤 수 있고, 무엇이 어디서 깨졌는지 추적이 중요할 때. 문서 QA의 기본값이다. supervisor가 질문을 받아 retriever 워커 / 답변 워커 / 검증 워커로 분배한다. 장점: 디버깅이 쉽다. 트레이스에서 어느 워커 출력이 틀렸는지 바로 보인다. 언제 안 쓰나: 단계 순서가 항상 고정이라면 supervisor의 라우팅 LLM 호출이 순수 오버헤드다(라우팅에 매번 토큰을 쓴다). 그땐 파이프라인. 도구: OpenAI Agents SDK의 "agents as tools" 패턴(특화 에이전트가 대화를 넘겨받지 않고 바운드된 하위작업만 처리해 결과를 반환)이 정확히 이 모양이다.

  2) 파이프라인

  언제: 순서가 고정이고 각 단계 사이에 반드시 통과해야 할 게이트가 있을 때. 예: 추출 → 검증(스키마/팩트체크) → 포맷팅. 검증을 통과 못 하면 다음 단계로 못 간다는 걸 토폴로지로 강제한다. 장점: 게이트 강제 + 라우팅 LLM 호출 0. 가장 싸고 예측 가능하다. 언제 안 쓰나: 어떤 단계를 건너뛰거나 동적으로 순서가 바뀌어야 하면 파이프라인은 못 버틴다. 그땐 supervisor.

  3) 디베이트 — "답이 좋아진다"는 절반만 맞다

  언제: 단일 정답이 없는 판단 작업(아키텍처 선택, 답변 품질 평가)에서, 한 에이전트의 편향을 다른 관점으로 깎아내고 싶을 때. 핵심 함정: judge(심판) 없이 N개 에이전트가 서로 의견을 보고 합의하게 하면 groupthink로 평균값에 수렴한다. 가장 자신 있는(틀려도) 에이전트나 다수 의견 쪽으로 끌려가고, 소수의 옳은 반론이 묻힌다. 디베이트의 가치는 "합의"가 아니라 "독립적 관점 충돌 → 별도 judge가 채점"에 있다. judge는 토론에 참여하지 않은 별도 에이전트여야 하고(self-approval 금지), 각 토론자 출력을 받아 acceptance criteria로 점수만 매긴다. 비용: 토론 3에이전트 × 2라운드 = LLM 호출 6회 + judge 1회 = 단일 호출의 7배다. 한글 작업이면 토큰이 더 잘게 쪼개져 체감 비용은 이보다 더 벌어진다. 문서 QA의 사실 검색에는 과하다. 디베이트는 "이 답변 둘 중 뭐가 맞나" 같은 판정에만 쓰고, 검색·추출엔 쓰지 마라.

  4) 계층형

  언제: 한 오케스트레이터의 컨텍스트 윈도우/추론으로 전체를 못 잡는 초대형 작업. 상위 오케스트레이터 → 중간 오케스트레이터들 → 워커. 함정: 3단계를 넘으면 컨텍스트 희석이 심해진다. 상위의 목표가 중간을 거쳐 워커까지 가면서 손실되어 워커가 엉뚱한 걸 한다. "얕고 넓게"가 원칙이다. 4단계가 필요하다 싶으면 대개 작업 분해가 틀린 것이다.

  모든 토폴로지 공통 — 핸드오프 계약과 히스토리 절단

  토폴로지보다 더 자주 사고 나는 두 가지가 있다.

  (a) 전체 히스토리 통째 전달 금지. 에이전트 A→B로 넘길 때 전체 대화를 그대로 주면 토큰이 폭증하고 노이즈로 B 성능이 떨어진다. OpenAI Agents SDK는 핸드오프 시 새 에이전트가 기본적으로 전체 히스토리를 본다. 이걸 바꾸려면 input_filter로 넘기는 입력을 가공하거나, run 레벨에서 RunConfig.nest_handoff_history를 켜면 이전 transcript를 단일 요약 메시지로 압축해 <CONVERSATION HISTORY> 블록에 넣는다(opt-in, 기본 off, handoff/run에 명시적 input_filter가 없을 때만 적용). 한글 멀티에이전트에서 이건 옵션이 아니라 거의 필수다.

  (b) 구조화된 핸드오프 계약. 자유 텍스트로 "이거 처리해줘" 넘기지 말고 goal / acceptance_criteria / constraints / open_questions 4필드를 강제하라. 받는 에이전트가 무엇을 만족시켜야 하는지(acceptance)와 모르는 것(open_questions)을 명시하면, 검증 단계가 그걸 그대로 체크리스트로 쓸 수 있다.

  from pydantic import BaseModel
  
  class Handoff(BaseModel):
      goal: str
      acceptance_criteria: list[str]   # 검증 워커가 이걸로 채점
      constraints: list[str] = []
      open_questions: list[str] = []   # 불확실한 것 명시 → 다운스트림이 채움
  

  문서 QA 구체 추천

  실무 기본값은 파이프라인(retriever → answerer → verifier 게이트). retriever가 동적으로 여러 소스를 골라야 하면 그 앞단만 supervisor. 디베이트는 "답변 A/B 중 채택" 같은 평가 단계에만 judge와 함께 제한적으로 쓴다. 계층형은 단일 문서 QA엔 거의 필요 없다.

  Sources: Agent orchestration - OpenAI Agents SDK, Handoffs - OpenAI Agents SDK, A practical guide to building agents - OpenAI

  2026년 5월 13일도움돼요 26

  신고