대부분의 AI 코딩 도구들은 여전히 한 명의 인간이 하나의 에이전트가 수행하는 하나의 작업을 지켜보는 아이디어를 중심으로 설계되어 있습니다.

그것은 유용하지만, 더 이상 흥미로운 부분은 아닙니다.

흥미로운 부분은 에이전트를 자동 완성 (autocomplete) 기능으로 취급하는 것을 멈추고, 하나의 작업 프로세스 (worker process)로 취급하기 시작할 때부터 시작됩니다. 작업 경계가 명확할 때, 에이전트는 오래 실행되고, 중단 가능하며, 때로는 틀리기도 하지만 대개 유용합니다.

이것은 병목 현상 (bottleneck)을 변화시킵니다.

병목 현상은 더 이상 에이전트가 파일을 편집할 수 있는지 여부가 아닙니다. 에이전트는 할 수 있습니다. 병목 현상은 상태를 잃거나 질문을 놓치지 않으면서 여러 개의 에이전트 작업 조각들을 당신이 감독할 수 있는지 여부입니다.

이것이 바로 Herdr가 내 관심을 끈 이유입니다.

Herdr는 또 다른 코딩 앱이 아닙니다. 그것은 에이전트 멀티플렉서 (agent multiplexer)입니다. 가장 짧은 설명은 아마도 다음과 같을 것입니다: 코딩 에이전트를 위한 tmux.

중요한 점은 그것이 실행되는 위치입니다

Herdr는 작업이 발생하는 곳에서 실행됩니다.

그곳은 당신의 노트북, Mac Mini, 개발 서버, 또는 적절한 자격 증명과 의존성 (dependencies)을 갖춘 VM (가상 머신)이 될 수 있습니다. 그곳에서 Herdr를 시작하고, 실제 터미널 창 (terminal panes) 안에서 에이전트를 실행한 다음, 분리 (detach)하고 나중에 다시 돌아오면 됩니다.

Herdr는 백그라운드 세션 서버 (background session server)를 가지고 있기 때문에 창들은 계속 실행됩니다. 클라이언트는 단지 세션을 렌더링하는 도구일 뿐입니다. 노트북을 닫고, 터미널 창을 잃어버리고, 기기를 전환하고, 다시 SSH로 접속하여 herdr를 실행하면 세션은 여전히 그곳에 있습니다.

Herdr 문서는 이를 매우 직접적으로 설명합니다:

ssh you@server
herdr

이것은 들리는 것보다 더 중요합니다.

데스크톱 에이전트 앱들은 세련되게 느껴질 수 있지만, 대개 GUI를 실행하는 머신에 종속되어 있습니다. 클래식한 터미널 멀티플렉서 (terminal multiplexers)는 SSH 연결 끊김에서 살아남지만, 3번 창은 차단되어 있고 5번 창은 완료되었다는 사실은 알지 못합니다.

Herdr는 그 중간에 위치합니다: 실제 PTY, 터미널 네이티브 지속성 (terminal-native persistence), 그리고 에이전트 인지 (agent awareness)를 갖추고 있습니다.

처리량 (throughput)은 병렬성 (parallelism)과 컨텍스트 손실 제로 (zero context loss)에서 나옵니다

에이전트를 통한 생산성 이야기는 종종 잘못 전달되곤 합니다.

사람들은 프롬프트를 보여주고, 에이전트가 코드를 작성하면, 그 결과물이 인상적인지에 대해 모두가 논쟁하곤 합니다. 그것은 잘못된 분석 단위입니다. 하나의 작업을 수행하는 단일 에이전트는 여전히 직렬 작업 (serial work)입니다.

승수 효과 (multiplier)는 병렬 감독 (parallel supervision)에서 나옵니다.

Herdr는 다음과 같은 기능을 제공합니다:

