AI 에이전트의 PR이 비대해지기 전에 멈추기: Ponytail로 '쓰지 않는 판단'을 리뷰 기준으로 삼기

AI 코딩 에이전트 (AI Coding Agent)를 사용하면 구현 속도가 올라갑니다. 작은 수정이라도 후보 코드, 테스트, 설명, 설정까지 한꺼번에 나옵니다.

하지만 빠르게 작성할 수 있는 것과, 반년 후에도 유지보수하기 쉬운 것은 별개의 문제입니다.

폼에 날짜 입력을 추가하는 작업만으로 새로운 npm 패키지, 래퍼 컴포넌트 (Wrapper Component), CSS import, 두 개의 useEffect가 추가됩니다. 작동은 합니다. 친절해 보이기도 합니다. 하지만 실제로는 '날짜를 선택한다'는 요구사항에 대해, 팀은 새로운 의존성 (Dependency)과 유지보수 대상을 떠안게 됩니다.

Ponytail는 이러한 AI 생성 코드의 비대화를 막기 위한 기술입니다. 공식 README에서는 “lazy senior dev”의 판단을 AI 에이전트에 넣는 것으로 설명하고 있습니다. 여기서 말하는 lazy는 대충 생략하는 것이 아닙니다. 표준 라이브러리 (Standard Library), 브라우저 표준, 기존 의존성으로 충분하다면 새로운 코드를 작성하지 않는다는 의미입니다.

이 기사에서는 Ponytail를 '편리한 프롬프트'가 아니라, AI 시대의 리뷰 기준으로 읽습니다. 대상은 Claude Code, Codex, Cursor, OpenCode 등을 사용하기 시작한 개발자, 또는 AI 생성 코드를 팀에 도입하는 테크 리드 (Tech Lead)입니다.

AI는 '만들 수 있는 것'을 너무 많이 만든다

AI 에이전트는 요청에 대해 정중하게 응답하려고 합니다. 그 정중함이 다음과 같은 차이로 나타날 수 있습니다.

• 표준 라이브러리로 충분한 처리에 새로운 의존성을 추가함
• 브라우저나 DB가 가진 기능을 애플리케이션 측에서 재구현함
• 단 하나만 구현된 인터페이스나 팩토리 (Factory)를 만듦
• 측정 전에 캐시 (Cache), 재시도 (Retry), 추상화 레이어 (Abstraction Layer)를 추가함
• 아직 사용하지 않는 설정 항목을 '미래의 확장성'이라며 가져옴

사람이 직접 쓰던 시대라면 번거로워서 피했을 양의 코드를 AI는 주저 없이 생성합니다. 생성 비용이 낮아질수록 받는 쪽에서는 리뷰 대상이 늘어납니다. 리뷰에서 봐야 할 것이 늘어나면 유지보수의 책임도 늘어납니다.

Ponytail가 다루는 것은 바로 이 마찰입니다.

공식 예시에서는 '날짜 피커를 추가해줘'라는 태스크에 대해, Ponytail가 없다면 flatpickr를 도입하여 React 컴포넌트를 만드는 구현을 보여줍니다. 반면 Ponytail가 있다면 다음 한 줄에서 멈춥니다 (examples/date-picker.md).

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

이것은 '짧으니까 좋다'는 이야기가 아닙니다. 브라우저에 이미 있는 기능을 사용하면 의존성도 래퍼도 라이프사이클 관리 (Lifecycle Management)도 필요 없게 됩니다. Ponytail의 예시에서는 접근성 (Accessibility), 모바일 UI, 로컬라이즈 (Localize)를 브라우저 측에 맡길 수 있다는 점이 강조되어 있습니다. MDN의 <input type="date">에서는 값은 항상 yyyy-mm-dd로 정규화된다는 것, 표시는 브라우저의 로케일 (Locale)을 따른다는 것, min, max, required 등의 제약 조건과 클라이언트 측 검증을 사용할 수 있다는 점이 설명되어 있습니다. 다만, 클라이언트 측 검증은 완전한 보호가 아닙니다. 서버 측 검증은 별도로 필요합니다.

