컨텍스트 압축은 임계값이 아니라 판단의 문제다

긴 에이전트 궤적이 자신의 컨텍스트 한계에 도달하면, 스캐폴드는 지금까지 누적된 모든 내용을 간결한 노트 하나로 요약하고, 그렇게 만들어진 요약본은 절반쯤 진행된 증명의 한가운데에 떨어진다. 에이전트는 네 개의 보조정리 중 세 개를 이미 손에 쥐고 있었다. 그런데 이제 그에게 남은 것은 자신이 “어떤 증명을 진행 중이었다”고만 적힌 한 단락과, 처음부터 다시 발견해 내야 하는 네 개의 보조정리뿐이다. 이 압축이 실패한 이유는 요약의 내용이 형편없었기 때문이 아니다. 그것은 단지 잘못된 순간에 작동했기 때문에 실패한 것이다.

대부분의 코딩 에이전트는 고정된 트리거에 따라 컨텍스트를 압축한다. 누적된 토큰이 임계값을 넘으면 요약하고 계속 진행하는 식이다. 트리거는 숫자에 기반하지만, 압축의 비용은 구조적이다. 도출 과정의 한가운데에서 작동하면 모델이 이후에 다시 만들어내야 하는 부분 결과를 폐기하게 되는데, 이는 무언가를 잊기에 가장 비싼 순간이다. 2026년 6월에 나온 논문 Self-Compacting Language Model Agents는 모델이 직접 언제 그리고 어떻게 압축할지 결정해야 한다고 주장하며, 판단에 기반한 방식이 토큰 비용의 일부만으로 임계값 방식과 대등하거나 그것을 능가한다는 것을 보여준다.¹

이 결과는 내가 그동안 한낱 배관 작업 정도의 세부 사항으로 취급해 온 문제를 완전히 다시 생각하게 만든다. 컨텍스트 압축은 어떤 카운터에 맞춰 작동하는 단순한 메모리 관리 잡무가 아니다. 그것은 언제 잊어도 안전한지에 대한 하나의 판단이며, 그 판단을 내리기에는 한낱 토큰 예산보다 에이전트 자신이 훨씬 더 나은 위치에 있다.

한눈에 보기

• Claude Code를 포함한 에이전트 스캐폴드는 윈도우 한계에 가까워지면 컨텍스트를 압축한다. 트리거는 토큰 개수이기 때문에, 에이전트가 작업의 어느 지점에 있는지와 무관하게 작동한다.
• 도출 과정의 한가운데나 탐색의 한가운데에서 작동하는 것이 최악의 경우다. 요약은 모델이 비용을 들여 계산한 부분 결과를 버리고, 모델은 그것을 다시 계산해야 한다.
• Self-Compacting Language Model Agents(2026)는 모델이 호출할 수 있는 압축 도구와, 언제 작동시켜야 하는지(하위 작업이 해결되었거나 궤적이 수렴하고 있을 때) 그리고 언제 멈춰야 하는지(도출 과정의 한가운데이거나 막혀 있을 때)를 알려주는 루브릭을 짝지운다. 둘 중 어느 한쪽만으로는 작동하지 않는다.
• 이 방법은 파인튜닝도 외부 감독도 필요로 하지 않는다. 여섯 개의 벤치마크와 일곱 개의 모델에 걸쳐, 요약을 하지 않는 기준선보다 수학에서 최대 18.1점, 에이전트 탐색에서 5~9점을 앞섰으며, 질문당 비용은 30~70% 더 낮았다.
• 이 교훈은 요약을 넘어 일반화된다. 무언가를 잊기 위한 올바른 트리거는 의미론적인 것이지(작업이 안전한 경계에 있는가?) 숫자적인 것이 아니다(버퍼가 가득 찼는가?).

임계값은 잘못된 트리거다

압축이라는 것이 존재하는 이유는 긴 궤적이 시간이 지나면서 썩어 들어가기 때문이다. 사고의 사슬과 도구 호출이 계속 쌓이고, 오래된 내용이 이후의 생성을 잘못된 방향으로 고정시키며, 결국 그 흔적 전체는 윈도우의 크기를 넘어서 버린다. 이에 대한 표준적인 해법은 토큰 총합이 임계값을 넘는 시점에 작동하도록, 일정한 간격을 두고 요약하는 것이다.¹ 이것은 누가 봐도 명백한 엔지니어링적 선택이며, 하나의 세션이 길게 이어질 때 프로덕션 스캐폴드가 실제로 하는 일이기도 하다. Claude Code는 그 자체 문서에 따르면 “한계에 가까워지면 자동으로 압축한다.”²

