TypeScript는 어떻게 공부해야 하나요?

“TypeScript를 꼭 해야 하나요?”

프롤로그 지금 현재 개발하는 상황을 보면 TypeScript 는 피할 수 없는 하나의 대세가 된 것 같습니다. TypeScript가 나온 이후로 점점 TypeScript로 만들어지고 있는 라이브러리나 코드의 비중은 높아지고 있고 아직도 상승 중입니다.

초기 자바스크립트 같은 경우에는 애초에 이렇게 웹이 커질 거라고 생각하지 않았기에 단순한 형태의 간단한 스크립팅 언어로 만들려고 했습니다. 그래서 대부분 짧은 형태의 간단한 코드들로 이루어질 거라고 생각했었습니다. 그러다 보니 최대한 간단하게 만들기 위해서 언어의 복잡도를 최소화하는 방향으로 구성하게 되었습니다. 그러면서 러닝 커브를 낮추기 위해 당시에 가장 유행하고 있던 C++, Java의 문법을 빌려오는 방법으로 구상이 되었습니다.

그래서 Java계열 문법을 차용하면서도 type을 제거하고 class와 같은 복잡성을 야기하는 부분들도 전부 제거하여 간결한 문법을 가지면서도 타입 없이 객체지향도 함수형 프로그래밍도 할 수 있는 prototype 객체 기반 함수형 동적 타입 스크립트 라는 아주 독특한 컨셉의 언어 가 만들어졌습니다.

그 당시 정통 언어(?)를 하던 개발자들이 보기에는 JavaScript는 아주 형편없는 언어였습니다만, 웹 산업의 발전이 급격하게 발전하면서 자바스크립트는 웹 개발의 필수 언어가 되다 보니 강제적으로 성장을 할 수밖에 없었습니다. 그래서 JavaScript를 Java처럼 만들기 위한 노력이나 JavaScript을 Python처럼 만들기 위한 Coffeescript 등 아니면 JavaScript를 쓰더라도 class처럼 개발하기 위한 수많은 라이브러리들과 JavaScript를 대체하기 위한 언어의 개발은 꾸준히 있어 왔습니다.

(출처: State of JS)

이러한 모든 시도들은 결국 성공하지 못했지만 TypeScript는 그걸 해내고 말았습니다. 과연 TypeScript는 어떠한 언어이고 현재 TypeScript는 어떤 위치인지, TypeScript를 배우거나 사용하기 위해서는 어떻게 접근을 하면 좋을지 한번 이야기해 보고자 합니다.

ECMASCRIPT 4는 왜 없을까?

ES3, ES5, ES6, ES7... 응..!? ES4는 왜 없나요?

우리가 사용하는 JavaScript의 사양이 되는 ECMAScript는 ES3, ES5, ES6,... ES4가 없다는 사실을 알고 있었나요?

무려 20년도 더 전인 1999년부터 2008년까지 JavaScript를 좀 언어다운 언어로 업그레이드를 해보자는 프로젝트가 진행되었습니다. 그래서 JavaScript에 class, 정적 타이핑, 인터페이스, 제네릭 등 JavaScript에 당시에 사용하던 다른 언어의 개념들을 넣기 위한 논의가 시작되었습니다.

이렇게 정상적인(?) 언어로 다시 탄생할 뻔했던 JavaScript는 여러 가지 이해관계자들이 모여서 각자의 이해관계를 논의하게 되면서, prototype과 함수기반의 체계를 이미 가진 언어에서 class와 정적 타입 기반의 언어로 체계를 바꾸는 것은 너무 많은 변화와 하위 호환성 유지의 어려움을 지적받게 됩니다. 결국 JavaScript의 체계를 유지하면서 조금씩 고쳐나가자며 방향 을 틀게 되었습니다.

ECMAScript 4 뒷얘기

궁금하면 한번 읽어 보세요 :)

