# GPT-5.5 Codex의 추론 토큰 클러스터링이 성능 저하로 이어질 수 있음 > Clean Markdown view of GeekNews topic #31144. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31144](https://news.hada.io/topic?id=31144) - GeekNews Markdown: [https://news.hada.io/topic/31144.md](https://news.hada.io/topic/31144.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-05T19:42:56+09:00 - Updated: 2026-07-05T19:42:56+09:00 - Original source: [github.com/openai](https://github.com/openai/codex/issues/30364) - Points: 1 - Comments: 1 ## Topic Body - OpenAI Codex 이슈 #30364는 `gpt-5.5` 응답의 `reasoning_output_tokens`가 **516**, 1034, 1552 같은 고정값에 몰리는 현상이 복잡한 Codex 작업의 품질 저하와 관련될 수 있다고 보고함 - 분석 대상은 2026년 2월 1일~6월 27일 UTC의 Codex `token_count` 메타데이터이며, **390,195개 응답 레코드**와 865개 세션에서 exact 516 이벤트 3,363건이 확인됨 - `gpt-5.5`는 전체 응답의 19.3%였지만 exact-516 이벤트의 **82.0%** 를 차지했고, `reasoning_output_tokens >= 516` 중 exact 516 비율은 44.0%로 non-GPT-5.5의 1.3%보다 훨씬 높았음 - 월별 exact-516 비율은 2026년 2월 0.11%에서 5월 **53.30%**, 6월 35.84%로 증가했지만, 같은 기간 평균 및 P90 추론 토큰 수는 낮아져 단순히 추론 토큰 사용량이 늘어난 현상은 아니었음 - 이후 댓글에서는 Codex CLI, Codex Desktop, OpenCode에서 유사한 516 클러스터링과 일부 오답 재현이 공유됐고, 임시 대응으로 `518·n−2` 패턴을 감지해 추론을 이어가는 **로컬 프록시**도 제안됨 --- ### 이슈의 핵심 문제 - Codex 이슈 #30364는 `gpt-5.5` 응답의 `token_count` 메타데이터에서 `reasoning_output_tokens = 516`에 과도하게 몰리는 패턴을 보고함 - 추가로 `1034`, `1552` 근처에서도 고정 경계처럼 보이는 스파이크가 나타난다고 함 - 제기된 범위는 **숨겨진 chain-of-thought 절단을 증명한다는 주장**이 아님 - 더 좁은 주장은 Codex 텔레메트리에서 `gpt-5.5`에 특이적인 **고정 토큰 클러스터링 이상 현상**이 보인다는 것 - 이 패턴이 임계값 기반 추론 예산 동작과 일관돼 보인다는 수준의 문제 제기임 - 관련 이슈 [#29353](https://github.com/openai/codex/issues/29353)는 `gpt-5.5` 실행이 정확히 516 reasoning tokens에서 끝나며 잘못된 답을 반환한 작업 단위 재현을 다뤘고, 이번 이슈는 더 큰 기간의 집계 증거를 추가함 ### 분석 환경과 데이터 - 제품은 **Codex**, 가장 관련된 모델은 `gpt-5.5` - 데이터 소스는 Codex `token_count` 메타데이터 - 분석 기간은 **2026년 2월 1일~6월 27일 UTC** - 집계 수치: - 응답 수준 토큰 레코드: **390,195개** - 세션: **865개** - exact `reasoning_output_tokens = 516` 이벤트: **3,363건** - `gpt-5.5`의 전체 응답 비중: **19.3%** - `gpt-5.5`의 exact-516 이벤트 비중: **82.0%** - `gpt-5.5` exact-516 / >=516 비율: **44.0%** - non-GPT-5.5 exact-516 / >=516 비율: **1.3%** ### 모델별·월별 패턴 - 모델별 exact 516 / >=516 비율은 `gpt-5.5`에서 가장 두드러짐 - `gpt-5.5`: 75,401개 레코드, **44.0%** - `gpt-5.4`: 25,214개 레코드, **19.8%** - `gpt-5.2`: 247,575개 레코드, **0.34%** - `gpt-5.3-codex`: 13,333개 레코드, **0.0%** - `gpt-5.3-codex-spark`: 26,179개 레코드, **0.0%** - 월별 exact-516 클러스터링은 2026년 5월에 급증함 - 2월: **0.11%** - 3월: **2.45%** - 4월: **4.25%** - 5월: **53.30%** - 6월: **35.84%** - 같은 기간 전체 추론 토큰 강도는 낮아짐 - 평균 reasoning tokens: 2월 268.1 → 5월 106.9 → 6월 168.5 - P90 reasoning tokens: 2월 772 → 5월 344 → 6월 515 - 이 조합 때문에 exact-516 증가는 **단순한 추론 토큰 사용량 증가**로 설명하기 어렵다는 문제가 제기됨 ### 요청된 내부 검증 항목 - Codex 팀에 `gpt-5.5`의 추론 예산, 라우팅, 절단, fallback, scheduler 동작이 516/1034/1552 근처 종료를 유발하는지 조사해 달라고 요청함 - 해당 동작이 의도된 것이라면 exact 516이 정상 종료 지점인지, 예산 상한인지, degraded tier인지, 다른 내부 임계값인지 알려 달라는 요청이 포함됨 - 제안된 검증 절차: - 모델별 `reasoning_output_tokens`가 포함된 `token_count` 이벤트 조회 - `0`, `516`, `1034`, `1552` exact-value 카운트 비교 - 모델·일자별 `count(reasoning_output_tokens = 516) / count(reasoning_output_tokens >= 516)` 계산 - `gpt-5.5`와 `gpt-5.2`, `gpt-5.4`, Codex 전용 변형 비교 - GPT-5.2와 GPT-5.5에서 복잡한 작업을 다시 실행하고, exact-516 응답과 더 긴 reasoning 응답을 분리해 품질 평가 ### 댓글에서 나온 추가 재현과 교차 데이터 - GitHub Actions는 관련 중복 후보로 [#29353](https://github.com/openai/codex/issues/29353)을 표시함 - 여러 사용자가 같은 문제를 겪었다고 댓글을 남겼고, 한 사용자는 이전 이슈보다 이번 이슈가 더 **데이터 기반 보고**라고 평가함 - `sinnet3000`은 Codex CLI와 OpenCode의 로컬 세션 저장소에서 교차 클라이언트 데이터를 제시함 - Codex `~/.codex/sessions`와 `archived_sessions`의 약 22.7k `token_count` 이벤트에서 `gpt-5.5`는 records 4,300, >=516 156, exact 516 88, 비율 **56.4%** - OpenCode `opencode.db`의 약 32.1k assistant messages에서 `gpt-5.5`는 records 6,977, >=516 126, exact 516 90, 비율 **71.4%** - Kimi, DeepSeek, MiMo, MiniMax, Gemini, Qwen, GLM 등 볼륨이 있는 non-OpenAI 모델 합산 약 24k records에서는 exact 516이 0건 - 이 데이터는 답의 정오답을 평가하지 않았고, exact 516 클러스터링 존재 여부만 확인했다는 caveat가 붙음 - `kyleboddy`는 Windows 11 Codex Desktop에서 관련된 행동 차이를 보고함 - 5개 fresh projectless Codex Desktop threads에서 같은 candy prompt를 실행 - 빠른 direct-`final_answer` 실행은 `29`를 반환해 오답 - 더 느리고 `commentary`가 먼저 나온 실행들은 `21`을 반환해 정답 - fresh Windows-host Desktop threads에서는 exact `reasoning_output_tokens`를 추출하지 못했으므로 해당 오답 실행이 정확히 516이었다고 말할 수는 없다고 밝힘 - 같은 사용자는 로컬 세션 메타데이터에서 `gpt-5.5 / xhigh`의 고정값 클러스터링도 집계함 - records 16,141, sessions 51, 평균 reasoning 149.7, P90 429 - `=516` 438건, `>=516` 1,298건, 비율 **33.74%** - `=1034` 52건, `=1552` 14건, `=2070` 16건, `=2588` 12건, `=3106` 5건 ### Codex Linux CLI 재현 결과 - `kyleboddy`는 Codex Linux CLI에서도 동일 candy prompt를 사용해 재현했다고 함 - 환경: - 제품: **Codex CLI** - 버전: `codex-cli 0.142.5` - 플랫폼: Ubuntu Linux `6.8.0-111-generic`, x86_64 - Node: `v24.14.0` - 인증 모드: ChatGPT - 테스트 모델: `gpt-5.5` - reasoning efforts: `xhigh`, `high` - 대조 모델: `gpt-5.4 xhigh` - prompt는 외부 도구를 쓰지 말고, 촉각으로 shape를 구분할 수 있는 candy bag 문제의 최소 draw 수를 묻는 내용임 - 기대 답은 brute-force enumeration으로 **21**이라고 독립 확인함 - shape를 촉각으로 구분할 수 있으므로 9 round + 12 star candies를 계획할 수 있다는 설명이 포함됨 - 결과: - `gpt-5.5 xhigh` 완료된 4회 실행은 모두 `reasoning_output_tokens = 516`이었고, 최종 답 `23`, `26`, `28`, `15`로 모두 오답 - `gpt-5.5 high` 3회 실행도 모두 `516`이었고, 답은 `22`, `21`, `27`로 1회만 정답 - `gpt-5.4 xhigh` 3회 실행은 6211, 12274, 10876 reasoning tokens를 사용했고 모두 `21`로 정답 - 이 결과는 `gpt-5.5`가 Codex에서 **고정 516-token 경로**에 들어갈 수 있고, 그 경로가 작업 품질 저하와 상관될 수 있다는 좁은 주장에 힘을 보탬 ### 임시 우회책 제안 - `dzshzx`는 upstream fix를 기다리는 동안 Codex 앞단에 두는 로컬 Responses 프록시 [codexcomp](https://github.com/dzshzx/codexcomp)를 제안함 - 동작 방식은 `518·n−2` 패턴을 절단으로 간주하고 추론을 이어가는 구조임 - `reasoning_tokens == 518·n − 2`, 즉 516, 1034, 1552 등으로 끝난 round를 **truncated**로 처리 - tentative output을 버리고, 해당 round의 reasoning items와 `encrypted_content`를 다음 입력으로 재생 - `phase:"commentary"`와 `"Continue thinking..."` 메시지를 함께 넣음 - 모든 round를 하나의 downstream response로 접어 Codex에는 완성된 답처럼 보이게 함 - 설정은 공식 top-level `openai_base_url` 키를 사용함 - 예: `openai_base_url = "http://127.0.0.1:8787/v1"` - built-in `openai` provider는 유지돼 session grouping, remote compaction, remote-control이 계속 동작한다고 함 - 실제 로그 예시는 두 번 연속 516 이후 세 번째 round에서 clean 종료하고 최종 답이 맞은 사례를 제시함 - round 1: reason=516 → continue - round 2: reason=516 → continue - round 3: reason=291 → clean - caveat: - **비공식** 우회책이며 upstream의 비계약 동작에 의존함 - continuation round는 추가 실제 토큰을 사용함 - `n` window와 3-continuation cap으로 제한됨 - loopback-only, auth passthrough이며 credentials를 읽거나 저장하지 않는다고 함 ## Comments ### Comment 61284 - Author: neo - Created: 2026-07-05T19:42:57+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48789428) - 이건 꽤 심각해 보이고, **codex cli**로도 쉽게 재현됨 추론이 필요한 퍼즐 프롬프트를 주면 가끔 갑자기 끊긴 듯 정확히 **516개 사고 토큰**만 쓰고 틀린 답을 냄 6000~8000개 사고 토큰을 쓰는 경우에는 정답을 내놓음 적응형 사고(adaptive thinking) 쪽 문제일 수도 있고, 로컬 모델은 조용한 서버 측 변경을 걱정하지 않아도 된다는 점에서 또 한 표가 감 같은 프롬프트를 10번 돌렸더니 4번이 이 516 토큰 문제였고, 그 4번은 모두 오답이었음. 표본은 작지만 5.5 xhigh가 거의 절반 확률로 단락되어 성능이 떨어질 수 있어 보임 - **적응형 사고**에는 철학적으로도 문제가 있다고 봄. 생각하기 전에 사고 예산을 얼마나 배정할지 찍는 방식인데, LLM 맥락에서는 필요한 사고량, 즉 토큰 생성량을 미리 알 방법이 거의 없을 것 같음 문제 공간은 무한히 넓고, 프롬프트 간 유사성만으로 얼마나 생각해야 할지 판단하기 어렵다. 모델은 이미 사고 예산에 도달하기 전에도 생각을 멈춤 왜 적응형 사고를 구현하는 데 이렇게 많은 노력을 쓰는지 모르겠고, 차라리 모델이 **사고 종료 토큰**을 더 잘 내도록 훈련해야 하는 것 아닌가 싶음 땜질처럼 느껴짐. 모델은 적당한 양의 추론을 하도록 훈련되어야 함: 추론 → 남은 불확실성 추정 → 계속할지 판단 → 더 추론 → 반복 - 로컬 모델도 **설정 오류**는 걱정해야 함. 전문가들도 틀리기 때문에, 제공자마다 로컬 모델 성능이 들쭉날쭉함 - 시간대나 요일별 테스트에서 패턴이 보이는지 궁금함. 예를 들어 업무 시간 피크에 단락 현상이 더 자주 발생하는지 볼 수 있을 듯함 - 그 낭비된 토큰 비용도 사용자가 내는 거라면, **환불 요청**을 하는 게 좋을 수 있음 - 거의 매일 품질이 계단식으로 떨어지는 걸 겪었고, 보통 xhigh를 썼음 올해 초 Codex의 뛰어나게 꼼꼼한 코딩에 의존하던 경험은 사라졌고, 간헐적으로 말도 안 되게 멍청한 구현이 나와서 OpenAI가 이 문제를 진지하게 다루기 전까지 **Claude**로 갈아탔음 개인적으로 몇 달째 보고 있는데, OpenAI가 심각하게 받아들이는 것처럼 보이지 않았음 - 3개월 전에는 Claude가 너무 멍청해져서 **Codex**로 옮겼고, 6개월 전에는 그 반대였음. Codex든 Claude든 언젠가는 둘 다 골탕 먹임. 그래도 Codex가 아마 덜한 편임 - 6월 초부터 **5.5의 신뢰성**이 내 경험상 Claude 수준으로 떨어진 걸 느꼈음 그래서 5.5 high → 5.5 xhigh → 5.4 high로 옮겨 왔음 5.4 high는 지난 3주 동안 완전히 안정적이었고, 지금은 거기에 만족함 가끔 5.5 xhigh로 작업을 돌려 100% 안정 상태로 돌아왔는지 확인하지만, 지금은 이 신뢰성 문제를 고치기보다 5.6 출시를 기다리는 쪽이라고 보고 있음 - 이런 문제를 기술적 문제라고 믿지 않음. 고치려면 돈이 많이 드는데, 사용자가 충분히 많이 내지 않으니 **성능을 낮추는 사업적 결정**이라고 봄 - 데자뷔 같음. 4월의 **Claude Code 성능 회귀**와 똑같아 보임. 그때 Claude 구독을 끊고 Codex로 옮겼음 이제는 둘 다 토큰당 과금으로 써 보고, 대부분의 작업은 Fireworks의 GLM 5.2를 쓰다가 필요할 때만 대형 모델에 돈을 쓰는 걸 생각 중임. 다만 손익분기점이 맞을지는 확신이 없음 - 토큰당 과금에 대해 나도 같은 반응이었지만, 두 연구소 모두 고객을 **토큰당 소비**로 옮기는 게 경제적으로 유리하다는 점 때문에 원칙적으로 피하고 싶어짐 의도적이지 않더라도, 품질이 저하된 제품에서 이익을 얻는 구조를 받아들이거나 가능하게 만들고 싶지 않음 원래 ChatGPT 출시 이후 어느 때보다 **오픈소스 모델**과 열린 실행 환경, 예를 들면 Pi 같은 것들이 훨씬 매력적으로 보임 - 맞음. 나도 그 일 때문에 Claude Code를 끊고 Codex로 바꿨음 이제는 이런 헛소리를 다시 걱정하지 않으려면 **65,000달러**를 어떻게 추가로 벌 수 있을지 생각 중임. OpenRouter 같은 것의 경제성은 알고 있음 2008년쯤 “클라우드”가 마케팅 용어로 떠오르던 때가 떠오름. 풍부한 클라이언트에 대한 기대를 낮추고, 로컬 소유권을 깎아내리는 구독 모델로 회사 마진을 키우는 포장처럼 보였음 그 뒤 “진짜 자유·오픈소스 소프트웨어”에 대한 열광과 절대주의에 질려서, 내가 어렸다고 생각하고 넘어갔음 사실 많은 구독 모델은 어느 정도 이해하거나 참을 수 있음. 소프트웨어 만드는 데 돈이 많이 들고, 2026년에 Photoshop 연간 업그레이드 가치를 200달러로 보는 건 공정하지 않을 수 있음. 다만 20년 동안 잘 되던 UI를 변덕스럽게 바꾸고 고전 색상 견본 같은 걸 아예 없애는 건 어리석음 그러면 월 200달러를 내는 업무 필수 도구인 Codex로 고전 견본 플러그인을 만들 수는 있음 내 토큰 사용량에 월 200달러가 공정한가? 아주 많이 쓴 달에는 10억 토큰쯤 썼을 수도 있음 하지만 바로 그게 문제임. 이들이 구체적으로 어떤 수익성이 맞는지 모르는 채 끝없이 레버를 당길 것이고, 부채 만기 같은 찻잎점을 보면 적어도 2030년이나 2032년까지는 그럴 것 같음 그런 걸 전혀 생각하고 싶지 않음. 모델 선호도와 성능 저하를 평가하고, 실제로 내가 돈 받고 만들고 유지하는 산출물에 쓰는 출력에 어떤 미스터리한 백엔드 실험이 돌고 있는지에 맞춰 AI에게 말하는 뉘앙스를 계속 업데이트하고 싶지 않음 AI는 도구와 공동 작업자 사이 어딘가인데, 추론 단계에서 잘 이해되지 않은 손잡이와 레버를 만지작거리며 생기는 변덕스러운 “성격” 변화가 미치게 함. 그래서 구석에 둔 박스를 가리키며, 나 말고는 아무도 바꾸지 않는 출력 품질을 정확히 알고 싶음 - Fireworks? - “느낌 기반” Claude Code 성능 회귀라는 거 맞음. 비결정적 시스템에서 **일관된 성능**을 기대하지 말아야 함. 성능 저하를 뒷받침하는 실증 자료는 전혀 없음 최근에 계단식으로 바뀐 건 모델 성능이 아니라 코더들의 징징거림과 불평의 양임 - **Codex가 오픈소스**라서 이런 이슈가 공개적으로 드러나고 다뤄질 수 있다는 점이 좋음 - 하지만 이건 모델 동작이고, 공개 이슈 추적기가 있다는 점은 코드만 없을 뿐 Claude Code와 같지 않나 싶음. 이런 문제에서는 [https://github.com/anthropics/claude-code]()와 무엇이 다른지 모르겠음 Codex가 오픈소스인 건 전반적으로 고맙지만, 이 부류의 문제에서는 모델이 여전히 닫혀 있으니 큰 의미가 없어 보임 - OpenAI는 전반적으로 Anthropic보다 훨씬 더 열려 있고 실제 기업답다고 느낌. Anthropic은 그냥 **블랙박스**임 - 기억이 나쁜 것일 수도 있지만, 토큰 사용량과 코드 품질 기준으로는 **5.3**이 최고였던 것 같음. 5.5가 더 잘 작동하긴 하지만 토큰을 완전히 갈아 먹음 - 나만 그런 게 아님. **5.3-codex**는 출력 품질과 비용의 균형 면에서 훌륭한 모델이었다고 봄 5.5나 Opus와 달리 거의 모든 작업에 쓸 수 있을 만큼 싸고 효율적이면서도 꽤 좋았고, Sonnet보다 선호했음 - 몇 주 전에 5.3은 내 기준으로 못 쓸 상태가 됐음. 그냥 멈추거나 형편없는 답을 냈음 - 며칠 전에 OpenAI가 획기적인 최적화로 **연산 비용을 절반**으로 줄였다고 누가 여기서 말했던 것 같은데, 그게 이건가? - 그건 The Information 기사였지만, 잘 쓰인 글처럼 보이진 않았음. 작성자가 LLM 작동 방식을 충분히 아는 기술 전문가라서 내부 소문을 신뢰성 있게 평가할 수 있다는 느낌은 받지 못했음: [https://www.theinformation.com/newsletters/ai-agenda/openai-...]() “OpenAI 엔지니어들이 이달 초 일부 동료들에게 새로 발견한 최적화 덕분에 기존 모델 실행, 즉 추론 비용을 절반 이상 줄이는 방법을 찾아냈다고 말했다”고, 그 논의를 아는 사람이 전했다는 내용이었음 - 그 소문은 OpenAI 자체가 아니라, 사태 이후 OpenAI에서 갈라져 나온 그룹 중 하나, 아마 **Thinking Machines**가 돌파구를 만들고 OpenAI에 제안 중이라는 얘기로 이해했음. OpenAI가 아직 실제로 구현한 건 아니라고 봄 - 나의 경우 암호화된 추론 내용을 base64 문자열 길이로 보면 이 효과가 나타남. 하지만 서버가 보고하는 **추론 토큰**에서는 나타나지 않음 그래서 순수하게 암호화나 난독화의 일부라고 생각했고, 실제 문제는 아니라고 봄 GPT의 가장 큰 단점은 사고 과정이 암호화되어 있어서 Kimi, GLM, DeepSeek보다 더 블랙박스라는 점임. 그래도 사고 요약은 받을 수 있으니 어색하지만 쓸 수는 있음 - 드물게 “모델을 멍청하게 만들었다”는 말이 평소의 사용자 망상이 아니라 실제로 **모델을 멍청하게 만든 경우**인가? - 이건 오히려 추론 엔진이나 에이전트 실행 환경의 결함 또는 설정 오류처럼 보임 이슈 상세 내용은 의도적인 몰래 약화의 증거가 아니고, 오히려 반대에 가까움. 근본 원인이 조잡하고, 일반 사용자가 독립 검증 가능한 정확한 세부사항으로 보고할 만큼 딱히 은밀하지도 않음 “평소의 사용자 망상”이라는 표현은 공정하지도 취향에 맞지도 않음. 문맥 창을 삼켜 이어지는 출력을 뱉는 마법 싱크대 같은 API 엔드포인트만 갖고 있으면 남는 건 주관적 판단과 추측, 의심뿐임 표준화된 모델 테스트 스위트가 있어도, 몰래 약화라고 주장하는 건 결국 그 회사 사람들의 의도를 읽는 일임. 명시적 의도나 기반 인프라 다운그레이드 없이도 모델 품질은 떨어질 수 있음 농담 섞인 음모론이나 실제 약화 가능성을 검토하는 것 자체가 정신병은 아님. 심리 진단 용어를 이렇게 남용하는 흐름이 마음에 들지 않음 물론 이런 판단에 지나치게 확신하는 사람들도 있겠고, 그들에게는 해당될 수 있겠지만 그건 소수임. 결국 과장일 뿐이고, 누구에게도 도움이 되지 않음 - 프런티어 모델 구독을 팔아 놓고 시간이 지나면서 빠르게 너프하는데 아무도 얘기하지 않는다는 게 웃김 서버 측에서 조용히 **추론 강도**를 낮추면 할인이라도 해줘야 함 반면 나는 5.5-high를 매일 병렬 다중 작업 흐름에서 쓰고 있는데, 주간 한도를 간신히 다 쓰는 정도임. 계획과 구현을 전부 따라가 읽기엔 내가 Human-as-a-Service로 충분히 빠르지 못함. 그런 면도 있긴 함 - 처리량 최적화를 위해 **추론 추론을 512 토큰 배수** 단위로 묶어 배치 처리하는 게 분명해 보임 - 내 첫 생각은 llama.cpp를 기준으로 보면 **추론 예산 매개변수** 조정이 이런 결과를 낳았을 수 있다는 것이었음. 하지만 OpenAI 발표 없이는 정확히 알 방법이 없음 피크 시간대 수요에 맞춰 확장하는 매우 부정직한 방식일 수도 있음. 이 주제에서 이미 모델 성능 체감의 주관성을 비웃는 사람들이 있다는 건 알지만, 적어도 5월 한 달간 내 테스트에서는 미국이 온라인으로 들어오는 시간대에 모델이 덜 똑똑해 보였음 몇 주 전 회사 블로그 글에서도 겹치는 시간대에 더 일관된 패턴으로 체감돼서 이 점을 짚어야겠다고 느꼈음. 추가 분석을 위해 세션 로그를 저장해뒀어야 했음 [https://webesque.agency/blog/2026-06-19-llms.html]() - 표준은 **연속 배치 처리**를 쓰는 것 아닌가? 연속 배치 처리를 쓴다면 생성 토큰 길이가 왜 중요하고, 왜 길이별로 묶는지 궁금함. 아니라면 왜 안 쓰는지와 그 절충점이 궁금함