Spring

DispatcherServlet 요청 흐름에 대해서 설명해주세요

Spring MVC의 핵심인 DispatcherServlet이 HTTP 요청을 처리하는 전체 흐름을 인터랙티브 시각화로 단계별로 학습합니다. HandlerMapping, HandlerAdapter, ViewResolver, 인터셉터 체인의 역할과 실행 순서를 면접 답변 수준으로 정복합니다.

2026년 3월 21일 · 약 12분 읽기

TL;DR

  • DispatcherServlet은 모든 HTTP 요청을 받는 단일 진입점 — 프론트 컨트롤러(Front Controller) 패턴의 구현체
  • — 요청 흐름: HandlerMapping(누가 처리?) → HandlerAdapter(어떻게 실행?) → 인터셉터 체인 → Controller → ViewResolver(어떤 화면?) 순서
  • — 인터셉터의 preHandle은 등록 순서대로, postHandle·afterCompletion은 역순으로 실행된다
  • @RestController는 ViewResolver를 거치지 않고 HttpMessageConverter가 JSON으로 직렬화하여 응답한다
  • Filter는 Servlet Container 레벨, Interceptor는 Spring Context 레벨 — Spring Bean 접근 가능 여부가 핵심 차이

Q. "Spring MVC에서 HTTP 요청이 들어왔을 때 DispatcherServlet이 처리하는 전체 흐름을 설명해주세요. HandlerMapping, HandlerAdapter, 인터셉터, ViewResolver가 각각 어떤 역할을 하는지도 함께 말씀해주세요."

예상 꼬리질문

답변 가이드

"DispatcherServlet은 Spring MVC에서 모든 HTTP 요청을 단일 진입점에서 받아 처리를 조율하는 프론트 컨트롤러(Front Controller) 패턴의 구현체입니다. 기존 서블릿 방식에서는 URL마다 별도 서블릿을 등록해야 했지만, DispatcherServlet은 모든 요청을 하나의 서블릿이 받아 적절한 핸들러로 위임합니다."

"요청이 들어오면 HandlerMapping으로 어떤 Controller가 처리할지 결정하고, HandlerAdapter를 통해 해당 Controller를 실행합니다. Controller 실행 전후에는 인터셉터 체인이 동작하며, Controller가 View 이름을 반환하면 ViewResolver가 실제 View 객체로 변환하여 렌더링합니다. @ResponseBody가 있으면 ViewResolver 대신 HttpMessageConverter가 JSON으로 직렬화하여 응답합니다."

"실무에서는 인증·인가 로직을 인터셉터의 preHandle에 구현하여 Controller 진입 전에 검증합니다. Filter와 달리 인터셉터는 Spring ApplicationContext 안에서 동작하므로 @Autowired로 Spring Bean을 자유롭게 사용할 수 있습니다. 또한 afterCompletion은 예외가 발생해도 반드시 호출되므로 리소스 정리에 적합합니다."

면접에서 "Spring MVC 동작 원리"를 물었을 때 "@Controller, @RequestMapping을 쓰면 됩니다"라고 답하면 탈락입니다. 면접관이 정말 듣고 싶은 건 DispatcherServlet이 어떻게 요청을 받아 Controller까지 전달하고, 인터셉터가 어디서 끼어드는지입니다.

이 아티클에서는 요청 처리 흐름을 인터랙티브 시각화로 단계별로 눌러보며, 면접 답변에 바로 쓸 수 있는 수준으로 익혀봅니다.


1. DispatcherServlet — 모든 요청의 단일 진입점

꼬리질문: "DispatcherServlet이 프론트 컨트롤러 패턴인 이유가 무엇인가요?"

Spring MVC 이전의 서블릿 방식에서는 /users,/orders,/products 마다 별도 서블릿을 등록해야 했습니다. 인증, 로깅, 인코딩 같은 공통 로직이 모든 서블릿에 중복되었죠. 프론트 컨트롤러(Front Controller) 패턴은 이 문제를 해결합니다. 단 하나의 서블릿이 모든 요청을 받아 공통 처리 후 적절한 핸들러에게 위임합니다.

두 방식의 차이를 탭으로 전환하며 확인하세요.

프론트 컨트롤러 패턴

기존 서블릿 방식과 프론트 컨트롤러 방식을 비교해보세요.

