핵심 아키텍처 패턴

Routing, Parallelization, Pipeline, Orchestrator-Workers, Evaluator-Optimizer, Hierarchical, DAG 7개 패턴 비교

오케스트레이션 패턴은 "어떤 일을 누가 언제 수행하는가"를 정하는 청사진입니다. 대부분의 시스템은 하나의 패턴만 쓰지 않고, 기본 패턴 2~3개를 조합해 만듭니다.

7가지 핵심 패턴

패턴	적합한 문제	장점	주의점
Routing	여러 작업 경로 중 하나를 선택해야 함	비용 절감, 책임 분리	분류 오류가 초반에 전체 품질을 망칠 수 있음
Parallelization	독립 분석이나 조사 작업이 많음	지연 단축, 비교 가능성 향상	결과 통합 품질이 별도 문제로 남음
Pipeline	단계 간 의존성이 강함	흐름이 명확하고 디버깅 쉬움	앞 단계 오류가 뒤로 전파됨
Orchestrator-Workers	권한과 역할이 다른 전문 agent가 필요함	도메인 분리, tool 접근 통제	handoff와 상태 조합이 복잡해짐
Evaluator-Optimizer	초안 생성 후 품질 개선이 중요함	품질 루프 확보	과도한 반복으로 비용 증가
Hierarchical	팀 구조처럼 상위 계획과 하위 실행을 나눔	큰 문제 분해에 강함	상위 agent가 병목이 되기 쉬움
DAG	단계의 선후관계가 복합적임	재사용, fan-out/fan-in 표현에 강함	설계와 관측성이 어려움

패턴 선택 기준

질문	Yes일 때 우선 검토할 패턴
입력을 먼저 분류해야 하는가	Routing
독립 step를 동시에 실행할 수 있는가	Parallelization
이전 산출물이 다음 단계의 핵심 입력인가	Pipeline
서로 다른 권한/도메인 전문성이 필요한가	Orchestrator-Workers
품질 평가를 별도 루프로 두어야 하는가	Evaluator-Optimizer
상위 계획과 하위 작업이 명확히 분리되는가	Hierarchical
실행 순서가 직선형이 아니라 그래프 구조인가	DAG

조합 예시

실전에서는 routing -> parallel research -> evaluator -> approval처럼 조합하는 경우가 많습니다. 즉, 패턴 선택의 핵심은 "무엇이 주 패턴인가"보다 어디에 통제 포인트를 둘 것인가입니다.

패턴별 상세 메모

Routing

분류 실패 비용이 큰 경우, semantic routing만 믿지 말고 rule-based pre-filter를 먼저 둡니다.
"어느 agent를 부를까"만이 아니라 "사람에게 넘길까"까지 라우팅 범위에 포함합니다.

Parallelization

병렬 step는 서로 독립적이어야 합니다.
결과 통합 단계에서 근거 출처와 신뢰도를 함께 병합해야 품질이 올라갑니다.

Pipeline

단계별 출력 계약이 명확할수록 안정적입니다.
앞 단계가 불안정하면 downstream의 정교함은 의미가 없습니다.

Orchestrator-Workers

worker는 폭넓은 능력보다 좁은 책임을 가져야 합니다.
orchestrator가 직접 모든 tool을 가지면 worker 분리의 의미가 사라집니다.

Evaluator-Optimizer

평가 기준이 텍스트 설명만 있으면 반복 루프가 흔들립니다.
pass/fail 기준, 스코어, 수정 지시를 구조화해야 합니다.
종료 조건을 반드시 정의합니다: max iteration, 최소 점수 도달, 또는 개선 정체 감지.

Hierarchical

상위 agent는 모든 세부 실행을 알 필요가 없습니다.
목표와 제약만 하위에 넘기고, 구현 세부는 worker에 위임하는 편이 유지보수에 유리합니다.

DAG

fan-out/fan-in, 조건 분기, 부분 재실행이 필요한 장기 workflow에 적합합니다.
그래프가 커질수록 시각화와 trace가 없으면 운영이 급격히 어려워집니다.

안티패턴

