코딩 에이전트를 도입하려는 팀이라면 대개 '어떤 모델을 쓸 것인가'를 먼저 따진다. 그러나 실제로 작업을 수행하는 것은 모델 단독이 아니라, 모델을 감싸고 파일을 읽고 명령을 실행하며 결과를 되먹임하는 '하네스(harness)'와의 조합이다. 'HarnessTax'라는 이름으로 공개된 이 평가 작업은 바로 그 지점을 정면으로 묻는다. 하네스는 실제로 무엇을 더해 주며, 그 대가는 얼마인가. 제목이 던지는 도발은 직설적이다. 당신이 쓰는 Claude 모델에는 Claude Code가 꼭 필요하지 않을 수도 있다는 것이다.
하네스라는 보이지 않는 변수
하네스는 모델과 개발 환경 사이를 잇는 실행 계층이다. 사용자의 요청을 받아 어떤 파일을 열지, 어떤 셸 명령을 돌릴지, 실패한 테스트 결과를 어떻게 다시 모델에 물려줄지를 결정하는 오케스트레이션 로직이 여기에 담긴다. 같은 모델이라도 어떤 하네스에 얹히느냐에 따라 문제 해결 절차와 도구 사용 방식이 달라지고, 그 결과 성공률과 토큰 소모량도 달라진다. 실무자 입장에서 모델 선택만큼이나 하네스 선택이 중요한 이유가 여기에 있지만, 그동안 이 변수는 벤치마크 표의 각주처럼 취급되는 경우가 많았다.
이번 평가는 그 변수를 전면에 내세운다. 일곱 개 모델과 세 개의 하네스를 교차시켜 스물한 개의 모델–하네스 쌍을 구성했다. 하네스로는 Anthropic 계열 작업 흐름에 맞춘 Claude Code, OpenAI 쪽의 Codex CLI, 그리고 Pi가 비교 대상에 올랐다. 핵심은 특정 모델을 특정 하네스에 묶어 두었을 때와 다른 하네스로 옮겼을 때, 성능이 어떻게 움직이는지를 같은 조건에서 관찰하는 데 있다.
두 벤치마크가 보는 서로 다른 능력
측정 무대는 SWE-bench Lite와 Terminal-Bench 2.0 두 가지다. SWE-bench 계열은 실제 오픈소스 저장소의 이슈를 가져와 에이전트가 코드를 수정하고 테스트를 통과시키도록 요구하는, 소프트웨어 버그 수정 중심의 과제다. Lite는 그 축소판으로, 상대적으로 가벼운 조건에서 저장소 단위의 문제 해결 능력을 본다. 반면 Terminal-Bench는 터미널 환경에서의 명령 수행과 작업 완수 능력에 초점을 맞춘다. 성격이 다른 두 벤치마크를 함께 쓴다는 것은, 코드 패치 능력과 셸 조작 능력이라는 서로 다른 축에서 하네스의 기여가 일정한지 아니면 과제 유형에 따라 갈리는지를 확인하려는 설계로 읽힌다.
'하네스 세금(harness tax)'이라는 표현이 시사하는 바도 분명하다. 더 정교한 하네스는 성능을 끌어올릴 수 있지만, 그 과정에서 추가 토큰과 왕복 호출이라는 비용을 물린다. 문제는 그 비용이 항상 그만큼의 성능 향상으로 되돌아오지 않을 수 있다는 점이다. 만약 어떤 모델이 자사 전용 하네스 없이도 대등한 결과를 낸다면, 특정 하네스에 종속될 이유는 그만큼 약해진다.
실무자가 읽어야 할 함의
이 프레임이 한국의 개발 조직에 주는 시사점은 실용적이다. 첫째, 모델과 하네스를 한 벤더의 패키지로 묶어 받아들이기보다 분리해서 평가할 여지가 생긴다. 사내 파이프라인이나 CI에 에이전트를 붙일 때, 익숙한 하네스 하나에 모든 모델을 몰아넣는 대신 과제 성격에 맞춰 조합을 바꿔 볼 수 있다. 둘째, 비용 산정의 기준이 달라진다. 단순히 모델 단가만 볼 것이 아니라, 하네스가 유발하는 호출 횟수와 토큰 소모까지 포함한 '실효 비용' 관점에서 조합을 비교해야 한다는 것이다.
다만 이 결과를 곧바로 일반화하기에는 유의할 점이 있다. 두 벤치마크 모두 통제된 과제 집합이며, 사내 레거시 코드베이스나 사내 규약이 얽힌 실제 업무 환경을 그대로 대변하지는 못한다. 하네스 세 종과 모델 일곱 종이라는 표본도 빠르게 바뀌는 생태계의 한 단면일 뿐, 버전이 오르면 우열은 재편될 수 있다. 따라서 '어느 조합이 이겼다'는 순위표보다, 하네스를 독립 변수로 놓고 자기 팀의 과제로 직접 측정해 보라는 방법론적 메시지를 취하는 편이 안전하다. 결국 중요한 것은 특정 제품의 우열이 아니라, 모델과 실행 계층을 분리해 저울질하는 습관 그 자체다.