[Spring MVC] 하수한 미션 제출합니다. #509

chemistryx · 2025-11-06T06:54:22Z

승현님 안녕하세요! 이번 Spring MVC 미션 리뷰이로 참여하게 된 하수한이라고 합니다!
이번 PR에서는 1단계 - 홈 화면, 2단계 - 예약 조회, 3단계 - 예약 추가 / 취소, 4단계 - 예외 처리 네가지 단계를 진행하였습니다.

현재 프로젝트 구조는 다음과 같습니다:

controller/
- HomeController.java : 메인 화면 관련 endpoint를 처리하는 컨트롤러
- ReservationController.java : 예약 관련 endpoint를 처리하는 컨트롤러
dto/
- ErrorResponse.java : 오류 응답 정보를 담을 객체
- ReservationCreateRequest.java : 예약 생성 요청 Payload를 담을 객체
- ReservationCreateResponse.java : 예약 생성 요청 응답 정보를 담을 객체
exception/
- GlobalExceptionHandler.java : 공통 예외 핸들러
- ReservationNotFoundException.java : 예약을 찾을 수 없을 때 발생하는 Custom Exception
- ReservationValidationException.java : 예약 값 검증에 실패했을 때 발생하는 Custom Exception
model/
- Reservation.java : 예약 데이터를 저장하기 위한 Record
service/
- ReservationService.java : 예약 관련 비즈니스 로직을 담은 객체
RoomescapeApplication.java : Main entrypoint

초기에는 ReservationController에 모든 비즈니스 로직을 작성해두었으나, 기능이 점점 많아짐에 따라 비즈니스 로직을 ReservationService로 나누어 보았습니다. 생성 시 id의 경우 내부 로직에 의해 자동으로 부여되는데, 이때 AtomicInteger를 사용하여 동시에 여러 요청이 들어와도 id값이 중복되지 않도록 처리하였습니다.

다음은 구현 과정에서 발생한 질문 사항입니다!

현재 ReservationCreateRequest 관련 예외 처리를 ReservationService에서 수행하고 있습니다. 지금 단계에서는 인자가 그렇게 많지 않아 값 검증 로직에 있어 부담이 없어 보이긴 하나, 만약 Payload에 많은 양의 인자가 들어오고, 이를 모두 검증해야 할 필요가 있다면 어떠한 방식으로 검증 로직을 설계하는 것이 가장 좋은 접근인지 궁금합니다.
현재 생성 요청, 생성 응답에 대해 DTO가 모두 작성되어 있습니다. 물론 DTO를 통해 응답 값을 필터링 한다거나 계층 간 분리를 명확하게 할 수 있다는 점에서 DTO는 필요하다고 생각합니다. 다만, 규모가 커짐에 따라 DTO 역시 많아질 것으로 예상이 되는데, 이때 만약 엔티티(e.g., Reservation)의 수정이 필요하여 수정하게 되면, 기존에 작성되었던 DTO 역시 이에 맞춰 수정이 이루어질 필요가 있다고 생각합니다.
제 생각엔 이러한 과정이 굉장히 번거로울 것으로 보이는데, 이를 해결할 수 있는 방법이 있는지, 아니면 이를 감수하고서라도 DTO를 사용함에 있어서 얻는 장점이 더 명확하여 제가 가진 우려의 경우 무시해도 되는 수준인지 궁금합니다!

다음은 지난 1, 2단계 미션 관련 코멘트 / 질문 사항이었으나, 제 나름대로 이유를 찾아본 뒤 코멘트를 달아보았습니다. 승현님께서 한번 보시고 관련해서 더 해주실 말씀이 있다면 언제든지 달아주세요!

지난 1, 2단계 미션 관련 코멘트

기존 boilerplate 코드에서는 웹 관련 의존성이 추가되어있지 않아 build.gradle내 spring-boot-starter-web 의존성을 추가했습니다.
추가로 클라이언트 요청 시 HTML 파일을 응답하기 위해 thymeleaf 템플릿 엔진을 도입하였습니다.

