ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [Claude][운영] Claude Opus 5에서 rollback 뒤 messages_changed와 tools_mismatch를 어떤 incident split으로 먼저 고정하나
    기타개발지식/풀스택개발 2026. 8. 28. 09:16

    IT 리서치 노트

    [Claude][운영] Claude Opus 5에서 rollback 뒤 messages_changed와 tools_mismatch를 어떤 incident split으로 먼저 고정하나

    Claude Opus 5에서 mid-conversation tool changes를 걷어낸 뒤 cache hit가 더 크게 흔들리면 많은 팀이 그냥 rollback 실패라고만 적는다. 하지만 2026년 8월 28일 KST 기준 Anthropic 문서를 다시 보면 tool changes는 beta header를 요구하고, prompt caching은 append-only history를 전제로 하며, cache diagnostics는 history 편집과 tool mismatch를 서로 다른 원인으로 다룬다. 이 글은 rollback 뒤 incident를 `messages_changed`와 `tools_mismatch`로 먼저 고정해야 왜 miss가 났는지 더 짧게 복기할 수 있다는 점을 정리한다.

    1. 개요

    결론부터 말하면 Claude Opus 5 rollback 뒤 incident split은 messages_changed와 tools_mismatch를 먼저 분리하는 쪽이 맞다. history 편집이 있었는지와 tools delta가 남았는지는 같은 miss처럼 보여도 고치는 순서와 재현 방법이 다르다.

    이미 cache miss 로그 필드 표준화 글이 전체 incident 필드를 정리했다면, 이번 글은 그중 가장 먼저 분리해야 할 두 필드를 좁힌 후속편이다. 앞단으로는 rollback 순서 글과 rollback 진단 템플릿 글이 연결된다.

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

    실무에서 가장 자주 생기는 실패는 rollback 뒤 cache hit 하락을 그냥 기능 철회 부작용으로 적는 것이다. 그런데 같은 miss처럼 보여도 실제 원인은 두 갈래다. 첫 갈래는 header 제거, fixed tools 전환, tool schema drift 같은 요청 계층이다. 두 번째 갈래는 top-level system 재편집, assistant turn 재직렬화, tool result 생략 같은 history 계층이다.

    Anthropic 문서는 mid-conversation tool changes가 beta header를 요구한다고 분리해 적고, prompt caching 문서는 append-only system message를 권장한다. cache diagnostics 문서는 assistant content와 tool results를 그대로 resend하라고 적는다. 이 셋을 같이 읽으면 rollback은 단순 토글이 아니라 request layer와 history layer를 따로 닫는 작업이라는 점이 분명해진다.

    그런데 운영 메모를 한 줄로 쓰면 여기서 문제가 생긴다. rollback_done=true 같은 값 하나만 남기면, 실제로는 header는 제거됐지만 history가 편집돼 messages_changed가 커진 상황과, history는 보존됐지만 tools mismatch가 남은 상황을 구분할 수 없다. 둘은 재시도 순서도 다르고 책임 범위도 다르다.

    • 증상: rollback 뒤 cache hit가 기대보다 더 크게 떨어진다.
    • 실패: 기능 철회와 history 편집을 같은 incident로 적는다.
    • 막힘: header 제거 시각과 assistant resend 상태를 따로 남기지 않는다.
    • 누락: messages_changed와 tools_mismatch를 별도 필드로 저장하지 않는다.
    헷갈리는 증상 먼저 볼 필드 왜 따로 남기나
    기능을 껐는데 hit가 더 떨어진다 beta_header, tools_mode tools mismatch가 남았는지 먼저 보기 위해
    동일 요청처럼 보이는데 miss가 커진다 messages_changed, assistant_rewritten history 편집 여부를 바로 자르기 위해
    일부 surface만 다르게 동작한다 header memo, tool_schema_hash 요청 계층 drift를 trace 단위로 보기 위해

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

    가장 짧은 운영 순서는 다섯 단계다. 먼저 beta header 제거 여부와 tools 고정 전환을 적는다. 다음으로 top-level system을 다시 쓰지 않았는지 확인한다. 세 번째로 assistant content와 tool results를 그대로 resend했는지 저장한다. 네 번째로 cache diagnostics에서 messages_changed와 tools_mismatch를 별도 필드로 조회한다. 마지막으로 같은 trace id에 counters를 붙여 비용 차이까지 같이 본다.

    1. header 제거와 tools 고정 전환을 먼저 기록한다.
    2. top-level system과 history를 편집하지 않았는지 확인한다.
    3. assistant turns와 tool results resend 상태를 저장한다.
    4. messages_changed와 tools_mismatch를 다른 필드로 조회한다.
    5. 같은 trace에 cache counters를 붙여 비교한다.

    실제로는 팀 메모에 누가 어떤 surface를 확인하고, 어떤 요청 JSON을 저장하고, 어떤 header 값을 조회하고, 어떤 assistant turn을 다시 실행하고, 어떤 tool result를 그대로 복사하고, 어떤 cache 진단 값을 입력했는지 순서대로 적어 두는 편이 좋다. 그래야 다음 incident에서 도구 설정을 먼저 고치나, history resend를 먼저 고치나가 바로 갈린다.

    운영자는 같은 trace에서 cache diagnostics 응답을 다시 조회하고, header 설정 파일을 확인하고, tools 설정 변경 로그를 저장하고, replay 요청을 한 번 더 실행하는 순서를 반복해야 한다. 이 네 동작이 있어야 두 miss를 실제로 분리해 설명할 수 있다.

    incident split 메모 예시
    trace_id=claude_rollback_2026_08_28_01
    beta_header_after=none
    tools_mode_after=fixed_list
    top_level_system_edited=false
    assistant_turns_rewritten=false
    messages_changed=false
    tools_mismatch=true
    next_action=check tool schema drift before replay

    관련 글로는 cache miss 필드 표준화 글, rollback 진단 템플릿 글, append-only change 관리 글을 같이 두면 branch가 자연스럽다.

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

    첫 자료는 mid-conversation system messages 문서다. 여기서 가장 먼저 봐야 할 점은 Claude Opus 5의 tool changes가 여전히 beta header를 요구한다는 사실이다.

    Claude Opus 5의 mid-conversation tool changes는 beta 기능이며 헤더 상태를 먼저 구분해야 한다.
    Claude Opus 5의 mid-conversation tool changes는 beta 기능이며 헤더 상태를 먼저 구분해야 한다.

    rollback 뒤 incident를 읽을 때 header가 남아 있는지부터 분리하지 않으면 tools mismatch와 messages_changed를 한 원인처럼 적기 쉽다. 요청 계층과 history 계층을 같은 줄에 적으면 이후 복기가 느려진다.

    두 번째 자료는 prompt caching 문서의 append-only 흐름이다. Anthropic은 top-level system을 덮어쓰기보다 `messages`에 system 메시지를 append하는 방식을 권장한다.

    rollback 뒤에도 기존 system과 assistant history를 고쳐 쓰지 말고 append-only로 다뤄야 cache 경계를 덜 흔든다.
    rollback 뒤에도 기존 system과 assistant history를 고쳐 쓰지 말고 append-only로 다뤄야 cache 경계를 덜 흔든다.

    이 권고를 빠뜨리면 기능을 끄는 과정에서 과거 turn 편집이 함께 들어가고, 그 순간 tools mismatch가 아니라 messages_changed miss가 튀어도 같은 사건처럼 보이게 된다.

    세 번째 자료는 cache diagnostics 문서다. 이 화면에서는 history를 append-only로 유지하라는 문장과 함께 assistant content, tool results를 그대로 resend하라고 적고 있다.

    Anthropic cache diagnostics 문서는 history 편집이 messages_changed를 만드는 대표 원인이라고 안내한다.
    Anthropic cache diagnostics 문서는 history 편집이 messages_changed를 만드는 대표 원인이라고 안내한다.

    즉 rollback 뒤 incident split의 핵심은 'tool delta가 달랐는가'와 'history를 편집했는가'를 다른 필드로 남기는 일이다. 이 둘이 같은 칸에 있으면 cache hit 하락 원인이 복원되지 않는다.

    실무에서는 원인 필드를 둘로 나눈 표가 가장 빠르다. 아래 표는 rollback 뒤 miss를 `messages_changed`와 `tools_mismatch`로 먼저 자를 때 남길 최소 칸을 정리한 것이다.

    rollback 뒤 cache miss를 messages_changed와 tools_mismatch로 나눠 읽는 incident split 표다.
    rollback 뒤 cache miss를 messages_changed와 tools_mismatch로 나눠 읽는 incident split 표다.

    이미 cache miss 필드 표준화 글이 incident 전체 필드 세트를 정리했다면, 이번 표는 그 안에서 miss 원인을 두 갈래로 먼저 고정하는 후속편이다.

    마지막 자료는 바로 붙여 넣을 수 있는 incident note 예시다. 중요한 것은 한 줄 결론이 아니라 원인 후보를 같은 이름으로 반복 저장하는 일이다.

    Claude rollback incident를 기록할 때 messages_changed와 tools_mismatch를 먼저 분리하는 JSON 예시다.
    Claude rollback incident를 기록할 때 messages_changed와 tools_mismatch를 먼저 분리하는 JSON 예시다.

    이 구조면 다음 회차에 header 제거 시점, fixed tools 전환 시점, history 편집 여부를 바로 비교할 수 있다. Claude branch에서는 rollback 진단 템플릿 글과 rollback 순서 글도 같이 읽는 편이 좋다.

    5. 주의사항과 리스크

    첫 번째 리스크는 rollback을 하며 top-level system까지 같이 수정하는 것이다. 두 번째 리스크는 tool delta를 없애는 과정에서 assistant turn이나 tool result를 보기 좋게 다시 직렬화하는 것이다. 세 번째 리스크는 messages_changed와 tools_mismatch를 같은 완료 신호처럼 메모하는 것이다.

    운영 전에 최소한 beta_header_after, tools_mode_after, top_level_system_edited, assistant_turns_rewritten, messages_changed, tools_mismatch는 남기는 편이 좋다. 이 여섯 칸이 없으면 다음 회차에도 miss 원인을 반으로 자르지 못한다.

    • 요청 계층과 history 계층을 서로 다른 사건으로 본다.
    • append-only 위반은 tools rollback과 다른 리스크다.
    • diagnostics 필드가 분리돼야 재현 순서가 짧아진다.

    6. 결론

    Claude Opus 5 rollback 뒤 miss를 더 빨리 복기하려면 기능을 껐다보다 messages_changed인가 tools_mismatch인가를 먼저 적는 편이 낫다. header와 tools set은 요청 계층, history 편집은 cache 계층으로 나누면 같은 cache hit 하락도 훨씬 짧게 설명할 수 있다.

    이후 cache hit 자체는 유지되는데 billing 지표가 다시 커지는 상황까지 이어서 보려면 Claude Opus 5에서 cache_read_input_tokens는 0인데 cache_creation_input_tokens만 커질 때 tool result tail을 어떤 기준으로 다시 보나를 같이 보면 incident 메모 기준을 더 촘촘하게 맞출 수 있다.

    • messages_changed와 tools_mismatch를 처음부터 나눠 적는다.
    • append-only history 확인을 tools rollback과 분리한다.
    • trace 단위 메모로 header와 resend 상태를 같이 남긴다.

    7. 참고 링크

    1. https://platform.claude.com/docs/en/build-with-claude/mid-conversation-system-messages
    2. https://platform.claude.com/docs/en/build-with-claude/prompt-caching
    3. https://platform.claude.com/docs/en/build-with-claude/cache-diagnostics
    4. https://platform.claude.com/docs/en/about-claude/models/whats-new-opus-5
Designed by Tistory.