AI 에이전트에 '덜 쓰기'를 가르치는 오픈소스, ponytail

게으른 시니어를 에이전트에 넣는 플러그인

DietrichGebert/ponytail은 2026년 10월 1일에 저장소를 열어 보니 별 14.97만 개, 포크 8.0k를 모은 MIT 라이선스 오픈소스예요. 표어는 "방 안에서 가장 게으른 시니어 개발자처럼 AI 에이전트가 생각하게 만든다"예요.

ponytail은 AI 코딩 에이전트(Claude Code, Codex, Cursor 등)에 룰과 스킬을 주입해서, 에이전트가 그 자리에 있는 '가장 게으른 시니어 개발자'처럼 행동하게 해요. 파일 50줄을 들이밀면 말없이 바라본 뒤 한 줄로 바꿔 주는 그런 선배요. 에이전트가 명령을 받자마자 프레임워크부터 깔려는 습관을 여기서 멈추게 하는 거예요.

before/after 예시가 직관적이에요. 날짜 선택기 하나만 요청했는데 에이전트가 날짜 라이브러리부터 설치하려 할 때, ponytail이 붙어 있으면 이렇게 돼요.

<!-- ponytail: browser has one -->
<input type="date">

README의 before/after에서 더 많은 사례를 볼 수 있어요.

'사다리' 룰: 첫 번째로 맞는 단계에서 멈춘다

