단일 책임 원칙편집자 확인

단일 책임 원칙에서 말하는 '책임'은 '변경의 이유'로 정의된다. 이는 로버트 C. 마틴이 제시한 개념으로, 하나의 클래스나 모듈이 변경되어야 하는 이유는 오직 하나뿐이어야 한다는 의미이다. 여기서 '변경의 이유'란 사용자 요구사항이나 비즈니스 규칙의 변화와 같이, 해당 코드를 수정하게 만드는 외부적 압력을 가리킨다.

예를 들어, 어떤 클래스가 영수증을 출력하는 로직과 데이터베이스에 저장하는 로직을 모두 포함한다면, 이 클래스는 출력 형식 변경과 저장 방식 변경이라는 두 가지 서로 다른 이유로 수정될 수 있다. 따라서 이 클래스는 두 가지 책임을 지고 있으며, 단일 책임 원칙을 위반한다고 볼 수 있다. 책임을 올바르게 분리하면, 출력 형식이 바뀔 때는 출력 담당 클래스만, 저장 방식이 바뀔 때는 저장 담당 클래스만 수정하면 된다.

이 원칙은 객체지향 설계의 응집도와 깊은 관련이 있다. 하나의 책임은 높은 응집도를 가진 기능의 집합으로 이어진다. 반면 여러 책임이 한데 모이면 결합도가 높아지고, 변경이 다른 부분에 미치는 영향이 커져 시스템이 취약해진다. 따라서 '책임의 정의'는 단순히 기능을 나누는 것을 넘어, 변경에 대한 영향을 최소화하는 설계의 단위를 규정한다.

단일 책임 원칙에서 '변경의 이유'는 '책임'을 정의하는 핵심 기준이다. 이 관점에서, 하나의 클래스나 모듈은 변경을 유발하는 단 하나의 '액터'[1]만을 위해 존재해야 한다. 여기서 '액터'는 해당 코드를 변경하도록 요구할 수 있는 사람이나 사용자 그룹을 의미한다.

이 원칙은 단순히 클래스가 한 가지 일만 해야 한다는 기술적 설명보다 더 깊은 의미를 지닌다. 서로 다른 액터가 동일한 클래스를 변경하도록 요구한다면, 그 클래스는 여러 책임을 지고 있는 것이다. 예를 들어, 하나의 클래스가 데이터베이스 연결 로직과 비즈니스 규칙 계산 로직을 모두 처리한다면, 이 클래스는 데이터베이스 관리자와 비즈니스 분석가라는 두 액터의 변경 요구에 모두 영향을 받게 된다. 한 액터의 요구로 인한 변경이 다른 액터와 무관한 코드에 영향을 미칠 수 있으며, 이는 예상치 못한 버그와 불필요한 재테스트를 초래한다.

따라서 변경의 이유를 분리하는 것은 설계의 안정성을 높인다. 아래 표는 단일 책임 원칙을 준수하는 경우와 위반하는 경우를 변경의 이유 측면에서 비교한다.

결론적으로, 단일 책임 원칙은 '변경의 이유'를 기준으로 책임의 경계를 설정하도록 유도한다. 이는 궁극적으로 시스템의 각 구성 요소가 독립적으로 진화할 수 있는 기반을 마련해 준다.

단일 책임 원칙을 준수하면 클래스나 모듈의 변경 이유가 하나로 제한되므로, 해당 컴포넌트를 수정해야 할 가능성이 줄어든다. 이는 시스템의 전반적인 유지보수 비용을 낮추는 직접적인 효과를 가져온다. 변경이 필요한 경우, 수정 범위가 명확하게 한정되어 관련 코드를 빠르게 찾고 안전하게 변경할 수 있다.

또한, 단일 책임 원칙을 적용하면 각 컴포넌트의 목적과 역할이 명확해진다. 이는 코드를 이해하고 파악하는 데 걸리는 시간을 단축시킨다. 유지보수 담당자는 복잡하게 얽힌 로직을 해석하기보다는, 잘 정의된 책임을 가진 작은 단위들을 조합하여 시스템을 이해할 수 있게 된다.

