타입스크립트 핸드북 훑어보기 [1. The Basics]

들어가며

이어서

타입스크립트 문서 훑어보기

타입스크립트 핸드북을 보면, 자바스크립트는 초기 설계에 비해 현재 매우 광범위한 목적으로 사용되고 있어, 자바스크립트 개발에 있어 규모에 맞는 관리가 어렵다고 말하고 있다.

Handbook - The TypeScript Handbook

사용자들이 가장 흔히 발생시키는 오류가 타입 오류이기에, 그것이 단순한 오타이거나 API의 낮은 이해도이더라도, 타입스크립트를 통해 자바스크립트 프로그램을 코드 실행 이전, 타입이 정확한지 검사할 수 있다고 한다.

또한, 다른 프로그래밍 언어에 대한 사용 경험이 있다면, 핸드북을 통해서 자바스크립트 구문과 타입스크립트 사용에 대해 빠르게 익힐 수 있다고 한다.

The Basics

자바스크립트의 모든 값은 저마다 다양한 동작들을 내장하고 있고, 다양한 연산을 통해 확인할 수 있다.

message.toLowerCase();

message()

위의 코드는 message의 프로퍼티인 toLowerCase에 접근하고 호출하는 것과 message를 직접 호출하는 방식이 작성되어있다.

message의 값이 무엇인지 모른다면, 어떤 값을 가지고 있는지에 따라 위 코드의 동작이 완전히 달라질 것이다.

• message는 호출 가능한가?
• toLowerCase라는 프로퍼티를 가지고 있는가?
• 만약 가진다면, toLowerCase 또한 호출 가능한다?
• 만약 두 값이 모두 호출 가능하다면, 각각이 무엇을 반환하는가?

위의 질문들은 자바스크립트 코드를 작성할 때 흔히 고민하게 되는 것들이며, 자바스크립트 사용 시, 세세한 부분들을 놓치지 않고 있기를 바래야만 한다.

만약 message가 "Hello World!"라고 해보자.

그럼, 위 코드의 첫번째 부분인 message.toLowerCase()를 실행했을 때는 우리가 원하는 결과를 얻을 수 있을 것이다. 하지만 두번째 부분인 message()는 문자열을 함수로서 호출하는 동작이므로 에러를 발생시킬 것이다. 이런 오류들을 실행 부분에서 알아차리는 것보다, 미리 방지할 수 있다면 더욱 방대한 규모의 프로젝트에서 더 효과적으로 프로그램을 작성할 수 있을것이다.

이런 측면에서, 자바스크립트는 오직 동적 타입만을 제공하기 때문에, 코드를 실행해야만 어떤 일이 벌어지는지 확인할 수 있다. 이 대안으로 타입스크립트는 정적 타입 시스템을 통해 코드가 실행되기 이전 코드에 대하여 예측을 한다.

정적 타입 검사

타입스크립트는 정적 타입 검사를 통해 우리가 작성한 프로그램에서 사용된 값들의 형태와 동작을 설명한다. 또한, 이 정보들을 활용해 프로그램이 제대로 동작하지 않을 경우에 컴파일 타임에 알려준다.

그래서 앞선 message()의 경우, message가 문자열이므로 에러가 발생한다는 것을 코드가 실행되기에 앞서 우선적으로 확인할 수 있다.

예외가 아닌 실행 실패

지금까지 런타임 오류에 대해서 다루었는데, 이것은 자바스크립트 런타임이 무언가 이상하다고 직접 우리에게 말해주는 경우에 해당한다. 이런 문제 외에도, 예기치 못한 문제가 발생했을 때의 자바스크립트의 동작은 다른 프로그래밍 언어들과 조금 다르다.

자바스크립트에는 'undefined'라는 타입이 존재한다. 이 타입으로인해 다른 프로그래밍 언어에서는 에러가 발생되어야하는 부분이 자바스크립트에서는 정상 동작 되는 경우가 빈번하게 발생한다.

const user = {
    name : "Daniel",
    age : 26,
};

user.location;

위 코드의 경우, 객체 내부에 name과 age라는 프로퍼티가 존재하고, location이라는 존재하지 않는 프로퍼티에 접근하고 있다. 만약 C++이라면, 클래스 내부에 존재하는 멤버 변수가 아닌 존재하지 않는 멤버 변수에 접근하려 한다면 에러를 발생시킬 것이다. 하지만 자바스크립트는 'undefined'를 반환하면서 이 코드를 정상적인 코드로 받아들인다.

