코덱스 100만 토큰 활성화와 오픈AI가 말하지 않은 요금의 진실

설정 세 줄이면 된다. 오픈AI에서 코덱스(Codex)를 이끄는 티보 소티오(Tibo Sottiaux)가 지난 17일 X에 GPT-5.6 솔(Sol)의 100만 토큰 컨텍스트를 켜는 방법을 공개했다. 붙여넣기 전에 확인할 숫자가 하나 있다. 27만2000이다.

같은 날 소티오는 원래 API 키에서만 작동하던 이 설정을 챗GPT 계정에도 열었다고 밝혔다. 하지만 이 숫자를 넘기는 요청은 입력 단가가 2배, 출력 단가가 1.5배로 계산된다. 오픈AI 공식 모델 문서에 적힌 조건은 이렇다. “27만2000토큰을 초과하는 프롬프트는 해당 요청 전체에 입력 2배, 출력 1.5배 요금이 적용된다.”

초과분에만 붙는 할증이 아니라 요청 전체에 붙는다.

설정 세 줄과 위치 조건

소티오가 공개한 방법은 ~/.codex/config.toml 파일에 다음 세 줄을 넣는 것이다.

model = "gpt-5.6-sol"
model_context_window = 1000000
model_auto_compact_token_limit = 900000

조건이 하나 붙는다. 소티오는 이 설정을 “최상위 레벨에, 어떤 [section] 헤더보다 앞에” 두라고 적었다. TOML 파일에서 키는 바로 위 섹션에 속하므로, [profiles.foo] 같은 헤더 아래에 붙이면 전역 설정으로 잡히지 않는다.

두 키의 역할은 코덱스 설정 문서에 짧게 정의돼 있다. model_context_window는 활성 모델이 쓸 수 있는 컨텍스트 토큰 수이고, model_auto_compact_token_limit은 자동 히스토리 압축이 걸리는 토큰 임계값이다. 후자를 비워두면 모델 기본값을 따르는데, 코덱스는 이때 유효 컨텍스트에서 1만3000토큰을 뺀 값을 압축 시점으로 잡는다.

임계값에는 상한이 있다. 코덱스는 사용자가 지정한 압축 한도와 컨텍스트 창의 90% 중 작은 값을 실제 한도로 쓰는데, v0.100.0에서 백엔드 오버플로를 막으려고 들어간 안전장치다. 100만에 90만을 짝지은 소티오의 예시는 이 상한에 딱 맞춘 값인 셈이다. 90%라는 숫자는 우연이 아니다. 코딩 에이전트의 압축 시점을 비교한 분석은 85~90% 구간을 최적으로 보고, 현재 구현이 흔히 쓰는 95%는 늦다고 지적한다. 압축을 늦출수록 한 번에 버려야 할 양이 늘어나기 때문이다.

왜 코덱스는 105만을 안 쓰고 있었나

GPT-5.6 솔의 문서상 컨텍스트 창은 105만 토큰이고, 최대 출력은 12만8000토큰, 지식 컷오프는 2026년 2월 16일이다.

코덱스가 쓰는 값은 달랐다. 지난 7월 13일 한 사용자가 코덱스의 GPT-5.6 솔 컨텍스트가 37만2000에서 27만2000으로 줄었다는 이슈를 올렸다. 코덱스는 원시값에 95%를 곱해 유효 컨텍스트를 잡는데, 이 계산대로면 35만3400토큰이 25만8400토큰으로 내려앉는다. 26.9% 감소다.

7월 21일에는 37만2000 프로필을 되돌리거나 선택 설정으로 열어달라는 이슈가 올라왔다. 작성자는 오픈AI가 기본 한도를 “완벽에 가깝게” 튜닝했다고 말해온 점, 며칠 안에 복구하겠다고 한 점을 함께 적었다. 같은 시기 대화형 세션은 105만을 표시하는데 codex exec는 25만8000만 잡는다는 이슈도 열렸다. 세 이슈 모두 관리자 답변이 붙지 않았다.

축소는 조용히 이뤄졌다. 값을 내린 코드 변경은 7월 18일 병합됐고, JSON 파일 한 개를 고치는 작업이었다. 별도 공지가 없었던 탓에 저장소를 직접 들여다보는 개발자 바깥에서는 알아채기 어려운 방식이었다.

