32k에서 35.7%p, 128k에서 2.7%p — 압축 기계를 만들기 전에 셀 것

컨텍스트 압축 로직을 직접 만들 생각이라면, 코드를 짜기 전에 숫자 하나를 봐야 한다. 압축을 쓴 쪽과 안 쓴 쪽의 성공률 차이가 32k 창에서 35.7%p, 128k 창에서 2.7%p다.

같은 기능인데 창 크기에 따라 13배 넘게 갈린다. 압축이 하는 일은 에이전트를 똑똑하게 만드는 게 아니라 컨텍스트를 넘겨 죽는 걸 막는 것이고, 창이 넉넉하면 막을 게 없기 때문이다.

출처: An Empirical Study of Harness Design for Coding Agents (arXiv 2609.20804, 2026-09-17)

확인된 것

논문 초록과 본문에서 확인한 수치만 적는다.

176개 대응 설정, 모델 4개, 벤치마크 2개(SWE-Bench Verified, Terminal-Bench 2.1). 컨텍스트 관리 전략 5종 × 컨텍스트 예산 4종 + 계획·행동공간 절제 실험. 43쪽.
컨텍스트 관리 전략 다섯 단계의 정의가 명확하다. T0은 압축 없음(넘치면 종료), T1은 오래된 도구 관찰을 생략, T2는 T1에 외부 저장과 recall_event를 더해 복구 가능하게, T3은 생략 없이 LLM 요약만, T4는 생략을 먼저 하고 필요할 때 요약하는 단계형.
관리 전략과 T0의 성공률 격차가 창 크기에 따라 줄어든다.

from 35.7 to 15.9, 5.5, and 2.7 percentage points on SWE-Bench

각각 32k / 64k / 96k / 128k다.
복구 기능은 값을 거의 못 했다. 생략한 내용을 다시 불러오는 경로가 실제로는 드물게 쓰였고, 일관된 정확도 향상도 없었다. 가장 좋은 비용 효율은 T4(생략 먼저, 요약은 나중)였다.
계획 단계의 효과가 모델 체급에 따라 뒤집힌다.

Planning increases success rate by 11.6 percentage points on SWE-Bench and 4.5 points on Terminal-Bench, at higher cost on both benchmarks.

이건 Nemotron-3 30B 기준이다. 반대로 Nemotron-3 550B와 Mistral-Medium-3.5-128B에서는 계획이 비용을 각각 약 30%, 32% 줄이고 성공률은 소폭 내려간다.
행동 인터페이스도 같은 방향으로 갈린다. 30B에서는 사전 정의 도구 세트가 성공률을 SWE-Bench 15.0%, Terminal-Bench 10.1% 올린다. 가장 센 모델에서는 반대다.

Bash-only improves success rate by 3.6% on SWE-Bench and 5.6% on Terminal-Bench while reducing cost by 53% and 30%, respectively.

판단

1. 압축은 성능 장치가 아니라 완주 장치다

35.7%p는 큰 숫자로 보이지만 그건 32k에서다. 128k에서 2.7%p는 측정 잡음과 구분하기 어려운 영역이다. 이 분포가 말하는 건 하나다 — 압축이 실제로 하는 일은 컨텍스트 초과로 인한 조기 종료를 막는 것이고, 창이 넉넉하면 애초에 막을 사고가 없다.

그래서 순서를 뒤집어야 한다. 컴팩션 로직을 짜기 전에 내 에이전트가 실제로 컨텍스트 초과로 죽는 비율부터 세라. 로그에서 셀 수 있는 숫자다. 0에 가까우면 그 코드는 만들 필요가 없고, 만들면 유지보수만 늘어난다.

어제 쓴 하네스 비용 글과 방향이 반대인 것처럼 보일 수 있는데 아니다. 거기서 다룬 건 비용(초기 컨텍스트가 무거우면 매 턴 값을 치른다)이고, 여기는 완주(창을 넘기면 죽는다)다. 짐이 무거운 것과 창을 넘기는 것은 다른 문제이고 처방도 다르다.

