Claude Code 품질 저하 포스트모텀과 LLM 운영의 교훈

Claude Code 성능 저하를 일으킨 추론 effort 변경, 캐싱 버그, 시스템 프롬프트의 복합 영향을 LLM 운영 관점에서 분석한다.

2026-08-14 · 최초 발행 2026-05-08

서로 다른 변경이 하나의 품질 저하로 보였다

2026년 3월 초부터 Claude Code 사용자들은 복잡한 코딩 작업에서 실수가 늘고, 답변이 반복되며, 이전 대화에서 합의한 내용을 모델이 잊는다고 신고하기 시작했다. 처음에는 기대치 상승이나 체감 편향(perception bias)이라는 해석도 나왔다. 그러나 개발자 커뮤니티의 정량적 분석이 쌓이면서 실제 품질 저하라는 공감대가 형성됐다.

Anthropic은 4월 23일 엔지니어링 블로그에 An update on recent Claude Code quality reports라는 포스트모텀을 공개했다. 설명의 핵심은 단일 장애가 아니었다. 추론 effort 다운그레이드, 캐싱 로직 버그, 장황함을 억제하는 시스템 프롬프트가 각각 별도로 도입됐고, 약 6주 동안 영향 구간이 겹쳤다.

03/0803/1503/2203/2904/0504/1204/19추론 effort 다운그레이드 (high→medium) 캐싱 로직 버그 (thinking 클리어 오류) 추론 effort 롤백 캐싱 버그 수정 (v2.1.116) 장황함 억제 시스템 프롬프트 (25단어 제한) 시스템 프롬프트 롤백 포스트모텀 발행 + 한도 초기화 원인 1원인 2원인 3수정Claude Code 성능 저하 타임라인

응답 속도를 위해 낮춘 추론 effort

Anthropic은 3월 4일 Claude Code의 기본 추론 effort를 high에서 medium으로 변경했다. high 설정에서 인터페이스가 멈춘 것처럼 보이는 UI 레이턴시 문제를 줄이려는 조치였다.

하지만 effort 감소는 깊은 추론이 필요한 작업의 품질 저하로 이어졌다. 코드 리팩토링이나 멀티 파일 의존성 추적, 아키텍처 설계처럼 여러 조건을 함께 검토해야 하는 태스크에서 영향이 두드러졌다.

이 변경은 4월 7일 롤백됐다. Anthropic은 사용자가 기본적으로 높은 지능을 원하며, 단순한 태스크에서는 낮은 effort를 선택할 수 있어야 한다는 교훈을 명시했다. 응답이 빨라지는 것과 사용자가 원하는 작업을 정확하게 끝내는 것은 같은 품질 지표가 아니었다.

유휴 세션에서 반복된 thinking 히스토리 초기화

3월 26일에는 캐싱 최적화 업데이트가 배포됐다. 의도한 동작은 유휴 세션의 오래된 thinking 히스토리를 1시간 후 단 한 번 제거하는 것이었다. 실제로는 1시간 동안 활동이 없었던 세션에서 이후 모든 턴마다 thinking 히스토리가 초기화됐다.

장기 세션일수록 문제가 선명하게 드러났다. 모델은 앞서 설명한 코드 구조를 다시 묻거나, 이미 결정한 설계를 무시하고, 비슷한 답변을 반복했다. 복잡한 코딩 작업을 여러 단계로 진행하던 사용자의 관점에서는 모델이 작업 도중 기억을 잃는 것처럼 보였다.

Anthropic은 이 버그를 4월 10일 v2.1.116에서 수정했다.

의도한 동작실제 버그 동작세션 시작KV 캐시 초기화 1: 추론 + KV 캐시 누적 2: 이전 KV 캐시 재사용 +추가 누적...세션 유휴1시간 이상캐싱 버그발생 지점thinking 히스토리1회 클리어이후 정상 캐시 유지이후 모든 턴에서thinking 히스토리반복 클리어모델이 이전 맥락을반복해서 잊고중복 응답 생성

