[스프링과 스프링 MVC] 2. 스프링 MVC는 “프론트 컨트롤러”로 움직인다

 

서블릿 MVC에서는 보통 이런 흐름이었다.

• URL마다 서블릿이 매핑된다
• 서블릿이 doGet/doPost에서 요청을 처리한다
• 필요하면 JSP로 forward/redirect 한다

스프링 MVC는 이 흐름을 더 강하게 “통제”한다.

스프링 MVC에서는 모든 요청이 반드시 DispatcherServlet을 거친다

 

DispatcherServlet은 스프링 MVC의 프론트 컨트롤러(Front-Controller)이다.

즉 “모든 요청의 입구”이다.

 

// ================================
// [Controller 예시] @GetMapping / @PostMapping
// - 서블릿의 doGet/doPost 대신 "메서드 단위"로 매핑한다
// ================================

@Controller
@RequestMapping("/todo")
@RequiredArgsConstructor
public class TodoController {

    private final TodoService todoService;

    // GET /todo/list
    @GetMapping("/list")
    public String list(Model model) {
        model.addAttribute("todos", todoService.list());
        return "todo/list"; // 뷰 이름(예: /WEB-INF/views/todo/list.jsp)
    }

    // GET /todo/register
    @GetMapping("/register")
    public String registerForm() {
        return "todo/register";
    }

    // POST /todo/register
    @PostMapping("/register")
    public String register(TodoDTO dto) { // 파라미터 바인딩(자동 수집)
        todoService.register(dto);
        return "redirect:/todo/list"; // PRG
    }
}

 

 

1) DispatcherServlet은 무엇인가

DispatcherServlet은 한 문장으로 말하면 이거다.

요청을 받아서, 어떤 컨트롤러가 처리할지 결정하고, 실행하고, 응답까지 연결하는 중앙 관제탑

 

이 구조 덕분에 스프링 MVC는 공통 처리(인터셉터, 예외 처리, 바인딩 등)를
중앙에서 일관되게 적용할 수 있다.

 

2) 서블릿의 “서블릿 단위” 매핑이, 스프링에서는 “메서드 단위” 매핑으로 바뀐다

서블릿 방식에서는 보통 URL 하나당 서블릿이 하나 매핑되는 느낌이다.

스프링 MVC에서는 컨트롤러 클래스 하나가 여러 URL을 처리하고,
그 안에서 메서드 단위로 매핑이 된다.

• @RequestMapping("/todo") : 클래스 레벨 공통 경로
• @GetMapping("/list") : GET /todo/list
• @PostMapping("/register") : POST /todo/register

즉 doGet/doPost 같은 “서블릿 라이프사이클 메서드” 대신
“요청 처리 메서드”를 여러 개 두는 구조로 바뀐다.

 

3) 스프링 MVC 요청 처리 흐름(핵심)

스프링 MVC의 큰 흐름은 이렇게 이해하면 된다.

1. 브라우저 요청이 들어오면 DispatcherServlet이 받는다
2. HandlerMapping이 “어떤 컨트롤러 메서드”가 처리할지 찾는다
3. 해당 메서드를 실행한다
4. 반환값을 해석해서 View를 렌더링하거나, 데이터로 바로 응답한다
5. response를 전송한다

즉 DispatcherServlet이 입구/출구를 통제한다.

 

4) @Controller는 무엇인가

@Controller는 스프링이 인식하는 “웹 컨트롤러 빈” 표시이다.

스프링은 component-scan을 통해 @Controller가 붙은 클래스를 빈으로 등록하고,
DispatcherServlet이 요청을 매핑할 때 이 컨트롤러들을 대상으로 찾는다.

즉 @Controller는

• 빈 등록 대상이면서
• 웹 요청 처리 대상으로도 등록되는

표시라고 보면 된다.

 

5) PRG 흐름도 스프링에서는 더 자연스럽게 표현된다

서블릿에서는 response.sendRedirect(...)를 직접 호출했다.

스프링 MVC에서는 반환 문자열로 redirect를 표현할 수 있다.

• return "redirect:/todo/list";

즉 “처리 후 redirect”가 코드에서 더 읽기 쉬운 형태로 드러난다.

 

 

핵심 정리

• 스프링 MVC는 모든 요청이 DispatcherServlet을 거치는 프론트 컨트롤러 구조이다
• URL 매핑이 서블릿 단위가 아니라 컨트롤러 메서드 단위로 세분화된다
• @Controller는 스프링 MVC 요청 처리 대상이 되는 빈 표시이다
• redirect는 "redirect:/..." 형태로 자연스럽게 표현된다