JS로도 잘되는데, 왜 굳이 Typescript를 왜 써야하는거죠?

이런 문제가 생길 수 있어요

😎
개발에 익숙하지 않은 분들을 위해 적절한 비유와 간단한 코드 설명을 같이 하면서 이야기를 시작해볼게요

연애의 과학 에디터, editor씨가 있다고 생각을 해봅시다.

태생 문과 editor씨는 글paragraph 을 넘겨주면, 멋진 글 제목을 붙이고 내용을 맞춤법에 맞게 수정을 하는 재능이 있어요.

function editor(paragraph) { // editor씨가 글을 paragraph라는 이름으로 넘겨받으면
    const awesomeTitle = '연과팀이 일 잘하는 이유는 ○○ 때문이다?'; // 멋진 제목을 가지고 있고
    const fixedParagraph = checkGrammer(paragraph); // 글 내용을 맞춤법에 맞게 수정도 잘한뒤
    return awesomeTitle + fixedParagraph; // 멋진 제목과 글 내용을 합쳐서 수정본을 줄거에요
}

editor('멋진 글 내용'); // editor 씨에게 멋진 글 내용을 맞춤법에 맞게 고치고 멋진 제목을 붙이라고 시킬거에요

하지만 이걸 어쩌죠!

오늘 새로 입사한 매니저 분이, 글을 넘겨 받아야 하는 editor씨에게 글이 아닌, 숫자를 넘겨줬어요!

function editor(paragraph) { // editor씨가 숫자를 paragraph라는 이름으로 넘겨받아요
    const awesomeTitle = '연과팀이 일 잘하는 이유는 ○○ 때문이다?'; // 멋진 제목을 가지고 있는데
    const fixedParagraph = checkGrammer(paragraph); // 으앙 숫자인데 맞춤법 검사를 어떻게 하죠? 저 못하겠어요!
    return awesomeTitle + fixedParagraph; // 멋진 제목과 숫자를 합치라고요? 정말요?
}

editor(3.1415932121233); // 앗! editor씨에게 글이 아닌 숫자를 줘버렸어요!

이런... 숫자를 넘겨주면 태생 문과 editor씨는 본인의 역할을 다 못하고 울고 말거에요... 😭

그럼 만약에,

  1. editor 씨에게 글을 줘야 한다는 걸 매니저가 알고 있었다면
  2. 일을 시작하기전에 editor씨가 "저는 숫자를 받으면 일할 수 없어요, 글을 주세요!" 라고 말했다면

editor씨는 울지 않고 일을 할 수 있지 않았을까요?

via GIPHY

이렇게 하면 되겠네요!

이제 editor씨가 울지 않도록 Typescript와 함께 개선해 봅시다!

이제 새로운 매니저로 누가 오더라도 알 수 있도록, editor씨가 글string 타입을 받아야 한다고 적어 놓을거에요

function editor(paragraph: string): string { // editor씨는 숫자가 아닌 글 (string 타입)만 넘겨 받고, 숫자가 아닌 글(string 타입)만 줄거에요
    const awesomeTitle: string = '연과팀이 일 잘하는 이유는 ○○ 때문이다?'; // 멋진 제목도 숫자가 아닌 글이에요!
    const fixedParagraph: string = checkGrammer(paragaph); // 물론 맞춤법 수정이 완료된 글도 숫자가 아닌 글이죠
    return awesomeTitle + fixedParagraph; // 멋진 제목(글)과 맞춤법 수정이 완료된 글(글)을 합쳐주세요!
}

editor(3.1415932121233); // editor씨: "저는 숫자(number)를 받으면 일할 수 없어요, 글(string) 을 주세요!"

멋져요!

이제 editor씨에게 뭘 줘야할지 알겠고, editor씨는 일을 시작하기 전에

"저는 숫자를 받으면 일할 수 없어요, 글을 주세요!"

라고 말할 수 있겠네요!

고마워요, Typescript!

정리하자면...

우리는 줄곧 Javascript로 코드를 짰어요.

하지만 타입을 명시하지 않는 Javascript의 특성상 어떤 값이 넘어오는지, 이 함수가 넘겨받을 값이 글인지, 숫자인지, 카테고리 데이터인지 알기 힘들어요

하지만 타입이 있다면 코드를 짤 때, editor씨가 "저는 숫자를 받으면 일할 수 없어요, 글을 주세요!" 라고 말한 것 처럼 예상치 못한 에러가 나는 상황(위에서 editor씨가 울었던 상황)을 사전에 방지할 수 있겠죠?

Typescript를 사용하면, 코드를 돌려보지 않아도 코드에서 생길 수 있는 문제점들을 프로그래머에게 알려줘요

(Typescript의 interface를 써서) 넘겨받을 object의 키 값들을 알 수 있으니, 자동 완성도 잘 되고, 개발이 훨씬 편해질거에요 😎

😱
잠깐! Typescript는 에러를 예방할 순 있지만, 에러를 해결해 주진 않아요!

자, 이제 걱정하는 팀원을 설득해볼까요?

via GIPHY

1. 갑자기 새로운 언어라니... 러닝커브가 겁나요

Javascript 개발자여, Typescript를 겁내지 마시오!

물론 익숙했던 Javascript와는 조금 다른, 새로운 친구 Typescript를 마주하는 건 쉽지 않은 일이에요.

