FastRender는 Cursor가 수천 개의 병렬 에이전트(parallel agents)를 활용하여 스크래치(from scratch)로 구축한 웹 브라우저 연구 프로젝트입니다. 이 프로젝트는 2025년 11월 Wilson Lin의 개인적인 사이드 프로젝트로 시작되어, Claude Opus 4.5, GPT-5.1, GPT-5.2와 같은 최신 프론티어 모델(frontier models)이 복잡한 작업(complex tasks)을 얼마나 잘 수행할 수 있는지 탐색하는 실험으로 활용되었습니다. 브라우저 렌더링 엔진(browser rendering engine)은 야심 차고 복잡하며 잘 정의되어 있고 시각적 피드백(visual feedback)이 명확하여 이상적인 선택이었습니다. 단일 에이전트(single agents)가 상당한 진전을 보이자, 다중 에이전트(multi-agents) 협업의 가능성이 확인되어 공식 Cursor 연구 프로젝트로 전환되었으며, 궁극적인 목표는 프로덕션(production)용 브라우저 개발이 아닌, 대규모 다중 에이전트 시스템의 동작을 관찰하는 것이었습니다.

FastRender의 핵심 방법론은 수천 개의 에이전트를 동시에 실행하는 데 있습니다. 시스템이 안정적으로 운영될 때 피크 시점에는 약 2,000개의 에이전트가 동시에 실행되었으며, 시간당 수천 건의 커밋(commits)이 발생하여 총 30,000개에 가까운 커밋을 기록했습니다. 인프라(infrastructure)는 각 대형 머신(large machine)이 약 300개의 에이전트를 동시 실행하는 방식을 채택했습니다. 이는 에이전트들이 도구 실행(running tools)보다는 사고(thinking)에 많은 시간을 할애하기 때문에 효율적이었습니다.

에이전트 아키텍처(agent architecture)는 트리 구조(tree structure)를 따르며, 상위 레벨의 기획 에이전트(planning agents)가 태스크를 생성하면 하위 레벨의 작업 에이전트(worker agents)가 이를 수행합니다. 브라우저 프로젝트는 CSS 파싱(parsing), 셀렉터 엔진(selector engine) 구현 등 여러 독립적인 명령(instructions) 또는 작업 스트림(work streams)으로 분할되었고, 각 스트림은 별도의 머신에서 전용 하네스(harness)를 실행하여 병렬 처리(parallelization)와 처리량(throughput)을 극대화했습니다. 놀랍게도, 수천 개의 에이전트가 동일한 코드베이스(codebase)에서 작업했음에도 불구하고 병합 충돌(merge conflicts)은 최소화되었습니다. 이는 기획 에이전트가 작업을 비겹치는 청크(non-overlapping chunks)로 효과적으로 분할하여 작업 범위(scope)와 태스크(tasks) 간의 중복을 최소화했기 때문입니다.

모델 선택에서는 코딩 전문 모델인 GPT-5.1-Codex보다 일반 모델인 GPT-5.1과 GPT-5.2가 더 적합하다고 밝혀졌습니다. 이는 에이전트에게 필요한 지시사항이 단순히 코딩을 넘어 하네스 내에서 작동하고 자율적으로(autonomously) 행동하는 등 보다 광범위했기 때문입니다. 이 시스템은 일단 지시를 받으면 인간의 개입 없이 완전히 자율적으로 실행되며, 가장 긴 연속 실행 기간은 약 1주였습니다.

에이전트의 장기적인 자율 작업을 위해 명확한 사양(specifications)과 효과적인 피드백 루프(feedback loops)가 중요하게 활용되었습니다. FastRender 저장소는 csswg-drafts, tc39-ecma262, whatwg-dom, whatwg-html 등 관련 사양을 git submodules로 포함시켰고, AI 에이전트는 코드 내에서 이 사양들을 명시적으로 참조했습니다. GPT-5.2는 비전(vision) 기능이 있는 모델이므로, 렌더링 결과의 스크린샷을 찍어 모델에 피드백으로 제공하고, 골든 샘플(golden sample)과의 차이를 비교하는 진행률 표시기(progress indicators)를 사용했습니다. Rust 컴파일러(compiler)의 엄격함 또한 컴파일 시점의 검증(verification)을 통해 강력한 피드백 루프를 제공했습니다.

대부분의 Cargo.toml 의존성(dependencies)은 에이전트가 스스로 선택했습니다. Skia, HarfBuzz와 같은 명확한 선택도 있었지만, Taffy처럼 CSS flexbox와 grid layout 알고리즘을 직접 구현하는 라이브러리를 사용한 사례도 있었습니다. 이는 에이전트가 프로젝트 목표에 대한 지시사항의 중요성을 보여주는데, Wilson Lin은 의존성 수준을 명시적으로 인코딩하지 않았다고 언급했습니다. Taffy는 에이전트가 벤더링(vendored)하여 직접 변경사항을 적용했으며, 이는 나중에 제거될 예정입니다. QuickJS의 포함은 다른 에이전트가 JavaScript 엔진을 개발하는 동안 자체적으로 작업을 언블록(unblock)하기 위해 일시적으로 사용된 사례로, 대규모 인간 엔지니어링 팀의 역동성과 유사합니다.

흥미로운 점은 에이전트가 코드베이스에 작은 오류(small errors)를 일시적으로 도입하는 것이 허용되었다는 것입니다. 모든 커밋이 완벽해야 한다는 제약은 동기화 병목 현상(synchronization bottleneck)을 유발할 수 있기 때문입니다. API 변경이나 구문 오류(syntax error)와 같은 작은 오류는 빠르게 수정되므로, 시스템은 높은 처리량(throughput)으로 지속적인 진행을 할 수 있었습니다. 이는 정확성보다는 처리량을 최적화하는 트레이드오프(trade-off)가 가치가 있다는 것을 시사합니다.

FastRender는 2026년 초에 단일 엔지니어가 수천 개의 에이전트 지원을 받아 달성할 수 있는 극단적인 가능성을 보여줍니다. 비록 프로덕션용 브라우저는 아니지만, 몇 주 만에 백만 줄 이상의 Rust 코드를 작성하고 실제 웹 페이지를 사용할 수 있는 수준으로 렌더링할 수 있게 되었습니다. 이 프로젝트의 주된 목표는 브라우저를 개발하는 것이 아니라, 브라우저 렌더링 엔진이라는 복잡한 과제를 다중 에이전트 협업 연구의 "hello world" 예시 또는 연구 목적(objective)으로 활용하여 다중 에이전트 하네스의 발전과 연구를 위한 도구로 삼는 것이었습니다.