DataNexus를 개발하면서 Claude Code와 Codex를 함께 사용하고 있습니다. Claude Code가 라우터 로직을 수정하는 동안 별도 터미널에서는 Codex로 빠진 테스트를 보완합니다.

처음에는 두 에이전트가 같은 작업 디렉토리를 사용했습니다. 같은 파일을 동시에 수정하면서 충돌이 생겼고, 한 에이전트가 의존성 버전을 바꾸면 다른 터미널에서 진행 중이던 빌드가 실패했습니다. 충돌할 때마다 git stash로 변경 사항을 임시 보관했지만 두 에이전트를 동시에 실행할 수는 없었습니다. 하나의 작업이 끝난 뒤 다음 에이전트를 실행했습니다.

git worktree로 에이전트 작업 공간 분리

일반적인 브랜치 전환은 작업 디렉토리 하나에서 체크아웃할 브랜치만 바꿉니다. git worktree를 쓰면 같은 저장소의 브랜치마다 별도 디렉토리를 둘 수 있습니다. git clone을 여러 번 할 필요도 없습니다. 각 worktree는 커밋 기록과 Git 메타데이터를 공유하고, 작업 파일만 별도 디렉토리에 둡니다. 어느 worktree에서 커밋하든 기록은 같은 저장소에 쌓입니다.

repo (datanexus)
 └─ base ref: origin/main
     ├─ worktree: fix-nl2sql-timeout    ← 브랜치 + 디렉토리 + 터미널
     ├─ worktree: semantic-layer-v2
     └─ worktree: rbac-audit

저는 브랜치 하나로 끝낼 수 있는 일을 태스크로 잡습니다. NL2SQL 타임아웃 수정과 시맨틱 레이어 개편이 각각 하나의 태스크입니다. 태스크마다 worktree를 만들고 각 에이전트가 자기 디렉토리에서만 작업하도록 했습니다. 에이전트 A가 node_modules를 바꿔도 에이전트 B의 빌드에는 영향을 주지 않습니다. 이제 두 에이전트를 동시에 실행해도 작업 파일과 빌드가 충돌하지 않습니다.

늘어난 worktree를 Orca로 통합 관리

worktree가 몇 개 없을 때는 수동으로 관리해도 괜찮았습니다. 태스크가 늘자 디렉토리와 실행 중인 에이전트를 일일이 확인하는 일이 번거로워졌습니다. Orca 는 worktree와 에이전트 실행 환경을 한곳에서 관리하는 오픈소스 데스크톱 앱입니다. YC 출신 팀 Stably가 만들었고 MIT 라이선스 로 공개했습니다. macOS, Windows, Linux를 지원하며 GitHub 스타는 이 글을 쓰는 시점에 1만 6천 개를 넘겼습니다.

태스크 하나 = git worktree 하나 = 에이전트 터미널 하나 = 브라우저 탭 하나

Orca에서 태스크를 만들면 worktree와 터미널, 브라우저 탭이 한 세트로 열립니다. 저장소를 등록할 때는 새 worktree를 만들 기준 브랜치인 base ref를 정합니다. 태스크 이름을 입력하면 Orca가 base ref에서 새 브랜치를 만들고 worktree로 체크아웃합니다. Orca가 만든 디렉토리도 표준 git worktree이므로 평소처럼 git 명령을 쓸 수 있습니다.

macOS에서는 아래 명령으로 설치합니다.

brew install --cask stablyai/orca/orca

첫 실행에서는 ~/.claude와 ~/.codex 설정을 가져올지 묻습니다. 제 경우 구독 로그인 정보까지 함께 옮겨져 다시 로그인하지 않고 Claude Code를 바로 실행할 수 있었습니다. 실행할 CLI는 Orca에 미리 등록된 목록에서 고릅니다. Claude Code, Codex, Cursor CLI를 포함해 25종이 넘으며 목록에 없는 CLI도 직접 추가할 수 있습니다.

세 에이전트의 결과 비교와 최종안 선택

