[Claude][운영] Claude Sonnet 5 fallback regeneration turn이 끝난 뒤 second-turn cache hit를 어떤 표로 따로 남기나

IT 리서치 노트

[Claude][운영] Claude Sonnet 5 fallback regeneration turn이 끝난 뒤 second-turn cache hit를 어떤 표로 따로 남기나

Claude Sonnet 5 fallback에서 regeneration turn까지는 잘 기록했는데, 그다음 second turn이 정말 새 cache point를 읽었는지는 메모가 비는 경우가 많다. 2026년 8월 30일 KST 기준 Anthropic 공식 문서를 다시 보면 Sonnet 5는 adaptive thinking이 기본이고, prompt caching은 cache point를 앞으로 옮기며, thinking 설정이나 tool_choice 변경은 cached block을 무효화할 수 있다. 이 글은 fallback regeneration turn이 끝난 뒤 second-turn cache hit를 어떤 표로 따로 남겨야 incident가 다시 짧아지는지 정리한다.

목차

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

1. 개요

결론부터 말하면 regeneration turn과 second turn은 같은 incident 안에 있어도 다른 표로 남겨야 한다. 첫 turn은 cache_creation_input_tokens 중심이고, 그다음 turn은 cache_read_input_tokens 중심이다. 이 둘을 합쳐 쓰면 캐시를 다시 만들었는지, 만들었는데도 다음 turn이 왜 miss였는지 설명이 끊긴다. 운영자는 usage 로그를 조회하고, second turn 응답을 확인하고, diff 파일을 저장해야 한다.

특히 Sonnet 5 fallback에서는 adaptive thinking과 tool_choice가 second turn에도 그대로 유지됐는지 확인해야 한다. regeneration turn 기록만 보고 incident를 닫으면, 다음 호출에서 같은 miss가 반복돼도 무엇이 바뀌었는지 비교할 기준이 남지 않는다. 같은 incident 파일 안에 설정 로그와 read-hit 확인 결과를 같이 저장하는 편이 안전하다.

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

현장에서 제일 흔한 실수는 regeneration turn에서 cache_creation_input_tokens가 커진 것만 적고 끝내는 것이다. 하지만 그다음 second turn이 read hit를 냈는지, 아니면 다시 miss였는지까지 봐야 진짜로 복구됐다고 할 수 있다.

Anthropic 문서는 Sonnet 5에 adaptive thinking이 기본이라고 설명하고, prompt caching 문서는 cache point가 대화가 커질수록 앞으로 이동한다고 적는다. 또 extended thinking 문서는 configuration changes invalidate caching이라고 말하고, tool use 문서는 tool_choice 변경이 cached blocks를 무효화할 수 있다고 설명한다. 즉 second turn miss는 단순 지연이 아니라 설정 변경의 결과일 수 있다.

문제는 많은 팀이 first miss와 second miss를 같은 재생성 현상처럼 기록한다는 점이다. 그러면 다음 회고에서 왜 first regeneration은 정상이었는데 second turn은 다시 miss였는지, tool result tail이 바뀐 것인지, adaptive thinking이나 max_tokens가 달라진 것인지, tool_choice가 흔들린 것인지를 알 수 없다. usage 로그를 조회하지 않거나, second turn 응답을 저장하지 않거나, 비교 설정 파일을 남기지 않으면 같은 오류를 다시 설명하게 된다.

• 증상: regeneration turn 이후에도 second turn이 다시 miss처럼 보인다.
• 실패: creation turn과 read-hit turn을 같은 usage 메모로 합친다.
• 막힘: adaptive thinking, tool_choice, tail diff를 따로 기록하지 않는다.
• 누락: second turn의 cache_read_input_tokens 확인이 빠진다.

겉으로 보이는 현상	실제로 다시 볼 값	판단 기준
regeneration 뒤에도 비용이 안 줄어든다	second turn cache_read_input_tokens	read hit가 실제로 났는지 본다
다음 turn만 다시 miss가 난다	thinking 설정, tool_choice	regen turn과 동일했는지 비교한다
cache_miss_reason이 자꾸 바뀐다	tool result tail 메모	messages_changed와 tools_mismatch를 가른다

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

실무 순서는 다섯 단계가 가장 짧다. 먼저 regeneration turn과 second turn을 동일 incident id 아래 두 줄로 기록한다. 다음으로 regen은 creation tokens 중심, second turn은 read tokens 중심으로 필드를 분리한다. 세 번째로 adaptive thinking, max_tokens, tool_choice, tail bucket을 두 turn 모두 같은 형식으로 적는다. 네 번째로 second turn이 miss면 messages_changed인지 tools_mismatch인지부터 가른다. 마지막으로 second turn이 hit면 그 시점에만 incident를 닫는다. 이때 로그 조회, 응답 확인, 설정 저장, diff 파일 보관 순서를 같이 적어야 운영 메모가 실제 점검 문서가 된다.

1. regeneration turn과 second turn을 다른 행으로 남긴다.
2. creation tokens와 read tokens 초점을 분리한다.
3. thinking, max_tokens, tool_choice를 두 행 모두 적는다.
4. second turn miss는 원인 종류를 다시 가른다.
5. read hit 확인 뒤에만 incident를 닫는다.

운영 체크도 함께 남긴다. 콘솔에서 usage 로그를 조회하고, 두 turn의 응답 JSON 파일을 저장하고, thinking 설정과 tool_choice 설정을 비교 확인하고, 필요하면 재실행 명령을 별도 줄에 적는다. 이렇게 해야 다음 담당자가 터미널 로그만 보고도 같은 판단을 재현할 수 있다.

second-turn 확인 메모

