저는 Herdr를 작업의 조종석으로 씁니다. Herdr는 코드를 대신 작성하는 모델이 아니라 터미널 pane마다 실행한 코딩 에이전트를 인식하고, working·blocked·done 같은 상태를 모아 보여 주는 멀티플렉서입니다. 이 차이는 작아 보여도 세션이 서너 개를 넘는 순간 꽤 크게 느껴집니다.
제가 말하는 바이브 코딩은 요구사항을 한 문장 던지고 결과를 믿는 방식이 아닙니다. 사람이 목표와 경계를 정하고, 에이전트에게 조사·구현·검토를 나눠 맡긴 뒤, 마지막 판단은 diff와 테스트로 닫는 방식에 가깝습니다. AI가 코드를 빨리 만드는 것보다 어느 작업이 진행 중이고, 어디서 멈췄고, 무엇을 아직 읽지 않았는지 한 화면에서 놓치지 않는 것이 더 중요해졌습니다.
herdr.dev · officialHerdr — 코딩 에이전트를 위한 터미널 런타임실제 터미널을 유지하고 여러 코딩 에이전트의 pane과 상태를 한 workspace에서 관리하는 공식 페이지입니다.
다만 먼저 선을 그어야 합니다. 상태값은 품질 점수가 아니며, pane 수도 생산성 지표가 아닙니다. Herdr가 알려 주는 것은 “어디를 봐야 하는가”까지입니다. “이 결과가 맞는가”는 여전히 사람이 확인해야 합니다.
이 글은 Herdr 0.8.2와 공식 agent skill의 설치·실행이 끝난 뒤, Codex CLI 로그인 세션에서 작업을 나누는 단계부터 다룹니다. 설치 문제 해결이나 다른 버전의 명령 동작까지 검증한 설치 가이드는 아닙니다.
이번 글에서 실제로 돌린 최소 구성
이 글을 쓰는 과정 자체를 작은 실험으로 삼았습니다. 하나의 Herdr workspace를 세 pane으로 나누고, 위쪽에는 전체 작업을 조정하는 오케스트레이터를, 아래쪽에는 읽기 전용 서브에이전트 두 개를 배치했습니다.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| 오케스트레이터 | 목표 분해와 결과 통합 | 사용자 요구를 조사와 구조 검토로 나누고, 각 pane에 지시한 뒤 보고를 읽어 최종 글과 검증 범위를 결정했습니다. | 상단 pane · 파일 작성과 최종 판단 |
| RESEARCH PANE | 공식 문서와 사용자 경험 분리 | Herdr·Orca·tmux·Zellij 공식 문서와 Reddit 경험담을 조사하되 파일은 수정하지 않도록 제한했습니다. | 하단 왼쪽 · 읽기 전용 조사 |
| REVIEW PANE | 과장과 빠진 질문 점검 | 독자가 실제로 궁금해할 질문, 상태값 오해, 병렬 작업의 충돌 조건을 검토하되 초안은 쓰지 않도록 했습니다. | 하단 오른쪽 · 읽기 전용 비평 |
구성은 의도적으로 작게 잡았습니다. 에이전트가 많을수록 좋은지 확인하려는 실험이 아니라, 두 개의 독립 작업을 사람이 놓치지 않고 회수할 수 있는지 확인하려는 실험이었기 때문입니다. RESEARCH PANE는 약 5분 12초, REVIEW PANE은 약 3분 42초 뒤 입력을 기다리는 상태로 돌아왔습니다.
관찰 기록이 말해 주는 범위
남아 있는 기록으로 확인할 수 있는 조건은 Herdr 0.8.2, Codex CLI, gpt-5.6-sol high, Windows 11·Windows Terminal·PowerShell, ko-KR, 2026년 9월 7일입니다. 계정 구독 유형은 확인되지 않았고, pane별 원문 입력·기대 결과·전체 출력·실패 로그를 독립된 비공개 기록으로 다시 대조할 수 있는 상태도 아닙니다.
따라서 아래 5분 12초·3분 42초는 이 한 실행의 관찰값으로만 읽어야 합니다. 생산성 향상률이나 다른 환경의 재현 시간을 뜻하지 않습니다. 뒤의 약 5초 영상도 두 pane이 working으로 바뀌는 초기 구간만 보여 주며 작업 완료를 증명하지 않습니다. 공식 문서가 설명하는 기능, 이 실행에서 관찰한 결과, 제가 선호하는 운영 방식을 구분해 적습니다.
에이전트가 Herdr를 다루게 하려면 스킬부터 설치합니다
Herdr를 사람이 단축키로만 조작한다면 스킬이 없어도 됩니다. 하지만 오케스트레이터가 pane을 나누고, 다른 에이전트에게 프롬프트를 보내고, 상태를 기다리게 할 생각이라면 공식 Herdr 스킬은 꼭 설치해 두는 편이 좋습니다.
공식 문서에 따르면 이 스킬은 Herdr 안의 에이전트에게 workspace·tab·pane 조회, focus를 빼앗지 않는 pane 분할과 명령 실행, 출력 읽기, 다른 에이전트 대기와 시작 방법을 알려 줍니다. 즉 모델이 CLI 사용법을 추측하지 않고 Herdr의 실제 제어 표면을 사용하게 만드는 지침입니다.
다음 스킬 설치 명령은 Node.js와 npm이 있는 Windows PowerShell·macOS zsh·Linux bash 공통입니다. 스킬 설치와 Herdr 앱 자체의 운영체제 지원은 별개이므로, 앱은 해당 플랫폼의 공식 설치·제약 안내를 따릅니다.
npx skills add herdrdev/herdr --skill herdr -g
-g는 지원되는 에이전트가 공통으로 쓸 수 있게 전역 설치합니다. 현재 프로젝트에서만 쓰고 싶다면 -g를 빼면 됩니다. 이미 Herdr를 설치했다면 herdr --skill로 실행 중인 바이너리 버전과 맞는 스킬 원문도 확인할 수 있습니다.
Herdr 0.8.2 공식 문서의 스킬 설치 구간입니다. 전역 설치 명령과 함께, 에이전트가 Herdr 안에서 실행 중인지 확인하는 HERDR_ENV=1 안전 규칙도 안내합니다.
스킬의 안전 규칙도 중요합니다. HERDR_ENV=1이 없으면 에이전트는 Herdr가 관리하는 pane 안이 아니라고 판단하고 제어를 멈춰야 합니다. Herdr 밖의 에이전트가 소유하지 않은 세션을 건드리는 일을 막는 최소 경계입니다.
pane에는 역할보다 종료 조건을 먼저 적습니다
“자료 조사해 줘”라고만 쓰면 결과의 범위가 계속 넓어집니다. 제가 pane에 보내는 지시에는 보통 네 가지를 붙입니다.
- 해야 할 일: 공식 문서와 커뮤니티 경험을 분리해 조사합니다.
- 하지 않을 일: 파일을 수정하거나 초안을 대신 쓰지 않습니다.
- 보고 형식: 장점·단점·검증할 주장·출처 URL로 정리합니다.
- 종료 조건: 독립적인 근거가 충분하면 멈추고 보고합니다.
이렇게 하면 오케스트레이터 pane이 모든 세부 검색을 품지 않아도 됩니다. 중요한 것은 “서브에이전트에게 맡겼다”가 아니라 나중에 어떤 출력이 돌아와야 일이 끝난 것으로 볼지 미리 정해 두었다는 점입니다.
비평 pane에는 글을 대신 쓰게 하지 않고, 과장하기 쉬운 표현과 실패 조건만 보고하게 했습니다.
화면을 나눠 놓는 것만으로 역할이 분리되지는 않습니다. 같은 저장소를 바라보는 두 에이전트가 동시에 파일을 고치면 충돌은 그대로 생깁니다. 그래서 조사와 리뷰 pane은 읽기 전용으로 두고, 실제 편집은 한 pane만 맡기는 규칙이 유용했습니다. 병렬 구현이 꼭 필요하다면 Git worktree로 파일 변경을 분리하고, 데이터베이스·포트·캐시·외부 계정 같은 공유 자원은 별도로 격리해야 합니다.
상태값은 “다음에 볼 pane”을 고르는 신호입니다
Herdr의 에이전트 상태 문서에서 상태는 단순한 프로세스 실행 여부보다 한 단계 더 의미가 있습니다. working은 에이전트가 일하는 중이고, blocked는 사용자 입력이나 권한을 기다리며, done은 작업을 마쳤지만 아직 보지 않은 출력이 있다는 뜻입니다. idle은 입력 가능한 상태이면서 이미 확인한 pane에 가깝고, unknown은 현재 화면을 분류하지 못했다는 뜻입니다.
기본 dots 표시에서는 작업·주의 상태가 채운 원, idle은 빈 원, unknown은 가운데점으로 보입니다. 아래 표의 상태명 옆 점에는 Herdr 기본 테마의 실제 상태 색상을 적용했습니다. 사용 중인 테마를 바꾸면 화면의 색조는 달라질 수 있습니다.
여기서 done을 “작업 성공”으로 읽으면 안 됩니다. 제가 이번 세션에서 두 서브에이전트의 보고를 직접 보고 있던 탓에 상태는 working에서 done이 아니라 idle로 돌아왔습니다. 즉, done은 테스트 통과나 목표 달성이 아니라 아직 보지 않은 완료 알림에 가깝습니다.
ORCHESTRATOR가 RESEARCH PANE에는 Reddit·웹 검색 기반 자료조사를, REVIEW PANE에는 상태값 오인과 병렬 파일 충돌 검토를 맡깁니다. 두 pane이 약 5초간 working으로 전환되는 초기 실행 흐름만 담았습니다.
상태 감지는 터미널 화면의 패턴을 해석합니다. 새로운 프롬프트 UI나 예상하지 못한 오류 화면은 idle 또는 unknown으로 분류될 수 있습니다. 따라서 저는 상태를 다음 행동을 정하는 대기열로만 씁니다.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| blocked | 입력이나 승인을 기다림 | 사용자 질문, 권한 요청, 승인 화면이 떠 있는 상태입니다. | 가장 먼저 pane 원문 확인 |
| done | 끝났지만 아직 보지 않은 결과 | 작업 결과가 나왔고 사용자가 아직 확인하지 않은 상태입니다. 성공 여부는 별도로 검증해야 합니다. | 보고·근거·변경 내용 회수 |
| working | 에이전트가 작업 중 | 현재 처리가 진행 중입니다. 너무 오래 유지될 때만 출력과 프로세스를 확인합니다. | 진행 관찰 · 불필요한 개입 보류 |
| idle | 입력 가능하고 확인한 상태 | 에이전트가 기다리고 있고 결과도 이미 본 것으로 처리된 pane입니다. | 이전 출력 확인 후 새 작업 지시 |
| unknown | 상태를 분류하지 못함 | 현재 화면을 Herdr가 확실하게 판정하지 못한 상태입니다. | 자동 판단을 멈추고 직접 확인 |
제가 쓰는 오케스트레이터 루프
Herdr는 오케스트레이터 모델을 따로 제공하는 제품이라기보다, 사람이 오케스트레이션하기 좋은 표면을 제공합니다. CLI 명령으로 에이전트 목록을 보고, 이름을 붙이고, 프롬프트를 보내고, 상태를 기다리고, 출력을 읽을 수 있습니다. 이 기능을 아래 순서로 묶으면 반복 가능한 작업 루프가 됩니다.
- 경계 설정오케스트레이터가 산출물, 금지 범위, 검증 명령을 먼저 적습니다.
- 독립 위임서로 기다릴 필요가 없는 조사와 구조 검토만 별도 pane에 보냅니다.
- 상태 관찰blocked와 done을 우선순위 신호로 보고 필요한 pane만 엽니다.
- 결과 회수보고서의 주장과 출처를 읽고, 충돌하는 조언은 오케스트레이터가 판정합니다.
- 직접 검증diff, 테스트, 빌드, 실제 화면을 확인한 뒤에만 완료로 닫습니다.
이 루프에서 가장 중요한 단계는 마지막입니다. 서브에이전트가 “완료했습니다”라고 말해도 검증 명령을 실행하지 않았다면 완료가 아닙니다. 반대로 상태가 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들을 확인하게 만들 수 있습니다. 다만 이것은 자동으로 좋은 분업을 만들어 주는 기능이 아닙니다. 잘못 나눈 일을 더 빠르게 반복할 수도 있습니다.
두 대의 노트북과 iPhone에서 작업을 이어갑니다
저는 Herdr를 두 대의 노트북에서 나눠 씁니다. MacBook은 iOS 앱 개발을 중심으로 두고, Windows 노트북은 이 블로그 운영과 다른 작업에 주로 사용합니다. 프로젝트 성격은 다르지만 workspace와 pane을 나누고 상태를 확인하는 방식은 같아서, 기기를 바꿔도 작업을 정리하는 규칙을 새로 만들 필요가 적었습니다.
MacBook과 iPhone은 Tailscale로 연결해 두었습니다. 밖에서는 iPhone으로 MacBook에 원격 접속해 진행 중인 pane을 확인하고, 필요한 입력을 보내거나 결과를 회수합니다. 휴대폰 화면에서 여러 터미널을 오래 읽는 일은 불편하지만, Herdr에서 pane 이름과 blocked·done 같은 상태를 먼저 확인하면 지금 봐야 할 작업부터 좁힐 수 있어 원격 작업에 특히 편했습니다.
여기서 Tailscale은 기기 사이의 원격 연결을 맡고, Herdr는 접속한 터미널 세션과 에이전트 상태를 정리합니다. Herdr가 iPhone 앱이나 원격 접속 자체를 대신하는 것은 아닙니다. 두 도구의 역할을 나눠 쓰니 휴대폰에서는 모든 화면을 순서대로 열기보다, 멈췄거나 결과가 나온 pane만 골라 확인할 수 있었습니다.
pane을 나누어도 같은 작업 폴더를 함께 수정하면 충돌할 수 있습니다. 작업 공간까지 분리하는 방법은 Git worktree와 Husky로 AI 병렬 코딩 충돌 줄이기에서 이어서 설명합니다.
Orca·tmux·Zellij와의 차이
Orca나 다른 멀티플렉서를 거쳐 Herdr에 머문 이유는 우열보다 제가 지금 풀려는 문제가 달라졌기 때문입니다. 제가 원하는 것은 통합 개발 환경 하나가 모든 작업을 감싸는 경험보다, 이미 쓰는 터미널 에이전트들을 같은 화면에 놓고 누가 일하고 있고 누가 제 입력을 기다리는지 빨리 찾는 경험입니다.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| Herdr | 에이전트 상태가 붙은 터미널 조종석 | 실제 pane을 유지하면서 코딩 에이전트를 인식하고 상태를 모아 봅니다. 터미널 중심 작업과 CLI 오케스트레이션에 잘 맞습니다. | 현재 작업과 대기 요청을 한 화면에서 찾고 싶을 때 |
| Orca | 작업 단위가 통합된 Agent Development Environment | 공식 문서상 각 작업을 worktree에 두고 터미널·편집기·브라우저·diff·리뷰·배포 흐름을 한 앱에 묶습니다. | 작업 생성부터 코드 리뷰와 전달까지 앱 하나에서 하고 싶을 때 |
| tmux | 검증된 범용 터미널 멀티플렉서 | 세션·window·pane과 원격 지속성이 핵심입니다. 이미 설정과 단축키가 몸에 익었다면 에이전트 상태를 별도 스크립트로 보강할 수 있습니다. | 범용성과 성숙한 생태계가 더 중요할 때 |
| Zellij | 레이아웃과 UX가 강한 범용 멀티플렉서 | 발견하기 쉬운 인터페이스, 레이아웃, 플러그인과 웹 클라이언트가 강점입니다. 에이전트 전용 상태보다 터미널 UX가 우선일 때 맞습니다. | 구조화된 레이아웃과 일반 터미널 작업을 함께 할 때 |
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을 열기 전에는 아래 기준부터 확인하는 편이 좋습니다.
- 병렬로 돌릴 작업이 서로의 결과를 기다리지 않는지 확인합니다.
- 한 pane에는 한 책임만 둡니다.
- 동시에 파일을 쓰는 주체는 하나로 제한합니다.
blocked와done은 알림으로 읽고, pane 원문을 직접 확인합니다.- 최종 완료는 상태값이 아니라 diff·테스트·빌드로 판정합니다.
즉 Herdr는 작은 일을 억지로 쪼개는 도구가 아니라, 작업량이 커졌을 때 조사와 검토 같은 보조 흐름을 분리해 관리하는 도구에 가깝습니다. 여러 에이전트가 벌인 일을 사람이 끝까지 추적하고, 확인해야 할 순간을 놓치지 않게 만드는 데 가치가 있습니다.
VIEW—
