Orca ADE | 병렬 AI 코딩 에이전트와 git worktree 오케스트레이션

오늘 스레드에서 Orca 써 보라길래 찾아 깔아 봤다. 위키 포스팅을 이걸로 돌리고, 이어서 다른 업무 에이전트도 붙여 보니 체감이 확 달랐다. 원래 Cursor나 Antigravity, 특히 Codex 쪽에 이미지 여러 장·편집을 계속 몰아넣으면 한 창이 버티지 못한다. 메모리 수십 기가까지 불어나고 CPU가 치고, 결국 머신 전체가 느려진다. 그런데 Orca로 나눠 돌리니 같은 PC인데도 숨이 트이는 느낌이었다.

왜 빠르냐면, Orca가 모델을 마법처럼 가속해서가 아니다. 무거운 작업을 한 IDE 세션에 몰아넣지 않고, 작업마다 git worktree + 별도 CLI 프로세스로 쪼개 두기 때문이다. 이미지·편집으로 한 에이전트가 버거워도 다른 worktree에서 다음 일을 이어 갈 수 있고, 터미널 중심 ADE라 “한 창에 모든 걸 쌓아 둔 Cursor형 세션”과 부하 패턴이 다르다. 병렬·멀티 에이전트를 남들이 어떻게 저렇게 띄우나 싶었는데, 알고 보니 이런 오케스트레이션을 쓰는 쪽이었다. 고민만 하지 말고 일단 설치해 실행해 보는 쪽이 맞다. git·diff가 낯설면 어렵긴 하다. 그래도 문서만 읽다 멈추기보다, worktree 하나 만들고 CLI 하나 붙여 보는 게 빠르다.

Orca(온오르카) 는 Stably AI가 만든 오픈소스 ADE(Agent Development Environment) 다. 일반 IDE가 아니라 ADE를 표방한다. 사람 한 명을 위한 편집기가 아니라, 사람과 그 사람의 에이전트 무리를 위한 환경이다. 공식 홈·문서·소스는 아래 바로가기 링크에 모았다. Y Combinator 지원, MIT 라이선스, macOS·Windows·Linux 데스크톱과 iOS·Android 모바일 컴패니언이 있다. 2026년 7월 기준 GitHub 스타는 약 1만 7천대이고, 팀은 매일 배포(ship daily) 를 내건다. 기능 목록보다 릴리스 changelog가 실제 최신에 가깝다.

이 문서는 공식 홈·문서·README·텔레메트리·워크트리·Design Mode·SSH·Orchestration과, 공개 리뷰·실사용 체감·GitHub 이슈를 교차해 특징, 왜 빠른지, 왜 쓰는지, 공식 CLI 안전성, 일반·전문가 사용법, Windows CLI 연결, 장단점을 한곳에 모았다.

바로가기 링크

홈에서 감을 잡고, 문서로 절차를 보고, GitHub로 버전·이슈를 확인하면 된다. 폰↔PC를 다른 망에서 이을 때는 Tailscale, Cursor/agy 없이 모델만 터미널로 붙일 때는 NeuralWatt 문서를 보면 된다.

그림 1. Orca는 모델·git 대체·클라우드 전용이 아니라 ADE다

1. ADE와 IDE의 차이

Orca 문서가 먼저 선을 긋는다. 모델이 아니다. Claude·Codex·OpenCode 같은 이미 쓰는 구독·CLI를 가져와 돌린다. git 대체품이 아니다. 모든 작업 단위는 진짜 git worktree다. 터미널에서 cd 한 뒤 평소처럼 git status, rebase, cherry-pick을 쓰면 Orca가 다음 렌더에 반영한다. 클라우드 전용도 아니다. 로컬에서 돌고, 원격은 본인이 소유한 머신 SSH로 붙인다.

공식 문서의 쓰기 좋은 경우는 네 가지다. 같은 버그에 세 에이전트를 병렬로 붙여 승자를 고를 때, AI diff를 배포 전에 진지하게 리뷰할 때, Claude Code·Codex·Cursor CLI를 이미 결제 중이고 한곳에서 오케스트레이션하고 싶을 때, IDE를 포기하지 않고 SSH로 원격 에이전트를 돌리고 싶을 때다. 대상은 코드로 먹고살며 AI를 대체가 아니라 레버리지로 쓰는 사람이다. diff를 읽고, 커밋을 신경 쓰고, worktree를 정리할 줄 안다는 전제다. 노코드 도구를 찾는 사람에게는 맞지 않는다고 문서에 명시돼 있다.

1.1. 서브 에이전트와 병렬 에이전트 군단

현장·소개 영상에서 헷갈리기 쉬운 구분이다. 한 창(한 CLI 세션) 안에서도 Cursor·Claude Code·Antigravity·Codex는 메인 에이전트 + 서브 에이전트 구조로 일을 쪼개는 경우가 많다. 이건 같은 제품 안의 위임이다. 사람들이 말하는 병렬(플릿) 에이전트는 그 한 단계 위다. Orca 패인마다 각각 공식 CLI 세션(그리고 그 안의 서브 에이전트군) 을 두고, worktree로 파일까지 가둔 채 동시에 돌리는 것이다.

Cursor의 에이전트 윈도우로도 여러 채팅을 열 수 있지만, 창·탭을 하나씩 늘리는 방식이면 금세 버벅이거나 한도가 난다. Orca는 터미널 패인을 늘리고 드래그로 위·아래·좌·우에 붙이는 쪽에 가깝다. “사람들이 CLI로 멀티·병렬을 돌린다”는 말이 여기서 연결된다.

2. 핵심 특징

그림 2. 파일은 worktree로 격리하고, 비교·리뷰·머지는 사람이 한다

2.1. 병렬 워크트리

Orca는 worktree-native다. 한 체크아웃에서 브랜치를 바꾸고 stash하는 대신, 작업(task)마다 디스크상 독립 사본을 둔다. 에이전트가 서로의 파일을 덮어쓰지 않고 동시에 일할 수 있는 기반이다. 한 프롬프트를 여러 에이전트에 동시에 던지고(fan-out), 격리된 결과를 비교한 뒤 나은 쪽을 머지하는 흐름이 대표 시나리오다.

문서상 모델은 간단하다. 레포에는 base ref(보통 origin/main)가 있고, 각 worktree는 start-from ref·자체 브랜치·디스크 파일·에이전트 터미널을 갖는다. 삭제 시 디렉터리와 브랜치를 함께 지운다(확인 후). 생명주기는 생성 → 작업 → 리뷰 → 배포(커밋·푸시·PR) → 아카이브/삭제다.

생성은 백그라운드로 돈다. Create 대화상자를 닫아도 git fetch와 git worktree add가 이어지고, 사이드바에 진행 행이 보인다. start-from은 base ref, 다른 로컬 브랜치, 커밋 SHA, 원격 브랜치를 고를 수 있다. 브랜치 이름은 워크스페이스 이름·연결된 GitHub PR·Linear/Jira 이슈·GitLab MR에서 파생되며, Advanced에서 직접 지정할 수도 있다. 부모 폴더에 여러 git 레포가 있으면 멀티레포 프로젝트 그룹과 폴더 워크스페이스로 묶을 수 있다. 외부에서 git worktree add로 만든 트리는 inbox에 잡혀 import하거나 숨길 수 있다.

다만 worktree 격리는 파일 충돌을 막는 것이지, 포트·로컬 DB·공유 서비스 충돌까지 막아 주지는 않는다. 같은 포트로 개발 서버를 두 개 띄우거나 동일 DB에 쓰면 여전히 부딪힌다. 머지 단계에서 사람이 충돌을 푸는 일도 남는다.

2.2. Bring Your Own Agent

Orca는 모델 판매가 아니다. 터미널에서 돌아가는 CLI 에이전트면 붙인다는 입장이다. 공식·README에 나열된 예시는 Claude Code, Codex, Grok, Gemini, Cursor, GitHub Copilot, OpenCode, Amp, OpenClaude, Antigravity, Pi, oh-my-pi, Hermes Agent, Goose, Auggie, Charm, Cline, Codebuff, Continue, Droid, Kilocode, Kimi, Kiro, Mistral Vibe, Qwen Code, Rovo Dev, Devin, MiMo Code 등 수십 개 + any CLI agent다.

계정 스위처와 사용량 추적은 Claude Code·Codex·Gemini·OpenCode·Kimi Code·MiniMax 등의 로컬 사용량 상태를 읽어 상태바에 보여 준다. ~/.claude, ~/.codex 및 각 CLI 홈 아래 파일을 읽는 방식이며, 문서에 별도 API 호출·추가 인증 없음이라고 적혀 있다. 5시간·일·주간 한도와 리셋 시각, 80% 경고 칩을 지원한다(에이전트 종류별).

