AutoCompact가 코딩 에이전트의 컨텍스트 압축 시점을 학습한다

무엇인가

저장소 수준 소프트웨어 엔지니어링 과제를 푸는 코딩 에이전트는 코드 탐색, 검색, 편집, 테스트를 오래 반복한다. 진행될수록 초반의 탐색 가설, 실패한 시도, 장황한 도구 출력은 낡은 정보가 되지만 컨텍스트에는 계속 쌓인다. 이 논문은 컨텍스트 관리를 단순한 오버플로 회피가 아니라 세 가지 결정의 문제로 규정한다. 언제 압축할지, 압축된 작업 상태에 무엇을 남길지, 그 상태에서 어떻게 실행을 이어갈지다. 기존의 길이 기반 압축은 남은 예산이 임계값 아래로 떨어질 때만 압축하므로 과제 진행도와 무관하게 낡은 탐색이 쌓이고, 아직 증거가 필요한 단계 한가운데서 압축이 일어날 수 있다. 추론 시점 루브릭이나 오프라인 삽입 방식의 사전 압축도 시점만 다룰 뿐 작업 상태의 정확성과 압축 이후 행동을 감독하지 않는다.

어떻게 동작하나

AutoCompact는 에이전트에 compact() 액션을 부여하고 이를 정책의 일부로 학습한다. 에이전트는 현재 단계가 충분히 정리됐다고 판단하면 컨텍스트 한계에 도달하기 전에 스스로 compact()를 호출한다. 압축은 이전 상호작용 이력을 모델이 생성한 작업 상태 요약으로 대체하고, 원래 과제는 그대로 유지한다. 요약은 확정된 발견, 관련 코드와 워크스페이스 상태, 남은 행동을 보존하고 불필요한 탐색 세부는 버리는 것을 목표로 한다.

무엇과 다른가

훈련 데이터 수집이 이 논문의 핵심 장치다. 베이스 모델은 프롬프트로 압축 규칙을 알려줘도 컨텍스트 한계 전에는 좀처럼 compact()를 호출하지 않았다. 그래서 베이스 정책을 굴린 뒤 판정자(judge)가 매 제안 행동을 검토하고 세 종류의 교정을 수행한다. 트리거 교정은 지금이 압축 적기인지 판단하고, 작업 상태 교정은 생성된 요약이 이후 실행에 필요한 결론·코드·워크스페이스 상태·남은 행동을 정확히 담았는지 확인하며, 연속성 교정은 압축 직후 행동이 요약을 따르는지(이미 기록된 검색을 다시 돌리거나 다음 단계를 무시하지 않는지)를 본다. 교정은 실행 전에 적용되어 환경이 원본 대신 교정본을 실행하고, 정책은 교정된 이력에서 다음 행동을 생성한다. 사후 주석과 달리 교정이 이후 상태를 바꾼다. 이렇게 모은 궤적으로 표준 다음 토큰 예측 목적의 지도 미세조정(SFT)을 수행해 AutoCompact-SFT를 얻고, 이어서 SWE-Gym에서 GRPO 기반 종단간 멀티턴 강화학습을 적용한다. 보상은 최종 패치가 테스트를 통과했는지에 따른 이진 결과 보상 하나뿐이며, 압축 전용 보상 설계나 보조 목적은 쓰지 않는다. compact() 호출이 컨텍스트 접두사를 다시 쓰기 때문에 궤적은 접두사가 재작성되는 지점마다 분할되고, 한 궤적의 모든 분절이 같은 어드밴티지를 공유해 압축 결정·요약·압축 후 행동이 동일한 결과 신호를 받는다. 정책 손실은 배치 내 모든 분절에 대해 토큰 단위로 평균하며 KL 페널티와 엔트로피 보너스는 쓰지 않는다.

어떻게 쓰나

