Claude Code와 Codex를 함께 쓸 때 역할 나누기: 커밋 384건에서 본 것

AI 코딩 도구를 두 개 이상 쓰다 보면 “이 일은 어느 쪽에 맡기지?”에서 자주 멈칫합니다. 저도 Claude Code와 Codex(oh-my-codex, 줄여서 OmX)를 같이 씁니다.

그래서 이번에는 기준을 머리로 짜는 대신 이미 남은 기록을 봤습니다. 이 블로그에서 연재한 데스크톱 펫 프로젝트의 커밋 384건입니다. 어느 도구가 어떤 커밋을 했는지 세어 보면, 역할이 어떻게 나뉘었는지 기록에 그대로 드러납니다.

커밋마다 도구 이름이 남아 있었습니다

이 프로젝트는 커밋 메시지 끝에 Co-Authored-By 트레일러로 어느 AI가 함께 작업했는지 남깁니다. 도구별로 세는 명령은 이렇습니다.

git log --format="%(trailers:key=Co-Authored-By,valueonly)" | sort | uniq -c | sort -rn

펫 프로젝트에서 나온 숫자는 이렇습니다.

도구	커밋 수
Claude Code (Fable 5)	91
OmX (Codex 기반)	84
Claude Code (Sonnet 5)	16

트레일러가 없는 커밋도 많습니다. 그래서 이 표는 전체가 아니라 도구가 이름을 남긴 커밋만의 분포입니다.

날짜별로 펼치면 순서가 보입니다

총계만 보면 두 도구가 비슷하게 일한 것 같습니다. 날짜별로 펼치면 이야기가 달라집니다.

날짜	주로 커밋한 도구	커밋 수
7월 10~11일	Claude Code (Fable 5)	45
7월 12일	Claude Code (Sonnet 5)	16
7월 13~14일	OmX	75
7월 22~23일	Claude Code (Fable 5)	39

두 도구가 같은 날 번갈아 일한 게 아니라, 구간을 나눠 이어 달렸습니다. 7월 13~14일 이틀 동안은 OmX가 75건을 몰아서 했고, 그 전후는 Claude Code가 맡았습니다.

커밋 제목을 보면 맡은 일이 다릅니다

각 구간의 커밋 제목을 몇 개씩 뽑아 보면 성격이 꽤 다릅니다.

Claude Code 구간에는 이런 커밋이 많습니다.

docs: draft the quarter-view omok versus game design (v0.1)
feat: let the character physically play omok with stone-carrying moves (Phase C)
fix: stop showing window-top speech poses on the floor

설계 문서를 쓰고, 새 기능을 만들고, 화면에서 보이는 문제를 고치는 커밋입니다.

OmX 구간은 결이 다릅니다.

Prevent stale ambient replies from interrupting live input
Guard target-owned climb edges against global leakage
Make stale release evidence fail preflight

“막는다”, “지킨다”, “실패하게 만든다”가 반복됩니다. 이미 있는 기능이 이상한 상황에서 깨지지 않게 조이는 일입니다.

정리하면 이 프로젝트에서는 새 방향을 여는 일은 Claude Code가, 열어 놓은 것을 단단하게 만드는 일은 OmX가 했습니다. 기록으로 확인되는 건 여기까지입니다. 왜 그렇게 나눴는지는 커밋에 남지 않으니, 이 결과를 규칙처럼 받아들일 필요는 없습니다.

도구를 바꿀 때는 인계 문서가 필요했습니다

구간을 나눠 이어 달리려면 바통을 넘겨야 합니다. 도구가 바뀌면 앞 도구가 대화 속에서 알던 맥락이 사라지기 때문입니다.

이 프로젝트에는 그런 인계 문서가 따로 있습니다. 예를 들어 계단식 창 오르기 기능의 인계 문서는 이런 목차로 되어 있습니다.

1. 인계 기준점 (브랜치, 커밋 해시, 작업 트리 상태)
2. 사용자 요구사항
3. 완료된 커밋
4. 구현 결과
5. 완료된 검증
6. 아직 완료되지 않은 검증
7. 대화 timeout 조사 결과
8. 다음 담당자의 실행 순서
9. 보호해야 할 사용자 파일과 워크트리
10. 완료 판정 기준

눈여겨볼 항목은 6번과 9번입니다. 아직 검증하지 못한 것을 따로 적어 두지 않으면, 다음 도구는 앞 작업이 다 끝난 줄 알고 그 위에 쌓습니다. 건드리면 안 되는 파일을 적어 두지 않으면, 다음 도구가 정리한다며 사용자 파일을 지울 수도 있습니다.

반대로 이 문서에 없는 게 있습니다. 앞 도구와 나눈 대화 내용입니다. 대화는 넘길 수 없으니, 결정과 그 근거만 문서로 넘깁니다.

이 블로그에서는 이렇게 나눠 씁니다

이 블로그의 글 파이프라인에서도 두 도구가 다른 일을 합니다.

• Codex는 초안 생성기입니다. 파이프라인이 codex exec --sandbox read-only로 부릅니다. 파일을 고치거나 명령을 실행하지 못하게 읽기 전용으로 막아 두고, 글만 받아 옵니다.
• Claude Code는 파이프라인 코드를 고치고, 서버 상태를 확인하고, 커밋하는 쪽을 맡습니다.

Codex를 명령 한 줄로 부르는 부품처럼 쓰고, Claude Code를 저장소 전체를 다루는 작업자처럼 쓰는 셈입니다.

도구가 둘이면 관리할 것도 둘입니다

같이 쓰면서 생기는 비용도 있습니다. 이 글을 쓰는 날에도 하나 겪었습니다.

Codex CLI를 불렀더니 기본 모델이 더 새로운 버전의 Codex가 필요하다는 오류로 실패했습니다. 이 상태라면 Codex에 맡긴 초안 생성도 같은 오류로 멈춥니다.

npm install -g로 최신 버전을 설치했는데도 버전이 그대로였습니다. 알고 보니 Codex가 두 군데 설치돼 있었습니다. 하나는 Homebrew 쪽(/opt/homebrew/bin), 하나는 홈 폴더 쪽(~/.local/bin)이었고, PATH에서 홈 폴더 쪽이 먼저 잡히고 있었습니다. 새 버전을 설치해도 실행되는 건 옛 버전이었던 거죠. 홈 폴더 쪽까지 올리고 나서야 정상으로 돌아왔습니다.

도구가 하나면 매일 쓰니까 이런 일이 바로 드러납니다. 둘이면 덜 쓰는 쪽이 조용히 낡아 갑니다. 그래서 두 도구의 버전을 확인하는 명령을 같이 돌려 봅니다.

claude --version; codex --version
which -a codex

which -a는 PATH에 걸린 같은 이름의 실행 파일을 전부 보여 줍니다. 두 줄 이상 나온다면 맨 위의 것이 실제로 실행되는 쪽입니다.

정리하면

• 역할 분담 기준을 머리로 짜기 전에, 커밋 기록에서 도구별로 무슨 일을 했는지 먼저 세어 보는 게 빠릅니다.
• 이 프로젝트에서는 새 방향을 여는 일과 단단하게 조이는 일로 역할이 갈렸습니다. 다른 프로젝트에서는 다르게 갈릴 수 있습니다.
• 도구를 바꿀 때는 아직 검증하지 못한 것과 건드리면 안 되는 것을 반드시 문서로 넘깁니다.
• 덜 쓰는 도구는 조용히 낡습니다. 버전 확인을 같이 해 둡니다.