클로드 코드 트랜스크립트 분석: '조기 압축'의 정체는 유휴 압축이었습니다
요약
본 문서는 Claude Code 세션에서 발생하는 토큰 압축(compaction) 현상에 대한 심층 분석 및 해결 가이드입니다. 특히 사용자가 자리를 비운 후 낮은 수준으로 압축되는 것은 임계값 하락이 아닌 '유휴 압축(idle compaction)'이며, 이는 settings.json 설정 변경을 통해 끌 수 있습니다. 또한 다른 세 가지 원인과 대응 명령어들을 안내합니다.
핵심 포인트
- 자리를 비운 후의 압축은 유휴 압축일 가능성이 높으며, 임계값 하락이 아닙니다.
- 유휴 압축을 방지하려면 settings.json에 "idleCompaction": false를 설정해야 합니다.
- 명령어 /context와 /autocompact로 현재 컨텍스트 창 크기 및 내용을 확인할 수 있습니다.
- 세 가지 다른 원인(auto-compact, thrashing 등)별 해결책을 숙지하는 것이 중요합니다.
원래 게재된 곳: its-tahir.com.
지난주에 제가 사용한 Claude Code 세션 중 두 개가 1M 토큰(token) 창 크기에서 약 265K 토큰 수준으로 압축(compacted)되었습니다. 이는 회귀 현상처럼 보였기 때문에, 저는 직접 기록된 트랜스크립트에서 압축 기록을 읽어보았습니다. 그 기록들은 다른 이야기를 전해주었고, 알고 보니 'Claude Code keeps compacting'이라는 문구는 사실 네 가지의 서로 다른 문제와 네 가지의 서로 다른 해결책으로 이루어져 있었습니다. 여러분의 코드도 조기에 압축되고 있나요? 어떤 경우에 해당되는지 알려주시면 좋겠습니다.
만약 사용자가 자리를 비운 후에 Claude Code가 제한치보다 훨씬 낮은 수준에서 압축되었다면, 그것은 임계값(threshold)이 낮아진 것이 아니라 유휴 압축(idle compaction)입니다. 이는 1시간 캐시가 만료되기 전에 200K 토큰 이상의 대화를 요약하는 과정이며, "idleCompaction": false를 설정하면 이를 끌 수 있습니다. 만약 다른 이유로 계속해서 압축된다면, 그것은 다음 목록 중 하나일 것이며, 각각은 다른 해결책이 필요합니다:
| 보이는 현상 | 실제 원인 | 해결 방법 |
|---|---|---|
| 자리를 비운 후 제한치보다 훨씬 낮은 수준에서 압축됨 | 유휴 압축(Idle compaction). 임계값 하락이 아님 | settings.json에 "idleCompaction": false 설정 |
| ... | ||
두 개의 명령어를 통해 어떤 경우인지 알 수 있습니다: /context는 창을 채우고 있는 내용을 보여주며, 아무 값 없이 사용하는 /autocompact는 현재 모델이 사용하는 창 크기를 보여줍니다. |
최종 확인일 2026년 10월 28일, Claude Code 2.1.312 기준.
‘Claude Code가 계속 압축된다’고 보이는 네 가지 상황이 있습니다. 해결책은 겹치지 않으므로, 먼저 증상에 맞는 것을 찾아야 합니다.
제가 직접 확인한 내용
이 글을 쓰기 전에 저는 이 기기의 Claude Code 트랜스크립트에서 압축 기록을 읽어보았습니다. 모든 압축 작업은 트리거와 토큰 카운트를 포함하는 compact_boundary 라인을 작성하므로, 언제 그리고 왜 실행되었는지 정확하게 볼 수 있습니다. 저는 대화 내용 자체가 아니라 오직 그 메타데이터만 읽었습니다.
버전 2.1.292부터 2.1.310까지의 모든 정상적인 자동 압축(auto-compaction)은 967,344에서 972,043 토큰 사이에서 발생했습니다. 이는 "약 967K 토큰"이라는 문서화된 1M 컨텍스트 모델의 기본값과 일치합니다.
그런 다음 10월 27일, 2.1.310 버전의 VS Code 확장 프로그램에서는 "trigger": "auto"로 표시된 두 개의 압축이 각각 265,565 토큰과 263,336 토큰에서 발생했습니다. 토큰 수만으로 판단하면 이는 창 용량의 4분의 1 지점에서 자동 압축이 작동한 것처럼 보입니다. 하지만 그렇지 않았습니다. 두 기록 모두 "precomputed": true를 포함하고 있었으며, 제가 긴 휴식 후에 메시지를 보낸 후 1~2초 뒤에 발생했습니다. 첫 번째는 약 세 시간 후였고, 두 번째는 약 일주일 후였습니다. 이것은 유휴 압축(idle compaction)이며, Anthropic이 VS Code 채팅 패널과 데스크톱 앱의 코드 탭에 배포하기 시작한 기능입니다.
사람들은 GitHub issue #101067에서도 같은 혼란을 겪었으며, 여기서는 자동 압축이 "281K에서 845K 토큰"에서 발생한 것을 회귀 현상으로 보고했습니다. 해당 신고자는 나중에 모든 초기 압축 기록에 "Compacted while idle, before the prompt cache expired"(프롬프트 캐시가 만료되기 전에 유휴 상태일 때 압축됨)라는 문구가 포함되어 있었으며, 이는 마지막 메시지 전 약 54분 후에 발생했음을 확인했습니다.
자신의 경우를 확인하려면 터미널(macOS, Linux 또는 Windows의 Git Bash)에서 다음 명령을 실행하십시오. 이 명령어는 저장된 기록에서 모든 압축의 트리거와 크기를 출력합니다:
grep -rh '"compact_boundary"' ~/.claude/projects/ | grep -oE '"(trigger|preTokens|precomputed)":[^,}]*'
제 컴퓨터에서는 "trigger":"auto" "preTokens":265565 "precomputed":true와 같은 줄이 출력되었습니다. precomputed: true 항목은 유휴 압축을 의미합니다.
원인 1: 자리를 비운 후에 발생하는 유휴 압축 (idle compaction)
초기 압축이 휴식 후 발생했다면, 다음 알림 중 하나를 찾아보십시오:
Compacted while idle, before the prompt cache expired
Compacted using a summary written while you were away · turn off with "idleCompaction": false in settings.json
첫 번째는 터미널의 알림입니다. 두 번째는 VS Code 채팅 패널과 데스크톱 앱 내 'Claude Code notice'라고 표시된 행에서 나타납니다.
유휴 압축(Idle compaction)은 1시간의 프롬프트 캐시가 만료되기 직전에 200,000 토큰 이상의 대화를 요약합니다. 따라서 다음 메시지를 보낼 때 전체 기록을 다시 처리하는 비용이 들지 않습니다. 이것은 낮은 임계값 문제가 아니며, 자동 압축 창(auto-compact window)을 변경한다고 해서 이를 막을 수는 없습니다. 비활성화하려면 다음과 같이 설정해야 합니다:
{
"idleCompaction": false
}
이는 Claude Code 2.1.290 이상이 필요합니다. 터미널에서 /config를 사용하면 2.1.302 버전부터 Idle compaction 항목을 확인할 수 있습니다. “유휴 상태일 때 압축(Compacted while idle)”에 대한 전체 가이드에는 정확한 조건, 새로운 VS Code 및 데스크톱 동작 방식, 그리고 이 기능을 켜두는 것이 적절한 경우에 대해 설명되어 있습니다.
원인 2: 작은 자동 압축 창(auto-compact window)
만약 항상 같은 지점에서 압축이 발생한다면, 창(window)을 확인해 보세요. 값을 지정하지 않고 /autocompact를 실행합니다. issue #101067 보고서에서 대화 상자는 Opus 5.5의 현재 설정: 1m 토큰 (이 모델의 기본값)을 보여주었고, Esc를 누르는 것은 이를 '변경하지 않음(unchanged)'으로 남겨두었습니다. 이 1M이 바로 창 크기입니다. 1M 모델에서는 압축이 그보다 약간 낮은 지점, 즉 약 967K에서 발생합니다.
창을 설정하지 않은 경우, Claude Code는 모델의 컨텍스트 한계에서 압축이 발생하며, 이는 모델 구성 문서에 명시된 예외 사항들이 있습니다:
| 세션 | 압축 시점 |
|---|---|
| 네이티브 1M 모델: Fable 모델, Sonnet 5 이상, Haiku 5.5, Opus 4.7 이상 | 약 967K 토큰 |
| ... |
더 작은 창을 설정할 수 있는 네 가지 위치가 있으며, 우선순위가 높은 순서부터 낮은 순서까지는 다음과 같습니다:
CLAUDE_CODE_AUTO_COMPACT_WINDOW환경 변수입니다. 이 변수는 모든 설정을 덮어쓰며, 설정된 상태에서는/autocompact가 이를 보고합니다.--autocompact플래그를 사용하여 한 번 실행할 때:claude --autocompact 500k./autocompact <크기>: 사용자의 설정(user settings) 내modelSettings에 현재 모델용으로 저장됩니다. 버전 2.1.288부터는 모델별로 적용되므로, Opus를 위해 설정한 창 크기는 Sonnet에는 적용되지 않습니다.- 모든 모델을 위한 설정 파일의 **
autoCompactWindow**입니다.
이 모든 방법은 100K에서 1M 토큰까지 값을 사용하며, Claude Code는 이 값을 해당 모델의 실제 창(window) 크기로 제한합니다. 기본값으로 돌아가려면 /autocompact auto를 실행하고 환경 변수가 설정되어 있다면 이를 해제해야 합니다.
환경 변수는 숫자를 다르게 읽습니다. /autocompact와 --autocompact에서는 단순한 200은 200,000을 의미합니다. 반면, CLAUDE_CODE_AUTO_COMPACT_WINDOW에서 200은 200 토큰을 의미하며, Claude Code는 이를 '200 토큰으로 읽었으므로 100K 최소값으로 처리한다'고 경고합니다. 버전 2.1.304 이상에서는 200000 또는 200k를 사용해야 합니다. 이전 버전(2.1.304 미만)에서는 200k가 해당 릴리스의 변경 로그에 따라 조용히 100K 창을 설정했습니다.
왜 CLAUDE_AUTOCOMPACT_PCT_OVERRIDE가 아무 효과가 없는 것처럼 보이는가. 이 변수는 압축이 트리거되는 창 크기의 백분율(%)을 1부터 100까지 설정합니다. 이는 임계값을 낮추는 역할만 할 수 있습니다: 기본 백분율보다 높은 값은 무시됩니다. 또한 문서에는 '모델의 컨텍스트 제한 전에 압축하는 세션에서만 적용된다'고 명시되어 있습니다. 기본 세션은 제한점에서 압축되므로, 이 백분율이 적용될 여지가 없습니다.
이것이 issue #63186에서 오랫동안 제기된 불만입니다. 한 댓글 작성자는 CLAUDE_CODE_AUTO_COMPACT_WINDOW도 함께 설정했을 때만 작동한다는 것을 발견했습니다. 이때 트리거는 대략 창 크기 곱하기 백분율이 됩니다: 500,000 창에서 60%로 압축될 경우 약 300K 지점에서 발생합니다. 만약 더 일찍 압축되기를 원한다면, 창 크기를 직접 설정하는 것이 더 간단합니다.
더 빨리가 아니라 나중에 필요하신가요? 1M 모델의 경우 이미 약 967K에 도달했습니다. 200K 모델의 경우, 200K 경계가 모델의 실제 한계이므로 더 올릴 공간이 없습니다. 제 도구 사이트에서 설정 빌더를 사용하면 자동으로 autoCompactWindow와 나머지 settings.json을 작성해 줍니다.
원인 3: "Autocompact is thrashing" (자동 압축이 불안정함)
전체 메시지는 다음과 같습니다:
Autocompact is thrashing: the context refilled to the limit within 3 turns of the previous compact, 3 times in a row. A file being read or a tool output is likely too large for the context window. Try reading in smaller chunks, or use /clear to start fresh.
컴팩션이 실패한 것이 아닙니다. 작동했지만, 컨텍스트가 세 번 연속으로 가득 차 다시 채워졌기 때문에 Claude Code는 움직이지 않는 루프에서 요청을 소모하는 대신 멈춘 것입니다.
/context를 실행하고 Messages 행과 그 위의 행들을 비교해 보세요. 이것이 문서 자체의 테스트이며, 문제를 두 가지로 나눕니다:
- Messages가 가장 큰 행인 경우: 대화 내용 중 무언가가 컨텍스트 윈도우를 다시 채우고 있습니다. Claude에게 전체 파일 대신 청크(chunks), 라인 범위 또는 하나의 함수 단위로 큰 파일을 읽도록 요청하세요.
/compact keep only the plan and the diff와 같이 큰 출력을 제거하는 초점을 가지고/compact를 실행하세요. 대용량 작업은 자체 컨텍스트 윈도우를 가진 서브 에이전트(subagent)로 옮기세요. Claude가 파일을 읽기 전에 파일 크기가 얼마나 되는지 확인하려면, 토큰 카운터(token counter)에 붙여넣어 보세요. - 나머지 행들이 합쳐져 더 큰 경우: 세션 시작 시 로드되는 내용이 작업할 공간을 너무 적게 남깁니다. 이를 줄이세요.
메시지는 항상 "읽히는 파일 또는 도구 출력"의 잘못을 탓하지만, GitHub에 올라온 보고서에는 다른 세 가지 출처가 더 있습니다:
- 재주입된 지침 파일(Re-injected instruction files). issue #85489에서는 단일 파일이나 출력이 크지 않았습니다. 각 압축 작업 후, 248 KB 규모의
.claude/rules/*.md와CLAUDE.md가 재첨부되었고, 이는 포스트-압축 요약본 위에 한 번에 약 122K 토큰을 차지하며 다시 트리거 지점에 도달했습니다. 해당 세션은 1시간 48분 동안 16번 압축되었습니다. 관련성이 있을 때만 로드되는 더 작은 지침 파일이나 규칙이 이 문제를 해결합니다. - 고정된 컨텍스트에 너무 작은 창(A window too small for your fixed context). issue #100932에서는 100K의
autoCompactWindow가 세션마다 약 25K~30K 토큰 분량의 지침과 메모리를 로드하면서 공간이 매우 부족했습니다. 이로 인해 해당 세션과 그 하위 에이전트들이 몇 번의 도구 호출(tool calls) 후에 불안정해졌습니다. 보고자는 또한 메시지 내에서 "3턴" 카운트를 모델 응답 내부의 도구 루프(tool loop)에서 발견했다고 언급했습니다. 윈도우 크기를 낮췄다면, 높여야 합니다. - 과도하게 큰 MCP 도구 정의(An oversized MCP tool definition). issue #102389에서는 도구 검색(tool search)이 입력 스키마가 약 2.99 MB에 달하는 MCP 도구를 가져왔습니다. 모든 요청이 1M 제한을 초과했고, 발견된 도구가 압축 후에도 유지되기 때문에 세션이 복구되지 못했습니다. 서버를 수정하거나 연결 해제한 다음 새 세션을 시작해야 합니다.
최근 릴리스 두 개가 사용자가 겪고 있을 수 있는 사례를 수정했습니다. 2.1.307은 "많은 PDF 페이지, 이미지 또는 기타 대용량 도구 결과를 읽는 턴에서 'Autocompact is thrashing' 오류"를 수정했습니다. 2.1.309는 매우 큰 중첩된 CLAUDE.md 파일을 읽은 후 반복적으로 압축되는 세션을 수정했습니다. 버전이 뒤처져 있다면, 먼저 업데이트하십시오.
원인 4: 압축 문제처럼 보이는 미해결 버그
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기