📌Spring 숙련 과제 트러블슈팅

일정을 효과적으로 관리할 수 있는 일정 관리 앱 API를 개발했다. 과제 트러블슈팅과 고민했던 점, 배운 점 등을 기록하고자 한다.

INSERT 됐지만 테이블이 안보이는 문제

댓글 작성 시, 아래와 같이 INSERT문은 제대로 실행된 것 같은데 DB에서는 comment 테이블이 보이지 않는 문제가 있었다.

@Transactional을 추가하지 않은 것이 원인이다. 트랜잭션이 자동으로 커밋되지 않아서 데이터가 DB에 반영되지 않았던 것이다. Service 계층에서 DB 작업을 수행할 때는 반드시 @Transactional 을 사용해 트랜잭션을 관리해야한다.

다음과 같이 @Transactional 을 붙인다.

@Transactional
public CommentResponseDto save(Long scheduleId, String email, CommentRequestDto dto) {
    Schedule schedule = scheduleRepository.findByIdOrElseThrow(scheduleId);
    Member member = memberRepository.findByEmailOrElseThrow(email);

    Comment comment = new Comment(dto.getContents(), member, schedule);
    Comment savedComment = commentRepository.save(comment);

    return new CommentResponseDto(
        savedComment.getId(),
        savedComment.getContents(),
        member.getUsername(),
        savedComment.getCreatedAt(),
        savedComment.getModifiedAt()
    );
}

이렇게 해도 되지만, 어제 <연관 관계 매핑 세션>에서 튜터님께서 클래스 레벨에 우선@Transactional(readOnly = true)를 사용한다는 것이 기억나 다음과 같이 수정했다. 그리고 지난번 피드백을 다시 보니 다른 튜터님께서도 "트랜잭션 범위를 확실히 하기 위해 DB 업데이트와 관련된 모든 작업을 트랜잭션 내에서 처리하는 것이 좋다."라고 피드백을 남겨주셨다.

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
public class CommentService {

    private final CommentRepository commentRepository;
    private final ScheduleRepository scheduleRepository;
    private final MemberRepository memberRepository;

    @Transactional
    public CommentResponseDto save(Long scheduleId, String email, CommentRequestDto dto) {
        Schedule schedule = scheduleRepository.findByIdOrElseThrow(scheduleId);
        Member member = memberRepository.findByEmailOrElseThrow(email);

        Comment comment = new Comment(dto.getContents(), member, schedule);
        Comment savedComment = commentRepository.save(comment);

        return new CommentResponseDto(
            savedComment.getId(),
            savedComment.getContents(),
            member.getUsername(),
            savedComment.getCreatedAt(),
            savedComment.getModifiedAt()
        );
    }
}

이 문제를 해결하면서 잘 신경쓰지 않았던 부분의 개념을 확실히 익히게 되었다.

• 클래스 레벨의 @Transactional(readOnly = true) 적용
  • 기본적으로 모든 메서드는 읽기 전용 트랜잭션 사용
  • 변경 감지(Dirty Checking) 비활성화 → 불필요한 데이터 변경 감지 로직 생략 → 성능 최적화
  • 조회 시 @Transactional이 없어도 동작하지만, @Transactional(readOnly = true)를 사용하면 성능이 최적화 되며 Lazy Loading(지연 로딩) 사용 시 트랜잭션 유지가 필요할 수 있음
• 쓰기 작업에는 @Transactional을 개별적으로 추가해야 함.
  • 메서드 레벨에서 @Transactional을 명시하면, 클래스 레벨의 readOnly = true를 무시하고 데이터 변경이 가능한 트랜잭션으로 동작

세션 키 가져올 때 ClassCastException

댓글 생성 시, 현재 로그인한 member의 세션키를 가져오는 과정에서 ClassCastException 오류가 발생했다.

HttpSession session = request.getSession(false);
Long memberId = (Long) session.getAttribute("sessionKey"); // 오류 발생 
CommentResponseDto commentResponseDto = commnetService.save(id, memberId, dto);

세션키로 Email을 저장했는데, String을 Long으로 변환하려고 하니 오류가 난 것이다. 따라서 다음과 같이 수정하여 문제를 해결했다.

HttpSession session = request.getSession(false);
String email = (String) session.getAttribute("sessionKey");
CommentResponseDto commentResponseDto = commnetService.save(id, email, dto);

Service에서도 id로 찾던 member를 email로 찾아 반환했다.

// Member member = memberRepository.findByIdOrElseThrow(id); // 기존 코드
Member member = memberRepository.findByEmailOrElseThrow(email);

Validation 어노테이션 적용 실패

