한 줄 요약: herdrdev/herdr는 Claude Code·Codex·Cursor·OpenCode 같은 코딩 에이전트를 감싸지 않고, 그 에이전트가 돌아가는 터미널(PTY)을 서버가 소유하는 Rust 단일 바이너리입니다. tmux처럼 detach/attach가 되고, 그 위에 “지금 어떤 에이전트가 승인 대기로 막혀 있나”를 알려주는 상태 감지 엔진과, 에이전트가 다른 에이전트를 스크립트로 부리는 소켓 API를 얹었습니다. 2026년 11월 1일 GitHub Trending Rust 일간 6위(하루 +246 스타), 누적 47,196 스타입니다. 이 글은 v0.9.5 공식 바이너리를 박스(CPU 전용 VM)에서 직접 돌려 본 측정치와 함께 구조·설계 선택·한계를 실무자 관점에서 뜯어봅니다.
1. 기본 정보 — 무엇을, 어떤 조건으로
| 항목 | 값 (2026-11-01 KST 확인) | 비고 |
|---|---|---|
| 저장소 | herdrdev/herdr | 공식 사이트 herdr.dev, 문서는 저장소 docs/next에 함께 있음 |
| 최신 안정 버전 | v0.9.5 (2026-10-15 01:07 KST 배포) | v0.9.4 기능 릴리스의 핫픽스. preview 채널이 별도로 운영됨 |
| 라이선스 | Apache-2.0 | 상업 사용·사내 배포에 부담이 적은 편 |
| 스타 / 포크 | 47,196 / 3,773 | GitHub API 기준, 오픈 이슈+PR 398 |
| 트렌딩 | Rust 일간 6위, 오늘 +246 | 전체 일간 목록에는 미진입 |
| 언어·규모 | Rust 2021 + 벤더링한 Zig 라이브러리 | src/ Rust 약 29만 1천 줄(이 중 테스트 경로 약 4만 7천 줄), 통합 테스트 파일 20개 |
| 생성일 / 최근 커밋 | 2026-03-27 / 2026-10-29 | 최상위 기여자 1명이 커밋 1,314개 — 사실상 1인 주도 + 외부 기여자 |
| 지원 OS | Linux·macOS (x86_64/aarch64), Windows x86_64 | Windows ARM64는 x64 에뮬레이션 “최선 노력” |
| 인식하는 에이전트 | 24종 (pi, claude, codex, gemini, cursor, devin, agy, cline, opencode, copilot, kimi, kiro, droid, amp, grok, hermes, qwen …) |
그중 22종은 화면 매니페스트(TOML) 보유 |
2. 왜 지금 뜨나 — “에이전트 여러 개” 시대의 진짜 병목
에이전트를 하나 쓸 때는 터미널 탭 하나면 충분합니다. 그런데 리뷰어·구현자·테스트 러너를 동시에 세 개, 다섯 개 돌리기 시작하면 병목은 모델이 아니라 사람의 주의력으로 옮겨 갑니다. “어느 탭이 5분째 ‘Do you want to proceed?’에서 멈춰 있지?”를 찾느라 탭을 순회하는 시간이 실제 비용이 됩니다. SSH 세션이 끊기면 에이전트도 함께 죽는 문제도 그대로입니다.
herdr의 답은 두 가지입니다. 첫째, tmux식 서버–클라이언트 분리로 터미널 프로세스를 클라이언트 수명에서 떼어낸다. 둘째, 모든 페인에 working / blocked / done / idle / unknown 배지를 붙여 “막힌 놈”을 즉시 보여준다. 여기에 에이전트가 herdr CLI로 옆 페인을 만들고 다른 에이전트에게 프롬프트를 보내고 “그 에이전트가 진짜로 막힐 때까지” 기다리게 하는 에이전트 네이티브 API가 붙어, 사람이 아니라 에이전트가 오케스트레이터가 될 수 있게 했습니다. README가 스스로를 “코딩 에이전트가 사는 런타임”이라고 부르는 이유입니다.
3. 아키텍처 — 서버가 PTY를 쥐고, 나머지는 전부 클라이언트
구조는 단순한 3층입니다. 맨 아래 herdr server가 워크스페이스 › 탭 › 페인 트리를 소유하고, 각 페인마다 PTY 액터가 실제 셸·에이전트 프로세스를 붙잡습니다. 그 위에 권한 0600의 로컬 소켓(Unix 도메인 소켓, Windows는 네임드 파이프)이 있고, TUI 클라이언트·--remote SSH 클라이언트·CLI·플러그인이 모두 같은 소켓 API의 손님입니다. 즉 사람이 쓰는 UI와 에이전트가 쓰는 자동화가 같은 제어면을 공유합니다.
- 터미널 에뮬레이션:
crates/ghostty-vt가 Ghostty의libghostty-vt를 벤더링해 Zig로 빌드하고 Rust에서 바인딩합니다. VT 시퀀스 해석과 화면 상태를 검증된 엔진에 맡긴 선택으로, Kitty 키보드 프로토콜·Kitty 그래픽·OSC 타이틀 같은 최신 터미널 기능 대응이 빨라지는 대신 빌드 체인에 Zig가 끼어듭니다. - PTY:
portable-pty0.9.0을vendor/로 패치해 씁니다. Windows ConPTY까지 한 추상화로 묶기 위한 선택입니다. - UI: ratatui + crossterm. Electron이 없고 사용자가 쓰던 터미널(WezTerm, Ghostty, iTerm2, Windows Terminal 등) 안에서 돕니다.
- 와이어 프로토콜: 클라이언트–서버 간 비공개 프로토콜(박스에서 확인한 값
private_protocol: 22)과 공개 JSON API가 분리돼 있습니다. 공개 API는herdr api schema --json으로 JSON Schema를 뽑을 수 있어 외부 도구가 계약을 고정하기 좋습니다.
3-1. 저장소 구조 지도
| 경로 | 역할 | 읽을 포인트 |
|---|---|---|
src/server/ (headless.rs 등) |
헤드리스 서버, 클라이언트 접속·렌더 스트림·핸드오프·종료 처리 | shutdown.rs와 Linux logind 지연 억제(inhibitor)로 종료 직전 저장 |
src/pane.rs, src/pane/terminal.rs, src/pty/ |
페인 수명주기, PTY 액터, 입력 인코딩 | 가장 큰 파일군(각 6~7천 줄대) — 키 입력 호환성 버그 수정이 몰리는 곳 |
src/detect/ + manifests/*.toml |
에이전트 식별·상태 감지 엔진과 에이전트별 규칙 | 규칙을 코드가 아닌 데이터로 분리, 원격 매니페스트 업데이트 지원 |
src/app/api/, src/api/ |
소켓 API 핸들러(panes, agents, worktrees, plugins…)와 이벤트 허브·wait | agent.wait가 서버 측 이벤트 기반으로 구현됨 |
src/integration/ + assets/ |
Claude·Codex·OpenCode 등 공식 훅 설치/제거 | 설치 스크립트가 에이전트 설정 파일(JSON/YAML/TOML)을 직접 편집 |
src/persist/ |
session.json 저장·복원, 스냅샷, 백업 | 원자적 쓰기(임시 파일 후 교체), 최대 48개 스냅샷 |
src/remote/ |
SSH 원격 attach, 저장된 머신, ssh-agent 처리 | 원격 호스트에 바이너리가 없으면 설치를 제안 |
crates/ghostty-vt |
libghostty-vt Zig 빌드 + Rust 바인딩 | VT 파서를 직접 쓰지 않은 핵심 설계 선택 |
skills/herdr/SKILL.md |
에이전트에게 herdr 사용법을 가르치는 스킬 문서 | herdr --skill로 출력 가능, 바이너리에 포함 |
4. 핵심 설계: “막힌 에이전트” 감지는 어떻게 하나
herdr의 차별점은 사실상 이 엔진입니다. 소스는 세 갈래이고, 서버가 이를 중재(arbitration)합니다.
| 신호 | 무엇을 알려주나 | 장점 | 약점 |
|---|---|---|---|
| 전경 프로세스 | 이 페인에서 지금 돌고 있는 게 어떤 에이전트인지 | OS가 주는 사실이라 오인 가능성이 낮음 | 상태(작업 중/대기)는 모름. 래퍼 스크립트로 실행하면 식별 실패 가능 |
| 화면 매니페스트 (TOML) | 화면 하단·OSC 타이틀·마지막 구분선 이후 등 영역을 정규식·문자열로 매칭해 상태 판정 | 에이전트 수정 없이 동작. 규칙이 데이터라 원격 업데이트로 빠르게 고침 | 에이전트 UI가 바뀌면 깨짐(실제로 Claude 2.1.228 스피너 변경 대응 주석이 있음) |
| 통합 훅 | 에이전트가 공식 훅으로 pane report-agent·report-agent-session을 호출해 상태·세션 ID 보고 |
가장 정확. 세션 ID로 서버 재시작 후 대화 재개 가능 | 에이전트별 설치 필요, 에이전트 설정 파일을 herdr가 편집 |
매니페스트 하나를 보면 설계 의도가 잘 드러납니다. 번들된 claude.toml(버전 2026.10.11.1)에는 osc_title_working(우선순위 1100), live_blocked_form(980), live_turn_working(970) 같은 규칙이 있고, 각각 region = "after_last_horizontal_rule", "bottom_non_empty_lines(12)"처럼 화면의 어느 부분을 볼지를 명시합니다. 대화 기록 안에 우연히 “Enter to confirm”이 섞여 있어도 마지막 구분선 이후만 보도록 해서 오탐을 줄이는 방식입니다. not = [...] 절로 승인 대화상자 문구가 있으면 working 판정을 막는 식의 상호 배제도 들어 있습니다. 감지 판정은 herdr agent explain으로 어떤 규칙이 왜 맞았는지 증거와 함께 볼 수 있어, 디버깅 가능성을 1급 기능으로 둔 점이 인상적입니다.
또 하나의 디테일은 done과 idle의 구분입니다. 에이전트가 끝났는데 아직 사람이 보지 않았으면 done, 봤으면 idle입니다. 클라이언트마다 “봤음” 상태를 따로 추적하므로 노트북에서 확인한 완료가 데스크톱의 Done 배지를 지우지 않습니다. CLI/API는 서버 기준 상태를 쓰므로 둘 다 “입력 받을 준비됨”으로 해석하면 됩니다.
4-1. 박스에서 감지 엔진을 직접 찔러 보기
실제 Claude Code를 박스에서 돌릴 수는 없어서, 오프라인 판정 모드(agent explain --file)에 직접 만든 화면 세 개를 넣어 봤습니다.
herdr agent explain --file screens/blocked.txt --agent claude
# agent: claude
# state: blocked
# manifest: bundled 2026.10.11.1
# rule: live_blocked_form (region=after_last_horizontal_rule priority=980)
# evidence: " Do you want to make this edit to config.rs? ... Enter to confirm · Esc to cancel"- 승인 대화상자 화면 →
blocked(live_blocked_form). 정상. - “✻ Pondering… (12s · ↑ 1.2k tokens)” + “esc to interrupt” 푸터 →
working(live_turn_working). 정상. - 평범한 셸에 같은 푸터 문자열만 출력(
cat notes.md결과) → 역시blocked. 오프라인 판정에서는 오탐입니다.
세 번째 결과가 흥미롭습니다. 화면 규칙만으로는 “진짜 대화상자”와 “대화상자처럼 보이는 텍스트”를 구분할 수 없다는 뜻이죠. 다만 소스를 보면 detect_agent(agent: Option<Agent>, screen)처럼 매니페스트 적용 자체가 전경 프로세스로 식별된 에이전트를 전제로 하므로, 실사용에서는 셸 페인에 claude 규칙이 적용될 일은 없습니다. 위험한 경우는 에이전트 출력 자체가 승인 대화상자 문구를 마지막 구분선 아래에 그대로 인용할 때입니다. 정확도가 중요한 자동화라면 통합 훅을 설치해 화면 판정보다 강한 신호를 확보하는 편이 맞습니다.
5. 설치와 기본 사용 — 실제 명령
# 설치 (택1)
curl -fsSL https://herdr.dev/install.sh | sh
brew install herdr
mise use -g herdr
# 또는 GitHub 릴리스의 단일 바이너리(herdr-linux-x86_64 등)를 PATH에 두기
# 실행: 작업할 디렉터리에서
herdr # TUI 실행/재접속, ctrl+b q 로 detach
herdr server stop # 세션과 모든 페인 종료
# 공식 훅 설치(정확한 상태·세션 재개용)
herdr integration install claude
herdr integration install codex자동화는 CLI 래퍼부터 시작하는 게 좋습니다. 모든 제어 명령은 JSON을 돌려주므로 ID를 예측하지 말고 응답에서 읽는 것이 공식 권장입니다.
# 옆 페인을 만들고 리뷰어 에이전트를 띄운 뒤, 일을 시키고 끝날 때까지 대기
NEW=$(herdr pane split --current --direction right --cwd "$PWD" --no-focus | jq -r .result.pane.pane_id)
herdr agent start reviewer --kind codex --pane "$NEW"
herdr agent prompt reviewer "현재 diff를 리뷰하고 실행 가능한 지적만 보고해" --wait --timeout 120000
herdr agent read reviewer --source recent --lines 80
# 일반 프로세스(테스트·서버)는 pane 명령으로
herdr pane run w1:p2 "cargo test"
herdr pane wait-output w1:p2 --regex 'test result: (ok|FAILED)' --timeout 600000agent prompt --wait에는 세심한 가드가 있습니다. 대상이 이미 blocked면 입력을 보내지 않고 agent_blocked로 거절하고, 프롬프트 후 5초 안에 working/blocked 활동이 관측되지 않으면 agent_prompt_stalled를 돌려줍니다. “보냈는데 안 먹힌” 경우와 “일하는 중”을 구분하려는 설계입니다. 원시 소켓 API로는 events.subscribe로 상태 변화를 스트림으로 받을 수 있습니다.
6. 박스 스모크 테스트 — 직접 재 본 숫자
환경: 8 vCPU / 16GB RAM Linux VM, GPU 없음. GitHub 릴리스의 공식 herdr-linux-x86_64(v0.9.5) 바이너리를 받고, 공유 설정을 건드리지 않도록 HOME·XDG_CONFIG_HOME을 작업 폴더로 격리했습니다. 설정에는 onboarding = false, 백그라운드 버전 확인·매니페스트 원격 확인을 끄는 version_check = false, manifest_check = false만 넣었습니다. TUI 없이 herdr server를 띄우고 CLI만으로 측정했습니다. 측정 스크립트는 Python subprocess로 CLI를 호출하므로, 아래 지연 시간에는 CLI 프로세스 기동 비용이 포함됩니다.
| 측정 항목 | 방법 | 결과 |
|---|---|---|
| 서버 기동 → API 응답 | herdr server 실행 후 workspace list가 성공할 때까지 5ms 간격 폴링, 3회 |
58 / 60 / 58 ms |
| 빈 서버 메모리 | /proc/PID/smaps_rollup |
RSS 17MB (PSS 17MB) |
| 페인 10개 / 30개 | pane split 반복 후 2초 대기, 서버 RSS + 자식 bash RSS 합 |
서버 21MB / 24MB, bash 합계 38.9MB / 117MB |
| CLI 왕복 | pane list 20회 평균 |
1.4 ms/회 |
| 명령 실행 → 출력 확인 | pane run으로 printf … $((6*7)) 실행 → wait-output --regex '^OUT_…_42'(계산된 출력 줄만 매칭), 20회 |
중앙값 3.5ms, p90 3.9ms, 최소 2.6 / 최대 5.5ms |
| 훅 보고 → 대기 해제 | report-agent --state working 후 1.5초 뒤 다른 프로세스가 blocked 보고, agent wait --until blocked |
1,606ms (지연 1.5초 + 약 0.1초) — 상태·state_change_seq: 2 정상 반영 |
| 재시작 복원 | 30페인 상태에서 루트 페인 cd /tmp → server stop → 재기동 |
30/30 페인, 워크스페이스 라벨, 루트 cwd /tmp 복원. 재기동→응답 134ms |
해석. 서버 자체는 페인 30개에서도 RSS 24MB로, 페인 하나당 증가분이 수백 KB 수준입니다. 실제 메모리는 페인 안의 셸·에이전트가 먹습니다(bash 하나에 약 4MB, Node 기반 에이전트라면 수백 MB). 즉 herdr를 얹는 오버헤드는 에이전트 런타임에 비하면 무시할 만합니다. 명령→출력 3.5ms는 서버가 PTY 출력을 실시간으로 화면 상태에 반영하고 wait_for_output을 서버 측에서 처리하기 때문에 나오는 숫자로, 폴링 기반 스크립트(tmux capture-pane 반복)보다 오케스트레이션 루프를 단단하게 만들기 좋습니다.
측정하지 못한 것. 실제 Claude Code/Codex 세션의 화면 감지 정확도, 원격 SSH attach, --handoff 업데이트, Windows/macOS 동작은 이번 테스트 범위 밖입니다. 위 감지 결과는 직접 만든 화면 텍스트에 대한 오프라인 판정이며, 실제 에이전트 화면에서의 성능 수치가 아닙니다.
7. 세션 복원 — 무엇이 살아남고 무엇이 죽나
이 부분은 기대치를 정확히 맞춰야 합니다. herdr의 가장 강한 영속성은 “서버가 살아 있는 동안의 detach”입니다. 서버가 죽으면(재부팅·server stop) 원래 프로세스는 함께 죽고, 돌아오는 건 레이아웃·cwd·포커스뿐입니다. 박스 테스트에서도 30개 페인이 모두 돌아왔지만 안의 셸은 새로 뜬 프로세스였습니다.
| 상황 | 프로세스 | 레이아웃 | 최근 화면 | 에이전트 대화 |
|---|---|---|---|---|
| detach → 재접속 | 유지 | 유지 | 유지 | 유지 (프로세스가 안 죽었으므로) |
| 서버 재시작 | 종료 | 복원 | pane_history 켰을 때만 |
공식 통합이 세션 ID를 보고했을 때만 재개 |
| update (handoff 없음) | 호환 서버면 유지 | 재시작 후 복원 | pane_history 켰을 때만 |
네이티브 세션 재개 시 |
update --handoff |
최선 노력(실험적) | 유지 | 유지(성공 시) | 유지(성공 시) |
대화 재개는 에이전트별 재개 명령(예: Claude Code claude --resume <id>, Codex codex resume <id>, OpenCode opencode --session <id>, Droid droid --resume <id>, Qwen qwen --resume <id>)을 통합 훅이 보고한 세션 ID로 호출하는 방식입니다. [session] resume_agents_on_restore가 기본으로 켜져 있어, 서버 재시작 직후 에이전트들이 자동으로 다시 뜬다는 점은 장점이자 주의점입니다(비용이 드는 에이전트가 의도치 않게 재기동될 수 있음). 저장은 임시 파일에 쓴 뒤 교체하는 원자적 방식이고, 읽기 실패 시 원본을 session-backups/에 3개까지 보존하며, 레이아웃 스냅샷은 15분 간격으로 최대 48개를 남깁니다. Linux에서는 systemd-logind의 종료 경고를 받아 저장할 시간을 확보하지만, 강제 종료·정전은 예외입니다.
8. 비교 — tmux로 충분하지 않나?
| 항목 | herdr | tmux | Zellij | Orca (stablyai/orca) | claude-squad (tmux 래퍼) |
|---|---|---|---|---|---|
| 형태 | Rust 단일 바이너리 TUI + 서버 | C 터미널 멀티플렉서 | Rust 터미널 워크스페이스 | 데스크톱 앱 + 데몬 | tmux 위의 CLI/TUI |
| detach/persist | 서버 상주 + 레이아웃·cwd 복원, 통합 시 대화 재개 | 서버 상주, 재시작 복원은 플러그인(resurrect 등) | 세션 상주 + 세션 직렬화 | 앱 수명에 의존 | tmux에 의존 |
| 에이전트 상태 감지 | 내장: 프로세스+화면 매니페스트+훅, 24종 | 없음(직접 스크립트) | 없음(플러그인으로 가능) | 에이전트 실행·상태 표시 중심 | 도구별 단순 감지 |
| 에이전트가 에이전트를 부리기 | agent start/prompt/wait, 이벤트 구독, 스킬 문서 동봉 |
send-keys/capture-pane 폴링 |
CLI 액션 일부 | 워크트리별 에이전트 관리 중심 | 제한적 |
| 원격 | SSH 저장 머신 여러 대를 한 창에, 로컬이 UI 렌더 | SSH 후 attach | SSH 후 attach, 웹 클라이언트 | 로컬 중심 | 로컬 중심 |
| git worktree | herdr worktree 명령 내장 |
없음 | 없음 | 핵심 기능 | 핵심 기능인 경우가 많음 |
| 성숙도 | v0.9.x, 7개월 차, 변경 빈번 | 십수 년, 매우 안정 | 안정 단계 | 빠르게 변화 | tmux에 기대는 경량 도구 |
| 라이선스 | Apache-2.0 | ISC | MIT | MIT | AGPL-3.0 |
정리하면, 사람이 쓰는 키바인딩 멀티플렉서로서는 tmux·Zellij가 여전히 더 성숙합니다. herdr가 이기는 지점은 “에이전트 상태를 1급 데이터로 다루는가”입니다. tmux로 같은 걸 하려면 페인마다 capture-pane을 돌리고 에이전트별 정규식을 직접 관리해야 하는데, herdr는 그 규칙 세트를 매니페스트로 유지·배포하고 agent wait를 서버 측 이벤트로 제공합니다. 반대로 Orca 같은 워크트리 오케스트레이터와는 층위가 다릅니다. herdr는 “터미널을 소유하는 런타임”이고, 그 위에 어떤 워크플로를 올릴지는 사용자의 몫입니다.
9. 도입 전 체크리스트 — 한계와 주의점
| 항목 | 기본 동작 | 권장 대응 |
|---|---|---|
| 백그라운드 네트워크 | version_check, manifest_check가 기본 ON — herdr.dev에서 버전·감지 매니페스트 카탈로그를 확인 |
폐쇄망·규제 환경은 [update]에서 끄고 매니페스트는 바이너리 번들본 사용. 반대로 켜 두면 에이전트 UI 변경에 빨리 대응 |
| 원격 매니페스트 | 감지 규칙이 원격으로 갱신됨(코드 실행이 아닌 TOML 데이터) | agent explain의 manifest_source/manifest_version으로 어떤 규칙이 쓰이는지 확인 |
| 소켓 API 권한 | 소켓 0600(소유자만). 같은 계정의 모든 프로세스는 페인 입력·읽기 가능 | 같은 계정에서 도는 신뢰 못 할 프로세스가 있다면 계정 분리. 에이전트에게 herdr 제어권을 주는 건 곧 다른 페인 키 입력 권한을 주는 것 |
| 화면 히스토리 | pane_history 기본 OFF |
켜면 session-history.json에 토큰·비밀값이 남을 수 있음 — 디스크 암호화·권한 관리 전제 |
| 통합 설치 | integration install이 에이전트 설정 파일(Claude settings 등)을 편집해 훅 스크립트 등록 |
dotfiles를 git으로 관리한다면 diff 확인. 훅 스크립트는 HERDR_ENV가 없으면 즉시 종료하도록 작성돼 있음 |
| 자동 재개 | resume_agents_on_restore = true |
과금 에이전트가 재부팅 후 자동 재기동되는 게 싫다면 끄기 |
| 감지 오탐/미탐 | 화면 규칙 기반, 에이전트 UI 업데이트에 취약 | 무인 자동화는 훅 신호 우선. unknown을 완료로 간주하지 말 것(공식 문서도 명시). Antigravity·Grok은 백그라운드 작업 중에도 idle로 보일 수 있음 |
| 성숙도 | v0.9.x, 핫픽스 릴리스가 잦음(v0.9.2→0.9.3, v0.9.4→0.9.5가 각각 하루 만에) | 팀 전체 배포는 버전 고정 + preview 채널 분리 운영 |
| 프로세스 영속성 | 서버가 죽으면 프로세스도 죽음 | 장시간 작업은 서버를 systemd user 서비스 등으로 안정적으로 띄우고, 재부팅을 피할 수 없다면 통합 훅으로 대화 재개 경로 확보 |
10. 어떤 팀에 맞나
- 잘 맞음: 원격 개발 서버에서 에이전트 여러 개를 하루 종일 돌리는 개인·소규모 팀, 에이전트가 하위 에이전트를 띄우는 오케스트레이션을 셸 스크립트 수준으로 만들고 싶은 경우, tmux를 이미 쓰지만 “막힌 페인 찾기”에 지친 경우.
- 애매함: 키바인딩·플러그인 생태계가 완성된 tmux 설정을 버리기 어려운 경우(herdr 페인 안에서 tmux를 쓰는 것도 가능하지만 이점이 줄어듦), 에이전트를 거의 IDE 안에서만 쓰는 경우.
- 안 맞음: 프로세스가 재부팅을 넘어 살아남아야 하는 서버 워크로드(그건 systemd·컨테이너의 일), 엄격한 네트워크 통제 환경에서 기본값 점검 없이 바로 쓰는 경우.
마무리
herdr는 “새 에이전트”가 아니라 에이전트들이 사는 집의 배관을 다시 깐 프로젝트입니다. VT 파싱은 libghostty에 맡기고, 상태 판정 규칙은 데이터로 빼서 원격 갱신하고, 사람과 에이전트가 같은 소켓 API를 쓰게 한 세 가지 선택이 일관됩니다. 박스에서 잰 숫자(빈 서버 17MB, 30페인 24MB, 명령→출력 3.5ms, 30/30 레이아웃 복원)는 오버헤드 걱정을 덜어 줍니다. 반면 화면 기반 감지의 구조적 한계(대화상자처럼 보이는 텍스트는 대화상자로 판정)와 v0.9대의 잦은 변경은 무인 자동화에 쓰기 전에 훅 설치·버전 고정으로 메워야 할 부분입니다. 에이전트를 세 개 이상 동시에 돌리고 있다면, 오늘 저녁 herdr 한 번 띄워서 사이드바의 blocked 배지를 경험해 볼 가치는 충분합니다.