한빛출판네트워크

타입스크립트(Typescript)와의 만남은 의도한 것도, 남들보다 빨리 시작한 것도 아니었습니다. 

대다수의 신입 개발자가 정적 타입 언어로 개발을 시작하듯이 저도 학교에서 주 언어로 자바를 사용했고, 다음으로 C++을 사용했습니다. 그 당시에는 자바스크립트를 웹사이트에서 실험용으로 사용하는 조잡한 스크립트라고 얕잡아 봤습니다.

처음 자바스크립트로 만들었던 프로젝트는 <슈퍼 마리오브라더스>를 리메이크한 게임이었는데요. 순수 HTML5, CSS, 자바스크립트만 사용했습니다. 프로젝트는 다소 유치했고 대다수 개발자의 첫 번째 프로젝트처럼 정말 엉망이었습니다. 프로젝트 초기에는 낯선 자바스크립트의 유연성과 가드레일 부족을 본능적으로 싫어했습니다. 

프로젝트 끝 무렵이 되어서야 비로소 자바스크립트의 특징과 별난 점을 존중하게 되었습니다. 자바스크립트는 프로그래밍 언어로서의 유연성을 가지며 작은 함수를 조합해서 사용할 수 있었고, 페이지 로딩 후 짧은 시간 안에 사용자 브라우저에서 작동했습니다. 

그렇게 첫 번째 프로젝트를 끝내며 자바스크립트와 사랑에 빠지게 되었습니다. (가...갑자기? 네, 사랑은 갑작스럽게 찾아오는...털썩,,)

타입스트립트를 만나다

타입스크립트 같은 정적 분석(코드를 실행하지 않고도 코드를 분석하는 도구)도 처음에는 답답해 보였습니다. 자바스크립트는 매우 빠르고 유연한데, 왜 굳이 유연하지 못한 구조와 타입에 얽매여야 할까? 우리는 왜 다시 예전의 자바와 C++의 세계로 돌아가게 되었을까?

제가 예전에 구현했던 프로젝트를 다시 뒤돌아봤을 때, 오래되고 복잡한 자바스크립트 코드를 읽고 이해하는 데 거의 10분이 소요되었고 정적 분석 없이 코드를 이해하는 게 얼마나 지저분한 일인지 깨달았습니다.

그리고 코드를 정리하면서 특정한 구조가 가져다주는 이점을 발견하게 되었습니다. 그 시점부터 가능한 한 많은 정적 분석을 제 프로젝트에 추가하는 일에 매료되었습니다.

(이쯤에서 살짝 짚고 넘어가는) 타입스크립트란?

타입스크립트는 2010년대 초에 마이크로소프트 내부에서 만들어진 후 2012년에 출시 및 오픈 소스화되었습니다. 개발 책임자인 아네르스 하일스베르는 인기 있는 언어인 C#과 터보 파스칼 언어의 개발을 주도한 인물로 알려져 있습니다. 

타입스크립트는 업계와 오픈 소스 진영에서 널리 사용되는 대중적인 언어이기도 합니다. 

프런트엔드 개발자 측면에서 살펴보자면, 타입스크립트 사용을 강력하게 권장하는 앵귤러(Angular)를 포함해 개츠비(Gatsby), Next.js, 리액트(React), 스벨트(Svelte), 뷰(Vue)와 같은 모든 주요 UI 라이브러리와 프레임워크에서 타입스크립트를 지원합니다. 

백엔드 개발자 측면에서 살펴보면 Node.js개발자가 개발한 새로운 런타임인 디노(Deno)도 타입스크립트 파일을 직접 지원합니다.

타입스크립트는 종종 ‘자바스크립트의 상위 집합(superset)’ 혹은 ‘타입이 있는 자바스크립트’로 설명되곤 하는데, 이렇게 네 가지로 설명됩니다.

● 프로그래밍 언어 : 자바스크립트의 모든 구문과, 타입을 정의하고 사용하기 위한 새로운 타입스크립트 고유 구문이 포함된 언어

● 타입 검사기 : 자바스크립트 및 타입스크립트로 작성된 일련의 파일에서 생성된 모든 구성 요소(변수, 함수 등)를 이해하고, 잘못 구성된 부분을 알려주는 프로그램

● 컴파일러 : 타입 검사기를 실행하고 문제를 보고한 후 이에 대응되는 자바스크립트 코드를 생성하는 프로그램

● 언어 서비스 : 타입 검사기를 사용해 비주얼 스튜디오 코드Visual Studio Code (VS Code)와 같은 편집기에 개발자에게 유용한 유틸리티 제공법을 알려주는 프로그램