클라이언트
├──
/users
UserServlet
인증로깅인코딩
├──
/orders
OrderServlet
인증로깅인코딩
├──
/products
ProductServlet
인증로깅인코딩

인증, 로깅, 인코딩 같은 공통 로직이 모든 서블릿에 중복됩니다.


2. 요청 처리 전체 흐름 — 9단계

꼬리질문: "HTTP 요청이 들어왔을 때 처리되는 전체 흐름을 설명해주세요"

DispatcherServlet의 doDispatch() 메서드가 실제로 요청을 처리합니다. HandlerMapping으로 핸들러를 찾고, HandlerAdapter로 실행하고, ViewResolver로 뷰를 결정하는 전 과정이 이 메서드 안에서 순서대로 일어납니다.

단계 번호를 클릭하거나 버튼으로 이동하며 각 단계의 담당 컴포넌트와 역할을 확인하세요.

요청 처리 전체 흐름

단계를 클릭하거나 버튼으로 이동하며 각 단계의 역할을 확인하세요.

1 / 9

HTTP 요청 수신

담당 컴포넌트
DispatcherServlet
역할

doDispatch() 메서드 진입. 모든 요청의 단일 진입점으로, 이후 처리를 조율합니다.

코드 힌트
protected void doDispatch(
  HttpServletRequest request,
  HttpServletResponse response
) throws Exception { ... }

3. HandlerMapping vs HandlerAdapter — 역할 분리의 이유

꼬리질문: "HandlerMapping과 HandlerAdapter의 역할 차이는 무엇인가요?"

HandlerMapping은 "어떤 Controller가 처리할지" 결정하고, HandlerAdapter는 "그 Controller를 어떻게 실행할지" 담당합니다. Controller 구현 방식이 @RequestMapping 어노테이션, HttpRequestHandler 인터페이스 등 다양하기 때문에 HandlerAdapter가 이 차이를 추상화합니다.

카드를 클릭하여 각 구현체의 역할을 확인하세요. 둘 다 선택하면 HandlerExecutionChain 구조가 표시됩니다.

HandlerMapping vs HandlerAdapter

각 카드를 클릭하여 역할 분리를 확인하세요. 둘 다 선택하면 연결 흐름이 표시됩니다.

HandlerMapping — 탐색: 누가?
중재자
DispatcherServlet
HandlerAdapter — 실행: 어떻게?

4. 인터셉터 체인 — preHandle, postHandle, afterCompletion

꼬리질문: "인터셉터의 preHandle, postHandle, afterCompletion은 각각 언제 사용하나요?"

인터셉터(Interceptor)는 Controller 실행 전후에 공통 로직을 수행하는 미들웨어입니다. preHandle은 Controller 실행 전, postHandle은 실행 후 뷰 렌더링 전, afterCompletion은 렌더링 완료 후 항상 실행됩니다.

인터셉터가 여러 개 등록됐을 때 preHandle은 등록 순서대로, postHandleafterCompletion은 역순으로 실행됩니다.

시나리오를 선택하고 실행하여 인터셉터 체인의 동작 순서를 확인하세요.

인터셉터 체인 시뮬레이션

시나리오를 선택하고 실행하여 인터셉터 체인의 동작을 확인하세요.

AuthInterceptor
preHandle()
postHandle()
afterCompletion()
LoggingInterceptor
preHandle()
postHandle()
afterCompletion()
Controller
handle()
시나리오를 선택하고 실행 버튼을 누르세요.

5. Filter vs Interceptor — 무엇이 다른가

꼬리질문: "Filter와 Interceptor의 차이점은 무엇인가요?"

필터(Filter)는 Tomcat 같은 서블릿 컨테이너 레벨에서 동작하고, 인터셉터(Interceptor)는 Spring ApplicationContext 레벨에서 동작합니다. 인터셉터는 Spring Bean을 @Autowired로 자유롭게 주입받을 수 있어 실무 인증·인가 로직에 적합합니다.

레이어를 클릭하여 동작 위치와 특성 차이를 확인하세요.

Filter vs Interceptor

레이어를 클릭하여 동작 위치와 특성을 확인하세요.

