HarnessOpt-Bench: Evaluating LLMs at Harness Optimization 요약 설명

목차

• 요약
• Introduction
• Related Work
• HarnessOpt-Bench: Harness Optimization as a Task
• The optimization problem
• The HarnessOpt-Bench suite
• Experimental Setup
• Results
• Distinguishing frontier models
• Tracking model progress
• Where current optimizers fall short
• The effect of the optimizer’s own harness
• Conclusion
• Full optimizer results
• The suite
• Model effects
• Supporting figures
• Reproducibility
• 부록
• 짧은 생각

이번 글에서는 HarnessOpt-Bench: Evaluating LLMs at Harness Optimization 논문의 핵심 포인트만 간단히 정리한다.

• 2026년 8월 6일(Arxiv), arXiv
• Ursekar, Varun, Shanker, Apaar, Maurya, Yash, Yasser, Shehab, Kalmath, Vijay S., Chatrath, Veronica, Xue, Yuan.
• Scale AI
• 논문 링크

요약

• HARNESSOPT-BENCH는 프롬프트, 도구, 제어 흐름, 문맥·메모리 관리, 오케스트레이션 코드로 구성된 에이전트 하네스를 LLM이 개선하는 능력을 측정한다. 최적화기인 ‘코딩 하네스와 결합한 LLM’은 시드 하네스를 편집하고 개발 분할의 사례별 결과·실행 추적, 검증 분할의 집계 점수, 고정된 대상 에이전트 평가 예산을 이용해 최종 후보를 지명한다. 탐색 중 접근할 수 없는 보류 테스트에서 시드 대비 정규화 이득으로 후보를 평가하며, 신뢰 실행 환경이 테스트 접근 차단, 자원 계량, 후보 버전 보존을 강제한다. 저자들은 네 과제에서 최전선 LLM 5개와 공통·네이티브 코딩 하네스를 포함한 111회 채점 실행을 비교해, 평균적으로 최적화기 모델 차이가 코딩 하네스 차이보다 크고 네이티브 하네스가 일관되게 우세하지 않으며 이득은 과제와 시드 체제에 따라 크게 달라짐을 보였다.

Introduction

• 같은 언어 모델도 어떤 하네스에 배치되는지에 따라 능력이 크게 달라지므로, 고정 예산 아래 측정된 결과를 바탕으로 하네스를 반복 개선하는 작업은 에이전트 구축에서 중요하다. 그러나 하네스 변경의 효과는 확률적 에이전트를 여러 사례에서 실행해야 추정할 수 있어 비용이 크고 잡음이 있다. 최적화기는 불완전한 증거로 실패를 진단하고, 시스템 수준 변경을 구현하며, 제한된 평가 예산을 배분하고, 우연한 상승과 실제 개선을 구별해 배포 후보를 선택해야 한다. 논문은 대상 모델·환경·검증기를 고정하고, 탐색 내내 최종 평가를 보류하며, 실행 환경이 예산과 접근 경계를 강제해야 모델 자체, 코딩 하네스, 목표 에이전트, 평가 규약의 효과를 분리할 수 있다고 본다.
  • 연구 질문은 최전선 모델을 하네스 최적화 능력으로 구별할 수 있는지, 현재 최적화기가 어떤 한계를 보이는지, 최적화기 자신이 쓰는 코딩 하네스가 모델에 비해 얼마나 기여하는지이다.
  • 기여는 공통 최적화 문제와 고정 분할을 갖춘 벤치마크, 감사 가능한 신뢰 실행 프로토콜, 모델·코딩 하네스를 통제한 비교, 그리고 탐색 궤적에서 도출한 역량 공백의 분석으로 구성된다.

Related Work

