View

출처: medium.com
결론부터 말하면 이번 Cmux 후기는 다소 쓰게 나올 수밖에 없다. 2주 동안 메인 터미널로 설치해 사용해 보았는데, Rectangle 앱과 단축키가 대놓고 충돌하고, 하루에 한두 번은 반드시 꺼지며, 창 분할(split pane)도 꼬이는 버그가 반복된다. HN 댓글을 보고 기대가 잔뜩 부풀었으나 현실은 아직 베타 냄새가 진하게 남아 있다. 다만 포텐셜은 분명히 보이기에, 지금 당장 도입할지 고민 중인 사용자를 위해 버그와 워크어라운드, 대안까지 정리했다.
Cmux는 무엇이고 왜 주목받는가
Cmux는 간단히 말하면 tmux + 모던 UI + AI 연동을 하나로 묶으려는 터미널 멀티플렉서다. 터미널 에뮬레이터 자체 역할도 하고, 세션/윈도우/페인 관리도 되는 올인원 지향 도구다. 맥 네이티브 감성을 살리면서 tmux 수준의 세션 복원도 지원하고, AI 에이전트 연동까지 얹어놓았다는 것이 포지셔닝이다.
관심을 받는 이유 간단 정리
.tmux.conf를 한 번이라도 깎아본 사람이라면 공감할 텐데, 설정 지옥에서 벗어나고 싶은 수요가 기본적으로 존재한다. 여기에 Warp가 좋긴 하지만 계정 로그인 강제와 구독 모델 때문에 거리를 두는 사용자가 생겨났고, Ghostty와 Zed 같은 네이티브·빠름·예쁨 트렌드에 묻어가는 측면도 있다. 결정타는 터미널 안에서 바로 프롬프트를 쏘는 AI 워크플로우다.
깃허브 스타도 빠르게 쌓이고, Hacker News에서도 코멘트 수백 개가 달린 스레드가 몇 차례 있었다. 그래서 "이것이 tmux 킬러인가?"라는 기대감이 있었는데, 실사용 Cmux 후기로 들어가면 이야기가 달라진다.
내가 써본 계기 - 도입 동기
솔직히 나 역시 tmux 피로감이 쌓여 갈아탄 경우다. 맥을 교체할 때마다 .tmux.conf를 복붙하고, 플러그인 매니저(TPM)를 설치하고, 색 테마를 맞추고, 키바인딩을 손보게 된다. 한 번 할 때마다 두세 시간이 날아간다.
그 와중에 Warp도 써보고 Ghostty도 며칠 돌려보았는데, Warp는 AI 진입장벽이 낮은 대신 로그인/구독이 거슬렸고, Ghostty는 빠르긴 하나 멀티플렉싱이 아직 약하다. 그러던 중 Cmux가 "AI까지 다 된다"기에 설치하게 된 것이다.
설치는 brew 한 줄이면 된다.
brew install --cask cmux
5초 만에 설치되고 바로 실행된다. 여기까지는 좋았다. 다만 문제는 이다음부터 시작된다.
Rectangle 앱과 단축키가 전부 겹친다

