[Typescript] Typescript를 시작하기 전에

무언가를 공부하기 시작할 때, 가장 좋은 것은 이것이 왜 등장하게 되었는지에 대한 배경, 즉 역사를 알아보는 것이다.

그래야만 왜 나오게 되었는지, 왜 이것을 공부해야 하는지 알고 공부할 수 있으며 앞으로의 공부에 나침반이 되어준다.

 

따라서 Typescript가 등장하게 된 배경에 대해 살펴보고 Typescript에 대해 하나씩 공부해보도록 하겠다.

 

웹 개발의 역사

자바스크립트의 탄생

1990년대 마이크로소프트의 인터넷 익스플로러와 넷스케이프 커뮤니케이션즈의 넷스케이프 네비게이터가 가장 많이 사용되는 웹 브라우저였다고 한다.

인터넷 익스플로러 로고

 

이후 1995년 넷스케이프의 브랜든 아이크는 웹의 다양한 콘텐츠를 표현하기 위해 이미지, 플러그인 요소를 쉽게 조합할 수 있는 새로운 언어가 필요하다고 생각하고 자바스크립트를 만들었다. 자바스크립트는 10일만에 만들어진 언어로 유명하다. 또한 Javascript라는 이름에서 굉장히 익숙한 Java라는 이름을 살펴볼 수 있는데, 지극히 정상이라고 할 수 있다. Java의 유명세를 타서 묻어가기 위해 의도적으로 지은 이름이기 때문이다. 이 때문에 Javascript는 굉장히 유명세를 탈 수 있었고, 개인적으로는 굉장히 성공한 마케팅 사례라고 생각한다.

 

자바스크립트는 기본적으로 C, Java와 유사한 기본 문법을 가지고 있다고는 하지만 개인적으로 느끼기로는 굉장히 다르다. 

 

자바스크립트 표준, ECMAScript의 탄생

자바스크립트는 본래 표준이랄 것이 딱히 없었다. 하지만 몇 가지 문제가 있어 표준을 정하게 되었다.

 

각자의 브라우저에서만 동작하는 기능들이 정말 많아지던 시절이 있었다. 이것을 크로스 브라우징 이슈라고 하는데, 이 때문에 개발자들이 많이 고생했다. Safari와 Chrome의 동작 방식이 완전히 달라서 모두 새롭게 각자 개발해야 하는 어려움이 있었다고 한다.

 

문제는 이뿐만이 아니었다. 10일만에 만들어졌기 때문에 굉장한 미숙아 상태였던 자바스크립트는 계속해서 폭풍성장하기 시작했다. 이에 따라 브라우저가 자바스크립트의 성장속도를 따라잡지 못했다.

 

따라서 jQuery같이 브라우저 호환성을 고민하지 않고 한 번에 개발할 수 있도록 지원해주는 라이브러리가 유행을 끌기도 했다. 나도 jQuery를 사용해 본 적이 있었지만, 브라우저 호환성 문제를 해결할 수 있었다는 것은 지금 처음 알았다.

 

하지만 당연히 jQuery 같은 라이브러리에 기대어서 크로스 브라우징 이슈를 해결할 수는 없다.

 

따라서 넷스케이프는 컴퓨터 시스템의 표준을 관리하는 Ecma 인터내셔널에 자바스크립트의 표준화를 위한 자바스크립트 기술 규격을 제출했고, ECMAScript라는 이름으로 공식 표준화되었다.

 

자바스크립트가 표준화되자 정적이던 웹사이트에서 동적인 웹 애플리케이션으로의 전환이 가속되었다.

 

웹사이트에서 웹 애플리케이션으로의 전환

웹사이트에서 웹 애플리케이션으로의 전환? 둘이 같은 말 아닌가?

 

웹 사이트

웹사이트도 HTML, CSS, JS를 사용한다. 하지만 여기서 중요한 것은 웹사이트는 수집된 데이터 및 정보를 특정 페이지에 표시하기 위한 정적인 웹이라는 것이다.

단방향으로 정보를 제공하기 때문에 사용자와의 상호작용이 없고, HTML에 링크가 연결된 웹 페이지 모음으로 콘텐츠가 동적으로 업데이트되지 않는다.

위키백과의 정적 페이지

 

웹 애플리케이션

웹 사이트가 단방향이라면 웹 애플리케이션은 무엇이겠는가? 사용자와 상호작용하는 쌍방향 소통의 웹이다. 검색, 댓글, 채팅, 좋아요 등 현재 우리가 접하는 대부분의 웹사이트는 웹 애플리케이션이다.

구글맵의 동적 웹 애플리케이션

 

그래서

그래서 웹사이트에서 웹애플리케이션으로의 전환이라는 말이 갑자기 왜 나왔을까?

웹 애플리케이션으로 전환되며 사용자와 소통하게 되면서 웹이 성장하고 규모가 커졌다. 따라서 개발 규모가 커진 만큼 개발 생태계도 변화가 필요하게 되었다.

 

개발 생태계의 발전