ponytail의 핵심은 YAGNI(You Aren't Gonna Need It, 필요 없는 건 만들지 말 것) 사다리예요. 코드를 쓰기 전에 아래 7단계를 올라가면서 가장 먼저 성립하는 단계에서 멈춰요.

1. 정말 존재해야 하나?         → 아니면 건너뛴다 (YAGNI)
2. 이미 이 코드베이스에 있나?   → 다시 쓰지 말고 재사용
3. 표준 라이브러리가 되나?     → 쓴다
4. 네이티브 기능이 되나?       → <input type="date"> 로 픽커 라이브러리 대체
5. 설치된 의존성이 되나?       → 새로 추가하지 않는다
6. 한 줄이면 되나?             → 한 줄
7. 그 다음에만: 동작하는 최소 코드

이 사다리가 문제를 이해하고 난 뒤에 작동한다는 점이 중요해요. 룰을 고르기 전에 변경할 코드를 먼저 읽고 실제 흐름을 추적한다고 해요. How it works에 적힌 표현 그대로, "풀이에는 게을러도 읽기에는 게으르지 않다"는 거죠.

실제 레포 벤치마크로 잰 수치

저자가 스스로 "솔직하게 잰 벤치마크"를 공개했어요. 아래는 저자의 자체 측정이고, 제가 재현한 값이 아니에요. 실제 헤드리스 Claude Code 세션으로 tiangolo/full-stack-fastapi-template(FastAPI+React 레포)을 편집하게 하고, 남긴 git diff 추가 줄 수를 기준으로 비교했어요. 스킬 없는 에이전트 대비 12개 피처 태스크의 평균치(n=4, Haiku 4.5)예요.

출처: © 2026 DietrichGebert

그림 출처: DietrichGebert/ponytail (commit 9cc65d03aa2d) · © 2026 DietrichGebert · MIT · 원본 그대로 사용

포인트가 뚜렷해요. ponytail은 모든 지표를 동시에 줄인 유일한 방식이고, 유일하게 100% 안전을 유지했어요. 반면 간결한 문체만 강조한 caveman은 코드는 적게 썼지만 토큰이 오히려 늘었고(+7%), 짧은 프롬프트는 값싸고 빠르지만 안전도가 95%로 떨어졌어요.

할인폭은 태스크마다 차이가 커요. 네이티브 입력 요소로 맞바꿀 수 있는 곳에서 극적으로 나와요. 날짜 선택기 404줄 → 23줄, 색상 선택기 287줄 → 23줄, 파일 드롭존 251줄 → 95줄. 반대로 이미 최소한인 백엔드 CRUD 같은 코드에선 네 방식 모두 비슷한 선에서 수렴했어요.

즉 -54%는 평균이고, 깎을 곳에선 크게, 없는 곳에선 거의 그대로라는 게 정정된 결론이에요.

이 벤치마크에는 드라마도 있어요. 원래 저장소는 단일 호출 기준 80~94%라는 수치를 내세웠는데, 커뮤니티의 #126 이슈가 "기준선에 간결하게 답하라는 지시가 없어 장황하게 답하기 때문에 수치가 부풀려졌다"고 짚었어요. 그래서 기준선을 '스킬 없는 실제 에이전트 세션'으로 바꿔 다시 잰 게 바로 위 표예요.

저장소는 이제 80~94% 격차가 "부분적으로 채팅형 기준선의 착시"라고 밝히고, 위 에이전트 수치를 "정정된, 방어 가능한 버전"이라고 불러요. 효과는 과설계 함정이 있는 곳에서 가장 크고, 이미 최소인 코드에서는 거의 없다고 적혀 있어요. 벤치마크 원문이 공개되어 누구나 재현 가능해요.

게으름의 최소 안전선

핵심은 ponytail의 룰이 "토큰을 아끼자"가 아니라 "할 일에 필요한 만큼만 쓰고, 검증·에러 처리·보안·접근성은 절대 잘라내지 않는다"라는 데 있어요. 안전 태스크(경로 탐색·SQL 인젝션·위조 토큰 등에 대한 방어)에서 그 차이가 도드라졌어요.

safe-path 태스크에서 한 줄 프롬프트는 6줄로 가장 짧게 썼지만 4번 중 1번, ../../ 가 디렉토리 바깥으로 나가는 경로 탐색 공격을 놓쳤어요. ponytail은 9.5줄로 4/4 안전했는데, 그 추가된 3줄이 바로 경로 탐색 검증이었어요.

'덜 쓴다'와 '태만하다'의 경계가 정확히 이 검증선이에요.

20여 개 에이전트에서 쓰는 설치

주요 행을 정리하면 이래요.

• Claude Code: /plugin marketplace add DietrichGebert/ponytail 입력 뒤 /plugin install ponytail@ponytail (두 번에 나눠 입력)
• Codex: codex plugin marketplace add + codex plugin add
• Gemini/Antigravity CLI: gemini extensions install https://github.com/DietrichGebert/ponytail 또는 agy plugin install
• OpenCode: opencode.json에 @dietrichgebert/ponytail 플러그인 등록
• Hermes Agent: hermes plugins install DietrichGebert/ponytail --enable 후 재시작
• OpenClaw: clawhub install ponytail

설치 섹션 전체에 20여 개 에이전트용 지침이 정리돼 있어요. 플러그인 훅이 없는 Cursor·Windsurf·Cline·Copilot Chat·Kiro·Zed 같은 편집기 계열은 이 저장소의 .cursor/rules/ 나 AGENTS.md 같은 룰 파일을 복사하는 방식으로 동작해요.

설정 파일 없이도 되고, PONYTAIL_DEFAULT_MODE 환경변수나 선택적 설정 파일로 기본 강도를 정할 수 있어요.

명령어로 게으름의 강도를 조절해요

챗에서 강도를 바꾸는 명령어를 제공해요. /ponytail lite|full|ultra|off 로 수준을 조절하고, /ponytail-review(현재 diff의 과설계 검토), /ponytail-audit(전체 레포 감사), /ponytail-debt(뒤로 미룬 절충을 ledger로 수집) 같은 명령도 있어요.

강도 단계별 동작 설명은 제가 확인한 README 범위에서는 찾지 못했어요. 절충한 곳에 ponytail: 마커 주석을 남겨두면 나중에 /ponytail-debt 로 모아 '갚을' 수 있게 설계했어요.

명령표를 보면 게으름과 책임을 어떻게 함께 설계했는지가 드러나요.

수치를 어떻게 읽어야 하나

벤치마크 원문을 보면 조건이 분명히 적혀 있어요. 엔진은 헤드리스 Claude Code, 모델은 Haiku 4.5 하나이고, 태스크는 기능 12개와 안전 6개 총 18개, 태스크당 4회 실행이에요. 그래서 -54%는 "여러 태스크 평균"일 뿐 모든 작업에서 절반이 줄어든다는 뜻이 아니에요. 저장소도 날짜 선택기 404줄에서 23줄 같은 큰 절감은 과설계 함정이 있는 곳에서 나오고, 이미 최소인 코드에서는 줄지 않는다고 적어요.

안전 100% 대 95%도 조심해서 봐야 해요. 안전 태스크는 실행 20회 기준이라 95%는 20번 중 1번 실패(19/20)예요. 한 번의 차이를 "ponytail만 안전하다"는 증거로 삼기에는 표본이 작아요. 저자도 이를 "바닥(floor)"이라고 부르고, 결정적인 6개 태스크로 한정된 검사라는 점을 한계로 밝혀요. 이 글에서 의미 있게 읽을 부분은 경로 탐색 태스크의 방향성이에요. 한 줄 프롬프트가 6줄로 짧게 썼다가 한 번 놓친 검증을 ponytail은 9.5줄에서 4번 모두 챙겼다는 건, "줄 수를 줄이는 규칙"이 "검증을 자르는 규칙"으로 번질 수 있다는 구체적 사례예요.

또 하나는 지표 자체예요. 비교 기준이 git diff 추가 줄 수라서 코드가 짧을수록 좋은 것으로 계산돼요. 줄 수가 줄어든 대신 네이티브 요소로 바꾼 기능이 요구사항을 다 충족하는지, 유지보수 비용이 실제로 내려갔는지는 이 표가 답하지 못해요. 예를 들어 <input type="date">는 브라우저별 모양이 다르고 커스텀 디자인이 막혀서, 디자인 요구가 있는 서비스에서는 23줄짜리 결과를 그대로 쓸 수 없을 수 있어요. 이건 수치가 아니라 제 추론이에요.

그래서 도입 전에 해 볼 일은 내 레포에서 같은 조건의 비교예요. 평소 쓰는 모델로 지난 기능 요청 몇 개를 스킬 있음/없음으로 돌려서 줄 수와 테스트 통과 여부를 같이 보는 거예요. 평균 54%는 저자의 레포와 저자의 모델에서 나온 숫자이고, 내 작업에서 얼마가 될지는 직접 재 봐야 알 수 있어요. MIT 라이선스라서 끼워 보고 걷어내기는 쉬워요. 시작 방법은 ponytail.dev에서 확인할 수 있어요.

참고 링크

• GitHub 저장소: DietrichGebert/ponytail
• 공식 사이트: ponytail.dev
• 에이전트 벤치마크 원문
• 단일호출 벤치마크에 대한 #126 논의