올해 초, 저희는 하나의 목표를 향해 협력하는 에이전트를 어디까지 확장할 수 있는지 시험하는 실험을 진행했습니다. 저희의 가설은 이것이 작업 규모와 복잡성의 새로운 단계로 이어질 것이라는 것이었습니다.

대표 프로젝트는 처음부터 웹 브라우저를 만드는 장시간 실행되는 스웜이었습니다. 개념 증명으로서는 성공했지만, 완성도 높은 소프트웨어와는 아직 거리가 멀었습니다.

그 작업은 의도적으로 경험적 접근을 택했습니다. 저희는 백지 상태에서 시작해 안정적이고 효과적인 시스템을 향해 점진적으로 개선해 갔고, 그 이후의 목표는 에이전트 스웜을 의도적으로 설계할 수 있을 만큼 충분히 이해하는 것이었습니다.

이런 진전을 검증하기 위해, 저희는 기존 스웜이 고전했던 작업으로 돌아갔습니다. 바로 문서만을 바탕으로 Rust로 처음부터 SQLite를 만드는 일이었습니다.

초기 결과는 고무적이었습니다. 저희는 기존 스웜과 새로운 스웜을 같은 작업에, 같은 모델과 같은 시간 예산으로 실행한 뒤, 각각이 별도로 분리해 둔 SQL 테스트 스위트 중 얼마나 통과할 수 있는지 측정했습니다.

새로운 스웜은 모든 모델 설정에서 더 나은 성능을 보였습니다. Grok 4.5를 사용했을 때는 4시간 만에 80%에 도달한 반면, 기존 스웜은 2시간도 되기 전에 흐름이 무너져 중단해야 했습니다.

또한 어떤 모델이 어떤 역할을 맡는지도 바꿔 보았습니다. 어떤 실행에서는 하나의 모델이 모든 일을 처리했고, 다른 실행에서는 프런티어 모델이 계획을 세우고 빠르고 저렴한 모델이 실제 작업을 수행했습니다. 어떤 조합이든 비슷한 품질을 냈지만, 비용 차이는 매우 컸습니다.¹

#트리와 리프

큰 과제에 대한 설명은 자연스럽게 트리 형태를 띱니다. 루트에는 목표가 있고, 그 목표는 재귀적으로 기본 작업 단위까지 쪼개집니다. 우리의 스웜에는 두 가지 역할이 있으며, 둘 다 이런 트리형 분해를 중심으로 구성됩니다.

• 가장 뛰어난 모델로 구동되는 Planner 에이전트는 목표를 여러 부분으로 나누고 각 부분을 위임합니다.
• 일반적으로 더 빠르고 비용이 낮은 모델로 구동되는 Worker 에이전트는 그 부분들을 실행합니다.

이 설계는 더 경직된 오케스트레이션 시스템을 포괄하는 상위 개념입니다. 과제에 고정된 토폴로지를 강제하는 대신, 스웜의 형태는 과제의 윤곽에 맞춰 확장되고, 연산 자원과 컨텍스트도 과제의 복잡성에 비례해 함께 확장됩니다.

우리는 이것이 이 설계가 브라우저 만들기, 수학 과제 해결, GPU 커널 최적화처럼 매우 다양한 과제에 일반화될 수 있는 이유라고 생각합니다. 또한 이를 내부적으로 활용해 오픈소스 소프트웨어의 취약점을 찾아 수정하고, 자체 코드베이스의 테스트 커버리지를 높이며, 수십억 개의 합성 학습 데이터 토큰을 생성해 왔습니다.

#메모리 측면에서 트리의 역할

단일 에이전트가 전체 작업 하나를 맡으면, 전체 트리를 혼자 훑어야 하며 각 리프까지 내려가는 내내 조상 노드들, 현재 위치, 그리고 더 큰 목표를 모두 컨텍스트에 담아둬야 합니다.

