[Clean Architecture] 크고 작은 모든 서비스들

Date:     Updated:

카테고리:

태그:

계층과 경계

계층과 경계 쳅터에서는 책에서 앞서 설명한 의존성의 흐름을 더 자세하게 설명하는 장입니다. 앞선 포스팅에 예제가 있어, 자세한 설명은 생략합니다. 이번 포스팅에서는 결론만 한번 더 강조합니다.

해당 챕터에서는 어떤 게임의 구조를 가져와서, 경계를 나누지 않을때 발생할 수 있는 문제점과 경계를 나누며, 이 문제를 해결하는 과정을 서술하였습니다. 여기서 알 수 있는 점은 아키텍처 경계가 어디에나 존재한다는 사실입니다. 따라서 우리는 아키텍처 경계가 언제 필요한지를 신중하게 파악해내야 합니다. 또한 우리는 이런 경계를 제대로 구현하려면, 비용이 많이 든다는 사실도 인지하고 있어야 합니다.

이와 동시에 이러한 경계가 무시되었다면 나중에 다시 추가하는 비용이 크다는 사실도 알아야 합니다. 포괄적인 테스트 스위트가 존재하고 리팩터링으로 단련되어 있더라도 마찬가지 입니다. (특정 모듈이 추가되거나 수정될 때 마다 수정이 일어나기 때문)

그렇다면 우리는 어떻게 해야 할까요? 정답은 정말 모호합니다.

YAGNI(You Arent Going To Need It) 이라는 원칙이 있습니다. 해당 원칙은 나중에 벌어질 일을 너무 지레짐작해서 코드에 반영하지 말라는 철학을 가졌습니다. 실제로, 오버엔지니어링이 언더엔지니어링보다 문제가 더 많이 발생하는 경우가 많다는 사실도 해당 원칙을 뒷받침 합니다.

하지만, 아이러니하게도 해당 원칙을 너무 철저하게 지키면, 나중에 확장을 위해 구조를 바꿀 때, 큰 비용과 위험을 감수해야 합니다.

바로 이것입니다. 소프트웨어 아키텍트는 미래를 내다볼 수 있어야 합니다. 현명하게 미래를 추축하여 비용을 산정하고, 어디에 경계를 둘지, 그리고 완벽하게 구현할 경계는 무엇일지와 부분적으로 구현할 경계와 무시할 경계는 무엇인지를 결정해야만 합니다.

다행이도 이는 일회성 결정은 아니며, 시스템이 발전해나가면서 계속 관찰을 합니다. 그러다가 구조가 망가질 조짐이 보이면, 해당 경계를 구현하는 비용과 그걸 무시해서 생기는 비용을 계산하여 후자가 높다면 경계를 구현하는 방식으로 개선해야 합니다.

즉, 처음부터 완벽한 구조는 없으며 끊임없이 구조를 지켜보며 개선해나가야 하는 끈기가 필요합니다.

크고 작은 모든 서비스들

MSA(마이크로 서비스 아키텍쳐)는 최근 많은 인기를 끌고 있습니다. 그 이유는 다음과 같습니다.

  • 서비스를 사용하면 상호 결합이 철저하게 분리되는 것처럼 보인다.
  • 서비스를 사용하면 개발과 배포 독립성을 지원하는 것처럼 보인다.

이것들은 일부만 맞는 말입니다. 왜냐하면, 실제 서비스들은 그렇게 간단하지 않기 때문입니다. 간단한 서비스를 만드는 경우라면 위 장점들이 다 맞을 수 있지만, 서비스가 복잡해지고, 각 서비스간의 소통이 많아질수록, 서로에 대한 관심도가 높아져 결합이 강해지기 때문입니다. 이러한 문제를 횡단 관심사 문제라고 합니다. 아래의 구조는 횡단 관심사 문제를 그림으로 표현한 것입니다. 모든 서비스들이 서로 연결되어 있어 독립적으로 개발, 배포, 유지가 불가능합니다.

야옹이 문제

그렇다면 이를 어떻게 개선할 수 있을까요? 바로 다형성을 이용하여 해결합니다. 앞서 책에서 계속 강조하였듯, 컴포넌트 기반 아키텍처를 통해 해결 가능합니다.

위 그림을 보면, 앞서 책에서 계속 강조하였던 의존관계 법칙을 준수하는 컴포넌트들로 구성되어 있습니다. 새로운 기능이 추가되면, jar / gem / dll 등을 시스템이 추가하고 런타임에 동적으로 로드하면 됩니다.

이 전략을 따르더라도, 결국 TaxiUI 와 같은 사용자 인터페이스들은 수정이 필요합니다. 하지만 그외의 것들은 수정할 필요가 없다는 강력한 장점을 지니고 있습니다. 다시말해, OCP(개방 폐쇄 원칙)을 준수하게 됩니다.

결국, 서비스는 시스템의 확장성과 개발 가능성 측면에서 유용하지만, 그 자체로는 아키텍처적으로 그리 중요한 요소는 아닙니다. 서비스 내부에 그어진 경계와 경계를 넘나드는 의존성에 의해 정해집니다. 어떤 방식으로 서로 통신을 하던, 결국 중요한것은 어떻게 경계를 나눌것인가를 알려주는 챕터였습니다.

Clean Architecture 카테고리 내 다른 글 보러가기

댓글 남기기