난이도 ⭐️
작성 날짜 2025.01.08
고민 내용
팀 프로젝트의 과제는 외부 API를 이용하여 UI와 접목시켜 프로그램을 만드는 것이었다.
API처리와 받아온 데이터를 View에 넘기는 파트를 맡아 자연스럽게 MVC 패턴을 적용시키고 있었는데,
팀원인 고든이 다음과 같은 의문을 제기하였다.
🤔
왜 UI 별로 DTO를 제작해? 이렇게 되면 “DTO Hell”에 빠질 수 있어!
찾아보기
- DTO를 사용하는 이유
우선은 우리가 DTO를 사용하는 이유는 다음과 같다.
- 결합도 감소: DTO를 사용하면 시스템 간 결합도를 낮출 수 있다.
- 보안 및 캡슐화: 내부 도메인 모델을 노출하지 않아 보안과 데이터 무결성을 유지한다.
- 유연성 향상: 데이터 표현 방식을 변경할 수 있어 다양한 클라이언트 요구에 대응 가능하다.
- 고든의 이야기
DTO는 직렬화에 관련한 데이터, 예를 들어 API 통신의 결과를 받기 위한 클래스라는 것이다.
그는 현재 다니고 있는 회사를 예시로 들며, 대규모 프로젝트에서는 End point를 이용하는 것처럼 외부 API와의 통신이 많기 때문에 이러한 경우 많이 쓰이지만, 우리는 소규모 프로그램이기 때문에 오히려 혼란을 만든다는 것이다.
만약 API에서 받아오는 데이터의 형식이 달라지는 경우, 해당 데이터와 관련한 모든 DTO를 수정해야 하며 관리가 힘들어질 것이다.
또한, View 자신이 필요한 데이터를 가져오는 것은 View의 책임이고, 이것을 Controller와 같은 레이어에서 모두 처리해서 전달하는 것은 이후 변화가 생길 때 너무 많은 수정을 야기할 것이다.
- DTO Trade-off에 대한 읽을거리
찾아보니 비슷한 이야기를 하는 게시글이 있었다.
https://medium.com/@gsferreira/dtos-the-good-the-bad-and-the-tradeoff-3bfbb3823243
결론
모든 파트에서 DTO를 작성하는 것이 각 레이어 별 결합은 줄여주지만, 복잡도가 증가한다는 단점도 있다.
생각해보니 나도 다른 프로젝트에서 DTO가 무한으로 늘어나서 골치 아팠던 경험이 있었다.
더군다나 이 팀프로젝트는 규모도 작은데 DTO를 너무 적극적으로 활용하면 커뮤니케이션 혼란을 더 야기하는 것은 아닐까?
DTO 찬성파였던 나는 1시간 정도 토론을 한 후 고든의 말에도 일리가 있음을 깨닫게 되었다.
물론 DTO의 장점은 확실하게 존재하지만..! 당연하게만 생각했던 DTO에 대한 새로운 관점을 갖게 되었다.
나는 매일 작성하는 MVC 패턴에 매몰되어 있는 것은 아닐까?
결론 : 모든 것은 상황에 맞게
