[내일배움캠프 Spring 3기] CH 3 심화 Spring 코드 개선 과제 - 도전 기능

Spring 심화 도전 기능 (Lv5 ~ Lv7)

이번 단계에서는 기존 필수 기능 위에 다음 작업을 진행했다.

1. JWT 인증 구조 리팩토링
2. 인증 책임 분리
3. ArgumentResolver 활용
4. 단위 테스트 작성
5. 테스트 커버리지 측정

단순히 기능을 추가하는 것이 아니라 코드 구조 개선과 테스트 가능한 구조를 만드는 것에 집중했다.

---

Lv5 JWT 인증 구조 개선

문제 상황

JWT 인증 로직을 구현할 때 처음에는 대부분의 로직이 JwtFilter에 집중되어 있었다.

기존 JwtFilter는 다음 역할을 모두 수행하고 있었다.

JwtFilter

• 토큰 검증
• Claims 추출
• 사용자 정보 request 저장
• 관리자 권한 검사

즉 하나의 클래스가 너무 많은 역할을 가지고 있었다.

이 구조는 다음 문제를 만들 수 있다.

1. 클래스의 책임이 너무 많아짐
2. 테스트가 어려워짐
3. 코드 유지보수가 어려워짐

이 문제는 객체지향 설계 원칙 중 하나인 SRP(Single Responsibility Principle) 를 위반하는 구조였다.

SRP는 하나의 클래스는 하나의 책임만 가져야 한다는 원칙이다.

---

해결 방법

JWT 인증 관련 로직을 JwtAuthHelper 클래스로 분리하였다.

구조는 다음과 같이 변경하였다.

기존 구조

JwtFilter
 -> validate token
 -> extract claims
 -> set request attribute
 -> check admin role

개선 구조

JwtFilter
 -> JwtAuthHelper

JwtAuthHelper

validateAndExtractClaims()
setUserAttributes()
validateAdminAccess()

이렇게 인증 관련 로직을 Helper 클래스로 이동시켰다.

---

JwtAuthHelper

토큰 검증과 Claims 추출을 담당하는 메서드이다.

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;
}

이 메서드는 다음 순서로 동작한다.

Authorization Header 확인

• Bearer 토큰 분리
• JWT Claims 추출

JWT에서 Claims는 토큰에 담긴 사용자 정보를 의미한다.

예를 들어

userId
email
userRole

같은 정보들이 Claims에 포함된다.

---

사용자 정보 request 저장

JWT에서 추출한 정보를 request attribute로 저장하였다.

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"));
}

이렇게 저장한 이유는 이후 단계에서 다음 구조로 사용하기 위해서이다.

JwtFilter
 -> request attribute 저장
 -> ArgumentResolver
 -> Controller

즉 Controller에서는 request를 직접 사용하지 않고 AuthUser 객체로 받을 수 있게 된다.

---

관리자 권한 검사

관리자 API 접근 시 권한을 검사하는 로직이다.

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("접근 권한이 없습니다.");
    }
}

여기서 중요한 포인트는 다음이다.

url.startsWith("/admin")

즉 관리자 API 경로는

/admin/comments
/admin/users

같이 시작하도록 설계되어 있기 때문에
이 경로를 기준으로 권한 검사를 수행하도록 구현했다.

---

구조 개선 결과

기존 구조

JwtFilter
 -> 인증
 -> 인가
 -> 사용자 정보 처리
 -> 토큰 처리

개선 구조

JwtFilter
 -> JwtAuthHelper

즉

Filter -> 요청 흐름 제어
Helper -> 인증 로직 처리

로 역할을 분리하였다.

---

Lv6 코드 구조 개선 및 리팩토링

문제 인식

기능 구현이 완료된 후 코드를 다시 확인하면서 다음 문제를 발견했다.

1. 인증 정보를 Controller에서 직접 꺼내는 코드 존재
2. request attribute 접근 코드 반복
3. 테스트 작성이 어려운 구조

예를 들어 기존 방식은 다음과 같았다.

Long userId = (Long) request.getAttribute("userId");

이 방식은 다음 문제를 가진다.

1. Controller가 HttpServletRequest에 의존
2. 인증 정보 처리 코드가 반복됨
3. 테스트 작성이 어려움

---

해결 방법

Spring에서 제공하는 HandlerMethodArgumentResolver 를 활용하였다.

ArgumentResolver는 Controller의 파라미터를 자동으로 생성해주는 기능이다.

즉 Controller에서는 request를 직접 다루지 않아도 된다.

---

