| name | keep-it-small |
| description | Enforces minimal-code-for-same-output discipline. Before letting new functions, files, modules, abstractions, or dependencies grow the codebase, this skill checks whether the same outcome can be achieved by extending what already exists, and gives a line-count estimate up front. 코드를 작성·확장·리팩터·생성·추가할 때 최소한의 코드량으로 같은 결과를 내도록 강제하는 엔지니어링 철학 스킬. |
| when_to_use | Use whenever code volume is about to increase — adding a new module, feature, file, scaffold, or boilerplate ("이거 추가해줘", "기능 더 붙이자", "파일 새로 만들어", "add a new module", "build this feature", "scaffold", "generate boilerplate") — and especially during AI-rapid-generation / vibe-coding sessions, or when the user expresses doubt about volume ("이거 다 필요한가?", "코드가 너무 많아진 거 같아", "리팩터하고 싶어"). |
| allowed-tools | Read Edit Grep Glob |
한 줄. 1000줄로 할 일을 100줄로 끝낼 수 있다면, 그렇게 한다.
Why this mindset
어떻게 하면 최적의 코드량으로 아웃풋을 낼 수 있을지 고민해야 합니다.
AI와 함께라면 하루에 1만 줄의 코드도 거뜬하게 작성할 수 있습니다. 하지만 너무 많은 코드량은 대부분의 경우 병목으로 작용합니다. 10만 줄이 넘어가면 AI에게도 병목이 됩니다.
1000줄의 코드로 만들어낼 수 있는 경험을 100줄의 코드로 만들어낼 수 있다면, 최대한 적은 코드로 아웃풋을 만들어내세요. 이미 있는 코드를 재활용하고, 반복되는 패턴은 모듈화하세요.
Instructions
코드를 더하기 전에 빼는 길을 먼저 본다. "쉽게 많이 쓸 수 있다"는 말이 "많이 써야 한다"는 말은 아니다.
-
있는 걸 먼저 본다.
새 코드를 짜기 전에 프로젝트 안에 같은 일을 하는 함수·유틸·컴포넌트·헬퍼가 이미 있는지 찾는다 (Grep, Glob). 80%만 맞아도 그쪽을 살짝 늘리는 게, 새로 만드는 것보다 거의 항상 가볍다.
-
반복되면 묶는다, 한 번뿐이면 안 묶는다.
같은 패턴이 3번 이상 반복되면 모듈화 후보. 하지만 1~2번 등장하는 코드를 미리 추상화하지 않는다 — 가짜 추상화는 줄 수만 늘리고 진짜 줄여주지 않는다.
-
줄 수 견적을 미리 말한다.
기능을 붙이기 전에 "이건 대략 N줄 정도로 끝날 거야"라고 먼저 말한다. 견적이 100줄을 넘기 시작하면 멈추고 "더 작은 길이 있는지" 한 번 더 본다. 200줄, 500줄을 넘기 시작하면 "정말 이만큼 필요한지" 사용자와 다시 짚는다.
-
삭제도 결과물이다.
요청이 "추가"여도, 추가하면서 기존 코드 일부를 줄일 기회가 보이면 같이 정리한다. 새로 50줄 넣고 기존 80줄을 지웠다면 그게 더 좋은 변경이다.
-
언어·프레임워크의 기본기를 먼저 쓴다.
직접 짜기 전에 표준 라이브러리, 프레임워크 내장 기능, 이미 설치된 의존성으로 끝낼 수 있는지 확인한다. 새 의존성을 추가하는 건 "줄 수는 줄지만 무게는 늘어나는" 거래라 신중하게.
Examples
작게 가는 흐름:
- 사용자: "유저 검색 기능 만들어줘."
- Claude: "기존에
useUsers 훅이 이미 목록을 가져오고 있네. 거기에 클라이언트 측 필터 한 줄 추가하면 끝나. 새 API·새 컴포넌트 안 만들고 ~10줄 추가로 충분해."
견적 말하고 시작:
- 사용자: "결제 연동해줘."
- Claude: "이건 대략 150~250줄 사이로 보여. 핵심은 SDK 초기화·체크아웃 호출·웹훅 검증 세 군데야. 더 줄일 여지는 SDK가 제공하는 헬퍼를 그대로 쓰는 거고. 그 방향으로 갈까?"
멈추는 흐름:
- 사용자: "이 컴포넌트마다 props validation 헬퍼 만들어서 다 통일하자."
- Claude: "지금 컴포넌트가 두 개라 헬퍼를 만들면 헬퍼 정의 + 두 컴포넌트 수정으로 오히려 줄 수가 늘어나. 세 번째 컴포넌트가 등장할 때 만드는 게 어때?"
Pitfalls
- "어차피 AI가 짜주니까" 하는 무게 없는 코드 폭주
- 한 번밖에 안 쓰는 추상화 / 한 번밖에 안 쓰는 헬퍼 함수
- 기존 코드 안 보고 비슷한 걸 또 만드는 일
- "혹시 모르니까" 미리 깔아두는 옵션·플래그·설정
- 보일러플레이트가 본문보다 긴 모듈
적은 코드는 게으름이 아니다. 읽는 사람·고치는 사람·미래의 본인을 위한 배려다. 줄이는 데 든 시간만큼, 그들의 시간이 돌아온다.
