카테고리 없음

2017년과 이후 JavaScript의 동향 - 브라우저 밖의 JavaScript

크레도스 2017. 5. 31. 22:45

출처 : http://d2.naver.com/helloworld/0473039


"2017년과 이후 JavaScript의 동향" 시리즈의 두 글에서는 ECMAScript의 브라우저 구현 상태와 주요한 기능을 중심으로 JavaScript의 변화를 살펴보고, JavaScript 라이브러리와 프레임워크의 동향을 알아봤습니다.

시리즈의 마지막 글인 이 글에서는 JavaScript 개발을 위한 다양한 도구와 브라우저 밖의 다양한 JavaScript 사용에 관해 살펴보겠습니다.

JavaScript 개발 도구

JavaScript 개발에서 외부 패키지를 사용하지 않는 일은 굉장히 드문 일이 됐고, 최종 결과물을 번들러와 빌드 도구로 만들어 내는 과정도 이제는 꼭 필요한 과정이 되어 가고 있다. 이제 도구는 개발의 일부분이고 필수적인 것으로 받아들여지고 있으며, 도구를 얼마나 잘 활용할 수 있는지에 따라 최종 결과물의 품질이 달라진다고 말할 수 있다.

이 장에서는 JavaScript 개발 도구인 패키지 관리자와 번들러, 빌드 도구의 현재 흐름과 2017년의 전망을 살펴보겠다.

이 장의 주요 내용은 2017년의 JavaScript 기술과 전망을 살펴보는 글인 "JavaScript’s Journey through 2016"을 참고로 했다.

패키지 관리자

지금까지 패키지 관리자는 npm과 Bower를 통해 발전되어 왔다. 그러나 동일한 역할을 수행하지만 별도로 분리된 저장소(registry) 등은 배포하는 입장에서도 사용하는 입장에서도 효율적인 상황이라고 볼 수는 없었다.

npm과 Bower

npm과 Bower

npm(Node package manager)과 Bower로 양분돼 있던 패키지 관리자 영역은 npm으로 단일화가 이루어진 것처럼 보인다.

패키지 관리자

대상

설정 파일

설치 경로

npm

Node.js

package.json

node_modules

Bower

프런트엔드

bower.json

bower_components

Module Counts 사이트의 통계에서는 2017년 5월을 기준으로 npm에 등록된 패키지가 45만 개를 넘어 끊임없이 증가하고 있다. 반면에 Bower에 등록된 패키지의 개수는 훨씬 적다. Module Counts 사이트에서는 2016년 5월부터 데이터 수집이 중단된 상태(2017년 3월에는 웹 사이트의 선택 항목에서도 Bower가 제외됐다)이지만 2016년 5월을 기준으로 5만여 개 정도의 패키지가 Bower에 등록돼 있었고 증가세도 거의 정체 상태였다. 같은 시기에 npm에는 28만여 개 패키지가 등록돼 있었다.

그림 1 2017년 3월 기준 npm과 Bower의 등록 패키지 개수 통계

그림 1 2017년 3월 기준 npm과 Bower의 등록 패키지 개수 통계(원본 출처: Module Counts)

라이브러리를 개발하고 배포하는 입장에서는 사용자가 접근할 수 있는 방법을 다양하게 제공하는 것이 나쁘지 않다. 하지만 그렇다고 모든 접근 방법을 다 제공해야 하는 필요성이나 이유 또한 없다. Ember와 SproutCore 개발에 참여했던 Tom Dale은 다양한 패키지 관리자를 지원해야 한다는 것이 좋은 점보다 나쁜 점이 더 많다고 말하기도 했다.

그림 2 Tom Dale의 트윗

