• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    미해결

DTO request와 response

24.05.28 16:45 작성 조회수 95

1

dto에서 request를 구성할 때에 Create와 Update에 대한 request를 두 개로 나누어 구성하시는 것을 봤습니다.

제가 생각하기에 user 테이블에 접근하여, userService에 사용되기 위한 것이니 UserRequest라는 클래스를 만들어 하나로 통합하여 사용하면 보기 편하고 사용하기 쉬울 것 같습니다.

성능에서 차이가 있다던지 request를 따로 구별해서 사용하신 이유가 있는지 궁금합니다.

답변 1

답변을 작성해보세요.

1

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

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

 

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

현재 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 를 할 때, 요구사항이 변경되어 nameage 뿐만 아니라 주소, 성별 등 다양한 정보를 받아야 한다고 생각해보겠습니다. 하지만 update 는 여전히 이름만 변경해야 합니다.

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

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

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

 

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

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

오쩜오님의 프로필

오쩜오

질문자

2024.05.28

혹시 그렇다면 response 클래스도 추후에 또 다른 곳에서 비슷한 형태의 response가 필요해도 request가 분리되어있는 것 처럼 UserResponse와 다른 새로운 클래스를 추가하는 것이 추후 용이할까요?

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

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

 

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

  • 지금 클래스를 분리해 개발 시간이 약간 (몇 분 정도..) 증가하지만 혹시 모를 추후 변경사항에 편할 것인가

  • 굳이 클래스를 분리하지 않고 나중에 변경사항이 달라지면 그때 분리할 것인가

     

 

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

채널톡 아이콘