여러 코딩 에이전트를 동시에 돌리다 보면 창을 닫아도 작업이 이어지기를 바라게 됩니다. 그 바람이 “프로세스가 계속 산다”는 뜻인지, “레이아웃과 대화만 돌아온다”는 뜻인지에 따라 운영 방식은 완전히 달라집니다.
Herdr을 두고 일부 소개 글은 데스크톱 앱이라고 표현합니다. 하지만 공식 저장소와 공식 문서를 확인하면 Herdr은 Electron 앱이 아니라 Rust로 만든 터미널 멀티플렉서(TUI)입니다. “하나의 Rust 바이너리, Electron 없음, 이미 쓰는 터미널에서 실행”이라고 저장소가 명시합니다. 이 차이를 바로잡지 않으면 세션 수명에 대한 기대도 어긋납니다.
무엇이 살아남는가
Herdr은 각 에이전트를 실제 PTY가 있는 터미널 팬에 둡니다. 클라이언트를 detach하면 백그라운드 서버가 팬과 프로세스를 계속 유지합니다. 하지만 Herdr 서버 자체가 재시작되면 원래 팬 프로세스는 사라집니다. 공식 세션 상태 문서가 이 차이를 표로 설명합니다.
| 상황 | 프로세스 유지 | 레이아웃 복원 | 최근 화면 복원 | 에이전트 대화 재개 |
|---|---|---|---|---|
| detach 후 재attach | 예 | 예 | 예, 살아 있는 터미널에서 | 예, 프로세스가 멈추지 않았으므로 |
| Herdr 서버 재시작 | 아니오 | 예 | 패널 화면 기록을 켠 경우만 | 네이티브 세션 복원을 지원하는 경우만 |
--handoff 없는 업데이트 |
호환 서버는 유지, 재시작이 필요한 서버는 중단 가능 | 재시작 후 예 | 패널 화면 기록을 켠 경우만 | 네이티브 세션 복원을 지원하는 경우만 |
--handoff 있는 업데이트 |
지원되는 실행 서버에서 최선 노력 | 예 | handoff가 성공하면 살아 있는 터미널에서 | handoff가 성공하면 프로세스가 계속 살아 있으므로 |
즉 “창을 닫아도 코어가 살아 있으면 작업이 유지된다”는 설명은 detach 경로에서는 맞습니다. 그러나 기기 재부팅이나 서버 재시작 뒤에 실행 중이던 프로그램까지 되살아나는 것은 아닙니다. 레이아웃은 돌아오고, 지원되는 에이전트는 자기 대화 세션을 --resume 형태로 다시 열 수 있지만, 원래의 빌드 프로세스나 테스트 러너는 새 프로세스입니다.
이 구분은 백그라운드 작업에 특히 중요합니다. 서버 재시작 전에 돌던 장시간 테스트가 있다면, 재시작 후 레이아웃이 복원돼도 그 테스트는 처음부터 다시 실행해야 합니다. “복원됐다”는 UI의 모습과 “같은 작업이 계속된다”는 실행의 상태를 분리해서 봐야 합니다.
여러 에이전트를 한 창에 모은다는 것
Herdr의 핵심은 터미널 팬을 예쁘게 나누는 데 있지 않습니다. 각 팬에 어떤 에이전트가 있는지, 지금 working, blocked, idle 중 무엇인지 추적하고, 탭과 워크스페이스 단위로 상태를 올려 보여주는 데 있습니다. Claude Code, Codex, Cursor Agent CLI, OpenCode, Copilot CLI 같은 도구를 감싸지 않고 기존 터미널 위에서 실행합니다.
에이전트 상태 판정 방식도 문서에 나옵니다. Herdr이 지원하는 에이전트는 화면 하단의 실제 출력, 즉 사용자가 스크롤한 위치가 아니라 현재 보이는 마지막 화면을 읽어 상태를 추론합니다. 공식 통합이 상태를 직접 보고하는 에이전트는 그 보고를 우선합니다. blocked는 승인·질문·권한 UI가 화면에 보일 때만 엄격하게 표시하고, 규칙이 맞지 않으면 idle로 떨어뜨립니다. 이 fallback은 문서에도 default_known_agent_idle_fallback으로 기록됩니다.
이 설계의 장점은 별도 프로토콜 없이도 다양한 CLI 에이전트를 한곳에서 볼 수 있다는 점입니다. 반대로 화면 문자열에 의존하므로 새 UI나 테마가 나오면 판정이 흔들릴 수 있습니다. 문서는 이 위험을 직접 경고합니다. 잘못된 idle을 신뢰한 자동화가 승인 대화상자에 입력을 보낼 수 있으므로, idle 상태는 승인 권한이 아니라고 못 박습니다.
운영 전에 확인할 계약
Herdr을 도입한다면 기능 목록보다 다음 항목을 먼저 시험하는 편이 좋습니다. 아래는 공식 문서를 바탕으로 CodeBridge가 정리한 점검표이며, Herdr을 설치해 직접 실행한 결과는 아닙니다.
| 시험 | 기대하는 계약 | 확인 방법 |
|---|---|---|
| detach/reattach | 원래 프로세스가 계속 살아 있음 | 긴 sleep을 띄우고 PID가 같은지 확인 |
| 서버 재시작 | 프로세스는 종료, 레이아웃은 복원 | 서버를 멈추고 PID 소멸·팬 복원을 각각 확인 |
| 에이전트 대화 복원 | 지원 에이전트만 네이티브 세션으로 재개 | 통합 버전과 --resume 명령 확인 |
| 원격 SSH 재연결 | 로컬과 원격 세션이 독립적으로 재연결 | 네트워크를 끊고 양쪽 상태를 따로 확인 |
| 화면 기록 | 기본 비활성, 켜면 비밀값이 저장될 수 있음 | pane_history 설정과 저장 파일 권한 확인 |
| 상태 판정 | idle이 승인을 뜻하지 않음 |
승인 대기 화면에서 자동 입력을 보내지 않는지 확인 |
| 업데이트 | --handoff는 실험적이며 실패 가능 |
지원 서버·설치 방식·팬 수 제한 확인 |
특히 원격 접속과 화면 기록은 보안 검토가 필요합니다. 공식 문서는 패널 화면 기록이 기본으로 꺼져 있는 이유를 비밀값·토큰·프롬프트가 포함될 수 있기 때문이라고 설명합니다. 세션 스냅샷도 실행 프로세스가 아니라 레이아웃과 에이전트 세션 참조를 담는 사적 데이터입니다. 백업이나 공유 대상으로 다룰 때는 터미널 기록과 같은 민감도로 취급해야 합니다.
어떤 팀에 맞는가
Herdr은 GUI 데스크톱 앱을 찾는 사용자보다, 이미 터미널에서 Claude Code와 Codex를 번갈아 쓰는 개발자에게 맞습니다. tmux의 prefix 키와 마우스 조작을 함께 제공하고, 여러 머신의 팬을 한 창에 모으며, 에이전트가 다른 에이전트를 기다리거나 프롬프트를 보내는 자동화를 CLI·소켓 API로 연결합니다.
반대로 GUI 중심의 프로젝트 관리, 시각적인 diff, 클릭으로 승인하는 워크플로를 기대한다면 Herdr만으로는 부족합니다. 에이전트 상태 판정도 화면 기반인 만큼, 중요한 승인은 사람이 팬을 직접 확인하는 편이 안전합니다.
이번 브리핑의 “데스크톱 앱” 표현은 공식 문서와 맞지 않습니다. Herdr은 터미널에서 사는 런타임이고, 강한 지속성은 detach 경로에 한정됩니다. 여러 에이전트를 오래 굴릴수록 “무엇이 복원되는가”보다 “무엇이 다시 시작되는가”를 먼저 확인해야 합니다.
아래 유료 강의는 여러 에이전트의 역할과 작업 전달을 그래프로 설계하는 내용을 다룹니다. Herdr의 설치·운영이나 이 점검표의 재현을 제공하는 강의는 아니며, 링크는 홍보 링크입니다.