Files
2nd/10_Wiki/Topics/02_Architecture_Principles/SOLID Principles.md
T

3.1 KiB

id, category, confidence_score, tags, last_reinforced
id category confidence_score tags last_reinforced
P-REINFORCE-AUTO-WIKI-ARCH-001 10_Wiki/💡 Topics/02_Architecture_Principles 0.95
architecture
ooad
solid-principles
maintainability
code-review
p-reinforce
2026-05-01

SOLID Principles

📌 한 줄 통찰 (The Karpathy Summary)

"소프트웨어의 유지보수성과 확장성을 보장하기 위한 5가지 핵심 설계 기둥: 인지적 부하를 낮추고, 변화에 유연하며, 결합도가 낮은 강건한 시스템을 구축하기 위한 객체지향 설계의 표준 지침."

📖 구조화된 지식 (Synthesized Content)

SOLID 원칙은 코드 리뷰와 시스템 설계의 무결성을 평가하는 핵심 기준입니다.

  1. Single Responsibility Principle (SRP): 클래스나 함수는 단 하나의 변경 이유만을 가져야 합니다. 모듈화를 통해 가독성과 테스트 용이성을 극대화합니다.
  2. Open-Closed Principle (OCP): 확장에는 열려 있고 수정에는 닫혀 있어야 합니다. 기존 코드를 건드리지 않고 새로운 기능을 추가할 수 있는 구조를 지향합니다.
  3. Liskov Substitution Principle (LSP): 하위 타입은 언제나 상위 타입으로 교체 가능해야 합니다. 상속 구조에서의 행동 일관성을 보장합니다.
  4. Interface Segregation Principle (ISP): 클라이언트가 사용하지 않는 메서드에 의존하도록 강요해서는 안 됩니다. 거대한 인터페이스보다 구체적이고 작은 인터페이스 여러 개가 낫습니다.
  5. 의존성 역전 원칙 (Dependency Inversion Principle DIP): 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 합니다. 구체적인 구현이 아닌 추상화에 의존하여 결합도를 낮춥니다.

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

  • 추상화의 비용: 확장성을 위해 인터페이스와 추상화를 과도하게 도입할 경우, 코드의 직관성이 떨어지고 오버엔지니어링(Over-engineering)으로 이어질 수 있습니다. 현재의 요구사항과 미래의 유연성 사이의 실용적 타협(Trade-off)이 필수적입니다.
  • 실행 흐름 파악의 어려움: DI(의존성 주입)를 극한으로 활용할 경우 런타임에 의존성이 결정되므로, 코드 정적 분석만으로는 전체 실행 흐름을 파악하기 어려워질 수 있습니다. 이를 보완하기 위한 명확한 문서화와 추적 로직이 필요합니다.

🔗 지식 연결 (Graph)