에이전트 여러 개를 git worktree로 격리해 동시에 돌리는 오픈소스 ADE,
Orca를 AI 엔지니어 관점에서 정리했다.
Claude Code Agent Teams 글을 쓰면서 한 가지 불편이 남았다.
에이전트를 여러 개 돌리는 순간 터미널 탭이 감당이 안 된다.
같은 저장소를 두 에이전트가 동시에 고치면 충돌이 나고, 누가 뭘 바꿨는지 추적하는 것도 일이 된다.
그 문제를 정면으로 겨냥한 도구가 나왔다.
이름은 Orca. 스스로를 IDE가 아니라 ADE(Agentic Development Environment)라고 부른다.
모든 글의 출처는 https://www.onorca.dev/
ADE라는 새 카테고리
Orca가 내세우는 구분은 이렇다.
IDE는 키보드 앞에 앉아 코드를 한 줄씩 검토하는 개발자를 위한 도구다.
ADE는 에이전트 여러 대를 출발시켜 놓고 자리를 뜨는 개발자를 위한 도구다.
그래서 UI의 중심이 자동완성이 아니라 작업 배분·비교·선택 머지에 맞춰져 있다.
2026년 3월에 처음 공개됐고 7월 기준 GitHub 스타 2.7만을 넘겼다.
MIT 라이선스 오픈소스이고 모델 구독은 각자 가진 걸 그대로 쓴다(중간 마진 없음).
“we ship daily”가 태그라인일 정도로 릴리즈가 빠르다. 7월 말 기준 v1.4.152.
핵심 아이디어: git worktree 격리
Orca의 뼈대는 git의 표준 기능인 worktree다.
에이전트 작업(태스크) 하나마다 .orca/worktrees/ 아래에 독립 워크트리와 브랜치가 생긴다.
각 에이전트는 자기 워크트리 안에서만 파일을 만지니 같은 저장소를 동시에 고쳐도 서로 충돌하지 않는다.
대표 워크플로는 “fan-out”이다.
orca worktree fan "Refactor auth module to use JWT" \
--agents claude-code,codex,opencode --count 3
프롬프트 하나를 에이전트 3개에 뿌리고 3개의 구현을 나란히 받아서 비교한 뒤 좋은 쪽만 머지한다.
“같은 작업을 여러 에이전트에 시켜보고 낫은 걸 고른다”는 다들 수동으로 하던걸 제품으로 만든 셈이다.
지원 에이전트는 Claude Code(및 agent teams), Codex, Gemini, OpenCode, Cursor CLI, Copilot CLI 등 30개 이상이고 TOML로 커스텀 에이전트도 붙일 수 있다.
눈에 띄는 기능들
- diff 비교와 주석: 에이전트별 결과를 나란히 놓고 비교하고 다시 프롬프트를 쓰는 대신 diff에 인라인 코멘트를 달아 수정시킨다.
- 레이트리밋 모니터: 상태 바에서 계정별 쿼터 소진 상황을 보여주고 세션 중간에 구독 계정을 갈아탈 수 있다.
- Design Mode: 임베디드 브라우저에서 UI 요소를 클릭하면 해당 HTML/CSS가 프롬프트에 자동으로 담긴다.
- 원격/모바일: SSH 워크트리로 원격 머신에서 실행하고, 모바일 컴패니언 앱으로 알림을 받고 답장한다.
- GitHub·Linear·Jira 연동, 세션 복원, 무한 분할 터미널 같은 기본기도 갖췄다.
설치는 macOS 기준 한 줄이다.
brew install --cask stablyai/orca/orca
(직접 실행한 화면)
직접 켜본 첫인상
내 사용 패턴은 Claude Code가 메인, Codex가 보조다.
Claude 요금제 한도를 어느 정도 소진했다 싶으면 Codex로 넘어가고, 내 코드를 적대적으로 검토시키고 싶을 때도 Codex를 불러 쓴다.
문제는 이 전환이 늘 매끄럽지 않았다는 것.
터미널에서는 한도가 얼마나 남았는지 보이지 않으니, 막혀봐야 알았다.
Orca에서는 상태 바에 계정별 쿼터 소진 상황이 떠 있어서, “이쯤 썼으니 넘어가자”는 판단을 미리 내릴 수 있었다.
전환도 로그아웃 없이 계정만 바꾸면 끝이라, “Claude 메인 + 한도 임박 시 Codex” 운용이 도구 차원에서 자연스러워졌다.
적대적 검토도 마찬가지다.
작업하던 워크트리 옆에 Codex를 불러서 검토를 시키는 흐름이, 터미널 탭을 오가며 하던 때보다 훨씬 가볍다.
또 하나 체감이 컸던 건 시각화다.
터미널로 에이전트를 돌리면 지금 뭘 하고 있는지가 안 보여서 답답했는데
Orca는 워크트리별로 에이전트가 일하는 과정이 눈에 보인다.
나는 여러 프로젝트를 동시에 굴리는 편인데, 그걸 화면 하나에서 조망할 수 있는 것도 좋았다.
프로젝트마다 터미널 창을 띄워놓고 뭐가 어디 있는지 찾아다니던 것과 비교하면
“관제탑이 생겼다”는 느낌에 가깝다.
누구에게 필요할까?
써보기 전에 미리 선을 그어두면 이렇다.
병렬 실행은 곧 토큰 비용의 배수다.
에이전트 3개에 fan-out하면 비용도 3배로 나간다
LLM API 비용 계산법에서 다룬 단가 감각이 여기서 그대로 필요하다.
에이전트 하나를 순차적으로만 쓰는 사람에게는 Orca 스스로도 “필요 이상의 표면적”이라고 인정한다.
유휴 상태에서도 RAM을 400~800MB 먹고, 모바일 앱은 데스크톱 세션이 살아 있어야 동작한다.
매일 릴리즈가 나오는 만큼 업데이트 전에 체인지로그를 확인하는 습관이 필요하다.
반대로 여러 에이전트를 이미 병렬로 굴리고 있거나
같은 작업의 구현을 비교 선택하고 싶은 사람에게는 지금 가장 완성도 높은 선택지로 보인다.
마무리하며
Orchestrator는 Agent가 아니다에서 오케스트레이션은 결정론적 코드의 영역이라고 썼다.
Orca는 그 관점을 개발 환경 레벨로 끌어올린 도구다.
에이전트의 판단은 각 CLI에 맡기고
격리·배분·비교·머지 오케스트레이션은 git worktree라는 결정론적 구조로 푼다.
IDE 다음이 ADE일지는 아직 모르겠지만
“에이전트 여러 대를 어떻게 다룰 것인가”가 2026년 하반기 개발 도구의 주전장이 된 것은 분명해 보인다.
글쓴이 · Plutojoshua
핀테크에서 LLM과 AI 에이전트를 실제 서비스에 적용하는 개발자다. 카카오 AI 앰배서더로 Kanana 모델을 앱에 직접 연동해 검증하고, 비전공자로 시작해 실제 코드와 측정값을 근거로 “왜 그렇게 설계했는지”를 1인칭으로 기록한다. 운영자 소개는 About, 코드는 GitHub에서 볼 수 있다.