Claude Code가 갑자기 둔해졌다면: 오래된 세션의 추론 기록 버그 구별하기

한동안 열어 둔 코딩 세션을 다시 쓰자 에이전트가 같은 설명을 되풀이하고, 앞서 선택한 수정 이유를 잊은 듯한 도구 호출을 한다면 무엇을 의심해야 할까요? 모델이 바뀌었다는 결론은 빠릅니다. 같은 모델이라도 제품이 요청을 구성하는 방식과 오래된 세션의 상태가 달라지면 체감 품질은 달라질 수 있습니다. Simon Willison의 링크 글이 짚은 Anthropic의 2026년 4월 23일 사후 분석은 그 차이를 구체적으로 보여 줍니다.

이것은 현재 진행 중인 장애 안내가 아닙니다. Anthropic은 세 가지 문제가 모두 4월 20일의 v2.1.116까지 해결됐다고 보고했습니다. 이 글은 그중 오래된 세션의 추론 기록 정리 버그를 중심으로, 다른 두 변경을 구별하는 독자용 진단 순서를 만듭니다. 제품 공급자의 사후 보고에 근거하며, 독립적인 영향 사용자 수 조사나 모델 재실행 결과는 아닙니다.

하나의 '퇴화'처럼 보인 세 가지 변경

공급자 보고서의 구분을 먼저 고정해야 숫자와 원인을 섞지 않습니다. 3월 4일 Claude Code의 기본 추론 노력 수준을 high에서 medium으로 낮춘 변경은 긴 지연을 줄이려는 선택이었고, 사용자의 품질 피드백 뒤 4월 7일 되돌렸습니다. 이는 Sonnet 4.6과 Opus 4.6에 영향을 주었습니다. 3월 26일에는 한 시간 넘게 유휴 상태였던 세션의 오래된 thinking을 한 번 정리하도록 만든 최적화에 결함이 들어갔습니다. 해당 버그는 4월 10일 v2.1.101에서 수정됐습니다. 4월 16일의 별도 시스템 프롬프트 변경은 도구 호출 사이와 최종 답의 길이를 제한했고, 4월 20일 되돌렸습니다. 마지막 변경에는 Opus 4.7도 해당했습니다.

Anthropic 사후 분석의 세 별도 변경과 수정일을 재배열한 자체 도식. 모두 세션 버그는 아니다. 출처: www.anthropic.com/engineering/april-23-postmortem.

이 변경들은 Claude Code, Claude Agent SDK, Claude Cowork 제품 경로에 걸쳐 나타났지만 API와 추론 계층 자체는 영향을 받지 않았다는 것이 Anthropic의 설명입니다. 모두를 ‘모델 가중치가 나빠졌다’ 또는 ‘오래된 세션 하나 때문’으로 합치면 점검할 대상을 잘못 고르게 됩니다. 날짜와 모델·제품의 적용 범위가 다르므로 체감도 일관되지 않을 수 있었습니다.

한 번만 비우려다 매 턴 비웠다

원래 설계는 한 시간 넘게 방치한 세션을 재개할 때, 이미 캐시에서 밀려난 오래된 추론 블록을 한 번 정리해 캐시 미스 시 다시 보내는 입력 토큰을 줄이는 것이었습니다. 이후에는 정상적인 추론 이력을 다시 보내야 했습니다. 구현은 clear_thinking_20251015 헤더와 keep:1을 사용했습니다. 그런데 결함이 있는 플래그는 유휴 기준을 넘긴 그 프로세스의 이후 모든 턴에 적용됐습니다. 요청마다 가장 최근 추론 블록만 남기고 이전 블록들을 버린 셈입니다. 이는 대화의 모든 텍스트가 사라졌다는 뜻도, 모델이 원래 한 블록밖에 기억할 수 없다는 뜻도 아닙니다.

보고서의 thinking 정리 기전을 자체 비교. 전체 대화 삭제나 모델의 일반적인 기억 한계를 뜻하지 않는다. 출처: www.anthropic.com/engineering/april-23-postmortem.

도구를 사용 중일 때 후속 메시지가 새로운 턴을 시작하면 현재 턴의 추론까지 떨어질 수 있었다고 보고서는 설명합니다. 앞서 파일을 고친 이유를 잃은 상태에서 다음 도구를 선택하니, 반복·건망증·이상한 도구 선택이 나타났습니다. 계속된 추론 블록 제거로 뒤따르는 요청의 캐시 미스도 반복됐습니다. 사용 한도가 빨리 닳는다는 제보를 이 현상과 연결하지만, Anthropic의 표현은 그것이 원인이라고 믿는다는 수준입니다. 영향률, 캐시 적중률 변화, 비용 증가액은 제시되지 않았습니다.

Simon의 글에는 자신도 한 시간 이상 묵힌 Claude Code 세션을 자주 쓴다는 경험담이 있습니다. 이는 어떤 사용 패턴에서 문제가 눈에 띌지 보여 주는 사례이지, 전체 사용자에게 얼마나 흔했는지를 나타내는 표본은 아닙니다. 내부 평가가 초기에 문제를 재현하지 못했고 내부 전용 실험과 thinking 표시 변경도 문제 확인을 가렸다는 사후 설명을 함께 읽어야 합니다.

