176개 대조 실험, 컨텍스트 관리 효과 35.7→2.7점

컨텍스트 윈도우가 32k에서 128k로 늘어난 뒤, 동일한 컨텍스트 관리 전략이 SWE-Bench Verified에서 거두는 이익은 35.7퍼센트 포인트에서 2.7퍼센트 포인트로 떨어졌다 —— 무려 13배다.

이 논문의 가장 매서운 지점은 이 숫자 자체가 아니라, 저자가 그 원인까지 함께 제시했다는 것이다: 이 전략은 애초에 agent를 똑똑하게 만드는 게 아니었다. 그것은 그저 agent가 터져 죽지 않게 막고 있었을 뿐이다. 윈도우가 충분히 커져서 터져 죽지 않게 되면, 그것이 가져오는 이익은 0이 된다.

그래서 공학적으로 대단히 골치 아픈 결론이 하나 나온다: harness 설계 결정은 일회성 설계 문서가 아니라, 모델 업그레이드와 묶여 있는 유통기한을 가진다.

1. 이 실험이 왜 따로 다룰 가치가 있는가

Agent 공학에는 오랫동안 아무도 진지하게 하지 않은 일이 하나 있다: 우리는 harness(모델 바깥을 감싸는 그 층: 계획, 도구, 컨텍스트 관리)를 하나의 덩어리로 놓고 평가한다.

그 결과는 이렇다. benchmark 점수가 올라도, 그 공을 어느 설계 결정에 돌려야 할지 모른다. 점수가 떨어져도, 어느 줄을 고쳐야 할지 모른다. 대부분 팀의 방식은 오픈소스 harness 한 세트를 베껴 온 다음, 직감과 입소문에 의지해 위에 이것저것 얹는 것이다——계획 모듈 하나, 컨텍스트 압축 하나, 사전 정의 도구 십몇 개. 다 얹고 나면 점수는 변하는데, 무엇을 제대로 얹은 것인지는 아무도 모른다.

9월 17일 arXiv에 올라온 이 논문(arXiv:2609.20804, 43페이지)은 소박하지만 희귀한 일을 하나 했다: 실행 루프를 고정해 놓고, 세 컴포넌트만 변하게 한 다음, 완전 순열 대조를 수행했다.

``` 고정 불변 세 가지 변수 ┌──────────────────┐ ┌──────────────────────────────┐ │ 실행 루프 loop │ │ ① 계획 planning │ │ 최대 스텝 수 300 │ │ 켜기 / 끄기 │ │ 온도 0 / top-p 0.95 │ ├──────────────────────────────┤ │ 출력 상한 16,384 │ │ ② 행동 공간 action space │ │ 도구 결과 절단 24k │ │ 사전 정의 도구 / 순수 bash │ │ 소프트/하드 임계값 .6/.85 │ ├──────────────────────────────┤ │ 교착 5회 알림/8회 종료 │ │ ③ 컨텍스트 관리 context mgmt │ └──────────────────┘ │ T0 / T1 / T2 / T3 / T4 │ └──────────────────────────────┘ × 윈도우 예산 32k / 64k / 96k / 128k ```

규모는 이렇게 갖춰졌다:

| 차원 | 값 | 개수 | | --- | --- | --- | | 모델 | Nemotron-3 30B / 120B / 550B, Mistral-Medium-3.5-128B | 4 | | 벤치마크 | SWE-Bench Verified(500개 태스크), Terminal-Bench 2.1(89개 태스크) | 2 | | 설정 | 컨텍스트 관리 5단계 × 4가지 예산 + 계획/행동 공간 소거 | 22 | | 합계 | | 176개 매칭 설정 |

컨텍스트 관리의 다섯 단계는 이렇게 나뉜다:

| 단계 | 메커니즘 조합 | 설명 | | --- | --- | --- | | T0 | 없음 | 턴 사이 압축을 전혀 하지 않고, 윈도우를 넘기면 종료 | | T1 | 생략만 | 낡은 도구 관찰을 짧은 스텁으로 대체하고, 원본 내용은 버림 | | T2 | 생략 + 회수 | 생략한 내용을 외부에 저장하고, recall_event로 가져올 수 있음 | | T3 | 요약만 | 중간 영역을 롤링 요약으로 접고, 생략은 하지 않음 | | T4 | 세 가지 계층화 | 먼저 임계값 B1에서 생략하고, 그다음 임계값 B2에서 요약 |

