코드 품질을 저하시키지 않으면서 Codex 토큰 비용을 줄이는 방법

범위: 2026년 6월 22일 Codex 문서에 따라 검증됨.

Codex 토큰 비용을 줄이는 안전한 방법은 고정된 품질 게이트(quality gates)가 변경되지 않는 범위 내에서만 최적화하는 것입니다. “품질을 저하시키지 않고”라는 말은 짧아진 트랜스크립트(transcript)가 똑같이 좋아 보일 것이라고 믿는 것을 의미해서는 안 됩니다. 이는 실행 전에 요구 사항, 테스트, 정적 검사(static checks) 및 검토 기준을 정의한 다음, 이러한 게이트에 대해 성능이 더 떨어지는 저렴한 설정은 모두 거부하는 것을 의미합니다.

이 원칙은 Codex CLI, IDE 확장 프로그램, 앱 및 클라우드 전반에 적용되지만, 예산은 각 인터페이스마다 다르게 나타납니다. ChatGPT 사용자는 일반적으로 직접적인 토큰 인보이스를 받는 대신 포함된 사용량, 속도 제한(rate limits) 또는 크레딧을 소비합니다. API 키 사용자는 표준 모델별 API 요금을 지불합니다. 컨텍스트(Context) 사용량은 스레드에 얼마나 많은 정보가 들어가는지에 영향을 미치며, 지연 시간(latency)은 단순히 경과된 시간입니다. 이것들은 서로 관련된 운영상의 제약 조건이지, 서로 대체 가능한 측정 단위가 아닙니다. 공식 Codex 가격 책정, 인증, API 가격 책정 문서를 참조하십시오.

1. 예산 정의 및 측정

Codex 스레드에는 프롬프트(prompt)와 최종 답변 이상의 것이 포함됩니다. Codex는 파일 내용, 도구 출력, 모델 응답 및 진행 중인 작업 기록을 수집하며, 이 모든 것이 모델의 컨텍스트 창(context window)에 들어맞아야 합니다. 따라서 긴 로그와 광범위한 파일 읽기는 최종 응답이 짧더라도 컨텍스트를 소비할 수 있습니다. Codex는 긴 스레드를 자동으로 압축(compact)할 수 있지만, 압축은 컨텍스트를 확보하기보다는 세부 사항을 요약하고 버리는 방식입니다 (Prompting Codex).

네 가지 별도의 결과를 측정하십시오:

Context (컨텍스트): 입력 토큰 (input tokens), 캐시된 입력 토큰 (cached input tokens), 그리고 남은 컨텍스트 용량 (remaining context capacity).
Generated tokens (생성된 토큰): 출력 토큰 (output tokens) 및 추론 출력 토큰 (reasoning-output tokens).
Account cost (계정 비용): API 비용 (API charges), ChatGPT 크레딧 (ChatGPT credits), 또는 속도 제한 소모량 (rate-limit consumption).
Operational efficiency (운영 효율성): 경과 시간 (elapsed time), 턴 (turns), 검증 실패 (failed verification), 및 수정 시도 (corrective attempts).

재현 가능한 비교를 위해, 일화적인 사례에 의존하기보다 다음의 제안된 방법을 사용하십시오:

다섯 가지의 대표적인 작업을 선택하십시오. 각 작업에 저장된 프롬프트 (prompt), 고정된 시작 커밋 (starting commit), 정확한 검증 명령 (verification command), 그리고 서면 검토 체크리스트 (written review checklist)를 부여하십시오.
베이스라인 프로필 (baseline profile) 하나와 후보 프로필 (candidate profile) 하나를 생성하십시오. 한 번에 하나의 변수만 변경하십시오. 만약 컨텍스트 규율 (context discipline)을 테스트하는 중이라면, 모델과 추론 노력 (reasoning effort)을 고정하십시오. 모델 변경은 별도로 테스트하십시오.
동일한 커밋의 깨끗한 복사본으로부터 프로필당 각 작업을 세 번씩 실행하십시오. 모든 초기 실행에는 새로운 비대화형 스레드 (noninteractive thread)를 사용하십시오.
이벤트 스트림 (event stream)을 캡처하십시오:

   codex exec --profile baseline --json - \
     < prompts/task-01.txt > results/task-01-baseline-1.jsonl

