스프링 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 는 스...