대부분의 에이전트 도구는 여전히 단일 대화(single conversation)를 중심으로 구축되어 있습니다. 즉, 하나의 에이전트, 하나의 작업, 하나의 터미널, 그리고 관리해야 할 하나의 스트림(stream)을 의미합니다. 작은 작업에는 괜찮지만, 실제 엔지니어링 작업에는 부적합합니다.

Herdr가 흥미로운 이유는 그것을 작업의 기본 형태(default shape)로 취급하기 때문입니다.

가장 간단하게 설명하자면 다음과 같습니다: Herdr는 코딩 에이전트를 위한 tmux입니다. 더 정확하게 말하면, 기존 터미널 내부에서 실행되는 에이전트 멀티플렉서(agent multiplexer)입니다. 각 에이전트에게 실제 PTY를 제공하고, 작업이 진행 중인 프로세스를 유지하며, 에이전트 상태를 보여주고, CLI 및 로컬 소켓 API(local socket API)를 노출합니다.

이러한 차이점은 중요합니다. Herdr는 또 다른 데스크톱 에이전트 앱이 아닙니다. 코드와 터미널이 존재하는 곳에서 실행하는 바이너리입니다: 서버, Mac Mini, VM, 또는 책상 아래의 개발용 머신 등 말이죠. 노트북을 닫고, 분리(detach)한 뒤, 나중에 다시 ssh로 접속하여 재연결(reattach)할 수 있으며, 심지어 휴대폰에서도 가능합니다. 터미널 창이 닫혔다고 해서 작업이 중단되지 않습니다.

처리량(Throughput) 문제

코딩 에이전트는 작업을 시작하는 비용을 변화시켰습니다. 저는 한 에이전트에게 버그를 탐색하게 하고, 다른 에이전트에게는 실패하는 테스트를 작성하게 하며, 또 다른 에이전트에게는 마이그레이션 계획(migration plan) 초안을 작성하도록 요청할 수 있습니다. 병목 현상은 바로 감독(supervision)입니다.

문제는 일반적인 터미널이 감독(supervision)을 이해하지 못한다는 점입니다. tmux와 Zellij는 지속성(persistence)과 창 분할(panes)을 제공하지만, 에이전트가 차단(blocked)되었는지, 작업 중인지, 완료되었는지, 유휴(idle) 상태인지, 아니면 세 화면 전쯤 질문을 출력한 후 그냥 가만히 있는 것인지는 알지 못합니다. 데스크톱 앱들은 종종 에이전트 상태를 더 잘 이해하지만, 그 경우 워크플로(workflow)가 GUI가 있는 머신에 종속됩니다. 워크트리 오케스트레이터(Worktree orchestrators)는 병렬 작업을 조정할 수 있지만, 대개 워크플로 자체를 소유하려고 합니다.

Herdr는 유용한 중간 지점에 위치합니다: 터미널 모델에 에이전트 인지(agent awareness)를 더한 형태입니다.

성능 승수(performance multiplier)는 마법이 아닙니다. 그것은 네 가지 실질적인 특성에서 나옵니다:

1. 여러 에이전트가 실제 PTY (Pseudo-terminal)에서 실행되며, 각 에이전트는 자신만의 쉘 (shell), 로그 (logs), 프롬프트 (prompts) 및 프로세스 상태 (process state)를 가집니다.
2. Herdr는 의미론적 상태 (semantic state)를 통합하므로, 어떤 에이전트가 차단 (blocked), 작업 중 (working), 완료 (done) 또는 유휴 (idle) 상태인지 확인할 수 있습니다.
3. 서버가 창 (panes)을 소유하므로, 클라이언트 분리 (client detach), 노트북 절전 모드, 터미널 종료 후에도 세션이 유지됩니다.
4. CLI 및 소켓 API (socket API)를 통해 스크립트나 에이전트가 멀티플렉서 (multiplexer)를 직접 제어할 수 있습니다.