전체 기계 판독 가능 스트림 (machine-readable stream)을 다른 모델 컨텍스트에 출력하는 대신, 즉시 완료 이벤트 (completion event)를 필터링하십시오:

   jq -c 'select(.type == "turn.completed") | .usage' \
     results/task-01-baseline-1.jsonl

Codex 외부에서 사전 정의된 검증 명령(verification command)을 실행합니다. 통과(pass) 또는 실패(fail) 여부를 기록합니다. 만약 실패한다면, thread.started 이벤트에서 정확한 세션 ID(session ID)를 가져와서, 검증 로그(verification log)와 "명시된 게이트를 통과하는 데 필요한 최소한의 수정만 수행하세요(Make the smallest correction required to pass the stated gate)"라는 수정된 지침(instruction)을 사용하여 해당 스레드를 재개하고, 각 수정 턴(corrective turn)을 별도의 JSONL 파일에 저장합니다. 세 번의 수정 시도 후에도 게이트를 통과하지 못하면 실패로 기록하고 중단합니다.
각 태스크(task)와 반복(repetition)당 하나의 행을 다음과 같은 항목으로 저장합니다: 프로필(profile), 입력 토큰(input tokens), 캐시된 입력 토큰(cached input tokens), 출력 토큰(output tokens), 추론 출력 토큰(reasoning-output tokens), 모든 JSONL 파일에 걸친 완료된 턴(completed turns), 검증 결과(verification result), 그리고 수정 시도 횟수(corrective-attempt count). 요구사항(requirement), 테스트(test), 리뷰(review) 결과가 동일함을 확인한 후에만 중앙값(median)을 비교합니다.

codex exec --json은 JSONL 이벤트를 방출하며, 해당 명령의 turn.completed 사용량(usage) 객체는 input_tokens, cached_input_tokens, output_tokens, 그리고 reasoning_output_tokens를 보고합니다 (비대화형 모드 (Non-interactive mode)). 이 글은 벤치마크 결과를 주장하는 것이 아니며, 이 절차는 여러분의 자체 워크로드(workload)에 대한 증거를 생성하는 방법입니다.

2. 품질 게이트(quality gates)를 먼저 설정하십시오

토큰 절감은 종종 태스크가 불충분하게 정의되었기 때문에 실패합니다. 다섯 단어 정도의 프롬프트(prompt)는 탐색(exploration), 가정(assumptions), 재작업(rework), 그리고 반복적인 확인을 유발할 수 있습니다. OpenAI는 Codex에 목표(goal), 관련 컨텍스트(context), 제약 조건(constraints), 그리고 완료 정의(definition of done)를 제공할 것을 권장하며, 재현 가능한 검증 단계(reproducible validation steps)를 포함할 것을 권장합니다 (Codex 모범 사례 (Codex best practices)).

다음과 같은 프롬프트 형태를 사용하십시오:

목표(Goal): 재시도 경로(retry path)에서 중복 송장 생성 문제를 수정하십시오.
컨텍스트(Context): src/billing/retry.ts 및 tests/billing/retry.test.ts부터 시작하십시오.
제약 조건(Constraints): 퍼블릭 API(public API)와 데이터베이스 스키마(database schema)를 보존하십시오. 리팩터링(refactor)하지 마십시오.
...

더 높은 위험이 따르는 작업의 경우, 타입 체크(type checks), 린팅(linting), 보안 체크(security checks), 성능 임계값(performance thresholds) 또는 인간 검토 루브릭(human review rubric)을 추가하십시오. 이러한 게이트(gates)를 베이스라인(baseline)과 후보(candidate) 실행 모두에서 동일하게 유지하십시오. 토큰은 적게 사용하지만 더 많은 수정 단계(corrective turns)가 필요하거나, 요구사항을 놓치거나, 더 위험한 디프(diff)를 생성하는 설정은 개선이 아닙니다.

3. 무관한 컨텍스트 및 도구 출력 줄이기

Codex가 가능성이 높은 파일들을 향하도록 유도하고, 생성된 코드(generated code), 의존성(dependencies), 빌드 아티팩트(build artifacts), 커버리지 출력(coverage output) 및 관련 없는 서비스들을 명시적으로 제외하십시오. 전체 트리나 큰 파일을 출력하는 것보다 타겟팅된 검색(targeted search)과 라인 범위 읽기(line-range reads)를 선호하십시오. 가장 작은 관련 테스트를 먼저 실행하고, 위험이나 실패가 필요한 경우에만 확장하십시오.

