AI에게 "덜 만들어"라고 시키는 스킬, Ponytail을 직접 돌려봤다

AI 코딩 에이전트는 묻지도 않은 것까지 만든다

여러분, 클로드 코드 같은 에이전트를 쓰다 보면 이런 경험 한 번씩 있으셨을 겁니다. 버튼 하나 만들어 달라고 했는데 컴포넌트를 쪼개고, 추상화 계층을 세우고, 의존성을 끌어오고, 브라우저에 이미 들어 있는 기능까지 처음부터 다시 짭니다. AI 코딩 에이전트가 “도움이 되도록” 학습된 결과죠. 그런데 현업에서 코드를 써본 개발자는 압니다. 좋은 코드는 더 많이 짠 코드가 아니라 덜 짠 코드라는 걸요.

Ponytail은 바로 그 지점을 겨눈 스킬입니다. AI 코딩 에이전트에게 “새로 만들기 전에 일단 멈춰라”라고 거는 브레이크라고 보면 됩니다. 2026년 6월 12일에 공개됐고, 2주 만에 깃허브 스타 5만 개를 넘겼습니다.

이 글에서 정리하고 싶은 건 네 가지입니다. Ponytail이 무엇이고 왜 만들어졌는지, 어떤 원리로 코드를 줄이는지, 제가 직접 돌려본 실험에서 실제로 얼마나 줄었는지, 그리고 어디까지 믿고 쓸 수 있는지입니다.

Ponytail은 AI를 “게으른 시니어 개발자”로 만든다

Ponytail의 콘셉트는 한 문장으로 요약됩니다. AI를 게으른 시니어 개발자처럼 굴게 만든다는 겁니다. 깃허브 저장소에는 긴 머리에 둥근 안경을 쓴 시니어 캐릭터, 이른바 “포니테일 아저씨”가 그려져 있는데요. 딱 봐도 개발 잘하게 생긴 관상이라 콘셉트가 한눈에 들어옵니다. 이름이 독일식이라 만든 사람이 독일계 개발자로 추정되지만, 이건 단정할 근거까지는 없습니다.

게으른 시니어는 일을 대충 하는 사람이 아닙니다. 새 코드를 짜기 전에 “이거 꼭 만들어야 하나”부터 묻고, 만들어야 한다면 “이미 누가 만들어 둔 건 없나”를 먼저 찾는 사람이죠. 라이브러리에 있으면 가져다 쓰고, 브라우저가 기본으로 제공하면 그걸 씁니다. 손이 게으른 게 아니라 새 코드를 늘리는 데 게으른 겁니다.

Ponytail은 이 태도를 규칙으로 명문화해 AI 에이전트에 주입합니다. 클로드 코드, Codex, 커서 같은 에이전트에 스킬 형태로 붙습니다.

AI는 왜 코드를 과하게 짜는가

문제의 뿌리는 학습 방향에 있습니다. AI 코딩 에이전트는 “도움이 되는” 답을 내도록 훈련됐죠. 사용자가 모달을 만들어 달라고 하면, AI 입장에서 “도움”은 대개 다음과 같은 모습입니다.

• 재사용 가능한 컴포넌트로 분리한다
• props로 모든 경우를 커버한다
• 애니메이션 옵션을 넣는다
• 포커스 트랩과 키보드 핸들링을 직접 구현한다
• 상태 관리 훅을 따로 뺀다

각각은 그 자체로 나쁜 선택이 아닙니다. 문제는 요청이 “지금 당장 필요한 것”이었는데 AI가 “언젠가 필요할지 모르는 것”까지 전부 짠다는 데 있죠. 브라우저 dialog 태그 하나면 끝날 일을 200줄짜리 컴포넌트로 만듭니다. 적게 만드는 게 더 나은 상황에서도 AI는 더 많이 만드는 쪽으로 기울어 있습니다. AI가 멍청해서가 아니라 오히려 너무 똑똑해서, 친절하게 응답하도록 보상 학습된 결과라고 보면 됩니다.

7단계 판단법, 그리고 소프트웨어 3대 원칙

Ponytail은 새 코드를 짜기 전에 AI가 거쳐야 할 7개의 관문을 세웁니다.

