reinforce:wikify - Batch 21: Design Patterns & SOLID (5 artifacts)

10_Wiki/Topics_Dev/SOLID_Principles.md

@@ -1,46 +1,47 @@
 ---
 id: P-REINFORCE-WIKI-DEV-SOLID
-title: "객체 지향 설계 5원칙 (SOLID Principles)"
+title: "SOLID 원칙과 객체 지향 설계의 건전성 (SOLID Principles)"
 category: "10_Wiki/💻 Topics_Dev"
 status: verified
 canonical_id: ""
-aliases: ["SOLID", "객체 지향 설계 원칙", "클린 코드 원칙"]
+aliases: ["SOLID", "SOLID 원칙", "객체 지향 설계 원칙", "객체 지향 5대 원칙", "로버트 마틴"]
 duplicate_of: ""
 source_trust_level: A
 confidence_score: 1.0
-tags: ["OOP", "SOLID", "Clean_Code", "Design_Principles", "Maintainability"]
+tags: ["SOLID", "OOP", "Design_Principles", "Clean_Code", "Refactoring"]
 raw_sources: ["Datacollector_Export_2026-05-02"]
 last_reinforced: 2026-05-02
 github_commit: ""
 ---
 
-# [[객체 지향 설계 5원칙 (SOLID Principles)]]
+# [[SOLID 원칙과 객체 지향 설계의 건전성 (SOLID Principles)]]
 
 ## 1. 개요
-SOLID 원칙은 객체 지향 프로그래밍에서 소프트웨어 설계를 더욱 유연하고 유지보수하기 좋게 만들기 위해 고안된 5가지 설계 원칙의 집합이다. 로버트 C. 마틴에 의해 체계화되었으며, 결합도를 낮추고 응집도를 높이는 견고한 코드베이스의 기초가 된다.
+SOLID 원칙은 객체 지향 프로그래밍과 설계(OOAD)에서 소프트웨어를 더 이해하기 쉽고, 유연하며, 유지보수하기 좋게 만들기 위해 고안된 5가지 설계 원칙의 집합이다. 로버트 C. 마틴이 정리한 이 원칙들은 구성 요소 간의 결합도를 낮추고 응집도를 높임으로써, 시스템의 일부분을 변경하더라도 다른 부분에 미치는 영향을 최소화하는 견고한 아키텍처의 토대를 제공한다.
 
-## 2. 5대 원칙 (Five Principles)
-1.  **SRP (Single Responsibility Principle, 단일 책임 원칙)**: 클래스는 단 하나의 변경 이유만 가져야 한다. (하나의 클래스는 하나의 역할만 수행)
-2.  **OCP (Open/Closed Principle, 개방-폐쇄 원칙)**: 확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다. (기존 코드 변경 없이 기능 추가 가능해야 함)
-3.  **LSP (Liskov Substitution Principle, 리스코프 치환 원칙)**: 하위 타입은 언제나 자신의 상위 타입으로 교체될 수 있어야 한다.
-4.  **ISP (Interface Segregation Principle, 인터페이스 분리 원칙)**: 자신이 사용하지 않는 메서드에 의존하도록 강제해서는 안 된다. (구체적인 여러 인터페이스가 범용 하나보다 낫다)
-5.  **DIP (Dependency Inversion Principle, 의존성 역전 원칙)**: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다.
+## 2. 5대 핵심 원칙
+- **S (SRP: Single Responsibility Principle)**: 클래스는 단 하나의 변경 이유(책임)만 가져야 한다. 하나의 클래스가 너무 많은 역할을 수행하지 않도록 분리.
+- **O (OCP: Open/Closed Principle)**: 소프트웨어 요소는 확장에 대해서는 열려 있어야 하지만 수정에 대해서는 닫혀 있어야 한다. 기존 코드를 고치지 않고 기능을 추가할 수 있도록 설계(추상화 활용).
+- **L (LSP: Liskov Substitution Principle)**: 서브타입은 언제나 자신의 기반 타입(Base Type)으로 교체할 수 있어야 한다. 상속 구조에서 자식 클래스가 부모 클래스의 계약을 위반하지 않도록 보장.
+- **I (ISP: Interface Segregation Principle)**: 클라이언트는 자신이 사용하지 않는 메서드에 의존하도록 강제되어서는 안 된다. 범용 인터페이스 하나보다 구체적인 인터페이스 여러 개로 분리.
+- **D (DIP: Dependency Inversion Principle)**: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다. 의존성 주입(DI)을 통해 구현 기술로부터 비즈니스 로직을 보호.
 