저희는 이것이 장시간 실행되는 단일 에이전트가 왜 흐트러지는지 설명해 준다고 봅니다. 눈앞의 작업에 집중하면 큰 그림을 놓치기 쉽고, 반대로 큰 그림을 계속 붙들고 있으면 개별 부분을 처리하는 능률이 떨어집니다.

스웜에서는 Planner가 구현을 하지 않기 때문에 컨텍스트가 저수준 세부사항으로 채워지지 않고, 워커는 계획을 세우지 않기 때문에 자신의 컨텍스트를 좁고 구체적인 작업 한 조각에 온전히 쓸 수 있습니다.

저희는 에이전트 스웜이 확장될 수 있는 이유가 병렬성 자체보다 이런 컨텍스트 효율성에 더 크다고 봅니다. 이 효율성은 규모와 관계없이 스웜 전반에 걸쳐 나타나므로, 이런 분해 방식은 중간 규모의 작업에서도 에이전트 성능 향상에 도움이 됩니다.

비슷한 구조는 다른 곳에서도 찾아볼 수 있습니다. 경제학자 Ronald Coase는 기업이 애초에 왜 존재하는지 물으며, argued 조정 비용은 일 자체보다 더 빠르게 커지기 때문에 모두가 모두와 직접 소통하는 대신 조직은 경계가 분명한 단위들의 계층으로 자리 잡는다고 했습니다.

#에이전트를 위한 버전 관리 시스템

스웜에 관한 이전 글에서 Git과 Cargo 같은 도구는 동시성 제어를 위해 큰 단위의 잠금을 사용한다고 언급했습니다. 이는 개발자 한 명이 작업할 때는 괜찮지만, 수백 개의 에이전트가 동시에 만들어내는 작업량에는 감당할 수 없습니다.

올해 초 브라우저 스웜은 Git에서 시간당 약 1,000개의 커밋으로 정점을 기록했습니다. 새 시스템은 초당 약 1,000개의 커밋으로 정점을 기록합니다.

이 정도의 활동량을 뒷받침하기 위해, 우리는 새로운 버전 관리 시스템(VCS)을 처음부터 직접 구축했습니다. 이 계층을 직접 소유해야 했던 이유는 처리량 때문만은 아니었습니다. 시스템의 모든 변경 사항이 VCS를 거치기 때문에 충돌이 가장 먼저 드러나는 지점이 바로 여기이며, 다음 섹션에서 설명할 여러 조정 메커니즘도 이 안에 직접 구현되어 있습니다.

#초당 1,000커밋에서 나타나는 실패 양상

사람으로 이루어진 엔지니어링 팀에는 코드 리뷰, 담당 영역, 스탠드업, 머지 큐처럼 협업을 조율하는 일반적인 방식이 있습니다. 이런 체계는 사람의 작업 속도에는 맞지만, 스웜의 커밋 속도에서는 인간 팀이 일상적으로 겪지 않는 실패 양상이 나타납니다.

#스플릿 브레인 설계

서로를 인지하지 못하는 두 계획자가 코드베이스의 서로 다른 부분에서 동일한 개념을 각기 다른 방식으로 구현합니다.

이 문제는 프롬프팅으로 해결했습니다. 계획자는 설계 결정을 위임하지 않고 직접 내리며, 위임된 두 하위 트리가 같은 사안을 각각 결정하지 않도록 해야 합니다.

#계획자들 사이의 경합

더 까다로운 형태의 경합은 두 계획자가 서로의 존재를 알고 있으면서 같은 파일을 두고 변경을 주고받으며 충돌하는 경우입니다.

문제는 현실에 대한 서로 다른 두 관점이 존재한다는 점이며, 병합 도구만으로는 이런 불일치를 해결할 수 없습니다. 대신 에이전트가 공유 설계 문서에 결정을 기록합니다. 어떤 결정에 의존하는 코드는 컴파일 시 검증되는 참조를 통해 해당 문서와 연결됩니다. 계획자들이 자신도 모르게 서로 모순되는 경우에는 조정자가 문서를 병합하고, 그 참조를 통해 해결 내용이 다운스트림으로 전파됩니다.

