[모던 딥다이브] 자바스크립트 2장 자바스크립트란?

2.1 자바스크립트의 탄생

넷스케이프 내비게이터2 (출처:딥다이브)

1995년 넷스케이프 커뮤니케이션즈는 웹페이지의 보조적인 기능을 수행하기 위해 브라우저에서 동작하는 경량 프로그래밍 언어를 도입하기로 결정했다. 이로 인해 탄생한 것이 브렌덴 아이크가 개발한 자바스크립트이다.

자바스크립트는 웹 브라우저인 넷스케이프 내비게이터2에 탑재되었고, 모카로 명명되었다. 그해에 라이브스크립트로 이름이 바뀌었었다가 그해 12월 자바스크립트라는 이름으로 최종 명명되었다.

자바스크립트가 탄생한 뒤 얼마 지나지 않아 자바스크립트 파생 버전인 JScript가 출시되어 자바스크립트는 위기를 맞는다.

 

 

 

2.2 자바스크립트의 표준화

1996년 마이크로소프트는 자바스크립트의 파생 버전인 “JScript”를 인터넷 익스프롤러3.0에 탑재했다. 하지만 JScript와 자바스크립트가 표준화되지 못하고 적당히만 호환되는 문제가 발생했다. 즉, 넷스케이프 커뮤니케이션즈와 마이크로소프트는 자사 브라우저의 시장 점유를 높이기 위해 자사 브라우저에서만 동작하는 기능을 경쟁적으로 추가하기 시작했다. 이로 인해 브라우저에 따라 웹페이지가 정상으로 작동하지 않는 크로스 브라우징 이슈가 발생하기 시작했다.

이로인해, 자바스크립트의 파편화를 방지하고 모든 브라우저에서 정상적으로 동작하는 표준화된 자바스크립트의 필요성이 대두되기 시작했다. 1996년 11월 넷스케이프 커뮤니케이션즈는 컴퓨터 시스템의 표준을 관리하는 비영리 표준화 기구인 ECMA 인터내셔널에 자바스크립트 표준화를 요청했다. 1997년 7월 ECMA-262라고 불리는 표준화된 자바스크립트 초판 사양이 완성되었고, 상표권 문제로 자바스크립트는 ECMAScript로 명명되었다.

 

버전	출시연도	특징
ES1	1997	초판
ES2	1998	ISO/IEC 16262 국제 표준과 동일한 규격을 적용
ES3	1999	정규 표현식, try…catch 예외 처리
ES5	2009	HTML5와 함께 출현한 표준안. JSON, strict mode, 접근자 프로퍼티(getter, setter), 향상된 배열 조작 기능(forEach, map, filter, reduce, some, every)
ES6 (ECMAScript 2015)	2015	let, const, class, 화살표 함수, 템플릿 리터럴, 디스트럭처링 할당, spread 문법, rest 파라미터, Symbol, Promise, Map/Set, iterator/generator, module import/export
ES7 (ECMAScript 2016)	2016	지수(**) 연산자, Array.prototype.includes, String.prototype.includes
ES8 (ECMAScript 2017)	2017	async/await, Object 정적 메소드(Object.values, Object.entries, Object.getOwnPropertyDescriptors)
ES9 (ECMAScript 2018)	2018	Object rest/spread 프로퍼티, Promise.prototype.finally, async.prototype.finally, async generator, for await ... of
ES10 (ECMAScript 2018)	2019	Object.fromEntries, Array.prototype.flat, Array.prototype.flatMap, optional catch binding
ES11 (ECMAScript 2020)	2020	String.prototpye.matchAll, BigInt, globalThis, Promise.allSettled, null 병합  연산자, 옵셔널 체이닝 연산자, for ... in enumeration order

 

 

2.3 자바스크립트 성장의 역사

초창기 자바스크립트는 웹페이지의 보조적인 기능을 수행하기 위해 한정적인 용도로 사용되었다. 대부분의 로직은 주로 웹 서버에서 실행되었고, 브라우저는 서버로부터 전달받은 HTML, CSS를 단순히 렌더링하는 수준이 었다.

*렌더링 rendaering
렌더링이란 HTML, CSS, 자바스크립트로 작성된 문서를 해석해서 브라우저에 시각적으로 출력하는 것을 말한다. 때로는 서버에서 데이터를 HTML로 변환해서 브라우저에게 전달하는 과정(SSR; Server Side Rendering)을 가리키기도 한다.

 

2.3.1 Ajax

