기계를 만드는 기계, 그리고 스스로 작동하는 스튜디오: 에이전트 군집(Agent Swarm)을 조직하는 두 가지 방법

내가 이 글을 쓰는 이유

나는 사람들이 이 비교가 유용하다고 느낄 것이라 생각했습니다. 왜냐하면 서로 완전히 격리된 상태에서 설계되어 동일한 유형의 문제를 해결하면서도, 양쪽 모두 정직하게 비교할 수 있을 만큼 충분한 상세 기록이 남아 있는 두 개의 완성된 에이전트 오케스트레이션 (Agent-orchestration) 시스템을 접하는 것은 매우 드문 일이기 때문입니다. 또한 두 시스템이 모두 활발히 운영되고 있는 시점에 그 차이점을 포착하는 것은 더욱 드문 일입니다. 나의 DAG TOML 관련 기사를 게시한 직후, 나는 비슷한 사례를 찾아 나섰고 wpank의 글인 Building the Machine That Builds the Machine을 발견했습니다. 이 글은 Bardo를 설명하고 있습니다. Bardo는 343개 파일에 걸친 234,657줄의 명세(Specification)를 받아 조정된 에이전트 군집 (Agent swarms)을 통해 26개의 컴파일된 Rust 크레이트 (Crates)로 변환하는 메타 시스템 (Meta-system)입니다. 나 또한 이 경주에 참여하고 있는 당사자로서, atelier-studio라는 시스템(약 5개월에 걸쳐 구축된 약 80,000줄의 Rust 코드)을 가지고 있습니다. 그의 포스트를 읽는 것은 낯선 사람의 코드베이스에서 나의 결정을 발견하는 기묘한 경험이었으며, 더 유용하게는 그와 내가 서로 반대되는 결정을 내린 지점들을 확인하는 경험이었습니다.

나는 여기서 중립적인 리뷰어가 아닙니다. 비교 대상이 되는 두 시스템 중 하나를 직접 구축했기 때문입니다. 그러므로 이 글을 존중과 정직한 잣대를 가진 한 실무자가 다른 실무자의 작업을 읽는 것으로만 받아들여 주시기 바랍니다. Bardo를 설명할 때 나는 코드가 아닌 작성된 글만을 바탕으로 작업하고 있으며, 모든 오독은 나의 책임입니다.

공장: Bardo

Bardo는 프로젝트 중심적입니다. 이 시스템은 하나의 거대한 빌드(Build)를 완료하기 위해 존재합니다. 즉, 사멸성(Mortality), 꿈(Dreaming), 감정(Emotion), 그리고 경제적 인센티브(Economic incentives)를 가진 자율 에이전트 (Autonomous agents)를 구현하는 26개 크레이트의 Rust 워크스페이스 (Workspace)를 구축하는 것입니다. 이 명세는 학술적 인용(대사적 자유에 관한 Hans Jonas와 신체적 표식에 관한 Damasio를 포함하여 467개에 달함) 수준까지 상세하게 정의되어 있습니다. 오케스트레이터 (Orchestrator)인 bardo-ctl은 42,744줄의 Rust로 작성되었으며, 내가 가장 감탄하는 부분은 약 2,000줄의 bash 코드입니다.

이 bash 코드는 3단계 컨텍스트 엔지니어링 파이프라인 (context engineering pipeline)이며, 솔직히 말해 전체 설계의 핵심입니다. 1단계는 두 가지 소스 가중치 모델 (two-source weighted model)을 사용하여 명세 섹션 (specification sections)을 추출합니다 (인라인 명세 참조는 crate 매핑 디렉토리보다 두 배의 가중치를 가집니다). 2단계는 102.4KB의 컨텍스트 제한 (context cap) 하에서 계획을 순서가 있는 단계들로 분해하며, 이때 각 단계는 이전의 모든 단계와 결합되었을 때 반드시 컴파일되어야 한다는 규칙을 따릅니다. 3단계는 각 단계를 5~15KB의 컨텍스트 슬라이스 (context slice)로 정제하며, 이전 단계들이 무엇을 완수했는지에 대한 한 줄 요약을 전달합니다. 덕분에 7단계를 구현하는 에이전트 (agent)는 1단계의 스캐폴딩 (scaffolding)을 결코 보지 않게 됩니다. 이 설계는 그의 표현을 빌리자면, 약 12KB만이 유효한 상황에서 80KB의 페이로드 (payload)에 빠져 허우적거리는 에이전트들을 지켜보는 과정에서 탄생했습니다.

