[Spring] DTO 와 Entity 의 개념과 차이
Spring Boot 로 프로젝트를 진행하면서 코드를 작성하고 있는데
DTO 는 데이터 전송을 위한 객체, Entity 는 DB 와 연결하는 객체라고 개념만 알고 있어서
이번 기회에 DTO 와 Entity 의 개념과 차이를 정리해본다
DTO, Data Transfer Object
계층 간 데이터를 전달하는 객체
일반적으로 데이터를 캡슐화하고, 필요한 정보만 포함하도록 설계된다
클라이언트에 응답 데이터를 보낼 때, 엔티티의 민감한 정보를 제외하거나 필요한 정보만 전달한다
🐣 예를 들어, 서버와 클라이언트가 통신할 때 데이터를 교환해야 하는데,
이 데이터를 하나로 묶어서 전달하는 데 사용된다
즉, DTO 는 데이터를 간단하게 포장해서 서버와 클라이언트가
데이터를 쉽게 주고 받을 수 있도록 도와주는 도구이다 🐣
DTO 는 어떠한 비즈니스 로직도 포함하지 않아도 되는 단순한 객체이기 때문에
순수하게 데이터를 저장하고, 데이터에 대한 Getter (조회), Setter (저장) 만 가져야 한다
그렇지만, 유선상 데이터 전송을 위해 직렬화와 역직렬화 로직을 포함할 수 있다
🐣 직렬화 Serialization - 데이터를 전송 가능한 형식 (ex. JSON, XML) 으로 변환
역직렬화 Deserialization - 전송된 데이터를 다시 객체로 변환 🐣
Entity
하나의 독립된 개체 또는 객체
(https://helloahram.tistory.com/188 여기에 정리했었는데 다시 공부해야지)
현실 세계의 사물, 사람, 사건 등을 소프트웨어에서 표현할 때 사용한다
Entity 의 구성 요소
1. 엔티티 이름 - 무엇을 표현하는지 나타낸다 (ex. 학생, 도서)
2. 엔티티 속성 Attribute - 엔티티가 가진 정보 (ex. 학생의 이름, 학번, 전공)
3. 식별자 Primary Key - 엔티티의 각 항목을 구별하는 고유한 값 (ex. 학번)
Entity 의 특징
1. 독립적 - 다른 것들과 구별되는 고유한 개체
2. 속성 보유 - 각 Entity 는 정보를 나타내는 속성을 가진다
3. 관계 형성 - 다른 Entity 와 관계를 가질 수 있다
Entity 의 종류
1. 독립 엔티티 - 다른 엔티티에 의존하지 않음 (학생 Student, 책 Book, 고객 Customer)
2. 종속 엔티티 - 다른 엔티티에 의존적임 (수업 등록 Student ↔ Class, 주문 정보 Customer ↔ Order)
DTO 와 Entity 의 차이
| 특징 | DTO | Entity |
| 역할 | 데이터 전송 용도 | 데이터 저장 |
| 데이터베이스 연동 | 없음 | 있음 (DB 테이블과 매핑) |
| 비즈니스 로직 | 없음 | DDD 에서는 포함 가능 |
| 구조 | 단순 | 복잡 (관계 매핑 포함 가능) |
| 보안 및 성능 | 민감한 데이터 제외 가능 | 모든 필드 포함 |
| 범위 | 계층 간 데이터 이동 | 어플리케이션 전체에서 사용 |
그래서 Entity 를 직접 반환하지 않고
DTO 로 변환하여 반환하는 이유가 뭘까?
1. 캡슐화와 보안 유지
Entity 는 데이터베이스와 직접적으로 매핑된 객체이므로,
이를 이대로 반환하면 민감한 데이터나 불필요한 정보가 외부에 노출될 위험이 있다
DTO 는 필요한 데이터만 추출해서 전달하므로, 민감한 정보 노출을 방지할 수 있다
2. 응답 데이터 최적화
Entity 는 데이터베이스 테이블 전체 구조를 나타낸다
하지만 클라이언트는 필요한 일부 데이터만 요청할 수 있다
DTO 는 요청에 맞게 필요한 데이터만 포함하므로, 불필요한 데이터를 줄여 성능을 최적화할 수 있다
3. 비즈니스 로직 분리
Entity 는 데이터베이스와의 연결을 관리하는 객체이므로 비즈니스 로직과는 분리되어야 한다
DTO 는 데이터 전송 역할만 담당하기 때문에 비즈니스 로직과 데이터베이스 로직의 혼합을 방지한다
🐣 만약 Entity 안에 비즈니스 로직이 추가된다면, 데이터베이스와의 관계가 복잡해지고 유지보수가 어려워진다
데이터를 단순히 저장/ 조회하려는 코드와, 데이터를 처리하려는 코드가 뒤섞여 가독성이 떨어지는 문제가 발생한다
DTO 는 오직 데이터를 담는 그릇으로만 사용되기 때문에, 계산, 데이터 가공 등의 로직이 들어가지 않는다 🐣
4. 변경 관리의 용이성
Entity 구조가 변경되면 API 응답 구조도 영향을 받을 수 있다
DTO 를 사용하면 Entity 변경이 클라이언트 응답에 영향을 미치지 않도록 설계할 수 있다
클라이언트가 사용하는 API 응답을 DTO 로 고정하면, API 버전별 응답을 유연하게 관리할 수 있다
5. 직렬화/ 역직렬화에 적합
Entity 는 직렬화와 역직렬화 시 불필요한 연관 관계나 데이터가 포함될 수 있다
🐣 데이터베이스와 관련된 정보인 외래키, 연관 관계 등이 포함될 수 있는데,
이런 데이터는 클라이언트에게 필요 없거나 보안 상 위험할 수 있다 🐣
DTO 는 전송에 필요한 데이터만 포함하기 때문에 직렬화/ 역직렬화에 최적화되어 있다
6. 단방향 데이터 흐름 유지
Entity 를 클라이언트에 그대로 반환하게 된다면, 클라이언트가 받은 데이터를 수정하고 다시 서버로 전송하고,
서버는 이 데이터를 저장하려고 할 때 Entity 의 상태 관리가 복잡해진다
DTO 를 통해 데이터 흐름을 단방향으로 유지하면 데이터 일관성을 보장할 수 있다
🐣 데이터를 클라이언트로 보낼 때는 Entity → DTO 변환을 거치고
클라이언트가 데이터를 서버로 보낼 때는 DTO → Entity 변환을 거치게 하면
Entity 의 상태를 직접적으로 변경하지 않으므로 데이터 일관성을 보장한다 🐣
정리하자면,
Entity 는 데이터베이스와 연결된 순수 데이터 객체로 남아야 하고,
DTO 는 데이터를 주고 받는 용도로만 사용해야 한다
비즈니스 로직은 Service Layer 에서 담당해야 코드가 깔끔하고 유지보수가 쉬워진다