'javascript 동향'에 해당되는 글 1건

JavaScript는 단지 브라우저 안에만 머물러 있지 않습니다. 다양한 영역에서 그 힘을 발휘하고, 오히려 브라우저에서보다 더 큰 가능성을 보여 주고 있습니다.

"2018년과 이후 JavaScript의 동향"시리즈의 마지막 글에서는 영역을 확장해 나가는 브라우저 밖의 JavaScript에 관해 살펴보겠습니다.

Node.js

Node.js는 매해 큰 폭의 성장을 지속하고 있으며 2017년에도 여전히 눈부신 성장세를 이어 갔다. 2017년 한 해에만 2억 5천만 번 다운로드됐고, 이는 매일 평균 70만 번의 다운로드가 이뤄진 것과 같다. 2017년의 월별 다운로드 수와 직전 해인 2016년의 월별 다운로드 수를 비교한 "Node by Numbers 2017"의 통계에서는 매월 7~8백만 건이 증가했음을 확인할 수 있다.

그림 1 Node.js의 월별 다운로드 수 비교 통계

Node.js 사용 기업의 확대

"2017년과 이후 JavaScript의 동향 - 브라우저 밖의 JavaScript"에서 예측했던 바와 같이 2017년은 많은 기업에서 Node.js의 도입과 성숙이 이루어진 해였다. 고객들에게 빠르고 새로운 디지털 경험을 제공해야 하는 기업이 빠른 개발 프로세스로 다양한 결과물(다중 플랫폼 지원, 보유하고 있는 기업 데이터의 API 제공 등)을 내놓을 수 있고 풍부한 생태계가 형성된 Node.js를 선택하는 것은 자연스러운 일이라고 할 수 있다.

이 '기업'은 작은 규모의 기술 스타트업만을 의미하는 것이 아니다. "2017 USER SURVEY EXECUTIVE SUMMARY"에서 확인할 수 있듯이 기존의 대기업에서 Node.js의 사용이 확대되고 있다.

그림 2 다양한 산업 영역에 걸쳐 있는 Node.js 사용 기업

Node.js 개발 경험 
다음은 다양한 기업에서 공유한 Node.js 개발 경험이다. Node.js를 어떤 영역에서 어떻게 활용하고 있는지를 엿볼 수 있다. 
- Walmart의 사례: Migrating Large Enterprise to NodeJS 
- Lowe's의 사례: Node.js Enterprise Conversations - Episode 6 Lowe's Digital 
- Netflix의 사례: Node.js at Netflix 
- NASA의 사례: Node.js Helps NASA Keep Astronauts Safe and Data Accessible

"2017 User Survey Executive Summary"의 설문 조사 결과에서는 또한 2017년에 Node.js가 백엔드 영역에서 주로 사용됐다는 것을 확인할 수 있다.

그림 3 Node.js를 사용하는 영역에 관한 설문 조사 결과

N-API의 추가와 주요 변화

N-API(Node.js API)는 네이티브 Node.js 애드온을 개발할 때 사용할 수 있는 새로운 API다. N-API는 JavaScript 런타임 엔진에 독립적이며, Node.js의 구성원으로 관리된다.

N-API는 2017년 5월에 발표된 Node.js 8.0에 실험적 기능으로 추가됐다. Node.js 10.0.0에서 '실험적(Experimental)'이라는 표시가 제거된 정식 기능으로 포함됐다(GitHub 저장소의 코드 변경 내역 참고).

Node.js와 JavaScript에 대한 추상화를 제공하기 때문에 런타임 엔진(예: V8)의 작동 방식을 깊게 알고 있지 않아도 C/C++로 Node.js 애드온을 작성할 수 있게 한다. 간단히 말하면 런타임 엔진과 Node.js 간의 추상화 레이어라고 정의할 수 있다.

N-API는 기존의 네이티브 Node.js 추상화 API인 NAN(Native Abstractions for Node.js)에 비해 큰 발전을 이뤘다. ABI(Application Binary Interface) 호환성을 제공하면서도 한 번의 컴파일만으로 각각 다른 Node.js 버전에서 작동이 가능하기 때문에 향후 NAN의 사용을 N-API가 점차 대체할 것으로 예측된다.

N-API 참고 자료 
N-API에 관한 더 자세한 내용은 다음 자료를 참고한다. 
- N-API and getting started with writing C addons for Node.js 
- N-API: Next generation Node.js APIs for native modules (한글 번역, 요약 슬라이드)

그 외에 Node.js 7.6부터 네이티브 async/await 함수 지원이 추가돼 표준을 따르는 비동기 코드 작성이 가능해졌다. 또한 "2018년과 이후 JavaScript의 동향 - JavaScript(ECMAScript)"에서 언급한 것처럼 Node.js 8부터 WebAssembly 지원이 추가돼 신기술에 대한 확장성을 더욱 넓혔다.

Node.js 10.0.0

Node.js의 7번째 메이저 릴리스 버전인 Node.js 10.0.0은 2018년 4월 24일에 발표됐다. 새로운 버전에는 그동안 실험적이었던 N-API가 정식 기능으로 포함됐다. Microsoft의 JavaScript 엔진인 ChakraCore를 런타임 엔진으로 사용하는 실험적인 Node.js인 Node-ChakraCore에도 N-API 지원이 포함됐다.

ChakraCore 10.0.0 
ChakraCore 10.0.0은 시간 여행(time travel) 디버깅 도구인 NodeChakra Time Travel Debug를 Visual Studio Code(VS Code) 확장으로 사용할 수 있게 지원하며, 제너레이터 함수와 async 함수도 지원한다. ChakraCore 10.0.0의 변경 사항에 더 관한 자세한 내용은 릴리스 노트를 참고한다.

V8 런타임 엔진이 6.6 버전으로 업데이트됐다. V8 6.6에는 다양한 성능 향상 항목이 포함돼 있어 Node.js에서도 동일한 성능 향상을 기대할 수 있을 것으로 보인다("V8 release v6.6" 참고).

Node.js에서 ESM(ECMAScript Module)을 완전하게 지원하려는 노력이 지속되고 있지만 아직까지는 많은 어려움을 겪고 있다. "2018년과 이후 JavaScript의 동향 - 라이브러리와 프레임워크"에서 언급한 바와 같이 ESM은 이제 최근에 나온 모든 브라우저에서 네이티브 형태로 지원된다. 하지만 Node.js에서 사용하는 기존의 CJS(CommonJS) 환경과 통합은 아직 요원한 상태다. 그러나 ESM 지원은 필수이기 때문에 해결책을 찾을 수 있을 것으로 예측된다.

Node.js의 ESM 지원에 관해서는 "Native ES Modules in NodeJS: Status And Future Directions, Part I"을 참고한다.

향후 릴리스 일정

