이번 포스팅에서는 Orca라는 도구에 대해서 정리하고자 한다. stablyai/orca는 Claude Code, Codex, Grok 같은 CLI 기반 AI 코딩 에이전트를 하나의 프롬프트로 여러 개 동시에 실행하는 오픈소스 Agent Development Environment다. 각 에이전트는 독립된 Git worktree에서 작업하기 때문에 서로 코드를 덮어쓸 걱정 없이 같은 문제에 대한 여러 해법을 나란히 비교할 수 있다. 이 프로젝트는 글 작성 시점 기준으로 GitHub 기준 17.9k 스타를 확보했고, 2주 전애 8.6k였던 것과 비교하면 성장 속도가 상당히 가파르다. 최신 버전인 v1.4.137은 어제인 7월 12일 배포됐을 만큼 릴리스 주기도 짧다. 이 글에서는 Orca 코딩 에이전트의 설치 방법부터 worktree 생성, 터미널·파일·브라우저를 CLI로 직접 제어하는 방법까지 실제 명령어를 기준으로 정리한다.
Orca 코딩 에이전트는 정확히 어떤 문제를 해결하나
Orca 코딩 에이전트의 핵심은 하나의 작업 지시를 여러 코딩 에이전트에 동시에 전달하고, 각 에이전트를 독립된 Git worktree에서 격리해 실행하는 데 있다. 기존에는 터미널 창을 여러 개 띄워 Claude Code와 Codex를 수동으로 오가며 작업했다면, Orca는 이 과정을 하나의 창 안에서 관리한다.
Orca는 자체 AI 모델을 제공하지 않고 계정 생성도 요구하지 않는다. 이미 사용 중인 Claude Code나 Codex 구독을 그대로 가리키기만 하면, 같은 에이전트를 여러 개 동시에 실행해 각각 독립된 저장소 체크아웃에서 작업하도록 조율한다. Orca에 대해서 리뷰한 Orca Review: The IDE Built for Parallel Coding Agents 포스팅은 터미널 세 개를 띄워 Claude Code, Codex, Cursor를 손으로 오가던 자신의 실제 작업 습관을 근거로 이 도구를 평가했고, Medium에 올라온 또 다른 후기에서는 2026년 들어 이른바 “10x 개발자”들이 이미 코딩 에이전트 3~5개를 동시에 돌리고 있다는 관찰도 나온다. Orca는 이런 수동 병렬 작업을 하나의 창 안에서 조율하는 쪽으로 옮겨주는 셈이다. 결과물은 각 에이전트가 만든 diff를 탭으로 나란히 비교하고, 마음에 드는 부분만 cherry-pick으로 병합하는 방식으로 정리한다.
Orca 코딩 에이전트를 설치하는 방법은
macOS에서는 Homebrew cask로 설치하는 방법이 가장 간단하다.
# macOS (Homebrew)
brew install --cask stablyai/orca/orca
# Arch Linux (AUR, 바이너리)
yay -S stably-orca-bin
# Arch Linux (AUR, 소스 빌드)
yay -S stably-orca-git
# 헤드리스 Linux 서버에서 실행
orca serve위 명령어 중 brew install --cask 한 줄이면 macOS에서 Orca 앱이 바로 설치된다. Arch Linux는 AUR 패키지 두 종류(바이너리/소스)를 선택할 수 있고, GUI가 없는 원격 서버에는 orca serve로 헤드리스 모드를 띄워 SSH worktree의 기반으로 삼는다. Windows는 orca-windows-setup.exe, Linux는 AppImage 형태의 직접 다운로드도 지원하며, macOS는 Apple Silicon과 Intel 빌드가 따로 배포된다. 각 플랫폼별 다운로드 링크는 공식 사이트에서 바로 확인할 수 있다.
Orca 코딩 에이전트가 지원하는 CLI 에이전트는 몇 개나 되나
Orca 코딩 에이전트는 Claude Code, Codex, Grok, Gemini, Cursor, GitHub Copilot, OpenCode, Cline, Continue, Kimi, Mistral Vibe, Qwen Code를 포함해 30종 이상의 CLI 에이전트를 지원하며, 목록에 없는 CLI 에이전트도 직접 연결할 수 있다. 어느 하나에 종속되지 않고 이미 결제하고 있는 구독을 그대로 꽂아 쓰는 구조다.
이 지점이 Orca를 단일 벤더 IDE와 구분 짓는 부분이다. Cursor나 Windsurf처럼 자체 모델 구독을 새로 결제해야 하는 도구와 달리, Orca는 오케스트레이션 계층만 제공하고 실제 추론 비용은 각 에이전트 서비스에 그대로 남는다. 그래서 이미 Claude Code와 Codex를 함께 쓰던 팀이라면 추가 구독료 없이 병렬 실행 환경만 얹는 셈이 된다. 계정 여러 개를 등록해두면 레이트 리밋에 걸린 계정을 실시간으로 감지해 다른 계정으로 자동 전환하는 기능도 붙어 있어서, 장시간 배치 작업을 돌릴 때 요청이 끊기는 상황을 줄여준다.
worktree는 CLI 명령어로 어떻게 만들고 관리하나
orca worktree 서브커맨드 하나로 생성, 조회, 삭제까지 전부 처리한다. create로 새 worktree를 띄우고 ps로 목록을 확인한 다음, 다 쓴 worktree는 rm으로 정리하는 흐름이 기본이다.
# worktree 생성 (저장소, 작업명, 연결할 이슈 지정)
orca worktree create --repo id:<repoId> --name my-task --issue 123 --json
# 현재 존재하는 worktree 목록 조회
orca worktree ps --json
# 지금 셸이 위치한 worktree 확인
orca worktree current --json
# 활성 worktree에 코멘트 남기기
orca worktree set --worktree active --comment "reproduced bug" --json
# worktree 강제 삭제
orca worktree rm --worktree id:<id> --force --jsonorca worktree create는 지정한 저장소를 기반으로 독립된 Git worktree를 새로 만들고, --issue 플래그로 GitHub 이슈 번호까지 함께 연결한다. --json 옵션을 붙이면 결과가 구조화된 JSON으로 나오기 때문에 셸 스크립트나 CI 파이프라인에서 파싱하기 쉽다. 셸의 현재 디렉터리가 대상 worktree 밖에 있을 때는 대부분의 명령어에서 --worktree <selector>로 대상을 직접 지정할 수 있다는 점도 공식 CLI 문서에 명시돼 있다.
Orca의 오케스트레이션이 실제로 어떻게 도는지 직접 돌려 봤다. “체크아웃에 할인 로직을 추가한다”는 하나의 작업을 같은 프롬프트로 세 에이전트(Claude Code·Codex·Cursor)에 각각 맡기는 팬아웃 상황이다. Orca에서는 worktree를 에이전트 수만큼 만들어 병렬로 돌린다.
# 한 작업을 3개 에이전트 worktree로 팬아웃
orca worktree create --repo path:checkout-app --name add-discount-claude
orca worktree create --repo path:checkout-app --name add-discount-codex
orca worktree create --repo path:checkout-app --name add-discount-cursor
orca worktree ps # 진행 상황 한눈에 (오케스트레이션 요약)
orca worktree rm <id> # 승자만 남기고 나머지 정리각 worktree create는 저장소를 에이전트별 독립 체크아웃으로 복제하고 그 안에서 에이전트를 돌린다. 실제로 만들어 git worktree list로 확인하면, 아래처럼 세 worktree가 같은 커밋에서 분기해 각자의 브랜치·디렉토리를 갖는다.
핵심은 격리다. 세 에이전트가 같은 파일을 건드려도 서로 다른 디렉토리·브랜치에서 작업하니 충돌이 없고, 끝나면 결과를 나란히 비교해 가장 나은 것만 머지한다. 나머지는 orca worktree rm으로 정리한다. 이 병렬 방식이 cmux 같은 다른 도구와 구체적으로 어떻게 갈리는지는 Orca vs cmux 비교에서 따로 다뤘다.
서브에이전트끼리 메시지를 주고받게 하려면
앞의 팬아웃이 서로 다른 에이전트를 격리해 “따로 돌리고 비교”하는 방식이라면, Orca에는 한 걸음 더 나아간 오케스트레이션이 있다. 하나의 코디네이터가 서브에이전트(워커)를 여러 개 띄우고, 이들이 Orca 내부의 메시지 인박스(inbox)로 서로 메시지·질문·완료 보고를 주고받게 하는 방식이다. 여기서 ‘메시지’는 이메일이 아니다. 같은 머신의 오케스트레이션 세션(Run) 안에서만 오가는 조율용 메시지로, 프로그래밍의 메시지 큐에 가깝다. orca orchestration 명령군이 이 조율을 담당한다.
흐름은 이렇다. 코디네이터가 목표로 Run을 열고(run-create), 목표를 태스크로 쪼갠다(task-create). 이때 --deps로 의존성을 주면 태스크 DAG가 만들어져 앞선 태스크가 끝나야 다음 태스크가 풀린다. 각 태스크는 worker-start로 감독형 워커(서브에이전트)에 배정되고, 워커는 자기 worktree에서 작업하며 send로 진행 상황과 완료 결과를 보고한다. 워커가 막히면 ask로 코디네이터에게 블로킹 질문을 던지고, 코디네이터는 reply로 답하거나 gate-create로 승인 게이트를 걸어 위험한 단계를 막는다.
# 코디네이터: 목표 → 태스크 DAG
orca orchestration run-create --objective "회원가입 기능을 병렬로 구현한다"
orca orchestration task-create --task-title "가입 API 구현" --spec "..."
orca orchestration task-create --task-title "가입 통합 테스트" --deps '["<api-task-id>"]'
# 태스크마다 감독형 워커(서브에이전트) 기동
orca orchestration worker-start --task <task-id> --agent claude-code --worktree new-child
# 워커 ⇄ 코디네이터 메시지 (내부 인박스 · 이메일 아님)
orca orchestration send --from api-worker --to run:<run-id> --subject "가입 API 구현 완료"
orca orchestration ask --question "이메일 중복 정책은?" --options "차단,허용"
orca orchestration inbox --full실제로 유료 워커를 띄우지 않고 목표·태스크 DAG·인박스 메시지까지의 조율 계층만 돌려 봤다. 결과는 아래와 같다.
왼쪽은 코디네이터가 “회원가입 기능” 목표를 두 태스크로 분해한 모습이다. 가입 통합 테스트는 가입 API 구현에 의존하므로 pending으로 묶여, API가 끝나기 전에는 시작되지 않는다(DAG). 오른쪽은 그 인박스(내부 메시지 큐)다. api-worker가 완료를 보고하고, coordinator가 다음 단계를 지시하며, test-worker가 테스트 통과를 알린다. 세 서브에이전트가 사람 개입 없이 메시지로 서로를 조율하는 것이다. 여기에 worker-start로 실제 에이전트를 붙이면 이 메시지들이 자동으로 오가며 병렬 작업이 굴러간다.
지금까지 본 orca orchestration ...가 저수준 도구라면, 이 조율을 “언제·어떻게” 쓰는지는 Orca가 함께 배포하는 orchestration 스킬 가이드가 정한다. 코디네이터 역할을 맡은 에이전트가 이 스킬을 읽고 Run 생성·바인딩 → 태스크 생성 → 워커 기동 → worker_done·에스컬레이션 대기 → 태스크 DAG·결정 게이트 절차를 규칙대로 수행한다. 스킬이 특히 강조하는 건 “그냥 서브에이전트를 하나 더 띄우는 것”과의 차이다. Orca로 조율하면 태스크·디스패치 이력(provenance), 워커 완료 권한(worker_done), 결정 게이트가 함께 남지만, 일반적인 에이전트 스폰 방식은 워커만 만들 뿐 이 계보를 남기지 않는다.
설정은 Orca 앱의 Settings → 오케스트레이션 항목에서 관리한다. 아래 실제 화면처럼 “오케스트레이션 스킬”이 최신 상태로 떠 있고 “All N detected agents have the skill”이면, 코디네이터·워커 에이전트가 이 스킬을 쓸 준비가 된 것이다. 처음 켜거나 갱신이 필요하면 업데이트(설치·갱신)·재확인 버튼을 누르면 된다. 같은 화면 아래 “사용방법”에는 활성 작업 전달·병렬 실행·단계별 워크플로 같은 대표 패턴이 정리돼 있다.
터미널을 선호한다면 같은 설치·확인을 CLI로도 한다. orca orchestration 명령은 실행 중인 Orca 런타임으로의 RPC 호출이라, 런타임이 떠 있어야(첫 줄) 동작한다.
orca status # runtimeReachable: true 인지 확인
orca skills install # 번들 스킬 전역 설치
orca skills list # 목록에 orchestration 있는지 확인
orca skills get orchestration # 스킬 가이드 내용 열람정리하면 이 화면에서 스킬이 “최신 상태”로 잡혀 있고 런타임이 떠 있으면 앞의 코디네이터·워커 조율이 실제로 굴러간다. 스킬이 없는 상태에서 orca orchestration 명령을 부르면 제대로 동작하지 않으니, 조율을 시작하기 전에 이 화면부터 확인하는 게 좋다.
주의할 점은 worker-start가 실제 코딩 에이전트를 기동한다는 것이다. 이 방식은 팬아웃보다 강력하지만 그만큼 토큰·비용도 워커 수만큼 늘어난다. 그래서 작은 작업은 팬아웃으로, 여러 단계를 조율해야 하는 복잡한 작업은 코디네이터·워커 방식으로 나눠 쓰는 게 현실적이다.
터미널과 파일을 CLI로 직접 제어할 수 있나
가능하다. Orca CLI는 worktree 안의 터미널 세션과 파일 diff를 스크립트에서 그대로 조작할 수 있는 명령어를 제공한다.
# 터미널 세션 목록/읽기
orca terminal list --json
orca terminal read --json
# 실행 중인 터미널에 텍스트 전송 후 엔터
orca terminal send --text "continue" --enter --json
# TUI가 idle 상태가 될 때까지 최대 30초 대기
orca terminal wait --for tui-idle --timeout-ms 30000 --json
# 특정 worktree 경로에서 새 터미널 생성
orca terminal create --worktree path:/projects/app --command "npm test" --json
# 파일 열기 및 staged diff 확인
orca file open src/App.tsx
orca file diff src/App.tsx --stagedorca terminal wait --for tui-idle는 에이전트가 응답을 마칠 때까지 스크립트가 기다리게 만드는 명령어로, 에이전트 완료 여부를 폴링하는 대신 이벤트 기반으로 다음 단계를 실행할 수 있게 해준다. orca file diff --staged는 에이전트가 만든 변경분을 커밋 전에 바로 확인하는 용도로, 여러 worktree의 diff를 한 번에 순회하며 리뷰하는 스크립트를 짤 때 유용하다.
Design Mode로 브라우저 요소를 에이전트에 바로 넘길 수 있다는데
그렇다. Orca 코딩 에이전트는 내장 Chromium 브라우저에서 클릭한 UI 요소의 HTML, CSS, 스크린샷을 자동으로 수집해 에이전트 프롬프트에 첨부하는 Design Mode를 제공한다. 프런트엔드 버그를 고칠 때 셀렉터부터 찾아 헤매던 경험이 있다면, 이 기능 하나만으로도 써볼 이유가 생긴다.
orca goto --url https://example.com --json
orca snapshot --json
orca click --element @e3 --json
orca fill --element @e1 --value "user@example.com" --json
orca screenshot --json버그가 발생한 화면 요소를 직접 클릭하면 별도로 셀렉터를 찾아 코드에 붙여 넣을 필요 없이, 해당 요소의 마크업과 스타일 정보가 그대로 에이전트에 전달된다. 모바일 화면을 확인해야 하는 경우에는 orca emulator attach로 iPhone 12 같은 디바이스를 붙이고 orca emulator tap, orca emulator type 명령으로 터치와 입력까지 자동화할 수 있어서, 프런트엔드 버그 리포트를 텍스트로 옮겨 적는 수고를 상당 부분 줄여준다.
SSH worktree와 모바일 앱은 실무에서 어떻게 쓰이나
SSH worktree는 로컬 데스크톱의 UI는 그대로 유지하면서, 실제 에이전트 실행은 리소스가 넉넉한 원격 서버에서 처리하는 구조다. 원격 머신에도 orca serve로 Orca 에이전트를 미리 설치해둬야 연결이 된다. 로컬 노트북의 배터리나 메모리를 아끼면서도 익숙한 데스크톱 UI를 그대로 쓸 수 있다는 점이 핵심이고, 여러 worktree를 동시에 돌릴 때 로컬 머신이 버거워지는 상황을 피하는 용도로도 쓰인다. 다만 원격 서버 쪽에도 별도의 Orca 프로세스를 유지 관리해야 하므로, 서버 재시작이나 세션 만료에 대비한 운영 체크리스트는 팀에서 따로 마련해두는 편이 낫다.
모바일 앱은 iOS와 Android 양쪽에서 제공되며, 여러 worktree에서 돌아가는 에이전트의 진행 상황을 확인하고 작업이 끝나면 알림을 받는 용도로 쓴다. 다만 모바일 앱은 데스크톱에서 Orca가 실행 중이어야 동작하는 컴패니언 형태이고, 앱만으로 독립적인 클라우드 실행을 지원하지는 않는다. 즉 출퇴근길에 새 작업을 시작하기보다는, 이미 데스크톱에서 돌려둔 에이전트 여러 개의 완료 여부를 확인하는 모니터링 용도에 가깝다.
Orca와 Cursor, Windsurf는 뭐가 다른가
Orca 코딩 에이전트, Cursor, Windsurf 세 도구 모두 AI 코딩을 표방하지만 지향점이 다르다. 아래 표로 정리했다.
| 항목 | Orca | Cursor | Windsurf |
|---|---|---|---|
| 다중 에이전트 병렬 실행 | 지원 (핵심 기능) | 미지원 | 미지원 |
| 모바일 동반 앱 | iOS/Android 지원 | 없음 | 없음 |
| 라이선스 | MIT 오픈소스 | 소스 비공개 | 소스 비공개 |
| 비용 구조 | 도구 자체 무료, 에이전트 구독 별도 | 월 20달러 이상 | 월 15달러 이상 |
Cursor와 Windsurf는 자체 모델을 내장한 단일 에이전트 IDE고, Orca는 이미 쓰고 있는 CLI 에이전트를 여러 개 얹어 조율하는 오케스트레이션 계층이다. 그래서 둘 중 하나를 버리고 갈아타는 도구라기보다는, 이미 Claude Code나 Codex를 tmux로 수동 병렬 실행하던 사람이 다음으로 집어 드는 도구에 가깝다.
Orca 코딩 에이전트를 팀 단위로 도입하려면 무엇을 먼저 봐야 하나
Orca 코딩 에이전트를 개인 실험을 넘어 팀 단위로 도입하려면, 먼저 팀원 각자가 보유한 에이전트 구독 종류와 계정 수부터 파악해야 한다. Orca는 모델을 직접 제공하지 않기 때문에, 팀 전체의 Claude Code·Codex 라이선스 현황이 곧 실질적인 동시 실행 한도를 결정한다.
Orca는 GitHub와 Linear 통합을 앱 안에서 바로 제공하기 때문에, worktree를 생성할 때 이슈 번호를 연결해두면 PR과 이슈 진행 상황을 별도 창 전환 없이 확인할 수 있다. 다만 에이전트 결과물이 늘어나는 만큼 리뷰 부담도 함께 커진다는 점은 도입 전에 짚어야 한다. 세 개의 diff를 비교해 cherry-pick하는 과정 자체가 리뷰어의 판단을 한 번 더 거치는 작업이라, 코드 리뷰 문화가 잡혀 있지 않은 팀이라면 오히려 병목이 늘어날 수 있다. 이런 이유로 처음부터 전체 조직에 배포하기보다는, 이미 여러 에이전트를 수동으로 병행하던 2~3명 규모의 파일럿 팀에서 Orca 코딩 에이전트를 먼저 굴려보고 리뷰 프로세스를 조정한 다음 넓히는 방식이 안전하다. SSH worktree로 원격 서버 자원을 공유하는 구조까지 고려한다면, 서버 쪽 계정 격리와 접근 권한도 미리 정리해두는 편이 좋다.
병렬로 여러 에이전트를 돌리면 정말 이득인가
Orca 코딩 에이전트로 얻는 이득이 확실한 만큼 대가도 명확하다. 같은 작업을 에이전트 세 개에 동시에 맡기면 토큰 소비량도 대략 세 배로 늘어나기 때문에, 결과 비교의 편의성과 비용 사이에서 균형을 잡아야 한다.
Orca 자체는 Electron 기반이라 실행 시 메모리를 250~400MB 정도 점유하고, Linux는 아직 AppImage 형식만 배포돼 사내 패키지 매니저 파이프라인에 바로 얹기는 번거롭다. 데일리 릴리스 방식으로 버전이 자주 올라가다 보니 버그가 섞여 나올 때도 있는데, 대체로 24시간 안에 후속 패치가 나오는 편이다. 비용 관리 차원에서는 병렬로 뿌리는 초안 작업에는 Haiku처럼 저렴한 모델을 배정하고, 여러 diff 중 최종 병합을 담당하는 에이전트에만 Opus 같은 고급 모델을 쓰는 식으로 역할을 나누는 방법이 실질적으로 도움이 된다.
실제로 Claude Code 하나만 돌리다가 Orca로 worktree 세 개를 띄워놓고 같은 리팩터링 작업을 세 가지 방식으로 동시에 맡겨본 적이 있는데, cherry-pick으로 diff를 골라 합치는 과정이 생각보다 손에 익는 데 오래 걸리지 않았다. 다만 토큰 비용이 그만큼 배로 나간다는 점은 프로젝트 예산을 관리하는 입장에서 한 번은 짚고 넘어가야 할 부분이었고, Linux 패키지 매니저 지원이 AppImage뿐이라는 점도 사내 배포 파이프라인에 넣기엔 아직 살짝 아쉬웠다. 그래도 diff 세 개를 나란히 놓고 고르는 경험 자체는, 에이전트 하나의 답을 그대로 믿고 넘어가던 이전 작업 방식보다 확실히 안심이 됐다. 앞으로 팀 단위로 도입한다면 리뷰 프로세스와 계정 관리부터 고려해 보기 바란다.
FAQ
Orca 코딩 에이전트는 무료인가
Orca 코딩 에이전트 자체는 MIT 라이선스 오픈소스로 무료로 배포된다. 다만 Claude Code, Codex 같은 CLI 에이전트를 실행하려면 해당 서비스의 자체 구독이 별도로 필요하다.
Orca를 쓰려면 어떤 운영체제가 필요한가
macOS, Windows, Linux 데스크톱을 모두 지원하며 모바일 동반 앱은 iOS와 Android에서 사용할 수 있다. Linux는 현재 AppImage 형식만 제공된다.
Orca 코딩 에이전트를 모바일 앱만으로도 실행할 수 있나
아니다. 모바일 앱은 데스크톱에서 실행 중인 Orca 코딩 에이전트 세션을 모니터링하고 알림을 받는 컴패니언 역할이며, 독립적인 클라우드 실행 모드는 아직 지원하지 않는다.
에이전트 3개를 병렬로 돌리면 비용도 3배인가
토큰 소비 기준으로는 그렇다. 3개 에이전트에 동일 작업을 맡기면 토큰 사용량이 대략 3배로 늘어나므로, 병렬 실행 단계에는 저렴한 모델을 쓰고 최종 병합에만 고급 모델을 배정하는 방식이 비용 관리에 도움이 된다.
Cursor나 Windsurf를 쓰고 있다면 Orca로 갈아타야 하나
꼭 그렇지는 않다. Orca는 IDE 대체재가 아니라 여러 CLI 에이전트를 오케스트레이션하는 계층에 가깝다. 이미 여러 에이전트를 tmux 등으로 수동 조율하고 있다면 전환 효과가 크지만, 단일 에이전트로 충분한 워크플로면 급하게 옮길 이유는 적다.