언제부턴가 많은 기업에서 자바스크립트 대신 타입스크립트를 사용하고 있습니다.
도대체 왜 그런 걸까요? 타입스크립트가 나온 배경을 알아보기 위해선 자바스크립트가 어떤 불편함이 있었는지를 알 수 있으면 쉽게 알 수 있을 것이라고 생각합니다. 아무래도 자바스크립트의 문제점을 해결하기 위해 나온 게 타입스크립트이기 때문입니다. 그렇다면, 자바스크립트가 어떤 불편함이 있었길래 상위집합인 정적 타입을 제공하는 타입스크립트를 사용하는 걸까요?
인터프리터 언어 vs 컴파일 언어
자바스크립트는 동적 타입 언어이며, 인터프리터 언어이고 타입스크립트는 정적 타입 언어이며, 컴파일 언어입니다.
여기서 잠깐! 인터프리터 언어와 컴파일 언어를 간단히 알아보고 갑시다.
인터프리터와 컴파일러는 한마디로 번역가라고 생각하면 좋습니다. 하지만, 두 번역가는 성질이 다릅니다. 밑에 예시와 함께 설명을 하겠습니다.
인터프리터는 미리 번역을 하지 않고 즉시 번역을 하는 MBTI ‘P’ 번역가라고 생각하면 좋습니다. 정리하자면, 프로그램 실행 시 한 번에 한 문장씩 번역하기 때문에 사전에 에러를 방지 못하고 동작하는 순간에 에러를 발견할 수 있습니다.
컴파일러 언어는 반대겠죠?? 미리 번역을 해놓는 꼼꼼한 MBTI ‘T’ 번역가라고 생각하면 좋습니다. 정리하자면, 프로그램을 실행하기 전에 미리 전체를 번역하여 사전에 에러를 발견하여 수정할 수 있습니다.
인터프리터와 컴파일러의 자세한 내용은 요기에 들어가서 볼 수 있습니다!
여기서 중요한 건 동적 타입 언어 보다 정적 타입 언어가 더 우수해서 자바스크립트를 사용하지 않고 타입스크립트를 사용하는 게 아닙니다! 이건 개발자가 추구하는 방향 혹은 프로젝트 단위에 따라 장단점이 있다고 생각합니다.
그럼에도 불구하고 자바스크립트 대신 타입스크립트를 많이 사용하는 이유는 시스템이 복잡해질수록 동적 타입 언어는 에러 검출이 어려워지지만, 정적 타입 언어는 에러 검출에 보다 더 용이하기 때문이라고 생각합니다.
그렇다면? 왜 다른 정적 타입 언어를 사용하면 안 되는 건가? 왜 타입스크립트여야 하는 걸까요?
자바스크립트의 상위 집합 타입스크립트
타입스크립트를 사용하기 전에는 Elm, Reason, PureScript 등 정적 타입 언어를 시도한 경우도 있었지만, 자바스크립트와는 상당히 다른 문법을 갖고 있었습니다.
그럼, 자바, PHP, 씨언어를 사용해서 구현하면 되지 않나요 할 수 있겠지만 자바나 PHP는 서버사이드라고 하는 서버에서 HTML 코드를 완성시켜 주는 작업은 가능하지만 사용자의 웹브라우저에서 렌더링 시킬 수는 없습니다.
위와 같은 이유들로 하여금, 자바스크립트가 웹에서 지배적으로 사용되는 이유입니다. 자바스크립트는 웹개발을 할 때, 서버 사이드 렌더링뿐만 아니라 클라이언트 사이드 렌더링도 제공하기 때문입니다.
여기서 잠깐! 서버 사이드 렌더링과 클라이언트 사이드 렌더링이란?
클라이언트 사이드 렌더링이란 사용자의 웹브라우저에서 서버에서 받은 데이터를 통해 화면을 그려주게 됩니다. 즉, 데이터를 가져올 경우에만 서버와 통신을 합니다.
서버 사이드 렌더링은 웹브라우저에서 화면을 그리지 않고 서버에서 다 만들어주고 브라우저에게 보내주게 됩니다. 서버 사이드 렌더링은 화면을 다 만들어서 브라우저에게 보내주기 때문에, SEO 최적화를 보다 쉽게 할 수 있다는 장점이 있습니다. 단, 페이지 이동할 때마다, 서버와 통신을 하여 서버의 부하가 많아집니다.
자바스크립트가 웹에서 많이 사용되기 때문에, 다른 문법을 갖고 있는 언어들로 마이그레이션을 하기에는 너무 많은 비용이 든다는 단점을 갖고 있고, 자바스크립트 개발자들이 또 다른 언어를 배워야 하는 문제가 있습니다.
하지만! 타입스크립트 같은 경우에는 자바스크립트의 생태계를 포용하고 있어, 자바스크립트의 모든 코드는 타입스크립트의 코드이기도 합니다. 그렇기 때문에, 타입스크립트 컴파일러는 확장자만 바꾸면, 심지어는 특정 옵션을 실행시킨다면 확장자를 바꾸지 않고도 자바스크립트를 이해할 수 있어 위에서 말씀드렸던 단점들이 장점이 될 수 있습니다.
객체 지향 개발 OOP를 보다 원활하게 할 수 있다.
추상클래스
자바스크립트에서는 추상클래스를 제공하지 않습니다. 물론, 추상클래스를 비슷하게는 구현이 가능합니다. 추상 클래스는 자체 인스턴스를 만들 수 없고, 선언한 함수를 반드시 오버라이딩을 해야 하기 때문에 아래와 같이 코드를 구현해야 합니다.
class Card {
constructor() {
if (this.constructor === Card) {
throw new Error('추상클래스는 인스턴스화 할 수 없습니다.');
}
}
pay() {
throw new Error('추상 메소드는 꼭 오버라이딩 되어야 합니다.');
}
}
위와 같이 만들게 되면, 얼추 추상클래스와 같이 만들 수 있습니다. 하지만, 위에서 발생하는 에러는 마찬가지로 실행하게 되면 생기기 때문에 개발 당시에 잘 못 개발하면 에러를 감지할 수 없기 때문에 추상클래스의 의도가 맞지 않다고 생각합니다.
abstract class Person {
private name: string;
constructor (name: string) {
this.name = name;
}
get name() {
return this.name;
}
set name(name: string) {
this.name = name;
}
}
const person = new Person('탱');
하지만 타입스크립트는 위와 같이 추상클래스를 정의할 수 있습니다.
또한, 자바스크립트와는 다르게 타입스크립트는 추상클래스로 인스턴스화하면, 위와 같은 에러를 발생시키기 때문에 추상클래스의 목적과도 맞는 개발을 할 수 있게 됩니다.
인터페이스 정의가 가능하다.
객체지향에서 가장 이해하기 어렵지만, 이해하고 사용하면 이보다 더 편리한 이론이 바론 의존 역전 원칙입니다.
의존 역전 원칙이란? 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 원칙을 말합니다.
의존 역전 원칙이 굉장히 유용합니다. 예를 들어, MySQL을 사용하여 데이터를 CRUD 하는 프로그램이 어느 순간 MongoDB로 변경된다고 가정해 봅시다. 그렇게 되면 CRUD를 하는 과정이 다 변경되어야 하지만, 의존 역전 원칙을 적용하면 모듈로 따로 분리해서 만들어두고 변경만 하게 되면 쉽게 DB를 변경할 수 있습니다.
이런 유지 보수에 좋은 의존 역전 원칙을 적용하기 위해서는 인터페이스 역할이 굉장히 중요하다고 생각합니다.
하지만, 자바스크립트는 Class를 제공하지만, Interface를 제공해주지 않습니다. 물론, 비슷하게는 구현이 가능합니다.
반면, 타입스크립트는 Interface를 제공해주어 보다 편리하게 객체지향원칙을 지킬 수 있게 해 줍니다.
이외에도 타입스크립트는 타입의 유무로 인한 유지보수에 이점이 있고, 타입을 제공하다 보니 코드 에디터에서 자바스크립트는 제공되어지지 않지만 타입스크립트를 사용하면 자동완성 기능도 제공이 되어 개발도 편해지고 시간도 단축되는 다양한 이점이 있습니다.
저도 자바스크립트를 사용할 때는 뭔가 날것의 느낌이 많이 들었다면, 타입스크립트는 세련된 느낌을 많이 받았습니다. 사실상 복잡할수록 정적 타입 언어를 사용하는 게 장점이라고는 하지만, 저는 가벼운 앱 혹은 웹을 만들더라도 자바스크립트보다는 타입스크립트를 사용할 것 같습니다!