DTO는 왜? 언제 사용할까?

 
DTO란 Data Transfer Object의 약어로, 데이터 전송 객체를 의미한다.
즉, 계층 간 데이터 전송을 위해 사용되는 객체이며 Entity의 사본이라고 할 수 있다.

Entity는 DB에서 나온 데이터의 원본이자 곧 DB로 들어갈, 연산이 끝난 후 원본이 될 객체를 의미한다. 

 

 

하지만 우리는 그동안 DTO를 사용하지 않고도 충분히 API를 만들 수 있었다. 
그런데 왜 개발자들은 하나의 객체, 데이터가 Repository까지 들어가면 무슨 단점이 있기에 DTO를 사용하는 걸까?

 

---

 

1. 필요 없는 데이터에 불필요한 접근 발생

DTO를 사용하지 않고 객체를 그대로 전달하면, 필요하지 않은 컬럼에도 접근하게 된다.

이는 보안 문제를 발생시킬 수 있고, 성능 저하로 이어질 수 있다. 

 

2. 불필요한 데이터의 이동이 발생 

 

실제로 도메인 객체에는 클라이언트에게 굳이 전달되지 않아도 되는 데이터를 포함하고 있기에 네트워크를 통해 불필요한 데이터들이 이동하면 네트워크 비용은 올라가고, 메모리 사용 효율이 떨어질 수 있다. 

 

3.  클라이언트가 필요한 데이터 미포함

구현 코드간에 연관 관계는 없지만 화면에 같이 뿌려져야 할 경우, 클라이언트가 필요한 데이터를 미포함 할 수 있는 가능성이 있다. 
 

4. DB 스키마가 바뀌었을 때 서버측만 바뀌어도 됨 

DTO를 사용하지 않으면 DB 스키마가 바뀔 때 도메인 객체와 연관된 모든 코드가 영향을 받는다.

그러나 DTO를 사용하면 데이터 전송 구조가 분리되어, 서버측의 코드 변경만으로도 문제를 해결할 수 있다. 
즉, DB 컬럼 이름이 바뀐다고 클라이언트를 호출할 때 부를 이름까지 바뀔 필요는 없다. 

 

---

그렇다면 DTO와 Entity가 변환되는 과정은 스프링 3계층(C/S/R) 중 어디에서  일어날까?

DTO(사본) ↔ Entity(원본, DB)

Client → Controller → Service → Repository → DB

DB → Repository→ Service → Controller → Client

 

 

우선, 나는 Service에서 변환해야 한다고 생각한다.

Service에서 모든 연산과 데이터 가공 및 처리를 완료한 후 Entity로 변환해 Repository로 보내거나

Repository에서 받아온 데이터를 Service에서 연산을 마친 후 ResponseDTO로 변환해 Controller에 전송한다. 

 

하지만 Contoller라고 주장하는 여러 CTO님들도 계신다.

그들의 주장은 다음과 같다.

"Service가 클라이언트까지 알아야해..?"

즉, 클라이언트가 어떤 필드를 요구하는지 굳이 Service 계층까지 들어가서 알려줘야 하는게 비효율적이라고 생각한다.

 

우리는 a Controller가 b Controller를 부를 일은 없고 실제로 이를 의존성이라고 한다.

반면, a Service가 b Service 또는 b Repository를 부르는 경우는 종종 발생한다. 

만약 이런 경우가 생긴다면 Entity와 DTO의 변환이 Controller에서 발생하면 코드가 너무 복잡해지지 않을까라고 조심스럽게 생각해본다..