안티패턴	왜 문제인가	대안
모든 문제를 hierarchical로 모델링	상위 계획 agent가 병목이 됨	pipeline 또는 routing부터 시작
평가도 생성 agent가 스스로 수행	자기합리화 편향이 생김	evaluator 분리
worker마다 공통 tool 전체를 제공	권한 경계가 무너짐	capability별 toolbox 분리
병렬화 후 통합 규칙이 없음	fan-in 품질이 낮아짐	aggregator 스키마 정의

2026 프로덕션 오케스트레이션 패턴

2026년 3월 기준 프로덕션 환경에서 관찰되는 5가지 주요 패턴을 정리합니다.

패턴	채택 비중	적합한 상황	특징
Orchestrator-Worker	~70%	대부분의 프로덕션 시스템	가장 검증된 패턴, 책임 분리 명확
Hierarchical	~15%	대규모 작업 분해	상위 계획 + 하위 실행의 트리 구조
Swarm	~8%	탐색적, 적응적 작업	agent가 자율적으로 협력, 결과 예측이 어려움
Mesh	~5%	peer-to-peer 전문가 협업	중앙 오케스트레이터 없이 agent 간 직접 통신
Pipeline	~2% (단독)	순차 의존성이 강한 작업	보통 다른 패턴의 하위 구성요소로 사용

Swarm 패턴

agent가 작업을 자율적으로 선택하고 다른 agent에 handoff합니다.
탐색적 리서치나 창의적 작업에 적합하지만, 결과 예측성이 낮아 프로덕션에서는 제한적으로 사용됩니다.
가드레일: 반드시 max iteration과 비용 한도를 설정해야 합니다.

Mesh 패턴

중앙 오케스트레이터 없이 agent가 peer-to-peer로 통신합니다.
각 agent가 전문 도메인을 담당하고, 필요할 때 다른 전문가를 호출합니다.
A2A v1.0.0의 Agent Card가 mesh 패턴의 discovery 문제를 해결합니다.

하이브리드 패턴

실전에서는 단일 패턴보다 하이브리드 조합이 일반적입니다.

하이브리드	구조	사용 예시
계층 + 리프 mesh	상위는 hierarchical, 리프 레벨은 mesh	팀 구조 + 전문가 간 자유 협업
파이프라인 + swarm 스테이지	파이프라인의 특정 단계에 swarm 투입	ETL 중 탐색적 데이터 보강 단계
Agentic Mesh	LangGraph 브레인 + CrewAI 팀 + OpenAI 도구	프레임워크 혼합 대규모 시스템

Agentic Mesh 주의점

프레임워크를 혼합하면 trace, 상태, 인증이 각각 다르게 동작합니다. 통합 observability 계층과 공통 인증 게이트웨이를 먼저 설계한 뒤에 도입해야 합니다.

빠른 선택 가이드

FAQ, 간단한 조회 자동화: 단일 agent + tool loop
고객 지원 triage: routing + retrieval + approval
코드 수정 자동화: pipeline + evaluator + human gate
리서치/시장 조사: parallelization + aggregator
장기 승인 프로세스: DAG workflow + checkpoint + resume

최소 구현 스켈레톤

type RequestKind = 'faq' | 'research' | 'execution'

async function orchestrate(input: string) {
  const kind: RequestKind = await route(input)

  if (kind === 'faq') {
    return runSingleAgent(input)
  }

  if (kind === 'research') {
    const evidence = await Promise.all([
      runWorker('market-research', input),
      runWorker('docs-research', input),
    ])

    return evaluateAndMerge(evidence)
  }

  const plan = await buildPlan(input)
  const result = await runPipeline(plan)
  return evaluateAndApprove(result)
}

이 스켈레톤의 포인트는 패턴 이름보다 route -> execute -> evaluate -> approve 같은 통제 지점을 코드에서 명확히 드러내는 데 있습니다.

ADR 스타일 결론

Decision

