앤스로픽 메시지 스레드 — 클로드 API 에이전트가 대화를 매번 다시 보내지 않게 된다

앤스로픽이 11월 2일 공개 베타로 내놓은 메시지 스레드의 작동 방식, 35% 빨라진다는 숫자의 조건, 비용은 왜 그대로인지, 5분 만료와 데이터 보관 제약까지 개발자가 알아야 할 것을 정리했습니다.

앤스로픽이 2026년 11월 2일, 클로드 Messages API 에 메시지 스레드(message threads) 를 공개 베타로 내놓았습니다. 이제 에이전트는 대화 전체를 한 번만 보내고, 그다음부터는 새 메시지와 직전 응답의 ID 만 보내면 됩니다. 앤스로픽은 50만~100만 토큰짜리 요청에서 첫 토큰까지 걸리는 시간의 중앙값이 약 35% 줄었다고 밝혔습니다.

다만 비용은 그대로입니다. 클로드는 매 턴 대화 전체를 여전히 읽으니까요. 빨라지는 건 '보내는 시간'이지 '생각하는 값'이 아닙니다. 이 글은 그 차이를 중심으로 풀어 봅니다.

무슨 일이 있었나

앤스로픽은 11월 2일(현지 시간) 클로드 플랫폼 공지에 "Make long-running agents faster with message threads" 라는 글을 올렸습니다. 공지와 기술 문서에서 확인한 사실은 이렇습니다.

Messages API 요청에 thread 파라미터를 더하면 쓸 수 있습니다. 첫 요청은 대화 전체를 담아 스레드를 만들고, 이후 요청은 새 메시지와 직전 응답 ID 만 보냅니다.
스레드는 서버 메모리에 암호화되어 머물고, 디스크에는 쓰지 않습니다. 마지막 요청 뒤 5분이 지나면 만료되고, 그때는 대화 전체를 다시 보내 새 스레드를 시작해야 합니다.
50만~100만 토큰 요청에서 첫 토큰까지의 시간(TTFT) 중앙값이 약 35% 줄었다고 밝혔습니다. 이 숫자는 클로드 코드(Claude Code) 사용자 대부분에게 기본으로 켜 둔 상태에서 잰 것입니다.
가격과 요청 한도는 바뀌지 않습니다. 토큰 사용량도 그대로입니다.
클로드 API 본 플랫폼, AWS 의 Claude Platform, 마이크로소프트 Foundry, 구글 클라우드(앤스로픽 관리형)에서 베타로 쓸 수 있습니다.
베타 헤더는 message-threads-2026-08-12 이고, 문서에 적힌 지원 모델은 Fable 5.1 부터 Sonnet 4.5 까지 현행 라인업 전부입니다.

배경과 맥락 — 왜 '보내는 시간'이 문제가 됐나

LLM API 는 원래 상태가 없습니다(stateless). 모델은 지난 대화를 기억하지 않으니, 클라이언트가 매 요청마다 처음부터 지금까지의 대화를 전부 실어 보냅니다. 사람이 채팅할 때는 괜찮습니다. 몇 십 턴에 수만 토큰이면 끝이니까요.

문제는 코딩 에이전트입니다. 에이전트는 한 세션에 수백 번 요청을 보내고, 그 안에는 파일 내용·명령 출력·스크린샷 같은 도구 결과가 다 들어갑니다. 대화가 수십만 토큰이 되면, 그 덩어리를 매번 올리고 서버가 매번 검증·토큰화하는 시간만으로 첫 응답이 늦어집니다. 앤스로픽 문서는 이걸 이렇게 설명합니다. 스레드가 없으면 "매 턴 대화 전체를 다시 올리고, API 가 그걸 다시 검증하고 토큰화한다"고요.

앤스로픽은 이미 프롬프트 캐싱으로 '계산 비용' 쪽은 한 번 손을 봤습니다. 같은 앞부분을 캐시에서 읽으면 더 싸게 처리하는 방식이죠. 메시지 스레드는 그 옆에 남아 있던 '전송 비용' 쪽을 건드립니다. 둘은 다른 문제를 풉니다. 이 점이 이 발표를 읽는 핵심입니다.

핵심 짚어 보기 — 어떻게 돌아가나

요청 흐름은 두 종류뿐입니다.

메시지 스레드의 요청 흐름

