Ponytail, 코딩 에이전트에게 코드를 덜 쓰게 만드는 오픈소스 스킬

코딩 에이전트에게 날짜 선택기를 붙여 달라고 하면 어떤 일이 벌어지는지 대부분 안다. 라이브러리를 하나 설치하고, 감싸는 컴포넌트를 만들고, 스타일시트를 추가한 다음, 시간대 처리에 관한 설명을 시작한다. 브라우저에 이미 <input type="date">가 있다는 사실은 언급되지 않는다. Ponytail은 이 습관을 겨냥한 스킬이다. 회사 버전 관리 시스템보다 오래 근무한, 긴 머리에 둥근 안경을 쓴 시니어 개발자를 에이전트 안에 넣는다는 컨셉이고, 저장소 설명은 이렇게 요약한다. 가장 좋은 코드는 애초에 쓰지 않은 코드다.

한눈에 보기

사다리 7칸을 순서대로 내려간다

동작 원리는 규칙 목록 하나로 끝난다. 에이전트는 코드를 쓰기 전에 아래 사다리를 위에서부터 훑고, 처음으로 답이 나오는 칸에서 멈춘다.

1. 이게 존재할 필요가 있나?      → 아니면 만들지 않는다 (YAGNI)
2. 이미 이 코드베이스에 있나?    → 다시 쓰지 말고 재사용한다
3. 표준 라이브러리로 되나?       → 그걸 쓴다
4. 플랫폼 기본 기능인가?         → 그걸 쓴다
5. 설치된 의존성으로 되나?       → 그걸 쓴다
6. 한 줄로 되나?                 → 한 줄로 쓴다
7. 그래도 안 되면                → 동작하는 최소한만 만든다

중요한 것은 이 사다리가 문제를 이해한 다음에 돌아간다는 점이다. 저장소는 이 부분을 분명히 못 박는다. 변경이 닿는 코드를 읽고 실제 흐름을 따라간 뒤에 칸을 고른다. 해법에는 게으르되 읽는 데는 게으르지 않다는 것이다. 앞의 날짜 선택기 예시가 4번 칸에서 멈추는 경우다. 저장소가 공개한 사례에서는 404줄짜리 구현이 23줄로, 색상 선택기는 287줄이 23줄로 줄었다.

측정값을 스스로 낮춰 잡은 벤치마크

숫자를 내세우는 프로젝트는 많지만 이 저장소는 자기 숫자를 내린 적이 있어서 참고할 만하다. 처음에는 모델에 프롬프트를 한 번 넣고 답변 줄 수를 세는 방식으로 코드량 80~94% 감소를 내걸었다. 그런데 비교 대상인 맨 모델이 설명과 선택지를 덧붙이며 답을 길게 쓰는 탓에 격차가 부풀려진다는 지적이 이슈로 들어왔고, 저장소는 측정을 다시 설계했다.

새 측정은 헤드리스 Claude Code 세션이 full-stack-fastapi-template이라는 실제 오픈소스 저장소를 고치게 하고, 남은 git diff를 채점하는 방식이다. 기능 티켓 12개, 스킬을 켠 경우와 끈 경우, 각 4회, Haiku 4.5 기준이다.

결과는 코드량 54% 감소, 토큰 22% 감소, 비용 20% 감소, 시간 27% 감소다. 같이 비교한 다른 방식과 견주면 성격이 드러난다. 말투만 짧게 만드는 대조군은 코드량을 20% 줄이는 대신 토큰과 비용, 시간이 오히려 늘었다. “YAGNI로 한 줄만 써라”라고 지시하는 프롬프트는 코드량을 33% 줄였지만 안전성 시험에서 방어 코드를 한 번 빠뜨렸다. 모든 지표를 함께 낮추면서 안전성 100%를 유지한 것은 Ponytail뿐이었다.

게으르되 부주의하지는 않다

