CLI 기반 코딩 에이전트를 오래 다뤄본 개발자라면 익숙한 풍경이 있다. 터미널 창 여러 개에 에이전트를 띄워 놓고, 어느 창에서 무엇이 돌고 있는지, 어떤 작업이 멈췄는지, 어디에 답을 줘야 하는지 놓치기 시작하는 순간이다. Herdr를 혼자 만든 개발자 Can은 이 상황을 두고 "내가 병목이 됐다"고 표현했다. 그는 최근 자신의 프로젝트 Herdr가 Y Combinator F26 배치에 합류한다고 밝히면서, 동시에 지금 쓰는 런타임은 계속 무료이며 Apache-2.0 라이선스로 열려 있을 것이라고 못박았다.
에이전트를 위한 '런타임'이라는 발상
Herdr가 스스로를 규정하는 핵심 개념은 '런타임'이다. Can의 설명은 단순하다. 터미널은 개발자가 코드를 고치고, 서버를 띄우고, CI와 설정을 관리하는 근본적인 공간이며, 그렇다면 에이전트에게도 그 안에서 일급(first class) 프리미티브가 필요하다는 것이다. Herdr는 이를 계층 구조로 정리한다. 하나의 터미널 페인(pane)은 하나의 에이전트에 속하고, 페인은 탭에, 탭은 프로젝트에 속한다. 산더미처럼 쌓인 에이전트 목록에 파묻히는 대신, 작업을 프로젝트 단위로 나눠 한눈에 상태를 파악하고, 정말로 사람의 개입이 필요할 때만 알림을 받자는 설계다.
또 하나의 축은 지속성이다. 요즘 에이전트는 몇 시간, 때로는 며칠씩 돌아간다. 실행 자체를 런타임이 책임지면 '어디서 도는가'는 부차적인 문제가 된다. 노트북이든 원격 서버든 에이전트를 띄워 놓고 계속 유지할 수 있어야 한다는 것이 Herdr가 지향하는 방향이다.
번들된 TUI, 그리고 그 위에 쌓인 생태계
런타임에는 인터페이스가 필요하고, Herdr의 기본 얼굴은 TUI(터미널 UI)다. 흥미로운 점은 이 TUI가 별도 설치물이 아니라 Herdr에 함께 묶여 있다는 것이다. VPS에 Herdr를 설치하고 ssh로 접속하면 UI가 이미 거기 있다. herdr --remote user@host를 실행하면 원격지에 스스로 설치된다. 네트워크 속도에 따라 몇 초 만에 에이전트를 돌리는 상태에 도달할 수 있다는 점이, Can이 TUI를 앞으로도 일급 클라이언트로 유지하겠다고 말하는 이유다.
다만 그는 TUI가 유일한 클라이언트일 필요는 없다고 본다. 런타임이 열려 있으니 사람들이 그 위에 무언가를 만들었고, 실제로 만들어졌다. Raycast 확장, Herdr용 버튼을 넣은 Stream Deck 구성, 휴대폰에서 세션 전체를 조종하는 iOS 앱이 등장했다. 마켓플레이스가 공개된 지 한 달 만에 500개가 넘는 플러그인이 올라왔고, 이 중 어느 것도 Can 본인이 만든 것이 아니다. 이런 흐름 덕분에 이 솔로 프로젝트는 GitHub 스타 2만5천 개, 다운로드 34만 건에 도달했다고 그는 밝혔다.
AGPL에서 Apache로, 그리고 회사화의 의미
이번 발표에서 실무자가 주목할 대목은 라이선스 변경이다. Can은 Herdr를 최근 AGPL에서 Apache-2.0로 전환했다고 밝혔다. AGPL은 네트워크를 통한 사용까지 소스 공개 의무를 확장하는 강한 카피레프트 라이선스인 반면, Apache-2.0은 상업적 이용과 폐쇄형 파생물을 폭넓게 허용하는 관대한 라이선스다. 그가 든 이유는 명확하다. 누구나 아무 문제 없이 자유롭게 Herdr를 쓰게 하고 싶다는 것이다. 회사와 자본이 들어오는 시점에 오히려 라이선스의 결속력을 낮춘 선택은, 코어 런타임을 상업화의 대상이 아니라 공용 기반으로 남기겠다는 신호로 읽힌다.
그렇다면 투자금은 어디에 쓰이나. Can은 런타임을 건강하고 견고하며 빠르게, 어디서나 쉽게 돌아가고 더 확장 가능하게 유지할 작은 팀을 만들고 싶다고 했다. 스스로도 다른 사용자들처럼 열린 런타임 위에서 기능을 얹겠다는 태도다. 그가 지목한 당면 과제는 흩어진 실행 환경의 연결이다. 노트북, 여섯 시간짜리 작업을 맡길 VPS, 위험한 코드와 일회성 에이전트를 위한 샌드박스가 각각 존재하지만 지금은 서로 단절돼 있다는 것이다.
실무적으로 무엇을 보면 되나
Herdr의 서사에서 되짚을 지점은 '코어를 작게 유지한다'는 원칙이다. 기능 하나 더 넣는 비용이 사실상 공짜인 시대에, 무엇을 코어에 넣지 않을지가 가장 중요한 결정이라는 관점이다. 개인의 스타일, 작업 흐름, 회사 설정, 테마 같은 것은 모두 확장으로 밀어내고 코어는 얇게 남긴다. 이는 개별 개발자가 자신의 워크플로에 맞춰 조립할 여지를 넓혀 주지만, 동시에 '기본 제공되는 것'과 '직접 붙여야 하는 것'의 경계를 사용자가 스스로 관리해야 한다는 뜻이기도 하다.
한계도 분명하다. Can 스스로 TUI 안에서 구현하기 어려운 아이디어가 있고 더 많은 클라이언트가 필요하다고 인정한 만큼, 여러 머신을 잇는 연결 기능은 아직 청사진에 가깝다. 회사화 이후 오픈소스 코어와 유료 기능 사이의 선이 어떻게 그어질지, Apache-2.0 약속이 장기적으로 어떻게 지켜질지는 앞으로의 실행에서 확인할 문제다. 에이전트를 상시로 돌리는 팀이라면, 지금은 라이선스가 관대해진 오픈 런타임을 실험해 보되 로드맵의 무게중심이 어디로 이동하는지 함께 지켜보는 편이 합리적이다.