타입스크립트를 왜 배워야 할까
- 오류 예방 : 컴파일 단계에서 타입을 검사하기 때문에 실행 단계에서 발생할 수 있는 오류를 사전에 발견하고 수정할 수 있다.
- 코드 가독성과 유지보수성 향상 : 타입을 명시적으로 지정함으로써 "코드의 의미"를 명확하게 표현할 수 있고, 코드의 재사용성과 유지보수성을 높일 수 있다.
- 협업 효율성 향상 : 타입을 통해 코드의 의도를 명확하게 전달할 수 있기 때문에 협업 효율성을 높일 수 있다.
- 자바스크립트와 호환 : 자바스크립트와 100% 호환된다. 자바스크립트가 사용하는 어떤 곳이든 타입스크립트를 사용할 수 있다.
웹 개발의 역사
자바스크립트의 탄생
90년대 마이크로소프트의 인터넷 익스플로러와 넷스케이프 내비게이터가 가장 많이 사용되는 웹 브라우저였다. 95년 넷스케이프의 브랜드 아이크는 웹의 다양한 콘텐츠를 표현하기 위해 자바스크립트를 만들었다. C, 자바와 유사한 기본 문법을 가지고 있다. 셀프(객체 지향 언어)의 프로토타입 기반 상속 개념, Lisp 계열 언어 스킴의 일급 함수 개념 차용한 경량의 프로그래밍 언어이다.
자바스크립트 표준, ECMAScript의 탄생
웹 브라우저마다 DOM 구조가 다르고, 다양한 기능때문에 각자의 브라우저에서만 동작하는 문제가 있었다. 이렇게 제대로 동작하지 않는 문제를 크로스 브라우징 이슈라 한다. 이 문제를 해결하기 위해 개발자는 브라우저에 개수 만큼 스크립트를 따로 개발해야 했다.
자바스크립트의 문제점
- 브라우저 생태계를 고려하지 않음, 발전 속도에 차이가 자바스크립트 기능을 지원하지 못함.
- 브라우저가 지원을 하더라도 사용자가 예전 버전을 사용한다면 무용지물
해결하기 위해 폴리필과 트랜스파일 개념이 등장하였다.
- 폴리필 : 지원하지 않는 코드를 브라우저에서 사용할 수 있도록 변환한 코드 조각이나 플러그인
core.js, polyfill.io 대표적 라이브러리 - 트랜스파일 : 최신 버전의 코드를 예전 버전의 코드로 변화하는 과정을 의미, 대표적인 트랜스파일러는 바벨이 있다.
둘 다 최신 기능을 구버전의 실행 환경에서 동작할 수 있게 바꿔주는역할을 한다.
jQuery같이 브라우저 호환성을 고민하지 않고 한 번에 개발할 수 있도록 지원해주는 라이브러리가 유행을 끈 것은 어찌 보면 당연한 결과였다. 이런 라이브러리에 의존만 할 수 없어 크로스 브라우징 이슈를 해결하기 위해 표준화된 자바스크립트의 필요성이 제기되었다.
넷스케이프는 Ecma 인터내셔널에 자바스크립트의 표준화를 위한 기술 규격을 제출했고, Ecma는 ECMAScript라는 이름으로 자바스크립트 표준화를 공식화했다. 자바스크립트가 표준화되자 정적 웹사이트는 동적 웹 애플리케이션으로 전환되었다.
웹사이트에서 웹 애플리케이션으로의 전환
웹사이트
단방향으로 정보를 제공하고 사용자와 상호 작용하지 않으며, HTML에 링크가 연결된 웹 페이지 모음으로 콘텐츠가 동적으로 업데이트되지 않는다.
웹 애플리케이션
사용자와 상호작용하는 쌍방향 소통의 웹을 말한다. 검색, 댓글, 채팅, 좋아요 기능 등 웹 페이지 내부에 수많은 애플리케이션이 동작하고 있기 때문에 웹 애플리케이션이라고 부른다.
개발 생태계의 발전
대규모 웹 서비스 개발은 컴포넌트 단위로 개발하는 방식으로 발전하였고, Ajax를 통해 부분적으로 데이터를 로드할 수 있게 되었다. 이에 따라 사용자마다 부분적으로 다른 화면을 렌더링할 수 있게 되었다.
서비스 규모가 커짐에 따라 데이터가 폭발적으러 늘어났고, 표현해야 하는 화면도 다양하고 복잡해졌다. 디바이스도 다양해졌다. 모바일, 패드, 노트북 등 매우 다양하다. 디바이스마다 최적화된 UX/UI를 기대해야한다.
이에 따라 컴포넌트 베이스 개발(CBD) 방법론이 등장하였다. CBD는 서비스에서 다루는 데이터를 구분하고 그에 맞는 UI를 표현할 수 있게 컴포넌트 단위로 개발하는 접근 방식이다. 작은 컴포넌트를 조합해 큰 컴포넌트를 만들어가는 방식이 주류가 되었다.
- 재사용할 수 있는 컴포넌트를 개발 또는 조합해서 하나의 애플리케이션을 만드는 개발 방법론
컴포넌트는 모듈과유사하게 하나의 독립된 기능을 재사용하기 위한 코드 묶음이다. 다만 모듈과는 달리 런타임 환경에서 독립적으로 배포, 실행될 수 있는 단위이다. 따라서 컴포넌트는 다른 컴포넌트와의 의존성을 최소화하거나 없애야 한다.
개발자 협업의 필요성 증가
서비스를 개발하고 나서 유지보수를 하는 데 협업의 중용성도 높아졌다. 자신이 만든 함수도 시간이 지나면 다시 확인해야 하는데, 남이 만든 함수는 어떨까? 인원이 많아지면 어떨까?
코드는 파악하기 점점 어려워 진다. 자바스크립트는 유지보수에 적합한 언어는 아니었다.
자바스크립트의 한계
- 동적 타입 언어
- 자바스크립트는 변수에 타입을 명시적으로 지정하지 않고 코드가 실행되는 런타임에 변숫값이 할당될 때 해당 값의 타입에 따라 변수 타입이 결정된다.
- 동적 타이핑 시스템의 한계
- 자바스크립트 엔진에서 주석, 함수 이름, 개발자 의도 같은 것은 고려 대상이 아니다.
// 이 함수는 숫자 a, b의 합을 반환한다
const sumNumber = (a, b)=>{
return a + b;
};
a, b에 "a, b" 문자를 넣어도 작동 되고, a에만 값을 넣어도 자바스크립트 엔진은 b를 적절한 타입(NaN)으로 바꿔서 "+"연산을 실행을 이어나간다. 그래서 오류를 발생시키지 않고 실행이 된다. 개발자가 적은 주석이나 의도와 다르게 실행된다.
한계 극복을 위한 해결 방안
- JSDoc
모듈, 네임스페이스, 클래스, 메서드, 매개변수 등에 대한 API 문서 생성 도구다. 주석에 @ts- check를 추가하면 타입 및 에러 확인이 가능하며 자바스크립트 소스코드에 타입 힌트를 제공하는 HTML 문서를 생성할 수 있다. - propTypes
리액트에서 컴포넌트 props의 타입을 검사하기 위해 사용하는 속성이다. prop에 유효한 값이 전달되었는지 확인할 수 있지만, 전체 애플리케이션의 타입 검사를 하는 데는 사용할 수 없다. 리액트 환경에서만 사용할 수 있다. - 다트
구글이 자바스크립트를 대체하기 위해 제시한 새로운 언어로 타이핑이 가능하다. 하지만 새로운 언어의 등장으로 과거의 브라우저 전챙처럼 개발의 파편화를 불러올 수 있어 다트를 달갑지 않게 보는 시선이 강했다.
타입스크립트의 등장
마이크로소프트는 타입스크립트를 공개했다. 다트와 달리 자바스크립트 코드를 그대로 사용할 수 있다.
- 슈퍼셋 : 기존 언어에 새로운 기능과 문법을 추가해서 보완하거나 향상하는 것을 의미한다. 슈퍼셋 언어는 기존 언어와 호환되며 일반적으로 컴파일러 등으로 기존 언어 코드로 변환되어 실행된다.
- 타입스크립트 인터페이스 : 객체 구조를 정의하는 역할을 한다. 다시 말해 특정 객체가 가져야 하는 속성과 메서드의 집합을 인터페이스로 정의해서 객체가 그 구조를 따르게 한다.
- 특징
- 안정성 보장
- 정적 타이핑을 제공하므로서, 컴파일 단계에서 타입 검사를 하여 타입 에러를 줄어준다.
- 개발 생산성 향상
- VSCode 등의 IDE에서 타입 자동 완성 기능을 제공한다. 이 기능으로 변수와 함수 타입을 추론할 수 있고, 리액트를 사용할 때 어떤 prop을 넘겨야 하는지 매번 확인하지 않아도 사용부에서 바로 볼 수 있기 때문에 개발 생산성이 크게 향상된다.
- 협업에 유리
- 복잡한 애플리케이션 개발, 협업에 유리하다. 타입스크립트는 인터페이스, 제네릭 등을 지원하는데 인터페이스가 기술되면 코드를 더 쉽게 이해할 수 있게 도와준다. 또한 복잡한 애플리케이션일수록 협업하는 개발자 수도 증가하는데 자동 완성 기능이나 기술된 인터페이스로 코드를 쉽게 파악할 수 있다.
- 자바스크립트에 점진적으로 적용 가능
- 자바스크립트의 슈퍼셋이기 때문에 일괄 전환이 아닌 점진적 도입이 가능하다.
- 안정성 보장
타입스크립트는 생산성, 안정성, 협업에 대한 고민이 있을 때 좋은 선택지가 될 수 있다는 것을 의미할 뿐이다. 절대적 사용을 의미하는건 아니다.