---
id: P-REINFORCE-AUTO-D3B79D
category: "10_Wiki/💡 Topics/Programming & Language"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - SOLID 원칙 (SOLID Principles)"
---

# [[SOLID 원칙 (SOLID Principles)|SOLID 원칙 (SOLID Principles)]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> 지식 요약 정보 추출 중...

## 📖 구조화된 지식 (Synthesized Content)
**SOLID의 5가지 핵심 원칙**
소스 데이터에 따르면 SOLID는 다음 다섯 가지 원칙의 약자입니다 [1].
*   **단일 책임 원칙 (Single Responsibility Principle, SRP):** 클래스는 단 하나의 변경 이유만 가져야 하며, 오직 하나의 작업(책임)만 수행해야 합니다 [4]. 예를 들어, 사용자 데이터를 저장하고 조회하는 클래스가 사용자 입력 검증 기능까지 담당해서는 안 됩니다 [4]. 이는 관심사의 분리(SoC) 원칙을 극단적으로 적용한 형태로 볼 수 있습니다 [5].
*   **개방/폐쇄 원칙 (Open/Closed Principle, OCP):** 소프트웨어 엔티티는 확장을 위해서는 열려 있어야 하지만, 수정을 위해서는 닫혀 있어야 합니다 [4, 6]. 인터페이스나 추상 클래스를 사용하여, 기존 코드를 변경하지 않고도 새로운 하위 클래스를 통해 기능을 추가할 수 있게 함으로써 달성할 수 있습니다 [4].
*   **리스코프 치환 원칙 (Liskov Substitution Principle, LSP):** 하위 타입(Subtype)은 프로그램의 정확성을 훼손하지 않으면서도 기본 타입(Base type)으로 완벽하게 대체될 수 있어야 합니다 [4].
*   **인터페이스 분리 원칙 (Interface Segregation Principle, ISP):** 클라이언트가 자신이 사용하지 않는 인터페이스에 의존하도록 강요받아서는 안 됩니다 [4]. 하나의 크고 범용적인 인터페이스를 만들기보다는, 더 작고 구체적인 여러 개의 인터페이스를 생성해야 합니다 [4]. 
*   **의존성 역전 원칙 (Dependency Inversion Principle, DIP):** 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 두 모듈 모두 추상화(예: 인터페이스)에 의존해야 합니다 [4, 7]. 이는 주로 의존성 주입(Dependency Injection)을 사용하여 구현됩니다 [4].

**구현을 위한 실용적인 조언**
*   **SRP부터 적용하기:** 단일 책임 원칙은 적용하기 가장 쉬우며 즉각적인 이점을 제공합니다. 클래스를 작성하기 전에 "이 클래스의 단일 책임은 무엇인가?"라고 스스로 질문해야 합니다 [3, 8].
*   **구현 전 인터페이스 설계:** 컴포넌트가 '어떻게' 동작할지를 구현하기 전에, '무엇을' 해야 하는지(인터페이스)를 먼저 정의해야 합니다 [8]. 이 방식은 자연스럽게 OCP와 DIP 원칙을 지원합니다 [8].
*   **의존성 주입(DI) 프레임워크 활용:** Spring(Java)이나 ASP.NET Core와 같이 내장된 DI 컨테이너를 제공하는 프레임워크를 사용하면 컴포넌트 간의 결합을 분리하고 DIP를 훨씬 쉽게 구현할 수 있습니다 [8].
*   **점진적 도입:** 기존의 레거시 애플리케이션을 한 번에 모두 리팩토링할 필요는 없습니다. 새로운 기능을 추가하거나 기존 코드를 수정할 때 SOLID 원칙을 점진적으로 적용하여 코드베이스의 상태를 개선해 나가는 것이 좋습니다 [8].

**적용 시의 복잡도 및 요구사항**
*   SOLID 원칙을 구현하는 것은 설계 규율과 패턴을 요구하므로 중간에서 높음(Medium–High) 수준의 복잡도를 가집니다 [3].
*   이를 원활하게 적용하기 위해서는 숙련된 개발자와 의존성 주입(DI) 프레임워크 등의 리소스가 뒷받침되어야 합니다 [3].

## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.

## 🔗 지식 연결 (Graph)
- **Related Topics:** [[객체 지향 프로그래밍 (OOP)|객체 지향 프로그래밍 (OOP)]], [[관심사의 분리 (Separation of Concerns)|관심사의 분리 (Separation of Concerns)]], [[의존성 주입 (Dependency Injection)|의존성 주입 (Dependency Injection)]]
- **Projects/Contexts:** [[엔터프라이즈 애플리케이션 및 점진적 리팩토링|엔터프라이즈 애플리케이션 및 점진적 리팩토링]], [[라이브러리 및 확장 가능한 코드베이스|라이브러리 및 확장 가능한 코드베이스]]
- **Contradictions/Notes:** 소스 내에서 상충하는 주장은 발견되지 않았습니다. 다만, 단일 책임 원칙(SRP)은 시스템을 고차원적인 수준에서 분리하는 '관심사의 분리(SoC)' 원칙과 종종 비교되며, SRP는 클래스나 모듈의 '책임'이라는 더 미시적인 수준을 다루는 것으로 설명됩니다 [9].

---
*Last updated: 2026-04-18*
- Raw Source: 00_Raw/2026-04-20/SOLID 원칙 (SOLID Principles).md
---