박종명의 아름다운 개발 since 2010.06

어제(2017.01.22) 기술사 111회 정기시험이 치뤄졌다.

1년전 이맘때 합격한 시험이라, 감회가 남달랐다.

같이 공부하던 조원 분들과 친한 지인이 이 시험을 치루는 날이여서 마음이 더 가는 하루였다.

정보분야 기술사가 특히 어려운 점이, 그 범위가 너무나 방대하다는 것이다.

또한 문제의 깊이 역시 무시못할 수준이다.

넓이와 깊이를 모두 섭렵하지 못한다면, 문제에 대응할 수 없는 시험이다.

어제 시험문제를 보니, 정말 양극화 현상이 눈에 띈다.

쉽고 어려운 문제가 극명하게 갈리는 현상.

쉬운 문제는 누가 더 차별화해서 채점자 프랜들리하게 적는지가 관건이고, 어려운 문제는 기본과 맥락을 얼마나 이해하고 문제를 푸는지가 관건일 것이다.

이렇게 어려운 시험을 준비하는 모든 기술사 수험생들에게 힘찬 응원을 보낸다~~~

* 111회 정보관리기술사 기출문제

<1교시>

<2교시>

<3교시>

<4교시>

간혹 헷갈리는 npm 옵션들.

각 명령어들의 상세한 옵션 등을 확인하려면 npm 문서 참조

https://docs.npmjs.com/cli/{명령어}

차차 추가하기로 함...

앞서 'SPA의 단점에 대한 단상'이라는 글에서 초기 구동속도 문제에 대해 다루었었다.

SPA의 초기 구동속도 문제를 완화하기 위해, 모듈을 청크단위로 분리해서 해당 모듈이 필요한 시점이 되었을 때 관련 리소스들이 다운로드 될 수 있도록 하는 Lazy Loading 기법을 사용할 수 있다.

Angular2에서는 모듈 단위로 컴포넌트와 서비스, 파이프 등 각종 구성요소들을 논리적으로 그룹화 시키고 해당 모듈단위로 Lazy Loading을 적용할 수 있는데, 이의 구현에 대해 알아본다.

1. 시나리오는 대략 이렇다

2. Angular 개발 환경은 다음과 같다.

참고로 부트스트랩 3.3.7도 사용.

3. 데모 프로젝트 디렉터리 구조는 다음과 같다.
앞서 시나리오와 같이 총 3개의 페이지를 위한 3개의 Angular 모듈 구성(one/two/three)

4. 각 모듈의 라우팅 구성은 다음과 같다.
1) 루트 라우팅 구성

2) 하위 모듈 라우팅 구성

5. 각 모듈 구성은 다음과 같다.
1) 루트 모듈

2) 하위 모듈 구성

컴포넌트 구성은 중요한 것이 아니라서, 생략하고 프로젝트를 빌드 한다

6. 청크(Chunk)단위 모듈 로딩 확인하기
1) 메인 페이지 요청
Angular 구동을 위한 번들 파일과 메인페이지의 리소스들을 다운로드 받는다.

2) 두번째 페이지 요청
두번째 페이지에서 사용하는 모듈이 번들링된 청크파일과 리소스만 로딩

3) 세번째 페이지 요청
세번째 페이지에서 사용하는 모듈이 번들링된 청크파일과 리소스만 로딩

이제 모든 리소스가 다운로드 되었고, 이후부터는 해당 페이지들을 다시 방문해도 (비동기 통신 데이터를 제외하고는) 이미 다운로드 된 리소스들을 사용해서 반응성이 빨라지게 된다.

추가로 이 데모에서는 초기 페이지의 컴포넌트 재생성을 방지하기 위해 사용자 정의 RouteReuseStrategy를 적용해서 매번 컴포넌트 생성을 하지 않게끔(싱글톤) 하였다.

아래 이미지를 확인해 보면, 세 개의 페이지를 왔다갔다 할 때 첫번째 페이지의 컴포넌트의 경우 더 이상 객체를 생성하지 않는 것을 알 수 있다.(해당 로그는 객체의 생성자에서 기록하도록 했음)

모바일 시대로 접어들면서 웹 환경에도 많은 변화가 동반되었다.

그 중 SPA(Single Page Application)도 단단히 한몫을 차지하고 있는데, 항간에 들리는 SPA의 단점들을 나열해 보면 크게 세 가지로 압축되는 듯 하다.

1. 초기 구동 속도

2. 검색엔진 최적화(SEO)

3. 보안

4. IE 8 이하 지원 (추가)

사실 이것들은 SPA의 단점이라기 보다는, SPA 구조이기에 당연히 생길수 밖에 없는 상황으로 이해되어야 한다.

모든 소프트웨어 아키텍처 전략에는 트레이드 오프(Trade-off)가 존재한다. 흔히 '은탄환'은 없다는 말처럼, SPA가 모든 웹 애플리케이션에 가장 적합한 구조는 아니다.

