#yoman

Angular는 구글에서 만든 자바스크립트 프레임워크이다.

프레임워크이기 때문에 일반적으로 여러분이 아시는 jQuery, underscore, lodash 보다 규모가 큰 프로젝트다. (지원되는 기능의 폭도 넓으며 채택한 의존 라이브러리들도 많다.)

한글 발음으로 “앵귤러 제이에스"라고 발음하면 되며 여기서 Angular는 “앙상한" 이라는 단어를 가지고 있는데,

아무래도 뼈대를 갖춰주는 프레임워크라는 의미로 사용했을 것이라고 생각된다.

Angular 공식페이지에 기재된 워딩이  “One framework” (하나의 프레임워크)인데, 이는 Mobile까지 대응하겠다는 Angular의 목표가 깃들어있다.

Angular에 대해서 대체 무슨 프레임워크인가, 어떤 목적과 장점을 가지고 있는가에 대해서 궁금증이 많으실 것이라 생각된다.

사실 이 물음을 풀어드리기 위해서는 앞서 웹 프론트엔드 개발 동향을 먼저 설명해야 할 것 같다.

웹 프론트엔드의 변화

현재 웹 프론트엔드 개발에서 사용되는 툴이 많다! 너무 많다! (그리고 많아지고 있다!!)

(필자는 이 사진에 보여지는 앱보다 많은 앱을 사용했음에도 전체에 비해서는 절반도 채 되지 않는다.)

일부 개발자는 전통적인 프론트엔드 개발 방식대로 html과 javascript 그리고 css를 개발하고,

javascript 엘리먼트를 쉽게 찾을 수 있는 jQuery와 jQueryUI를 연동하여 서비스를 완성 했을 것이다 그리고 그렇게 개발하는 방법에 큰 불편함이 없었을 것이다.

결과적으로 오늘에서 이렇게 개발을 도와주는 앱이 많아진 것은 ECMA 5에서 ECMA 6로 자바스크립트 표준이 변경되고 있는 상황과,

Node.js 보급으로 인해 백엔드 서버 개발자가 점점 javascript를 사용하게 되면서 백엔드 기술 프론트엔드와의 경계가 허물어지고 있는 점.

그리고 거대한 웹 서비스 벤더사(구글, 페이스북)에서 프론트엔드 프로젝트에 기여를 하고 있는 점 이것들이 뭉치면서 아래와 같은 결과를 내었다.

웹 프론트엔드 개발에 백엔드 개발에서 요구되던 기능이 추가되고 있다.

ECMA6의 지원을 위한 서브 툴이 생겨나고 있다.

많은 모바일기기 지원으로 보다 빠른 웹을 시장이 원하고 있다.

많은 기존 자바스크립트 라이브러리들이 최신 기술을 수용하고 있다.

(웹 프론트엔드 개발자들은 공부할 것이 엄청나게 늘어나 버렸다.)

또한 이러한 변화가 프론트엔드의 러닝커브를 늘렸으며,

기존 개발 환경에 익숙하여 최신 동향을 살펴보지 않는 개발자들은

자리를 위협받는 상황이 오지않았나 조심스럽게 추측해본다.

웹 프론트엔드 도구들

그러면 아까 사진에 보여드린 수많은 앱 들이 도대체 무슨역할을 하나?

그리고 그것이 반드시 필요한가에 대해서도 설명을 드릴까 한다.

상당히 지루하고 딱딱한 내용이 될 것 같아 많은 링크와 사진을 첨부했다.

   1. npm, bower, yoman, yarn

이 4가지 서비스는 Pakcage Manager(패키지 매니저)라고 부르는 서비스다.

(yoman은 정확히 말하면 스캐폴딩(Scaffolding - 실제 작업을 하기 전 철골을 덧대듯이 작업에 필요한 최소한에 구조를 만들어주는 단계)만 해주는 서비스.)

