단일 책임 원칙(SRP), 백엔드 코드의 복잡성을 줄이는 설계의 시작점

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

백엔드 개발을 하다 보면 처음에는 깔끔했던 코드가 시간이 흐를수록 비대해지는 경험을 자주 하게 됩니다. 사용자 가입 로직 안에 이메일 발송, 포인트 지급, 로그 기록까지 섞여 들어가면 나중에 이메일 서비스 업체만 바꾸려 해도 전체 회원 가입 로직을 건드려야 하는 상황이 발생합니다. 이것이 바로 SRP가 깨졌을 때 나타나는 전형적인 증상입니다.

이 원칙을 제대로 이해하려면 객체지향 설계의 5대 원칙인 SOLID에 대한 전반적인 흐름을 먼저 파악하는 것이 좋습니다. SRP는 그중에서도 가장 기초가 되며, 이후에 다룰 개방-폐쇄 원칙이나 의존성 역전 원칙을 실천하기 위한 필수 전제 조건이기도 합니다.

많은 개발자가 SRP를 이론적으로는 알지만, 실무에서 '어디까지 쪼개야 하는가'에 대해서는 늘 고민에 빠집니다. 무조건 클래스를 잘게 나누는 것이 정답은 아니기에, 이번 글에서는 실무적인 판단 기준과 함께 SRP가 왜 유지보수의 생명선이 되는지 살펴보겠습니다.

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

핵심 내용 먼저 보기

핵심 키워드 단일 책임 원칙 · 연관 검색어 단일 책임 원칙, SRP, 객체지향 설계, 백엔드 유지보수, 클린 코드

하나의 클래스가 하나의 일만 해야 하는 진짜 이유

SRP에서 말하는 '책임'은 '변경을 위한 이유'와 같습니다. 만약 어떤 클래스가 사용자 정보 관리와 데이터베이스 연결 설정을 동시에 담당하고 있다면, DB 스키마가 바뀔 때도 이 클래스를 수정해야 하고 사용자 인증 정책이 바뀔 때도 이 클래스를 수정해야 합니다. 변경의 이유가 두 가지가 되는 셈입니다.

이렇게 책임이 섞여 있으면 한 쪽을 수정하다가 전혀 상관없는 다른 기능에서 버그가 발생할 확률이 높습니다. 이를 '취약성'이라고 부르는데, SRP는 코드 간의 결합도를 낮추고 응집도를 높여서 시스템의 한 부분을 수정하더라도 전체 시스템이 흔들리지 않게 만드는 방어막 역할을 합니다.

'만능 클래스'가 서비스 운영을 방해하는 과정

실무에서 흔히 발생하는 실수는 UserService 같은 클래스에 모든 비즈니스 로직을 몰아넣는 것입니다. 처음에는 편리해 보이지만, 시간이 지나면 이 클래스는 수천 줄에 달하는 '신(God) 객체'가 됩니다. 이 상태에서는 코드 한 줄을 고칠 때마다 영향 범위를 파악하기 위해 수많은 테스트 케이스를 다시 확인해야 합니다.

예를 들어, 결제 로직이 포함된 주문 서비스에서 영수증 PDF 생성 로직까지 직접 구현하고 있다면 어떨까요? PDF 라이브러리 버전을 올리는 단순한 작업이 결제 시스템 전체의 안정성을 위협하는 리스크로 돌변합니다. 책임이 분리되지 않은 코드는 개발자의 심리적 부담을 높이고, 결국 배포 주기를 늦추는 결과를 초래합니다.

코드를 분리해야 할 시점을 판단하는 기준

그렇다면 언제 클래스를 나누어야 할까요? 가장 명확한 신호는 '특정 기능을 수정할 때 관련 없는 변수나 메서드가 자꾸 눈에 밟힐 때'입니다. 클래스 내부의 메서드들이 서로 다른 인스턴스 변수 그룹을 사용하고 있다면, 이는 이미 해당 클래스가 여러 책임을 수행하고 있다는 강력한 증거입니다.

