[내일배움캠프 Spring 3기] CH3 코드 개선 과제 - Lv 6

Lv6. Config 구조 개선 및 ArgumentResolver Bean 등록 문제 해결

1. 문제 인식 및 정의

Lv5에서 관리자 API 로깅 기능(Interceptor + AOP)을 구현하면서 WebConfig를 수정하였다.
이 과정에서 AuthUserArgumentResolver를 생성자 주입 방식으로 관리하도록 구조를 정리하였다.

기존 코드에서는 HandlerMethodArgumentResolver를 등록할 때 아래처럼 직접 객체를 생성할 수도 있었다.

resolvers.add(new AuthUserArgumentResolver());

하지만 Config 구조를 정리하면서 다음과 같이 의존성 주입(DI) 방식으로 변경하였다.

private final AuthUserArgumentResolver authUserArgumentResolver;

그런데 실행 과정에서 다음과 같은 오류가 발생했다.

Could not autowire. No beans of 'AuthUserArgumentResolver' type found

즉, WebConfig에서 AuthUserArgumentResolver를 주입받으려고 했지만
스프링 컨테이너에 해당 클래스가 Bean으로 등록되어 있지 않아 객체를 찾지 못하는 문제였다.

이 문제의 원인은 다음과 같다.

• AuthUserArgumentResolver가 스프링 Bean으로 등록되어 있지 않음
• WebMvcConfigurer에서 Resolver를 등록하려면 Bean 등록 + Config 등록 두 단계가 필요

결국 Config 클래스와 Bean 등록 구조를 명확하게 정리할 필요가 있었다.

---

2. 해결 방안

2-1. 의사결정 과정

AuthUserArgumentResolver를 스프링 Bean으로 등록하는 방법은 크게 두 가지가 있었다.

방법 1. @Component를 사용한 Bean 등록

@Component
public class AuthUserArgumentResolver implements HandlerMethodArgumentResolver

방법 2. @Configuration에서 @Bean으로 직접 등록

@Bean
public AuthUserArgumentResolver authUserArgumentResolver() {
    return new AuthUserArgumentResolver();
}

이번 프로젝트에서는 방법 1 (@Component)를 선택하였다.

선택 이유는 다음과 같다.

• ArgumentResolver는 여러 컨트롤러에서 재사용되는 컴포넌트
• 스프링이 직접 관리하는 Bean으로 등록하는 것이 구조적으로 더 자연스러움
• Config 클래스의 책임을 최소화할 수 있음

---

2-2. 해결 과정

1) AuthUserArgumentResolver를 Bean으로 등록

@Component
public class AuthUserArgumentResolver implements HandlerMethodArgumentResolver {

이렇게 하면 스프링 컨테이너가 자동으로 Bean으로 등록한다.

---

2) WebConfig에서 ArgumentResolver 등록

@Configuration
@RequiredArgsConstructor
public class WebConfig implements WebMvcConfigurer {

    private final AuthUserArgumentResolver authUserArgumentResolver;
    private final AdminApiInterceptor adminApiInterceptor;

    @Override
    public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
        resolvers.add(authUserArgumentResolver);
    }

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(adminApiInterceptor)
                .addPathPatterns("/admin/comments/*")
                .addPathPatterns("/admin/users/*");
    }
}

이 과정을 통해

• AuthUserArgumentResolver는 스프링 Bean
• WebConfig는 Resolver를 Spring MVC에 등록하는 역할

로 책임이 명확하게 분리되었다.

---

3. 해결 완료

3-1. 회고

이번 문제를 통해 Spring MVC의 ArgumentResolver 동작 구조를 명확히 이해할 수 있었다.

특히 다음 두 가지 포인트가 중요했다.

1) ArgumentResolver는 자동 등록되지 않는다

단순히 클래스를 만드는 것만으로는 동작하지 않는다.

다음 두 단계가 필요하다.

1. Bean 등록
2. WebMvcConfigurer.addArgumentResolvers 등록

---

2) Config 구조가 명확해야 오류를 줄일 수 있다

Config 클래스가 여러 개로 나뉘거나 Bean 등록이 누락되면

Could not autowire
No beans found

같은 오류가 쉽게 발생한다.

이번 경험을 통해

• 스프링 Bean 등록 방식
• WebMvcConfigurer의 역할
• ArgumentResolver 동작 방식

