아직 타입스크립트 사용을 고민 중이라면 (타입스크립트를 1달 간 사용해본 후기)

안녕하세요, 오늘은 자바스크립트에서 타입스크립트로 넘어가면서 제가 개인적으로 느낀 점에 대하여 포스팅해보려 합니다.

아무래도 사용 기간이 짧고, 리액트에 대한 지식도 완전하지 않기 때문에 타입스크립트에 대한 분석보다는 여과없는 의견이 들어간 글이 될 것 같습니다. 

---

 

🥺 편한 듯 불편한 너..

 

저는 리액트를 사용하면서 자바스크립트만 사용하다가 최근에야 타입스크립트를 접하게 되었습니다. 최근에 회사에서 도입한 프로젝트를 타입스크립트 + 리액트로 구성하게 되었기 때문이죠. 확실히 타입스크립트를 시작하면서 공부하였을 때 알아본 것처럼, 타입스크립트는 장점이 확실하면서도 그 장점을 감당하기 위한 어쩔 수 없는 불편함이 존재하는 언어인 것 같습니다.

 

자바스크립트와 타입스크립트의 가장 큰 차이점은 뭘까요?

자바스크립트는 동적 타입(dynamic typed) 혹은 느슨한 타입(loosely typed) 언어라고도 불립니다. 타입 체크를 하지 않기 때문에 클래스 기반 객체지향 언어에 익숙한 개발자들에게는 혼란스러울 수도 있는 특수성을 지닌 언어였죠. 그리고 브라우저나 노드에 띄워야만 콘솔이 확인이 되는 특성이 있기도 합니다.

 

개인적인 경험으로, 자바스크립트로 코딩을 하면 저는 종종 다음과 같은 경우를 맞이하기도 하였습니다.

 

🙂 슥슥 코딩 완료.. 생각한 대로 잘 구현이 됬을까? 한번 로컬에서 확인해 보자!
$ yarn start
😎 오! 역시 잘 돌아가네!
(테스트를 위해 이 페이지 저 페이지 눌러본다.)
(미처 예외처리 하지 못한 오류를 발견한다.)
🤬 아~~! 이걸 왜 이제야 확인할 수 있는거야~~!(분노)

 

자바스크립트의 등장 이후로 컴파일 언어와 인터프리터에 대한 경계가 모호해지고, 자바스크립트의 공식 명세에도 자바스크립트는 인터프리터 언어다! 라는 말은 없지만, 자바스크립트라는 언어는 해석하고 사용하기 위해서는 노드나 브라우저가 필요하다는 고유한 특수성 때문에, 인터프리터 언어로 여겨지기도 합니다. 실제로 사소한 오타 에러도 브라우저나 노드에 띄워서야 확인이 가능하죠.

 

👇 자바스크립트는 인터프리터 언어인가, 컴파일 언어인가! 에 대한 자세한 내용은 아래 링크를 참조해 주세요

hashcode.co.kr/questions/7560/javascript-%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%EB%8A%94-%EC%BB%B4%ED%8C%8C%EC%9D%BC%EC%96%B8%EC%96%B4%EC%9D%B8%EA%B0%80%EC%9A%94-%EC%9D%B8%ED%84%B0%ED%94%84%EB%A6%AC%ED%84%B0-%EC%96%B8%EC%96%B4%EC%9D%B8%EA%B0%80%EC%9A%94

 

 

이에 반해 타입스크립트는 자바스크립트에서 정적 타입 체크와 강력한 문법을 추가한 컴파일 언어이기 때문에 컴파일 단계에서 보다 더 많은 것을 감지해 줍니다. 텍스트 편집기 + 자동완성 기능 제공으로만 사용하던 IDE가(저 같은 경우 vscode가) 제 값을 하기 시작했습니다.

 

오타 감지와 문법 체크는 물론이며, 타입 체크가 올바로 이루어지지 않거나, 무조건 null이나 undefined로 떨어지는 객체를 감지해준다거나 하는, 자바스크립트를 사용하던 저로써는 감격스러울 정도로 강력한 기능을 제공하기 시작했죠!

 

