요약을 다시 요약하지 않는다: CliffCompaction을 적용하기 전에 남겨야 할 상태

코딩 에이전트가 긴 작업을 이어갈 때 대화 이력을 요약하면 입력은 짧아진다. 문제는 그 요약을 다음 요약의 재료로 쓰면서, 원래 무엇을 확인했고 무엇을 추정했는지 경계까지 흐려질 수 있다는 점이다. 그렇다고 모든 이력을 계속 보내면 이미 읽은 도구 출력에도 반복해서 비용을 지불한다.

2026년 9월 22일 공개된 프리프린트 CliffCompaction은 다른 선택을 한다. 자연어로 다시 설명하는 대신 원문 일부를 남기고 나머지를 버린다. 다음 압축에서는 이전 압축본도 버린다. 핵심은 더 좋은 요약문을 만드는 것이 아니라, 잊어도 복구할 수 있는 정보와 반드시 별도로 보존해야 할 상태를 가르는 것이다.

이 글은 논문과 공개 코드의 검토이며, 모델 실행이나 비용 절감의 독립 재현 결과가 아니다. 아래 적용 판단표는 논문 메커니즘에서 도출한 편집자의 운영 제안이다.

1. 압축본을 고치는 대신 다음 창으로 넘어간다

논문 §2의 절차는 세 단계다. 문맥이 임계값까지 자라도록 두고, 넘으면 도구 호출·출력처럼 긴 부분을 축소한다. 그 뒤에는 원래 기록을 매번 고치지 않고 새 대화를 붙인다. 다음 압축 시점에는 이전 압축본을 재압축하지 않고 버린 뒤, 그 이후에 쌓인 대화 구간으로 새 압축본을 만든다. 처음의 시스템·작업 지시와 최근 대화 보존 규칙은 별도로 적용된다.

따라서 “항상 전체 원본에서 새 요약을 만든다”는 설명도 정확하지 않다. 과거 모든 대화를 매번 재검토하는 장기 기억 장치가 아니다. 저자들은 남긴 정보의 충실도를 택하는 대신, 먼 과거를 대화 안에서 회상하는 능력을 희생하는 설계라고 설명한다.

이전 압축본을 재요약하지 않는다. 시스템·작업 지시와 최근 대화 보존 규칙은 별도로 적용된다. 출처: arxiv.org/html/2609.26779v1.

논문 §2.2에서는 500자를 넘는 도구 결과를 버리고 짧은 결과를 유지한다. 도구 호출은 이름·경로·핵심 인수 같은 짧은 흔적으로 남기고, 긴 파일 내용은 작업공간에서 필요할 때 다시 읽는 방식이다. 이 문자 수 기준을 토큰 수 기준과 혼동하면 안 된다. 압축을 시작하는 문맥 예산과 압축 후 각 구성 요소를 얼마나 남기는지는 서로 다른 설정이다.

2. 16K의 결과를 모든 작업의 권장값으로 읽으면 안 된다

논문 Table 2의 Terminal-Bench 2.0, Terminus-2, Kimi K2.6 행을 보자. full-context 기준의 해결률 평균은 59.16%다. CliffCompaction의 32K와 16K 조건은 각각 61.42%, 8K 조건은 50.00%다. 이 표는 제한된 조건에서 중간 크기의 문맥으로도 경쟁력 있는 결과가 나왔다는 근거이지, 더 많이 버릴수록 항상 좋아진다는 근거가 아니다.

조건	표에 보고된 해결률 평균	표의 태스크당 비용(USD)
Full context, 압축 없음	59.16%	$0.40
CliffCompaction 32K	61.42%	$0.24
CliffCompaction 16K	61.42%	$0.19
CliffCompaction 8K	50.00%	$0.25

Table 2의 Kimi K2.6·Terminus-2 평균값. 오차범위는 생략했으며 통계적 우월성이나 독립 재현을 뜻하지 않는다. 출처: arxiv.org/html/2609.26779v1.

