Cursor는 9월 10일 신기능 'Projects'를 베타 버전으로 전체 사용자에게 공개했다. 목표는 여러 개의 풀리퀘스트(PR)에 걸쳐 몇 주에서 몇 달까지 이어지는 작업이다. 신규 기능 개발, 프레임워크 마이그레이션, 또는 애플리케이션을 처음부터 구축하는 작업 등이 해당한다.
구조는 두 개 층으로 나뉜다. 상위에는 스스로 코드를 작성하지 않고 하위 에이전트에게 작업을 배분하기만 하는 '조정자 에이전트'가 있다. Cursor에 따르면 조정자는 위임만 하고 실행은 하지 않기 때문에 특정 작업에 발이 묶이는 일이 없으며 언제든 새 지시를 받을 수 있다. 하위에는 실제로 코드를 작성하는 하위 에이전트들이 있으며, 공식 발표에 따르면 프로젝트 하나가 수천 개를 지휘할 수 있다.
"It doesn't write code itself but directs other agents that do."
(스스로 코드를 작성하지 않고, 코드를 작성하는 다른 에이전트들에게 지시만 내린다.)
기반이 되는 세 가지 기능
Projects는 다음 세 가지 기능 위에서 작동한다.
- 클라우드 우선: 프로젝트는 전용 서버에서 실행되므로 노트북을 덮어도 작업이 중단되지 않는다.
- 공유 컨텍스트: 파일이 클라우드와 로컬 머신 사이에서 동기화되어, 앞서 작업한 에이전트가 파악한 내용을 뒤에 오는 에이전트가 그대로 재사용할 수 있다.
- 구독: 프로젝트는 Slack 채널을 지켜보거나 일정에 따라 정기적으로 실행되거나 PR 상태에 맞춰 자동으로 반응할 수 있다.
Cursor는 세 가지 대표적인 활용 사례를 제시했다. 신규 기능 개발 시에는 여러 에이전트가 먼저 기존 시스템을 병렬로 조사한 뒤 각각 다른 구성 요소를 나눠 구현한다. 마이그레이션 작업에서는 팀이 이를 이용해 수백 건의 PR에 걸쳐 프레임워크와 스타일 시스템을 단계적으로 교체한다. 유지보수 작업에서는 조정자가 코드 품질과 회귀 문제를 지속적으로 감시한다.
디자인 시스템 사례
Cursor 블로그에서 가장 구체적으로 설명한 사례는 디자인 시스템 유지보수다. 조정자가 새 PR을 하나씩 스캔해 디자인 시스템에 편입해야 할 컴포넌트를 추려내고, 같은 실수를 두 번째로 발견하면 lint 규칙을 추가한다. Cursor의 추산에 따르면 이런 유형의 프로젝트는 하루 20건에서 100건의 PR을 처리한다.
이 물량을 사람의 작업량으로 환산해 보자. 중간 규모 PR을 꼼꼼히 검토하는 데 15분에서 30분이 걸린다고 가정하면, 하루 20건이면 5시간에서 10시간으로 한 사람이 겨우 감당할 수 있는 수준이다. 반면 하루 100건이면 25시간에서 50시간으로, 1인당 하루 8시간 기준으로 3명에서 6명의 리뷰어가 전담으로 필요하다. 기계가 만들어내는 속도가 빨라질수록 병목은 리뷰 단계로 옮겨간다. 팀이 '일부 PR은 자동 검사만 통과하면 병합된다'는 것을 받아들이지 않는 한은 그렇다. Projects가 만들어내는 PR 중 사람이 검토한 뒤 병합되는 비율이 얼마나 되는지에 대해 Cursor는 밝히지 않았다.
'6배'는 어디서 나왔나
Cursor가 제시한 성과 수치는 두 가지다. 사내에서는 신규 사용자가 병합하는 PR이 30% 늘었고, Projects를 주로 사용하는 사용자는 병합량이 기존의 6배가 됐다. 다만 두 수치 모두 Cursor 직원 자신이 낸 것이며, 측정 대상은 병합된 PR 건수뿐이다. PR 규모, 재작업, 롤백은 다루지 않았고, 30%의 비교 기준이 무엇인지도 명시되지 않았다. 외부 팀의 데이터는 현재로서는 확보되지 않았다.
가격 정책에 대해서는, Projects가 별도로 과금되는지, 수천 개의 하위 에이전트 가동을 어떤 기준으로 계량해 과금하는지에 대해 블로그 글은 언급하지 않았다. 클라우드에서 수백에서 수천 개의 에이전트를 장시간 가동하는 비용이 작을 리 없으며, 이 부분은 Cursor의 추가 설명이 필요하다.
두 걸음이 하나로 이어지다
지난 6개월간 Cursor의 행보에 겹쳐 보면 Projects는 그 연장선에 있는 한 수다. 4월 버전 3.0을 출시했을 때 Cursor는 IDE를 에이전트를 관리하는 인터페이스로 재정의했다. 9월 초에는 클라우드 에이전트가 기업 자체 서버에서도 돌아갈 수 있게 했다. Projects는 이 두 가지를 연결하는 지점으로, 사람이 조정자를 관리하고 조정자가 실행 에이전트를 관리하며, 실행 에이전트는 클라우드에서도 기업 자체 서버에서도 실행될 수 있다.
같은 날 공개된 OpenAI의 'Agents API' 역시 주 에이전트가 작업을 하위 에이전트에게 나누는 구조를 지원하지만, 두 회사가 파는 것은 다르다. OpenAI는 개발자에게 자체 에이전트를 구축할 수 있는 기반을 팔고, Cursor는 팀의 작업을 직접 대신 처리해주는 완성품을 판다. Projects의 진입점은 왼쪽 사이드바에 있으며, Cursor는 여러 PR에 걸치거나 장기간 이어지는 작업에만 사용할 것을 권장한다.
참고 출처: Cursor 공식 블로그, CocoLoop, MarkTechPost. 하위 에이전트 규모, PR 병합 증가율 기준, 사례 세부 내용은 Cursor 블로그 게시물로 확인했다.