그 위에는 진정으로 완전한 오케스트레이션 레이어 (orchestration layer)가 자리 잡고 있습니다. 파일, 수락 기준 (acceptance criteria), 계획 간 의존성 (cross-plan dependencies; 예를 들어 작업은 계획 17의 작업 T1인 "17:T1"에 의존할 수 있으며, 이를 통해 스케줄러는 계획 경계를 가로질러 병렬성을 추출할 수 있음), 그리고 독점적 파일 점유 (exclusive file claims)를 선언하는 약 100개의 작업 TOML 파일들이 있습니다. Kahn 알고리즘을 통한 웨이브 스케줄링 (wave scheduling)이 적용된 이중 레이어 DAG (Directed Acyclic Graph), 실행 중인 작업과 파일이 겹치는 작업의 시작을 거부하는 next_runnable() 체크, 역량에 따라 세 가지 백엔드로 라우팅되는 25개의 에이전트 역할 (리팩토링 및 진단에는 Codex, 리뷰 판정에는 Cursor, 오케스트레이션 및 구현에는 Claude), 3회 실패 시 중단되는 게이트 건틀릿 (gate gauntlet; 컴파일, 의존성 거부, 테스트, 명세 준수), Critic에 의해 합성되는 병렬 3인 리뷰어 패널, 병렬 빌드가 서로의 캐시 히트 (cache-hit)를 유도할 수 있도록 공유 sccache를 사용하는 계획별 git worktree, 그리고 300초가 지나면 침묵하는 에이전트를 독려하고 600초가 지나면 멈춘 에이전트를 재시작하며, 구현자 (Implementer)의 생성 슬롯 (spawn slot)을 결코 굶기지 않는 컨덕터 (Conductor)가 포함되어 있습니다.

두 가지 작은 메커니즘은 실제적인 고통의 흔적을 담고 있기에 주목할 가치가 있습니다. 반복 메모리 (Iteration memory)는 컴파일러 오류와 리뷰 차단 요소들로부터 누적된 '재시도 금지 (DO NOT RETRY)' 목록을 구축합니다. 이는 에이전트가 네 번의 반복 동안 동일한 타입 불일치 (type mismatch) 오류에 부딪히면서, 매번 다르게 그리고 틀리게

메모리 시스템 또한 동일한 방식으로 차이가 납니다. Bardo의 학습은 텍스트 기반이며 에이전트가 반드시 읽어야 하는 'DO NOT RETRY' 목록과 같은 규칙 형태를 띱니다. 반면 Atelier의 학습은 통계적입니다. 다음 시도가 실패할 확률을 예측하는 실패 오라클 (failure oracle)에 데이터를 제공하는 시도 추적기 (Dirichlet modelling 사용), 그리고 시스템의 신뢰도가 실제 적중률에 부합하도록 유지하는 보정 추적기 (isotonic regression 및 Platt scaling 사용)로 구성됩니다. 하나는 무엇이 실패했는지를 기억하고, 다른 하나는 실패가 발생할 가능성이 얼마나 높은지를 모델링합니다. 또한 Atelier는 Bardo가 시도조차 하지 않은 경계를 넘습니다. 바로 Atelier 자신의 코드에 변경을 제안하는 자기 개선 서브시스템 (self-improvement subsystem)입니다. 바로 이 점 때문에 Atelier에는 인간의 승인을 거치는 안전 게이트 (safety gate)와 적대적 검토 (adversarial review)가 포함되어 있습니다. 스스로를 재작성하는 시스템은 빌드 공장 (build factory)과는 다른 방식의 거버넌스 (governance)가 필요하기 때문입니다.

