Orca vs cmux: AI 코딩 에이전트 병렬 실행, 뭘 골라야 하나

Claude Code 하나로 시작했다가 에이전트를 두세 개씩 동시에 굴리게 되면, 도구 선택이라는 문제가 따라온다. 지금 가장 많이 비교되는 두 후보가 Orca와 cmux다. 둘 다 여러 AI 코딩 에이전트를 병렬로 돌리는 걸 목표로 하지만, 접근 방식은 정반대에 가깝다. Orca는 Git worktree 격리와 diff 비교를 중심에 둔 크로스 플랫폼 오케스트레이션 앱이고, cmux는 알림과 사이드바를 터미널에 녹여 넣은 macOS 네이티브 앱이다. 이 글에서는 Orca vs cmux를 플랫폼, 병렬 실행 모델, 알림, 자동화, 결과 리뷰라는 다섯 축으로 나눠 비교하고, 어떤 상황에서 어느 쪽이 맞는지까지 실제 명령어와 표로 정리한다.

Orca vs cmux, 한 문장으로 뭐가 다른가

Orca는 여러 에이전트를 독립 Git worktree에서 돌리고 결과 diff를 cherry-pick으로 합치는 크로스 플랫폼 오케스트레이션 도구다. cmux는 대기 중인 에이전트를 알림 링으로 짚어주는 macOS 전용 네이티브 터미널이다. 한쪽은 여러 해법을 나란히 놓고 비교하는 데, 다른 쪽은 켜둔 세션을 하나도 놓치지 않는 데 무게가 실려 있다.

두 도구의 성격 차이는 만든 방식에서부터 드러난다. Orca는 stablyai/orca 오픈소스로 GitHub 17.9k 스타를 확보한 Electron 기반 앱이고, MIT 라이선스라 사내 재배포 제약이 적다. cmux는 manaflow-ai가 Swift/AppKit로 작성한 순수 네이티브 앱으로 GPL-3.0-or-later 라이선스이며, Ghostty의 렌더링 엔진 libghostty를 그대로 쓴다. 아래 표가 전체 그림이다.

설치와 지원 플랫폼은 어디서 갈리나

플랫폼이 곧 첫 번째 갈림길이다. Orca는 macOS·Windows·Linux 데스크톱과 iOS·Android 모바일 앱까지 지원하는 반면, cmux는 macOS에서만 돌아간다. Windows나 Linux를 쓴다면 이 지점에서 선택지가 사실상 Orca로 좁혀진다. 둘 다 Homebrew cask로 설치하는 건 같다.

# Orca 설치 (macOS)
brew install --cask stablyai/orca/orca

# cmux 설치 (macOS 전용)
brew tap manaflow-ai/cmux
brew install --cask cmux

# Orca 설치 (macOS)
brew install --cask stablyai/orca/orca

# cmux 설치 (macOS 전용)
brew tap manaflow-ai/cmux
brew install --cask cmux

Orca는 brew install --cask 한 줄이면 되고, Arch Linux는 AUR 패키지, Windows는 설치 실행 파일, Linux 서버는 orca serve 헤드리스 모드까지 열어둔다. cmux는 tap을 먼저 추가한 뒤 cask를 받는 두 줄이며, macOS 애플리케이션 번들만 배포한다. cmux를 GitHub 릴리스의 DMG로 받으면 Sparkle 기반 자동 업데이트가 붙는다는 점도 차이다. 크로스 플랫폼이 필요 없고 macOS만 쓴다면 이 차이는 체감되지 않지만, 팀에 Windows·Linux 사용자가 섞여 있다면 cmux는 후보에서 빠진다.

병렬 실행을 처리하는 방식이 근본적으로 다르다

가장 큰 차이는 여기 있다. Orca는 하나의 프롬프트를 여러 에이전트에 뿌리고 각 에이전트를 독립된 Git worktree에 격리해, 서로 코드를 덮어쓰지 않은 채 여러 해법을 만들게 한다. cmux는 워크스페이스 탭으로 세션을 나누되, 격리 자체는 사용자가 Git worktree와 조합해 직접 구성한다. Orca에선 이 격리가 기본으로 딸려 오고, cmux에선 필요할 때 붙이는 옵션에 가깝다.