실험은 Qwen3-Coder-30B-A3B-Instruct를 베이스로, 동일한 터미널 REPL 스캐폴드에 compact()를 추가해 진행했다. 데이터 수집용 판정자로는 GPT-5.5-Codex를 썼고 평가 시에는 제거한다. SFT 데이터는 SWE-rebench 379개 과제에서 판정자 교정 궤적 1,052개를 모았으며, 그중 24%가 압축 트리거, 53%가 작업 상태 구성, 23%가 압축 후 연속성을 감독한다. SFT는 학습률 5×10⁻⁷, 배치 8로 2에포크, RL은 학습률 1×10⁻⁶, 배치 64, 롤아웃당 50 환경 스텝과 32K 토큰 제한으로 수행했다. 결과적으로 SWE-bench Verified에서 39.6%, SWE-PolyBench Verified에서 24.5% 통과율을 기록해 베이스 대비 각각 9.2%p, 5.0%p 개선했다. 길이 트리거 방식인 Fixed Compaction은 베이스보다 오히려 1.6%p, 0.9%p 낮았고, CompactionRL은 Fixed Compaction 대비 3.9%p, 1.2%p 올렸지만 AutoCompact와의 격차는 컸다. 같은 베이스와 스캐폴드, 비슷한 규모의 훈련 데이터를 쓴 SWE-Compressor보다 AutoCompact-SFT가 1.2%p, 1.6%p 높았고, 결과 기반 RL이 SFT 위에 추가로 7.4%p, 2.8%p를 더했다.

전제와 한계

분석은 압축이 컨텍스트 오버플로 이전에도 이득이라는 점을 보인다. 어떤 궤적도 강제 압축 임계값에 닿지 않는 256K 설정에서 AutoCompact-SFT가 모든 추론 예산 구간에서 베이스를 앞섰다. 같은 256K 조건에서 AutoCompact는 모든 예산에서 SFT를 능가했고 저예산 구간에서 격차가 가장 컸다. 16K 강제 압축 폴백을 공유하는 조건에서도 AutoCompact가 모든 예산에서 베이스를 앞서, 과제 진행 기반 압축이 길이 기반 압축보다 효과적임을 시사한다. 학습된 체크포인트에서 compact() 호출을 건너뛴 Summary-ignored 변형과 비교하면 정상 실행의 통과율이 더 높았고, 그 이점은 0.10달러에서 19.9%, 4.00달러에서 1.9%로 예산이 빡빡할수록 컸다. 즉 이득의 일부는 학습된 파라미터가 아니라 실제로 압축을 실행하는 데서 나온다. 압축 사용률은 베이스가 거의 호출하지 않는 반면 SFT가 44.3% 과제에서 사용했고 RL이 58.5%로 늘렸으며, 핵심 상태 누락은 3.1%에서 0.2%로, 다음 행동 누락은 8.2%에서 2.2%로 줄었다. 사례 연구는 요약 자기일관성을 강조한다. SFT 요약은 미해결 구문 오류를 기록하고도 추가 조치 없이 마무리하자고 제안해 해당 실행이 SyntaxError로 실패했고, RL 후 요약은 구현 완료 상태에 맞춰 제출 전 검증을 제안해 테스트를 통과했다.

개발자 관점에서 이 논문은 컨텍스트 압축을 인프라 설정이 아니라 에이전트가 학습해야 할 행동으로 다룬다. 실무에서 긴 저장소 작업의 비용과 성공률을 좌우하는 것은 창 크기 자체보다 낡은 탐색을 언제 버리고 무엇을 남기느냐이며, 압축 요약이 기록한 상태와 다음 행동이 서로 모순되지 않는지가 실제 실패 지점이 된다는 것을 보여준다. 자체 에이전트 하네스를 운영한다면 압축 트리거를 길이 임계값에만 묶지 말고, 압축 후 첫 행동이 요약을 따르는지 감독하는 신호를 훈련에 넣는 것을 검토할 만하다. 다만 이 결과는 단일 스캐폴드와 특정 베이스 모델, 두 벤치마크에서 얻은 것이므로 자기 시스템에 그대로 옮겨진다고 가정해서는 안 된다.

저자들이 밝힌 한계는 명확하다. 자원 제약 때문에 RL 훈련은 32K 토큰 시퀀스로 수행되어 평가에 쓰는 256K 컨텍스트 창보다 짧다. 그럼에도 256K와 16K 양쪽 설정의 모든 예산 구간에서 이득이 유지되어 이 훈련 조건이 유용한 사전 압축을 학습하기에 충분했다고 주장한다. 또한 AutoCompact는 하나의 스캐폴드 안에서 연구된 모델-하네스 공동 설계이며, Codex나 Claude Code처럼 창 한계에 가까워지면 자동으로 압축하는 널리 쓰이는 하네스와 학습된 사전 압축을 결합하는 일은 향후 과제로 남긴다.