커서의 AI 에이전트 군집, 저렴한 모델로도 코딩 완수 입증
AI 코드 에디터 커서(Cursor)는 최첨단 고성능 AI 모델이 계획(Planning)을 담당하고 저렴한 모델들이 실제 코딩을 수행하는 '에이전트 군집(Agent Swarm)' 방식을 도입했습니다. 이를 통해 수많은 AI 에이전트가 병렬로 작업하여 방대한 프로젝트를 빠르고 저렴하게 완수할 수 있음을 증명했으며, 1초에 1,000개의 커밋을 처리하는 등 기존 개발 방식의 한계를 뛰어넘었습니다. 이는 향후 소프트웨어 개발 파이프라인이 고성능 모델의 지시와 경제적인 작업 모델의 결합으로 재편될 수 있음을 시사하는 중요한 변화입니다.
커서(Cursor)의 에이전트 군집(Agent swarm)은 최첨단 고성능 모델(frontier models)이 작업을 계획할 때, 더 저렴한 모델들이 대부분의 코딩을 처리할 수 있음을 보여줍니다. 조나단 켐퍼(Jonathan Kemper) / THE DECODER가 작성 (2026년 7월 26일)
커서(Cursor)는 업그레이드된 에이전트 군집을 이전 버전과 경쟁시키는 테스트를 진행했습니다. 두 시스템 모두 소스 코드나 인터넷 접근 없이 오직 공식 문서만 사용하여 SQLite를 러스트(Rust)로 다시 만들도록 지시받았습니다. 그 결과, 새로운 시스템의 모든 구성은 테스트 스위트(test suite)에서 100%의 달성률을 기록한 반면, 이전 버전의 군집은 자체적인 병합 충돌(merge conflicts)에 빠져 제대로 진행하지 못했습니다.
커서에서 에이전트 함대(fleet)는 단순한 연구 프로젝트를 넘어 핵심 제품으로 자리 잡았습니다. 커서 3(Cursor 3)에서는 개발자들이 전체 AI 에이전트 함대를 병렬로 실행할 수 있습니다. 커서를 개발한 Anysphere사는 최근 일론 머스크의 스페이스X(SpaceX)에 600억 달러에 인수되었습니다.
이 시스템은 에이전트를 두 가지 역할로 나눕니다. 강력한 최첨단 모델을 사용하는 '플래너 에이전트(Planner agents)'는 목표를 재귀적으로 더 작은 작업으로 분해합니다. 그리고 더 빠르고 저렴한 모델을 사용하는 '워커 에이전트(Worker agents)'가 해당 작업들을 수행합니다. 그 결과, 작업이 진행됨에 따라 적응하는 '태스크 트리(Task tree)'가 만들어집니다.
커서는 이러한 역할 분담이 주로 문맥(context) 문제를 해결한다고 설명합니다. 단일 에이전트는 전체 트리를 탐색하면서 최종 목표와 현재 작업을 동시에 기억해야 합니다. 이것이 긴 작업 도중 에이전트가 엉뚱한 방향으로 빠지는(drift) 이유를 설명해 줍니다. 커서의 군집 시스템에서는 플래너는 코드를 작성하지 않고, 워커는 계획을 세우지 않습니다.
Git은 초당 1,000개의 커밋을 처리하지 못했다
초기 버전의 커서 브라우저 군집은 Git에서 시간당 약 1,000개의 커밋에 도달했습니다. 당시에는 워커 에이전트, 심사 역할을 하는 판사 에이전트(judge agent), 그리고 충돌을 해결하는 통합자(integrator)를 사용했습니다. 하지만 그 통합자가 제거한 것보다 더 많은 병목 현상을 만들어냈습니다.
새로운 군집은 초당 1,000개의 커밋에 도달했기 때문에, 커서는 자체적인 버전 관리 시스템을 구축해야만 했습니다. 이 속도로 작동하는 에이전트들은 인간 팀이 한 번도 겪어보지 못한 방식의 실패 모드(failure modes)를 만들어냈기 때문입니다. 커서가 명명한 소위 "스플릿 브레인(split-brain) 설계" 상황에서는, 두 명의 플래너가 서로 모르는 채로 같은 아이디어를 다른 장소에 각각 구축하고 서로 다른 방식으로 구현하기도 했습니다. 플래너들이 서로의 존재를 알게 되어 경쟁적인 코드 수정으로 상대방을 차단하려 할 때 충돌을 관리하는 것은 훨씬 더 어려웠습니다.
이를 해결하기 위해 커서는 에이전트들이 자신의 결정을 공유 디자인 문서에 기록하도록 했습니다. 결정과 관련된 코드는 컴파일 타임에 확인되는 참조(reference)를 통해 해당 문서로 다시 연결되었습니다. 병합 충돌이 발생하면 중립적인 에이전트가 개입하여 이를 해결했습니다. 워커 에이전트들은 파일이 너무 비대해지면 표시를 남겼고, 외부 에이전트가 이를 더 작은 모듈로 분할했습니다. 기존 코드베이스에서 인간과 함께 작업할 때 핵심 코드를 건드리지 않도록 학습된 에이전트들에게, 커서는 이번에는 의도적으로 코드를 망가뜨려도 된다고 허용했습니다. 에이전트가 할당된 영역을 벗어난 코드를 패치하더라도, 컴파일러가 시스템 전체에 해당 변경 사항을 전파하는 방식이었습니다.
다각적인 리뷰와 자체 관리되는 필드 가이드
커서는 여러 가지 코드 리뷰 방식을 테스트했습니다. 첫 번째 리뷰어는 워커의 전체 작업 기록(transcript)을 받고, 두 번째는 결과물만 보며, 세 번째는 코드베이스만 확인하는 식이었습니다. 어느 단일 관점도 모든 것을 완벽히 잡아내지는 못했지만, 서로 무관한(uncorrelated) 여러 관점을 결합하면 훨씬 높은 신뢰성을 확보할 수 있었습니다.
또한 커서는 에이전트들이 스스로 유지 관리하며 줄 수 제한이 있는 지식 폴더인 '필드 가이드(field guide)'를 테스트했습니다. 모든 에이전트는 시작될 때 이 폴더의 내용을 전달받았습니다. AI 모델의 가중치(weights)가 고정되어 있기 때문에, 예상치 못한 유용한 발견을 기록해 두면 이후에 작동하는 에이전트들이 지름길을 찾는 데 큰 도움이 되었습니다.
커서는 이 군집에 835페이지 분량의 SQLite 매뉴얼을 제공하고 러스트(Rust)로 구현해 내라고 지시했습니다. 소스 코드, 테스트 스위트, SQLite 바이너리, 인터넷 접속은 모두 차단되었습니다. 벤치마크는 수백만 개의 SQL 쿼리와 정답이 포함된 테스트 스위트인 sqllogictest였습니다. 군집 에이전트들에게는 이 테스트의 존재 자체를 알려주지 않았습니다.
총 네 가지 구성이 테스트되었습니다: GPT-5.5 단독, Grok 4.5 단독, 플래너로 Opus 4.8과 워커로 Composer 2.5를 사용한 조합, 그리고 플래너로 Fable 5와 워커로 Composer 2.5를 사용한 조합이었습니다. 새로운 시스템은 모든 구성에서 이전 시스템을 능가했습니다. 4시간 후, 새 시스템의 실행 결과는 73%에서 85% 사이의 점수를 기록한 반면, 이전 시스템은 11%에서 77% 사이에 머물렀습니다. 이후 새로운 시스템의 모든 구성은 결국 100% 달성률에 도달했습니다.
이전 버전의 군집은 완료한 것보다 더 많은 수정 작업을 스스로 만들어내는 악순환에 빠졌습니다. (Grok 4.5 실행 기준)