올해 초, 우리는 목표를 향해 협력하도록 에이전트(agent)를 확장할 때의 한계를 테스트하기 위해 실험을 진행했습니다. 우리의 가설은 이것이 작업 규모와 복잡성의 새로운 차원을 열어줄 것이라는 점이었습니다.

주요 프로젝트는 웹 브라우저를 처음부터 구축하는 장기적인 스웜(swarm) 프로젝트였습니다. 이는 개념 증명(proof of concept)으로서 성공했지만, 완성도 높은 소프트웨어에는 훨씬 미치지 못했습니다.

그 작업은 의도적으로 경험적(empirical)이었습니다. 우리는 빈 캔버스에서 시작하여 안정적이고 효과적인 시스템을 향해 힐 클라이밍(hill-climbing)을 수행했습니다. 그 이후로 우리의 목표는 에이전트 스웜을 의도적으로 설계할 수 있을 만큼 충분히 이해하는 것이었습니다.

그 진전 상황을 테스트하기 위해, 우리는 이전 스웜이 어려움을 겪었던 작업으로 돌아갔습니다. 바로 SQLite를 문서(documentation)만 가지고 Rust 언어로 처음부터 구축하는 작업이었습니다.

우리의 초기 결과는 유망했습니다. 우리는 동일한 모델과 동일한 시간 예산 하에 동일한 작업에 대해 이전 스웜과 새로운 스웜을 실행하였고, 각각이 별도로 준비된 SQL 테스트 스위트(test suite)를 얼마나 통과할 수 있는지 측정했습니다.

새로운 스웜은 모든 모델 구성에서 더 나은 성능을 보였습니다. Grok 4.5를 사용했을 때, 새로운 스웜은 4시간 만에 80%에 도달한 반면, 이전 스웜은 혼란에 빠져 2시간이 지나기도 전에 중단해야 했습니다.

우리는 또한 어떤 모델이 어떤 작업을 수행할지도 변경해 보았습니다. 어떤 실행에서는 하나의 모델이 모든 것을 처리했고, 다른 실행에서는 프론티어 모델(frontier model)이 계획을 세우고 빠르고 저렴한 모델이 작업을 수행했습니다. 모든 조합이 유사한 품질을 만들어냈지만, 비용은 엄청나게 차이가 났습니다.1

Cost to rebuild SQLite by model mix under old and new agent swarms

Cost to rebuild SQLite by model mix under old and new agent swarms

대규모 작업에 대한 설명은 자연스럽게 트리(tree) 형태를 띠게 되며, 루트(root)에 있는 목표가 기본 작업 단위로 재귀적으로 세분화됩니다. 우리의 스웜은 동일한 트리 구조의 분해(decomposition)를 중심으로 조직된 두 가지 역할을 가집니다:

• 플래너 에이전트(Planner agents): 가장 똑똑한 모델을 기반으로 목표를 조각으로 나누고 위임합니다.
• 워커 에이전트(Worker agents): 일반적으로 더 빠르고 저렴한 모델을 기반으로 해당 조각들을 실행합니다.

이 설계는 더 경직된 오케스트레이션 (orchestration) 시스템의 상위 집합입니다. 문제에 고정된 토폴로지 (topology)를 강요하는 대신, 스웜 (swarm)의 형태는 문제의 윤곽을 따라 성장하며, 연산 (compute)과 컨텍스트 (context)는 작업의 복잡성에 비례하여 확장됩니다.

우리는 이것이 브라우저 구축, 수학 문제 해결, GPU 커널 최적화와 같이 다양한 작업으로 설계가 일반화될 수 있는 이유라고 생각합니다. 우리는 또한 이를 내부적으로 사용하여 오픈 소스 소프트웨어의 취약점을 찾아 수정하고, 자체 코드베이스의 테스트 커버리지를 높이며, 수십억 토큰의 합성 학습 데이터 (synthetic training data)를 생성하는 데 사용했습니다.

단일 에이전트 (single agent)가 전체 작업을 맡게 되면, 에이전트는 조상 노드, 현재 위치, 그리고 더 넓은 목표를 컨텍스트에 유지한 채 모든 리프 (leaf) 노드로 내려가며 트리 전체를 스스로 탐색해야 합니다.

