에이전트 2천 개가 2주 만에 스스로를 다시 쓴 방법: Prime Agent가 TypeScript를 Rust로 옮긴 과정

2천 명의 팀, 그중 진짜 사람은 없다

2026년 8월에야 정식 출시된 코딩 에이전트 Prime Agent는 두 달 만에 30만 회가 넘는 다운로드를 쌓고 8조 개 이상의 토큰을 처리했다. 10월 9일, 개발사 Prime Intellect는 더 눈길을 끄는 소식을 발표했다. 이 도구가 스스로를 다시 작성했다는 것이다. TypeScript에서 Rust로, 2주 만에. 작업을 수행한 것은 2천 개가 넘는 자율 에이전트였다.

이것은 홍보 문구에 나오는 "AI가 코드를 대신 써 준다"는 이야기가 아니다. 이식 전 과정에서 인간 팀이 주로 한 일은 하나였다. 수용 기준을 세워 에이전트가 스스로 제대로 했는지 측정할 수 있게 만드는 것이다. 나머지 오케스트레이션, 코딩, 리뷰, 검증은 모두 기계에 맡겼다.

비용과 규모: 2천억 토큰의 이사

공식 블로그에 따르면 이번 재작성은 2,000개가 넘는 에이전트를 동원해 10,000개가 넘는 Prime 샌드박스에 걸쳐 병렬로 작업했고, Prime Inference의 GLM-5.3 엔드포인트에서 2,000억 개가 넘는 토큰을 소비했다. 실제로 Rust를 작성한 단계는 1,981개의 에이전트가 맡아 약 1,929.9억 토큰을 썼다. 이어진 3일간의 성능 끌어올리기 단계에는 228개의 에이전트가 추가로 투입되어 약 357억 토큰을 소비했다.

이 숫자들 자체가 하나의 신호다. 오픈 모델인 GLM-5.3이 프로덕션급 에이전트 군집의 주력 추론 엔진이 되었다는 것은 "어떤 모델의 점수가 또 1점 올랐다"는 이야기와는 다르다. 장시간, 대량으로, 안정적인 도구 호출이 필요한 엔지니어링 상황에서 오픈 웨이트 모델의 비용 효율이 실제 프로젝트에 받아들여질 수준에 이르렀다는 뜻이다.

오케스트레이션: 루트 에이전트는 제품 코드를 쓰지 않는다

가장 따라 할 만한 것은 "에이전트 2천 개를 썼다"는 점이 아니라 그 분업 방식이다. 전체 재작성은 하나의 루트 에이전트가 지휘했지만, 그것은 제품 코드를 한 줄도 쓰지 않는다. 하는 일은 세 가지뿐이다. 작업을 위상 순서가 있는 그래프로 쪼개고, 각 작업의 진행 상황을 추적하고, 완료된 작업을 병합한다.

각 작업은 네 가지 역할을 차례로 통과한다.

• 플래너: 명세, 기능 설계, "모범 답안"을 작성한다. 모범 답안은 TypeScript 버전의 기존 동작에서 그대로 가져온다.
• 구현자: 독립된 worktree에서 Rust 코드를 작성해 서로 다른 기능을 병렬로 진행할 수 있게 한다.
• 리뷰어: 다른 모델, 다른 컨텍스트로 바꿔 이 변경의 결함을 적대적으로 찾는다.
• 검증자: 완전히 새로운 샌드박스에서 코드를 컴파일하고 일관성 테스트를 돌린다.

리뷰나 검증 중 하나라도 통과하지 못하면 작업은 결론을 달고 구현자에게 되돌아간다. 두 단계를 모두 통과해야 변경이 병합될 수 있다. Prime Intellect는 "생성"과 "평가"를 일부러 분리했다. 이유는 솔직하다. 코드를 쓴 그 에이전트에게 자기 결과물을 평가하게 하면 본질적으로 자기 편을 들기 때문이다.

진짜 가드레일: 네 가지 일관성 검증

프로세스만으로는 부족하다. 객관적인 정오 기준도 필요하다. 팀은 같은 기능의 서로 다른 측면을 덮는 네 가지 패리티 검사를 만들었다.

• TUI 차분 테스트: TypeScript와 Rust 두 바이너리를 같은 스크립트 모델 아래에서 돌리고 터미널 화면을 프레임 단위로 비교한다. 시작, 메뉴, 도구 호출, 세션 복원, 서브에이전트, 크래시 복구를 포괄한다.
• 하네스 일관성: 양쪽이 생성한 세션 기록과 각자가 모델 제공자에게 보내는 요청을 비교한다.
• 프로토콜 일관성: 데몬 프로토콜의 모든 메시지 유형을 TypeScript 구현과 하나하나 대조해 검증한다.
• 기능 감사: 스크립트가 닿지 못하는 곳은 에이전트가 컴포넌트별로 대조해 "일치", "부분 일치", "누락"으로 표시한다.

