한빛출판네트워크

프런트엔드 개발은 웹의 탄생과 함께 시작되어, 기술의 발전에 따라 끊임없이 변화해 왔습니다. 자바스크립트의 등장부터 프레임워크의 발전, Vue.js의 등장까지, 웹 개발의 역사를 살펴보며 현재 우리가 사용하는 기술이 어떻게 자리 잡았는지 알아보겠습니다.

자바스크립트의 등장과 초기 한계

브라우저에서 동작하는 언어인 자바스크립트는 1995년, 처음 세상에 등장했습니다. 이 언어는 세계 최초의 상용 브라우저인 넷스케이프 내비게이터 ^{Netscape Navigator} 를 출시한 넷스케이프 커뮤니케이션즈가 개발한 언어인데요. 출시 초기에는 라이브스크립트 ^LiveScript 라는 이름을 가지고 있었지만 당시 유행하던 자바의 영향을 받아 자바스크립트 ^JavaScript 로 변경하게 됩니다. 이후 넷스케이프 내비게이터에 탑재되면서 본격적으로 사용되기 시작했습니다.

자바스크립트가 등장한 시기는 웹이 막 태동하던 시기였기 때문에 당시 콘텐츠는 이미지나 글을 정적으로 표시하는 것이 전부였습니다. 하지만 자바스크립트를 활용하면 동적인 페이지를 구현할 수 있었죠. 다만, 초기에는 사용성이 그다지 뛰어나지 않았습니다. 특히, 넷스케이프 내비게이터처럼 자신만의 언어를 가지고 있었던 마이크로소프트의 인터넷 익스플로러(IE)에서 사용하려면 또 다른 코드를 작성해야 하는 불편함도 있었습니다.

이 때문에 당시에는 ‘자바스크립트는 가급적 사용하지 않는 것이 좋다’는 이야기도 나왔습니다. 실제로 웹 초창기에는 보안상의 이유로 자바스크립트 실행을 기본적으로 해제한 채 사용하는 경우도 많았죠.

자바스크립트의 재조명: 구글 지도와 웹 2.0

이렇게 불운의 시기를 보내던 자바스크립트는 2005년 극적인 전환점을 맞이합니다. 계기는 바로 구글 지도였습니다. 구글은 지도 서비스에 브라우저에서 지도를 드래그하면 실시간으로 지도가 움직이는 기능을 구현해 주목을 받았습니다. 지금은 아주 당연하게 사용하는 기능이지만 2005년 당시에는 구현하기가 매우 어려운 기술이었습니다. 왜인지 살펴볼까요?

당시 웹 애플리케이션의 큰 원칙은 ‘처리는 서버에서 한다’는 것이었습니다. 일반적으로 모든 처리를 서버에서 수행하고 결과인 HTML 데이터를 브라우저에 반환하는 방식이었습니다.

하지만, 이러한 구조에서 브라우저는 서버에서 반환된 HTML 데이터만 표시할 뿐, 한번 표시된 화면은 아무런 움직임이 없습니다. 애초에 브라우저가 받은 데이터에 움직임을 구현하는 프로그램이 존재하지 않기 때문입니다. 당시 구글은 서버에서 반환된 HTML 데이터를 읽어들인 후 지도 확장이나 축소, 슬라이드 등의 동작을 브라우저에서 구현하고 싶었습니다. 이때, 오래전부터 브라우저에 내장되어 있었음에도 불구하고 거의 사용되지 않았던 자바스크립트에 눈을 돌리게 되었죠.

구글 지도의 등장으로 웹 제작 현장은 충격에 휩싸임과 동시에 새로운 웹의 가능성과 자바스크립트의 가능성을 인식하게 됩니다. 이 충격적인 사건으로 인해 웹 2.0이라는 단어가 등장합니 다. 웹의 ‘버전 업’이라는 의미지만 특정 소프트웨어나 프로토콜의 버전이 올라갔다는 의미가 아니라 웹의 방식 자체가 올라갔다는 의미의 2.0입니다.

제이쿼리의 등장과 프런트엔드 개발의 시작

웹 2.0으로 인해 자바스크립트는 재평가되었지만, 여전히 자바스크립트 사양의 파편화 문제는 해결되지 않았습니다. 앞서 언급한 대로, 자바스크립트 외에도 IE에서 사용되는 J스크립트가 있었기 때문입니다. 이를 해결하기 위해 정보통신 시스템 분야의 국제 표준화 단체인 Ecma International은 1997년 ECMA스크립트(ECMAScript)를 제안했으나, 큰 주목을 받지 못했죠.

