
AI 에이전트 시대의 터미널 멀티플렉서 「herdr」로 tmux에서 갈아탄 이유
요약
AI 코딩 에이전트를 효율적으로 관리하기 위해 tmux 대신 Rust 기반의 에이전트 멀티플렉서인 herdr를 사용하는 이유와 특징을 소개합니다. herdr는 세션 영속성을 유지하면서도 CLI와 Socket API를 통해 강력한 플러그인 확장성을 제공합니다.
핵심 포인트
- AI 에이전트 병렬 구동 시 상태 파악을 위한 특화된 관리 도구 필요
- Rust 기반의 herdr는 tmux의 영속성과 에이전트 통합 기능을 결합
- CLI 및 Socket API를 제공하여 언어에 구애받지 않는 플러그인 작성 가능
- Workspace, Tab, Pane의 3계층 구조로 체계적인 컨텍스트 관리 지원
서론
Study Pocket에서 집행임원 CTO를 맡고 있는 @Tocyuki입니다.
저는 오랫동안 tmux를 터미널 멀티플렉서 (Terminal Multiplexer)로 사용해 왔습니다. Zellij나 WezTerm의 멀티플렉서 기능 등 갈아탈 후보를 몇 번이나 검토했지만, tmux를 키워온 애착도 있었고, 무엇보다 tmux를 사용하며 딱히 불편함이 없다는 이유로 이전을 하지 않았습니다.
상황이 바뀐 것은 AI 코딩 에이전트 (AI Coding Agent)를 여러 개 병렬로 구동하게 되면서부터입니다. 저는 Claude Code를 중심으로 Codex, Cursor, Kiro와 같은 여러 에이전트를 용도에 따라 구분하여 사용하고 있습니다. tmux의 페인 (Pane)에 에이전트들을 나열해 두면, "어느 에이전트가 승인 대기 상태로 멈춰 있는지"를 파악하기 위해 모든 페인을 순서대로 하나씩 확인해야 했습니다.
에이전트 관리에 특화된 도구로서 cmux도 갈아탈 후보에 올랐지만, tmux에서 갈아탈 만큼의 강력한 동기가 생기지 않아 보류했습니다.
그러던 중 herdr를 만났습니다. 실제로 사용해 보고 "AI 에이전트 시대의 터미널 멀티플렉서는 이것이다"라고 느껴 tmux에서 갈아탔습니다. 이 기사에서는 herdr의 주요 기능을 갈아타서 좋았던 포인트와 함께 소개합니다.
herdr란
herdr는 "one terminal for the whole herd"를 내걸고 있는 Rust 제작 에이전트 멀티플렉서 (Agent Multiplexer)입니다. herd(무리)라는 이름처럼, 여러 개의 AI 코딩 에이전트를 하나의 터미널에서 관리하는 것에 특화되어 있습니다.
2026년 3월에 공개된 비교적 최신 프로젝트이지만, GitHub의 스타 수는 집필 시점 기준으로 약 4,800개에 달하며 활발하게 개발이 진행되고 있습니다. 싱글 바이너리 (Single Binary)로 배포되기 때문에 도입도 간편합니다.
tmux와의 차이점을 정리하면 다음과 같습니다.
| 관점 | tmux | herdr |
|---|---|---|
| 세션의 영속화 | ○ | ○ |
| ... | send-keys 등을 직접 조합해야 함 | CLI · Socket API를 표준 제공 |
| 플러그인 구조 | TPM + 쉘 스크립트 (Shell Script) | CLI · Socket API 기반 (언어 불문) |
tmux의 강점이었던 영속 세션이나 기존 환경 유지 기능은 그대로 가져가면서, 에이전트 관리 기능이 추가된 구조입니다.
플러그인을 만드는 방식도 대조적입니다. tmux가 쉘 스크립트로 옵션이나 명령어를 후킹 (Hooking)하는 것에 반해, herdr는 CLI와 소켓 API (Socket API) 그 자체를 플러그인의 접점으로 공개하고 있습니다. 소켓과 통신할 수 있는 언어라면 무엇이든 플러그인을 작성할 수 있는 것입니다. cmux와 같은 GUI 도구와 달리 터미널 안에서 완결되기 때문에, tmux 사용자에게는 "tmux와 유사한 조작감을 유지하면서 cmux와 같은 에이전트 통합 환경을 얻을 수 있는" 위치라고 할 수 있습니다.
설치와 기본 조작
Linux와 macOS에서는 설치 스크립트를 실행하기만 하면 됩니다.
curl -fsSL https://herdr.dev/install.sh | sh
macOS라면 Homebrew로도 설치할 수 있습니다.
brew install herdr
실행은 터미널에서 herdr를 실행합니다. tmux와 마찬가지로 서버 · 클라이언트 분리 아키텍처 (Server-Client Separation Architecture)를 채택하고 있어, 터미널을 닫아도 세션은 백그라운드에서 계속 유지됩니다. SSH를 통한 서버 상의 herdr 원격 어태치 (Remote Attach)도 지원합니다.
Workspace > Tab > Pane의 3계층 구조
herdr의 화면은 다음 3계층으로 구성됩니다.
- Workspace: 프로젝트 단위의 컨텍스트 (Context). 리포지토리 (Repository)별로 나누는 것이 기본
- Tab: Workspace 내의 서브 컨텍스트 (Sub-context)
- Pane: Tab 내의 터미널 분할. 쉘 (Shell), 에이전트, 서버 등을 각각 실행
tmux의 Session > Window > Pane에 대응하는 개념이므로, tmux 사용자라면 망설임 없이 사용을 시작할 수 있습니다. git worktree와 조합하여 하나의 리포지토리 내 여러 브랜치를 Workspace에 나열하는 방식과도 궁합이 좋습니다.
에이전트 상태의 자동 감지 및 통지
herdr로 갈아탄 가장 큰 이유는 바로 이 기능입니다. 사이드바에 각 에이전트의 상태가 색상과 함께 목록으로 표시되며, 다음 5가지 상태를 자동으로 판별해 줍니다.
| 상태 | 의미 |
|---|---|
| 🔴 Blocked | 승인이나 입력을 기다리며 정지 중 |
| ... |
중요한 점은, 이 감지에 특별한 설정이나 플러그인이 전혀 필요하지 않다는 것입니다. herdr는 프로세스 테이블 (Process Table) 모니터링과 터미널 화면 출력의 패턴 매칭 (Pattern Matching)을 결합한 휴리스틱 감지 (Heuristic Detection)를 백그라운드에서 상시 수행하고 있으며, Claude Code, OpenCode, Codex, Cursor 등의 에이전트를 설치 직후부터 인식합니다.
나아가 각 에이전트용 공식 인테그레이션 (Integration)을 추가하면, 에이전트 스스로가 훅 (Hook)이나 플러그인을 통해 라이프사이클 이벤트 (Lifecycle Event)를 herdr로 직접 보고하게 됩니다. 인테그레이션이 활성화되어 있는 동안에는 이 정보가 우선시되어, 더욱 정확한 상태가 반영되는 구조입니다.
인테그레이션의 도입과 삭제는 각각 1개의 명령어로 수행할 수 있습니다.
# Claude Code의 인테그레이션을 설치
herdr integration install claude
# 언인스톨
...
지원되는 에이전트는 Claude Code, Codex, Copilot, Cursor, Devin, OpenCode 등 집필 시점 기준으로 13종류입니다. 에이전트마다 다음 중 하나 또는 둘 모두가 추가됩니다.
라이프사이클 상태의 직접 보고: 화면 출력 패턴 매칭을 통한 추정이 아니라, 에이전트의 훅으로부터의 보고이므로 Idle, Working, Blocked의 감지 정밀도가 향상됨 -
세션 ID 연동을 통한 네이티브한 세션 복원: herdr가 에이전트의 세션 ID (Session ID)를 파악하여, 서버 재시작 후에도 에이전트의 대화를 복원하고 지속할 수 있음
특히 세션 복원은 tmux에는 없었던 경험입니다. 머신을 재부팅한 후 herdr를 다시 실행하면, 레이아웃뿐만 아니라 에이전트의 대화 컨텍스트 (Context)까지 통째로 복원할 수 있습니다 (자동 재개 (Auto-resume) 동작은 후술할 config.toml의 [session]에서 제어할 수 있습니다).
감지 메커니즘에 대해 조금 더 자세히
herdr의 상태 감지는 이단계 구조로 되어 있습니다.
휴리스틱 감지 (Heuristic Detection): OS의 프로세스 테이블에서 페인 (Pane) 내의 포그라운드 프로세스 (Foreground Process)를 식별하고, 화면 출력을 기지의 에이전트 패턴과 대조하여 상태를 추정함. 설정 없이 작동하는 것은 이 방식임 -
인테그레이션 (Integration): Claude Code는 셸 훅 (Shell Hook), OpenCode는 JavaScript 플러그인과 같은 형태로, 에이전트의 라이프사이클 훅으로부터 herdr의 소켓 API (Socket API)로 상태를 보고함. 인테그레이션이 활성화된 경우 이 정보가 권위 있는 정보원으로서 우선됨
인테그레이션이 없는 에이전트라도 휴리스틱 감지로 폴백 (Fallback)하기 때문에, 상태 표시가 완전히 사라지는 일은 없습니다.
tmux 시절에는 "이제 끝났나?" 싶어 모든 페인을 순회하곤 했지만, herdr에서는 사이드바를 보는 것만으로 Blocked 상태인 에이전트로 직행할 수 있습니다. 에이전트의 병렬 수가 늘어날수록 이 차이는 더욱 크게 체감됩니다. 상태 변화는 토스트 알림 (Toast Notification)이나 알림음으로도 받을 수 있으며, 알림 전송 대상은 후술할 config.toml에서 변경할 수 있습니다.
tmux 스타일의 키 바인딩 (Keybinding)
herdr의 프리픽스 키 (Prefix Key)는 기본적으로 Ctrl+B입니다. 그렇습니다, tmux와 완전히 동일합니다. 전환 시 학습 비용이 낮다는 점은 이 기본 설정 덕분이 크다고 느낍니다.
주요 기본 키 바인딩은 다음과 같습니다.
| 작업 | 키 바인딩 |
|---|---|
| 프리픽스 (Prefix) | Ctrl+B |
| 세로 분할 | prefix → v |
| 가로 분할 | prefix → - |
| 페인(Pane) 닫기 | prefix → x |
| 페인 포커스 이동 | prefix → h / j / k / l |
| 줌 (Zoom) | prefix → z |
| 리사이즈 모드 | prefix → r |
| 사이드바 표시 전환 | prefix → b |
| 다음 탭으로 이동 | prefix → n |
| 이전 탭으로 이동 | prefix → p |
| 탭 번호로 전환 | prefix → 1 〜 9 |
| 신규 Workspace | prefix → Shift+N |
| Workspace 이름 변경 | prefix → Shift+W |
| 디태치 (Detach) | prefix → q |
마우스 조작도 기본적으로 활성화되어 있어, 페인 클릭 이동이나 리사이즈는 마우스로도 수행할 수 있습니다.
config.toml을 통한 설정
설정은 ~/.config/herdr/config.toml에 TOML 형식으로 기술합니다 (환경 변수 HERDR_CONFIG_PATH로 경로를 덮어쓸 수도 있습니다). herdr --default-config를 통해 기본 설정 전체를 출력할 수 있으므로, 이를 살펴보면 무엇을 변경할 수 있는지 대략적으로 파악할 수 있습니다. 설정 항목의 전체 모습은 공식 레퍼런스에 정리되어 있습니다.
주요 커스터마이징 포인트는 다음과 같습니다.
[keys]: 프리픽스 키 변경 및 각 액션의 키 바인딩 정의.""를 할당하면 해당 바인딩을 무효화할 수 있습니다.[theme]:catppuccin,tokyo-night,dracula,nord,gruvbox,kanagawa,rose-pine등 풍부한 빌트인 (Built-in) 테마 중에서 선택.custom테이블을 통해 개별 색상을 덮어쓰는 것도 지원합니다.[terminal]: 기본 쉘 지정 및 신규 페인의 작업 디렉토리 (follow,home,current, 고정 경로) 제어.[ui]: 사이드바 너비 및 실행 시 접기 여부, 페인 테두리 표시, 마우스 캡처 등 화면 주변 조정.mobile_width_threshold(기본값 64자) 이하의 너비에서는 모바일용 단일 열 레이아웃으로 자동 전환됩니다.[ui.toast]: 토스트 알림의 전송 대상 (off,herdr,terminal,system) 및 표시 위치, 표시까지의 지연 시간(초) 조정 가능.[ui.sound]: 알림음 활성화 및 오디오 파일 지정. 에이전트별 뮤트(Mute) 기능도 지원합니다.[session]: 세션 복구 시 에이전트를 자동으로 재개(Resume)할지 여부 제어.[update]: 업데이트 채널 (stable,preview) 및 자동 버전 체크 제어.[advanced]/[experimental]: 스크롤백 상한 바이트 수나 페인 히스토리 영속화 등의 실험적 기능.
[theme]에서 흥미로운 점은 name = "terminal"을 지정하면 WezTerm이나 Ghostty와 같은 터미널 에뮬레이터의 배색을 그대로 상속받을 수 있다는 점입니다. auto_switch를 활성화하면 터미널의 라이트/다크 모드 전환에 따라 dark_name, light_name으로 지정한 테마를 자동으로 전환할 수도 있습니다.
설정 예시를 몇 가지 들어보겠습니다.
[theme]
name = "terminal" # 터미널 에뮬레이터의 배색을 그대로 상속
auto_switch = true # 터미널의 라이트/다크 전환에 따라 자동 전환
...
나아가 [[keys.command]]를 통해 독자적인 명령어를 키에 할당할 수 있습니다. type = "pane"을 지정하면 임시 페인에서 명령어를 실행할 수 있으므로, tmux의 display-popup으로 lazygit을 여는 것과 같은 사용법을 herdr에서도 재현할 수 있습니다.
[[keys.command]]
key = "prefix+alt+g"
type = "pane" # "pane" (임시 페인) / "shell" (백그라운드)
...
키 바인딩은 prefix+n
과 같이 "프리픽스(prefix)를 누른 후 n"이라는 명시적인 시퀀스로 기술합니다. 설정 반영은 herdr server reload-config
명령 또는 기본값으로 prefix
→ Shift+R
에 할당된 리로드 키로 수행할 수 있습니다. UI 관련 설정은 페인을 재시작하지 않고도 반영되며, 기동 시에만 읽히는 일부 설정에 대해서만 herdr의 재시작이 필요합니다.
CLI 및 UNIX 소켓 API
herdr가 "AI 에이전트 시대의" 멀티플렉서라고 느껴지는 또 다른 이유는 CLI와 UNIX 도메인 소켓 (UNIX domain socket) API의 존재입니다. Workspace, Tab, Pane의 조작이나 출력 읽기, 상태 변화 대기까지, herdr 상의 모든 조작을 명령어로 실행할 수 있습니다.
# 페인 목록 표시
herdr pane list
# 페인을 오른쪽으로 분할하여 명령어 실행
...
이러한 명령어들은 로컬의 UNIX 소켓을 통해 실행 중인 herdr 인스턴스와 통신하며, 결과를 JSON으로 반환합니다. 즉, 에이전트 스스로가 herdr를 조작할 수 있다는 뜻입니다.
공식 skill로 에이전트가 herdr를 능숙하게 사용하기
공식 리포지토리에는 에이전트용 skill(herdr의 조작 방법을 정리한 문서)이 준비되어 있습니다. 이를 Claude Code 등에 읽히면, 에이전트가 자율적으로 herdr를 조작하게 됩니다.
예를 들어 "개발 서버를 실행한 뒤 테스트를 수행해줘"라고 요청하면, 에이전트는 다음과 같이 움직입니다.
# 에이전트가 스스로 페인을 분할하고, 서버를 실행한 뒤 ready를 기다림
herdr pane split 1-2 --direction right --no-focus
herdr pane run 1-3 "npm run dev"
...
에이전트가 다른 에이전트를 새로운 페인에 spawn 하여 태스크를 넘겨주는 것과 같은 멀티 에이전트 오케스트레이션 (multi-agent orchestration)도 명령어의 조합으로 실현할 수 있습니다. tmux에서도 send-keys를 구사하면 유사한 작업이 가능하지만, 상태 대기까지 포함하여 표준 CLI로서 정비되어 있다는 점이 결정적인 차이점입니다.
플러그인을 통한 확장
herdr의 플러그인은 "공유 가능하고 실행 가능한 워크플로우 패키지"로 정의됩니다. 공식 문서에 "the entire Herdr CLI is the plugin API"라고 명시된 것처럼, 지금까지 소개한 CLI와 소켓 API가 그대로 플러그인의 API가 됩니다.
이 때문에 구현 언어를 가리지 않습니다. Bash 스크립트든 JavaScript든 Lua든 Rust 바이너리든, 명령어로 실행할 수 있는 것이라면 무엇이든 플러그인으로 만들 수 있습니다. 최소 구성은 herdr-plugin.toml이라는 매니페스트 (manifest) 파일과 실행 가능한 스크립트 두 가지만 있으면 됩니다. 플러그인으로 할 수 있는 일도 폭넓으며, 다음 4가지 종류의 확장 포인트가 마련되어 있습니다.
- 액션 (Action): Workspace 상에서 실행할 수 있는 조작을 매니페스트로 선언
- 이벤트 후크 (Event hook):
worktree.created등의 이벤트 발생 시 처리를 실행 - 페인 (Pane): 터미널 내에 독립적인 UI 영역을 가짐
- 링크 핸들러 (Link handler): 터미널 상의 URL에 대한 Ctrl+클릭을 처리
설치는 GitHub 리포지토리를 지정하여 명령어 한 번으로 가능합니다. 로컬 개발 중인 플러그인은 link로 테스트할 수 있습니다.
# GitHub에서 설치
herdr plugin install owner/repo
# 로컬 플러그인을 링크하여 개발
...
마켓플레이스
공개된 플러그인은 마켓플레이스에서 찾을 수 있습니다. 이름, 작성자, 설명, 언어로 검색할 수 있으며, 인기순이나 업데이트순 정렬도 지원합니다. 집필 시점을 기준으로 50개가 넘는 플러그인이 공개되어 있습니다. 대표적인 것들을 살펴보면 플러그인으로 무엇을 할 수 있는지 구체적으로 그려볼 수 있습니다.
| 플러그인 | 할 수 있는 일 |
|---|---|
| herdr-remote | SSH 없이도 스마트폰이나 메뉴바, Telegram을 통해 에이전트를 모니터링하고 승인 작업까지 수행 가능 |
| ... | vim-tmux-navigator의 herdr 이식 버전. herdr의 페인 (pane)과 Vim의 분할을 동일한 키로 심리스 (seamless)하게 오갈 수 있음 |
| herdr-sessionizer | 프로젝트나 worktree를 퍼지 검색 (fuzzy search)으로 열고, TOML로 선언한 레이아웃에 따라 워크스페이스 (Workspace)를 일괄 구축 가능. tmuxinator과 유사한 사용 방식 가능 |
| herdr-plugin-github-start | GitHub의 Issue나 PR을 기점으로 Claude Code나 Codex를 실행 가능 |
| herdr-token-dashboard | 에이전트 페인 (pane)별 토큰 소비량을 실시간으로 표시 가능 |
알림, 리뷰, 레이아웃, 네비게이션 등 tmux 플러그인이 커버하던 영역은 일단적으로 갖춰지고 있으며, 나아가 에이전트의 원격 승인이나 토큰 가시화와 같은 herdr만의 독자적인 확장 기능도 생겨나고 있습니다.
플러그인 공개 방식도 독특하여, 퍼블릭 리포지토리 (public repository)에 GitHub 토픽 herdr-plugin을 달고 매니페스트 (manifest)를 배치하면 완료됩니다. 인덱스는 30분마다 자동으로 업데이트되므로, 중앙에 별도로 신청하거나 등록하는 작업은 필요하지 않습니다.
tmux의 TPM (Tmux Plugin Manager)에 익숙했던 입장에서는, 확장성을 수용할 수 있는 구조가 있다는 점이 전환을 결정하는 안심 요인이었습니다. CLI가 곧 플러그인 API라는 설계 덕분에, 자신의 워크플로우에 맞춘 확장을 평소 사용하는 쉘 스크립트 (shell script)의 연장선상에서 작성할 수 있다는 점도 장점입니다.
요약
tmux에서 herdr로 전환하며 느낀 장점들을 정리합니다.
tmux와 유사한 키 바인딩 (keybinding): 프리픽스 (prefix)가 동일한 Ctrl+B로, 학습 비용이 거의 제로에 가까웠다 -
설정이 필요 없는 에이전트 상태 감지: 휴리스틱 (heuristic) 감지가 백그라운드에서 작동하여, 설치 직후부터 Blocked · Working · Done · Idle 상태를 시각화해 준다 -
CLI와 UNIX 소켓 API: 공식 스킬 (skill)을 에이전트에게 읽히는 것만으로, 에이전트 스스로 herdr를 능숙하게 다룬다 -
플러그인을 통한 유연한 확장: 마켓플레이스에서 커뮤니티 제작 플러그인을 도입할 수 있으며, CLI의 연장선에서 직접 제작도 가능하다 -
Rust 기반의 안정성: 싱글 바이너리 (single binary)로 도입이 간편할 뿐만 아니라, 일상적인 사용에서 불안정함을 느낀 적이 없다
"tmux를 쓰는 데 불편함이 없으니까"라며 이전을 미뤄왔던 저조차도, AI 에이전트의 병렬 운용이라는 새로운 과제 앞에서는 전환할 이유가 충분했습니다. 여러 에이전트를 tmux의 페인 (pane)으로 관리하며 어려움을 느끼고 계신 분이라면, 꼭 한번 시도해 보시기 바랍니다.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기