[Claude][운영] Claude Sonnet 5 fallback second turn은 read hit인데 latency가 여전히 길 때 어떤 usage와 tail diff를 같이 비교하나

IT 리서치 노트

[Claude][운영] Claude Sonnet 5 fallback second turn은 read hit인데 latency가 여전히 길 때 어떤 usage와 tail diff를 같이 비교하나

Claude Sonnet 5 fallback 운영에서 second turn에 cache read hit가 찍혔는데도 체감 latency가 길면, 단순히 캐시가 안 먹었다고 결론 내리기 쉽다. 하지만 2026년 8월 31일 KST 기준 Anthropic 공식 문서를 다시 보면 cache read hit는 usage의 한 부분일 뿐이고, prefix 밖 tail 입력, thinking 파라미터, output 길이, service tier가 실제 응답 시간에 같이 영향을 준다. 이 글은 read hit가 있었는데도 second turn이 느릴 때 어떤 usage와 tail diff를 같이 비교해야 하는지 정리한다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 second turn에서 cache_read_input_tokens가 잡혔더라도 latency 원인은 아직 절반만 본 것이다. read hit는 prefix가 재사용됐다는 뜻일 뿐이고, 실제 대기 시간은 새로 붙은 tail 입력, tool result diff, output 길이, service tier를 같이 봐야 갈린다.

그래서 운영 로그는 cache hit 여부만 저장하면 부족하다. second turn latency incident는 usage와 tail diff를 같은 trace id에 묶어야 다음날 다시 봐도 왜 느렸는지 설명할 수 있다.

2. 어디서 실제로 막히는가

현장에서 가장 흔한 오해는 cache_read_input_tokens > 0이면 second turn이 반드시 빨라야 한다는 기대다. 하지만 prefix는 재사용돼도 tool 결과가 크게 바뀌거나, tail 사용자 입력이 길어지거나, 출력 토큰이 커지면 전체 응답 시간은 여전히 길 수 있다.

Prompt caching 문서는 cache read와 cache creation usage 필드를 보여 주고, cache diagnostics 문서는 earlier message 변경이나 tool reorder가 캐시 동작에 영향을 줄 수 있다고 설명한다. extended thinking 문서는 같은 thinking 파라미터일 때 second request hit 예시를 보여 준다. 이 셋을 합치면 second turn latency는 hit 여부, 파라미터 동일성, tail diff를 함께 봐야 한다.

문제는 실제 incident note가 'cache hit confirmed' 한 줄로 끝나는 경우다. 그러면 왜 여전히 느렸는지, prefix 밖에 얼마나 큰 tool result가 붙었는지, 출력이 얼마나 길었는지, standard tier 대기였는지를 나중에 설명하기 어렵다.

• 증상: cache read hit가 있는데 second turn latency가 그대로 길다.
• 실패: cache hit 여부만 저장하고 tail 입력 크기를 안 남긴다.
• 막힘: thinking 파라미터 diff를 먼저 배제하지 않는다.
• 누락: output_tokens와 service_tier를 같은 로그에 안 둔다.

증상	먼저 볼 곳	판단 기준
hit는 있는데 느리다	tail 입력 크기, tool result diff	cache 밖 새 입력이 큰지 본다
같은 재현인데 hit 결과가 다르다	thinking 파라미터, earlier message 변경	prefix가 바뀌지 않았는지 본다
느린 이유 설명이 약하다	output_tokens, service_tier	출력 길이와 대기 계층을 같이 본다

3. 실무에서 적용하는 순서

가장 실용적인 운영 순서는 다섯 단계다. 먼저 cache_read_input_tokens로 read hit를 확인한다. 다음으로 thinking 파라미터와 tool 목록 순서가 바뀌지 않았는지 본다. 세 번째로 prefix 밖 tail 입력 크기와 tool result diff를 저장한다. 네 번째로 output_tokens와 service_tier를 같은 trace에 붙인다. 마지막으로 latency가 긴 케이스만 따로 모아 second turn 비교표를 만든다.

1. cache_read_input_tokens로 hit 여부를 확인한다.
2. thinking 파라미터와 tool ordering diff를 먼저 배제한다.
3. tail 입력 크기와 tool result diff 요약을 저장한다.
4. output_tokens와 service_tier를 같은 trace에 붙인다.
5. latency 상위 케이스만 별도 표로 비교한다.

이렇게 보면 '캐시가 먹었는데 왜 느리지'라는 질문이 훨씬 빨리 정리된다. 어떤 케이스는 read hit는 맞지만 tail tool result가 커서 느리고, 어떤 케이스는 tail은 작지만 output이 길고, 어떤 케이스는 standard tier 대기 시간이 길 수 있다. 각각 보는 포인트가 다르기 때문에 usage 한 칸만으로는 부족하다.

turn=2
cache_read_input_tokens=1840
tail_input_bytes=9210
output_tokens=1180
service_tier=standard
latency_ms=8920

