[arXiv 2608.06301] HarnessOpt-Bench: 비싸고 확률적인 평가 아래 하네스 최적화 측정하기

HarnessOpt-Bench: Evaluating LLMs at Harness Optimization

https://arxiv.org/abs/2608.06301

Varun Ursekar, Apaar Shanker, Yash Maurya, Shehab Yasser, Vijay S. Kalmath, Veronica Chatrath, Yuan (Emily) Xue | Scale AI | arXiv:2608.06301 | 2026년 8월

---

1. 서론: 모델을 감싼 실행 체계까지 최적화 능력의 일부가 된다

1.1 가중치 밖에서 성능을 결정하는 harness

대규모 언어 모델은 단독 함수처럼 호출되기보다 프롬프트, 도구, 제어 흐름, 문맥, 메모리, 호출 오케스트레이션을 묶은 프로그램 안에서 작동한다. 저자들은 이 전체 프로그램을 harness라고 부르며, 같은 모델도 어떤 harness에 연결되는지에 따라 상당히 다른 능력을 보일 수 있다는 점에서 출발한다. 여기서 harness 최적화란 측정된 결과와 고정된 예산을 기준으로 harness를 반복적으로 개선하는 과정이다. 따라서 대상 모델의 가중치를 바꾸지 않더라도 모델이 정보를 받고 행동하며 답을 제출하는 경로를 바꾸어 시스템 수준의 성능을 높일 수 있다.

이 문제에서 최적화 대상은 단순한 시스템 프롬프트 하나가 아니다. 도구 정의, 메모리 운용, 단계 수, 오류 재시도, 문맥 관리, 답 추출, 검색 정책, 추론 강도처럼 서로 영향을 주는 구성요소가 모두 후보가 된다. 저자들이 채택한 표현에서는 후보 harness 자체가 실행 가능한 코드베이스이며, 프롬프트와 제어 로직 사이에 미리 정해 둔 의미론적 경계를 두지 않는다. 이 정의는 문구 수정과 프로그램 수정을 한 공간에 놓고, 최적화기가 무엇을 얼마나 넓게 바꿀지 스스로 결정하게 한다.

1.2 값비싸고 확률적인 평가가 만드는 별도의 능력 시험

일반적인 소프트웨어 변경은 테스트 스위트가 비교적 싸고 명확한 정답 판정을 제공하지만, harness 변경의 효과는 확률적 에이전트를 여러 사례에 실행해야 추정할 수 있다. 한 번의 실행 결과가 곧 기대 성능은 아니므로, 최적화기는 불완전한 증거로 실패 원인을 진단하고 어떤 실험에 평가 예산을 쓸지 선택해야 한다. 또한 관측된 향상이 실제 개선인지 실행 변동인지 구분하고, 여러 후보 가운데 최종 배포 대상을 스스로 지명해야 한다. 코딩 능력은 필요조건이지만, 제한된 실험으로 확률적 시스템을 이해하고 의사결정하는 능력까지 요구된다는 점이 핵심이다.

평가가 싸다면 많은 후보를 무차별적으로 생성한 뒤 최고 점수를 고르는 방식이 개별 후보에 대한 빈약한 추론을 보완할 수 있다. 반대로 고정 코퍼스 연구나 터미널 작업처럼 평가가 비싸고 잡음이 크면, 한 번의 실험이 소비하는 사례와 토큰이 커서 이전 증거를 해석하는 능력 자체가 성패를 가른다. HarnessOpt-Bench는 바로 이 두 번째 체제를 겨냥하며, 값싸게 채점되는 과제보다 평가 자체가 병목인 과제를 선택한다. 장기 상호작용, 복잡한 도구 생태계, 확률적 결과 해석이 한 과제에 결합되므로 단일 정답 단계의 생성과도 성격이 다르다.

1.3 보이는 향상을 실제 일반화로 바꾸는 통제 조건

기존 방법의 보고값은 최적화기 모델, 그 모델이 사용하는 코딩 harness, 개선 대상 에이전트, 시드 구현, 예산, 정보 공개 정책, 채점 절차가 함께 달라 원인을 분리하기 어렵다. 저자들은 비교 가능한 측정을 위해 대상 모델, 실행 환경, 검증기를 고정하고, 탐색 중 최종 테스트 상태를 완전히 숨기며, 신뢰 실행 경계가 접근 권한과 예산을 강제해야 한다고 규정한다. 이 조건이 없으면 높은 점수가 harness의 일반화된 개선인지, 공개 점수에 대한 적합인지, 더 많은 자원이나 다른 모델을 사용한 결과인지 판별하기 어렵다. 모든 후보를 버전으로 보존하는 감사 가능성도 동일한 통제 설계에 포함된다.

Figure 1. 보류 테스트를 보호하는 HarnessOpt-Bench의 신뢰 실행 구조.

그림 1에서 최적화기 sandbox는 대상 harness만 쓸 수 있고, 과제 데이터와 허용된 평가 결과는 읽을 수 있지만 수정할 수는 없다. 개발 사례의 개별 trace와 검증 집계 점수는 공개되지만 테스트 사례와 점수는 신뢰 서버 뒤에 남는다. 후보 평가는 격리된 비특권 sandbox에서 실행되며 모든 모델 호출은 허용 모델과 범위별 예산을 강제하는 gateway를 통과한다. 테스트는 최종 후보가 지명된 뒤에만 수행된다. 이 때문에 후보가 높은 점수를 내도 접근 경계와 재현 기록을 함께 감사할 수 있다.

이 구조에서 제한은 최적화기에게 지시문으로 준 약속이 아닌 실행 환경의 속성이다. 최적화기 sandbox에는 보류 데이터, 모델 제공자의 credential, 예산 집행 권한이 없으므로 프롬프트를 무시해도 경계를 우회할 수 없게 설계된다. 연구 질문도 이 분리를 따라 구성되어, frontier 모델을 harness 최적화 능력으로 구별할 수 있는지, 현재 최적화기가 어디에서 부족한지, 최적화기 자체의 코딩 harness가 모델 대비 얼마나 기여하는지를 묻는다. 측정 대상은 결과물을 만드는 모델 하나가 아닌 고정된 조건 아래에서 증거를 모으고 코드를 고쳐 최종 후보를 선택하는 전체 최적화 능력이다.

HarnessOpt-Bench는 시드 harness, 등급화된 개발 및 검증 피드백, 고정된 대상 평가 예산을 최적화기에게 제공한다. 최적화기는 여러 후보를 만들 수 있지만 최종적으로 하나를 지명해야 하며, 성과는 탐색 중 접근할 수 없었던 테스트 분할에서 시드 대비 정규화 이득으로 계산된다. 네 개 downstream task의 시드와 분할은 고정되고, 대상 에이전트의 자원 사용과 후보 버전은 신뢰 실행 계층에서 기록된다. 인터페이스와 예산을 만족하는 프로그램이라면 특정 진화 알고리즘이나 코딩 에이전트에 한정되지 않고 최적화기로 참여할 수 있다.

2. 배경 및 관련 연구: 최적화 방법의 경계를 넘어 공통 측정 문제를 세운다

2.1 프롬프트에서 프로그램 전체로 넓어진 자동 최적화

LLM을 더 큰 탐색 scaffold 안에 넣어 프로그램을 발견하거나 최적화하는 흐름에는 OPRO, FunSearch, AlphaEvolve, ShinkaEvolve가 있다. 이 계열을 harness 최적화 관점에서 나누는 두 축은 어떤 구성요소까지 수정할 수 있는가와 LLM이 탐색에서 어떤 역할을 맡는가이다. 예를 들어 ShinkaEvolve와 GEPA에서는 LLM이 더 큰 진화 절차 안의 변이 또는 반성적 제안 구성요소로 사용된다. 반면 VeRO와 MetaHarness는 코딩 에이전트가 코드베이스를 읽고, 평가 증거를 선택하며, 수정과 후보 선택을 끝까지 수행하게 한다.

수정 범위가 좁은 방법과 넓은 방법은 동일한 숫자만으로 우열을 비교하기 어렵다. DSPy는 주변 프로그램을 고정한 채 프롬프트를 최적화하고, Meta Context Engineering은 이중 수준 절차로 skill과 문맥 artifact를 탐색한다. TextGrad, Trace, LLM-AutoDiff는 연결된 workflow 안의 임의 텍스트 구성요소에 LLM 기반 텍스트 피드백을 역전파하며, GEPA는 반성적 피드백으로 텍스트 artifact의 진화 탐색을 유도한다. 이들은 각각 중요한 최적화 방식을 제시하지만, 허용된 탐색 공간과 예산 및 채점 방식이 다르면 보고된 향상이 어떤 능력 차이를 뜻하는지 분해되지 않는다.

표 1. 기존 자동 최적화 접근과 HarnessOpt-Bench의 측정 위치

접근 범주	대표 시스템	수정 범위와 탐색 방식	공통 평가와의 관계
프롬프트 최적화	DSPy	주변 프로그램을 고정하고 프롬프트를 최적화	탐색 공간이 텍스트 일부로 제한됨
문맥 및 텍스트 artifact 최적화	Meta Context Engineering, TextGrad, Trace, LLM-AutoDiff, GEPA	skill, 문맥 artifact, workflow의 텍스트 구성요소를 이중 수준 탐색, 텍스트 피드백, 진화 절차로 수정	텍스트 구성요소와 이를 감싼 절차의 효과가 결합될 수 있음
코드 정의 agent 및 workflow 탐색	STOP, ADAS, AFlow	scaffolding program의 재귀 개선, 코드 표현 agent 설계 탐색, code-defined workflow의 tree search	프롬프트보다 넓지만 방법별 search algorithm이 결과에 개입
재귀적 자기 수정	Darwin Gödel Machine, Gödel Agent, SICA	자신의 agent 또는 scaffold를 재귀적으로 수정	자기 수정 체계와 평가 protocol을 함께 해석해야 함
end-to-end harness optimizer	VeRO, MetaHarness, Agentic Harness Engineering, HarnessX	coding agent가 target source, 이전 점수와 trace를 읽고 수집할 증거와 수정을 선택	HarnessOpt-Bench가 직접 겨냥하는 최적화 체제
고정된 평가 과제	HarnessOpt-Bench	최적화 방법을 제안하는 대신 문제, 공개 정책, 예산, held-out scoring을 고정	optimizer model, coding harness, search algorithm을 같은 조건에서 비교