아래 표는 단일 책임 원칙 적용 전후의 유지보수 특성을 비교한 것이다.

결과적으로, 이 원칙은 소프트웨어의 생명주기 전반에 걸쳐 변경에 대한 두려움을 줄이고, 보다 안정적이고 예측 가능한 방식으로 시스템을 진화시키는 토대를 제공한다. 이는 장기적인 프로젝트의 성공에 중요한 기여를 한다.

단일 책임 원칙을 준수하는 클래스는 하나의 명확한 책임만을 가지므로, 그 목적과 기능이 명료해집니다. 이는 코드의 가독성을 크게 향상시킵니다. 다른 개발자가 코드를 파악할 때, 클래스가 무엇을 하는지 쉽게 이해할 수 있고, 이는 협업과 유지보수 과정을 원활하게 만듭니다. 복잡한 로직이 여러 책임으로 뒤엉키지 않고 단일 모듈에 캡슐화되면, 시스템의 전반적인 구조를 이해하기도 훨씬 수월해집니다.

이러한 명확성은 자연스럽게 재사용성 증가로 이어집니다. 하나의 잘 정의된 책임을 가진 클래스는 다른 맥락에서도 독립적으로 사용될 가능성이 높습니다. 예를 들어, 데이터를 특정 형식으로 변환하는 책임만 가진 클래스는 보고서 생성, 파일 저장, 네트워크 전송 등 다양한 시나리오에서 재사용될 수 있습니다. 반면, 여러 책임이 결합된 클래스는 특정 컨텍스트에 너무 강하게 결합되어 있어, 다른 곳에서 사용하려면 불필요한 의존성을 함께 가져오거나 수정해야 하는 경우가 많습니다.

결과적으로, 가독성과 재사용성은 서로 시너지 효과를 냅니다. 읽기 쉬운 코드는 재사용 가능한 구성 요소를 식별하기 쉽게 만들고, 재사용 가능한 컴포넌트는 시스템 전반에 걸쳐 일관된 패턴으로 사용되어 코드베이스의 일관성과 가독성을 더욱 높입니다. 이는 소프트웨어의 응집도를 높이고 결합도를 낮추는 핵심 메커니즘으로 작동합니다.

단일 책임 원칙을 준수하는 클래스는 하나의 명확한 책임만을 가지므로, 해당 책임과 관련된 동작만을 테스트하면 된다. 이는 테스트 대상의 범위가 명확히 제한됨을 의미하며, 결과적으로 테스트 케이스를 작성하고 유지보수하는 것이 훨씬 간단해진다.

테스트의 용이성은 주로 낮은 결합도에서 비롯된다. 하나의 클래스가 여러 책임을 가질 경우, 그 클래스를 테스트하려면 다양한 의존성들을 모두 설정해야 하며, 이는 테스트를 복잡하고 불안정하게 만든다. 반면 SRP를 적용하면 각 클래스가 독립적이므로, 특정 기능을 검증하기 위해 필요한 의존성의 수가 최소화된다. 이는 단위 테스트를 더 빠르고 격리된 상태에서 실행할 수 있게 한다.

또한, 책임이 분리되면 테스트의 코드 커버리지를 측정하고 분석하기도 쉬워진다. 하나의 거대한 클래스에 대한 높은 커버리지를 달성하는 것은 어렵지만, 여러 개의 작고 집중된 클래스들에 대한 커버리지는 각각 명확한 기준으로 측정할 수 있다. 이는 테스트되지 않은 코드 경로를 발견하고 테스트 전략을 수립하는 데 도움을 준다.

갓 클래스는 단일 책임 원칙을 심각하게 위반하는 대표적인 안티패턴이다. 이는 하나의 클래스가 너무 많은 책임을 지니고 있어, 시스템의 광범위한 부분을 과도하게 제어하거나 알고 있는 상태를 의미한다. 마치 모든 것을 아는 신과 같은 존재처럼 동작하기 때문에 '갓 클래스'라는 이름이 붙었다. 이러한 클래스는 보통 수백에서 수천 줄에 이르는 방대한 코드를 포함하며, 다양한 이유로 변경될 가능성이 매우 높다.

