FastRender 브라우저 실험: 2,000 에이전트가 만든 ‘연구용 웹’

FastRender는 “크롬을 이기기 위한 새 브라우저”가 아닙니다. 더 정확히 말하면, 수천 개의 병렬 AI 에이전트가 한 코드베이스에서 장시간 협업할 때 어떻게 일하고, 어디서 무너지고, 무엇이 의외로 잘 굴러가는지를 관찰하기 위해 만든 ‘실험용 브라우저’에 가깝습니다. 실제로 Rust 기반 렌더러로 여러 웹 페이지를 띄울 수 있지만, JavaScript 엔진은 아직 완성되지 않았고(그래서 기능 플래그로 JS를 꺼둔 상태), 그럼에도 화면이 꽤 그럴듯하게 나오는 지점이 흥미를 끕니다.¹

FastRender는 ‘브라우저’보다 ‘멀티 에이전트 하네스’에 가깝다

사람들은 브라우저 얘기만 나오면 자동으로 “크롬/파이어폭스랑 경쟁하겠다는 건가?”부터 묻습니다. FastRender는 그 프레임을 일부러 비켜 갑니다. 목표는 제품이 아니라, 대규모 멀티 에이전트 코딩 시스템의 행동을 계측하는 데 있습니다.

왜 하필 브라우저일까요? 브라우저는 HTML 파서, CSS 캐스케이드, 레이아웃, 폰트/텍스트 셰이핑, 페인팅, 이벤트, 네트워크 등 복잡도가 끝이 없습니다. 즉, 에이전트가 ‘진짜로’ 협업 가능한지 보려면 이런 괴물 과제가 딱 맞습니다. 잘되면 대단하고, 삐끗해도 무엇이 문제인지 데이터가 남으니까요.

2,000개 병렬 에이전트가 만드는 주당 ‘수천 커밋’의 의미

FastRender에서 가장 영화 같은 장면은 “한 사람이 키를 잡고, 약 2,000개의 에이전트가 동시에 코드를 밀어 넣는” 구조입니다. 병렬로 달리는 에이전트가 주당 수천 개 커밋을 만들며 브라우저의 다양한 부분을 쌓아 올렸다고 알려졌습니다.

여기서 중요한 건 커밋 개수 자체가 아니라, 충돌(merge conflict)이 생각보다 적었다는 점입니다. 보통 여러 사람이 한 저장소에서 동시에 일하면 충돌은 피할 수 없는 ‘세금’인데, 이 실험에서는 일을 잘게 쪼개고 경계를 나눠 충돌을 최소화했다는 관찰이 나옵니다. 사람 팀에서도 어려운 문제를 에이전트 팀이 ‘어떤 방식으로든’ 우회했다는 사실이 꽤 인상적입니다.

“1백만 라인” 논쟁이 놓치기 쉬운 핵심: 지속 가능한 이해력

커뮤니티 반응에서 빠지지 않는 게 “라인 수가 뭐가 중요하냐”입니다. 맞는 말입니다. 라인 수는 20년 전에도 별로였고 지금도 별로죠. 대신 이 실험이 던지는 질문은 다른 데 있습니다.

핵심은 “대규모 코드가 생겼는데도, 새로 투입된 에이전트가 그 코드베이스를 읽고 계속 기여할 수 있느냐”입니다. 즉, 에이전트가 단발성으로 파일을 ‘찍어내는 것’과, 커진 시스템을 이해하면서 점진적으로 고쳐나가는 것은 완전히 다른 능력입니다. Simon Willison도 직접 빌드해 페이지를 띄운 경험을 공유하면서, 기존 엔진을 감싼 게 아니라는 단서(특유의 렌더링 글리치)를 근거로 “꽤 그럴듯하게 작동한다”는 인상을 남겼습니다.¹

JavaScript가 꺼진 브라우저가 오히려 실험에 유리한 이유