만들기(create)대화 전체 + system + tools 를 보내고 thread: {type: create} 를 더한다. 응답 id 아래에 대화가 저장된다.
이어가기(continue)새 메시지만 보내고 thread: {type: continue, previous_message_id} 를 더한다. system·tools 는 빼야 한다.
다음 턴방금 받은 응답 id 를 다음 continue 에 쓴다. 매 요청마다 5분 타이머가 다시 돈다.
만료·오류5분이 지나거나 404 thread_not_found 가 오면 대화 전체로 새 스레드를 만든다. 그래서 클라이언트는 대화 사본을 꼭 들고 있어야 한다.

위 흐름에서 눈여겨볼 건 '클라이언트가 대화를 버리면 안 된다' 는 점입니다. 서버는 5분 뒤 지우니까요.

문서에서 확인한 세부 규칙 몇 가지를 더 옮깁니다.

고정 필드: model, tool_choice, thinking, 최상위 cache_control 등은 스레드 안에서 매 요청 같은 값을 보내야 합니다. 다르면 400 오류 thread_fingerprint_mismatch 가 납니다. 모델을 바꾸려면 새 스레드를 만들어야 한다는 뜻입니다.
캐싱은 자동이 아닙니다. 스레드는 대화를 '들고 있을' 뿐 캐시하지 않습니다. 매 턴 캐시를 쓰려면 최상위 cache_control 을 매 요청 보내야 하고, 스레드 요청 하나에 캐시 브레이크포인트는 최대 4개입니다.
스트리밍: 응답 id 는 message_start 이벤트에 오지만, 이어가기는 message_stop 을 받은 뒤에 해야 합니다. 일찍 보내면 404 가 날 수 있습니다.
못 쓰는 것: Message Batches, 토큰 카운팅, 온디맨드 압축(compaction)은 스레드와 함께 쓸 수 없습니다.
거부 응답: stop_reason: "refusal" 이 오면 그 스레드를 이어가지 말고 새로 시작하라고 합니다. 거부된 턴을 서버에서 지울 수 없기 때문입니다.
SDK 헬퍼: 공식 SDK 에 스레드 헬퍼가 있어 베타 헤더·고정 필드·system/tools 제외를 대신 처리합니다. 만료되면 대화 전체를 다시 보내는 것도 헬퍼가 합니다. fork() 로 스레드를 복사할 수도 있는데, 포크의 첫 턴은 다시 대화 전체를 보냅니다.

비용이 왜 그대로인가

앤스로픽 공지는 분명하게 적었습니다. "클로드는 매 턴 대화 전체를 읽는다. 토큰 사용량은 바뀌지 않는다." 스레드는 네트워크로 보내는 바이트를 줄이지, 모델이 처리하는 토큰을 줄이지 않습니다. 돈을 아끼고 싶다면 여전히 프롬프트 캐싱을 따로 설계해야 합니다.

35% 를 어떻게 읽을까

조건을 그대로 옮기면 "50만~100만 토큰 요청, TTFT 중앙값, 클로드 코드 사용자 기준" 입니다. 짧은 대화에서는 효과가 거의 없을 겁니다. 보내는 양 자체가 작으니까요. 그리고 이 숫자는 앤스로픽이 밝힌 자사 측정값입니다. 제3자 벤치마크는 아직 없습니다.

다른 시각과 한계

개발자 커뮤니티 반응을 정리한 daily.dev 글(11월 3일 기준 X 토론 2건, 댓글 204개 집계)은 긍정 45%, 혼합 35%, 회의적 20% 로 요약했습니다. 거기서 나온 우려들은 대체로 문서로 답할 수 있습니다.

"5분은 너무 짧다" — 사람이 검토하느라 멈추거나 긴 테스트를 돌리는 워크플로에는 맞지 않을 수 있습니다. 만료 시간을 바꿀 수 있는지는 문서에 없습니다. 대신 SDK 가 알아서 다시 만들어 주니, 체감은 '가끔 한 턴이 느린' 정도일 겁니다.
"서버에 대화가 남는다" — 문서는 메모리에만 두고 디스크에 쓰지 않으며 마지막 사용 뒤 늦어도 1시간 안에 지운다고 밝혔습니다. 하지만 제로 데이터 보관(ZDR) 적격이 아닙니다. 규제 산업이나 ZDR 계약이 있는 조직은 쓰면 안 됩니다. 이건 반론이 아니라 제약입니다.
"아마존 Bedrock 에서 되나" — 댓글에서 안 된다는 말이 나왔지만, 공식 문서는 'Claude Platform on AWS' 를 베타 지원으로 적고 있습니다. 같은 이름이 아니라서 정확히 어느 경로인지는 아직 확인되지 않았습니다.
"캐시 요금은?" — 스레드 자체는 요금에 영향이 없습니다. 캐시 쓰기·읽기 요금은 기존 프롬프트 캐싱 규칙 그대로입니다.

