요약
Tmux로 Claude Code 여러 개를 돌리는 설정과, 에이전트가 늘 때 부딪히는 한계를 정리한 안내서입니다.
macOS용 Claude Code 터미널 crystl을 만드는 쪽이 자기 사이트에 올린 가이드입니다. Tmux가 AI 에이전트 작업에 잘 맞는 이유와 실제 설정을 소개합니다. 끝에서는 에이전트가 많아질 때의 한계를 들어 자사 제품을 대안으로 내세웁니다.
왜 중요한가
- 터미널을 닫거나 SSH가 끊겨도 살아남는 Tmux 세션은 오래 도는 에이전트를 맡기기에 알맞은 기반입니다.
- 하지만 Tmux는 에이전트를 알지 못해서, 승인을 기다리는지 일하는지 끝났는지를 구분해 주지 못합니다.
- 에이전트가 늘수록 직접 짠 감시 스크립트에 기대야 하고, 글은 이것을 전용 도구가 필요한 이유로 듭니다.
핵심 내용
- 프로젝트마다 저장소 이름을 딴 세션 하나를 두고, 작업마다 창을 하나씩 열라고 권합니다.
- 최신 Claude Code는
claude --worktree --tmux로 git 워크트리(저장소를 폴더별로 따로 꺼내 쓰는 기능)와 세션을 함께 만듭니다. send-keys(다른 창에 키 입력을 대신 보내는 명령)는-l로 글자 그대로 보내고, 0.3초 쉰 뒤 Enter를 보내야 입력이 빠지지 않는다고 합니다.capture-pane으로 각 창의 마지막 줄을 읽어 상태 표시줄에 대기·작업·유휴를 띄우는 스크립트도 실었지만, 화면 문구가 바뀌면 깨진다고 인정합니다.- 재부팅하면 세션이 사라지고, 세션끼리 작업 내용을 나누지 못하는 점도 한계로 꼽았습니다.
HN 반응
- Tmux는 10분만 익혀도 두고두고 득이 된다는 칭찬과 함께, 에이전트용으로는 herdr 같은 전용 도구로 옮겼다는 경험담이 잇따랐습니다.
- 반면 herdr가 가끔 세션 전체를 날린다며, 잃으면 안 되는 작업은 여전히 Tmux 안에서 돌린다는 이용자도 있었습니다.
tmux(나 GNU screen)를 잘 모른다면 꼭 익혀 두세요. 개발자든 시스템 관리자든 CLI를 주로 쓰는 사람이든 생산성이 몇 배는 뛰는 도구입니다. 세팅하고 기본 단축키를 익히는 데 10분이면 되는데, 그걸로 절약하는 시간은 몇 자릿수 단위로 큽니다. 제 생각에는 소프트웨어 공부 중에 가장 남는 투자 중 하나입니다.
덧붙이면 tmux만 그런 게 아닙니다. vim, emacs, bash, zsh도 마찬가지입니다. 처음 쓰는 사람이나 안 배운 사람과, 10분만 들여 기본기를 익힌 사람의 차이는 엄청납니다. 이게 고수(greybeard)의 경지로 가는 첫걸음입니다.
저는 zelij를 쓰다가, 그 전에는 tmux, 그보다 전에는 GNU screen을 썼습니다. 지금은 herdr와 에이전트 연동이 꽤 마음에 듭니다.
다 훌륭한 도구예요. 뭐가 더 낫냐는 용도와 환경에 따라 달라집니다.
저는 tmux에서 갈아탔습니다. 터미널 창과 pane, 분할을 관리하는 키 조합이 따로 있고, Emacs 안에서 파일 버퍼를 다루는 키 조합이 또 따로 있는 게 지겨워졌거든요. 지금은 Emacs 안에서 터미널 에뮬레이터를 돌려서 파일 창이든 터미널 창이든 같은 키로 다룹니다.
저도 tmux에서 갈아탔습니다. 터미널 창을 관리하는 키 조합이 하나, 나머지 모든 OS 창을 관리하는 키 조합이 또 하나라는 게 지겨워졌거든요. 터미널뿐 아니라 GUI 앱도 세션에 포함시키고 싶었고요.
그래서 몇 달에 걸쳐 Claude와 함께 대체품을 키워 냈습니다. 정말 만족스럽고 다시는 돌아가지 않을 겁니다.
아, 그렇군요. 저는 집에 있는 리눅스 데스크톱에서 Forge0를 쓰는데, 타일링이나 OS 창 관리용 단축키를 마음대로 바꿀 수 있습니다.
아쉽게도 회사에서는 여전히 macOS와 Windows를 써야 해서, OS 창 관리를 어디서나 통일하는 건 아직 해결되지 않은 문제입니다. 그래도 Emacs는 어디서든 돌릴 수 있고 그 안에서는 키 조합이 일정하니 그 정도로 만족하고 있습니다.
이 vim 플러그인과 비슷한 게 Emacs에도 있는지 궁금하네요. https://github.com/christoomey/vim-tmux-navigator 아니면 이제는 직접 바이브 코딩으로 만들 수도 있겠고요.
저는 몇 년째 이걸로 vim 창과 tmux pane 사이를 같은 키로 오가고 있습니다. vim 안에서 터미널을 돌리려고 애쓰는 것보다 훨씬 잘 맞았어요.
Emacs 안에서는 winum 모드를 쓰는데, 이제 위/아래/왼쪽/오른쪽으로 방향 이동하는 방식으로는 못 돌아가겠더라고요.
동의합니다.
2018년쯤 vim에 "입문"했던 기억이 나요. 헤드리스 머신에서 작업할 일이 많아지면서 제대로 된 텍스트 편집 환경이 필수가 됐거든요. tmux도 그러면서 알게 됐고 뭘 할 수 있는지도 배웠습니다.
어느 순간 VSCode의 원격 기능이 충분히 좋아져서 vim이 꼭 필요하지는 않게 됐지만(물론 필요할 때는 여전히 제일 먼저 찾습니다), tmux는 지금도 계속 씁니다. 그리고 tmux와 에이전트는 당연히 최고의 조합입니다. 원격 에이전트가 제 기존 tmux 세션과 상호작용할 수 있다는 건 2018년의 제가 꿈꾸던 워크플로 그대로예요.
어쨌든 하고 싶은 말은, vim이나 emacs 칭찬은 많이 들리지만 tmux만큼은 누구나 우선순위를 두고 배워야 한다는 겁니다. 적어도 tmux 안에서 길을 찾고 세션을 에이전트에게 넘길 수 있을 만큼은요.
저는 1월부터 8월까지 tmux에서 Claude Code를 썼습니다.
지금은 100% ChatGPT 데스크톱 앱입니다. 진짜 일은 안 하고 환경 설정을 만지작거리고 유지보수하는 데 시간을 너무 많이 쓰고 있다는 느낌이 들어서요.
돌이켜 보면 올해 초에는 대안이 없었으니 tmux가 맞는 선택이었던 것 같습니다. 기본 요소만으로 나만의 워크플로를 만드는 것도 흥미롭고 재미있었고 배운 것도 많지만, 배움은 정체기에 들어섰고 남은 건 대부분 잡일이었습니다.
원격 작업에는 tmux가 여전히 좋습니다. 서로 다른 하네스끼리 소통하게 할 때는 더 좋고요. 저는 보통 Codex, Claude Code, Pi를 한 팀으로 묶어 같은 작업을 시킵니다. 구글 쪽 기능이 필요하면 agy를 넣기도 하는데, 서로 소통하게 하기가 아주 쉽습니다. 말하자면 Claude Code의 새 프로젝트 기능을 가난한 사람 버전으로 발전시킨 셈이에요. 그런데 좋은 점은 cc 말고 다른 코딩 하네스에 특정 작업을 맡길 수 있다는 겁니다.
이 웹사이트는 15인치 레티나 화면에서 읽기가 너무 힘드네요.
본문이 화면의 20% 정도만 차지하고 나머지는 텅 비어 있습니다. 창 크기를 조절하면 나아지고요.
Firefox 리더 뷰가 바로 이런 문제를 위한 겁니다. 콘텐츠 너비 슬라이더를 조금 조절하면 아주 좋아요.
아이러니하게도 Firefox 창을 더 작게(너비 830픽셀쯤) 만들었더니 본문이 넓어져서 전체 너비를 다 채우네요.
창을 천 픽셀쯤보다 넓히면 본문 열이 400픽셀로 줄어들고요.
희한한 디자인 선택이에요.
참고로 저는 텍스트 열의 max-width를
64ch정도로 잡습니다. 뷰포트가 작을 때는 45ch까지 내려가기도 하고요. 읽기에는 50~65ch 범위가 이상적이라고 생각합니다. 20%나 20vw로 설정하면 딱 이런 문제가 생길 수 있어서 위험합니다.서버에 Claude Code를 설치하고 Claude Desktop에서 원격 제어로 조작하면 됩니다. 그러면 Claude Desktop, 모바일, 웹에서 여러 서버의 Claude Code를 바로 제어할 수 있고, 전부 앤트로픽 도구 안에서 해결됩니다.
다 됩니다. 서브에이전트를 네이티브 화면으로 볼 수 있고, 파일과 이미지도 올리고, 스레드도 포크할 수 있고요.
가장 큰 장점은 실제 작업이 서버에서 돌아가니까 노트북을 닫아도 계속 진행되고, 허벅지가 뜨거워지지도 않는다는 겁니다. 세션(써 보진 않았지만 이론상으로는 말이 되는 방식입니다)에 비해 좋은 점은 서버에서 Claude의 환경을 마음대로 구성할 수 있다는 점입니다. 필요한 도구, 다른 머신으로의 ssh 접근, sudo, 뭐든 줄 수 있어요.
단점은 하나, 새 프로젝트를 시작할 때마다 개발할 서버에서 설정 단계(systemd 서비스 추가)를 거쳐야 한다는 겁니다. Claude가 디렉터리당 서버 하나만 다룰 수 있어서요. 그래도 서버에 ssh 접근을 주면 이 단계는 Claude가 알아서 처리합니다.
머신들은 Claude Desktop, 모바일, 웹에 깔끔하게 표시되고 저장소와 프로젝트는 드롭다운에 들어 있습니다. 아주 많은 프로젝트를 동시에 하는 게 아니라면 이 구성은 최고예요.
저는 데스크톱에 Tailscale을 깔고 AI 세션을 tmux(또는 다른 HN 글에 나온 것처럼 붙였다 뗐다 할 수 있는 영속 세션이 있는 아무 도구)에서 돌립니다. 이제 폰이나 노트북에서 termux로 접속해 작업을 이어 갈 수 있어요. 놀고 있는 데스크톱이 있는 사람이 많지는 않겠지만, 저는 공급자를 자유롭게 고를 수 있고 실제 파일 시스템도 제 머신에 둘 수 있어서 좋습니다.
이게 유일한 단점이라고요? 내 서버를 Claude 인프라와 그쪽 보안에 노출시키는 겁니다. 시스템에 백도어를 열어 두는 거나 마찬가지예요.
보안 기준이 얼마나 뒷걸음질 쳤으면 이렇게 뻔한 걸 다들 못 보는 건지 도무지 이해가 안 갑니다.
프롬프트 인젝션이 아직 해결되지 않았다는 걸 다들 잊은 것 같아요.
Claude가 소프트웨어를 만드는 데만 쓰는 순수 개발 서버라면 괜찮은 건가요?
저도 비슷한 걸 생각 중인데요, 갖고 있는 작은 로버에 pizero2w를 달아서요. cc를 풀어 놓고 장애물 회피용 센서를 읽으면서 주행하는 소프트웨어를 짜게 하는 겁니다. "벽까지 가서, 돌아서, 다시 와" 하고 프롬프트를 줬을 때 알아서 해내는지 보면 재미있을 것 같아요.
저도 당분간은 Tmux와 Zellij가 마음에 들었는데, 에이전트 코딩에서는 Herdr가 기본 상태로도 훨씬 낫습니다. tmux/zellij로는 되는데 herdr로는 안 되는 건 아직 못 찾았어요.
제가 충분히 안 써 봐서일 수도 있는데, herdr는 저한테는 엉뚱한 문제를 푸는 도구였습니다. 저는 에이전트 세션을 잔뜩 관리하고 싶은 게 아니라 GTD처럼 작업을 출시까지 이끌고 싶거든요. 세션은 구현 세부 사항일 뿐이고, 뭔가 잘못됐을 때만 들어가 보고 싶습니다.
Herdr의 유일한 문제는 VC 투자를 받았다는 거예요. 어떤 식으로 배신할지는 모르겠지만 언젠가는 반드시 옵니다.
herdr의 유일한 문제는 툭하면 죽어서 세션 전체를 날려 버린다는 점입니다. 한때는 하루에 한두 번씩 죽었고 요즘은 2주에 한 번쯤인데, 그래도 죽긴 죽어요. 세션 자동 복구를 켜 두긴 했지만, 그래도 진행 중이던 작업은 끊기고 오래 도는 비에이전트 프로세스는 전부 손으로 다시 띄워야 합니다.
그래서 절대 잃고 싶지 않은 세션과 프로세스는 herdr 안에 중첩한 tmux에서 돌립니다. tmux는 절대 안 죽거든요.
반대 사례로, 저는 WSL/Windows에서 herdr를 쓰는데 한 번도 죽은 적 없습니다.
여기 다른 분들처럼 저도 터미널 멀티플렉서를 직접 만들었습니다. 모든 세션을 붙들고 있는 데몬이 있고, 바이너리를 끊김 없이 업그레이드해서 세션이 사라지지 않고, 모든 걸 기록해서 언제든 복구할 수 있습니다. 씬 클라이언트 모드가 있어서 노트북에는 데몬에 연결하는 네이티브 앱이 있고, wasm 기반 반응형 웹 UI에 받아쓰기까지 있어서 폰으로도 세션을 이어 갈 수 있어요. Claude/codex 세션은 uuid로 시작하기 때문에 마음대로 죽였다가 다시 이어 갈 수 있습니다(제 건 12시간 동안 활동이 없으면 자원을 확보하려고 자동으로 잠듭니다). CLI로 에이전트가 모든 걸 제어할 수 있어서, Claude의 channels를 하네스에 구애받지 않게 구현한 셈이에요. 친구 몇 명이 포크해서 매일 쓰고 있습니다. 세션을 정리하는 스페이스 구성은 herdr와 비슷합니다. 씬 클라이언트 모드에서 돌릴 때는 속도와 대역폭에 맞춰 최적화했습니다.
https://github.com/zackham/seance
컨텍스트 전환과 세션이 너무 많을 때 오는 인지적 피로를 피하려면 세션(그리고 tmux 윈도)을 최소로 유지해야 하는데, 이게 항상 일이었어요. 제 목표는 컨텍스트 전환을 막기 위해 활성 세션을 2개로 두는 건데, 일을 더 맡아서 전부 돌아가며 보다가 결국 전체적으로는 덜 해내기가 너무 쉽습니다. 열두 개 넘게 띄워 본 적도 있는데 정말 진이 빠집니다. 윈도 안에 pane을 더 두고 하위 작업을 추적하는 것도 감당이 안 되고요. 또 다른 문제는 에이전트가 하다 보면 관련된 일이나 계획에 없던 일까지 계속 집어 와서 작업이 점점 불어난다는 겁니다. 그래서 에이전트에게 티켓을 만들게 해서 나중에 계획 세션에서 다시 보는 식으로 고삐를 쥐려고 합니다. 작업을 최소로 유지하면 느리게 느껴지지만, 다른 세션들의 인지적 잔여물 없이 문제를 깊이 생각할 수 있습니다.
2015년부터 Tmux를 쓰다가 에이전트용으로 herdr를 쓰기 시작했는데 꽤 좋습니다.
workmux는 써 보셨나요? herdr의 90%를 tmux(또는 아무 터미널 멀티플렉서)로 해 줍니다.
Windows에서는 tmux나 tmux 비슷한 도구를 어떻게 쓰시나요? git bash 안의 tmux는 정말 느립니다. 다른 도구가 있을까요? WSL을 쓰면 된다는 건 알지만, 배포 관련 제약 때문에 저는 쓸 수 없습니다.