Turbo Harness가 작업 인스턴스마다 하네스를 패치해 성능을 높인다

무엇인가

이 논문이 다루는 문제는 에이전트의 '하네스' 최적화다. 하네스란 LLM 주변의 런타임 기계장치 전반으로, 컨텍스트 구성, 메모리, 워크플로 오케스트레이션, 도구 사용, 권한, 검증까지 포함한다. 저자들은 하네스 설계 자체가 하나의 어려운 최적화 문제라고 보고, 이를 자동화하는 기존 연구(Meta-Harness, Harness-R1 등)의 두 가지 한계를 지적한다. 첫째, 기존 방법은 모든 작업 인스턴스에 균일하게 적용되는 단일 전역 하네스를 만든다. 그러나 평균적으로 좋은 하네스가 개별 인스턴스에서도 최적이라는 보장은 없다. 예를 들어 SWE-Bench류 인스턴스는 서로 다른 GitHub 저장소에서 오고 개발 워크플로와 테스트 관례가 달라, 저장소별로 다른 하네스 구성이 유리할 수 있다. 둘째, 하네스 최적화는 비싸고 그 과정에서 생성된 정보가 대부분 사장된다. 탐색 중에는 어떤 전략이 어떤 조건에서 성공·실패했는지에 대한 풍부한 이력이 쌓이지만, 최적화가 끝나면 인스턴스 특화 신호는 버려진다.

어떻게 동작하나

제안 방법인 Turbo Harness는 이 버려지는 탐색 산출물을 재활용한다. 구체적으로는 완료된 외부 루프(outer-loop) 하네스 탐색의 검색 아카이브를 모아 구조화된 '플레이북'으로 요약한다. 이 플레이북은 ACE 방식을 따라 성능 향상을 이끈 편집과 실패한 편집을 모두 기록하며, 어떤 편집 전략이 어떤 조건에서 유용한지 담는다. 그다음 소형 오픈웨이트 LLM인 '하네스 편집기'(실험에서는 Qwen3.5-9B)를 학습시킨다. 편집기는 작업 인스턴스 x, 전역 최적 하네스 H*의 소스 코드, 플레이북 P를 입력받아 패치 p_x를 출력하고, 이를 적용해 인스턴스별 하네스 H_x = H* ⊕ p_x를 만든다. 즉 처음부터 새 하네스를 합성하는 것이 아니라 이미 최적화된 하네스를 국소적으로 고치는 방식이다.

무엇과 다른가

편집기 학습은 강화학습으로 이뤄진다. 각 학습 인스턴스마다 G개의 후보 편집을 샘플링해 H*에 적용하고, 고정된 실행 모델 M으로 에이전트를 돌려 과제 성능과 과제별 평가 지표로 보상을 계산한다. 적용 불가능하거나 검증에 실패한 편집은 보상 0을 받고 실행되지 않는다. 최적화는 GRPO를 사용하며, 어드밴티지는 같은 인스턴스 x에 대한 후보들의 상대 보상으로 계산하고, 초기 편집기(참조 정책)에 대한 샘플링 KL 페널티를 건다. 실행 모델 M은 학습 내내 고정된다. 추론 시에는 인스턴스당 편집기 호출이 단 한 번뿐이고, 패치 적용이 실패하면 H*로 폴백한다. 편집기가 작고 호출 횟수가 적어 배포 오버헤드가 작다는 점을 저자들은 강조한다.

어떻게 쓰나

실험은 상호작용형 에이전트 과제, 소프트웨어 엔지니어링, 장기 터미널 과제에 걸친 7개 벤치마크에서 이뤄졌다. 에이전트 벤치마크 4개(ALFWorld, ScienceWorld, DBBench, WebShop)에서 Turbo Harness는 Meta-Harness보다 각각 10.0%포인트, ScienceWorld 점수 7.3점, 4.2%포인트, 2.0%포인트 개선됐고, ReAct·Self-Refine·Reflection 같은 프롬프트 기반 베이스라인도 모두 앞섰다. Harness-R1과는 ALFWorld·ScienceWorld·DBBench에서 우세했고 WebShop에서는 42.0% 대 42.2%로 비슷했다. 코딩 벤치마크인 SWE-smith-MR에서는 통과율이 Claude Haiku 4.5에서 50.7%→64.0%, Gemini 3.7 Flash에서 70.7%→88.0%로 올랐다(각각 13.3, 17.3%포인트). 두 코딩 벤치마크 평균으로 보면 GEPA 45.9, ACE 44.3, Meta-Harness 54.1, Turbo Harness 66.4로, 전역 하네스 하나로는 여러 저장소의 이슈를 커버하기에 상당한 여지가 남는다는 것을 보여준다. SWE-bench Verified에서도 Gemini는 38.4%→54.4%, Haiku는 56.7%→59.3%로 개선됐는데, Haiku의 개선폭이 작은 것은 Meta-Harness가 이미 31.6%→56.7%로 대부분의 여지를 소진했기 때문이라고 저자들은 해석한다.