이 사양은 결국 2008년 정식으로 폐기가 되었지만 ECMAScript4를 그대로 이어받아서 Flash의 ActionScript3도 만들어지고 이때 논의되었던 내용들을 계기로 여전히 자바스크립트를 좀 다른 언어로 바꿔야겠다는 시도가 끊임없이 일어나게 됩니다.

그 당시 OOP 패러다임이 지배하고 있던 세상에서 만들어진 JavaScript에 OOP를 도입하기 위한 라이브러리 들은 여전히 시도되고 있으며, JavaScript의 부족한 문법을 개선 하고자 조금 더 Python 스럽게 만들어 보고자 했던 Coffeescript 가 한때 인기를 끌었습니다. (이러한 Coffeescript의 인기로 인해 Arrow Function이나 구조 분해 할당, Template Literal 같은 문법들이 ES6에서 표준이 되기도 합니다.)

이후 Babel 이 등장을 하게 되면서 여러 가지 문법적인 개선 시도 를 하게 되어 Decorator나 Optional Chaining, Nullish 등 여러 가지 문법적인 개선이 시도되고 그중 호응을 얻었던 것들은 Native에 편입이 되는 식으로 JavaScript가 발전하게 됩니다.

JavaScript를 바꾸고 싶다는 열망과 시도들은 굉장히 많았으나, 결국 JavaScript가 살아남고 현재의 모습을 하고 있는 것은 prototype 객체 기반 함수형 동적 타입 스크립트 라는 당시에는 이 괴상한 조합이 알고 봤더니 굉장히 쓸만하다는 것 에 대한 합의 때문입니다. 실제로 객체지향에 함수형 프로그래밍 컨셉을 얹은 이 방식은 Java에서 파생된 Kotlin 같은 언어에 일부 도입이 될 만큼 유용한 구조였습니다.

결국 모두의 힘이 모여 JavaScript는 체계는 유지하되 문법을 지속적으로 개선하는 방향으로 성장 을 하면서 사람들이 많이 쓰고 또 사랑하는 언어가 되었습니다. 그렇지만 웹에서 대규모의 엔터프라이즈급의 서비스들이 등장하면서 사람들은 JavaScript의 체계에서 아쉬운 점을 하나 발견하게 됩니다.

그렇습니다. 그것은 바로 Static Typing 입니다. 최근에 끝났던 State of JS 2021에서도 자바스크립트에서 가장 부족한 점, 가장 먼저 개선돼야 될 과제에서 첫 번째로 꼽혔던 게 바로 이 Static Typing 이었죠.

(출처: State of JS)

JavaScript는 타입이 없기에 문법이 단순하며, Dictionary와 Object를 하나로 통합해서 객체를 다루듯이 데이터를 다룰 수 있고 Prototype을 통해 동적으로 타입을 변경할 수도 있고 메소드를 동적으로 교체를 할 수 있으며 Duck Typing을 통해서 굉장히 유연한 체계를 가진다는 장점이 있었습니다.

하지만 이 장점은 프로그램의 사이즈가 작고 이러한 이점을 잘 사용할 수 있는 라이브러리들에는 아주 유용했지만, 대규모의 협업을 하기 위해 이미 만들어진 스키마 위에서 작업을 하는 과정에서 자잘한 오타로 인한 에러가 발생되었습니다. 무엇보다 그 에러는 바로 확인되는 게 아니었기에, 실행하면서 런타임이 되어서야 에러를 발견할 수 있다는 치명적인 문제 는 생산성의 큰 저하를 가져왔습니다.

이러한 연유로 기존 JavaScript의 동적 타입 체계를 완전히 뒤엎어 기존의 타입을 통해 컴파일이 메모리 사용에 대한 최적화를 할 수 있는 언어로 바꾸는 것은 아니지만, 정적 타입 언어의 장점인 빌드 전에 미리 오류를 검증할 수 있다는 장점만 합치는 방향 으로 발전을 하게 됩니다.

