하네스가 사는 것은 토큰뿐? Claude Code·OpenCode·mini-SWE-agent를 같은 모델로 돌려본 논문

"우리가 측정한 하네스 효과는 전부 과제를 잃는 방법이었고, 과제를 얻는 방법은 하나도 없었다." — 논문 1절

2026년 10월 3일 산둥대학교의 Yangze Liu와 Zhongyi Han이 What Does a Harness Buy? Tokens, Mostly.(arXiv 2610.04433)를 공개했고, 10월 27일 AI타임스가 "성능은 그대로, 비용은 최대 3배"라는 제목으로 보도했다(기사는 산둥대와 UC버클리 공동 연구라고 썼지만, 논문과 공개 저장소에 적힌 소속은 산둥대뿐이다). 코드와 8,032건의 trial 테이블은 github.com/YangzeLiu/what-does-a-harness-buy에 올라와 있고, reproduce.sh 하나로 논문의 모든 표와 그림을 다시 만든다. 전체 trajectory는 "논문과 함께 공개 예정"이라고만 적혀 있다.

이 블로그의 하네스 시리즈는 지금까지 하네스를 키우는 쪽 글이었다. Effective harnesses는 사람이 하네스를 설계했고, Raven은 하네스를 조합했으며, RRSI와 Harness², ScholarEvolve는 하네스가 스스로를 고쳤고, 루프 엔지니어링은 그 바깥 루프를 다뤘다. 이 논문은 그 전제를 정면으로 묻는다. 모델을 고정했을 때, 복잡한 하네스가 실제로 더 잘 푸는가? 그래서 이 글은 시리즈의 반론 편이다.

원문: https://arxiv.org/abs/2610.04433

🤔 배경: 하네스 비교는 왜 읽기 어려운가

저자들이 꼽는 문제는 두 가지다. 첫째, 기존 하네스 비교는 거의 전부 셀당 한 번 실행인데, SWE-bench Verified에서 같은 설정을 열 번 돌리면 이미 2.2~6.0점이 퍼진다(Bjarnason et al., 2026). 둘째, 비교되는 하네스들이 같은 조건에 있지 않다. 같은 백본에 최소 어댑터를 붙이면 19.1%, 완전한 어댑터를 붙이면 73.4%가 나온 연구도 있다(Zheng et al., 2026). "하네스를 바꾸는 것이 같은 하네스를 다시 돌리는 것보다 점수를 더 움직이는가"는 같은 과제·같은 모델에서 측정된 적이 없었다는 것이 출발점이다.

📐 실험 설계

하네스 3종은 출시된 그대로 버전을 고정했다. Claude Code 2.1(2.1.2592.1.273), mini-SWE-agent 2.4.6, OpenCode 1.18(1.18.3031). 논문의 설명대로 적으면 mini-SWE-agent는 bash 도구 하나만 노출하고, 아주 긴 관찰값을 자르는 것 말고는 컨텍스트 관리가 없으며, 모델의 컨텍스트 창에 닿으면 그냥 멈춘다. 약 100줄의 Python으로 SWE-agent 점수에 도달한다는 것이 '최소'의 근거다. Claude Code와 OpenCode는 타입이 있는 파일·검색·편집 도구, 긴 시스템 프롬프트, 자동 compaction을 가진 완제품이고, 하나는 닫혀 있고 하나는 열려 있다. 세 하네스 모두 샘플링 파라미터를 보내지 않고, 모델 호출 1회를 1스텝으로 세어 300스텝 예산을 공통으로 둔다. DeepSeek의 공식 CLI 하네스(dsh)도 DeepSeek 모델에서 "홈 필드 점검"용으로 돌렸다.

모델은 다섯이다. Qwen3.6-35B-A3B와 Qwen3.8-27B는 vLLM 0.27.1로 직접 서빙했고, DeepSeek-V4-Flash(0731), GLM-5.3-Flash, HY4-Preview는 벤더 API로 불렀다. Claude Opus 5는 Claude Code 안에서만 돌려 상단 기준점으로 썼다. 오케스트레이션은 Harbor 0.22.0, trial마다 컨테이너 하나다.

