[Java]DTO는 항상 만들어야 할까?

답은 Yes라고 생각한다.

요청(Request), 응답(Response) 모두 DTO를 만들어주면 좋다.

 

실무에서 API를 설계할 때 요청과 응답 각각에 DTO를 안 쓰면 컨트롤러에서 엔티티를 직접 노출하거나 받아야 하는데, 이건 보안, 유지보수, 확장성 면에서 매우 불리하다. 즉, 계층 분리, 보안, 유지보수, 유연성 모두를 위한 기본 설계 원칙이기 때문에 사실상 필수나 다름 없다.

 

특히 Form 데이터 다룰 때는 100% 써야한다.

@ModelAttribute나 @RequestParam으로 폼 데이터를 받는 경우, 필드를 하나씩 받기보다는 DTO로 묶어서 받는 게 훨씬 명확하고 유지보수하기 좋다. 게다가 필드가 많아질수록 코드가 복잡해지는데, DTO를 쓰면 검증도 쉽게 걸 수 있어서 정말 좋다.

---

 

이유는 4가지 정도로 볼 수 있다.

 

1. 역할 분리

• 컨트롤러는 요청을 받고 응답을 반환하는 역할만 수행해야 한다.
• 서비스나 도메인 영역의 로직은 DTO가 아닌 엔티티(Entity)가 맡는다.
• 이렇게 역할을 나누면 코드가 더 읽기 쉽고 유지보수가 쉬워진다.

예시:
LoginRequestDTO는 사용자 로그인 정보를 받아오고,
User 엔티티는 실제 DB 사용자 정보와 관련된 작업을 수행.

 

 

2. 깔끔한 구조

• DB 모델과 컨트롤러 사이에 중간 계층(DTO)을 둠으로써 의존성을 줄인다.
• 나중에 DB 스키마가 바뀌더라도 DTO를 통해 컨트롤러는 영향 없이 유지 가능.
• DTO를 사용하지 않고 엔티티를 바로 쓰면, 계층 간 강한 결합(coupling)이 생겨 유지보수가 힘들어진다.

 

3. 보안

• 엔티티에 포함된 민감한 정보(예: 패스워드, 내부 상태 값 등)가 외부에 노출될 수 있다.
• DTO를 따로 두면 노출할 필드만 선택적으로 보여줄 수 있어서 안전하다.

예시:
User 엔티티에는 password, role, isDeleted 같은 필드가 있지만,
UserResponseDTO에는 username, email만 포함시켜 응답 가능.

 

 

4. 유연성

 

• 나중에 API 요구사항이 바뀌거나 응답 형식을 가공해야 할 때 DTO를 사용하면 쉽게 변경 가능.
• 예를 들어 날짜 포맷을 yyyy-MM-dd로 바꾸거나, 다른 필드를 추가/삭제해도 엔티티에는 영향을 주지 않음.

---

 

 

🤷‍♀️DTO랑 엔티티 차이점

 

📦 DTO는 배달 상자에 비유할 수 있음. 운반 중에 모양이 바뀌어도 괜찮다.
📦 반면 Entity는 창고에 있는 진짜 물건처럼 애플리케이션 전반에 영향을 준다.

 

구분	DTO (Data Transfer Object)	도메인 모델 / 엔티티 (User)
목적	요청/응답용 데이터 전달	실제 비즈니스 데이터 표현
위치	컨트롤러 ↔ 서비스 사이	서비스 ↔ DB 사이
예시	LoginRequest, SignupResponse	User, Post, Comment
특징	필드가 단순하고 목적에 따라 바뀜	DB 테이블과 매핑됨 (나중에 @Entity)
수명	요청/응답 때 잠깐 사용됨	애플리케이션 전반에서 지속적으로 사용