코딩 에이전트(Coding agents)는 명백한 방식으로 토큰을 낭비합니다. 이미 스스로를 설명하고 있는 코드에 대해 설명을 덧붙이거나, 단 한 번만 호출될 헬퍼(helper) 함수를 생성합니다. 표준 라이브러리를 확인하기도 전에 의존성(dependency)을 추가하기도 합니다.

이러한 낭비에 대한 첫 번째 대응은 간단했습니다. 에이전트에게 더 짧게 말하라고 지시하는 것이었습니다.

Caveman은 그 아이디어를 산문(prose)에 적용했습니다. Ponytail은 이를 코드에 적용했습니다. 두 모델 모두 개발자들이 느끼는 실제 좌절감을 식별해냈으며, 문제가 인식하기 쉽기 때문에 둘 다 인기를 얻었습니다.

하지만 짧은 출력이 단 하나의 문제인 것은 아닙니다.

유틸리티 함수(utility function), 랜딩 페이지(landing page), 그리고 에이전트 간의 메시지는 실패하는 방식이 서로 다릅니다. 한 가지 상황에서 작동하는 규칙이 다른 상황에서는 해를 끼칠 수 있습니다.

이것이 바로 GreenPT가 오픈 소스 제품인 Honey를 구축한 이유이며, 몇 가지 매력적인 전후(before-and-after) 사례에 의존하는 대신 이를 벤치마킹하기로 결정한 이유입니다.

세 가지 다른 종류의 낭비

Honey는 세 가지 별도의 레버(levers)를 사용합니다.

1. 더 적은 코드

코드를 추가하기 전에, 에이전트는 필요성이 존재하는지, 코드베이스(codebase)가 이미 이를 해결하고 있는지, 표준 라이브러리나 플랫폼이 이를 지원하는지, 그리고 설치된 의존성(dependency)이 해당 작업을 수행할 수 있는지를 확인합니다.

이는 일반적인 엔지니어링 규율(engineering discipline)입니다. 중요한 부분은 중단 규칙(stopping rule)입니다. 단순한 솔루션이 작업을 충족하면 에이전트는 멈춥니다.

이것이 입력 검증(input validation), 에러 처리(error handling), 인증(authentication), 접근성(accessibility) 또는 사용자가 요청한 그 어떤 것도 제거한다는 의미는 아닙니다. 요구 사항을 조용히 누락시키는 짧은 구현은 효율적인 것이 아니라 미완성된 것입니다.

2. 더 적은 산문(prose)

많은 에이전트의 답변에는 서론(wind-up), 프롬프트(prompt)의 요약, 읽기 쉬운 코드에 대한 서술, 그리고 마지막의 두 번째 요약이 포함되어 있습니다.

Honey는 사용자가 구현(implementation)을 원할 때 이러한 내용을 제거합니다. 설계 결정(design decision), 트레이드오프(trade-off), 또는 학습 질문과 같이 설명 자체가 결과물인 경우에는 설명을 유지합니다.

3. 더 밀도 높은 에이전트 핸드오프(agent handoffs)

에이전트 간의 통신(Agent-to-agent communication)은 인간의 통신과는 다른 요구 사항을 가집니다.

인간은 읽기 쉬운 산문을 원합니다. 반면 다른 에이전트는 종종 구조화된 기록 (structured records)을 필요로 합니다. 예쁘게 출력된 JSON (Pretty-printed JSON)은 모든 행마다 동일한 키를 반복하며, 이는 정보의 추가 없이 토큰 (tokens) 비용만 발생시킵니다.

Honey는 기본적으로 압축된 JSON (compact JSON)을 사용하며, 반복되는 레코드 배열에는 ESON을 사용할 수 있습니다. 키는 한 번만 선언되고, 레코드는 안정적인 식별자 (stable identifiers)를 통해 주소 지정이 가능하며, 행 수 (row counts)를 통해 간단한 절단 확인 (truncation check)을 제공합니다.

