Codex 비용 최적화 실전: 판단력을 잃지 않고 토큰을 아끼는 법

같은 작업인데도 quota가 예상보다 훨씬 빨리 사라진다. 긴 thread가 하루 종일 컨텍스트를 다시 읽고, multi_agent가 기본값으로 켜져 있고, AGENTS.md가 수천 줄이며, 작은 작업도 가장 비싼 모델로 돌고 있다면 돈이 어디로 새는지 바로 감이 온다. 어디서 비용이 생기고 어떻게 줄이는지, 여기서 정리한다.

1. 돈은 어디서 빠지나: 과금 구조

Codex 비용은 네 군데서 나온다. 컨텍스트 재읽기, 긴 세션, 병렬 subtasks, 높은 추론 단계다. 기본은 token/credit 과금이다. input, cached input, output이 각각 그에 맞는 credit을 쓰며, 토큰 종류마다 요율이 다르다. cached input은 일반 input보다 싸고, 그래서 prompt cache가 돈을 아끼는 핵심이다. 정확한 요율은 official rate card를 보면 된다.

Codex는 단순 월 한도가 아니라 rolling window로 움직인다. 창이 꽉 차면 rate limit이 걸린다. Plus와 Pro에는 rate-limit reset banking이 있고, 창은 시간이 지나면 복원된다. API key는 token 기준으로 따로 과금되며 Codex 플랜 한도와는 별개다.

사용량을 보려면 현재 세션은 /status로 확인하고, 팀 전체 사용량은 Codex 설정의 usage dashboard에서 보면 된다.

컨텍스트 재읽기는 가장 쉽게 놓치는 비용 원천이다. 작업할 때마다 Codex는 AGENTS.md, 프로젝트 문서, thread 기록을 다시 읽는다. AGENTS.md가 수천 줄이고 문서가 크고 thread가 여러 라운드에 걸치면 token이 쌓인다. 긴 세션은 누적된다. thread가 길고 읽는 양이 많을수록 더 비싸다. multi_agent를 켜면 활성 agent마다 별도 quota를 쓰므로 병렬성이 비용을 올린다. GPT-5.5/5.4 같은 상위 모델은 GPT-5.4 mini보다 비싸고, Low/Medium/High/Extra High 추론 단계도 요금을 바꾼다.

절감 수단별 효과와 대가는 이렇다.

절감 수단	기대 효과	대가
더 저렴한 모델 선택	사용량 30-60% 감소	추론력이 떨어지고 복잡한 작업에 약해짐
컨텍스트를 제때 비우기	사용량 20-40% 감소	새 thread가 늘고 기록이 끊김
AGENTS.md 줄이기	사용량 10-20% 감소	문서 분리가 필요하고 유지보수 비용이 듦
prompt cache 활용	사용량 15-30% 감소	컨텍스트를 안정적으로 유지해야 함
multi_agent 줄이기	사용량 20-50% 감소	병렬성이 줄고 느려짐

아낀다고 해서 무조건 줄이는 건 아니다. 더 싼 모델은 30-60% 절감할 수 있지만 복잡한 작업은 약해질 수 있다. 컨텍스트를 제때 비우면 20-40% 줄일 수 있지만 새 thread를 더 자주 열어야 한다. AGENTS.md를 줄이면 10-20% 줄어들지만 문서 구조를 더 신경 써야 한다. 진짜 기준은 작업이다. 핵심 능력을 희생해서 자잘한 금액을 아끼지는 말자.

사용량 보기

콘솔에서 /status를 치면 현재 thread 상태와 컨텍스트 크기, 사용한 quota를 볼 수 있다. Codex 설정의 usage dashboard에서는 팀 사용량과 quota window 상태를 본다. 절감 수단의 효과는 주기적으로 비교해 보는 게 좋다.

2. 모델과 추론 단계: 항상 제일 비싼 게 답은 아니다

모델 선택은 비용에 직접 영향을 준다. Codex에는 Low, Medium, High, Extra High의 네 가지 추론 단계가 있다. Low는 빠르고 범위가 좁아 단순 작업에 좋다. Medium과 High는 복잡하거나 debugging이 많은 작업에 더 맞는다. Extra High는 긴 agentic 작업용이다. 모델 쪽에서는 GPT-5.5와 GPT-5.4가 frontier고, GPT-5.4 mini가 가벼운 버전이다. 5.3-Codex와 5.2는 이미 구형이다.

