Files

T

koriweb 5ba5a55c78 feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]

2026-05-08 19:52:07 +09:00

5.1 KiB

Raw Blame History

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit, inferred_by, tech_stack

title

3의 법칙 (Rule of Three)

📌 한 줄 통찰 (The Karpathy Summary)

3의 법칙(Rule of Three)은 돈 로버츠(Don Roberts)가 제안하고 마틴 파울러(Martin Fowler)가 대중화한 소프트웨어 리팩토링의 핵심 경험 법칙(Rule of Thumb)이다 [1, 2]. 이 법칙은 유사한 형태의 코드가 세 번 반복해서 사용될 때 비로소 중복을 피하기 위해 리팩토링을 수행해야 한다고 명시한다 [1, 3]. 이는 무분별한 리팩토링으로 인한 오버 엔지니어링과 기술 부채 사이의 균형을 맞추고, 실용적인 설계 조정을 권장하는 가이드라인이다 [3].

📖 구조화된 지식 (Synthesized Content)

3단계 진행 방식 (Three strikes and you refactor):
1. 첫 번째로 무언가를 구현할 때는 단순히 기능을 완성하는 데 집중하여 일단 진행한다 [4-6].
2. 두 번째로 비슷한 작업을 수행할 때는 코드 중복으로 인해 다소 꺼림칙하거나 불편함을 느끼더라도, 같은 방식으로 중복을 허용하여 코드를 작성한다 [2, 4, 6].
3. 세 번째로 동일한 형태의 작업이 반복되는 시점이 오면, 그때 비로소 리팩토링을 시작하여 중복된 코드를 새로운 프로시저나 클래스로 추출 및 공통화한다 [1, 2, 4, 5].
패턴 발견과 정확한 추상화 유도: 단 두 번의 사례만으로는 코드의 공통점을 명확히 찾기 어려울 수 있다. 하지만 중복이 세 번 이상 발생할 경우, 공통점과 차이점의 패턴을 훨씬 쉽게 파악할 수 있어 더 정확하고 올바른 추상화 수준을 결정하는 데 도움이 된다 [2, 7, 8].
경제성 관점: 코드의 중복은 코드를 유지보수하기 어렵게 만들지만, 3의 법칙은 세 개의 복사본이 존재하게 될 때 발생하는 유지보수 비용이 리팩토링을 수행하는 비용 및 잠재적인 나쁜 설계의 위험성을 확실히 초과하게 된다는 것을 내포하고 있다 [1, 9].

⚠️ 모순 및 업데이트 (Contradictions & Updates)

성급한 추상화(Premature Refactoring)의 위험성: 세 번의 중복이 나타나기 전에 너무 일찍 리팩토링을 시도하면 잘못된 추상화를 선택할 위험이 커진다 [2, 8]. 잘못된 추상화 모델이 시스템에 고착되면, 새로운 요구사항(유스케이스)을 처리하기 위해 부자연스러운 매개변수나 if 문 등을 억지로 추가해야 하므로 코드 유연성이 저하된다 [2, 10]. 결론적으로 잘못된 추상화보다 차라리 코드의 중복을 남겨두는 것이 유지보수 비용 측면에서 훨씬 저렴하다 [11].
도그마화(Dogmatic)에 대한 경계: 3의 법칙은 반드시 100% 지켜야 하는 엄격한 교리가 아니라 지침으로 활용해야 한다 [12, 13]. 세 번의 중복이 발견되었더라도 올바른 추상화 방법을 찾기 어렵거나 새로운 개념에 명확한 이름을 붙일 수 없다면, 억지로 추상화(over-abstraction)를 강요해서는 안 된다 [12]. 이런 경우에는 상황에 대한 더 많은 컨텍스트를 얻고 추가적인 중복 사례가 나타날 때까지 리팩토링을 유보하고 기다리는 것이 더 안전하다 [10].

Last updated: 2026-05-03

🤖 LLM 활용 힌트 (How to Use This Knowledge)

언제 이 지식을 쓰는가:

(TODO)

언제 쓰면 안 되는가:

(TODO)

🧪 검증 상태 (Validation)

정보 상태: needs_review
출처 신뢰도: A
검토 이유: (P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)

🧬 중복 검사 (Duplicate Check)

기존 유사 문서: (TODO: 인덱서 클러스터 리포트 참조)
처리 방식: UPDATE (자동 정규화)
처리 이유: Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

🔗 지식 연결 (Graph)

Parent: 10_Wiki/Topics
Related: (TODO: 최소 2개)
Opposite / Trade-off: (TODO)
Raw Source: 직접 입력

🕓 변경 이력 (Changelog)

날짜	변경 내용	처리 방식	신뢰도
2026-05-08	P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화)	UPDATE	A

💻 코드 패턴 (Code Patterns)

패턴 1: (TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)

# TODO

🤔 의사결정 기준 (Decision Criteria)

선택 A를 써야 할 때:

(TODO)

선택 B를 써야 할 때:

(TODO)

기본값:

(TODO)

❌ 안티패턴 (Anti-Patterns)

[안티패턴]: (TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)

5.1 KiB Raw Blame History