2.3. 터미널·편집기·검색

Ghostty급 WebGL 터미널, 무한 분할, 재시작 후에도 남는 스크롤백과 검색을 내세운다. 편집기는 VS Code 계열로 자동저장·Quick Open·숨김 파일 검색·파일·이미지를 에이전트 프롬프트로 드래그할 수 있다. Markdown·이미지·PDF 미리보기, worktree·파일·에이전트·명령을 가로지르는 네이티브 검색, 패인 분할로 에이전트·터미널·브라우저·diff·파일을 한 화면에 배치한다.

실사용 흐름은 단순하다. + 로 터미널(Windows면 PowerShell 계열)을 추가하고, 그 안에서 agent·agent.cmd·agy·claude 같은 공식 CLI를 띄운 뒤, 패인을 드래그해 위·아래·옆에 붙인다. Cursor IDE 창을 여러 개 켜 두는 것과 달리, 벤더 GUI를 닫아 두고 Orca 안의 CLI 세션만으로도 이어 갈 수 있다. 새 GUI가 나올 때마다 UI를 다시 익히기보다, CLI 호출과 패인 배치에 익숙해지는 쪽이 ADE의 학습 경로다.

2.4. Design Mode

내장 Chromium에서 Design Mode를 켠 뒤 UI 요소를 클릭하면, 해당 요소의 HTML(주변 포함), 계산된 CSS, 크롭 스크린샷, (가능하면) 소스맵 기준 파일·라인이 하나의 첨부로 활성 에이전트 채팅에 들어간다. 에이전트가 수정하면 핫리로드로 확인하고 다시 클릭하는 짧은 UI 수정 루프가 목표다. 공식 문서의 히어로 레시피도 “Design Mode로 UI 버그 고치기”다.

2.5. GitHub·Linear와 Annotate AI Diff

앱 안에서 PR·이슈·프로젝트 보드를 보고, 태스크에서 바로 worktree를 연다. AI가 만든 diff 라인에 마크다운 코멘트를 달아 배치로 에이전트에 되돌릴 수 있다. CI 확인·충돌 해결·PR 오픈까지 앱을 벗어나지 않으려는 설계다.

2.6. SSH 워크트리

Settings → SSH에 호스트·유저·포트·키를 등록한다. OpenSSH config와 Include도 가져온다. worktree 생성 시 Local 대신 SSH 타깃을 고르면 원격에 worktree를 만들고 에이전트는 원격에서 돈다. 편집·diff·브라우저는 로컬처럼 보이게 파일 이벤트를 동기화한다. 재연결·포트 포워딩(Detected 포트 원클릭, 권한 포트는 로컬에 리맵), 점프 호스트·프록시·연결 재사용 옵션이 있다. 데스크톱을 닫아도 원격 PTY는 릴레이에 임대되어 남고, 재접속 시 스크롤백과 함께 복구된다(기본 유예 약 5분, 타깃별 설정). Wi-Fi가 끊겨도 원격 에이전트는 계속 돈다.

2.7. 모바일 컴패니언·Orca CLI·Computer Use

폰에서 에이전트 상태·사용량·계정 전환·팔로업·Live input·Source Control을 한다. iOS는 App Store·TestFlight, Android는 GitHub APK다. 모바일은 데스크톱과 페어링하는 컴패니언이지 단독 코딩 IDE가 아니다. 노트북이 꺼지면 폰도 사실상 멈춘다. 세부 절차·네트워크는 아래 모바일 컴패니언·네트워크·Tailscale 절을 본다.

orca CLI는 데스크톱 앱과 함께 제공되며 Settings → Experimental → CLI에서 등록한다. worktree 생성·조회·삭제, 터미널 송수신·대기, 브라우저 click/fill, 스냅샷, 스케줄 자동화 등을 스크립트·에이전트가 호출한다. Computer Use로 데스크톱 앱 UI를 에이전트가 조작하는 경로도 문서화돼 있다. 에이전트용 스킬은 `npx skills add https://github.com/stablyai/orca --skill orca-cli` 형태로 안내된다.

2.8. Orchestration

단순 orca terminal send와 달리, Orchestration은 멀티 에이전트용 공유 inbox·task·dispatch·decision gate·worker_done·heartbeat를 둔다. 코디네이터가 작업을 쪼개 워커에 dispatch --inject하고, 워커는 taskId·dispatchId와 함께 완료를 보고한다. orca orchestration run --spec "…" --max-concurrent 3처럼 코디네이터 루프를 Orca가 돌릴 수도 있다. 실사용자가 말한 /orchestrate 계열 편의와 문서의 orchestration 계층이 맞닿는 지점이다.

그림 3. 공식 CLI라도 자격증명·약관·실행 위험을 나눠 본다

3. 오픈소스 커뮤니티·GitHub 스타와 기여자

Orca는 Stably AI가 공개한 MIT 오픈소스 ADE다. 2026년 3월 공개 이후 업데이트가 잦고, GitHub에서 관심·포크·이슈가 빠르게 쌓이는 편이다. 2026-07-14 기준 stablyai/orca API 기준으로 보면 대략 아래와 같다(수치는 매일 변하므로 링크에서 재확인).

README의 Developing 구역은 CONTRIBUTING.md로 로컬 기여를 안내하고, 기여자 아바타 그리드로 실제 커밋에 참여한 사람들을 보여 준다. “누가 고쳐 주나”가 궁금할 때 이 화면이 커뮤니티 존재감을 한눈에 보여 준다. 스타 수 자체는 품질 보증이 아니지만, 이슈·릴리스·기여자 밀도가 같이 움직이는지를 볼 때 Orca는 2026년 중반 기준 ADE 중에서도 공개 활동이 왕성한 축에 속한다.

그림 11. GitHub Developing — CONTRIBUTING 안내와 기여자 아바타 그리드

버그픽스·기능 요청은 리포 Issues·Discord·X(@orca_build) 쪽으로 열려 있다고 README가 안내한다. 엔터프라이즈 전용 SaaS라기보다 로컬 ADE + 커뮤니티 기여 모델에 가깝다. 도입을 고민할 때는 “스타만 많은지”보다 (1) 쓰는 CLI가 Supported Agents에 있는지, (2) Windows/macOS에서 최신 릴리스가 도는지, (3) 이슈 트래픽이 감당 가능한지 순으로 보는 편이 실무적이다.

4. 공식 CLI를 쓰는 구조와 안전성

“Claude Code·Antigravity 같은 공식 CLI를 Orca 같은 제3자 GUI에서 돌려도 되느냐”는 질문이 자주 나온다. 답은 자격증명·통신 경로와 약관, 에이전트 실행 위험을 나눠야 한다.

4.1. 기술적으로 맞는 부분

Orca는 벤더 인증을 새로 구현하거나 프록시 API를 끼워 넣는 방식이 아니라, 공식 CLI 바이너리를 터미널에서 실행한다. “터미널에서 돌면 Orca에서도 돈다”는 문구가 그 구조다.

4.2. 공식 Supported Agents 목록

공식 README·사이트는 이렇게 쓴다. Works with any CLI agent — if it runs in a terminal, it runs in Orca. 즉 목록에 없는 CLI라도 터미널에서 실행되면 붙일 수 있고, 아래는 UI에 칩으로 노출되는(또는 문서화된) 대표 지원 목록이다. 2026-07 기준 공개 화면에 보이는 이름이다

이름은 벤더 표기를 그대로 따랐다. 이 위키의 Windows 예시는 그중 Grok(grok) · Cursor Agent(cursor-agent/cs) · Antigravity(agy) 에 초점을 맞춘다. Orca 안에서는 “지원한다”와 “PATH에 설치돼 있다”가 다르다. 칩에 있어도 로컬에 바이너리가 없으면 패널만 비어 보인다.

그림 12. 공식 Supported Agents — 터미널 CLI면 Orca에서도 돌린다는 전제 로그인 토큰은 각 CLI 홈에 남고, 사용량 추적은 그 로컬 상태를 읽을 뿐이다. 모델 통신은 CLI ↔ 벤더 서버에서 이뤄지고, Orca가 프롬프트·응답을 가로채는 중간 프록시가 아니라는 점이 자체 구현 래퍼보다 신뢰하기 쉬운 이유다.

텔레메트리 문서도 보수적이다. 파일 내용·프롬프트·에이전트·터미널 출력·레포·브랜치·URL·경로·커밋 메시지는 전송하지 않는다. 익명 랜덤 ID와 버전·OS·에이전트 종류(고정 enum) 같은 제품 사용 이벤트만 PostHog(미국)로 보낸다. DONOTTRACK=1 또는 ORCATELEMETRYDISABLED=1, 또는 Settings → Privacy에서 끌 수 있다. 계정 시스템 자체가 없고, MIT 오픈소스라 주장을 코드로 검증할 여지가 있다.

