흐름 단계를 외워서 나열하는지, 아니면 각 컴포넌트가 왜 그 자리에 있는지를 책임 단위로 풀어내는지를 가른다.
요청은 DispatcherServlet으로 진입해 HandlerMapping이 대상 핸들러를 찾고, HandlerAdapter가 컨트롤러 메서드를 실행한다. 파라미터 바인딩은 ArgumentResolver가, 반환값 처리는 ReturnValueHandler가 맡는다. 뷰 이름을 반환하면 ViewResolver가 뷰를 렌더링하고, @ResponseBody나 HttpEntity처럼 본문을 직접 반환하면 HttpMessageConverter가 직렬화한다. 같은 진입점에서 반환 타입에 따라 뷰 렌더링 경로와 메시지 변환 경로로 갈린다.
장애 로그를 보고 어느 단계에서 깨졌는지 짚어 본 경험이 있다면 DispatcherServlet 이후 파이프라인 이해와 연결할 수 있다
@ResponseBody와 뷰 반환을 섞어 쓰다가 응답 형식이 어긋난 사례가 있다면 두 처리 경로 분기 설명으로 풀어낼 수 있다
커스텀 ArgumentResolver나 HttpMessageConverter를 직접 끼워 넣어 본 경험을 핸들러 단계의 책임 분리 이해와 엮을 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.