코딩 에이전트 성능, 모델보다 '하네스'가 더 좌우할까

코딩 에이전트의 성능을 이야기할 때 우리는 보통 모델 이름을 먼저 본다. 그런데 같은 모델을 붙여놓고도 도구마다 결과가 다르게 나오는 일이 잦다. 최근 개발자 커뮤니티에서 회자되는 'HarnessTax'는 바로 이 지점을 겨냥한 문제 제기다. 모델 바깥에서 성능을 좌우하는 실행 골격, 즉 하네스가 만들어내는 차이를 하나의 비용처럼 따져보자는 관점이다.

여기서 하네스는 모델을 감싸 실제 작업을 수행하게 만드는 모든 장치를 뜻한다. 에이전트 루프의 형태, 시스템 프롬프트, 도구 호출 스키마, 파일을 읽고 고치는 방식, 셸 명령과 테스트 실행 절차, 컨텍스트가 길어질 때의 압축·요약 정책, 실패 시 재시도 규칙, 작업을 쪼개는 서브에이전트 구조까지 포함된다. 모델 가중치는 그대로여도 이 층이 바뀌면 에이전트가 실제로 만들어내는 결과물은 달라진다.

문제는 이 두 층이 평가에서 잘 분리되지 않는다는 점이다. 리더보드에 올라온 점수는 모델과 하네스가 함께 만든 합작품인데, 표에는 대개 모델 이름만 남는다. 그래서 'A 모델이 B 모델보다 코딩을 잘한다'는 결론이 어떤 하네스를 씌우느냐에 따라 뒤집힐 여지가 생긴다. 하네스가 모델의 실력을 깎아먹는 세금처럼 작동할 수도 있고, 반대로 모델의 약점을 가려주는 보정 장치가 될 수도 있다는 뜻이다.

이런 질문이 나오는 배경에는 코딩 에이전트가 데모 단계를 지나 실무 파이프라인으로 들어오고 있다는 변화가 있다. 저장소를 통째로 다루고, 테스트를 돌리고, 실패한 명령을 다시 시도하는 식의 긴 작업 흐름에서는 모델의 단발 성능보다 주변 장치의 설계가 결과를 크게 흔든다. 여러 도구가 비슷한 모델을 얹고 경쟁하는 상황에서 무엇이 진짜 차이를 만드는가라는 물음이 자연스럽게 따라온다.

실무에서 챙길 것은 두 가지다. 첫째, 도구를 고를 때 모델 목록만 비교하지 말고 하네스가 제공하는 기능을 함께 봐야 한다. 컨텍스트를 어떻게 관리하는지, 어떤 도구 권한을 주는지, 테스트 실행과 수정 루프가 어떻게 짜여 있는지, 실패 로그를 얼마나 재현 가능하게 남기는지가 실제 생산성을 가른다. 둘째, 자체적으로 에이전트를 평가한다면 모델을 고정하고 하네스만 바꿔보는 통제 실험을 설계하는 편이 낫다. 그래야 개선 효과가 모델 교체 때문인지 골격 변경 때문인지 구분할 수 있다.

다만 하네스의 영향력은 측정 대상과 평가 방식에 따라 크게 달라진다. 특정 벤치마크에서 관찰된 격차를 모든 저장소와 모든 작업 유형에 일반화하기는 어렵고, 태스크 정의나 채점 기준을 어떻게 잡느냐에 따라 결론이 흔들릴 수 있다. 숫자 하나를 인용하기 전에 그 숫자가 어떤 조건에서 나온 것인지 확인하는 습관은 여전히 필요하다.