Claude Code 세 개에 Codex 하나를 동시에 돌려본 적 있다면 안다. 창을 이리저리 넘기다 보면 어느 에이전트가 지금 일하는 중이고, 어느 놈이 “이거 진행할까요?” 하고 멈춰 나를 기다리는지 놓치게 된다. Herdr는 바로 이 문제를 겨냥한 도구다. AI 코딩 에이전트 전용으로 만든 Rust 기반 터미널 워크스페이스 매니저로, 모든 패인의 상태를 working·blocked·idle로 표시해 “누가 나를 기다리나”를 한눈에 보여준다. 6월 말 GitHub 트렌딩 Rust 부문 1위를 찍었고 8월엔 YC F26에 합류했다. 이 글에서는 설치부터 상태 모델, 에이전트끼리 서로를 부리는 소켓 API, 노트북을 닫아도 살아남는 지속성까지 실제 명령으로 짚고, tmux·cmux와 언제 뭘 써야 하는지 비교 테이블로 정리한다.
Herdr가 뭐고 왜 지금 뜨나
Herdr는 AI 코딩 에이전트를 위한 터미널 워크스페이스 매니저다. Rust로 짠 단일 바이너리(Electron 없음)이고 Apache 2.0 라이선스로 공개돼 있다. 핵심은 하나 — 여러 에이전트를 한 화면에서 띄워 놓고, 각 패인이 지금 working(작업 중)·blocked(입력 대기)·idle(놀고 있음) 중 어디에 있는지 실시간으로 보여준다. tmux처럼 터미널을 나누되, 그 안에서 돌아가는 게 사람이 아니라 에이전트라는 전제로 설계됐다.
왜 지금 떴냐면, AI 코딩 에이전트를 여러 개 병렬로 굴리는 게 흔한 워크플로가 되면서다. 에이전트 하나는 몇 분씩 혼자 일하다 중간중간 확인을 요구한다. 이걸 서넛 동시에 돌리면 “누가 끝났고 누가 멈췄나”를 사람이 창을 넘겨가며 추적해야 하는데, 이 추적 비용이 병렬성의 발목을 잡는다. Herdr는 그 상태를 도구가 대신 감시한다. GitHub 스타 31.4k, 최신 버전 0.8.2로, 발표 두 달 만에 빠르게 자리를 잡았다.
한 가지 짚어둘 게 있다. Herdr는 에이전트를 감싸거나 대체하지 않는다. 공식 설명대로 “이미 쓰던 걸 그대로 돌리되(runs what you already run), 그들의 터미널을 소유한다”. Claude Code는 여전히 Claude Code로 돌고, Herdr는 그 위에 상태 감시와 지속성, 그리고 에이전트용 API를 얹을 뿐이다.
herdr의 구성 — 세션·워크스페이스·탭·패인
Herdr는 tmux처럼 화면을 계층으로 나눈다. 다만 이름이 조금 다르다. 가장 바깥이 세션(session), 그 안에 프로젝트 단위인 워크스페이스(workspace), 워크스페이스 안에 탭(tab), 탭 안에 화면을 쪼갠 패인(pane), 그리고 각 패인에서 에이전트가 돈다. tmux를 써봤다면 herdr의 탭이 tmux의 window에 해당한다고 보면 된다.
herdr workspace create로 워크스페이스를 만들면 실제로 workspace_id: w1, tab_id: w1:t1, pane_id: w1:p1처럼 id가 계층으로 부여된다. 각 계층은 herdr session·herdr workspace·herdr tab·herdr pane·herdr agent 서브커맨드로 따로 조회·제어한다. 워크스페이스가 프로젝트/디렉토리 단위라, 뒤에서 볼 git worktree 격리도 이 워크스페이스 위에 얹힌다.
설치하고 바로 띄우기
설치는 한 줄이다. macOS·Linux는 공식 스크립트나 Homebrew로, Windows는 PowerShell로 받는다. 버전 관리 도구를 쓴다면 mise로도 된다.
# macOS · Linux — 공식 설치 스크립트
curl -fsSL https://herdr.dev/install.sh | sh
# Homebrew
brew install herdr
# mise
mise use -g herdr
# Windows PowerShell
irm https://herdr.dev/install.ps1 | iex설치 후 프로젝트 루트에서 herdr만 치면 지속 세션이 뜨거나 기존 세션에 붙는다. 세션에서 빠져나올 때는 tmux와 똑같이 ctrl+b q, 다시 들어갈 때는 그냥 herdr를 다시 치면 된다. 세션은 백그라운드 서버에 남아 있어서, 터미널을 닫아도 그 안의 에이전트는 계속 돈다.
herdr # 지속 세션 실행 또는 붙기
herdr --session work # 이름 붙인 세션 생성/사용
herdr status # 클라이언트·서버 상태 확인herdr status를 치면 클라이언트 버전과 서버 실행 여부, 소켓 경로(~/.config/herdr/herdr.sock)까지 보여준다. 여기서 눈여겨볼 건 서버와 클라이언트가 분리돼 있다는 점이다. 이 구조 덕에 클라이언트(내 터미널)를 닫아도 서버는 살아서 에이전트를 계속 돌린다.
실전 워크플로 — 패인을 나누고 에이전트를 붙인다
Herdr 안에서 실제 작업은 화면을 패인으로 나눠 각 패인에 에이전트를 하나씩 붙이는 식이다. tmux를 써봤다면 익숙한 ctrl+b 프리픽스가 그대로 통하고, 마우스로 클릭·드래그·분할하는 것도 된다. 키보드와 마우스가 둘 다 1급이라 손에 맞는 방식으로 나누면 되고, 이 패인 조작과 에이전트 붙이기는 전부 소켓 API로도 노출된다.
herdr pane list # 열린 패인 목록
herdr agent start <pane> claude # 특정 패인에 Claude Code 띄우기
herdr pane zoom # 현재 패인 전체화면 토글
herdr pane focus <방향> # 이웃 패인으로 포커스 이동herdr agent start로 빈 패인에 원하는 에이전트를 올리고, herdr pane zoom으로 한 패인을 잠깐 전체화면으로 키워 자세히 보다가 다시 줄일 수 있다. 여러 패인을 묶어 다루고 싶으면 herdr workspace로 워크스페이스 단위로 나눈다. 어떤 에이전트가 blocked로 돌아서면 herdr notification으로 데스크톱 알림까지 띄울 수 있어, 다른 창을 보고 있어도 나를 기다리는 에이전트를 놓치지 않는다.
핵심: 어느 에이전트가 나를 기다리나
Herdr의 존재 이유는 상태 감시다. 모든 패인은 매 순간 working·blocked·idle 중 하나로 표시되고, 에이전트가 멈춰서 답을 요구하면 Herdr가 그걸 blocked로 알려준다. 다섯 개를 돌리다가도 “지금 나를 기다리는 건 3번뿐”이라는 걸 화면만 봐도 안다. 이게 병렬 실행에서 사람이 쓰던 추적 비용을 없앤다.
tmux나 일반 멀티플렉서에서는 이게 불가능하다. tmux는 패인 안에서 무슨 프로그램이 무슨 상태인지 모른다. 그냥 텍스트가 흐르는 창일 뿐이다. 그래서 어느 에이전트가 끝났는지 알려면 사람이 창마다 넘겨보며 눈으로 확인해야 한다. Herdr는 에이전트의 출력 패턴을 읽어 상태를 판정하기 때문에, “멈춰서 기다리는 중”과 “열심히 일하는 중”을 구분해준다. 확인이 필요한 에이전트만 골라서 대응하면 되니, 병렬로 굴릴수록 이득이 커진다.
에이전트가 서로를 부린다 — herdr agent API
Herdr가 tmux와 결정적으로 갈리는 지점은 에이전트용 API다. CLI와 소켓 API가 같은 표면이라, 사람이 치는 명령을 에이전트도 그대로 호출할 수 있다. 즉 한 에이전트가 다른 에이전트에게 프롬프트를 넣거나, 특정 상태가 될 때까지 기다릴 수 있다. herdr agent 서브커맨드가 그 창구다.
herdr agent list # 떠 있는 에이전트 목록
herdr agent prompt <id> "리뷰 끝났으면 배포 스크립트 실행해" # 프롬프트 주입
herdr agent wait <id> --state blocked # 그 에이전트가 멈출 때까지 대기
herdr agent read <id> # 에이전트 터미널 출력 읽기
herdr agent start <pane> claude # 빈 패인에 에이전트 띄우기
여기서 wait가 핵심이다. 폴링으로 “끝났나? 끝났나?” 되묻는 대신, 에이전트가 실제로 blocked나 idle 같은 목표 상태에 도달할 때까지 진짜로 블로킹한다. 이 덕에 “A 에이전트가 코드를 다 짜면 B 에이전트가 테스트를 돌린다” 같은 조율을 스크립트나 상위 에이전트가 짤 수 있다. tmux에서는 send-keys로 키를 쑤셔 넣을 순 있어도, 상대가 언제 준비됐는지 알 방법이 없어서 이런 조율이 불안정하다. Herdr는 상태를 아니까 조율이 성립한다. 패인 제어(herdr pane)나 git 워크트리 헬퍼(herdr worktree)도 같은 소켓 API 위에 올라가 있다.
실제로 herdr 서버를 헤드리스로 띄우고 소켓 API를 조회하면 이 구조가 그대로 보인다. 아래는 서버를 띄운 뒤 워크스페이스·패인을 만들고 조회한 실측 출력이다. 유료 에이전트는 띄우지 않고 안전하게 확인했다.
에이전트가 패인에 붙으면 같은 소켓 API로 서로를 조율한다. 예컨대 A가 코드를 다 짜면 B가 테스트를 돌리게 하는 스크립트는 이렇게 된다.
# A가 idle(작업 완료) 상태가 될 때까지 진짜로 블로킹
herdr agent wait "$A" --until idle
# 끝났으면 B에게 프롬프트를 주입
herdr agent prompt "$B" "방금 A가 만든 변경으로 테스트 돌려줘"--until에는 idle·working·blocked·done·unknown을 줄 수 있고, --timeout <ms>로 무한 대기를 막는다. 폴링 없이 상태 전이를 기다리기 때문에, 상위 에이전트나 셸 스크립트가 여러 에이전트의 순서를 안정적으로 엮을 수 있다.
에이전트마다 git worktree로 격리한다
에이전트 셋을 같은 폴더에서 돌리면 서로의 파일 변경을 밟는다. Herdr는 herdr worktree create로 각 에이전트를 별도의 git worktree에 앉혀 이 충돌을 없앤다. git worktree는 하나의 저장소를 여러 브랜치로 동시에 체크아웃하는 기능인데, 에이전트마다 하나씩 주면 A는 인증 기능을 B는 결제 기능을 같은 레포에서 충돌 없이 병렬로 짤 수 있다.
herdr worktree create feature-auth # feature-auth 브랜치의 worktree 생성·열기
herdr worktree list # worktree 워크스페이스 목록
herdr worktree remove feature-auth # 끝난 worktree 정리각 worktree는 독립된 작업 트리라 브랜치·빌드 산출물·미완성 변경이 서로 섞이지 않는다. 병렬 실행에서 가장 골치 아픈 “여러 에이전트가 같은 파일을 동시에 고쳐 충돌 나는” 문제를 구조적으로 막아주는 셈이다. 이 worktree 격리는 GUI 앱인 Orca가 내세우던 강점인데, Herdr는 그걸 터미널에서 CLI 명령 하나로 끌어온다.
노트북을 닫아도 에이전트는 계속 일한다
Herdr는 클라이언트-서버 구조라 세션이 사람의 접속과 무관하게 살아남는다. 백그라운드 서버가 에이전트를 붙들고 있어서, 노트북을 닫거나 네트워크가 끊겨도 작업이 멈추지 않는다. 다시 접속하면 그 사이 진행된 상태를 그대로 이어받는다. 긴 리팩터링을 걸어두고 퇴근했다가 아침에 결과를 확인하는 식이 가능해진다.
여기에 원격 옵션이 더해진다. herdr --remote <ssh-target>로 다른 머신의 세션에 붙을 수 있어서, 성능 좋은 원격 박스(rent a box)에 에이전트 무리를 띄워 두고 노트북에서는 붙기만 하는 구성이 된다.
herdr --session refactor # 이름 붙인 세션에 작업을 걸어두고
# (노트북을 닫아도 서버가 refactor 세션의 에이전트를 계속 돌린다)
herdr --remote user@gpu-box --session refactor # 다른 머신/원격 박스의 세션에 붙기이 지속성이 cmux나 tmux 없이 그냥 여러 터미널 탭에 에이전트를 띄우던 방식과의 실질적 차이다. 탭 방식은 창을 닫는 순간 에이전트가 죽지만, Herdr 세션은 서버가 붙들고 있어 죽지 않는다. 병렬 실행 환경을 어떻게 짜는지는 Orca vs cmux 비교 글에서 다룬 선택지와 이어진다.
지원 에이전트 — 17종 자동 감지
Herdr는 주요 에이전트 CLI를 기본으로 인식한다. herdr integration status로 감지 상태를 보고, herdr integration install <name>으로 특정 에이전트 연동을 켠다. 감지 대상에는 Claude Code, Codex, Cursor, Copilot, Devin, opencode, Grok, Hermes, Qwen, Kimi 등이 들어간다.
herdr integration status # 감지된 에이전트 상태
herdr integration install claude # Claude Code 연동 설치
herdr integration install codex # Codex 연동 설치목록이 넓다는 건 특정 벤더에 묶이지 않는다는 뜻이다. cmux가 Claude Code 병렬 실행에 초점을 둔 것과 달리, Herdr는 어떤 에이전트든 같은 상태 모델과 API 아래로 끌어온다. 팀이 Claude Code와 Codex를 섞어 쓰거나, 에이전트를 갈아타는 중이라도 워크스페이스는 그대로 유지된다.
주요 설정 — config.toml과 키바인딩, 업데이트 채널
Herdr의 설정은 ~/.config/herdr/config.toml 한 파일에 모인다. 키바인딩을 바꾸거나 동작을 손본 뒤에는 herdr config check로 문법과 진단을 확인하고, 서버가 떠 있는 상태라면 herdr server reload-config로 재시작 없이 바로 반영한다. 커스텀 키바인딩이 꼬였을 때는 herdr config reset-keys가 백업을 남기고 기본값으로 되돌린다.
herdr config check # config.toml 검증 + 진단
herdr config reset-keys # 커스텀 키바인딩 초기화(백업 후)
herdr server reload-config # 서버 재시작 없이 설정 다시 읽기
herdr channel set preview # 프리뷰 채널로 전환(최신 기능 먼저)
herdr update # 최신 버전 설치업데이트 채널이 stable과 preview로 나뉜다는 점도 알아두면 좋다. 안정성이 우선이면 stable에 두고, 새 기능을 먼저 만져보고 싶으면 herdr channel set preview로 바꾼 뒤 herdr update로 받는다. 무중단으로 설정을 다시 읽는 reload-config는 여러 에이전트를 띄워 둔 채 키바인딩만 손보고 싶을 때 특히 편하다. 세션을 죽이지 않아도 되니까.
설정 파일이 없어도 Herdr는 기본값으로 돌지만, 키·셸·worktree 위치 정도는 처음에 잡아두면 편하다. herdr --default-config > ~/.config/herdr/config.toml로 기본 설정을 통째로 뽑은 뒤 아래처럼 필요한 부분만 손보는 걸 권한다.
# ~/.config/herdr/config.toml
onboarding = false # 첫 실행 온보딩 화면 건너뛰기
[terminal]
shell_mode = "auto" # macOS 로그인 셸 PATH(Homebrew 등) 반영
new_cwd = "follow" # 새 패인은 현재 워크스페이스 디렉토리를 상속
[worktrees]
directory = "~/.herdr/worktrees" # 에이전트별 git worktree 체크아웃 위치
[keys]
prefix = "ctrl+b" # tmux와 같은 프리픽스
new_tab = "prefix+c"
split_horizontal = "prefix+minus"가장 먼저 챙길 값은 [terminal] shell_mode = "auto"다. macOS에서 로그인 셸을 띄워 Homebrew·path_helper 같은 PATH 설정이 새 패인에도 먹게 해주는데, 이게 없으면 에이전트가 brew로 깐 CLI를 못 찾는 사고가 난다. [worktrees] directory는 사이드바에서 만드는 worktree들이 쌓일 곳이라 프로젝트 밖 깔끔한 경로로 지정해두면 관리가 쉽다. 키바인딩을 바꿨다면 herdr config check로 검증하고, 서버가 떠 있으면 herdr server reload-config로 무중단 반영한다. 활성 바인딩은 실행 중 prefix+?로 언제든 확인할 수 있다.
Herdr vs tmux vs cmux vs Orca — 뭘 언제 쓰나
넷은 겨냥이 다르다. tmux는 범용 터미널 멀티플렉서라 에이전트를 몰라도 어디서나 쓰이고, cmux는 Claude Code 병렬 실행에 특화됐다. Orca는 상태 감시·오케스트레이션·worktree 격리를 갖춘 GUI 앱으로 여러 에이전트를 묶고, Herdr는 그와 거의 같은 걸 터미널에서 Rust 단일 바이너리로 해낸다. 아래 표가 선택 기준을 압축한다.
| 항목 | Herdr | tmux | cmux | Orca |
|---|---|---|---|---|
| 주 대상 | AI 코딩 에이전트(다종) | 범용 프로그램 | Claude Code 병렬 | AI 에이전트(다종) |
| 에이전트 상태(working/blocked/idle) | ✓ | ✗ | 일부 | ✓ |
| 에이전트용 API(프롬프트·wait) | ✓ (CLI=소켓) | ✗ | 제한적 | ✓ (오케스트레이션) |
| git worktree 격리 | ✓ (worktree create) | ✗ | ✗ | ✓ |
| 백그라운드 지속성 | ✓ (서버-클라이언트) | ✓ (세션) | ✓ | 일부 |
| 원격(ssh) 세션 | ✓ (--remote) | ✓ | 제한적 | 제한적 |
| 키보드+마우스 | ✓ (prefix+GUI) | 키보드 중심 | GUI 중심 | GUI 중심 |
| 구현 | Rust 단일 바이너리 | C | Electron 앱 | GUI 앱 |
| 라이선스 | Apache 2.0 | ISC | 오픈소스 | 앱(비공개) |
판단은 단순하다. 에이전트를 안 쓰는 일반 원격 작업이면 tmux가 여전히 정답이고, Claude Code만 여러 개 굴린다면 cmux가 가볍다. 여러 종류의 에이전트를 섞어 돌리면서 “누가 나를 기다리나”와 “에이전트끼리 조율”, worktree 격리가 필요해지면 Orca와 Herdr의 영역이다. 이 둘은 형태로 갈린다 — 시각적 GUI 대시보드로 오케스트레이션을 다루고 싶으면 Orca가, 터미널에 살면서 가벼운 Rust 단일 바이너리로 같은 상태·API·격리를 원하면 Herdr가 맞다. 터미널 자체를 다루는 기본기는 tmux 치트시트에 정리해 뒀으니 함께 보면 좋다.
직접 띄워본 결과
herdr 0.8.2를 실제로 설치해 명령 표면을 확인해봤다. 데몬을 띄워 에이전트를 붙이는 대신, 상태와 API 구조만 안전하게 들여다본 결과다.
herdr --version은 0.8.2를, herdr status는 클라이언트/서버 분리 구조와 소켓 경로를 보여준다. 눈여겨볼 건 herdr agent --help에 찍힌 서브커맨드들이다. list·prompt·wait·send-keys·read·start가 그대로 있어서, 앞서 설명한 “에이전트가 서로를 부린다”는 게 문서상 수사가 아니라 실제 CLI 표면임을 확인할 수 있다. herdr integration의 설치 목록에는 claude·codex·cursor·copilot·devin·opencode·grok 등이 늘어서 있다.
자주 묻는 질문 (FAQ)
Herdr가 tmux를 대체하나요?
용도가 다르다. tmux는 에이전트를 모르는 범용 멀티플렉서라 서버 접속·로그 모니터링 등 어디서나 쓰인다. Herdr는 AI 코딩 에이전트에 특화돼 상태 감시와 에이전트용 API를 얹는다. 에이전트를 여러 개 굴리는 워크플로가 아니라면 tmux로 충분하고, 그 워크플로가 핵심이면 Herdr가 값을 한다.
어떤 AI 에이전트를 지원하나요?
Claude Code, Codex, Cursor, Copilot, Devin, opencode, Grok, Hermes, Qwen, Kimi 등 17종 안팎을 기본 감지한다. herdr integration install <name>으로 개별 연동을 켠다. Herdr는 에이전트를 감싸지 않고 원래 CLI 그대로 돌리므로, 각 도구의 동작은 바뀌지 않는다.
노트북을 닫아도 정말 계속 도나요?
그렇다. Herdr는 클라이언트-서버 구조라 백그라운드 서버가 에이전트를 붙들고 있다. 클라이언트(내 터미널)를 닫아도 서버 세션은 살아 있어 작업이 이어지고, 다시 herdr로 붙으면 그 사이 진행 상태를 이어받는다. --remote로 다른 머신의 세션에 붙는 것도 된다.
cmux나 Orca와는 뭐가 다른가요?
cmux는 Claude Code 병렬 실행에 특화된 반면 Herdr는 여러 종류의 에이전트를 같은 상태 모델·API로 묶는다. Orca는 GUI 앱 중심이고 Herdr는 Rust 단일 바이너리로 터미널에 산다. 상태 감시(working/blocked/idle)와 herdr agent wait 같은 조율 프리미티브가 Herdr의 색깔이다.
무료인가요?
Apache 2.0 라이선스의 오픈소스다. GitHub에서 소스를 받을 수 있고, 회사(YC F26)가 붙었지만 런타임 자체는 오픈으로 유지한다고 밝히고 있다.
마치며 — 에이전트를 ‘무리’로 보기 시작하면
처음 Claude Code 하나를 쓸 때는 이런 도구가 왜 필요한지 몰랐다. 창 하나면 충분했으니까. 그런데 둘, 셋으로 늘리는 순간 문제가 바뀌었다. 코드를 짜는 시간보다 “지금 누가 뭘 하고 있나”를 파악하는 데 신경이 더 쓰였다. 병렬성이 주는 이득을 관리 비용이 갉아먹는 지점이 분명히 있었다.
Herdr가 파고든 건 그 관리 비용이다. 에이전트를 하나하나의 창이 아니라 상태를 가진 ‘무리’로 다루기 시작하면, “누가 나를 기다리나”만 보면 된다. herdr agent wait 같은 프리미티브까지 오면 사람이 조율하던 걸 스크립트가 대신한다. 아직 0.8 대라 다듬을 곳은 있겠지만, AI 에이전트를 여러 개 굴리는 게 일상이 된 지금, 이 방향이 맞다는 건 스타 31.4k가 말해준다. 나처럼 창을 넘겨가며 “얘 끝났나?”를 반복하고 있다면, 한 번 무리로 묶어볼 때가 됐다.
함께 읽으면 좋은 글
- Orca vs cmux: AI 코딩 에이전트 병렬 실행, 뭘 골라야 하나
- cmux 사용법: Claude Code 여러 개를 한 터미널에서 병렬로 굴리는 법
- tmux 명령어·단축키 치트시트: 세션부터 복사 모드까지 한 장 정리