DTO request와 response

안녕하세요 오쩜오님! 🙂 좋은 질문 감사드립니다. 👍

결론부터 말씀드리면 성능상 차이는 없고, 더 나은 유지보수를 위해서입니다.

우선 현재 상태를 보겠습니다.

현재 UpdateRequest는 id와 name이 있고, CreateRequest는 name과 age가 있죠!

만약 이들을 합친 UserRequest 를 만들어 필드를 모두 적게 된다면, id / name / age를 갖고 있을 겁니다.

그리고 이후 로직을 작성하면 몇 가지 혼란이 생깁니다.

[case 1 - UserRequest를 사용하는 POST 로직]

DTO에는 id가 들어옵니다.
그런데 유저를 생성하는 로직에서는 id를 지정하지 않고 auto_increment를 사용하고 있죠.
최초로 UserRequest를 사용한 사람은 이러한 로직이 당연하다고 느끼지만,
이러한 맥락을 접하지 않은 새로 들어온 (혹은 동료) 개발자는 이상하게 느낍니다.
- 엇.. 왜 id도 받고 있는데 id는 주어진 값을 사용하지 않는거지? 버그인가?
- id를 안쓸 거면 왜 이렇게 DTO를 합쳐둔거지? 무슨 이유가 있나?
코드를 보며 직관적이지 않고 100% 이해되지 않는 부분이 있다면 해당 부분을 변경하는데 혹시 모를 버그를 만들 수도 있기에 코드 변경에 있어 거부감이 들게 되고, 더 나은 코드로 리팩토링 할 수 없게 됩니다.

[case 2 - UserRequest를 사용하는 PUT 로직]

이런 일은 update 로직에서도 동일하게 발생합니다.
DTO에는 id와 name, age가 있죠. 그런데 정작 업데이트되는 항목은 '이름'입니다.
그럼 왜 age는 업데이트 하지 않는 것인지, 이것이 요구사항인지 버그인지 혼란이 생기게 되죠.

현재 상태 뿐 아니라 미래에 대해서도 유지보수성을 고려해야 합니다!

예를 들어 create 를 할 때, 요구사항이 변경되어 name 과 age 뿐만 아니라 주소, 성별 등 다양한 정보를 받아야 한다고 생각해보겠습니다. 하지만 update 는 여전히 이름만 변경해야 합니다.

이때 UserRequest 로 DTO가 통일되어 있다면 UserRequest에는 다양한 필드가 추가될겁니다. 또한 그러한 필드들에 대해 검증도 해야겠죠. 예를 들어 주소가 비어 있다면 에러(Exception)를 내보내야 할거에요.

그런데 update 를 할 때도 이런 DTO를 사용한다면, 로직에 분기가 들어가게 됩니다. create 를 할 때 사용된 DTO는 필드값 검증을 하고, update 를 할 때 사용한 DTO 는 필드값 검증을 하지 않는 방식으로 말이죠.

또한, 처음에는 비슷해 보였던 create / update DTO 필드가 점점 달라지며 극단적으로는 겹치는 필드가 하나도 없게 바뀔 수도 있습니다.

따라서 현재 시점으로보나, 미래 시점으로 보나 처음부터 DTO를 분리해 두는 것이 유지보수성이 좋기 때문에 보통은 API 별로 DTO를 분리해두는 편입니다. 🙂 추가로, 응답 DTO의 경우는 함께 사용하는 경우가 간혹 있습니다만, 설사 필드가 완전히 겹치더라도 최종 DTO를 분리해두면 변경되는 요구사항에 대해 조금 더 유연하게 대응할 수 있습니다.

답변이 도움이 되었으면 좋겠습니다. 감사합니다! 🙏

그 부분이 또 어려운 부분이긴 합니다! 🤔

제가 "응답 DTO의 경우는 함께 사용하는 경우가 간혹 있습니다만"라고 단서를 단 이유도, 요청 DTO 보다는 필드가 중첩되고, 요구사항이 함께 변화할 가능성이 높기 때문입니다.

결국 정답은 없고, 그때 그때 상황에 따라 다른 Trade-Off로 봐주시면 좋을 것 같아요!

지금 클래스를 분리해 개발 시간이 약간 (몇 분 정도..) 증가하지만 혹시 모를 추후 변경사항에 편할 것인가
굳이 클래스를 분리하지 않고 나중에 변경사항이 달라지면 그때 분리할 것인가

개발을 하게 되면 단순히 코드를 작성하는게 아니라 이런 고민을 함께 하게 되는 것 같네요! 😊

인프런 커뮤니티 질문&답변