타입스크립트, 쓰는 이유가 궁금하다!

스터디를 통해 얻고 싶은 것들

• 타입이 필요한 이유에 대해 알고 싶다.
• 타입스크립트의 장점이나 단점을 명확하게 설명하고 싶다.

스터디 멤버들

• Han!
• Rosie!
• Hailey!
• Hannah!
• Jin!

++

• Special Thanks to. 테러범
• Special Thanks to. 노악

// TODO: 사진 자르기

스터디 범위

TypeScript Handbook 의 The Basic 에서 아래 항목들을 진행!

• Static-type Checking
• Non-exception Failure
• Types for Tooling

Basic

JavaScript, 실행을 해보아야만 타입을 알 수 있다

JavaScript 런타임은 코드가 실행될 때 자신이 무엇을 해야 할지 결정하기 위하여 값의 타입, 즉 해당 값이 어떤 동작과 능력을 가지고 있는지를 확인합니다.

JavaScript는 오직 동적 타입만을 제공하며, 코드를 실행해야만 어떤 일이 벌어지는지 비로소 확인할 수 있습니다.

예를 들자면 이렇습니다. 다음과 같이 message 라는 변수에 대해 두가지의 연산을 할 수 있죠. 이 코드를 실행해보기 전까지는 어떤 것이 동작할지 알 수 없습니다. message 가 함수가 아니라면 message() 는 오류를 발생시키겠지만, 그 오류를 확인할 수 있는 건 실행한 다음 뿐이죠.

message.toLowerCase();

message();

벌써 타입스크립트를 사용하는 이유 한가지를 어렴풋이 알 것 같네요. 실행 후 가 아닌 실행 전 에 검사할 수 있는 도구가 필요한겁니다. 실행 전에 어떤 타입에 대해 어떤 연산을 가능한지 검사하는 방법이 있습니다. 이것을 자바스크립트의 동적 타입(dynamic type)과 비교해서 정적 타입(static type)이라고 부릅니다.

정적 타입 검사

실행 전에 타입을 검사하자

코드가 실행되기에 앞서 타입을 검사해 주는 도구를 정적 타입 검사기라고 합니다. 정적 타입 검사를 통해 다음 그림 처럼 타입에서 불가능한 동작에 대한 오류를 확인 할 수 있게 됩니다.

오류를 확인하는 속도가 더 빨라지니 실수를 해도 빠르게 고칠 수 있게 되겠군요.

실행을 많이 하는 방법도 있습니다

이런 생각도 해볼 수 있습니다. JavaScript 에서 실행을 더 자주하면 될 것 이다! 맞습니다. 테스트 코드가 하나의 대안이 될 수 있습니다. 테스트 코드를 실행하면, 테스트 대상 코드를 실행하고 실행결과를 확인할 수 있습니다.

테스트 주도 개발(TDD) 방법론에서는 다음과 같이 테스트를 매우 빈번하게 실행하고 결과를 확인합니다.

• link: https://www.youtube.com/watch?v=L1dtkLeIz-M

정적 타입 검사는 반드시 좋을까요? 정적 타입 검사의 이득을 보기 위해서는 확실히 비용을 치러야 합니다. 타입 명시가 제대로 되어야 하죠. 만약, 얻게 되는 이득이 오류를 빠르게 발견하는 것 뿐이라면 아직은 사용을 좀 유보해도 될 것 같습니다. 물론, 자동화 된 테스트를 실행하는 테스트 주도 개발을 한다는 전제하에서요.

예외가 아닌 실행 실패

undefined, 당신은 정체는 무엇인가요? 설마 오류?

JavaScript 런타임(실행 시점)에서 문제가 발생했을때, 처리하는 기준은 무엇일까요? ECMAScript 명세 는 오류의 처리 방식을 정해주고 있습니다.

하지만, 이런 처리 방식이 만족스럽지 못한 사람들도 존재합니다. JavaScript 런타임에서는 명백하게 오류인 상황에서 오류의 원인을 명시적으로 알기 어려운 경우가 많기 때문입니다. 예를들어, 객체에 존재하지 않는 속성에 접근할때, JavaScript 런타임에서는 오류를 발생시키지 않습니다. 단지, undefined 를 반환할 뿐입니다.

정적 타입 검사를 이용하면 이 부분에서 도움을 얻을 수 있습니다.

이외에도 논리 연산이나 오타 등을 잡는데 유용한 오류를 제공합니다.

프로그래밍 도구

올바른 것을 추천받기

앞선 내용은 정적 타입 검사를 통해 실수를 예방하는 것에 관한 것이었습니다. 하지만, 실수를 방지하기 보다 예방할 수 있으면 더욱 좋겠죠.

정적 타입 기능을 이용하면, 무엇이 잘못되었는지 알 수 있을 뿐만 아니라, 무엇이 올바른지도 알 수 있습니다. 그리고 올바른 것을 추천받을 수도 있죠.

사실 타입 스크립트에서는 추천보다 한단계 더 나아간 지원을 하고 있습니다. 타입 스크립트를 지원하는 에디터를 사용하면, 잘못된 것에 대해 quick fix 도 가능합니다. 뿐만 아니라, 변수나 함수가 정의된 곳으로 이동하는 기능도 지원할 수 있죠. 이것들이 모두 타입에 의해서 가능해집니다.

무엇을 배웠습니까?

먼저, 저는 글을 읽기전에 타입스크립트 사용에 대해 우호적인 입장이 아니었습니다. 타입을 일일히 명시해 주면서 개발하는 과정은 번거롭게 느껴졌습니다. 그냥 any 를 사용하거나, 타입없이 하고 싶은 마음이 많이 생겼었죠.

지금도 사실 자바스크립트를 테스트 워치 모드(코드 수정 시 자동으로 테스트 실행)와 함께 실행하는 것이 더 편하게 느껴집니다. 충분하다고 생각하기도 하구요.

하지만, 이 글을 읽으면서 타입스크립트의 장점에 대해서 명확하게 이해하고 설명할 수 있게 되었습니다. 앞으로 누군가에게 왜 사용하는지 혹은 사용하지 않는지에 설명한다고 하더라도 명확하게 설명하고 좋은 의사결정을 할 수 있을 것 같습니다.