기본 규칙은 단순하다. 생각은 frontier, 반복 작업은 mini다. 작업 난이도에 맞춰 추론 단계를 고르자. 비싼 조합을 늘 기본값으로 두면 간단한 작업에서 quota만 태운다.

구분은 이렇게 보면 된다.

작업 유형	추천 추론 단계	대표 시나리오
단순 검색, 포맷 변경	Low	문서 정리, 작은 수정
리팩터, 기능 작업	Medium	단일 파일 리팩터, API 통합
debugging, 복잡한 로직	High	여러 파일에 걸친 버그, 성능 조정
긴 agentic 작업	Extra High	다단계 자동화, 탐색적 개발

단순 질의와 포맷 변환은 Low + mini로 처리한다. 리팩터와 기능 작업은 Medium + mini 또는 Medium + GPT-5.4를 쓴다. debugging과 복잡한 로직은 High + GPT-5.4/5.5가 맞다. 긴 agentic 작업은 Extra High + GPT-5.5가 맞다. 안전하다는 느낌이 아니라 실제 난이도로 고르자. 혹시 모르니까 높이는 건 비싸다.

FAQ: 어떤 모델이 더 아끼나요?

생각이 필요한 작업은 frontier(GPT-5.5/5.4), 단순 작업은 mini(GPT-5.4 mini)가 맞다. 추론 단계는 난이도에 맞춰 조정한다. 단순 검색은 Low, 복잡한 debugging은 High, 긴 agentic 작업은 Extra High.

3. 세션 관리: 하루 종일 같은 thread를 돌리지 말기

긴 세션은 하루 종일 컨텍스트를 다시 읽는다. token이 금방 사라진다. Codex는 실행할 때마다 thread를 다시 읽기 때문에 thread가 길고 읽는 양이 많을수록 비용이 커진다. 해결은 간단하다. 세션을 짧게 가져가자. 한 thread, 한 작업.

실제로는 AGENTS.md가 수천 줄이고 프로젝트 문서가 크며, 주고받는 과정이 여러 번 반복된다. 한 번의 재읽기는 몇 token일 수 있지만 수십 번이면 수만 token이 된다. thread가 길어질수록 Codex도 헷갈리기 쉽고 결과도 나빠진다.

명령	용도	언제 쓰나
/compact	초기 컨텍스트 압축	thread가 길어질 때 (Codex가 자동으로도 함)
/clear	현재 thread 지우기	작업이 끝났을 때
/resume	이전 thread 이어가기	전에 하던 일을 계속할 때
/fork	가지치기	다른 방향을 탐색할 때
/agent	병렬 agent로 전환	multi_agent가 필요할 때
/status	thread 상태 확인	사용량을 볼 때

세션 best practice

작업이 끝나면 즉시 /clear를 하거나 새 thread를 열어 context가 쌓이지 않게 한다. 긴 세션에서는 /compact로 앞부분을 압축해 token을 아낀다. 이전 일을 정말 이어가야 할 때만 /resume을 쓴다. bugfix, feature, refactor, deployment를 한 thread에 섞지 말자. context가 흐트러지고 token이 새어 나간다. 탐색용 분기는 /fork를 쓰되, 분기마다 quota가 따로 든다는 점을 기억한다.

FAQ: 긴 세션은 어떻게 관리하나요?

작업이 끝나면 /clear 또는 새 thread를 연다. 긴 세션 중에는 /compact를 쓴다. 한 thread, 한 작업.

4. AGENTS.md 줄이기: 32KiB 잘림 피하기

AGENTS.md는 금방 커지고 context를 많이 먹는다. 잘릴 수도 있다. project_doc_max_bytes 기본값은 32 KiB다. AGENTS.md가 이 한도에 닿으면 시스템이 더 이상 추가하지 못하고 잘라 버린다. 그러면 지시가 빠지고 context도 낭비된다.

AGENTS.md 크기는 이렇게 보면 된다.

AGENTS.md 크기	영향	해결책
< 16 KiB	체감 영향 없음, context 적게 사용	그대로 유지
16-32 KiB	중간 부담, 관찰 필요	핵심이 아닌 내용 분리
> 32 KiB	잘림 위험, 일부 지시 누락	중첩 폴더로 분해

