[CS] 아키텍처 패턴 딥다이브하기(feat. 디자인 패턴)

들어가며

MVVM 패턴에 관한 글을 작성하던 중, 제가 “아키텍처 패턴”과 “디자인 패턴”을 함께 사용하고 있다는 것을 알아차렸습니다. 용어를 하나로 통일시키려는 찰나, 문득 의문이 생겼습니다.

 

“MVVM은 아키텍처 패턴일까, 디자인 패턴일까?”

 

글을 쓰기 위해 참고하던 여러 글 중에서도 어떤 글에서는 아키텍처 패턴이라 설명하고, 또 다른 글은 디자인 패턴이라 부르고 있었습니다.

저 또한 둘의 대략적인 의미만 알고있었지, 구체적으로 무엇이 다른지는 몰랐습니다.

차이점을 알기 위해 위키에서 정의를 찾아보아도 곧바로 이해할 수 없었습니다.

소프트웨어 아키텍처 패턴

주어진 문맥 안에서 소프트웨어 아키텍처의 공통적인 발생 문제에 대한 일반적인, 재사용 가능한 해결책

소프트웨어 디자인 패턴

소프트웨어 디자인의 특정 문맥에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책

 

MVVM에 대한 글을 작성하기 전, 두 용어의 정의와 차이를 정확히 이해해야 MVVM을 이해하고 설명할 수 있을 것 같았습니다. 그래서 MVVM 공부는 잠시 접어두고, 저를 포함한 많은 개발자가 헷갈려하는 아키텍처 패턴과 디자인 패턴에 대해 먼저 알아보려 합니다.

 

해당 포스트는 아키텍처 패턴과 디자인 패턴에 대해 필자가 공부하고 이해한 과정을 상세히 서술한 글입니다.
두 패턴의 정의와 차이점을 빠르게 살펴보고 싶다면 글 하단의 아키텍처 패턴 vs 디자인 패턴 목차로 이동하여 읽어주시기 바랍니다.

 

---

 

1. 패턴(Pattern)이란?

아키텍처 패턴과 디자인 패턴의 차이점을 알아보기에 앞서 둘의 공통점을 이해하면 어떤 부분이 다른 것인지 파악하기 쉬울 것입니다.

두 용어에는 모두 “패턴”이라는 단어가 포함되므로, 먼저 패턴의 의미를 이해해보았습니다.

1.1. 정의

A pattern is a regularity in the world, in human-made design, or in abstract ideas. As such, the elements of a pattern repeat in a predictable manner.

Pattern - Wikipedia

 

 

패턴은 세상이나 인간이 만든 디자인 또는 추상적인 아이디어에서 나타나는 규칙성입니다.

따라서 패턴과 그 요소들은 예측 가능한 방식으로 반복됩니다.

사람들은 오래 전부터 자연 속에서 패턴을 찾아왔고, 이를 일상 생활에 적용하기도 하였습니다. 사람들은 패턴을 활용해 카펫, 옷, 그림 등의 특징적인 무늬가 규칙성 있게 반복되어 나타나는 시각적인 디자인을 나타내기도 하고, 벽, 도로, 건물 등의 구조물의 일부가 규칙적으로 반복되는 구조적인 형태를 만들기도 합니다.

 

1.2. 소프트웨어의 패턴

소프트웨어에서 나타나는 패턴은 시스템이나 코드에서 규칙적, 반복적으로 나타나는 형태나 구조를 의미합니다.

 

오래 전부터 개발자들이 공통적으로 마주하는 문제점이 있었고, 이를 해결하기 위해 누군가 도입한 형태를 다른 곳에서도 찾아볼 수 있었습니다. 반복적으로 나타나는 문제를 규칙성 있는 형태나 구조를 사용하여 해결했다는 점에서, 그 모습이 마치 패턴의 특징과 비슷했기 때문에 “패턴”이라는 용어를 활용했다고 이해할 수 있습니다.

 

정리하자면, 프로그래밍에서 패턴이란 특정 문제를 해결하기 위해 적용할 수 있는, 규칙적이고 반복적으로 사용 가능한 코드 형식이나 시스템 구조를 일컫습니다.

 

