Cursor가 에이전트로 SQLite를 다시 만들었을 때 비용이 $10,565 vs $1,339로 갈린 이유

같은 일을 시켰는데, 한쪽은 $10,565, 다른 쪽은 $1,339.

품질은 비슷했다. 둘 다 결국 숨겨진 SQL 테스트 스위트를 100% 통과했다.

Cursor가 공개한 실험이다. 수백 개 에이전트에게 SQLite 공식 매뉴얼 835페이지만 주고, 소스코드·바이너리·테스트·인터넷은 전부 막은 채 Rust로 데이터베이스를 다시 만들게 했다. 결과는 "모델이 똑똑하냐"보다 일을 어떻게 쪼개고, 누가 계획하고 누가 실행하느냐가 비용을 좌우했다는 쪽에 가깝다.

이 글은 Cursor 공식 블로그 Agent swarms and the new model economics를 바탕으로, 실험이 무엇을 했는지부터 숫자와 해석 가능한 결론까지 정리한다. 회사 내부 1회 비교이므로, 개인 프롬프트 비용에 숫자를 그대로 대입하면 안 된다.

 

1. 배경: 왜 하필 SQLite인가

Cursor는 올해 초부터 "에이전트 여러 개를 한 목표로 협력시키면, 단일 에이전트가 못 다루는 규모의 일이 가능한가"를 실험해 왔다. 초기의 대표 과제는 웹 브라우저를 처음부터 만드는 것이었다. 개념 증명으로는 성공했지만, 완성된 소프트웨어라고 보긴 어려웠다.

그 다음 검증용으로 고른 게 SQLite 재구현이다. 이유는 분명하다. 명세가 길고, 정답 검증이 가능하며, 예전 스웜이 특히 고전했던 과제이기 때문이다. 이번 실험에서는 구 하네스와 신 하네스를 같은 모델·같은 시간 예산으로 비교했다.

에이전트에게 준 것은 공식 SQLite 매뉴얼 835페이지뿐이다. 주지 않은 것은 더 많다.

• SQLite 소스코드
• 공식 테스트 스위트
• SQLite 바이너리
• 인터넷 접속

채점 기준은 sqllogictest다. 같은 쿼리에 대해 다른 DB 엔진과 같은 답을 내는지 보는 테스트로, 수백만 개 쿼리와 정답이 있다. 점수는 맞힌 비율이다. 중요한 점은 스웜이 이 테스트의 존재 자체를 몰랐다는 것이다. Cursor는 실행 후 수동으로 부정행위·지름길 여부를 점검하고, 코드가 테스트 근처만 때운 게 아니라 고르게 구현됐는지도 봤다고 밝혔다.

 

2. 구조: Planner와 Worker

큰 일은 자연스럽게 트리 모양이 된다. 맨 위 목표가 있고, 아래로 갈수록 작은 작업 단위로 쪼개진다. Cursor 스웜은 그 트리 위에 두 역할을 올린다.

• Planner: 목표를 쪼개고 위임한다. 보통 가장 똑똑한 프론티어 모델.
• Worker: 잘린 조각을 실행한다. 보통 더 빠르고 저렴한 모델.

단일 에이전트가 전체 트리를 혼자 들고 다니면 두 가지 중 하나를 잃기 쉽다. 눈앞 구현에 집중하면 큰 그림을 잃고, 큰 그림을 붙잡으면 세부 구현 품질이 떨어진다. 스웜에서는 Planner가 구현을 하지 않아 컨텍스트가 저수준 디테일로 오염되지 않고, Worker는 계획하지 않아 한 조각에 컨텍스트를 몰아줄 수 있다.

Cursor는 이 효율이 단순 병렬성보다 더 중요할 수 있다고 본다. 수백 개 에이전트를 동시에 돌리는 것 자체보다, 누가 어떤 맥락을 들고 어떤 결정을 하느냐가 스케일을 만든다는 해석이다.

 

3. 왜 일반 Git으로는 안 됐나

사람 팀 속도에서는 Git과 코드리뷰, 머지 큐가 대충 버틴다. 에이전트 수백 개가 동시에 커밋하면 얘기가 달라진다.

예전 브라우저 스웜은 Git 기준 시간당 약 1,000 커밋 수준이었다. 새 시스템은 초당 약 1,000 커밋까지 올라간다고 한다. 그래서 Cursor는 에이전트용 버전 관리 시스템을 새로 만들었다. 처리량 때문만이 아니다. 모든 변경이 그 층을 지나기 때문에, 충돌이 처음 보이는 지점이 되고, 아래 조율 메커니즘도 그 안에 구현된다.

새 하네스가 다룬 실패 모드는 대략 이런 것들이다.

