📌 Spring 심화 과제 트러블 슈팅

Spring 심화 주차 개인 과제를 진행했다. 코드 리팩토링, N+1 문제 해결, API 로깅, 테스트 코드 작성 등의 과제를 수행했다. 그 과정에서의 트러블슈팅과 고민했던 점, 배운 점 등을 기록하고자 한다.

Main 실행 시 에러 발생

처음 프로젝트를 받아 실행하니 다음과 같은 에러가 나왔다.

에러 메세지가 길긴 하지만 잘 읽어보면 JWT 시크릿 키에 대한 문제인 것을 짐작할 수 있다. application.properties 파일에 키를 넣으려고 했는데, 아예 resourse 폴더가 없었다. 따라서 먼저 키를 만들어야 했다.

java.lang.IllegalArgumentException: Could not resolve placeholder 'jwt.secret.key' in value "${jwt.secret.key}"

org.springframework.beans.factory.BeanCreationException: 
Error creating bean with name 'jwtUtil': Injection of autowired dependencies failed

Unsatisfied dependency expressed through constructor parameter 0: 
Error creating bean with name 'jwtUtil': Injection of autowired dependencies failed

터미널에 아래와 같이 입력해 키를 만들었다. 키를 처음 만들어 보지만 검색하니 만드는 방법이 바로 나왔다. 터미널로 만드는 방법 외에도 키를 만드는 사이트를 활용하는 방법도 있었다.

openssl rand -hex 64

결과는 다음과 같이 아주 긴 시크릿 키가 나왔다.

22b8c9ae9a1b397ef0c8a2d142f91d1d00b7c0dc0dae01d2999d197f111f3e01117c15a4477f63732fa2aa6fe8fbf313874b681fa31cef4049aa50707b7f8156

그리고 resourse 폴더를 생성 후, application.properties 파일을 만들고 다음과 같이 키를 넣었다.

jwt.secret.key="JWT_시크릿_키"

여기서 중요한 점은 JwtUtil 클래스에서${jwt.secret.key} 로 적었다면, jwt.secret.key 로 똑같이 적어야 한다는 점이다.

그런데 또 에러가 났다. 왜일까? 잘 살펴보니 새로운 에러가 등장했다.

java.lang.IllegalArgumentException: Illegal base64 character 22

해당 에러에 대한 내용을 검색하다가 JWT를 사용한 다른 사람의 스크린샷을 보고 나의 실수를 알아차렸다. 바로 쌍따옴표로 키를 감싼 것이다.

이렇게 작성하지 말고,

jwt.secret.key="JWT_시크릿_키"

이렇게 쌍따옴표 없이 작성해야 한다. 제대로 고친 후 실행하니 정상적으로 작동했다.

jwt.secret.key=JWT_시크릿_키

+) 추가 공부 👀

처음에는 시크릿 키 값을 바꾼 것 때문에 정상 작동하는 줄 알았지만 아니었다. 키 값이 문제는 아니었지만, 내가 위에서 만든 키 값은 현재 프로젝트에서 사용하고 있는 알고리즘에 적합하지 않다는 것을 알게 되었다.

현재 프로젝트에서 적용한 알고리즘은 HS256 알고리즘이다.

private final SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;

사용하는 알고리즘에 따라 키를 다르게 생성해야 한다. 내가 위에서 키를 생성하기 위해 사용한 openssl rand -hex 64 는 HS512(512비트) 알고리즘을 사용할 때 적합하다.

따라서 다음과 같이 조금 다른 명령어를 gitbash에 치니 더 짧은 키가 나왔다.

openssl rand -base64 32

결과를 보니 확실히 위에서 얻은 키와 다르다.

7yD9Da2chXAX5qCI2WrIzdiIifDZI8WPtcqJ+rjUJRA=

💡-hex 64 vs -base64 32 차이

1) -hex 64 (HEX)

• HS512(512비트) 알고리즘을 사용할 때 적합
• 다만, HEX 문자열은 Base64와 다르게 바로 Secret Key로 사용하려면 바이트 변환이 필요함
• 예제 변환 코드

    byte[] keyBytes = new BigInteger(secretKey, 16).toByteArray();

2) -base64 32 (Base64)

• HS256(256비트) 알고리즘을 사용할 때 적합
• Base64.getDecoder().decode(secretKey)를 통해 바로 바이트 배열로 변환 가능
  