4. 공식 문서와 예시 화면으로 확인하기

첫 자료는 prompt caching 문서의 usage 예시다. cache_read_input_tokens가 늘면 cache hit가 있었다는 기본 증거를 얻는다.

cache_read_input_tokens는 second turn read hit 여부를 확인하는 가장 직접적인 usage 신호다.

하지만 read hit가 있었다고 해서 전체 응답이 반드시 짧아지는 것은 아니다. second turn latency는 tail prompt와 tool 결과, 출력 길이까지 같이 봐야 한다.

두 번째 자료는 cache diagnostics 문서다. 캐시는 byte-for-byte identical prefix일 때만 강하게 이점을 주고, earlier message 변경이나 tool reorder가 조용히 cache 동작을 바꿀 수 있다고 설명한다.

cache hit 여부와 별개로 prefix나 tool 순서가 흔들리면 tail 비용과 latency는 여전히 커질 수 있다.

즉 read hit 하나만 보고 incident를 닫으면 위험하다. cache hit 이후에도 tail diff가 커지면 second turn이 느릴 수 있다는 전제를 가져가야 한다.

세 번째 자료는 extended thinking 문서의 second request 예시다. 같은 thinking 파라미터면 second request에서 cache hit를 기대할 수 있다고 문서가 직접 보여 준다.

same thinking parameters와 second request cache hit 예시는 second turn 분석에서 파라미터 diff를 먼저 빼야 한다는 근거가 된다.

따라서 second turn latency를 볼 때는 effort나 thinking 파라미터 변경이 없었다는 사실을 먼저 고정하고, 그다음 tail과 output 길이를 봐야 한다.

실무에서는 usage와 tail diff를 따로 캡처해 두기 쉽다. 아래 표는 second turn read hit가 있었는데도 latency가 남을 때 어떤 값을 한 표에서 같이 봐야 하는지 정리한 것이다.

second turn latency는 cache read hit, tail size, output size, tool result diff를 같은 표로 봐야 원인이 빨리 갈린다.

이미 second-turn cache hit 글이 hit 자체를 다뤘다면, 이번 글은 hit 이후에도 느린 경우 무엇을 더 비교해야 하는지에 초점을 둔다.

마지막 자료는 second-turn latency 로그 예시다. 핵심은 cache hit 여부만이 아니라 tail size, output_tokens, tool diff 요약을 한 trace에 같이 붙이는 것이다.

second turn latency 로그는 usage와 tail diff를 같은 trace id로 묶어야 한다.

이 구조가 있어야 post 430의 fallback checklist, post 433의 regeneration memo, post 443의 tools_mismatch diff-save ordering이 하나의 실무 runbook으로 이어진다.

5. 주의사항과 리스크

첫 번째 리스크는 read hit를 곧 latency 성공으로 오해하는 것이다. 두 번째 리스크는 tool result diff를 저장하지 않아 prefix 밖 새 계산량을 설명하지 못하는 것이다. 세 번째 리스크는 service_tier를 무시해 모델 작업량과 대기열 요인을 섞어 버리는 것이다.

운영 전에 확인할 때는 최소한 cache read hit, tail bytes, output_tokens, service_tier, tool diff 요약 다섯 칸을 같은 incident note에 두는 편이 좋다. 그래야 next turn cost spike나 output budget follow-up으로도 자연스럽게 이어진다.

• cache hit는 latency 원인의 일부일 뿐 전체가 아니다.
• tail diff와 output 길이를 함께 남겨야 한다.
• service_tier를 빼면 대기 시간 해석이 섞인다.

6. 결론

Claude Sonnet 5 fallback second turn에서 read hit가 있었는데도 latency가 길다면, 문제는 대개 캐시가 아니라 cache 밖 tail과 출력 길이 쪽에 있다. cache_read_input_tokens, thinking 파라미터, tail diff, output_tokens, service_tier를 같은 trace에 묶으면 second turn incident를 훨씬 짧게 닫을 수 있다.

같은 지연을 더 넓게 분기하고 싶다면 새 후속 글인 Claude Sonnet 5 fallback second turn에서 cache read hit와 effort·max_tokens 문제를 나누는 비교 글을 이어서 보면 좋다. 이번 글이 usage와 tail diff에 집중했다면, 후속 글은 왜 같은 read hit인데도 조치가 달라지는지 상위 triage 표로 정리한다.

• read hit 확인 뒤 tail diff를 바로 본다.
• thinking 파라미터 변경 여부를 먼저 배제한다.
• usage와 latency 메모를 같은 trace에 저장한다.

7. 참고 링크

1. https://platform.claude.com/docs/en/build-with-claude/prompt-caching
2. https://platform.claude.com/docs/en/build-with-claude/cache-diagnostics
3. https://platform.claude.com/docs/en/build-with-claude/extended-thinking
4. https://platform.claude.com/docs/en/build-with-claude/working-with-messages
5. https://platform.claude.com/docs/en/api/service-tiers