윗 분 말씀대로, 두 방식 모두 사용되는 방식입니다. 다만 개인적으로는 시간이 지날수록 유틸리티 타입을 더 자주 사용하게 되는 것 같네요. 그 이유를 말씀 드리자면, 개인적으로 유틸리티 타입을 활

윗 분 말씀대로, 두 방식 모두 사용되는 방식입니다. 다만 개인적으로는 시간이 지날수록 유틸리티 타입을 더 자주 사용하게 되는 것 같네요. 그 이유를 말씀 드리자면, 개인적으로 유틸리티 타입을 활용하는 것을 좋아하기도 하고, 상황 자체가 두 타입 간 의존성을 생성하는 것이 유리한 경우가 많았습니다. 예를 들어, 하나의 엔티티의 타입이 수정되는 경우, 해당 엔티티에 대한 DTO나 프론트엔드에 출력하기 위해 포맷된 타입 역시 엔티티의 변화를 반영해야 하는 경우가 일반적이었습니다. 또한, 타입스크립트가 기본적으로 제공하는 유틸리티 타입, 또한 필요에 따라 커스텀으로 유틸리티 타입을 생성하여 유틸리티 타입을 폭넓게 적재적소에 사용하면 보다 더 선언적으로 타입스크립트를 작성할 수도 있고, 두 타입 간 의존성을 생성함으로써 발생하는 장점을 높이고 단점을 낮출 수 있다고 생각합니다. 물론, 과유불급이라는 말이 있죠. 모든 것을 유틸리티 타입으로 해결하려고 하면 오히려 타입스크립트 코드가 너무 복잡해져 가독성이 떨어지거나, 유지보수성이 오히려 하락하는 경우도 생길 수 있는 것 같습니다. 또한 상황에 맞지 않는 유틸리티 타입을 사용하면 역시 예상치 못한 오류가 발생하거나 가독성이 떨어질 수 있다고 생각합니다. 그래도 저는 최대한 다른 타입과 연관된 새로운 타입을 생성할 때에는 유틸리티 타입을 적극적으로 활용해 보려고 하고 있습니다. 이 과정에서 타입스크립트에 대해 더 공부하게 되기도 하고, 이를 통해 언제 어떻게 유틸리티 타입을 사용해야 할 지, 혹은 말아야 할 지 결정하기가 더 쉬워지는 것 같습니다. 그리고 무엇보다 정말 잘 만든 유틸리티 타입은 그 효과가 정~말 너무 좋습니다. 도움이 될 지는 모르겠지만, 제가 유틸리티 타입을 사용하여 의존관계를 만들어내는데에 주로 사용되는 패턴에 대한 간단한 예시를 살포시 얹어 놓고 가겠습니다. https://bit.ly/new-type-associated-with-an-entity