1. 정말 필요한가 (YAGNI, You Ain’t Gonna Need It)
2. 코드베이스에 이미 있는가
3. 표준 라이브러리로 되는가
4. 브라우저나 플랫폼이 네이티브로 제공하는가
5. 이미 설치된 의존성으로 되는가
6. 한 줄로 끝나는가
7. 그래도 만들어야 한다면, 최소 구현으로

제가 보기에 이 순서가 핵심입니다. 위쪽 관문(필요한가, 이미 있나, 표준이나 네이티브로 되나)에서 대부분이 걸러집니다. 아래로 갈수록 “그래도 만들어야 한다면”의 영역이고, 거기서도 최소한으로 짜게 만들죠.

이건 사실 소프트웨어 3대 원칙을 AI에 강제하는 것과 같습니다.

• YAGNI (You Ain’t Gonna Need It): 필요해질 때까지 만들지 마라
• KISS (Keep It Short and Simple): 짧고 단순하게 유지하라
• DRY (Don’t Repeat Yourself): 같은 것을 반복하지 마라

사람 개발자라면 경험으로 체화한 원칙들이죠. Ponytail은 이걸 규칙 텍스트로 명문화해 매 요청마다 AI 앞에 들이밉니다.

한 가지 중요한 단서가 있습니다. Ponytail은 보안, 입력 검증, 접근성은 깎지 않습니다. 게으른 것과 소홀한 건 다르니까요. 줄여도 되는 것(불필요한 추상화, 과한 컴포넌트화)과 줄이면 안 되는 것(안전과 품질)을 구분합니다.

직접 실험 1: 작은 컴포넌트 4종

말로만 들으면 그럴듯하죠. 그래서 제가 직접 돌려봤습니다. 클로드 코드 Opus로 동일한 프롬프트를 세 가지 조건에서 실행했습니다.

• baseline: 아무 규칙도 주지 않음
• YAGNI: “YAGNI 지켜” 한 줄만 추가
• Ponytail: Ponytail 스킬 적용

작은 컴포넌트 4종을 만들게 하고 생성된 코드 줄 수를 셌습니다.

컴포넌트	baseline	YAGNI	Ponytail
모달	230	143	100
색상 선택기	197	105	71
아코디언	180	129	78
날짜 선택기	151	91	61

순서는 네 번 모두 똑같았습니다. baseline이 가장 길고, YAGNI 한 줄이 그다음, Ponytail이 가장 짧았죠. Ponytail은 평균적으로 baseline의 약 40%, 즉 절반 이하 줄 수로 같은 컴포넌트를 만들어 냈습니다. 기능은 셋 다 동일하게 잘 동작했고요.

다만 정직하게 짚을 부분이 있습니다. 날짜 선택기와 색상 선택기는 baseline조차 이미 브라우저 네이티브 input을 썼습니다. 그러니까 Ponytail의 기여는 “네이티브 기능을 새로 발견한 것”이 아니라 “그 위에 붙은 군더더기를 걷어낸 것”이었던 거죠. 실제로 구조 자체가 바뀐 건 아코디언 하나뿐이었습니다. baseline은 자바스크립트로 펼침 로직을 짰는데, Ponytail은 브라우저 네이티브 details 태그로 처리했습니다.

속도와 토큰: “YAGNI 지켜” 한 줄의 가성비

제가 더 흥미롭게 본 건, “YAGNI 지켜” 한 줄만 추가해도 코드가 꽤 줄었다는 점입니다. Ponytail만큼은 아니어도, 단어 하나로 baseline 대비 30~40% 감소 효과가 있었습니다.

속도는 Ponytail이 가장 빨랐습니다. 같은 컴포넌트 생성에 걸린 시간(날짜 선택기 기준)은 Ponytail 14초, YAGNI 16초, baseline 32초였죠. 코드가 적으니 생성도 빨랐고, 4종 모두 Ponytail이 가장 빨랐습니다.

그런데 토큰은 예상을 벗어났습니다. 4종 합산 세션 토큰은 다음과 같습니다.

조건	세션 토큰 (4종 합)
baseline	64,029
YAGNI	60,931
Ponytail	61,750

가장 적게 쓴 건 Ponytail이 아니라 YAGNI였습니다. Ponytail은 매 요청마다 7단계 규칙을 주입하기 때문에 입력 토큰을 더 씁니다. 그래서 출력(코드)이 가장 짧은데도 총 토큰은 YAGNI보다 살짝 많았죠. 그래도 baseline보다는 적었습니다. 출력이 줄어든 효과가 규칙 주입 비용을 상쇄한 셈입니다.

