저희는 코딩 에이전트를 몇 주씩 자율적으로 실행하는 실험을 해왔습니다.

저희의 목표는 보통 인간 팀이 완료하는 데 몇 달이 걸리는 프로젝트에서 에이전트 기반 코딩의 한계를 어디까지 밀어붙일 수 있는지 파악하는 것입니다.

이 글에서는 단일 프로젝트에서 수백 개의 에이전트를 동시에 실행하고, 이들의 작업을 조율하며, 100만 줄이 넘는 코드와 수조 개의 토큰을 생성하는 과정을 지켜보며 저희가 배운 내용을 설명합니다.

#단일 에이전트의 한계

오늘날의 에이전트는 집중된 작업에는 잘 작동하지만, 복잡한 프로젝트에서는 속도가 느립니다. 자연스러운 다음 단계는 여러 에이전트를 병렬로 실행하는 것이지만, 이를 어떻게 조율할지 결정하는 일은 쉽지 않습니다.

처음에는 미리 계획을 세우는 방식이 너무 경직적일 것이라고 생각했습니다. 대규모 프로젝트에서 어떤 경로로 진행할지는 불확실하고, 작업을 어떻게 나누는 것이 적절한지도 시작 시점에는 분명하지 않습니다. 그래서 우리는 에이전트가 다른 에이전트들이 현재 무엇을 하고 있는지에 따라 할 일을 결정하는 동적 조율 방식부터 시작했습니다.

#조율하는 법 배우기

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

이 방식은 흥미로운 방식으로 실패했습니다.

1. 에이전트들이 잠금을 너무 오래 유지하거나, 아예 해제하는 것을 잊어버리곤 했습니다. 잠금이 제대로 작동하더라도 병목이 되었습니다. 에이전트가 20개여도 실제 처리량은 2~3개 수준으로 떨어졌고, 대부분의 시간은 대기하는 데 쓰였습니다.

2. 시스템은 취약했습니다. 에이전트가 잠금을 쥔 채 실패할 수도 있었고, 이미 자신이 보유한 잠금을 다시 획득하려 하거나, 아예 잠금을 획득하지도 않고 조율 파일을 업데이트할 수도 있었습니다.

우리는 잠금을 낙관적 동시성 제어로 대체해 보았습니다. 에이전트는 상태를 자유롭게 읽을 수 있었지만, 마지막으로 읽은 이후 상태가 바뀌었다면 쓰기는 실패했습니다. 이 방식은 더 단순하고 더 견고했지만, 여전히 더 근본적인 문제가 남아 있었습니다.

계층 구조가 없자 에이전트들은 위험을 회피하게 되었습니다. 어려운 작업은 피하고, 대신 작고 안전한 변경만 했습니다. 어떤 에이전트도 까다로운 문제나 처음부터 끝까지의 구현을 책임지지 않았습니다. 그 결과 진전 없이 작업만 오랫동안 맴도는 상황이 이어졌습니다.

#계획자와 작업자

다음으로 우리는 역할을 분리하는 접근 방식을 택했습니다. 모든 에이전트가 모든 일을 처리하는 평면적인 구조 대신, 책임이 뚜렷이 나뉜 파이프라인을 만들었습니다.

• 계획자는 지속적으로 코드베이스를 살펴보고 작업을 만듭니다. 특정 영역을 위한 하위 계획자를 생성할 수 있어, 계획 자체도 병렬적이고 재귀적으로 이루어집니다.

• 작업자는 작업을 받아 오직 그것을 완수하는 데만 집중합니다. 다른 작업자와 조율하거나 큰 그림을 신경 쓰지 않습니다. 맡은 작업이 끝날 때까지 그저 묵묵히 수행한 뒤, 변경 사항을 푸시합니다.

각 주기가 끝나면 판단 에이전트가 계속 진행할지 결정했고, 그러고 나서 다음 반복은 처음부터 다시 시작했습니다. 이 방식은 조율 문제 대부분을 해결했고, 어느 한 에이전트도 터널 비전에 빠지지 않으면서 매우 큰 프로젝트까지 확장할 수 있게 해주었습니다.

#몇 주째 실행 중

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

코드베이스 규모가 큰데도 새 에이전트도 여전히 이를 이해하고 의미 있는 진전을 만들어낼 수 있습니다. 수백 개의 워커가 동시에 실행되면서도, 충돌은 거의 없이 같은 브랜치에 푸시합니다.

언뜻 보면 단순한 스크린샷처럼 보일 수 있지만, 브라우저를 처음부터 만드는 일은 극도로 어렵습니다.

