자바스크립트 프로그래밍 언어는 긴 역사가 있지만, 1995년 약 일주일에 걸쳐 만들어졌다. 처음에는 라이브스크립트라고 불렸지만, 자바와는 아무런 관련이 없음에도 불구하고 자바의 유행을 타기 위해 자바스크립트로 이름이 변경됐다. 자바스크립트는 곧 큰 인기를 얻으며 웹 애플리케이션 혁명을 일으키고 전 세계 거의 모든 웹 브라우저의 지원을 이끌어냈다. 오늘날 자바스크립트는 세계에서 가장 일반적으로 사용되는 프로그래밍 언어가 됐다.

필자는 자바스크립트의 팬이 아니다.

필자는 수년 동안 자바스크립트와 웹 브라우저의 관계가 어셈블리 코드와 CPU의 관계 같다고 말해왔다. 물론 어셈블리도 자바스크립트처럼 강력한 언어이지만, 우리가 고차원 언어를 사용하는 데는 이유가 있다. 그리고 오늘날 브라우저가 진정한 운영체제라는 점을 고려할 때, 자바스크립트는 개발자들의 마음속에서 어셈블리처럼 사라져야 하고, 결국 그렇게 될 것이다.

자바스크립트의 성공과 효율성을 부정하는 것은 아니다. 웹은 자바스크립트를 기반으로 구축됐고, 사람들은 자바스크립트의 상당한 단점에도 불구하고 자바스크립트로 놀라운 일을 해왔다. 하지만 오늘날 소수의 개발자만이 어셈블리어로 코드를 작성하는 것처럼 자바스크립트를 우리가 코드를 작성할 때 사용하는 보편적인 언어로 생각하기는 어렵다.

필자는 윈도우 애플리케이션을 빌드할 때는 컴파일러가 어셈블리 언어를 작성하는 것을 선호한다. 웹 애플리케이션을 빌드할 때는 컴파일된 타입스크립트가 자바스크립트를 작성하는 것을 선호한다.

타입스크립트는 또 다른 이야기이다. 이제 프로그래밍 언어가 있다. 위대한 앤더스 하일스버그가 설계한 타입스크립트는 자바스크립트의 모든 장점에 표현력이 풍부하고 강력한 타입 시스템을 추가했다. 솔직히 필자는 왜 타입스크립트보다 자바스크립트를 선호하는지 이해할 수 없다.

타입스크립트를 사용하지 않을 이유가 없다

첫째, 자신의 속도에 맞춰 타입스크립트로 시작할 수 있다. 전부 아니면 전무가 아니다. 모든 자바스크립트 코드는 타입스크립트 코드이다. 필자는 농담 삼아 모든 자바스크립트 개발팀이 *.js 파일을 *.ts 파일로 바꾸기만 해도 기꺼이 타입스크립트 개발자로 인정하고 더 나은 대우를 하겠다고 말하기도 한다. 그렇게 한 번만 바꾸면 모든 개발팀이 타입스크립트 개발자가 되고 코드 작성 방식은 전혀 바꿀 필요가 없다. 그런 다음 점진적으로 원하는 대로 티입스크립트를 사용하면 된다.

자바스크립트를 고수하는 개발자들이 타입스크립트 사용에 대해 제기하는 궁색한 반대는 다음과 같다.

“모든 타입이 방해만 된다”

물론 방해가 될 수도 있다. 무언가를 빨리 완성하고 자신이 작성한 코드에 대해 모든 것을 파악할 수도 있다. 하지만 6개월 또는 1년 전의 코드를 보고 개발자가 무슨 생각을 했는지 알아내야 하는 불쌍한 사람은 어떻게 될까? 불쌍한 사람은 아마 또 다른 개발자, 결국 여러분이다. “이 모든 코드가 무엇을 해야 하는지 기억하지 못하는 1년 후에 예기치 않은 문제가 겪고 싶다”는 말이 된다.

타입스크립트는 모든 것을 입력하면 코드의 의도를 명확하고 간결하게 선언할 수 있을 뿐만 아니라 코드 베이스 전체에 이런 의도를 적용할 수 있다. 개발자가 많은 애플리케이션의 경우 코드가 하는 일을 명확하고 확실하게 표현할 수 있다는 것은 동료 개발자가 이를 파악하는 데 인지적 에너지를 소비해야 하는 코드에 비해 큰 장점이다.

