타입스크립트: 3000m 상공에서 내려다보기

본 포스팅은 "타입스크립트 프로그래밍" 책을 읽고 정리한 내용입니다.

• 컴파일러

  • 프로그래머가 작성한 텍스트는 컴파일러라는 특별한 프로그램이 파싱하여 추상 문법 트리(abstract syntax tree, AST)라는 자료구조로 변환합니다.
  • 그리고 컴파일러는 AST를 다시 bytecode라는 하위 수준의 표현으로 변환합니다.
  • 이후 런타임이라는 프로그램에 bytecode를 입력해 평가하고 결과를 얻을 수 있습니다.

  프로그램 실행과정은 결국 다음과 같이 요약할 수 있습니다.

  프로그램 -(파싱)-> AST -(컴파일)-> bytecode -(평가)-> 실행

  C, Java등 대부분의 언어들은 구현법은 다르지만 모두 위와 유사한 형태로 실행됩니다.

  타입스크립트가 다른 언어와 다른 점은 컴파일러가 코드를 바이트코드 대신 자바스크립트 코드로 변환한다는 것입니다. 이렇게 만들어진 자바스크립트는 일반적인 자바스크립트로 브라우저, 노드 등으로 실행할 수 있습니다.

  타입스크립트 컴파일러는 AST를 만들어 결과 코드를 내놓기 전에 타입 확인을 거칩니다. 그리고 바로 이 지점이 타입스크립트의 마법이 일어나는 지점입니다.

  타입스크립트의 컴파일 과정을 단계별로 확인해볼까요?

  • TS
    • 1. 타입스크립트 소스 -> 타입스크립트 AST
    • 2. 타입 검사기가 AST를 확인 (타입 마법)
    • 3. 타입스크립트 AST -> 자바스크립트 소스
  • JS
    • 4. 자바스크립트 소스 -> 자바스크립트 AST
    • 5. AST -> bytecode
    • 6. 런타임이 bytecode 평가

  1~3의 과정은 TSC가 수행하며 4~6은 브라우저, 노드, 기타 자바스크립트 엔진 같은 자바스크립트 런타임이 실행합니다.

  과정 3 이후부터는 타입을 확인하지 않습니다. 즉, 개발자가 기입한 타입 정보는 최종적으로 만들어지는 프로그램에 아무런 영향을 주지 않으며, 단지 1~2과정에서 타입을 확인하는 데에 쓰인다는 뜻입니다.

  따라서 마음대로 프로그램의 타입을 바꾸고 개선하고 실험해도 기존의 응용 프로그램이 망가질 염려가 없습니다.

• 타입 시스템
  타입 시스템은 타입 검사기가 프로그램에 타입을 할당하는 데 사용하는 규칙 집합입니다.

  타입시스템은 보통 명시적, 추론적 시스템으로 구분됩니다.
  명시적 - 어떤 타입을 사용하는지 컴파일러에 명시적으로 전달
  추론적 - 컴파일러가 자동으로 타입을 추론

  타입스크립트는 두 가지 시스템 모두의 영향을 받았습니다. 따라서 개발자는 타입스크립트 컴파일러는 타입을 추론할 수 있으며, 개발자가 명시하는 것도 가능합니다.

  타입스크립트는 어노테이션을 사용해 명시적으로 타입을 지정할 수 있습니다.

  어노테이션은 다음과 같은 형태로 사용됩니다.

  let a: number = 1
  let b: string = "hello"
  let c: boolean[] = [true, false]

  어노테이션을 사용하지 않으면 타입스크립트가 알아서 타입을 추론합니다. 대부분의 경우 타입스크립트는 타입을 잘 추론할 수 있으며, 따라서 명시적으로 꼭 필요한 경우를 제외하곤 어노테이션을 생략하는 것이 일반적입니다.

  타입 시스템 기능	자바스크립트	타입스크립트
  타입 결정 방식	동적	정적
  타입 자동 변환	O	X(대부분)
  타입 확인 시점	런타임	컴파일 타임
  에러 검출 시점	런타임(대부분)	컴파일 타임(대부분)

  동적 타입 바인딩이란 자바스크립트가 프로그램을 실행해야만 특정 데이터의 타입을 알 수 있음을 의미합니다. 따라서 자바스크립트는 프로그램을 실행하기 전에는 타입을 알 수 없죠.

  타입스크립트는 점진적으로 타입을 확인하는 언어입니다. 즉, 모든 타입을 알아야 최상의 결과를 보장하지만 컴파일에 반드시 모든 타입을 알아야 하는 것은 아닙니다.

  타입스크립트는 타입이 지정되지 않은 프로그램이라도 일부 타입을 추론해서 오류를 검출할 수 있습니다. 하지만 모든 타입을 알지 못하는 상황에선 오류가 사용자에게 그대로 노출될 수 있습니다.

  따라서 코드 마이그레이션 등 특별한 상황이 아니라면 모든 코드의 타입을 컴파일 타임에 지정하는 것을 목표로 해야 합니다.
  