MS: 내가 원래 개발언어와 IDE 개발의 원조지! JavaScript를 ECMAScript4의 형태로 가장 만들고 싶어했던 벤더는 Microsoft 였습니다. 이미 C++, C# 등의 언어를 만들어서 성공했던 경험이 있을뿐더러 Visual Studio 등을 통해서 IDE를 이용한 수익이나 개발 관련해서 영향력을 행사하고 있었기 때문입니다. 마이크로소프트가 IE를 통해서 웹에 대한 주도권을 가지고 있었으나 점차 방만한 업데이트를 하고 웹에 대해서 큰 투자를 하지 않는 동안 브라우저 엔진은 Safari가, JavaScript v8엔진은 구글이 가장 많이 사용되고 있는 웹 프레임워크인 React는 페이스북이 가져가며 마이크로소프트는 점점 웹에 대한 주도권에서 멀어지고 있었습니다.

이제 다시 정신을 차리고 다시 웹 쪽으로 눈을 돌린 마이크로소프트가 보기에 남아있는 부분이 어딜까 고심하다 보니, 원래 마이크로소프트가 잘하는 언어와 IDE를 만드는 쪽의 노하우를 통해서 웹 쪽 영향력을 다시 영향력을 행사하고자 하는 욕심이 있었을 거라고 생각합니다.

마이크로소프트웨어도 주류가 되어버린 웹으로 오게 되면서 기존에 만들었던 핵심 애플리케이션인 오피스와 함께 Visual Studio를 웹으로 옮기려는 시도를 하게 되고 우리가 너무나 잘 쓰고 있는 VSCode가 탄생하게 됩니다. 기존 Visual Studio에서의 가장 큰 강점이라고 하면 정적 언어에 대한 AutoComplete와 다양한 보조도구들이었는데 JavaScript는 기존의 언어와는 결이 맞지 않았습니다.

그리하여 자기들이 가지고 있는 언어인 c#과 유사한 형태로 언어를 만들되 기존의 언어를 바꾸는 시도가 모두 실패했다는 것을 거울삼아 JavaScript를 버리고 새로운 언어를 배워야만 하는 게 아니라 JavaScript의 원형을 그대로 살리면서 본인들의 IDE에서 제대로 동작할 수 있도록 하기 위한 언어를 만들어내기 시작합니다.

모든 CSS가 Sass이듯이 그리하여 모든 JavaScript는 TypeScript다라는 superset이라는 컨셉으로 기존의 JavaScript는 TypeScript엔진에서도 돌아가게 만드는 방법을 택했고 이 방식은 아시다시피 상당히 유효했습니다.

굳이 타입 스크립트를 해야 하나요? 님? 왜 타입 스크립트 안 함? (출처: 트위터 @Mark Dalgleish)

이제는 자바스크립트로 개발을 하고 있다면 주위에서 항상 듣는 소리가 있습니다. "왜 타입 스크립트를 안 써요?" "타입 스크립트 좋아요~ 써볼 생각 없어요?" 물론 자바스크립트에서 타입 스크립트로 굳이 넘어가야 할 이유가 있는가? 에 대해서 사람들이 얘기하는 타입 스크립트의 단점들에 대한 이야기를 먼저 한번 짚고 넘어가 봅시다!

TypeScript의 고질적인 문제 1: 속도! TypeScript의 고질적인 문제는 tsc의 속도가 엄청나게 느리다는 점입니다. tsc로 타입 체크를 하고 한번 빌드를 하기 위해서는 적지 않은 시간이 필요합니다. 프로그래밍의 덩치가 크면 클수록 그 시간은 엄청나죠. 빌드와 배포가 느려진다는 것은 그만큼 생산성을 까먹는 일이기도 합니다. 그러다 보면 TypeScript가 좋은 건 알겠지만 굳이 필요한가 라는 생각을 하게 됩니다.

그래서 TypeScript에서는 이러한 속도의 문제를 해결하기 위해서 IDE에서는 백그라운드에서 체크를 하고 실제 빌드 시에는 타입 체크를 하지 않고 빌드를 하는 묘수를 생각해내게 됩니다.