우리는 이것이 왜 장시간 실행되는 단일 에이전트가 표류(drift)하는지를 설명한다고 생각합니다. 에이전트는 눈앞의 작업에 집중하느라 큰 그림을 놓치거나, 큰 그림을 유지하느라 개별 작업의 품질을 떨어뜨릴 수밖에 없습니다.

스웜에서는 플래너 (planner)가 절대 구현 (implement)을 수행하지 않으므로 컨텍스트가 저수준의 세부 사항으로 채워지지 않으며, 워커 (worker)는 절대 계획 (plan)을 세우지 않으므로 하나의 좁은 작업에 모든 컨텍스트를 쏟아부을 수 있습니다.

Diagram of decomposing work across planner and worker agents in a task tree

Diagram of decomposing work across planner and worker agents in a task tree

우리는 에이전트 스웜을 확장할 수 있는 능력이 병렬성 (parallelism) 그 자체보다 이러한 컨텍스트 효율성 (context efficiency)에서 비롯된다고 추측합니다. 그 효율성은 모든 규모의 스웜에 존재하며, 이것이 바로 이러한 분해 (decomposition)가 중간 규모의 작업에서도 에이전트의 성능을 돕는 이유입니다.

이러한 구조는 다른 곳에서도 메아리처럼 울려 퍼집니다. 경제학자 로널드 코스 (Ronald Coase)는 기업이 왜 존재하는지에 대해 질문하며, 조정 비용 (coordination costs)이 작업 자체보다 더 빠르게 증가하기 때문에 조직은 모든 사람이 서로 소통하게 두기보다 제한된 단위의 계층으로 정착한다고 주장했습니다.

스웜에 관한 이전 게시물에서 우리는 Git이나 Cargo와 같은 도구들이 동시성 제어 (concurrency control)를 위해 거친 잠금 (coarse locks)에 의존한다는 점을 언급했습니다. 이는 한 명의 개발자에게는 괜찮지만, 수백 명의 동시 에이전트가 만들어내는 작업량에는 실행 불가능한 방식입니다.

올해 초의 브라우저 스웜(browser swarm)은 Git에서 시간당 약 1,000개의 커밋(commit)으로 정점을 찍었습니다. 새로운 시스템은 초당 약 1,000개의 커밋으로 정점에 도달합니다.

이러한 활동 속도를 용이하게 하기 위해, 우리는 새로운 버전 관리 시스템 (VCS, Version Control System)을 처음부터 구축했습니다. 처리량(Throughput)만이 이 계층을 직접 소유해야 하는 유일한 이유는 아니었습니다. 시스템의 모든 변경 사항은 VCS를 통과하므로, 충돌(collision)이 처음으로 가시화되는 지점이기도 하며, 다음 섹션에서 설명할 여러 조정 메커니즘(coordination mechanisms) 중 일부가 그 내부에서 직접 구현됩니다.

인간 엔지니어링 팀은 코드 리뷰(code review), 소유권(ownership), 스탠드업(standups), 머지 큐(merge queues)와 같은 표준적인 조정 메커니즘을 가지고 있습니다. 이러한 시스템은 인간의 템포(tempo)로 작동하지만, 스웜의 커밋 속도에서는 인간 팀이 일상적으로 겪지 못하는 실패 모드(failure modes)가 나타납니다.

두 명의 플래너(planner)가 서로의 존재를 모르는 상태에서, 코드베이스의 서로 다른 부분에 동일한 개념을 서로 다른 방식으로 구현하는 경우가 발생합니다.

우리는 이를 프롬프팅(prompting)을 통해 해결했습니다. 플래너가 설계를 위임하는 대신 스스로 설계 결정을 내리도록 하며, 위임된 두 개의 서브트리(subtree)가 동일한 문제에 대해 결정하지 않도록 보장할 것을 요구합니다.

더 어려운 형태의 경합(contention)은 두 플래너가 서로의 존재를 알고 있으며, 동일한 파일에 대해 주고받는 변경 사항을 통해 싸우는 경우입니다.

