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

2017년, 1년간의 아키텍트 업무 수행 내역을 기록한다.

오랜 기간 게임회사에 근무하다,
작년에 SI 회사로 이직하여 올해(2017년) Full 1년을 어플리케이션 아키텍트(AA)라는 직함을 달고 수행한 업무들이다.

게임회사 때의 개발 체계와 기술적 부분이 다소 상이하여 나름 고군분투하였으나, 많이 배우고 그만큼 성장한 한해가 아니었나 한다.

돌이켜 정리해 보니, 1년을 참으로 알차게 보냈구나 하며 스스로 칭찬해 본다. (토닥토닥)

내년에는 이 블로그에 더 성장한 한해를 기록할 수 있기를 기대하며...

* 통합 kt.com 구축

(사업유형) SI

(프로젝트 개요) 기존 유/무선 olleh.com 전면 개편,.대국민 서비스 향상 및 백오피스 효율화

(역할) 어플리케이션 아키텍트(AA)

(투입기간) 2017.01.02 ~ 2017.05.31 (6개월)

(수행업무) TO-BE 아키텍처 설계, 개발표준 수립, 성능향상 전략수립, 코드 템플릿 작성, 기술지원 등

(상면위치) KT 분당 본사

* kt estate 통합 부동산 시스템 구축

(사업유형) SI

(프로젝트 개요) kt estate 부동산 시스템 통/폐합을 위한 차세대 프로젝트

(역할) 어플리케이션 아키텍트(AA)

(투입기간) 2017.06.07 ~ 2017.07.05 (1개월)

(수행업무) AS-IS 분석 및 개선방향 도출, TO-BE 아키텍처 설계, 표준 프레임워크 선정 등

(상면위치) kt 관악 지점

* 신한은행 AI(인공지능) 코어플랫폼 제안 지원

(사업유형) 제안

(프로젝트 개요) 신한은행 챗봇 및 인공지능 코어 플랫폼 사업 제안 프로젝트

(역할) 어플리케이션 아키텍트(AA)

(투입기간) 2017.07.11 ~ 2017.07.20 (약 2주)

(수행업무) AI 코어플랫폼 아키텍처 영역 제안서 작성 지원

(상면위치) kt 행당 지점

* kt 기가지니 개발자 포털 Front-end 아키텍처 지원

(사업유형) SI

(프로젝트 개요) kt 기가지니 개발자 포털 구축

(역할) 어플리케이션 아키텍트(AA)

(투입기간) 2017.08.07 ~ 2017.08.11 (1주)

(수행업무) Angular4 기반 개발표준 수립 및 가이드, 코드템플릿, 개발자 교육

(상면위치) kt 융합기술원(우면 연구소)

* 하나투어 구조진단 컨설팅

(사업유형) 컨설팅

(프로젝트 개요) 하나투어 호텔 중계 시스템 어플리케이션 구조진단

(역할) 컨설턴트

(투입기간) 2017.08.14 ~ 2017.09.01 (3주)

(수행업무) 시스템 구조진단(AS-IS 구조 및 소스 분석, TO-BE 개선사항 도출)

(상면위치) 하나투어 본사(종로)

* K쇼핑 구조진단 컨설팅

(사업유형) 컨설팅

(프로젝트 개요) KTH, K쇼핑 어플리케이션 구조진단

(역할) 컨설턴트

(투입기간) 2017.09.04 ~ 2017.09.22 (3주)

(수행업무) 시스템 구조진단(AS-IS 구조 및 소스 분석, TO-BE 개선사항 도출)

(상면위치) KTH(동작구 보라매)

* 전사 AA(Application Architecture) 활동

1. DevPro 프레임워크, Angular-Starter 개발
- 전사 프레임워크(Devpro)에 Angular4 기반 Front-end 프레임워크 및 템플릿 추가

2. Zero-Copy 전사 세미나 개최
- 전사 세미나 세션 발표(주제: Front-end 트랜드)
- 2017.10.31 ~ 2017.11.01

