Spring MVC와 MVC 패턴 이해하기

학습 내용

Spring MVC가 왜 등장했는지, MVC 패턴이 어떤 문제를 해결하는지 알아보았다.
초반에는 단순히 3계층 아키텍처 정도로만 이해했는데, 이번 내용을 보면서 역할 분리와 유연한 구조를 만드는데 있어 더 중요한 개념을 알아보았다.

---

0. Java 웹 기술의 역사

Java 웹 개발은 다음과 같은 흐름으로 발전해왔다.

📌 한눈에 보는 흐름

  [ 1단계 ]                 [ 2단계 ]                [ 3단계 ]                [ 4단계 (Modern) ]
Servlet / JSP   👉   Servlet + JSP (MVC)   👉   MVC 프레임워크   👉   Annotation 기반 Spring MVC
(역할 혼재)             (비즈니스/화면 분리)            (구조화·표준화)          & 비동기 최적화 WebFlux

• 웹 기술은 점점 복잡한 설정은 줄이고 역할은 더 명확하게 나누고 유지보수를 높이는 방향으로 발전했다.

1. Servlet의 등장(1997)

Servlet은 Java 웹 개발의 시작점이라고 볼 수 있다.
클라이언트의 요청을 받아서 동적으로 응답을 만들어주는 서버 측 프로그램이다.

하지만 Servlet만으로 개발하면 다음과 같은 문제가 생긴다.

• 코드의 복잡성이 증가한다.
• 책임이 너무 많아진다.
• 유지보수가 어려워진다.

예를 들어, 사용자 정보를 조회하는 로직과 HTML을 직접 출력하는 코드가 한 곳에 있으면 코드가 금방 복잡해진다.

---

2. JSP의 등장(1999)

Servlet의 단점을 조금 완화하기 위해 나온 것이 JSP(Java Server Pages) 이다.

JSP는 HTML 안에 Java 코드를 삽입할 수 있게 해줘서,
Servlet에서 직접 HTML 문자열을 조립하던 방식보다 훨씬 편하게 동적으로 화면을 만들 수 있게 해줬다.

JSP의 장점

• View를 조금 더 편하게 작성할 수 있다.
• HTML 중심으로 화면을 구성할 수 있다.

JSP의 한계

• 여전히 Java 코드가 JSP 안에 들어간다.
• 비즈니스 로직이 View에 스며들 수 있다.
• 결국 역할 분리가 완전하지 않다.

→ 즉, Servlet만 쓰던 시절보다는 나아졌지만
여전히 "로직"과 "화면"이 완전히 분리되지는 않았다.

---

3. MVC 패턴이 왜 필요했을까

웹 애플리케이션에서 자주 바뀌는 것은 크게 두 가지이다.

1. 화면 구성
2. 비즈니스 요구사항

이 두 가지는 화면을 수정한다고 비즈니스 로직이 바뀌는 것도 아니고 비즈니스 로직이 바뀐다고 해서 화면이 꼭 수정된다는 것도 아니다. 근데 이 두개가 한 파일안에 섞여 있으면 수정할 때 힘들다

그래서 등장한 것이 MVC 패턴(Model View Controller) 이다.

---

4. MVC 패턴이란?

MVC 패턴은 하나의 파일이나 컴포넌트가 모든 걸 처리하던 구조를 역할별로 분리한 패턴이다.

• Controller
• Model
• View

Controller

Controller는 사용자의 요청을 받고 처리 흐름을 제어한다.

• Controller의 역할
  • HTTP 요청 수신
  • 요청 파라미터 검증
  • 비즈니스 로직 호출
  • View에 넘길 데이터 준비

실무에서는 Controller가 비즈니스 로직까지 전부 처리하지 않고,
보통 Service에 로직을 넘긴다.

Model

• Model은 View에 전달할 데이터를 담는 객체다.

• View는 이 Model에 담긴 데이터를 꺼내서 화면에 출력하기만 하면 된다.

→ 즉, View는 데이터를 어디서 가져왔는지, 어떤 비즈니스 로직을 거쳤는지 몰라도 된다.

View

View는 화면을 렌더링하는 역할을 맡는다.

여기서 중요한 점은 View는
화면을 그리는 데 집중해야 한다는 것이다.
비즈니스 로직이나 데이터 접근 로직까지 알 필요는 없다.

---

5. MVC 패턴의 핵심

MVC 패턴의 핵심은 단순히 3개로 나누는 것이 아니다.
진짜 핵심은 변경 포인트를 분리하는 것이다.

• 화면이 바뀌면 View를 수정한다.
• 요청 흐름이 바뀌면 Controller를 수정한다.
• 데이터 처리 방식이 바뀌면 Service/Repository를 수정한다.

이렇게 나누면 코드의 책임이 명확해지고,
변경이 생겨도 영향 범위를 줄일 수 있다.

---

6. Template Engine이란?

Template Engine은 정적인 HTML과 동적인 데이터를 합쳐서 최종 화면을 만들어주는 도구다.

