조용한 개발 노트

22편에서는 Security Filter Chain이 어떤 필터들로 구성되어 있고, 인증과 인가가 어떤 순서로 처리되는지를 살펴봤습니다.이번 글에서는“그럼 JWT 인증은 이 필터 체인 안에서 실제로 어떻게 동작할까?”라는 질문에 답해보겠습니다.이 글의 목표는 JWT 문법을 설명하는 것이 아니라, 요청 하나가 들어왔을 때 JWT가 어디서 읽히고, 언제 인증이 완료되는지를 명확히 이해하는 것입니다.1. JWT 인증의 전제JWT 기반 인증의 가장 큰 특징은서버가 세션을 저장하지 않는다는 점입니다.즉,요청마다 토큰을 보내고요청마다 인증을 수행하는 구조입니다.그래서 JWT 인증은반드시 Filter 단계에서 처리되어야 합니다.2. 요청이 들어오면 가장 먼저 보는 것JWT 인증이 적용된 API로 요청이 들어오면, S..

21편에서는 Spring Security가 Filter 기반 보안 프레임워크이며, 요청이 Spring MVC로 들어오기 전 가장 앞단에서 동작한다는 점을 살펴봤습니다.이번 글에서는“그럼 Security는 정확히 어떤 Filter들을, 어떤 순서로 실행할까?”라는 질문에 답해보겠습니다.1. Security Filter Chain의 본질Spring Security는 단일 필터가 아니라,여러 개의 Filter가 체인 형태로 연결된 구조로 동작합니다.이를 Security Filter Chain이라고 부르며, 각 필터는인증인가세션 관리예외 처리중 하나의 책임만 가집니다.2. 필터 체인은 어디서 시작될까모든 Security Filter Chain의 시작점은DelegatingFilterProxy입니다.이 필터는 서블..

20편에서는 Filter vs Interceptor를 통해 요청 흐름에서 두 컴포넌트가 어디에 위치하고 무엇을 책임지는지 정리했습니다.이번 글에서는 그 위에서 동작하는 Spring Security가요청을 어디서 가로채고, 어떤 순서로 인증·인가를 수행하는지를 요청 흐름 기준으로 정리해보겠습니다.1. 가장 중요한 결론부터Spring Security의 핵심은 이 한 줄로 요약할 수 있습니다.Spring Security는 Filter 기반 보안 프레임워크다즉,DispatcherServlet 이전Spring MVC보다 앞단에서 요청을 보호합니다.그래서:컨트롤러까지 가지 못하는 요청이 생기고Interceptor가 실행되지 않는 경우도 발생할 수 있습니다.2. Security는 어디에 끼어들까요청 흐름을 단순화하면..

19편에서는 Spring MVC의 요청 처리 흐름을 DispatcherServlet부터 ExceptionResolver까지 한 장으로 정리했습니다.이번 글에서는 그 흐름 위에서 많이 헷갈리는 두 존재,FilterInterceptor가 정확히 어디에서, 어떤 역할을 맡는지를 구조 기준으로 정리해보겠습니다.1. 가장 먼저 정리해야 할 결론Filter와 Interceptor의 차이는 기능 차이가 아니라 위치와 책임 차이입니다.Filter – 서블릿 레벨, Spring 바깥Interceptor – Spring MVC 내부이 한 줄을 기준으로 보면 대부분의 혼란이 사라집니다.2. Filter는 어디에 위치할까Filter는DispatcherServlet 앞단에 위치합니다.즉,Spring MVC를 타기 전서블릿 컨테..

12편부터 18편까지 우리는 Spring MVC에서 하나의 웹 요청이어디서 시작되고어떤 단계를 거쳐어디서 실패하거나 성공하는지를 구성 요소별로 나누어 살펴봤습니다.이번 글에서는 그 내용을 “한 장의 흐름”으로 다시 묶어,지금 이 에러는 어느 단계에서 발생한 걸까?를 바로 떠올릴 수 있도록 정리해보겠습니다.1. Spring MVC 요청 처리의 큰 흐름Spring MVC의 요청 처리 흐름은 다음과 같이 요약할 수 있습니다.DispatcherServlet – 모든 요청의 진입점HandlerMapping – 누가 처리할지 결정HandlerAdapter – 어떻게 실행할지 결정ArgumentResolver – 파라미터 생성Validation – 입력값 검증컨트롤러 메서드 실행ReturnValueHandler – ..

