Posts ECMAScript, 자바스크립트 엔진, Babel과 Webpack 스토리 살펴보기
Post
Cancel

ECMAScript, 자바스크립트 엔진, Babel과 Webpack 스토리 살펴보기


ECMAScript, 자바스크립트 엔진, Babel, Webpack 까지


자바스크립트와 관련된 것들을 접하다 보면 ES6, ES2017 문법과 같은 말을 보거나, Babel, Webpack 이라는 단어도 쉽게 볼 수 있습니다. 그런데 이들이 자바스크립트와 웹 개발에서 어떤 관련이 있고, 어떤 역할을 하는지 그 정의만 알고 있자니 마음에 쉽게 와닿지 않았습니다.

찾아본 결과 많은 분들의 자세하고 좋은 글들을 읽을 수 있었습니다. 그것들이 탄생하게 된 이유부터, 어떤 목적을 가지고 있는지 알면 은근히 재밌으면서도(?) 나중에 다시 떠올리기도 쉬웠습니다. 어떤 것이든 스토리텔링이 있어야 기억에 잘 남는 것 같습니다.

그래서 저도 이러한 내용을 정리해 두어서 제 머릿속에도 다시 한번 담고, 블로그에 방문해 주실 누군가에게도 도움이 되었으면 하는 바램에서 글을 작성하게 되었습니다.

ECMAScript 부터 시작해서 이와 연관되는 것들을 차례대로 다뤄보고자 합니다. 키워드는 다음과 같습니다.

ECMAScript, JavaScript, 자바스크립트 엔진, 스크립트 언어, JIT 컴파일, Babel, Webpack

재미있던 점은 이들이 줄줄이 엮여서 의미를 이루는 느낌이 들었다는 점입니다. 그냥 뉴스기사 읽듯이 편하게 읽어 주세요 😀


🎯 ECMA(European Computer Manufacturers Association)

ES5, ES6 이라는 단어를 제일 많이 볼 수 있을 텐데 ESECMAScript의 줄임말입니다. 그러면 여기서 ECMA가 무엇일까요? 위에 제목에서도 눈치채신 분들이 있겠지만 Association이란 단어에서 무언가 협회, 기구 같은 것을 칭하는 것처럼 보입니다.

위키백과에서는 ECMA를 다음과 같이 설명하고 있습니다. (출처)

Ecma 인터내셔널(영어: Ecma International)은 정보와 통신 시스템을 위한 국제적 표준화 기구이다…(중략)

…..

Ecma 인터내셔널은 다수의 표준을 책임지고 있다. 다음은 그 중 일부의 목록이다.

즉, ECMA정보 통신 시스템을 위한 국제 표준화 기구이고, ECMAScript는 ECMA에서 관리하는 표준인 ECMA-262 에서 정의한 스크립트 언어 규격(명세)을 말하는 것입니다.

위에 항목들을 보시면 개발자들에게 정말 익숙한 거의 모든 것들을 ECMA라는 표준화 기구에서 관리하고 있음을 알 수 있었습니다. 아스키 코드부터 시작해서 파일 시스템, C언어들의 규격, JSON, … 정말 많습니다.

이제 ECMAScript는 ECMA-262 표준에서 정의한, 표준화된 스크립트 언어 규격임을 알게 되었습니다.


🎯 ECMAScript 그리고 JavaScript

  • ECMAScript

ECMA-262는 1997년 6월 처음 초판이 제정되어, 가장 최근인 2019년 6월까지 판 업데이트가 이루어지고 있습니다. 명칭은 ES 뒤에 년도를 붙이는 방식이 ES 6판, 즉 ES2015부터 사용되었습니다.

현재까지 대부분의 브라우저는 ES5(2009년 12월 첫 배포)를 거의 다 지원한다고 생각하면 되고, ES6(ES2015) 까지도 상당수 지원하고 있습니다.

ES6에서 생긴 문법 중 가장 익숙하실 것으로 예상되는 것들로는 화살표 문법let, const 변수 사용 등이 있습니다.


  • JavaScript

자바스크립트(JavaScript)는 ECMAScript의 표준 사양을 준수하는 스크립트 언어입니다.

