cmux와 Orca 비교: 터미널을 늘릴 것인가, 시도를 늘릴 것인가

두 앱의 소개 문구는 거의 같습니다. 코딩 에이전트를 여러 개 동시에 돌린다는 것입니다. 그런데 cmux는 Swift와 AppKit으로 짠 macOS 전용 앱이고, Orca는 Electron으로 짜서 Windows와 Linux, 심지어 휴대폰까지 갑니다. 라이선스도 GPL-3.0과 MIT로 갈립니다.

같은 일을 하는 도구가 이렇게까지 다른 선택을 할 이유는 없습니다. 실제로 두 앱이 세는 "여러 개"가 서로 다른 것을 가리킵니다.

"에이전트 여러 개"가 두 앱에서 다른 뜻인 이유

둘을 놓고 고를 때 흔히 이렇게 이해합니다. 에이전트를 병렬로 돌리는 도구가 둘 있으니 생김새와 취향의 문제라는 것입니다. 그러면 왜 한쪽만 git 워크트리를 대표 기능으로 내세우는지가 설명되지 않습니다.

Orca가 첫 번째로 내세우는 기능은 병렬 워크트리이고, 설명은 이렇습니다.

Fan one prompt across five agents, each in isolated git worktrees

프롬프트 하나를 다섯 에이전트에 뿌리고, 각각을 격리된 워크트리에 앉힌 다음, 나온 결과를 비교해서 마음에 드는 것을 병합합니다. 여기서 "여러 개"는 같은 문제에 대한 시도의 개수입니다.

cmux 쪽 문서에는 워크트리를 만들어 주는 기능이 없습니다. 워크트리라는 단어가 나오는 곳은 워크스페이스 그룹 문서의 지나가는 한 줄뿐이고, 그나마 "예를 들어 워크트리 스크립트에 연결된"이라는 표현이라 사용자가 직접 만든 스크립트를 붙이는 이야기입니다. cmux에서 "여러 개"는 열려 있는 터미널 창의 개수입니다.

이 차이는 취향이 아니라 무엇을 1급 개체로 두느냐의 차이입니다.

cmux가 늘리는 것, 터미널 창

cmux는 터미널입니다. 정확히는 Ghostty의 렌더링 엔진인 libghostty를 그대로 품은 터미널이고, ~/.config/ghostty/config를 읽어서 테마와 폰트를 그대로 씁니다. Ghostty를 쓰던 사람이라면 설정을 옮길 것이 없습니다.

에이전트는 별도의 개념이 아니라 그냥 창에서 도는 프로세스입니다. 그 대신 창 쪽에 정보를 몰아 넣었습니다. 세로 탭 사이드바가 워크스페이스마다 git 브랜치, 연결된 PR의 번호와 상태, 작업 디렉터리, 열려 있는 포트, 마지막 알림 문구를 함께 보여 줍니다. 에이전트가 사람의 확인을 기다리면 해당 패널에 파란 링이 돌고 탭이 반짝입니다.

제가 이 설계에서 좋다고 보는 지점은 숨는 것이 없다는 점입니다. 에이전트가 백그라운드 작업으로 사라지지 않고 전부 눈에 보이는 창으로 남습니다. 대신 창이 늘어나는 만큼 사람이 관리해야 합니다. 브랜치를 나눠 쓰고 싶으면 워크트리를 직접 만들어 두고 그 자리에 창을 열어야 합니다.

Orca가 늘리는 것, 워크트리 위의 시도

Orca는 IDE 쪽에 가깝습니다. 40개가 넘는 CLI 에이전트를 붙일 수 있다고 밝히고 있고, 목록에는 Claude Code와 Codex부터 Cursor, Copilot, Cline, Goose까지 들어 있습니다. 터미널에서 도는 것이면 대체로 받는다는 뜻입니다.

기능 목록이 향하는 곳도 다릅니다. diff의 특정 줄에 주석을 달아 그 피드백을 에이전트에게 되돌려 보내고, 디자인 모드에서 화면 요소를 클릭하면 그 HTML과 CSS와 스크린샷이 프롬프트에 붙습니다. GitHub의 PR과 Linear의 이슈를 앱 안에서 봅니다. 휴대폰에서 알림을 받아 진행 중인 에이전트를 지켜보고 방향을 바꿀 수도 있습니다.