Babel와 TypeScript와의 아름다운 결합 TypeScript는 결국 JavaScript를 만들어내는 도구입니다. 정적 타입은 유효성 체크일 뿐 타입이 맞지 않다고 해서 JavaScript로써 동작을 하지 않는 것은 아닙니다. TypeScript는 Babel과 손을 잡고 Babel의 Parser에 TypeScript를 지원하게 하고 Babel에서는 TypeScript의 문법만 제거해서 JavaScript로 만들어 주는 플러그인 개발을 성공합니다.

그래서 tsc로 컴파일을 하지 않고서 그냥 TypeScript를 JavaScript로 만들고 번들 툴을 이용해서 빌드하는 방식을 통해서 빌드 속도를 대폭 올릴 수 있게 되었습니다.

100배나 빠른 빌드 도구 esbuild! 그 이후로는 esbuild가 나오면서 TypeScript의 속도 문제는 어디상 문제의 영역이 되지 않게 되었습니다. JavaScript가 아닌 Go 언어로 만들어져서 스크립트가 아니라 native방식으로 동작하는 esbuild은 기존 번들 툴의 100배나 빠른 속도를 자랑합니다.

이로 인해서 타입 스크립트로 빌드하는 과정에서 속도의 문제로 인해 성능이 저하되는 대신 타입 유효성 검사와 AutoComplete를 지원한다는 트레이드오프에서 속도는 더 이상 기회비용이 아니게 되었습니다.

TypeScript의 고질적인 문제 2: 잘 동작하던 건데 전부 에러가 뜨데요? TypeScript의 대중화가 덜 된 시절에는 타입이 지정되어 있지 않은 라이브러리들이나 타입 스크립트에서 지원하지 않는 동적 타이핑을 통해서 만들어진 기법들로 인해서, 타입선언이 되어 있지 않은 라이브러리들을 쓰면 계속 빨간 에러 표시와 함께 해야 하는 것들이 스트레스였습니다. 그리고 이러한 에러를 수정하기 위해서 타입에 any를 선언하게 됩니다. 이러한 불합리함(?)들은 TypeScript의 효용성에 대한 인식을 낮추게 하며 수많은 any meme들이 생겨나기 시작합니다.

그때는 그랬지만 지금은 아닙니다. (출처: DEVS.LOL)

TypeScript가 완전히 대중화가 된 지금 대부분 사용하던 라이브러리가 TypeScript로 작성이 되어 있고 그렇지 않은 경우도 많은 압박(?)들로 인해서 대부분 @types을 내놓거나 오픈소스로 나오고 있는 형국입니다. 반대로 대부분의 라이브러리들이 TypeScript를 가지고 재작성을 하게 되면서 오히려 JavaScript에서는 TypeScript 코드를 사용하지 못하는 불상사가 생겨 버리는 경우도 있게 되었습니다.

그러니 그냥 하세요. 안 해야 할 이유가 없습니다. “타입 유효성 체크를 가능하게 하고 강력한 AutoComplete를 제공받는 대신 복잡한 문법과 빌드 속도와 호환되지 않는 라이브러리로 인한 장단점이 있기에 선택입니다.”라고 하던 시절은 지나가버렸습니다.

지금은 JavaScript를 쓰더라도 Babel이나 번들러를 쓰지 않는다는 것은 상상하기 어렵습니다. 최신 문법은 사용해야 하면서 하위 버전에 맞는 트랜스 파일과 모듈을 이용한 번들러는 필수입니다.

“그렇다면 왜 굳이 Babel을 쓰나요? TypeScript를 쓰면 되죠.” TypeScript는 JavaScript의 모든 문법을 포함하고 있기 때문에 굳이 TypeScript를 쓰지 않고 JavaScript라고 생각하고 써도 아무런 문제가 없습니다. 이 점이 TypeScript의 가장 강력한 점이지요. 이미 JavaScript를 하고 있다면 곧 TypeScript를 할 수 있다는 것입니다. 오히려 TypeScript를 하지 않으면 JavaScript에서는 TypeScript 생태계로 돌아가는 환경을 돌릴 수가 없습니다. 그러니 아직 TypeScript를 쓰고 있지 않다면 일단은 한번 시작해보는 것은 어떨까요?

