에이전트 111개를 풀자 주간 한도가 30분 만에 사라졌습니다 — 멀티에이전트의 핵심은 역할 분리

핵심 요약 (TL;DR)

Quesma 엔지니어 Bartosz Kotrys의 멀티모델 딥리서치 파이프라인은 첫 실행에서 에이전트 111개를 동시에 풀어 30분 만에 Claude 주간 토큰 한도를 소진했습니다. 검증을 통과한 주장은 123개 중 25개뿐이었습니다. 역할 분리로 재설계한 최종판은 에이전트 61개·22분으로, 추가 구독료 없이 약 10배 긴 리서치를 수행합니다.

토큰을 아끼는 방법을 연구하다가 일주일치 토큰을 다 태운 엔지니어가 있습니다. 바르샤바의 DB 게이트웨이 스타트업 Quesma의 Bartosz Kotrys는 Claude Code, Codex(GPT-5.5), Gemini 3.1 Pro를 공유 메모리로 엮은 딥리서치 파이프라인을 만들었습니다(quesma.com/blog/custom-deep-research-pipeline). 이 여정은 HN 88포인트, 댓글 126개의 토론으로 이어졌습니다(news.ycombinator.com/item?id=48967355).

왜 30분 만에 일주일치 토큰이 증발했을까요?

첫 실행에서 에이전트 111개가 동시에 풀렸습니다. 30분 뒤 주간 한도가 바닥났고, 산출물의 품질은 더 뼈아팠습니다. 파이프라인이 뽑아낸 주장 123개 중 검증을 통과한 건 25개. 나머지는 자신감 있게 서술된 비검증 주장이었습니다.

컴팩션 설정 실수도 있었습니다. 설정 하나가 어긋나자 세션당 토큰이 8,900만에서 1억 6천만~1억 8,500만으로 폭증하는 회귀가 기록됐습니다. 수도꼭지 잠그는 법을 배우기 전에 배관 전체가 터진 셈이죠.

무엇을 바꿔서 10배를 얻었을까요?

핵심은 에이전트 수를 줄인 게 아니라 모델별 역할을 나눈 겁니다. 최종판의 구조는 이렇습니다.

• Claude Code가 전체 오케스트레이션, Fable 5는 판단과 계획 담당
• Sonnet 5가 조사, Opus 4.8이 검증, Haiku 4.5가 추출
• 조사 결과는 반드시 검증 에이전트를 거치도록 검증 규칙을 파이프라인 단계로 명시
• 토큰을 크게 태우는 딥리서치는 파이프라인 마지막에 배치

결과는 에이전트 61개, 실행 22분. 저자 표현으로 "추가 비용 없이" 약 10배 긴 리서치가 가능해졌습니다. 모든 단계를 최고 모델에 맡기는 건 설계가 아니라 회피입니다. 추출처럼 값싼 일은 Haiku급에, 판단처럼 오류 비용이 큰 일만 상위 모델에 — 이 배분이 파이프라인의 실력인 거죠.

우리 워크플로에는 어떻게 적용할까요?

구독 한도가 아까워서 "일단 크게" 돌려보고 싶은 유혹은 파워유저라면 누구나 느낍니다. 이 사례의 결론은 명확합니다. 에이전트가 일하되, 파이프라인은 인간이 계속 다듬는 하이브리드가 답이라는 것. 자동화는 한 번 만들고 끝나는 게 아니라, 회귀를 잡아가며 기르는 것에 가깝습니다. 토큰 한도는 제약이 아니라 설계를 강제하는 좋은 선생인지도 모릅니다.

FAQ

Q. 에이전트를 많이 풀면 리서치 품질이 좋아지지 않나요?
이 사례에서는 반대였습니다. 111개 병렬 실행의 검증 통과율은 123개 중 25개였고, 역할을 분리한 61개 구성이 더 나은 결과를 냈습니다.

Q. 어떤 작업을 값싼 모델에 맡겨야 하나요?
정형화된 추출·요약은 Haiku급으로 충분합니다. 계획·판단·검증처럼 오류 비용이 큰 단계에만 상위 모델을 쓰는 게 이 파이프라인의 배분 원칙입니다.

Q. 컴팩션 설정이 왜 중요한가요?
장기 세션의 컨텍스트 압축이 어긋나면 같은 작업의 토큰 소비가 배로 뜁니다. 이 사례에서는 세션당 8,900만 토큰이 최대 1억 8,500만까지 늘었습니다.

여러분의 파이프라인에서 지금 Opus가 하고 있는 일 중, Haiku에 넘겨도 아무도 모를 일은 몇 개나 될까요?