에이전트 군집(swarm)과 새로운 모델 경제학

https://cursor.com/en-US/blog/agent-swarm-model-economics#1000

올해 초에 저희는 에이전트를 하나의 목표를 향해 협력하도록 확장할 때 어디까지 가능한지 실험해 보았습니다. 이렇게 하면 지금까지와는 다른 규모와 복잡도의 작업을 다룰 수 있게 될 것이라고 가정했습니다.

가장 대표적인 프로젝트는 웹 브라우저를 처음부터 만드는 장기 실행 군집이었습니다. 개념 증명으로는 성공했지만, 완성도 있는 소프트웨어에는 한참 못 미쳤습니다.

그 작업은 의도적으로 경험에 의존했습니다. 아무것도 없는 상태에서 출발해 안정적이고 효과적인 시스템에 도달할 때까지 조금씩 개선해 나갔습니다. 그 뒤로 저희 목표는 에이전트 군집을 의도한 대로 설계할 수 있을 만큼 깊이 이해하는 것이었습니다.

그동안의 진전을 확인하려고, 이전 군집이 고전했던 과제로 다시 돌아갔습니다. 문서만 가지고 SQLite를 러스트로 처음부터 만드는 일입니다.

초기 결과는 기대할 만했습니다. 같은 과제에 같은 모델과 같은 시간 예산을 주고 이전 군집과 새 군집을 각각 돌린 뒤, 미리 감춰 둔 SQL 테스트 스위트를 얼마나 통과하는지 측정했습니다.

새 군집은 모든 모델 구성에서 더 좋은 성적을 냈습니다. Grok 4.5를 쓴 경우 네 시간에 80%에 도달했지만, 이전 군집은 통제를 잃고 헤매다가 두 시간이 되기도 전에 중단해야 했습니다.

어떤 모델이 어떤 역할을 맡을지도 바꿔 보았습니다. 한 모델이 전부 처리한 실행도 있었고, 프런티어 모델이 계획을 세우고 빠르고 저렴한 모델이 실제 작업을 수행한 실행도 있었습니다. 조합마다 품질은 비슷했지만 비용은 엄청나게 차이가 났습니다.¹

이전 에이전트 군집과 새 군집에서 모델 조합별로 SQLite를 다시 만드는 데 든 비용

나무와 잎

큰 작업을 설명하다 보면 자연히 나무 모양이 됩니다. 뿌리에 목표가 있고, 그것이 재귀적으로 쪼개져 가장 작은 작업 단위까지 내려갑니다. 저희 군집에는 역할이 두 가지 있는데, 둘 다 이 나무 모양 분해를 그대로 따릅니다.

• 계획 에이전트(planner)는 가장 똑똑한 모델이 담당하며, 목표를 조각으로 나눠 아래로 위임합니다.
• 작업 에이전트(worker)는 대체로 더 빠르고 저렴한 모델이 담당하며, 그 조각들을 실행합니다.

이 설계는 더 경직된 오케스트레이션 시스템을 모두 품는 상위 집합입니다. 문제에 고정된 구조를 억지로 씌우는 대신, 군집의 모양이 문제의 윤곽에 맞춰 자라납니다. 그래서 연산량과 컨텍스트도 작업의 복잡도에 비례해 늘어납니다.

저희는 이 덕분에 브라우저 만들기, 수학 문제 풀기, GPU 커널 최적화처럼 서로 다른 작업에까지 이 설계가 두루 통한다고 봅니다. 내부적으로는 오픈소스 소프트웨어의 취약점을 찾아 고치고, 자체 코드베이스의 테스트 커버리지를 올리고, 수십억 토큰 규모의 합성 학습 데이터를 만드는 데도 써 왔습니다.

나무 구조가 기억에 해 주는 일

에이전트 하나가 작업 전체를 맡으면, 그 나무를 처음부터 끝까지 직접 걸어야 합니다. 잎 하나하나까지 내려가는 동안 상위 노드들과 현재 위치, 그리고 더 큰 목표를 계속 컨텍스트에 담고 있어야 합니다.