갓 클래스의 주요 징후는 다음과 같다. 클래스가 여러 개의 서로 다른 비즈니스 로직이나 도메인 개념을 처리한다. 수많은 인스턴스 변수와 메서드를 보유하고 있으며, 그 중 상당수는 서로 밀접하게 연관되어 있지 않다. 다른 많은 클래스에 대한 의존성이 높고, 반대로 시스템 내 많은 다른 클래스들이 이 갓 클래스에 의존한다. 결과적으로 결합도가 극도로 높아지고, 응집도는 매우 낮아진다.

이러한 클래스는 여러 가지 문제를 초래한다. 한 부분의 작은 변경이 예상치 못한 다른 부분에 영향을 미칠 수 있어 유지보수가 어렵다. 클래스의 규모가 크고 복잡하여 새로운 개발자가 코드를 이해하는 데 많은 시간이 소요된다. 단위 테스트 작성이 거의 불가능해지며, 테스트 케이스 자체가 복잡해진다. 코드 재사용이 사실상 불가능하고, 시스템의 다른 부분을 분리하여 개별적으로 발전시키는 것도 어렵게 만든다.

갓 클래스를 해결하기 위해서는 리팩토링을 통해 책임을 분리해야 한다. 관련된 데이터와 메서드를 식별하여 새로운 클래스로 추출하는 클래스 추출 기법이 핵심이다. 큰 메서드를 더 작고 명확한 책임을 가진 메서드들로 나누는 메서드 추출도 함께 진행된다. 이를 통해 하나의 거대한 클래스는 여러 개의 작고 응집된 클래스들로 분해되며, 각 클래스는 명확한 단일 책임을 가지게 된다.

단일 책임 원칙을 위반하는 클래스는 종종 결합도가 과도하게 높아지는 문제를 야기한다. 이는 하나의 클래스가 여러 책임을 지니게 되면서, 서로 다른 이유로 변경되어야 하는 요소들이 강하게 연결되어 있기 때문이다. 이러한 클래스는 시스템 내 다른 모듈들과 불필요하게 많은 의존 관계를 형성하게 되며, 이는 시스템의 한 부분을 수정했을 때 예상치 못한 다른 부분에 영향을 미치는 파급 효과를 초래한다.

과도한 결합도의 구체적인 징후로는 클래스가 다수의 다른 클래스에 대한 인스턴스를 직접 생성하거나 관리하는 경우, 또는 하나의 메서드 내에서 서로 관련 없는 여러 외부 시스템(예: 데이터베이스 접근, 네트워크 통신, 로깅, 비즈니스 로직 처리)을 동시에 조작하는 경우를 들 수 있다. 또한, 클래스의 인터페이스가 지나치게 복잡하고 다양한 목적의 메서드로 구성되어 있는 것도 결합도가 높아질 수 있는 신호이다.

이러한 높은 결합도는 다음과 같은 실질적인 문제를 발생시킨다.

• 변경의 어려움: 한 책임 영역의 요구사항 변경이 다른 책임 영역의 코드 수정을 강제한다.

• 재사용성 저하: 여러 책임이 뒤엉킨 클래스는 특정 기능만을 필요로 하는 다른 컨텍스트에서 사용하기 어렵다.

• 테스트 복잡성 증가: 단위 테스트를 작성할 때 테스트 대상 클래스와 결합된 모든 의존성을 설정해야 하므로 테스트가 번거로워진다.

따라서 단일 책임 원칙을 준수하여 각 클래스의 책임을 명확히 분리하는 것은 결합도를 낮추는 핵심적인 방법이다. 책임이 분리되면 각 클래스는 자신의 핵심 기능에만 집중하고, 다른 클래스와는 명확하게 정의된 인터페이스를 통해 최소한으로 소통하게 되어, 시스템 전체의 유연성과 견고함이 향상된다.

