Autocompact is thrashing 해결법 — Claude Code 컨텍스트 압축 루프 대처

Claude Code로 작업하다가 갑자기 "Autocompact is thrashing"이라는 경고가 뜨면서 대화가 멈춘 적 있으신가요? 몇 턴 지나면 또 뜨고, /clear를 눌러도 다시 뜨고 — 작업 흐름이 뚝뚝 끊기니 답답할 수밖에 없습니다. 이 오류는 정확히 어떤 상황에서 발생하고, 왜 반복되는지, GitHub 이슈와 공식 문서를 근거로 정리했습니다.

Claude Code 터미널에 "Autocompact is thrashing" 경고 배너가 뜬 화면

 

"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."

anthropics/claude-agent-sdk-python의 Issue #958과 anthropics/claude-code의 Issue #60485에서 동일한 문구가 그대로 확인됩니다. 두 이슈 모두 같은 텍스트를 보고하고 있어서, 이 메시지는 Claude Code 내부에 하드코딩된 고정 경고문으로 보입니다.

Issue #60485가 정리한 재현 조건은 이렇습니다. 루트 CLAUDE.md 24KB, .claude/CLAUDE.md 8KB, 프로젝트별 memory/ 9KB — 합쳐서 41KB 정도 되는 정상적인 자동 로드 컨텍스트를 가진 프로젝트에서 새 세션을 열고, Read 몇 개와 Bash 명령어 몇 개 정도 가벼운 작업을 몇 턴 하면 3턴 이내에 이 배너가 뜨고 매 compact 이후에도 계속 반복됩니다.

 

이 경고, 버그일까 정상 동작일까

일단 알아둘 게 있습니다. 이건 그 자체로는 버그가 아니라 의도된 가드 메커니즘입니다. Claude Code가 압축(compact)을 했는데도 컨텍스트가 3턴 이내에 다시 한계까지 차는 상황이 3회 연속 반복되면, 무한 압축 루프에 빠지는 대신 스스로 멈추고 경고를 띄우는 구조입니다.

근본 원인은 대개 하나로 좁혀집니다. 단일 파일이나 도구(tool) 출력이 컨텍스트 윈도우에 비해 너무 큰 경우입니다. 압축을 해도 그 거대한 콘텐츠가 다시 읽히면서 컨텍스트를 즉시 재충전시키고, 이 압축→재팽창 사이클이 반복되면서 thrashing으로 감지되는 겁니다. fazm.ai는 이 감지 메커니즘을 "보호 장치"로 설명하면서, "그것은 싸워야 할 버그가 아니라 신호다. 창(window) 안에 비대한 무언가가 있다는 신호"라고 서술합니다.

근데 문제는 여기서 끝나지 않습니다. Issue #60485는 자동 로드 컨텍스트가 41KB에 불과해 200K 토큰 윈도우에서 문제될 수준이 아닌데도 thrashing이 반복됐다고 보고했습니다. 버전 2.1.144부터 증상이 시작됐고, 이전 버전에서는 같은 프로젝트·같은 파일로 정상 작동했다는 점에서 autocompact 휴리스틱이나 컨텍스트 계산 로직 자체가 바뀐 회귀(regression) 버그일 가능성이 제기됩니다. 즉 "공식 설명(파일이 너무 큰 경우에만 발생)"과 "실사용 보고(컨텍스트가 크지 않은데도 발생)" 사이에 차이가 있다는 얘기입니다.

Autocompact 트리거 전후 컨텍스트 사용률 변화를 보여주는 다이어그램

 

Autocompact가 원래 어떻게 작동하는지부터 짚어보기

Claude Code의 autocompact는 대화가 컨텍스트 윈도우 한계에 가까워지면 이전 내용을 자동으로 요약해서 대화를 이어가는 기능입니다. 기술 블로그 claudefa.st에 따르면 200K 토큰 윈도우 기준으로 실제 쓸 수 있는 컨텍스트는 약 167K 토큰이고, 나머지 33K 토큰(16.5%)은 요약 처리 자체를 위한 버퍼로 예약돼 있습니다.

그런데 이 auto-compaction이 정확히 몇 %에서 트리거되는지는 소스마다 설명이 다릅니다. claudefa.st는 약 83.5% 사용률(약 167K 토큰) 근처로 설명하는 반면, hyperdev.matsuoka.com은 "이전에는 90% 이상에서 작동했으나 현재는 약 75% 사용률에서 더 일찍 트리거된다"고 설명합니다. 두 수치가 다르고, 어느 쪽도 공식 changelog에 명시된 값임을 확인하지 못했습니다 — 둘 다 스스로 "공식 문서에 명시되지 않은 관찰"이라고 인정하고 있습니다. 그러니 "정확히 몇 %에서 압축된다"는 식으로 단정하기보다는 대략적인 참고치로만 보는 게 안전합니다.

hyperdev 쪽 설명이 흥미로운 부분은 이겁니다. 과거 방식은 90% 도달 후 압축하다 보니 작업 중간에 끊기고 컨텍스트가 손실되는 문제가 있었는데, 더 이른 시점에 압축하고 현재 작업을 완료한 뒤 리셋하는 방식으로 바뀌면서 일관성이 나아졌다는 겁니다.

 

공식이 권장하는 대처법

에러 메시지 원문에 이미 1차 대처법 두 가지가 적혀 있어요.

• 파일이나 도구 출력을 한 번에 통째로 읽지 말고 더 작은 단위로 나눠 읽기
• /clear로 세션을 초기화하고 새로 시작하기