이제 자바스크립트와 ECMAScript와의 관계나 의미를 명확히 아시게 되었을 것 같습니다.

위에서 스크립트 언어라는 용어가 나와서 잠시 다루고 넘어가고자 합니다.


📜 스크립트 언어란?

이미 존재하는 어플리케이션이나 소프트웨어를 제어하기 위해 사용하는 언어들을 일컬을 때 사용하는 말입니다. 예를 들어 웹 구현과 구동을 위해 자바스크립트가 있고, 플래시에서는 플래시 제어를 위해 액션 스크립트가 있습니다. 이들이 모두 스크립트 언어에 해당합니다.

간혹 스크립트 언어 = 인터프리터 언어라고 생각하실 수 있지만, 인터프리터 언어는 오히려 컴파일 언어와 비교되야 하는 대상입니다.

컴파일 언어는 C, C++과 같이 실행 전 컴파일러가 기계어로 변환하는 컴파일 작업을 거친 뒤에 하나의 응용 프로그램(목적 프로그램)이 작동하는 방식인 반면, 인터프리터 언어사전에 컴파일 과정을 거치지 않고 코드를 그 때마다 한 줄씩 기계어로 번역하면서 실행하는 방식입니다.

물론 런타임 상황에서는 컴파일 언어로 짠 코드의 경우 이미 전부가 기계어로 번역되어 있는 상태이므로 인터프리터 언어보다 빠른 실행 속도를 가집니다. 각 언어마다 사용 목적이 다른 것입니다.

여기서 많은 인터프리터 언어들이 스크립트 언어로써 사용되게 됩니다. 스크립트 언어의 사용 목적 자체가 컴파일 언어의 방식과는 어울리지 않았고 인터프리터 언어 방식이 더 적합했기 때문입니다.


🎯 자바스크립트 엔진(JavaScript engine), JIT 컴파일

자바스크립트 엔진은 자바스크립트 언어로 작성된 코드를 해석하는 인터프리터 혹은 프로그램을 말합니다.

자바스크립트 엔진은 그 종류가 다양한데, 크롬은 V8, 파이어폭스는 스파이더몽키 등의 자바스크립트 엔진을 사용하고 있습니다. 즉 브라우저마다 채택한 엔진이 다른 경우를 볼 수 있습니다. (참고로 자바스크립트 엔진 자체스파이더몽키의 경우 C, C++로 구현되어 있고 V8 도 C++로 구현되어 있습니다.)

자바스크립트가 멀티태스킹을 구현하는 방법에서 자바스크립트 엔진이 돌아가는 방식을 알게 되는데, 그 때 등장하는 그 자바스크립트 엔진이 맞습니다.

여기서 크롬의 엔진인 V8은 JIT 컴파일 방식인데, 이것은 온전한 전통적인 인터프리터 방식과는 사뭇 다릅니다.

  • JIT(just-in-time 컴파일)

위에서도 말했던 컴파일 언어와 인터프리터 언어의 모습이 혼합된 방식입니다.

인터프리트 방식의 경우 실행 시점에 기계어로 번역한다고 앞서 말씀을 드렸습니다. 그런데 같은 함수 혹은 같은 코드는 매번 기계어로 번역하는 것보다, 캐싱을 해놓으면 나중에 또다시 기계어로 번역할 필요 없이 그것을 가져다 쓰기만 하면 됩니다. 즉 같은 것은 매번 번역하지 않는 것입니다. 이것이 JIT 컴파일의 방식입니다.

자바 컴파일러는 자바 프로그램 코드(.java)를 바이트코드(.class)로 변환합니다. 이 때 바이트코드는 아직 기계어는 아닙니다. 이 바이트코드를 실행하는 시점에 자바 가상 머신(JVM)은 바이트코드를 JIT 컴파일 방식으로 기계어 변환을 합니다. 그래서 자바를 컴파일 언어이자 인터프리터 언어라고 부르기도 합니다.


🎯 Babel과 Webpack

  • Babel

ES5, ES6과 같은 명칭은 이제 확실히 아셨을 것 같습니다. 새로운 규격은 계속해서 나오지만 아직까지도 ES6을 온전히 지원하지 않는 브라우저도 있습니다. 이런 식으로 브라우저 종류가 다양하다 보니, 새로운 문법을 지원하지 않는 브라우저에서 발생하는 호환성 문제가 발생하게 됩니다.

