터미널 도구 비교 — iTerm2·ghostty·warp·tmux·cmux·herdr·orca 계층별 선택 가이드

이번 포스팅에서는 요즘 자주 언급되는 터미널 도구 일곱 개 — iTerm2, ghostty, warp, tmux, cmux, herdr, orca — 를 계층별로 분류하는 터미널 도구 비교 가이드를 정리하고자 한다. 이름을 한 줄에 늘어놓으면 다 비슷한 “터미널 뭔가”처럼 보이지만, 실제로는 세 개의 다른 층위에 속한다. 이 구분을 놓치면 “warp를 쓸까 orca를 쓸까?” 같은 애초에 성립하지 않는 고민에 빠진다. 각 도구가 어느 계층에 있고, 같은 계층 안에서 무엇이 다르며, 계층을 넘나들며 어떻게 조합하는지까지 정리한다.

터미널 도구 비교의 출발점 — 세 계층으로 나눠야 한다

터미널 도구 비교에서 가장 먼저 할 일은 계층을 구분하는 것이다. iTerm2·ghostty·warp는 터미널 창 자체를 그리는 “터미널 에뮬레이터(앱)”이고, tmux는 한 터미널 안에서 여러 세션을 쪼개는 “멀티플렉서”이며, cmux·herdr·orca는 AI 코딩 에이전트를 여러 개 병렬로 굴리는 “AI 에이전트 오케스트레이터”다. 층위가 다르니 서로 경쟁하지 않고, 오히려 겹쳐 쓴다.

계층을 기능으로 나누면 위와 같지만, 여기엔 중요한 단서가 하나 있다. 이 계층들이 항상 세로로 “쌓이는” 건 아니라는 점이다. 실행 방식이 두 갈래로 갈리기 때문이다. tmux와 herdr는 터미널 안에서 도는 프로그램이라 터미널 앱 위에 얹는다. 반면 cmux·orca는 자체 터미널을 내장한 독립 앱이라, 얹는 게 아니라 그 자체를 단독으로 실행한다(계층①을 대체·포함한다). 그래서 “ghostty 위에 orca를 얹는다”는 식의 조합은 성립하지 않는다 — orca는 자기 앱으로 뜨기 때문이다. 이 실행 방식 차이가 조합을 정하는 핵심이므로, 계층별로 뜯어보며 함께 짚는다.

계층① 터미널 앱 — iTerm2 vs ghostty vs warp

터미널 앱은 세 갈래 성격으로 갈린다. iTerm2는 15년 묵은 기능 깊이, ghostty는 네이티브·GPU 속도, warp는 AI 내장이다. 셋 다 탭·분할을 지원하는 완성형 앱이라, 어느 하나만 골라 기본 터미널로 삼으면 된다. 선택 기준을 표로 먼저 본다.

iTerm2는 macOS에서 오래 표준이었던 만큼 기능이 촘촘하다. split pane, hotkey window, triggers, Python 스크립팅에 더해, 원격 tmux 세션을 iTerm2의 네이티브 탭·분할로 바꿔 주는 tmux control mode가 있어 SSH 중심 작업에 특히 강하다. 오래 검증된 안정성과 방대한 설정이 강점이지만, 그만큼 무겁고 macOS 전용이다.

ghostty는 HashiCorp 창업자 Mitchell Hashimoto가 만든 터미널로, “터미널은 진짜 네이티브 앱이어야 한다”는 방향을 밀어붙였다. GPU(macOS에서는 Metal)로 렌더링해 iTerm2보다 눈에 띄게 빠르고, ProMotion 120Hz와 저전력 렌더링을 지원한다. 설정이 거의 필요 없는 “zero configuration” 철학이라 깔면 바로 쓸 수 있고, 탭·분할도 내장한다(ghostty 공식 문서 참고). 자세한 설치·커스터마이징은 Ghostty 실전 가이드에 정리해 두었다. 성능·벤치마크 근거는 2026 터미널 비교 자료에서 확인할 수 있다.