책임 분리 기법은 단일 책임 원칙을 준수하기 위해 하나의 클래스나 모듈이 지닌 여러 책임을 식별하고, 각각을 독립적인 구성 요소로 분리하는 방법을 포괄한다. 가장 기본적인 접근법은 변경의 이유를 분석하는 것이다. 클래스를 수정해야 하는 이유가 둘 이상이라면, 이는 서로 다른 책임이 혼재되어 있을 가능성이 높다. 각 변경 이유에 해당하는 코드를 별도의 클래스로 추출하는 것이 일반적인 첫 단계이다.

흔히 사용되는 구체적인 기법으로는 추상화와 인터페이스 분리가 있다. 공통된 동작은 추상 클래스나 인터페이스로 정의하고, 구체적인 책임은 이를 구현하는 개별 클래스에 위임한다. 또한, 의존성 주입을 활용하면 강한 결합 없이 분리된 책임들을 유연하게 조합할 수 있다. 예를 들어, 데이터 저장과 보고서 생성이라는 두 책임이 한 클래스에 있다면, 저장 로직은 리포지토리 패턴 클래스로, 생성 로직은 별도의 서비스 클래스로 분리할 수 있다.

다음 표는 몇 가지 대표적인 책임 분리 기법과 그 설명을 정리한 것이다.

이러한 기법들을 적용할 때는 분리의 적정 수준을 고려해야 한다. 지나치게 많은 작은 클래스는 시스템을 복잡하게 만들 수 있으며, 응집도를 유지하면서 자연스러운 경계를 찾는 것이 중요하다. 최종 목표는 각 모듈이 변경, 이해, 재사용되는 데 있어 명확한 이유 하나만을 가지도록 하는 것이다.

단일 책임 원칙을 위반한 코드를 개선하기 위해 적용할 수 있는 일반적인 리팩토링 패턴이 존재한다. 이러한 패턴들은 하나의 클래스가 지나치게 많은 책임을 지고 있을 때, 그 책임을 명확히 분리하여 새로운 클래스나 모듈로 이관하는 방법을 제시한다.

주요 패턴으로는 추출 클래스, 추출 메서드, 이동 메서드 등이 있다. 추출 클래스는 하나의 클래스에서 두 개 이상의 책임을 수행하는 부분을 찾아, 그 부분을 새로운 클래스로 분리하는 기법이다. 예를 들어, Order 클래스가 주문 정보 관리와 동시에 영수증 출력 및 이메일 발송 로직을 포함한다면, InvoicePrinter와 EmailService라는 별도의 클래스를 추출할 수 있다. 추출 메서드는 하나의 긴 메서드 내에서 명확히 구분되는 작업을 별도의 메서드로 분리하여 가독성을 높이고, 이후 클래스 분리의 후보가 될 수 있도록 한다. 이동 메서드는 한 클래스의 메서드가 다른 클래스의 데이터를 더 많이 사용한다면, 그 메서드를 데이터가 있는 클래스로 옮기는 패턴이다.

보다 고수준의 아키텍처 패턴도 적용될 수 있다. 전략 패턴은 알고리즘 군을 정의하고 각각을 캡슐화하여 상호 교환 가능하도록 만든다. 이는 하나의 클래스가 여러 방식으로 데이터를 처리하거나 출력하는 책임을 질 때, 각 방식을 별도의 전략 클래스로 분리하는 데 유용하다. 퍼사드 패턴은 복잡한 서브시스템에 대한 단순화된 인터페이스를 제공하는 패턴으로, 기존의 복잡하고 다중 책임을 가진 클래스들을 재구성한 후, 그들과 상호작용하는 단일 진입점을 제공할 때 사용된다. 이는 클래스를 분리한 후에도 사용 편의성을 유지하는 데 도움을 준다.

단일 책임 원칙은 SOLID 원칙의 첫 번째 글자 'S'를 차지하며, 이 다섯 가지 객체 지향 설계 원칙의 기초를 형성한다. 다른 원칙들이 효과적으로 작동하기 위한 전제 조건 역할을 한다. 만약 하나의 클래스나 모듈이 여러 책임을 지니면, 그 자체로 응집도가 낮아지고 변경이 빈번해져 다른 원칙들을 적용하기 어려운 환경이 조성된다.

