Claude Code에 GPT-5.6을 연결해 보니: CCR은 빨랐고 Codex는 더 꼼꼼했다

Insight — 빠른 진입점과 안전한 검증 관문은 같은 도구일 필요가 없습니다

핵심 Insight
동일한 GPT-5.6 Sol을 사용해도 Claude Code Router를 거친 경로는 총시간이 38% 짧았고, 순정 Codex는 평균 품질이 2.4점 높았습니다. 따라서 Claude(CCR)는 탐색·PM·문서 작업의 front door, Codex는 쓰기·보안·배포·고위험 판단의 assurance gate로 배치하는 편이 합리적입니다.

이 글에서 Claude(CCR) 모드란 Anthropic의 Claude 모델을 뜻하지 않습니다. Claude Code 클라이언트 + CCR + GPT-5.6 Sol 조합입니다. Codex 모드는 같은 GPT-5.6 Sol을 OpenAI 순정 Codex에서 실행한 경로입니다.

Figure 1. Claude(CCR)는 빠른 진입점, 순정 Codex는 고위험 승격 경로로 배치합니다.

인포그래픽 읽는 법: 문서 작성이나 초기 진단은 CCR에서 시작합니다. 파일 쓰기, 테스트 재현, 권한, 보안, 배포처럼 실패 비용이 커지는 순간 순정 Codex로 승격합니다. 전체 작업을 양쪽에서 반복하지 않고 위험 구간만 넘기는 것이 핵심입니다.

핵심 요약: 이번 결론은 “어느 모델이 더 좋은가”가 아니라 “어느 단계에서 실행 경로를 바꿀 것인가”입니다.

왜 이 실험을 했는가 — 모델 순위가 아니라 제 작업 흐름의 병목을 확인하려 했습니다

제가 이 실험을 시작한 직접적인 계기는 Claude Code의 모델 목록에서 CCR이 연결한 GPT-5.6 Sol을 실제로 선택할 수 있게 된 것이었습니다. 연결 성공 자체는 흥미로웠지만, 그것만으로 업무 기본 경로를 바꾸기에는 답하지 못한 질문이 너무 많았습니다. 같은 엔진을 쓰는데도 Claude Code를 거칠 때와 순정 Codex를 쓸 때 실제 작업 결과가 달라지는가? 달라진다면 그 차이는 속도인가, 품질인가, 아니면 운영 위험인가?

이 질문이 중요했던 이유는 제 하루 업무가 한 종류가 아니기 때문입니다. 오전에는 여러 저장소와 장문 문서를 훑어 경영진 브리프나 PM 판단안을 만들고, 오후에는 실패한 발행 파이프라인의 원인을 추적하거나 dirty tree에서 안전한 변경 범위를 정합니다. 어떤 날은 800줄이 넘는 설계·계획 문서의 모순을 찾고, 어떤 날은 WordPress에 올릴 기술 글의 주장과 출처를 교차검증합니다. 이 작업들은 모두 “AI에게 질문한다”는 점에서는 같지만, 실패 비용은 전혀 다릅니다.

실제 사용 중에는 네 가지 마찰이 반복됐습니다.

1. 긴 세션의 compact가 예상보다 자주 발생했습니다. 모델 선택 화면의 컨텍스트 표기와 실제 세션 운영 한계가 같은지 확인할 필요가 있었습니다.
2. 상태바의 달러 표시와 쿼터 표기가 혼동을 만들었습니다. API-equivalent 환산치인지 실제 별도 API 청구인지, Codex 구독 Primary quota에서 차감되는지 구분해야 했습니다.
3. 작업환경과 검증력을 동시에 포기하기 싫었습니다. Claude Code의 hooks·Model Context Protocol(MCP)·skills·권한 UX는 문서·PM 작업에 편리했습니다. 반면 코드 쓰기·테스트·보안·배포에서는 순정 Codex의 네이티브 동작과 재현성이 중요했습니다.
4. CCR은 유용하지만 비공식 중간 계층입니다. 요청·응답·tool call을 변환하는 과정이 속도를 높일 수도 있지만, 반대로 새로운 장애지점과 의미 손실을 만들 수도 있습니다.

