아무도 이야기하지 않는 문제: 에이전트 확산 (Agent Sprawl)

개발자들은 조용히 에이전트 문제를 축적하고 있습니다. 이제 단 한 명의 엔지니어가 서로 다른 작업을 위해 Claude, Codex, Cursor 에이전트를 병렬로 실행하는 것이 일상이 되었습니다. 하나는 모듈을 리팩터링하고, 다른 하나는 테스트를 작성하며, 세 번째는 문서를 처리합니다. 각 에이전트는 완전히 격리된 상태로 작동합니다. 공유된 런타임(runtime)도, 통합된 가시성 계층(visibility layer)도 없으며, 에이전트 집단이 특정 순간에 실제로 무엇을 하고 있는지 추적하기 위한 표준 프로토콜도 없습니다.

도구의 격차는 모델 계층에 있는 것이 아닙니다. GPT-4o, Claude Sonnet, Gemini는 모두 프로덕션 품질의 코드를 생성할 수 있는 능력을 갖추고 있습니다. 진짜 인프라의 구멍은 개발자와 에이전트 사이, 즉 오케스트레이션 계층(orchestration layer), 프로세스 관리, 그리고 네 개의 서로 다른 터미널 창이나 브라우저 탭을 전환하지 않고도 동시 실행되는 에이전트 세션을 감독할 수 있는 능력 사이에 존재합니다. 아무도 이 부분에 대한 솔루션을 출시하지 않고 있습니다.

Can Celik은 이 격차를 인식하고 Rust로 작성된 터미널 네이티브 에이전트 멀티플렉서(multiplexer)인 herdr를 구축했으며, 이는 이미 거의 10,000개의 GitHub 스타를 보유하고 있습니다. 이 프로젝트의 프레임워크는 정확합니다. herdr는 또 다른 AI 모델 래퍼(wrapper)나 채팅 인터페이스가 아니라, 에이전트 시대를 위한 런타임(runtime)입니다. 이는 여러 코딩 에이전트를 실행하는 것을 전용 런타임 솔루션을 요구하는 운영 문제로 취급합니다.

대부분의 AI 코딩 관련 논의는 벤치마크 비교에 집착합니다. 어떤 모델이 HumanEval을 가장 빠르게 완료하는지, 어떤 모델이 복잡한 알고리즘에서 환각(hallucination)을 덜 일으키는지에 집중합니다. 그러한 대화는 개발자가 단일 에이전트 세션을 넘어 확장하는 순간 직면하게 되는 운영상의 복잡성을 간과합니다. 병렬 AI 워크스트림(workstreams)을 조정하고, 동시 프로세스 전반에서 에이전트 출력을 모니터링하며, 자동화된 코딩 파이프라인에 대한 개발자의 감독을 유지하는 것은 인프라 문제입니다. 이는 컨테이너 런타임(container runtimes)이 마이크로서비스(microservices) 관리에 가져온 것과 동일한 진지함으로 구축된 에이전트 오케스트레이션 도구를 필요로 합니다.

표준화된 에이전트 관리 계층(agent management layer)의 부재는 현재 모든 팀이 셸 스크립트(shell scripts), tmux 설정, 임시 로깅(ad hoc logging)과 같이 각자 자신만의 짜깁기된 솔루션을 만들어내고 있음을 의미합니다. 에이전트 확산(Agent sprawl)은 이미 일어나고 있습니다. 이를 해결하기 위한 개발자 도구(developer tooling) 카테고리는 이제 막 형성되기 시작했습니다.

herdr의 실체 — 그리고 왜 '멀티플렉서(Multiplexer)'가 핵심 키워드인가

Can Celik은 많은 것을 함축하는 한 줄의 설명으로 herdr를 구축했습니다: "터미널에서 실행되는 에이전트 멀티플렉서(agent multiplexer)". 이 문장의 단어 하나하나가 중요한 의미를 담고 있습니다.

멀티플렉서(multiplexer) 개념은 시스템 프로그래밍(systems programming)에서 유래되었습니다. 멀티플렉서는 단일 인터페이스를 통해 여러 데이터 스트림을 관리합니다. 여러 터미널 세션을 처리하는 tmux나, 연결을 통해 패킷을 라우팅하는 네트워크 스위치를 생각하면 됩니다. Celik은 이 아키텍처(architecture)를 빌려와 AI 코딩 에이전트(AI coding agents)에 적용했습니다. 한 번에 하나의 에이전트를 실행하고 GUI를 통해 일일이 관리하는 대신, herdr는 여러 에이전트를 동시에 실행하고 하나의 지속적인 인터페이스를 통해 이를 노출합니다. 그 결과는 채팅창이 아니라, 에이전트 워크로드(agentic workloads)를 위한 제어 평면(control plane)입니다.

