순차적 파이프라인이 에이전트 처리량을 저해합니다. 3배 향상시킨 동시 실행 대안을 소개합니다

한 사용자가 41초 만에 리서치 보고서를 포기하는 것을 지켜봤습니다. 파이프라인은 여전히 작동하고 있었습니다. 순차적인 에이전트 작업이 45초 동안 진행되었고, 모든 단계는 이전 단계에 의존했으며, 모든 에이전트는 자신의 차례를 기다리고 있었습니다. 결과물이 도착할 때쯤에는 이미 탭이 닫혀버렸습니다. 이 단 한 번의 포기된 세션은 그 주 전체 GPU 비용보다 더 큰 신뢰 손실을 안겨주었습니다.

그날 저는 순차적 오케스트레이션을 합리적인 기본값으로 취급하는 것을 멈추고, 눈치채지 못하고 지불해왔던 '지연 시간 세금(latency tax)'으로 여기기 시작했습니다.

제가 보지 못했던 세금

파이프라인은 화이트보드 위에서 그럴듯하게 보였습니다. 플래너(planner)가 쿼리를 하위 질문들로 분해했습니다. 리트리버(retriever)가 각 질문에 대한 소스를 가져왔습니다. 애널라이저(analyzer)가 분석 결과를 만들어냈습니다. 베리파이어(verifier)가 주장을 검증했습니다. 그리고 신세사이저(synthesizer)가 모든 것을 최종 답변으로 통합했습니다. 다섯 단계였고, 각각은 논리적으로 이전 단계에 의존하고 있었습니다.

실제 운영 환경에서는 LLM 호출의 직렬 큐였습니다. 리트리버는 플래너가 끝날 때까지 시작할 수 없었습니다. 애널라이저는 모든 검색(retrieval)이 완료될 때까지 시작할 수 없었습니다. 베리파이어는 애널라이저를 기다렸습니다. 신세사이저는 모든 것을 기다렸습니다. 이전 단계가 자신에게 실제 의존성이 없는 작업을 끝내는 동안, 모든 에이전트는 유휴 상태였습니다.

Microsoft의 오케스트레이션 문서 자체도 이 산술을 명확하게 설명합니다. 시장 분석에 12초가 걸리고 위험 평가에 10초가 걸린다면, 순차적 실행은 총 22초가 걸립니다. 병렬 실행은 두 작업 중 최대 시간인 12초 만에 완료됩니다. 독립적인 작업을 가진 워크플로우의 경우, 병렬 실행은 동시 에이전트 수만큼 지연 시간을 비례적으로 단축합니다. 네 개의 에이전트를 병렬로 실행하면 모든 에이전트의 합계 시간보다 느린 에이전트의 시간에 가깝게 완료됩니다.

저는 동시에 실행할 수 있는 네 개의 에이전트를 가지고 있었지만, 그들의 최대 시간이 아닌 총합을 지불하고 있었습니다.

연구가 이미 알고 있던 것들

연구가 이미 알고 있던 것들

2026년 벤치마크 문헌은 제가 느끼던 것을 이미 정량화했습니다. 한 NYU의 연구는 네 가지 오케스트레이션 아키텍처(순차적 파이프라인, 병렬 팬-아웃 후 병합, 계층적 감독자-작업자, 반사적 자체 수정 루프)를 10,000개의 SEC 제출 서류와 다섯 개의 최첨단 모델에 걸쳐 비교했습니다. 저를 깜짝 놀라게 한 발견은 다음과 같습니다. 팬-아웃 후 병합(parallel fan-out with merge)이 **지연 시간 측면에서 최적(latency-optimal)**이라는 것입니다. 왜냐하면 지연 시간은 모든 단계의 합계가 아니라 가장 느린 병렬 분기점과 병합 오버헤드로 인해 결정되기 때문입니다.