아마도 타입스크립트가 더 적은 버그로 많은 자바스크립트 코드를 작성할 수 있고(true!), 다른 사람이 이해하기 쉽게 코드를 잘 문서화한다고(true!) 들었을 겁니다. 혹은 다양한 채용 공고에서, 또는 현업에서 새로운 역할을 맡게 되면서 타입스크립트를 접했을지도 모릅니다. 

이유가 무엇이든 타입스크립트를 전혀 모르더라도 자바스크립트의 기초 개념(변수, 함수, 클로저/스코프, 클래스)을 알고 있다면, 타입스크립트 기초와 가장 중요한 기능을 숙달하는데 어려움이 없을 거예요.

저는 이제 타입스크립트를 사용한 지 거의 10년이 지났고, 이제는 그 어느 때보다 즐겨 사용하고 있습니다. 타입스크립트는 계속해서 새로운 기능이 추가되고 있고, 자바스크립트에 안전성과 구조를 제공할 때 가장 유용하게 사용할 수 있습니다.

타입스크립트에 대한 오해

타입스크립트는 자바스크립트 코드를 구조화하는 데 도움이 되지만, 타입 안정성 강화를 제외하고는 해당 구조가 어떻게 보여야 하는지에 대해서는 어떤 것도 강요하지 않습니다. (저는 이게 매우 좋은 특징이라고 생각합니다!)

타입스크립트는 특정 대상만을 위한 독단적인 프레임워크가 아닌 모든 개발자가 사용할 수 있는 프로그래밍 언어이기도 합니다. 자바스크립트에서 사용했던 아키텍처 패턴 중 무엇이든 사용해서 코드를 작성할 수 있고, 타입스크립트가 이를 지원하거든요.

타입스크립트는 클래스나 함수 사용 여부와 같은 코드 스타일 의견을 강요하지 않습니다. 앵귤러, 리액트 등의 특정 애플리케이션 프레임워크와도 연관되어 있지 않고요.

타입스크립트는 자바스크립트 작동 방식을 전혀 변경하지 않습니다. (타입스크립트 개발자들은 자바스크립트에 추가되거나 자바스크립트와 충돌할 수 있는 새로운 코드 기능을 타입스크립트에 추가하지 않기 위해 매우 열심히 노력했고, 이런 작업은 ECMA스크립트 자체에서 작업하는 기술 위원회인 TC39의 영역입니다.)

때로는 인터넷 속 익명의 개발자가 런타임에서 타입스크립트는 자바스크립트보다 느리다고 불평하는 걸 듣게 될지도 모릅겠습니다. 하지만 이 주장에는 오해의 소지가 있습니다. 

타입스크립트가 코드에 적용하는 유일한 변경 사항은 인터넷 익스플로러 11과 같이 오래된 런타임 환경을 지원하기 위해 이전 버전의 자바스크립트로 코드를 컴파일하도록 요청하는 경우입니다. 

운영 프레임워크 대다수는 타입스크립트의 컴파일러를 전혀 사용하지 않습니다. 대신 트랜스파일(transpile)을 위한 별도의 도구를 사용하고 타입스크립트는 타입 검사용으로만 사용합니다.

그러나 타입스크립트는 코드를 빌드하는 데 시간이 조금 더 걸립니다. 타입스크립트 코드는 브라우저나 Node.js와 같은 환경에서 실행되기 전에 자바스크립트로 컴파일되어야 하거든요. 

빌드 파이프라인은 대부분 성능 저하를 무시하도록 설정됩니다. 코드에서 발생할 수 있는 오류를 분석하는 느린 타입스크립트 기능은 실행 가능한 애플리케이션 코드 파일을 생성하는 것과는 분리된 채로 수행됩니다.

무엇보다 웹의 진화는 아직 끝나지 않았습니다. 타입스크립트도 마찬가지죠. 웹 커뮤니티는 타입스크립트에 버그 수정과 기능 추가를 지속적으로 요청하고 있습니다. 타입스크립트의 기본 원칙은 거의 변함이 없겠지만, 오류 메시지, 더 멋진 기능 그리고 편집기와의 통합은 시간이 지남에 따라 개선되고 있습니다.

이 글은 <러닝 타입스크립트> 도서 내용을 발췌 편집하여 작성되었습니다. 타입스크립트의 작동원리부터 발생하는 오류와 로그까지, 모범사례와 독립적인 예제로 실습하며 배우는 도서의 상세 내용은 하기 링크에서 만나볼 수 있습니다.  

 『러닝 타입스크립트』