모델이 아니라 하네스: 같은 LLM이 올바른 스캐폴딩 없이는 왜 토큰을 4배나 태우는가

토큰 비용에 관한 논의 전체를 다시 짜맞추는 차트 하나가 돌아다니고 있습니다. 한 엔지니어가 같은 모델에서 180개의 동일한 코드 수정 과제를 실행하면서 실행 사이에 딱 한 가지만 바꿨습니다 — 모델을 감싸는 스캐폴딩, 즉 하네스입니다. 맨몸의 모델은 그중 **6.7%**를 풀었습니다. 올바른 하네스와 함께라면 68% — 그것도 그곳에 도달하기까지 토큰을 4배 적게 쓰면서 말입니다.

같은 가중치. 같은 과제. 배선 하나만으로 성공률은 10배, 비용은 4배가 흔들렸습니다.

분석가 Aakash Gupta는 그 비즈니스적 함의를 직설적으로 정리했습니다: “모델은 누구나 가진 범용재입니다. 하네스는 당신의 성을 둘러싼 해자 — 당신의 경쟁 우위입니다.” 이 글은 그 아이디어를 이 블로그가 관심을 두는 단 하나의 렌즈로 읽습니다: 토큰. 하네스는 정확도가 사는 곳일 뿐만 아니라 — 청구서가 사는 곳이기 때문입니다.

이 글은 LLM에서 토큰을 절약하는 방법의 자매편입니다. 그 가이드가 전술 목록이라면, 이 글은 그 모든 전술 아래에 깔린 원리 — 그리고 그 목록 전체가 결국 하네스 엔지니어링인 이유입니다.

1. “하네스”가 실제로 의미하는 것

모델은 엔진입니다: 다음 토큰을 예측하는 순수한 능력. 하네스는 그 엔진을 실제로 일을 해내는 에이전트로 바꿔주는, 엔진을 둘러싼 모든 것입니다:

• 과제가 어떻게 틀지어지는가 (시스템 프롬프트, 도구 문서, 예시);
• 어떤 도구를 갖고 있으며 그 결과가 어떻게 돌아오는가;
• 저장소/파일/이력을 얼마나, 어떤 형태로 보는가;
• 실패했을 때 무슨 일이 벌어지는가 — 맹목적으로 재시도하는가, 아니면 방향을 잡아주는가;
• 단계와 세션 사이에 무엇을 기억하는가.

Claude Code는 하네스입니다. Cursor도, Codex도, 손으로 짠 에이전트 루프도 마찬가지입니다. 동일한 모델을 구동하는 두 하네스는 엄청나게 다른 결과 — 그리고 엄청나게 다른 토큰 청구서 — 를 만들어냅니다. 그 모델에 엄청나게 다른 컨텍스트를 먹이고, 실수로부터 엄청나게 다르게 회복하기 때문입니다.

2. 토큰이 타는 곳이 왜 하네스인가

여기서부터가 비용에 중요한 부분입니다. 에이전트형 과제에서 토큰 청구서는 문제를 푸는 단 하나의 깔끔한 궤적이 지배하지 않습니다. 그것을 지배하는 것은 가는 길에 잘못되는 모든 것입니다:

• 재시도. 모호한 에러, 잘못된 형식의 도구 호출, 틀린 가정 — 이런 막다른 길 하나하나가 입력(누적된 컨텍스트 전체)과 출력을 온전히 지불하고서도 아무것도 만들어내지 못한 한 바퀴입니다.
• 재읽기. 모델에게 정확한 30줄을 건네주지 못하는 하네스는 모델이 800줄짜리 파일 전체를 읽게 만들거나 — grep하고, 실패하고, 파일 세 개를 더 읽게 만듭니다.
• 허우적거림. 방향 잡음이 없으면, 막힌 모델은 실패하는 같은 행동을 조금씩 다른 말로 반복하고, 반복할 때마다 컨텍스트 전체를 다시 보냅니다.
• 컨텍스트 부패(Context rot). 실패한 시도들이 윈도우에 쌓이면서 품질이 떨어지고(토큰 가이드의 §3 참조), 이것이 더 많은 실패를 유발하고, 그 실패가 더 많은 토큰을 태웁니다. 악순환입니다.

