단일 책임 원칙(SRP), 백엔드 코드의 복잡도를 낮추는 설계 기준과 실무 적용법

단일 책임 원칙(Single Responsibility Principle, SRP)은 하나의 클래스나 모듈이 변경되어야 하는 이유가 오직 하나여야 한다는 설계 원칙입니다. 단순히 '하나의 기능만 수행한다'는 의미를 넘어, 특정 기능의 요구사항이 변했을 때 그 변화의 영향이 다른 기능으로 번지지 않게 만드는 것이 핵심입니다.

백엔드 개발 실무에서 서비스 로직이 비대해지면 코드 한 줄을 고쳤을 뿐인데 전혀 상관없는 API에서 에러가 발생하는 상황을 자주 겪게 됩니다. 이는 대부분 하나의 클래스가 너무 많은 역할을 짊어지고 있기 때문에 발생하며, 유지보수 비용을 기하급수적으로 높이는 주범이 됩니다.

이 원칙을 제대로 이해하려면 먼저 객체지향 설계의 근간이 되는 SOLID 원칙 전반에 대한 흐름을 파악하고 있어야 합니다. SRP는 그중에서도 가장 기본이 되면서도 실무자들이 가장 빈번하게 어기게 되는 원칙이기도 합니다.

이번 글에서는 SRP가 왜 단순한 이론을 넘어 실무적인 생존 전략인지 살펴보고, 비대해진 코드를 어떤 기준으로 분리해야 하는지 구체적인 판단 지표를 정리해 보겠습니다.

단일 책임 원칙 주제를 읽기 전에 먼저 보면 좋은 대표 이미지 · 핵심 포인트: 개념, 왜 중요한지, 나쁜 구조

핵심 내용 먼저 보기

핵심 키워드 단일 책임 원칙 · 연관 검색어 단일 책임 원칙, SRP, SOLID 원칙, 백엔드 설계, 객체지향 프로그래밍

단일 책임 원칙의 본질: '하나의 기능'이 아닌 '하나의 액터'

많은 개발자가 SRP를 '함수 하나는 한 가지 일만 해야 한다'는 수준으로 오해하곤 합니다. 하지만 로버트 C. 마틴이 정의한 SRP의 본질은 '모듈은 오직 한 명의 사용자 또는 이해관계자(Actor)에 대해서만 책임져야 한다'는 것입니다. 즉, 코드를 변경해야 할 주체가 누구인지를 파악하는 것이 설계의 시작입니다.

예를 들어 결제 서비스 클래스 안에 '결제 승인' 로직과 '결제 영수증 PDF 생성' 로직이 함께 있다고 가정해 봅시다. 결제 승인 방식이 바뀌는 상황과 영수증 디자인이 바뀌는 상황은 서로 다른 부서나 요구사항에서 발생합니다. 이 두 로직이 한 클래스에 묶여 있다면, 영수증 폰트를 바꾸다가 결제 승인 로직에 버그를 심는 불상사가 생길 수 있습니다.

SRP를 지키지 않았을 때 발생하는 실무적 리스크

책임이 혼재된 코드는 테스트 코드 작성을 매우 어렵게 만듭니다. 특정 비즈니스 로직 하나를 검증하고 싶은데, 클래스 생성자에 수많은 의존성(DB, 외부 API, 메일 발송 등)이 엮여 있어 Mock 객체를 설정하는 데만 수십 줄의 코드를 써야 한다면 이미 SRP 위반을 의심해야 합니다.

또한, 코드의 재사용성이 현저히 떨어집니다. A 서비스에서 필요한 로직이 B 클래스에 들어있는데, B 클래스가 너무 많은 책임을 가지고 있어 불필요한 의존성까지 함께 끌어와야 한다면 개발자는 결국 코드를 복사해서 붙여넣는 선택을 하게 됩니다. 이는 중복 코드 양산으로 이어져 시스템 전체의 부채가 됩니다.

흔히 저지르는 실수: 모든 로직을 담고 있는 '거대 서비스(Fat Service)'

백엔드 프로젝트에서 가장 흔히 보이는 안티 패턴은 UserService나 OrderService 같은 클래스가 수천 줄에 달하는 것입니다. 사용자 가입, 비밀번호 변경, 프로필 이미지 업로드, 이메일 인증, 마케팅 수신 동의 처리가 모두 한곳에 모여 있다면 이는 전형적인 SRP 위반입니다.

