조용한 개발 노트

Spring Web은 단순히 Controller를 만드는 기술이 아니라, HTTP 요청이 애플리케이션 내부를 통과하는 전체 흐름을 정의한 프레임워크다.이 글에서는 지금까지 살펴본 구성 요소들을 하나의 흐름으로 묶고, 실무에서 어떤 선택을 해야 하는지 기준을 정리한다.1. Spring Web 요청 처리 전체 흐름Spring Web MVC 기준으로, HTTP 요청은 다음 순서로 처리된다.브라우저 또는 클라이언트가 HTTP 요청을 전송한다Filter가 요청을 가장 먼저 가로챈다DispatcherServlet이 모든 요청의 진입점이 된다HandlerMapping이 요청을 처리할 Controller를 찾는다HandlerAdapter가 Controller 실행을 준비한다ArgumentResolver가 메서드 파라미..

Spring Web을 다루다 보면, 반드시 한 번은 마주치는 질문이 있다.“Spring Web MVC로 충분한데, WebFlux는 왜 존재할까?”Spring WebFlux는 Spring Web MVC의 대체재가 아니라, 서로 다른 실행 모델을 제공하는 또 하나의 선택지다.이 글에서는 Spring WebFlux가 등장한 배경과 실행 모델의 차이를 살펴보고, 실무에서 언제 WebFlux를 선택해야 하는지 기준을 정리한다.1. Spring Web MVC의 실행 모델 다시 보기Spring Web MVC는 서블릿 기반의 블로킹 I/O 모델을 사용한다.요청 처리 방식은 비교적 단순하다.요청 1건당 스레드 1개가 할당된다해당 스레드는 요청 처리 전체를 담당한다I/O 작업 동안 스레드는 대기 상태가 된다이 모델은 구현..

브라우저에서 API를 호출하다 보면, 서버 로직과는 무관하게 요청이 차단되는 상황을 자주 마주한다.콘솔에는 다음과 같은 메시지가 출력된다.“Blocked by CORS policy”이 문제는 Spring 코드의 버그가 아니라, 브라우저 보안 정책과 HTTP 응답 설계의 문제다.이 글에서는 Same-Origin Policy가 무엇인지, CORS는 왜 필요한지, 그리고 Spring Web에서 이 문제를 어디서 해결해야 하는지 정리한다.1. Same-Origin Policy란 무엇인가?Same-Origin Policy는 브라우저가 기본적으로 적용하는 보안 정책이다.여기서 Origin은 다음 세 가지 요소의 조합이다.프로토콜 (http / https)호스트 (도메인)포트이 세 가지 중 하나라도 다르면, 브라우저..

웹 애플리케이션에서 요청 처리만큼 중요한 것이 응답을 어떻게 반환할 것인가다.응답은 단순히 데이터를 전달하는 수단이 아니라, 서버의 처리 결과를 HTTP라는 규약에 맞게 표현하는 책임을 가진다.Spring Web MVC는 이 역할을 위해 ResponseEntity라는 명확한 도구를 제공한다.1. HTTP 응답이 의미하는 것HTTP 응답은 크게 세 가지 요소로 구성된다.상태 코드(Status Code)헤더(Header)본문(Body)이 중에서 상태 코드는 요청 처리 결과를 가장 압축적으로 표현하는 정보다.예를 들어,200 OK → 정상 처리400 Bad Request → 클라이언트 요청 오류404 Not Found → 리소스 없음500 Internal Server Error → 서버 오류Spring Web..

웹 애플리케이션에서는 모든 요청에 공통으로 적용해야 하는 로직이 존재한다.인증 및 인가요청/응답 로깅트랜잭션 경계 설정요청 컨텍스트 초기화Spring Web MVC는 이러한 횡단 관심사를 처리하기 위해 Filter와 Interceptor라는 두 가지 확장 지점을 제공한다.이 글에서는 두 컴포넌트의 역할과 차이를 정리하고, 어떤 경우에 무엇을 선택해야 하는지 기준을 잡아본다.1. Filter의 위치와 역할Filter는 서블릿 컨테이너 레벨에서 동작하는 컴포넌트다.HTTP 요청이 DispatcherServlet에 도달하기 전에, 또는 응답이 클라이언트로 나가기 전에 Filter 체인을 거친다.DispatcherServlet 이전 단계에서 실행ServletRequest / ServletResponse 기반Sp..