4.3. 약관·정책은 별개

공식 CLI를 그대로 실행하는 것은, 구독 토큰을 제3자 하네스로 추출·프록시하는 것과 다르다. 후자(예: Antigravity OAuth를 가로채 Claude/OpenCode에 꽂는 비공식 프록시)는 Google 등 벤더가 약관 위반·계정 제재 사례를 공개적으로 경고한 유형이다. Orca처럼 공식 claude·agy(Antigravity) 바이너리를 로컬에서 감싸는 쪽은 상대적으로 안전한 편에 가깝다. 다만 벤더 정책은 2025~2026년에 빠르게 바뀌었고, 구독을 제3자 도구와 어떻게 조합하느냐를 회색지대로 보는 논의도 있다. 실제 사용 전 각 CLI의 최신 약관을 직접 확인하는 편이 맞다.

4.4. 에이전트 행동 위험은 남는다

공식 CLI라는 사실은 인증·통신 경로의 신뢰를 높일 뿐, 에이전트가 파일을 수정·삭제·명령을 실행하는 위험 자체를 없애지 않는다. worktree 격리는 에이전트 끼리의 파일 충돌을 줄일 뿐, OS 전역 샌드박스는 아니다. Browser Use·Computer Use·SSH·플러그인까지 켜면 공격 면은 오히려 넓어질 수 있다. 신뢰하기 어려운 코드베이스·외부 입력에는 별도 샌드박스와 머지 전 diff 리뷰가 필요하다.

4.5. CLI가 IDE보다 빠르게 느껴지는 이유

모델 API 지연 자체가 CLI라서 줄어드는 것은 아니다. 같은 모델이라도 감싸는 껍데기 무게가 다르다.

그래서 “CLI가 빠르다”는 말은 대개 토큰이 더 빨리 나온다기보다, PC가 덜 버벅인다 / 한 창이 덜 죽는다 / 다른 일을 동시에 이어 가기 쉽다는 체감에 가깝다. Orca는 그 CLI들을 IDE급 관제실로 묶되, 무거운 작업을 worktree 단위로 분리해 두는 쪽에 가깝다.

5. 왜 쓰는지와 실사용 후기

가치 제안은 세 가지 부정으로도 정리된다. 모델이 아니고, git 대체품이 아니며, 클라우드 전용이 아니다. 이미 여러 CLI를 결제 중인 사람이 “오케스트레이션 셸”을 원할 때 들어맞는다. Cursor·Windsurf처럼 한 벤더 에이전트에 깊게 통합된 제품과 역할이 다르다. 단일 에이전트 UI에 만족하면 그쪽이 맞고, 둘 이상·모바일 알림·벤더 중립이 필요하면 Orca 쪽이 맞다는 비교가 반복된다.

공개 후기는 아직 Reddit·HN 장문보다 X 인용·얼리어답터 블로그 비중이 크다. 표본 편향을 감안해야 한다. 공식 사이트가 큐레이션한 목소리와 독립 리뷰에서 반복되는 강점은 다음과 같다.

• X의 @EXM7777은 Claude Code + Codex + omp를 Orca 안에서 동시에 돌리며 /orchestrate가 위임에 편하다고 적었다(비자발적 협찬 표기). @fmontes는 Warp·Ghostty·CMUX를 거쳐 에이전틱 개발의 자리를 Orca에서 찾았다고 했고, @ericeastco는 Grok을 설계·Claude를 디자인·Codex를 구현으로 나눈 세팅을 소개했다.
• Warp·Ghostty·CMUX를 거쳐 에이전틱 개발의 자리를 Orca에서 찾았다는 평가.
• Grok을 설계·판단, Claude를 디자인, Codex를 구현으로 나누는 역할 분담 세팅.
• Codex·Claude Code를 관리하기 쉬워졌고, 팀의 배포·피드백 속도가 빠르다.
• Ghostty형 터미널 분할, 올인원, PR 리뷰를 1급 워크플로로 둔 점.

andrew.ooo 리뷰는 모바일 App Store 출시, 계정 스위처·한도 추적, SSH worktree가 겹친 시점에 관심이 몰렸다고 본다. Medium 등 해설 글은 worktree가 전체 클론 복제가 아니라 객체 DB를 공유하는 git 기능이라는 점을 강조한다. 동시에 “파일은 안 덮어써도 포트·DB는 충돌한다”, “병렬 = 구독 한도 N배”, “매일 배포 = 거친 모서리”를 솔직한 한계로 적는다.

종합하면, 후기 지형은 병렬 관리·올인원·빠른 팀 반응에 대한 호평이 주류이고, 대규모·장기·중립 검증은 아직 얇다.

실사용에서 특히 체감되는 동기는 구독·한도 로테이션이다. Antigravity 한도가 끝나면 Cursor CLI로, Cursor가 닳으면 Codex·Claude·Grok으로 — 제품을 일일이 열고 닫으며 UI를 다시 익히지 않고, 같은 Orca 화면의 다른 패인으로 넘긴다. 이미지도 못 만드는 구독, 코딩만 강한 구독, 토큰·전력 과금 API를 섞어 쓸 때 이 “한 관제실”이 빛난다. Codex·Cursor에 이미지·장시간 편집을 몰아넣으면 한 IDE 세션 메모리가 수십 GB까지 치솟는 체감이 반복되는데, worktree·CLI로 나누면 같은 PC에서도 부하가 한 창에 안 뭉친다는 보고가 많다. 다만 패인을 늘리면 CPU·스레드는 여전히 먹는다. 병렬을 키울수록 코어·스레드가 많은 CPU가 유리하고, 영상·로컬 생성 쪽은 별도로 NVIDIA GPU를 권하는 실무 조언과 맞물린다.

그림 4. 장단점을 보고 일반·전문가 루프를 고른다

6. 장점과 단점

6.1. 장점

6.2. 단점

