[OOP] 'The Single Responsibility Principle' by Robert C. Martin 번역

원글: https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

 

📌 번역이 틀릴 수 있으며, 자의적으로 불필요하게 여겨지는 부분은 제외했습니다.

 

본문

1972년, David L. Parnas는 <On the Criteria To Be Used in Decomposing Systems into Modules> 논문을 출간했다. 논문의 마지막에서 그는 다음과 같은 결론을 내린다.

우리는 플로우차트를 기반으로 시스템을 모듈로 분해하는 과정을 시작하는 것이 잘못되었다고 주장해왔다. 대신 어렵거나 변경될 가능성이 있는 설계 결정 목록으로부터 시작할 것을 제안한다. 각 모듈은 다른 모듈로부터 그러한 결정을 숨기도록 설계되어야 한다.

나는 마지막 두 문장에 특히 공감한다. Parnas는 모듈이 변경 가능성을 기반으로 분리되어야 한다고 말한다.

 

2년이 지나고, Edsger Dijkstra는 <On the role of scientific thought> 논문을 썼으며 그 안에서 관심사의 분리라는 용어를 소개한다. 1970년대 및 80년대에는 소프트웨어 아키텍처의 원칙에 대해 활발하게 의논되던 시기이다. 구조적 프로그래밍과 설계는 엄청난 인기를 끌었다. 그 당시 결합도와 응집도이라는 개념은 Larry Constantine에 의해 소개되었고, 많은 다른 개발자들에 의해 발전되었다.

 

1990년대 후반에, 나는 이러한 개념들을 하나의 원칙으로 통합하고 싶었다. 이것이 The Single Responsibility Principle(SRP, 단일 책임 원칙)이다.

 

SRP는 소프트웨어 모듈이 각각 오직 하나의 변경해야할 이유를 가져야 한다고 말한다. 이것은 Parnas의 주장과도 맞물리는 좋은 원칙으로 보이나, 하나의 의문을 야기한다. "무엇이 변경의 이유를 정의하는가?"

 

누군가는 버그 수정이 변경의 이유로 간주되는지 궁금해한다. 다른 누군가는 리팩토링이 변경의 이유가 되는 지 궁금해한다. 이는 "변경할 이유"와 "책임"을 묶어 설명할 수 있다.

 

확실히, 코드는 버그 수정이나 리팩토링에 대한 책임을 지지 않는다. 그것들은 프로그램이 아닌 개발자의 책임이다. 그러면 이러한 상황에서 프로그램이 가진 책임은 무엇인가? 다시 얘기하자면, "프로그램의 설계는 누구에게 응답해야 하는가?"

 

일반적인 비즈니스 조직을 떠올려보자. 꼭대기에는 CEO가 있다. CEO에게 보고하는 것은 C-레벨의 임원들(CFO, COO, CTO...)이다. CFO는 회사의 재정을 조절해야 할 책임이 있다. COO는 회사의 운영을 관리해야 할 책임이 있다. 그리고 CTO는 회사의 기술적 인프라와 개발에 책임이 있다.

 

이 상황을 자바 코드로 나타내보자.

public class Employee {
    public Money calculatePay();
    public void save();
    public String reportHours();
}

• calculatePay 메서드는 특정 직원의 급여를 얼마나 지급할지 그 사람의 계약, 상태, 근무 시간 등에 따라 결정하는 알고리즘을 구현한다.
• save 메서드는 Employee 객체에 의해 관리되는 데이터를 회사의 데이터베이스에 저장한다.
• reportHours 메서드는 직원들이 적절한 근무 시간 동안 일하고 보상 또한 적절하게 받는지 확인하기 위해 사용하는 보고서에 추가될 문자열을 반환한다.

CEO에게 보고하는 C-레벨의 임원들 중 누가 calculatePay 메서드의 행동을 명시할 책임이 있는가? 이 메서드가 심각하게 잘못 명시되어 있으면 해고될 임원이 누구인가? 당연히 CFO이다. 회사 직원들의 급여를 명시하는 것은 금융적인 책임이다. 만약 모든 직원들이 CFO 부서에 속한 누군가가 calculatePay 메서드에 잘못 명시한 규칙으로 인해 두 배의 연봉을 받았다면, CFO는 해고될 것이다.

 

다른 C-레벨 임원은 reportHours 메서드에서 반환되는 문자열의 내용과 형식을 명시할 책임이 있다. 해당 임원은 감사원과 검토자를 관리하며, 이것은 운영 책임이다. 따라서 보고서에 심각하게 잘못 명시된 내용이 있다면 COO는 해고될 것이다.

 

마지막으로 save 메서드에 심각하게 잘못된 내용이 있으면 어떠한 C-레벨 임원이 해고될 지는 명백하다. 만약 기업 데이터베이스가 끔찍하게도 이 때문에 손상된다면 CTO는 해고될 것이다.

 

따라서 calcuatePay 메서드 내부의 알고리즘이 변경된다면, 그런 변경에 대한 요청은 CFO가 이끄는 부서에서 일어날 것이다. COO와 CTO가 이끄는 부서에서도 비슷하게 reportHours와 save 메서드의 변경에 대한 요청이 일어날 것이다.

 

이 때 SRP의 핵심으로 다가간다. 이 원칙은 사람에 관한 것이다.

 

당신은 소프트웨어 모듈을 개발할 때 변화가 일어나면 그 변화는 오직 하나의 사람, 혹은 하나의 강하게 결합된 조직에서만 일어나기를 원한다. 당신은 모듈을 조직 전체의 복잡성에서 분리시키고, 각자의 모듈이 그저 하나의 비즈니스 기능에 대한 요구에만 책임을 지도록 시스템을 설계하기를 원한다.

 

왜냐고? 우리는 CTO가 요구한 변경 사항 때문에 COO가 해고되는 일을 막고 싶기 때문이다. 우리의 고객과 매니저들 관점에서, 그들이 요청한 변경 사항과는 완전히 관계 없는 곳에서 프로그램이 고장났다는 걸 발견하는 것보다 무서운 게 없다. 만약 당신이 calculatePay 메서드를 변경하면서 우연히 reportHours 메서드를 망가트린다면, COO는 당신에게 절대로 calculatePay 메서드를 다시는 변경하지 말 것을 요구할 것이다.

 

이것은 우리가 JSP 파일에 SQL을 넣지 않는 이유다. 결과를 계산하는 모듈에 HTML 코드를 작성하지 않는 이유며, 비즈니스 규칙이 데이터베이스 스키마를 몰라야 하는 이유다. 이것이 우리가 관심사를 분리하는 이유다.

 

SRP를 다르게 정의하자면 다음과 같다.

같은 이유로 변경되는 것들을 하나로 모아라. 다른 이유로 변경될 것들을 나누어라.

당신은 이제 SRP가 그저 응집도과 결합도를 정의하는 다른 방법이라는 것을 깨달았을 것이다. 우리는 같은 이유로 인해 변경되는 것들 사이의 응집도를 높이고 싶어하며, 다른 이유로 변경되는 것들 사이의 결합도는 낮추고 싶어한다.

 

하지만 당신이 이 원칙에 대해 생각할 때, 변경되는 이유는 사람이라는 걸 기억해라. 변경을 요청하는 건 사람이다. 그리고 당신은 많은 사람들이 다른 이유들로 관심을 갖는 코드를 하나로 섞어, 그 사람들 혹은 자신을 혼란스럽게 만들고 싶지 않는다.