쉽게 풀어보자면 프로젝트에 사용할 라이브러리를 직접 찾아 해당 파일을 원격지에서 다운받아 로컬 파일에 옮기지 않아도, 간단한 명령어로 추가/수정/삭제를 지원하고 의존성(Dependency)을 관리해주는 서비스들을 의미한다.

또한 라이브러리 배포와 호스팅/빌드/테스트 스크립트 정의도 가능하다.

      2. Typescript, Flow

타입스크립트는 자바스크립트에서 발생할 수 있는 문제(타입 검증)를 해결해주는 동시에 ECMA6의 스펙을 포함하여 지원하고 있으며 Microsoft와 Google이 협력하여 개발하고 있는 언어이다. Typescript를 통해 개발을 진행하게되면 런타임 단계에서 발생할 수 있는 오류를 미연에 방지할 수 있고 OOP 지향한 개발과 Dependency Injection(DI)등의 패턴을 구현할 수 있게 된다. React 프로젝트의 Flow또한 타입 검증을 지원해준다.

      3. Reactive Programming

과거에는 웹 페이지 이동 (빈 화면에서 로딩이 걸리고 새로운 페이지가 보여지는) 없이 데이터를 업데이트 하는 사이트는 드물었지만 지금은 웬만한 서비스에서 이 기술을 적용하고 있다. 이러한 비동기 통신은 콜백함수를 통해 전달이 되어야 했으며 이 때문에 콜백지옥이 발생하기도 했다. RX(ReactiveX) 프로젝트는 이러한 문제를 해결해주며, 옵저버 패턴을 제공하여 서로다른 컨텍스트에 데이터를 동시적으로 제공해줄 수 있다.  Redux, Flux 서비스는 이러한 데이터를 효율적으로 대상에게 전달할 수 있다. 참고로 AngularJS 2는 RxJS를 포함 할 수 있다.

     4. grunt, gulp, webpack

여러분이 만약 반복되는 작업을 조금이라도 재활용하여 효율적인 프로그래밍을 원했다면 CSS의 작성이 굉장히 피곤하게 느껴졌을 수 있다, LESS와 SASS, Stylus와 같은 기술은 이러한 반복되는 작업을 없애주고 더불어 색상 코드를 특정 % (밝게, 어둡게)와 같은 편의 함수를 제공한다. 다만 결국 브라우저는 CSS 문서만을 인식하기 때문에 .less .sass와 같은 확장자는 빌드단계에서 변경이 이루어져야 한다, 그 밖에도 빌드 단계에서 진행되야 하는 작업들 (ECMA6 파일을 ECMA5 파일로 변경, 문서 최적화, 코드 테스트, 카피라이팅 삽입, 문서 문법 검증, 번들링 등)을 도와주는 도구가 grunt, gulp, webpack과 같은 도구이며 이는 다시 npm등의 패키지 매니저 도구와 연동하여 사용하거나 IDE(통합 개발환경)에서 연동하여 빌드과정을 일관화 시킬 수 있다. 이렇게 되면 파편화 되있는 JS, CSS, HTML 문서를 하나로 합쳐주며 표준코딩을 지향하게 되며 하위 호환 여부 검토가 수월하고 예기치 못한 버그와 사이드이펙트를 미연에 방지 할 수 있게 된다.

     5. RequireJS 그리고 CommonJS와 AMD(Asynchronous Module Definition)

Node.js의 영향 중 하나라고 필자는 생각한다.

네이버 D2에서 작성한 글이 보기 좋아 링크를 공유한다.

웹 페이지에서 서비스를 개발할 때 여러 Javascript 라이브러리를 합쳐 하나의 완성된 서비스를 만든다. 이때 이 라이브러리를 하나의 모듈로 볼 때 그 모듈에 대한 표준이 없다는 것이다. 따라서 각각의 라이브러리들은 서로다른 라이브러리 제공방식을 사용하고 있고 이를 이용하는 개발자는 각각의 라이브러리마다 다른 방식의 사용법 (같은 라이브러리라도 버전마다 달라지기도 한다.)을 이용해야하고 또 이러한 부분은 굉장히 비효율적으로 이용된다. (케익 한조각을 먹기위해 케익 전체를 사야하는 상황)

