포니테일(Ponytail) 스킬 정리 — AI 코드 54% 줄이는 미니멀리즘, 설치법까지

누구나 겪어봤을 장면 하나. 날짜 입력창 하나 만들어 달라고 했더니, AI가 flatpickr 라이브러리를 통째로 깔고 설정 파일까지 만든다. 브라우저엔 이미 <input type="date">가 있는데 말이다. 포니테일(Ponytail)은 바로 이 과잉 구현을 막으려고 나온 스킬이다. 저장소 소개 문구가 성격을 그대로 말해준다. "당신의 AI 에이전트를 방 안에서 제일 게으른 시니어처럼 생각하게 만든다."

포니테일의 얼굴은 '방 안에서 제일 게으른 시니어' 그 자체다. 오십 줄짜리 코드를 보고 아무 말 없이 한 줄로 바꿔놓는, 딱 그 표정. (출처: DietrichGebert/ponytail)

여기서 스킬은 앤트로픽이 정의한 그 스킬, 즉 에이전트에게 규칙을 주입하는 SKILL.md 파일이다. 포니테일은 그 안에 '절제의 규칙'을 담았다. 새 코드를 짜기 전에 순서대로 따져 묻게 만든다.

게으름에도 순서가 있다

1. 이거 진짜 필요한가? 추측성 기능이면 만들지 마라 (YAGNI)
2. 기존 코드에 있는 헬퍼·유틸부터 재사용해라
3. 표준 라이브러리로 되면 그걸 써라
4. 브라우저 네이티브 기능(CSS, <input>)이 있으면 그걸 써라
5. 이미 깔린 패키지로 해결해라
6. 한 줄로 되면 한 줄로, 안 되면 최소한의 코드만

"삭제가 추가보다 낫고, 지루한 게 영리한 것보다 낫다"가 핵심 문장이다. 단, 게으름에도 예외는 있다. 입력 검증, 에러 처리, 보안, 접근성은 절대 생략하지 않는다. 저자도 "이해를 건너뛰고 작은 diff만 뽑아내는 게으름은 위험한 종류"라고 못 박아 뒀다.

숫자와 그 뒤의 물음표

저자가 공개한 벤치마크는 화려하다. 스킬 없이 돌린 것과 비교해 코드는 54% 줄고, 토큰 22%, 비용 20%가 줄었으며, 실행은 27% 빨라졌는데 안전성은 그대로였다. 앞서 말한 날짜 선택기는 404줄에서 23줄로, 색상 선택기는 287줄에서 23줄로 쪼그라들었다.

그런데 이 숫자를 곧이곧대로 믿기 전에 짚을 게 있다. 벤치마크는 저자 본인이 측정한 값이다. 해커뉴스에선 "결국 규칙 몇 줄이고 나머지는 플러그인용 보일러플레이트 아니냐", "일곱 단어짜리 YAGNI 프롬프트로도 비슷하지 않겠냐"는 냉소가 나왔다. 더 실질적인 빈틈은 따로 있다. 포니테일의 가장 큰 절감은 라이브러리 대신 브라우저 네이티브를 고를 때 나오는데, 이미 shadcn/ui나 테일윈드 같은 디자인 시스템을 쓰는 프로젝트라면 정답이 오히려 '그 컴포넌트 라이브러리'다. 사다리상으론 '이미 깔린 패키지'가 네이티브보다 위라 이론적으론 맞게 판단하겠지만, 저자 벤치마크가 디자인 시스템 없는 템플릿으로 돌린 탓에 이 부분은 아직 검증되지 않았다. 팀 규칙이 확고한 성숙한 코드베이스에서도 잘 먹히는지는 써봐야 안다.

왜 이렇게 떴나

2026년 6월 공개된 지 9일 만에 스타 4만 개, 지금은 13만 개를 넘겼다. 클로드 코드부터 Codex, 깃허브 코파일럿 CLI, 제미나이 CLI까지 20개가 넘는 에이전트를 지원하고, MIT 라이선스라 공짜에 설정 파일도 필요 없다. 한 리뷰어의 표현이 정확하다. 많은 팀이 말로만 하고 문서로는 안 적던 위생 습관을, 포니테일이 코드로 박제해줬다는 것이다.

설치 — 내 도구에 맞게

플러그인을 지원하는 도구는 두 줄이면 끝난다. 클로드 코드 기준으로 마켓플레이스를 등록하고 설치한다.

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

다른 CLI도 방식만 조금씩 다르다. 자기가 쓰는 것 한 줄만 골라 치면 된다.

# Codex
codex plugin marketplace add DietrichGebert/ponytail
codex plugin add ponytail@ponytail

# GitHub Copilot CLI
copilot plugin marketplace add DietrichGebert/ponytail
copilot plugin install ponytail@ponytail

# Gemini CLI / Antigravity
gemini extensions install https://github.com/DietrichGebert/ponytail

# Devin / Grok / Pi
devin plugins install DietrichGebert/ponytail
grok plugin install DietrichGebert/ponytail --trust
pi install git:github.com/DietrichGebert/ponytail

플러그인 체계가 없는 도구(커서·윈드서프·클라인·Kiro 등)는 규칙 파일만 프로젝트에 넣는 '수동 설치(지시문 모드)'를 쓴다. 저장소를 받아서 자기 도구에 맞는 파일을 복사하면 된다.

git clone https://github.com/DietrichGebert/ponytail

# 커서 — 훅 스크립트로 설치 (--project 붙이면 프로젝트 한정)
node ponytail/scripts/cursor-hooks.js install

# 규칙 파일만 넣는 '지시문 모드' — 도구별로 경로가 다르다
#  커서:      .cursor/rules/ponytail.mdc
#  윈드서프:  .windsurf/rules/ponytail.md
#  Copilot:   .github/copilot-instructions.md
#  Kiro:      .kiro/steering/ponytail.md
#  그 외 공통: AGENTS.md 를 프로젝트 루트에 복사

강도는 세 단계다. 제안만 하는 lite, 사다리를 강제하는 full(기본), 요구사항이 필요한지부터 따지고 드는 ultra, 그리고 끄는 off. 스킬을 지원하는 도구에선 /ponytail lite|full|ultra|off로 바꾸고, 기본값은 환경변수 PONYTAIL_DEFAULT_MODE 나 ~/.config/ponytail/config.json 의 defaultMode 로 고정한다. 이 밖에 /ponytail-review(지금 diff의 과잉 구현 점검), /ponytail-audit(레포 전체 감사), /ponytail-gain(절감 스코어보드) 같은 명령이 함께 딸려 온다.

제대로 붙었는지는 새 대화를 열었을 때 시작 문구에 현재 모드(예: full)가 표시되는지로 확인한다. 커서 훅 방식이라면 ~/.cursor/hooks.json 에 ponytail 항목이 들어갔는지 보면 된다.

며칠 써보고 든 생각은 이렇다. 포니테일의 값어치는 신기술이 아니라 '태도의 기본값'을 바꾼 데 있다. AI에게 일을 시키면 열에 아홉은 시키지도 않은 걸 얹어 오는데, 그 습성의 방향을 반대로 틀어놓는 것만으로도 리뷰 시간이 눈에 띄게 준다. 다만 벤치마크 숫자에 취해 모든 프로젝트에 ultra를 걸어두는 건 위험하다. 이미 잘 정리된 디자인 시스템 위에서 "더 짧게"만 외치면, 팀이 애써 맞춰둔 일관성을 게으름이 갉아먹을 수 있다. 결국 이 스킬도 도구다. 언제 게을러도 되고 언제는 안 되는지, 그 판단만큼은 사람 몫으로 남는다.