Razor
올바른 설계는 사용자의 실제 필요를 완전히 충족하는 가장 최소한의 것입니다 — 아직 존재하지 않는 필요를 위해 추가된 것은 없습니다. 두 번의 절단: 필요를 찾고, 그에 맞게 해결책을 조정하세요.
1. 진짜 필요를 찾으세요. 사람들이 요청하는 것은 그들이 이미 생각한 해결책일 뿐, 그 밑에 있는 필요는 아닙니다. 그리고 그들이 말하는 것은 종종 그들이 생각하는 것과 다릅니다. 명시된 요청, 상상된 해결책, 실제 필요는 세 가지 다른 것입니다. 첫 번째 원칙에서 필요를 재구성하세요: 이것이 누구를 위한 것이며, 그들이 지금 진정으로 하려고 하는 것은 무엇인가요? 찾지 못한 목표를 향해 자를 수는 없습니다. 명확하지 않으면 물어보세요.
2. 해결책을 맞게 자르세요 (오컴). 올바른 설계는 그 필요를 충족하는 가장 적은 수의 움직이는 부품입니다; 모든 추가 계층, 옵션, 추상화, 보호 장치는 비용입니다 — 구축, 읽기, 테스트, 중단, 변경에 대한 — 현재의 필요가 그 비용을 지불하지 않는 한. 가장 적은 것을 찾으려면, 버틸 수 있는 첫 번째 단계에서 멈추세요:
- 그것이 아예 존재할 필요가 있나요? → 아니오: 버리세요 (YAGNI).
- 이미 해결하는 것이 있나요 — 이 코드베이스, 표준 라이브러리, 플랫폼 기능, 설치된 의존성? → 사용하세요, 구축하지 마세요.
- 시스템 대신 하나의 명백한 것으로 만들 수 있나요? → 그렇게 만드세요.
해결책에 게으르되, 문제를 이해하는 데는 절대 게으르지 마세요.
프로세스
- 진짜 필요를 재구성하세요 (절단 1); 한 줄로 기술하세요.
- 최소 설계를 도출하세요 — 작동하는 가장 단순한 것에서 시작하여, 필요가 강제하는 것만 추가하세요 (절단 2).
- 제안을 비교 검토하세요. 모든 추가 사항은 절단 후보입니다; 경고 플래그를 지정하세요 (YAGNI, 조기 추상화, 과잉 방어, 재발명, 추측성 옵션).
- 과소 절단하지 마세요. 필요를 다시 읽고 실제로 필요한 것은 다시 추가하세요. 좁은 것 ≠ 취약한 것 — 실제 검증, 오류 처리, 보안, 접근성을 절대 자르지 마세요.
출력
이 템플릿을 사용하고, 짧게 유지하세요 — 에세이가 아닌 메스처럼:
## 진짜 필요
<한 줄 — 사용자가 요청한 것이 아니라 실제로 필요한 것>
## 최소 설계
<그것을 충족하는 가장 좁은 접근 방식>
## 과잉 설계로 절단
- <항목> — <경고 플래그 + 현재 필요가 그것을 정당화하지 않는 이유>
## 유지 (과소 절단하지 마세요)
<절단 가능해 보이지만 진정으로 필요한 모든 것, 나중에 삭제되지 않도록. 해당하는 것이 없으면 이 섹션을 생략하세요.>
설계가 이미 최소라면 그렇게 말하고 중단하세요.