패턴은 또한 대부분의 경우, 특정 물체나 객체에 종속되지 않습니다. 그보다는 어떤 상황이나 이유에 종속됩니다. 벌에게서 볼 수 있는 노란색, 검정색이 교차된 줄무늬 패턴은 천적에게 경고와 주의의 역할을 합니다. 이 패턴은 벌에게만 나타나는 것이 아니며(등에, 파리매 등 벌을 모방한 곤충도 많습니다), 사람들은 공사장의 꼬깔, 안전 제일 간판, 지하 주차장의 기둥 모서리 등 이 패턴을 주의가 필요한 다양한 상황에서 활용합니다.

 

아키텍처 패턴과 디자인 패턴도 마찬가지로 시스템과 시스템의 도메인에 영향을 받지 않습니다. 필요에 따라서 다른 시스템과 상황에도 적용할 수 있으므로 재사용 가능한 해결책이라고 설명하는 것입니다.

 

 

2. 소프트웨어 아키텍처 패턴

2.1. 정의

Software architecture pattern is a reusable, proven solution to a specific, recurring problem focused on architectural design challenges, which can be applied within various architectural styles.

Architectural pattern - Wikipedia

 

소프트웨어 아키텍처 패턴은 소프트웨어 구조를 설계할 때 자주 나타나는 문제점을 해결하는, 재사용 가능하고 검증된 해결책입니다.

 

2.1.1. 단어 뜯어보기

아키텍처라는 단어의 의미를 살펴보면 아키텍처 패턴의 정의와 특징을 더 자세히 이해할 수 있을 것 같습니다.

Architecture is the art and technique of designing and building, as distinguished from the skills associated with construction. It is both the process and the product of sketching, conceiving, planning, designing, and constructing buildings or other structures.

Architecture - Wikipedia

 

아키텍처(건축)는 건설에 관한 기술과는 구별되는, 구조물을 계획하고, 설계하고 만들어내는 과정과 결과물입니다.

여기서 건설 기술과 구별된다는 점은, 설계대로 구조물을 만드는데 필요한 여러가지 건축 기법에 의존적이지 않다는 의미인 것 같습니다.

 

과거에는 거중기와 같은 기구를 사용했겠지만, 현대에는 타워 크레인과 같은 장비를 사용할 것입니다. 하지만 설계도에서 묘사하는 건설 과정과 설계대로 만들어진 결과물은 비슷하거나 동일합니다.

프로그래밍으로 따지자면, 네트워크 통신을 API 명세서대로 구현한 코드를 아키텍처, 그 구현을 위해 활용하는 개발 방식을 건설 기술에 비유할 수 있겠습니다.

개발 방식은 다를 수 있습니다.
  - 언어에서 자체적으로 제공하는 네트워크 통신 API를 활용한다. (e.g. Java/Kotlin의 HTTP)
  - 네트워크 통신 구현을 편리하게 돕는 라이브러리를 활용한다. (e.g. Okhttp3, Retrofit 등)
그러나 API 명세대로 구현한 결과는 동일합니다.
  - 클라이언트는 API를 사용하여 서버와 통신할 수 있다.

 

2.1.2. 아키텍처 패턴의 의미

소프트웨어의 아키텍처 패턴은 소프트웨어(시스템, 프로그램)의 구조적인 관점에서 규칙성 있게 반복되는 형태나 구조를 의미하며, 이는 결국 소프트웨어 구조를 설계하고 개발할 때 일반적으로 자주 마주하는 문제를 해결하기 위함입니다.

 

“시스템에서 어떻게 구현되는가?” 와는 큰 연관성이 없습니다. 각 시스템이 다른 언어와 기술을 사용해 아키텍처 패턴을 적용했다 하더라도, 두 시스템이 띄는 전체적인 구조는 비슷할 것입니다.

”시스템이 어떤 동작을 하는가?” 와도 연관성이 없습니다. A 아키텍처 패턴이 적용된 소프트웨어를 B 아키텍처 패턴으로 바꾸어 적용했다고 해서, 해당 시스템이 다른 동작을 하지 않습니다.

 