을 실제 오류 해결 과정을 통해 이해할 수 있었다.

---

3-2. 전후 데이터 비교

항목개선 전개선 후

Resolver 생성	new로 직접 생성 가능	스프링 Bean으로 관리
Config 구조	Bean 등록 누락 가능	DI 기반 구조
오류 발생	No beans found	해결
유지보수	설정 위치 불명확	역할 분리

---

Lv6. JwtFilter에서 인증과 인가 책임 분리

1. 문제 인식 및 정의

현재 JwtFilter는 인증, 인가, 사용자 정보 세팅, 에러 응답 생성까지 모두 담당하고 있었다.

하나의 클래스에 너무 많은 책임이 몰려 있어 유지보수성과 가독성이 떨어진다고 판단했다.

1. JWT 토큰 존재 여부 확인  
2. JWT 유효성 검증  
3. Claims 추출 및 사용자 정보 저장  
4. 관리자 권한 검증  
5. 에러 응답 생성

즉 하나의 클래스가 인증 과 인가 그리고 예외 처리까지 담당하고 있었다.

• 클래스의 책임이 과도하게 커짐
• 유지보수 어려움
• 테스트 어려움
• 코드 가독성 저하

---

2. 해결 방안

2-1. 의사결정 과정

처음에는 Filter를 인증용/인가용 두 개로 분리하는 구조도 고민했다.
하지만 현재 프로젝트 규모와 과제 범위를 고려했을 때, 먼저 JwtFilter를 얇게 만들고 JWT 처리 로직을 별도 helper로 위임하는 방식이 가장 적절하다고 판단했다.

---

각 클래스의 역할은 다음과 같다.

클래스역할

JwtFilter	요청 필터링
JwtValidator	JWT 검증
JwtAuthorizationChecker	권한 검사

---

2-2. 해결 과정

JwtAuthHelper 클래스를 생성했다.

claims 추출, request attribute 저장, admin 권한 체크를 JwtAuthHelper로 이동했다.

JwtFilter는 요청 흐름 제어와 예외 응답만 담당하도록 수정했다.

@RequiredArgsConstructor
public class JwtAuthHelper {

    private final JwtUtil jwtUtil;

    public Claims validateAndExtractClaims(HttpServletRequest request) {
        String bearerJwt = request.getHeader("Authorization");

        if (bearerJwt == null) {
            throw new IllegalArgumentException("인증 헤더가 없습니다.");
        }

        String jwt = jwtUtil.substringToken(bearerJwt);
        Claims claims = jwtUtil.extractClaims(jwt);

        if (claims == null) {
            throw new IllegalArgumentException("유효하지 않은 토큰입니다.");
        }

        return claims;
    }

    public void setUserAttributes(HttpServletRequest request, Claims claims) {
        request.setAttribute("userId", Long.parseLong(claims.getSubject()));
        request.setAttribute("email", claims.get("email"));
        request.setAttribute("userRole", claims.get("userRole"));
    }

    public void validateAdminAccess(String url, Claims claims) {
        UserRole userRole = UserRole.valueOf(claims.get("userRole", String.class));

        if (url.startsWith("/admin") && !UserRole.ADMIN.equals(userRole)) {
            throw new IllegalArgumentException("접근 권한이 없습니다.");
        }
    }
}

---

3. 해결 완료

3-1. 회고

이번 리팩토링을 통해 인증과 인가를 코드 구조 상에서 분리해서 생각하는 연습을 할 수 있었다.

완전히 별도 Filter로 분리하지는 않았지만, 최소한 하나의 클래스가 모든 책임을 가지는 구조는 개선할 수 있었다.

특히 다음 개념을 명확히 이해하게 되었다.

개념설명

인증(Authentication)	사용자가 누구인지 확인
인가(Authorization)	해당 사용자가 접근 권한이 있는지 확인

---

3-2. 전후 데이터 비교

항목개선 전개선 후

JwtFilter 책임	인증 + 인가 + 사용자 정보 세팅 + 에러 응답	요청 흐름 제어 + 예외 응답
JWT 처리 로직	JwtFilter 내부	JwtAuthHelper로 분리
가독성	낮음	개선
유지보수성	변경 지점이 많음	역할 분리로 개선