문제는 현실에 대한 두 개의 서로 다른 그림이 존재한다는 것이며, 머지 도구(merge tooling)로는 의견 불일치를 해결할 수 없습니다. 대신, 우리는 에이전트가 공유 설계 문서(design docs)에 결정을 기록하도록 합니다. 특정 결정에 의존하는 코드는 해당 문서로 돌아가는 컴파일 체크된 참조(compile-checked reference)를 가집니다. 플래너들이 자신도 모르게 서로 모순되는 결정을 내리면, 조정자(reconciler)가 문서를 병합하고 참조를 통해 해결책이 하류(downstream)로 전파됩니다.

스웜 내부에서 에이전트들은 동일한 파일에서 끊임없이 충돌합니다. 충돌을 해결하기 위해 에이전트들은 작업을 중단하고, 다른 에이전트의 컨텍스트(context)를 흡수하며, 이를 바탕으로 병합해야 합니다. 워커 에이전트(worker agent)는 이를 수행하는 데 서투르며, 실제로 다른 변경 사항을 덮어쓰거나 자신의 변경 사항을 포기해 버립니다.

이를 해결하기 위해, 우리는 중립적인 제3자 에이전트(third-party agent)가 병합 충돌(merge conflicts)에 개입하여 모든 당사자를 대신해 이를 해결하는 시스템을 구축했습니다. 이 에이전트의 유일한 목표는 엔지니어링 팀의 병합 큐(merge queues)가 작동하는 방식과 유사하게, 공정하고 효율적으로 행동하는 것입니다.

일부 파일은 에이전트들이 작업하기에 특히 인기가 많은 장소입니다. 각 에이전트는 아주 적은 양의 코드만 추가할 수 있으며, 단일 에이전트가 파일의 크기를 작게 유지할 책임은 없습니다.

이러한 "메가파일(megafiles)"은 모든 것을 저해합니다. 이 파일들은 전송(transport), 차이점 비교(diff), 병합(merge)하는 데 비용이 많이 들며, 끊임없는 충돌의 장소가 됩니다.

이를 해결하기 위해, 우리는 워커 에이전트(worker agent)가 비대해진 파일을 표시(flag)할 수 있는 방법을 제공했습니다. 일단 표시되면, 새로운 커밋(commit)을 차단하고 외부 에이전트가 비대해진 파일을 더 작은 모듈로 분해합니다.

에이전트들은 인간이 참여하는(human in the loop) 기존 코드베이스에서 작업하며, 핵심 코드(core code)는 변경이 필요하더라도 건드리지 않도록 학습했습니다.

이를 해결하기 위해, 우리는 의도적인 파손(intentional breakage)을 허용합니다. 핵심 변경 사항이 가치가 있다고 판단하는 에이전트는 자신의 범위 밖에서 집중적인 패치(patch)를 만들고, 왜 그렇게 했는지 설명하는 주석을 남길 수 있습니다.

컴파일러(compiler)는 해당 변경 사항을 시스템의 나머지 부분까지 전달하며, 이전 설계에 의존하는 모든 요소는 빌드에 실패합니다. 이러한 오류 중 하나를 마주하는 각 에이전트는 주석을 찾아 그 근거를 읽고, 자신의 작업 부분을 그에 맞춰 업데이트합니다.

장기적으로 실행되면서 다중 에이전트(multi-agent)로 구성된 시스템에서는 오류가 축적되며, 스웜(swarm)은 작은 실수가 근본적인 문제가 되기 전에 스스로를 수정할 방법이 필요합니다.

우리는 리뷰 에이전트(review agent)에게 워커의 전체 기록(transcript)을 제공하거나, 출력값만 제공하거나, 혹은 코드베이스 외에는 아무것도 제공하지 않는 등 다양한 종류의 리뷰 렌즈(review lenses)를 실험했습니다. 또한 서로 다른 모델, 서로 다른 학습 방식 및 성격(personality)을 가진 리뷰어를 실행하는 방식도 시도했습니다.

단 하나의 렌즈(lens)가 모든 것을 포착할 수는 없지만, 자율 주행 시스템이 단 하나의 완벽한 구성 요소 없이도 인간 이상의 신뢰성에 도달하는 방식처럼, 상관관계가 낮은(decorrelated) 여러 렌즈를 쌓아 올리는 방식은 효과적입니다. 리뷰(review)에 소비되는 연산(compute)은 높은 수익을 가져다주는데, 이는 리뷰가 검토 대상이 되는 작업보다 훨씬 저렴하기 때문입니다. 우리는 이러한 계층적 리뷰 시스템(stacked review system)이 실행(runs)의 지속적인 품질을 유지하는 데 주요한 기여를 했다고 추측합니다.

