Claude Code용 Ponytail Skill: 정말 토큰을 줄일까

결과 요약

• Ponytail은 효과가 있지만 모든 과제에서 홍보상의 코드 −54%를 기대할 수는 없음

  • 80개 페어 과제에서 일반적인 비용을 10.3%, 작성 코드량을 약 15% 줄였으며, 검출 가능한 품질 차이는 없었음

  • 이미 간결한 과제에서는 거의 변화가 없었고 대규모 구현 과제에서는 코드량이 약 31% 줄었음. 즉, 에이전트가 과도하게 구현할수록 절감할 수 있는 여지가 커짐

  • 플러그인과 SessionStart 훅을 통해 규칙 모음을 실제로 주입해야 측정 가능한 효과가 나타남.

    • 설치 후 지속적으로 적용하면 이 과제 묶음에서는 비교적 완만한 비용 절감 효과를 기대할 수 있음

어떻게 코드를 줄이며, 무엇과 비교했나

• Ponytail은 문제를 이해한 뒤 꼭 필요한 최소 코드만 작성하도록 판단 순서를 강제함

  • 새 코드가 필요한지, 코드베이스에 이미 있는지, 표준 라이브러리·플랫폼 기본 기능·설치된 의존성으로 해결할 수 있는지, 한 줄로 줄일 수 있는지를 차례로 확인함

  • 검증, 오류 처리, 보안, 접근성은 축소 대상에서 명시적으로 제외됨

  • 예를 들어 날짜 선택기를 요청받으면 flatpickr와 래퍼 컴포넌트 대신 <input type="date">를 택하는 방식임

• three.js 장면을 Blender용 OBJ 파일로 내보내는 과제에서는 같은 결과를 절반의 문장으로 구현했음

  • 두 에이전트 모두 OBJExporter가 인스턴스 메시를 처리하지 못해 같은 확장 루프를 작성했고, 검증기가 승인한 동일한 지오메트리를 내보내 1.0점을 받음

  • 기본 에이전트는 회전용 부모 객체와 중간 변수를 만들어 10개 문장을 썼지만, ponytail은 기존 객체를 직접 회전하고 불필요한 import를 생략해 5개 문장으로 끝냄

// no skill — 10 statements to rotate the scene and write the file
const exportRoot = new THREE.Group();
exportRoot.name = 'blender_export_root';
exportRoot.rotation.x = -Math.PI / 2;
exportRoot.add(root);
exportRoot.updateMatrixWorld(true);

const exporter = new OBJExporter();
const objString = exporter.parse(exportRoot);

const outputPath = '/root/output/object.obj';
fs.mkdirSync(path.dirname(outputPath), { recursive: true });
fs.writeFileSync(outputPath, objString);

// ponytail — the same job, 5 statements
root.rotation.x = -Math.PI / 2;
root.updateMatrixWorld(true);

const obj = new OBJExporter().parse(root);
fs.mkdirSync('/root/output', { recursive: true });
fs.writeFileSync('/root/output/object.obj', obj);

• 이번 실험에서는 공개된 토큰 절약 도구를 같은 페어 A/B 벤치마크로 세 번째 검증함

  • caveman skill은 코드 −65%를 내세웠지만 −8.5%로 측정됐고, rtk는 비용 −60~90%를 주장했으나 실제 비용은 7.6% 늘어남

  • Ponytail의 원래 벤치마크는 실제 FastAPI + React 저장소를 화면 없이 실행한 Claude Code가 편집하고 남긴 git diff로 평가했으며, 12개 기능 개발 요청의 평균 코드 감소율이 −54%였음

  • 초기 결과가 말이 많은 기본 조건에서 나왔다는 issue #126의 비판을 반영해 벤치마크를 다시 만들었고, SessionStart 훅이 기본 조건에도 ponytail을 주입하던 오염 버그까지 공개함

어떤 환경에서 검증했나

• Harbor 0.18의 Docker 격리 환경에서 SkillsBench 80개 과제를 페어 실행하고, 부분 점수를 허용하는 0~1 검증기로 자동 평가했음

  • 두 실험군 모두 화면 없이 실행하는 Claude Code 2.1.201과 bypassPermissions를 고정하고, claude-sonnet-5를 medium 추론 강도로 사용함

  • 기본 조건은 stock Claude Code, 실험군은 ponytail v4.8.4를 설치하고 자체 hooks/ponytail-instructions.js가 생성한 규칙 모음을 바이트 단위로 동일하게 주입한 구성임

    • 실제 플러그인의 전체 모드와 가깝지만 첫 실행 상태 표시줄 안내, 하위 에이전트 재주입은 재현하지 않았고, 규칙 모음은 과제 앞이 아니라 뒤에 붙였음