장시간 돌아가는 단일 에이전트가 방향을 잃는 이유가 여기 있다고 봅니다. 눈앞의 작업에 집중하면 큰 그림을 놓치고, 큰 그림을 붙들고 있으면 개별 조각을 더 엉성하게 처리합니다.

군집에서는 계획 에이전트가 직접 구현하지 않으므로 컨텍스트가 세부 구현으로 채워지지 않고, 작업 에이전트는 계획을 세우지 않으므로 컨텍스트 전부를 좁은 작업 하나에 쓸 수 있습니다.

작업 트리에서 계획 에이전트와 작업 에이전트로 일을 나누는 과정을 나타낸 도식

에이전트 군집을 확장할 수 있는 힘은 병렬 처리 자체보다 이 컨텍스트 효율에서 나온다고 짐작합니다. 이 효율은 규모와 무관하게 군집 어디에나 있고, 그래서 중간 규모 작업에서도 이런 분해가 에이전트 성능에 도움이 됩니다.

비슷한 구조는 다른 데서도 보입니다. 경제학자 로널드 코스는 기업이 왜 존재하는지 물으면서, 조정 비용이 일 자체보다 빠르게 늘어나기 때문에 조직은 모두가 모두와 이야기하도록 두지 않고 크기가 제한된 단위를 여러 층으로 쌓는 형태로 자리 잡는다고 주장했습니다.

에이전트를 위한 버전 관리 시스템

군집을 다룬 이전 글에서 저희는 Git이나 Cargo 같은 도구가 동시성 제어를 위해 굵은 단위의 잠금에 의존한다고 지적했습니다. 개발자 한 명에게는 충분하지만, 수백 개 에이전트가 동시에 쏟아내는 작업량에는 감당이 안 됩니다.

올해 초 브라우저 군집은 Git에서 시간당 1,000커밋 정도가 정점이었습니다. 새 시스템은 초당 1,000커밋 정도가 정점입니다.

이 정도 활동량을 뒷받침하려고 버전 관리 시스템(VCS)을 처음부터 새로 만들었습니다. 이 계층을 직접 소유한 이유가 처리량 하나만은 아닙니다. 시스템의 모든 변경이 VCS를 거치기 때문에 충돌이 가장 먼저 드러나는 곳이 바로 여기이고, 다음 절에서 설명하는 조정 장치 중 몇 가지는 VCS 안에 직접 구현했습니다.

초당 1,000커밋에서 나타나는 실패 양상

사람으로 이뤄진 엔지니어링 팀에는 코드 리뷰, 담당자 지정, 스탠드업, 머지 큐 같은 표준 조정 장치가 있습니다. 이런 장치는 사람의 속도에서는 잘 작동하지만, 군집의 커밋 속도에서는 사람 팀이 평소에 겪지 않는 실패 양상이 나타납니다.

설계가 두 갈래로 갈리는 문제

서로의 존재를 모르는 계획 에이전트 둘이 같은 개념을 코드베이스의 서로 다른 곳에 다른 방식으로 구현합니다.

이 문제는 프롬프트로 해결했습니다. 계획 에이전트는 설계 결정을 아래로 위임하지 않고 직접 내리며, 위임한 두 하위 트리가 같은 질문을 각각 결정하는 일이 없도록 보장하게 했습니다.

계획 에이전트 사이의 경합

더 까다로운 경합은 계획 에이전트 둘이 서로를 알면서도 같은 파일을 두고 변경을 주고받으며 싸우는 경우입니다.

현실을 보는 그림이 둘로 갈렸다는 게 문제이고, 병합 도구는 의견 충돌을 해결해 주지 못합니다. 그래서 에이전트가 결정 사항을 공유 설계 문서에 기록하도록 했습니다. 어떤 결정에 의존하는 코드는 그 문서를 가리키는 참조를 갖고, 이 참조는 컴파일 단계에서 검사됩니다. 계획 에이전트들이 자기도 모르게 서로 모순되는 결정을 내리면, 조정 에이전트가 문서들을 병합하고 참조를 통해 그 결론이 아래쪽으로 전파됩니다.

병합 충돌

