요약: “하네스를 자동 개선한다”는 약속, 실제로는?
LLM 에이전트 성능을 끌어올리는 데 하네스(harness) 설계가 핵심이라는 것은 이제 상식이다. 프롬프트, 도구, 메모리, 검증 루틴, 제어 로직을 포함하는 하네스는 모델은 그대로두고 에이전트 능력을 바꾸는 가장 실용적인 수단이다. 최근 Meta-Harness, AHE, AEVO 등이 자동 하네스 진화(automatic harness evolution) —에이전트가 자신의 하네스를 반복적으로 개선하는 루프— 를 제안하며 주목받았다.
Allen Institute for AI와 University of Washington 연구진이 던진 질문은 단숨에 날카롭다:
“하네스 진화가 얻는 성능 향상은 진짜 하네스 설계 개선 때문인가, 아니면 그저 더 많이 시도했기 때문인가?”
핵심 결과 (Figure 1): unit test 피드백이 없을 때, 하네스 진화 알고리즘(파란색)은 단순 test-time scaling 베이스라인(병렬 샘플링, 순차적 정제)을 일관되게 능가하지 못한다. 점선은 초기 하네스의 성능을 나타낸다. (Wang et al., 2026)
문제의 핵심: 두 가지 평가 함정
논문은 기존 하네스 진화 연구의 평가 방식에 대해 두 가지 근본적 우려를 제기한다.
1. Test-time scaling과의 불공정한 비교
하네스 진화는 본질적으로 반복적 검색(iterative search) 절차다. 이전 궤적을 분석하고, 하네스를 수정하고, 다시 평가하는 루프를 돈다. 이는 test-time scaling(병렬 샘플링, 순차적 정제)과 동일한 메커니즘이다. 그런데 기존 연구들은 하네스 진화에 더 많은 추론 예산을 주면서, 단순 test-time scaling과 비교하지 않았다. 동일한 피드백과 추론 예산에서 비교해야 “하네스 설계 개선”인지 “그저 더 많이 시도한 것”인지 알 수 있다.
2. 검색·평가 태스크 중복
더 심각한 문제: 하네스 진화가 검색에 사용한 태스크와 최종 평가에 사용한 태스크가 같은 벤치마크다. 이는 과적합 위험을 의미한다. 하네스가 특정 태스크 패턴에 맞춰진 것인지, 일반 가능한 설계 개선인지 구분하려면 분리된(disjoint) 태스크 세트로 평가해야 한다.
Figure 2: Test-time scaling(병렬 샘플링, 순차적 정제)과 자동 하네스 진화(하네스 진화, 하네스 스케일링)를 통일된 예산에서 비교. 각 방법이 무엇을 업데이트하고 어떤 피드백을 받는지가 핵심이다. (출처: Wang et al., 2026)
실험 설계: 공정한 비교를 위해
연구진은 네 가지 방법을 통일된 예산 프로토콜 아래 비교한다:
| 방법 | 무엇을 업데이트하는가 | 피드백 |
|---|---|---|
| 병렬 샘플링 | 독립적 궤적 K개 | unit test 또는 자기 판단 |
| 순차적 정제 | 이전 궤적을 반영한 새 궤적 | 이전 결과 + 요약 |
| 하네스 진화 | 태스크 분포 전체에 걸친 공유 하네스 | 배치 결과 + 요약 |
| 하네스 스케일링 | 단일 태스크마다 하네스 적응 | 단일 궤적 + 결과 |
- 벤치마크: Terminal-Bench 2.1 (89개 터미널 태스크, 검증된 개정판)
- 모델: Claude Opus 4.6, GPT-5.4, GPT-5.4 mini
- 예산: 각 방법에 동일한 추론 예산 할당
- 반복: 분산 감소를 위해 각 결과 2회 평균
결과: 하네스 진화는 일관된 우위를 보이지 못했다
실험 1: Unit test 피드백이 없을 때
unit test 케이스 없이 모델 자기 판단(self-selection)만으로 평가했을 때, 하네스 진화는 단순 test-time scaling(병렬 샘플링, 순차적 정제)을 일관되게 능가하지 못했다. 세 모델 평균에서 오히려 test-time scaling이 더 나은 경우가 많았다.
실험 2: Unit test 피드백이 있을 때
unit test 피드백을 제공했을 때도 결과는 극적으로 바뀌지 않았다. 하네스 진화가 특정 설정에서 약간의 이점을 보이기도 했지만, 일관된 우위는 없었고, 모델 간 결과가 불안정했다.
실험 3: 일반화 평가 (핵심 실험)
가장 중요한 실험이다. 하네스 검색에 사용한 태스크와 겹치지 않는 홀드아웃 태스크로 평가했다. 결과: 하네스 진화의 이점이 홀드아웃 태스크로 전이되지 않았다. 검색·평가 태스크가 같을 때의 성능 향상은 상당 부분 특정 태스크에 대한 과적합이었다.
Figure 3: 하네스 스케일링에서 메타 에이전트가 적용하는 하네스 수정 예시들. (출처: Wang et al., 2026)
왜 이런 결과가 나왔을까?
논문은 몇 가지 가능한 설명을 제시한다:
- 하네스 진화의 검색 공간이 너무 넓다: 프롬프트, 도구, 메모리, 제어 로직 전부를 수정하다 보니, 유의미한 개선을 찾기 어렵다.
- Test-time scaling이 이미 강력하다: 최신 모델(GPT-5.4, Claude Opus 4.6)은 단순히 여러 번 시도하는 것만으로도 상당한 성능 향상을 얻는다. 하네스 진화가 이를 넘어서려면 더 체계적인 탐색이 필요하다.
- 벤치마크 태스크 수가 적다: Terminal-Bench 2.1은 89개 태스크로, 하네스 진화가 일반 가능한 패턴을 학습하기엔 부족할 수 있다.
- 메타 에이전트의 한계: 하네스를 수정하는 메타 에이전트 자체도 같은 LLM이기 때문에, 자신의 약점을 진단하고 수정하는 능력에 한계가 있다.
시사점: 하네스 연구의 새로운 기준
이 논문의 기여는 “하네스 진화가 안 된다”가 아니라 **“제대로 평가하려면 이렇게 해야 한다”**는 방법론적 기준을 제시한 데 있다:
- Test-time scaling 베이스라인과 비교하라: 동일한 피드백, 동일한 예산에서.
- 검색·평가 태스크를 분리하라: 일반화를 확인하려면 disjoint split이 필수다.
- 하네스 수정의 해석 가능성을 높여라: 무엇이 바뀌었는지, 왜 효과가 있는지 분석해야 한다.
더 실습해보고 싶은 분들께
에이전트 하네스, 자동화된 에이전트 루프, 그리고 긴 컨텍스트 에이전트 설계를 직접 실험해보고 싶다면 다음 두 자료를 추천한다:
- 『이게 되네? 오픈클로 미친 활용법 50제』 — 에이전트 자동화와 하네스 엔지니어링을 실전에서 다루는 활용 가이드
- 「모두를 위한 루프 엔지니어링」 — 에이전트 루프 설계와 최적화의 기초부터 심화까지
마무리
하네스 엔지니어링은 여전히 중요하다. 이 논문이 보여주는 것은 “자동 진화가 충분히 좋지 않다”가 아니라 **“우리가 생각만큼 그 효과를 엄밀하게 검증하지 않았다”**는 사실이다. 에이전트 연구가 성숙해질수록, ‘무엇이 효과가 있는가’만큼 ‘그 효과를 어떻게 증명할 것인가’가 중요해진다. 이 논문은 그 방향으로의 중요한 한 걸음이다.
Paper: Rethinking the Evaluation of Harness Evolution for Agents (Wang et al., AI2 + UW, 2026) Code: github.com/rethinking-harness-evolution