YouTube바이브랩스·2026년 11월 2일·0

Orca에서 Herdr로 갈아타도 될까요? 터미널 앱 세 번째 실험기

Quick Summary

Orca에서 Herdr로 당장 갈아타기보다는, 에이전트 위임과 화면 맞춤화의 이점이 상태 확인·작업 관리 비용을 줄이는지 먼저 시험할 만하다.

영상 보기

클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.

원본 열기

🖼️ 인포그래픽

Orca에서 Herdr로 갈아타도 될까요? 터미널 앱 세 번째 실험기 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

Orca에서 Herdr로 갈아타도 될까요? 터미널 앱 세 번째 실험기의 핵심 내용을 4단계로 요약한 인포그래픽
Orca에서 Herdr로 갈아타도 될까요? 터미널 앱 세 번째 실험기 핵심 내용을 4단계로 압축한 4컷 인포그래픽

💡 한 줄 결론

Orca에서 Herdr로 당장 갈아타기보다는, 에이전트 위임과 화면 맞춤화의 이점이 상태 확인·작업 관리 비용을 줄이는지 먼저 시험할 만하다.

📌 핵심 요점

  1. Herdr의 핵심 실험은 탭 추가가 아니라 에이전트 간 위임과 결과 회수다. Claude Code가 리뷰어를 띄우고 검토 결과를 자신의 대화창으로 받는 흐름을 시연했다.
  2. Herdr TUI와 데스크톱 앱은 서로 다른 실행 기반을 사용한다. TUI의 에이전트는 앱·Core의 목록에 나타나지 않으며, 기존 세션을 함께 보는 화면으로 이해하면 안 된다.
  3. 앱창을 닫아도 Core의 작업은 남지만, 탭·페인 종료나 잠자기·재부팅까지 같은 보장을 뜻하지는 않는다. 재부팅과 덮개 닫기 동작은 촬영에서 직접 실험하지 않았다.
  4. Core의 상세 상태 표시는 에이전트가 보내는 OSC 7501 신호에 의존한다. 프로세스가 살아 있다는 표시와 실제 작업·대기 상태를 구분해야 한다.
  5. AI가 설정 파일을 고쳐 화면을 맞춤화하는 기능은 매력적이지만, Orca의 작업별 워크트리·브라우저·코드 리뷰 흐름을 대체할지는 미정이다. 두 실행기를 병행하면 확인할 곳이 늘 수 있다.

🧩 배경과 문제 정의

발표자는 앞선 터미널 도구를 거쳐 현재 Orca에 정착한 상태에서 Herdr를 세 번째로 시험한다. Orca의 프로젝트·워크트리 설정과 다른 컴퓨터 연결에 만족하고 있으며, 맥미니와 맥북 프로를 Tailscale로 연결해 사용한다고 설명한다.

Herdr를 다시 살펴본 계기는 에이전트가 다른 에이전트를 실행한다는 소개 문구다. 다만 탭을 여러 개 열거나 작업을 위임하는 기능 자체는 Orca에서도 가능하므로, 결과를 어떻게 돌려받는지가 비교의 중심이 된다.

영상은 작업 위임과 결과 회수, 창을 닫은 뒤의 작업 유지, Orca를 떠날 때 잃는 기능을 확인한다. 실습에는 아직 상태 필터가 작동하지 않는 작은 영상 제작 보드를 사용한다.

🕒 시간순 섹션별 상세정리

1. 창이 사라진 뒤에도 남은 작업과 전환의 질문

  • Herdr 앱에서 Claude Code와 리뷰어를 실행한 뒤 창을 닫아도 HC 목록에는 두 에이전트와 웹 작업이 남는다. 다만 남은 작업의 상세 상태를 알려면 에이전트가 직접 상태를 전달해야 한다는 조건을 제시한다. [00:44]
  • 발표자는 현재 Orca의 프로젝트·워크트리 설정과 원격 연결에 만족하고 있다. Herdr로 바꿀지는 더 사용해 봐야 한다고 드러낸다. [01:24]
  • 비교 항목은 에이전트에게 일을 나누고 결과를 받는 과정, 창을 닫은 뒤 작업 지속 여부, Orca를 포기할 때 잃는 기능이다. 결론은 미리 정하지 않았다. [02:17]

