"DTO 없이 Entity만 쓰면 안 되나요?" 실무 기준으로 답해드립니다.

Spring Boot로 개발을 하다 보면 한 번쯤 이런 질문을 받습니다.

DTO 없이 Entity만 써도 되는 거 아닌가요?
둘이 너무 비슷하게 생겼는데 굳이 나눠야 하나요?

결론부터 말하면, 기술적으로는 가능하지만, 실무에서는 거의 분리합니다.

왜 그런지 하나씩 살펴보겠습니다.

1. Entity와 DTO는 역할이 다릅니다

겉으로 보면 둘 다 비슷한 "데이터 클래스"처럼 보입니다.

하지만 역할은 완전히 다릅니다.

• Entity
  → 데이터베이스 테이블과 매핑되는 객체
  → DB 중심 구조
• DTO
  → API 요청/응답을 위한 객체
  → 클라이언트 중심 구조

즉, Entity는 "저장용", DTO는 "전달용"입니다.

2. Entity만 사용할 때 발생하는 문제

2-1. API 스펙이 DB 구조에 종속됨

예를 들어 Entity가 이렇게 생겼다면:

@Entity
class User {
    String username;
    String password;
    String email;
}

이걸 그대로 응답으로 내려주면?  password까지 그대로 노출됩니다.

즉, DB 구조가 곧 API 스펙이 되어버립니다.

2-2. 요구사항 변경에 취약

프론트에서 이런 요구가 생겼다고 가정해봅시다.

• username → userName으로 변경
• email은 숨기기
• fullName 필드 추가

DTO가 없다면?

• Entity를 계속 수정해야 합니다.
• 결국 DB 구조까지 영향을 받습니다.
  
  

2-3. 성능 문제 (Lazy Loading)

Entity는 연관관계를 가지고 있습니다.

class Order {
    @ManyToOne
    User user;
}

이 상태에서 Entity를 그대로 반환하면

• JSON 변환 과정에서 연관 객체를 계속 탐색
• 필요 없는 데이터까지 조회

N+1 문제 발생 가능
성능 저하

2-4. 보안 및 데이터 제어 문제

Controller에서 Entity를 그대로 받으면:

@PostMapping
public void create(User user)

• 클라이언트가 의도하지 않은 필드까지 수정 가능
• 내부 데이터 보호가 어려움

 

3. DTO를 사용하면 좋은 점

3-1. API를 자유롭게 설계 가능

class UserResponseDto {
    String username;
}

필요한 데이터만 선택적으로 노출

3-2. 보안 강화

• password 숨김
• 내부 필드 숨김
• 민감 정보 통제 가능
  
  

3-3. 계층 분리

• Controller ↔ Service ↔ Repository 역할 분리
• 각 계층의 책임이 명확해짐
• 유지보수 쉬워짐
  
  

3-4. 성능 최적화

• 필요한 데이터만 조회
• 쿼리 최적화 가능

4. 그럼 Entity만 써도 되는 경우는?

완전히 불가능한 건 아닙니다.

다음과 같은 경우에는 사용하기도 합니다.

• 작은 토이 프로젝트
• 빠르게 만들어야 하는 경우
• 외부에 공개되지 않는 내부 API
• 하지만 규모가 커지면 결국 DTO로 분리하게 됩니다.
  
  

5. 한 줄 정리

Entity = 데이터 저장 구조
DTO = 데이터 전달 구조

비슷해 보여도 역할이 완전히 다르기 때문에 분리하는 것이 맞습니다.

6. 쉽게 이해하는 비유

• Entity = 설계도
• DTO = 고객에게 보여주는 화면

설계도를 그대로 고객에게 보여주진 않습니다
필요한 정보만 가공해서 전달합니다

 

마무리

DTO를 따로 만드는 것이 처음에는 번거롭게 느껴질 수 있습니다.

하지만 프로젝트가 커질수록

• 유지보구
• 확장성
• 안정성

이 세 가지에서 큰 차이를 만들어냅니다.

실무에서는 “선택”이 아니라 사실상 필수에 가까운 구조라고 보시면 됩니다.