• Keys.hmacShaKeyFor(Base64.getDecoder().decode(secretKey))와 같은 방식으로 사용 가능

그런데, openssl rand -hex 64 를 이용해 생성한 키도 정상적으로 돌아가서 의문이 들었다. HS256 알고리즘에 적합한 키는 openssl rand -base64 32 로 생성한 키라고 했는데, 왜 정상적으로 작동하는 걸까? 이 부분은 GPT에게 물어봤다.🤔

그 이유는 Spring Security 및 JJWT 라이브러리에서 내부적으로 HEX 문자열을 바이트 배열로 변환하여 처리하기 때문이라고 한다.

• JJWT (Java JWT, JSON Web Token for Java) : Java 기반의 JWT(Json Web Token) 생성 및 검증을 위한 라이브러리로, JWT를 쉽게 다룰 수 있도록 도와준다.

JJWT에서 Keys.hmacShaKeyFor() 메서드는 다음과 같이 동작한다. byte[] keyBytes를 입력 받아 SecretKey 객체로 변환하는데, 여기서 입력값이 256비트보다 길면 자동으로 적절한 길이로 잘라서 사용한다.

public static SecretKey hmacShaKeyFor(byte[] keyBytes) {
    return new SecretKeySpec(keyBytes, SignatureAlgorithm.HS256.getJcaName());
}

따라서, 키가 길어도 문제가 발생하지 않는다. 하지만 불필요하게 긴 값을 사용하기보단 Base64 키를 사용해 변환 과정을 없애는 것이 더 효율적일 것이다.

@Pattern을 나눠야 할까?

코드 개선 문제 중 아래 코드 부분을 해당 API의 요청 DTO에서 처리할 수 있게 개선하는 문제가 있었다.

if (userChangePasswordRequest.getNewPassword().length() < 8 ||
        !userChangePasswordRequest.getNewPassword().matches(".*\\d.*") ||
        !userChangePasswordRequest.getNewPassword().matches(".*[A-Z].*")) {
    throw new InvalidRequestException("새 비밀번호는 8자 이상이어야 하고, 숫자와 대문자를 포함해야 합니다.");
}

그동안 과제에서 했던 내용이어서 바로 @size 와 @Pattern을 사용해 다음과 같이 작성했다. 그런데 @Pattern을 하나로 합치는게 나을 것 같았다. 합치지 않으면 새 비밀번호는 숫자와 대문자를 포함해야 합니다. 라는 메세지도 어디에 넣어야 할지 애매했다.

@NotBlank
@Size(min =  8, message = "새 비밀번호는 8자 이상이어야 합니다.")
@Pattern(regexp = ".*\\d.*")
@Pattern(regexp = ".*[A-Z].*")
private String newPassword;

그래서 정규표현식을 검색해 수정 후 다음과 같이 한 번에 넣고 메세지도 같이 넣었다.

@NotBlank
@Size(min =  8, message = "새 비밀번호는 8자 이상이어야 합니다.")
@Pattern(regexp = "^(?=.*\\d)(?=.*[A-Z]).*$", message = "새 비밀번호는 숫자와 대문자를 포함해야 합니다.")
private String newPassword;

이 문제에서 내가 고민한 점은 @Pattern을 하나의 정규 표현식으로 적기 vs 따로 나눠서 적기 였다.

• 하나의 정규 표현식으로 적는다면?
  • 나눠서 적는 것보다 깔끔해보인다.
  • 지금까지 따로 나눈 적이 없어서 하나로 하는 게 맞는 것 같다.
• 따로 나눠서 적는다면?
  • 나중에 유지보수하기 쉬울 것 같다.
  • 오류 메세지를 따로 보여준다면 다른 개발자입장에서 더 편리할 것 같다.

와 같은 생각을 하다가 튜터님께 찾아가 여쭤봤다. 우선 결론부터 말하자면, 개발자마다 다르지만 지금 상황(비밀번호에 숫자와 대문자가 포함되어야 하는 상황)은 특이한 조건이 아니기 때문에 하나로 합쳐도 좋을 것 같다고 말씀해주셨다.

각자의 스타일에 따라 다르지만, 다음과 같은 상황을 제시해주셔서 이해가 잘 됐다.

