레이블이 TypeScript인 게시물을 표시합니다. 모든 게시물 표시
레이블이 TypeScript인 게시물을 표시합니다. 모든 게시물 표시

2018-05-20

2018년 20번째 주

이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
 보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.

Polkadot: Vision for a Heterogeneous Multi-chain Framework

Cosmos - A Network of Distributed Ledgers

블록체인이 쏟아져 나오면서 다른 블록체인과 통신을 어떻게 할 수 없을까에 대해 고민하는 사람들이 나왔다.
예를 들어 지금은 Alice의 비트코인과 Bob의 이더리움을 교환하기 위해서는 양자가 신용하는 Ted가 필요하다. Alice는 비트코인을 Bob은 이더리움을 Ted에게 보내고, 양쪽에게 받은 트랜잭션을 확인한 Ted는 Alice와 Bob에게 이더리움과 비트코인을 보내주는 식이다. 지금은 거래소가 이 역할을 해주고 있다. 하지만 trustless를 가정하고 설계된 블록체인에서 거래소는 가장 약한 고리가 된다. 그래서 이 거래소에 해당하는 역할을 블록체인으로 구성하자는 제안이 나왔고, PolkadotCosmos가 대표적이다.

How I targeted the Reddit CEO with Facebook ads to get an interview at Reddit

어떤 사람이 공개된 페이스북 프로필을 이용해서 레딧 CEO를 타겟으로 광고를 했다고 한다. 결국, 10$만에 레딧 CEO에게 광고하는 데 성공했다고 한다. 마케터들은 페이스북이 이렇게 유용하다고 생각할 것이다. 근데 사용자 입장에서 반대로 내 신원이 이 정도로 추적된다는 것인데 이런 것을 감수하고 쓸 정도로 페이스북이 매력적인 서비스인지 이해가 안 된다. 사실 사람들이 개인 정보 보호에 그다지 관심 없는 게 아닌가 싶다.

To Type or Not to Type:Quantifying Detectable Bugs in JavaScript

JavaScriptTypeScriptflow를 사용하여 정적분석을 하는 것 만으로 15%의 버그를 예방할 수 있다는 연구다.

How a Rust upgrade more than tripled the speed of my code

Parity 팀에서 지난 5월 10일에 발표한 Rust 1.26의 128 bit 정수 타입을 이용해서 실제 성능 향상을 확인했다. 이는 이더리움이 256 bit 정수와 512 bit 정수를 많이 사용하기 때문이고, 이더리움 외의 소프트웨어에서는 128 bit 정수를 쓸 일이 없으니 크게 영향 없을 수도 있다.

Sia: Simple Decentralized Storage

Sia는 블록체인을 이용하여 분산 서비스를 구축하자는 프로젝트이다. 분산 스토리지라고 해도 데이터 전체를 블록체인에 올리는 것은 비현실적이기 때문에 블록체인에는 어떤 데이터를 어떤 노드가 가졌는지에 대한 증명과 그에 대한 보상만 블록체인에 기록한다. 결국, 실제 데이터를 원하는 클라이언트에게 서비스하지 않아도 데이터를 가지고 있다는 증명만 하면 보상을 받는다. 이 문제를 oracle problem이라고 하는데 이 문제를 어떻게 풀었는지 궁금해서 찾아봤는데 아직 못 찾았다.

2016-01-18

