Claude Code와 Codex를 한 대의 기기에서 협업시키기 ― 설계는 Claude, 구현은 Codex에게 맡기기

Claude Code의 기억을 4개 층으로 나눈 이야기에서 이어지는 「Claude Code 환경」 시리즈입니다. 이번에는 1대의 Mac 안에서 Claude Code와 Codex CLI의 역할을 분담하는 이야기를 쓰겠습니다.

계기는 단순합니다. 메인 세션(Main Session)을 경량 모델로 돌리고 있을 때, 구현을 위한 긴 타이핑으로 토큰을 낭비하는 것이 아깝다고 느꼈기 때문입니다. 설계나 리뷰는 모델의 지능이 중요하지만, 정해진 구현을 꾸준히 써 내려가는 공정은 별도의 프로세스로 분리하고 싶었습니다. 그래서 구현은 Codex에 위임하고, 설계·리서치·리뷰는 Claude 측에 남기는 형태로 정착되었습니다.

분담 내용은 CLAUDE.md에 명문화했습니다. 요점은 다음과 같습니다.

공정	담당	이유
설계·코드베이스 리서치·계획	Claude (메인)	문맥 이해와 트레이드오프 (Trade-off) 판단이 필요함
...	...	...

포인트는 "전부 위임하지 않는다"는 것입니다. 구현 난이도가 높거나 무거운 설계 판단을 동반하는 구현은, 문맥을 파악하고 있는 메인 세션이 직접 작성하는 것이 더 빠르고 정확합니다. 위임은 어디까지나 "정해진 것을 양산하는" 공정으로 한정합니다.

모델의 지능이 필요한 공정(설계·리뷰)과 지능보다 양이 필요한 공정(정형 구현)을 나누는 것이 핵심입니다. "AI가 2개 있으니까 병렬로 빨라진다"가 아니라, "높은 자리에 앉힐 작업을 선택한다"는 발상입니다.

Codex는 CLI (codex-cli 0.135.0) 형태로 설치되어 있습니다. 위임은 **비대화형 헤드리스 실행 (Headless Execution)**으로 던집니다.

# 구현·태스크 위임 (@file로 파일 참조 가능)
timeout 600 codex exec --skip-git-repo-check "<의뢰 내용>" </dev/null
# 코드 리뷰 (현재 리포지토리에 대해 실행)
...

세세하지만 효과적인 포인트가 3가지 있습니다.

• </dev/null로 stdin을 반드시 닫는다: 닫지 않으면 Codex가 대화형 입력을 기다리며 프리즈(Freeze) 상태가 되고, timeout이 stdin을 닫을 때까지 무의미하게 대기하게 됩니다.
• timeout으로 감싸기: 헤드리스 AI 프로세스는 가끔 끝나지 않을 때가 있습니다. OS 측에서 강제 종료할 수 있도록 해두면, 멈춰버린 프로세스가 쌓이는 것을 방지할 수 있습니다.
• --skip-git-repo-check: git 리포지토리 외의 디렉토리에서 실행할 때 필요합니다. 이것이 없으면 리포지토리 판정에서 거부됩니다.

Codex는 nvm 하위에 설치되어 있습니다. 대화 중인 Claude의 Bash는 nvm default를 로드한 상태이므로 codex 명령어가 바로 통하지만, 순수 zsh나 cron을 통해 실행하면 command not found가 되는 경우가 있습니다. 그럴 때는 풀 경로(Full Path)로 실행합니다.

/Users/<you>/.nvm/versions/node/v24.13.0/bin/codex exec ...

launchd나 cron에서 무인으로 돌릴 경우, 최소 PATH에는 nvm이 포함되어 있지 않으므로 여기서 반드시 막히게 됩니다. 풀 경로 지정이 확실합니다.

실제 운용 플로우는 다음과 같습니다.

• 메인 (Claude): 요구사항을 받아 코드베이스를 리서치하고, 설계와 계획을 세움
• 규모 판단: 정형적·대규모·반복적이라면 위임, 난도가 높은 곳은 메인에서 직접 구현
• 위임 (Codex): codex exec에 구체적인 태스크를 던져 구현하게 함
• 리뷰 (Codex): 구현 완료 후, codex exec review로 코드 리뷰 수행
• 메인이 막히면: Codex에게 인계

3번과 4번을 별도의 엔진으로 나누는 것이 은근히 효과적입니다. 동일한 모델이 "직접 쓴 본인"으로서 리뷰하면 관대해지기 쉽지만, Codex에게 쓰게 하고 Codex에게 리뷰하게 하거나, 혹은 Claude가 리뷰하게 함으로써 작성자와 리뷰어를 분리할 수 있습니다.

긴 위임의 경우, 태스크·인계 사항·상태를 파일로 전달하도록 하고 있습니다. 대화의 문맥은 휘발되기 때문에, 상태를 디스크에 기록해 두면 재개나 검증이 쉬워집니다. worktree로 격리하여 실행할 때는 스테이터스 파일에 브랜치와 worktree 경로를 기록합니다.

# Status
- State: running
- Updated: 2026-06-17T...
...

이는 기억을 4개 층으로 나누었던 이야기와 같은 사상입니다. 휘발되는 대화 외부에 상태의 정본(Source of Truth)을 두는 것. 협업에서도 장기 기억에서도 적용되는 유효한 원칙은 동일했습니다.

• </dev/null $\rightarrow$ stdin은 반드시 닫을 것

• Codex가 대화 대기 상태로 프리징(freeze)되는 경우 $\rightarrow$ cron/launchd에서 실행 시 nvm 하위에 있으므로 전체 경로(full path)가 필수임 codex: command not found

• Git 리포지토리 외부에서 실행이 거부됨 $\rightarrow$ --skip-git-repo-check 사용

• 모두 위임하여 문맥(context) 손실 발생 $\rightarrow$ 어려운 부분은 메인에서 직접 작성. 위임은 정형화된 작업으로 한정

• 작성자=리뷰어라 리뷰가 느슨해짐 $\rightarrow$ 구현(implementation)과 리뷰(review)를 서로 다른 엔진으로 분리

• 한 대의 기기 안에서
  설계·리뷰는 Claude, 정형 구현은 Codex로 분리 - 위임 시에는
  codex exec --skip-git-repo-check "..." </dev/null

을 timeout으로 감싸서 비대화형(non-interactive) 실행

• 전부 위임하지 말 것. 어려운 부분은 메인에서 직접 작성 - 구현과 리뷰를 별도의 엔진으로 나누어 품질을 높임
• 상태는 파일로 저장할 것. 휘발되는 대화 외부(out of conversation)에 정본(source of truth)을 둠

다음 회차에서는, 그 push 직전에 **비밀 정보(secret)의 유출을 기계적으로 차단하는 훅(hook)**에 대해 다룹니다. ―― pre-push 가드로 API 키와 잘못된 push를 방지하는 방법에 대해 쓰겠습니다.