Servlet Container (Tomcat)
Filter Chain ← 클릭하여 상세 확인
Spring ApplicationContext
DispatcherServlet
Interceptor Chain ← 클릭하여 상세 확인
Controller
항목FilterInterceptor
동작 위치Servlet Container (Tomcat)Spring ApplicationContext
Spring Bean 접근어려움 (DelegatingFilterProxy 필요)가능 (@Autowired)
적용 범위모든 요청 + 정적 자원DispatcherServlet 이후 요청
주요 용도인코딩, XSS 필터, CORS인증/인가, 로깅, 세션 검사

6. ViewResolver와 @ResponseBody — 두 갈래 응답 처리

꼬리질문: "@RestController를 사용하면 ViewResolver는 어떻게 되나요?"

@Controller가 String(View 이름)을 반환하면 ViewResolver가 실제 View 파일을 찾아 렌더링합니다.@RestController처럼@ResponseBody가 붙으면 ViewResolver를 건너뛰고 HttpMessageConverter가 반환 객체를 JSON으로 직렬화하여 응답 바디에 직접 씁니다.

토글로 두 경로를 전환하며 응답 처리 흐름을 비교하세요.

ViewResolver vs HttpMessageConverter

어노테이션에 따라 응답 처리 경로가 달라집니다. 토글로 전환해 확인하세요.

@Controller — String(View 이름) 반환 → ViewResolver → View.render() → HTML
Controller 실행 완료
String("home") 반환
ViewResolver
/WEB-INF/views/home.jsp
View.render()
HTML 응답
코드 예시
@Controller
public class HomeController {
    @GetMapping("/home")
    public String home() {
        return "home"; // ViewResolver가 처리
        // → /WEB-INF/views/home.jsp 렌더링
    }
}

자주 발생하는 문제

퀴즈로 확인하기

개념을 제대로 이해했는지 확인해 보세요.

퀴즈 1

인터셉터 preHandle 실행 순서

// 다음과 같이 인터셉터를 등록했을 때,
// preHandle은 어떤 순서로 실행될까요?

registry.addInterceptor(loggingInterceptor);  // 1번째 등록
registry.addInterceptor(authInterceptor);     // 2번째 등록
퀴즈 2

예외 발생 시 afterCompletion 호출 여부

// Controller에서 예외가 발생했습니다.
// 다음 중 호출되는 메서드는?

AuthInterceptor.preHandle()  // → true 반환
Controller.handle()          // → NullPointerException 발생!
퀴즈 3

@RestController는 ViewResolver를 거칠까요?

@RestController
public class UserController {
    @GetMapping("/users/1")
    public User getUser() {
        return new User(1L, "홍길동");
    }
}
// 이 응답은 어떻게 처리될까요?
퀴즈 4

JWT 토큰 검증을 어디에 구현해야 할까요?

// JWT 토큰 검증 로직에서
// Spring Bean을 사용해야 합니다.

@Component
public class JwtTokenProvider {
    public boolean validate(String token) { ... }
}

// 더 적합한 구현 위치는?
퀴즈 5

@GetMapping을 처리하는 HandlerAdapter는?

// 다음 Controller 메서드를 실행할 때
// 사용되는 HandlerAdapter는 무엇일까요?

@GetMapping("/users/{id}")
public User getUser(@PathVariable Long id) {
    return userService.findById(id);
}

면접 체크리스트

이 항목들을 자신 있게 설명할 수 있다면 DispatcherServlet 질문은 준비 완료입니다.

  • DispatcherServlet: 프론트 컨트롤러 패턴으로 모든 요청을 단일 진입점에서 처리
  • HandlerMapping: URL → Handler 탐색, HandlerExecutionChain(Handler + Interceptors) 반환
  • HandlerAdapter: Handler 실행 방법 추상화, 파라미터 바인딩·타입 변환·유효성 검사 담당
  • 인터셉터 순서: preHandle(등록 순서) → Controller → postHandle(역순) → afterCompletion(역순, 항상)
  • ViewResolver vs HttpMessageConverter: 템플릿 렌더링 경로 vs JSON 직렬화 경로
  • Filter vs Interceptor: Servlet Container 레벨 vs Spring Context 레벨, Spring Bean 접근 여부

참고 자료


의견을 들려주세요

서비스 개선에 큰 도움이 됩니다. 익명으로 자유롭게 남겨주세요.

0 / 1000