그래서 같은 모델이 하네스를 걸쳤을 때보다 맨몸일 때 4배나 더 비쌀 수 있는 것입니다. 성공률 68%짜리 하네스는 단지 더 똑똑한 것이 아니라 — 허우적거림에 돈을 내지 않습니다. 가장 싼 토큰은 재시도에 결코 쓰지 않는 토큰입니다. 하네스 품질과 토큰 비용은 두 번 측정된 같은 축입니다.

3. 연구: 모델이 아니라 인터페이스를 적응시켜라

이것은 단순한 인플루언서의 프레이밍이 아닙니다 — 이제 숫자를 갖춘 연구 방향입니다.

Life-Harness

Life-Harness (Xu, Wen, Li — arXiv 2605.22166)는 그 제목에서 명제를 문자 그대로 만듭니다: “모델이 아니라 인터페이스를 적응시켜라(Adapting the Interface, Not the Model).” 주장은, 규칙이 지배하는 환경에서 에이전트가 실패하는 것은 모델이 멍청해서가 아니라 모델-환경 인터페이스 불일치 때문이라는 것입니다. 그래서 가중치를 파인튜닝하는 대신 런타임에 하네스를 진화시킵니다: 관찰된 실패를 재사용 가능한 개입으로 바꾸고, 그 개입들을 새로운 과제를 위해 고정해 둡니다. 이것은 학습이 필요 없습니다(training-free) — 그래디언트 업데이트도, 새 가중치도 없습니다.

이것은 네 개의 런타임 레이어로 이루어져 있으며, 각각을 토큰 절약 장치로 보는 것이 가치 있습니다:

레이어	하는 일	토큰 관점
Environment contracts	과제의 실제 제약을 미리 명시한다	모델이 규칙을 위반하면서 알아내는 재시도 루프를 없앤다
Procedural skills	이전에 통했던, 정제된 회복 패턴을 재사용한다	에이전트가 한 번 찾아낸 해법을 다시 도출하는 것을 건너뛴다
Action realization	모델의 의도를 유효한 실행 가능 행동으로 번역한다	잘못된 형식의 호출로 인한 왕복을 제거한다
Trajectory regulation	반복되는 실패 패턴을 감지하고 차단한다	컨텍스트를 N번 다시 보내는 허우적거림 루프를 멈춘다

이 네 가지 하나하나가 낭비된 토큰의 한 범주를 겨냥합니다. 결과는 이렇습니다: 7개의 결정론적 환경과 18개의 모델 백본에 걸쳐 Life-Harness는 126개 설정 중 116개를 개선했고, 평균 88.5%의 상대적 향상을 보였습니다 — 그리고 한 모델에서 진화한 하네스가 다른 17개 모델로 전이되었습니다. MIT 라이선스 코드는 GitHub에 있습니다. (논문은 토큰 헤드라인이 아니라 성공률을 보고합니다. “토큰 4배 절약” 수치는 위의 실무자 실험에서 나온 것입니다 — 하지만 그 메커니즘은 정확히 좋은 하네스가 하는 일입니다: 실패한 궤적이 더 적고, 토큰이 더 적습니다.)

Meta-Harness

Life-Harness가 실패로부터 하네스를 진화시킨다면, Meta-Harness (Lee, Nair, Zhang, Lee, Khattab, Finn)는 끝에서 끝까지 나아갑니다: 모델을 건드리지 않고 하네스 자체를 자동으로 최적화 — 과제 설명, 프롬프트, 평가 기준을 학습 가능한 대상으로 다룹니다. 그 헤드라인은 “하네스 문제”입니다: 동일한 과제라도 다르게 틀지어지면 실질적으로 다른 결과를 낸다, 그리고 체계적인 하네스 최적화는 모델 업그레이드로 얻는 이득에 필적하거나 그것을 능가할 수 있습니다. T-Bench 2에서 의도 감지, 감정 인식, 코드 과제에 걸쳐 테스트되었습니다.

두 논문, 같은 분기, 서로 다른 각도에서 나온 같은 결론: 인터페이스는 일급(first-class) 레버이며, 고정된 모델에게는 그것이 유일하게 남은 레버입니다.

4. 이것이 당신의 Claude Code 청구서에 의미하는 것

Claude Code 사용자를 위한 핵심은 이렇습니다: 토큰 절약 가이드에 있는 모든 것이 하네스 엔지니어링입니다. “하네스”라고 적힌 손잡이는 없지만, 당신은 다음을 할 때마다 하네스를 만들고 있습니다:

