Anthropic 메시지 스레드가 긴 대화의 첫 토큰 시간을 35% 단축한다

Anthropic이 Claude 플랫폼에서 메시지 스레드(Message Threads)를 퍼블릭 베타로 열었다. 지금까지 Claude API를 호출할 때마다 애플리케이션은 대화의 처음부터 끝까지를 매번 다시 실어 보내야 했다. 메시지 스레드는 이 전제를 바꿔, 직전 메시지 이후 달라진 부분만 전송한다.

효과가 가장 뚜렷한 구간은 컨텍스트가 이미 두꺼워진 요청이다. 50만 토큰에서 100만 토큰 사이의 요청을 기준으로 첫 토큰이 나오기까지 걸리는 시간이 약 35% 줄어든다고 Anthropic은 설명한다. 대화가 길어질수록 매 요청에 실리는 중복 데이터가 커지던 구조에서, 그 중복을 걷어낸 셈이다.

회사가 꼽은 대표 수혜 워크로드는 코딩 에이전트, 컴퓨터를 직접 조작하는 에이전트, 그리고 문서와 이미지를 대량으로 다루는 파이프라인이다. 이들은 공통적으로 한 세션이 길게 이어지고, 그만큼 이력이 누적된 상태에서 다음 요청을 계속 던지는 패턴을 갖는다.

동작 방식에서 눈여겨볼 지점은 스레드의 수명이다. 요청과 요청 사이에 스레드는 메모리 위에 암호화된 형태로 남아 있고, 5분 동안 아무 활동이 없으면 만료된다. 세션을 오래 붙잡아 두는 워크로드일수록 이 유지 조건이 실제 이점으로 이어지고, 호출 간격이 뜸한 경우에는 그렇지 않을 수 있다는 뜻이다.

비용 계산은 달라지지 않는다. Claude가 여전히 전체 대화 이력을 읽는 구조이기 때문에 토큰 사용량 자체는 동일하다. 이번 발표가 겨냥한 것은 과금이 아니라 지연, 그중에서도 사용자가 첫 응답을 보기까지 기다리는 시간이다.

배경에는 에이전트 중심으로 옮겨간 API 사용 패턴이 있다. 한 번의 질의응답이 아니라 수십, 수백 번의 호출이 이어지는 워크플로가 일반화되면서, 호출마다 이력을 다시 붙이는 오버헤드가 응답 속도의 병목으로 부각됐다. 메시지 스레드는 이 지점을 프로토콜 수준에서 손본 기능이다.

적용 범위는 Claude 플랫폼에 국한되지 않는다. AWS, Microsoft Foundry, Google Cloud를 경유하는 호출에서도 같은 기능을 쓸 수 있다. 멀티 클라우드로 Claude를 붙여 쓰는 조직이라면 별도 경로를 만들 필요가 없다.

실무 관점에서 달라지는 것은 긴 세션의 체감 속도다. 컨텍스트가 50만 토큰을 넘어가는 구간에서 첫 토큰까지의 대기가 3분의 1가량 줄어들면, 에이전트가 다음 행동을 결정하기까지의 텀도 그만큼 짧아진다. 다만 토큰 청구서가 줄어드는 것은 아니므로, 비용 최적화와 지연 최적화를 별개 과제로 봐야 한다.

주의할 전제도 분명하다. 아직 퍼블릭 베타 단계이고, 스레드가 5분 비활성으로 만료되는 구조이므로 대화 재개가 드문 사용 패턴에서는 이득이 제한적일 수 있다. 세부 동작과 제약은 Anthropic 문서에서 확인하는 것이 안전하다.