Flow vs TypeScript - 왜 나는 아직 타입스크립트를 쓰는가

 나는 개인적으로 동적 타입 언어보다 정적 타입 언어를 선호한다. 아니 동적 타입 언어를 싫어한다. 정확히 말하면 동적 타입 언어이기에 생기는 실수에 의한 버그들과 그로 인해 사고에 걸리는 부하를 싫어한다. 그래서 웹 개발을 몇 년을 했지만 여전히 동적 타입 언어인 자바스크립트로 코딩하는 것은 싫어한다. 그 때문에 어지간히 간단한 일이 아니라면, 자바스크립트를 사용할 때 반드시 다른 툴을 붙여 정적분석을 한다.
 자바스크립트의 정적 분석을 위해 사용되는 도구는 크게 2가지로 나뉜다. 마이크로소프트에서 만든 타입스크립트와 페이스북에서 만든 플로우다. 한때는 구글이 타입스크립트를 기반으로 만든 AtScript라는 것도 있었지만, 이는 다시 TypeScript로 합쳐지면서 사라지게 되었다.

 타입스크립트와 플로우는 둘 다 자바스크립트를 정적 타입 검사가 가능하도록 만들어주었다. 하지만 접근하는 방향은 완전 다른 방향으로 접근하였다.
 우선 타입스크립트는 2012년에 첫 버전이 나왔다. 타입스크립트의 목표는 자바스크립트로 변환되는 더 쓰기 편하고 안전한 언어를 만드는 것이었다. 어디까지나 자바스크립트로 변환되는 언어를 만드는 것이었기에 문법적 기반을 자바스크립트에 두었다. 다시 말해서 타입스크립트의 문법은 자바스크립트 문법의 슈퍼 셋이다. 자바스크립트의 문법을 기반으로 하여 그 위에 추가적인 기능을 더했다. 추가된 기능에는 classenum처럼 사용성을 올리기 위한 기능도 있고, private이나 타입 어노테이션 처럼 안전한 코드를 만들기 위해 추가된 기능도 있다.
 반면에 페이스북의 플로우는 새로운 언어를 정의하지 않는다. 플로우는 ECMAScript 6(a.k.a. ES6)의 타입 검증 도구일 뿐이다. 이미 타입스크립트의 많은 기능이 ES6에 표준으로 들어왔기 때문에 새로운 언어를 만들 필요가 없었다. 플로우는 새로운 언어를 정의하지 않기 때문에 이미 자바스크립트로 작성된 프로그램을 바로 분석할 수 있다. 타입이 모호한 경우에는 어노테이션을 추가하여 타입을 선언할 수도 있다. 이런 경우 바벨 등을 이용해서 어노테이션을 없애야 올바른 자바스크립트 코드가 되는 불편함이 있었지만, 0.4.0 이후부터는 어노테이션을 주석으로 처리할 수도 있다.

 2016년인 지금은 타입스크립트의 기능 대부분이 ES6에 추가되었다. 오히려 지금은 타입스크립트가 ES6나 ES7의 기능을 타입스크립트로 가지고 오고 있다. 게다가 ES6를 ES5로 변환시켜주는 바벨이 널리 사용되고 있고, 플로우가 ES6의 중요한 기능들은 대부분 처리할 수 있다.1) 따라서 더는 ES6 + 플로우를 사용하는 것에 비해 타입스크립트를 사용해서 얻는 장점은 없다.
 게다가 플로우가 타입 추론을 더 잘해준다. 물론 타입스크립트도 타입 추론을 한다. 하지만 함수형 언어들이 많이 사용하는 힌들리-밀러 타입 시스템처럼 추론이 강력하지 않다. 변수를 선언하는 시점에서 타입을 추론할 수 있어야 한다. 추론할 수 없는 변수는 any 타입으로 선언된다.
 반면에 플로우는 그 값이 사용되는 부분의 타입까지 고려하여 타입을 추론해준다. 그를 보여주는 좋은 예가 아래의 코드이다.
 위와 같이 함수를 선언한 경우, 플로우에서는 코드를 사용하는 부분에서 타입 에러를 검사한다. 따라서 length 함수의 인자로 numberboolean을 넣으면, numberboolean이 x가 되기 적절한지, 다시 말해 length 프로퍼티를 가지는지를 확인하기 때문에 잘못된 타입을 사용했다는 것을 알 수 있다.
 하지만 타입스크립트는 length 함수를 선언하는 순간 이 함수의 타입이 any -> any로 결정되기 때문에 length 프로퍼티가 없는 값을 넘겨도 타입 에러인지 알 수 없다. 이런 경우를 막기 위해 타입스크립트에서는 함수를 선언할 때 타입 어노테이션을 붙이는 것을 추천한다. 즉, 위의 length 함수는 아래와 같이 선언하여 사용하는 것이 좋다.

 지금까지 말한 것만 보면 ES6가 나온 지금은 플로우를 쓰는 것이 더 올바른 방식으로 보인다. 하지만 그럼에도 나는 아직 타입스크립트를 사용한다. 단순히 쓰던 것이 익숙해서가 아니다. 그저 플로우가 아직 미완성이기 때문이다. 플로우가 미완성이라는 것은 단순히 아직 1.0이 나오지 않았다는 것만을 말하지 않는다. 플로우는 사용하는 데 중요한 몇 가지 부분이 아직 미완성이다.
 우선 기본 API에 대한 타입 정의가 완전하지 못하다. 우선 DOM API의 타입 선언이 어떻게 되었는지 보자. 타입스크립트는 13,813줄로 선언되어 있지만 플로우의 경우 1,306줄의 파일로 선언되어 있다. bom.jscssdom.js를 합쳐도 2천 줄밖에 되지 않는다. ES6와 관련된 타입은 플로우는 614줄밖에 정의되지 않지만, 타입스크립트는 5,174줄로 정의되어 있다. node.js API는 타입스크립트의 타겟이 아니라서 DefinitelyTyped에 정의된 선언을 사용해야 해서 공정한 게임은 아니지만, 이 경우에도 플로우보다 타입스크립트가 더 상세하게 타입을 정의하고 있다. 플로우도 해당 이슈를 알고 있고 해결하려고 하지만 아직 해결되지 않았고, 내가 보기에 1.0이 나오기 전에 해결되면 다행일 것으로 보인다.
 게다가 아직 써드파티 라이브러리 지원이 완전하지 않다. 플로우는 타입 어노테이션이 없는 함수도 타입을 추론해준다. 따라서 플로우의 타입어노테이션을 사용하지 않은 라이브러리를 사용해도 플로우가 자동으로 타입 추론을 해준다.
