지난 1년 동안 단일 에이전트 (Single agent)의 역량은 상당히 극적으로 확장되었습니다. 도구 호출 (Tool calling)은 불안정한 함수 선택 단계에서 벗어나 신뢰할 수 있는 다단계 계획 (multi-step planning) 단계로 진화했습니다. 코드 생성 (Code generation)은 코드 조각 완성에서 전체 모듈 구현 단계로 이동했습니다. 데스크톱 GUI 제어는 데모 영역을 넘어 실제로 의미 있는 OSWorld 벤치마크 수치에 도달했습니다. Mano CUA 1.1은 특화 모델 트랙에서 58.2%를 기록하며 2위인 opencua 72b보다 약 13포인트 앞섰고, WebRetriever NavEval은 41.7%를 기록하며 Gemini 2.5 Pro Computer Use의 40.9%와 Claude 4.5 Computer Use의 31.3%를 근소하게 앞질렀습니다. 이러한 수치들은 1년 전이었다면 믿기 어려웠을 것입니다.

하지만 단일 에이전트 시스템의 천장은 점점 더 명확하게 보이고 있습니다. 일단 작업이 동일한 루프 내에서 작동하는 하나 이상의 역할을 필요로 하게 되면, 문제들이 빠르게 쌓입니다. 교차 참조를 하기 전에 세 가지 소스에 걸쳐 병렬 조사가 필요한 경쟁사 분석, 작성 후 독립적인 보안 검토를 거쳐야 하는 코드, 하나를 선택하기 전에 두 개의 독립적인 초안을 원하는 창의적인 작업 등이 그 예입니다. 사람들은 여러 역할 설명을 단일 시스템 프롬프트 (system prompt)에 밀어 넣고 모델이 역할을 전환하게 하려고 시도해 왔지만, 실제로 역할 간의 주의력 분산 (attention bleed)을 제어하기는 어렵습니다. 글을 쓰는 에이전트는 자연스럽게 자신의 출력 품질을 과대평가합니다. 동일한 컨텍스트 체인 (context chain)을 공유하는 검토자는 자신이 생성되는 과정을 지켜본 문제들에 대해 관대해집니다. 우리는 코딩과 테스트가 동일한 에이전트 컨텍스트 내에 존재했던 초기 Mano AFK 테스트에서 이를 반복적으로 목격했습니다. 테스트는 형식적으로 변했고, 명백한 논리적 오류들이 통과되었으며, 에이전트들을 분리하고 나서야 상황이 개선되었습니다.

여러 에이전트 간에 작업을 분할하는 것은 새로운 아이디어가 아닙니다. 이는 수년 동안 논문에서 다뤄져 왔습니다.

변화한 것은 비용 구조입니다. 1년 전만 해도 다단계 작업(multi-step task)에 GPT 4 수준의 인스턴스 3개를 실행하는 것은 토큰 비용이 빠르게 쌓이는 것을 의미했습니다. 특히 수정 단계가 반복되는 반복적 개발 작업(iterative dev work)에서는 비용이 계속해서 발생했습니다. 하지만 이제 그 방정식은 달라 보입니다. 작고 온디바이스(on-device) 모델들이 예상보다 훨씬 빠르게 특정 작업에서의 격차를 좁혔습니다. Mano CUA 4B Thinking 모델은 M5 Pro에서 단계당 약 7.9초의 속도로 실행되며, 100개의 실제 macOS GUI 작업에서 56%의 성능을 기록했습니다. 이는 클라우드에서 실행되는 Qwen3 VL Plus가 39%를 기록한 것보다 17포인트 높은 수치입니다. GUI 자동화 및 이와 유사한 수직적 작업(vertical tasks)의 경우, 로컬 4B 모델이 실제로 일부 클라우드 호출을 대체할 수 있으며, M5 Pro나 M4 Mac mini에서 여러 에이전트 인스턴스를 동시에 실행하는 것도 더 이상 무리가 아닙니다. Cider SDK는 W8A8 및 W4A8 활성화 양자화(activation quantization)를 통해 이를 더욱 발전시키고 있으며, M5 Pro에서 실행되는 채널별(per channel) W8A8은 MLX W8A16 베이스라인보다 프리필(prefill) 속도를 약 1.8배 더 빠르게 만듭니다. MCP 채택 또한 통합 마찰(integration friction)을 줄여주고 있으며, 도구 인터페이스(tool interfaces)를 표준화하여 새로운 에이전트가 매번 커스텀 어댑터 스택(custom adapter stack)을 필요로 하지 않도록 하고 있습니다.

