아키텍처 패턴
위키피디아에서 내린 정의로는,
주어진 상황에서의 소프트웨어 아키텍처에서 일반적으로 발생하는 문제점들에 대한 일반화되고 재사용 가능한 솔루션이다. 아키텍처 패턴은 소프트웨어 디자인 패턴과 유사하지만 더 큰 범주에 속한다.
라고 나와 있다.
아키텍처 패턴을 사용함으로써 얻을 수 있는 장점으로는
시행착오를 줄여 개발시간을 단축시킬 수 있고, 검증된 구조로 개발하기 때문에 안정적인 개발이 가능하며, 시스템의 구조를 이해하는 것이 쉬워지고 시스템의 특성을 개발 전에 예측하는 것이 가능하다는 등 이 있다.
다음과 같은 여러 아키텍처 패턴들이 있지만, 그 중에서도 클라이언트-서버, MVC, MVP에 대해서만 정리해볼 것이다.
계층화 패턴 (Layered pattern)
클라이언트-서버 패턴 (Client-server pattern)
마스터-슬레이브 패턴 (Master-slave pattern)
파이프-필터 패턴 (Pipe-filter pattern)
브로커 패턴 (Broker pattern)
피어 투 피어 패턴 (Peer-to-peer pattern)
이벤트-버스 패턴 (Event-bus pattern)
MVC 패턴 (Model-view-controller pattern)
블랙보드 패턴 (Blackboard- pattern)
인터프리터 패턴 (Interpreter pattern)
클라이언트-서버 패턴(Client-Server Pattern)
서버는 단독으로 움직이지 않으며 불특정 다수의 컴퓨터에 일방적으로 서비스를 제공하는 것도 아니다. 서버는 클라이언트로부터 요청(Request)을 받아야 비로소 처리를 시작하며 서비스를 제공한다. 요청을 해야 응답이 오고 요청 없이 응답이 오는 경우는 없다.
서버가 클라이언트에게 서비스를 제공할 때 다음과 같은 처리가 일어난다.
1. 클라이언트가 서버에게 어떤 서비스를 요청
2.서버는 요청에 응답해 처리를 수행
3. 서버는 처리 결과를 클라이언트에게 반환
4. 클라이언트는 처리 결과를 받음
이를 웹 브라우저(크롬, 사파리 등)에 적용하면 다음과 같다.
1. 웹 브라우저가 웹 서버에게 “www.naver.com” 사이트 데이터를 달라고 요청
2. 웹 서버는 해당 사이트의 파일을 찾음
3. 웹 서버는 찾은 파일을 웹 브라우저에게 반환
4. 웹 브라우저는 파일을 받아 네이버 메인을 화면에 표시
이처럼 서버와 클라이언트로 구성된 시스템을 ‘클라이언트/서버 시스템'이라고 한다. 클라이언트/서버 시스템은 서버에서 데이터를 쉽게 관리할 수 있기 때문에 대부분 컴퓨터 시스템에서 채택하고 있다.
보통 서버는 리소스를 전달해주는 역할을 담당하고, 클라이언트는 리소스를 사용하는 역할을 한다. 그리고 데이터베이스는 리소스를 저장하는 공간과 같은 역할을 한다.
클라이언트 영역을 프론트엔드에서 담당하며, 사용자가 직접 눈으로 보고 UI를 클릭하는 등의 상호작용을 할 수 있는 부분을 다룬다.
서버와 데이터베이스 영역을 백엔드에서 담당하고, 상품 정보를 API로 노출한다거나 로그인/로그아웃, 권한 관리 등의 사용자 인증을 주로 다루며 데이터베이스 등의 시스템 설계까지 하는 경우도 있다.
MVC 패턴 (Model-View-Controller pattern)
대표적인 아키텍처 패턴 중 하나로 Model, View, Controller 3개의 컴포넌트로 구성된다.
- Model은 데이터와 관련된 것으로, 데이터의 형식을 지정하고 데이터와 관련된 것들을 처리할 때의 코드가 이에 속한다.
- View는 사용자에게 시각적으로 정보가 보이는 부분을 담당한다.
- Controller는 사용자의 입력(Action)을 받고 처리하는 비즈니스 로직을 담당한다.
이처럼 3개의 컴포넌트는 각자의 역할을 가지고 사용자에게 서비스를 제공한다.
사용자의 입력은 Controller가 처리하며, view-controller의 관계는 1:n이며, 경우에 따라선 n:m 이 될 수 있다. controller 하나가 여러 개의 view를 선택할 수 있다.
view는 model과 연관이 없고, 영향을 끼칠 수도 없다. Observer 방식으로 간접적으로 알 수 있다. MVC 패턴의 경우 규모가 커질수록 controller도 비례해서 커진다. controller가 다수의 view를 선택할 수 있기 때문이다.
그렇다면 MVC 패턴은 왜 사용하는걸까?
작은 프로젝트라면 한 파일 안에 mvc 역할을 다 사용할 수 있는 코드를 작성해도 큰 문제가 없을 것이다. 또 그렇게 작성한 코드가 개발하는 속도에 있어서는 훨씬 빠를 수도 있을 것이다. 하지만 프로젝트의 단위가 커지면 유지보수를 하는 데 있어서 큰 비용을 들여야 할 것이다.
MVC 패턴을 처음에 구축할 때에는 더 시간을 써야 할지라도, 한 번 구축해놓으면 프로젝트를 확장하고 유지 보수하는데 훨씬 효율적이다.
MVC의 개념을 웹에 적용해본다면?
다음 사진은 일반적인 웹 애플리케이션의 설계 아키텍처이다.
- 먼저 사용자가 웹사이트에 접속하면 사용자 Action이 controller로 들어오게 된다.
- Controller는 사용자가 요청한 웹페이지를 서비스하기 위해서 Model을 호출해야 한다.
- 모델은 데이터베이스나 파일과 같은 데이터 소스를 제어한 후 그 결과를 리턴한다.
- Controller는 Model이 리턴한 결과를 View에 반영한다.
- 데이터가 반영된 View는 사용자에게 보인다.
MVP 패턴
Model, View, Presenter의 약자이다.
Model은 데이터와 그 데이터를 처리하는 부분을 담당하고, View는 사용자에게 보이는 UI 부분을 담당한다.
Presenter는 View에서 요청한 정보로 Model을 가공해서 View에게 전달해주는 부분을 담당한다.
사용자의 입력은 View를 통해서 입력하게 되며, view-presenter의 관계는 1:1이다. 이전의 MVC에서는 view-controller가 1:n 관계였다.
view는 presenter를 refer 하며, presenter는 view를 refer 한다. 그렇기 때문에 서로 간의 연결 결합 고리가 강하다.
MVP 패턴은 어떻게 동작할까?
- 사용자의 Action이 View를 통해 들어오게 되고
- View는 데이터를 Presenter에게 요청한다.
- Presenter는 Model에게 데이터를 요청하고
- Model은 Presenter에게 요청받은 데이터를 응답한다.
- Presenter는 View에게 데이터를 응답한다.
- View는 Presenter가 응답한 데이터를 이용하여 화면에 나타낸다.
View는 Model에게 영향을 끼칠 수 없다는 점에서 MVC와 비슷하다. Presenter는 Model의 데이터를 수정하고, 데이터를 가져오는 것이 가능하다. View와 Model의 인스턴스를 가지고 있는 Presenter는 둘을 연결하는 접착제 역할을 한다는 것이 MVP 패턴의 특징이다.
MVC 패턴의 단점이었던 View-Model 사이의 의존성은 해결되었지만, View-Presenter 사이의 의존성이 높아졌다는 단점이 있다. 애플리케이션이 복잡해질수록 View와 Presenter 사이의 의존성이 강해진다.
정리하면, View와 Model은 Presenter라는 연결고리를 통해서만 주고받을 수 있다. 하지만 View와 Presenter 관계는 강한 결합을 가지게 된다. View-Presenter는 1:1 관계로 각각의 View마다 Presenter가 존재하게 되므로, MVP 패턴을 사용하게 된다면 코드는 증가하게 된다.
[References]
https://mingrammer.com/translation-10-common-software-architectural-patterns-in-a-nutshell/
https://www.developier.com/2020/03/design-pattern-04-mvc-mvp-mvvm-3.html
https://tech.toktokhan.dev/2021/04/28/architecture-patterns/