Claude Code 중심 운용에서 Codex 중심 운용으로 전환하는 판단 기준

서론

Claude Code로 쌓아온 운용을 어떤 단위로 Codex로 옮겨야 할지 정리하고 싶었기에, 지난 몇 주간 자신의 환경을 실측하며 이행 기준을 다져왔습니다. 결론부터 말하자면, 설정이나 프롬프트를 통째로 복사하는 것보다 "해당 운용이 무엇을 달성하고 있는가"를 capability (역량) 단위로 분리한 뒤 옮기는 것이 더 안정적이었습니다.

2026-06-15 시점에서 수중에 있는 것을 확인하니, ~/.codex/automations의 automation.toml은 15건, ~/.claude/scheduled-tasks 측의 SKILL.md / config.toml / automation.toml은 24건이 있었습니다. 즉, 아직 1:1로 모두 이식된 상태는 아닙니다. 게다가 python3 ~/.codex/skills/claude-context-sync/scripts/check_claude_codex_drift.py의 출력에서도, codex-hook-coverage나 tooling-mcp-cli-parity는 partial (부분적) 상태였습니다. 이행은 "존재하니까 완료"가 아니라, "어디까지 실운용을 대신할 수 있게 되었는가"로 보지 않으면 위험하다는 사실이 먼저 눈에 들어왔습니다.

1. 먼저 옮기는 것은 파일이 아니라 capability

제가 처음에 시도했을 때 실패하기 어려웠던 방법은, Claude 측의 자산을 "기능"으로 분해하는 것이었습니다. ~/.codex/references/claude-to-openai-migration.md와 Vault 측의 02_Knowledge/decisions/2026-05-24_codex-primary-runtime-migration.md / 02_Knowledge/playbooks/ai/codex-primary-runtime-migration-spec.md를 읽어보면, 사고방식이 상당히 일관되어 있습니다.

• 일상 운용의 중심은 코드 편집, Vault 운용, 리뷰, 정기 태스크, 안전 가드
• 각각에 대해 "Codex 측에 이미 대체 수단이 있는가" 또는 "아직 shadow (그림자) 병행을 해야 하는가"를 부여
• 미이식된 것은 이름이 있다고 해서 완료로 취급하지 않음

이 관점으로 바꾼 뒤부터 이행 판단이 상당히 수월해졌습니다. 예를 들어 review 계열은 covered (커버됨) 상태여도, hook이나 CLI parity는 partial 상태로 남아 있는 경우가 있습니다. 이 부분을 전부 "이행 완료"라고 대충 묶어버리면, 나중에 compact (압축) 후의 복원이나 자동화의 이중 발화로 인해 문제가 생기기 쉽습니다.

2. "exists"보다 "artifact (결과물)가 돌아가는가"를 본다

이행 spec (명세)에서 특히 효과적이었던 것은, target=exists를 완료 조건으로 삼지 않는다는 생각이었습니다. 실제로 제 환경에서도 "파일은 있지만, 운용 측면에서는 아직 부족한" 것들이 남아 있습니다.

# 2026-06-15에 확인한 실측
find ~/.codex/automations -maxdepth 2 -name automation.toml | wc -l
# => 15
...

이 차이가 보이기 시작한 이후부터, 이행 완료 조건을 "파일이 있다"가 아니라 다음의 3가지 관점으로 보게 되었습니다.

• 실행 결과의 artifact (결과물)를 확인할 수 있는가
• 이중 발화되지 않는가
• 승인 게이트 (approval gate)가 Codex 측에도 유지되고 있는가

특히 scheduled task (예약된 태스크)는 이 부분을 모호하게 하면 위험합니다. Claude 측과 Codex 측에 이름이 비슷한 메커니즘이 남아 있더라도, owner (소유자)를 정하지 않고 방치하면 "한쪽은 멈추거나", "양쪽 모두 실행되거나" 둘 중 하나가 되기 쉬웠습니다.

3. 현재 나의 기준

지금은 새로운 운용을 Codex로 옮기기 전에 다음 순서로 확인하고 있습니다.

• 해당 운용을 capability 명칭으로 한마디로 정의할 수 있는가
• Codex 측에 대응하는 skill / automation / hook이 있는가
• covered 인지 partial 인지를 drift (편차) 체크로 확인했는가
• 실제 결과물이나 dry-run (드라이 런)을 통해 "돌아가는 것"을 확인했는가
• push, 공개, 송신의 승인 게이트가 뒤섞여 있지 않은가

이 순서를 따르니 "일단 옮기긴 했지만, 운영 측면에서는 미완성 상태였다"와 같은 사고가 줄어들었습니다. 제 환경에서는 Claude를 즉시 폐기하기보다, read-only (읽기 전용) 참조원으로 남겨두면서 Codex 측을 capability (역량) 단위로 채워 나가는 것이 더 현실적이었습니다.

요약

• Claude Code에서 Codex로의 전환은 설정 이식보다 capability (역량) 분해부터 시작하는 것이 판단하기 쉽다
• exists (존재 여부) 판정만으로는 부족하며, 결과물 확인 · 이중 실행 방지 · 승인 게이트 유지까지 확인하는 것이 더 안전하다 - 2026-06-15 기준 제 환경에서는 Codex automation (자동화) 15건에 대해 Claude 측 artifacts (아티팩트)는 24건이 있어, 아직 완전 일치 상태는 아니었다
• drift (드리프트) 체크 시 covered (커버됨)와 partial (부분적)을 구분해서 보면, 다음에 채워야 할 공백이 명확해진다
• 갑작스러운 전면 전환보다는 Claude를 read-only (읽기 전용) 참조원으로 남겨두고 단계적으로 전환하는 것이 시스템 파괴를 방지하기 쉽다

Discussion