코드 땜장이

스프링 MVC에서 @RequestBody와 @ModelAttribute를 어떻게 구분해 써야 할까 목차 왜 둘이 자주 헷갈릴까 요청은 어디서 읽히는가 내부 동작은 어떻게 다를까 @RequestBody 가 맞는 상황과 코드 예시 @ModelAttribute 가 맞는 상황과 코드 예시 설정까지 함께 봐야 하는 이유 curl 로 보면 차이가 더 분명해진다 검증과 예외 처리에서 주의할 점 실무에서는 어떤 기준으로 고르면 될까 빠른 답 JSON 본문을 DTO로 받는다면 대부분 @RequestBody를 사용합니다. 쿼리스트링, 폼 전송, multipart/form-data를 객체로 묶을 때는 @ModelAttribute가 더 자연스럽습니다. 둘의 차이는 문법보다 Content-Type, 바인딩 대상, 내부 변환기 흐름에서 갈립니다. 파일 업로드와 일반 필드를 함께 받는 요청은 @ModelAttribute 쪽이 실무에서 더 자주 쓰입니다. 빠른 답 application/json 본문을 DTO로 받는 요청이라면 보통 @RequestBody 를 사용합니다. 쿼리스트링, application/x-www-form-urlencoded , multipart/form-data 를 객체로 묶을 때는 @ModelAttribute 가 더 자연스럽습니다. 둘의 차이는 문법보다 데이터를 어디서 읽는지, 그리고 어떤 바인딩 경로를 타는지에 있습니다. 파일 업로드가 섞인 요청은 대부분 @ModelAttribute 로 처리하고, JSON 파트가 따로 필요할 때만 @RequestPart 를 함께 검토합니다. 왜 둘이 자주 헷갈릴까 @RequestBody 와 @ModelAttribute 는 둘 다 컨트롤러에서 "요청 데이터를 DTO로 받는다"는 점만 보면 비슷해 보입니다. 그래서 처음에는 애너테이션 취향 차이처럼 느껴지기 쉽습니다. 하지만 실제로는 출발점이 완전히 다릅니다. @RequestBody 는 HTTP 요청의 body 전체를 읽어서 객체로 변환합...

스프링에서 @ControllerAdvice 를 언제 쓰고 어떻게 구성해야 할까 목차 왜 @ControllerAdvice 가 필요한가 @ControllerAdvice 와 @RestControllerAdvice 의 차이 스프링 MVC에서 전역 처리 로직은 어떻게 적용될까 적용 범위는 반드시 좁혀서 시작하는 것이 좋다 실전 예시: 공통 에러 응답과 전역 예외 처리기 @InitBinder 와 @ModelAttribute 는 언제 쓸까 에러 응답 설계에서 자주 놓치는 기준 기대대로 동작하지 않을 때 확인할 것 운영 가능한 구조로 정리하는 방법 빠른 답 여러 컨트롤러에서 반복되는 예외 처리 로직은 @ControllerAdvice로 모으는 것이 기본입니다. JSON 에러 응답이 목적이라면 보통 @RestControllerAdvice를 먼저 검토하면 됩니다. 적용 범위는 패키지나 애너테이션 기준으로 좁힐 수 있어 전역 남용을 막을 수 있습니다. 핸들러가 기대대로 동작하지 않으면 예외 타입, 우선순위, 응답 본문 생성 방식을 먼저 확인해야 합니다. 빠른 답 여러 컨트롤러에서 반복되는 예외 처리, 바인딩, 공통 모델 설정은 @ControllerAdvice 로 모으는 것이 기본입니다. REST API에서 JSON 에러 응답을 일관되게 내려야 한다면 보통 @RestControllerAdvice 를 먼저 선택합니다. 적용 범위는 basePackages , assignableTypes , annotations 로 좁혀야 전역 남용과 예상치 못한 충돌을 줄일 수 있습니다. 동작이 기대와 다르면 예외가 발생한 위치, 예외 타입 매칭, 여러 어드바이스의 우선순위와 응답 직렬화 방식을 먼저 확인해야 합니다. 컨트롤러 코드가 늘어나기 시작하면 비슷한 로직이 반복됩니다. 입력 검증 실패를 400으로 바꾸는 코드, 특정 비즈니스 예외를 404나 409로 바꾸는 코드, 날짜 문자열을 공통 형식으로 파싱하는 코드가 대표적입니다. 처음에는 각 컨트롤러에서 직접 처리해도 큰 문...

