Claude Code에서 가장 잘 알려진 token 절약 skill(agent에게 일하는 방식을 가르치는 지침 묶음) 가운데 하나인 Ponytail이 버전 5로 올라섰습니다. GitHub star가 17만 개 가까이 쌓인 이 skill은 Claude의 성능을 유지하면서 코드를 절반 가까이 줄인다고 내세웁니다. Claude Opus 5.5로 공개 수치를 따로 검증한 결과, 아무 skill도 쓰지 않은 기본 Claude보다 코드는 61%, 비용은 24%, 작업 시간은 35% 줄어 주장에 가까운 수치가 나왔고 코드의 안전성도 거의 떨어지지 않았습니다. 다만 요청하지 않은 화면 요소와 편의 기능까지 함께 덜어 내기 때문에, 요구 사항을 꼼꼼히 정해 둔 작업에는 이득이지만 디자인처럼 열린 작업에는 손해가 될 수 있습니다.
코드를 쓰기 전에 일곱 번 묻는 skill
Ponytail은 Claude가 기본적으로 말이 많고 해법을 지나치게 크게 설계하는 경향이 있다는 판단에서 출발합니다. 엄격한 제약 규칙을 주면 꼭 필요한 기능에만 집중해 더 깔끔하고, 싸고, 빠른 결과를 낸다는 것입니다.
핵심 장치는 코드를 쓰기 전에 차례로 따지는 일곱 단계의 질문 사다리입니다. ’이 코드가 꼭 있어야 하나?’에서 시작해 ’한 줄로 될까?’까지 내려가며, 작동하는 가장 낮은 단계에서만 코드를 쓰고 작은 테스트를 함께 붙입니다.
앱 화면에 날짜 선택기(date picker)를 넣는 예에서 차이가 잘 드러납니다.
| 구분 | 접근 방식 | 코드 분량 |
|---|---|---|
| skill 없음 | 외부 라이브러리를 가져오거나 달력을 처음부터 직접 구현 | 335줄 |
| Ponytail 5 | 브라우저에 내장된 날짜 입력과 기존 UI 요소를 활용 | 10줄 |
Ponytail 5가 공식적으로 내세운 수치는 다음과 같습니다.
- 코드 줄 수 53% 감소
- 비용 26% 감소
- 출력 token 45% 감소
- 실행 시간 41% 단축
- 위험한 로직에 테스트가 함께 붙는 비율 98%(skill이 없으면 68%)
버전 5에서 달라진 다섯 가지
- 규칙 분량 절반: 지침 prompt를 1,094단어에서 592단어로 줄였습니다. 세션마다 읽어야 할 분량이 줄어 v4.13보다 실행 비용이 약 10% 낮습니다.
- 고치기 전에 변경 범위 파악: 코드를 쓰기 전에 그 코드를 부르는 곳, 테스트용 고정 데이터(fixture), 설정, 변경이 미칠 영향 범위를 먼저 정리하게 합니다.
- 건너뛴 것 공개: 무엇을 건너뛰었는지, 무엇을 확인하지 않기로 했는지, 어떤 위험이 남았는지 밝히게 합니다. v4에서는 선택 사항이었습니다.
- 검토 범위 확대: 과한 설계만 잡던 검토 기능이 이번 변경분 밖의 버그, 보안 취약점, 빠진 테스트, 성능 문제까지 찾아냅니다.
- 저장소 지도와 실시간 상태 표시줄: 세션을 시작할 때 저장소 구조를 정리한 지도(repo map)를 만들어 이미 있는 함수를 다시 쓰게 하고, 터미널에 세션 비용, token 사용량, agent 작업 시간, 코드 재사용 비율, 테스트 통과 여부를 실시간으로 보여 줍니다.
공개 수치는 맞았을까
검증에 쓴 Claude Code 세션은 모두 약 700개입니다. 이 가운데 공식 수치를 확인하는 시험은 Claude Opus 5.5로 39개 작업을 132개 세션에 걸쳐 돌렸고, 결과는 공식 주장과 크게 다르지 않았습니다.
| 항목 | 공식 주장 | 검증 결과 |
|---|---|---|
| 코드 줄 수 | 53% 감소 | 61% 감소 |
| 비용 | 26% 감소 | 24% 감소 |
| 실행 시간 | 41% 단축 | 35% 단축 |
| v4.13 대비 비용 | 약 11% 감소 | 10.5% 감소 |
공식 대표 수치에서 빠져 있던 6개 작업을 따로 돌려 보니 코드가 76% 줄었습니다. 유리한 작업만 골라 수치를 냈다는 의심은 들어맞지 않은 셈입니다.
일곱 단어 한 줄이면 충분할까
X와 Reddit에서는 Ponytail이 지나치게 복잡하고 YAGNI 원칙을 지키라는 한 줄이면 대신할 수 있다는 반론이 자주 나옵니다. YAGNI(You Aren’t Gonna Need It)는 지금 필요하지 않은 기능은 만들지 말라는 소프트웨어 개발 원칙입니다. 그래서 지침 파일 AGENTS.md에 ‘Follow YAGNI principles, and prefer one-liner solutions.’(YAGNI 원칙을 따르고 한 줄짜리 해법을 우선하라)라는 일곱 단어만 넣은 설정을 Ponytail과 맞붙였습니다.
30개 작업에서 분량과 비용만 보면 일곱 단어 prompt가 이겼습니다. 코드를 72%, 비용을 38% 줄여 Ponytail(코드 60%, 비용 24%)보다 더 많이 덜어 냈습니다.
하지만 계산기, 분석 대시보드, 달력 앱처럼 앱을 만들어 달라는 과제 24개를 어느 설정이 만든 결과인지 가린 채 평가하자(blind audit) 차이가 드러났습니다.
| 평가 항목 | 일곱 단어 prompt | Ponytail |
|---|---|---|
| 데이터를 잃게 만드는 버그 | 2건 | 0건 |
| 테스트를 함께 만든 과제 | 24개 중 14개(58%) | 24개 중 24개(100%) |
| 꼭 필요한 기능 충족 | 89% | 95% |
| 핵심 기능 충족 | 97% | 100% |
| 건너뛴 항목을 밝힌 비율 | 49% | 78% |
Ponytail이 일곱 단어보다 더 쓰는 약 580단어는 단순한 군더더기가 아니라 버그와 데이터 손실을 막는 안전장치 구실을 한다고 볼 수 있습니다. 거꾸로 말하면 ‘짧게 써라’ 식의 아주 짧은 지침만으로 실제 서비스 코드를 맡기면 테스트가 빠지고 데이터를 망가뜨리는 버그가 생길 수 있습니다.
▲ 짧은 지침과 안전장치의 차이
코드가 망가지거나 위험해지지는 않았다
규칙으로 Claude를 묶으면 코드가 덜 안전해지지 않을까 하는 걱정도 따로 시험했습니다. Claude Opus 5.5로 351개 코딩 작업을 돌려 숨겨 둔 검증 테스트를 통과하는지 본 시험에서는 342개가 통과했습니다. 일부러 까다롭게 만든 입력 145가지를 넣은 시험의 통과율은 다음과 같습니다.
| 설정 | 까다로운 입력 통과율 |
|---|---|
| 기본 Claude | 100.0% |
| Ponytail 5 | 99.5% |
| 일곱 단어 prompt | 98.4% |
개인정보 보호를 본 시험도 있습니다. 뉴스레터 구독자 모두에게 이메일을 보내되 받는 사람끼리 주소가 드러나지 않게 하라는 과제로, 숨은 참조(BCC)를 써야 제대로 풀 수 있습니다. 세 번씩 시도한 결과 기본 Claude는 두 번, Ponytail 5는 한 번 실패했고, 이전 버전 Ponytail과 일곱 단어 prompt는 세 번 모두 실패했습니다. 이런 결과로 보면 Ponytail 5가 코드를 기능적으로 망가뜨리거나 안전하지 않게 만든다고 보기는 어렵습니다.
대가는 요청하지 않은 부가 요소
차이는 화면을 만드는 작업에서 나타났습니다. 사양을 A부터 G까지 빠짐없이 적은 PRD(제품 요구 사항 문서)를 주면 Ponytail은 지시대로 깔끔하고 짧게 구현합니다. 반면 ’랜딩 페이지를 만들어 줘’처럼 열린 요청에서 기본 Claude는 사용자의 의도를 짐작하고 필요한 UI 요소를 알아서 채워 넣는 Opus 5.5의 능력에 기댑니다. Ponytail은 바로 이 능력을 억누릅니다.
다섯 가지 prompt로 만든 랜딩 페이지를 평가자가 어느 설정의 결과인지 모른 채 채점한 결과는 다음과 같습니다. 부가 요소는 요청에는 없지만 있으면 좋은 화면 요소를 얼마나 갖췄는지를 뜻합니다.
| 설정 | 부가 요소 | 디자인 점수(5점 만점) | 페이지 5개 비용 |
|---|---|---|---|
| 기본 Claude | 82% | 4.3 | $1.83 |
| Ponytail 5 | 41% | 2.7 | $0.64 |
| 일곱 단어 prompt | 46% | 2.9 | $0.66 |
| Ponytail 5 + ‘polish it’ | 63% | 3.1 | $2.82 |
Ponytail로 만든 뒤 ‘polish it’(다듬어 줘)이라고 한 번 더 요청하면 부가 요소는 63%로 늘지만, 비용이 $2.82로 기본 Claude보다 오히려 비싸지고 디자인 점수는 여전히 낮습니다.
Free, Pro, Team 세 요금제를 둔 한 SaaS의 가격 페이지를 만드는 과제에서도 같은 경향이 나타났습니다.
| 설정 | 코드 | 비용 | 필수 요소 | 부가 요소 |
|---|---|---|---|---|
| 기본 Claude | 388줄 | $0.32 | 100% | 89% |
| Ponytail 5 | 94줄 | $0.13 | 100% | 47% |
| 일곱 단어 prompt | 93줄 | $0.11 | 100% | 39% |
| Ponytail 5 + ‘polish it’ | 209줄 | $0.50 | 100% | 66% |
기본 Claude는 내비게이션 바, 요금제별 기능 비교표, 접었다 펴는 FAQ까지 갖춘 페이지를 만들었습니다. Ponytail 5는 필수 요소를 모두 넣었지만 내비게이션 바, 애니메이션, 사용자 후기 같은 신뢰 요소, FAQ, 보조 행동 유도 버튼, 비교표, 결제 방식 전환 버튼을 뺐습니다. ’polish it’을 더한 뒤에도 풍부한 비교표와 기능별 상세 설명은 빠져 있었습니다. 이런 양상은 매장 분석 대시보드, 커피 로스터리 소개 페이지, 대기자 명단 페이지, 할 일 앱에서도 되풀이됐습니다.
결과를 모아 보면 Ponytail이 무엇을 덜어 내는지 분명해집니다. 요청한 기능은 거의 지키고, 요청하지 않은 부가 기능을 크게 줄입니다.
| 설정 | 요청한 기능 | 요청하지 않은 부가 기능 |
|---|---|---|
| 기본 Claude | 100% | 98% |
| Ponytail 5 | 98% | 54% |
| 일곱 단어 prompt | 97% | 36% |
빠진 부가 기능에는 검색, 페이지 나누기(pagination), 알기 쉬운 오류 메시지, 되돌리기(undo)처럼 실제 쓰임새에 영향을 주는 기능도 들어 있습니다. 화면이나 기능의 빈칸을 Claude가 알아서 채워 주길 기대하는 사용자라면 Ponytail의 엄격한 최소주의가 부족한 결과로 이어질 수 있습니다.
▲ 빠진 화면 부가 요소
정리: 요구 사항이 상세한 작업에, 프로젝트 단위로
Ponytail 5는 검증에서 코드 61%, 비용 24%, 실행 시간 35%를 줄여 공식 주장을 대체로 뒷받침했고, 큰 버그나 보안 문제도 만들지 않았습니다. 다만 그 효율은 Claude Opus 5.5의 가장 큰 강점인, 사용자가 말하지 않은 필요를 짐작해 알맞은 기본값으로 채우는 능력을 덜어 낸 대가로 보입니다. 규칙 묶음 하나로 모든 분야의 token 효율 문제가 간단히 풀린다면 Anthropic이나 OpenAI Codex 같은 곳이 이미 기본 기능으로 넣었을 것이라는 점에서도 만능 해법으로 보기는 어렵습니다.
| 상황 | 판단 |
|---|---|
| 모든 사양을 적은 PRD가 있는 백엔드·구조 설계 작업 | 설치해 볼 만함 |
| 프런트엔드 디자인, UI 시제품, 모호한 요청 | 기본 Claude가 나음 |
| 한두 줄을 고치는 작은 수정 | 지침을 싣는 token 부담이 절약분보다 큼 |
| 결과가 밋밋해 다듬기를 다시 요청해야 하는 경우 | 비용 이점이 사라짐 |
Ponytail을 고민한다면 다음 순서로 판단하면 됩니다.
- 모든 프로젝트에 한꺼번에 설치하지 말고, 한 프로젝트에서 먼저 시험해 비용과 결과물을 비교합니다.
- 요구 사항을 상세히 정해 둔 작업에 쓰고, 화면 디자인처럼 Claude의 판단에 기대는 작업에서는 끕니다.
- 결과가 밋밋하다고 ‘polish it’ 같은 추가 요청으로 메우지 않습니다. 대화가 이어질수록 절약한 비용이 사라집니다.
- 비용만 보고 일곱 단어 같은 아주 짧은 지침에 실제 서비스 코드를 맡기지 않습니다. 테스트 누락과 데이터 손실 버그로 이어질 수 있습니다.
- Ponytail을 쓰지 않더라도 그 생각은 CLAUDE.md나 AGENTS.md 같은 지침 파일에 옮겨 쓸 수 있습니다. 고치기 전에 영향 범위를 먼저 정리하게 하고, 건너뛴 항목과 확인하지 않은 위험을 밝히게 하면 무엇을 감수하는지 눈으로 확인할 수 있습니다.