17편에서는 ExceptionResolver를 통해 요청 처리 중 발생한 예외가 어디서, 어떤 순서로 HTTP 응답으로 변환되는지를 살펴봤습니다.이번 글에서는 그보다 한 단계 앞에서 동작하는 검증(Validation)에 대해 다뤄보겠습니다.잘못된 요청은 컨트롤러 로직까지 가야 할까?Spring MVC의 대답은 “아니다” 입니다.1. Spring MVC에서 Validation의 위치Validation은 요청 처리 흐름에서 컨트롤러 메서드가 실행되기 전에 수행됩니다.정확한 위치를 정리하면 다음과 같습니다.HandlerMapping – 컨트롤러 선택HandlerAdapter – 실행 준비ArgumentResolver – 파라미터 생성Validation – 생성된 파라미터 검증컨트롤러 메서드 실행즉, Valid..

16편에서는 HttpMessageConverter를 통해 요청/응답 본문(JSON)이 어디에서 변환되는지를 살펴봤습니다.이번 글에서는 요청 처리 중 예외가 발생했을 때, Spring MVC가이 예외를 어디서 잡고, 어떤 응답으로 바꿀지 를 결정하는 과정을 구조적으로 정리해보겠습니다.1. Spring MVC에서 예외는 어디서 발생할까예외는 요청 처리 전 과정에서 발생할 수 있습니다.ArgumentResolver 단계 (파라미터 바인딩 실패)HttpMessageConverter 단계 (JSON 파싱 실패)컨트롤러 메서드 내부서비스 / 트랜잭션 계층중요한 점은,예외가 어디서 발생했든 DispatcherServlet까지 전파된다는 것입니다.2. 예외를 처리하는 주체: HandlerExceptionResolver..

15편에서는 ArgumentResolver가 컨트롤러 메서드의 파라미터를 어떻게 만들어주는지를 살펴봤습니다.그 과정에서 특히 눈에 띄는 파라미터가 하나 있었습니다.@RequestBody는 다른 파라미터들과 뭔가 다르게 동작한다이번 글에서는 그 “다른 동작”의 정체, 즉 HttpMessageConverter가 언제, 어디서, 왜 호출되는지를 구조적으로 정리해보겠습니다.1. HttpMessageConverter의 역할HttpMessageConverter는 한 문장으로 정의할 수 있습니다.HTTP 메시지 바디와 Java 객체 사이의 변환을 담당하는 컴포넌트즉,요청 본문(JSON → 객체)응답 본문(객체 → JSON)을 처리하는 책임을 가집니다.중요한 점은,HttpMessageConverter는 컨트롤러의 책임..

14편에서는 HandlerAdapter가 HandlerMapping이 선택한 컨트롤러를 실제로 실행하기 위한 “실행 전략”이라는 점을 살펴봤습니다.이번 글에서는 컨트롤러 실행 과정에서 가장 많은 개발자가 궁금해하는 질문을 다뤄보겠습니다.@RequestParam, @PathVariable, @RequestBody 같은 값들은 도대체 언제, 어디서 만들어질까? 이 질문에 대한 답이 바로 ArgumentResolver입니다.1. ArgumentResolver의 역할ArgumentResolver의 공식적인 이름은HandlerMethodArgumentResolver 입니다.이 인터페이스의 역할은 단순합니다.컨트롤러 메서드의 파라미터 하나를 실제 값으로 변환해주는 역할 즉, 컨트롤러 메서드의 각 파라미터마다이 파라..

13편에서는 HandlerMapping이 요청 정보를 기준으로 어떤 컨트롤러가 이 요청을 처리할지 결정하는 과정을 살펴봤습니다.하지만 컨트롤러를 “찾았다”고 해서 곧바로 메서드를 실행할 수 있는 것은 아닙니다.찾은 컨트롤러를 어떤 방식으로 실행해야 할까? 이 질문에 대한 Spring MVC의 해답이 바로 HandlerAdapter입니다.1. HandlerAdapter의 역할HandlerAdapter는 한 문장으로 정리할 수 있습니다.HandlerMapping이 선택한 핸들러를 실제로 실행할 수 있게 “연결”해주는 역할 즉,누가 처리할지는 HandlerMapping어떻게 실행할지는 HandlerAdapter로 역할이 명확히 분리되어 있습니다.2. 왜 DispatcherServlet이 직접 실행하지 않을까D..