목표는 어떤 대가를 치르더라도 압축하는 것이 아닙니다. 다음 에이전트가 여전히 필요한 모든 사실을 복구할 수 있어야 합니다.

측정 방법

벤치마크는 세 그룹으로 나뉜 23개의 태스크 (tasks)를 포함합니다:

• 실행 가능한 체크 (executable checks)가 포함된 14개의 코딩 태스크 (coding tasks)
• 구조 및 접근성 체크 (structural and accessibility checks)가 포함된 7개의 사용자 대상 태스크 (user-facing tasks)
• 적대적 복구 질문 (adversarial recovery questions)이 포함된 2개의 에이전트 핸드오프 (agent-handoff) 태스크

각 태스크는 네 가지 변형 (variants)에 대해 실행됩니다:

• Plain baseline
• Caveman
• Ponytail
• Honey

프롬프트 (prompt)와 모델 (model)은 동일하게 유지됩니다. 오직 기술 (skill)만 변경됩니다.

실행 결과는 중앙값 (median)으로 병합되며, 그런 다음 각 태스크는 자체 베이스라인 (baseline)과 쌍을 이룹니다. 우리는 이러한 쌍을 이룬 변화의 중앙값을 보고합니다. 이는 전체 토큰의 비율이 유난히 긴 하나의 태스크에 의해 지배될 수 있기 때문에 중요합니다.

정확성 (Correctness)은 가능한 경우 객관적인 테스트 (objective tests)를 사용합니다. 교차 모델 판사 패널 (cross-model judge panel)은 테스트로 환원하기 어려운 품질들을 평가합니다. 채점 기준 (rubric)은 짧은 답변에 보상을 주지 않습니다.

방법론, 태스크 정의, 원시 결과 (raw results), 그리고 보고 코드 (reporting code)는 모두 리포지토리 (repository)에 있습니다.

현재 결과

Claude Opus 4.8에서 Honey는 전체 스위트 (suite)에 대해 중앙값 기준 29% 적은 출력을 생성했으며, p=0.020을 기록했습니다.

Honey는 객관적 테스트 (objective tests)를 100% 통과했습니다.

전반적인 판정 품질 (judged quality)은 베이스라인과 측정 가능한 차이가 없었으며, p=0.648을 기록했습니다.

출력 감소 효과는 GPT-5.5에서도 재현되었으며, 여기서 Honey는 p=0.004와 함께 20% 적은 출력을 생성했습니다.

집중된 Honey 기술에 대한 별도의 실시간 벤치마크(live benchmark) 결과, 좁은 범위의 워크플로우(workflows)에서 더 큰 감소가 발견되었습니다. Honey의 리뷰 기술은 정답률을 유지하면서도 출력량을 70% 더 적게 사용했습니다. 이것이 우리가 하나의 숫자가 모든 사용 사례에 적합한 것처럼 꾸미는 대신, 혼합된 작업 전반에 걸쳐 29%, 집중된 리뷰 워크플로우에서는 최대 70%라는 결과로 제시하는 이유입니다.

결과는 작업 유형에 따라 달라지며, 이것이 핵심입니다.

코드 (Code)

Honey는 100%의 유닛 테스트(unit-test) 통과율을 유지하면서 코드 작업에서 가장 강력하게 출력량을 줄였습니다.

이 지점에서 '첫 번째로 작동하는 단계에서 멈추기(stop-at-the-first-working-rung)' 규칙이 효과를 발휘합니다. 에이전트는 추측성 헬퍼(speculative helpers), 옵션, 그리고 추상화(abstractions)를 피하면서도 테스트가 요구하는 동작은 그대로 유지합니다.

사용자 대상 작업 (User-facing work)

UI 작업에서 Honey는 통계적으로 의미 있는 출력 감소를 생성하지 않았습니다. 이는 유용한 결과입니다.