궁극적으로, 위와 같은 자바스크립트 내에서 "유효한" 코드일지라도, 정적 타입 시스템을 통해 오류로 간주되는 경우라면 이를 알려주게 된다. 타입스크립트에서는 이를 지원하고 있다.

비록 이 시스템 때문에 자바스크립트의 고유한 언어의 표현성과 유연성이 희생될지라도, 마땅히 버그라고 간주되는 경우를 잡아내는 데에 그 목적이 있다. 사용자들이 가장 흔히 발생시키는 오류들에 오타 혹은 기본적인 논리 오류들도 포함되기 때문이다.

tsc

function greet(person, date) {
    console.log(`Hello ${person}, today is ${date}!`);
}

greet("Brendan");

타입스크립트는 컴파일을 통해 타입을 검사하게 된다. "tsc"를 통해 컴파일하게 되고, 정상 동작 시 자바스크립트 구문으로 변환된 js파일이 생성된다.

만약 자바스크립트 코드를 타입스크립트로 변환하는 경우에 대해 생각해보자면, 변환하는 과정 중 타입 검사에 의해 오류가 발생할 수도 있다. 하지만 자바스크립트 상에서는 정상적으로 동작하는 코드인데 검사하는 과정에서 오류가 발생할 이유는 없을것이다. 이 경우, 컴파일 시 --noEmitOnError 옵션을 사용해서 js파일의 수정을 제한할 수도 있다.

명시적 타입

우리는 위의 greet함수에 대한 타입 정보를 타입스크립트에게 알려주지 않았다. person과 date의 타입을 알려주기 위해 코드를 다음과 같이 수정할 수 있다.

function greet(person: string, date: Date) {
    console.log(`Hello ${person}, today is ${date.toDateString()}!`);
}

greet("Brendan");

타입을 표기함으로써, greet함수에는 string타입과 Date 타입만이 들어가게 되고, 그 외의 타입이 들어온다면 에러가 발생할 것이다.

명시적으로 타입을 표기하지 않더라도, 타입스크립트는 생략된 타입 정보를 추론할 수 있다. 따라서 모든 요소에 타입을 적어주기보다 타입스크립트가 알아서 올바른 타입을 알아낼 수 있는 부분이라면 굳이 타입을 표기하지 않는것이 가장 좋다.

엄격도

타입스크립트의 타입 검사기를 사용하는 목적은 사용자마다 다양하므로, 타입 검사는 선택적이며 가장 관대한 기준으로 이루어지게 된다. 그러나 대다수의 타입스크립트 사용자들은 타입스크립트가 최대한으로 검사를 수행해주기를 선호한다. 따라서 가능하다면, 새로 작성하는 코드에서는 항상 엄격도를 활성화 하는것이 좋다.

타입스크립트에서는 컴파일 시 온오프가 가능한 검사 엄격도 플래그가 몇 가지 존재한다. CLI에서 strict 플래그를 설정하거나, tsconfig.json에서 "strict" : true로 설정하면 모든 플래그를 동시에 활성화할 수 있다. 반드시 알아야 하는 두 가지 가장 주요한 옵션은 noImplictAny와 strictNullChecks이다.

• noImplicitAny

몇몇 경우에서 타입스크립트는 값의 타입을 추론하지 않고 가장 관대한 타입인 any로 간주한다는 사실을 기억하자. 타입을 any로 간주하는 것은 자바스크립트 상에서는 어쩌면 당연한 것이기도 하다. 하지만, any를 많이 사용하는 것은 애초에 타입스크립트를 사용하는 이유가 희미해질 수 있다. 프로그램에서 타입을 조금 더 구체적으로 사용할수록, 더 많은 유효성 검사와 도구를 만난다는 의미이며, 이는 곧 코드상에서 보다 적은 버그를 만나게 된다는 의미이다. noImplicitAny 플래그를 활성화하면 타입이 any로 추론되는 변수에 대해 오류를 발생시킨다.

• strictNullChecks

null과 undefined와 같은 값은 다른 타입의 값에 할당할 수 있는 것이 기본 동작이다. 이는 코드 작성을 쉽게 만들어주지만, 이로인해 발생하는 많은 버그들이 존재하는것도 무시할 수 없다. strictNullChecks 플래그는 null과 undefined를 보다 명시적으로 처리하며, null 및 undefined 처리를 잊었는지의 여부의 걱정을 조금 덜어줄 수 있다.