명령어 출력이 스레드(thread)에 들어오기 전에 필터링하십시오:

rg "InvoiceRetry" src tests
git status --short
git diff --stat
...

기계 판독 가능 출력(Machine-readable output)은 의사결정에 필요한 필드로 즉시 필터링될 때만 유용합니다. 가공되지 않은 JSONL, 상세한 테스트 리포터(verbose test reporters), 전체 CI 로그는 간결한 인간 판독 가능 출력(human-readable output)보다 더 클 수 있습니다. 실패한 어설션(failing assertion), 스택 트레이스(stack trace), 요약(summary)은 보존하되, 반복되는 성공 사례와 관련 없는 진단 정보는 생략하십시오. Codex에는 tool_output_token_limit 설정이 있지만, 절단(truncation)이 실제 오류를 숨길 수 있으므로 하드 캡(hard cap)은 최후의 보루로만 사용해야 합니다 (Configuration reference).

지속적인 라우팅(routing) 및 검증 명령어를 위해 AGENTS.md를 사용하되, 탐색(discovery) 방식을 정확히 이해하십시오. Codex는 하나의 전역 지침 파일(global instruction file)을 로드한 다음, 프로젝트 루트에서 실행이 시작된 디렉토리까지 내려가며 디렉토리당 최대 하나의 지침 파일을 로드합니다. 단순히 나중에 해당 디렉토리 하위의 파일을 편집한다고 해서 중첩된 AGENTS.md를 보편적으로 로드하지는 않습니다. 중첩된 지침이 적용되어야 하는 경우 관련 서브트리(subtree)에서 Codex를 시작하십시오. 또한 지침 파일은 시작 시 컨텍스트에 포함되므로 간결하게 유지하십시오 (AGENTS.md guide).

자체 출판된 Caveman 프로젝트는 Claude API 출력 스타일의 벤치마크일 뿐, Codex, 추론 토큰 (reasoning tokens) 또는 총 작업 비용에 대한 증거는 아닙니다. 이 프로젝트가 주는 유용한 교훈은 제한적입니다. 즉, 불필요한 내용을 제거하면 눈에 보이는 출력량은 줄일 수 있지만, 간결한 문체가 무관한 읽기 (irrelevant reads), 노이즈가 심한 도구 (noisy tools) 또는 재시도 (retries)를 보완해주지는 못한다는 점입니다.

4. 작업에 맞춰 모델과 추론 노력 (reasoning effort)을 매칭하기

정해진 게이트 (fixed gates)를 통과할 수 있는 범위 내에서 가장 저렴한 설정을 사용하십시오. OpenAI는 현재 까다로운 Codex 작업에는 gpt-5.5를, 가벼운 코딩 작업에는 더 빠르고 비용이 저렴한 옵션으로 gpt-5.4-mini를 권장합니다. 추론 노력 (reasoning effort)은 범위가 잘 정해진 기계적인 변경 작업에는 낮게 설정할 수 있고, 복잡한 디버깅 (debugging)에는 중간 또는 높게 설정할 수 있습니다. 노력이 높을수록 더 많은 토큰을 사용하며 한도 (limits)를 더 빨리 소모할 수 있습니다 (Codex models 및 IDE features).

첫 번째 실험에서 모델 성능 (model capability), 추론 노력 (reasoning effort), 컨텍스트 (context)를 동시에 줄이지 마십시오. 만약 후보 모델이 실패한다면, 어떤 변경 사항 때문에 실패했는지 알 수 없게 됩니다. 모호함, 동시성 (concurrency), 보안 (security) 또는 반복적인 검증 실패가 필요성을 입증할 때 의도적으로 단계를 높이십시오.

빠른 모드 (Fast mode)는 지연 시간 (latency) 제어 수단이지, 비용 절감 제어 수단이 아닙니다. ChatGPT 로그인 사용자의 경우 지원되는 모델을 더 빠르게 만들지만 크레딧 (credits)을 더 높은 비율로 소모하며, API 키 사용자는 대신 표준 API 가격을 유지합니다. 목표가 응답 속도보다 크레딧 효율성인 경우에는 /fast off를 사용하십시오 (Codex speed).