타입 스크립트를 대하는 마음가짐과 자주 하는 오해 TypeScript를 시작하기 어려워하는 사람들이 많습니다. 아니면 굳이 필요 없다고 하는 사람들도 있습니다. TypeScript를 하는 것은 기존의 JavaScript보다 생산성이 떨어질 거라고 생각하는 사람들도 있습니다. 그런 적도 있었지만 지금은 아닙니다. TypeScript를 대한 오해와 어떤 마음 가짐으로 학습을 하면 좋을지 이야기해봅시다.

TypeScript에 대한 자주 하는 오해 3가지

오해 1. 타입 스크립트는 정적 타입의 새로운 언어기에 러닝 커브가 높다.

오해 2. 타입 스크립트를 하면 class와 객체지향 프로그래밍을 해야 한다.

오해 3. 타입 스크립트를 하면 협업은 좋으나 당장의 생산성은 떨어진다.

잊지 마세요. TypeScript는 JavaScript의 슈퍼셋입니다. (출처: meme-arsenal)

TypeScript는 JavaScript에 조금 더 문법이 추가된 언어입니다. JavaScript가 ES3, ES5, ES6처럼 조금씩 새로운 문법이 추가되듯이 그냥 JavaScript에 조금 더 문법이 추가된 언어일 뿐입니다. 그 새로운 문법을 반드시 써야 할 필요도 없습니다. TypeScript는 전혀 새로운 언어가 아닙니다. 또한 Type과 Class를 이용한 전통적인 객체지향 프로그래밍을 하기 위해서 만들어진 언어도 아닙니다.

TypeScript를 JavaScript처럼 써도 TypeScript는 여전히 잘 동작할 것입니다. TypeScript는 물론 배워야 할 것이 있지만 그 모든 것을 배워야만 쓸 수 있는 것이 아니라 내가 JavaScript를 안다면 당장이라도 사용할 수가 있는 언어입니다. 필요할 때 필요한 만큼만 배우면 되기에 러닝 커브가 높아도 도입을 막는 허들은 되지 않습니다.

타입 스크립트는 그저 자바스크립트의 자동완성 도구일 뿐이다. (출처: imgflip.com)

‘TypeScript를 배운다.’라고 하는 개념은 새로운 언어를 배우는 것이 아닙니다. OOP를 할 필요도 없습니다. 언어의 형태는 아주 유사하고 TypeScript를 Java, C# 등에 빗대어 OOP로 풀어가려는 시도도 물론 있습니다.

하지만 TypeScript는 그러한 객체지향 정적 컴파일 언어와는 결이 다릅니다. TypeScript는 JavaScript이기에 JavaScript답게 prototype 객체 기반 함수형 동적 타입 스크립트 처럼 개발을 하고 타입 검사 + AutoComplete 가 문법적으로 추가된 개념이라고 생각해주세요. TypeScript를 처음 쓰면 놀랄 만큼의 자동완성 기능에 다시 JavaScript로 돌아가기 싫어질 겁니다.

에러가 신경 쓰이면 차라리 strict를 꺼두자. any는 쓰지 마세요!

처음 타입 스크립트를 쓰게 되면 잘 모르는데 빨간색 에러들이 엄청 거슬리고 무작정 해당 에러를 막기 위해서 타입들을 붙이고 코드를 수정하다 보면 왜 이렇게 해야 하는지 힘이 들 때가 있습니다. 그렇게 ‘@ts-ignore’과 ‘any’를 찾게 되고 Type이 덕지덕지 붙은 코드가 만들어지면서 TypeScript 무용론을 외치게 됩니다.

