Spring MVC흐름에 대해서 설명해주세요

[koreaioi]

Spring MVC흐름에 대해서 설명해주세요

최근에 디버깅 찍어보면서 흐름을 본 적이 있습니다.
10-20분정도면 충분하니까 디버깅 해보면서 든 본인의 생각을 적어주세요.

거창하지않아도됩니다.
"그냥 신기합니다"여도 충분합니다

[softmoca]

조금 더 디테일한 답변

Spring MVC의 요청 처리 흐름은 DispatcherServlet을 중심으로 여러 객체가 역할을 나눠 협력하는 구조입니다.
먼저 HTTP 요청이 WAS 즉 톰캣에 도달하면 서블릿 컨테이너가 HttpServletRequest와 HttpServletResponse 객체를 생성하고,
스프링이 등록한 DispatcherServlet으로 요청을 전달합니다.
DispatcherServlet은 Spring MVC의 Front Controller 역할을 하며, 모든 요청의 공통 진입점이 됩니다.

그다음 DispatcherServlet은 HandlerMapping을 통해 현재 요청 URL과 HTTP 메서드에 매핑되는 컨트롤러 메서드를 찾습니다.
대표적으로 @RequestMapping, @GetMapping, @PostMapping 같은 정보를 기반으로
컨트롤러를 찾는 RequestMappingHandlerMapping이 사용됩니다.
컨트롤러를 찾은 뒤에는 해당 컨트롤러를 실제로 호출할 수 있는 HandlerAdapter를 찾고,
일반적으로 RequestMappingHandlerAdapter가 이 역할을 수행합니다.

컨트롤러가 호출되기 전에는 Interceptor의 preHandle이 실행될 수 있습니다.
여기서 인증이나 권한 검사, 로깅 같은 공통 관심사를 처리할 수 있고,
preHandle이 false를 반환하면 컨트롤러까지 흐름이 이어지지 않고 중단됩니다.

이후 HandlerAdapter는 컨트롤러 메서드를 호출하기 위해 필요한 파라미터들을 준비합니다.
이때 ArgumentResolver가 동작해서 @RequestParam, @PathVariable, @ModelAttribute, @RequestBody 같은 파라미터를 해석합니다.
특히 @RequestBody처럼 요청 본문을 객체로 변환해야 하는 경우에는 ArgumentResolver가 HttpMessageConverter를 사용하고,
JSON 요청이라면 보통 MappingJackson2HttpMessageConverter가 JSON을 자바 객체로 역직렬화합니다.

파라미터 준비가 끝나면 실제 컨트롤러 메서드가 실행됩니다.
컨트롤러의 반환값은 다시 Spring MVC 흐름을 따라 응답으로 변환됩니다.
REST API처럼 @responsebody나 @RestController를 사용하는 경우에는
반환 객체를 HttpMessageConverter가 JSON으로 직렬화해 응답 본문에 담습니다.
반면 JSP 같은 뷰를 반환하는 방식이라면 ViewResolver가 논리적인 뷰 이름을 실제 뷰로 매핑하고, 해당 뷰가 렌더링되어 응답이 만들어집니다.

컨트롤러 실행 이후에는 Interceptor의 postHandle, afterCompletion이 이어서 호출됩니다.
정상 흐름에서는 postHandle과 afterCompletion이 모두 호출되지만,
컨트롤러에서 예외가 발생하면 postHandle은 건너뛰고 afterCompletion은 호출됩니다.
예외가 발생한 경우에는 HandlerExceptionResolver가 동작해 예외를 처리할 방법을 찾고,
@RestControllerAdvice나 @ExceptionHandler가 있다면 해당 메서드를 통해 예외를 일반적인 컨트롤러 반환처럼 응답으로 변환합니다.

Spring MVC는 요청을 받은 뒤 DispatcherServlet → HandlerMapping → HandlerAdapter → ArgumentResolver/HttpMessageConverter → Controller → HttpMessageConverter 또는 ViewResolver → Interceptor/ExceptionResolver 흐름으로 처리합니다. DispatcherServlet이 모든 요청의 입구가 되는 Front Controller 역할을 하고, 나머지 객체들이 매핑, 파라미터 해석, 메시지 변환, 예외 처리, 뷰 렌더링 같은 책임을 나눠 맡는다는 점이 스프링 MVC의 핵심입니다.

그래서 Spring MVC는 잘 분리된 객체들이 협력해 웹 요청과 응답을 처리하는 구조를 만들기 위해 OOP의 추상화와 다형성을 아주 잘 적용한 프로젝트로서
OOP 이해와 학습용으로서도 아주 좋은 예시라고 생각합니다.

[haeyoon1]

디버깅으로 여러 요청들을 보내보며 과정을 확인해 보았습니다.

`GET /reservations` 요청을 보냈을 때 과정

→ ReservationController#getReservations()가 실행됨
→ @RequestParam 값이 LocalDate, Long 타입으로 변환되어 들어옴
→ date = 2026-06-11
→ themeId = 1
→ 이제 reservationService.getReservations(date, themeId)를 호출하려는 상태

1. Spring의 형 변환

직접 date 문자열을 LocalDate로 바꾼 적이 없는데 Spring이 알아서 변환해주었습니다.

