[객체 지향] SRP의 진정한 의미

저번주 우아한 테크코스 프리코스 2주 차 피드백에서 이러한 피드백을 받았습니다

한 함수가 한 가지 기능만 담당하게 한다

그리고, 현재 읽고 있는 ‘클린 아키텍처’ 책에서 다음과 같은 내용이 있었습니다.

‘SRP(Single-Responsibility Principle)는 ‘한 함수가 한 가지 기능만을 담당하는 것과는 다른 법칙이다. 이는 함수형 프로그래밍의 원칙’

그리고 이 책을 통해서 ‘SRP ≠ 한 함수가 한 가지 기능만 담당하게 한다’ 라는 것을 이해할 수 있었습니다. 그 부분을 공유하려고 이 글을 적어봅니다!

❓SRP의 진정한 의미

SRP의 정의는 다음과 같습니다. ‘단일 모듈은 변경의 이유가 하나, 오직 하나 뿐이어야 한다.’ 이 문장에서 부터 ‘함수’와는 거리가 있다는 사실이 느껴지시나요?

‘클린 아키텍처’ 에서는 SRP의 정의를 조금 더 쉽게 풀어서 설명하는데요, ‘하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다’ 라고 말합니다.

그러면 여기서 말하는 ‘모듈’은 무엇일까요?

‘모듈’이란 파일 하나가 될 수 있지만, 그보단 함수와 데이터 구조로 구성된 응집된 집합을 의미합니다. 자바스크립트를 사용하신 분들이라면 ESmodule 시스템을 통해 이 ‘모듈’이라는 것에 익숙하신 분들이 만들 것이라 생각합니다.

그렇다면 ‘액터’는 무엇일까요?

‘액터’란 해당 변경을 요청하는 한 명 이상의 사람들을 뜻하는 것입니다.

그러면 다시 한 번 SRP의 의미를 풀어서 적어볼까요?

하나의 ‘함수의 응집체’는 하나의, 오직 하나의 ‘요청자’에 대해서만 책임져야 한다.

저는 여기서 들었던 생각은, SRP라는 것 역시 코드를 빌드 해 나가는 방법이 아니라, 추상화 단계, 즉 설계의 방법이구나! 라는 것입니다.

❓SRP가 필요한 이유

‘클린 아키텍처’에서는 이 SRP의 의미를 정확히 알지 못했을 때의 상황을 예시로 들어주는데요, 제가 하던 실수를 그대로 보여주더라구요🤣

그 예시를 간략화 하여 보여드리겠습니다.

하나의 회사에서 여러개의 브랜드를 관리하는 시스템이 있다고 가정해 봅시다.

‘A 주얼리 브랜드’ 라는 액터가 있구요, ‘B 의류 브랜드’라는 액터가 각각 존재합니다.

A브랜드의 마진률은 3할이어서, 마진을 구하는 로직은 수익률 * 0.3 이구요, B브랜드역시 마진률은 3할이어서, 마진을 구하는 로직은 수익률 * 0.3 인 상황을 가정해 봅시다.

이 때 마진을 구해주는 로직 자체가 다른 점이 없다는 것을 알아 차린 개발자가 이를 ‘중복’이라 생각하여 다음과 같이 리팩토링을 하였습니다

이렇게 되면 코드가 줄어들겠죠. 하지만 이것이 바로 SRP를 어긴 시스템이라는 것입니다. 이 때의 문제 상황은 다음과 같습니다.

❗B 의류 브랜드의 마진률이 4할이 되었을 때.

B 의류 브랜드에 속한 개발자가 B 의류 브랜드의 요구 사항의 변경으로 인하여 로직을 변경하였다고 합시다. 그렇게 된다면 ‘A 주얼리 브랜드’ 에서는 마진률이 변경되지도 않았는데, 영문도 모른채 언젠가 부터 마진이 이상하게 찍히게 되는 버그가 발생하겠죠. 그러니 다음과 같은 상황으로 이어져야 합니다.

A 브랜드와 B 브랜드를 책임지는 각각의 로직이 존재해야 하는 것이죠. 이것이 바로 SRP의 본질이라 할 수 있습니다. 아까전에 말한 SRP의 정의가 바로 이것이죠 ‘하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다’

🥲지금까지 내가 실수한 것

저는 지금까지 설계를 할 때, Validate, 유효성을 검사하는 로직을 담는 모듈을 생성했었습니다. SRP에 대해서 공부해 보니 이게 정말 잘못된 것임을 깨달았죠.

이번 우테코 프리코스의 3주차 진행중 제가 만든 유스케이스 다이어그램입니다. 여기서 아래 Validator가 보이시나요? 이 유효성 검사를 하는 로직은, Input의 여러 입력 값에 사용되는 로직입니다. 이것이 SRP 법칙을 어긴다는 것!

여기서 저는 ‘관심사의 분리’ 라는 것은, **‘개발자 중심의 관심사’**가 아닌 **‘액터 중심의 관심사’**라는 것을 깨달았습니다.

---

❗결론..!

이 부분은 단순히 SRP 뿐만 아니라 SOLID 법칙 전체에 해당되는 이야기 이기도 합니다. 의존성에 대한 이야기를 담고 있기도 하고, Open, Close에 대한 이야기를 담고 있기도 하죠. 결국 이런 객체 지향이라는 것은 ‘추상화’라는 이야기가 아닐까요?

객체 지향의 여러 원칙들은 이것은 이것이고, 저것은 저것이다 라고 말할 수 있는 것처럼 나눠 져 있는 것이 아닌 듯 합니다. 많은 법칙들이 얽혀있고, 정량적이기 보다는 추상적이죠.

아무튼 좋은 아키텍트를 만들기 위해 더 노력해야겠습니다!