warp는 앞의 둘과 성격이 다르다. 유일하게 AI를 앱에 내장한 터미널로, 명령 제안·블록 단위 출력·에이전트 모드를 갖추고 macOS·Linux·Windows를 모두 지원한다. “에이전트와 함께 일하도록 설계된 터미널”을 표방하며 MCP 연동도 붙는다(warp 공식). 터미널 자체가 AI 워크플로의 허브가 되길 원한다면 warp가 답이다. 다만 이 AI는 warp 안에서만 도는 것이라, cmux·herdr·orca 같은 외부 에이전트 오케스트레이터와는 지향점이 다르다. 자세한 사용감은 Warp 터미널 리뷰에 담았다.

계층② 멀티플렉서 — tmux는 왜 여전히 필요한가

멀티플렉서는 터미널 앱과 다른 문제를 푼다. **tmux의 진짜 가치는 “세션 지속(persistence)”**이다. 앱의 분할은 창을 닫으면 사라지지만, tmux 세션은 SSH 연결이 끊기거나 터미널을 닫아도 서버 쪽에서 계속 살아 있다가 다시 붙을 수 있다. 원격 서버에서 오래 도는 작업을 관리할 때 이 지속성이 결정적이다.

tmux가 하는 일은 크게 셋이다. 한 터미널 창을 여러 페인·윈도우로 나누고(앱의 분할과 비슷), tmux attach로 언제든 떠났다 돌아올 수 있는 지속 세션을 만들며, 키 바인딩·스크립트로 레이아웃을 자동화한다. 터미널 앱이 GPU 렌더링을 담당한다면, tmux는 그 위에서 “세션을 어떻게 조직하고 유지하느냐”를 담당하는 셈이다.

여기서 흔한 질문이 나온다. “ghostty가 분할을 지원하는데 tmux가 왜 필요한가?” 답은 지속성과 원격이다. 앱의 분할은 로컬 창에 종속되지만, tmux는 원격 서버에서 세션을 살려 두고 여러 기기에서 같은 세션에 재접속하게 해 준다. 로컬 화면 분할만 필요하면 앱 기능으로 충분하고, 원격·장기 실행·재접속이 걸리면 그때 tmux를 얹는다. 최신 기능인 플로팅 페인 같은 건 tmux 3.7 가이드에서 다뤘다.

한 가지 짚어둘 것은, 계층③의 AI 오케스트레이터 중 일부는 내부적으로 tmux를 쓰거나 tmux를 대체하려 한다는 점이다. 즉 tmux는 “사람이 세션을 조직하는 도구”이고, cmux·herdr는 “AI 에이전트를 조직하는 도구”라 문제의 대상이 다르다. 다음 계층에서 그 차이를 본다.

계층③ AI 에이전트 오케스트레이터 — cmux vs herdr vs orca

이 계층은 최근에 생겨난 새 범주다. **문제의식은 하나 — “Claude Code 여러 개를 동시에 돌리면 관리가 안 된다”**는 것이다. 창을 이리저리 넘기다 보면 어느 에이전트가 일하는 중이고 어느 놈이 “이거 진행할까요?” 하고 멈춰 기다리는지 놓친다. cmux·herdr·orca는 바로 이 병렬 AI 에이전트 관리 문제를 푼다. 셋의 성격을 먼저 표로 본다.

cmux는 가장 단순한 접근이다. Claude Code 같은 에이전트를 한 터미널에서 여러 개 병렬로 띄우는 데 초점이 맞춰져 있어, 가볍게 시작하기 좋다. 한 가지 흥미로운 점은 cmux가 ghostty의 렌더링 엔진인 libghostty 위에 만들어졌다는 것이다(ghostty를 fork한 게 아니라 그 코어 엔진을 가져다 쓴다). 그래서 기존 ~/.config/ghostty/config의 폰트·테마·색상을 그대로 물려받아, ghostty를 쓰던 사람은 익숙한 화면 그대로 에이전트 관리 기능만 얹는 셈이다. 근거는 cmux 공식 저장소에서 확인할 수 있다. 세부 사용법은 cmux 가이드에 있다.

herdr는 “무리(herd)를 친다”는 이름 그대로, 여러 에이전트의 상태를 한눈에 추적하는 데 특화됐다. Rust로 만든 AI 에이전트 전용 터미널 워크스페이스 매니저로, 어느 에이전트가 작업 중이고 어느 것이 입력을 기다리는지 놓치지 않게 해 준다. Claude Code 셋에 Codex 하나를 동시에 돌리는 식의 작업에서 진가가 난다. 여기서 중요한 점은, herdr가 cmux·orca와 달리 독립 앱이 아니라는 것이다 — ghostty·iTerm2·WezTerm 같은 기존 터미널 안에서 실행되는 약 10MB Rust 바이너리(TUI)다. 그래서 tmux처럼 터미널 앱 위에 얹어 쓰며, 별도 터미널이 반드시 필요하다. tmux·cmux와의 구체적 차이는 Herdr 가이드에서 다뤘다.

