저는 Herdr를 위한 VSCode extension을 만들지 않았습니다. 설치를 마친 지 약 1주일 후, 아이디어가 자연스럽게 떠올랐고 — 코드 한 줄을 쓰기도 전에, 유지 관리자(maintainer)를 포함하여 누군가가 이미 계획한 적이 있는지 확인했습니다.

빠른 답변

요약 (TL;DR): 방금 설치한 CLI 도구를 위한 컴패니언 extension을 만들기 전에, 해당 도구의 GitHub Issues, Discussions, Releases에서 "extension" 및 "editor integration"을 검색해 보세요. 그런 다음 관련 extension 마켓플레이스에서 해당 도구의 이름을 검색하세요. 만약 어디에도 계획이 존재하지 않고 이미 사용 중인 다른 도구에 동일한 기능이 이미 존재한다면, 코드 한 줄 쓰지 않고도 답을 얻을 수 있습니다.

Herdr의 경우 구체적으로: GitHub에 그러한 계획은 존재하지 않았고, 이미 다른 곳에 동일한 기능(Claude Code의 자체 VSCode extension, Cursor의 Cloud Agents)이 존재했으며, 이를 만드는 것은 제가 Herdr를 설치한 이유와는 정반대 방향으로 Herdr의 가치를 향하게 만들었을 것입니다. 결론은 건너뛰기(SKIP)였습니다. 그리고 저는 3개월 후에 같은 질문을 다시 고민하지 않도록 그 이유를 기록해 두었습니다.

이미 사용 중이던 것들

Herdr (github.com/ogulcancelik/herdr)는 개발자 ogulcancelik이 만든 오픈 소스 (OSS) Rust CLI로, 터미널 멀티플렉서(terminal multiplexer)인 tmux가 셸(shell)을 멀티플렉싱하는 방식과 유사하게 Claude Code, Codex 등의 AI 코딩 에이전트(AI coding agents)를 멀티플렉싱합니다. 다만, 각 에이전트가 어떤 상태에 있는지도 파악합니다. 백그라운드 서버는 사용자가 분리(detach)된 후에도 에이전트를 활성 상태로 유지하며, 프로세스 이름 매칭과 출력 휴리스틱(output heuristics)을 통해 에이전트가 작업 중인지, 완료되었는지, 아니면 사용자의 입력을 기다리고 있는지 감지합니다. 소켓 API(socket API)와 원격 모드(remote mode)를 통해 외부 스크립트가 해당 상태를 읽고 제어할 수 있습니다. 이 글을 쓰는 시점을 기준으로 21개의 지원되는 에이전트 러너(agent runners)를 나열하고 있으며, 그중 대부분은 설정이 전혀 필요하지 않습니다. 패널에서 에이전트를 시작하기만 하면 Herdr가 이를 감지합니다.

저는 소스 코드 빌드 대신 Homebrew의 stable 채널을 통해 이를 설치했습니다. 새로운 도구는 개발 브랜치(dev branch)가 아닌, 안정적인 릴리스(stable release)가 스스로의 가치를 증명할 시간이 흐른 뒤에야 제 일상적인 워크플로우(workflow)에 편입되기 때문입니다. 저는 Claude Code 및 Codex 통합을 확인하고, 공식 Skill을 배치한 뒤, 단순히 "작동하는 것 같다"는 식의 추측 대신 독립적인 체크를 실행했습니다. 결과는 추측이 아닌 PASS로 나왔습니다. 그 후, 세션에 연결하고, 창을 분할하고, 각 에이전트를 수동으로 시작하는 매일의 시작 의식을 워크스페이스와 첫 번째 에이전트를 한 번의 동작으로 부팅하는 단일 명령어로 압축했습니다. 사소한 일이지만, 하루에도 수없이 실행하는 명령이기에 절약된 동작은 실질적이었습니다.

자연스러운 다음 질문: VSCode 확장 프로그램(extension)을 만들까?

Herdr가 실행되자 명백한 다음 아이디어가 떠올랐습니다. 제 실제 코딩의 대부분은 에디터 내부에서 이루어지므로, 터미널 대신 사이드바(sidebar)에서 에이전트별 Herdr 상태를 볼 수 있다면 좋지 않을까 하는 생각이었습니다.