그래서 공개 모델 벤치마크 점수를 다시 인용하는 대신, 모델을 GPT-5.6 Sol로 고정하고 클라이언트와 도구 경로만 바꾸는 비교를 설계했습니다. 코딩 퍼즐 대신 제가 실제로 자주 수행하는 브리프, PM 거버넌스, WordPress 장애 RCA, 871줄 장문 추적성, 통합 리포트 감사, Git closeout, 3-turn 의사결정 대화를 사용한 이유입니다.

실험이 답하려는 의사결정 질문도 처음부터 세 가지로 제한했습니다.

• 반복 탐색과 문서 작업의 기본 진입점은 어느 경로가 적합한가?
• 결함 누락 비용이 큰 작업은 언제 순정 Codex로 승격해야 하는가?
• 두 경로를 혼합할 때 과금·컨텍스트·로그·설정 오염을 어떻게 통제할 것인가?

즉, 이 실험의 목적은 CCR이나 Codex의 승자를 정하는 것이 아니었습니다. 제가 매일 반복하는 복합 PM·리서치·개발 작업에서 어느 경로가 시간을 줄이고, 어느 경로가 놓치면 비싼 결함을 더 잘 잡는지 확인하는 것이었습니다.

핵심 요약: 같은 엔진을 고정한 것은 모델 성능이 아니라 클라이언트·도구 루프·운영 경로가 실제 업무에 만드는 차이를 분리해 보기 위해서였습니다.

TL;DR — 두 리포트의 결론을 다섯 줄로 정리했습니다

1. 연결은 가능합니다. MIT 오픈소스 CCR이 Claude Code의 Anthropic Messages 요청과 다른 공급자 프로토콜 사이를 라우팅·변환합니다.
2. 공식 교차제품 통합은 아닙니다. Anthropic은 제3자 게이트웨이를 감사·보증하지 않으며 비Claude 모델 라우팅을 지원하지 않는다고 명시합니다.
3. 실측 속도는 CCR이 우세했습니다. 7개 시나리오에서 18.2분 대 29.4분으로 38% 짧았습니다.
4. 실측 품질은 순정 Codex가 우세했습니다. 94.4점 대 96.9점이며 RCA와 장문 추적성에서 추가 결함을 찾았습니다.
5. 권장은 혼합 운영입니다. Claude(CCR)는 빠른 탐색, Codex는 고위험 실행과 최종 검증에 사용합니다.

핵심 요약: CCR은 Claude Code를 대체하는 모델이 아니라 여러 모델과 인증 경로를 연결하는 로컬 제어 계층입니다.

Part 1. CCR은 무엇인가 — Claude Code를 멀티모델 작업대로 만드는 MIT 오픈소스입니다

Claude Code Router(CCR)는 MIT 라이선스로 공개된 로컬 모델 게이트웨이이자 에이전트 제어판입니다. 공급자·모델·계정·프로필·라우팅·로그를 한곳에서 관리하고, 요청·응답 변환기를 통해 서로 다른 API 형식을 연결합니다. 공식 저장소는 모델 전환, 조건부 라우팅, retry와 fallback, 토큰·지연·예상비용 관측을 주요 기능으로 제시합니다.

오픈소스라는 말은 소프트웨어를 검토·수정·자가 호스팅할 수 있다는 뜻이지, 연결한 모델이 무료이거나 공급자가 그 조합을 지원한다는 뜻은 아닙니다. 이 시험에서 사용한 CCR은 3.0.19였고, GPT-5.6 Sol의 비용은 별도 Platform API가 아니라 가져온 Codex ChatGPT 로그인과 구독 한도에서 차감되도록 구성했습니다.

CCR이 유용한 경우

• Claude Code의 hooks·MCP·skills·권한 UX는 유지하면서 과업별 모델을 바꾸고 싶을 때
• 문서·리서치·배경 작업은 빠른 경로로, 어려운 추론은 강한 모델로 라우팅할 때
• 여러 공급자의 연결 상태·실제 선택 모델·지연·토큰·실패를 한 화면에서 관찰할 때
• 기존 Claude 기본 설정을 건드리지 않고 격리 프로필에서 GPT를 파일럿할 때
• API Key 대신 지원되는 로컬 agent login을 가져와 구독 경로를 시험할 때

