Javasrcipt와 관련된 프레임워크, 기술 흐름에 대한 좋은글

JavaScript와 연관된 기술들이 생긴 배경과 설명이 잘 설명된 글이라서 실어 왔습니다! 혹시나 궁금하신 분들은 참고 하시길 바래요!

JavaScript의 혁명

마인드맵으로 그려보았다.

먼저 물음을 던져보자. 프로그래머로써 JavaScript는 무엇이라고 생각하는가? 아마도 대부분은 그저 홈페이지를 간단히 제어하기 위한 단순한 문법의 언어라고 생각할 것이다. 아주 단순하게, 폼의 각 입력컨트롤에 입력된 값들이 제대로 입력된 것인지 체크하기 위하여 사용되는 언어쯤이라고 생각하거나, 아니면, HTML이 기본적으로 제공해주는 컨트롤들을 보완해주기 위한 도구쯤이라고 생각할지도 모르겠다. 

JQuery처럼 좀더 복잡하고 정교하게 웹페이지를 제어할 수 있고, 또 다양한 컨트롤들을 제공하는 역할을 JavaScript가 하고 있다는 것을 알고 있지만, Java와 같은 일반적인 범용언어에 비해서, JavaScript는 왠지 프로그래머가 하기에는 걸맞지 않은 언어라고 생각할 수도 있다. 요즘의 웹페이지 제작에서 HTML과 CSS를 전문적으로 담당하는 퍼블리셔라는 분야의 기술자들이나 다뤄야할 지도 모를 나쁘게 이야기하면 비 프로그래머들이나 다루는 언어라고 생각하는 것이 보통일 수도 있다.

사실 그랬다. 나도 그랬고. 브라우저에서 기생하여 돌아가는 자바스크립트는 과거에 3000번의 for루프만 돌려도 처리성능이 현격하게 떨어지는 언어였다. 잘써봐야 정적인 HTML홈페이지를 좀더 동적으로 만들어주는 정도의 역할이 고작이었으니까. 그래서 X-internet이라는 개념의 기술이 등장하였고, RIA(Rich Internet Application)이라는 개념의 기술들이 웹2.0이라는 문과적 레토릭에 사로잡힌 애매모호한 구호를 배경으로 인기를 누렸던 것 아니었던가?

그러던 JavaScript가 변하였다. 그 스스로의 한계를 전세계의 수많은 프로그래머들이 엉뚱한 발상들 속에서 깨뜨리고 새로운 나아가기 시작하였다. 그리고 신세계가 만들어지기 시작한 것이다.

JavaScript를 Java나 python과 같이 좀더 범용적인 언어로 만들어서, 모든 것을 JavaScript로 개발하면, 이 언어 저 언어 할 필요없이, 간편한 자바스크립트만 가지고 뭔가를 할 수 있지 않을까? 하는 생각에서 시작한 Node.JS와 브라우저에서만 자바스크립트를 돌릴 필요는 없지 않느냐 하는 생각에서 구글에서 만든 독립적(Standalone) 자바스크립트 엔진인 V8이 바로 혁명의 시작이다.  이 두가지로 인해서, JavaScript는 범용적 언어로써 어느날 갑자기 우뚝 서게 된다.

구글의 JavaScript엔진 V8

V8이라는 이름은, 자동차에 흥미를 가진 사람이면 금방 눈치채겠지만, 바로 자동차의 V형 8기통 엔진인 V8엔진에서 유래한다고 한다. V8엔진은 대형승용차의 엔진으로 많이 사용되는 것에서도 알수 있듯이, 구글에서 만든 신형 자바스크립트엔진 V8은 그만큼 뛰어난 성능과 역할을 가지고 있다. 원래는 크롬 브라우저의 자바스크립트 엔진으로 개발되었지만, 독립적으로 작동하여 자바스크립트를 해석 처리할 수 있고, C++로 작성된 어플리케이션에 내장되어 자바스크립트를 처리할 수 있다. 

브라우저에 분리되어 독립적으로 작동할 수 있다는 것은, 이 엔진을 이용하면, 브라우저에서 작동하는 웹어플리케이션이 아니더라도 자바스크립트를 범용적 언어로 사용할 수 있음을 의미한다. 즉 Curl로 치면, Curl RTE에 해당하는 역할을 이것이 한다는 것이지. 이 얼마나 매력적인 일이란 말인가? 굳이 잘 모르는 언어를 사용하기 위해서 버추얼 머신을 설치하여 그 언어를 사용하는 것 보다, 이미 친숙하고 잘 알려진 언어인 JavaScript로 모든 것을 할 수 있다면, 많은 개발자들이 새로운 언어를 익히는 수고를 안하고도 많은 것을 구현할 수 있다는 것이 얼마나 환상적인 일이란 말인가? 2008년 이 엔진은 처음으로 세상에 첫선을 보이게된다.