이 설계 차이는 결과물을 다루는 방식으로 이어진다. Orca는 각 worktree가 만든 diff를 탭으로 나란히 놓고, 마음에 드는 조각만 cherry-pick으로 병합하는 흐름을 기본 워크플로로 삼는다. 같은 리팩터링을 세 가지 방식으로 동시에 시켜 비교하는 식이다. cmux는 한 워크스페이스 안에서 에이전트와 로그, 테스트 창을 패널로 나눠 보는 데 강하다. 한쪽은 여러 개의 답을 만들어 고르게 하고, 다른 쪽은 여러 개의 세션이 흩어지지 않게 잡아준다. 나눠 시켜 비교할 일이 잦은 사람에게는 Orca의 diff 흐름이 확실히 손에 붙고, 그냥 여러 개를 안전하게 굴리고 싶은 사람에게는 cmux가 편하다.

어느 에이전트가 날 기다리는지 — 알림은 누가 더 나은가

대기 중인 에이전트를 짚어주는 알림은 cmux가 더 앞서 있다. cmux는 에이전트가 입력을 요구하면 해당 패널 테두리에 파란 링을 띄우고 사이드바 탭을 밝힌다. Cmd+Shift+U로 읽지 않은 알림 패널로 바로 점프한다. Orca도 워크스페이스 카드에 상태를 표시하지만, cmux처럼 링으로 즉시 시선을 끄는 방식은 아니다.

cmux는 알림을 스크립트에서 직접 쏘는 통로도 세 가지 제공한다. CLI, OSC 777 이스케이프 시퀀스, 그리고 Kitty 프로토콜인 OSC 99다.

# cmux CLI로 알림 보내기
cmux notify --title "Claude Code" --body "서브태스크 완료"

# OSC 777 이스케이프 시퀀스로 어디서든 알림
printf '\e]777;notify;빌드 완료;테스트 통과\a'

# cmux CLI로 알림 보내기
cmux notify --title "Claude Code" --body "서브태스크 완료"

# OSC 777 이스케이프 시퀀스로 어디서든 알림
printf '\e]777;notify;빌드 완료;테스트 통과\a'

첫 줄은 cmux CLI로 제목과 본문을 지정해 알림을 띄우고, 둘째 줄은 셸 스크립트 어디서든 printf 한 줄로 알림을 발생시킨다. 빌드 스크립트나 CI 훅 끝에 넣어두면 완료 시점을 놓치지 않는다. AI 에이전트는 몇 분씩 조용하다가 불쑥 승인을 요청하는 리듬이라, 이 알림 하나가 “지금 어느 창을 봐야 하나”라는 감시 부담을 대신 덜어준다.

스크립트로 자동화하려면 어느 쪽이 유리한가

CLI로 워크플로 전체를 자동화하려면 Orca가 더 넓은 표면적을 제공한다. Orca는 worktree 생성부터 터미널 제어, 파일 diff, 브라우저 조작까지 서브커맨드로 노출하고, 대부분 --json 출력을 지원해 스크립트에서 파싱하기 쉽다. cmux도 CLI와 Unix 소켓 API를 갖췄지만, 자동화의 초점은 알림과 세션 복원 쪽에 더 가깝다.

# Orca: worktree 생성 후 에이전트가 끝날 때까지 이벤트 대기
orca worktree create --repo id:<repoId> --name my-task --issue 123 --json
orca terminal wait --for tui-idle --timeout-ms 30000 --json
orca file diff src/App.tsx --staged

# Orca: worktree 생성 후 에이전트가 끝날 때까지 이벤트 대기
orca worktree create --repo id:<repoId> --name my-task --issue 123 --json
orca terminal wait --for tui-idle --timeout-ms 30000 --json
orca file diff src/App.tsx --staged

orca terminal wait --for tui-idle는 에이전트 응답이 끝날 때까지 스크립트가 폴링 없이 기다리게 해주는 이벤트 기반 명령이다. orca file diff --staged는 커밋 전 변경분을 바로 확인하는 용도라, 여러 worktree의 diff를 순회하며 리뷰하는 스크립트를 짤 때 쓴다. 여기에 계정 여러 개를 등록해두면 레이트 리밋에 걸린 계정을 감지해 자동 전환하는 기능까지 붙어, 장시간 배치 작업의 중단을 줄인다. CI 파이프라인이나 무인 배치까지 염두에 둔다면 Orca의 CLI 깊이가 유리하다.

