SOLID Principles

📌 Brief Summary

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

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

📖 Core Content

SOLID 원칙은 코드 리뷰와 시스템 설계의 무결성을 평가하는 핵심 기준입니다.

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

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

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

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

🔗 Knowledge Connections

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

[관계 유형 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
처리 이유: 신규 지식 체계 도입

11 KiB Raw Blame History