출처: the.hailey-life.com
처음 부딪힌 문제다. Rectangle을 사용하는 맥 유저라면 거의 모두 공감할 것이다. macOS 기본 창 관리가 부실하다며 Rectangle을 설치하지 않은 개발자가 어디 있겠는가. 그런데 Cmux 기본 단축키가 Rectangle 기본값과 대놓고 겹친다.
구체적으로 어떤 단축키가 겹치는가
내가 겪은 충돌 케이스를 정리한 Cmux 후기 표다.
| 단축키 | Rectangle 기능 | Cmux 기능 | 결과 |
| `Ctrl + Opt + ←` | 왼쪽 반 정렬 | 이전 페인 이동 | Rectangle 먹힘, Cmux 무시 |
| `Ctrl + Opt + →` | 오른쪽 반 정렬 | 다음 페인 이동 | Rectangle 먹힘, Cmux 무시 |
| `Ctrl + Opt + ↑` | 위쪽 반 정렬 | 위 페인 포커스 | Rectangle 먹힘 |
| `Ctrl + Opt + Enter` | 최대화 | 새 페인 | Rectangle 먹힘 |
| `Ctrl + Opt + D` | 1/3 분할 | 페인 디태치 | Rectangle 먹힘 |
결과적으로 Cmux 내부의 페인 이동 단축키가 전부 Rectangle에 가로채인다. 시스템 단축키가 앱 단축키보다 우선순위가 높기 때문이다.
왜 이것이 생산성을 박살 내는가
터미널 멀티플렉서를 쓰는 이유의 80%가 페인/윈도우를 빠르게 오가는 것이다. 그러기 위해 tmux도 쓰고 Cmux도 쓰는 것이다. 그런데 이동 단축키가 전부 막히면 결국 마우스로 클릭해야 한다. 이렇게 되면 터미널 멀티플렉서를 쓰는 의미가 없다. iTerm2 창을 여러 개 띄우는 것과 차이가 없어진다.
임시 우회법 - 단축키 재매핑
해결책이 몇 가지 있지만 전부 불완전하다. 내가 실제로 시도한 순서는 다음과 같다. 먼저 Rectangle 환경설정에 들어가 문제의 단축키를 Ctrl + Cmd + ← 조합으로 변경해 보았다. 일단 충돌은 사라졌으나 Rectangle이 손에 익은 터라 재학습 비용이 꽤 컸다.
그래서 반대로 Cmux 쪽을 tmux 스타일 프리픽스(예: Ctrl + B를 먼저 누르고 방향키)로 바꿔보았다. Cmux 설정 파일에서 바인딩 수정 자체는 가능하지만, 문서가 아직 부실하여 시행착오가 좀 있었다. 결과적으로는 이 방향이 내 손에 가장 잘 맞았다. 한 단계 더 나아가고 싶다면 Karabiner-Elements로 Cmux 포커스 시에만 Rectangle 단축키를 무시하도록 분리하는 방법도 있는데, 설정이 복잡하여 여기까지는 가지 않았다.
어쨌든 "Cmux Rectangle 충돌"은 Cmux 쪽이 기본 단축키를 잘못 고른 탓이다. 맥 파워유저가 Rectangle 기본 단축키를 사용한다는 사실을 뻔히 알면서도 이를 기본값으로 잡은 것은 리서치 부족으로 보인다.
자주 꺼지는 크래시 버그

단축키는 설정으로 어떻게든 돌릴 수 있다고 치자. 다만 진짜 답이 없던 것은 크래시 이슈다. 이번 Cmux 후기에서 가장 크게 감점한 포인트다.
어떤 상황에서 꺼지는가
2주 동안 크래시가 발생한 시나리오를 모아 보면 대략적인 패턴이 보인다. docker logs -f처럼 대량 출력을 스트리밍할 때 10~20% 확률로 꺼진다. 페인을 6개 이상 띄워놓고 작업하다 보면 무작위 타이밍에도 터진다. JSON 덩어리 수천 줄을 한 번에 붙여 넣을 때, 그리고 nvim으로 10MB가 넘는 로그 파일을 열 때도 불안정했다.
재현율이 100%는 아니고 대략 하루 1~3회 정도 터진다. 중요한 작업 중에 꺼지면 페인 레이아웃이 전부 날아가는 것이 치명적이다. tmux는 세션이 서버 프로세스에 붙어 있어 클라이언트가 죽어도 재접속하면 그대로 복구된다. 반면 Cmux는 앱 자체가 터지면 레이아웃이 초기화된다.
로그 확인 방법
꺼졌을 때 원인을 파악하려면 Console.app을 열고 "cmux" 필터를 걸면 스택 트레이스가 나타난다. 대부분 메모리 관련 에러(EXC_BAD_ACCESS)나 렌더링 쓰레드 데드락으로 보이는 메시지가 찍힌다. 프로세스가 GPU 버퍼 관리를 다소 거칠게 하는 느낌이다.
릴리즈 노트에도 언급이 있는가
공식 깃허브 릴리즈 노트를 확인해 보았는데, 최근 몇 개 릴리즈에 "stability improvements"는 있지만 Rectangle 충돌이나 재현 가능한 크래시 케이스는 명시적으로 잡혀 있지 않다. 이슈 트래커에 비슷한 리포트가 몇 건 올라와 있고 confirmed 라벨까지 붙은 것도 확인했으나, 아직 픽스는 되지 않은 상태다. 개발자 입장에서는 우선순위를 새 기능에 더 두고 있는 분위기다.
창 분할(Split Pane) 이상 동작

