대부분의 AI 코딩 도구들은 여전히 생산성의 단위를 한 명의 엔지니어와 한 명의 에이전트가 짝을 이루는 것으로 간주하며 논의됩니다. 이는 데모용으로는 유용하지만, 실제 워크플로우가 나아가는 방향은 아닙니다.

흥미로운 질문은 터미널 상태(terminal state)나 디프(diff)에 대한 제어력을 잃지 않으면서 여러 에이전트를 계속 움직이게 할 수 있느냐는 것입니다.

그것이 바로 Herdr가 저의 눈길을 끈 이유입니다.

Herdr는 스스로를 에이전트 멀티플렉서(agent multiplexer)라고 설명합니다. 이 차이는 중요합니다. 모든 작업이 일어나는 앱이 되려고 하는 것이 아닙니다. 이는 터미널 지속성 모델(terminal persistence model)에 에이전트 인지(agent awareness) 기능이 추가된, 코딩 에이전트를 위한 tmux에 더 가깝습니다.

작업이 이루어지는 곳, 즉 서버, Mac Mini, VM 또는 원격 개발 머신에서 실행합니다. 에이전트들은 실제 터미널 창(pane)에서 실행됩니다. 노트북을 닫아도 세션은 계속 유지됩니다. 휴대폰을 포함하여 ssh를 통해 다시 연결(reattach)할 수 있습니다.

이것이 바로 에이전트 기반 개발(agentic development)이 나아가는 방향이라고 생각합니다.

복합적인 부분(compounding part)은 마지막 단계입니다.

Herdr는 CLI와 JSON 소켓 API (socket API)를 제공합니다. 문서에는 워크스페이스 (workspaces), 탭 (tabs), 창 (panes)을 생성하고, 명령을 실행하며, 출력을 읽고, 에이전트 (agent)를 기다리는 명령들이 나와 있습니다. 소켓 API는 워크스페이스, 탭, 창, 에이전트, 이벤트 (events), 상태 (state)에 대해 유사한 제어 기능을 제공합니다.

이는 멀티플렉서 (multiplexer)가 인간만을 위한 것이 아니라는 의미입니다. 에이전트 또한 이를 사용할 수 있습니다.

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

이것을 단순히 귀여운 자동화 기술로 읽어서는 안 됩니다. 새로운 형태의 엔지니어링 워크플로 (engineering workflow)로 읽어야 합니다. 감독 에이전트 (supervisor agent)는 창을 생성하고, 보조 에이전트 (helper agents)를 시작하며, 상태를 기다리고, 그들의 출력을 읽고, 인간의 검토가 필요한 사항을 요약할 수 있습니다.

구체적인 워크플로

세 가지 독립적인 작업이 포함된 서비스 마이그레이션 (service migration)을 상상해 보십시오.

에이전트 1은 API 변경, 요청 검증 (request validation), 응답 직렬화 (response serialization), 그리고 계약 테스트 (contract tests)를 담당합니다.

에이전트 2는 데이터베이스 (database) 측면, 마이그레이션 (migration), 시드 데이터 (seed data), 그리고 로컬 통합 테스트 세트 (local integration suite)를 담당합니다.

에이전트 3은 클라이언트 (client) 및 문서 변경, SDK, 예제, 그리고 변경 로그 (changelog)를 담당합니다.

네 번째 에이전트는 감독관 (supervisor) 역할을 합니다. 이 에이전트는 다른 세 에이전트를 별도의 창에서 시작하고, 상태 변화를 기다리며, 창이 차단되거나 완료되었을 때 최근 출력을 읽고, 짧은 조정 노트 (coordination note)를 작성합니다. 에이전트 2가 완료되었지만 에이전트 1이 실패한 계약 테스트로 인해 차단된 경우, 감독관은 해당 문제를 표면화합니다.

인간은 여전히 모든 디프 (diff)를 검토합니다. 인간은 여전히 마이그레이션이 수용 가능한지 결정합니다. 인간은 여전히 머지 (merge)를 소유합니다.

하지만 대기 시간은 달라집니다. 이러한 작업들을 순차적으로 수행하는 대신, 감독관이 인터럽트 (interrupts)를 감시하는 동안 세 개의 스트림 (streams)이 동시에 움직입니다. 각 작업에 에이전트 시간 25분과 인간 검토 시간 5분이 소요된다면, 승리 지점은 "AI가 코드를 작성했다"가 아닙니다. 승리 지점은 75분의 에이전트 시간이 중첩된다는 것입니다.

그것이 바로 실질적인 생산성 승수 (productivity multiplier)입니다. 마법이 아니라 스케줄링 (scheduling)입니다.

비교 분석

가장 유사한 멘탈 모델 (mental model)은 tmux나 Zellij입니다. 이들은 지속적인 터미널 세션 (terminal sessions), 창 (panes), 분리 (detach) 및 재연결 (reattach) 기능을 제공합니다. 매우 훌륭한 도구들이며, 저 역시 여전히 tmux를 좋아합니다. 하지만 이들은 에이전트 (agent)가 무엇인지 알지 못합니다. 코딩 에이전트가 차단되었는지, 완료되었는지, 유휴 상태 (idle)인지, 아니면 여전히 작업 중인지 알려줄 수 없습니다.