CCR을 기본 경로로 삼지 말아야 할 경우

• OpenAI 고유 도구·persisted reasoning·네이티브 multi-agent 동작을 온전히 보존해야 할 때
• 비밀정보, 권한 변경, 배포, 삭제처럼 중간 변환 계층의 실패 비용이 클 때
• 벤더의 공식 지원과 엄격한 감사·컴플라이언스 보증이 필수일 때
• tool argument, streaming, thinking field 변환 회귀를 시험할 여력이 없을 때

Anthropic은 게이트웨이 사용 자체는 문서화하지만, 제3자 게이트웨이를 보증·감사하지 않고 비Claude 모델 라우팅을 지원하지 않는다고 밝힙니다. 또한 Claude Code가 발전할 때 게이트웨이가 새 필드를 전달하지 못하면 기능이 깨질 수 있다고 경고합니다. (Anthropic, Other Large Language Model(LLM) gateways, 2026-08-07 확인)

핵심 요약: CCR은 모델 선택과 관측성을 높이는 유용한 오픈소스이지만, 동시에 직접 운영해야 하는 추가 인프라입니다.

Part 2. 안전한 파일럿 — 기존 Claude와 API 과금 경로를 분리하십시오

설치는 간단합니다. CLI 기준 Node.js 22 이상에서 다음 두 명령으로 시작할 수 있습니다.

<span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="ex">npm</span> install <span class="at">-g</span> @musistudio/claude-code-router</span>
<span id="cb1-2"><a href="#cb1-2" aria-hidden="true" tabindex="-1"></a><span class="ex">ccr</span> ui</span>

중요한 것은 설치보다 격리와 인증 확인입니다.

1. Providers에서 로컬 Codex ChatGPT 로그인을 가져와 Codex API 공급자를 만듭니다.
2. OpenAI Platform API Key 공급자와 그쪽으로 향하는 failure fallback은 비활성화합니다.
3. Claude Code Agent Profile을 만들고 적용 범위를 CCR에서 열 때만으로 제한합니다.
4. 기본 모델을 Codex API/gpt-5.6-sol로 지정합니다.
5. 실제 272K와 맞도록 격리 프로필에 CLAUDE_CODE_MAX_CONTEXT_<wbr>TOKENS=272000을 적용합니다.
6. 연결 후 resolved provider·model·status·quota를 확인하고 요청 본문 로깅은 검증 뒤 끕니다.

Claude Code의 ANTHROPIC_BASE_URL은 요청 목적지를 바꿀 뿐, 스스로 모델이나 프로토콜을 변환하지 않습니다. (Anthropic, Model configuration, 2026-08-07 확인) 실제 변환에는 CCR 같은 게이트웨이가 필요합니다.

OpenAI는 ChatGPT 로그인을 구독 접근, API Key 로그인을 종량 접근으로 구분합니다. (OpenAI, Authentication, 2026-08-07 확인) 따라서 Claude Code 화면의 API Usage Billing이나 CCR의 달러 환산치만 보지 말고, upstream·인증 원천·공급자·fallback·Primary quota를 함께 확인해야 합니다.

핵심 요약: Claude 기본 프로필은 보존하고, CCR 격리 프로필에는 구독 인증 하나만 연결해야 롤백과 과금 판정이 명확해집니다.

Part 3. 실제 프로젝트 시나리오 — 자주 반복되는 일곱 장면으로 시험했습니다

벤치마크는 코딩 퍼즐이 아니라 필자의 실제 프로젝트에서 자주 반복되는 작업을 재현했습니다. 저장소 탐색, 규칙 확인, 장문 문서, 원인 분석, dirty tree, 반복 대화로 구성한 7개 시나리오 쌍·18회 유효 CLI 호출입니다.

시나리오 A — 보호 규칙이 있는 저장소 정리

[pm] clean docs apply
현재 dirty tree에서 문서 정리 범위, 보호 파일, 소유권 충돌을 확인하고
실행 가능 여부와 근거를 제시하라. 실제 변경은 하지 마라.

이 유형은 규칙·registry·보호 절차를 빠르게 찾는 것이 먼저입니다. CCR이 초동 탐색에 유리했지만 governance 변경으로 이어진다면 순정 Codex의 재검토가 필요했습니다.