fazm.ai는 여기에 몇 가지를 더 얹습니다. /context 명령으로 현재 무엇이 컨텍스트 창을 채우고 있는지 확인하는 것, /compact focus on the API changes처럼 압축 시 보존할 내용을 지정하는 것, CLAUDE.md에 "Compact Instructions" 섹션을 추가해서 이후 모든 압축에 지침이 적용되게 하는 것 등입니다. 한계에 도달하기 전에 선제적으로 /compact를 실행하면 압축기가 더 선택적으로 동작한다는 점도 함께 소개합니다. 세션 자체를 보존하고 싶다면 --fork-session 플래그나 /branch 명령으로 한계 도달 전 깨끗한 지점에서 새 브랜치를 만들어 이어가는 방법도 있습니다.

한 가지 확실히 해둘 게 있습니다. fazm.ai는 "Claude Code의 자동 컨텍스트 압축은 완전히 비활성화할 수 없다"고 명시합니다. ~/.claude/settings.json에 autoCompactEnabled: false를 추가해도 작동하지 않는데, 이유는 그 키가 설정 스키마 자체에 존재하지 않아 무시되기 때문이라고 합니다.

근본적인 예방책으로는 claudefa.st가 제시하는 방법도 있습니다. 1M 토큰 컨텍스트를 지원하는 모델(Sonnet 5, Fable 5, Opus 4.6 이상)을 쓰면 추가 비용 없이 훨씬 넓은 여유 공간을 확보할 수 있다는 설명입니다.

 

근데 이 워크어라운드, 항상 통하는 건 아니다

여기서 정직하게 짚고 넘어가야 할 부분이 있습니다. Issue #60485의 실사용 보고를 보면 공식 워크어라운드가 항상 통하는 건 아니라는 게 드러납니다. 보고자는 "/clear는 한 번은 작동하지만 ~3턴 내에 thrashing이 재발한다", "/compact <focus>도 동일한 결과"라고 밝혔습니다. thrash 이벤트가 뜰 때마다 워크플로우가 끊기고 수동으로 /clear와 작업 재시작을 반복해야 했다는 지적입니다.

환경변수 쪽도 비슷한 사정입니다. CLAUDE_AUTOCOMPACT_PCT_OVERRIDE는 1~100 범위 값을 받아 압축 발동 퍼센티지를 직접 지정하는 환경변수로, docs.bswen.com은 40~70% 범위를 권장합니다. CLAUDE_CODE_AUTO_COMPACT_WINDOW로 유효 토큰 윈도우 크기 자체를 줄이는 방법도 있는데, 두 값 모두 새 세션부터 적용되고 재시작이 필요합니다.

문제는 Issue #42394입니다. ~/.claude/settings.json의 env 필드에 "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "95"와 "DISABLE_AUTO_COMPACT": "1"을 동시에 설정했는데도, Opus 4.6(1M 컨텍스트) + Claude Code v2.1.90 + macOS 환경에서 새 세션 시작 시 자동으로 컴팩션이 실행됐다고 보고됩니다("Cultivating… (1m 26s · ↓ 3.2k tokens)" 로그와 함께 컨텍스트가 6%로 떨어졌다는 내용). 공식 설정값이 문서상 존재하더라도 버전에 따라 기대대로 작동하지 않을 수 있다는 뜻이니, 설정을 걸어뒀다고 안심하지 말고 실제 트리거 시점이 바뀌는지 확인해보는 게 나아요.

이 워크어라운드들을 시도했는데도 반복적으로 thrashing이 발생한다면, 버전 회귀 가능성을 의심하고 다운그레이드하거나 재현 조건과 함께 공식 이슈 트래커에 등록하는 게 실질적인 대안입니다.

/context 명령 실행 화면 예시, 컨텍스트 창을 채우고 있는 항목별 비율

 

자주 묻는 질문

Q. Autocompact를 아예 끌 수는 없나요?
공식적으로는 없습니다. autoCompactEnabled: false는 스키마에 없는 키라 무시되고, DISABLE_AUTO_COMPACT=1도 여전히 컴팩션이 실행됐다는 버그 보고(Issue #42394)가 있습니다.

Q. /clear를 눌렀는데도 thrashing이 계속 뜨면요?
Issue #60485처럼 재발한다면 버전 회귀 가능성부터 의심하세요. 버전을 확인하고, 필요하면 다운그레이드하거나 재현 조건을 정리해 공식 이슈로 등록하는 게 낫습니다.

Q. CLAUDE_AUTOCOMPACT_PCT_OVERRIDE 값은 얼마로 설정해야 하나요?
docs.bswen.com은 40~70% 범위를 권장합니다. 다만 설정해도 항상 기대대로 작동하지 않을 수 있으니, 적용 후 실제 압축 시점이 바뀌는지 확인이 필요합니다.

 

컨텍스트 문제, thrashing 하나로 끝나지 않는다

Autocompact thrashing은 결국 "Claude Code가 컨텍스트를 다루는 방식" 전반의 문제 중 하나입니다. 비슷한 맥락에서 Claude Code Task Budgets로 API 비용 폭주 막는 법도 컨텍스트·토큰 소비를 통제하는 문제를 다루고 있어서 같이 보면 도움이 될 겁니다. 반대로 파일 권한 문제로 Claude Code 자체가 안 열리는 상황이라면 Claude Code EACCES 오류 해결법 쪽 체크리스트가 먼저일 수도 있고요.

컨텍스트 창이 자꾸 꽉 차서 압축이 반복된다면, 일단 /context로 뭐가 창을 채우고 있는지부터 확인해보시길 권해요. 큰 로그 파일이나 방대한 도구 출력을 통째로 읽고 있는 건 아닌지, 그 지점부터 좁혀 나가는 게 가장 빠른 길입니다.