DTO에 대해서 생각하게 된 이유

실무를 시작한 지 1달 반 정도가 지났다. MyBatis를 사용하면서 resultType을 DTO로 받는 경우가 많았는데, Select 쿼리에서 필요한 컬럼만 조회하더라도 DTO에는 모든 필드가 정의되어 있기 때문에 조회되지 않은 값은 null로 채워진다. 이를 어떻게 처리할 수 있을까 고민하던 중, '목적 기반 DTO'라는 개념을 알게 되었다.

목적 기반 DTO가 뭔데?

같은 엔터티라도 조회용, 저장용, 삭제용 등 목적에 따라 다른 DTO를 선언하는 방식이다. 예를 들어 아래와 같다.

public class UserCreateDto {
    private String name;
    private String email;
}

public class UserResponseDto {
    private Long id;
    private String name;
    private String email;
}

public class UserDeleteDto {
    private Long id;
}

해당 DTO 분리의 장점

• 각 요청/응답의 역할이 명확해져 가독성과 유지보수성이 향상된다.
• 불필요한 필드 노출을 방지할 수 있다. (개인적으로 가장 고민했던 부분이다.)

단점

• DTO 클래스가 많아져 관리 피로도가 생긴다.
• 비슷한 필드 구조를 가진 중복된 클래스가 생길 수 있다.
• 실상 하나의 DTO로도 충분히 처리 가능한 경우가 많다.

내 생각

필드가 많든 적든 클라이언트에 보이지 않고, DB에 특별한 부담을 주는 것도 아니라면 굳이 나눌 필요가 있을까? 라는 의문이 들었다.

구글링을 해봐도 대부분 DTO vs VO에 대한 이야기만 많고, ‘목적 기반 DTO’라는 키워드는 상대적으로 생소하게 다가왔다.

회사에서는 빠르게 기능을 완성하는 게 우선이었기 때문에, 깊게 고민하지 않고 일단 넘어갔다.

그래서 나는 어떻게 했나?

직장 동료분께 여쭤봤는데, 돌아온 반응은 “굳이?“였다. 물론 케이스에 따라 분리할 필요는 있지만, 대부분은 하나로도 충분하다는 입장이었다. 결국 나도 고민하다가 DTO를 분리하지 않기로 결정했다. 필요하다면 나중에 리팩토링해도 늦지 않다고 생각했다.

생각을 많이 하는 개발자가 되자.

회사 동료분과 짧게라도 의견을 주고받는 과정에서 내가 놓치고 있던 시각을 배울 수 있었고, 결과물도 더 나은 방향으로 갈 수 있다는 걸 느꼈다.

앞으로도 주어진 방향을 그대로 따르기보다, “왜 이렇게 하지?“라고 한 번 더 생각해보는 습관을 들이고 싶다.