Apr 3, 2026

SRP 가이드: 단일 책임 원칙은 왜 중요한가

SOLID를 처음 접하면 가장 먼저 많이 듣는 원칙이 SRP, 즉 단일 책임 원칙입니다. 이름만 보면 간단해 보이지만, 실제로는 “이 클래스가 지금 너무 많은 이유로 바뀌고 있지 않은가”를 묻는 꽤 중요한 질문입니다.

이 글에서는 아래 내용을 정리합니다.

SRP가 무엇인지
왜 중요한지
“책임이 하나”라는 말이 실제로 무엇을 뜻하는지
입문자가 어떤 식으로 적용해보면 좋은지

핵심은 SRP는 기능 수를 하나로 줄이라는 뜻이 아니라, 변경 이유가 뒤섞이지 않도록 책임 경계를 나누자는 원칙이라는 점입니다.

SRP란 무엇인가

SRP는 보통 “하나의 클래스는 하나의 책임만 가져야 한다”라고 설명됩니다.

하지만 실무적으로는 이렇게 이해하는 편이 더 좋습니다.

하나의 클래스가 너무 많은 이유로 수정되고 있지 않은가

즉, 책임은 “메서드 개수”보다 “변경 이유”와 더 가깝습니다.

왜 중요한가

한 클래스가 여러 책임을 동시에 가지면:

수정할 때 영향 범위가 커지고
테스트가 복잡해지며
재사용이 어려워지고
코드 읽기가 힘들어집니다

예를 들어 주문 처리 클래스가:

주문 계산
DB 저장
이메일 발송
로그 기록

까지 다 하고 있다면, 서로 다른 이유의 변경이 한곳에 몰리게 됩니다.

”책임이 하나”라는 말은 무슨 뜻일까

입문자에게 가장 헷갈리는 부분이 여기입니다. 책임이 하나라는 것은 “메서드가 하나”라는 뜻이 아닙니다.

오히려:

같은 종류의 변경은 함께 모으고
다른 종류의 변경은 분리하자

는 감각에 더 가깝습니다.

즉, 관련 있는 일은 같이 두되, 성격이 다른 일은 억지로 한 클래스에 몰지 않는 것이 중요합니다.

SRP를 어기면 어떤 일이 생길까

자주 보이는 문제는 아래와 같습니다.

하나를 고치려다 다른 기능이 깨짐
테스트가 너무 많은 외부 의존성을 필요로 함
클래스 이름은 단순한데 실제 역할은 지나치게 큼

이런 신호가 보이면 SRP 관점에서 한 번 나눠볼 가치가 큽니다.

입문자는 어떻게 적용해보면 좋을까

코드를 볼 때 아래 질문이 도움이 됩니다.

이 클래스는 왜 바뀌는가
서로 다른 이유의 변경이 같이 들어오는가
외부 시스템 역할까지 한 클래스가 다 떠안고 있지 않은가

이 질문만 습관적으로 해도 SRP 감각이 꽤 빨리 생깁니다.

자주 하는 오해

1. 클래스를 최대한 잘게 쪼개면 SRP다

너무 쪼개면 오히려 구조가 복잡해질 수 있습니다.

2. 메서드가 많으면 무조건 SRP를 어긴다

메서드 수보다 변경 이유가 핵심입니다.

3. SRP는 작은 프로젝트에는 필요 없다

작은 코드에서도 책임이 섞이면 금방 읽기 어려워질 수 있습니다.

FAQ

Q. SRP는 어떻게 판단하나

변경 이유가 하나로 모이는지 보는 것이 가장 좋습니다.

Q. 역할이 비슷하면 같이 둬도 되나

그렇습니다. 중요한 것은 변경 이유와 책임 성격이 자연스럽게 묶이는가입니다.

Q. 입문자는 어디부터 분리해보면 좋을까

DB 접근, 알림 발송, 비즈니스 규칙처럼 성격이 다른 부분부터 나눠보는 것이 좋습니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.