Common JS, 그 꿈의 실현 - Node.js

V8의 등장은 범용적 언어로써의 JavaScript인 CommonJS의 탄생을 촉발시킨다. JavaScript를 범용적언어로써 사용하고자 하는 움직임이 2009년 무렵 태동하게되고, 이 움직임은 CommonJS의 스펙을 정하게되는데, 이 CommonJS의 스펙을 가지고 구체적인 산출물로써 태어난 것이 Node.js이다. 이 Node.js로 인해서 우리는 범용적 언어로써, JavaScript를 사용할 수 있게된다.  Node.js는 서버측 프로그래밍 언어로써 그 빛을 발하기 시작하는데, 그래서인지 Node.js는 자바스크립트의 서버 버전이라고도 오해를 받지만, 그 근본적인 목표는 자바스크립트의 범용성 확보이다. 

Node.js가 확산되면서, Node.js기반으로 자바스크립트 라이브러리들이 속속 개발되기 시작하는데, 이 라이브러리들을 관리하기 위한 패키지 관리툴이 npm이다. 마치 리눅스에서 패키지를 설치하기 위하여 사용하는 명령어처럼, Node.js만 설치되어있으면, npm이라는 명령어를 콘솔상에서 입력하여 원하는 패키지 라이브러리들을 설치할수가 있다.

즉 이 Node.js가 없으면, 지금 시대의 JavaScript 프로그래밍은 불가능하다고 봐도 과언이 아닐정도이다.

JavaScript언어의 발전, 그리고 새로운 보완 언어들의 등장.

JavaScript라고 불리우는 언어들은 그 원래 스펙은 ECMAScript를 기반으로 한다. ECMAScript란 European Computer Manufacturers Association 라고하는 단체에서 만드는 JavaScript표준 스펙이다. 즉 이 스펙을 가지고 각 브라우저 제작사들은 JavaScript엔진을 만들게된다. 스펙을 어떻게 구현하느냐는 전적으로 브라우저 제작사들 마음이니까, JavaScript로 코딩할때에, 브라우저 호환성 문제가 발생하게 된다. 

현재 공식 최신 버전은 ECMAScript 2015이고 작년에 발표되었다. 그 직전 버전은 ECMAScript5인데, 버전 표기가 다른 이유는, ECMAScript 2015 부터 좀더 많은 변화를 반영시킬 예정이라, 버전 변화가 잦을 것으로 예상하여, 전통적으로 1부터 시작한 버전 매김을 연도로 바꾸기로 했단다. 이 사실만으로도 앞으로 JavaScript가 엄청난 변화가 있을 것임을 예고하는 것인데, 실제로 ECMAScript2015부터 가히 혁명적이라고 할 수 있는 언어의 변화가 일어났다.

ECMAScript2015는 웹상의 문서들에서는 ES6라고 생략해서 부르는 경우가 많으니 참고하도록 하자. ES5(ECMAScript5)까지는 근본적인 언어의 변화가 없었다. 그러나 ES6부터 완벽한 Class개념의 도입, 변수 scope문제 해결, let 지시자의 등장, 패키지 import개념의 등장 등, 범용적 언어로써 제대로 기능하기 위한 근본적 언어의 혁신이 추가되었다.

ES6는 아직 모든 브라우저에서 100% 지원하지 않으므로, 이것으로 코딩해서 바로 이용할 수는 없다. 동작된다는 확신이 없기 때문이다. 그렇다면, 이런 자바스크립트의 혁명은 찻잔속의 폭풍일뿐이지 않은가라고 생각하겠지만, 전세계의 개발자들이 그냥 멍청히 있을리가 없지 않은가? 이것에 대한 대책은 뒤에서 호환성 확보와 관련하여 이야기하도록 하자.

지금까지의 자바스크립트, 즉 ES5까지의 JavaScript 언어는 실제로 객체지향언어가 아니고, 순수 스크립트 언어라서, 개발시에 불편함이 한두개가 아니었다. JavaScript에서 사용되던 클래스 비슷한 꼴의 객체개념의 이용, 변수 Scope문제는 타언어 개발자들의 머리속을 아프게하는 놈이었다. 이런 단순함에서 오는 복잡함 난잡함, 디버깅 등의 개발 생산성을 떨어뜨리는 문제점들을 해결하기 위해서, 새로운 보완언어들이 등장하게 되는데, 대표적으로 CoffeeScript와 TypeScript를 들 수 있는데, CoffeeScript는 속되게 이야기해서 한물 가고 있는 언어로 평가 받는 경우가 많아서, TypeScript에 대해서 간단히 이야기 해보자. 

