포니테일(Ponytail): AI 에이전트의 “과도한 설계 병”을 치료해 봅니다—실측 결과 코드 54% 감소

저장소: https://github.com/DietrichGebert/ponytail

난이도 낮음, 10분이면 익혀서 1시간 안에 첫 벤치마크를 끝냅니다. AI가 코드를 “멈추지 못하는(스로틀 브레이크가 없는)” 습관을 고쳐보세요.

서문

혹시 이런 경험이 있나요? Claude Code로 날짜 선택기를 만들어 달라 했더니, 정중하게 flatpickr를 붙이고… 래퍼 컴포넌트를 만들고… CSS까지 추가한 다음에 타임존 처리를 논의하다가… 결국 287줄을 당신에게 넘겨줍니다.

당신이 하고 싶었던 말은 “날짜를 고를 수 있는 입력창이 필요해”였는데, 그들이 내놓은 건 “날짜 선택 프레임워크”였습니다.

이것이 바로 AI 에이전트의 “과도한 설계 병”입니다. 모델은 학습 중 “전문적으로 보이는” 방식으로 훈련되기 때문에, 자동으로 추상화 계층을 더하고, 설정 항목을 늘리고, 오류 처리를 넣고, 테스트 커버리지를 추가합니다. 그런데 당신이 원하는 것은 사실 <input type="date"> 한 줄일 가능성이 큽니다.

Ponytail은 바로 이 병을 치료하려고 만들었습니다. Dietrich Gebert가 오픈소스로 공개했으며 핵심 아이디어는 한 문장입니다: 「가장 좋은 코드는, 결코 쓰지 않은 코드다」.

Ponytail은 모델도 아니고 IDE 플러그인도 아닙니다. “게으른 고급 엔지니어” 스타일의 규칙 세트입니다. AI에게 6단짜리 사다리를 씌워요:

1. 이걸 정말로 작성해야 하나요?          → 필요 없음: 스킵 (YAGNI)
2. 표준 라이브러리로 할 수 있나요?       → 쓰세요
3. 플랫폼 네이티브 기능으로 가능한가요?  → 쓰세요
4. 이미 깔려 있는 의존성으로 가능한가요? → 쓰세요
5. 한 줄 코드로 가능한가요?             → 한 줄로 작성
6. 정말 안 되면: 동작하는 최소 코드만 작성

tiangolo의 full-stack-fastapi-template 실제 저장소에서, 12개의 feature ticket, n=4, Haiku 4.5 대조 실험으로 Ponytail은 이 성적표를 받았습니다:

Ponytail은 모든 지표가 전부 내려간 유일한 솔루션이면서, 동시에 코드를 줄이되 안전성을 깎지 않은 유일한 솔루션입니다. 컬러 선택기는 287줄에서 23줄로 줄고, 날짜 선택기는 404줄에서 23줄로 줄었습니다. 이유는 간단합니다. 브라우저에 내장된 <input type="color">와 <input type="date">를 바로 썼기 때문이에요.

또한 Ponytail은 14개의 AI 코딩 도구와 호환됩니다: Claude Code, Codex, Cursor, Windsurf, Cline, Copilot CLI, Aider, Kiro, Zed, CodeWhale, OpenCode, Pi, Gemini CLI, OpenClaw. 오늘은 이 규칙 세트를 Claude Code에 그대로 넣고, 30초 만에 당신의 에이전트 “과도한 설계 병”을 치료해 봅시다.

목표 독자

• 일상적으로 AI 에이전트로 코드를 작성하는 1~5년차 개발자
• “AI가 코드를 너무 길게 쓰고, 쓸모없는 의존성을 한 무더기 붙인다”는 감각형(체감형) 분
• 팀에 코딩 스타일을 통일하고 싶지만, 딱딱한 ESLint 규칙에 얽매이고 싶지 않은 분
• AI 프로그래밍 비용/토큰 청구서가 아픈 작은 사장님 / 테크 리드

핵심 의존성 및 환경

• Node.js 18+ (필수. Ponytail의 lifecycle hook은 Node로 실행됩니다. nvm 사용자는 비대화형 shell의 PATH에 설치가 잡히도록 주의하세요.)
• 지원되는 AI 에이전트(데모: Claude Code)
• LLM API Key(데모용 Defapi의 Claude Haiku 4.5, 반값)
• 선택: Python 3.10+(벤치마크 실행 시 pandas 사용)
• 선택: Git(저장소 클론)

