[MVC][개념]⚡ "MVC로 웹 개발의 신이 되다!" Model1 vs Model2 완벽 분석

김상욱·2024년 10월 12일

Design Pattern MVC 개념

💥 7.1 SPA (Single Page Application): 빠르고 끊김 없는 경험
🎯 7.2 MVP (Model-View-Presenter): 모든 비즈니스 로직은 여기!
⚙️ 7.3 마이크로서비스 아키텍처: 작은 서비스, 큰 성과
🌐 7.4 Jamstack: 정적인 웹의 진화
🛠️ 7.5 Headless CMS: 모든 걸 해주는 CMS의 미래

🔮 8. MVC 아키텍처의 현대적 적용

현대 기술로 완성하는 MVC의 마법!

💎 9. (추가) VO의 다양한 형태와 ORM

데이터 객체로 완성되는 아름다움

🔥 웹 애플리케이션 아키텍처 개요

🚀 웹 애플리케이션 구조: 클라이언트와 서버의 하모니

웹 애플리케이션은 클라이언트(웹 브라우저)와 서버 간의 요청과 응답을 통해 동작합니다. Java 기반의 웹 애플리케이션에서는 주로 JSP(Java Server Pages)와 Servlet을 사용하여 이러한 상호작용을 처리합니다.

웹 애플리케이션 아키텍처는 크게 두 가지 모델로 나뉩니다:

Model1 아키텍처
Model2 아키텍처 (MVC 패턴 적용)

🏗️ Model1 구조 상세 설명

🛠️ Model1의 특징: 단순함의 미학

단순 구조: JSP 페이지가 클라이언트의 요청을 받아 비즈니스 로직 처리와 뷰 렌더링을 모두 담당합니다.
역할 통합: 하나의 JSP 파일에서 데이터 처리와 화면 구성을 모두 수행하므로, 코드가 한 곳에 집중됩니다.
빠른 개발: 작은 규모의 프로젝트나 프로토타이핑에 적합하며, 빠른 개발이 가능합니다.

🔄 Model1의 작동 흐름: 단일 페이지로 모든 것을

클라이언트 요청: 사용자가 웹 브라우저에서 특정 URL에 접근합니다.
JSP 페이지 호출: 해당 URL에 매핑된 JSP 페이지가 실행됩니다.
비즈니스 로직 처리:
- JSP 페이지 내에서 스크립트릿(<% %>)이나 Java 코드를 사용하여 데이터베이스 조회, 데이터 처리 등의 로직을 수행합니다.
- Java Beans를 생성하고 조작하여 데이터를 관리할 수 있습니다.
뷰 생성 및 응답:
- JSP 페이지 내에 HTML 및 CSS 코드를 사용하여 사용자에게 보여질 화면을 구성합니다.
- 처리된 데이터를 화면에 출력하고, 최종적으로 클라이언트에게 응답합니다.

📋 Model1 예시 코드: 직접 코딩으로 체험해보세요!

<%@ page import="java.sql.*, java.util.*" %>
<html>
<head>
    <title>사용자 목록</title>
</head>
<body>
<%
    // 데이터베이스 연결 및 조회 로직
    Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/mydb", "user", "password");
    Statement stmt = conn.createStatement();
    ResultSet rs = stmt.executeQuery("SELECT * FROM users");

    // 결과를 화면에 출력
%>
<h1>사용자 목록</h1>
<ul>
<%
    while(rs.next()) {
%>
    <li><%= rs.getString("username") %> - <%= rs.getString("email") %></li>
<%
    }
    // 리소스 해제
    rs.close();
    stmt.close();
    conn.close();
%>
</ul>
</body>
</html>

위 예시에서 JSP 페이지는 데이터베이스 연결부터 결과를 출력하는 뷰 구성까지 모두 처리합니다.

⚖️ Model1 구조의 장단점

🌟 장점: 단순함이 주는 자유

개발 용이성:
- 단일 JSP 파일로 모든 처리를 하기 때문에 초보자도 쉽게 이해하고 개발할 수 있습니다.
빠른 프로토타이핑:
- 작은 규모의 애플리케이션이나 간단한 기능 구현에 적합하며, 개발 속도가 빠릅니다.
낮은 초기 비용:
- 별도의 아키텍처나 디자인 패턴을 적용하지 않아도 되므로, 초기 설정 및 학습 비용이 적습니다.

⚠️ 단점: 작은 프로젝트의 함정

유지보수 어려움:
- 로직과 뷰 코드가 혼재되어 있어, 코드의 복잡도가 증가하고 가독성이 떨어집니다.
- 수정이나 기능 추가 시 영향을 받는 부분을 파악하기 어렵습니다.
협업 비효율:
- 개발자와 디자이너가 같은 파일을 수정해야 하므로, 역할 분담이 어렵습니다.
- 버전 관리 및 충돌 발생 가능성이 높아집니다.
재사용성 감소:
- 로직이 JSP 페이지마다 분산되어 있어, 코드의 재사용이 어렵습니다.
테스트 및 확장성 문제:
- 단위 테스트나 자동화 테스트를 적용하기 어렵고, 프로젝트 규모가 커질수록 확장성이 떨어집니다.
보안 취약성:
- 데이터베이스 연결 정보나 비즈니스 로직이 노출될 가능성이 높아, 보안상 위험이 증가합니다.

🏆 Model2 구조 (MVC 패턴) 상세 설명

🧩 Model2 구조 개요: MVC의 마법

