---
title: "에이전트 2,000개를 동시에 돌려서 브라우저를 만들어버린 Cursor의 FastRender 프로젝트"
published: 2026-01-23T22:28:01.000Z
canonical: https://jeff.news/article/1152
---
# 에이전트 2,000개를 동시에 돌려서 브라우저를 만들어버린 Cursor의 FastRender 프로젝트
Cursor의 엔지니어 Wilson Lin이 AI 에이전트 수천 개를 병렬로 돌려 3주 만에 Rust 100만 줄 이상의 웹 브라우저를 만든 실험 프로젝트. 플래닝 에이전트가 작업을 겹치지 않게 분할하는 것이 핵심이며, 간헐적 에러를 허용하고 처리량을 최적화하는 전략을 채택함. 생산용이 아닌 멀티 에이전트 코디네이션의 가능성을 보여주는 연구 사례임.
- Cursor 리서치 프로젝트에서 **에이전트 수천 개를 동시에 돌려서 웹 브라우저를 통째로 만들어버린** 실험 결과가 공개됨
- 프로젝트명은 FastRender. 엔지니어 한 명 + AI 에이전트 떼가 **3주 만에 Rust 100만 줄 이상**을 작성해 실제 웹페이지를 렌더링하는 수준까지 도달함
## 프로젝트 배경
- Wilson Lin이라는 엔지니어가 11월에 개인 사이드 프로젝트로 시작함. Claude Opus 4.5, GPT-5.1, GPT-5.2 같은 최신 모델이 복잡한 태스크를 얼마나 잘 처리하는지 실험하려는 목적이었음
- 브라우저 렌더링 엔진을 선택한 이유가 꽤 영리함: 극도로 복잡하면서도 스펙이 잘 정의되어 있고, 결과를 **눈으로 바로 확인**할 수 있기 때문
- 단일 에이전트가 의외로 잘 해내자 "그럼 여러 개 돌리면?" 으로 발전했고, 결국 Cursor 공식 리서치 프로젝트로 승격됨
- 목표는 Chrome과 경쟁하는 브라우저가 아님. 멀티 에이전트 협업의 "hello world" 같은 것
## 2,000개 에이전트 동시 운영
- 피크 시 약 **2,000개 에이전트가 동시에 가동**, 시간당 수천 건의 커밋 발생. 총 커밋 수는 약 30,000개
- 인프라는 단순무식한 접근: 거대한 머신에 각각 ~300개의 에이전트를 올려서 돌림. 에이전트가 "생각하는" 시간이 길어서 CPU 경합이 크지 않았다고
- 에이전트는 **트리 구조**로 조직됨. 플래닝 에이전트가 작업을 분배하고, 워커 에이전트가 실제 코딩을 수행
```mermaid
graph TD
A[Planning Agent] --> B[Worker Agent 1
CSS 파싱]
A --> C[Worker Agent 2
셀렉터 엔진]
A --> D[Worker Agent 3
레이아웃]
B --> E[커밋 → 머지]
C --> E
D --> E
E --> F[메인 브랜치]
F --> G[스크린샷 피드백]
G --> A
```
## 머지 충돌이 거의 없는 비결
- 핵심 트릭: 플래닝 에이전트가 작업을 **겹치지 않는 청크**로 충분히 잘 나누면, 수백~수천 개의 에이전트를 동시에 투입해도 머지 충돌이 거의 발생하지 않음
- 이게 바로 병렬 에이전트 스케일링의 핵심 인사이트임. 분할만 잘 하면 된다는 것
## 피드백 루프와 자율성
- CSS/JS/HTML 스펙을 **git submodule**로 포함시켜 에이전트가 직접 참조하게 함. 코드 내 주석에서 스펙을 인용하는 부분이 많이 발견됨
- GPT-5.2의 비전 기능을 활용해 렌더링 결과 스크린샷을 찍고 골든 샘플과 비교하는 시각적 피드백 루프 구축
- Rust를 선택한 이유 중 하나: **컴파일러가 강력한 피드백 루프** 역할을 해줌. 다른 언어에서는 얻기 어려운 수준의 검증을 컴파일 단계에서 받을 수 있음
- 최장 자율 운영 시간은 약 **1주일**. 한번 시작하면 방향 수정이 불가능하고, 멈추는 것만 가능
## 에이전트가 직접 고른 의존성
- Skia(2D 그래픽), HarfBuzz(텍스트 셰이핑) 같은 당연한 선택도 있었지만, Taffy(CSS flexbox/grid 구현체)처럼 "그건 직접 구현했어야 하는 거 아닌가?" 싶은 것도 끌어옴
- 의존성 수준에 대한 가이드라인을 명시하지 않은 게 원인. 지시사항 설계가 그만큼 중요하다는 교훈
> [!NOTE]
> QuickJS 에피소드가 압권임: 한 에이전트가 다른 에이전트들이 JS 엔진 만드는 걸 기다리다 답답해서 **QuickJS를 그냥 끌어와 버림**. "나중에 자체 엔진 완성되면 교체하자"는 메모까지 남김. 대규모 엔지니어링 팀에서 흔히 보는 패턴과 똑같음
## 간헐적 에러는 허용
- 모든 커밋이 100% 컴파일 가능해야 한다는 제약을 걸면 동기화 병목이 됨
- 대신 "작은 에러는 몇 커밋 안에 곧 수정된다"는 전제하에 **처리량 최적화** 전략을 채택함
- 에러가 누적되는 게 아니라 일정한 비율로 유지되므로 합리적인 트레이드오프라는 판단
> [!IMPORTANT]
> GPT-5.1/5.2 범용 모델이 코딩 특화 모델(GPT-5.1-Codex)보다 더 잘 작동했다는 점이 흥미로움. 하네스 내에서의 자율적 행동, 사용자 피드백 없는 환경에서의 운영 같은 "코딩 이외의 지시사항"이 범용 모델에서 더 잘 먹힌다는 것
## 시사점
- 2026년 1월 기준, 엔지니어 한 명이 에이전트 떼와 함께 **3주 만에 100만 줄 이상의 Rust 코드**로 실제 웹페이지를 렌더링하는 브라우저를 만들 수 있게 됨
- 생산용 소프트웨어는 아니지만, 멀티 에이전트 코디네이션의 가능성을 극적으로 보여주는 사례
- 브라우저라는 거대한 스코프 덕에 JS → WebAssembly → WebGPU 등 앞으로 수년간 실험을 이어갈 수 있는 테스트베드가 됨
## 핵심 포인트
- 피크 시 2,000개 에이전트 동시 가동, 시간당 수천 커밋, 총 30,000 커밋
- 플래닝 에이전트가 작업을 비중첩 청크로 분할해 머지 충돌 최소화
- GPT-5.1/5.2 범용 모델이 코딩 특화 모델보다 자율 운영에 더 적합
- 최장 1주일 자율 운영, Rust 컴파일러와 스크린샷 비교로 피드백 루프 구축
- 에이전트가 직접 의존성 선택 — QuickJS를 답답해서 끌어온 에피소드가 인상적
## 인사이트
멀티 에이전트 병렬 코딩의 핵심은 '작업 분할의 질'이며, 처리량 최적화를 위해 간헐적 에러를 허용하는 전략이 유효함을 실증한 사례.