Cursor의 에이전트 스웜과 새로운 모델 경제학: '품질은 같아도 비용은 8배까지 차이날 수 있다'

9bow · 7월 22, 2026, 1:30오전

Cursor의 에이전트 스웜 소개: 수백 개의 에이전트를 하나의 목표로 묶기

AI 코드 에디터를 만드는 Cursor는 올해 초부터 "여러 에이전트를 협력시켜 하나의 목표를 향해 규모를 키우면, 지금까지 한 개의 에이전트로는 닿지 못하던 규모와 복잡도의 작업을 풀 수 있지 않을까" 라는 가설을 실험해 왔습니다. 이 실험의 상징적인 프로젝트는 바닥부터 웹 브라우저를 만드는 장시간 스웜이었습니다. 개념 증명으로는 성공했지만 완성도 높은 소프트웨어에는 한참 못 미쳤고, 그 과정은 철저히 경험적이었습니다. 백지 상태에서 시작해 안정적이고 효과적인 시스템을 향해 조금씩 언덕을 오르듯 개선해 온 것입니다.

이번 글은 그 다음 단계에 대한 이야기입니다. Cursor는 스웜을 "우연히 굴러가는 것" 이 아니라 "의도적으로 설계할 수 있을 만큼" 이해하는 것을 목표로 삼았고, 그 진전을 확인하기 위해 예전 스웜이 고전했던 과제로 되돌아갔습니다. 바로 오직 문서만 보고 SQLite를 Rust로 처음부터 다시 만드는 것 입니다. 원본 소스 코드도, 테스트 스위트도, SQLite 바이너리도, 인터넷 접속도 모두 차단한 채 SQLite의 835페이지짜리 매뉴얼 하나만 던져 주고 Rust로 데이터베이스 엔진을 구현하게 한 것입니다.

초기 결과는 고무적이었습니다. 같은 모델, 같은 시간 예산으로 예전 스웜과 새 스웜을 나란히 돌렸을 때, 새 스웜은 모든 모델 조합에서 더 나은 성적을 냈습니다. Grok 4.5를 사용한 경우 새 스웜은 네 시간 만에 SQL 테스트 스위트의 80%를 통과한 반면, 예전 스웜은 두 시간을 채우기도 전에 통제 불능 상태에 빠져 중단해야 했습니다. 그런데 정작 이 글에서 가장 흥미로운 대목은 성능이 아니라 비용 입니다. 어떤 모델에게 어떤 역할을 맡기느냐에 따라 품질은 비슷했지만 비용은 최소 $1,339에서 최대 $10,565까지, 약 8배 가까이 벌어졌습니다.

차트에서 별표()가 붙은 Opus 4.8와 Fable 5*는 프런티어 모델을 단독으로 돌려 비용 감만 잡아 본 비공식 실행으로, 정식 통제 비교에는 포함되지 않습니다(품질은 대략적으로만 채점했습니다). 아래에서 자세히 다루는 네 가지 통제 구성의 비용이 $1,339에서 $10,565 사이에 놓입니다.

이 글은 그 비용 차이가 어디에서 오는지, 그리고 그것을 설명하기 위해 Cursor가 스웜의 내부 구조를 어떻게 설계했는지를 하나씩 풀어 갑니다. 결론을 먼저 요약하면, 큰 작업에서 진짜로 프런티어급 지능이 필요한 순간은 몇 되지 않으며(원래의 작업 분해, 설계 결정, 몇몇 트레이드오프 정도), 프런티어 모델이 그 모호함을 명확한 지시로 정리해 두면 나머지 실행은 훨씬 저렴한 모델이 그대로 따라 하기만 하면 된다는 것입니다. 이 구조를 안정적으로 돌아가게 만드는 여러 조율 장치가 이 글의 핵심입니다.

트리와 잎: 큰 작업은 자연스럽게 나무 모양이 된다

큰 작업에 대한 설명은 자연스럽게 트리(tree) 의 형태를 띱니다. 뿌리에 목표가 있고, 그 목표가 재귀적으로 더 작은 작업 단위로 갈라져 내려가 마침내 잎에 해당하는 기본 작업 단위에 도달하는 구조입니다. Cursor의 스웜은 바로 이 트리 형태의 분해를 중심으로 두 가지 역할을 둡니다.