• 기존 연구는 LLM을 진화·탐색 절차 안의 돌연변이 연산자로 사용하거나, 프롬프트와 문맥 산출물 같은 텍스트 구성 요소를 최적화하거나, 에이전트 프로그램 전체를 코드로 탐색한다. DSPy, TextGrad, GEPA는 주로 프롬프트 또는 텍스트 산출물을 다루고, STOP, ADAS, AFlow와 재귀적 자기개선 연구는 탐색 공간을 프로그램·에이전트 설계까지 확장한다. VeRO와 MetaHarness는 코딩 에이전트가 소스 코드, 이전 점수, 실행 추적을 읽고 평가할 대상을 선택하면서 하네스 코드베이스를 종단간 편집한다는 점에서 이 벤치마크가 측정하는 상황과 가깝다. HARNESSOPT-BENCH는 특정 최적화 알고리즘을 제안하기보다 시드, 예산, 탐색 공간, 공개 정책, 점수 규약을 고정해 이러한 시스템을 같은 조건에서 비교하도록 설계했다.

HarnessOpt-Bench: Harness Optimization as a Task

• 이 벤치마크는 하네스 개선을 제약된 확률적 프로그램 최적화로 정의한다. 최적화기는 시드 후보를 포함한 후보 집합에서 후보를 수정해 커밋하거나, 기존 후보와 개발 또는 검증 사례의 부분집합을 선택해 평가한다. 서버는 점수 추정치와 실행 정보를 반환하되 분할별 공개 정책이 허용한 정보만 노출하며, 최적화기는 예산 안에서 후보 하나를 최종 지명한다. 그 뒤 신뢰 서버가 보류 테스트에서만 후보를 실행해 이득을 보고한다. 따라서 정해진 인터페이스, 예산, 편집 권한을 지키고 최종 후보를 지명할 수 있는 시스템이면 어떤 모델이나 탐색 알고리즘도 최적화기로 참가할 수 있다.
  • 최적화기 샌드박스는 목표 에이전트 하네스만 쓸 수 있고, 과제 데이터와 평가 결과는 읽기만 가능하다. 테스트 사례·점수, 공급자 자격 증명, 예산 강제 구성 요소는 샌드박스 밖에 두며, 대상 에이전트의 사례별 실행은 권한 없는 격리 샌드박스에서 수행한다.
  • 최적화기의 추론 호출과 대상 에이전트 평가 호출은 모두 모델 API 게이트웨이를 통과한다. 게이트웨이는 범위별 허용 모델 목록과 토큰 예산을 적용하므로, 평가 경계는 최적화기가 지시를 준수할 것이라는 가정이 아니라 실행 환경의 속성으로 유지된다.

보류 하네스 최적화를 위한 신뢰 실행 구조

The optimization problem

• 후보 하네스 H는 실행 가능한 코드베이스이며, 최적화기는 고정 실행 인터페이스와 소수의 불변 경로를 제외하고 파일을 추가·수정·삭제할 수 있다. 반면 과제 불변량 θ=(M,E,V), 즉 후보가 사용할 수 있는 대상 모델 M, 사례별 환경 E, 완료 궤적을 0~1 점수로 변환하는 검증기 V는 고정한다. 개발·검증·테스트 사례는 서로 겹치지 않으며, 개발 분할은 입력·사례별 결과·추적을 공개하고 검증 분할은 후보 선택용 집계 점수만 공개한다. 테스트 분할은 최종 지명 전까지 공개하지 않는다.
  • 분할 D에서의 성능은 사례와 확률적 실행 궤적에 대한 검증 점수의 기댓값으로 정의한다. 탐색 중 개발 또는 검증 사례 부분집합을 평가하면 집계 성능 추정치와 사례별 결과·추적이 생성되며, 최적화기가 볼 수 있는 범위는 분할별 공개 정책이 정한다.
  • 목표는 보류 테스트에서 시드 H0보다 높은 기대 점수를 낸 후보 H+를 찾는 것이다. 과제별 척도와 시드 난이도 차이를 보정하기 위해 g=(Eθ(H+)−Eθ(H0))/(1−Eθ(H0))를 사용하며, 이는 시드 위에 남은 성능 여유 가운데 확보한 비율이다. 음수는 제출 후보가 시드보다 낮은 점수를 받았음을 뜻한다.
  • 평가 비용은 다차원 벡터로 누적되며 예산의 각 성분을 넘을 수 없다. §3.1은 개발·검증 분할마다 평가 호출 상한을 100회, 전체 사례 통과를 4회, 대상 모델의 소모 토큰 상한을 둔다고 설명한다. 그러나 §5.3은 같은 분할의 호출 상한을 200회라고 서술해 원문 내부에서 충돌한다. 따라서 호출 상한의 정확한 값은 확인할 수 없지만, 전체 사례 통과 4회와 대상 모델 토큰 상한이 별도 제약이라는 점은 일관된다. 최적화기 자체의 추론 토큰은 계량하지만 이 실험에서는 제한하지 않았다.