“자바스크립트는 빠른 프로토타입을 만들기에 좋다”

알겠다. 하지만 이 점을 생각해 보자. ‘프로토타입’이라는 개념이 일종의 농담이라는 것을 우리 모두 알고 있다. 프로토타입을 버리고 ‘진짜’ 애플리케이션을 다시 시작하는 경우는 슬프게도 드물다. 프로토타입이 실제 애플리케이션이 되면, 절대 배포하지 않겠다고 했지만 결국 배포하게 되는 프로토타입을 만들 때 내린 잘못된 기본 결정에 영원히 갇히게 된다. 무언가를 빠르게 조합하는 능력은 미덕이 아니다.

“자바스크립트는 초보자에게나 좋다”

이런 말을 들으면 “초보 개발자들이 실제 프로그래밍 언어의 작동 원리를 배우지 않고 나쁜 습관으로 코딩을 배우면 안 되겠다”는 생각이 든다.

“타이핑을 많이 하면 손가락이 피곤해져요”

제발. 필자가 들어본 최악의 변명 중 하나이며, 이런 말을 진지하게 하는 개발자가 부끄러울 정도다. 시스템을 구축할 때 입력하는 방법도 있고, 나중에 유지 관리, 재실행, 수정해야 할 때 더 많이 입력하는 방법도 있다. 타이핑이 너무 많다고 해서 명확하고 명확한 코드를 작성하지 않으려는 것은 터무니없고 게으른 행동이다. 키보드를 더 치면 코드가 하는 일을 충분히 표현할 수 있다. 조금 더 입력해도 된다.

“타입스크립트 컴파일러가 사소한 오류만 찾고 너무 많은 오류를 찾는다.”

맞다.

하지만, 이런 지적은 약간 경솔하다. 오류가 핵심이다. 타입스크립트 컴파일러는 테스트를 통해 잡아내지 못하면 배포까지 이어질 수 있는 오류를 발견한다. 개발 주기 초기에 문제를 발견하는 것이 항상 더 좋으며, 오류를 입력하는 즉시 빨간색으로 표시되는 것보다 더 빠른 것은 없다.

“너무 많은 오류”를 찾아내는 것도 하나의 기능이다. 타입스크립트는 정확하며, 코딩할 때 정확성은 좋은 것이고 바람직한 것이다. 자바스크립트를 사용하면 자기 발등을 찍을 수 있는 방법에 한계가 없다. “이 자바스크립트 코드가 무엇을 출력할지 맞춰보라”는 문제를 너무 많이 본다. 언어에 모호함과 부정확성이 있다면, 그 언어는 버그가 많은 코드를 만들게 된다. 코드를 실행해야만 출력이 무엇인지 알 수 있다면 잘못된 코드가 있는 것이다.

“단위 테스트를 통해 코드가 제대로 작동하는지 확인할 수 있다”

필자를 잠시 멈칫하게 하는 주장 중 하나다. 필자는 단위 테스트와 테스트 중심 개발을 좋아하고, 우리 모두 그런 방식으로 코드를 작성해야 한다고 생각하기 때문에 이 주장은 설득력이 있다. 하지만 타입스크립트로도 단위 테스트를 할 수 있기 때문에 타입스크립트에 대한 반대 주장으로는 설득력이 떨어진다.

나쁜 프로그래밍 언어와 나쁜 코드

필자는 “자바스크립트로 빠르게 개발할 수 있다”라고 쓰고, ‘이 프로젝트는 유지보수의 악몽이 될 것이다”라고 읽는다. “난 그런 장황함이 싫다. 자바스크립트가 더 간단하고 간결하다”라고 말하면, ‘다시 돌아왔을 때 이해할 수 있는 코드가 좋아요’라고 들린다. “이런 유형은 다 다루지 않고 문제만 해결하고 싶다”라고 말은 ‘나중에 엄청난 문제를 만들고 싶다’라고 들린다.

자바스크립트는 적절한 시기에 적절한 선택이었다. 결국 자바스크립트는 적합하지 않은 목적에 맞춰 이렇게 저렇게 변형됐다. 이것이 바로 타입스크립트가 등장한 이유다. 타입스크립트는 자바스크립트의 편재성을 활용하면서 최신 타이핑 시스템의 모든 기능을 추가한다. 이것이 바로 타입스크립트를 사용해야 하는 이유다.
dl-itworldkorea@foundryco.com