전체 프로젝트 구조

ponytail/
├── AGENTS.md                  # 핵심 규칙(모든 에이전트가 함께 읽는 "게으른 철학")
├── README.md / README.es.md   # 영/한/스페인어 3개 언어 README
├── package.json               # pi-agent 패키지 정의
├── commands/                  # 6개의 slash command
│   ├── ponytail.toml          # /ponytail [lite|full|ultra|off]
│   ├── ponytail-review.toml   # /ponytail-review（현재 diff를 깎음）
│   ├── ponytail-audit.toml    # /ponytail-audit（전체 저장소 스캔）
│   ├── ponytail-debt.toml     # /ponytail-debt（포니테일 회수: 주석）
│   ├── ponytail-gain.toml     # /ponytail-gain（벤치 성적표 보기）
│   └── ponytail-help.toml     # /ponytail-help
├── skills/                    # 6개의 skill 이미지
│   ├── ponytail/              # 메인 규칙
│   ├── ponytail-review/ ...   # 나머지 5개
├── hooks/                     # Claude / Codex lifecycle hook
│   ├── ponytail-config.js     # 모드 파싱（env + config.json）
│   └── ponytail-instructions.js
├── ponytail-mcp/              # MCP 서버 적응（MCP-only 호스트용）
│   ├── index.js
│   ├── instructions.js
│   └── test/
├── examples/                # 12개의 실제 "과도한 설계 vs 한 줄" 비교
│   ├── date-picker.md / color-picker.md（웹 내장 요소）
│   ├── deep-clone.md（structuredClone）
│   ├── debounce.md
│   ├── email-validation.md（75줄 → 3줄）
│   └── ... 총 12개
├── benchmarks/              # promptfoo + agentic 벤치
│   ├── promptfooconfig.yaml   # 단일 라운드 벤치
│   ├── benchmark-local.py     # agentic 실제 저장소 벤치
│   ├── agentic/               # 12개 ticket 스크립트
│   └── results/2026-06-18-agentic.md  # 전체 데이터
├── docs/
│   ├── agent-portability.md   # 어떤 에이전트에 어떤 파일을 달지
│   └── platform-native.md
├── .openclaw/                 # OpenClaw 적응 skill（자동 생성）
├── .cursor/ .windsurf/        # Cursor / Windsurf 규칙 파일
├── .clinerules/               # Cline 규칙
├── .kiro/steering/            # Kiro 규칙
└── tests/                     # 규칙 일관성 테스트

---

손에 잡히는 튜토리얼

1단계: Ponytail을 Claude Code에 설치

Claude Code에서 Ponytail은 플러그인 마켓플레이스 하나를 붙이는 것과 같습니다. 30초면 끝.

# Ponytail 저장소를 당신의 plugin marketplace 목록에 추가
/plugin marketplace add DietrichGebert/ponytail

# 메인 skill 설치（한 세션에 한 번）
/plugin install ponytail@ponytail

설치가 끝나면 새 세션을 열고, startup 문구에 현재 모드가 표시되는지 확인하세요(기본값 full). 이런 식으로 나옵니다:

Ponytail v0.1.0  [full]  Lazy senior dev mode active
1. Need to build?  2. Stdlib?  3. Platform?  4. Installed dep?
5. One line?       6. Minimum that works.

강도를 바꾸고 싶으면 이렇게 입력하세요:

/ponytail lite     # 가볍게 두드리는 모드(1~2단은 보호)
/ponytail full     # 기본
/ponytail ultra    # 강 삭제 모드(추상화 한 겹도 안 남김)
/ponytail off      # 끄기
/ponytail          # 파라미터 없이 = 현재 단계 표시

또는 영구 설정도 가능합니다:

# 기본 모드를 ultra로 영구 설정
export PONYTAIL_DEFAULT_MODE=ultra

혹은 config 파일을 작성:

// ~/.config/ponytail/config.json
// Windows: %APPDATA%\ponytail\config.json
{ "defaultMode": "ultra" }

2단계: 반례 비교를 실행

바로 효과를 보겠습니다. 완전히 똑같은 프롬프트 2개를 준비하세요:

Prompt A(포니테일 끄기): 먼저 /ponytail off를 하고, 다음을 물어보세요.

Add a color picker to the settings page

