2nd/10_Wiki/Topic_Programming/Architecture/3의 법칙 (Rule of Three).md

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

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-3의-법칙-rule-of-three	3의 법칙 (Rule of Three)	10_Wiki/Topics	verified	self	Rule of Three WET Three Strikes Refactor	none	A	0.9	applied	refactoring dry code-smell abstraction		2026-05-10	pending	language framework python general

3의 법칙 (Rule of Three)

매 한 줄

"매 두 번까지는 복사, 세 번째 등장하면 추출." Don Roberts 가 Refactoring (Fowler, 1999) 에 정식화한 휴리스틱. 매 premature abstraction 을 피하면서 매 진짜 duplication 만 제거하는 trade-off rule. 2026 LLM 기반 codegen 시대에도 매 the cheapest signal — 매 abstraction 의 timing 을 결정.

매 핵심

매 왜 "3"인가

• 2회는 coincidence: 매 same-shape 의 코드 두 개는 매 future 에 diverge 할 가능성이 높음. 매 abstraction 으로 묶으면 매 wrong abstraction lock-in.
• 3회는 pattern: 매 third occurrence 에서 매 invariant 가 무엇인지 보임. 매 axis of variation 이 명확해짐.
• AHA principle: "Avoid Hasty Abstractions" (Sandi Metz). 매 duplication is far cheaper than the wrong abstraction.

매 vs DRY

• DRY: "Every piece of knowledge must have a single, authoritative representation" — 매 knowledge 에 대한 rule.
• Rule of 3: 매 code shape 에 대한 rule.
• 매 두 코드가 same-shape 이지만 different-knowledge 일 수 있음 → 매 DRY 가 적용되지 않음.

매 응용

1. Helper function 추출 timing 결정.
2. Component / Module 추출 timing 결정.
3. Configuration parameter 도입 timing 결정.

💻 패턴

1) 2회까지는 inline (resist abstraction)

# Occurrence 1
user_email = data["user"]["email"].strip().lower()

# Occurrence 2 — DO NOT extract yet
admin_email = data["admin"]["email"].strip().lower()

2) 3회째에 추출 — invariant 가 분명해진 시점

def normalize_email(raw: str) -> str:
    return raw.strip().lower()

user_email = normalize_email(data["user"]["email"])
admin_email = normalize_email(data["admin"]["email"])
support_email = normalize_email(data["support"]["email"])  # ← trigger

3) 매 wrong-abstraction 의 anti-pattern

# 2회만에 추출했다가 3회째가 다른 shape 으로 등장
def process_record(r, mode):  # mode 가 점점 늘어남 — leaky abstraction
    if mode == "user": ...
    elif mode == "admin": ...
    elif mode == "audit": ...  # 완전히 다른 logic

4) 매 React component 의 Rule of 3

// 2개 까지는 copy-paste
<Card title="A"><p>...</p></Card>
<Card title="B"><p>...</p></Card>
// 3번째 → extract <UserCard> abstraction

5) 매 LLM-assisted refactoring 의 trigger

# Claude / Cursor 에게 "extract this duplication" 을 매 3회 occurrence 부터 요청.
# 2회 occurrence 에서는 "leave inline" 을 명시.

6) 매 test 에서의 예외

# Test 코드는 Rule of 3 보다 readability 우선.
# 매 fixture 추출은 매 2회에도 OK (DAMP > DRY in tests).

매 결정 기준

상황	Approach
매 same-shape 코드 2회	Inline 유지
매 same-shape + same-knowledge 3회	Extract
매 same-shape + different-knowledge 3회	Inline 유지 (DRY 위반 아님)
Test fixture	2회에도 추출 OK
Cross-module duplication	3회 + 매 stable interface 확인 후

기본값: 매 3회까지 wait, 매 4번째에 후회하지 않을 abstraction 만 추출.

🔗 Graph

• 부모: Refactoring_Best_Practices · DRY
• 변형: YAGNI
• 응용: Code Smell

🤖 LLM 활용

언제: 매 codegen 의 review 시 — "이거 2회만에 추출됐는데 3회 기다려야 하나?" 매 sanity check. 언제 X: 매 test 코드 / 매 boilerplate / 매 framework-required pattern 에는 적용 X.

❌ 안티패턴

• Premature abstraction: 매 1-2회 occurrence 에서 추출 → 매 wrong axis 로 lock-in.
• Eternal copy-paste: 매 5+ occurrence 인데도 추출 안 함 → 매 maintenance burden.
• Mode-flag explosion: 매 추출한 함수에 매 boolean / enum flag 가 계속 늘어남 → 매 wrong abstraction signal.
• DRY-religious: 매 "any duplication is sin" → 매 shape 만 같은 code 까지 강제 통합.

🧪 검증 / 중복

• Verified (Fowler Refactoring 2nd ed. 2018, Sandi Metz "The Wrong Abstraction" 2016).
• 신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — Rule of 3 trade-off + AHA + LLM refactor trigger 정리