플래너(Planner) 에이전트: 가장 똑똑한 모델이 맡으며, 목표를 여러 조각으로 나누고 그것을 위임합니다.
워커(Worker) 에이전트: 대체로 더 빠르고 저렴한 모델이 맡으며, 나뉜 조각을 실제로 실행합니다.

이 설계는 고정된 위상(topology)을 강제하는 경직된 오케스트레이션 시스템의 상위 집합(superset) 입니다. 문제에 미리 정해진 구조를 씌우는 대신, 스웜의 모양이 문제의 윤곽을 따라 자라나면서 연산량과 컨텍스트가 작업의 복잡도에 비례해 늘어납니다. Cursor는 바로 이 유연함 덕분에 같은 설계가 브라우저 만들기, 수학 문제 풀이, GPU 커널 최적화처럼 서로 다른 과제로 두루 일반화된다고 봅니다. 내부적으로는 오픈소스 소프트웨어의 취약점을 찾아 고치거나, 자사 코드베이스의 테스트 커버리지를 높이거나, 수십억 토큰 규모의 합성 학습 데이터를 생성하는 데에도 이 구조를 써 왔습니다.

이렇게 작업을 계층적으로 나누어 여러 에이전트에게 위임하는 접근은 커뮤니티에서도 활발히 논의되어 왔습니다. 특히 Anthropic이 공개한 멀티 에이전트 기반 연구 시스템은 리드 에이전트가 하위 에이전트에게 조사를 위임하는 유사한 오케스트레이션 구조를 다루고 있어 함께 읽어 볼 만합니다.

트리가 메모리를 위해 하는 일: 병렬성보다 중요한 컨텍스트 효율

하나의 에이전트가 완결된 작업 전체를 떠맡으면, 그 에이전트는 트리 전체를 혼자 걸어 다녀야 합니다. 각 잎으로 내려가는 동안 조상 노드들과 현재 위치, 그리고 더 넓은 목표까지 내내 컨텍스트에 담고 있어야 하는 것입니다. Cursor는 장시간 돌아가는 단일 에이전트가 표류(drift)하는 이유를 여기서 찾습니다. 눈앞의 작업에만 집중하면 큰 그림을 놓치고, 큰 그림을 붙들고 있으면 각 조각을 제대로 해내지 못하는, 둘 중 하나로 귀결되기 쉽다는 것입니다.

반면 스웜에서는 플래너가 결코 직접 구현하지 않으므로 그 컨텍스트가 저수준 세부 사항으로 채워지지 않고, 워커는 결코 계획을 세우지 않으므로 자신의 컨텍스트 전부를 하나의 좁은 작업에만 쓸 수 있습니다.

여기서 Cursor는 스웜의 확장성이 병렬성 그 자체보다는 이러한 컨텍스트 효율(context efficiency) 에서 나온다고 추측합니다. 이 효율은 스웜의 모든 규모에서 존재하기 때문에, 이 분해 방식은 중간 규모의 작업에서도 에이전트 성능을 끌어올립니다. 즉 "에이전트를 많이 띄우니까 빨라진다" 가 아니라 "각 에이전트가 감당할 만큼만 들고 있으니까 잘한다" 는 쪽에 무게를 둡니다.

이런 구조에는 다른 분야의 메아리도 있습니다. 경제학자 로널드 코즈(Ronald Coase)는 "애초에 왜 기업이라는 것이 존재하는가" 라는 질문에 답하며, 조율 비용이 일 자체보다 더 빠르게 늘어나기 때문에 조직은 모두가 모두와 대화하도록 두는 대신 경계가 정해진 단위들의 계층으로 정착한다고 주장했습니다. 에이전트 스웜의 계층 구조도 같은 압력에 대한 응답인 셈입니다.

에이전트를 위한 버전 관리 시스템: 초당 1,000커밋을 견디는 계층

Git이나 Cargo 같은 도구는 동시성 제어를 위해 굵직한 잠금(coarse lock)에 의존합니다. 개발자 한 명에게는 문제가 없지만, 수백 개의 에이전트가 동시에 쏟아내는 작업량에는 감당이 되지 않습니다. 올해 초의 브라우저 스웜은 Git에서 시간당 약 1,000커밋으로 정점을 찍었는데, 새 시스템은 초당 약 1,000커밋으로 정점을 찍습니다. 시간 단위가 초 단위로 바뀐 것입니다.