FastRender의 JavaScript 엔진은 아직 완성되지 않았고, 에이전트들이 기능 플래그로 JS를 비활성화해둔 상태라고 합니다. 얼핏 보면 “브라우저에서 JS가 안 되면 반쪽짜리 아닌가?” 싶죠.

그런데 실험 관점에선 이게 꽤 전략적입니다. JS까지 들어오면 DOM 조작, 이벤트 루프, 보안 샌드박스, 성능 최적화 등 난이도가 급격히 상승합니다. 그러면 ‘하네스/조정’ 문제인지 ‘JS VM 구현’ 문제인지가 뒤엉켜 관찰이 어려워질 수 있어요. 즉, 복잡한 목표를 한 번에 다 먹으려 하지 않고, 렌더링 파이프라인 같은 큰 뼈대부터 쌓아 올리며 에이전트 협업의 패턴을 먼저 측정하려는 선택으로 볼 수 있습니다.

에이전트가 고른 의존성: “똑똑한 선택”과 “어긋난 선택”이 함께 온다

재밌는 디테일은 일부 라이브러리 선택이 사람 기준에선 “왜 이걸?” 싶은 경우가 있었다는 점입니다(예: Taffy, QuickJS 등). 에이전트가 결정을 잘 내릴 때도 있지만, 프로젝트 목표와 어긋난 선택을 끼워 넣기도 합니다.

이건 멀티 에이전트 개발이 ‘자동화’가 아니라 ‘관리’에 가깝다는 신호입니다. 앞으로의 역할은 코드를 직접 치는 것보다, 규칙(가이드), 경계(아키텍처), 검증(테스트/리뷰)을 설계해 에이전트의 선택지를 좋은 방향으로 제한하는 쪽으로 이동할 가능성이 큽니다. 최근 “에이전트 하네스”가 사실상 운영체제(OS) 같은 역할을 한다는 관점이 힘을 얻는 것도 같은 맥락입니다.²

“작은 오류를 허용”한다는 전략: 속도냐, 품질이냐의 재정의

FastRender 실험에서 또 하나 눈에 띄는 대목은 “작은 오류를 허용하는 편”이 처리량을 위한 전략적 선택처럼 보인다는 점입니다. 사람 팀이라면 PR에서 잡힐 만한 사소한 어긋남이 대규모로 쌓일 수 있고, 그걸 나중에 사람이 치우느라 고생할 수도 있습니다.

실제로 The Register는 이 프로젝트를 두고 “규모로 허술한 코드를 찍어낼 수 있음을 보여줬다”는 비판적 시각을 소개합니다. 특히 CI가 불안정하고, 품질 면에서 기존 엔진들과 비교하기 어렵다는 지적이 나옵니다.³ 다만 비판 자체도 실험의 일부입니다. “이 방식이 제품 개발에 바로 쓸 만한가?”와 “이 방식이 연구 데이터로서 유의미한가?”는 다른 질문이니까요.

시사점: 2026년식 ‘개발’은 코딩보다 조정이 더 커진다

FastRender가 던지는 메시지는 단순합니다. 에이전트는 이제 파일을 몇 개 만드는 수준이 아니라, 수백만 라인급 코드베이스에서도 계속 움직일 수 있는지 시험대에 올랐고, 최소한 “움직이긴 한다”는 데이터 포인트가 생겼습니다.¹

실무적으로는 이렇게 가져가면 좋습니다. 먼저 “에이전트가 잘하는 일(병렬 탐색/초안 생성/반복 작업)”과 “사람이 책임져야 하는 일(목표 정의/아키텍처 경계/테스트/리스크 관리)”을 분리하세요. 그리고 성과 지표도 라인 수나 커밋 수가 아니라, 빌드 안정성·테스트 통과율·회귀 감소 같은 검증 가능한 결과로 바꾸는 게 맞습니다. 에이전트가 많아질수록, 코드는 빨리 쌓이지만 ‘정리의 속도’가 경쟁력이 되니까요.

참고

¹Scaling long-running autonomous coding

²The importance of Agent Harness in 2026

³Cursor shows AI agents capable of shoddy code at scale • The Register