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

# [[SOLID Principles|SOLID Principles]]

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

## 📖 구조화된 지식 (Synthesized Content)
SOLID 원칙은 코드 리뷰와 시스템 설계의 무결성을 평가하는 핵심 기준입니다.

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

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

## 🔗 지식 연결 (Graph)
- [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]: 첫 번째 원칙의 심화.
- [[Dependency Injection (DI)|Dependency Injection (DI]]: DIP를 실현하는 구체적 기법.
- [[Clean Architecture|Clean Architecture]]: SOLID를 애플리케이션 전체로 확장한 구조.
- Abstraction & Over-engineering: 설계 시 경계해야 할 트레이드오프.
- Test-Driven Development (TDD: 테스트하기 좋은 코드를 만드는 원칙으로서의 연결.
---