Orca vs Herdr 비교: 멀티 에이전트 코딩 툴, 언제 뭘 써야 할까 (오케스트레이션 관점 정리)

요즘 Claude Code, Codex, Antigravity CLI 같은 터미널 기반 코딩 에이전트를 하나만 쓰는 사람은 드뭅니다. 두세 개를 동시에 띄워놓고 작업을 나눠 맡기다 보면 어느 순간 터미널 창이 뒤엉키고, 어떤 에이전트가 승인을 기다리는지, 어떤 게 끝났는지 한눈에 안 보이는 상황이 옵니다.

이 문제를 풀겠다고 나온 툴이 여럿 있는데, 그중 요즘 가장 많이 언급되는 두 개가 Orca와 Herdr입니다. 둘 다 "여러 코딩 에이전트를 한 곳에서 관리한다"는 목표는 같지만, 접근 방식이 완전히 다릅니다. 이 글에서는 두 툴의 구조적 차이, 장단점, 그리고 오케스트레이션 관점에서 어떤 상황에 어떤 툴이 맞는지를 정리합니다. 마지막에는 Claude Desktop이나 Antigravity 같은 단일 앱 대신 굳이 이런 툴을 써야 하는 이유도 짚어보겠습니다.

1. 한 줄 요약

항목	Orca	Herdr
정체	ADE (Agent Development Environment). 에이전트를 위한 데스크톱 IDE	Agent Runtime. 터미널 안에서 돌아가는 에이전트 런타임 + 멀티플렉서
형태	GUI 데스크톱 앱 (macOS / Windows / Linux) + 모바일 컴패니언 앱	Rust 단일 바이너리. 기존 터미널 안에서 실행 (macOS / Linux / Windows)
핵심 단위	Git worktree 기반 워크스페이스	서버가 소유하는 터미널 pane + 에이전트 상태(state)
라이선스	MIT	Apache 2.0
설치	brew install --cask stablyai/orca/orca 또는 onorca.dev 다운로드	curl -fsSL https://herdr.dev/install.sh | sh 또는 brew install herdr
지원 에이전트	Claude Code, Codex, Gemini, Antigravity, Cursor, Copilot, OpenCode 등 CLI라면 전부	21종 자동 감지 (Claude Code, Codex, Antigravity CLI, Cursor, Copilot, OpenCode 등)
비유	VS Code를 에이전트용으로 다시 만든 것	tmux가 에이전트를 이해하게 된 것

2. 구조가 어떻게 다른가

이 둘을 비교할 때 가장 중요한 질문은 딱 하나입니다. "내가 보고 있던 창을 닫으면 에이전트는 어떻게 되는가?"

Orca: 앱이 곧 작업 환경

Orca는 GUI 앱 자체가 워크트리, 터미널, 에디터, 브라우저, GitHub/Linear 연동을 전부 품고 있는 통합 환경입니다. 하나의 태스크마다 독립된 git worktree를 만들고, 그 안에서 에이전트를 띄웁니다. 에이전트가 만든 diff에 라인 단위로 코멘트를 달아 다시 에이전트에게 돌려보내고, 내장 Chromium 브라우저에서 UI 요소를 클릭해 HTML/CSS/스크린샷을 프롬프트에 바로 넣는 Design Mode까지 제공합니다.

즉 "사람이 여러 에이전트를 감독하고 리뷰하는 허브"로 설계되어 있습니다. 대신 앱을 종료하면 그 안에서 돌던 작업 환경도 함께 내려갑니다. (원격 서버에서 orca serve로 headless 실행하는 방식은 별도로 지원합니다.)

Herdr: 서버가 터미널을 소유하고, UI는 클라이언트일 뿐

Herdr는 완전히 반대 방향입니다. 백그라운드 서버가 모든 터미널(PTY)을 소유하고, 우리가 보는 TUI는 그 서버에 붙는 클라이언트 중 하나일 뿐입니다. TUI를 닫든, SSH가 끊기든, 심지어 클라이언트가 크래시 나든 에이전트는 계속 돌아갑니다. 나중에 노트북이든 서버든 아무 터미널에서나 다시 attach하면 떠날 때 그 상태 그대로 있습니다.

여기에 tmux에는 없던 것이 하나 추가됩니다. Herdr는 어떤 pane이 에이전트인지, 그 에이전트가 idle / working / blocked / done 중 어떤 상태인지를 압니다. 이 상태는 pane → tab → workspace로 롤업되어 사이드바에 표시되고, CLI/소켓 API로 스크립트나 다른 에이전트가 읽어갈 수 있습니다.

Herdr 공식 비교 페이지의 표현을 빌리면: "tmux는 pane을 보고, Herdr는 에이전트를 본다." 그리고 Orca 같은 매니저 앱에 대해서는 "에이전트를 관리하는 창이지, 에이전트가 사는 곳은 아니다"라고 선을 긋습니다.

