본문으로 건너뛰기
Community실험 리포트

멀티에이전트 리서치, 넓은 조사만 이기고 좁은 문제는 토큰 6배 낭비

오세훈

@researcher_oh

셋업: 같은 질문을 두 방식으로

내부 리서치 작업 두 종류를 단일 에이전트와 멀티에이전트(오케스트레이터 1 + 워커 5)로 각각 3회씩 돌렸다. A는 넓은 조사("벡터DB 6종을 축별로 정리"), B는 좁은 판단("주어진 제약에서 1종 추천·근거")이다. 품질은 미리 만든 12개 체크포인트 루브릭으로 블라인드 채점하고, 토큰은 API 사용량 로그에서 그대로 읽었다.

숫자

A(넓음): 단일 85k 토큰·71점, 멀티 470k 토큰·82점. 5.5배 태우고 +11점. 벽시계는 4분10초에서 1분40초로 줄었다(병렬 이득 명확). 멀티가 12개 소스 중 3개를 더 찾았다.

B(좁음): 단일 88k·78점, 멀티 540k·76점. 6.1배 태우고 -2점(오차 범위 안). 벽시계는 오히려 2분30초에서 2분50초로 느려졌다. 조율 오버헤드가 병렬 이득을 먹었다.

첫 시도는 더 처참했다. 오케스트레이터가 워커에게 경계를 애매하게 줬더니 워커 2개가 같은 subtopic을 팠고, A 품질이 단일보다 낮게 나왔다. 분해 경계를 조인 뒤에야 멀티가 이겼다.

왜 좁은 문제에서 낭비였나

멀티의 비용은 컨텍스트 복제다. 워커는 매번 콜드 스타트라 공유 작업기억이 없다. 오케스트레이터가 맥락을 각 프롬프트에 다시 요약해 넣고, 워커 출력을 다시 읽어 병합한다. 이 병합이 또 하나의 어려운 추론이고, 그걸 열화된 컨텍스트로 한다.

좁은 문제는 애초에 하나의 추론 사슬이다. 2단계가 1단계 결과에 의존하면 분해는 가짜다. 억지로 쪼개면 병합 단계에서 추론을 다시 하니 토큰만 두 번 낸다.

when-NOT: 쪼개지 말아야 할 때

판단 휴리스틱 하나로 정리했다. 다른 워커의 답을 몰라도 각 서브태스크 프롬프트를 전부 쓸 수 있으면 병렬 가치가 있다. "워커 A가 찾은 걸 전제로…"가 필요하면 순차 의존이니 팬아웃 금지.

멀티를 쓰지 말아야 할 경우:

  • 순차 의존 사슬(step2가 step1 결과를 필요로 함)
  • 좁은 단일 답 문제(추천·진단 하나)
  • 단일 에이전트 컨텍스트에 다 들어가는 작은 문제
  • 병합이 어려운(용어·범위 충돌) 출력
  • 하루 수백 번 도는 배치(토큰 비용이 지배)

손익은 토큰 배수 대 품질 델타로 잰다. 채택 여부는 반복 빈도에서 흑자인지로 갈렸다.

채택? = (품질델타 / 토큰배수)가 태스크 반복빈도에서 흑자인가
# A: +11점 / 5.5배, 일회성 전략 리서치 → 채택
# 배치(200회/일): 같은 델타라도 토큰비용이 지배 → 기각

"병렬이면 빠르다"는 절반만 맞다. 독립 분해가 되는 문제에서만 빠르고, 아니면 조율세만 낸다.

이 글에 대한 Q&A

이 글에 질문하기

이 글에서 궁금한 점이 있다면 먼저 질문을 남겨보세요.

댓글

첫 댓글을 남겨보세요.