TECH REPORT · CURSOR RESEARCH 정리

에이전트 스웜과 새로운 모델 경제학
Agent Swarms and the New Model Economics — 상세 분석 리포트

원문 저자: Wilson Lin (Cursor) 원문 게시: 2026-07-20 리포트 작성: 2026-07-21
원문: EN · KO 결과물: github.com/cursor/minisqlite

1핵심 요지 (TL;DR)

• 새 스웜은 4가지 모델 조합 전부 sqllogictest 스위트 100% 통과. 기존 스웜 대비 코드량 1/4~1/6, 병합 충돌 ~1/70.
• 피크 초당 ~1,000커밋을 감당하기 위해 에이전트 전용 VCS를 자체 구축.
• 경제성 핵심 발견: Worker가 토큰의 69~90%+를 쓰지만, 비용의 약 2/3는 Planner(프런티어 모델)에서 발생. 프런티어 모델을 계획에만 쓰면 총비용 약 1/8 절감 ($10,565 → $1,339).
• 결론: 스웜은 "스펙을 프롬프트로 받는 확률적 컴파일러"이며, 앞으로 가장 희소한 역량은 코딩이 아니라 의도를 정확히 기술하는 능력.

2배경

• 이전 프로젝트(스웜으로 웹 브라우저 구축)는 개념 증명으로는 성공했으나 "완성도 높은 소프트웨어"에는 크게 미달.
• 이번에는 시스템을 의도적으로 설계한 뒤, 기존 스웜이 고전했던 과제(문서 기반 SQLite 구현)로 돌아가 재검증.

3아키텍처: 트리와 리프 (Trees and Leaves)

역할	모델 등급	담당
Planner	가장 뛰어난(프런티어) 모델	목표를 부분 작업으로 분해, 설계 결정, 하위 위임
Worker	더 빠르고 저렴한 모델	할당된 좁은 작업만 실행

• 고정 토폴로지를 강제하지 않음 — 과제의 윤곽에 맞춰 트리가 적응적으로 확장.
• 적용 과제: 브라우저 제작, 수학 문제, GPU 커널 최적화, 오픈소스 취약점 발견·수정, 테스트 커버리지 확대, 합성 학습 데이터 생성.

트리가 메모리(컨텍스트)에 해주는 것

• 단일 에이전트: 모든 조상 결정 + 현재 위치 + 전체 목표를 컨텍스트에 계속 유지해야 함 → 비효율.
• 분리 후: Planner는 저수준 구현 디테일로 오염되지 않고, Worker는 계획 고민 없이 좁은 작업에만 집중.
• 이론적 유추: 경제학자 Ronald Coase의 기업 이론 — 조정 비용이 작업 자체보다 빠르게 증가하기 때문에 조직이 계층화된다.

4에이전트 전용 버전 관리 시스템 (VCS)

• 커밋 규모: 이전 브라우저 스웜 시간당 ~1,000커밋 → 새 시스템 초당 ~1,000커밋 (피크). 약 3,600배.
• Git/Cargo류의 큰 단위 잠금(coarse locking)으로는 감당 불가 → VCS를 처음부터 자체 구축.
• 특징: 충돌 감지·조정 내장, 설계 결정을 컴파일 시 검증되는 참조(compile-checked references)로 기록.

5초당 1,000커밋에서의 5가지 실패 양상과 해법