Model2 구조는 MVC 패턴(Model-View-Controller)을 웹 애플리케이션 개발에 적용한 형태로, 각 구성 요소의 역할을 명확히 분리하여 유지보수성과 확장성을 향상시킵니다.

Model: 비즈니스 로직과 데이터 처리를 담당합니다.
View (JSP): 사용자에게 보여지는 화면을 구성합니다.
Controller (Servlet): 클라이언트의 요청을 해석하고 적절한 Model과 View를 연결합니다.

또한 계층으로 분리할 수도 있습니다.

Presentation Layer (화면 계층): 사용자에게 정보를 표시하고 입력을 받는 계층입니다.
Business Layer (비즈니스 계층): 애플리케이션의 핵심 로직을 처리하는 계층입니다.
Persistence Layer (데이터 계층): 데이터의 저장 및 관리를 담당하는 계층입니다.

유지보수성 향상: 각 계층이 독립적으로 변경될 수 있어 수정이 용이합니다.
확장성 강화: 새로운 기능 추가 및 성능 개선이 수월합니다.
역할 분담 명확화: 개발 팀 내에서 각자의 역할이 명확해져 협업이 효율적입니다.

🔍 MVC 구성 요소 설명: 조각을 맞춰 완성하는 퍼즐

MVC 별 구성 요소와 역할

💡 Model: 데이터와 비즈니스의 심장

비즈니스 로직 처리:
- 데이터베이스 접근, 데이터 검증, 계산 등 애플리케이션의 핵심 로직을 수행합니다.
- Service 클래스와 DAO(Data Access Object) 클래스로 구성됩니다.
데이터 관리:
- Java Beans나 VO(Value Object)를 사용하여 데이터 객체를 생성하고 관리합니다.

🎨 View: 사용자와 소통하는 얼굴

사용자 인터페이스 구성:
- HTML, CSS, JavaScript 등을 사용하여 사용자에게 보여질 화면을 구성합니다.
- 표현 로직만을 포함하며, 비즈니스 로직은 포함하지 않습니다.
데이터 표시:
- Controller로부터 전달받은 데이터를 화면에 출력합니다.
- JSTL(JSP Standard Tag Library)이나 EL(Expression Language)을 사용하여 데이터를 표현합니다.

🎮 Controller: 모든 요청을 지휘하는 마에스트로

요청 처리 및 흐름 제어:
- 클라이언트의 요청을 받아들이고, 어떤 작업을 수행할지 결정합니다.
- 적절한 Service 클래스(Model)를 호출하여 비즈니스 로직을 수행합니다.
결과 전달 및 View 선택:
- Model로부터 받은 결과를 Request나 Session에 저장합니다.
- 어떤 View를 사용할지 결정하고, RequestDispatcher를 통해 해당 JSP로 포워딩합니다.

계층별 구성 요소와 역할

클라이언트 (Client)

역할: 웹 애플리케이션의 최종 사용자로서, 웹 브라우저를 통해 서버에 요청을 보냅니다.
작동 방식:
- 사용자는 웹 브라우저에서 URL을 입력하거나 링크를 클릭하여 서버에 HTTP 요청을 전송합니다.
- Context Object (VO)를 통해 서버와 데이터를 주고받습니다.

Value Object (VO)

정의: 데이터를 담는 단순한 객체로, 주로 값을 전달하는 데 사용됩니다.
특징:
- 불변성(Immutable)을 가지며, 데이터의 상태를 보존합니다.
- 로직을 포함하지 않고, 속성(Property)과 Getter 메서드로만 구성됩니다.

컨트롤러 (Controller - Servlet)

역할: 클라이언트의 요청을 받아들이고, 적절한 비즈니스 로직을 호출하며, 결과를 뷰에 전달하는 중앙 제어 장치입니다.
작동 방식:
1. 요청 수신: 클라이언트로부터의 요청을 받아들입니다.
2. 데이터 추출 및 DTO 생성:
  - 요청 파라미터를 추출하여 Data Transfer Object (DTO)에 담습니다.
3. 비즈니스 로직 호출:
  - DTO를 전달하여 Business Logic Object를 호출합니다.
4. 결과 처리 및 뷰로 전달:
  - 비즈니스 로직의 처리 결과를 받아 Request 객체에 저장합니다.
  - 적절한 JSP(View)로 포워딩 또는 리다이렉트합니다.

Data Transfer Object (DTO)

정의: 계층 간 데이터 교환을 위해 사용하는 객체로, 여러 데이터를 하나의 객체로 묶어서 전달합니다.
특징:
- VO와 유사하지만, DTO는 주로 데이터 전송에 초점을 맞춥니다.
- Getter와 Setter 메서드를 통해 데이터를 읽고 쓸 수 있습니다.

비즈니스 계층 (Business Layer)

역할: 애플리케이션의 핵심 비즈니스 로직을 처리합니다.
구성 요소:
- Business Logic Object (Service 클래스): 비즈니스 규칙을 적용하여 데이터를 처리하고, 필요한 경우 DAO를 호출합니다.
- Entity (VO): 데이터베이스에서 가져온 데이터를 담는 객체로, 비즈니스 로직에서 사용됩니다.

Business Logic Object (Service 클래스)

기능:
- 비즈니스 로직을 구현하여 데이터 처리 및 검증을 수행합니다.
- 트랜잭션 관리 등 비즈니스 관련 작업을 처리합니다.

Entity (VO)

