AI 에이전트를 말할 때 가장 먼저 나오는 것은 모델 이름과 벤치마크 점수입니다. 한 모델은 더 강하고, 다른 모델은 더 저렴하며, 또 다른 모델은 코딩을 잘한다는 식으로 순위를 만들기 쉽습니다. 하지만 실제 작업을 끝내는 것은 모델만이 아닙니다. 컨텍스트, 도구, 권한, 상태, 재시도, 중단 조건을 공급하는 실행층이 함께 움직입니다.
이 실행층을 흔히 에이전트 하네스라고 부릅니다. 최종 답변은 모델이 만든 것처럼 보이지만, 실제로는 모델이 무엇을 보고 바꿀 수 있는지, 성공처럼 보이는 실행이 잘못된 산출물을 만들었는지 알아차릴 수 있는지를 하네스가 결정합니다.
Harness-Bench는 2026년 5월 공개된 연구로 이 층을 평가 대상으로 분리했습니다. 연구진은 106개의 샌드박스 오프라인 태스크에서 모델과 하네스 조합을 비교하고 5,194개의 실행 궤적을 분석했습니다. 각 실행에는 완료 여부뿐 아니라 최종 산출물, 실행 기록, 사용량 통계, 검증기 결과가 함께 남았습니다.
모델 주변의 실행 경로가 달라지면 결과와 실패가 드러나는 방식도 달라집니다.
평가 단위는 모델과 하네스의 조합입니다
이 연구가 특정 하네스가 항상 최고라고 말하는 것은 아닙니다. 더 중요한 주장은 에이전트의 능력을 기본 모델 하나가 아니라 모델과 하네스의 구성 단위로 보고해야 한다는 점입니다. 모델의 추론이 도구 반환값, 작업 공간 상태, 근거, 결과 검증 조건과 분리되는 실행 정렬 실패도 별도로 살펴야 합니다.
두 결과를 비교하기 전에 다음 조건을 고정하거나 공개해야 합니다.
| 항목 | 확인해야 하는 이유 |
|---|---|
| 모델과 버전 | 모델이 업데이트되면 같은 태스크도 행동이 달라질 수 있습니다. |
| 태스크와 초기 입력 | 숨은 준비 단계가 실제 프롬프트만큼 결과에 영향을 줄 수 있습니다. |
| 컨텍스트와 기억 | 검색된 지침은 도움을 주기도 하고 주의를 분산시키기도 합니다. |
| 도구와 권한 | 읽기 전용 에이전트와 파일을 수정·실행할 수 있는 에이전트는 다른 문제를 풉니다. |
| 시간·토큰·재시도 예산 | 복구 기회가 실패에 가까운 실행을 통과로 바꿀 수 있습니다. |
| 검증기와 산출물 계약 | 느슨한 검증기는 성공률을 부풀리고, 지나치게 엄격한 검증기는 유효한 부분 결과를 놓칠 수 있습니다. |
비교 조건을 매니페스트로 남기기
에이전트 비교 결과를 나중에도 믿으려면 실행 조건을 한 장의 매니페스트처럼 남겨야 합니다. “모델 A가 모델 B보다 점수가 높았다”는 문장만으로는 어떤 모델이 더 나았는지 알 수 없습니다. A에는 더 긴 컨텍스트가 주어졌거나, 실패한 호출을 재시도할 기회가 많았거나, 검증기가 더 느슨했을 수 있기 때문입니다.
최소한 다음 항목은 결과와 함께 공개해야 합니다.
| 기록할 항목 | 빠지면 생기는 오해 |
|---|---|
| 모델과 버전 | 업데이트로 행동이 달라졌는데 같은 모델로 비교하게 됩니다. |
| 태스크와 초기 입력 | 숨은 준비 작업이 프롬프트의 차이처럼 보입니다. |
| 컨텍스트와 기억 | 검색된 지침이 도움을 줬는지 방해했는지 알 수 없습니다. |
| 도구와 권한 | 읽기 전용 실행과 파일 수정 실행의 난도가 섞입니다. |
| 시간·재시도·토큰 예산 | 복구 기회가 성공률에 미친 영향을 놓칩니다. |
| 검증기와 산출물 계약 | 느슨한 검사나 지나치게 엄격한 검사가 결과를 왜곡합니다. |
최종 답변만 저장하면 계획이 맞았는지, 도구 호출이 실패했다가 복구됐는지, 잘못된 산출물이 약한 검증기를 통과했는지 구분할 수 없습니다. 입력, 사용한 도구, 권한 변경, 실행 결과, 사용량, 검증기 판단, 실패 이유를 같은 묶음으로 남겨야 다음 사람이 결과를 재현하거나 반박할 수 있습니다. 이 글에서 제안하는 것은 새로운 벤치마크 점수가 아니라, 공개된 연구와 작업 기록을 비교 가능한 형태로 만드는 기록 방식입니다.
실제 저장소 작업에 적용하면 매니페스트는 거창한 보고서일 필요가 없습니다. 같은 버그 수정 태스크를 비교할 때 모델 버전과 초기 저장소 상태를 고정하고, 한 실행은 읽기·테스트만 허용하고 다른 실행은 패치 작성까지 허용했는지 기록하면 됩니다. 두 결과의 차이가 모델에서 왔는지 권한에서 왔는지 먼저 분리할 수 있습니다. 네트워크를 허용했는지, 실패한 테스트를 몇 번 다시 실행했는지, 최종 파일을 어떤 검사로 확인했는지도 같은 수준에서 남겨야 합니다.
이 기록은 결과가 좋았을 때보다 실패했을 때 더 큰 역할을 합니다. 성공률만 보면 “더 강한 모델이 필요하다”는 결론으로 쉽게 달려가지만, 실제 원인이 빠진 도구·잘못된 권한·짧은 예산·검증기 오류일 수 있습니다. 실패 원인을 다시 분류할 수 있어야 다음 변경에서 무엇을 하나만 바꿀지 정할 수 있습니다.
모델만 적는 대신 도구·컨텍스트·권한·예산·검증 조건을 함께 기록해야 비교의 의미가 남습니다.
실패를 한 점수로 묶으면 안 됩니다
에이전트가 실패하는 이유는 서로 다릅니다. 태스크를 잘못 이해했을 수도 있고, 필요한 사실을 컨텍스트에서 잃었을 수도 있습니다. 필요한 권한이 없었거나, 도구 인자를 잘못 전달했거나, 위험하게 재시도했을 수도 있습니다. 좋은 산출물을 만들었지만 검증기가 알아보지 못한 경우도 있습니다. 모두를 모델 실패라고 부르면 고쳐야 할 지점을 잘못 찾게 됩니다.
같은 구분은 오케스트레이션 시스템에도 적용됩니다. Drig의 공개 워크플로는 기획, 일반 구현, 코드 리뷰, QA, 결정론적 전달 단계를 나눕니다. 이것이 모든 프로젝트에 더 많은 에이전트가 필요하다는 뜻은 아닙니다. 각 단계의 책임자, 남겨야 할 증거, 실패를 차단해야 하는 전환을 분리해 볼 수 있다는 뜻입니다.
실무에서 비교하는 방법
모델을 비교한다면 도구·컨텍스트·권한·예산·검증기를 고정하고 모델만 바꿔야 합니다. 하네스를 비교한다면 모델과 태스크 집합을 고정한 뒤 추가된 재시도, 검색된 컨텍스트, 도구 범위, 복구 동작을 공개해야 합니다. 최종 답변만 보지 말고 실제 산출물과 실행 기록, 도구 결과, 사용량, 검증 결과, 실패 이유를 함께 남겨야 합니다.
이 글은 로컬에서 새로 통제된 벤치마크를 수행한 결과가 아닙니다. 인용한 연구와 공개된 워크플로 문서를 읽고 정리한 판단입니다. 다음 실험은 모델, 도구 경계, 기억, 복구 정책을 한 번에 하나씩만 바꾸는 방식이어야 합니다. 그래야 점수의 차이가 무엇 때문에 생겼는지 설명할 수 있습니다.
