뷰(view)에 엔티티(entity) 를 직접 노출 시키면 안되는 이유 + DTO 변환

개인 프로젝트를 진행하면서 view 페이지에 데이터를 직접 바인딩 하는 과정에서 항상 Serivce Layer 에서 엔티티를 DTO 로 변환하여 Controller Layer 에 전달하고 view 페이지에 데이터를 바인딩 하고 있다.
 
단순히 하나의 테이블을 dto 로 변환해서 Controller Layer 로 넘기고 뷰페이지에 데이터를 바인딩 하는 것은 어렵지 않지만 수많은 테이블의 연관관계를 가지고 있는 여러 엔티티 객체를 조인하여 dto 로 변환하는 것에 처음에는 어려움을 가지고 있어서 뷰페이지에 항상 원하는 데이터가 넘어가지 않는 경우가 종종 발생하였다.
 
먼저 엔티티 객체를 뷰페이지에 직접적으로 바인딩 하면 안되는 이유에 대해 알아보자
 
1. 보안 및 데이터 노출 최소화
- Entity 에는 민감한 정보(예: 비밀번호, 개인정보) 가 포함될 수 있으며, 이를 view 로 직접 노출할 경우 사용자가 불필요하게 접근할 수 있는 위험이 있다.
- DTO 는 필요한 데이터만 포함하여 View 로 전달할 수 있어, 민감한 데이터를 노출하지 않도록 제한할 수 있다. 예를 들어 Entity 에는 password 라는 변수가 존재하지만 DTO 에는 해당 데이터를 생성하지 않고도 데이터를 외부로 전송 할 수 있다
 
2. 불필요한 데이터 전송 방지
- Entity 에는 종종 View 에 필요하지 않은 필드나 연관 관계가 포함될 수 있다. 이를 전부 노출하면 불필요한 데이터가 전송되어 성능에 영향을 줄 수 있다.
 
3. 변경에 대한 유연성 확보
- Entity 는 데이터베이스 구조에 따라 변할 수 있는데, 이를 View 에 직접 노출하면 Entity 변경 시 프론트엔드 코드도 영향을 받게 된다.
- DTO 를 사용하면, Entity 구조가 변경되더라도 View 와의 데이터 형식을 독립적으로 유지할 수 있어 유연성을 확보 할 수 있다.
 
4. 비즈니스 로직 보호
- Entity 에는 비즈니스 로직이 포함될 수 있으며, 이를 노출하는 것은 시스템의 내부 동작 방식을 외부에 드러내는 것이 될 수 있다. 
- DTO 는 순수하게 데이터 전달에 필요한 요소만 포함하도록 항, 비즈니스 로직이 외부에 노출되는 것을 막을 수 있다.
 
5. 데이터 가공 및 표현의 자유도 
- DTO 는 Entity 의 데이터를 특정한 방식으로 가공하여 프론트엔드에 전달할 수 있다. 예를 들어, 날짜 형식을 변경하거나 특정 값을 합산하여 전송할 수 있다. view 페이지에 특정한 근무시간을 합산하여 보여줘야 하는 데이터가 필요하다고 가정할 때, 데이터베이스 컬럼이나 엔티티 데이터를 새로 만들지 않아도 기존의 엔티티 데이터를 가지고 DTO 에서 계산하여 View 페이지로 바인딩 할 수 있다.
 
6. 유지보수성과 테스트 용이성 증가
- Entity 와 DTO 를 분리하면 각각의 책임이 명확해지고, 유지보수와 테스트가 더 쉬워진다. Entity 는 데이터베이스와의 상호작용에 집중하고, DTO 는 데이터 전송에 집중하기 때문에 각 역할에 맞춰 테스트하고 유지보수할 수 있다.