현재 필터에서 JWT 토큰의 유무, 만기 일자만 검증을 하고 토큰의 유효성 검증은 빠져있는 것 같아요!
별도로 토큰에 대한 유효성 검증이 jwtExtractor.getEmail 여기서 일어나고 있는 걸까요!?

필터에서는 조금 더 명시적으로 validate 등의 메서드로 유효성 검증이 표현이 되면 좋을 것 같아요!

맞습니다!
조금 더 정확히는 getEmail(), getRole(), isExpired() 등의 메서드가 호출하는 getClaimFromToken()의 parseClaims()에서 유효성 검증이 수행됩니다.

이 메서드는 jwtToken의 유효성 검증 및 디코딩을 수행 후 Claims를 반환합니다!

    private Claims parseClaims(String token) {
        try{
            JwtParser parser = Jwts.parserBuilder()
                    .setSigningKey(key)
                    .build();
            return parser.parseClaimsJws(token).getBody();
        }catch (JwtException e){
            throw new TokenInvalidException();
        }
    }

저는 토큰의 값을 꺼내는 전제 조건이 유효한 토큰이라고 생각했습니다.
Email, Role, Expiration과 같은 Claims를 반환할 때 유효성 검증이 수행되는 JwtParser의 parseClaimsJws를 사용했습니다.

그럼 해당 메서드에 유효성 검증이라는 의미가 들어나도 좋을 것 같아요!
현재 필터만 봤을 때 검증의 역할을 하는 메서드가 확인이 안돼서 jwtExtractor로 내려가서 확인을 할 때 해당 클래스에서도 검증을 하는 메서드는 보이지 않아서 메서드 명이 validateToken 등으로 수정이 되는 것도 좋을 것 같아요

어떻게 보면 추출의 역할은 이 메서드를 호출하는 쪽에서 진행하는 것이니 이 메서드의 책임은 검증이라고 봐도 괜찮을 것 같아서요!

그리고 갑자기 든 생각인데, 현재 jwtExtractor에 구현된 추출 메서드 들은 매번 parseClaims를 거쳐야하는데, 이것이 조금 비 효율적일 수도 있겠다는 생각이 들었어요

가장 초기에 토큰 검증 후에 추출 추출 추출 이렇게 사용할 수 있는게 아니라 토큰 검증+추출 이다보니 id, email 등이 같이 필요할 때는 매번 검증을 할 필요는 없지 않나 라는 생각이 들었습니다!

전 이렇게 관리하는 것도 좋을 것 같아요!

좋습니다!
다른 분들 의견도 궁금하네요!

CurrentMemberId 부분도 위 코멘트 내용과 동일합니다 !

리뷰 내용을 참고해 코드를 수정해봤는데 검토 부탁드립니다!!

import static com.gachtaxi.global.auth.jwt.annotation.CurrentMemberId.*;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.PARAMETER)
@AuthenticationPrincipal(expression = "#this == '" + ANONYMOUS_USER + "' ? null : id")
public @interface CurrentMemberId {
    String ANONYMOUS_USER = "anonymousUser";
}

제가 찾은 그나마 깔끔한 방법입니다.
id는 문자열이 아니라 id 자체를 반환해야하므로 String으로 상수화 시키면 null이 반환되더군요!

위 방법은 하드코딩을 지양하고 상수화를 거쳤다는 장점이 있습니다.
그런데 문자열과 + 연산을 사용해 문자열이 계속 생기게 되어 메모리 성능 상 좋지 않을 거 같습니다
그리고 일부는 상수화 일부는 id라는 값 자체를 사용해서 뭔가 어색하기도 하네요....
'anonymousUser'는 @CurrentMemberId 안에서만 사용되기 때문에 유지보수에도 그렇게 어렵지 않을 거 같다는 생각도 듭니다!

혹시 더 나은 개선 방법이 있다면 알려주실 수 있을까요??

anonymousUser를 상수화하는 방식 자체에 대해서는 긍정적으로 생각합니다.
상수화를 통해서 하드코딩된 문자열을 제거하는 방식만으로 진행을 해도 유지보수성이 향상될 수 있다고 생각했습니다.
근데 문자열을 + 연산자로 이어붙이는 방식이 저희는 어노테이션을 사용하는 메소드가 빈번하게 호출될 경우가 있을 수도 있어,
저도 이런 경우에 연산이 성능에 미치게 될 수도 있다고 판단했습니다. 큰 차이는 없다고 생각되긴하지만 최적화를 위해서는 + 연산자 보다는 String.format()이나 StringBuilder를 이용하는 방법이 더 적절하지 않을까 하는 생각은 있습니다 !

헤더에서 토큰을 추출할 때 request를 직접 넘겨주기 보다는 @CookieValue, @RequestHeader 등의 어노테이션을 사용해서 쿠키를 가져올 수 있을 것 같아요!

저도 쿠키는 가져와보진 못했지만, 헤더에서 값을 빼올 때는 @RequestHeader를 사용해서 빼오는 것이 해당 컨트롤러에서 필요로 하는 값이 한 눈에 보여서 조은 것 같습니다

그리고 갑자기 든 생각인데, 현재 jwtExtractor에 구현된 추출 메서드 들은 매번 parseClaims를 거쳐야하는데, 이것이 조금 비 효율적일 수도 있겠다는 생각이 들었어요

가장 초기에 토큰 검증 후에 추출 추출 추출 이렇게 사용할 수 있는게 아니라 토큰 검증+추출 이다보니 id, email 등이 같이 필요할 때는 매번 검증을 할 필요는 없지 않나 라는 생각이 들었습니다!

reissueJwtToken 은 토큰 재생성 + 재발급의 책임을 가져야한다고 생각합니다.

따라서 해당 메서드는 하위 private 메서드들을 호출하는 파사드의 역할을 수행하고, 하위 메서드로 토큰 추출, 검증, 발급, setHeader를 수행해서 컨트롤러에서 jwtService.setHeader, jwtService.setCookie를 호출 해주기 보다는 서비스 클래스에서 전부 수행한 후에 반환해주는 방식도 좋을 것 같아요!

그리고 현재 토큰 재발급시 이전에 저장된 리프레시 토큰을 삭제하진 않는 것으로 보이는데 특별한 이유가 있을까요??

RefreshToken을 재발급 받고 Redis에 저장 시 덮어쓰기 되어 삭제하지 않았습니다!