이 정도 활동량을 감당하기 위해 Cursor는 새로운 버전 관리 시스템(VCS, Version Control System) 을 처음부터 직접 만들었습니다. 처리량만이 이유는 아니었습니다. 시스템의 모든 변경이 VCS를 통과하므로, 이곳이 바로 충돌이 가장 먼저 드러나는 지점이 됩니다. 뒤에서 설명할 여러 조율 장치 상당수가 바로 이 VCS 안에 직접 구현되어 있습니다.

수십 개의 코딩 에이전트를 Git 위에서 안정적으로 조율하는 문제는 커뮤니티에서도 뜨거운 주제입니다. 예를 들어 Gas Town은 20~30개의 AI 코딩 에이전트를 Git 기반으로 조율하는 멀티 에이전트 오케스트레이션 시스템으로, Cursor가 자체 VCS로 풀려 한 문제를 다른 각도에서 접근한 사례라 비교해 볼 만합니다.

에이전트 스웜 더 알아보기

Scaling agents: 에이전트 스웜으로 바닥부터 브라우저 만들기 - Cursor의 초기 대규모 스웜 실험

Self-driving codebases - 스웜이 스스로 코드베이스를 운영하도록 만든 과정

Multi-agent kernels: 스웜으로 GPU 커널 최적화하기 - 같은 설계의 다른 응용

초당 1,000커밋에서 드러나는 다섯 가지 실패 양상

사람으로 이루어진 엔지니어링 팀에는 코드 리뷰, 소유권(ownership), 스탠드업, 머지 큐(merge queue) 같은 표준적인 조율 장치가 있습니다. 이 장치들은 사람의 속도에서는 잘 작동하지만, 스웜의 커밋 속도에서는 사람 팀이 좀처럼 마주치지 않는 새로운 실패 양상이 나타납니다. Cursor는 이를 다섯 가지로 정리했습니다.

스플릿 브레인(Split-brain): 두 플래너가 같은 개념을 따로 구현

서로의 존재를 모르는 두 플래너가 같은 개념을 코드베이스의 서로 다른 곳에 서로 다른 방식으로 구현해 버리는 문제입니다. Cursor는 이를 프롬프트로 해결했습니다. 플래너가 설계 결정을 위임하지 않고 스스로 내리도록 하고, 위임된 두 하위 트리가 같은 질문을 각자 결정하는 일이 없도록 보장하게 만든 것입니다.

플래너 간 경합(Contention): 같은 파일을 두고 벌이는 줄다리기

더 까다로운 형태의 경합은 두 플래너가 서로의 존재를 알면서도 같은 파일을 두고 변경을 주고받으며 다투는 경우입니다. 문제의 본질은 "현실에 대한 두 개의 서로 다른 그림" 이고, 병합 도구는 이런 의견 불일치를 해소하지 못합니다. Cursor는 대신 에이전트들이 결정을 공유 설계 문서(design doc)에 기록하게 했습니다. 어떤 결정에 의존하는 코드는 그 문서로 되돌아가는, 컴파일 시점에 검사되는 참조를 지니게 됩니다. 두 플래너가 서로 모르게 모순된 결정을 내리면, 조정자(reconciler)가 문서들을 병합하고 그 참조들이 하류로 해결책을 전파합니다.

병합 충돌(Merge conflicts): 중립적인 제3의 심판

스웜 안에서 에이전트들은 끊임없이 같은 파일에서 충돌합니다. 충돌을 해소하려면 하던 일을 멈추고 상대의 컨텍스트를 흡수한 뒤 그 주변을 병합해야 하는데, 워커 에이전트는 이 작업을 잘 못합니다. 실제로는 상대의 변경을 덮어쓰거나 자기 변경을 포기해 버립니다. Cursor는 중립적인 제3의 에이전트가 병합 충돌에 개입해 모든 당사자를 대신해 해소하는 시스템을 만들었습니다. 이 에이전트의 유일한 목표는 공정하고 효율적인 것으로, 엔지니어링 팀의 머지 큐가 작동하는 방식과 닮았습니다.

메가파일(Megafiles): 모두가 몰리는 비대한 파일

어떤 파일은 유난히 에이전트들이 작업하기 좋아하는 장소가 됩니다. 각 에이전트는 코드를 조금씩만 추가하고, 그 파일을 작게 유지하는 책임은 누구에게도 없습니다. 이렇게 비대해진 "메가파일" 은 전송, 비교(diff), 병합에 비용이 많이 들고 끊임없는 충돌의 현장이 되어 모든 것을 질식시킵니다. Cursor는 워커 에이전트가 비대해진 파일에 깃발을 꽂을 수 있게 했습니다. 일단 표시되면 새 커밋을 막고, 외부 에이전트가 그 과대 성장한 파일을 더 작은 모듈로 분해합니다.

