겁나 빡셌다.
UsernamePasswordAuthenticationFilter를 상속한 UserAuthenticationFilter를 만들어 인증을 담당,
BasicAuthenticationFilter를 상속한 JwtTokenAuthorizationFilter를 만들어 인가를 담당토록 했다.
그리고 GlobalFilter에 corsFilter를 포함, 상기한 인증 인가에 관한 필터를 메소드화하여 들고왔다.

그리고 아래와 같이 GlobalFilter에 다 낑겨넣었다.

근데 외않된뎨?
당장 저 위의 스크린샷들은 이미 문제를 해결한 코드이다.
원래는, 모든 필터를 @Component, 모든 메소드를 @Bean으로 등록해 @Autowired로 가지고 오게끔 설계했었다.
그러질 말았어야 했는데~
한 3일 넘게 애먹었던 것 같다. permitAll()을 해줘도, annonymous()를 해줘도, 심지어 ignoring()을 해줘도 안되는데 도대체 왜 안된단 말인가?
의존성 주입, 제대로 알고 쓰자.
결론은 자동 주입의 남발이 문제였다. FilterChain의 구조적 특성 때문에 DI 남발이 뽀록난 것이다.

FilterChain의 구조는 이렇다.
SecurityFilter는 DelegatingFilterProxy 단계에서 적용되는데...

그냥 @Component로 등록한 Filter는 WAS의 ApplicationFilterChain에 등록되게 돼버린다.
그러면? 우리의 SecurityFilterChain과는? 아예 무관한 놈이 된다. 탈 일이 없으니 영향을 받지도 않게 된다.
그럼 어떻게?
이론은 간단하다.
@Component와 @Bean으로 등록하지 말고,
직접 new로 생성해 주입해주면 된다.

GlobalFilter에 내가 만든 Filter를 new로 생성해 넣어주었다.

그 다음 addFilterBefore로 적용시켜 주었다.
내가 직접 만든 Custom Filter이기 때문에, addFilterBefore를 써야한다.
corsFilter같은 경우에는 기존 제공하는 CorsFilter를 바로 상속해 작성했기 때문에 그냥 addFilter를 사용해도 제대로 동작했다.

WebSecurityCustomizer(Adapter 시절의 WebSecurity) 사용하여 ignoring 적용.
이것도 WebSecurityConfigurerAdapter가 Deprecated 된지 얼마 안돼서 자료 찾기 힘들었다.
아무튼 이제 정상 작동하니 괜찮아!