• 타입 검사 시점
  타입스크립트는 컴파일 타임에 코드의 타입을 확인하기 때문에 코드를 실행하지 않고도 코드에 에러가 있음을 바로 알 수 있습니다.

  타입스크립트는 정적으로 코드를 분석해 이런 에러를 검출하여 코드를 실행하기도 전에 알려줍니다.

• 에러 검출 시점
  타입스크립트는 컴파일 타임에 문법 에러와 타입 관련 에러를 모두 검출합니다. 개발자가 코딩을 시작하면 코드 편집기에 이런 종류의 에러를 바로 보여주죠.

  물론 스택 오버플로, 네트워크 연결 끊김, 잘못된 사용자 입력 등 타입스크립트가 컴파일 타임에 검출할 수 없는 런타임 예외도 많이 존재합니다.

  하지만 순수 자바스크립트 세계에서 런타임 에러로 발생했을 많은 에러를 컴파일 타임에 검출할 수 있다는 점이 핵심입니다.

  타입스크립트를 사용하면 테스트, 배포, 실서비스 단계에서 검출되었을 에러를 코드작성, 컴파일 단계에서 검출할 수 있습니다.

  이러한 부분이 타입스크립트의 가장 큰 장점입니다.

• 코드 편집기 설정
  모든 타입스크립트 프로젝트는 루트 디렉터리에 tsconfig.json이라는 파일이 존재해야 합니다. 이 파일은 타입스크립트 프로젝트에서 어떤 파일을 컴파일하고, 어떤 자바스크립트 버전으로 방출하는지 등을 정의합니다.

  간단한 옵션을 살펴보겠습니다.

  옵션	설명
  include	TSC가 타입스크립트 파일을 찾을 디렉터리
  lib	TSC가 코드 실행 환경에서 이용할 수 있다고 가정하는 API
  module	TSC가 코드를 컴파일할 대상 모듈 시스템
  outDir	생성된 자바스크립트 코드를 출력할 디렉터리
  strict	유효하지 않은 코드를 가능한 한 엄격하게 검사. 올바른 타입을 갖추도록 강제(권장)
  target	TSC가 코드를 컴파일할 자바스크립트 버전(ES3, ES5, ES2015, ES2016 등)

• tslint.json
  보통 프로젝트는 TSLint 설정(탭을 사용할지 공백을 사용할지 등을 결정하는 코딩 스타일 규약)을 정의하는 파일을 포함합니다.

  이는 선택 사항이지만, 무조건 사용하여 일관된 코딩 스타일을 사용하는 것이 권장됩니다. 그러면 코드 리뷰 시 소모적인 논쟁을 줄일 수 있기 때문입니다.

<출처>

• 보리스 체르니, 타입스크립트 프로그래밍, OREILLY