'프로그래밍/이것저것'에 해당되는 글 10건

<meta name="DuzonNewturns" content="DocuStyler" />

- Using WebCenter Spaces Extension Samples (11.1.1.5.0) 문서는 웹센타 스페이스 확장방법에 대해서 기술해 놓았습니다. 이번에 사용한 사항은 세션 타임아웃 변경하는법 입니다. 모든 내용이 메뉴얼에 자세하게 기술되어 있습니다. 중간 중간에 필요한 부분과 간단한 멘트를 달아 두었습니다. 참고 하시기 바랍니다.   단, 처음부터 WebCenterSpacesSharedLibExtension 프로젝트를 빌드하시면 안됩니다. 필요한 라이브러리만 선택해서 빌드해야 합니다.   추가로 제가 회사에서 테스트한 파일을 첨부 하였습니다. 참고 하시기 바랍니다.     - 첨부파일 1. 메뉴얼 2. 세션타임 줄이는 소스 3. 빌드 환경설정 4. 필요한 샘플 프로젝트     - 차례 중에서 필요한 부분 입니다.(목차의 일부분 입니다.) Deploying and Undeploying Sample WebCenter Spaces Extensions 3 Overview .. 3 Downloading, Copying, and Exploring the WebCenter Spaces Sample Workspace .. 4 Setting Build and Deployment Options (config.properties) .. 8 Building and Deploying a Custom Shared Library for WebCenter Spaces .. 10 Removing WebCenter Spaces Extensions .. 11 Sample – Customizing the Session Timeout .. 14     - 커스텀 라이브버리 추가 방법 순서 입니다.(메뉴얼 순서 그대로 입니다.) 1. JavaCodeAndSessionTimeout 내에 SessionTimeoutPhaseListener.java 를 수정합니다. 2. JavaCodeAndSessionTimeout 프로젝트를 jar로 컴파일해서 생성합니다. 3. WebCenterSpacesSharedLibExtension 프로젝트에 생성한 jar 파일을 추가합니다. 4. WebCenterSpacesSharedLibExtension 내 config.properties 파일을 로컬 환경에 맞게 설정합니다. 5. 메뉴얼에 따라서 빌드 합니다. 6. 웹로직 콘솔에 접속하여 라이브러리 추가 여부를 확인하면 됩니다. 7. 이후 제대로 라이브러라가 추가 되었다면 세션 만료후 SessionExpired.html로 자동 이동 합니다.

#!/bin/sh
USER_NAME=웹로직서버계정
DOMAIN_NAME=웹로직도메인

SERVER_NAME=서버명

ADMIN_URL=t3://서버IP or 도메인:7001
DOMAIN_HOME=/webcenter/wls1036/user_projects/domains/웹로직도메인
LOG_DIR=/webcenter/wls1036/user_projects/domains/웹로직도메인/logs
LOG_NAME=$SERVER_NAME
LANG=C
# Check User Name
IAM=`id | awk '{print substr($1, 1, index($1,")")-1 )}' | awk '{print substr($1, index($1,"(")+1 )}'`

# Check startup user validation
if [ $USER_NAME != $IAM ]
then
echo "Startup Error :[SALT-WLS001] User validation is failed. This instance has been started as \"$IAM\", actual script owner is
 \"$USER_NAME\""
 exit
 fi

 # Check process status
 PID=`ps -ef|grep java|grep :${DOMAIN_NAME}_${SERVER_NAME} |awk '{print $2}'`
 if [ "$PID" != "" ]
 then
 echo "Startup Error :[SALT-WLS002] \"${DOMAIN_NAME}_${SERVER_NAME}\" server is already running !!!"

 exit
 fi

mv $LOG_DIR/stdout/$LOG_NAME.log $LOG_DIR/stdout/backup/$LOG_NAME.log.`date '+20%y%m%d_%H%M%S'`

########## Custom Args ##########
#Common start Args
 USER_MEM_ARGS="-D:${DOMAIN_NAME}_${SERVER_NAME}  -Xms2048m -Xmx2048m -XX:MaxPermSize=512m"
#64bit JDK
 ## only HP
 #USER_MEM_ARGS="${USER_MEM_ARGS} -d64"

#GC (not setted)

#GC Log
 ## General
 ## GC Log gc file write
        USER_MEM_ARGS="${USER_MEM_ARGS} -verbose:gc -XX:+PrintGCDetails -Xloggc:${LOG_DIR}/gc/${SERVER_NAME}_GC_`date '+%y%m%d_%H%M%S'`.gc"
        ## GC Log stdout file write
        #USER_MEM_ARGS="${USER_MEM_ARGS} -verbose:gc -XX:+PrintGCDetails -Xloggc:=${LOG_DIR}/gc/${SERVER_NAME}_GC_`date '+%y%m%d_%H%M%S'`.gc"
 ##HP only 
 #USER_MEM_ARGS="${USER_MEM_ARGS} -Xverbosegc:file=${LOG_DIR}/gc/${SERVER_NAME}_GC_`date '+%y%m%d_%H%M%S'`.gc"

 ##only IBM
  #USER_MEM_ARGS="${USER_MEM_ARGS} -Xverbosegclog:${LOG_DIR}/gc/${SERVER_NAME}_GC_`date '+%y%m%d_%H%M%S'`.gc" 
  
#HeapDump
 ## hp : over 1.4.2.10 or over 1.5.0.03
 ## sun :  over 1.4.2_12 or over 1.5.0_07 
 #USER_MEM_ARGS="${USER_MEM_ARGS} -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${LOG_DIR}/heapdump"

 ##IBM only ( kill -3 <pid> makes heap dump setting)
 #export IBM_HEAPDUMP=true
 #export IBM_HEAP_DUMP=true
 #export IBM_HEAPDUMP_OUTOFMEMORY=true
 #export IBM_JAVADUMP_OUTOFMEMORY=true
 #export IBM_HEAPDUMPDIR=${LOG_DIR}/heapdump
 #export IBM_JAVACOREDIR=${LOG_DIR}/heapdump

#Jconsole using
 #USER_MEM_ARGS="${USER_MEM_ARGS} -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"

#Common end Args
 export USER_MEM_ARGS
########## Custom Args ##########

nohup  $DOMAIN_HOME/bin/startManagedWebLogic.sh $SERVER_NAME $ADMIN_URL >> $LOG_DIR/stdout/$LOG_NAME.log &
sleep 2

# don't use this in WLS 8.1 at AIX
tail -f $LOG_DIR/stdout/$LOG_NAME.log

SE가 웹센터 설치후 각각의 서버를 본격적으로 띄우기전에 수동으로 서버를 띄워서 각각의 서버의 설정과 필요한 데이타들을 생성해주어야 각서버의 구동 스크립트를  이용해서 구동했을때 문제없이 서버가 로딩이 된다.

1. /webcenter/wls1036/user_projects/domains/ECOLL/bin 위치에 보면 웹로직의 구동 스크립트가 있다. 

./startManagedWebLogic.sh 구동하려는서버명 http://192.168.xxx.xxx:7001 (콘솔)

와 같이 실행을 하면 해당 서버가 기동하게 되고  /webcenter/wls1036/user_projects/domains/ECOLL/servers/ 밑에 해당 서버의 정보가 생성되어진다.

2. 수동구동을 통행 기본적인 정보가 만들어 지면 수동으로 올린 해당 서버를 종료하고

/webcenter/wls1036/user_projects/domains/ECOLL/servers/Adminserver/security 디렉토리를 복사해서 구동하려는 서버 위치에 복사해준다.

3. /webcenter/wls1036/user_projects/domains/ECOLL 에서 구동 스크립트를 이용해 구동한다.

▶Oracle WebCenter Suite

1)정의: Oracle WebCenter는 기업 내 여러 시스템으로 관리되고 있는 모든 자원을 통합하여 하나의 포탈환경에서 사용하도록 해주는 Enterprise portal solution.

Ps. BEA가 Oracle에 합병된 후 Oracle WebCenter Suit의 구성은,

OWCS(Oracle WebCenter Suit)는 기존 WebCenter의 구성에 UI부분과 기타 서비스 부분에 BEA의 ALUI의 Product의 기능들이 + α 되었다고 보면 이해하기 쉽다.

▶WebCenter Portal Solution

1)제품개요: 엔터프라이즈 포탈을 신속하게 구축할 수 있는 통합 소프트웨어

2)주요기능:  -사용자 및 권한 관리 (웹 서비스에 대한 사용자 자동 동기화 기능,

조직의 그룹 및 dynamic 그룹에 따른 권한 관리기능)

  -포틀릿/메뉴 관리 (JAVA, .NET, ASP, JSP등 다양한 개발언어 지원)

            -개인화/차별화 (개인의 Role에 따른 커뮤니티 제공, 사용자 그룹에 따른 멀티포탈 기능 제공)

            -통계 분석 (커뮤니티 및 포틀릿, 로그인 횟수, 응답시간 정보등을 제공)

▶Portlet(포틀릿) 개념

포틀릿이란 재사용이 가능한 웹 구성요소로서 포탈 사용자들에게 관련 정보를 표시해주는데 사용된다.

// html을 return하는 모든 것

포틀릿 규격은 포틀릿과 포탈 사이트 사이의 상호 운용성을 가능하게 해준다.

포틀릿은 view의 종류,크기,배치를 다르게 할 수 있다.

Ex) 어떤 주소(URL)을 호출 했다고 가정했을 때, 페이지는 타이틀,프로필,카탈로그,달력,바디포스팅부분 들의 여러가지 포틀릿으로 구성되어 있다.

 ▶WebCenter Interaction(구 제품)에서 기능 추출 ☞ WebCenter Portal + α

// WebCenter Interaction(기존 고객 유지보수)

▶Oracle WebCenter Portal 11g(10.3.3)

-병렬 포탈엔진 ( Req가 들어오면 포틀릿 서버들이 해당 Req에 관련한 포틀릿 페이지를 return함.)