이를 테면,

타입스크립트 + 리액트로 useRef를 사용할때 null로 초기화를 하지 않으면 컴파일 단계에서 바로 감지해낸다.

useRef를 사용할 때 null로 초기화를 하지 않으면, 렌더링이 되어 DOM에 액세스 하기 전에는 무조건 undefined로 떨어지기 때문에, 컴파일 단계에서 바로 감지해냅니다. 이러한 사소하면서도 개발자가 놓치기 쉬운 내용들을 IDE가 전부 잡아주니, 개인적으로는 더 편하게 느껴졌습니다. 이를 직접 브라우저에 펼쳐보고 직접 렌더링이 된 후에 콘솔로 오류를 확인하는 것과는 훨씬 차이가 있죠.

 

그 외에도 타입스크립트는 공식 문서에도 나와있듯 '엄격한 문법'을 지원하기 때문에 컴파일 단계에서 놓치기 쉬운 에러들을 캐치하기 쉽습니다.

 

---

🧐 그래서 타입 체크를 해서 좋은게 대체 뭔데요?

(아주 극단적인 예시임을 밝힙니다)

🤓백엔드 개발자: 이번에 사용할 API 명세와 함께 전달드렸습니다~ 확인 부탁드려요!

params 예시 
{
    id: number,
    name: string,
    display: string,
    price: string
}

🙂나: 감사합니다, 한번 테스트 해볼게요!

data: {
    id: 1,
    name: '준',
    display: '하하하',
    price: 25000 // ?!
}

(늘 그렇듯 403에러를 겸허히 맞이한다)

🙂(멍청한)나: 아니, 이거 API가 잘못된 것 같은데요? 로그 확인 부탁드려요 ㅠ ㅠ

 

🤓백엔드 개발자: 아니, 명세 제대로 안 읽어 보셨어요?! 😡

 

 

놀랍게도 꼼꼼하지 못한 성격인 저에게는 종종 있는 실수입니다. 자바스크립트에서는 Request를 넘기면서 따로 타입을 체크하지 않기 때문에, 서버 단에 요청할 때 까지도 이 Request는 에러가 뜰 것이라는 것을 감지하지 못합니다. 하지만 타입스크립트에서는 다음과 같은 방식으로 시도해 볼 수 있습니다.

 

interface Order {
    id: number;
    name: string;
    display: string;
    price: string;
}

 

이렇게 Request Parameter에 대한 Interface를 미리 선언해 놓는다면, 실수로 price에 int값을 할당해도, 컴파일 단계에서 잡히게 됩니다.

선언해 놓은 인터페이스에 맞는 타입에 맞춰 넣어야 하기 때문이죠.

const order:Order = {
      id: 1,
      name: '준',
      display: '하하하',
      price: 25000
    }

 

이 외에도

실수로 필드명을 잘못 입력해도 문제가 없습니다.

심지어 인터페이스로부터 올바른 변수명을 찾아주기도 합니다.

 

이렇듯 타입스크립트를 사용하면 개발자 간의 커뮤니케이션에서 발생하는 오차를 줄일 수 있고, 개발자의 비인간적인 실수도 컴파일 단계에서 캐치할 수 있습니다. DB 스키마대로 인터페이스를 미리 만들어 놓고 제공하면 CRUD 기능을 사용할 때도 에러가 발생할 일이 적어집니다. 특히 아주 많은 API와 명세가 오가는 대형 프로젝트에서는 타입을 미리 정해둔다라는 게 의미가 있겠죠?

 

 

---

🙏🏻 그럼에도 불구하고 사람들이 꺼릴만한 이유는..

여태까지의 글만 읽어보면 타입스크립트를 찬양하는 것 처럼 보이실 겁니다. 실제로 타입스크립트를 사용해보면서 단점보다는 장점을 훨-씬 많이 느꼈습니다. 특히 단순히 개발자 입장에서 바라볼 때 너무 편한 언어이니까요. 개발자 관점에서 생산성을 끌어올리고 최적화가 잘 되어있다는 장점 하나만으로도 타입스크립트를 사용할 만한 이유는 충분합니다. 하지만 아직 완벽하지는 않습니다.

 