문제는 임계값이 컨텍스트의 크기는 알지만 그 형태에 대해서는 아무것도 모른다는 점이다. 토큰 카운터는 방금 하위 작업을 깔끔하게 마무리한 궤적과, 다섯 단계짜리 도출의 세 번째 단계에 들어선 궤적을 구별하지 못한다. 카운터에게는 둘 다 똑같아 보인다. 그저 선을 넘은 숫자일 뿐이다. 그래서 스캐폴드는 둘 다 똑같은 방식으로 압축하고, 두 번째 경우에는 에이전트가 작업을 끝내기 위해 필요로 하는 바로 그 중간 결과를 요약으로 날려버린다.

나는 내 자율 루프에서 바로 이런 일이 벌어지는 것을 직접 지켜봤다. 긴 실행이 여러 파일에 걸친 리팩토링을 하던 도중에 한계에 도달하면 스캐폴드가 압축을 수행하고, 그러면 에이전트는 자신이 이미 어떤 파일을 편집했는지조차 잊어버린 채로 돌아온다. 그 작업이 어떤 파국적인 의미에서 완전히 사라진 것은 아니다. 에이전트가 그것을 결국 다시 도출해 냈으니까. 하지만 그 재도출 자체가 바로 비용이며, 임계값은 자신이 작동한 그 순간이 나빴다는 사실을 볼 수 없기 때문에 이 비용을 맹목적으로 부과한다.

이 실패는 내가 컴파운딩 컨텍스트에서 다뤘던 실패와는 다르다. 컴파운딩은 프로젝트가 세션을 거치며 무엇을 유지하는가에 관한 것이다. 즉 500번째 세션을 1번째 세션보다 빠르게 만드는 관례, 훅, 메모리에 관한 것이다. 압축은 단일 세션이 그 안에서 무엇을 버리는가에 관한 것이다. 둘은 반대 방향으로 작용하며, 압축은 아무도 조율하지 않는 쪽이다. 임계값이 그것을 자동인 것처럼 느끼게 만들기 때문이다.

SelfCompact가 바꾸는 것

이 논문이 제안하는 SelfCompact는 결정을 스캐폴드에서 모델로 옮긴다. 이는 추론 시점의 두 가지 요소를 짝지운다.¹

압축 도구. 모델은 다른 도구를 호출하는 것과 똑같은 방식으로, 누적된 컨텍스트를 요약하기 위해 호출할 수 있는 도구를 갖게 된다. 압축은 런타임이 부과하는 인터럽트가 아니라 에이전트가 취하는 행동이 된다.

언제 작동시킬지에 대한 루브릭. 가벼운 지침이 모델에게 언제 압축이 적절한지(하위 작업이 해결되었거나 궤적이 수렴하고 있을 때) 그리고 언제 억제해야 하는지(모델이 도출 과정의 한가운데이거나 막혀 있을 때)를 알려준다. 이 루브릭이 바로 토큰 카운터에게 없는 판단이다.

이 논문은 두 절반이 모두 필요하다는 점을 분명히 하며, 그 이유가 흥미로운 부분이다. 오픈 웨이트 모델은 도구를 고르지 않게 사용한다. 도움이 되지 않는 순간에 호출하거나 아예 건너뛴다. 자기 본능에 맡겨두면 모델은 자신의 컨텍스트가 썩고 있다는 것을 알아차리는 데 신뢰할 만하지 못하다. 루브릭만으로는 아무것도 할 수 없다. 행동으로 옮길 메커니즘 없는 지침에 불과하기 때문이다. 둘이 합쳐지면 어떤 파인튜닝이나 외부 감독도 없이 적응적인 압축이 만들어진다.¹ 모델은 이미 요약을 잘하는 능력을 갖고 있다. 부족한 것은 언제 요약이 그 손실만큼의 가치가 있는지에 대한 메타인지적 감각이다. 루브릭이 그 감각을 제공한다.

이 틀이 중요한 이유는 사람들이 흔히 뒤섞어 생각하는 두 가지 능력을 분리하기 때문이다. 궤적을 어떻게 압축하는지 아는 것은 생성 능력이며, 프런티어 모델은 이를 잘한다. 언제 압축이 안전한지 아는 것은 자기 모니터링 능력이며, 모델은 별다른 지시 없이는 이를 못한다. SelfCompact는 모델을 요약에 더 능숙하게 만들려 하지 않는다. 모델이 그렇지 않았다면 틀렸을 타이밍 결정을 위한 체크리스트를 모델에게 준다.

수치