#병합 충돌

스웜 내부에서는 에이전트들이 같은 파일에서 끊임없이 부딪힙니다. 이런 충돌을 해결하려면 작업을 멈추고 다른 에이전트의 컨텍스트를 흡수한 다음, 이를 반영해 병합해야 합니다. 워커 에이전트는 이런 일에 서툴러서, 실제로는 상대 변경 사항을 덮어쓰거나 자기 변경 사항을 포기하곤 합니다.

이를 해결하기 위해, 중립적인 타사 에이전트가 병합 충돌에 개입해 모든 당사자를 대신해 해결하는 시스템을 만들었습니다. 이 에이전트의 유일한 목표는 공정성과 효율성을 유지하는 것이며, 엔지니어링 팀에서 병합 큐가 작동하는 방식과 비슷합니다.

#메가파일

일부 파일은 에이전트가 특히 자주 작업하는 곳입니다. 각 에이전트는 적은 양의 코드만 추가할 수 있고, 어느 한 에이전트도 그 파일을 작게 유지할 책임을 지지 않습니다.

이런 “메가파일”은 모든 것을 마비시킵니다. 전송하고 diff를 확인하고 병합하는 데 비용이 많이 들며, 끊임없이 충돌이 일어나는 지점이 됩니다.

이를 해결하기 위해 저희는 워커 에이전트가 비대해진 파일에 플래그를 지정할 수 있도록 했습니다. 플래그가 지정되면 새 커밋을 차단하고, 외부 에이전트가 너무 커진 파일을 더 작은 모듈로 분해합니다.

#경직화

Agent는 사람이 개입된 기존 코드베이스에서 작업해 오면서, 바뀌어야 할 때조차 핵심 코드는 건드리지 않게 되었습니다.

이를 해결하기 위해, 우리는 의도적으로 깨지는 변경을 허용합니다. 핵심 변경이 그럴 만한 가치가 있다고 판단한 에이전트는 자신의 범위 밖에 국소적인 패치를 만들고, 왜 그렇게 했는지 설명하는 주석을 남길 수 있습니다.

컴파일러는 그 변경을 시스템의 나머지 부분까지 전파하고, 이전 설계에 의존하는 모든 것은 빌드에 실패합니다. 그런 오류를 마주한 각 에이전트는 그 주석을 찾아 읽고, 그 판단 근거를 이해한 뒤, 자신의 작업 부분을 그에 맞게 업데이트합니다.

#검토 관점

장시간 실행되는 다중 에이전트 시스템에서는 오류가 누적되기 때문에, 작은 실수가 근본적인 문제로 굳어지기 전에 시스템이 스스로 바로잡을 방법이 필요합니다.

저희는 다양한 종류의 검토 관점을 실험했습니다. 예를 들어 검토 에이전트에 워커의 전체 대화 기록을 주기도 하고, 출력만 주기도 하고, 코드베이스만 주기도 했습니다. 또한 서로 다른 모델에서, 서로 다른 학습과 성향을 가진 검토자가 실행되도록 해보기도 했습니다.

어떤 단일 관점도 모든 것을 잡아내지는 못하지만, 서로 상관성이 낮은 관점들을 겹쳐 쓰면 효과가 누적됩니다. 이는 완벽한 단일 구성 요소 없이도 자율주행 시스템이 인간을 뛰어넘는 신뢰성에 도달하는 방식과 같습니다. 검토에 투입되는 컴퓨팅 자원은 높은 효율을 냅니다. 검토 비용이 검토 대상 작업보다 훨씬 저렴하기 때문입니다. 저희는 이렇게 층층이 쌓은 검토 시스템이 실행 전반의 일관된 품질을 유지하는 데 크게 기여했다고 보고 있습니다.

#에이전트가 환경을 만들어가도록 하기

스티그머지는 개미나 흰개미 같은 군집 생물이 직접적인 의사소통 없이 서로 조율하는 메커니즘입니다. 이들은 환경을 바꾸고, 그 환경은 다음 개체의 행동에 영향을 줍니다.