과제는 SWE-bench Verified 500개 중 검증에 외부 웹 서비스가 필요한 psf/requests 8개를 빼 492개. 난이도 표기가 '1~4시간'(42개)과 '4시간 초과'(3개)인 hard45를 통째로 떼고, 나머지 pool447은 직접 서빙한 Qwen 두 모델에서만 돌렸다. 에이전트 단계는 모델 엔드포인트 외에 네트워크가 없다. 초기 웹 허용 실행을 감사했더니 DeepSeek·Qwen trial의 71%가 GitHub에서 업스트림 수정을 가져왔고(그 trial의 96%가 통과), 그 결과는 전부 폐기하고 네트워크 계층에서 차단했다.

반복과 비용 계산. 각 셀의 점수는 "첫 번째 예정 실행"으로 미리 규칙을 정했고, 같은 설정의 재실행은 분리해 점수가 저절로 얼마나 움직이는지만 재는 데 쓴다. hard45에서는 Qwen 두 모델의 모든 셀과 DeepSeek의 Claude Code 셀이 2회, Opus 5가 3회이고, pool447에는 재실행 쌍이 하나(mini-SWE-agent × Qwen3.6)다. 비용은 trial마다 자기 토큰 수를 캐시 히트 입력·캐시 미스 입력·출력으로 나눠 벤더 정가로 계산한다. 그래서 금액(CNY)이 붙는 모델은 DeepSeek-V4-Flash와 GLM-5.3-Flash뿐이고, Qwen은 토큰 수만, Opus는 구독이라 금액이 없다. 통계는 과제 단위로 짝지은 McNemar 정확검정과 Newcombe 구간이고, pool447에서는 $\delta = 5$점 동등성 검정(TOST)을 추가한다.

📊 결과 1: 하네스는 통과율을 거의 움직이지 않는다

그림 1(a)가 논문의 요약이다. 같은 모델의 세 점은 토큰 축으로는 2~3배 벌어지지만 통과율 축으로는 45개 과제가 겨우 절반의 확률로 잡아내는 13점 폭 안에 들어 있다. hard45 표(Table 2)를 옮기면 다음과 같다. 첫 실행 기준, 45개 중 통과 수다.

세 하네스의 폭은 모든 모델에서 2~5개 과제이고, 같은 셀을 다시 돌리면 최대 3개가 움직인다. 순위도 고정되지 않아 mini-SWE-agent가 다섯 모델 중 셋에서, Claude Code가 둘에서 앞선다. 가장 강한 HY4-Preview에서도 Claude Code는 mini-SWE-agent에 6.7점 뒤지고 mini-SWE-agent는 OpenCode를 11.1점 앞서지만 둘 다 $p = .45$, $.12$로 45개 과제가 분해할 수 있는 크기가 아니다.

447개 과제(Table 1)에서는 검정력이 생긴다. Claude Code와 mini-SWE-agent의 차이는 Qwen3.6에서 −1.8점 [−5.2, +1.6], Qwen3.8에서 −1.4점 [−4.2, +1.5]이고, 90% 구간이 ±5 안에 들어 5점 기준으로 동등하다. 가장 무거운 하네스와 가장 가벼운 하네스가 같은 점수를 낸 것이다. 노이즈를 넘는 쌍은 전부 OpenCode가 뒤처지는 쪽이다. Qwen3.6에서 mini−OC +4.7점($p = .02$), Qwen3.8에서 CC−OC +7.9점, mini−OC +9.2점(둘 다 $p < .001$). Holm 보정 뒤에는 Qwen3.8의 두 격차만 남는다.

