-
[Claude][비교] Claude Sonnet 5 fallback second turn이 느릴 때 cache read hit와 effort·max_tokens 문제를 어떤 triage 표로 나누나기타개발지식/AI 2026. 9. 1. 09:13
IT 리서치 노트
[Claude][비교] Claude Sonnet 5 fallback second turn이 느릴 때 cache read hit와 effort·max_tokens 문제를 어떤 triage 표로 나누나
Claude Sonnet 5 fallback second turn이 느릴 때 많은 팀이 cache hit 여부 하나로 원인을 설명하려고 한다. 하지만 2026년 9월 1일 KST 기준 Anthropic 공식 문서를 다시 보면 cache read와 cache write는 비용 계수가 다르고, thinking configuration과 effort level을 바꾸면 prompt caching 해석이 달라질 수 있으며, Sonnet 5는 최대 128k output tokens를 지원하더라도 실제 요청의 max_tokens 설정이 별도다. 이 글은 second turn이 느릴 때 cache read hit와 effort·max_tokens 문제를 어떤 triage 표로 나눠야 하는지 정리한다.
1. 개요
결론부터 말하면 second turn latency는
cache read hit,effort 또는 thinking 설정 변화,max_tokens 부족을 분리해서 봐야 한다. read hit가 있었다는 사실만으로 느림의 원인을 cache 자체로 단정하면 조치가 엇나간다.특히 fallback 경로에서는 직전 turn과 같은 설정을 유지했는지와, 출력 상한이 실제 결과 길이에 비해 낮지 않은지를 함께 기록해야 한다. 그래야 cache가 맞게 읽힌 상태인지, 아니면 다른 설정이 latency를 밀어 올렸는지 구분할 수 있다.
2. 어디서 실제로 막히는가
실무에서 가장 흔한 혼선은 세 가지다. 첫째, cache read hit가 보이면 latency 원인이 해결됐다고 생각한다. 둘째, effort를 바꾸고도 same-turn 비교처럼 로그를 본다. 셋째, max_tokens가 낮아 결과가 잘리거나 재호출이 생겼는데 이것을 cache 불안정으로 적는다.
Anthropic 문서는 prompt caching에서 read와 write가 다른 비용 계수를 갖는다고 설명하고, thinking steering 문서에서는 같은 effort와 thinking configuration을 유지해야 prompt caching이 보존된다고 적는다. 또 context windows 문서는 Sonnet 5의 최대 출력 한도를 별도로 설명한다. 이 셋을 합치면 second turn triage는 cache 신호 하나로 닫히지 않는다.
문제는 운영 로그가 대개
cache_read_hit=true같은 플래그 한 줄로 끝난다는 점이다. 이렇게 남기면 read hit 이후에도 왜 느렸는지, 왜 output이 잘렸는지, 왜 같은 fallback chain에서 turn마다 체감이 달랐는지를 설명하기 어렵다.- 증상: read hit인데도 second turn이 느리다.
- 실패: effort 변경과 cache 상태를 같은 원인처럼 적는다.
- 막힘: max_tokens 부족을 cache miss처럼 기록한다.
- 누락: turn별 설정 drift를 같은 trace에 안 남긴다.
겉으로 보이는 현상 먼저 볼 값 판단 기준 read hit인데 latency가 길다 effort, thinking config 직전 turn과 설정이 같은지 본다 응답이 자주 잘린다 max_tokens, 출력 길이 output budget 부족인지 본다 비용이 갑자기 뛴다 cache read/write 비율 새 write가 다시 발생했는지 본다 3. 실무에서 적용하는 순서
가장 실용적인 triage 순서는 다섯 단계다. 먼저 second turn에서 cache read hit 여부를 적는다. 다음으로 직전 turn과 effort, thinking 설정이 같은지 비교한다. 세 번째로 max_tokens와 실제 출력 길이를 대조한다. 네 번째로 cache write 비용이 새로 발생했는지 본다. 마지막으로 이 네 값을 같은 trace id에 묶어 다음 turn과 비교한다.
- cache read hit를 기록한다.
- effort와 thinking 설정 drift를 확인한다.
- max_tokens와 observed output 길이를 함께 본다.
- cache write가 다시 일어났는지 비용 신호를 확인한다.
- 같은 trace id로 second turn triage row를 보존한다.
이렇게 보면 조치가 단순해진다. read hit인데도 느리면 설정 drift부터 의심하고, 출력이 자주 잘리면 output budget을 먼저 본다. 비용이 갑자기 커졌다면 새 write가 cache를 다시 채우는지 확인하면 된다. 모두 같은
느림이지만 해결 순서는 다르다.cache_read_hit=true effort_changed=false thinking_config_changed=false max_tokens=3200 observed_output_tokens=2870 triage_bucket=slow-read-hit-not-budget-bound4. 공식 문서와 예시 화면으로 확인하기
첫 자료는 prompt caching 문서다. 여기서는 cache write와 cache read가 서로 다른 가격 계수를 가진다고 설명한다.
즉 second turn이 느리더라도 read hit가 있었다는 사실만으로 비용과 원인을 설명할 수는 없다. cache hit는 입력 재사용 여부이고, 느림의 원인은 effort나 출력 상한과 별도일 수 있다.
두 번째 자료는 thinking steering 문서다. Anthropic은 같은 thinking configuration과 effort level을 유지해야 prompt caching이 보존된다고 설명한다.
그래서 second turn triage는 단순히 cache_read_input_tokens만 보는 것이 아니라, 직전 turn과 effort 설정이 같은지부터 같이 봐야 한다. 설정이 바뀌었다면 read hit처럼 보여도 실제 체감 지연은 달라질 수 있다.
세 번째 자료는 context windows 문서다. Claude Sonnet 5는 1M context window와 최대 128k output tokens를 지원한다고 적혀 있다.
즉 느린 second turn은 cache 문제만이 아니라 output budget 설정 문제일 수 있다. 특히 fallback 경로에서 max_tokens를 과하게 낮춘 상태라면, cache hit가 있어도 출력이 잘리거나 반복 재시도가 생긴다.
실무에서는 read hit, effort, max_tokens, 결과 길이 신호가 한 줄 로그에 섞여 원인 분리가 늦어진다. 아래 표는 second turn triage를 어떤 축으로 자를지 정리한 예시다.
이미 usage와 tail diff 글을 읽었다면, 이번 표는 그 숫자를 어디로 분기할지 정하는 상위 판이다. 또 adaptive thinking과 max_tokens 체크리스트 글과도 자연스럽게 이어진다. read hit인데 incomplete가 섞일 때 stop reason과 max_tokens를 먼저 자르는 후속편은 Claude fallback second turn incomplete 글에서 이어진다.
마지막 자료는 실제로 남겨 둘 trace log 예시다. cache read hit 여부와 effort, max_tokens, completion 상태를 한 줄로 같이 보관하면 원인 분기가 빨라진다.
이 구조가 있으면 post 441의 second-turn cache hit, post 443의 tools mismatch, post 446의 usage tail diff를 하나의 triage 사다리로 연결할 수 있다.
5. 주의사항과 리스크
첫 번째 리스크는 read hit 플래그만 보고 cache 문제로 몰아가는 것이다. 두 번째 리스크는 effort를 바꿔 놓고 전후 latency를 같은 기준으로 비교하는 것이다. 세 번째 리스크는 output budget 부족을 cache instability처럼 기록해 잘못된 조정을 반복하는 것이다.
운영 전에는 최소한 cache read/write, effort, thinking configuration, max_tokens, observed output tokens 다섯 값을 한 trace에 남겨 두는 편이 좋다. 그래야 second turn latency가 cache, 설정, 출력 상한 중 어디서 시작됐는지 빨리 잘린다.
- read hit는 원인 전체가 아니라 입력 재사용 신호일 뿐이다.
- effort와 thinking 설정 drift는 별도 원인 축이다.
- max_tokens 부족은 cache 문제와 다른 조치가 필요하다.
6. 결론
Claude Sonnet 5 fallback second turn이 느릴 때는 cache read hit 여부 하나로 닫으면 안 된다. cache, effort 설정, output budget을 다른 triage row로 나눠야 로그도 짧아지고 조치도 빨라진다.
- cache read hit와 설정 drift를 분리한다.
- max_tokens 부족을 별도 버킷으로 본다.
- 같은 trace id로 turn 간 비교를 남긴다.
7. 참고 링크
'기타개발지식 > AI' 카테고리의 다른 글
