Herdr로 LLM 오케스트레이션 액기스 모음

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Herdr로 LLM 오케스트레이션을 구성하는 핵심은 메인 에이전트와의 대화를 유지하면서 작업을 별도 세션·워크트리·원격 컴퓨터에 나누어 맡기는 것이다.

📌 핵심 요점

1. Herdr는 여러 에이전트를 관리하는 터미널 UI다. 워크스페이스·탭·패널로 작업을 구성하고, 사이드바에서 실행 중인 에이전트와 완료·대기·막힘 상태를 확인한다.
2. 수동 조작을 익힌 뒤에는 Herdr 스킬과 CLI를 통해 화면 구성까지 에이전트에 맡긴다. 워크트리 생성, 워크스페이스 등록, 패널 분할, 다른 에이전트 실행을 자연어 요청으로 연결하는 방식이다.
3. 메인 에이전트는 기획과 대화를 담당하고, 구현은 독립된 세션에 위임한다. 시연에서는 코덱스와 논의를 이어가면서 클로드 패널에 구현 지시와 프롬프트 작성을 넘긴다.
4. 여러 구현안이나 모델을 병렬로 실행하고 결과를 비교할 수 있다. 코드 작업은 별도 워크트리에서 진행한 뒤 선택한 결과를 병합하고, 콘텐츠나 콘셉트 비교는 폴더·탭으로 나누는 활용을 제안한다.
5. 등록한 원격 컴퓨터에도 작업을 배정할 수 있다. 로컬과 원격 실행을 한 화면에서 관리하며, 반복적인 테스트를 분산하거나 Tailscale을 통해 외부에서 연결하는 활용까지 소개한다.

🧩 배경과 문제 정의

여러 프로젝트에서 클로드와 코덱스를 함께 사용하면 터미널 창을 열고, 일을 배정하고, 병렬 작업의 진행 상태를 확인하는 관리 부담이 생긴다. 발표자는 이 부담을 줄이기 위해 AI가 다른 에이전트를 실행하고 작업을 전달하도록 구성한 자신의 워크플로우를 소개한다.

영상은 Herdr의 기본 화면 조작에서 출발해 스킬을 통한 자동 제어, 메인 에이전트와 실행 에이전트의 역할 분리, 여러 구현안의 병렬 생성으로 범위를 넓힌다. 후반부에는 원격 컴퓨터를 등록하고 로컬과 원격 작업을 함께 관리하는 방법, 반복 테스트 분산과 Tailscale을 통한 외부 접속을 다룬다.

핵심 문제는 에이전트 수를 늘리는 것만이 아니라 대화 맥락을 유지하면서 실행 환경과 작업을 나누고, 진행 상태와 결과를 다시 한곳에서 확인하는 흐름을 만드는 것이다.

🕒 시간순 섹션별 상세정리

1. 여러 에이전트를 직접 관리하는 번거로움

• 여러 프로젝트에서 클로드와 코덱스를 함께 쓰며 창을 열고 작업을 배정하는 과정이 번거로웠다고 보여준다. [00:17]
• AI가 다른 에이전트를 띄우고 지시와 소통을 맡도록 구성한 자신의 작업 방식을 보여준다. [00:34]
• Herdr 터미널 UI와 함께 여러 컴퓨터의 에이전트를 로컬에서 병렬로 관리하는 방법까지 보여주겠다고 예고한다. [01:10]

2. 터미널 선택과 Herdr 실행

• Ghostty를 추천하되, 사용자가 선호하는 다른 터미널 에뮬레이터를 사용해도 된다고 드러낸다. [01:22]
• 터미널 UI를 사용하는 만큼 기반 터미널의 성능이 중요하다고 설명하고, 운영체제별 설치 경로를 간략히 안내한다. [01:54]
• 터미널에서 Herdr를 실행한 뒤, 이미 설정된 자신의 화면과 초기 사용자 화면이 다를 수 있음을 보여준다. [02:11]

3. 워크스페이스와 탭의 기본 구조

• 화면은 사이드바와 메인 영역으로 구성되며, 사이드바에는 워크스페이스와 에이전트 목록이 위치한다. [02:27]
• 다른 컴퓨터를 연결하면 해당 컴퓨터에서 Herdr와 AI를 실행하는 작업 공간에 접근할 수 있다고 보여준다. [03:01]
• New 버튼으로 탭을 만들고 이름을 바꾸며, 단축키 외에도 마우스로 기본 조작을 할 수 있음을 보여준다. [03:42]

4. 패널 분할과 에이전트 상태 확인

