자바스크립트와 타입스크립트의 한계

자바스크립트와 타입스크립트 는 비슷하지만 서로 다른 언어로서 바라보고 접근해야 않겠나 생각이 듭니다. 다른 언어로 바라봐야 한다는 것은 서로 다른 관점과 접근방식을 가지고 해당 언어들을 다룰 필요가 있다는 것입니다.

자바스크립트의 특징

자바스크립트는 타입이 없기 때문에 타입오류를 오직 런타임시에만 확인 가능하다는 약점이 있습니다. 개발자가 모든 함수와 데이터의 타입을 정확하게 인지하고 코딩을 한다는 것은 사실상 불가합니다. 그렇기 때문에 우리는 자바스크립트로 코딩을 할 때 본인도 모르게 수많은 타입에러 가능성들을 마치 지뢰를 설치하듯 여러 로직들 가운데 심어두게 됩니다. 결국 우리는 언제나 런타임에 언제 터질 지 모르는 타입에러에 대한 불안감에서 벗어날 수가 없습니다.

타입스크립트의 특징

이에 대한 대안으로서 타입스크립트가 많은 자바스크립트 개발자의 사랑을 받으며 성장해 왔습니다. 하지만 타입스크립트는 강한 타입 정의를 개발자에게 요구하기 때문에 간단한 기능하나 추가하거나 수정할 때라도 꼼꼼한 타입정의를 개발자에게 강제합니다. 뿐만 아니라 현실적으론 런타임에 발생하지 않을 상황까지도 완벽하게 통제할 것을 개발자에게 요구합니다. 이는 불필요한 개발공수를 발생시키고 프로젝트 개발기간을 늘리는 요인으로 작용할 수 있습니다.

위와 같이 2가지 언어의 장단점은 분명합니다. 따라서 아래와 같은 코딩 방법을 제안합니다.

자바스크립트 사용시 당부

자바스크립트를 사용할 때는 최대한 간결하게 코드를 작성합니다. 이는 코드의 가독성을 높이고 개발 및 유지보수를 용이하게 합니다. 예상되는 타입에러에 대한 우려는 최소한의 예외처리 코드로 방어합니다. 타입에러에 대한 지나치게 많은 예외처리 코드들은 코드의 가독성을 떨어뜨리는 원인이 될 수 있습니다. 단위 테스트케이스 작성시 런타임 타입에러에 대한 부분을 포함시켜 타입에러에 대한 예외처리가 정상적으로 동작하는지 확인합니다.

하지만 미리 예상할 수 없는 타입에러에는 어떻게 대응해야 할까요? 타입스크립트를 사용하는 것 외에는 답이 없습니다. 자바스크립트를 사용하는 이상, 소 잃고 외양간 고치는 전략 외에 우리에게 다른 카드가 없음을 인정하고 받아들여야 할 것 같습니다.😥

타입스크립트 사용시 당부

타입스크립트의 장점과 혜택을 마음껏 누리기 위해 any 타입 사용을 최소화합니다. any 타입의 사용은 타입언어가 주는 장점과 혜택을 모두 무력화합니다. 하지만 타입정의는 통제가능한 수준으로(필요한 만큼만) 정의합니다. 지나친 타입정의는 중요한 로직보다 타입정의 코드가 더 많아지게 하여 코드 가독성을 떨어 뜨리고 작은 범위의 코드 수정도 어렵게 하는 요인이 될 수 있습니다.

그럼에도 불구하고 타입스크립트는 당신에게 과도한 타입정의를 자연스럽게 요구할 것입니다. 그럴 땐 불평하지 말고 타입스크립트의 권고를 따르십시오. 당신은 이미 런타임 타입에러 헬로부터 벗어나기 위해 타입스크립트를 선택한 것이 아닙니까. 세상에 공짜는 없습니다.