The HarnessOpt-Bench suite

• 스위트는 OfficeQA, BrowseComp-Plus, Terminal-Bench, GAIA의 네 과제로 구성된다. 모든 시드는 의도적으로 조정하지 않은 소형 Python 하네스이며, OfficeQA 시드는 약 130줄, 도구 3개, 최대 24턴, 일반적 시스템 프롬프트를 사용한다. 세 과제의 시드는 작동하지만 단순한 중간 성능 상태이고, GAIA 시드는 비기능적 스텁이다. 전자는 작동하는 에이전트를 정교화하는 능력을, 후자는 동작하는 에이전트를 구성하는 능력을 상대적으로 더 많이 시험한다. 과제마다 대상 모델 하나만 고정했고, 시드가 성능 바닥이나 천장이 아닌 측정 가능한 중간 범위에 놓이도록 모델을 선택했다.
  • 시드의 보류 성능은 독립 3회 실행(K=3)의 평균으로 한 번 측정해 고정하며, 제출 후보도 테스트 사례마다 3회 실행한 평균으로 평가한다. 같은 후보를 같은 사례에서 두 번 채점했을 때의 불일치를 K=3 정규화 이득 척도로 환산한 중앙값을 과제별 해상도 밴드로 사용한다. 이보다 작은 차이는 통계적 유의성 검정의 결론이 아니라 판별되지 않은 차이로 취급한다.
  • 오프더셸프 하네스 점수는 정규화 이득의 기준선이 아니라 시드의 개선 여지를 보여 주는 맥락이다. Table 3에서 OfficeQA 시드는 0.341이고, 동일 대상 모델·분할·라운드에서 오프더셸프 하네스는 0.505~0.734였다. GAIA의 시드는 측정된 0이므로, 이 과제의 정규화 이득은 보류 원시 점수와 같다.

Experimental Setup

• 핵심 격자는 세 개발사의 최전선 계열에서 고른 claude-opus-5, claude-sonnet-5, gpt-5.6-sol, gpt-5.6-terra, kimi-k3를 네 과제에 적용한다. 각 모델은 모든 모델에 공통인 opencode와 네이티브 코딩 하네스인 claude-code, codex, kimi-cli에서 실행되어 핵심적으로 10개 모델-하네스 구성을 이룬다. 공통 하네스 안에서 모델을 비교하면 스캐폴드를 고정할 수 있고, 같은 모델에서 공통·네이티브 하네스를 비교하면 하네스 선택 민감도를 측정할 수 있다. GAIA에는 goose와 mini-swe-agent를 모든 모델에 추가 적용했으며, OfficeQA에서는 Claude Opus와 GPT 계열의 이전 릴리스도 각 계열의 네이티브 하네스에서 실행했다.
  • 보류 평가는 테스트 사례당 3회 시도의 평균이며, 각 최적화기 구성은 두 번 실행했다. 부록의 범위는 이 두 실행에서 관찰된 범위일 뿐 신뢰구간이나 분산 추정치가 아니다. 최적화기 모델의 추론 토큰은 측정하지만 제한하지 않았으므로, 결과는 최적화기 추론이 희소 자원이 아닐 때의 달성 가능 성능을 나타낸다.
  • 주 지표는 정규화 이득이다. 과제 간 합성 점수 LSS-λ는 작동하는 시드를 지닌 세 과제의 균형 잡힌 opencode 격자만 사용한다. 반복 평균 이득을 전체 평균, 과제 효과, 모델 효과로 가법 분해했을 때의 모델 효과 λ를 뜻하므로 과제별 체계적 차이를 제거한 상대 효과다. GAIA는 이득이 원시 점수이고, 네이티브 하네스는 스캐폴드를 고정하지 못하므로 이 계산에서 제외한다.

