DTO와 Entity 분리하기: 왜, 어떻게, 어디까지?

Spring Boot 기반 웹 애플리케이션을 개발하다 보면 DTO(Data Transfer Object)와 Entity를 구분하지 않고 사용하는 경우가 종종 있습니다. 특히 초보 개발자일수록 @Entity 클래스를 그대로 컨트롤러에 넘기거나, 클라이언트 요청 바디에 바인딩하는 실수를 저지르기도 합니다.

하지만 실무에서는 DTO와 Entity를 명확히 분리하는 것이 유지보수성과 보안, 유연한 확장성 측면에서 매우 중요합니다.

 

1. DTO와 Entity의 역할 차이

• Entity: JPA에서 데이터베이스 테이블과 매핑되는 핵심 도메인 객체입니다. 주로 Repository 계층과 연동됩니다.
• DTO: 계층 간 데이터 전달을 위한 객체로, 프레젠테이션 레이어(View, API)와 도메인 모델 간의 간극을 메워줍니다.

한마디로, Entity는 DB와, DTO는 클라이언트와 대화합니다.

 

2. 왜 분리해야 하는가?

2-1. 보안 및 유효성 검증 문제

Entity를 그대로 클라이언트와 주고받으면, 클라이언트가 의도하지 않은 필드(예: 관리자 권한, 내부 식별자 등)를 조작할 수 있는 보안 문제가 발생할 수 있습니다.

2-2. 유지보수성 확보

Entity 구조가 바뀔 때마다 모든 API에 영향을 준다면 유지보수가 매우 어렵습니다. DTO를 도입하면 API 응답 구조를 고정할 수 있어 안정성을 확보할 수 있습니다.

2-3. 관심사의 분리

Entity는 비즈니스 로직 중심, DTO는 표현(또는 수신) 중심이므로 명확한 책임 분리가 가능합니다.

3. DTO 분리 예제

예시 1: 회원 등록

// Entity
@Entity
public class User {
    @Id
    @GeneratedValue
    private Long id;

    private String name;
    private String email;
    private String role; // 예: "ADMIN", "USER"
}

// DTO
public class UserCreateRequest {
    private String name;
    private String email;
}

// Controller
@PostMapping("/users")
public ResponseEntity<Void> createUser(@RequestBody @Valid UserCreateRequest request) {
    User user = new User();
    user.setName(request.getName());
    user.setEmail(request.getEmail());
    user.setRole("USER"); // 기본 권한 지정

    userRepository.save(user);
    return ResponseEntity.ok().build();
}

예시 2: 응답 전용 DTO

public class UserResponse {
    private String name;
    private String email;

    public UserResponse(User user) {
        this.name = user.getName();
        this.email = user.getEmail();
    }
}

// Controller
@GetMapping("/users/{id}")
public ResponseEntity<UserResponse> getUser(@PathVariable Long id) {
    User user = userRepository.findById(id).orElseThrow();
    return ResponseEntity.ok(new UserResponse(user));
}

 

 

4. 변환을 효율적으로 하기 위한 팁

• ModelMapper 또는 MapStruct를 사용하여 Entity-DTO 간 변환을 자동화할 수 있습니다.
• 단순 매핑은 생성자나 정적 팩토리 메서드(static method)를 활용해도 충분합니다.

 

5. 주의할 점

• DTO에 @Entity나 @Table 어노테이션을 붙이지 마세요. JPA 관리 대상이 아닙니다.
• DTO는 직렬화/역직렬화가 쉬운 구조여야 하므로, 무거운 비즈니스 로직은 넣지 않는 것이 좋습니다.
• Entity에 Presentation 레이어의 유효성 검증 로직(@NotNull 등)을 함께 두지 마세요. 유효성 검사는 DTO에서 담당하는 것이 바람직합니다.

 

6. 결론

DTO와 Entity를 분리하면 개발 구조가 처음엔 다소 복잡해질 수 있지만, 장기적으로 볼 때 유지보수성과 확장성, 보안성 측면에서 큰 이점을 가져옵니다. 특히 API 응답 구조를 안정적으로 유지하고, 도메인 모델의 변경이 외부에 영향을 미치지 않도록 하려면 반드시 분리를 고려해야 합니다.