그림 2가 "노이즈"라는 말을 수치로 만든다. 두 실행 사이에 결과가 뒤집힌 과제 비율(flip rate)을 재면, hard45에서 같은 하네스 재실행이 중앙값 13%, 하네스 교체도 13%, 모델 교체는 22%다. 더 중요한 건 하네스가 이긴 과제가 반복되지 않는다는 점이다. 양쪽 다 2회 돌린 여섯 하네스 쌍에서, 1차 실행에서 갈린 과제가 2차에서 같은 방향으로 갈린 경우는 5개, 반대로 갈린 경우는 7개였다. 동전 던지기와 구별되지 않는다. 반면 모델 교체는 15개 중 10개가 같은 방향이었다. 이 분산에서 45개 과제는 12.9점 격차를 절반의 확률로만 잡고 80% 검정력으로는 아무 격차도 못 잡으며, 447개 과제는 5.2점을 분해한다. 저자들은 발표된 하네스 개선치 상당수가 첫 숫자 아래, 일부는 둘째 숫자 아래에 있다고 지적한다.

하네스 안을 들여다본 결과도 같다. Claude Opus 5 + Claude Code에서 파일 편집 도구를 빼고 bash로만 편집하게 하거나, 반대로 쉘을 빼거나, 1년 전 릴리스(1.0.100)를 쓰거나 전부 대조 실행 3회(35~36/45)의 ±1 과제 안이었다. 1년 전 릴리스는 확장 사고를 기본으로 켜지 않아 비용만 0.44배였다. Terminal-Bench 2.1의 50개 과제로 옮겨도 19/20/20으로 순서가 안 보인다.

💸 결과 2: 하네스가 정하는 것은 청구서다

청구서는 대략 스텝당 입력 × 스텝 수이고, 하네스는 두 항을 모두 움직인다. 그림 4는 호출마다 모델이 읽는 토큰을 스텝 순서로 그린 것인데, 세 하네스는 첫 호출에서 이미 갈라진다. GLM-5.3-Flash에서 첫 호출은 Claude Code 17.1k, OpenCode 7.6k, mini-SWE-agent 1.4k 토큰이고 DeepSeek에서도 같은 크기다. 이 중 과제 설명을 뺀 하네스 자체의 preamble, 즉 시스템 프롬프트·도구 스키마·메시지 래퍼가 Claude Code 16,581, OpenCode 7,025, mini-SWE-agent 829 토큰이며 매 스텝 다시 지불된다. 기울기는 세 하네스가 1.5배 이내(GLM에서 스텝당 937/648/681 토큰)라 차이가 훨씬 작다. 도구가 돌려주는 텍스트도 호출당 평균·90분위 모두 비슷하다(Table A4). 하네스를 가르는 것은 저장소의 텍스트가 아니라 하네스 자신의 텍스트다. Claude Code는 모델의 reasoning을 transcript에 남겨 다시 보내는 것으로 재구성되는데, 이 항은 관측이 아니라 적합(fit)에서 추론된 것이라고 저자들이 분명히 적어 두었다.

그 결과가 그림 5(논문 Figure A3)다. GLM-5.3-Flash에서 Claude Code와 mini-SWE-agent는 스텝 수가 비슷해서(88 대 80) 격차는 스텝당 무게에서 나오고, trial당 1.81 CNY 대 0.97 CNY다. OpenCode는 스텝당 가볍고 가장 일찍 멈추니 0.56 CNY로 가장 싸다. 여기서 "최대 3배"가 나온다. 그런데 DeepSeek-V4-Flash에서는 스텝 수가 갈린다. mini-SWE-agent가 141스텝을 쓰는 동안 Claude Code는 104스텝이고, 가벼운 하네스의 transcript가 매 스텝 자라면서 가장 많은 토큰(11.5M)을 옮긴다. 금액은 0.98 대 1.02 CNY로 역전된다. 스텝당 무게와 스텝 수는 서로 맞바꾸는 관계이고 어느 쪽이 이기는지는 모델이 정한다.

