에이전트가 쉰 번째 턴을 돌고 있어요. 첫 턴에 "금액은 원 단위, 반올림하지 않기"라고 적어 뒀는데, 마흔 번째 턴쯤부터 천 원 단위로 올려 적기 시작해요. 로그를 열어 보면 컨텍스트는 아직 한도의 절반도 안 찼어요. 자리가 모자란 게 아니었어요. 읽을 게 너무 많았던 거예요.
이번 주에 나온 소식 하나가 이 장면을 다시 꺼내게 했어요. 요청을 작게 보내는 기능인데, 모델이 읽는 양은 그대로라는 설명이 붙어 있었거든요.
전송은 줄었는데, 모델이 읽는 양은 그대로예요
11월 2일 Anthropic 이 Messages API 에 메시지 스레드(message threads) 공개 베타를 열었어요. 첫 요청에 대화 전체를 보내 스레드를 만들고, 그다음부터는 새 메시지와 직전 응답 ID 만 보내요. Anthropic 발표로는 50만~100만 토큰짜리 요청에서 첫 토큰까지의 시간 중앙값이 약 35% 줄었다고 해요. Claude Code 사용자 대부분에게는 기본으로 켜졌고요.
그런데 같은 글에 이렇게 적혀 있어요. 요청은 작아져도 Claude 는 매 턴 대화 전체를 읽기 때문에 토큰 사용량은 변하지 않는다고요. 빨라진 건 업로드와 재토큰화예요. 모델의 주의가 아니에요. 스레드는 마지막 요청 뒤 5분이면 만료되고 조회 · 삭제 API 도 없어서, 대화 기록의 정본은 앱이 계속 들고 있어야 해요.
보내는 비용이 싸질수록, 무엇을 보내지 않을지는 더 또렷하게 우리 몫이 돼요.
한도가 남아도 틀리기 시작하는 이유
Chroma 가 2025년 7월에 모델 18개로 잰 결과가 있어요. 입력이 길어질수록 성능이 균일하게 유지되지 않고 점점 불안정해진다는 거예요. 같은 질문을 대화 전체 약 11만 3천 토큰으로 줄 때와 답에 필요한 부분만 약 300토큰으로 줄 때를 비교했는데, 18개 모델 전부가 짧은 쪽에서 더 잘했어요. 관련 없는 문장이 하나만 끼어도 정확도가 떨어졌고요.
Anthropic 은 이걸 컨텍스트 부패(context rot)라고 부르고, 컨텍스트를 한계 효용이 줄어드는 유한한 자원이라고 설명해요. 토큰 n 개가 n² 쌍의 관계를 만들어서, 새 토큰이 들어올 때마다 주의 예산이 깎여요. 쉰 번째 턴의 에이전트가 규칙을 어긴 건 규칙이 지워져서가 아니라, 규칙 앞뒤로 도구 결과 수십만 토큰이 쌓여서예요.
토큰 비용 글에서 입력 토큰이 턴 수의 제곱으로 쌓인다고 썼는데, 돈만 제곱으로 느는 게 아니에요. 틀릴 확률도 같이 늘어요.
가장 먼저 버릴 건 오래된 도구 결과예요
무엇부터 버릴지는 답이 정해져 있어요. Anthropic 엔지니어링 글은 도구 결과 비우기를 가장 안전하고 가벼운 압축이라고 불러요. 열 턴 전에 조회한 ERP 응답 4천 토큰을 모델이 다시 볼 일은 거의 없거든요.
Claude API 에는 이걸 규칙으로 돌리는 컨텍스트 편집이 있어요. 입력이 기준을 넘으면 오래된 도구 결과부터 지우고, 그 자리에 지웠다는 표시만 남겨요. 저희는 기준을 기본값 10만보다 낮게 두고, 지울 때는 한 번에 충분히 지우게 해요. 지우면 프롬프트 캐시가 그 지점에서 깨지니까, 조금씩 자주 지우면 캐시만 잃고 얻는 게 없거든요.
{
"context_management": {
"edits": [{
"type": "clear_tool_uses_20250919",
"trigger": { "type": "input_tokens", "value": 30000 },
"keep": { "type": "tool_uses", "value": 3 },
"clear_at_least": { "type": "input_tokens", "value": 5000 },
"exclude_tools": ["read_policy"]
}]
}
}달라지는 건 턴이 쌓여도 모델이 읽는 양이 일정 선에서 멈춘다는 거예요. exclude_tools 에 넣은 규정 조회 결과는 끝까지 남아요. Anthropic 자체 평가에선 100턴짜리 웹 검색 작업에서 토큰 소비가 84% 줄었고, 편집만으로 29%, 메모리 도구를 같이 쓰면 39% 성능이 올랐다고 해요. 벤더 자체 평가라 방향만 가져가요.
요약으로 접을 땐 무엇을 남길지 먼저 적어요
도구 결과를 비워도 결국 대화는 차요. 그다음이 압축(compaction)이에요. 오래된 턴을 요약 한 덩어리로 바꾸고 최근 턴만 그대로 두는 방식인데, 이제 양쪽 API 가 서버에서 해 줘요. OpenAI 는 compact_threshold 를 넘으면 서버가 압축하고 결과는 사람이 읽을 수 없는 항목이에요. Claude 는 요청형과 토큰 기준 자동형이 따로 있고 요약 프롬프트를 직접 쓸 수 있어요. 스레드와는 같이 못 써서 요약으로 새 스레드를 시작해야 하고요.
중요한 건 어느 API 냐가 아니라 요약이 무엇을 남기느냐예요. Claude Code 는 압축할 때 설계 결정 · 해결 안 된 버그 · 구현 세부를 남기고 중복된 도구 출력을 버린 뒤, 최근에 연 파일 다섯 개를 다시 붙여요. Anthropic 은 요약 프롬프트를 재현율(recall)부터 맞추고 그다음에 정밀도를 올리라고 적어요. 빠뜨리는 게 늘어놓는 것보다 비싸거든요.
저희는 요약 프롬프트에 기대기 전에, 요약과 무관하게 살아남을 상태 메모를 컨텍스트 밖에 둬요. Anthropic 이 구조화된 메모라고 부르는 방식이에요. 결정 · 제약 · 식별자 · 미해결 항목, 네 줄이에요.
# runs/settlement-2026-11/state.yaml — 턴마다 갱신, 압축돼도 다시 읽어요
constraints:
- 금액은 원 단위, 반올림 금지
- 거래처 코드는 ERP 값 그대로 (사용자 입력 무시)
decisions:
- 10월분은 세금계산서 발행일 기준으로 집계 (turn 7)
ids:
batch_id: STL-2026-10-B
erp_query_id: q-88213
open_items:
- 거래처 3곳 미수 확인 대기 (turn 41)달라지는 건 압축이 무엇을 잘라도 이 파일은 남는다는 거예요. 요약이 반올림 규칙을 빠뜨려도 다음 턴은 이 파일을 먼저 읽어요. 멱등성 키 글에서 키를 모델 밖 업무 식별자에서 가져오라고 한 것과 같은 이유예요.
세 정책을 60턴으로 계산해 봤어요
측정은 아니고 가정값 계산이에요. 시스템 프롬프트와 도구 정의 3천 토큰, 턴마다 사용자 150 · 도구 결과 4천 · 답변 300 토큰이 쌓인다고 두고, 60턴 동안 모델이 읽는 입력 토큰을 더했어요.
| 정책 | 60턴 누적 입력 | 턴당 최대 입력 |
|---|---|---|
| 아무것도 안 함 | 약 832만 | 27만 |
| 도구 결과 비우기 (3만 넘으면 최근 3개만 유지) | 약 182만 | 4.3만 |
| 요약 압축 (6만 넘으면 2,500토큰 요약 + 최근 3턴) | 약 221만 | 5.9만 |
도구 결과 비우기만으로 누적 입력이 5분의 1 근처로 내려와요. 캐시를 빼고 계산했으니 실제 청구는 다르고, 도구 결과가 더 크면 차이는 더 벌어져요. 중요한 건 숫자보다 모양이에요. 아무것도 안 하면 읽는 양이 턴마다 늘고, 나머지 둘은 어느 선에서 멈춰요. 그 선 아래에서 규칙을 지키는지는 골든셋으로 재야 해요.
| AS-IS | TO-BE | |
|---|---|---|
| 긴 세션 대응 | 컨텍스트가 더 큰 모델로 바꿔요 | 읽는 양을 일정 선에서 멈춰요 |
| 버리는 순서 | 한도에 걸리면 앞부분을 잘라요 | 오래된 도구 결과 → 요약 압축 순서로, 규정 조회는 예외 |
| 규칙 · 식별자 | 첫 턴 프롬프트에만 있어요 | 컨텍스트 밖 상태 메모에 두고 턴마다 읽어요 |
| 전송 | 매 턴 전체를 다시 보내요 | 스레드로 새 메시지만 보내고, 정본은 앱이 보관해요 |
바로 믿으면 안 되는 세 가지
하나, 35% 는 50만~100만 토큰 요청에서 잰 Anthropic 수치예요. 몇만 토큰짜리 요청에서 얼마나 줄어드는지는 발표에 없어요. 저희 세션 크기로 다시 재야 해요.
둘, 84% · 39% 는 벤더 자체 평가예요. 위 60턴 계산도 가정값이고요. 우리 숫자는 편집을 켠 뒤의 골든셋 통과율과 턴당 입력 토큰이에요.
셋, 압축은 잃는 걸 전제로 해요. OpenAI 압축 항목은 사람이 읽을 수 없고, Claude 요약도 프롬프트를 손보기 전엔 무엇을 빠뜨렸는지 몰라요. 상태 메모가 그 보험이에요.
무엇을 버릴까요의 답은, 모델이 다시 볼 일 없는 것부터예요
쉰 번째 턴에 필요했던 건 더 큰 컨텍스트가 아니라, 마흔 턴치 도구 결과를 치우는 규칙과 반올림 규칙이 적힌 파일 한 장이었어요. 전송이 빨라져도 읽는 양을 정하는 건 여전히 우리예요. 어느 선에서 멈출지, 요약에 무엇을 남길지는 세션마다 다르고, 저희도 계속 다듬는 중이에요.
자주 묻는 질문
Q. 컨텍스트가 100만 토큰인 모델을 쓰면 해결되나요? A. 한도가 늘어나는 거지 주의 예산이 느는 건 아니에요. Chroma 실험에서 긴 입력은 18개 모델 전부에서 짧은 입력보다 못했어요.
Q. 메시지 스레드를 켜면 비용이 줄어요? A. 아니에요. Anthropic 발표대로 토큰 사용량은 그대로고 표준 단가가 적용돼요. 줄어드는 건 요청 크기와 첫 토큰 대기 시간이에요.
Q. 도구 결과를 지우면 모델이 다시 조회하지 않나요?
A. 필요하면 다시 불러요. 조회 비용이 크거나 규정처럼 끝까지 봐야 하는 도구만 exclude_tools 로 빼두면 돼요.
Sources
- Claude — Make long-running agents faster with message threads (2026-11-02): https://claude.com/resources/articles/message-threads
- Claude Platform Docs — Message threads (beta): https://platform.claude.com/docs/en/build-with-claude/message-threads
- Anthropic Engineering — Effective context engineering for AI agents (2025-09-29): https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Claude — Managing context on the Claude Developer Platform (2025-09-29): https://claude.com/blog/context-management
- Claude Platform Docs — Context editing: https://platform.claude.com/docs/en/build-with-claude/context-editing
- Claude Platform Docs — Compaction overview: https://platform.claude.com/docs/en/build-with-claude/compaction
- OpenAI — Compaction guide: https://developers.openai.com/api/docs/guides/compaction
- Chroma Research — Context Rot: How Increasing Input Tokens Impacts LLM Performance (2025-07-14): https://www.trychroma.com/research/context-rot
도입부 장면과 state.yaml 은 설명용 구성이고 고객사 사례가 아니에요. 60턴 계산은 가정값이고 측정값이 아니에요.