3. SSAM 사내강의 진행
 - 2일 과정 사내 강의(주제: Angular4로 SPA 개발하기)
 - 2017.11.21 ~ 2017.11.22

* kt 기업 LTE 2.0 통합고객관리시스템 개발 프로젝트, 품질종합진단

(사업유형) 감리

(프로젝트 개요) 분석/설계 말 품질종합진단 AA영역 진단 수행

(역할) 어플리케이션 아키텍트(AA)

(투입기간) 2017.11.27 ~ 2017.11.30 (1주)

(수행업무) 프로젝트 품질진단(AA영역 품질 진단 및 개선방안 도출)

(상면위치) KT 분당 본사

* kt Biznaru 통합 분석/설계 

(사업유형) SI

(프로젝트 개요) Biznaru 에너지 + 보안 + new biz(신재생 등) 통합을 위한 분석/설계 프로젝트

(역할) 어플리케이션 아키텍트(AA)

(투입기간) 2017.12.01 ~ 현재

(수행업무) 통합 방향성 및 아키텍처 설계, 인터페이스 정의, 개발표준 수립, 개발 가이드 작성 등

(상면위치) KT 분당 본사

* 기타

1. 애터미(Atomy) 내부 전산 고도화 영업 지원(기술 컨설팅) (11월)

2. 하나투어 호텔 중계 시스템 사업 제안 지원 (12월)

작년(2016)에 1월 1차 시험, 4월에 2차 면접을 치루고 5월에 정보관리기술사에 최종 합격을 했다.

2017년 12월도 얼마 남지 않은 이 시점에...
합격수기를 기록하기에는 늦은 감이 있지만, 더 늦기 전에 흔적을 남기고자 한다.

새로 적기에는 귀찮고, 작년 10월인가...
KPC(한국생산성본부)에서 발표한 합격수기 PPT 자료를 옮기는 것으로 한다.

일명. 6하 원칙 합격수기라는 고도의(?) 컨셉하에 작성된 합격수기 ㅋㅋ

1. Why 기술사?

기술사라는 자격증에 도전하기로 맘 먹은 이유이다.  
가장 주요한 요인은 바로... 그 유명한 '정체성(identity)' 이었다.
나의 정체성은 내가 정하고 싶었고 그 정체성이 지속가능한 이유가 필요했다.

2. What 기술사?

기술사법에서는 다음과 같이 기술사를 정의하고 있다. 지금 봐도 멋진 정의다.
기술사 = (전문지식 + 실무경험 + 응용능력) + 자격 취득자

3. Who 기술사?

기술사 공부는 누가 하는가에 대한 내용이다.
공부는 내가 하지만, 주위의 이해와 지원이 없으면 힘든 시험이다. 

4. When 기술사?

1차 시험 합격까지의 타임라인이다. 대략 1년 6개월 정도 걸렸다.
지금 돌이켜 봐도 힘든 시간들 이었다. 지금은 추억이 되었지만 당시에는 '불확실성 가득한 상태'로 지속하는 것이 아주 힘들었다.

5. Where 기술사?

어디서 공부했는냐인데.. 때와 장소를 가리지 않았다. 암기카드를 들고 다니며 틈만 나면 본 기억이 난다. 암기카드, 클라우드 저장소, 음성녹음 등 언제 어디서나 자료를 볼 수 있는 환경이 중요하다.

6. How 기술사?

공부하는 방법이라기 보다는...
공부하면서 작성한 수기노트와 암기장, 워드파일, 엑셀파일, 사용한 볼펜, 답안지를 보여준다.
평생살면서 이렇게 많은 볼펜과 노트와 암기장을 써 본적이 없었다. ㅜㅜ

느즈막히 철들어서 나이들어 고생하는 전형적인 케이스라 생각한다.

* 나만의 합격 노하우?

기술사 공부하면서 이런저런 시행착오를 거쳐가며 공부방법 자체에 많은 인사이트를 얻게 되었다.
그 내용을 정리하고자 목차만 적어본 것이다. 지금봐도 새록새록 느낌이 살아난다 ㅎㅎ