금융 문서 벤치마크는 두 번째 데이터 포인트로 이를 확인해 주었습니다. 순차적 파이프라인은 대규모에서 가장 저렴하고 안정적이며, 특히 하루 10만 건 이상의 문서를 처리할 때는 그렇습니다. 하지만 병렬 팬-아웃은 더 높은 토큰 비용을 감수하더라도 지연 시간 면에서 압도적으로 우수합니다. 아키텍처는 선택의 문제이지, 판결이 아닙니다. 저는 사용자 대상 제품에 있어 반응성이 누군가 결과물을 보게 만들지 여부를 결정하는 상황에서 잘못된 트레이드오프를 선택하고 있었습니다.

LangGraph 병렬 실행 PoC(Proof of Concept)는 이 수학적 개념을 체감하게 했습니다. 직렬 그래프의 네 개의 노드는 4.97초가 걸렸습니다. 같은 네 개의 노드를 병렬 에지로 연결했을 때는 2.29초가 걸렸습니다. 단지 그래프 배선 세 줄만 변경했을 뿐인데도 월 클락 시간(wall-clock time)이 53.9% 감소한 것입니다.

저는 몇 주 동안 프롬프트를 조정하고 있었습니다. 해결책은 토폴로지였습니다.

문제를 해결한 팬-아웃

이 패턴을 **팬-아웃 및 팬-인(fan-out and fan-in)**이라고 부르며, 이름보다 훨씬 간단합니다. 팬-아웃은 여러 에이전트 작업을 동시에 생성(spawn)합니다. 팬-인은 모든 (또는 특정 임계값 이상의) 에이전트가 완료될 때까지 기다린 후에 다음 단계로 진행합니다.

저는 세 가지 변경 사항을 중심으로 파이프라인을 재구축했습니다.

플래너(planner)는 여전히 먼저 실행됩니다. 왜냐하면 그것은 진정으로 필수적이기 때문입니다. 분해(Decomposition)는 진정한 순차적 의존성입니다. 무엇을 검색할지 알지 못하면 검색할 수 없습니다. 하지만 플래너는 독립적인 하위 질문 목록을 생성하며, 이 목록에서 직렬 체인이 끝납니다.

검색(Retrieval), 분석(analysis), 검증(verification)은 하위 질문별로 병렬화됩니다. 다섯 개의 하위 질문을 순차적으로 처리하는 하나의 검색 단계 대신, 다섯 개의 검색 에이전트가 동시에 실행됩니다. 하나의 분석 단계 대신, 다섯 개의 분석이 동시에 실행됩니다. 각 단계의 경과 시간(wall-clock time)은 모든 하위 질문의 합계에서 가장 느린 단일 하위 질문의 시간이 됩니다.

합성기(synthesizer)는 병렬화가 끝난 후에 실행됩니다. 이 단계만이 진정으로 상류(upstream)의 모든 것을 필요로 합니다. 이는 모든 병렬 분기가 완료되기를 기다리고, 그 출력들을 조정하여 최종 답변을 생성합니다.

이러한 아키텍처적 변화는 의존성 그래프가 코드 순서에 의해 암시되는 것이 아니라 명시적이라는 것입니다. 제가 제시한 다섯 단계 중 세 단계는 실제로 서로 의존하지 않았습니다. 체인(chain)은 요구사항이 아니라 습관이었던 것입니다.

수치 비교

재구축 전: 종단 간(end-to-end) 45초. 재구축 후: 14초. 3.2배 감소입니다.

수학적 계산은 정확합니다. 만약 순차적 파이프라인이 검색에 약 12초(하위 질문 5개 × 각 2.4초), 분석에 15초, 검증에 8초를 사용했다면, 병렬 버전은 각 단계를 가장 느린 분기의 시간으로 실행합니다. 검색은 약 3초로 줄어듭니다. 분석은 약 4초로 줄어들고. 검증은 약 2초로 줄어듭니다. 모든 것을 진정으로 필요로 하는 합성기는 여전히 약 5초에 머뭅니다. 총합: 약 14초입니다.