TypeScript에서는 JavaScript를 극복하기 위해서 Microsoft에서 개발한 오픈소소 언어이다. 마이크로소프트가 왠일로 오픈소소를 하냐고 할지도 모르겠다만, 세상은 오픈소스로 모든것이 돌아가게끔 변하고 있고, 마이크로소프트도 이런 대세에 거스를수는 없었겠지.

아무튼 TypeScript는 이름에서 알수 있듯이, Type지정이 가능하다. 변수 선언시 타입을 지정하고, 그 해당 타입의 값이 변수에 할당되지 않으면 에러가 난다는거지. 변수 타입 지정은 프로그래밍에서 버그와 오류를 양산하는 것을 막아주는 중요한 역할을 하므로, 이것이 있다면 우리는 삽질을 덜 할 수 있을 것이다. 

자바스크립트의 근본적 한계점들을 하나씩 보완해가면서 만든 TypeScript는 재미있는게, 순수 자바스크립트 그러니까 ES5기반의 자바스크립트 코드를 그대로 갖다써도 정상작동한다는 점이다. 그래서 혹자는 TypeScript는 ES+라고 이름붙이는 것이 더 합당하지 않냐고 할 정도이다. 그렇다보니 TypeScript는 미래의 JavaScript를 지금 사용하는 것이라고 까지 표현된다. 실제로 마이크로소프트에서 개발한 언어지만, 구글에서도 TypeScript를 밀고 있기 때문에(AngularJS 2에서는 TypeScript가 공식 지원언어이다) TypeScript의 스펙들이 미래의 JavaScript의 표준으로 정해지지 않을까하는 생각을 많은 사람들이 하고 있을 정도이다.

TypeScript는 별도의 포스트에서 다룰 것이라 깊게는 이 정도로만 이야기하고 넘어가지만, 참고로 Curl을 개발했던 개발자들은 TypeScript의 문법이 친숙하게 느껴질 수 있다. 흡사한 부분이 많다.

자, 그렇다면, 이렇게 새로 확장된 자바스크립트와, 새로 탄생한 언어들을 우리는 과연 어떻게 이용할 수 있단 말인가? 이 브라우저에서 되는데, 저 브라우저에서 안된다면 어떻게 한다는 말인가? 

Babel 그리고 Webpack, browserify

오픈소스의 장점은 수많은 전세계의 개발자들이 함께 고민하고 함께 만들어 간다는 점이다. 누구나 알고 있는 사실이지만, 실제로 오픈소스들을 접하다보면 이말에 다시한번 공감하게 된다. 앞서 제시한 호환성 확보의 문제는 바로 이것을 해결하는 또 다른 오픈소스들이 해결해주고 있다. 

먼저, 어얼리어답터인 성격의 프로그래머라면, 새로운 문법을 제공해주는 ES6(ECMAScript2015)나 ES7(ECMAScript2016)를 써보고 싶어 안달이 날 것이다. 그런데 이것이 모든 브라우저에서 돌았으면 좋겠다라는 소망도 있겠지. 그래서 만들어진 것이 Babel이다. Babel은 ES6 코드를 ES5로 변형시켜준다. 

즉 근본적으로 호환성 확보문제의 해결은 해당 코드들을 모든 브라우저에서 돌도록 소스코드를 재생산해버리는 방식을 취한다. Babel도 그렇고 browserify, webpack도 그러하다. browserify와 webpack은 의존 라이브러리들을 하나의 파일로 만들어서 웹페이지에서 구동될 수 있는 구조로 배포버전을 만들어주는 역할을 한다. webpack은 browserify보다 더 많은 일을 할 수 있으므로, 일반적으로 webpack을 사용한다. babel은 webpack과 함께 이용하게 된다. 

이러한 호환성 라이브러리들은 별도로 우리가 해당 개발사이트가서 어떤 설치파일을 받는게 아니라, node.js가 설치되어있다면, npm을 이용하여 간편히 패키지를 설치하고, 이용할 수 있다.

SPA와 프레임워크의 등장

SPA란 Simple Page Application이란 말의 약어이다. 전통적인 웹페이지들은 다수의 HTML파일들로 구성되어있고, 메인화면에서 메뉴를 누르면 해당 메뉴에 있는 URL이 호출되어 그 페이지를 보여주는 방식이 일반적인 방식이이었다.

