---
id: P-REINFORCE-WIKI-1E35B0CA
title: "SOLID 원칙 (SOLID Principles)"
category: "10_Wiki/💡 Topics/02_Architecture_Principles"
status: draft
canonical_id: ""
aliases: []
duplicate_of: ""
source_trust_level: A
confidence_score: 0.95
tags: ['SOLID Principles']
raw_sources: ["Datacollector_MAC/out_wiki/SOLID 원칙 (SOLID Principles).md"]
last_reinforced: 2026-05-02
github_commit: ""
---

# [[SOLID 원칙 (SOLID Principles)]]

## 📌 Brief 시Summary
SOLID 원칙은 객체 지향 프로그래밍(OOP)에서 소프트웨어 설계를 더 이해하기 쉽고, 유연하며, 유지보수하기 좋게 만들기 위해 고안된 5가지 핵심 설계 원칙의 집합이다 [1]. 로버트 C. 마틴("Uncle Bob")에 의해 대중화되었으며, 시간이 지나도 시스템을 쉽게 관리하고 확장 가능하게 만들어 코드의 부패(code rot)를 방지하는 견고한 기반을 제공한다 [1].

## 📖 Core Content
SOLID 원칙은 특정한 패턴이라기보다는 코드를 구성하는 방식에 영향을 미치는 사고방식(Mindset)에 가깝다 [2]. 이 원칙들은 서로 협력하여 의존성을 줄이고, 소프트웨어의 한 부분을 변경할 때 다른 부분에 미치는 영향을 최소화하도록 돕는다 [1]. 올바르게 적용될 경우 코드 품질 향상, 복잡성 감소, 재사용성 증대의 효과를 가져오며 5가지 원칙은 다음과 같다 [1].

*   **단일 책임 원칙 (Single Responsibility Principle, SRP):** 클래스는 단 하나의 변경 이유만 가져야 하며, 이는 곧 단 하나의 역할만 수행해야 함을 의미한다 [2]. 예를 들어, `UserPersistence` 클래스는 사용자 데이터를 저장하고 검색하는 일만 처리해야 하며 사용자 입력 검증을 담당해서는 안 된다 [2].
*   **개방-폐쇄 원칙 (Open/Closed Principle, OCP):** 소프트웨어 엔티티는 확장에는 열려 있어야 하지만 수정에는 닫혀 있어야 한다 [2]. 인터페이스나 추상 클래스를 사용하여 기존 코드를 변경하지 않고도 새로운 하위 클래스를 통해 새로운 기능을 추가할 수 있도록 한다 [2].
*   **리스코프 치환 원칙 (Liskov Substitution Principle, LSP):** 하위 타입(Subtypes)은 프로그램의 정확성을 훼손하지 않으면서 기본 타입(Base types)으로 매끄럽게 대체 가능해야 한다 [2]. 
*   **인터페이스 분리 원칙 (Interface Segregation Principle, ISP):** 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하도록 강요받아서는 안 된다 [2]. 거대하고 범용적인 인터페이스 하나를 만들기보다는 작고 구체적인 인터페이스 여러 개를 생성하여 이를 달성한다 [2].
*   **의존성 역전 원칙 (Dependency Inversion Principle, DIP):** 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다 [2]. 이는 주로 의존성 주입(Dependency Injection, DI)을 통해 구현된다 [2].

구현에 있어서는 '단일 책임(SRP)'부터 시작하는 것이 즉각적인 이점을 제공하며 가장 쉬운 접근법이다 [3]. 또한 구현 방법(How)보다 인터페이스(What)를 먼저 설계하는 프랙티스가 OCP와 DIP 원칙을 자연스럽게 지원한다 [3].

## ⚖️ Trade-offs & Caveats
*   **구현 복잡성 증가:** SOLID 원칙을 도입하려면 높은 수준의 설계 규율(Design discipline)과 객체 지향 패턴에 대한 이해가 요구되어 구현 복잡성이 '중간에서 높음(Medium-High)' 수준에 이른다 [4].
*   **자원 및 기술적 요구 사항:** 이 원칙들을 효과적으로 구현하기 위해서는 DI 프레임워크와 같은 기술적 도구와 이를 다룰 줄 아는 숙련된 개발자(Skilled developers)가 필요하다 [4].
*   **전면 개편의 위험성 (점진적 적용의 필요성):** 기존의 거대한 레거시 애플리케이션 전체를 한 번에 리팩토링하려고 하면 불필요한 복잡성과 오버헤드가 발생할 수 있다. 따라서 새로운 기능을 추가하거나 기존 코드를 수정할 때 점진적으로(Incrementally) 원칙을 적용해야 한다 [3].

## 🔗 Knowledge Connections

### Related Concepts

