중앙 지휘자 없이 1,024개 에이전트가 스스로 일을 나누는 자가 조직 하네스 Agensh

무엇인가

대규모 언어 모델 기반 단일 에이전트는 컨텍스트 창 하나, 행동 스트림 하나, 메모리 스트림 하나에 묶여 있다. 그래서 복잡한 실제 과제에서는 작업을 순차적으로 처리할 수밖에 없고 지연이 커진다. 이 제약을 넘으려면 에이전트 수를 늘려야 하는데, Codex의 서브에이전트, Claude Code의 서브에이전트와 에이전트 팀, Copilot fleet, Kimi Agent Swarm 같은 기존 하네스 프레임워크는 대부분 오케스트레이터-워커 구조를 쓴다. 메인 에이전트가 계획을 세우고 과제를 분해해 워커에게 배정하고 관리하는 방식이며, Kimi는 오케스트레이터를 별도로 학습시키기까지 한다. 문제는 이 구조에서 전체 시스템의 확장성이 결국 오케스트레이터가 워커를 관리·조정하고 그 기여를 통합하는 능력에 의해 결정된다는 점이다. 논문이 겨냥하는 것이 바로 이 병목이다.

어떻게 동작하나

Agensh는 중앙 오케스트레이터를 없앤 자가 조직 멀티에이전트 하네스다. 워커들은 동시에, 비동기적으로 돌면서 가벼운 에이전트 조직 인프라를 통해 상태와 진행 상황을 공유한다. 인프라는 세 가지로 구성된다. 첫째, 공유 워크스페이스는 조직의 진행 중 작업과 통합된 결과를 담는 파일 시스템으로, 동시 쓰기와 비동기 읽기, 버전 이력 보존, 기여 병합을 지원하고 병합 충돌을 워커에게 노출해 되돌아가 해결할 수 있게 한다. 둘째, 메시지 인터페이스는 팀 공지를 나르는 공유 태스크 채널과 긴급한 일대일 직접 메시지를 제공한다. 셋째, 공유 컨텍스트는 재사용 가능한 발견과 작업 의도를 보관한다.

무엇과 다른가

각 워커는 다섯 단계 협력 루프를 반복한다. 먼저 컨텍스트를 수집해 사용자 목표, 현재 상태, 동료 진행 상황, 메시지, 누적된 발견을 읽고 다음에 할 일을 계획한다. 다음으로 서브태스크를 제안하고 그 범위를 CLAIM으로 공유 컨텍스트에 덧붙여 선언한다. 두 워커의 클레임이 겹치거나 충돌하면 직접 메시지로 해결하도록 권장된다. 그다음 도구를 써서 로컬에서 작업하고, 다른 워커에 도움이 될 발견이 생기면 공유 컨텍스트에 중간 진행을 보고한다. 이후 자신의 진행을 서브태스크의 수용 기준과 대조해 검증하고, 기준을 만족할 때까지 접근을 수정한다. 마지막으로 기여를 공유 워크스페이스에 병합하고 무엇이 바뀌었는지, 어떤 아이디어였는지, 검증 증거는 무엇인지 담은 업데이트를 발행한다. 병합이 충돌로 막히면 최신 동료 진행을 반영해 충돌을 해결한 뒤 다시 병합하고, 다시 1단계로 돌아간다.

어떻게 쓰나

구현에서 Agensh는 단일 에이전트 하네스를 대체하는 것이 아니라 그 위에 얹히는 조직 하네스다. 대화 상태 유지, 모델 호출, 도구 실행 같은 로컬 에이전트 루프는 기존 단일 에이전트 하네스가 맡고, Agensh는 워커 아이덴티티, 협력 프로토콜, 이벤트 라우팅, 공유 워크스페이스 접근, 메시징, 공유 컨텍스트, 복구와 생존성 같은 조직 수준 동작을 공급한다. 협력 루프는 런타임에 하드코딩된 것이 아니라 각 워커 프롬프트의 워크플로 지시로 실현되며, 워커 ID만 다르고 나머지 프롬프트는 완전히 동일하다. 덕분에 Claude Code나 Copilot 같은 다른 하네스에도 가벼운 어댑터만 붙이면 연결된다. 공유 워크스페이스는 Gitea, 메시지 인터페이스는 Mattermost로 구현했고, 공유 컨텍스트는 DeLM의 핵심 아이디어를 따르되 도구 형식과 워커 지시를 조정했다. 공유 컨텍스트 항목은 OBSERVED, FACT, FAIL, CLAIM, PATCH_SUMMARY 같은 타입으로 발행되고, 최근 기억을 넘어 전체 이력을 검색하는 context grep 도구가 제공된다.

전제와 한계