그림 2 Tom Dale의 트윗(원본 출처: https://twitter.com/tomdale/status/667389972794724352)

Yarn

Yarn

Yarn은 2016년 10월에 Facebook에서 새롭게 발표한 npm 클라이언트다. 별다른 변화가 없을 것 같던 영역에서 등장한 새로운 도구이고 Facebook에서 개발한 도구라는 점 때문에 많은 이들이 관심을 가졌다.

Yarn은 npm 저장소를 사용하기 때문에 npm에 등록돼 있는 모든 패키지를 그대로 사용할 수 있다. 또한 npm 설정 파일인 package.json 파일에서 Yarn 설정 파일인 yarn.lock 파일을 손쉽게 생성할 수 있다.

## yarn.lock 파일이 없으면 생성
## 설정 파일 있으면 패키지 설치
$ yarn
yarn install v0.16.1  
info No lockfile found.  
[1/4] Resolving packages...
...
success Saved lockfile.  
Done in 34.60s.

병렬 처리를 통해 처리 성능도 npm보다 더 향상됐다.

그림 3 npm과 Yarn의 처리 성능 비교

그림 3 npm과 Yarn의 처리 성능 비교(원본 출처: NPM versus Yarn - the epic fight for speed in Continuous Integration)

Yarn이 npm 저장소를 사용하고 있지만 npm 저장소 서버의 도메인(http://registry.npmjs.org)과는 다른 별도의 저장소 서버 도메인(https://registry.yarnpkg.com)을 사용한다. 공식적으로는 이 별도의 저장소 서버 도메인은 npm 저장소 서버에 대한 리버스 프락시라고 밝히고 있으며, 앞으로 있을 수 있는 커스터마이징에 활용할 수도 있음을 내비치고 있다("What is the role of 'registry.yarnpkg.com'?" 참고). Yarn이 보다 확산되면 'npm과는 별개의 새로운 저장소를 구축하려고 하지 않을까?'라는 의심을 갖게 하는 부분이기도 하다.

2017년 전망은?

npm이 점점 더 확고하게 위치를 다지고 표준으로 자리를 잡을 것으로 보인다. Yarn 또한 기존의 npm CLI의 단점을 보완하면서 계속 발전할 것으로 보인다.

2017년 5월에 Bower의 GitHub 저장소에 병합된 리드미 파일(README.md)에는 새로운 프런트엔드 프로젝트에는 Yarn과 webpack을 사용하라고 권장하는 내용이 추가됐다. Bower의 향후 지속 여부에 대해 아마도 내부에서도 그리 밝게 보고 있지 않은 듯하다.

결국 많은 패키지가 기존의 npm과 Bower 지원에서 npm과 Yarn 지원으로 지원 범위를 점차 변경할 것으로 예상된다.

번들러와 빌드 도구

번들러와 빌드 도구

2016년 말부터 2017년 초에 많은 라이브러리가 활발하게 번들러를 도입하기 시작했다.

기존의 빌드 도구는 작업(task)을 기반으로 실행되는 수동적인 도구라 할 수 있다. 사용자가 지정한 작업 내에서 결과물을 얻기 때문에 결과물을 예측할 수 있다는 장점이 있다. 하지만 프로젝트의 복잡성이 점점 증가하면 효율성이 떨어지고 코드 분석을 통해 상황에 따라 다르게 빌드하기에는 어려움이 있을 수밖에 없는 구조다.

반면에 번들러는 프로젝트에서 사용하는 다양한 자원을 묶고 파일의 상관관계를 정적으로 분석해 지정한 형태의 파일로 결과를 출력한다. 다양한 프레임워크에서 이미 번들러를 기본적인 도구로 사용하고 있다. ECMAScript 2015를 사용하는 프레임워크에서는 번들러가 거의 필수적인 도구로 자리를 잡아가고 있다.

번들러가 등장한 초기에는 Browserify가 두드러져 보였지만, 최근에는 webpack으로 단일화되고 있는 모습이다. 2017년 1월에 릴리스된 webpack 2 버전(정식 릴리스 버전은 webpack 2.2.0 버전이다)은 다음과 같이 더 강력한 기능을 제공한다.

  • ECMAScript 2015의 import 구문과 export 구문 지원
  • ECMAScript 2015를 위한 tree-shaking 기능 지원

tree-shaking 
tree-shaking 기능은 import 구문을 정적으로 분석해 실제로 사용하지 않는 코드는 제외하고 결과물을 만드는 기능이다. tree-shaking은 번들러인 rollup.js를 통해 알려지시기 시작했다. tree-shaking 기능에 관한 더 자세한 내용은 "Tree-shaking versus dead code elimination"를 참고한다.

사실 번들러와 빌드 도구의 구분은 모호하다. 예를 들어 webpack은 로더를 사용해 ECMAScript 2015와 Sass를 변환할 수 있는데 이런 작업은 빌드 도구가 실행하던 작업이다.

하지만 번들러는 코드를 분석해 원하는 형태로 가공할 수 있는 기회를 제공한다는 장점이 있다. 예를 들어 코드의 특정 함수가 호출됐을 때에만 필요한 라이브러리를 지연 로딩(lazy loading)으로 로딩하게 하려면 기존에는 코드 분리와 빌드 등 모든 작업을 개발자가 수행해야 했다. 하지만 webpack의 require.ensure() 구문으로 코드를 분리할 지점을 지정하면 코드 분할 기능을 통해 함수 실행 시점에 라이브러리를 로딩하는 코드가 자동으로 생성될 뿐만 아니라 코드 분리와 빌드도 자동으로 실행된다.

2016년의 번들러와 빌드 도구 선호도 
다음은 2016년을 기준으로 번들러와 빌드 도구의 선호도를 조사한 사이트다. 이 글에서 언급한 Browserify와 webpack 외에 더 다양한 번들러와 빌드 도구를 확인할 수 있다. 
- The State Of JavaScript - Build Tools 
- The State of Front-End Tooling 2016 - Task Runners 
- The State of Front-End Tooling 2016 - JavaScript Module Bundlers

2017년 전망은?

기존의 빌드 도구도 어느 정도의 역할을 수행하겠지만 전체적으로 webpack으로 전환이 이루어질 것으로 예측된다. 다양한 배포 전략에 따라 원하는 빌드를 구성할 수 있다는 장점은 물론 webpack에서 제공되거나 오픈소스로 추가되는 로더와 플러그인의 수많은 기능이 webpack과 빌드 도구의 격차를 더 벌릴 것으로 보인다.

브라우저를 넘어서다

전통적으로 JavaScript는 항상 브라우저에서만 실행할 수 있다고 인식돼 왔다. 그러나 이제는 그런 인식은 맞지 않는 것임을 누구나 알고 있다. Node.js를 통해 브라우저 밖의 영역으로 JavaScript가 확장하면서 다양한 가능성이 나타나고 있다. 이 장에서는 JavaScript를 멀티 플랫폼에서 단일 개발 언어로 사용할 수 있는 가능성을 살펴본다.

이 장의 주요 내용은 브라우저 이외의 영역에서 2017년의 JavaScript 기술과 전망을 살펴보는 글인 "JavaScript in 2017 – Beyond the Browser"를 참고로 했다.

Node.js

Node.js

Node.js는 오픈소스 런타임 라이브러리로, 서버사이드 애플리케이션과 브라우저 바깥 환경에서 실행되는 JavaScript 애플리케이션을 만드는 데 도움을 준다. 지난 수년간 주로 스타트업에서 사용되며 인기를 얻었고 점차 주요 기업체로 영향력을 확대해 왔다.

패키지 관리자인 npm의 저장소는 서버사이드 애플리케이션에서 사용할 수 있는 유틸리티 모듈들을 호스팅하는 역할에서 배포 가능한 JavaScript 코드의 표준 저장소로 변모하고 있다.

Module Counts 사이트에서 조사한 바로는 2017년 1월부터 5월 말까지 8만 3천여 개의 새로운 모듈이 등록됐다(5월 24일 기준, 총 458,275개 모듈). 매달 1만 6천여 개 이상의 모듈이 등록되는 수준이다. 영역에 국한하지 않고 살펴보더라도 npm에 등록된 모듈의 수가 다른 언어나 플랫폼에 등록된 모듈의 수보다 압도적으로 많다는 것을 확인할 수 있다.

그림 4 언어별 모듈 개수 통계

그림 4 언어별 모듈 개수 통계(원본 출처: Module Counts)

이러한 증가세에는 여러 이유가 있겠지만 하나를 꼽자면 엔터프라이즈 기업에서의 Node.js 사용 증가라 할 수 있다. 이는 단순히 사용된다는 의미에서 벗어나 안정성이 요구되는 영역에서 검증된 제품이라는 의미기도 하다. Node.js의 적용 사례 페이지에서는 잘 알려진 다양한 기업의 이름을 볼 수 있다. NASA와 같이 고도의 안정성이 요구되는 분야에서도 Node.js가 사용된다.

"When you've got the safety of astronauts on the line, little hiccups and service interruptions turn into life-and-death situations. From EVA [extra vehicular activity] data to astronauts up in space, Node.js helps ensure there's a safe home for everything and everyone." 
(우주 비행사의 안전이 위태로울 때는 사소한 고장이나 서비스 장애가 생과 사를 가를 수 있다. Node.js는 선외 활동(EVA) 데이터는 물론 우주 공간에 있는 우주 비행사까지 모두 안전할 것이라는 것을 보장해 준다.) 
— Node.js Helps NASA Keep Astronauts Safe and Data Accessible

2017년 전망은?

많은 기업이 전통적인 개발 접근 방법에서 Node.js로 전환할 것으로 예측된다. 특히 Microsoft가 발표한 JavaScript 확장 언어(superset)인 TypeScript는 JavaScript를 Java나 C# 개발자가 더 이해하기 쉬운 언어로 만들어 Node.js의 성장에 힘을 실어 줄 것으로 보인다.

다양한 개발 환경과 언어를 유지 보수하는 것을 싫어하는 큰 기업들은 개발 언어를 하나로 통합할 수 있게 하는 Node.js에 매력을 느낄 것이다.

PhoneGap과 Cordova

Cordova

PhoneGap과 Cordova는 JavaScript로 네이티브 모바일 애플리케이션을 개발하려 시도한 첫 오픈소스다. Cordova의 기본 접근 방법은 웹뷰(WebView)에서 웹 코드를 감싸고, 웹뷰를 통해 네이티브 모바일 애플리케이션을 구동하는 것이다.

웹뷰에 관한 더 자세한 내용은 "What is a WebView?"를 참고한다.

이 접근 방법은 웹 개발자가 이미 알고 있는 웹 기술(주로 JavaScript)을 사용할 수 있게 한다. 그래서 수 년 동안 모바일 애플리케이션 개발 영역에서 강력한 위치를 유지할 수 있었다. 그러나 "2016년과 이후 JavaScript의 동향"에서 언급한 것처럼 Google의 Progressive Web Apps(PWA)의 강력한 도전을 받고 있는 상태다.

PWA는 네이티브 애플리케이션에서 사용하는 기능을 웹에서 사용할 수 있게 한다. 예를 들어 Push API와 Notifications API는 웹 애플리케이션에서 푸시 알림을 사용할 수 있게 한다. 그 외에 오프라인 상태에서 캐시를 사용할 수 있게 하는 서비스 워커(service worker), 스마트폰의 홈 화면에 웹 애플리케이션 아이콘을 등록하게 할 수 있는 웹 앱 매니페스트(web app manifest) 등의 기술이 있다.

2016년에 Google은 PWA에 많은 관심과 노력을 쏟았다. Google의 주요 개발자 콘퍼런스인 Chrome Dev Summit 2016에서는 총 25개 세션 가운데 9개 세션을 PWA 관련 세션으로 진행했다. 또 다른 주요 콘퍼런스인 Google I/O 2016에서도 많은 세션을 PWA 관련 세션으로 진행해 PWA 기술의 확산에 노력을 기울였다.

PWA를 활용한 애플리케이션 개발에 관한 더 자세한 내용은 "현실적 PWA"를 참고한다.

Cordova와 같은 하이브리드 애플리케이션 개발 방식 대신 PWA를 선택하는 개발자의 비율을 정확하게 계산하기는 어렵다. 그러나 많은 데이터가 Cordova의 사용량이 정체되거나 감소하고 있다는 사실을 나타내고 있다. npm-stat 사이트에서 지난 2년 동안(2015년 3월 17일~2017년 3월 17일)의 통계를 살펴보면 npm에서 Cordova의 다운로드 횟수는 2015년 12월에 50만으로 정점을 찍은 이후 30~40만 정도에 머물러 있다.

그림 5 npm에서 Cordova 다운로드 횟수 통계

그림 5 npm에서 Cordova 다운로드 횟수 통계(원본 출처: npm-stat: cordova)

2017년 전망은?

하이브리드 애플리케이션 개발 방식의 매력은 점점 더 감소하고 있다. 한때 네이티브 애플리케이션 개발의 대안으로 여겨지기도 했지만 PWA와 같은 새로운 기술의 등장과 단일 도구를 통한 개발 효율성(시간 및 비용 측면)에 대한 욕구가 커지면서 관심도가 점차 낮아지고 있다.

2017년에도 상황이 뚜렷하게 바뀔 만한 요인은 보이지 않는다. Google I/O 2017의 "The Mobile Web: State of the Union" 세션에서 확인할 수 있듯이 Google은 모바일 웹 영역에서 AMP(Accelerated Mobile Pages)와 PWA에 힘을 싣고 있다. 하이브리드 애플리케이션 개발 방식의 입지는 점점 더 줄어들 수밖에 없을 것으로 보인다.

네이티브 모바일 애플리케이션

React Native와 NativeScript

JavaScript 주도적(JavaScript-driven) 네이티브 애플리케이션 개발은 Appcelerator의 Titanium이 개척하고 선도했던 영역이다. 현재는 React Native와 NativeScript가 그 자리를 점점 대체하고 있다.

웹뷰를 감싸는 형태의 Cordova와는 다르게 JavaScript 주도적 네이티브 애플리케이션 개발은 웹뷰를 사용하지 않는다. 그렇기 때문에 웹 기반 개발에서 일어나는 성능 문제에 영향을 받지 않는다.

npm-stat 사이트에서 지난 1년 동안의 다운로드 통계를 살펴보면 React Native의 성장세가 확실히 두드러진다. NativeScript의 다운로드 횟수는 완만하게 상승하다가 2017년 3월에 정점을 찍은 후 조금은 하락하는 모습을 보이고 있다.

그림 6 npm에서 React Native와 NativeScript의 다운로드 횟수 통계

그림 6 npm에서 React Native와 NativeScript의 다운로드 횟수 통계(원본 출처: npm-stat: react-native, npm-stat: nativescript)

2017년 전망은?

더욱더 많은 JavaScript 개발자가 모바일 애플리케이션을 개발하게 되면서 JavaScript 주도적 네이티브 애플리케이션 개발은 지속적으로 성장할 것으로 예측된다.

React의 인기를 업은 React Native는 React로 개발한 애플리케이션을 손쉽게 네이티브 애플리케이션으로 전환하는 방법을 제공한다. 성능에서도 네이티브 애플리케이션에 뒤지지 않아 React Native로 개발한 iOS 애플리케이션이 Swift로 개발한 네이티브 애플리케이션보다 더 나은 성능을 보인다는 사례도 있다("Comparing the Performance between Native iOS (Swift) and React-Native" 참고).

2016년 5월에 NativeScript가 Angular 2 지원을 발표하면서("Sharing Code Between Web and Native Apps" 참고) 대표적인 JavaScript 프레임워크 모두에서 단일한 코드를 기반으로 웹과 네이티브 모바일 애플리케이션을 개발할 수 있게 됐다. 이는 개발자와 기업 모두에게 매우 매력적인 일이다.

데스크톱 애플리케이션

Electron과 NW.js

데스크톱 영역에서 JavaScript를 사용할 수 있는 방법은 그리 많지 않다. Electron과 NW.js가 대표 주자로 이 영역을 이끌어 가고 있다.

Electron과 NW.js 모두 성장했지만 Electron이 점점 실질적인 표준(de-facto)으로서의 위치를 굳혀 가고 있다. Electron은 Microsoft의 Visual Studio Code 개발에 사용된 이후 많은 데스크톱 애플리케이션 개발 도구로 사용되고 있다. Electron은 또한 React 커뮤니티와 Angular 커뮤니티의 지지를 동시에 받는 흔치 않은 모습을 보일 정도로 이 영역에서는 독보적인 위치를 구축하고 있다.

2017년 전망은?

Electron이 2017년에도 압도적인 우위를 보일 것이라 예측하는 것이 전혀 이상하지 않다. React와 Angular 같은 인기 있는 프레임워크의 지원도 예상된다. JavaScript가 Java와 Microsoft 기반 기술(WPF)이 차지하고 있는 영역을 서서히 침범하고 있어 기존 기술을 대체하는 역할이 점점 더 커질 것으로 보인다.

JavaScript의 새로운 영역

앞으로 등장하거나 각광을 받을 기술을 꼽으라면 빠지지 않고 등장하는 기술이 있다. 바로 챗봇(chatbot)과 사물 인터넷(IoT, Internet of things), 가상현실(virtual reality)이다.

챗봇

챗봇 프레임워크

챗봇 생태계에서 JavaScript의 영향력은 크다. 많은 개발자가 JavaScript로 챗봇을 개발하고 있다. 그 외에 단순한 Slack 봇부터 복잡한 상거래용 봇까지 다양한 챗봇을 개발한다.

다양한 유형의 챗봇에 관해서는 "11 Examples of Conversational Commerce and Chatbots"를 참고한다.

또한 Botkit, Microsoft의 Bot Framework, Facebook의 Wit.ai 등 챗봇 프레임워크의 대부분은 SDK에 Node.js 라이브러리를 포함하고 있다.

사물 인터넷

사물 인터넷 라이브러리

사물 인터넷인 IoT 영역에서도 JavaScript를 쉽게 볼 수 있다.

IoT 라이브러리인 Losant와 Zetta는 Node.js API를 제공한다. 가상현실 컨트롤러 기기로 유명한 립모션은 JavaScript API를 제공한다. 삼성은 웹 기반의 IoT 플랫폼 구축을 위한 IoT 엔진인 JerryScript를 2015년에 발표했다.

가상현실

가상현실 프레임워크

웹의 가상현실 기술 표준화는 WebVR을 통해 진행되고 있다. WebVR API는 JavaScript로 가상현실 기기(Oculus의 Rift와 같은 HMD(head mounted display) 등)에서 감지되는 위치와 움직임 등에 대한 정보를 얻을 수 있게 한다.

Google의 Chrome 팀은 실험적이면서 인상적인 가상현실 예제를 Chrome Experiments for Virtual Reality 사이트에 공개하고 있다. Mozilla는 2015년 중반부터 가상현실 경험을 개발할 수 있는 프레임워크인 A-Frame을 개발하고 있다. Microsoft는 자사의 가상현실 기기인 HoloLens에서 사용할 수 있는 애플리케이션 개발을 위한 프레임워크인 HoloJS를 2016년 12월에 공개했다.

2017년 전망은?

JavaScript의 유명세와 인기는 2017년에도 다양한 영역에서 이어질 것이라 예상된다. 다양한 환경에 JavaScript가 침투하고, 새로 등장할 개발 생태계에서도 JavaScript는 주요 언어가 될 것으로 보인다.

마치며

10년 전에는 JavaScript의 현재 모습을 결코 생각할 수 없었다. 곧 생명력이 다할 것처럼 보이는 시기마다 상황을 전환하는 다양한 플랫폼과 프레임워크가 때맞춰 등장했고, 이제는 다양한 영역에서 JavaScript가 사용되고 있다. JavaScript가 모든 영역에서 사용되거나 기존 개발 언어를 대체하지는 않겠지만, 범용적인 사용성 때문에 개발 영역에서 주요한 자리를 차지하고 있다는 점에는 의심의 여지가 없어 보인다.

스탠퍼드 대학교의 컴퓨터공학 학부는 JavaScript로 기본 프로그래밍 방법론을 가르치는 "CS106J: Programming Methodologies in JavaScript" 과정을 2017년 봄에 시험적으로 개설했다("CS department updates introductory courses" 참고)했다. 기존의 기본 프로그래밍 방법론 과정인 "CS 106A: Programming Methodology"에서 사용하는 언어는 Java인데, JavaScript가 이를 대체할 가능성이 있다("Stanford CS department updates introductory courses: Java is Gone" 참고). 이런 변화는 학문적인 영역에서도 JavaScript의 미래에 대한 가능성을 염두에 두고 있다는 것을 보여 주는 일이기도 하다.

개발자라면 누구나 아는 질의, 응답 사이트인 Stack Overflow의 공동 창업자 중 한 명인 Jeff Atwood는 현재와 같은 상황을 미리 예견했는지도 모르겠다. Jeff Atwood는 2007년에 블로그에서 다음과 같은 'Atwood의 법칙'을 이야기했다("The Principle of Least Power" 참고).

Any application that can be written in JavaScript, will eventually be written in JavaScript. 
(JavaScript로 작성될 수 있는 애플리케이션은 결국 모두 JavaScript로 작성될 것이다.)

2017년과 이후 JavaScript의 동향


저작자표시 비영리 변경금지 (새창열림)