HarnessOpt-Bench는 위 방법 가운데 하나를 새 표준 최적화 알고리즘으로 지정하지 않는다. 오히려 최적화 문제와 평가 protocol을 고정하는 benchmark를 제공하여, 서로 다른 모델과 harness 및 search algorithm이 공통 조건에서 경쟁하게 한다. 기반 실행 인프라와 protocol은 VeRO에서 이어받지만, 기여의 중심은 여러 downstream optimization task로 구성한 suite와 통제된 비교 설계다. 따라서 한 방법의 데모 성과를 재현하는 문제와 최적화 능력 자체를 측정하는 문제를 분리한다.

2.2 end-to-end 최적화기가 맡는 증거 수집과 배포 결정

VeRO와 MetaHarness에 가까운 체제에서는 LLM이 미리 정해진 변이 연산을 호출하는 데 그치지 않는다. 코딩 에이전트는 대상 코드와 이전 후보의 점수 및 실행 trace를 읽고, 다음에 어떤 사례를 어느 분할에서 평가할지 고르며, 코드 수정과 최종 후보 지명을 수행한다. 이 역할은 실패 진단, 실험 설계, 프로그램 변경, 예산 배분, noisy selection을 하나의 긴 궤적으로 결합한다. HarnessOpt-Bench가 평가하려는 것은 이러한 end-to-end 판단을 수행하는 최적화기이며, 실제 실험에서는 LLM과 coding harness의 조합이 그 역할을 맡는다.

이때 최적화기의 coding harness와 최적화 대상인 target harness를 구분해야 한다. 전자는 최적화기 모델이 파일을 읽고 명령을 실행하고 코드를 고칠 수 있게 하는 scaffold이며, 후자는 downstream task를 수행하는 대상 에이전트의 프로그램이다. 동일한 optimizer model도 opencode, claude-code, codex, kimi-cli 같은 서로 다른 coding harness에서 다른 탐색 궤적을 만들 수 있다. 두 층을 분리하지 않으면 성능 차이가 모델의 추론 능력에서 왔는지, 모델을 감싼 개발 도구에서 왔는지 알 수 없다.

2.3 코딩 benchmark와 구별되는 확률적 system optimization

코딩 에이전트 평가는 HumanEval과 MBPP의 함수 수준 합성에서 SWE-bench의 repository 규모 실행 과제로 확장되어 왔다. MLE-bench의 machine learning engineering과 KernelBench의 kernel optimization은 반복 최적화까지 평가 범위를 넓힌다. HarnessOpt-Bench도 실제 코드베이스를 탐색하고 환경 피드백에 따라 반복한다는 점에서는 이 흐름과 닿아 있다. 그러나 최적화 대상이 에이전트 harness이고 평가 피드백이 확률적이며 탐색에 명시적 자원 경계가 있다는 점에서 차이가 난다.

정확한 unit test가 있는 저장소 과제에서는 변경과 정답 사이의 연결을 비교적 직접 확인할 수 있지만, harness 후보의 효과는 사례 집합과 rollout 변동을 거친 통계량으로만 관측된다. validation에서 가장 높았던 후보가 held-out test에서도 같은 순서를 유지한다는 보장이 없으며, 보이는 점수에 적응할수록 실제 일반화와 선택 편향이 섞일 수 있다. 그래서 개발 분할은 입력, 사례별 결과, trace를 진단용으로 공개하고 validation은 집계 점수만 선택용으로 공개한다. test를 끝까지 숨기는 설계는 부가적인 보안 장치가 아닌 관측된 개선을 일반화된 harness 개선으로 해석하기 위한 측정 조건이다.

3. 방법론: HarnessOpt-Bench는 제한된 탐색을 보류 성능으로 채점한다

3.1 제약된 확률적 프로그램 최적화 문제

후보 harness $H$는 고정 실행 interface와 소수의 immutable path를 지키는 실행 가능한 코드베이스다. 최적화기는 파일을 수정하고 추가하거나 삭제할 수 있으며, 가능한 후보의 집합을 $\mathcal{H}$, 고정된 시드를 $H_0 \in \mathcal{H}$로 표기한다. 과제는 후보가 바꿀 수 없는 불변량 $\theta=(\mathcal{M},E,V)$도 함께 고정한다. 여기서 $\mathcal{M}$은 후보가 호출할 수 있는 모델 집합, $E(x)$는 사례 $x$의 실행 환경, $V$는 완료된 궤적을 $[0,1]$ 점수로 바꾸는 검증기다.

최적화기가 바꿀 수 있는 것은 $H$뿐이며, $\theta$를 바꾸면 같은 후보의 개선이 아닌 다른 과제가 된다. 예를 들어 web 접근 가능 여부가 환경 $E$에서 통제된다면 후보 코드가 임의로 그 제약을 해제할 수 없다. 각 과제에서 사용 가능한 target model도 하나로 고정되어 $|\mathcal{M}|=1$이며, 시드 점수가 바닥이나 천장에 붙지 않도록 과제별 모델을 선택한다. 이 분리는 harness 변경으로 인한 차이만 측정값에 남기기 위한 attribution 장치다.

표 2. HarnessOpt-Bench protocol의 핵심 기호와 고정 조건

기호	정의	최적화기 접근 범위
$H_0$	재현성을 위해 고정된 seed harness	읽고 출발점으로 사용하지만 원본 기준값은 고정
$H$, $\mathcal{H}$	candidate harness와 feasible candidate 집합	interface와 immutable path 안에서 파일 수정, 추가, 삭제 가능
$\theta=(\mathcal{M},E,V)$	target model 집합, 사례 환경, verifier로 구성된 task invariant	변경 불가
$\mathcal{D}^{\mathrm{dev}}$, $\mathcal{D}^{\mathrm{val}}$, $\mathcal{D}^{\mathrm{test}}$	서로 겹치지 않는 개발, 검증, 테스트 분할	개발은 상세 공개, 검증은 집계 공개, 테스트는 탐색 중 비공개
$F_{\theta}(H,Q)$	후보 $H$를 사례 부분집합 $Q$에서 평가해 $(\hat{s},\varphi)$를 반환하는 함수	예산 안에서 개발 또는 검증 사례를 선택해 요청
$\pi_{\mathcal{D}}$	분할별로 점수와 trace 중 무엇을 보여 줄지 정하는 disclosure policy	정책이 공개한 projection만 관측
$c_j$, $B$	평가 요청 $j$의 non-negative cost vector와 componentwise budget vector	$\sum_j c_j \leq B$를 만족하도록 평가 규모와 빈도를 선택
$H^{+}$, $g$	지명된 최종 후보와 seed 대비 normalized gain	후보는 지명하지만 test 평가와 $g$ 계산은 trusted server가 수행

3.2 rollout, 기대 점수, 분할별 공개 정책

사례 $x$에서 harness $H$를 실행하면 확률적 궤적 $\tau \sim \operatorname{Rollout}(H,\theta,x)$가 생성되고, 검증기 $V(\tau,x)$가 점수를 부여한다. 분할 $\mathcal{D}$에서의 성능은 사례 추출과 rollout 변동을 모두 평균한 기대 점수로 정의한다. 저자들은 test 분할의 기대 점수 $\mathcal{E}_{\theta}(H;\mathcal{D}^{\mathrm{test}})$를 간단히 $\mathcal{E}_{\theta}(H)$로 쓴다. 정의상 단일 실행의 점수와 후보의 기대 성능은 같은 양이 아니다.

$$ \mathcal{E}_{\theta}(H;\mathcal{D})= \mathbb{E}_{x\sim\mathcal{D}} \mathbb{E}_{\tau\sim\operatorname{Rollout}(H,\theta,x)} \left[V(\tau,x)\right]. $$

탐색 중 최적화기는 개발 또는 검증 분할의 부분집합 $Q$를 골라 $F_{\theta}(H,Q)$를 호출할 수 있다. 이 함수는 집계 성능 추정치 $\hat{s}$와 사례별 결과 및 실행 trace를 담은 $\varphi$를 만들지만, 최적화기가 실제로 보는 것은 disclosure policy $\pi_{\mathcal{D}}$가 허용한 부분뿐이다. 개발 분할은 입력, 사례별 결과, trace를 공개해 진단을 돕고, 검증 분할은 후보 선택을 위한 집계 점수만 공개한다. 테스트 분할은 탐색 중 접근할 수 없고 최종 후보가 지명된 뒤 신뢰 서버에서만 평가된다.

$$ F_{\theta}(H,Q)\longrightarrow(\hat{s},\varphi), \qquad \text{observation}=\pi_{\mathcal{D}}(\hat{s},\varphi). $$

3.3 후보 생성과 평가 요청을 하나의 예산으로 묶는 protocol

Protocol은 candidate set을 $\mathcal{C}=\{H_0\}$로 초기화한다. 최적화기는 아직 최종 후보를 지명하지 않았고 예산이 남아 있는 동안 새 $H'\in\mathcal{H}$를 commit해 $\mathcal{C}$에 추가하거나, 기존 $H\in\mathcal{C}$와 사례 집합 $Q$를 골라 평가를 요청한다. 평가 결과에서는 해당 분할 정책이 공개한 정보만 받아 다음 수정 또는 추가 평가를 결정한다. 마지막에는 $H^{+}\in\mathcal{C}$ 하나를 지명하고, 서버가 이를 $\mathcal{D}^{\mathrm{test}}$에서 평가해 $g$를 보고한다.

각 평가 요청 $j$는 non-negative cost vector $c_j$를 소비하고, 누적 비용은 budget vector $B$를 componentwise로 넘을 수 없다. 실제 설정의 핵심 한도는 개발과 검증 분할 각각 최대 100회 평가 호출, 각 분할에서 네 번의 full case pass, 총 expendable target-model token cap이다. 작은 사례 부분집합을 여러 번 볼지, 넓은 집합을 적게 볼지, 어느 후보를 더 높은 fidelity로 확인할지는 최적화기가 정한다. 최적화기 모델 자신의 inference는 관측을 위해 계량하지만 이 연구에서는 상한을 두지 않아, scarce resource를 target-agent 평가로 한정한다.

