Claude Code → Codex 마이그레이션 툴 공개: MCP·메모리 그대로 옮기는 법

판교에서 9명 규모로 운영하는 우리 팀은 Claude-native로 출발했습니다. Claude Code Max 3계정에 월 약 100만원을 쓰면서, 거의 모든 코딩 워크로드를 Claude Code 위에서 돌렸습니다. 그런데 최근 4주 동안 일부 워크로드를 Codex로 옮기기 시작했고, 그 과정에서 만든 마이그레이션 툴을 오픈소스로 공개했습니다. 이 글은 Claude Code를 Codex로 부분 이전한 실측 기록과, MCP·메모리·하네스를 어떻게 그대로 가져왔는지 정리한 가이드입니다.

왜 Claude-native 팀이 Codex 병행을 고민하는가

작년 한 해 우리 팀의 표준 코딩 환경은 Claude Code였습니다. Sonnet과 Opus를 워크로드에 따라 갈아 끼우면서, 9명 엔지니어가 동시에 자동화 파이프라인을 돌리는 구조였습니다. 그런데 4주 전부터 두 가지 문제가 누적됐습니다.

첫째, 불안정성입니다. 피크 시간대에 503·529 응답이 반복적으로 발생하면서 자동화 파이프라인이 중간에 끊기는 일이 생겼습니다. 스케줄러로 돌아가는 백그라운드 작업의 경우, 재시도 로직이 있어도 한 사이클이 30~60분씩 밀렸습니다.

둘째, 토큰 비용 곡선입니다. Max 플랜으로 정액 사용은 하고 있었지만, 컨텍스트 윈도우가 큰 코드베이스를 분석하는 작업에서 사용량 한도에 도달하는 빈도가 늘었습니다. 메인 키워드인 Claude Code 자체의 한계라기보다, 워크로드 분리 없이 한 도구에 모든 작업을 맡긴 우리 운영 방식의 문제였습니다.

이 시점에 Codex가 GPT-5.1 기반 코딩 워크플로우로 안정화되면서 선택지가 늘었습니다. "전부 옮기자"가 아니라 "워크로드별로 분리하자"는 결론이었고, 이게 마이그레이션 툴이 필요해진 배경입니다.

Claude Code Max 3계정, 월 100만원의 비용 구조

먼저 우리 팀이 실제 쓰던 비용을 공개합니다. 9명이 Claude Code Max 3계정을 공유하는 구조였습니다.

3계정으로 9명을 커버한 건 동시성이 그렇게 높지 않았기 때문입니다. 한 계정당 평균 3명이 시간대를 나눠 쓰는 구조였고, 자동화 파이프라인은 별도 계정 한 자리를 점유했습니다.

문제는 자동화 파이프라인이 Max 한 자리를 거의 풀로 점유하기 시작하면서 발생했습니다. 사람 엔지니어가 쓸 슬롯이 부족해진 겁니다. 이 자동화 워크로드가 가장 먼저 Codex로 이전 후보가 됐습니다. 자동화는 사람과 달리 응답 속도보다 안정성과 토큰 단가가 더 중요했고, Codex의 GPT-5.1 코딩 모드가 이 두 조건에 더 잘 맞았습니다.

어떤 워크로드를 Codex로 옮겼나 (4주 실측)

4주 동안 워크로드별로 안정성·토큰 비용·결과 품질을 비교했습니다. 우리가 내린 분리 기준은 단순합니다.

Codex로 이전한 워크로드:

• 블로그 자동화 파이프라인 — 매일 1~2개 글을 7개 채널로 배포하는 스케줄러. 안정성이 결과 품질보다 중요.
• 로그 분석·요약 배치 — 새벽 4시에 도는 GA·GSC 데이터 요약 작업.
• OSS PR 트리아지 — GitHub 알림을 받아서 라벨링하는 자동화. 짧은 컨텍스트, 반복 작업.
• 테스트 케이스 생성 — 기존 코드 보고 단위 테스트 양산하는 작업.

Claude Code에 남긴 워크로드:

• 아키텍처 설계·디자인 리뷰 — 사람과 대화하면서 트레이드오프를 따지는 작업.
• 복잡한 디버깅 — 멀티 파일 reasoning이 필요한 케이스.
• 리팩토링 — 의도 파악이 결과 품질을 좌우하는 작업.
• 새로운 도메인 탐색 — 처음 보는 코드베이스 이해.

이 분리의 결과, Claude Code 사용량 한도 도달 빈도가 4주 전 대비 약 60% 줄었습니다. 자동화 워크로드가 빠진 빈자리에 사람 엔지니어의 슬롯이 안정적으로 들어갔습니다. Codex 쪽 비용은 워크로드 단가 기준으로 Claude 대비 약 35~45% 낮게 형성됐습니다.

