Claude Code는 대규모 코드베이스를 읽고 여러 파일에 걸친 계획을 유지하는 데 강합니다. Codex는 범위가 명확하고 테스트 주도적인 변경에 강합니다. 많은 엔지니어가 결국 같은 저장소에서 둘 다 사용하고 싶어 합니다. 한쪽은 리팩터링 초안을 작성하고 다른 쪽은 불안정한 테스트 스위트를 다지는 식이죠. 그런데 막상 시도해 보면 같은 작업 디렉터리가 문제가 됩니다. 서로 다른 두 도구, 서로 다른 두 CLI, 그리고 둘 다 쓰기를 시도하는 하나의 폴더.
이 가이드는 설정 과정을 단계별로 안내하고, 각 단계에서 발생하는 실패 유형을 짚어 주며, 두 개의 터미널이 어디서부터 확장되지 않는지 보여 줍니다. 격리 측면은 git worktree로 이미 해결된 문제입니다. 문제는 조정 측면, 즉 어떤 도구가 무엇을 하고 있는지 파악하고 모든 변경을 리뷰 가능한 상태로 유지하는 일이며, 여기서 Sharkly 같은 런타임 중립 계층이 등장합니다.
Sharkly는 Claude Code나 Codex를 대체하는 도구가 아닙니다. 이미 사용 중인 실행 도구 주위에 공유 Task, Computer, 컨텍스트, 리뷰 계층을 추가하여, Claude Code 세션과 Codex 세션이 두 개의 터미널이 아니라 하나의 워크플로 안에 두 개의 할당이 되도록 만들어 줍니다.
같은 저장소에서 Claude Code와 Codex를 함께 실행하는 이유
세 가지 이유가 반복적으로 등장하는데, 이들은 서로 다른 문제입니다.
작업마다 다른 강점. 넓은 컨텍스트가 필요한 작업(모듈 전반에 걸쳐 이 버그를 추적하기, 이 마이그레이션 계획하기)은 한 에이전트에게, 좁고 검증 가능한 작업(이 테스트 통과시키기, 이 함수 다듬기)은 다른 에이전트에게 맡깁니다. 도구를 작업에 맞추는 것은 그 자체로 별도의 주제입니다. 어떤 코딩 작업에 어떤 모델을 쓸지를 참고하세요.
실제 작업에서의 정면 대결. 유일하게 정직한 벤치마크는 리더보드가 아니라 여러분의 코드베이스입니다. 같은 티켓에 둘 다 실행하고 diff를 비교하면 어떤 공개 점수보다 더 많은 것을 알 수 있습니다. 이 방법은 자체 코드베이스에서 코딩 에이전트를 비교하는 방법에서 다룹니다.
이미 둘 다 비용을 지불하고 있습니다. 많은 팀이 이미 Claude 구독과 Codex 또는 API 좌석을 보유하고 있습니다. 요점은 공급자 중립성입니다. 다음 최고 모델을 어느 도구가 내놓든 워크플로가 재구축 없이 살아남아야 합니다.
이유가 무엇이든 실패 양상은 동일합니다. 한 폴더에 있는 두 에이전트는 잠금 장치 없이 하나의 문서를 편집하는 두 명의 작성자입니다. 한쪽이 다른 쪽 발밑에서 브랜치를 바꾸거나 편집 도중 파일을 재포맷하면, 말이 안 되는 반쯤 적용된 diff가 나옵니다.
1단계: 각 에이전트에게 자체 worktree 부여하기
git worktree는 충돌을 근본적으로 해결합니다. 하나의 저장소가 여러 작업 디렉터리를 동시에 체크아웃할 수 있으며, 각각 자체 브랜치에 있고 단일 .git 데이터베이스를 공유합니다. 두 도구가 다투는 하나의 폴더 대신 작업마다 하나씩 폴더를 갖게 됩니다.
# One checkout per task, each on its own branch
git worktree add ../app-refactor -b agent/refactor
git worktree add ../app-tests -b agent/tests
git worktree list
각 디렉터리에 서로 다른 도구를 지정합니다.
cd ../app-refactor && claude # Claude Code on the refactor
cd ../app-tests && codex # Codex on the test suite
이 단계를 건너뛸 때의 실패 양상: 두 도구가 같은 저장소로 cd를 실행하고, 같은 파일에서 경쟁하며, 한쪽이 다른 쪽의 커밋되지 않은 작업을 조용히 덮어씁니다. worktree를 사용하면 이것이 물리적으로 불가능해집니다. 이후 정리에 나름의 까다로운 지점이 있는데, 정리 고통 없이 worktree 관리하기에서 git worktree remove와 오래된 브랜치 문제를 다룹니다.
2단계: 각 도구가 올바른 지침을 가리키게 하기
Claude Code와 Codex는 서로 다른 프로젝트 파일을 읽습니다. Claude Code는 CLAUDE.md를 찾고, Codex는 AGENTS.md를 읽습니다. 저장소에 둘 중 하나만 있으면 한 에이전트는 여러분의 관례를 보지 못한 채 작업합니다.
둘 다 유지하고, 일관성 있게 관리하세요. 신뢰할 수 있는 패턴은 공유 규칙을 한 번만 작성하고 각 진입점이 이를 포함하게 하는 것입니다.
<!-- CLAUDE.md and AGENTS.md both start with -->
See ./docs/agent-conventions.md for build, test, and style rules.
# Verify each tool actually loads its file before you turn it loose
claude --version # Claude Code reads CLAUDE.md from the worktree root
codex --version # Codex reads AGENTS.md from the worktree root
이 단계를 건너뛸 때의 실패 양상: Codex는 한 린트 설정을 따르고 Claude Code는 다른 설정을 따르면서, 모든 머지가 아무도 기록해 두지 않은 스타일 싸움으로 변합니다. 여기서 개인적인 조언 하나가 중요합니다. 설치 토큰은 여러분의 관례를 담지 않으며, .gitignore에 들어간 로컬 파일은 worktree로 이동하지 않습니다. 공유 규칙은 추적되는 파일에 넣으세요. 그렇지 않으면 새 worktree마다 빈 상태로 시작합니다.
3단계: 실행한 뒤 벌어지는 조정 격차 지켜보기
두 개의 worktree와 두 개의 설정 파일이 있으면 역학은 작동합니다. 한 브랜치에는 Claude Code가, 다른 브랜치에는 Codex가 있고 서로의 파일을 건드리지 않습니다. 두 에이전트로 한나절 정도라면 이 구성이 유지됩니다.
격차는 키보드에서 눈을 떼는 순간 벌어집니다. 각 세션은 자기 탭에 자기 이력을 보관하며 다른 쪽에는 보이지 않습니다. Codex 실행이 Claude Code 실행이 이미 무엇을 바꿨는지 알아야 할 때 참고할 공유 메모리가 없으므로, 여러분이 통합 계층이 됩니다. 에이전트들은 서로 다른 시점에 끝나고 조용히 입력을 기다리므로, "둘 다 병렬로 실행"은 어느새 "둘을 순차적으로 확인"으로 조용히 전락합니다.
이를 두 개 이상으로 확장해 보세요. 자연스러운 다음 단계는 worktree를 생성하고, 각각에 알맞은 도구를 실행하며, 출력을 이름 붙인 tmux 창으로 보내는 래퍼 스크립트입니다. 몇 개의 실행에는 도움이 됩니다. 그러다 커집니다. 브랜치 명명, 정리, 어떤 도구가 어떤 작업을 하는지 알 수 있는 방법, 충돌한 것에 대한 재시도. 얼마 지나지 않아 상태의 절반은 셸 히스토리에, 나머지 절반은 머릿속에 있는, bash로 대충 묶인 부서지기 쉬운 오케스트레이션 프레임워크를 유지보수하게 됩니다. 한 번에 많이 실행하는 것은 에이전트가 전부 Claude Code인 경우든, 여러 Claude Code 에이전트 실행하기에서처럼, 아니면 혼합이든 같은 벽에 부딪힙니다.
두 터미널이 확장되지 않는 지점
DIY 구성에서 벗어났는지 판단하는 정직한 테스트입니다.
- 동료가 여러분이 터미널을 읽어 주지 않아도 지금 여러분의 에이전트가 무엇을 하는지 볼 수 있나요?
- Codex가 오후 2시에 끝나고 입력이 필요할 때, 무언가가 여러분에게 알려 주나요?
- 두 에이전트가 동시에 끝났을 때, 그 작업을 리뷰할 큐가 있나요, 아니면 그저 여러분과 두 개의 브랜치뿐인가요?
답이 모두 아니오라면, 빠진 조각은 또 다른 셸 스크립트가 아닙니다. 그것은 어느 도구에든 작업을 할당하고, 실시간 상태를 보여 주며, 머지 전에 모든 변경을 리뷰 가능한 상태로 유지하는 계층입니다. 이것이 바로 태스크 보드가 순수 터미널 위에 더해 주는 것입니다.
이것이 분명히 짚어 둘 만한 경계입니다. Claude Code와 Codex는 실행을 수행합니다. 명령 계층은 할당, 연결된 Computer, 작업 컨텍스트, 진행 상황, 차단 요소, 결과, 그리고 둘 모두에 걸친 사람의 리뷰를 관리합니다. Sharkly에서는 하나의 Task를 Claude Code Runtime에, 다른 하나를 Codex Runtime에 할당합니다. 각각은 연결된 Computer의 자체 격리된 worktree에서 실행되며, 실행, 차단 요소, 결과가 개인 터미널로 사라지는 대신 Task 타임라인으로 돌아옵니다.
역할 분담은 깔끔하게 유지됩니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하며, 결과를 받아들입니다. 자동화는 여러분의 판단이 필요한 지점에서 멈추고, 검증 증거가 첨부된 diff를 되돌려 줍니다. 이미 비용을 지불하고 있는 도구를 그대로 유지하고, 모델 사용은 각 도구에 설정된 구독과 API 키를 통해 계속 처리되며, 누가 무엇을 하는지 볼 수 있는 한 곳을 얻게 됩니다.
한나절 동안 에이전트 하나나 둘을 실행하면서 상태를 머릿속에 담아 둘 수 있을 때는 수동 설정을 사용하세요. 두 번째 사람이 가시성을 필요로 할 때, 실행 수가 한 터미널 창에 보이는 양을 넘어설 때, 또는 "이 브랜치가 어느 실행에서 나왔지"가 더 이상 명확하지 않을 만큼 자주 도구를 비교할 때는 공유 계층을 찾게 됩니다.
오늘 바로 실행할 수 있는 체크리스트
다음에 두 도구를 한 저장소에 올릴 때 위에서 아래로 실행하세요.
- [ ] 작업마다 하나의
git worktree를 만들고, 각각 자체 브랜치를 두세요. 절대 두 도구를 같은 디렉터리에 지정하지 마세요. - [ ]
CLAUDE.md와AGENTS.md를 둘 다 커밋하고, 각각이 추적되는 소스의 하나의 공유 관례 파일을 가리키게 하세요. - [ ] 작업을 할당하기 전에 각 도구가 worktree 루트에서 설정을 로드하는지 확인하세요.
- [ ] 에이전트마다 범위가 정해진 Task 하나를 할당하세요. 넓은 컨텍스트 작업은 한쪽에, 좁은 테스트 주도 작업은 다른 쪽에.
- [ ] 리뷰 게이트를 미리 정하세요. 사람이 diff와 테스트 결과를 읽기 전까지는 어떤 브랜치도 머지하지 않습니다.
- [ ] 동시 실행이 두세 개를 넘어서면 bash 확장을 멈추고 할당, 상태, 리뷰를 하나의 계층으로 옮기세요.
하나의 생태계에 전념하는 대신 Claude Code와 Codex를 계속 함께 사용하고 싶다면, 그것이 바로 Sharkly가 염두에 두고 설계된 문제입니다. Sharkly 다운로드하고 Computer 하나를 연결한 뒤, 작업에 맞는 에이전트에 첫 Task를 할당하세요.
FAQ
Claude Code와 Codex가 같은 파일을 안전하게 편집할 수 있나요? 같은 디렉터리에서는 안 됩니다. 각자 자체 git worktree를 부여해 별도 브랜치에서 작업하게 하고, 리뷰를 거쳐 머지하세요. 같은 디렉터리에서의 동시 작업은 커밋되지 않은 작업이 유실되는 지점입니다.
구독 두 개가 필요한가요? 각 도구가 요구하는 만큼이면 됩니다. 모델 사용은 Claude Code와 Codex에 설정된 구독이나 API 키를 통해 계속 처리되며, 조정 계층이 그 접근을 바꾸거나 재판매하지 않습니다.
에이전트 둘에 태스크 보드는 과한가요? 한자리에서 직접 통제하는 에이전트 둘이라면 평범한 worktree와 터미널 두 개로 충분합니다. 보드는 동료가 가시성을 필요로 하거나 실행 수가 늘어날 때 제 역할을 합니다. 병렬 AI 코딩 에이전트를 관리하는 최고의 도구를 참고하세요.
