Typescript가 무엇일까? 기본 개념 알아보기

오늘의 5분 개발지식 라디오! 안녕하세요~ 오늘은 타입스크립트에 대해서 이야기해보려고 합니다.

 

> 생긴 이유 (장점)

일단 타입스크립트가 왜 생겼는지를 먼저 알아보려고 하는데요, 타입스크립트랑 이름이 비슷한 친구가 있죠? 네 맞습니다. 자바스크립트가 있는데요, 타입스크립트는 이 자바스크립트에서 파생된 언어입니다. 자바스크립트는 동적 타입 언어로 개발자들이 코딩을 할 때 각 변수들이 어떤 타입인지를 명시하지 않습니다. 때문에 개발을 하다보면 로직상의 오류로 개발자가 의도한 타입이 아닌 경우가 있는데요, 

예를 들어 a와 b를 더하는 함수를 작성했다고 했을 때, 위의 코드는 에러없이 동작하는 매우 정상적인 코드입니다만, 개발자의 의도는 이게 아니죠. 

 

이렇게 오류없이 돌아가지만 의도한 동작이 아닌 경우도 있고, 아예 코드가 동작하지 않아서 빈화면이 뜨거나 멈춰버리는 경우도 많이있습니다.

따라서 타입스크립트는 변수에 타입을 명시하도록해서  정적분석을 통해 런타임에서 발생할 수 있는 에러를 미리 해결할 수 있도록 합니다. 화면에서 보이는 것처럼 IDE에서 빨간줄로 힌트를 주는 경우도 있고, 빌드타임에 에러가 발생해서 미리 검출하고 미리 해결할 수 있습니다. 

 

만약 타입스크립트처럼 미리 잡아주지않으면 실제 프로덕션 환경에 배포되어 사용자들이 피해를 본 다음에 고칠 수 밖에 없겠죠. 물론 타입스크립트는 타입관련 에러만 잡아주기때문에 그 외의 로직상의 오류는 당연히 스스로 찾아야 합니다만, 제 경험상으로 타입 관련 오류만 잡아주더라도 전체 발생하는 오류의 반 정도는 사전에 예방이 되는 것 같습니다.

 

이 외에도 미리 타입을 정의하고 작업을 하기때문에 경우에 따라선 조금 더 계획적으로 접근할 수 있기도 합니다.

 

타입스크립트에서 타입 명시는 필수가 아니며 여러가지 옵션들을 통해 조절을 할 수 있고, 바닐라 자바스크립트로 작성하더라도 정상적으로 동작합니다. 즉, 타입스크립트는 자바스크립트의 superset, 확대집합으로서 타입 정의와 체킹만 추가한 것으로 보셔도 됩니다.

 

> 트랜스파일러

하지만 문제가 하나 있습니다. 우리가 사용하는 크롬, 웨일, 사파리 등의 브라우저는 “타입스크립트"라는 언어를 이해하지 못합니다. 타입스크립트엔진이 아닌 자바스크립트 엔진만을 내장하고 있기 때문이죠. 오직 자바스크립트밖에 이해하지 못하는데요, 그럼 우리는 어떻게 타입스크립트를 사용할 수 있을까요?

 

여기서 트랜스파일이라는 개념이 등장하는데요, 

어 트랜스파일? 컴파일은 들어봤는데?라고 생각하실 수 있습니다.

 

컴파일은 더 높은 수준으로 추상화된 언어(high level language)를 그보다 낮은 수준으로 추상화된 언어(low level language)로 변환하는 작업을 뜻합니다. c언어를 머신코드로 바꿔주는 작업이 바로 컴파일인것이죠.

 

트랜스파일은 비슷한 개념이지만 더 낮은 추상화레벨로 바꿔주는 것이 아닌 비슷한, 또는 동일한 레벨의 언어로 바꿔주는 작업입니다. 자바스크립트는 머신코드와 같은 더 낮은 레벨은 언어라고 볼 수는 없기 때문에 컴파일이 아닌 트랜스파일이라고 합니다.

 

정리해보자면, 브라우저는 타입스크립트를 이해할 수 없기때문에 자바스크립트로 변환을 해서 실제 브라우저에서 돌리게 됩니다.

> 단점

• 하나의 절차가 더 추가되니까 비효율적인 것 아닌가?

자 여기까지 잘 따라오셨으면 문득

 

아니, 그냥 자바스크립트로 작성하면바로 브라우저에서 실행할 수 있는데 괜히 타입스크립트로 작성하면 코드도 트랜스파일해야되고 괜히 빌드 타임만 늘어나고 비효율적인거 아니야?

 

