사전 공개: 저는 아래 나열된 9가지 도구 중 하나인 agentproto를 개발했습니다. 모든 사실은 날짜가 기재되어 있으며 각 프로젝트의 자체 문서 또는 리포지토리(repo)에서 가져왔습니다. 경쟁사가 저보다 뛰어난 부분은 있는 그대로 명시했습니다. 수정 사항은 언제든 환영합니다 — 이슈(issue)를 남겨주시면 수정하겠습니다.

대부분의 "최고의 오케스트레이터(best orchestrator)" 모음집은 순위를 매깁니다. 리더보드(leaderboard)를 제시하고, 승자를 왕관 씌워준 뒤, 3주 후에 당신이 깨닫게 만듭니다. 그 승자가 당신에게는 필요 없는 문제를 해결하고 있다는 사실을 말이죠.

이 글은 순위를 매기지 않습니다. 대신 "위치"를 정해줍니다. 왜냐하면 멋진 목록(awesome list)이 50개 이상의 항목으로 늘어났고, 그중 절반은 지난 6개월 동안 형태가 바뀌었기 때문입니다. 따라서 유용한 질문은 "어느 것이 최고인가"가 아니라, "내 설정의 특정 고충에 어떤 것이 맞는가"였습니다.

다른 것은 다 잊더라도, 이 한 가지 아이디어만은 기억하세요:
순위(ranking)는 누가 이겼는지를 알려줍니다. 지도(map)는 당신이 어디에 있는지를 알려줍니다. 두 가지 질문이 지도 위에서 어떤 오케스트레이터든 위치를 찾아낼 수 있습니다 — 누가 작업을 검토하는가(who checks the work), 그리고 누가 에이전트에게 장비를 갖춰주는가(who equips the agents) — 그리고 거의 모든 도구는 하나에는 답하면서 다른 하나는 조용히 회피합니다.

이 두 질문은 지형도(the landscape piece)가 끝나는 지점이며, 임의적인 것이 아닙니다. 이들은 모든 에이전트 함대(agent fleet)의 병목 현상을 제한하는 두 가지 측면입니다. 즉, "완료"가 참인지 결정하는 판단(judgment), 그리고 새로운 능력을 단일 에이전트가 아닌 모든 에이전트에게 전달하는 배관(plumbing) 작업입니다. 도구가 광고하는 다른 모든 것들 — 패널, 음성, 칸반 스윔레인(kanban swimlanes) — 은 이 두 질문에 어떻게 답하느냐 위에 구축된 UX(사용자 경험)일 뿐입니다.

방법론: 각 프로젝트의 자체 문서 및 리포지토리(repo) 확인, 2026-07-07 → 2026-07-14, 그리고 언급된 경우 직접 실습 세션 진행. 감독 단계(Supervision rungs)는 사다리(the ladder)를 참조합니다: L0 직접 관찰, L1 감시자(watchdogs), L2 권한 전달(permission relay), L3 검증 루프(verifier loops), L4 외부 정책 게이트(external policy gates).

두 가지 질문, 그리고 왜 지도가 10개가 아닌 2개의 축을 갖는가

도구의 브랜딩을 걷어내면, 그것은 두 가지 질문에 답하거나 혹은 그 질문들을 회피합니다.

첫 번째 질문 — 누가 작업을 검토하는가? 에이전트가 "완료되었습니다"라고 말할 때, 그것이 사실인지 여부를 무엇이 결정하는가? 이것이 바로 감독 계층(supervision ladder)입니다. 최하단(L0)에서는 검토자가 diff를 읽는 당신이며, 최상단(L4)에서는 에이전트가 볼 수 없거나 감언이설로 설득할 수 없는 프로세스로서, 게이트(gate)를 통과할 때까지 커밋(commit)을 붙잡고 있는 단계입니다. 그 계층(rung) 자체가 바로 답입니다.

두 번째 질문 — 누가 에이전트에게 장비를 갖춰주는가? 당신이 한 에이전트에게 새로운 도구(tool)나 기술(skill)을 부여했을 때, 다른 에이전트 중 몇 개가 이를 자동으로 얻게 되는가? 거의 모든 도구에 대한 답은 0입니다. 즉, 당신은 각 에이전트를 수동으로 재배선해야 하며, 이는 아무도 가격 페이지에 기재하지 않는 조용한 직렬 과세(serial tax)입니다. 벤더(vendor)들은 에이전트에게 장비를 갖춰주지만, 오직 자신들의 울타리 안에서만 가능합니다. 이 목록에 있는 도구 중 정확히 하나만이 당신의 도구를 모든 에이전트에게 배포합니다. 그것은 이 자체의 동반 글에서 다룹니다.