즉, 아키텍처 패턴은 시스템 전체 설계도, 시스템의 청사진과 같습니다.

 

2.2. 아키텍처 패턴이 해결해주는 문제

소프트웨어 아키텍처 패턴이 해결하고자 하는 문제는 다양하지만, 대표적으로 아래와 같은 것들이 있습니다.

• 규칙성 있는 구조로 빠르고 효율적인 개발을 가능하게 합니다.
  • 새롭게 개발을 시작하거나 기능을 추가할 때, 구조를 어떻게 할 것인가 고민하지 않고 청사진에 따라서 구현하면 되므로 시간을 단축할 수 있습니다.
  • 보편적으로 잘 알려져 있고 효과가 검증된 아키텍처 패턴을 사용하기 때문에, 큰 노력과 자원의 투자 없이 좋은 구조의 시스템을 효율적으로 만들 수 있습니다.
• 시스템의 유지 보수를 편리하게 합니다.
  • 특정한 규칙과 구조를 바탕으로 시스템을 설계하기 때문에, 어느 한 곳의 수정 사항이 다른 곳으로 전파되지 않아 코드 수정에 대처하기 용이합니다.
  • 기능을 새롭게 추가하더라도 반복적인 구조에 맞춰 구현하면 되므로 기능 개발이 유리합니다.
• 아키텍처 패턴의 적용으로 동료 개발자와 협업과 소통을 원활히 합니다.
  • 규칙적인 구조를 적용하기 때문에 개발자가 시스템의 구조와 코드를 파악하기 쉽습니다.
  • 특정 아키텍처 패턴은 팀 내 또는 개발자 사이에서 규율, 약속으로도 작용할 수 있습니다. 따라서 개발 상황에서 구조를 어떻게 설계할 것인지 결정하는 추가적인 리소스 낭비를 줄일 수 있습니다.

 

2.3. 소프트웨어 아키텍처 패턴의 종류

아키텍처 패턴에는 아래와 같은 종류가 있습니다.

• MVC (MVP, MVVM)
• Service Locator
• Publish-subscribe
• Broker
• Client-server 모델

아키텍처 패턴의 종류를 보면 알 수 있듯, MVVM은 사실 아키텍처 패턴에 속합니다.

 

 

3. 소프트웨어 디자인 패턴

그렇다면 소프트웨어 디자인 패턴은 무엇일까요?

3.1. 정의

In software engineering, a software design pattern or design pattern is a general, reusable solution to a commonly occurring problem in many contexts in software design.

Software design pattern - Wikipedia

 

소프트웨어 디자인 패턴은 소프트웨어 설계에서 자주 나타나는 문제에 대한, 일반적이고 재사용 가능한 해결책입니다.

정의만 보아서는 아키텍처 패턴과 정말 유사합니다. 디자인 패턴 역시, 소프트웨어를 설계할 때 자주 나타나는 문제를 해결해주는 재사용 가능한 해결책이라고 설명하고 있습니다.

 

3.1.1. 단어 뜯어보기

용어에서 나타나는 유일한 차이점인, “디자인”이라는 단어를 살펴보면 감이 잡힐 것 같습니다.

A design is the concept of or proposal for an object, process, or system. (중략) A design is expected to have a purpose within a specific context, typically aiming to satisfy certain goals and constraints while taking into account aesthetic, functional and experiential considerations.

Design - Wikipedia

 

디자인은 어떤 객체, 프로세스, 또는 시스템에 대한 개념이나 목적을 의미합니다.

디자인은 특정 맥락에서 목적을 가지고 있으며, 일반적으로 미적, 기능적, 경험적 고려사항을 참작하면서 특정 목표와 제약사항을 충족시키는 것을 목적으로 합니다.

 

디자인은 설계의 일부입니다. 특정 객체나 물체, 요소를 만들 때, 그 객체를 만드는 행위 자체를 의미하기도 하지만, 그 객체가 지닌 목적에 적합하도록 도와주는 도구로 활용되기도 합니다.