• 보안을 강조하는 상황에서 조건이 계속 추가된다면?
  • 튜터님은 요구 조건의 변경이 잦은 프로젝트 참여 경험이 많으셔서 패턴을 따로 나누는 편이라고 하셨다. 그러면 요구 조건에 맞게 주석으로 처리할 수 있다.
• 패턴을 늘리거나 줄여야 할 경우라면?
  • 정규식 패턴을 모두 묶어서 처리하면 가독성이 떨어질 수 있다.
  • 정규 표현식이 익숙하지 않은 개발자가 있을 수 있다.

💭 하나의 방법을 정답으로 고수하기 보다는, 상황에 맞춰서 유연하게 코드 스타일을 적용하는 것도 개발자의 역량이라는 생각이 들었다.

테스트 코드 작성 시 UnnecessaryStubbingException 발생

테스트 코드를 작성하는데 다음과 같은 에러가 발생했다.

찾아보니 mockito-core 버전이 1.x일 때 없었던 Strictness(테스트코드의 엄격성)을 규정하기 위해 생긴 에러라고 한다. 블로그들을 쭉 보니 해결 방법은 3가지 정도가 있었다.

• 필요없는 Stubbing 제거하기
• Lenient() 메서드를 앞에 추가하기
• Mockito-core버전을 1.x나 2.x로 내리기

뭔가를 추가하거나 버전을 내리는 것은 조금 두려워서(...) 필요없는 Stubbing을 제거하는 방법을 선택했다. 하지만 중요한 점은 Stubbing이 정확히 무엇인지 모른다는 점이다.🤨

• Stubbing : Mock 객체가 특정 메서드를 호출했을 때 미리 정해진 값을 반환하도록 설정하는 것으로, 테스트에서 DB나 외부 의존성을 제거하고, 테스트 환경을 제어하기 위해 사용한다.
• 다음과 같이 findById(todoId)를 호출하면 항상 Optional.of(todo)가 반환된다. 여기서 todoRepository는 실제 DB를 조회하는 것이 아니라 미리 지정한 값을 반환하는 가짜(Mock) 객체로 동작한다. 실제 DB에 접근하지 않고 테스트하면 더 빠르고 독립적인 테스트가 가능하기 때문에 Stubbing을 사용한다.

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

이제 다시 에러 코드를 살펴보면, UnnecessaryStubbingException, 즉 필요하지 않은 Stubbing이 존재한다는 뜻인 것 같다. 필요하지 않은 Stubbing이라는 것은 실제 댓글 목록을 조회하는 CommentService 클래스의 getComments() 메서드에서 사용되지 않는 부분을 말하는 것이다.

에러가 난 테스트 코드와 getComments() 메서드를 보면 서비스 코드에서는 호출하지 않지만, 테스트 코드 내에서는 호출하고 있는 부분이 있다.

@Test
void comment_목록_조회에_성공한다() {
    // given
    long userId = 1L;
    long todoId = 1L;

    User user = new User("user1@example.com", "password", UserRole.USER);
    ReflectionTestUtils.setField(user, "id", userId);

    Todo todo = new Todo("Title", "Contents", "Sunny", user);
    ReflectionTestUtils.setField(todo, "id", todoId);

    Comment comment = new Comment("comment", user, todo);
    List<Comment> commentList = List.of(comment);

    given(todoRepository.findById(todoId)).willReturn(Optional.of(todo));
    given(commentRepository.findByTodoIdWithUser(todoId)).willReturn(commentList);

    // when
    List<CommentResponse> commentResponses = commentService.getComments(todoId);

    // then
    assertEquals(1, commentResponses.size());
    assertEquals(comment.getId(), commentResponses.get(0).getId());
    assertEquals(comment.getUser().getEmail(), commentResponses.get(0).getUser().getEmail());
}

@Transactional(readOnly = true)
public List<CommentResponse> getComments(long todoId) {
    List<Comment> commentList = commentRepository.findByTodoIdWithUser(todoId);

    return commentList.stream()
            .map(comment -> new CommentResponse(
                    comment.getId(),
                    comment.getContents(),
                    new UserResponse(comment.getUser().getId(), comment.getUser().getEmail())
            ))
            .collect(Collectors.toList());
}