캐시 가격은 청구서의 크기를 바꾸지 순서를 바꾸지 않는다. 매 스텝 직전 transcript를 다시 보내므로 입력의 96~99%가 캐시 히트이고, Zhipu는 히트를 미스의 0.287배, DeepSeek은 0.033배로 받는다. 그래서 GLM에서는 캐시된 transcript가 청구서의 대부분이고 DeepSeek에서는 절반 이하라 출력 항이 같은 크기가 된다. 각 모델의 토큰을 상대 벤더 가격표로 다시 계산해도 세 하네스의 순서는 그대로다. 벤더 하네스도 예외가 아니었다. DeepSeek의 dsh는 DeepSeek 모델에서 21/45로 Claude Code와 같고 mini-SWE-agent보다 하나 적으면서, trial당 1.04 CNY로 넷 중 가장 비쌌다.

🔍 결과 3: 하네스는 과제를 잃는 방법이다

노이즈를 넘는 유일한 효과인 OpenCode의 손실은 trajectory에서 원인이 읽힌다. 첫째, 복구 없는 출력 한도다. OpenCode의 provider 설정은 응답 하나를 32k 출력 토큰으로 제한하는데, 모델의 reasoning이 스텝 중간에 그 한도를 넘으면 OpenCode는 다시 프롬프트하지 않고, 마지막 스텝에서 잘린 trial은 디스크에 있는 것, 보통은 아무것도 없는 상태로 끝난다. pool447 × Qwen3.8-27B에서 OpenCode의 33개 trial이 이렇게 실패했다(잘린 trial의 통과율 7.9% 대 나머지 75.9%, 34개 중 32개는 저장소를 건드리지도 못한 채 중앙값 11스텝에서 종료). 같은 모델에서 같은 한도에 걸린 Claude Code는 52개 trial에서 66번 잘렸지만 64번은 하네스의 resume 프롬프트로 세션이 이어졌고, 한도에서 끝난 trial은 하나다. 잘리지 않은 과제만 세면 OpenCode의 격차는 대략 절반이 된다. 둘째, 일찍 멈추는 습관이다. 컷오프가 하나도 없는 Qwen3.6 × pool447에서도 OpenCode는 중앙값 28회 호출에서 끝나는데 mini-SWE-agent는 71, Claude Code는 55다. 무엇이 모델을 일찍 멈추게 하는지 데이터는 말해주지 않고, 짧은 실행과 잃은 과제가 함께 다닌다는 것만 보인다.

나머지 실패 유형도 전부 손실이고 각각 설계 선택 하나로 추적된다. mini-SWE-agent는 compaction이 없어 Qwen3.8-27B에서 hard45의 11개, pool의 18개 과제가 컨텍스트 창에서 끝났다. 다만 그 과제의 대부분은 다른 두 하네스도 실패한 과제라, 다른 하네스가 푼 것만 되살려도 hard45에서 6.7점 이동이고 재실행하면 11개 중 7개가 다시 넘친다. 오버플로는 대개 모델이 이미 지고 있던 과제의 증상이라는 것이 저자들의 해석이다. Claude Code와 OpenCode는 compaction 덕에 창에서는 최대 1개만 잃지만 자기 한도에서 진다. OpenCode는 Qwen3.8 × hard45에서 6개 과제가 벽시계 한도(5,760초, Claude Code는 36,000초)에서 끊겼는데, 저자들은 이를 하네스 효과가 아니라 통제 안 된 요인으로 보고한다. 또 OpenCode는 출시 상태로는 첫 사용 시 ripgrep을 내려받기 때문에 오프라인에서 검색 도구가 안 돌아, 미리 바이너리를 넣은 arm을 본 결과로 썼다.