SPA를 직역하면 '단일 페이지 어플리케이션'으로, 기존의 전통적인 새로고침 방식의 웹과는 달리 필요한 정적파일을 한번에(나눠서도 가능하다) 모두 다운로드 받고, 이후 사용자와의 상호작용 가운데 필요한 데이터만 서버로부터 (비동기로) 동적으로 받게하여 트래픽의 총량을 줄이고, 네이티브 앱과 유사한 사용자 경험을 제공할 수 있는 어플리케이션 형태이다.

결국 SPA가 추구하는 핵심적인 가치는 웹의 (사용자 경험을 향상시키는, UX) 사용성이라 할 수 있으며 부가적으로 속도의 향상도 얻게 된다.(물론 속도에 큰 틀에서 보면 사용성에 포함시킬 수 있다.)

특히 모바일 환경에서는 트래픽 최소화와 속도 및 반응성, 사용성 등이 보다 중요한 이슈이므로 SPA 구조는 모바일 퍼스트(Mobile First) 전략에서는 거의 모범사례에 가까운 모델이라 할 수 있다.

최근 App-like, Naively Web을 지향하는 구글의 PWA(Progressive Web App) 역시 모바일 환경에서의 웹의 사용성을 향상시키는 일환으로 대두되고 있다. PWA가 SPA를 직접적으로 포함하는 개념은 아니지만 비동기 통신과 SPA 구조는 PWA와 궁합이 잘 맞는 선택이다. 개인적으로 SPA도 PWA와 같은 선상에서 이해되기를 바라는 마음이다.

위에서 언급한 SPA 단점(?)이란 것들도, 가만히 들여다 보면 SPA가 추구하는 사상에서 파생되는 당연한 특징들에 가까우며, 저런 단점들 때문에 SPA 적용에 대해 큰 의문이 든다면, 그것은 SPA 자체의 문제가 아니라 현재 어플리케이션이 SPA모델과는 어울리지 않을 가능성이 더 높다.

다시 말하지만, SPA가 모든 상황에 있어 최고의 아키텍처 전략이 아니라, SPA가 어울리는 곳에 사용했을 때만이 최적의 효과와 효율을 발휘할 수 있을 것이다.

위에서 언급한 SPA의 문제(문제라고 해 두자)들을 하나씩 살펴보자.

1. 초기 구동속도 문제
평소 우리는 많은 모바일 '네이티브 앱'을 사용한다. 당신의 스마트폰에 깔려 있는 많은 앱들을 생각해보라. 이 앱들을 사용하는 우리의 자세(?)를 돌이켜보자.

먼저 앱스토어에서 수메가(mb)에 달하는 앱을, 몇 초에 걸쳐 다운로드 받는다. 그리고 또다시 몇 초의 시간을 설치하는데 할애한다. 아직 끝이 아니다. 설치한 앱을 처음 띄울때 초기 구동을 위한 각종 설정과 초기화 작업을 기다리며 앱 초기배너 혹은 광고배너를 무심히 바라본다.

드디어 앱이 실행되면 그때부터는 큰 기다림 없이 앱을 사용한다. 물론 이제부터는 빠른 응답과 높은 반응성을 만끽(?)하면서 말이다.

(또한 설치된 앱을 종료하고 다시 실행할 때도 약간의 시간을 감수해야 한다.)

이제 SPA로 돌아와보자. SPA 역시 모바일 네이티브 앱과 같은 효과를 웹에서 제공해 주고자 한다.
즉 앱의 사용성을 추구하고자 SPA에서도 초기에 필요한 대부분의 리소스를 다운로드 받는다. 물론 이것은 초기 구동속도를 조금 손해보고 더 많은 가치(전체적인 앱의 속도/반응성/사용성 등)를 추구하기 위함이다.

우리는 모바일 앱(극단적인 예로 모바일 게임을 떠올려 보자)을 사용하면서 초기 구동속도가 치명적인 단점이라고 생각하지 않는다. 오히려 다운로드와 설치과정 및 앱 초기 구동을 위한 약간의 시간들을 오히려 자연스럽게 받아들인다.

SPA 사상도 이와 유사하기에 초기 구동속도가 치명적인 단점이라고 언급되는 것은 곤란하다고 강조하고 싶다.

SPA의 사상은, 더 이상 웹이 단순한 웹 문서(웹 페이지)가 아닌 하나의 응용프로그램으로 바라보기에 개념의 전환이 필요한 것이다.

물론 그럼에도 불구하고 SPA도 (여전히) 웹 이기에 기존 웹의 경험을 무시할 수 없는 측면도 있을 것이다.

이런 조건 말이다. "SPA가 좋은건 알겠는데... 메인 페이지는 무조건 빨리 떠야 합니다."

SPA에서도 이런 상황에 대한 기술적 대안을 마련할 수 있다.
초기 페이지에서 모든 리소스를 다운받지 않고, 리소스를 청크(Chunk) 단위로 묶어서 해당 리소스에 대한 요청이 있을 때만 다운로드 받도록 하는 방법을 적용하면 초기 구동속도 문제를 많이 완화시킬 수 있다.

