[심층분석] herdr — cmd 창 관리 도구가 아니라, 코딩 에이전트가 사는 런타임입니다

클로드 코드 하나만 돌릴 때는 아무 문제가 없습니다. 두 개가 되면 창을 왔다 갔다 하게 되고, 세 개가 되면 어느 놈이 다 끝났고 어느 놈이 뭘 물어보며 멈춰 서 있는지를 알 수가 없어집니다. herdr은 정확히 그 지점을 겨냥해 만들어진 도구입니다.

에이전트를 세 개 돌리면 터미널이 무너집니다

요즘 개발 풍경이 이렇습니다. 하나는 리서치를 시키고, 하나는 리팩터링을 맡기고, 하나는 테스트를 돌립니다. 문제는 세 개를 동시에 볼 방법이 없다는 것입니다.

한 놈은 벌써 5분 전에 끝나서 놀고 있고, 한 놈은 "이 파일 지울까요?"에서 멈춰 서 있는데 아무도 모릅니다. 긴 작업은 스크롤 위로 사라져 버렸고요. 도구가 느려서가 아니라 상태를 볼 방법이 없어서 생기는 손실입니다.

herdr이 무엇인가

herdr(허더)은 코딩 에이전트를 위한 터미널 멀티플렉서입니다. 여러 에이전트에게 각각 진짜 터미널을 하나씩 주고, 전체 상태를 한 화면에 모아 보여 줍니다.

공식 소개 문구가 성격을 잘 압축합니다 — "당신의 코딩 에이전트가 사는 런타임". 노트북이든 데스크탑이든 빌린 서버든 상관없이요. 그러니까 cmd 창을 예쁘게 꾸며 주는 도구가 아니라, 에이전트를 계속 살려 두는 서버 런타임에 가깝습니다.

왜 지금 이런 도구가 나왔나

2026년 들어 에이전트를 여러 개 동시에 돌리는 것이 예외가 아니라 일상이 됐습니다. 한 명의 개발자가 서너 개의 에이전트를 부리는 게 특별한 일이 아니게 됐죠.

그런데 터미널이라는 인터페이스는 사람 한 명이 한 가지 일을 한다는 전제 위에 만들어져 있습니다. 그 전제가 깨지면서 생긴 공백을 채우려고 나온 게 herdr입니다.

tmux로는 왜 안 되나

"그냥 tmux 쓰면 되지 않나"가 첫 반응일 겁니다. 실제로 창을 나누고 세션을 유지하는 기능만 보면 tmux로 충분합니다.

결정적인 차이는 하나입니다. tmux는 각 페인 안에서 무슨 일이 벌어지는지 전혀 모릅니다. 범용 멀티플렉서라 그게 당연합니다. 페인 열두 개가 있으면 열두 개가 똑같이 생겼고, 어느 것이 끝났는지는 사람이 하나씩 들어가서 봐야 합니다.

핵심 차이 — 에이전트의 상태를 안다

herdr의 존재 이유가 여기 있습니다. 각 페인이 지금 그 에이전트가 어떤 상태인지를 직접 표시합니다. 사이드바에 전체가 한 줄씩 늘어서고, 어느 것이 멈춰 있는지가 한눈에 보입니다.

기능 목록의 차이가 아니라 정보의 층위가 하나 더 있는 것입니다. tmux는 "창"을 관리하고, herdr은 "에이전트"를 관리합니다.

working / blocked / idle 세 가지 상태

상태는 크게 셋으로 표시됩니다.

• working — 지금 일하는 중
• blocked — 뭔가를 물어보며 멈춰 선 상태. 사람이 개입해야 하는 유일한 상태입니다
• idle — 끝났고 놀고 있음

세 개만 있어도 실전에서는 충분합니다. 개발자가 알아야 할 건 결국 "지금 누가 나를 기다리고 있나" 하나니까요.

상태 감지 ① 라이프사이클 훅