실제로 제가 타입스크립트에서 react-reveal 라이브러리를 사용하던 경험을 공유합니다.

www.react-reveal.com/

 

 

1. 우선, 사용하고자 하는 모듈을 install 한다.

하지만 d.ts 파일을 제공하지 않는다(타입스크립트에서 바로 사용이 불가능하다)

 

👇

 

2. @types/모듈명으로 install을 시도한다.

하지만..

 타입스크립트로는 제공하지 않아요~ 👻

눈물의 404에러를 마주한다. 지푸라기 잡는 심정으로 npm에서도 찾아보지만

타입스크립트에서도 사용하게끔 제공하지는 않는다.

 

👇

 

3. (눈물을 흘리며😢) 타입스크립트 커뮤니티(대표적으로 definitelytyped.org/라든지..)를 찾아본다.

어림없다.

사용하고자 하는 라이브러리가 없다. (조금이라도 마이너한 라이브러리는 존재하지 않기 일쑤다)

그리고 definetelytyped에 분노의 PR을 날린다.

혹시나 해서 들어가본 react-reveal.js도 지원하지 않는다.

 

👇

 

4. 울며 겨자먹기로 직접 .d .ts파일을 사용하거나, 해당 부분만 JS로 작성한다. 자존심이 매우 상한다

 

 

이렇듯 .d.ts 파일의 존재 여부에 따라 라이브러리 선택이 갈리는 것, 의존성에 따로 @types/... 형태로 추가해줘야 하는 점, 이 역시 기존 라이브러리가 바뀌면 계속 유지보수를 해야한다는 점 등이 아직 타입스크립트에서 npm을 사용할 때 큰 단점으로 남아있습니다. 실제로 제가 처음 타입스크립트를 사용할 때 가장 먼저 마주한 진입장벽이기도 했습니다. 원래 npm은 갖다 쓰기만 하면 되는 거였는데, 따로 타입 정의가 안 되어 있으면 직접 타입을 정의해야 하는 게 번거로울 뿐 더러, .d.ts 파일을 작성하는 게 마냥 쉽지도 않습니다.

 

이렇듯 타입스크립트는 진입장벽이 꽤나 있는 언어라고 볼 수 있습니다.

 

---

😌 결론(그럼에도 불구하고 쓴다)

제가 한 달 간 타입스크립트를 써보며 느낀 점은, 앞으로도 계속 써야할 이유는 분명히 있다 입니다. 실제로 타입스크립트를 사용하면서 자바스크립트에서는 느낄 수 없었던 장점을 느끼기도 하였고, 사용하면서 오히려 편하다는 느낌도 받았기 때문이죠. 아직까지 단점은 있지만, 아직 수많은 개발자들에 의해 업데이트가 이루어지고 있는 언어기도 하고, 꽤나 좋은 성장 속도를 보여주고 있기도 한 언어니까요. (techit.kr/view/?no=20190324150204)

앞으로도 개선될 여지는 많아보입니다. 타입프리 언어를 사용하다 정적 타입 언어를 사용하게 되면 처음에는 불편함과 선입견이 있을 수 있지만, 타입을 정의한다 라는 건 그만큼 개발자의 실수를 줄여줄 수도 있다는 뜻이기도 합니다. 저는 앞으로도 타입스크립트를 사용할 것 같습니다. 모든 모듈의 타입이 정의될 때 까지..

 

 

 

 

📖 출처

- 타입스크립트 소개

poiemaweb.com/typescript-introduction

- 자바스크립트는 컴파일 언어인가요 인터프리터 언어인가요

hashcode.co.kr/questions/7560/javascript-%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%EB%8A%94-%EC%BB%B4%ED%8C%8C%EC%9D%BC%EC%96%B8%EC%96%B4%EC%9D%B8%EA%B0%80%EC%9A%94-%EC%9D%B8%ED%84%B0%ED%94%84%EB%A6%AC%ED%84%B0-%EC%96%B8%EC%96%B4%EC%9D%B8%EA%B0%80%EC%9A%94