군집 안에서 에이전트들은 같은 파일에서 끊임없이 부딪칩니다. 충돌을 풀려면 작업을 멈추고 상대 에이전트의 맥락을 흡수한 뒤 그에 맞춰 병합해야 합니다. 작업 에이전트는 이 일을 잘 못해서, 실제로는 상대의 변경을 덮어쓰거나 자기 변경을 포기해 버립니다.

이 문제를 해결하려고, 중립적인 제3의 에이전트가 병합 충돌에 개입해 관련된 모두를 대신해 충돌을 정리하는 구조를 만들었습니다. 이 에이전트의 목표는 공정하고 효율적으로 처리하는 것 하나이며, 엔지니어링 팀에서 머지 큐가 하는 역할과 비슷합니다.

거대 파일

어떤 파일은 에이전트들이 특히 많이 몰려서 작업하는 곳이 됩니다. 각 에이전트가 추가하는 코드는 얼마 안 되지만, 그 파일을 작게 유지할 책임을 진 에이전트는 아무도 없습니다.

이렇게 생긴 '거대 파일(megafile)'은 모든 것을 막아 세웁니다. 전송하고 차이를 계산하고 병합하는 비용이 크고, 충돌이 끊이지 않는 지점이 됩니다.

이를 해결하려고 작업 에이전트가 비대해진 파일을 신고할 수 있게 했습니다. 신고가 들어오면 새 커밋을 막고, 외부 에이전트가 지나치게 커진 파일을 더 작은 모듈로 쪼갭니다.

굳어 버리는 코드

에이전트들은 사람이 함께 관여하는 기존 코드베이스에서 일하면서, 핵심 코드는 바꿔야 할 때조차 건드리지 않는 습성을 익혔습니다.

이를 해결하려고 의도적으로 깨뜨리는 일을 허용했습니다. 핵심 코드를 바꿀 만하다고 판단한 에이전트는 자기 범위를 벗어나서라도 좁은 범위의 패치를 넣고, 왜 그렇게 했는지 설명하는 주석을 남길 수 있습니다.

컴파일러가 그 변경을 시스템 나머지로 퍼뜨리면, 이전 설계에 의존하던 모든 코드가 빌드에 실패합니다. 그 오류를 만난 에이전트는 각자 주석을 찾아 이유를 읽고, 자기 작업을 그에 맞게 고칩니다.

리뷰의 여러 시선

장시간 돌아가면서 여러 에이전트가 참여하는 시스템에서는 오류가 쌓입니다. 그래서 군집은 작은 실수가 토대로 굳어 버리기 전에 스스로 바로잡을 방법이 필요합니다.

리뷰 에이전트에게 작업 에이전트의 전체 대화 기록을 주거나, 결과물만 주거나, 코드베이스만 주는 식으로 여러 종류의 시선을 실험했습니다. 학습 내용과 성향이 다른 모델로 리뷰어를 돌려 보기도 했습니다.

어느 시선 하나로 모든 문제를 잡아내지는 못하지만, 서로 상관관계가 낮은 시선들은 겹쳐 쌓입니다. 자율주행 시스템이 완벽한 부품 하나 없이도 사람보다 높은 신뢰도에 이르는 것과 같은 원리입니다. 리뷰에 쓰는 연산은 수익률이 높습니다. 리뷰가 그 대상인 작업보다 훨씬 싸기 때문입니다. 이렇게 겹쳐 쌓은 리뷰 체계가 실행 내내 품질을 유지한 큰 이유였다고 짐작합니다.

에이전트가 환경을 바꾸게 하기

스티그머지는 개미나 흰개미처럼 군집을 이루는 생물이 직접 소통하지 않고도 서로 조율하는 방식입니다. 이들이 환경을 바꾸고, 그 환경이 다음 개체의 행동을 바꿉니다.

이전 실행에서는 '메모를 남겨라', '결정을 문서화하라' 같은 규칙을 당연히 좋아 보인다는 이유로 넣어 두었습니다. 돌아보면 이 규칙들은 에이전트가 미래의 자신과 동료를 위해 지식을 제도화하게 만들고 있었습니다.