2. "혹시 필요할까 봐" 만든 복구 경로는 모델이 잊는다

T2는 생략한 관찰을 다시 불러올 수 있게 만든 전략이다. 직관적으로는 T1보다 안전하다. 실제로는 그 복구 호출이 드물게 쓰였고 정확도도 일관되게 오르지 않았다.

이건 컨텍스트 관리에 한정된 얘기가 아니라 에이전트 설계에서 반복되는 함정이다. 안전망 삼아 도구를 하나 더 붙여두면, 모델은 그 도구의 존재를 대체로 잊는다. 그리고 잊힌 도구도 스키마는 매 턴 실려 나간다.

→ 규칙: 에이전트에 붙인 도구가 로그에서 실제로 몇 번 불렸는지 세라. 호출 0에 가까운 도구는 보험이 아니라 매 턴 내는 고정비다. 지우는 게 맞다.

3. 계획 단계를 넣는 이유가 모델 체급에 따라 반대가 된다

이 논문에서 가장 실무적인 발견이다. 작은 모델에서 계획은 정확도 장치다 — 11.6%p 올리고 비용은 는다. 큰 모델에서는 비용 장치다 — 30% 안팎 아끼고 정확도는 조금 내려간다.

같은 기능이 정반대 이유로 정당화된다는 뜻이고, 여기서 따라 나오는 결론이 있다. "에이전트에게 먼저 계획을 세우게 하면 결과가 좋아진다"는 조언은 모델을 명시하지 않으면 틀린 조언이다. 강한 모델에서는 정확도가 오히려 조금 떨어진다.

그런데 실무에서는 대개 계획 단계를 한 번 넣고 다시 안 건드린다. 모델은 몇 달마다 바꾸면서. → 실행: 모델을 올렸으면 계획 단계의 존재 이유도 다시 쓰라. 정확도 때문에 넣었는데 지금은 비용 때문에 유지되는 중일 수 있고, 그러면 평가 기준이 달라야 한다.

4. 도구를 줄이는 것이 업그레이드일 수 있다

가장 센 모델에서 bash 전용 인터페이스가 성공률을 올리면서 비용을 53%, 30% 줄였다. 반대로 작은 모델에서는 사전 정의 도구가 성공률을 두 자릿수로 올렸다.

내 해석은 이렇다. 사전 정의 도구는 셸을 잘 못 쓰는 모델을 위한 보조바퀴다. 셸에 능한 모델은 여러 작업을 한 호출에 묶어버리는데, 도구로 잘게 쪼개두면 그 묶기를 구조적으로 막는 셈이 된다. 안전해 보이는 설계가 호출 수를 늘린다.

→ 실행: 모델을 올렸다면 도구 목록을 줄이는 방향으로 A/B를 해봐라. 보통은 늘리는 쪽만 시도한다. 이 논문은 반대 방향에 절반 가까운 비용 여지가 있다고 말한다. 물론 도구를 걷어내면 권한 통제는 따로 설계해야 한다 — bash 전용은 곧 뭐든 실행 가능하다는 뜻이다. 그 얘기는 논문 범위 밖이다.

모르는 것

43쪽 논문 전문을 읽지 않았다. 초록과 본문에서 위 수치가 담긴 문장들을 확인했을 뿐이다.
성공률 표기가 원문에서 percentage points와 %로 섞여 있다. 15.0%·3.6% 같은 수치가 절대 포인트인지 상대 증가인지 단정하지 못했다. 표를 봐야 한다. 그래서 이 글에서는 원문 표기를 그대로 옮겼다.
테스트된 모델 4개의 전체 목록을 확인하지 못했다. 본문에서 확인된 건 Nemotron-3 30B, Nemotron-3 550B, Mistral-Medium-3.5-128B다.
코드와 트레이스 공개 여부를 확인하지 못했다.
비용 계산의 가격 기준 시점을 확인하지 못했다.
벤치마크 두 종 한정이라는 한계는 어제 글에서 본 것과 같다. 내 실제 작업 분포와 다르면 그대로 옮길 수 없다.