---
category: Unified
tags: [auto-consolidated, technical-documentation]
title: [[SOLID 원칙|SOLID 원칙]]
last_updated: 2026-05-02
---

# [[SOLID 원칙|SOLID 원칙]]

## 📌 Brief Summary
> SOLID 원칙은 객체 지향 프로그래밍에서 소프트웨어 설계를 더 이해하기 쉽고, 유연하며, 유지보수하기 좋게 만들기 위해 고안된 5가지 핵심 설계 원칙의 집합이다 [1]. 로버트 C. 마틴(Ro[[BERT|BERT]] C. Martin)에 의해 대중화된 이 원칙들은 코드의 부패를 방지하고 견고한 기반을 구축하는 데 필수적인 지침으로 작용한다 [1]. 이 원칙들을 올바르게 적용하면 시스템 내 컴포넌트 간의 의존성이 줄어들어 한 부분의 변경이 다른 부분에 미치는 영향을 최소화할 수 있다 [1].

---

SOLID 원칙은 객체 지향 프로그래밍에서 소프트웨어 설계를 더욱 이해하기 쉽고 유연하며 유지보수하기 좋게 만들기 위해 고안된 5가지 기본 설계 원칙의 집합이다 [1]. 이 원칙들은 구성 요소 간의 의존성을 줄여 시스템의 한 부분을 변경하더라도 다른 부분에 미치는 영향을 최소화하도록 돕는다 [1]. 올바르게 적용될 경우 코드의 품질이 향상되고 복잡성이 감소하며, 장기적으로 결합도가 낮고 테스트하기 쉬운 견고한 코드베이스를 구축할 수 있다 [1, 2].

## 📖 Core Content
**SOLID의 5가지 핵심 원칙**
* **단일 책임 원칙 (SRP, Single Responsibility Principle):** 클래스는 단 하나의 변경 이유만 가져야 하며, 이는 오직 하나의 역할(책임)만을 수행해야 함을 의미한다 [2, 3]. 이를 통해 클래스를 더 쉽게 이해하고 평가할 수 있으며, 코드의 명확성과 유지보수성이 향상된다 [3]. SRP는 '관심사의 분리(SoC)' 개념에서 직접적으로 파생된 원칙 중 하나이다 [4].
* **개방-폐쇄 원칙 (OCP, Open/Closed Principle):** 소프트웨어 엔티티는 확장에는 열려 있어야 하지만 수정에는 닫혀 있어야 한다 [2, 3, 5]. 이는 인터페이스나 추상 클래스와 같은 추상화 및 다형성 과정을 사용하여, 기존 코드를 변경하지 않고도 새로운 하위 클래스를 통해 새 기능을 추가할 수 있게 함으로써 달성된다 [2, 3].
* **리스코프 치환 원칙 (LSP, Liskov Substitution Principle):** 하위 타입(서브클래스)은 프로그램의 정확성을 훼손하지 않으면서 기본 타입(부모 클래스)을 대체할 수 있어야 한다 [2, 3]. 이는 파생 클래스가 기본 클래스의 동작을 임의로 변경하지 않고 매끄럽게 호환되어 시스템의 신뢰성과 견고성을 향상시킬 수 있도록 보장한다 [2, 3].
* **인터페이스 분리 원칙 (ISP, Interface Segregation Principle):** 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하도록 강요받아서는 안 된다 [2, 3]. 이를 위해 하나의 크고 범용적인 인터페이스보다는 작고 구체적이며 전문화된 인터페이스를 여러 개 만드는 것이 권장되며, 이 역시 '관심사의 분리(SoC)' 원칙에서 파생되었다 [2-4].
* **의존성 역전 원칙 (DIP, Dependency [[Inversion|Inversion]] Principle):** 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 양쪽 모두 추상화(예: 인터페이스)에 의존해야 한다 [2, 3, 6]. 이러한 접근은 종종 의존성 주입(Dependency Injection, DI) 프레임워크를 통해 구현되며, 모듈성을 높이고 시스템이 변화에 쉽게 적응할 수 있도록 만든다 [2, 3, 7].