하지만 자바스크립트처럼 오버로딩이 섞여 있는 언어를 분석하여 추론하는 경우 타입 추론은 쉽게 틀린다. 그래서 멀쩡한 라이브러리를 타입 에러라고 검사하기도 하고, 라이브러리를 잘못 사용한 경우를 잡지 못하기도 한다. 이런 경우는 라이브러리의 타입을 선언해놓은 인터페이스 파일을 사용하면 된다. 하지만 아직 플로우의 인터페이스 파일은 만들어진 것을 찾기 힘들어서 대부분의 경우 직접 만들어서 써야 한다. 2012년부터 기록을 쌓아서 이제는 1천 개가 넘는 라이브러리의 타입선언을 보유하고 있는 타입스크립트와는 상대되지 않는다.
 이에 대해서 타입스크립트의 타입선언을 읽을 수 있게 하는 방향으로 진행되고 있지만, 아직 완성되지 않았다.
 마지막 문제는 타입 추론의 완성도에 대한 문제다.
 위의 자바스크립트에서 많이 사용되는 object에 프로퍼티를 추가하는 코드이다. 새로운 프로퍼티를 추가하는 것이기 때문에 문제없어야 할 것 같지만, 플로우는 이를 { bar: number } 타입으로 추론하기 때문에 해당 코드를 타입 에러로 처리한다.
 위의 코드는 정반대의 경우라서 문제가 되는 경우이다. {}는 어떤 값이라도 키로 받을 수 있도록 해석하기 때문에 실제로는 obj.foo가 nullable한 ?number 타입이 되어야 하지만 number 타입으로 받아도 타입 에러라고 검사하지 못한다.

 다음 문제는 더 심각하다. 플로우는 리터럴 한 값 그 자체를 타입으로 사용할 수 있다. 이를 이용해서 쉽게 다른 언어의 enum에 해당하는 타입을 만들거나 tagged union을 만들 수 있다. 이는 자바스크립트의 관습적인 사용법에 맞기 때문에 enum타입을 새로 추가한 타입스크립트에 비해서 올바른 접근이라고 생각한다. 하지만 이에 대한 타입 추론이 완벽하지 않다는 것이 문제다.
 위와 같은 코드를 보면 인자로 올 수 있는 "red", "green", "blue"를 전부 처리하였기 때문에 모든 경우를 처리한 것이다. 하지만 플로우는 모든 경우를 처리하였다고 생각하지 않고, undefined가 반환될 수 있다는 에러를 출력한다.
 더 심각한 문제는 위와 같은 경우다. 위의 코드의 무엇이 잘못되었을까? case 문에서 "green"의 스펠링을 "greeen"으로 잘못 사용하였다. color 타입은 "red", "green", "blue"만 가능하므로 이는 있을 수 없는 경우다. 하지만 플로우는 이것을 타입 에러로 검사해주지 못한다. 심지어 작년 10월에 리포트되었는데 아직 아무런 피드백조차 없다.

 이런 예제들은 하나하나 들자면 끝이 없다. 하나하나는 사소한 사례로 보일 수 있지만, 타입 추론이 핵심인 툴에서 타입 추론을 못 하는 부분이 있다는 것은 플로우에 대한 신뢰도와 사용성을 떨어뜨린다.
 그렇다고 앞으로 계속 타입스크립트만을 사용하겠다는 것은 아니다. 앞에서도 말했듯이 설계 자체만을 놓고 보면 더는 타입스크립트가 ES6 + 플로우에비해 얻는 이득은 없다. 따라서 플로우가 기본적인 도구들을 갖추고, 많이 사용되는 패턴들에 대해 안전하게 타입 추론을 하게 된다면 플로우로 넘어갈 것이다. 일단 지금은 이것들이 1.0 릴리즈에는 해결될 것으로 보고 기다리고 있다.