여기서 한 걸음 더 나아가, 에이전트가 스스로 쓰는 공유 컨텍스트를 실험했습니다. 저희는 이것을 필드 가이드(Field Guide)라고 부릅니다. 전적으로 에이전트가 소유하는 폴더이고, 그 안의 index.md는 모든 에이전트가 시작할 때 자동으로 주입됩니다. 가이드에 무엇을 담을지 정리하는 일은 에이전트의 몫이며, 유일한 제약은 줄 수 예산입니다.

이 가이드의 논리는 모델 가중치가 고정돼 있다는 데서 출발합니다. 그러니 기록할 가치가 있는 것은 바로 예상 밖의 일이고, 그래야 다음 에이전트가 더 짧은 경로로 갈 수 있습니다.

필드 가이드는 아직 초기 실험이지만 결과는 기대할 만합니다. 에이전트가 완전히 소유하지 않은 코드베이스에서는 효과가 더 클 것으로 봅니다. 더 잘 기록할수록 더 큰 보상을 받게 해서 모델이 후임자를 위해 쓰도록 학습시키는 것은 흥미로운 후속 연구 주제입니다.

SQLite 실험

위에서 설명한 개선을 모두 갖춘 새 군집에, 835쪽짜리 SQLite 설명서 전체를 러스트로 구현하라고 지시했습니다. 소스 코드와 테스트 스위트, SQLite 바이너리, 인터넷 접근은 모두 차단했습니다.

진척을 측정하려고 sqllogictest로 채점했습니다. SQLite 프로젝트에서 만든 테스트 스위트로, 서로 다른 데이터베이스 엔진이 같은 질의에 같은 결과를 돌려주는지 확인하는 용도입니다. 정답이 알려진 질의가 수백만 개 들어 있고, 점수는 군집이 만든 데이터베이스가 맞힌 비율입니다. 진척은 실행이 진행되는 동안 올라가는 곡선으로 나타납니다.

군집에는 이 테스트 스위트가 있다는 사실조차 알리지 않았습니다. 실행이 끝날 때마다 코드와 실행 과정을 직접 살펴보며 부정행위나 편법이 없는지 확인하고, 테스트가 들여다보는 부분만이 아니라 시스템이 고르게 구축됐는지 검증했습니다.

곡선을 볼 때는 에이전트가 전략을 스스로 골랐다는 점을 기억해 주십시오. 어떤 에이전트는 넓은 토대를 먼저 쌓아서 몇 시간 동안 낮은 점수에 머물다가 뒤늦게 급등했고, 어떤 에이전트는 한 영역을 깊게 파서 일찍 점수를 올린 뒤 나머지를 채우는 동안 정체했습니다. 특정 시점의 정확한 점수보다 추세가 더 중요합니다.

모델 조합별 결과

성능과 비용을 아우르는 네 가지 구성을 시험했습니다.

1. GPT-5.5를 계획과 작업 양쪽에 사용. 처음부터 끝까지 강력한 프런티어 모델을 쓰는 구성입니다.²
2. Grok 4.5를 계획과 작업 양쪽에 사용. 비용 효율이 좋은 프런티어 모델을 비교 기준으로 삼았습니다.
3. Opus 4.8을 계획에, Composer 2.5를 작업에 사용. 프런티어 모델의 판단력과 효율적인 실행을 짝지었습니다.
4. Fable 5를 계획에, Composer 2.5를 작업에 사용. 한 단계 위의 계획 모델이 이 혼합 구성을 더 유리하게 만드는지 아닌지 보려고 했습니다.

새 하네스는 모든 조합에서 이전 하네스를 앞섰습니다.

Fable 5 혼합 구성은 첫 한 시간 안에 테스트 스위트의 약 3분의 2를 통과했습니다. 네 시간 마감 시점에 새 실행들은 73%에서 85% 사이였고, 이전 실행들은 11%에서 77%까지 흩어져 있었습니다.

이전 하네스의 Grok 4.5 실행은 두 시간이 되기 전에 중단했습니다(자세한 내용은 아래에 있습니다). 새 구성은 모두 결국 테스트 스위트를 100% 통과했습니다.

