웹 애플리케이션 구조

August 21st, 2020

1. 전통적인 클라이언트/서버 구조(2-tier)

  • 클라이언트는 UI와 비지니스 처리를 담당하고, 서버는 데이터 처리만 담당하는 구조입니다.
  • 애플리케이션 구조가 클라이언트/서버 두 가지로 나뉘므로, 2 tier 구조라고도 부릅니다.
    • 여기서 서버는 DBMS와 같은 데이터베이스 서비스를 둔 서버를 말합니다.
  • 이 구조의 문제는 비지니스 로직이 클라이언트에 있기때문에, 프로그램의 변경이 있을 때마다 클라이언트가 변경된 애플리케이션을 다시 설치해야한다는 점입니다.
  • 또한, 클라이언트가 DBMS에 직접 접근하기 때문에 보안상 문제가 될 수 있습니다.
    • 접속 정보를 포함하는 애플리케이션이 많은 클라이언트에 유출되기 때문입니다.

2. 개선된 클라이언트/서버 구조(3-tier)

  • 클라이언트는 UI만 담당하고 비지니스 처리 부분을 서버로 옮긴 구조입니다.
  • 비지니스 처리를 담당하는 서버를 애플리케이션 서버라고 하며 클라이언트 대신에 DBMS 서버에 접근하여 데이터 처리를 합니다.
  • 이처럼 애플리케이션 구조가 클라이언트/애플리케이션 서버/DBMS 서버 세 가지로 나뉘므로, 3 tier 구조라고 합니다.
  • 클라이언트가 직접 데이터 베이스 접근을 하지않기 때문에, 접속 정보가 노출되는 보안 문제를 해결할 수 있습니다.
  • 또한, 애플리케이션의 비지니스 기능이 추가/변경되더라도 서버쪽에서만 변경하면 됩니다.

3. MVC 모델 구조

  • MVC 모델이란 웹 개발에 가장 많이 사용되고 있는 모델로,
  • Model-View-Controller라는 컴포넌트 별로 역할을 세분화하여 역할 간 의존성을 낮추고 조금 더 쉬운 유지보수를 할 수 있는 장점을 가집니다.
    • 쉬운 유지보수란 각 컴포넌트 별로 독립적으로 수정할 부분이 있을 때, 다른 컴포넌트와 관계없이 독립적으로 수정할 수 있다는 의미입니다.
  • MVC 모델은 MVC 모델 1과 MVC 모델 2로 두 가지가 있으며, 둘의 차이점은 다음과 같습니다.

MVC 모델 1

  • Jsp와 JavaBeans만 사용하여 웹 개발하는 방식입니다.
    • JSP에서 Controller와 View의 역할로써, 요청과 화면 모두 처리합니다.
    • JavaBeans는 Model과 같은 역할로써, 데이터 베이스 연동 등의 로직 부분을 처리합니다.
      • 보통 VO, DAO 클래스 정도들로 볼 수도 있고, 조금 비지니스 로직을 섞은 클래스들도 포함할 수 도 있습니다. 아무튼 명확히 세분화된 구조는 아닌 것 같습니다.
  • JSP에서 두 가지의 역할을 수행하다 보니, 자바 코드와 마크업 코드가 뒤섞이면서 역할 구분이 명확하지 않고 유지보수에 어려움이 생깁니다.
  • 정말 간단한 프로젝트를 수행하는 경우라면 사용할 수 있겠지만, 조금 복잡한 시스템에서는 부적절합니다.

MVC 모델 2

  • 역할이 세분화되지 않고 여러 언어의 코드가 뒤섞인 MVC 모델 1의 문제를 해결하고자 등장한 모델로써, 일반적으로 MVC 모델이라 하면 MVC 모델 2를 의미합니다.
  • Model - View - Controller 컴포넌트 별로 역할을 분리하여 개발하는 방식으로, 기존의 JSP에서 요청을 받아서 처리하는 Controller 로직을 분리하는 것이 핵심입니다.
  • 컴포넌트별로 세분화하여 개발해야 하는 부분에서 MVC 모델 1에 비해 개발비용이 높고 MVC 모델의 이해가 필요되기도 합니다.

MVC 모델 2의 컴포넌트별 역할

  • Controller
    • 클라이언트의 요청을 받아서 적절한 Model을 호출하며, View에서 생성한 화면을 다시 클라이언트로 응답하는 역할을 합니다.
    • 즉, 클라이언트의 요청을 받아 적절한 Model과 View를 호출하면서 흐름을 제어하고 응답합니다.
  • Model
    • 클라이언트에서 들어온 데이터나 사용자에게 출력할 데이터를 다루는 실제 비지니스 로직과 데이터 처리를 담당하는 역할을 힙니다.
    • 즉, 비지니스 로직과 데이터 처리를 수행합니다.
  • View
    • Controller를 통해 Model이 처리한 결과와 함께 클라이언트에 출력할 화면을 만드는 역할을 한다.
    • 즉, 클라이언트에게 출력할 화면을 생성합니다.

스프링 MVC 모델

  • 스프링 MVC 구조의 베이스는 기본적인 MVC 모델 2에서 조금 더 업그레이드 한 것으로, 각 컨트롤러들 앞에 FrontController를 추가한 구조입니다.
    • FrontController는 컨트롤러들에서 일부 중복적인 부분이나 개발자별로 개발 패턴의 차이를 보이는 부분들을 분리한 클래스로, 흔히 위임이라는 역할을 하게됩니다.
      • 위임이란 각 컨트롤러마다 필요한 개별 로직만 해당 컨트롤러에게 맡기고, 클라이언트의 요청 처리에 대한 흐름 제어를 담당하는 것을 의미합니다.
  • 즉, FrontController를 통해 컨트롤러들의 요청처리에 대한 일부 중복적인 부분을 제거해주고 개발자 별로 개발 패턴 차이를 보이는 부분을 통일시켜줍니다.
    • 개발자 별로 개발 패턴 차이를 보인다는 것은 같은 기능을 서로 다른 패턴으로 구현해놓는 것을 말합니다.
  • 위의 그림은 스프링 MVC 모델 구조의 간략한 흐름이고, 아주아주 조금 더 자세하게 보면 스프링 MVC의 흐름은 다음과 같습니다.
    • 아래 그림에서 handler란 요청 url을 담당 할 Controller의 Method를 의미합니다.