정의: 데이터베이스의 테이블과 매핑되는 객체로, 데이터의 상태를 표현합니다.
특징:
- 비즈니스 로직을 포함하지 않고, 데이터 속성과 Getter/Setter로 구성됩니다.
- ORM 프레임워크에서 엔티티 클래스로 사용됩니다.

데이터 접근 객체 및 영속성 계층 (DAO & Persistence Layer)

DAO (Data Access Object):
- 역할: 데이터베이스와의 상호작용을 담당하며, 비즈니스 계층에 데이터 접근 메서드를 제공합니다.
- 기능:
  - CRUD(Create, Read, Update, Delete) 작업을 수행합니다.
  - SQL 쿼리를 실행하거나 ORM을 사용하여 데이터베이스와 통신합니다.
Persistence Layer (영속성 계층):
- 역할: 데이터의 영구 저장 및 관리를 담당합니다.
- 특징:
  - 데이터베이스의 구체적인 구현을 추상화하여 상위 계층이 데이터 저장소의 종류에 의존하지 않도록 합니다.

ORM (Object-Relational Mapping)

정의: 객체 지향 프로그래밍 언어의 객체와 관계형 데이터베이스의 테이블을 매핑하는 기술입니다.
장점:
- SQL 쿼리를 직접 작성하지 않아도 데이터베이스 작업이 가능합니다.
- 데이터베이스 독립성을 향상시켜 다양한 DBMS에 적용할 수 있습니다.
예시: Hibernate, JPA(Java Persistence API)

데이터베이스 관리 시스템 (DBMS)

역할: 데이터를 영구적으로 저장하고 관리하는 시스템입니다.
기능:
- 데이터의 저장, 수정, 삭제, 검색 등의 작업을 지원합니다.
- 데이터 무결성, 보안, 동시성 제어 등을 제공합니다.
예시: MySQL, PostgreSQL, Oracle, SQL Server

프레젠테이션 계층 (Presentation Layer - JSP)

역할: 사용자에게 정보를 표시하고, 사용자로부터 입력을 받는 뷰(View) 역할을 합니다.
작동 방식:
- 컨트롤러로부터 전달된 데이터를 이용하여 HTML 페이지를 생성합니다.
- JSP (Java Server Pages)는 동적인 웹 페이지를 생성하기 위한 기술로, HTML 코드 내에 Java 코드를 삽입할 수 있습니다.
특징:
- 비즈니스 로직을 포함하지 않고, 표현 로직에 집중합니다.
- JSTL (JSP Standard Tag Library)와 EL (Expression Language)를 사용하여 데이터 표현을 단순화합니다.

📈 Model2의 동작 과정: 데이터 흐름의 마스터클래스

전체 흐름

클라이언트 요청:
- 사용자가 웹 브라우저를 통해 특정 URL에 접근하거나, 폼을 제출하여 서버에 HTTP 요청을 보냅니다.
컨트롤러(Servlet) 처리:
- Servlet이 요청을 받아들입니다.
- 요청 파라미터를 추출하여 DTO에 저장합니다.
- 비즈니스 로직 처리를 위해 Business Logic Object를 호출합니다.
비즈니스 계층 처리:
- Service 클래스가 비즈니스 로직을 수행합니다.
- 필요한 경우 DAO를 호출하여 데이터베이스와 상호작용합니다.
DAO 및 데이터베이스 상호작용:
- DAO가 데이터베이스에 접근하여 필요한 데이터를 조회하거나 변경합니다.
- ORM을 사용하여 객체와 데이터베이스 간의 매핑을 처리합니다.
결과 반환 및 컨트롤러로 복귀:
- DAO는 결과를 Entity (VO)에 담아 Service 클래스에 반환합니다.
- Service 클래스는 비즈니스 로직 처리를 마치고 결과를 컨트롤러에 반환합니다.
뷰로 데이터 전달:
- 컨트롤러는 결과 데이터를 Request 객체나 Session 객체에 저장합니다.
- 적절한 JSP(View)를 선택하여 포워딩합니다.
응답 생성 및 클라이언트로 전달:
- JSP는 전달된 데이터를 사용하여 HTML 페이지를 생성합니다.
- 생성된 페이지는 웹 서버를 통해 클라이언트에게 응답으로 전달됩니다.
클라이언트 응답 처리:
- 사용자의 웹 브라우저는 서버로부터 받은 HTML을 렌더링하여 사용자에게 표시합니다.

시각적 흐름

[Client] --(HTTP Request)--> [Controller (Servlet)] --(DTO)--> [Business Layer (Service)] --(Entity/VO)--> [DAO] --(SQL/ORM)--> [DBMS]
[DBMS] --(Data)--> [DAO] --(Entity/VO)--> [Business Layer (Service)] --(Result)--> [Controller (Servlet)]
[Controller (Servlet)] --(Data)--> [View (JSP)] --(HTTP Response)--> [Client]

📚 Model2 예시 코드: 실전으로 이해하는 MVC

📑 Controller 예시: 첫 단추 끼우기

@WebServlet("/user/list")
public class UserListController extends HttpServlet {
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // 비즈니스 로직 처리
        UserService userService = new UserService();
        List<User> userList = userService.getUserList();

        // 결과를 Request에 저장
        request.setAttribute("users", userList);

        // View로 포워딩
        RequestDispatcher dispatcher = request.getRequestDispatcher("/WEB-INF/views/userList.jsp");
        dispatcher.forward(request, response);
    }
}

📊 Model (Service 및 DAO) 예시: 데이터와의 협업