UFC의 스타 '코너 맥그리거'가 챔피언 '조제알도'와의 대전에서 1라운 KO승을 하며 이런 말을 했다.

'정확도가 파워를, 타이밍이 스피드를 압도한다'

그렇다. 강점을 살려 자신만의 노하우를 찾는 것이 중요하다. 그 강점은 각자 모두 다르다.
그러니 누구의 방법이 좋고 나쁨을 따지지 말고 그 방법들을 벤치마킹하되 자신만의 색깔을 입히는 것이 중요하다.

기술사 답안을 채점하는 사람은 그럴싸한 답안은 늘상 마주하게 된다.
그러니 그럴싸한 답안에 자신만의 차별화를 더해야만 빠른 합격이 가능할 것이다.

* 지금 중요한 건 단 하나, 실행력

무슨 일이든 마찬가지일 것이다. 중요한 것은 실행력이다.
생각과 고민은 모두 집어치우고 당장 시작하셈요~ 라고 수기발표를 마무리 하였다.

지금 글을 쓰며, 지난 과정을 곱씹어 보니 (당시에는 힘들었으나) 참으로 가치있는 시간이 아니었다 한다. 당시에는 공부로 인해 체력과 정신력이 많이 소진 되었었다.

무엇보다도 '불확실성'이 항상 괴롭혔다.
이 공부를 언제까지 해야 하며 과연 더 한다고 합격을 할 것인가라는 불확실성에서 오는 두려움...

과연 내가 지금 이 짓을 계속 하는게 맞나? 라는 의구심이 중간중간에 훅훅 치고 들어온다.

이때 지속가능한 힘을 주었던 것은 바로 다음의 한 문장이었다.

'진인사대천명' 

그리고 맹자님의 다음 말씀도 아주 큰 위로가 되었다.

PS

본 합격수기를 발표한 그때 그 시간

1차 시험 합격연에서 소감 발표

최종 합격연에서 한 컷

글을 쓰려면...

(부제: 그들이 글을 쓰지 못하는 이유)

글을 쓰려면,

복잡해 보이는 현상들 속에서 단순한 원리를 끄집어 내어 하나의 이론으로 전개할 수 있어야 한다.

그들이 글을 쓰지 못하는 이유는 여기저기 가져다 붙인 코드들에서 어떤 이론도 세울 수 없기 때문이다.

대부분의 문제해결은 마치 '소 뒷걸음 치다' 라는 속담을 연상케한다.

근본적인 원인을 분석해서 그에 맞는 대응책과 예방책을 마련하는 것이 아니라,
이것저것 피상적인 수준의 수정으로 어찌하다 보니 해결이 되는 경우가 허다하다.

경우에 따라서는 피상적인 해결 수준에도 미치지 못하는 결론도 쉽게 내린다.

그도 그럴 것이 근원적인 원리를 알지 못하니 어찌보면 당연한 수순일 것이다.

기억도 영화처럼 다시보기 할 수 있었으면 좋겠다.

지난 주, 이틀에 걸쳐 사내강의를 진행했다.

주제는 'Angular4로 SPA 개발하기'로 Angular 개발에 관한 강의였다.

대체로 현업에서 관련 기술이 요구되는 개발자 분들이 참여했으며, 나역시 많은 것을 배울 수 있는 기회였다.

사내강사(SSAM) 뱃지

교육과정

교육교재

강의시작

데모 소스

https://github.com/mkex/angular-spa-demo.git

어제, 오늘 이틀에 걸쳐 사내 역량 강화 세미나를 팀 주최로 진행한다.

그 중 내가 맡은 세션은
 '프론트엔드 트랜드 뽀개기'라는 주제로, 최신 웹 트랜드와 프론트엔드 생태계 전반에 대해 설명하는 자리를 가졌다.

사내 기술 리더들인 AA, DA 들이 거의 모두 참여하여 진행한 뜻 깊은 자리 였다.

