안정성:패키지 결합도의 원칙

Photo by Scott Webb on Unsplash

패키지 설계의 아키텍쳐에 작용하는 힘은 기술적이기도 하고, 정치적이기도 하며, 쉽게 변화하는 힘이기도 하다.

어쩌면, 로버트.C 마틴은 위 문구를 절실하게 이야기 하고 싶었던 것일수도 있다는 생각을 했다. 책을 읽으면 읽을수록, 기술적인 관점에서의 아키텍쳐와, 정치적으로, 그리거 빠르게 변화되는 요구사항은 언제나 우리의 아키텍쳐의 변경을 강요하게 만든다고 생각합니다.

로버트 마틴의 클린 소프트웨어의 책 내용을 발췌하여, 정리 후 저의 내용과 함께 적어내렸습니다.

들어가기

  이번에는 패키지의 결합도와 관련된 법칙 3가지에 대해서 알아볼 예정입니다. 이 부분을 읽으면서, 느꼈던 것은 내가 유지보수 하고 있는 서비스의 경우에 충분히 적용해볼수 있고, 아래 3가지 원칙을 지키기 위한 행위를 잘하고 있는가? 에 대해서 되돌아보게 되는 내용들입니다. 아마도 엔터프라이즈급 프로젝트라면 아래 3가지 원칙이 큰 도움이 되지 않을까 싶습니다.

1. 의존 관계 비순환 원칙(Acyclic Dependencies Principle) - ADP

 패키지 의존성 그래프에서 순환을 허용하지 말라.

 책에서는 '다음 날 아침 증후군' 이라고 부르는 현상을 설명합니다. 이 현상은 어떤 것이냐면, 여러 패키지가 서로 의존되어 결합도가 높을 경우, 어떤 기능을 완성해 놓고 다음 날 출근했을 때- 완성되었던 그 기능이 정상적으로 동작되지 않는 현상을 말합니다. 거대한 프로젝트 경우, 의존 관계가 섞여 있어 이러한 문제가 더 많이 일어 날 수 있음을 암시합니다.

이런 문제를 해결하기 위해 의존 관계 비순환 원칙(ADP) 에 대해서 설명합니다. 

의존 관계 비순환 원칙의 개념은 사실 간단하다고 생각합니다. 패키지 간의 의존성에 순환 구조를 만들지 않는 것. 

그러나, 이것도 어디까지나 이론적인 얘기일 뿐, 제가 운영하는 다우오피스의 경우에도 이 문제를 알고 있지만, 해결하지 못하는 경우가 많았습니다. 이유는, 엔터프라이즈급 코드에서는 의존성 한 부분을 제거하는 것은 또 다른 사이드 이펙트를 야기할 수 있기 때문에, 더욱 철저해져야 하기 때문에- 해결하지 못하는 경우가 있습니다.

 책에서는 2가지 방법으로 의존 관계 순환을 없애는 방식에 대해 소개합니다.

1.  의존 관계의 방향을 역전 시킴으로써 순환을 끊는 방법

2. 새로운 패키지를 중간에 두어 순환을 끊는 방법

 이 두 가지 방식에 대해서는 오브젝트책에 6장 내용을 참고하면 좋습니다. 이 부분에 대해서 이전에 따로 내용을 요약한 것이 있어 공유드립니다. 

github.com/LenKIM/object-book/tree/master/object6

LenKIM/object-book

  그러나, 위 2번째 방식은 위험할 수 있습니다. 새로운 패키지를 만든다는 것은, 다시말해 패키지 구성을 변경한다는 것과 같은 의미입니다. 이렇게 될 경우 또다른 의존성이 의도치 않게 발생하는 것이고 이는 의존 관계 구조가 성장하는 것이다 라고 책에서 이야기하고 있습니다.

2. 안정된 의존 관계 원칙(Stable Dependencies Principle) - SDP

 의존은 안정적인 쪽으로 향해야 한다.

 저는 개인적으로 SDP, SAP 가 상당히 흥미로웠습니다. 의존성을 수치로 표현함으로써, 객관적인 자료를 만든다는 부분에서 말이죠. SDP를 설명하려다 먼저 저의 생각을 말해버렸네요.

 SDP ? 책에서 말하길, 설계는 완전히 정적일 수 없다고 합니다. 설계는 계속 유지보수하려면 어느 정도의 변동성도 필요하고, 공통 폐쇄 원칙을 지킴으로써 SDP를 달성할 수 있는데, 안정된 의존 관계 원칙을 잘 유지한다면, 특정 변화에 쉽게 반응할 수 있는 패키지를 만들 수 있다고 합니다.
 예를 들어, 쉽게 바뀔 것이라고 예상되는 패키지들이 바뀌기 어려운 패키지들의 의존 대상이 되어서는 안되는 것과 같습니다. 
 책에서 안정성을 측정하는 방법이 나오는데, 책에서 나오는 설명보다, 참고자료에 있는 우아한 형제들 기술 블로그에 나온 내용을 참고하는 것을 권장합니다. 실제 동작하는 코드에서 보여줌으로써 더욱 와닿았습니다.

3. 안정된 추상화 원칙(Stable Abstractions Principle) - SAP

 패키지는 자신이 안정적인 만큼 추상적이기도 해야 한다.

 안정된 추상화 원칙이란, 안정성과 추상성 사이의 관계를 정합니다. 이 원칙에 따르면, 안정적인 패키지는 그 안정성 때문에 확장이 불가능하지 않도록 추상적이기도 해야 합니다. 거꾸로, 이 원칙에 따르면 불안정한 패키지는 구체적이어야 하는데, 그 발안정성이 그 패키지 안의 구체적인 코드가 쉽게 변경될 수 있도록 허용하기 때문입니다.

 따라서, 어떤 패키지가 안정적이라면 확장할 수 있도록 추상 클래스들로 구성되어야 합니다. 확장이 가능한 안정적인 패키지는 유연하며, 따라서 설계를 지나치게 제약하지 않습니다.

 위 내용은 클린 소프트웨어에서 가져온 내용이며, 더욱 이야기 해보면, SAP와 SDP를 합쳐 놓으면 DIP의 패키지판이 된다고 합니다. SDP는 의존 관계의 방향이 안전성의 증가방향과 같아야 한다고 말하고, SAP는 안정성이란 추상성을 내포한다고 말하기 때문입니다. 따라서 의존 관계는 추상성의 방향으로 흘러가야 한다고 합니다. 

 하지만 DIP는 클래스르 대상으로 하는 원칙입니다. 클래스가 대상이면 흑백이 분명한데, 클래스는 추상 클래스이거나 아니거나 둘 중 하나이기 때문입니다. SDP와 SAP의 조합은 패키지가 대상이고, 패키지가 부분적으로 추상적이나 부분적으로 안정적인 것도 허용합니다.

참고자료

woowabros.github.io/study/2018/03/05/sdp-sap.html

안정된 의존관계 원칙과 안정된 추상화 원칙에 대하여 - 우아한형제들 기술 블로그