3. Orca 장단점

장점

• 워크트리 관리가 기본 내장: 태스크 하나 = 워크트리 하나. 같은 레포에서 에이전트 다섯 개를 돌려도 서로 파일을 건드리지 않습니다. 하나의 프롬프트를 여러 에이전트에 뿌리고 결과를 비교해 승자를 머지하는 워크플로우가 자연스럽습니다.
• 리뷰 루프가 강력: AI가 만든 diff에 라인 코멘트를 달아 배치로 에이전트에게 돌려보내는 기능, PR/CI 상태 확인, 충돌 해결까지 앱 안에서 처리됩니다.
• GitHub / Linear 네이티브 연동: 이슈나 태스크 보드에서 바로 워크트리를 열 수 있습니다. 태스크 관리 툴과 에이전트 실행이 이어집니다.
• Design Mode: 내장 브라우저에서 UI 요소를 클릭하면 HTML, CSS, 크롭된 스크린샷이 프롬프트로 들어갑니다. 프론트엔드 작업에서 특히 편합니다.
• 모바일 컴패니언 앱: iOS/Android 앱으로 에이전트 상태 확인, 완료 알림, 후속 지시 전송이 가능합니다. 공식 앱으로 제공됩니다.
• 계정 스위처 + 사용량 추적: Claude/Codex 사용량과 rate limit 리셋 시간을 보여주고, Codex 계정을 재로그인 없이 바꿀 수 있습니다.
• 진입 장벽이 낮음: GUI라서 tmux 단축키를 몰라도 됩니다. VS Code 스타일 에디터가 들어 있어 코드도 바로 볼 수 있습니다.

단점

• 앱이 곧 런타임: 앱을 끄면 로컬 작업 환경도 내려갑니다. "노트북 덮고 나갔다가 다른 기기에서 이어서"는 원격 서버 구성이 있어야 가능합니다.
• 무거움: 터미널, 에디터, Chromium 브라우저를 다 품은 데스크톱 앱이라 가벼운 편은 아닙니다. 리소스에 민감한 환경에서는 부담이 됩니다.
• 내 터미널을 대체함: 기존에 쓰던 터미널 앱, 테마, 설정을 그대로 못 씁니다. Orca 안의 터미널을 써야 합니다.
• 기능이 많은 만큼 복잡함: "매일 배포"를 내세우는 만큼 UI와 기능이 빠르게 바뀝니다. 안정적인 워크플로우를 원하는 사람에게는 피로할 수 있습니다.
• 익명 텔레메트리 기본 활성화: 옵트아웃은 가능하지만 기본은 수집입니다.

4. Herdr 장단점

장점

• 에이전트가 죽지 않음: 서버-클라이언트 구조라 UI를 닫아도, SSH가 끊겨도 에이전트는 계속 작업합니다. 이게 Herdr의 존재 이유입니다.
• 기존 터미널 그대로: Ghostty든 iTerm이든 WezTerm이든 지금 쓰는 터미널 안에서 돌아갑니다. 설치해도 환경이 바뀌는 게 없습니다.
• 에이전트 상태를 이해함: idle / working / blocked / done을 자동 감지합니다. Claude Code, Codex, Antigravity CLI 등 21종을 기본 지원하고, 어떤 에이전트가 승인을 기다리는지 사이드바에서 바로 보입니다.
• CLI + 소켓 API: read / send / wait / split / attach 같은 명령으로 스크립트나 다른 에이전트가 에이전트를 제어할 수 있습니다. 폴링이 아니라 "이 에이전트가 끝날 때까지 기다려"가 됩니다.
• 멀티 머신: herdr machine add로 SSH 머신을 등록하면 로컬 에이전트와 원격 에이전트가 한 사이드바에 나란히 뜹니다. 클라이언트를 바꿀 필요 없이 기기를 넘나듭니다.
• 가벼움: Rust 단일 바이너리. 램 적은 서버에 깔아도 부담 없습니다.
• 플러그인 생태계: GitHub에 herdr-plugin 토픽만 달면 마켓플레이스에 자동 등록되는 구조라 커뮤니티 플러그인이 빠르게 늘고 있습니다. 파일 뷰어, 코드 리뷰 사이드바, 워크트리 관리(worktrunk), Telegram 알림, 모바일 릴레이 등이 이미 있습니다.
• 마우스 우선 TUI: tmux 경험이 없어도 클릭, 드래그, 우클릭 메뉴로 시작할 수 있습니다. tmux 사용자라면 ctrl+b prefix 그대로입니다.

단점

