Ai

Orca — 에이전트를 병렬로 굴리는 개발 환경(ADE)

목차

터미널에서 Claude Code 하나 띄워놓고 일하다 보면 결국 이렇게 된다. 작업 하나 시켜놓고 기다리고, 끝나면 브랜치 갈아끼우고, 다음 작업 시키고. 에이전트는 병렬로 일할 수 있는데 내 작업 공간이 하나라 순차가 된다.

Orca 는 그 부분을 건드리는 도구다. ADE 라고 부른다. Agent Development Environment. 에디터가 사람용 IDE 면 이건 에이전트용 IDE 인듯

2026년 3월에 나왔고 MIT 라이선스다. 아래 내용은 2026년 9월 기준. 변화가 빠른 프로젝트라 설정 포맷 같은건 바뀔 수 있다.

모델이 아니다

Orca 는 AI 가 아니다.

자체 모델이 없다. 내가 이미 쓰고 있는 CLI 에이전트를 대신 실행해주는 껍데기다. Claude Code, Codex, Cursor CLI, OpenCode, GLM-5.2 같은 것들. 문서상 30종이 넘는다. 터미널에서 도는 코딩 에이전트면 대체로 붙는다.

그래서 구독이나 API 키가 따로 있어야 한다. Orca 자체는 공짜다.

worktree 개념

이 도구는 아래 한 줄로 설명된다.

작업 하나 = git worktree 하나 = 에이전트 하나

Orca 가 만드는건 진짜 git worktree 다. 자체 가상 레이어가 아님. 디스크에 실제 디렉토리가 생기고 브랜치가 체크아웃된다. 터미널에서 cd 해서 평범한 git 명령을 그대로 써도 된다. Orca 를 지워도 작업물은 남는다.

에이전트끼리 같은 파일을 건드릴 일이 없다. 각자 자기 디렉토리를 가진다. 브랜치 갈아끼울 필요도, stash 할 필요도 없다.

설치

1
2
3
4
5
# macOS
brew install --cask stablyai/orca/orca

# Arch
yay -S stably-orca-bin

Windows 는 GitHub releases 의 installer, Linux 는 AppImage 나 .deb / .rpm. macOS 빌드는 서명·공증돼 있다.

리눅스에서는 CLI 이름이 orca 가 아니라 orca-ide 다. GNOME 스크린리더 orca 랑 이름이 겹쳐서 그렇다.

첫 실행 때 저장소 관리용으로 홈 디렉토리 접근을 요청한다. ~/.claude ~/.codex Ghostty 설정이 있으면 가져올지 물어본다. 자동 업데이트가 기본이고 stable 채널을 탄다.

기본 흐름

문서에 정리된 흐름은 아래와 같다.

1
add → worktree → agent → split → diff → ship

1. 저장소 추가

사이드바 Add Repo 로 로컬 체크아웃을 지정한다. git 상태를 읽고 기본 브랜치를 base ref 로 잡는다.

2. worktree 만들기

저장소 이름 옆 +. 작업 이름을 넣으면 그게 브랜치명이 된다. 비우면 바다생물 이름을 알아서 붙여준다.

start-from ref 를 고른다. 보통 base ref(origin/main)인데 다른 로컬 브랜치, 원격 브랜치, 커밋 SHA 도 된다.

만들기를 누르면 다이얼로그는 바로 닫힌다. git fetch 와 git worktree add 는 백그라운드로 돈다. 사이드바에는 진행 표시줄이 달린 채로 나타난다.

3. 에이전트 붙이기

터미널이 열리고 위에 에이전트 콤보박스가 있다. 고르면 해당 디렉토리 컨텍스트와 자격증명을 물려서 그 CLI 를 띄워준다.

4. 경주시키기

2~3번을 반복해서 같은 프롬프트를 서로 다른 에이전트 셋에 던진다. Orca 가 내세우는 원래 용도가 이거다.

5. 화면 분할

worktree 탭을 다른 패널의 오른쪽이나 아래 가장자리로 드래그하면 쪼개진다. 셋이 동시에 도는걸 한 화면에서 본다.

6. 고르고 내보내기

각 worktree 의 diff 뷰어를 연다. Annotate AI Diff 로 diff 줄에 직접 코멘트를 달면 그대로 에이전트한테 되돌려 보낼 수 있다. 이게 꽤 괜찮다. 리뷰 → 수정 지시가 한 화면에서 끝난다.

제일 나은걸 고르면 Orca 안에서 바로 commit·push. 나머지는 원클릭으로 지운다. 디렉토리와 브랜치가 같이 삭제된다 (확인은 받는다).

병합 안 된 커밋 때문에 git 이 브랜치 삭제를 거부하면 일단 지우지 않고 남겨둔다. 그 다음 강제 삭제할지 유지할지 고르게 해준다.