터미널 네이티브(terminal-native) 방식의 결정은 미학적인 선택이 아닌 아키텍처적인 선택입니다. 터미널 내부에서 실행됨으로써 herdr는 가볍고 조합 가능한(composable) 상태를 유지합니다. 개발자들은 이를 기존 셸 스크립트(shell scripts)로 파이프(pipe) 연결하거나, 다른 CLI 도구들과 체이닝(chain)하고, 이미 커맨드 라인(command line)에서 실행 중인 워크플로에 통합할 수 있습니다. 설치해야 할 Electron 앱도, 계속 열어두어야 할 브라우저 탭도, 메모리를 잡아먹는 별도의 대시보드도 없습니다. 이 도구는 개발자들이 이미 작업하고 있는 환경에 딱 들어맞습니다.

"런타임(runtime)"이라는 프레이밍(framing)은 가장 전략적인 무게감을 가집니다. 유틸리티(utilities)는 일회성입니다. 실행하고, 출력을 얻고, 종료하면 됩니다. 하지만 런타임(runtime)은 인프라(infrastructure)입니다. 지속적으로 실행되며, 프로세스 라이프사이클(process lifecycles)을 관리하고, 다른 것들이 의존하는 기질(substrate) 역할을 합니다. Celik은 herdr를 명시적으로 "에이전트 시대의 런타임(the runtime for the agent era)"으로 포지셔닝하며, 목표가 단일 목적의 도구가 아니라 에이전트 기반 개발 워크플로 하단에 위치하는 지속적인 계층(layer)임을 시사합니다.

Rust로 구축된 오픈 소스인 herdr는 GitHub 별(star) 9,717개를 달성했습니다. 이는 GUI로 감싸진 대안들보다 터미널 네이티브 (terminal-native) 에이전트 오케스트레이션 (orchestration)에 대한 개발자들의 진정한 관심이 있음을 나타내는 신호입니다. Celik은 수익 없이 herdr 개발에 전념하고 있으며, 개인 후원자를 위한 월 25달러부터 로고 배치가 포함된 Gold 레벨 후원까지 제공되는 GitHub Sponsors를 통해 개발 자금을 조달하고 있습니다.

이러한 조합 — 멀티플렉서 (multiplexer) 모델, 터미널 상주 (terminal residency), 런타임 (runtime) 포지셔닝 — 은 하나의 특정한 베팅을 정의합니다. 즉, AI 에이전트를 관리하는 것은 SaaS 제품을 사용하는 것보다 시스템 프로세스 (system processes)를 관리하는 것과 더 유사해야 한다는 것입니다.

오픈 소스, 무수익 베팅 — 그리고 이것이 신뢰에 중요한 이유

Celik은 수익이 전혀 없는 상태에서 herdr를 전업으로 구축할 수 있을까요? 벤처 캐피털(VC)도, 기업 계약도, 프리미엄 (freemium) 깔때기도 없습니다. 이 프로젝트는 전적으로 GitHub Sponsors를 통해 운영되며, 개인 후원자는 월 25달러부터 시작하고 기업 로고 배치는 Gold 티어부터 시작됩니다. 대부분의 개발 도구 스타트업들이 Series A 라운드나 대형 플랫폼과의 인수 논의를 향해 달려가는 2025년의 상황에서 이는 이례적인 입장입니다.

이 자금 조달 모델은 의도적인 선택이며, herdr가 구축되는 방식에 실질적인 영향을 미칩니다. 기관의 자금을 지원받는 도구들은 워크플로 (workflow) 데이터를 수익화하거나, 독점적인 락인 (lock-in)을 도입하거나, 유료 결제 장벽 뒤에 기능을 숨겨야 한다는 압박에 직면합니다. 개발자와 여러 자율 코딩 에이전트 (autonomous coding agents) 사이에 위치하는 AI 에이전트 런타임은 바로 그러한 인센티브가 위험해질 수 있는 인프라의 전형입니다. ogulcancelik/herdr 리포지토리(repository)를 통해 GitHub에 호스팅되는 herdr의 오픈 소스 코드베이스는 누구나 런타임이 에이전트 프로세스, 세션 상태 (session state), 그리고 터미널 출력 (terminal output)에 실제로 무엇을 하는지 감사(audit)할 수 있게 해줍니다. 포크(Fork)하고, 검사하고, 기여하십시오 — 코드는 공개되어 있습니다.