처음이라 잘 모르겠다면 무수히 많은 에러를 메꾸기 위해서 any를 남발하지 말고... 억지로 Type을 붙이지 말고 그냥 strict와 lint를 잠시 꺼두길 바랍니다. 나의 기존의 개발경험을 무너뜨리지 말고 그냥 필요할 때 조금씩 자동완성 도구 같이 꺼내어 쓰기를 바랍니다.

타입 스크립트 학습 로드맵 TypeScript 그러면 어떻게 시작하고 어떻게 공부를 하면 좋을까요?

일단 가급적 세팅이 되어 있는 프로젝트로 시작하세요. 우선 TypeScript를 맨땅에서 세팅하려고 하지는 마세요. 이미 너무너무 좋은 세팅들과 변환 도구들이 나와있습니다. tsconfig의 옵션은 방대하며 하나하나 이해하려고 했다가는 시작하기도 전에 진이 빠질 수 있습니다. 앞서 배운 마음가짐으로 내 개발경험을 해지치 않고 조금 더 편하게 개발해주는 플러그인이라는 생각으로 접근을 해야 합니다.

그러니 일단 그냥 시작하는 것이 중요합니다. 현재 기준으로 초기 세팅을 추천하자면 Vite나 tsup을 추천합니다.

Vite npm(tsup)

변수 선언과 함수 인자부터 일단 JavaScript를 쓰듯이 한번 사용해보세요. 그리고 처음에는 변수 선언과 함수 인자에 타입을 넣는 것 으로 시작합니다.

let name:string = "teo.yu" let age:number = NaN let isFrontEnd:boolean = true let favorites:string[] = ["svelte", "rxjs", "vite", "adorableCSS"] const doBest = (params:string) => { }

이렇게 한번 변수로 선언을 해두는 순간 자동완성의 수준이 JavaScript 때와는 엄청 쉬워진다는 것을 알 수 있습니다.

. 을 한 번만 눌러보세요! 이렇게 필요에 의해서 조금씩 타입을 선언해보시면 됩니다. 처음에는 number, string, boolen과 같은 기본 타입, Array와 함께 선언을 할 줄 알면 됩니다. 이후 함수 인자 의 경우 구조 분해 와 결합하여 타입을 지정하는 법까지 익혀둔다면 거의 대부분의 TypeScript에서 필요한 것들을 할 수 있게 됩니다.

하지만 타입 선언보다는 가급적 자동 추론을 사용하자. let bad:number = 10 let good = 10

TypeScript는 자동 추론 이라는 멋진 기능이 있습니다. 굳이 쓰지 않아도 당연히 이 자리에는 이 타입이라고 알 수 있는 것은 TypeScript는 멋지게 추론을 합니다. 가능하면 Type을 적게 적으려고 해 보세요. 자동 추론을 하고 있다면 굳이 Type을 중복되게 적어서 2번 수정을 해야 하는 경우를 피해봅시다.

백엔드 스키마 interface를 만드는 것을 연습해보자. 프론트엔드 개발에 빼놓을 수 없는 백엔드 API 연동 시에 TypeScript는 빛을 발합니다. Network를 통해서 스키마를 확인하고 어떤 필드에 어떤 내용들이 담겨 있었는지 매번 값을 보고 확인해야 했지만 TypeScript로 interface를 만들어둔다면 강력한 자동완성과 함께 훨씬 스키마를 이해하기 편해집니다.

intercae User { id:string name:string age:number email:string } const getUser(id:string):Promise { ... }

Axios나 React-Query 혹은 Fetch등과 함께 Response에 interface를 연결하는 작업을 한번 해보고 나면 타입을 외부에서 선언을 해주는 제네릭 이라는 개념을 함께 알게 됩니다. 깊은 것은 아직 몰라도 됩니다. 표기를 통해서 적절히 Promise등에 타입을 명시할 수 있다는 개념을 이해하게 되면 Record 등을 통해서 조금 더 복잡한 구조의 타입도 정의하는 방법을 알게 됩니다.

언제까지나 Type은 보조하기 위한 수단이며 편의성을 위해 쓰는 것임을 잊지 마세요. Type이 맞는지 interface가 맞는지 어떤 식으로 작성을 해야 좋은지는 지금은 생각하지 않아도 됩니다.

