책임자가 없는 상태에서 큰 프로젝트를 계획하면 어떻게 될까요? 대부분의 소프트웨어 스택은 단일 오케스트레이터(orchestrator)가 있다고 가정합니다. 하나의 프로세스가 상태를 유지하고, 작업을 큐에 쌓으며, 태스크를 할당합니다. 만약 그 코디네이터가 재시작되면 전체 워크플로우가 흔들립니다. 새로운 프로젝트는 이러한 가정을 완전히 뒤집습니다. 이 프로젝트는 AI 에이전트 군단(swarm)이 "2주간의 일본 여행 계획하기"와 같은 목표를, 어느 한 노드도 전체 계획을 온전히 보유하지 않은 상태에서 어떻게 완전한 태스크 트리(task tree)로 분해할 수 있는지 보여줍니다.
왜 리더 없는 시스템을 구축하는가?
중앙 집중식 플래너는 추론하기 쉽습니다. 서버에 요청을 보내면 서버가 작업을 분할하고, 작업자들이 결과를 보고합니다. 문제는 서버가 인지적, 물리적 병목 현상이 된다는 점입니다. 서버가 '진실(truth)'을 독점하게 됩니다.
분산 환경에서 진실은 네트워크가 가십(gossip)을 통해 수렴해 나가는 공유된 그림이 됩니다. 이 특정 Python 구현체는 두 가지 뚜렷한 개념을 결합합니다. 첫 번째는 반복적인 정제 루프(iterative refinement loop)입니다. 한 에이전트가 제안서를 작성하면, 다른 에이전트가 점수를 매기고, 세 번째 에이전트가 이를 다듬습니다. 두 번째는 libp2p를 기반으로 구축된 P2P(peer-to-peer) 네트워킹 레이어입니다. 이를 통해 에이전트들은 레지스트리나 로드 밸런서 없이도 서로를 자동으로 발견할 수 있습니다. 그 결과, 지휘자 없이도 피어(peer)들이 나타나고, 제안하고, 투표하고, 실행하는 클러스터가 만들어집니다.
네 가지 역할
시스템은 모든 참여자에게 네 가지 성격 중 하나를 부여합니다. 물리적인 기계 네 대가 필요한 것은 아닙니다. 노트북 한 대에서 공존할 수도 있고, 홈 네트워크 전체에 퍼져 있을 수도 있습니다. 역할은 다음과 같습니다:
Decomposer (분해자). 이 에이전트는 최상위 목표를 받아 하위 목표로 분할할 것을 제안합니다. 시스템이 여러 분해자를 병렬로 실행하기 때문에, 동일한 일본 여행에 대해 세 가지 서로 다른 레시피를 얻을 수도 있습니다. 하나는 지리적(도쿄, 교토, 오사카)으로 여정을 나눌 수 있고, 다른 하나는 활동(이동, 숙박, 식사, 관광)별로 나눌 수 있으며, 세 번째는 날짜별로 순서를 정할 수 있습니다. 네트워크는 이 모든 것을 고려합니다.
Scorer (평가자). 이 에이전트들은 편집 위원회 역할을 합니다. 제안된 분할 방식을 검토하고 점수를 매깁니다. 점수는 하위 목표가 충분히 구체적인지, 중복되지 않는지, 그리고 전체를 포괄하는지를 반영합니다. 더 중요한 것은, 평가자가 제안을 수락할 만큼 충분히 좋은지 결정한다는 점입니다. 평가자의 승인이 없으면 분할된 계획은 미결 상태로 남습니다.
Executor (실행자). 트리가 실행 가능한 수준의 작은 리프 노드(leaf nodes)에 도달하면, 실행자들이 이를 차지하기 위해 경쟁합니다. 이들은 중앙 큐의 허가를 기다리지 않습니다. 대신, 타임스탬프 프로토콜을 사용하여 누가 태스크를 선점할지 결정합니다. 승자는 로컬 LLM 호출을 통해 작업을 수행하고 결과를 브로드캐스트합니다.
Observer (관찰자). 이는 모든 네트워크에 필요한 '구석의 관찰자(wallflower)'입니다. 가십을 조용히 경청하며, 대화 내용으로부터 계획 트리를 재구성하고, 읽기 쉬운 스냅샷을 출력합니다. 이 에이전트는 결코 말을 하지 않으므로 중요한 점을 증명합니다. 즉, 나중에 합류한 사람이라도 엿듣는 것만으로 전체 계획을 파악할 수 있다는 것입니다.
진실의 원천으로서의 가십(Gossip)
libp2p 레이어는 발견과 메시징을 처리합니다. 에이전트들은 프로토콜의 내장된 피어 발견(peer discovery) 기능을 통해 서로를 찾고, 공유된 토픽에 메시지를 브로드캐스트합니다. 기록을 위한 데이터베이스도, 정식 계획을 보유한 Redis 캐시도 없습니다.
각 피어는 계획 트리의 복사본을 자체적으로 유지하며, 들리는 가십을 바탕으로 이를 업데이트합니다. 분해자가 제안을 브로드캐스트하면, 다른 모든 노드가 이를 수신하고 형식을 검증한 뒤 자신의 로컬 트리에 해당 브랜치를 추가합니다. 평가자들이 투표를 하면, 집계 결과도 동일한 방식으로 전파됩니다. 만약 두 실행자가 동일한 태스크에 대해 충돌하는 주장을 발표하면, 타임스탬프 프로토콜이 충돌을 해결합니다. 네트워크는 더 이른 주장을 채택하고 늦은 주장은 폐기합니다.
시간이 흐름에 따라 트리는 원래의 목표로부터 수락된 하위 목표의 계층을 거쳐 한입 크기의 태스크에 도달할 때까지 아래로 성장합니다. 이 과정은 블록체인이 합의에 도달하는 것과 유사하지만, 페이로드가 코인 장부가 아닌 여행 일정이나 소프트웨어 사양이라는 점이 다릅니다.
투표와 실행 경쟁
민주주의는 비용이 많이 들며, 이 시스템은 그 대가를 지연 시간(latency)으로 치릅니다. 분할 방식은 충분한 평가자가 동의해야만 승인됩니다. 그 임계값은 클러스터 구성 방식에 따라 단순 과반수일 수도 있고, 더 엄격한 정족수(quorum)일 수도 있습니다. 분해자들은 제안을 멈추지 않으므로, 네트워크는 종종 여러 개의 경쟁하는 트리를 동시에 평가합니다. 결국 하나가 필요한 투표수를 확보하면, 그 하위 목표들은 초안(draft) 단계에서 수락(accepted) 단계로 승격됩니다.
Executor는 조율의 또 다른 계층을 추가합니다. 작업이 가십 채널에 공개되어 있기 때문에, 여러 executor가 동일한 매력적인 리프 노드를 차지하려고 시도할 수 있습니다. 타임스탬프 프로토콜이 타이브레이커 역할을 합니다. 각 클레임은 단조 증가하는 타임스탬프를 포함하며, 네트워크는 가장 빠른 것을 인정합니다. 패배한 쪽은 단순히 다음 사용 가능한 작업으로 넘어갑니다. 이는 투박한 방식이지만, 데이터베이스의 행을 잠그는 중앙 집중식 스케줄러의 필요성을 피할 수 있게 해줍니다.
설계에 의한 회복 탄력성
이 아키텍처는 장애가 발생했을 때 제 역할을 다합니다. decomposer가 하위 목표의 절반만 제안한 상태에서 충돌하더라도, 살아남은 decomposer들이 계속해서 분할을 제안합니다. 계획은 재시작을 기다리며 멈춰 서지 않습니다. scorer가 네트워크에서 이탈하더라도, 클러스터 규모를 적절하게 설정했다면 남은 투표자들이 여전히 쿼럼에 도달할 수 있습니다.
진정한 이점은 지연 참여(late joins)에 있습니다. 중간에 부팅된 새로운 에이전트는 스냅샷이나