dto란?

---

DTO란?

💡

Data Trasnfer Object 란 계층간 데이터 교환을 위해 사용하는 객체이다.

즉, 클라이언트 요청에 포함된 데이터를 담아 서버 측에 전달하고,

서버 측의 응답 데이터를 담아 클라이언트에 전달하는 계층간 전달자 역할을 한다.

DTO를 사용하는 이유는?

• 계층 간 명화관 분리: 백엔드의 내부 도메인 모델과 프론트엔드로 노출되는 데이터 구조를 분리할 수 있다. 이를 통해 내부 모델이 변경되어도 외부 API는 안정적으로 유지할 수 있다
• 데이터 변환 및 가공: 백엔드의 데이터 모델을 프론트엔드에서 사용하기 적합한 형태로 변환할 수 있다. 예를 들어, 날짜 형식 변환이나 계산된 필드 추가 등이 가능하다.
• API 버전 관리: API가 발전함에 따라 여러 버전의 DTO를 유지하여, 이전 API 버전과의 호환성을 보장할 수 있다.
• 유효성 검증: DTO에서 데이터 유효성 검증 로직을 구현하여 시스템에 들어오는 데이터의 품질을 보장할 수 있다.

DTO를 사용했을 때 단점

어떤 기술이든 사용했을 때의 장단점은 분명 존재하기에, DTO를 사용했을 때 발생하는 단점을 알아보았다.

• 중복 코드 증가: 도메인 모델과 DTO 간의 변환 코드를 작성해야 하므로 중복 코드가 증가한다. 이는 소규모 프로젝트보다 대규모 프로젝트에서 유지보수 부담을 늘릴 수 있다.
• 개발 시간 증가: 각 도메인 객체마다 DTO를 정의하고 변환 로직을 구현해야 하므로 개발 시간이 늘어난다.
• 동기화 문제: 해당 도메인에 하나의 API 또는 props를 넘겨줄 때, 해당 DTO 또한 추가하거나 수정해줘야하기 때문에 번거로움이 추가된다.
• 복잡성 증가: 시스템에 추가적인 계층이 생기면서 전체 아키텍처의 복잡성이 증가한다. 특히, 소규모 프로젝트에서는 이러한 복잡성이 불필요할 수 있다.

의문점

💡

DTO에 대해 찾아보면서 ‘그럼 애초에 백엔드에서 프론트로 데이터를 보낼 때, 프론트가 요구하는 데이터로 보내주면 되지 않을까?’라는 의문이 들었다.

⇒ 해당 의문에 대한 정답(?)은 DTO는 데이터 형식 변환 측면 뿐만 아니라, 아키텍쳐적 이점으로써도 사용되기 때문에 해당 생각은 맞지 않다는 것이다. 구체적으로 정의하면 다음과 같다.

• 관심사의 분리: 백엔드는 비즈니스 로직과 데이터 처리에 집중하고, 프론트엔드는 사용자 인터페이스와 경험에 집중한다. DTO는 이 두 영역 사이의 명확한 경계를 제공한다.
• 유연성: 프론트엔드의 요구사항은 자주 변경될 수 있다. 그렇기 떄문에 백엔드에서 모든 변환 로직을 처리한다면, 프론트엔드의 작은 변화에도 백엔드 코드를 수정해야 할 수 있기 때문에 이는 불필요하다.
• 프론트 독립적 개발: 프론트에서 자체적으로 데이터 변환 로직을 관리함으로써, 백엔드에 의존하지 않고 필요한 데이터 변경을 직접 구현할 수 있기 때문에, 프론트의 유연성이 증가한다.

DTO의 형태

⇒ 해당 사진은 NEXT JS에서 지향하는 DTO의 형태이다.

⇒ 해당 사진처럼 백엔드에서 불러오는 Task라는 API 데이터에 대한 타입을 미리 지정해준다.

결론

즉, DTO에 중요한 비지니스 로직은 담지 않고, 데이터의 전송 로직만 담아야한다. 예를 들어, A라는 데이터를 백엔드에서 프론트로 주고 있을 때 A를 B라는 타입으로 바꾸고 싶다면 해당 DTO만 바꿔주면 손쉽게 데이터 타입을 바꿀 수 있다. 그리고 프로젝트의 규모에 따라 DTO를 도입하는게 가장 바람직 해보인다.