세션 소개

프론트엔드 트렌드 발표자료 목차와 세션 진행 사진

데모 소스

https://github.com/mkex/FETrend.git 

하루하루를 그냥 수동적으로 반응하며 사는게 아닌지...

그래서 일상의 불편, 불만이 머릿속을 떠나지 않는 거지...

"중요한 것에 집중하고 기본에 충실하기" 를 실천하고자 한다.

자바스크립트 개발환경에서 Ajax로 백엔드와 통신을 테스트 할때 걸리적 거리는 것 중 하나가 바로 CORS이다. 

CORS는 웹 브라우저의 기본 보안 모델로,
자바스크립트로 원격 리소스에 접근하고자 할 때, 자바스크립트를 내려 준 원천(Origin)이 아니면 Cross-Origin HTTP 요청으로 판단하여 요청을 허가하지 않게끔 한다.

그래서 웹 서버 설정이나 프로그래밍 방식으로 CORS 설정(HTTP 헤더 설정)을 통해 상호 통신이 가능케 한다.

이는 프로덕션 환경에서는 당연하겠지만, 개발 환경에서는 여간 불편한게 아니다.

개발 환경에서 서버 측을 직접 제어 할 수 있으면 별로 문제 될 것이 없으나, 그렇지 않을 경우 서버 측 담당자에게 CORS 설정을 요청해야 한다. 

만일 서버 측 환경이 다수의 서비스와 통신을 해야 하는 상황이라면 더욱 귀찮아 진다.

그래서 프론트엔드 단에서 Cross-Origin HTTP 요청이 가능하게끔 하는 방법이 자주 사용된다.

흔히 사용되는 방법으로는 Node.js의 http-proxy 관련 모듈을 사용해서 중간에 프록시 계층을 하나 두는 것인데, 이는 프록시 만을 위한 Node 응용프로그램을 별도로 띄워야 하는 점이 마음에 들지 않는다.

따라서 이 글에서는 프론트엔드 테스트 도구와 프록시 설정을 한방에 해결 할 수 있는 편리한 환경에 대해 소개하고자 한다.

몇 가지 선택지가 있으나 여기서는 Browser-Sync를 이용해 보자

1. 설치
 > npm install -g browser-sync

2. 프록시 설정 없이 테스트 돌려 보기
 > browser-sync start --server --files “*.*”

기본포트인 3000번 포트로 프론트엔드 파일들을 마치 웹 서버에서 실행하듯 테스트 해 볼 수 있다.
물론 Browser-Sync가 제공하는 각종 브라우저 동기화, 라이브로딩 등의 장점을 만끽하면서 말이다.
그런데 이렇게만 하면, CORS 통신을 하지 못하게 된다.

따라서 아래와 같이 실행.

3. 프록시 모드로 돌려보기

  > browser-sync start --proxy "localhost:8080" --serverStatic "public" --files "public"

정적리소스는 "public" 폴더에 있다고 가정하고 나머지 요청은 8080포트로 서비스 중인 서버 측으로 요청을 프록시하도록 한다.

이렇게 함으로써 정적파일은 정적파일대로 테스트 할 수 있고, 다른 도메인(포트)로 서비스 되고 있는 원격 API도 CORS상에서 호출이 가능해 진다.

음.. 아주 편하군...

끝!!!

그런데 이런 환경을 만들어 주는 게 비단, Browser-Sync만 있는 것이 아니다. 다음은 이와 같은 개발 환경을 가능케 해 주는 다른 모듈을 안내한다.

1) lite-server
- AngularJS 계의 거장(?)인 존파파께서 만들어준 로컬 서버 환경. Broswer-Sync를 기반으로 하고 있기 때문에 동일하게 동작한다. 물론 Angular 환경이 아니더라도 얼마던지 사용가능하다.