대규모 웹 서비스 개발의 필요성이 커지면서 하나의 웹 페이지를 통으로 개발하지 않고, 컴포넌트 단위로 개발하는 방식이 생겨났다. 이렇게 하면서 컴포넌트 재사용이 가능해졌다.

또한 Ajax로 페이지 전체를 새로고침하지 않아도 자바스크립트의 비동기 요청을 사용해 페이지의 일부 데이터를 로드할 수 있게 되었다. 이에 따라 사용자마다 부분적으로 다른 화면을 렌더링할 수 있게 되었다.

 

이런 방식을 컴포넌트 베이스 개발(Component Based Development) 방법론이라고 한다.

CBD는 서비스에서 다루는 데이터를 구분하고 그에 맞는 UI를 표현할 수 있게 컴포넌트 단위로 개발하는 접근 방식이다.

요즘은 작은 컴포넌트를 조합해서 좀 더 큰 컴포넌트를 만들어가는 방식이 주류가 되었다고 한다.

 

컴포넌트
모듈과 유사하게 하나의 독립된 기능을 재사용하기 위한 코드 묶음.
하지만 모듈과는 달리 런타임 환경에서 독립적으로 배포, 실행될 수 있는 단위.
따라서 컴포넌트는 다른 컴포넌트와의 의존성을 최소화하거나 없애야 함.

 

이런 개발 생태계의 발전과 거디한 동적 웹 서비스 수요 증가는 자연스럽게 자바스크립트 개발자의 증가로 이어졌다.

 

개발자 협업의 필요성 증가

결과물이 커졌기 때문에 개발 이후의 유지보수와 협업의 중요성도 높아졌다.

 

대규모 프로젝트를 개발하고 나서 자바스크립트는 과연 유지보수에 적합한 언어였을까?

 

 

자바스크립트의 한계

동적 타입 언어

자바스크립트의 특징 중 하나가 동적 타입 언어라는 것이다.

동적 타입 언어
변수에 타입을 명시적으로 지정하지 않고 코드가 실행되는 런타임에 변수의 값이 할당됨.
이때, 해당 값의 타입에 따라 변수 타입이 결정되는 것을 동적 타입 언어라고 함.

 

그러면 어떤 문제가 생기느냐. 자바스크립트를 사용하는 것이 사람인 데에서 문제가 생긴다.

 

사람은 완벽하지 않기 때문에 동적 타입 언어가 주는 관대함으로 개발자의 의도와 상관없는 결과물이 생길 수 있게 된다.

 

어떻게 해결하려 했나?

JSDoc, propTypes, 다트 같은 해결 방안이 등장했다. 궁금하면 직접 찾아보길 바란다.

 

우리는 현재 답을 알고 있다. Typescript를 배우기 위해 역사를 공부하고 있으니 말이다.

 

자바스크립트의 동적 타입 언어라는 한계 때문에 타입스크립트가 등장하게 되었다.

마이크로소프트가 공개한 자바스크립트의 슈퍼셋 언어였다.

슈퍼셋
기존 언어에 새로운 기능과 문법을 추가해서 보완하거나 향상하는 것.
슈퍼셋 언어는 기존 언어와 호환되며 일반적으로 컴파일러 등으로 기존 언어 코드로 변환되어 실행됨.

 

자바와 코틀린
코틀린도 JVM에서 실행되기 때문에 슈퍼셋인가? 하는 의문이 들었지만 코틀린은 타입스크립트와 다르게 슈퍼셋은 아님.
코틀린은 자바와 상호 운용이 가능한 언어로 설계됨. 따라서 자바와 함께 사용될 수 있고, 자바 코드와 상호작용할 수 있음.

 

타입스크립트

이렇게 등장하게 된 타입스크립트는 어떤 특징이 있을까?

타입스크립트 로고

 

안정성 보장

타입스크립트는 정적 타이핑을 제공한다.

컴파일 단계에서 타입 검사를 해주기 때문에 자바스크립트를 사용했을 때 빈번하게 발생하는 타입 에러를 줄일 수 있고, 런타임 에러를 사전에 방지할 수 있어 안정성이 크게 높아진다.

 

개발 생산성 향상

VSCode 등의 IDE에서 타입 자동 완성 기능을 제공한다.

이 기능으로 변수와 함수 타입을 추론할 수 있다.

 

협업에 유리

타입스크립트는 인터페이스, 제네릭 등을 지원하는데 인터페이스가 기술되면 코드를 더 쉽게 이해할 수 있게 도와준다.

 

자바스크립트에 점진적으로 적용 가능

타입스크립트는 자바스크립트의 슈퍼셋이기 때문에 일괄 전환이 아닌 점진적 도입이 가능하다.

 

 

 

 

 

지금까지는 왜 타입스크립트가 나오게 되었는지에 대해 알아보았다.

다음 시간부터는 타입스크립트에 대해 알아보도록 하자.

---

출처

타입스크립트 with 리액트

https://product.kyobobook.co.kr/detail/S000210716282

우아한 타입스크립트 with 리액트 | 우아한형제들 - 교보문고