[TS] 타입스크립트를 사용해야하는 이유: TS 퇴출 논쟁

 

본 글은 "이펙티브 타입스크립트"를 읽고 작성하는 독후감입니다.

 

https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01

Turbo 8 is dropping TypeScript

Turbo의 타입스크립트 퇴출에 관한 이슈입니다. 조금 지난 이슈지만 이번 포스팅에서는 해당 글과 관련지어 "타입스크립트를 왜 사용해야 하는가?"라는 주제로 이야기를 해보겠습니다.

 

자바스크립트는 이상한 언어입니까?

자바스크립트는 웹 개발자가 필수적으로 알아야 할 기본 언어입니다. 브라우저에서 동작하는 클라이언트 어플리케이션을 만들기 위해 가장 많이 사용되는 언어입니다. 하지만 가끔 객체지향 언어에 익숙한 사람들과 이에대해 이야기하면 늘 자바스크립트는 "이상한 언어"라는 말을 듣습니다. 자바스크립트는 예상한대로 동작하지 않을 경우가 많기때문입니다. 10일만에 설계한 언어라서 그럴까요? (개인적인 생각)

 

자바스크립트가 예상대로 동작하지 않는다고 생각하는 이유는 바로 동적 타입을 지원하기 때문입니다. 예상대로 동작하지 않는 것이 아니라 개발자가 그렇게 생각할 수 있다는 말입니다. 바로 자바스크립트의 런타임과 개발자가 코드를 작성하는 시기에 간극이 존재하기 때문에 많은 개발자들이 그렇게 느낄 수 있습니다. 프로젝트의 볼륨이 커지고 코드의 양이 많아질 수록 어쩔 수 없이 겪게되는 현상입니다.

타입스크립트에 대해서

타입스크립트는 "자바스크립트의 런타임과 개발자가 코드를 작성하는 시점의 간극을 줄이기위해" 탄생했습니다. 실제로 타입스크립트를 작성해 실행해도 런타임시에는 자바스크립트가 실행됩니다. 이러한 맥락에서 타입스크립트는 새로운 언어는 아닙니다. 그렇다면 타입스크립트는 어떤 언어일까요?

 

첫번째 타입스크립트는 타입체크를 위한 도구입니다.

코드의 실행과 타입 연산은 독립적으로 실행됩니다. 실제로 런타임환경에서 타입 관련된 코드와 연산은 제거됩니다.

// 코드 베이스
function asNumber(val: number | string):{return val as number};

// 실제 동작
funtion asNumber(val){return val}

 

즉, 타입 스크립트의 타입 연산은 런타임 성능에 영향을 주지 않습니다. 또한, 타입 오류가 있더라도 코드 생성(실행)은 가능합니다.

타입스크립트는 자바스크립트의 이상한 동작을 사전에 방지할 수 있도록 도와줍니다. 자바스크립트만을 고집하는 개발자들은 타입을 머릿속에 넣고 개발할 가능성이 큽니다. 하지만 코드의 볼륨이 커질 수록 프로젝트에 참여하는 개발자가 많을 수록, 그 개발자들 모두가 자바스크립트의 동작을 모두 외우고 예측하고 다닐 가능성은 크지 않습니다.(구성원 모두가 모던 자바스크립트 딥다이브를 10 회독 하고 경력이 10년 이상이면 모를까.)

 

개인의 프로그래밍 역량과 협업은 다른 맥락입니다. 알고리즘 테스트나 절차지향적인 프로그래밍을 할 경우 강 타입언어는 불편합니다. 하지만 애플리케이션을 설계할 경우 이야기가 다릅니다. 협업을 위해서는 약속이 필요하고, 타입을 통해 개발자들은 약속할 수 있습니다. (여기서 언급한 타입은 객체지향 패러다임 관점에서의 포괄적인 의미의 타입입니다.) 자바스크립트의 이상한 동작을 방지하고, 코드의 품질을 중요하게 생각하는 팀이라면 타입스크립트의 적극적인 사용은 필수입니다. 팀 단위로, 유연하고 일관된 코드를 작성하기위해서는 타입 컨벤션을(type과 interface 예약어의 사용, 타입 정의 등) 정하고 이를 활용해야합니다.

 

두번째, 타입스크립트는 개발자를 도와 타입을 추론합니다.

