Single Responsibility Principle

Single Responsibility Principle

Single Responsibility Principle(단일 책임 원칙, SRP) 은 SOLID 설계 원칙 중 하나로, " 클래스, 모듈, 함수 등은 오직 하나의 책임만을 가져야 하며, 단 하나의 변경 이유만을 가져야 한다 " 는 원칙이다. SRP 를 적용하면 각 클래스가 명확한 역할을 갖고, 코드의 응집도가 높아지며, 유지보수성과 테스트 용이성이 크게 향상된다. SRP 는 대규모 시스템, 마이크로서비스, 도메인 주도 설계 등 다양한 환경에서 핵심적으로 적용된다.

핵심 개념

정의 및 기본 개념

• 책임 (Responsibility): 모듈이 수행해야 하는 기능이나 역할을 의미한다.
• 단일 책임: 클래스나 모듈이 오직 하나의 기능이나 역할만을 담당해야 함
• 변경의 이유: 클래스가 변경되어야 하는 이유가 단 하나여야 함
• Actor: 변경을 요구하는 이해관계자 그룹
• 응집성 (Cohesion): 관련된 기능들이 하나의 모듈에 집중되는 정도
• 결합도 (Coupling): 모듈 간의 의존성 정도

핵심 원리

1. 분리의 원칙: 서로 다른 이유로 변경되는 기능들을 분리
2. 단일 목적: 각 구성요소는 명확하고 단일한 목적을 가져야 함
3. 변경 격리: 한 기능의 변경이 다른 기능에 영향을 주지 않아야 함

graph TD
    A[단일 책임 원칙] --> B[하나의 책임]
    A --> C[하나의 변경 이유]
    A --> D[하나의 Actor]
    
    B --> E[명확한 목적]
    B --> F[기능적 응집성]
    
    C --> G[변경 격리]
    C --> H[영향 범위 최소화]
    
    D --> I[이해관계자 분리]
    D --> J[요구사항 분할]

배경 및 필요성

발전 배경

• 1970 년대: Tom DeMarco 의 응집성 개념에서 시작
• 1979 년: Structured Analysis and System Specification 에서 응집도 원리 제시
• 2002 년: Robert C. Martin 이 SOLID 원칙의 일부로 공식화
• 2003 년: “Agile Software Development, Principles, Patterns, and Practices” 저서에서 구체화
• 2014 년: Martin 이 " 변경의 이유 " 개념을 명확히 정의

목적 및 필요성

1. 코드 복잡성 감소: 각 구성요소의 역할을 명확히 하여 이해하기 쉬운 코드 작성
2. 유지보수성 향상: 변경 사항의 영향 범위를 제한하여 안전한 수정 가능
3. 재사용성 증대: 단일 목적의 구성요소는 다른 컨텍스트에서 재사용 용이
4. 테스트 용이성: 각 구성요소를 독립적으로 테스트 가능
5. 병렬 개발: 서로 다른 팀이 독립적으로 개발 가능

주요 기능 및 역할

• 역할 분리: 각 클래스/모듈이 한 가지 책임만 담당.
• 변경 영향 최소화: 한 책임의 변경이 다른 책임에 영향을 주지 않음.
• 응집도 향상: 관련 기능이 한 곳에 모여 있어 코드 관리가 쉬움.

설계 차원의 역할

• 아키텍처 정리: 시스템을 논리적이고 일관성 있는 구조로 조직화
• 의존성 관리: 모듈 간 불필요한 의존성 제거
• 인터페이스 정의: 명확한 책임 경계를 통한 인터페이스 설계

개발 차원의 역할

• 코드 품질 향상: 가독성, 유지보수성, 확장성 개선
• 버그 감소: 변경 사항의 부작용 최소화
• 개발 효율성: 명확한 책임 분할로 개발자 간 협업 개선

특징

설계적 특징

• 단순성: 각 구성요소가 하나의 명확한 목적을 가짐
• 예측가능성: 변경의 영향 범위를 예측하기 쉬움
• 모듈성: 독립적으로 동작하는 구성요소들의 조합

구현적 특징

• 높은 응집성: 관련 기능들이 하나의 모듈에 집중
• 낮은 결합도: 모듈 간 의존성 최소화
• 명확한 인터페이스: 각 모듈의 역할이 인터페이스를 통해 명확히 드러남

핵심 원칙

SRP 는 모듈이 하나의 책임만을 가지도록 설계하여, 변경의 이유를 하나로 제한한다. 이를 통해 코드의 응집도를 높이고, 변경에 따른 영향을 최소화한다.

기본 원칙

1. 단일 책임: 클래스는 오직 하나의 책임만을 가져야 함
2. 단일 변경 이유: 클래스가 변경되는 이유는 오직 하나여야 함
3. 단일 Actor: 클래스는 하나의 이해관계자 그룹에만 책임을 져야 함