시나리오 B — “검사 0건, 성공 종료”가 발생한 장애 RCA

과거 수정 이력을 기준으로 장애를 재현하고
원인→수정→검증의 인과를 증명하라.
핵심 수정 밖의 잔여 fail-open도 찾아라.

양쪽 모두 핵심 위험을 찾았지만 순정 Codex는 API 실패가 검사 0건·exit 0으로 끝나는 동작을 직접 재현하고 추가 fixture 오류를 발견했습니다. 실제 수정 전 assurance가 필요한 대표 사례입니다.

시나리오 C — 871줄 설계와 계획의 장문 추적성

설계의 요구사항이 실행계획에 빠짐없이 반영됐는지 추적하고
누락, 충돌, 제거 목표와 실행 전제의 자기모순을 근거 위치와 함께 제시하라.

CCR은 빠르게 공통 불일치를 정리했고, 순정 Codex는 계획 내부의 추가 자기모순을 찾았습니다. 긴 문서를 처음부터 두 번 읽히기보다 CCR이 gap map을 만들고 Codex가 고위험 gap만 공격하는 편이 효율적입니다.

시나리오 D — 수백 개 변경이 섞인 Git closeout

현재 변경을 작업 묶음별로 분류하고
사용자 소유 변경, governance 파일, 민감정보 가능성을 점검하라.
안전한 커밋 경계를 제시하되 stage나 commit은 하지 마라.

두 경로 모두 즉시 commit을 거부했습니다. 이 장면에서는 속도보다 사용자 변경 보존과 사람 승인으로 이어지는 판단이 중요합니다.

핵심 요약: 문서 탐색은 CCR이 빨랐고, RCA·장문 모순·Git 경계처럼 실패 비용이 큰 장면은 Codex의 추가 검증이 값을 만들었습니다.

Part 4. 평가지표 공개 — 완료시간만으로 승자를 정하지 않았습니다

두 경로는 모델 gpt-5.6-sol, 추론 강도 xhigh, 컨텍스트 메타데이터 272,000, 같은 작업공간, 읽기 전용 권한으로 맞췄습니다. 웹과 하위 에이전트는 금지했습니다. 반면 시스템 프롬프트·도구 루프·캐시 정책은 제품 사용성의 일부이므로 그대로 두었습니다.

정량 지표

품질 100점 루브릭

평가는 동일 루브릭으로 수행했지만 단일 평가자가 실행 경로를 아는 상태에서 채점했습니다. 따라서 2.4점 차이는 방향성 증거이지 통계적 우월성 선언이 아닙니다. 시나리오별 n=1이며 전체 원시 출력과 점수 근거를 보존해 사후 재검토가 가능하도록 했습니다.

핵심 요약: 이번 평가는 속도·성공·연속성·토큰·품질을 함께 봤으며, 단일 평가자와 n=1이라는 한계도 결과에 포함했습니다.

Part 5. 종합 결과 — CCR은 속도, Codex는 고위험 증적에서 앞섰습니다

표시된 평균 두 개를 빼면 2.5점처럼 보이지만, 원점수 합계 차이는 17/7 = 2.43점입니다. 본문과 제목의 2.4점은 이 원점수 차이를 소수 첫째 자리에서 반올림한 값입니다.

순정 Codex가 더 빨랐던 것은 25.6초의 짧은 브리프 한 건뿐입니다. 도구 기반 6건에서는 CCR이 1.18~3.53배 빨랐습니다. 반대로 Codex는 RCA의 fail-open과 장문 계획의 자기모순처럼 결정 비용이 큰 추가 결함을 찾았습니다.

토큰 합계는 직접 비용 비교에 사용할 수 없습니다. 누적 처리 입력은 CCR 132만, Codex 357만이었지만 비캐시 입력은 CCR 108만, Codex 55만이었습니다. 출력은 CCR 47,636, Codex 73,575토큰이었습니다. 두 클라이언트의 캐시·reasoning 회계가 달라 “토큰이 적은 쪽이 쿼터도 적게 쓴다”고 단정할 수 없습니다.