다른 SOLID 원칙과의 구체적인 관계는 다음과 같다.

• 개방-폐쇄 원칙 (OCP): 단일 책임 원칙이 잘 지켜진 클래스는 하나의 변경 이유만을 가지므로, 그 변경을 수용하기 위한 확장(개방)이 명확해지고 기존 코드 수정(폐쇄)을 최소화할 수 있다.

• 리스코프 치환 원칙 (LSP): 단일하고 명확한 책임을 가진 클래스는 행위의 계약이 분명해져, 하위 클래스가 상위 클래스를 올바르게 대체할 수 있는 가능성이 높아진다.

• 인터페이스 분리 원칙 (ISP): 이 원칙은 인터페이스 수준에서의 단일 책임 원칙이라 볼 수 있다. 클라이언트가 필요로 하지 않은 메서드에 의존하지 않도록 큰 인터페이스를 구체적이고 작은 인터페이스로 분리하는 것이 핵심이다.

• 의존관계 역전 원칙 (DIP): 고수준 모듈이 저수준 모듈에 의존하지 않도록 하려면, 각 모듈의 책임이 명확히 분리되어 있어야 추상화를 통한 의존성 역전이 효과적으로 이루어진다.

따라서 단일 책임 원칙은 SOLID의 출발점이자 토대이다. 이 원칙을 무시하고 복합적인 책임을 가진 모듈을 만들면, 나머지 원칙들을 적용하려는 시도 자체가 복잡해지거나 무의미해질 수 있다.

단일 책임 원칙과 개방-폐쇄 원칙은 SOLID 원칙을 구성하는 두 가지 핵심 원칙으로, 서로 밀접하게 연관되어 있다. 단일 책임 원칙은 하나의 클래스가 변경되어야 할 이유를 하나만 가지도록 하는 데 초점을 맞춘다. 이는 결과적으로 각 클래스가 하나의 잘 정의된 책임만을 수행하게 함으로써, 시스템의 구성 요소를 더 작고 응집력 높은 단위로 분리한다.

이러한 분리는 개방-폐쇄 원칙을 효과적으로 적용하기 위한 필수적인 토대를 마련한다. 개방-폐쇄 원칙은 소프트웨어 개체(클래스, 모듈, 함수 등)가 확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다는 것을 의미한다. 단일 책임 원칙을 준수하여 각 책임이 고립된 클래스로 분리되면, 새로운 기능을 추가할 때 기존 클래스를 수정하기보다는 새로운 클래스를 생성하거나 기존 클래스를 확장하는 방식으로 변경을 수용하기가 훨씬 쉬워진다. 예를 들어, 보고서를 생성하는 책임과 보고서를 출력하는 책임이 하나의 클래스에 섞여 있다면, 출력 형식(PDF, HTML 등)을 추가하려 할 때 보고서 생성 로직까지 수정할 위험이 있다. 단일 책임 원칙에 따라 이 두 책임을 분리하면, 새로운 출력 형식을 추가할 때는 출력 전용 클래스를 확장하기만 하면 되므로, 기존 보고서 생성 클래스는 수정하지 않아도 된다[2].

따라서 단일 책임 원칙은 개방-폐쇄 원칙을 실현 가능하게 하는 선행 조건 또는 수단으로 작용한다고 볼 수 있다. 책임이 명확히 분리되지 않은 모놀리식 클래스는 새로운 요구사항이 발생했을 때 해당 클래스 자체를 직접 수정할 가능성이 높으며, 이는 개방-폐쇄 원칙의 '수정에 닫혀 있다'는 조건을 위반하게 만든다. 반면, 잘 정의된 단일 책임을 가진 클래스들은 서로 느슨하게 결합되어 있어, 시스템의 다른 부분에 영향을 최소화하면서 기능을 확장하는 것이 용이해진다. 이 두 원칙의 조화는 변경에 유연하고 안정적인 소프트웨어 아키텍처를 구축하는 데 중요한 기여를 한다.