이런 객관적인 잣대가 있으면 에이전트는 스스로 진행 상황을 판단하고 병합 전에 회귀를 막을 수 있어, 인간 리뷰의 필요성이 그만큼 줄어든다. 팀도 솔직하다. 실제로 빠져나간 버그는 어떤 테스트도 덮지 못한 것들이었고, 결국 내부에서 매일 쓰면서 드러났다.

결과: 콜드 스타트 14배, 메모리 8할 절감

공식 비교 데이터에서 콜드 스타트에서 입력 가능까지의 지연은 TypeScript 버전의 737.8밀리초에서 55.8밀리초로 줄어 14.18배 빨라졌다. 웜 스타트는 13.34배 향상됐다. 전체 프로세스 트리의 메모리 사용량은 607.4MB에서 106MB로 줄어 약 8할을 절약했다. 설치 용량도 172.1MB에서 59.6MB로 줄었다. 첫 가시 출력은 23.6밀리초에 도달했다. 끌어올리기 단계에서는 총 144건의 실험을 기록하고 69건의 유효한 변경을 병합했다. 다만 주의할 점은, 이 수평 비교가 공식 자체의 런타임 스위트를 사용한 것이고 공식도 통일된 벤치마크가 없다고 밝혔다는 것이다. 숫자는 조심해서 읽어야 한다.

구조적 변화는 속도보다 오래 남을지 모른다. 코드는 9개의 crate로 나뉘었고 의존 관계는 단방향이며 Cargo가 강제한다. 가장 큰 소스 파일은 약 15,000줄에서 약 2,500줄로 줄었고 5,000줄을 넘는 파일은 더 이상 없다. 각 세션은 자신의 워커 프로세스에서 실행되어 하나가 죽어도 나머지에 영향을 주지 않는다. Windows 지원은 플랫폼 추상화가 깔끔해진 덕에 덤으로 실현됐고, 모델 카탈로그는 런타임에 가져오는 방식으로 바뀌어 새 모델 출시가 릴리스에 의존하지 않게 됐다.

왜 Rust인가

팀이 꼽은 TypeScript의 문제점은 구체적이다. 타입은 선택 사항이고 런타임에는 사라진다. 오류는 검사되지 않은 예외로 전파된다. 렌더링과 대형 세션 파싱처럼 CPU를 많이 쓰는 일이 키보드 입력과 같은 이벤트 루프를 두고 다툰다. 모든 프로세스가 JavaScript 런타임과 가비지 컬렉션을 하나씩 부양해야 한다. 오래 상주하고 세션마다 워커 프로세스를 두는 데몬에게 GC 없는 네이티브 코드는 메모리와 시작 시간을 개선하는 주된 원천이다.

그리고 코드를 주로 에이전트가 작성하게 되면 "컴파일 타임 보장"의 가치가 커진다. 망라적인 열거형, 소유권과 수명, 여기에 Clippy의 엄격한 lint까지 더하면 코드가 돌아가기 전에 통째로 한 부류의 버그를 걸러낼 수 있다. 다시 말해 컴파일러가 인간 리뷰어의 판단 일부를 대신 지고 있는 셈이다.

이것이 사람마다 무엇을 의미하는가

엔지니어링 팀을 이끌고 있다면 재사용할 수 있는 것은 "에이전트 2천 개"라는 숫자가 아니라 그 방법이다. 먼저 수용 기준을 객관적이고 자동 실행 가능한 검사로 만들고, 다음으로 생성과 평가를 서로 다른 모델과 컨텍스트에 나눠 맡기고, 마지막으로 에이전트를 가드레일 안에서 스스로 나아가게 한다. Primer Intellect는 이미 이 네 역할 패턴을 재사용 가능한 워크플로로 제품화하고 있다. "잘 정의된 군집 공장"이 프로젝트마다 즉석에서 짜 맞추는 것보다 믿을 만하다는 이유에서다.

그냥 일반 사용자라면 이것은 한 가지를 설명해 준다. Prime Agent 같은 도구의 업데이트 속도는 앞으로 점점 전통적인 소프트웨어와 달라질 것이다. 제품이 스스로를 다시 쓸 수 있으면 버전 번호의 의미도 달라진다. 이는 또한 "리팩터링으로 14배 빨라졌다" 같은 결론을 보면 먼저 각주로 가서 누가 측정했고 무엇과 비교했는지 확인하라는 경고이기도 하다. 에이전트는 쓸 만한 코드를 쓰지만, 자신감 넘치는 자기 칭찬도 똑같이 써낼 수 있다.