• Split-brain design: 서로 모르는 Planner 둘이 같은 개념을 다른 방식으로 구현. Planner가 설계 결정을 직접 내리고, 같은 질문을 두 하위 트리가 동시에 결정하지 않게 강제.
• Planner 간 쟁탈: 서로 알면서 같은 파일을 밀고 당김. 공유 설계 문서에 결정을 기록하고, 코드가 그 문서를 참조하게 해서 모순이 생기면 중재자가 문서를 합친다.
• Merge conflict: Worker는 충돌 해결을 잘 못 한다. 중립 제3 에이전트가 대신 병합.
• Megafile: 인기 파일에 코드가 계속 붙으며 비대해짐. 신고되면 신규 커밋을 막고 별도 에이전트가 모듈로 분해.
• Ossification: 에이전트가 핵심 코드를 건드리지 않으려는 관성. 의도적 파괴를 허용하고, 이유를 남기면 컴파일 에러를 통해 다른 에이전트가 따라 고치게 함.

여기에 Field Guide라는 실험도 있다. 에이전트가 소유하는 공유 폴더로, 시작 시 모든 에이전트에 자동 주입된다. 모델 가중치는 고정되어 있으니, 예상 못 한 경험을 남겨 다음 에이전트의 경로를 줄이자는 발상이다. 개인이 일하면서 실패/성공을 메모로 쌓아 다음 작업 비용을 줄이는 것과 같은 방향이다.

 

4. 바쁜 척과 진도의 차이

숫자만 보면 헷갈린다. 구 하네스 Grok 4.5 런은 첫 두 시간에 커밋 6만 8천 개를 찍었다. 새 하네스의 약 70배 속도다.

그런데 merge conflict는 7만 개를 넘겼고, 안정화되지 않고 가속되다가 중단됐다. 새 런은 4시간 동안 conflict 1천 개 미만이었다. 구 런에서 가장 뜨거운 파일 하나는 conflict 7,771개, 에이전트 1,173명이 건드렸다. 새 런에서 가장 분쟁 많은 파일은 47개였다.

패키지 구조도 달랐다. 구 런은 crate 54개까지 퍼졌고 SQL 패키지가 세 개로 갈라졌다. 새 런은 초반에 crate 9개로 정리한 뒤 더 늘리지 않았다.

같은 100% 통과라도 코드 양은 크게 달랐다.

• Fable 5 믹스: 구 하네스 엔진 코드 64,305줄 vs 신 하네스 9,908줄
• Opus 믹스: 구 하네스 19,013줄(97%) vs 신 하네스 4,645줄(100%)

커밋이 많다고 잘 만든 게 아니다. 활동량과 생산성을 같은 말로 쓰면 안 된다.

 

5. 모델 조합과 점수

Cursor가 비교한 네 구성은 이렇다.

1. GPT-5.5 Planner + GPT-5.5 Worker
2. Grok 4.5 Planner + Grok 4.5 Worker
3. Opus 4.8 Planner + Composer 2.5 Worker
4. Fable 5 Planner + Composer 2.5 Worker

4시간 컷오프 기준 신 하네스는 73~85%, 구 하네스는 11~77%였다. Fable 하이브리드는 첫 1시간에 약 2/3까지 올라갔다. 구 Grok 4.5는 2시간 전에 중단됐다. 신 하네스 구성은 이후 모두 스위트 100%를 통과했다.

참고로 Cursor는 원래 GPT-5.6 Sol을 프론티어 구성으로 쓰고 싶었다고 밝혔다. 그런데 이 모델은 강조 문구에 더 민감했고, 다른 모델에서 못 보던 폭주 루프가 나와 프롬프트 튜닝 시간이 부족했다. 한 모델만 따로 튜닝하면 비교가 기울어지므로 GPT-5.5로 대체했다. 하네스 결과가 모델마다 자동 이식되지 않는다는 경고로 읽힌다.

 

6. 비용이 갈린 지점

이미지 출처: Cursor Blog, “Agent swarms and the new model economics”

공식 글에서 명시적으로 비교한 총비용 끝점은 이렇다.

• GPT-5.5가 Planner+Worker 전부: $10,565
• Opus 4.8 Planner + Composer 2.5 Worker: $1,339

차트에 같이 보이는 비공식 solo 런까지 포함하면 폭이 더 커진다. 비공식 Fable 5 solo $20,057 대비 Opus+Composer $1,339는 약 15배 이야기다. 다만 Cursor도 이 solo 런은 비공식적으로만 채점했다고 밝혔으므로, 통제 비교의 핵심은 GPT-5.5 $10,565 vs 하이브리드 $1,339(약 7.9배)로 보는 편이 안전하다.

이미지 출처: Cursor Blog, “Agent swarms and the new model economics”

