장기 실행 자율 코딩의 확장 (Scaling long-running autonomous coding)

우리는 몇 주 동안 코딩 에이전트 (coding agents)를 자율적으로 실행하는 실험을 진행해 왔습니다.

우리의 목표는 일반적으로 인간 팀이 완료하는 데 수개월이 걸리는 프로젝트를 위해, 에이전트 기반 코딩 (agentic coding)의 한계를 어디까지 밀어붙일 수 있는지 이해하는 것입니다.

이 포스트는 단일 프로젝트에서 수백 개의 에이전트를 동시에 실행하고, 그들의 작업을 조정하며, 그들이 100만 줄 이상의 코드와 수조 개의 토큰 (tokens)을 작성하는 과정을 지켜보며 배운 점들을 설명합니다.

오늘날의 에이전트들은 집중적인 작업에는 잘 작동하지만, 복잡한 프로젝트에는 느립니다. 자연스러운 다음 단계는 여러 에이전트를 병렬로 실행하는 것이지만, 이들을 어떻게 조정할지 결정하는 것은 매우 어렵습니다.

우리의 첫 번째 직관은 미리 계획을 세우는 것이 너무 경직될 것이라는 점이었습니다. 대규모 프로젝트를 통과하는 경로는 모호하며, 시작 단계에서 적절한 작업 분할은 명확하지 않습니다. 우리는 에이전트들이 다른 에이전트들이 현재 무엇을 하고 있는지에 따라 무엇을 할지 결정하는 동적 조정 (dynamic coordination) 방식으로 시작했습니다.

우리의 초기 접근 방식은 에이전트들에게 동등한 지위를 부여하고 공유 파일을 통해 스스로 조정하게 하는 것이었습니다. 각 에이전트는 다른 에이전트들이 무엇을 하고 있는지 확인하고, 작업을 점유하며, 자신의 상태를 업데이트합니다. 두 에이전트가 동일한 작업을 가져가는 것을 방지하기 위해 우리는 잠금 메커니즘 (locking mechanism)을 사용했습니다.

이는 흥미로운 방식으로 실패했습니다:

에이전트들이 잠금을 너무 오래 보유하거나, 아예 해제하는 것을 잊어버리곤 했습니다. 잠금이 올바르게 작동할 때조차 병목 현상 (bottleneck)이 되었습니다. 20개의 에이전트가 실질적인 처리량 (throughput) 측면에서 2~3개 수준으로 느려졌으며, 대부분의 시간은 대기하는 데 소비되었습니다.

시스템이 취약했습니다: 에이전트들이 잠금을 보유한 채로 실패하거나, 이미 보유하고 있는 잠금을 다시 획득하려고 시도하거나, 잠금을 전혀 획득하지 않은 채 조정 파일을 업데이트할 수도 있었습니다.

우리는 잠금을 낙관적 동시성 제어 (optimistic concurrency control)로 교체해 보았습니다. 에이전트들은 상태를 자유롭게 읽을 수 있지만, 마지막으로 읽은 이후 상태가 변경되었다면 쓰기 작업은 실패하게 됩니다. 이는 더 단순하고 견고했지만, 여전히 더 깊은 문제들이 남아 있었습니다.

계층 구조가 없었기에, 에이전트들은 위험을 회피하게 되었습니다. 그들은 어려운 작업은 피하고 대신 작고 안전한 변경 사항만을 만들었습니다. 어떤 에이전트도 어려운 문제나 엔드 투 엔드 구현 (end-to-end implementation)에 대한 책임을 지지 않았습니다. 이는 진전 없이 장기간 작업이 겉돌게 되는 결과를 초래했습니다.

우리의 다음 접근 방식은 역할을 분리하는 것이었습니다. 모든 에이전트가 모든 것을 수행하는 평면적인 구조 대신, 우리는 명확한 책임을 가진 파이프라인을 구축했습니다.

• **플래너 (Planners)**는 코드베이스를 지속적으로 탐색하고 작업을 생성합니다. 이들은 특정 영역을 위한 서브 플래너 (sub-planners)를 생성할 수 있어, 계획 수립 자체를 병렬적이고 재귀적 (recursive)으로 수행할 수 있습니다.
• **워커 (Workers)**는 작업을 가져와 이를 완료하는 데 전적으로 집중합니다. 이들은 다른 워커와 협력하거나 큰 그림을 걱정하지 않습니다. 그저 할당된 작업이 완료될 때까지 묵묵히 수행한 뒤, 변경 사항을 푸시 (push)합니다.

각 사이클의 끝에서 심판 에이전트 (judge agent)가 계속 진행할지 여부를 결정하면, 다음 반복 (iteration)이 새롭게 시작되었습니다. 이는 우리의 조정 (coordination) 문제 대부분을 해결했으며, 단일 에이전트가 터널 시야 (tunnel vision)에 빠지지 않고도 매우 큰 프로젝트로 확장할 수 있게 해주었습니다.

이 시스템을 테스트하기 위해, 우리는 웹 브라우저를 처음부터 구축한다는 야심 찬 목표를 설정했습니다. 에이전트들은 거의 일주일 동안 실행되었으며, 1,000개의 파일에 걸쳐 100만 줄 이상의 코드를 작성했습니다. GitHub에서 소스 코드를 확인하실 수 있습니다.

코드베이스의 규모에도 불구하고, 새로운 에이전트들은 여전히 이를 이해하고 의미 있는 진전을 이룰 수 있습니다. 수백 명의 워커가 동시에 실행되며, 최소한의 충돌로 동일한 브랜치 (branch)에 푸시합니다.