즉 Ponytail의 발상은 코드를 짧게 만드는 것이 아니라, 소유하는 것을 줄이는 것에 있습니다.

이 사고방식은 AI 이전부터 있었다

Ponytail는 새로운 도구이지만, 사상 그 자체는 새롭지 않습니다.

가까운 조상은 Extreme Programming의 YAGNI입니다. Martin Fowler는 YAGNI를

left-pad가 사라지면서 Node나 Babel을 포함한 많은 프로젝트의 빌드가 깨졌습니다 (Code pulled from NPM). left-pad 자체는 짧은 문자열 처리였지만, 그럼에도 불구하고 많은 프로젝트가 외부 패키지로 안고 있었습니다.

물론 모든 의존성 (Dependency)이 나쁜 것은 아닙니다. 암호화, 날짜 및 시간, 국제화 (i18n), 접근성 (Accessibility), 보안 관련 분야에서는 잘 관리된 라이브러리에 맡기는 것이 더 안전한 상황도 있습니다. 다만, 몇 줄이면 끝날 처리나 브라우저 표준으로 충분한 UI까지 외부화하면, 편리함보다 소유 비용 (Ownership cost)이 먼저 증가합니다.

Ponytail은 YAGNI, 표준 기능의 활용, 의존성을 늘리는 것에 대한 신중함을 AI 에이전트의 행동 규칙으로 다시 정리한 것입니다. AI가 코드를 작성하는 시대에, 예전부터 내려온 "만들지 않는 기술"이 다시 한번 필요해지고 있습니다. 그렇게 보면 이 기술의 위치를 이해하기 쉬워집니다.

이것들은 일직선상의 인과관계가 아닙니다. Ponytail은 YAGNI, 심플한 설계, 표준 기능의 활용, 의존성을 소유하는 리스크, AI에 의한 생성 비용 저하라는 밀접한 문제 의식을 리뷰에서 사용할 수 있는 형태로 묶어낸 것입니다.

그림 1: Ponytail은 일직선상의 인과가 아니라, YAGNI, 표준 기능, 의존 관계, AI 생성 비용 저하라는 밀접한 문제 의식을 묶은 리뷰 규율로 읽을 수 있습니다.

Ponytail의 핵심은 "최소 구현"보다 앞단에 있다

Ponytail의 핵심은 skills/ponytail/SKILL.md에 적힌 6단계의 래더 (Ladder)입니다. 에이전트는 코드를 작성하기 전에 위에서부터 순서대로 확인하며, 성립되는 첫 번째 단계에서 멈춥니다.

애초에 필요한가

투기적인 요구라면 만들지 않는다. -
표준 라이브러리로 충분한가

자체 구현보다 먼저 언어나 런타임 (Runtime)의 기능을 확인한다. -
네이티브 기능으로 충분한가

브라우저, CSS, DB 제약, OS 기능을 사용할 수 있다면 사용한다. -
기존 의존성으로 충분한가

새로운 의존성을 추가하기 전에 이미 들어있는 도구를 사용한다. -
한 줄로 끝나는가

큰 구조로 만들기 전에 국소적인 구현으로 끝낸다. 그래도 안 된다면, 동작하는 최소 구현을 작성한다

텍스트로만 설명하면 "최소 구현 이야기"로 보이기 쉬우므로, 래더를 그대로 도식화하겠습니다. Ponytail은 아래로 내려갈수록 신중해집니다. 위에서 멈출 수 있다면 거기서 멈춥니다.

그림 2: Ponytail에서는 최소 구현을 작성하기 전에, 만들지 않기, 표준 기능으로 해결하기, 기존 의존성에 맞추기라는 단계를 위에서부터 확인합니다.

