'모델 인 더 루프(model-in-the-loop)'에서 '에이전트 인 더 스웜(agent-in-the-swarm)'으로의 전환

우리는 2024년과 2025년 내내 모든 작업에 대해 질의할 거대하고, 비싸며, 신과 같은 LLM인 "프론티어 모델(frontier model)"에 집착하며 시간을 보냈습니다. 우리는 프롬프트(prompt)를 최적화하고, RAG를 적용하고, 캐싱(caching)을 했습니다.

하지만 지금 실제로 일어나고 있는, 지루하지만 영향력이 큰 혁명은 바로 **에이전트 스웜(agent swarms)**으로의 전환입니다.

핵심 전제는 냉혹합니다. 모든 것에 대해 충분히 똑똑한 단 하나의 모델이 필요하지는 않다는 것입니다. 대신, 각각 한 가지 일에 대해서만 충분히 똑똑한 20개의 모델이 필요하며, 이들이 당신을 위해 제품을 구축하도록 조정(coordinated)되어야 합니다.

새로운 모델 경제학

만약 당신이 여전히 에이전트 워크플로(agentic workflow)의 모든 단계에서 거대한 추론 모델(reasoning model)을 실행하려고 한다면, 클라우드 비용 청구서를 잘못 보고 있는 것입니다.

에이전트의 경제학은 "지능에 대한 지불"에서 "병렬 처리량(parallel throughput)에 대한 지불"로 이동하고 있습니다.

1. 작업 분해 (Task Disaggregation): 하나의 모델이 "계획, 검색, 코드 작성, 코드 실행, 검토"를 모두 수행하는 대신, "Planner(계획자)"(작고 저렴함), "Executor(실행자)"(중간 크기, 빠름), 그리고 "Reviewer(검토자)"(매우 똑똑함, 비쌈)를 갖게 됩니다.
2. 80/20 함정: 코딩에서의 대부분의 작업은 프론티어 모델을 필요로 하지 않습니다. 빠르고 신뢰할 수 있는 형식(formatted)을 갖춘 모델이 필요할 뿐입니다. 단순한 단위 테스트(unit-test) 생성에 하이엔드 모델을 사용한다면, 당신은 가치의 90%를 낭비하고 있는 것입니다.
3. 스웜 수율 (The Swarm Yield): 인지적 부담의 90%를 작고 매우 저렴한 모델로 오프로딩(offloading)함으로써, 실제로 추론이 필요한 나머지 10%에 전체 토큰 예산을 쏟아부을 여력을 확보할 수 있습니다.

이것이 "제품으로서의 프론티어(Frontier-as-a-Product)"가 끝나는 이유인 이유

스웜 아키텍처(swarm architecture)로 이동하면, "모델"은 제품이라기보다는 원자재(commodity)처럼 느껴집니다.

만약 당신이 "Executor" 역할에 대해 Qwen, Llama, 또는 Claude를 즉시 교체(hotswap)할 수 있도록 의존성을 구축한다면, 특정 연구소의 API 가격표에 종속되지 않습니다. 당신은 사용하는 특정 모델 엔드포인트(endpoints)가 아니라, 당신의 스웜 아키텍처 주위에 해자(moat)를 구축하게 됩니다.

운영상의 현실

이것은 단순한 이론이 아닙니다. 만약 당신이 오늘날 프로덕션 에이전트(production agents)를 구축하고 있다면:

• 이질성(Heterogeneity)을 고려하여 구축하세요: 단일 모델 시리즈만을 위한 프롬프트 파이프라인(prompt pipelines)을 하드코딩하지 마세요. 작업 유형(task type)에 따라 서로 다른 모델 클래스(model classes)를 사용할 수 있는 인터페이스를 구축해야 합니다.
• 스웜(swarm) 내의 모든 브릿지(bridge)를 계측(Instrument)하세요: 스웜 내의 어떤 모델이 환각(hallucination)을 일으키고 있는지 파악할 수 없다면, 스웜을 디버깅(debug)할 수 없습니다. 플래너(Planner)와 실행자(Executor)를 위한 별도의 지표(metrics)가 필요합니다.
• 로컬(Local) vs 클라우드(Cloud): 둘 중 하나를 선택할 필요는 없습니다. 스웜 내에서 VAD(Voice Activity Detection)나 빠른 텍스트 파싱(text-parsing)을 위해서는 로컬 오픈 모델(open-model)을 사용하고, 최종 단계의 추론(reasoning)을 위해서만 비용이 많이 드는 API를 호출하세요.

내년의 승자는 가장 "똑똑한" 모델을 만드는 기업이 아닐 것입니다. 그들은 자신들이 설계한 스웜을 위한 최고의 **조정 레이어(coordination layers)**를 구축하는 기업이 될 것입니다.

더 똑똑한 모델을 찾는 것을 멈추세요. 더 나은 스웜을 구축하기 시작하세요.

출처: “Agent swarms and the new model economics” (cursor.com).