네 번째 포인트가 제가 가장 중요하게 생각하는 부분입니다. 세 개의 창을 감독하는 인간은 유용합니다. 하지만 보조 에이전트를 시작하고, 출력을 읽고, 상태 전이 (state transitions)를 기다리며, 결과를 통합할 수 있는 에이전트야말로 복리 효과 (compounding)가 시작되는 지점입니다.

Herdr의 문서는 이에 대해 명시적으로 설명하고 있습니다. 소켓 API (socket API)는 워크스페이스 (workspaces), 탭 (tabs), 창 (panes) 및 에이전트 (agents)를 관리할 수 있습니다. 권장되는 경로는 먼저 CLI 래퍼 (wrappers)를 사용하는 것이며, 그 다음 직접적인 요청-응답 (request-response) 제어 또는 구독 (subscriptions)을 위해 로우 소켓 API (raw socket API)를 사용하는 것입니다. 또한 HERDR_ENV=1에 의해 보호되는 에이전트 스킬 파일 (agent skill file)이 있어, 에이전트가 창 (pane) 내부에서 Herdr를 사용하는 방법을 학습할 수 있습니다.

구체적인 워크플로 (workflow)

리팩터링 (refactor)을 감독하는 스태프 엔지니어 (staff engineer)를 상상해 보세요: 내부 클라이언트 교체, 테스트 조정, 배포 확인 작업을 수행합니다. 저는 이를 분할하겠습니다.

한 명의 감독자 (supervisor)가 계획과 검토를 담당합니다. 감독자는 세 개의 창을 생성합니다:

herdr

Herdr 내부에서, 감독자는 창을 분할하고 에이전트를 시작할 수 있습니다:

split=$(herdr pane split --current --direction right --no-focus)
api_pane=$(printf '%s\n' "$split" | jq -r '.result.pane.pane_id')

...

그 다음 두 개의 에이전트를 더 시작합니다:

test_split=$(herdr pane split --current --direction down --no-focus)
test_pane=$(printf '%s\n' "$test_split" | jq -r '.result.pane.pane_id')

...

감독자는 터미널을 폴링 (polling)하는 대신 상태 (state)를 기다립니다:

herdr agent wait api-change --until blocked --timeout 120000
herdr agent read api-change --source recent-unwrapped --lines 80

또는 일반적인 프로세스 출력의 경우:

herdr pane run w1:p3 "just test --watch"
herdr pane wait-output w1:p3 --regex "passed|failed" --timeout 120000

사람은 한 단계 위로 올라갑니다: diff(차이점)를 검토하고, 차단된 에이전트(agent)에게 답변하며, 잘못된 접근 방식을 거부하고, 테스트를 판단하며, 프로덕션(production)에 반영되기 전에 피해 범위(blast radius)를 차단합니다.

병렬성(Parallelism)과 컨텍스트 손실 제로

병렬성(Parallelism)만으로는 충분하지 않습니다. 터미널 다섯 개를 여는 것은 쉽습니다. 하지만 점심 식사 후에 그것들을 여전히 이해할 수 있는 상태로 유지하는 것이 어려운 부분입니다.

Herdr가 작동하는 이유는 병렬 실행(parallel execution)을 지속성(persistence) 및 상태(state)와 결합하기 때문입니다. 만약 에이전트(agent)가 차단되면, 그 상태가 가시적으로 보입니다. 당신이 첫 번째 에이전트를 검토하는 동안 다른 에이전트가 완료되면, 검토될 때까지 '완료'로 표시됩니다. 만약 ssh 연결이 끊어지더라도, 서버가 pane(창)과 프로세스(process)를 계속 소유합니다.

지속성(persistence)이 없다면, 추가되는 에이전트마다 오버헤드(overhead)가 발생합니다. 지속적인 pane과 상태(state)가 있다면 오버헤드는 줄어듭니다. 리포지토리(repo), 가설(hypothesis), 또는 전략(strategy)당 하나의 에이전트를 실행할 수 있으며, 필요할 때만 주의를 기울이면 됩니다.

비교 및 트레이드오프(tradeoffs)