이 표를 먼저 기억해 두자. 뒤의 모든 결론이 여기로 되돌아온다.

2. 그 13배의 감쇠 곡선

논문의 주 결과는 아주 직관적인 그림 하나다: 관리형 단계(T1–T4)와 무관리(T0)의 성공률 격차가, 윈도우 예산이 넓어질수록 붕괴한다.

| 윈도우 예산 | SWE-Bench Verified 이득 | Terminal-Bench 2.1 이득 | | --- | --- | --- | | 32k | 35.7 pp | 9.5 pp | | 64k | 15.9 pp | 7.5 pp | | 96k | 5.5 pp | 4.8 pp | | 128k | 2.7 pp | 2.8 pp |

두 벤치마크의 추세는 완전히 일치하지만, 폭은 한 자릿수만큼 차이가 난다——이 점은 뒤에서 설명한다.

만약 당신이 2024년에 컨텍스트 관리를 한 세트 만들어 두었다면(그때 32k는 사치스러운 사양이었다), 그것은 그 당시 당신 시스템에서 가장 값나가는 조각이었을 수 있다. 오늘날 윈도우가 보편적으로 128k부터 시작하는 상황에서, 같은 것은 2.7점의 가치가 있다.

이것은 "효과가 나빠졌다"가 아니라, "그것이 원래 사 주던 그 물건이 이제 무료가 되었다"는 것이다.

3. 왜 감쇠하는가: 그것은 똑똑해지는 게 아니라, 터져 죽는 걸 막는 것이다

저자의 설명에는 단단한 데이터가 뒷받침한다. 그들은 T0(컨텍스트 관리를 전혀 하지 않음)의 윈도우 오버플로율을 집계했다:

| 벤치마크 | 32k일 때 오버플로율 | 128k일 때 오버플로율 | | --- | --- | --- | | SWE-Bench Verified | 78.7% | 8.7% | | Terminal-Bench 2.1 | 61.0% | 12.1% |

다른 절반도 보자: 모든 관리형 단계(T1–T4)는 모든 예산에서 오버플로로 실패한 태스크 수가 정확히 0이다.

이 두 숫자 묶음을 나란히 놓으면 메커니즘이 명확해진다:

``` 32k 환경 128k 환경 ┌────────────────────────┐ ┌────────────────────────┐ │ T0: 78.7%의 태스크가 터져 죽음 │ │ T0: 8.7%의 태스크가 터져 죽음 │ │ T1–T4: 0개 태스크가 터져 죽음 │ │ T1–T4: 0개 태스크가 터져 죽음 │ │ │ │ │ │ 차이 35.7 pp │ │ 차이 2.7 pp │ │ ↑ 거의 전부가 "안 죽음"에서 │ │ ↑ "안 죽음"의 8.7%만 남음│ └────────────────────────┘ └────────────────────────┘ ```

거칠지만 쓸 만한 근사 하나로 곡선 전체를 이해할 수 있다:

컨텍스트 관리의 이익 ≈ 오버플로 실패율 × 개별 오버플로 태스크의 기대 손실

오버플로율이 78.7%에서 8.7%로 떨어지면, 이익도 원래의 약 1/9로 떨어져야 한다——실측은 1/13로 떨어졌으니 자릿수는 맞는다. 남은 그 2.7점은, 그 8.7%가 터져 죽는 것을 막은 잔여 가치다.

Terminal-Bench의 이득이 전반적으로 한 자릿수 낮은 것도 같은 공식으로 설명된다: 그 태스크들은 명령줄 위주여서 단일 턴의 컨텍스트 압박이 애초에 작고, T0의 32k에서의 오버플로율도 61%에 불과하며, 오버플로 후 손실되는 태스크 가치도 상대적으로 더 낮다.

이 절은 전문에서 가장 중요한 절이다. 왜냐하면 이것이 "컨텍스트 관리를 할 것인가"라는 질문을, "어느 전략이 더 고급인가"라는 미학적 판단에서, 직접 측정할 수 있는 공학적 판단으로 바꿔 놓기 때문이다——7절을 보라.

4. 세 개의 노브, 세 가지 전혀 다른 메커니즘