많은 자바스크립트 모듈 번들러에서 Lazy Loading 혹은 비동기 모듈로딩이라는 이름으로 이런 시나리오를 지원하며, 우리의 훌륭한 Angular에서도 모듈단위로 구성요소를 묶고 청크단위로 다운로드 받게 할 수 있다.

심지어 SPA에 PWA를 조합하면 보다 뛰어난 사용성을 부가적으로 제공할 수도 있다. 초기 구동에 필요한 필수적 파일을 웹쉘로 구성하고 백그라운드에서 서비스워커를 통해 비동기 리소스 탐방(?)을 실현할 수 있다.

다시 강조하지만, SPA에서 초기 구동속도는 더 이상 결정적인 단점으로 논해져서는 안된다.
오히려 현재 적용하려는 웹 사이트가 SPA 사상과 맞지 않는 것이 아닌가 살펴보기 바란다.

2. 검색엔진 최적화(SEO) 문제
SEO는 서버랜더링 방식이 아닌 자바스크립트 기반 비동기 연동 모델(클라이언트 랜더링 방식)에서는 항상 이슈가 되어 왔던 주제이다. SPA로 가면서 극단적(?) 자바스크립트 기반 웹이 되다 보니 그 문제가 더욱 부각되는 것이다. 구글 크롬 브라우저는 최신 웹 트랜드를 반영해서 자사의 검색엔진에서 클라이언트 래더링 방식도 검색 봇(Bot)이 컨텐츠를 가져갈 수 있도록 개선하고 있지만 기타 다른 브라우저에서는 그 방향성이 불투명하다.

그러나 이 문제 역시 비슷한 맥락에서 말할 수 있다.

다시 말하지만, SPA로 구현된 웹은 더 이상 단순한 정보제공을 위한 웹 문서(페이지)가 아니다.
SPA 결과물을 하나의 응용프로그램으로 본다면 기존 웹 페이지의 정보제공이란 측면의 SEO가 맞지 않을 수도 있다는 것이다.

생각해 보자. 모바일 네이티브 앱을 만들면서 SEO를 걱정하는 이는 드물 것이다.
(다시 극단적인 예로, 모바일 게임을 만들면서 SEO가 안된다고 걱정하는 것을 상상해보라)

SPA를 적용하면서도 개념은 여전히 웹 페이지에 머물러 있다면 둘 중 하나일 것이다.

SPA 사상을 이해하지 못했거나 해당 프로젝트가 SPA와 어울리지 않거나!

(다시한번) 그럼에도 불구하고 SPA도 웹이기에 SEO가 되어야 한다면 역시 대안 기술이 존재한다.

prerender.io 같은 상용 솔루션도 존재하고, Angular나 React같은 SPA 프레임워크에서도 서버 랜더링이라는 이름으로 SEO에 대응하고 있다.  

Angular의 경우 Angular Universal 이라는 SEO 대응 기술이 이미 존재한다.
아직까지 Node.js나 ASP.NET 서버 환경에서만 서버 랜더링을 지원하지만 향후 다른 서버플랫폼도 지원을 계속 추가해 나갈 것이며, 중요한 것은 SPA로 구현된 모든 페이지가 SEO가 되어야 하는 것은 아닐 것이다.

따라서 SEO에 노출되어야 하는 전략적인 페이지들을 선별해서 서버랜더링 기술을 적용하면 될 것이다.

3. 보안문제
SPA의 보안문제로 자주 언급되는 것이 사용자 정보가, 기존 서버기반 세션이 아닌 클라이언트 기반 쿠키라는 것이다. 

그런데 세션은 쿠키 아닌가? 세선도 클라이언트에는 쿠키형태로 저장되고 모든 요청의 헤더에 그 값이 전달된다. 단지 쿠키와 다른점은 서버측에도 클라이언트 쿠키와 매핑되는 세션정보가 저장되어 있다는 것만 다를 뿐 이다.

보안관점에서 보면 쿠키의 가장 큰 문제는 '도용'이다. 쿠키 정보의 기밀성이나 변조는 쉽게 방어할 수 있지만 누군가의 쿠키를 그대로 복사해서 재사용하는 것은 조금더 높은 방어기술을 요구한다.

그런데 이런 쿠키도용은 서버세션이라는 시나리오에서도 동일하게 적용된다. 물론 서버측에 세션만료시간내에 도용해야 한다는 제약이 존재하지만, 요즘 쿠키는 대부분 브라우저 쿠키로 영구적으로 저장하지 않으니 별반 차이가 없다고 보는 것이 맞다.

따라서 사용자 정보저장이라는 측면에서는 SPA의 쿠키나, 기존 서버랜더링 방식의 세션이나 별반 다를 것이 없다. 그리고 요즘 왠만한데는 쿠키 잘 쓰지도 않는다.

SPA의 보안이라는 측면에서 더욱 심각한 것은 핵심로직이 자바스크립트로 구현된다는 점이다.

