Claude Code vs Codex 논쟁이 모델 IQ에 관한 것이라고 생각했지만, 단 하나의 프롬프트가 세션의 53%를 소비하는 것을 본 후

저는 Claude Code vs Codex 논쟁에 들어가면서 평소와 같은 답변을 예상했습니다. 모델의 품질을 비교하고, 가장 똑똑한 것을 선택한 뒤, 다음으로 넘어가는 것이죠. 하지만 제가 발견한 것은 달랐습니다. 가장 유용한 Reddit 스레드들은 사실 지능에 관한 것이 아니었습니다. 그것은 에이전트(Agent)를 실제 코딩 워크플로우(Workflow) 내에서 몇 시간 동안 실행할 때 어떤 일이 발생하는지에 관한 것이었습니다. 저장소(Repo)의 절반을 읽고, 패치(Patch)를 재시도하며, 메모리 파일을 계속 끌고 가고, 실제 작업이 시작되기도 전에 컨텍스트(Context)나 할당량(Quota)을 조용히 태워버리는 일 말입니다.

한 r/openclaw 스레드가 저에게 이 모든 것을 깨닫게 해주었습니다. 한 사용자는 자신의 첫 번째 Claude 요청이 Pro 세션의 53%를 소비했다고 말했습니다. 두 번의 요청이 더 이어지자 사용량은 76%까지 치솟았습니다. 작업을 완료하는 데 나머지 23%가 소요되었습니다. 이것은 벤치마크(Benchmark) 문제가 아닙니다. 이것은 운영(Operations) 문제입니다.

'저렴함'이 더 이상 저렴하지 않게 되는 순간

제가 이 문제를 생각하는 방식을 바꾼 스레드는 다음과 같습니다: r/openclaw: https://reddit.com/r/openclaw/comments/1tce1xn/agents_and_models_and_and_and/

그 사용자는 Claude가 똑똑한지를 묻고 있는 것이 아니었습니다. 그들은 기본적으로 이렇게 묻고 있었습니다: '사람들은 어떻게 계량기를 계속 지켜보지 않고도 이런 자율 코딩 루프(Autonomous coding loops)를 실행하고 있는가?' 이것이 훨씬 더 나은 질문입니다.

만약 여러분이 OpenClaw, Claude Code, Codex 또는 기타 커스텀 에이전트 하네스(Agent harness)를 사용하고 있다면, 여러분의 비용은 더 이상 깔끔한 프롬프트/응답(Prompt/Response) 모델에 의해 결정되지 않습니다. 비용은 다음 요소들에 의해 결정됩니다:

• 첫 번째 도구 호출(Tool call) 전에 얼마나 많은 컨텍스트가 로드되는가
• 에이전트가 얼마나 자주 재시도하는가
• 단계 사이에 얼마나 많은 상태(State)가 다시 전송되는가
• 오케스트레이터(Orchestrator)가 메모리를 얼마나 공격적으로 요약하고 재수화(Rehydrate)하는가
• 여러분의 가격 모델이 오래 지속되는 루프에 대해 페널티를 부여하는가

이것이 바로 '최고의 코딩 모델'에 대한 담론이 빠르게 이상해지는 이유입니다. 사람들은 자신들이 두뇌를 비교하고 있다고 생각하지만, 실제로는 전체 운영 환경(Operating environments)을 비교하고 있는 것입니다.

진정한 실패 모드: 작업 시작 전의 컨텍스트 팽창 (Context bloat)

그 스레드에서 얻은 가장 좋은 조언은 여섯 단어였습니다: '컨텍스트, 컨텍스트, 컨텍스트! /new /compact를 자주 사용하라!'

이것은 당연하게 들릴 수도 있습니다. 하지만 이것이 게임의 전부입니다.

여러 OpenClaw 토론 전반에 걸쳐 불만 사항은 매우 일관적입니다: 너무 일찍 로드되는 워크스페이스 파일(workspace files), 메모리 파일과 노트가 첫 번째 턴을 비대하게 만듦, 기본 오케스트레이션(orchestration) 레이어에 의해 컨텍스트로 밀려 들어가는 AGENTS.md, 너무 많은 상태(state)를 다시 전송함, 광범위한 파일 포함으로 인해 에이전트가 모든 것을 검사하게 만듦, 세션 제한으로 인해 일반적인 에이전트 동작이 예산 관리 연습처럼 변함. 한 댓글 작성자는 OpenClaw가 "첫 메시지를 입력하기도 전에 엄청난 양의 컨텍스트를 소비할 수 있다"라고 말했습니다. 이 문장은 모든 에이전트 엔지니어(agent engineer)가 멈춰 서서 자신의 설정을 점검하게 만들어야 합니다. Claude, Codex, 그리고 OpenClaw는 단 하나의 축에서 경쟁하는 것이 아닙니다. 다음은 실무적인 버전입니다.