Results

• Table 1은 핵심 구성의 과제별 정규화 이득을, Figure 2는 실행 수준 분포와 과제 보정 모델 효과를 제시한다. 정규화는 시드 위 성능 여유의 비율을 공통 단위로 표현할 뿐, 과제 간 체계적 난이도 차이를 제거하지는 않는다. 따라서 행 전체를 단일 종합 순위로 읽기보다 같은 과제 열에서 비교해야 하며, 과제별 해상도 밴드보다 작은 차이는 판별되지 않는다. GAIA는 시드가 측정된 0인 비기능적 스텁이므로 다른 세 과제의 정규화 이득과 같은 의미로 합산할 수 없다.

Distinguishing frontier models

• §5.1과 Figure 2에서 과제와 코딩 하네스를 고정한 채 최적화기 모델을 바꿨을 때 정규화 이득의 평균 이동량은 0.142였고, 과제와 모델을 고정한 채 하네스를 바꿨을 때는 0.079였다. 기준값 0.079와 비교값 0.142의 비율은 0.142/0.079=1.80이므로 모델 대비 효과는 약 1.8배이며, 두 값은 과제별 해상도 밴드를 넘지만 하네스 대비 효과는 근소하게 넘는다. Table 1의 모든 구성 중 과제별 최고 이득은 OfficeQA에서 claude-opus-5+opencode 0.63, BrowseComp-Plus에서 같은 구성 0.48, Terminal-Bench에서 같은 구성 0.29, GAIA에서 gpt-5.6-sol+codex 0.49다. 따라서 한 구성이 모든 과제에서 최고라는 결과는 아니며, GAIA의 0.49는 측정된 0 시드에 대한 원시 보류 점수이기도 하다.
  • 작동하는 시드 세 과제와 opencode만으로 계산한 LSS-λ는 claude-opus-5가 +0.228로 1계층, claude-sonnet-5 +0.029·kimi-k3 −0.014·gpt-5.6-sol −0.069가 2계층, gpt-5.6-terra −0.174가 3계층이다. 이 추정량의 해상도는 ±0.058이므로 같은 계층 안의 세밀한 순위는 확정할 수 없다.

모든 최적화기와 과제의 정규화 이득

최적화기 모델 효과와 코딩 하네스 효과의 비교

Tracking model progress

• OfficeQA에서 대상 모델, 시드, 예산, 코딩 하네스를 계열 안에서 고정하고 최적화기 모델 릴리스만 바꾼 Figure 3 실험은 이 벤치마크가 세대별 차이를 포착할 수 있음을 보인다. GPT의 다섯 릴리스에서 정규화 이득은 +0.03에서 +0.49까지 단조 증가했고, 네 번의 인접 변화 중 세 번이 OfficeQA 해상도 ±0.045를 넘었다. Claude Opus의 다섯 릴리스는 +0.37~+0.59 범위이며 단조적이지 않지만, 첫 릴리스와 마지막 릴리스의 차이는 해상도 밴드를 넘었다. 따라서 릴리스 진전은 두 계열에서 관찰되지만, 모든 계열의 성능이 출시 순서에 따라 단조롭게 증가한다고 일반화할 수는 없다.

모델 릴리스별 OfficeQA 이득 변화