• 워크트리 관리는 코어가 아님: 공식 비교표에서도 "worktree/diff 리뷰 흐름은 다른 툴과 pair한다"고 명시합니다. 플러그인으로 보완은 되지만 Orca처럼 태스크 = 워크트리가 자동으로 되지는 않습니다.
• diff 리뷰, 브라우저, 에디터 없음: 코어는 터미널과 에이전트 상태에 집중합니다. 코드 리뷰는 별도 툴이나 커뮤니티 플러그인에 의존해야 합니다.
• GitHub / Linear 같은 태스크 연동 없음: 이슈에서 바로 작업 환경을 여는 흐름은 직접 스크립트로 만들어야 합니다.
• 모바일은 커뮤니티 플러그인: 공식 모바일 앱은 없고, collie나 herdr-mobile-relay 같은 커뮤니티 프로젝트를 써야 합니다. (Herdr Cloud가 "coming soon" 상태입니다.)
• 상태 감지가 100%는 아님: 에이전트 화면을 읽어 상태를 판단하는 방식이라 새로운 프롬프트 UI가 나오면 blocked를 idle로 잘못 볼 수 있습니다. (lifecycle hook 통합이 있는 에이전트는 더 정확합니다.)
• 플러그인 샌드박스 없음: 플러그인은 내 계정 권한으로 그대로 실행됩니다. 마켓플레이스도 리뷰되지 않으므로 설치 전 매니페스트를 직접 봐야 합니다.

5. 오케스트레이션 관점: 어떤 상황에 어떤 툴인가

"멀티 에이전트 오케스트레이션"이라는 말은 같은데, 두 툴이 상정하는 오케스트레이터가 다릅니다.

관점	Orca	Herdr
오케스트레이터는 누구?	사람. 사람이 태스크를 나누고, 워크트리를 열고, diff를 리뷰하고, 머지를 결정	사람 또는 에이전트/스크립트. CLI/소켓 API로 에이전트가 다른 에이전트를 read/send/wait 가능
격리 단위	Git worktree (자동)	터미널 pane / workspace (worktree는 플러그인이나 수동)
병렬 패턴	같은 프롬프트를 N개 에이전트에 뿌리고 결과 비교 후 승자 머지 (경쟁형)	역할을 나눈 에이전트들이 상태 기반으로 이어달리기 (파이프라인형)
완료 감지	알림 + unread 상태, 모바일 푸시	agent state (done/blocked) + wait 명령으로 블로킹 대기
리뷰 루프	내장 (diff 코멘트 → 에이전트로 회신)	없음 (플러그인 또는 다른 에이전트가 리뷰)
장기 실행	앱이 살아있는 동안 (원격 serve 별도)	클라이언트와 무관하게 서버가 유지

Orca가 맞는 상황

• 한 레포에서 여러 기능을 동시에 개발할 때. 워크트리 격리가 자동이라 충돌 걱정이 없습니다.
• "이 기능 구현해봐"를 Claude Code, Codex, Gemini에 동시에 던지고 결과를 비교하고 싶을 때. 가장 잘 나온 걸 머지하면 됩니다.
• 리뷰가 병목일 때. 에이전트가 짜는 속도보다 내가 읽는 속도가 느리다면, diff에 코멘트 달아 돌려보내는 루프가 있는 Orca가 편합니다.
• 프론트엔드 작업. Design Mode로 브라우저에서 요소 찍어서 프롬프트에 넣는 게 말로 설명하는 것보다 빠릅니다.
• GitHub 이슈 / Linear 태스크 기반으로 일하는 팀. 태스크 → 워크트리 → PR 흐름이 앱 안에서 끝납니다.
• 터미널 멀티플렉서에 익숙하지 않고 GUI가 편한 경우.

Herdr가 맞는 상황

• 에이전트를 몇 시간씩 돌려놓고 자리를 비우는 작업. 노트북 덮고, 다음 날 서버에서 SSH로 붙어도 그대로입니다.
• 여러 머신에 에이전트가 흩어져 있을 때. 집 데스크톱, 회사 노트북, 클라우드 VPS를 한 사이드바에서 봅니다.
• 에이전트가 에이전트를 오케스트레이션하게 만들고 싶을 때. 예를 들어 Claude Code를 "매니저"로 두고 herdr agent send로 Codex에게 구현을 시키고 wait로 완료를 기다린 뒤 결과를 리뷰하게 하는 식의 파이프라인을 스크립트로 짤 수 있습니다.
• 기존 터미널 환경을 유지하고 싶을 때. Neovim, 터미널 테마, 셸 설정을 하나도 안 바꾸고 싶다면 Herdr입니다.
• 저사양 서버나 원격 박스에서 돌릴 때. 단일 바이너리라 설치도 실행도 가볍습니다.
• tmux를 이미 쓰고 있어서 "tmux + 에이전트 상태 인식"만 필요한 경우.

둘 다 쓰는 것도 가능

