[Spring] Request DTO는 스프링이 만들어주는데, Response DTO는 왜 내가 만들어야 할까?

 

오늘 스프링을 공부하면서 가장 궁금했던 점은

CreateMovieRequest는 내가 new를 하지 않았는데도 객체가 생성되어 있었고,

반대로 CreateMovieResponse는 내가 직접 new를 해서 만들어야 했다.

왜 이런 차이가 있을까?

@PostMapping("/movies")
public ResponseEntity<CreateMovieResponse> createMovie(
        @RequestBody CreateMovieRequest request) {

    return ResponseEntity.status(HttpStatus.CREATED)
            .body(movieService.save(request));
}

 

---

Request DTO는 스프링이 만들어준다.

사용자가 서버에 요청을 보내면 보통 JSON 형태로 전달된다.

 

 

예를 들어

{
  "title": "겨울왕국"
}

이런 요청이 들어오면,

 

@RequestBody CreateMovieRequest request

를 보고 스프링이 내부적으로 다음과 같은 일을 자동으로 수행한다.

 

CreateMovieRequest request = new CreateMovieRequest();
request.setTitle("겨울왕국");

 

즉, JSON 데이터를 Request DTO 객체로 변환하는 작업을 스프링이 대신 해주는 것이다.

그래서 개발자는 객체를 직접 생성하지 않아도 된다.

---

Response DTO는 왜 내가 직접 만들어야 할까?

반대로 Response는 상황이 다르다.

사용자에게 어떤 데이터를 보내줄지는 오직 서버만 알고 있다.

 

 

예를 들어 영화를 저장하면

Movie savedMovie = movieRepository.save(movie);

 

저장된 결과에는

• 생성된 ID
• 제목
• 기타 정보

등이 들어있다.

이 중에서 사용자에게 무엇을 보여줄지는 개발자가 결정해야 한다.

그래서 직접 새로운 Response DTO를 만들어 필요한 데이터만 담아준다.

return new CreateMovieResponse(
    savedMovie.getId(),
    savedMovie.getTitle()
);

 

 

즉,

• Request DTO는 클라이언트가 보낸 데이터를 담기 위한 객체
• Response DTO는 서버가 사용자에게 보낼 데이터를 담기 위한 객체

이기 때문에 Response DTO는 개발자가 직접 생성해야 한다.

 

 

DTO를 사용하는 이유

처음에는

"그냥 Entity를 반환하면 되지 않을까?"

라는 생각이 들었다.

 

하지만 Entity를 그대로 반환하면 문제가 생길 수 있다.

예를 들어 Entity가 다음과 같다고 해보자.

Movie

id
title
password
createdDate

 

사용자에게는 제목과 ID만 보여주고 싶은데,

Entity를 그대로 반환하면

• 비밀번호
• 생성일
• 내부 데이터

까지 함께 노출될 수도 있다.

 

그래서 DTO를 사용해 필요한 데이터만 담아서 전달한다.

예를 들어

CreateMovieResponse

id
title

 

이렇게 필요한 정보만 보내는 것이다.

 

---

DTO를 사용하는 또 다른 이유

DTO는 단순히 민감한 정보를 숨기기 위한 것만이 아니다.

Entity는 데이터베이스와 연결된 객체이고,

DTO는 클라이언트와 통신하기 위한 객체이다.

 

만약 나중에 데이터베이스 구조가 변경되어 Entity에 새로운 필드가 추가되더라도,

Response DTO는 그대로 유지할 수 있다.

 

즉,

• 데이터베이스 구조(Entity)
• API 응답(Response DTO)

를 서로 독립적으로 관리할 수 있다는 장점이 있다.