Entity 대신 DTO를 써야 하는 이유

✅ 1. 🔐 보안 문제 – 민감한 정보 노출 방지

💬 설명

Entity에는 클라이언트에게 보여주면 안 되는 민감한 정보도 함께 포함돼 있을 수 있어요.
예를 들어, User 엔티티에 password, email, role 같은 필드가 있다면 이걸 그대로 반환하면 위험합니다.

 

❌ Entity 직접 반환 예

@Entity
public class User {
    private Long id;
    private String username;
    private String password;   // ❗️절대 노출되면 안 됨
    private String email;
    private String role;
}

@GetMapping("/users")
public List<User> getUsers() {
    return userService.findAll();  // ❗️password까지 클라이언트에 전달됨
}

 

✅ DTO 사용 예

public class UserResponseDto {
    private String username;
    private String email;
}

@GetMapping("/users")
public List<UserResponseDto> getUsers() {
    return userService.findAll().stream()
        .map(user -> new UserResponseDto(user.getUsername(), user.getEmail()))
        .collect(Collectors.toList());
}

🔐 → DTO를 사용하면 필요한 정보만 선택해서 줄 수 있으니 보안에 안전합니다.

 

✅ 2. 🧱 응답 포맷 커스터마이징 – 필요한 형식으로 변환 가능

💬 설명

Entity는 DB 모델이기 때문에 클라이언트에게 주기엔 불친절한 구조일 수 있어요.
DTO에서는 필드명을 바꾸거나, 날짜 포맷 변경, 가공된 값 추가 등을 할 수 있습니다.

❌ Entity 직접 반환 시

@Entity
public class Board {
    private LocalDateTime createdAt;
}

클라이언트는 "createdAt": "2024-10-24T16:25:00" 이렇게 받음 → 보기 어렵고 형식이 다양할 수 있음.

---

✅ DTO로 포맷 가공

public class BoardResponseDto {
    @JsonFormat(pattern = "yyyy-MM-dd HH:mm")
    private LocalDateTime createdAt;
}

📦 클라이언트는 "createdAt": "2024-10-24 16:25"처럼 보기 좋은 형식으로 받게 됨.

또는 필드명도 변경 가능:

@JsonProperty("created_date")
private LocalDateTime createdAt;

 

 

✅ 3. 🔄 유연성 확보 – Entity 변경이 외부 API에 영향 없도록

💬 설명

Entity 구조는 프로젝트 내에서 언제든 변경될 수 있어요.
예를 들어, DB 설계 변경으로 Board 엔티티에 category 필드가 추가되었을 때,
Entity를 직접 반환하면 클라이언트 API 응답이 바뀌게 됩니다.

→ API 응답을 고정하고 싶다면 DTO를 써야 합니다.

❌ Entity 직접 반환 시

// 클라이언트는 이렇게 받게 되는데
{
  "id": 1,
  "title": "제목",
  "content": "내용",
  "writer": "홍길동",
  "category": "공지사항"  // 필드 추가됨
}

→ 클라이언트 쪽에서 에러 발생 가능

---

✅ DTO 사용 시

public class BoardResponseDto {
    private Long id;
    private String title;
    private String content;
    private String writer;
}

 

→ Entity는 바뀌어도, DTO는 고정된 필드만 제공하므로 API 안정성 확보 가능

---

✅ 4. 🔁 순환참조 방지 – JPA 연관관계로 인한 JSON 무한 루프 막기

💬 설명

JPA는 연관관계를 갖기 때문에 양방향 매핑에서 서로 참조하는 필드들이 JSON으로 변환될 때 무한 루프가 생길 수 있어요.

❌ 예: Entity 직접 반환 시 순환참조

@Entity
public class Board {
    @ManyToOne
    private User writer; // Board → User
}

@Entity
public class User {
    @OneToMany(mappedBy = "writer")
    private List<Board> boards; // User → Board
}

→ Board → User → Board → User → ... 순환 참조 발생

 

Board 객체를 클라이언트에 반환할 때, Spring은 내부적으로 Jackson이라는 라이브러리를 사용해서 객체를 JSON으로 변환합니다.

예를 들어 Board를 반환한다고 할 때:

{
  "id": 1,
  "title": "제목",
  "writer": {
    "id": 10,
    "name": "홍길동",
    "boards": [  // 여기서 다시 Board 리스트 시작!
      {
        "id": 1,
        "title": "제목",
        "writer": {
          ...
        }
      }
    ]
  }
}

이렇게 JSON 변환 시, Jackson은 Board → User → List<Board> → User ...
끝없이 참조를 따라가며 무한히 JSON을 생성하려고 하다가 StackOverflowError 발생!

 

실행 시 에러:

com.fasterxml.jackson.databind.JsonMappingException: Infinite recursion

 

✅ DTO로 방지

필요한 정보만 꺼내서 DTO에 담으면, 순환 구조 자체가 사라져요.

public class BoardResponseDto {
    private String title;
    private String writerName;  // writer.getName()만 사용
}

→ User를 전부 담지 않고, writer.getName()으로 필요한 정보만 꺼내와서 DTO에 넣기

 

✅ 정리 표

항목문제점 (Entity 직접 반환 시)DTO 사용 효과

🔐 보안	민감 정보 노출	필요한 정보만 전달
🧱 포맷	보기 어려운 JSON, 필드명	보기 좋은 형태, 이름 변경 가능
🔄 유연성	Entity 변경 시 API도 영향	API 응답 형식 고정 가능
🔁 순환참조	JSON 변환 시 무한 루프	필요한 정보만 추출해 전달