결론부터 말하면, Orca로 Claude Code와 Codex를 동시에 돌리는 방식은 “코드를 두 배 빨리 짜는 도구”라기보다 “좋은 답을 더 빨리 고르는 방식”에 가까웠습니다. 저는 작은 기능 하나를 두 에이전트에 동시에 맡겼고, 최종 병합은 사람이 diff를 보고 골라야 했습니다.
작은 버그 하나를 골라 worktree 2개로 먼저 실험해보세요.
혼자 Claude Code만 붙잡고 있으면 한 방향으로 깊게 파고들 때가 많습니다. 반대로 Codex까지 병렬로 시키면 같은 요구사항을 다르게 해석한 결과가 나와서, 설계 선택지가 빨리 보입니다.
제가 실제로 쓴 셋업: Orca + git worktree + 같은 프롬프트
이번 테스트는 제가 운영 중인 블로그/쇼츠 자동화 파이프라인의 관리자 페이지 일부를 고치는 작업이었습니다. 큰 프로젝트는 아니지만, API 응답 정리와 UI 상태 처리, 테스트 수정이 같이 들어가는 애매한 사이즈였습니다.
핵심은 Orca에서 두 작업 공간을 나누고, Claude Code와 Codex CLI가 서로 다른 git worktree에서 같은 지시문을 받게 하는 것이었습니다. 저는 요즘 IDE보다 Warp 터미널에서 이런 식으로 굴리는 편이 손에 맞습니다.
git worktree add ../monstereae-claude -b agent/claude-admin-fix
git worktree add ../monstereae-codex -b agent/codex-admin-fix
cp .env.example ../monstereae-claude/.env
cp .env.example ../monstereae-codex/.env그다음 같은 task.md를 두 폴더에 넣었습니다. 프롬프트는 길게 쓰지 않았습니다. “관리자 페이지에서 발행 상태 필터가 초기화되는 버그를 고치고, 기존 테스트를 깨지 말 것. 변경 이유를 마지막에 요약할 것.” 정도였습니다.
처음 실패한 지점: 같은 포트, 같은 캐시, 다른 결과
처음에는 단순히 두 터미널에서 각각 실행했습니다. 바로 EADDRINUSE: address already in use :::3000가 나왔고, 한쪽에서 만든 임시 파일을 다른 쪽이 읽는 상황도 생겼습니다.
해결은 평범했습니다. 포트를 나누고, 캐시 디렉터리와 테스트 DB도 분리했습니다.
# claude worktree
PORT=3101 npm run dev
# codex worktree
PORT=3102 npm run dev병렬 코딩에서 제일 중요한 건 “AI를 동시에 많이 돌리는 것”보다 격리된 실험실을 만들어 주는 것이었습니다. 이걸 안 하면 빠른 게 아니라 헷갈립니다.
Claude Code와 Codex가 갈린 부분
둘 다 쓸 만한 코드를 냈지만 성격은 달랐습니다. Claude Code는 기존 코드 흐름을 읽고 최소 변경으로 접근하는 쪽이 강했고, Codex는 테스트 케이스와 타입 경계에서 더 공격적으로 수정안을 냈습니다. 물론 작업 종류와 프롬프트에 따라 달라질 수 있습니다.
| 구분 | Claude Code 단독 | Codex 단독 | Orca 병렬 운용 |
|---|---|---|---|
| 속도 체감 | 한 방향으로 빠르게 진행 | 대안 구현을 빠르게 제시 | 구현보다 비교 시간이 줄어듦 |
| 리스크 | 초기 가정이 틀리면 계속 밀고 감 | 수정 범위가 커질 때가 있음 | 충돌 관리를 사람이 해야 함 |
| 잘 맞는 일 | 기존 코드 리팩터링, 작은 버그 | 테스트 보강, 다른 설계 탐색 | 애매한 기능의 해법 비교 |
| 필수 조건 | 좋은 컨텍스트 | 명확한 완료 기준 | worktree, 테스트 명령, 리뷰 루프 |
구체적인 예: 필터 초기화 버그를 맡겼을 때
가상의 예가 아니라 이번에 제가 실제로 테스트한 작업 흐름입니다. 관리자 페이지에서 상태 필터를 바꾼 뒤 상세 화면에 갔다가 돌아오면 필터가 초기화되는 문제였습니다.
Claude Code는 URL query string에 상태를 보존하는 방식으로 작게 고쳤습니다. Codex는 상태 관리 훅을 분리하고 테스트를 더 붙였습니다. 최종으로는 Claude Code의 구현을 가져오고, Codex가 만든 테스트 아이디어 일부만 옮겼습니다.
여기서 병렬의 이득이 나왔습니다. 한쪽 결과물을 그대로 믿은 게 아니라, 두 diff를 비교하면서 “작은 수정 + 테스트 보강” 조합을 고른 것입니다.
이 방식이 잘 맞는 사람, 안 맞는 사람
추천하는 경우
이미 Claude Code나 Codex를 단독으로 써봤고, 매번 “이 방향이 맞나?”를 오래 고민한다면 병렬 운용이 꽤 도움이 됩니다. 특히 SaaS 관리자, 자동화 파이프라인, WordPress 연동처럼 작은 기능이 계속 쌓이는 프로젝트에 잘 맞습니다.
또한 테스트 명령이 준비된 팀에 좋습니다. 예를 들어 npm test, pnpm lint, pytest처럼 에이전트가 스스로 확인할 수 있는 하네스가 있어야 결과 비교가 쉬워집니다.
비추천하는 경우
아직 git branch와 conflict 해결이 익숙하지 않다면 먼저 단독 에이전트부터 권합니다. 병렬은 비용도 늘고, 컨텍스트가 부실하면 틀린 답이 두 개 생깁니다.
그리고 “둘 중 하나가 알아서 정답을 내겠지”라는 마음으로 켜면 실망합니다. 마지막 선택권은 여전히 개발자에게 있습니다.
가장 흔한 실수: 프롬프트만 같고 완료 기준은 없는 것
처음에는 저도 “이 버그 고쳐줘”만 던졌습니다. 결과는 보기엔 그럴듯했지만, 한쪽은 UI만 고치고 다른 한쪽은 테스트만 만졌습니다.
이후에는 프롬프트 끝에 완료 기준을 붙였습니다.
완료 기준:
1. 기존 테스트 통과
2. 필터 상태가 뒤로가기 후에도 유지
3. 변경 파일 5개 이하
4. 마지막에 변경 이유와 남은 리스크 요약이 네 줄을 넣으니 리뷰 시간이 확 줄었습니다. AI 코딩 에이전트에게는 “무엇을 할지”보다 “언제 끝났다고 볼지”가 더 중요할 때가 많습니다.
FAQ
Orca 없이도 같은 방식이 가능한가요?
가능합니다. Warp, tmux, VS Code 터미널만으로도 git worktree를 나눠 비슷하게 운영할 수 있습니다. Orca는 병렬 실행과 관찰을 편하게 만드는 쪽에 가깝고, 핵심은 격리와 비교 루프입니다.
비용이 두 배로 드나요?
사용량 기반 도구라면 대체로 호출량이 늘어 비용도 늘 수 있습니다. 그래서 모든 작업에 병렬을 쓰기보다, 설계가 애매하거나 실패 비용이 큰 작업에만 쓰는 편이 현실적입니다.
두 결과가 충돌하면 어떻게 고르나요?
저는 먼저 테스트 통과 여부, 변경 범위, 롤백 쉬움 순서로 봅니다. 멋진 구조보다 운영 중 빨리 되돌릴 수 있는 작은 diff가 더 나을 때가 많았습니다.
지금 바로 해볼 액션 체크리스트
- 작은 버그 하나를 고르고 완료 기준 3~4개를 적습니다.
git worktree로 Claude Code용, Codex용 폴더를 분리합니다.- 포트와 환경 파일을 나눠 같은 테스트 명령을 실행하게 만듭니다.
- 두 결과를 바로 병합하지 말고 diff만 비교해 좋은 부분만 가져옵니다.
처음부터 큰 기능을 병렬로 맡기기보다, 반나절 안에 되돌릴 수 있는 작업으로 감을 잡는 게 좋습니다. 다음 단계는 이 루프를 Make나 n8n 같은 자동화 도구와 연결해 결과 요약까지 모으는 것입니다.
오늘도, 코딩할 용기.
관련 링크
- AI 에이전트 하네스 엔지니어링 입문 결정적 오케스트레이션 직접 짜기: 에이전트를 ‘믿는’ 대신 묶어두는 법
- ai 코딩 구독 요금 비교: Claude Code·Cursor·Copilot, 빌드용으로 돈값 하는 조합
- AI 코딩 에이전트 용어가 안 들릴 때 왕초보가 챙긴 최소 개념: Cursor와 Claude Code로 읽는 법
- 관련 태그 더 보기
- 카테고리 더 보기
- 검색 결과 더 보기
- 참고 링크