옵션	실무에서 실제로 중요한 점
Claude 구독 또는 API를 통한 Claude Code	어려운 엔지니어링 작업에서 강력한 코딩 품질을 보여주지만, 컨텍스트(context)가 관리되지 않으면 긴 루프(loops)가 빠르게 세션 민감성을 유발할 수 있음
OpenAI Codex / GPT-5.4 Codex 설정	반복적인 코딩 루프에 대해 더 관대한 것처럼 느껴지지만, 여전히 한계가 존재하며 동작은 주변 하네스(harness)에 크게 의존함
OpenClaw 스타일의 오케스트레이션 (orchestration)	자율적인 워크플로우(workflows)에 매우 좋지만, 제약하지 않으면 메모리, 워크스페이스 로딩, 재시도(retries), 도구 채팅(tool chatter)을 통해 토큰 소모를 증폭시킬 수 있음

마지막 행이 중요합니다. OpenClaw 그 자체는 비싸지 않습니다. 그것은 증폭기(amplifier)입니다. 당신의 스택(stack)이 절제되어 있다면, 그것은 좋은 라우팅(routing)과 깨끗한 컨텍스트 경계를 증폭시킵니다. 당신의 스택이 엉성하다면, 그것은 낭비를 증폭시킵니다. Reddit에서 가장 솔직한 의견은 기본적으로 사후 분석(postmortem)이었습니다. 다른 스레드는 그 어떤 제품 페이지보다 더 잘 설명했습니다: r/openclaw: https://reddit.com/r/openclaw/comments/1tcyqda/how_good_is_openclaw_at_orchestrating_codex_and/

한 사용자는 다음과 같이 썼습니다: "그것은 동시에 좋기도 하고 나쁘기도 합니다. 나쁜 점들을 어떻게 해결했냐면, 코딩을 위해 특별히 설계된 스킬(skills)을 구축하여 에이전트에게 내가 원하는 특정 사항에 대한 컨텍스트를 제공했습니다. 세련되지는 않았지만 유용합니다."

그들의 해결책은 "모델을 바꾸는 것"이 아니었습니다. 그들의 해결책은 컨텍스트 경계(context boundary)를 좁히는 것이었습니다. 이는 제가 실무에서 계속 보고 있는 것과 일치합니다.

최고의 결과를 얻고 있는 팀들은 단순히 Claude나 Codex 중 하나를 선택하는 것이 아닙니다. 그들은 각 모델이 무엇을, 언제 보게 될지를 설계하고 있습니다. 비싼 실수: 하나의 모델에게 모든 것을 요청하기. 여전히 많은 팀이 전체 워크플로우(workflow)를 위해 단 하나의 모델만을 원합니다. 레포지토리 스캐닝(Repo scanning), 계획(Planning), 리팩터링(Refactors), 패치 생성(Patch generation), 재시도 루프(Retry loops), 문서화(Documentation), 분류(Triage), 도구 사용(Tool use), 정리(Cleanup). 이는 우아하게 들릴지 모르지만, 대개는 게으른 아키텍처(architecture)입니다. 더 강력한 패턴은 작업 기반 라우팅(task-based routing)입니다. 예를 들어:

• 저렴한 유틸리티 작업을 위한 로컬의 Qwen 또는 GLM
• 빠르고 가벼운 패스(passes)를 위한 Gemini Flash
• 속도와 허용 오차(tolerance)가 필요한 코딩 루프를 위한 GPT-5.4 Codex
• 더 어려운 엔지니어링 판단을 위한 Claude Opus 또는 Claude Sonnet

이것은 우유부단함이 아닙니다. 에이전트 스택(agent stack)을 팬덤(fandom)이 아닌 인프라(infrastructure)처럼 다루는 것입니다.