적용 원칙

flowchart TD
    A[요구사항 분석] --> B{여러 책임 존재?}
    B -->|Yes| C[책임 분리]
    B -->|No| D[단일 책임 유지]
    
    C --> E[별도 클래스 생성]
    E --> F[인터페이스 정의]
    F --> G[의존성 주입]
    
    D --> H[구현 완료]
    G --> H

작동 원리

식별 과정

1. 책임 식별: 클래스나 모듈이 수행하는 모든 기능 나열
2. 변경 이유 분석: 각 기능이 변경될 수 있는 이유 파악
3. Actor 구분: 변경을 요구하는 이해관계자 그룹 식별
4. 분리 결정: 서로 다른 이유로 변경되는 기능들을 별도 모듈로 분리

리팩토링 과정

sequenceDiagram
    participant Dev as 개발자
    participant Code as 기존 코드
    participant Analysis as 분석
    participant Refactor as 리팩토링

    Dev->>Code: 다중 책임 클래스 식별
    Code->>Analysis: 책임 분석
    Analysis->>Analysis: 변경 이유 파악
    Analysis->>Refactor: Extract Class 적용
    Refactor->>Refactor: 인터페이스 정의
    Refactor->>Dev: 단일 책임 클래스들

아키텍처 다이어그램

classDiagram
    class UserController {
        +createUser(request)
        +updateUser(id, request)
        +deleteUser(id)
    }
    
    class UserService {
        +createUser(userData)
        +updateUser(id, userData)
        +deleteUser(id)
    }
    
    class UserRepository {
        +save(user)
        +findById(id)
        +delete(id)
    }
    
    class UserValidator {
        +validateUserData(userData)
        +validateEmail(email)
    }
    
    class EmailService {
        +sendWelcomeEmail(user)
        +sendNotification(user, message)
    }
    
    UserController --> UserService : uses
    UserService --> UserRepository : uses
    UserService --> UserValidator : uses
    UserService --> EmailService : uses

구현 기법

Extract Class 기법

• 정의: 하나의 클래스에서 여러 책임을 별도 클래스로 분리
• 구성: 원본 클래스, 추출될 클래스, 인터페이스
• 목적: 과도한 책임을 가진 클래스를 단일 책임으로 분리
• 예시: 사용자 관리 클래스에서 이메일 발송 기능을 별도 클래스로 분리

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

// 기존 - SRP 위반
class UserManager {
    public void createUser(String name, String email) {
        // 사용자 생성 로직
        User user = new User(name, email);
        database.save(user);
        
        // 이메일 발송 로직 (다른 책임)
        Email email = new Email();
        email.setTo(user.getEmail());
        email.setSubject("환영합니다!");
        emailSender.send(email);
    }
}

// 개선 - SRP 적용
class UserService {
    private EmailService emailService;
    
    public void createUser(String name, String email) {
        User user = new User(name, email);
        database.save(user);
        emailService.sendWelcomeEmail(user);
    }
}

class EmailService {
    public void sendWelcomeEmail(User user) {
        Email email = new Email();
        email.setTo(user.getEmail());
        email.setSubject("환영합니다!");
        emailSender.send(email);
    }
}

Extract Method 기법

• 정의: 큰 메소드에서 특정 기능을 별도 메소드로 분리
• 구성: 원본 메소드, 추출된 메소드들, 주 로직
• 목적: 메소드 레벨에서 단일 책임 원칙 적용
• 예시: 복잡한 계산 로직을 여러 단계로 분리

Interface Segregation 기법

• 정의: 큰 인터페이스를 작은 단위로 분리
• 구성: 원본 인터페이스, 분리된 인터페이스들, 구현체
• 목적: 클라이언트가 필요하지 않은 기능에 의존하지 않도록 함
• 예시: 다기능 프린터 인터페이스를 출력, 스캔, 팩스 인터페이스로 분리

Dependency Injection 기법

• 정의: 의존성을 외부에서 주입받아 결합도 감소
• 구성: 의존성 인터페이스, 구현체, 주입 메커니즘
• 목적: 구성요소 간 느슨한 결합으로 단일 책임 유지
• 예시: 서비스 클래스에 리포지토리 인터페이스를 주입

장점과 단점

단점 해결 방법

과도한 분할 방지

• 비즈니스 도메인 기준으로 적절한 추상화 수준 유지
• KISS(Keep It Simple, Stupid) 원칙과의 균형 고려

성능 최적화

• 필요시 구성요소 간 통신 최소화
• 캐싱, 배치 처리 등 성능 개선 기법 적용

명확한 가이드라인 수립

• 팀 내 일관된 책임 정의 기준 마련
• 코드 리뷰를 통한 지속적인 개선

도전 과제

분류 기준에 따른 종류 및 유형