논문에서 가장 값나가는 부분은 궤적(trajectory) 층 분석이다. 저자는 점수에서 멈추지 않고, agent가 실제로 지나온 경로를 들여다보며 세 노브 각각의 작용 지점을 제시했다:

| 노브 | 그것이 바꾸는 것 | | --- | --- | | 컨텍스트 관리 | 궤적의 【길이】 | | | 더 오래 달리게 할 뿐, 다르게 달리게 하지는 않음 | | 계획 | 궤적의 【정지점】 | | | 어느 위치에서 손을 떼고 / 방향을 트는가 | | 행동 공간 | 코드 기록의 【입자 크기】 | | | 도구 조합을 쓰는가, 아니면 바로 bash를 쓰는가 |

이것은 내가 본 harness에 대한 가장 깔끔한 멘탈 모델이다. 왜냐하면 자주 뒤섞여 취급되는 세 가지를 서로 다른 세 가지 실패면으로 갈라 놓기 때문이다:

- 컨텍스트 관리 실패 → 태스크를 끝내지 못함(길이 문제)

- 계획 실패 → 태스크를 잘못된 곳에서 멈춤(정지점 문제: 막다른 길에서 허비하거나, 너무 일찍 손을 뗌)

- 행동 공간 실패 → 코드를 고칠 수 없음(입자 크기 문제: 도구 조합으로는 이 수정을 표현할 수 없음)

다음에 당신의 agent가 망가지면, 먼저 어느 면에서 망가졌는지 물어라. 이 세 면에 대응하는 수정법은 전혀 다르고, 섞어서 조정하면 서로를 가린다.

5. 네 가지 반직관적 실측 결론

5.1 회수 가능한 생략(T2)은 순부채다

많은 harness가 하는 일이 하나 있다: 생략한 내용을 외부에 저장하고, agent가 나중에 recall_event로 되가져올 수 있게 한다. 이유는 "만약 그때 필요하면 어쩌나"다.

실측 결과:

| 지표 | 값 | | --- | --- | | 64개 T2/T4 설정 중 recall_event를 한 번도 호출하지 않은 비율 | 36 / 64(56.3%) | | 평균 호출 횟수 @32k | 0.540회/태스크 | | 평균 호출 횟수 @64k | 0.069회/태스크 | | 평균 호출 횟수 @128k | 0.007회/태스크 | | 호출이 가장 빈번한 설정 조합(30B / Terminal-Bench / 32k / T2) | 4.326회/태스크, 그러나 정확도는 T1보다 3.37% 낮음 |

절반이 넘는 설정이 그것을 한 번도 쓰지 않았고, 가장 많이 쓴 조합은 오히려 회수를 하지 않는 버전보다 더 나빴다.

이 결과는 직관을 넘어선 또 한 층의 논리와 잘 맞는다: 회수 메커니즘이 존재하는 의미는 "agent가 자신에게 정보가 부족함을 인식하는 것"인데, 그것을 인식하지 못한다——그저 현재 컨텍스트에 있는 것에 따라 계속 나아갈 뿐이다. 당신은 그것이 누르지 않을 초인종을 달아 준 것이다.

5.2 계획은 강한 모델에게 "더 정확"이 아니라 "더 절약"이다

| 시나리오 | 계획을 켰을 때의 효과 | | --- | --- | | 550B / SWE-Bench | 비용 −30%, 정확도는 거의 불변 | | Mistral-3.5 / SWE-Bench | 비용 −32%, 정확도는 거의 불변 | | 120B / Terminal-Bench | 비용 −26% | | 30B / Terminal-Bench | 비용 +75% |

같은 말을 둘로 쪼개서 할 수 있다:

- 약한 모델에게 계획은 발판이다——정확도를 곧바로 끌어올린다.

- 강한 모델에게 계획은 비용 절감 스위치다——모델은 이미 무엇을 해야 하는지 알고 있고, 계획의 가치는 막다른 길로 탐색하러 가지 않게 하는 데 있다.

- 명령줄 위주 태스크에서 약한 모델에게 계획은 오히려 더 비싸다(+75%)——쓸모 있는 계획을 써 내지 못하면서 token 한 라운드를 더 쓴다.

5.3 도구 면은 당신이 "쓰지 않는 그 모델"을 위해 내는 세금일 수 있다