또 다른 실험은 Cursor 코드베이스에서 Solid를 React로 인플레이스 마이그레이션하는 작업이었습니다. +266K/-193K 수정으로 3주가 넘게 걸렸습니다. 여전히 꼼꼼한 리뷰가 필요하지만, CI와 초기 검사 단계는 통과했습니다.

또 다른 실험은 출시 예정인 제품을 개선하는 것이었습니다. 장시간 실행되는 에이전트가 효율적인 Rust 버전으로 비디오 렌더링 속도를 25배 높였습니다. 또한 커서를 따라 자연스러운 스프링 전환과 모션 블러를 적용해 부드럽게 확대/축소하고 이동할 수 있는 기능도 추가했습니다. 이 코드는 이미 머지되었으며 곧 프로덕션에 반영될 예정입니다.

아직도 실행 중인 흥미로운 다른 예시가 몇 가지 있습니다:

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

#우리가 배운 점

우리는 하나의 목표를 위해 이 에이전트들에 수조 개의 토큰을 투입해 왔습니다. 이 시스템이 완벽하게 효율적이지는 않지만, 예상했던 것보다 훨씬 더 효과적입니다.

아주 오랫동안 실행되는 작업에서는 모델 선택이 중요합니다. GPT-5.2 모델은 장시간 자율 작업에서 훨씬 뛰어났습니다. 지시를 따르고, 집중을 유지하고, 흐트러지지 않으며, 기능을 정확하고 완전하게 구현하는 데 강점이 있었습니다.

Opus 4.5는 편의에 따라 더 일찍 멈추고 지름길을 택하는 경향이 있으며, 제어권도 빠르게 다시 넘겨줍니다. 또 모델마다 잘하는 역할이 다르다는 점도 확인했습니다. GPT-5.1-Codex는 코딩에 특화되어 학습되었지만, 계획을 세우는 능력은 GPT-5.2가 더 뛰어납니다. 이제 우리는 하나의 범용 모델 대신, 각 역할에 가장 적합한 모델을 사용합니다.

개선 사항의 상당수는 복잡성을 더해서가 아니라 덜어내는 과정에서 나왔습니다. 처음에는 품질 관리와 충돌 해결을 위한 integrator 역할을 만들었지만, 실제로는 해결한 것보다 더 많은 병목을 만들었습니다. worker들은 이미 스스로 충돌을 처리할 수 있었습니다.

최고의 시스템은 종종 예상보다 더 단순합니다. 처음에는 분산 컴퓨팅과 조직 설계의 시스템을 본떠 모델링하려 했습니다. 하지만 그런 방식이 모두 에이전트에 맞는 것은 아닙니다.

적절한 수준의 구조는 그 중간 어딘가에 있습니다. 구조가 너무 적으면 에이전트들이 충돌하고, 작업이 중복되며, 방향을 잃습니다. 구조가 너무 많으면 시스템이 취약해집니다.

놀랄 만큼 많은 부분이 에이전트에 어떻게 프롬프트를 주느냐에 달려 있습니다. 에이전트들이 서로 잘 협업하고, 이상 동작을 피하며, 오랜 시간 집중력을 유지하게 하려면 광범위한 실험이 필요했습니다. 하네스와 모델도 중요하지만, 프롬프트는 그보다 더 중요합니다.

#다음 단계

멀티 에이전트 조율은 여전히 어려운 문제입니다. 현재 시스템은 작동하고 있지만, 최적과는 아직 거리가 멉니다. 계획자는 작업이 완료되면 깨어나 다음 단계를 계획할 수 있어야 합니다. 에이전트가 가끔 너무 오랫동안 실행되기도 합니다. 드리프트와 터널 비전을 막으려면 여전히 주기적으로 처음부터 다시 시작할 필요가 있습니다.

하지만 문제에 더 많은 에이전트를 투입해 자율 코딩을 확장할 수 있는가라는 핵심 질문에 대해서는, 우리가 예상했던 것보다 더 낙관적인 답이 나왔습니다. 수백 개의 에이전트가 하나의 코드베이스에서 몇 주 동안 함께 작업하며, 야심찬 프로젝트에서 실질적인 진전을 만들어낼 수 있습니다.

여기서 우리가 개발하고 있는 기술은 결국 Cursor의 에이전트 기능에 반영될 것입니다. AI 지원 소프트웨어 개발에서 가장 어려운 문제들을 푸는 일에 관심이 있다면, hiring@cursor.com으로 연락해 주세요.