이를 해결하기 위해 나온 모듈 제공 방식이 CommonJS와 AMD이다.

각각의 사용형태가 다른 모듈들을 제공하는 하나의 표준을 만들어 그것을 지향하면 라이브러리 추가와 확장이 훨씬 쉬워지며 이는 큰 프로젝트에서도 모듈의 관리가 용이하며 효율적이다. 하지만 이 방식을 사용해도 마찬가지로 브라우저에서는 지원하지 않기 때문에 (다만 ECMA6는 import 키워드를 제공한다.) 이를 번들링 하기 위한 systemjs, Jspm, Rollup.js, Webpack등의 서비스가 존재한다

      6. jasmin, chai, mocha

규모가 큰 프로젝트 일수록 소스관리가 중요하여 자칫 하나의 수정사항이 사이드이펙트(다른 비즈니스 로직에 직/간접적으로 영향이 가는 것)가 발생 할 수 있다.

이는 라이브서비스에 커다란 이슈이며 이를 해결하기 위해 QA와 테스트케이스가 존재한다. 다만 규모가 크고 지원하는 플랫폼이 넓으며 수많은 페이지와 버그가 발생하는 환경을 시연하기 어려운 요소가 발생되면 이러한 테스트는 사람이 직접하기 어렵고 특히 애자일 방법론을 사용하는 개발 환경에서는 이러한 과정이 거의 불가능에 가깝다. 결국 이를 해결하기 위해서는 자동화된 개발 테스트 환경이 필요하다.

프론트엔드 개발도 마찬가지로 유닛 테스트를 지원하는 서비스가 있다. 가상의 DOM Mock에 라이브러리의 모든 케이스를 테스트해보고 결과적으로 테스트의 결과를 확인할 수 있게 제공하여 서비스 배포이전에 모든 기능에 안전성을 검토 할 수 있다.

      7. istanbul, blanket, JSCoverage

이전에 말한 유닛테스트는 서비스 되고있는 소스코드의 얼마나 많은 부분을 테스트 해주는지에 대한 부분이 상당히 중요하다. (많은 부분이 자동화 테스트를 지원할 수록 서비스는 안정적이고 신뢰를 보장하기 때문) 하지만 얼마나 많은 부분의 소스코드에 테스트를 지원하는지 사람이 알기에는 어렵다고 볼 수 있다. 이 때문에 얼마나 많은 부분이 테스트가 되었는지, 다시말해 얼마나 코드가 커버(Cover)되었느냐는 커버리지(Coverage)라는 용어를 사용하여 지표를 결정한다. 유닛 테스트 도구와 연동하여 커버리지 도구를 사용하게 되면 커버리지 지표를 리포트로 제공받게 된다.

      8. JSDoc

JSDoc은 javascript 모듈에서 사용되는 각각의 클래스, 함수들에 대한 정의를 JSDoc에서 정의한 표준 주석양식에 맞춰 작성하게 되면 그에따른 자동화된 개발 래퍼런스 문서가 만들어지게 된다. 마크다운 문서로 래퍼런스 문서를 제공하여 gitbook 같은 호스팅 서비스에 등재하게 되면 하나의 인쇄물로서 출력도 가능하다. 이러한 방법은 개발자가 일일히 래퍼런스 문서를 만들지 않아도 래퍼런스 문서를 만들 수 있는 이점이 있으며 표준화된 주석 사용으로 협업 및 인수인계가 원할하게 된다. 사실 다른 Doc 툴도 있지만 해당 서비스가 가장 유력하다.

AngularJS 2에 대한 설명을 위한 포스팅이었으나, 최근들어 웹 프론트엔드 개발 동향이 많이 변하고 있어 그 부분을 중점적으로 정리해보았다.