출처: codelucky.com
세 번째 이슈다. 창 분할이 tmux처럼 깔끔하지가 않다.
증상 정리
가장 자주 보이는 것은 비율 문제다. 수평 분할 후 수직 분할을 하면 1:1로 쪼갠 줄 알았는데 3:7과 같은 식으로 찌그러져 있다. 페인을 닫았을 때 포커스가 방금 작업하던 페인이 아니라 엉뚱한 창으로 튀는 경우도 꽤 있었다. 탭을 여러 개 띄운 상태에서 페인을 분할하면 탭 순서가 뒤바뀌는 경우도 보았고, 드래그로 페인 경계를 조절할 때는 깜빡거리면서 일부 페인 렌더링이 1~2초 멈춘다. 버그가 하나였다면 그러려니 했을 텐데 네 가지가 번갈아 나오니 멀티플렉서 핵심 기능 자체가 미덥지 않게 느껴진다.
tmux와 비교하면 왜 어색한가
tmux는 수학적으로 깔끔하다. 페인 레이아웃이 2D 트리 구조로 관리되어 어떤 분할을 하더라도 예측 가능하게 움직인다. 리사이즈도 수치 기반이라 신뢰할 수 있다. Cmux는 트리 구조를 쓰긴 하지만 UI 렌더링과 상태가 가끔 어긋난다. 내부 상태는 3:7인데 화면은 5:5로 그려지는 식이다.
현재까지의 워크어라운드
페인을 4개 이하로만 사용하면 버그 빈도가 눈에 띄게 줄어든다. 리사이즈는 최소화하고 레이아웃을 고정해 사용했다. 탭 간 이동을 하면서 분할하면 꼬일 확률이 높기에, 탭을 먼저 만든 뒤 그 안에서만 분할하도록 습관을 바꾸었다. 이 정도 제약을 걸고 쓰면 좀 낫긴 하지만, 원래 멀티플렉서는 자유도를 챙기려고 쓰는 것인데 제약이 많아지면 메리트가 사라진다.
그럼에도 좋았던 점은 분명히 존재한다
계속 단점만 언급하면 불공평하다. 이번 Cmux 후기에서 칭찬할 부분도 짚고 넘어가야 한다.
UI/UX는 확실히 뛰어나다. 폰트 렌더링, 애니메이션, 탭바 디자인 모두 감각적이고 맥 네이티브 룩앤필을 제대로 살렸다. tmux를 그대로 쓰다가 Cmux를 켜면 "아, 이것이 2026년의 터미널이지"라는 인상을 받는다. 설정 진입장벽도 낮아서, tmux처럼 한 시간씩 .conf 파일을 깎을 필요 없이 GUI에서 웬만한 것은 전부 가능하다. 이 하나만으로도 입문자에게는 매력이 크다.
내장된 AI 에이전트 연동도 물건이다. 터미널 안에서 바로 "이 에러가 무슨 뜻인가?"라고 물으면 즉시 답해 주는 UX가 편리하다. Warp와 비슷한 방향이지만 구독 강제가 없다는 것이 장점이다. 아직 기능이 완전하지는 않다. 세션 복원은 크래시로 날아가는 경우를 제외하면 잘 돌아가는 편이다.
대안 비교 - 지금은 무엇을 쓰는 것이 나은가
Cmux가 지금 아니라면 무엇이 나은가. 실제로 함께 돌려본 도구들을 기준으로 정리한다.
tmux는 설정이 귀찮다는 것이 단점인데, 한 번 세팅이 끝나면 10년은 가는 안정성을 제공한다. 서버를 운영하는 사람들에게는 여전히 기본값이고, tmux resurrect 같은 플러그인을 붙이면 세션 복원도 된다. Cmux 크래시를 겪다가 tmux로 돌아오면 "아, tmux는 정말 왜 안 꺼졌는지"를 새삼 실감하게 된다.
Ghostty는 Mitchell Hashimoto가 만든 네이티브 터미널이다. GPU 가속이 제대로 작동하고 체감 속도가 확실히 빠르다. 다만 멀티플렉싱이 아직 약해 tmux와 함께 써야 한다. 나 역시 Cmux를 접고 돌아간 조합이 "Ghostty + tmux"였다. 현재 가장 합리적인 선택 중 하나라고 본다.
Warp는 AI 기능만 보면 압도적이다. 다만 계정 로그인 강제, 일부 기능 유료화, 텔레메트리 이슈로 거부감을 느끼는 사람이 많고, 기업 환경에서는 보안팀의 허락이 나오지 않을 수도 있다. iTerm2 + tmux 조합은 재미없는 대신 가장 검증된 선택지다. 업무용으로 쓰는 것이라면 이것이 최선일 수도 있다.
지금 Cmux를 쓸 것인가 - 3~6개월 더 기다리기를 권한다
이번 Cmux 후기를 정리하면 다음과 같다.
지금 당장 메인으로 쓰는 것은 비추천이다. Rectangle 기본 단축키와 충돌하는 점이 맥 파워유저에게는 바로 걸리고, 하루 1~3회 꺼지는 크래시는 중요한 작업 중에 레이아웃을 날려 버린다. 여기에 창 분할 버그까지 겹치면 멀티플렉서 핵심 기능이 불안정하다는 결론이 나온다.
다만 가능성은 분명히 있다. UI/UX와 AI 통합 방향성은 확실히 맞고, 설정 진입장벽이 tmux보다 훨씬 낮다는 것도 강점이다. 3~6개월 정도 지나 안정화 패치가 몇 번 더 들어간 뒤 다시 써볼 가치는 충분하다.
지금 당장 써야 한다면 Rectangle 단축키 재매핑을 먼저 하고, 페인은 4개 이하로 제한하며, 중요한 작업은 iTerm2+tmux 병행으로 타협해야 한다. 나는 이 글을 쓰면서 결국 tmux로 돌아갔고, 6개월 뒤 다시 점검해 보려고 캘린더에 알림을 걸어 두었다.
자주 묻는 것들
Cmux는 윈도우에서도 되는가
현재는 macOS 전용이다. Linux/Windows 지원은 로드맵에는 있지만 ETA 공지가 없다. 당분간은 맥 유저만 쓸 수 있다.
Rectangle 말고 BetterTouchTool이나 Magnet을 쓰면 충돌이 없는가
BetterTouchTool은 설정을 세밀하게 할 수 있어 앱별로 단축키 분리가 가능하다. 그래서 Cmux 충돌을 피하기에 가장 편하다. Magnet은 Rectangle과 기본 단축키가 거의 동일하여 똑같이 충돌한다.
Cmux vs tmux, 결국 무엇이 나은가
2026년 4월 기준으로는 tmux가 낫다. 안정성 차이가 너무 크다. Cmux는 가능성은 있지만 아직 신뢰하기 어렵다. 안정화된 뒤 다시 평가해야 할 듯하다.
'소프트웨어' 카테고리의 다른 글
| 좋은 코드 만들기::코드 품질 높이기 (1) | 2023.12.04 |
|---|