Node.js 릴리스 일정에 따르면 Node.js 10.x는 2018년 10월에 'Active LTS' 단계로 접어든다.

그림 4 Node.js 릴리스 일정

Node.js의 모든 메이저 버전은 LTS 계획에 따라 관리된다. 'Active LTS' 단계에 접어드는 시점부터 18개월 동안 정식 지원이 시작되고, 이후 'Maintenance' 단계로 전환되면 12개월 동안의 추가 지원이 제공된다.

패키지 관리자

패키지 관리자의 양대 산맥이라 할 수 있는 npm과 Bower는 지난 한 해 동안 어떠한 변화를 겪었을까?

npm 레지스트리에 지난 1년(2017년 5월~2018년 5월) 동안 약 20만 개의 새로운 패키지가 등록되며 npm이 선두를 더욱더 공고하게 유지하고 있다.

Bower의 다운로드가 매주 50만 건 정도 발생하고 있어 Bower의 사용량도 계속 높게 유지되고 있다. 그러나 "2017년과 이후 JavaScript의 동향 - 브라우저 밖의 JavaScript"에서 언급한 바와 같이 Bower는 공식적으로 Yarn 사용을 권장하고 있다. 아직 업데이트가 지속적으로 제공되고 있지만 어느 시점까지 계속 제공될지 알 수 없기 때문에 Bower의 권장에 따라 새로운 프로젝트에서 Bower의 사용은 지양해야 할 것으로 보인다.

Bower 사용 및 지원 중단 
Bower 사용과 지원 중단에 관한 더 자세한 내용은 다음 글을 참고한다. 
- How to migrate away from bower? 
- How to drop bower support?

npm

2018년 5월을 기준으로 npm 레지스트리에 총 65만여 개의 패키지가 등록돼 있다.

Module Counts의 통계에 나타난 증가세를 보면 매일 평균 500개 이상의 새로운 패키지가 npm 레지스트리에 등록되고 있다. 이 수치는 언어와 환경에 상관없이 모든 패키지 레지스트리에서 가장 높은 수치다. 등록된 패키지의 개수가 두 번째로 많은 Java의 Maven(23만여 개)과 세 번째로 많은 PHP의 Packagist(18만여 개)가 보여 주는 매일 평균 100여 개보다 5배 높은 수치다.

그림 5 npm과 Maven, Packagist의 레지스트리에 등록된 패키지 개수 비교(2018년 5월 기준)

메이저 버전 릴리스와 주목할 만한 기능들

2017년과 2018년에 메이저 버전이 한 번씩 릴리스됐다.

2017년 5월에 릴리스된 npm 5.0.0에는 yarn.lock 파일과 같은 기능을 하는 package-lock.json 파일 지원이 추가됐다(GitHub의 Pull Request 대화 참고).

2017년 7월에 릴리스된 npm 5.2.0은 새로운 도구인 npx를 선보였다. npx는 npm 레지스트리에 있는 CLI 도구를 프로젝트의 의존성 모듈로(또는 전역 영역에) 등록하거나 설치하지 않고 한 번만 실행할 필요가 있을 때 유용한 '패키지 실행자'(package runner)다("Introducing npx: an npm package runner" 참고).

# create-react-app으로 React 프로젝트를 생성하는 예
$ npx creat-react-app myApp

2018년 2월에 릴리스된 npm 5.7.0은 파일 시스템의 소유권을 변경하는 문제로 큰 혼란을 야기할 뻔했다("Critical Linux filesystem permissions are being changed by latest version #19883" 참고).

가장 최근의 메이저 버전인 npm@6은 2018년 4월 24일에 릴리스됐다. npm@6에는 새로운 명령어인 audit 명령어가 추가됐다(npm 5.10.0에도 포함됨). audit 명령어는 프로젝트에서 사용된 모듈의 보안 검사를 수행하고 권고 사항을 알려 준다("npm audit: identify and fix insecure dependencies" 참고).

$ npm audit

# Run `npm install webpack-cli@2.1.3` to resolve 2 vulnerabilities
  low             Cryptographically Weak PRNG
  Package         randomatic
  Dependency of   webpack-cli [dev]
  Path            webpack-cli > jscodeshift > micromatch > braces >
                  expand-range > fill-range > randomatic
  More info       https://nodesecurity.io/advisories/157
  ...

차기 메이저 버전 릴리스

차기 메이저 버전인 npm 7.0은 2018년 말에 출시될 것으로 예측된다. 패키지 별칭(alias) 기능이 주요 변경 사항으로 추가될 것으로 보인다. 차기 릴리스에 관한 더 자세한 내용은 "Beyond npm@6: The future of the npm cli"를 참고한다.

yarn

yarn은 2016년에 처음 발표된 이래 매주 40만 건의 다운로드가 발생하는 패키지 매니저로 성장했다. Bower의 영향력 감소에 따라 현재 패키지 매니저는 npm 대 yarn의 구도로 변모했다.

GitHub에서는 2018년 5월을 기준으로 약 45만여 개의 프로젝트가 yarn을 사용하고 있는 것으로 확인되며, yarn을 사용한 패키지 설치는 매일 평균 3억 건 이상 발생하고 있다.

2017년 9월에는 yarn 1.0이 릴리스됐으며, 다음과 같은 주요 기능이 추가됐다.

• workspaces: workspaces는 실제로는 yarn 0.28 버전에서 도입됐다. workspaces는 여러 패키지를 단일 저장소 구조(monorepo)로 관리하는 프로젝트에서 의존성 패키지를 효율적으로 관리할 수 있게 한다. 하위 패키지들이 버전이 같은 의존성 패키지를 중복으로 설치하는 것을 막고 의존성 패키지의 상호 공유와 업데이트 등을 편리하게 할 수 있게 한다.

Lerna 
yarn의 workspaces와 유사한 도구로 Lerna가 있다. workspaces를 Lerna와 함께 사용할 수도 있다("Workspaces in Yarn"의 'Lerna' 참고).

• 하위 패키지의 의존성 패키지 버전 관리: package.json 파일에 resolution 항목이 추가됐다. resolution 항목은 프로젝트의 의존성 패키지에 의존하는 서브 패키지의 버전을 관리할 수 있는 기능을 제공한다("Selective dependency resolutions" 참고).

npm 대 yarn

패키지 관리자 영역에서는 이제 'npm 대 yarn' 구도가 전개되고 있다. Bower와 달리 yarn은 npm과 동일한 레지스트리를 사용하고 있기 때문에 두 도구는 클라이언트의 성능에 초점이 맞추어져 비교된다.

그림 6 매일 업데이트되는 npm과 yarn의 비교표(원본 출처: Comparing npm and yarn. Updated daily.)

