자동 압축(Autocompaction)은 메모리가 아니다

Long-context 에이전트들은 이미 요약을 수행하고 있습니다.

그것은 유용합니다.

하지만 그것은 메모리(Memory)가 아닙니다.

내장된 자동 압축(Autocompaction)은 Claude Code, Codex, Cursor, Windsurf 또는 다른 코딩 에이전트가 긴 세션(Session)을 버텨낼 수 있도록 도와줍니다. 하지만 팀 워크플로우(Workflow)에는 "채팅이 요약되었습니다"보다 더 엄격한 무언가가 필요합니다.

그것은 이식 가능한 운영 상태(Portable operational state)가 필요합니다.

이것은 제가 로컬 MCP 토큰 경제 스택(Token-economy stack)을 작업하면서 계속해서 되돌아오게 되는 차이점입니다. 압축(Compression)은 하나의 대화를 유지시키지만, 핸드오프(Handoff)는 워크스페이스(Workspace)를 지속하게 합니다.

자동 압축(Autocompaction)이 잘하는 것

자동 압축은 컨텍스트 윈도우(Context window)가 너무 가득 찼을 때 제품 세션의 가공되지 않은 컨텍스트(Raw context)를 줄이는 데 탁월합니다.

단일 채팅 내의 단일 에이전트에게는 그것만으로 충분할 수 있습니다:

광범위한 목표를 보존합니다.
이전 논의 내용을 압축합니다.
모델이 계속 작동하도록 유지합니다.
사용자가 처음부터 다시 시작해야 하는 상황을 방지합니다.

이것은 실질적인 가치입니다.

문제는 작업이 더 이상 단일 채팅에 머물지 않을 때 발생합니다.

실제 리포지토리(Repo)에서 동일한 작업은 Claude Code, Codex, Cursor, Windsurf, 원격 Mac Mini, MCP 도구, CI 게이트(CI gates), 그리고 인간의 검토 사이를 이동할 수 있습니다. 그 시점에서 서사적인 요약(Narrative summary)은 운영 계약(Operational contract)과 동일한 것이 아닙니다.

자동 압축(Autocompaction)이 보통 잃어버리는 것

가장 중요한 세부 사항들은 종종 요약하기에 가장 적합하지 않은 형태를 띱니다:

어떤 승인(Approvals)이 실제로 이루어졌는지;
어떤 파일이나 서비스가 접근 금지(Off-limits)인지;
어떤 정확한 값들이 변동(Drift)되어서는 안 되는지;
어떤 소스들이 신뢰할 수 있는지, 반신뢰할 수 있는지, 또는 신뢰할 수 없는지;
어떤 오류들이 이미 시도되었고 수정되었는지;
어떤 명령어가 통과되었는지;
어떤 체크(Checks)가 아직 보류 중인지;
다음 에이전트가 무엇을 다시 반복해서는 안 되는지.

이것들은 단순한 "컨텍스트(Context)"가 아닙니다.

이것들은 제어 평면 상태(Control-plane state)입니다.

만약 압축 과정에서 이 상태가 사라진다면, 다음 에이전트는 자신감 있게 말하면서도 이전 에이전트가 이미 해결했던 리스크를 조용히 다시 열어버릴 수 있습니다.

누락된 계층: 로컬 핸드오프 MCP (Local handoff MCP)

제가 원하는 메커니즘은 윈도우가 가득 차기 전에 구조화된 핸드오프(Structured handoff)를 작성하는 로컬 핸드오프 MCP입니다.

핵심은 더 보기 좋은 요약을 만드는 것이 아닙니다.

핵심은 다른 에이전트가 안전하게 사용할 수 있는 재개 계약(resume contract)을 만드는 것입니다.

최소한의 핸드오프(handoff)는 다음 사항들을 보존해야 합니다:

목표 및 완료 조건 (objective and done condition);
로드된 지침 및 제약 사항 (loaded instructions and constraints);
승인 상태 (approval state);
변경되어서는 안 되는 정확한 값 (exact values that must not change);
리스크 및 레드 플래그 (risks and red flags);
이미 수행된 작업 (actions already taken);
오류 및 수정 사항 (errors and fixes);
보류 중인 검증 (pending verification);
권장되는 다음 단계 (next recommended step);
다시 수행하지 말아야 할 것 (what not to redo).

해당 계약은 제품의 비공개 채팅 메모리 내부에만 머무는 것이 아니라, 워크스페이스(workspace)에 존재해야 합니다.

자동 압축(Autocompaction) vs 로컬 핸드오프(local handoff)

Comparison table showing that built-in autocompaction is usually one product session, late, narrative, product-specific, and opaque, while local handoff MCP is a shared workspace protocol with pre-scoring, operational state, cross-agent vocabulary, and measurable resume metrics

타이밍의 차이가 중요합니다.

자동 압축(Autocompaction)은 종종 컨텍스트 압박(context pressure)이 이미 높아진 후에 발생합니다. 핸드오프 프로토콜(handoff protocol)은 세션을 더 일찍 사전 점수화(pre-score)하여, 다음 전환 시 일반적인 요약이 필요한지, 레드 플래그 핸드오프(red-flag handoff)가 필요한지, 아니면 인간의 검토를 위한 강제 중단(hard stop)이 필요한지를 결정할 수 있습니다.

1M 컨텍스트 윈도우가 필요성을 없애지 못하는 이유