$$ \sum_j c_j \leq B. $$

평가 호출 횟수와 사례 소비량을 동시에 제한하는 이유는 작은 요청으로 call cap을 우회하거나 한 번의 대규모 요청으로 사례 예산을 무력화하는 것을 막기 위해서다. 비용이 vector이므로 한 구성요소에 여유가 있어도 다른 구성요소를 초과할 수 없으며, 부등식은 모든 구성요소에 대해 적용된다. 이러한 설계는 최적화기를 고정된 횟수의 mutation loop에 가두지 않으면서도, 서로 다른 탐색 전략이 소비한 target evaluation을 비교 가능하게 만든다. 후보 commit과 평가 요청을 분리해 코드 탐색 자체는 열어 두되, 성능 증거를 얻는 행위에는 동일한 자원 경계를 적용한다.

3.4 보지 못하는 목적함수와 정규화 이득

최적화 목표는 held-out test에서 지명 후보가 고정 seed보다 얼마나 나아지는지를 최대화하는 것이다. $H_0$가 고정되어 있으므로 $\mathcal{E}_{\theta}(H_0)$는 한 과제 안에서 상수지만, test disclosure가 비어 있어 최적화기는 실제로 최대화하는 값을 탐색 중 한 번도 보지 못한다. 개발 trace와 검증 집계 점수는 목적함수의 간접 증거일 뿐이며, 최종 판단은 그 증거가 test로 일반화될 것이라는 추론에 의존한다. 원시 점수 차이는 과제의 baseline과 scoring scale에 민감하므로 과제 간 비교에는 남은 headroom의 비율을 사용한다.

$$ \max_{H\in\mathcal{H}} \left[\mathcal{E}_{\theta}(H)-\mathcal{E}_{\theta}(H_0)\right] \quad\text{subject to}\quad \sum_j c_j\leq B. $$ $$ g= \frac{\mathcal{E}_{\theta}(H^{+})-\mathcal{E}_{\theta}(H_0)} {1-\mathcal{E}_{\theta}(H_0)}. $$

정규화 이득 $g$는 seed 위에 남은 headroom 가운데 최종 후보가 확보한 비율이다. $g=0$이면 seed와 같고 양수면 개선이며, 음수면 최적화기가 seed보다 나쁜 후보를 지명했다는 뜻이다. baseline이 측정된 0인 GAIA에서는 분모가 1이므로 $g$가 곧 raw held-out score가 되어, competent seed의 개선이 아닌 작동하는 agent를 만드는 능력을 측정한다. 이 차이 때문에 task normalization이 공통 단위를 제공하더라도 GAIA를 다른 세 task의 model-effect composite에 합치지 않는다.

3.5 네 과제, 고정 seed, 반복 측정으로 구성한 suite

Suite는 OfficeQA, BrowseComp-Plus, Terminal-Bench, GAIA의 네 downstream task로 구성된다. 각 task의 환경과 검증기는 원래 benchmark에서 가져오며, 제한된 network access와 엄격한 wall-clock bound 같은 환경 제약도 그대로 유지한다. 모든 seed는 의도적으로 조정하지 않은 작은 Python harness이며, OfficeQA, BrowseComp-Plus, Terminal-Bench의 세 seed는 작동하지만 단순하고 GAIA seed는 non-functional stub이다. OfficeQA seed는 약 130줄, 세 개 도구, 24-turn loop, generic system prompt로 구성된 사례다.

표 3. HarnessOpt-Bench task별 고정 설계와 seed headroom

Task	고정 target model	분할 dev/val/test	Seed test score	가장 높은 off-the-shelf score
OfficeQA	deepseek-v4-flash	$49/98/99$	$0.341\pm0.023$	mini-swe-agent, $0.734\pm0.009$
BrowseComp-Plus	deepseek-v4-flash	$33/66/66$	$0.462\pm0.020$	mini-swe-agent, $0.701\pm0.009$
Terminal-Bench	grok-build	$17/36/36$	$0.241\pm0.009$	opencode, $0.607\pm0.030$
GAIA	gpt-5.4-mini	$33/66/66$	$0.000$	openhands-sdk, $0.508\pm0.029$

표의 seed 점수와 후보의 최종 점수는 test case마다 세 번 시도한 값을 평균하며, seed baseline도 $K=3$ independent round를 pooling해 한 번 고정한다. 표에 적힌 오차는 세 round mean의 standard error이고 사례 간 분산이 아니며, timeout은 제외하지 않고 0점으로 처리한다. Off-the-shelf harness 점수는 같은 dataset, partition, round, target model에서 seed 프로그램만 교체한 참고값이다. 정규화 이득의 기준은 어디까지나 seed baseline이며, off-the-shelf 최고값은 시드 위에 실제 headroom이 있음을 보여 주는 맥락이다.

분할은 서로 겹치지 않는 고정 manifest로 관리되고, task별 실제 dev, validation, test 사례 수는 표 3의 값으로 고정된다. 각 candidate는 immutable Git commit으로 보존되며 dependency는 lockfile로 고정되고, 평가는 dataset이 정한 case별 timeout을 사용하는 isolated sandbox에서 수행된다. Gateway는 모델 호출의 input, cached, output, total token을 구분해 기록하고 request log에 trial attribution 정보를 남긴다. 동일한 후보를 같은 사례에서 다시 채점했을 때의 차이는 task-specific resolution band로 환산되어, 그보다 작은 차이는 통계적 유의성이 아닌 측정상 미해결로 취급된다.

3.6 optimizer model과 coding harness를 분리하는 실험 격자

Core grid는 세 개발사의 frontier optimizer model 다섯 개, 즉 claude-opus-5, claude-sonnet-5, gpt-5.6-sol, gpt-5.6-terra, kimi-k3를 네 task에서 평가한다. 모든 모델은 공통 coding harness인 opencode와 짝지어지고, 동시에 Claude에는 claude-code, GPT에는 codex, Kimi에는 kimi-cli라는 native harness가 대응한다. 따라서 core grid에는 열 개 model-harness configuration이 있으며, 공통 harness 비교는 scaffold를 고정한 모델 차이를, 같은 모델의 공통 및 native 비교는 scaffold 민감도를 측정한다. Core grid의 각 optimizer configuration은 두 번 실행되고 전체 연구에는 111개의 scored optimizer run이 포함된다.

GAIA에서는 harness 축을 더 넓히기 위해 모든 모델에 goose와 mini-swe-agent를 추가로 실행한다. OfficeQA에서는 두 model family의 이전 release도 각 native harness에서 실행해, target model, seed, budget, coding harness를 고정한 채 optimizer model release만 바꾸는 capability ladder를 만든다. Held-out 평가는 각 test case당 세 번의 시도를 평균해 seed baseline의 $K=3$ pooling과 맞춘다. 이 paired design은 모델과 scaffold가 함께 바뀌는 자연스러운 제품 비교 대신, 한 축씩 고정해 원인을 분리하는 비교를 가능하게 한다.

Figure 2. 두 coding harness의 run별 normalized gain과 공통 harness에서 추정한 model effect.

왼쪽 패널은 두 harness를 통제한 설계의 모든 run을 task별 normalized gain으로 표시하며, marker 모양은 harness를 뜻하고 가로 offset은 겹침만 피한다. 오른쪽의 LSS-$\lambda$는 competent seed를 가진 세 task의 balanced shared-harness grid에서 계산한 task-adjusted model effect다. 공통 harness만 사용하므로 model effect에 native scaffold 차이가 섞이지 않는다. 중간 모델 간 차이는 재실행 변동보다 작을 수 있어 tier로 해석한다.

3.7 task 차이를 흡수하는 composite와 해상도 기준

Task별 normalized gain은 headroom 단위를 맞추지만 task가 체계적으로 쉬운지 어려운지까지 제거하지는 않는다. 공통 harness에서 model $m$, task $t$, replicate $r$의 gain을 $g_{mtr}$라 두고 먼저 qualifying replicate를 평균해 $\bar{g}_{mt}$를 만든다. 이어 configuration-level gain을 grand mean $\mu$, task effect $\tau_t$, optimizer model effect $\lambda_m$, residual $\varepsilon_{mt}$로 분해한다. Balanced grid이므로 $\widehat{\lambda}_m$은 해당 모델의 task 평균에서 모든 모델과 task의 grand mean을 뺀 값으로 계산된다.

$$ \bar{g}_{mt}= \frac{1}{|\mathcal{R}_{mt}|} \sum_{r\in\mathcal{R}_{mt}}g_{mtr}. $$ $$ \bar{g}_{mt}=\mu+\tau_t+\lambda_m+\varepsilon_{mt}, \qquad \sum_t\tau_t=0, \qquad \sum_m\lambda_m=0. $$ $$ \operatorname{LSS}_{\lambda}(m)=\widehat{\lambda}_m= \frac{1}{|\mathcal{T}|}\sum_{t\in\mathcal{T}}\bar{g}_{mt} - \frac{1}{|\mathcal{M}||\mathcal{T}|} \sum_{m'\in\mathcal{M}}\sum_{t\in\mathcal{T}}\bar{g}_{m't}. $$

LSS-$\lambda$는 평가된 모델 전체의 grand mean에 비해 한 모델이 task를 보정한 뒤 얼마나 높거나 낮은지를 normalized-gain unit으로 나타낸다. Primary score는 competent seed가 있는 세 task의 shared-harness run만 사용하고, GAIA와 native-harness run은 각각 baseline 성격과 scaffold 고정 원칙 때문에 제외한다. 해상도는 같은 candidate를 같은 사례에서 두 번 채점한 discrepancy의 중앙값을 held-out scoring의 $K=3$ gain scale로 옮긴 descriptive threshold이며 formal significance test가 아니다. 이 분석 protocol은 작은 순위 차이를 과해석하지 않고 model, task, harness 중 어떤 축이 측정값에 들어왔는지를 명시적으로 제한한다.

4. 실험 설정 — 모델·하네스·과제를 분리한 통제 설계

4.1 평가 그리드: 다섯 모델과 공통·네이티브 하네스