npm은 npm 6에서 1년 전에 비해 17배 향상된 성능을 이뤘다고 발표했다. 실제로도 최근 버전은 yarn보다 나은 성능을 보여 주고 있다. 상황과 업데이트되는 기능에 따라 계속 결과는 달라지겠지만 yarn이 등장 초기에 특징으로 내세웠던 장점인 성능 차이가 점점 의미가 없어져 가고 있는 것은 사실이다.

그 외 패키지 관리자들

npm과 yarn 외에도 많은 패키지 관리자가 있다. 그중 잘 알려진 도구로는 jsmpm과 pnpm이 있다.

jspm

jspm은 패키지 관리자의 이름이면서 동시에 자체 생태계와 도구들을 지칭하는 이름이기도 하다.

jspm의 주요한 구성 요소는 다음과 같다.

• jspm 레지스트리: npm 패키지가 네이티브 ESM을 로딩할 수 있게 파일을 호스팅하는 CDN 저장소다("jspm.io - Native ES Modules CDN" 참고).

<script type=module>  
    import React from 'https://dev.jspm.io/react';

    // 또는 dynamic import (chrome의 경우)
    import('https://dev.jspm.io/react').then(({ default: React }) => console.log(React));
</script>  

• SystemJS: 다양한 형식으로 작성된 모듈을 로딩할 수 있는 모듈 로더다.

<!-- SystemJS 로더를 먼저 로딩 -->  
<script src="systemjs/dist/system.js"></script>  
<script>  
    // main.js가 어떤 모듈 문법을 사용하더라도 상관없이 로딩할 수 있다.
    SystemJS.import("/js/main.js");
</script>  

pnpm

pnpm은 2016년에 처음 발표됐다. 다른 패키지 관리자와 유사한 특징을 가지고 있지만 가장 큰 차이점은 바로 '효율적 디스크 사용'이다.

대부분의 패키지 관리자는 프로젝트에서 사용하는 패키지의 의존성 패키지가 서로 중복돼도 의존성 패키지를 설치하기 때문에 디스크 사용의 효율성이 떨어진다. pnpm은 동일한 버전의 패키지는 디스크에 한 번만 설치하도록 관리하기 때문에 디스크 사용의 효율성을 높일 수 있다는 점을 장점으로 내세운다.

향후 전망

패키지 관리자는 큰 변화가 발생하는 영역은 아니다. 따라서 현재의 상태와 유사한 흐름을 계속 보일 것으로 예측된다. npm은 레지스트리만으로도 대체 불가능해 보이고, 다운로드 수에서도 다른 경쟁자를 압도하고 있기 때문에 현재의 독점적 지위를 계속해서 누릴 수 있을 것으로 보인다(npm trends의 통계 참고).

그림 7 최근 6개월간의 npm, yarn, jspm, pnpm 다운로드를 비교한 npm trends의 통계

번들러와 빌드 도구

번들러와 빌드 도구에서는 webpack이 다른 도구에 비해 압도적인 위치에 있다. 현시점에서 특별한 경우가 아니라면 굳이 webpack 이외의 도구를 사용할 필요는 없어 보인다.

npm trends의 통계에서 확인할 수 있는 것처럼 webpack의 다운로드는 매일 3백만 건 이상 발생하고 있지만 다른 도구의 다운로드는 1백만 건에도 미치지 못한다.

그림 8 최근 6개월간의 webpack, browserify, grunt, gulp, parcel 다운로드를 비교한 npm trends의 통계

webpack

2018년 2월 25일에 릴리스된 새로운 메이저 버전인 webpack 4.0에는 다음과 같은 주요한 변화가 포함됐다.

webpack 4.0에 관한 더 자세한 내용은 "webpack 4: released today!!"를 참고한다.

• 성능 향상: 빌드 시간이 기존보다 60~98% 줄었다.
• CLI 도구 분리: CLI 도구가 webpack-cli로 분리됐다(별도 설치 필요).

webpack-command 
2018년 4월 30일에 새로운 CLI 도구인 webpack-command가 발표됐다("Webpack’s New (CLI) Hotness" 참고). webpack 4.0의 CLI 도구인 webpack-cli와 주요 차이점에 관해서는 "webpack-command"의 'Differences With webpack-cli'를 참고한다.

• mode 옵션: 번들링 모드를 설정할 수 있는 옵션인 mode 옵션이 필수 옵션으로 추가됐다. 개발 모드(development)와 제품 모드(production)를 설정할 수 있다. 설정에 맞춰 최적화된 번들링이 수행된다.

production 설정과 압축 
mode 옵션을 production으로 설정하면 모든 결과물에 압축(minify)이 적용된다. 압축을 실행하는 플러그인(예: UglifyJSPlugin)을 사용하는 별도의 작업(task)이 있다면 mode 옵션을 none으로 설정해 번들링 모드를 비활성화시킨다. 
mode 옵션과 성능에 관해서는 "webpack 4: mode and optimization"을 참고한다.

webpack을 사용하고 있다면 webpack의 수많은 설정 옵션의 사용이 그리 녹록지 않음을 잘 알 것이다. 각종 로더와 플러그인까지 추가로 사용한다면 설정은 더욱더 복잡해지고 많은 골칫거리가 생겨난다.

이러한 문제를 해결하기 위해 'Zero configuration(0CJS)'을 표방하는 새로운 도구가 등장했다(예: Parcel). webpack의 mode 옵션도 0CJS을 통해 나름대로 문제를 해결하기 위한 것이라 할 수 있다.

webpack 4.6에서는 브라우저가 대기(idle) 상태일 때 사용자가 방문할 수도 있는 리소스를 미리 로딩하는 '리소스 힌트'(Resource Hint) 기능을 보다 손쉽게 적용할 수 있다("<link rel="prefetch/preload"> in webpack" 참고).

// 상위 청크(parent chunk)의 로딩이 끝난 후 온디맨드로 로딩되도록 청크가 생성된다.
import(/* webpackPrefetch: true */ "모듈명")

// 상위 청크(parent chunk)와 동시에 병렬로 로딩된다.
import(/* webpackPreload: true */ "모듈명")  

현재(2018년 6월 19일 기준) webpack의 최신 버전은 webpack 4.12.0이다. webpack의 릴리스는 정해진 일정을 따르는 것으로 보이지 않으며, 빠른 주기로 새로운 릴리스가 나오고 있다.

대체로 가장 최신 버전을 사용하는 것이 권장되지만, webpack 4.0 릴리스에서는 플러그인과 로더에 큰 변경이 있어 프로젝트에 따라 플러그인과 로더의 호환성이 유지되지 않는 문제가 발생하기도 했다("Breaking changes for plugins/loaders" 참고).

플러그인과 로더는 서드파티 개발자가 관리하기 때문에 이러한 문제가 발생하는 것은 자연스러운 일이라고 할 수도 있다. 그러나 이런 특성으로 인해 메이저 릴리스로 업데이트하는 것은 시간을 두고 진행하는 전략을 세우는 것이 필요해 보인다.