예로, 인체공학적 디자인은 사람의 신체 구조에 적합한 형태를 의미하며, 사람이 사용하기 편리하게 만든다는 목적에 따라 설계된 것입니다. 인체공학적 디자인은 다양한 도구와 제품에 적용될 수 있으며, 디자인 자체의 목적을 수행하는 동시에 디자인이 적용된 도구의 목적을 받쳐 줍니다.

 

3.1.2. 디자인 패턴의 의미

소프트웨어의 디자인 패턴은 소프트웨어를 설계할 때 사용하는 규칙적인 설계 방식과 형태를 의미합니다. 소프트웨어 설계에서 분명한 목적을 가지고 사용하거나, 설계 단계에서 반복적으로 나타나는 문제를 해결하기 위함입니다.

 

시스템 전체 구조적인 관점에서 작용하는 아키텍처 패턴과 달리, 디자인 패턴은 시스템 내부의 특정 맥락에서 작용합니다. 즉, 시스템 안에서 나타나는 특정 문제를 해결하는데 집중합니다. 그래서 시스템의 동작 구현을 할 때 디자인 패턴이 곳곳에서 독립적으로 적용되거나, 특정 아키텍처 패턴을 구현하기 위해 디자인 패턴을 함께 사용하기도 합니다.

 

즉, 디자인 패턴은 시스템 구현에 사용하는 기법이라고 할 수 있습니다.

 

3.2. 소프트웨어 디자인 패턴의 역사

디자인 패턴이라는 용어 자체는 1977년 초반, Christopher Alexander라는 건축학자의 ‘A Pattern Language’ 라는 책에서 기원한 건축학 개념입니다.

해당 용어가 프로그래밍에 처음 도입된 것은, 1987년도에  Kent Beck 과 Ward Cunningham 이 디자인 패턴이라는 개념을 프로그래밍에 적용하고자 연구하면서부터 입니다.

시간이 지나 1994년도에, 소위 4인방(Gang of Four)이라고 불리는 Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides 네 사람이 ‘Design Patterns: Elements of Reusable Object-Oriented Software’이라는 책을 쓰면서 해당 용어가 유명해졌습니다.

그래서 일반적으로 소프트웨어 디자인 패턴은 위 책에 나오는 23가지 디자인 패턴(Gang of Four Patterns이라고도 불립니다)을 의미합니다.

참고로 위 책에는 MVC, MVP, MVVM와 같은 패턴이 언급되지 않습니다.

 

3.3. 디자인 패턴이 해결해주는 문제

앞서 먼저 소개된 아키텍처 패턴이 해결해주는 문제들과 유사합니다.

아키텍처 패턴에서는 시스템의 구조적 관점에서의 문제를 해결한 반면, 디자인 패턴은 구현 중심의 관점에서 문제를 해결합니다.

• 적절한 패턴을 적용한 구현으로 빠르고 효율적인 개발을 가능하게 합니다.
  • 문제 발생 시, 그에 적합한 디자인 패턴을 도입해 빠른 문제 해결이 가능합니다.
  • 새롭게 기능을 추가할 때도, 디자인 패턴의 규칙을 바탕으로 구현해 개발 시간을 단축시킬 수 있습니다.
• 시스템의 유지 보수를 편리하게 만들어줍니다.
  • 당장 나타나지 않는 문제도 미리 예방이 가능하여, 추후 발생할 문제를 줄일 수 있습니다.
• 패턴에 따른 구현으로, 동료 개발자의 빠른 이해를 도와주어 협업에 용이합니다.
  • 검증된 패턴을 적용하면 개발자가 시스템의 설계와 동작을 파악하기 쉽습니다.
  • 특정 디자인 패턴 또한 팀에서 규율, 약속으로 적용할 수 있습니다. 따라서 팀원 각자가 기능을 개발하면서 나타날 수 있는 이해 관계의 거리를 좁힐 수 있습니다.

두 패턴의 더 자세한 차이점은 잠시 뒤에 다뤄보겠습니다.

 

3.4. 소프트웨어 디자인 패턴의 종류