바로 ttodoRepository.findById(todoId)를 호출하고 있는 부분이다. 실제 서비스 로직에서는 호출하고 있지 않다. 따라서 다음 given()을 제거했다.

given(todoRepository.findById(todoId)).willReturn(Optional.of(todo)); // 제거

그리고나서 다시 실행하니 테스트 코드가 잘 작동하는 것을 볼 수 있었다. 필요할 것 같다고 무작정 끌어쓰다가 이런 에러를 마주하니 서비스 로직을 잘 살펴보고 테스트 코드를 짜야한다는 것을 깨달았다.

N+1 문제 해결하기

다음 getTodos() 메서드에서 발생하고 있는 N+1 문제를 @EntityGraph를 사용해 해결해야 한다.

public Page<TodoResponse> getTodos(int page, int size) {
    Pageable pageable = PageRequest.of(page - 1, size);

    Page<Todo> todos = todoRepository.findAllByOrderByModifiedAtDesc(pageable);

    return todos.map(todo -> new TodoResponse(
            todo.getId(),
            todo.getTitle(),
            todo.getContents(),
            todo.getWeather(),
            new UserResponse(todo.getUser().getId(), todo.getUser().getEmail()),
            todo.getCreatedAt(),
            todo.getModifiedAt()
    ));
}

위 코드에서 할일을 모두 불러온 후, 그 아래 유저를 또 다시 불러오는 과정에서 N+1 문제가 발생할 가능성이 높아보인다.

Todo 엔티티의 일부를 살펴보면 User와 @ManyToOne 다대일 연관관계를 맺고 있고, 지연 로딩(FetchType.LAZY)으로 설정되어 있다. 지연 로딩으로 설정하면 Todo를 조회할 때 User를 바로 가져오는 것이 아니라 프록시 객체로 있다가 실제 사용될 때 SELECT 쿼리가 실행되는 것이다.

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "user_id", nullable = false)
private User user;

먼저 findAllByOrderByModifiedAtDesc() 메서드를 통해 다음과 같이 모든 todo를 불러오고 있다.

Page<Todo> todos = todoRepository.findAllByOrderByModifiedAtDesc(pageable);

이때 다음과 같은 쿼리가 실행될 것이다.

SELECT * FROM todo ORDER BY modified_at DESC LIMIT ?, ?

그리고 다음 코드에서 todo.getUser()를 하면 User에 대한 SELECT 추가 쿼리가 실행된다. 즉 todo가 100개라면 위에서 1개의 쿼리를 실행하고, 아래에서 100개의 쿼리가 또 발생하게 되는 것이다.

todos.map(todo -> new TodoResponse(
        todo.getId(),
        todo.getTitle(),
        todo.getContents(),
        todo.getWeather(),
        new UserResponse(todo.getUser().getId(), todo.getUser().getEmail()), // N+1 문제 발생 가능
        todo.getCreatedAt(),
        todo.getModifiedAt()
));

Repository에서는 이미 다음과 같이 fetch join을 사용해 N+1 문제를 해결했다.

@Query("SELECT t FROM Todo t LEFT JOIN FETCH t.user u ORDER BY t.modifiedAt DESC")
Page<Todo> findAllByOrderByModifiedAtDesc(Pageable pageable);

여기서 @EntityGraph라는 어노테이션을 활용해 해결해보자. @EntityGraph(attributePaths = {"user"})와 같이 적어주면 User도 함께 조회하도록 설정할 수 있다.

@EntityGraph(attributePaths = {"user"})
Page<Todo> findAllByOrderByModifiedAtDesc(Pageable pageable);

팀원분께서 N+1 문제를 해결하지 않았을 때의 결과와 해결했을 때의 결과를 직접 보여주셨다. 그래서 나도 따라서 테스트 해보니 훨씬 이해가 잘됐다. 미리 유저 2명을 생성하고, 일정도 각 유저마다 1개씩 만들어 테스트 했더니 다음과 같은 결과가 나왔다.

@EntityGraph 적용 전	@EntityGraph 적용 후

N+1 문제를 해결하기 전에는 일정을 조회하고, 각 유저마다 한 번씩 더 조회하고 있다. 유저의 수(2명)만큼 쿼리가 실행된 것이다. N+1 문제를 해결한 후에는 유저를 추가로 조회하는 것 없이 쿼리가 한 번만 실행되는 것을 볼 수 있다.