그것은 나쁜 직관이 아닙니다. 새로운 도구를 더 적극적으로 사용하고 싶어 하는 마음은 보통 그 도구의 진정한 한계를 찾아내는 방법이기도 합니다. 하지만 VSCode 확장 프로그램은 주말 동안 뚝딱 만들 수 있는 결과물이 아닙니다. Herdr는 아직 초기 단계이며 인터페이스가 계속 변하고 있기 때문에, 오늘 이를 기반으로 만든 확장 프로그램은 끝이 없는 유지보수 의무를 물려받게 됩니다. 즉, 아직 필요성을 확인하지도 않은 편의성을 위해 업스트림(upstream)의 모든 변경 사항을 영원히 추적해야 한다는 뜻입니다. "이것이 있으면 좋겠다"는 말은 "이것이 지속적인 유지보수 약속을 할 가치가 있다"는 주장과 동일하지 않으며, 저는 두 번째 주장을 받아들이기 전에 첫 번째 주장을 현실에 비추어 검증하고 싶었습니다.

1차 자료를 확인하며 실제로 알게 된 것

무엇인가를 설계하기 전에 저는 네 가지 독립적인 영역을 확인했습니다. Herdr 자체의 GitHub Issues, Discussions, Releases, 그리고 VSCode 호환 에디터가 실제로 사용할 확장 프로그램 마켓플레이스(extension marketplaces)입니다.

다음은 어떤 저장소(repo)를 기반으로 구축하기 전에 직접 실행해 볼 수 있도록 일반화한 실제 확인 절차의 형태입니다:

# 1. 유지 관리자(maintainer)가 이것을 구축하는 것에 대해 논의한 적이 있는가?
gh issue list -R <owner>/<repo> --state all --search "vscode extension"
gh issue list -R <owner>/<repo> --state all --search "editor integration"
...

# 3단계의 실제 출력 형태, Herdr의 실제 릴리스(release) 기록을 대상으로 실행
# (72개 릴리스 스캔, 일치 항목 0개)

하지만 마켓플레이스(marketplace) 검색 결과가 완전히 '0'은 아니었습니다. 그리고 "이름은 0개지만 기능은 0이 아닌" 이 분리된 결과는 따로 살펴볼 가치가 있습니다. Herdr의 이름을 딴 확장 프로그램은 없지만, 몇몇 확장 프로그램들이 인접한 문제를 해결하고 있습니다. 즉, 에이전트 생명주기 이벤트(agent lifecycle events)에 연결하여 VSCode 사이드바에 세션 상태를 보여주는 방식입니다. 하지만 이들 중 어떤 것도 지속적인 백그라운드 프로세스(background process)를 실행하지 않습니다. 에디터를 닫으면 추적도 함께 중단됩니다. 이는 Herdr의 백그라운드 서버가 수행하는 것과는 실질적으로 다른 능력입니다. 따라서 "마켓플레이스 검색 결과 아무것도 나오지 않았다"는 헤드라인은 틀린 표현이었을 것입니다. "Herdr를 사용할 가치가 있게 만드는 단 한 가지 기능을 복제하는 것은 아무것도 없었다"가 정확한 표현입니다.

왜 비어 있는 이슈 트래커(issue tracker)가 수요가 없음을 증명하지 못할까요?

"유지 관리자가 X를 만들지 않았다"를 "아무도 X를 원하지 않는다"로 해석하는 것은 지름길이며, 초기 프로젝트에서는 위험할 정도로 자주 틀리는 방식입니다. 대부분의 사람들은 아직 의식적으로 원하지 않는 기능에 대해서는 이슈를 제기하지 않기 때문입니다. 비어 있는 트래커 그 자체는 유지 관리자가 해당 기능을 우선순위에 두지 않았음을 알려줄 뿐입니다. 커뮤니티가 그것을 원하는지 여부는 알려주지 않습니다.

그렇기 때문에 마켓플레이스 검색은 단순한 형식적인 절차가 아니라, 두 번째 독립적인 소스로서 매우 중요합니다. 만약 여러 개의 비공식 확장 프로그램(unofficial extensions)들이 Herdr의 핵심 기능을 구현하기 위해 경쟁하고 있었다면, 그 조합 — 즉, 공식적인 침묵과 눈에 보이는 비공식적 수요의 결합 — 은 "수요는 있지만 공식적으로 소유한 주체가 없다"는 것을 의미했을 것이고, 확장 프로그램을 만드는 것은 합리적인 도박이었을 것입니다. 하지만 제가 실제로 발견한 것은 다른 조합이었습니다. 가장 중요한 기능(지속적인 백그라운드 서버)에 대해 공식적인 침묵과 마켓플레이스의 침묵이 동시에 나타났으며, 이는 서로 의존하지 않는 두 소스로부터 동일한 방향을 가리키고 있었습니다. 그 일치된 신호가 저의 직감을 글로 적을 만한 결정으로 바꾸어 놓았습니다.

진짜 결정적 요인: 실현 가능성이 아닌 설계 의도

