SRP - 단일 책임 원칙 (Single Responsibility Principle)

1. 단일 책임 원칙(SRP)란?

• "클래스는 단 하나의 책임만 가져야 한다."
• 여기서 말하는 '책임'이란 변경의 이유(Reason to Change)이다.
• 즉, 클래스는 오직 하나의 변경 이유만 가져야 한다는 것이 핵심이다.

2. SRP가 필요한 이유

 

📌 SRP가 지켜지지 않으면?

• 하나의 클래스가 너무 많은 역할을 담당 -> 높은 결합도
• 한 기능이 바뀌면, 관련 없는 기능도 영향을 받음
• 유지보수가 어렵고, 테스트도 어려워짐

📌 SRP가 지켜지면?

• 클래스가 하나의 역할만 담당 -> 낮은 결합도, 높은 응집도
• 변경이 국소화되어 예측 가능
• 테스트 단위가 작아지고 명확함

❌ 3. SRP 위반 예제

public class ReportManager {
    public void generateReport() {
        // 1. 보고서 생성
    }

    public void saveToDatabase() {
        // 2. DB 저장
    }

    public void sendEmail() {
        // 3. 이메일 전송
    }
}

 

▶ 문제점

• 3가지 책임(생성/저장/전송)이 한 클래스 몰려 있음
• 메일 전송 로직이 바뀌어도, 보고서 생성과 DB 저장 로직에 영향

✅ 4. SRP 적용 예제 (역할 분리)

public class ReportGenerator {
    public Report generate() { ... }
}

public class ReportRepository {
    public void save(Report report) { ... }
}

public class ReportSender {
    public void send(Report report) { ... }
}

public class ReportService {
    private final ReportGenerator generator;
    private final ReportRepository repository;
    private final ReportSender sender;

    public void processReport() {
        Report report = generator.generate();
        repository.save(report);
        sender.send(report);
    }
}

 

▶ 개선 포인트

• 클래스마다 단일 책임에 집중
• 변경이 발생하더라도 각 클래스만 수정하면 됨
• 재사용성 증가, 테스트 용이, 유지보수 용이

5. 실무에서 자주 보는 SRP 위반 사례

위반 코드 예	문제
Controller에 비즈니스 로직, DB 호출, 응답 생성까지 모두 있음	Controller가 너무 많은 책임을 가짐
Service 클래스 하나에 DB 로직 + API 호출 + 파일 처리	SRP 위반, 테스트 어렵고 유지보수 지옥

 

6. 실무에서 SRP를 지키는 방법

• 클래스와 메서드 이름이 그리고(and)를 포함하면 SRP 위반 의심
• 비즈니스 로직은 Service, DB 로직은 Repository, 외부 호출은 Client로 분리
• 인터페이스 단위로 책임을 쪼개고 의존성 주입(DI)으로 유연하게 연결

 

✅ 마무리 요약

• SRP는 클래스가 오직 하나의 변경 이유만 가지게 하는 설계 원칙
• 기능이 추가되거나 바뀌더라도 영향을 최소화 할 수 있다
• 클래스가 작고 명확한 역할을 가지면 유지보수성과 테스트가 비약적으로 향상 됨
• SRP를 잘 지키는 구조는 결국 확장에 강한 설게로 이어진다.

🔜 다음 포스팅에서는 "OCP - 계방/패쇄 원칙 : 확장에는 열려 있고, 변경에는 닫혀 있어야 한다." 라는 제목으로 포스팅 할 예정이다.

• if-else 지옥에서 벗어나는 방법
• 새로운 요구사항이 들어와도 기존 코드는 건드리지 않는 설계
• 실무에서 전략 패턴과 함께 쓰이는 이유