Skip to content
←

Split View: 에이전트를 다섯 개 돌리면 정말 다섯 배 빨라질까 — 병렬 작업의 병목은 생성이 아닙니다

✨ Learn with Quiz
|

에이전트를 다섯 개 돌리면 정말 다섯 배 빨라질까 — 병렬 작업의 병목은 생성이 아닙니다

오후 두 시에 디프 다섯 개가 동시에 도착했습니다

같은 이슈를 놓고 에이전트 다섯 개를 동시에 돌렸습니다. 20분 뒤에 다섯 개의 브랜치가 생겼고, 각각 300줄에서 900줄 사이의 변경이 들어 있습니다. 접근 방식은 셋이 비슷하고 둘이 다릅니다. 테스트는 넷이 통과하고 하나는 실패합니다.

여기서 생기는 일은 대개 이렇습니다. 다섯 개를 다 읽는 데 두 시간이 걸립니다. 두 시간 뒤에 하나를 고르는데, 고르고 나면 나머지 넷에서 좋았던 부분이 아깝습니다. 그래서 조금씩 옮겨 붙이다가 결국 여섯 번째 버전을 손으로 만듭니다. 생성에 든 20분은 확실히 줄었고, 그 뒤에 붙은 두 시간 반은 원래 없던 시간입니다.

이 글은 그 두 시간 반이 어디서 오는지에 대한 이야기입니다.

이런 환경이 실제로 파는 것은 모델이 아닙니다

Orca는 이 흐름을 정면으로 겨냥한 도구입니다. 저장소 설명은 스스로를 병렬 에이전트 무리를 다루기 위한 ADE라고 소개하고, 어떤 CLI 에이전트든 사용자 본인의 구독으로 돌린다고 밝힙니다. 즉 모델을 파는 제품이 아닙니다.

README가 첫 번째로 내세우는 기능은 병렬 워크트리입니다. 프롬프트 하나를 여러 에이전트에 뿌리고, 각각을 격리된 git worktree에 넣고, 결과를 비교해 이긴 것을 병합한다고 적혀 있습니다. 나머지 기능도 같은 방향입니다. 디프의 각 줄에 코멘트를 달아 에이전트에게 되돌려 보내기, GitHub과 Linear의 이슈를 앱 안에서 열어 바로 워크트리를 만들기, 원격 서버 위의 워크트리를 SSH로 붙이기, 브라우저에서 UI 요소를 클릭해 그 HTML과 CSS와 잘라낸 스크린샷을 프롬프트에 넣기.

목록을 늘어놓고 보면 공통점이 보입니다. 이 제품이 파는 것은 코드를 만드는 능력이 아니라 만들어진 것을 사람이 감당하는 표면입니다. 격리, 비교, 코멘트, 병합. 정확히 리뷰와 통합의 도구들입니다.

격리 부분은 오늘 git만으로 해 볼 수 있습니다

병렬 에이전트에서 가장 먼저 아픈 곳은 한 디렉터리를 여럿이 건드리는 상황입니다. 이건 git의 기본 기능으로 해결됩니다. 아래는 실제로 실행해 확인한 명령입니다.

# 저장소 안에서, 브랜치를 새로 만들면서 별도 디렉터리를 붙인다
git worktree add -b try/a ../wt-a
git worktree add -b try/b ../wt-b

git worktree list
# /path/main-repo  2072b5c [main]
# /path/wt-a       2072b5c [try/a]
# /path/wt-b       2072b5c [try/b]

각 디렉터리는 파일 트리와 빌드 산출물이 완전히 분리되어 있고, .git 객체 저장소는 하나를 공유합니다. 저장소를 다섯 번 클론하는 것과 결과는 비슷하되 디스크와 페치 시간은 훨씬 적게 듭니다.

정리할 때 걸리는 지점이 하나 있습니다.

git worktree remove ../wt-a
git branch --list
# * main
#   try/a      <- 워크트리는 지웠지만 브랜치는 남아 있다
# + try/b      <- 플러스 표시는 다른 워크트리가 잡고 있다는 뜻

