herdr: 코딩 에이전트를 위한 분리형 터미널 런타임

배경

터미널에서 돌아가는 코딩 에이전트가 빠르게 늘었습니다. Claude Code, Codex, Cursor, OpenCode는 저마다 명령줄 인터페이스를 갖고 있어서, 개발자는 터미널 창을 여러 개 띄워 둡니다. 한 창에서는 프런트엔드를 고치고, 다른 창에서는 테스트를 돌리고, 또 다른 창은 권한 승인을 기다립니다. 창이 많아지면 문제가 생깁니다. 어느 에이전트가 멈췄는지, SSH가 끊기면 실행 중인 작업이 사라지는지, 다른 머신으로 옮기면 세션을 어디서 찾는지 알기 어렵습니다.

전통적인 해법은 tmux입니다. tmux는 세션을 살려 두지만 에이전트라는 개념은 모릅니다. 눈에 보이는 것은 문자 흐름뿐입니다. herdr는 바로 이 틈을 겨냥한 Rust 기반 단일 파일 터미널 런타임입니다. 새로운 에이전트도, 기존 에이전트의 대체품도 아닙니다. 에이전트가 실행되는 터미널을 맡아서, 안정적이고 관찰할 수 있으며 다른 프로그램이 편성할 수 있는 거처를 제공합니다. GitHub 별이 4만 5천 개를 넘어, 같은 고민을 가진 사람이 많다는 점을 보여 줍니다.

심층 분석

herdr는 코딩 에이전트에게 구체적으로 무엇을 해 줄까요? 기능은 네 갈래로 나뉩니다. 첫째는 끊김 없는 분리입니다. 클라이언트를 닫거나 SSH 연결을 잃어도 백그라운드 서비스가 터미널을 계속 실행합니다. 서버나 머신이 재시작되면 저장된 레이아웃을 복원하고, 지원되는 에이전트 세션은 이어 붙일 수 있습니다. 다만 원래 프로세스는 살아남지 않습니다. 복원되는 것은 레이아웃과 세션이지 프로세스 자체가 아니라고 프로젝트가 분명히 밝힙니다.

둘째는 여러 머신을 한 창에 모으는 기능입니다. 로컬 작업과 저장된 ssh 머신이 같은 창에 들어가고 에이전트 목록도 합쳐져 보입니다. 머신마다 따로 다시 연결하므로 한 대가 끊겨도 나머지는 영향을 받지 않습니다. 셋째는 상태 표시입니다. 모든 패널에 working, blocked, idle 표시가 붙어서, 에이전트가 사용자의 답을 기다리며 멈추면 herdr가 바로 알려 줍니다. 창을 하나씩 순찰할 필요가 없습니다.

넷째가 agent-native 인터페이스입니다. 에이전트가 명령줄과 socket API로 herdr를 직접 조작해 새 패널을 만들고, 다른 에이전트에게 프롬프트를 보내고, 상대가 실제로 막힐 때까지 기다린 뒤 움직입니다. 별도의 편성 프레임워크 없이 터미널 자체가 협업 공간이 됩니다. Claude Code, Codex, Cursor, OpenCode, Grok이 그대로 실행되며, herdr는 감싸지 않고 터미널만 소유합니다. tmux 스타일 접두 키와 마우스 조작을 지원하고, 플러그인과 플러그인 마켓도 있습니다.

산업 영향

시작은 간단합니다. curl 스크립트 한 줄, brew install herdr, mise use -g herdr 중 하나로 설치하고, Windows에는 PowerShell 설치 스크립트가 있습니다. 작업 디렉터리에서 herdr를 실행해 에이전트 몇 개를 띄우고 패널을 나눈 뒤, ctrl+b q로 분리하고 다시 herdr를 실행하면 재접속됩니다. 원격 개발 머신에서 에이전트 여러 개를 돌려 두고 저녁에 노트북을 닫았다가 다음 날 다시 연결해도, 레이아웃과 세션이 남아 있고 답을 기다리는 패널이 한눈에 보입니다.

문서 사이트는 빠른 시작, 핵심 개념, 지원 에이전트, 키 바인딩, 설정, 세션 상태, 다중 머신 연결, 원격 지속성, 통합, 플러그인, socket API를 다룹니다. 저장소에는 AGENTS.md와 CONTRIBUTING.md가 있고, 저장소에서 일하는 AI 에이전트가 변경 전에 읽도록 요구합니다. 에이전트를 주요 사용자로 보는 프로젝트다운 선택입니다. 기여자는 cargo build --release로 빌드하고 just test와 just check로 검증합니다.

산업적 의미는 터미널을 에이전트 시대의 기반 시설로 다시 설계했다는 데 있습니다. 에이전트는 오래 실행되고, 서로 협력하며, 여러 머신에 흩어집니다. 그러려면 누가 일하고, 누가 막혔고, 누구를 깨울 수 있는지 아는 바닥층이 필요합니다. 엔지니어링 팀에게는 여러 에이전트를 동시에 관리하는 주의력 비용을 줄여 주는 도구입니다.

전망

위험도 있습니다. 첫째, 복원은 프로세스가 살아 있다는 뜻이 아닙니다. 재시작 뒤 이어 가기는 각 에이전트의 세션 복구 지원에 달려 있으므로 당연하게 여기면 안 됩니다. 둘째, socket API로 에이전트가 패널을 만들고 서로 지시를 보낼 수 있으므로, 특히 여러 머신에 걸쳐 쓸 때 권한 경계와 보안 범위를 사용자가 직접 점검해야 합니다. 셋째, 에이전트별 상태 인식에는 적응 작업이 필요해서, 에이전트가 업데이트로 동작이 바뀌면 따라가야 할 수 있습니다.

입력 자료에서 라이선스 설명이 잘려 있었으므로, 팀에 도입하기 전에 저장소에서 라이선스 조항을 먼저 확인해야 합니다.

앞으로 볼 지점은 세 가지입니다. 플러그인 마켓이 실제 생태계로 자랄지, 지원 에이전트 범위가 어디까지 넓어질지, 에이전트끼리 기다리고 프롬프트를 주고받는 협업 방식이 실제 프로젝트에서 안정적인 작업 흐름으로 자리 잡을지입니다. 답에 따라 herdr가 편리한 멀티플렉서에 머물지, 에이전트 기반 개발의 표준 런타임 계층이 될지 가려질 것입니다.