자바스크립트를 이용해 서버와 브라우저가 비동기(Asynchronous)방식으로 데이터를 교환할 수 있는 통신 기능인 Ajax(Asynchronous JavaScript and XML)가 XMLHttpRequest라는 이름으로 등장했다. 이전의 웹페이지는 완전한 HTML 코드를 서버로부터 전송받아 웹페이지 전체를 렌더링하는 방식으로 동작했다. 이러한 방식은 변경할 필요가 없는 부분까지 포함된 HTML코드를 서버로부터 다시 전송받기 때문에 불필요한 데이터 통신이 발생하고, 변경할 필요가 없는 부분까지 처음부터 다시 렌더링해야 하기 때문에 성능면에서도 떨어진다.

Ajax는 웹페이지에서 변경할 필요가 없는 부분은 다시 렌더링하지 않고, 서버로부터 필요한 데이터만 전송받아 변경해야 하는 부분만 한정적으로 렌더링하는 방식이 가능해졌다. —> 웹 브라우저에서도 데스크톱 애플리케이션과 유사한 빠른 성능과 부드러운 화면 전환이 가능해졌다.

 

2.3.2 jQuery

다소 번거롭고 논란이 있던 DOM(Document Object Model)을 더욱 쉽게 제어할 수 있게 되었고, 크로스 브라우징 이슈도 어느정도 해결되었다.

 

2.3.3 V8 자바스크립트 엔진

더 빠르게 동작하는 자바스크립트 엔진이 대두되면서, 2008년 등장한 구글의 V8 자바스크립트 엔진은 이러한 요구에 부합하는 빠른 성능을 보여주었다. 자바스크립트는 데스크톱 애플리케이션과 유사한 사용자 경험(UX)을 제공할 수 있는 웹 애플리케이션 프로그래밍 언어로 정착하게 되었다. 이러한 자바스크립트의 발전으로 과거 웹 서버에서 수행되던 로직들이 대거 클라이언트로 이동했고, 이는 웹 애플리케이션 개발에서 프론트엔드 영역이 주목받는 계기로 작용되었다.

 

2.3.4 Node.js

브라우저의 자바스크립트 엔진에서만 동작하던 자바스크립트를 브라우저 이외의 환경에서도 동작할 수 있도록 자바스크립트 엔진을 브라우저에서 독립시킨 자바스크립트 실행 환경이다. 다양한 플랫폼에 적용할 수 있지만 주로 서버 사이드 애플리케이션 개발에 사용되며, 필요한 모듈, 파일 시스템,  HTTP 등 빌트인 API를 제공한다.

비동기 I/O를 지원하며 단일 스레드 이벤트 루프 기반으로 동작함으로써 요청처리 성능이 좋다. 따라서 Node.js는 데이터를 실시간으로 처리하기 위해 I/O 가 비번하게 발생하는 SPA(Single Page Application)에 적합하다. 하지만 GPU사용률이 높은 애플리케이션에는 권장하지 않는다.

이제 자바스크립트는 크로스 플랫폼을 위한 가장 중요한 언어로 주목받고 있다. 웹은 물론 모바일 하이브리드 앱(PhoneGap, Ionic), 서버 사이드(Node.js), 데스크톱(Electron), 머신러닝(TensorFlow.js), 로보틱스(Johnny-Five) 환경을 위한 프로그래밍 언어이다.

 

2.3.5 SPA 프레임워크

변경에 유연하면서 확장하기 쉬운 애플리케이션 아키텍쳐를 구축하기 위해서, (성능 향상 및 사용자 경험 제공) 프레임워크가 등장했다.

이러한 요구에 발맞춰 CBD(Component based development) 방법론을 기반으로 하는 SPA(Single Page Application)가 대중화되면서 Angular, React, Vue.js, Svelte 등 다양한 SPA 프레임워크 / 라이브러리 또한 많은 사용층을 확보하고 있다.

*CBD 방법론 (Component based Development)

컴포넌트의 재사용을 통해 개발 생산성 향상, 개발 기간 단축 및 신뢰성 높은 소프트웨어를 생산할 목적으로 컴포넌트를 생성, 조립하여 소프트웨어를 개발하는 개발 방법론

1) 객체지향 방법론의 문제점 해결
- 기술적 측면: binary 형태의 표준이 없고 OOP의 각 객체 같은 컴파일러 사용
- 프로세스 측면: 재사용 사례거의 없고 대규모 프로젝트에서는 확장성이 떨어짐