그러면 대략 287줄짜리 답을 받게 됩니다. react-color를 붙이거나, 직접 5개 파일짜리 컴포넌트를 만들고, prop 검증을 더하고, onChange에 스로틀을 넣고, 접근성용 label을 추가하고, CSS 변수까지 붙이죠.

Prompt B(포니테일 켜기): 먼저 /ponytail full을 하고, 똑같은 말을 다시 해보세요.

답은 이렇게 나옵니다:

// ponytail: browser has one
<input type="color" />

한 줄. 끝.

Ponytail의 AGENTS.md에는 이 핵심 규칙을 그대로 써뒀습니다(원문):

Before writing any code, stop at the first rung that holds:
1. Does this need to be built at all? (YAGNI)
2. Does the standard library already do this? Use it.
3. Does a native platform feature cover it? Use it.
4. Does an already-installed dependency solve it? Use it.
5. Can this be one line? Make it one line.
6. Only then: write the minimum code that works.

마지막 줄의 뉘앙스도 중요합니다: 「Only then」— 코드를 쓰지 말라는 게 아니라, 먼저 앞의 5단을 전부 밟고 나서 쓰라는 뜻입니다.

3단계: Defapi로 끝까지 돌려 토큰 비용 절반 절약

Ponytail은 코드 양을 줄여주지만, AI 에이전트 자체를 돌리려면 Claude/GPT에 토큰을 태워야 합니다. Defapi는 공식 반값 Claude / GPT / Gemini를 제공하며 인터페이스가 완전히 호환됩니다.

Defapi로 벤치마크를 돌려보겠습니다:

3.1단계: Defapi Key 받기

defapi.org에 등록한 뒤 dk-xxx로 시작하는 키를 발급받아 Ponytail의 .env에 적습니다.

# ponytail 저장소 루트에서
cat > .env <<'EOF'
ANTHROPIC_API_KEY=dk-당신의defapi-key
ANTHROPIC_BASE_URL=https://api.defapi.org
EOF

3.2단계: curl로 바로 동작 확인

curl -s https://api.defapi.org/api/v1/messages \
  -H "Authorization: Bearer dk-당신의defapi-key" \
  -H "content-type: application/json" \
  -d '{
    "model": "anthropic/claude-haiku-4.5",
    "max_tokens": 256,
    "messages": [
      {"role": "user", "content": "포니테일이라는 단어를 이모지로 설명해줘"}
    ]
  }'

응답은 대략 이렇게 옵니다:

{
  "id": "msg_01H...",
  "role": "assistant",
  "content": [{"type": "text", "text": "🦄 (애초에 나올 일이 아닌 것)"}],
  "usage": {"input_tokens": 22, "output_tokens": 12}
}

3.3단계: promptfoo가 Defapi를 쓰게 만들기

Ponytail에는 promptfoo 벤치가 기본 포함되어 있습니다. benchmarks/promptfooconfig.yaml을 편집하세요:

providers:
  - id: anthropic:messages:anthropic/claude-haiku-4.5
    config:
      baseURL: https://api.defapi.org
      apiKey: ${ANTHROPIC_API_KEY}

실행:

npx promptfoo@latest eval -c benchmarks/promptfooconfig.yaml

절약되는 돈(Ponytail 벤치 기준 12개 ticket × n=4 = 총 48회 실행 규모로 추정):

Ponytail은 20% 비용을 깎고, Defapi는 50% 더 깎습니다. 둘을 같이 켜면 실제 청구서가 4분의 1(4티어) 가격이 됩니다.

4단계: /ponytail-review로 현재 diff를 깎기

Ponytail이 “쓰기” 단계에서만 지켜주는 것으로는 부족합니다. 이미 당신에게 있는 “과도한 설계” 코드의 누적분이 있으니까요. 그때 review 커맨드를 사용합니다:

# 변경이 있는 저장소에서
/ponytail-review

이것은 현재 git diff만 심사하고, 출력 포맷은 고정입니다:

L12: 쓰지 않는 `cache` 파라미터 삭제; 호출자가 아무도 넘기지 않음
L34: stdlib Array.prototype.sort는 ES2019 이후 안정 정렬; `lodash.orderby` 삭제
L88: 네이티브 URLSearchParams가 커버함; 커스텀 `parseQuery` 제거
L102: yagni `BaseRepository`는 구현이 하나뿐임; 인라인
L150: 루프를 arr.filter(x => x.active).map(x => x.id)로 줄이기
---
순 가시 제거 가능: 47줄, 1개 의존성