클라우드 작업 (Cloud tasks)은 현재 로컬 모델 선택을 노출하지 않으므로, 로컬 프로필 대신 작업 범위 (task scope), 리포지토리 지침 (repository instructions), 환경 설정 (environment setup) 및 검증 (verification)을 통해 최적화하십시오 (Codex models).

5. 스레드 (threads), 압축 (compaction) 및 서브에이전트 (subagents) 관리

하나의 스레드(thread)는 하나의 목표에만 정렬되도록 유지하세요. CLI에서 /status는 세션 설정, 토큰 사용량(token usage), 그리고 남은 컨텍스트 용량(context capacity)을 보고합니다. /compact는 컨텍스트를 확보하기 위해 대화 내용을 요약하며, /new 또는 /clear는 이전 조사가 더 이상 관련이 없을 때 새로운 대화를 시작합니다. /usage는 계정 수준의 ChatGPT 활동 또는 속도 제한(rate-limit) 모니터링 용도이며, 실행당 벤치마크가 아닙니다. 이러한 제어 기능과 현재의 의미는 CLI 슬래시 명령 참조(CLI slash-command reference)에 문서화되어 있습니다.

압축(compaction)은 반복적으로 수행하기보다 진단(diagnosis) 또는 구현(implementation)과 같은 단계의 경계에서 수행하세요. 작업이 실질적으로 변경되면 새로운 스레드를 시작하세요. 이전의 결정과 리포지토리 상태(repository state)가 여전히 유용할 때만 재개하세요.

서브에이전트(subagents)는 노이즈가 많은 탐색(exploration)을 메인 스레드로부터 분리하고 독립적인 작업에 소요되는 시간을 줄일 수 있지만, 전체 토큰 소비량을 줄여주지는 않습니다. 각 서브에이전트는 자체적인 모델 및 도구 작업을 수행하므로, 유사한 멀티 에이전트(multi-agent) 실행은 더 많은 토큰을 소비합니다. 서브에이전트는 격리(isolation)나 속도가 추가 비용을 정당화할 수 있는 병렬 연구, 테스트 분석, 또는 독립적인 리뷰 차원(dimensions)을 위해 예약해 두세요 (서브에이전트 개념(Subagent concepts)).

6. 간결하고 재사용 가능한 설정 적용하기

CLI는 CODEX_HOME(기본값 ~/.codex) 아래에 별도의 파일로 저장되는 이름이 지정된 프로필(named profiles)을 지원합니다. 예시는 다음과 같습니다:

# ~/.codex/economy.config.toml
model = "gpt-5.4-mini"
model_reasoning_effort = "low"
...

codex --profile economy 또는 codex exec --profile economy "task"로 실행하세요. 프로필 파일은 최상위 키(top-level keys)를 사용합니다. 현재의 Codex는 더 이상 config.toml에서 레거시 [profiles.name] 테이블을 읽지 않습니다 (고급 설정(Advanced configuration)). model_verbosity는 Responses API 제공업체에 적용됩니다 (고급 설정(Advanced configuration)).

CLI, IDE 확장 프로그램(extension), 그리고 앱은 설정 레이어(configuration layers)를 공유합니다 (Codex best practices). 이 워크플로우의 경우, CLI는 명명된 프로필(named profiles), 슬래시 명령(slash-command) 인터페이스, 그리고 codex exec --json 사용 이벤트를 제공합니다 (profiles, slash commands, noninteractive mode). 프로젝트별 경로와 체크 사항은 저장소의 AGENTS.md에 유지하고, 모델 선택이 검증 단계(gates)를 통과하는 경우에만 프로필을 사용하십시오.

모든 간결한 최종 보고서는 여전히 다음 네 가지 검토 출력(review outputs)을 보존해야 합니다:

변경된 동작 (changed behavior);
실행된 체크 (checks run);
결과 (results);
해결되지 않은 리스크 (unresolved risks).

이것이 품질의 경계입니다. 해당 출력물과 그 근간이 되는 검증 결과(verification outcomes)가 온전하게 유지될 때만 토큰 사용량을 줄여야 합니다.