Herdr을 이용한 바이브 코딩

제가 말하는 바이브 코딩은 요구사항을 한 문장 던지고 결과를 믿는 방식이 아닙니다. 사람이 목표와 경계를 정하고, 에이전트에게 조사·구현·검토를 나눠 맡긴 뒤, 마지막 판단은 diff와 테스트로 닫는 방식에 가깝습니다. AI가 코드를 빨리 만드는 것보다 어느 작업이 진행 중이고, 어디서 멈췄고, 무엇을 아직 읽지 않았는지 한 화면에서 놓치지 않는 것이 더 중요해졌습니다.

그래서 지금은 Herdr를 작업의 조종석으로 씁니다. Herdr는 코드를 대신 작성하는 모델이 아니라 터미널 pane마다 실행한 코딩 에이전트를 인식하고, working·blocked·done 같은 상태를 모아 보여 주는 멀티플렉서입니다. 이 차이는 작아 보여도 세션이 서너 개를 넘는 순간 꽤 크게 느껴집니다.

herdr.dev · officialHerdr — 코딩 에이전트를 위한 터미널 런타임실제 터미널을 유지하고 여러 코딩 에이전트의 pane과 상태를 한 workspace에서 관리하는 공식 페이지입니다.공식 페이지

다만 먼저 선을 그어야 합니다. 상태값은 품질 점수가 아니며, pane 수도 생산성 지표가 아닙니다. Herdr가 알려 주는 것은 “어디를 봐야 하는가”까지입니다. “이 결과가 맞는가”는 여전히 사람이 확인해야 합니다.

이번 글에서 실제로 돌린 최소 구성

이 글을 쓰는 과정 자체를 작은 실험으로 삼았습니다. 하나의 Herdr workspace를 세 pane으로 나누고, 위쪽에는 전체 작업을 조정하는 오케스트레이터를, 아래쪽에는 읽기 전용 서브에이전트 두 개를 배치했습니다.

구성은 의도적으로 작게 잡았습니다. 에이전트가 많을수록 좋은지 확인하려는 실험이 아니라, 두 개의 독립 작업을 사람이 놓치지 않고 회수할 수 있는지 확인하려는 실험이었기 때문입니다. RESEARCH PANE는 약 5분 12초, REVIEW PANE은 약 3분 42초 뒤 입력을 기다리는 상태로 돌아왔습니다.

에이전트가 Herdr를 다루게 하려면 스킬부터 설치합니다

Herdr를 사람이 단축키로만 조작한다면 스킬이 없어도 됩니다. 하지만 오케스트레이터가 pane을 나누고, 다른 에이전트에게 프롬프트를 보내고, 상태를 기다리게 할 생각이라면 공식 Herdr 스킬은 꼭 설치해 두는 편이 좋습니다.

공식 문서에 따르면 이 스킬은 Herdr 안의 에이전트에게 workspace·tab·pane 조회, focus를 빼앗지 않는 pane 분할과 명령 실행, 출력 읽기, 다른 에이전트 대기와 시작 방법을 알려 줍니다. 즉 모델이 CLI 사용법을 추측하지 않고 Herdr의 실제 제어 표면을 사용하게 만드는 지침입니다.

npx skills add herdrdev/herdr --skill herdr -g

-g는 지원되는 에이전트가 공통으로 쓸 수 있게 전역 설치합니다. 현재 프로젝트에서만 쓰고 싶다면 -g를 빼면 됩니다. 이미 Herdr를 설치했다면 herdr --skill로 실행 중인 바이너리 버전과 맞는 스킬 원문도 확인할 수 있습니다.

크게 보기

×확대 이미지 닫기

스킬의 안전 규칙도 중요합니다. HERDR_ENV=1이 없으면 에이전트는 Herdr가 관리하는 pane 안이 아니라고 판단하고 제어를 멈춰야 합니다. Herdr 밖의 에이전트가 소유하지 않은 세션을 건드리는 일을 막는 최소 경계입니다.

pane에는 역할보다 종료 조건을 먼저 적습니다

“자료 조사해 줘”라고만 쓰면 결과의 범위가 계속 넓어집니다. 제가 pane에 보내는 지시에는 보통 네 가지를 붙입니다.