2) webpack-dev-server
- Angular2가 처음 출시될 때는 System.js에 lite-server를 사용했는데, 이후 버전 업이 되면서 최근 Angular-CLI는 webpack을 빌드도구를 채용하고 로컬 서버를 webpack-dev-server로 교체하였다.

역시나 Angular 환경이 아니더라도 webpack-dev-server를 사용할 수 있으며, 이 환경에서 CROS 설정이 가능하다.

다음 URL에서 아주 잘 설명하고 있다.

> https://webpack.github.io/docs/webpack-dev-server.html#proxy 

3) Angular환경 
- 만일 최신 Angular 프레임워크로 작업하고 있다면 ng serve 실행 시 프록시 설정을 추가 할 수 있다. 역시 다음 URL에서 아주 잘 설명하고 있다.

> https://www.npmjs.com/package/angular-cli#proxy-to-backend

"소셜 크롤러(Social crawler)는 자바스크립트를 실행하지 않는다"

얼마 전, 아키텍트로 지원했던 프로젝트에서 기술지원 요청이 들어왔다.

Ajax로 점철된(?) 페이지에 소셜 공유 기능을 추가해야 하는데, 여의치 않다는 것이다.
그래서 기술적 해결방안을 요청해 왔다.

해당 프로젝트는 일종의 SPA(Single Page Application) 구조로,
전통적인 웹 구현 모델인 서버랜더링 방식이 아니라 클라이언트 랜더링 방식을 채택하고 있었다.

즉 HTML/Javascript/CSS와 같은 정적 리소스를 먼저 브라우저에 랜더링 한 후, 필요한 비즈니스 데이터를 Ajax 통신으로 가져와서 DOM 제어를 하는 방식이다.

이런 구조의 대표적인 걸림돌(?)은 SEO(검색엔진최적화)나 Open Graph 프로토콜에 기반한 소셜 공유에 취약하다는 것이다.

서버에서 비즈니스를 처리하고 동적으로 생성된 HTML을 반환하는 것이 아니라, 아무런 동적 처리가 되지 않는 HTML을 먼저 반환하기 때문에, 웹 크롤러가 가져갈 수 있는 정보가 한정적이기 대문이다.

다시말해 대부분의 웹 크롤러는 자바스크립트를 실행하지 않기에, 자바스크립트를 사용해 동적으로 구성한 정보를 웹 크롤러에게 줄 방법이 없는 것이다.

이에 대한 기술적 해결 방안으로는, 크게 다음과 같은 두 가지 전략을 생각해 볼 수 있다.

1. 서버 랜더링 방식을 살짝 가미하기
소셜 공유를 위해서는 소셜 크롤러를 위한 메타 정보를 제공해야 한다.
해당 메타 정보는 비즈니스 처리가 된 동적 정보로 구성되어야 하기 때문에 서버 랜더링 방식으로 필요한 메타정보를 구성하는 방식이다.

그리고 페이지의 나머지 처리는 Ajax 통신을 통해 동적으로 구성한다.
이 방식은 서버랜더링 + 클라이언트랜더링 방식을 하이브리드 시켜 '꿩 먹고 알 먹는' 착각(?)을 주기도 한다.

이런 구조는 다음 사이트에서 구현하고 있는 듯 하다

> http://jakduk.com

이 방식의 단점 이라면, 클라이언트 랜더링 방식이라는 아키텍처 구조를 조금 흔들어야 한다는 것이며 Angular와 같은 Full SPA 구조에서는 적용하기 힘들다는 것이다.

이를 위해 다음과 같은 두 번째 방식을 권장한다.

2. 웹 크롤러를 위해 별도의 메타 정보 제공하기
이 방식은 다음의 사이트에 잘 설명되어 있다.

> https://rck.ms/angular-handlebars-open-graph-facebook-share/ 

기존 페이지나 아키텍처 구조를 건드리지 않고도 적용할 수 있는 훌륭한 방법이다.

동적으로 생성된 메타 정보를 반환하는 별도의 로직을 만들고,
페이지 요청이 웹 크롤러로부터 온 것이라면 웹 서버의 Rewrite 모듈을 사용해 요청을 다시 작성한다.

