안 만든 것이 규율이다 — 절제로 끌고 간 토이 프로젝트 회고 (Scrooge 5편)

🔗 scrooge

1. 도입부 — 토이 프로젝트가 망하는 진짜 이유

개인 프로젝트는 보통 기능 부족으로 망하지 않는다. 하고 싶은 게 너무 많아서 망한다. "이왕 만드는 김에 이것도", "나중에 필요할 테니 미리", "더 일반적으로 추상화해두면" — 이런 충동이 쌓이면, 정작 핵심은 미완인 채로 곁가지에 짓눌려 프로젝트가 무거워진다. 혼자 쓰는 도구일수록 이 제동장치가 없다. 리뷰어도, 데드라인도, 말려줄 동료도 없으니까.

scrooge는 약 2주, 57개 커밋으로 v0.6.1까지 굴러간 작은 도구다(2026-05-25 첫 커밋 ~ 06-02). 이 회고에서 말하고 싶은 건 그동안 만든 기능 목록이 아니다 — 그건 0~4화에서 충분히 다뤘다. 대신 "안 만든 것"이 어떻게 이 도구를 가볍게 유지했는가를 말하려 한다.

이 글에서 당신이 얻어갈 것은, 토이 프로젝트에 적용할 수 있는 "절제의 규율(discipline of restraint)" 몇 가지와, 그 규율이 실제로 무엇을 막았는지에 대한 구체적 사례다. 추상적 다짐이 아니라, "이 규칙이 없었다면 만들었을 것"의 목록이다.

---

2. 핵심 개념 — 규율은 "막은 것"으로 측정된다

좋은 working rule의 효과는 눈에 잘 안 띈다. 막은 것은 존재하지 않으므로 보이지 않기 때문이다. 쓰지 않을 추상을 안 만들었다면, 그 안 만든 추상은 코드베이스 어디에도 없어서 "내가 뭘 아꼈는지"조차 잊는다. 그래서 절제의 규율은 의식적으로 기록해야 그 가치를 알 수 있다.

이 글의 척추는 하나의 원칙이다.

speculative 금지 — 미래의 Task는 스캐폴딩일 뿐, 미리 만들지 않는다.

"나중에 필요할 것 같아서" 미리 짓는 코드를 금지하는 규칙이다. 그리고 이 원칙은 혼자 굴러가지 않는다. simplicity first(가장 단순한 해법부터), surgical changes(필요한 곳만 최소 변경), verification gate(완료 전 검증 통과 강제)가 함께 절제의 망을 짠다. 이들은 CLAUDE.md의 Working rules에 명문화돼 있다.

---

3. 동작 원리 — 각 규칙이 막은 것

규칙을 "지킨 미덕"이 아니라 "막은 사고"로 뒤집어 보면 그 값어치가 드러난다.

working rule이 실제로 막은 것: speculative 금지·simplicity first·surgical changes·verification gate가 각각 차단한 부채

 

speculative 금지 → 안 쓸 추상·죽은 코드를 막았다.
scrooge를 만들다 보면 "압축 규칙을 플러그인 시스템으로 일반화하면 어떨까", "dial을 임의 단계로 확장 가능하게 미리 설계하면" 같은 유혹이 온다. 전부 지금은 안 쓰는 기능이다. speculative 금지는 이걸 "필요해지면 그때"로 미뤘다. 결과적으로 코드베이스에 쓰이지 않는 추상 레이어와 죽은 코드가 쌓이지 않았다. 미래를 위한 스캐폴딩은 대부분 그 미래가 안 와서 부채로만 남는다.

simplicity first → 과설계를 막았다.
4화에서 본 단일 전역 상태 파일(~/.claude/.scrooge-active)이 좋은 예다. 프로젝트별·세션별 상태 키를 두는 "더 일반적인" 설계가 가능했지만, simplicity first는 "지금 필요한 가장 단순한 것"을 골랐다. 전역이라는 한계는 4화에서 솔직히 적었지만, 그 단순함이 상태 관리 코드를 한 군데로 모아줬다. 필요해지기 전에 일반화하지 않는다가 핵심이다.

surgical changes → 곁다리 리팩터의 회귀 위험을 막았다.
기능 하나를 고치다 보면 "이 김에 주변도 정리하자"는 충동이 온다. surgical changes는 변경을 필요한 곳에 국한했다. 곁다리 리팩터는 리뷰하기 어려운 큰 diff를 만들고, 본 작업과 무관한 회귀를 끌어들인다. 작은 변경은 되돌리기도 쉽다.

verification gate → 불일치와 "됐겠지" 머지를 막았다.
scrooge의 registry는 language × dial → rule path 1:1 계약이다(0화). 규칙 파일을 옮기거나 이름을 바꾸면 같은 변경에서 registry도 동기화해야 한다. verification gate는 이 동기화를 사람의 기억이 아니라 완료 전 검증에 맡겼다. "아마 맞겠지" 하고 머지했다가 registry와 실제 파일이 어긋나는 사고를 구조적으로 막은 것이다.

---

4. 실무 적용 — 절제를 규칙으로 박기

이 시리즈에서 "코드 예제" 자리는 working rule 문서가 채운다. 토이 프로젝트에도 그대로 옮길 수 있는 형태다.

✅ Good Practice — working rule을 명문화하고 "안 만들 것"을 적기