경직화(Ossification): 핵심 코드를 건드리지 못하는 습관

에이전트들은 사람이 개입하는 기존 코드베이스에서 일하며, 바꿔야 할 때조차 핵심 코드는 건드리지 않는 습관을 학습해 왔습니다. Cursor는 이를 의도적인 파손(intentional breakage)을 허가 하는 방식으로 풀었습니다. 어떤 핵심 변경이 가치 있다고 판단한 에이전트는 자기 범위 밖이더라도 집중적인 패치를 가하고, 왜 그렇게 했는지 설명하는 주석을 남깁니다. 그러면 컴파일러가 그 변경을 시스템 전체로 실어 나르고, 옛 설계에 의존하던 모든 것이 빌드에 실패합니다. 그 오류에 부딪힌 각 에이전트는 남겨진 주석을 찾아 이유를 읽고, 자신의 작업을 새 설계에 맞게 갱신합니다.

리뷰 렌즈: 상관 없는 시선을 쌓아 오류를 걸러내기

장시간 돌아가면서 동시에 여러 에이전트가 참여하는 시스템에서는 오류가 누적됩니다. 스웜은 작은 실수가 토대가 되어 굳어지기 전에 스스로를 교정할 방법이 필요합니다. Cursor는 여러 종류의 리뷰 렌즈(review lens) 를 실험했습니다. 리뷰 에이전트에게 워커의 전체 대화 기록(transcript)을 주기도 하고, 결과물만 주기도 하고, 아무것도 없이 코드베이스만 주기도 했습니다. 또 서로 다른 학습과 성격을 가진 다른 모델로 리뷰어를 돌려 보기도 했습니다.

핵심 발견은 이것입니다. 어떤 단일 렌즈도 모든 것을 잡아내지는 못하지만, 서로 상관 없는(decorrelated) 렌즈들은 쌓인다 는 것입니다. 자율주행 시스템이 어느 하나의 완벽한 부품 없이도 사람을 능가하는 신뢰성에 도달하는 것과 같은 원리입니다. 게다가 리뷰에 들이는 연산은 감사 대상인 작업보다 훨씬 저렴하므로, 리뷰에 쓴 비용은 수익률이 높습니다. Cursor는 이렇게 쌓아 올린 리뷰 시스템이 실행 내내 품질을 유지하는 데 크게 기여했다고 봅니다.

에이전트가 환경을 빚게 하기: 스티그머지와 필드 가이드

스티그머지(Stigmergy)는 개미나 흰개미 같은 군집 생물이 직접 소통하지 않고도 조율하는 메커니즘입니다. 그들은 환경을 바꾸고, 그 환경이 다시 다음 개체를 이끕니다. Cursor는 예전 실행에서 "메모를 남겨라", "결정을 문서화하라" 같은 규칙을 그냥 당연히 좋아 보여서 넣었는데, 돌이켜 보니 이 규칙들이 에이전트가 미래의 자기 자신과 동료를 위해 지식을 제도화하도록 만들고 있었다고 말합니다.

Cursor는 이 아이디어를 더 밀어붙여 스스로 작성하고 공유하는 컨텍스트, 이른바 필드 가이드(Field Guide) 실험을 진행했습니다. 이것은 전적으로 에이전트가 소유하는 폴더로, 그 안의 index.md가 모든 에이전트가 시작할 때 자동으로 주입됩니다. 가이드에 무엇을 담을지 큐레이션하는 것은 에이전트의 몫이며, 유일한 제약은 줄 수 예산(line budget)뿐입니다.

가이드의 밑바탕에 깔린 논리는 명료합니다. 모델 가중치는 얼어붙어 있으므로(frozen), 정확히 그 놀라운 마주침(surprise encounter) 이야말로 붙잡아 둘 가치가 있고, 그래야 다음 에이전트의 궤적이 더 짧아진다는 것입니다. 필드 가이드는 아직 초기 실험이지만 결과는 유망하며, Cursor는 에이전트가 완전히 소유하지 않은 코드베이스에서는 그 이점이 더 클 것으로 봅니다. "더 나은 포착이 더 나은 보상으로 이어지도록, 후임자를 위해 글을 쓰도록 모델을 학습시키는 것" 은 흥미로운 후속 연구 주제라고 덧붙입니다.