토큰 구조는 일관됐다. Worker가 거의 모든 런에서 토큰의 69% 이상, 대개 90% 이상을 먹었다. 그런데 달러 비중은 달랐다. Opus+Composer 믹스에서 Opus는 토큰 비중은 작지만 Planner 단가가 비싸 비용의 약 2/3를 차지했다. Worker 함대 전체는 $411.

GPT-5.5를 Worker로 돌린 쪽은 Worker만 $9,373이었다. 같은 실행 층을 Composer로 바꾼 순간 비용 구조가 바뀐 셈이다.

Cursor의 해석도 여기에 가깝다. 큰 일에서 프론티어 지능이 진짜 필요한 순간은 생각보다 적다. 최초 분해, 설계 결정, 몇몇 트레이드오프. 그 애매함이 상세하고 명시적인 지시로 붕괴된 뒤에는, 더 싼 모델이 따라가면 된다.

 

7. 비싼 모델이 더 좋은 계획을 보장하진 않았다

여기서 제일 흥미로운 건 Fable 5다.

Fable Planner는 토큰당 가격이 Opus보다 대략 두 배였는데, 계획에 쓴 토큰 수가 적어 Planner 청구액 자체는 조금 더 낮았다. 문제는 그 다음이다. Worker가 토큰을 몇 배나 더 태웠고, 전체 런 비용은 훨씬 비싸졌다. 차트 기준으로 Fable+Composer는 $2,234, Opus+Composer는 $1,339 근처다.

그래서 이 실험에서 말할 수 있는 건 이 정도다.

모델 단가와 계획의 효율이 자동으로 비례하진 않았다.

Fable 계획이 "나쁘다"거나 "애매하다"고 단정할 근거는 없다. Cursor가 계획 품질을 직접 채점한 것도 아니고, Fable 하이브리드는 첫 1시간에 테스트의 약 2/3까지 가기도 했다. 다만 최종 영수증을 보면, 앞단에서 애매함을 덜 걷어내면 뒤단 실행이 비싸진다는 해석은 가능하다. 계획 비용이 싸 보여도, Worker 낭비까지 합산하면 전체가 비싸질 수 있다.

 

8. 과대해석하면 안 되는 것

이 실험을 "이제 코딩은 의도만 설명하면 된다"로 읽으면 과하다. 반론도 분명하다.

• SQLite 관련 코드가 모델 학습 데이터에 이미 들어 있을 수 있다.
• 매뉴얼 자체가 기존 구현에서 나온 문서다.
• 하네스는 모델마다 따로 조율이 필요했다. GPT-5.6 Sol은 이번 비교에서 빠졌다.
• 회사 내부 실험 1회 비교이지, 개인 업무 프롬프트에 같은 배율이 적용된다는 증명은 아니다.

Cursor 스스로도 이 구조를 컴파일러에 비유한다. 스펙을 단계적으로 실행 가능한 작업으로 낮춘다는 점에서는 비슷하지만, 매 단계가 확률적이다. 이 글 전체가 그 확률 간극을 줄이려는 조율 이야기다. 산출물 예시는 github.com/cursor/minisqlite에 공개되어 있다. Cursor도 깊게 수동 분석하진 않았다고 밝혔으니, 참고용으로 보는 편이 맞다.

 

9. 그래서 개인 작업에 남는 것

실무적으로 남는 감각은 이렇다.

• 일을 크게 맡기기 전에, 모호한 지점을 먼저 문장으로 고정할수록 뒤 토큰이 줄어든다.
• 비싼 모델을 모든 단계에 깔면 안전해 보이지만, 실제로는 Worker 층이 돈을 태운다.
• 커밋 수, 활동 로그, "바쁘게 돌아가는 화면"은 진도 지표가 아니다.
• 계획의 좋고 나쁨은 계획 문장 자체보다, 그 계획이 만든 실행 낭비로 재는 편이 낫다.

한 줄로 남기면 이렇다. 에이전트 시대의 절약은 모델 할인쿠폰보다, 앞단 설명의 품질에서 나온다.

혼자 일할 때도 같은 원리를 축소해 쓸 수 있다. 먼저 "무엇을 만들지 / 무엇을 하지 말지 / 성공 기준 / 건드리면 안 되는 것"을 짧게 고정하고, 그다음에 구현 에이전트를 돌리는 식이다. 완벽한 스웜을 흉내 낼 필요는 없다. 다만 애매한 목표를 통째로 던지고 토큰이 타는 걸 모델 탓으로만 돌리기엔, 이 실험의 영수증이 너무 노골적이다.

 

참고

• Cursor Blog — Agent swarms and the new model economics
• github.com/cursor/minisqlite (Opus solo 산출물)
• sqllogictest 소개

작성: 2026년 7월 22일. 수치·모델명·비용은 Cursor 공식 블로그 기준. 차트 이미지 출처 동일. 회사 내부 실험 비교이므로 개인/팀 프롬프트 비용에 배율을 그대로 적용하면 안 된다.