워크트리를 지워도 브랜치는 그대로 남습니다. 실험 브랜치가 쌓이는 원인이 대개 여기입니다. 그리고 플러스 표시가 붙은 브랜치는 다른 워크트리가 체크아웃 중이라 이쪽에서 다시 체크아웃할 수 없습니다. 병렬로 돌리다 보면 반드시 만나는 제약이라 미리 알아 두는 편이 낫습니다.

병목은 사라지지 않고 자리를 옮깁니다

격리를 해결하고 나면 다음 벽이 나옵니다. 생성이 다섯 배 빨라져도 읽는 사람은 한 명입니다.

이 관계는 대기 행렬 이론의 리틀의 법칙 한 줄로 정리됩니다. 시스템 안에 평균적으로 머무는 작업 수를 L, 도착률을 람다, 평균 체류 시간을 W라고 하면 L은 람다와 W의 곱입니다. 뒤집으면 W는 L을 람다로 나눈 값입니다.

에이전트를 다섯 개로 늘린다는 것은 람다를 다섯 배로 올리는 일입니다. 리뷰 처리 능력이 그대로면 시스템 안의 L, 즉 리뷰를 기다리는 디프의 재고가 쌓입니다. 재고가 쌓이면 각 디프의 체류 시간 W가 늘어납니다. 체류 시간이 늘어난 디프는 그 사이에 베이스 브랜치가 움직여서 충돌이 생기고, 다시 고쳐야 하고, 다시 줄을 섭니다.

숫자 없이도 결론은 분명합니다. 리뷰 능력을 함께 올리지 않으면 병렬화는 완료 속도가 아니라 재고를 늘립니다. 오후 두 시의 두 시간 반은 여기서 옵니다.

그래서 볼 것은 생성 기능이 아니라 선별 기능입니다

이 관점으로 다시 보면 병렬 에이전트 도구를 고를 때 물어야 할 질문이 달라집니다. 몇 개를 동시에 돌릴 수 있는지가 아니라, 다섯 개 중 넷을 얼마나 싸게 버릴 수 있는지입니다.

버리는 비용을 낮추는 방법은 셋입니다. 첫째, 읽기 전에 기계가 먼저 떨어뜨리게 합니다. 각 워크트리에서 테스트와 린트를 자동으로 돌려 실패한 것을 리뷰 대상에서 빼는 것으로, 도구 없이도 스크립트로 됩니다. 둘째, 비교를 나란히 놓습니다. 다섯 개를 순서대로 읽으면 앞의 것을 잊지만, 같은 파일의 다섯 버전을 나란히 보면 차이만 남습니다. 셋째, 고친 점을 다시 사람이 옮겨 붙이지 않게 합니다. 디프 위에 코멘트를 달아 그대로 에이전트에게 돌려보내는 기능이 필요한 이유가 이것입니다. 앞서 본 Orca의 기능 목록이 정확히 이 세 가지에 몰려 있습니다.

다시 말해 이런 도구의 가치는 에이전트를 여러 개 돌린다는 데 있지 않습니다. 그건 터미널 다섯 개로도 됩니다. 가치는 넷을 버리는 비용을 낮추는 데 있습니다.

다섯 개가 비슷하면 다섯 배를 읽고 한 개를 얻습니다

여기서 한 겹 더 들어가야 할 것이 있습니다. 팬아웃이 정보를 주려면 후보들이 서로 달라야 합니다. 같은 프롬프트를, 같은 컨텍스트로, 같은 모델에 다섯 번 던지면 대개 대동소이한 답이 다섯 개 나옵니다. 그러면 읽는 비용은 정직하게 다섯 배인데 얻는 정보는 한 개분입니다. 앞의 오후 두 시 장면에서 셋이 비슷했던 이유가 보통 이것입니다.

다양성을 만드는 축은 세 가지입니다. 첫째는 프롬프트입니다. 같은 요구를 던지는 대신 접근 방식을 못 박아 나눕니다. 하나는 기존 추상화를 재사용하게 하고, 하나는 새 모듈을 만들게 하고, 하나는 가장 작은 변경만 하게 하는 식입니다. 이렇게 하면 비교가 구현 취향이 아니라 설계 선택의 비교가 됩니다. 둘째는 컨텍스트 범위입니다. 어떤 후보에게는 관련 파일만 주고 어떤 후보에게는 테스트와 이슈까지 줍니다. 셋째는 실행 주체입니다.