핵심 실험은 세 개발사의 최신 프런티어 모델 다섯 개, 즉 Claude Opus 5, Claude Sonnet 5, GPT-5.6-Sol, GPT-5.6-Terra, Kimi K3를 네 과제에 모두 투입한다. 각 모델은 모든 모델에 공통인 opencode와 해당 계열의 네이티브 코딩 하네스에서 각각 실행된다. Claude 계열의 네이티브 하네스는 claude-code, GPT 계열은 codex, Kimi K3는 kimi-cli이므로 핵심 그리드는 모델 5개와 하네스 조건 2개의 조합인 10개 optimizer configuration으로 구성된다. 이 설계는 모델을 바꿀 때 하네스를 고정하고, 하네스를 바꿀 때 모델을 고정할 수 있게 한다.

optimizer configuration은 단순한 언어모델 이름이 아닌 모델과 코딩 하네스의 쌍을 뜻한다. 같은 Claude Opus 5라도 opencode에서 움직이는 경우와 claude-code에서 움직이는 경우는 서로 다른 구성이다. 연구진은 GAIA에서만 goose와 mini-swe-agent를 모든 모델에 추가해 하네스 축을 네 수준으로 넓혔다. 또한 OfficeQA에서는 Claude Opus 계열과 GPT 계열의 과거 릴리스를 각자의 네이티브 하네스로 실행해 모델 세대 변화가 gain에 반영되는지 별도로 확인했다.

모델	표기	공통 하네스	네이티브 하네스	핵심 과제 수
Claude Opus 5	claude-opus-5	opencode	claude-code	4
Claude Sonnet 5	claude-sonnet-5	opencode	claude-code	4
GPT-5.6-Sol	gpt-5.6-sol	opencode	codex	4
GPT-5.6-Terra	gpt-5.6-terra	opencode	codex	4
Kimi K3	kimi-k3	opencode	kimi-cli	4

핵심 그리드의 각 optimizer configuration은 두 번 독립 실행되며, 표에 보고된 평균 옆 범위는 이 반복 실행에서 실제 관측된 최솟값과 최댓값이다. 이 범위는 두 번의 실행만으로 계산한 신뢰구간이 아니므로 통계적 불확실성처럼 해석하면 안 된다. 전체 보고에는 핵심 그리드, GAIA 추가 하네스, 세대 사다리 실험을 합쳐 111개 scored run이 포함된다. optimizer 모델의 추론 사용량은 계측하지만 상한을 두지 않아, 결과는 optimizer의 사고 토큰보다 target 평가 예산이 희소한 조건에서 달성 가능한 성능을 측정한다.

4.2 네 과제, 고정 split, 고정 seed baseline

각 과제는 target 모델, 실행 환경, 검증기, seed harness를 고정하며 optimizer가 수정할 수 있는 대상은 harness 코드뿐이다. 데이터는 개발·검증·테스트로 겹치지 않게 나뉘고, optimizer는 개발 데이터에서 입력·케이스별 결과·실행 trace를 보지만 검증 데이터에서는 집계 점수만 본다. 테스트 데이터와 점수는 탐색 중 완전히 차단되고 최종 후보를 지명한 뒤 trusted server가 한 번 평가한다. 따라서 개발 피드백을 이용한 수정, 검증 점수를 이용한 선택, 비공개 테스트를 이용한 일반화 측정이 역할별로 분리된다.

과제	고정 target 모델	split (개발/검증/테스트)	seed baseline	표준오차	gain resolution band
OfficeQA	deepseek-v4-flash	49 / 98 / 99	0.341	$\pm$0.023	$\pm$0.045
BrowseComp-Plus	deepseek-v4-flash	33 / 66 / 66	0.462	$\pm$0.020	$\pm$0.066
Terminal-Bench	grok-build	17 / 36 / 36	0.241	$\pm$0.009	$\pm$0.054
GAIA	gpt-5.4-mini	33 / 66 / 66	0.000	해당 없음	$\pm$0.035

OfficeQA, BrowseComp-Plus, Terminal-Bench의 seed는 작고 의도적으로 튜닝하지 않았지만 기본 기능은 수행하는 Python agent다. 반면 GAIA의 seed는 작동하지 않는 stub이므로 baseline은 실제로 측정된 0.000이고, 이 과제의 gain은 곧 최종 held-out raw score가 된다. 세 과제는 기존 agent를 개선하는 능력을, GAIA는 사실상 작동하는 agent를 처음부터 구성하는 능력을 더 강하게 묻는다. 이 차이 때문에 GAIA는 task-adjusted 모델 효과인 LSS-$\lambda$를 계산하는 주 분석에서 제외된다.

고정 seed가 충분한 headroom을 남기는지는 상용·오픈소스 하네스를 그대로 바꿔 끼운 참고 실험으로 확인한다. 동일한 target 모델과 split에서 가장 높은 off-the-shelf 점수는 OfficeQA의 mini-swe-agent 0.734$\pm$0.009, BrowseComp-Plus의 mini-swe-agent 0.701$\pm$0.009, Terminal-Bench의 opencode 0.607$\pm$0.030, GAIA의 openhands-sdk 0.508$\pm$0.029다. 이 수치는 optimizer 결과의 기준점이 아닌 seed 위에 실질적인 개선 여지가 존재한다는 맥락을 제공한다. normalized gain의 분모는 언제나 이 off-the-shelf 최고점이 아닌 표에 적힌 고정 seed baseline이다.

4.3 점수와 반복 평가: headroom을 얼마나 회수했는가

최종 성능은 raw score 차이가 아닌 남아 있던 headroom 중 얼마를 회수했는지를 나타내는 normalized gain으로 비교한다. 최종 후보를 $H^{+}$, 고정 seed를 $H_0$, 비공개 테스트에서의 기대 점수를 $\mathcal{E}_{\theta}(\cdot)$라 두면 정의는 $g=\frac{\mathcal{E}_{\theta}(H^{+})-\mathcal{E}_{\theta}(H_0)}{1-\mathcal{E}_{\theta}(H_0)}$이다. 예를 들어 $g=0.50$은 seed 위에 남은 최대 개선 폭의 절반을 회수했다는 뜻이며, 음수는 최종 지명 후보가 seed보다 나빠졌음을 뜻한다. GAIA에서는 baseline이 0이어서 이 식이 raw held-out score와 일치한다.

각 held-out test case는 세 번의 시도, 즉 $K=3$으로 평가되며 seed baseline도 같은 pooling 규칙으로 고정된다. 동일 후보를 같은 케이스에서 다시 채점했을 때의 중앙 discrepancy를 $K=3$ normalized-gain 척도로 옮겨 과제별 resolution band를 만든다. 이 band는 정식 유의성 검정이나 confidence interval이 아닌, 그보다 작은 차이는 현재 측정 해상도로 구분되지 않는다고 표시하는 기술적 문턱이다. 따라서 0.02의 차이는 OfficeQA의 $\pm$0.045나 BrowseComp-Plus의 $\pm$0.066보다 작다면 순위를 확정하는 근거가 되지 않는다.

partition	optimizer가 보는 정보	호출 상한	case-pass 상한	실험에서의 역할
개발	입력, 케이스별 결과, 실행 trace	100회	전체 데이터 4회 통과	오류 진단과 수정
검증	집계 점수만 공개	100회	전체 데이터 4회 통과	후보 비교와 선택
테스트	탐색 중 비공개	최종 지명 뒤 trusted server 평가	탐색 예산과 분리	실현된 일반화 gain 측정

예산은 호출 횟수 하나로만 정의되지 않고 평가 호출, 각 partition의 전체 case-pass, 소모 가능한 target-model token의 성분별 상한으로 구성된다. 개발과 검증은 각각 100회 호출과 네 번의 전체 case-pass를 허용하므로 호출 상한을 합치면 200회다. optimizer는 어떤 후보를 어떤 subset에 어느 fidelity로 평가할지 스스로 선택하며, 어느 한 성분이라도 다 쓰면 그 방향의 탐색이 막힌다. 이 다차원 제약 덕분에 단순히 평가 함수를 많이 호출하는 전략과 실제로 많은 케이스를 소비하는 전략을 구분할 수 있다.

실험 인프라는 이 비교가 코드 밖의 우회로로 오염되지 않도록 모든 후보를 격리된 sandbox에서 실행한다. optimizer가 만든 후보는 immutable Git commit으로 보존되고, dependency는 lockfile로 고정되며, model call은 trusted gateway를 지나면서 입력·cache·출력·총 token으로 계측된다. split은 겹치지 않는 committed manifest로 고정되고 생성기가 저장된 tree를 byte 단위로 검증하므로 run마다 쉬운 test case가 우연히 섞일 여지를 막는다. 이 기록 구조는 최종 점수에 더해 어떤 후보를 어느 partition에서 평가했고 예산을 얼마나 사용했는지까지 재실행 없이 감사할 수 있게 한다.

4.4 교차 과제 모델 점수 LSS-$\lambda$

과제마다 seed와 난도가 다르므로 normalized gain만으로도 모든 task effect가 사라지지는 않는다. 연구진은 공통 opencode에서 얻은 반복 평균 $\bar{g}_{mt}$를 $\bar{g}_{mt}=\mu+\tau_t+\lambda_m+\varepsilon_{mt}$로 분해하고, $\sum_t\tau_t=0$, $\sum_m\lambda_m=0$ 제약을 둔다. 균형 그리드에서 $\widehat{\lambda}_m$는 모델 $m$의 과제별 평균 gain에서 전체 모델·과제 grand mean을 뺀 값과 같다. LSS-$\lambda$는 이 $\widehat{\lambda}_m$를 사용하므로, 양수면 평가된 모델들의 평균보다 높고 음수면 낮다는 뜻이다.

주 LSS-$\lambda$는 competent seed를 가진 OfficeQA, BrowseComp-Plus, Terminal-Bench의 공통 하네스 15개 contestant row만 사용한다. 네이티브 하네스 run을 제외하는 이유는 모델 효과를 추정하면서 scaffold까지 동시에 바꾸지 않기 위해서다. 측정된 estimator resolution은 $\pm$0.058 gain unit이며 이 폭으로 tier를 나눈다. 같은 tier 안의 세부 순서는 그리드를 재실행할 때 움직이는 양보다 작으므로 완전한 서열로 읽지 않는 것이 맞다.

5. 주요 실험 결과 — 모델 격차, 과제별 gain, 세대 진전

