DTO, Domain 비교

DTO vs Domain (Entity) — 왜 분리해야 할까?

스프링 부트로 프로젝트를 하다 보면,
Controller에서 데이터를 주고받을 때 Entity를 그대로 쓸지, DTO를 따로 만들어야 할지 헷갈릴 때가 많다.
둘 다 데이터를 담는 객체지만, 역할과 사용 목적이 완전히 다르다.

---

1. Domain(Entity)

Entity는 데이터베이스와 직접 연결되는 객체다.
스프링에서는 주로 @Entity 어노테이션을 붙여서 DB 테이블과 1:1 매핑한다.

역할

• DB 테이블과 직접 연결
• JPA 어노테이션으로 구조 정의
• 비즈니스 로직의 핵심 객체

문제점

• 보안 이슈: 비밀번호나 내부 식별자 같은 정보가 그대로 노출될 수 있다.
• 불필요한 데이터: 연관관계가 함께 조회되어 응답이 무거워진다.
• 변경에 취약: 요청/응답 형식이 자주 바뀌면 Entity 구조도 영향을 받는다.

---

2. DTO (Data Transfer Object)

DTO는 말 그대로 “데이터 전송용 객체”다.
Entity를 그대로 노출하지 않고, 필요한 데이터만 따로 담아 Controller ↔ 클라이언트 간 통신에 사용한다.

역할

• 클라이언트와 서버 간 데이터 전송
• 필요한 필드만 노출
• API의 요청/응답 형식을 명확히 정의

---

정리표

구분	Domain(Entity)	DTO
목적	DB 테이블과 매핑	계층 간 데이터 전송
사용 위치	Repository, Service 내부	Controller ↔ 클라이언트
특징	JPA 어노테이션 포함	순수 데이터 객체
변경 빈도	DB 구조 변경 시	API 요구사항 변경 시
보안	내부 정보 포함 가능	필요한 데이터만 노출

 

---

실무 팁 (?)

• 작은 프로젝트나 학습 단계에서는 Entity를 그대로 써도 큰 문제는 없다.
• 하지만 실제 서비스나 보안이 중요한 환경에서는 반드시 DTO를 따로 두는 게 좋다.
  → Entity는 내부 로직용, DTO는 외부 통신용으로 구분하면 된다. 

---

 

Entity와 DTO를 구분하는 건 단순한 코드 스타일 문제가 아니다.
도메인 모델을 보호하고, API를 안정적으로 설계하기 위한 핵심 원칙이다.
규모가 커질수록 이 두 객체의 경계를 명확히 해야 유지보수도 훨씬 쉬워진다.