Codex 이미지 생성 한도, 그림 한 장당 입력 토큰을 25분의 1로 줄인 실험
게임 장비 그림을 Codex 로 뽑다가 한도에 막힌 적이 있다. 대기열엔 그림이 500장 넘게 남아 있었다. 근데 기존 방식으로 3장 뽑아 보니 5시간 창 사용률이 6%p 올랐다. 이대로면 남은 걸 다 뽑는 데 며칠은 걸릴 판이었다.
내 기록에선 입력 토큰을 크게 줄인 방식에서 한도 사용률도 크게 내려갔다. 그림 한 장당 입력 토큰이 548,320 에서 21,483 으로, 대략 25분의 1이 됐다. 5시간 창 사용률은 장당 2.00%p 에서 0.11~0.22%p 쯤으로 내려갔다. 그림 생성 호출 수는 25%만 줄어서 토큰 쪽 영향이 큰 것 같았다. 다만 여러 조건을 한꺼번에 바꿔서 무엇이 얼마나 영향을 줬는지는 따로 확인 못 했고, 표본도 12장뿐이다.
한도는 어디서 새고 있었을까
먼저 그동안 돌린 세션 기록부터 뜯어봤다. 그림을 10장씩 저장한 세션 44개를 골라서 토큰이 어디에 쓰였는지 나눠 봤다. 이때는 지금과 다른 모델을 쓰던 때다.
그림 한 장 저장할 때마다 모델 호출이 3.45번 있었다. 문제는 호출할 때마다 그때까지 쌓인 맥락 전체를 다시 읽는다는 거다. 참고 그림이랑 방금 그린 그림이 맥락에 들어가서 입력 읽기의 26% 를 차지했다. Codex 가 스스로 쓴 코드랑 프롬프트, 추론이 쌓인 게 48% 쯤이었고, 세션 시작할 때 읽는 지시문이 20%, 작업 문서 읽기가 6% 였다.
그러니까 그림 자체보다 그림을 그리러 가는 길에 읽는 게 훨씬 많았던 거다. 근데 이 기록만으론 한도가 그림 횟수 때문인지 토큰 때문인지 가를 수가 없었다. 두 해석 다 숫자가 비슷하게 맞았다. 그래서 직접 비교해 보기로 했다.
같은 대기열에서 이미지 생성 한도 비교
기존 방식은 Codex 가 작업 안내 문서랑 대기열, 요청서를 직접 읽고, 참고 그림을 열어 보고, 그린 걸 다시 보면서 진행하는 식이었다.
줄인 방식은 반대로 갔다. 요청서 다듬는 일은 Claude Code 쪽에서 미리 끝냈다. 한국어 장비 이름은 영어로 바꿨다. 그림 생성기가 한글을 글자로 그려 넣지 않게 하려는 거였다. 생김새 설명도 한 줄씩 구체적으로 붙였다. Codex 한테는 짧은 코드 틀만 넘겼다. 작업 파일을 읽고, 프롬프트를 그대로 그림 생성에 한 번 넘기고, 결과 파일을 복사하고, 로그 한 줄 남기는 게 전부다. 그린 그림은 보지도 않는다. Codex 입력은 2,578자였다.
같은 대기열 1~12위를 나눠서 세 번 돌렸다. 1~3위는 기존 방식으로, 4~9위는 줄인 방식에 참고 그림 2장을 붙여서, 10~12위는 참고 그림 4장을 붙여서. 모델은 셋 다 gpt-6-sol medium 으로 맞췄다. 같은 장비를 두 번 뽑은 시험은 아니었다. 장비마다 모양이 달라서 그 차이도 섞여 있다.
결과, 입력 토큰은 25분의 1
기존 방식은 3장 뽑는 데 모델을 24번 불렀고 입력 토큰이 1,644,960 이었다. 9분 걸렸다. 줄인 방식은 6장에 7번, 3장에 4번 불렀다. 입력은 각각 124,807 이랑 68,538 이었다. 여기서 토큰은 캐시를 포함한 입력 토큰이다.
장당으로 바꾸면 기존 방식이 548,320 토큰에 181초, 줄인 방식 9장을 합치면 21,483 토큰에 70초다. 5시간 창은 장당 2.00%p 에서 0.11%p 로 찍혔다. 근데 이 사용률은 1% 단위로만 바뀌고, 마지막 기록이 실행 끝나기 1분 30초 전 값이었다. 그래서 오차를 넣으면 장당 0.11~0.22%p 정도다. 기존과 비교하면 89~94% 줄어든 셈이다.
여기서 재밌는 건 그림 생성 호출 횟수다. 기존 방식은 3장에 4번, 줄인 방식은 9장에 9번이었다. 장당으로 치면 25% 줄었을 뿐인데 사용률은 훨씬 많이 줄었다. 그래서 토큰 쪽 영향이 컸다고 짐작하고 있다. 그래도 그림 보기, 문서 읽기, 참고 그림 수를 다 같이 바꿨으니 어느 게 얼마였는지는 모른다. 다른 계정이나 다른 모델에서도 그런지도 확인 못 했다.
5시간 창 하나를 90% 까지 쓴다고 치면 기존 방식으론 45장, 참고 그림 4장 방식으론 270장쯤 된다는 계산이 나왔다. 남은 511장을 기존 방식으로 하면 5시간 창이 11개 넘게 필요했다. 이건 계산이지 실제로 돌려 본 건 아니다.
그림 품질은 괜찮았나
줄인 방식 9장은 검수에서 전부 승인됐다. 1장은 가는 선이 뭉개져서 후처리로 살렸다. 참고 그림을 4장 붙인 쪽이 2장 붙인 쪽보다 나은 점은 안 보였다. 입력만 장당 10% 쯤 더 들었다. 그래서 2장으로 가기로 했다.
근데 부작용이 하나 있었다. 줄인 방식 9장이 전부 요청한 크기보다 크게 그려졌다. 3% 에서 84% 까지. 크기를 맞추느라 많이 줄여야 하는 작은 물건은 가는 고리 선이 뭉개졌다. 기존 방식 3장은 전부 범위 안이었다. 그 차이가 그림을 다시 보느냐 마느냐 때문인지는 따로 비교하지 않았다. 일단 프롬프트 끝에 빈 여백을 몇 px 이상 두라는 문장을 넣었는데, 그게 얼마나 먹혔는지는 이 기록엔 없다.
그리고 일이 사라진 게 아니라 옮겨 간 거다. 예전엔 Codex 가 하던 요청서 해석을 이젠 Claude Code 쪽에서 미리 해 줘야 한다. 이번 결과는 요청서를 미리 손본 상태에서 나온 거다. 그 준비를 빼도 같은 품질이 나오는지는 재 보지 않았다. 한 도구 한도를 아끼려고 다른 쪽 일을 늘린 셈이다.
Codex 이미지 생성 한도에서 해 볼 만한 것
내가 쓴 내장 그림 생성에는 품질이나 크기를 낮추는 설정이 없었다. 그래서 줄일 수 있는 건 결국 맥락이었다. 그림을 다시 보여 주지 않기, 문서를 읽히지 않고 필요한 것만 지시문에 넣기, 고쳐 그리기 대신 한 번에 끝내고 나중에 고치기. 내가 바꾼 건 이 셋이었고, 하나씩 따로 재 보진 않았다.
한 세션에 몇 장을 넣을지도 방식마다 달랐다. 기록으로 계산해 보니 기존 방식은 맥락이 빨리 불어나서 3장쯤이 제일 쌌고, 줄인 방식은 장마다 맥락이 0.6k 쯤만 늘어서 15장씩 묶는 쪽이 싸다는 추정이 나왔다.
한도 메시지가 떴을 때 뭘 먼저 봐야 하는지는 Claude Code, Codex 사용량 한도에 걸렸을 때 에 따로 적어 뒀다.
다음엔 윈도우에서 AI 코딩 도구를 처음 깔 때 미리 해 둘 설정 얘기를 하려고 한다.