우리는 자율 소프트웨어 개발 파이프라인인 Mano AFK를 구축하는 과정에서 이 문제에 매우 직접적으로 부딪혔습니다. 이 시스템은 자연어(natural language)를 입력받아 제품 요구 사양서(PRD)를 생성하고, 코드를 작성하며, 배포하고, 여러 단계의 테스트를 실행하고, 결과에 따라 문제를 수정하여 작동하는 앱을 전달합니다. 테스트에는 린트(lint), API 체크, E2E GUI 실행이 포함되며, 로컬의 Mano P 또는 클라우드의 Claude CUA를 구동할 수 있는 별도의 적대적 리뷰어 에이전트(adversarial reviewer agent)가 포함됩니다. 첫 번째 버전은 코딩과 테스트가 단일 에이전트 컨텍스트(agent context) 내에서 이루어졌습니다. 그 결과는 지속적인 확증 편향(confirmation bias)이었습니다. 테스트 커버리지(test coverage)는 빈약했고, 엣지 케이스(edge cases)는 간과되었으며, 에이전트는 기본적으로 자기 숙제를 스스로 채점하는 격이었습니다. 코더(coder)와 테스터(tester)가 별도의 컨텍스트를 갖도록 분리하고, 테스터가 코더의 사고 과정에 접근할 수 없이 코드와 PRD만 볼 수 있게 하자 리뷰 품질이 즉시 향상되었습니다. 적대적 리뷰어(adversarial reviewer) 또한 완전히 격리되어야 했습니다. 만약 리뷰어가 코더가 어느 부분에서 타협했는지 또는 어떤 부분에서 어려움을 겪었는지 알게 된다면, 비판의 강도가 약해졌기 때문입니다. 5개의 웹 앱에 걸친 100개의 테스트 케이스로 구성된 CUA 벤치마크(CUA Benchmark)에서, W8A16은 전체 정확도 58%를 기록했으며, Cider를 사용한 W8A8은 약 1453 토큰(tok s)의 프리필(prefill) 속도로 54%를 기록했습니다. 양자화(quantization)를 통한 속도 향상은 멀티 에이전트(multi agent) 환경에서 더 중요합니다. 여러 인스턴스가 병렬로 실행될 때 프리필 대기(prefill queuing) 현상이 눈에 띄게 나타나기 때문입니다.

멀티 에이전트 시스템의 어려운 점은 여러 인스턴스를 실행하는 것이 아닙니다. 각 에이전트가 무엇을 볼 수 있는지 제어하는 것입니다.

초기 프레임워크의 상당수는 이 점을 간과하고, 모든 것을 공유 메시지 스트림 (shared message stream)이나 블랙보드 컨텍스트 (blackboard context)에 쏟아부어, 사실상 모든 에이전트가 모든 것을 듣게 되는 채팅방을 재현합니다. 실제 팀은 그런 방식으로 일하지 않습니다. 정보 비대칭 (Information asymmetry)은 인간의 협업에서 버그가 아니라, 실제로 업무가 수행되는 방식입니다. 브레인스토밍 (Brainstorming) 세션은 전체적인 가시성을 바탕으로 진행되는데, 그 목적 자체가 교차 수분 (cross pollination)이기 때문입니다. 코드 리뷰 (Code review)는 그 반대로 작동합니다. 차이점 (diff)을 확인하기 전에 저자가 모든 설계 결정을 설명하는 것을 듣게 되는 리뷰어는 더 약한 피드백을 줄 수밖에 없으며, 이것이 성숙한 팀이 책상 옆에 붙어 서 있는 대신 풀 리퀘스트 (pull requests)를 사용하는 이유입니다. 파이프라인 단계 (Pipeline stages)는 이전 단계의 출력값만 필요할 뿐이며, 상위 단계의 논의에서 오는 과도한 컨텍스트 (context)는 그저 노이즈 (noise)를 추가할 뿐입니다. 여러 사람에게 분산된 연구 과제는 실행 중에 각 트랙이 격리되어 있을 때 더 잘 운영됩니다. 그래야 접근 방식이 조기에 수렴하여 다양성을 해치는 것을 방지할 수 있기 때문입니다. 이러한 각 시나리오는 서로 다른 가시성 토폴로지 (visibility topology)를 요구하며, 이 모든 것을 하나의 공유 컨텍스트 모델 (shared context model)로 강제하는 것은 모든 용도에 단 하나의 데이터 구조 (data structure)를 사용하는 것과 같습니다. 작동은 하겠지만, 많은 잠재력을 놓치게 됩니다.