UserService.java

public class UserService {
    private UserDAO userDAO = new UserDAO();

    public List<User> getUserList() {
        // 비즈니스 로직 수행
        return userDAO.selectAllUsers();
    }
}

UserDAO.java

public class UserDAO {
    public List<User> selectAllUsers() {
        // 데이터베이스 연결 및 조회 로직
        List<User> userList = new ArrayList<>();
        // JDBC 코드로 데이터 조회 후 userList에 추가
        return userList;
    }
}

🖥️ View (JSP) 예시: UI를 손쉽게

userList.jsp

<%@ page contentType="text/html;charset=UTF-8" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<html>
<head>
    <title>사용자 목록</title>
</head>
<body>
<h1>사용자 목록</h1>
<ul>
    <c:forEach var="user" items="${users}">
        <li>${user.name} - ${user.email}</li>
    </c:forEach>
</ul>
</body>
</html>

⚖️ Model2 구조의 장단점

🌠 장점: 팀워크와 확장성의 정석

역할 분리로 인한 유지보수 용이성:
- 각 계층(Model, View, Controller)이 명확히 분리되어 있어 코드의 가독성이 높아집니다.
- 수정이 필요한 부분만 집중적으로 변경할 수 있어 유지보수 비용이 감소합니다.
협업 효율성 증가:
- 개발자들이 자신의 역할에 집중할 수 있어 생산성이 향상됩니다.
  - 프론트엔드 개발자는 뷰(View)에 집중합니다.
  - 백엔드 개발자는 컨트롤러와 비즈니스 로직에 집중합니다.
  - 데이터베이스 관리자는 데이터 계층에 집중합니다.
- 역할이 명확히 분리되어 팀 단위의 협업이 원활합니다.
재사용성과 확장성 향상:
- 공통 로직이나 컴포넌트를 재사용할 수 있어 개발 효율이 높아집니다.
- 새로운 기능 추가 시 기존 구조를 활용하여 확장성이 우수합니다.
- ORM 등의 기술을 도입하여 데이터 계층을 개선할 수 있습니다.
테스트 용이성:
- 비즈니스 로직과 화면이 분리되어 있어 단위 테스트와 통합 테스트를 수행하기 쉽습니다.

⛔ 단점: 구조가 복잡해도 괜찮을까?

구조의 복잡성 증가:
- MVC 패턴과 각 계층의 역할을 이해해야 하므로 초기에 학습해야 할 내용이 많습니다.
- 작은 규모의 프로젝트에서는 과도한 구조로 느껴질 수 있습니다.
개발 시간 증가:
- 계층별로 코드를 작성해야 하므로 초기 개발 시간이 증가할 수 있습니다.
- 그러나 장기적으로는 유지보수 시간의 감소로 보완됩니다.
성능 오버헤드:
- 계층 간의 데이터 전달로 인해 약간의 성능 저하가 발생할 수 있습니다.

⚔️ Model1과 Model2 비교

구분	Model1	Model2 (MVC 패턴)
구조	JSP에 모든 로직과 뷰가 포함됨	Model, View, Controller로 역할 분리
유지보수성	코드 복잡도가 높아 유지보수 어려움	역할 분리로 유지보수가 용이함
개발 난이도	초보자도 쉽게 접근 가능	초기 학습이 필요하며 구조가 복잡함
확장성	프로젝트 규모가 커지면 관리 어려움	대규모 프로젝트에도 구조적 확장이 용이함
협업 효율성	역할 분담이 어려워 협업에 불리함	개발자와 디자이너의 역할이 분리되어 협업에 유리함

🌍 다양한 웹 개발 아키텍처 소개

웹 개발에서 MVC를 항상 사용하지 않는 이유

프로젝트의 복잡도와 규모

단순한 웹 사이트: 개인 블로그나 포트폴리오 사이트처럼 기능이 단순한 웹사이트에서는 MVC 패턴을 적용하는 것이 과도할 수 있습니다. 이러한 사이트들은 주로 정적 콘텐츠를 제공하며, 복잡한 비즈니스 로직이 없습니다.

예시:
- 개인 블로그: 글을 작성하고 보여주는 단순한 기능
- 포트폴리오 사이트: 자신의 작업물을 소개하는 정적 페이지
복잡도 증가: MVC 패턴은 구조가 체계적이지만, 작은 프로젝트에서는 불필요한 복잡성을 초래할 수 있습니다. 파일과 디렉토리 구조가 늘어나고, 설정해야 할 부분이 많아져 개발 효율이 떨어질 수 있습니다.

유지보수 및 개발 비용

초기 설정의 복잡성: MVC 패턴을 적용하면 프로젝트 설정에 시간이 많이 소요됩니다. 컨트롤러, 모델, 뷰를 각각 구성하고 연결해야 하며, 이는 작은 프로젝트에서는 비용 대비 효과가 낮을 수 있습니다.
개발 속도 저하: 작은 팀이나 개인 개발자의 경우, MVC 패턴을 적용하면 개발 속도가 느려질 수 있습니다. 단순한 기능을 구현하는데도 여러 계층을 거쳐야 하므로 생산성이 저하될 수 있습니다.

프레임워크에 의존

