내가 Type Script에 관한 글을 쓴 이유
최근 프로젝트에서 Type Script를 사용하여 프로젝트를 했고 주변인과 프로젝트 얘기를 하다 내 프로젝트를 소개를 할 상황이 생겨버렸다. 그리고 한 질문이 들어왔다.
왜 이 프로젝트에서 TypeScript를 썼어?
그 질문에 정석적인 대답인 정적인 타입 선언으로 예상치 못한 오류를 사전에 방지할 수 있다는 점과 interface를 통해 변수들의 타입선언을 바인딩 시켜 사용했다는 점을 말하였다.
그러나 한 편으로는 과연 우리의 프로젝트에서 타입 스크립트를 사용해야 될 만한 이유가 뭘까? 라는 근본적인 의문이 생기게 되었다. 우리 프로젝트는 그다지 규모가 큰 프로젝트라고 생각되지 않는다.
그렇기에 과연 불안정한 타입 선언으로 인한 에러가 발생하게 될까? 라는 의문을 가지게 되었고 이에 대해 글을 써서 남기려고 하였다.
Type Script가 뭘까?
기존 java script 같은 경우 변수를 선언할 때 불변하는 변수에는 const, 가변성을 띠는 변수에는 let을 붙이며 타입과 같은 경우는 자바 스크립트 엔진의 JIT 컴파일 과정에서 타입 추론이 이루어져 그에 맞는 타입을 추론을 하여 가지게 된다.
하지만 typescript 같은 경우는 코드에 타입 선언을 엄격하게 하여 코드 자체의 안정성과 유지보수성을 개선할 수 있다는 장점을 가지며 구글이나 페이스북과 같은 기업이 타입을 사용함으로써 코드의 퀄리티를 높일 수 있다는 것이 입증되며 현재까지도 프론트 엔드 분야에서 많이 사용을 하고 있다.
Type Script의 type 선언
export interface SpaceListData {
status?: string;
languageIds?: string;
joinable?: boolean;
keyword?: string;
lastId?: number;
}프로젝트 개발 중 작성했던 type Scirpt type 선언 코드
변수의 타입 선언같은 경우 :(콜론)을 이용하여 변수명 뒤에 변수에 들어갈 type을 지정할 수 있다. 물론 type 선언을 하고나서는 그 변수는 정적인 타입을 가지기에 다른 타입의 데이터가 들어갈 수 없기에 TS2322 오류가 발생하게 된다.
개발 과정에서 가장 많이 마주쳤던 오류였다. 변수에 어떤 데이터가 들어갈지 초반 설계과정에서 정하였지만 개발 과정에서 문자열 데이터가 들어가도록 설계되었던 변수가 문자열 요소의 배열 형태로 변경되는 등의 여러 변경 과정에서 TS2322라는 오류를 많이 마주치게 되었다.
그렇다면 Type Script는 매우 규격이 엄격하고 딱딱한 언어였을까? 그건 아니라고 생각한다. extends를 이용한 확장으로 변수 자체의 딱딱함을 변수 집합 인터페이스에 대해서는 유연하게 기존 인터페이스에서 확장할 수 있다.
export interface StudyFormData extends Record<string, string | number[]> {
name: string;
password: string;
totalUserCount: string;
languages: number[];
workbooks: number[];
}기존 인터페이스에서 확장을 이용하여 새로운 인터페이스를 만든 코드
또한 작성된 코드에서는 Record를 사용하였는데 이는 코드의 Type을 다른 Tpye의 속성에 매핑하는데 사용되는 유틸리티 타입이다. 이러한 유틸리티 타입도 지원하기에 Type Script가 조금의 유연성도 갖추고 있다고 생각한다. docs를 보면 특정 인터페이스에서 특정 타입을 제거하는 Omit 등의 유틸 타입이 많은 것을 확인할 수 있다.
typescript docs 레퍼런스
Type Script의 발전
최근 흥미로운 스크랩을 봤었다. type script의 엔진으로 기존 js가 아닌 go를 사용하여 빌드 시간을 10배 빠른 속도로 빌드 할 수 있으며 메모리 사용량을 줄인 것이다.
출처 : https://devblogs.microsoft.com/typescript/typescript-native-port/
출처에 나와 있는 표를 보면 알 수 있듯이 성능이 매우 개선된 게 지표로 나타내져 있다. typescript를 사용해야 하는 이유가 하나 더 늘어난 것 같다고 생각한다. 기존 타입의 정확성으로 인한 예기치 못한 오류를 방지한다는 점은 소규모 프로젝트에서는 큰 설득력있는 요소로 작용하지 못한다고 생각하였는데 성능 개선으로 인해 typescript를 더욱 잘 활용해야 겠다고 생각한다. SPA에서는 하나의 페이지로 어플리케이션을 나타내기에 번들 크기 감소로 인한 영향도 클 것이라고 생각한다.