이번 발표는 이 세 갈래 불만에 대한 답이다.

27만2000이 만드는 요금 절벽

한도를 100만으로 올리면 요금 구간도 함께 넘어간다. GPT-5.6 솔의 API 정가는 입력 100만 토큰당 5달러(약 7060원), 출력 100만 토큰당 30달러(약 4만2300원), 캐시 적중 입력 100만 토큰당 0.5달러(약 710원)다.

27만2000토큰을 넘기면 이 숫자가 전부 다시 계산된다. 컨텍스트를 90만까지 채운 요청 한 번은 입력에서만 9달러(약 1만2700원)가 나가고, 여기에 출력 12만8000토큰을 붙이면 5.76달러(약 8130원)가 더해진다. 요청 하나가 1만4700원대다.

캐시가 이 계산을 눌러준다. 캐시 적중 입력은 배수를 얹어도 100만 토큰당 1달러(약 1410원)이고, 같은 파일을 반복해서 읽는 코딩 세션은 대부분 이 구간에 걸린다. 실제 청구액은 캐시 적중률에 좌우되며, 그 비율은 세션마다 다르다.

챗GPT 요금제 사용자는 계산이 또 다르다. 코덱스 요금표는 메시지 단위가 아니라 토큰 단위로 크레딧을 빼며, 솔은 입력 100만 토큰당 125크레딧, 캐시 입력 12.5크레딧, 출력 750크레딧이다. 이 요금표에는 27만2000 임계값도, 배수 조항도 없다. 구독 미터에 API와 같은 배수가 그대로 붙는지는 오픈AI가 공개한 문서 어디에도 적혀 있지 않다.

소티오도 이 지점을 짚었다. 100만 토큰을 켜면 구독 할당량 소모가 눈에 띄게 빨라진다며, 꼭 필요할 때만 켜라고 당부했다. X에서 이 설정을 정리해 공유한 카이(@hqmank)도 작은 작업에는 꺼두라고 적었다.

그러면 100만 토큰이 답인가

컨텍스트를 늘리면 모델이 더 똑똑해진다는 전제부터 흔들린다.

크로마(Chroma)는 지난해 18개 모델을 긴 입력에 넣고 성능을 측정한 연구를 내놨다. 클로드 오푸스 4와 소넷 계열, o3와 GPT-4.1 계열, 제미나이 2.5 프로, Qwen3까지 포함했다. 결과는 한 방향이었다. 입력이 길어질수록 모든 모델의 정확도가 떨어졌고, 바늘 찾기 변형과 11만3000토큰짜리 대화 기억 과제, 1만 단어 그대로 복창하기 어디에서도 예외가 없었다.

아티피셜 애널리시스(Artificial Analysis)의 장문 추론 벤치마크는 더 좁은 구간을 잰다. AA-LCR은 1만~10만 토큰 문서 30세트, 234개 문서에 대한 100문항으로 구성되며 논문과 재무보고서, 법률문서가 섞여 있다. 현재 리더보드 1위 점수는 83.3%다. 10만 토큰 구간에서도 최상위 모델이 여섯 문항 중 하나를 틀린다.

100만 토큰 구간을 재는 공개 벤치마크는 아직 없다.

또 100만 토큰은 오픈AI만의 숫자도 아니다. 제미나이 3.1 프로는 104만8576토큰, 클로드 오푸스 4.8과 소넷 4.6은 각각 100만 토큰을 표시한다. 같은 자료는 광고된 크기가 상한일 뿐이며 실제 유효 컨텍스트는 그보다 짧다는 점을 함께 적었다. 경쟁 모델이 모두 100만을 내건 상황이 코덱스 사용자의 불만을 키운 배경이기도 하다.

비용 구조도 선형이 아니다. 해커뉴스(Hacker News) 토론에서 한 개발자는 어텐션이 길이의 제곱으로 늘어나기 때문에 37만2000번째 토큰의 처리 비용이 27만2000번째 토큰보다 87% 비싸다고 계산했다. 오픈AI가 기본값을 낮춘 이유를 설명하는 계산이다.

