에이전트 여러 개를 한꺼번에 굴리면 일이 더 꼬입니다. 서로 같은 파일을 건드리고, 같은 아이디어를 중복으로 구현하고, 병합할 때마다 충돌이 쌓이죠. Cursor도 처음엔 이 벽에 부딪혔습니다.

코딩 도구 Cursor가 자사 에이전트 스웜을 다시 설계한 결과를 블로그에 공개했습니다. 똑똑하지만 비싼 모델은 계획만 세우고, 빠르고 저렴한 모델이 실제 코드를 짜는 역할 분리 구조죠. SQLite를 문서만 보고 처음부터 다시 짜게 했더니, 초당 커밋 속도가 기존보다 1,000배 빨라졌습니다.

출처: Agent swarms and the new model economics – Cursor

계획은 프론티어 모델, 실행은 저렴한 모델

Cursor의 새 스웜은 역할이 둘로 나뉩니다. 플래너 에이전트는 가장 똑똑한 모델로 돌아가며 목표를 잘게 쪼개 나눠줍니다. 워커 에이전트는 더 빠르고 저렴한 모델로, 플래너가 나눠준 조각을 실제로 구현합니다.

이 구분이 중요한 이유는 컨텍스트 때문입니다. 에이전트 혼자 큰 작업을 맡으면 전체 작업 트리를 스스로 훑어야 합니다. 상위 목표를 계속 기억하면서 지금 당장의 세부 작업도 놓치지 말아야 하죠. Cursor는 장시간 작업하는 에이전트가 방향을 잃는 이유가 여기 있다고 봅니다. 큰 그림에 집중하면 눈앞의 작업 품질이 떨어지고, 눈앞의 작업에 집중하면 큰 그림을 놓치는 딜레마에 빠진다는 겁니다.

스웜에서는 플래너가 구현을 하지 않으니 컨텍스트가 세부 사항으로 채워지지 않습니다. 워커도 계획을 세우지 않으니 자기가 맡은 좁은 작업 하나에 컨텍스트를 전부 쓸 수 있습니다. Cursor는 스웜이 작업 규모에 관계없이 잘 작동하는 이유를 병렬 작업량 자체보다 이 컨텍스트 효율성에서 찾습니다.

SQLite를 문서만 보고 다시 짜게 했더니

Cursor는 이전 스웜이 실패했던 과제를 다시 꺼냈습니다. 소스 코드도, 테스트 코드도, 인터넷 접속도 없이 835쪽짜리 SQLite 매뉴얼만 주고 Rust로 처음부터 재구현시키는 실험입니다. 채점 기준은 수백만 개의 SQL 쿼리로 구성된 sqllogictest였고, 스웜은 이 테스트의 존재조차 몰랐습니다.

신형 스웜은 모델 조합과 관계없이 구형보다 나은 결과를 냈습니다. Grok 4.5로 돌렸을 때 신형은 4시간 만에 80%를 통과했지만, 구형은 첫 두 시간을 넘기지 못하고 중단해야 했습니다. 프론티어 모델이 계획하고 저렴한 모델이 실행하는 조합이든, 한 모델이 계획과 실행을 다 맡는 조합이든 결과 품질은 비슷했습니다. 다만 비용 차이는 컸습니다.

에이전트 수천 개가 부딪히지 않게 만드는 법

작년에 만든 브라우저 스웜은 시간당 1,000커밋 정도를 기록했습니다. 이번 신형 스웜은 초당 1,000커밋에 도달했죠. 문제는 Git이나 Cargo 같은 기존 도구가 이 속도를 감당하지 못한다는 것이었습니다. 이 도구들은 개발자 한 명이 쓸 땐 문제없는 성긴 잠금 방식으로 동시성을 처리하는데, 에이전트 수백 개가 동시에 코드를 건드리는 규모에서는 감당이 안 됐죠. Cursor는 이 속도를 감당할 자체 버전관리 시스템을 처음부터 새로 만들었습니다.

구형 스웜은 “스플릿 브레인”이라 부르는 문제도 겪었습니다. 서로의 존재를 모르는 두 플래너가 같은 아이디어를 각자 다른 곳에서, 다른 방식으로 구현해버리는 현상입니다. 플래너들이 서로의 존재를 알게 해도 이번엔 서로 경합하는 편집으로 발목을 잡았습니다. 실제로 구형 스웜은 두 시간 동안 6만 8천 개의 커밋을 만들었는데, 신형보다 70배 많은 양이었지만 대부분 낭비된 작업이었습니다. 머지 충돌만 7만 건 넘게 쌓였죠. 신형 스웜은 같은 시간 동안 충돌을 1,000건 아래로 유지했습니다.

Cursor는 이 문제를 에이전트들이 공유 설계 문서에 결정 사항을 기록하게 하는 방식으로 풀었습니다. 특정 결정과 연결된 코드는 컴파일 시점에 확인되는 참조로 그 문서와 연결됩니다. 병합 충돌이 생기면 중립적인 에이전트가 나서서 해결하고, 워커가 비대해진 파일을 발견하면 별도 에이전트가 여러 모듈로 쪼갭니다.

이전 실험과 어떻게 다른가

에이전트 여러 개를 굴릴 때 “설계는 비싼 모델, 실행은 저렴한 모델”에 맡기면 이득이라는 직관은 흔합니다. 하지만 이 조합이 늘 통하는 건 아닙니다. AI 코딩 도구 회사 Stencil은 최근 이 방식이 오히려 14% 더 비쌌다는 결과를 발표했습니다. 비싼 모델이 코드를 읽고 쌓은 맥락을 계획 문서 하나로 압축해 넘기면, 저렴한 모델이 그 압축된 요약만으로는 부족해 같은 파일을 처음부터 다시 읽었기 때문입니다.

Cursor의 실험이 같은 조합에서 다른 결과를 낸 지점은 여기에 있습니다. Cursor의 플래너는 압축된 문서 한 장을 워커에게 던지고 끝내지 않습니다. 작업 트리 자체를 통해 계획을 계속 세분화하고, 워커는 그렇게 잘게 쪼개진 좁은 단위 하나만 맡습니다. 요약본을 해석하는 부담이 애초에 워커에게 넘어가지 않는 구조인 셈입니다. 같은 재료(비싼 모델과 저렴한 모델의 역할 분리)라도 어떤 형태로 작업을 넘기느냐에 따라 비용과 품질이 갈릴 수 있다는 걸 두 실험이 각자 다른 방향에서 보여준 셈입니다.