앞으로는 계획 모델과 작업 모델의 조합을 N×N 전체 행렬로 돌려 보고 싶습니다. 이번 주기에서 중요한 비교는 하네스 버전 사이의 차이였고, 실제 동작의 차이는 점수 차이가 보여 주는 것보다 훨씬 컸습니다.

이전 군집과 새 군집에서 GPT-5.5의 시간별 SQLite 테스트 스위트 점수

이전 군집과 새 군집에서 Grok 4.5의 시간별 SQLite 테스트 스위트 점수

Opus 4.8이 계획하고 Composer 2.5가 작업한 구성의 시간별 SQLite 테스트 스위트 점수

Fable 5가 계획하고 Composer 2.5가 작업한 구성의 시간별 SQLite 테스트 스위트 점수

실행 과정 깊이 들여다보기

가장 단순한 활동 지표부터 보면, 이전 하네스와 새 하네스에서 Grok 4.5의 커밋 속도가 어떻게 달랐는지 알 수 있습니다. 이전 실행은 첫 두 시간에 커밋 6만 8,000개를 만들었는데, 새 실행보다 약 70배 빠른 속도입니다.

이것을 더 생산적이었다고 읽을 수도 있습니다. 반대로 그 커밋 대부분이 헛일이었다고 읽을 수도 있습니다. 즉 뒤엉킴과 경합, 무의미한 반복이었다는 해석입니다.

이전 하네스와 새 하네스에서 Grok 4.5의 활동 시간에 따른 누적 커밋 수

병합 충돌 데이터는 뒤쪽 해석을 가리킵니다. 이전 실행은 중단하기 전까지 충돌을 7만 건 넘게 쌓았고, 안정되기는커녕 오히려 빨라졌습니다. 반면 새 실행은 네 시간 전체에서 충돌을 1,000건도 기록하지 않았습니다.

이전 하네스와 새 하네스에서 Grok 4.5의 시간별 누적 병합 충돌 수

충돌은 파일이 가장 커진 곳에 몰렸습니다. 이전 실행에서는 큰 파일들이 실행이 끝날 때까지 계속 커졌고, 가장 뜨거웠던 파일 하나에 충돌 7,771건이 쌓였으며 서로 다른 에이전트 1,173개가 그 파일을 건드렸습니다. 새 실행에서는 코드베이스 전체에서 가장 많이 다툰 파일의 충돌이 47건이었습니다.

이전 하네스와 새 하네스에서 Grok 4.5의 실행 진행에 따른 최다 충돌 파일의 코드 줄 수

이전 군집의 가장 큰 조정 실패, 즉 설계가 두 갈래로 갈려 계획 에이전트들이 서로의 작업을 중복하는 문제는 패키지 구조에서 드러났습니다. 러스트 코드는 크레이트(crate)라는 패키지 단위로 묶이는데, 이런 프로젝트에서 크레이트 하나는 대체로 주요 구성 요소 하나에 해당합니다.

이전 실행은 크레이트가 54개까지 불어났고, 그중에는 별도의 SQL 패키지가 세 개나 있었습니다. 새 실행은 이른 시점에 크레이트 아홉 개로 정리한 뒤 하나도 더 추가하지 않았습니다.

이전 하네스와 새 하네스의 Grok 4.5 SQLite 실행에서 시간에 따른 러스트 크레이트 개수

이 모든 차이가 최종 코드베이스에 그대로 나타납니다. Fable 5 조합에서는 이전 군집과 새 군집이 결국 둘 다 테스트 스위트를 전부 통과했지만, 이전 군집은 엔진 코드 6만 4,305줄이 필요했고 새 군집은 9,908줄로 해냈습니다. Opus 조합도 같은 양상입니다. 이전 하네스에서는 1만 9,013줄로 97%였고, 새 하네스에서는 4,645줄로 100%였습니다.

이전 하네스와 새 하네스에서 SQLite 실험을 완수하는 데 필요했던 엔진 코드 줄 수

모델 경제학

