더 많은 병렬 서브에이전트(subagents)가 파이프라인을 더 느리게 만들었습니다. 데이터로 증명합니다.

7번째 서브에이전트(subagent)를 추가하자 오케스트레이터(orchestrator)의 지연 시간(latency)이 22초에서 31초로 늘어났습니다. 이는 제가 예상했던 것과는 정반대의 결과였습니다.

저는 광고 크리에이티브 분석 SaaS에서 팬아웃(fanout) 패턴을 실행해 왔습니다. N개의 서브에이전트를 병렬로 생성하고, 결과를 수집하여 하나의 판결로 병합하는 방식입니다. 병렬 처리 부분은 잘 작동했습니다. 개별 서브에이전트들은 생성된 개수와 상관없이 9~12초 내에 작업을 완료했습니다. 문제는 그 이후의 모든 과정이었습니다.

8개의 서브에이전트가 각각 약 800 토큰(token)의 분석 결과를 반환할 때, 오케스트레이터는 LLM을 단 한 번 호출하기도 전에 6,400 토큰의 컨텍스트(context)를 조립해야 했습니다. Cloudflare Workers 환경에서 8개의 JSON 블롭(blob)을 하나의 프롬프트(prompt) 문자열로 직렬화(serializing)하는 데 첫 API 호출이 발생하기 전 순수 CPU 시간만 4초 이상이 소요되었습니다. 이를 명확히 보여주는 로그 항목은 다음과 같습니다:

[worker:orchestrator] WARN
  aggregate_context_size=52480 bytes
  serialize_duration=4312ms
...

3주간의 프로덕션 데이터를 측정해 본 결과는 다음과 같습니다:

서브에이전트(Subagents)	총 지연 시간(Total latency)	집계 비중(Aggregation share)
2	14.2s	18%
...

6개 이상의 서브에이전트가 사용될 때, 집계(aggregation) 과정이 전체 실행 시간(wall-clock time)의 절반 이상을 차지했습니다. 팬아웃(fanout)은 빨랐지만, 깔때기(funnel)가 병목(bottleneck)이었습니다.

해결책은 병렬성을 줄이는 것이 아니라, 오케스트레이터가 실제로 읽는 내용을 바꾸는 것이었습니다. 집계 LLM 호출에 전체 결과를 전달하는 대신, 이제 각 서브에이전트는 완료 시 R2에 내용을 작성합니다. 오케스트레이터는 에이전트당 세 개의 필드로 구성된 요약 구조체(verdict, confidence, top_signal)만 가져옵니다. 8개의 에이전트가 여전히 8개의 파일을 생성하지만, 집계 컨텍스트는 약 6,400 토큰에서 약 1,100 토큰으로 줄어들었습니다. 해당 파이프라인 단계의 월간 비용은 $207에서 $38로 감소했습니다.

직관에 어긋나는 부분은 바로 이것입니다: 병목은 LLM이 아니었습니다. LLM이 호출되기도 전에 발생하는 컨텍스트 조립(context assembly) 과정이 문제였습니다.

R2 청킹(chunking) 패턴, 폴링(polling) 없이 부분 완료를 추적하기 위한 D1 카운터 접근 방식, 그리고 실패한 집계 재시도를 위한 KV 기반 루프 가드(loop guard)를 포함한 전체 분석 내용은 riversealab.com에 작성해 두었습니다.

Full post →