단순한 스크린샷처럼 보일 수도 있지만, 브라우저를 처음부터 만드는 것은 매우 어려운 일입니다.

또 다른 실험은 Cursor 코드베이스에서 Solid를 React로 인플레이스 마이그레이션 (in-place migration)하는 것이었습니다. 이는 +266K/-193K의 편집을 수반하며 3주 이상 소요되었습니다. 여전히 세심한 검토가 필요하지만, 우리의 CI 및 초기 체크를 통과했습니다.

또 다른 실험은 출시 예정인 제품을 개선하는 것이었습니다. 장기 실행 에이전트 (long-running agent)가 효율적인 Rust 버전을 사용하여 비디오 렌더링 속도를 25배 더 빠르게 만들었습니다. 또한 커서를 따라 자연스러운 스프링 전환 (spring transitions) 및 모션 블러 (motion blurs)와 함께 부드럽게 확대 및 이동 (zoom and pan)할 수 있는 지원 기능을 추가했습니다. 이 코드는 병합되었으며 곧 프로덕션 (production)에 적용될 예정입니다.

현재 여전히 실행 중인 몇 가지 흥미로운 사례들이 있습니다:

• Java LSP: 7.4K 커밋, 550K LoC (Lines of Code)
• Windows 7 에뮬레이터: 14.6K 커밋, 1.2M LoC
• Excel: 12K 커밋, 1.6M LoC

우리는 단일 목표를 향해 이러한 에이전트 전반에 걸쳐 수조 개의 토큰 (trillions of tokens)을 배포했습니다. 시스템이 완벽하게 효율적인 것은 아니지만, 우리가 예상했던 것보다 훨씬 더 효과적입니다.

극도로 긴 시간이 소요되는 작업에는 모델 선택이 중요합니다. 우리는 GPT-5.2 모델이 지시 사항 준수, 집중력 유지, 표류 (drift) 방지, 그리고 정확하고 완전한 구현 측면에서 확장된 자율 작업 (extended autonomous work)에 훨씬 더 뛰어나다는 것을 발견했습니다.

Opus 4.5는 더 일찍 작업을 중단하고 편리할 때 지름길을 택하여 제어권을 빠르게 반환하는 경향이 있습니다. 또한 우리는 서로 다른 모델이 각기 다른 역할에서 탁월한 성능을 보인다는 점도 발견했습니다. GPT-5.1-Codex가 코딩을 위해 특별히 훈련되었음에도 불구하고, GPT-5.2가 더 나은 플래너 (planner) 역할을 수행합니다. 이제 우리는 하나의 범용 모델 대신 각 역할에 가장 적합한 모델을 사용합니다.

우리의 많은 개선 사항은 복잡성을 추가하기보다 제거하는 데서 왔습니다. 초기에는 품질 관리 및 충돌 해결을 위해 통합자 (integrator) 역할을 구축했지만, 이것이 문제를 해결하기보다 더 많은 병목 현상 (bottlenecks)을 만든다는 것을 발견했습니다. 작업자 (workers)들은 이미 스스로 충돌을 처리할 능력이 있었습니다.

최선의 시스템은 종종 예상보다 단순합니다. 우리는 처음에 분산 컴퓨팅 (distributed computing)과 조직 설계 (organizational design)에서 시스템 모델을 가져오려 시도했습니다. 하지만 그 모델들이 모두 에이전트에게 작동하는 것은 아니었습니다.

적절한 구조의 양은 그 중간 어디쯤에 있습니다. 구조가 너무 적으면 에이전트들이 충돌하고, 작업을 중복하며, 표류 (drift)하게 됩니다. 반대로 구조가 너무 많으면 취약성 (fragility)이 생깁니다.

시스템 동작의 놀라울 정도로 많은 부분이 에이전트들에게 어떻게 프롬프트 (prompt)를 제공하느냐에 달려 있습니다. 에이전트들이 잘 협력하고, 병리적인 행동 (pathological behaviors)을 피하며, 장기간 집중력을 유지하도록 만드는 데에는 광범위한 실험이 필요했습니다. 하네스 (harness)와 모델 (models)도 중요하지만, 프롬프트 (prompts)가 더 중요합니다.

다중 에이전트 협업 (Multi-agent coordination)은 여전히 어려운 문제입니다. 우리의 현재 시스템은 작동하지만, 최적화에는 아직 한참 못 미칩니다. 플래너 (Planners)는 자신의 작업이 완료되었을 때 다음 단계를 계획하기 위해 깨어나야 합니다. 에이전트들이 가끔 너무 오랫동안 실행되는 경우도 있습니다. 표류 (drift)와 터널 시야 (tunnel vision) 현상에 대응하기 위해서는 여전히 주기적인 재시작 (fresh starts)이 필요합니다.

하지만 핵심 질문인 '더 많은 에이전트를 문제에 투입함으로써 자율 코딩 (autonomous coding)을 확장할 수 있는가?'에 대해서는 예상보다 더 낙관적인 답을 얻었습니다. 수백 명의 에이전트가 단일 코드베이스 (codebase)에서 몇 주 동안 함께 협력하며, 야심 찬 프로젝트에서 실질적인 진전을 만들어낼 수 있습니다.

여기서 우리가 개발하고 있는 기술들은 궁극적으로 Cursor의 에이전트 기능에 반영될 것입니다. 만약 AI 지원 소프트웨어 개발 (AI-assisted software development) 분야에서 가장 어려운 문제들을 해결하는 데 관심이 있다면, hiring@cursor.com으로 연락해 주시기 바랍니다.