태그 체계:

• delete — 죽은 코드 / 투기성 기능
• stdlib — 표준 라이브러리를 재발명
• native — 이미 의존성이 하는 일 / 플랫폼 네이티브가 가능한 일
• yagni — 구현이 하나인 추상화 계층
• shrink — 같은 로직인데 줄 수만 더 적음

마지막 줄에는 “순수로 제거 가능한 줄 수”가 나옵니다. 이것이 곧 tech debt의 정량화 지표입니다.

만약 출력이 Lean already. Ship.라면, 코드는 이미 충분히 날렵하다는 뜻이니 안심하고 merge하면 됩니다.

5단계: /ponytail-audit로 전체 저장소 스캔

review는 diff를 보고, audit은 전체 트리를 봅니다.

/ponytail-audit

출력은 비슷하지만 “가장 많이 깎을 수 있는 것” 순서로 정렬됩니다:

delete src/utils/cache.ts (412 lines) — 1곳에서만 사용; 인라인
stdlib src/utils/deep-clone.ts — structuredClone 사용
native src/components/DatePicker/ (287 lines) — <input type="date">
yagni src/repositories/BaseRepository.ts (180 lines) — 구현 1개; 인라인
shrink src/api/users.ts:42-78 — 동일 로직, 60 → 18줄
---
순 가시 제거 가능: 1,247줄, 4개 의존성

실전 팁: 먼저 review, 그다음 audit. review는 diff를 수정하고 merge하면, audit이 다음 청소 우선순위를 정리해줍니다.

6단계: 다른 에이전트에서도 활성화

Ponytail의 핵심 장점은 “한 번의 규칙이 어디서나 적용된다”는 점입니다. 각 주류 AI 코딩 도구마다 적응 파일을 준비해뒀어요:

Codex（CLI 모드）

codex plugin marketplace add DietrichGebert/ponytail
codex
# /plugins → Ponytail 선택 → 설치
# /hooks → 두 개의 lifecycle hook을 신뢰 → 새 스레드

Cursor

.cursor/rules/ponytail.mdc를 프로젝트에 복사합니다:

cp .cursor/rules/ponytail.mdc ~/your-project/.cursor/rules/

또는 전역으로:

cp .cursor/rules/ponytail.mdc ~/.cursor/rules/

Windsurf

cp .windsurf/rules/ponytail.md ~/.codeium/windsurf/memories/

GitHub Copilot CLI

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

OpenClaw（이미 쓰고 있다면）

# 가장 우아한 한 줄
clawhub install ponytail

또는 수동 복사:

cp -r .openclaw/skills/ponytail ~/.openclaw/skills/

Gemini CLI

gemini extensions install https://github.com/DietrichGebert/ponytail

Pi / Aider / Kiro / Zed / CodeWhale

이 에이전트들은 바로 AGENTS.md를 읽습니다:

# 프로젝트 레벨
cp AGENTS.md ~/your-project/AGENTS.md

# 전역( pi / Aider / CodeWhale 모두 인식 )
cp AGENTS.md ~/.pi/AGENTS.md

전체 대응표（프로젝트 docs/agent-portability.md에서 발췌）:

7단계: 당신만의 벤치마크를 실행

Ponytail의 실 데이터는 “감으로” 만든 게 아니라 benchmarks/benchmark-local.py를 돌려 나온 결과입니다. 당신의 진짜 작업 5개를 골라 똑같이 재현해도 됩니다:

7.1단계: prompts 준비

benchmarks/prompts.json을 편집하거나, 이미 준비된 5개를 사용하세요:

[
  { "id": "date-picker", "task": "설정 페이지에 날짜 선택기를 추가하세요" },
  { "id": "color-picker", "task": "설정 페이지에 색상 선택기를 추가하세요" },
  { "id": "email-validate", "task": "이메일 주소를 검증하는 파이썬 함수를 작성하세요" },
  { "id": "deep-clone", "task": "이 객체를 deep clone 하세요: {sample}" },
  { "id": "debounce", "task": "자바스크립트로 debounce 함수를 작성하세요" }
]

7.2단계: 3개의 arm을 대조 실행

# baseline: 아무것도 추가하지 않음
npx promptfoo@latest eval -c benchmarks/promptfooconfig.yaml

# ponytail: skill이 붙은 plugin arm
PONYTAIL_DEFAULT_MODE=full npx promptfoo@latest eval -c benchmarks/promptfooconfig.yaml