orca는 가장 무겁고 통합적이다. 크로스플랫폼 오케스트레이션을 지향하는 네이티브 앱으로, 자동화 CLI와 리뷰 흐름까지 갖춰 여러 에이전트를 하나의 플랫폼에서 조율한다. cmux와의 직접 비교, 즉 “크로스플랫폼 통합이냐 macOS 네이티브 경량이냐”는 Orca vs cmux 비교에서 상세히 정리했다. 간단히 요약하면, 가볍게 병렬만 원하면 cmux, 에이전트 상태 추적이 중요하면 herdr, 통합 플랫폼과 자동화를 원하면 orca 쪽이다. 실행 방식 측면에서 orca는 자체 터미널을 내장한 독립 데스크톱 앱(Electron)이라는 점도 기억할 만하다. cmux가 ghostty 엔진(libghostty)을 실제로 쓰는 것과 달리, orca는 VS Code와 같은 xterm.js 기반 터미널에 WebGL 렌더링·무제한 분할 같은 “ghostty급” 기능을 자체 구현했다(엔진 자체는 ghostty가 아니다). 대신 첫 실행 때 ghostty 테마·폰트·커서를 가져올 수 있다(Orca 터미널 문서).

얹는 herdr vs 독립 앱 cmux·orca — 계층을 겸하는 도구들

먼저 실행 방식의 차이부터 분명히 하자. 계층③의 세 도구는 실행 방식이 두 갈래로 갈린다. herdr는 tmux처럼 기존 터미널 안에서 도는 프로그램(TUI)이라 ghostty 같은 터미널 앱을 먼저 띄우고 그 안에서 실행한다 — 별도 터미널이 필요하고 “터미널 위에 얹는” 방식이다. 반면 cmux·orca는 자체 터미널을 내장한 독립 앱이라 단독으로 실행하며, 그 자체가 계층①(터미널 앱)을 겸한다. 그래서 “터미널 위에 얹는다”는 표현은 herdr에는 맞지만 cmux·orca에는 맞지 않는다 — 이 둘은 얹는 대상이 아니라 그 자리를 대신하기 때문이다.

여기서 한 가지 예외를 짚어 둘 필요가 있다. 지금까지 세 계층을 깔끔하게 나눴지만, 계층을 겸하는 도구도 있다. 방금 본 cmux가 대표적이다. cmux는 계층③(에이전트 오케스트레이터)이면서 동시에 libghostty로 렌더링하는 계층①(터미널 앱)의 성격을 함께 가진다. warp도 비슷하게 계층①(터미널 앱)에 AI 기능을 품어 계층③의 일부 역할을 겸한다. 이런 통합형 도구는 “한 앱으로 여러 층을 해결”하는 쪽이라, 분류가 틀렸다기보다 계층의 경계에 걸쳐 있다고 보는 편이 정확하다.

이 사실은 조합을 정할 때 실질적인 차이를 만든다. cmux를 쓰기로 했다면 이미 ghostty 엔진이 그 안에 들어 있으니, 계층①에 ghostty를 따로 깔 필요가 없다. warp를 쓰기로 했다면 앱 자체가 AI를 품고 있으니 가벼운 작업에는 별도 오케스트레이터가 불필요할 수 있다. 즉 통합형 도구를 고르면 그만큼 겹치는 층을 덜어낼 수 있다는 점을, 아래 결정 플로우와 함께 기억해 두면 좋다.

그래서 뭘 골라야 하나 — 상황별 결정 플로우

계층을 이해했다면 선택은 의외로 단순하다. 각 계층에서 하나씩 고르되, 필요 없는 계층은 건너뛰면 된다. 아래 흐름을 따라가면 자기 상황에 맞는 조합이 나온다.