이런 상황에서 운영 판단 포인트는 '변경의 주기'입니다. 이메일 템플릿은 자주 바뀌지만 가입 로직은 거의 바뀌지 않는다면, 이 둘은 반드시 분리되어야 합니다. 클래스가 커지는 것을 두려워해서는 안 됩니다. 오히려 명확한 이름을 가진 여러 개의 작은 클래스로 쪼개는 것이 시스템의 흐름을 파악하는 데 훨씬 유리합니다.

코드 분리 여부를 결정하는 판단 기준과 개선 팁

클래스를 분리할지 고민될 때는 '이 클래스의 메서드들이 같은 멤버 변수를 공유하고 있는가?'를 확인해 보세요. 만약 특정 메서드들만 일부 멤버 변수를 사용하고 있다면, 그 변수와 메서드들을 별도의 클래스로 추출할 신호입니다. 이를 응집도(Cohesion)가 높다고 표현하며, SRP를 잘 지킨 코드의 특징입니다.

실무적인 팁으로, 서비스 레이어에서 모든 일을 처리하려 하지 말고 도메인 모델(Entity)이나 별도의 컴포넌트로 책임을 넘기세요. 예를 들어 '주문 금액 계산'은 Order 엔티티 내부로, '외부 PG사 연동'은 별도의 Client 클래스로 분리하는 식입니다. 이렇게 하면 서비스 클래스는 각 객체에 메시지를 전달하는 '조율자' 역할만 수행하게 되어 코드가 훨씬 간결해집니다.

단일 책임 원칙은 단순히 코드를 예쁘게 만드는 기술이 아니라, 변화에 유연하게 대응하기 위한 생존 전략입니다. 처음부터 완벽한 설계를 하려고 애쓰기보다는, 코드를 수정할 때마다 '내가 지금 이 클래스를 고치는 이유가 무엇인가?'를 스스로 질문해 보는 습관이 중요합니다.

만약 한 클래스를 고치는 이유가 여러 부서의 요구사항 때문이라면, 그 클래스는 이미 너무 많은 짐을 지고 있는 것입니다. 작은 단위로 책임을 나누고 인터페이스를 통해 소통하게 만들면, 나중에 시스템 규모가 커지더라도 특정 부분만 떼어내어 마이크로서비스로 전환하거나 리팩토링하기가 훨씬 수월해집니다.

SRP를 실천하며 코드의 응집도를 높였다면, 다음 단계로는 객체 간의 결합도를 낮추는 '의존성 역전 원칙(DIP)'이나 '개방-폐쇄 원칙(OCP)'을 함께 살펴보는 것을 추천합니다. 설계의 원칙들이 서로 어떻게 맞물려 돌아가는지 이해할 때 비로소 단단한 백엔드 아키텍처를 구축할 수 있습니다.

자주 묻는 질문

클래스가 너무 많아지면 오히려 관리가 힘들지 않나요?

클래스 개수가 늘어나는 것보다, 하나의 클래스 내부 로직이 복잡하게 꼬여서 분석이 불가능해지는 것이 훨씬 위험합니다. 명확한 네이밍과 패키지 구조를 통해 클래스를 관리하면 복잡도는 충분히 제어 가능합니다.

어느 정도 규모일 때 클래스를 분리해야 하나요?

코드의 줄 수보다는 '변경의 이유'가 기준입니다. 서로 다른 시점에, 서로 다른 이유로 변경되어야 하는 로직들이 한곳에 있다면 코드 양과 상관없이 분리하는 것이 좋습니다.

SRP를 지키면 성능이 떨어지지는 않나요?

현대적인 컴퓨팅 환경에서 클래스 분리로 인한 성능 저하는 무시할 수 있는 수준입니다. 오히려 유지보수 실패로 인한 기술 부채와 버그 수정 비용이 훨씬 큽니다. 성능 최적화는 설계 원칙을 지킨 후 병목 지점에서 진행하는 것이 맞습니다.

---

해시태그

#단일책임원칙 #SRP #SOLID원칙 #백엔드설계 #객체지향프로그래밍 #리팩토링