Octo는 이를 Loop 레벨에서 선택 가능한 6가지 오케스트레이션 (orchestration) 모드로 세분화합니다. Solo는 단순한 작업을 위한 단일 에이전트 실행입니다. Roundtable은 모든 참여자에게 토론과 아이디어 구상을 위한 완전한 가시성을 제공합니다. Critic은 실행자와 검토자를 완전히 격리하여, 검토 에이전트는 중간 추론 과정에 접근할 수 없이 최종 결과물만을 확인합니다. Pipeline은 각 에이전트가 바로 이전 단계의 출력값만 볼 수 있도록 단계를 체인 (chain) 형태로 연결합니다. Split은 작업을 상호 배타적인 청크 (chunk)로 나누어 격리된 병렬 상태로 실행하며, 모든 작업이 완료되면 메인 루프에서 결과를 병합합니다. Swarm은 동일한 작업에 대해 여러 개의 독립적인 에이전트를 가동하고 가장 강력한 결과를 선택합니다. 일단 모드가 선택되면 시스템이 컨텍스트 경계 (context boundaries), 메시지 라우팅 (message routing), 결과 병합을 처리하므로, 팀이 매번 메시지 큐 (message queue)와 컨텍스트 트리밍 (context trimming)을 처음부터 구축할 필요가 없습니다. 그 오케스트레이션 레이어 (orchestration layer)가 멀티 봇 채팅과 실제 협업 구조를 가르는 차이점입니다.

그룹 채팅은 에이전트 협업을 위한 잘못된 프리미티브 (primitive)입니다.

채팅 모델은 모든 참여자가 모든 메시지를 본다고 가정합니다. 이는 인간에게는 유효한데, 우리는 바쁜 채널의 노이즈를 걸러내며 공격적으로 필터링하기 때문입니다. 에이전트에게는 그런 사치가 없습니다. 특정 메시지를 무시하도록 지시하여 프롬프트 토큰 (prompt tokens)을 낭비할 수도 있지만, 이는 취약하고 신뢰할 수 없습니다. 아니면 전체 이력을 컨텍스트 윈도우 (context windows)에 밀어 넣어 낭비되는 비용을 지불해야 합니다. 더 근본적으로, 일부 협업 패턴은 평면적인 채팅 모델로는 단순히 표현될 수 없습니다. 진정한 독립적 초안 작성을 위해서는 공유 채널이 제공할 수 없는 메시지 격리가 필요합니다. Critic 모드의 검토 독립성은 모든 중간 출력물이 보일 때 무너집니다. 이것들은 프롬프트 엔지니어링 (prompt engineering)의 문제가 아니라, 정보 모델 (information model)의 제약 사항입니다.