이전 실행에서는 “메모 남기기”, “결정 사항 문서화하기” 같은 규칙을 넣어 두었는데, 언뜻 봐도 분명히 좋은 방법처럼 보였기 때문입니다. 돌이켜보면, 이는 에이전트가 미래의 자기 자신과 팀 동료들을 위해 지식을 축적하고 체계화하게 만드는 방식이었습니다.

우리는 이를 더 발전시켜, Field Guide라고 부르는 에이전트 주도의 공유 컨텍스트 실험을 진행했습니다. 이는 전적으로 에이전트가 관리하는 폴더이며, 그 안의 index.md는 시작 시 모든 에이전트에 자동으로 주입됩니다. 가이드에 무엇을 넣을지 선별하는 것은 에이전트의 몫이며, 유일한 제약은 줄 수 예산뿐입니다.

이 가이드의 기본 논리는 모델 가중치가 고정되어 있기 때문에, 예상치 못한 경험일수록 다음 에이전트 트래젝터리를 더 짧게 만드는 데 도움이 되므로 기록할 가치가 있다는 것입니다.

Field Guide는 유망한 결과를 보여 주는 초기 실험입니다. 에이전트가 완전히 소유하지 않은 코드베이스에서는 그 효과가 훨씬 더 클 것으로 예상합니다. 더 잘 포착할수록 더 나은 보상으로 이어지는 환경에서, 후속 에이전트를 위해 글을 쓰도록 모델을 훈련하는 일은 흥미로운 후속 조사 분야입니다.

#SQLite 실험

위에서 설명한 모든 개선 사항을 반영한 새 버전의 스웜에 Rust로 835페이지 분량의 SQLite 매뉴얼 전체를 구현하게 했습니다. 소스 코드, 테스트 스위트, SQLite 바이너리, 인터넷 접근 권한은 제공하지 않았습니다.

진행 상황을 측정하기 위해 sqllogictest를 기준으로 평가했습니다. sqllogictest는 같은 쿼리에 대해 서로 다른 데이터베이스 엔진이 동일한 결과를 반환하는지 확인하기 위해 만들어진 SQLite 프로젝트의 테스트 스위트입니다. 여기에는 정답이 알려진 수백만 개의 쿼리가 들어 있으며, 평가는 스웜의 데이터베이스가 그중 몇 개를 맞히는지의 비율로 매겨집니다. 진행 상황은 실행이 진행될수록 상승하는 곡선으로 나타납니다.

스웜에는 이 스위트의 존재 자체를 전혀 알려주지 않았습니다. 각 실행이 끝난 뒤에는 코드와 실행 과정 자체를 사람이 직접 검토해 속임수나 편법이 없는지 확인했고, 테스트가 보는 부분만 맞춘 것이 아니라 시스템 전반이 고르게 구축되었는지도 확인했습니다.

곡선을 볼 때는 에이전트들이 각자 자신만의 전략을 선택했다는 점을 염두에 두세요. 어떤 에이전트는 넓은 기반을 다지느라 몇 시간 동안 낮은 점수를 기록하다가 후반에 급격히 치솟았고, 다른 에이전트는 한 영역을 깊게 파고들어 초반에 점수를 얻은 뒤 나머지를 채우는 동안 정체되기도 했습니다. 특정 시점의 정확한 점수보다 전반적인 추세가 더 중요합니다.

#모델 조합별 결과

저희는 성능과 요금을 아우르는 네 가지 설정을 테스트했습니다.

1. GPT-5.5를 Planner와 워커로 모두 사용. 전 과정에 걸쳐 강력한 프런티어 모델입니다.²
2. Grok 4.5를 Planner와 워커로 모두 사용. 비교 기준점으로 삼은 비용 효율적인 프런티어 모델입니다.
3. Opus 4.8을 Planner로, Composer 2.5를 워커로 사용. 프런티어 수준의 판단력에 효율적인 실행을 결합한 구성입니다.
4. Fable 5를 Planner로, Composer 2.5를 워커로 사용. 한 단계 낮은 등급의 Planner가 이 하이브리드 구성을 더 가치 있게 만드는지, 아니면 오히려 덜 가치 있게 만드는지 확인하기 위한 설정입니다.