실무에서 제일 먼저 막히는 것

worktree 를 새로 파면 node_modules 도 .env 도 빌드 캐시도 없다. 매번 npm install 을 새로 돌리면 병렬의 의미가 없다. 여기가 진짜 장벽이다.

Orca 는 두 가지로 푼다. 공유할 것과 복사할 것을 나눈다.

저장소에 커밋하는 파일이다.

1
2
3
4
worktree:
  sharedDirectories:
    - node_modules
    - .cache

복사가 아니고 symlink 나 APFS clone-copy 라서 디스크와 시간을 아낀다. npm install 자체는 그대로 돈다. 주 체크아웃에서 이미 받아둔게 깔려 있어서 훨씬 빨리 끝난다.

조건이 두 개 있다.

  • 주 체크아웃에 실제로 있는 디렉토리일 것
  • gitignore 되어 있을 것

추적 중이거나 없는 경로는 그냥 건너뛴다. 조용히 무시된다. 안 먹으면 이걸 의심하자.

.worktreeinclude — 복사

저장소 루트에 두는 파일. 이쪽은 symlink 가 아니고 복사다. worktree 마다 자기 사본이 있어야 하는 것들을 넣는다.

1
2
3
# 로컬 환경변수
.env
.vscode/settings.json

빈 줄과 # 주석은 된다. 글롭은 안 되고 리터럴 경로만 된다.

기준은 아래처럼 잡으면 된다.

대상예
sharedDirectories재생성 가능하고 큰 것node_modules, .cache
.worktreeincludeworktree 별로 값이 달라야 하는 것.env, 로컬 설정

Orca CLI 로 조종하기

UI 만 보면 그냥 예쁜 터미널 래퍼 같다. 개인적으로는 이쪽이 더 흥미롭다.

orca 명령으로 실행 중인 Orca 를 외부 셸에서 조종할 수 있다. Settings → General → Orca CLI 에서 등록한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
# worktree
orca worktree ps                 # 목록
orca worktree create             # 생성 (repo, name, issue 연결)
orca worktree current            # 현재 worktree
orca worktree rm                 # 삭제

# 에이전트 터미널
orca terminal list
orca terminal send  ...          # 입력 밀어넣기
orca terminal read  ...          # 출력 읽기
orca terminal wait  ...          # 특정 상태까지 대기
orca terminal split ...          # 방향 지정 분할

# 파일 / diff
orca file open
orca file diff
orca file open-changed

브라우저도 조종된다.

1
2
3
4
5
6
orca goto <url>
orca snapshot          # 상호작용 가능한 DOM 상태
orca click / orca fill
orca screenshot
orca set device        # 반응형 테스트용 디바이스 프로파일 전환
orca tab profile       # 격리된 브라우저 세션

iOS 시뮬레이터 제어(orca emulator attach/tap/type/gesture/rotate)도 있다. orca automations 로 스케줄 작업, orca artifacts 로 공유 링크 관리, orca skills install 로 에이전트 능력 등록까지 된다.

대부분 --json 출력과 --worktree <selector> 타게팅을 받는다.

그러니까 에이전트가 Orca 자체를 조종하게 만들 수 있다. terminal send 로 지시를 넣고, terminal wait 으로 끝날때까지 기다리고, file diff 로 결과를 읽는다. 이 루프를 셸 스크립트로 짜면 된다.

어디서 돌릴지 고르기

방식하는 일한계
로컬 데스크톱에이전트·터미널·브라우저가 내 노트북에서노트북 자원에 묶이고 슬립되면 멈춤
SSH 타깃에이전트와 worktree 는 원격, 에디터·diff 는 로컬원격에 git 등 사전 세팅 필요, 연결 끊기면 멈춤
원격 Orca 서버orca serve 로 상시 런타임, 여러 클라이언트가 세션 공유상시 켜둘 장비를 따로 관리해야 함
클라우드 VMworktree 마다 레시피로 샌드박스·VM·Docker 를 띄움worktree 당 비용, 레시피 관리. 관리형 호스팅은 제공 안 함
모바일원격 서버 세션에 폰으로 재접속원격 서버가 있어야 함

원격 서버 방식은 Tailscale 을 권장한다. 장시간 도는 에이전트 세션이나 폰으로 상태만 볼 거면 이 조합이 맞는듯

언제 쓰면 좋을까

쓸 데와 안 쓸 데가 꽤 명확하다.

맞는 경우

  • 어떻게 짤지 모르겠는 문제: 정답 접근이 안 보일때 셋을 경주시키고 고른다. 원래 용도다
  • 에이전트 비교 평가: Claude Code 와 Codex 중 뭐가 나은지 실제 코드로 재보고 싶을때
  • 독립적인 작업이 여러 개: 버그 셋이 서로 다른 파일이면 진짜로 병렬이 된다
  • 리뷰가 무거운 팀: diff 줄 코멘트를 에이전트에 되돌리는 루프
  • 원격 개발: SSH 로 서버에서 돌리고 폰으로 상태만 본다