SQLite 실험: 835페이지 매뉴얼만으로 데이터베이스 만들기

앞서 설명한 모든 개선을 갖춘 새 버전의 스웜에게, Cursor는 835페이지에 달하는 SQLite 매뉴얼 전체를 Rust로 구현하라고 지시했습니다. 소스 코드, 테스트 스위트, SQLite 바이너리, 인터넷 접속은 모두 차단했습니다. 오직 산문으로 된 명세만 주어진 셈입니다.

진행 상황을 측정하기 위해 sqllogictest를 채점 기준으로 삼았습니다. 이것은 서로 다른 데이터베이스 엔진이 같은 쿼리에 대해 같은 결과를 반환하는지 확인하기 위해 SQLite 프로젝트가 만든 테스트 스위트로, 정답이 알려진 수백만 개의 쿼리를 담고 있습니다. 채점 점수는 스웜이 만든 데이터베이스가 맞힌 비율이고, 진전은 실행 내내 상승하는 곡선으로 나타납니다.

여기서 눈여겨볼 점이 두 가지 있습니다. 첫째, 스웜에게는 이 테스트 스위트의 존재 자체를 알려 주지 않았습니다. 각 실행이 끝난 뒤 Cursor는 코드와 실행 과정을 직접 검토해 부정행위나 지름길이 없는지 확인하고, 시스템이 테스트가 들여다보는 곳에만 몰려 만들어진 것이 아니라 고르게 구축되었는지 점검했습니다. 둘째, 곡선을 읽을 때는 에이전트가 스스로 전략을 골랐다는 사실을 염두에 두어야 합니다. 어떤 실행은 넓은 토대를 먼저 다지느라 몇 시간 동안 낮은 점수를 유지하다 후반에 급등했고, 어떤 실행은 한 영역을 깊게 파고들어 일찍 점수를 올린 뒤 나머지를 채우는 동안 정체되었습니다. 따라서 특정 순간의 정확한 점수보다 추세 가 더 중요합니다.

모델 조합별 결과: 하네스가 바뀌면 행동이 달라진다

Cursor는 능력과 비용을 아우르는 네 가지 구성을 시험했습니다.

GPT-5.5를 플래너와 워커 모두에 사용: 처음부터 끝까지 강력한 프런티어 모델로 채운 구성.
Grok 4.5를 플래너와 워커 모두에 사용: 비용 효율이 좋은 프런티어 모델을 비교점으로.
Opus 4.8을 플래너로, Composer 2.5를 워커로: 프런티어급 판단과 효율적인 실행의 결합.
Fable 5를 플래너로, Composer 2.5를 워커로: 한 단계 위 플래너가 이 하이브리드를 더 낫게, 혹은 오히려 더 못하게 만드는지 확인하기 위한 구성.

새 하네스는 모든 조합에서 예전 하네스를 능가했습니다. Fable 5 하이브리드는 첫 한 시간 안에 스위트의 약 3분의 2를 통과했습니다. 네 시간의 마감 시점에 새 실행들은 73%에서 85% 사이에 있었던 반면, 예전 실행들은 11%에서 77%까지 넓게 흩어져 있었습니다. 예전 Grok 4.5 실행은 두 시간을 채우기 전에 중단되었고(자세한 내용은 아래), 새 구성은 하나도 빠짐없이 결국 스위트의 100%를 통과했습니다.

Grok 4.5의 곡선은 예전 하네스와 새 하네스의 차이를 가장 극적으로 보여 줍니다. 새 실행은 꾸준히 상승해 80%에 도달하는 반면, 예전 실행은 낮은 점수에서 요동치다 중단됩니다.

Opus 4.8을 플래너로, Composer 2.5를 워커로 쓴 하이브리드 구성은 프런티어급 판단과 저렴한 실행을 결합한 대표 사례입니다.

Cursor는 앞으로 플래너와 워커의 조합을 N×N 행렬 전체로 돌려 보고 싶다고 밝혔습니다. 이번 주기에서 중요한 비교는 하네스 버전 사이의 비교 였고, 행동상의 차이는 점수 차이가 시사하는 것보다 훨씬 컸습니다.