오케스트레이션 (Orchestration)은 하나의 계층일 뿐입니다. 멀티 에이전트 시스템 (multi agent systems)이 결합력을 유지하려면 몇 가지 다른 요소들이 존재해야 합니다. 에이전트들은 자신이 무엇을 잘하는지 설명하는 정체성 메타데이터 (identity metadata)가 필요합니다. Octo는 AgentCard를 사용하여 역량 경계 (capability boundaries)를 표시하며, 이를 통해 향후 에이전트 간 (A2A) 라우팅 (routing) 시 라운드 로빈 (round robin) 방식 대신 적절한 에이전트에게 하위 작업 (subtasks)을 할당할 수 있습니다. 실행 과정에서의 피드백 (Feedback)이 쌓일 공간도 필요합니다. 작업이 반려된 이유, 리뷰 과정에서 발견된 공통적인 문제, 수락 과정에서 표현된 취향 (taste preferences) 등 이 모든 것들은 대화 로그 (conversation logs)에 묻혀 있다면 낭비될 뿐입니다. 선호도 시스템 (Preference system)은 이러한 피드백을 에이전트와 프로젝트에 연결하여, 향후 유사한 작업 시 이를 불러올 수 있게 합니다. 이는 시간이 지남에 따라 복리로 쌓입니다. 3개월간의 실제 프로젝트 피드백을 축적한 에이전트는 갓 배포된 에이전트와는 매우 다르게 동작합니다. 런타임 관리 (Runtime management)는 현재 V1 단계로, 로컬 프로세스 등록 (local process registration), 상태 확인 (health checks), 기본적인 리소스 할당 (resource allocation)을 지원하며, 멀티 머신 스케줄링 (multi machine scheduling)은 추후 도입될 예정입니다. 스킬 팩 (Skill packs)은 재사용 가능한 프롬프트 번들 (prompt bundles)과 MCP 마켓플레이스 (marketplace) 임포트를 지원합니다. 리드 에이전트 (lead agent)가 작업을 분해하고 알려진 강점에 따라 위임하는 A2A 라우팅은 로드맵에 포함되어 있습니다.

지난주 Octo 마켓플레이스에는 Docker Compose 원클릭 배포 기능이 추가되었으며, octo cli에는 전체 텍스트 검색 (full text search) 기능이 도입되었습니다. octo cli는 332개의 스타를 기록하며 Octo 생태계에서 가장 빠르게 성장하는 리포지토리 (repo)입니다. 전체 프로젝트는 GitHub의 Mininglamp OSS 조직 아래 Apache 2.0 라이선스로 운영됩니다. 런타임 계층은 모델 불가지론적 (model agnostic)이어서 OpenClaw, Codex, Claude Code, Hermes 또는 기타 백엔드 (backends)를 연결할 수 있습니다. 프라이빗 배포 (Private deployment)가 지원되므로 작업 데이터와 축적된 선호도는 사용자의 환경 내에 유지됩니다. Octo는 웹, 데스크톱, 모바일, 브라우저 확장 프로그램 및 CLI를 통해 제공되며, 네이티브 IM 통합을 지원하여 사용자가 별도의 작업 시스템으로 전환하지 않고도 그룹 채팅에서 에이전트를 직접 언급함으로써 루프 (loop)를 실행할 수 있습니다.

멀티 에이전트 오케스트레이션 (Multi agent orchestration)은 아직 초기 단계입니다. 정보 격리 (information isolation)를 위한 적절한 입도 (granularity), 선호도 피드백 (preference feedback)이 유용한 신호에서 노이즈 (noise)로 변하는 빈도, 또는 에이전트 간 (A2A) 라우팅 (routing) 결정 시 과거의 성능을 다른 신호들과 비교하여 어느 정도의 비중을 두어야 하는지에 대해 아직 완벽한 해답을 찾은 사람은 없습니다. 우리가 여섯 가지 모드를 먼저 출시한 이유는 이론에서 카테고리를 도출하기보다 실제 사용 과정에서 반복적으로 나타난 패턴들을 다루기 위해서였습니다. 이 여섯 가지가 전체 세트는 아니며, 사용이 깊어짐에 따라 더 많은 모드가 나타날 것입니다. 단일 에이전트의 도구 호출 (tool calling) 및 실행 (execution)이 데모 수준에서 진정으로 유용한 수준으로 발전하는 데 약 2년이 걸렸습니다. 멀티 에이전트 오케스트레이션 또한 아마도 그와 유사한 반복 (iteration) 과정이 필요할 것입니다.

https://github.com/Mininglamp-OSS