Parcel

새로운 번들링 도구인 Parcel은 2017년 12월에 발표됐다("Announcing Parcel: A blazing fast, zero configuration web application bundler" 참고). 발표되자마자 큰 인기를 얻었고 발표 이후 첫 한 달간 GitHub에서 단숨에 13,000여 개의 'Star'를 얻을 정도로 커다란 반응을 이끌어 냈다(2018년 5월에는 22,000여 개).

뜨거운 반응에는 여러 가지 이유가 있을 수 있지만 아무래도 설정이 복잡한 webpack에 대한 반감도 한 가지 이유가 될 수 있을 것이다. webpack을 사용해 본 경험자라면 Parcel은 사용하기가 너무나 단순하다고 느낄 수밖에 없을 것이다. 조금 더 자세한 내용은 "If you’ve ever configured Webpack, Parcel will blow your mind!"를 참고한다.

Parcel 개발자인 Devon Govett은 크게 2가지 목표를 가지고 Parcel을 개발했다고 말한다.

• 빠른 성능: worker 프로세스를 사용한 병렬 컴파일과 캐시(컴파일 결과를 캐싱해 다음 빌드를 빠르게 수행)를 통해 기존 번들러보다 최대 10배 이상 향상된 성능을 보일 수 있다고 밝히고 있다(벤치마크 결과 참고).

그림 9 4개의 물리적 CPU에서 1,726개의 모듈이 있는 프로젝트 빌드 벤치마크

• 설정 경험의 향상: 다음과 같은 방법으로 설정을 손쉽게 한다.
  • 모든 자원(JavaScript, HTML, CSS, 이미지 등)은 자체적인 처리가 가능해 별도의 플러그인이 필요하지 않다(Parcel 문서의 "애셋" 참고).
  • 자동 변환을 지원하며, 필요에 따라 Babel과 PostCSS, PostHTML 등을 사용한다(Parcel 문서의 "변환" 참고).
  • 별도의 설정 없이 import() 구문으로 동적으로 코드 분할(Code splitting)을 처리한다(Parcel 문서의 "코드 분할" 참고).
  • 런타임에 모듈을 자동으로 갱신하는 HMR(Hot Module Replacement, 빠른 모듈 교체)을 지원한다(Parcel 문서의 "빠른 모듈 교체(HMR)" 참고).

다국어 지원 
Parcel의 다국어 지원도 좋은 편이다. 현재 9개 언어로 문서가 제공되고 있으며, 한국어도 포함돼 있다. 
webpack은 영어와 중국어로 된 문서만 제공하고 있다. Parcel보다 문서의 양은 많지만 문서 자체의 품질도 충실하지 못한 편이다.

Parcel 1.7에는 Vue.js에 대한 0CJS 지원이 추가됐고, 2018년 5월 초에 릴리스된 Parcel 1.8에는 다중 엔트리 포인트 지원과 UMD(Universal Module Definition) 지원 등이 추가됐다.

다음 릴리스에 어떤 변화가 발생할지는 GitHub 저장소에서 RFC 레이블이 붙은 이슈를 통해 간접적으로 확인해 볼 수 있다. 현재 다양한 항목들에 제안된 상태다. 실제 반영 여부와 시기는 예측하기 어렵지만 첫 릴리스 이후 총 19번의 릴리스가 이루어진 것으로 미루어 볼 때 빠른 속도로 개발이 진행되고 있다.

사용자도 증가하고 있어서 앞으로 계속 성장세를 이어 나갈 수 있을 것으로 보인다.

모바일 애플리케이션

JavaScript로 모바일 애플리케이션을 개발하는 도구는 "2017년과 이후 JavaScript의 동향 - 브라우저 밖의 JavaScript"에서 언급한 바와 같이 현재 React Native와 NativeScript의 2개로 좁혀진 상태라 할 수 있다(npm trends의 통계 참고). 각 도구의 인기는 기반 프레임워크(React Native의 기반 프레임워크는 React고, NativeScript의 기반 프레임워크는 Angular다)의 인기에 비례하는 모습을 보여 주고 있다.

이 글에서 다루지는 않지만 Fuse는 그래픽 처리에서 강점과 XML 기반의 단순한 UI 개발을 내세우며 사용자 확산에 노력했다. 2018년 5월에 기존의 유료 정책을 폐기하고 오픈소스로 전환을 발표했다. 하지만 현재의 구도에 영향을 주기엔 역부족으로 보인다.

그림 10 최근 6개월간의 Cordova, PhoneGap, React Native, NativeScript 다운로드를 비교한 npm trends의 통계

NativeScript

2015년에 처음 발표된 NativeScript는 JavaScript로 크로스플랫폼 모바일 애플리케이션을 개발할 수 있게 하는 도구다("Creating Mobile Native Apps in JavaScript with NativeScript" 참고). 꾸준한 업데이트를 통해 관리되고 있으며, 2018년 4월 10일에 NativeScript 4.0.0이 릴리스됐다.

NativeScript 4.0.0에 관한 자세한 내용은 "NativeScript 4.0 is out!"를 참고한다.

네이티브 JavaScript 또는 TypeScript로 개발할 수 있지만, Angular를 사용하면 더 효율적이고 잘 통합된 개발 환경이 지원된다("Angular for NativeScript" 참고).

NativeScript는 개발 편의성을 위해 다음의 도구를 추가로 제공한다.

• NativeScript UI: 달력, 차트, 데이터 폼, 자동 완성 등과 같은 리치 UI 구성에 필요한 컴포넌트의 모음이다. 2017년 9월 진행된 NativeScript 개발자 행사에서 모든 컴포넌트가 무료로 전환됐다("NativeScript UI is Now Free—Here’s How to Get Started" 참고). npm을 통해 각각 개별적인 컴포넌트로 배포된다.
• NativeScript Sidekick: 2017년 7월에 발표된 새로운 데스크톱 애플리케이션 도구의 모음이다. 단순하고 지루한 작업(예: 스캐폴딩, 빌드 등)을 단순화시켜 줄 수 있다. Vue.js와 Electron을 사용해 개발됐다. 구조상 NativeScript CLI의 상위에 위치하기 때문에 CLI가 제공하는 기능을 사용할 수 있다.

그림 11 NativeScript Sidekick의 다양한 도구들

생태계

2018년 2월에 Vue.js Amsterdam 행사에서 NativeScript의 Vue.js 지원 플러그인인 NativeScript-Vue 1.0가 발표됐다("Announcing NativeScript-Vue 1.0" 참고).

그림 12 NativeScript-Vue 사이트

Angular 지원이 NativeScript 개발팀에 의해 이뤄지는 것과는 달리 커뮤니티가 주도하는 Vue.js 지원 프로젝트는 NativeScript 사용성을 한 단계 더 확장할 수 있는 계기가 될 수도 있다.