기존에는 대부분의 비즈니스 로직이 서버에서 수행되어 최종 결과만을 (HTML 덩어리로) 전달받았을 뿐인데, SPA에서는 필요한 데이터만 전달받고 많은 비즈니스 기능을 클라이언트에서 수행하기 때문에 핵심 로직이 노출될 수 있다는 점이 문제라면 문제일 것이다.

따라서 SPA 보안문제를 언급하려면 이 관점에서 풀어나가야 한다.

이것은 별다른 방법이 없다.
핵심로직은 서버에서 수행하도록 하고 중요한 유효성 검사는 양측 모두에서 수행하도록 해야 한다.

유효성 검사의 양측 모두 구현은, 굳이 SPA가 아니더라도 기존방식에서도 그렇게 해 왔었고 해야 되는 것이었다. SPA라서 더욱 신경써야 할 포인트는 바로 클라이언트에서 수행되는 핵심로직을 최소화시키는 것이다.

자바스크립트 난독화만으로 해결될 문제가 아니기에 설계시 고민해야 하는 부분이다.
실제로 게임 어플리케이션을 만들 때 이런 고민을 한다.

4. IE 8 이하 지원
SPA가 비단 Angular, ReactJS로만 만들 수 있는 것은 아니지만, 진정한 SPA 다운 결과물을 만들기 위해서는 이런 프레임워크의 도움이 절실하다. 
그리고 이런 최신의 자바스크립트 프레임워크들은 IE8을 지원대상에서 제외하고 있는 추세이다.
따라서 SPA를 진정 원한다면 IE8 이하를 과감히 버리는 것을 고려해야 한다.

그렇게 하지 못한다면, IE8용 대안을 별도로 마련해야 하는데 대국민 서비스에 규모가 큰 조직이라면 해 볼만 하다. 그러나 서비스 특징과 비용 효율 측면을 따져보고 결정할 일이다.

-----------------------------------------------------------------

하나를 얻으면 하나를 잃게 되는 것이 세상사가 아닌가 한다.

SPA로 얻는 가치가 있다면 SPA로 잃는 가치도 있을 것이다. 그런데 SPA에서 언급되는 저러한 단점들이 과연 단점이라 할 수 있는지 의문이 든다. 

심지어 SPA의 특징으로 인해 부각되는 몇 가지 문제상황들은 대안 기술로 해결될 수 있는 부분이 많다.

결론을 내리자.
SPA 자체를 보지 말고, 현재 수행하는 프로젝트의 특성을 먼저 살펴보기 바란다.
지금 개발하려는 애플리케이션이 SPA의 사상과 일치하는지 말이다.

당신의 프로젝트에 SPA를 적용하지 않는다고 해서 SPA가 서운해 하거나 하지는 않을 것이다.

Webpack을 사용한 비동기 번들 로딩.

관심사의 분리/분할과 정복 등의 기본 원리를 바탕으로 잘 나눠진 모듈로 분리된 자바스크립트 파일을 만들고..

배포할때는 웹팩으로 단 하나의 번들 파일로 배포해서 사용하는 좋은 시나리오에서...

어떤 경우에는 이런 방식이 부담되기도 하는데, 예를 들어 (필요는 하지만) 굳이 미리 다운로드 받지 않아도 되는 즉 필요할 때만 다운로드 받게 하고 싶은 경우가 있다.

이때 사용할 수 있는 것이 비동기 번들 로딩

내부적으로 번들파일이 나눠지고 해당 스크립트를 사용하게 되면 그때 관련된 번들파일이 다운로드 되게해서 초기 로딩 속도를 향상시키고 사용자의 행동에 따라 추가 스크립트를 제공해 주는 Lazy Loading 기법이라 할 수 있다.

* 비동기 번들 로딩 구현

1) 먼저 필요한 것들 설치
- webpack 환경(npm, webpack, babel-load, babel-core 등등 필요한 것)

2) webpack 설정파일(옵션)

3) 스크리트 작성 및 html 작성

4) 빌드
웹펙으로 빌드하면 다음과 같이 두 개의 번들 파일이 생성됨

브라우저에서 실행을 해 보면, 처음에는 index.html과 bundle.js 파일만 다운로드 받고, 버튼을 클릭하면 그때 1.bundle.js 파일을 다운받게 된다

처음 로딩 시

버튼 클릭 후

이제 중요한 것은 모듈을 어떻게 나누고, 비동기 로딩의 대상과 시점을 어떻게 하느냐.. 하는 전략.

샘플 수행의 거의 모든 소스는 다음 사이트를 참조함
(내 환경에서 버그가 나서 아주 미미한 수정을 가했으며 문구도 내 입맛에 맞게 맘대로 바꿈 ^^;)
=> http://jilles.me/webpack-async-bundle-loading/

Webpack 제공 기능 정리.

자바스크립트 개발과 관리...

대규모 복잡한 자바스크립트 개발 환경에서는 무지 편해지고 추가 이득이 수루룩... 

But, 소규모 단순한 자바스크립트 개발에서는 괜한 복잡성 증가...