즉 일반 사용자는 원래 페이지에 접근하고 웹 크롤러는 동적 메타 정보를 제공하는 HTML을 반환받도록 하는 것이다.

이때 메타정보를 제공하는 로직은 HTML을 반환하는 REST API로 구현하거나 별도 서버 측 페이지로 구현할 수 있다.

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

여러모로 비교해 봤을 때, 2번 방식이 보다 깔금하게 해결 할 수 있는 솔루션인 듯 하다.

그러나 이 글을 쓰는 목적은 다른데 있다.

3. 자바스크립트를 해석하는 웹 크롤러

근래 웹 아키텍처에 SPA(Single Page Application)가 많이 차용되는 추세이고, 특히 앱 스러운(App Like) 모바일 웹 환경에서는 SPA가 보다 효과적이다.

또한 Angular, Vue.js, React.js와 같은 SPA 프레임워크들이 인기가 치솟고 있으며, 하이브리드 앱 환경에서도 클라이언트 랜더링 방식이 심심찮게 적용되고 있다.

이렇듯 클라이언트 랜더링 방식이 기술적 트랜드로 자리매김 하고 있고 필드에서 많이 적용되고 있음에도 웹 크롤러는 아직 과거에 머물러 있다는 점을 꼬집고 싶다.

일부 브라우저 업계에서는 클라이언트 랜더링 방식에서 SEO 등의 적용을 위해 자바스크립트의 동작을 해석하는 웹 크롤러를 만들고 있다고는 한다. 그러나 현재까지도 대부분의 웹 크롤러는 단순히 URL을 호출하고 즉시 반환되는 HTML 덩어리에만 의존하고 있는 실정이다.

아무리 진보한 아키텍처라고 해도, 주변 환경이 이를 지원하지 않는다면 아키텍처의 훼손은 어쩔 수 없이 발생할 것이다.

개인적인 희망으로는, 웹 크롤러를 현실에 맞게 진화시켜 클라이언트 랜더링 방식에서도 SEO나 소셜 공유가 가능토록 해 주길 바란다.

혹여 망설여지는게,
표준적이고 범용적인 적용이 어려울 수도 있겠다 하는 것인데...

이것 역시 , 클라이언트 랜더링의 모든 커스텀 로직을 인식할 필요는 없고 초기화 함수 정도만 인식해 줘도 쉽게 풀릴 문제가 아닌가 한다.

크롤러의 발전을 기대하며...

참고> 페이스 북 클로러 테스트 페이지
다음 URL은 페이스북 크롤러가 소셜 공유를 했을 때 어떤 정보를 가져가는지 테스트 해보기 위한 도구이다.

https://developers.facebook.com/tools/debug/sharing

인정욕구로 자신의 역량을 높이는 게 아니라, 말을 앞세우는 사람이 되지 말 것이며...

혹여 그런 자가 주위에 있다면 가까이 하지 말 것이다...

* ECMAScript 6 브라우저 지원 현황

https://kangax.github.io/compat-table/es6/ 

간혹 내가... 농담처럼 하는 얘기가 있다.

농담반 진담반 인냥, 우스개 소리처럼 지인에게 꺼내는 말이지만, 사실 진담이 더 많이 담겨있다.

이것은 전문가가 되기 위한, 시간과 공간의 함의라 할 수 있다.

"나만의 서재" - 성장을 위한 사색과 독서, 공부, 연구를 위한... 어떤 방해도 받지 않는 사적 공간.

"나만의 새벽 시간" - 세상이 아직 깨어나지 않은 듯한, 나에게만 주어진 듯한 깨끗한(?) 사적 시간.

사실 이 두 가지는 마음만 먹으면 쉽게 가질 수 있는 것이다. 단지 의지와 노력이 없을  뿐!

그래서 더욱 더 전문가의 자질과 관계되는 것이기도 하다.

---

구본형 선생의 다음의 글은 실천하는 전문가의 삶을 보여준다.