NativeScript-Vue 외에도 커뮤니티가 주도적인 역할을 하는 다양한 플러그인들이 등장하고 있다. 증강 현실 지원 플러그인인 nativescript-ar도 그중 하나다. Apple의 ARKit API(iOS 11)와 Google의 ARCore API(Oreo)를 사용해 증강 현실 애플리케이션을 개발할 수 있다.

nativescript-ar 플러그인과 증강 현실 구현에 관한 더 자세한 내용은 "Preview of Augmented Reality in NativeScript"를 참고한다.

향후 전망

NativeScript의 로드맵을 통해 NativeScript의 발전 방향을 유추해 보면, NativeScript는 다양한 플랫폼에 대해 지원을 강화할 것으로 보인다.

현재는 커뮤니티가 주도하는 Vue.js 지원을 공식적으로 지원할 것으로 예측된다.

또한 모바일 애플리케이션 개발을 벗어나 다양한 플랫폼으로 확산을 시도할 것으로 보인다. Android TV 앱 개발과 관련된 PoC(Proof of Concept) 플러그인이 개발돼 있고("Building an Android TV App with NativeScript" 참고), 자동차 플랫폼인 Android Auto와 Apple CarPlay 지원도 포함될 것으로 예측된다.

NativeScript 관련 참고 자료 
NativeScript 개발에 관심이 있다면 다음 자료를 추가로 참고한다. 
- NativeScript Marketplace: 마켓 플레이스에서 다양한 NativeScript 플러그인과 템플릿을 제공한다. 
- NativeScript Playground: 온라인 편집기로 NativeScript를 사용한 개발을 직접 경험할 수 있다. 
- The NativeScript Book: 무료 전자책 형태로 제공되는 450쪽 분량의 NativeScript 개발 가이드다.

React Native

React Native는 2015년 3월에 처음 발표된 이래 React의 인기와 함께 성장했다. 현재 JavaScript 네이티브 모바일 애플리케이션 개발 영역에서 가장 선두에 있다.

React Native로 Windows 데스크톱 애플리케이션 개발 
React Native로 모바일 애플리케이션만 개발할 수 있는 것은 아니다. Microsoft가 진행하는 react-native-windows는 React로 UWP(Universal Windows Platform) 애플리케이션과 WPF(Windows Presentation Foundation) 애플리케이션을 개발할 수 있게 한다.

매월 한 차례씩 정기적으로 릴리스되고 있으며, 최신 버전(2018년 5월 기준)은 4월에 발표된 React Native 0.55다.

React Native 0.55의 주요 변경 사항에는 Android TV 앱 개발 지원이 포함됐다. 이를 통해 주요 TV 플랫폼인 Apple TV 앱과 Android TV 앱 개발이 가능하게 됐다. 또한 프로젝트의 라이선스를 MIT 라이선스로 변경했다(GitHub 이슈와 답글 참고).

React Native의 릴리스 상태 
React Native의 릴리스 상태는 release status 레이블이 붙은 GitHub 이슈를 통해 확인할 수 있다.

2017년 3월에는 React 앱 개발을 도와주는 CLI 도구인 create-react-app와 유사한 도구인 create-react-native-app을 발표했다.

생태계

React Native에서 사용 가능한 다양한 컴포넌트가 많은 곳에서 개발되고 있다. 대표적인 저장소로 React Native Community와 React Community가 있다. 이 저장소에는 다수의 외부 소속 개발자와 React 개발팀이 같이 참여하고 있다.

그림 13 대표적인 React Native 커뮤니티 저장소

create-react-native-app은 Expo와 React 개발팀의 협업을 통해 개발된 프로젝트 중 하나다("Introducing Create React Native App" 참고).

Expo는 React Native 개발을 위한 다양한 오픈소스 도구 체인을 개발하고 있는데, 대표적인 프로젝트로 데스크톱에서 개발과 테스트를 해 볼 수 있는 환경을 제공하는 XDE(Expo Development Environment)가 있다.

그림 14 다양한 Expo 개발 도구들

React Native 관련 자료 
React Native 개발에 관심이 있다면 다음 자료를 추가로 참고한다. 
- Awesome React Native 
- Native Directory 
- How to Become a React Native Developer in 2018

향후 전망

현재의 인기에 따라 계속 성장세를 이어나갈 것으로 보인다. 그러나 GitHub의 로드맵과 마일스톤에는 구체적인 향후 개발 방향이 정리돼 있지 않아 어떤 기능이 추가될지 예측하기 어렵다. 다만 매달 진행되는 릴리스를 통해 빠른 속도로 개발이 이뤄지고 있다.

아직 메이저 버전이 릴리스되지 않은 상태라 0.14.7 버전에서 메이저 버전인 15.0.0 버전으로 바로 변경된 React와 같이 안정화가 이루어졌을 때 메이저 버전으로 바로 변경될 수도 있을 것이다.

많은 관심을 얻고 있어 꾸준한 발전을 이뤄 나갈 것으로 예측된다.

단일 코드베이스 개발 시도

최근에는 동일한 언어(JavaScript)를 사용해 한 가지 영역(네이티브 애플리케이션 또는 웹 애플리케이션)만 개발하지 않고, 동일한 코드베이스로 네이티브 애플리케이션과 웹 애플리케이션을 개발하려는 시도가 각 커뮤니티의 생태계에서 이뤄지고 있다.

React Native의 경우에는 React Native for Web 프로젝트를 통해 React Native로 개발된 앱을 웹 애플리케이션으로 렌더링하는 방법을 시도하고 있다.

Angular 또한 Angular NativeScript Seed 프로젝트에서 Angular CLI를 통해 하나의 코드베이스로 웹 애플리케이션과 NativeScript 애플리케이션을 개발할 수 있는 방법을 제공한다.

기업 입장에서는 각각을 별도로 개발하는 데 따르는 비용을 줄일 수 있기 때문에 이런 시도는 당연한 것이라 할 수 있다. 하지만 기존과는 다른 새로운 접근 방법이기 때문에 많은 프로젝트에 도입하려면 보다 많은 경험이 필요하며, 당분간은 꾸준한 시도가 있을 것으로 예측된다.

단일 코드베이스 개발 사례 
크리스마스 동영상 메시지를 만들 수 있는 'PNP 2017 Portable North Pole' 앱은 단일 코드베이스를 통해 효율적인 개발을 진행했던 사례를 "A Christmas Story with Nx, Angular and NativeScript-Part 1"에서 공유했다.

데스크톱 애플리케이션

