에이전트 다섯을 동시에 굴리는 작업대: stablyai/orca v1.4.229의 워크트리 네이티브 모델·orcad 런타임 분리·오케스트레이션 심층 해부

코딩 에이전트 하나를 터미널에서 돌리는 단계는 이미 지났다. 요즘 실무자들의 고민은 “Claude Code·Codex·OpenCode를 동시에 여러 개 돌릴 때 파일 충돌, 브랜치 정리, 누가 끝났는지 추적, 노트북을 덮어도 계속 돌게 하기”를 어떻게 처리하느냐다. 오늘(2026-10-19) GitHub Trending 전체 일간 7위(오늘 +1,146 stars), TypeScript 일간 4위에 오른 stablyai/orca는 이 문제를 “에이전트마다 자기 git 워크트리를 하나씩 주고, 그 위에 IDE·런타임 서버·CLI·모바일을 얹는다”는 방식으로 푼다. README의 한 줄 소개도 “Codex, Claude Code, OpenCode, Pi를 나란히 실행하되 각자 자기 워크트리에서, 추적은 한곳에서”다.

이 글은 기능 목록을 옮기는 대신 세 가지를 확인한다. ① 워크트리 네이티브 모델과 orca.yaml·.worktreeinclude가 실제로 무엇을 보장하고 무엇을 보장하지 않는지, ② UI와 분리된 orca serve/orcad 런타임·터미널 데몬·오케스트레이션 계층이 어떻게 생겼는지, ③ 텔레메트리·원격 페어링·에이전트 “폴더 신뢰” 사전 기록 같은 신뢰 경계다. 그리고 박스(리눅스 VM)에서 공식 AppImage v1.4.229를 받아 GUI 없이 헤드리스 서버로 띄워, 워크트리 생성부터 서버 재시작 후 터미널 생존까지 직접 돌려 봤다. 수치는 모두 2026-10-19 11:50~12:00 KST 기준이다.

한눈에 보기: 오늘 기준 스냅숏

왜 지금 트렌딩인가