7.3단계: 결과 보기

benchmarks/output.json에 결과가 나옵니다. 각 prompt가 각 arm에서 어떻게 나왔는지 포함합니다:

• loc — 코드 줄 수
• tokens — 총 토큰
• cost — 달러
• time — 엔드투엔드 시간
• passed_safety — 안전 테스트 통과 여부(입력 검증, 오류 처리, a11y)

대개 ponytail arm은 baseline 대비 LOC가 50~80% 더 적습니다.

8단계: ponytail-mcp 실행(고급)

당신의 AI 호스트가 MCP만 지원한다면(어떤 데스크톱 앱들처럼), Ponytail에도 MCP 서버 적응이 있습니다:

cd ponytail-mcp
npm install
node index.js    # stdio MCP 서버 실행

호스트의 MCP 설정에 다음을 추가:

{
  "mcpServers": {
    "ponytail": {
      "command": "node",
      "args": ["ponytail-mcp/index.js"]
    }
  }
}

그러면 다음을 노출합니다:

• Prompt ponytail: 규칙 텍스트를 반환하며, 선택적으로 mode 파라미터(lite / full / ultra)를 받음
• Tool ponytail_instructions: 위와 동일하지만 structuredContent를 포함해, code-execution 스타일의 호스트에 적합

---

자주 묻는 질문 및 문제 해결

Q1: 설치했는데 반응이 없고 startup 문구가 안 뜹니다?

99%는 Node가 비대화형 shell의 PATH에 없기 때문입니다. 확인해보세요:

# 새 셸에서 실행(비대화형을 시뮬레이션)
bash -lc 'node -v'      # bash
zsh -lc 'node -v'       # zsh

command not found가 나오면, nvm source를 ~/.bashrc / ~/.zshrc에 추가하거나 system Node를 직접 설치하세요:

# macOS
brew install node@20

# Windows
winget install OpenJS.NodeJS.LTS

Q2: “난 저 120줄짜리 cache 클래스를 써야 해” 강한 요구일 때는?

두 가지 해결책:

# 임시로 끄기
/ponytail off

# 또는 부분 허용: 프롬프트에서 직접 말하기
"120-line cache class를 만들어. 이 작업에서는 ponytail을 무시해"

Ponytail은 규칙 세트이지 수갑이 아닙니다. 모델이 명시적인 override를 받으면 듣습니다.

Q3: Ponytail이 ESLint / Prettier와 충돌하나요?

충돌하지 않고, 역할이 다릅니다:

• Ponytail: "써야 하는지 말아야 하는지"—이 추상화가 필요한지, 이 의존성이 이미 있는지, 이 래퍼를 만들어야 하는지 결정
• ESLint: "제대로 썼는지"—네이밍, 스타일, 안 쓰는 변수
• Prettier: "형식이 보기 좋은지"—들여쓰기, 세미콜론, 줄바꿈

세 가지를 함께 켜는 게 가장 좋습니다. Ponytail이 가장 상류에서 코드의 ‘길이/구조’를 정하고, ESLint / Prettier가 하류에서 디테일을 보장해요.

Q4: 팀은 규칙을 어떻게 통일하나요?

AGENTS.md는 저장소 레벨 파일입니다. git에 커밋만 하면 돼요:

# 당신 팀 저장소의 루트에서
curl -o AGENTS.md https://raw.githubusercontent.com/DietrichGebert/ponytail/main/AGENTS.md
git add AGENTS.md
git commit -m "chore: adopt ponytail team-wide coding rules"

AGENTS.md를 읽는 에이전트들(CodeWhale, Aider, Zed, Pi, Kiro, Codex extension)은 자동으로 따릅니다.

Q5: Ponytail이 안전 테스트를 저하시킬까요?

아니요. 이건 Ponytail 벤치마크에서 가장 중요한 지표입니다. 표의 baseline / caveman / Ponytail은 모두 100% 안전 통과, 오직 벌거벗은 "YAGNI + 한 줄" 프롬프트만 95%로 떨어졌습니다.

Ponytail의 AGENTS.md에는 전용 문장이 있습니다:

Not lazy about: input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs.

번역(의미): 게으르냐 마냐는 상황에 따라 달라집니다. 비즈니스 로직과 UI 포장은 아끼는 게 좋을 수 있어요. 하지만 입력 검증, 오류 백업(대체/복구), 보안, a11y는 절대 생략하면 안 됩니다.