• 클로드를 실행한 뒤 오른쪽과 아래쪽으로 패널을 나누어 코덱스 등을 함께 실행하는 모습을 보여준다. [04:21]
• Ctrl+B를 접두 키로 사용해 V와 마이너스 키로 분할하고, Z로 선택한 패널을 확대하거나 원래 배치로 되돌린다. [05:04]
• 사이드바의 표시와 필터로 작업 중·완료·대기 상태를 살피고, 막힌 에이전트는 접근해 필요한 권한을 확인한다고 보여준다. [05:53]

5. 스킬로 워크트리와 워크스페이스 생성

• 파일 생성과 초기 커밋을 요청한 뒤, 새 워크트리를 만들고 워크스페이스에 등록하는 작업을 자연어로 지시한다. [06:18]
• Herdr 스킬이 CLI를 통해 기능을 사용하면서 직접 화면을 조작해야 했던 과정을 대신한다고 보여준다. [06:41]
• 새 워크스페이스가 나타나고, 그 안의 작업이 생성한 워크트리에서 진행되는 구성을 확인한다. [06:55]

6. 워크트리 배치와 탭의 활용 구분

• 별도 워크스페이스를 추가하는 대신 현재 탭 오른쪽에 새 워크트리의 코덱스 패널을 만들어 달라고 요청한다. [07:21]
• 같은 탭에서 여러 워크트리를 함께 보거나, 워크스페이스로 따로 등록해 관리하는 선택지를 보여준다. [08:08]
• 콘텐츠는 같은 폴더와 스킬을 공유하면서 주제별 탭으로 나누고, 소프트웨어 개발은 워크트리를 독립적으로 운영하는 활용을 제안한다. [08:57]

7. 대화를 유지하며 구현을 다른 세션에 위임

• 발표자는 코덱스를 관리 에이전트로 선호하며, 주식 차트 모니터링 프로그램의 기본 기능을 함께 기획하는 예를 든다. [09:25]
• 메인 에이전트가 구현에 묶이지 않도록 작업을 독립된 세션에 넘겨 대화 맥락을 유지하자고 제안한다. [10:16]
• 별도 클로드 패널에 구현을 맡기며 실행과 프롬프트 전달을 자동화하고, 메인 에이전트에서는 추가 기획이나 다른 워크트리 작업을 이어가는 흐름을 보여준다. [11:49]

8. 여러 콘셉트와 모델을 병렬로 비교

• 레이싱 게임의 핵심 요소와 세 가지 콘셉트를 논의한 뒤, 각 콘셉트를 서로 다른 에이전트에 전달하는 예를 보여준다. [12:29]
• 세 개의 패널을 생성해 동시에 작업하도록 요청하고, 순차적으로 결과를 기다리기보다 여러 안을 함께 만드는 방식을 선호한다고 드러낸다. [13:26]
• 모델이나 작업 환경을 달리하고, 독립된 워크트리 결과 중 선택한 것을 병합하거나 폴더별 결과를 비교할 수 있다고 보여준다. [14:03]

9. 단계별 오케스트레이션으로 확장

• 메인 에이전트가 탭 안의 패널들을 계속 모니터링하도록 구성할 수 있다고 보여준다. [14:33]
• 사용자 피드백 수집, 중요도 조사, 우선순위 결정, 독립 브랜치 구현과 검증을 잇는 작업 흐름을 예로 든다. [14:51]
• 단계마다 사용할 모델과 작업을 스킬에 정의하고, 완료 시 새 패널을 생성하도록 연결하면 복잡한 오케스트레이션도 구성할 수 있다고 제안한다. [15:14]

10. 원격 컴퓨터 조회와 등록

• 스킬로 등록된 원격 컴퓨터 목록과 상태를 확인하고, 같은 네트워크에 있는 컴퓨터를 등록하는 흐름을 보여준다. [15:53]
• 네트워크 장비를 찾는 과정 자체는 Herdr 기능이 아니라고 구분한 뒤, 발견한 컴퓨터를 머신 목록에 등록하도록 요청한다. [16:41]
• 등록한 원격 컴퓨터에서 새 터미널을 열고 코덱스를 실행하며, 독립된 컴퓨터가 필요한 작업에 활용할 수 있다고 보여준다. [17:34]

11. 한 화면에서 로컬과 원격 작업을 함께 실행

• 현재 탭에 패널 세 개를 만들되 하나는 로컬, 두 개는 원격 컴퓨터에서 실행하도록 요청한다. [18:06]
• 원격 패널의 데이터와 실행 자원은 원격 컴퓨터에 있으며, CPU·GPU도 해당 컴퓨터의 자원을 사용한다고 보여준다. [18:37]
• 여러 컴퓨터의 에이전트를 한 컴퓨터에서 통합 관리하는 구성을 강조한다. [18:52]

12. 반복 테스트를 원격 장비에 분산하는 구상