안 맞는 경우

  • 작업이 순차 의존적일때: A 가 끝나야 B 를 아는 구조면 병렬이 의미 없다. 진단 → 수정 → 측정으로 이어지는 일이 대체로 이렇다
  • 답이 하나로 모이는 일: 글쓰기나 설정 수정. 셋을 돌리면 고르는데 더 걸린다
  • 토큰 예산이 빡빡할때
  • 안정성이 중요한 프로덕션 워크플로: 아직 이르다

걸리는 것들

비용이 배수로 는다

셋을 경주시키면 토큰도 3배다. 그리고 둘은 버린다.

리뷰 부담도 같이 는다. 한 독립 리뷰에 “parallel sessions can multiply cost and review debt” 라고 적혀 있다. 셋 중 하나를 고르려면 diff 셋을 다 읽어야 한다. 안 읽고 고르면 그냥 주사위 굴리는 거다.

보안 지적은 절반만 정리됐다

Windows 쪽으로 네 가지가 지적됐다. 2026년 9월 16일 기준으로 저장소를 확인해보니 아래와 같다.

지적상태
Windows 경로 하드닝 ACL 이 실제로는 안 돌던 문제머지됨 (9/6, PR #17884)
불필요한 -ExecutionPolicy Bypass머지됨 (9/6, PR #17873)
데몬 리스너가 모든 인터페이스에 열리던 문제열려 있음 (PR #20690, 9/14 생성)
에이전트 프롬프트가 자격증명 입력창에 타이핑되는 문제열린 draft (PR #19978, 리뷰 지적 미해결)

ACL 건은 꽤 실질적이었다. powershell.exe -Command 가 $args 를 안 채웠다. 그래서 하드닝 스크립트가 대상 없이 돌았고 아무것도 보호하지 않았다. 그런데 테스트는 통과하고 있었다.. icacls.exe 로 바꾸면서 인젝션 표면도 같이 없앴다.

아직 열려 있는 두 건이 더 신경쓰인다.

리스너 건은 한 번이라도 페어링한 기기가 있으면 그 이력만으로 런타임이 0.0.0.0 에 바인딩되던 동작이다. PR 설명에 이렇게 적혀 있다.

네트워크에 노출하겠다고 한 적 없는 운영자에게, 어떤 기기가 한 번 붙었다는 이유만으로 런타임이 모든 인터페이스에 바인딩돼서는 안 된다.

수정은 networkExposureConsent 를 기본 false 로 두고, 명시적 동의가 있을때만 loopback 밖으로 나가게 한다. 아직 머지 전이다.

자격증명 건은 더 고약하다. Orca 는 에이전트가 준비됐다고 판단하면 작업 프롬프트를 타이핑한다. 그 판단이 틀렸는데 화면에 자격증명 입력창이 떠 있으면 프롬프트가 인증 제공자한테 자격증명으로 제출된다. draft 상태고, 리뷰에서 지적된 오탐·비영어 프롬프트 미탐지가 아직 안 풀렸다.

사내 장비나 민감한 저장소에 바로 붙이기 전에 격리 환경에서 먼저 보자.

텔레메트리가 기본 켜짐

익명 수집이고 opt-out 방식이다. 직접 꺼야 한다.

아직 어리다

나온 지 반년이다. 워크플로나 설정 안정성이 검증됐다고 보긴 어려운듯

정리

  • 모델이 아니고 껍데기다. 에이전트 구독은 따로 있어야 한다
  • worktree 가 전부. 진짜 git worktree 라서 Orca 없이도 남는다
  • 의존성 처리가 첫 관문. orca.yaml 로 공유, .worktreeinclude 로 복사
  • CLI 쪽이 진짜 쓸만한 부분. 에이전트가 Orca 를 조종하게 만들 수 있다
  • 순차 의존적인 일에는 이득이 없다. 접근법이 갈리는 문제에 쓰는 도구
  • 비용도 배수, 리뷰 부담도 배수
  • 보안 지적 4건 중 2건은 머지, 2건은 진행 중. 격리 환경에서 먼저 보자

써볼 거면 Your first 3-agent session 튜토리얼 하나만 따라가면 감이 올듯. 문서가 스스로 “가장 중요한 페이지” 라고 표시해둔 곳이다.

이 블로그처럼 node_modules 도 없는 Hugo 정적 사이트에선 worktree 생성 비용이 거의 0이다. 병렬 이득도 그만큼 작다. 쓴다면 회사 코드베이스 쪽이 맞을 것 같다.

참고