먼저 계층①(터미널 앱)은 모두에게 필요하다. macOS에서 속도와 기본값을 원하면 ghostty, 터미널 안에서 AI를 바로 쓰고 싶으면 warp, 오래된 워크플로·스크립팅·SSH 중심이면 iTerm2를 고른다. 셋 중 하나면 충분하고, 여기서 둘을 겹쳐 쓸 이유는 없다.

계층②(tmux)는 조건부다. 로컬에서 화면만 나누면 앱의 분할로 충분하니 tmux는 생략해도 된다. 반대로 원격 서버에서 장기 실행 작업을 관리하거나, 세션을 껐다 켰다 재접속해야 하면 tmux를 얹는다.

계층③(AI 오케스트레이터)은 AI 코딩 에이전트를 동시에 두 개 이상 굴릴 때만 필요하다. 하나만 쓰면 그냥 터미널에서 직접 실행하면 된다. 여러 개를 병렬로 굴려야 한다면 먼저 실행 방식으로 갈린다 — 기존 터미널에 얹어 쓰고 싶으면 herdr, 자체 터미널을 갖춘 독립 앱이 편하면 cmux(경량)나 orca(통합)를 고른다. 독립 앱(cmux·orca)을 고르면 그게 곧 터미널이라 계층①을 따로 둘 필요가 없다. 에이전트를 안 쓰거나 하나만 쓰면 이 계층은 통째로 건너뛴다.

실전 조합 시나리오 — 나는 뭘 어떻게 겹쳐 쓸까

이론보다 구체적인 조합이 와닿을 것이다. 대표적인 개발자 유형별로 실제로 쓰기 좋은 스택을 정리했다. 핵심은 두 갈래다 — tmux·herdr는 터미널 앱 위에 얹고, cmux·orca는 그 자체가 터미널이라 단독으로 쓴다.

대표 조합 몇 개를 더 풀어 본다. 먼저 얹는 방식의 대표는 “ghostty + (tmux) + herdr”다. ghostty로 빠른 로컬 창을 띄우고, 원격 세션이 필요하면 tmux를 얹고, 그 안에서 herdr로 에이전트 여러 개의 상태를 추적한다. herdr는 터미널 안에서 도는 TUI라 이렇게 층층이 얹는 게 자연스럽다.

반대로 독립 앱 방식은 층을 쌓지 않는다. “cmux 단독”이나 “orca 단독”이 여기 해당한다. cmux·orca는 자체 터미널을 내장한 독립 앱이라, ghostty 같은 터미널 앱을 따로 깔 필요 없이 그 하나만 실행하면 된다. cmux는 ghostty 엔진을 품어 가볍고, orca는 크로스플랫폼 통합에 강하다. “터미널 + 에이전트 관리”가 한 앱에 들어 있는 셈이다.

가장 단순한 극단은 “warp 단독”이다. warp 하나로 터미널과 AI를 다 해결하고, 별도 멀티플렉서나 외부 오케스트레이터 없이 앱 내장 기능으로 버틴다. 결국 좋은 스택의 조건은 하나다 — 얹을 건 얹고(tmux·herdr), 단독으로 충분한 건 단독으로(cmux·orca·warp) 쓰되, 자기한테 필요 없는 층은 과감히 빼는 것이다.

FAQ

마치며

지금까지 터미널 도구 일곱 개를 세 계층으로 나눠 비교하고, 상황별 조합까지 정리해 보았다. 개인적으로 이 글을 쓰면서 가장 하고 싶었던 말은 “이것들은 경쟁 상대가 아니라 층이 다른 도구”라는 한 문장이었다. 나 역시 처음엔 ghostty를 깔고도 “그럼 tmux는 버려야 하나”, “orca랑 warp 중 뭐가 이기나” 하고 헷갈렸는데, 계층을 나눠 보고 나서야 “아, 그냥 각 층에서 하나씩 골라 쌓으면 되는구나” 하고 정리가 됐다. 지금 나는 ghostty 위에 필요할 때만 tmux를 얹고, AI 에이전트를 여럿 돌릴 때 herdr를 붙이는 식으로 쓴다. 정답은 없고, 자기 작업에서 어느 계층이 실제로 필요한지만 솔직히 따져 보면 스택은 자연스럽게 정해진다. 각 도구를 더 깊이 파고 싶다면 본문 곳곳에 링크한 개별 가이드를 이어서 보면 된다.