정적 타입을 지원하는 다른 언어와의 차이점입니다. 타입스크립트는 타입을 명시하지 않아도 객체의 타입을 추론합니다. 타입 추론으로 인해 개발자들은 장황한 코드를 방지할 수 있고 꼭 필요한 부분만 타입을 명시할 수 있습니다.

또한 타입 넓히기, 좁히기, 단언, 타입 확장 등의 타입 연산을 통해 타입 시스템을 유연하게 사용할 수 있습니다. 이러한 맥락에서 우리는 타입스크립트의 타입 시스템을 집합과 범위의 개념으로 이해할 수 있습니다.

 

세번째, 타입스크립트는 객체지향을 지원합니다.

객체지향 패러다임 관점에서 보자면 타입은 우리가 인식하는 다양한 사물이나 객체에 적용할 수 있는 아이디어와 관념입니다.

타입 시스템은 classification(분류)철학에 익숙한 객체지향 패러다임과 잘 맞고, 우리가 인식하는 객체를 더욱 잘 표현할 수 있게 도와줍니다. 타입스크립트에서 지원하는 class와 interface, 멤버변수 접근제어자, 생성자와 같은 기능은 객체지향 언어에 익숙한 개발자들에게 스크립트 언어에 대한 진입장벽을 낮춰줍니다. 실제로 타입스크립트를 통해 구현된 Nest js는 SOLID 원칙에하에 탄생한 자유도가 낮은 백엔드 프레임워크입니다. 또한 서버사이드를 지원하는 프레임워크인 Next js와 타입스크립트의 조합은 프론트엔드 개발자가 관심사의 분리와 애플리케이션 아키텍처에 고민할 수 있는 발판을 마련해줍니다. 서버 액션, 인터페이스, 클래스를 활용함으로서 보다 더 유연하고 변화에 잘 대응하는 애플리케이션을 설계할 수 있습니다.

 

네번째, 타입스크립트는 완전하지 않습니다.

모든 소프트웨어가 그렇듯 타입스크립트도 한계가 존재합니다. any의 사용, 잉여 체크 타입, 타입 단언 등 개발자는 마음만 먹으면 타입 체크 시스템을 속일 수 있습니다. 물론, 속이는 것이 나쁜 것은 아닙니다. 하지만 이러한 예외 동작을 알고 타입 시스템을 사용해야합니다.

타입스크립트를 반대하는 이유?

위 글에서 타입스크립트를 반대하는 이유를 요약하면 다음과 같습니다.

 

1. 추가적인 컴파일 단계 필요

2. 코드 복잡성 증가

3. 간단한 작업을 어렵게 만들고, 결국엔 any를 사용하게되는 현상

4. JavaScript의 유연성

 

실제로 타입 스크립트의 타입 연산과 런타임은 독립적입니다. 단순한 빌드 과정의 추가성은 있지만 그 과정이 개발자의 경험을 해치지는 않습니다. 실제로 런타임의 성능에 영향을 미치지 않습니다. 오히려 타입 연산과 런타임의 분리로인해 성능 저하는 방지하면서 자바스크립트의 이상한 동작을 사전에 제어할 수 있습니다. 또한 타입으로 인한 장대한 코드 또한 타입 추론 시스템과 함께라면 방지할 수 있습니다.

 

"간단한 작업을 어렵게 만든다."라는 말은 "자바스크립트에게 타입과 관련된 모든 작업을 위임한다."라고 생각합니다. 자바스크립트에서의 작업이 간단한 이유는 타입과 관련된 작업을 자바스크립트가 대신 해주기 때문입니다. 많은 개발자들의 지지를 받고 오랜 시간 유지되고 있는 객체지향 패러다임에서 타입스크립트를 버리고 자바스크립트로 돌아가려는 시도는 적절하지 않다고 생각합니다.

 

프로그래밍 언어를 사용하는 개발자 관점에서 자바스크립트는 유연할 수 있습니다. 하지만 복잡한 비즈니스 문제와 변화를 요구하는 관점에서는 자바스크립와 타입스크립트 중 어느것이 더 유연할까요? 필자는 타입을 설계할 수 있고, 이로 인해 런타임 시 나비효과를 예방할 수 있는 타입스크립트가 더 안정적이고 유연한 어플리케이션을 설계하는데 적합하다고 생각합니다.