유틸리티 타입 사용하기 vs 명시적으로 작성하기

두 가지 방식 모두 현업에서 흔하게 볼 수 있는 타입 선언 패턴입니다. 말씀하신 것처럼 두 가지 방법 중 무엇을 사용하든 동일한 형태의 타입을 얻게 되지만 유지 보수 측면에서 상당한 차이가 있기 때문에 이를 이해하고 적합한 방식을 선택하는 것이 중요할 것 같습니다. 첫 번째 방식에서는 `ChessPieceOption` 인터페이스가 `ChessPiece` 인터페이스에 의존하게 됩니다. 다시 말해서, `ChessPiece` 인터페이스에 변경을 가하면 `ChessPieceOption` 인터페이스가 영향을 받을 수 있습니다. 예를 들어, `ChessPiece` 인터페이스에 다른 속성을 추가하면, `ChessPieceOption` 인터페이스에도 자동으로 추가되겠지요? 마찬가지로 `ChessPiece` 인터페이스로 부터 속성을 제거하면, `ChessPieceOption` 인터페이스에도 자동으로 제거될 것입니다. 반면에 두 번째 방식에서는 `ChessPieceOption` 인터페이스는 `ChessPiece` 인터페이스에 독립적입니다. 즉, `ChessPiece` 인터페이스에 어떤 변경을 가하든 `ChessPieceOption` 인터페이스는 영향을 받지 않죠. 예를 들어, `ChessPiece` 인터페이스의 `type` 속성의 이름을 `kind`로 바꾸시더라도, `ChessPieceOption` 인터페이스도 맞춰서 직접 바꿔주시지 않는 한 여전히 `type`이라는 속성이 남아 있을 것입니다. > `ChessPiece` 인터페이스가 변할 때, `ChessPieceOption` 인터페이스도 따라 변하는 게 나중에 코드를 수정할 때 편하게 해줄까? 아니면 힘들게 할까? 위 질문을 스스로에게 해보시면 어떤 방식이 더 합리적인지 판단하시는데 도움이 될 것 같습니다.

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