Claude Messages API에 대화를 서버 메모리에 두는 메시지 스레드가 생겼다. 이 기능은 ZDR 대상이 아닌데, API는 ZDR 조직의 요청도 막지 않는다. SDK 베타 tool runner처럼 기본으로 켜는 경로부터 찾아 끈다.
ZDR(zero data retention) 계약을 맺은 조직의 데이터 처리 검토는 대개 계약서에서 끝난다. Anthropic과 ZDR을 맺었으니 프롬프트와 응답은 남지 않는다고 적고 넘어간다. 이 결론은 요청마다 어떤 기능이 붙어 나가는지 묻지 않는다.
Anthropic 11월 2일 발표는 Messages API에 메시지 스레드를 공개 베타로 붙였다. 대화 전체를 한 번만 보내고 이후 턴에는 새 메시지만 보낸다. 50만~100만 토큰 요청에서 첫 토큰까지 걸리는 시간(TTFT) 중앙값이 약 35% 줄었고, 이 수치는 스레드가 대부분 기본으로 켜진 Claude Code 사용자에게서 나왔다. 요금과 rate limit은 그대로다.
속도와 맞바꾼 것은 대화가 Anthropic 서버에 머무는 시간이다. ZDR 조직은 이 기능을 성능 옵션이 아니라 데이터 처리 조건으로 검토해야 한다.
스레드는 대화를 최대 1시간 서버 메모리에 두고, ZDR은 그 시간을 덮지 않는다
Message threads 문서에 적힌 동작은 단순하다. 첫 요청에 "thread": {"type": "create"}를 붙이면 API가 대화·system·tools를 응답 id 아래 저장한다. 다음 요청은 새 메시지와 previous_message_id만 보낸다. 스레드는 마지막 요청 뒤 5분이 지나면 이어 쓸 수 없고, API는 마지막 사용 뒤 최대 1시간 안에 지운다. 서버 관리 키로 암호화해 메모리에만 두고 디스크에는 쓰지 않는다.
같은 문서의 데이터 처리 항목은 스레드를 ZDR·HIPAA 모두 '대상 아님'으로 분류한다. 스레드를 조회하거나 삭제하는 API도 없다. 응답에는 이번 턴이 저장됐는지 표시가 없어서, 어느 요청이 서버에 대화를 남겼는지는 요청 본문의 thread 필드와 anthropic-beta: message-threads-2026-08-12 헤더로만 가린다.
HIPAA 조직은 400으로 막히고 ZDR 조직은 그대로 통과한다
스레드 요청의 결과는 조직 설정에 따라 갈린다.
| 조직 설정 | 스레드 요청 결과 |
|---|---|
| HIPAA readiness 켬 | 400 thread_unsupported_request (hipaa) |
| Inference hooks 켬 | 400 thread_unsupported_request (inference_hooks) |
| ZDR 계약 | 정상 처리, 해당 데이터는 ZDR 밖 |
API·데이터 보존 문서는 ZDR 아래에서 API가 '대상 아님' 기능을 막지 않는다고 적었다. 그 기능을 쓰면 해당 데이터에 한해 ZDR 밖으로 나가고, 기능별 보존 정책이 적용된다.
ZDR 조직에서 스레드를 끄는 일은 API가 아니라 호출하는 코드가 맡는다.
걸리는 지점은 기본값이다. 문서는 Anthropic SDK의 베타 tool runner가 스레드를 기본으로 쓰고, 만들 때 끌 수 있다고 적는다. Python은 tool_runner(..., thread=False), TypeScript는 toolRunner({ ..., thread: false })다. 개발자가 thread를 한 번도 적지 않아도 tool runner로 짠 에이전트는 스레드 요청을 보낸다. Claude Code ZDR 문서는 Enterprise ZDR 조직에서 클라우드 세션·Remote Control·/feedback을 백엔드에서 끈다고 나열하지만, 그 표에 스레드는 없다.
같은 날 반대 방향의 기본값 변경도 나왔다. GitHub 11월 2일 공지는 public 저장소의 pull_request_target을 12월 2일부터 기본 차단하면서, 평가 모드와 11월 9일·16일 두 차례 brownout으로 막힐 실행을 미리 보여준다. 스레드 문서가 ZDR 조직에 적어 둔 내용은 '막지 않는다'까지다. 서버 쪽 대화 상태가 ZDR과 부딪히는 구조는 OpenAI Agents API는 샌드박스를 자체 호스팅해도 ZDR을 열어주지 않는다, 대화 기록은 하네스가 있는 곳에 남기 때문이다에서도 다뤘다.
가져갈 것
- ZDR 조직 API 키로 나간 요청 가운데
anthropic-beta: message-threads-2026-08-12헤더가 붙은 건수를 사내 게이트웨이나 프록시 로그에서 셌는가? - 베타 tool runner를 쓰는 서비스마다
thread=False(TypeScript는thread: false)를 명시했는가? - 저장소에서
messages.thread(와"type": "create"를 검색해 스레드 헬퍼나thread필드를 직접 쓰는 코드를 찾았는가? - ZDR 조직의 Claude Code가 스레드를 쓰는지 Anthropic 계정 팀에 서면으로 물었는가?
- 데이터 처리 검토서의 ZDR 항목에 "ZDR '대상 아님' 기능은 API가 막지 않는다"는 조건을 적었는가?
안 되는 경우
- Amazon Bedrock이나 Google 관리형 Google Cloud로 Claude를 쓰는 조직은 데이터 처리자가 클라우드 사업자이고, 스레드 지원 플랫폼 목록에도 두 곳은 없다.
- ZDR 계약이 없는 조직은 이미 표준 보존 정책을 따르므로 이 논지의 대상이 아니다.
- Claude Code가 ZDR 조직에서도 스레드를 기본으로 켜는지는 소스가 밝히지 않았다. 발표문은 '대부분' 사용자에게 켜져 있다고만 적었다.
- 발표문은 35% 수치의 측정 기간·모델·비교 기준을 밝히지 않았다. 1시간은 삭제 시점의 상한이고 실제 보존 시간 분포는 공개되지 않았다.
이번 주에는 SDK 초기화 코드에 thread=False 한 줄을 넣는 것부터 한다. 스레드를 다시 켤지는 TTFT 35% 단축과 최대 1시간 메모리 보존을 나란히 놓고 보안팀이 정한다. 계약서 대신 요청 헤더로 데이터 처리 조건을 확인하는 절차가 조직에 있는지도 같이 점검한다. 사업영역 →