Q6: CI에서 어떻게 돌리나요?

/ponytail-review의 로직을 별도 스크립트로 분리하세요(Ponytail 저장소의 benchmarks/correctness.test.js가 참고 구현을 제공합니다). 그런 다음:

# .github/workflows/ponytail.yml
name: ponytail
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: node scripts/ponytail-review.js origin/main
        env:
          ANTHROPIC_API_KEY: ${{ secrets.DEFAPI_KEY }}
          ANTHROPIC_BASE_URL: https://api.defapi.org

PR에서 실패하면, 현재 diff가 Ponytail 입장에서 “아직 더 깎을 수 있다”는 뜻입니다.

Q7: MCP 모드 vs always-on 모드—뭘 고르면 좋을까요?

당신의 호스트를 기준으로 선택하세요:

---

확장 읽을거리 / 고급 방향

Ponytail 철학의 뿌리

• Rich Hickey의 “Simple Made Easy” 발표(클로저의 아버지가 말하는 “쉬움”과 “단순함”의 차이)
• Sandi Metz의 “The Magic Tricks of Testing”(테스트 커버리지를 최소화하는 원칙)
• Ted Neward의 “Thirty Years of 'WTF'”(기업 코드가 비대해지는 걸 풍자)
• 6단 사다리의 다른 표현: Coad의 “Just Enough Architecture”

내가 직접 ponytail 스타일 주석 달기

ponytail: 주석은 “미래의, 이 코드를 읽게 될 개발자”에게 남기는 쪽지입니다. 약속된 포맷:

// ponytail: <이유>, <알려진 제한 / 업그레이드 경로>

예시:

# ponytail: stdlib re 모듈로 충분해서 email-validator를 설치할 필요 없음
# 알려진 제한: RFC 5322의 모든 엣지 케이스를 검증하진 않음; [email protected] 같은 edge case를 지원해야 한다면 email-validator로 교체
import re
def is_valid_email(email: str) -> bool:
    return bool(re.match(r'^[^@]+@[^@]+\.[^@]+$', email))

/ponytail-debt 커맨드는 모든 ponytail: 주석을 훑어서 tech debt ledger 한 장을 생성해 줍니다. “later”는 “never”가 되지 않게요.

팀 코드 리뷰 프로세스에 통합하기

/ponytail-review를 lint처럼 돌리고, PR 템플릿에 한 줄 추가:

## Ponytail review
- [ ] 이 diff에 대해 `/ponytail-review`를 실행함
- [ ] 순 제거 가능 줄 수: ___
- [ ] 0이 아니라면 정당화: ___

전체 벤치마크 데이터

benchmarks/results/2026-06-18-agentic.md는 12개 ticket × 3개 arm × 4회 런의 완전한 방법론 + 한계 설명입니다. 읽어볼 만하고, 특히 “fair agentic baseline” 파트는 더더욱 그렇습니다—이전의 80~94% “단일 라운드 신화”는 conversational baseline을 인위적으로 부풀린 결과였고, **54%**만이 정직한 숫자입니다.

Ponytail의 경계에 대해

Ponytail이 코드를 깎는 전제는 “코드가 올바르다”입니다. Ponytail은 검증하지 않습니다:

• 비즈니스 로직이 맞는지(이건 당신이 테스트를 써야 함)
• 성능이 충분한지(O(n²) 같은 건 ponytail 주석에서 표시하지만 자동으로 고치진 않음)
• 엣지 케이스 커버가 되는지(lazy 주석은 목록만 남기고 테스트를 대신 추가해주진 않음)

Ponytail은 시작점이지 종점이 아닙니다. Ponytail을 설치하면 AI가 쓰는 코드는 줄어들지만, 대신 당신이 리뷰해야 하는 부담도 가벼워집니다. 이 두 가지는 같은 동전의 양면이에요.

마지막 한 문장으로 요약하면: Ponytail은 “코드를 덜 쓰게 하는 것”이 아니라 “먼저 써야 하는지 한 번 묻는 것”입니다.

다음 단계 추천: Defapi로 반값 Claude 키를 하나 받아서, Ponytail과 함께 당신의 실제 작업을 한 번 돌려보세요. 청구서에서 깎인 그 60%가 “Ponytail이 토큰을 줄여서” 절반, “Defapi가 단가를 줄여서” 나머지 절반임을 발견하게 될 겁니다.