1) ES6의 let/const를 플로우가 처리할 수 있게된게 2015년 9월의 일이다. 2014년 11월 플로우가 처음 공개된 이후 거의 1년 가까이 플로우는 ES6의 기본적인 기능인 스코프 단위 변수 할당을 하지 못했던 것이다.

2015-08-08

[TypeScript] Type guard - sum type 분리하기

 Type guard는 다른 언어에서 보기 힘든 TypeScript만의 독특한 기능으로, 타입 인트로스펙션을 통해 분기한 블록 안에서 해당 변수의 타입을 한정시켜주는 기능을 말한다.

 TypeScript를 사용하다 보면, 하나의 변수가 2개 이상의 타입일 가능성이 있는 경우가 자주 생긴다. TypeScript의 본질이 JavaScript이고 이는 동적 타입 언어이기 때문일 것이다. 이를 위해서 TypeScritp는 any 타입을 이용하거나, 조금 더 안전한 사용을 위해서 유니언 타입을 이용한다. 하지만 유니언 타입의 값은 그 값이 될 수 있는 모든 타입이 공통으로 가지는 함수와 프로퍼티만 이용할 수 있고, 모든 타입이 들어갈 수 있는 함수에만 사용 사용할 수 있다.
 이런 불편함을 없애기 위해서 나온 기능이 type guard이다.

 위의 코드처럼 여러 개의 타입이 될 수 있는 값을 사용하기 전에 인트로스펙션을 이용해서 타입을 확인하고 값을 사용하는 것은 JavaScript에서 볼 수 있는 흔한 패턴이다. 이렇게 타입을 확인하고 나면, 확인한 블록 안에서 그 값은 해당하는 타입이 되는 것이 type guard이다.

 하지만 아직 모든 인트로스펙션에 대해서 type guard가 적용되는 것은 아니다. 현재 type guard가 적용되는 경우는 인트로스펙션이 조건문에 들어가는 if 블록과 그에 따라오는 else 블록뿐이다.