데스크톱 애플리케이션 영역은 큰 변화가 이루어지는 영역은 아니다. 발전 속도와 방향은 다르지만 2017년과 동일한 구도가 계속 유지되고 있으며 승패가 이미 결정지어졌다고도 할 수 있다. 그러나 최근에 Microsoft의 GitHub 인수로 인해 Electron 또한 영향을 받을 수도 있을 것이다.

Electron은 GitHub가 개발한 편집기인 Atom의 데스크톱 셸 개발을 통해 탄생했다. 최근에 인기가 급부상하고 있는 편집기인 Microsoft의 VS Code 또한 Electron을 사용해 개발됐다. GitHub 인수로 인해 Microsoft가 2개의 유사한 제품을 보유하게 된 셈이라 향후 어떻게든 변화가 있을 것으로 예측된다.

Electron

Electron은 지난 1년간 폭발적이지는 않지만 꾸준한 성장세를 보이고 있다. npm-stat의 월 단위 다운로드 통계를 보면 Electron은 2017년 5월에는 npm을 통해 약 37만 번 다운로드됐지만, 2018년 4월에는 47% 정도가 늘어 약 54만 번 다운로드됐다.

그림 15 npm을 통한 Electron 다운로드 통계(2017년 5월~2018년 4월)

download-stats에서는 주요 모듈의 일간 다운로드 수를 고려한 통계를 확인할 수 있다.

2018년 5월 2일에 릴리스된 Electron 2.0.0은 Chrome 61과 Node.js 8.9.3, V8 6.1.534.41, GTK+ 3을 지원한다. 또한 다수의 새로운 API(파일 로딩, 로케일 설정, 애플리케이션 창 활성/비활성)가 추가됐으며, MacOS의 Mac App Store에서 인앱 구매(In-app purchases) 기능도 포함됐다(Microsoft Store 지원도 향후 고려 예정).

2018년 5월 초에는 오픈소스 앱의 자동 업데이트를 지원하는 서비스인 update.electronjs.org를 지원을 발표했으며("Easier AutoUpdating for Open-Source Apps" 참고), 자동 업데이트 모듈인 update-electron-app을 제공해 손쉽게 자동 업데이트를 수행할 수 있게 했다.

그림 16 자동 업데이트 모듈 업데이트 알림 메시지

Electron 1.6.9부터 TypeScript 정의 파일(definition file) 지원이 포함됐다. 이 기능은 코드 작성 시 API에 대한 코드 자동 완성 기능으로, 개발 편의성을 향상시키고 버그의 발생을 줄일 수 있게 한다.

Electron 2.0부터는 새로운 버전 부여 전략이 적용될 예정이다. 기존의 API의 변경(breaking changes)뿐만 아니라 Electron의 기반이 되는 Chromium의 업데이트와 Node.js의 메이저 버전 업데이트가 있을 때에도 메이저 버전을 릴리스할 것이라고 한다. 이에 따라 메이저 버전 릴리스가 이전보다 더 자주 이뤄질 것으로 보인다.

데스크톱 애플리케이션 영역에서 다른 뚜렷한 경쟁자가 없는 상태이기 때문에 현재의 선도적인 위치를 어렵지 않게 계속 유지할 것으로 보인다.

NW.js

Roger Wang이 개발한 NW.js(이전에는 node-webkit)는 2011년에 발표된 이후 많은 이들의 관심을 이끌어 냈으며, 이후 Electron의 탄생에 모태가 됐다.

node-webkit과 Electron 
Electron의 주요 개발자인 Cheng Zhao는 과거 node-webkit 프로젝트에서 인턴십으로 참여했고, node-webkit 0.3.6을 재구성해 Electrons을 탄생시켰다. Cheng Zhao의 글인 "From node-webkit to Electron 1.0"에서 Electron의 탄생에 관한 비화를 볼 수 있다.

NW.js의 다운로드 수가 별도로 제공되지 않기 때문에 Electron과 직접 비교하기는 어렵지만 NW.js 설치 도구인 nw 패키지의 다운로드 통계를 통해 간접적으로 상태를 확인할 수 있다. npm-stat의 월 단위 다운로드 통계에서 2018년 4월의 상태를 봤을 때 nw 패키지의 다운로드 수는 19,000여 건이지만 Electron의 다운로드 수는 25배 이상 많은 54만여 건이다.

그림 17 npm을 통한 nw 패키지 다운로드 통계(2017년 5월~2018년 4월)

2018년 5월에 릴리스된 NW.js 0.30.5에는 Chrome 66 지원과 Payment Request API 지원이 추가됐다("NW.js v0.30.5 Released with Chromium Update, PaymentRequest API Support" 참고).

기반 애플리케이션(Chromium과 Node.js)의 새로운 릴리스를 빠르게 반영해야 하기 때문에 Electron과 마찬가지로 릴리스가 상당히 자주 이뤄진다. NW.js의 릴리스에 관한 자세한 내용은 NW.js의 블로그를 참고한다.

향후 전망

"2017년과 이후 JavaScript의 동향 - 브라우저 밖의 JavaScript"에서 전망한 바와 같이 Electron이 압도적 우위를 점하고 있다. 웹 기술로 개발한 애플리케이션(웹 페이지)을 큰 수고 없이 데스크톱 애플리케이션으로 전환할 때는 NW.js를 선택하는 것이 더 좋을 수 있지만, 세밀한 제어와 기능이 필요하다면 Electron을 선택해야 한다.

"Nw.js vs. Electron"에서는 HTML5로 개발한 웹 애플리케이션을 NW.js와 Electron을 사용해 데스크톱 애플리케이션으로 전환하면서 겪은 경험을 볼 수 있다.

Electron과 기능적 차이, 모기업인 인텔의 오픈소스에 대한 소극적 지원과 생태계 확산 등을 고려한다면 NW.js가 현 상황을 반전시키는 것은 앞으로도 역부족으로 보인다. 그러나 node-webkit의 등장이 Electron의 산파 역할을 했듯이 NW.js와 같은 시도가 더 나은 도구의 등장을 위한 밑거름을 제공한다는 것으로도 큰 가치와 의미가 있다고 볼 수 있다.

PWA(Progressive Web Apps)

다수의 표준 기술 모음에 기반을 두는 PWA는 Google이 확산을 위해 많은 노력을 기울여 왔지만 오랜 시간 동안 주요 브라우저(Safari와 Microsoft Edge)의 미지원에 가로막혀 확산되지 못하는 상태가 지속됐다.

PWA 공식 로고 
PWA 공식 로고는 2017년에 PWA 커뮤니티에 의해 선정된 로고다. PWA 커뮤니티에서 공식 로고를 선정한 과정은 "We now have a community-approved Progressive Web Apps logo!"를 참고한다.

PWA를 구성하는 핵심 기술은 Service Worker(오프라인 캐싱)라 할 수 있다.