여기서 중요한 것은 "최소 구현"조차 마지막 단계라는 점입니다. 많은 개발 현장에서는 최소 구현을 좋은 타협점으로 취급합니다. Ponytail은 그보다 한 발 앞서 멈춥니다.

그 기능은 정말로 존재해야 하는가.

기존 기능으로 부족한 것인가.

새로운 소유물을 늘릴 만큼의 이유가 있는가.

이 세 가지를 코드 생성 전에 묻게 하는 것이 Ponytail입니다.

단, "짧음"을 "안전성"보다 위에 두어서는 안 된다

Ponytail은 무엇이든 깎아내기 위한 도구가 아닙니다. 스킬 정의에서는 다음 영역을 깎아내지 말라고 명시되어 있습니다.

• 신뢰 경계 (Trust boundary)에 있는 입력 검증
• 데이터 손실을 방지하는 에러 핸들링 (Error handling)
• 보안 대책
• 접근성 (Accessibility)의 기본
• 사용자가 명시적으로 요구한 것

이 부분을 간과하면 Ponytail은 위험한 지름길 (Shortcut)이 됩니다.

인증이나 결제 코드에서 "짧으니까"라는 이유로 검증 처리를 생략하는 것은 Ponytail이 아니라 태만입니다. 사용자 입력을 받는 API에서 유효성 검사 (Validation)를 깎는 것도 마찬가지입니다. 짧은 코드가 반드시 안전한 것은 아닙니다.

Ponytail의 가치는 안전성이나 책임과 관련 없는 불필요한 소유물을 깎아내는 것에 있습니다. 보안, 데이터 보호, 접근성까지 깎아낸다면 그것은 별개의 문제입니다.

실측값은 매력적이다. 하지만 자신들의 코드로 측정해야 한다

Ponytail의 README에는 5가지 일상적인 코딩 태스크, 3가지 모델, 3가지 조건의 비교가 실려 있습니다. no skill baseline 대비, 8094% 적은 코드, 4777% 낮은 비용, 3~6배 빠른 속도였다고 합니다 (README의 Numbers 섹션). README에는 퀵 실행을 위한 명령어도 안내되어 있습니다.

npx promptfoo eval -c benchmarks/promptfooconfig.yaml

npx promptfoo@latest eval -c promptfooconfig.yaml --repeat 10
npx promptfoo@latest view

한편, 벤치마크 (benchmark) 결과를 읽을 때는 주의가 필요합니다. 예를 들어 benchmarks/results/2026-06-12-caveman-vs-ponytail.md를 보면,

Ponytail v3가 caveman보다 코드 라인 수가 적고, 총 토큰 (total tokens) 및 실행 시간 (execution time) 측면에서도 좋은 결과를 보였다고 기록되어 있습니다. 다만 동일한 파일에는 n=1 per cell이며, 소요 시간 (duration)에 노이즈가 있다는 주의 사항도 명시되어 있습니다.

팀에 도입한다면, 우선 작은 규모로 측정하는 것이 더 안전합니다.

자사 팀에서 직접 확인하려면, 몇 가지 작은 태스크를 선정하여 Ponytail이 없을 때와 있을 때의 PR 차이점 (diff)을 나열해 봅니다. 확인해야 할 항목은 추가된 LOC (Lines of Code), 신규 의존성 (dependency) 수, 리뷰 코멘트 수, 수정 왕복 횟수, 테스트 추가 여부, 그리고 추후 발생한 수정 사항의 유무입니다.

이러한 작은 평가 과정을 도입하면, Ponytail은 단순히 "분위기 좋은 미니멀리즘"이 아니라, 리뷰 부하와 유지보수 비용을 낮추기 위한 실험이 됩니다.

도입 시 변화하는 것은 코드 생성보다 리뷰입니다

Ponytail은 여러 에이전트 (agent)에서 읽어들일 수 있는 형태로 배포됩니다. 공식 문서에는 Claude Code, Codex, OpenCode, Cursor, Windsurf, Cline, GitHub Copilot, Kiro, 그리고 범용 AGENTS.md 등으로 연결되는 어댑터 (adapter)가 정리되어 있습니다 (docs/agent-portability.md).