Where current optimizers fall short

• 탐색 궤적에서 사전 등록한 여덟 하네스 레버는 프롬프트, 문맥 관리, 단계 상한, 재시도·타임아웃 정책, 도구 스키마, 답 추출, 검색 정책, 추론 노력이다. 이 레버 가운데 탐색 중 건드린 비율은 네 과제 모두에서 이득과 양의 스피어만 상관을 보였으며, OfficeQA·BrowseComp-Plus는 각각 +0.88, Terminal-Bench는 +0.65, GAIA는 +0.34였다. 이는 최종 제출물에 남은 변경 폭이 아니라 탐색 범위이고 전체 수정량과도 상관되므로, 폭넓은 탐색이 이득의 원인이라고 식별한 결과는 아니다.
  • 평가 출력 읽기에 사용한 행동 비율은 네 과제에서 이득과 −0.31~−0.64의 음의 상관을 보였다. 111개 셀 가운데 7개만 상세 추적 구간을 합계 16회 요청했고, 대다수는 사례별 점수 요약을 이용했다. 저자들은 이를 상세 진단이 불필요하다는 증거로 해석하지 않으며, 사례별 요약이 실패 위치를 충분히 알려 주어 전체 추적을 읽는 문맥 비용을 정당화하지 못했을 가능성으로 한정한다.
  • 평가 예산 분석에서도 원문 수치가 충돌한다. §5.3은 개발·검증 분할마다 200회 호출과 4회 전체 사례 통과를 허용했다고 쓰고, 중앙값이 8회 호출, 즉 8/200=4%를 사용했으며 100개 셀 중 55개가 한 분할 이상의 사례 예산을 소진했다고 보고한다. 그러나 §3.1의 분할당 호출 상한은 100회다. 호출 상한의 정확한 값은 확인할 수 없지만, 원문은 사례 통과 예산이 호출 횟수 상한보다 실제 탐색을 더 강하게 제약했다고 해석한다.
  • Figure 13에서는 대부분의 점이 동일선 아래에 있어, 탐색에서 본 최고 검증 점수보다 제출 후보의 테스트 점수가 낮다. 이는 관측 가능한 최고 검증 점수가 낙관적임을 뜻하지만, 그림만으로 후보 선택에 따른 과적합과 검증·테스트 분포 불일치를 분리할 수 없으므로 저자들도 전자만을 원인으로 확정하지 않는다.

탐색 중 하네스 레버 범위와 이득의 관계

The effect of the optimizer’s own harness

• §5.4는 20개 모델-과제 쌍에서 공통 opencode와 모델별 네이티브 하네스를 비교한다. 공통 하네스가 11회, 네이티브 하네스가 9회 높았고 동점은 없었으며, 11개 쌍의 차이는 해당 과제 해상도 밴드를 넘었다. 효과 방향이 모델과 과제에 따라 달라 집계상 근소한 공통 하네스 우세는 일관된 작은 효과가 아니라 이질적인 효과의 결과다. 따라서 네이티브 도구만 사용해 모델의 하네스 최적화 능력을 평가하는 것은 신뢰도 높은 추정이 되지 않는다.
  • GAIA는 opencode·네이티브 하네스 외에도 goose와 mini-swe-agent를 적용한 유일한 과제다. 모델별 하네스 선이 교차하므로 모든 모델에서 가장 좋은 하네스는 없다. 각 모델의 최선 공통 하네스 대비 네이티브 성능은 gpt-5.6-sol의 codex가 +0.179, gpt-5.6-terra의 codex가 +0.131이며, GAIA 해상도 ±0.035에 대해 각각 0.179/0.035=5.1배, 0.131/0.035=3.7배다. 반면 두 Claude 모델과 Kimi의 차이는 영점에서 한두 해상도 밴드 안에 있다.

GAIA에서 모델별 최적 코딩 하네스의 차이

Conclusion