Callback을 인자로 만드는 방법을 공부하자 이렇게 Type 등을 선언해 나가다 보면 복잡한 Callback을 선언해야 할 일이 생깁니다. Callback의 Type선언은 다 적고 나면 복잡해 보이는데 하나씩 적어 나가면 금방 적응할 수 있습니다. 헷갈린다면 별도의 Type으로 빼두고 작성하고 다시 끼워 넣어 보는 식으로 Callback Type을 선언하는 법을 배워나가 보세요.

축하합니다! 여기까지 오셨다면 TypeScript 초급은 이제 끝났습니다. 여기까지 왔다면 이제 JavaScript로 돌아가기 힘들 만큼 편하다는 것을 느꼈을 거예요.

유틸리티를 사용하는 법 TypeScript의 중급으로 넘어가는 관문은 복잡한 경우의 수에 대한 타입들입니다. 발생이 빈번하지 않지만 경우의 수가 한 가지만 있지 않는 상황들입니다. 대표적인 예가 바로 null와 object를 함께 쓰는 경우입니다.

interface User { name:string age:number } let selectedUser:User|null = null // 선택된 항목은 있을 수도 있고 없을 수도 있다.

JavaScript는 동적 타입의 언어이며 TypeScript는 JavaScript의 체계를 거스르는 것은 아니라고 말했는데요. JavaScript의 동적 타입의 여러 가지 경우에 대응을 할 수 있도록 TypeScript는 여러 가지 문법적인 내용들을 추가했습니다.

대부분의 경우에 대해 TypeScript는 Type을 정의받을 수 있는 방법들을 제공하고 있습니다. 위와 같이 여러 가지 타입을 가지고 있는 경우에는 다시 원하는 하나의 Type로도 다시 변경하는 방법들 이 존재합니다.

selectedUser.doSomthing() // null일수도 있기 때문에 TypeScript는 에러라고 표기한다! // 이렇게 조건문을 걸어 주면 TypeScript가 null이 아니라고 판단을 스스로 해서 User로 취급해준다. if (!selectedUser) { selectedUser.doSomthing() }

공식문서에 다 있지만 차근차근 공부는 안 해도 된다. TypeScript 사이트는 공식문서 가 엄청 친절한 편이며 로드맵이 나쁘지 않게 되어 있습니다. 다만 양이 워낙 방대하다 보니 어디까지 공부해야 할지 엄두가 안 나고 무수히 쏟아내는 에러에 압도되어 TypeScript를 힘들어하는 것 같아요.

공식문서는 빠르게 한번 어떤 것들이 있는지 정도만 훑어보세요. 거듭 말하지만, JavaScript에 AutoComplete + Type 검사용 플러그인 이라는 생각으로 그때그때 필요한 것들만 찾아서 살펴보는 방식으로 접근을 하시기 바랍니다.

이제는 Error를 Zero로 만들어 볼 시간! 에러가 나더라도 적당히 TypeScript를 통해서 Type을 붙여보면서 여기까지 왔다면 이제는 Error를 0으로 만들어 볼 도전을 하실 수 있습니다.

strict도 true로 세팅하고 어떤 식으로든 Type을 정리할 수 있을 거라는 마인드로 해결해나가 보시기 바랍니다. as나 any, 괜히 복잡해 보이는 형태로 코드가 만들어졌다면 잘못된 방식입니다. 원래 작성하려고 했던 JavaScript의 모양에서 이게 정말 최소한의 형태인가 생각하면서 에러를 잡아나가다 보면 TypeScript를 정말 편한 도구로 활용하시게 되고 이제 훨씬 더 Clean 한 코드를 작성하실 수 있게 될 겁니다.

