모델 안 바꾸고 토큰 41% 줄였다? Writer 하네스 효과 논문 상세 해설 (2026)

AI 에이전트를 쓰다 보면 이상한 일이 생긴다. 더 똑똑하다는 모델로 갈아탔는데 청구서가 안 줄어든다. 오히려 늘기도 한다. 왜일까?

AI 기업 Writer의 연구가 답을 준다. 문제는 모델이 아니라 모델을 감싸서 돌리는 방식이라는 것이다. 이 "감싸는 껍데기"를 하네스(harness)라고 부른다. 논문 제목이 그대로 결론이다. The Harness Effect — 하네스만 잘 바꿔도 토큰은 38%, 비용은 41% 줄었다.

원문: The Harness Effect (arXiv:2607.06906), AI타임스 보도 기준.

 

하네스가 뭔데?

비유하면 이렇다. 요리사(모델)가 아무리 실력이 좋아도, 주방 동선이 엉망이면 요리가 느리고 재료가 낭비된다. 하네스는 그 주방 동선이다. 모델에게 무엇을 언제 넣어주고, 어떤 도구를 쥐어주고, 어디서 멈추게 할지를 정하는 바깥 코드다.

우리가 흔히 신경 쓰는 건 "어느 요리사가 더 잘하나"(모델 비교)다. 그런데 Writer는 요리사를 그대로 두고 주방 동선만 바꿨더니 비용이 확 줄었다는 걸 보여준다.

 

돈이 새는 진짜 원인: 토큰맥싱

에이전트가 비싼 이유는 한 번 묻고 끝이 아니기 때문이다. 계획하고, 실행하고, 검증하고, 고치기를 반복한다. 이때 흔한 낭비 패턴이 토큰맥싱이다.

• 매 턴마다 지금까지의 대화 전체를 다시 집어넣는다
• 같은 시스템 지시문을 요청마다 통째로 재전송한다
• 필요 없는 도구를 자꾸 호출한다

작업이 길어질수록 이 누적이 눈덩이처럼 커진다. "더 싼 모델로 갈아타자"로는 못 막는다. 동선이 새고 있으면 요리사를 바꿔도 재료는 계속 버려진다.

 

실험: 요리사는 그대로, 동선만 교체

연구진은 기업용 AI 업무 22개를 고정하고, 모델 6종(Claude Sonnet 4.6, Gemini 3.1, Gemini Flash 3.5, Qwen 3.6, GLM-5.1, Palmira X6)에서 "기존 루프" vs "최적화 하네스"만 바꿔 비교했다.

지표	기존	하네스 최적화	변화
작업당 토큰	14,200	8,800	-38%
작업당 비용	$0.21	$0.12	-41%
처리 시간(중앙값)	48초	27초	-44%
성공률	78%	81%	+3%p

출처: Writer 논문 / AI타임스 보도 수치

중요한 건 성공률이 안 떨어졌다는 점이다. 싸게 만들려고 품질을 깎은 게 아니라, 낭비만 걷어냈는데 비용·시간이 줄고 성공률은 오히려 소폭 올랐다. 작업 1,000건이면 $210 → $120, 즉 $90 절감이다.

 

핵심 기법 3가지 (쉽게)

1. 투 존 프롬프트 — 안 바뀌는 건 위에 고정
시스템 규칙·도구 정의처럼 매번 똑같은 부분은 프롬프트 맨 위에 고정한다. 그러면 그 부분은 "프롬프트 캐시"로 처리돼 입력 비용이 정가의 10% 수준까지 떨어질 수 있다. 반대로 매 턴 바뀌는 유저 요청·현재 상태는 아래에 따로 둔다. 한 줄 요약: 시스템 프롬프트를 매번 통째로 다시 붙이지 마라.

2. 컨텍스트 오프로딩 — 다 넣지 말고 필요할 때 꺼내라
대화·검색 결과를 프롬프트에 계속 쌓지 말고, 외부 저장소에 두었다가 필요한 것만 다시 불러온다. 검색 같은 무거운 일은 서브 에이전트가 하고, 메인에는 결론만 넘긴다. "일단 다 넣고 알아서 하겠지"가 낭비의 전형이다.

3. 하드 예산 — 모델을 믿지 말고 코드로 막아라
작업당 토큰 상한, 반복 횟수 제한, 실패 후 재시도 제한을 코드 레벨에서 강제한다. 에이전트는 막히면 같은 도구를 또 부르고 같은 파일을 또 읽는다. 가드레일이 없으면 비용이 먼저 터진다.

 

내일 당장 할 수 있는 체크

1. 시스템 프롬프트가 매 요청마다 통째로 다시 들어가는지 확인 → 고정 구간으로 분리
2. 긴 대화 전체를 재주입하는지 확인 → 상태 요약 + 필요한 조각만
3. 검색/파일 훑기를 메인에 쌓는지 확인 → 서브로 빼고 결론만 회수
4. 작업당 max tokens / max tool calls / max retries가 코드에 있는지 확인
5. 모델 업그레이드 회의 전에 "컨텍스트가 왜 매 턴 다시 들어가나"부터 보기

Cursor, Claude Code, 자체 에이전트 어디든 적용된다. 이건 그록 한도가 빨리 닳는 개인 사용자에게도 똑같이 유효하다.

 

한계도 솔직히

• 복잡한 멀티 에이전트가 모든 모델에 맞진 않았다. 경량 모델(Gemini Flash 3.5, Qwen 3.6)은 서브 협업 신뢰성이 부족했다.
• 무조건 41% 절감이 보장되진 않는다. 자기 워크로드로 A/B를 돌려봐야 한다.
• 모델 품질이 안 중요하다는 뜻이 아니다. "덜 낭비하는 구조가 먼저"라는 뜻이다.

 

남는 한 줄

에이전트 비용이 문제라면 질문 순서를 바꿔라. "어떤 모델로 업그레이드하지?"가 아니라 "고정 프롬프트는 캐시되나, 컨텍스트는 왜 매 턴 다시 들어가나, 실패 재시도에 상한이 있나?"가 먼저다. 청구서를 가르는 건 모델 카드가 아니라 하네스다.

 

참고: AI타임스 · arXiv:2607.06906 · 관련: Cursor 스웜 비용