에이전트가 자율화될 때 비용 문제가 악화되는 이유
이 부분은 모델 논쟁이 이론적인 수준을 벗어나는 지점입니다. 한 Reddit 사용자는 약 3.5개월, 1,300시간, 거의 50억 개의 토큰(tokens), 그리고 약 700달러를 지출한 후 OpenClaw를 포기했다고 말했습니다. 또 다른 게시물은 비전(vision), 서버 관리, 양식 채우기를 포함하는 소프트웨어 숍(software-shop) 워크플로우에 Opus 토큰 비용으로 2,500달러를 사용했다고 언급했습니다. 이것은 "질문을 너무 많이 했다" 수준의 숫자가 아닙니다. "내 워크플로우가 공공요금 고지서가 되어버렸다" 수준의 숫자입니다.

물론 상충되는 보고도 있습니다. 어떤 사용자들은 Codex 제한에 거의 걸리지 않는다고 말하고, 어떤 이들은 며칠 만에 제한에 도달한다고 하며, 어떤 이들은 프리미엄 플랜이 사실상 무제한처럼 느껴진다고 하는 반면, 다른 이들은 에이전트가 유용해지는 바로 그 시점에 한계(ceilings)가 나타난다고 말합니다. 이것은 실제로는 모순되는 것이 아닙니다. 단지 에이전트 경제학(agent economics)이 런타임 동작(runtime behavior)에 매우 민감하다는 것을 의미할 뿐입니다.

개발자들이 IQ에 대해 논쟁하는 대신 측정해야 할 것

실제 엔지니어링 작업을 위해 Claude Code와 Codex를 평가하고 있다면, 리더보드(leaderboard) 스크린샷에 신경 쓰기 전에 다음 다섯 가지를 측정하겠습니다:

1. 첫 번째 턴의 컨텍스트 크기 (First-turn context size)
2. 작업당 평균 재시도 횟수 (Average retry count per task)
3. 성공적인 패치당 도구 호출 볼륨 (Tool call volume per successful patch)
4. 턴 사이에 유지되는 상태 (State carried between turns)
5. 자율 런타임(autonomous runtime) 시간당 비용 또는 할당량 소모 (Cost or quota burn per hour of autonomous runtime)

이것이 해당 설정이 긴 루프(long loops)를 견뎌낼 수 있는지에 대한 실제 그림을 제공합니다. 벤치마크(Benchmarks)는 이를 알려주지 않습니다. 두 시간 동안 방치된 리팩터링(refactor)이 이를 알려줍니다.

월요일에 제가 실제로 할 일

모델 쇼핑(model shopping)이 아니라 컨텍스트 위생(context hygiene)부터 시작하십시오. 만약 당신의 스택에 OpenClaw, Claude CLI, Codex, Ollama 또는 커스텀 오케스트레이터(custom orchestrator)가 포함되어 있다면, 먼저 지루한 것들부터 확인하십시오.

/new /compact cmd openclaw logs --follow ollama list

만약 스택에 Ollama가 있다면, 다음도 확인하십시오: http://localhost:11434/

한 댓글 작성자는 모델이 32k를 지원하더라도 Ollama는 4096 토큰 컨텍스트로 시작할 수 있다고 지적했습니다. 그러한 불일치야말로 팀들이 실제로는 설정 드리프트(configuration drift)인 문제를 Claude, Codex 또는 OpenClaw의 탓으로 돌리게 되는 정확한 방식입니다.

소모(burn)를 줄이기 위한 실질적인 체크리스트

1. 첫 번째 작업 전에 로드되는 항목을 다듬기
   다음 항목들을 초기 턴에 자동으로 집어넣지 마십시오:

• 워크스페이스 요약 (workspace summaries)
• 메모리 파일 (memory files)
• 프로젝트 노트 (project notes)
• AGENTS.md
• 오래된 작업 기록 (stale task history)
  의도적으로 로드하십시오.

2. 더 좁은 기술(skills) 구축하기
   코딩 기술에 단 몇 개의 파일과 작은 도구 세트만 필요하다면, 이를 명시적으로 만드십시오.

나쁜 예:
scope : files : " **/*" tools : [ read , write , bash , grep , search , browser ]

