같은 일을 두 번 반복하고 있지는 않은가

Claude Code로 여러 세션을 진행하다가 문득 깨달은 점이 있다.

작업을 마칠 때, 필자의 환경에서는 중요한 결정을 외부 기억(external memory)에 저장하고, 세션 전체를 요약한 뒤 종료한다. 그 직후, 다음 작업을 준비하기 위해 /compact를 실행한다.

그때 '어라, 지금 완전히 똑같은 정보를 두 번 요약하고 있는 것 아닌가?'라는 생각이 들었다.

결론부터 말하자면, 자연스러운 구분점에서 외부 기억으로 퇴피(evacuation)할 수 있다면, /compact 대신 다음과 같은 흐름을 사용할 수 있다.

종료 처리 → /clear → 다음 세션 시작 시 recall

이렇게 하면 /compact의 장점인 문맥의 연속성(context continuity)을 유지하면서도, 컨텍스트 윈도우 (Context Window, 이하 컨텍스트 창)는 /clear를 통해 깨끗하게 비울 수 있다. 본고는 이 깨달음과 실측한 수지를 가볍게 정리한 것이다.

/compact가 실제로 하고 있는 일

/compact는 대화 이력을 그 자리에서 짧게 접고 끝내는 가벼운 처리가 아니다.

실체는 그 시점의 컨텍스트 전량을 입력으로 하는 플래그십 모델(flagship model)의 요약 호출이다. 200K의 컨텍스트 창이라면, auto-compact가 발화할 무렵에는 약 150~180k 토큰이 입력된다. 그리고 생성된 요약 블롭(summary blob)은 다음 창의 맨 앞에 선불로 고정 주입된다.

다음 창도 가득 차면 다시 같은 처리가 일어난다. 긴 세션을 지속할수록 이 '창의 대부분을 읽게 하여 요약하고, 다음 창으로 넘기는' 처리를 반복하게 된다.

물론 작업 도중의 세세한 상태까지 인계할 수 있다는 점은 강력하다. 반면, 생성물에는 다음과 같은 성질이 있다.

• 해당 세션을 넘나들며 재사용할 수 없다
• 나중에 검색할 수 없다
• 과거의 요약으로서 축적되지 않는다
• 압축 후의 창에서는 요약 블롭만큼 처음부터 공간을 차지한다

즉, /compact는 현재 창에 있는 기억을 다음 창에서도 사용할 수 있는 형태로 일시적으로 다시 채워 넣는 처리라고 볼 수 있다.

외부 기억이 있는 경우의 종료 처리

필자는 자작 외부 기억 MCP server인 「CPersona」를 사용하고 있다. 하지만 여기서 중요한 것은 제품 고유의 기능이 아니라, 기억을 컨텍스트 창 외부에 저장하고 검색할 수 있다는 패턴이다. 동일한 역할을 하는 메모리(memory) 계열 MCP server라면 기본적인 구조는 변하지 않는다.

필자의 환경에서는 다음 두 종류를 외부 DB에 남기고 있다.

• 중요한 결정이나 재사용하고 싶은 지식은 작업 중에 store로 수시 저장한다.
• 세션 종료 시에는 대화의 요점을 archive_episode로 에피소드로서 격납한다.

archive_episode에 전달할 summary와 keywords는 더 저렴한 서브 에이전트(sub-agent)인 Sonnet이 사전 계산하도록 하고 있다. 따라서 종료 처리 시 메인 모델에 의한 컨텍스트 전량 요약 호출은 발생하지 않는다.

이 상태에서 추가로 /compact를 하면, 이미 영속화(persistence)된 정보를 다시 한번 정리하게 된다. 게다가 두 번째 생성물은 휘발성(volatile)이며, 검색할 수 없고, 축적도 되지 않는다.

바꿔 말하면, 같은 정보의 두 번째 요약을 더 열화된 저장 형식으로 만들고 있는 것이다. 종료 경계를 만들 수 있는 상황이라면 이것은 거의 무의미한 것이 아닌가, 하는 것이 이번의 깨달음이다.

대체 시의 수지

종료 경계에서의 가변 부분만 나열하면 다음과 같다.

외부 기억으로 대체하는 일련의 과정은 store 몇 건, archive_episode, 차기 recall을 합쳐도 약 10k 토큰 이하였다. /compact 1회의 약 150180k 토큰에 비해 **1520분의 1** 수준이며, 오더(order)가 하나 다르다. 단순한 토큰 절감이 아니라 지출 구조의 교체이다.

4개월 치의 기억과 compact 6~7회가 같은 규모

다음은 추측치가 아니라, 필자가 약 4개월 동안 운용한 외부 기억 DB를 read-only로 집계한 실측치이다. 대상은 에이전트(agent) 1개 분량이다.

• memory: 1,251건, 평균 1,100자, 최대 2,472자. 1건당 약 1k 토큰급
• episode summary: 316건, 평균 1,447자, 최대 6,577자
• 전체 memory 코퍼스(corpus): 1,376,423자, 약 100만 토큰 전후

가장 흥미로운 점은 마지막 숫자이다. 4개월에 걸쳐 축적한 전체 memory 코퍼스가, 입력 토큰량으로 보면 /compact를 단 6~7회 실행하는 규모와 동등했다.

동일한 정도의 토큰량을 사용한다면, 단 한 번만 사용되고 휘발되는 요약 블롭(blob)이 아니라, 검색 가능하고 영구적이며 세션을 가로질러 유지되는 기억이 4개월 분량이나 남는다. 외부 기억이 토큰의 활용 용도로서 훨씬 더 합리적이다.

