연결 중…
연결 중…
전체 보기
Continuous Learning_Startup & Investment
Telegram · @continuouslearningmatthew

2,000개의 AI 에이전트는 어떻게 1주일 만에 브라우저를 만들었나?

게시
2026.01.26 23:10
조회
232
포워드
15

Cursor 팀은 최근 최대 2,000개의 AI 에이전트를 동시에 가동하여, 약 1주일(실제 연구 기간 포함 3-4주) 만에 100만 라인이 넘는 Rust 코드 기반의 브라우저 엔진을 만들어내는 실험에 성공했습니다.

프로젝트의 핵심 목표: "선형적 확장(Linear Scaling)"

현재의 단일 코딩 에이전트(Single Agent)는 특정 작업은 잘 수행하지만, 복잡하고 거대한 소프트웨어를 구축하기에는 속도가 너무 느립니다.

가설: 에이전트(컴퓨팅 자원)를 10개, 100개, 1,000개로 늘리면 개발 속도도 그에 비례해서 빨라질까?

도전 과제: 수천 개의 에이전트가 서로의 발을 밟지 않고 하나의 코드베이스에서 작업하게 만드는 '조직화(Coordination)' 문제 해결.

2. 아키텍처의 진화: 수평 구조에서 위계 구조로

연구팀은 에이전트를 조직하는 방식에서 큰 시행착오를 겪었습니다.

초기 시도 (수평 구조 - 실패):
모든 에이전트에게 동등한 권한을 주고, 공유 파일(Lock)을 통해 작업을 선점하게 했습니다.

결과: 에이전트들이 서로 Lock을 걸고 기다리느라 병목이 생겼습니다. 또한, 책임자가 없다 보니 어려운 작업은 피하고 쉽고 안전한 수정만 하려는 '위험 회피(Risk-averse)' 성향을 보였습니다. 20개를 돌렸는데 실제 속도는 2~3개 수준으로 떨어졌습니다.

최종 해결책 (Planner-Worker 위계 구조 - 성공):

기획자(Planners): 코드를 직접 짜지 않고 전체적인 설계를 하고 하위 작업을 생성합니다. 재귀적으로 하위 기획자를 또 만들어서 업무 범위를 쪼갭니다.

작업자(Workers): 전체 그림을 신경 쓰지 않습니다. 할당받은 아주 구체적이고 좁은 작업 하나만 수행하고 코드를 푸시합니다.

결과: 이 구조를 통해 최대 2,000개의 에이전트가 충돌 없이 병렬로 작업할 수 있었습니다.

3. 실행 환경 및 기술 스택

수천 개의 에이전트를 제어하기 위해 독자적인 'Harness(제어 장치)'를 구축했습니다.

1. 모델 선택: GPT-5.2가 주로 사용되었습니다. Opus 4.5도 테스트했으나, Opus는 작업을 너무 일찍 끝내버리거나 편한 지름길을 택하는 경향이 있어, 끈기 있게 지시를 따르는 GPT-5.2가 장기 자율 작업에 더 적합했습니다.

2. 컨텍스트 관리: 복잡한 To-Do 리스트 대신 '스크래치패드(Scratchpad)'라는 단순한 파일을 사용하여, 에이전트들이 현재 상태와 진행 상황을 지속적으로 기록하게 했습니다.

3. 충돌 해결 (Optimistic Concurrency): '통합 관리자(Integrator)' 에이전트를 두어 병합을 관리하려 했으나 이것 역시 병목이 되었습니다. 대신 낙관적 동시성 방식을 택해, 각 작업자가 코드를 푸시할 때 충돌이 나면 해당 작업자가 알아서 해결하도록 했습니다.

4. 피드백 루프: 왜 하필 '브라우저'를 만들었나?

에이전트가 장시간 혼자 작업하면 코드가 엉뚱한 방향으로 흘러가는 'Drift(표류)' 현상이 발생합니다. 이를 막기 위해 확실한 외부 기준(Grounding)이 필요했습니다.

명확한 스펙(Spec): 브라우저는 HTML, CSS 같은 국제 표준 문서가 명확히 존재합니다. 에이전트에게 "이 스펙 문서를 참고해"라고 지시하면 환각을 줄일 수 있습니다.

시각적 검증: 렌더링 된 화면을 캡처하여 원본과 비교(Visual Diff)하는 방식으로 에이전트 스스로 디버깅이 가능합니다.

Rust 컴파일러: Rust 언어의 엄격함이 오히려 도움이 되었습니다. 컴파일이 된다는 것 자체가 강력한 1차 검증(Guardrail) 역할을 해주기 때문입니다.

5. 흥미로운 에이전트의 행동 패턴 (Emergent Behaviors)

수천 개의 에이전트가 돌아가면서 사람 개발팀과 유사하거나 놀라운 행동들이 관찰되었습니다.

1. 완벽보다는 속도: 모든 커밋이 100% 완벽하게 컴파일될 필요는 없었습니다. 작은 오류가 발생해도, 뒤따르는 에이전트들이 엄청난 속도로 고쳐나가는 것이 전체 프로젝트 속도(Throughput) 면에서 훨씬 유리했습니다.

2. 스스로 내리는 의사결정:
JavaScript 엔진을 직접 구현하는 작업이 지지부진하자, 한 에이전트가 자신의 작업을 끝내기 위해 스스로 외부 오픈소스 C 라이브러리(QuickJS)를 가져와서 연결해버렸습니다. (동료가 일을 안 하니 외부 솔루션을 도입해버린 셈)

기능 구현이 덜 된 부분은 스스로 판단하여 'Feature Flag(기능 스위치)'를 만들어 비활성화 처리했습니다.

타이트한 시간 제한(Timeout)을 걸어두자, 시간 내에 작업을 마치기 위해 에이전트들이 강제로 코드를 최적화하는 현상도 보였습니다.

6. 최종 성과

이 프로젝트의 결과물인 FastRender는 단순한 데모가 아닙니다.

규모: 100만 라인 이상의 Rust 코드, 30,000개 이상의 커밋.

기능: 위키피디아, 깃허브, CNN 같은 실제 웹사이트를 렌더링할 수 있으며, CSS 레이아웃, 테이블, HTML 파싱 등을 수행합니다.

확장성: 이 시스템은 브라우저뿐만 아니라, 윈도우 7 에뮬레이터(120만 라인), 엑셀 클론(160만 라인) 제작 등 다른 대규모 프로젝트에도 성공적으로 적용되었습니다.

이 실험은 AI 코딩의 미래가 단순히 "더 똑똑한 모델 하나"에 있지 않음을 보여줍니다.
핵심은 "수많은 모델을 어떻게 조직화(Organization)하고, 어떻게 일을 나누며(Planning), 어떻게 검증(Feedback)할 것인가"에 있습니다. 적절한 구조만 갖춰진다면, AI 에이전트 군단은 이미 수개월 치의 엔지니어링 작업을 단 며칠 만에 해치울 수 있는 단계에 와 있습니다.

https://cursor.com/blog/scaling-agents

https://www.youtube.com/watch?v=bKrAcTf2pL4

조회232포워드15텔레그램에서 보기