전제와 한계

비용 측면의 결과도 구체적이다. 코딩 설정 4개 중 3개에서 Turbo Harness는 Meta-Harness보다 적은 스텝과 낮은 API 비용으로 이슈를 해결했다. SWE-smith-MR + Gemini에서는 이슈당 평균 23.1스텝·$0.310이 8.7스텝·$0.046으로 줄어 약 6.7배 절감됐고, Haiku에서는 18.5→17.3스텝, $0.151→$0.136이었다. SWE-bench Verified + Gemini도 32.5→25.9스텝, $0.470→$0.331로 같은 방향이었다. 예외는 통과율 개선이 가장 작았던 SWE-bench Verified + Haiku로, 18.8→20.4스텝으로 오히려 늘었다. 장기 터미널 과제인 Terminal-Bench-2.1에서는 Claude Sonnet 4.5를 실행 모델로 썼는데, 여기서는 Meta-Harness가 사람이 만든 하네스를 앞서지 못했음에도 인스턴스별 적응이 55.5%의 최고 평균 통과율을 기록해 Meta-Harness보다 5.0%포인트, 가장 강한 기본 하네스인 Terminus-Kira보다 3.2%포인트 높았고 5회 실행 모두 최고 평균을 냈다. 같은 벤치마크에서 턴 수는 76.3→71.2, 비용은 $1.56→$1.38, 입력 토큰은 3.15M→2.65M으로 줄었다.

어블레이션은 이득의 출처를 분리한다. SWE-smith-MR + Haiku 조합에서 전역 Meta-Harness가 50.7%일 때, 학습하지 않은 9B 편집기를 플레이북 없이 쓰면 51.3%, 플레이북과 함께 쓰면 50.0%, RL만 하고 플레이북 없이 쓰면 49.3%였다. 반면 RL 학습과 플레이북 조건을 결합하면 64.0%로, 같은 RL 편집기를 플레이북 없이 쓴 경우보다 14.7%포인트 높았다. 즉 소형 편집기에서는 일반적인 인스턴스별 편집, 플레이북 접근만, RL만으로는 어느 것도 이득을 설명하지 못하고, 외부 루프 탐색에서 증류된 전략을 식별·적용하도록 RL이 학습시킬 때 개선이 나타난다. 편집기 모델을 바꾼 실험에서는 학습하지 않은 Qwen3.5-9B가 50.0%, 고정된 Sonnet-4.5가 55.3%, Opus-4.6이 61.3%였고, RL로 학습한 Qwen3.5-9B가 64.0%로 Opus-4.6과 대등하면서 로컬 하드웨어에서 돌릴 만큼 작았다.

개발자 관점에서 이 논문의 실무적 의미는 명확하다. 모델을 바꾸지 않고도 하네스 런타임을 인스턴스별로 조정하는 것만으로 통과율과 비용을 동시에 개선할 수 있다는 주장이며, 특히 여러 저장소를 상대하는 코딩 에이전트나 장기 터미널 에이전트에서 전역 설정 하나로 버티는 데 한계가 있을 때 참고할 만하다. 다만 도입 전에 확인할 것은 두 가지다. 첫째, 이미 완료된 전역 하네스 탐색 아카이브가 있어야 하고 그 품질이 결과를 좌우한다. 둘째, 편집기 학습에 추가 환경 롤아웃이 필요하므로 그 비용을 감수할 수 있는지 따져야 한다. 논문이 제시한 비용 수치는 실행 모델 비용만 포함하고 오프라인 최적화와 인스턴스당 1회 편집기 호출 비용은 제외한다는 점도 유의해야 한다.

저자들이 밝힌 한계는 두 가지다. 첫째, Turbo Harness는 완료된 전역 하네스 탐색 위에 세워지므로 그 과정에서 수집된 하네스 후보, 궤적, 피드백의 품질과 다양성에 효과가 의존한다. 원래 탐색이 약한 전략만 살펴봤거나 유용한 경험이 적었다면 인스턴스별 적응의 이득도 제한될 수 있다. 둘째, 편집기 학습에 추가 환경 롤아웃이 필요하고 이는 에이전트 과제에서 비쌀 수 있다. 향후 과제로는 더 표본 효율적인 최적화나 기존 롤아웃 데이터 재사용으로 학습 비용을 줄이는 것, 그리고 편집기와 플레이북이 과제·도메인·하네스 탐색 실행 간에 전이되는지 조사하는 것을 제안한다. 더 넓게는 하네스 최적화 중간 산출물이 일회용 부산물이 아니라 재사용 가능한 경험이 될 수 있다는 것이 이 논문의 주장이다.