SRP

정의

SOLID 중 S에 해당한다.

SRP는 Single Responsibility Principle의 약자로, 직역하면 단일 책임 원칙이다.

 

여기서 말하는 책임은 무엇일까?

이 책임이라는 단어가 애매해서, 프로그래머가 모든 모듈이 하나의 일을 해야 한다는 의미로 받아들이기가 쉽다.

 

필자가 생각하기에 Responsibility라는 단어보다는 Persona^[각주:1]라는 단어가 더 어울린다고 생각한다.

즉, 하나의 모듈은 하나의 Persona에 의해 좌지우지돼야 한다.

 

SRP의 창시자 "Robert C. Martin"은 책임을 변경의 이유로 정의했다. 즉, 단일 책임 원칙은 변경의 이유가 반드시 하나이어야 한다.

Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to be changed (e.g. rewritten).^[각주:2]

위반 사례

이해를 돕기 위해 예시를 들겠다.
어떤 클래스의 페르소나가 두 명일 때 발생하는 문제를 살펴보자.
페르소나는 각각 "사내 대출 담당자", "급여 담당자"이고, 클래스는 대충 Bank라고 해보자.

type Bank interface {
	RaiseSalary()
	InterestOnBorrowedMoney()
}

급여 담당자는 직원의 급여를 1년마다 3% 고정으로 올렸고,
사내 대출 담당자는 1년마다 빌린 돈에 이자를 계속 3%씩 부과했다고 해보자.
그리고, 해당 함수들은 돈에서 3%를 증가시키기 위해서 Inflate이라는 함수를 사용한다고 쳐보자.

 

어느 날 사장이 사내 대출 담당자에게 가서, 너무 많은 돈을 빌리는 사람에게는 차등으로 좀 더 많은 이자율을 부과하라는 지시를 내린다면? 사내 대출 담당자는 이를 개발자에게 알리고, 개발자는 Inflate이라는 함수를 건드렸다면?

어느 날 갑자기, 직원들의 월급이 뻥튀기되고, 정말 즐겁겠다.

 

개발자가 꼼꼼한 사람이거나, Bank를 직접 개발한 사람이라면 이런 실수를 하지 않겠지만, 자신이 개발한 것이 아니라면 생각보다 이런 실수는 자주 발생한다.
만약에 정말 만약에, 마이크로 서비스로 두 책임이 분리되어 있는데, Inflate 함수가 유틸리티로서 존재하고, 두 마이크로 서비스가 이를 참조한다면, 이건 정말 찾기도 힘들다.
이런 일이 발생하지 않도록 애초부터 Inflate 함수가 두 개로 나누어져 있었다면, 이야기가 달랐을 것이다.

마치며...

다른 사람이 짠 코드를 또 다른 사람이 고치는 경우는 정말 비일비재하다. 버그를 고쳤더니, 새로운 버그가 생긴다!

---

1. 특정 인물 혹은 특정 집단 정도로 생각하면 된다. [본문으로]
2. https://en.wikipedia.org/wiki/Single-responsibility_principle [본문으로]