• 사람이 클릭하듯 진행하는 엔드투엔드 테스트를 반복해야 할 때, 로컬 컴퓨터의 종료나 자원 부하가 문제가 될 수 있다고 드러낸다. [19:20]
• 이슈 관리에 연결된 테스트 항목 100개를 열 묶음으로 나누어 원격 머신에 병렬 배정하는 활용을 제안한다. [19:39]
• 원격 머신이 작업을 수행한 뒤 로컬에 피드백을 돌려주는 흐름으로 여러 컴퓨터를 관리할 수 있다고 보여준다. [19:51]

13. Tailscale로 외부 접속 환경 구성

• 같은 와이파이 밖에서도 장비에 접근하려면 VPN을 활용할 수 있다며 자신이 사용하는 Tailscale을 보여준다. [20:17]
• 무료 등록 가능한 기기 수는 모른다고 밝히고, 컴퓨터를 Tailscale에 등록한 뒤 필요할 때 연결해 접근하는 방법을 보여준다. [20:46]
• 등록한 컴퓨터들을 외부에서도 연결해 활용하자고 권하며, 사용 제안과 구독·알림 안내로 영상을 마친다. [21:07]

🧾 결론

• 영상이 제시하는 작업 방식의 중심은 사람이 각 창을 직접 조작하는 부담을 줄이고, 에이전트가 다른 에이전트의 실행과 작업 전달을 맡게 하는 것이다.
• 워크스페이스·탭·패널은 작업을 정리하는 구조이며, 코드 변경을 분리할 때는 별도 워크트리를 함께 활용한다.
• 단순한 병렬 실행에서 더 나아가려면 단계별 작업, 사용할 모델, 완료 후 다음 작업으로 넘어가는 조건을 스킬에 정의해야 한다.
• 원격 컴퓨터 활용은 실행 환경과 자원을 나누는 선택지다. 영상의 다수 장비 테스트 운영 사례는 활용 구상으로 제시되며, 대규모 운영 결과를 검증한 사례는 아니다.

📈 투자·시사 포인트

• AI 도구 지출을 판단할 때는 구독 개수보다 병렬 작업으로 줄어드는 대기 시간과 실제 채택한 결과물의 가치를 함께 살펴볼 필요가 있다. 영상은 효용을 주장하지만 비용 대비 성과 수치는 제시하지 않는다.
• 여러 모델을 이미 사용하는 사람에게는 실행·전달·상태 확인을 묶는 관리 도구가 작업 흐름의 중요한 요소가 될 수 있다는 시사점을 준다.
• 추가 컴퓨터를 도입하려면 반복 테스트와 실행 환경 분리가 얼마나 필요한지 먼저 확인해야 한다. 영상의 장비 확장 예시는 구매 효과를 입증하는 근거로 볼 수 없다.
• 병렬 생성의 효율은 결과 비교와 검증 절차에 달려 있다. 생성 수를 늘리는 것과 유효한 결과를 빠르게 선택하는 것은 별도로 관리할 과제다.

⚠️ 불확실하거나 확인이 필요한 부분

• Ghostty의 구현 언어와 성능에 관한 설명은 발표자의 인식에 근거한다. 영상에는 이를 확인할 자료나 성능 비교가 없다.
• 영상에서 언급하는 ‘오퍼스 5.5’, 실행 옵션, 설치 방식의 정확한 명칭과 지원 범위는 전사만으로 확정하기 어렵다. 전사 오류 가능성도 고려해야 한다.
• 원격 컴퓨터를 제한 없이 등록할 수 있다는 주장과 Tailscale 무료 이용 범위는 검증되지 않았다. 발표자도 무료 등록 가능한 기기 수를 모른다고 말한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 작은 프로젝트에서 워크스페이스·탭·패널을 만들고, 분할·확대와 에이전트 상태 표시를 직접 확인한다.
• 메인 에이전트와의 기획 대화를 유지하면서 별도 세션에 한 가지 구현 작업을 위임해 본다.
• 코드 변경이 겹칠 수 있는 작업은 별도 워크트리로 나누고, 결과를 검토한 뒤 병합하는 흐름을 확인한다.
• 같은 과제의 구현안 두세 개를 병렬로 생성해 대기 시간, 사용량, 채택률과 검토 부담을 기록한다.

❓ 열린 질문

• 병렬 실행 수를 늘릴 때 결과 검토 부담과 사용량까지 고려한 적정 규모는 어디인가?
• 메인 에이전트가 작업 완료와 검증 통과를 어떤 기준으로 판단하고 다음 단계로 넘겨야 하는가?
• 원격 장비의 연결이 끊기거나 작업이 막혔을 때 재시도와 상태 복구는 어떻게 관리하는가?