출처

개요

Cursor는 여러 에이전트를 동시에 운영할 때 발생하는 중복 구현과 병합 충돌을 줄이기 위해 에이전트 스웜을 플래너와 워커로 분리했습니다. 플래너는 상대적으로 강력하고 비싼 모델로 작업을 세분화하고, 워커는 빠르고 저렴한 모델로 좁은 단위의 구현만 수행합니다. Cursor는 이 구조의 핵심 효과를 병렬 에이전트 수보다 컨텍스트를 역할별로 분리하는 데서 찾았습니다. SQLite를 835쪽 매뉴얼만 참고해 Rust로 재구현한 실험에서 신형 스웜은 Grok 4.5 기준 4시간 만에 테스트의 80%를 통과했습니다. 다만 이러한 모델 역할 분리가 항상 비용 절감으로 이어지는 것은 아니며, 작업을 어떻게 세분화하고 전달하는지가 중요하다고 설명합니다.

핵심 포인트

  • 플래너 에이전트는 전체 목표를 작업 트리 단위로 세분화하고, 워커 에이전트는 할당받은 좁은 작업의 구현에 집중합니다.
  • 역할 분리를 통해 플래너는 구현 세부사항에 컨텍스트를 소모하지 않고, 워커는 전체 설계 부담 없이 담당 작업에 컨텍스트를 사용할 수 있습니다.
  • SQLite 재구현 실험에서 신형 스웜은 구형보다 안정적인 결과를 냈으며, Grok 4.5 사용 시 4시간 만에 sqllogictest의 80%를 통과했습니다.
  • 신형 스웜은 초당 1,000커밋 수준을 처리하기 위해 기존 Git·Cargo 대신 자체 버전관리 시스템을 구축했습니다.
  • 공유 설계 문서에 결정 사항을 기록하고 코드와 연결해, 플래너 간 중복 구현과 “스플릿 브레인” 문제를 줄였습니다.
  • 병합 충돌은 중립 에이전트가 해결하고, 비대해진 파일은 별도 에이전트가 여러 모듈로 분리합니다.
  • Stencil의 실험처럼 계획 문서만 전달하면 워커가 컨텍스트를 다시 읽느라 비용이 늘 수 있으므로, 단순한 모델 교체보다 작업 전달 구조가 중요합니다.

왜 중요한가

멀티에이전트 시스템의 성능은 에이전트 수를 늘리는 것만으로 개선되지 않습니다. 전체 계획과 세부 구현을 한 에이전트가 동시에 담당하면 컨텍스트가 과도하게 커지고, 여러 에이전트가 같은 코드 영역을 독립적으로 수정하면 작업량이 커져도 실제 산출물은 늘지 않을 수 있습니다. Cursor의 사례는 플래닝과 실행을 분리하되, 계획을 추상적인 요약문이 아니라 세분화된 작업 구조와 공유 설계 기록으로 전달해야 비용·품질·충돌 문제를 함께 다룰 수 있음을 보여줍니다.

참고 링크

관련 위키

원문 보존 위치

원문 전체는 raw source: 2026-07-28-aisparkup-post-14800-cursorsource_url 및 HTML 원문과 함께 저장되어 있습니다.