Antigravity Agent
46 lines
3.8 KiB
Markdown
46 lines
3.8 KiB
Markdown
---
|
|
id: P-REINFORCE-WIKI-DEV-SRP
|
|
title: "단일 책임 원칙과 높은 응집도 (SRP)"
|
|
category: Dev
|
|
status: verified
|
|
canonical_id: ""
|
|
aliases: ["SRP", "단일 책임 원칙", "Single Responsibility Principle", "응집도", "책임 분리"]
|
|
duplicate_of: ""
|
|
source_trust_level: A
|
|
confidence_score: 1.0
|
|
tags: ["SOLID", "Design_Principles", "Clean_Code", "Refactoring", "Modularity"]
|
|
raw_sources: ["Datacollector_Export_2026-05-02"]
|
|
last_reinforced: 2026-05-02
|
|
github_commit: ""
|
|
---
|
|
|
|
# [[단일 책임 원칙과 높은 응집도 (SRP)]]
|
|
|
|
## 1. 개요
|
|
단일 책임 원칙(SRP, Single Responsibility Principle)은 "하나의 클래스는 단 하나의 책임만을 가져야 하며, 클래스가 변경되어야 하는 이유는 오직 하나뿐이어야 한다"는 설계 원칙이다. 이는 객체 지향 설계의 핵심인 응집도(Cohesion)를 극대화하고 결합도(Coupling)를 낮추어, 소프트웨어를 더 이해하기 쉽고 변경에 강하며 테스트 가능한 구조로 만드는 기초 토대가 된다.
|
|
|
|
## 2. 핵심 개념 및 판단 기준
|
|
- **변경의 이유 (Reason to Change)**: 책임이란 곧 '변경의 근거'를 의미한다. 만약 기획 부서의 요구사항 변경과 데이터베이스 관리자의 구조 변경이 동시에 한 클래스의 수정을 유발한다면, 그 클래스는 두 가지 책임을 가진 것이다.
|
|
- **응집도 (Cohesion)**: 클래스 내부의 메서드와 데이터들이 얼마나 밀접하게 관련되어 있는지의 척도. SRP를 준수할수록 응집도는 자연스럽게 높아진다.
|
|
- **관심사의 분리**: 비즈니스 로직, 데이터 영속성, UI 렌더링, 입력 검증 등 서로 다른 도메인 관심사를 명확히 구분하여 개별 클래스나 모듈로 격리.
|
|
|
|
## 3. 엔지니어링 가치
|
|
- **유지보수 안정성**: 특정 기능을 수정할 때 해당 책임만을 전담하는 클래스만 고치면 되므로, 예상치 못한 사이드 이펙트(Side Effect)가 시스템 전반으로 퍼지는 위험 차단.
|
|
- **코드 가독성 및 명확성**: 클래스의 이름과 구현 코드가 하나의 목적만을 지향하므로, 코드를 처음 읽는 개발자가 시스템의 의도를 신속하고 정확하게 파악 가능.
|
|
- **재사용성 및 테스트 용이성**: 작고 명확한 책임을 가진 클래스는 다른 컨텍스트에서 재사용하기 쉽고, 모의 객체(Mock)를 활용한 단위 테스트 작성이 매우 간편함.
|
|
|
|
## 4. 트레이드오프 및 주의사항
|
|
- **클래스 폭발 (Class Explosion)**: 원칙을 너무 잘게 적용하면 시스템에 수많은 클래스가 생성되어 전체적인 오케스트레이션(흐름)을 파악하기 위한 인지적 비용이 증가할 수 있음. 적절한 수준의 추상화와 그룹화 필요.
|
|
- **파편화된 로직**: 하나의 비즈니스 프로세스가 너무 많은 클래스에 흩어져 있으면 오히려 가독성을 해칠 수 있다. '변경의 이유'가 같은 로직은 하나로 묶는 균형 감각이 요구됨.
|
|
- **점진적 리팩토링**: 거대한 레거시 클래스를 한 번에 분해하기보다는, 새로운 요구사항이 발생하거나 버그를 수정할 때마다 책임의 경계를 확인하며 점진적으로 분리할 것.
|
|
|
|
## 5. 지식 연결 (Related)
|
|
- [[SOLID_Principles]]: SRP를 포함한 객체 지향 설계의 5대 원칙.
|
|
- [[Separation_of_Concerns]]: 시스템 전체 수준에서의 관심사 분리 철학.
|
|
- [[Clean_Code]]: 명확한 책임을 가진 코드를 작성하기 위한 실무 기법.
|
|
|
|
## 🧪 검증 상태 (Validation)
|
|
- **정보 상태**: 검증 완료 (Verified)
|
|
- **출처 신뢰도**: A
|
|
- **검토 이유**: 소프트웨어 모듈의 근본적인 단위인 클래스의 책임을 명확히 정의함으로써, 시스템의 유지보수성과 확장성을 보장하는 가장 강력한 설계 도구 정립.
|