Orca가 특정 모델에 묶이지 않고 터미널에서 도는 CLI 에이전트라면 무엇이든 붙인다고 명시한 점은 세 번째 축에서 의미가 있습니다. 서로 다른 에이전트는 기본 프롬프트와 도구 사용 습관이 달라서, 같은 요구에도 다른 모양의 답을 냅니다. 다만 이건 제품이 가능하게 해 주는 축일 뿐이고, 실제로 다양성을 설계하는 것은 여전히 사람의 일입니다.

이 프로젝트의 현재 상태를 있는 그대로 적으면

과장하지 않기 위해 확인한 사실만 적습니다. 저장소는 2026년 3월 17일에 만들어졌고, 라이선스는 MIT이며, 주 언어는 TypeScript입니다. 데스크톱은 macOS, Windows, Linux를 지원한다고 표시되어 있고 Homebrew 캐스크와 AUR 패키지가 안내되어 있습니다. 모바일 동반 앱은 iOS는 App Store와 TestFlight, 안드로이드는 저장소 릴리스에 올라온 APK로 배포됩니다.

README는 스스로 매일 배포한다고 적고 있고, 그래서 기능 목록이 항상 뒤처져 있으니 릴리스 노트가 진짜 목록이라고 안내합니다. 저는 이 문장을 장점이자 경고로 읽습니다. 만들어진 지 반년이 안 된 데스크톱 앱이 매일 배포된다는 것은, 어제 되던 것이 오늘 다르게 동작할 수 있다는 뜻이기도 합니다. 확인한 시점에 열린 이슈는 3천 건이 넘습니다. 인기 있는 저장소에서 이 숫자 자체가 결함을 뜻하지는 않지만, 성숙도를 대신 말해 주지도 않습니다.

정리하면 이 도구는 쓸 만한지 여부를 남이 대신 판단해 줄 단계에 있지 않습니다. 팀의 코드가 들어가는 환경이므로, 도입한다면 그 판단을 직접 해야 합니다.

도구를 깔기 전에 이번 주에 해 볼 실험

설치 없이 워크플로만 먼저 시험해 보는 방법이 있습니다. 실제로 돈이 드는 부분은 도구가 아니라 리뷰이므로, 리뷰 쪽부터 재면 됩니다.

# 1) 같은 이슈로 브랜치 세 개를 판다 (에이전트를 세 개 돌리든, 사람이 세 번 시도하든)
for n in a b c; do git worktree add -b try/$n ../wt-$n; done

# 2) 사람이 읽기 전에 기계가 먼저 떨어뜨린다
for n in a b c; do
  ( cd ../wt-$n && npm test >/dev/null 2>&1 && echo "PASS $n" || echo "DROP $n" )
done

# 3) 살아남은 것만, 파일 단위로 나란히 본다
git diff try/a try/b -- src/

그리고 두 가지를 기록합니다. 살아남은 후보를 하나 고르는 데 실제로 몇 분이 걸렸는지, 그리고 고른 뒤에 다른 후보에서 손으로 옮겨 붙인 코드가 있었는지. 후자가 있었다면 그 팀에서는 팬아웃이 아직 이득이 아닙니다. 옮겨 붙이는 순간 다섯 개를 만든 이유가 사라지기 때문입니다.

이 측정을 한 주만 해 보면 도구를 살지 말지가 아니라 몇 개까지 뿌리는 것이 우리 팀에 맞는지를 숫자로 말할 수 있게 됩니다. 대개 그 숫자는 다섯보다 작습니다.

정리와 출처