이러한 감사 가능성(auditability)은 거의 다른 어떤 개발자 인프라(developer infrastructure) 카테고리보다 에이전트 오케스트레이션(agent orchestration) 도구에서 더 중요합니다. 도구가 터미널 환경에서 동시에 실행되는 여러 AI 에이전트를 관리할 때, 런타임(runtime) 계층에 대한 신뢰는 선택 사항이 아닙니다. 개발자들은 도구가 외부로 데이터를 전송(phoning home)하거나, 출력을 재구성하거나, 나중에 마이그레이션(migration)을 고통스럽게 만드는 독점적인 의존성 체인(proprietary dependency chains)을 구축하지 않는다는 것을 알아야 합니다.

Celik이 이를 독립적으로 구축하고 있다는 사실 또한 시장에 대해 무언가를 시사합니다. 에이전트 멀티플렉싱(Agent multiplexing), 터미널 네이티브(terminal-native) AI 워크플로, 그리고 멀티 에이전트 런타임 조정(multi-agent runtime coordination)은 아직 지배적인 상용 모델이 등장하지 않을 정도로 초기 단계입니다. 이 영역은 Salesforce, Microsoft 또는 주요 클라우드 제공업체들에 의해 점유되지 않았습니다. 그 공백이야말로 독립적인 오픈 소스 빌더들이 가장 잘 활동할 수 있는 지점입니다. 즉, 빠르게 움직이고, 투자자가 아닌 사용자에게 책임을 다하며, 통합의 물결이 오기 전에 아키텍처적 선례(architectural precedents)를 세우는 곳입니다.

herdr의 9,700개 이상의 GitHub 스타는 개발자들 또한 이 공백을 인식하고 있음을 시사합니다. 후원(Sponsorship)은 프로젝트를 유지시키고 로드맵을 외부의 간섭으로부터 자유롭게 유지합니다.

더 큰 비전: '에이전트 시대'를 위한 런타임

Celik은 herdr를 생산성 도구나 개발자 편의 도구로 설명하지 않습니다. 그는 이를 "에이전트 시대를 위한 런타임(the runtime for the agent era)"이라고 부르는데, 이는 점진적인 개선이 아닌 근본적인 야망을 나타내는 문구입니다.

이러한 프레이밍(framing)은 중요합니다. 런타임은 액세서리가 아니라, 다른 모든 것이 실행되는 기질(substrate)입니다. Celik이 herdr를 대시보드나 래퍼(wrapper)가 아닌 런타임으로 포지셔닝할 때, 그는 AI 에이전트 오케스트레이션이 인프라 스택(infrastructure stack)의 어디에 위치하는지에 대해 주장하고 있는 것입니다. 즉, 최상단이 아닌 최하단에 위치한다는 것입니다.

Docker와의 역사적 평행 이론을 무시하기는 어렵습니다. 컨테이너화 (containerization) 이전에는 소프트웨어를 배포한다는 것이 환경 불일치, 취약한 의존성 (dependencies), 그리고 부서지기 쉬운 서버 설정과 씨름하는 것을 의미했습니다. Docker는 배포를 단순히 조금 더 쉽게 만든 것이 아니라, 배포의 정의를 재정립했으며 클라우드 시대의 필수적인 인프라 (infrastructure)가 되었습니다. herdr와 같은 에이전트 런타임 (agent runtimes)도 동일한 종류의 전환을 목표로 자리 잡고 있습니다. 현재로서는 여러 AI 코딩 에이전트를 병렬로 실행하는 것이 어색하고 수동적입니다. 만약 멀티 에이전트 (multi-agent) 개발이 표준 관행이 된다면 — 그리고 그 궤적은 그렇게 될 것임을 시사합니다 — 오케스트레이션 계층 (orchestration layer)은 하중을 견디는 핵심 인프라가 될 것입니다.

그러한 변화는 문제의 틀을 완전히 바꿉니다. AI 에이전트 그 자체는 어려운 부분이 아닙니다. Claude, GPT-4, Gemini, 그리고 오픈 소스 (open-source) 모델들은 이미 자율적으로 코드를 작성, 테스트 및 리팩터링 (refactor)할 수 있을 만큼 충분히 유능합니다. 어려운 부분은 수십 개의 에이전트를 동시에 실행할 때 발생하는 일을 관리하는 것입니다. 즉, 에이전트 간의 작업 스케줄링 (scheduling), 세션 상태 모니터링 (monitoring), 장애가 연쇄적으로 발생하기 전 포착하기, 그리고 인간 개발자가 에이전트 무리 (herd)를 의미 있게 제어할 수 있도록 유지하는 것입니다. 에이전트 생명주기 관리 (agent lifecycle management), 터미널 멀티플렉싱 (terminal multiplexing), 병렬 실행 제어 (parallel execution control)와 같은 이러한 관리 계층이 바로 herdr가 점유하기 위해 구축된 영역입니다.

