Data Transfer Object 의 필요성

사실이 아니라 공부한 내용과 생각을 정리한 글입니다. 언제든 가르침을 주신다면 감사하겠습니다.

 

1.  DTO 만들자 VS DTO 만들지 말자

최근 API 개발을 하면서 DTO 가 꼭 필요하다 vs DTO를 꼭 만들어야만 하냐 사이에서 작은 논쟁이 있었습니다.

DTO 를 만들 필요가 없다는 분들의 주장은 아래와 같았습니다.

1. 굳이 별도의 객체를 하나 더 만들어야 하기 때문에 관리 포인트가 증가한다.
2. DTO의 수가 늘어날수록 DTO <-> Entity 메핑 코드가 불필요하게 반복되고 Entity 만 있을 때 보다 메모리를 불필요하게 많이 차지한다.

습관적으로 DTO를 만들어 왔었을 뿐 왜 DTO를 만들어야만 하는지 깊게 고민해 보지 않았기 때문에 DTO의 필요성에 대해 확실하게 반론하지 못하는 스스로를 발견하게 되어 이 글을 통해 정리하고 넘어가려 합니다.

 

2. 왜 Entity 만으로는 안 되는가

위에서 DTO 를 만들지 말자에 대한 이유를 언급했는데 그럼에도 불구하고 DTO를 만들자!라고 주장하기 위해선 단점을 커버할 만큼 커다란 장점이 있으면 된다고 생각합니다.

 

DTO를 만들어야 하는 이유를 살펴보기 전에 Entity의 특성을 살펴보는 게 좋을 것 같습니다.

Entity는 기본적으로 데이터베이스 테이블과 메핑 되며, 무수한 요구사항에서 핵심이 되는 객체일 가능성이 매우 높습니다. 
예를 들어, 회원 Entity 가 있다고 가정해 보죠. 회원에 대한 기본 동작(등록, 수정, 삭제, 조회) 뿐 아니라 소셜 로그인, 간편 로그인 등등 요구사항은 얼마든지 확장될 수 있고 그 요구사항 모두 핵심 객체인 회원 Entity와 연관되어 있을 것입니다.

이는 최악의 경우, 하나의 Entity 객체가 모든 요구사항과 강하게 결합될 수 있다는 의미 이고 회원 Entity의 필드 하나만 변경되어도 연관된 모든 기능들에 영향을 미칠 수 있음을 의미합니다.

가장 최악인 것은 어디까지 영향도가 있을 지 도무지 예측이 되지 않는다는 것이죠. 이는 유지보수의 지옥으로 이어질 가능성이 높습니다.

 

수 많은 기능들이 하나의 데이터베이스 테이블을 바라보며 동작을 하게 되고, 데이터베이스 테이블을 대변하는 JAVA 세상의 객체가 Entity라는 점을 감안하면, 하나의 Entity 객체가 수많은 기능과 논리적으로 연관되어 있는 것은 어쩔 수 없는 선택이라고 생각합니다. 

하지만 연관된 정도(결합도) 를 낮추는 것은 가능합니다. DTO를 만들면 됩니다.

3.  DTO 를 만들자

소프트웨어 세상에서 결합도를 낮추기 위해 가장 흔하게 사용되는 방법이 중간 계층을 두는 것입니다.

DTO는 핵심 Entity와 연관된 기능들 사이에 일종의 중간 계층을 두어, 각각의 기능과 Entity의 결합도를 낮추기 위해 필요합니다.

결합도를 낮추게 되면 얻는 이점은 아래와 같습니다.

1. 기능별로 상이한 요구사항(ex> 요청 파라미터 검증) 을 하나의 Entity에 다 밀어 넣는 것이 아니라, 각각의 DTO 가 각각의 기능들에 대한 단일 책임만 지도록 설계할 수 있다.
2. (서비스 레이어에서 Entity <-> DTO 메핑이 모두 이루어진다고 가정했을 때) Entity 의 변화에 따른 추가적인 변경 지점을 서비스 계층으로 격리할 수 있다.
3. Entity 객체가 수정되었을 때, Entity <-> DTO 메핑 코드에서 명시적인 컴파일 오류가 발생해 주기 때문에 실수를 방지할 수 있다.

 

DTO를 만들면 별도의 객체를 만들어야 하고 메핑 코드도 늘어날 수밖에 없기 때문에 불편하다고 느낄지 모릅니다. 

하지만 개발 시 단순 반복 코드를 조금 더 넣는 것이 유지보수에서 엄청난 이득을 가져다 준다면 득실을 따졌을 때 실보단 득이 많은 작업이라고 생각합니다.