# CLAUDE.md — Working rules (발췌, 개념적 표현)

## 절제 원칙
- speculative 금지: "나중에 필요할 것 같아서"는 만들 이유가 아니다.
  미래 Task는 스캐폴딩으로만 남기고 코드로 짓지 않는다.
- simplicity first: 지금 필요한 가장 단순한 해법부터. 일반화는 두 번째
  사용 사례가 실제로 등장하면 그때.
- surgical changes: 변경은 필요한 곳에 국한. "이 김에"를 금지.
- verification gate: 완료 전 검증을 통과해야 머지. registry-rule 1:1
  동기화는 검증 항목에 포함.

## (선택) "안 만들기로 한 것" 로그
- 압축 규칙의 범용 플러그인화 → 보류 (사용 사례 1개뿐)
- dial 임의 단계 확장 → 보류 (lite/full로 충분)

핵심은 마지막 섹션이다. "안 만들기로 한 것"을 명시적으로 적으면, 막은 것이 비로소 보인다. 같은 충동이 또 올 때 "이미 보류하기로 했지"로 빠르게 처리된다.

❌ Anti-Pattern — "이왕 만드는 김에"의 누적

# 규칙 없는 토이 프로젝트의 전형
- "이왕이면 플러그인 시스템으로" → 안 쓰는 추상
- "나중을 위해 설정 레이어 미리" → 죽은 코드
- "이 김에 주변 리팩터" → 큰 diff, 회귀 위험
- "혼자 쓰는데 검증은 무슨" → registry-rule 불일치 방치

왜 문제인가. 각각은 "더 좋게 만들려는" 선의지만, 누적되면 핵심을 곁가지가 짓누른다. 혼자 쓰는 도구라 제동장치가 없으니 더 빨리 무거워진다. 그리고 이 부채는 "기능"처럼 보여서 줄이기도 어렵다 — 만든 걸 지우는 건 안 만드는 것보다 늘 힘들다.

🔍 실행 결과 — 절제가 남긴 궤적

약 2주·57커밋·v0.6.1이라는 작은 궤적은 규모로 인상적인 숫자가 아니다. 이 숫자의 의미는 반대다 — 이 기간 동안 쌓이지 않은 부채가 이 도구를 계속 손볼 만하게(maintainable) 유지했다는 것이다. dogfooding도 같은 결이다. 압축 도구를 만들며 그 도구로 압축한 문서를 쓰는(자기 도구를 자기가 먹는) 습관은, "안 쓰는 기능"을 일찍 발견하게 해줘 speculative를 자연히 억제했다. (registry 확장성과 dogfooding의 자세한 이야기는 0화에서 다뤘으니 여기선 콜백만.)

---

5. 장단점 및 고려사항

장점	단점·비용
✓ 부채가 안 쌓여 도구가 계속 손볼 만함	✗ "나중에 필요했던" 걸 그때 만드는 비용 발생
✓ 작은 변경이라 리뷰·롤백이 쉬움	✗ 큰 그림 리팩터를 미루다 한꺼번에 몰릴 수 있음
✓ "안 만들 것" 로그가 같은 고민을 재활용	✗ 규율을 기록·유지하는 약간의 오버헤드

 

실무 팁 — 토이 프로젝트 절제 체크리스트

• "나중에 필요할 것 같아서"는 만들 이유가 아니다. 두 번째 사용 사례가 실제로 올 때까지 미룬다(speculative 금지).
• 가장 단순한 해법부터 시작한다. 일반화는 단순함이 한계에 부딪힌 뒤에.
• 변경을 필요한 곳에 국한한다. "이 김에"가 떠오르면 별도 작업으로 적어두고 지금은 안 한다.
• 혼자 써도 검증 게이트를 둔다. 계약(registry 같은)이 있으면 그 동기화를 사람 기억이 아니라 검증에 맡긴다.
• "안 만들기로 한 것"을 기록한다. 막은 것은 보이지 않으므로, 적어야 그 가치를 안다.

---

핵심 3줄 요약

1. 토이 프로젝트는 기능 부족이 아니라 "이왕이면"의 누적으로 무거워진다. 품질은 무엇을 만들었나가 아니라 무엇을 안 만들었나로 갈린다.
2. speculative 금지·simplicity first·surgical changes·verification gate는 각각 죽은 코드·과설계·회귀 위험·계약 불일치를 막았다 — 규율은 막은 것으로 측정된다.
3. 막은 것은 보이지 않으므로 "안 만들기로 한 것"을 기록해야 그 가치가 드러난다.

시리즈를 마치며

이 시리즈는 "출력을 다루는 일도 인터페이스 craft"라는 한 줄을 따라왔다. scrooge는 LLM 출력의 표현·register·포맷을 설계하는 도구였고, 그건 FE가 오래 잘해온 presentation layer가 에이전트 표면으로 넓어진 것일 뿐이다. 접근성으로서의 압축(0화), 측정 우선(1화), 안전성 계약(2화), 비자명한 디버깅(3화), 멀티 호스트 이식(4화), 그리고 절제(5화) — 표면이 사람이든 에이전트든, 결과물이든 그걸 만드는 과정이든, 잘 만드는 craft는 결국 하나다.

 

저장소는 github.com/Kir93/scrooge-mode에 공개돼 있고, 이슈·PR·새 언어 rule 기여 모두 환영한다.