한 가지 흥미로운 각주도 있습니다. Cursor는 원래 프런티어 구성으로 GPT-5.6 Sol 을 쓰고 싶었지만, 이 신형 모델은 문자 그대로의 표현이나 강조된 문구에 다른 모델들보다 더 민감했고 다른 모델에서는 볼 수 없던 통제 불능의 나선(runaway spiral)을 일으켰다고 합니다. 갓 출시된 모델에 맞춰 프롬프트를 조율할 시간이 없었고, 한 모델만 조율하고 나머지는 그대로 두면 비교가 부정확해지기에 GPT-5.5로 물러섰다는 것입니다. 모델과 하네스의 조합이 성능을 좌우한다는 점은 Artificial Analysis가 공개한 코딩 에이전트 벤치마크에서도 확인할 수 있는 흐름입니다.

실행 과정 심층 분석: 커밋, 충돌, 파일, 크레이트

가장 단순한 활동 지표인 커밋 수부터 보겠습니다. 예전 하네스의 Grok 4.5 실행은 첫 두 시간 동안 68,000개의 커밋을 만들어 냈는데, 이는 새 실행 속도의 약 70배입니다. 이것을 "더 생산적이었다" 고 읽을 수도 있지만, 다른 해석은 그 커밋 대부분이 헛일(스래싱, 경합, 잦은 뒤집기)이었다는 것입니다.

병합 충돌 데이터는 후자의 해석에 힘을 실어 줍니다. 예전 실행은 중단되기 전까지 70,000건이 넘는 충돌을 쌓았고, 안정되기는커녕 가속되고 있었습니다. 반면 새 실행은 네 시간 전체를 통틀어 1,000건에 못 미치는 충돌을 기록했습니다.

충돌은 파일이 가장 커진 곳에 집중되었습니다. 예전 실행에서 가장 큰 파일들은 실행 내내 계속 자랐고, 그중 가장 뜨거웠던 파일 하나는 1,173명의 서로 다른 에이전트가 건드리며 7,771건의 충돌을 모았습니다. 새 실행에서 코드베이스 전체를 통틀어 가장 경합이 심했던 파일조차 충돌은 47건에 그쳤습니다.

예전 스웜의 가장 큰 조율 실패인 스플릿 브레인, 즉 플래너들이 서로의 작업을 중복 구현하는 문제는 패키지 구조에서 드러났습니다. Rust 코드는 크레이트(crate) 라는 패키지로 조직되는데, 이런 프로젝트에서는 크레이트 하나가 대략 하나의 주요 구성 요소에 해당합니다. 예전 실행은 세 개의 별도 SQL 패키지를 포함해 무려 54개의 크레이트로 뻗어 나갔습니다. 반면 새 실행은 초반에 9개의 크레이트로 정착한 뒤 단 하나도 추가하지 않았습니다.

이 모든 것은 최종 코드베이스에 그대로 반영됩니다. Fable 5 조합에서는 예전 스웜과 새 스웜 모두 결국 전체 스위트를 통과했지만, 예전 스웜은 64,305줄의 엔진 코드가 필요했던 반면 새 스웜은 9,908줄로 해냈습니다. Opus 조합도 같은 모양을 보여, 예전 하네스에서는 19,013줄로 97%를 기록했고 새 하네스에서는 4,645줄로 100%를 달성했습니다. 같은 모델이라도 하네스가 바뀌면 훨씬 적은 코드로 더 나은 결과 를 낸다는 뜻입니다.

지금까지의 심층 지표를 Grok 4.5 실행 기준으로 한눈에 정리하면 다음과 같습니다. 예전 하네스가 활동량은 압도적으로 많았지만 그 대부분이 충돌과 중복으로 새어 나갔음을 알 수 있습니다.