평가는 경쟁 수학과 에이전트 탐색에 걸친 여섯 개의 벤치마크를, 일곱 개의 모델에 대해 다룬다.¹ 비교 기준은 요약을 하지 않는 기준선과 고정 간격 임계값 방식이다.

요약을 하지 않는 경우와 비교하면, SelfCompact는 수학에서 최대 18.1점, 에이전트 탐색에서 5~9점만큼 결과를 개선했으며, 질문당 비용은 30~70% 더 낮았다.¹ 그 격차가 바로 컨텍스트가 썩는 비용이다. 자신의 오래된 흔적에 빠져 허우적대는 모델은 영리하게 가지치기하는 모델보다 측정 가능할 만큼 더 나쁜 결과를 내고, 비용도 더 많이 치른다.

고정 간격 요약과 비교하면, 핵심은 효율성이다. SelfCompact는 토큰 비용의 일부만으로 임계값 방식의 품질을 대등하게 따라잡거나 능가했다.¹ 시계가 아니라 판단에 따라 압축한다는 것은 에이전트가 더 드물게, 더 나은 순간에 압축한다는 뜻이고, 따라서 더 적은 요약 패스에 비용을 치르며 더 적은 폐기 결과를 재구성한다. 임계값은 가끔 타이밍이 어긋난 것이 아니었다. 같거나 더 나쁜 품질에 대해 체계적으로 더 비쌌다.

장기 과제에서 30~70%의 비용 절감은 반올림 오차가 아니다. 대량으로 에이전트를 운영하는 사람이라면 누구에게나 압축 정책은 하나의 비용 항목이며, 이 논문은 대부분의 스캐폴드가 기본으로 제공하는 정책이 필요하지도 않은 요약 패스에 비용을 치르고 있다고 말한다.

이것이 에이전트를 운영하는 사람들에게 의미하는 것

실용적인 교훈은 “지금 당장 SelfCompact를 구현하라”가 아니다. 대부분의 운영자는 자기 에이전트의 압축 트리거를 직접 통제하지 못한다. 교훈은 압축이 실제 품질과 비용에 영향을 미치는 조율 가능한 정책이며, 임계값이라는 기본값은 의심해 볼 만하다는 것이다.

압축 경계를 숫자가 아니라 의미론으로 다루세요. 긴 과제를 구성할 때는 에이전트에게 자연스러운 정지 지점을 주세요. 파일 하나를 끝내거나, 하위 작업을 마무리하거나, 체크포인트에 도달하는 것 말이다. 하위 작업 경계에서 압축하는 에이전트는 필요한 어떤 것도 잃지 않는다. 토큰 경계에서 압축하는 에이전트는 마침 손에 쥐고 있던 무엇이든 잃는다. 운영자의 일의 일부는 안전한 순간과 압축의 순간이 일치하도록 궤적을 빚어내는 것이다.

재도출을 증상으로 살펴보세요. 에이전트가 압축에서 돌아와 이미 끝낸 작업을 다시 한다면, 트리거가 잘못된 곳에서 작동한 것이다. 재도출은 타이밍이 어긋난 압축의 관찰 가능한 흔적이며, 눈여겨 찾으면 그 흔적 속에서 볼 수 있는 비용이다.

트리거가 모델 안으로 옮겨갈 것을 예상하세요. SelfCompact는 파인튜닝이 필요 없으며, 이는 어떤 스캐폴드든 채택할 수 있는 프롬프트와 도구 패턴이라는 뜻이다. 오픈 웨이트 모델에서 나온 깔끔한 결과는 이것이 기본값이 된다는 것을 시사한다. 즉 런타임이 강제하기를 기다리는 대신 스스로 압축을 결정하는 에이전트 말이다. 돌이켜보면 임계값은 컨텍스트를 관리할 작업 기억이 아니라 비워야 할 버퍼로 취급한 데서 비롯된 유물처럼 보일 것이다.

더 넓은 패턴은 내가 에이전트와 작업하며 계속 마주치는 것이다. 어려운 부분은 좀처럼 능력 자체가 아니다. 프런티어 모델은 궤적을 잘 요약할 수 있다. 어려운 부분은 메타인지다. 즉 이미 할 줄 아는 일을 언제 해야 하는지 아는 것이다. 압축 타이밍은 언제 확인을 요청할지 아는 것이나 언제 탐색 루프를 멈출지 아는 것과 마찬가지로 자기 모니터링 결정이며, 자기 모니터링은 지금 세대가 가장 약한 부분이다. 모든 경우에서 해법은 SelfCompact가 사용하는 것과 같은 형태다. 모델이 알아차리기를 바라는 것을 멈추고, 그 판단을 위한 명시적인 루브릭을 건네주는 것이다.