같은 작업으로 태스크를 3개 만든 뒤 각 worktree에서 Claude Code, Codex, Cursor CLI를 하나씩 실행합니다. 세 에이전트에게 같은 프롬프트를 보내고 화면을 나눠 결과를 비교합니다. 채택할 결과를 고르면 나머지 두 브랜치는 지웁니다. Orca 문서 는 이처럼 같은 일을 여러 에이전트에게 동시에 맡기고 하나만 채택하는 방식을 레이스(race)라고 부릅니다.

9편 에서는 같은 모델이 만든 SQL 후보를 비교했지만 개선 효과가 없었습니다. 질문마다 후보를 3개씩 생성했는데 테스트 질문의 92%에서 세 후보가 같은 결과를 냈습니다. 후보를 고르는 selector도 첫 번째 후보를 한 번도 뒤집지 못했습니다. 후보 수를 늘려도 결과가 같아 selector가 선택할 여지가 없었습니다.

이번에는 세 worktree에서 서로 다른 모델을 실행했습니다. 같은 리팩토링을 맡겨도 한쪽은 인터페이스를 추출하고 다른 쪽은 상속 구조를 정리하는 등 접근법이 달랐습니다. 인터페이스 분리와 상속 구조 정리처럼 실제로 비교할 선택지가 생겼습니다.

태스크를 3개 실행하므로 토큰 사용량도 세 배 가까이 늘어납니다. 구현 방향이 분명한 수정에는 레이스를 쓰지 않습니다. 설계안이 여러 개 나올 수 있는 문제에만 사용하고, 채택하지 않은 worktree는 Orca에서 브랜치와 함께 지웁니다.

diff 코멘트를 활용한 수정 요청

결과를 고를 때는 먼저 diff를 확인합니다. 각 줄에 마크다운으로 코멘트를 달면 Orca가 내용을 묶어 해당 에이전트에게 다시 보냅니다. “early return으로 바꿔 주세요”, “이 테스트에는 에지 케이스가 빠졌습니다” 같은 한 줄 메모가 그대로 다음 수정 지시가 됩니다. 리뷰 내용을 프롬프트에 다시 옮겨 적지 않아도 됩니다.

11편 에서는 AI 답변과 함께 근거를 제공하는 문제를 다뤘습니다. 코딩 결과를 검토할 때는 diff가 판단 근거가 됩니다. 에이전트가 작성한 코드라도 사람이 변경 내용을 확인한 뒤 머지 여부를 정합니다. 커밋, 푸시, PR 리뷰, CI 상태 확인도 앱 안에서 이어서 처리할 수 있습니다. Linear나 Jira 이슈를 태스크로 가져오면 Orca가 해당 이슈용 worktree를 만듭니다.

태스크별 브라우저와 원격 worktree

worktree마다 별도의 Chromium 브라우저가 열립니다. Orca의 Design Mode에서 UI 요소를 클릭하면 해당 요소의 HTML과 CSS, 캡처한 스크린샷이 에이전트 프롬프트에 첨부됩니다. 에이전트에게 화면 상태를 말로 다시 설명하는 일이 줄었습니다.

연산량이 큰 작업은 SSH worktree에서 실행합니다. 로컬 대신 원격 머신에 worktree를 만들고 그 안에서 에이전트를 실행합니다. 실행 중 문제가 생기면 worktree별 복원 지점(checkpoint)으로 되돌릴 수 있습니다.

한 에이전트가 각 worktree의 작업을 배분하는 오케스트레이션(orchestration) 기능도 있습니다. 아직 실험 단계라 Settings > Experimental에서 켠 뒤 orca orchestration 명령으로 실행해야 합니다. 코딩 에이전트가 필요할 때 이 명령을 직접 호출하도록 스킬로 등록할 수도 있습니다.

Orca는 프로젝트 코드를 Stably 서버로 보내지 않고 로컬에 둡니다. 텔레메트리도 설정에서 끌 수 있습니다 .

레이스 적용 기준

어떤 태스크에 레이스를 쓸지는 아직 명확한 기준이 없습니다. 여러 설계안이 나올 문제를 작업 전에 가려내기가 어렵기 때문입니다. 몇 주간 더 사용하면서 어떤 유형의 태스크에서 레이스 결과를 실제로 머지했는지 기록할 생각입니다. 채택률과 토큰 비용을 함께 남겨 레이스 적용 기준을 정할 계획입니다.