[Spring] DTO를 왜 써?(Entity는 외않되?)

Hanul Jeong·2024년 9월 20일

DTO Java Spring entity

Spring

목록 보기

1/2

0. 들어가며...

지난 여름방학에 진행했던 프로젝트에서 회원가입/로그인 기능을 구현하던 중, 패키지 설계에 DTO 패키지가 별도로 없는 것이었다.

최초에 패키지를 설계해준 친구에게 물었다.
나: DTO 패키지는 따로 없는 거야?
친구: DTO 없이 바로 Entity로 넘겨주면 돼
나: 내가 공부한 건 DTO로 넘겨준다는데..?

당장에 구현을 해내야 해서 일단 DTO를 사용해서 기능을 구현했다. 하지만, 왜 DTO를 사용하는가? 언제 사용해야 하는가? 꼭 사용하지 않아도 되는가? 이런 의문은 해결되지 않았다.

이 글을 통해 DTO의 사용 이유에 대해 완벽하게 이해해 보도록 하자.

1. DTO란?

1-1. DTO? Entity?

데이터 전송 객체(data transfer object, DTO)는 프로세스 간에 데이터를 전달하는 객체이다.
-위키백과

추가적인 설명을 붙이자면, 오로지 데이터 전달만을 위한 순수한 데이터 객체라는 것이다. 따라서, DTO는 별도의 메서드를 가지지 않고 getter / setter만 가진 클래스이다.

다음은 UserDTO 예시이다.

public class UserDTO {
    private Long id;
    private String name;
    private String email;

    // 생성자, getter/setter
}

~~어디서 많이 봤는데...~~
그렇다면 User Entity 예시를 보자.

@Entity
@Table(name = "users")
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private String name;

    @Column(nullable = false, unique = true)
    private String email;

    @Column(nullable = false)
    private String password;

    // 생성자, Getter/Setter
}

DB의 테이블과 매핑하기 위한 어노테이션들을 제거한다면 구조는 동일하다.

그렇다면 컨트롤러, 서비스, 리포지토리 계층 간 데이터 전달에 DTO 대신 Entity를 직접 사용해도 되는 것 아닌가?

1-2. DTO와 Entity의 차이점

위에서 제시한 의문을 해결하기 위해, 차이점에 대해 알아볼 필요가 있다.

	DTO	Entity
역할	계층 간의 데이터 전송을 위한 객체	DB 테이블과 매핑되는 객체
사용 목적	데이터를 전송하고, 외부 API 또는 클라이언트와 상호작용	데이터 저장, 조회, 수정, 삭제 등의 DB 작업
데이터 범위	필요한 필드만 포함 (부분적인 데이터 전송)	DB 테이블의 모든 필드를 포함
변경 영향	DTO 구조 변경은 데이터 전송에만 영향을 미침	Entity 구조 변경은 DB 스키마에 영향을 미침

역할과 사용 목적

DTO는 오직 데이터 전송만을 위한 객체이다. 순수하게 데이터를 담고 있다는 점이 Entity와 유사하지만, 일회성으로 사용되는 성격이 강하다.
또한, DTO는 전송할 데이터만을 포함하기 때문에 외부 API나 클라이언트와의 상호작용 시, 불필요한 정보를 줄여 네트워크 트래픽을 최적화할 수 있다.

Entity에는 데이터와 관련된 비즈니스 로직이 포함될 수 있는데, DTO를 통해 비즈니스 로직이 외부로 노출되는 것을 막고 순수하게 데이터를 전송할 수 있다.

데이터 범위

이는 보안성과 직결되는데, DB로부터 조회한 Entity를 외부에 그대로 노출하게 되면 불필요한 정보 / 민감한 정보까지 노출할 수 있다.

변경 영향

Entity에 대한 요구사항이 변경됐다고 가정하자.
Entity를 통해 데이터를 주고받는 경우라면, 요구사항이 변경될 때마다 DB 구조를 변경해 주어야 한다. DTO를 사용한다면 DB 구조 변경의 부담을 줄일 수 있다.

1-3. DTO와 Entity를 분리하는 이유

앞의 내용을 종합하면 4가지의 이유를 들 수 있겠다.

역할과 책임 분리
- DTO: 데이터 전송에만 사용, 비즈니스 로직 없음
- Entity: DB 작업과 비즈니스 로직 포함
보안성 강화
- DTO: 필요한 데이터만 전송, 민감한 정보 보호
- Entity: 모든 필드를 포함하므로 그대로 노출 시 위험성 있음
네트워크 성능 최적화
- DTO: 불필요한 데이터를 제외하여 전송, 네트워크 트래픽 감소
- Entity: 모든 데이터를 포함해 전송 시 트래픽 증가 가능성
유지보수성 향상
- DTO: 클라이언트 요구에 맞춰 유연하게 수정 가능, DB 스키마와 무관
- Entity: 구조 변경 시 DB 스키마에 직접적인 영향

2. 마치며...

장점이 있으면, 단점도 있기 마련.

기존의 Entity 이외에 추가의 클래스를 만드는 것이기 때문에 코드의 복잡성이 올라가고...
DTO와 Entity 간의 변환 작업이 빈번하게 발생할 경우엔 성능 오버헤드가 발생할 수 있고...
변경 사항이 DTO나 Entity 한쪽에만 적용되어 데이터 불일치나 일관성 문제가 발생할 가능성이 있고...