코딩 에이전트(Coding Agents)에 관한 대부분의 대화는 여전히 단일 에이전트(One-agent) 사고 모델에 갇혀 있습니다.

당신은 에이전트에게 작업을 부여합니다. 에이전트는 파일을 수정합니다. 당신은 차이점(diff)을 검토합니다. 어쩌면 작동할 수도 있고, 그렇지 않을 수도 있습니다. 유용하지만, 여전히 직렬적(serial)인 작업입니다.

흥미로운 질문은 처리량(throughput)입니다.

여러 에이전트를 동시에 실행하고, 세션(session)을 유지하며, 어떤 에이전트가 주의를 필요로 하는지 파악하고, 다른 에이전트가 전체 과정을 조정하게 할 수 있다면 어떤 일이 벌어질까요?

그것이 바로 Herdr를 살펴볼 가치가 있는 관점입니다. Herdr는 또 다른 코딩 앱이 되려는 것이 아닙니다. 이것은 에이전트 멀티플렉서(agent multiplexer)입니다. 가장 유사한 사고 모델은 코딩 에이전트를 위한 tmux이며, 단순한 터미널 창의 집합 그 이상이 될 수 있을 만큼 충분한 에이전트 인지 능력을 갖추고 있습니다.

작업이 일어나는 곳에서 실행됩니다

Herdr는 데스크톱 앱이 아닌 바이너리(binary)입니다. 실제 작업이 존재하는 머신, 즉 개발 서버(dev server), Mac Mini, 샌드박스 VM(sandbox VM), 또는 저장소(repo)와 자격 증명(credentials)이 있는 곳이라면 당신의 노트북에서 실행할 수 있습니다.

작업이 서버에 있다면 Herdr는 서버에서 실행됩니다. 노트북을 닫아도 창(panes)은 계속 실행됩니다. SSH 연결이 끊어져도 에이전트는 함께 사라지지 않습니다. 나중에 일반 터미널, 다른 머신, 또는 심지어 휴대폰 SSH 클라이언트에서 다시 연결(reattach)할 수 있습니다.

ssh you@workbox
herdr

이것은 AI 코딩 작업에 적용된 기존 tmux의 약속입니다: 분리(detach), 재연결(reattach), 프로세스 유지. 차이점은 Herdr가 해당 창 내부에서 일어나고 있는 일에 대해 더 많이 알고 있다는 것입니다: 실제 PTY, 지속적인 세션(persistent sessions), 차단됨(blocked), 작업 중(working), 완료(done), 유휴(idle) 상태, 그리고 CLI 및 소켓(socket) API를 알고 있습니다.

그 조합이 바로 제품입니다.

승수(Multiplier)는 마법이 아니라 큐잉(Queueing)입니다

Herdr의 성능 논거는 간단합니다: 병렬성(parallelism)과 컨텍스트 손실 제로(zero context loss)의 결합입니다.

만약 나에게 백엔드 버그를 수정하는 에이전트 하나, 문서를 업데이트하는 에이전트 하나, 그리고 불안정한 테스트(flaky test)를 조사하는 에이전트 하나가 있다면, 나는 취약한 세 개의 터미널 창을 원하는 것이 아닙니다. 나는 가시적인 상태를 가진 세 명의 내구성 있는 작업자를 원합니다.

Herdr는 각 에이전트에게 실제 터미널 창(terminal pane)을 제공합니다. 에이전트 UI를 웹 대시보드로 재구축하는 방식이 아닙니다. 사용자의 셸(shell), 키 바인딩(keybindings), 터미널, 그리고 명령줄 에이전트(command-line agents)가 그대로 유지됩니다. 게다가 Herdr는 의미론적 상태(semantic state)를 추적하므로, 사람은 모든 창을 일일이 확인할(poll) 필요가 없습니다.

운영 루프(operational loop)는 다음과 같이 변화합니다:

기존:

1. 터미널 A를 응시함
2. 터미널 B로 Alt-Tab 전환
3. 터미널 C가 차단(blocked)되었는지 의구심을 가짐
4. 세션이 종료되면 전체 실행 과정을 놓침

변경 후:

1. 독립적인 작업을 시작함
2. 차단되거나 완료된 상태를 관찰함
3. 개입이 필요한 창만 검토함
4. 급한 일이 생기면 분리(detach)하고, 준비되면 다시 연결(reattach)함

이것이 기본적인 처리량(throughput)입니다. 인간 감독자는 보육자(babysitter)보다는 스케줄러(scheduler)에 가까워집니다.

API에서 복리 효과가 발생합니다

소켓 API(socket API)는 워크스페이스(workspaces), 탭(tabs), 창(panes), 에이전트(agents), 이벤트(events), 읽기(reads), 프롬프트(prompts), 대기(waits), 그리고 상태 변경(state changes)을 다룹니다. CLI는 설치된 바이너리에 맞는 스키마(schema)를 출력합니다:

herdr api schema --json

문서에는 다음과 같이 나와 있습니다:

herdr workspace create --cwd ~/src/payments --label payments
herdr pane split w1:p1 --direction right
herdr pane run w1:p2 "npm test"
...