병렬 에이전트 환경은 생성 처리량을 파는 것처럼 보이지만 실제로 파는 것은 선별과 통합의 도구입니다. 그리고 그 도구가 필요한 이유는 생성이 싸질수록 병목이 리뷰로 옮겨 가기 때문입니다. 도구를 고르기 전에 우리 팀의 리뷰 처리 능력을 먼저 재는 편이 순서가 맞습니다.

  • stablyai/orca 저장소 — 기능 목록, 지원 에이전트, 설치 경로, 라이선스. 이 글의 Orca 관련 서술은 모두 저장소 README와 저장소 메타데이터에서 직접 확인한 것입니다.
  • git worktree 공식 문서 — 워크트리 추가, 목록, 제거의 정확한 동작
  • 본문의 git 명령은 git 2.50.1에서 실제로 실행해 출력을 확인했습니다. npm test가 들어간 마지막 예시는 프로젝트마다 다르므로 그대로 실행해 보지는 않았습니다.

Does Running Five Agents Really Make You Five Times Faster — The Bottleneck in Parallel Work Is Not Generation

Five diffs arrived simultaneously at two in the afternoon

Five agents were run at once against the same issue. Twenty minutes later there were five branches, each containing between 300 and 900 lines of change. Three approaches are similar and two are different. Four pass the tests and one fails.

What happens next is usually this. Reading all five takes two hours. Two hours later you choose one, and once you have chosen, the good parts in the other four feel wasted. So you start grafting bits across and end up building a sixth version by hand. The twenty minutes spent on generation was certainly saved, and the two and a half hours attached afterwards is time that did not exist before.

This post is about where that two and a half hours comes from.

What environments like this actually sell is not a model

Orca is a tool aimed squarely at this trend. The repository description introduces it as an ADE for handling a swarm of parallel agents, and states that it runs whichever CLI agent you like on your own subscription. In other words it is not a product that sells a model.

The first feature the README leads with is parallel worktrees. It says it sprays one prompt at several agents, puts each in an isolated git worktree, compares the results, and merges the winner. The rest of the features run in the same direction: comment on individual lines of a diff and send it back to the agent, open GitHub and Linear issues inside the app and create a worktree straight from them, attach worktrees on remote servers over SSH, click a UI element in the browser and put its HTML, CSS, and a cropped screenshot into the prompt.

Lay the list out and the common thread shows. What this product sells is not the ability to produce code but the surface on which a human can cope with what has been produced. Isolation, comparison, comments, merge. Precisely the tools of review and integration.

The isolation part you can try today with git alone

The first thing that hurts with parallel agents is several actors touching one directory. That is solved by a basic git feature. Below are commands I actually ran and verified.

# inside the repository, create a new branch and attach a separate directory
git worktree add -b try/a ../wt-a
git worktree add -b try/b ../wt-b

git worktree list
# /path/main-repo  2072b5c [main]
# /path/wt-a       2072b5c [try/a]
# /path/wt-b       2072b5c [try/b]

Each directory has a completely separate file tree and build outputs, while the .git object store is shared. The result is similar to cloning the repository five times, but it costs far less disk and fetch time.

There is one place that catches you when cleaning up.

git worktree remove ../wt-a
git branch --list
# * main
#   try/a      <- the worktree is gone but the branch remains
# + try/b      <- the plus sign means another worktree holds it

Removing a worktree leaves the branch behind. This is usually the reason experiment branches accumulate. And a branch marked with a plus is checked out by another worktree, so it cannot be checked out again here. It is a constraint you will certainly meet when running things in parallel, so it is better to know about it in advance.

The bottleneck does not disappear, it relocates

Once isolation is solved, the next wall appears. Even if generation is five times faster, there is one person reading.

This relationship is captured in one line of queueing theory. Call the average number of jobs sitting in the system L, the arrival rate lambda, and the average time in system W; then L is the product of lambda and W. Flip it and W is L divided by lambda.

Raising the number of agents to five means raising lambda fivefold. If review capacity is unchanged, L inside the system — the inventory of diffs waiting for review — piles up. When inventory piles up, the time in system W of each diff grows. A diff whose time in system has grown finds that the base branch moved in the meantime, producing conflicts, so it has to be fixed and queue again.

The conclusion is clear even without numbers. If you do not raise review capacity alongside, parallelization raises inventory, not completion speed. The two and a half hours at two in the afternoon comes from here.

So what to look at is not the generation features but the selection features

Seen this way, the question to ask when choosing a parallel agent tool changes. Not how many you can run at once but how cheaply you can discard four out of five.