그럼 herdr은 그 상태를 어떻게 알아낼까요. 두 가지 방식이 있습니다. 첫 번째가 라이프사이클 훅입니다.

에이전트가 자기 상태를 스스로 보고하는 방식이라 정확하고 실시간입니다. 에이전트 쪽에 훅을 걸 수 있으면 이게 가장 좋은 경로입니다.

상태 감지 ② 화면 매니페스트 TOML

두 번째는 화면 매니페스트입니다. TOML로 규칙을 적어 두고, 터미널 화면에 나타나는 시각적 패턴을 보고 상태를 추론합니다.

훅을 지원하지 않는 에이전트도 커버할 수 있다는 게 장점입니다. 대신 화면 출력이 바뀌면 규칙이 어긋날 수 있다는 약점이 따라옵니다.

클로드 코드는 아직 화면 추론 방식이다

실무에서 중요한 대목입니다. 클로드 코드는 현재 두 번째 방식(화면 패턴 추론)에 의존합니다.

결과적으로 blocked 감지가 약간 늦게 잡힐 수 있습니다. 이벤트를 받는 게 아니라 화면을 읽어서 판단하니까요. 전반적인 모니터링에는 충분하지만, "물어본 그 순간 정확히 알림이 온다"를 기대하면 어긋납니다. 이 한계는 알고 쓰는 편이 낫습니다.

항상 켜져 있다 — 서버 런타임 구조

herdr의 두 번째 축은 지속성입니다. herdr은 백그라운드 서버로 돌고, 에이전트는 그 서버가 관리하는 페인 안에서 삽니다.

그래서 노트북을 덮어도, 네트워크가 끊겨도, 터미널을 닫아도 에이전트는 계속 일합니다. 심지어 머신이 재시작돼도 이전 세션 레이아웃을 복원합니다. 30분짜리 리팩터링을 걸어 두고 이동해야 할 때 이 차이는 큽니다.

디태치와 리어태치

tmux를 써 봤다면 익숙한 개념입니다. 세션에서 빠져나왔다가(detach) 다시 붙는(reattach) 동작이죠. herdr도 같은 모델을 씁니다.

단축키도 관습을 그대로 따릅니다 — Ctrl+B Q로 빠져나옵니다. 여기에 페인 히스토리 재생이 붙어서, 다시 붙었을 때 그동안 무슨 일이 있었는지를 되짚어 볼 수 있습니다.

감싸지 않는다는 설계 원칙

README가 반복해서 강조하는 문장이 있습니다. herdr은 기존 도구를 감싸거나 대체하지 않는다는 것입니다.

클로드 코드를 herdr 버전으로 다시 구현하는 게 아니라, 클로드 코드가 도는 터미널을 소유할 뿐입니다. 이게 왜 중요하냐면 — 에이전트 쪽이 업데이트돼도 herdr이 따라갈 필요가 없기 때문입니다. 래퍼 방식 도구들이 늘 겪는 버전 추격전이 구조적으로 발생하지 않습니다.

지원 에이전트 — 기본 19종

붙는 에이전트 목록이 넓습니다. 공식 자료 기준으로 19종을 기본 인식합니다.

클로드 코드, 코덱스, 커서, 제미나이 CLI, 오픈코드, 그록, 깃허브 코파일럿 CLI, 클라인, 파이(Pi), 드로이드, 앰프(Amp) 등이 포함됩니다. 사실상 터미널에서 도는 에이전트면 대부분 붙습니다.

마우스 우선 — 멀티플렉서의 관습을 깬 지점

herdr에서 가장 이질적인 선택이 이겁니다. 문서가 스스로를 "마우스 우선(mouse-first)" 멀티플렉서라고 설명합니다.

페인을 클릭해서 고르고, 경계를 끌어서 크기를 바꾸고, 우클릭 메뉴에서 분할합니다. tmux를 배울 때 겪는 "단축키 스무 개를 외워야 시작할 수 있다"는 장벽을 아예 없애 버린 셈입니다.