1. 해야 할 일: 공식 문서와 커뮤니티 경험을 분리해 조사합니다.
2. 하지 않을 일: 파일을 수정하거나 초안을 대신 쓰지 않습니다.
3. 보고 형식: 장점·단점·검증할 주장·출처 URL로 정리합니다.
4. 종료 조건: 독립적인 근거가 충분하면 멈추고 보고합니다.

이렇게 하면 오케스트레이터 pane이 모든 세부 검색을 품지 않아도 됩니다. 중요한 것은 “서브에이전트에게 맡겼다”가 아니라 나중에 어떤 출력이 돌아와야 일이 끝난 것으로 볼지 미리 정해 두었다는 점입니다.

크게 보기

×확대 이미지 닫기

화면을 나눠 놓는 것만으로 역할이 분리되지는 않습니다. 같은 저장소를 바라보는 두 에이전트가 동시에 파일을 고치면 충돌은 그대로 생깁니다. 그래서 조사와 리뷰 pane은 읽기 전용으로 두고, 실제 편집은 한 pane만 맡기는 규칙이 유용했습니다. 병렬 구현이 꼭 필요하다면 Git worktree로 파일 변경을 분리하고, 데이터베이스·포트·캐시·외부 계정 같은 공유 자원은 별도로 격리해야 합니다.

상태값은 “다음에 볼 pane”을 고르는 신호입니다

Herdr의 에이전트 상태 문서에서 상태는 단순한 프로세스 실행 여부보다 한 단계 더 의미가 있습니다. working은 에이전트가 일하는 중이고, blocked는 사용자 입력이나 권한을 기다리며, done은 작업을 마쳤지만 아직 보지 않은 출력이 있다는 뜻입니다. idle은 입력 가능한 상태이면서 이미 확인한 pane에 가깝고, unknown은 현재 화면을 분류하지 못했다는 뜻입니다.

여기서 done을 “작업 성공”으로 읽으면 안 됩니다. 제가 이번 세션에서 두 서브에이전트의 보고를 직접 보고 있던 탓에 상태는 working에서 done이 아니라 idle로 돌아왔습니다. 즉, done은 테스트 통과나 목표 달성이 아니라 아직 보지 않은 완료 알림에 가깝습니다.

크게 보기

×확대 이미지 닫기

상태 감지는 터미널 화면의 패턴을 해석합니다. 새로운 프롬프트 UI나 예상하지 못한 오류 화면은 idle 또는 unknown으로 분류될 수 있습니다. 따라서 저는 상태를 다음 행동을 정하는 대기열로만 씁니다.

• blocked: 가장 먼저 열어 권한 요청인지, 질문인지, 오류인지 읽습니다.
• done: 보고를 회수하고 근거와 변경 내용을 확인합니다.
• working: 방해하지 않되 너무 오래 유지되면 출력과 프로세스를 확인합니다.
• idle: 새 일을 주기 전에 이전 출력이 실제로 검토되었는지 확인합니다.
• unknown: 자동 판단을 멈추고 pane을 직접 봅니다.

제가 쓰는 오케스트레이터 루프

Herdr는 오케스트레이터 모델을 따로 제공하는 제품이라기보다, 사람이 오케스트레이션하기 좋은 표면을 제공합니다. CLI 명령으로 에이전트 목록을 보고, 이름을 붙이고, 프롬프트를 보내고, 상태를 기다리고, 출력을 읽을 수 있습니다. 이 기능을 아래 순서로 묶으면 반복 가능한 작업 루프가 됩니다.

이 루프에서 가장 중요한 단계는 마지막입니다. 서브에이전트가 “완료했습니다”라고 말해도 검증 명령을 실행하지 않았다면 완료가 아닙니다. 반대로 상태가 idle이어도 필요한 근거가 모두 왔고 사람이 검증했다면 작업은 닫을 수 있습니다. 도구의 상태와 프로젝트의 완료 조건을 분리해야 합니다.

더 잘 쓰려면 pane 수보다 회수 비용을 줄입니다

