*'레이어드 아키텍처' 에서 이어지는 아티클입니다.
A. N-tier 아키텍처.
N-티어 아키텍처는 종종 n-레이어드 아키텍처와 혼동되어 논리적인 부분을 나누는 아키텍처를 설명할 때 쓰이기도 하지만 엄밀히 따지면 n-티어 아키텍처는 논리적인 모듈이 아닌 "컴포넌트들을 관심사별로 '물리적'으로 독립된 모듈로 나누어 관리하는 아키텍처" 입니다. N-티어 아키텍처는 논리적인 분할에 집중하는 레이어드 아키텍처보다 물리적인 시스템 레벨의 아키텍처를 설명하는데 사용됩니다.
또한, N-티어 아키텍처는 CS의 특정 분야에서 쓰이는 용어가 아닌 "물리적 모듈로 분리"라는 개념적인 용어로 소프트웨어 아키텍처의 여러 상황에서 쓰일 수 있고 어떤 상황에서 쓰이냐에 따라 각 티어가 어떤 것을 말하는지 조금씩 달라질 수 있습니다. 3-티어 아키텍처(3-tier Architecture) 관점에서 예시를 들어 보겠습니다.
-1. 백엔드 관점에서 예시(웹서버 + WAS + DB) (디지털데일리)
- 프레젠테이션 티어(웹서버): apache, nginx등 클라이언트의 최초 진입점 및 로드 밸런싱
- 어플리케이션 티어(WAS): 비즈니스 로직 처리. 동적 컨텐츠 생성. Tomcat등이 포함.
- 데이터 티어(DB): 데이터의 저장과 관리.
- 백엔드 관점에서 다른 n-티어 아키텍처
- 1-티어 아키텍처: 한 서버에서 비즈니스, 데이터 영속 모두 관리.
- 2-티어 아키텍처: 데이터 영속을 위한 DB서버와 데이터를 보내주는 프레젠테이션 서버.
-2. 웹개발 관점에서 예시(Client Side Application 서버 + Server Side Application 서버 + DB) (Calvin Nguyen)
- 프레젠테이션 티어(프론트엔드 서버): 클라이언트의 웹브라우저에서 실행되는 react등 프론트엔드 어플리케이션.
- 어플리케이션 티어(백엔드 서버): HTTP 서버의 역할을 하며 비즈니스 로직을 처리하는 서버.
- 데이터 티어(DB): 데이터의 저장과 관리.
- 웹개발 관점에서 다른 n-티어 아키텍처
- 1-티어 아키텍처: 한 서버에서 DB, 비즈니스 처리, 뷰 반환 처리.
- 2-티어 아키텍처: JSP/Servlet을 통한 서버사이드 랜더링 중점의 WAS 서버 + DB 서버
-3. 소프트웨어 관점에서 예시(클라이언트 컴퓨터 + 웹페이지의 서버 + DB 서버 = 웹페이지 이용)
- 프레젠테이션 티어(Client-Side): 클라이언트가 컴퓨터에서 웹페이지에 요청.
- 어플리케이션 티어(Server-Side): 웹페이지의 서버에서 응답.
- 데이터 티어(DB): 웹페이지의 DB.
- 소프트웨어 관점에서 다른 n-티어 아키텍처 (javatpoint, PerfMatrix)
- 1-티어 아키텍처: 로컬 파일서버를 이용하여 어플리케이션 동작 (데스크탑 어플리케이션, MS Office, MP3 플레이어)
- 2-티어 아키텍처: 클라이언트가 DB서버 직접 접근 (SQL를 통한 DB 서버와의 통신, 직원이 조회를 위해 서버를 사용)
B. MVC(Model-View-Controller) 패턴
MVC도 레이어드 아키텍처와 비슷하게 논리적으로 관심사를 분리하여 각 컴포넌트의 책임을 확실히 하고 유지보수성을 높입니다. 그러나 MVC는 조금 더 프레젠테이션 레이어에 집중해서 반복되는 문제를 해결하기 위한 "디자인 패턴" 입니다.(Quora, gnuoyus님) MVC는 비즈니스 로직과 UI (유저 인터페이스)간의 관심사를 분리하지만, 레이어드 아키텍처는 어플리케이션 전체를 어떻게 설계할지를 다루는 "소프트웨어 아키텍처" 입니다. 그래서 MVC 패턴을 사용하는 것은 JSP를 사용할때 처럼 비즈니스 코드와 UI의 로직이 섞여서 유지보수와 재사용성을 해치는 일을 방지하기 위함으로 프레젠테이션 계층에서 발생하는 문제를 해결합니다. (Model 1 -> Model 2, mag1c님)
MVC에서는 비즈니스를 담당하는 부분을 데이터 레이어, 비즈니스 레이어 이렇게 나누지 않고 비즈니스 로직 관련 부분을 "모델"이라는 부분으로 합쳐서 부르고, 모델 부분 보다는 UI 와 비즈니스의 관심사를 어떻게 분리할지를 다룹니다. 이는 어플리케이션 전반의 문제를 해결하기 보다는 UI와 관련된 부분적인 문제를 해결하려는 "디자인 패턴"이기 때문입니다. 또한, 아키텍처의 규칙을 따져보자면 레이어드 아키텍처는 선형적(linear)으로 고수준 레이어가 저수준 레이어를 의존 하는 것이 중요한 규칙인 데에 반해, MVC는 서로의 관심사를 나눌 뿐이지 의존관계에 대해 규칙을 정하지 않습니다. 그래서 MVC가 레이어드 아키텍처 보다 조금 더 지엽적인 문제를 다룬다고 볼 수 있습니다.
물론 복잡하지 않은 어플리케이션의 경우 MVC의 모델을 레이어드 아키텍처처럼 더 계층화 해서 나누지 않고 단순히 MVC 패턴만으로도 구현과 유지보수의 어려움이 없을 것입니다. 그렇지만 MVC 패턴이 MVC 구조, MVC 아키텍처라고도 쓰이면서 근본적으로 어떤 범위의 문제를 해결하기 위함인지 헷갈리게 사용되는 경우가 많고, 레이어드 아키텍처와 같은 개념으로 설명는 경우도 많아 개념적으로 구분하기 위해 차이점을 정리해 보았습니다.
출처
N-tier 아키텍처
디지털데일리 - 웹-WAS 아키텍처 구성, 표준 지켜야 더 안전
ResearchGate - Coordinating product and process variety of mass customized order fulfilment
Software Architecture and its types by PerfMatrix
javatpoint - 2-tier-architecture-in-dbms
FullStack Development with M.E.R.N Stack: Part1 by Calvin Nguyen
도니님의 3계층 구조(3 Tier Architecture)
N-Tier/ N-Layer Architecture by Swapnil Baxi
Juhyuck님의 3-Tier, 3-Layered Architecture
Reddit: N-Tier vs N-Layer Architecture: Are They the same? by sumologic
MVC
gnuoyus님의 [Architecture] Layered Architecture(feat. MVC 패턴)
mag1c님의 Spring MVC 구조/ MVC1 MVC2
MVC and Layered Architecture by serena-yeoh
Quora: Is MVC different from 3 layered architecture?