설계 측면에서 흥미로운 점은, 핵심 동작을 skills/에 두고 각 호스트 (host)용 파일을 얇은 어댑터로 구성했다는 점입니다. AI 도구마다 유사한 규칙을 흩뿌리는 대신, 가능한 한 하나의 행동 정의를 참조하게 만듭니다. 이러한 구조는 팀의 개발 규약 (development convention)에도 응용할 수 있습니다.

Ponytail을 단순히 "짧게 쓰는 프롬프트 (prompt)"로만 사용한다면, 그 효과는 개인의 작업 효율에 국한됩니다. 실무에서 진가를 발휘하는 것은 PR 리뷰의 기준으로 사용할 때입니다.

리뷰 시에는 다음과 같은 질문을 먼저 던질 수 있습니다.

• 이 기능은 현재의 요구사항에 정말로 필요한가
• 표준 라이브러리 (standard library)나 브라우저 표준 (browser standard)으로 대체할 수 없는가
• 새로운 의존성을 추가해야 하는 이유를 짧게 설명할 수 있는가
• 단 하나만 구현된 추상화 (abstraction)를 만들고 있지는 않은가
• ponytail: 코멘트를 통해 간략화의 상한선과 업그레이드 조건이 설명되어 있는가

Ponytail에는 /ponytail-review라는 리뷰용 스킬 (skill)도 있습니다. skills/ponytail-review/SKILL.md에서는 과잉 구현에 대해 delete, stdlib, native, yagni, shrink와 같은 태그로 지적하는 형식을 정의하고 있습니다.

정확성을 리뷰하는 것과는 별개로, 소유하는 코드를 줄이는 리뷰를 분리합니다. 이러한 발상은 AI 생성 코드가 늘어날수록 더욱 중요해집니다.

그림 3: 일반적인 리뷰는 정확성을 확인합니다. Ponytail 리뷰는 그 차이점을 팀이 소유해야 하는지를 별도의 축에서 확인합니다.

팀에서 시작한다면, 3가지 규칙이면 충분합니다

Ponytail을 도입할 때, 갑자기 모든 태스크를 /ponytail ultra로 만들 필요는 없습니다. 처음에는 다음 세 가지만으로도 충분합니다.

1. 신규 의존성은 대체안을 작성한 후 추가한다

의존성 추가는 코드 라인 수보다 훨씬 길게 남습니다. 취약점 대응, 라이선스 확인, 버전 업데이트, 번들 크기 (bundle size), API 변경 추종 등의 작업이 수반됩니다.

PR 본문에 다음 한 줄을 필수적으로 작성하게 합니다.

stdlib / native / 기존 의존성으로 대체할 수 없는 이유: ...

이 문장을 작성할 수 없는 의존성이라면, 아직 추가할 단계가 아닙니다.

2. 간략화에는 "상한선"과 "다음 단계"를 남긴다

짧은 구현은 나중에 읽는 사람에게 "의도적으로 줄인 것인지, 단순히 놓친 것인지" 전달하기 어려울 때가 있습니다. Ponytail은 의도적인 간략화에 ponytail: 코멘트를 남기는 방침을 취합니다.

# ponytail: 1k 행 미만에서는 O(n) 스캔으로 충분함; 이 엔드포인트가 느려지면 인덱스를 추가할 것.
match = next((row for row in rows if row.id == target_id), None)

이것은 변명이 아닙니다. 나중에 수정해야 할 조건을 미리 고정해 두는, 작은 설계 메모입니다.

3. 깎아내서는 안 되는 영역을 명문화하기

코드를 짧게 만드는 규율은 편리하지만, 적용 범위를 잘못 설정하면 사고로 이어집니다. 팀에서는 Ponytail의 예외 사항을 더욱 구체화해 두는 것이 안전합니다.

