요즘 코딩 보조 도구를 하나만 쓰기보다, 상황에 따라 “역할 분리”해서 쓰는 게 생산성이 더 좋긴하다. Codex CLI를 주력으로 사용하고 있는 와중에 주말간 Claude Code를 개인적으로 구매해서 사용해보며 테스트를 해본다.
두 도구 모두 내 로컬 PC 내 공통 지침사항, MCP, 작업 레포 내에서만 사용할 지침들은 맞춰놓고 쓰고있음은 동일하다.
git worktree로 작업 디렉터리를 분리해 Claude Code(Opus 4.5) 와 Codex CLI(GPT-5.2) 를 동시에 돌리는 방식을 나름 테스트중이다.
특히 Claude(Opus)는 사용량 제한에 금방 걸리는 경우가 있어, “언제 쓰는 게 가장 효율적인지” 기준을 잡아두는 게 중요했다.
결론: Codex는 구현, Claude는 설계/리뷰에 강점
지금 시점으로부터 시간이 또 흐르면 각 AI 도구 별로 바뀌겠지만 현재 체감 기준으로 정리하면 아래 느낌이다. 이번 글은 어디까지나 git worktree 내용이 주요하니까...
(꼭 이게 옳은건 아님...)
- Codex CLI(GPT-5.2)
- 반복 구현, 파일 수정, 테스트 채우기 같은 “손이 많이 가는 작업”에 강함
- 한번 방향이 정해지면 속도가 잘 나온다.
- Claude Code(Opus 4.5)
- 설계 정리, 큰 구조 변경, 리팩터링 방향 잡기 같은 “큰 그림”에 강함
- 문서 템플릿/설계 문서 형태로 정돈된 답을 잘 만든다.
그래서 나름의 기본 전략은 이거다.
“문서/설계/리스크 체크는 Claude, 실제 구현/반복 수정은 Codex”
git worktree로 병렬 작업 환경 만들기
worktree를 쓰면 같은 레포를 여러 폴더로 분리해서 사용할 수 있다.
가장 좋은 점은 툴별로 브랜치와 작업공간이 분리되기 때문에, 동시에 작업해도 충돌이 크게 줄어든다는 것.
worktree 생성 예시
git fetch origin
# Claude용 작업공간 (설계/문서/큰 변경)
git worktree add ../repo-claude -b feat/claude origin/main
# Codex용 작업공간 (구현/테스트/반복 수정)
git worktree add ../repo-codex -b feat/codex origin/main
결과적으로 디렉터리는 이렇게 나뉜다.
repo-claude/ # Claude가 작업
repo-codex/ # Codex가 작업
역할 분리 운영 방식
보통 이렇게 나누는게 좋을 듯 싶다.
1) Claude(worktree)에서 설계/문서 먼저 만든다
Claude는 한 번에 “설계 문서 + 구현 체크리스트”까지 뽑아두면 효율이 좋다.
특히 문서는 md로 만들고, Mermaid 다이어그램을 같이 포함시키는 방식이 유용했다.
- API 설계 문서
- Mermaid 시퀀스/구조도
- 에러 포맷/트랜잭션 전략
- 운영 체크리스트(관측성, 롤백 등)
- 구현 TODO 리스트
예를 들면 이런 식이다.
- docs/feature-x.md
- docs/runbook.md
커밋은 문서 단위로 먼저 만든다.
cd ../repo-claude
git add docs/
git commit -m "docs: add spec + runbook for feature-x"
2) Codex(worktree)에서 실제 구현과 테스트를 채운다
설계가 정해졌으면 구현은 Codex가 잘한다.
특히 컨트롤러/서비스/레포 구현, 예외 처리, 테스트 추가 같은 반복 작업이 빠르게 진행된다.
cd ../repo-codex
git add src test
git commit -m "feat: implement feature-x + tests"
3) 마지막에 한쪽으로 합친다
예를 들어 문서가 있는 Claude 브랜치로 구현 결과를 가져오려면
cd ../repo-claude
git merge feat/codex
이 패턴이 단순하고, 충돌이 적어보인다.
충돌 줄이는 팁: “파일 소유권”을 정해두기
병렬 작업에서 제일 큰 적은 “같은 파일을 동시에 만지는 것”이다.
그래서 아예 파일 소유권을 나눈다.
- Claude 쪽에서 주로 다루는 파일
- docs/**, README.md
- 설계 문서, Mermaid 다이어그램
- 큰 구조 변경
- Codex 쪽에서 주로 다루는 파일
- src/**
- test/**
- 구현과 반복 수정
그리고 아래 파일들은 둘이 동시에 만지면 충돌이 자주 나서 한쪽만 담당하도록 한다.
- build.gradle(.kts)
- 배포/설정 파일 (values.yaml, kustomization.yaml 등)
- 공통 config 파일
Claude 사용량을 아끼는 요령

Opus는 강하지만, 기본적으로 비용(혹은 사용량 제한)이 빨리 닳는다.
내가 효과적이었던 방법은 “짧고 강하게 쓰는 것”이다.
- Claude는 처음 설계 1회 + 마지막 리뷰 1회 정도로만 사용
- 중간 반복 구현은 Codex로 넘기기
- Claude에게는 항상 출력 형태를 고정해서 요청
- 예: “md 문서 + Mermaid 2개 + TODO 리스트까지”
결국 핵심은 Claude는 ‘방향을 잡는 순간’에, Codex는 ‘방향대로 밀어붙이는 순간’에 쓰는 게 가장 효율적인 것 같다.
마무리
git worktree로 작업 공간을 분리해두면, 도구를 병렬로 쓰면서도 브랜치/파일 충돌이 줄어들고 정신이 덜 피곤해진다.
특히 Claude를 전략적으로 아껴 써야 하는 상황이라면 이 방식이 꽤 괜찮았다.
일단 두 도구 모두 내 개인적인 사용 패턴(eg. 작업하는 디렉토리나 자주 쓰는 명령어, 마우스로 클릭하는 사항 등)들을 토대로 커스텀하게 환경을 맞춰놓고 사용해봐야 좀 더 효율이 나지 않을까 싶다.