보통 비즈니스 로직과 분리되어 공통적으로 처리해야 하는 작업들을 맡는다.
필터가 등장한 이유 : 공통 관심사(Cross-Cutting Concerns)
우리가 서비스를 만들다 보면, 비즈니스 로직(핵심 기능)외에도 반복적으로 수행해야 하는 부가 기능들이 생긴다.
핵심 기능 : 게시글 작성, 수정, 삭제(비즈니스 로직)

부가 기능 : 로그인 여부 확인, 로그 남기기, 인코딩 처리 등(비지니스 로직과는 별개로 동작하는 기능)

로그인이 필요한 모든 컨트롤러 메서드마다 로그인 검증 로직을 넣어야 한다.
코드 예시
@RestController
@RequestMapping("/post")
public class PostController {
@PostMapping
public PostResponseDto create(PostCreateRequestDto request) {
// 로그인 여부 확인 로직
// 생성 로직
}
@PutMapping("/{postId}")
public void update(
@PathVariable Long postId,
PostUpdateRequestDto request
) {
// 로그인 여부 확인 로직
// 수정 로직
}
@DeleteMapping("/{postId}")
public void delete(@PathVariable Long postId) {
// 로그인 여부 확인 로직
// 삭제 로직
}
}
위의 코드에서 공통으로 관심이 있는 부분을 공통 관심사라고 한다.
로그인 여부 확인 로직 -> 공통 관심사 (인증 : 로그인)
이를 해결하기 위해서 Servlet Filter를 사용한다.
- Filter를 적용하면 Servlet이 호출되기 이전에 Filter를 항상 거치게 된다.
- 공통 관심사를 필터에만 적용하면 모든 요청 or 응답에 적용된다.
- Filter는 특정 URL Pattern에 적용할 수 있다.
- Spring을 사용하는 경우 Servlet은 Dispatcher Servlet이다.

filterChain.doFilter()호출 → 다음 필터나 DispotcherServlet호출 → 정상 응답
doFilter()를 호출하지 않음 → 컨트롤러까지 요청이 가지 않음 → 에러 응답(401 Unauthorized 등)필터 뭐가 없으면 jwt까지