AI 코딩 에이전트 여러 개 돌리기, herdr가 파고든 병목은 딱 하나입니다 (2026년 실측)
Free Resource
PDF · Free
herdr — 코딩 에이전트가 사는 런타임 — 비개발자를 위한 쉬운 가이드
Get the practical guide first, before diving into the full article.
AI 코딩 에이전트 여러 개 돌리기, herdr가 파고든 병목은 딱 하나입니다 (2026년 실측)
herdr는 코딩 에이전트가 사는 런타임입니다. 2026-03-27에 시작해 137일 만에 깃허브 스타 26,905개를 모았고, 2026-08-06에는 와이컴비네이터 합류를 발표했어요.
결론부터 말씀드리면, 에이전트를 세 개 이상 동시에 굴리는 사람에게는 값을 하고 하나만 쓰는 사람에게는 거의 의미가 없습니다. herdr가 새로 만든 것은 에이전트가 아니라 관제실이거든요. "요즘 AI한테 일을 여러 개 시키는데 자꾸 놓쳐요." 이런 얘기를 들으면 대개 도구가 부족한 게 아니라 상황판이 없는 겁니다. 이 글에서는 에이전트를 여러 개 돌릴 때 실제로 무엇이 막히는지, herdr가 그중 무엇을 풀었는지, 해커뉴스의 반대 의견은 무엇인지, 그리고 오늘 도입해도 되는지를 차례로 짚어봅니다.
목차
- 에이전트를 여러 개 돌리면 생기는 진짜 문제
- herdr가 정확히 무엇인가
- 핵심은 blocked 하나입니다
- 노트북을 닫아도 계속 도는 구조
- 브랜치 세 개를 동시에
- 에이전트가 에이전트를 부린다
- 와이컴비네이터, 그리고 라이선스 전환
- 해커뉴스는 뭐라고 하나
- 지금 도입해야 할까
에이전트를 여러 개 돌리면 생기는 진짜 문제
AI 직원 열 명을 고용했다고 해볼게요. 문제는 이 직원들이 각자 다른 방에서 일한다는 겁니다. 누가 일하는 중이고 누가 "이거 어떻게 할까요?" 하고 손 들고 기다리는지 보려면 방마다 문을 열어봐야 해요.
실무에서는 이렇게 나타납니다. 터미널 탭 여덟 개를 하나씩 클릭해 상태를 확인하고, 한참 뒤에야 세 번째 탭의 에이전트가 30분째 승인을 기다리고 있었다는 걸 발견하죠. 해커뉴스의 한 사용자는 이 지점을 이렇게 표현했어요. "다섯에서 일곱 개를 넘어가면 어디에 내 주의가 필요한지 보려고 일일이 클릭하는 게 싫어진다."
여기에 세 가지가 더 붙습니다. 노트북을 닫거나 SSH 연결이 끊기면 몇 시간짜리 작업이 날아가고, 같은 저장소에서 여러 에이전트를 돌리면 서로의 변경을 밟고, A가 끝나야 B가 시작해야 하는 상황을 사람이 지켜보고 있어야 해요.
herdr를 만든 사람도 같은 진단을 내렸습니다. 와이컴비네이터 발표문에 이런 문장이 있어요. "그러다 문득 깨달았습니다. 내가 병목이다."
herdr가 정확히 무엇인가
깃허브 주제 태그에 tmux, 멀티플렉서, 에이전트 오케스트레이션, 워크스페이스 관리자가 함께 달려 있어 헷갈리기 쉽습니다. 공식 문서의 자기 정의는 "터미널 워크스페이스 관리자"예요.
핵심은 herdr가 하지 않는 일에 있습니다. 저장소 설명에 이렇게 적혀 있어요. "이미 쓰고 있는 걸 그대로 돌린다. herdr는 그것들을 감싸거나 대체하지 않고, 그저 터미널을 소유할 뿐이다."
즉 Claude Code든 Codex든 Cursor든 쓰던 도구를 그대로 씁니다. herdr는 그 위에 상황판을 얹어요. 2026-08-03 문서 기준으로 18종을 자동 인식하고, 여기에는 Claude Code, Codex, Cursor Agent CLI, 깃허브 코파일럿 CLI, Devin, Grok CLI, OpenCode 등이 들어갑니다.
실측 수치는 이렇습니다(2026-08-11 확인).
| 항목 | 값 |
|---|---|
| 깃허브 스타 | 26,905개 |
| 포크 | 1,885개 |
| 기여자 | 74명 |
| 열린 이슈 | 143건 |
| 저장소 나이 | 137일 (2026-03-27 시작) |
| 최신 버전 | v0.8.0 (2026-08-03) |
| 언어 / 라이선스 | Rust / Apache-2.0 |
하루 평균 196개씩 스타가 붙은 셈입니다. 2026-06-30에는 깃허브 트렌딩 1위에 올랐어요. 결과물은 의존성 없는 단일 실행 파일 하나이고 용량은 10MB 남짓입니다. 일렉트론 같은 무거운 껍데기가 없어요.
터미널 멀티플렉서: 터미널 창 하나 안에서 여러 개의 독립된 터미널을 나눠 쓰고, 연결을 끊었다 다시 붙어도 그 안의 작업이 계속 돌게 해주는 프로그램입니다. tmux가 대표적이고, herdr는 여기에 "에이전트 상태 인식"을 얹은 형태예요.
핵심은 blocked 하나입니다
herdr가 tmux와 갈라지는 지점은 사실상 하나입니다. 에이전트가 지금 멈춰서 사람을 기다리는 중인지 아는 것.
herdr는 상태를 다섯 가지로 나눕니다.
| 상태 | 의미 |
|---|---|
| blocked | 입력이나 승인, 판단을 기다리는 중 |
| working | 실제로 돌아가는 중 |
| done | 끝났는데 아직 사람이 안 봤음 |
| idle | 끝났고 사람도 확인했음 |
| unknown | herdr가 확신하지 못하는 상태 |
이 상태가 아래에서 위로 굴러 올라갑니다. 터미널 한 칸(pane)에서 탭으로, 탭에서 프로젝트로요. 그래서 사이드바만 봐도 어느 프로젝트가 나를 부르고 있는지 보입니다.
문서가 짚는 뉘앙스가 하나 있어요. 중요한 건 herdr가 에이전트를 볼 수 있느냐가 아니라, 어떤 신호가 상태를 결정할 권한을 갖느냐입니다. 생명주기 훅을 설치할 수 있는 에이전트는 훅이 상태를 확정하고, Claude Code나 Codex는 화면 내용을 읽어 상태를 추정해요. 후자는 추정이라 가끔 틀립니다. 실제로 "Claude Code가 대기 중인데 헤더에는 다른 상태가 뜬다"는 이슈가 올라와 있어요.
노트북을 닫아도 계속 도는 구조
herdr는 백그라운드 서버로 돌고, 터미널 화면은 거기에 붙는 손님입니다. 서버가 실제 프로세스와 상태를 소유해요.
그래서 ctrl+b q로 화면을 떼어내도 에이전트는 계속 일합니다. 네트워크가 끊기거나 기계를 재시작해도 세션이 돌아오고, SSH로 다른 기계에서 붙을 수도 있어요.
이게 실무에서 의미하는 바는 이렇습니다. 회사 서버나 개인 서버에 herdr를 올려두고 여섯 시간짜리 작업을 맡긴 뒤 퇴근합니다. 지하철에서 폰으로 접속해 blocked 표시가 뜬 것만 확인하고 답을 주죠. 만든 사람도 노트북과 긴 작업용 서버, 위험한 코드를 돌릴 샌드박스를 잇는 걸 다음 과제로 언급했어요. 지금은 그 기계들이 서로 끊겨 있다고요.
브랜치 세 개를 동시에
깃 워크트리(같은 저장소를 여러 폴더로 따로 체크아웃하는 기능)가 1급 명령으로 들어가 있습니다.
herdr worktree create --branch feat/login
herdr worktree create --branch feat/payment
herdr worktree create --branch fix/perf
명령 한 줄이 체크아웃을 만들고, 작업 공간으로 열고, 부모 저장소 작업 공간과 묶어서 사이드바에 붙여 놓습니다. 에이전트 셋이 각자 다른 폴더에서 돌기 때문에 서로의 파일을 밟지 않아요.
안전장치가 꼼꼼한 점이 눈에 띕니다. 작업 공간을 닫는 것과 실제 폴더를 지우는 것이 분리돼 있어요. workspace close는 herdr 안의 상태만 닫고, 실제 체크아웃 삭제는 worktree remove만 합니다. 브랜치는 어떤 경우에도 지우지 않고, 커밋 안 한 변경이 남아 있으면 --force를 요구해요. 자동화 도구가 파일을 지울 때 가져야 할 태도입니다.
에이전트가 에이전트를 부린다
herdr에서 사람이 쓰는 명령과 에이전트가 쓰는 소켓 API는 같은 표면입니다. 원시 도구는 셋이에요. 배치(작업 공간과 탭, 칸의 구조), 칸(생 터미널 제어), 에이전트(인식된 에이전트를 이름과 생명주기 상태로 제어).
그래서 오케스트레이터 역할의 에이전트 하나가 작업용 칸들을 만들고, 프롬프트를 넣고, 다른 에이전트가 진짜로 막힐 때까지 기다릴 수 있습니다. 몇 초마다 확인하는 폴링이 아니라 상태를 보고 기다리는 방식이에요.
모든 생성 명령이 JSON을 뱉는 것도 중요합니다. 문서는 ID를 예측하지 말고 응답에서 꺼내 쓰라고 명시해요.
created=$(herdr workspace create --cwd ~/project --label api --no-focus)
pane_id=$(printf '%s\n' "$created" | jq -r '.result.root_pane.pane_id')
v0.8.0에서는 herdr --skill이 추가됐습니다. 설치된 실행 파일에 들어 있는 사용법 문서를 그대로 출력해요. 에이전트가 herdr 쓰는 법을 자기 컨텍스트에 바로 넣을 수 있다는 뜻입니다. 문서와 실행 파일의 버전이 어긋나는 문제를 구조로 막은 셈이에요.
와이컴비네이터, 그리고 라이선스 전환
2026-08-06, 오늘 기준 5일 전에 소식이 나왔습니다. 혼자 만들던 이 프로젝트가 와이컴비네이터에 합류했어요. 발표문 제목이 "런타임은 계속 열려 있습니다"입니다.
만든 사람은 발표 시점 기준으로 스타 25,000개와 다운로드 340,000건, 마켓플레이스 공개 한 달 만에 플러그인 500개 이상을 집계했다고 밝혔어요. 그리고 "한 사람이 감당할 수 있는 수준을 넘었다"며 팀을 꾸리는 이유를 설명했습니다.
같은 주에 라이선스도 바뀌었습니다. 2026-08-03 v0.8.0에서 AGPL-3.0에서 Apache-2.0으로 전환했어요. 사유는 명확합니다. "누구나 아무 문제 없이 herdr를 쓰게 하고 싶어서."
해커뉴스는 뭐라고 하나
herdr는 해커뉴스에 세 번 크게 올랐습니다. 2026-07-02에 404점, 2026-08-06 와이컴비네이터 발표가 279점, 2026-06-29에 166점이었어요.
좋은 평가부터 보면 공통점이 있습니다. 몇 주 써본 사람들이 세션 지속성을 예상 밖의 장점으로 꼽아요. 한 사용자는 "설치하면 바로 되는데 커스터마이즈도 깊게 된다"는 인상과 함께 "세션 지속성을 내가 이렇게 좋아할 줄 몰랐다"고 적었습니다. tmux를 몇 년 쓴 사람이 "기분 좋게 놀랐다, 주력으로 쓸 것 같다"고 남긴 글도 있어요.
반대편도 만만치 않습니다.
- "터미널 위에 키보드 단축키 레이어가 하나 더 얹히는 게 거슬린다. WezTerm에 분할 몇 개 띄우는 것과 뭐가 다른지 모르겠다."
- "tmux에서도 된다. 지금 내 tmux 창마다 상태 표시가 있다. 작업 중이면 파란 스피너, 주의 필요하면 빨간 점, 끝나면 초록 체크. Claude Code 훅으로 tmux 명령을 실행하면 된다."
- 와이컴비네이터 발표 아래에는 이런 반응이 달렸어요. "투자를 받으면 유료화는 if가 아니라 when이다."
라이선스 전환을 둘러싼 논쟁도 뜨거웠습니다. AGPL을 피하는 관행 자체가 근거 없다는 쪽과, 실제 법무 검토에서 걸린다는 쪽이 부딪혔어요.
한 가지 밝혀둘 게 있습니다. 이 반응들은 모두 해커뉴스에서 모은 것입니다. 레딧과 X는 자동 수집이 막혀 확보하지 못했어요. 해커뉴스는 tmux 사용자 비중이 높은 곳이라 개발자 여론 전체로 일반화하기는 어렵습니다.
지금 도입해야 할까
기준은 의외로 선명합니다. 에이전트를 세 개 이상 굴리고, 한 번 시키면 5분 넘게 도는 작업을 맡기고, 서버에 올려두고 오가며 확인하는 사람이라면 값을 합니다. 반대로 에이전트 하나만 쓴다면 tmux 대비 추가 가치가 얇아요. 리뷰어들의 결론이 대체로 여기서 겹칩니다.
넣기 전에 짚어야 할 것들은 이렇습니다.
아직 1.0이 아닙니다. 최신이 v0.8.0이에요. 소켓 API로 자동화를 짜두면 버전이 오르며 손볼 각오가 필요합니다. 2026-07부터 2026-08 사이에만 안정 버전이 네 개 나왔을 만큼 변화가 빨라요.
핵심 개발자가 한 명입니다. 기여자는 74명이지만 중심은 여전히 만든 사람 한 명이에요. 팀 구성은 와이컴비네이터 합류 이후 이제 막 시작입니다.
윈도우는 베타입니다. v0.8.0 릴리스 노트의 윈도우 관련 수정이 유독 많은데, 뒤집어 보면 그만큼 불안정했다는 뜻이에요.
유료화 지점이 미정입니다. 런타임은 무료로 남는다고 못 박았지만 그 위에 무엇이 올라올지는 예고 수준이에요. 업무 필수 경로에 넣기 전에 이 불확실성은 감안하는 게 좋습니다.
알려진 이슈도 있습니다. 화면 갱신 60Hz 제한, 원격 세션이 에이전트 목록에 안 뜨는 문제, 줄바꿈된 링크를 클릭할 수 없는 문제 등이 올라와 있어요.
마무리
herdr가 만든 것은 새로운 에이전트가 아니라 관제실입니다. 에이전트를 여러 명 동시에 굴릴 때만 값을 하고, 그 조건에서는 손 든 사람이 보인다는 것 하나를 아주 잘 해요.
한번 세어보시면 좋겠습니다. 지금 열려 있는 터미널 탭 중에 답을 기다리며 멈춰 있는 게 몇 개인가요. 그 숫자가 셋을 넘는다면 herdr가 푸는 문제가 이미 내 문제일 가능성이 높습니다.
자주 묻는 질문
Q: tmux로도 되지 않나요?
세션 지속성과 화면 분할만 놓고 보면 tmux로 충분합니다. 실제로 Claude Code 훅을 걸어 tmux 창에 상태 표시를 띄워 쓰는 분들도 있어요. 차이는 에이전트 상태를 herdr가 기본으로 인식하고 그것을 프로젝트 단위까지 올려 보여준다는 점입니다. 에이전트가 한둘이면 훅으로 충분하고, 여러 프로젝트를 오가며 대여섯 개를 굴린다면 herdr 쪽이 손이 덜 갑니다.
Q: 핵심 개발자가 한 명인데 믿고 써도 되나요?
용도를 나눠 판단하시는 게 좋습니다. herdr는 작업을 대신 실행하지 않고 터미널만 소유하기 때문에, 서비스가 멈춰도 에이전트와 코드는 그대로 남아요. 이 점에서 위험 크기는 데이터를 보관하는 도구보다 작습니다. 다만 소켓 API로 사내 자동화를 깊게 엮는 건 1.0 이후로 미루시길 권합니다. 2026-08-06 와이컴비네이터 합류로 팀을 꾸리는 중이지만 아직 시작 단계예요.
Q: 에이전트를 하나만 쓰는데도 이득이 있나요?
크지 않습니다. herdr의 값어치는 "여러 개 중 누가 멈췄는지 알려준다"에서 나오는데, 하나면 그 화면을 이미 보고 있으니까요. 다만 오래 도는 작업을 서버에 맡기고 오가며 확인하는 방식이라면 하나여도 세션 지속성만으로 쓸 이유가 생깁니다.
관련 글
참고자료
- herdrdev/herdr (GitHub)
- Herdr is joining Y Combinator. The runtime stays open. (공식 블로그, 2026-08-06)
- herdr v0.8.0 릴리스 노트 (2026-08-03)
- herdr 공식 문서 — 지원 에이전트
- herdr 공식 문서 — CLI 레퍼런스 (워크트리 명령)
- Hacker News: Herdr is joining Y Combinator (2026-08-06)
- Hacker News: Herdr — One terminal to rule them all (2026-07-02)

