본문 바로가기
기타

가볍게 보는 아키텍처 vs 디자인 패턴

by 나이아카 2024. 7. 11.

 회사에서 코드 컨벤션을 정리하면서 가볍게 현재 사용중인 아키텍처와 패턴들을 정리하고 있었는데요. 여러가지 생각을 하다 보니, 예전에 MVVM이 디자인 패턴인지 아키텍처인지 찾아봤던 기억이 떠올랐습니다. 그때는 블로그들의 설명이 길고 장황해서 우와... 어려운 개념인가? 하고 넘어갔었는데, 조금만 생각해보면 그리 어려운 개념은 아니었다는 것을 알게 되서 넘어갔었습니다.

 간만에 다시 다른 블로그 글들을 보다 보니 이걸 왜 이해하지 못했을까 하는 생각들이 들었지만, 그 당시에는 이 글들이 참 어렵다는 생각이 들어 가볍고 간단하게 기록해보려고 합니다. '가볍고 간단하게' 에 초점을 맞추다보니 정확하게 100% 들어맞지 않을 수도 있지만, 가닥을 잡기에는 도움이 되지 않을까 생각합니다.


디자인 패턴의 종류

 디자인 패턴이라고 부르는 것들에는 뭐가 있을까요.

Singleton pattern

Repository pattern

Factory Method pattern

Observer Pattern

 위에 적은 네 가지가 자주 사용하는 패턴들 중 하나인데요. 이 뿐만 아니라, MVVM, MVP, MVC 역시 어떻게 사용하느냐에 따라 디자인 패턴이라고 부를 수 있겠습니다. 혹은 iOS에서 사용하는 VIPER 패턴도 디자인 패턴이라고 부를 수 있겠습니다.

 

아키텍처의 종류

 아키텍처라고 부르는 것 중 안드로이드 개발자로서 가장 익숙한 것은 역시 클린 아키텍처가 아닐까 싶습니다. 혹은 위에서 나왔지만 쓰임에 따라 MVVM, MVP, MVC로 대표되는 것들도 아키텍처라고 할 수 있겠네요. 물론 다른 프레임워크에서 쓰는 MSA, 헥사고날 아키텍처, TCA등도 아키텍처로 분류할 수 있습니다.

 

 각 아키텍처와 디자인 패턴이 어떤 역할을 하고 어떤 것인지는 자세하게 적진 않겠습니다. 이번 게시글에서 다룰 내용이 아니기 때문이죠. 대신, 이 둘의 공통점과 차이점에 대해서 살펴보겠습니다.

 이 둘의 공통점은 무엇일까요. 일단 코드를 일반화시킬 수 있다는 것입니다. 싱글톤 패턴이라 함은 언어 마다 각자 사용하는 방식은 다르지만(kotlin의 object, java의 instance 선언처럼 문법이 달라질 수 있다는 의미입니다), 결국 프로그램이 실행되는 동안 하나의 인스턴스만을 생성하고 사용하겠다는 규칙을 가지게 됩니다. 또한 클린 아키텍처는 프로젝트 전반적으로 레이어를 분리하고 각 레이어의 의존성을 합의된 룰에 맞게 지정해두고 규칙에 어긋나지 않는 방향으로 사용합니다.

 디자인 패턴과 아키텍처는 하나의 정의된 룰을 따르게 됩니다. 이는 많은 개발자들이 동일한 프로젝트를 통해 협업을 진행할 때, 유지보수의 측면에서 커뮤니케이션의 중요성을 이해하게 되면서 다른 사람들과의 효과적인 협업을 위해 더 효율적인 코드 작성 방향을 규칙으로 정해두게 되었습니다. 이러한 규칙들을 다른 사람들에게도 소개하고 서로 공유하며 유명해지게 되었습니다. 그렇게 현재는 많은 사람들이 시행착오를 통해 여러 규칙들을 정의해놓은 것이죠.

 그렇다면 둘의 차이점은 무엇일까요? 일단 디자인 패턴의 경우, 프로젝트의 일부를 정의하는데 쓰입니다. Repository pattern은 데이터를 가져오고 보관하는 클래스를 중간에 따로 하나 두는 패턴인데요. 패턴을 사용하는 사람들마다 세부적인 내용은 조금씩 차이가 있습니다만, 데이터의 저장소에 접근하기 위한 통로를 repository로 제한함으로서 데이터의 일관성을 얻거나 데이터의 가공을 대신하고 데이터의 소스(Local인지 Remote인지)를 캡슐화하는 역할을 합니다.

 이 Repository 패턴은 오직 프로젝트 중 데이터의 호출 및 관리에 대한 부분에 대한 규칙입니다. UI를 구성하는데 이 Repository 패턴을 사용할 방법은 없죠. 혹은 ViewModel이 호출하든, UseCase가 호출하든 Repository를 호출하는데는 아무런 문제가 없죠. 이처럼 프로젝트 내부에서 일부분에 대해서 적용한다면 디자인 패턴으로 볼 수 있습니다.

 아키텍처는 디자인 패턴과 다르게 프로젝트 전반을 관리합니다. 저에게 가장 친숙한 클린 아키텍처는 사용하는 대부분의 안드로이드 프로젝트는 data - domain - presentation으로 패키지가 나눠져 있습니다(멀티 모듈을 사용하는지, 패키지에 다른 추가적인 패키지가 들어가는 지 등의 세부적인 부분은 조금 다릅니다). 이처럼 프로젝트의 전반적인 규칙을 지정하게 됩니다. 또한 repository interface를 강제해 domain layer가 다른 계층에 독립되도록 설계하는 것 까지 정해져 있습니다. 그러니 프로젝트 내에서 강제되어 있는 부분들이 많고, 아키텍처를 잘 이해한 여러 사람들이 하나의 프로젝트를 진행할 때 좀 더 매끄럽게 진행할 수 있게 되죠(미리 여러가지를 합의하고 작업을 하는 느낌이겠네요).

 한 마디로 결론을 정의하자면, 아키텍처는 하나의 프로젝트에 전반적으로 영향을 끼치지만, 디자인 패턴은 세부적인 부분에 대해서 영향을 끼치게 됩니다. 아키텍처를 통해 프로젝트의 전반적인 부분에 대한 설계를 진행하고 디자인 패턴을 통해 프로젝트의 세부 내용을 다듬는 형태로 볼 수 있겠습니다.

 MVVM과 같은 것들이 아키텍처이면서 디자인 패턴이 될 수 있는 이유는 여기에 있습니다. MVVM은 그 자체로도 프로젝트 전반적인 룰을 생성하고 유지할 수 있으나, 다른 아키텍처의 내부에서 디자인 패턴처럼 부분적인 규칙을 가질 수도 있습니다. 가령 MVVM만 사용하는 앱은 Model - View - ViewModel로 이루어진 형태의 프로젝트를 진행하게 되며, 각각 아키텍처에 맞는 역할을 수행하게 됩니다. 그러나 안드로이드 클린 아키텍처에서의 MVVM은 Presentation Layer에서 부분적으로 사용됩니다. 이를 Domain이나 Data 계층에 영향을 미치지 않습니다. 이때는 MVVM을 Presentation Layer에 사용하는 디자인 패턴이라고 부를 수 있습니다.

 


 요새는 정말 다양한 패턴과 아키텍처가 많은 것 같습니다. 각 프레임워크 및 언어 별로 선호하는 아키텍처도 다르고, 디자인 패턴의 사용 방식도 다르다보니 배워야 할 지식도 늘어가더라구요. 점점 배워야 할 트렌드는 늘어가는데 익숙한 게 더 좋아지는 터라 고민이 많아집니다.

댓글