- Cursor가 수주간 자율 코딩 에이전트를 병렬로 실행하며 대규모 프로젝트를 완성할 수 있는지 실험함
- 초기에는 동적 협업 구조를 사용했으나, 락(lock) 충돌과 작업 중복으로 병목 현상이 발생
- 이후 계획자(Planner) 와 작업자(Worker) 로 역할을 분리해 병렬성과 효율성을 크게 향상
- 이 구조로 웹 브라우저를 처음부터 구현, 수백 명의 에이전트가 100만 줄 이상의 코드를 작성
- 실험 결과, 단순한 구조와 적절한 프롬프트 설계가 장기 자율 코딩 확장의 핵심임
단일 에이전트의 한계
- 현재의 단일 코딩 에이전트는 단순 작업에는 효율적이지만 복잡한 프로젝트에서는 속도가 느림
- 여러 에이전트를 병렬로 실행하는 것이 자연스러운 확장 방향이지만, 작업 조정이 어려움
- 초기에는 사전 계획 없이 동적 협업 방식을 시도
- 각 에이전트가 다른 에이전트의 상태를 보고 스스로 다음 작업을 결정하는 구조
협업 학습 과정
- 모든 에이전트가 동등한 권한을 갖고, 공유 파일을 통해 작업을 조정하는 구조를 도입
- 각 에이전트는 다른 에이전트의 상태를 확인하고, 작업을 할당받아 상태를 갱신
- 중복 방지를 위해 락(lock) 메커니즘을 사용
- 문제점
- 에이전트가 락을 오래 점유하거나 해제하지 않아 전체 속도가 20개 중 2~3개 수준으로 저하
- 락을 보유한 상태에서 실패하거나, 락 없이 파일을 수정하는 등 시스템 불안정성 발생
-
낙관적 동시성 제어(optimistic concurrency control) 로 전환
- 읽기는 자유롭게, 쓰기는 상태 변경 시 실패하도록 설정
- 단순하고 안정적이지만, 위계 없는 구조에서는 에이전트가 위험 회피적 행동을 보임
- 어려운 문제를 회피하고 작은 수정만 반복, 진전 없는 작업 순환 발생
계획자와 작업자 구조
- 역할을 분리한 계층형 파이프라인으로 전환
-
계획자(Planners) : 코드베이스를 탐색하며 작업을 생성, 필요 시 하위 계획자 생성
-
작업자(Workers) : 주어진 작업만 수행하고 완료 후 변경사항을 푸시
- 각 주기마다 판정 에이전트(judge) 가 다음 단계 진행 여부를 결정
- 이 구조로 대부분의 협업 문제가 해결되어, 대규모 프로젝트 확장성 확보
장기 실행 실험
- 실험 목표: 웹 브라우저를 처음부터 구현
- 약 1주간 실행, 1,000개 파일에 100만 줄 이상의 코드 작성
- 수백 개의 작업자가 동시에 같은 브랜치에 푸시했으나 충돌은 최소화
- 결과 코드는 GitHub에 공개됨
- 추가 실험
-
Solid → React 마이그레이션: 3주간 +266K/-193K 변경, 병합 가능성 확인
-
비디오 렌더링 개선: Rust 버전으로 25배 속도 향상, 줌·팬·모션 블러 기능 추가
- 해당 코드는 곧 프로덕션 반영 예정
주요 학습 결과
- 수십억 토큰을 투입한 결과, 완전 효율적이지는 않지만 예상보다 높은 성과 확인
-
모델 선택이 장기 자율 작업의 핵심
-
GPT-5.2는 집중력 유지, 지시 이행, 정확한 구현에서 우수
-
Opus 4.5는 빠른 종료 경향
-
GPT-5.2는 GPT-5.1-codex보다 계획자 역할에 적합
- 역할별로 최적 모델을 선택해 사용
-
복잡성 제거가 성능 향상에 기여
- 품질 통합자(integrator) 역할은 오히려 병목을 유발
- 작업자들이 자체적으로 충돌 해결 가능
-
단순한 구조가 가장 효과적
- 분산 시스템 이론이나 조직 설계 모델은 일부만 유효
- 구조가 너무 적으면 충돌·중복 발생, 너무 많으면 취약성 증가
-
프롬프트 설계가 시스템 행동에 결정적 영향
- 장기 집중 유지, 병리적 행동 방지, 협업 유도에 핵심 역할
향후 과제
-
다중 에이전트 조정은 여전히 어려운 문제
- 계획자가 작업 완료 시 자동으로 다음 단계를 계획하도록 개선 필요
- 일부 에이전트는 과도하게 오래 실행되어 주기적 재시작 필요
- 그러나 핵심 질문, 즉 “에이전트를 늘리면 자율 코딩을 확장할 수 있는가”에 대해
-
수백 개 에이전트가 수주간 협업하며 실제 진전 가능함을 확인
- 이 기술은 향후 Cursor의 에이전트 기능에 반영될 예정임