예약 데이터의 경우 Reservation 모델을 통해 관리할 수 있도록 구현하였습니다!

다음은 구현 과정에서 발생한 질문 사항입니다.

초기에 예약 데이터를 저장하기 위한 객체를 생성할 때 아래와 같이 VO를 만들었는데, 이를 Controller에 적용한 후 테스트를 해보니 다음과 같은 오류가 발생했습니다. 일단 Record로 변경하여 해결하긴 했는데, 어떠한 조건에서 다음과 같은 오류가 발생하는 것인지 궁금합니다!
➡️ 관련해서 찾아보니 Spring의 경우 내부적으로 Jackson이라는 라이브러리를 활용하여 JSON 직렬화를 수행하는데, 이 과정에서 접근할 수 있는 필드(getter)가 없어 직렬화를 할 수 없어 발생한 오류로 이해했습니다.

기존 Reservation VO:

public class Reservation {
    private final int id;
    private final String name;
    private final String date;
    private final String time;

    public Reservation(int id, String name, String date, String time) {
        this.id = id;
        this.name = name;
        this.date = date;
        this.time = time;
    }
}

발생 오류:

com.fasterxml.jackson.databind.exc.InvalidDefinitionException: No serializer found for class roomescape.model.Reservation and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationFeature.FAIL_ON_EMPTY_BEANS) (through reference chain: java.util.ImmutableCollections$ListN[0])

긴 글 읽어주셔서 감사드리며, 이번 리뷰도 잘 부탁드립니다!

BackFoxx

안녕하세요! 1-4단계 미션을 함께 구현하여 제출해주시느라 고생 많으셨습니다.
코드 리뷰와 함께 질문에 대한 제 의견을 남길게요.

1. ReservationCreateRequest 검증을 ReservationService에서 하는 것

ReservationCreateRequest를 대상으로 실행하는 검증 과정(이름이 있는가, 시간이 있는가)은 결국 Reservation이라는 도메인 객체를 만들기 위한 검증 과정입니다.
'도메인 객체와 관련된 작업은 도메인 객체 안으로 응집한다'라는 객체지향 개념을 중심에 두고자 한다면, 작성해주신 검증 로직은 Request도 Service도 아닌 Reservation 안에 있어야 자연스럽겠죠.
그런데 현재 단계에서의 검증 작업은 값 존재 유무만 검증하는 굉장히 단순한 작업입니다. 이 정도로 당연한 검증을 굳이 도메인 안에서 해야 하냐, 도메인에는 더 복잡하고 중요한 검증 작업만 넣고, 이렇게 단순한 일은 밖에서 미리 거르는 게 좋겠다 생각하실 수도 있습니다. 그 때는 spring boot에서 제공하는 bean validation 기능이 큰 도움이 됩니다. 이 키워드로 학습해 보시고 한번 적용해서 어떤 게 더 편해지나 실험해보시는 것을 추천드립니다.

2. 엔티티가 수정되면 DTO도 수정해야 하니 DTO가 많아지면 유지보수가 힘들지 않은가

엔티티가 수정됐을 때 같이 패치해야 하는 범위가 DTO에서 끝난다면 그건 아주 잘 설계된 것입니다.
보통 클래스가 늘어나는 게 번거로워서 DTO를 안 두거나 엔티티의 속성을 그대로 따라가는 유명무실 DTO를 만들어 사용하는 경우가 많은데,
이 때 엔티티에 변경이 발생하면 변경이 일어난 영역 너머의 수많은 레이어에 변경이 전파됩니다.
DTO 몇개 고치는 것보다 더 무서운 일이 일어나지요.
그런 점에서 DTO는 수도꼭지같은 존재입니다. 물이 집에 넘쳐흐르지 않고 수도꼭지 선에서 물이 멈추게 해주지만, 꼭지를 직접 돌리는 수고 정도는 감수해야 합니다.

BackFoxx · 2025-11-12T13:00:30Z