프레임워크의 필요성: MVC 패턴은 Spring, Django, Ruby on Rails 등과 같은 프레임워크에서 쉽게 구현할 수 있습니다. 그러나 이러한 프레임워크를 사용하지 않는다면 MVC 구조를 수동으로 구현해야 하며, 이는 개발자에게 부담이 될 수 있습니다.
기술 스택 제한: 특정 프레임워크에 의존하면 기술 스택이 제한될 수 있습니다. 팀원들이 해당 프레임워크에 익숙하지 않다면 학습 시간이 필요하며, 이는 프로젝트 일정에 영향을 미칠 수 있습니다.

다른 웹 개발 아키텍처와 사용 사례

💥 SPA (Single Page Application): 빠르고 끊김 없는 경험

특징

클라이언트 측 렌더링: SPA는 한 개의 HTML 페이지로 구성되며, JavaScript를 사용하여 동적으로 콘텐츠를 변경합니다.
빠른 사용자 경험: 페이지 전환 시 전체 페이지를 다시 로드하지 않고 필요한 부분만 업데이트하므로, 앱과 유사한 빠른 인터랙션을 제공합니다.
상태 관리: 클라이언트 측에서 상태를 관리하며, Redux, Vuex와 같은 상태 관리 라이브러리를 사용합니다.

기술 스택

프론트엔드 프레임워크: React, Vue.js, Angular 등이 주로 사용됩니다.
백엔드: 서버는 주로 REST API 또는 GraphQL API를 제공하며, 클라이언트는 이 API를 통해 데이터를 가져옵니다.

MVC와의 차이

뷰 관리 위치: MVC에서는 서버 측에서 뷰를 렌더링하지만, SPA에서는 클라이언트 측에서 뷰를 관리합니다.
페이지 전환 방식: MVC는 페이지 이동 시 서버로부터 새로운 페이지를 받아오지만, SPA는 동적으로 콘텐츠를 변경합니다.

사용 사례

대화형 웹 애플리케이션: 이메일 클라이언트(Gmail), 소셜 미디어(Facebook), 프로젝트 관리 도구(Trello) 등 복잡한 사용자 인터페이스를 필요로 하는 애플리케이션에서 사용됩니다.

🎯 MVP (Model-View-Presenter): 모든 비즈니스 로직은 여기!

특징

Presenter의 역할: Presenter는 View와 Model 간의 중개자로서, 모든 비즈니스 로직을 처리하고 View와의 상호작용을 관리합니다.
테스트 용이성: View와 Presenter가 분리되어 있으므로, 단위 테스트가 용이합니다.

MVC와의 차이

Controller vs Presenter: MVC의 Controller는 주로 사용자 입력을 처리하고 모델과 뷰를 업데이트하는 반면, MVP의 Presenter는 더 많은 로직을 포함하며 View의 인터페이스를 통해 View를 업데이트합니다.

사용 사례

모바일 애플리케이션 개발: Android 개발에서 Activity나 Fragment가 View 역할을 하고, Presenter가 로직을 처리합니다. 이는 View의 수명 주기와 비즈니스 로직을 분리하여 코드의 안정성을 높입니다.

⚙️ 마이크로서비스 아키텍처: 작은 서비스, 큰 성과

특징

서비스 분리: 애플리케이션을 독립적인 작은 서비스들로 분리하여 개발 및 배포합니다.
독립적인 배포 및 확장: 각 서비스는 독립적으로 배포될 수 있으며, 필요에 따라 개별적으로 확장할 수 있습니다.
다양한 기술 스택: 각 서비스는 다른 프로그래밍 언어나 데이터베이스를 사용할 수 있습니다.

MVC와의 차이

아키텍처 수준의 차이: MVC는 애플리케이션의 구조를 정의하는 패턴인 반면, 마이크로서비스는 시스템 전체의 아키텍처를 정의합니다.
서비스 간 통신: 마이크로서비스에서는 서비스 간에 API 호출을 통해 통신하며, 이는 분산 시스템의 특성을 가집니다.

사용 사례

대규모 엔터프라이즈 애플리케이션: Netflix, Amazon 등 복잡하고 대규모의 서비스를 제공하는 기업에서 사용합니다. 마이크로서비스 아키텍처를 통해 개발 팀이 서비스별로 독립적으로 작업할 수 있으며, 시스템의 유연성과 확장성을 높입니다.

🌐 Jamstack: 정적인 웹의 진화

특징

정적 사이트 생성: 빌드 시점에 정적인 HTML 파일을 생성하여 서버에 배포합니다.
빠른 로딩 속도: 정적 파일은 CDN(Content Delivery Network)을 통해 제공되므로, 빠른 로딩 시간을 보장합니다.
보안성 향상: 서버 측에서 동적으로 콘텐츠를 생성하지 않으므로, 서버 사이드 공격의 위험이 감소합니다.

기술 스택

정적 사이트 생성기: Gatsby, Next.js, Hugo 등
Headless CMS: Contentful, Strapi 등을 사용하여 콘텐츠를 관리하고 API로 제공합니다.

MVC와의 차이

서버 측 로직 부재: Jamstack은 서버 측 로직이 거의 없거나 아예 없는 구조입니다.
동적 기능 처리: 필요한 동적 기능은 API 호출이나 서드파티 서비스를 통해 처리합니다.

사용 사례

블로그, 마케팅 사이트: 빠른 로딩과 SEO 최적화가 중요한 블로그나 기업 웹사이트에서 사용됩니다.

🛠️ Headless CMS: 모든 걸 해주는 CMS의 미래

특징

백엔드와 프론트엔드의 분리: 콘텐츠 관리 시스템(CMS)은 데이터만 관리하며, 프론트엔드는 API를 통해 데이터를 가져와 표시합니다.
프론트엔드 자유도: 개발자는 원하는 프론트엔드 기술을 사용하여 사용자 인터페이스를 자유롭게 구성할 수 있습니다.

