Typescript, 왜 써야할까? (Why we have to use Typescript?)

몬드리안에이아이(주)

Typescript, 왜 써야할까?

(Why we have to use Typescript?)

Typescript란?

Ecmascript( Javascript, Typescript )

(본격) 써야하는 이유와 쓰지 말아야하는 이유에 대한 나의 생각

© rawpixel, 출처 Pixabay

Typescript 란

Typescript란 Microsoft에서 만든 Javascript로 컴파일되는 강타입 슈퍼셋 언어입니다.

ECMAscript ( Javascript, Typescript )

ECMAscript란 유럽 컴퓨터 제조사 연합 (European Computer Manufacturers Association) 에서 제안된 스크립트 의 표준입니다. 그 때 당시 JScript와 Javascript가 있었고, 브라우저 표준으로 하나를 채택을 해야했기 때문에 둘의 격 차를 완화하고 중재하기 위해 나온 표준이 ES입니다. 그리고 ES1을 따르는 자바스크립트가 브라우저 언어 표준으로 채 택되었습니다.

그리고, Typescript는 ECMAscript 표준을 따릅니다. 그렇기때문에, Typescirpt를 Javascript의 상위 집합(superset) 언어라고 합니다.

따라서, Javascript에서 Typescript를 써야하는 상황이 오더라도 Learning Curve는 크지 않으니 안심하셔도 됩니다.

(본격) 써야하는 이유와 쓰지 말아야하는 이유에 대한 나의 생각

'Javascript도 다 되고, TS를 쓴다해도 결국 Javascript로 다시 컴파일 시키는데 왜 굳이 써야할까?'

'Typescript를 쓰면 오히려 생산성이 떨어지지않나?'

'기존 JS 라이브러리들을 써도 문제 없는 건가?'

아마 Typescript를 쓰지 말아야하는 이유를 대라면 다음과 같은 것들이 단점과 함께 왜 써야하는지에 대한 의문으로 대 표적이지 않을까 생각합니다.

지금부터 제가 생각하는, TS를 채택한 사람들이 생각하는 이유를 설명하겠습니다.

안전성

The broken promise of static typing

위 글은 '정적 타입과 동적 타입이 버그 발생 빈도가 별다르지 않다.' 라는 글이니 읽어봐도 좋을 것 같습니다.

물론, 저 역시 타입이 모든걸 완벽하게 막아준다는 생각은 없습니다. 하지만, 정적 타입은 우리에게 자잘한 버그를 동적 타입으로 부터 막아줄 기회를 준다고 생각합니다.

버그는 무조건 개발자가 먼저 발견해야 한다고 생각합니다(물론, 모든건 불가능 할 겁니다 ). 사용자가 버그를 발견하게 되면 당연히 크든 작든 신뢰도는 떨어질 수 밖에 없다고 생각해서 입니다.

유지보수

프로젝트가 어느정도 자리를 잡아가고, 개발자는 계속해서 코드 리뷰 및 리팩토링과 버그를 잡고, 기능들을 확장해 나갈 겁니다.

그런데 코드 상에 타입이 명시 되어 있지 않는 동적인 언어 같은 경우 이 과정들을 힘들게 만들 수 있다고 생각합니다. 타입이 명확하지 않으면 변수의 값이나 함수의 리턴 값을 체크하는데 큰 혼란을 가져올 수 있습니다. 물론, 정확한 명시 없이도 실수없이 쓸 수 있는 분들도 여러 계시겠지만, 중요한건 협업입니다.

팀 전체가 위와 같은 상황에서도 혼란 없이 해결이 가능한 능력자들 이라면 유지 보수에는 문제가 없을 것 같습니다만, 제가 아는 한 그런 능력자들은 몇 이나 있을지는 모르겠습니다

제가 항상 생각하는 것이지만, 개발자들의 최고의 문서는 잘 짜이고, 이해하기 쉬운 코드입니다. Typescript는 그런 코드를 짜는데 큰 역할을 할 겁니다.

호환성과 생태계

TypeSearch

Typescript가 나온지 초 중반까지는, Javascript Library들 중에 Type Difinition을 지원해주는 라이브러리는 많지 않았을 겁니다. 하지만, Typescript의 생태계는 계속해서 가속이 붙어 커지고 있으며 올해 주목해야할 언어로도 많이 언급되고 있습니다.

그러다보니, 현재는 웬만한 라이브러리에서는 Type Difinition을 지원해주고 있으며, 크다고 하는 라이브러리들은 자 체적으로 포함이 되어있습니다.

위에 TypeSearch는 Microsoft에서 제공해주는 것으로, 사용하고 하는 라이브러리가 Typescript를 지원하는지 확인해 볼 수 있습니다.

여담으로 재밌는 것을 알려드리겠습니다.

Deno

Nodejs를 만든 라이언 달(Ryan Dahl) 이 Nodejs를 만들 때 후회했던 것들을 바로잡으며 만들고 있는 것이 있습니다. 이 오픈 소스 프로젝트는 Repository가 등록된지 얼마 지나지않아 엄청난 각광을 받았는데요,

바로 위의 Deno입니다. Deno는 V8엔진 기반의 Typescript 런타임입니다.

Nodejs 자체가 현재 Javascript 생태계에 많은 영향을 끼쳤다는 것은 조금만 관심있는 개발자라면 당연히 알겁니다. 그렇다면 Deno가 얼마나 기대되는 프로젝트인지는 말 안 해도 알겠죠?

단언컨데, 추후에 Deno는 모든 사람들에게 Nodejs 이상의 사랑을 받고 있을 겁니다.

생산성

흔히들 Typescript는 생산성이 떨어진다고 많이들 말씀하십니다. 개인적인 생각은 반은 맞고, 반은 틀렸다고 생각합니다.

초반에 Configuration 과정과 코딩 부분에서는 생산성이 당연히 떨어진다고 생각합니다. 그래서, 작은 프로젝트에서는 상황을 봐서 사용하죠. 하지만, 프로젝트가 어느정도 규모가 있다면 얘기는 달라집니다. 이는 위의 유지 보수와도 엮이는데 초반에 Typescript로 베이스가 잘 깔린 것 만큼 후반에 생산성은 기대 이상일 겁니다.

일단 Type을 알맞게 명시를 해뒀다면, IDE에서 후반 코딩을 적극적으로 도와줍니다. IDE는 대표적으로 VS Code나 Web Storm이 되겠죠.

그리고, 명시되어있는 Type들은 여러분들이 코딩하며 헤매는 것을 도와주는 최고의 문서가 될 겁니다. 그래서 결론적으로 생산성은 case by case라고 생각하고 있습니다.

기업문화 엿볼 때, 더팀스

로그인

/