본문 바로가기
개발공부_Blog/TypeScript

TypeScript의 타입 체크는 JavaScript 런타임에 영향을 주지 않는다

by 독서개발자 2023. 12. 22.

 Effective- TypeScript - Intro

Effective TypeScript 책으로 스터디를 했다. 책을 읽고 정리한 내용은 아래에 따로 적어두었다. 블로그 시리즈는 읽으면서 중요하다고 크게 깨달은 부분, 엄청 와닿은 몇 개의 주제를 뽑았다.
[ ✨Effective-TypeScript Book-study 요약✨ ]

 

[BOOK-STUDY] Effective TypeScript | Built with Notion

Effective TypeScript

fun-blog.notion.site

 

TypeScript로 프로젝트를 예전에 한 번 해봤는데 그 때는 그저 어찌저찌 타입을 끼워맞추는 식으로 에러와 함께 프로젝트를 진행했었다. ( 정말 괴로웠었다ㅠㅠ ) 이후 타입스크립트는 조금 멀리, 하게 되었었다. 하지만 이번에 스터디를 통해 접하게 되었고, 큰 맘 먹고 집중해서 공부를 하고 있다.

역시 처음 배울 때는 수박 겉 핥기 식으로 배우면 안된다는 걸 크게 느꼈다. 그때 너무 급하게 배워서 썼던 터라 타입에 대해 제대로 이해도 못하고, any만 도배했던 거로 기억한다. 그래서 TypeScript는 ‘어렵다’는 벽이 생겼었다. 이번에 공부하면서 그 ‘벽’을 깬 것 같다.

 

TypeScript의 장점 중 하나가 JavaScript의 상위 언어라 JavaScript문법과 크게 다를 게 없다고 사람들은 말한다. 하지만 나는 TypeScript가 마냥 새롭게만 느껴졌다. (이런 새로운 언어같으니라구….. ) 하지만 시간을 쏟을수록 TypeScript의 매력에 빠지는 것 같다. 책과 강의를 통해 배우고 있는 중이지만 빨리 프로젝트에 적용해보고 싶은 욕구가 마구마구 솟는다. 매력있는 언어다.

 

내 공부 스타일이 전체적인 그림을 그리고, 세세하게 더 공부하는 스타일이다. 그런데 TypeScript가 그런 느낌이다. 함수를 예로 들면, 함수의 전체적인 입출력 타입을 알고, 그에 따른 타입을 지정해줘야 한다는 점에서, TypeScript를 한다는 건 ‘전체적인 모든 상황을 파악하고 있어야 해!! 숲을 봐!!!‘야 한다는 느낌을 받았다. 왠지 나에게 도전장을 내미는 것 같아 마음에 쏙 든다


 

TypeScript의 동작원리

우리가 TypeScript( = TS )로 제작하는 프로젝트는 거의 웹에서 동작할 것이다. 하지만 웹은 TS를 이해하지 못한다. 이로 인해 TS는 웹이 이해할 수 있는 JS로 변환을 해줘야 한다. JS보다 컴파일 과정이 한 번 더 들어가야 하는 것이다.

  • TS컴파일러는 타입 체커를 한 뒤에,
  • JS로 컴파일 한다. ( 트랜스파일 한다. ⇒ 소스코드를 동일한 동작을 하는 다른 형태의 소스코드로 변환하는 것 )
  • 이후 JS는 바이트 코드로 변환하여 인터프티터 ( 또는 JIT컴파일 ) 로 코드를 실행한다.

TypeScript 컴파일러의 역할

  • 변수, 함수, 객체 등의 선언에 대한 타입 정보를 분석하고, 정적 타입 시스템에 따라서 코드의 타입을 확인하여 오류를 체크한다. 이로 인해 개발자는 코드 작성 시점에 타입 관련 오류를 미리 확인할 수 있게 된다. 코드의 타입 안정성을 높이기 위해 TS의 문법과 규칙을 활용한다.
  • TS 컴파일러는 JS로 트랜스파일링 하기 때문에, 사용자가 tsconfig.json에 ECMAscript버전을 지정하면 그에 맞는 JS로 트랜스파일링이 가능하다. 그래서 최신 TS와 JS를 사용해 개발할 수 있다. ( 우리는 최신 TS, JS를 사용하지만, 그래도 브라우저에서 지원하는 ECMAscript 버전을 생각…해줘야 한다. 쨌든 그에 맞는 버전을 설정하면 TS컴파일러가 트랜스파일링 해준다는 거. )

TypeScript 컴파일러의 핵심 작업은 독립적으로 동작한다.

TS컴파일러는 TS코드를 JS로 트랜스파일링 하는 일과 TS코드에 사용된 타입을 체크하는 역할을 하는데, 이 두 역할은 독립적으로 동작을 한다. TS가 JS로 변환될 때 코드 내의 타입에는 영향을 주지 않고, 실행시점에도 타입은 영향을 미치지 않는다.