두 낯선 이가 동일한 부품을 만들어낸 곳

수렴 목록이 충분히 길어지면서, 저는 이를 더 이상 기괴하게 느끼지 않고 오히려 교훈적으로 받아들이기 시작했습니다. 두 시스템은 모두 독립적으로 다음과 같은 요소들에 도달했습니다: 자체적인 수락 기준 (acceptance criteria)과 파일 세트를 포함하는 원자적 작업 단위 (atomic work units); 해당 단위들에 대한 명시적인 의존성 DAG (Directed Acyclic Graph); 안전한 병렬 에이전트 운용을 위한 전제 조건으로서의 파일 수준 충돌 탐지 (Bardo의 exclusive-files 체크는 제 DAG TOML 런타임의 충돌 그룹과 기능적으로 동일합니다); 종합적인 판결을 내리는 검토자 패널; 세 번의 실패 시 종료되는 실패 예산 (failure budget); 다음 시도로 전달되는 실패 메모리; 작업 예시 (worked examples)로서 다음 시도로 전달되는 성공 사례 (그의 골든 패스 (golden paths)는 제가 리뷰 아카이브를 마이닝할 때 부정 클래스 (negative class)로 사용했던 깔끔한 단판 승인 사례들과 거의 토씨 하나 틀리지 않고 일치합니다); 그리고 별도의 작업 복사본을 통한 병렬 작성자들의 격리입니다.

이 중 어느 것도 복제된 것이 아닙니다. 저는 제 시스템을 구축한 후에 그의 글을 발견했습니다. 그의 포스트는 제 작업물을 전혀 언급하지 않았음에도 불구하고, 핵심적인 안전 메커니즘(load-bearing safety mechanisms)이 거의 일대일로 일치합니다. 한 번도 만난 적 없는 두 설계자가 파일 수준의 충돌 감지(file-level conflict detection)와 누적된 재시도 금지 메모리(cumulative do-not-retry memory)라는 지점에서 수렴한다면, 그것은 유행이 아니라 문제 자체가 해결책의 형태를 결정하고 있는 것입니다. 이는 다리를 건설하는 모든 문화권이 아치(arch) 구조를 발견해내는 방식과 같습니다.

철학이 갈라지는 지점

세 가지 진정한 차이점이 존재하며, 각각은 취향이 아닌 작업의 형태에서 기인합니다.

첫째, 정적 증류(static distillation) 대 동적 검색(living retrieval)입니다. Bardo는 사양(specification)이 고정되어 있기 때문에 컨텍스트 슬라이스(context slices)를 미리 계산할 수 있습니다. 즉, 사양이 곧 영역(territory)이며 파이프라인은 단 한 번 수행되는 지도 제작 과정입니다. 반면 Atelier는 그 무엇도 고정할 수 없습니다. 지식 그래프(knowledge graph)는 계속 성장하며, 의회(councils)는 각 의회별 토큰 예산(token budgets)이 할당된 사서 계층(librarian layer)을 통해 런타임(run time)에 이를 쿼리합니다. Bardo는 컨텍스트를 컴파일(compiles)하고, Atelier는 이를 검색(retrieves)합니다. 컨텍스트 엔지니어링(context engineering)이 게임의 전부이며, 적절한 시점에 적절한 12KB를 전달하는 것이 핵심이라는 그의 마지막 문장은, 고정된 세계를 위한 선언이자 제가 고정되지 않은 세계를 위해 지식 그래프를 구축하게 만든 것과 동일한 신념의 표현입니다.

둘째, 기술적 다양성(skill diversity) 대 관점의 다양성(perspective diversity)입니다. 이는 위에서 설명했으므로 반복하지 않겠으나, 그 결과만을 언급하겠습니다. Bardo의 검토 패널(review panel)은 결함을 잡아내기 위해 존재하며, Atelier의 풍미 합의(flavour consensus)는 사각지대(blind spots)를 찾아내기 위해 존재합니다. 그리고 성숙한 군집(swarm)은 아마도 이 두 가지가 모두 필요할 것입니다.