꼼꼼하게 타입정의를 했음에도 발견되는 타입에러들은 무엇입니까? 내가 작성한 타입스크립트코드들의 타입이 완벽하더라도 프로젝트 내에서 사용하는 외부 자바스크립트라이브러리 들이 있지 않았었습니까. 나 혼자 잘한다고 모든 것이 완벽해 지는 것은 아닙니다. 자바스크립트커뮤니티 안에서 당신은 자유로울 수 없습니다. 실제 런타임에서 동작하는 코드는 결국 자바스크립트 임을 잊지 마십시오. 자바스크립트는 태생이 원래 그런 언어였음을 인정해 주세요.

스크립트 언어의 한계

자바스크립트를 사용하든 타입스크립트를 사용하든 당신은 완전히 만족스러울 수 없을 것입니다. 자바스크립트는 스크립트 언어로서의 한계를 분명히 가지고 있습니다. 그 한계를 인정하고 그 한계 안에서 사용을 해야 합니다.

그 한계를 어떻게든 넘어 보려는 시도가 타입스크립트겠지요. 타입스크립트가 자바스크립트의 super set 이라고 자신을 소개하지만, 저는 타입스크립트가 근본적으로 자바스크립트의 sub set 일 수 밖에 없다고 생각합니다. 자바스크립트에 타입시스템을 추가했다고 하지만 반대로 생각하면 동적 타입 기능을 제거했다고 바라볼 수도 있기 때문입니다. 그리고 결국 타입스크립트는 자바스크립트 생태계 안에 포함되어 있기 때문입니다.

타입스크립트가 자바스크립트 생태계 안에 포함되기 때문에, 타입스크립트는 any 타입을 결코 포기할 수 없을 것 같습니다. 당신이 아무리 당신의 프로젝트에 타입정의를 꼼꼼히 하더라고 타입이 없는 외부 생태계와 연결되기 위해서 any 타입은 필수적이기 때문이죠. 결국 타입스크립트의 치명적인 한계는 any 타입을 포기할 수 없는 태생적 제약에 있습니다.

다른 대안은?

그렇다면 다른 대안은 없을까요? elm 에 대해 들어보셨나요? elm은 이에 대한 매력적인 시도라고 생각합니다. elm 은 강한 타입을 가진 함수형 프로그래밍 언어로서 웹앱을 만들기 위한 자바스크립트의 대안으로 태어났습니다. elm 은 자바스크립트와는 전혀 다른 언어로서 완벽한 타입언어입니다. ts와 마찬가지로 자바스크립트로 컴파일되지만 자바스크립트 생태계와 인터랙션하기 위하여 any 타입을 사용하지는 않습니다. elm은 전혀 다른 방법으로 외부와 인터랙션을 합니다.

또 다른 방법으로 MS에서 제공하는 ASP.NET Core Blazor 가 있습니다. 블레이저는 C#으로 개발하고 웹어셈블리로 컴파일이 되기 때문에 웹앱 개발이 가능합니다. 그리고 개발하기 위한 환경들이 잘 갖춰져 있다고 합니다. 저는 노마드코어의 .NET Core 영상을 통해 블레이져를 알게 되었고 관련 기술경험을 가지고 있지 않기 때문에 자세한 설명을 더하기는 어려울 것 같습니다.

웹 개발의 미래는?

굳이 10년 단위로 웹개발 생태계를 나눠본다면, 90년대는 웹의 태동기라 할 수 있을 것 같습니다. 2000년대는 웹이 대중화되었던 시기였던 것 같습니다. 그리고 인터넷과 웹이 대중화됨에 따라 웹에 대한 여러가지 니즈들이 생겨났고 조금 더 수려한 웹을 만들기 위해 Ajax 를 이용한 SPA 개발이 유행하기 시작하였으며, 그에 따라 DOM 을 효과적으로 다루기 위해 Jquery 가 유행을 하였습니다. 2010년대에는 웹프레임워크들의 춘추전국시대가 아니었나 생각합니다. Nodejs 의 탄생에 힘입어 보다 훌륭한 웹개발도구 및 Angular, React, Vue, Svelte 등 프레임워크들이 나타났습니다. 물론 아직도 그 전쟁은 아직도 진행형인 것 같습니다.

이후 10년은 어떤 기술들이 유행하게 될까요. 저도 관심을 가지고 함께 지켜보도록 하겠습니다. 🙂