2. Herdr TUI·앱·Core의 역할과 분리된 실행 기반

  • Herdr는 터미널 안에서 사용하는 TUI, 마우스로 조작하는 데스크톱 앱, 화면 없이 터미널과 에이전트를 실행하는 Core로 드러난다. HC는 Core에 일을 시키는 명령이다. [02:55]
  • TUI는 전용 서버를 사용하고 앱은 Core를 사용한다. 서로 실행한 에이전트가 다른 쪽에 나타나지 않으므로, 같은 세션을 공유하는 두 화면으로 볼 수 없다. [03:27]
  • TUI와 앱은 각각 설치하며 Core는 앱 첫 실행 때 설치할 수 있다. 영상은 프로그램들이 무료이며 코드도 공개되어 있다고 보여준다. [03:51]

3. TUI 설치와 화면을 나갔다 돌아오는 실험

  • macOS에서는 Homebrew로 TUI를 설치한다. 별도 설치 스크립트 방식도 소개하지만, 발표자는 내려받은 파일을 먼저 읽고 실행하는 방식을 권한다. 실습 대상은 작동하지 않는 상태 필터가 있는 작은 제작 보드다. [04:37]
  • 초기 안내에는 화면 분할 단축키와 에이전트 통합 설치가 나온다. 통합은 기존 설정을 수정하므로 이번 촬영에서는 설치하지 않고, Claude Code에 프로젝트 구조를 읽고 설명하도록 요청한다. [05:19]
  • TUI는 화면에 나타나는 형태로 에이전트 상태를 추정하며 통합을 설치하면 정확도가 개선된다고 안내한다. TUI 화면을 종료했다 다시 열자 기존 대화가 그대로 남아, 화면과 실행이 분리됨을 확인한다. [06:01]

4. 데스크톱 앱 설치와 초기 설정 확인

  • 앱 DMG는 Apple Silicon 맥용으로 소개되며 Intel 맥은 소스 빌드가 필요하다고 보여준다. DMG에 Core가 포함되지는 않아 첫 실행 화면에서 Core와 HC를 추가 설치한다. [06:32]
  • HC 버전은 0.1.16으로 확인된다. Core 목록에 앞서 TUI에서 실행한 Claude Code가 없는 것은 두 실행 기반이 분리되어 있기 때문이다. [07:11]
  • 사용량 통계 전송은 기본으로 켜져 있어 촬영에서는 끈다. 원고 작성 당시 앱 버전은 0.1.11로 소개되며, 짧은 기간에 서명·권한·입력기·CPU 관련 수정이 이어진 초기 제품이라고 평가한다. [07:45]

5. 필터 구현과 백그라운드 개발 서버 실행

  • 앱에서 Claude Code를 실행해 기존 디자인을 유지하면서 상태 필터를 구현하도록 요청한다. 결과를 브라우저에서 보기 위해 개발 서버도 함께 실행한다. [08:03]
  • HC로 웹이라는 이름의 개발 서버를 백그라운드에 띄우고 출력 내용을 읽는다. 명령을 입력한 터미널에 계속 머무르지 않아도 서버 실행과 출력 확인이 가능하다. [08:28]
  • 웹 작업은 HC 목록에는 있지만 앱 사이드바에는 나타나지 않는다. 앱은 어느 공간에 표시할지 지정된 터미널만 보여주므로, 화면에 없다는 사실과 실행되지 않는다는 사실을 구분해야 한다. [08:47]

6. Claude Code가 리뷰어를 실행하고 결과를 받는 흐름

  • Claude Code에 HC 스킬을 읽고 리뷰어를 띄우도록 요청한다. 리뷰어에게는 변경 코드의 버그 가능성과 빠진 예외만 확인하고 수정하지 않으며, 결과를 부모 에이전트에게 보고하도록 지시한다. [09:19]
  • Claude Code가 리뷰 터미널을 실행하고 중간의 MCP 서버 선택 창도 처리한다. 이후 리뷰 결과가 Claude Code 대화창으로 전달되며, 치명적 버그는 없고 데이터 변경 시 고려할 가능성 네 가지가 보고된다. [09:55]
  • 브라우저에서는 상태별 필터 작동을 확인한다. 발표자는 에이전트가 실행·요청·결과 회수의 전달 절차를 맡았다는 점을 차이로 보면서도, 작업 분할과 리뷰의 타당성 판단은 여전히 필요하다고 보여준다. [10:25]