이 두 가지를 도표로 그리면, 이 분야는 순위가 아닌 하나의 형태(shape)로 분류됩니다. 콕핏(Cockpits)은 당신의 눈을 통해 첫 번째 질문에 답하고 두 번째 질문은 회피합니다. 스티어링 도구(Steering tools)는 인간에게 더 나은 인터페이스를 제공하며 두 질문 모두를 회피합니다. 오직 데몬(daemon) 형태만이 우측 상단 구석에 도달할 수 있으며, 오직 하나만이 그곳에 서 있습니다. 지도를 따라가 봅시다.

데몬(The daemons): 두 질문 모두에 답할 수 있는 유일한 형태

데몬은 API 뒤에서 세션(session)을 소유하는 장기 실행 프로세스(long-lived process)입니다. 이것은 *무인 상태(unattended)*로 실행될 수 있는 유일한 형태이며, 이는 위에서 언급한 L2 계층 이상의 첫 번째 질문과 두 번째 질문 모두에 답할 수 있는 유일한 형태임을 의미합니다.

agentproto (공개: 본인의 프로젝트)

agentproto homepage

로컬 데몬 (Local daemon) + CLI, Apache-2.0, 0.5.0-alpha. 하나의 매니페스트 계약(manifest contract) 아래 9개의 어댑터 (Claude Code, Anthropic/Moonshot/OpenRouter 게이트웨이를 사용하는 Claude SDK, Codex, Hermes, opencode, Mastra Code + Agent, browser-as-agent).
세 가지 베팅은 정확히 앞서 언급한 두 가지 질문과 이를 위임할 수 있는 안전성입니다:

• 작업 검증: L4. 세션에 완료 정책 (completion policy)이 부착됩니다. 턴이 종료될 때 게이트 (gate)가 작동합니다 — 쉘 명령 (lint/tests/typecheck) 또는 회의적인 판사 모델 (skeptical judge model) — 그리고 커밋은 인간의 승인 (human ack) 뒤에 스테이징(staged)됩니다. 이는 데몬 위에서 실행되므로, 노트북을 닫아도 계속 유지됩니다.
• 에이전트에게 장비 제공: 예 — 그리고 이것이 보기 드문 특징입니다. 도구(tool)를 한 번만 작성하면 (TOOL 계약 + DRIVER 구현, 일반 파일 형태), 데몬이 MCP를 통해 모든 에이전트에게 이를 제공합니다. 외부 MCP 서버를 가져와서 생성 시점에 어떤 에이전트에게든 전달할 수 있습니다. 한 번 작성하면 모든 에이전트가 이를 사용할 수 있습니다.
• 역할 기반 중첩 오케스트레이션 (Role-gated nested orchestration): 실행자 (executors)는 생성(spawn)할 수 없지만, 감독자 (supervisors)는 가능합니다 (깊이 및 자식 제한 포함). 따라서 에이전트가 머신에 포크 폭탄 (fork-bombing)을 일으키지 않고도 안전하게 팀을 관리할 수 있습니다.

솔직한 약점은 다음과 같습니다: 계속 변할 알파 API, 모바일 클라이언트 없음, 음성 지원 없음, 터미널 네이티브 UX만 지원함. 그리고 약 52개의 번호가 매겨진 AIP 사양 중, 데몬과 핵심 어댑터는 작동 가능한 상태이며 나머지는 초기 스캐폴딩 (scaffolding) 단계입니다. 만약 당신의 병목 현상이 휴대폰에서의 제어라면, 이 도구는 적절하지 않습니다. 계속 읽어보세요.

Paseo — 이 목록에서 가장 강력한 제어(steering) 도구

Paseo homepage

또 다른 진정한 데몬(daemon)이자, — 공정하게 평가하자면 — 어디서든 에이전트를 구동하기 위한 가장 뛰어난 도구입니다. 10.3k★ (2026-07-13 기준), AGPL-3.0, 1인 기업 제품입니다. 데몬(Daemon)과 더불어 데스크톱 / iOS / Android / 웹 / CLI 클라이언트, QR 페어링, 음성 제어 (로컬 또는 OpenAI STT/TTS), 공식 Docker 이미지, 그리고 셀프 호스팅 가능한 웹 UI를 제공합니다. 5가지 퍼스트 클래스 프로바이더 (Claude Code, Codex, Copilot, OpenCode, Pi) 외에도 커스텀 프로바이더 — 커스텀 바이너리, ACP 에이전트, Z.AI 및 Qwen과 같은 Anthropic 호환 엔드포인트 — 를 지원합니다. 실행 이력이 포함된 반복 스케줄링 기능도 있습니다. MCP 서버는 선택 사항(daemon.mcp.enabled)이므로 Claude Desktop이나 Code가 이를 제어할 수 있습니다.

저는 단순히 문서만 읽은 것이 아니라, 직접 설치하여 권한 릴레이(permission relay)를 처음부터 끝까지 실행해 보았습니다. 에이전트를 '항상 확인(always-ask)' 모드로 실행하고, Write 작업에서 멈추는 것을 지켜본 뒤, 다른 터미널에서 paseo permit allow로 승인하면 작업이 완료됩니다. 광고된 대로 정확하게 작동합니다.

