요즘 핫한 Orca IDE 사용법, Claude Code·Codex 3개를 동시에 돌려도 보자

 

원래 오늘 TTS 3편을 쓰고 마무리 하려했지만, 과정에서 테스트하게 된 Orca IDE에 대한 글을 안 쓸수가 없었다.

---

 

터미널을 세 개 열어 Claude Code와 Codex를 동시에 돌려보자. 한쪽에서는 로그인 버그를 잡고, 다른 쪽에서는 테스트를 만들고, 나머지 창에서는 리팩터링을 시킨다. 그런데 10분쯤 지나면 어느 변경을 누가 만들었는지 헷갈리고, 두 에이전트가 같은 파일을 건드리기 시작한다.

Orca를 켜야 하는 순간이 딱 이때다.

이름에는 IDE가 붙었지만, 평소 쓰던 코드 편집기를 떠올리면 조금 어긋난다. 제작사에서는 ADE(Agent Development Environment)라고 부른다. Claude Code·Codex·Gemini·Cursor CLI·OpenCode 같은 코딩 에이전트를 여러 개 띄워놓고 작업별로 챙기는 공간이라는 뜻이다. 별도의 AI 모델을 새로 결제하는 방식도 아니다. 이미 쓰던 에이전트와 구독을 그대로 가져온다.

설치와 저장소 추가부터 독립된 Git worktree에서 에이전트를 실행하고 PR을 만드는 흐름까지 따라가 보자. `저장소 추가 → worktree 생성 → 에이전트 실행 → diff 검토 → 반영`이라는 한 바퀴만 먼저 익히면 된다.

Orca가 해결하는 건 AI 성능이 아니라 작업 충돌이다

Cursor나 VS Code에도 AI 기능이 있는데 굳이 하나를 더 설치해야 할까. 둘의 역할은 다르다. Cursor에서는 편집기 안에서 AI와 코드를 함께 쓴다. Orca에서는 여러 에이전트의 진행 상황을 보고, 결과를 비교해 어느 변경을 가져올지 고른다. 비슷해 보여도 작업 방식은 꽤 다르다.

그 기반이 `git worktree`다. Git 저장소 하나에서 브랜치를 여러 개 만들 수 있다는 건 익숙하지만, 보통은 한 폴더에서 브랜치를 바꿔가며 작업한다. worktree를 쓰면 같은 저장소의 서로 다른 브랜치를 별도 폴더에 동시에 꺼내 둘 수 있다.

예를 들어 이런 식이다.

my-app/
├── main                 # 기준 브랜치
├── fix-login-race       # Claude Code가 작업
├── add-auth-tests       # Codex가 작업
└── refactor-session     # Gemini가 작업

폴더마다 브랜치와 파일, 터미널이 따로 생긴다. Claude Code가 `auth.ts`를 수정하는 동안 Codex가 다른 폴더의 `auth.ts`를 고쳐도 당장 서로 덮어쓰지 않는다. 결과가 별로면 그 작업 폴더를 버리고, 괜찮으면 commit해서 PR로 올린다. 공식 문서에서 말하는 “worktree-native”가 이런 뜻이다.

한 가지는 미리 선을 그어야 한다. 작업 폴더가 나뉜다고 에이전트의 모든 행동까지 안전해지는 건 아니다. 코드가 뒤섞이지 않는 것과 위험한 명령을 막는 건 별개의 문제다.

설치 전에 준비할 것

데스크톱 앱은 macOS, Windows, Linux용이 있다. 설치하기 전에 Git부터 확인하자. Codex를 쓸 거라면 Codex CLI 설치와 로그인까지, Claude Code를 쓸 거라면 Claude Code 인증까지 끝내놓는 편이 덜 막힌다.

여기서 자주 오해한다. Orca 비용만 내면 Claude나 Codex까지 따라오는 구조가 아니다. 컴퓨터에 이미 설치된 CLI와 로그인 정보를 불러와 실행한다. 목록에 에이전트가 안 뜬다면 앱을 다시 설치하기 전에 CLI 설치, 로그인, `PATH`부터 보는 게 빠르다.

