OpenClaw 멀티 에이전트 오케스트레이션 해킹: 진정한 협업 구현

한 개발자가 에이전트들이 실제로 서로를 호출하지 않고 협업을 가장하고 있다는 사실을 발견한 후, OpenClaw를 수정하여 진정한 다중 에이전트 오케스트레이션을 구현한 경험을 공유했습니다.

문제점: 가짜 협업

개발자는 처음에 다양한 할당 모델을 가진 여러 에이전트(PM, 기획자, 백엔드, 프론트엔드, 디자이너)를 설정하고 오케스트레이터가 이들을 조정할 것으로 기대했습니다. 응답이 다른 섹션과 관점으로 구조화되어 나타났지만, 로그 분석 결과 PM 에이전트가 모든 작업을 혼자 수행하고 다른 에이전트들의 기여를 가장하고 있음이 드러났습니다. 다른 에이전트들은 실제로 호출되지 않았습니다.

핵심 문제: OpenClaw는 각 에이전트를 독립적인 단위로 취급하여 한 에이전트가 다른 에이전트를 생성하고, 결과를 기다린 후, 이를 다시 통합할 수 있는 내장된 방법이 없습니다.

해결책: 코어 런타임 수정

적절한 오케스트레이션을 구현하기 위해 개발자는 코어 런타임(reply-Bm8VrLQh.js)을 수정하여 다음을 처리하도록 했습니다:

sessions_spawn / sessions_yield를 통한 부모-자식 에이전트 생성
하위 에이전트 완료 이벤트가 부모에게 전달되도록 함
게이트웨이와 TUI를 위한 적절한 메시지 조립

sessions_yield 구현은 특히 어려웠으며, 비동기 흐름을 올바르게 설정하기 위해 약 90분 동안 지속적인 Codex 지원이 필요했습니다.

결과와 절충점

구현 후:

에이전트들이 이제 별도의 스레드에서 병렬로 실행됨
결과가 오케스트레이터에 의해 집계됨
PM이 통합 보고서를 받아 최종 출력을 형식화함
각 에이전트가 실제로 할당된 모델을 사용함(모두 기본 모델로 기본 설정되는 버그 수정)

절충점은 다음과 같습니다:

전체 파이프라인은 단일 에이전트의 거의 즉각적인 처리에 비해 30-60초 소요
2일간의 테스트 비용은 약 $0.90
활성 실행 중 메모리는 약 10-16GB 유지

하드웨어 및 초기 설정

개발자는 M4 Mac Mini(32GB)를 전용 AI 어시스턴트로 사용하여 지저분한 노트를 정리하고 연구를 요약했습니다. 처음에는 30B 모델로 LLM을 로컬에서 실행하려 했지만 매우 느려서 OpenClaw를 통해 상용 API(OpenAI, Claude, Gemini)로 전환했습니다.

오케스트레이션을 통한 출력 품질은 아직 평가 중입니다. 간단한 작업의 경우 단일 에이전트가 더 빠르고 저렴하지만, 복잡한 다단계 작업의 경우 전문화가 더 많은 튜닝과 함께 효과를 발휘할 수 있습니다.

📖 Read the full source: r/openclaw