하나의 터미널에서 하나의 에이전트를 실행하는 것은 작업의 기본 단위입니다. 프롬프트를 입력하고, 기다리고, 검토한 뒤, 다시 프롬프트를 입력합니다. 에이전트는 빠르지만 사람이 병목이 됩니다. 당연한 해결책은 여러 에이전트를 동시에 실행하는 것이지만, 문제는 동일한 작업 트리(working tree)를 수정하는 에이전트들이 서로의 작업을 망가뜨린다는 점입니다.
Orca는 이 문제를 깔끔하게 해결합니다. Stably에서 개발한 데스크톱 애플리케이션으로, 각 에이전트를 독립된 git worktree에서 실행하여 여러 코딩 에이전트를 동시에 운용할 수 있게 해줍니다. GitHub 스타 58,464개를 기록 중이며 MIT 라이선스로 제공됩니다. 혼자 일하면서 당장 작업 처리량을 늘리고 싶다면 Orca는 확실한 해답이며, 이 글에서도 적극 추천합니다. 다만, 다른 팀원들과 작업 과정을 공유하는 기능은 제공하지 않는데, 이는 애초에 목적이 다른 영역입니다.
요약 (TL;DR)
이 글은 코딩 에이전트 기능을 확장하는 오픈소스 도구 시리즈에서 다루는 5개의 심층 분석 중 하나입니다.
Orca는 Codex, Claude Code, OpenCode, Cursor CLI 등 거의 모든 CLI 에이전트를 격리된 git worktree에서 나란히 실행할 수 있으며, 사용자가 이미 보유한 구독 계정을 그대로 활용합니다. 터미널 분할, diff 어노테이션, SSH를 통한 원격 worktree, Chromium 기반 디자인 모드, GitHub 및 Linear 탐색, 모바일 컴패니언 앱 등을 지원합니다. 1인 개발자에게는 더할 나위 없이 훌륭합니다. 하지만 팀 단위 개발에서는 작업 이력이 여전히 한 컴퓨터의 터미널 스크롤백에만 남게 되며, 바로 이 지점에서 협업 작업 관리 시스템의 필요성이 시작됩니다.
주요 기능과 동작 방식
핵심 원리는 '에이전트당 하나의 worktree'입니다. Git worktree를 사용하면 하나의 저장소에서 여러 작업 디렉터리를 동시에 체크아웃할 수 있으므로, 5개의 에이전트가 서로의 파일을 건드리지 않고 동일한 저장소에서 작업할 수 있습니다. 이는 병렬 실행을 위한 격리된 worktree의 기반이 되는 메커니즘과 같으며, 올바른 설계 방향입니다.
이를 통해 가능해지는 패턴이 바로 팬아웃(fan-out)입니다. 하나의 프롬프트를 여러 에이전트에 동시에 보낸 뒤, 결과를 비교하고 최선의 결과물을 병합하는 방식입니다. 정답이 명확하지 않은 복잡한 문제의 경우, 서로 다른 세 모델이 시도하면 실패하는 양상도 제각각 다릅니다. 따라서 한 모델의 결과를 두고 계속 씨름하는 것보다 세 모델의 결과 중 최고를 고르는 편이 훨씬 효율적입니다.
| 기능 | 제공하는 가치 |
|---|---|
| 병렬 worktree | 완전히 격리된 환경에서 단일 저장소에 여러 에이전트 동시 작업 |
| 터미널 분할 | WebGL 렌더링 지원, 재시작 후에도 유지되는 스크롤백 |
| AI diff 어노테이션 | 코드 라인별 코멘트를 에이전트에게 바로 피드백으로 전달 |
| SSH worktree | 더 고성능의 원격 서버에서 에이전트 실행 및 자동 재연결 |
| 디자인 모드 | UI 요소를 클릭하여 HTML, CSS 및 스크린샷을 프롬프트에 즉시 포함 |
| GitHub 및 Linear 연동 | PR, 이슈, 보드를 탐색하고 작업(Task)에서 바로 worktree 생성 |
| 사용량 추적 | Claude 및 Codex의 한도 및 초기화 시간 표시, 계정 핫스왑 지원 |
| 모바일 컴패니언 | 스마트폰에서 알림 수신 및 후속 작업 진행 |
특히 계정 전환(Account switcher) 기능은 주목할 만합니다. 5개의 에이전트를 동시에 돌리면 필연적으로 사용량 한도(rate limit)에 도달하게 되는데, 앱 내에서 초기화 시간을 미리 확인할 수 있으면 작업 도중 멈추는 일 없이 계획적인 운용이 가능해집니다.
설치는 공식 다운로드, Homebrew cask, AUR 패키지로 간편하게 진행할 수 있으며, 헤드리스 리눅스 서버 환경을 위한 orca serve 명령도 지원합니다.
팬아웃(Fan-out) 전략이 효과적인 경우
병렬 처리가 공짜는 아닙니다. 잘못 사용하면 똑같은 답변 5개를 얻기 위해 5배의 토큰 비용만 낭비하게 됩니다.
팬아웃은 선택할 수 있는 타당한 접근 방식이 여러 가지일 때 진가를 발휘합니다. 예를 들어 상태 관리 리팩터링, 생소한 라이브러리 연동, 병목 지점이 명확하지 않은 성능 문제 해결 등이 있습니다. 결과물 간의 차이와 다양성 자체가 가치를 만들어냅니다.
반면 작업 요건이 명확할 때는 단일 에이전트만 실행해야 합니다. 엔드포인트에 필드 하나를 추가하거나 기존 핸들러 4개와 동일한 규격의 핸들러를 새로 작성하는 일에 팬아웃을 쓰면, 거의 동일한 diff 5개와 낭비된 청구서만 남을 뿐입니다.
또한 동일한 모델을 여러 번 실행하기보다는 서로 다른 모델들로 팬아웃하는 것이 좋습니다. 하나의 에이전트를 3개 인스턴스로 돌리면 결과가 비슷하게 수렴하지만, 서로 다른 3개의 에이전트는 학습 데이터와 구조 자체가 달라 확연히 다른 결과를 보여줍니다.
시작하기 전에 반드시 인수 조건(acceptance criteria)을 작성해 두어야 합니다. 올바른 결과가 무엇인지 사전에 명확히 정의하지 못하면 결국 감이나 겉보기에 기대어 승자를 고르게 됩니다.
1인 개발 모델의 한계
Orca는 1인 개발자를 위한 탁월한 조종석(cockpit)입니다. Worktree, 세션, diff, 그리고 재시작 후에도 보존되는 스크롤백까지 모든 것이 개발자의 로컬 머신에 존재합니다. 개인 작업에는 더할 나위 없이 최적화된 구성입니다.
하지만 다른 사람과 협업하는 순간 이것이 한계로 작용합니다. 목요일에 5개의 에이전트를 실행했다고 가정해 봅시다. 월요일에 팀원이 결제 클라이언트의 재시도 로직이 왜 바뀌었는지 묻습니다. 그 답변은 노트북의 터미널 패널 속에만 있고, 그마저도 해당 worktree가 아직 열려 있을 때의 이야기입니다. 그 결과를 만들어낸 프롬프트는 이미 사라졌고, 남은 것은 AI 모델이 작성한 커밋 메시지뿐입니다.
프롬프트는 영구적인 기록이 아닙니다. 개인 조종석은 팀 협업 시스템이 아닙니다. 이는 Orca의 결함이 아니라, 1인용 데스크톱 애플리케이션이라는 태생적 범위의 한계입니다.
패널 단위 격리 vs Task 단위 격리
Sharkly와 Orca는 겉으로 보이는 카테고리 이상으로 많은 철학을 공유합니다. 둘 다 병렬 에이전트가 충돌하지 않도록 작업을 격리하며, 기존 개발 도구를 대체하기보다 이미 설치된 도구를 그대로 실행합니다. 모델 사용량 역시 해당 도구에 설정된 구독이나 API 키를 그대로 따릅니다.
차이점은 격리하는 단위에 있습니다.
Sharkly에서 작업의 핵심 단위는 'Task'입니다. 저장소 작업은 Task 실행마다 격리된 디렉터리와 git worktree에서 수행됩니다. 즉, Orca의 패널들을 분리해 주는 동일한 메커니즘을 활용하되, 이를 팀 전체가 열람할 수 있는 작업 단위로 격리하는 것입니다.
각 구성 요소는 하나의 역할만 담당합니다. Agent는 작업을 처리하는 방식을 정의하고, Computer는 호스트와 로컬 리소스를 제공합니다. Runtime은 실제 에이전트 세션을 실행하며, Task는 공유되는 기록으로 남습니다.
Sharkly는 Claude Code나 Codex를 대체하지 않으며, 로컬 개발 환경으로서의 Orca를 대체하는 것도 아닙니다. 팀이 이미 사용 중인 도구 위에 공유 태스크, Computer, 컨텍스트, 제어 및 코드 리뷰 레이어를 추가해 주는 역할을 합니다.
이러한 구조 덕분에 1인용 도구에서는 불가능한 두 가지 역량이 가능해집니다. 첫째는 Crew 기능입니다. 리더 에이전트가 사람과 에이전트로 구성된 팀을 조율하므로, 팬아웃에 '종합(synthesis)' 단계가 추가됩니다. 리더가 목표를 해석하고, 필요한 멤버를 참여시키고, 그 결과를 하나의 Task로 통합해 주므로 사람이 직접 5개의 diff를 비교하며 심판을 볼 필요가 없습니다. 둘째로 백로그(Backlog) 상태의 Task는 실행되지 않으므로, 작업 실행 전 사전 준비와 승인 과정을 거칠 수 있습니다.
실행 과정, 장애 요인, 결과, 후속 논의가 모두 태스크 타임라인에 기록됩니다. 따라서 월요일에 들어온 질문에도 화면 녹화본을 뒤질 필요 없이 명확한 답변을 제시할 수 있습니다.
상황별 도구 선택 가이드
혼자 작업하고, 프로젝트 전반을 혼자 책임지며, 동시에 다룰 수 있는 에이전트 수가 병목인 경우에는 Orca를 사용하세요. 1인 환경에서는 현존 최고의 데스크톱 도구이며, 지금 바로 설치해 쓸 가치가 충분합니다.
반면 에이전트가 수행한 작업을 다른 팀원도 알아야 하거나, 배포 전에 리뷰를 거쳐야 하거나, 3개월 뒤에 누군가가 변경 이유를 물어볼 가능성이 있다면 공유 작업 시스템을 사용해야 합니다. 기준은 팀의 규모가 아닙니다. 작업 기록이 해당 작업 세션 이후에도 계속 유지되어야 하는지 여부입니다.
실제로 많은 팀이 두 도구를 함께 사용하며, 훌륭한 시너지를 냅니다. 에이전트는 조사, 실행, 테스트, 보고를 담당하고, 사람은 방향을 제시하고 권한을 부여하며 결과물을 최종 승인합니다.
자주 묻는 질문 (FAQ)
Orca는 어떤 에이전트를 지원하나요? 모든 CLI 기반 에이전트를 지원합니다. Claude Code, Codex, Cursor CLI, Copilot CLI, OpenCode, Grok, Amp, Pi, Devin, Goose, Cline, Continue, Kimi, Qwen Code 등이 공식적으로 명시되어 있습니다.
병렬 에이전트를 실행하려면 별도의 추가 구독이 필요한가요? 아닙니다. Orca는 기존에 보유한 계정을 그대로 사용합니다. 다만 여러 에이전트를 동시에 실행하면 플랜의 사용량 한도(rate limit)에 더 빨리 도달할 수 있는데, 이는 도구의 문제가 아니라 각 서비스 플랜의 문제입니다.
하나의 저장소에서 5개의 에이전트를 실행해도 안전한가요? 파일 측면에서는 안전합니다. 각 에이전트마다 독립된 worktree가 할당되기 때문입니다. 다만 데이터베이스, 개발 서버, 포트 등 저장소 외부의 공유 상태는 사용자가 직접 관리해야 합니다.
생성된 여러 diff 중 최선의 결과물을 어떻게 선택하나요? 모든 결과물에 대해 동일한 테스트 스위트를 실행하여 통과 여부로 판단하세요. 만약 테스트가 후보 결과물들을 변별해 내지 못한다면, 팬아웃 규모를 늘리기 전에 테스트 코드부터 보완해야 합니다.
Orca와 Sharkly 중 무엇을 써야 하나요? 두 도구는 역할 레이어가 다르며 상호 보완적입니다. Orca는 개인이 에이전트를 직접 지휘하는 작업대이고, Sharkly는 팀 구성원 간에 작업을 할당, 추적, 검토하는 협업 시스템입니다. 1인 개발이라면 Orca만으로 충분할 수 있습니다. 자세한 비교는 병렬 에이전트 관리 도구 비교 글을 참고하세요.
요약 정리
Orca는 1인 개발자의 작업 처리량 문제를 해결해 주는 가장 강력한 도구입니다. 병렬 worktree, 터미널 분할, diff 어노테이션, 원격 실행, 모바일 컴패니언 등 완성도 높은 기능들을 제공하며, 기존 구독을 그대로 활용할 수 있다는 점도 훌륭합니다.
이를 통해 시간당 더 많은 후보 결과물을 도출할 수 있습니다. 결과물 간 비교와 변경 이력 파악을 혼자서 감당할 수 있는 한 이는 분명한 생산성 향상입니다. 하지만 다른 사람과의 협업이나 공유가 필요해지는 순간, 작업에는 'Task'라는 단위가 필요합니다. Sharkly는 동일한 worktree 격리 기술을 바탕으로 팀 전체가 공유할 수 있는 작업 레이어를 제공합니다.