더 큰 컨텍스트 윈도우(context window)는 가치가 있습니다.

저도 원합니다. 저도 사용할 것입니다.

컨텍스트 윈도우가 커지면 압축이 필요해지기 전까지 에이전트가 더 많은 코드, 로그, 소스 자료 및 이전의 추론(reasoning)을 사용할 수 있게 해줍니다.

하지만 더 큰 윈도우는 대부분 실패 모드(failure mode)를 지연시킬 뿐입니다. 그것이 상태(state)를 자동으로 이식 가능하거나(portable), 신뢰할 수 있거나(trusted), 감사 가능하거나(auditable), 또는 제품 간에 공유 가능하게(shared) 만들어주지는 않습니다.

100만 토큰이라 할지라도 여전히 다음과 같은 것들을 포함할 수 있습니다:

만료된 승인 (stale approvals);
묻혀 있는 비밀 정보 (buried secrets);
모순된 지침 (contradictory instructions);
쓸모없어진 진단 결과 (obsolete diagnostics);
반복된 실패 시도 (repeated failed attempts);
라벨이 지정되지 않은 소스 신뢰도 (unlabeled source trust);
명확한 다음 단계의 부재 (no clear next step).

공간이 더 넓은 것이 더 나은 상태 관리(state management)와 동일한 것은 아닙니다.

단순한 핸드오프 계약

다음은 제가 에이전트들이 실제 전환 시점에 생성하기를 원하는 형태입니다:

## 목표 (Objective)
우리가 완료하려고 하는 것.

...

이것은 의도적으로 지루하게 작성되었습니다.

좋은 핸드오프는 영리할 필요가 없습니다. 오해하기 어렵게 만들어야 합니다.

우리가 측정할 수 있는 것

유용한 질문은 "요약이 보기 좋게 되었는가?"가 아닙니다.

유용한 질문은 다음 에이전트(Agent)가 낭비와 실수를 줄이면서 작업을 계속할 수 있는가 하는 점입니다.

저는 다음과 같은 항목들을 측정하겠습니다:

재개 성공률 (resume success): 새로운 에이전트가 핸드오프(Handoff) 정보만으로 다음 단계를 수행할 수 있는가?
재독률 (re-read rate): 이전 파일이나 이전 채팅 컨텍스트(Chat context)를 다시 열어야 하는 빈도가 얼마나 되는가?
토큰 추정치 (token estimate): 재개 과정에서 얼마나 많은 컨텍스트(Context)를 피할 수 있었는가?
유출률 (leak rate): 비밀 정보, 비공개 구현 세부 사항, 또는 접근 금지된 사실이 핸드오프에 포함되었는가?
승인 보존 (approval preservation): 재개된 에이전트가 올바른 권한 경계(Permission boundary)를 유지하고 있는가?
재작업률 (redo rate): 에이전트가 이미 완료된 작업을 반복했는가?

이 지점에서 MCP 토큰 경제(Token-economy) 관점이 실용적으로 변합니다. 핵심은 단순히 토큰을 줄이는 것이 아닙니다. 핵심은 안전하지 않거나 낭비적인 복구 루프(Recovery loops)를 줄이는 것입니다.

이것이 도움이 되는 경우

이 패턴은 다음과 같은 상황에서 유용합니다:

코딩 세션이 컨텍스트 압박(Context pressure)에 직면할 때;
작업이 Claude Code에서 Codex 또는 Cursor로 넘어갈 때;
로컬 에이전트가 원격 머신에 작업을 넘길 때;
백그라운드 MCP 워크플로우(Workflow)가 나중에 재개되어야 할 때;
작업이 라이브 배포(Live deploys), 자격 증명(Credentials), 출판물 또는 승인 사항을 다룰 때;
동일한 결함 유형(Defect class)이 이미 두 번 나타났을 때.

이러한 경우, "채팅이 스스로 요약할 것이다"라는 식의 프로세스만으로는 충분하지 않습니다.

실질적인 시사점

자동 압축(Autocompaction)을 사용하십시오.

더 큰 컨텍스트 윈도우(Context windows)를 사용할 수 있다면 사용하십시오.

하지만 그 어느 것도 메모리(Memory)와 혼동하지 마십시오.

에이전트 엔지니어링(Agentic engineering)을 위한 메모리는 단순히 말한 내용을 기억하는 것이 아닙니다. 그것은 다음 행위자가 안전하게 작업을 계속할 수 있도록 운영 상태(Operational state)를 보존하는 것입니다.

자동 압축은 채팅이 유지되도록 돕습니다.

핸드오프는 워크스페이스가 지속되도록 돕습니다.

출처

MCP stack token economy — 바이트 절약(byte saving), 캐시 친화성(cache-friendliness), 프롬프트 컨텍스트 경제성(prompt-context economics)의 이면에 있는 로컬 측정 프레임워크.
Agentic engineering for marketing teams — Claude Code, Codex, Cursor, Windsurf, n8n, MCP, 증명 루프(proof loops), 품질 게이트(quality gates)를 위한 공유 운영자 어휘.
AI agent failure loops — 레드 퍼스트 게이트(red-first gates), 맹목적 검증(blind validation), 거부된 사례(rejected examples), 실패 루프 제어(failure-loop control)의 이면에 있는 QA 및 중단 규칙(stop-rule) 노트.

전체 정전(canonical) 노트:

https://gregshevchenko.com/notes/autocompaction-is-not-memory/