소프트웨어 디자인 패턴은 어떤 유형의 문제를 해결하느냐에 따라 여러 그룹으로 나누어집니다. 크게 생성 패턴(Creational Patterns), 구조 패턴(Structural Patterns), 행동 패턴(Behavioral Patterns), 동시성 패턴(Concurrency Patterns)으로 분류되며, 아래 예시들이 있습니다.

• 생성 패턴(Creational Patterns) : 객체를 생성합니다.
  • Abstract factory
  • Builder
  • Dependency Injection
  • Lazy initialization
  • Singleton
• 구조 패턴(Structural Patterns) : 객체를 구성하여 새로운 기능을 제공하는 더 큰 구조를 형성합니다.
  • Adapter
  • Composite
  • Facade
  • Proxy
• 행동 패턴(Behavioral Patterns) : 객체 간의 통신을 제공합니다.
  • Iterator
  • Mediator
  • Observer
  • State
  • Strategy
• 동시성 패턴(Concurrency Patterns) : 멀티 스레드 환경에서 데이터의 동시성을 보장합니다.
  • Event-based asynchronous
  • Join
  • Lock
  • Scheduler
  • Thread pool

 

4. 아키텍처 패턴 vs 디자인 패턴

4.1. 두 패턴의 차이점

그렇다면 아키텍처 패턴과 디자인 패턴은 정확히 어떤 부분에서 차이가 있을까요?

Software design pattern - Wikipedia

Software Design Patterns offer finer granularity compared to software architecture patterns and software architecture styles, as design patterns focus on solving detailed, low-level design problems within individual components or subsystems. Examples include Singleton, Factory Method, and Observer.

 

디자인 패턴은 개별 구성 요소 또는 하위 시스템 안에서, 세부적이고 낮은 수준의 문제를 해결하는 데 초점을 맞춥니다. 때문에 아키텍처 패턴에 비해 더 세세한, 작은 단위의 문제를 해결해줍니다.

 

Software Architecture Pattern refers to a reusable, proven solution to a recurring problem at the system level, addressing concerns related to the overall structure, component interactions, and quality attributes of the system. Software architecture patterns operate at a higher level of abstraction than design patterns, solving broader system-level challenges.

 

반면, 아키텍처 패턴은 시스템 레벨에서 자주 나타나는 문제를 해결해줍니다. 여기서 시스템 레벨에서의 문제란, 시스템 전반적인 구조, 구성 요소간의 상호작용, 시스템의 성능에 관련해 발생하는 문제입니다.

 

아키텍처 패턴이 디자인 패턴보다 더 넓은 시스템 수준의 문제를 해결해주며, 디자인 패턴보다 더 추상적이고 상위의 레벨에서 적용됩니다.

	아키텍처 패턴	디자인 패턴
정의	소프트웨어 구조를 설계할 때 자주 나타나는 문제점을 해결하는데 사용하며, 재사용 가능하고 검증된 솔루션	소프트웨어 설계에서 자주 나타나는 문제에 대한, 일반적이고 재사용 가능한 솔루션
해결해주는 문제	- 규칙적인 구조를 적용하여 빠르고 효율적인 개발 가능 - 안정적인 구조로 유지보수 편리 - 원활한 협업 가능	- 규칙성 있는 구현으로 빠르고 효율적인 개발 가능 - 특정 문제를 해결, 예방해주어 유지보수 편리 - 원활한 협업 가능
적용 범위	시스템 전체, 전반적인 구조	특정 레이어, 맥락, 기능
종류	MVC, MVP, MVVM, Service Locator, Publish-subscribe, Client-server 등	Abstract factory, Singleton, Adapter, Observer, State, Strategy 등

 

 

4.2. 두 패턴에 대해 유념할 점

아키텍처 패턴, 디자인 패턴 모두 소프트웨어 설계 및 개발에서 일반적으로 마주하는 문제를 해결하기 위한 해결책입니다. 그러나 이 패턴들이 모든 상황에서 해결책이 되지는 못합니다.

1. 패턴이 자체적으로 갖는 문제점이 존재합니다.
   • 예시로, MVP 패턴은 View와 Presenter 사이 강한 의존성으로 1대1 관계가 형성됩니다. 따라서 View가 많아질수록 Presenter도 많아져 유지보수가 어렵다는 문제점이 있습니다.