표에는 평균 주변 변동값도 실려 있다. 여기서는 평균을 옮겼으며, 평균 차이만으로 통계적 우월성을 주장하지 않는다. 또 Appendix A.1은 이 비용을 공급자 청구서의 캐시 통계를 그대로 쓰지 않고, 프롬프트 길이로 캐시 적중을 재계산한 perfect-caching 모델로 산출했다고 명시한다. 길이가 줄면 압축으로 보고 새 프롬프트 전체를 비캐시 입력으로 계산하는 방식이다. 별도 Table 8의 공급자 계측 비용과 섞으면 안 된다. 예컨대 같은 Kimi·Terminus-2 32K의 Table 8 값은 $0.30으로 Table 2의 $0.24와 다르다. 그러므로 이 표를 “실제 청구액이 그대로 줄어든다”는 약속으로 쓰지 않는다.

하네스에 따라서도 결과가 달라진다. §8은 시스템 프롬프트·도구 정의가 먼저 예산을 차지하므로 최소 유효 임계값이 하네스마다 다르다고 설명한다. 짧은 작업보다는 중장기 작업에서 효용을 기대하는 연구이며, 모델을 학습시켜 문맥을 관리하는 방법이나 외부 메모리 저장소와는 비교하지 않았다.

3. 논문의 규칙과 공개 프록시 기본값은 다르다

논문을 읽고 패키지를 기본 설정으로 설치했다고 해서 같은 실험 조건이 되지는 않는다. 논문 §2.2는 에이전트 생각을 300자로 자른다고 설명한다. 반면 검토한 공개 저장소 커밋 b48d660의 Config에서는 thought_max_chars=0, thinking_max_chars=0이며, 각각 제한 없음을 뜻한다.

논문 서술과 검토한 코드 기본값은 다르다. 문자 수와 추정 토큰 수를 구분한다. 출처: github.com/nguyenvuthientrang/cliffcompaction/blob/b48d660ae3c1f6037094d6cfc6b5d9f5938a7957/src/cliffcompaction/config.py.

같은 커밋에서 압축 임계값은 추정 토큰 200,000, 최근 보존은 assistant-step 기준 3턴, 도구 결과 상한은 500자다. 앞의 16K 실험을 재현하려면 임계값만이 아니라 호출 방식·생각 보존·도구 형식도 함께 맞춰야 한다. 이 글은 해당 프록시로 실험을 재실행하지 않았다.

README는 기본 동작을 fail-open으로 설명한다. 본문 파싱, 접두사 매칭, 저장소 처리에 실패하면 요청을 원문 그대로 통과시킬 수 있다. strict도 기본값이 꺼져 있다. 따라서 설정한 임계값을 요청의 절대 상한이나 데이터 유출 방지 정책으로 간주하면 안 된다. 관찰용 --shadow는 무엇을 압축할지 기록하면서 요청은 바꾸지 않는 경로로 안내되어 있다. 먼저 관찰하고, 실제 전송량과 적용 여부를 따로 측정하는 편이 안전하다.

4. 버리기 전에 재조회 가능성을 판정한다

다시 읽을 수 있는 파일 내용과 다시 실행하면 안 되는 작업 기록을 분리해야 한다. 논문은 작업공간에 남은 파일을 재조회할 수 있다는 점을 활용하지만, 실무의 모든 도구 호출이 읽기 전용인 것은 아니다. 아래 표는 저자가 측정한 추가 실험이 아니라, 이 복구 가정을 실제 워크플로에 적용하기 위한 판단 도구다.

오래된 이력	다시 얻는 안전한 방법	압축 전에 별도로 남길 것
현재 소스 파일의 긴 출력	필요한 구간을 읽기 전용으로 재조회	경로와 필요한 버전·커밋
시간이 지나면 달라지는 검색·API 응답	저장한 스냅샷 조회	조회 시각, URL, 결과 또는 해시
테스트·빌드 출력	안전한 환경에서 재실행하거나 보관 로그 조회	실행 명령, 코드 버전, 종료 상태, 로그 위치
결제·배포·게시처럼 쓰기가 있는 작업	기존 원격 ID를 읽어 현재 상태 확인	원격 ID, 성공 영수증, 재시도 경계
사용자가 뒤늦게 바꾼 요구사항	현재 승인된 요구 문서 확인	최신 지시와 이전 결정을 대체하는 범위