계획의 부재가 자동으로 "만들지 마라"를 의미하지는 않습니다. 단지 만들지 말아야 할 나쁜 이유 중 하나("공식적인 누군가가 이미 이것을 하고 있다")를 제거할 뿐입니다. 실제 결정은 실현 가능성(feasibility)이 아닌 설계 철학(design philosophy)에서 나왔습니다. 즉, "이것을 만들 수 있는가"가 아니라, "이 도구가 어떤 방향의 투자를 위해 존재하는가"의 문제였습니다.

구조적으로 VSCode 확장 프로그램은 시각화 패널(visualization panel)입니다. 즉, 에이전트(agent)의 상태, 진행 상황, 로그를 인간의 시야로 끌어오는 방식입니다. 그것은 정당한 가치의 종류입니다. Claude Code의 공식 확장 프로그램 자체도 정확히 그 전제를 바탕으로 구축되었습니다. 하지만 제가 처음에 Herdr를 설치했던 이유는 정반대의 방향 때문이었습니다. 즉, 진정으로 다른 동작 방식을 가진 두 에이전트인 Claude Code와 Codex 사이의 조율 — 즉 촉진(facilitation) — 을 제가 아닌 다른 무언가에 맡겨서, 다음번에 어떤 터미널에 주의를 기울여야 할지 제가 수동으로 결정하는 일을 멈추기 위해서였습니다.

그 두 가지 목표는 서로를 향하고 있습니다. 확장을 만드는 것은, 더 적게 보는 것을 목적으로 설치한 도구 위에 "인간이 더 많이 보게 하자"는 투자를 더하는 셈이었습니다. 두 방향 모두 그 자체로는 틀리지 않습니다. 가시성 (visibility)은 실질적인 가치가 있고, 자동화 (automation) 또한 실질적인 가치가 있습니다. 하지만 이 도구가 무엇을 '위한' 것인지 결정하지 않은 채 두 가지를 같은 도구에 쌓아 올리는 것은, 하나의 이름을 가진 두 개의 호환되지 않는 도구로 조용히 변질되는 지름길입니다.

"하지만 CLI는 제한적인 것 같다"는 갈증을 같은 방식으로 테스트하기

개발하지 않기로 결정한 후에도 한 가지 끈질긴 의구심이 남았습니다. "VSCode 확장을 만들면 생 터미널 (bare terminal)을 사용하는 것보다 세션들을 조율하는 것이 덜 어색하지 않을까?" 이것은 수사적인 질문이 아니라 실제적인 느낌이었기에, 저 역시 제 직감이 아닌 1차 자료를 바탕으로 같은 방식으로 테스트해 보았습니다.

Claude Code의 공식 VSCode 확장은 이미 여러 개의 독립적인 탭 세션을 병렬로 실행하며, 각 세션은 고유한 히스토리를 갖는 동시에 파일 변경 사항, 프로젝트 설정, 그리고 CLAUDE.md 규칙은 모든 탭에서 공유됩니다. 숨겨진 탭에 표시되는 배경의 점은 에이전트가 작업을 마쳤을 때 알려주는데, 이는 제가 직접 만들고 싶었을 법한 디테일입니다. Cursor의 Cloud Agents는 한 발 더 나아갑니다. 최대 8개의 에이전트가 독립적인 원격 VM (Virtual Machine)에서 병렬로 실행되므로, "이 기능을 구현해줘"와 "이 버그를 수정해줘"를 각각 맡겨두고 노트북이 온라인 상태를 유지할 필요 없이 준비가 되었을 때 언제든 결과를 확인할 수 있습니다. 이는 완전히 다른 도구임에도 불구하고, Herdr의 백그라운드 서버가 시도하려는 것과 놀라울 정도로 유사합니다.

다시 말해, 그 갈증은 Herdr에 무언가 부족하다는 증거가 아니었습니다. 오히려 제가 이미 사용 중인 두 도구가 이미 해결한 문제를 Herdr에게 다시 해결하라고 요구하고 있었다는 증거였습니다. 확장을 건너뛰었다는 것은, 이미 다른 탭에서 제공되고 있는 기능의 더 나쁜 복사본을 Herdr 내부에 다시 만들지 않았음을 의미합니다.

Herdr가 실제로 제 자리를 찾는 곳

개인 작업(Solo work) — 한 사람이 세션 사이를 전환하는 것 — 은 이미 Claude Code의 탭(tabs)과 Cursor의 Cloud Agents에 의해 엔드 투 엔드(end-to-end)로 커버되고 있습니다. 그 위에 Herdr 전용 패널을 추가하는 것은 새로운 기능을 더하는 것이 아니라, 이미 존재하는 기능의 더 약한 두 번째 버전을 추가하는 것에 불과할 것입니다.

