앤스로픽, 클로드 API 메시지 스레드 공개

앤스로픽이 11월 2일(현지시간) 클로드 Messages API에 메시지 스레드(message threads) 기능을 공개 베타로 내놓았다. 대화를 서버에 잠시 붙잡아 두고, 둘째 턴부터는 새 메시지와 직전 응답의 ID만 보내게 하는 방식이다. 앤스로픽은 공식 글에서 "메시지 스레드를 쓰면 에이전트가 매 턴 전체 대화 기록을 다시 보낼 필요가 없어 장시간 세션의 지연이 줄어든다"고 밝혔다. 회사는 클로드 코드 이용자 대부분에게 이 기능을 기본으로 켠 결과, 50만~100만 토큰 규모 요청에서 첫 토큰까지 걸리는 시간(TTFT)의 중앙값이 약 35% 줄었다고 설명했다.

기능이 겨냥한 병목은 긴 에이전트 루프다. 앤스로픽에 따르면 코딩 에이전트는 한 세션에서 수백 번 요청을 보내고, 요청마다 앞선 메시지와 도구 실행 결과를 전부 다시 싣는다. 대화가 수십만 토큰에 이르면 이 재전송이 클로드가 답을 시작하기 전의 시간을 늘린다. 공식 문서는 스레드가 없으면 매 턴 전체 대화를 다시 업로드하고 API가 그 전체를 다시 검증하고 토큰화한다고 적었다. 스레드를 쓰면 이 작업 대부분이 새 턴에만 걸린다.

쓰는 법은 매개변수 하나다. 첫 요청에는 지금처럼 전체 대화와 시스템 프롬프트, 도구 정의를 담고 "thread": {"type": "create"}를 붙인다. API는 클로드의 응답까지 포함한 대화를 그 응답 ID 아래에 저장한다. 다음 요청부터는 직전 응답 이후의 메시지만 보내면서 type을 continue로, previous_message_id에 직전 응답 ID를 넣는다. 이때 system과 tools는 빼야 하고, 하나라도 보내면 값이 null이어도 400 오류가 난다. 스레드에 속한 모든 요청에는 message-threads-2026-08-12 베타 헤더가 붙는다.

대화는 서버 메모리에만 머문다. 공식 문서에 따르면 스레드 내용은 서버가 관리하는 키로 암호화돼 메모리에 보관되고 영구 저장소에는 기록되지 않는다. 스레드는 마지막 요청 뒤 5분이 지나면 만료되고, API는 마지막 사용 뒤 1시간 안에 이를 지운다. 응답이 하나 저장될 때마다 5분이 다시 시작된다. 보관은 최선 노력(best-effort) 방식이라 계속 요청이 404 오류로 돌아오면 전체 대화를 새 생성 요청으로 다시 보내야 한다. 문서는 "애플리케이션이 대화의 기준 원본으로 유지된다"며 모든 메시지의 사본을 직접 보관하라고 못 박았다.

비용 구조는 바뀌지 않는다. 앤스로픽은 "메시지 스레드로 요청 하나하나는 작아지지만 클로드는 매 턴 여전히 전체 대화를 읽으므로 토큰 사용량은 같다"고 밝혔다. 표준 토큰 요금과 기존 속도 제한이 그대로 적용된다. 프롬프트 캐싱도 자동으로 붙지 않는다. 개발자가 캐시 중단점을 직접 두거나 최상위 cache_control을 매 요청에 보내야 하고, 스레드 요청 하나에 둘 수 있는 cache_control 중단점은 최대 4개다.

규칙은 꽤 촘촘하다. 문서는 요청 필드를 세 묶음으로 나눴다. system과 tools는 생성 요청에만 보내는 필드다. model, tool_choice, thinking, mcp_servers, output_config, 최상위 cache_control 같은 고정 필드는 매 요청 같은 값이어야 하고, 다르면 thread_fingerprint_mismatch 오류가 난다. max_tokens, stream, metadata 같은 나머지는 턴마다 바꿀 수 있다. 스레드는 덧붙이기만 되고 응답 ID 하나는 한 번만 이어 갈 수 있어, 이전 턴을 고치거나 대화를 갈래로 나누려면 새 스레드를 열어야 한다. 오류 코드는 thread_not_found부터 thread_unsupported_request까지 다섯 가지이고, 모두 모델이 돌기 전에 반환돼 토큰을 쓰지 않는다.

적용 범위에서 빠진 기능도 문서에 적혀 있다. 메시지 배치, 토큰 카운팅, 온디맨드 압축, 대부분의 컨텍스트 편집은 스레드와 함께 쓸 수 없다. HIPAA 준비가 활성화된 조직과 인퍼런스 훅(Inference hooks)을 켠 조직에서도 쓸 수 없고, 제로 데이터 보존(ZDR) 적용 대상도 아니다. 스레드를 나열하거나 읽거나 지우는 API는 없다. 스트리밍에서는 message_stop 이벤트를 받은 뒤에야 그 응답 ID로 이어 갈 수 있고, 거부(refusal) 응답이나 폴백 모델이 쓴 턴 뒤에는 새 스레드를 열어야 한다.

대상은 지연이 중요한 활성 세션이다. 앤스로픽은 파일 수정과 도구 결과가 계속 쌓이는 장시간 코딩 에이전트, 스크린숏을 매 턴 다시 올리지 않고 스레드에 남겨 두는 컴퓨터 사용 에이전트, 문서와 이미지가 많은 작업을 꼽았다. 공개 베타는 Claude Platform과 Claude Platform on AWS, Microsoft Foundry의 Claude, 구글 클라우드의 Claude 모델(앤스로픽 관리형)에서 열렸고 모든 모델에서 베타 상태다. SDK에는 생성과 계속, 베타 헤더, 404 뒤 재전송을 대신 처리하는 스레드 헬퍼(client.beta.messages.thread)가 들어갔고, 베타 도구 러너는 기본으로 스레드를 쓴다.

메탈이 확인한 클로드 개발자 공식 X 계정의 발표 글은 게시 약 한 시간 만에 조회수 12만 5,000회와 좋아요 2,500개를 넘겼다. 함께 올라온 35초 영상은 2턴, 18턴, 87턴째에 같은 내용을 되풀이해 보내며 막대가 불어나는 장면으로 문제를 보여 주고, 스레드를 쓰면 시스템 프롬프트는 한 번만 보내고 이후에는 새로 생긴 것만 보낸다고 설명한다. 메탈은 오픈AI가 GPT-6의 프롬프트 캐싱 개선을 발표한 소식을 보도한 바 있다. 캐싱이 이미 읽은 앞부분의 계산을 아끼는 장치라면, 메시지 스레드는 그 앞부분을 네트워크로 다시 실어 나르는 일 자체를 덜어 낸다. 대화 기록은 여전히 개발자의 몫으로 남기고 전송량과 대기 시간만 줄인 이번 설계는, 에이전트 경쟁의 축이 모델의 답 품질에서 응답이 시작되는 속도로 넓어지고 있음을 보여 준다.