#### [관계 유형 A (아키텍처/기반 기술)]
- [[객체 지향 프로그래밍 (Object-Oriented Programming, OOP)]]
  - 연결 이유: SOLID 원칙 자체가 객체 지향 프로그래밍을 위한 5가지 기반 설계 원칙으로 구성되어 있기 때문이다 [1].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클래스, 상속, 서브타입, 추상화 등의 OOP 기반 개념을 이해함으로써 코드베이스 내에서 SOLID 원칙이 어떻게 의존성을 줄이고 유연성을 제공하는지 코어 메커니즘을 해독할 수 있다 [1, 2].

#### [관계 유형 B (구현/활용 도구)]
- [[의존성 주입 (Dependency Injection, DI)]]
  - 연결 이유: SOLID 원칙 중 '의존성 역전 원칙(DIP)'을 구현할 때 구성 요소들을 디커플링(Decoupling)하기 위해 실무적으로 가장 빈번하게 활용되는 프레임워크 및 패턴이기 때문이다 [2, 3, 5, 6].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Spring이나 ASP.NET Core와 같은 프레임워크 환경에서 객체의 생명주기와 의존성이 코드베이스 내에 어떻게 주입되고 역전되는지 동적인 흐름을 이해할 수 있다 [3].

### Deeper Research Questions

- 단일 책임 원칙(SRP)을 레거시 코드베이스에 점진적으로 적용할 때, 클래스를 나누는 경계를 결정하는 가장 객관적인 기준이나 지표는 무엇인가? [2, 3]
- 의존성 역전 원칙(DIP)을 준수하기 위해 DI 프레임워크를 전면 도입할 때 발생하는 런타임 오버헤드와 초기 학습 곡선을 어떻게 최소화할 수 있는가? [2-4]
- 인터페이스 분리 원칙(ISP)에 따라 거대한 인터페이스를 다수의 작은 인터페이스로 쪼개는 것이 오히려 코드베이스 내 파일 수 증가와 복잡성을 유발하지 않도록 방지하는 구조적 팁은 무엇인가? [2]
- 구현 코드 작성 이전에 인터페이스를 먼저 정의하는 방식이 OCP와 DIP를 보장하는 구체적인 메커니즘은 무엇인가? [2, 3]
- 마이크로서비스 아키텍처(Microservices Architecture)로 분리된 시스템 경계 너머에서도 SOLID 원칙이 유효한 설계 철학으로 작용할 수 있는가? [1, 7]

### Practical Application Contexts

- **Implementation:** 코드를 새로 작성하거나 수정할 때, 하나의 클래스가 두 가지 이상의 책임을 갖지 않도록 쪼개고(SRP), 기존 로직을 고치지 않고 기능 확장이 가능하도록 인터페이스 기반으로 개발한다 [2].
- **System Design:** 소프트웨어 컴포넌트들이 구체적인 구현체(저수준 모듈)가 아닌 추상화에 의존하도록 의존성 주입(DI) 패턴을 시스템 전반의 아키텍처 표준으로 도입한다 [2, 3].
- **Operation / Maintenance:** 방대한 레거시 코드를 한 번에 갈아엎기보다는 수정이 필요한 모듈이나 신규 피처 개발 시에 점진적으로 원칙을 적용해 유지보수성을 단계적으로 끌어올린다 [3].
- **Learning Path:** 코드베이스를 처음 파악하거나 원칙을 연습할 때, 가장 적용하기 쉽고 직관적인 '단일 책임 원칙(SRP)'이 지켜지고 있는지부터 분석하는 훈련을 한다 [3].
- **My Project Relevance:** 복잡하게 얽힌 소스코드를 읽을 때, 의존성 방향(DIP 위배 여부)과 거대 클래스(SRP 위배 여부)를 파악해 코드베이스의 리팩토링 포인트를 도출하는 진단 기준으로 활용한다.

### Adjacent Topics

- [[디자인 패턴 (Design Patterns)]]
  - 확장 방향: SOLID의 개념적 원칙들을 실제 코드 상에서 어떻게 구조화(생성, 구조, 행위 패턴)할 것인가에 대한 구체적이고 검증된 설계 해결책으로 학습을 확장할 수 있다 [1, 2, 8].
- [[클린 아키텍처 (Clean Architecture)]]
  - 확장 방향: 클래스 레벨의 객체 지향 원칙을 넘어, 시스템 전체의 비즈니스 로직을 프레임워크 및 외부 DB로부터 격리시키는 상위 수준의 아키텍처 설계 지식으로 연결된다 [9].

---
*Last updated: 2026-05-02*
## 🧪 검증 상태 (Validation)
- **정보 상태:** draft
- **출처 신뢰도:** A
- **검토 이유:** Datacollector에서 자동 추출된 위키 데이터의 초기 통합.

## 🧬 중복 검사 (Duplicate Check)
- **기존 유사 문서:** None
- **처리 방식:** CREATE
- **처리 이유:** 신규 지식 체계 도입