쉽게 말하면,
"화면 틀은 HTML로 만들고, 바뀌는 데이터만 서버에서 끼워 넣는 방식"이라고 이해하면 된다.

대표적인 템플릿 엔진으로는 다음이 있다.

• Thymeleaf
• JSP
• FreeMarker
• Velocity
• Mustache

현재 Spring에서는 Thymeleaf가 많이 사용된다.
Spring과의 통합이 좋고 문법도 비교적 직관적이기 때문이다.

---

7. Spring MVC에서 ViewResolver의 역할

Controller가 요청을 처리한 뒤 "test" 같은 논리적인 View 이름을 반환하면,
Spring은 그 이름만으로 실제 JSP나 템플릿 파일을 바로 찾을 수는 없다.

이때 필요한 것이 ViewResolver다.

ViewResolver는 논리적인 View 이름을 실제 물리 경로로 변환해주는 역할을 한다.

예를 들어 아래와 같이 설정되어 있다면,

spring.mvc.view.prefix=/WEB-INF/views/
spring.mvc.view.suffix=.jsp

8. Spring Boot가 편리한 이유

Spring Boot를 사용하면 개발자가 일일이 복잡한 설정을 하지 않아도
필요한 컴포넌트들을 자동으로 등록해준다.

ViewResolver도 그중 하나다.

예전에는 직접 Bean으로 등록해야 했던 설정들을
Spring Boot가 자동으로 처리해주기 때문에
개발자는 핵심 비즈니스 로직 작성에 더 집중할 수 있다.

예를 들어 JSP를 사용하기 위한 ViewResolver도
application.properties 설정만으로 대부분 처리된다.

이런 점에서 Spring Boot는
"Spring을 더 쉽게 쓰게 해주는 도구"라는 표현이 정말 잘 어울린다.

9. 내가 이해한 Spring MVC 동작 흐름

내 기준으로 가장 쉽게 정리하면 아래 흐름이다.

클라이언트가 요청을 보낸다.
Controller가 요청을 받는다.
Controller가 비즈니스 로직을 호출한다.
결과 데이터를 Model에 담는다.
Controller가 View 이름을 반환한다.
ViewResolver가 실제 View를 찾는다.
View가 Model 데이터를 사용해 화면을 렌더링한다.
최종 HTML이 브라우저에 응답된다.
10. 이번 내용에서 중요하게 느낀 점
이번 내용을 보면서 가장 중요하다고 느낀 건
기술을 외우는 것보다 왜 이런 구조가 나왔는지 이해하는 것이었다.

Servlet만 쓰면 왜 힘든지,
JSP를 써도 왜 부족한지,
그래서 왜 MVC가 필요한지를 따라가다 보니
Spring MVC가 단순한 프레임워크가 아니라
"웹 애플리케이션을 더 잘 구조화하기 위한 결과물"이라는 게 보였다.

결국 MVC는 단순한 문법이 아니라
유지보수하기 좋은 구조를 만들기 위한 사고방식에 더 가깝다.

11. 추가로 보충하면 좋은 포인트

1) @Controller와 @RestController의 차이
헷갈리기 쉬운 부분이라 같이 정리해두면 좋다.

@Controller

주로 View를 반환할 때 사용
"post" 같은 문자열을 반환하면 View 이름으로 해석될 수 있음
@RestController

반환값을 HTTP Response Body에 그대로 담아 응답
"post"를 반환하면 View가 아니라 문자열 "post" 자체가 응답됨
즉, 화면 렌더링 중심이면 @Controller,
JSON/문자 데이터 응답 중심이면 @RestController라고 이해하면 편하다.

2) 실무에서는 Layered Architecture와 함께 본다
MVC만으로 끝나는 경우는 드물고, 보통 아래처럼 함께 본다.

Controller
Service
Repository
즉, Controller는 요청/응답 흐름 제어에 집중하고,
실제 비즈니스 로직은 Service,
DB 접근은 Repository가 맡는 식으로 더 세분화된다.

12. 한 줄 정리

Spring MVC는
웹 애플리케이션의 역할을 분리해서 유지보수성과 확장성을 높이기 위한 구조이고,
Spring Boot는 그 구조를 더 쉽게 사용할 수 있도록 도와주는 도구다.

이미지 넣기 좋은 위치
아래처럼 벨로그에 이미지 첨부하면 이해가 더 잘 된다.

추천 삽입 위치는 이 정도다.

Servlet의 문제점 설명 뒤
MVC 패턴 구조 설명 뒤
Spring MVC 동작 흐름 설명 뒤
ViewResolver 동작 순서 설명 뒤
마무리
오늘 정리하면서 느낀 점은,
Spring MVC를 배우는 건 단순히 프레임워크 사용법을 익히는 게 아니라
좋은 웹 애플리케이션 구조를 배우는 과정이라는 것이다.

다음에 Spring MVC 코드를 볼 때는
"이 코드가 Controller 역할인지",
"Model은 무엇을 담고 있는지",
"View는 어디서 렌더링되는지"를 구분해서 보면 훨씬 이해가 잘 될 것 같다.