5.1 전체 모델×하네스 gain: 한 행이 네 과제를 가로지른다

optimizer 모델	optimizer 하네스	OfficeQA	BrowseComp-Plus	Terminal-Bench	GAIA
Claude Opus 5	claude-code	0.59	0.41	0.18	0.42
Claude Opus 5	opencode	0.63	0.48	0.29	0.47
Claude Sonnet 5	claude-code	0.53	0.07	0.10	0.33
Claude Sonnet 5	opencode	0.51	0.15	0.15	0.25
GPT-5.6-Sol	codex	0.49	0.03	0.12	0.49
GPT-5.6-Sol	opencode	0.29	0.09	0.13	0.31
GPT-5.6-Terra	codex	0.07	-0.03	0.01	0.30
GPT-5.6-Terra	opencode	0.14	0.02	0.04	0.17
Kimi K3	kimi-cli	0.59	0.23	0.16	0.31
Kimi K3	opencode	0.41	0.16	0.12	0.28

Claude Opus 5 + opencode는 OfficeQA 0.63, BrowseComp-Plus 0.48, Terminal-Bench 0.29로 competent-seed 세 과제에서 모두 열 최고값을 기록한다. 이 값들은 각각 seed 위 headroom의 63%, 48%, 29%를 회수했다는 뜻이다. GAIA에서는 GPT-5.6-Sol + codex가 raw held-out score와 같은 gain 0.49로 최고다. 하나의 모델·하네스 조합이 모든 과제를 지배하지 않는다는 사실은 optimizer capability와 task–harness interaction을 함께 봐야 함을 보여준다.

하위권에서는 GPT-5.6-Terra + codex가 BrowseComp-Plus에서 -0.03을 기록해 seed보다 나쁜 후보를 지명했고, Terminal-Bench의 0.01도 $\pm$0.054 band 안이라 0과 구분되지 않는다. GPT-5.6-Terra + opencode의 BrowseComp-Plus 0.02와 Terminal-Bench 0.04 역시 각 band보다 작다. 반면 OfficeQA는 Claude Sonnet 5 + claude-code 0.53, Kimi K3 + kimi-cli 0.59처럼 여러 구성이 큰 gain을 낸다. 즉 모델 간 분리는 OfficeQA에서 선명하지만, 중간권의 세밀한 순위는 과제와 반복 변동에 따라 쉽게 달라진다.

반복 범위를 함께 보면 평균만으로는 숨겨지는 안정성 차이가 드러난다. 예를 들어 Claude Opus 5 + opencode의 OfficeQA gain은 0.60–0.67이고 BrowseComp-Plus는 0.42–0.55이며, Kimi K3 + opencode의 OfficeQA는 0.23–0.59로 훨씬 넓다. GPT-5.6-Terra + codex의 OfficeQA도 -0.04–0.17로 0을 가로지른다. 두 번의 실행 범위는 신뢰구간은 아니지만 평균 0.14만 보고 일관된 개선으로 단정하는 오류를 막아 준다.

gain이 높다고 target-model 사용량이 항상 더 큰 것도 아니다. OfficeQA에서 Claude Opus 5 + opencode는 gain 0.63에 target token 3.77M을 사용한 반면, 같은 모델의 claude-code 구성은 gain 0.59에 9.97M을 사용했다. BrowseComp-Plus의 Claude Opus 5 + opencode는 gain 0.48과 12.50M을 기록하지만 GPT-5.6-Terra + codex는 7.77M을 쓰고도 gain -0.03에 머문다. 이 값은 비용을 통제한 인과 ablation은 아니지만, 단순히 더 많은 target 추론을 소비한 구성이 자동으로 더 좋은 harness를 만든다는 설명과는 맞지 않는다.

5.2 모델 효과가 하네스 효과보다 1.8배 크다

과제와 하네스를 고정한 paired contrast에서 optimizer 모델을 바꾸면 gain이 평균 0.142 움직인다. 반대로 과제와 모델을 고정하고 공통·네이티브 하네스를 바꾸면 평균 이동량은 0.079이다. 두 값의 비는 1.8이므로 이 평가 범위에서는 모델 선택의 영향이 코딩 하네스 선택보다 약 1.8배 크다. 다만 0.079도 과제별 resolution band를 가까스로 넘기므로 하네스가 중요하지 않다는 결론은 성립하지 않는다.

optimizer 모델	LSS-$\lambda$ (gain unit)	tier	grand mean 대비 해석
Claude Opus 5	+0.228	1	뚜렷하게 높음
Claude Sonnet 5	+0.029	2	근소하게 높음
Kimi K3	-0.014	2	grand mean 부근
GPT-5.6-Sol	-0.069	2	낮지만 tier 2 내부
GPT-5.6-Terra	-0.174	3	뚜렷하게 낮음

task-adjusted LSS-$\lambda$에서도 Claude Opus 5가 +0.228로 tier 1, GPT-5.6-Terra가 -0.174로 tier 3에 놓여 양 극단은 명확히 갈린다. Claude Sonnet 5의 +0.029, Kimi K3의 -0.014, GPT-5.6-Sol의 -0.069는 모두 tier 2다. 이 세 값을 숫자 순서대로 2·3·4위로 고정하면 $\pm$0.058 estimator resolution을 무시하게 된다. task 내 gain 표준화와 mean within-group rank라는 두 보조 추정량도 같은 모델 순서를 만들었지만, 논문의 핵심 해석은 여전히 tier 사이의 분리이지 tier 내부의 정밀 순위가 아니다.

5.3 릴리스 사다리: benchmark가 모델 진전을 추적하는가

OfficeQA 세대 실험은 target 모델, seed, 평가 예산, 네이티브 코딩 하네스를 계열 안에서 고정하고 optimizer 모델 릴리스만 바꾼다. GPT 계열 다섯 릴리스의 gain은 0.03에서 0.49까지 단조 증가하며 네 번의 인접 이동 중 세 번이 OfficeQA resolution band $\pm$0.045를 넘는다. Claude Opus 계열 다섯 릴리스는 0.37에서 0.59 범위에 있고 중간에 하락해 단조롭지는 않다. 그래도 첫 릴리스와 마지막 릴리스의 차이는 resolution band보다 커서 최신 세대의 개선을 감지한다.

그림 3. 파란 Claude Opus 계열은 4.5의 약 0.37에서 4.6·4.7로 상승한 뒤 4.8에서 잠시 낮아지고 Opus 5에서 0.59에 도달한다. 주황 GPT 계열은 5.1의 0.03에서 GPT-5.6-Sol의 0.49까지 단조 상승한다. 아래 회색 띠는 OfficeQA resolution $\pm$0.045로, 작은 세대 차이와 측정 가능한 진전을 구분한다. 같은 하네스 안에서 릴리스만 바꿔 얻은 추세라 세대 효과의 귀속이 비교적 명확하다.

이 결과는 단 한 번의 최신 모델 비교보다 강한 sanity check를 제공한다. 특히 GPT 계열은 같은 native codex와 같은 OfficeQA 조건에서 세대가 진행될수록 harness optimization gain이 함께 올라, benchmark가 무작위 순위표가 아닌 capability 진전을 포착한다는 근거가 된다. Claude Opus 계열의 비단조성은 릴리스 번호가 모든 과제 능력을 일률적으로 올린다고 가정해서는 안 된다는 경고다. 세대 사다리의 목적은 절대적인 두 계열 비교가 아닌 한 계열 내부에서 optimizer 모델만 바꾼 통제 비교다.

5.4 과제별 난도와 성공 양상의 차이

OfficeQA의 최강 구성은 headroom의 약 3분의 2를 회수하지만 BrowseComp-Plus의 최강 구성은 절반에 못 미치고 Terminal-Bench는 0.29에 머문다. 동일한 Claude Opus 5 + opencode도 0.63, 0.48, 0.29로 과제에 따라 크게 달라진다. normalized gain이 공통 headroom 단위를 만들더라도 검색·터미널 조작·문서 질의의 구조적 차이까지 제거하지는 않는다. 이 때문에 논문은 서로 다른 과제의 셀을 단순 합산하기보다 task term을 둔 LSS-$\lambda$와 과제별 resolution을 함께 사용한다.

GAIA의 높은 숫자는 기존 competent seed를 다듬은 결과와 다른 의미를 갖는다. baseline 0의 stub에서 GPT-5.6-Sol + codex가 0.49를 얻었다는 것은 사용 가능한 agent를 구성해 49% raw held-out score를 냈다는 뜻이다. OfficeQA 0.63은 baseline 0.341에서 남은 headroom의 63%를 회수했다는 뜻이므로 두 숫자를 raw capability처럼 직접 비교하면 안 된다. GAIA는 이질적이지만, 모델과 하네스가 함께 작동하는 방식을 드러내는 중요한 stress test다.

6. 추가 분석 및 Ablation Study — 탐색 행동·하네스 상호작용·선택 편향

6.1 탐색 폭 ablation: 여덟 개 lever를 얼마나 건드렸는가

연구진은 OfficeQA 결과를 보기 전에 harness의 변경 지점을 prompt, context management, step cap, retry·timeout policy, tool schema, answer extraction, retrieval policy, reasoning effort의 여덟 lever로 등록했다. 각 optimizer가 탐색 중 이 가운데 얼마를 한 번이라도 검토하거나 수정했는지 비율을 계산하고 normalized gain과의 Spearman 상관을 과제별로 구했다. 이는 최종 제출물에 남은 변경 범위가 아닌 탐색 과정에서 건드린 범위다. 따라서 원본 seed를 최종 제출했더라도 중간에 여러 lever를 시험했다면 탐색 폭은 높게 측정될 수 있다.

그림 4. 가로축은 사전 등록한 여덟 lever 중 탐색 중 건드린 비율, 세로축은 normalized gain이다. Spearman $\rho$는 OfficeQA +0.88, BrowseComp-Plus +0.88, Terminal-Bench +0.65, GAIA +0.34로 네 과제 모두 양수다. 점의 색은 모델 계열, 모양은 코딩 하네스를 나타내며 회색 띠는 과제별 0 부근 resolution이다. 다만 점의 분산이 커 breadth 자체의 인과 효과와 총 탐색량 효과는 분리되지 않는다.