2)  소프트웨어 개발 패러다임의 변화
- 고품질, 생산성 및 엔지니어 위주 -> 견고성/재사용성/상호 운영성 / 적시성 및 사용자 위주
- 구조적 방법론 -> 정보공학 방법론 -> 객체지향 방법론 -> CBD 방법론

 

*SPA(Single Page Application)

서버에서 HTML을 생성하고 브라우저는 출력하기만 하는 전통적인 형태가 아니라, 서버가 하던 대부분의 작업을 브라우저에서 처리하는 웹 애플리케이션 개발 방법이다.

즉, SPA에서는 서버가 처리하던 HTML 생성부터 내비게이션 처리, 사용자 인증에 따른 분기처리, 검색 등을 JavaScript로 처리하게 된다.

SPA는 첫로딩 때 모든 스크립트 파일을 불러오고 사용자 요청에 따라 변경이 필요한 부분만 변경해 줘 불필요한 로딩을 줄여준다. 이런 모든 행위는 서버에서 하는 것이 아닌 자바스크립트 엔진이 있는 브라우저에서 해주게 된다.

필요한 부분은 RESTAPI를 이용해 JSON(자바스크립트 객체 양식)으로 들여와 진다.

요약) 하나의 페이지(HTML)에 클라리언트 단에서 스크립트 언어가 DOM 요소에 요청을 보내 끊임없이 사용자 요청을 처리해준다는 것이다.

 

2.4 자바스크립트와 ECMAScript

ECMAScript는 자바스크립트의 표준 사양인 ECMA-262를 말하며, 프로그래밍 언어의 값, 타입, 객체와 프로퍼티, 함수, 표준 빌트인 객체 등 핵심 문법을 규정한다.

자바스크립트는 일반적으로 ECMAScript를 아우르는 개념 (출처: 딥다이브)

 

 

2.5 자바스크립트의 특징

자바스크립트는 HTML, CSS와 함께 웹을 구성하는 요소 중 하나로 웹 브라우저에서 동작하는 유일한 프로그래밍 언어이다.

자바스크립트는 개발자가 별도의 컴파일 작업을 수행하지 않는 인터프리터 언어(interpreter language)다. 대부분의 모던 자바스크립트 엔진은 인터프리터와 컴파일러의 장점을 결합해 비교적 처리 속도가 느린 인터프리터의 단점을 해결했다. 인터프리터는 소스코드를 즉시 실행하고, 컴파일러는 빠르게 동작하는 머신 코드를 생성하고 최적화한다. 이를 통해 컴파일 단계에서 추가적인 시간이 필요함에 더욱 빠르게 코드를 실행할 수 있다.

 

*인터프리터 언어 vs 컴파일러 언어

자바스크립트는 일반적으로 인터프리터 언어로 구분한다. 전통적인 컴파일러 언어와 인터프리터 언어를 비교하면 다음과 같다.

컴파일러 언어	인터프리터 언어
코드가 실행되기 전 단계인 컴파일 타임에 소스코드 전체를 한번에 머신 코드로 변환한 후 실행한다.	코드가 실행되는 단계인 런타임에 문 단위로 한 줄씩 중간 코드인 바이트코드로 변환한 후 실행한다.
실행 파일을 생성한다.	실행 파일을 생성하지 않는다.
컴파일 단계와 실행 단계가 분리되어 있다. 명시적인 컴파일 단계를 거치고, 명시적으로 실행 파일을 생성한다.	인터프리트 단계와 실행 단계가 분리되어 있지 않다. 인터프리터는 한줄 씩 바이트코드로 변환하고 즉시 실행한다.
실행에 앞서 컴파일은 단 한번 수행된다.	코드가 실행될 때마다 인터프리트 과정이 반복 수행된다.
컴파일과 실행 단계가 분리되어 있으므로 코드 실행 속도가 빠르다.	인터프리트 단계와 실행 단계가 분리되어 있지 않고 반복 수행되므로 코드 실행 속도가 비교적 느리다.

<표> 컴파일러 언어와 인터프리터 언어의 비교(출처: 딥다이브)

 

자바스크립트는 명령형(imperative), 함수형(functional), 프로토타입 기반(prototype-based) 객체지향 프로그래밍을 지원하는 멀티 패러다임 프로그래밍 언어다.
자바스크립트는 클래스 기반 객체지향 언어보다 효율적이면서 강력한 프로토타입 기반의 객체지향 언어다.