**구현 팁 및 기대 효과**
* SOLID 원칙을 레거시 애플리케이션 전체에 한 번에 적용하기보다는, 가장 적용하기 쉽고 즉각적인 이점을 제공하는 '단일 책임 원칙(SRP)'부터 시작하여 점진적으로 적용하는 것이 유리하다 [7].
* 구현 방법(How)보다 컴포넌트가 해야 할 일인 인터페이스(What)를 먼저 설계하는 관행을 들이면 자연스럽게 OCP와 DIP 원칙을 뒷받침할 수 있다 [7].
* 이 원칙들은 객체 지향 시스템, 라이브러리, 그리고 지속적으로 성장하는 대규모 코드베이스에 이상적으로 적용되며, 결합도가 낮고 테스트 가능성이 높으며 유연한 코드를 산출하는 핵심 기반이 된다 [8].

---

로버트 C. 마틴("Uncle Bob")에 의해 대중화된 SOLID 원칙은 특정한 단일 패턴이라기보다는 코드를 구성하는 사고방식(mindset)에 가깝다 [1, 3]. 다음 5가지 핵심 원칙으로 구성된다.

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

**구현을 위한 실행 팁 (Actionable Tips):**
*   가장 쉽고 즉각적인 이점을 제공하는 **단일 책임 원칙(SRP)**부터 시작하여 설계를 훈련하는 것이 좋다 [4].
*   구현 방식을 코딩하기 전에 컴포넌트가 '무엇을 해야 하는지' 정의하는 **인터페이스를 먼저 설계**하여 자연스럽게 OCP와 DIP를 지원하도록 한다 [4].
*   기존 레거시 애플리케이션 전체를 단번에 리팩토링하기보다는 **새로운 기능을 추가하거나 코드를 수정할 때 점진적**으로 건강한 코드베이스로 개선해 나간다 [4].

## ⚖️ Trade-offs & Caveats
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.

---

*   **높은 구현 복잡성:** 설계 규율(design discipline)과 패턴에 대한 높은 이해도를 요구하기 때문에 구현 복잡성이 중간에서 높은(Medium-High) 수준이다 [2].
*   **리소스 요구사항:** 이 원칙을 제대로 적용하려면 숙련된 개발자 인력과 Spring, ASP.NET Core 등과 같은 의존성 주입(DI) 프레임워크 기술이 필요하다 [2, 4].
*   **점진적 도입의 필요성:** 대규모 레거시 코드를 한 번에 SOLID 기반으로 재설계하려 하면 시스템이 지나치게 복잡해질 위험이 있다. 따라서 점진적으로 원칙을 적용하는 현실적인 접근이 필수적이다 [4].