이 문제는 캐시 무효화(cache invalidation) 조건을 관리하는 상태 변수에서 발생했다. “마지막 활동으로부터 1시간 경과” 조건을 나타내는 플래그가 첫 번째 정리 이후 올바르게 리셋되지 않았다. 플래그가 계속 조건 충족 상태에 머물면서 다음 턴에도 같은 정리 작업이 실행됐다.

LLM의 캐싱 문제는 일반적인 장애와 다른 모습으로 나타난다. 명확한 에러 메시지나 스택 트레이스 대신 응답 일관성이 떨어진다. 세션 초반과 후반의 품질이 달라지고, 모델이 기존 맥락을 반복해서 놓치며, 세션이 길어질수록 품질이 낮아지는 패턴이 관찰된다.

짧은 중간 응답이 에이전트의 계획 공간을 줄였다

4월 16일에는 도구 호출 사이의 응답을 25단어 이하로 제한하는 시스템 프롬프트 인스트럭션이 추가됐다. 목적은 불필요하게 긴 설명을 줄이는 것이었지만, 실제 결과는 코딩 품질의 측정 가능한 저하였다.

코딩 에이전트는 도구를 한 번 호출한 뒤 결과를 해석하고, 다음 행동을 계획하며, 오류 가능성을 검토한다. 중간 응답 공간을 강하게 제한하면 이 과정도 짧아진다. 특히 여러 파일과 의존성을 함께 다루는 작업에서는 다음 단계로 넘어가기 전에 검토해야 할 조건을 충분히 다루지 못할 수 있다.

이 시스템 프롬프트는 도입 4일 뒤인 4월 20일 롤백됐다.

Think Budget이 바꾸는 추론 깊이

LLM의 추론 effort는 Think Budget, 즉 사고 토큰 예산과 Chain-of-Thought(CoT) 단계 수를 통해 제어된다. Claude에서는 thinking 블록에 할당되는 토큰 수가 추론 깊이를 결정한다.

Think Budget은 모델 내부 추론에 사용되며 최종 응답에는 포함되지 않는다. Budget이 높으면 더 긴 사고 체인을 구성해 복잡한 문제를 처리할 수 있다. 낮은 Budget은 처리 속도에 유리하지만, 복잡한 태스크에서는 품질이 떨어질 수 있다.

단순 태스크(조회·요약)중간 태스크(단일 파일 수정)복잡 태스크(멀티 파일 리팩토링)태스크 복잡도분류Think Budget결정Low Budget빠른 응답Medium Budget균형High Budget깊은 추론응답 레이턴시: 낮음추론 품질: 기본응답 레이턴시: 중간추론 품질: 양호응답 레이턴시: 높음추론 품질: 최고

effort를 조절할 때는 태스크 성공률(task success rate), 사용자 재시도율(retry rate), 레이턴시와 만족도의 상관관계를 함께 봐야 한다. effort를 낮춘 뒤 복잡한 태스크의 성공률이 얼마나 변하는지 확인해야 하며, 품질 저하로 재시도가 늘면 줄어든 토큰 비용이 다시 상쇄될 수 있다. 레이턴시 감소가 실제 만족도 상승으로 연결되는지도 별도의 검증 대상이다.

이번 사건에서 빗나간 부분은 레이턴시가 줄면 사용자 만족도가 높아질 것이라는 가정이었다. 사용자는 빠르지만 작업을 끝내지 못하는 응답보다 시간이 더 걸리더라도 복잡한 작업을 수행하는 응답을 원했다.

KV 캐시와 장기 세션의 상태 관리

LLM 추론 캐싱은 주로 Key-Value(KV) 캐시로 구현된다. 트랜스포머 어텐션 연산에서 앞서 계산한 Key·Value 행렬을 재사용해 같은 컨텍스트를 다시 처리하는 비용을 줄이는 방식이다.

Claude Code에서는 thinking 히스토리, 즉 이전 추론 과정의 결과도 KV 캐시로 관리된다. 장기 세션에서는 이 히스토리가 계속 누적되어 캐시 크기가 커지므로 주기적인 정리(pruning)가 필요하다. 문제는 무엇을 언제 지울지 결정하는 무효화 조건이다.

