주니어를 위한 아키텍처 패턴

이 글은 번역본 입니다.
(영어 공부 겸 외국 개발 커뮤니티를 번역해 보고 있습니다.)
괄호 표시(*)는 이해해 조금 더 도움이 되기 위한 제 첨언입니다.

원문
https://dev.to/chiragagg5k/architecture-patterns-for-beginners-mvc-mvp-and-mvvm-2pe7

주니어를 위한 아키텍처 패턴 (MVC, MVP, MVVM)

소프트웨어 구축은 복잡합니다.

여러분들은 아마도 사이드 프로젝트를 만들 때 큰 고민을 한 적이 없을 것입니다.
하지만 소프트웨어 제작은 다릅니다.

이는 여러 컴포넌트를 요구하며,
제대로 처리하지 않는다면 혼란을 부를 수 있습니다.

하지만 이렇게 복잡할 필요는 없습니다.
오늘 이 글에서는 아키텍처 패턴의 세계를 탐구하며,
소프트웨어를 세 가지 간단한 구성 요소로 나누고 각각 관련된 작업에 집중하는 방식을 논의할 것입니다.

아키텍처 패턴

언제나 소프트웨어 디자인에서 우리는 항상 클라이언트-서버 , 계층형, 모놀리틱, 마이크로커널(운영 체제나 소프트웨어 시스템을 핵심 기능과 별도의 서비스로 나눈 방식), even-driven(이벤트기반 오타로보임) 같은 아키텍처에 대해 먼저 얘기합니다.
이 패턴들은 시스템, 아키텍처, 여러 어플리케이션, 서비스, 서버에 관련되어 있습니다.

그러나 MVP, MVC 그리고 MVVM은 한 어플리케이션에서 데이터 분리, 유저 인터페이스, 로직 등 조직코드에 집중되어 있습니다.
이 아키텍처 패턴의 집합은 전반적인 시스템에 초점을 두었습니다.

MVP, MVC 그리고 MVVM

블로그의 가독성을 유지하고 글자 수를 초과하지 않기 위해,
단일 애플리케이션 내에서 코드를 구성하는 아키텍처 패턴에만 초점을 맞추겠습니다.

이름하여
1. Model-View-Controller
2. Model-View-Presenter
3. Model-View-ViewModel

확실히 이 세 모델은 모델과 뷰, 2가지 컴포넌트 변경점이 있습니다.
그래서 각 아키텍처를 논하기 전에 다른 디테일을 토론해봅니다

모델

모델은 소프트웨어 안에 데이터 상태에 연관된 코드로 구성되어 있습니다.
모델은 데이터베이스, 네트워크 계층과 소통하는 계층입니다.
메인 역할은 아래와 같이 포함되어 있습니다.

데이터 처리와 비즈니스 로직
어플리케이션 데이터의 캡슐화 그리고 해당 데이터에 대한 접근을 관리하는 규칙
데이터 구조 핸들링
데이터 CRUD 처리

View

뷰는 어플리케이션의 프론트의 끝이거나 유저가 볼수있고 상호작용할 수 있는 모든 것이다. 또한 다들 아시다시피 유저 인터페이스(UI)로도 알려져 있습니다.

뷰는 아래와 같은 것을 맡습니다.

비즈니스로직이 아닌것을 담당하고 온전히 표현로직을 담당한다
유저로부터 다른계층으로부터 제공받은 데이터를 표현한다.
유저의 입력을 받고 다른 계층에 전달한다.
모델레이어와 직접 통신할수도있습니다.

지금까지 모델과 뷰 계층이 어떤 역할을 하는지 알아봤습니다.
이제 각 아키텍처 패턴을 알아봅시다.

Model-View-Controller (MVC) Architecture

MVC패턴은 뷰와 모델 계층 둘 다 접근하는 컨트롤러 계층을 사용합니다.

컨트롤러 계층은 다음과 같은 역할을 합니다.

모델레이어를 통한 데이터 조작
뷰 계층(UI)로 부터 응답받기
컨트롤 로직을 통한 뷰의 변화

여기서 뷰는 직접 모델레이어를 통해 데이터를 받아 업데이트를 할 수 없습니다.
따라서, 세 계층은 각각 컨트롤러가 메인 컴포넌트가 되어 특정 폼으로 서로 연결되어있습니다.

Model-View-Presenter (MVP) Architecture

Presenter 계층은 모델과 뷰 계층을 소통하고 핸들링하는 "중간다리" 역할을 합니다.
즉, 모델과 뷰 계층은 서로 직접적으로 접근할 수 없습니다.

이건 아래와 같은 책임이 있습니다.

유저 액션 기반의 뷰(UI) 업데이트
코드 로직 기반의 모델계층, 데이터 업데이트
MVC패턴의 컨트롤러 안에 핸들되는 비즈니스 로직의 대부분을 처리

