Claude thinking 블록의 Invalid signature 오류 진단하기

Claude가 thinking 블록의 서명이 유효하지 않다고 하면 서버에 다시 보낸 구조화된 대화를 확인하세요. 화면에 표시된 텍스트로 재구성하지 말고 원래 thinking 블록과 서명을 보존해야 합니다. 오류가 다른 대화를 명시한다면 앞선 시스템 프롬프트, 도구와 메시지의 변경도 검사하세요.

두 원인은 다릅니다. 서명 문자열이 그대로 있어도 대화에 묶인 블록은 수정된 앞부분에서 유효하지 않을 수 있습니다. 이 글은 2026년 9월 14일 확인한 thinking 문제 해결 문서를 따릅니다. 모든 모델에 같은 바인딩 규칙이 적용된다는 주장은 아닙니다.

이력을 바꾸기 전에 오류 읽기

전체 오류 유형과 메시지, request ID, 모델 식별자와 클라이언트 버전을 보관하세요. 첫 요청부터 실패했는지, 도구 호출·세션 복원·이력 수정 뒤에 시작됐는지 구분합니다. 그 경계가 상태를 잃거나 바꾼 코드 경로를 찾는 단서입니다.

공개 issue에 비공개 대화나 불투명 서명을 붙이지 마세요. 블록 유형과 변환 과정을 민감정보 없이 설명하는 것으로 시작하는 편이 좋습니다. 자신의 요청 경로를 비교하려면 필요에 따라 변경하지 않은 로컬 진단 복사본을 보관하세요.

assistant content 전체 보존하기

네이티브 thinking 블록에는 thinking 값과 불투명한 signature가 있습니다. redacted_thinking은 data를 사용하며 일반 문장으로 취급하면 안 됩니다. 눈에 보이는 thinking 텍스트가 비어 있다는 사실만으로 손상을 판단할 수도 없습니다.

공식 thinking 도구 워크플로 안내는 후속 도구 턴에서 블록을 쓰는 방법을 설명합니다. 다른 assistant 응답과 함께 원래 값과 순서를 유지하세요. thinking 블록을 요약하거나 서명을 교체하거나 UI의 텍스트 이력으로 메시지를 다시 만들면 안 됩니다.

아래 Python은 이미 응답을 받은 뒤 전체 내용을 보존하는 조각입니다. 완성된 요청이나 실제 API 테스트가 아닙니다. 설치된 SDK에 맞게 직렬화하되 텍스트 필드만 뽑지 말고 반환 content 전체를 유지하세요.

assistant_content = [block.model_dump(exclude_none=True) for block in response.content]
messages.append({"role": "assistant", "content": assistant_content})
# Append the real tool_result message next, following the native tool protocol.

샘플 요청에 가짜 서명을 넣지 마세요. 그럴듯한 문자열은 제공업체가 발급한 유효 블록의 증거가 아닙니다. 원래 내용이 사라졌다면 상태를 만들어 내기보다 사라진 원인을 진단하세요.

스트리밍에는 텍스트 delta 외 데이터도 필요합니다

스트리밍 통합은 지원되는 content-block 이벤트를 조립해야 합니다. Messages API 문서는 해당 content_block_stop 전에 도착하는 signature_delta를 설명합니다. text_delta나 보이는 추론 텍스트만 모으면 SDK의 완전한 구조화 응답과 같은 내용을 보존하지 못합니다.

연결 종료, 취소, UI 다시 그리기 때문에 부분 블록을 완료로 표시했는지 확인하세요. 디버깅 때 블록 인덱스와 이벤트 순서를 남깁니다. 화면에 읽을 수 있는 답변이 있어도 미완성 블록을 전송하면 안 됩니다.

공식 SDK의 지원 스트림 처리는 직접 조립할 코드를 줄이지만 이후 앱이 이력을 평탄화하거나 필터링하는 것까지 막지는 않습니다. 메모리의 응답 객체와 다음 직렬화 요청을 비교하세요. 둘 사이의 변환이 가장 유용한 조사 지점일 수 있습니다.

대화 바인딩은 별도 검사입니다

현재 문서는 Claude Fable 5.1의 대화 바인딩 서명을 설명하며 2026년 8월 31일을 포함해 그 이후 생성된 계정과 문서에 정한 바인딩 제어를 설정한 요청에 적용됩니다. 특정 모델의 규칙입니다. 오류가 다른 대화를 지목한다면 블록을 바꾸지 않았더라도 앞선 시스템 지침, 도구, 이전 메시지의 변경이 영향을 줄 수 있습니다.

그 워크플로에서는 기존 내용에 새 메시지만 추가하거나 문서에 나온 서버 측 압축 및 문맥 편집 기능을 사용하세요. 로컬에서 과거 이력을 일괄 수정하고 서명을 보존했으니 유효하다고 가정하면 안 됩니다. 공식 문서의 모델별 복구 제어도 모든 Claude 요청에 붙이는 공통 설정이 아닙니다.

이 글은 특별한 복구 beta 활성화를 첫 단계로 권하지 않습니다. 먼저 선택한 모델과 정확한 오류가 적용 범위에 맞는지 확인하세요. 블록을 버리는 복구는 유지 상태를 바꿀 수 있어 앱에서 의도적으로 선택해야 합니다.

모델을 바꾸면 항상 실패하는 것은 아닙니다

현재 문제 해결 문서는 다른 모델이 읽지 못하는 블록을 버릴 수 있으며 반드시 대화 바인딩 오류를 내는 것은 아니라고 설명합니다. 따라서 모델 변경은 항상 thinking 서명을 깨뜨린다는 주장은 너무 넓습니다. 제공업체 간 모든 경로가 본질적으로 호환되지 않는다는 주장도 마찬가지입니다.

원본 모델, 대상 경로, 정확한 오류를 기록하고 해당 호환 문서를 확인하세요. 클라이언트가 Claude 네이티브 메시지를 다른 API로 바꾼다면 공통 필드 매핑을 추측하지 말고 필수 메타데이터 보존을 검증해야 합니다.

도구 결과 짝 맞춤도 독립 검증입니다. 오류가 짝 없는 ID를 지목하면 서명 대신 missing tool_result 안내를 따르세요. Gemini의 thought-signature 필드도 Claude의 네이티브 signature와 바꿔 쓸 수 없습니다.

자주 묻는 질문

서명 값을 수정하면 고칠 수 있나요?

아닙니다. 제공업체가 발급한 불투명 상태로 취급하세요. 가능하면 원래 전체 블록을 복원하고 바꾸거나 버린 변환 과정을 조사해야 합니다.

첫 요청은 되는데 두 번째 요청은 왜 실패하나요?

후속 요청에서 구조화된 thinking 데이터를 잃었거나 바인딩된 대화 앞부분이 바뀌었을 수 있습니다. 화면 텍스트가 아닌 전체 첫 응답과 실제 후속 요청을 비교하세요.

새 세션이 성공하면 버그가 고쳐진 건가요?

아닙니다. 손상된 이력을 분리했을 뿐, 어댑터가 다음 도구 라운드에서 다시 필수 필드를 없앨 수 있습니다. 보존 경로를 확인해야 합니다.