Conductor, Claude Squad, Emdash, Orca and Wooi all do the same first thing: give every agent its own isolated git worktree so N tasks can run at once. That part is settled. This page compares what they do after that — and everything in the table below comes from each project's own documentation. Conductor, Claude Squad, Emdash, Orca, Wooi 는 모두 에이전트마다 격리된 git worktree 를 두고 여러 작업을 동시에 돌립니다. 이제 이 기능은 기본에 가깝습니다. 이 페이지는 그 다음에 무엇을 할 수 있는지 비교합니다. 아래 내용은 각 프로젝트의 공식 문서에서 확인했습니다.
This comparison is days old. It was last verified against each project's documentation on 1 September 2026, and these projects ship fast. Treat every "not documented" as a statement about that date, not about today — check the project's own docs before you decide, and open an issue if something here is now wrong. 이 비교는 일 지났습니다. 2026년 9월 1일에 각 프로젝트 문서를 기준으로 마지막으로 확인했고, 여기 있는 프로젝트들은 빠르게 바뀝니다. "문서 없음"은 전부 그 날짜에 대한 진술이지 오늘에 대한 진술이 아닙니다. 결정하기 전에 각 프로젝트의 공식 문서를 확인하시고, 틀린 부분이 있으면 이슈를 열어 주세요.
Run four agents on four unrelated bugs and any tool here will serve you well. The picture changes the moment task B needs task A's code before it can start. 서로 상관없는 버그 네 개에 에이전트 넷을 붙이는 일이라면, 여기 있는 어떤 도구를 써도 잘 굴러갑니다. 그림이 달라지는 건 B 작업이 A 작업의 코드 없이는 시작조차 못 하는 순간부터입니다.
Stacking. Can a new task branch off another task's branch instead of
off main? Without it, task B either waits for A to merge, or starts from
main and re-implements A's changes so its own diff makes sense.
스태킹. 새 작업을 main 이 아니라 다른 작업의 브랜치에서
딸 수 있는가? 이게 없으면 B 는 A 가 병합될 때까지 기다리거나, main 에서
시작해 A 의 변경을 다시 만들어 넣어야 자기 diff 가 말이 됩니다.
What happens on merge. Stacking is the easy half. The hard half is the parent merging: every child is now based on a commit that no longer exists on the target branch, and every child PR still points at a merged base. Someone has to rebase the children and retarget the PRs — either the tool, or you, by hand, in order, every time. 병합된 다음. 스택을 쌓는 건 쉬운 쪽입니다. 어려운 쪽은 부모가 병합될 때입니다. 자식들은 이제 타깃 브랜치에 없는 커밋 위에 얹혀 있고, 자식 PR 은 전부 병합된 base 를 가리키고 있습니다. 누군가는 자식을 rebase 하고 PR base 를 다시 잡아야 합니다. 도구가 하든지, 아니면 매번 사람이 순서대로 손으로 하든지.
Review, on the diff. Most tools here let you click a diff line and send a note to the agent that wrote it — a feedback loop for your own work. A separate question is whether you can pull up somebody else's open pull request and leave review comments that land on GitHub as review comments. diff 위에서 하는 리뷰. 여기 있는 도구 대부분은 diff 한 줄을 찍어 그걸 쓴 에이전트에게 메모를 보낼 수 있습니다. 내 작업을 다듬는 피드백 루프입니다. 그와는 별개로, 남이 열어 둔 pull request 를 불러와 GitHub 에 실제 리뷰 코멘트로 남길 수 있느냐는 또 다른 질문입니다.
Verified against each project's own README and documentation on 1 September 2026. Every cell is a statement about what those documents said on that date — these projects ship fast, so read "not documented" as "not described then", never as "missing now". Undocumented behaviour may well exist. 2026년 9월 1일에 각 프로젝트의 README 와 공식 문서를 기준으로 확인했습니다. 표의 모든 칸은 그 날짜에 그 문서들이 무엇을 말했는지에 대한 진술입니다. 여기 있는 프로젝트들은 빠르게 바뀌므로, "문서 없음"은 "그때 문서에 없었다"로 읽어야지 "지금 없다"로 읽으면 안 됩니다. 문서에 없는 동작이 실제로 있을 수 있습니다.
| Capability기능 | Wooi | Conductor | Claude Squad | Emdash | Orca |
|---|---|---|---|---|---|
| The settled part이미 정리된 부분 | |||||
| Run coding agents in parallel 코딩 에이전트 병렬 실행 | Yes | Yes | Yes | Yes | Yes |
| Isolated git worktree per task 작업마다 격리된 git worktree | Yes | Yes | Yes | Yes | Yes |
| Open a pull request from the app 앱에서 pull request 열기 | Yes | Yes | not documented문서 없음1 | Yes | Yes |
| Comment on a diff line, back to the agent diff 줄에 코멘트해서 에이전트에게 전달 | Yes | Yes | not documented문서 없음 | not documented문서 없음 | Yes |
| Where the tools diverge도구가 갈리는 부분 | |||||
| Stack dependent work 의존적 작업 스태킹 Branch a new task off another task's branch 새 작업을 다른 작업의 브랜치에서 따기 | Yes | not documented문서 없음 | not documented문서 없음 | not documented문서 없음 | Yes2 |
| Parent merges → children rebased 부모 병합 → 자식 자동 rebase Automatically, for the whole chain 체인 전체에 대해 자동으로 | Yes | not documented문서 없음 | not documented문서 없음 | not documented문서 없음 | not documented문서 없음 |
| Parent merges → child PR bases retargeted 부모 병합 → 자식 PR base 재타게팅 Child PRs repointed at the grandparent branch 자식 PR 을 조부모 브랜치로 다시 겨냥 | Yes | not documented문서 없음 | not documented문서 없음 | not documented문서 없음 | not documented문서 없음 |
| Adopt a stack created outside the app 앱 밖에서 만든 스택 인식 Rebuild the chain from existing PR base branches 기존 PR 의 base 브랜치로 체인 복원 | Yes | not documented문서 없음 | not documented문서 없음 | not documented문서 없음 | not documented문서 없음 |
| Review someone else's PR as its own task 남의 PR 리뷰를 독립된 작업으로 Dedicated worktree, comments posted to GitHub as review comments 전용 worktree, 코멘트는 GitHub 리뷰 코멘트로 게시 | Yes | not documented문서 없음 | not documented문서 없음 | not documented문서 없음 | partial일부3 |
| Shape of the thing도구의 형태 | |||||
| Platform플랫폼 | macOS | macOS | Terminal터미널 | macOS · Windows · Linux | macOS · Windows · Linux · mobilemacOS · Windows · Linux · 모바일 |
Wooi
s in its menu);
its README does not describe opening the pull request itself.
Claude Squad 는 브랜치를 커밋하고 GitHub 에 push 합니다(메뉴의 s). pull
request 를 여는 것까지는 README 에 적혀 있지 않습니다.
--parent-worktree
/ --no-parent). Automatic rebasing or PR retargeting after a parent
merges is not described.
Orca 의 worktree 문서에는 "Another local branch — useful for stacking work on top of
a PR in review" 라는 선택지가 있고, CLI 에 부모/자식 worktree 계보가 있습니다 (--parent-worktree
/ --no-parent). 다만 부모가 병합된 뒤의 자동 rebase 나 PR 재타게팅은
문서에 없습니다.
These are all good tools built by people solving a real problem. They are not the same tool, and the right pick depends on which part of the problem is biting you. 여기 있는 건 전부 실제 문제를 풀려고 만든 좋은 도구입니다. 서로 같은 도구가 아니고, 지금 나를 물고 있는 문제가 무엇이냐에 따라 답이 달라집니다.
The tightest native loop around Claude Code, Codex and Cursor. Every task gets a workspace — branch, files, terminal, diff, review path — backed by a git worktree, and the diff viewer lets comments point at changed lines so the agent gets precise context instead of a paragraph of chat. If you want one polished Mac app and your tasks are independent, this is the shortest path. Claude Code, Codex, Cursor 를 감싸는 가장 매끄러운 네이티브 루프입니다. 작업마다 워크스페이스가 생기고 — 브랜치, 파일, 터미널, diff, 리뷰 경로까지 — 그 밑을 git worktree 가 받칩니다. diff 뷰어에서는 코멘트가 변경된 줄을 직접 가리켜서, 에이전트가 긴 채팅 대신 정확한 맥락을 받습니다. 잘 다듬어진 맥 앱 하나면 되고 작업들이 서로 독립적이라면 이게 가장 빠른 길입니다.
The lightest thing here, and deliberately so. One terminal window manages many agents — Claude Code, Codex, Gemini, Aider — each in its own worktree, running tasks in the background including auto-accept mode. Diff tab, review, commit, push. If you live in tmux and want nothing between you and the agents, it is hard to beat. 여기서 가장 가벼운 도구고, 일부러 그렇게 만들었습니다. 터미널 창 하나로 여러 에이전트 — Claude Code, Codex, Gemini, Aider — 를 각자의 worktree 에서 관리하고, 자동 수락 모드를 포함해 백그라운드로 작업을 돌립니다. diff 탭, 리뷰, 커밋, push. tmux 안에서 살고 에이전트 사이에 아무것도 끼우고 싶지 않다면 이걸 이기기 어렵습니다.
The one that reaches furthest into the rest of your stack. Bring whichever CLI agent you already use, pull work in from Linear, GitHub, Jira, GitLab, Asana and more, run it locally or on a remote machine over SSH, then review diffs, open PRs and watch CI checks from one place. Open source, cross-platform, and moving fast. 개발 스택의 나머지 부분까지 가장 멀리 뻗는 도구입니다. 이미 쓰던 CLI 에이전트를 그대로 가져오고, Linear · GitHub · Jira · GitLab · Asana 등에서 할 일을 끌어오고, 로컬이든 SSH 로 붙은 원격 머신이든 거기서 돌린 다음, diff 리뷰와 PR 생성과 CI 체크 확인을 한 곳에서 합니다. 오픈소스이고, 크로스 플랫폼이고, 빠르게 움직입니다.
The widest surface area of the group. Fan a single prompt across five agents in five worktrees and merge the winner, drop comments on any diff line and ship them back, run worktrees over SSH, drive the whole thing from a CLI, and carry it in your pocket on iOS and Android. It is also the only other tool here whose docs name stacking directly — you can start a worktree from another local branch to stack on a PR that is still in review. 이 중에서 다루는 범위가 가장 넓습니다. 프롬프트 하나를 다섯 worktree 의 다섯 에이전트에 뿌려 놓고 이긴 쪽을 병합하고, diff 아무 줄에나 코멘트를 달아 돌려보내고, worktree 를 SSH 로 원격에서 돌리고, 전체를 CLI 로 조종하고, iOS · Android 로 들고 다닙니다. 여기서 문서에 스태킹을 직접 언급하는 유일한 다른 도구이기도 합니다 — 아직 리뷰 중인 PR 위에 얹으려고 다른 로컬 브랜치에서 worktree 를 시작할 수 있습니다.
Same starting point as everyone else — one worktree, one branch, one agent per
task, running in parallel. What Wooi adds is the rest of the story. Stack a
workspace on another workspace's branch, and when the parent PR merges, Wooi
retargets each child PR's base to the grandparent branch and rebases the children
onto it, so the rest of the chain stays valid instead of quietly rotting. A stack
you built by hand with git checkout -b and
gh pr create gets picked up too, reconstructed from the PRs' base
branches. And reviewing someone else's PR is its own row in the sidebar with its own
worktree — three panes, comments batched and posted to GitHub as real review
comments.
출발점은 다른 도구들과 같습니다. 작업마다 worktree 하나, 브랜치 하나, 에이전트
하나가 병렬로 돕니다. Wooi 가 더하는 건 그 다음 이야기입니다. 워크스페이스를 다른
워크스페이스의 브랜치 위에 스택으로 얹고, 부모 PR 이 병합되면 Wooi 가 각 자식 PR 의
base 를 조부모 브랜치로 다시 잡고 자식들을 그 위로 rebase 합니다. 나머지 체인이
조용히 썩는 대신 멀쩡하게 남습니다. git checkout -b 와
gh pr create 로 직접 쌓은 스택도 PR 의 base 브랜치를 읽어 복원합니다.
남의 PR 리뷰는 사이드바에서 자기 줄과 자기 worktree 를 갖습니다. 세 개의 패널,
모아서 보내는 코멘트, GitHub 에 실제 리뷰 코멘트로 게시.
Worth being honest about, because for plenty of workflows the answer is no. 솔직하게 적어 둡니다. 적지 않은 경우에 답은 "아니오"입니다.
Free and open source under Apache 2.0. Bring your own Claude Code or Codex. Apache 2.0 오픈소스, 무료입니다. Claude Code 나 Codex 는 쓰던 걸 그대로 가져오면 됩니다.
Download for macOSmacOS 용 다운로드