MVC와의 차이

완전한 분리: MVC는 서버 측에서 View를 렌더링하지만, Headless CMS는 프론트엔드와 백엔드가 완전히 분리되어 있습니다.
데이터 제공 방식: Headless CMS는 API를 통해 데이터를 제공하므로, 모바일 앱이나 다른 서비스에서도 동일한 데이터를 사용할 수 있습니다.

사용 사례

이커머스 사이트: 제품 정보와 재고 관리 등은 백엔드에서 처리하고, 프론트엔드는 다양한 플랫폼(웹, 모바일 등)에서 데이터를 가져와 표시합니다.
콘텐츠 관리 시스템: 여러 채널에 콘텐츠를 배포해야 하는 경우(예: 웹사이트, 모바일 앱, 디지털 사이니지 등)

언제 MVC를 선택할까?

역할 분담이 중요할 때

팀 협업: 백엔드 개발자와 프론트엔드 개발자가 명확하게 역할을 분담하여 작업해야 할 때 MVC 패턴이 유용합니다.
유지보수성 향상: 각 계층이 분리되어 있으므로, 한 부분의 변경이 다른 부분에 최소한의 영향을 줍니다.

복잡한 비즈니스 로직 관리

트랜잭션 처리: 은행 시스템이나 ERP처럼 복잡한 비즈니스 로직과 데이터 일관성이 중요한 경우
검증과 계산: 다양한 검증 로직과 복잡한 계산이 필요한 애플리케이션에서 Model 계층을 통해 로직을 관리합니다.

유지보수와 확장성이 중요한 장기 프로젝트

장기 프로젝트: 프로젝트 기간이 길고, 기능 추가 및 변경이 자주 발생하는 경우
스케일링 필요: 사용자 수 증가에 대비하여 애플리케이션을 수평적으로 확장해야 할 때

서버 사이드 렌더링이 필요한 애플리케이션

SEO 최적화: 검색 엔진 최적화가 중요한 경우 서버 측에서 HTML을 렌더링하여 크롤러가 콘텐츠를 쉽게 수집할 수 있도록 합니다.
전통적인 웹 애플리케이션: 서버에서 뷰를 렌더링하고, 클라이언트는 단순히 HTML을 받아 표시하는 구조가 적합한 경우

결론

프로젝트 특성에 맞는 아키텍처 선택: 모든 웹 개발 프로젝트에 MVC 패턴이 최적은 아닙니다. 프로젝트의 규모, 복잡도, 팀 구성, 기술 요구사항 등을 고려하여 적합한 아키텍처를 선택해야 합니다.
작고 단순한 프로젝트:
- MVC의 복잡성이 오히려 생산성을 저하시킬 수 있습니다.
- 정적 사이트 생성기, 단순한 HTML/CSS/JavaScript 조합, 또는 Jamstack이 더 효율적일 수 있습니다.
복잡한 애플리케이션:
- MVC 패턴을 통해 코드의 모듈화와 유지보수성을 향상시킬 수 있습니다.
- 마이크로서비스 아키텍처를 고려하여 확장성과 유연성을 높일 수 있습니다.
현대 웹 개발 경향:
- SPA와 Headless CMS의 조합으로 사용자 경험을 향상시키고, 백엔드와 프론트엔드의 개발 효율성을 높입니다.

추가 정보

아키텍처 선택 시 고려사항

팀의 기술 역량: 팀원들이 익숙한 기술 스택과 패턴을 사용하는 것이 생산성을 높입니다.
프로젝트의 수명 주기: 단기 프로젝트인지, 장기적인 유지보수가 필요한 프로젝트인지에 따라 선택이 달라집니다.
성능 요구사항: 로딩 속도, 반응성 등 성능이 중요한 경우 적합한 아키텍처를 선택해야 합니다.
보안 요구사항: 민감한 데이터를 다루는 경우 보안에 강한 구조를 선택해야 합니다.

혼합된 접근법

Backend for Frontend (BFF):
- 모바일 앱과 웹 애플리케이션이 각각의 백엔드를 가지도록 설계하여 최적화된 데이터를 제공합니다.
Progressive Web Apps (PWA):
- 웹 애플리케이션에 모바일 앱의 기능(오프라인 접근, 푸시 알림 등)을 추가하여 사용자 경험을 향상시킵니다.
Serverless Architecture:
- 서버 관리를 필요로 하지 않고, 클라우드 서비스의 함수(FaaS)를 활용하여 백엔드 로직을 구현합니다.

🔮 MVC 아키텍처의 현대적 적용

현대적인 웹 개발과 MVC

Spring Framework:
- Spring MVC는 MVC Model2 구조를 기반으로 한 프레임워크로, 복잡한 웹 애플리케이션 개발을 지원합니다.
- Spring Boot를 사용하면 초기 설정을 간소화하여 빠르게 프로젝트를 시작할 수 있습니다.
프론트엔드 프레임워크와의 결합:
- 최근에는 React, Angular, Vue.js와 같은 프론트엔드 프레임워크를 사용하여 클라이언트 측에서 뷰를 처리하는 경우가 많습니다.
- 이 경우 서버 측에서는 RESTful API를 제공하고, 클라이언트 측 애플리케이션이 API를 통해 데이터를 받아와 렌더링합니다.

계층 간 통신 방식