위의 예제처럼 if 블록이 반드시 return 하여 그다음은 else 블록과 다를 바 없는 경우에는 type guard가 적용되지 않는다.

 게다가 모든 인트로스펙션이 가능한 것도 아니고, instanceof를 사용하는 경우와 typeof의 결과가 'number', 'string', 'boolean'이 되는 경우뿐이다. 그래서 underscore 등을 이용해서 타입 체킹을 하는 경우나 인트로스펙션 부분을 함수로 뺀 경우는 type guard가 동작하지 않는다. 이는 TypeScript 1.6에 계획된 type guard function이 들어오면 해결될 문제지만, 아직은 어쩔 수 없다.

2015-07-05

sfuture - JavaScript에서 concurrent한 프로그램 작성하기

 sfuture는 JavaScript에서 사용할 수 있는 컨커런트한 프로그램을 쉽게 작성할 수 있도록 도와주는 라이브러리다. 이름에서 알 수 있듯이, Scala의 Future를 JavaScript로 포팅한 것으로, 내부적으로 ECMA Script 6 promise를 사용하고 있어서, promise가 구현된 환경(node.js 0.12.0 이상, 대부분의 모던 브라우저)에서는 아무런 디펜던시 없이 바로 사용할 수 있다.

 만들게 된 이유는, 전에 rhino engine을 이용해서 Scala로 작성한 beyond라는 게임 서버 엔진이 있었는데, 여러 가지 문제가 있어서 이것을 node.js로 포팅하게 되면서 필요하게 되었다.
 Rhino를 사용할 때는 Java class를 그대로 재사용할 수 있었기에 인터페이스만 수정하는 수준이면 가능했는데, node.js로 포팅해오면서 그럴 수 없게 되었다. 처음에는 Future를 포팅해올지, async등 기존의 라이브러리들을 이용하도록 할지 고민했다.
 하지만 async를 실제로 사용을 해보니, 이것도 결국 콜백 헬을 없앨 수 있는 건 아니고, 오히려 코드가 길어질수록, 가독성만 떨어뜨리는 느낌이라서 결국 새로 구현하였다.

 구현은 타입스크립트로 되어 있지만, publish 전에 컴파일하여 자바스크립트 파일만 배포한다. 원본 소스를 보고 싶으면, 깃헙 리파지토리를 보길 바란다.

2015-06-26

타입스크립트의 단점

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

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

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

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

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


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

2015-06-22