비교 삼아 OpenAI 쪽을 보면, Responses API 의 previous_response_id 가 비슷한 역할을 합니다. OpenAI 문서도 "체인 안의 이전 입력 토큰은 모두 입력 토큰으로 과금된다"고 적어 두었습니다. 즉 두 회사 모두 '전송'은 줄이되 '과금'은 그대로라는 점이 같습니다. 다른 점은 보관 기간입니다. OpenAI 는 응답 객체를 기본 30일 저장하고(store: false 로 끌 수 있음) 별도 Conversations API 는 그 제한도 없습니다. 앤스로픽은 5분 만료에 디스크 저장 없음입니다. 편의성은 OpenAI 쪽이, 보관 최소화는 앤스로픽 쪽이 더 무겁게 둔 설계로 보입니다.

그래서 우리에게

클로드 API 로 에이전트를 만드는 개발자라면

대화가 수십만 토큰까지 자라는 루프(코딩·컴퓨터 사용·문서 처리)가 있다면 SDK 스레드 헬퍼부터 써 보세요. 베타 헤더와 고정 필드 처리를 대신해 줍니다.
속도와 비용을 분리해서 생각하세요. 비용은 cache_control 을 스레드 안에서 매 요청 보내야 줄어듭니다.
오류 처리는 error.details.error_code 로 분기하세요. thread_not_found(404) 면 전체 재전송, thread_fingerprint_mismatch(400) 면 고정 필드를 되돌리는 식입니다.
대화 사본은 반드시 클라이언트가 보관합니다. 서버는 저장소가 아닙니다.

ZDR 이나 의료 데이터 계약이 있는 조직이라면 이 기능은 쓸 수 없습니다. SDK 의 베타 도구 러너가 스레드를 기본으로 켠다고 하니, 끄는 옵션을 확인해 두는 게 안전합니다.

클로드 코드를 쓰는 사람이라면 이미 켜져 있을 가능성이 큽니다. 긴 세션에서 첫 글자가 조금 빨리 나오는 게 그 효과입니다.

일반 사용자·투자자라면 당장 바뀌는 건 없습니다. 다만 '에이전트가 길게 일할수록 API 회사가 서버 쪽 상태를 더 들고 가는' 흐름이 양사 모두에서 확인된다는 점은 기억해 둘 만합니다.

앞으로 지켜볼 것

공개 베타가 정식(GA)이 되는 시점과, 그때 5분 만료가 바뀌는지.
ZDR 적격 여부가 바뀌는지. 지금은 '아님'으로 명시되어 있습니다.
AWS 경로의 정확한 지원 범위(Bedrock 포함 여부).
제3자가 잰 TTFT 수치. 지금은 앤스로픽 자체 측정값뿐입니다.

맺으며

저는 작은 앱을 혼자 만드는 사람이라 긴 에이전트 루프를 돌릴 일은 아직 적습니다. 그래도 이 발표를 읽으면서, 요즘 AI API 의 발전이 '모델이 더 똑똑해졌다'보다 '같은 모델을 덜 기다리게 한다' 쪽으로 많이 움직인다는 생각이 들었습니다. 화려하진 않지만, 매일 쓰는 도구는 이런 데서 체감이 달라지더군요.

여러분은 에이전트를 돌릴 때 어느 쪽이 더 답답하셨나요. 첫 글자가 늦게 나오는 것, 아니면 청구서요?

출처

Anthropic, "Make long-running agents faster with message threads" (2026-11-02): https://claude.com/resources/articles/message-threads
Claude Platform 문서, "Message threads": https://platform.claude.com/docs/en/build-with-claude/message-threads
OpenAI 문서, "Conversation state": https://developers.openai.com/docs/guides/conversation-state
The Next Web, "Anthropic's message threads let Claude agents skip resending chats": https://thenextweb.com/news/anthropic-message-threads-beta-claude-api-agents
daily.dev, "Anthropic adds message threads to the Claude Messages API in public beta": https://daily.dev/posts/anthropic-adds-message-threads-to-the-claude-messages-api-in-public-beta-a4vfrfrii