| 시나리오 | bash-only의 효과 | | --- | --- | | 550B / SWE-Bench | 비용 −53% | | 550B / Terminal-Bench | 비용 −30% |

원문의 표현은 아주 직설적이다: 사전 정의 도구는 명령줄 능력이 약한 모델을 돕는 것 이며, shell에 이미 능숙한 모델에게는 순수 bash 인터페이스가 똑같이 잘 돌아가고 비용은 훨씬 낮으며, 명령줄 위주 태스크에서 그 차이가 가장 크다.

다시 말해: 당신이 공들여 설계한 그 도구 면은, 십중팔구 당신이 실제로 쓰지도 않는 모델을 위해 지팡이를 만들어 준 것이고, 당신은 매 라운드마다 그 지팡이 값을 token으로 치르고 있다.

5.4 계층화 순서: 먼저 결정론적 생략, 그다음 모델이 요약

다섯 단계 전략 중 효율이 가장 높은 것은 T4다: 먼저 규칙에 따라 확실히 버릴 수 있는 것(낡은 도구 관찰, 중복 내용)을 버리고, 그다음 모델에게 남은 부분을 압축하게 한다.

이유는 비용 구조다——결정론적인 일은 돈을 들여 모델에게 시키지 말라. 만약 바로 T3(전량 요약)로 가면, 애초에 그냥 버릴 수 있었던 내용 더미를 모델에게 압축시키는 셈이니, token마다 두 번 돈을 내는 것이다.

5.5 덤으로 비용 장부를 펼쳐 보면: 같은 태스크가 네 모델에서 100배까지 차이 난다

논문은 OpenRouter의 공개 가격을 썼는데, 그대로 베껴 와 자로 삼을 만하다:

| 모델 | 입력 / 출력(백만 token당) | SWE-Bench 단일 태스크 비용 구간 | | --- | --- | --- | | Nemotron-3 30B | 0.05 / 0.20 | 0.04 – 0.11 | | Nemotron-3 120B | 0.08 / 0.45 | 0.05 – 0.39 | | Nemotron-3 550B | 0.50 / 2.20 | 0.26 – 2.70 | | Mistral-Medium-3.5-128B | 1.50 / 7.50 | 0.87 – 4.65 |

Terminal-Bench에서도 구간은 비슷하다(30B 0.02 – 0.15, Mistral 0.76 – 4.16).

양 끝점만이 아니라 구간의 폭에 주목하라. 같은 모델, 같은 벤치마크에서 가장 비싼 설정과 가장 싼 설정 사이의 차이가 7–12배다(30B는 Terminal-Bench에서 7.5배). 격차의 출처는 바로 그 세 개의 노브다.

다시 말해: 모델을 바꾸기 전에 다이얼을 먼저 제대로 맞추는 것이, 모델을 바꾸는 것보다 훨씬 저렴할 수 있다. 550B를 bash-only(−53%)로 돌린 뒤의 비용은 기본 설정 550B의 절반보다 낮다——이것은 "차세대 모델 가격 인하를 기다리는 것"보다 훨씬 통제 가능하다.

六、六个工程死结（该泼的冷水）

이 논문의 결론은 매우 단단하지만, 경계도 아주 명확하며, 그중 몇 가지는 저자 스스로 Limitations에 적어 넣은 것이다.

1. 계획과 행동 공간은 단 한 지점에서만 소거 실험(ablation)을 했다. 이 두 다이얼의 모든 실험은 기본 설정(T4 / 128k)에서 돌렸다. 그런데 128k는 바로 컨텍스트 관리가 가장 중요하지 않은 쪽 끝이다. 즉, "계획의 가치는 모델 강도에 따라 변한다"는 결론은 컨텍스트가 거의 제약을 이루지 않는 조건에서 측정된 것이다——계획 × 예산의 상호작용 항은 이 논문에서 측정하지 않았다. 만약 32k 환경에서 돌린다면, 계획의 역할은 여기서 보고된 것과 완전히 다를 수 있다.

2. "모델 강도"라는 독립변수가 교란되어 있다. 네 모델 중 셋은 같은 패밀리에서 나왔고(Nemotron-3의 30B / 120B / 550B), 넷째는 Mistral-Medium-3.5-128B다. 이는 "강도 구배"가 실제로는 주로 "동일한 후속 학습 레시피 아래의 크기 구배"라는 뜻이다. 크기가 비슷한 모델이라도 학습 레시피, 도구 인터페이스 노출도, 네이티브 shell 숙련도가 다르면 추세가 성립하지 않을 수 있다. 저자들도 이 점을 스스로 지적했다.