또한, 협업 과정에서 서로 다른 이유로 같은 파일을 동시에 수정하여 컨플릭트(Conflict)가 자주 발생한다면 SRP 위반을 의심해 봐야 합니다. 한 명은 로깅 형식을 바꾸고 있고, 다른 한 명은 비즈니스 계산 로직을 바꾸고 있는데 같은 파일을 수정 중이라면 그 클래스는 너무 많은 일을 하고 있는 것입니다.

SRP를 지켰을 때 얻는 테스트와 협업의 이점

단일 책임 원칙을 준수한 코드는 테스트 코드를 작성하기가 압도적으로 쉽습니다. 의존성이 적고 역할이 명확하기 때문에 가짜 객체(Mock)를 복잡하게 설정할 필요 없이 특정 기능만 떼어내어 검증할 수 있습니다. 이는 곧 테스트 커버리지의 상승과 소프트웨어 품질 향상으로 이어집니다.

결과적으로 SRP는 코드의 가독성을 높여줍니다. 클래스 이름만 보고도 이 코드가 무슨 일을 하는지, 어디를 수정해야 할지 명확해지기 때문입니다. 새로운 팀원이 합류했을 때 수천 줄짜리 클래스 파일을 분석하게 하는 대신, 명확하게 분리된 작은 모듈들을 보여주는 것이 훨씬 효율적인 온보딩 방법이 됩니다.

단일 책임 원칙은 단순히 코드를 예쁘게 만드는 규칙이 아니라, 변화에 유연하게 대응하기 위한 생존 전략입니다. 모든 코드를 처음부터 완벽하게 분리할 수는 없지만, 비대해진 클래스를 발견할 때마다 조금씩 책임을 덜어내는 리팩토링 습관이 중요합니다.

이후에는 SRP를 통해 잘 분리된 객체들이 어떻게 서로 소통해야 하는지를 다루는 '의존성 역전 원칙(DIP)'이나, 기존 코드를 수정하지 않고도 기능을 확장하는 '개방-폐쇄 원칙(OCP)'에 대해서도 함께 학습해 보시길 권장합니다. 설계 원칙들은 서로 유기적으로 연결되어 있어 하나씩 적용하다 보면 자연스럽게 클린 아키텍처에 가까워질 수 있습니다.

객체지향 설계의 기초를 다졌다면, 다음 단계로는 도메인 주도 설계(DDD)에서 말하는 바운디드 컨텍스트 개념을 살펴보는 것도 좋습니다. SRP가 클래스 수준의 책임 분리라면, DDD는 서비스 수준에서의 책임 분리를 다루기 때문에 백엔드 설계의 시야를 한층 넓혀줄 것입니다.

자주 묻는 질문

클래스 하나에 메서드가 하나만 있어야 SRP인가요?

아닙니다. SRP는 메서드의 개수가 아니라 '변경의 이유'에 집중합니다. 하나의 책임을 수행하기 위해 여러 개의 보조 메서드가 필요할 수 있으며, 이들이 논리적으로 하나의 목적(이유)을 위해 뭉쳐 있다면 SRP를 준수한 것입니다.

클래스를 너무 많이 나누면 관리가 더 힘들지 않나요?

단기적으로는 파일 개수가 늘어나 복잡해 보일 수 있지만, 장기적으로는 수정 범위가 명확해져 유지보수 비용이 줄어듭니다. 다만, 너무 사소한 기능까지 분리하여 응집도를 떨어뜨리는 '파편화'는 경계해야 합니다.

이미 비대해진 레거시 코드에 SRP를 어떻게 적용하나요?

한 번에 모든 것을 분리하려 하지 마세요. 새로운 요구사항이 생겨 해당 코드를 수정해야 할 때, 수정이 필요한 부분만 별도의 클래스로 추출(Extract Class)하는 것부터 시작하는 것이 가장 안전합니다.

---

해시태그

#단일책임원칙 #SRP #객체지향설계 #백엔드유지보수 #클린코드 #리팩토링