요청 데이터가 Controller 메서드의 파라미터로 정상적으로 변환되었다면, 다음으로 고려해야 할 것은 입력 값이 올바른지, 그리고 문제가 발생했을 때 이를 어떻게 응답할 것인지다.Spring Web MVC는 이 두 문제를 Validation과 Exception Handling이라는 메커니즘으로 분리해 다룬다.1. Validation의 역할Validation은 요청 데이터가 비즈니스 로직을 수행하기에 적절한 상태인지 검증하는 과정이다.여기서 중요한 점은, Validation이 에러 처리의 시작점이라는 것이다.형식이 잘못된 요청필수 값이 누락된 요청허용 범위를 벗어난 값이런 문제들은 비즈니스 로직이 실행되기 전에 차단되어야 한다.2. Bean Validation 기반 검증Spring Web MVC는 Be..

Spring Web MVC의 Controller 메서드를 보면, 요청 데이터가 별다른 코드 없이도 메서드 파라미터로 자연스럽게 전달되는 것처럼 보인다.@PathVariable, @RequestParam, @RequestBody 같은 어노테이션이 자동으로 동작하는 이유는, Spring Web 내부에서 ArgumentResolver와 HttpMessageConverter가 역할을 나누어 처리하기 때문이다.이 글에서는 요청 데이터가 Controller 메서드의 파라미터로 변환되는 전체 과정을 두 컴포넌트 중심으로 정리한다.1. Controller 메서드 파라미터는 누가 채우는가?HandlerAdapter가 Controller를 실행할 때, 가장 먼저 해결해야 할 문제는 다음이다.이 메서드의 파라미터들은 어디서..

DispatcherServlet이 모든 HTTP 요청의 진입점이라는 사실을 이해했다면, 다음으로 궁금해지는 것은 Spring이 수많은 Controller 중에서 어떤 기준으로 하나를 선택하고, 어떤 방식으로 실행하는가이다.이 역할을 담당하는 핵심 구성 요소가 HandlerMapping과 HandlerAdapter다.이 글에서는 이 두 컴포넌트가 Spring Web MVC 요청 처리 과정에서 어떤 책임을 가지고 협력하는지 정리한다.1. 역할 분리가 필요한 이유HTTP 요청을 처리하기 위해서는 크게 두 단계가 필요하다.이 요청을 처리할 대상은 누구인가?그 대상을 어떤 방식으로 실행할 것인가?Spring Web MVC는 이 두 책임을 HandlerMapping과 HandlerAdapter로 명확하게 분리한다...

Spring Web MVC에서 모든 HTTP 요청은 DispatcherServlet을 통해 처리된다. Controller가 직접 요청을 받는 것처럼 보이지만, 실제로는 DispatcherServlet이 요청의 시작점이자 중심이다.이 글에서는 DispatcherServlet이 어떤 역할을 하는지, 그리고 HTTP 요청이 들어온 뒤 어떤 순서로 처리되는지를 Spring 공식 문서의 흐름에 따라 정리한다.1. DispatcherServlet의 정체DispatcherServlet은 Spring Web MVC의 핵심 구성 요소로, Front Controller 패턴을 구현한 서블릿이다.Front Controller 패턴이란, 모든 요청을 하나의 진입점에서 받아 공통 처리 로직을 거친 뒤 적절한 핸들러로 위임하는 ..

Spring Web은 Spring Framework에서 HTTP 요청을 애플리케이션 코드로 연결하는 웹 계층을 담당한다.이 글에서는 Spring Web이 무엇을 책임지는지, 그리고 Spring이 웹 요청을 처리하기 위해 어떤 구조와 실행 모델을 선택했는지를 공식 문서의 관점에서 정리한다.1. Spring Web의 역할Spring Web의 가장 핵심적인 역할은 클라이언트로부터 들어오는 HTTP 요청(Request)을 애플리케이션 내부의 코드 흐름으로 전달하고, 그 처리 결과를 다시 HTTP 응답(Response)으로 변환하는 것이다.이를 위해 Spring Web은 다음과 같은 책임을 가진다.URL과 HTTP 메서드를 기준으로 요청을 처리할 핸들러(Controller)를 선택한다요청 파라미터, 경로 변수, ..