• 10개 과제 예비 실행, 같은 10개 과제의 k=3 실행, 전체 80개 실행과 자동 활성화·연결 상태 점검까지 총 251회의 유료 에이전트 실행에 USD 246.09가 들었음

  • SkillsBench 87개 중 로컬 격리 환경에서 실행할 수 없는 1개와 해당 하드웨어에서 양쪽 모두 똑같이 실패한 6개를 대칭적으로 제외함

  • 모든 실행 뒤 규칙 모음 전달 여부를 감사한 결과 실험군은 100%, 기본 조건은 0%로 확인돼 오염 없이 비교됨

설치만 해도 자동으로 작동하나

• SKILL.md를 skills 폴더에 복사하고 Claude Code의 선택에 맡기면 효과가 나타나지 않을 가능성이 큼

  • 모든 코딩 과제에서 사용하라는 설명이 있어도 10개 세션에서 자동 활성화는 한 번도 일어나지 않았음

  • 이는 ponytail 자체의 버그가 아니라, 규칙 모음을 강제로 주입하는 SessionStart 훅을 포함한 플러그인 형태로 배포하는 이유임

  • 아래의 모든 측정치는 규칙 모음이 실제로 주입된 실행에서 나온 결과이며, 설치 방식이 효과의 전제 조건임

코드·토큰·비용은 실제로 얼마나 줄었나

• 80개 페어 과제에서 일반적인 과제의 작성 코드는 15.4% 줄어 10,205줄이 8,756줄이 됐지만, 광고한 −54%에는 크게 못 미쳤음

  • 코드 감소의 p-value는 0.088로 주요 결과 중 가장 약하며, 통계적으로 확실하다고 보기 어려움

  • 원래 수치는 과도한 구현이 발생하기 쉬운 12개 기능 개발 요청의 평균이고, 이번 수치는 특정 효과에 맞춰 고르지 않은 80개 과제의 중앙값임

    • 원래 실험에서도 과도한 구현이 생기면 최대 94%까지 줄지만 이미 최소인 코드에서는 거의 줄지 않는다고 명시함

• Ponytail의 규칙은 파일을 건드리는 횟수보다 한 번에 작성하는 코드량을 줄이는 쪽으로 작동했음

  • 전체 80개의 중앙값과 같은 −15.4% 감소를 보인 대표 과제에서 기본 에이전트는 15번 편집해 943줄, ponytail은 더 많은 18번을 편집하고도 798줄로 끝나 145줄 적었음

• 코드가 많아질수록 감소 폭도 커졌지만, 이 관계를 확정된 법칙으로 볼 수는 없음

  • 기본 에이전트가 작성한 코드량으로 나누면 거의 코드가 필요 없는 26개 과제는 중앙값 0.0%, 20~99줄의 21개는 −11.9%, 100~299줄의 24개는 −20.9%, 300줄 이상인 9개는 −31.2%였음

  • 구간은 데이터를 본 뒤 정했고 기본 조건의 출력량으로 분류했으므로 기울기가 과장될 수 있으며, 300줄 이상 표본도 9개뿐임

• 거의 코드가 필요 없던 과제에서는 저장 위치 차이가 줄 수치를 일부 왜곡했지만, 순효과는 전체 코드의 2% 미만이었음

  • 기본 에이전트가 heredoc으로 Python 인터프리터에 바로 흘려보내 0줄로 기록된 7개 과제에서 ponytail은 edit.py, diff.py, build_model.py 같은 일반 작업 스크립트를 파일로 저장해 각각 51~230줄로 집계됐고, 이 구간 총량은 104줄에서 910줄로 늘어남

  • Ponytail만 코드를 남긴 7개 과제는 761줄, 기본 에이전트만 남긴 4개는 567줄이어서 순차이는 약 190줄이며, 이를 근거로 −15.4%가 보수적이라고 주장할 수는 없음

• Ponytail이 정의한 전체 입력·캐시·출력 토큰은 7.5% 줄었지만 p=0.12로 무작위 변동 범위에 머물렀음

  • 광고 수치 −22%와 비교해야 하는 항목은 이 전체 토큰이며, 모델이 작성한 출력만 보면 13.8% 감소해 p=0.001로 견고한 결과가 나옴

  • 새 입력 토큰은 −3.9%(p=0.085), 이전 대화 기록 재독은 −8.4%(p=0.138), 대화 단계는 −6.4%(p=0.057)로 줄어드는 경향만 보였음

• 일반적인 과제의 비용은 10.3% 줄어 이 시리즈에서 처음으로 통계적으로 확실한 비용 절감이 확인됐음

  • 80개 중 46개가 저렴하고 34개가 비쌌으며, 페어 검정 결과 p=0.004였음

  • 중앙값의 부트스트랩 구간은 0에 살짝 닿을 만큼 분산이 넓으므로, 이 과제 묶음에서 약 10% 저렴했다고 말할 수는 있어도 항상 10% 절약된다고 일반화할 수는 없음

  • 비용 감소는 입력보다 출력 감소에서 나타났으며, 완료 시간은 −10.6%(p=0.040)였지만 7개 평가 지표에 단순 다중 비교 보정을 적용하면 유의하지 않음