• 실제 PTY에서 작동하는 N개의 에이전트, 각 에이전트는 자신만의 작업 또는 리포지토리 (repo)에서 작업
• 차단됨 (blocked), 작업 중 (working), 완료 (done), 유휴 (idle)와 같은 의미론적 상태 (semantic state)
• 지속적인 세션 (persistent sessions), 따라서 터미널 충돌이 발생해도 실행 내용이 삭제되지 않음
• CLI 및 소켓 API (socket APIs), 에이전트와 스크립트도 멀티플렉서 (multiplexer)를 조작할 수 있음

마지막 포인트가 바로 흥미로운 부분입니다.

Herdr는 단순히 사이드바가 더 예쁜 창 관리자 (pane manager)가 아닙니다. 소켓 API는 워크스페이스 (workspaces), 탭 (tabs), 창 (panes), 에이전트 (agents), 이벤트 (events), 대기 (waits)를 노출합니다. CLI는 이러한 기능들을 스크립트와 에이전트로부터 유용하게 사용할 수 있게 해줍니다.

예를 들어:

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

중요한 세부 사항은 agent wait가 단순히 셸 명령어가 종료되었는지 여부뿐만 아니라 에이전트의 상태를 관찰한다는 점입니다. 감독자 (supervisor)는 에이전트가 완료되거나 차단될 때까지 기다린 후, 출력을 읽고 다음 행동을 결정할 수 있습니다.

이것이 "많은 터미널을 열어두고 있다"와 "코딩 작업을 위한 작은 실행 구조 (execution fabric)를 갖추고 있다"의 차이입니다.

구체적인 워크플로 (workflow)

평범한 플랫폼 엔지니어링 (platform engineering)의 아침을 상상해 보세요. 마법 같은 일은 아닙니다. 그저 순차적으로 실행하기에는 번거로운 세 가지 작은 작업이 있을 뿐입니다.

에이전트 1은 API 서비스의 버그를 수정합니다.

에이전트 2는 스테이징 환경 (staging environment)을 위한 Terraform을 업데이트합니다.

에이전트 3은 다른 리포지토리의 불안정한 테스트 (flaky test)를 조사합니다.

감독자 에이전트 (supervisor agent)는 네 번째 창에 자리 잡고 있습니다. 이 에이전트의 역할은 이 무리 (herd)를 조정하는 것입니다.

이 에이전트는 창을 분할하고, 에이전트를 시작하며, 상태 변화를 기다리고, 출력을 읽을 수 있습니다:

herdr pane split w1:p1 --direction right
herdr pane run w1:p2 "codex 'fix the pagination bug and run the API tests'"

...

그 다음 감독자는 기다립니다:

herdr agent wait w1:p2 --until blocked
herdr agent wait w1:p3 --until done
herdr agent wait w1:p4 --until done

이것은 리뷰가 사라지는 척하는 것에 관한 것이 아닙니다. 리뷰는 더욱 중요해집니다. 다만 당신의 주의력이 가장 느린 작업에 갇히지 않게 하는 것입니다.

만약 에이전트 2가 Terraform을 먼저 완료하면, 당신은 diff (차이점)를 검사합니다. 만약 에이전트 1이 모호한 API 동작으로 인해 차단(block)되면, 당신은 해당 창(pane)에 답변합니다. 만약 에이전트 3이 테스트 설정에서 레이스 컨디션 (race condition)을 발견하면, 당신은 에이전트가 테스트를 수정하게 둘지, 아니면 중단하고 해당 발견 사항을 기록할지 결정합니다.

이득은 "세 명의 에이전트가 완벽한 코드를 작성한다"는 것이 아닙니다.

이득은 에이전트 중 하나가 일시 중지될 때마다 발생하는 컨텍스트 손실 세금 (context loss tax)을 지불하지 않아도 된다는 것입니다.

비교 분석

Herdr는 그 정신에 있어 tmux 또는 Zellij와 가장 유사합니다. 터미널 세션 (terminal sessions), 창 (panes), 탭 (tabs), 그리고 원격 접속 (remote attach)을 유지합니다. 만약 당신에게 필요한 것이 지속적인 셸 (persistent shells)뿐이라면, tmux는 이미 검증되었으며 아마도 충분할 것입니다.