2026년 7월 전후 GitHub 이슈 예시는 Resource Manager가 활성 세션을 orphan으로 오분류해 강제 종료(#8459), headless serve가 GUI 재실행을 가로채 에이전트 중단·중복(#8457), WSL 재개 경로 오류(#8470), SSH에서 Node/npm 툴체인 오선택(#8450), 내장 브라우저가 HTTPS 로컬·자체 서명 인증서를 못 여는 문제(#8454) 등이다. 개별 이슈는 곧 고쳐질 수 있으므로, 특정 버그 목록보다 “매일 배포형 제품의 회귀 빈도”로 읽는 편이 맞다. 중요 작업은 자주 커밋·푸시하고, 활성 worktree 수를 제한하는 방어가 실용적이다.

그림 5. 일반은 좁게·리뷰 필수, 전문가는 병렬·원격·오케스트레이션

7. 일반 사용자와 전문가 사용법

7.1. 시작 전 공통

이미 결제 중인 CLI를 PATH에 두고 Orca를 설치한다. 첫 실행이 CLI를 스캔해 에이전트 목록을 채운다. macOS는 brew install --cask stablyai/orca/orca 또는 DMG, Windows는 setup.exe, Linux는 AppImage, Arch는 AUR(stably-orca-bin)가 공식 경로다. 다운로드 허브는 onorca.dev/download와 GitHub Releases다.

잘 쓰는 전제는 도구가 아니라 사용자 쪽에 있다. diff를 읽고, worktree 개념을 알고, 에이전트 결과를 무조건 머지하지 않는 습관이다.

7.2. 일반 기준

처음부터 다섯 에이전트 fan-out을 하지 않는다. worktree 하나 · 에이전트 하나로 “기능/버그 단위 생성 → 작업 → diff 리뷰 → 머지 또는 폐기” 루프를 몸에 익힌다. Windows면 먼저 터미널 하나를 열고 agent / agent.cmd / agy가 각각 원하는 CLI인지 확인한 뒤, Orca + 로 패인을 늘려도 늦지 않다. 명령 이름이 헷갈리면 PowerShell 별칭으로 바꾸는 편이 터미널 쪽 장점이다. 프롬프트 범위는 좁게. UI 작업이면 Design Mode로 요소를 찍어 컨텍스트를 넘긴다. 자리를 비우면 모바일 페어링으로 완료 알림과 짧은 후속을 보낸다. Annotate AI Diff로 이상한 라인만 되돌려 보내는 것이 기본 안전장치다.

7.3. 전문가 기준

같은 프롬프트를 여러 에이전트·여러 worktree에 던져 비교·머지한다. 모델 강점에 맞춰 역할(설계·구현·테스트·UI)을 나누고, 계정 스위처로 rate limit을 넘긴다. 무거운 빌드는 SSH 원격, 반복 흐름은 orca worktree·orchestration·브라우저 자동화로 스크립팅한다. 장시간 자율 실행 전에는 스펙·테스트 계획을 먼저 쓰게 하고, 신뢰 구간이 낮은 레포에는 OS 수준 샌드박스를 별도로 둔다. Orchestration의 decision gate·worker_done 계약을 쓰면 “누가 뭘 끝냈는지”가 터미널 스크롤에만 남지 않는다. 패인끼리 산출물·요약을 건네며 핑퐁하거나, Orchestration으로 코디네이터가 워커에 일을 나누는 흐름이 “한 화면에서 여러 CLI가 협력한다”는 체감과 연결된다.

8. 다른 도구와 비교

공식 마케팅 비교와 독립 리뷰를 합치면 대략 아래와 같다. 수치는 제품 버전에 따라 바뀐다.

병렬 에이전트만 보면 johannesjo/parallel-code 같은 오픈소스나 Crystal·Conductor류도 있다. Orca의 차별은 터미널 래퍼에서 멈추지 않고 브라우저·편집·PR·모바일·오케스트레이션까지 한 환경으로 묶는다는 점에 가깝다.

9. 설치 후 체크리스트와 상황별 선택

1. 데스크톱 설치 후 Claude Code·Codex·Antigravity 등 쓸 CLI가 PATH·로그인 상태인지 확인한다.
2. 레포를 추가하고, 작은 버그용 worktree를 하나 만든다.
3. Design Mode·diff 주석을 한 번씩만 써 본다.
4. 필요하면 모바일 페어링, SSH 타깃, CLI 등록, 텔레메트리 옵트아웃을 설정한다.
5. 프로덕션에 가까운 레포에서는 병렬 수를 제한하고, 머지 전 사람 리뷰를 고정한다.

그림 6. 프로젝트 추가부터 diff·커밋·PR까지의 실전 순서

10. 실전으로 에이전트 돌리기

Orca를 처음 열면 사이드바에서 워크스페이스(프로젝트)를 고르거나, 가운데 프로젝트 추가로 로컬 git 폴더를 등록한다. 프로젝트 하나 ≈ git 저장소 하나다. 그다음 작업 단위마다 생성 worktree(보통 Ctrl+N)로 이름을 짓고, start-from(대개 origin/main, 다른 로컬·원격 브랜치, 커밋 SHA)을 고른다. 생성은 백그라운드에서 git fetch·git worktree add가 돌고, 사이드바에 진행 표시가 뜬다.

worktree가 열리면 가운데는 그 폴더를 cwd로 둔 터미널, 우측은 Agent 세션 기록인 경우가 많다. 여기서 코드를 짜는 엔진은 Orca 내장 모델이 아니라, 터미널에 띄운 공식 CLI다. Claude Code는 claude, Codex는 codex, Grok CLI는 환경에 따라 agent 또는 grok, Cursor Agent는 Windows에서 경로·별칭으로 agent.cmd, Antigravity는 agy처럼 각 벤더 명령을 친다. 같은 화면에서 Cursor용 패인을 여러 개 두고, 옆에 agy·Grok·NeuralWatt(nw/llm)·중국 OSS CLI를 나란히 두는 구성이 가능하다. 플러스 → 터미널 → CLI 실행 → 패인 드래그가 기본 조작이다. 세션이 쌓이면 우측 기록에 남고, 끝나면 diff 뷰·Annotate AI Diff·커밋·푸시·PR로 이어간다. 끝나면 worktree를 아카이브하거나 삭제한다(삭제 시 디렉터리·브랜치 확인 후 제거).

Detached HEAD로 열린 worktree에서도 파일 수정·에이전트 대화는 된다. 다만 커밋·푸시·PR까지 가려면 git switch -c feature/작업이름으로 브랜치를 붙이거나, 처음부터 start-from을 브랜치로 두는 편이 낫다. Search/Ctrl+J(Mac은 Cmd+J)로 worktree·파일·에이전트·명령에 점프할 수 있다.

한 줄로 정리하면, Orca는 CLI만 있는 도구가 아니다. 에이전트 실행은 CLI이고, 감싸는 껍데지는 에디터·diff·브라우저·사이드바를 갖춘 GUI ADE다. Cursor처럼 에디터 안에 AI가 박힌 형태가 아니라, 외부 CLI 여러 개를 worktree에 배치하는 관제실에 가깝다.

그림 7. agent 이름 충돌을 Get-Command로 확인하고 경로를 나눈다

11. Windows에서 Grok·Cursor·Antigravity CLI 연결

실사용에서 자주 막히는 지점은 명령 이름이 겹치는 것이다. Grok CLI와 Cursor Agent가 둘 다 agent를 쓰려 하면, PATH 우선순위에 따라 Grok만 뜨는 것처럼 보일 수 있다.

11.1. 한눈 비교

11.2. Cursor 설치와 호출

PowerShell에서 공식 설치 예시는 `irm 'https://cursor.com/install?win32=true'; | iex다. 설치 직후 안내가 agent라고 나와도, Grok이 이미 agent.exe를 선점하면 agent --version은 Grok이다. 확인은 Get-Command agent -All | Select-Object CommandType, Name, Source로 한다. Cursor는 보통 …\cursor-agent\agent.ps1·agent.cmd`로 잡힌다.

PowerShell에서 Cursor를 확실히 열려면 호출 연산자 &와 경로 따옴표가 필요하다.

agent.cmd" "hello"처럼 앞 따옴표·&가 빠지면 PowerShell이 문자열을 계속 기다려 >>만 반복된다. 경로는 환경마다 다를 수 있으니 Get-Command 결과를 기준으로 잡는다. 로그인·Workspace Trust는 첫 실행 때 한 번 거친다.

11.3. Antigravity 설치와 PATH

설치 예시는 `irm https://antigravity.google/cli/install.ps1 | iex다. 바이너리는 %LOCALAPPDATA%\agy\bin\agy.exe에 두고 사용자 PATH에 등록하지만, 이미 열린 터미널에는 PATH가 즉시 안 먹을 수 있다. 새 터미널을 열거나, 현재 세션에 $env:PATH += ";$env:LOCALAPPDATA\agy\bin"를 추가한 뒤 agy --version으로 확인한다. version`만 단독 입력하면 명령이 아니다. 첫 실행은 테마 선택·보안 경고·개선용 데이터 수집 동의가 나올 수 있다. 상단 경고는 AI 에이전트 일반 위험 고지이고, 하단 체크는 제품 개선용 상호작용 수집 옵트인이다. 체크를 끄고 진행할 수 있다. 다만 클라우드 모델이면 프롬프트·코드 컨텍스트는 기능 동작상 서버로 갈 수 있다.

11.4. Grok과의 병행

Grok을 계속 쓰면 agent는 Grok, Cursor는 전체 경로·별칭으로 나누는 편이 안전하다. Orca의 강점은 같은 작업을 서로 다른 CLI를 다른 worktree에 두고 비교하는 것이므로, 명령을 헷갈리지 않게 고정해 두는 것이 실전 핵심이다. 소개·실습에서 반복되는 패턴은 한 화면 = 한도 로테이션 보드다. Cursor IDE·Antigravity IDE를 각각 띄워 두지 않아도, Orca 터미널에 공식 CLI만 붙이면 구독 전환이 된다. Antigravity를 agy로 감싸 쓰는 것은 제3자 토큰 프록시와 다르다는 점은 위 공식 CLI 안전성 절과 같다. Orca 앱 UI의 에이전트 프리셋에 각 CLI를 등록해 두면, 터미널에 매번 긴 경로를 치지 않아도 된다. 다만 PATH·설치가 깨져 있으면 프리셋도 실패하므로, 위 표로 쉘에서 먼저 버전 확인하는 습관이 필요하다.

중요한 폴더를 지우거나 새 PC로 옮긴 뒤에는 보통 재설치 → PATH/별칭 복구 → --version → Orca에서 에이전트 경로 재지정 순서로 복구한다. AppData\Local\cursor-agent, .grok\bin, AppData\Local\agy\bin이 빠지면 해당 CLI만 사라지고 Orca 자체는 남을 수 있다.

12. NeuralWatt 같은 API와 CLI 에이전트의 차이

NeuralWatt / portal docs는 Cursor·agy·Grok처럼 전용 코딩 에이전트 CLI를 설치하는 제품이 아니다. OpenAI 호환 엔드포인트 `https://api.neuralwatt.com/v1`에 API 키(sk-...)로 chat/completions를 치는 추론 API다. Orca 입장에서는 “에이전트 프리셋에 기본 내장된 CLI”가 아니라, worktree 터미널 안에서 llm·nw·Python·curl로 붙이는 BYO 모델에 가깝다.

전용 CLI가 없을 때의 실전 패턴은 두 갈래다.

1. 터미널 CLI — Python 패키지 llm + llm-neuralwatt 플러그인 + 짧은 래퍼 nw
2. 봇/에이전트 런타임(예: Hermes) — provider 플러그인 + .env의 NEURALWATTAPIKEY + config.yaml의 API 모델 ID

둘 다 최종 API model 필드는 문서 Model ID와 같다. 예: Kimi K2.7 Code → kimi-k2.7-code.

12.1. 독립 작동 — Hermes 없어도 됨

nw / llm은 Hermes 없이 단독으로 돌아간다. 텔레그램 봇(Hermes)과 터미널 CLI는 같은 NeuralWatt API를 쓸 수 있어도 서로 의존하지 않는다.

• 터미널만: nw / llm → Hermes는 꺼 두어도 된다.
• 봇만: Hermes → llm / nw 없어도 된다.
• 둘 다: 각각 따로 켜서 쓰면 된다.

Hermes는 NeuralWatt를 쓰기 위한 필수 조건이 아니다. Orca worktree 터미널에서도 마찬가지다.

12.2. 모델 이름이 두 가지인 이유 (틀린 게 아님)

NeuralWatt 대시보드·Playground·Python SDK·Hermes config.yaml은 API ID를 쓴다. llm CLI 플러그인은 앞에 neuralwatt-를 붙인 별칭을 쓰고, 요청 직전에 API ID로 바꾼다.

확인 로그 예: 'neuralwatt-kimi-k2.7-code' -> 'kimi-k2.7-code'. 매핑이 맞으면 “모델이 틀렸다”가 아니라 이름 체계가 두 층인 것이다.

가격·스펙(예: input 약 $0.95/M, output 약 $4.00/M, context 262K, INT4, Vision·Tool·JSON·Reasoning)은 모델 페이지 시점에 따라 바뀌니 Models에서 확인한다.

12.3. Python·curl로 바로 치기 (CLI 없이)

문서 패턴은 OpenAI SDK다. baseurl을 NeuralWatt로, apikey에 대시보드 키, model에 API ID만 넣는다.

PowerShell에서 단발 호출은 Invoke-RestMethod로 같은 URL에 JSON body를 보내도 된다. 맥락을 쌓는 채팅이 필요하면 messages 배열을 루프에 유지하는 짧은 Python 스크립트가 편하다.

12.4. 터미널 llm / nw 설정 A→Z (전용 CLI 대체)

아래는 Windows + PowerShell 기준으로, 직접 짠 코드는 사실상 nw 래퍼 하나이고 나머지는 설치·키·PATH·기본 모델 지정이다. 경로는 계정마다 다르니 %USERPROFILE%, %LOCALAPPDATA%로 읽는다.

12.4.1. 전제

• Python 3 + pip/python -m 사용 가능
• NeuralWatt 대시보드에서 API 키 발급
• Orca worktree 터미널이든 일반 PowerShell이든 동일

12.4.2. llm 설치와 PATH

llm 패키지(예: 0.31.x)를 설치하면 보통 %LOCALAPPDATA%\Python\…\Scripts\llm.exe에 생긴다. Scripts가 User PATH에 없으면 llm 명령을 못 찾는다. 설정 → 환경 변수 → Path에 Scripts 폴더를 추가하거나, 현재 세션에만 $env:PATH 앞에 Scripts를 붙인다. 새 터미널을 연 뒤 llm --version으로 확인한다.

12.4.3. NeuralWatt용 llm 플러그인

공식 플러그인 설치 예(시점·URL은 저장소 기준):

`python -m llm install "llm-neuralwatt @ git+https://github.com/neuralwatt/neuralwatt-tools.git#subdirectory=plugins/llm-neuralwatt"`

설치 후 site-packages의 llm_neuralwatt가 neuralwatt-* 별칭 → API ID 매핑을 담당한다. 이 소스는 직접 작성한 코드가 아니다.

12.4.4. API 키 등록

llm keys set neuralwatt 실행 후 키를 붙여 넣는다. Hermes .env와 저장소가 다르다. 확인 시 key set: True 형태면 된다. 키 문자열을 채팅·위키·커밋에 남기지 않는다.

12.4.5. 기본 모델

llm models default neuralwatt-kimi-k2.7-code

llm에서는 반드시 neuralwatt- 접두 별칭을 쓴다. 목록에 neuralwatt-kimi-k2.6, …-fast, …-flex 등이 보이면 같은 규칙이다 Default만 neuralwatt-kimi-k2.7-code로 두면 된다.

12.4.6. 짧은 명령 nw (직접 작성하는 래퍼)

%USERPROFILE%\bin 같은 PATH에 올라간 폴더에 nw.cmd(또는 nw.ps1)를 둔다. 요지는 다음과 같다.

1. Scripts를 PATH 앞에 붙여 llm을 찾게 한다.
2. 인자 없으면 llm chat -m neuralwatt-kimi-k2.7-code
3. 인자 있으면 llm -m neuralwatt-kimi-k2.7-code …

User PATH에 %USERPROFILE%\bin과 Python Scripts를 넣어 두면 새 터미널에서 nw, nw 이 코드 리뷰해줘, llm chat이 된다. Orca worktree 터미널에서도 동일하다. 전용 에이전트 CLI가 없어도 NeuralWatt 모델을 대화형으로 쓸 수 있다.

12.4.7. 흐름도 (터미널)

nw → nw.cmd → llm -m neuralwatt-kimi-k2.7-code → llm-neuralwatt 플러그인 → `POST https://api.neuralwatt.com/v1/chat/completions` (Authorization: Bearer sk-…, model: kimi-k2.7-code).

12.5. Hermes 등 봇 런타임에 붙일 때 (선택·요약)

터미널 nw/llm만 쓸 거면 이 절은 건너뛰어도 된다. 텔레그램 봇처럼 장기 프로세스에 NeuralWatt를 넣을 때만 아래를 맞춘다.

Hermes에는 API ID(kimi-k2.7-code) 를 넣고, llm 별칭(neuralwatt-…)을 넣지 않는다. 예전 다른 벤더 base_url(예: xAI)이 남아 있으면 지운다.

12.6. 파일·환경 체크리스트 (경로 일반화)

12.7. Orca와의 관계

Orca는 NeuralWatt를 내장 구독으로 팔지 않는다. 공식 CLI 에이전트 슬롯과 별도로, 터미널에 nw를 켜 두면 “전용 CLI가 없는 모델”도 worktree 안에서 바로 실험할 수 있다. 이미지·편집으로 Cursor 한 창이 무거울 때, 다른 worktree에서 nw로 문서·리뷰만 빼는 식으로 부하를 나누는 용도에도 맞다. 토큰·전력 과금형 API라 구독 한도와 결이 다르다. 실사용 안내에서 종종 나오는 체감은 대략 1억 토큰 ≈ 수 달러 대이고, 월 수억 토큰을 쓰면 고정 구독보다 싸거나 비쌀 수 있다. 요금은 시점·모델·프롬프트에 따라 바뀌므로 대시보드 단가를 기준으로 하고, Hermes 등 봇 런타임에 같은 키를 물려도 Orca 패인에서 nw만 단독으로 쓸 수 있다.

한 줄: 직접 짜는 코드는 nw 래퍼 정도이고, API 모델명은 문서대로 kimi-k2.7-code, llm에서는 neuralwatt-kimi-k2.7-code 다.

그림 8. 페어링은 신뢰 LAN 또는 Tailscale 주소를 쓰고 vEthernet은 피한다

13. 모바일 컴패니언·네트워크·Tailscale

모바일 앱은 데스크톱 Orca와 페어링하는 컴패니언(원격 조종기)이다. 코드·셸·에이전트는 PC에 남고, 폰은 화면을 보고 짧은 입력을 보낸다. 공식 모바일 문서도 “read-mostly remote control”이라고 못 박는다. 전체 편집 IDE를 폰으로 대체한다는 말이 아니다.

다운로드는 다운로드 페이지 기준이다. iOS는 App Store·TestFlight, Android는 GitHub 릴리스 APK(문서·저장소에 공개된 빌드 번호 기준, 예: 0.0.27)다. 실기 화면(Android)에서는 Host 아래 worktree를 고르고, 세션 탭·팔로업·Live input까지 이어지는 흐름이 보인다.

13.1. 폰에서 할 수 있는 일

공식 docs와 앱 화면을 합치면 역할은 대략 아래다.

요지는 감시 + 짧은 조종이다. 병렬로 돌리 둔 worktree가 여러 개여도, 밥 먹으며 “끝난 놈만 continue” 하거나 막힌 세션에 한 줄만 더 던질 때 맞다.

13.2. 페어링 절차

1. 데스크톱 Orca 계정·상태 메뉴에서 페어링을 연다. 일회용 코드(또는 QR)가 뜬다.
2. 폰 앱에서 Pair를 고르고 코드를 넣는다. 데스크톱 deep link로 페어링 화면을 여는 경로도 있다.
3. 교환은 데스크톱↔폰 직접이다. 클라우드 릴레이로 세션을 대신 들고 있지 않는다.

데스크톱 앱을 끄면 연결이 끊긴다. 다시 열면 폰이 자동으로 붙는 흐름이 문서에 적혀 있다. 같은 Orca 계정으로 맞춰 두는 편이 페어링 실패를 줄인다. 코드는 몇 분 지나면 만료되니 오래 켜 둔 화면이면 새로 발급한다.

13.3. 네트워크·Tailscale

설정에 네트워크 인터페이스 목록이 보이면, QR에 넣을 PC 주소를 고르는 자리이다.

안전은 조건부다. 페어링은 폰에서 PC 에이전트를 조종하는 창구다. 신뢰하는 사설망에서 QR로만 연결하는 편이 낫다. 카페·공용 Wi-Fi에 PC 사설 IP를 드러내는 방식은 피한다. 서로 다른 네트워크면 Tailscale·ZeroTier 주소를 쓰는 쪽이 낫다. 페어링된 장치 목록에 모르는 기기가 있으면 제거한다.

Tailscale Personal은 개인·소수 기기용 무료 플랜이 있다. 홈에서 Orca 모바일·원격만 쓸 때 Standard/Premium이 필수인 경우는 적다. PC·폰에 각각 설치해 같은 계정으로 로그인한 뒤 100.x.x.x를 Orca 네트워크 인터페이스에 지정하는 흐름이 일반적이다.

13.4. 터미널 설정·트러블슈팅

모바일 터미널 설정(Settings → Terminal)에는 글자 크기(대략 50%~200%, 핀치 줌과 연동)·자동완성·자동수정이 있다. 자동완성·자동수정은 기본 꺼짐으로, OS가 명령·플래그·경로를 고쳐 쓰지 않게 한다. Live 키보드 캡처는 생 키 입력을 그대로 보낸다.

상태가 어긋나면 worktree 행을 강제 새로고침한다. 데스크톱은 idle인데 폰만 working으로 남는 경우가 문서에 나온다. 페어링이 안 되면 같은 계정인지, 코드가 만료되지 않았는지부터 본다.

14. 공식 문서에 더 있는 기능 지도

문서·제품 UI에는 이 밖에도 에이전트 패인 드래그, VS Code 쪽 세션을 끌어오는 흐름, Hermes 등 외부 에이전트 관리, SSH worktree, Design Mode의 브라우저 로그인·인증 컨텍스트, 스케줄·자동화(Orca CLI), Computer Use가 이어져 있다. 세부 절차는 공식 docs·릴리스 노트 쪽이 정본이다.

홈페이지 카드만 보면 핵심 기능으로 충분해 보이지만, 문서 목차에는 아래 계층이 더 있다. 매일 배포라 UI 이름은 바뀔 수 있으니 changelog와 함께 본다.

운영사 표기는 사이트 푸터 기준 Lovecast Inc. / Stably·Y Combinator 맥락과 함께 보면 된다. 스타·릴리스 수(예: 1만 7천 스타대, v1.4.13x)는 시점 스냅샷이므로 GitHub와 Releases를 확인한다.

15. 검색으로 자주 묻는 Orca 키워드

Orca ade 사용법을 처음 찾을 때는 대개 설치보다 "무엇을 눌러야 에이전트가 도는지"에서 막힌다. 벤더별 공식 CLI(Claude Code, Codex, Grok CLI 등)를 각자 설치했다면, Orca 쪽에서는 프로젝트 등록 → worktree 생성 → 터미널에서 벤더 CLI 실행이라는 3단계만 기억하면 된다. 오르카 ade라는 한글 표기로 검색해도 같은 앱을 가리키므로, 세부 기능은 항상 onorca.dev 공식 문서를 기준으로 확인한다.

orca 오케스트레이션(Orchestration)은 한 worktree 안에서 CLI에게 서브 작업을 위임하는 것과는 다른 층위다. 오케스트레이션은 여러 worktree·여러 에이전트 실행을 규칙·스케줄로 묶어 순서대로 자동 진행시키는 기능이고, 터미널에 짧은 지시만 추가하는 팔로업(Add a follow-up)은 지금 열린 한 세션에 한 줄을 보태는 것뿐이다. 두 개념을 섞으면 "왜 자동으로 안 돌아가지"라는 혼란이 생기기 쉽다.

orca wsl 조합으로 검색해 들어오는 경우는 대부분 Windows에서 Linux 경로 기반 개발 환경을 WSL 안에 두고, Orca 앱 자체는 Windows에서 실행하며 worktree cwd만 WSL 경로로 잡으려는 상황이다. 이때는 Orca 설정의 터미널 셸을 WSL bash로 지정하고, 프로젝트 경로도 WSL 내부 절대경로 형태로 등록해야 사이드바 worktree가 정상 인식된다. Windows 네이티브 경로와 WSL 경로를 섞으면 git worktree add가 실패하기 쉽다.

orca ide라는 표현에는 오해가 섞여 있다. Orca는 자체 AI 모델을 파는 IDE가 아니라, Claude Code·Codex·Grok CLI 같은 공식 CLI를 감싸는 껍데기다. 에디터·diff·터미널 분할은 IDE처럼 보이지만, 실제 코드 생성은 각 CLI 프로세스가 담당한다. 원격에서 여러 대를 안전하게 잇는 네트워크 설정은 테일스케일 메시 VPN 정리를 참고하면, 사설 IP를 그대로 드러내지 않고도 Orca 모바일 페어링까지 확장할 수 있다. 이 문서를 다시 찾아올 때는 정본 주소인 min-inter.co.kr/wiki/orca-ade-parallel-agents를 기준으로 삼는다.

16. 마무리

앞에서 다룬 Orca ADE의 핵심만 짧게 정리한다.

• Orca는 모델이 아니라 공식 CLI들을 git worktree로 격리·병렬 실행하는 로컬 ADE다.
• 서브 에이전트 ≠ 병렬 패인 — 한 CLI 안의 위임과, Orca에 띄운 CLI 군단(플릿)을 구분한다.
• 한 화면·공식 CLI로 구독 한도를 로테이션하고, 잘된 worktree만 선택 머지한다.
• 차별점은 fan-out·diff 리뷰·Design Mode·GitHub/Linear·SSH·모바일·Orchestration을 한 앱에 묶은 점이다.
• 공식 CLI 래핑은 자격증명·중간 가로채기 측면에서 자체 프록시보다 신뢰하기 쉽지만, 약관과 에이전트 실행 위험은 별개다.
• 일반은 1트리·1에이전트·좁은 범위·필수 리뷰, 전문가는 역할 분담 fan-out·원격·오케스트레이션·스펙 선행이 잘 맞는다.
• 장점은 병렬·락인 낮음·오픈소스, 단점은 매일 배포형 회귀·디스크·한도 N배·학습 곡선이다.
• 모바일은 컴패니언이다. worktree 감시·팔로업·Live input·Source Control·알림이 핵심이고, 코드 실행은 데스크톱에 남는다.
• 세부 기능·지원 목록은 변하니 onorca.dev/docs와 GitHub Releases를 기준으로 확인한다.

「병렬 에이전트는 worktree로 가두고, 머지는 사람이 한다」 — Orca는 그 루프를 빠르게 돌리게 돕는 환경이지, 리뷰를 대신해 주지 않는다. CLI만 익히면 새 IDE GUI를 매번 배우지 않아도 구독을 갈아탈 수 있다. 벤더 약관과 로컬 실행 권한은 쓰는 사람이 직접 관리해야 한다.

자주 묻는 질문

• Orca가 Cursor·Codex보다 빠르게 느껴지는 이유는 뭔가요?

  모델 API 자체를 가속하는 제품 아닙니다. 이미지·연속 편집을 한 IDE 세션에 몰아넣으면 메모리·CPU가 한 프로세스에 몰리고, 그 창이 버거워지면 PC 전체가 느려집니다. Orca는 작업마다 git worktree와 별도 CLI 프로세스로 나눠 두어, 한쪽이 무거워도 다른 worktree에서 일을 이어 가기 쉽습니다. 체감 속도는 ‘오케스트레이션·격리’에서 오는 경우가 많습니다.

• Orca는 Cursor나 Windsurf를 대체하나요?

  직접 대체 제품 아닙니다. Cursor·Windsurf는 자사 에이전트에 깊게 통합된 단일 IDE에 가깝고, Orca는 Claude Code·Codex·Cursor CLI 등 여러 공식 CLI를 git worktree로 병렬 돌리는 ADE(오케스트레이션 환경)입니다. 에이전트 하나에 만족하면 기존 IDE를, 둘 이상·리뷰·모바일이 필요하면 Orca를 고르는 편이 맞습니다.

• Orca 자체 요금이 있나요?

  데스크톱·모바일 앱은 무료이며 소스는 MIT 라이선스 오픈소스입니다. 비용은 연결해서 쓰는 Claude Code·Codex·Antigravity 등 각 벤더 구독·사용량입니다. Orca가 모델 과금을 중간에 얹는 구조가 아닙니다.

• 공식 CLI를 Orca에서 쓰면 자격증명이 안전한가요?

  Orca는 자체 인증을 만들지 않고 벤더 공식 CLI를 터미널에서 실행합니다. 토큰은 각 CLI 홈 디렉터리에 남고, 사용량 표시도 로컬 상태 파일을 읽는 방식입니다. 텔레메트리는 프롬프트·파일·터미널 내용을 보내지 않는다고 문서에 명시돼 있습니다. 다만 약관 해석과 에이전트 실행 위험은 별개이므로 최신 ToS와 diff 리뷰는 필요합니다.

• Antigravity나 Claude 구독을 제3자 프록시로 우회하는 것과 같은가요?

  다릅니다. OAuth·토큰을 가로채 다른 하네스에 꽂는 비공식 프록시는 벤더가 약관 위반·계정 제재로 경고한 유형입니다. Orca는 공식 CLI 바이너리를 감싸 실행하는 쪽에 가깝습니다. 둘을 같은 ‘제3자 프로그램’으로 묶으면 위험 판단이 왜곡됩니다.

• 병렬로 돌리면 구독 한도가 얼마나 빨리 닳나요?

  대략 에이전트 수에 비례합니다. Claude Code를 세 워크트리에서 동시에 돌리면 토큰·rate limit도 대략 세 배로 소모됩니다. Orca 상태바의 사용량·리셋 시각을 보고, 저가·빠른 모델로 후보를 뽑은 뒤 비싼 모델로 머지하는 식으로 조절하는 사용자가 많습니다.

• git worktree를 모르면 Orca를 쓰기 어렵나요?

  공식 문서도 노코드 도구가 아니라고 밝힙니다. worktree·diff·커밋에 익숙하지 않으면 복잡도만 늘어납니다. 다만 처음에는 워크트리 하나와 에이전트 하나로 좁은 작업만 반복해도, 브랜치 갈아타고 stash하던 방식보다 정리가 쉬워지는 경우가 많습니다.

• 모바일 앱만으로도 코딩할 수 있나요?

  모바일은 데스크톱과 페어링하는 컴패니언입니다. worktree 상태·터미널 스크롤백·팔로업·Live input·Source Control·계정 전환·푸시 알림이 중심이고, 코드·에이전트 실행은 PC에 남습니다. 노트북을 끄면 폰 세션도 사실상 멈춥니다. 전체 편집 IDE를 폰으로 대체하지는 않습니다.

• SSH 워크트리는 아무 서버나 붙이면 되나요?

  Settings → SSH에 호스트를 등록한 뒤 worktree 생성 시 원격 타깃을 고릅니다. git이 원격에 있어야 하고, 연결 재사용·점프 호스트·포트 포워딩 옵션이 있습니다. 기업망처럼 SSH 정책이 까다로운 환경에서는 릴레이·Node 툴체인 이슈를 문서로 확인한 뒤 단계적으로 도입하는 편이 안전합니다.

• Design Mode는 어떤 웹앱에 쓰나요?

  내장 Chromium에 렌더된 페이지의 실제 DOM을 찍습니다. React·Vue 등 SPA도 렌더된 요소 기준으로 HTML·계산 CSS·크롭 스크린샷이 에이전트 첨부로 들어갑니다. 로컬 HTTPS·자체 서명 인증서 환경에서는 브라우저 이슈가 보고된 적 있으니, 해당 스택이면 이슈 트래커를 함께 확인하세요.

• 매일 배포한다는데 팀에서 쓰기 불안하지 않나요?

  기능 반영은 빠르지만 회귀 버그도 이슈 트래커에 자주 올라옵니다. 활성 세션이 예기치 않게 끊긴 보고도 있습니다. 팀은 버전을 고정하거나, 활성 워크트리 수를 제한하고, 중요 변경은 자주 커밋·푸시하는 방어를 권장합니다. 세부 버그보다 ‘빠른 배포형 제품’이라는 성격으로 이해하는 것이 맞습니다.

• Orchestration과 그냥 터미널에 프롬프트 보내는 차이는 무엇인가요?

  orca terminal send는 보고 있는 에이전트에 한 번 지시할 때 씁니다. Orchestration은 task·dispatch·worker_done·decision gate·공유 inbox로 여러 워커의 소유권과 완료 상태를 추적합니다. 작업을 쪼개 병렬로 돌리고 코디네이터가 결과를 모을 때 orchestration run·dispatch --inject 쪽이 맞습니다.

• 코드나 프롬프트가 Stably 서버로 올라가나요?

  데스크톱 앱은 로컬에서 돌고, 에이전트 통신은 각 공식 CLI와 벤더 사이입니다. 제품 텔레메트리는 익명 사용 이벤트만 보내며 파일·프롬프트·터미널 내용은 보내지 않는다고 문서에 적혀 있습니다. 모바일 원격 네트워크 릴레이는 옵트인 성격의 설명도 리뷰에 나오므로, 팀 정책에 맞게 Privacy·페어링 설정을 확인하세요.

• Orca는 CLI만 쓰는 도구인가요, IDE인가요?

  둘을 섞은 ADE에 가깝습니다. 코드를 짜는 엔진은 Claude Code·Cursor Agent·agy 같은 외부 CLI이고, Orca 자체는 worktree 사이드바·터미널 분할·에디터·diff·브라우저·모바일 페어링을 제공하는 GUI입니다. 내장 모델 판매가 아니라 CLI 오케스트레이션 환경으로 이해하면 됩니다.

• Windows에서 agent를 쳤더니 Grok만 나옵니다. Cursor는 어떻게 여나요?

  Grok이 C:/Users/<유저>/.grok/bin/agent.exe를, Cursor가 AppData/Local/cursor-agent/agent.cmd를 쓰는 식으로 이름이 겹칠 수 있습니다. Get-Command agent -All로 Source를 확인한 뒤, Cursor는 & "$env:LOCALAPPDATA\cursor-agent\agent.cmd" 형태로 호출하거나 Set-Alias로 짧은 이름을 만드세요. agent만 치면 PATH상 Grok이 먼저 잡히는 경우가 많습니다.

• Antigravity agy가 방금 설치했는데 명령을 못 찾습니다.

  설치 스크립트가 사용자 PATH에는 등록해도, 이미 열린 터미널에는 반영되지 않을 수 있습니다. 새 터미널을 열거나 $env:PATH에 %LOCALAPPDATA%\agy\bin을 추가한 뒤 agy --version을 확인하세요. version만 단독 입력하면 안 됩니다.

• NeuralWatt도 Orca에 CLI처럼 붙이나요?

  보통은 아닙니다. NeuralWatt 문서는 OpenAI 호환 API 엔드포인트와 키 사용법을 설명합니다. 전용 코딩 에이전트 CLI 설치와는 다릅니다. 터미널 채팅이 필요하면 HTTP 호출이나 OpenAI SDK 스크립트를 쓰고, Orca 에이전트 슬롯에는 터미널에서 도는 CLI를 연결합니다.

• 모바일 페어링에서 172.x vEthernet 주소를 골라도 되나요?

  대개 안 됩니다. Hyper-V·WSL용 vEthernet은 PC 내부 가상망이라 스마트폰이 닿지 못하는 경우가 많습니다. 같은 공유기의 192.168.x.x 같은 실제 LAN 주소를 고르거나, 원격이면 Tailscale 등 가상 사설망 주소를 쓰는 편이 맞습니다.

• Tailscale은 유료여야 Orca 모바일에 쓰나요?

  개인·소수 기기 연결이면 Tailscale Personal 무료 플랜으로 충분한 경우가 많습니다. 팀 SCIM·규정 로그 등이 필요하면 Standard/Premium을 검토합니다. Orca는 Tailscale을 내장 과금하지 않고, 네트워크 주소만 페어링에 쓰는 형태입니다.

• worktree가 Detached HEAD인데 에이전트를 돌려도 되나요?

  대화·파일 수정은 가능합니다. 다만 커밋·푸시·PR 흐름을 쓰려면 git switch -c로 브랜치를 만들거나, worktree 생성 때 start-from을 브랜치로 지정하는 편이 안전합니다. Detached 상태는 ‘커밋에 묶인 브랜치가 없다’는 뜻입니다.

• 중요 폴더를 지운 뒤 CLI만 다시 연결하려면?

  Orca 앱과 CLI 설치 경로는 별개인 경우가 많습니다. cursor-agent·.grok\bin·agy\bin을 다시 설치하거나 PATH를 복구한 뒤 --version으로 확인하고, Orca 에이전트 설정에 실행 파일 경로를 다시 지정합니다. 별칭(Set-Alias)은 터미널 세션·프로필에도 다시 넣어야 합니다.

• NeuralWatt에서 모델이 틀렸다고 나오는데 kimi-k2.7-code가 맞나요?

  대부분 이름 체계 혼동입니다. API·Python·Hermes는 kimi-k2.7-code를 쓰고, llm/nw는 neuralwatt-kimi-k2.7-code 별칭을 씁니다. 플러그인이 API로 보낼 때 접두사를 제거합니다. llm에서 kimi-k2.7-code만 치면 모델을 못 찾을 수 있고, Hermes에 neuralwatt- 접두를 넣으면 반대로 어긋납니다.

• 전용 CLI가 없을 때 Orca에서 NeuralWatt를 쓰려면?

  Orca worktree 터미널에서 llm 또는 nw를 실행하면 됩니다. llm-neuralwatt 플러그인 설치, llm keys set neuralwatt, 기본 모델을 neuralwatt-kimi-k2.7-code로 두고, PATH에 Python Scripts와 nw 래퍼 폴더를 넣습니다. Python만 쓸 거면 base_url과 model=kimi-k2.7-code로 OpenAI SDK를 호출합니다.

• nw와 llm의 차이는 뭔가요?

  llm이 본체이고, nw는 llm chat/호출을 neuralwatt 기본 모델로 감싼 짧은 래퍼입니다. 직접 작성하는 코드는 보통 nw.cmd(또는 동등 스크립트) 하나이며, 매핑·API 통신은 llm-neuralwatt 플러그인과 NeuralWatt 서버가 담당합니다.

• Hermes와 터미널 llm에 같은 키·모델명을 쓰면 되나요?

  키는 같아도 저장 위치가 다릅니다. Hermes는 .env의 NEURALWATTAPIKEY, llm은 llm keys set neuralwatt입니다. 모델 문자열도 다릅니다. Hermes·Python은 kimi-k2.7-code, llm/nw는 neuralwatt-kimi-k2.7-code입니다.

• NeuralWatt용 nw/llm을 쓰려면 Hermes가 필요한가요?

  필요 없습니다. nw와 llm은 Python·플러그인·API 키만으로 터미널에서 독립 동작합니다. Hermes는 텔레그램 봇 등 별도 런타임이고, 같은 NeuralWatt API를 쓰더라도 서로 의존하지 않습니다. 터미널만 쓸 거면 Hermes를 꺼 두어도 됩니다.

• 왜 CLI 에이전트가 Cursor 같은 IDE보다 빠르게 느껴지나요?

  모델 속도 마법이 아니라 껍데기 무게 차이인 경우가 많습니다. IDE는 에디터·확장·LSP·미리보기·파일 감시가 상시로 붙고, 이미지·연속 편집을 한 창에 몰면 메모리·CPU가 한 프로세스에 쌓입니다. CLI는 터미널 요청/응답 중심이라 상대적으로 가볍고, Orca처럼 worktree로 나누면 한쪽이 무거워도 다른 일을 이어 가기 쉽습니다.

• 서브 에이전트와 Orca의 병렬 에이전트는 다른가요?

  다르다. 서브 에이전트는 Cursor·Claude·Codex 같은 한 CLI 세션 안에서 메인이 일을 쪼개는 구조다. Orca의 병렬은 패인·프로세스마다 공식 CLI(및 그 안의 서브 에이전트)를 두고, 보통 git worktree로 파일까지 격리한 플릿이다. 한 제품을 깊게 쓰는 것과, 여러 구독을 한 화면에서 돌리는 것을 혼동하지 않는 편이 낫다.

• Cursor 에이전트 윈도우만으로도 충분하지 않나요?

  가벼운 병렬·채팅 여러 개는 IDE 쪽 창으로도 된다. 다만 창·탭이 늘수록 Electron 계열 IDE 메모리가 크게 불어나고, Antigravity·Grok·API형 CLI까지 한곳에 두려면 Orca처럼 터미널 패인·worktree 관제실이 유리하다. Cursor GUI를 닫아 두고 agent.cmd만 Orca에서 돌리는 구성도 가능하다.

• 구독 한도가 끝나면 어떻게 전환하나요?

  Orca에서는 보통 다른 패인에서 다른 공식 CLI를 연다. Antigravity(agy) 한도가 끝나면 Cursor(agent.cmd), 그다음 Codex·Claude·Grok·NeuralWatt(nw) 순처럼 로테이션한다. 제품을 새로 설치·UI를 다시 익히기보다 CLI 호출만 바꾸면 된다. 다만 병렬 수는 한도·요금을 N배로 쓰므로 무한정 늘리지 않는다.

• 패인을 많이 띄워도 PC가 안 느려지나요?

  한 IDE에 작업을 몰아넣는 것보다는 덜 뭉치는 경우가 많다. 그래도 패인·worktree·모델 세션이 늘면 CPU·RAM은 올라간다. 병렬을 키울 계획이면 코어·스레드가 많은 CPU가 유리하고, 영상·로컬 생성은 GPU를 따로 보는 편이 맞다. 활성 패인 수를 제한하는 것이 실무 방어다.

• Orca 모바일에서 Source Control이나 Live input은 뭔가요?

  Source Control은 폰에서 해당 worktree의 변경 파일을 보고 stage·unstage·커밋까지 하는 짧은 후속용 화면입니다. Live input은 글자를 칠 때마다 활성 터미널로 보내는 모드이고, 일반 Add a follow-up(한 번에 짧은 답)과 다릅니다. Tab·Esc·Paste 같은 액세서리 키도 폰 키보드를 보완합니다. 전체 IDE 편집을 대신하진 않습니다.

• 모바일 페어링에 클라우드가 끼나요? 데스크톱을 끄면요?

  공식 문서는 데스크톱이 정본이고, 페어링 교환은 데스크톱↔폰 직접이며 클라우드 릴레이로 세션을 대신 두지 않는다고 적습니다. 데스크톱 앱을 닫으면 연결이 끊기고, 다시 열면 폰이 붙는 흐름입니다. 같은 Wi-Fi·올바른 LAN/VPN 주소·같은 Orca 계정이 전제입니다.

• Orca GitHub 스타와 기여자 규모는 어느 정도인가요?

  2026-07-14 기준 stablyai/orca API에서 스타는 약 1.84만(18395), 포크는 약 1.4천, 기여자는 GitHub 메타상 약 200명대로 집계됐다. 릴리스도 수백 회대라 버그픽스·업데이트가 잦은 편이다. 수치는 매일 변하므로 github.com/stablyai/orca에서 다시 확인하는 것이 좋다.

• Orca가 공식적으로 지원하는 CLI 에이전트는 어떤 것들인가요?

  공식 문구는 터미널에서 도는 CLI면 Orca에서도 돈다는 것이다. README·사이트 칩에는 Claude Code, Codex, Grok, Cursor, GitHub Copilot, OpenCode, Antigravity, Pi, Hermes Agent, Cline, Continue, Qwen Code 등 약 30개 가까운 이름과 + any CLI agent가 보인다. 목록에 없어도 PATH에 실행 파일만 있으면 연결할 수 있는 구조다.

• orca 사용법을 처음 배우려면 어디서 시작하나요?

  공식 문서 onorca.dev/docs의 Install과 Your first 3-agent session부터 따라 하는 편이 빠릅니다. Orca 자체는 프로젝트 등록 → worktree 생성 → 터미널에서 Claude Code·Codex 같은 공식 CLI 실행이라는 순서만 익히면 됩니다. 처음부터 오케스트레이션·다중 worktree로 벌리지 말고, 1트리·1에이전트로 diff 리뷰까지 한 번 끝내본 뒤 병렬로 넓히는 편이 안전합니다.

• orca 오케스트레이션 뜻이 정확히 뭔가요?

  터미널에 한 줄 지시를 보내는 팔로업과 달리, Orca의 Orchestration은 여러 worktree·여러 에이전트 실행을 규칙·스케줄로 자동 배치하는 상위 기능입니다. 새 worktree 생성, 각 CLI 실행, 완료 후 후속 처리를 이어 붙이는 자동화 파이프라인에 가깝고, 단일 세션 대화 위임(서브 에이전트)과는 층위가 다릅니다.