좋은 예:
scope : files : - src/api/** - tests/api/** tools : [ read , write , grep ]

3. 공격적으로 리셋하기
   에이전트가 하위 작업(subtask)을 마쳤다면, 압축(compact)하거나 새로 시작하십시오.
   /new /compact
   이것은 편법(hacks)이 아닙니다. 유지보수(maintenance)입니다.

4. 작업 유형별로 라우팅하기
   단순 정리 작업(janitorial work)에 프리미엄 모델의 컨텍스트를 낭비하지 마십시오.
   대략적인 예시:
   def route_task ( task ): if task . type in [ " lint_fix " , " file_scan " , " summarize_logs " ]: return " gpt-5.4-codex " if task .

type in [ " architecture_decision " , " complex_refactor " , " ambiguous_bug " ]: return " claude-opus " return " gemini-flash "

정확한 모델은 변경될 수 있습니다. 하지만 원칙은 변하지 않아야 합니다.

5. 오케스트레이션 오버헤드 (orchestration overhead)를 주시하세요
   예산을 소비하는 것은 당신의 모델만이 아닙니다. 당신의 오케스트레이터 (orchestrator)가 다음과 같은 일을 하고 있을 수 있습니다:

• 매 단계마다 요약 (summarizing) 수행
• 오래된 메모리를 너무 자주 재수화 (rehydrating) 함
• 도구 호출 (tool calls)을 너무 공격적으로 재시도함
• 에이전트 (agents) 사이에 거대한 중간 출력값 (intermediate outputs)을 전달함
  로그를 남기세요. 측정하세요. 낭비를 제거하세요.

Claude Code vs Codex에 대한 나의 실제 견해
어려운 엔지니어링 판단 (engineering judgment)에 있어서, 나는 여전히 Claude Opus가 그 명성을 얻을 자격이 있다고 생각합니다. 많은 개발자들이 작업이 모호하거나, 구조적(architectural)이거나, 트레이드오프 (tradeoffs)가 가득할 때 분명히 이를 더 신뢰합니다.
인내심, 속도, 그리고 할당량 (quota) 확인으로 인한 정신적 피해가 적어야 하는 코딩 루프 (coding loops)의 경우, Codex 스타일의 설정이 더 낫게 느껴질 수 있습니다.
하지만 더 중요한 점은 이것입니다:
승자는 보통 단일 모델이 아닙니다. 승자는 다음과 같은 기능을 제공하는 스택 (stack)입니다:

• 어려운 추론 (reasoning)을 위한 강력한 모델
• 반복적인 루프를 위한 더 저렴하거나 비용이 평탄한 (flatter-cost) 경로
• 컨텍스트 성장 (context growth)에 대한 무자비한 통제
  모델 품질만을 최적화한다면, 멋진 데모는 얻겠지만 경제성은 나빠질 것입니다. 가격만을 최적화한다면, 실제 작업이 시작될 때까지는 돈을 아낄 수 있을 것입니다.

대부분의 팀이 결국 깨닫게 되는 부분
에이전트가 충분히 오래 실행되고 나면, 가격 책정 (pricing)은 더 이상 단순한 가격 문제가 아니라 시스템 설계 (system design)의 문제로 느껴지기 시작합니다. 이것이 바로 에이전트 팀들에게 비용이 평탄한 컴퓨팅 (flat-cost compute)이 점점 더 흥미로워지고 있는 정확한 이유입니다. 만약 당신의 워크플로우가 긴 자율 실행 (autonomous runs)에 의존한다면, 토큰당 과금 (per-token billing) 방식은 모든 오케스트레이션 실수를 비용 급증으로 바꿉니다. 결국 당신은 작업을 중심으로 엔지니어링하는 대신, 청구서 (invoice)를 중심으로 엔지니어링하게 됩니다.

그것이 Standard Compute의 매력입니다: 고정된 월정액으로 무제한 AI 연산 (compute)을 제공하며, OpenAI 호환 API를 통해 기존의 SDK 및 클라이언트들을 그대로 유지할 수 있습니다. 또한 n8n, Make, Zapier, OpenClaw 및 커스텀 워크플로우 (custom workflows)와 같은 에이전트 및 자동화 스택 (automation stacks)과 연동되며, GPT-5.4, Claude Opus 4.6, Grok 4.20 간의 동적 라우팅 (dynamic routing)을 지원합니다. 이것이 컨텍스트 관리 (context discipline)의 필요성을 없애주는 것은 아닙니다. 다만, 당신이 모든 긴 루프 (long loop)를 결제 사고처럼 취급하지 않아도 에이전트가 계속 작동할 수 있음을 의미할 뿐입니다. 그리고 솔직히 말해서, 이것이 Claude Code 대 Codex 논쟁의 이면에 있는 진짜 질문입니다. 어떤 모델이 더 똑똑한가가 아닙니다. 어떤 설정이 당신을 에이전트의 회계사로 만들지 않고 에이전트가 계속 나아갈 수 있게 해주는가 하는 점입니다.