핵심 요약: 생산성 기준에서는 CCR, 결함 누락 비용 기준에서는 Codex가 우세했으며 성공률은 같았습니다.

Claude(CCR) 모드와 Codex 모드 — 장단점과 권장 역할

Claude(CCR)를 우선할 때

• 여러 문서와 규칙을 훑어 빠르게 gap map을 만들 때
• 회의 메모, 보고서 감사, PM 라우팅처럼 사람이 최종 검토할 때
• 같은 Claude Code 작업 습관을 유지하며 모델을 실험할 때
• background·think·long-context 작업을 모델별로 분리하고 싶을 때

Codex를 우선할 때

• 실패를 실제 명령과 테스트로 재현해야 할 때
• 파일 쓰기, Git, 권한, 보안, 배포, 삭제가 포함될 때
• OpenAI 고유 기능과 정확한 tool semantics가 중요할 때
• 장기·고가치 작업에서 중간 변환 계층을 제거하고 싶을 때

혼합할 때의 handoff 계약

전체 대화 대신 목표, 확인 사실, 미해결 위험, 근거 위치, 검증 명령 다섯 블록만 넘깁니다. CCR에서 만든 초안을 Codex가 전부 다시 만드는 것이 아니라, 손실 가능성이 큰 finding만 적대적으로 검토합니다.

핵심 요약: Claude(CCR)는 front door, Codex는 assurance gate이며, 둘의 연결점은 대화 복사가 아니라 증거 중심 handoff입니다.

과금·컨텍스트·보안 — 상태바 하나로 판단하지 마십시오

유효 CCR 시험의 API-equivalent 합계는 $6.73이었지만 실제 청구액이 아닙니다. 두 경로 모두 ChatGPT/Codex 구독 Primary quota를 사용했고 Platform API Key 공급자는 사용하지 않았습니다. OpenAI 요금 문서도 구독 로컬 메시지와 API Key 종량 사용을 별도 경로로 구분합니다. (OpenAI, Pricing, 2026-08-07 확인)

두 경로의 모델 메타데이터는 272,000토큰이었습니다. OpenAI도 Sol·Terra·Luna의 컨텍스트 창을 272,000으로 정정했습니다. (OpenAI, Changelog, 2026-08-07 확인) 다만 이번 시험은 200K+ active context와 compact 후 요구사항 보존을 검증하지 않았습니다.

첫 “순정” 파일럿은 전역 Codex 설정이 CCR provider를 가리켜 무효 처리했습니다. 유효 순정 시험은 codex exec --ignore-user-config로 개인 설정을 배제했습니다. OpenAI 비대화형 문서는 이 옵션과 JSON Lines 계측을 공식 지원합니다. (OpenAI, Non-interactive mode, 2026-08-07 확인)

CCR은 request·response·tool call을 관측할 수 있는 만큼 로그가 새로운 민감정보 표면이 됩니다. 게이트웨이는 loopback에만 두고, 요청 본문 로그는 진단할 때만 켜며, provider fallback과 credential pool은 최소화해야 합니다.

핵심 요약: 비용은 인증 경로로, 컨텍스트는 공식 메타데이터와 경계시험으로, 보안은 게이트웨이·로그·fallback 구성으로 검증해야 합니다.

추천 사용 가이드 — 실패 비용으로 경로를 정하십시오

즉시 중단해야 할 신호도 명확합니다. 의도하지 않은 provider나 API Key fallback이 선택되거나, 모델 메타데이터가 272K와 다르거나, tool argument·streaming·hook·MCP 동작이 순정과 달라지거나, 요청 본문이 로그에 남는다면 CCR 경로를 멈추고 순정으로 복귀해야 합니다.

핵심 요약: 빠른 작업은 CCR에서 시작하되, 되돌리기 어렵거나 네이티브 의미 보존이 중요한 순간 Codex로 승격하십시오.

Known Limitations — 이 결과는 운영 가설이지 보편 법칙이 아닙니다