-## 3. 실전 적용 팁
-- **SRP부터 시작**: 클래스의 역할을 분리하는 것만으로도 코드의 복잡성이 획기적으로 줄어든다.
-- **인터페이스 우선 설계**: 구현체보다 인터페이스(Contract)를 먼저 정의하여 자연스럽게 OCP와 DIP를 준수하도록 유도한다.
-- **점진적 리팩토링**: 레거시 코드를 한꺼번에 바꾸기보다 신규 기능 추가 시 해당 영역에 원칙을 적용하며 개선한다.
+## 3. 엔지니어링 가치
+- **변경에 유연한 구조**: 비즈니스 요구사항이 변할 때 코드의 대대적인 수정 없이도 안전하게 기능을 확장하거나 변경 가능.
+- **테스트 가능성 향상**: 결합도가 낮고 인터페이스 기반으로 설계되어 있어, 개별 모듈을 독립적으로 테스트하거나 모의 객체(Mock)로 대체하기 용이함.
+- **코드 가독성 및 재사용성**: 각 클래스의 역할이 명확하고(SRP) 모듈 간의 연결이 추상화되어 있어(DIP), 코드를 처음 접하는 개발자도 구조를 빠르게 이해하고 필요한 부분을 재사용 가능.
 
-## 4. 트레이드오프
-- **장점**: 코드 재사용성 향상, 테스트 용이성, 변화에 유연한 대응.
-- **단점**: 인터페이스 및 추상화 도입으로 인해 초기 설계 비용과 보일러플레이트 코드 증가.
+## 4. 트레이드오프 및 주의사항
+- **초기 설계 오버헤드**: 원칙을 지키기 위해 더 많은 인터페이스와 클래스를 정의해야 하므로, 초기 개발 속도가 다소 느려질 수 있음.
+- **과도한 추상화의 함정**: 모든 곳에 SOLID를 강박적으로 적용하면 코드가 파편화되어 오히려 전체적인 흐름을 파악하기 어려워질 수 있음(인지 부하 증가).
+- **점진적 적용의 미학**: 레거시 시스템을 단번에 SOLID로 바꾸려 하기보다, 새로운 기능을 추가하거나 버그를 수정할 때 해당 영역부터 점진적으로 개선하는 것이 현실적임.
 
 ## 5. 지식 연결 (Related)
-- [[Clean_Architecture]]: SOLID 원칙이 대규모 시스템 레이어 분리에 적용된 결과물.
-- [[Dependency_Injection]]: DIP를 실현하기 위한 핵심 기술적 수단.
-- [[Design_Patterns]]: SOLID 원칙을 특정 문제 해결에 맞게 구체화한 검증된 패턴들.
+- [[Design_Patterns]]: SOLID 원칙을 실현하기 위한 구체적인 구현 템플릿들.
+- [[Clean_Architecture]]: SOLID 원칙이 시스템 전반의 레이어 분리에 적용된 사례.
+- [[Dependency_Inversion_Principle]]: SOLID 원칙 중 아키텍처적으로 가장 영향력이 큰 원칙.
 
 ## 🧪 검증 상태 (Validation)
 - **정보 상태**: 검증 완료 (Verified)
 - **출처 신뢰도**: A
-- **검토 이유**: 소프트웨어 공학의 정수인 SOLID 원칙의 명확한 정의와 실천 방안 수록.
+- **검토 이유**: 객체 지향 시스템의 건전성을 평가하고 지속 가능한 코드베이스를 유지하기 위한 글로벌 설계 표준 정립.