핵심 인사이트 (3줄 요약)
- **SRP(단일 책임 원칙)**은 클래스나 모듈이 단 하나의 변경 이유(책임)만을 가져야 한다는 객체 지향 설계의 첫 번째 원칙입니다.
- 응집도를 극대화하여 사이드 이펙트(Side Effect)를 방지하고 유지보수성을 크게 향상시킵니다.
- 데이터 접근, 비즈니스 로직, UI 출력이 한 클래스에 섞이는 '갓 클래스(God Class)' 안티 패턴을 타파하는 근본적인 해결책입니다.
Ⅰ. 개요 (Context & Background)
SRP는 소프트웨어 개발에서 가장 지키기 어렵지만 가장 중요한 원칙 중 하나입니다. 기능 추가나 요구사항 변경 시 수정해야 할 대상이 여러 곳에 분산되거나 한 곳에 집중되어 발생하는 결함의 파급(Ripple Effect)을 막기 위해, 책임을 세밀하게 분리하는 것이 핵심입니다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
클래스는 한 가지의 책임만 지며, 그 책임을 완전히 캡슐화해야 합니다.
+-------------------------------------------------------------+
| SRP Architecture Principle |
| |
| [Bad Design - God Class] |
| +--------------------+ |
| | UserAccount | -> Handles Auth, DB, and UI |
| +--------------------+ |
| |
| [Good Design - SRP] |
| +----------------+ +----------------+ +-------------+ |
| | Authenticator | | UserRepository | | UserView | |
| +----------------+ +----------------+ +-------------+ |
| (Auth Logic) (DB Operations) (UI Display) |
+-------------------------------------------------------------+
Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)
| 특성 | 단일 책임 원칙 준수 (SRP) | 단일 책임 원칙 위반 (God Class) |
|---|---|---|
| 응집도 (Cohesion) | 높음 (High) | 낮음 (Low) |
| 결합도 (Coupling) | 낮음 (Low) | 높음 (High) |
| 테스트 용이성 | 모킹(Mocking) 및 단위 테스트가 매우 쉬움 | 의존성이 복잡하여 단위 테스트 어려움 |
| 재사용성 | 모듈화가 잘 되어 재사용성 극대화 | 불필요한 기능까지 묶여 재사용 불가 |
Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)
- 책임의 범위 설정: '책임'이라는 단어는 비즈니스 도메인에 따라 유연하게 해석되어야 합니다. 과도한 분리는 클래스의 파편화(Shotgun Surgery)를 유발할 수 있으므로, 적절한 추상화 수준을 유지해야 합니다.
- 아키텍처 적용: 마이크로서비스(MSA) 설계 시 단일 책임 원칙은 서비스의 바운디드 컨텍스트(Bounded Context)를 쪼개는 가장 근본적인 척도로 작용합니다.
Ⅴ. 기대효과 및 결론 (Future & Standard)
SRP를 충실히 따르면 시스템의 복잡성이 분산되어 코드의 가독성이 높아지고, 여러 명의 개발자가 동시에 협업하더라도 머지(Merge) 충돌을 최소화할 수 있습니다. 이는 클린 코드(Clean Code)를 향한 첫걸음입니다.
📌 관련 개념 맵 (Knowledge Graph)
- 상위 개념: SOLID 원칙
- 하위 개념: 응집도(Cohesion), 결합도(Coupling)
- 연관 개념: 갓 클래스(God Class), 마이크로서비스(MSA), 파사드 패턴(Facade)
👶 어린이를 위한 3줄 비유 설명
- 요리사는 요리만, 웨이터는 서빙만, 계산원은 계산만 해야 식당이 잘 돌아가요.
- 한 사람이 모든 일을 다 하려고 하면 실수하기 쉽고 엄청 피곤해져요.
- 코드도 각자 자기 역할만 딱 하나씩 맡아서 하도록 나눠주는 것이 SRP랍니다!