DTO와 Entity의 분리 이유

 

DTO와 Entity를 왜 분리해야 할까?

한 줄 요약

DTO는 "데이터 전달용", Entity는 "데이터 저장/로직용"이다.
역할이 다르기 때문에 둘을 분리하면 더 안전하고 유지보수에 강한 코드가 된다.

---

핵심 개념 정리

구분 DTO (Data Transfer Object) Entity (도메인 모델)

목적	계층 간 데이터 전달용	DB 테이블 매핑 및 비즈니스 로직 처리
위치	Controller ↔ Service ↔ View 사이	Repository ↔ Service ↔ DB
예시	회원가입폼, 숙소등록폼	Member, Accommodation 등 테이블 객체
사용 범위	외부 입력/응답 전용	DB 저장/조회, 연관관계 포함
포함 데이터	최소한의 필드만	모든 컬럼, 연관 객체 포함
특징	Getter/Setter만 있는 순수 데이터 객체	JPA 어노테이션, 연관관계, 도메인 로직 포함

---

분리하는 이유 5가지

1. 보안

• Entity에는 id, password, userRole, createdAt 같은 민감 정보가 들어 있음
• DTO는 필요한 필드만 담기 때문에, 의도하지 않은 정보 노출을 방지할 수 있음

2. 유효성 검증 (Validation)

• @NotNull, @Pattern, @Min 같은 검증 어노테이션은 DTO에 적용하는 게 자연스럽고 깔끔함
• Entity는 DB 구조고, 검증 책임은 Controller/Service가 갖는 게 명확함

3. 역할 분리 & 유지보수

• View 요구사항이 바뀔 때마다 Entity를 수정하면 DB 구조까지 흔들림
• DTO를 따로 두면 프론트 요청에 맞게 유연하게 대응 가능

4. 테스트 편의성

• 테스트할 때 Entity를 직접 만들면 연관관계 복잡해서 불편함
• DTO는 테스트에 필요한 필드만 있어 단순하고 깔끔함

5. 계층 간 의존성 최소화

• Controller/Service → Entity 직접 사용하면, 도메인 로직이 프레젠테이션 계층에 노출됨
• DTO는 이걸 끊어주는 완충재 역할을 함

---

📌 실전 예시

👎 Entity를 직접 받는 경우

@PostMapping("/register")
public String register(@ModelAttribute User user) {
    // ❌ Entity를 직접 받으면 보안 위험 + 연관관계 파악 어려움
}

👍 DTO로 받는 경우

@PostMapping("/register")
public String register(@ModelAttribute UserRegisterDto dto) {
    // ✅ 필요한 값만 전달받고
    User user = new User(dto.getUsername(), dto.getPassword());
    userRepository.save(user);
}

---

최종 정리

DTO는 "필요한 값만 전달하는 가벼운 택배 상자"
Entity는 "DB 테이블과 1:1로 연결된 무거운 설계도"

둘을 섞지 않고 역할을 나누는 것이 결국 유지보수성, 확장성, 안정성을 모두 가져다줌.

---

필요하면 이걸 Notion에 복사 붙여넣기 쉽게 마크다운 형식으로도 따로 정리해줄게.
계속 정리 이어갈까?