Service Workers와 System Application WG 
Service Workers API는 삼성과 Google, 인텔, Mozilla의 Web OS 표준화를 위한 System Application WG 활동에서 파생됐다. 삼성에 근무했던(현재는 Microsoft Edge 개발팀 소속) 송정기 님이 표준화를 위해 주도적인 역할을 수행했다. System Application WG의 활동과 Service Workers에 관해서는 송정기 님의 "Leaving Samsung"에서 'SysApps WG and Service Workers'를 참고한다.

Safari는 프리뷰 릴리스인 Safari Technolgy Preview 46(2017년 12월 20일 공개)을 통해 처음으로 Service Worker를 지원하기 시작했고, 이후 Safari 11.1(MacOS 10.13.4)에서 정식으로 PWA를 지원했다.

그림 18 Safari의 Service Worker 지원을 알리는 Safari 개발자 Ricky Mondello의 트윗

WebKit과 Service Workers 
WebKit은 다른 제조사와 달리 Service Workers의 등록 정보와 캐시가 사용되지 않으면 수주 후에 자동으로 콘텐츠를 삭제하는 정책을 적용하고 있어 이슈가 제기되고 있기도 하다("Workers at Your Service" 참고). 
iOS에서 PWA 사용과 관련된 자세한 기술적 이슈는 "Progressive Web Apps on iOS are here"를 참고한다.

Microsoft Edge의 경우에는 2017년 12월에 릴리스된 Windows Insider Build에 처음으로 Service Workers 지원이 포함됐다. 이후 EdgeHTML 17(2018년 4월)에서 Service Workers와 push notifications가 기본으로 활성화됐다.