DTO와 VO의 구분 및 사용:
- DTO (Data Transfer Object): 계층 간 데이터 전달에 사용되며, 비즈니스 로직이나 데이터를 처리하는 메서드를 포함하지 않습니다.
- VO (Value Object): 불변의 속성을 가지며, 주로 값 자체를 표현하는 데 사용됩니다.
계층 간 의존성 관리:
- 상위 계층은 하위 계층에 의존하지만, 하위 계층은 상위 계층에 의존하지 않는 단방향 의존성을 유지합니다.
- 인터페이스와 의존성 주입(DI)을 활용하여 유연성을 높일 수 있습니다.

디자인 패턴의 활용

페이저네이션 패턴:
- 대량의 데이터를 효율적으로 처리하기 위해 페이지 단위로 데이터를 가져오는 방식입니다.
싱글톤 패턴:
- 애플리케이션 내에서 하나의 인스턴스만 존재하도록 하는 디자인 패턴으로, 주로 DAO나 Service 객체에서 사용됩니다.
팩토리 패턴:
- 객체 생성 로직을 캡슐화하여 객체 생성을 담당하는 팩토리 클래스를 통해 객체를 생성합니다.

💎 (추가) VO의 다양한 형태와 ORM

VO (Value Object)

Value Object(VO)는 데이터를 담는 객체로, 주로 시스템 간 데이터를 전달할 때 사용됩니다.
VO는 단순한 값 객체로, 상태를 갖지 않으며 한 번 생성되면 불변하는 특징이 있습니다. 값만을 담고 있기 때문에, 주로 데이터 전달을 위한 목적에 사용됩니다.
특징:
- 불변성: VO는 한 번 값이 설정되면 변경되지 않습니다.
- 값 비교: VO 객체는 참조가 아닌 값 자체로 비교됩니다. (객체의 속성들이 같은 경우 동등하다고 간주)
- 데이터베이스의 테이블에 있는 레코드 한 줄과 비슷한 역할을 합니다.

사용 예시:

public class PersonVO {
    private String name;
    private int age;

    // 생성자
    public PersonVO(String name, int age) {
        this.name = name;
        this.age = age;
    }

    // getter 메서드
    public String getName() { return name; }
    public int getAge() { return age; }

    // equals, hashCode 메서드 재정의 (값 비교를 위해)
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        PersonVO personVO = (PersonVO) o;
        return age == personVO.age && name.equals(personVO.name);
    }

    @Override
    public int hashCode() {
        return Objects.hash(name, age);
    }
}

Context Object (VO)

Context Object는 특정 요청이나 세션 등의 상태나 환경적인 정보를 담아 전달하는 VO입니다.
보통 웹 애플리케이션에서 클라이언트의 요청이나 세션 정보를 담아 다음 계층(Controller나 Service 계층)으로 넘기기 위해 사용합니다.

Context Object 사용 목적:

클라이언트의 세션 상태, 요청 헤더, 인증 정보 등을 담아 컨트롤러나 서비스 계층에 전달합니다.
클라이언트와 서버 간의 요청-응답 과정에서 상황에 맞는 데이터를 유지하고 전달합니다.

사용 예시:

public class RequestContextVO {
    private String sessionId;
    private String authToken;
    private Map<String, String> headers;

    public RequestContextVO(String sessionId, String authToken, Map<String, String> headers) {
        this.sessionId = sessionId;
        this.authToken = authToken;
        this.headers = headers;
    }

    // getter 메서드들
    public String getSessionId() { return sessionId; }
    public String getAuthToken() { return authToken; }
    public Map<String, String> getHeaders() { return headers; }
}

DTO (Data Transfer Object)

DTO는 데이터 전송을 위한 객체로, 주로 클라이언트와 서버 간, 또는 시스템 간에 데이터를 전달할 때 사용됩니다.
DTO는 비즈니스 로직 없이 단순히 데이터를 캡슐화하고 운반하는 역할만 합니다.
데이터베이스와 상호작용하거나 서버 간 통신 시 네트워크 비용을 줄이기 위해 필요한 데이터만 전송합니다.

DTO의 특징:

데이터 전송에 필요한 최소한의 정보를 담고 있습니다.
데이터베이스의 엔티티와 구조적으로 유사할 수 있지만, DTO는 비즈니스 로직과 분리되어 오직 데이터 전달만을 담당합니다.

사용 예시:

public class UserDTO {
    private String username;
    private String email;
    private String phoneNumber;

    // 생성자
    public UserDTO(String username, String email, String phoneNumber) {
        this.username = username;
        this.email = email;
        this.phoneNumber = phoneNumber;
    }

    // getter, setter 메서드들
    public String getUsername() { return username; }
    public String getEmail() { return email; }
    public String getPhoneNumber() { return phoneNumber; }
}

Entity (VO)

Entity는 데이터베이스 테이블과 1:1로 매핑되는 객체입니다.
Entity는 영구적인 데이터를 저장하고 관리하기 위해 설계된 객체로, ORM(Object-Relational Mapping)을 통해 데이터베이스와 상호작용합니다.
Entity는 일반적으로 데이터베이스의 테이블과 매핑되며, 데이터의 영속성을 관리합니다.

Entity의 특징:

CRUD 작업에서 중요한 역할을 합니다.
Entity 객체는 비즈니스 로직을 포함할 수 있으며, 데이터의 상태를 영구적으로 유지하는 것이 목표입니다.

사용 예시 (JPA 사용 시):