탐색 폭과 gain의 방향은 모든 과제에서 일관되지만 인과 효과로 읽을 수는 없다. lever coverage는 전체 수정량과도 상관되어 있어 폭넓게 탐색한 효과와 단순히 더 많은 작업을 한 효과가 분리되지 않는다. 실제로 한 구성은 lever의 75%를 건드리고 일곱 번 수정했지만 최종적으로 원본 seed를 제출했다. 그림이 지지하는 결론은 현재 optimizer 중 높은 gain을 낸 구성은 대체로 더 넓은 설계 공간을 탐색했다는 연관성까지다.

6.2 하네스 축 ablation: GAIA에서 순위가 교차한다

핵심 그리드의 공통 대 네이티브 비교 20개 model–task pair에서는 공통 하네스가 11번, 네이티브 하네스가 9번 이겼고 동률은 0번이다. 그중 차이가 각 과제 resolution band를 넘은 pair는 11개지만 승리 방향은 모델과 과제에 따라 달라진다. 따라서 평균적으로 거의 비겼다는 사실은 모든 pair의 효과가 작다는 뜻이 아닌 큰 양·음 효과가 상쇄됐다는 뜻이다. 네이티브 tooling이 항상 유리하다는 가정은 이 통제 비교에서 성립하지 않는다.

그림 5. 왼쪽은 GAIA에서 opencode·mini-swe-agent·goose를 거칠 때 모델별 선이 교차해 보편적 최고 하네스가 없음을 보여준다. 오른쪽은 각 모델의 네이티브 하네스에서 얻은 gain과 최고 shared harness의 차이다. GPT-5.6-Sol은 +0.179, GPT-5.6-Terra는 +0.131로 codex 이점이 크지만 Claude와 Kimi는 $\pm$0.035 band 주변이다. 모델과 하네스의 결합에 따라 이점의 부호까지 바뀐다는 뜻이다.

optimizer 모델	opencode	mini-swe-agent	goose	네이티브 하네스	native − best shared
Claude Opus 5	0.47	0.36	0.31	claude-code 0.42	-0.051
Claude Sonnet 5	0.25	0.20	0.27	claude-code 0.33	+0.056
GPT-5.6-Sol	0.31	0.30	0.20	codex 0.49	+0.179
GPT-5.6-Terra	0.17	0.16	0.17	codex 0.30	+0.131
Kimi K3	0.28	0.34 (1 run)	0.24 (1 run)	kimi-cli 0.31	-0.033

GAIA는 모든 모델이 opencode, goose, mini-swe-agent, 자기 네이티브 하네스에서 실행된 유일한 과제다. GPT-5.6-Sol과 GPT-5.6-Terra는 codex에서 각각 최고 shared harness보다 0.179와 0.131 높아 resolution band의 약 다섯 배와 네 배에 이르는 실질적 차이를 보인다. 반대로 Claude Opus 5는 native claude-code가 best shared보다 0.051 낮고 Kimi K3는 0.033 낮다. shared 하네스만 보면 capability가 높을수록 harness sensitivity가 커 보이지만 native 조건을 추가하면 그 패턴이 사라진다는 점이 핵심 상호작용이다.

6.3 validation–held-out ablation: 보이는 최고점은 낙관적이다

optimizer는 validation aggregate score를 보면서 후보를 선택하지만 최종 목적은 비공개 test score다. 후보를 여러 번 시험한 뒤 가장 높은 validation 관측값을 기준으로 고르면 noise가 좋은 방향으로 나타난 후보가 선택될 수 있다. 연구진은 각 셀의 탐색 중 best validation score와 최종 제출 후보의 held-out test score를 직접 대응시켰다. 이 비교는 selection-induced overfitting과 validation–test distribution mismatch를 구별하지는 못하지만, 선택에 보인 수치가 실제 배포 성능을 얼마나 낙관적으로 보이는지는 점검한다.

그림 6. 가로축은 탐색 중 관측한 최고 validation score, 세로축은 제출 후보의 held-out test score이며 점선은 두 값이 같은 identity line이다. 다수의 점이 점선 아래에 있어 보이는 최고 validation 성능이 실제 test 성능보다 높다. 색과 모양은 각각 모델 계열과 하네스를 구분하며, 이 분산은 비공개 test가 필요한 이유를 직접 보여준다. 보이는 최고점만으로 후보를 고르면 selection noise를 실제 일반화로 오인할 수 있다.

점선 아래의 셀이 많다는 관찰은 validation 최고점을 최종 성능처럼 보고하면 gain을 과대평가할 위험이 있음을 뜻한다. 특히 한정된 validation set에 여러 후보를 반복 대입할수록 최대 관측값은 selection pressure의 영향을 받는다. 그러나 이 그림만으로 optimizer가 validation에 과적합했다고 단정할 수는 없고, 두 partition의 사례 구성이 달라 생긴 mismatch일 수도 있다. 논문이 주장하는 범위는 visible best validation score가 realized held-out score에 비해 낙관적이며 최종 비공개 평가가 필수라는 데 한정된다.

6.4 trace 사용과 예산 ablation: 호출 횟수보다 case-pass가 먼저 묶인다

탐색 행동 분석에서 평가 출력을 읽는 action의 비중과 gain의 Spearman $\rho$는 과제별로 -0.64에서 -0.31 사이여서 모두 음수였다. 가장 상세한 trace span 조회는 111개 scored cell 가운데 7개 cell에서 총 16번만 호출됐다. optimizer는 대체로 전체 trace보다 케이스별 score summary에 의존했고, 더 많이 읽은 구성이 더 높은 gain을 보이지 않았다. 이 결과는 trace 진단이 불필요하다는 증명이 아닌, 현재 과제에서는 상세 trace의 context 비용보다 summary의 국소화 정보가 더 효율적이었을 가능성을 보여준다.

그림 7. 회색 막대는 evaluation-call 상한 소비율, 파란 막대는 case-pass 상한 소비율의 중앙값이며 서로 다른 분모를 쓴다. 전체 중앙값은 호출 4%와 case-pass 82%로 크게 갈린다. 오른쪽 주석은 case-pass 소진 셀을 표시하며 전체 55/100, native 33/60, common 22/40으로 호출 수가 아닌 사례 처리량이 실제 병목임을 보여준다. 한 호출에 넣은 사례 수를 분리해야 실질 계산량과 피드백 해상도를 비교할 수 있다.

분석 항목	상한 또는 관측값	정확한 수치	해석
evaluation call 예산	개발 100회 + 검증 100회	총 200회	두 partition의 호출 상한
중앙 evaluation call 사용	8회	상한의 4%	호출 상한은 여유가 큼
case-pass 예산	개발 4회 + 검증 4회	각 partition 4 full passes	성분별로 따로 제한
중앙 case-pass 사용	허용량 대비	82%	실제 탐색에서 높은 소비
case-pass 소진	분석 가능한 100개 cell	55/100	적어도 한 partition 예산 소진
하네스별 소진	native / common	33/60 / 22/40	두 scope 모두 55% 소진
과제별 소진	OfficeQA / BrowseComp-Plus	11/20 / 11/20	각각 55%
과제별 소진	Terminal-Bench / GAIA	12/20 / 21/40	각각 60% / 52.5%
상세 trace span 조회	111개 scored cell 중 7개	총 16회	깊은 trace 조회는 드묾
trace-reading 비중과 gain	과제별 Spearman $\rho$ 범위	-0.64 ~ -0.31	네 과제 모두 음의 방향

중앙 optimizer는 허용된 200회 호출 중 8회만 사용해 call cap의 4%를 소비했지만 case allowance는 82%를 사용했다. 분석 가능한 100개 cell 중 55개가 개발 또는 검증 중 적어도 한 partition의 case-pass 예산을 모두 썼고, task별로는 OfficeQA 11/20, BrowseComp-Plus 11/20, Terminal-Bench 12/20, GAIA 21/40이다. 공통 하네스와 네이티브 하네스도 각각 22/40과 33/60으로 정확히 55%가 소진돼 특정 scaffold만의 현상이 아니다. 따라서 후속 benchmark가 탐색 강도를 조절하려면 evaluation API 호출 수보다 실제로 처리한 case 수와 full-pass allowance를 우선 설계해야 한다.

6.5 추가 분석을 종합하면: 완전 순위보다 상호작용과 측정 해상도

통제 축별 분석은 세 가지 결론을 함께 만든다. 첫째, 모델 교체 효과 0.142는 하네스 교체 효과 0.079보다 크지만 GAIA의 GPT–codex 결합처럼 특정 상호작용은 평균을 훨씬 넘어선다. 둘째, 넓은 lever 탐색은 모든 과제에서 gain과 양의 상관을 보이지만 상세 trace reading은 같은 일관된 이점을 보이지 않는다. 셋째, validation 최고점과 held-out 성능의 간극 및 case-pass 병목은 optimizer가 코드를 잘 쓰는 능력에 더해 noisy evidence 아래에서 실험을 선택하는 능력도 평가 대상임을 보여준다.

이 논문의 ablation은 단일 prompt 문구를 하나씩 제거하는 전통적 component ablation보다 모델·코딩 하네스·릴리스·탐색 행동·정보 사용·예산 축을 고정하거나 교체하는 controlled contrast에 가깝다. 그 결과 Claude Opus 5의 우세처럼 resolution을 넘어서는 큰 차이는 믿을 수 있지만 tier 2 내부나 작은 하네스 차이는 확정 순위로 만들지 않는다. 또한 GAIA를 LSS-$\lambda$에서 제외하고 별도 interaction 분석으로 다루어 measured-zero stub와 competent seed를 억지로 같은 척도에 합치지 않는다. HarnessOpt-Bench의 결과를 읽을 때 가장 중요한 단위는 단독 모델명이 아닌 과제, 모델, optimizer harness, 평가 예산이 함께 정의하는 configuration이다.

7. 한계점 및 향후 연구 방향: 고정된 평가에서 얻은 개선은 어디까지 일반화되는가