새 하네스는 모든 조합에서 기존 하네스보다 더 뛰어난 성능을 보였습니다.

Fable 5 하이브리드는 첫 1시간 안에 스위트의 약 3분의 2를 통과했습니다. 4시간 컷오프 시점에는 새 실행의 통과율이 73%~85%였고, 기존 실행은 11%~77% 범위였습니다.

기존 Grok 4.5 실행은 2시간이 되기 전에 일시 중지되었습니다(자세한 내용은 아래 참고). 새 설정은 모두 결국 스위트의 100%를 통과했습니다.

앞으로는 Planner-워커 조합의 전체 N×N 매트릭스를 실행해 보고 싶습니다. 이번 사이클에서 중요한 비교는 하네스 버전 간 비교였고, 실제로 동작 차이는 점수 차이만으로는 드러나지 않을 만큼 훨씬 컸습니다.

#실행 심층 분석

가장 단순한 활동 지표부터 살펴보면, 기존 하네스와 새 하네스에서 Grok 4.5의 커밋 발생률이 어떻게 달라졌는지 확인할 수 있습니다. 기존 실행은 처음 두 시간 동안 68,000개의 커밋을 만들어 냈고, 이는 새 실행 속도의 약 70배에 달했습니다.

이를 더 생산적이었다고 해석할 수도 있습니다. 반대로 그 커밋 대부분이 실질적 진전 없는 소모적 작업(thrash, contention, churn)이었다고 볼 수도 있습니다.

병합 충돌 데이터는 후자의 해석을 뒷받침합니다. 기존 실행은 우리가 중단하기 전까지 70,000건이 넘는 충돌이 누적됐고, 안정화되기는커녕 오히려 더 가속됐습니다. 반면 새 실행은 전체 4시간 동안 천 건이 채 안 되는 충돌만 기록했습니다.

충돌은 파일 크기가 가장 크게 불어난 지점에 집중됐습니다. 기존 실행에서는 가장 큰 파일들이 실행 내내 계속 커졌고, 가장 경합이 심했던 단일 파일에는 7,771건의 충돌이 쌓였으며 1,173개의 서로 다른 에이전트가 이 파일을 건드렸습니다. 새 실행에서는 전체 코드베이스에서 가장 경합이 심한 파일도 47건에 그쳤습니다.

기존 스웜의 가장 큰 조율 실패인 스플릿 브레인, 즉 계획자들이 서로의 작업을 중복 수행하는 현상은 패키지 구조에서 드러났습니다. Rust 코드는 crate라고 하는 패키지 단위로 구성되며, 이런 프로젝트에서는 각 crate가 대체로 하나의 주요 구성 요소에 해당합니다.

기존 실행은 별도의 SQL 패키지 세 개를 포함해 54개의 crate까지 늘어났습니다. 새 실행은 초기에 9개의 crate로 정착한 뒤, 그 이후로는 하나도 추가하지 않았습니다.

이 모든 차이는 최종 코드베이스에 그대로 드러납니다. Fable 5 믹스에서는 기존 스웜과 새 스웜이 모두 결국 전체 스위트를 통과했지만, 기존 쪽은 엔진 코드가 64,305줄 필요했고 새 쪽은 9,908줄로 이를 해냈습니다. Opus 믹스도 같은 양상을 보였습니다. 기존 하네스에서는 19,013줄로 97% 점수를 받았고, 새 하네스에서는 4,645줄로 100%를 달성했습니다.

#모델 경제성

앞서 모든 모델 조합이 비슷한 품질을 보였지만 비용은 크게 달랐다고 말씀드렸습니다. Opus 4.8 하이브리드는 $1,339였던반면GPT-5.5단독은$10,565였습니다. 토큰 데이터는 그 차이가 어디에서 비롯되는지 보여줍니다.