regen_turn.cache_creation_input_tokens=18240
second_turn.cache_read_input_tokens=17680
adaptive_thinking_same=true
tool_choice_same=true
tail_bucket_same=true
incident_close_after=read_hit_confirmed

이 구조를 잡아 두면 같은 Sonnet fallback branch에서도 post 430의 큰 체크리스트, post 433의 regeneration incident, 이번 second-turn hit 검증이 서로 역할이 겹치지 않는다. 독자 입장에서도 'fallback을 했다', '캐시가 다시 만들어졌다', '그 다음 turn이 실제로 읽었다'를 각기 다른 질문으로 이해할 수 있다.

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

첫 자료는 Sonnet 5 변경점 문서다. Sonnet 5는 adaptive thinking이 기본 동작이기 때문에 fallback regeneration turn이 끝난 뒤 second turn에서도 thinking 상태를 다시 비교해야 한다.

Sonnet 5는 adaptive thinking이 기본이라 second-turn cache hit 메모에도 thinking 상태가 들어가야 한다.

즉 첫 regeneration turn에서 캐시가 다시 만들어졌다고 끝이 아니다. 두 번째 turn이 같은 thinking 경계로 들어왔는지까지 적어야 read hit를 기대할 수 있다.

두 번째 자료는 prompt caching 문서다. Anthropic은 대화가 커질수록 마지막 cacheable block을 자동으로 캐시하고 cache point를 앞으로 옮긴다고 설명한다.

regeneration turn 뒤에는 다음 turn이 새 cache point를 실제로 읽었는지 따로 남겨야 한다.

여기서 핵심은 first miss와 second hit를 같은 사건으로 적지 않는 것이다. regeneration turn은 cache_creation_input_tokens 중심이고, 그다음 turn은 cache_read_input_tokens 중심으로 봐야 한다.

세 번째 자료는 extended thinking 문서다. thinking configuration이 바뀌면 caching이 무효화될 수 있다는 점을 직접 적고 있다.

second turn이 miss라면 thinking 설정이 regeneration turn과 달라지지 않았는지 먼저 봐야 한다.

따라서 second-turn cache hit 표에는 단순 토큰 수뿐 아니라 thinking mode, budget, max_tokens 같은 설정 차이도 들어가야 한다.

네 번째 자료는 tool use 문서다. prompt caching을 쓸 때 tool_choice 변경이 cached message block을 무효화할 수 있다고 설명한다.

fallback 후 second turn이 miss라면 tool_choice와 tool result diff도 같은 표에 들어가야 한다.

즉 second turn의 핵심 질문은 '캐시가 다시 만들어졌는가'가 아니라 '왜 읽히지 않았는가'다. tool_choice나 tool result tail이 바뀌면 regeneration 다음 turn도 다시 miss가 될 수 있다.

실무에서는 regeneration turn과 second turn을 아예 두 줄로 나누는 편이 빠르다. 아래 표는 incident 메모에서 최소한 남겨 둘 항목을 정리한 것이다.

regeneration turn과 second turn은 creation 중심 메모와 read-hit 중심 메모로 나눠야 한다.

이미 Sonnet 5 fallback 체크리스트 글과 fallback regeneration incident 글을 읽었다면, 이번 표는 그다음 second-turn 검증 레이어다.

마지막 자료는 second-turn cache hit 메모 예시다. regeneration turn과 second turn을 같은 trace 안에 두되, 초점 필드를 다르게 남기는 형태다.

second-turn 메모는 read hit와 설정 diff를 한 줄에 보여줘야 한다.

이 레코드가 있으면 cache_miss_reason이 tools_mismatch였는지, thinking 설정 차이였는지, 단순히 second turn이 아직 다른 tail을 가졌는지 훨씬 빨리 좁혀진다.

5. 주의사항과 리스크

첫 번째 리스크는 regeneration turn만 성공하면 incident를 끝냈다고 보는 것이다. 두 번째는 second turn miss를 또 다른 regeneration처럼만 기록해 설정 diff를 놓치는 것이다. 세 번째는 tool_choice와 tail diff를 남기지 않아 tools_mismatch 원인을 설명하지 못하는 것이다.

운영 전에 최소한 cache_creation_input_tokens, cache_read_input_tokens, adaptive_thinking_same, tool_choice_same, tail_bucket_same 다섯 항목은 남겨 두는 편이 좋다.

• regeneration turn과 second turn을 같은 숫자로 묶지 않는다.
• second turn hit는 read tokens로 확인한다.
• thinking과 tool_choice diff를 항상 같이 본다.

6. 결론

Claude Sonnet 5 fallback에서 regeneration turn 뒤 second-turn cache hit를 따로 남기면 incident가 훨씬 짧아진다. 첫 turn은 cache creation, 다음 turn은 cache read라는 역할 분리를 문서로 고정하고, adaptive thinking과 tool_choice diff를 함께 보면 같은 miss를 반복 설명하지 않게 된다.

같은 Claude branch에서는 fallback 체크리스트 글, regeneration incident 글, tail split logging 글과 이어 읽으면 cache miss에서 cache reuse까지 흐름이 닫힌다. 후속으로 tools_mismatch일 때 tool result diff 저장 순서를 정리한 글을 보면 second-turn hit 뒤 다시 miss가 날 때 어떤 evidence를 먼저 모을지까지 연결된다.

7. 참고 링크

1. https://platform.claude.com/docs/en/models/sonnet-5/whats-new-sonnet-5
2. https://platform.claude.com/docs/en/build-with-claude/prompt-caching
3. https://platform.claude.com/docs/en/build-with-claude/extended-thinking
4. https://platform.claude.com/docs/en/agents-and-tools/tool-use/define-tools
5. https://platform.claude.com/docs/en/release-notes/overview