Cursor Agent Swarm은 대형 코딩 작업을 플래너(planner)와 워커(worker) 에이전트로 나눠 실행하는 Cursor의 멀티 에이전트 하네스 구조다. 핵심은 병렬 실행 자체보다 컨텍스트 책임을 나누는 데 있다. 프론티어 모델은 목표 분해와 설계 판단을 맡고, 더 빠르고 저렴한 모델은 작은 작업을 실행한다.

왜 중요한가

긴 코딩 작업에서 단일 에이전트는 전체 목표, 현재 파일, 이전 결정, 테스트 결과를 모두 같은 컨텍스트 안에서 유지해야 한다. 이 구조는 시간이 지날수록 드리프트, 중복 구현, 충돌을 만든다.

Cursor의 새 스웜은 역할을 분리한다.

이 분리는 agent-harness에서 말하는 컨텍스트 정책, 작업 분해, 검증 루프를 제품 수준으로 밀어붙인 사례다.

SQLite 재구현 실험

The Decoder가 정리한 Cursor 실험은 SQLite 835쪽 매뉴얼만 제공하고, 소스 코드·인터넷·테스트 스위트를 차단한 상태에서 Rust 구현을 만들게 했다. 평가는 sqllogictest로 수행됐다.

주요 결과:

• 새 스웜의 모든 구성은 최종적으로 테스트 100%에 도달했다.
• 4시간 시점에서 새 구조는 73~85%, 기존 구조는 11~77%에 머물렀다.
• 기존 Grok 4.5 스웜은 2시간 동안 6만 8천 커밋과 7만 개 이상 merge conflict를 만들었지만, 새 구조는 충돌을 1천 개 이하로 유지했다.
• Opus 플래너 + Composer 워커 구성은 전체 비용이 약 1,339달러였고, GPT-5.5 단독 구성은 약 10,565달러였다.

설계상 교훈

1. 병렬화보다 책임 경계가 먼저다

에이전트를 많이 띄우는 것만으로는 성능이 오르지 않는다. 같은 설계를 서로 다른 파일에 중복 구현하는 split-brain 문제가 생긴다. 플래너는 설계 문서를 만들고, 워커는 그 결정에 링크된 코드를 작성하는 식의 추적 가능한 경계가 필요하다.

2. Git은 인간 협업 속도에 맞춰져 있다

Cursor는 새 스웜이 초당 1천 커밋 수준에 도달하자 자체 버전 관리 계층을 만들었다고 설명한다. 에이전트 스웜은 사람 팀보다 훨씬 높은 빈도로 작은 변경을 만들기 때문에, 기존 Git conflict resolution만으로는 병목이 된다.

3. 리뷰 관점은 상관관계가 낮아야 한다

전체 transcript를 보는 리뷰어, 결과만 보는 리뷰어, 코드베이스만 보는 리뷰어는 서로 다른 오류를 잡는다. 단일 심판보다 서로 다른 관점의 조합이 더 안정적이다.

4. 필드 가이드는 가중치 업데이트의 대체재다

고정된 모델은 실행 중 새 사실을 가중치에 반영할 수 없다. 그래서 Cursor는 에이전트가 유지하는 제한 길이 지식 폴더를 둬, 다음 에이전트가 같은 실패를 반복하지 않게 했다. 이는 agentic-memory와 agent-skills의 경계에 있는 실용 패턴이다.

언제 참고할 만한가

• 대형 리팩터링, 포팅, 테스트 보강처럼 독립 작업을 많이 분해할 수 있는 코드 작업
• 비싼 모델을 모든 토큰에 쓰기보다 설계 판단에만 집중시키고 싶은 팀
• 여러 코딩 에이전트를 운영하면서 merge conflict, 중복 구현, 검증 병목이 커지는 조직

반대로 작은 버그 수정이나 설계 불확실성이 낮은 작업에는 오케스트레이션 비용이 더 클 수 있다.

관련 문서

• agent-harness — 에이전트 성능을 좌우하는 하네스 설계
• long-running-agents — 장시간 에이전트 작업의 컨텍스트·상태 관리
• ai-agent-tips-tools-vs-subagents — 도구와 서브에이전트를 선택하는 기준
• agentic-memory — 에이전트 경험을 저장하고 재사용하는 메모리 계층

참고 자료

• Cursor’s agent swarm suggests cheaper models can handle most coding when frontier models plan the work — The Decoder (2026-07-26)