@Entity
@Table(name = "users")
public class UserEntity {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(name = "username", nullable = false)
    private String username;

    @Column(name = "email", nullable = false)
    private String email;

    // 기본 생성자 및 getter, setter 메서드들
    public UserEntity() {}

    public UserEntity(String username, String email) {
        this.username = username;
        this.email = email;
    }

    public Long getId() { return id; }
    public String getUsername() { return username; }
    public String getEmail() { return email; }
}

ORM (Object-Relational Mapping)

ORM은 객체 지향 프로그래밍에서 객체와 데이터베이스 테이블 간의 매핑을 자동으로 처리해주는 기술입니다.
ORM을 사용하면 SQL을 직접 작성하지 않고 객체 지향 언어의 코드만으로 데이터베이스와 상호작용할 수 있습니다.
ORM의 주요 역할:
- 객체를 테이블에 매핑해 SQL 쿼리 없이 데이터베이스와 상호작용
- 영속성 관리: 객체의 상태를 영구적으로 저장, 삭제, 수정
- 대표적인 ORM 도구로는 Hibernate, JPA, EclipseLink 등이 있습니다.

ORM 사용 예시 (JPA와 Hibernate):

@Entity
@Table(name = "orders")
public class OrderEntity {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne
    @JoinColumn(name = "user_id", nullable = false)
    private UserEntity user;

    @Column(name = "order_total", nullable = false)
    private Double orderTotal;

    // 기본 생성자 및 getter, setter
    public OrderEntity() {}

    public OrderEntity(UserEntity user, Double orderTotal) {
        this.user = user;
        this.orderTotal = orderTotal;
    }

    // getter, setter 메서드들
    public Long getId() { return id; }
    public UserEntity getUser() { return user; }
    public Double getOrderTotal() { return orderTotal; }
}

김상욱

이전 포스트

[Computer Science][Database] 🔍 Elastic Search vs. RDBMS LIKE: 검색의 끝을 보다!

다음 포스트

[MVC][개념]⚡ "MVC로 웹 개발의 신이 되다!" Model1 vs Model2 완벽 분석

목차

🔥 웹 애플리케이션 아키텍처 개요

🚀 웹 애플리케이션 구조: 클라이언트와 서버의 하모니

🏗️ Model1 구조 상세 설명

🛠️ Model1의 특징: 단순함의 미학

🔄 Model1의 작동 흐름: 단일 페이지로 모든 것을

📋 Model1 예시 코드: 직접 코딩으로 체험해보세요!

⚖️ Model1 구조의 장단점

🌟 장점: 단순함이 주는 자유

⚠️ 단점: 작은 프로젝트의 함정

🏆 Model2 구조 (MVC 패턴) 상세 설명

🧩 Model2 구조 개요: MVC의 마법

🔍 MVC 구성 요소 설명: 조각을 맞춰 완성하는 퍼즐

MVC 별 구성 요소와 역할

💡 Model: 데이터와 비즈니스의 심장

🎨 View: 사용자와 소통하는 얼굴

🎮 Controller: 모든 요청을 지휘하는 마에스트로

계층별 구성 요소와 역할

클라이언트 (Client)

Value Object (VO)

컨트롤러 (Controller - Servlet)

Data Transfer Object (DTO)

비즈니스 계층 (Business Layer)

Business Logic Object (Service 클래스)

Entity (VO)

데이터 접근 객체 및 영속성 계층 (DAO & Persistence Layer)

ORM (Object-Relational Mapping)

데이터베이스 관리 시스템 (DBMS)

프레젠테이션 계층 (Presentation Layer - JSP)

📈 Model2의 동작 과정: 데이터 흐름의 마스터클래스

전체 흐름

시각적 흐름

📚 Model2 예시 코드: 실전으로 이해하는 MVC

📑 Controller 예시: 첫 단추 끼우기

📊 Model (Service 및 DAO) 예시: 데이터와의 협업

🖥️ View (JSP) 예시: UI를 손쉽게

⚖️ Model2 구조의 장단점

🌠 장점: 팀워크와 확장성의 정석

⛔ 단점: 구조가 복잡해도 괜찮을까?

⚔️ Model1과 Model2 비교

🌍 다양한 웹 개발 아키텍처 소개

웹 개발에서 MVC를 항상 사용하지 않는 이유

프로젝트의 복잡도와 규모

유지보수 및 개발 비용

프레임워크에 의존

다른 웹 개발 아키텍처와 사용 사례

💥 SPA (Single Page Application): 빠르고 끊김 없는 경험

특징

기술 스택

MVC와의 차이

사용 사례

🎯 MVP (Model-View-Presenter): 모든 비즈니스 로직은 여기!

특징

MVC와의 차이

사용 사례

⚙️ 마이크로서비스 아키텍처: 작은 서비스, 큰 성과

특징

MVC와의 차이

사용 사례

🌐 Jamstack: 정적인 웹의 진화

특징

기술 스택

MVC와의 차이

사용 사례

🛠️ Headless CMS: 모든 걸 해주는 CMS의 미래

특징

MVC와의 차이

사용 사례

언제 MVC를 선택할까?

역할 분담이 중요할 때

복잡한 비즈니스 로직 관리

유지보수와 확장성이 중요한 장기 프로젝트

서버 사이드 렌더링이 필요한 애플리케이션

결론

추가 정보

아키텍처 선택 시 고려사항

혼합된 접근법

최신 트렌드와 기술

🔮 MVC 아키텍처의 현대적 적용