AuthUserArgumentResolver

Long userId = (Long) request.getAttribute("userId");
String email = (String) request.getAttribute("email");
UserRole userRole = UserRole.of((String) request.getAttribute("userRole"));

return new AuthUser(userId, email, userRole);

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

request attribute에서 인증 정보를 가져온다
-> AuthUser 객체 생성
-> Controller 파라미터로 전달

---

Controller 코드 개선

기존 방식

Long userId = (Long) request.getAttribute("userId");

개선 방식

public ResponseEntity<CommentSaveResponse> saveComment(
        @Auth AuthUser authUser,
        ...
)

Controller에서는 AuthUser 객체만 사용하면 된다.

---

구조 개선 효과

Controller -> 인증 로직 제거
ArgumentResolver -> 인증 객체 생성
Filter -> request attribute 저장

즉 다음 구조가 만들어졌다.

JwtFilter
 -> JwtAuthHelper
 -> request attribute 저장

ArgumentResolver
 -> AuthUser 객체 생성

Controller
 -> AuthUser 사용

이 구조는 실제 Spring Security의 인증 흐름과도 유사하다.

Lv6 벨로그

Lv 6. 위 제시된 기능 이외 ‘내’가 정의한 문제와 해결 과정 - jiiimni 벨로그

---

Lv7 테스트 코드 작성 및 커버리지 측정

이번 단계에서는 서비스 로직과 인증 로직에 대한 단위 테스트를 작성하였다.

테스트 작성 목적은 다음과 같다.

1. 비즈니스 로직 검증
2. 리팩토링 안정성 확보
3. 코드 품질 향상

---

작성한 테스트

Service 테스트

CommentServiceTest
ManagerServiceTest
AuthServiceTest
UserServiceTest

Config 테스트

JwtAuthHelperTest
GlobalExceptionHandlerTest
WebConfigTest
FilterConfigTest

---

테스트 커버리지

IntelliJ Coverage 기준

전체 클래스 커버리지 77%
메서드 커버리지 73%
라인 커버리지 76%
Domain 패키지 82%
Config 패키지 81%

---

테스트 작성 예시

@Test
void 댓글_생성에_성공한다() {

    given(todoRepository.findById(anyLong()))
            .willReturn(Optional.of(todo));

    CommentSaveResponse response =
            commentService.saveComment(authUser, 1L, request);

    assertEquals("댓글", response.getContents());
}

이 테스트는 다음 흐름을 검증한다.

Todo 존재 여부 확인
-> Comment 생성
-> Response 반환

---

테스트 작성하면서 알게 된 점

테스트 코드를 작성하면서 다음을 많이 느꼈다.

1. 테스트 가능한 구조가 중요하다
2. 책임 분리가 되어 있어야 테스트가 쉽다
3. 테스트 코드가 리팩토링 안정성을 높여준다

특히 JwtFilter 구조를 리팩토링하면서 테스트 코드 작성이 훨씬 쉬워졌다.

---

트러블슈팅

JWT Claims 테스트 오류

테스트 코드 작성 중 다음 오류가 발생했다.

Cannot resolve symbol Claims

원인은 build.gradle 설정이었다.

기존 설정

compileOnly 'io.jsonwebtoken:jjwt-api'

compileOnly는 테스트 클래스패스에 포함되지 않는다.

그래서 테스트 코드에서 Claims를 사용할 수 없었다.

---

해결 방법

다음과 같이 수정하였다.

implementation 'io.jsonwebtoken:jjwt-api'

이후 테스트 코드에서 Claims를 정상적으로 사용할 수 있었다.

---

회고

이번 도전 기능에서는 단순한 기능 구현보다 코드 구조 개선과 테스트 코드 작성 경험을 많이 할 수 있었다.

JWT 인증 구조 리팩토링
-> 책임 분리
-> ArgumentResolver 활용
-> 테스트 코드 작성

이 과정을 통해 Spring 애플리케이션 구조를 더 깊이 이해할 수 있었다.

또한 Filter -> Helper -> Resolver -> Controller 구조는
Spring Security의 인증 흐름과도 유사하다는 점에서 의미 있는 경험이었다.

테스트 코드 작성 과정에서는 AI를 참고하여 테스트 구조와 작성 방법을 학습하였다.

단순히 코드를 그대로 사용하는 것이 아니라 테스트 동작 원리를 이해하고 프로젝트 구조에 맞게 수정하여 적용하였다.

이를 통해 단위 테스트 작성 방식과 테스트 커버리지 측정에 대한 이해도를 높일 수 있었다.