Herdr가 제 가치를 증명하는 지점은 앞서 언급한 단일 벤더(single-vendor) IDE 확장 프로그램들이 하지 못하는 단 한 가지, 즉 도구 간의 조정(cross-tool coordination)입니다. 이를 통해 Claude Code와 Codex가 사람이 매번 메시지를 전달하지 않아도 서로에게 작업을 넘기거나, 막혔을 때 서로에게 위임할 수 있습니다. Claude Code의 확장 프로그램은 Claude Code의 범위 내로 한정됩니다. Cursor의 Cloud Agents는 Cursor의 범위 내로 한정됩니다. 진정으로 서로 다른 에이전트 간의 도구 간 핸드오프(cross-tool handoff)는 현재 Herdr만이 채우고 있는 공백입니다.

이로 인해 세 가지 실행 규칙이 만들어졌습니다: 개인 세션은 이미 해당 기능을 지원하는 에디터 자체의 탭이나 클라우드 에이전트를 통해 실행할 것; 작업이 진정으로 두 개의 서로 다른 에이전트 간의 작업 핸드오프를 필요로 할 때만 Herdr를 열 것; 그리고 이를 위한 전용 UI를 만들지 말 것. 시각화의 가치는 이미 다른 곳에 존재하기 때문입니다. 저는 새로운 AI 도구가 워크플로우에 들어올 때마다 이 갈림길 — 더 많이 시각화할 것인가, 아니면 더 많이 자동화할 것인가 — 을 지켜보며, 해당 패널의 가치가 이미 스택(stack) 어딘가에 존재하는지 확인하기도 전에 "패널을 추가하자"는 유혹에 빠지곤 합니다. Herdr의 범위를 그 하나의 작업으로 좁힌 이후, 저는 Herdr를 여는 횟수가 눈에 띄게 줄었으며, 이제 Herdr를 여는 모든 행위는 특정한 의미를 갖습니다. 즉, 더 이상 세션을 시작하는 기본 방식이 아니라, 에이전트 간 핸드오프를 위한 의도적인 선택이 된 것입니다.

복사-붙여넣기 체크리스트: 컴패니언 확장 프로그램을 만들기 전에 실행하세요

다음에 새로운 CLI 도구가 마음에 들어 "이것을 위한 UI를 만들어야 할까"라는 생각이 들 때, 에디터를 열어 스캐폴딩(scaffolding)을 시작하기 전에 다음 체크리스트를 실행해 보세요:

1, 2단계(실질적인 기능적 중복이 있는 경우) 또는 4단계에 대해 단 하나라도 "예"라는 답변이 나온다면, 무언가를 설계하기 전에 중단해야 한다는 강력한 신호입니다. 5단계는 1~4단계가 모두 깨끗하게(해당 사항 없음으로) 나왔음에도 불구하고 이번 사례의 결정을 내리게 만든 단계였습니다.

FAQ

"X를 요청하는 GitHub Issues가 없다"는 것이 X에 대한 수요가 없다는 뜻인가요?

아니요, 그리고 그렇게 취급하는 것이 바로 이 접근 방식 전체가 피하고자 하는 실수입니다. 비어 있는 트래커(tracker)는 유지 관리자가 이를 우선순위에 두지 않았음을 의미할 뿐, 다른 누군가가 그것을 원하는지 여부에 대해서는 아무것도 말해주지 않습니다. 그렇기 때문에 이를 어떤 식으로든 증거로 읽기 전에는 두 번째의 독립적인 소스(마켓플레이스 검색, 경쟁 구현체)가 반드시 필요합니다. 동일한 방향을 가리키는 두 개의 독립적인 침묵은 실제 신호이지만, 단 하나의 침묵은 신호가 아닙니다.

마켓플레이스 검색 결과 이름은 비슷하지만 기능은 다른 것이 나온다면 어떻게 하나요?

"확장 프로그램이 존재한다"를 "공백이 채워졌다"로 취급하기 전에, 그것이 실제로 무엇을 하는지 읽어보세요. 이 사례의 경우, 여러 마켓플레이스 확장 프로그램들이 인접한 문제(사이드바에 에이전트 세션 상태를 표시하는 것)는 해결했지만, 기반 도구를 사용할 가치가 있게 만든 핵심 기능(분리되어도 유지되는 백그라운드 프로세스)은 복제하지 못했습니다. "무언가가 존재한다"와 "차별화 요소가 존재한다"는 서로 다른 질문입니다. 오직 두 번째 질문만이 당신의 결정을 바꿔야 합니다.

이것은 코드가 아닌 툴링(tooling)에 적용된 YAGNI 아닌가요?