#	실패 양상	증상	해법
1	스플릿 브레인 설계	서로 모르는 두 Planner가 같은 개념을 다르게 구현	Planner가 설계 결정을 직접 내리고, 위임된 하위 트리가 중복 결정하지 않도록 프롬프팅
2	Planner 간 경합	같은 파일을 두고 두 Planner가 변경을 반복 충돌	공유 설계 문서에 결정 기록 → 컴파일 검증 참조로 코드와 연결 → 중립 조정자가 문서 병합 → 참조 통해 다운스트림 전파
3	병합 충돌	Worker가 충돌 해결을 잘못 처리 (덮어쓰기·포기)	중립적인 제3 에이전트가 모든 당사자를 대신해 해결 (인간 팀의 머지 큐와 유사)
4	메가파일	특정 파일(1,000줄+)이 비대해져 모두가 손대며 충돌 폭증	Worker가 플래그 → 해당 파일 신규 커밋 차단 → 외부 에이전트가 작은 모듈로 분해
5	경직화 (Ossification)	기존 코드를 건드리길 꺼려 핵심 코드가 화석화	의도적 파괴 변경 허용 → 범위 밖은 국소 패치+주석 → 컴파일러가 전파 → 각 에이전트가 주석 읽고 자기 작업 갱신

6검토 렌즈 (Review Lenses)

• 실험한 검토 방식: 전체 대화 기록 검토 / 출력만 검토 / 코드베이스만 검토 / 서로 다른 모델·학습의 검토자.
• 핵심 발견: 단일 관점은 모두 불완전하지만, 상관성이 낮은(decorrelated) 관점들을 겹쳐 쌓으면 효과가 누적되어 "인간 이상의 신뢰성" 달성 가능 — 자율주행의 다중 센서 융합과 같은 원리.
• 검토 비용이 검토 대상 작업 비용보다 훨씬 저렴 → 효율적인 품질 게이트.

7스티그머지 (Stigmergy): 에이전트가 환경을 만들게 하기

• 개미·흰개미처럼 직접 통신 없이 환경 변화를 통해 조율하는 개념.
• 이전 방식: "메모 남겨라", "결정을 문서화해라" 같은 규칙 주입.
• 현재 방식: Field Guide — 에이전트가 전적으로 소유·관리하는 폴더.
  • index.md가 모든 에이전트 시작 시 자동 주입됨.
  • 포함 내용은 에이전트가 스스로 선별 (제약은 줄 수 예산뿐).
  • 원칙: 예상 밖의 경험(surprise)일수록 후속 에이전트의 궤적을 단축시키므로 기록 가치가 높음.
• 초기 실험 결과 유망. 에이전트가 처음부터 소유하지 않은(기존) 코드베이스에서 더 큰 효과 기대.

8SQLite 실험

실험 설계

항목	내용
과제	835페이지 SQLite 매뉴얼을 Rust로 구현
금지 사항	SQLite 소스코드, 테스트 스위트, SQLite 바이너리, 인터넷 접근
평가	sqllogictest — 정답이 알려진 수백만 개 쿼리의 정답률
블라인드	에이전트는 테스트 스위트의 존재를 모름
검증	사람이 직접 검토하여 부정행위 없음 확인

모델 조합 4종

설정	Planner	Worker	의도
1	GPT-5.5	GPT-5.5	프런티어 모델 단일
2	Grok 4.5	Grok 4.5	비용 효율적 프런티어 단일
3	Opus 4.8	Composer 2.5	프런티어 판단력 + 저렴한 실행
4	Fable 5	Composer 2.5	최상위 Planner + 저렴한 실행

성능 결과

• 4시간 컷오프: 새 스웜 전 조합 73~85% 통과 (Grok 4.5 조합은 80%). 기존 스웜은 11~77% (Grok 4.5는 통제 불능으로 2시간 전 중단).
• Fable 5 하이브리드는 첫 1시간 내 ~67% 도달.
• 최종: 새 스웜은 모든 조합이 스위트 100% 통과.
• 전략 다양성: 낮은 점수 유지 후 급상승하는 실행, 한 영역을 깊게 파 초반 점수 확보 후 정체하는 실행 등 — 에이전트가 스스로 전략 선택.

9신·구 스웜 심층 비교 (주로 Grok 4.5 기준)

지표	기존 스웜	새 스웜	배율
커밋 수 (첫 2시간)	68,000개	약 1/70 수준	~70×
병합 충돌 (누적)	70,000건+ (가속, 중단 전)	1,000건 미만 (4시간 전체)	~70×
최다 충돌 파일	7,771건 / 에이전트 1,173개 관여	47건	~165×
Crate 수	54개 (중복 SQL 패키지 3개 포함)	9개 (초기 확정 후 추가 없음)	6×

