클린 아키텍쳐는 아키텍쳐 패턴의 종류인가요?

제가 집필한 e-book이 출판되고 벌써 몇 주가 흘렀네요. 첫 집필으론 아주 만족스러운 결과지만, 역시 여전히 부족함을 다시금 느낍니다. 처음에 기획했던 책이 cover하는 지식이 상당히 방대했다가 차차 줄여나간 것이 그 원인이라고 생각됩니다.

 

이 글은 제 책의 초반에 설명이 부족해 아주 독자입장에서 매우 모호하다고 생각될 수 있는 부분에 대해 바로잡기 위해 작성합니다.

 

0. 클린 아키텍쳐는 아키텍쳐 패턴의 종류인가요?

 

이 질문에 대한 저의 답이 정확하다고는 할 수 없습니다. 우선 제 대답은 '네니오(Yes but no)' 입니다. 이 결론에 다다르기 전에 먼제 아키텍쳐 패턴에 대해서 생각해봅시다.

 

1. 아키텍쳐 패턴이라는게 그래서 왜 그렇게 많을까? 문제가 뭐길래?

 

우리가 모바일 앱 개발을 할때 보통 다음과 같은 작업요소들이 기본적으로 머리속에 떠오릅니다. 'UI', '비즈니스 로직', '통신'.  오케이, 그렇게 우리는 코드를 작성하지만 흔히 '스파게티 코드'라는 서로 단단하게 엉켜 알아보기도, 보수하기도 힘든 코드가 탄생하는 "문제"가 발생합니다.

이 문제를 해결하기 위해 우리는 각각의 코드들을 작성하며 하나의 앱을 만들고 이 작업이 계속 유지되어 진행될 수 있도록 아키텍쳐 패턴이라는 것을 따르도록 작성합니다. Architecture pattern은 '구조(건축)의 양식'이라는 말 그대로 소프트웨어가 조직적으로 구성되기 위해서 따라야하는 양식입니다. 간단한 예시로 가장 흔하게 이야기 되는 MVC, MVP, MVVM 등이 있죠.

 

각 아키텍쳐 패턴이 뭔지에 대한 이야기는 다른 블로그에 너무나도 자료가 많으니, 다 알고 계신다는 가정 하에 각 아키텍쳐 패턴이 어떤식으로 유저의 인풋을 처리하는 지에 초점을 맞춰서 이야기 해봅시다

 

우선 MVC와 MVP는 유저의 인풋을 각각 Controller, Presenter에 전달합니다. 그리고 각자 Model을 업데이트하면 그것을 반영할 View에 적용이 됩니다. 하지만 MVC는 View와 Controller가 아주 밀접하게 붙어있습니다. UIKit을 사용하면 이를 ViewController라고 하나로 취급되는 것을 아실겁니다. MVP는 여기서 View와 Controller를 물리적으로 떨어뜨려 놓은 것 뿐입니다.

 

여기서 MVVM은 살짝 달라집니다. 우선 MVVM에선 View와 ViewModel이 바인딩(결속)이 되어있습니다. 이 전제 위에서 이야기해보면, MVVM에서는 유저의 인풋을 ViewModel에게 전달하고, ViewModel은 Model을 업데이트하고 이가 변경되었음을 감지하면 바인딩된 View가 업데이트됩니다. '바인딩'이라는 것을 통해서 Presenter가 직접적으로 View를 참조하는 MVP 때보다 더 분리되어있죠.

 

각 아키텍쳐 패턴을 데이터 흐름을 통해 정리를 해보았는데요. 다들 알고계시는 내용이지요. 그래서 실제로 분리가 엄청 잘 되고 결국 MVVM의 ViewModel이 MVP의 Presenter보다 엄청나게 덜 비대해지는 마법과도 같은 일이 생겼나요? 결국 ViewModel도 비대하다는 평을 받고, 다들 그렇게 느끼셨던 적이 있으실 겁니다. 아키텍쳐 패턴이라는게 왜 그렇게 많을까요? 문제가 해결되지 않았으니까요.

 

