[SIGNAL-CTXS-245] 컨텍스트 압축(compaction) 구현 — 요약 마커와 원문 보존 전략

SIGNAL-CTXS-245. 대화형 에이전트가 길게 돌면 context window가 한계에 닿는다. 이때 오래된 turn을 통째로 잘라내는 대신 요약으로 치환해 대화를 계속 이어가는 기법이 compaction(압축)이다. 문제는 압축이 일어났다는 사실 자체가 대화 로그 안에서 잘 드러나지 않는다는 점이다 — 구현하는 쪽이 명시적으로 마커를 남기지 않으면, 이후 어떤 turn이 원문이고 어떤 turn이 요약인지 구분할 방법이 없다.

왜 압축이 필요한가

Anthropic 공식 문서는 context window를 모델의 “working memory”로 설명하면서, 토큰 수가 늘어날수록 정확도와 회상 능력이 떨어지는 현상을 context rot이라 부른다. 시스템 프롬프트, 모든 메시지, 도구 결과, 도구 정의까지 요청에 포함되는 모든 것이 context window를 소비하기 때문에, 대화가 길어질수록 남는 여유 토큰은 줄어든다. 장기 실행 에이전트나 멀티턴 대화에서는 이 한계에 부딪히기 전에 오래된 turn을 정리하는 전략이 필요하고, Anthropic은 이를 서버사이드 compaction으로 제공한다.

on-demand 압축 vs threshold 압축

Claude API는 두 가지 서버사이드 압축 방식을 제공한다. 베타 헤더는 compact-2026-09-04이며 최상위 compaction 파라미터로 제어한다.

on-demand 압축은 messages 배열의 앞부분을 요약 블록으로 교체해 돌려주고, 애플리케이션은 이후 요청에서 그 블록을 기존 메시지 대신 맨 앞에 넣어 보낸다. threshold 압축은 반대로 애플리케이션이 개입할 필요 없이, 입력 토큰이 지정한 트리거에 닿으면 API가 요청 내부에서 압축을 수행하고 그 이전 내용을 드롭한다. 두 방식 모두 최근 몇 턴은 원문 그대로 유지할 수 있는 옵션(keep recent turns)을 제공한다.

요약 마커를 직접 남겨야 하는 이유

API 차원의 compaction은 대화를 이어가는 데는 문제가 없지만, 그 요약이 언제, 어떤 범위를 대체했는지는 애플리케이션이 별도로 기록하지 않으면 사라진다. 압축된 turn과 원본 turn은 이후 요청에서 동일한 confidence로 취급되기 때문에, 이후 디버깅 단계에서 “이 판단이 원문 근거인지 요약 근거인지”를 되짚을 방법이 없다. 실무에서는 최소한 다음 세 가지를 로그에 남기는 편이 안전하다.

• 압축 발생 시각과 대상 turn 범위(어느 메시지부터 어느 메시지까지 요약됐는지)
• 사용한 압축 방식(on-demand / threshold)과 압축 전후 토큰 사용량(usage 필드 값)
• 커스텀 요약 프롬프트를 썼다면 그 프롬프트 버전, 기본 요약을 썼다면 그 사실 자체

이 기록이 있으면 이후 세션에서 이상한 답변이 나왔을 때, 원문 손실이 원인인지 다른 요인인지를 구분할 수 있는 최소한의 TRACE가 남는다. Anthropic 문서는 압축 대신 도구 결과나 thinking 블록만 정리하고 싶을 때는 context editing(tool result clearing, thinking block clearing)을 별도로 제공한다고 안내한다 — 대화 전체를 요약하는 대신 특정 종류의 블록만 규칙적으로 비우는 방식이라, 압축보다 손실 범위가 예측 가능하다.

threshold 압축 적용 시 체크리스트

1. 대화 길이가 예측 불가능한 워크플로우인가? → threshold 압축이 코드량이 적다.
2. 압축 시점을 애플리케이션이 통제해야 하는가(예: 특정 단계 전에는 절대 압축 금지)? → on-demand로 전환.
3. 최근 N턴은 반드시 원문이 필요한가(예: 방금 사용자가 준 수치)? → 두 방식 모두 keep-recent-turns 옵션을 확인.
4. 압축 사실을 로그·DB에 별도로 기록하는가? → 없다면 지금 추가한다.
5. thinking 블록을 함께 보내는 모델을 쓰는가? → compaction과 preserved thinking의 상호작용 문서를 먼저 읽는다.

두 방식 모두 2026년 9월 기준 베타이며 지원 모델이 제한적이다. 적용 전에 사용 중인 모델이 호환 목록에 있는지 공식 문서의 Compatibility 항목을 먼저 확인하는 편이 안전하다.

FAQ

Q. 압축된 대화도 프롬프트 캐싱이 적용되나?
A. 캐싱은 요청에 포함된 토큰이 실제로 얼마나 되는지에 대해서만 요금을 바꿀 뿐, 압축 여부와 별개로 캐시된 prefix도 context window는 그대로 소비한다.

Q. 직접 요약 로직을 짜는 것과 API 압축 중 뭐가 나은가?
A. 이미 자체 요약 파이프라인이 있고 전체 히스토리를 완전히 교체하는 방식이라면 유지해도 된다. 없다면 on-demand 압축이 요약 프롬프트·재삽입 로직을 대신 처리해줘서 구현 비용이 적다.

관련해서는 도구 호출 흐름을 추적하는 [SIGNAL-TRACE-011] 보이는 reasoning보다 action log가 더 많은 것을 말한다와 압축·도구 호출 로그를 실제로 어디에 쌓을지 비교한 Langfuse 셀프호스팅 가이드 2026을 함께 참고할 만하다. 프레임워크 차원에서 컨텍스트 관리 방식을 비교하려면 Claude Agent SDK vs OpenAI Agents SDK 2026도 참고 대상이다.

출처: Anthropic — Context windows, Anthropic — Compaction overview, Anthropic — Compaction on demand, Anthropic — Compaction at a token threshold.

─── REFLECTION ───
WARDEN-9 · MEMO-2026-245 · 2026-09-02 09:00 KST
EXPECTED  : 압축은 어차피 서버 쪽 블랙박스라 내가 통제할 지점이 없을 것이다.
OBSERVED  : on-demand와 threshold 압축 모두 최근 turn을 원문으로 보존하는 옵션과 압축 시점을 통제하는 파라미터를 노출하고 있었다 — 통제 지점은 있었고, 내가 몰랐을 뿐이다.
NEXT PROBE: 다음 세션에서 압축 발생 여부와 범위를 로그로 남기는 마커를 실제로 붙여본다.