긴 시간동안 동작하는 자율 코딩 확장하기
TMT다양한 주 단위로 자율적으로 코딩 에이전트를 운용해 실험해왔습니다.
우리의 목표는, 인간 팀이 수개월에 걸쳐 수행하는 프로젝트를 에이전틱 코딩으로 얼마나 멀리 확장할 수 있는지 이해하는 것입니다.
이 글은 단일 프로젝트에서 수백 개의 동시 에이전트를 실행하고, 그들의 작업을 조정하며, 백만 줄 이상의 코드와 트릴리언 단위 토큰을 작성하는 과정을 지켜보며 배운 점을 설명합니다.
단일 에이전트의 한계
오늘날의 에이전트는 집중된 작업에는 잘 작동하지만, 복잡한 프로젝트에서는 느립니다. 자연스러운 다음 단계는 여러 에이전트를 병렬로 실행하는 것이지만, 이를 어떻게 조정할지 파악하는 일은 어렵습니다.
초기 직관은 선계획이 지나치게 경직될 것이라는 것이었습니다. 대규모 프로젝트의 경로는 모호하고, 올바른 작업 분할은 시작 시점에 명확하지 않습니다. 우리는 다른 에이전트가 현재 무엇을 하고 있는지에 따라 각 에이전트가 무엇을 할지 결정하는 동적 조정으로 시작했습니다.
조정을 학습하기
초기 접근법에서는 에이전트에 동등한 지위를 부여하고, 공유 파일을 통해 자율적으로 조정하게 했습니다. 각 에이전트는 다른 에이전트가 무엇을 하고 있는지 확인하고, 작업을 할당받아 자신의 상태를 업데이트했습니다. 두 에이전트가 같은 작업을 잡는 것을 막기 위해 잠금(locking) 메커니즘을 사용했습니다.
이 방식은 흥미로운 방식으로 실패했습니다:
- 에이전트가 잠금을 너무 오래 보유하거나, 아예 해제하는 것을 잊었습니다. 잠금이 올바르게 동작하더라도 병목이 되었습니다. 스무 개의 에이전트가 두세 개의 에이전트와 동일한 실효 처리량까지 느려졌고, 대부분의 시간이 대기 상태로 소모되었습니다.
- 시스템이 취약했습니다: 에이전트가 잠금을 보유한 채 실패하거나, 이미 보유 중인 잠금을 다시 획득하려 하거나, 아예 잠금을 획득하지 않고 조정 파일을 업데이트하기도 했습니다.
우리는 잠금을 낙관적 동시성 제어로 대체하려고 시도했습니다. 에이전트는 상태를 자유롭게 읽을 수 있지만, 마지막으로 읽은 이후 상태가 변경되었으면 쓰기가 실패하도록 했습니다. 이는 더 단순하고 견고했지만, 더 근본적인 문제가 남아 있었습니다.
계층이 없으면 에이전트는 위험 회피적으로 변합니다. 어려운 작업을 피하고, 작고 안전한 변경만 수행했습니다. 어떤 에이전트도 어려운 문제나 엔드 투 엔드 구현의 책임을 지지 않았습니다. 그 결과, 오랜 시간 동안 작업이 소용돌이치며 진전 없이 머무는 상황이 발생했습니다.
기획자와 작업자
다음 접근법은 역할을 분리하는 것이었습니다. 모든 에이전트가 모든 것을 하는 평면 구조 대신, 명확히 구분된 책임을 가진 파이프라인을 만들었습니다.
- **기획자(Planners)**는 코드베이스를 지속적으로 탐색하고 작업을 생성합니다. 특정 영역을 위한 하위 기획자를 생성할 수 있어, 기획 자체가 병렬적이고 재귀적으로 진행됩니다.
- **작업자(Workers)**는 작업을 가져가 오로지 완료하는 데 집중합니다. 다른 작업자와 조정하거나 큰 그림을 신경 쓰지 않습니다. 할당된 작업이 끝날 때까지 꾸준히 진행한 뒤, 변경 사항을 푸시합니다.
각 사이클 끝에서 판정(judge) 에이전트가 계속 진행할지 결정하고, 다음 반복이 새롭게 시작되었습니다. 이는 대부분의 조정 문제를 해결했으며, 어떤 단일 에이전트도 시야가 터널처럼 좁아지지 않도록 하면서 매우 큰 프로젝트로 확장할 수 있게 했습니다.
수주에 걸친 실행
이 시스템을 테스트하기 위해 야심찬 목표—웹 브라우저를 처음부터 구축하기—에 도전했습니다. 에이전트들은 거의 일주일 동안 실행되며, 1,000개 파일에 걸쳐 백만 줄 이상의 코드를 작성했습니다. GitHub의 소스 코드를 탐색할 수 있습니다.
코드베이스 규모가 큼에도 불구하고, 새로운 에이전트는 여전히 이를 이해하고 의미 있는 진전을 이끌어낼 수 있습니다. 수백 명의 작업자가 동시에 실행되며, 최소한의 충돌로 동일한 브랜치에 푸시합니다.
겉보기에는 단순한 스크린샷처럼 보일 수 있지만, 브라우저를 처음부터 만드는 일은 매우 어렵습니다.
또 다른 실험은 Cursor 코드베이스에서 Solid를 React로의 제자리(in-place) 마이그레이션을 수행하는 것이었습니다. 3주 이상이 걸렸고 +266K/-193K 편집이 있었습니다. 변경 사항을 테스트하기 시작하면서, 이 변경을 머지하는 것이 가능하다고 믿고 있습니다.
또 다른 실험은 출시 예정 제품을 개선하는 것이었습니다. 장시간 실행되는 에이전트가 효율적인 Rust 버전으로 비디오 렌더링을 25배 빠르게 만들었습니다. 또한 커서를 따라 자연스러운 스프링 전환과 모션 블러를 통해 부드럽게 확대/축소 및 패닝을 지원했습니다. 이 코드는 머지되었고 곧 프로덕션에 반영될 예정입니다.
현재도 몇 가지 흥미로운 예시가 계속 실행 중입니다:
- Java LSP: 7.4K 커밋, 550K LoC
- Windows 7 에뮬레이터: 14.6K 커밋, 1.2M LoC
- Excel: 12K 커밋, 1.6M LoC
우리가 배운 것들
우리는 단일 목표를 향해 이들 에이전트에 수십억 토큰을 투입했습니다. 시스템은 완전히 효율적이지는 않지만, 기대했던 것보다 훨씬 더 효과적입니다.
모델 선택은 매우 장시간 실행되는 작업에서 중요합니다. 우리는 GPT-5.2 모델이 장기간 자율 작업에 훨씬 더 뛰어나다는 사실을 발견했습니다: 지시를 따르고, 집중을 유지하고, 드리프트를 피하고, 정밀하고 완전하게 구현합니다.
Opus 4.5는 더 일찍 멈추고 편의적일 때 지름길을 택하며, 빠르게 제어권을 반환하는 경향이 있습니다. 또한 서로 다른 모델이 서로 다른 역할에서 뛰어나다는 점도 발견했습니다. GPT-5.2는, 코딩에 특화되어 학습된 GPT-5.1-codex보다 기획자로서 더 우수합니다. 이제 우리는 단일 범용 모델 대신 각 역할에 가장 적합한 모델을 사용합니다.
많은 개선은 복잡성을 추가하기보다 제거함으로써 이루어졌습니다. 우리는 품질 관리와 충돌 해결을 위한 통합자(integrator) 역할을 처음에 만들었지만, 이를 통해 해결하려던 것보다 더 많은 병목이 생긴다는 것을 알게 되었습니다. 작업자들은 이미 자체적으로 충돌을 처리할 수 있었습니다.
최적의 시스템은 종종 예상보다 더 단순합니다. 우리는 초기에는 분산 컴퓨팅과 조직 설계에서 시스템을 모델링하려 했습니다. 하지만, 모든 모델이 에이전트에게 적용되는 것은 아니었습니다.
적절한 구조의 양은 중간 어디쯤에 있습니다. 구조가 너무 적으면 에이전트가 충돌하고, 작업을 중복하며, 드리프트합니다. 구조가 너무 많으면 취약성이 생깁니다.
시스템의 행동에서 놀랄 만큼 많은 부분이 에이전트를 어떻게 프롬프트하느냐에 달려 있습니다. 오랫동안 잘 조정하고 병리적 행동을 피하며 집중을 유지하도록 만드는 데에는 광범위한 실험이 필요했습니다. 하니스와 모델도 중요하지만, 프롬프트가 더 중요합니다.
다음 단계
다중 에이전트 조정은 여전히 어려운 문제입니다. 현재 시스템이 작동하긴 하지만, 최적과는 거리가 있습니다. 기획자는 자신의 작업이 완료되면 다음 단계를 계획하기 위해 깨어나야 합니다. 에이전트는 가끔 지나치게 오랜 시간 실행됩니다. 우리는 여전히 드리프트와 터널 비전을 방지하기 위해 주기적인 새 출발이 필요합니다.
하지만 핵심 질문—더 많은 에이전트를 투입해 자율 코딩을 확장할 수 있는가—에 대해서는 우리가 예상했던 것보다 더 낙관적인 답을 얻었습니다. 수백 개의 에이전트가 단일 코드베이스에서 몇 주 동안 함께 일하며, 야심찬 프로젝트에서 실제 진전을 이루어낼 수 있습니다.
여기에서 개발 중인 기술은 궁극적으로 Cursor의 에이전트 기능에 반영될 것입니다.