기술 요약: HarnessOpt-Bench

문제 정의

대규모 언어 모델(LLM)이 에이전트 시스템 내에 점점 더 많이 배치됨에 따라, 모델의 성능은 모델 가중치뿐만 아니라 "하네스(harness)"—즉, 주변 프롬프트, 도구, 제어 흐름, 메모리 및 오케스트레이션 코드—에도 의존하게 됩니다. 하네스 최적화(하네스를 반복적으로 개선하고 평가를 통해 향상시키는 과정)는 유능한 AI 시스템을 구축하기 위한 핵심적인 경로임에도 불구하고, 커뮤니티에는 프런티어 LLM이 이 작업을 얼마나 잘 수행할 수 있는지 측정할 수 있는 공통된 프로토콜이 부족합니다.

기존의 평가 방식은 대상 에이전트, 시드(seed), 예산(budget), 점수 산정 프로토콜이 서로 달라 혼재되어 있는 경우가 많아, 성능 향상이 최적화 모델 때문인지, 모델이 사용하는 코딩 하네스 때문인지, 아니면 특정 작업 설정 때문인지를 구분하기 어렵게 만듭니다. 또한, 하네스 최적화는 표준 코딩 벤치마크와는 다릅니다. 평가는 비용이 많이 들고 확률적(stochastic)입니다. 즉, 단순히 하나의 정답 코드를 생성하는 것이 아니라, 불완전한 증거로부터 실패 원인을 진단하고, 제한된 평가 예산을 관리하며, 실제 개선과 노이즈를 구분해야 합니다.

방법론: HARNESSOPT-BENCH

저자들은 비용이 많이 들고 확률적인 평가 조건 하에서 엔드 투 엔드(end-to-end) 하네스 최적화를 평가하기 위해 설계된 벤치마크인 HARNESSOPT-BENCH를 소개합니다. 이 프레임워크는 다음과 같은 핵심 구성 요소를 통해 통제되고 재현 가능한 환경을 강제합니다.

1. 최적화 문제

• 후보 하네스 ($H$): 프롬프트, 도구 및 제어 흐름을 포함하는 실행 가능한 코드베이스입니다. 최적화 모델은 고정된 실행 인터페이스와 불변의 경로를 준수하는 범위 내에서 파일을 수정, 추가 또는 삭제할 수 있습니다.
• 불변량 ($\theta$): 대상 모델, 환경 및 검증기(verifier)는 고정되어 있습니다. 최적화 모델은 대상 모델이나 평가 로직을 변경할 수 없으며, 오직 하네스 코드만을 수정할 수 있습니다.
• 예산 ($B$): 탐색은 고정된 평가 호출 횟수(파티션당 최대 100회)와 총 대상 모델 토큰 수에 의해 제한됩니다. 최적화 모델은 무엇을 어떤 정밀도로 평가할지 결정해야 합니다.
• 공개 정책:
  • 개발 ($D_{dev}$): 진단을 지원하기 위해 케이스별 입력, 케이스별 결과 및 실행 트레이스(execution traces)를 공개합니다.
  • 검증 ($D_{val}$): 선택을 지원하기 위해 집계된 점수만을 공개합니다.
  • 테스트 ($D_{test}$): 탐색 과정 중에는 완전히 접근이 차단됩니다.

2. 신뢰 실행 환경 (Trusted Execution Environment)

과적합을 방정하고 공정성을 보장하기 위해, 이 벤치마크는 VERO [23]를 기반으로 한 신뢰 실행 환경 내에서 실행됩니다.

• 격리: 각 대상 에이전트 롤아웃은 일시적이고 권한이 없는 샌드박스에서 발생합니다.
• 액세스 제어: 최적화 모델은 대상 에이전트의 하네스만 작성할 수 있습니다. 개발 트레이스와 검증 메트릭은 읽을 수 있지만, 테스트 파티션에 접근하거나 검증기를 수정할 수는 없습니다.
• 감사: 모든 후보 버전은 감사를 위해 보존되며, 리소스 사용량은 측정됩니다.

3. 평가 지표

주요 지표는 **정규화된 이득(Normalized Gain, $g$)**이며, 이는 홀드아웃(held-out) 테스트 파티션에 대해 핀 고정된 시드(pinned seed) 대비 후보 모델의 개선 정도를 가용 헤드룸(headroom)으로 나눈 값으로 정의됩니다.
$$g = \frac{E_\theta(H^+) - E_\theta(H_0)}{1 - E_\theta(H_0)}$$
여기서 $H_0$는 시드 하네스이며, $E_\theta$는 기대 점수입니다. 음수 값은 후보 모델이 시드보다 성능이 낮았음을 나타냅니다.

4. 실험 설계

• 작업(Tasks): 핀 고정된 시드가 포함된 네 가지 다운스트림 작업(OfficeQA, BrowseComp-Plus, Terminal-Bench, GAIA)을 대상으로 합니다. 세 개의 시드는 유능하지만 기초적인 수준이며, 하나(GAIA)는 기능이 없는 스텁(stub)입니다.
• 최적화 모델: 5개의 프런티어 LLM(Claude Opus-5, Claude Sonnet-5, GPT-5.6-Sol, GPT-5.6-Terra, Kimi-K3)이 평가되었습니다.
• 하네스 구성: 각 모델은 두 가지 조건에서 테스트되었습니다:
  1. 공유 하네스 (Shared Harness): 모든 모델이 공통의 코딩 하네스(opencode)를 사용합니다.
  2. 네이티브 하네스 (Native Harness): 모델들이 각각의 네이티브 코딩 도구(예: claude-code, codex, kimi-cli)를 사용합니다.