반대편 주장도 만만치 않다. 같은 토론에서 개발자들은 압축이 걸릴 때 잃는 정보가 너무 많다고 반박했고, 5000줄이 넘는 코드베이스에서는 압축이 연쇄로 터지면서 모델이 코드를 다시 읽고 환각을 일으킨다는 후기가 이어졌다. 자동 압축을 끌 방법이 없다는 점도 함께 지적됐다.

압축은 무엇을 버리나

코덱스의 자동 압축은 두 시점에 걸린다. 새 사용자 메시지를 보내기 직전, 그리고 긴 도구 호출 사슬 중간의 루프 경계다. 압축이 끝나면 문맥에 남는 것은 요약 메시지 하나와 최근 사용자 메시지 최대 2만 토큰뿐이다. 이전 어시스턴트 응답과 도구 실행 결과, 앞서 읽은 파일 내용은 전부 버려진다. 오픈AI 모델에서는 이 요약이 암호화된 불투명 덩어리로 들어간다.

임계값을 90만으로 올리면 이 폐기 시점이 그만큼 뒤로 밀린다. 대규모 리팩터링처럼 파일 수십 개의 관계를 동시에 붙들어야 하는 작업에서는 이 차이가 크다.

압축 빈도 자체가 버전에 따라 흔들리기도 한다. 코덱스 v0.118은 직전 버전인 v0.116보다 압축이 약 두 배 자주 걸리는 회귀를 냈다. 임계값을 명시해두면 이런 변동에서 자유로워진다.

다른 도구는 무엇을 남기나

압축 방식은 도구마다 갈린다. 같은 문제를 서로 다른 철학으로 푼다.

코덱스는 압축 직후 최근 편집한 파일을 최대 5개까지, 5만 토큰 예산 안에서 자동으로 다시 읽는다. 잃은 문맥의 일부를 스스로 복구하는 설계다. 대신 요약 자체는 오픈AI 서버만 풀 수 있는 암호화 덩어리라, 사용자는 무엇이 남았는지 확인할 수 없다.

클로드 코드(Claude Code)는 반대로 사람이 읽는 텍스트 요약을 만든다. /compact 명령으로 작업 경계에서 직접 압축을 걸 수 있고, 무엇에 집중해 요약할지 지시할 수도 있다. OpenCode는 압축 시점을 모델에게 맡기고, 최근 4만 토큰은 건드리지 않는 보호 구역으로 두고 나머지를 선별해 잘라낸다.

결국 코덱스 사용자가 압축을 통제할 수 있는 지점은 임계값 하나뿐이다. 소티오가 공개한 설정이 실질적인 조정 수단인 이유다.

언제 켜고 언제 끄나

판단 기준은 컨텍스트 길이가 아니라 작업의 형태다.

한 세션에서 읽어야 할 파일이 서로 얽혀 있고, 앞부분을 잊는 순간 뒷부분이 틀리는 작업이라면 켤 값이 있다. 마이그레이션과 대규모 리팩터링, 여러 모듈을 가로지르는 버그 추적이 여기 해당한다.

반대로 파일 몇 개를 고치는 작업이나 테스트 하나를 통과시키는 작업에서는 켤 이유가 없다. 요금 구간만 넘기고 정확도는 오히려 내려간다. 세 번째 선택지도 있다. 컨텍스트를 키우는 대신 작업을 쪼개는 방법인데, 해커뉴스에서 여러 개발자가 계층적 계획과 하위 에이전트로 세션을 나누면 압축 자체를 안 만나게 된다고 조언했다.

남은 문제

이번 발표는 설정 하나를 열었을 뿐, 기본값 논쟁을 닫지 않았다.

코덱스가 왜 105만 대신 27만2000을 기본으로 쓰는지, 왜 37만2000에서 한 번 더 내렸는지, 대화형 세션과 codex exec의 컨텍스트가 왜 다르게 잡히는지는 여전히 깃허브 이슈에 답 없이 열려 있다. 컨텍스트 변경을 체인지로그에 공지해달라는 요청도 마찬가지다.

사용자가 얻은 건 스위치다. 그 스위치를 켰을 때 구독 미터가 얼마나 빨리 도는지는 아직 아무도 문서로 공개하지 않았다.