하지만 Typescript의 타입들을 처음부터 다시 배워야하는건 아니에요. number, string 처럼 Javascript에서 사용되는 타입들을 이용하기도 하고, interfacegeneric은 Javascript가 아닌 다른 정적 타입 언어들에서 본 적이 있을거에요. (예| Java)

로직을 짜는 문법은 Javascript에서 사용한 ES2015 이후 문법들과 같아요! 함수, 클래스, 변수들에 타입을 지정 한다는 것 처럼 타입 관련 기능들을 빼면 결국 Javascript와 같아요. 심지어 Typescript를 빌드하면 Javascript가 되죠.

처음부터 Typescript의 모든 기능을 써서 모든 걸 바꾸려 하지 않고, 타입 지정을 차근차근 해보세요.

혹시 타입이 지정될 때마다 에러가 뜬다고요? 그 에러들은 Typescript 도입 때문에 생기는 에러라기 보다는 Javascript를 쓰며, 우리가 미쳐 놓친 '일어 날 수도 있는 에러' 일거에요

2. 그냥 짜도 작동 되는데, 타입 지정 까지 하면 생산성이 줄어들지 않나요?

그 코드. 한 번짜고 나서 다시는 안볼거에요?

서버에서 모든 로직을 처리를 해주고, 서버에서 보낸 데이터를 보여주기만 했던 호랑이 담배피던 시절 웹 프론트 엔드와 지금은 많이 달라요.

프론트 엔드에서 비즈니스 로직을 구현하기도 하고, 심지어 라우팅도 프론트 엔드에서 하기도 하죠.

만약 우리가 코드의 양이 적은 간단한 프로젝트를 구현한 뒤 유지 보수를 코드를 짠 사람이 계속한다면 Typescript를 쓰지 않을거에요. 번거로운건 사실이니까요.

하지만 프론트 엔드에 많은 로직들이 들어가고 유지 보수를 장기간 해야하거나, 새로운 담당자가 코드를 마주해도 수월하게 기능 개발과 유지 보수를 해야 한다면, Typescript는 신의 한 수가 될거에요. 어떤 데이터 형식이 넘어오는지 코드를 보고 알 수 있고, 리팩토링 할 때도, 내가 바꾼 코드로 인해 생길 수 있는 side-effect들을 몇몇 알려주니까 훨씬 수월해요.

물론 코드를 더 적어야 해서 들이는 시간이 많아지니 생산성이 줄어든다고 1차원적으로 생각할 수 있겠지만, Typescript 도입으로 얻을 수 있는 장점들을 생각해본다면, '타입을 지정해서 생산성이 낮아졌어!' 라고 말할 순 없을거에요.

3. Typescript를 사용하면, Type이 없는 패키지들은 못쓰지 않아요?

아니에요! 하지만 생각보다 편하진 않아요

Typescript는 Javascript와 호환이 잘돼요! JS로 짜여진 모듈을 TS에서 import 하는 것도 가능하죠.

그리고, 대부분 많이 사용되는 패키지들은 @types/<패키지 이름> 의 Type definitions package를 제공해요 (자세한 설명은 Definitely Typed를 확인해보세요!).

만약 내가 설치한 react 가 Type이 없다고 TS에서 오류가 뜬다면,

yarn add react  # 앗! react는 Type을 알 수 없어요
yarn add --dev @types/react # Type definitions package를 추가해주세요!

짠! 이제 react 의 Type definitions package가 추가됐으니, Typescript에서 잘 쓸 수 있겠죠?

여기서 내가 사용하고 있는 Page가 Type definitions package가 있는지 확인 할 수 있어요!

하지만 만약 @types/<패키지 이름> 가 없고, 패키지가 Typing을 함께 제공하고 있지 않다면?
직접 Type definitions를 만들어줘야겠죠!

새로 <패키지 이름>.d.ts 파일을 만든 뒤,

declare module '<패키지 이름>';

이렇게만 해도 작동은 하지만, Typescript의 장점을 완벽하게 살릴 순 없어요 😭
자동 완성이나 Type checking 등이 잘 동작하길 원한다면,

declare module 'some-package' {
  interface SomeComponentProps {
    name: string;
    disabled: boolean;
  } 
  class SomeComponent extends React.Component<SomeComponentProps> {}
};

이런 식으로 하나하나 Type을 지정해줘야합니다!

마치며...

이번 포스트에서는 간단하게 Typescript가 뭔지, 대표적인 장단점이 뭔지 알아봤어요. 물론 프로그래밍을 하면서 '무조건 이렇게 해야 해!'라고 단호하게 말할 수 있을 정도로 완벽하게 맞고 틀린 건 없겠지만, 위에서 설명한 장점들만 보더라도 Typescript는 충분히 프로젝트에 적용해볼 가치가 있어요.

실제로 저희 연애의 과학 팀에서는 Javascript로 작성된 React와 React Native 코드를 Typescript로 개편한 뒤, 비교적 쉬운 유지 보수나 높은 코드 퀄리티 등 Typescript의 장점들을 몸소 느끼고 있답니다.

만약 이 글을 보고 있는 개발자분의 프로젝트에서 Typing 없는 Javascript를 사용하며 유지 보수 및 기능 개발을 하고 있다면, 한번 Typescript 도입을 고민해보세요!

🙌
연애의 과학 프로덕트팀에서는 프론트엔드 엔지니어를 채용중이에요 프로덕트와 리엑트, 웹을 사랑하고 능력있는 Pro-duck들이 모여, 연애의 과학을 만들고 있어요. 지금 연애의 과학팀에 합류하세요! → 채용공고 바로가기