AI 코딩 에이전트를 여러 개 띄우면 개발은 조율하는 일로 변화된다. 한 에이전트는 코드를 수정하고, 다른 에이전트는 테스트를 돌리며, 또 다른 에이전트는 변경 사항을 검토한다. 각 작업은 터미널에서 돌아가지만, 개발자는 어느 창이 무엇을 하는지 계속 기억해야 한다. 작업이 늘수록 어려워지는 것은 에이전트에게 일을 시키는 일보다, 작업의 위치와 진행 상황을 잃지 않는 일이다.
Herdr는 이 문제를 터미널 작업환경의 관점에서 풀려는 도구다. 기존에는 TUI, 즉 터미널 안에서 작동하는 텍스트 기반 인터페이스로 알려졌고, 이제는 별도의 네이티브 데스크톱 앱도 제공한다. 새 앱은 여러 공간과 탭에 터미널을 배치하고, 상태를 보고하는 에이전트를 한 목록에서 확인하며, 창을 닫은 뒤에도 실행 중인 터미널을 유지한다. SSH로 접근할 수 있는 원격 머신도 연결할 수 있다.
다만 Herdr를 “에이전트가 알아서 작업을 나눠 완성하는 가상 개발팀”으로 묘사하면 안된다. Herdr의 중심은 세션 관리와 작업 가시성, 에이전트 간 명령 전달을 돕는 실행 환경이다. 작업을 어떻게 나누고, 결과를 어떻게 검증할지는 사용자와 에이전트가 정해야 한다. 이 차이를 염두에 두고 보면 새 데스크톱 앱이 무엇을 바꾸는지 더 정확히 이해할 수 있다.
TUI와 데스크탑앱은 별개의 실행 환경
먼저 정리해야 할 점은 Herdr TUI와 데스크톱 앱의 관계다. 새 앱은 기존 TUI에 그래픽 화면을 씌운 버전이 아니다. 공식 사이트는 TUI를 자체 서버를 가진 원래의 Herdr로 소개하고, 데스크톱 앱은 herdr-core 위에 만들어진 별도 프로그램이라고 설명한다. 두 제품은 세션을 공유하지 않는다. 따라서 TUI에서 실행한 에이전트가 데스크톱 앱에 자동으로 나타나지는 않는다.
두 인터페이스의 차이는 사용 방식에 있다. TUI는 터미널 안에서 키보드 중심으로 작업하는 흐름에 어울린다. 데스크톱 앱은 독립된 창에서 여러 공간과 탭을 시각적으로 정리하고, 마우스로 오가며, 원격 머신의 작업도 한 사이드바에서 살펴볼 수 있게 한다. 새 앱이 등장했다고 해서 TUI가 사라지는 것도 아니다. 공식 사이트는 기존 TUI가 계속 유지된다고 안내한다.
이 구조에서 데스크톱 앱은 터미널을 없애는 도구가 아니다. 앱의 패널에는 여전히 실제 터미널이 표시되고, 에이전트도 평소처럼 터미널에서 실행된다. 앱은 터미널을 대체하기보다 여러 터미널 세션을 정리하고, 다시 찾아가고, 실행 상태를 살피는 화면을 제공한다.
데스크톱 앱의 기반인 herdr-core는 터미널에서 프로그램과 코딩 에이전트를 실행하고 유지하는 런타임이다. hc라는 명령줄 도구로 작업을 시작하고, 실행 중인 터미널을 확인하거나 다시 연결할 수 있다. 코어는 화면을 그리는 앱이 아니다. 앱이나 셸, 다른 클라이언트가 연결해 사용하는 실행 기반이다.
이 구조의 실용적인 장점은 앱 창과 작업의 라이프싸이클이 분리된다는데 있다. 데스크톱 앱을 닫거나 업데이트해도 코어가 살아 있으면 터미널 속 프로그램은 계속 실행된다. 다시 앱을 열어 같은 세션에 연결하면 진행 상황을 이어서 볼 수 있다. 오래 걸리는 테스트나 에이전트 작업을 실행한 뒤 창을 닫을 수 있다는 뜻이다.
여기서 “계속 실행된다”는 말에는 조건이 있다. 컴퓨터가 재부팅되거나 herdr-core가 종료되면 기존 에이전트 작업이 자동으로 재개되는 것은 아니다. 데스크톱 앱의 공식 안내는 앱이 다시 열릴 때 보존된 패널이 이전 폴더에서 새 셸로 돌아올 수는 있지만, 이전 프로그램이나 에이전트가 자동으로 이어서 실행되지는 않는다고 설명한다. 세션 지속성은 앱 창이 닫혀도 프로세스를 유지한다는 뜻이지, 시스템 장애 뒤 작업을 완벽히 복구한다는 뜻은 아니다.
공간/탭/패널로 작업을 분리
Herdr 데스크톱 앱은 작업을 공간(space), 탭(tab), 패널(pane)로 구성한다. 공간은 보통 하나의 저장소나 머신에서 하는 일을 묶고, 탭은 그 안의 작업을 나누며, 패널은 터미널이나 모드 화면을 나란히 배치하는 데 쓸 수 있다. 예를 들어 한 공간에 기능 개발, 테스트, 코드 리뷰용 탭을 두고, 각 탭 안에 필요한 터미널을 나누어 배치하는 식이다.
이 구조가 해결하는 것은 작업 자체보다 작업을 찾고 전환하는 비용이다. 에이전트가 어느 프로젝트에서 어떤 일을 하는지 화면의 배치로 구분하면, 여러 터미널을 오가며 맥락을 기억해야 하는 부담이 줄어든다. 사용자는 작업별로 다른 세션을 열어두고 필요할 때 이동할 수 있다.
앱에는 에이전트 사이드바도 있다. 상태를 보고하는 에이전트는 working, blocked, done, idle 등으로 표시된다. 에이전트가 작업 중인지, 사용자의 응답을 기다리는지, 완료됐지만 아직 확인되지 않았는지 한 목록에서 살펴볼 수 있다. 다른 에이전트가 시작한 작업자도 목록에 포함될 수 있다.
다만 모든 에이전트가 동일하게 상태를 표시하는 것은 아니다. Herdr는 OSC 7501이라는 공개 상태 프로토콜을 통해 프로그램이 직접 보고한 상태를 읽는다. 이를 지원하지 않는 프로그램도 터미널에서 실행될 수 있지만, 사이드바에서 상태가 보이지 않을 수 있다. Herdr가 화면을 읽고 임의로 상태를 추측하는 구조는 아니다.
에이전트가 다른 에이전트를 실행하고 결과를 받는다.
herdr-core의 hc명령은 한 에이전트가 다른 에이전트를 실행하고, 작업을 보내고, 결과를 읽도록 돕는다. 한 에이전트가 테스트나 코드 리뷰를 위해 보조 에이전트를 시작하고, 작업이 끝나면 결과를 전달받는다. 보조 에이전트가 일하는 동안 처음 에이전트는 자신의 작업을 계속할 수도 있다.
이 흐름은 역할을 나누는 협업 패턴을 가능하게 한다. 구현 에이전트가 코드를 수정하고, 리뷰 에이전트가 변경을 살피며, 별도 터미널에서 테스트를 실행하는 식이다. 결과가 각기 다른 창에 흩어지는 대신, hc를 통한 메시지로 처음 작업한 에이전트에게 돌아오게 할 수 있다.
하지만 이것이 자동으로 일을 분배해 주는 범용 오케스트레이터라는 의미는 아니다. 에이전트가 하위 작업을 언제 만들고, 누구에게 어떤 지시를 보내며, 결과를 어떻게 통합할지는 프롬프트와 에이전트의 동작에 달려 있다. Herdr는 실행과 전달의 통로를 제공하지만, 작업 분할의 품질이나 결과의 정확성을 보증하지 않는다. 하위 에이전트가 중복 작업을 하거나 같은 파일을 동시에 수정할 수도 있다. 결과를 테스트하고 검토하는 책임은 여전히 개발자에게 있다.
따라서 Herdr의 에이전트 협업 기능을 설명할 때는 “리드 에이전트가 자동으로 팀을 지휘한다”보다 “에이전트가 hc를 통해 보조 작업을 실행하고 결과를 전달받을 수 있다”고 생각해야 한다.
자연어로 화면 변경
Herdr 데스크톱 앱의 독특한 점은 사용자가 앱의 레이아웃과 일부 화면 요소를 에이전트에게 수정하게 할 수 있다는 것이다. 공식 안내에 따르면 설정 디렉터리에는 레이아웃, 테마, 키 설정, 모드 파일이 있고, AGENTS.md가 에이전트가 참고할 가이드를 제공한다. 사용자가 “탭마다 에이전트의 작업 시간을 표시해 달라”고 요청하면 에이전트가 관련 모드 파일을 수정하는 예시도 공개되어 있다.
여기서 “자기 수정”은 앱이 스스로 실행 코드를 다시 쓰고 자동 배포한다는 뜻이 아니다. 에이전트가 사용자의 설정 디렉터리에 있는 구성 파일이나 모드 코드를 편집하고, 앱이 변경된 파일을 읽어 화면에 반영하는 방식이다. 공식 문서에서 레이아웃은 창의 배치와 모양을 정의하고, 모드는 패널/메뉴/대화상자 등을 그리는 작은 JavaScript 프로그램으로 설명된다.
레이아웃과 모드를 복사해 개인 버전을 만들고, 이를 편집하는 흐름도 안내되어 있다. 앱은 개인 설정 파일을 다시 읽어 변경을 반영하며, 편집에 오류가 있으면 마지막 정상 버전을 유지하고 오류를 알린다고 README는 설명한다. 이런 구조는 설정 메뉴에 있는 선택지에 머물지 않고, 개발자 자신의 작업 방식에 맞춰 화면을 확장할 수 있게 한다.
커뮤니티 모드는 편리하지만 검토가 필요
공식 사이트에는 여러 예시 레이아웃이 소개되어 있다. 에이전트를 카드 형태로 보여주는 보드, 채널과 대화처럼 배치하는 화면, 미션 컨트롤 스타일, 양치기와 양 떼를 본뜬 Pasture같은 테마가 있다. 사용자는 에이전트에게 특정 레이아웃이나 모드를 추가해 달라고 요청할 수 있다.
커뮤니티 공유 방식은 공개 GitHub 저장소와 RECIPE.md에 기반한다. 레이아웃이나 모드의 구성 파일과 설명을 저장소에 올리고, 다른 사용자는 에이전트에게 설명 파일과 코드를 읽고 적용하도록 요청할 수 있다.
공식 페이지는 커뮤니티 레이아웃과 모드의 코드가 Herdr에 의해 검수되지 않는다고 밝힌다. 사용자의 에이전트가 파일을 읽고 추가하도록 안내하지만, 모드는 샌드박스 확장 기능이 아니라 신뢰된 코드로 취급된다는 점도 README에 명시되어 있다. 그러므로 다른 사람이 만든 모드를 설치할 때는 코드를 검토하거나, 신뢰할 수 있는 출처에서 받아야 한다.
이는 개인화의 자유와 보안 책임이 함께 있다는 뜻이다. 레이아웃이나 패널을 원하는 대로 만들 수 있는 만큼, 그 코드가 어떤 파일과 기능에 접근하는지 살펴야 한다. 회사에서 팀 공용 모드를 쓴다면 저장소에 변경 이력을 남기고, 일반 코드처럼 리뷰하는 절차가 유용하다.
네이티브 앱
데스크톱 앱의 지원 범위는 macOS Apple Silicon, Linux x86-64 및 ARM64, Windows x64다. Linux에서는 데스크톱 세션과 Vulkan 드라이버가 필요하다. Intel Mac 사용자는 소스 빌드 안내를 이용할 수 있다.
앱은 기본 레이아웃으로 Herdr, Terminals, Herdr 98 등을 제공한다. 사용자는 창의 배치나 분위기를 바꿀 수 있지만, 이것은 GUI가 터미널을 대체한다는 뜻은 아니다. 에이전트는 계속 실제 터미널에서 작동한다.
모바일 클라이언트에 대해서도 구분이 필요하다. herdr-core의 API는 다른 클라이언트가 연결할 수 있도록 공개되어 있고, 공식 설명은 전화 앱이나 편집기 패널, Stream Deck 같은 클라이언트를 예로 든다. 이는 외부 개발자가 클라이언트를 만들 수 있다는 가능성을 보여준다.
Herdr의 새 데스크톱 앱이 보여주는 변화는 검은 화면을 화려한 GUI로 대체하는 데 있지 않다. 에이전트는 여전히 터미널에서 실행되고, 개발자는 필요할 때 직접 명령을 입력하고 결과를 읽는다. 달라지는 것은 여러 세션을 한 화면에서 배치하고, 상태를 확인하고, 원격 머신까지 함께 다루는 방식이다.
Herdr가 “에이전트 함대”를 완성된 자율 조직으로 만들어 주는 것은 아니다. herdr-core와 hc는 에이전트가 보조 작업자를 실행하고 결과를 전달하는 기반을 제공하지만, 작업 분해와 품질 관리는 사용자와 에이전트가 함께 설계해야 한다. 레이아웃을 자연어로 바꾸는 기능도 마찬가지다. 에이전트가 파일을 편집해 화면을 바꿀 수 있지만, 커뮤니티 모드의 코드를 검토하고 신뢰할지는 사용자에게 달려 있다.
그럼에도 이 접근은 개발 도구의 무게중심이 바뀌고 있음을 보여준다. 에이전트가 코드를 작성하는 것만큼, 어디서 실행되고 어떤 상태인지, 언제 사람의 판단을 기다리는지를 정리하는 일이 중요해졌다. Herdr는 그 흐름을 공간과 탭, 터미널, 코어, 원격 머신을 통해 한 작업환경으로 묶으려 한다.
개발자에게 필요한 것이 더 많은 에이전트는 아니다. 때로는 여러 작업이 어디에서 돌아가는지 한눈에 보는 일, 창을 닫아도 세션을 유지하는 일, 작업자 에이전트가 끝난 뒤 결과를 다시 받는 일이 더 중요하다.
Herdr 데스크톱 앱은 그 항로를 보여주는 작업환경이다. 함대의 자율성은 아직 사용자의 설계에 달려 있지만, 여러 배가 어디로 가고 있는지를 살피는 화면은 조금 더 분명해진 것 같다.
Sources:
0 Comments:
댓글 쓰기