• 프로토콜: 각 구성은 두 번씩 실행되었습니다. 결과는 테스트 케이스당 $K=3$번의 독립적인 평가 라운드에 대해 평균을 내어 확률적 노이즈를 완화했습니다.

주요 기여

1. 통제된 벤치마크: HARNESSOPT-BENCH는 최적화 모델을 코딩 하네스 및 대상 작업으로부터 분리하여, 하네스 최적화에서의 모델 역량을 격리하여 측정할 수 있게 합니다.
2. 신뢰할 수 있는 프로토콜: 예산을 강제하고, 홀드아웃 데이터에 대한 접근을 차단하며, 감사를 위해 후보를 보존하는 신뢰 실행 경계를 도입하여, 개선 사항이 가시적인 점수에 대한 과적합이 아닌 일반화 능력을 반영하도록 보장합니다.
3. 경험적 평가: 4개의 작업과 111개의 점수 산정 실행에 걸쳐 5개의 프런티어 모델을 평가하고, 공유 하네스와 네이티브 하네스를 비교했습니다.
4. 탐색 행동 분석: 특정 최적화 행동(예: 개입의 폭, 트레이스 읽기)과 최종 성능 간의 상관관계를 규명하기 위해 도구화된 탐색 궤적을 분석했습니다.

결과

1. 모델 vs. 하네스 민감도

• 모델 선택이 지배적임: 최적화 모델의 선택은 코딩 하네스의 선택보다 성능에 훨씬 더 큰 영향을 미칩니다. 최적화 모델을 변경했을 때 정규화된 이득은 평균 0.142 변동한 반면, 하네스를 변경했을 때는 0.079 변동했습니다.
• 일관된 네이티브 우위 없음: 네이티브 하네스(예: Claude 모델을 위한 claude-code)가 공유 하네스에 비해 일관된 이점을 제공하지는 않았습니다. 20개의 모델-작업 쌍 중 11개에서는 공유 하네스가 네이티브보다 우수했고, 9개에서는 네이티브가 우수했습니다. 총체적인 차이는 거의 0에 가까웠으며, 이는 하네스에 대한 민감도가 균일하기보다는 이질적임을 시사합니다.

2. 역량 격차 및 진행 상황

• 모델 출시: 본 벤치마크는 연속적인 모델 릴리스를 성공적으로 구분해 냅니다. OfficeQA에서 GPT-5.6 릴리스는 단조 증가하는 이득을 보였으나, Claude Opus 릴리스는 단조롭지는 않지만 유의미한 편차를 보였습니다.
• 작업별 편차: 이득은 작업에 따라 크게 다릅니다. 가장 강력한 구성들은 OfficeQA에서 가용 헤드룸의 약 3분의 2를 확보했으나, BrowseComp-Plus와 Terminal-Bench에서는 0에서 벗어나지 못했습니다.

3. 탐색 행동 통찰

• 개입의 폭 (Breadth of Intervention): 탐색 중에 건드린 하네스의 "레버"(예: 프롬프트, 재시도 정책, 도구 스키마) 비율과 최종 정규화 이득 사이에는 강한 양의 상관관계($\rho$ 값 +0.34 ~ +0.88)가 존재합니다. 더 넓은 탐색이 더 나은 결과와 연관되어 있습니다.
• 트레이스 읽기 (Trace Reading): 직관과는 반대로, 상세한 실패 트레이스 검사는 거의 사용되지 않았으며(111개 셀 중 단 16회), 이득과 음의 상관관계를 보였습니다. 최적화 모델들은 주로 케이스별 점수 요약에 의존했습니다.
• 예산 제약: 대부분의 최적화 모델에게는 평가 호출 캡(cap)이 아닌, 케이스 통과 허용 횟수(파티션당 4회의 전체 패스)가 실질적인 제약 조건이었습니다.
• 과적합: 가시적인 검증 점수는 최종 홀드아웃 점수에 비해 종종 낙관적인 것으로 나타났으며, 이는 홀드아웃 파티션의 필요성을 확인시켜 줍니다.

의의 및 주장

본 논문은 하네스 최적화를 프런티어 LLM의 측정 가능하고 차별화 가능한 능력으로 확립합니다. 저자들은 다음과 같이 주장합니다:

• 현재의 모델들은 하네스 최적화를 수행할 수 있지만, 그 성능은 불균일하며 특정 작업 및 시드 체제에 크게 의존합니다.
• 에이전트를 최적화하는 능력은 코드를 작성하는 능력과는 별개입니다. 전자는 확률적 시스템에 대해 추론하고 제한된 자원을 관리하는 능력을 요구합니다.
• HARNESSOPT-BENCH는 하네스 엔지니어링을 최적화 모델 특화 데모에서 재현 가능한 평가 대상으로 전환합니다. 이를 통해 커뮤니티는 다른 에이전트를 확실히 더 좋게 만들 수 있는 시스템을 측정하고 발전시킬 수 있습니다.

저자들은 본 벤치마크가 "해킹 방지(hack-resistant)는 되지만 해킹 불가능(hack-proof)은 아니다"라고 언급하며, 결과가 현재의 작업 및 시드 분포에 국한되어 있음을 밝히며 신중한 입장을 유지합니다. 그들은 다음 단계의 프런티어는 단순히 더 나은 에이전트가 아니라, 에이전트를 확실하게 더 좋게 만들 수 있는 모델이라고 강조합니다.