TS의 타입 체크가 JS런타임에 영향을 주지 않는다는 예시들이 책에 나와있다. TS 프로젝트를 하면서 ‘어 맞아, 타입에러 났었는데 에러 안뜨고 화면 동작했어!’ 하는 경험이 있었다. 그때는 그게 왜 그렇게 됐는지 모르고, ‘와 신낰ㅋ’라고 만 했었는데. 그 이유를 드디어 찾았다.

  • 타입 오류가 있는 코드도 컴파일이 가능하다. 타입에 오류가 있어도, 오류가 난 부분의 JS가 에러가 발생하지 않는 유효한 내용의 코드라면 TS컴파일러는 컴파일을 한다. 그렇게 되면 화면 동작에는 문제가 없다.
  • 위와 같은 경우에는 코드가 빨간 밑줄이 쳐져 있을 것이다. 이 때의 빨간 에러의 정체는 컴파일 문제가 아니라 타입 체크의 문제이기 때문에 ’컴파일에 문제가 있어!!’ 가 아니라 ‘타입 체크에 문제가 있다’ 고 말하는 것이 더 정확한 표현이 되겠다.
  • 런타임에 타입 체크 불가 ( 런타임 시에도 타입을 유지하려면 별도의 방법이 필요 )
    TS컴파일러가 타입 체킹을 하고 나면 타입에 관한 코드는 사라진다. 이후 런타임에는 타입과 관련된 정보가 없기 때문에 타입에 관련된 내용과 값을 비교하는 경우 에러를 발생하게 된다. 
interface Square {
  width: number;
}
interface Rectangle extends Square {
  height: number;
}
type Shape = Square | Rectangle;
function calculateArea(shape: Shape) {

	if (shape instanceof **Rectangle**) {  // Error
    shape;  // Type is Rectangle
    return shape.width * shape.**height**;  // Error
  } else {
    shape;  // Type is Square
    return shape.width * shape.width;
  }
}
​

 

 

위 코드에서 TS컴파일러가 타입 체킹을 하고나면 아래와 같은 JS로 트랜스파일링 된다. if문의 조건식에 instanceof가 객체의 인스턴스 여부를 확인하는데, Rectangle는 타입이므로 정보를 확인할 수 없다. 그렇기 때문에 에러가 발생하게 된다. 반환값도 Rectangle타입의 프로퍼티 속성을 확인할 수 없으니, height를 확인할 수 없는 것이다.

"use strict";
function calculateArea(shape) {
    if (shape instanceof Rectangle) {
        shape; // Type is Rectangle
        return shape.width * shape.height;
    }else {
        shape; // Type is Square
        return shape.width * shape.width;
  }}

 

런타임 시에도 타입을 체크하려면 별도의 방법이 필요하다 ( 다음 글에서…. )

  • 태그된 유니온을 사용해 비교하는 것
  • in 연산자로 속성을 체크하는 방법
  • 타입을 클래스로 생성하여 타입으로 비교하는 방법 ( 클래스는 TS의 타입값과 JS 런타임에 값을 다 제공할 수 있다 )
  •  

결론, TypeScript의 타입 체크는 JS 런타임에 영향을 주지 않는다.

END —-

새로운 개념에 대한 부분을 공부했기 때문에 내가 이해한 부분이 맞는지 재차 확인하면서 공부했다. 아마 Effective TypeScript를 공부하는 동안, 책에 쓰인 글을 내가 정확히 이해한 게 맞는지 많이 찾아보며 공부할 것이다. 시간은 꽤 걸리지만 그만큼 머리에 남는 게 많아서 기분이 좋다. ( 현재진행형 )

TS에 관해 검색하다가 TS를 사용하면 런타임 시간에 영향을 준다고 했던 글들을 본 기억이 있다. 그래서 TS를 쓰는 것이 비추라고 했던가… 검색을 통한 글들이 나에게 도움을 줄 때도 있지만, 모든 정보가 ‘옳은 것’이라고 생각하지는 않는다. 내가 찾아보는 글, 내가 쓰는 글 모두 정확성에 대해 생각해보게 되는 시간이었다.

 

처음 블로그를 작성했을 때는 내가 쓴 글에 대한 정확성을 생각해 보지 않았다. 하지만 공부를 하고 내가 찾아보는 정보가 많아질수록 정확도에 대한 생각을 하게 된다. 지금 글을 쓰면서도 최대한 검색하고, 비교하고 맞는 말인지 생각해서 작성하려고 한다. 그럼에도 부족한 부분은 있을 거지만… ( 이전에 작성한 글을 보면 꼭 틀린 부분이 한 두 군데씩은 있었기 때문… )

한번에 모든 정보를 100% 완벽하게 소화할 수 없다. 특히 IT분야에서는 더 그렇다고 생각한다. 항상 내가 할 수 있는 선에서 최선의 방법으로 공부를 하고, 정확한 마무리 짓는 습관을 들이도록 해야겠다. 그리고 자주 글을 돌아보면서 업데이트도 해야지. ( 그래서 노션에 블로그를 하기 시작했다. 정리하기도 쉽고 수정도 편해서 ㅋㅋㅋㅋ )

댓글