Herdr는 에이전트 스킬 파일(agent skill file)도 함께 제공합니다. 에이전트가 Herdr로 관리되는 창 내부에서 실행될 때, HERDR_ENV=1이 설정되며, 이 스킬은 에이전트에게 인접한 창을 조사하고, 창을 분할하고, 명령을 실행하고, 출력을 읽고, 테스트를 기다리고, 보조 에이전트(helper agents)를 시작하는 방법을 알려줍니다.

이것이 바로 복리(compounding)가 일어나는 지점입니다. 일단 에이전트가 에이전트를 호스팅하는 시스템을 제어할 수 있게 되면, "사람이 세 개의 프롬프트를 시작하는" 단계를 넘어 감독된 오케스트레이션(supervised orchestration)으로 나아갈 수 있습니다.

구체적인 3개 에이전트 워크플로

다음은 제가 실제로 사용할 워크플로입니다.

감독(supervisor) 에이전트가 계획을 소유합니다. 이 에이전트는 작업을 분할하고 다른 창들을 모니터링합니다.

에이전트 1은 API 리포지토리(repo)의 제품 코드 변경을 담당합니다.

에이전트 2는 테스트를 업데이트하고 관련 테스트 스위트(suite)를 실행합니다.

에이전트 3은 별도의 워크트리(worktree)나 리포지토리에서 문서 또는 마이그레이션 노트를 업데이트합니다.

감독 에이전트는 창들을 시작하고, 각 에이전트에게 좁은 범위의 작업(narrow task)을 프롬프트로 전달한 뒤 대기합니다.

herdr workspace create --cwd ~/src/platform --label platform

herdr pane split w1:p1 --direction right
...

그 다음 감독(supervisor)은 상태를 관찰합니다. 만약 에이전트 2가 피스처(fixture)가 변경되어 차단(blocked)되었다면, 해당 창(pane)을 읽고 에이전트 1에게 새로운 계약(contract)을 요청합니다. 만약 에이전트 3이 일찍 작업을 마친다면, 문서(documentation)가 구현(implementation)과 일치하는지 확인합니다. 세 에이전트가 모두 완료되면, 사람이 결합된 변경 사항을 검토합니다.

이것이 판단(judgment)을 없애는 것은 아닙니다. 판단의 위치를 작업 경계(task boundaries), 의존성 관리(dependency management), 차이 검토(diff review), 그리고 최종 통합(final integration) 단계로 옮기는 것입니다.

Herdr의 위치

tmux 및 Zellij와의 비교는 명확합니다. 그것들은 이미 지속성(persistence), 창 관리(pane management), 그리고 SSH 워크플로를 해결합니다. 하지만 그것들은 에이전트를 이해하지 못합니다. 스크립트로 제어할 수는 있지만, 특정 창이 승인을 기다리는 중인지, 여전히 생각 중인지, 아니면 완료되었는지는 알지 못합니다.

데스크톱 에이전트 앱들은 정반대의 형태를 띱니다. 에이전트를 인식(agent-aware)할 수 있고 사용하기 편리한 것들도 있지만, 주로 GUI 머신에 머무는 경향이 있습니다. 로컬 환경에서는 괜찮지만, 본격적인 작업이 서버, VM, 또는 어디서든 다시 연결(reattach)하고 싶은 머신에서 이루어질 때는 적절하지 않습니다.

워크트리 오케스트레이터(Worktree orchestrators) 또한 유용합니다. 브랜치(branches), 작업(tasks), 그리고 검토 흐름(review flow)을 관리할 수 있습니다. 트레이드오프(tradeoff)는 그것들이 종종 워크플로 자체를 소유(own)한다는 점입니다. Herdr는 더 낮은 수준(lower-level)의 느낌을 줍니다. 사용자가 자신의 에이전트, 터미널, 리포지토리 레이아웃(repo layout), 그리고 프로세스를 직접 가져옵니다. 이러한 유연성이 매력적이지만, 이미 자신이 어떻게 일하고 싶은지 알고 있는 사람들에게 더 큰 보상을 제공합니다.

솔직한 권장 사항은 다음과 같습니다: Herdr는 숙련된 엔지니어에게 가장 적합합니다. 누구나 실행할 수는 있지만, 이를 통해 가장 큰 이득을 얻는 사람들은 작은 작업을 설계하고, 병렬 작업(parallel work)을 감독하며, 차이(diffs)를 빠르게 읽고, 모든 워크플로를 의도치 않은 플랫폼으로 만들지 않으면서 API를 사용할 수 있는 사람들일 것입니다.

병렬 에이전트는 또한 병렬적인 폭발 반경(blast radius)을 의미합니다. 만약 광범위한 권한을 가진 세 개의 에이전트를 실행한다면, 한 번에 세 개의 잘못된 차이(diffs)를 얻을 수도 있습니다. 변경 사항을 검토하십시오. 작업 범위를 제한(scoped)하십시오. 우회 권한 모드(bypass permissions modes)를 사용할 때는 주의하십시오.

그것이 바로 제가 "앱이 아닌 멀티플렉서(multiplexer, not app)"라는 프레임워크를 좋아하는 이유입니다. Herdr는 엔지니어링적 판단(engineering judgment)을 해결하는 척하지 않습니다. 대신, 그 판단을 적용할 수 있는 더 나은 제어 평면(control plane)을 제공합니다.

references

• Herdr
• Herdr comparison page
• Herdr socket API docs
• Herdr agent skill docs
• herdrdev/herdr on GitHub
• Herdr releases

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