이런 도구에서 가장 먼저 걱정되는 것은 줄이지 말아야 할 것까지 줄이는 경우다. 저장소는 규칙이 “토큰을 가장 적게 쓰는 것”이 아니라고 못 박고, 신뢰 경계에서의 입력 검증과 데이터 손실 처리, 보안, 접근성은 잘라 내는 대상이 아니라고 명시한다. 결과물이 작아지는 이유는 짧게 쓰려고 줄여서가 아니라 필요한 것만 남겨서라는 설명이다. 앞의 안전성 시험에서 경로 조작과 SQL 주입, 잘못된 입력 같은 항목을 통과한 것이 이 주장을 뒷받침한다.

명령으로 강도를 조절한다

설치하면 강도를 바꾸는 명령이 따라온다. /ponytail lite, full, ultra, off로 개입 수준을 조절하고, 인자 없이 부르면 현재 설정을 알려 준다. 그 밖에 현재 변경분을 과잉 설계 관점에서 검토해 지울 목록을 돌려주는 /ponytail-review, 저장소 전체를 훑는 /ponytail-audit, 미뤄 둔 단축 결정을 장부로 모으는 /ponytail-debt가 있다. 다만 이 명령들은 스킬을 지원하는 호스트에서만 동작한다. Cursor의 규칙 파일이나 Windsurf, Cline, Copilot처럼 지시문만 읽는 어댑터에서는 상시 규칙만 적용되고 명령은 쓸 수 없다.

시작하기

1. Claude Code에서 /plugin marketplace add DietrichGebert/ponytail을 보낸다.
2. 이어서 /plugin install ponytail@ponytail을 보낸다. 두 명령은 반드시 따로 보내야 설치된다.
3. node가 PATH에 있는지 확인한다. 생명주기 훅 두 개가 Node.js로 돌기 때문이다. 없어도 스킬 자체는 동작하고 상시 활성화만 조용히 꺼진다.
4. 강도를 /ponytail full로 켜 두고 평소 작업을 시킨 뒤, 만들어진 diff를 /ponytail-review로 한 번 되돌아본다.

에이전트가 만든 코드를 사람이 읽고 유지보수해야 하는 팀이라면 효과가 바로 보인다. 특히 프런트엔드에서 기성 컴포넌트를 습관적으로 설치하는 패턴을 많이 겪었다면 체감이 크다. 반대로 이미 규칙이 촘촘한 레거시 코드베이스이거나, 정해진 사내 컴포넌트 라이브러리를 반드시 써야 하는 환경이라면 사다리 2번 칸과 충돌할 수 있으니 강도를 낮춰 시작하는 편이 낫다.

주의점

• 모든 모델에서 싸지는 것은 아니다. 저장소도 사다리를 놓고 오래 숙고하는 추론 모델에서는 오히려 비용과 지연이 늘 수 있다고 적어 두었고, 특정 모델을 실명으로 언급한다. 측정값은 Haiku 4.5 기준이라는 점을 감안해야 한다.
• 코드량 54%는 평균이지 보장이 아니다. 과잉 설계 여지가 큰 작업에서는 90%대까지 줄지만, 이미 최소한으로 짜인 코드에서는 거의 0에 가깝다. 자기 저장소에서 직접 재 보는 것이 맞다.
• 명령 지원은 도구마다 다르다. 스킬을 지원하지 않는 편집기에서는 상시 규칙만 걸리고 검토나 감사 명령을 쓸 수 없으니, 도입 전에 쓰는 도구가 어느 쪽인지 확인해야 한다.
• 규칙이 팀의 관례와 부딪힐 수 있다. 의존성을 줄이라는 지침은 사내 표준 라이브러리를 쓰라는 지침과 충돌하기 쉽다. 강도 설정과 코드 리뷰로 경계를 정해 두는 편이 안전하다.

정리

Ponytail은 새 기능을 더하는 도구가 아니라 만들지 않을 이유를 먼저 확인하게 만드는 규칙 묶음이다. 사다리 일곱 칸이라는 형식이 단순해서 결과를 사람이 검증하기 쉽고, 벤치마크를 스스로 낮춰 다시 잰 이력 덕분에 숫자를 그대로 받아들이기도 덜 부담스럽다. MIT 라이선스에 설치가 명령 두 줄이니, 에이전트가 만든 diff가 매번 필요 이상으로 길다고 느껴 왔다면 한 번 켜 보고 직접 비교해 볼 만하다.