자바스크립트를 만든 넷스케이프 내비게이터가 윈도우의 점유율을 바탕으로 한 IE의 브라우저 독점으로 역사 속으로 사라지게 된 일도 있습니다. 그 후, 모질라 재단이 2002년에 출시한 파이어폭스와 애플의 사파리 같은 새로운 브라우저들이 등장했으나, 각 브라우저는 고유한 자바스크립트를 탑재하고 있어 여전히 각기 다른 자바스크립트 코드를 작성해야 했습니다. 파편화 문제가 해결되지 않은 채로 말이죠.

하지만 2006년에 이 문제를 해결할 라이브러리, 제이쿼리^jQuery가 등장합니다. 사용 중인 브라우저를 자동으로 인식하여 그에 맞는 코드를 실행하는 구조를 제이쿼리를 통해, 브라우저 간의 차이를 손쉽게 해결할 수 있었습니다. 제이쿼리 덕분에 프로그래머들은 자바스크립트로 코딩하는 데 있어 안심할 수 있게 되었죠.

그동안 웹 애플리케이션 프로그래밍은 주로 서버측 프로그래밍을 의미했다면, 이 시기부터는 자바스크립트를 이용해 브라우저에서 동작하는 프로그램을 개발하는 방식이 일반적으로 자리잡게 되었습니다. 이후 이 분야를 ‘프런트엔드 개발’이라고 부르게 되었습니다.

이후 자바스크립트는 ① ECMA스크립트를 통한 사양의 표준화 ② HTML5와 마이크로소프트의 새 브라우저 에지 Edge  ③ 브라우저에서 자바스크립트 실행 환경을 분리한 Node.js의 등장 ④ 자바스크립트의 단점을 보완하기 위해  altJS의 등장 등을 통해 다양한 변화와 진화를 겪으며 지금처럼 웹 개발의 핵심으로 도약하게 됩니다.

그리고, 다음 단계의 언어로 성장하기 위해 Vue.js가 등장하게 됩니다.

라이브러리의 한계와 프레임워크의 부상

자바스크립트의 발전에 중요한 역할을 한 제이쿼리는 본래 브라우저 간 차이를 극복하기 위해 탄생했습니다. 하지만 모던 브라우저의 등장으로 이러한 차이가 줄어들면서, 제이쿼리의 역할도 점점 축소되고 있습니다.

그럼에도 여전히 제이쿼리를 사용하는 개발자는 많습니다. ‘글로벌 내비게이션을 클릭하면 하위 메뉴가 표시된다’와 같은 동작을 쉽게 구현할 수 있는 다양한 라이브러리가 제이쿼리에 의존하고 있기 때문이죠.

다만, 라이브러리를 사용할 때는 원하는 동작을 위해 여러 라이브러리를 조합해야 하는 경우가 많고, 이 과정에서 직접 추가적인 코드를 작성해야 합니다. 결국 라이브러리는 편리한 기능을 모아 놓은 도구일 뿐, 모든 상황을 해결해 주지는 않습니다.

그래서 등장한 것이 바로 프레임워크입니다.

애플리케이션의 코드를 처음부터 끝까지 직접 작성하다 보면, 여러 곳에서 비슷한 형태의 코드를 반복해야 하는 경우가 많습니다. 단순히 복사해 붙여넣는 방식으로 해결할 수도 있지만, 이는 비효율적일 뿐만 아니라 유지 보수에도 불리합니다. 프레임워크에는 대부분의 정형화된 코드가 미리 작성되어 있기 때문에, 개발자는 비정형적인 코드 부분, 즉 차이점이 있는 코드에만 집중할 수 있습니다. 

이 차이는 매우 큽니다. 라이브러리에서는 움직임을 제어하는 코드를 프로그래머가 작성하고 필요한 부분만 라이브러리를 사용합니다. 반면 프레임워크에서는 움직임을 제어하는 코드를 프레임워크에 맡깁니다. 이 차이를 제어의 반전 ^{Inversion of Control} (IOC)이라고 합니다.

자바스크립트 프레임워크로 가장 먼저 등장한 것은 2009년 구글이 출시한 앵귤러JS^AngularJS입니다. 2010년에는 커피스크립트 저자가 Backbone.js를 출시합니다. 또한 2011년에는 Ember.js와 리액트^React 가 출시됩니다. Ember.js는 Ember.js 커뮤니티에서 개발하여 출시하고 있지만 리액트는 메타가 주도하여 개발하고 있습니다. 한편 앵귤러JS는 성능 문제와 기능의 복잡함을 개선하기 위해 코드를 처음부터 다시 작성하여 2016년 새로운 프레임워크인 앵귤러 ^Angular 로 재출시되었습니다.

Vue.js의 탄생