• 작은 컨텍스트로 서브에이전트에게 위임하기(§2) — 실패가 자식 컨텍스트에 머물러 부모를 부패시키지 않도록;
• MCP를 스킬로 교체하기(§5) — procedural-skills 레이어를 다른 이름으로 부른 것: 다시 도출하는 대신 필요할 때 로드되는 재사용 가능한 노하우;
• 훅으로 도구 출력을 필터링하고 rtk로 명령어를 압축하기(§11, §13) — action realization: 500줄짜리 로그 대신 유효하고 간결한 결과;
• 저장소 전체를 읽는 대신 그래프를 질의하기 — graphify, 그리고 이제 CodeGraph와 Serena(가이드의 개정된 §7/§13 참조) — “모든 것을 다시 읽는” 세금에 대한 단연 가장 큰 절감;
• /rewind, /compact, /clear로 세션을 관리하기(§4) — trajectory regulation: 막다른 경로가 계속 다시 청구되게 두지 않기.

그 목록을 네 개의 Life-Harness 레이어에 대조해 보면 그 매핑은 거의 일대일입니다. 학술적 프레이밍은 단지 비용을 의식하는 에이전트 사용자들이 이미 본능적으로 하고 있던 것에 이름을 붙여줄 뿐입니다. 그 스택은 잔재주 더미가 아닙니다 — 그것은 하네스이며, 각 조각은 낭비된 토큰의 한 범주를 제거합니다.

5. 더 나은 하네스를 얻는 두 가지 방법: 만들거나 빌리거나

만들기. 이것이 claude-code-token-savers 셋업이 하는 일입니다 — rtk, graphify, caveman, 그리고 이제 pxpipe/headroom을 Claude Code에 배선하여 플래그십 모델을 둘러싼 하네스가 허우적거림에 돈을 내지 않게 만듭니다. Anthropic의 모델은 그대로 두고, 배선을 업그레이드합니다.

빌리기. 어떤 제품은 하네스 자체를 제품으로 판매합니다. 예를 들어 commandcode.ai는 Claude Code 프록시가 아닙니다 — 자체 하네스 뒤에서 저렴한 풀 웨이트, 절대 양자화되지 않은 오픈 모델(DeepSeek V4 Pro, MiniMax M3, MiMo V2.5 Pro)을 구동하는 독립형 에이전트($1/월, $10 무료 크레딧)입니다. 여기에는 당신의 수락/거부/편집을 지켜보고 프로젝트 수준의 스킬을 자동으로 작성하는 “taste-1” 학습 시스템 — procedural-skills 레이어를 제품화한 것 — 이 딸려 있습니다. 그 경제학은 §6의 수(저렴한 모델)에 더해, 쓰면 쓸수록 좋아지는 하네스입니다. 하나의 범주로 알아둘 가치가 있습니다: 하네스가 충분히 좋으면, 그 위의 범용 모델이 맨몸의 플래그십 모델을 이깁니다 — 그것이 바로 6.7% 대 68% 차트 전체를, 구독으로 판 것입니다. (이것은 당신의 Claude Code 스택에 대한 애드온이 아니라 대안 에이전트입니다.)

두 경로 모두 같은 베팅입니다: 모델이 아니라 하네스에 쓰라.

정리

모델은 엔진이고, 엔진은 범용재가 되었습니다 — DeepSeek, MiniMax, Qwen, Claude, 모두 $1 구독이나 저렴한 OpenRouter 별칭으로 손닿는 거리에 있습니다. 같은 과제에서 $6짜리 세션과 $42짜리 세션을 가르는 것은 엔진이 아닙니다. 그것은 하네스입니다: 배선이 얼마나 잘 모델을 궤도 위에 유지하고, 정확히 필요한 컨텍스트를 건네주고, 같은 실수에 두 번 돈 내기를 거부하는가.

Aakash Gupta는 하네스를 해자라고 불렀습니다. 토큰 청구서를 지켜보는 사람에게는 그보다 더 단순합니다: 하네스는 당신의 토큰이 쓰이거나 절약되는 바로 그곳입니다. 좋은 것을 만들거나 — 아니면 빌리세요 — 그러면 같은 모델이 4분의 1의 비용으로 10배의 일을 해냅니다.

---

함께 읽기: LLM에서 토큰을 절약하는 방법 — 실전 Claude Code 가이드, 이 원리가 그 아래에 자리한 전술별 목록.