스티그머지(Stigmergy)는 개미나 흰개미와 같은 군집 유기체들이 직접적인 의사소통 없이 협력하는 메커니즘입니다. 이들은 환경을 변화시키고, 그 환경은 다시 다음 유기체를 변화시킵니다.

우리는 이전 실행(runs)에서 "노트 작성"이나 "결정 사항 문서화"와 같은 규칙들을 명시적으로 인코딩했는데, 이는 그것들이 분명히 유익해 보였기 때문입니다. 돌이켜보면, 이러한 규칙들은 에이전트들이 미래의 자신과 팀 동료들을 위해 지식을 제도화(institutionalize)할 수 있도록 도왔습니다.

우리는 "필드 가이드(Field Guide)

진척도를 측정하기 위해, 우리는 서로 다른 데이터베이스 엔진이 동일한 쿼리에 대해 동일한 결과를 반환하는지 확인하기 위해 구축된 SQLite 프로젝트의 테스트 스위트인 sqllogictest를 기준으로 평가했습니다. 여기에는 정답이 알려진 수백만 개의 쿼리가 포함되어 있으며, 점수는 스웜(swarm)의 데이터베이스가 정답을 맞힌 비율입니다. 진척도는 실행 과정 동안 상승하는 곡선으로 나타납니다.

스웜에게는 이 테스트 스위트의 존재를 알려준 적이 없습니다. 매 실행이 끝난 후, 우리는 코드를 수동으로 검토하고 실행 자체를 검토하여 부정행위나 지름길을 사용했는지 확인했으며, 시스템이 단순히 테스트가 집중된 곳뿐만 아니라 전체적으로 균형 있게 구축되었는지 확인했습니다.

곡선을 읽을 때, 에이전트(agents)들이 스스로 전략을 선택했다는 점을 명심하십시오. 어떤 에이전트들은 광범위한 토대를 구축하여 한동안 낮은 점수를 유지하다가 나중에 급격히 상승한 반면, 다른 에이전트들은 한 분야를 깊게 파고들어 초기에 높은 점수를 얻은 뒤 나머지를 채우는 동안 정체기를 겪기도 했습니다. 특정 시점의 정확한 점수보다는 추세(trends)가 더 중요합니다.

우리는 능력과 비용을 아우르는 네 가지 구성을 테스트했습니다:

GPT-5.5를 플래너(planner)와 워커(worker) 모두로 사용. 전 과정에 걸친 강력한 프런티어 모델 (frontier model).Grok 4.5를 플래너와 워커 모두로 사용. 비교 기준점으로 활용한 비용 효율적인 프런티어 모델.**Opus 4.8을 플래너로, Composer 2.5를 워커로 사용.**프런티어의 판단력과 효율적인 실행의 결합.**Fable 5를 플래너로, Composer 2.5를 워커로 사용.**다음 단계의 플래너가 하이브리드 모델의 가치를 더 높이는지 혹은 낮추는지 확인하기 위함.

새로운 하네스(harness)는 모든 조합에서 기존 방식을 능가했습니다.

Fable 5 하이브리드는 첫 한 시간 이내에 스위트의 약 3분의 2를 통과했습니다. 4시간 제한 시점에서 새로운 실행 결과는 73%에서 85% 사이였던 반면, 기존 실행 결과는 11%에서 77% 범위에 머물렀습니다.

기존 Grok 4.5 실행은 2시간이 지나기 전에 중단되었습니다(자세한 내용은 아래 참조). 모든 새로운 구성은 결과적으로 스위트의 100%를 통과했습니다.

향후에는 플래너-워커(planner-worker) 조합의 전체 N×N 매트릭스를 실행해보고 싶습니다. 이번 사이클에서는 하네스(harness) 버전 간의 비교가 중요하며, 행동 양식의 차이는 점수 차이가 시사하는 것보다 훨씬 더 큰 것으로 나타났습니다.

SQLite test suite grade over time for GPT-5.5 under old and new swarms