7. 상세 상태 표시는 에이전트의 신호에 달려 있다

  • Core는 화면 글자를 읽어 추정하는 대신 OSC 7501 신호를 받아 작업·완료·응답 대기·오류 상태를 표시한다고 보여준다. 신호를 보내지 않는 프로그램은 상세 상태가 비어 있다. [10:56]
  • TUI의 화면 기반 추정과 달리 Core는 프로그램이 보내는 신호를 기다린다. 실습에서는 Claude Code와 리뷰어가 작업 중·유휴 상태로 바뀌는 모습을 확인한다. [11:28]
  • 웹 개발 서버에는 실행 중이라는 표시만 나타난다. 이는 프로세스가 살아 있다는 뜻이며 실제 작업 여부까지 알려주지는 않으므로, 사용하는 에이전트의 신호 지원에 따라 앱의 효용이 달라진다. [11:58]

8. AI로 레이아웃을 고치고 작업 경과 시간을 표시

  • 앱 설정은 파일로 저장되며 에이전트용 안내문도 함께 제공된다. 발표자는 설정 폴더를 먼저 복사하고, 기본 레이아웃이 갱신될 수 있으므로 복제본을 수정하는 방식을 보여준다. [12:29]
  • Claude Code에 원본을 보존하면서 탭마다 작업 경과 시간을 표시하도록 요청한다. 수정 후 작업 중에만 시간이 증가하는 표시가 나타나며, 화면 저장 명령으로 에이전트가 수정 결과를 확인할 수도 있다. [13:13]
  • 이런 코드 묶음을 모드라고 부른다. 모드는 샌드박스가 아닌 신뢰 코드로 소개되므로 외부 모드는 내용을 확인해야 한다. 발표자는 자신의 습관에 맞춰 화면을 바꾸는 기능을 Orca 대비 큰 장점으로 평가한다. [13:47]

9. 작업 유지의 범위와 직접 검증하지 않은 조건

  • 앱창을 닫으면 작업은 계속되지만 탭이나 페인을 닫으면 해당 터미널은 종료된다. 로컬 맥이 잠자기에 들어가면 작업도 멈추며, 깨어 있는 원격 컴퓨터에서 실행한 작업과 구분한다. [14:22]
  • 재부팅이나 Core 중단 뒤에는 같은 폴더에 새 셸이 열릴 수 있어도 기존 작업이 자동으로 이어지는 것은 아니라고 보여준다. 반면 HC 업데이트 중 터미널 유지는 문서에 명시된 내용으로 보여준다. [14:42]
  • TUI의 공식 통합 에이전트는 재부팅 뒤 대화 기록을 다시 열 수 있지만, 앱·Core에도 같은 기능이 있다는 근거는 찾지 못했다. 재부팅과 덮개 닫기는 촬영에서 직접 실험하지 않았다고 드러낸다. [15:06]

10. Orca의 작업 흐름과 HC 병행의 관리 비용

  • Orca는 작업별 워크트리, 브라우저 탭, 변경 코드를 읽고 메모하는 화면을 제공한다고 비교한다. Herdr 실습에서는 브라우저를 따로 열었고 같은 파일의 동시 수정을 막기 위해 리뷰어를 읽기 전용으로 제한했다. [15:31]
  • 발표자는 Herdr 앱이 당장 Orca를 대체하기는 어렵지만 Core에 개발 서버·검사·리뷰어 같은 백그라운드 작업을 맡길 가능성은 있다고 본다. 다만 실행기가 두 개면 작업 위치도 두 군데서 확인해야 한다. [16:02]
  • Core의 효용은 에이전트가 직접 HC를 부를 때 생긴다는 조건으로 좁힌다. Orca는 일상 작업대로 두고 HC에는 백그라운드 작업을 맡기는 방안을 제안하지만, 병행 시 충돌 여부는 추가 사용이 필요하다. [16:27]