삽으로 파야할 땅인지 포크레인으로 파야할 땅인지 부터 보고 결정.

요즘 대부분 포크레인이 요구되기는 함.

자신의 삶에서 어떤 것이 진정으로 값진 것인지 그는 알고 있었다.

남다른 사람의 사고 방식은 역시 남다르다.

궁극적 인생의 행복은 한 순간의 부와 명예보다는, 보장되지 않은 것일지라도 도전하며 개척해 나가는 과정에 있지 않을까 한다.

"80세가 되었을 때, 서른 살에 거액의 인센티브를 받지 못한 것을 아쉬워할까? 그렇지 않을 것이다. 도전하지 않으면 분명히 후회한다. 그것은 부인할 수 없는 사실이다."

> http://www.ttimes.co.kr/view.html?no=2017072816067752817 

"아는 것이 힘이다"라는 말이 있는 반면, "모르는 게 약이다"라는 말도 있다.

두 속담이 모두 맞는 말이지만 생활의 이런저런 상황을 겪다 보면 아는 것이 독이 되는 경우를 자주 접하게 된다.

개인적인 생각으로,

첫번째 케이스는 많이들 알고 있듯이, 알아서 독이 되는 대표적인 케이스로  '반풍수 집안 망친다! or 선무당 사람 잡는다!'라는 속담이 내포하는 경우이다.

아예 모르면, (자신의 부족함을 알기에) 알려고 노력하고 상대의 의견을 경청하고 존중하려 한다.
하지만 조금 아는 경우에는 자칫 어설픈 지식과 편협한 경험만으로 주어진 상황을 재단하려 드는 나쁜 습관에 빠지기 쉽다.

두번째 케이스는 일반적으로 잘 회자되는 것은 아니지만, 간혹 접하게 된다.

이 경우 많이 알아서 다른 상황에서 도움이 되기는 하지만, 자신이 모든 것을 알고 있다는.. 또는 알고 있어야 한다는... 부담감에 무리수를 두게 된다. 자신이 모든 것을 예측할 수 있고 통제할 수 있다는 심각한 착각은 결국 독단과 아집의 끝을 보여주기도 한다.

첫번째 케이스는 학습의 문제로 다룰 수 있을 것이다. 좀 더 알고 경험하고 하다보면 저절로 깨닫게 되는 경우가 많다.

그러나 두번째 경우는 인성의 문제로 단순히 지식과 경험을 더 쌓은 것으로 고치지 못할 가능성이 높다.독단과 아집으로 발전해 버린 이상 쉽게 정신을 차리지 못하게 되는 것이다. 그래서 더 위험하다고 보는 것이다.

안다는 것에서, 두 가지 모두를 경계하며 살기로... 경계를 늦추지 말기로 한다.

"무지는 지식보다 더 확신을 가지게 한다" - 찰스 다윈

"이 시대의 아픔 중 하나는 자신감이 있는 사람은 무지한데, 상상력과 이해력이 있는 사람은 의심하고 주저한다는 것이다" - 버트란드 러셀

좋은 글) 더닝 크루거 효과(Dunning-Kruger Effect)

멋진 팀과 더 멋진 팀 구성원들!!!
앞으로 많이 배우겠습니다 ^^.

조만간 Front-end 개발 프레임워크를 선정해야 될 지도 모르겠다.

몇 년 전부터 AngularJS가 핫 트랜드로 떠오르면서, 진보적 프로젝트에서 많이 도입되어 왔다.

지금의 선택지는 AngularJS 버전 2의 릴리즈로 하나 더 늘어난 셈이다.

우리의 프로젝트에 AngularJS 버전 2를 도입을 고려한다면 다음과 같은 품질속성 관점의 접근이 일종의 명분이 될 수 있을 것이다.

성능

Angular2에서 성능 관점의 어프로치는 크게 두 가지로 속도와 용량부분이다.

AoT 컴파일(ahead of time compilation)
요즘 AoT 컴파일이 성능향상의 주요 컨셉으로 도입되는 추세다. 얼마전 안드로이드에서도 이와 유사한 컨셉이 도입되어 앱의 실행 성능을 향상시켜 왔는데, Angular2에서도 도입되었다.
AoT는 사전에 미리 컴파일 해 둔다는 개념으로, 기존 AngualrJS의 ng-** 따위의 해석을 위한 런타임의 컴파일 과정을 미리 해 둬서 실행 속도를 향상시키는 기법이다.

또한 이러한 AoT컴파일 덕분에 런타임시 필요했던 JIT(just-in-time compiler)를 더 이상 적재하지 않아도 되기 때문에 용량부분에서도 이점을 가져다 준다.(JIT 컴파일러는 기존 AngularJS 라이브러리 용량의 50%가까이 차지하던 녀석이다)