하지만 tmux와 Zellij는 에이전트를 이해하지 못합니다. 어떤 창이 차단되었는지, 작업 중인지, 완료되었는지, 혹은 유휴 (idle) 상태인지 알려줄 수 없습니다. 그것들은 터미널 멀티플렉서 (terminal multiplexers)이지, 에이전트 멀티플렉서 (agent multiplexers)가 아닙니다.

데스크톱 에이전트 앱들은 다른 문제를 해결합니다. 그것들은 에이전트를 인식할 수 있고 사용하기 편리하며, 특히 워크플로 (workflow)가 하나의 리포지토리 (repo)와 하나의 머신에 집중되어 있을 때 유용합니다. 트레이드오프 (tradeoff)는 위치입니다. 만약 GUI 머신이 작업이 이루어지는 곳에 없다면, 결국 워크플로를 다시 당신의 데스크톱으로 끌어오게 됩니다.

워크트리 오케스트레이터 (Worktree orchestrators) 또한 유용합니다. 어떤 것들은 브랜치 (branch), diff, PR, 그리고 리뷰 흐름을 엔드 투 엔드 (end to end)로 관리합니다. 이는 관리형 워크플로를 원할 때 매우 훌륭할 수 있습니다. 하지만 이미 자신만의 리포지토리 레이아웃, 스크립트, 터미널, SSH 습관, 그리고 독특한 로컬 관례를 가지고 있다면 매력이 덜할 수 있습니다. Herdr는 워크트리와 함께 사용할 수 있지만, 전체 프로세스를 소유할 필요는 없습니다.

트레이드오프는 Herdr가 당신이 실제 프로세스를 감독하는 데 익숙하다고 가정한다는 점입니다. 이는 숙련된 엔지니어에게는 기능(feature)이지만, 부주의한 엔지니어에게는 풋건 (footgun, 실수하기 쉬운 요소)입니다.

누가 사용해야 하는가

숙련된 엔지니어들이 Herdr를 통해 가장 큰 이득을 얻을 것입니다.

초보자가 실행할 수 없기 때문이 아닙니다. 그들도 실행할 수 있습니다:

curl -fsSL https://herdr.dev/install.sh | sh
herdr

시니어급 인력들이 더 많은 이득을 얻습니다. 왜냐하면 병렬성 (Parallelism)은 작업을 분해하고, 경계를 정의하며, 차이점 (Diffs)을 평가하고, 에이전트가 확신에 차서 틀렸을 때를 알아챌 수 있을 때만 도움이 되기 때문입니다.

병렬 에이전트는 또한 병렬적인 폭발 반경 (Blast radius)을 의미합니다.

만약 광범위한 파일 시스템 접근 권한과 권한 우회 기능을 가진 세 개의 에이전트를 실행한다면, 당신은 검토하지 않았을 수도 있는 것들을 수정할 수 있는 세 가지 빠른 방법을 만든 셈입니다. 이는 일회성 저장소 (Disposable repo), 깨끗한 워크트리 (Clean worktree), 또는 컨테이너 (Container) 환경에서는 괜찮을 수 있습니다. 하지만 주변 자격 증명 (Ambient credentials)이 존재하는 프로덕션 인프라 (Production infrastructure)에서는 괜찮지 않습니다.

저의 실무적인 규칙은 다음과 같습니다: Herdr은 각 에이전트가 명확한 작업, 제한된 작업 디렉토리 (Working directory), 그리고 검증 명령어를 가질 때 의미가 있습니다. 모든 차이점 (Diff)을 검토하세요. 위험한 권한은 지루할 정도로 단순하게 유지하세요. 차단된 상태를 밀어붙여야 할 짜증 나는 요소가 아니라 유용한 신호로 취급하세요.

references

• Herdr
• Compare Herdr
• Herdr socket API
• Herdr agent skill file
• Herdr GitHub repository
• Herdr releases

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