이것들을 브라우저 간 호환성(Cross Browser compatibility) 문제라고 합니다. 여기서 호환성이란 단어에 주목할 필요가 있습니다.

크로스 브라우저 이슈를 해결하기 위한 목적이 “모든 브라우저마다 100% 똑같이 보이게 하자!” 는 것이라기 보다는, “특정 브라우저에 치우치지 않고 모든 브라우저에서 기능이 정상적으로 동작하게 하자!” 는 것이 목적이라고 할 수 있습니다.

물론 최신 브라우저들은 ES6을 자체적으로 지원하지만, 그보다 구버전을 사용하거나 다른 브라우저(예를 들면 IE…)들은 예외적으로 사용자들이 어려움을 겪을 수 있습니다.

이러한 예시들처럼 현재 존재하는 브라우저들에서 각자 조금씩이라도 발생할 수 있는 호환성 이슈를 해결하기 위해 Babel이 등장하게 됩니다.

ES6(ES2015) 이상의 문법을, ES5 버전까지만 지원하는 브라우저에서도 실행될 수 있도록 트랜스파일링 해 주는 역할을 합니다. Babel의 역할은, 공식 사이트에 다음과 같이 깔끔하게 나와 있습니다.

바벨은 자바스크립트 컴파일러입니다.

Babel은 주로 ECMAScript 2015+ 코드를 현재 및 이전 브라우저 또는 환경에서 자바 스크립트의 이전 호환 버전으로 변환하는 데 사용되는 도구 체인입니다.

(여기서 트랜스파일, 컴파일 용어가 헷갈리실 수 있는데, 컴파일이 좀 더 큰 범위라고 생각하시면 됩니다. 트랜스파일이 컴파일의 범주에 속한다고 볼 수 있으며, 트랜스파일은 거의 비슷한 레벨로 변환이 되고, 컴파일은 어떤 언어가 거의 다른 레벨로 변환이 되는 것을 주로 일컫게 됩니다.)


  • 모듈 번들러, Webpack

자바스크립트에서는 요즘 모듈을 자주 작성하고 매우 유용하게 사용합니다. 여기서 말하는 모듈이란 단순히 스크립트 파일 하나를 말하지만, 코드에서 import, export 등의 키워드로 다른 모듈(파일)들을 불러와서, 그 내부에 있는 함수들을 자유롭게 호출할 수 있는 기능을 의미하기도 합니다. 리액트로 웹 페이지를 만들다 보면 import, export 등을 특히 많이 접할 수 있습니다.

그런데 이 모듈 시스템 조차도 사실 ES6(ES2015)에서 본격 표준화 및 지원되기 시작한 문법입니다. 그래서 어떤 브라우저가 ES6을 지원한다고 해도 아직까지 새로 생긴 Module 기능을 온전히 지원하지 않는 경우도 있습니다.

이처럼 하나의 파일에 포함된 여러 모듈 간의 의존성을 모든 브라우저에서 인식할 수 있게끔 하나의 파일로 묶어 주는 역할모듈 번들러 가 하게 됩니다.

babel 이야기를 하다가 갑자기 모듈 번들러 이야기가 나왔다고 생각하실 수도 있지만, 이 둘은 같이 묶어서 잘 이야기되는 것들이기도 하고, 무엇보다 브라우저 호환성 이야기를 할 때 같이 기억하시면 이해에 큰 도움이 될 것 같아서 적게 되었습니다.

모듈 번들러나 webpack에 관해서는 좀 더 쓸 이야기가 많을 것 같아서 다른 포스팅 때 다루려고 합니다.


이처럼 ECMAScript의 등장 배경부터 살펴보다 보니, 자연스럽게 자바스크립트와 관련된 정보들을 차례대로 정리해 볼 수 있었습니다.

아직 이들이 무슨 역할인지 자세히 모르셨던 분들에게 큰 도움이 되었으면 좋겠습니다!


도움이 된 블로그 및 자료

[CSS-in-JS] styled-components에 대하여

[백준] 1202번 - 보석 도둑