Model-View-ViewModel (MVVM) Architecture

MVVM 아키텍처는 MVP 아키텍처와 거의 유사합니다.
하지만 몇 가지 다른 점이 있습니다.

하나의 뷰모델 객체에 여러 뷰가 매핑될 수 있습니다.
event-driven 으로 뷰모델과 뷰 계층 사이에 데이터 바인딩을 사용할 수 있습니다 ??
아키텍처 안에 UI 컨셉이 없습니다. 뷰 계층은 단순 유저 액션을 표현합니다.

표

Aspect	MVC (Model-View-Controller)	MVP (Model-View-Presenter)	MVVM (Model-View-ViewModel)
역할 분리	Basic	Better	Best
데이터 흐름	양방향(Two-way) View와 Model 간 직접 상호작용	단방향(One-way) Presenter가 View와 Model을 중재	단방향 + 데이터 바인딩 ViewModel이 UI를 자동 업데이트
View와 논리 관계	Many-to-One (여러 View가 하나의 Controller를 공유)	One-to-One (각 View에 Presenter가 1:1 매칭)	Many-to-One (여러 View가 하나의 ViewModel 사용)
테스트 용이성	어렵다	좋음	최고 (ViewModel이 UI와 분리됨)
유지보수성	어렵다	쉬움	쉬움
학습 곡선	쉽다	쉽다	약간 어려움
성능	Controller와 View 간 결합이 강해 속도가 느릴 수 있음	Presenter가 역할을 분리해 성능 향상	UI가 복잡할수록 성능이 매끄러움
UI 업데이트 방식	Controller → View 직접 변경	Presenter → View 직접 변경	ViewModel이 데이터 바인딩을 통해 자동 업데이트
UI 프레임워크 의존성	높음	낮음	낮거나 없음
확장성	작은 프로젝트에 적합	간단한 프로젝트부터 복잡한 앱까지 가능	대규모, 데이터 중심 앱에 이상적

그럼 어떤 패턴이 제일 인기가 많은가? 라고 의문이 생길 수 있습니다
이 모든 패턴은 각 기업의 요구 사항에 따라 동일하게 많이 사용되는 아키텍처들 입니다.

각 패턴을 채택한 대표적인 기업은 다음과 같습니다.
MVC : StackOverflow , Visual Studio
MVP : Google(일부 Android 앱)
MVVM : Apple (SwiftUI를 사용하는 일부 IOS 앱), Angular, Vuejs 프레임워크

또한 많은 회사들이 각 프로젝트나 프로덕트에 따라 특별한 필요성들만 의존에 아키텍처를 섞어 쓰기도 합니다.
아키텍처의 선택은 프로젝트의 특별한 요구성, 개발팀의 경험, 어플리케이션의 복잡성 등 여러 요소에 따라 선택됩니다.

결론

이 게시글은 아키텍처 패턴의 기본적인 내용을 적었습니다.
전체 아키텍처가 어떻게 설계되는지부터,
단일 애플리케이션을 더 나은 관리와 확장성을 위해 세 가지 구성 요소로 나누는 방법까지 설명했습니다.

MVC : 간단한 접근 방식으로 웹 애플리케이션에서 여전히 인기를 끌고 있습니다.
MVP : MVC의 기초 위에 구축되어, 개선된 테스트 용이성과 더 깔끔한 관심사의 분리를 제공합니다.
MVVM : 세 가지 중 가장 최근에 등장한 패턴으로, 현대적인 애플리케이션 개발에서 큰 인기를 얻고 있습니다.

이 세 가지 아키텍처 패턴 간에는 명확한 승자가 없으며, 각 패턴은 고유한 장점을 제공하고, 서로 다른 프로젝트와 개발 시나리오에 적합합니다. 소프트웨어 개발 환경이 계속해서 발전함에 따라, 이러한 패턴이 더욱 세분화되거나 새로운 아키텍처가 등장할 수도 있습니다.

아키텍처 패턴에 대해 어떤 것을 좀 더 얘기해보고 싶나요?
제가 찾은 도움된 레퍼런스들을 남겨놓겠습니다.

영어 - 아예 문장 해석이 안되는 부분도 있어 어려움을 겪었다.. GPT한테 몰랐던 문장을 많이 배웠다

개발 - 이렇게 보니 말로만 듣던 세 패턴을 좀 더 확실하게 알 수 있어서 좋았다. 나중에는 실습을 통해 장단점을 확실하게 느껴봐야겠

저작자표시 비영리

'번역' 카테고리의 다른 글

프로그래머가 아닌, 소프트웨어 엔지니어가 되어라 (0)	2025.01.19

개발고구마

주니어를 위한 아키텍처 패턴 - MVC, MVP, MVVM