Ctrl+B — tmux 관습은 남겼다

그렇다고 키보드를 버린 건 아닙니다. 기본 프리픽스 키가 Ctrl+B로, tmux와 같습니다.

• Ctrl+B V — 세로 분할
• Ctrl+B C — 새 탭
• Ctrl+B Q — 디태치

tmux를 쓰던 사람은 손가락을 다시 훈련할 필요가 없고, 안 쓰던 사람은 마우스로 시작할 수 있습니다. "도구별로 고르는 게 아니라 순간별로 고른다"는 게 이 설계의 표현입니다.

CLI 구조 ① 세션 명령

herdr은 GUI만이 아니라 완전한 CLI를 갖고 있습니다. 세션 단위부터 보면 이렇습니다.

• herdr session list — 세션 목록
• herdr session attach <name> — 특정 세션에 붙기
• herdr session stop <name> — 세션 종료

기본 세션은 default라는 이름으로 참조합니다.

CLI 구조 ② 페인 명령

페인 단위 조작이 상당히 촘촘합니다. 스크립트로 화면을 짜 놓을 수 있을 정도예요.

• pane split / pane move — 분할하고 탭·워크스페이스 사이로 옮기기
• pane send-text — 원문 입력 그대로 넣기
• pane send-keys — 키 이벤트 전달
• pane run — 명령 실행(엔터까지 자동)
• pane read — 화면 내용 읽기

pane read는 visible·recent·detection 같은 소스를 골라 읽을 수 있고, 평문과 ANSI 서식 양쪽을 지원합니다.

CLI 구조 ③ 에이전트 명령 — 여기가 진짜다

herdr을 그냥 예쁜 tmux가 아니라 다른 종류의 물건으로 만드는 부분이 이겁니다. 에이전트 자체를 다루는 명령군이 따로 있습니다.

• agent start <name> --kind KIND — 지정한 종류의 에이전트를 띄운다
• agent prompt — 에이전트에게 질문을 넣는다(대기 조건·타임아웃 지정 가능)
• agent wait — 상태가 바뀔 때까지 블로킹(idle · done · blocked · unknown)
• agent read — 에이전트 출력 읽기

agent prompt와 agent wait — 에이전트가 에이전트를 부린다

이 두 명령이 함께 있다는 사실이 중요합니다. 질문을 넣고, 끝날 때까지 기다리는 것이 셸 스크립트 한 줄로 가능하다는 뜻이니까요.

그러면 이런 게 됩니다 — 에이전트 A에게 리서치를 시키고 agent wait로 완료를 기다린 뒤, 그 결과를 에이전트 B에게 agent prompt로 넘깁니다. 오케스트레이션을 셸에서 짤 수 있게 되는 것입니다.

공식 문서가 이 설계를 "에이전트 네이티브"라고 부르는 이유입니다. CLI가 사람만 쓰라고 만든 게 아니라, 에이전트가 다른 에이전트를 띄우고 프롬프트를 넣는 데 쓰는 인터페이스이기도 합니다.

소켓 API — 사람과 에이전트가 같은 문을 쓴다

구조적으로 보면 이렇습니다. CLI 명령은 실행 중인 서버와 로컬 소켓 API로 대화하고, 통합 기능과 에이전트도 정확히 같은 API를 씁니다.

응답은 대체로 JSON이라 스크립트로 엮기 좋고, herdr api schema로 스키마를 확인할 수 있습니다. 사람용 문과 기계용 문을 따로 만들지 않았다는 점이 이 프로젝트의 성격을 잘 보여 줍니다.

플러그인과 마켓플레이스

확장 구조도 있습니다. 매니페스트 액션과 이벤트 훅을 가진 로컬 실행형 워크플로우 플러그인을 붙일 수 있습니다.

