How to Get Frontier Coding Results at 70% Lower Cost - Nouha Dziri, Cohere

한 줄 핵심

코딩 에이전트를 여러 개 쓰면 단일 에이전트보다 더 높은 성능을 낼 수 있지만, 실제로는 어떤 단계에 몇 명을 배치하느냐가 성능과 비용을 좌우하며 특히 병목 단계에 강한 리더를 두고 값싼 워커를 쓰는 구성이 가장 효율적이다.

시간별 요약

1. 0:00
   멀티 에이전트는 새 추론 축이지만 비용이 급격히 커진다 단일 에이전트를 오래 생각하게 하거나 여러 번 샘플링하는 방식은 긴 코딩 작업에서 컨텍스트 폭증과 지연 문제를 피하기 어렵다. 일을 나눠 여러 coding agent가 팀으로 처리하면 더 빨리 풀 수 있지만, 팀이 커질수록 토큰 비용과 조정 비용이 함께 커진다.
2. 3:01
   팀 구조와 지휘 방식이 성능을 크게 바꾼다 리더-워커 계층 구조, 직접 통신 허용 여부, 팀 크기, 모델 배치, 계획·구현·검증 중 어디에 자원을 둘지가 결과를 좌우한다. 최소 프롬프트만 주면 비효율이 크지만, 리더에게 협업 규칙과 단계별 역할을 명확히 주면 async 구성도 개선되어 팀 성능이 단일 에이전트를 앞선다.
3. 11:00
   병목은 계획 단계였고, 그곳에 에이전트를 넣을 때 가장 이득이 컸다 Program Bench에서는 블랙박스 실행 파일의 동작을 먼저 추적하고 계획을 세우는 단계가 핵심 병목이어서, 계획용 워커를 늘렸을 때 단일 에이전트와 비슷한 성능을 절반 비용으로 달성했다. 반대로 구현이나 검증 단계에 워커를 더 붙여도 성능 향상은 거의 없고 비용만 늘어났다.
4. 19:02
   리더는 강하게, 워커는 싸게 두는 구성이 가장 유리하다 lead로 강한 모델을 유지하고 worker에는 더 저렴한 모델을 쓰면, 성능은 거의 유지하면서 비용을 크게 낮출 수 있다. 팀 크기를 계획 단계에 집중해 키우면 70%까지 비용을 줄이면서도 frontier 수준에 근접할 수 있지만, 약한 리더는 저렴한 워커로도 보완되지 않는다.
5. 23:01
   통신은 대부분 상향식 보고에 머물렀고, 안전성과 확장성이 다음 과제다 실제로는 워커끼리 직접 협업하기보다 대부분 리더에게만 보고하는 구조가 형성되었고, 추가 메시징은 종종 성능 향상 없이 오버헤드만 늘렸다. 앞으로는 수백~수천 개 에이전트의 자기조직화, 더 효율적인 통신 방식, 그리고 자율 실행 팀의 보안·정렬 문제가 핵심 연구 과제가 된다.

실무 인사이트

• 멀티 에이전트 최적화의 핵심은 '몇 명을 쓸까'보다 '어느 단계의 병목을 풀까'에 있다.
• 실무에서는 강한 오케스트레이터 1명과 저렴한 실행 워커 조합이 가장 먼저 검토할 만한 비용 최적화 패턴이다.
• 워커 간 직접 소통을 늘리기 전에, 먼저 역할 경계와 단계별 책임을 명확히 설계해야 중복 작업과 비용 폭증을 줄일 수 있다.