Herdr 쪽에서 공식적으로 "매니저 앱과 pair해도 된다"고 말하듯, 이 둘은 배타적이지 않습니다. 실제로는 Herdr를 런타임으로 두고 그 위에서 에이전트를 돌리며, 리뷰나 워크트리 관리가 필요한 순간에만 Orca를 여는 조합도 성립합니다. 다만 처음 시작한다면 하나를 골라 익숙해지는 게 낫습니다.

6. Claude Desktop, Antigravity 같은 단일 앱 대신 이런 툴을 쓰는 이유

"그냥 Claude Desktop 하나, Antigravity 하나 쓰면 되지 않나?"라는 질문이 나올 수 있습니다. 단일 앱이 충분한 경우도 분명 있습니다. 하지만 아래 상황이 하나라도 해당되면 Orca나 Herdr 같은 계층이 필요해집니다.

1. 벤더 락인: Claude Desktop은 Claude만, Antigravity는 Gemini 중심입니다. 모델마다 잘하는 게 다르고, 구독 한도도 따로 돕니다. Claude Max 한도가 찼을 때 Codex로 넘기거나, Gemini의 긴 컨텍스트가 필요한 작업만 Antigravity에 맡기는 식의 구독 여러 개를 동시에 활용하려면 벤더 중립적인 상위 툴이 필요합니다.
2. 한 세션 = 한 작업: 단일 앱은 기본적으로 한 번에 하나의 대화에 집중하도록 설계되어 있습니다. 기능 A를 짜는 동안 기능 B의 테스트를 다른 에이전트가 돌리게 하려면, 결국 터미널 여러 개를 직접 관리해야 하고 그게 바로 이 툴들이 해결하는 문제입니다.
3. 컨텍스트 오염: 한 세션에서 여러 작업을 섞으면 에이전트 컨텍스트가 지저분해지고 품질이 떨어집니다. 작업당 에이전트 하나, 워크트리 하나로 격리하는 게 결과물이 좋습니다.
4. 크로스 리뷰: Claude가 짠 코드를 Codex가 리뷰하고, Gemini가 테스트를 쓰는 식으로 서로 다른 모델이 서로를 검증하게 하면 한 모델의 맹점을 잡아낼 수 있습니다. 단일 앱에서는 구조적으로 불가능합니다.
5. 창을 닫으면 끝: 데스크톱 앱은 앱을 종료하면 작업이 멈추거나 상태가 날아갑니다. 몇 시간짜리 리팩터링을 시켜놓고 퇴근하려면 Herdr 같은 런타임이 필요합니다.
6. 원격과 모바일: 단일 앱은 그 기기에 묶입니다. 집 데스크톱에서 돌던 에이전트를 카페에서 확인하려면 Orca 모바일 앱이나 Herdr SSH attach 같은 경로가 있어야 합니다.
7. 에이전트 상태 가시성: 에이전트 다섯 개 중 어떤 게 승인을 기다리며 멈춰 있는지 알 수 없다면, 병렬화의 이점은 대부분 사라집니다. 상태 감지와 알림이 있어야 실제로 여러 개를 굴릴 수 있습니다.

반대로 단일 앱이 나은 경우도 분명합니다. 작업이 한 번에 하나뿐이고, 구독이 하나뿐이고, 작업 시간이 짧아서 앱을 계속 켜두는 데 문제가 없다면 굳이 계층을 하나 더 얹을 이유가 없습니다. Antigravity처럼 에디터 통합이 깊은 앱은 "코드를 보면서 대화하는" 경험에서는 오히려 더 매끄럽습니다.

7. 정리

이런 사람이면 Orca	이런 사람이면 Herdr
GUI가 편하다 워크트리 격리 + diff 리뷰가 핵심이다 GitHub / Linear 태스크 기반으로 일한다 프론트엔드 작업이 많다 공식 모바일 앱이 필요하다 사람이 오케스트레이터다	터미널을 떠나기 싫다 에이전트를 오래 돌려놓고 자리를 비운다 여러 머신에서 에이전트를 돌린다 스크립트나 에이전트로 에이전트를 제어하고 싶다 가벼운 단일 바이너리를 선호한다 tmux 사용자다

개인적으로는 Claude Code, Codex, Antigravity CLI를 병렬로 돌리는 워크플로우에서는 Herdr가 잘 맞았습니다. 기존 터미널을 그대로 쓰면서 에이전트 상태만 얹어주는 구조가 부담이 없고, 자리를 비워도 작업이 계속된다는 점이 가장 큽니다. 다만 리뷰 병목이 심해지는 프로젝트라면 Orca의 diff 코멘트 루프가 확실히 효율적이니, 본인의 병목이 "실행"인지 "리뷰"인지를 먼저 판단해보시길 권합니다.

참고 링크

• Orca: onorca.dev / github.com/stablyai/orca
• Herdr: herdr.dev / github.com/herdrdev/herdr / Herdr 공식 비교 페이지