2. 디자인 패턴, 아키텍처 패턴으로도 해결하지 못하는 문제점이 많습니다.
   • 두 패턴들은 일반적으로 마주하는 문제를 위한 해결책입니다. 때문에 특수하거나 다른 이해 관계가 얽혀있는 상황이라면 해결책으로 활용하지 못합니다.
3. 언어의 특성에 따라서도 적용할 수 있는 패턴이 달라집니다.
   • 이는 특히 디자인 패턴에 관한 것입니다. 언어가 가진 특성에 맞추어 구현할 때 나타나는 문제점 또는 언어 자체가 가진 단점을 보완하기 위해 디자인 패턴이라는 개념을 적용했습니다.
   • 객체 지향 프로그래밍 패러다임을 가진 언어에서 적용하는 디자인 패턴은 함수형 프로그래밍 패러다임에서 적용하기 어렵거나, 적용할 필요가 없을 수 있습니다.
     • e.g. 변경 가능한 상태를 내포하는 패턴은 함수형 프로그래밍 언어에서 사용하기에 적합하지 않음

위와 같은 주의점 때문에, 개발을 진행할 때 또는 문제가 발생했을 때 무작정 패턴을 적용하는 것은 옳지 않습니다. 아키텍처 패턴과 디자인 패턴은 참고서와 같은 것이지, 꼭 따라야하는 정답지가 아닙니다.

 

사실 제일 좋은 개발 방법은 이러한 패턴에 영향을 받지 않고, 문제를 해결할 수 있으면서 유지보수가 유리하도록 시스템의 구조와 형태를 스스로 설계하는 것이라고 생각합니다.

하지만 이는 리소스가 많이 필요하고, 실제 개발 상황에서는 시간적 여유가 부족하므로 효율적으로 개발해야 합니다. 그렇기에 아키텍처 패턴과 디자인 패턴이 어떤 문제를 해결하는데 사용되고, 어떤 특징과 단점을 품고 있는지 충분히 이해해야 합니다. 나아가 현재 상황에 따라서 해당 패턴을 도입하는 것이 적절한지 파악하는게 중요합니다.

 

---

 

마치며

MVVM에서 시작된 아키텍처 패턴과 디자인 패턴을 이해하는 여정이 마무리되었습니다.

아키텍처 패턴은 시스템 전반적인 구조에서 나타나는 일반적인 문제점들을 해결해주고, 디자인 패턴은 시스템 내부의 구현 맥락에서 나타나는 일반적인 문제점들을 해결해 줍니다. 아키텍처 패턴이 디자인 패턴에 비해 더 넓은 범위에서 적용됩니다.

다만, 분명한 이유와 목적이 없이 좋다고 알려진 패턴을 무작정 도입하는 것은 올바르지 않습니다. 정말 그 패턴을 적용해야하는 이유와 목적이 충분한지 고민하고, 현재 개발 상황에서 적절한 선택인지 파악해야 합니다.

 

이제 MVVM 글로 돌아가서 용어를 다시 정리하려 합니다. MVVM 은 Model - View - ViewModel로 구성된 시스템 구조를 의미하므로, 디자인 패턴보다는 아키텍처 패턴에 가깝다고 할 수 있습니다. 그래서 저는 아키텍처 패턴이라고 용어를 통일하고자 합니다.

번외로, 이전에 제이슨이 이런 이야기를 해주셨습니다.

여러분이 구현한 MVVM은 아키텍처 패턴과 디자인 패턴의 혼합이에요.

 

이제 이 설명의 의미가 무엇인지 알 수 있습니다.

MVVM 자체는 아키텍처 패턴이지만, 안드로이드 미션에서 이를 구현하기 위해 옵저버 패턴(LiveData), 어댑터 패턴(ViewModel은 어댑터와 같은 역할을 한다), 추상 팩토리 패턴(ViewModelFactory) 등의 디자인 패턴 개념이 적용되었습니다.

그러므로 아키텍처 패턴과 디자인 패턴을 혼합한 결과물이라고 말씀하신 것입니다.