최근에 프론트엔드 파트별 네트워킹에서 '타입스크립트를 사용하는 이유'에 대해서 준비를 하고 얘기를 나눈 시간을 가졌다.
타입스크립트 공식 문서를 보면 첫 페이지에 타입스크립트에 대해서 다음과 같이 설명하고 있다.
- JavaScript and More : 타입스크립트는 자바스크립트에 정적 타입(type)을 추가한 언어
- A Result You Can Trust : 타입스크립트로 작성한 코드는 신뢰할 수 있는 자바스크립트로 변환
- Safety At Scale : 타입스크립트는 타입 시스템과 강력한 에디터 지원으로 대규모 프로젝트에서도 안전하게 코드를 관리
내용을 정리하면 타입스크립트로 코드를 작성하면 쉽게 프로젝트를 관리할 수 있고, 이는 자바스크립트로 변환되기 때문에 자바스크립트와 완전히 호환된다고 설명한다.
이런 이론적인 내용이 아니더라도 프로젝트에서 자바스크립트와 타입스크립트 모두 사용한 경험이 있다면 자바스크립트로 개발을 하는 게 얼마나 불편한지, 타입스크립트를 사용하면 개발을 하기가 얼마나 편한지 몸소 느꼈을 것이다.
이렇게 타입스크립트를 사용해서 프로젝트를 진행하는 것이 매우 편리하지만, 한 가지 의문이 생긴 점이 있었다.
왜 자바스크립트가 처음 출시할 때 타입스크립트처럼 편리하게 만들지 않았을까?
이번 글에서는 자바스크립트가 왜 그런 모습으로 시작했는지 그 배경을 살펴보고, 시간이 지나며 자바스크립트는 어떻게 달라졌는지 이야기해 보겠다.
글에서 다루는 자바스크립트에 대한 의견은 책이나 공식 문서를 참고한 것이 아닌, 100% 개인적인 생각에 기반한 내용이다. 그러니 너무 진지하게 받아들이기보다는, "아, 저 사람은 이렇게 생각하는구나~" 정도로 가볍게 읽어주면 좋겠다.
1995년 : 자바스크립트의 출시
1995년, 웹 브라우저 시장은 넷스케이프 커뮤니케이션즈(Netscape Communications)가 주도하고 있었다. 그 당시 브라우저는 정적인 HTML과 CSS만을 사용할 수 있었고, 사용자와의 상호작용은 거의 불가능했다. 넷스케이프는 이러한 한계를 극복하고 보다 동적인 웹을 구현하기 위해 브라우저에 사용할 프로그래밍 언어를 도입하기로 결정했다.
1995년 3월 넷스케이프에 근무하던 브렌던 아이크(Brendan Eich)는 브라우저에서 실행 가능한 언어인 Mocha를 개발했다. 이후 Mocha는 그해 9월에 LiveScript로 이름이 바뀌었고, 3개월 뒤인 12월에 지금 우리가 알고 있는 JavaScript라는 이름으로 다시 변경되며 오늘날까지 이어지고 있다.
그리고 1996년 3월, Netscape Navigator 2에 자바스크립트가 탑재되면서 웹은 처음으로 동적인 기능을 가진 플랫폼으로 진화하기 시작했다.
최초의 자바스크립트 사용법
자바스크립트가 처음 등장한 이후, 2000년대 초반까지 웹 브라우저는 지금처럼 SPA(Single Page Application) 방식이 아닌, 각 페이지마다 별도의 HTML 문서를 사용하는 MPA(Multi Page Application) 방식이 주를 이루고 있었다. 즉, 사용자가 페이지에 접근하면 서버가 해당 페이지의 HTML 문서를 직접 제공하는 방식이었다.
이 시기 자바스크립트는 정적인 HTML에 약간의 동적인 기능을 더하는 보조 도구로 사용되었으며, <script> 태그 내부에 직접 코드를 작성하거나 외부 .js 파일을 불러오는 간단한 방식으로 활용되었다. 이렇게 자바스크립트는 하나의 페이지에서만 작동하는 작은 스크립트 수준이었기 때문에 엄격한 규칙이나 체계적인 관리보다는, 자유롭고 유연한 사용 방식이 더 적합한 환경이었다.
바로 이런 이유 때문에, 자바스크립트는 처음부터 타입스크립트처럼 정적 타입을 갖춘 언어가 아니라, 가능한 한 가볍고 간단한 형태로 설계되었던 것이다.
그럼 사람들은 언제부터 자바스크립트의 불편함을 느끼기 시작했을까?
2009년 : Node.js를 통한 서버 개발
2008년, 구글에서 V8 자바스크립트 엔진이 개발되면서 자바스크립트의 실행 속도는 획기적으로 향상되었다. 이를 계기로 브라우저에서는 자바스크립트를 사용해 다양한 기능을 추가하는 게 가능해졌다.
이후 2009년, 이 V8 엔진을 기반으로 한 자바스크립트 런타임인 Node.js가 등장하게 된다. 기존에는 자바스크립트를 실행하려면 반드시 브라우저 환경이 필요했지만, Node.js의 등장으로 자바스크립트는 브라우저를 벗어나 독립적인 런타임 환경에서 실행될 수 있게 되면서 웹 서버나 백엔드 애플리케이션까지 개발할 수 있는 범용 언어로 확장되었다.
애플리케이션을 개발하면서 달라진 자바스크립트의 사용법
기존에는 자바스크립트가 단순히 브라우저에서 UI를 제어하는 역할에 그쳤다면, 애플리케이션 개발에 사용되기 시작하면서 중요한 변화가 일어났다. 가장 큰 차이점은 자바스크립트에서 데이터를 본격적으로 다루게 되었다는 점이다. 자바스크립트에서 데이터를 직접 다루기 시작하면서 코드의 구조와 복잡도는 급격히 증가하게 되었다.
복잡해진 구조 속에서 자연스럽게 유지보수와 안정성에 대한 요구도 커졌고, 이때부터 기존 자바스크립트만으로 개발하는 것에 대한 불편함과 한계를 느끼는 개발자들이 많아지기 시작했다.
2010년 : Angular의 등장과 SPA의 대중화
2010년, Google은 프론트엔드 프레임워크 AngularJS를 출시하며 SPA(Single Page Application) 개발의 전환점을 만들었다. 이전까지 웹 페이지는 MPA방식으로 동작했지만, Angular의 등장으로 클라이언트 단에서 자바스크립트를 이용해 페이지를 렌더링 하는 SPA 방식이 본격적으로 확산되었다.
Angular보다 Backbone.js가 조금 먼저 등장했지만, 구조화가 부족하고 라이브러리 성격이 강했기 때문에 SPA 개발에 최적화된 Angular가 더 빠르게 주목받으며 프론트엔드 생태계를 주도했다.
SPA 방식의 도입은 기존처럼 서버에서 렌더링 된 페이지를 받아오는 방식이 아닌, 클라이언트에서 동적으로 렌더링 하는 방식으로 웹의 반응성과 사용자 경험을 획기적으로 향상하는 계기가 되었다.
SPA에서의 자바스크립트 사용법
웹 페이지가 MPA에서 SPA로 전환되면서 자바스크립트의 역할은 단순한 동적 요소 처리에서 웹 페이지 전체 구조를 생성하고 제어하는 수준으로 크게 확장되었다.
기존에는 서버에서 완성된 HTML을 받아 렌더링 했지만, SPA에서는 자바스크립트로 HTML을 클라이언트에서 직접 생성한다. 페이지 전환도 전체 HTML을 교체하는 방식이 아닌, 자바스크립트로 일부 뷰만 변경하는 방식으로 바뀌었다.
이로 인해 클라이언트와 서버는 HTML이 아닌 데이터를 주고받는 구조로 전환되었고, 프론트엔드 개발은 점점 서버 개발과 유사한 복잡성을 갖게 되면서 프론트엔드 개발자에게도 기존 자바스크립트의 한계를 체감하게 되었다.
2012년 : 타입스크립트로 개발자들의 불편함을 해결
초기의 자바스크립트는 단순히 HTML에 동적인 요소를 추가하기 위한 보조 언어였기 때문에 복잡한 기능이나 구조가 필요하지 않았다. 하지만 시간이 지나면서 자바스크립트는 서버 개발과 SPA 중심의 프론트엔드 개발에 사용되며 프로젝트의 복잡성과 규모가 급격히 증가하게 되었다.
이로 인해 개발자들은 자바스크립트의 불편함을 크게 느끼기 시작했고, 이를 해결하기 위해 Microsoft는 2012년, 자바스크립트의 슈퍼셋(superset) 언어인 타입스크립트를 출시했다.
이처럼 타입스크립트는 정적 타입을 도입해 데이터를 훨씬 효율적으로 다룰 수 있게 되었고, 구조화된 코드 작성을 가능하게 하며 자바스크립트의 불편함을 효과적으로 해소했다.
2015년 : ES6를 통한 자바스크립트의 직접적인 변화
2015년, 자바스크립트는 ECMAScript 6(ES6)의 도입으로 언어 차원의 근본적인 변화를 맞이하게 된다.
Node.js와 Angular를 사용하게 되면서 느낀 자바스크립트의 불편함을 타입스크립트가 개선했지만, 타입스크립트는 어디까지나 도구적인 보완 언어로, 자바스크립트 자체의 기능을 확장해 주지는 못했다.
반면, ES6는 자바스크립트 자체에 새로운 기능을 정식으로 도입한 표준으로, 실제로 사용할 수 있는 새로운 문법과 기능들을 제공하며 언어의 기능적 진화를 이끌었다.
ES6에서 추가된 문법은 많이 있지만 자주 사용하는 문법들은 다음과 같다.
- 변순 선언 방식 (let, const)
- 화살표 함수 (arrow function)
- 구조 분해 할당 (destructuring)
- 전개 연산자 (spread operator)
- 프로미스 (promises)
이러한 문법들은 단순한 문법적 변화가 아니라, 자바스크립트가 가지고 있던 실질적인 문제를 해결하기 위해 도입되었다. 이를 분류하면 다음과 같다.
- 스코프 문제 해결 : 변수 선언 방식, 화살표 함수
- 객체, 배열을 사용한 데이터 처리 : 구조 분해 할당, 전개 연산자
- 간결한 비동기 I/O : 프로미스
ES6는 스코프, 데이터 처리, 비동기 제어 등 자바스크립트의 주요 불편 요소에 대한 언어 차원의 해결책을 제시하며, 현대적인 애플리케이션 개발에 적합한 기반을 마련했다.
현재의 자바스크립트는 어떤 모습일까?
이번 글에서는 자바스크립트가 처음 만들어진 배경부터, 개발자들이 느꼈던 불편함, 그리고 이를 해결하기 위한 변화들까지 살펴보았다.
글의 제목인 "자바스크립트는 왜 불편한 언어였을까?"에 대한 답변은 자자바스크립트는 처음부터 불편한 언어였던 것이 아니라, 당시 목적에 맞게 단순하고 유연하게 설계된 언어였다.
하지만 시간이 지나면서 자바스크립트는 서버 애플리케이션과 SPA 중심의 프론트엔드 개발에 사용되며, 그 역할과 범위가 급격히 확장되었고, 이로 인해 기존 언어의 불편함을 타입스크립트와 ES6를 통해 해결해 왔다.
그러면 현재 자바스크립트는 어떤 모습일까?
최근에 타입스크립트 컴파일러가 Go로 포팅되면서 기존보다 10배 빠른 변화를 가져오고, ES6이후로 옵셔널 체이징(?.), 널 병합 연산자(??), 예외 처리(try, catch)와 같이 자바스크립트의 불편함을 해결하는 문법들이 지속적으로 추가되고 있다.
이처럼 자바스크립트는 개발자들이 대규모 애플리케이션을 더 나은 개발 경험을 제공하기 위해 계속해서 진화를 이어가고 있다.