AGENTS.md 줄이는 방법

32 KiB 아래에서 가볍고 안정적인 AGENTS.md 하나를 유지하고, 핵심 지시와 공통 규칙만 넣는다. 한도를 넘으면 추가 규칙은 docs/.agents 같은 중첩 폴더로 옮기고, 세부 내용은 작업별 .md 파일에 둔다. 가까운 곳의 AGENTS.md가 우선하도록 override를 활용한다.

더 자세한 안내는 AGENTS.md Best Practices를 보자.

---

5. Prompt cache: 안정적인 컨텍스트를 더 싸게

cached input은 일반 input보다 싸다. 그래서 prompt cache가 중요하다. 컨텍스트가 안정적이면 Codex는 그것을 cached input으로 과금할 수 있다. AGENTS.md와 프로젝트 문서를 안정적으로 유지해 cache가 제대로 먹히게 하자.

메커니즘은 단순하다. Codex는 AGENTS.md와 프로젝트 문서처럼 안정적인 컨텍스트 블록을 저장한다. 다음 실행에서는 이것이 cached input으로 과금된다. 자주 바꾸면 cache가 깨져서 다시 일반 input 요금이 붙는다. cache hit이 좋으면 한 번 실행 비용을 15-30% 줄일 수 있다.

실전 규칙은 이렇다. AGENTS.md는 짧고 안정적으로 유지하고, 오래 가는 규칙은 고정된 위치에 두며, 변동이 큰 내용은 임시 폴더나 작업 전용 문서로 옮긴다. 모든 걸 prompt에 넣지 말자.

캐시 활용의 트레이드오프:

캐시 수단	기대 효과	대가
안정적인 AGENTS.md	cached input 적중률 상승	사전 설계가 필요하고 변경이 적어짐
안정적인 프로젝트 문서	반복 읽기 token 감소	문서가 바뀌면 cache가 무효화됨
잦은 변경 피하기	캐시 hit이 안정적	유연성이 줄어듦

FAQ: prompt cache는 어떻게 돈을 아끼나요?

AGENTS.md와 프로젝트 문서를 안정적으로 유지해서 cached input을 타게 한다. cached input은 일반 input보다 싸고, 정확한 차이는 official rate card에 나온다.

6. 병렬 처리와 plan mode: 필요할 때만 켜기

multi_agent v2는 활성 실행 단위로 과금된다. 활성 agent마다 quota를 쓰므로 병렬 처리는 단일 agent보다 비싸다. 지금의 multi_agent는 실험적 기능이므로 기본 자세는 절제다. 정말 필요할 때만 켜자.

계산은 단순하다. agent 하나가 한 번 실행되면 X를 쓴다. multi_agent가 세 agent를 병렬로 돌리면 활성 agent마다 X가 들어가서 총 3X가 된다. agent 수가 많을수록 비싸다. 게다가 각 agent는 context를 다시 읽고 reasoning을 하고 결과를 내므로 그것도 더해진다.

병렬 모드	비용 영향	대표 시나리오
단일 agent	기본 비용	한 작업, 순차 실행
multi_agent(가벼운 병렬)	+20-30%	병렬 탐색이 필요할 때
multi_agent(강한 병렬)	+50-100%	긴 agentic 작업

multi_agent는 여러 파일을 동시에 수정하거나, 여러 문서를 동기화하거나, 자동 테스트·배포·모니터링 같은 긴 agentic 흐름이 필요한 경우에 맞다. 단일 bugfix, 단계적 refactor, 예산이 빠듯한 개인 작업에는 적합하지 않다. 병렬 비용을 더 이해하려면 Codex Multi-Agent in Practice를 보자.

multi_agent 규칙은 간단하다. 기본은 끄고, 정말 필요할 때만 켠다. 활성 agent 수를 적게 유지하고, 비용이 빨리 늘면 병렬성을 줄인다.

FAQ: multi-agent 병렬은 비싼가요?

그렇다. multi-agent v2는 활성 실행 단위로 과금되므로 활성 agent마다 quota가 든다. 기본은 꺼 두자.

---

7. Plan mode: 단순 작업에 남용하지 말기

