모델 선택보다 중요한 건 에이전트 하니스(harness)다
The agent harness matters more than the model you pick
핵심 요약
에이전트 성능은 모델 자체보다 이를 감싸는 하니스(구조) 설계에 따라 크게 좌우됩니다.
- 하니스 중요성 — 모델을 에이전트로 만드는 코드 구조가 실제 동작과 성능을 결정함
- 벤치마크 왜곡 — 동일 모델이라도 하니스에 따라 SWE-bench 점수가 10~20점씩 차이 남
- 신뢰성 개선 — 에이전트가 불안정할 때 모델 교체보다 하니스 최적화가 더 효과적임
대부분의 에이전트 논쟁은 결국 모델 이야기로 끝남. GPT냐 Claude냐, 아니면 이번 주에 새로 나온 모델이 뭐냐 하면서 리더보드 점수 몇 점 올리는 데 급급함. 하지만 에이전트가 실제로 어떻게 행동할지를 결정하는 핵심 요소는 정작 관심을 덜 받고 있음. 바로 모델을 감싸고 있는 '하니스(harness)'임.
여기서 하니스란 모델을 감싸서 에이전트로 만들어주는 코드를 의미함. 언제 도구를 호출하고 언제 멈출지 결정하는 루프, 도구 출력값이 어떻게 컨텍스트로 다시 전달되는지, 윈도우가 꽉 찼을 때 메모리를 어떻게 정리할지, 오류와 재시도는 어떻게 처리할지, 애초에 작업을 어떻게 구성할지 같은 것들임. 모델은 그 모든 것 안에 들어있는 하나의 부품일 뿐임.
과소평가된 부분은 이거임. 똑같은 모델이라도 하니스에 따라 점수가 완전히 다르게 나옴. SWE-bench Pro에서 Claude Opus 4.5는 표준화된 스캐폴드 하나에서는 약 46%를 기록하지만, 다른 스캐폴드에서는 약 55%를 기록함. 같은 가중치, 같은 벤치마크인데 하니스만 다른 경우임. 사람들은 스캐폴드 변경만으로 동일 모델에서 10~20점의 점수 변동을 보고하고 있음. 심지어 어떤 논문에서는 하니스를 공개하지 않으면 에이전트를 공정하게 비교할 수 없다고 주장하기도 함.
이 사실로부터 두 가지 결론이 나옴.
리더보드 점수는 '모델+하니스' 점수임. 벤치마크 결과를 그대로 베껴서 자기 스캐폴드에 적용해봤자 보통은 그 점수가 안 나옴. 당신이 보고 있는 건 모델 단독의 성능이 아니라, 강력한 하니스가 그 모델을 활용해 낸 결과물임.
에이전트가 불안정할 때, 모델을 바꾸는 게 가장 먼저 할 일은 아님. 잘린 컨텍스트, 루프로 돌아오지 못한 도구 오류, 잘못된 상태 위에 쌓인 재시도 같은 것들은 하니스의 문제임. 이걸 정리하는 게 모델을 바꾸는 것보다 신뢰성을 높이는 데 훨씬 효과적임.
다른 사람들은 어떤 경험을 했는지 궁금함. 에이전트를 만들 때 모델을 바꾸는 것과 하니스를 재작업하는 것 중 무엇이 신뢰성 향상에 더 큰 도움이 됐음?