독자용 진단 순서: 무엇을 비교해 남길까

아래는 사후 분석의 기전을 바탕으로 만든 편집 진단 절차입니다. 지금의 Claude Code에서 같은 결함이 다시 발생한다는 주장이나 검증된 자동 치료법이 아닙니다.

1. 증상과 경계 기록: 반복 설명, 이전 수정 이유를 놓친 선택, 이상한 도구 호출 중 무엇이 발생했는지와 대략적인 유휴·재개 시점을 적습니다. 세션이 계속 열려 있었는지, 재시작했는지도 구분합니다. 실제 내부 헤더나 캐시 상태를 확인하지 않았다면 관찰 가능한 행동만 기록합니다.
2. 조건 비교: 같은 저장소·같은 작업을 비교하되, 오래 쉬었다 재개한 세션과 새 세션의 차이를 먼저 기록합니다. 작업 난도, 사용 모델, 제품 버전, 명시한 /effort 설정, 프롬프트를 함께 적어 놓지 않으면 차이를 세션 탓으로 귀속할 수 없습니다. 프로덕션 수정 작업에서는 똑같은 명령을 무턱대고 재실행하지 말고 복제 환경 또는 읽기 전용 비교로 제한합니다.
3. 원인 후보 분리: 재개 후의 누적 망각이라면 오래된 세션 문맥 관리라는 가설을 검토하고, 새 세션에도 일관되게 짧거나 얕은 답이 보인다면 당시 기본 effort나 출력 길이 지침 같은 별도 제품 변경도 점검합니다. 같은 증상만으로 clear_thinking_20251015가 실제로 전송됐다고 단정하지 않습니다.
4. 보고와 재검증: 재현 가능한 최소 작업 설명, 유휴 간격, 세션 신구, 버전과 모델, 적용 설정, 관찰된 출력 차이를 묶어 전달합니다. 수정 버전이 반영됐는지 확인하고 같은 조건으로 비교하되, 새 세션이 좋아졌다는 한 번의 관찰만으로 단일 근본 원인을 확정하지 않습니다.

사후 분석을 바탕으로 한 독자용 편집 절차. 검증된 장애 확진 도구나 제품 설정 화면이 아니다. 출처: www.anthropic.com/engineering/april-23-postmortem.

관찰	먼저 확인할 차이	성급한 결론을 막는 조건
오래 쉰 동일 프로세스에서 재개 이후 반복·망각	유휴 시간, 새 세션과의 비교, 도구 중 후속 턴	옛 결함의 패턴과 비슷하다는 사실만으로 현재 헤더·원인 확정 금지
새 세션을 포함해 답의 깊이가 달라짐	모델별 effort 기본값과 명시 설정	노력 설정의 변경을 모델 가중치 변경으로 부르지 않기
특히 답이 지나치게 간결해짐	적용된 시스템 프롬프트와 제품 버전	출력 길이 변경의 평가 수치를 세션 버그 효과로 옮기지 않기

3%는 별도 프롬프트 평가 1건의 결과이며 세션 버그의 측정 효과가 아니다. 원문 수치의 소속을 자체 도식화. 출처: www.anthropic.com/engineering/april-23-postmortem.

숫자의 함정과 남는 한계

4월 16일 프롬프트는 도구 호출 사이 25단어 이하, 자세한 설명이 필요한 경우를 제외한 최종 답 100단어 이하를 요구했습니다. 이후 확장된 평가 중 하나에서 Opus 4.6과 4.7 각각 3% 하락이 관찰됐다고 Anthropic은 말합니다. 그 평가의 자세한 분모나 지표를 본문이 제시하지 않았으므로 전체 코딩 성공률의 3퍼센트포인트 하락으로 바꿔 쓸 수 없습니다. 무엇보다 이 수치는 세션의 thinking 정리 버그를 측정한 값이 아닙니다. 세션 버그의 성능 하락률이나 피해 사용자 수는 이 자료에서 정량화되지 않았습니다.

이 진단 순서는 Anthropic 사후 분석에서 도출한 편집 제안이지, 특정 사용자의 장애를 확진하거나 수정 효과를 독립 실험한 결과가 아닙니다. 공급자의 결함 설명은 설계와 수정 시점을 확인하는 핵심 1차 자료이지만, 개별 사용자의 로그와 빌드를 대조하지 않고 당시 모든 품질 불만의 원인을 하나로 묶을 수는 없습니다. 실무적으로 남길 교훈은 ‘문제가 느껴지면 새 세션을 열어라’가 아니라, 모델, 제품 기본값, 세션 문맥 처리, 프롬프트를 서로 다른 원인 후보로 분리해 증거를 보존하라는 것입니다. 관련 내부 글은 실제 URL과 본문 관련성을 이 단계에서 확인하지 못해 억지로 붙이지 않았습니다.