타입 스크립트는 어떤 장점이 있나?

이전에 이야기한 것처럼…

복습을 해보자.

타입스크립트는 정적 타입의 컴파일 언어이다. 이는 우리가 변수를 만들 때, 이 변수가 어떤 유형인지를 미리 명시하고 개발을 진행해야한다는 의미이다.

이전 에피소드에서 썼듯이, 나는 자바스크립트 코딩을 하면서 변수의 타입을 처음부터 명시하지 않고 그때그때마다 데이터 타입을 바꾸거나 하는 과정을 꽤나 즐기면서 코딩을 해왔다.

하우에버...타입스크립트는 이러한 행위를 좋아하지 않는다. (any 타입을 사용하여 구현이 가능은 하다.)

타입스크립트의 모든것

타입스크립트를 한번 쭉 둘러보면서 공부를 해본 결과, 내가 생각한 타입스크립트를 관통하는 하나의 컨셉은 ‘타입을 미리 확정하자!’ 이다.

사실 이게 타입스크립트의 전부라고 생각한다. 코딩을 하면서 등장하는 요소들의 정체를 미리 명시해주는 것.

여러가지 타입스크립트만의 문법들이 있지만, 타입스크립트가 결국에 개발자로서 요구하는 단 하나의 행위는 변수의 타입을 미리 정하는 것 밖에 없다.

타입스크립트를 써야 할까?

결론부터 말하자면, 써야한다고 생각한다. 귀찮은건 안다. 하지만, 쓰는게 맞다고 생각한다.

자바스크립트처럼 동적인 타입 할당이 가능하다는 것은, 개발을 한창 진행하고 있는 개발자에게 덜 귀찮은 부분인 것이 맞지만, 사실 이건 더 큰 문제를 야기하는 것이 될 수 있다.

동적인 타입 할당에 익숙해지다보면, 변수를 여기저기에 적용시켜서 그 안에 들어오는 데이터 형식을 마구잡이로 넣어버리는 태도가 생기기 쉽다. (적어도 나는 그랬다.)

이러한 태도에 너무 익숙해지다보니, 코드를 실행하고 웹사이트를 확인했을 때 변수에 들어온 값이 문제가 되는 경우에 문제의 원인을 찾는 것이 꽤나 성가신 일이 되는 문제에 직면하게 되었다.

예를 들어, 내가 원하는 데이터가 배열 형식인데, 나도 모르게 중간에 그 변수에 스트링 데이터를 넣어버린 경우에, 실행하는 과정에서 이러한 오류를 잡아주지 못하기 때문에 내가 직접 코드를 일일이 확인하면서 문제가 발생한 지점을 확인해줘야했기 때문이다.

타입스크립트는 위와 같은 상황을 어지간해서 만들지 못한다. 미리 이건 무슨 변수이고, 어디에 써야하는지를 생각해서 명시해줘야 하기 때문이다.

그래서 타입스크립트는 자바스크립트 코딩을 하는 사람이 자주 써버릇해야하는 언어라고 생각이 든다.

어플리케이션 (나의 경우에는 웹사이트)을 만드는 과정에서는, 필요한 데이터 및 함수가 굉장히 다양하고, 구조가 복잡할수록 그 양 또한 증가한다.

이러한 데이터를 명확하고, 잘 정리된 상태로 유지하지 못하면 코드를 유지 및 보수하는 과정에서 굉장히 머리가 아파오기 시작한다. 내가 개발을 처음 시작하고 마구잡이로 웹사이트를 만들어나가기 시작했을 때, 처음에 호기롭게 이것저것 정리하지 않고 만들다가 마지막에 가서는 코드가 너무 복잡하게 얽혀있어서 건드릴 엄두를 내지 못하는 경우가 많았다. 그건 지금도 마찬가지이지만, 점점 더 프로젝트의 청사진을 명확하게 가지고 가는 것의 중요성을 체감하는 중이다.

타입스크립트를 사용한다는 것은, 미리 구현하고자 하는 어플리케이션의 구조를 명확하게 잡고 가는 태도를 갖겠다는 것과 동일한 의미처럼 보인다.

그렇기 때문에, 자바스크립트 개발자가 타입스크립트는 사용하는 것의 의미가 큰 것 같다.

타입스크립트를 처음 마주했을 때, 나는 꽤나 큰 부담감을 느꼈다. 자바스크립트도 완전히 마스터하지 않은 상태에서 더 넓은 범위를 포함하는 타입스크립트를 새로 공부한다는 것에 그러한 압박감을 느꼈던 것 같다.

지금도 모르는 부분이 있겠지만, 타입스크립트의 문법을 공부하고, 실제로 적용시켜보면서 손에 익기 시작하니 이게 그렇게 부담을 가질 것은 아니었구나 하는 생각이 들었다.

공포는 내가 알지 못하는 것에서 온다는 말처럼, 내가 이 엄청난 것을 할 수 있을까?하는 두려움이 있을때, 최대한 빨리 그걸 배우기 시작하는 태도를 가져야겠다는 생각이 든다.

그렇게 하나씩 배우다보면, 점점 두려운 것들이 적어지지 않을까.

다음 시리즈부터는 타입스크립트의 주요한 문법들에 대해 내 나름대로 정리를 할 예정이다.