캐시를 지나치게 빨리 무효화하면 계산 비용이 증가한다. 너무 늦게 무효화하면 구식 컨텍스트가 남아 품질을 해칠 수 있다. 이번 사고는 정리 시점을 판단하는 조건 자체보다, 한 번 실행된 조건의 상태를 이후 턴에서 어떻게 해제하는지가 중요하다는 점을 보여줬다.

품질 장애는 레이어별로 추적해야 한다

일반적인 소프트웨어 장애에는 에러 로그와 스택 트레이스가 남는다. LLM 품질 저하는 정상 응답을 반환하면서도 결과가 나빠질 수 있어 정량화와 원인 격리가 더 어렵다.

원인을 추적할 때는 모델, 인프라, 구성 레이어를 나누어 보는 방식이 유용하다. 모델 레이어에는 가중치 변경이나 파인튜닝 효과 저하가 포함된다. 캐싱 버그와 컴퓨팅 리소스 제약은 인프라 레이어에 속한다. 시스템 프롬프트와 파라미터 조정은 구성 레이어의 변경이다. Anthropic 사건에서는 이 세 분류가 동시에 영향을 미쳤다.

성능 저하 감지원인 분류모델 레이어(가중치·파인튜닝)인프라 레이어(캐싱·컴퓨팅)구성 레이어(프롬프트·파라미터)영향 범위 측정영향 사용자 태스크 유형품질 저하 정도(A/B 비교 측정)시작 시점 지속 기간롤백 전략 수립

영향 범위에는 영향을 받은 사용자와 태스크 유형, A/B 비교로 측정한 품질 저하 정도, 시작 시점과 지속 기간이 포함돼야 한다. 서로 다른 레이어의 변경이 겹쳤다면 각 변경의 배포 시점과 롤백 시점을 나란히 놓아야 상호작용을 분리할 수 있다.

롤백 방식도 레이어마다 다르다. 구성 변경은 즉시 되돌릴 수 있지만, 인프라 버그는 수정 후 다시 배포해야 한다. 모델 레이어의 문제는 이전 체크포인트로 롤백해야 하며 비용과 시간이 가장 많이 든다.

재발 방지를 위해서는 내부 파라미터 변경도 A/B 테스트를 거쳐 단계적으로 적용해야 한다. 재시도율, 태스크 성공률, 사용자 피드백 지표를 실시간으로 관찰하고 품질 저하를 자동으로 감지할 수 있어야 한다. 사용자 체감에 영향을 줄 수 있는 내부 변경은 변경 이력 공개와 사전 공지의 대상이 된다.

롤백 이후에는 신뢰를 복구해야 한다

Anthropic은 추론 effort 변경과 장황함 억제 프롬프트를 롤백했고, 캐싱 버그를 v2.1.116에서 수정했다. 이어 전체 Claude Code 구독자의 사용 한도를 초기화했다.

사용 한도 초기화는 버그와 잘못된 변경으로 사용자가 소비한 토큰을 보상하려는 신뢰 회복 조치였다. The Register는 Anthropic이 “업그레이드”로 Claude를 둔하게 만들었다가 이를 인정했다고 보도했다. 개발자 커뮤니티에서는 문제를 공개적으로 인정하고 원인을 설명한 포스트모텀이 오히려 신뢰를 강화했다는 평가도 나왔다.

이 사건에서 각 변경의 의도는 나름의 운영상 이유가 있었다. UI 레이턴시를 낮추고, 캐시를 정리하며, 불필요한 설명을 줄이려는 시도였다. 그러나 사용자에게 드러나지 않는 추론 effort와 캐싱 정책, 시스템 프롬프트가 겹치면서 약 6주간 체감 품질을 떨어뜨렸다. 내부 설정도 사용자 노출 품질을 기준으로 A/B 테스트하고, 단계적으로 롤아웃하며, 자동 롤백 조건을 마련해야 하는 이유다.

Sources

Claude CodeLLM 운영추론 캐싱시스템 프롬프트포스트모텀