-->

⏱️ 예상 읽기 시간: 8분

왜 지금 이 주제인가

2026년 상반기 기준으로 프로덕션 LLM 워크로드의 상당 부분이 단일 모델 호출이 아닌 멀티에이전트 파이프라인으로 전환됐다. LangGraph, CrewAI, Microsoft Agent Framework, Google ADK 같은 프레임워크가 안정 버전을 낸 이후 “어떻게 붙이느냐”보다 “어떤 패턴을 언제 쓰느냐”가 더 중요한 질문이 됐다.

문제는 멀티에이전트가 공짜가 아니라는 점이다. 중앙집중식 아키텍처는 단일 에이전트 대비 토큰 오버헤드가 약 285%, 독립 분산 구조도 약 58% 더 발생한다. 패턴을 잘못 고르면 결과가 나빠지는 게 아니라 비용이 폭증하면서 결과도 나빠진다.

이 글에서는 2026년 현재 프로덕션에서 실제로 쓰이는 6가지 패턴을 정리하고, 각각의 적합 조건과 피해야 할 상황을 구체적으로 다룬다.

패턴 1: Orchestrator-Worker

가장 많이 쓰이는 패턴이다. 업계 조사 기준으로 2026년 프로덕션 멀티에이전트 배포의 약 70%가 이 구조를 사용한다.

구조는 단순하다. 오케스트레이터가 들어온 태스크를 분류하고 서브태스크로 쪼갠 뒤, 각각을 전문 워커(리서처, 코더, 테스터, 리뷰어)에게 디스패치하고 결과를 합친다.

오케스트레이터
├── 태스크 분해
├── 워커 A 디스패치 → 결과 A
├── 워커 B 디스패치 → 결과 B
└── 결과 병합 → 최종 출력

쓸 때: 태스크가 명확하게 분리 가능하고, 각 도메인에 전문성이 필요할 때.

피할 때: 워커 간 의존도가 높아서 오케스트레이터가 매 스텝마다 상태를 동기화해야 하는 경우. 이 경우 오케스트레이터가 병목이 된다.

비용 주의: 오케스트레이터 모델을 Opus로 고정하면 모든 라우팅 결정이 최고가 모델을 쓰게 된다. 오케스트레이터는 Sonnet, 워커 중 추론이 필요한 단계만 Opus로 가르는 게 경제적이다.

패턴 2: Sequential Pipeline

단계가 고정된 선형 구조다. 앞 단계 출력이 다음 단계 입력이 된다.

RAG 파이프라인이 전형적인 예다: 쿼리 재작성 → 검색 → 재랭킹 → 생성 → 후처리. 순서가 바뀌면 의미가 없고, 중간 단계를 건너뛸 수 없다.

쓸 때: 워크플로가 결정론적이고 단계 간 순서가 반드시 지켜져야 할 때.

피할 때: 태스크 특성에 따라 일부 단계가 불필요할 수 있을 때. 그 경우 조건 분기가 있는 동적 패턴이 낫다.

구현 팁: LangGraph에서 노드 간 엣지를 고정하면 Sequential Pipeline이 된다. 단계별 중간 결과를 체크포인트로 저장하면 실패 시 처음부터 재시작하지 않아도 된다.

패턴 3: Fan-out / Fan-in

독립적인 태스크 N개를 병렬 실행하고 결과를 하나로 합치는 구조다.

예: 같은 문서를 정확성 검토 에이전트, 보안 취약점 검토 에이전트, 코드 스타일 검토 에이전트가 동시에 처리하고 각 리포트를 합쳐 종합 리뷰를 만드는 경우.

# 개념적 구조
results = await asyncio.gather(
    accuracy_agent.run(document),
    security_agent.run(document),
    style_agent.run(document)
)
final_report = merge_agent.run(results)

쓸 때: 4개 이상의 독립 태스크가 있고, 각 태스크 사이에 데이터 의존성이 없을 때. 병렬화로 전체 레이턴시를 줄일 수 있다.

피할 때: 태스크가 실제로 독립적이지 않을 때. 의존성이 있는 태스크를 억지로 병렬화하면 Fan-in 단계에서 결과 충돌이 생긴다.

패턴 4: Multi-agent Debate

같은 태스크에 대해 여러 에이전트가 각기 다른 관점으로 답을 내고, 비판자 에이전트가 이를 검토해 최종 답을 도출하는 구조다. Maker-Checker 루프라고도 부른다.