공식 사이트에서 macOS용 DMG, Windows용 설치 파일, Linux용 AppImage 또는 `.deb`를 받을 수 있다.

macOS에서 Homebrew를 쓴다면 한 줄이면 끝난다.

brew install --cask stablyai/orca/orca

업데이트는 다음 명령으로 받는다.

brew upgrade --cask orca

처음 실행하면 로컬 저장소를 추가하기 위해 홈 디렉터리 접근 권한을 요청한다. 기존 `~/.claude`, `~/.codex`, Ghostty 설정을 가져오겠다는 화면도 나타날 수 있으니 내용을 읽고 선택한다.

시작 전에 권한 모드부터 확인한다

여기서는 설정 하나를 반드시 확인해야 한다. 에이전트를 빠르게 돌리려고 권한 확인을 건너뛰는 옵션이 기본으로 붙을 수 있다. Claude Code에는 `--dangerously-skip-permissions`, Codex에는 `--dangerously-bypass-approvals-and-sandbox`, Gemini 계열에는 `--yolo` 같은 식이다. 작업 폴더를 언제든 버릴 수 있으니 그 안에서는 자유롭게 움직이게 하겠다는 발상이다.

토이 프로젝트에서는 편하다. 회사 저장소나 자격 증명이 있는 컴퓨터라면 얘기가 달라진다. Git worktree는 다른 브랜치와 파일을 나눠줄 뿐, 셸 명령까지 가두는 보안 장치는 아니다.

처음 쓰는 동안에는 `Settings → Agents → Agent Permissions`에서 **Manual**을 선택하는 쪽을 권한다. 작업 흐름이 익숙해지고, 저장소의 스크립트와 에이전트 행동 범위를 이해한 다음 프로젝트별로 자율성 수준을 조절해도 늦지 않다. 이미 특정 에이전트의 실행 인수를 직접 바꿨다면 전역 설정이 적용되지 않을 수 있으니 해당 에이전트 행도 펼쳐 확인한다.

첫 저장소와 worktree 만들기

처음 켜면 비어 있는 화면이 나온다. 여기서 기존 로컬 Git 저장소를 하나 고른다. 일반 폴더도 열리지만, 첫 연습은 Git 저장소로 하는 편이 낫다. 그래야 worktree를 만들고 diff를 비교하는 흐름까지 한 번에 볼 수 있다.

저장소가 사이드바에 나타나면 이름 옆의 `+` 버튼을 누른다. 여기서 만드는 작업 공간 하나가 사실상 하나의 Git worktree다.

작업 이름은 결과가 아니라 할 일을 적는다.

fix-login-race
add-password-reset-tests
reduce-dashboard-lcp

 

로그인 요청이 동시에 두 번 들어올 때 세션이 중복 생성되는 원인을 찾아줘.
먼저 재현 테스트를 추가하고, 테스트가 실제로 실패하는지 확인한 뒤 수정해.
기존 공개 API는 바꾸지 말고 마지막에 변경 파일과 실행한 테스트를 알려줘.

`test-1`, `new-work` 같은 이름은 에이전트가 서너 개 돌기 시작하면 바로 헷갈린다. 입력한 작업 이름이 기본 브랜치 이름으로 들어간다. `feature/login-race`처럼 따로 정하고 싶다면 Advanced 영역을 펼치면 된다.

이어서 `Start from` 기준을 고른다. 특별한 이유가 없다면 `origin/main` 또는 팀의 기본 개발 브랜치를 선택한다. 생성 버튼을 누르면 Orca가 백그라운드에서 fetch와 `git worktree add`를 실행한다.

새 작업 공간의 터미널이 열리면 에이전트 선택 목록에서 Codex나 Claude Code를 고른다. Orca가 해당 worktree를 현재 작업 디렉터리로 삼아 CLI를 실행한다. 인증 오류가 난다면 같은 터미널에서 에이전트 명령을 직접 실행해본다. 여기서도 실패하면 Orca 문제가 아니라 CLI 설치나 로그인 문제일 가능성이 크다.