그런데 이러한 방식은 화면상에서 변경이 필요한 부분만 동적으로 처리하면 되면 끝날일을 불필요하게 전체 화면을 요청해야한다라는 단점이 존재하고 있었고, 데스크탑 어플리케이션 처럼 화면 구성 요소간의 연계와 표현들이 부족하다는 한계점을 안고 있어서, 이것을 웹어플리케이션에서는 극복이 안되는가 하는 것은 그동안의 고민거리였다.

사실 이것을 해결한 놈이 RIA였다. HTML기반 기술들이 JavaScript를 비롯하여, 이 웹어플리케이션의 한계를 극복할 능력이 없었다. 그래서 나타난것이 Curl이라던가, Flex, Xplatform 등의 기술들이었지. 그런데 자바스크립트의 혁명,  HTML5의 등장은 그 한계를 단숨에 뒤집어 엎을 수 있다라는 확신을 개발자들에게 안겨준거지. 그래서 데스크탑 어플리케이션 처럼 브라우저에 메인 화면만 로딩하고, 내부 구성은 자바스크립트로 표시하고 제어가능 하도록 하는 웹어플리케이션을 SPA라고 부른다.

SPA는 결국 Curl에서 만든 Curl애플릿의 구조와 동일한 것으로 보면 이해가 빠를 것이다.
이 SPA를 구현하기 위해서, 개발자들이 일일이 하나하나 코드를 작성해서 A-Z까지 다 만드는 것이 아니라, 구축과 관리를 편리하도록 하고, 구조의 명확성과 일관성을 위해서 개발된 것이 프레임워크이다. 프레임워크는 화면 레이아웃의 구성과 각 요소간의 통신 그리고 외부통신의 처리까지를 포함하는 것이 일반적이다.

참고삼아 말하지만, 프레임워크와 라이브러리는 다른 것이다. JQuery처럼 다양한 컨트롤과 외부통신 함수들을 제공하는 라이브러니는 어플리케이션의 구조와는 아무 인연이 없다. 일관적인 화면과 데이터 흐름을 제어하는 구조체가 프레임워크이다.

초창기에 등장하여 히트친 것이 ExtJS. 그러나 자바스크립트 기술의 진보와 더불어 많은 프레임워크들이 흥망성쇠를 거듭하는데, 현재 가장 널리 이용되는 것이 Google에서 만든 AngularJS. 이것은 현재 버전2까지 나와있고, 구글에서 만들어 배포하는 오픈소스인지라, 구글이라는 인지도 덕분에 많은 이용자들을 가지고 있지만, 글쎄... 사용하기가 쉽지는 않다.

AngularJS는 PHP와 같은 웹개발언어에서 사용하던 템플릿개념의 자바스크립트 버전이라고 보면 이해에 도움이 될 것이다. 즉 정적인 HTML기반의 템플릿 파일이 있고, 템플릿내에서 여러가지 일들을 하기 위한 별도의 문법이 존재한다. 이런 방식은 별도의 문법을 익혀야한다라는 부담감과, 화면 각 요소들을 별도의  HTML파일로 분리하다 보니, 실제 프레임워크 처리를 담당하는 JavaScript코드에서 관리하기가 쉽지가 않다.

그래서 요즘 혜성같이 등장하여 급속도로 세력을 확장하고 있는 것이 ReactJS이다.

Facebook의 분투 - React시리즈

SNS의 대명사로 불리울 만큼 친목 도모 서비스나 하는 페이스북이 뭔 기술을 가지고 있나할수도 있겠지만은, 나름대로 페이스북은 자신들의 거대한 서비스를 기반으로 습득한 노하우를 투여하여 IT기술력에도 영향력을 넓히려 하고 있는데, 그 가장 대표적인 것중 하나가 ReactJS이다.

ReactJS의 사상은 프레임워크에서 한발 물러나서, 화면과 데이터 처리까지 일괄적인 구조체를 갖는 거대한 프레임워크보다는, 화면중심에서 생각해서, 화면의 표시와 제어를 자바스크립트가 담당하도록 하는 것에 주안점을 두고 있다. 그래서 혹자는 ReactJS는 프레임워크가 아니라 화면 레이아웃 즉 View에 대한 라이브러리라고 한다.

프레임워크하면 흔히 떠오르는 MVC패턴에서 V만 강조한 것이라고 하는데. MVC패턴은 사실 그대로 구현이 쉽지가 않고, 뭔가 하나는 빠지게 되거나 구현이 이론대로 되지 않는다. 이것은 내 경험에서 나온 말이니, 알아서 생각하도록하고...