핵심 요점

에이전트 운영자를 위해: - 스캐폴드가 언제 압축하는지 점검하세요. 토큰 임계값에 따라 작동한다면, 에이전트가 작업 한가운데인지와 무관하게 작동하고 있는 것입니다. - 압축 경계가 임의의 순간이 아니라 안전한 순간에 떨어지도록, 긴 과제를 명시적인 체크포인트를 중심으로 구성하세요. - 압축 이후의 재도출을 모델의 별난 특성이 아니라 트리거의 버그로 다루세요.

스캐폴드를 만드는 사람을 위해: - 압축 도구에 작동/억제 루브릭을 더한 것은 파인튜닝이 전혀 필요 없이, 더 낮은 비용으로 고정 간격 방식을 능가합니다. - 두 능력을 분리하세요. 모델은 요약은 잘하지만 타이밍은 형편없이 판단합니다. 설계 노력을 요약기가 아니라 타이밍 루브릭에 쏟으세요.

에이전트 실행 예산을 짜는 사람을 위해: - 압축 정책은 비용 항목입니다. 판단에 기반한 트리거는 이 연구에서 동등하거나 더 나은 품질로 질문당 비용을 30~70% 줄였습니다.

자주 묻는 질문

컨텍스트 압축이란 무엇인가요?

컨텍스트 압축은 흔적이 모델의 컨텍스트 윈도우를 넘어서지 않도록, 에이전트가 누적한 궤적(사고의 사슬과 도구 호출)을 더 짧은 형태로 요약하는 것입니다. 공간을 얻기 위해 세부 사항을 맞바꾸는 것입니다. 잘 해내면 에이전트가 여전히 필요로 하는 것을 보존하면서 오래된 내용을 제거합니다. 잘못된 순간에 하면 에이전트가 다시 계산해야 하는 부분 결과를 폐기합니다.

왜 토큰 임계값은 나쁜 압축 트리거인가요?

토큰 임계값은 컨텍스트의 크기는 측정하지만 그 구조는 측정하지 못합니다. 에이전트가 방금 하위 작업을 끝냈는지, 아니면 도출의 절반쯤을 지나고 있는지 구별할 수 없습니다. 두 번째 경우에 작동하면 모델이 비용을 들여 계산한 중간 결과를 버려, 비싼 재도출을 강요합니다. 트리거는 에이전트가 작업의 어느 지점에 있는지를 반영해야 하지만, 카운터는 그것을 볼 수 없습니다.

SelfCompact는 언제 압축할지 어떻게 결정하나요?

모델이 호출할 수 있는 압축 도구와, 언제 작동시킬지(하위 작업이 해결되었거나 궤적이 수렴하고 있을 때) 그리고 언제 억제할지(도출 과정의 한가운데이거나 막혀 있을 때)를 명시하는 루브릭을 짝지웁니다. 모델은 이미 요약을 잘합니다. 루브릭은 별다른 지시 없이는 모델에게 없는 타이밍 판단을 제공합니다. 이 접근은 파인튜닝이나 외부 감독을 필요로 하지 않습니다.

이것은 특별한 모델이 필요한가요?

아니요. 이 논문은 오픈 웨이트 모델을 포함해 일곱 개의 모델을 평가했으며, 이 패턴은 프롬프트와 도구 사용만으로 작동합니다. 그래서 어떤 스캐폴드든 재훈련 없이 채택할 수 있습니다.

판단에 기반한 압축은 얼마나 절약하나요?

이 연구에서 SelfCompact는 질문당 30~70% 더 적게 쓰면서 고정 간격 요약을 대등하게 따라잡거나 능가했고, 요약을 하지 않는 기준선보다 수학에서 최대 18.1점, 에이전트 탐색에서 5~9점 앞섰습니다.

출처

• Tianjian Li, Jingyu Zhang, William Jurayj, Xi Wang, Chuanyang Jin, Mehrdad Farajtabar, Eric Nalisnick, Daniel Khashabi, “Self-Compacting Language Model Agents,” arXiv, 2026년 6월 22일: arxiv.org/abs/2606.23525
• Anthropic, “Explore the context window,” Claude Code 문서, 컨텍스트 한계 근처에서의 자동 압축에 관하여: code.claude.com/docs/en/context-window
• 자율 루프와 컨텍스트 관리에 관한 관련 프로덕션 경험: Ralph 에이전트 아키텍처, 컴파운딩 컨텍스트, 그리고 에이전트 운영자 핸드북