전부 "여러 개를 돌려 놓고 결과를 고른다"는 한 가지 흐름을 위한 장치입니다. 반대로 말하면, 에이전트 하나를 붙잡고 오래 대화하는 방식에는 이 장치들이 대부분 쓰이지 않습니다.

네이티브와 Electron이 실제로 갈리는 자리

설치된 앱을 열어 보면 구조가 그대로 드러납니다. Orca 번들 안에는 Electron Framework와 렌더러 헬퍼가 들어 있고, cmux 번들 안에는 Swift 리소스와 ghostty 실행 파일이 들어 있습니다.

여기서 판단이 자주 한쪽으로 쏠립니다. Electron이니까 무겁고 네이티브니까 가볍다는 것입니다. 저는 이 비교가 실제 선택에서는 별로 중요하지 않다고 봅니다. 진짜로 갈리는 것은 속도가 아니라 어디서 돌 수 있는가입니다.

	cmux	Orca
구현	Swift + AppKit, libghostty	Electron
실행 환경	macOS 14.0 이상	macOS, Windows, Linux
모바일	iOS 컴패니언 (TestFlight)	iOS, Android
원격	SSH 워크스페이스	SSH 워크트리, orca serve 헤드리스
라이선스	GPL-3.0-or-later	MIT

macOS만 쓰고 앞으로도 그럴 사람에게 크로스플랫폼은 값이 아닙니다. 반대로 리눅스 서버에서 헤드리스로 돌려 놓고 휴대폰으로 들여다보는 그림이 필요하면 cmux는 애초에 후보가 아닙니다. Electron이라는 이유로 먼저 거르면 이 차이를 못 보고 지나갑니다.

라이선스가 조직에서 문제가 되는 지점

cmux는 GPL-3.0-or-later이고, 저장소에 GPL을 지킬 수 없는 조직을 위한 상업 라이선스가 따로 있다고 적혀 있습니다. Orca는 MIT입니다.

혼자 터미널로 쓸 때는 이 차이가 드러나지 않습니다. 갈리는 것은 포크해서 고친 것을 사내에 배포하거나 제품에 넣으려 할 때입니다. 어느 쪽이 어떻게 걸리는지는 배포 방식에 따라 달라지고 저는 여기서 단정할 위치에 있지 않으니, 그런 계획이 있다면 라이선스 원문을 먼저 읽어 보시기를 권합니다. 도구를 고르고 나서 확인하면 늦습니다.

선택을 가르는 질문 하나

늘리고 싶은 것이 창인지 시도인지만 정하면 됩니다.

에이전트 하나에 붙어서 오래 대화하고, 그 옆에 로그와 개발 서버와 브라우저를 같이 띄워 두는 방식이면 cmux 쪽이 맞습니다. 터미널을 이미 그렇게 쓰고 있었다면 새로 배울 것이 거의 없다는 점도 이유가 됩니다.

같은 문제를 여러 에이전트에 한꺼번에 던져 놓고 나중에 결과를 골라 담는 방식이면 Orca 쪽입니다. 이 방식은 손이 남는 대신 토큰과 API 비용이 시도 수만큼 늘어난다는 것을 미리 계산에 넣어야 합니다.

둘 다 특정 에이전트에 묶여 있지 않으니 같이 깔아 두고 상황에 따라 쓰는 것도 이상한 선택은 아닙니다. 실제로 두 앱 모두 Claude Code와 Codex를 그냥 받습니다.

여기까지가 확인한 부분

이 글이 근거로 삼은 것은 두 저장소의 README, cmux의 시작하기 문서와 워크스페이스 그룹 문서, 그리고 배포된 앱 번들의 구성입니다. 기준 버전은 cmux 0.64.22, Orca 1.4.194입니다.

확인하지 않은 것도 분명히 해 두겠습니다. 오래 써 봤을 때의 안정성, 메모리 사용량, 다섯 갈래로 뿌린 결과가 실제로 고를 만한 품질로 나오는지는 이 글의 근거 안에 없습니다. 두 앱 모두 릴리스가 빠른 편이라 기능 표는 몇 달이면 낡습니다. 고르기 전에 각 저장소의 최신 README를 한 번 더 보시는 편이 낫습니다.