마이그레이션 툴이 자동으로 옮겨주는 것과 수동 작업

옮기는 과정에서 가장 어려웠던 건 Claude Code에서 쓰던 자산을 Codex로 그대로 가져오는 일이었습니다. 단순히 프롬프트만 옮기면 되는 게 아니라, 다음 자산이 모두 따라와야 했습니다.

• MCP 서버 설정 — Playwright MCP, GitHub MCP, 자체 빌드 MCP 등 약 8개
• 플러그인 — `oh-my-claudecode` 같은 워크플로우 확장
• CLAUDE.md / 프로젝트 메모리 — 누적된 팀 컨벤션·반복 지시
• 하네스 / 슬래시 커맨드 — `/team`, `/autopilot` 등 커스텀 워크플로우
• 세션 히스토리 일부 — 이어가야 하는 장기 작업의 컨텍스트

이걸 매번 수작업으로 옮기면 한 프로젝트당 1~2시간이 걸렸습니다. 그래서 마이그레이션 툴을 만들었습니다.

자동으로 옮겨주는 것

```bash

# 설치

npx @treesoop/cc-to-codex-migrate init

# 현재 프로젝트의 Claude Code 자산 스캔

cc-to-codex-migrate scan

# Codex 형식으로 변환·복사

cc-to-codex-migrate apply --target ./codex-config

```

이 툴이 자동으로 처리하는 항목입니다.

1. MCP 서버 설정 변환 — `~/.claude.json`의 mcpServers 블록을 Codex가 읽을 수 있는 형식으로 변환.
2. CLAUDE.md → AGENTS.md 매핑 — 두 도구 모두 프로젝트 메모리 파일을 읽지만 파일 이름과 규약이 다릅니다. 헤더 구조를 자동 변환합니다.
3. 슬래시 커맨드 변환 — `~/.claude/commands/*.md`를 Codex 호환 포맷으로 변환.
4. 프로젝트 메모리 인덱스 — 누적된 메모리 파일을 검색 가능한 인덱스로 재구성.

수동으로 해야 하는 것

자동 변환이 어려운 영역도 있습니다.

• 세션 히스토리 — Claude Code의 세션 ID 기반 컨텍스트는 Codex로 옮기는 표준이 없어, 우리는 요약본만 새 메모리로 주입했습니다.
• 하네스 의존 워크플로우 — `superpowers` 같은 외부 스킬 시스템은 Codex에 동등한 등가물이 없는 경우가 있습니다. 이 부분은 워크로드 분리 시 해당 워크플로우를 어느 쪽에 둘지부터 결정해야 합니다.
• API 키 — 보안상 마이그레이션 툴이 자동으로 옮기지 않습니다. `codex auth login`으로 새로 인증하는 게 원칙입니다.

Claude Code vs Codex: 워크로드별 권장 매트릭스

4주 실측을 토대로 우리가 내부적으로 쓰는 매트릭스입니다.

워크로드 유형

권장 도구

이유

멀티 파일 reasoning, 아키텍처 설계	Claude Code (Opus)	컨텍스트 통합·트레이드오프 분석
자동화 파이프라인, 배치 처리	Codex	안정성·토큰 단가
복잡한 디버깅, 의도 파악	Claude Code (Sonnet)	대화형 reasoning
반복 작업, 템플릿 코드 생성	Codex	비용 효율
신규 코드베이스 탐색	Claude Code	큰 컨텍스트 윈도우
로그·문서 요약	Codex	짧은 컨텍스트, 반복 처리

이건 4주 실측 기준이고, 모델 업데이트가 잦은 영역이라 1~2개월 주기로 재검토할 예정입니다.

다음 단계

마이그레이션 툴은 GitHub에 OSS로 공개되어 있고, 우리 팀이 실제로 쓰면서 PR을 받는 구조입니다. Claude Code에서 Codex로 일부 워크로드를 옮기려는 팀, 또는 두 도구를 병행하려는 팀에게 가장 빠른 시작점이 될 거라 봅니다.

다음 글에서는 4주 실측 데이터를 기반으로 한 Claude Code vs Codex 정량 비교**를 다룰 예정입니다. 응답 시간 분포·토큰 단가·실패율 같은 raw number를 공개합니다. treesoop.com 자동화 파이프라인 운영기는 블로그에서 계속 이어집니다.

마이그레이션 툴 도입이나 워크로드 분리 전략에 대해 의견이 있으시면 GitHub 이슈로 남겨주세요. 같은 방향을 보고 있는 팀들과 더 많이 연결되면 좋겠습니다.