Herdr를 오래 열어 두는 것보다, 맡긴 일을 빠르게 이해하고 회수할 수 있게 만드는 편이 중요합니다. 다음 규칙이 실제 운영에서 도움이 됩니다.

• 이름에 역할과 산출물을 적습니다. RESEARCH PANE, REVIEW PANE처럼 지금 무엇을 돌리는지 바로 읽히게 합니다.
• 웹 조사는 읽기 전용으로 격리합니다. Reddit과 검색 결과를 읽는 pane에는 파일 수정과 비밀값 접근을 금지하고, 공식 문서와 사용자 경험을 구분해 보고하게 합니다.
• 반복 클릭 대신 상태 대기를 씁니다. 스킬이 설치되어 있다면 agent wait로 필요한 상태를 기다리고, 알림이 온 pane의 원문만 엽니다.
• 보고 길이를 먼저 제한합니다. 결론, 근거 URL, 실패 조건만 한 화면 안에 정리하도록 하면 여러 결과가 한꺼번에 돌아와도 검토 대기열이 덜 쌓입니다.
• 쓰기 작업은 소유권을 나눕니다. 여러 pane이 코드를 수정해야 한다면 파일 담당을 겹치지 않게 하거나 worktree로 분리합니다.
• 역할이 끝나면 pane을 닫습니다. 다음 작업까지 빈 에이전트를 남겨 두지 않으면 상태판이 실제로 확인할 대상만 보여 줍니다.

이 규칙의 공통점은 에이전트 수를 늘리는 것이 아니라 사람이 확인해야 할 화면과 결과를 줄인다는 데 있습니다.

Herdr를 쓰며 실제로 편해진 점

첫째, 각 pane의 터미널을 그대로 볼 수 있습니다. 요약 대시보드만 보는 것이 아니라 에이전트가 어느 파일을 읽고 어떤 승인을 기다리는지 원문으로 확인할 수 있습니다. 자동 요약이 잘못되어도 근거 화면으로 돌아갈 수 있습니다.

둘째, 이름과 상태가 생깁니다. RESEARCH PANE, REVIEW PANE처럼 작업 의미로 이름을 붙이면 “아래 왼쪽 터미널이 무엇이었지?”라는 기억 비용이 줄어듭니다. workspace와 tab 단위로 상태가 모이기 때문에 여러 pane을 차례로 클릭하는 횟수도 줄었습니다.

셋째, 터미널 도구의 자유를 유지합니다. 특정 코딩 에이전트에만 묶이지 않고 각 pane에서 원하는 CLI를 실행할 수 있습니다. 세션을 떼었다가 다시 붙이거나 원격 환경에서 이어 보는 멀티플렉서의 장점도 유지됩니다.

넷째, CLI가 있어서 관찰을 자동화할 수 있습니다. 목록 조회, 프롬프트 전송, 상태 대기, 출력 읽기를 명령으로 다룰 수 있으므로 상단의 오케스트레이터 에이전트가 아래 pane들을 확인하게 만들 수 있습니다. 다만 이것은 자동으로 좋은 분업을 만들어 주는 기능이 아닙니다. 잘못 나눈 일을 더 빠르게 반복할 수도 있습니다.

Orca·tmux·Zellij와의 차이

Orca나 다른 멀티플렉서를 거쳐 Herdr에 머문 이유는 우열보다 제가 지금 풀려는 문제가 달라졌기 때문입니다. 제가 원하는 것은 통합 개발 환경 하나가 모든 작업을 감싸는 경험보다, 이미 쓰는 터미널 에이전트들을 같은 화면에 놓고 누가 일하고 있고 누가 제 입력을 기다리는지 빨리 찾는 경험입니다.

Orca의 worktree 중심 모델은 여러 구현 작업의 파일 충돌을 줄이는 데 매력적입니다. Herdr도 worktree 작업 흐름을 지원하지만, 기본적으로는 실제 터미널을 중심에 둡니다. tmux와 Zellij는 더 범용적이고 오래 다듬어진 선택지입니다. 이미 그 환경에 상태 표시 스크립트와 단축키를 잘 갖췄다면 Herdr로 옮겨 얻는 이익이 작을 수 있습니다.