글 앞에서 모델 조합마다 품질은 비슷했지만 비용은 엄청나게 차이가 났다고 했습니다. Opus 4.8 혼합 구성은 1,339달러였고, GPT-5.5만 쓴 구성은 1만 565달러였습니다. 토큰 데이터를 보면 그 차이가 어디서 오는지 알 수 있습니다.

지출 구조는 모든 실행에서 비슷했습니다. 작업 에이전트가 토큰의 최소 69%를 감당했고, 대부분의 실행에서는 90%를 넘었습니다.

그런데 계획 에이전트의 토큰이 더 비싸기 때문에, 금액은 토큰과 다르게 나뉩니다. Opus 4.8과 Composer 2.5를 섞은 구성에서 계획을 맡은 Opus는 토큰은 일부만 썼는데 비용은 약 3분의 2를 차지했고, 작업을 맡은 Composer는 토큰 대부분을 처리하면서 남은 3분의 1만 썼습니다.

SQLite 군집 구성별로 계획 에이전트와 작업 에이전트가 각각 사용한 토큰 양

큰 작업에서 정말로 프런티어 수준의 지능이 필요한 순간은 몇 군데뿐입니다. 처음의 작업 분해, 설계 결정, 그리고 몇 가지 절충 판단이 그렇습니다. 프런티어 계획 모델이 모호함을 걷어 내고 구체적이고 명시적인 지시로 정리해 주면, 더 저렴한 모델은 그 지시를 따르기만 하면 됩니다. 여기서 비용을 크게 아낄 여지가 생깁니다. 계획과 작업 모두에 GPT-5.5를 쓴 실행에서는 작업 에이전트만으로 9,373달러가 들었습니다. Opus 4.8이 계획을 세우고 Composer 2.5가 작업을 수행한 실행에서는 작업 에이전트 전체가 411달러였습니다.

두 혼합 구성을 비교하면 눈여겨볼 점이 하나 있습니다. Fable 5 계획 모델은 토큰당 가격이 Opus 4.8의 약 두 배인데도 청구액은 조금 더 적었습니다. 계획에 쓴 토큰이 훨씬 적었기 때문입니다. 그런데 Fable 실행의 작업 에이전트는 토큰을 몇 배나 더 썼고, 그래서 실행 전체로는 비용이 훨씬 많이 나왔습니다.

명세가 곧 프롬프트

AI 성능이 한 단계씩 뛸 때마다 엔지니어가 일하는 추상화 수준도 함께 올라갔습니다.

자동 완성은 엔지니어가 코드 한 줄 단위로 일하게 해 주었습니다. 초기 모델은 그 단위를 코드 블록으로 올렸고, 에이전트는 파일이나 기능 단위까지 올렸습니다.

군집에 이르면 작업 단위가 명세가 됩니다.

그렇게 되려면 군집이 명세를 실제로 따라야 하고, 이 글의 상당 부분이 바로 그 이야기입니다. 저희는 군집에 산문 835쪽을 주었고, 군집은 데이터베이스를 만들어 왔습니다. 이 실험에서 부족했던 것, 그리고 앞으로 소프트웨어 엔지니어링에서 부족해질 것으로 보는 것은 의도를 제대로 기술하는 일입니다.

이렇게 보면 군집은 컴파일러와 닮아 보입니다. 컴파일러는 여러 중간 단계를 거쳐 소스 코드를 기계어까지 내려 번역합니다. 군집은 의도를 두고 비슷한 일을 합니다. 계획 에이전트가 목표를 작업 트리로 파싱한 다음, 단계마다 한 층씩 낮춰 실행 가능한 작업으로 만듭니다. 차이는 컴파일러가 모든 단계에서 의미를 그대로 보존하는 데 비해 군집은 모든 단계가 확률적이라는 점입니다. 이 글에서 설명한 모든 장치는 그 간격을 좁히기 위해 존재합니다.

군집이 만들어 낸 결과물을 직접 살펴보시기 바랍니다. Opus 4.8 단독 실행에서 나온 코드베이스는 github.com/cursor/minisqlite에 공개해 두었습니다. 처음 훑어본 인상은 좋았지만, 사람이 더 깊이 분석해 보지는 않았습니다. 직접 들여다보고 무엇을 발견했는지 알려 주십시오.