HarnessOpt-Bench가 닫으려는 질문은 명확하다. 최적화 모델이 개발·검증 피드백을 이용해 에이전트 코드를 고친 뒤, 보지 못한 테스트 분할에서도 기준 하네스보다 높은 보상을 내는가를 묻는다. 테스트 데이터, 대상 모델, 실행 환경, 검증기를 최적화 모델이 직접 바꾸지 못하게 하고 모든 후보를 불변 Git 커밋으로 남긴 설계는 단순한 점수 조작을 어렵게 만든다. 그러나 저자들이 표현했듯 이 벤치마크는 hack-resistant이지 hackproof는 아니다. 고정된 개발·검증 사례와 도구 동작, 검증기 구현에서 피드백을 반복해서 받으면 일반적인 하네스 원리보다 그 평가기의 안정된 흔적에 맞춘 전략이 선택될 수 있다.

7.1. 테스트 분할 은닉만으로 평가기 일반화가 보장되지는 않는다

가장 먼저 구분해야 할 것은 사례 일반화와 평가기 일반화이다. 현재 프로토콜은 같은 과제·도구·검증기 계열 안에서 사례를 개발 20%, 검증 40%, 테스트 40%로 나누고 테스트를 숨긴다. 이는 개발 사례를 외우는 후보를 걸러 내지만, 공개된 검증 점수의 오류 구조나 timeout 관례, 답 추출 규칙, 도구 응답 형식에 맞춘 코드는 테스트에서도 이득을 유지할 수 있다. 검증과 테스트가 동일한 평가 계약을 공유하기 때문이다. 제출 후보의 테스트 점수가 탐색 중 관측한 최고 검증 점수보다 대체로 낮다는 결과도 선택 과정의 낙관성을 보여 주지만, 현재 그림만으로는 반복 선택에 따른 과적합과 검증–테스트 분포 불일치를 분리할 수 없다.

저자들이 제안한 직접적인 보완은 실행마다 사례, 도구 동작, 검증기 구현에 작은 무작위 변동을 주는 것이다. 여기서 변동은 정답 의미를 바꾸는 노이즈가 아닌, 같은 능력을 여러 등가 표면에서 확인하는 의미 보존형 jitter여야 한다. 예를 들어 도구 응답의 필드 순서·무관 문구·지연 분포를 바꾸고, 답 검증은 독립 구현 두 개가 같은 의미 판정을 내리도록 할 수 있다. 후보를 제출한 뒤에는 개발 중 한 번도 쓰지 않은 검증기와 도구 wrapper에서 재평가해, 고정 구현에서 얻은 이득과 구현을 넘겨 유지되는 이득을 따로 보고해야 한다.

7.2. seed harness는 중립적 출발점이 아닌 강한 과제별 사전정보다

두 번째 경계는 시작 코드의 완성도다. GAIA는 baseline이 0인 비기능 stub에서 출발하므로 최적화 모델이 사실상 에이전트를 건설하는 능력을 시험한다. 반대로 성숙한 seed를 고치는 과제는 이미 들어 있는 구조를 진단하고 제한된 headroom을 회수하는 능력을 더 강하게 본다. 두 체제는 같은 ‘하네스 최적화’라는 이름 아래 있어도 요구되는 탐색이 다르다. stub에서는 최소 실행 경로를 만드는 큰 편집이 유리할 수 있고, 성숙한 seed에서는 context 관리, 재시도, 답 추출처럼 작은 정책 변경이 더 중요할 수 있다.

현재 suite에는 두 체제가 함께 있지만 seed 복잡도를 체계적으로 조작하지 않는다. 따라서 과제 효과를 통제한 모델 항인 $LSS-\lambda$도 이 네 과제와 현재 seed 분포에 대한 상대적 추정치로 읽어야 한다. 후속 연구에서는 동일 과제마다 빈 stub, 최소 기능 버전, 중간 수준 버전, 성숙한 버전의 완성도 사다리를 만들고 공개 API·도구 권한·대상 모델·평가 예산을 고정해야 한다. 사다리별 normalized gain, 제출 성공률, 원본 seed를 그대로 낸 비율, 탐색한 lever 수를 함께 보면 어떤 모델이 건설에 강하고 어떤 모델이 정밀 진단에 강한지 분리할 수 있다.

7.3. 더 많은 탐색과 더 좋은 진단을 인과관계로 읽으면 안 된다

OfficeQA에서 먼저 정의한 여덟 lever, 즉 prompt, context management, step cap, retry·timeout, tool schema, answer extraction, retrieval policy, reasoning effort 가운데 탐색 중 건드린 비율은 네 과제 모두 gain과 양의 Spearman 상관을 보였고 $\rho$ 범위는 $+0.34$에서 $+0.88$이었다. 반면 평가 출력을 읽는 행동 비중은 $-0.64$에서 $-0.31$ 범위의 음의 상관을 보였다. 상세 trace span 요청도 111개 scored cell 중 7개 cell에서 총 16회에 그쳤다. 이 결과만 보면 넓게 편집하고 trace를 덜 읽는 전략이 정답처럼 보일 수 있다.

하지만 lever breadth는 총 수정량과 함께 움직이며, 어떤 lever를 살펴본 뒤 변경을 폐기한 경우도 포함한다. trace 읽기 역시 난도가 높아 실패가 누적된 실행에서 늘어났을 수 있어 역인과 가능성이 있다. 따라서 이 상관은 ‘진단이 불필요하다’거나 ‘여덟 lever를 모두 수정하면 gain이 오른다’는 처방이 아니다. 후속 실험은 같은 모델·과제·seed에서 탐색 순서만 무작위화하고, 허용 lever 수와 trace 요약의 정보량을 요인 설계로 조작해야 한다. 같은 case-pass 예산 아래 최종 held-out gain과 토큰당 gain을 비교해야 breadth 자체의 효과와 단순한 search effort를 분리할 수 있다.

Figure 8: 과제별 optimizer token 탐색 비용과 normalized gain의 관계

가로축은 로그 눈금의 optimizer token 수, 세로축은 normalized gain이며, 채워진 점은 각 과제에서 비용은 더 낮고 gain은 더 높은 다른 후보가 없는 비지배 전선을 뜻한다. 회색 ×로 표시된 후보가 많고 전선의 모양도 네 과제마다 달라, 토큰을 더 쓰면 성능이 단조롭게 오른다고 말할 수 없다. 이 그림은 최고 gain과 별도로 비용 대비 탐색 효율을 보고해야 함을 보여 준다. 같은 gain을 더 싼 비용으로 얻는 후보와 같은 비용에서 더 높은 gain을 얻는 후보가 전선을 이룬다.

7.4. 실제 병목은 evaluation call 수보다 case-pass 예산이다

개발 분할과 검증 분할은 각각 최대 200회의 평가 호출과 네 번의 전체 case pass를 허용한다. 그러나 optimizer가 사용한 평가 호출 중앙값은 8회, 호출 한도의 4%에 불과한 반면 case allowance의 중앙 사용률은 82%였다. 100개 cell 중 55개는 적어도 한 분할에서 case-pass 예산을 소진했다. 호출 횟수만 맞추면 계산 조건이 공정하다고 보기 어려운 이유다. 한 호출에 적은 사례를 넣어 자주 확인하는 전략과, 한 번에 많은 사례를 통과시키는 전략은 같은 호출 수에서도 소비 계산량과 피드백 해상도가 다르다.

다음 버전은 평가 호출, 고유 사례 수, 누적 case pass, optimizer 입력·캐시·출력 토큰, 대상 에이전트의 추론 토큰을 분리해 공개해야 한다. 예산 비교도 단일 상한보다 여러 비용 등고선에서 이루어져야 한다. Figure 8에서 비지배 전선 밖의 후보를 단순 실패로 부르기보다, 같은 gain에서 더 비싼 후보와 같은 비용에서 더 낮은 후보로 구분하면 optimizer의 운영 효율을 읽을 수 있다. 특히 저렴한 탐색이 우연히 좋은 후보를 한 번 찾았는지 확인하려면 비용 수준별 반복 수를 맞추고 전선의 불확실성 구간을 추정해야 한다.

7.5. 언어·런타임·대상 모델을 넘는 외적 타당도는 아직 열려 있다

모든 후보는 Python으로 제한되고, 각 과제는 하나의 pinned target model을 사용한다. 이 선택은 비교 중 대상 능력이 바뀌는 교란을 막지만, 얻은 결과가 TypeScript 기반 브라우저 에이전트, JVM 서비스, GUI 중심 구조, multi-agent runtime, 다른 target model에서도 유지되는지는 말해 주지 않는다. optimizer model을 바꾼 평균 효과 0.142가 coding harness를 바꾼 0.079보다 약 1.8배 컸다는 결과도 현재 언어와 도구 생태계 안의 paired contrast다. 이를 모델 고유의 보편적 하네스 설계 능력으로 확대하려면 언어·runtime·agent architecture를 교차한 반복이 필요하다.

native harness가 자동으로 우세하지 않았다는 결과 역시 방향이 없다는 뜻과 효과가 없다는 뜻을 구분해야 한다. 20개 model–task pair에서 공통 OpenCode가 11회, native harness가 9회 이겼고 tie는 없었다. 이 중 11개 pair는 차이가 과제 resolution band를 넘었지만 방향이 모델과 과제에 따라 바뀌었다. 그러므로 native tooling만 사용한 단일 리더보드는 최적화 능력을 안정적으로 추정하지 못한다. 최소한 하나의 공통 harness와 하나의 native harness를 함께 돌리고, target model도 둘 이상으로 복제해 optimizer–harness–target의 상호작용을 별도 항으로 추정해야 한다.

한계–검증 매핑. 현재 결과의 증거 범위와 다음 실험에서 닫아야 할 판정 기준

남은 한계	현재 관찰	후속 조작	통과 기준
고정 평가기 특화	best validation score가 제출 후보의 test score보다 대체로 낙관적	의미 보존형 tool·case jitter와 독립 verifier 구현	동일 평가기 gain에 더해 미관측 평가기 gain이 resolution band를 넘음
seed prior 의존	비기능 GAIA stub와 성숙 seed가 한 suite에 혼재	동일 과제의 stub–최소 기능–중간–성숙 seed 사다리	완성도별 성능 곡선과 실패 유형이 반복 실행에서 재현됨
탐색 폭의 인과성	lever breadth와 gain의 $\rho=+0.34\sim+0.88$	lever 수와 탐색 순서를 무작위 배정하고 case-pass를 고정	총 수정량·토큰을 통제한 뒤에도 breadth 효과가 유지됨
비용 비교의 불완전성	호출 한도 사용률 4%, case allowance 사용률 82%	여러 case-pass·token budget에서 같은 cell을 반복	비용별 비지배 전선과 불확실성 구간이 안정적으로 재현됨
외적 타당도	Python 후보와 과제별 단일 pinned target model	언어·runtime·target model의 교차 복제	optimizer 효과와 상호작용을 분리하고 새 조건에서도 부호가 유지됨