• plugin install <owner/repo> — 깃허브에서 설치(매니페스트 검증 포함)
• plugin action invoke <action_id> — 플러그인 워크플로우 실행
• plugin pane open — 오버레이·분할·탭·팝업·줌 중 배치를 골라 플러그인 화면 띄우기

커뮤니티 플러그인이 이미 531개로 집계됩니다. 깃허브 기반 마켓플레이스도 준비 중입니다.

러스트 단일 바이너리, 일렉트론 없음

구현 쪽도 짚고 갈 만합니다. herdr은 러스트로 짠 단일 바이너리이고 일렉트론을 쓰지 않습니다.

별도의 데스크탑 앱을 띄우는 게 아니라 이미 쓰고 있는 터미널 안에서 돕니다. 워프(Warp) 같은 도구가 터미널 자체를 교체하는 것과 대비되는 선택입니다. 무거운 GUI 앱을 하나 더 띄우지 않아도 된다는 점은 실무에서 생각보다 크게 체감됩니다.

숫자로 본 herdr

공개된 지표를 모아 보면 이렇습니다. 자료마다 시점이 달라 숫자가 조금씩 다릅니다.

• 깃허브 스타 — 약 2만 6천 (공식 사이트 기준 25,976, 저장소 기준 26,500+)
• 포크 — 약 1,900
• 누적 설치 — 363,843
• 커뮤니티 플러그인 — 531개
• 현재 버전 — v0.8.0

스타 2만 6천은 적은 숫자가 아닙니다. 다만 버전이 아직 0.8이라는 점을 같이 봐야 합니다. 관심은 크게 모였지만 1.0 이전이라는 뜻이니까요.

라이선스 — Apache 2.0인가 AGPL-3.0인가

확인하다 발견한 불일치가 있어 그대로 적습니다. 1차 출처인 공식 사이트와 깃허브 저장소 README는 모두 Apache 2.0으로 명시합니다.

반면 일부 3자 소개 글은 AGPL-3.0으로 적고 있고, SaaS 맥락에서 수정본을 공개해야 한다는 주의까지 덧붙입니다. 두 라이선스는 상업적 사용 조건이 크게 다릅니다.

회사에서 도입을 검토한다면 저장소의 LICENSE 파일을 직접 확인하시길 권합니다. 3자 요약을 근거로 판단할 사안이 아닙니다.

윈도우 지원 ① ConPTY라는 벽

윈도우 사용자에게는 이 항목이 가장 중요합니다. 결론부터 말하면 윈도우는 베타입니다.

이유는 구조적입니다. 리눅스·macOS는 POSIX 의사 터미널(PTY)을 쓰는데 윈도우는 ConPTY(윈도우 10에 도입)를 씁니다. 완전히 다른 메커니즘이라 플랫폼 전용 작업이 통째로 필요했습니다.

게다가 ConPTY 자체에 알려진 문제가 있습니다 — 지연, 불완전한 VT 시퀀스 지원, TUI 앱이 쓰는 대체 화면 버퍼 문제. 유니코드 렌더링도 달라서 박스 그리기 문자와 이모지에서 레이아웃이 깨질 수 있습니다.

윈도우 지원 ② 지금 되는 것

그래도 베타에서 이미 도는 것들이 꽤 있습니다.

• ConPTY 기반 네이티브 페인
• 세션 지속성
• 윈도우 터미널·파워셸 어태치
• cmd.exe 페인
• 에이전트 명령 탐지
• 페인 화면 히스토리

개인 로컬 용도라면 쓸 만한 수준까지는 올라와 있습니다.

윈도우 지원 ③ 지금 안 되는 것

반대로 걸리는 지점도 명확합니다.