2. 그래서 어떡할건데?

 

그렇다면 우리는 어떡해야할까요? 아키텍쳐를 쓰면 분명히 생산성이 올라가고, 딱 원하는 부분만 고치면 기계처럼 움직이며 만사형통이길 바랬는데, 그렇지 않죠. 그럼 또 MVVM이 문제고 새로운 아키텍쳐 패턴을 도입해야하나요? 아마도 그렇습니다(maybe yes). 여기서 클린 아키텍쳐의 필요성이 나타납니다. 우리의 코드가 복잡하게 얽히기 전에 그 계층, 레이어을 미리 나눠두자는 '가이드라인'의 필요성이죠. 클린 아키텍쳐에서는 데이터를 보여줄 UI와 도메인과의 연결을 도와줄 Controller가 포함된 프레젠테이션 레이어, 특정 행위에 해당하는 유즈케이스와 비즈니스로직과 데이터를 캡슐화한 것인 엔티티(어떠한 하나의 개체를 의미)를 담은 도메인 레이어, 그리고 저장소가 있는 데이터 레이어, 이렇게 세가지의 레이어로 나누자는 가이드라인을 제시합니다.

 

3. 결론

 

그래서 클린 아키텍쳐라는 것이 하나의 아키텍쳐패턴인가? 의 질문에 '네니오(Yes but no)'라고 대답한 이유를 말씀드리겠습니다.

 

네(Yes)의 이유:

클린 아키텍쳐라는 것이 소프트웨어의 설계에 대한 구조적인 접근방식을 제공한다는 점에서 그렇다고 볼 수 있을 것 같습니다.

클린 아키텍쳐는 분명히 Architecture pattern(구조/건축의 양식)을 제안하고 있습니다.

 

아니오(But no)의 이유:

위 1, 2번 질문에 대합 대답을 정리해보면,

클린 아키텍쳐는 하나의 앱을 프레젠테이션, 도메인, 데이터 레이어로 나누어주는 '가이드라인'이고,

아키텍쳐 패턴은 도메인에서 온 데이터가 들어가서 UI에 어떻게 display되어야하는지에 대한 일련의 규칙입니다

따라서 우리는 아키텍쳐의 디자인 패턴을 따르면서 클린 아키텍쳐라는 '가이드라인'을 지킬 수 있는거죠.

 

즉, 아키텍쳐 패턴과 클린 아키텍쳐는 양립가능한 개념입니다. 특정 아키텍쳐 패턴을 따르면서, 클린 아키텍쳐 가이드라인에 따르도록 설계할 수 있는 것입니다. 그리고 TCA와 같은 아키텍쳐 패턴은 클린 아키텍쳐 가이드라인에 따르기에 적합한 형태를 띄고 있다는 것도 사실입니다.

 

4. 여담

 

제가 한 회사의 Flutter 프로젝트의 외주를 하면서 생각한 부분입니다. BLoC이라는 상태관리 라이브러리가 있는데, 이에 대해 더 깊게 이해하기 위해 해외 플러터 개발 커뮤니티를 돌아다니던 중에 대부분의 글에 MVVM with BLoC 라는 표현이 쓰인 것에 대해 정말 의아했습니다. 제가 BLoC이라는 라이브러리에 쉽게 적응할 수 있었던 이유가 TCA의 상태관리 방식과 굉장히 유사하기 때문인데, 이를 커뮤니티에서 MVVM이라고 부르고 있었기 때문입니다. 위젯(View)에서는 사용자 인터페이스를 담당하고, BLoC은 비즈니스 로직과 상태 관리를 담당한다는 것에 MVVM에 유사하다는 생각을 하며 넘어가긴 했습니다만, 실제로 아직까지도 BLoC을 이용한 아키텍쳐 패턴이 MVVM이라는 것에 100% 동의하지는 않습니다. 여전히 '포정해우'의 경지에 이르기까지 마음속의 장애물이 있는 모양입니다.