그리고 그 삶을 위해서는 소중한 시간과 삶을 침식당하지 않기 위한 습관이 필요하다.

타인에게 존경받기 위해 쓸데없는 코스프레를 하기 전에, 나 스스로를 존경할 수 있도록 말이다... 

정보통신기술사협회에서 주관하는 국회토론회.

아이들의 SW교육에 관심있는 모든 사람 대상. 일반인 참석 가능.

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

초중고 SW교육 의무화 대비 방안 마련을 위한 국회토론회 마련.

SW중심 사회 정착과 제4차 산업혁명을 이끌 초중고 SW교육 방안을 제시하고, 논의하기 위하여 아래와 같이 토론회를 개최하오니 많은 분들의 참여를 부탁드립니다.

ㅇ 일시: 2017년 2월 15일(수) 오전 10시 ~ 12시
ㅇ 장소: 여의도 국회 의원회관 (9호선 여의도 국회의사당역 1번 출구)

본 아티클에서는 Angular 2.4.4 버전에서 테스트 되었습니다.

Angular 응용프로그램은 컴포넌트와 디렉티브, 파이프, 서비스 등의 조합으로 이루어진다.

응용프로그램의 규모가 커질 수록, 이러한 구성요소들을 특정 기준에 따라 그룹화시켜 관리하는 것이 좋은데 이를 위해 Angular에서는 @NgModule이라는 decorator를 통해 모듈화 구성을 지원한다.

Angular의 모듈 구성을 사용하면, 컴포넌트들을 논리적으로 그룹핑하여 관리할 수 있으며
라우팅과 연계하면 모듈 단위 Lazy Loading을 구현할 수도 있다.

(참고: 논리적 그룹이라는 측면에서 보면 닷넷의 namespace, 자바의 package와 유사할 것이다.)

Angular의 모듈화 구성에 대해 살펴보자

@NgModule Decorator
Angular 모듈구성을 위한 메타데이터 객체정보를 전달받는 데코레이터 함수이다.
전달된 메타데이터 정보에 기반해서 현재 모듈로 구성해야할 컴포넌트와 디렉티브, 파이브 등의 정보를 식별하고 외부로 노출할 컴포넌트를 결정한다.

전달되는 메타데이터 속성은 다음과 같다.

1) declarations
- 현재 모듈에 포함시킬 뷰 클래스들을 지정.(뷰 클래스 종류: 컴포넌트/디렉티브/파이프)

2) exports
- declarations에서 정의한 현재 모듈의 구성요소를 다른 모듈의 템플릿에서 사용할 수 있도록 노출시킬 뷰 클래스들을 지정.(여기서 지정하지 않은 뷰 클래스들은 다른 모듈에서 사용 불가)

3) imports
- 다른 모듈에서 노출(exports)한 뷰 클래스들를 사용하기 위해 해당 모듈 임포트.

4) providers
- 공통 서비스의 등록. 등록된 서비스는 앱의 모든 부분에서 사용 가능.

5) bootstrap
- 메인 뷰로 사용될 루트 컴포넌트 지정. 루트모듈에서만 지정가능.

