세미나는 별도의 스크립트 없이 진행하였습니다. 세미나 때 발표했던 내용을 재현하여 글로 작성해보았습니다.
세 가지 프로젝트에서 저는 TypeScript라는 언어를 미숙하게나마 다뤄본 경험이 있습니다.
오히려 부족한 경험의 시선으로 발견한 여러가지 토론점들이 있는데, 이것을 많은 사람들에게 공유함으로써 이 주제들로 토론해보면 좋을 것 같다는 생각에 발표를 준비하게 되었습니다.
이 세미나 후에는 앞으로 수행할 프로젝트에서 TypeScript로 더 좋은 코드, 이유 있는 코드를 짜기 위해 즐거운 토론을 이어가시길 바랍니다!
그럼 발표 시작하겠습니다.
TypeScript를 프로젝트에 도입하는 그 시작점에서 여러분들은 대부분 어떤 고민을 하시나요?
저는 **"Why"**에 대한 고민에서부터 늘 시작하는 것 같습니다.
TypeScript를 도입한다면 왜 우리 프로젝트에 도입해야 하는지? 나는 아직 JavaScript도 미숙한데 TypeScript를 도입하면 오히려 프로젝트가 어려워지고 복잡해지는 것 아닐까? 그런데 많은 사람들이 TypeScript를 필수적으로 사용한다고 하는데 왜 그런걸까? 우리 프로젝트도 그래야 하나?
이런 여러가지 고민들로 TypeScript라는 언어를 바라보게 됩니다.
그렇다면 이 고민은 JavaScript와 TypeScript를 비교하는 것에서부터 시작해야하지 않을까요?
TypeScript가 탄생했다는 것은 JavaScript에 어떤 단점이 있고 그 단점을 보완하기 위해 나왔을 가능성이 높으니까요.
그럼 JavaScript는 어떤 특징들을 갖고 있는지 먼저 살펴보도록 합시다.
JavaScript에는 아주 많은 특징들이 있지만, 딱 세가지의 대표적인 특징들을 가져와보았습니다.
JavaScript는 브라우저에서 유일하게 동작하는 언어이며, 인터프리터 언어이고, 동적 타입 언어입니다.
그럼 여기서 한 뎁스 더 들어가볼게요.
인터프리터 언어는 컴파일 과정을 가지지 않습니다. 만일 에러가 발생하면 컴파일 타임이 없기 때문에 런타임에 발생하게 됩니다.
그리고 동적 타입 언어라는 것은 타입을 약하게 다룬다는 것이고, 그만큼 타입에 있어서 유연성을 가진 언어라는 것을 알 수 있습니다.
그런데 유연성을 가진다는 것은 "실수할 여지를 포함한다"라고도 볼 수 있습니다. 코드는 개발자, 즉 사람이 짜는 것이기 때문에 유연성을 가지게 되면 실수할 가능성이 있죠.
그리고 그 "실수" 때문에 에러를 발생시킨다면 컴파일 타임이 없기 때문에 고스란히 런타임 에러로 발생하게 됩니다.
이것이 JavaScript의 단점이죠. 하지만 JavaScript는 브라우저에서 유일하게 동작하는 언어이기 때문에 다른 언어로 이를 보완할 수 없습니다.
그럼 TypeScript의 특징에 대해 살펴봅시다.
TypeScript는 타입스크립트 컴파일러 또는 바벨을 통해 JavaScript 코드로 변환됩니다. 그리고 JavaScript와 달리 컴파일 언어이며, 정적 타입 언어입니다.
정적 타입 언어는 타입을 강하게 다룹니다. 그래서 강제성을 띄고 있다고 볼 수 있습니다. 또한 컴파일 언어이기 때문에 컴파일 타임에 장애를 방지할 수 있습니다.
즉 JavaScript가 가진 단점을 보완하면서, 컴파일 러를 통해 JavaScript로 변환해 브라우저에서 동작하도록 만들어진 것이죠.
이러한 특징들을 비교해봤을 때 저는 이런 결론을 내려보았습니다.
TypeScript는 런타임 에러를 방지하여 위험성을 줄여주고, 데이터 타입을 지정해줌으로써 타입을 공유할 수 있다는 장점이 있습니다. 그래서 협업 프로젝트나 규모가 있는 프로젝트에 알맞을거라 생각합니다.
하지만 TypeScript는 컴파일 과정이 있기에 복잡한 구조를 가지게 되고, 어느 정도 러닝 커브를 감당해야 하기 때문에 1인 프로젝트나 간단한 기능을 구현할 때에는 무겁지 않나라는 생각도 듭니다.
상황에 따라 적절한 언어를 선택해 사용하면 되지 않을까요? 🤗
네. 그럼 다음 주제로 넘어가보겠습니다.
Interface vs Type alias인데, 이 주제는 TypeScript를 접했을 때 가장 대표적으로 토론이 이루어지는 주제이기도 합니다.
토론이 많이 이루어진다는 것은 이 두가지가 많이 닮아있다는 뜻 아닐까요? 그래서 공통점을 먼저 찾아보았습니다.
Interface와 Type alias의 공통점은 둘 다 "타입 선언"의 역할을 한다는 것입니다.
예시 코드를 가져와봤는데, Person 이라는 타입을 interface 와 type 으로 선언했을 때 그 차이점을 알기 힘들만큼 둘은 비슷합니다. 그리고 결정적으로 같은 역할을 하고 있네요.
하지만 TypeScript에서 이 둘이 나뉘어져 있다는 것은 차이점을 가지고 있다는 것 아닐까요? 이번엔 차이점을 한 번 살펴봅시다.
Interface는 Type alias와 달리 상속받을 수 있습니다.
예시 코드를 살펴보면 Person 타입의 속성을 가지는 Student 타입을 선언하고 싶을 때, interface 는 상속을 받아 처리할 수 있음을 알 수 있습니다.
또 Interface는 확장이 가능합니다.
Person 이라는 같은 이름으로 interface 를 정의했을 때, 아래에 정의한 Person 은 위에서 정의한 Person 의 속성을 포함합니다. 이렇게 같은 이름으로 interface를 정의하여 확장할 수 있습니다.
반면 Type alias는 interface와 달리 union type이 가능합니다.
예시 코드를 살펴보면 Gender 라는 타입을 female 또는 male 의 두 가지 값을 가지도록 선언하고 있습니다.
Type alias는 union type을 통해 타입의 범위를 제한할 수 있습니다.
그럼 이 둘을 비교해볼까요?
Interface와 Type alias의 특징을 살펴보았을 때 다음과 같은 성격을 가진다는 것을 알 수 있습니다.
Interface는 확장에 열려있고 외부와 소통할 수 있는 성격을 가지고 있습니다.
그리고 Type alias는 타입의 범위를 지정해줄 수 있으며, 외부에 열려있기보다는 내부 데이터를 선언하고 지정해주는 느낌이 강한 것 같습니다.
이에 대해 제가 내린 결론은 이렇습니다.
Interface는 외부와 소통하고 확장을 하는 성격을 가지고 있기 때문에 외부에 공개할 API, 오픈소스, React props 타입을 선언할 때 사용하는 것이 좋지 않을까 생각합니다.
그리고 Type alias는 특정 데이터 타입을 지정하여 타입의 범위를 지정해줄 때, 그리고 React state 타입을 선언할 때 사용하는 것이 좋을 것 같습니다.
이는 물론 제가 생각하고 내린 결론이기 때문에 더 좋은 결론이 존재할 수도 있을 것 같네요!