이렇게 다양한 프레임워크가 등장하는 가운데 비교적 후발주자인 Vue.js가 2014년에 출시됩니다. Vue는 구글에서 일하고 있었던 개발자 에반 유^{Evan You}가 만들었는데, 에반은 앵귤러JS를 활용한 UI프로토타입을 만들던 중 ‘앵귤러JS의 데이터 바인딩과 데이터에 따른 DOM 조작 등 좋은 점만 채택한 더 가벼운 프레임워크를 만들고 싶다’고 생각하게 됩니다. 이를 실현한 것이 바로 Vue이죠.

Vue는 개발자인 에반의 바램처럼 가볍게 작동합니다. 또한 자바스크립트 코드에서 변숫값을 변경하면 그에 따라 DOM 요소, 즉 디스플레이가 자동으로 변경되는 구조가 핵심 기능으로 내장되어 있습니다. 이 구조는 반응형 시스템 ^{reactivity system} 이라고 합니다. 이 반응형 시스템에 대해서는『Vue3와 타입스크립트로 배우는 프런트엔드 개발』3장에서 예제와 함께 살펴봅니다.)

프로그레시브 프레임워크로서의 Vue

Vue는 반응형 시스템을 핵심으로 하는 DOM 렌더링 기능에 특화된 프레임워크입니다. 하지만 이것은 어디까지나 Vue.js 본체에 대한 이야기이고 Vue의 특징은 Vue.js 본체를 중심으로 다양한 외부 모듈을 추가할 수 있다는 점입니다.

예를 들어 Vue.js 본체에 라우팅 기능을 추가하고 싶다면 Vue 라우터라는 모듈을 추가하면 됩니다. 또는 상태 관리 모듈인 Pinia를 추가하여 데이터를 집중적으로 처리할 수도 있습니다. 또, Vue의 단위 테스트를 수행하려면 Vitest와 Vue Test Utils를 추가합니다. 

물론 이러한 조합은 자유롭게 선택할 수 있으며 항상 모든 것을 설치해놓고 반드시 사용해야 하는 것은 아닙니다. 꼭 필요한 것을 필요한 만큼 이용할 수 있습니다. 이러한 구조를 프로그레시브 ^progressive 프레임워크라고 합니다. Vue.js의 메인 페이지에 크게 소개된 ‘프로그레시브 자바스크립트 프레임워크 (The Progressive JavaScript Framework)’라는 표현이 바로 이런 의미입니다.

Vue 3의 등장과 주요 변화

2020년 9월, Vue.js의 메이저 업데이트로 버전 3이 출시되었습니다. 이번 버전에서는 다양한 새로운 기능과 코드 작성 방식이 도입되었으며, 가장 큰 변화로 내부 소스 코드를 모두 타입스크립트로 다시 코딩했다는 점입니다.

이건 새로운 기능처럼 눈에 보이는 것은 아니지만 상당히 큰 변화입니다. Vue 2 에서도 타입스크립트로 코딩을 지원했지만 Vue.js 내부 코드가 자바스크립트로 되어 있어 타입 안정성이 부족하고, 프로그래머가 작성한 타입스크립트 코드와 완전히 연동되지 않는 경우가 많았기 때문입니다.  하지만 이제 내부도 타입스크립트로 작성됨으로써 더 엄격한 타입 검사가 가능해졌고, 개발 안정성이 크게 향상되었습니다.

물론 Vue 3 출시 이후에도 연동되는 모듈들이 새로운 기능이나 작성 방법, 타입 검사 방식에 대응하는 데는 시간이 걸렸습니다. 이때문에 한동안은 Vue 애플리케이션의 기본 버전은 여전히 Vue 2로 설정되어 있었습니다. 그러다 2022년 2월 7일, 드디어 주요 모듈들이 Vue 3을 지원하면서 Vue 3이 Vue 프로젝트의 기본이 되었습니다. 이와 함께 프로젝트 자체 구조에도 아래와 같이 다양한 변화가 일어나고 있습니다. 

   ☑️Vue 3과 함께 변경된 개발 환경

        ① 프로젝트 생성 도구 변경: Vue CLI → create-vue로 변경

        ② 프로젝트 실행 환경 변경: 웹팩 ^webpack → Vite로 변경

        ③ 상태 관리 기능의 변경: Vuex → Pinia로 변경

        ④ 단위 테스트용 도구 변경: Jest → Vitest로 변경

이제 프런트엔드 개발의 역사를 살펴봤으니, 본격적으로 Vue의 최신 환경을 활용하여 타입스크립트로 Vue 애플리케이션을 만드는 방법을 소개합니다.

위 컨텐츠는 『Vue3와 타입스크립트로 배우는 프런트엔드 개발』의 내용을 재구성하여 작성되었습니다.