표의 통과 기준은 더 큰 평균 점수를 요구하는 목록이 아니다. 현재 claim을 흔드는 대안 설명을 하나씩 제거하기 위한 식별 조건이다. 특히 resolution band보다 작은 차이는 완전한 순위로 배열하지 말고 같은 tier로 남겨야 한다. balanced scope에서 보고된 $LSS-\lambda$도 claude-opus-5가 $+0.228$인 tier 1, claude-sonnet-5 $+0.029$, kimi-k3 $-0.014$, gpt-5.6-sol $-0.069$가 tier 2, gpt-5.6-terra $-0.174$가 tier 3이라는 수준까지가 안전하다. tier 내부의 미세 순위는 재실행 변동으로 해소되지 않았다.

7.6. 안전한 최적화라는 운영 가정도 평가 대상이어야 한다

에이전트 코드를 자동으로 고치는 능력은 양면적이다. 같은 기술이 문서 QA나 터미널 작업의 오류를 수리할 수도 있고, 유해한 에이전트의 실행력을 강화하는 데 쓰일 수도 있다. 이 논문은 대상을 문서 QA, deep research, multi-step reasoning, terminal use의 제한된 양성 과제로 묶고, trusted harness가 비용을 계량하며 모든 변경을 버전 관리하고, 고정 target model을 allow-list 뒤에 둔다. 점수도 held-out split의 과제 verifier에서만 나온다. 이 경계 안에서는 새 도구나 자원 획득을 보상하지 않는다.

다만 ‘trusted’라는 이름만으로 신뢰가 생기지는 않는다. evaluator hijacking이나 judge prompt injection을 막으려면 네트워크 egress, 자격증명, 파일 권한, verifier 프로세스가 optimizer와 실제로 분리되어 있음을 실행 로그로 증명해야 한다. 후속 공개본은 후보 diff와 점수에 더해 차단된 시스템 호출, allow-list 위반, sandbox 탈출 시도, verifier 입력 오염을 표준 failure category로 보고할 필요가 있다. 성능 gain과 안전 경계 위반률을 동시에 공개해야 자동 하네스 개선이 어떤 운영 조건에서 허용 가능한지 판단할 수 있다.

8. 내 해석: 약점 1 + 후속 제안 1: 평가기 전이를 직접 시험하는 이중 홀드아웃

나는 논문 저자 팀 바깥에서 에이전트 평가를 운영하는 입장에서, 가장 큰 약점을 숨긴 사례에 대한 개선과 숨긴 평가 계약에 대한 개선을 분리하지 못한 점으로 본다. 테스트 40%를 가려도 개발·검증·테스트가 같은 도구와 verifier 계보를 공유하면 고정 평가기의 습관을 학습한 후보가 일반적 하네스 원리처럼 보일 수 있다. 이는 Rethinking the Evaluation of Harness Evolution이 반복 탐색 예산과 held-out task 일반화를 분리하라고 요구한 맥락과 맞닿지만, HarnessOpt-Bench의 현재 held-out reward만으로 그 문제를 완전히 닫지는 못한다.

내가 후속으로 실행할 한 가지 제안은 사례×평가 계약 이중 홀드아웃이다. target model, seed, optimizer harness, case-pass·token budget을 고정하고, 의미는 같지만 tool wrapper·timeout jitter·답 추출·verifier 구현이 독립인 계약 A와 B를 만든다. optimizer에는 A의 개발·검증만 보인 뒤 후보를 동결하고 A-test와 B-test의 gain, 전이 보존율 $R=\Delta G_B/\max(\Delta G_A,\epsilon)$, 비용당 gain을 비교한다. OpenForge RL처럼 배포 하네스 trajectory를 학습에 넣기 전에도 이 전이 검사를 거치고, LongHorizon-Harness의 도구·상태·감사 계약을 B의 조작 축으로 쓰면 학습 이득과 장기 운영 구조를 같은 검증 언어로 연결할 수 있다. $\Delta G_A$만 resolution band를 넘고 $\Delta G_B$가 0 이하라면 일반 개선 주장을 기각하겠다.

9. 결론: 에이전트를 개선하는 능력을 별도의 경험적 대상으로 만들다

HarnessOpt-Bench의 가장 중요한 기여는 하네스 엔지니어링을 모델 밖의 수작업 인프라로 남겨 두지 않고, 모델이 진단하고 수정하며 held-out reward로 개선을 증명해야 하는 능력으로 바꾼 데 있다. 네 과제에서 현재 frontier optimizer들은 실제로 gain을 만들었지만 그 크기는 과제와 seed, optimizer model, optimizer를 감싼 coding harness에 따라 달랐다. 모델 교체 효과 0.142가 harness 교체 효과 0.079보다 컸다는 결과는 최적화 모델 선택이 중요함을 보여 주면서도, harness 효과가 resolution band를 가까스로 넘을 만큼 실재한다는 점을 함께 남긴다.

성과는 완전한 서열보다 세 층의 결론으로 읽는 편이 정확하다. 첫째, 강한 모델은 대체로 더 넓은 lever를 탐색하고 일부 과제에서 남은 headroom의 큰 부분을 회수한다. 둘째, 중간권 구성의 차이는 반복 변동보다 작아 tier 내부 순위를 해소하지 못한다. 셋째, native harness의 우위는 일관된 기본값이 아니며, GAIA처럼 harness 축을 넓혀 보면 모델별 순위 교차가 드러난다. 따라서 ‘어떤 모델이 언제나 최고인가’보다 ‘어떤 모델–harness 조합이 어느 과제와 seed 체제에서 재현 가능한 개선을 만드는가’가 이 벤치마크가 실제로 답하는 질문이다.

탐색 과정에 대한 진단도 운영상 유용하다. 여덟 lever를 폭넓게 살펴보는 행동은 모든 과제에서 gain과 같은 방향으로 움직였지만, 상세 trace 읽기는 그렇지 않았다. 평가 호출 200회 한도보다 네 번의 case pass가 먼저 묶였고, visible validation best는 제출 후보의 held-out 성능에 비해 낙관적이었다. 이는 차기 optimizer가 호출 횟수를 늘리기보다 제한된 사례 예산에서 가설을 넓게 세우고, 요약 피드백과 정밀 trace를 실패 유형에 따라 선택하며, validation best를 그대로 신뢰하지 않는 선택 규칙을 가져야 함을 시사한다. 다만 상관 분석을 설계 처방으로 확정하려면 무작위 절제 실험이 더 필요하다.

결국 이 논문이 확립한 것은 포괄적인 tool-integrated reasoning 점수가 아닌, 제한된 Python 하네스와 pinned target model, 네 과제, 고정 budget 아래에서 측정한 에이전트 개선 능력의 첫 재현 가능한 단면이다. 다음 단계는 과제 수만 늘리는 데 그치지 않는다. 평가기 jitter와 독립 구현, seed 완성도 사다리, 다중 언어·runtime, target model 교차, 비용별 반복, 안전 경계 감사를 함께 넣어야 한다. 이러한 조건에서도 held-out gain이 유지될 때 ‘더 좋은 에이전트’에서 한 걸음 더 나아가 ‘에이전트를 안정적으로 더 좋게 만드는 모델’이라는 결론이 성립한다.

10. 요약 정리: 수치와 해석을 함께 남기는 열 가지 기준

• 평가 대상: HarnessOpt-Bench는 완성된 에이전트의 정답률만 재는 벤치마크가 아닌, optimizer model이 seed agent의 Python 코드를 진단·수정해 held-out reward를 높이는 능력을 측정한다.
• suite 범위: OfficeQA, BrowseComp-Plus, Terminal-Bench, GAIA의 네 과제를 사용하며, GAIA는 baseline 0의 비기능 stub라 normalized gain이 사실상 raw held-out score로 읽힌다.
• 비교 원칙: 점수 차이는 과제별 resolution band와 반복 범위를 함께 보아야 하며, band보다 작은 중간권 차이는 완전한 순위가 아닌 같은 tier로 남겨야 한다.
• 주요 축: 과제와 harness를 고정하고 optimizer model을 바꾼 평균 gain 변화는 0.142, 과제와 model을 고정하고 coding harness를 바꾼 변화는 0.079로 model 축이 약 1.8배 컸다.
• 탐색 과정: 여덟 harness lever 중 탐색한 비율은 네 과제에서 gain과 $\rho=+0.34\sim+0.88$의 양의 상관을 보였지만, 총 수정량과 탐색 노력의 효과를 분리하지 못해 인과 처방으로 볼 수 없다.
• trace 해석: 평가 출력 읽기 비중은 gain과 $\rho=-0.64\sim-0.31$이었고 상세 span은 111개 cell 중 7개에서 16회만 요청되었으나, 이것이 정밀 진단의 무용성을 증명하지는 않는다.
• 실제 예산 병목: 평가 호출은 중앙값 8회로 200회 한도의 4%만 사용했지만 case allowance는 82%가 소비되었고 100개 cell 중 55개가 적어도 한 분할의 case-pass 예산을 소진했다.
• harness 상호작용: 20개 paired 비교에서 공통 OpenCode가 11회, native harness가 9회 이겼고 11개 차이가 resolution band를 넘었다. 집계상 근소한 차이는 효과 부재가 아닌 방향이 뒤섞인 이질성을 뜻한다.
• 핵심 한계: 고정 evaluator 특화, seed 완성도 prior, Python·단일 target model 범위, 비용별 반복 부족 때문에 현재 $LSS-\lambda$와 gain은 이 suite의 상대적 결과로 제한해 읽어야 한다.
• 다음 검증: 의미 보존형 evaluator jitter와 독립 verifier, seed 완성도 사다리, 언어·runtime·target 교차, 비용별 비지배 전선, 안전 경계 로그를 함께 통과해야 일반적인 ‘에이전트 개선 능력’ 주장으로 확장할 수 있다.