라고 생각이 드실 수 있습니다.

 

합리적인 추론이긴 한데요, 현실은 생각보다 녹록치 않습니다. 프론트엔드용 코드는 개발사가 세팅해둔 서버에서 돌아가는 것이 아니라 각각의 사용자의 디바이스에서 돌아갑니다. 이 디바이스는 최신 안드로이드일 수도 있고, iOS일 수도 있으며, 윈도우 PC일 수도 있습니다. 또, 극단적으로 이제 더이상 업데이트가 지원되지 않는 갤럭시 S2일 수도 있습니다. 이 경우 최신 자바스크립트 문법이 동작하지 않을 수 있는데요, 이러한 기기들을 지원하기 위해 polyfill을 사용하여 구형 자바스크립트 엔진에서도 돌아갈 수 있도록 코드를 변환합니다.

 

즉, 프론트엔드의 코드는 거의 항상 개발작업을 마치면 배포 전에 pollyfill 작업을 통해 코드를 변환하는 작업을 거치게 됩니다. 이 과정에서 최적화를 위해서 코드양을 줄이는 minification 등도 거치게되죠. 따라서 이 과정들과 함께 타입스크립트를 자바스크립트로 변환하면 되니까 크게 작업성에 문제가 되지 않는 것이죠.

 

정리하자면, 이왕 코드 작업 마치고 브라우저 호환성과 최적화를 위해서 변환작업을 거칠꺼면, 개발할 때 안정성과 편리함을 위해서 타입스크립트를 사용하고 같이 변환해버리자~ 가 된 것입니다.

• 코드양이 늘어나는 것 아닌가?

정적 타입을 사용하는 언어를 처음 접하게 되면 가장 먼저 들 수 있는 생각이 비즈니스 로직만 작성하면 되는데 쓸데없이 변수 타입까지 선언해줘야되서 코딩하는 것이 늘어나는 거 아니야?라고 생각하시는 분들이 많습니다.

 

이건 사람마다 조금씩 생각이 다를 수는 있는데요, 제 개인적인 생각으로는 개발자는 사람이기 때문에 필연적으로 실수를 하게 되어있는데요, 바닐라 자바스크립트를 사용할 때는 이 버그를 실제 페이지를 접근해서 오류가 발생해 빈화면이 떠야지만 그제서야 검출할 수 있었습니다. 타입스크립트를 사용하면 visual studio code와 같은 IDE에서 개발 중에 바로 에러를 표시해주기 때문에 오히려 제 기준에서는 생산성이 더 높아졌습니다.

 

또, 타입스크립트에서는 객체가 어떤 속성을 가지고 있는지 미리 선언해야되기때문에 IDE가 어떤 속성이 있는 지를 미리 알 수 있고, 따라서 속성을 타이핑할때 자동완성이되어 끝까지 치지않아도 되기때문에 작업속도가 더 빨라지는 것 같기도 합니다.

 

(^ 31)

> 최신 이슈

하지만 최근에는 타입스크립트를 자바스크립트로 변환하는 과정이 작업성을 저해한다는 의견도 조금씩 나오고 있습니다. 이는 최신 브라우저들의 발전때문인데요, 예전과 달리 브라우저들이 스스로 업데이트를 하면서 항상 최신 상태를 유지하는 기능을 많이 가지고 있는데요, 이런 브라우저들을 evergreen 브라우저라고 합니다.

 

이런 브라우저들이 많아지게되면 더이상 개발자가 브라우저 호환성을 신경쓸필요가 없어지게되고, 그럼 pollyfill을 사용하여 자바스크립트 변환이 필요없어지는 때가 온다는 것이죠. 그럼 트랜스파일하는 과정은 온전히 타입스크립트를 자바스크립트로 변환하기 위한 것이 되고, 이는 불필요한 작업성 저하라는 의견이 나오고 있습니다.

 

하지만 타겟 사용자가 구형 디바이스를 사용할 가능성이 높거나 이런 사용자도 다수 포함되어있는 오래된 서비스나 대기업에서 제공하는 서비스들은 어쩔수없이 꽤 오랜 시간 동안 브라우저 호환성을 신경쓸 수 밖에없기도 하고 everygreen 브라우저가 대세가 되기 위해서는 아직은 시간이 더 걸릴 것으로 보여 제 개인적으로는 타입스크립트가 한동안은 기본으로 쓰이는 언어가 되지 않을까 싶습니다