(https://angular.io/docs/ts/latest/guide/architecture.html#!#modules 참고)

이제 @NgModule을 사용해서 모듈화 구성의 초간단 샘플을 작성해보자.
두 가지 형태로 테스트를 해볼텐데, 첫번째는 규모가 작은 응용프로그램이라는 가정 하에 단일 모듈(루트모듈) 구성을 두번째는 서브모듈을 하나 더 만들어 볼 것이다.

1. 루트 모듈만 사용
Angular는 최소한 하나 이상의 모듈로 구성해야 하는데, 가장 기본이 되는 모듈이 바로, 
루트모듈(Root Module)이다. angular-cli로 프로젝트를 생성하면 루트모듈이 자동으로 생성된다.

기본 생성된 구조에서, 컴포넌트와 서비스를 추가해보자.
추가된 컴포넌트는 sub.component와 sub.service이다. 폴더구조와 소스는 다음과 같다.

* 폴더구조

* 소스(sub.service.ts)

* 소스(sub.component.ts)

새로 추가한 SubComponent는 서비스를 주입 받아서 id/name 데이터를 획득해서 자신의 멤버변수에 할당하는 간단한 코드이다.

이렇게 추가한 SubComponent를 루트 컴포넌트에 해당하는 AppComponent에서 사용하기 위해 AppComponent의 HTML에 SubComponent 태그를 추가시킨다.

* 소스(app.component.html)

 그런데 이렇게 사용하려면 루트 모듈에 SubComponent와 SubService에 대한 참조가 정의되어 있어야 한다.

* 소스(app.module.ts)

이로써 결과를 확인할 수 있게 되었다.

* 결과화면

2. 모듈 분리하기.
앞서 루트모듈만 사용했을 경우 문제는, 프로그램 규모가 복잡하고 커질 경우 상당량이 컴포넌트/서비스/파이프/디렉티브가 생기게 되는데 이것들을 모두 하나의 모듈로 관리해야 하기 때문에 구조가 비직관적으로 복잡해지고 모듈단위 관리(라우팅 및 비동기모듈로딩 등)가 용이하지 않다는 점이다.

이에 데모를 조금 변경하여 모듈을 분리해 보자.

SubComponent와 SubService를 묶어서, 별도의 다른 모듈로 그룹화 시키기 위해 SubModule을 생성한다.

* 소스(sub.module.ts)

여기서 주의 할 점은 이 모듈의 컴포넌트를 외부 모듈에서도 사용하게끔 하려면 exports로 명시를 해줘야 한다는 것이다.

이렇게 함으로써 Sub집합(여기서는 하나의 컴포넌트와 하나의 서비스)을 별도의 Angular 모듈로 만들었으며 이 모듈을 루트모듈에서 사용하려면 다음과 루트모듈을 수정하면 된다.

* 소스(app.module.ts)

앞서 루트모듈만 사용했을 때에는, 컴포넌트와 서비스를 모두 참조해야 했지만 모듈을 분리하고 나서는 해당 모듈(여기서는 SubModule)만 참조하면 된다.

그리고 결과화면은 (볼 것도 없이) 앞의 예와 동일한다.

다음 아티클에서는 모듈과 연관되는 라우팅(Routing)에 대해 정리할 예정.


* 참고자료
- Angular 공식 가이드
- Angular Architecture Overview
- Angular Tutorial

서버와 클라이언트 사이드에서 모두 동작하는 자바스크립트 어플리케이션을 Isomorphic JavaScript(동형 자바스크립트)라고 한다.

굳이... 새로운 용어에 피로감이 들긴 하지만.

그간, 클라이언트.. 그것도 웹 브라우저에서만 주로 동작하던 자바스크립트가 명실상부! 그 영역을 점차 확대하고 있는 획기적인 시대에 이러한 패러다임을 공유하기 위한 개념적 용어는 필요해 보인다.

Isomorphic JavaScript 또는 Universal JavaScript라고들 하는데... 용어가 중요한 것이 아니라 서로 공감하고 이해되는 개념이 중요한 것이다.

Isomorphic JavaScript의 개념을 조금 더 확장시켜서, 서버-클라이언트의 동형은 물론이고 데스크톱, 가상현실/증강현실 분야에서의 자바스크립트와 하나의 어플리케이션 개발 생태계에 일조하는 개발 지원환경등을 모아서 다음과 같이 정리해 보았다

자바스크립트는 더 이상 웹만을 위하지 않는다. 그는 데스크톱 영역을 침범하기 시작했으며 가상현실 영역으로부터도 러브콜(?)을 받고 있다. 그의 생태계는 점점 넓어지고 깊어지고 있는 것이다.

순전히 개인적으로 좋아서, 틈틈히 해 오던 자바스크립트 공부에 활력소가 되고 있다. 음.. 좋아~~~