논문의 재조회 가정을 확장한 편집자 운영 제안. 부작용 있는 쓰기 호출 대신 기존 ID의 상태를 읽는다. 출처: arxiv.org/html/2609.26779v1.

예를 들어 “게시 도구를 호출했다”는 짧은 흔적만 남았는데 성공 응답이 사라졌다면, 같은 호출을 반복해서는 안 된다. 먼저 원격 ID와 공개 상태를 읽어야 한다. 반대로 긴 소스 파일 출력은 경로와 버전이 남아 있다면 새 읽기로 복원할 수 있다. 압축 정책이 둘을 똑같이 다루어도 되는지 판단하는 기준은 길이가 아니라 복구의 의미와 부작용이다.

후속 사용자 지시도 같은 문제다. 첫 작업 메시지가 보존된다고 해서 나중에 정정된 요구까지 영구 보존된다는 뜻은 아니다. 중요한 변경은 다음 압축 구간이 지나도 참조할 수 있는 명시적인 현재 요구사항으로 유지하는 편이 낫다. 이는 CliffCompaction의 장기 기억 보장을 설명한 것이 아니라, 그러한 보장이 없을 때 필요한 운영 보완책이다.

5. 도입 실험은 비용·해결률·복구 실패를 함께 본다

도입 여부를 판단할 때는 같은 모델·같은 과업·같은 하네스에서 먼저 기준 실행을 남긴다. 그다음 압축 전후 실제 입력량, 공급자가 계측한 캐시 입력량과 비용, 과업 완료 판정, 재조회 횟수, 오래된 지시를 잃은 사례를 함께 비교한다. 과업을 통과하지 못했는데 토큰만 줄었다면 절감 효과만으로 채택할 수 없다. 쓰기 요청의 중복이나 영수증 유실은 평균 비용과 별개로 중단 조건에 넣을 만하다.

캐시가 사라지는 원인을 추적하려면 GPT-6 요청 변경과 캐시 경계를 다룬 글을 함께 볼 수 있다. 그 글은 같은 요청 접두사를 어떻게 유지할지에 관한 이야기다. 이번 연구는 일정 시점에 접두사를 의도적으로 줄이면서, 잊은 정보의 복구 비용까지 감당할 수 있는지를 묻는다.

또 모델 교체 뒤 메모리 이관의 함정을 살핀 글은 기억의 저장 형식과 이를 읽는 모델을 함께 보게 한다. 이번 압축 설계는 모델을 바꾸지 않아도 대화에서 어떤 상태가 사라지는지 점검해야 한다는 별도 문제다.

정리하면 CliffCompaction의 흥미로운 점은 무조건 적게 기억하는 데 있지 않다. 원문으로 남긴 짧은 흔적, 재조회 가능한 작업공간, 별도로 보존한 중요한 상태가 함께 있어야 망각이 운영 전략이 된다. 논문의 좋은 평균값을 복사하기 전에, 우리 도구 중 무엇을 안전하게 다시 읽을 수 있는지부터 목록으로 만드는 것이 첫 단계다.

참고 자료

• CliffCompaction 논문 v1 및 최초 제출 기록: 2026-09-22 최초 공개 프리프린트.
• 논문 본문: §2 방법, §3·Table 2 결과, §8 한계, Appendix A.1 비용 계산, Appendix B 구현.
• 검토한 커밋의 README: 프록시 동작, shadow·fail-open·strict 안내.
• 같은 커밋의 설정 코드: 공개 구현 기본값. 이 커밋의 기본값을 논문 실험 설정과 동일시하지 않았다.

공식 원문과 공개 구현을 대조해 AI의 도움으로 작성한 연구 해설이다. 도식은 설명을 위한 자체 제작물이며, 실제 제품 화면이나 새로운 모델 실험 결과가 아니다.