There are three ways to lower the cost of discarding. First, let the machine drop candidates before a human reads them. Run tests and lint automatically in each worktree and take the failures out of the review set — this works with a script and no tool at all. Second, put comparisons side by side. Read five in sequence and you forget the earlier ones; look at five versions of the same file side by side and only the differences remain. Third, stop making a human graft the fixes back across. This is why you need a feature that lets you comment on a diff and send it straight back to the agent. The Orca feature list we saw above is concentrated on exactly these three.

Put another way, the value of a tool like this is not that it runs several agents. Five terminals do that. The value is in lowering the cost of discarding four.

If all five are similar, you read five times and get one

There is one more layer to go into here. For fan-out to yield information, the candidates have to differ from one another. Throw the same prompt with the same context at the same model five times and you generally get five broadly identical answers. Then the reading cost is honestly fivefold while the information you gain is worth one. This is usually why three of them were similar in the two-in-the-afternoon scene above.

There are three axes for manufacturing diversity. The first is the prompt. Instead of throwing the same requirement at each, nail down and divide the approaches. Have one reuse the existing abstraction, have one create a new module, have one make the smallest possible change. Do that and the comparison becomes a comparison of design choices rather than of implementation taste. The second is the scope of context. Give some candidates only the relevant files and others the tests and the issue too. The third is the executing agent.

That Orca explicitly states it is not tied to a specific model and will attach any CLI agent that runs in a terminal is meaningful on that third axis. Different agents have different default prompts and tool-use habits, so they produce differently shaped answers to the same requirement. That said, this is only an axis the product makes possible; actually designing the diversity remains a human job.

Writing down the current state of this project as it is

To avoid overstating, I write only what I confirmed. The repository was created on 17 March 2026, the license is MIT, and the primary language is TypeScript. The desktop app is marked as supporting macOS, Windows, and Linux, and a Homebrew cask and an AUR package are documented. The mobile companion app is distributed through the App Store and TestFlight on iOS, and as an APK posted to the repository releases on Android.

The README states that it ships every day, and therefore warns that the feature list is always behind and that the release notes are the real list. I read that sentence as both a strength and a warning. A desktop app less than six months old shipping every day also means what worked yesterday may behave differently today. At the time I checked, the number of open issues was over three thousand. In a popular repository that number does not by itself indicate defects, but neither does it stand in for maturity.

In short, this tool is not at the stage where someone else can decide for you whether it is worth using. It is an environment your team's code passes through, so if you adopt it, you have to make that judgment yourself.

An experiment to try this week before installing anything

There is a way to test just the workflow without installing anything. What actually costs money is not the tool but the review, so measure the review side.

# 1) cut three branches from the same issue (run three agents, or try three times yourself)
for n in a b c; do git worktree add -b try/$n ../wt-$n; done

# 2) let the machine drop candidates before a human reads them
for n in a b c; do
  ( cd ../wt-$n && npm test >/dev/null 2>&1 && echo "PASS $n" || echo "DROP $n" )
done

# 3) view only the survivors, side by side at the file level
git diff try/a try/b -- src/

And record two things. How many minutes it actually took to choose one of the surviving candidates, and whether there was any code you grafted by hand from another candidate afterwards. If there was, fan-out is not yet a gain for that team, because the moment you start grafting, the reason for making five in the first place is gone.

Do this measurement for a single week and you will be able to state as a number not whether to buy a tool but how many candidates it makes sense for your team to spray. That number is usually smaller than five.

Summary and sources

Parallel agent environments look like they sell generation throughput, but what they actually sell is the tooling for selection and integration. And the reason that tooling is needed is that the cheaper generation gets, the further the bottleneck moves into review. Measuring your team's review capacity before choosing a tool is the right order.

  • The stablyai/orca repository — feature list, supported agents, installation paths, license. Everything written about Orca in this post was confirmed directly from the repository README and the repository metadata.
  • The official git worktree documentation — the exact behavior of adding, listing, and removing worktrees
  • The git commands in this post were actually run on git 2.50.1 and the output was verified. The final example containing npm test varies by project, so it was not run as written.