작성자 Matt Connor
Ponytail로 AI 코딩 에이전트의 과잉 구현 줄이기
Ponytail은 AI 코딩 에이전트가 가장 작은 변경으로 문제를 해결하게 하는 규칙 집합입니다. 실제 제공 기능, 자체 벤치마크 수치와 오늘 적용하는 방법을 확인합니다.
Ponytail이란 무엇인가
Ponytail은 AI 코딩 에이전트가 코드를 덜 작성하도록 유도하는 규칙 세트입니다. 이 프로젝트는 스스로를 "방 안에서 가장 게으른 시니어 개발자처럼 생각하게 만든다. 최고의 코드는 작성하지 않은 코드다"라는 한 문장으로 정의합니다. MIT 라이선스를 따릅니다. 자체 런타임이 없으며 내부에서 실행되는 코드는 없습니다. 이는 에이전트의 지침에 포함되는 텍스트이며, 스킬을 로드하는 호스트를 위한 스킬 형태나, 그렇지 않은 호스트를 위한 일반 규칙 파일 형태로 제공됩니다.
저장소는 DietrichGebert/ponytail입니다. 2026년 6월 12일에 생성되었으며 2026년 8월 1일 기준으로 별 90,000개를 돌파했습니다. 2026년 8월 1일 당시 최신 태그된 릴리스는 2026년 6월 29일에 게시된 v4.8.4였으며, 릴리스 페이지에는 6월 14일부터 29일 사이에만 10개의 태그가 나열되었습니다. 개발 속도는 줄어들지 않아, 2026년 10월 17일 기준 최신 릴리스는 10월 16일 늦게 게시된 v5.3.2입니다. 이는 v5.3.0와 v5.3.1에 이어 당일 세 번째로 나온 릴리스입니다. 그 이전에는 10월 13일의 v5.2.0이 있었고, 10월 8일에 v5.0.0과 v5.1.0가 모두 출시된 지 5일 만이었습니다. 현재 저장소는 165,000개 이상의 별을 기록하고 있습니다. 이처럼 빠르게 움직이는 프로젝트는 독자가 이 글을 읽을 때쯤이면 변경되었을 가능성이 높으므로, 기반 작업을 시작하기 전에 특정 태그를 고정하십시오.
도구보다 먼저 확인할 것: 성립하는 첫 번째 단계에서 멈추기
Ponytail의 핵심은 의사 결정 단계다. 에이전트는 코드를 작성하기 전에 이 단계를 순서대로 확인하고, 성립하는 첫 번째 단계에서 멈춘다.
- 이것이 애초에 필요한가? 이는 YAGNI(You Are Not Going to Need It) 원칙이다. 필요하지 않다면 건너뛴다.
- 이 코드베이스에 이미 존재하는가? 이미 있는 헬퍼나 패턴을 재사용한다.
- 표준 라이브러리가 처리하는가? 표준 라이브러리를 사용한다.
- 네이티브 플랫폼 기능으로 처리할 수 있는가? 해당 기능을 사용한다.
- 이미 설치된 의존성으로 해결할 수 있는가? 해당 의존성을 사용한다.
- 한 줄로 작성할 수 있는가? 한 줄로 작성한다.
- 그 다음에야 동작하는 최소한의 코드를 작성한다.
이것이 v4.8.4에 작성된 단계이며, 이 글의 나머지 부분에 나오는 단계 번호도 이를 따른다. 현재 main 브랜치에서는 3단계와 4단계를 하나로 합쳐 "표준 라이브러리나 플랫폼 기능으로 처리할 수 있는가? 프로젝트에 자체 기능이 없다면 이를 사용한다"로 정리하고, "하우스 컴포넌트가 네이티브 위젯보다 우선한다"는 규칙을 추가했으므로 6단계로 구성된다. 순서는 동일하다.
효과를 내는 것은 개별 단계가 아니라 순서다. 날짜 선택기를 요청받은 에이전트는 날짜 선택기를 작성한다. 지시받은 작업이 날짜 선택기 작성이기 때문이다. 이 단계는 에이전트가 무엇인가를 만들기 전에 이미 존재하는 것을 확인하게 한다. 2단계에서는 저장소에 해당 컴포넌트가 이미 있는지 확인하고, 4단계에서는 브라우저에 이미 <input type="date">이 있는지 확인한다. 프로젝트의 현재 벤치마크 기록은 이 사례를 정확히 보여준다. 규칙이 없을 때 335줄이었던 날짜 선택기가 Ponytail 5를 사용하자 10줄로 줄었다. 에이전트가 저장소 자체의 Input 컴포넌트를 type="date"와 함께 재사용하고 달력은 브라우저가 제공하게 했기 때문이다. 색상 선택기는 135줄에서 26줄로 줄어 감소 폭이 상대적으로 작았다. 조용히 실패하는 것은 2단계다. 에이전트가 이미 있는 헬퍼를 찾지 못하면 두 번째 헬퍼를 아무렇지 않게 작성하기 때문이다. 코드베이스를 조회 가능한 맵으로 만드는 기능은 이 공백을 메우기 위한 것이다.
여기서 게으르다는 말은 부주의하다는 뜻이 아니다. 규칙 집합도 이를 직접 명시한다. "게으르게 처리하지 말아야 할 항목"에는 판단하기 전에 문제를 이해하는 일, 신뢰 경계에서의 입력 검증, 데이터 손실을 방지하는 오류 처리, 보안, 접근성, 그리고 이름을 명시해 요청한 모든 항목이 포함된다. 또한 중요 로직의 각 부분마다 작게 실행할 수 있는 검사를 하나씩 작성하도록 요구한다. 이 규칙은 불필요한 발명을 줄인다. 정확성을 줄이는 것은 아니다.
저장소에 포함된 실제 내용
AGENTS.md: 항상 활성화된 규칙 세트로, 5분 안에 읽을 수 있는 전체 개념이 하나의 파일에 담겨 있습니다.skills/ponytail/SKILL.md: 스킬 정의 파일로,lite,full,ultra또는off의 인자 힌트를 포함합니다..cursor/rules/및.windsurf/rules/과 같이 에디터별 디렉터리에 위치한 규칙 파일들: 스킬을 로드하지 않고 규칙만 읽는 호스트를 위한 것입니다.hooks/,benchmarks/,examples/및scripts/.
강도(intensity) 인자는 규칙이 적용되는 강도를 변경합니다. lite는 요청한 내용을 빌드하면서 더 게으른 옵션을 한 줄로 제안합니다. full은 기본값이며 단계별 규칙을 강제합니다. ultra는 YAGNI(You Ain't Gonna Need It) 극단주의 설정으로, 추가보다는 삭제를 선호하며 요구 사항 자체에 대해 논쟁을 벌이기도 합니다.
스킬을 지원하는 호스트는 슬래시 명령어도 사용할 수 있습니다. /ponytail는 레벨을 설정하고, /ponytail-review은 과도한 엔지니어링이 있는지 diff를 확인하며, /ponytail-audit은 전체 저장소를 검사하고, /ponytail-debt은 미뤄둔 단축키를 수집하며, /ponytail-gain는 벤치마크 점수표를 출력합니다. 규칙 파일만 읽는 호스트는 명령어 없이 규칙 세트만 사용합니다. 2026년 10월 16일에 릴리스된 v5.3.0부터는 Claude Code의 프롬프트 상단에 작업 비용, 코드 재사용률, 테스트 상태를 보여주는 밴드가 표시됩니다. 이는 Claude Code 2.1.290 이상 버전이 필요하며, VS Code 채팅 패널, 클라우드 세션 또는 claude -p에는 나타나지 않고 /ponytail band off를 통해 숨길 수 있습니다. v5.3.2부터는 /ponytail band import가 과거 Claude Code 세션을 한 번 읽어 들여 비용, 에이전트 시간, 토큰 정보와 함께 보드에 추가하므로, 규칙을 적용한 세션과 비교할 수 있습니다.
소스를 신뢰하기 전에 읽어보려면 브랜치가 아닌 태그를 클론하십시오. 아래는 위에서 언급한 단계별 규칙이 포함된 태그입니다. 2026년 10월 17일 기준 최신 버전인 v5.3.2를 사용하여 현재 내용을 확인하십시오.
git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.gitClaude Code의 경우 프로젝트 문서에서는 대신 플러그인 설치를 안내하며, 2026년 10월 17일 기준으로 문서화된 두 줄은 다음과 같습니다.
/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail플러그인 경로는 태그가 아닌 기본 브랜치를 따르므로, 에이전트를 제어하는 지침이 세션 사이에 변경될 수 있습니다. 이는 업데이트 명령어의 편의성을 위해 감수해야 하는 부분입니다.
VPS에서 느슨한 에이전트가 더 저렴한 이유
에이전트가 작성한 diff는 대화에서 사라지지 않는다. 다음 턴에서 모델은 해당 diff를 다시 읽으며, diff를 만들기 위해 열었던 모든 파일도 함께 읽는다. 따라서 500줄의 변경은 이를 만든 턴에만 부담을 주는 것이 아니다. compaction이 이전 턴을 요약으로 대체할 때까지 세션의 이후 모든 턴에 부담을 준다. 세션이 진행될수록 과도한 리팩터링 때문에 에이전트가 더 느리고 둔해지는 이유가 여기에 있다. 컨텍스트 창이 에이전트 자신의 출력으로 채워지므로 실제 코드에 사용할 공간이 줄어든다. 이 문제를 통제하는 방법이 코딩 에이전트의 컨텍스트 창 관리의 핵심이다.
토큰은 입력과 출력 모두에 대해 과금된다. 따라서 diff의 크기가 절반이면 비용도 두 번 줄어든다. 한 번은 diff를 작성할 때 줄어들고, 이후 매 턴마다 diff를 다시 읽을 때도 줄어든다. 이 절감액이 실제 청구 금액에 반영되는지는 결제 방식에 따라 다르다. Pro 또는 Max 구독은 사용량 한도까지 추가 토큰을 포함하지만, 그 한도를 초과하면 opt-in 사용량 크레딧이 별도로 청구된다. 반면 토큰별 API 과금에서는 사용한 토큰마다 비용이 청구된다. 자체 호스팅 환경에서 비용을 확인하고 있다면, 지시 파일은 비용 없이 조정할 수 있는 수단이다. AI 에이전트 비용을 통제하는 방법은 출력량에서 시작하며, 코딩 에이전트가 토큰을 사용하는 방식은 다시 읽기가 예상보다 중요한 이유를 설명한다.
사람은 여전히 diff를 검토해야 한다. 20줄이면 충분한 변경이 400줄이라면 검토자의 주의력을 소모한다. 주의력은 가장 먼저 고갈되는 자원이다. 누구도 하루 중 네 번째 긴 diff를 첫 번째 diff와 같은 주의력으로 검토하지 않는다. 따라서 과도한 구현은 시간만 낭비하지 않는다. 실수를 찾아내야 하는 검토의 품질도 조용히 떨어뜨린다.
서버에서는 위험이 달라진다. 에이전트가 감시하는 사람 없이 실행되는 경우가 많기 때문이다. tmux 세션이나 timer로 실행되는 에이전트는 사용자가 확인하기 전에 잘못된 결정을 바탕으로 몇 시간 동안 작업할 수 있다. 이것이 VPS에서 코딩 에이전트 실행의 실질적인 위험이다. 또한 loop engineering을 수행하는 사람들이 개별 프롬프트보다 상시 지시 사항에 많은 주의를 기울이는 이유이기도 하다. 항상 사용하는 파일의 규칙은 200번째 턴에도 적용된다. 채팅에 입력한 규칙은 3번째 턴에만 적용된다. 같은 서버에서 시작한 두 번째 세션에도 적용된다. 두 번째 세션은 커밋된 파일은 읽지만 첫 번째 세션에서 입력한 내용은 상속하지 않는다. 이는 두 세션이 서로 메시지를 보낼 수 있는 경우에도 마찬가지다.
새로운 의존성도 눈에 잘 띄지 않는 비용이다. Rung 5는 설치된 항목을 사용하라고 지시한다. 에이전트가 독자적으로 추가하는 모든 패키지는 나중에 패치해야 하는 대상이다. 또한 해당 저장소에서 빌드하는 모든 컨테이너 이미지에 포함되는 대상이기도 하다.
Ponytail 자체 벤치마크 수치가 의미하는 것
이 프로젝트는 두 가지 종류의 결과를 게시했는데, 서로 큰 차이를 보입니다. 둘 다 프로젝트 자체에서 게시한 수치이며 독립적인 테스트 결과는 아닙니다.
이 차트의 데이터
[
{
"label": "Lines of code",
"v4_13_pct": 48,
"v5_pct": 53
},
{
"label": "Cost per run",
"v4_13_pct": 16,
"v5_pct": 26
},
{
"label": "Wall clock time",
"v4_13_pct": 38,
"v5_pct": 41
}
]이 차트는 2026년 10월 7일자로 작성된 프로젝트의 현재 에이전트 벤치마크입니다. Opus 5.5 모델에서 기본 노력(default effort)으로 설정된 Headless Claude Code 2.1.288 세션이 39개의 작업을 수행했습니다. 작업 및 분기당 5회 실행, 총 585개의 세션이 스킬 없음, Ponytail v4.13.0, Ponytail 5 환경에서 진행되었습니다. 작업 중 12개는 실제 FastAPI 및 React 저장소인 tiangolo의 full-stack-fastapi-template에 대한 기능 티켓이며, 남겨진 git diff를 기준으로 점수가 매겨졌습니다. 나머지는 숨겨진 검사가 포함된 18개의 외과적 작업, 6개의 소규모 앱 요청, 3개의 "예시를 보여달라"는 요청입니다. 모든 분기에서 Bash는 비활성화되었습니다. Ponytail 5 사용 시 출력 토큰은 45퍼센트 감소했습니다.
이 수치를 2026년 6월에 게시된 단일 샷(single shot) 수치와 비교해 보십시오. 해당 수치는 규칙 적용 여부에 따라 5개의 일상적인 프롬프트에 응답하는 기본 모델에서 도출되었으며, 반복 실행의 중앙값으로 보고되었습니다. Haiku, Sonnet, Opus 모델 전반에서 80~94퍼센트 적은 코드를 보여주었고, 2026년 6월 17일자 비용 검증에서는 Haiku가 63퍼센트 더 저렴한 것으로 나타났습니다. Ponytail 5에 대한 현재 에이전트 결과는 코드 라인 수 53퍼센트 감소, 비용 26퍼센트 절감, 작업 시간 41퍼센트 단축입니다. 프로젝트 측은 단일 샷 수치를 빠르게 수정했습니다. 2026년 6월 29일 v4.8.4 시점에는 README 상단에 에이전트 결과인 "~54% less code (up to 94%)"가 명시되었고, 이전의 80~94퍼센트는 "평균이 아닌 작업별 상한선"이라는 주석이 달렸으며, 단일 샷 수치는 "이전 단일 샷 수치"라는 접힌 섹션으로 옮겨졌습니다. 해당 섹션은 왜 격차가 존재하는지 솔직하게 설명합니다. 단일 샷 기준은 "답변을 산문과 옵션으로 채우는" 기본 모델이며, 이는 이기기 쉬운 대상입니다. 실제 작업을 수행하는 실제 에이전트를 기준으로 측정하면 성과는 줄어듭니다. 하지만 그 결과는 여전히 실질적이며, 이것이 더 유용한 사실입니다. Haiku 4.5에서 각각 4회씩 실행한 12개의 티켓에 대한 6월 에이전트 실행 결과는 오늘날의 수치와 가까운 54퍼센트 라인 감소를 기록했으며, 현재 README에는 더 이상 단일 샷 수치가 포함되어 있지 않습니다.
한 가지 주의 사항은 프로젝트 자체에서 언급한 내용이며, 이것이 여러분에게 도움이 될지 결정짓는 핵심입니다. 절감 효과는 과도하게 구축된 함정이 있는 곳에서 가장 크고, 이미 최소화된 코드에서는 거의 제로에 가깝습니다. 10월의 작업별 표가 이를 뒷받침하며, 여러 외과적 작업에서는 세 가지 분기 모두에서 동일한 라인 수를 기록했습니다. Bash를 끄고 하나의 모델과 하나의 호스트에서 수행한 39개의 작업은 여러분의 저장소를 대변하지 않습니다. 이 수치가 중요하다면, 규칙 적용 여부에 따라 자신의 티켓으로 직접 비교를 실행하고 라인 수를 직접 세어 보십시오.
오늘 바로 아무것도 설치하지 않고 복사해 사용할 수 있는 패턴
이 ladder는 텍스트이므로 이 아이디어를 사용하기 위해 plugin을 설치할 필요가 없다. AGENTS.md, CLAUDE.md 또는 editor의 rules file처럼 agent가 이미 읽는 instruction file에 다음과 같은 block을 붙여 넣으면 된다.
## Before you write code
Climb this list in order. Stop at the first line that applies.
1. Does this need to exist? If not, say so and stop.
2. Does this repo already have it? Reuse the helper.
3. Does the standard library do it? Use it.
4. Does the platform do it natively? Use it.
5. Does an installed dependency do it? Use it.
6. Can it be one line? Write one line.
7. Otherwise write the minimum that works.
Never take the shortcut on: reading the code before changing it, validating
input that crosses a trust boundary, error handling that would otherwise lose
data, security, accessibility, or anything I asked for by name.
Do not add an abstraction I did not ask for. Do not add a dependency without
saying why in one line. Prefer deleting code to adding it.
Mark a deliberate simplification with a comment naming its ceiling and the
upgrade path.마지막 rule은 별도로 살펴볼 가치가 있다. Ponytail의 현재 releases에서는 한도와 업그레이드 시점을 지정하는 shortcut: 주석을 사용하는 것이 convention이다. v4.8.4을 포함한 June releases에서는 대신 ponytail:로 지정했다.
# shortcut: global lock, per-account locks if throughput matters이 주석을 추가하면 작업이 두 줄이면 끝나고, 그렇지 않으면 review cycle이 필요한 질문도 해결된다. 이 주석은 다음 독자에게 단순한 버전이 의도적인 결정이었음을 알린다. 또한 그 결정이 더 이상 유효하지 않게 되는 조건도 명시한다. 이 내용이 없으면 reviewer는 신중하게 선택한 shortcut인지 agent가 빠뜨린 것인지 판단할 수 없다. 따라서 reviewer는 질문해야 한다.
block을 어디에 배치하는지는 내용만큼 중요하다. agent가 매번 불러오는 file은 사용자가 지켜보지 않는 실행을 포함해 모든 실행에 영향을 준다. agent가 실제로 따르는 AGENTS.md 작성에서는 이 차이를 설명한다. 따라서 이 pattern은 shell history가 아니라 commit된 file에 두어야 한다. monorepo에서는 commit된 file을 여러 개 두는 것이 좋다. package마다 AGENTS.md 두기를 적용하면 각 directory의 rules를 짧게 유지할 수 있고, agent가 매번 전체 tree의 convention을 읽지 않아도 된다. 그러나 배치만으로 실행이 보장되지는 않는다. ladder의 표현을 더 강하게 해야 한다고 결론내리기 전에 agent가 이미 읽은 rule을 지나치는 이유를 알아두는 것이 좋다.
규칙이 더 이상 맞지 않는 경우
이 단계표는 이미 존재하는 코드베이스에서 기능을 개발하는 작업에 맞춰져 있다. 이런 환경에서는 기존 코드를 재사용할 수 있고, 재사용하는 것이 대체로 올바르다. 그린필드 프로젝트에는 잘 맞지 않는다. 2단계에서는 재사용할 코드가 없고, 5단계에서는 설치된 항목이 없기 때문이다. 에이전트는 여전히 1단계인 표준 라이브러리, 플랫폼 기능 또는 한 줄짜리 코드에서 멈출 수 있다. 하지만 가장 비용이 낮은 선택지 중 2개가 사라지므로 더 많은 작업이 새 코드 작성으로 이어진다. 실제로 추상화가 필요한 시점에도 잘 맞지 않는다. 같은 복사된 블록을 사용하는 네 번째 호출자를 추가하려는 상황이라면, "최단 diff"는 다섯 번째 복사본을 만들게 한다.
ultra 수준에서는 요구 사항에 이의를 제기한다. 이것이 해당 수준의 목적이며, 이미 결정을 내리고 작업 완료를 원할 때는 실제 비용이 된다. 일반적인 작업에는 full을 사용하고, 기능 요청 자체가 문제라고 의심될 때 ultra를 선택한다.
어떤 지시문 블록도 문제를 잘못 이해한 상황을 해결해 주지는 않는다. 규칙 집합의 첫 번째 항목 자체가 결정하기 전에 코드를 이해하라고 요구한다. 이 과정이 가장 많은 비용이 들며, 문서가 대신 수행할 수 없는 부분이다. 잘못된 함수에 적용한 최소 diff도 여전히 잘못된 수정이다. 다만 이제는 승인하기 쉬운 작은 잘못된 수정이 되었을 뿐이다.
정리하면 Ponytail은 신중하게 작성되고 잘 배포된 프롬프트이며, 여기에 수치가 붙어 있다. 이를 위해 플러그인이 필요한 것은 아니다. 이 프로젝트가 제공하는 것은 누군가 목록을 올바르게 작성하고, 실제 저장소에서 테스트한 뒤, 그 결과와 함께 방법을 공개했다는 점이다.
FAQ
Ponytail은 Claude Code 외의 agent에서도 작동합니까?
예. Ponytail은 skill을 로드하는 host에서 사용할 수 있는 skill로 제공되며, 여기에는 Claude Code, Codex, OpenCode, Gemini와 README에 명시된 여러 다른 host가 포함됩니다. Cursor, Windsurf, Cline, Copilot처럼 rule file은 읽지만 skill은 로드하지 않는 editor는 일치하는 rules directory에서 always-on ruleset을 사용하며 slash command는 제공하지 않습니다. 어느 방식이든 텍스트는 동일합니다. 실제 차이는 host가 해당 텍스트를 매 turn마다 context에 유지하는지, 아니면 skill이 트리거될 때만 로드하는지입니다.
게으른 agent가 테스트, 검증 또는 보안을 건너뛸 수 있습니까?
아닙니다. ruleset은 이 원칙을 직접 명시합니다. "never lazy about" 목록에는 trust boundary에서의 input validation, data loss를 방지하는 error handling, security와 accessibility가 포함됩니다. 또한 중요하지 않은 단순 로직이 아닌 각 로직에 대해 실행 가능한 작은 check를 하나씩 작성하도록 요구합니다. 이 rule이 제거하는 것은 요청받지 않은 abstraction과 필요하지 않은 dependency처럼 인위적으로 추가한 구조입니다. 설치 후 agent가 테스트를 생략하기 시작한다면, 원인은 자체 config의 다른 instruction이 이 rule보다 우선하기 때문입니다. 따라서 agent가 마지막으로 로드하는 file을 확인해야 합니다.
공개된 속도와 비용 수치를 신뢰할 수 있습니까?
해당 수치는 프로젝트가 자체적으로 측정한 결과이며, 측정 방법과 함께 공개되었습니다. 따라서 그 범위 안에서 해석해야 합니다. 2026년 6월의 single shot 수치는 답변에 설명과 선택지를 불필요하게 덧붙인 bare model과 비교한 결과입니다. 당시 README 자체도 이 비교 대상을 약한 baseline으로 명시했습니다. 현재의 agentic 수치는 Opus 5.5를 사용하는 headless Claude Code session에서 얻은 결과입니다. 총 39개 task를 각각 5회 실행했으며, 그중 12개는 하나의 FastAPI 및 React repository에서 수행한 feature ticket이었습니다. 해당 설정에서는 이 수치를 신뢰할 수 있습니다. 그러나 사용자의 codebase에 대한 forecast로 볼 수는 없습니다. 프로젝트의 task별 자체 결과에서도 이미 최소화된 code에서는 절감 효과가 거의 0까지 감소하기 때문입니다.
효과를 얻기 위해 무언가를 설치해야 합니까?
아닙니다. 이 ladder는 텍스트로 구성됩니다. agent가 이미 읽는 instruction file에 이에 상응하는 block을 붙여 넣으면 효과의 대부분을 얻을 수 있습니다. plugin은 관리되는 문구, intensity level, review command와 update 경로를 제공합니다. 먼저 block을 복사해 적용하는 것은 설치가 반드시 필요한지 확인하는 rung 1 방식의 답입니다.
unattended agent가 밤새 과도하게 구현하지 않도록 하려면 어떻게 해야 합니까?
rule을 chat message가 아니라 always-on instruction file에 넣어야 합니다. 그러면 장시간 실행의 turn 3에서만이 아니라 turn 200에서도 적용됩니다. 그런 다음 피해 범위를 별도로 제한해야 합니다. agent가 망가뜨려도 되는 checkout을 제공하고, 유일한 사본은 사용하지 않아야 합니다. 또한 무엇이든 merge하기 전에 사람이 diff를 review하도록 요구해야 합니다. minimal diff rule을 적용하면 검토해야 할 내용이 줄어듭니다. 그러나 무엇을 반영할지는 결정하지 않으며, 결정해서도 안 됩니다.