참고로, 가공되지 않은 트랜스크립트(transcript)인 .jsonl 파일은, 실측한 94개 세션에서 전형적으로 511MB, 최대 64MB였다. 다만 /compact의 실제 입력은 컨텍스트 창(context window)의 상한선에서 제한(cap)된다. 64MB라는 그럴싸한 숫자를 그대로 비교에 사용하면 과대광고가 될 수 있으므로, 본고에서는 창(window) 기반의 약 150180k 토큰을 기준으로 삼는다.

/compact를 대체할 수 있는 성립 조건

여기까지 읽으면 항상 /clear를 사용하는 것이 좋아 보인다. 하지만 이 대체에는 명확한 성립 조건이 있다.

자연스러운 구분이 필요함

대체가 가능한 경우는 종료 처리(termination process)를 실행할 수 있는 경계가 있을 때이다.

태스크(task)의 한복판에서 auto-compact가 발화(fire)할 경우, 직전에 읽은 파일, 작업 중인 중간 결과, 아직 확정되지 않은 추론 등은 외부 기억으로 옮겨지지 않은 상태이다. 여기서 /clear를 하면 작업 상태를 잃게 되므로, 단순하게 대체할 수는 없다.

따라서 긴 태스크 중 긴급 대피용으로서의 /compact는 지금도 의미가 있다. 목표로 삼아야 할 것은 태스크 완료 후나 방침이 확정된 후와 같이, 인간이 의도적으로 구분을 지을 수 있는 장면이다.

recall은 확률적임

/compact의 요약에는 품질이 저하되더라도 원래의 문맥 전체가 재료로서 포함되어 있다. 반면 recall은 쿼리(query)와 관련이 있다고 판단된 기억만을 가져온다. 필요한 정보가 매번 확실하게 돌아온다고 보장할 수 없다.

따라서 벡터 검색(vector search), 전체 텍스트 검색(full-text search), 키워드 등을 포함한 외부 기억 측의 검색 품질이 성립 조건이 된다. 단순히 저장하고 끝내는 것이 아니라, 다음 세션에서 적절하게 끌어낼 수 있어야 한다.

고정비는 제외하고 생각할 것

CLAUDE.md나 MCP schema와 같은 고정 정보는 /compact 이후에도, /clear 이후에도 재주입(re-inject)된다. 어느 쪽을 선택하든 다시 지불해야 하는 부분이므로, 비교상의 차이가 되지 않는다.

차이가 발생하는 지점은 과거의 대화를 통째로 요약할 것인지, 아니면 필요한 기억만을 검색해서 가져올 것인지라는 가변적인 부분이다. 앞서 제시한 비교표도 이 가변적인 부분의 수지(balance)로서 정리되어 있다.

시도해 보려면 — SKILL에 맡기기

본고의 워크플로우를 자신의 환경에서 시도하려면, 외부 기억 MCP server와 자연스러운 구분점에서 종료 처리를 실행하는 운용 규율(operational discipline)이 모두 필요하다. server를 도입하는 것만으로는 중요한 정보를 저장하는 것을 잊거나, /clear를 하기 전에 세션을 대피시키지 못할 수 있다. 메커니즘과 운용을 세트로 준비해야 비로소 「종료 처리 → /clear → recall」이 성립한다.

필자의 구성을 그대로 시도할 경우, CPersona에는 Agent Skill인 cpersona-memory가 동봉되어 있다. 이 SKILL은 인스톨러(installer)인 동시에 운용 규범이다. CPersona 본체의 설치, 임베딩 서버인 CEmbedding의 기동, MCP 등록, 동작 확인까지를 Claude 스스로가 실행한다.

그뿐만 아니라, 도입 후의 Claude에는 「중요한 결정은 즉시 store한다」, 「세션 종료 문구가 감지되면 archive_episode한다」라는 발화 조건도 포함된다. 이는 본고에서 서술해 온 종료 처리의 규율 그 자체이다. 즉, 본고가 전제로 한 「자연스러운 구분에서 종료 처리가 실행되는」 상태가 SKILL 도입만으로 재현된다.

전제 조건은 Python 3.11+와 uv 정도이다. 도입은 다음 명령어로 SKILL을 배치하는 것부터 시작한다.

# SKILL을 사용자 레벨의 skills 디렉토리에 배치
git clone --depth 1 https://github.com/Cloto-dev/cpersona.git /tmp/cpersona
mkdir -p ~/.claude/skills
...

그 후 Claude Code 세션에서 "CPersona를 설정해줘. 영구 기억(persistent memory)이 필요해."라고 말하기만 하면 된다.

수동 구성의 상세 내용이나 내부 메커니즘은 『Claude는 내일도 당신을 잊는다 — MCP Memory Server cpersona 설계와 실전』에 맡기겠다.

요약

외부 기억이 없다면, /compact는 긴 작업을 이어가기 위한 잘 만들어진 메커니즘이다. 하지만 중요 사항과 세션 요약이 이미 외부 DB에 있고, 다음 세션부터 검색할 수 있다면, 종료 직후의 /compact는 동일한 정보를 다시 한번 재사용하기 어려운 형태로 압축하는 처리가 된다.

자연스러운 구분 시점에는 다음 흐름만으로 충분하다.

store / archive_episode → /clear → recall

/compact는 기억이 컨텍스트 창 (context window) 안에만 존재하는 세계의 도구이다. 외부 기억을 가지고 구분(boundary)만 만들 수 있다면, /clear의 완전한 하위 호환이 된다.

필자가 사용 중인 외부 기억 서버 (external memory server)의 설계와 실전은 Zenn 책인 『Claude는 내일도 당신을 잊는다 — MCP Memory Server cpersona 설계와 실전』에 정리해 두었다. 외부 기억 자체의 구성에 관심이 있다면 참고가 될 것이다.

Discussion