Plan mode는 계획 라운드를 한 번 더 추가하므로 token이 더 든다. 복잡한 작업에서는 이 라운드가 재작업을 막아 준다. 단순한 작업에서는 그저 오버헤드일 뿐이다. 일이 분명하면 바로 실행하자.

복잡도와 plan mode의 관계는 이렇게 보면 된다.

작업 난이도	plan mode 사용?	비용 영향
단순(한 단계, 명확)	아니오	기본 비용
중간(여러 단계, 검증 필요)	예	계획 라운드 1회 추가, 하지만 재작업 감소
복잡(긴 agentic 체인)	예	계획 라운드 1회 추가, 더 비싼 재작업 회피

규칙은 간단하다. 복잡한 작업에는 plan mode, 단순 작업에는 바로 실행. 이것이 보수적인 권장이다. 실제 결정은 작업에 따라 다르다.

FAQ: plan mode는 더 비싼가요?

그렇다. token 라운드가 하나 더 들어간다. 단순 작업에는 쓰지 말고, 복잡한 작업에만 써서 재작업을 줄이자.

8. 모니터링과 예산: 보이는 것만 줄일 수 있다

절감이 잘 되는지 알려면 가시성이 필요하다. Codex에는 usage dashboard와 /status라는 두 가지 모니터링 창구가 있다. usage dashboard는 Codex 설정 안에 있고, 팀 사용량과 quota window 상태를 보여 준다. 콘솔의 /status는 현재 thread의 컨텍스트 크기와 사용한 quota를 보여 준다.

사용량 점검 방법

Codex 설정의 usage dashboard를 열어 팀 사용량을 본다. /status로 현재 thread를 확인한다. 예산 참고치로는 Plus가 대략 $20/월, Pro가 대략 $200/월, Business가 사람당 월 $25-30 정도, 실제 팀 경험은 사람당 월 $100-200 근처인 경우가 많다(공식 수치가 아니라 참고용). 이 숫자는 2026-06 기준 참고치이며, 실제 결정은 공식 가격을 따른다.

FAQ: 한 달에 얼마쯤 드나요?

Plus는 대략 $20/월, Pro는 대략 $200/월이다. 실무에서는 사람당 월 $100-200 정도의 팀 경험이 자주 보인다. 실제 숫자는 usage dashboard에 있다.

9. FAQ

Q1: Codex 비용은 주로 어디서 나가나요?

컨텍스트 재읽기, 긴 세션, multi_agent 병렬 처리, 높은 추론 단계에서 새어 나간다. 1절을 보자.

Q2: 더 저렴하게 쓰려면 어떤 모델이 좋나요?

생각은 frontier(GPT-5.5/5.4), 단순 작업은 mini(GPT-5.4 mini)가 맞다. 추론 단계는 난이도에 맞춘다. 2절을 보자.

Q3: 긴 세션은 어떻게 관리하나요?

작업이 끝나면 /clear, 긴 thread에서는 /compact. 한 thread, 한 작업. 3절을 보자.

Q4: prompt cache는 어떻게 도움이 되나요?

AGENTS.md와 프로젝트 문서를 안정적으로 유지해 cached input을 타게 한다. cached input은 일반 input보다 싸다. 5절을 보자.

Q5: AGENTS.md가 너무 크면 문제인가요?

그렇다. 32 KiB를 넘으면 잘릴 수 있고 context도 많이 먹는다. 본문 파일은 가볍게 유지하고, 나머지는 중첩 폴더로 옮긴다. 4절을 보자.

Q6: multi-agent 병렬은 비싼가요?

그렇다. 활성 실행 단위로 과금되기 때문이다. 기본은 꺼 두자. 6절을 보자.

Q7: plan mode는 더 비싼가요?

그렇다. token 라운드가 추가된다. 단순 작업에는 쓰지 말자. 7절을 보자.

Q8: 한 달에 대략 얼마 드나요?

Plus는 대략 $20/월, Pro는 대략 $200/월. 팀에서는 사람당 월 $100-200 정도의 경험이 자주 보인다. 8절을 보자.

10. 다음 단계와 더 읽을거리

승인과 자주 나는 오류를 보고 싶다면 Codex Sandbox and Permission Boundaries를 보자. 병렬 agent를 더 깊이 알고 싶다면 Codex Multi-Agent in Practice를 보자.