LLM 단일 호출보다 정확도가 높지만 비용도 높다. 속도보다 정확도가 우선인 경우에 쓴다.

쓸 때: 의료, 법률, 금융 도메인처럼 오류의 비용이 높은 경우. 혹은 코드 생성 후 보안 취약점을 찾아야 할 때.

피할 때: 지연 시간이 중요한 실시간 응답 경로. 토론 라운드가 추가될수록 레이턴시가 선형으로 늘어난다.

패턴 5: Dynamic Handoff

에이전트가 태스크를 처리하다가 자신의 역량 바깥이라고 판단하면 적합한 에이전트에게 제어권을 넘기는 구조다. 라우팅 로직이 사전에 하드코딩되지 않고, 대화 흐름에 따라 결정된다.

고객 지원 시나리오가 전형적이다. 일반 문의 에이전트가 기술 이슈를 만나면 기술 지원 에이전트로 핸드오프하고, 결제 문제가 나오면 결제 에이전트로 넘긴다.

구현 주의점: 핸드오프가 루프를 형성하지 않도록 에이전트 간 이전 이력을 컨텍스트에 포함해야 한다. 그렇지 않으면 에이전트 A → B → A → B로 무한 루프가 생긴다.

패턴 6: Adaptive Planning

목표만 주어지고, 계획 자체를 실행 중에 발견해야 하는 개방형 문제에 쓴다. 에이전트가 환경을 탐색하고, 중간 결과를 바탕으로 다음 행동을 결정한다.

소프트웨어 엔지니어링 에이전트(SWE-bench 류)나 자율 리서치 에이전트가 이 패턴을 쓴다. 사전에 스텝 시퀀스를 정의할 수 없을 때 필요하다.

위험: 종료 조건이 불명확하면 에이전트가 필요 이상으로 많은 스텝을 탐색한다. 반드시 최대 반복 횟수나 비용 상한을 설정해야 한다.

패턴 선택 기준표

패턴 태스크 구조 순서 의존 병렬화 비용 수준
Orchestrator-Worker 분리 가능 낮음 부분 중간
Sequential Pipeline 선형 고정 높음 없음 낮음
Fan-out / Fan-in 독립 병렬 없음 최대 낮음-중간
Multi-agent Debate 동일 태스크 없음 부분 높음
Dynamic Handoff 예측 불가 없음 없음 중간
Adaptive Planning 개방형 없음 없음 가장 높음

비용 제어 원칙

멀티에이전트를 도입하기 전에 “이 태스크가 실제로 멀티에이전트가 필요한가”를 먼저 따져야 한다. 단순 태스크를 억지로 멀티에이전트화하면 비용만 늘고 품질은 단일 에이전트와 비슷하거나 더 나빠진다.

멀티에이전트가 정당화되는 경우는 세 가지다.

첫째, 도메인 전문성이 실제로 다를 때. 코드 생성과 보안 검토는 다른 특성의 태스크다.

둘째, 독립적인 병렬화가 가능해서 전체 레이턴시를 줄일 수 있을 때.

셋째, 비판-검토 루프가 정확도를 실질적으로 높일 때. 이때는 Multi-agent Debate의 추가 비용을 정당화할 수 있다.

모델 티어 분리가 비용 제어의 핵심이다. 탐색/그렙/파일 읽기 워커는 Haiku, 구현/리뷰 워커는 Sonnet, 아키텍처 결정이나 검증 게이트만 Opus로 가른다. 전체 파이프라인을 같은 모델로 돌리면 비용과 품질을 동시에 잃는다.

마치며

패턴을 고르는 것이 프레임워크를 고르는 것보다 중요하다. LangGraph로 Fan-out을 구현하든 CrewAI로 Orchestrator-Worker를 구현하든, 패턴이 태스크 구조와 맞지 않으면 프레임워크가 문제를 해결해주지 않는다.

지금 가장 많은 팀이 실수하는 지점은 Adaptive Planning이 필요 없는 태스크에 해당 패턴을 쓰는 것이다. 종료 조건 없이 개방형 탐색 루프를 프로덕션에 올리면 비용 폭주나 타임아웃으로 이어진다. Sequential Pipeline이나 Fan-out으로 충분한지를 먼저 확인하는 것이 좋다.

참고