Lazy Loading
지연(Lazy) 바인딩, 지연 로딩 등의 개념도 다른 많은 언어들에서 차용하고 있는 최적화 기법이다.
지연(Lazy)이라는 개념은 최대한 필요한 시점까지 지연시킨다는 개념으로 불필요한 리소스 낭비를 막자는 컨셉이다. Angular2의 지연 로딩은 어플리케이션 실행 시점에 모든 모듈을 로딩하지 않고 현재 페이지에 실제로 필요한 모듈만 로딩함으로써 최적화를 시키는 기법이다. 역시 모든 내용을 처음부터 로딩하지 않게 함으로써 속도와 불필요한 리소스 낭비를 막을 수 있게 된다.

Digest Loop로 인한 성능저하 제거
이전 버전의 AngularJS에서 대표적으로 성능 문제로 지적되었던 Digest Loop로 인한 성능저하가 AngularJS에서는 더 이상 발생하지 않는다. 

코드 최적화
Angular2 자체의 코드 최적화도 수행되어 50KB 정도의 용량 축소가 되었다고 한다.

생산성

컴포넌트 중심 개발
기존 AngularJS는 컨트롤러 중심으로 개발이 진해되었던 것에 반해 Angular2에서는 컴포넌트 중심으로 개발이 진행된다. 오래된 SW 공학 예기지만, CBD(Component Based Developement)의 생산성 향상을 꾀할 수 있을 것이다. 물론 컴포넌트 설계가 잘 되었다는 가정하에..

TypeScript
AngularJS2에서는 MS(Microsoft)에서 개발한 자바스크립트를 위한 타입 명시적 스크립트 언어인 TypeScript를 주력 언어로 채택했다. TypeScript는 자바스크립트의 슈퍼 셋(Super Set)으로 자바스크립트의 문법을 그대로 이용 가능하며 명시적 타입 지정이 가능하도록 하여 타입 안정성을 향상시키고 ECMA Script 버전 7까지의 표준 스크립트 문법을 지원한다.

개인적으로 MS가 모바일 시대에 미미하게나마(?) 선전한 걸작으로 평가하고 싶다.
TypeScript로 개발하면 타입 안정적인 상황에서 객체 지향적 프로그래밍이 가능하고 원하는 버전의 자바스크립트 버전으로 변환이 가능해 생산성 향상을 꾀할 수 있다.

Learning Curve
생산성 향상은 마치 양날의 검과 같다. 컴포넌트 중심 개발, TypeScript라는 새로은 언어 등이 무조건 생산성 향상을 가져다 주지는 않는다. 컴포넌트는 해당 프로젝트와 도메인에 맞도록 컴포넌트 단위가 잘 분리되고 조립되어야 하며 TypeScript 역시 자바스크립트 기반이라고는 하지만 적절한 러닝커브가 존재한다. 즉 초기에 약간의 투자를 한다면 점차 그 혜택은 커질 것이다.

Mobile First
Angular2는 모바일 환경을 목표로 만들어진 고성능 프레임워크를 표방한다.
앞서 살펴본, 속도와 용량 최적화는 모바일 환경에서 보다 중요한 특성으로 어필될 것이며 생산성은 대규모 프로젝트에 많은 이점을 가져다 줄 것이다.

소프트웨어 위기(Software Crisis)라는 용어가 등장한지 50년 가까이 되었음에도 여전히 그 위기속에 생명을 유지하고 있는 소프트웨어가 간혹 발견된다.

이런 문제를 몇몇 자질이 낮은 개발자의 문제로 치부하는 경향도 발견되는데, 이는 문제의 본질을 흐리게 하고 근본원인의 해결을 할 수 없게 만드는 좋지 못한 접근법이다.

소프트웨어 위기에 내포된 문제점은 결국 돈과 시간, 만족도의 문제이다.

계획된 납기를 준수하지 못한채 예정된 예산보다 더 많은 돈을 지출하고도 불만족스러운 소프트웨어를 사용하게 되는 것이다.

소프트웨어 위기는 소프트웨어 개발에서의 공학적 접근의 필요성과 중요성을 강조하는 계기가 되었는데, 소프트웨어 공학의 목표라는 것이 결국에는 '한정된 자원(돈, 시간)으로 사용자가 만족하는 고품질의 소프트웨어를 생산하는 것'이란 점에서 돈과 시간, 만족도에 대한 문제해결의 접근법이라 할 수 있다.

각종 공학적 기법과 방법론, 관리체계를 기반으로 표준화를 통한 일관성과 호환성을 확보하고 자동화 툴을 사용하여 생산성 향상을 꾀하며 개발수명주기간 품질보증체계를 적용하여 개발초기부터 고품질 소프트웨어를 생산하도록 촉진하여 소프트웨어 위기라는 문제에 근본적으로 대응할 수 있게 된다.

기본적이고 이론적인 내용일 수 있으나, 항상 문제는 기본을 지키지 못한데서 발생한다는 것을 잊지말자.

마치 역사가 반복되는 것처럼, 패션 스타일도 돌고 돌고 UI 디자인 트랜드도 돌고 도는 듯 하다.

디자이 트래드에 대한 이해는 다음 글들을 참고.

- http://blog.naver.com/youngdisplay/220690365967
- http://blog.naver.com/kosoodream/220769634590
- http://segrami.tistory.com/11

