긴 컨텍스트는 필요 없다: 잦은 compaction과 선택적 읽기

Who Should Read

긴 에이전트 루프나 긴 문서 QA에서 토큰 비용과 지연이 커져 고민인 LLM 앱 개발자

Core Mechanics

• 뒤쪽 토큰이 더 비싸다
  • 컨텍스트 윈도우를 256K에서 16K로 줄이면 토큰당 비용이 GLM 5.2 3.6배, Kimi K2.6 5.6배, Qwen 3 Coder Next 7배 낮아진다.
  • 리테일 가격은 길이와 무관하게 고정이라 사용자 눈에는 이 차이가 안 보인다.
• 에이전트는 히스토리를 다 안 들고 가도 된다
  • 컨텍스트가 한도에 닿으면 요약(compaction)하고 새 대화로 이어가는 방식(EoCC)을 썼다.
  • Claude Opus 4.5와 GPT 5.6 Sol 모두 대부분의 설정에서 정확도가 거의 유지됐다.
• 긴 문서는 통째로 넣지 말고 파일로 두고 grep으로 읽기
  • 긴 입력을 파일로 저장하고 에이전트가 grep·sed로 필요한 부분만 읽게 했다.
  • 긴 입력 문제가 에이전트 문제로 바뀌어 컨텍스트가 문서 길이에 비례해 커지지 않았다.
• 매 행동마다 압축해도 버틴다
  • 행동 1번당 새 대화를 열고 요약된 상태(semantic state)만 넘기는 방식(SAC)도 테스트했다.
  • 피크 컨텍스트 중앙값이 7~9K 토큰이었는데도 정확도는 대체로 유지됐다.
• 모든 모델에 통하지는 않는다
  • 오픈웨이트 Qwen 3 Coder Next는 SWE-bench Verified에서 16K/12K일 때 53.0%에서 3.6%로 무너졌다.
  • 출력이 장황한 모델은 압축 사이에 진행할 여유가 없어서 실패했다.
• 압축은 손실이 있다
  • 코인 던지기 결과처럼 모든 기록이 필요한 작업은 압축하면 반드시 틀린다.
  • 해결책은 전체 기록을 파일로 남기고 필요할 때 선택적으로 읽는 것이다.

Evidence

• 장기 에이전트 작업에서 정확도 변화는 작고 비용은 크게 줄었다
  • Opus 4.5는 정확도 변화가 -3.7~+5.6%p, 비용 절감이 2.2~8.8배였다(풀 히스토리 기준).
  • GPT 5.6 Sol은 -3.3~+4.4%p, 비용 절감 2.4~5.0배였다.
• AA-LCR에서 선택적 읽기가 전체 입력보다 나았다
  • 16K/12K에서 Opus 4.5 정확도는 65.0%에서 84.0%로 올랐다.
  • GPT 5.6 Sol은 82.0%에서 83.0%로 올랐다.
• RULER와 BABILong에서 정확도가 크게 올랐다
  • RULER recall은 Opus 4.5 62.5%에서 95.7%, GPT 5.6 Sol 65.5%에서 96.4%로 올랐다.
  • BABILong 정확도는 Opus 4.5 67.1%에서 92.0%, GPT 5.6 Sol 70.7%에서 94.0%로 올랐다.
• SAC는 Claude에서 정확도를 유지하거나 올렸다
  • Opus 4.5의 Terminal-Bench는 mini baseline 47.2%에서 SAC 51.8%로 올랐다.
  • GPT 5.6 Sol은 SWE-bench Verified에서 84.4%에서 82.4%, Terminal-Bench에서 87.6%에서 84.3%로 소폭 하락했다.

How to Apply

• 에이전트에 compaction 프롬프트 붙이기
  • 대화가 16K~48K 토큰 근처에 오면 지금 쓰는 에이전트 루프에 인수인계 요약 요청을 한 번 넣어라.
  • 요약 뒤에는 시스템 프롬프트, 원래 과제, 요약만 가진 새 대화로 이어가라.
• 긴 문서를 파일로 두고 grep으로 읽게 하기
  • RAG나 문서 QA에서 문서를 프롬프트에 통째로 붙이는 부분을 파일 저장으로 바꿔라.
  • bash 도구로 grep, sed, head를 쓰게 하고 한 번에 읽는 양을 6000자 안팎으로 제한하라.
• 압축 임계값별로 정확도와 비용 재기
  • 자체 평가셋으로 풀 히스토리와 48K, 32K, 16K 임계값을 비교하라.
  • 정확도와 토큰 총량을 같이 기록해서 재시도로 늘어난 토큰이 절감분을 깎는지 확인하라.
• 압축된 내용이 사라지면 안 되는 정보는 파일로 남기기
  • 모든 도구 결과 로그를 파일로 저장하고 에이전트가 필요할 때 읽게 하라.
  • 요약에는 파일 경로와 읽을 명령을 적게 하라.

Try It

# Claude Code나 에이전트 루프에서 컨텍스트가 길어졌을 때 붙여넣는 프롬프트 (논문 방법의 간이 버전)

Stop work. Write only a concise handoff recap; do not call tools.
The conversation will reset, and the system prompt, task, and recap will be provided again.
Files and environment state remain available: {{유지되는 파일·환경}}

Preserve what your next stretch needs:
1. Current progress and best answer/result, separating verified facts from assumptions.
2. Relevant evidence with exact values and source locations; changes already made, with paths and verification status.
3. What was solved, what worked, what remains unresolved, what failed, and useful commands already tried.
4. Remaining plan - outstanding subgoals in execution order; the immediate next command or edit; and the condition for completion.
If important output was truncated, name a narrow command to retrieve the missing part. Do not invent observations or repeat the full task.

이어서 해 볼 것: 이 요약을 새 대화의 첫 메시지에 원래 과제와 함께 넣고 작업이 이어지는지 확인하세요.

Terminology

관련 논문

• LLM 추론을 암호학적으로 증명하는 FlashProve (Provable Inference)

  zkSNARK로 400B 모델 응답을 증명했더니 GPU 시간이 70~95배 들었다

• Gemini는 구독자 개인 계정의 대화 기록도 학습에 쓴다 (HN 댓글 기반)

  Gemini 개인 계정은 구독해도 대화가 학습·사람 검토에 쓰일 수 있다

• JavaScript 프레임워크별 AI 에이전트 빌드 비용 벤치마크

  같은 앱을 12개 프레임워크로 에이전트에 5번씩 짜게 했더니 비용이 최대 약 2배 차이

• Claude Code가 백그라운드 에이전트 상태줄에 토큰을 쓰는 문제와 Bun preload 우회법

  30초마다 에이전트 전체 대화를 보내던 상태줄 요약을 끄니 요청 19.7%가 사라졌다

• GLM-5.3 Workers AI의 KV cache 교차 노출 사고와 SGLang 수정

  컨텍스트 창보다 작은 KV 풀 때문에 긴 프롬프트 155건에 타인 데이터가 섞였다

• Microsoft Decision-1: Qwen3.5-9B 기반 결정 점수 전용 모델

  글 대신 선택지별 확률만 내놓는 9B 모델, 라우팅·분류용으로 공개

• Cerebras가 조 단위 파라미터 모델을 웨이퍼 여러 장에 올리는 방법

  Kimi K3(3T)를 웨이퍼 59장 파이프라인에 올려 초당 1000~2000+ 토큰을 낸다

• AI 이미지 생성 실전 가이드: diffusion부터 에이전트 연동까지

  이미지 API를 직접 써 보니 캔버스 단위 과금과 카메라 묘사 프롬프트가 핵심이었다