Orca에서 Herdr로 갈아타도 될까요? 터미널 앱 세 번째 실험기
Quick Summary
Orca에서 Herdr로 당장 갈아타기보다는, 에이전트 위임과 화면 맞춤화의 이점이 상태 확인·작업 관리 비용을 줄이는지 먼저 시험할 만하다.
영상 보기
클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.
🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론
Orca에서 Herdr로 당장 갈아타기보다는, 에이전트 위임과 화면 맞춤화의 이점이 상태 확인·작업 관리 비용을 줄이는지 먼저 시험할 만하다.
📌 핵심 요점
- Herdr의 핵심 실험은 탭 추가가 아니라 에이전트 간 위임과 결과 회수다. Claude Code가 리뷰어를 띄우고 검토 결과를 자신의 대화창으로 받는 흐름을 시연했다.
- Herdr TUI와 데스크톱 앱은 서로 다른 실행 기반을 사용한다. TUI의 에이전트는 앱·Core의 목록에 나타나지 않으며, 기존 세션을 함께 보는 화면으로 이해하면 안 된다.
- 앱창을 닫아도 Core의 작업은 남지만, 탭·페인 종료나 잠자기·재부팅까지 같은 보장을 뜻하지는 않는다. 재부팅과 덮개 닫기 동작은 촬영에서 직접 실험하지 않았다.
- Core의 상세 상태 표시는 에이전트가 보내는 OSC 7501 신호에 의존한다. 프로세스가 살아 있다는 표시와 실제 작업·대기 상태를 구분해야 한다.
- 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 앱의 이점은 얼마나 남는가?