• 인증 (Authentication), 인가 (Authorization), 결제, 개인정보 처리에서는 간결함보다 명시성을 우선한다
• 사용자 입력을 받는 경계에서는 유효성 검사 (Validation)를 생략하지 않는다
• 감사 로그 (Audit log), 복구 (Recovery), 권한 체크는 YAGNI (You Ain't Gonna Need It)로 취급하지 않는다
• 접근성 (Accessibility) 속성은 외관상의 편의를 위해 깎아내지 않는다

이러한 기준선이 있다면, Ponytail은 '대충 생략하는 도구'가 아니라, 불필요한 것만을 깎아내기 위한 규율이 됩니다.

Ponytail이 특히 효과적인 팀

개인 개발에서도 Ponytail은 즉시 도움이 됩니다. AI가 과한 구현을 내놓았을 때, 표준 기능이나 한 줄 구현으로 되돌리는 힘이 있기 때문입니다.

하지만 더욱 효과적인 것은 팀 개발입니다. AI 에이전트 도입 후의 마찰은 생성 그 자체가 아니라, 생성물을 받아들이는 측에서 발생합니다.

리뷰가 무거워진다. 의존성 (Dependency)이 늘어난다. 의도 없는 추상화 (Abstraction)가 늘어난다. 반년 뒤에, 아무도 필요성을 설명할 수 없는 코드가 남는다.

Ponytail은 이러한 마찰에 대해 "짧게 써라"라고 말하는 것이 아닙니다. 쓰기 전에 멈춰라라고 말하고 있습니다.

도입 가치가 높은 팀은 다음과 같습니다.

• AI 에이전트 도입 후, PR (Pull Request) 차분이 커졌다
• 작은 변경에 의존성 추가나 추상화가 섞여 들어온다
• 리뷰에서 "이것은 지금 필요 없다"라는 말을 매번 설명하고 있다
• 표준 라이브러리나 플랫폼 기능의 활용이 철저하게 이루어지지 않고 있다
• 생성된 코드의 유지보수 책임을 팀 규약으로 명문화하고 싶다

반대로, 이미 강력한 설계 리뷰 문화가 있고 의존성 추가나 추상화에 ADR (Architecture Decision Record)이 있는 팀에서는 Ponytail의 효과가 미미할 수도 있습니다. 그런 경우라도, /ponytail-review와 같은 과잉 구현 리뷰만을 도입할 가치는 있습니다.

리뷰에서 보는 관점을 바꾸기

Ponytail의 사고방식은 특정 에이전트에 국한되지 않습니다. PR을 볼 때 갑자기 구현의 세부 사항으로 들어가지 마세요. 먼저 "이 차분이 팀이 새로 소유해야 할 것인가"를 봅니다. 그 순서만 바꾸어도 리뷰의 대화는 상당히 달라집니다.

새로운 의존성이 들어왔다면, 표준 라이브러리, 브라우저 표준, 기존 의존성으로 해결할 수 없었던 이유를 읽습니다. 추상화가 늘어났다면, 이용 사례가 단 하나뿐이지 않은지 확인합니다. 짧은 구현이 나왔다면, 그것이 태만함이 아니라 의도적인 간략화인지, 상한선과 다음 단계가 코멘트로 남아있는지 확인합니다.

반대로, 깎아내서는 안 되는 곳도 미리 정해둡니다. 인증, 인가, 결제, 개인정보, 감사 로그, 접근성, 사용자 입력 검증. 이 영역에서 "짧으니까 충분하다"라고 말하기 시작하면, Ponytail이 아니라 사고를 준비하는 것이 됩니다.

AI 코딩 시대의 유지보수성은 더 많이 생성하는 능력이 아니라, 받아들이는 차분을 작게 유지하는 능력에 좌우됩니다.

Ponytail은 코드를 작성할 수 있는 AI에게 "아직 쓰지 않아도 된다"라고 말하게 하는 시도입니다. 여기에 이 도구의 실무적인 가치가 있습니다.

Discussion