#35를 이 질문으로 끝냈다. “저 점수는 모델이 낸 것인가, 하네스가 받쳐준 것인가?” 그 글에서 근거로 쓴 LangChain과 Faros 사례는 둘 다 “우리 하네스를 고쳤더니 올랐다”는 자기 개선 보고였다. 설득력은 있지만 비교 실험은 아니다.
그 비교 실험을 정면으로 한 논문이 엿새 전에 나왔다. ToFu: A White-Box, Token-Efficient Agent Harness for Researchers. 모델 3개를 고정해 두고 하네스만 3개를 갈아 끼우며 SWE-bench Verified를 돌린 것이다. 결과부터 말하면, 하네스만 바꿨는데 정답률이 최대 9%p 갈렸다.
실험 설계가 정확히 그 질문이다
저자들은 Claude Opus 4.6, GLM 5.1, DeepSeek-v4-pro 세 모델 각각을 세 하네스 — 자기네 ToFu, Claude Code, 오픈소스 OpenCode — 에 물려 SWE-bench Verified 500문제를 풀게 했다. 논문 Table 1의 수치를 그대로 옮긴다.
| 모델 | 하네스 | Pass@1 | 평균 토큰 | 평균 비용 |
|---|---|---|---|---|
| Opus 4.6 | ToFu | 83.2% | 663,881 | $5.13 |
| Claude Code | 79.6% | 837,764 | $4.97 | |
| OpenCode | 74.2% | 757,925 | $7.00 | |
| GLM 5.1 | ToFu | 80.4% | 575,255 | $1.19 |
| Claude Code | 77.6% | 1,020,453 | $1.67 | |
| OpenCode | 71.6% | 568,097 | $0.81 | |
| DeepSeek-v4-pro | ToFu | 80.2% | 1,110,192 | $1.66 |
| Claude Code | 75.2% | 1,401,574 | $1.86 | |
| OpenCode | 71.8% | 831,294 | $1.08 |
세 모델 평균으로 ToFu는 Claude Code보다 Pass@1이 3.8%p, OpenCode보다 8.7%p 높다. 토큰은 Claude Code 대비 평균 28.4% 적게 썼고, GLM 5.1에서는 43.6%까지 벌어졌다.
표에서 눈여겨볼 건 순위가 아니라 간격의 크기다. 같은 GLM 5.1이 하네스에 따라 71.6%에서 80.4%까지 움직인다. 이 9%p는 모델 세대를 하나 올려야 나올 법한 차이인데, 모델은 한 글자도 안 바뀌었다. #35에서 “벤치 순위 = 모델 성능 등식이 깨졌다”고 썼을 때 필요했던 게 바로 이런 통제된 숫자다.
그리고 또 하나 — 토큰을 더 쓴 쪽이 더 못 맞혔다. Claude Code는 세 모델 모두에서 ToFu보다 토큰을 많이 쓰고도 점수가 낮다. 테스트 타임 컴퓨트를 늘리면 성능이 오른다는 통념이 하네스 층위에서는 성립하지 않는다는 얘기다. 낭비되는 토큰은 계산이 아니라 그냥 소음이다.
비결은 3계층 컨텍스트 압축
ToFu가 토큰을 아끼는 방법은 한 방이 아니라 세 단계다. 논문 Section 2.2 기준으로 정리하면 이렇다.
1층 — 도구 출력 외부화. 검색, 명령 실행, 웹 페치의 큰 결과물을 컨텍스트에 통째로 싣지 않는다. 파일로 빼두고 짧은 미리보기와 참조만 남긴다. 모델은 “증거가 어디 있는지”는 알지만 전문을 계속 들고 다니지 않는다. 단, 파일 읽기 결과는 보수적으로 다룬다 — 지웠다가 같은 파일을 또 읽는 낭비를 막기 위해서다.
2층 — 캐시 인식 마이크로 컴팩션. 오래된 도구 출력과 낡은 추론 블록을 짧은 플레이스홀더로 치환한다. 여기서 설계가 영리한데, 이 과정은 LLM 호출 없이 결정론적으로 돌고, 캐시된 프리픽스는 건드리지 않는다. 요약하느라 토큰을 쓰고 프롬프트 캐시까지 날리는 이중 손해를 피하는 것이다.
3층 — 쿼리 인식 의미 요약. 컨텍스트 한계에 다다르면 그제서야 경량 모델이 과거 턴을 요약한다. 기준은 ’오래됐나’가 아니라 ’지금 질문과 관련 있나’다. 핵심 턴은 원문 수준으로 보존하고, 곁가지는 한 줄로 줄이고, 무관한 턴은 버린다.
Claude Code 사용자라면 auto-compact가 떠오를 텐데, 둘은 구조가 다르다. auto-compact는 임계치에서 대화 전체를 LLM으로 요약하는 큰 이벤트 하나다. ToFu는 그 큰 이벤트가 오기 전에 싼 수단 두 개(외부화, 결정론적 치환)로 압력을 계속 빼서, 비싼 요약을 최대한 늦추고 드물게 만든다. #30에서 다룬 컨텍스트 엔지니어링의 원칙(컨텍스트는 유한한 예산이다)을 지출 시점별로 계층화한 셈이다.
토큰 절감이 비용 절감은 아니었다
표를 다시 보면 이상한 줄이 하나 있다. Opus 4.6에서 ToFu는 토큰을 21% 덜 썼는데 비용은 오히려 $0.16 더 나왔다 ($5.13 vs $4.97). GLM과 DeepSeek에서는 토큰 절감이 비용 절감으로 그대로 이어졌는데 Opus만 역전이다.
논문은 이 역전의 원인을 따로 분석하지 않았고, 저자들도 “토큰 효율과 성능의 트레이드오프를 정량 분석하지 못했다”고 한계로 인정한다. 다만 청구서의 구조를 아는 사람이라면 짚이는 데가 있다. 비용은 토큰 수가 아니라 토큰 수 × 단가의 합이고, 단가는 캐시 적중 여부에 따라 10배쯤 갈린다. Claude Code는 자사 모델의 캐시 경제에 극도로 최적화된 하네스다. 컨텍스트를 건드리면 토큰 총량은 줄어도 캐시 재사용이 깨질 수 있고, 단가가 비싼 프런티어 모델에서는 그 손해가 절감분을 삼킬 수 있다.
실전 함의는 명확하다. 하네스를 고를 때 “토큰 몇 % 절감”이라는 숫자만 보지 말고 청구서로 검증하라. 절감 기법이 캐시와 어떻게 상호작용하는지에 따라, 같은 기법이 GLM에서는 30% 절약이고 Opus에서는 적자일 수 있다.
한국어 사용자에게는 아직 아니다
ToFu의 다국어 처리는 translate-then-reason 방식이다. 비영어 입력을 영어로 번역해 추론하고 답을 역번역하는 파이프라인으로, 논문은 이걸로 10개 언어 중 7개에서 성능을 올렸다고 보고한다. 그 7개 목록에 한국어가 있을 것 같지만, 없다. 개선된 쪽은 스페인어·독일어·아랍어·러시아어·일본어·포르투갈어·힌디어이고, 한국어는 히브리어·이탈리아어와 함께 효과가 없거나 소폭 하락한 3개 쪽이다 (Section 4.3, Figure 3).
왜 한국어만 빠졌는지 논문은 설명하지 않는다. 코드 이슈 텍스트의 번역 품질 문제일 수도, 요즘 프런티어 모델의 한국어가 이미 번역 우회가 불필요할 만큼 좋아진 것일 수도 있다. 어느 쪽이든 결론은 같다 — “영어로 번역해서 추론시키면 낫다”는 오래된 요령은 이제 언어별로 검증하고 쓸 것. 평균 +2.5%p라는 헤드라인 숫자 뒤에 내 언어가 그 평균에 못 드는 경우가 있다.
이 논문을 받을 때 주의 3가지
첫째, 벤치마크 수치는 전부 저자 셀프 리포트다. 제3자 재현은 아직 없다. 하네스 비교는 설정 하나로 결과가 크게 흔들려서 측정 조건 공개를 요구하는 논문이 따로 나올 정도로 민감한 영역이다. “논문 주장에 따르면”이라는 괄호를 계속 붙여 읽어야 한다.
둘째, ablation이 없다. 3계층 압축, planner-worker-critic 루프, BM25 메모리 중 어느 부품이 성능을 끌었는지 논문은 분해해 보여주지 않는다. “3계층 압축 덕분에 이겼다”는 서사는 그럴듯하지만 아직 증명이 아니라 추정이다.
셋째, 이름에서 오해하기 쉬운 게 둘 있다. 저자 소속 “Northeastern University”는 보스턴이 아니라 중국 선양의 동북대학이다. 기계번역으로 유명한 NiuTrans 연구실(Tong Xiao, Jingbo Zhu)과 Meituan의 합작이고, 다국어 파이프라인에 공을 들인 이유도 이 배경으로 읽으면 자연스럽다. 그리고 GitHub 레포는 논문의 “Claude Code를 이기는 코딩 하네스”가 아니라 Flask 기반 셀프호스팅 AI 어시스턴트로 자신을 소개한다. 논문의 프레이밍과 제품의 포지셔닝 사이에 간극이 있다는 것도 알고 받아들이는 게 좋다.
사람들이 진짜 원한 것 — 열어볼 수 있는 하네스
주의점을 셋이나 달았지만, 이 논문에서 정말 값진 건 수치의 정확성이 아니라 물건의 성격이라고 본다. 제목의 “white-box”가 그 방향이다.
#35에서 하네스 엔지니어링이 직무가 됐다고 썼는데, 직무에는 실험대가 필요하다. 그런데 지금까지 최고 성능 하네스들은 전부 상용 블랙박스였다. Claude Code의 컴팩션이 정확히 언제 무엇을 버리는지, 시스템 프롬프트가 어떻게 생겼는지는 밖에서 알 수 없고, 바꿔서 실험할 수는 더더욱 없다. 하네스가 성능을 좌우한다는 걸 다들 알게 됐는데 정작 그 하네스를 열어볼 방법이 없었던 것 — 이게 ToFu가 겨냥한 수요다. MIT 라이선스로 전체 코드가 공개돼 있으니, 3계층 압축의 임계치를 바꿔 돌려보는 것도, 2층만 떼어 내 하네스에 이식하는 것도 각자 해볼 수 있다. 저자들이 못 낸 ablation을 커뮤니티가 대신 낼 수 있는 구조다.
#35의 마지막 질문 — 저 점수는 모델이 낸 것인가, 하네스가 받쳐준 것인가 — 에 이 논문은 통제실험이라는 형식으로 답했다. 다음 벤치마크 발표에서 물어야 할 질문이 하나 늘었다. 저 하네스, 열어볼 수 있는가?
참고: ToFu: A White-Box, Token-Efficient Agent Harness for Researchers (arXiv 2607.11423, 2026-07-13), NiuTrans/ToFu (GitHub, MIT), Stop Comparing LLM Agents Without Disclosing the Harness (arXiv). 수치는 2026-07-19 기준 논문 v1의 저자 보고치이며, 제3자 재현 결과는 아직 없다.