실무 적용 예시

활용 사례

사례 1: 전자상거래 주문 시스템

시나리오: 온라인 쇼핑몰의 주문 처리 시스템을 SRP 를 적용하여 설계하는 사례

시스템 구성:

graph TB
    A[OrderController] --> B[OrderService]
    B --> C[PaymentService]
    B --> D[InventoryService]
    B --> E[ShippingService]
    B --> F[NotificationService]
    
    C --> G[PaymentGateway]
    D --> H[InventoryRepository]
    E --> I[ShippingProvider]
    F --> J[EmailService]
    F --> K[SMSService]
    
    H --> L[(Database)]
    G --> M[외부 결제 API]
    I --> N[배송업체 API]

각 구성요소의 단일 책임:

• OrderController: HTTP 요청/응답 처리만 담당
• OrderService: 주문 비즈니스 로직 조율
• PaymentService: 결제 처리 로직
• InventoryService: 재고 관리
• ShippingService: 배송 처리
• NotificationService: 알림 발송

Workflow:

sequenceDiagram
    participant Client
    participant OrderController
    participant OrderService
    participant PaymentService
    participant InventoryService
    participant ShippingService
    participant NotificationService

    Client->>OrderController: 주문 요청
    OrderController->>OrderService: 주문 처리 요청
    OrderService->>InventoryService: 재고 확인
    InventoryService-->>OrderService: 재고 상태
    OrderService->>PaymentService: 결제 처리
    PaymentService-->>OrderService: 결제 결과
    OrderService->>ShippingService: 배송 요청
    ShippingService-->>OrderService: 배송 정보
    OrderService->>NotificationService: 알림 발송
    NotificationService-->>OrderService: 발송 완료
    OrderService-->>OrderController: 처리 결과
    OrderController-->>Client: 응답

SRP 적용 효과:

• 유지보수성: 결제 로직 변경 시 PaymentService 만 수정
• 확장성: 새로운 결제 수단 추가 시 기존 코드 영향 없음
• 테스트 용이성: 각 서비스를 독립적으로 테스트 가능
• 재사용성: NotificationService 를 다른 기능에서도 활용 가능

사례 2: 온라인 학습 플랫폼

시나리오: 온라인 학습 플랫폼

시스템 구성:

• CourseManager: 강좌 생성, 수정, 삭제 (→ SRP 위반)
• SRP 준수 시 다음과 같이 분리:
  • CourseCreator
  • CourseEditor
  • CourseDeleter

시스템 아키텍처 다이어그램

classDiagram
  class CourseCreator {
    +createCourse()
  }

  class CourseEditor {
    +editCourse()
  }

  class CourseDeleter {
    +deleteCourse()
  }

  class Frontend {
    +handleUserInput()
  }

  Frontend --> CourseCreator
  Frontend --> CourseEditor
  Frontend --> CourseDeleter

Workflow:

1. 사용자가 강좌 생성 요청
2. CourseCreator 가 요청 처리
3. 강좌 편집 요청 시 CourseEditor 가 처리
4. 삭제 요청은 CourseDeleter 가 처리

역할 분리 효과:

• 코드 테스트가 용이해짐
• 요구사항 변경에 유연하게 대응
• DevOps 관점에서 기능별 CI/CD 적용 가능

실무 적용 고려사항 및 권장사항

최적화 고려사항 및 주의할 점

SRP 관련 주요 문제와 해결 방안

주제와 관련하여 주목할 내용

심화학습 및 연계 주제

용어 정리

핵심 개념

객체지향 설계 원칙

설계 및 구현 기법

디자인 패턴

아키텍처 및 구조

테스트 및 개발 방법론

참고 및 출처

• 단일 책임 원칙 위키피디아
• SOLID 원칙 설명 - DigitalOcean
• 단일 책임 원칙 예제 - GeeksforGeeks
• SOLID 원칙 실생활 예제 - GeeksforGeeks
• Java에서의 단일 책임 원칙 - Baeldung
• SOLID Principles Explained with Examples - Baeldung
• SRP 상세 설명 - HackerNoon
• 단일 책임 원칙 정의 - TechTarget
• SRP 클린 코드 패턴 - αlphαrithms
• SRP 실무 적용 - LambdaTest
• Java 적용 방법 - TheServerSide
• Refactoring Guru: SRP
• Clean Architecture by Robert C. Martin - O’Reilly
• Microsoft Learn - Clean Architecture
• Microsoft: SRP 적용 가이드
• SOLID 원칙 - SRP(단일 책임 원칙) - 티스토리
• SOLID 원칙 1 - 단일 책임 원칙(SRP) - Steady Coding
• SOLID 원칙 - 단일 책임 원칙(SRP) - Velog
• SOLID SRP: 단일 책임 원칙 - Dream Coding