기본값은 가장 단순한 패턴입니다. 단일 agent 또는 pipeline으로 시작하고, 병렬화는 독립 작업이 분명할 때만, worker 분리는 권한과 책임 분리가 필요한 경우에만 도입합니다. 품질 보증이 중요하면 생성과 평가를 반드시 분리합니다.

실무 체크리스트

현재 문제를 설명할 때 주 패턴을 한 문장으로 말할 수 있는가
각 패턴 추가가 지연, 비용, 품질에 미치는 영향을 설명할 수 있는가
fan-out 이후 fan-in 스키마가 정의되어 있는가
평가 루프의 종료 조건이 있는가
사람이 개입해야 하는 지점을 패턴 수준에서 모델링했는가

다음에 읽을 장

7가지 핵심 패턴

패턴	적합한 문제	장점	주의점
Routing	여러 작업 경로 중 하나를 선택해야 함	비용 절감, 책임 분리	분류 오류가 초반에 전체 품질을 망칠 수 있음
Parallelization	독립 분석이나 조사 작업이 많음	지연 단축, 비교 가능성 향상	결과 통합 품질이 별도 문제로 남음
Pipeline	단계 간 의존성이 강함	흐름이 명확하고 디버깅 쉬움	앞 단계 오류가 뒤로 전파됨
Orchestrator-Workers	권한과 역할이 다른 전문 agent가 필요함	도메인 분리, tool 접근 통제	handoff와 상태 조합이 복잡해짐
Evaluator-Optimizer	초안 생성 후 품질 개선이 중요함	품질 루프 확보	과도한 반복으로 비용 증가
Hierarchical	팀 구조처럼 상위 계획과 하위 실행을 나눔	큰 문제 분해에 강함	상위 agent가 병목이 되기 쉬움
DAG	단계의 선후관계가 복합적임	재사용, fan-out/fan-in 표현에 강함	설계와 관측성이 어려움

패턴 선택 기준

질문	Yes일 때 우선 검토할 패턴
입력을 먼저 분류해야 하는가	Routing
독립 step를 동시에 실행할 수 있는가	Parallelization
이전 산출물이 다음 단계의 핵심 입력인가	Pipeline
서로 다른 권한/도메인 전문성이 필요한가	Orchestrator-Workers
품질 평가를 별도 루프로 두어야 하는가	Evaluator-Optimizer
상위 계획과 하위 작업이 명확히 분리되는가	Hierarchical
실행 순서가 직선형이 아니라 그래프 구조인가	DAG

분류 실패 비용이 큰 경우, semantic routing만 믿지 말고 rule-based pre-filter를 먼저 둡니다.
"어느 agent를 부를까"만이 아니라 "사람에게 넘길까"까지 라우팅 범위에 포함합니다.

Parallelization

병렬 step는 서로 독립적이어야 합니다.
결과 통합 단계에서 근거 출처와 신뢰도를 함께 병합해야 품질이 올라갑니다.

Pipeline

단계별 출력 계약이 명확할수록 안정적입니다.
앞 단계가 불안정하면 downstream의 정교함은 의미가 없습니다.

Orchestrator-Workers

worker는 폭넓은 능력보다 좁은 책임을 가져야 합니다.
orchestrator가 직접 모든 tool을 가지면 worker 분리의 의미가 사라집니다.

Evaluator-Optimizer

평가 기준이 텍스트 설명만 있으면 반복 루프가 흔들립니다.
pass/fail 기준, 스코어, 수정 지시를 구조화해야 합니다.
종료 조건을 반드시 정의합니다: max iteration, 최소 점수 도달, 또는 개선 정체 감지.

Hierarchical

상위 agent는 모든 세부 실행을 알 필요가 없습니다.
목표와 제약만 하위에 넘기고, 구현 세부는 worker에 위임하는 편이 유지보수에 유리합니다.

DAG

fan-out/fan-in, 조건 분기, 부분 재실행이 필요한 장기 workflow에 적합합니다.
그래프가 커질수록 시각화와 trace가 없으면 운영이 급격히 어려워집니다.

안티패턴

