클로드코드 코덱스 조합법 2026: Opus 5.5·GPT-6 Sol 이후 계획과 실행 다시 나누기
퀀텀점프클럽 정상록9 min read10 viewsFree Resource
PDF · Free
클로드코드와 코덱스, 같이 쓰면 뭐가 달라질까 — 비개발자를 위한 쉬운 가이드
Get the practical guide first, before diving into the full article.
클로드코드 코덱스 조합법 2026: Opus 5.5·GPT-6 Sol 이후 계획과 실행 다시 나누기
클로드코드 코덱스 조합의 답은 어느 쪽에 계획을 두느냐가 아닙니다. 2026-09-22 Opus 5.5와 GPT-6 Sol 출시로 근거가 바뀌었고, 지금 손해를 만드는 건 모델이 아니라 버전과 기본값입니다.
계획은 클로드, 실행은 코덱스라는 공식, 지금도 맞을까요?
클로드코드 코덱스 조합을 두고 흔히 쓰는 이 공식은 틀리지 않았습니다. 다만 근거가 바뀌었어요. 예전에는 "어느 모델이 더 똑똑한가"가 근거였다면, 지금은 "어느 버전이 켜져 있는가, 한도가 얼마나 남았는가, 누가 검증하는가"가 근거입니다. "요즘도 계획은 클로드에, 실행은 코덱스에 맡기면 되나요?" 이런 질문을 자주 받습니다. 당연한 궁금증이에요. Opus 5.5와 GPT-6 Sol이 2026-09-22 같은 날 나온 지금, 실측 자료를 기준으로 AI 코딩 조합을 하나씩 다시 짚어보겠습니다.
"40% 쌌다"는 광고, 언제까지 진짜인가요?
가격표부터 볼게요. 입력·출력 기준으로 Claude Opus 5.5는 4달러/20달러, Claude Fable 5.1은 10달러/50달러, GPT-6 Sol은 2달러/10달러, GPT-6 Astra는 10달러/50달러예요(Anthropic·OpenAI 공식 문서 기준, 2026-09-22).
"40% 절감"이란: Anthropic이 밝힌 Opus 5.5의 비용 절감폭으로, 기본 effort(medium)·일반 워크로드 기준에서만 성립하는 수치입니다. 최대 effort로 올리면 이 절감은 사라집니다.
Anthropic이 밝힌 "40% 저렴"에는 기준선이 딱 하나뿐이에요. 기본 effort(medium)·일반 워크로드일 때만 성립하고, 최대 effort로 올리면 절감은 사라지죠. Artificial Analysis가 최대 effort 기준으로 태스크당 비용을 실제로 분해해 봤더니 Opus 5(최대 effort) $5.86에서 Opus 5.5(최대 effort)는 오히려 $5.98로 소폭 올랐습니다. 토큰 사용량이 늘어난 만큼(약 1.6배) 단가 인하와 캐시 할인을 상쇄한 결과예요.
그러니 "막히면 effort를 올리세요"와 "40% 싸졌어요"는 한 문장에 같이 쓸 수 없는 말이에요. effort를 올리는 순간 그 40%는 없어지거든요. 실무 기준은 간단해요. 기본값(medium)으로 굴러가는 일상 작업은 확실히 싸지고, 막혀서 effort를 올려야 하는 어려운 작업은 가격 차이가 거의 없어요.
태스크당 비용 숫자는 세 종류가 있고, 기준선이 다 다릅니다. Terminal-Bench 4.0 태스크당 총비용은 Opus 5.5(medium) $2.94, GPT-6 Astra(high) $7.21인데 점수는 57.6% 대 57.9%로 거의 같아요. Artificial Analysis 지능지수 실행 기준으로는 Opus 5.5(medium) $1.34, Astra(high) $1.76이고요. 그런데 출력 토큰 지출만 놓고 max 기준으로 재면 Opus 5.5 $2.38, Astra $1.35로 이 기준선에서는 Astra가 더 쌉니다. 세 숫자를 하나로 뭉뚱그리면 안 되는 이유가 여기 있어요.
벤치마크 숫자를 있는 그대로 믿어도 될까요?
아니요, 조건을 꼭 봐야 해요. Anthropic 자체 측정에서 Opus 5.5는 Terminal-Bench 4.0에서 66.4%(xhigh), GPT-6 Astra는 57.9%(high)를 받았습니다. effort 설정 자체가 다른 비교죠. 그런데 Artificial Analysis가 조건을 맞춰 독립 측정했더니 두 모델 다 59.6%로 동률이었어요. "Opus 5.5가 8.5포인트 앞선다"는 서술은 이래서 성립하지 않습니다. 정확히 말하면 같은 조건 독립 측정에서는 동률이고, 갈리는 건 비용이에요.
ARC-AGI-3도 조건을 빼고 인용하면 안 되는 숫자입니다. 전용 Provider Adapter 하네스에서는 99.9%가 나왔지만, 제공자 중립 표준 하네스로는 62.7%예요. ARC Prize에 따르면 표준 하네스 실행에는 컴퓨트 비용만 2만 6천 달러 이상이 들었고요. 참고로 Opus 5.5의 ARC-AGI-3 점수는 아직 없어요. 출시 전 평가가 끝나지 못했고 API 요청이 리버스 엔지니어링으로 오분류돼 차단된 탓이죠. 측정이 안 된 것을 낮은 점수로 읽으면 곤란합니다.
Astra가 앞서는 항목도 분명히 있어요. AutomationBench 41.4%(Opus 5.5 40.0%), Terminal-Bench-Science 0.1에서 64.6%(Opus 5.5 58.7%), Frontend Code Arena 1위, FrontierMath Tier 4 97.6%가 전부 Astra 몫이죠. 이런 항목을 빼고 "Opus 5.5가 전반적으로 앞선다"고 쓰면 편향된 요약이 돼요.
GPT-6 Sol은 "더 똑똑해진 모델"이 아니에요. DeepSWE는 68.8%로 GPT-5.6 Sol의 72.7%보다 낮고, OSWorld 2.0도 64.4%로 66.2%보다 낮습니다. OpenAI가 밝힌 "실수 약 절반 감소"는 GPT-5.6 Sol과 비교한 수치예요. 능력 천장이 올라간 게 아니라 같은 비용에서 더 낫다는 쪽으로 곡선이 옮겨갔다고 보는 게 정확하죠.
Anthropic이 발표한 68만 라인 마이그레이션 하루 완료, 20만 라인 감사 3시간 완료 같은 사례는 인상적이지만 벤더가 보고한 초기 테스터 사례고 독립 재현은 아직 없어요. 고객명도 공개되지 않았고요. 다만 Deloitte가 제3자로 측정한 결과는 조합 설계에 바로 쓸 수 있습니다. 최저 effort Opus 5.5가 알려진 리뷰 버그의 72%를 검출했고, high effort Opus 5는 56%를 검출했어요. 리뷰 용도라면 effort를 굳이 올릴 필요가 없다는 근거죠.
버전 하나 잘못 맞추면 이만큼 손해 봅니다
가장 흔한 실패는 모델 선택이 아니라 버전이에요. Claude Code는 2.1.280 이상에서만 Opus 5.5가 켜집니다. 미만 버전에서 모델명을 지정하면 400 에러가 나거나 "Opus 5.5 (disabled)"로 표시돼요. claude --version으로 확인하고 claude update로 올리면 되는데, Homebrew 사용자는 이 명령으로 해결되지 않습니다. 2026-09-23 기준 claude-code cask는 2.1.267, claude-code@latest는 2.1.278로 둘 다 요구치에 못 미치고 자동 갱신도 안 돼요. 공식 npm 패키지로 옮기는 수밖에 없죠.
Codex 쪽도 비슷한 함정이 있어요. GPT-6 Sol은 Codex CLI 0.154.0 모델 목록에 아예 없었고, rust-v0.157.0-alpha.10 프리릴리스에서야 추가됐습니다. 정식 릴리스가 아니라는 뜻이죠. 원격 Linux 호스트에서는 Sol·Luna가 안 보이고 기본이 gpt-6-astra로 잡힌 사례도 보고됐는데, 같은 Pro 계정 Windows에서는 정상 선택됐다고 해요. GPT-6 Astra는 사이버보안 Critical 등급으로 분류돼 엔터프라이즈 기본값이 비활성이니 관리자가 직접 켜야 쓸 수 있고요. OpenAI는 2026년 10월 14일 전까지 워크스페이스 기본값·저장된 모델 설정·예약 작업의 GPT-5.5를 Sol이나 Luna로 바꾸라고 권고했습니다.
실제 사용자들은 방향을 어느 쪽으로 잡을까요?
방향은 하나로 정해져 있지 않아요. Gokul Rajaram의 "브레인스토밍·계획은 클로드, 리뷰·실행은 코덱스"는 지금도 자주 인용되는데, 이 발언이 가리키는 모델은 Opus 4.7/4.8과 GPT-5.5예요. 한 세대 전 이야기를 지금 조합 권고로 그대로 옮기면 곤란하죠.
실제로 반대 방향을 쓰는 사람도 많습니다. Nathan Onn은 Codex가 95% 확신이 설 때까지 되묻게 해서 계획을 만들고, 그 계획을 Claude Code로 구현한 뒤 git diff를 다시 Codex에 돌려 리뷰시켜요. code_workflow 저장소는 Codex를 플래너, Claude Code를 실행자로 둡니다. 공통점은 방향이 아니라 계획자와 실행자를 분리하고, 계획을 쓰지 않은 쪽이 반대 벤더 리뷰어를 맡는 구조예요. X 이용자 nex_ify가 공개한 스킬(별 약 2.1k)도 같은 원리예요. 한 모델이 계획을 쓰면 다른 모델이 근거로 감사하고, 계획을 쓰지 않은 쪽이 구현하고, 새 세션이 검수합니다.
Every 팀도 전원이 한쪽으로 몰리지 않았어요. Kieran Klaassen은 Fable 5.1을 밀어내고 Opus 5.5를 데일리 드라이버로 바꿨고, Tyler Nishida는 "대여섯 번 입이 벌어졌다"고 적었습니다. 그런데 Dan Shipper는 자신에게는 여전히 Codex가 더 나은 하네스라고 밝혔어요. 팀 전원이 갈아탄 게 아니죠.
한도(쿼터)는 코덱스가 먼저 바닥난다는 쪽으로 증언이 모입니다. X 이용자 Mr_Salio는 같은 가격 계정, 같은 작업에서 Codex(Sol Medium)는 5시간 한도의 94%를, Claude(Opus 5 Max)는 50%를 썼다고 보고했어요. HN 이용자 paulmist도 같은 방향이에요. Codex가 medium·low를 50만 토큰으로 제한해도 CLI 한 창으로 23일이면 소진되는데 Claude Code는 23창으로 4~5일 간다고 밝혔습니다. HN 이용자 impulser_는 200달러 Claude 플랜을 Opus 5로 100억 토큰 써서 다 썼는데 Codex 계정 2개는 50억 토큰도 못 채웠다고 했고요. HN 이용자 cameronh90은 다르게 봐요. "Codex는 코드베이스만 읽으며 토큰을 태우는 경향이 덜하다"고 적었고, 비용 환산 토큰은 훨씬 적어도 실제 처리되는 작업량은 비슷하다고 설명했습니다. 정리하면 소진 방향을 말한 네 건은 모두 코덱스가 먼저 찬다는 쪽이고, 반대 방향 증언은 확인되지 않았어요. 다투는 지점은 방향이 아니라 "토큰을 빨리 태우는 것이 곧 일을 많이 한 것이냐"입니다.
실사용 경고도 하나 짚고 갈게요. HN 이용자 solsson은 2026-09-23, 첫 Opus 5.5 세션이 "멈춘 cat을 중지하려고" 이름에 cat이 들어간 프로세스를 전부 죽였다고 보고했어요. effort high, auto mode 상태였다는 점이 핵심입니다. 자동 실행 권한을 넓게 줄수록 이런 사고가 날 여지도 커지죠.
그래서 오늘부터 어떻게 나눠 써야 할까요?
상황별로 나누면 이래요.
| 상황 | 권장 조합 | 근거 |
|---|---|---|
| 일상 코딩 기본값 | Claude Code + Opus 5.5 medium | Terminal-Bench medium 57.6%를 태스크당 $2.94에, 40% 절감 구간 |
| 대규모 리팩터·마이그레이션 | Opus 5.5 | 벤더 사례(68만·20만 라인), 단 독립 재현 없음 |
| 명세가 확정된 병렬 구현 | Codex + GPT-6 Sol | $2/$10, 반복 작업에 유리 |
| 프론트·UI, 컴퓨터 조작 | GPT-6 Astra | Frontend Code Arena 1위, AutomationBench 41.4% |
| 코드 리뷰 | 실행한 쪽의 반대 벤더 | 자기 검수는 구멍을 못 봄, Deloitte 기준 최저 effort로도 충분 |
| 승인된 보안 연구 | GPT-6 Astra | ExploitBench 전 항목 성공 (Opus 5.5는 사이버 요청이 Opus 4.8로 재라우팅) |
실행 팁 하나 더요. X 이용자 Voxyz_ai가 공유한 방법인데, 규칙을 AGENTS.md 한 곳에 적어두는 거예요. 클로드코드도 AGENTS.md를 읽으니 작은 수정이 큰 작업으로 번지는 걸 막는 스코프 규칙을 벤더 상관없이 같은 파일에서 관리할 수 있어요.
마지막으로 하나만 더요. HN 이용자 knapcio는 같은 모델을 실제 태스크 10개로 벤치마크했더니 완료 시간이 실행마다 최대 50%까지 차이 났다고 밝혔어요. 한두 번 돌려보고 결론 내지 말고, 자기 워크로드로 여러 번 재보는 편이 어떤 벤치마크 표보다 정확해요.
마무리
클로드코드 코덱스 조합에서 기억할 건 세 가지입니다. 버전부터 확인하고, effort는 필요할 때만 올리고, 리뷰는 반대 벤더에 맡기세요. 우리 팀 워크플로에 맞는지는 위 표를 두고 하나씩 대조해 보셔도 충분해요. 판단에 필요한 근거는 이미 다 적어 뒀습니다.
관련 글
자주 묻는 질문
Opus 5.5가 갑자기 안 보이는데 왜 그런가요?
Claude Code 버전이 2.1.280 미만이면 Opus 5.5가 비활성화됩니다. claude --version으로 확인하고 claude update로 올리면 되지만, Homebrew 배포판(claude-code cask 2.1.267, claude-code@latest 2.1.278)은 2026-09-23 기준 요구치에 못 미치고 자동 갱신도 안 되니 공식 npm 패키지로 전환하는 게 안전해요.
GPT-6 Sol을 코덱스 CLI에서 못 고르는 이유는요?
정식 릴리스인 Codex CLI 0.154.0의 모델 목록에는 GPT-6 Sol이 없었어요. rust-v0.157.0-alpha.10 프리릴리스에서 추가됐지만 정식 버전이 아니라서, 안정성이 중요한 작업이라면 정식 릴리스에 반영될 때까지 기다리는 편이 안전합니다.
코드 리뷰는 꼭 반대 벤더 모델에 맡겨야 하나요?
같은 모델이 쓴 코드를 같은 모델이 다시 검수하면 자기가 만든 맹점을 그대로 놓칠 가능성이 커요. 별개로 Deloitte가 제3자로 측정했을 때 최저 effort Opus 5.5가 알려진 리뷰 버그의 72%를 검출한 반면 high effort Opus 5는 56%에 그쳤어요. 이건 같은 벤더 안에서 effort를 비교한 결과라 반대 벤더 리뷰의 효과를 잰 건 아니고, 리뷰 용도라면 effort를 굳이 올릴 필요가 없다는 근거로 읽으시면 됩니다.
Opus 5.5를 쓰면 항상 40% 저렴해지나요?
아니에요. Anthropic이 밝힌 40% 절감은 기본 effort(medium)·일반 워크로드 기준일 때만 성립합니다. Artificial Analysis가 최대 effort로 태스크당 비용을 분해했더니 Opus 5 $5.86에서 Opus 5.5는 오히려 $5.98로 소폭 올랐어요. effort를 올려야 하는 어려운 작업에서는 절감을 기대하기 어렵습니다.
GPT-6 Astra는 보안 작업에 그냥 써도 되나요?
OpenAI Preparedness Framework에서 사이버보안 Critical 등급으로 분류돼 엔터프라이즈 기본값이 비활성 상태예요. 관리자가 직접 켜야 쓸 수 있고, ExploitBench 전 항목 성공·ExploitGym 42.4% 같은 능력치는 승인된 보안 연구 용도를 전제로 한 수치입니다.
한도(쿼터)는 클로드코드와 코덱스 중 어느 쪽이 더 빨리 줄어드나요?
모은 증언은 코덱스 쪽으로 기울어요. X 이용자 Mr_Salio는 같은 가격 계정에서 코덱스(Sol Medium)가 5시간 한도의 94%, 클로드(Opus 5 Max)는 50%를 썼다고 보고했고, HN 이용자 paulmist도 코덱스는 23일, 클로드코드는 45일 간다고 밝혔습니다. 소진 방향을 말한 네 건이 모두 같은 쪽이었어요. 다만 HN 이용자 cameronh90은 코덱스가 토큰을 덜 쓰고도 처리하는 일의 양은 비슷하다고 지적합니다. 소진 속도와 생산성은 다른 축이니, 자신의 실제 워크로드로 며칠 재보는 편이 벤치마크 수치 하나보다 믿을 만해요.