실제적인 모바일 UI/UX 설계 및 개발시 참고할 만한 가이드는 다음 사이트를 참고.

- Material Design Guide: https://material.google.com
- Material Design CheckList: https://developers-kr.googleblog.com/2014/10/material-design-on-android-checklist.html
- 모바일 UI 디자인 시 고려해야 할 가이드라인: https://brunch.co.kr/@chulhochoiucj0/9

모바일 SW 및 UX 사례연구.

- http://www.sw-eng.kr/member/customer/Webzine/BoardView.do?boardId=00000000000000046341&currPage=&searchPrefaceId=00000000000000020135&titOrder=&writeOrder=&regDtOrder=&searchCondition=TOT&searchKeyword=

- http://www.sw-eng.kr/member/customer/Webzine/BoardView.do?boardId=00000000000000045634&currPage=&searchPrefaceId=00000000000000020135&titOrder=&writeOrder=&regDtOrder=&searchCondition=TOT&searchKeyword=

- http://www.sw-eng.kr/member/customer/Webzine/BoardView.do?boardId=00000000000000045697&currPage=&searchPrefaceId=00000000000000020135&titOrder=&writeOrder=&regDtOrder=&searchCondition=TOT&searchKeyword=

올해 몇 가지 자격증을 취득하면서 든 생각과, 주위 지인들의 자격증에 대한 그들의 견해를 접하면서 들었던 생각을 정리해 본다.

자격증 자체에 대해서는 별로 할 말이 없고, 다음과 같은 질문에 대한 필자의 생각 한 꼭지를 끄적여 본다.

자격증은 과연 그 사람의 역량을 증명해 주는가?

곰곰히 생각해보니, 이 질문을 좀 바꾸는 게 좋겠다는 생각이 들었다.

'역량을 증명한다'라는 것은 과도하게 포괄적이고 추상적일 수 있어, 다음과 같이 질문을 바꿔보기로 했다.

사람의 역량은 자격증 취득으로 향상되는가?

이제 좀 현실적인 답변이 가능해 질 것 같다.

역량이란 '주어진 임무를 수행할 수 있는 힘'을 의미하며, 그 힘의 정도는 그 사람의 총체적 능력에 대한 문제로 이해할 수 있다.

한 사람의 총체적 능력에는, 
그 사람의 두뇌의 질적 우수성은 물론이고 & 의도적으로 머릿속에 차곡차곡 밀어넣은 지식 & 그리고 삶에서의 성공, 실패를 통해 배운 경험 등 모든 것이 영향을 주게 된다.

생각이 여기에 다다르자 다음과 같은 공자님의 말씀이 자연스레 떠오른다.

학이불사즉망 사이불학즉태(學而不思則罔 思而不學則殆)

"배우기만 하고 생각하지 않으면 어둡고, 생각만 하고 배우지 않으면 위태롭다"

역량에 기여하는 선천적인 요소(타고난 천재와 같은)를 제외하면 역량 향상을 위한 노력은 바로 의도적 학습과 경험적 지식으로 나눠볼 수 있다.

공자께서는 '배우고 생각하라'고 하셨다.

배움과 생각이 한 쪽으로 치우치지 않고 서로 보완되고 융합되어야만 한다는 메시지를 전달한다.

여기서 필자는 '배움'을 의도적 학습에 의해 축적되는 '지식'으로 연결하고, 배운 지식을 자신의 것으로 만들기 위한 끊임없는 '고찰(생각)'은 지식이 시행착오를 거쳐 현장에서 적용되는 '경험'과 그 경험으로부터 얻어지는 실질적 경험지식으로 연결될 수 있다고 본다.

실제적 상황과 복잡한 현장의 문제해결 능력은 그 사람의 지식과 경험으로 부터 생긴 응용능력이 밑바탕이 되는 것이다. 
(그리고 문제해결의 과정과 결과로부터 다시 지식과 경험의 양적/질적 향상이 이뤄져 순환구조를 띄게 된다)

이런 측면에서 보면 자격증 그 자체는 지식적인 요소에 해당한다고 볼 수 있다.

자격증을 취득하기 위해서는 의도적인 학습이 반드시 필요하다. 그 분야에서 요구하는 일반화된 지식을 습득하고 문제를 풀어야 하기에 지식 그 자체에 집중하게 되는 경우가 많기 때문이다.

그리고 지식만으로 부족한 경험은 실제 현장에서 뛰어봐야 얻을 수 있는 것이다.

따라서 '사람의 역량은 자격증 취득으로 향상되는가?에 대한 답은 다음과 같이 결론 내 볼 수 있겠다.

자격증 취득으로 지식적인 요소의 향상을 이룰 수 있다

그리고 이 글의 원 명제였던 "자격증은 그 사람의 역량을 증명해 주는가?"하는 것은

자격증은 그 사람의 지식적인 소양을 증명해 줄 수 있다

이제 자격증 그 자체로 시야를 돌려 보면, 좋은 자격증의 기준도 정할 수 있겠다.