실험은 ProgramBench에서 수행했다. 인터넷 접근이 차단된 상태에서 6시간 예산 안에 참조 소프트웨어의 동작을 재현해야 하는, 에이전트 소프트웨어 엔지니어링 벤치마크다. 200개 인스턴스 중 최상위 모델 기준 평균 테스트 통과율이 가장 낮은 다섯 개, 즉 FFmpeg, gromacs, pandoc, PHP-src, ctags를 골랐다. 참조 저장소는 파일 수천 개, 소스 코드 수십만에서 수백만 줄 규모다. 모델은 GPT-5.6-sol (high), 단일 에이전트 하네스는 Copilot, 예산은 6시간으로 고정하고 에이전트 수만 바꿨다. 다섯 과제 평균 최종 테스트 통과율은 1개일 때 19.31%, 8개 20.68%, 32개 26.52%, 128개 28.78%로 올랐다. 1개에서 128개로 늘린 상승폭은 9.47%포인트, 상대 개선으로 약 49%다. 지연 측면에서도 pandoc에서는 128개 조직이 30분 체크포인트에 30% 통과율을 넘어섰고, 32개는 60분, 8개는 90분에 그 문턱을 처음 넘었으며 단일 에이전트는 처음 두 시간 내내 넘지 못했다. pandoc에서 1개 33.89%였던 최종 통과율은 128개에서 50.94%, 1,024개에서 55.06%가 됐다. 1,024개 조직은 128개 결과보다 4.12%포인트, 단일 에이전트보다 21.17%포인트 높다.

논문은 성능 수치와 함께 워커 궤적에서 관찰된 자가 조직 협력의 변화를 보고한다. 모든 워커가 워커 ID 외에는 같은 프롬프트와 같은 루프를 받는데도 규모가 커지면서 협력 형태가 달라진다. 8개 규모에서는 구체적인 기술 인터페이스에 합의하고 각자 그에 맞는 컴포넌트를 구현하며(gromacs의 모듈 인터페이스), 겹치는 클레임을 스스로 발견해 조정한다(FFmpeg에서 한 워커가 범위를 바꿔 상보적 작업을 맡은 사례). 32개 규모에서는 여러 워커가 하나의 기여를 함께 다룬다. PHP-src에서 여러 동료가 처음 승인한 기여에 다른 워커가 반례를 찾아내자 승인이 철회되고 작성자가 문제를 고친 뒤 재검토와 병합이 이뤄졌다. 128개 규모에서는 전문화와 워크플로 표준화가 나타난다. 관련 경험이 있는 동료를 리뷰어로 선택하고 그 관계를 재사용하며, pandoc에서는 작성자가 브랜치를 갱신·테스트한 뒤 커밋 해시를 보내 동료가 검증하고 병합하는 통합 프로토콜이 정착해 다른 워커들이 재사용했다. 실패가 쌓이자 동료에게 갱신·테스트·확인·병합 전체 사이클을 맡기는 권한을 주는 방식으로 프로토콜을 개정하기도 했다. 1,024개 규모에서는 조직 수준의 역할 전문화가 나타난다. 여러 워커가 통합자 역할을 맡고, 한 워커가 여러 후보 통합자에게 접촉해 가장 먼저 유효한 응답을 준 상대를 고른 뒤 나머지 요청을 취소하고 코드를 넘긴다. 같은 기술 영역을 전담하는 워커들이 다른 워커의 시도가 실패한 뒤 작업을 이어받아 복구하기도 해, 특정 워커에 대한 의존을 줄인다.

실무 관점에서 이 논문이 던지는 메시지는 분명하다. 지연 예산이나 시간 예산이 빡빡한 장기 과제에서, 모델이나 단일 에이전트 하네스를 바꾸지 않고도 동시에 투입하는 워커 수를 늘리는 것 자체가 성능과 도달 시간을 함께 개선하는 스케일링 축이 될 수 있다는 것이다. 특히 오케스트레이터를 따로 학습시키거나 중앙 스케줄러를 튜닝하지 않고, Git 기반 공유 워크스페이스와 메시지 채널, 타입이 붙은 공유 컨텍스트라는 이미 익숙한 도구 조합으로 조직을 구성한다는 점이 참고할 만하다. 다만 도입을 검토한다면 워커 간 클레임 충돌과 병합 충돌이 실제로 얼마나 발생하는지, 공유 컨텍스트가 커질 때 검색 비용이 어떻게 변하는지, 그리고 에이전트 수를 늘릴 때 비용이 어떻게 늘어나는지를 함께 확인해야 한다.

원문에 별도의 한계 절은 없고, 대신 실험의 전제가 명시돼 있다. 모든 결과는 인터넷이 차단된 상태에서 6시간 예산이 주어지는 ProgramBench 소프트웨어 재현 과제에서, GPT-5.6-sol (high)와 Copilot이라는 동일 모델·동일 단일 에이전트 하네스를 고정하고 에이전트 수만 바꾼 비교다. 따라서 다른 모델이나 다른 하네스, 다른 종류의 과제로 일반화되는지는 이 논문의 범위 안에서 확인되지 않는다. 또한 오케스트레이터 기반 하네스와 Agensh를 같은 조건에서 직접 비교한 수치는 원문에 제시되지 않았고, 에이전트 수를 1,024개까지 늘릴 때 드는 비용이나 토큰 소모에 대한 수치도 제시되지 않았다. 1,024개 규모 실험은 pandoc 한 개 과제에서만 수행됐다는 점도 함께 봐야 한다.