이 글은 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 세션에서 실행하게 하고 있음
터미널은 본질적으로 파일 디스크립터일 뿐이라 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가 여전히 최선임
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는 대체가 불가능함
suckless 진영은 터미널을 설계할 때 tmux 같은 기능을 일부러 구현하지 않겠다는 정반대 접근을 택함
참고: st.suckless.org/goals
Kitty는 터미널 에뮬레이터의 미래를 이끌 수 있을 것 같아 성공하길 바람
하지만 나는 Kitty를 업무용으로 쓸 수 없고, tmux가 없으면 세션, 창배치, 상태, 복사 버퍼, 스크롤백 모두 날아가서 절대 포기 못함
적절한 대체제가 Windows에 나오기 전까진 옆에 Kitty를 쓰더라도 업무에선 tmux를 계속 쓸 계획임
그러나 결국 tmux와 기본 터미널 조합으로 돌아옴
어디서든 잘 동작하고, 툴을 조합하는 방식이 더 오래 살아남는다는 점에서 tmux가 여전히 최선임