Orca는 3월에 공개돼 이미 10만 스타에 가까운 저장소라 신작은 아니다. 오늘 다시 상위권에 오른 데는 “에이전트를 몇 개 굴리느냐”가 이번 주 개발자 커뮤니티의 공통 화두라는 배경이 있다. 같은 날 Trending에는 opencode(전체 #3), cursor/plugins(#4), ruflo(#5), ai-memory(#6)처럼 에이전트 런타임·하네스·메모리 저장소가 몰려 있고, Orca는 그 에이전트들을 담는 그릇 역할을 한다.

문제 정의: 병렬 에이전트의 네 가지 마찰

핵심 설계 판단은 “에이전트를 직접 만들지 않는다”는 것이다. Orca는 모델 호출·프롬프트 루프를 소유하지 않고, 각 에이전트 CLI를 PTY 안에서 실행하며 작업 공간(워크트리)·터미널·리뷰·알림을 소유한다. 그래서 새 에이전트 CLI가 나와도 터미널에서 돌기만 하면 바로 붙고, 반대로 에이전트 내부 품질에는 관여하지 않는다.

저장소 구조: 거대한 단일 모노레포

눈에 띄는 것은 품질 장치의 밀도다. package.json 스크립트 175개 중 상당수가 check:*-ratchet(최대 줄 수, @ts-nocheck 수, 경로 리터럴, 동기 spawn 금지 등을 “늘어나지 못하게” 고정하는 검사)와 bench:*(유휴 CPU, 메인 스레드 jank, 터미널 타이핑 지연)다. 또 pnpm-workspace.yaml에 minimumReleaseAge: 4320(분, 즉 3일)을 걸어 새로 올라온 npm 버전은 3일이 지나야 설치되게 했다. 공급망 공격의 “첫 며칠”을 피하는 실용적인 방어다. 저장소 루트에 AGENTS.md(13.8KB)를 두고 CLAUDE.md는 그 파일을 가리키게 한 것도, 이 코드베이스 자체가 에이전트로 대량 개발되고 있음을 보여 준다.

런타임 아키텍처: UI는 손님, 서버와 터미널 데몬이 주인

릴리스 AppImage를 풀어 보면 구조가 그대로 드러난다. resources/ 아래에 Electron 앱 번들(app.asar 72MB + unpacked 102MB) 외에 별도 Node 런타임(121MB), orcad-template(85MB: orcad-server.js·daemon-entry.js 등), 브라우저 자동화용 agent-browser, ripgrep, 컴퓨터 유즈 헬퍼가 따로 들어 있다. 헤드리스로 orca serve를 띄우면 Electron 프로세스가 번들 Node 24로 orcad 서버를 띄우고, 그 서버가 다시 PTY를 소유하는 터미널 데몬을 별도 프로세스로 둔다.

CLI의 구현도 흥미롭다. Linux 런처 셸 스크립트는 별도 Node를 깔지 않고 ELECTRON_RUN_AS_NODE=1로 앱 실행 파일을 Node처럼 돌려 app.asar.unpacked/out/cli/index.js를 실행한다. 덕분에 orca-ide --version이 0.1초 만에 응답하고, 앱과 CLI 버전이 항상 일치한다. 모든 명령이 --json에서 {id, ok, result, _meta} 봉투를 돌려주며, orca agent-context --json은 281개 명령의 기계 판독용 스키마(v1)를 출력한다. 에이전트가 Orca를 “도구”로 쓰도록 처음부터 설계된 셈이다.

워크트리 네이티브 모델: 무엇을 보장하나

문서의 첫 문장이 “Orca is worktree-native”다. 작업 하나 = 워크트리 하나 = 브랜치 하나이며, 각 워크트리가 자기 에이전트 터미널·에디터 탭·브라우저 탭을 가진다. 생성은 백그라운드에서 git fetch와 git worktree add를 돌리고, 삭제는 디렉터리와 브랜치를 함께 지운다(병합 안 된 커밋이 있으면 브랜치를 보존하고 “Review N Branches”로 알린다). 모든 워크트리는 진짜 git 워크트리라 터미널에서 git rebase를 해도 Orca가 다음 갱신 때 반영한다.

orca.yaml은 생각보다 엄격하다. 파일 전체 256KiB, 문자열 필드 64KiB 상한이 있고, 중복 키가 하나라도 있으면 파일 전체를 거부한다(“마지막 값 우선”을 기대하면 안 된다). 또 어떤 설정을 어느 체크아웃에서 읽는지가 갈린다. setup 스크립트·defaultTabs는 새 워크트리의 orca.yaml에서, 공유 디렉터리·복사 규칙·archive 스크립트는 기본(primary) 체크아웃에서 읽는다. 기능 브랜치에서 .worktreeinclude를 고쳐도 다음 워크트리에 반영되지 않는 이유다. setup 러너에는 ORCA_ROOT_PATH·ORCA_WORKTREE_PATH와 함께 CONDUCTOR_ROOT_PATH 호환 별칭이 들어가는데, 비슷한 워크트리 기반 도구에서 넘어오는 사용자를 의식한 흔적이다.

# orca.yaml (repo root)
scripts:
  setup: |
    pnpm install
  archive: |
    echo Workspace archived
setupAgentStartupPolicy: wait-for-setup   # 셋업 성공 후 에이전트 시작
defaultTabs:
  - title: Agent                           # 첫 탭은 에이전트 몫(템플릿 명령 무시)
  - title: Git status
    command: git status --short
worktree:
  sharedDirectories:
    - .cache                               # 존재 + gitignore된 디렉터리만

# .worktreeinclude (repo root) — 한 줄에 리터럴 경로 하나
.env
.env.local

오케스트레이션 계층: Run · Task · Dispatch · Gate

여러 에이전트를 “나란히” 띄우는 것과 “조율”하는 것은 다르다. Orca의 오케스트레이션(설정 → Experimental에서 활성화)은 코디네이터 에이전트가 CLI로 작업을 쪼개 워커 에이전트에게 맡기고, 완료·질문·하트비트를 메일함으로 받는 구조다. 메시지 큐를 따로 띄우지 않고 런타임 서버가 상태를 들고 있다.

설계에서 좋은 점은 완료 권한을 Dispatch ID에 묶은 것이다. 워커는 worker_done을 정확히 한 번, --outcome succeeded|failed와 task·dispatch ID를 함께 보내야 하므로, 재시도된 오래된 워커가 엉뚱한 작업을 “완료” 처리하는 사고를 막는다. 반면 보낸 쪽 터미널을 식별해야 하므로 Orca 터미널 밖에서 부르면 거부된다(스모크에서 no_active_sender_terminal 확인). 즉 오케스트레이션은 “Orca 안에서 도는 에이전트를 위한 API”이지 범용 워크플로 엔진이 아니다.

설치와 실행: 문서에 있는 명령 그대로

# 데스크톱 (macOS / Linux AUR)
brew install --cask stablyai/orca/orca
yay -S stably-orca-bin

# Linux AppImage를 직접 받는 경우
curl -LO https://github.com/stablyai/orca/releases/latest/download/orca-linux.AppImage
chmod +x orca-linux.AppImage

# CLI 등록은 앱 Settings → General → Orca CLI (Linux 명령은 orca-ide)
orca status --json
orca worktree create --repo id:<repoId> --name my-task --issue 123 --json
orca terminal wait --for tui-idle --timeout-ms 30000 --json

# 헤드리스 서버 (Linux)
orca-ide serve --pairing-address 100.64.1.20

# 에이전트에게 Orca 사용법 스킬 설치
npx skills add https://github.com/stablyai/orca --skill orca-cli
orca skills install --skill orca-cli --skill orchestration

# 소스에서 (CONTRIBUTING: Node 24 + pnpm + Bun)
pnpm install && pnpm dev

박스 스모크 테스트: 헤드리스 serve로 끝까지 돌려 보기

박스는 Node 20이라 소스 빌드(Node 24 + pnpm 12 필요)는 하지 않고, 공식 릴리스 orca-linux.AppImage(265,301,177바이트, sha256 033e947e…7da0)를 --appimage-extract로 풀어 썼다. 격리된 HOME/XDG 디렉터리, DO_NOT_TRACK=1·ORCA_TELEMETRY_DISABLED=1, 페어링 끔(--no-pairing), 에이전트 로그인 없음 조건이다. “에이전트” 자리에는 파일을 수정하는 파이썬 한 줄짜리 가짜 에이전트를 넣었다.

신뢰 경계와 보안: 편의를 위해 넓힌 곳

비슷한 도구와 비교

이 블로그에서 앞서 다룬 도구와도 위치가 다르다. trycua/cua(2245)는 에이전트가 GUI를 조작하는 컴퓨터 유즈 인프라, ECC(2884)와 CLI-Anything(3030)은 에이전트 안쪽의 하네스·도구층이다. Orca는 그 바깥에서 여러 에이전트 프로세스의 작업 공간과 수명을 관리하는 층으로, 위 도구들과 경쟁하기보다 함께 쓰이는 관계다.

평가 방법: 우리 팀에 맞는지 재는 법

트레이드오프와 주의점

누가 도입하면 좋은가

정리

Orca의 본질은 “에이전트 IDE”라기보다 에이전트 프로세스를 위한 작업 공간·수명 관리 런타임이다. 작업마다 git 워크트리를 주고, setup·복사 규칙으로 환경을 재현하고, PTY를 별도 데몬에 맡겨 UI·서버 재시작과 분리했으며, 그 전부를 281개 명령의 JSON CLI로 에이전트에게도 열어 두었다. 박스에서 헤드리스로 돌려 보니 워크트리 생성 0.34초, 병렬 3개 생성, 서버 재시작 후 터미널 12개 재부착까지 문서대로 동작했다. 반면 0.0.0.0 바인드, 기본 켜진 텔레메트리, 에이전트 폴더 신뢰 사전 기록처럼 편의를 위해 넓힌 경계도 분명하다. 워크트리 모델과 런타임 분리는 적극적으로 쓰되, 네트워크·텔레메트리·신뢰 경계는 내 기준으로 좁혀서 도입하는 것이 지금 시점의 합리적인 사용법이다.