2.9 KiB
2.9 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 |
|
2026-05-01 |
SOLID Principles
📌 한 줄 통찰 (The Karpathy Summary)
"소프트웨어의 유지보수성과 확장성을 보장하기 위한 5가지 핵심 설계 기둥: 인지적 부하를 낮추고, 변화에 유연하며, 결합도가 낮은 강건한 시스템을 구축하기 위한 객체지향 설계의 표준 지침."
📖 구조화된 지식 (Synthesized Content)
SOLID 원칙은 코드 리뷰와 시스템 설계의 무결성을 평가하는 핵심 기준입니다.
- Single Responsibility Principle (SRP): 클래스나 함수는 단 하나의 변경 이유만을 가져야 합니다. 모듈화를 통해 가독성과 테스트 용이성을 극대화합니다.
- Open-Closed Principle (OCP): 확장에는 열려 있고 수정에는 닫혀 있어야 합니다. 기존 코드를 건드리지 않고 새로운 기능을 추가할 수 있는 구조를 지향합니다.
- Liskov Substitution Principle (LSP): 하위 타입은 언제나 상위 타입으로 교체 가능해야 합니다. 상속 구조에서의 행동 일관성을 보장합니다.
- Interface Segregation Principle (ISP): 클라이언트가 사용하지 않는 메서드에 의존하도록 강요해서는 안 됩니다. 거대한 인터페이스보다 구체적이고 작은 인터페이스 여러 개가 낫습니다.
- Dependency Inversion Principle (DIP): 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 합니다. 구체적인 구현이 아닌 추상화에 의존하여 결합도를 낮춥니다.
⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- 추상화의 비용: 확장성을 위해 인터페이스와 추상화를 과도하게 도입할 경우, 코드의 직관성이 떨어지고 오버엔지니어링(Over-engineering)으로 이어질 수 있습니다. 현재의 요구사항과 미래의 유연성 사이의 실용적 타협(Trade-off)이 필수적입니다.
- 실행 흐름 파악의 어려움: DI(의존성 주입)를 극한으로 활용할 경우 런타임에 의존성이 결정되므로, 코드 정적 분석만으로는 전체 실행 흐름을 파악하기 어려워질 수 있습니다. 이를 보완하기 위한 명확한 문서화와 추적 로직이 필요합니다.
🔗 지식 연결 (Graph)
- Single Responsibility Principle (SRP): 첫 번째 원칙의 심화.
- Dependency Injection (DI): DIP를 실현하는 구체적 기법.
- Clean Architecture: SOLID를 애플리케이션 전체로 확장한 구조.
- Abstraction & Over-engineering: 설계 시 경계해야 할 트레이드오프.
- Test-Driven Development (TDD): 테스트하기 좋은 코드를 만드는 원칙으로서의 연결.