앞서 이야기한 AngularJS는 템플릿개념으로 화면 표시를 정적인 HTML이 담당한다면, ReactJS는 Virtual DOM개념을 이용하여, 자바스크립트에서 동적으로 HTML을 생성 할당하는 방식을 사용한다. HTML의 변경에는 DIFF알고리즘을 사용하여, 퍼포먼스를 높였다고 하고 있고, HTML태그는 JSX라는 JavaScript XML이라고하는 독특한 개념을 사용한다.

화면제어를 자바스크립트에서 오로지 처리하기때문에, 별도의 템플릿 문법도 존재하지 않고, 별도의 HTML파일을 생성할 필요도 없으므로, 요즘 이 ReactJS가 프레임워크 계에서는 거의 탑 핫 아이템으로 거론된다.

데이터 흐름과 각 화면요소들의 제어는 FLUX라는 개념을 이용하는데, FLUX는 단순 개념이고, 이것을 실제로 구체화된 라이브러리가 REDUX이다. 그런데 이미 이야기하였듯이, ReactJS는 View에 촛점이 맞춰져 있으므로, REDUX를 꼭 사용해야하는 것은 아니다.

ReactJS는 웹어플리케이션을 SPA개념에 좀더 어울릴 수 있도록 하고 있어서, 나를 비롯한 수많은 개발자들이 ReactJS의 활용에 대해서 생각하고 있다.

그런데, 페이스북 개발팀은 한발 더 나아가, ReactJS개념을 확장해서 모바일 개발에 사용하면 어떨까해서 만든 것이 React Native이다. 이놈은 폰갭과 같은 하이브리드 모바일 어플리케이션 툴과 다른 점은, 자바스크립트로 소스코딩을 하되, 배포물은 네이티브 기술로 변환된다는 것이지. 즉, 안드로이드에서는 자바로, 아이폰에서는 Objective C 코드로 변환되어 배포된다. 이것은 하이브리드 앱이 갖는 한계점으로 인한 시장에서의 인기 하락을 근본적으로 돌려보고자 하는 의도에서 시도된 듯한데, 상당히 기대되는 라이브러리 이기도 하다.

이것이 되면, 그야말로 자바스크립트만 알고 있다면, 모바일 데스크탑 어플리케이션의 개발이 모두 가능한 것이 된다.

데스크탑 어플리케이션 라이브러리 Electron.

Node.js가 범용언어로써의 자바스크립트를 구체화 하여준 것이라면, 데스크탑 어플리케이션에 특화되어 개발할 수 있도록 한 것이 Electron이다. Electron은 윈도우, 맥, 리눅스에서 배포가능한 어플리케이션을 자바스크립트로 개발할 수 있도록 해준다. 배포는 설치파일형식으로 된다.
어플리케이션의 자동업데이트 및 배포파일 생성은 모두 오픈소스 라이브러리를 이용한다. Electron은 이미 ATOM 텍스트에디터, Visual Studio Code 텍스트 에디터의 개발에 활용된 실졔 예가 존재한다.

글을 마치며 - 신세계에서...

JavaScript와 관련한 기술들의 흐름에 대해서 대략적으로 정리해봤는데도 이 정도 분량이 나온다. 실로 급격하게 변화하고 있고, 많은 열린 가능성을 우리에게 제시하는 것이 요즘 기술 트렌드이다.

그 트렌드라는 것에 대해서 한마디 하자면, 열린 체계의 가공할 만한 위력이다. 과거 자기 테이프 들고 다니면서 프로그래밍 하던 시절엔, 전산지식이란 것은 폐쇄적인 몇몇 기술자들만이 갖는 특권이었다. 그래서 천재프로그래머라는 말이 있었고, 말없이 모니터를 바라보며 알수없은 코드들을 마구 키보드치며 내려가는 프로그래머의 모습이 정형화된 이미지였지.

그러나 인터넷으로 지식습득과 공유과 쉬워진 지금세상에서, 중요한건 얼마만큼 오픈된 체계에서 나도 거기에 참여하느냐가 중요한 내용이 된다. 여기서 필요한건 천재프로그래머이기 보다, 서로간의 지식을 활용하여 만들어가는 집단 지성이다. 오픈된 체계에서 집단 지성이란 수평적 관계로 맺어진 인간관계가 그 기본이 된다.

이번 글에서 다루지 못한 자바스크립트 관련 내용도 아직 많고, HTML5와 관련해서는 더더욱 많다. 또한 다룬 내용이 부정확한 부분도 있을 수 있고... 그만큼 정말 방대한 지식들이 인터넷에서 공유되고 또 탄생하고 있다.

신세계에 발을 들여놓고 보니 참으로 세상은 넓더라.


출처 - http://www.qtilab.com/2016/08/javascript.html