- tmux를 오랫동안 사용했으나, 최근에는 tmux의 복잡성과 한계(컬러 호환, 스크롤백, 마우스 복사, 프로토콜 미지원 등)에 회의감을 느낌
- 세션 지속성(detach/attach)이나 윈도우 분할/관리 등 tmux의 주요 기능이 꼭 tmux로만 가능한 것은 아님
- dtach, abduco, shpool 같은 Unix 철학의 경량 툴들을 활용하면, 세션 관리만 집중하면서도 네이티브 스크롤백, 단순성을 확보할 수 있음
- 특히
shpool+ ssh 조합을 통해 여러 원격 세션을 윈도우 매니저로 직접 관리하고, 네이티브 기능(알림, 스크롤, 타이틀 등)을 그대로 쓸 수 있는 환경 구축 가능 - 완벽하진 않지만, 본인 기준으로는 tmux를 완전히 대체할 수 있었고, 단순하고 유지보수가 쉬운 워크플로우로 만족감을 얻음
tmux의 장점과 단점
- 세션 유지(detach/attach), 윈도우 관리(탭, split) 등, 기존에 tmux가 제공하던 기능이 워크플로우 핵심이었음
- 하지만, 올바른
TERM설정이 없을 경우 색상 렌더링 문제, 터미널과 tmux 간의 상호작용 고려 필요 등 복잡도가 증가함 - 스크롤 버퍼 사용도 tmux만의 별도 방식에 익숙해져야 하며, 마우스를 이용한 영역 복사도 splits 환경에서 불편함이 있었음
- kitty graphics protocol 등 신규 터미널 기능 지원 미흡, 실험적 프로토콜 미지원 이슈도 존재함
- 중복된 escape code 재해석과 세션/윈도우 개념 부여로 인해 멀티플렉서가 터미널 생태계의 발전을 저해한다는 비판도 있음
tmux의 대체 방식 탐색
-
세션 지속성:
- 단순하게
ctrl-z+fg,nohup,disown등도 있지만 완전한 대체는 어려움 -
세션 유지만을 목표로 한 여러 툴(
dtach, abduco, shpool)이 등장- fork() 및 UNIX 소켓 조합으로 daemon과 클라이언트 간 연결
- tmux와 달리 가상 split 없이 네이티브 스크롤백 지원, 버퍼 복원 기능도 일부 제공
- 사용 경험상, 대체 툴 대부분은 버그 및
nvim내에서 detach 키합이 동작하지 않는 등 완성도가 낮음 - shpool만이 detach/attach 커맨드와 keymap 커스터마이징 측면에서 가장 완성도가 높았음
- 단순하게
-
윈도우 관리:
- 로컬에서는 윈도우 매니저로 분할·배치 관리
- 원격(SSH) 환경에서도 ssh_config와 shpool을 조합해, 여러 세션을 별도의 창에서 독립적으로 유지 가능
- autossh와 결합해 네트워크 재접속 환경에서도 세션 유지
새로운 워크플로우
- 개인적으로 ghostty(노트북), sway+foot(개인 PC)로 윈도우 관리. 서버는 프로머스(Proxmox) 기반 headless VM, 항상 SSH 개발 환경 유지
- 여러 shpool 세션을 ssh 단축키로 자동 연결, 로컬 윈도우 매니저에서 독립적 제어
-
ssh_config에서 각 호스트별로 shpool 세션 attach 자동화 - 터미널마다 IRC, dotfiles 관리, 별도 neovim 환경 등 다중 세션 개별 접속 가능
-
- 네이티브 스크롤, 알림, 터미널 타이틀 등 tmux가 불안정하게 지원하던 기능들이 오히려 더 자연스럽게 동작
- 단점도 있음: vim 재접속시 터미널 상태 복구 지연,
nvim사용 시 리사이즈 문제 존재- 멀티플레이어 미지원(여러 클라이언트에서 autossh 동시 발생 시 세션 충돌)
- 그러나 개인 기준에서는 tmux 완전 대체 성공
결론
- 완전히 동일하지는 않지만, tmux의 복잡성과 한계를 벗어나 단순하고 유연한 세션 관리 워크플로우로 전환 가능
- 각자 워크플로우에 따라 shpool 등 대안 툴을 고려해볼 만함
요즘은 AI로 tmux 같은 걸 찍어서 써요. Xterm.js + react + electron 으로 3-4시간이면 저런거 100개 도 찍어내고 필요하면 실시간 수정 해서 쓰고 샤브샤브 먹는 느낌? 먹고싶은거 넣으면 소스에 듬뿍
Hacker News 의견
-
이 글은 Linux-on-the-Desktop 사용자들을 위한 내용이지만, tmux는 MacBook에서 iTerm2와 함께 사용할 때 진정한 빛을 발함을 강조하고 싶음
iTerm2의 tmux 통합 기능 덕분에 내 워크플로우에서 tmux가 완전히 자연스럽게 녹아듦
~/.ssh/config에 아래처럼 설정해두면, 맥북을 다시 켜거나 네트워크를 바꿔도 언제든지 ssh tmux로 원격 개발 서버에 쉽게 접근 가능함
iTerm2와 tmux 통합 덕분에 원격 tmux 탭과 스크롤 버퍼가 마치 로컬 탭처럼 동작하며, 사실 tmux 명령어도 알 필요가 없이 쓸 수 있음-
나는 모든 개인용 장비에는 Linux를 쓰고, 일할 때 주로 MacBook을 쓰는데, tmux는 플랫폼 독립적으로 동일한 환경을 재현해 줘서 정말 유용함
Linux에서는 Alacritty를 쓰지만, macOS에서는 알맞은 설정이나 창/스크롤 관련 차이점 때문에 항상 뭔가가 바로 안 됨
이런 OS 차이에 시간을 쓰고 싶지 않으니, tmux와 iTerm2 조합으로 Linux와 거의 동일한 경험을 얻는 것이 좋음
세션 내 스크롤백이 완전히 별개로 제공되는 점도 나에겐 장점임
tmux에 대한 비판은 오히려 터미널 개발자에 가까운 이슈라고 생각함
지원이 부족하면 그저 더 좋은 지원을 해주는 터미널로 옮기면 됨 -
나는 mosh와 screen 조합을 사용 중임
서버가 재부팅되어도 세션을 복원할 수 있고, 네트워크를 바꿔도 세션이 끊기지 않음
참고: Immortal SSH Sessions -
tmux를 수십 번 시도해봤지만, 별로 마음에 들지 않아 항상 screen으로 돌아갔음
하지만 이번 팁을 보고 다시 한번 시도해보고 싶은 마음이 생김 -
나는 vim, tmux, iTerm2 조합에서 색상, 폰트 문제에 자주 부딪혀서 결국 로컬에서는 tmux를 포기하게 됨
업데이트에도 살아남고, 세션 유지 덕분에 얻는 이득이 크진 않았음
폰트 문제만 해결되면 다시 시도할 의향은 있지만, 지금은 시간이 부족함 -
Linux 터미널 중에 iTerm2처럼 tmux와 통합 기능을 제공하는 게 있는지 궁금함
아직도 GNU Screen을 사용 중이지만, tmux를 다시 한번 써볼 의향이 있음
-
-
이 블로그 글을 보며 왜 tmux를 쓰는지 다시 한 번 깨달음
사람들이 tmux와 비슷한 워크플로우를 구현하려고 엄청나게 많은 작업을 해야 하는 걸 보니, 그냥 tmux 쓰는 게 훨씬 나음
가끔 복붙이 살짝 불편하긴 해도 별로 신경 쓰지 않음
'멀티플렉서가 쓸데없는 오버헤드를 유발한다'는 비판은, 코드베이스 유지자가 아니라면 신경 쓸 필요가 없음-
복붙 문제는 tmux만의 문제가 아님
vim처럼 터미널 전체를 직접 그리는 앱은 모두 발생할 수 있음
OSC52라는 터미널 이스케이프 시퀀스로 이 문제를 쉽게 해결할 수 있음
아래 간단한 파이썬 스크립트를 쓴다면 grep 결과 등도 시스템 클립보드로 바로 보낼 수 있음
tmux와 nvim은 이미 OSC52를 지원하며, 다른 곳에서도 쉽게 써먹을 수 있음 -
참고로 내가 tmux에 PR을 제출한 적 있는데, 메인테이너 Nick Marriott가 소통이 정말 좋아서 마음에 들었음
코드도 잘 정돈되어 있고, tmux가 더 좋아졌음 -
뭔가 없는 문제를 억지로 만드는 듯한 논의에 질림
저자가 말하는 이유들이 납득이 안 되고, 오히려 그의 "7년 이상 tmux 사용 경력"도 의심스럽게 느껴짐
-
-
몇 주 전에 Tmux를 알게 되었고, 프로그래밍적으로 특정 패인에 키 입력을 보낼 수 있는 스크립트 가능성에 매료되었음
일본 포럼에서 영감을 얻어 Claude Code(이하 CC)가 상호작용이 필요한 CLI 스크립트와 직접 상호작용할 수 있을까 고민했고, Tmux를 이용해 이를 구현할 수 있음을 확인함
그래서 claude-code-tools라는 작은 도구를 만들어, CC 같은 CLI 에이전트가 Tmux 패인을 생성하고, 그 안에서 스크립트를 실행하며 실시간 상호작용까지 할 수 있게 되었음
일종의 Playwright나 Puppeteer의 터미널 버전 같음
claude-code-tools 깃허브 링크
이 방법으로 CC가 상호작용이 필요한 CLI 스크립트를 자동 테스트하거나, 다른 패인에서 UI를 띄우고 Puppeteer MCP로 브라우저에서 테스트, 디버거 활성화 후 브레이크포인트 잡기, 멀티 에이전트 연동 등 다양한 응용이 가능함
이런 확장성을 tmux 대안 툴들도 구현할 수 있을지 궁금함-
참고로 screen도 "stuff"라는 명령어로 패인에 프로그래밍적으로 키 입력을 보낼 수 있음
-
이 방식으로 Claude Code가 Gemini CLI, OpenCode 같은 다양한 CC 인스턴스를 interactive 모드에서 제어할 수 있음
전통적인 서브에이전트와는 다른 방식의 연동이 가능함 -
tmux-cli 래퍼가 실제로 결과 향상에 도움이 되는지 궁금함
나는 Claude에게 기존 tmux 명령어를 쓰라고만 하면 잘 동작해서, 따로 Bash를 쓰지 않고 모든 명령을 tmux 세션에서 실행하게 하고 있음 -
이런 걸 터미널 수준에서 더 쉽게 하고 싶다면, Kitty의 remote control 기능도 멋짐
Kitty Remote Control 소개 -
터미널은 본질적으로 파일 디스크립터일 뿐이라 script(1), expect(1), chat(8) 같은 유사한 툴이 80년대부터 있었음
꼭 tmux가 필요한 건 아님
-
-
tmux에서 TERM 설정을 제대로 하지 않으면 색상 등이 제대로 표현되지 않는다는 문제는 모든 터미널 에뮬레이터/프로그램에서도 동일하게 발생하는 문제임
Unix, Linux 시스템에서 TERM과 terminfo/termcap 개념 자체가 본질이라, 올바른 설정이 필수임
이것은 tmux 고유의 문제가 아님-
하지만 저자는 잘못을 tmux에 돌려서 아쉬움
스크롤 문제 역시 tmux 자체의 문제인지 의문스럽고, tmux는 alternate screen buffer를 사용하는데, 이는 뷰포트 기준선을 명확히 해서 커서 움직임을 쉽게 하려고 도입된 것임
현대 터미널 대부분은 alternate screen 상태에서도 로컬 스크롤을 허용해서 이 특성이 제대로 안 지켜짐 -
대부분의 프로그램도 기본 설정을 제대로 하지 않으면 의도대로 동작하지 않음
tmux의 경우엔 바로 '왜'가 드러나지 않아 불편하지만, 그 해결책이 뭔지는 불명확함(예: 기본값을 256colors로 할지?) -
맞는 말이지만, tmux를 쓸 때는 한 단계 더 신경 써야 할 레이어가 추가됨
tmux 안에서는 tmux 전용 TERM을 써야 하고, 바깥에서는 자기 터미널에 맞는 TERM을 써야 함
tmux FAQ만 봐도 display 문제의 대부분은 TERM 미설정에서 기인함
-
-
"멀티플렉서가 쓸데없는 오버헤드를 준다"는 지적은 오히려 내가 tmux를 선호하는 이유임
termcap 지원을 포기하는 앱이 늘어나는 현재 상황에서, tmux가 있으면 내 VT520 같은 옛날 터미널에서도 여전히 앱 실행이 가능함
어떤 터미널 개발자가 tmux를 싫어하든 별로 신경 안 씀
궁극적으로 유저 입장에서는 아키텍처적 우아함보다 잘 동작하는 게 중요함
참고로 개인적으로는 alacritty가 더 낫다고 생각함(하지만 주로 Konsole 사용 중임)-
VT520을 갖고 있다니 부럽다는 말을 전하고 싶음
오래전부터 VT525를 구하고 있었지만, 가격도 비싸고 해외 판매자들이 대부분임
genuine VT525에선 nosh realizer가 잘 동작하는지 늘 궁금했음
tmux가 없어져도, 미묘한 TERM 미호환 앱은 다른 방법으로 transliteration할 수 있음 -
내 VT420은 하드웨어 플로우 제어를 지원하지 않아 소프트웨어 플로우 제어를 써야 하는데, 이 방식은 요즘 터미널 앱과 호환이 영 좋지 않음
GNU Screen이 아주 훌륭한 해결책이 되고 있으며, 이 외에도 다양한 기능이 있음
tmux는 최신 에뮬레이터에서 많이 썼지만, 구형 단말에서는 이 중요한 플로우 제어 기능이 부족해 보임
termcap/terminfo 미지원 앱 처리를 위해 tmux가 유용하다는 점에 동의함 -
alacritty가 더 낫다고 생각하는 이유가 궁금함
오래된 하드웨어에서는 시작 속도도 느리고, 탭 기능 등 실용적인 기능도 부족하며 벤치마크마저 kitty/ghostty/konsole/foot보다 딸림
그럼에도 불구하고 뭔가 이유가 있어서 alacritty를 쓰는 사람들이 있다는 점이 흥미로움
-
-
아직도 tmux를 쓸 계획임
여러 프로젝트간 세션 관리 및 재부팅 후 세션 복구가 쉬워서 좋아함
mouse copy/paste는 tmux-yank로 전혀 문제없었음
몇 년째 같은 환경을 쓰고 있음
tmux의 send-keys 기능으로 dotfile을 리팩토링할 때 여러 패인/세션에 동시에 alias나 설정 파일을 쉽게 갱신하고 nvim도 재시작하는 자동화를 구현함
이 경험을 블로그와 영상에서 정리함 -
나는 "you might not need tmux"를 "you might not need browser tabs" 논의와 비슷하게 봄
터미널 세션이나 웹페이지가 한두 개라면 굳이 안 쓸 수도 있지만, 그 이상을 다루려면 창관리가 너무 불편해져서 결국 같은 기능을 반복 구현하게 됨-
요즘 나는 그냥 내가 사용하는 윈도우 매니저의 창 관리 기능을 최대한 활용하려고 함
브라우저 탭이나 터미널 탭, tmux 대신 윈도우 매니저에 창 배치와 탭 관리, 북마크 등을 맡기니 불편하지 않음 -
탭 관리는 애플리케이션이 아니라 윈도우 매니저가 맡는 것이 맞다는 신념에 가까워짐
내 윈도우 매니저는 창을 타일로 배열하거나, 겹쳐진 창을 탭으로 그룹화할 수 있음
이 탭들은 동일 앱이든 서로 다른 앱이든 무관하게 쓸 수 있음 -
브라우저 탭은 서로 다른 창으로 쉽게 분리하거나 합칠 수 있지만, tmux 탭은 이 점에서 유연성이 부족함
좋은 윈도우 매니저라면 탭과 창을 자유롭게 재조합할 수 있음 -
내 tmux 설정에는 클릭 가능한 탭이 있음
-
MS Windows의 다중 창 관리(Alt Tab, Win Tab 등)는 매우 훌륭함
각 터미널마다 아이콘/배경색을 다르게 해서 식별하고, 운영체제 자체가 창 관리에서 많은 부분을 대신 해줌
Mac도 써봤지만 이 부분에서 Windows만큼 만족스럽진 않음
-
-
버퍼 스크롤백 등 tmux에 대해 불평하는 점들이 오히려 나에게는 tmux를 쓰게 하는 동기임
두 번째 랩탑이 오래된 debian 터미널 전용이라 마우스가 안 돼서 오직 tmux로만 복사/붙여넣기가 가능한 상황임
나에게 tmux는 대체가 불가능함- tmux capture-pane - | vim - 조합이 마우스 스크롤 휠보다 더 편리할 때가 있음
-
suckless 진영은 터미널을 설계할 때 tmux 같은 기능을 일부러 구현하지 않겠다는 정반대 접근을 택함
참고: st.suckless.org/goals- suckless와 Kitty는 개발철학 면에서 정반대라고 할 수 있음
-
Kitty는 터미널 에뮬레이터의 미래를 이끌 수 있을 것 같아 성공하길 바람
하지만 나는 Kitty를 업무용으로 쓸 수 없고, tmux가 없으면 세션, 창배치, 상태, 복사 버퍼, 스크롤백 모두 날아가서 절대 포기 못함
적절한 대체제가 Windows에 나오기 전까진 옆에 Kitty를 쓰더라도 업무에선 tmux를 계속 쓸 계획임- Kitty도 잠시 써봤는데, tmux 설정과 비슷하게 환경을 재현할 수 있어 인상적이었음
그러나 결국 tmux와 기본 터미널 조합으로 돌아옴
어디서든 잘 동작하고, 툴을 조합하는 방식이 더 오래 살아남는다는 점에서 tmux가 여전히 최선임
- Kitty도 잠시 써봤는데, tmux 설정과 비슷하게 환경을 재현할 수 있어 인상적이었음