시각적 다듬기(Visual polish), 반응형 동작(responsive behavior), 그리고 접근성(accessibility)은 코드를 필요로 합니다. 기술(skill)은 단순히 토큰 차트를 개선하기 위해 이러한 요소들을 제거해서는 안 됩니다. Honey의 정교한 절제(carve-out)는 이 계층에서 유일한 100% 접근성 통과율을 유지했습니다.

에이전트 핸드오프 (Agent handoffs)

Honey의 가장 강력한 결과는 구조화된 핸드오프(handoffs)에서 나타났습니다. Honey는 출력량을 약 절반으로 사용하면서도 100%의 복구율(recovery)을 유지했습니다.

Caveman과 Ponytail은 더 짧은 핸드오프를 생성했지만, 적대적 질문(adversarial questions) 상황에서 정보를 손실했습니다. 압축된 형식은 수신자가 데이터를 재구성할 수 있을 때에만 도움이 됩니다.

이 계층에는 두 개의 작업이 포함되어 있으므로, p-value를 주장하지는 않습니다. 이는 유망하며 더 큰 작업 세트가 필요합니다.

우리가 주장할 수 없는 것들

우리는 Honey가 숨겨진 추론 토큰(hidden reasoning tokens)을 줄인다고 주장할 수 없습니다.

우리는 아직 입증된 비용 절감(dollar savings)을 주장할 수 없습니다. 모델 가격 책정, 프롬프트 캐싱(prompt caching), 하네스 동작(harness behavior), 그리고 작업 혼합(task mix) 모두가 청구 금액에 영향을 미칩니다. 이 샘플에서 비용 결과는 통계적으로 유의미하지 않았습니다.

또한 우리는 23개의 작업이 모든 코딩 워크플로우를 대표한다고 주장할 수 없습니다. 벤치마크는 증거이지, 보편적인 법칙이 아닙니다.

마지막으로, 심사 패널(judge panels)에는 편향(biases)이 존재합니다. 객관적인 테스트가 더 강력하며, 이것이 벤치마크에서 정답 체크를 스타일 판단과 분리하여 유지하는 이유입니다.

우리는 자체 수치를 수정했습니다

이전 버전의 프로젝트에서는 팔(arm) 총계의 비율을 기반으로 혼합된 수치를 보고했습니다. 해당 방식은 긴 작업(long tasks)이 결과에 지배적인 영향을 미치게 만들었습니다.

우리는 이를 작업별 중앙값(per-task medians) 쌍으로 교체하고 수정 사항을 발표했습니다. 그 결과 헤드라인 출력 감소율은 29%로 이동했습니다. 일부 경쟁사 결과 또한 변경되었으며, 이전의 두 가지 이상치(outlier) 주장도 철회되었습니다.

이는 당황스러운 각주가 아닙니다. 이것이 바로 벤치마크가 가능하게 해야 하는 일입니다. 방법론이 개선된다면, 주장 또한 바뀌어야 합니다.

직접 시도하거나 도전해 보세요

Honey는 MIT 라이선스를 가진 오픈 소스 GreenPT 제품입니다. 이는 Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenClaw, Kiro 및 스킬(skills)이나 프로젝트 지침(project instructions)을 지원하는 기타 에이전트(agents)와 함께 작동합니다.

저장소(repository)에는 설치 경로, 벤치마크 방법, 원시 결과(raw results), 그리고 보고서를 재현하는 데 필요한 명령어가 포함되어 있습니다:

https://github.com/Green-PT/honey-for-devs

가장 유용한 기여는 '스타(star)'를 누르는 것이 아닙니다. 다른 모델이나 하네스(harness)에서 벤치마크를 실행해 보세요. 간결함이 위험해질 수 있는 작업을 추가해 보세요. Honey가 제거해 버리는 요구사항을 찾아보세요. 그런 다음 증거와 함께 이슈(issue)를 제기해 주세요.

짧은 것이 유용한 경우는 오직 중요한 부분이 살아남았을 때뿐입니다.