에이전트를 병렬로 실행했을 때, 청구서 내역이 어떻게 되는지를 진지하게 공개한 사례를 본 적이 별로 없다. Cursor가 7월 20일에 발표한 실험 리포트는 그 부분에 숫자를 집어넣었다. 토큰의 90% 이상을 저렴한 모델이 뱉어내고 있음에도 불구하고, 금액의 3분의 2는 소수의 비싼 모델이 차지한다. 이러한 비대칭성이 멀티 에이전트 (Multi-agent) 구성의 설계 그 자체를 규정하고 있다는 이야기다.

실험의 과제 설정부터가 매우 날카롭다. SQLite의 공식 매뉴얼(835페이지)만을 에이전트 군에게 주고, Rust로 동등한 데이터베이스 엔진을 구현하게 한다. SQLite의 소스 코드도, 테스트 스위트(Test suite)도, 바이너리도, 인터넷도 주지 않는다. 채점은 sqllogictest라는, SQLite가 실제로 사용하고 있는 수백만 쿼리 규모의 적합성 테스트로 수행한다.

결과적으로, held-out SQL 테스트 스위트를 100% 통과하는 엔진이 완성되었다. 게다가 지난번의 유사한 실험(Cursor는 올해 1월에 에이전트 군만으로 Web 브라우저를 만들게 했다)과 비교했을 때, 코드량이 64,305행에서 9,908행으로 줄어들었다. "같은 성과를 더 적은 코드로"라는 방향으로 개선한 것은, 솔직히 이런 종류의 데모로서는 드문 일이다. 에이전트를 늘리면 보통은 코드가 방대해지기 때문이다.

새로운 구성의 골격은 단순하며, planner(계획 담당)와 worker(구현 담당)의 2층 트리 구조로 되어 있다. planner는 프론티어 모델 (Frontier model), worker는 저렴하고 빠른 모델이다. 중요한 것은 역할의 금지 사항인데, planner는 구현하지 않고, worker는 계획하지 않는다. planner의 컨텍스트 (Context)가 저수준의 구현 상세 내용으로 채워지지 않도록 하고, worker는 자신이 담당하는 좁은 영역에 컨텍스트를 전부 사용할 수 있게 한다.

Cursor는 이 설계 이유를, 기업이 왜 계층 구조가 되는지를 논한 로널드 코스(Ronald Coase)의 논의에 끌어들여 설명하고 있다. 모든 구성원이 모든 구성원과 대화하는 조직은 조정 비용이 업무량보다 빠르게 증가하기 때문에 파괴된다. 에이전트에서도 똑같은 일이 일어난다는 논리다. 비유로서 매우 솔직하며, 실제로 구(舊) 구성이 무너진 이유와도 일치한다.

구 구성의 실패는 지난 블로그에 적혀 있는데, 이것이 읽을거리로서 매우 흥미롭다. 처음에는 공유 파일을 통한 락(Lock)으로 중복 작업을 방지하려 했으나, 에이전트가 락을 잡은 채 놓지 않거나 해제를 잊어버린다. 20개를 돌려도 실효 스루풋 (Throughput)은 2~3개 분량으로 떨어졌다. 다음으로 낙관적 병행 제어 (Optimistic concurrency control, 읽기는 자유롭지만 쓰기 시점에 상태가 변해있으면 실패하는 방식)로 전환했을 때는 덜 망가지게 되었지만, 계층이 없는 탓에 에이전트 전체가 "리스크 회피적"이 되어 어려운 태스크를 피하며 끊임없이 헛바퀴만 돌게 되었다. 아무도 결정하지 않는 조직 그 자체였다.

신 구성에서는 결정은 반드시 planner가 내린다. 여기에 더해 4가지 조정 장치가 들어있다. 합의 사항을 기록해 두는 설계 문서 (의존하는 코드 측에서 참조되며, 컴파일 시 검증됨), 충돌을 제3자로서 판결하는 머지 충돌 중재자 (Merge conflict arbiter), 비대해진 파일을 외부에서 분할하는 megafile decomposer, 그리고 field guide라고 불리는, 에이전트 스스로가 작성하며 행수 예산(Line budget)을 가지고 관리하는 공유 컨텍스트 (기동 시 자동 주입됨)이다. 리뷰 또한 "전체 트랜스크립트를 본다", "출력만 본다", "코드베이스만 본다"와 같이 관점을 바꾼 여러 개의 렌즈를 서로 다른 모델로 실행하여 상관관계를 낮추고 있다.

본론인 비용 구조다. 동일한 과제를 여러 모델 구성으로 풀게 한 결과, 총액은 구성에 따라 수십 배 차이가 났다.

Opus/Composer 하이브리드 구성에서는 worker인 Composer가 전체 토큰의 90% 이상을 생성하고 있음에도 불구하고, 금액 점유율은 약 3분의 1이다. 나머지 3분의 2는 토큰량으로는 아주 일부만을 차지하는 Opus의 planner가 가져간다. 단가 차이가 그대로 나타나고 있다.