내장 브라우저와 원격 실행은 둘 다 되나

둘 다 된다. Orca와 cmux 모두 스크립트 가능한 내장 브라우저와 원격 실행(SSH)을 지원하므로, 이 두 기능만으로는 우열을 가리기 어렵다. 다만 브라우저를 다루는 진입점이 조금 다르다.

Orca는 Design Mode로 브라우저에서 클릭한 UI 요소의 HTML·CSS·스크린샷을 자동 수집해 에이전트 프롬프트에 첨부한다. 프런트엔드 버그를 고칠 때 셀렉터를 찾아 헤맬 필요 없이 요소를 클릭하면 그대로 넘어간다. cmux는 Cmd+Shift+L로 브라우저 패널을 분할해 열고, 에이전트가 접근성 트리를 스냅샷으로 떠서 클릭·폼 입력·JavaScript 평가까지 스스로 수행한다. 에이전트가 코드를 고친 뒤 화면을 열어 검증하는 닫힌 루프가 한 창에서 돈다. 원격 실행은 접근 방식 자체가 다르다. Orca는 원격 서버에도 orca serve로 헤드리스 Orca 프로세스를 미리 띄워둬야 하고, 로컬 데스크톱 UI는 그대로 유지하면서 실제 에이전트 실행만 원격 서버에서 처리하는 “The Remote Split” 구조를 쓴다. 노트북 배터리·메모리를 아끼면서 리소스가 넉넉한 서버에서 여러 worktree를 돌리고 싶을 때 맞는 방식이지만, 원격 서버 쪽 Orca 프로세스를 별도로 유지 관리해야 하는 부담이 따라온다. cmux는 cmux ssh user@remote-host 한 줄로 원격 워크스페이스를 만들고, 네트워크 라우팅을 호스트 머신을 통해 잡아준다. 별도 원격 프로세스 설치 없이 로컬과 원격 워크스페이스를 같은 사이드바에서 나란히 관리할 수 있다는 점이 더 가볍다. 다만 cmux는 원격 서버의 무거운 빌드를 대신 실행하는 용도에 가깝고, Orca의 SSH worktree처럼 “로컬 UI + 원격 실행”을 구조적으로 분리하는 개념은 아니다.

도구를 고르기 전에 — 병렬로 돌리는 게 항상 이득인가

둘 중 뭘 쓸지보다 먼저 짚어야 할 문제가 있다. 실제로 여러 사용자가 두 도구를 써보고 내놓은 공통된 관찰은 “어느 터미널이 더 쓰기 편한가”가 아니라, 에이전트를 병렬로 늘릴수록 결과물을 검토하고 정리하는 부담이 도구 자체보다 커진다는 점이다. Orca 쪽에서 이미 확인된 사실만 봐도, 같은 작업을 에이전트 세 개에 맡기면 토큰 소비량이 대략 세 배로 늘어난다. diff 세 개를 놓고 cherry-pick하는 경험 자체는 나쁘지 않지만, 그 판단을 매번 사람이 해야 한다는 점은 그대로다.

그래서 Orca와 cmux 중 하나를 고르기 전에, 지금 겪는 문제가 정말 “병렬 실행 도구가 없어서”인지부터 확인하는 게 순서다. 단일 에이전트로도 충분히 처리되는 작업을 굳이 세 갈래로 나눠 돌리면 비용만 늘고 리뷰 부담까지 떠안는다. 반대로 같은 요구사항에 대해 서로 다른 구현을 실제로 비교해보고 싶거나, 여러 세션을 동시에 굴리는 게 이미 일상이 된 상황이라면 그때부터 두 도구의 차이가 의미를 갖는다.

실제로 써보면 어디서 걸리나 — 알려진 한계

기능 비교만 보면 둘 다 흠 없어 보이지만, 실사용에서는 각자 분명한 약점이 있다. Orca는 Electron 기반이라 실행 시 메모리를 250~400MB 정도 점유하고, Linux는 아직 AppImage 형식만 배포돼 사내 패키지 매니저 파이프라인에 바로 얹기는 번거롭다. 데일리 릴리스 방식으로 버전이 자주 올라가다 보니 버그가 섞여 나올 때도 있는데, 대체로 24시간 안에 후속 패치가 나오는 편이다.