Amdahl의 법칙(Amdahl's Law) 한계는 실재하며 중요합니다. LLM 팀을 분산 시스템으로 다룬 2026년 연구는, 직렬 부분(planning, synthesis, merge overhead 등)이 제거될 수 없는 요소이기 때문에, 고도로 병렬화된 조건에서도 속도 향상이 이론적인 Amdahl 한계보다 상당히 낮게 유지됨을 확인했습니다. 제가 달성한 3.2배 감소는 패턴의 실패가 아니었습니다. 그것은 패턴이 설계대로 작동했다는 의미였습니다. 즉, 직렬 부분이 이득을 제한했고, 병렬 부분이 나머지 부분을 담당한 것입니다.

프로덕션 팀들이 실행하는 것들

Microsoft의 Contoso Capital 레퍼런스 아키텍처는 위험 평가(risk assessment) 및 시장 분석 에이전트를 병렬로 실행하여 보고서 생성 시간을 90초에서 25초로 단축했습니다. 이는 3.6배 향상된 수치이며, 그 이유는 각 에이전트가 독립적인 데이터 소스에 대해 작동하고 공유 상태(shared state)가 없기 때문입니다.

LangGraph의 멀티-에이전트 슈퍼바이저(multi-agent supervisor) 벤치마크는 API 키 없이도 6초 만에 재현 가능하며, 결정론적 지연 시간(deterministic latency)에서 1.99배, 실제 HotpotQA에서는 1.31배의 속도 향상을 보여줍니다. 1.99배는 이론적인 최대치입니다. 각 단계가 0.5초씩 걸리는 네 개의 순차적 단계를 가장 느린 단일 단계로 압축한 수치입니다. 실제 실행 결과는 현실 세계의 변동성을 보여주는데, 질문당 속도 향상은 1.05배에서 1.45배 사이를 오갑니다. 이는 각 레이어의 가장 느린 전문가(specialist)가 병목 현상(bottleneck)이 되기 때문입니다.

iFood의 Rosie 지원 에이전트는 독립적인 워크플로우를 병렬화하여 평균 해결 시간을 38분에서 10분으로 줄였고, 케이스의 70%를 완전히 자동화했습니다. 병렬화가 유일한 요인은 아니지만, 대규모로 지연 시간 단축을 가능하게 만든 아키텍처적 동인(architectural enabler)입니다.

생산 배포 연구인 Scalable Inference Architectures for Compound AI Systems는 이전의 정적 배포 방식과 비교하여 **꼬리 지연 시간(tail latency, P95)**이 50% 이상 감소했으며, 처리량(throughput)은 최대 3.9배 향상되었다고 보고합니다. 이 연구에서는 다중 모델 팬아웃 오버헤드(multi-model fan-out overhead)와 연쇄적인 콜드 스타트 전파(cascading cold-start propagation)에 대한 구체적인 분석도 포함했습니다.

생존 가능하게 만든 가드레일(Guardrails)

팬아웃은 공짜가 아닙니다. 순차적 체인에서는 존재하지 않던 실패 모드를 도입하며, 저는 첫 주 동안 이 모든 것을 경험했습니다.

경계 병목 현상(barrier bottleneck). 만약 한 분기가 다른 분기보다 10배 더 오래 걸린다면, 전체 팬인(fan-in)은 그것을 기다려야 합니다. GitHub 벤치마크의 실제 HotpotQA 결과가 이를 정확히 보여줍니다. 가장 느린 전문가가 병목이 되기 때문에 질문당 속도 향상은 1.05배에서 1.45배 사이를 오갑니다. 해결책은 각 분기에 대한 타임아웃(timeout)과 폴백 값(fallback values)을 설정하는 것입니다. 이렇게 하면 느린 분기가 전체 병합(merge)을 막는 대신 부분적인 결과로 저하됩니다.

팬-인 조정(Fan-in reconciliation). 다섯 개의 분석 결과가 동시에 반환될 때, 무엇이 '병합되었다(merged)'는 것을 결정해야 합니다. 저는 동시성 연구에서 설명된 정확한 함정에 빠졌습니다. 두 분기가 동일한 측정 항목에 대해 상충되는 숫자를 반환했고, 합성 에이전트(synthesis agent)가 조용히 그중 하나를 선택했습니다. 해결책은 출처(provenance)가 있는 구조화된 주장(structured claims)입니다. 각 분기는 소스와 타임스탬프가 포함된 스키마 태그 결과(schema-tagged result)를 방출하며, 팬-인(fan-in)은 동일한 불변 키(invariant key)에 대해 상충되는 값을 혼합하는 것을 거부합니다. 중단하고 차이점(diff)을 노출해야 합니다. 그럴듯한 환각(hallucination)보다 큰 실패가 더 저렴합니다.

Promise.all 대신 내구성 있는 팬-아웃(Durable fan-out). 순진한 구현은 Promise.all을 사용합니다. 모든 것을 생성하고, 모든 것을 기다립니다. 이는 지연 시간(latency)을 응축하지만, 배치 중간에 충돌이 발생하면 복구 시 모든 것을 재실행하고, 한 분기의 재시도(retry)는 동일한 부작용(side effect)을 두 번 폭발시킵니다. Resonate의 내구성 있는 팬-아웃은 모든 생성과 모든 기다림을 내구성 있는 약속(durable promise)으로 만듭니다. 하나의 분기가 실패하고 재시도하더라도, 다른 것들은 체크포인트된 상태를 유지하며 재실행되지 않습니다. 충돌 복구는 작업자(worker)가 죽었을 때 진행 중이던 것만 재실행합니다.

읽기 전용 분기(Read-only branches). 공유 상태에 쓰는 팬-아웃 분기는 논리 버그처럼 보이는 경쟁 조건(race conditions)을 도입합니다. 한 분기가 값을 읽고, 다른 분기가 그것을 쓰면, 첫 번째 분기는 오래된 결과(stale result)를 커밋하고, 추적 기록에는 그 경쟁이 전혀 나타나지 않습니다. 각 분기를 자체 상태 슬라이스에 격리(scoping)하고 팬-인에서 명시적으로 병합하면 이러한 유형의 버그 전체를 제거할 수 있습니다.

언제 Fan Out을 사용하지 말아야 하는가 (When Not to Fan Out)

금융 문서 벤치마크의 결과는 정직한 반대급부입니다. 순차적 파이프라인은 대규모에서는 가장 저렴하고 안정적이며, 특히 하루에 10만 개 이상의 문서를 처리할 때는 더욱 그렇습니다. 팬-아웃은 모든 분기가 자체 컨텍스트를 가지고 있기 때문에 토큰 비용을 추가하며, 병합 오버헤드는 분기의 수에 따라 증가합니다.

작업에 진정한 순차적 종속성(serial dependencies)이 있는 경우 순차적으로 유지하십시오. 만약 단계 B가 단계 A의 전체 출력을 필요로 한다면, 병렬화할 수 없는 것을 병렬화하지 마십시오.

지연 시간(latency)이 병목 제약 조건이 아닐 때는 순차적으로 유지하세요. 6분 만에 끝나는 야간 배치 작업은 팬아웃(fan-out)이 필요하지 않습니다. 하지만 45초가 걸리는 사용자 대상 보고서는 다릅니다.

여러 분기(branch)가 공유 상태(shared state)에 쓰기 작업을 할 때는 순차적으로 유지하세요. 쓰기 집약적인 워크로드에서 팬아웃은 발생하기 쉬운 동시성 버그(concurrency bug)를 기다리고 있습니다. 읽기 전용 팬아웃(Read-only fan-out)일 때 이 패턴이 효과를 발휘합니다.

머지 로직(merge logic)이 계산 과정보다 더 복잡할 때는 순차적으로 유지하세요. 다섯 개의 분기 출력을 조정하는 데 걸리는 시간이 그것들을 생성하는 시간보다 길다면, 병목 지점을 제거한 것이 아니라 단지 옮긴 것일 수 있습니다.

과거의 나에게 해주고 싶은 말

순차적 파이프라인 자체가 잘못된 것이 아니었습니다. 제가 잘못된 프레임워크를 사용했기 때문에 문제가 된 것입니다. 문제는 존재하지 않는 의존성(dependency)을 코드로 구현했기 때문입니다. 체인(chain)은