지표	예전 하네스 (v1)	새 하네스 (v2)
첫 2시간 커밋 수	약 68,000건	예전의 약 1/70 수준
누적 병합 충돌	70,000건 이상 (가속)	1,000건 미만
가장 뜨거운 파일의 충돌	7,771건 (에이전트 1,173명)	47건
서로 다른 Rust 크레이트	54개 (SQL 패키지 3개 중복)	9개
엔진 코드 줄 수 (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%가 넘었습니다. 하지만 달러는 토큰과 다르게 갈렸습니다. 플래너 토큰이 더 비싸기 때문입니다. Opus 4.8과 Composer 2.5 조합에서 플래너 역할의 Opus는 전체 토큰의 작은 일부만 생산했지만 비용의 약 3분의 2를 차지했고, 워커 역할의 Composer는 압도적인 다수의 토큰을 처리하면서도 나머지 3분의 1의 비용만 썼습니다.

큰 작업에서 진정으로 프런티어급 지능을 요구하는 순간은 몇 되지 않습니다. 원래의 작업 분해, 설계 결정, 그리고 특정 트레이드오프 정도입니다. 프런티어 플래너가 일단 모호함을 상세하고 명시적인 지시로 정리해 두면, 더 저렴한 모델은 그저 그것을 따르기만 하면 됩니다. 이것이 비용 절감의 거대한 잠재적 원천입니다. GPT-5.5를 플래너와 워커 모두에 쓴 실행에서는 워커만으로 $9,373 이 들었습니다. 반면 Opus 4.8이 계획하고 Composer 2.5가 실행한 실행에서는 워커 함대 전체가 $411 이었습니다. 같은 실행 작업을 20배 넘게 저렴하게 처리한 것입니다.

두 하이브리드 실행을 비교하면 눈여겨볼 세부 사항이 하나 더 있습니다. Fable 5 플래너는 토큰당 단가가 Opus 4.8 플래너의 약 두 배였는데도, 계획 토큰을 훨씬 적게 써서 청구액은 오히려 조금 더 작았습니다. 하지만 Fable 실행의 워커는 몇 배나 많은 토큰을 소비했고, 그 결과 실행 전체로는 상당히 더 비쌌습니다. 플래너 단계의 청구액이 더 싸다고 해서 실행 전체가 더 싸지는 것은 아니며, 결국 전체 비용을 좌우하는 것은 플래너의 지시가 하류에서 유발하는 워커의 토큰 소비량이라는 점을 보여 주는 대목입니다.

이처럼 하네스와 모델 조합을 함께 설계하는 흐름은 Claude Code의 동적 워크플로우처럼 작업마다 오케스트레이션을 직접 짜는 접근이나, 병렬 AI 에이전트를 동시에 실행하는 프로그래밍 기법에 대한 최근 논의와도 맞닿아 있습니다.

명세가 곧 프롬프트다: 스웜은 의도를 번역하는 컴파일러

AI 능력이 도약할 때마다 엔지니어가 일하는 추상화의 층위(level of abstraction)가 한 단계씩 올라갔습니다. 자동완성은 엔지니어가 한 줄씩 작업하게 했고, 초기 모델은 그것을 코드 블록 단위로 끌어올렸으며, 에이전트는 파일이나 기능 단위로 올렸습니다. 그리고 스웜과 함께 이제 작업의 단위는 명세(spec) 가 됩니다.

이것이 성립하려면 스웜이 명세를 실제로 충실히 따라야 하는데, 이 글의 상당 부분이 바로 그 문제를 다룬 것입니다. Cursor는 스웜에게 835페이지의 산문을 주었고, 스웜은 데이터베이스를 들고 돌아왔습니다. 이 실험에서 희소했던 것, 그리고 앞으로 소프트웨어 엔지니어링에서 희소할 것이라 Cursor가 내다보는 것은 바로 의도에 대한 올바른 서술 입니다.

이런 관점에서 보면 스웜은 점점 컴파일러(compiler) 를 닮아 갑니다. 컴파일러는 소스 코드를 일련의 중간 단계를 거쳐 기계어로 낮춰 번역합니다. 스웜도 의도를 두고 비슷한 일을 합니다. 플래너가 목표를 작업 트리로 파싱하고, 그것을 한 단계씩 실행 가능한 작업으로 낮춰 갑니다. 차이가 있다면, 컴파일러는 모든 단계에서 의미를 보존하지만 스웜은 모든 단계에서 확률적(probabilistic)이라는 점입니다. 이 글에서 설명한 모든 장치는 결국 그 간극을 좁히기 위해 존재합니다.

Cursor는 스웜의 결과물을 직접 살펴보라고 초대합니다. Opus 4.8 단독 실행으로 만든 코드베이스는 github.com/cursor/minisqlite에 공개되어 있습니다. Cursor는 "처음 훑어본 인상으로는 훌륭해 보이지만 깊은 수동 분석은 아직 하지 않았다" 며, 직접 들여다보고 무엇을 찾았는지 알려 달라고 청합니다.

Agent swarms and the new model economics 소개 블로그

cursor/minisqlite GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다! 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~