• 논문은 하네스 공학을 단순한 주변 인프라가 아니라 보류 보상으로 측정할 수 있는 모델 능력으로 다룬다. 현재 최전선 모델은 에이전트를 개선할 수 있지만, 성과는 과제와 시드 체제에 따라 고르지 않고 중간권 구성의 세부 순위는 반복 실행 변동 때문에 확정하기 어렵다. 반복된 개발·검증 피드백이 고정 평가에 특화된 전략을 보상할 수 있다는 점, 시드 완성도와 복잡도를 체계적으로 변화시키지 않은 점, Python과 과제별 단일 고정 대상 모델만 다룬 점도 한계다. 저자들은 사례·도구 동작·검증기 구현의 실행별 변동, 시드 완성도·구조 복잡도의 통제된 사다리, 언어·런타임·에이전트 구조·대상 모델의 확대를 후속 과제로 제안한다.

Full optimizer results

• 부록 A는 과제별 전체 최적화기 결과를 확장해 제시한다. 핵심 모델-하네스 구성의 반복 실행 범위와 생성된 하네스의 특성을 보고하고, GAIA에서 추가로 실행한 코딩 하네스 결과를 포함한다.

The suite

• 부록 B는 네 과제의 스위트 설계를 다룬다. 과제별 고정 대상 모델, 개발·검증·테스트 분할, 시드의 보류 성능, 같은 조건에서 오프더셸프 하네스를 적용했을 때의 성능을 통해 시드의 개선 여지를 설명한다.

Model effects

• 부록 C는 균형 잡힌 공통 하네스와 작동하는 시드를 지닌 세 과제의 범위에서 계산한 LSS-λ 모델 효과를 설명한다. 가법 분해 외의 추가 순위 추정량도 비교해 보고한 모델 순서가 한 가지 추정 방식에만 의존하지 않는지를 다룬다.

Supporting figures

• 부록 D는 편집 유형과 변경 폭, 최적화기 행동, 탐색·배포 토큰 비용, 공통·네이티브 하네스의 과정 차이, 검증과 보류 성능의 관계, GAIA 하네스 스윕, 예산 소비를 보조 그림으로 제시한다.

Reproducibility

• 부록 E는 데이터·분할·후보·의존성·실행 기록을 고정하고 재현하는 절차를 설명한다. 다만 분할 크기에는 원문 내부 충돌이 있다. 부록 E는 모든 분할을 20/40/40이라고 서술하지만, 부록 Table 3은 OfficeQA 49/98/99, BrowseComp-Plus 33/66/66, Terminal-Bench 17/36/36, GAIA 33/66/66으로 제시한다. 과제별 표가 명시한 실제 분할값을 확인 가능한 값으로 기록하되, 두 서술이 충돌하므로 원문만으로 20/40/40의 의미나 적용 범위를 확정할 수 없다.

부록

• 부록은 전체 최적화기 결과, 과제 스위트의 고정 상수와 오프더셸프 하네스 맥락, 과제 보정 모델 효과, 탐색 과정·비용·검증 일반화를 보조하는 그림, 그리고 데이터·분할·후보·자원 사용의 재현성 절차로 구성된다.

짧은 생각

이 벤치마크가 유용하려면 최종 점수만 비교하는 데 그치지 않고, 어떤 자원 제약이 탐색 방식을 실제로 바꾸는지 분명히 해야 한다. 원문은 사례 통과 예산이 병목이라고 해석하지만, 평가 호출 상한을 §3.1에서는 100회, §5.3에서는 200회로 다르게 적었다. 이 불일치가 해소되어야 호출 수와 사례 선택 중 무엇을 개선해야 하는지 판단할 수 있다. 또한 최적화기 자체 추론은 무제한이므로, 추론 토큰도 예산에 넣었을 때 폭넓은 탐색과 높은 이득의 관계가 유지되는지, 또는 적은 사례를 더 잘 고르는 전략이 우세해지는지를 비교할 필요가 있다.