첫 프롬프트는 범위를 작게 잡는 편이 좋다.

로그인 요청이 동시에 두 번 들어올 때 세션이 중복 생성되는 원인을 찾아줘.
먼저 재현 테스트를 추가하고, 테스트가 실제로 실패하는지 확인한 뒤 수정해.
기존 공개 API는 바꾸지 말고 마지막에 변경 파일과 실행한 테스트를 알려줘.

“로그인 고쳐줘”보다 재현 조건, 작업 순서, 바꾸면 안 되는 것, 완료 보고 형식을 함께 주면 결과를 비교하기 쉽다. Orca가 프롬프트를 더 똑똑하게 만드는 건 아니다. 대신 같은 지시를 서로 격리된 환경에서 반복 실행하고 결과를 나란히 검토하기 좋게 만든다.

같은 문제를 세 에이전트에게 시켜보면 차이가 보인다

Orca다운 사용법은 작업을 여러 접근으로 나누는 것이다. 같은 저장소에서 worktree를 세 개 만든다고 해보자.

- `login-race-claude`: Claude Code에 원인 분석부터 수정까지 요청
- `login-race-codex`: Codex에 같은 프롬프트 전달
- `login-race-test`: 별도 에이전트에 구현 없이 재현 테스트와 반례만 요청

앞의 두 개는 같은 문제를 두고 경쟁하고, 테스트 전용 작업은 독립적인 검증자 역할을 맡는다. 모든 에이전트에 똑같이 “고쳐줘”라고 하는 것보다 결과를 평가하기 쉽다.

탭을 화면 오른쪽이나 아래쪽 끝으로 끌면 창이 나뉜다. 터미널 옆의 작은 점도 은근히 유용하다. 초록색이면 아직 일하는 중이고, 노란색이면 내 답을 기다리는 중, 회색이면 쉬고 있다는 뜻이다. 점이 안 보일 때는 에이전트 명령을 터미널에 직접 쳤는지 확인해본다. 선택 메뉴로 실행해야 상태를 제대로 잡는 경우가 있다.

완료 알림과 질문은 사이드바의 Agents 피드에 모인다. 노란색부터 눌러 답하고, 초록색은 그냥 두면 된다. 터미널을 하나씩 열어 확인하던 시간이 여기서 꽤 줄어든다.

병렬 실행 개수를 무작정 늘리고 싶어지지만 브라우저 탭과 파일 감시자가 worktree마다 붙어 메모리 사용량도 늘어난다. 처음에는 두세 개로 시작하는 게 현실적이다.

생성된 코드는 대화가 아니라 diff로 판단한다

AI 코딩 도구를 쓰다 보면 설명이 그럴듯해서 코드도 맞을 거라고 착각하기 쉽다. Orca에서는 터미널의 마지막 답변보다 각 worktree의 diff 화면을 먼저 본다.

검토 순서는 단순하다.

1. 변경 파일 수가 요청 범위를 벗어나지 않았는지 본다.
2. 핵심 로직의 diff를 읽는다.
3. 새 테스트가 원래 버그를 실제로 재현하는지 확인한다.
4. lint, typecheck, test 결과를 직접 다시 실행한다.
5. 설정 파일, 잠금 파일, 비밀값이 의도치 않게 바뀌지 않았는지 확인한다.

마음에 가까운 결과가 있는데 한두 군데 아쉽다면 diff 줄에 메모를 달아 에이전트에게 다시 보낼 수 있다. “전체를 다시 해줘”보다 `이 분기는 refresh token이 없는 기존 사용자도 통과해야 한다`처럼 줄 단위 맥락을 주는 편이 수정 범위를 안정적으로 묶는다.

