[타입스크립트] 타입스크립트 컴파일러(Typescript Compiler, TSC)

컴파일러
 

타입스크립트 컴파일러(Typescript Compiler, TSC)
타입스크립트는 자바스크립트나 자바 같은 주요 언어와는 다른 방식으로 동작

 프로그램은 프로그래머가 작성한 다수의 텍스트 파일로 구성된다.

 

 

<다른 언어>

텍스트를 컴파일러가 파싱하여 추상 문법 트리(abstract syntax tree, AST)라는 자료구조로 변환

컴파일러가 AST를 바이트코드로 변환

런타임 프로그램에 2에서 변환된 바이트코드를 입력, 평가 후 결과얻음.

즉, 프로그램 실행이란, 컴파일러가 소스 코드를 파싱해 AST로 만들고, 다시 AST를 바이트코드로 변환한 것을 런타임이 평가하도록 지시하는 것

 

<타입스크립트>

타입스크립트는 컴파일러가 소스 코드를 자바스크립트 코드로 변환한다(바이트코드X).

타입스크립트는 코드는 언제 안전해지는가.
타입스크립트는 컴파일 단계에서 AST를 만들어 결과 코드를 내놓기 전에 타입 확인 과정을 거친다. 

typechecker(타입검사기) 사용 : 코드의 타입 안전성을 검증하는 프로그램

이 타입 확인 단계 덕분에 프로그래머의 기대대로 실수를 방지할 수 있다.

전체적인 타입스크립트 컴파일 과정은 다음과 같다.

1~3은 TSC(타입스크립트 컴파일러)
4~6은 브라우저, nodeJs, 기타 자바스크립트 엔진에서 수행한다.
<전체적인 타입스크립트 컴파일 과정>

TS 소스를 TSC가 파싱하여 타입스크립트 추상 문법 트리(AST)로 변환 : 타입 이용됨 

타입 검사기가 AST를 확인(타입 안정성 확보 구간) : 타입 이용됨 

TSC가 AST를 JS 소스로 컴파일(변환) : 더이상 타입 확인하지 않음

JS 소스가 자바스크립트 추상 문법 트리(AST)로 변환

AST를 바이트 코드로 변환

런타임 프로그램에 5에서 변환된 바이트코드를 평가
1~3은 TSC가 수행하며, 4~6은 브라우저, NodeJS, 기타 자바스크립트 엔진 등에서 수행한다.
 


보통 자바스크립트 컴파일러와 런타임은 엔진이라는 하나의 프로그램으로 합쳐진다.
프로그래머는 주로 이 엔진과 상호작용한다. V8(NodeJS, 크롬, 오페라에서 사용), 
스파이더몽키(파이어폭스), JSCore(사파리), 샤크라(엣지) 등이 이처럼 동작하며 
자바스크립트가 해석되는 (interpreted) 언어의 모습을 갖게 만든다.
 

과정 1~2에서는 소스 코드에 사용된 타입을 사용하지만, 과정 3에서는 이용하지 않는다.

즉, 개발자가 코드에 기입한 타입 정보는 최종적으로 만들어지는 프로그램에 아무런 영향을 주지 않으며, 단지 2번 과정까지 타입을 확인하는 데만 쓰인다.

타입 시스템 (type system)
타입 검사기가 프로그램에 타입을 할당하는 데 사용하는 규칙 집합이다.

타입 시스템에는 사용하는 보통 2가지 종류가 존재

어떤 타입을 사용하는지를 컴파일러에 명시적으로 알려주는 타입 시스템

자동으로 타입을 추론하는 타입 시스템

2가지 시스템은 서로 장단점이 존재하고, 타입스크립트는 양측에 모두 영향을 받았다. 즉, 프로그래머는 선택할 수 있다.

어노테이션 : 타입스크립트에 명시적으로 타입을 지정할 수 있다.
'value:type’의 형태로 쓰이며 타입 검사기에게 곧바로 타입을 알리는 역할을 한다.

어노테이션을 쓰지 않으면 타입스크립트가 알아서 타입을 추론한다 : 코드양을 줄인다는 측면에서 이점이 있다.  


const a: number = 10;  // 타입을 명시

const b = 10; // 타입을 추론하게 함
타입스크립트 vs 자바스크립트
다음 표는 타입스크립트와 자바스크립트의 타입 시스템을 비교한 표다.


다만, 스택 오버 플로/네트워크 연결 끊김/ 잘못된 사용자 입력 등 타입스크립트가 컴파일 타임에 검출할 수 없는 런타임 예외도 많다. 다만… 순수 자바스크립트 세계에서 런타임 에러로 발생했을 많은 에러를 타입스크립트는 컴파일 타임에 검출할 수 있다는 점이 핵심이다.
타입 결정
동적 타입 바인딩이란, 자바스크립트가 프로그램을 실행해야만 특정 데이터의 타입을 알 수 있음을 의미한다. 

반대로 타입스크립트는 점진적으로 타입 확인한다. 컴파일 타임에 프로그램의 모든 타입을 알고 있을 때 최상의 결과를 보여줄 수 있지만, 프로그램을 컴파일하는 데 반드시 모든 타입을 알아야 하는 것은 아니다.(일부 타입 추론 가능하므로)

이런 점진적 컴파일은 코드의 일부만 고쳤을 때 전체 프로그램을 다시 컴파일할 필요가 없으므로 빨리 재컴파일된다는 장점도 있다.

점진적 타입 확인은 ‘타입을 지정하지 않은 기존 자바스크립트 코드’를 ‘타입을 사용하는 타입스크립트’로 마이그레이션할 때 매우 유용하다. 

 

하지만 코드를 마이그레이션하는 상황이 아니라면 모든 코드의 타입을 컴파일 타임에 지정하는 것을 목표로 해야 한다. 따로 언급하지 않는 한 이 책은 모든 코드의 타입이 컴파일 타임에 식별되도록 하는 방식을 추구할 것을 권장한다.

 

타입 변환
자바스크립트는 약한 타입 언어다. 유효하지 않은 연산을 수행하면 다양한 규칙을 적용해가며 개발자가 의도한 바를 알아내려고 노력하고, 결과를 도출한다.

다음과 같은 예가 있다.


3 + [1]

1. 자바스크립트는 3이 숫자고 [1]이 배열임을 확인
2. 개발자가 +를 사용했으므로 자바스크립트는 값을 연결하고 싶어하는 것으로 인지
3. 자바스크립트는 3을 문자열 "3"으로 암묵적인 변환을 시도
4. 자바스크립트는 [1]을 문자열 "1"로 암묵적인 변환을 시도
5. 두 문자열을 붙여 "31"이라는 결과 도출
즉, 순식간에

3 + [1]를  

(3).toString() + [1].toString()로 바꾸어버렸다. 자바스크립트가 제공하는 이러한 종류의 암묵적 변환 덕분에 뒤늦게 문제가 터져도 그 원인을 찾기가 힘들다.

 

반면 타입스크립트는 유효하지 않은 작업을 발견하는 TSC가

컴파일 타임에 코드의 타입을 확인한 결과로 에러를 보여준다.


3 + [1]     // 에러 TS2365: '+' 연산자를 '3'과 'number[]' 타입에 적용 불가

'31'의 결과 값을 도출하고 싶은 경우

let result = (3).toString() + [1].toString();
console.log(result); //31
올바르지 않은 연산을 수행하면 타입스크립트가 바로 그 부분을 지적하며, 의도를 명시해야 통과할 수 있다.

빨간 밑줄이 그어지는 덕분에 개발자는 코드를 실행하기 전에 실수를 알아차리고 바로잡을 수 있다.