• herdr --remote가 윈도우에서 안 됩니다. 원격 서버에 붙으려면 SSH로 접속해야 합니다
• Shift+Enter는 바깥 터미널이 그 키를 별개의 수정키로 보고해야만 동작합니다
• cd 이후 현재 작업 디렉터리 추적이 불안정합니다
• 이미지 붙여넣기와 CJK IME 조합 위치는 부분 지원입니다
• 커서 깜빡임·튐 때문에 기본값이 커서를 터미널 내용으로 그리는 방식인데, 이 때문에 IME 앵커 위치가 어긋납니다
• 윈도우 ARM64 미지원

메인테이너 본인이 "네이티브 윈도우는 지원하기 어렵고, 베타 기간은 시험이다. 버그를 예상하고 유닉스판과 1:1 기능 대응을 기대하지 말라"는 취지로 못박아 뒀습니다. 완전한 기능 동등성에 대한 일정도 없습니다.

한글 IME를 쓰는 입장에서는 IME 앵커 문제가 실사용에서 가장 거슬릴 가능성이 큽니다. 설정에서 네이티브 커서 모드로 바꾸면 완화되지만, 이번에는 커서가 튀는 문제가 돌아옵니다. 둘 중 하나를 고르는 구조라는 뜻입니다.

설치 방법 정리

플랫폼별로 이렇습니다.

• macOS — brew install herdr
• 리눅스·크로스플랫폼 — curl -fsSL https://herdr.dev/install.sh | sh
• 버전 매니저 — mise use -g herdr
• 윈도우(베타) — 파워셸 설치 스크립트. 프리뷰 채널로만 배포되며 %USERPROFILE%\.herdr\packages\standalone\releases 아래 설치됩니다
• 수동 — 깃허브 릴리스에서 바이너리 내려받기

설치 후 클로드 코드를 붙이려면 herdr integration install claude를 한 번 실행합니다.

⚠️ 참고로 curl | sh나 irm | iex 형태의 원라이너는 내려받은 스크립트를 그대로 실행합니다. 회사 장비라면 스크립트를 먼저 열어 보고 실행하는 편이 안전합니다.

저시력 사용자 관점에서 본 herdr

SVIL 연구소가 이 도구를 볼 때 가장 눈여겨본 지점입니다. herdr의 상태 표시는 접근성 관점에서 양날입니다.

좋은 쪽부터 보면, 확대 배율이 높은 화면에서 페인을 하나씩 열어 보는 비용이 매우 큽니다. 창 하나가 화면을 가득 채우니까요. 상태가 사이드바 한 줄로 요약된다는 건, 스무 번 확대·이동하던 것을 한 번으로 줄여 준다는 뜻입니다. 이건 실질적인 이득입니다.

주의할 쪽도 분명합니다. 상태를 색으로만 구분하면 색 대비가 약한 환경에서 그대로 무력해집니다. SVIL 접근성 기준은 색만으로 상태를 구분하지 않고 텍스트 라벨을 함께 쓰는 것인데, 터미널 UI는 이 원칙을 어기기 쉽습니다. herdr은 테마와 사이드바 동작을 설정할 수 있으니, 도입한다면 상태 표기를 텍스트가 함께 나오도록 맞추는 게 먼저입니다.

마우스 우선 설계도 양면입니다. 단축키 암기 부담을 없앤 건 진입장벽을 낮추지만, 정밀한 드래그가 어려운 사용자에게는 키보드 경로가 여전히 주 통로입니다. Ctrl+B 관습을 그대로 남겨 둔 것이 이 지점에서 의미가 있습니다.

냉정하게 볼 지점

기대만 갖고 도입하면 곤란한 것들입니다.

• 버전 0.8, 1.0 이전입니다. 프로토콜이 올라가면 서버를 재시작해야 합니다
• 클로드 코드의 blocked 감지는 이벤트가 아니라 화면 추론입니다. 정확도에 한계가 있습니다
• 윈도우는 베타이고, 메인테이너가 기능 동등성을 약속하지 않았습니다
• 라이선스 표기가 출처마다 다릅니다. 상업적 도입 전 직접 확인이 필요합니다
• 결국 에이전트를 여러 개 돌리는 사람에게만 가치가 있습니다. 하나만 쓴다면 굳이 필요 없습니다