-포틀릿서버위에 포틀릿이 개발되어 올라간다.

-모든 시스템의 제일 앞단에 존재 // 디자인에 예민한 시스템

*특징

ð  분산아키텍처

ð  통합이 상대적으로 유용

ð  사용자와의 동기화 유용 (조직도 관리 유연)

ð  개발생산성

ð  병렬처리이기 때문에 기다리지 않고 출력처리를 할 수 있음 (화면 갱신) / (성능상 이득)

▶포틀릿 소스 간단한 특징

-<pt: ~> // 이 페이지는 포틀릿입니다.. 라고 알려주는 정보.

-<head><body>태그가 없다. // why? 전체페이지가 아니라 일부이기 때문에.

-포탈엔진에서 너비, 폭, 위치 설정가능

▶pencake (penta framework)

-신속하고 안정적인 포탈개발을 위해 만들어진 포탈개발 프레임워크

-반복적인 작업 or 개발자 교육시간x ☞ 개발 편이, 커뮤니케이션 향상에 도움

-       1)Framework (포틀릿을 쉽게 개발하게 해주는)

-       2)Social Enterprise(SNS기능을 pencake에 넣은 것)

-       3)ByteFly(시스템 간에 데이터를 주고 받을 때 사용하는 것)

웹 서비스를 운영하는 서버 관리자라면 외부에서 어떤 요청이 들어오는지 그리고 어떤 사용자가 있는지에 대한 정보를 담고 있는 액세스 로그에 관심을 가질 필요가 있습니다. 과거 인터넷이 발달하기 전 시절과는 달리 요즘은 PC 및 스마트폰의 대중화로 다양한 OS와 브라우저를 사용하고 있고, 공개 도메인에 대해 크롤러나 외부 해킹과 같은 무차별적 호출이 많아지고 있는 추세이기 때문입니다.

다행히도 일반적인 웹 서버는 이와 같은 외부 호출에 대한 정보를 로그로 남기는 기능을 제공합니다. 특히 Apache는 다양한 형식으로 액세스 로그를 남길 수 있는 모듈을 제공하기 때문에 이를 활용하면 유의미한 데이터를 만들어 낼 수 있습니다.

이 글에서는 Apache 2.2를 웹 서버로 운영하며 액세스 로그를 분석해 유의미한 결과를 얻은 사례를 공유하겠습니다.

Apache 액세스 로그는 어떻게 생겼을까

Apache 액세스 로그를 분석하기 위해서 어떤 형식으로 구성되어 있는지, 그리고 각 데이터에서 어떤 정보를 추출할 수 있는지 알아보자.

Apache는 log_config_module 모듈을 제공하여, 형식 문자열을 사용하여 액세스 로그의 형식을 설정할 수 있게 한다. 형식 문자열 중 이 글에서 필요한 부분만 살펴보면 다음과 같다.

표 1 Apache 액세스 로그 형식 문자열(출처: 아파치 모듈 mod_log_config)

형식 문자열을 사용하여 Apache 설정 파일(httpd.conf)에 다음과 같이 액세스 로그의 형식을 설정할 수 있다.

LogFormat "%h %l %u %t \"%r\" %>s %b %D \"%{Referer}i\" \"%{User-Agent}i\"" combined  
CustomLog "| /~<del>/apache/bin/rotatelogs -l /</del>~/logs/apache/access.log.%Y%m%d 86400" combined env=!nolog-request  

위와 같이 설정한 결과 생성된 액세스 로그는 다음과 같다.

123.123.123.123 - - [12/Apr/2018:17:03:50 +0900] "GET /api/aaaa HTTP/1.1" 200 34 1468 "https://m.naver.com" "Mozilla/5.0 (iPhone; CPU iPhone OS 11_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E216 NAVER(inapp; search; 580; 8.6.3; 7)"  

외부에서 요청이 발생할 때마다 위와 같은 문자열이 로깅된다. 그렇다면 이 문자열은 무슨 의미일까? 간단하게 살펴보면 아래와 같은 정보로 구성되어 있는 것을 확인할 수 있다.

그림 1 액세스 로그 구성 예

1. 원격 호스트 IP 주소(요청자)
2. 요청 시간
3. 'GET' 메서드를 사용하고 '/api/aaaa'라는 경로에 'HTTP/1.1'의 프로토콜로 요청
4. HTTP 상태 코드
5. HTTP 헤더를 제외한 전송 바이트 수
6. 요청을 처리하는 데 걸린 시간(ms)
7. 리퍼러(referrer)

위에서 언급한 LogFormat 내용 중 마지막에 있는 User-Agent(이하 UA)는 Wikipedia에 따르면 ‘사용자를 대신하여 일을 수행하는 소프트웨어 에이전트’라고 한다. 즉, UA만 알아도 어떤 기기/브라우저를 사용하는지 알 수 있다는 것이다. UserAgentString.com에 접속해 보면 자신의 UA 문자열을 파싱하여 얻은 OS, 브라우저 등의 정보를 볼 수 있다. Mozilla MDN의 User-Agent - HTTP에는 다양한 브라우저의 UA 문자열과 지원 정보가 정리되어 있다. 주로 사용되는 브라우저는 모두 UA 문자열을 지원하는 것을 확인할 수 있다.