11. 전환 판단을 보류하며 남긴 최종 기준

  • 에이전트가 다른 에이전트를 부르게 하거나 화면을 자유롭게 바꾸고 싶다면 시험할 만하다고 평가한다. 다만 Orca도 스킬로 위임 흐름을 구현할 수 있고, 기존 TUI 세션이나 작업별 브라우저·리뷰 화면이 중요하다면 전환을 서두를 필요가 없다고 드러낸다. [16:57]
  • 정확한 상태 표시가 필요하다면 에이전트가 신호를 어떻게 보내는지부터 확인해야 한다. 앱창을 다시 닫아 작업 목록이 남은 것을 보면서, 작업을 맡길 곳이 늘어난 동시에 확인할 곳도 늘었다고 해석한다. [17:21]
  • 마지막 판단 기준은 작업 지속 자체를 넘어 상태를 전달받을 수 있느냐에 있다. 설치 명령과 참고 문서를 설명란에 정리했다고 안내한 뒤 영상을 마친다. [17:45]

🧾 결론

  • 영상의 판단은 전환 확정이 아니라 보류다. Orca를 일상 작업대로 유지하고, 백그라운드 작업 일부를 HC에 맡기는 방안을 제안한다.
  • Core의 가치는 에이전트가 직접 다른 작업을 실행하고 결과를 받아올 때 커진다. 사람이 매번 명령을 입력하고 확인한다면 추가 터미널과의 차이가 작아진다.
  • 화면 맞춤화가 중요하다면 Herdr 앱을 시험할 이유가 있다. 기존 TUI 세션이나 작업별 브라우저·리뷰 화면이 중요하다면 전환을 서두를 이유는 적다.
  • 창을 닫은 뒤 작업이 남는다는 사실만으로 생산성 향상을 판단할 수 없다. 상태를 믿고 파악할 수 있는지, 확인 부담이 줄었는지가 함께 중요하다.

📈 투자·시사 포인트

  • 개발 도구의 비교 기준이 탭 수에서 위임·결과 회수·상태 전달로 확장된다. 영상에서 드러난 가치는 여러 창을 띄우는 기능보다 작업 사이의 전달 절차를 줄이는 데 있다.
  • 새 도구 도입의 비용에는 기존 작업 흐름의 상실과 관리 지점의 증가도 포함된다. Orca와 HC 병행은 기능을 더하면서도 확인 부담을 늘릴 수 있다.
  • 상태 신호 지원 여부가 같은 앱의 체감 효용을 바꾼다. 도구 자체의 기능뿐 아니라 실제 사용하는 에이전트와의 연결 방식을 확인해야 한다.
  • 빠른 업데이트와 자유로운 화면 수정은 가능성과 운영 부담을 함께 보여준다. 영상만으로 기업 가치나 투자 수익을 판단할 근거는 없으며, 여기서 얻을 수 있는 시사점은 개발 도구의 선택 기준이다.

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

  • 재부팅과 맥북 덮개 닫기 실험은 촬영에서 수행하지 않았다. 해당 동작과 업데이트 중 터미널 유지 설명은 영상이 참고한 문서에 근거한 내용으로 구분해야 한다.
  • TUI의 공식 통합 에이전트는 재부팅 뒤 대화 기록을 다시 여는 기능이 소개되지만, 앱·Core에도 같은 기능이 있다는 근거는 이번 조사에서 확인하지 못했다.
  • 개발 서버의 실행 여부와 에이전트의 상세 작업 상태는 다르다. OSC 7501 신호를 보내지 않는 프로그램에서는 상세 상태가 비어 있을 수 있다.
  • 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
  • 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
  • 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

  • 현재 작업에서 Orca의 워크트리·브라우저·리뷰 화면 중 꼭 필요한 기능을 먼저 적는다.
  • 작은 프로젝트에서 구현 에이전트가 읽기 전용 리뷰어를 실행하고 결과를 돌려받는 흐름을 시험한다.
  • 사용하는 에이전트가 작업·대기·오류 상태 신호를 보내는지 확인하고, 프로세스 실행 표시와 구분한다.
  • 앱창 닫기와 탭·페인 닫기의 차이를 확인한다. 잠자기·재부팅 검증은 잃어도 되는 작업으로 별도 수행한다.

❓ 열린 질문

  • 에이전트가 직접 HC를 사용하는 흐름이 Orca의 기존 기능과 스킬 활용보다 얼마나 편리한가?
  • 두 실행기를 병행해도 작업 위치와 상태를 한눈에 파악할 수 있는가?
  • 사용하는 에이전트가 상태 신호를 충분히 보내지 않는다면 Herdr 앱의 이점은 얼마나 남는가?

관련 문서

공통 태그와 주제 흐름을 기준으로 같이 보면 좋은 문서를 이어서 제안합니다.