타입스크립트를 도입하며,

 처음에 개발을 시작했을때는 자바스크립트만 배웠지만, 운이 좋게도(?) 첫 회사를 입사하고 부터는 줄곧 타입스크립트만 사용하고 있다. 물론 지금 회사는 기존 모든 프로젝트는 자바스크립트를 사용해서 타입스크립트로 전환중이긴 하다. 그래서 타입스크립트에 대한 간단한 내용과 타입스크립트를 중간에 도입하면서 겪은 내용에 대해 기록해 본다. 

 

왜 타입스크립트를 써야하는가?

 이유는 자바스크립트가 동적 프로그래밍 언어이기 때문이다. 동적 프로그래밍 언어는 런타임시 변수의 타입이 결정되기 때문에, 런타임 중 변수의 타입이 결정되면서 생기는 버그와 에러를 자바스크립트를 실행해 보지 않으면 알 수가 없다. 그래서 나온게 대안으로 나온게 flow와 typescript이다.

‌

Flow vs Typescript

 flow는 페이스북에서 만들었고 typescript는 마이크로소프트에서 만들어졌다. 위 두개의 자바스크립트 extension 모두 정적 타입핑을 제공하지만, 타입스크립트의 경우 react, vue, angular, express 같은 주요 프레임워크를 모두 지원하며, flow의 경우 react만 지원한다. 또한 npm에 있는 수많은 라이브러리들이 타입스크립트를 지원하며 타입스크립트를 통해 짜여진 라이브러리도 많기 때문에 타입스크립트의 압승이 아닐까 생각한다.

‌

타입스크립트 장점

타입스크립트의 장점은 타입스크립트의 디자인 목표를 보면 잘 알 수 있다. 몇 가지 목표만 간단히 요약해 본다.

1. 오류 가능성이 있는 코드를 정적으로 식별한다.
2. 더 큰 코드 조각에 따른 구조화된 메커니즘을 제공한다.
3. 런타임엔 자바스크립트로 내보내지기 때문에 런타임에 오버헤드를 주지 않는다.
4. 현재 및 미리의 ECMAScript의 제안과 일치한다.
5. 여러 플랫폼을 지원한다.

‌

우리가 실제 운영환경에서 사용하고 있는 프로젝트는 자바스크립트 프로젝트인데 신규 프로젝트에서만 해야하는가?

결론부터 말하자면 아니다. 프로젝트 중간에서도 도입할 수 있고 나 역시도 기존 자바스크립트 프로젝트에서 타입스크립트 코드를 작성하고 있다.

 

어떻게 중간에서 도입하지? (feat. eject 하지 말기)

 CRA로 만들어진 react앱을 개발중에 있다면 나의 경험을 살려 이야기 한다면, gsoft에서 개발한 craco 라이브러리를 사용하자. 사용법도 간단하고 기존 CRA 프로젝트를 eject하지 않고도 설정을 변경할 수 있게 해준다.

 craco를 통해 기존 프로젝트에 설정을 약간만 수정하고 타입스크립트를 도입한다면 프로젝트 중간부터도 아무런 무리없이 타입스크립트를 도입할 수 있다.

‌

중간에 타입스크립트로 전환시 단점

사실 항상 처음부터 타입스크립트로 세팅하거나 세팅된 프로젝트만 보다가 직접 변경해 보니 생각치 못한 단점이 조금 있었다. 사실 설정이나 타입스크립트를 작성하는 부분에 있어서의 단점은 처음부터 도입하는 거랑 큰 차이가 없다. 단점은 아래과 같다.

1. 구성원 "모두" 타입스크립트를 사용하거나 정적 타이핑에 익숙해야 한다. 우리의 경우 일부 팀원이 타입스크립트에 익숙했기 때문에 타입스크립트의 장점을 이야기하며 도입하는데에는 어려움이 없었다. 하지만 익숙하지 않는 구성원이 이 상황에서 익숙하지 않다는 이유로 반대하는 것이 참 힘들기도 하고 본인의 시간을 추가로 할애하며 타입스크립트 공부를 하며 짜야하는 것도 단기간에 버거울 수도 있다. 이러면 JS에 익숙한 사람은 계속 자바스크립트로 코드를 작성하고, TS에 익숙한 사람은 TS로 작성하다 보니 참 애매한 프로젝트가 되버린다. 구성원 간에 많은 대화와 컨벤션을 정함으로서 해결해 보자.
2. 기존에 정적 타이핑이 되어있지 않던 react 컴포넌트들의 타입이 모두 any로 변경되고 필수값으로 프로퍼티를 받게 되어, 기존 JS로 개발된 컴포넌트 사용시 해당 컴포넌트를 타입스크립트로 변경해야 하는 약간의 귀찮음이 생긴다. (이때 팁은 테스트 코드를 작성했다면 동작성에 대해 고민할 필요가 없겠지만, 혹시 테스트 코드 조차 없다면, 스냅샷 테스트라도 진행해서 컴포넌트가 변경되었는지 전/후를 확인하면, 타입스크립트로 전환하면서 혹시 모를 변경을 인지할 수 있다.)
3. tsconfig에서 작성하는 일부 필요한 옵션을 트레이드 오프로 조금 꺼야한다. 타입 안정성을 해칠 수는 있겠지만, 중간에 도입하는 만큼 기존 코드의 수정을 최소화 해야하기 때문에 어쩔 수 없는 선택이다. 다만 이 경우 구성원 간의 합의를 거치고 컨벤션을 잘 정의하여, 작성자가 옳바른 타입스크립트 코드를 작성하고 코드 리뷰를 통해 한번 더 확인하면서 해결 할 수 있다.

‌

구성원 간에 합의가 되어 도입은 했는데 사실 어떤 규칙을 가지고 작성해야 되는지 모르겠다면...

사실 정답은 없다. 하지만 우리는 프로젝트를 만들면서 최소한의 일관된 코딩 규칙을 원하긴 한다. 이때 제시하는 방법은 아래와 같다.

1. 타입스크립트에 능숙한 시니어 개발자가 있다면 최소한의 컨벤션을 eslint와 tsconfig, 문서를 통해 정하고 구성원에게 전파한다..
2. 사용해봤지만 능숙한 사람은 없다면, 많이 사용하는 eslint, tsconfig 규칙을 적용하면서 주기적으로 이야기하며 필요한 규칙을 추가하거나 생산성을 오히려 떨어뜨리는 규칙을 제거하는 방향으로 한다.
3. 마지막 방법으로는 타입스크립트 작성자에 대한 규칙은 아니지만, 타입스크립트 기여자에 대한 규칙은 있다. 이 규칙을 따르는 방법도 있다.

 

[본 글을 깃북으로 보기]