## 🔗 Knowledge Connections
- **Related Topics:** [[객체 지향 프로그래밍 (OOP)|객체 지향 프로그래밍(OOP]], 관심사의 분리(SoC), [[의존성 주입 (DI)|의존성 주입(DI]]
- **Projects/Contexts:** [[클린 아키텍처 (Clean Architecture)|클린 아키텍처(Clean Architecture]], [[소프트웨어 아키텍처 베스트 프랙티스|소프트웨어 아키텍처 베스트 프랙티스]]
- **Contradictions/Notes:** 소스 전반에 걸쳐 SOLID 원칙은 코드의 복잡성을 줄이고 유지보수성을 높이는 필수적인 기법으로 일관되게 강조되고 있으며, 서로 대립하거나 모순되는 주장은 존재하지 않습니다 [1, 3, 8].

---
*Last updated: 2026-04-18*

---

---

### Related Concepts

#### [아키텍처 및 설계 패러다임]
- [[객체 지향 프로그래밍 (OOP)]]
  - 연결 이유: SOLID 원칙은 OOP 시스템의 유연성과 유지보수성을 극대화하기 위해 탄생한 핵심 기반 설계 철학이다 [1, 2].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클래스, 인터페이스, 상속 및 다형성과 같은 OOP의 기본 요소들이 SOLID와 어떻게 상호작용하는지 이해할 수 있다.

#### [구현 및 활용 도구]
- [[의존성 주입 (Dependency Injection)]]
  - 연결 이유: SOLID의 의존성 역전 원칙(DIP)을 달성하고 계층 간의 결합도를 낮추기 위해 사용되는 핵심 구현 기법이자 프레임워크이다 [3, 5, 6].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 객체 간의 생성과 결합을 외부로 분리함으로써 테스트 가능성(Testability)이 어떻게 향상되는지 파악할 수 있다.
- [[디자인 패턴 (Design Patterns)]]
  - 연결 이유: SOLID 원칙의 철학은 팩토리 패턴, 퍼사드 패턴 등 검증된 여러 소프트웨어 디자인 패턴들을 구현하는 기초 논리로 작동한다 [1, 3, 7].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 복잡한 코드베이스에서 설계 문제에 봉착했을 때, 원칙을 넘어 구체적이고 반복 가능한 해법을 도출하는 능력을 기를 수 있다.

### Deeper Research Questions
- 의존성 역전 원칙(DIP)을 효과적으로 구현하기 위해 Spring이나 ASP.NET Core와 같은 의존성 주입(DI) 프레임워크를 어떻게 최적화하여 구성할 수 있는가? [4]
- 모놀리식 시스템의 레거시 코드를 마이크로서비스 아키텍처로 분리하는 과정에서 SOLID 원칙을 어떻게 가이드라인으로 삼을 수 있는가? [8-10]
- 인터페이스 분리 원칙(ISP)을 적용할 때, 인터페이스를 너무 잘게 쪼개어 발생할 수 있는 파편화나 과도한 추상화를 어떻게 방지할 수 있는가? [3]
- 방대한 레거시 코드베이스에서 점진적인 리팩토링을 수행할 때, 가장 먼저 단일 책임 원칙(SRP)을 적용하기 좋은 코드 악취(Code Smell)는 어떻게 식별하는가? [4, 11]
- 객체 지향 프로그래밍에서 리스코프 치환 원칙(LSP)을 위반하는 일반적인 안티 패턴들은 무엇이며, 이를 구조적으로 어떻게 해결할 수 있는가? [3]

### Practical Application Contexts
- **Implementation:** 코드를 구현할 때 구체적인 클래스보다 인터페이스를 먼저 작성하여(Contract-first), 컴포넌트 간결합을 분리(OCP, DIP)하는 코딩 습관을 형성한다 [4].
- **System Design:** 코드가 계속해서 성장하는 라이브러리나 객체 지향 시스템을 설계할 때, 테스트 용이성과 낮은 결합도를 목표로 아키텍처의 근간으로 사용된다 [2].
- **Operation / Maintenance:** 코드의 한 부분에 변경 사항이 생기거나 버그를 수정할 때 다른 모듈에 미치는 사이드 이펙트를 줄여 유지보수의 효율성과 운영 안정성을 높인다 [1, 2].
- **Learning Path:** 복잡한 구조를 한 번에 이해하려 하기보다, 새로운 기능 추가나 버그 수정 시 '단일 책임 원칙(SRP)' 같은 가장 직관적인 원칙부터 적용하며 코드베이스의 구조를 학습해 나간다 [4].
- **My Project Relevance:** 소스에 관련 정보가 부족합니다.

### Adjacent Topics
- [[클린 아키텍처 (Clean Architecture)]]
  - 확장 방향: 비즈니스 로직을 중심에 두고 외부 프레임워크로부터 독립시키는 설계 방식으로, SOLID 원칙이 대규모 시스템 레이어 분리에 어떻게 적용되는지 확장하여 학습할 수 있다 [12, 13].
- [[계층형 아키텍처 (Layered Architecture)]]
  - 확장 방향: 시스템을 엄격한 수평 계층으로 나누고 의존성 주입을 통해 통신하는 전통적인 아키텍처 패턴과 SOLID 원칙의 결합도를 탐구할 수 있다 [6, 14].

---
*Last updated: 2026-05-02*
