단일 책임 원칙(SRP, Single Responsibility Principle)은 "하나의 클래스는 단 하나의 책임만을 가져야 하며, 클래스가 변경되어야 하는 이유는 오직 하나뿐이어야 한다"는 설계 원칙이다. 이는 객체 지향 설계의 핵심인 응집도(Cohesion)를 극대화하고 결합도(Coupling)를 낮추어, 소프트웨어를 더 이해하기 쉽고 변경에 강하며 테스트 가능한 구조로 만드는 기초 토대가 된다.
2. 핵심 개념 및 판단 기준
변경의 이유 (Reason to Change): 책임이란 곧 '변경의 근거'를 의미한다. 만약 기획 부서의 요구사항 변경과 데이터베이스 관리자의 구조 변경이 동시에 한 클래스의 수정을 유발한다면, 그 클래스는 두 가지 책임을 가진 것이다.
응집도 (Cohesion): 클래스 내부의 메서드와 데이터들이 얼마나 밀접하게 관련되어 있는지의 척도. SRP를 준수할수록 응집도는 자연스럽게 높아진다.
관심사의 분리: 비즈니스 로직, 데이터 영속성, UI 렌더링, 입력 검증 등 서로 다른 도메인 관심사를 명확히 구분하여 개별 클래스나 모듈로 격리.
3. 엔지니어링 가치
유지보수 안정성: 특정 기능을 수정할 때 해당 책임만을 전담하는 클래스만 고치면 되므로, 예상치 못한 사이드 이펙트(Side Effect)가 시스템 전반으로 퍼지는 위험 차단.
코드 가독성 및 명확성: 클래스의 이름과 구현 코드가 하나의 목적만을 지향하므로, 코드를 처음 읽는 개발자가 시스템의 의도를 신속하고 정확하게 파악 가능.
재사용성 및 테스트 용이성: 작고 명확한 책임을 가진 클래스는 다른 컨텍스트에서 재사용하기 쉽고, 모의 객체(Mock)를 활용한 단위 테스트 작성이 매우 간편함.
4. 트레이드오프 및 주의사항
클래스 폭발 (Class Explosion): 원칙을 너무 잘게 적용하면 시스템에 수많은 클래스가 생성되어 전체적인 오케스트레이션(흐름)을 파악하기 위한 인지적 비용이 증가할 수 있음. 적절한 수준의 추상화와 그룹화 필요.
파편화된 로직: 하나의 비즈니스 프로세스가 너무 많은 클래스에 흩어져 있으면 오히려 가독성을 해칠 수 있다. '변경의 이유'가 같은 로직은 하나로 묶는 균형 감각이 요구됨.
점진적 리팩토링: 거대한 레거시 클래스를 한 번에 분해하기보다는, 새로운 요구사항이 발생하거나 버그를 수정할 때마다 책임의 경계를 확인하며 점진적으로 분리할 것.
Antigravity Agent