우리는 아직 DTO가 필요할까?

Source: Dev.to

DTO란 무엇인가?

DTO(Data Transfer Object)는 레이어 또는 시스템 간에 데이터를 전달하기 위해 사용되는 구조화된 객체이다. 주로 다음과 같은 목적을 위해 존재한다:

• 백엔드에서 오는 데이터를 검증한다.
• 백엔드 응답을 프론트엔드 요구에 맞게 변환한다.
• 프론트엔드와 백엔드 스키마를 분리하여 깨지는 변경을 방지한다.

전통적인 REST API에서는 응답에 불필요한 필드, 중첩 구조, 혹은 프론트엔드가 필요로 하지 않는 데이터가 포함될 수 있기 때문에 DTO가 흔히 사용된다.

GraphQL이 게임을 바꾸는 방식

GraphQL은 클라이언트가 정확히 필요한 데이터만 요청할 수 있게 해준다. 이는 여러 가지 영향을 미친다:

• 세밀한 쿼리 – 클라이언트‑사이드 쿼리에서 데이터 형태를 정의하므로, 큰 응답을 DTO에 매핑할 필요가 줄어든다.
• 강력한 타입 – GraphQL 스키마는 강력하게 타입이 지정된다. Apollo Codegen이나 GraphQL Code Generator 같은 도구를 사용하면 쿼리와 뮤테이션에 대한 TypeScript 타입을 자동으로 생성할 수 있다.
• 유연한 프론트엔드 진화 – 백엔드가 추가 필드를 제공하더라도, 해당 필드를 쿼리하지 않으면 클라이언트에 영향을 주지 않는다. DTO는 더 이상 깨지는 변경에 대한 방패 역할을 하지 않는다.

여전히 DTO가 필요할 수 있는 경우

GraphQL의 장점에도 불구하고, 프론트엔드에서 DTO를 사용하는 것이 유용한 상황이 있다:

• 비즈니스 로직 변환 – 새로운 필드를 계산하거나, 날짜를 포맷하거나, 여러 쿼리를 하나의 UI에 적합한 객체로 병합한다.
• 검증 또는 정제 – 백엔드에서 온 선택적 혹은 nullable 필드를 UI가 사용하기 전에 더 엄격한 규칙을 적용한다.
• 장기 프로젝트를 위한 분리 – 대규모 팀에서는 DTO가 프론트엔드 코드를 백엔드 스키마 변경으로부터 격리시킬 수 있다. 특히 백엔드가 여러 클라이언트와 공유될 때 유용하다.

대부분의 경우 DTO가 필요 없을 때

• 작은 앱이나 MVP – DTO로 매핑하는 오버헤드가 이점보다 크다.
• 타입‑안전 GraphQL 클라이언트 – 생성된 타입을 사용한다면, 그 타입 자체가 “실시간 DTO” 역할을 한다.
• 직접 UI 소비 – 컴포넌트가 GraphQL 응답을 바로 사용할 수 있다면, DTO를 추가하는 것은 큰 이득 없이 보일러플레이트만 늘린다.

부가 설명: 일부는 여전히 클린 아키텍처의 일환으로 DTO를 선호한다. 여러분은 어떤 입장이신가요?