최종 코드 규모 (엔진 코드 줄 수)

모델 조합	기존 스웜	새 스웜	비고
Fable 5 계열	64,305줄 (100%)	9,908줄 (100%)	코드 1/6.5
Opus 4.8 계열	19,013줄 (97%)	4,645줄 (100%)	코드 1/4, 성능은 오히려 ↑

10모델 경제학 (Model Economics) — 글의 핵심 발견

토큰 vs 비용의 비대칭

• 토큰: Worker가 최소 69%, 대부분 실행에서 90% 이상 소비.
• 비용: 반대로 Planner(프런티어 모델)가 지배 — Opus 4.8 + Composer 2.5 조합에서 Opus는 토큰의 극히 일부만 쓰고도 비용의 약 2/3 차지.

총비용 비교

구성	총비용
GPT-5.5 (Planner + Worker 모두)	$10,565
Opus 4.8 Planner + Composer 2.5 Worker	$1,339 (~1/8)
Fable 5 Planner + Composer 2.5 Worker	Opus 하이브리드보다 높음

Worker 비용만 비교

구성	Worker 비용
GPT-5.5 Worker 함대	$9,373
Composer 2.5 Worker 함대 (Opus Planner 하)	$411 (~1/23)

절감 메커니즘

• 프런티어 모델이 정말 필요한 순간은 제한적: 초기 분해, 설계 결정, 트레이드오프 판단.
• 프런티어 Planner가 이를 명확한 지침으로 정리하면, 저렴한 모델은 지침을 따르기만 하면 됨.

Fable 5 vs Opus 4.8 (Planner 비교)

• Fable 5: 토큰 단가 ~2배이지만 계획 토큰을 훨씬 적게 씀 → Planner 비용 자체는 약간 더 낮음.
• 그러나 Fable 5 실행에서는 Worker(Composer)가 토큰을 몇 배 더 소비 → 전체 실행 비용은 더 높음.

11프롬프트로서의 스펙 (Specs as Prompts)

추상화 수준의 진화

단계	도구	추상화 단위
1	자동완성	코드 한 줄
2	초기 모델	코드 블록
3	에이전트	파일 / 기능
4	에이전트 스웜	스펙(사양서) 전체 — 835페이지 서술형 문서 → 동작하는 DB

컴파일러 유추

• 컴파일러: 소스코드 → 중간 표현들 → 기계어. 모든 단계에서 의미 보존이 결정론적.
• 스웜: 의도 → 작업 트리 → 단계별 구체화 → 구현. 모든 단계가 확률적.
• 이 글의 모든 기법은 결국 이 확률적 격차를 좁히기 위한 것.

이 실험에서 가장 부족했던 자원은 컴퓨팅도 모델도 아닌 "의도를 정확히 설명하는 능력"이었다 — 앞으로 소프트웨어 엔지니어링에서 가장 희소한 역량이 될 것이다.

12공개 및 각주

• Opus 4.8 단독 실행 결과물을 github.com/cursor/minisqlite로 공개. 초기 인상은 매우 훌륭하나 깊이 있는 수동 분석은 아직 미시행 → 커뮤니티 검토·발견 공유 독려.
• 각주 1 — 모델 단독 실행: Opus 4.8·Fable 5의 스웜 없는 단독 실행도 수행(차트에 사선 무늬로 표시)했으나 비공식 평가만 진행. 둘 다 좋은 성능 예상.
• 각주 2 — GPT-5.6 Sol 제외 사유: 프런티어 설정으로 쓰려 했으나, 문자 그대로의 표현·강조 문구에 과민 반응하며 다른 모델에서는 없던 통제 불능 악순환(runaway spirals) 발생. 프롬프트 조정 시간이 부족해 GPT-5.5로 회귀.