실제 세션(2026-07-13)에서 발견한 두 가지 주의사항. 기본 Claude 모델이 Opus이므로, 실제 프롬프트를 입력하기도 전에 단 한 단어인 `

콕핏(Cockpit)은 당신이 그 안에 앉아서 검토하는 인터페이스입니다. 모든 솔루션은 첫 번째 질문에 대해 "당신이 지켜보고 있다" (L0 단계)라고 답하며, 두 번째 질문에 대해서는 "당신이 직접 각 에이전트를 재배선(rewiring)한다"라고 답합니다. 이는 비난이 아닙니다. 탐색적 작업(exploratory work)을 위해서는 L0가 올바른 단계입니다. 다만 그것은 천장이며, 그 천장은 바로 당신 자신의 주의력(attention)입니다.

측정된 천장. 감독 모델이 "사람이 각 창을 지켜보는 방식"인 도구들은 프로그래밍 가능한 API도, 턴(turn)별 게이트(gate)도 없으며, 앱을 닫으면 상태가 증발해 버립니다 — 사다리 조각이 정확한 벽을 가지고 있습니다. 그러면 팀들은 이를 보완하기 위해 tmux-plus-Redis 방식의 와치독(watchdog)을 직접 구현하게 되는데, 이는 데몬(daemon)을 나쁜 방식으로 재발명하는 꼴입니다.

Claude Squad — 터미널 우선(terminal-first) 방식의 클래식.

Claude Squad

tmux + git worktrees 기반의 AGPL-3.0 TUI, 멀티 에이전트 (Claude Code, Codex, Gemini, Aider), brew install claude-squad (tmux + gh 필요). 작업당 하나의 격리된 워크스페이스를 가지며, 수동으로 검토합니다. 설계상 L0 단계입니다 — 당신이 곧 루프(loop)입니다. API가 없으므로 두 번째 질문은 아예 고려 대상조차 되지 않습니다.

Conductor — 가장 세련된 L0 콕핏.

Conductor homepage

폐쇄 소스(Closed-source) Mac 앱: 리포지토리를 복제하고, 각 에이전트(Claude Code, Codex, Cursor)에게 고유한 git-worktree 워크스페이스를 부여하며, 진정으로 강력한 diff 뷰어와 PR 흐름을 제공합니다. Conductor Cloud 변형 버전이 존재합니다. macOS 전용이며 프로그래밍 가능한 접점(surface)은 없습니다 — 검토 처리량(review throughput) 자체가 제품의 전부이며, 그 기능에 매우 충실합니다.

Crystal → Nimbalyst — 형태가 앱보다 오래 지속됩니다.

Nimbalyst homepage

Crystal (worktree 내에서 병렬 Claude Code/Codex 세션을 위한 최초의 GUI인 Stravu의 Electron 앱)은 **2026년 2월에 지원이 중단(deprecated)**되었습니다. Nimbalyst는 그 후속작입니다. 동일한 모델에 세션 칸반(kanban), 연결된 작업 보드(task board), 클릭 한 번으로 가능한 워크트리 격리(worktree isolation), 세션별 디프(diff) 사이드바, 그리고 입력 시 푸시 알림을 지원하는 이 카테고리 내 유일한 네이티브 iOS 앱 기능이 추가되었습니다. 본질적으로는 여전히 L0 수준이지만, 모바일 모니터링 기능 덕분에 "어디서든 관찰하기"에 가까워졌습니다. 오픈 소스이며 Mac/Windows/Linux 및 iOS를 지원합니다.

Vibe Kanban — 주의가 필요한 데이터 지점입니다.

Vibe Kanban homepage

에이전트 칸반 보드 — 그리고 아래 표에서 "누가 이것을 유지 관리하는가?"가 실제 열(column)로 존재하는 이유입니다.

날짜가 찍힌 지속 가능성의 영수증. Vibe Kanban의 배후에 있는 기업인 Bloop는 2026년 4월에 폐업했습니다. 클라우드 서비스가 종료됨에 따라 이 프로젝트는 커뮤니티가 유지 관리하는 오픈 소스로만 생존하고 있습니다. 이런 사례는 혼자가 아닙니다. Opcode (이전 명칭 Claudia)는 더 이상 활발히 개발되지 않으며, Crystal은 Nimbalyst가 되었습니다. 오픈 소스 에이전트 도구를 지원이 보장되는 SaaS가 아니라, _당신이 소유한 로컬 도구_로서 평가하십시오. (Nimbalyst가 자체적으로 작성한 2026년 에이전트 관리 도구 요약본도 동일한 점을 지적합니다.)

배치 러너(batch runner)와 원격 제어

멀리서 감독하는 것처럼 보이지만, 알고 보면 첫 번째 질문에 별표(*)를 달고 답하게 되는 두 가지 도구입니다.

Claude Code Agent Farm — L1이며, 이에 대해 솔직합니다.