Once a frontier planner has collapsed the ambiguity into a detailed, explicit instruction, less expensive models simply have to follow it.

(프론티어 planner가 모호함을 제거하여 상세하고 명시적인 지시로 떨어뜨려 놓으면, 저렴한 모델은 그저 그것을 따르면 된다.)

이 문장이 실험 주장의 핵심이라고 생각한다. 뒤집어 말하면, 모델 선택은 '태스크(Task)별'이 아니라 '역할(Role)별'로 결정해야 한다는 설계 지침이 된다. 모호함을 제거하는 공정에만 높은 성능의 모델을 배치하고, 그 이후 단계는 저렴한 모델로 밀어붙이는 것이다. 이는 나의 실무적 감각과도 일치한다. 요구사항이 확정되지 않은 단계에서 저렴한 모델에 대량으로 요청을 던지면, '그럴싸해 보이지만 방향이 틀린 코드'가 대량으로 생성되어 리뷰 비용이 치솟게 된다. 반대로 지시가 충분히 구체적이라면, 모델의 지능 차이는 상당히 좁혀진다.

참고로, 이 기사를 소개한 AlphaSignal의 헤드라인에는 '15배 저렴하다'라고 적혀 있지만, 공개된 $1,339와 $10,565를 기준으로 계산하면 약 7.9배이며, 15배가 어떤 비교를 의미하는지는 원문에서 찾아볼 수 없었다. 2차 정보의 배율은 그대로 믿지 않는 것이 좋다.

수수하지만 구현 측면에서 가장 눈에 띄었던 부분은 바로 여기로, Cursor는 버전 관리 시스템(VCS)을 자체적으로 다시 작성했다. 에이전트 군단의 커밋(Commit) 빈도가 피크 시점에 초당 약 1,000회에 달하여 Git으로는 감당할 수 없기 때문이다. 기존 구성의 처리량(Throughput)은 시간당 약 1,000커밋 규모였으므로, 세 자릿수 차이가 난다.

효과는 충돌(Conflict) 수에서 나타난다. 기존 구성은 Grok 4.5를 사용하여 2시간 동안 68,000커밋을 쌓으며 70,000건 이상의 머지 충돌(Merge Conflict)을 일으켰으나, 신규 구성은 4시간 동안 충돌이 1,000건 미만이었다. 가장 경합이 심했던 파일 하나만 보더라도 7,771건에서 47건으로 떨어졌다. 생성된 crate 수도 54개에서 9개로 줄었다. 테스트 통과율 측면에서도 신규 구성은 Grok 4.5를 통해 4시간 만에 80%에 도달한 반면, 기존 구성은 2시간을 채우지 못하고 발산하여 중단시켜야만 했다.

VCS를 다시 작성하는 것이 과해 보일 수도 있지만, "모든 변경 사항이 VCS를 통과하므로 충돌이 그곳에서 가시화되고, 조정 메커니즘을 삽입할 위치가 한 곳으로 결정된다"라는 설계는 합리적이다. 멀티 에이전트(Multi-agent)의 조정 문제를 에이전트 간의 프로토콜이 아닌 공유 스토리지 계층의 문제로 해결했다고 읽을 수도 있다.

Hacker News(HN) 스레드에서는 당연하게도 'from scratch(처음부터)'에 대한 비판이 나오고 있다. SQLite의 소스 코드는 학습 데이터에 분명히 포함되어 있을 것이므로, 이것은 새로 만들게 한 것이 아니라 모델이 압축해서 가지고 있는 지식을 전개시킨 것뿐이 아니냐는 지적이다. 이는 타당한 유보 의견이라고 생각한다. 동일한 수법을 학습 데이터에 존재하지 않는 사내 사양(Specification)에 적용했을 때도 같은 수치가 나올 보장은 없다.

또 하나, 댓글창에서 날카롭게 지적된 부분은 사양서(Specification) 이야기로, 835페이지에 달하는 엄격한 사양이 이미 존재했다는 사실 자체가 이 실험의 전제가 되어 있다. 실무에서 어려운 것은 구현보다 그 사양을 작성하는 것이며, 게다가 사양은 실행하여 검증할 수도 없다. Cursor 스스로도 리포트 마지막에 taste(취향), judgement(판단), direction(방향)은 인간으로부터 왔다고 적고 있다.

그럼에도 불구하고, 비용 구조의 비대칭성은 실험의 시비와는 별개로 성립하는 이야기다. planner 역할에는 높은 모델을, worker 역할에는 저렴한 모델을 사용하는 구분은, swarm을 구성하지 않는 일반적인 에이전트 운용에서도 그대로 유효하다. 당장 시도해 본다면, 우선 '모호함을 제거하는 1회'와 '그 이후의 구현 N회'를 명시적으로 별도의 모델 호출로 나누는 것부터 시작하면 된다. VCS를 다시 작성하는 것은 그 이후에 해도 늦지 않다.