코드를 줄여도 품질은 유지됐나

• 80개 과제에서 검출 가능한 품질 차이는 없었지만, 품질이 동일하다고 입증한 결과는 아님

  • Ponytail이 더 나은 과제는 6개(7.5%), 동일한 점수는 65개(81.3%), 더 나쁜 과제는 9개(11.3%)로 부호 검정 p=0.61이었음
    

    

  • 평균 점수는 기본 조건 0.378, ponytail 0.334였으나 이 표본 크기에서는 무작위 변동 범위 안에 있음

  • 약 80개 페어로는 큰 영향만 배제할 수 있고, 합격률 몇 %포인트의 변화를 검출하거나 비열등성을 증명하려면 미리 허용 한계를 정한 뒤 실험군마다 수백 개의 페어 과제가 필요함

• 이번 검증은 과제 완료 여부를 측정했을 뿐, 검증·오류 처리·보안·접근성 보존 주장은 시험하지 못했음

  • SkillsBench 검증기는 보안·검증·접근성 시험 모음이 아니므로, 보호 장치가 유지됐는지는 이 결과로 판단 불가

  • 다만 코드를 줄이느라 테스트 통과가 눈에 띄게 무너지는 실패 양상은 관찰되지 않았음

  • 의도적인 지름길에는 한계와 업그레이드 경로를 적은 ponytail: 주석을 남기라는 규칙이 있었지만 80회 중 한 번만 지켜져, 판단 순서는 따르되 기록 규칙은 거의 따르지 않았음

표본과 측정 방식에서 무엇을 주의해야 하나

• 10개 과제를 한 번씩 실행한 예비 결과는 실제 방향과 정반대였으므로 k=1 결과를 믿어서는 안 됨

  • 첫 실행에서는 코드가 3%만 줄고 비용은 9.6% 늘며 평균 점수도 0.51에서 0.31로 떨어졌음

  • 같은 10개를 세 번씩 실행하자 비용은 11.8% 줄었고 품질 하락도 사라졌으며, 전체 80개에서는 비용 −10.3%로 통계적으로 확실해짐

• 유료 실행 전에 평가 지표와 페어 분석 방식을 고정해 긴 세션 하나가 평균을 왜곡하지 않도록 했음

  • 점수, 작성 코드, 출력 토큰, 새 입력 토큰, 비용, 대화 횟수, 경과 시간을 미리 정하고, 한쪽이라도 오류가 난 과제는 양쪽에서 모두 제외함

  • 품질에는 부호 검정, 나머지에는 과제별 중앙값과 Wilcoxon 검정을 사용했으며, 긴 이전 대화 기록 세션 하나가 정상 비용의 25배까지 발생할 수 있어 평균은 쓰지 않았음

  • 전체 토큰은 ponytail의 benchmarks/agentic/run.py가 입력·캐시·출력을 합산한다는 점을 확인한 뒤 사후 추가했으며, 출력 토큰만 −22%와 비교하면 효과를 약 3배 부풀리게 됨

• 작업 공간의 최종 diff가 없어 도구 호출에서 누적 작성 줄 수를 재구성했으며, 이는 최종 구현 크기와 다른 지표임

  • Write, Edit, 파일로 리디렉션한 shell heredoc에서 ponytail의 benchmarks/loc.js와 같은 방식으로 빈 줄과 주석을 제외해 집계함

  • 작성 후 다시 고친 줄은 매번 세고, 인터프리터로 바로 보낸 heredoc은 일회성 분석으로 제외했으며, 런타임 스크립트가 만든 파일과 하위 에이전트 내부의 코드는 양쪽 모두 포착하지 못함

  • 감사 결과 Write 15,632줄과 Edit 2,496줄이 총 18,961줄의 95.6%를 차지해 결과가 코드 위치 누락만으로 생긴 것은 아님

• 적용 범위는 데이터·분석·수리 작업이 많은 SkillsBench로 제한됨

  • 프런트엔드의 과도한 구현 함정이 적어 비용·속도·품질 주장은 공정하게 시험하지만, 코드 −54% 주장은 보수적으로 검증하는 과제 묶음임

  • 따라서 자체 과제에서 측정한 −54%를 반박하지 않으며, 해당 규모의 절감이 모든 과제에 적용된다는 뜻도 아님

  • ponytail은 MIT 라이선스의 커밋 16f2980(v4.8.4)으로 고정하고, 에이전트 버전과 규칙 모음의 sha256도 기록했음

  • 시각화 스타일은 dither-kit을 참고하되 의존성 없는 인라인 위젯으로 다시 구현함

^{source https://blog.jetbrains.com/ai/2026/07/ponytail-skill-claude-tested/}