TypeScript와 함께 한 4개월

 내가 타입스크립트를 처음 쓰게 된 것은 올해 3월이었다. 당시에 알바를 하고 있던 회사에서 작성하던 서버 사이드 자바스크립트 코드의 안정성을 향상하기 위해 타입스크립트로 포팅하는 일을 시작하였고, 당시 그 팀의 구성원은 전원 너무 바빴기 때문에 다른 일을 하던 내가 불려가서 포팅하게 되었다.

 사실 처음에 포팅을 하기로 했을 때는 흥미로운 일이라고 생각하지만, 딱히 의미 있는 일이라고는 생각하지 않았었다. 당시 코드는 이미 뼈대에 해당하는 부분이 대부분 완성되어 있었고, 그 대부분은 이미 타입의 개념이 없이 짜인 코드였었다. 그래서 단순히 타입스크립트로 옮겨도 별 이득이 없을 것이고, 완벽하게 포팅하는데 들어가는 노력에 대비해서 안정성을 확보할 수 있을지에 대해 확신이 없어서였다.

 그래도 돈을 받고 하기로 한 일이었으므로 작업은 시작하였다. 우선 이미 구현되어있는 코드가 너무 많았기 때문에 초반에는 손에 닿는 파일부터 타입스크립트로 변환하며 작업을 하였다. 그 뒤로 한 3개월은 코드를 바꾸는 일만 했다.

 하지만 이때까지는 타입스크립트의 장점을 딱히 느낄 수 없었다. 변환하는 과정에서 몇몇 버그를 잡았지만, 이미 타입이 중요한 부분은 underscore.js를 이용해서 타입체크를 하고 있었기에 타입스크립트가 추가로 해주는 일이 거의 없었다. 변환하는 과정에서 몇몇 버그를 발견하기는 했지만, 충분한 유닛 테스트로 잡을 수 있는 버그들이었기에 딱히 타입스크립트를 사용해야 한다고 느끼지 못했다. 오히려 리팩토링에 너무 많은 시간이 들었기 때문에 비용 대비 효용이라는 측면에서 비효율적이라고 느꼈다. 그러다가 타입스크립트에 대한 인식이 바뀌게 된 것은 다음 프로젝트를 시작하면서부터였다.

 다음 프로젝트를 시작하게 된 것은 지난 5월 말이었으니 거의 한 달 정도 전이다. 하게 된 일은 기존의 스칼라로 작성되었던 beyond 프레임워크node.js에서 돌도록 포팅한 beyond.ts를 만드는 것이었는데, 이번 프로젝트는 처음부터 타입스크립트를 이용해서 작성하였다.

 타입스크립트를 제대로 이용하면서 느껴진 타입스크립트의 장점은 크게 4가지이다.

 우선 자바스크립트를 이용할 때 귀찮은 부분인 타입 체크하는 코드나 테스트를 작성하지 않아도 된다는 것이다. 자바스크립트뿐 아니라 파이썬이나 루비 같은 동적 타입 언어들도 가지는 문제인데 자바스크립트는 타입점검을 하거나 타입을 테스트하기 위해 코드가 verbose 해지기 쉬운데, 타입스크립트를 사용하면 이럴 이유가 전혀 없다.

 두 번째로 안심하고 코딩할 수 있다. 기존에 자바스크립트를 사용할 때는 장황한 테스트를 작성하여 높은 커버리지를 유지하여야 했다. 그렇지 않으면 사소한 실수건 의도적인 수정이었건 간에 코드를 잘못 변경하여 문제가 생기는 경우가 가끔 발생하는데, 타입스크립트는 이런 문제들을 컴파일 타임에 점검해주기 때문에 사전에 막을 수 있었다.

 세 번째로 ES6의 기능들을 사용할 수 있었다. 사실 이건 타입스크립트의 장점이라고 하기는 뭐하지만, 타입스크립트는 대부분의 ES6를 ES5나 ES3로 변환시켜준다. 덕분에 fat arrow, class, const와 let, 다양한 parameter 등 많은 기능을 사용할 수 있다.

 마지막으로 내가 사용하는 라이브러리를 더 쉽게 파악할 수 있다. TypeScript에서는 기존의 JavaScript로 작성된 npm 라이브러리를 그대로 사용할 수 있다. 대신에 타입 추론을 해주기 위해서 선언 파일이 있어야 한다. 하지만 사용하는 모든 모듈에 대해서 선언 파일을 직접 만들 필요는 없고, DefinitelyTyped를 통해서 다른 사람들이 이미 구현해둔 파일을 받을 수 있다. 이것은 사용할 API를 이해하는 데 꽤 많은 도움을 준다.

 물론 타입스크립트에 단점이 없는 것은 아니다. 하지만 타입스크립트를 사용하여 얻을 수 있는 장점이 더 크다고 생각된다. 정확히는 타입스크립트를 사용함으로 인해 들어가는 비용에 비해 타입스크립트를 통해 얻을 수 있는 이득이 훨씬 크다고 생각한다.
 그래서 다음에도 자바스크립트를 사용할 일이 생긴다면, 타입스크립트를 사용할 것이다. 아니 타입스크립트가 아닌 Google의 AtScript나 Facebook의 flow를 사용하게 될 수는 있지만, 최소한 자바스크립트를 동적 타입 언어인 그대로 사용하지는 않을 것이다.