지출 구조는 모든 실행에서 일관됐습니다. 워커가 최소 69%의 토큰을 차지했고, 대부분의 경우 90%를 넘었습니다.

하지만 달러 기준 비용 분포는 토큰 비중과 달랐습니다. planner 토큰의 단가가 더 높기 때문입니다. Opus 4.8과 Composer 2.5 조합에서는 planner 역할의 Opus가 전체 토큰 중 극히 일부만 생성했지만 전체 비용의 약 3분의 2를 차지했고, 워커 역할의 Composer는 나머지 3분의 1 비용으로 토큰의 대부분을 처리했습니다.

대규모 작업에서 실제로 프런티어 intelligence가 필요한 순간은 많지 않습니다. 예를 들어 초기 분해, 설계 결정, 그리고 일부 트레이드오프 판단 같은 경우입니다. 프런티어 planner가 이런 모호함을 상세하고 명확한 instruction으로 정리해 두고 나면, 더 저렴한 모델은 그 지침을 따르기만 하면 됩니다. 이는 비용 절감의 매우 큰 잠재 요인입니다. 계획자와 워커 모두에 GPT-5.5를 사용한 실행에서는 워커 비용만 $9,373가들었습니다.반면Opus4.8이계획을맡고Composer2.5가작업을수행한실행에서는전체워커집단의비용이$411이었습니다.

주목할 만한 점 하나는 두 하이브리드 실행을 비교해 보면 드러납니다. Fable 5 planner는 토큰당 가격이 거의 두 배였음에도 planning 토큰을 훨씬 적게 사용했기 때문에 Opus 4.8 planner보다 총비용이 약간 더 적었습니다. 하지만 Fable 실행의 워커는 토큰을 몇 배 더 많이 사용했고, 그 결과 실행 전체 비용은 훨씬 더 높아졌습니다.

#프롬프트로서의 스펙

AI 역량이 한 단계 도약할 때마다 엔지니어가 일할 수 있는 추상화 수준도 함께 높아졌습니다.

자동 완성은 엔지니어가 한 번에 코드 한 줄씩 작업할 수 있게 해주었습니다. 초기 모델은 이를 코드 블록 단위로 끌어올렸고, 에이전트는 파일이나 기능 단위까지 확장했습니다.

스웜에서는 작업의 단위가 스펙이 됩니다.

이 방식이 작동하려면 스웜이 실제로 스펙을 따라야 하며, 이 글의 상당 부분은 바로 그 이야기를 다룹니다. 우리는 스웜에 835페이지 분량의 서술형 문서를 주었고, 스웜은 데이터베이스를 만들어냈습니다. 이 실험에서 부족했던 것, 그리고 앞으로 소프트웨어 엔지니어링에서 점점 더 희소해질 것이라고 우리가 보는 것은 의도를 정확히 설명하는 일입니다.

이렇게 보면 스웜은 점점 컴파일러를 닮아갑니다. 컴파일러는 일련의 중간 단계를 거쳐 소스 코드를 기계어로 번역합니다. 스웜도 의도를 다룰 때 비슷한 일을 합니다. 계획자는 목표를 작업 트리로 파싱한 다음, 그것을 한 단계씩 실행 가능한 작업으로 구체화합니다. 차이점은 컴파일러는 모든 단계에서 의미를 보존하는 반면, 스웜은 모든 단계가 확률적이라는 점입니다. 이 글에서 설명하는 모든 것은 그 격차를 줄이기 위해 존재합니다.

스웜의 결과물을 직접 살펴보시길 바랍니다. 단독 Opus 4.8 실행에서 나온 코드베이스는 github.com/cursor/minisqlite에서 공개되어 있습니다. 처음 훑어본 인상으로는 매우 훌륭해 보이지만, 아직 더 깊이 있는 수동 분석은 하지 않았습니다. 직접 확인해 보시고, 무엇을 발견하셨는지 알려 주세요.