데스크톱 에이전트 앱 (Desktop agent apps)은 이와 반대되는 트레이드오프 (tradeoff)를 가집니다. 이들은 종종 에이전트를 인식하며, 더 나은 작업 뷰 (task views)와 더 명시적인 리뷰 흐름 (review flows)을 제공합니다. 대가는 위치입니다. 앱이 GUI가 있는 머신에 상주한다면, 작업은 해당 머신에 종속됩니다. 실제 환경이 서버, Mac Mini, 또는 VM (가상 머신)인 경우에는 이것이 매우 어색합니다. Herdr의 핵심 제안은 런타임 (runtime)이 작업이 발생하는 곳에 존재한다는 것입니다.

워크트리 오케스트레이터 (Worktree orchestrators)는 브랜치 (branches), 워크트리 (worktrees), 체크 (checks), 그리고 리뷰 인터페이스 (review surfaces)와 같은 워크플로우 (workflow)를 직접 소유하기 때문에 강력할 수 있습니다. 트레이드오프는 구조 (structure)입니다. 이는 표준화된 프로세스를 가진 팀에게는 좋을 수 있지만, 오늘 사용 중인 에이전트, 리포지토리 (repo), 또는 작업 형태에 맞춰 유연한 터미널 런타임을 원하는 경우에는 번거로울 수 있습니다.

Herdr가 자동으로 더 나은 것은 아닙니다. Herdr는 더 좁은 범위(narrower)를 다루며 더 유닉스 스타일 (Unix flavored)입니다. 터미널, 창 (panes), ssh, 그리고 디프 (diff) 리뷰에 익숙해야 합니다. 세련된 데스크톱 조종석 (cockpit)을 원한다면 이것은 너무 로우 레벨 (low level)이라고 느껴질 수 있습니다. 티켓 (ticket)부터 PR (Pull Request)까지 관리하는 제품을 원한다면, Herdr는 너무 유연하다고 느껴질 수 있습니다.

괜찮습니다. 저는 자신이 무엇인지 명확히 아는 도구를 선호합니다.

폭발 반경 (blast radius) 또한 병렬화됩니다

경고는 명백하지만 분명하게 말할 가치가 있습니다.

병렬 에이전트는 병렬적인 폭발 반경을 의미합니다.

만약 세 개의 리포지토리에서 광범위한 권한을 가진 세 개의 에이전트를 실행한다면, 출력량 (output)만 늘어나는 것이 아닙니다. 잘못된 명령어나 무모한 셸 명령 (shell command)이 피해를 입힐 수 있는 지점의 수도 늘어나는 것입니다.

Herdr가 엔지니어링적 판단 (engineering judgment)의 필요성을 없애주는 것은 아닙니다. 오히려 그 필요성을 증가시킵니다. 디프 (diff)를 리뷰하십시오. 작업 범위를 제한하십시오 (Keep tasks scoped). 에이전트에게 권한을 무심코 우회하여 넘겨주지 마십시오. 비밀 정보 (secrets)와 운영 환경 (production) 접근 권한을 다룰 때는 주의하십시오.

이것이 바로 제가 숙련된 엔지니어들이 Herdr를 통해 가장 큰 이점을 얻는다고 생각하는 이유입니다. 누구나 실행할 수는 있지만, 진정한 레버리지(leverage)는 작업을 안전하게 분할하는 방법, 무엇을 위임할지, 언제 개입할지, 그리고 어떻게 검증할지를 아는 데서 나옵니다. 만약 당신이 이미 자동화 경계(automation boundaries)와 실패 모드(failure modes)를 고려하며 사고한다면, Herdr의 API는 특히 흥미로울 것입니다.

Herdr는 판단력(judgment)을 대체하는 것이 아닙니다. 적절한 시기에 적절한 영역에 판단력을 쏟을 수 있게 해주는 방법입니다.

저에게 있어, 이것이 AI 코딩 처리량(throughput)에 대한 더 솔직한 이야기입니다. 미래는 단 하나의 에이전트가 당신의 업무를 완벽하게 수행하는 모습이 아닙니다. 그것은 지속성(persistence), 상태(state), 그리고 인간이 소음(noise) 위에서 머무를 수 있을 만큼 충분한 감독(supervision) 기능을 갖춘 여러 개의 불완전한 에이전트들이 병렬로 실행되는 모습입니다.

이는 일반적인 AI 생산성 홍보 문구보다 덜 마법처럼 들립니다. 또한 실제 엔지니어링 작업에 훨씬 더 가깝게 느껴집니다.

참고 문헌 (References)

• Herdr
• Compare Herdr
• Herdr socket API
• Herdr agent skill file
• herdrdev/herdr on GitHub
• Herdr releases

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