그림 2 User-Agent 브라우저 호환성(원본 출처: http://developer.mozilla.org)

이렇게 Apache가 제공하는 모듈을 사용하면 요청지의 다양한 정보를 확인할 수 있다. 하지만 하루에 생성되는 액세스 로그가 수백 건, 수천 건이라면 한줄 한줄을 살펴보고 있을 수는 없다. 우리는 개발자이니 개발자답게 이를 분석해서 한눈에 볼 수 있는 방법을 생각해 보자.

분석 방법 1: 가장 단순하게

그럼 내가 운영하는 서버에 들어온 사용자 혹은 요청을 어떻게 분석할 수 있을까? 가장 단순한 방법으로는 이러한 데이터를 Linux 명령어나 Excel 등을 활용하여 데이터를 추출한 후 정규식을 사용하여 일정한 형식으로 만들고 그 결과를 다시 그룹화하면 얼추 원하는 정보를 얻을 수 있다. UA 문자열과 같은 경우는 이미 다른 사람들이 만들어 둔 정규식을 가져다 사용할 수도 있겠다(예: RegExr).

하지만 자동화되어 있지 않아 정보를 얻으려 할 때마다 매우 번거롭다. 데이터 추출 자동화를 직접 개발한다고 해도 실시간으로 정보를 살펴보고 싶은 경우에는 제한 사항이 많다.

분석 방법 2: Elastic Stack을 활용한다면

Elastic 공식 홈페이지에서도 소개하듯이 Elastic Stack은 실시간 데이터 분석에서부터 다양한 형식의 시각화까지 제공하고 있다. 오픈소스인 Elastic Stack은 크게 데이터를 담는 Elasticsearch, 데이터를 수집 및 전송하며 파이프라인 역할을 담당하는 Logstash, 그리고 데이터를 시각화하는 Kibana로 구성되어 있다. 전에는 ELK라고도 불렸으나 지금의 정식 명칭은 Elastic Stack이다. 그럼 이 Elastic Stack을 활용하여 어떻게 단순한 방법을 벗어나서 효율적으로 서버로부터의 인입을 분석할 수 있을까?

간단하게 설명하면, 위에서 언급한 액세스 로그를 사용하지 않고 프런트엔드 단계에서 JavaScript로 UA 문자열을 구한다. 이러한 정보를 받을 수 있는 API를 서버에 만들어 두고 서버에 UA 문자열을 전송한다. 서버에서는 해당 UA 문자열을 분석 후 Elasticsearch로 전송한다. 알기 쉽게 그림으로 살펴보자.

그림 3 좀 더 '나은' 방법 - Elastic Stack 활용

프런트엔드 단계에서는 navigator.userAgent를 활용하여 UA 문자열을 구할 수 있다. API에서는 UA 문자열을 받아 파싱하는데 관련 코드는 다음과 같이 작성하였다.

private static final String VERSION_SEPARATOR = ".";  
private void userAgentParsingToMap(String userAgent, Map<String, Object> dataMap) {  
    HashMap browser = Browser.lookup(userAgent);
    HashMap os = OS.lookup(userAgent);
    HashMap device = Device.lookup(userAgent);
    dataMap.put("browserName", browser.get("family"));
    dataMap.put("browserVersion", getVersion(browser));
    dataMap.put("osName", os.get("family"));
    dataMap.put("osVersion", getVersion(os));
    dataMap.put("deviceModel", device.get("model"));
    dataMap.put("deviceBrand", device.get("brand"));
}
private String getVersion(HashMap dataMap) {  
    String majorVersion = (String)dataMap.get("major");
    if (StringUtils.isEmpty(majorVersion)) {
        return StringUtils.EMPTY;
    }
    String minorVersion = (String)dataMap.get("minor");
    String pathVersion = (String)dataMap.get("path");
    StringBuffer sb = new StringBuffer();
    sb.append(majorVersion);
    if (!StringUtils.isEmpty(minorVersion)) {
        sb.append(VERSION_SEPARATOR);
        sb.append(minorVersion);
    }
    if (!StringUtils.isEmpty(pathVersion)) {
        sb.append(VERSION_SEPARATOR);
        sb.append(pathVersion);
    }
    return sb.toString();
}

참고로 Java 단계에서 UA 문자열을 파싱하는 파서는 여러 가지가 있는데 그중 uap_clj 모듈이 상세한 파싱 결과를 제공하여 이를 사용했다.

표 2 UA 문자열 파싱 모듈 비교

파싱 결과는 다음과 같다.

Browser : {patch=3239, family=Chrome Mobile, major=63, minor=0}  
OS : {patch=1, patch_minor=, family=Android, major=5, minor=1}  
Device : {model=Nexus 6, family=Nexus 6, brand=Generic_Android}  

위와 같이 구성하면 Elasticsearch에 인덱싱된 데이터를 Kibana에서 입맛에 맞게 실시간으로 볼 수 있다. 하지만 별도의 API를 만들어야 한다는 점, 프런트엔드 단계에서 로깅을 위한 JavaScript 로직이 들어가야 한다는 점, 운영하는 모든 페이지에 해당 JavaScript를 넣어야 한다는 점, 액세스 로그만큼 풍부한 정보를 볼 수 없다는 점 등 여러모로 아쉬운 점이 많다. 뭔가 더 좋은 방법이 없을까? 깔끔하면서도 '우아한' 방법. 더 열심히 생각해 보자.

분석 방법 3: 조금 더 우아하게

Logstash보다 가벼운 log shipper인 Filebeat를 이용하여 Apache 액세스 로그를 수집한다. Filebeat의 설정은 다음과 같다.

filebeat.prospectors:  
  - type: log
    enabled: true
    paths:
      - /log/access.log.*
output.logstash:  
  hosts: ["x.x.x.x:5044"]

이렇게 Filebeat가 액세스 로그를 수집하여 Logstash에 전달하면 UA 문자열을 파싱하는 Logstash의 plugins-filters-useragent와 IP 주소를 정해진 규칙에 의해 위도/경도 값으로 바꿔주는 Logstash의 plugins-filters-geoip를 활용해서 로그를 입맛에 맞게 필터링한다. 설정은 다음과 같다.

input {  
        beat {
                port => "5044"
        }
}
filter {  
        grok {
                match => { "message" => ["%{IPORHOST:clientip} (?:-|%{USER:ident}) (?:-|%{USER:auth}) \[%{HTTPDATE:timestamp}\] \"(?:%{WORD:httpMethod} %{NOTSPACE:uri}(?: HTTP/%{NUMBER:httpversion})?|-)\" %{NUMBER:responseCode} (?:-|%{NUMBER:bytes}) (?:-|%{NUMBER:bytes2})( \"%{DATA:referrer}\")?( \"%{DATA:user-agent}\")?"] }
                remove_field => ["timestamp","@version","path","tags","httpversion","bytes2"]
        }
        useragent {
                source => "user-agent"
        }
        if [os_major]  {
                mutate {
                        add_field => {
                                os_combine => "%{os} %{os_major}.%{os_minor}"
                        }
                }
        } else {
                 mutate {
                        add_field => {
                                os_combine => "%{os}"
                        }
                }
        }
        if [os] =~ "Windows" {
                mutate {
                        update => {
                                "os_name" => "Windows"
                        }
                }
        }
        if [os] =~ "Mac" {
                mutate {
                        update => {
                                "os_name" => "Mac"
                        }
                }
        }
        geoip {
                source => "clientip"
                target => "geoip"
        }
}
output {  
        kafka {
                bootstrap_servers => "~<del>"
                topic_id => "</del>~"
                codec => json{}
        }
}

설정하는 과정에서 grok filter 패턴을 작성하는 데 많은 시간을 할애해야만 했다. 개인적으로는 http://grokconstructor.appspot.com/do/match?example=2에서 테스트해 보면서 패턴을 작성한 것이 도움이 되었다. 그리고 Logstash가 파싱한 정보를 조금 다듬기 위해 mutate filter를 사용해서 필드를 조합, 수정하였다.

마지막으로, 인입량이 많을 경우 버퍼 역할을 하고 데이터 유실을 방지하기 위해 중간에 Kafka를 두었다. 관련 내용은 "아파치 엑세스 로그를 엘라스틱서치에 인덱싱 해보자"에 정리했다. 전체적인 흐름을 그림으로 보자.

그림 4 좀 더 우아한(?) 방법

분석 결과를 한눈에

위에서 설정을 이용해서 수집한 액세스 로그가 Elasticsearch에 담겼으니 Kibana를 이용하여 시각적으로 나타내면 분석에 도움이 될 수 있다.

Logstash에 내장된 데이터베이스를 활용하여 IP 주소를 위치(geoip)로 변환해서 지도 및 그래프로 나타냈다. 그리고 URI를 그룹화하여 타입별로 시각화했다. 해외에는 서비스하고 있지 않기 때문에 국내 접속이 월등히 많고 그중 서울에서 접속을 가장 많이 한다는 것을 한눈에 볼 수 있다(해외 접속은 무차별적인 호출 또는 해킹 시도로 보인다).

그림 5 지도 및 그래프로 나타낸 접속 위치

또한 UA를 각 타입별로 그룹화할 수도 있다. PC보다 모바일 사용자가 더 많고, 그중 안드로이드 7.0에서 가장 많이 접속하는 것을 확인할 수 있다(이런 정보를 기반으로 비즈니스 모델을 타겟화할 수도 있겠다).

그림 6 그래프로 나타낸 UA 타입별 접속 수

마치며

여러 가지 방법을 사용하여 Apache 액세스 로그를 분석해 보았다. raw 상태의 데이터를 보는 것보다 유의미한 데이터로 가공하여 시각화하는 것이 데이터의 의미를 이해하는 데 도움이 되었다.

또한 결과를 도출하기 위해 백지 상태부터 개발하여 도구를 만드는 것도 좋은 방법일 수 있으나, 이 사례에서 Elastic Stack이라는 오픈소스를 활용했듯이 외부 오픈소스를 활용하는 것도 고려해볼 만하다고 생각한다.

백엔드 개발자의 진로

일의 범위

백엔드 개발자는 현업에서 실제 무슨 일을 하고 어떤 일을 할 수 있나요?

'백엔드 개발자'가 담당하는 일은 범위가 넓습니다. 사용자에게 보이는 웹 어플리케이션 개발뿐만 아니라 데이터 분석을 위한 엔지니어링, 분산파일시스템이나 DBMS와 같은 제품을 만드는 개발자들도 백엔드 개발자라 불리기도 합니다. '웹 프런트엔드 개발자', '모바일앱(iOS/Android) 개발자' 에 비하면 그 대상이나 하는 일이 상대적으로 모호합니다. 어플리케이션을 개발하는 백엔드 개발자는 프로젝트에 따라서는 서버관리, DB관리, 프런트엔드 개발까지 모두 담당하기도 합니다. 현대 야구가 발전하면서 선발/중간/마무리 투수가 구별된 것처럼 이전에는 백엔드 개발자가 다 하던 일이 분업화된 영역도 있습니다.

이렇듯 백엔드 개발자는 폭넓은 기술을 접할 수 있는 역할을 수행합니다. SE(System engineer), FE(Front End) 등 인접한 분야의 개발자와 소통할 기회가 많습니다. 그리고 접한 분야 중 한 분야에 대한 전문성을 키울 수 있는 기회를 만나기도 쉽습니다. 예를 들면 담당하는 서비스의 통계 모듈 개발로 시작해서 대용량 데이터를 다루는 데이터 엔지니어로 성장하는 경우입니다.

특화된 분야의 전문가로 성장하더라도 어플리케이션을 잘 개발하는 능력은 중요합니다. 다른 개발자가 사용하는 플랫폼이나 라이브러리의 개발도 어플리케이션 개발의 특성을 이해해야 적용하기가 편리한 인터페이스를 설계할 수 있습니다. 대용량 데이터 분석이나 처리를 담당하는 개발자라도 업무 효율화를 위해 모니터링, 관리 도구를 만들어야 할 때도 있습니다. 그래서 깊이 있는 전문분야와 함께 어플리케이션 개발 능력을 갖춘다면 더욱 유능한 개발자가 될 수 있습니다. 남은 질문에 대한 대답들은 백엔드 어플리케이션 개발 분야에 초점을 맞춰서 드리고자 합니다.

보람과 고충

백엔드 개발을 할 때 가장 어려운 점과 백엔드 개발을 하면서 느낀 매력은 무엇인가요?

개발 프로젝트 팀을 음악 밴드에 비유하자면, 인프라 담당자와 백엔드 개발자는 드럼이나 베이스 기타와, 프런트엔드 개발자는 보컬이나 퍼스트 기타와 비슷하게 느껴집니다. 무대에서 주목받고 찬사를 받기 쉬운 쪽은 보컬이지만 베이스와 드럼이 안정적으로 뒷받침하지 못하면 좋은 공연이 나올 수 없습니다.

백엔드 개발자는 시스템을 안정적이고 효율적으로 만들 때 보람을 느낍니다. 사용자가 갑자기 몰려와도 에러 없이 서버 프로그램이 실행될 때, 성능을 획기적으로 개선했을 때, 모듈의 구조를 개선해서 코드를 많이 줄였을 때가 그런 경우입니다. 문제가 생기지 않을 때에는 겉으로 잘 드러나지 않는 영역일 수도 있습니다. 내면적인 부분까지 완성도를 추구하는 사람이 백엔드 개발을 하기에 더욱 적합합니다.

서버 프로그램은 24시간 실행된다는 점이 백엔드 개발자들에게는 고충이기도 합니다. 긴급한 상황에 대비하기 위해서 노트북 컴퓨터를 항상 가지고 다니는 사람이 많습니다. 회식자리에서도 노트북을 켜고 장애 상황에 대응하는 경우도 있습니다. 그런 부담을 줄이기 위해서 규모가 큰 서비스에서는 당번(oncall)을 정해서 통상적인 휴식 시간대에는 돌아가면서 대응을 하기도 합니다.

향후 전망

다양한 도구와 프레임워크가 개발되고 있는 상황에서 백엔드 개발자의 미래는 어떻게 될지 백엔드 개발에 어떤 비전이 있다고 생각하시나요?

새로운 도구와 프레임워크로 인해 개발자의 수요나 가치가 하락하지 않을까 하는 우려도 있습니다. 하지만 현장에서 느껴지는 바로는 우리가 해야할 과제가 늘어가는 속도에 비하면 도구 등에 의한 생산성 증가 속도는 오히려 느리다고 느껴집니다. 새로운 시스템에 대한 수요와 유지 보수할 기존의 시스템도 늘어만 간다는 느낌입니다. 혁신에 투자할 수 있는 여력을 가진 사회라면 S/W개발자에 대한 투자는 계속 증가할 것이라고 전망합니다. 새로운 도구/프레임워크는 기존의 문제를 해결하고 개선하기 위해 나온 것입니다. 기존의 기술을 쓰면서 깊이 있는 고민을 한 사람이라면 새로운 도구에 더 빨리 적응하고 응용할 수 있을 것입니다. 따라서 새로운 도구와 프레임워크들도 기존의 개발자에게 더 큰 기회가 될 수도 있습니다.

다만 개발 분야에 따라서는 흥망성쇄가 엇갈릴 수도 있습니다. 예를 들면 이전에는 Flash기반의 UI개발에 대한 수요가 많았습니다. 하지만 HTML 내부에서 화려한 UI를 구현할 수 있도록 기술환경이 변화되면서 이전만큼 Flash 개발자를 찾지 않게 되었습니다. 모바일에서 Symbian OS를 바탕으로 개발을 했던 분들 익숙했던 개발플랫폼이 저물어가는 모습을 지켜봐야 했습니다.

지금까지는 개발자에 대한 수요가 계속 늘었기에, 개발분야를 바꿀 수 있는 기회도 많았습니다. 기존 기술을 깊이 있게 이해한 분들은 새로운 환경에서도 뛰어난 개발자로 정착하는 모습을 많이 봤습니다. Flash에서 사용하는 ActionScript를 잘 쓸 수 있었던 개발자들이 웹FE개발자로 전환하는 경우는 많습니다. Android 초창기에는 같은 Java 언어를 썼던 서버개발자보다 FE개발자 출신 분들이 훨씬 빠르게 적응한다는 이야기를 들었었습니다. UI에 대한 패턴, 프로그래밍 모델들은 기존에 FE 개발을 하신 분들에게 익숙한 것이었기 때문입니다.

기존에 있던 개발 분야들도 깊게 발전하면서 이전에 없던 전담자가 생기고 있습니다. 하지만 한번 맡은 분야를 끝까지 담당한다는 보장은 없습니다. 실무에서는 갑자기 새로운 업무가 필요해졌을 때 사람이 채용될 때까지 기다릴 수도 없습니다. 그래서 새로운 개발분야에 적응할 수 있는 역량은 키워두는 것이 좋습니다. 지금 하는 업무와 연관성이 있는 분야에 관심이 있다면 그런 준비가 자연스럽게 이루어질 수 있습니다.

백엔드 개발은 여러 분야와 연결되기에 그런 면에서 무난한 선택입니다. 포용하는 분야가 많고, 이론과 실무경험이 잘 조화될 수 있기 때문입니다. RDB, TCP/IP, OS, 통계 등의 바탕이 되는 지식들은 몇십 년 전부터 축적되면서 발전된 것들입니다. 그래서 실무에 들어가기 전에 학교에서부터 준비할 수 있는 지식이 많기도 합니다.

머신러닝이나 빅데이터 기술의 발달이 백엔드 개발에 어떤 영향을 미칠 것으로 예상되나요?

해당 분야들은 급격한 수요 증가로 인해 여러 방면으로 전문가를 수혈하고 있습니다. AI같은 분야는 학교에서 이론적으로 준비가 된 분들이 회사에 들어오는 경우가 많아 보입니다. 기존에 백엔드 개발을 하시던 분이 해당 서비스의 필요해 의해 해당 분야의 전문가로 성장한 경우도 있습니다. 예를 들어 어떤 서비스의 추천 모듈을 1~2명이 개발하다가 고도화를 위해 전담 팀을 따로 분리한 경우도 있습니다.

백엔드 개발을 하다가 데이터 분석, 모델링 업무에 참여하는 경우도 더 늘어날 것 같습니다. 이론적인 바탕이 튼튼하더라도 특정 분야에 의미있는 분석/모델링을 하기 위해서는 그 도메인을 이해하는 것이 중요합니다. 서비스를 개발하면서 사용자의 특성을 이해한 개발자가 이론적인 깊이까지 갖춘다면 가치가 더 높아질 수 있습니다.

직접적으로 분석/모델링을 수행하지 않더라도 많은 백엔드 개발자는 이를 뒷받침하는 개발을 하게 될 것입니다. 예를 들면 깊이 있는 데이터 분석을 위해서는 데이터를 단순히 RDB같은 하나의 저장소에 쌓아두는 것만으로는 부족합니다. 이전에는 그냥 버렸던 로그성 데이터들도 어떻게 활용할 수 있을지 분석하기 좋게 저장을 할지 고민을 더 하게 되었습니다. 데이터를 다른 저장소로 옮기는 일도 용량이 클 때는 쉬운 일이 아닙니다. 무엇보다 해당하는 서비스가 많은 사용자와 데이터를 받을 정도로 운영되어야 머신러닝 같은 고급기법으로 분석할 만큼 많은 데이터가 쌓일 것입니다. 넓게 보면 대용량의 서비스를 개발하는 백엔드 개발자는 AI/빅데이터와 시대의 과제와 맞닿아 있습니다.

다른 분야로의 확장

백엔드 개발이라는 포지션에서 다른 영역(경영, 기획 등)에 관여하는 게 현실적으로 가능한지

프로젝트에 따라서는 서비스/제품의 기획 단계에서 개발자의 의견이 많이 반영됩니다. 개발자가 사용하는 플랫폼을 만들 때에는 더욱 그러합니다. 개발업무를 개선하기 위해 만드는 자동화 도구들, 모니터링 도구들도 큰 방향성을 잡는 사람은 개발자일 수 밖에 없습니다. 비개발자들이 사용하는 서비스들도 최근 들어서도 개발자의 의견이 많이 반영되고 있다고 느낍니다. 특히 구체적인 데이터 구조를 고려하는 백엔드 개발자가 초기에 의견을 주면 효율적인 방향으로 기획이 이루어질 가능성이 높아집니다. 기획자, UX설계자 역할을 하시는 분들 중에서도 개발자 출신들이 있기도 합니다.

'경영'의 영역에 관여하는 것은 개발 조직에서 조직장이 하는 역할입니다. 어떤 일에 어느 정도의 투자를 하고, 사람을 얼마나 채용할지, 어떻게 보상을 할 건지가 모두 경영적인 판단이라고 할 수 있습니다. 개발자 중 일부는 그런 역할을 하는 사람이 될 수도 있습니다. 하지만 그런 일이 모든 사람의 적성에 맞는 일은 아닙니다. 조직장은 기술뿐만 아니라 사람 사이의 일에 관심을 깊이 가져야 잘 할 수 있는 일이라고 생각합니다. 뛰어난 개발자가 사람 사이의 문제를 잘 해결할 수 있으리라는 보장은 없습니다. 기술을 깊이 파고 널리 쓰이는 프로그램을 만들고 지식을 잘 전파하는 일에서 행복을 더 느끼는 개발자들이 더 많을 것 같습니다. 그런 일로도 긍정적인 영향력을 크게 미친다면 조직 내에서 중요한 존재로 대우받을 것입니다.

백엔드 개발에 필요한 지식

백엔드 개발을 하려면 어떤 지식이 중요하고 무엇을 기본적으로 알아야 할까요? 백엔드 개발 전문가는 어떤 언어, 툴, 주제를 공부하고 개발하나요? 프로젝트 스킬셋을 결정하는데 고려되는 부분들은 어떤 것들이 있나요?

백엔드 개발에서 중요하다고 생각되는 지식이 무엇인지에 대해서 많은 분들이 질문해 주셨습니다. 저는 주로 JVM과 Linux를 바탕으로 한 환경에서 서버 모듈 개발을 했습니다. 그래서 앞으로 이어지는 이야기에서 여러 기술 생태계를 다양하게 담지는 못했다는 점을 감안해 주셨으면 합니다. 웹 서버를 개발할 때는 아래와 같은 요소들이 우선 떠오릅니다.

• 웹 생태계의 스펙
  • HTML, HTTP(1.1 , HTTP/2)
• 기본 SDK, 라이브러리/프레임워크 이해와 활용
• 클라이언트를 위한 API 설계
• 서버/컴퍼넌트/객체 간의 역할 분담/의존성/통신 방법 설계
• 저장소 활용
  • DBMS 설계
  • Cache 적용
    • Global/Local cache 적용범위, 라이프 싸이클, 솔루션 선택
  • 파일 저장 정책/솔루션 선택 활용
• 검색엔진 연동 방식 결정
• 빌드 도구
  • Maven/Gradle
• 배포 전략
• 성능 테스트/프로파일링/튜닝
  • JVM 레벨의 튜닝 (GC 옵션 등)
    • 웹 서버(Nginx,Tomcat)등의 설정/튜닝
  • OS 설정의 주요 값 확인
• 인접 기술에 대한 이해
  • DBMS, Front End 등
• 서버 개발자에만 해당하지는 않는 항목
  • 테스트 코드 작성/리팩토링 기법
  • 버전 관리 전략
    • branch 정책 등

개발자 한 명이 위에 언급한 모든 요소를 깊이 잘 알아야 프로젝트에 참여할 수 있어야한다는 의미는 아닙니다. 팀을 이룬 개발자들의 지식들이 합쳐져서 구현 방식과 정책이 결정됩니다.

프로젝트의 스킬셋을 정할 때에도 보통 구성원 중 적어도 한명은 경험이 있는 기술들을 택합니다. 사용자가 많은 서비스라면 프로그램이 돌아가는 만드는 것만이 목적이 아니기 때문에 기술의 선택에 더 조심스러워집니다. 운영환경에서의 모니터링과 문제해결까지 팀 구성원이 할 수 있는 기술을 선택합니다. 내부의 소수만 사용하는 관리 도구를 만들 때는 상대적으로 부담 없이 팀원 모두가 처음 쓰는 기술을 적용하기도 합니다. 새로운 기술은 위험성이 적은 서비스에 적용해서 경험을 키운 이후에 큰 서비스에 적용을 합니다.

데이터베이스

데이터베이스를 어디까지 알아야하나요?? 데이터베이스를 어떻게 활용하는 것이 효율적인가요? 쿼리를 어떻게 만들고 튜닝해야할까요?

사용자의 요청량과 저장 용량이 많은 서비스에서는 하나의 저장소만을 쓰지는 않습니다. 네이버의 서비스에서도 MySQL, CUBRID, Redis, Memchaced, HBase, MonoDB, Elasticsearch 등 다양한 저장소를 활용하고 있습니다. 네이버와 라인에서 Arcus, Elasticsearch, Cassandra, Redis, HBase와 같은 다양한 저장소가 쓰인 사례는 아래 글을 참고하실 수 있습니다.

• Storm과 Elasticsearch Percolator를 이용한 NELO2 알람 기능 개선
• LINE 소셜 네트워크 서비스의 아키텍처 를 참고하실 수 있습니다.
• LINE 스토리지, 한달에 수십억 건의 데이터를 Redis와 HBase에 저장하다

다양한 저장소가 쓰이는 시대에도 RDB(관계형 데이터베이스)는 여전히 가장 우선시되는 저장소입니다. 그래서 RDB를 잘 다루는 능력은 백엔드 개발자의 핵심 역량 중 하나입니다. 개발을 하는 도중에도 쿼리의 호출 횟수나 실행 계획이 비효율적이지 않은지 확인하는 습관이 필요합니다. 운영 중에도 느린 쿼리를 모니터링하고 DBA와 협업하여 성능 개선을 하는 작업을 실무개발자들은 꾸준히 하고 있습니다. ORM같은 추상화된 프레임워크를 써서 직접 SQL을 작성하지 않는 경우에도 그런 작업들은 더욱 중요합니다.

대용량 서비스들을 보면 DB 쿼리를 만드는 스타일이 과거와는 달라졌습니다. 과거에는 서버 간의 네트워크 호출 비용을 줄이기 위해 굉장히 많은 테이블을 한번에 조인하는 긴 SQL을 만드는 경우가 많았습니다. 하지만 요즘은 복잡한 JOIN은 가급적 피하는 경향이 생겼습니다. 데이터를 조회하는 SQL이 단순할수록 데이터를 다른 저장소에 캐시하거나 분산해서 저장하기가 쉬워집니다. 대용량을 저장하는 UGC 서비스에서는 RDB 테이블 사이의 JOIN은 최대한 제약을 하고 어플리케이션 레벨에서 여러 저장소의 연관된 데이터를 조합하기도 합니다.

Stored prodecure도 가급적 사용하지 않는 경우가 많습니다. DB안에서 실행되는 Stored procedure는 급하게 개발된 서비스에서는 많이 사용되었습니다. 네트워크 호출비용이 없어서 성능에 이득이 있고, DB안에 저장되니 배포절차가 단순했기 때문입니다. 그러나 길게 작성된 Stored prodecure는 만들었던 사람도 수정하기 힘든 경우가 많습니다. 데이터와 독립적으로 로직을 테스트하기도 어렵습니다. 별다른 배포절차가 없으니 버전관리가 제대로 되지 않는 경우가 많았습니다. 그리고 데이터의 연산에 DB서버의 CPU 자원을 소모함으로서 서비스가 커가면서 DB에 병목이 될수 있는 가능성을 더 키울 수 있습니다. 이런 이유로 초기에 Stored procedure로 개발했던 로직을 어플리케이션 단으로 빼는 작업이 서비스가 성장하는 과정에서 흔하게 일어납니다.

DB서버 1대로 트래픽이나 저장량이 감당이 안 될 때, 이떻게 이를 분산할지도 항상 어려운 과제입니다. 성능 향상을 위해서 Local cache, Global cache를 동원하기도 합니다. 어느 정도 복제지연(Replication replay)이 그다지 민감하지 않은 서비스에서는 쓰기 작업은 Master 노드로, 읽기작업은 복제되는 Master의 데이터를 복제한 여러 대의 Slave로 DB를 구성하기도 합니다. 총 저장되는 용량이 많을 때에는 여러 개의 DB인스턴스에 이를 나누어서 저장하기도 합니다. 이를 샤딩이라고 부르는데 Sharding Platform에서 자세한 개념을 참조하실 수 있습니다. Spider, MySQL fabric와 같은 솔루션으로 샤딩을 할 수 있고 네이버 내부에서는 이런 용도로 자체 개발한 Nbase-T라는 저장플랫폼을 쓰고 있습니다. 샤딩의 기준이 되는 키가 명확하면 나누어서 저장하기가 상대적으로 쉽습니다. 개인화 서비스의 경우에는 사용자의 ID별로 샤드키를 잡으면 자연스럽습니다. 그런데 샤드키를 어떤 것으로 잡아야 할지 명확히 확신이 서지 않는 서비스가 있을 수 있고, 중간에 샤드키를 바꾸는 비용은 굉장히 큽니다. 어떤 솔루션을 쓰든 RDB는 사용량이 늘어났을 때 분산하는 비용이 비쌉니다. 그래서 성장할 가능성이 큰 서비스라면 RDB의 자원을 아껴서 쓸 필요가 있습니다.

개발툴

Jenkins, AWS 등 Backend에 도움이 되는 도구를 배웠지만 도구를 배운다는 게 과연 실력을 키우는 것인지는 의문입니다.

개발도구를 잘 활용하는 능력은 생산성과 직결되기에 중요합니다. 그런데 개발도구를 '배워야'하는 개발자보다는 스스로 익힐 수 있고, 적절한 도구를 선택할 수 있는 개발자가 현장에서는 필요합니다. 특정 개발도구를 익혔다는 사실은 단기적으로는 실력이라고 할 수 있습니다. 새로운 도구가 나왔을 때도 적응할 수 있는 학습력/적응력/판단력이 본질이고 이것이 누적되어 실력이 됩니다.

개인적으로는 아래와 같이 개발자의 수준을 분류하고 싶습니다.

• 레벨0: 이미 쓰고 있는 개발도구의 사용법을 알려주거나 가이드 문서를 줘도 잘 못 씀
• 레벨1: 알려주거나 같은 팀에서 만든 가이드 문서에 있는 만큼만 쓸 수 있음
• 레벨2
  • 개발도구의 공식 레퍼런스를 보고 사용법을 스스로 익힐 수 있음
  • 자신이 경험한 사용법을 문서화해서 팀 내에 전파할 수 있음
• 레벨3
  • 여러 개발도구를 비교 분석해서 상황에 적합한 도구를 선택할 수 있음
  • 공식 레퍼런스 문서에서 부족한 부분을 수정해서 기여할 수 있음
• 레벨4
  • 개발도구의 문제를 소스 코드를 수정해서 Fork/패치해서 사용할 수 있음

신입사원이라도 레벨2 정도는 함께 일할 개발자에게 기대를 하게 됩니다.

병렬처리

병렬처리를 어떻게 도입하면 좋은가요?

Servlet기반의 Java웹서버들은 기본적으로 사용자의 요청을 병렬적으로 처리합니다. 그래서 객체가 멀티스레드에서 공유되는 것인지, 아닌지를 의식하는 일은 중요합니다. 클래스의 멤버변수에는 항상 멀티스레드에서 접근해도 안전한(Thread-safe)한 변수만 두면 된다는 단순한 규칙만으로도 많은 문제를 예방할 수 있습니다. 그런데 Local cache를 적용할 때는 멀티스레드에서 공유된 객체가 쉽게 눈에 안 띌 수도 있습니다. 그래서 Cache대상의 객체는 Immutable하게 유지하는 것이 안전합니다. 직접 Cache 모듈을 만드는 경우 위험한 버그가 생기는 경우가 많습니다. 하나의 메모리 누수를 잡기까지 도 그런 사례입니다.

사용자 요청을 처리하는 스레드 외에도 별도의 스레드 풀로 실행해야 할 작업이 종종 생기기도 합니다. 예를 들면 사용자에게 주는 응답에 영향을 주지는 않지만 실행시간이 길어질 수도 있는 update 구문을 DB에 실행하는 작업같은 것입니다. 그런 경우 Java에서는 Executors, ThreadPoolExecutor에 있는 많은 옵션들이 정교한 제어를 하는데 도움이 됩니다. new Thread()로 직접 스레드를 생성하는 방식은 JDK5 이후로는 권장하지 않습니다.

보안

다양한 보안 위협 상황에 어떻게 대처해야 하나요?

널리 알려면 XSS, CSRF, SQL Injection 공격에 대해서 대처하는 방법은 모든 개발자가 알고 있어야 합니다. 실무에서 일하다보면 의존하는 라이브러리에서 발견된 보안 취약점에 대처한 경우가 많았습니다. 보통 버전업을 하거나 회사 내에서 자체적인 패치를 하기도 했습니다. 보안 취약점이 자주 발견되는 Struts2 같은 프레임웍들은 신경써서 대처하기 위해 주요 변경을 알리는 메일링 그룹에 가입하기도 했습니다.

테스트

테스트가 얼마나 중요하다고 생각하는지 궁금합니다. 실제 서비스에서는 테스트 코드를 어떻게, 어느 정도로 짜는가요?

많은 사람이 협업해서 개발하고 지속적으로 개선해나갈 소프트웨어라면 테스트 코드를 작성하는 일은 더욱 중요합니다. 테스트 코드를 작성하는 능력도 백엔드 개발자의 핵심역량 중 하나이기도 합니다. FE개발이 분업화되고 서비스간의 API 호출이 많아지면서 최근 백엔드 개발자의 업무는 API 서버 개발에 더 집중되고 있습니다. 따라서 최종적으로 UI와 통합하기 전에 개발한 API를 스스로 테스트해야 할 필요성이 더 커졌습니다. 오류를 있다는 제보를 다른 개발자로부터 받아서 수정 후 재배포하고 다시 알리는 비용은 스스로 오류를 발견했을 때보다 굉장히 크기 때문입니다. HTTP API에 대한 테스트는 작성하기도 쉽고 작성했을 때의 이득도 큽니다. 최근 진행 중인 프로젝트에서는 Rest-assured 와 Spring MVC Test Integration 을 이용해서 HTTP API를 통합 테스트 하고 있습니다. 라이브러리나 개발플랫폼을 개발하는 경우에도 테스트 코드는 중요합니다. 수천 대의 서버에 배포되는 라이브러리에서 사소한 수정을 해서 배포한 적이 있었는데, 최대한 모든 경로를 상상해서 테스트 코드를 작성할 수 밖에 없었습니다. 라이브러리 배포 후 이를 적용한 서비스에서 오류가 발생했을 경우 재배포하는 과정이 비용도 크고 신뢰를 잃게하는 요인이 되기 때문입니다.

'시간이 없어서 테스트를 못 만들었다’는 말은 '나는 테스트 코드를 만드는데 시간이 많이 걸린다’는 말과 동일합니다. 해당 언어에 대한 숙련도가 떨어지는 사람일수록 테스트 코드를 작성하는데 부담을 크게 느끼는 경우도 많이 봤습니다. 능숙해질수록 테스트 작성 시간은 줄어들어 테스트에 투자한 대비 이득이 커집니다. 가끔 테스트를 작성할 때 이 테스트 덕분에 어느 시점에 실제적인 이득이 있을지 나누어 생각할 때가 있습니다. 예를 들면 아래와 같습니다.

• 유지보수 기간의 생산성을 높여주고 새로 프로젝트에 투입될 사람에게도 이득을 주는 테스트
• 프로젝트 오픈 일정 직전까지의 코드 변경과 버그 발견에 도움을 주는 테스트
• 오늘 당장 프로그램을 목표한 곳까지 작성하는 일을 더 빨리 마치게 해주는 테스트

테스트 코드를 작성하다 보면 실제로 당장 할 일을 더 마치게 빠르게 해주는 테스트도 만나게 됩니다. 복잡하게 얽힌 프로그램을 개발할 때는 최종적인 UI를 통해서 수동으로 테스트하기 전에 부분적으로 잘라서 테스트하는 것이 버그를 쉽게, 빨리 잡는데 도움이 됩니다. 예를 들어 일주일 걸려서 만든 프로그램을 마지막 날에 한번에 테스트한다면 디버깅에 훨씬 시간이 많이 걸릴 것입니다. 몇 달 간 진행하는 프로젝트에서 단 한 줄의 테스트 코드도 안 짜는 분이 있다면 당신의 지금 능력으로도 그 방식이 오늘 일을 가장 빨리 마치는 방법이 아닐 것 같다고 말씀드리고 싶습니다. 그리고 테스트를 적극적으로 짜다보면 오늘 하루를 넘어서서 더 큰 이득을 주는 테스트를 만들어서 다른 사람의 생산성에도 긍정적인 영향을 미칠 수 있을 것입니다.

실제로 테스트로 인한 긍정적인 경험을 쌓아가다 보면 더 넓은 범위와 다양한 기법으로 테스트 코드를 작성하는데 동기유발이 됩니다. 제 개인적인 경험을 돌아보면, 점진적으로 테스트 코드를 작성하는 범위를 늘려가는 방식이 도움이 되었습니다. 처음에는 테스트가 쉬운 Utilty 클래스에 대한 테스트부터 작성했습니다. 전에도 간단한 유틸리티에 대한 테스트는 main메서드 안에서 하기도 했는데, 그런 코드를 JUnit 안으로 옮기니 반복해서 실행하고 결과를 확인하기에 훨씬 편해졌습니다. 그 이후에는 Spring framework의 통합테스트 기능을 이용한 테스트를 작성하기 시작했습니다. 특히 테스트 코드에서 DB에 입력한 데이터를 자동으로 롤백시키는 기능이 DB와 연동된 테스트를 할 때 유용했었습니다. 이후에 더 정교한 테스트를 하려다 보니 테스트용 객체를 만드는 프레임워크인 Mockito를 사용하게 되었습니다. 테스트 코드를 먼저 작성하는 기법도 사용할 수 있게 되었습니다. 저는 실무에서 테스트코드를 작성하기 시작한 후부터 6개월정도가 지나서야 Mockito와 같은 라이브러리의 필요성을 느끼게 되었었습니다. 처음으로 시도한 프레임워크는 EasyMock이었는데, 그 당시에는 프레임워크 제목처럼 전혀 Easy하게 느껴지지 않았습니다. 근래에는 프레임워크의 발달로 이전보다는 테스트 코드를 작성하기도 쉬운 구조로 모듈을 구성하기도 쉽고 테스트 코드 작성 자체도 훨씬 편해졌습니다. 따라서 이제는 대부분 제가 겪었던 단계적인 과정을 훨씬 더 빠르게 경험하실 수 있으실 것이라 예상합니다.

자료구조/알고리즘

학교에서 배운 알고리즘, 자료구조를 어떻게 실무에서 적용하나요? 실무에서는 기본적인 알고리즘을 직접 구현하지는 않습니다. 이미 기본적인 SDK나 많이 사용되는 라이브러리 솔루션에서 자주 쓰이는 자료구조, 알고리즘은 구현이 되어 있기 때문입니다. 하지만 그러한 이미 구현된 솔루션을 잘 선택하고 활용하기 위해서는 그 바탕이 되는 지식이 중요합니다.

JDK의 Collection framework의 소스를 볼 때에도 기본적인 자료구조에 대한 이해가 필요합니다. Java HashMap은 어떻게 동작하는가?와 같은 깊이 있는 분석도 그런 배경지식을 바탕으로 하고 있습니다. 대용량 데이터를 어떻게 저장하고 탐색할지를 결정할 때도 자료구조는 중요합니다. LINE 소셜 네트워크 서비스의 아키텍처, SSD는 소프트웨어 아키텍처를 어떻게 바꾸고 있는가? 의 기사에서 B-Tree, B+Tree를 어떻게 활용했는지도 참고할 수 있습니다. 이미지 처리처럼, 특화된 분야의 알고리즘이 실무에서 응용되는 경우도 있습니다. PHOLAR의 흔들림 보정 원리가 그 예입니다.

개발 프레임워크

백엔드 개발 프레임워크의 트렌드는 어떤가요?

제가 주로 관심을 가지는 JVM 생태계에서는 계속 Spring/Netty 기반의 프레임워크들이 꾸준한 발전을 하고 있다고 느껴집니다. 제 주변에 있는 여러 개발팀에서는 고부하 처리를 위한 서버에는 Netty를 바탕으로 UI개발과 직접 호출되는 API 서버나 HTML까지 그리는 서버 개발에는 Spring 계열이 많이 쓰이고 있습니다.

비동기 I/O를 활용하는 서버 개발이 최근 몇 년 동안 서버개발자들 사이에서는 많은 관심을 끌고 있습니다. Java 생태계에서는 보통의 웹어플리케이션을 개발하는데까지는 비동기방식의 개발이 확산되지는 못했습니다. 여러가지 이유가 있겠는데, 비동기 개발 자체가 가지는 진입장벽과 기술적인 난이도가 있기도 합니다. RDB를 호출하는 어플리케이션이 대부분인데 이를 뒷받침해야 할 비동기 JDBC 스펙의 구현체가 공식적으로 나오지 않은 탓도 있습니다. 최근 나온 Spring 5에서 비동기 IO개발을 지원하는 Webflux 모듈도 주목을 받고 있습니다.

모든 서버 어플리케이션이 비동기로 개발되어야 할 필요는 없다고 생각합니다. 그러나 트래픽이 많아서 동기/쓰레드 기반으로는 자원을 효율적으로 쓸 수 없는 시스템에서는 택할만한 선택지입니다. 네이버에서 고부하를 처리하는 플랫폼의 서버는 Netty/Vert.x 위에서 비동기 방식으로 개발된 것이 많습니다. 대용량 세션을 위한 로드밸런서 도 그 예입니다.

Serverless

Serverless 아키텍처에 대해 궁금합니다.

Serverless라는 용어가 자극적이기에 널리 퍼졌다는 생각도 듭니다. 주로 BaaS와 FaaS에 의존하는 아키텍처를 Severless라고 주로 부릅니다. AWS의 람다나 네이버 클래우드 플랫폼의 Cloud Functions에 Servleless 아키텍처를 지원하는 플랫폼입니다. 요즘은 그 의미를 더 넓게도 쓰고 있습니다. 폭넓게는 어플리케이션 코드를 작성하는 개발자가 서버관리를 신경쓰지 않는 구조나 역할분담을 해당 어플리케이션 입장에서는 'Serverless'라고 부르기도 합니다. 외부로 공유하는 글에 Serverless 라는 용어를 쓰게 된다면 마틴파울러의 블로그에 올라온 https://martinfowler.com/bliki/Serverless.html 와 같은 글을 읽어볼 만합니다.

Serverless와 같이 인프라 환경이 고도로 자동화/추상화된 환경에서는 이제 전통적인 어플리케이션에서 했던 JVM, 커널 파라미터, 웹 서버 튜닝이 이제 필수 지식이 아니라고 생각할 수도 있습니다. 그러나 인프라의 기반 구조를 잘 이해하면 추상화된 서비스도 잘 쓸 수 있게 될 여지도 있습니다. 네이버와 같은 회사에서는 내부적으로 BaaS, FaaS를 만들기도 하기 때문에 그런 프로젝트에 참여하는 개발자들에게는 최종 사용자 격인 개발자들보다 숨겨진 레이어에 대한 지식이 더 필요하기도 합니다.

실무에서 하는 고민

이 단락은 구체적인 질문은 없었더라도 실무에서 반복적으로 하는 고민들을 떠오르는 대로 정리해봤습니다.

용어의 범위

협업하는 사람들 사이에서 용어의 정의가 명확하지 않다면 갈등이 생기기 쉽습니다. 익숙하게 쓰고 있는 용어일지라도 그 정의에 대해서 한번도 찾아본 적이 없다면 원래의 의미를 잘못 이해했을 가능성이 높습니다. 책이나 인터넷 동영상에서도 정밀하지 못한 용어를 쓰는 경우가 꽤 많습니다. 때로는 용어의 정의 자체가 논쟁적인 경우도 있습니다. 그런 경우 어떤 논란이 있는지 이해를 한다면 그 용어를 피하거나 합의점을 찾아가는데 도움이 됩니다.

HTTP 프로토콜 위에서 JSON혹은 XML의 형식으로 통신하는 API를 폭넓게 REST API라고 부르는 경우가 많습니다. 그런데 현업에서 많은 이들이 REST라고 부르는 API들은 창시자인 Roy Fielding의 기준으로는 REST가 아닙니다. 대표적으로 상태가 Hyper link를 통해 전이되어야 한다는 HATEOAS를 대부분의 API를 충족시키지 않습니다. 이에 대해서는 그런 REST API로 괜찮은가를 참조하실 수 있습니다. REST API의 범위에 대한 논란을 피하고 싶다면 HTTP API 혹은 Web API라고 칭하는 것이 무난합니다.

테스트 코드를 작성하는 일을 통칭해서 TDD (Test Driven Develop)라고 부르는 사람도 있습니다. 이미 운영서버에서 잘 돌아가는 코드에 테스트 코드를 추가하면서 커밋로그에 'TDD 코드 추가'라고 적어놓은 경우도 본 적이 있습니다. 그러나 TDD의 개념을 정리한 Kent Beck이 'Test Driven Development: By Example' 책에서 보여준 기법은 테스트 작성, 테스트를 통과하는 코드 작성, 리팩토링의 싸이클을 거치는 것입니다. 테스트가 없던 레거시 코드의 버그를 고치거나 리팩토링 하기 전에 테스트를 추가하는 것도 TDD의 싸이클의 일부일 수도 있습니다. 그렇지 않은 경우에 뒤늦게 테스트를 추가하는 작업은 TDD라고 부르기보다는 '테스트 코드를 작성한다.'라는 표현이 무난합니다.

비슷하게 JUnit으로 작성하는 코드를 모두 '단위 테스트'라고 부르는 사람도 있습니다. JUnit의 이름으로 인해 생긴 오해입니다. JUnit으로는 다양한 범위의 테스트 코드를 작성할 수 있습니다. 예를 들면 스프링 프레임워크의 레퍼런스 메뉴얼에서도 단위 테스팅(Unit-testing)과 통합 테스팅(Integration-testing)이 구분되어 있습니다. 해당 메뉴얼의 단위 테스팅에 대한 설명에서는 아래와 같이 설명을 덧붙이고 있습니다.

진정한 단위 테스트는 실행시점에 구성되어야할 기반요소가 없기 때문에 대체로 굉장히 빠르게 실행된다. (True unit tests typically run extremely quickly, as there is no runtime infrastructure to set up.) https://docs.spring.io/spring/docs/current/spring-framework-reference/testing.html#unit-testing

Spring 레퍼런스 메뉴얼의 통합 테스팅 절에서 설명하는 기법들도 JUnit을 쓰고 있습니다. 이를 봐서도 JUnit으로 만든 테스트 코드를 모두 '단위 테스트’라고 칭하는 것은 정교하지 못한 분류이고, 혼동의 소지가 있습니다.

VO (Value Object)라는 패턴 이름도 실무에서 혼란스럽게 쓰이고 있습니다. getter/setter만 있는, 값을 실어나르는 VO라고 칭하는 사람이 있는데 이는 DTO로 칭하는 것이 혼란의 여지가 적습니다. Core J2EE Patterns 라는 책의 초판에서 그 의미로 VO가 정의되어 있었지만, 혼동의 여지가 있어서 2판부터는 TO(Transfer Object)로 바뀌었었습니다. 아래 자료들에서 VO와 TO의 정의를 확인할 수 있습니다.

• VO
  • http://martinfowler.com/bliki/ValueObject.html
  • https://en.wikipedia.org/wiki/Value_object
  • https://docs.microsoft.com/ko-kr/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/implement-value-objects
• TO
  • http://martinfowler.com/eaaCatalog/dataTransferObject.html
  • http://www.oracle.com/technetwork/java/transferobject-139757.html

위의 자료들에 따르면 Value Object는 값에 의해 동등성이 판단되는 객체입니다. Getter/Setter만 가진 객체를 VO라고 생각한다면 ORM이나 DDD(Domain Driven Development)의 맥락에서 나오는 VO 용어를 접할 때 혼란이 올 것입니다. Java의 스펙 제안 문서인 JEP 169: Value Objects에도 VO는 getter/setter만 가진 객체를 의미하지 않습니다.

이렇듯 새로운 용어를 접할 때 엄밀한 정의를 검색해 보는 습관을 들인다면 위의 사례들과 같은 혼란에 더 잘 대처할 수 있습니다. 그 용어를 만든 사람이 한국인이 아니라면, 영어 자료를 구글로 검색해보는 것을 추천합니다.

더불어 내가 속한 회사에만 쓰이는 용어와 업계에서 범용적으로 쓰이는 용어도 구분할 줄 알아야합니다. 특히 큰 회사에 다니시는 분들이 회사 내에서만 통용되는 어를 회사밖에서도 쓰는 경우가 종종 보입니다. 예를 들면 네이버에서는 품질향상을 위한 활동을 QP(Quality Practice)라는 용어로 칭했었습니다. 어떤 분들은 이 용어를 QA처럼 외부에서도 쓰이는 것으로 생각하고 사용하시는 경우를 봤었습니다.

클라이언트와 백엔드의 역할분담

이전에는 JSP와 같이 HTML를 서버사이드에서 생성하는 기술이 주로 쓰였습니다. 화면 전체를 다시 그릴 필요가 없는 요청은 Ajax로 처리했지만, 서버 렌더링에 보조적으로 쓰이는 경향이 강했습니다. 하지만 요즘은 React.js나 Vue.js와 같은 프레임워크가 널리 쓰이면서 클라이언트 사이드에서 HTML을 생성하는 비중이 높아지고 있습니다. https://d2.naver.com 도 React를 이용해서 전적으로 클라이언트 사이드인 웹브라우저에서 HTML을 그리고 있습니다. 선택지가 더 생김으로 인해서 어플리케이션이나 페이지의 특성에 따라서 어느 방식이 적합할지 이전보다 더 많이 고민하게 되었습니다. 사용자가 페이지에 처음에 진입할 때는 서버에서, 그 이후로는 클라이언트에서 HTML을 그리는 Universal Rendering도 최근 많이 시도되고 있습니다.

HTML 렌더링을 어디에서 할지는 개발자 간의 역할분담에도 영향을 미칩니다. 100% 클라이언트 사이드 렌더링을 하는 구조는 서버 개발자가 HTTP API 개발에만 전념할 수 있다는 장점이 있습니다. 반면 전문 Front End 개발자의 작업이 더 많아지는 부담도 생깁니다. 제가 속한 조직에서는 백엔드 개발자들도 React.js나 Vue.js를 이용한 UI개발자 참여함으로써 그런 단점을 보완하고 있습니다.

클라이언트를 위한 API 설계

앞서 언급한 REST 스타일의 일부를 차용하더라도 HTTP API의 설계의 많은 부분은 매번 프로젝트마다 고민해야할 점이 많습니다. 예를 들면 단순 CRUD(입력/조회/수정/삭제) API는 각각 POST/GET/PUT/DELELE의 HTTP 메서드로 연결시키더라도 이를 벗어난 기능들은 어떻게 설계해야할지 명확하지 않은 경우가 많습니다. 페이징 처리를 할 때나 복잡한 검색조건이 있을 때의 파라미터 표현방식에서도 서비스마다 다르게 정의하고 있습니다. 그리고 API에서 선택적으로 반환할 속성과 아닐 속성을 지정하는 방식도 다양합니다. 아래의 스펙들이 보다 구체적인 API 설계안들을 제안하기는 합니다. 그러나 아직 어떤 상세한 스펙이 지배적으로 많이 쓰이고 있지는 않은 상황입니다.

• Microsoft REST API Guidelines
• JSON API 스펙

클라이언트 사이드에서 UI 렌더링을 하는 경우가 늘어나면서도 HTTP API를 더 다양하고 정교하게 사용하고자 하는 필요성이 늘었습니다. 이러한 흐름 속에서 Facebook에서는 GraphQL을 내 놓았고, Github에서도 이를 도입하는 등 점점 확산되고 있는 추세입니다. 현시점에서 기존의 소위 REST 스타일과 유사한 틀에서 나름대로의 관례를 정립해서 최선을 추구할지, GraphQL을 도입할지도 고민되는 선택 중의 하나입니다.

시스템을 어떻게 자를것인가

시스템을 만들 때 많은 고민들은 결국 '구성요소 간의 역할과 책임을 어떻게 나눌 것인가'로 표현할 수 있습니다. 적게는 메서드, 클래스, 패키지 사이의 분담을, 크게는 jar로 배포되는 모듈이나 API로 통신을 하는 컴퍼넌트를 나누고 통신을 하는 방법을 고민을 하게 됩니다. 그리고 소프트웨어가 나누어진 경계에 맞추어 사람이 담당하는 업무의 범위나 협업 방식이 정해집니다. 그런 구조가 잘 잘라져 있어야 많은 사람들이 동시에 협업하면서 소프트웨어를 개발할 수 있습니다.

최근 MSA(Micro Service Architecture)라는 구조가 각광을 받으면서 서버에 배포 가능한 모듈의 단위를 이전보다 작게 가져가는 경향이 나타나고 있습니다. 많은 개발자가 동시에 협업하면서 개발하는데 MSA가 장점이 있기 떄문입니다. 이전에는 MSA와 같은 구조로 서비스를 만드는 것이 비용이 더 컸었습니다. 서버/네트워크를 더 많이 사용해야 하고, 서버/구성요소마다 설정하는 시간이 더 들어가고 문제가 생겼을 때 모니터링과 추적을 하는 것도 중간에 원격호출이 없을 때보다는 쉽지 않았습니다. 그러나 요즘에는 인프라시스템, 모니터링, 프레임워크의 발전으로 과거보다는 작게 단위로 서비스를 쪼개는 비용이 내려갔습니다. 그렇지만 서비스 간의 경계를 어떻게 잘라야 할지는 여전히 어려운 일이고, 적절히 잘라지지 않은 경계를 나중에 바꾸는 일도 비용이 큽니다.

네이버의 서비스들은 상호 연관되어 있고 다양한 조직의 많은 개발자들이 협업으로 만들고 있습니다. 네이버의 첫화면에 들어가는 구성요소만 해도 다양한 조직이 담당하는 모듈들을 거치고 있습니다. MSA라는 용어가 나오기 전이었지만, 그리고 최근의 경향보다는 서비스의 단위가 큰 경우가 많았겠지만 MSA가 이루고자 했던 장점들은 네이버에서 오랫동안 실용적으로 추구되어 왔다고 느껴집니다.

네이버의 백엔드 개발

개발,배포 방식

실무에서 어떻게 협업을 하고 개발, 배포를 하나요? 개발팀이나 프로젝트의 성격에 따라서 일하는 방식은 다양합니다. 제가 참여하는 프로젝트 중 하나의 예를 들면 아래와 같습니다.

• 주 1회 배포
  • 월요일 쯤에 회의로 이번 주 배포 범위를 확정. 목/금요일에 주로 배포
  • 치명적인 버그에 대한 Hot fix는 주1회 주기에 상관없이 배포
  • 최대한 무정지 배포
• 버전 관리/ 코드 리뷰
  • master에서 추가할 기능별로 feature branch(topic branch)를 따고 주로 master를 목표로 PR(pull request) 요청
  • Github의 마일스톤으로 버전을 입력하고 PR마다 매핑
  • 한번에 반영하기 힘든 기능이나 큰 단계의 버전업은 별도의 feature branch로 merge하기도 함
  • 리뷰를 충분히 받았는지는 PR을 올린 사람이 판단하여 merge
  • 배포일이 다가오는데 기능 오류가 없는 것으로 검증된 branch는 일단 merge후 사후 리뷰를 하기도 함
• DB 스키마 관리
  • 개발환경에서는 Liquibase 로 관리
  • 운영환경에는 Liquibase에서 생성된 SQL을 사내 스키마 관리 시스템을 통해서 요청
• 테스트
  • PR를 올리면 CI서버에서 빌드 실행. API 서버의 테스트 코드와 FE코드에 검사도구인 Eslint의 검증을 통과해야 merge 가능
  • 현재는 서버 모듈만 테스트 코드 작성
    • 통합 테스트: JUnit + Rest assured + (Spring MVC Test framework 또는 Embeded Tomat 활용) 이용
    • 단위 테스트: JUnit + Mockito 활용
    • 특별히 의식하지는 않았는데 Line coverage 는 74% 정도
  • Docker를 이용한 테스트 환경 활용
    • 마크업 등 UI변경을 확인해야 하는 경우는 PR에 'Docker build'라는 라벨을 붙임
    • 그러면 docker 이미지가 만들어져서 사내 docker 이미지 배포용 cluster에 해당 branch를 확인할 수 있도록 배포가 됨
    • docker로 배포된 서버에서 어느 정도 테스트 후 merge
  • 주1회 배포전 QA시간을 따로 잡고 개발팀 전체가 함께 테스트. (전담 QA가 없는 프로젝트인 경우)
  • 테스트 시나리오는 그 주 변경된 기능과 영향받는 기능 위주로 작성
  • 큰 기능 추가, 전체적인 코드 변경 시점에는
    • 스테이징 서버에서 1~2주 정도 개발팀이 미리 운영 데이터로 시스템을 써보기도 함
      • 전체 기능에 대한 테스트 시나리오를 다 수행해보기도 함

인프라 기술 활용

네이버에서 클라우드 컴퓨팅 기술(IaaS, PaaS, SaaS)을 어떻게 활용하고 있는지 알고 싶습니다. 네이버 서버 개발팀과 IT Operations팀 간의 소통 방식과 코드 배포 방법, 또 모니터링 툴들에 대해서 알고 싶습니다

네이버 내부에서 가상 서버(VM)를 관리하는 방식은 IaaS에 가깝습니다. 개발망에서는 특별한 결재없이 개발자 누구나 직접 가상서버(VM)를 생성할 수 있습니다. 운영망에서는 예산 승인 절차 등을 거쳐서 SE에게 요청해서 VM 서버를 생성합니다. 물리서버도 필요하다면 사용 신청을 할 수 있는데, 가상서버에 비해서는 신청 절차에 시간이 더 걸립니다. 최근에는 Docker container를 이용해 더 운영효율성을 높이려는 시도도 진행되고 있습니다. 이에 대해서는 아래 자료들을 참조하실 수 있습니다.

• Docker + Kubernetes를 이용한 빌드 서버 가상화 사례
• DEVIEW 2015의 Docker Orchestration 발표를 참고하실 수 있습니다.

사내에 많이 쓰이는 플랫폼은 조직마다 직접 설치하고 운영할 필요가 없도록 PaaS 형태로 제공되고 있습니다. 로그수집시스템 Nelo, 어플리케이션 성능 측정 도구인 Pinpoint, 성능테스트 도구인 nGrinder, 분산메모리 저장소인 NbaseARC이 그 대표적인 예입니다. 많이 쓰이는 오픈소스 솔루션도 PaaS화하여 운영하는 사례가 늘어가고 있습니다.

최종 사용자가 바로 서비스를 사용하는, 네이버 메일, 캘린더, 클라우드(NDrive) 등이 SaaS의 예라고 생각합니다. 네이버 내부의 IaaS/PaaS/SaaS 기술들은 Naver Cloud Platform ( https://www.ncloud.com/ )을 통해서 외부에도 제공되고 있습니다.

코드 배포는 내부적으로 만든 배포 솔루션을 사용하고 있고, 개발자 누구나 서버에 몇번의 클릭으로 서버에 배포할 수 있습니다. 개발 환경에서는 코드 Push나 Pull request가 올라오는 이벤트 등과 연결시켜서 자동으로 배포하기도 합니다. 운영환경에 배포하는 작업은 개발팀의 내/외부와 긴밀한 협의를 거쳐서 시점이 정해집니다. 배포 일정에 맞춰서 코드 리뷰, 소스 합치기, 테스트, 의존하는 다른 서비스에 공지하는 작업 등이 사전에 이뤄져야하기 때문입니다.

모니터링 도구는 여러가지를 복합적으로 사용하고 있습니다. 장비별 주요 자원 사용량, 네트워크, 어플리케이션 성능, 로그 수집 분석 등 모니터링 툴마다 특화된 영역이 다르기 때문입니다. 장애에 대한 모니터링을 하는 시스템은 빌드배포 시스템, 각종 모니터링 시스템과도 연동되어 있습니다.

네이버 내부에 정확히 'IT operation팀'이라는 용어는 쓰이고 있지는 않습니다. Nginx, Tomcat, JVM과 같은 솔루션의 설치와 설정 변경은 개발팀에서 직접하고 있습니다. 운영서버 VM의 생성, OS패치 등의 작업, 인프라 구성 등에 대한 컨설팅을 서비스마다 지정된 SE분들이 해주십니다. 개발DB의 설치와 스키마 변경은 개발팀에서 자율적으로 하고, 운영 DB에 대한 중요한 작업은 전담 DBA에게 요청합니다. 오랫동안 서비스를 개발,운영하면서 실용적인 프로세스가 정착되었다고 느껴집니다.

마치며

개발과 요리가 비슷한 면이 있다는 생각이 들 때가 있습니다. 몇 명이 먹을 요리를 정해진 레시피를 보고 혼자 만드는 일은 어렵지 않습니다. 그런데 많은 사람을 위한 음식을 여러 사람이 함께 준비하는 일은 차원이 다른 일입니다. 예전에 친척 분의 집에 방문했다가 샌드위치 500인분을 만드는 과정에 한두시간정도 참여한 적이 있습니다. 재료가 얼마나 필요할지 예측해서 구하고, 일하는 방식과 담당자를 정하고, 작업 시간을 계획하는 것 등 하나하나가 수월해 보이지 않았고, 그 중 하나만 어긋나도 샌드위치는 예상대로 만들어지지 않을 것 같았습니다. 그 일을 겪은 이후로 저는 큰 식당이나 결혼식 피로연에 갈 때마다 그 음식들을 준비하신 분들이 정말 대단하다고 느낍니다.

일단 실행은 되는 백엔드 프로그램을 만드는 일은 쉽습니다. 요즘은 특히 인터넷에 많은 재료와 레시피가 있기에 더욱 그러합니다. 그러나 협업하기에 좋은 방식으로, 성능과 안정성까지 고려한 백엔드 프로그램을 만드는 개발은 쉽지 않습니다. 그리고 모니터링과 데이터 수집,분석 등 사용자의 눈에 보이지 않는 영역들도 실무에서는 많은 비중을 차지합니다. 데이터나 사용자가 적었을 때에는 효율적이었던 구현 방식이 시스템이 성장하면서 문제의 근원지가 되기도 합니다.

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.