[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 에서 담당해야 코드가 깔끔하고 유지보수가 쉬워진다