타입스크립트의 단점

지난번 글에서 너무 타입스크립트를 사용하면서 얻게 되는 장점만 말한 것 같아서 이번 글에서는 타입스크립트를 사용하면서 맞게 되는 단점들을 말해보도록 하겠다.

타입스크립트의 단점은 명확하다. 타입스크립트와 자바스크립트를 섞어서 쓸 수 있다는 점이다.

타입스크립트로 컴파일한 코드는 자바스크립트가 되기 때문에 타입스크립트로 작성한 모듈을 자바스크립트에서 불러올 수 있다. 하지만 이렇게 사용한다면, 지난번 글에서 말한 타입스크립트를 사용하는 장점 중 하나인 타입 체크를 위한 verbose 한 코드를 작성하지 않아도 되는 장점이 사라진다. 자바스크립트에서 사용될 것을 가정하고 코드를 작성할 경우는 여전히 verbose 한 타입 체크 코드를 작성해야 한다. 이것은 내가 자바스크립트 코드를 타입스크립트를 포팅하면서 딱히 좋은 점을 느끼지 못했던 이유이기도 하다. 하지만 이는 자바스크립트를 사용했다면 언제나 발생했을 문제가 타입스크립트를 사용할 때 다시 발생하는 것뿐이다. 자바스크립트를 사용해야 하는 환경에서 타입스크립트를 사용하지 않을 이유는 되지 않는다.

이번에는 반대로 타입스크립트를 사용하면서 자바스크립트로 작성된 모듈을 불러오는 경우를 보자. 타입스크립트에서는 자바스크립트의 모듈을 그대로 가져다 쓸 수 있다. 덕분에 타입스크립트 생태계는 크게 노력하지 않고 자바스크립트의 생태계를 흡수할 수 있었다. 하지만 이것은 동시에 단점이 되기도 한다. 자바스크립트로 작성된 모듈은 타입 추론을 할 수 없어서 모든 API가 any 타입이 되고, 결국 이 부분이 unsafe 한 부분이 되기 때문이다.

이런 문제를 해결할 수 있도록 타입스크립트는 모듈의 타입만 분리해서 선언하는 선언 파일을 사용할 수 있게 해놓았다. 선언 파일과 함께 사용하면 자바스크립트로 작성된 모듈을 사용할 때도 잘못된 타입을 사용하면 타입 에러를 내준다. 물론 선언 파일을 만드는 것도 비용이다. 하지만 이는 큰 문제가 되지 않는다. 유명한 라이브러리에 대해서는 이미 DefinitelyTyped에 많은 선언 파일이 만들어져 있다. DefinitelyTyped에 만들어지지 않은 라이브러리도 있고, 버전이 맞지 않는 경우도 있다. 이에 대해서는 직접 만들거나 수정해서 사용해야 한다. 하지만 이는 큰 문제가 되지 않는다. 어차피 외부 모듈을 사용하려면 어떤 함수가 어떤 인자를 통해서 실행되고 어떤 값을 리턴하는지 파악을 해야 한다. 그렇지 않으면 (특히 자바스크립트같이 동적 타입의 언어들에서는) 무언가 문제가 발생하기 십상이다. 따라서 그저 파악한 API의 시그니쳐를 코드로 옮겨 적으면 된다.

다시 한 번 강조하지만, 타입스크립트의 단점은 다른 정적 타입 언어들보다 불안하다는 것 뿐이다. 자바스크립트보다 못하는 점은 없다. 타입어노테이션이나 선언 파일이라는 약간의 비용을 들여서 타입 세이프한 코드를 만든다는 큰 이득이 있어서, 자바스크립트를 사용해야만 하는 환경에서 타입스크립트를 사용하지 않을 이유는 전혀 없다. 그래서 나는 앞으로도 자바스크립트를 사용할 것이다. 아니 타입스크립트 대신 Google의 AtScript나 Facebook의 flow를 사용할 수는 있겠지만, 정적인 타입 분석이 붙지 않은 상태의 자바스크립트를 이용해 코딩할 생각은 없다.