정리하면 “YAGNI 지켜” 한 줄은 비용 대비 효율이 좋은 가성비 옵션이고, Ponytail은 코드량과 속도를 가장 확실하게 잡되 토큰을 조금 더 쓰는 옵션이라고 봅니다.

직접 실험 2: 대규모 칸반 보드

작은 컴포넌트에서의 효과가 큰 작업에서도 유지될까요. 이게 제일 궁금했습니다. 이번엔 팀 칸반 보드 하나를 /goal 명령 한 방으로 통째로 만들게 했습니다. 조건은 동일하게 셋입니다.

전체 줄 수는 baseline 811, YAGNI 849, Ponytail 722였습니다. Ponytail이 여전히 가장 적긴 했지만 baseline 대비 11% 감소에 그쳤죠. 작은 컴포넌트에서 약 60% 줄였던 것과 비교하면 효과가 확연히 약합니다. 흥미롭게도 YAGNI는 이번엔 baseline보다 오히려 길었고요.

세션 시간도 역전됐습니다. baseline 5분 5초, YAGNI 5분 29초, Ponytail 5분 58초로, 대규모 작업에서는 Ponytail이 가장 오래 걸렸습니다. 규칙을 따져 가며 만드느라 더 느려진 것으로 보입니다.

토큰도 큰 차이가 없었습니다. baseline 91,582, YAGNI 94,648, Ponytail 91,749로 사실상 비슷했죠.

이유는 단순합니다. 칸반 보드처럼 규모가 크고 구현해야 할 로직이 명확하게 정해진 작업에서는, 줄일 수 있는 군더더기 자체가 적습니다. 만들어야 할 게 진짜로 많거든요. 이번 실험에서도 Ponytail이 네이티브 태그로 단순화한 건 도움말 섹션 정도였고, 나머지 본체 로직은 어느 조건이든 비슷하게 짤 수밖에 없었습니다.

결론적으로 Ponytail은 “꼭 안 만들어도 되는 것”과 “이미 있는 것”이 섞여 있는 작은 작업에서 효과가 극대화되고, 규모가 크고 로직이 정해진 작업에서는 효과가 미미하다고 정리할 수 있습니다.

설치 방법

클로드 코드 기준 설치는 두 줄이면 됩니다.

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

모드는 네 가지입니다. lite, full, ultra, off. 기본값은 full이고요. 게으름의 강도를 조절한다고 보면 됩니다. 가볍게 적용하려면 lite, 강하게 밀어붙이려면 ultra, 잠깐 끄려면 off입니다. 한 번 레벨만 정해 두면 그다음부터는 스킬이 알아서 작업에 맞게 불려와 동작합니다. 저장소는 github.com/DietrichGebert/ponytail에 있습니다.

결론: 작은 작업엔 효과가 크고, 큰 앱엔 미미하다

결론부터 말하면, Ponytail은 AI 코딩 에이전트에 소프트웨어 3대 원칙을 강제하는 스킬입니다. 작은 컴포넌트를 만들 때는 코드량을 절반 이하로 줄이고 생성 속도도 가장 빨랐습니다. 여기서 제가 더 중요하게 보는 건, “YAGNI 지켜” 한 줄만으로도 비슷한 방향의 효과를 볼 수 있다는 점, 그리고 토큰 효율만 따지면 오히려 그 한 줄이 더 낫다는 점입니다.

반대로 규모가 크고 구현 로직이 정해진 애플리케이션에서는 효과가 크지 않았습니다. 줄일 군더더기 자체가 적기 때문이죠. 오히려 규칙을 따지느라 시간이 더 걸리기도 했고요.

마지막으로 한 가지는 분명히 해 두고 싶습니다. 이 결과는 제가 몇 가지 작업만 돌려본 것이라 모든 경우를 대변하지는 못합니다. 그러니 경향으로만 참고하시고, 각자의 실제 워크플로에 직접 적용해 보면서 판단하시면 좋겠습니다. 출시 2주 만에 스타 5만 개가 붙은 데는 이유가 있겠지만, 그 효과가 내 작업에서도 그대로 나타날지는 직접 써봐야 알 수 있으니까요.