안티패턴	왜 문제인가	대안
모든 문제를 hierarchical로 모델링	상위 계획 agent가 병목이 됨	pipeline 또는 routing부터 시작
평가도 생성 agent가 스스로 수행	자기합리화 편향이 생김	evaluator 분리
worker마다 공통 tool 전체를 제공	권한 경계가 무너짐	capability별 toolbox 분리
병렬화 후 통합 규칙이 없음	fan-in 품질이 낮아짐	aggregator 스키마 정의

2026 프로덕션 오케스트레이션 패턴

2026년 3월 기준 프로덕션 환경에서 관찰되는 5가지 주요 패턴을 정리합니다.

패턴	채택 비중	적합한 상황	특징
Orchestrator-Worker	~70%	대부분의 프로덕션 시스템	가장 검증된 패턴, 책임 분리 명확
Hierarchical	~15%	대규모 작업 분해	상위 계획 + 하위 실행의 트리 구조
Swarm	~8%	탐색적, 적응적 작업	agent가 자율적으로 협력, 결과 예측이 어려움
Mesh	~5%	peer-to-peer 전문가 협업	중앙 오케스트레이터 없이 agent 간 직접 통신
Pipeline	~2% (단독)	순차 의존성이 강한 작업	보통 다른 패턴의 하위 구성요소로 사용

Swarm 패턴

agent가 작업을 자율적으로 선택하고 다른 agent에 handoff합니다.
탐색적 리서치나 창의적 작업에 적합하지만, 결과 예측성이 낮아 프로덕션에서는 제한적으로 사용됩니다.
가드레일: 반드시 max iteration과 비용 한도를 설정해야 합니다.

Mesh 패턴

중앙 오케스트레이터 없이 agent가 peer-to-peer로 통신합니다.
각 agent가 전문 도메인을 담당하고, 필요할 때 다른 전문가를 호출합니다.
A2A v1.0.0의 Agent Card가 mesh 패턴의 discovery 문제를 해결합니다.

하이브리드 패턴

실전에서는 단일 패턴보다 하이브리드 조합이 일반적입니다.

하이브리드	구조	사용 예시
계층 + 리프 mesh	상위는 hierarchical, 리프 레벨은 mesh	팀 구조 + 전문가 간 자유 협업
파이프라인 + swarm 스테이지	파이프라인의 특정 단계에 swarm 투입	ETL 중 탐색적 데이터 보강 단계
Agentic Mesh	LangGraph 브레인 + CrewAI 팀 + OpenAI 도구	프레임워크 혼합 대규모 시스템

Agentic Mesh 주의점

빠른 선택 가이드

FAQ, 간단한 조회 자동화: 단일 agent + tool loop
고객 지원 triage: routing + retrieval + approval
코드 수정 자동화: pipeline + evaluator + human gate
리서치/시장 조사: parallelization + aggregator
장기 승인 프로세스: DAG workflow + checkpoint + resume

최소 구현 스켈레톤

type RequestKind = 'faq' | 'research' | 'execution'

async function orchestrate(input: string) {
  const kind: RequestKind = await route(input)

  if (kind === 'faq') {
    return runSingleAgent(input)
  }

  if (kind === 'research') {
    const evidence = await Promise.all([
      runWorker('market-research', input),
      runWorker('docs-research', input),
    ])

    return evaluateAndMerge(evidence)
  }

  const plan = await buildPlan(input)
  const result = await runPipeline(plan)
  return evaluateAndApprove(result)
}

이 스켈레톤의 포인트는 패턴 이름보다 route -> execute -> evaluate -> approve 같은 통제 지점을 코드에서 명확히 드러내는 데 있습니다.

ADR 스타일 결론

Decision

실무 체크리스트

현재 문제를 설명할 때 주 패턴을 한 문장으로 말할 수 있는가
각 패턴 추가가 지연, 비용, 품질에 미치는 영향을 설명할 수 있는가
fan-out 이후 fan-in 스키마가 정의되어 있는가
평가 루프의 종료 조건이 있는가
사람이 개입해야 하는 지점을 패턴 수준에서 모델링했는가

핵심 아키텍처 패턴

목차

핵심 아키텍처 패턴

목차