흥미로운 교차 효과가 하나 있다. Qwen3.6-35B-A3B의 thinking을 서빙 계층에서 끄면 Claude Code는 +2.2, OpenCode는 +3.4점으로 노이즈 안에서 움직이지만 mini-SWE-agent는 −11.1점($p = .04$)이다. 반대로 HY4-Preview에서 Claude Code 안의 thinking을 끄면 11점이 빠진다. 명시적 추론 의존도는 모델만이 아니라 모델·하네스 쌍에 속한다는 것이 저자들이 "추적하고 싶은 단 하나의 단서"다.

💡 저자 권고와 기사의 정리

논문 본문이 직접 권고하는 것은 하나다. 같은 셀을 한 번 더 돌리는 것이 하네스 비교에서 가장 싼 통제이며, 대부분의 비교가 이것을 건너뛰니 어떤 하네스 격차든 재실행 격차 옆에 나란히 보고하라는 것. 그리고 벤더를 넘어 들고 다닐 숫자는 첫 호출 크기, 스텝당 증가량, 스텝 수 세 가지라고 적는다. 기사에 따르면 연구진은 여기에 더해 시스템 프롬프트와 도구 정의를 간소화하고, 실제 쓰는 모델에서 비용과 성능을 반복 측정해 개선이 확인되는 기능만 남기라고 조언했다. 이 두 가지는 논문의 "엔지니어링을 손실이 있는 곳에 두라"는 결론과 비용 분해에서 자연스럽게 따라 나오지만, 논문에 그 문장 그대로 있지는 않다. Claude Code가 OpenCode에 없는 resume 프롬프트 하나로 33개 trial을 구한 것이 "손실이 있는 곳"의 가장 구체적인 예다. 다만 그 프롬프트를 OpenCode에 이식해 41개 과제를 다시 돌린 결과는 0.585→0.634로 6개 개선, 2개 악화, 33개 동점($p = .29$)이었고, 폭주 reasoning이 같은 과제에서 다시 나는 비율은 약 15%에 그쳤다. 그 실패는 과제가 아니라 실행에 속한다.

🧐 비판적으로 읽기

범위. 결과는 SWE-bench Verified 하나에서 나왔고, 과제는 오프라인이며 한 번의 이슈 해결로 끝난다. 사용자와 주고받는 긴 세션, 저장소 전체 리팩터링, 네트워크를 쓰는 과제에서는 compaction·권한·도구 설계가 다른 방식으로 작동할 수 있다. 저자들도 Terminal-Bench 2.1 한 모델 점검은 전이 확인일 뿐이고 "범용 에이전트는 다른 체제일 수 있다"고 적었다. 또 닫힌 프런티어 모델은 Claude Code에서만 돌았으므로 세 하네스 사다리는 HY4-Preview에서 멈춘다.

공정성. Claude Code를 Anthropic 모델이 아닌 엔드포인트에 붙이면 Grep 도구가 빠지고 Bash로 검색하며, HY4 arm에서는 리버스 프록시가 시스템 메시지를 접는 등 변환이 들어간다. Qwen arm의 compaction 창은 OpenCode와 맞추려 110k로 덮어썼지만 벤더 API arm에서는 Claude Code 기본값이라 GLM에서 중앙값 168k에서야 compaction이 돈다. 벽시계 한도도 Qwen arm에서 비대칭이다. 저자들은 이를 부록 A에 전부 적어 두었지만, "출시된 그대로"라는 설계 원칙은 통제와 맞바꾼 것이다.

비용의 단위. "3배"는 토큰이 아니라 벤더 정가 CNY이고, GLM-5.3-Flash 한 모델의 숫자다. DeepSeek에서는 Claude Code가 mini-SWE-agent보다 싸다. 캐시 가격이 순서는 안 바꾼다는 점이 이 비교를 토큰 수에 가깝게 읽을 수 있게 해 주지만, Opus의 비용 열은 구독 사용분을 정가로 환산한 "노력 지수"라 지출이 아니다.