GET /reservations?date=2026-06-11&themeId=1 요청
-> LocalDate date / Long themeId controller에 들어와있음

Spring MVC는 단순히 Controller만 호출하는 게 아니라, 요청 파라미터를 읽고, 타입 변환까지 해서 메서드 인자로 넣어줍니다.

2. Spring의 프록시 사용

reservationService = ReservationService$$SpringCGLIB...

이건 실제 ReservationService 객체가 그냥 들어온 게 아니라, Spring이 프록시 객체로 감싸서 관리하고 있다는 뜻입니다.

• 순수한 객체라면 ReservationService@443cf3a6 이런식으로 보입니다
• @Transactional 같은 기능 때문에 이런 프록시가 만들어집니다
  

최종 요청 흐름:
Controller → ReservationService 프록시 → TransactionInterceptor → 실제 ReservationService 메서드 → Repository

신기하네요!

[sangjun121]

로직이 없는 api/health엔드포인트로 직접 요청을 보내 MVC 내부 흐름을 살펴보았습니다.

요청 흐름도

MVC의 진입점인 DispatcherServlet부터 컨트롤러 사이의 흐름을 집중적으로 보았습니다. 따라서 브레이크 포인트를 MVC의 시작점인 DispatcherServlet.service()에 찍고 흐름을 살펴보았습니다.

1. DispatcherServlet.service()

DispatcherServlet는 요청의 데이터를 자바의 객체로 처리하는 과정을 오케스트레이션 합니다. 대표적으로 DispatcherServlet은 들어온 요청이 어떤 컨트롤러에 매핑되야할지 핸들러를 찾고 실행하는 과정을 거친다고 알려져있는데요, 이 과정도 DispatcherServlet 내부의 doDispatch 메서드가 수행합니다.

일반적으로 저희가 알고 있는 핸들러 매핑 작업 외에도, 요청의 Path와 같은 요청의 기타 데이터들도 자바 객체로 매핑하는 역할도 하고 있음을 확인할 수 있었습니다.

2. DispatcherServlet.doDispatch()

getHandler를 통해 요청을 처리할 대상을 찾고(사진의 HealthCheckController#check()), 핸들러를 실행시킬 수 있는 어댑터를 찾습니다.(여기서는 Get 요청이었기에, 어뎁터로 RequestMappingHandlerAdapter@8054가 채택된것을 확인할 수 있었습니다.)

이후 preHandle을 통해 컨트롤러 실행전 인터셉터가 먼저 동작하여 인증 인가와 같은 비즈니스 외 필요한 로직을 먼저 처리합니다.

마지막으로 HandlerAdapter가 실제 컨트롤러 메서드를 호출합니다.

3. AbstractHandlerMethodAdapter.handle()

RequestMappingHandlerAdapter는 HandlerAdapter의 구현체입니다. 그런데 RequestMappingHandlerAdapter는 Get요청이기에 별도의 handle메서드를 정의하지 않아 부모 클래스인 AbstractHandlerMethodAdapter의 hanlde()구현을 따라갑니다. 별도의 요청값 변환과정이 없기에 내부에서 바로 컨트롤러를 호출합니다.

이후 호출된 요청은 ReturnValueHandler와 MessageConverter를 통해 HTTP응답으로 변환하고 다시 DispatcherServlet로 나오게 됩니다.

4. DispatcherServlet.processDispatchResult()

응답 결과들을 정리하는 책임을 갖고, 요청의 진입점으로 다시 나가게 됩니다.

[koreaioi]

// DispatcherServlet.doDispatch(); 요약
HandlerExecutionChain mappedHandler = getHandler(request) // 핸들러 가져오기.
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler()); // 어댑터 가져오기
mappedHandler.applyPreHandle(request, response); // Interceptor의 preHandle() 수행
mv = ha.handle(); // 1. ArgumentResolver 2. 본문수행 3. returnValueHandler
mappedHandler.applyPostHandle(request, response, mv) // Interceptor의 postHandle() 수행

triggerAfterCompletion(processedRequest, response, mappedHandler, ex); // 예외 O, 여기서 Interceptor의 afterCompletion() 수행
processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException); // 예외 X, 여기서 Interceptor의 afterCompletion() 수행

[Uechann]

Spring MVC의 흐름

Spring MVC에서 핵심은 DispatcherServlet을 기준으로 흐름을 보는게 중요하다고 생각합니다.

1. 요청 수신: DispatcherServlet으로 클라이언트 요청이 들어온다.
2. 핸들러 조회: HandlerMapping이 요청 url에 맞는 컨트롤러를 찾아준다.
3. 핸들러 실행: HandlerAdapter가 해당 컨트롤러를 실행한다. 이때 ArgumentResolver가 파라미터를 바인딩
4. 분기: 컨트롤러의 반환 형태에 따라 ReturnValueHandler에 의해 분기 된다.
5. 뷰 처리: ViewResolver가 뷰 이름을 실제 View로 변환하고, View가 모델을 렌더링한다.
6. REST 경로: HttpMessageConverter가 반환 객체를 JSON으로 직렬화후 body에 작성한다.
7. 응답 전송: 최종 렌더링 결과를 클라이언트에 응답한다.

크게 이렇게 7개로 볼 수 있을거 같습니다.