Spring MVC 요청 처리 흐름 한눈에 이해하기: DispatcherServlet부터 MessageConverter까지 목차 Spring MVC 실행 흐름을 왜 알아야 하는가 DispatcherServlet, HandlerMapping, HandlerAdapter의 역할 먼저 잡기 화면을 반환할 때의 요청 처리 흐름 JSON API를 반환할 때는 어디서 달라질까 ArgumentResolver와 ReturnValueHandler를 같이 이해해야 하는 이유 Spring Boot에서는 어떤 설정이 기본으로 잡히는가 요청 하나를 끝까지 따라가 보기 실무에서 가장 먼저 확인할 디버깅 포인트 정리 빠른 답 Spring MVC 요청의 출발점은 DispatcherServlet이고, 실제 컨트롤러 호출은 HandlerAdapter가 담당합니다. HTML 응답은 ViewResolver로, JSON 응답은 HttpMessageConverter로 처리 경로가 갈립니다. @RequestBody와 @ResponseBody는 ArgumentResolver와 ReturnValueHandler를 통해 MessageConverter와 연결됩니다. 문제가 생기면 URL 매핑, Accept·Content-Type 헤더, 컨버터 선택 로그를 먼저 확인하는 것이 가장 빠릅니다. 빠른 답 Spring MVC 요청은 DispatcherServlet 에서 시작하고, 어떤 컨트롤러를 실행할지는 HandlerMapping , 실제 호출은 HandlerAdapter 가 담당합니다. HTML 화면을 반환하면 ViewResolver 가 뷰를 찾고 렌더링하며, JSON이나 문자열 본문을 반환하면 HttpMessageConverter 가 응답 본문을 만듭니다. @RequestBody 는 요청 본문을 객체로 읽는 과정에서, @ResponseBody 와 ResponseEntity 는 응답 객체를 본문으로 쓰는 과정에서 HttpMessageConverter 와 연결됩니다. 문제가 생기면 URL ...

스프링 MVC에서 Filter와 Interceptor를 언제 어떻게 나눠 써야 할까 목차 왜 둘이 자꾸 헷갈릴까 요청이 들어왔을 때 실제로 어떤 순서로 실행될까 어떤 경우에 Filter를 써야 할까 어떤 경우에 Interceptor를 써야 할까 Spring Boot에서 함께 등록하는 방법 실전 코드로 보기: 로깅은 Filter, 핸들러 기반 인증은 Interceptor curl과 로그로 실행 순서를 검증하는 방법 자주 생기는 실수와 선택 기준 빠른 답 서블릿 단위 공통 처리라면 Filter, 컨트롤러 전후 제어라면 Interceptor가 먼저 후보입니다. 요청 본문/응답 자체를 직접 다뤄야 하면 Filter가 더 유연합니다. 핸들러 정보나 애노테이션 기반 분기가 필요하면 Interceptor가 더 적합합니다. 순서 문제와 중복 실행은 실제 장애로 이어지기 쉬우니 등록 위치와 실행 로그를 함께 확인해야 합니다. 빠른 답 서블릿 레벨에서 모든 요청과 응답을 공통 처리해야 하면 Filter , 컨트롤러 실행 전후를 제어해야 하면 Interceptor 가 먼저 후보입니다. 헤더, 인코딩, CORS, 요청 본문, 응답 감싸기처럼 HTTP 자체를 다뤄야 하면 Filter 가 더 맞습니다. 어떤 컨트롤러 메서드가 호출되는지, 특정 애노테이션이 붙었는지 보고 분기해야 하면 Interceptor 가 더 적합합니다. 스프링 시큐리티를 쓰는 프로젝트라면 인증과 인가의 중심은 보통 시큐리티 필터 체인에 두고, Filter 와 Interceptor 는 보조 역할로 좁히는 편이 안전합니다. 왜 둘이 자꾸 헷갈릴까 Filter 와 Interceptor 는 둘 다 "공통 로직을 한곳에 모아 넣는다"는 점에서 비슷합니다. 그래서 로깅, 인증, 권한 확인, 성능 측정 같은 요구가 나오면 둘 중 어디에 넣어도 될 것처럼 보입니다. 하지만 둘은 동작하는 계층이 다릅니다. Filter 는 서블릿 컨테이너 쪽에서 동작하고, Interceptor 는 스...