판단 기준은 문서가 제시한 한 문장으로 충분합니다 — "각 AI 에이전트가 지금 뭘 하고 있는지 실시간으로 알아야 하는가?" 그렇다면 herdr이고, 아니라면 tmux로 충분합니다.

핵심 정리

• herdr은 코딩 에이전트를 위한 터미널 멀티플렉서 겸 백그라운드 런타임이다
• tmux와의 결정적 차이는 각 페인의 에이전트 상태(working·blocked·idle)를 안다는 것
• 상태 감지는 라이프사이클 훅(정확·실시간)과 화면 매니페스트 TOML(추론) 두 가지. 클로드 코드는 아직 후자
• 서버 구조라 노트북을 덮거나 네트워크가 끊겨도 에이전트가 계속 돌고, 재시작 후 레이아웃까지 복원
• 기존 도구를 감싸지 않고 터미널만 소유 — 에이전트 업데이트를 따라갈 필요가 없다
• 19종 에이전트 기본 인식 (클로드 코드·코덱스·커서·제미나이 CLI·코파일럿 CLI 등)
• 마우스 우선 설계 + Ctrl+B tmux 관습 병행
• agent prompt · agent wait로 에이전트가 에이전트를 부리는 오케스트레이션이 셸에서 가능
• CLI와 로컬 소켓 API가 동일 — 사람과 에이전트가 같은 인터페이스를 쓴다
• 러스트 단일 바이너리, 일렉트론 없음. 스타 약 2만 6천, 설치 36만 건, 플러그인 531개, v0.8.0
• 윈도우는 베타 — --remote 불가, IME 앵커·CWD 추적 문제, ARM64 미지원, 기능 동등성 일정 없음
• 라이선스 표기 불일치 — 공식 사이트·README는 Apache 2.0, 일부 3자 글은 AGPL-3.0. 직접 확인 필요

지금 해 볼 것

에이전트를 두 개 이상 돌리고 계신다면 시험해 볼 가치가 있습니다. 순서는 이 정도면 충분합니다.

• 맥·리눅스라면 brew install herdr 또는 설치 스크립트로 시작
• 윈도우라면 베타라는 걸 알고 개인 로컬 용도로만 — 원격 어태치가 필요하면 SSH를 쓴다
• herdr integration install claude로 클로드 코드를 붙이고, 에이전트 두 개를 띄워 blocked 표시가 실제로 잡히는지 먼저 확인
• 쓸 만하다 싶으면 agent prompt와 agent wait로 작은 오케스트레이션 스크립트를 하나 짜 본다 — 여기서 진가가 나옵니다
• 회사 도입이라면 LICENSE 파일 확인이 첫 단계

SVIL 연구소는 클로드 코드·커서·코덱스를 실무에서 함께 돌리고 있어서, herdr을 실제 워크플로우에 붙여 본 뒤 윈도우 베타에서 한글 IME가 어떻게 동작하는지를 포함해 후기를 이어서 정리하겠습니다.

출처

1. herdr 공식 사이트 — the runtime your coding agents live on
2. GitHub — herdrdev/herdr (README·라이선스·통계)
3. herdr 공식 문서 — 개요·핵심 개념
4. herdr 공식 문서 — CLI 레퍼런스
5. herdr 공식 문서 — Windows 베타
6. GitHub Discussion #436 — Windows support (ConPTY 관련 메인테이너 발언)
7. Shareuhack — herdr 2026 실전 가이드 (상태 감지·tmux 비교)
8. Open Intelligence (Medium) — 에이전트 시대의 오픈소스 멀티플렉서 herdr 분석
9. AlternativeTo — herdr 대체 도구 비교

협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://kuroicode-beep.github.io/svil-homepage/