쓸 결과를 골랐다면 Source Control 화면으로 간다. 파일 전체를 올려도 되고, 필요한 변경 묶음만 stage해도 된다. pre-commit hook에서 막히면 실패 로그도 바로 보인다. branch를 push한 뒤 GitHub를 연결해뒀다면 PR까지 앱 안에서 만들 수 있다. commit 메시지와 PR 설명을 자동으로 써주는 버튼도 있지만, 제출하기 전에 내용을 확인하자.

탈락한 작업 폴더는 지우면 된다. 폴더와 브랜치가 함께 사라질 수 있으니 필요한 commit은 먼저 push하고 확인창을 읽는다. 삭제 버튼이 편해서 오히려 여기서 한 번 멈추게 된다.

직접 써보며 자주 막히는 지점

에이전트 선택 목록에 Codex나 Claude Code가 보이지 않으면 `Settings → Agents`에서 감지 상태와 실행 파일 경로를 확인한다. Orca 터미널에서 해당 CLI 명령을 직접 실행하는 테스트가 가장 빠르다. 인증 화면이 나오거나 명령을 찾지 못한다면 먼저 CLI 쪽을 고친다.

worktree 생성이 실패한다면 기준 브랜치를 아직 fetch하지 않았거나, 같은 브랜치가 이미 다른 worktree에 연결돼 있을 수 있다. 저장소 터미널에서 원격 정보를 갱신하고 새 브랜치 이름으로 다시 시도한다.

앱을 다시 켜면 작업 폴더와 탭, 화면 분할, 터미널 기록이 돌아온다. 그런데 창을 닫았다고 실행 중인 에이전트까지 멈추는 건 아니다. 백그라운드에서 계속 돌 수 있으니, 정말 멈출 때는 해당 터미널의 프로세스를 종료해야 한다.

Orca를 계속 쓰게 되는 기준

Orca가 모든 사람에게 필요한 건 아니다. 한 저장소에서 한 에이전트와 대화하며 작은 수정을 처리한다면 익숙한 터미널이나 Cursor가 더 단순하다. Git 브랜치와 diff가 아직 낯설다면 worktree가 하나 더 늘어나는 것 자체가 부담일 수도 있다.

반대로 아래 장면이 자주 나온다면 잘 맞는다.

- Claude Code와 Codex를 같은 프로젝트에서 번갈아 쓴다.
- 기능 개발, 테스트 작성, 코드 리뷰를 병렬로 맡기고 싶다.
- 에이전트마다 브랜치와 파일을 분리하고 결과만 비교하고 싶다.
- 터미널 여러 개에서 “어느 창이 무슨 작업이었지?”를 반복한다.
- 결과를 대화 내용이 아니라 diff와 테스트, PR 단위로 관리하고 싶다.

처음부터 에이전트 함대를 만들 필요는 없다. 저장소 하나를 추가하고, 작은 버그 하나에 worktree 두 개를 만든 다음, Claude Code와 Codex에 같은 프롬프트를 보내보자. 두 diff를 비교하고 하나만 남겨 PR을 올리는 데 성공했다면 Orca의 사용법은 이미 대부분 익힌 셈이다.

Orca를 쓴다고 판단할 일이 줄어들지는 않는다. 오히려 검토할 결과가 더 빨리, 더 많이 쌓인다. 에이전트를 세 개 돌려도 마지막에는 사람이 diff를 읽고 테스트를 확인해야 한다. Orca는 그 판단을 대신하는 도구가 아니라, 판단하기 전까지의 작업을 병렬로 돌리는 도구다.

참고 자료

- [Orca 공식 사이트](https://www.onorca.dev/)
- [Orca 설치 문서](https://www.onorca.dev/docs/install)
- [첫 3-agent 세션](https://www.onorca.dev/docs/first-session)
- [Worktree 동작 방식](https://www.onorca.dev/docs/model/worktrees)
- [지원 에이전트와 권한 기본값](https://www.onorca.dev/docs/agents/supported)
- [Commit과 push](https://www.onorca.dev/docs/review/commit-push)
- [문제 해결과 FAQ](https://www.onorca.dev/docs/troubleshooting)