Herdr는 사고 모델(mental model) 측면에서 tmux나 Zellij와 가장 유사합니다. 지속적인 pane과 원격 재연결(remote reattach) 기능을 제공하지만, 에이전트 상태(agent state)와 에이전트 형태의 제어 인터페이스(control surface)를 추가합니다. 이미 tmux를 사용 중이라면, 해당 계층을 위해 더 젊은 도구를 채택하는 셈입니다.

데스크톱 에이전트 앱과 비교했을 때, Herdr는 덜 다듬어져 있지만 엔지니어링 작업이 실제로 어디에서 일어나는지에 대해 더 정직합니다. 작업용 박스(work box) 위의 터미널 멀티플렉서(terminal multiplexer)는 노트북을 닫아도 살아남습니다.

worktree 오케스트레이터(orchestrators)와 비교했을 때, Herdr는 덜 독단적(less opinionated)입니다. 작업 할당, worktree 생명주기(lifecycle), 검토 흐름(review flow), 그리고 머지 정책(merge policy)을 관리하는 제품을 원한다면 오케스트레이터를 사용하십시오. 에이전트, 셸(shell), 테스트 와처(test watchers), 로그(logs), 그리고 감독 스크립트(supervisor scripts)가 공존하는 유연한 런타임(runtime)을 원한다면 Herdr가 더 적합한 형태입니다.

실제적인 위험도 존재합니다. 병렬 에이전트(Parallel agents)는 병렬적인 피해 범위(parallel blast radius)를 의미합니다. 만약 광범위한 우회 권한(bypass permissions)을 가진 에이전트를 실행한다면, 그들은 모두 동시에 잘못된 수정을 가할 수 있습니다. 여전히 git 규율, 작은 프롬프트(prompts), 격리된 worktree, diff 검토, 그리고 테스트 우선(test-first) 확인이 필요합니다.

저는 이를 숙련된 엔지니어들에게 가장 강력하게 추천합니다. 누구나 몇 개의 창을 열 수는 있겠지만, 이 API는 작업을 분할하고, 경계를 정의하며, 패치(patches)를 검토하고, 의심스러운 변경 사항을 포착할 줄 아는 사람들에게 보상을 제공합니다.

나의 견해

현재 세대의 코딩 에이전트(coding agents)는 모델의 품질에 의해서만 제한되는 것이 아닙니다. 이는 런타임 인체공학(runtime ergonomics)에 의해 제한됩니다.

단일 채팅 에이전트 워크플로(Single-chat agent workflows)는 모든 작업을 선형적으로 느끼게 만듭니다. 실제 엔지니어링 작업은 조사, 테스트, 검토, 실패한 시도, 로그, 그리고 결정들이 얽힌 그래프(graph) 형태입니다. Herdr의 도박은 적절한 인터페이스가 더 예쁜 채팅창이 아니라는 점에 있습니다. 그것은 지속성(persistence), 상태(state), 그리고 API를 갖춘 터미널 네이티브 런타임(terminal-native runtime)입니다.

Herdr가 판단력, 코드 리뷰(code review), 또는 미적 감각(taste)을 대체하지는 않을 것입니다. 기본적으로 모든 엔지니어를 기본적으로 세 배 더 빠르게 만들어 주지도 않을 것입니다. 하지만 이미 에이전트를 적극적으로 활용하고 있는 엔지니어들에게, Herdr는 문맥(context)을 잃지 않으면서도 여러 작업 스트림(workstreams)을 살아있게 하고, 가시화하며, 제어할 수 있게 해줍니다.

처리량(throughput)은 바로 그 지점에서 나옵니다. 한 명의 에이전트가 팀인 것처럼 가장하는 것이 아니라, 한 명의 엔지니어에게 여러 에이전트를 위한 합리적인 제어 표면(control surface)을 제공하고, 그것을 사용할 만큼 충분히 규율을 갖추는 것에서 나옵니다.

참고 문헌

• Herdr 홈페이지
• Herdr 비교
• Herdr Socket API
• Herdr 에이전트 스킬 파일 문서
• Herdr GitHub 저장소

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작하기 위해 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.