단점은 pane이 늘수록 자동으로 드러납니다

Herdr의 가장 큰 위험은 도구가 아니라 사용 방식입니다. pane을 쉽게 늘릴 수 있다는 이유로 모든 일을 병렬화하면 다음 문제가 생깁니다.

• 같은 파일을 동시에 수정합니다. merge 충돌보다 더 위험한 것은 서로의 변경을 조용히 덮는 경우입니다.
• 공유 자원이 충돌합니다. worktree를 나눠도 같은 데이터베이스, 개발 서버 포트, 캐시, 브라우저 세션은 격리되지 않습니다.
• 검토 대기열이 쌓입니다. 에이전트 세 개가 동시에 긴 결과를 내면 사람의 읽기 속도가 병목이 됩니다.
• 상태를 결과로 착각합니다. done이어도 요구사항 누락, 잘못된 출처, 실패한 테스트는 남을 수 있습니다.
• 0.x 제품의 변화 비용이 있습니다. 설정과 상태 감지 규칙이 빠르게 바뀔 수 있으므로 중요한 자동화는 버전을 고정하고 다시 확인해야 합니다.
• Windows 제약이 있습니다. 공식 Windows beta 문서는 IME·커서·원격 대상·클립보드 등 플랫폼별 제한을 따로 안내합니다. 제 환경에서도 PowerShell이 herdr 명령을 바로 찾지 못해 HERDR_BIN_PATH의 실행 파일을 직접 호출했습니다.

Reddit의 경험담도 엇갈립니다. 두세 세션만 쓰는 사람에게는 관리 비용이 이득보다 크다는 의견이 있는 반면, 원격 머신에서 많은 에이전트를 돌리는 사람은 상태 표시와 세션 회수를 장점으로 꼽습니다. 병렬 에이전트가 공유 작업 트리와 자원에서 충돌했다는 경험도 있습니다. 이 글에서는 이런 경험담을 제품 사실로 일반화하지 않고, 도입 전에 확인할 실패 조건으로만 사용했습니다.

제 테스트에서는 또 하나의 경계가 드러났습니다. 제한된 자동화 환경에서 Herdr의 로컬 소켓 접근은 처음에 거부되었고, 명시적으로 권한을 승인한 뒤에야 pane을 제어할 수 있었습니다. 번거로웠지만 오히려 자연스러운 안전장치입니다. 오케스트레이터가 다른 터미널에 입력을 보낼 수 있다면 그 권한의 범위도 코드 쓰기 권한만큼 분명해야 합니다.

작업이 많아질 때 pane을 역할로 나눕니다

가벼운 프로젝트라면 pane마다 서브에이전트를 돌릴 필요가 없습니다. 한 에이전트에게 짧고 분명한 작업을 맡기고 결과를 바로 확인하는 편이 오히려 빠릅니다. Herdr의 이점은 pane 수를 늘리는 데 있지 않습니다.

해야 할 일이 많고 조사·구현·리뷰·검증처럼 서로 독립적인 작업이 동시에 쌓일 때 역할을 나누는 데 의미가 있습니다. 이때 필요한 pane만 열어 책임을 붙이고, 결과를 회수한 뒤 닫으면 현재 작업의 맥락을 잃지 않으면서 대기 시간을 줄일 수 있습니다.

여러 pane을 열기 전에는 아래 기준부터 확인하는 편이 좋습니다.

1. 병렬로 돌릴 작업이 서로의 결과를 기다리지 않는지 확인합니다.
2. 한 pane에는 한 책임만 둡니다.
3. 동시에 파일을 쓰는 주체는 하나로 제한합니다.
4. blocked와 done은 알림으로 읽고, pane 원문을 직접 확인합니다.
5. 최종 완료는 상태값이 아니라 diff·테스트·빌드로 판정합니다.

즉 Herdr는 작은 일을 억지로 쪼개는 도구가 아니라, 작업량이 커졌을 때 조사와 검토 같은 보조 흐름을 분리해 관리하는 도구에 가깝습니다. 여러 에이전트가 벌인 일을 사람이 끝까지 추적하고, 확인해야 할 순간을 놓치지 않게 만드는 데 가치가 있습니다.