타입스크립트는 자바스크립트로 컴파일되며, 실행 역시 자바스크립트로 이루어진다.
1. 타입스크립트와 자바스크립트의 관계 이해하기
" 타입스크립트는 자바스크립트의 상위 집합 ( suspect ) 이다. "
" 타입스크립트는 타입이 정의된 자바스크립트의 상위집합이다. "
자바스크립트는 보다 자유롭고, 타입스크립트는 보다 엄격하기 때문에 자바스크립트가 타입스크립트보다 상위에 있다고 인식하기 쉽다. 이 책을 읽기 전의 나 역시도 그랬다.
이 책에 따르면, 자바스크립트 프로그램이 제대로 작동할 수 있는 문법을 지녔다면 모두 유효한 타입스크립트 프로그램이라고 할 수 있다. 그러나 타입스크립트에는 타입스크립트 프로그램이지만 자바스크립트가 아닌 프로그램이 존재한다. 즉, " 자바스크립트 + something = 타입스크립트 " 인 것이다.
이 공식에서의 something이 처음 타입스크립트를 접하는 사람들이 타입스크립트의 정체성이라고 느껴질 타입 설정이다.
타입스크립트의 정적 타입 시스템은 런타임에 오류를 발생시킬 코드를 미리 찾아내는 것을 목표로 하고 있다.
변수에 타입을 지정해주지 않아도 초깃값을 통해 타입을 추론하기도 하지만 의도를 명확히 해서 타입스크립트가 잡재적 문제점을 찾을 수 있도록 하는 것이 보다 옳은 방식이라 할 수 있다.
2. 타입스크립트 설정 이해하기
타입스크립트 컴파일러는 매우 많은 설정을 지니고 있다. 타입스크립트의 설정을 통해 프로젝트를 어떻게 진행할지 결정할 수 있다.
타입스크립트를 설정하는 방법은 크게 두 가지가 있다.
첫째, 커맨드 라인에 직접 작성하는 것이다.
$ tsc --noImplicitAny program.ts둘째, tsconfig.json 설정 파일을 작성하는 것이다. 커맨드 라인에 아래와 같이 작성하여 설정 파일을 생성할 수 있다.
$ tsc --init이 책에서는 가급적 설정 파일을 사용하는 것을 권하고 있다. 협업하는 경우 뿐만 아니라 프로젝트에서 사용하는 모든 도구들이 설정 파일을 통해 타입스크립트를 어떻게 사용할 계획인지 인식할 수 있기 때문이다.
앞서 말한 것처럼 타입스크립트에는 수많은 설정이 있지만 가장 주목해야 하는 것은 noImplicitAny와 strictNullCheck이다.
1 ) noImplicitAny : 변수들이 미리 정의된 타입을 가져야 하는지 여부 제어
어떤 변수에 초깃값 없이 선언되었다면 any를 코드에 넣지 않았지만, any 타입으로 간주되기 때문에 이를 암시적 any라고 부른다. noImplicitAny 설정을 true로 두었다면, 변수의 타입을 명시적으로 any로 선언해주거나 더 분명한 타입을 사용해야 한다.
되도록이면 noImplicitAny를 설정할 것이 권고된다.
2 ) strictNullCheck : null과 undefined가 모든 타입에서 허용되는지 확인하는 설정
이 설정을 true로 둔 경우 변수에 null 또는 undefined가 들어갈 경우 오류가 발생한다. 새로운 프로젝트를 시작한다면 설정할 것이 권유되지만, 타입스크립트가 익숙하지 않거나 자바스크립트 코드를 마이그레이션하는 중이라면 설정하지 않아도 괜찮다.
이 외에도 언어에 영향을 미치는 설정이 많지만, 앞선 설정들보다 중요한 것은 없다. 다만, 모든 설정을 엄격하게 시키고 싶다면 strict 설정을 하면 된다.
3. 코드 생성과 타입이 관계없음을 이해하기
타입스크립트 컴파일러는 크게 두 가지 역할을 수행한다.
1 ) 최신 타입스크립트 / 자바스크립트를 구버전의 자바스크립트로 트랜스파일 ( transpile ) 한다.
2 ) 코드의 타입 오류를 체크한다.
타입스크립트에서는 두 역할이 철저하게 독립적으로 수행된다. 즉, 타입 오류가 있어도 트랜스파일이 가능하다. 이는 문제가 된 오류를 수정하지 않더라도 애프리케이션의 다른 부분을 테스트할 수 있도록 해, 보다 효율적인 개발이 가능하다.
만약 오류가 있을 때 컴파일하지 않으려면, 설정 파일에 noEmitOnError를 true로 두면 된다.
타입스크립트가 자바스크립트로 컴파일되는 과정에서 모든 인터페이스, 타입, 타입 구문은 그냥 제거되어 버리기 때문에 인터페이스를 타입으로 사용하여 조건문을 만들었다면, 제대로 작동하지 않을 수 있다.
그럴 때는 그 안의 구성요소의 여부를 통해 조건문을 만들거나 인터페이스 안에 타입 정보를 명시적으로 저장하는 태그 기법을 사용하여 해결할 수 있다.
타입스크립트의 타입은 런타임에는 전혀 영향을 주지 않기 때문에 값을 정제하기 위해서는 런타임의 타입을 체크해야 하고 자바스크립트 연산을 통해 변환을 수행해야 한다.
앞서 말했듯이, 타입스크립트의 타입과 타입 연산자는 자바스크립트 변환 시점에 제거되기 때문에, 런타임의 성능에 아무런 영향을 주지 않는다.
4. 구조적 타이핑에 익숙해지기
자바스크립트는 본질적으로 덕 타이핑 ( duck typing ) 기반이다.
즉, 어떤 함수의 매개변수 값이 모두 제대로 주어진다면, 그 값이 어떻게 만들어졌는지 신경 쓰지 않고 사용한다.
구조적 타이핑을 사용하면 유닛 테스트를 보다 쉽게 시행할 수 있다.
5. any 타입 지양하기
타입스크립트의 타입 시스템은 점진적 ( gradual ) 이고 선택적 ( optional ) 이다.
코드에 타입을 조금씩 추가할 수 있기 때문에 점진적이며, 언제든지 타입 체커를 해제할 수 있기 때문에 선택적이다.
이를 가능하게 하는 것이 ' any ' 이다.
any 타입은 변수에 어떤 것이든 올 수 있다고 선언해주는 것과 같다. 하지만 any는 쓰지 않는 것이 좋다. 다음은 그 이유이다.
1 ) any 타입에는 타입 안전성이 없다.
2 ) any는 함수 시그니처를 무시한다.
함수 시그니처란 호출하는 쪽과 함수의 약속된 출력 타입이다. 주고 받는 타입을 지정해두는 것이다. 하지만 any를 쓰면 어떤 타입이든 올 수 있개 때문에 문제가 발생할 수 있다.
3 ) any 타입에는 언어 서비스가 적용되지 않는다.
타입스크립트의 언어 서비스는 자동완성 기능과 적절한 도움말을 제공한다. 하지만 any 타입을 사용할 경우 아무런 도움을 받을 수 없다.
언어 서비스는 코드 실수를 줄이고 보다 효율적인 개발을 가능하게 하는 중요한 도구 중 하나이다. any를 사용함으로써 발생하는 생산성 문제라고 할 수 있다.
4 ) any 타입은 코드 리팩터링 때 버그를 감춘다.
5 ) any는 타입 설계를 감춰버린다.
객체를 정의할 때 특히 문제가 되는데, 상태 객체의 설계를 감춰버린다. 따라서, 설계가 명확히 보이도록 타입을 일일이 작성하는 것이 좋다.
6 ) any는 타입시스템의 신뢰도를 떨어뜨린다.
사람은 항상 실수를 한다. 보통은 타입 체커가 실수를 잡아주고 코드의 신뢰도가 높아진다. 하지만 any를 사용하면 타입이 불확실해 신뢰도가 떨어진다.
오늘의 총평
처음 타입스크립트를 접하고 많은 어려움이 있었다. 자바스크립트에서는 분명히 잘 작동했던 코드들이 제대로 작동하지 않아 어떻게 해야 할지 갈피를 못 잡고 하루를 보내기도 했다. 한 편으로는 굳이 잘 쓰고 있는 자바스크립트를 타입스트립트로 바꿔야 할 필요가 있는지 의문을 갖기도 했다. 하지만, 타입스크립트는 이제 몰라서는 안 되는 언어 중 하나로 발전했다. 따라서, 보다 잘 이해하고 보다 효과적이고 효율적인 코드를 작성하기 위해 " Effective Typescript "를 공부해보고자 한다.