cmux의 약점은 더 근본적이다. macOS 전용이라는 플랫폼 제약은 우회할 방법이 없고, 아직 초기 단계 도구라 거친 부분(rough edges)이 남아 있다. 다만 네이티브 Swift/AppKit과 libghostty 기반이라, Orca가 짊어지는 Electron 메모리 부담 자체가 없다는 점은 반대로 cmux의 강점이기도 하다. 즉 Orca는 “무겁지만 크로스 플랫폼과 자동화 깊이를 얻는” 쪽이고, cmux는 “가볍지만 macOS에 갇히고 아직 다듬어지는 중인” 쪽이라고 보면 된다.

팀 단위로 도입한다면 뭘 더 봐야 하나

개인 사용과 팀 도입은 고려할 게 다르다. Orca는 계정 여러 개를 등록해두면 레이트 리밋에 걸린 계정을 실시간으로 감지해 다른 계정으로 자동 전환하는 기능이 있어서, 팀원 여러 명이 같은 시간대에 몰려 써도 요청이 끊기는 상황을 줄여준다. GitHub·Linear 통합도 앱 안에서 바로 제공돼 worktree 생성 시 이슈 번호를 연결해두면 PR 진행 상황을 창 전환 없이 볼 수 있다. 다만 diff 세 개를 비교해 cherry-pick하는 워크플로 자체가 리뷰어의 판단을 한 번 더 거치는 작업이라, 코드 리뷰 문화가 자리 잡지 않은 팀이라면 오히려 병목이 늘어날 수 있다.

cmux는 Founder’s Edition이라는 유료 옵션으로 우선 지원·클라우드 VM·iOS 앱 같은 팀 편의 기능을 따로 묶어 판다. 핵심 터미널 기능 자체는 무료로 전부 쓸 수 있지만, 팀 단위로 지원 SLA나 클라우드 실행이 필요하다면 이 옵션을 검토해야 한다. ~/.config/ghostty/config를 팀 저장소에 공유해두면 폰트·테마·키바인딩을 팀원 전체가 동일하게 맞출 수 있다는 점도 실무적으로 유용하다. 어느 쪽이든 처음부터 조직 전체에 배포하기보다는, 이미 여러 에이전트를 수동으로 병행하던 소규모 파일럿 팀에서 먼저 굴려보고 넓히는 방식이 안전하다.

그래서 언제 Orca, 언제 cmux인가

고르는 기준 자체는 복잡하지 않다. 크로스 플랫폼이 필요하거나 한 작업에서 여러 해법을 뽑아 비교하고 싶다면 Orca가 맞고, macOS에서 Claude Code를 중심에 두고 켜둔 세션만 놓치지 않으면 되는 상황이면 cmux로 충분하다. 아래 표에 상황별로 정리했다.

둘은 대체재가 아니라 겨냥하는 지점이 다른 도구다. 하나는 오케스트레이션과 비교, 다른 하나는 관제와 알림 쪽에 무게가 실려 있어서, 팀 구성이나 평소 작업 습관에 따라 답이 갈린다. 각 도구를 더 깊게 보고 싶다면 Orca 설치·실전 가이드와 cmux 사용법 가이드를 함께 참고하면 세부 기능까지 판단하기 쉽다.

자주 묻는 질문(FAQ)

마무리

Claude Code를 하나만 쓰던 시절엔 이런 비교 자체가 필요 없었다. 그런데 에이전트에게 맡길 일이 늘면서 자연스럽게 병렬 실행 도구를 찾게 됐고, Orca와 cmux를 며칠씩 번갈아 써봤다. 결론부터 말하면 나는 상황에 따라 둘을 나눠 쓰는 쪽으로 정리됐다. 여러 해법을 놓고 골라야 하는 리팩터링이나 마이그레이션 작업엔 Orca의 diff cherry-pick이 확실히 안심이 됐고, 평소 여러 Claude Code 세션을 켜두고 감시 부담만 덜고 싶을 땐 cmux의 알림 링이 더 손에 붙었다. 처음엔 하나로 통일하고 싶었지만, 두 도구가 겨냥하는 문제가 애초에 다르다 보니 억지로 하나만 고르는 게 오히려 손해였다. 크로스 플랫폼 팀이라면 고민 없이 Orca부터, macOS에서 Ghostty를 쓰고 있다면 cmux부터 시작해보길 권한다.