Celik은 수익 없이 GitHub Sponsors를 통해 개발 자금을 전적으로 조달하며 herdr를 전업으로 구축하고 있습니다. 이는 자본력이 탄탄한 기존 업체들이 시장을 통합하기 전에, 에이전트 오케스트레이션 런타임이 핵심 인프라가 될 것이라는 데 거는 베팅입니다. herdr 리포지토리 (repository)가 거의 10,000개의 GitHub 스타 (stars)를 기록하고 있는 것을 보면, 개발자 커뮤니티도 이 베팅을 진지하게 받아들이고 있습니다.

더 넓은 산업계가 여기서 얻어야 할 점

대형 AI 연구소(Large AI labs)들은 모델 역량(model capability)에 수십억 달러를 쏟아붓고 있습니다. OpenAI, Anthropic, Google은 벤치마크 경쟁에 몰두하고 있는 반면, 운영 계층(operational layer) — 즉, 에이전트가 실제 프로덕션 환경에서 어떻게 실행되고, 지속되며, 확장되는지 — 에 대한 문제는 그들 중 누구도 제대로 다루지 않고 있습니다. 독립적인 프로젝트들이 그 공백을 메우고 있습니다. GitHub 별(star) 수가 거의 10,000개에 달하는 Rust 기반의 에이전트 멀티플렉서(agent multiplexer)인 herdr는, 기업 팀들이 결국 대규모 환경에서 해결해야 할 격차를 풀어나가는 풀뿌리 인프라의 가장 명확한 사례 중 하나입니다.

herdr의 터미널 네이티브(terminal-native) 설계 철학은 AI 도구에 대한 널리 퍼진 가정, 즉 개발자용 제품이 채택되기 위해서는 세련된 웹 인터페이스(web interfaces)가 필요하다는 생각에 도전합니다. 파워 유저들에게는 심미성보다 구성 가능성(composability)이 더 중요합니다. 터미널에서 실행되는 런타임(runtime)은 기존의 쉘 스크립트(shell scripts), CI 파이프라인, 워크플로 자동화(workflow automation)에 깔끔하게 통합됩니다. 이는 인프라가 마땅히 갖춰야 할 모습, 즉 스크립트 작성이 가능하고(scriptable), 관찰 가능하며(observable), 개발자의 스택에 이미 존재하는 모든 것과 구성 가능한(composable) 방식으로 동작합니다. GUI 래퍼(wrappers)는 가장 빠르게 움직이는 엔지니어들에게 오히려 마찰(friction)을 더할 뿐입니다.

지속 가능성 측면도 중요합니다. herdr의 유일한 개발자인 Celik은 개인 후원자를 위한 월 25달러부터 시작하여, Gold 티어의 기업을 위한 로고 노출까지 확장되는 계층형 GitHub Sponsors 구조를 구축했습니다. 파트너십 문의는 hey@herdr.dev로 직접 연결됩니다. 이는 수익이 없는 상태에서 오픈 소스 에이전트 오케스트레이션(agent orchestration) 인프라에 전념하고 있는 개발자가 프로젝트의 장기적인 자생 방안에 대해 여전히 체계적으로 고민하고 있음을 보여줍니다. 이러한 태도는 성숙함을 나타냅니다. 너무 많은 오픈 소스 프로젝트들이 자금이 필요해지기 전에 펀딩 모델을 구축하지 못해, 채택 규모의 무게를 견디지 못하고 무너집니다.

AI 개발 도구 분야에 주는 더 넓은 교훈은 다음과 같습니다: AI 코딩 에이전트(AI coding agents)를 위한 런타임(runtime) 및 오케스트레이션(orchestration) 계층은 아직 개척되지 않은 영역입니다. 복잡한 코드베이스 전반에서 여러 에이전트를 실행하는 기업들은 프로세스 관리(process management), 세션 제어(session control), 그리고 멀티 에이전트 조정(multi-agent coordination) 기능이 필요하지만, 현재 어떤 주요 벤더도 이를 일급 제품(first-class product)으로 출시하고 있지 않습니다. 커맨드 라인(command line) 환경에서 작업하는 개발자들을 위해 구축된 터미널 네이티브 에이전트 런타임(Terminal-native agent runtimes), 에이전트 프로세스 관리자(agent process managers), 그리고 AI 워크플로우 오케스트레이터(AI workflow orchestrators)는 그 궁극적인 중요성에 비해 아직 초기 단계이며 자금 지원도 부족한 카테고리에 속합니다. 현재 이 분야에서 강력한 아키텍처 기반과 초기 지속 가능성에 대한 고민을 바탕으로 진지하게 구축되고 있는 프로젝트들이, 향후 에이전트 기반 개발 인프라(agentic development infrastructure)가 대규모로 어떻게 구성될지를 정의하게 될 것입니다.

원문은 Newzlet에 게시되었습니다.