이로써 모든 모던 웹브라우저에서 PWA를 사용할 수 있는 기본적인 환경이 갖춰지게 됐다(("is ServiceWorker ready?" 참고).

생태계

PWA 확산에 노력했던 Google은 다양한 PWA 도구를 선보였다. PWA는 특정 기술만을 지칭하는 것이 아니기 때문에 관련된 도구는 주로 관련된 기술 전체가 아닌 특정 기술을 대상으로 한다.

Workbox

Workbox는 웹 애플리케이션에 오프라인 지원을 추가할 수 있게 하는 도구다. SO PWA는 개발자 질의응답 사이트인 Stack Overflow의 글을 확인할 수 있는 PWA 샘플 앱으로, Workbox를 사용해 개발됐다.

기존에 Google이 개발한 도구인 sw-toolbox와 sw-precache는 Workbox 발표로 인해 향후 deprecate 상태로 변경될 것으로 보인다.

HNPWA

HNPWA는 MVC 프레임워크를 선택할 때 참고 자료를 제공하는 역할을 하는 TodoMVC의 PWA 버전이라 생각하면 된다.

커뮤니티 기반 IT 뉴스 사이트인 Hacker News의 클라이언트를 PWA로 개발한 사례를 모아 놓았다. 여러 가지 프레임워크로 개발된 PWA 웹 애플리케이션을 살펴볼 수 있어 PWA 앱 개발에 유용한 참고 자료가 된다.

PWA Starter Kit

PWA Starter Kit은 PWA 앱 개발을 쉽게 시작할 수 있도록 제공되는 샘플 프로젝트다. 환경 구성과 페이지 구성(디자인, 반응형 레이아웃, 등)이 포함돼 있다. PWA Starter Kit을 활용하는 예제는 Google I/O 2018의 "PWA starter kit: build fast, scalable, modern apps with Web Components" 세션을 참고한다.

pwa-helpers

Polymer 개발팀에서 개발한 pwa-helpers는 PWA 앱을 개발할 때 사용할 수 있는 다양한 도구(router, network, metadata, media-query helper)와 테스트 도구, Redux 헬퍼를 제공한다.

향후 전망

2018년 5월 8일~10일에 진행된 Google I/O 2018에서는 최근의 환경 변화를 반영하듯 다수의 PWA 관련 세션이 진행됐다. 이는 앞으로도 Google이 계속해서 PWA 영역에 대한 활발한 행보를 이어나갈 것으로 예측하게 만든다.

다음은 Google I/O 2018에서 진행된 PWA 관련 세션이다.

• PWAs: building bridges to mobile, desktop, and native
• PWA starter kit: build fast, scalable, modern apps with Web Components
• Beyond single-page apps: alternative architectures for your PWA
• Build e-commerce sites for the modern web with AMP, PWA, and more

Microsoft 또한 Microsoft Edge에 PWA 지원을 포함한 이후 PWA 기술에 대한 투자를 늘려나갈 것으로 보인다. [Microsoft Store에서의 PWA 앱 배포와 관련된 글인 "Progressive Web Apps in the Microsoft Store"와 여러 기술 문서를 통해 간접적으로 방향을 확인해 볼 수 있다.

그림 19 Progressive Web Apps on Windows 기술 문서 페이지

PWA는 웹이지만 애플리케이션처럼 설치되고 사용될 수 있다는 점에서 그동안 네이티브 모바일 애플리케이션의 대체재로 많은 관심을 받았다.

네이티브 모바일 애플리케이션 개발의 다양한 대체재에 관해서는 "Choosing Between Progressive Web Apps, React Native & NativeScript in 2018"을 참고한다.

이제 환경이 무르익었다. PWA가 '만년 기대주'에서 주류 기술 스택으로 자리 잡을 수 있을지 지켜보는 것은 매우 흥미로운 일일 것이다.

뛰어난 인터넷 인프라 구성으로 인해 국내의 인터넷 환경에서는 PWA의 주요 기능 중 하나인 오프라인 캐싱이 상대적으로 크게 주목받지 못 하고 있다고 생각한다. 그러나 네트워크의 상태에 상관없이 다양한 환경에서 사용할 수 있는 향상된 사용자 경험을 제공하려는 지속적인 노력은 서비스 제공자와 개발자에게 필수적인 일일 것이다.

증강 현실과 가상 현실

증강 현실과 가상 현실은 유망한 기술 분야로 수년간 많은 이들의 관심을 얻고 있는 분야다. 하지만 관심에 비해 활발한 사용이 아직 이뤄지고 있지는 않다. 주도권을 잡은 도구가 없는 상태이기 때문에 수년간 과도기 상태를 유지하고 있다. 그러나 앞으로 기술의 사용이 활발하게 일어날 것으로 보이기 때문에 주도권을 차지하려는 노력은 한동안 계속될 것으로 보인다.

WebVR API

웹에서 가상 현실의 구현을 위해 2016년 3월에 제안된 WebVR API를 통해 표준화가 진행되고 있었고("Introducing the WebVR 1.0 API Proposal" 참고), WebVR 1.1이 2017년 4월에 발표됐다.

그림 20 다양한 WebVR 관련 도구

2017년 한 해 동안 WebVR은 브라우저의 지원이 확산되고 다양한 도구와 라이브러리가 등장하면서 큰 성장세와 인기를 얻었다.

• 브라우저의 지원 확산
  • Firefox 55.0(2017년 08월)
  • Microsoft Edge(2017년 04월)
  • 삼성의 GearVR(2016년 12월)
• 다양한 도구와 라이브러리의 등장
  • Mozilla의 A-Frame
  • React에서 360 뷰어 및 가상 현실 콘텐츠 구현을 위한 React 360(2017년 4월)
  • 웹 게임 엔진 PlayCanvas, 가상 현실 콘텐츠의 생성과 공유를 위한 Vizor, 증강 현실/가상 현실 생성 도구인 Ottifox와 Sketchfab의 VR 편집기, AR.js 등

그러나 현재의 WebVR API는 개발자가 형태의 애플리케이션 개발에 충분치 못해 새로운 API의 디자인의 필요성이 제기되었다.

WebVR 리팩터링 의견 
Reddit을 통해 진행된 Chrome 개발팀의 AMA(Ask Me Anything)에서 WebVR 리팩터링의 필요성에 대한 개발팀의 의견을 확인할 수 있다. 
- Based on feedback received from web developers, hardware manufacturers, and other implementers the WebVR API has been undergoing a significant refactoring.(웹 개발자, 하드웨어 제조사, 그 외 구현 관련자에게 받은 피드백을 기반으로 WebVR API을 커다랗게 변화시킬 리팩터링이 이뤄졌다.)

WebXR Device API

WebVR API의 한계에 따라 WebVR을 대체하는 새로운 API인 WebXR Device API가 2017년 10월에 제안됐다("Bringing Mixed Reality to the Web" 참고). 기존의 가상 현실에 더해 증강 현실의 지원도 포함됐으며, 'Immersive Web'의 개념을 주창한다.

Immersive Web 
Immersive Web은 웹에서 몰입 환경을 구현할 수 있도록 앞으로 다가올 새로운 기술의 모음이라 정의할 수 있다(The immersive web is defined as a collection of new and upcoming technologies that prepares the web for the full spectrum of immersive computing,…). 
Immersive Web에 관한 더 자세한 내용은 다음 자료를 참고한다. 
- Like the internet? Google wants to attach it to your face 
- Welcome to the immersive web

그림 21 현실에서 가상 현실로 단계별 스펙트럼(원본 출처: Welcome to the immersive web)

WebXR Device API의 표준화는 Google과 Microsoft, Mozilla의 개발자가 참여한 'Immersive Web Community Group'을 통해 진행되고 있으며, 기존의 WebVR 2.0을 대체한다("WebVR is now 'WebXR Device API', supports augmented reality" 참고).

현재 Chrome 67에서는 chrome://flags/#webxr 플래그를 통해 WebXR Device API를 사용할 수 있으며(가상 현실만 가능, 증강 현실은 Chrome 68에 포함 예정), 다음의 환경을 지원한다.

• 헤드셋: Daydream VR, Cardboard 등
• 데스크톱 가상 현실 시스템: HTC VIVE, Oculus Rift 등
• 가상 현실 장비가 없는 경우: 스마트폰의 센서를 이용하는 Magic Window. magic Window는 방향 센서(orientation sensor) 기능이 있는 모바일 기기에서 단일 뷰 기반의 앱 렌더러를 통해 Immersive Web 콘텐츠를 볼 수 있는 기술이다("The future of the web is immersive (Google I/O '18)" 참고).

WebXR Device API에 관한 더 자세한 내용은 다음 자료를 참고한다. 
- The future of the web is immersive 
- Best practices to design AR applications

향후 전망

WebVR에서 WebXR로의 발전과 Apple의 ARKit API 지원(iOS 11), Google의 ARCore API(Oreo) 지원 등이 이어지며 점점 증강 현실과 가상 현실을 활용한 다양한 서비스와 앱이 등장할 것으로 예측된다.

네이티브 앱뿐만 아니라 WebXR을 통해 웹에서도 새로운 기술을 활용할 수 있게 됐다. 그러나 아직 기술의 표준화가 성숙한 단계에 진입하지 못한 상태기 때문에 당분간은 많은 개발자와 기업이 실사용보다는 가능성을 확인하는 용도로 접근을 할 것으로 보인다. 하지만 증강 현실과 가상 현실이 점점 대세 기술로 관심을 얻고 있어 잘 발전한다면 향후 웹에서 사용도 점차 확산할 것으로 기대된다.

다음은 증강 현실과 가상 현실 기술에 참고할 수 있는 도구와 예제 사이트다. 
- WebXR Polyfill: Polyfill로 구현한 WebXR 
- three.ar.js: 유명한 JavaScript 3D 라이브러리인 three.js에서 증강 현실 구현을 위한 헬퍼 라이브러리 
- WebXR Viewer: Mozilla의 iOS용 WebXR 뷰어 앱 
- WebXR 예제-samples: WebXR로 구현한 다양한 예제 
- Mozilla VR: Mozilla의 VR 사이트

마치며

JavaScript가 처음 발표된 1995년 12월 4일에는 JavaScript가 지금과 같은 위치에 있을 것이라고 아무도 상상하지 못했을 것이다.

그림 22 JavaScript 개발을 처음 발표했던 Netscape 사의 보도 자료(원본 출처: weybackmachine)

1999년에 발표된 Martin Fowler의 책 "Refactoring - Improving the Design of Existing Code"(한글 번역본의 제목은 "리팩토링: 코드 품질을 개선하는 객체지향 사고법")는 특정 언어를 대상으로 설명하지는 않는다. 다만 리팩터링의 내용을 최대한 잘 전달하기 위해 많은 개발자가 사용하고 있고 이해하기 쉬운 언어인 'Java'를 예제로 사용했다. 하지만 2018년 말에 완성될 두 번째 판에서는 JavaScript를 예제로 사용한다고 밝혔다("Announcing the Second Edition of "Refactoring"" 참고).

클래스 중심이 아니라는 언어적 특성과 상위 레벨 함수(top-level functions)의 존재, 일반적인 일급 클래스 함수(first-class function)의 사용 등의 JavaScript의 특징 때문에 클래스에 얽매이지 않고 리팩터링을 설명할 수 있기 때문이라고 Martin Fowler는 이유를 설명한다.

…But the compelling reason for choosing it over Java is that isn't wholly centered on classes. There are top-level functions, and use of first-class functions is common. This makes it much easier to show refactoring out of the context of classes. - "Announcing the Second Edition of "Refactoring""

JavaScript의 끝이 어디일지 알 수는 없다. 하지만 JavaScript가 계속 성장하고 있고 앞으로도 그럴 가능성이 매우 높다는 데 이의를 제기하는 사람은 아마 없을 것이다.

JavaScript는 아직도 세상을 먹어 치우고 있다.

JavaScript is still eating the world.