지식과 경험이 모두 갖춰져야지만 취득 가능한 자격증이, 역량 증명이라는 측면에서 보다 경쟁력 있는 자격증이 되는 것이다.

그럼에도 불구하고 필자 역시 부정적으로 보는 자격증 유형이 있다.

크게 두 가지 유형으로, 특정 기관의 수익사업의 일환으로만 활용되는 사업행위로서의 자격증과 소위 덤프라고 불리는 기출문제만 달달 외워도 취득할 수 있는 자격증이 그 부류에 속한다.

이런 자격증의 특징은 가만히 들여다 보면 지식도 경험도 필요치 않다는 것을 알 수 있다.

암기와 지식은 엄연히 다른 것이다.

암기는 지식 축적을 위한 하나의 수단일 뿐이며, 진정한 지식은 본질에 대한 이해와 암기를 통한 습득이다. 본질에 대한 이해 없는 암기와 경험도 필요로 하지 않는 자격증은 이 글에서 논하는 자격증의 범주에서 제외하는 것이 좋겠다

이론과 실무의 균형을 어떻게 맞추냐는 것은 교육(education)과 훈련(training)을 어떻게 특징짓는가에 달려있다. 교육은 다양한 지적인 모험에 효과적으로 대응할 수 있는 자질을 부여하는 과정을 의미한다. 그리고 좀더 일반적인 지식에 초점을 두고, 비평적 사고력 개발을 포함한다. 그에 비해 훈련은 당장 쓸 수 있는 특정 기술과 지식을 제공한다. 즉. 교육이 전략적이라면, 훈련은 전술적이라고 할 수 있다. 

오늘날 소프트웨어 개발자에게 가장 많이 부여되는 능력 개발 형태는 바로 훈련이다. 훈련의 목적은 개발자가 특정 프로젝트에서 업무를 수행하기 위해 필요한 특정 기술을 빠른 시간 내에 익히는 것이다. 그에 비해 오랫동안 도움이 될 소프트웨어공학 원리들을 가르치는 교육은 거의 이루어지지 않고 있다.

어떤 사람은 소프트웨어 개발이 표준화된 교육으로 정립되기에는 너무나 전문적이고, 분화되었다고 주장한다. 그러나 소프트웨어 개발이 표준화된 훈련으로 정립되기에 너무 분화되었을지는 몰라도, 표준화된 교육으로는 정립될 수 있다. 

- Professional 소프트웨어 개발, 스티브 맥코넬 -
 

구글의 인터넷 기술 기여는 놀라웁다.

그 중, 고성능 인터넷 프로토콜에 대한 영향력과 파급력도 굉장한 수준이다.

이미 SPDY가 HTTP/2의 표준화에 기여했으며, 이젠 UDP기반의 고속 통신 기술인 QUIC(Quick UDP Internet Connections)도 표준화될 움직임을 보이고 있다.

구글의 고성능 프로토콜 전략과 표준화 흐름은 다음과 같다.

QUIC의 고속 처리는 다음 그림 한장으로 가늠할 수 있다.

다음 슬라이드를 통해 좀더 구체적으로 참고.

=> http://www.slideshare.net/deview/quic-67614063

올해 구글 IO 2016에서 '구글이 제시한 미래의 웹'에서 PWA와 같이 언급된 것이 AMP(Accelerated Mobile Pages)이다.

AMP는 웹 페이지의 고속 처리를 위한 구글의 Best Practice가 집약된 기술이다.

구글 AMP가 집중하는 것은 오직 성능이다.

성능을 위해 외부 JS 삽입도 불허하고 인라인 CSS의 크기도 제한한다.
굳이 AMP 페이지에 이런 것들이 구현되어야 한다면 iframe으로 분리하라고 권고한다.

AMP Components

AMP 페이지에서는 HTML 태그에 대응되는 몇 가지 커스텀 Component를 제공하며 이를 반드시 사용해야 성능이 개선된다.

AMP Cache

AMP 페이지는 구글 봇에 의해 자동으로 구글 CDN에 캐싱되어 Middle mile 경유를 최소화하여 응답속도를 향상시키다.

AMP Validation

지금 개발하고 있는 페이지가 AMP 제약사항을 따르는지 검사해 주는 도구이다.
URL 뒤에 #development 해시태그를 추가하면 크롬 개발자 도구를 통해 그 유효성 검사 결과를 보여준다.

중요한 것은, (앞서 언급했듯이) AMP 페이지를 만들기 위해 강제되어야 하는 제약사항이 비현실적일 수도 있다는 것이다. 특히 사용자와의 상호작용이 많은 복잡한 웹 페이지를 만든다면 AMP적용이 녹록치 않을 것이다.

결국 "단순한 정적페이지의 고속화에 초점을 맞춘 기술"이니 만큼 취사 선택하길 권장한다.

자세한 것은 구글 사이트를 참고.
=> https://www.ampproject.org/
=> https://www.ampproject.org/learn/about-amp/
=> https://www.ampproject.org/docs/get_started/create/basic_markup