셋째, 콕핏(cockpit) 대 제어 평면(control plane)의 차이입니다. 그의 헤드리스 운영(headless operation) 시도는 본인의 표현을 빌리자면 눈을 가리고 운전하는 것과 같았습니다. 관찰되지 않은 20분 중 15분 동안 에이전트가 컴파일-수정 루프(compile-fix loop)에 갇혀 있는 상황이었죠. 이에 대한 그의 해답은 26개의 위젯, 일시 정지 및 강제 진행 제어 기능, 그리고 역할별 색상 코딩이 적용된 터미널 대시보드였습니다. 동일한 고통에 대한 저의 해답은 구조화된 이벤트 스트리밍(structured event streaming)이었으며, 결과적으로 데이터를 직접 관찰하는 대신 데이터로부터 플릿 상태(fleet state)를 평가하는 외부 제어 평면(external control plane)을 구축하는 것이었습니다. 상호작용형 콕핏(cockpit) 대 쿼리 가능한 계기판(instrument panel)의 대결이며, 제 생각에 그의 방식은 전환(converts)된 에이전트를 더 빠르게 개입(intervention)하게 만들지만, 저의 방식은 한 사람이 볼 수 있는 화면의 수를 넘어 확장(scale)할 수 있게 합니다.

내가 얻은 교훈

1. 안전 메커니즘은 수렴하지만, 전략 계층은 그렇지 않습니다. 충돌 탐지(conflict detection), 수락 기준(acceptance criteria), 실패 예산(failure budgets), 반복 메모리(iteration memory)는 두 시스템 모두에서 요청하지 않아도 나타났지만, 컨텍스트 전략(context strategy), 다양성 전략(diversity strategy), 관찰 가능성 전략(observability strategy)은 각 시스템의 목적에 따라 명확하게 갈렸습니다. 만약 오케스트레이터(orchestrator)를 구축하고 있다면, 첫 번째 목록은 확신을 가지고 복사하되, 두 번째 목록은 의도적으로 선택하십시오.
2. 프로젝트 형태의 시스템과 기관 형태의 시스템은 서로 다른 메모리를 필요로 합니다. 공장은 교훈을 텍스트로 보유할 수 있지만, 기관은 보정(calibration)이 필요합니다. 왜냐하면 기관은 개별적인 교훈이 유효하지 않게 된 이후에도 오랫동안 예측을 수행할 것이기 때문입니다.
3. 컨텍스트 엔지니어링(Context engineering)이 계속 승리하고 있습니다. 서로 반대되는 아키텍처를 가진 두 시스템이 동일한 결론에 도달했습니다. 더 나은 모델도, 더 긴 컨텍스트 윈도우(context window)도 아닌, 적절한 순간에 제공되는 적절하고 작은 컨텍스트가 핵심입니다.
4. 동시성(Synchronicity)은 증거입니다. 고립된 빌더들이 계속해서 동일한 메커니즘에서 만난다면, 그 메커니즘은 아마도 분야 전체를 지탱하는 핵심 요소일 것입니다. 그리고 그것들은 제가 이제 가장 없어서는 안 될 부분들입니다.

내부 구조를 충분히 상세하게 기술하여 실제적인 비교를 가능하게 해준 wpank의 글에 감사를 표합니다. 이러한 관대함은 엔지니어링 기술보다도 더 희귀한 것입니다. 여기까지 읽어주셔서 감사하며, 두 기계에 대한 저의 분석이 여러분께 유익한 가치를 제공하기를 바랍니다. 만약 여러분만의 오케스트레이터 (Orchestrator)를 직접 구축해 보았고 이러한 메커니즘들을 인지하고 있다면 (혹은 더 좋게는, 완전히 제3의 선택을 내렸다면), 그 과정에서 어떤 한계에 부딪혔는지 진심으로 듣고 싶습니다.