3. 각 설정마다 각 과제를 단 한 번만 돌렸다. 분산 추정이 없다. 게다가 Terminal-Bench는 과제가 89개뿐이라, 상당히 많은 비교가 짝지은 McNemar 검정에서 유의하지 않았다——논문의 결론은 "모델과 예산 전반에 걸쳐 방향이 일치한다"에 의존하지, 개별 셀이 유의하다는 데 의존하지 않는다. 이는 정직한 방식이지만, 동시에 개별 숫자를 너무 세밀하게 파고들지 말고 추세를 보라는 뜻이기도 하다.

4. 행동 공간은 하나로 묶인 개입이다. "사전 정의된 도구 → bash-only"로 전환할 때, 네 가지가 동시에 바뀐다: 도구 가용성, 인터페이스 프롬프트, 파일 상태 추적, 자동 진단. 따라서 "도구면"이 가져오는 이득은 그중 어느 하나로도 귀속시킬 수 없다. 이 논문에서 "파일 상태 추적을 없애면 어떻게 되는가"를 도출할 수는 없다.

5. SWE-Bench Verified는 Python만 지원한다. 결론을 다른 언어 생태계로 옮기기 전에는 재검증이 필요하다.

6. 공개 코드 저장소가 없다. 컨텍스트 관리는 단일 임계값 전략(0.6 / 0.85)과 고정 압축비를 사용했고, 임계값 민감도 분석을 하지 않았다. 당신이 그대로 베껴 갈 때, 이 두 숫자는 십중팔구 자신의 과제에 맞게 다시 조정해야 할 것이다.

한 가지 더 덧붙이자면: 이것들은 저자가 스스로 보고한 결과이며, 현재까지 독립적 재현은 보이지 않는다. 논문은 9월 17일에 공개되었고, 하루 만에 Hacker News 첫 페이지에 올랐다(194점). 이는 이 문제가 실제로 측정이 부족하다는 것을 보여준다——하지만 측정이 부족하다는 것이 이 논문이 제대로 측정했다는 뜻은 아니다.

七、今天下午就能做的四件事

① 먼저 오버플로율을 측정하고, 그다음 컨텍스트 관리를 할지 말지를 결정하라.

1. 컨텍스트 관리를 끄고, 자신의 실제 과제로 한 번 돌려라 2. 컨텍스트 초과로 실패한 과제의 비율을 집계하라 3. 이 비율이 0에 가깝다면 → 당신의 컨텍스트 관리는 기껏해야 2-3점의 가치가 있으니, 거기에 시간을 쓰지 마라 만약 50%를 넘는다면 → 그것은 당신 시스템에서 가장 값진 구성 요소이니, 진지하게 할 가치가 있다

이 단계는 비용이 극히 낮지만, 앞으로 한 달 동안 당신이 어디에 투자할지를 결정한다. 대부분의 사람은 이 숫자를 한 번도 측정해 본 적이 없다.

② 등급 순서를 고정하라: 결정론적 생략 → LLM 요약; 회수 가능(recallable)은 하지 마라.

recall_event를 하지 마라. 56.3%의 설정에서 한 번도 사용되지 않았고, 가장 많이 사용한 그 그룹은 오히려 더 나빴다. 만약 이미 이 체계를 갖추고 있다면, 그 실제 호출 로그를 살펴보라——십중팔구 0일 것이다.

③ harness 설계 문서에 메타데이터 필드를 하나 추가하라: 측정 당시의 컨텍스트 예산.

이것이 이 논문의 가장 직접적인 엔지니어링 시사점이다. 어떤 "우리 agent의 모범 사례"든 그것이 측정된 당시의 윈도 크기를 함께 명기해야 한다, 왜냐하면 모델을 바꿀 때 그것은 무효가 되고, 게다가 아주 조용히 무효가 되기 때문이다——오류를 내지 않고, 다만 점수가 소리 없이 떨어진다.