반복 횟수. 재실행은 hard45의 일부 셀에서 2회, Opus에서 3회, pool447에서 쌍 하나다. "하네스 격차 = 재실행 격차"라는 결론은 열 쌍의 재실행에 기대고 있고, 결론도 "효과가 없다"가 아니라 "이 설계로는 분해할 수 없다"로 읽어야 한다.

시리즈의 다른 논문과 어떻게 양립하는가. Harness²는 WorkBuddy-Bench에서 +11.5pp, RRSI는 SWE-bench Verified OOD에서 +1.8점(Opus 4.8)을 보고했고, Raven은 SWE-bench Verified에서 +0.6점이 paired-gain 기준을 넘지 못했다고 스스로 적었다. 이 논문의 자로 재면 RRSI의 +1.8과 Raven의 +0.6은 447개 과제가 분해하는 5.2점보다 작고, Harness²의 두 자릿수 이득은 다른 벤치마크(컨테이너 안의 업무 과제, 루브릭 채점)와 다른 단위(완성품 하네스 교체가 아니라 같은 하네스 안의 컴포넌트 편집)에서 나온 숫자다. 모순이라기보다 측정 대상이 다르다. 이 논문이 보여준 것은 "SWE-bench Verified에서 완성품 하네스 세 종을 바꾸는 효과는 재실행 노이즈 수준"이고, 시리즈의 자기 개선 논문들이 보여준 것은 "특정 벤치마크·모델 쌍에서 하네스 편집으로 몇 점을 벌 수 있다"는 것이다. 두 결과 사이의 다리는 RRSI가 과적합의 한 형태로 꼽은 noise chasing이다. 재실행 분산을 재지 않은 채 벌어들인 점수는 이 논문이 말하는 13% flip의 일부일 수 있고, 그래서 Harness²·RRSI가 3회 스트림 평균과 paired bootstrap을 붙인 것은 이 논문의 권고와 같은 방향이다.

📝 정리와 열린 질문

이 논문이 사는 것은 "하네스는 쓸모없다"가 아니다. 모델을 고정하면 하네스는 통과율을 거의 움직이지 않고, 과제를 잃는 방법을 결정하며, 청구서를 결정한다는 세 문장이다. 그 청구서는 첫 호출의 preamble(16,581 대 829 토큰)과 스텝 수로 거의 설명된다.

남는 질문은 이렇다. 이 논문의 모델은 전부 오픈웨이트나 저가 API이고, Opus 5는 Claude Code 안에서만 돌았다. 자기 하네스에 맞춰 학습된 모델(논문이 인용한 DCAS는 스캐폴드를 옮기면 최대 29점이 빠진다고 보고)에서도 하네스 교체가 노이즈일까. thinking 의존도가 모델·하네스 쌍에 속한다는 단서는 어디까지 일반화되는가. 그리고 16k 토큰의 preamble이 SWE-bench에서 아무것도 사지 못한다면, 그 preamble은 어떤 과제를 위해 거기 있는 것일까.

📚 참고

• 원문: What Does a Harness Buy? Tokens, Mostly. (Yangze Liu, Zhongyi Han, Shandong University, arXiv 2610.04433, 2026.10.03) · HTML
• 코드·데이터: github.com/YangzeLiu/what-does-a-harness-buy (trial 테이블 8,032행, 분석 스크립트, Harbor job 파일; MIT / CC BY 4.0)
• 기사: "성능은 그대로, 비용은 최대 3배"…에이전트 가로막는 '복잡한 하네스' (AI타임스, 박찬 기자, 2026.10.27)
• 하네스: Claude Code, mini-SWE-agent, OpenCode, Harbor
• 노이즈 관련 선행 연구: Bjarnason et al., On randomness in agentic evals (2026); Vats & Golev, The scaffold effect in coding agents (2026)
• 이 블로그의 하네스 시리즈: Effective harnesses · Raven · RRSI · Harness² · ScholarEvolve · 루프 엔지니어링

본 글의 그림은 원문에서 가져왔습니다(arXiv HTML의 SVG를 렌더링).