다음과 같이 Validation 어노테이션을 적용하고 테스트 하는 과정에서 문제가 있었다.

    @NotBlank(message = "비밀번호는 필수값입니다.")
    @Size(min = 8, max = 12, message = "비밀번호는 8자 이상, 12자 이하여야 합니다.")
    @Pattern(regexp = "^(?=.*[A-Za-z])(?=.*\\d)[A-Za-z\\d@$!%*?&]+$", message = "비밀번호는 영문, 숫자, 특수문자를 적어도 1개 이상 포함해야 합니다.")
    @Setter
    @Column(nullable = false)
    private String password;

문자 길이 조건은 충족하고, 패턴 조건은 충족하지 않고 테스트 했을 때 1개의 오류를 예상했지만 2개의 오류 모두 나왔다. 순서도 바꿔보고 몇 번이나 조건을 다시 확인했는데 계속 같은 결과가 나왔다.

튜터님께 여쭤보니 생성자에서 메세지를 찍어보라고 하셔서 찍어보니 내가 입력한 값이 아닌 암호화 된 값이 나왔다. 알고보니 해당 어노테이션은 DTO 클래스에 적용해야하는데 Member 엔터티 클래스에 적용해서 생긴 문제였다.

무작정 적용하려다 보니 이런 문제가 생긴 것 같다. DTO에 적용하니 정상적으로 작동하였다.

@Setter 대신 명확한 도메인 메서드 사용하기

강의를 참고해 비밀번호 수정 기능을 구현하면서 왜 Setter를 사용하지않고 다음과 같이 굳이 updatePassword() 메서드를 만들어 수정하는지 궁금했다.

public void updatePassword(String password) {
    this.password = password;
}

Member 엔티티에서 아래와 같이 @Setter를 password 필드 위에 추가하면 안되는 것일까?

@Setter
@Column(nullable = false)
private String password;

찾아보니 Setter의 사용을 지양하는 이유는 여러가지가 있었다.

• 값을 변경한 의도를 파악하기 힘들다.
  • 단순히 이름이 setter인 메서드들이 나열되어있다면 어떤 의도로 해당 데이터를 변경하는지 알 수 없다.
• 객체의 일관성을 유지하기 어렵다.
  • setter를 적용하면 어디서든 값을 변경할 수 있어 위험할 수 있다.
• 비즈니스 로직을 통제하기 어렵다.
• 유지보수가 어렵다.

setPassword()만으로는 이 메서드가 비밀번호를 처음 저장하는 용도인지, 변경하는 용도인지 알 수 없다. 또한, 비밀번호 변경 시 기존 비밀번호 검증 같은 추가 로직이 필요할 수도 있다. 따라서, updatePassword()처럼 역할이 명확한 메서드를 제공하는 것이 더 바람직하다.

피드백

✔️ 잘한점

• request와 response에서 사용하는 dto들이 잘 나눠져 있다.
• HTTP 상태코드를 적절하게 사용했다.
• @Transactional(readOnly = true)과 @Transactional이 적절하게 사용되고 있다.
• 코드가 세밀하게 잘 작성되어있고, 예외처리나 세션으로 처리하는 부분을 잘 구현했다.

✔️ 생각해볼 점

• 로그인 성공 시 HttpStatus.OK를 반환하고 있지만, 일반적으로 로그인 성공 시 로그인한 사용자 정보를 ResponseEntity에 담아서 반환하면 클라이언트가 로그인 후 정보를 바로 사용할 수 있어 더 유용할 수 있다.

✔️ 궁금한 점 & 어려웠던 점

• 예외 처리를 얼마나 세세하게 하는 것이 좋을까?
  • 예외 처리는 시스템의 안정성과 사용자 경험에 매우 중요한 부분이기 때문에 세밀하게 처리할 수록 좋다.
  • 적절한 HTTP 상태 코드도 같이 넣어주자.
• repository에서 default 메서드를 이용해 예외 처리하는 방식과 service에서 예외 처리하는 방식 중 일반적인 방식은 무엇이고, default 메서드를 사용해서 repository에서 예외처리를 하는 특별한 경우가 있는지 궁금하다.
  • findByScheduleIdOrElseThrow()와 같은 메소드를 repository에서 구현하는 방식과 service에서 예외 처리를 하는 방식은 둘 다 유효하며, 선택은 상황에 따라 달라질 수 있다.
  • 서비스 레이어는 비즈니스 흐름과 예외 처리를 일관성 있게 관리할 수 있는 위치이다. 따라서 서비스 레이어에서 예외 처리를 하는 방식이 더 일반적이다.
  • Spring Data JPA의 findById()와 같은 메소드를 활용할 때, Optional을 반환하거나 기본적인 throw 처리만 하고 싶은 경우에는 respository에서 처리하는 것이 유용할 수 있다. 또한, 특정 예외를 자주 던지는 경우에도 편리하게 사용할 수 있다.