규칙을 하나 정하길 권한다: 하위 모델을 업그레이드할 때마다, 컨텍스트 관리 항목을 재측정하라. 전면 재측정은 필요 없고, T0 오버플로율에다托管 등급의 이득 차이만 측정하면 되며, 비용은 몇십 분의 일이다.

④ 만약 당신이 강한 모델을 쓴다면, 한 번 bash-only와 계획 끄기를 시도하고, 그다음 비용만 보라.

정확도는 십중팔구 움직이지 않지만(이것이 바로 논문이 말한 바다), 비용은 30%–53% 떨어질 수 있다. 이런 실험에서 유일하게 주의할 점은 정확도만 측정하지 말라는 것이다——정확도만 보면 "차이가 없다"는 잘못된 결론을 얻고, 그러고 나서 그 목발에 계속 돈을 지불하게 된다.

八、四条判断

harness 결정에는 유통기한이 있고, 그 유통기한은 모델이 정하지, 당신이 정하지 않는다. 3년 전 가장 값졌던 그 부분(컨텍스트 관리)은 오늘 2.7점의 가치가 있다. 이것은 그것을 깎아내리는 것이 아니라, 일회성 설계 문서가 아니라 모델 업그레이드와 묶인 재측정 리듬이 필요하다는 말이다.

어떤 harness 구성 요소가 값어치가 있는지 판단하려면, 먼저 그것이 막는 실패가 어느 종류인지 묻고, 그다음 그런 실패가 당신의 환경에 얼마나 남아 있는지 보라. 컨텍스트 관리가 막는 것은 "배 터짐"이고, 터짐률이 0이 되면 그것도 0이 된다. 이 사고방식은 어떤 구성 요소에도 적용된다——먼저 실패면을 특정하고, 그다음 재고를 계산하라.

"강한 모델 + 간소한 harness"는 저평가된 조합이다. 계획은 강한 모델에게 돈 절약 스위치이고, 도구면은 shell에 익숙한 모델에게 목발이다. 대부분의 harness는 그 아래에 있는 모델을 위해 설계되었는데, 매 라운드마다 그 대가를 치르고 있다.

가장 기억해야 할 것은 그 삼분법이다: 길이 / 정지점 / 입자도(granularity). 다음에 agent가 죽으면, 급하게 프롬프트를 조정하지 말고, 먼저 그것이 어느 면에서 죽었는지 판단하라——이 세 면의 수리법은 완전히 다르고, 섞어서 조정하면 서로를 가릴 뿐이다.

마지막 한마디: 만약 당신의 팀에 《우리 agent의 모범 사례》문서가 있다면, 거기에 "이 숫자들이 얼마나 큰 컨텍스트 윈도 아래에서 측정된 것인지"가 적혀 있는지 한번 펼쳐 보라. 십중팔구 없다. 그리고 이번 주에 더 얻게 된 이 몇십 점이, 바로 그 누락된 메타데이터 한 줄이다.

数据来源与说明

- 주 논문: An Empirical Study of Harness Design for Coding Agents, arXiv:2609.20804, 2026년 9월 17일 제출, 43페이지, 저자 Run-Ze Fan 등 9인. 이 글의 모든 실험 숫자는 해당 논문 본문, 표 2–4 및 그림 3에서 가져왔다.

- 모델 가격은 논문이 채택한 OpenRouter의 백만 토큰당 가격이다: Nemotron-3-30B 0.05 / 0.05/ 0.05/ 0.20, 120B 0.08 / 0.08/ 0.08/ 0.45, 550B 0.50 / 0.50/ 0.50/ 2.20, Mistral-Medium-3.5 1.50 / 1.50/ 1.50/ 7.50.

- 논문은 코드 저장소를 공개하지 않았다; 컨텍스트 관리는 임계값 0.6 / 0.85와 고정 압축비를 사용했고, 임계값 민감도 분석을 하지 않았다.

- 한계와 통계적 검정력 설명(설정당 단일 실행, Terminal-Bench 89개 과제, McNemar 대부분 비교 비유의, 행동 공간은 묶인 개입, SWE-Bench Verified는 Python만)은 모두 논문 Limitations 장에서 나온 것이다.

- 이 글은 실험을 재현하지 않았다; 결론은 논문의 자기 보고 결과에 대한 해석이며, 제3자의 독립적 재현은 보이지 않는다.

米小虾

大模型开发工程师

255

文章

146k

阅读

55

粉丝