• 시나리오별 n=1이라 응답 변동과 서버 부하를 분리하지 못했습니다.
• 읽기 전용 시험으로 편집 정확도, 테스트 통과율, rollback, commit 품질은 미측정입니다.
• 272K 표시는 검증했지만 200K+ active context와 auto-compact 후 보존은 미시험입니다.
• 품질은 단일·비블라인드 평가자가 채점했습니다.
• 한 Git 시나리오는 실행 사이 dirty tree가 변해 시간 비교 공정성이 낮았습니다.
• CCR의 Codex 로그인 가져오기는 커뮤니티 구현이며 OpenAI·Anthropic의 공식 교차제품 통합이 아닙니다.
• 오픈소스 CCR과 Claude Code가 빠르게 변경되므로 버전 상승 뒤 회귀시험이 필요합니다.

반대 해석도 가능합니다. Codex의 추가 시간은 비효율이 아니라 더 많은 검증 비용일 수 있고, CCR의 속도는 모델이 아닌 Claude Code 도구 루프나 캐시 회계의 결과일 수 있습니다. 후속 시험은 격리 worktree의 실제 write path 5쌍과 200K+ compact 경계 2쌍으로 설계하는 편이 적절합니다.

핵심 요약: 현재 결과는 필자의 복합 PM·문서·개발 패턴에 대한 1차 근거이며, 실제 쓰기와 장기 컨텍스트 검증이 남았습니다.

FAQ — 가장 많이 오해하는 다섯 가지

1. Claude(CCR)가 GPT보다 빨랐다는 뜻인가요?

아닙니다. Claude(CCR) 경로의 모델도 GPT-5.6 Sol입니다. 같은 모델을 서로 다른 클라이언트·도구 루프에서 비교했습니다.

2. CCR은 무료 서비스인가요?

CCR 소프트웨어는 MIT 오픈소스지만 연결한 모델·API·구독 비용은 별도입니다. 오픈소스와 무료 추론을 혼동하면 안 됩니다.

3. $6.73이 API로 청구됐나요?

아닙니다. API-equivalent 환산치입니다. 유효 시험은 Codex 구독 Primary quota를 사용했고 Platform API Key는 사용하지 않았습니다.

4. 272K를 설정하면 compact 문제가 해결되나요?

조기 200K 가정을 교정할 수는 있지만 장기 안정성을 보장하지 않습니다. 실제 200K+ 세션과 compact 이후 요구사항 보존을 별도로 시험해야 합니다.

5. 하나만 기본값으로 고른다면 무엇이 낫나요?

사람이 검토하는 문서·분석 비중이 높으면 Claude(CCR), 코드 쓰기·테스트·보안·배포 비중이 높으면 Codex가 적합합니다. 혼합할 수 있다면 위험도 기반 승격이 더 낫습니다.

핵심 요약: CCR의 오픈소스성, 모델 비용, Claude 모델 여부, 컨텍스트 안정성은 서로 다른 질문입니다.

다음 액션 — 이번 주 업무 세 가지로 직접 검증하십시오

오늘 할 일 세 가지를 빠른 탐색, 고위험 검증, 되돌리기 어려운 실행으로 나누십시오. 각각 Claude(CCR), CCR 뒤 Codex challenger, Codex와 사람 승인으로 시작합니다.

일주일 동안 완료시간, 수동 개입, 재작업, 놓친 결함, Primary quota 전후 변화만 기록하십시오. 전체 작업을 매번 A/B로 중복 실행할 필요는 없습니다. 자신의 실패 비용이 급격히 올라가는 경계를 찾으면 됩니다.

핵심 요약: 도구 선택의 정답은 평균 점수가 아니라 내 프로젝트에서 재작업과 실패 비용이 바뀌는 지점에 있습니다.

참고 자료

• Claude Code Router 공식 GitHub — 기능·설치·MIT License
• Anthropic Model configuration — custom model과 gateway 설정
• Anthropic Other LLM gateways — 지원 범위와 운영 책임
• OpenAI Authentication — ChatGPT 구독과 API Key 인증
• OpenAI Pricing — GPT-5.6 구독 사용량과 API Key 경로
• OpenAI Changelog — GPT-5.6 Sol·Terra·Luna 272K 정정
• OpenAI Non-interactive mode — JSONL·sandbox·사용자 설정 격리

핵심 요약: 외부 제품 사실은 공식 저장소와 양사 공식 문서로, 성능 수치는 2026-08-07 로컬 실측 데이터로 분리해 검증했습니다.