끝으로… 최대한 간단한 언어로 만들기 위해서 태어났기에 기존과는 다른 체계를 가진 매력적인 언어인 JavaScript, 갓 태어났을 때에는 갖춰야 할 것들을 못 갖춘 언어로 취급을 받았기에 JavaScript를 바꾸려는 시도는 끊임없이 있었습니다. 하지만 JavaScript의 매력은 prototype 객체 기반 함수형 동적 타입 스크립트 라는 컨셉이었기에 JavaScript는 사랑받는 언어로 성장하기 시작했습니다. 그러나 엔터프라이즈급 개발 환경에서 에러를 확인하거나 협업함에 있어 다소 불편한 점이 많은 언어였습니다.

JavaScript의 가치를 그대로 유지한 채 Type검사와 AutoComplete의 엔터프라이즈 협업을 위해서 꼭 필요한 기능이 탑재된 형태의 TypeScript는, 이제 웹 개발 엔터프라이즈 씬에서는 완전히 주류 언어가 되어버렸습니다. JavaScript를 그대로 쓸 수 있으면서 Type체크와 협업을 도와주는 형태의 컨셉 은 기존 JavaScript 생태계를 그대로 흡수하는 결과를 가져왔습니다. 반대로 JavaScript로는 TypeScript의 생태계를 사용할 수가 없다는 문제도 더해졌기에 많은 수의 라이브러리들이 TypeScript로 다시 작성되고 있습니다.

또한 속도와 도입에 따른 번거로움의 장벽도 esbuild와 같은 Native기술의 도움으로 극복이 되고 있습니다. TypeScript 역시 Native기술을 이용해서 tsc를 다시 개발하고 있고요. 이제 웹을 한다면 TypeScript를 하지 않아야 할 이유가 없기에 트레이드오프를 따지기보다는 TypeScript를 당장이라도 시작하기를 권합니다.

그러나 TypeScript에 대한 이해가 부족한 채로 무작정 시작을 했다가는 TypeScript가 내뱉은 에러 앞에 내 코드를 이리저리 바꾸면서 불평과 불만을 쏟아내게 될 것이고 tsc를 그대로 썼다가 한없이 오래 걸리는 빌드 시간으로 인해서 TypeScript의 효용가치를 잘 못 느낄 수도 있습니다.

OOP를 더 좋아하는 사람들이 드디어 웹에서도 OOP를 할 수 있다며 TypeScript로 내놓는 여러 가지 TypeScript기반 OOP 관련 내용들로 인해 OOP를 해야만 할 것 같아, ‘JavaScript의 개발경험을 바꿔야 하는 건 아닌가.’ 하는 우려도 있을 수 있습니다.

TypeScript를 공부한다는 것은 작정하고 Type을 기반한 class와 OOP를 다루는 것이 아닙니다. 장황한 tsconfig를 습득하거나 여러 가지 Type을 정의하는 것을 미리 배워둘 필요도 없습니다. 미리 세팅되어 있는 Vite나 tsup으로 시작하고 기존의 개발 경험 그대로 개발을 하셔도 무방합니다.

Typescript는 그저 타입체크와 자동완성을 도와주는 플러그인 이라는 마인드로 접근을 한다면 정말 Typescript의 장점만 이용하면서 부드럽게 도입을 할 수 있을 거라고 생각합니다.

(출처: imgflip.com)

TypeScript도 주류에서 밀려나게 될지 모릅니다. 하지만 투표를 통해 JavaScript에서 가장 개선되어야 생각하는 것이 Static Type 으로 꼽힌 만큼, 많이 쓰이는 것들이 결국 새로운 표준이 될지도 모르겠습니다. ‘언젠가는 TypeScript 해봐야지...’라고 생각하셨다면, 아직도 하고 있지 않다면, 그냥 오늘 한번 설치해보고 그냥 TypeScript로 개발을 바로 해보는 것은 어떨까요?

TypeScript는 JavaScript의 슈퍼셋이며 그저 Type체킹과 자동완성을 도와주는 하나의 플러그인이라고 여기고 그냥 시작해보세요. 그러면 어느 순간 TypeScript에서 다시 JavaScript로 돌아오기 쉽지 않으실 겁니다.