728x90
반응형

 Performance Issue

먼저 얘기할 부분은 Angular의 Performance 입니다.

기존 AngularJS에 비해서 Angualr는 여러 관점에서 성능향상이 이루어졌습니다. 하나씩 간단하게 살펴보겠습니다.

  • Digest Loop로 인한 성능 저하 문제가 개선되었습니다. 우리 예제에서 다뤄보았던 양방향 바인딩 기억하시나요? AngularJS에서는 이 양방향 바인딩을 처리하기 위해 watcher라는걸 사용합니다. 이 watcher라는 놈이 수행될 때 마다 digest loop가 수행되어 양방향 바인딩을 처리하는 구조였습니다. 양방향 바인딩이 많아질수록 watcher가 증가하고 결과적으로 digest loop의 수행도 같이 증가해서 결국 성능이 저하되는 문제가 발생했던 겁니다. 지금의 Angualr는 전통적인 양방향 바인딩을 다른 방식으로 처리함으로써 이 문제를 해결했습니다.

    현재 Agnular에서 양방향 바인딩은 내부적으로 Property binding과 Event binding으로 변환되어서 처리됩니다. 만약 Angular의 Change Detection에 대해 자세히 알고 싶으시면 여기를 참고하세요.


  • Angular는 AoT Compile을 지원합니다. AoT(Ahead of Time) compile이란 사전 컴파일을 지칭합니다. 런타임에 컴파일을 하지 않고 미리 컴파일을 해 놓기 때문에 실행 속도를 더 높일 수 있는 것이죠. 안드로이드 개발을 해 보신 분이라면 Dalvik과 ART를 알고 계실 겁니다. Dalvik은 JIT 컴파일러를 이용하고 ART는 AoT 컴파일러를 사용합니다. 둘을 비교해보자면 JIT(Just-In-Time)은 실행시점에 소스코드를 컴파일하는 방식입니다. 설치는 빠르게 되겠지만 실행이 좀 느리겠지요. AoT는 설치시점에 소스코드를 컴파일하는 방식입니다. 따라서 설치가 조금 느려지지만 실행시 빠르게 실행되는 장점을 가지고 있습니다.


  • Angular뿐만 아니라 모든 Front-End Framework이 가지는 문제점 중 하나는 바로 SPA(Single Page Application) 구조에서 오는 rendering의 속도 문제입니다. 우리는 기존에 SSR(Server Side Rendering)을 이용해 프로그램을 했었습니다. 예를 들면, JSP 이런것들 이지요. SSR의 장점은 일단 클라이언트에게 빠르게 화면을 보여줄 수 있다는 겁니다. 하지만 라이브러리가 다 로딩된 후에야 Client와 interaction이 가능합니다. 반면에 SPA 구조는 모든 라이브러리가 다 로딩되어야 Client가 화면을 볼 수 있습니다. 즉, Client가 초기에 화면을 보기까지 로딩시간이 걸린다는 것입니다. CSR(Client Side Rendering) 이라고 불리는 이 방식은 화면이 뜨자마자 바로 interaction이 가능하다는 장점이 있습니다. 요즘에는 이 둘을 섞어서 최적화를 꾀하고 있습니다. 이와 관련된 사항으로 Angular는 Lazy Loading을 사용합니다. Lazy Loading(지연 로딩)은 SPA의 단점을 극복하기 위한 하나의 방법으로 사용하는 모든 라이브러리를 한꺼번에 다 불러들이지 않고 필요한 시점에 필요한 라이브러리만 로딩하는 방식입니다. 이를 이용해 로딩 시간을 단축할 수 있기 때문입니다.

 Angular CLI

그 다음 살펴볼 부분은 Angular CLI입니다. 우리 예제 프로그램을 작성하기 위해 사용했던 것 기억하시지요?

Angular CLI(Command Line Interpreter)는 command 명령어를 이용해서 프로젝트의 생성 및 Scaffolding, build, 개발서버를 이용한 실행과 테스팅까지 수행할 수 있는 개발지원 도구 입니다. 간단하지 않는 프로젝트의 구조 생성 및 설정 그리고 Coding Convention등을 자동으로 잡아주기 때문에 편하게 개발환경을 구축하고 표준적 방식으로 프로젝트를 진행할 수 있도록 도와주는 아주 고마운 도구이지요.

다음은 일반적으로 많이 사용되는 Angular CLI의 명령어와 알아두어야 할 사항들 입니다.

  • 프로젝트의 생성
    ng new <project_name>
    

    위와 같은 형태로 프로젝트를 생성하면 기본 폴더 구조와 파일이 생성됩니다. 이전에도 언급했지만 이렇게 생성된 프로젝트의 구조와 Coding Convention이 Angular의 표준 스타일입니다. 또한 필요한 의존 Module이 같이 설치됩니다. 만약 의존 Module을 설치하고 싶지 않을 경우 --skip-install option을 이용해 프로젝트를 생성하시면 됩니다.


  • 내장 개발서버를 이용한 프로젝트 실행
    ng serve
    

    위와 같은 명령을 이용하면 내장 개발 서버를 이용해 우리 프로젝트를 deploy할 수 있습니다. 기본적으로 사용하는 port는 4200 입니다. 만약 다른 포트를 사용하고 싶을 때는 --port option을 이용해 포트번호를 변경할 수 있습니다. 그리고 --ooption을 이용하면 시스템에 설정되어 있는 default browser를 실행해 http://localhost:4200 으로 접속까지 해 줍니다.

    이 내장 개발서버는 LiveReload 기능을 지원합니다. 쉽게말하자면 우리가 코드를 수정하면 그 내용을 컴파일하여 즉각 반영하고 browser를 refresh까지 시켜준다는 것이지요. 개발을 편하게 가져갈 수 있습니다.


  • 프로젝트 구성요소 추가
    ng generate <구성요소> <구성요소명>
    

    위와 같은 명령을 이용하면 프로젝트에 새로운 Angular 구성요소를 추가할 수 있습니다. 우리는 componentservice 구성요소를 추가해 봤지요. 그 외에 다음과 같은 Angular 구성요소들을 추가할 수 있습니다.

    • directive
    • pipe
    • module
    • class
    • interface
    • enum
    • guard

    이런 구성요소가 어떤 역할을 하는지는 나중에 하나씩 살펴봐야 겠네요. 기존에 우리 프로젝트에서 추가했던 search-box Component를 가지고 간단하게 Naming Rule에 대해 정리를 한번 해 보겠습니다.

    다음과 같은 명령을 실행하면 새로운 Component가 하나 만들어 집니다.

    ng generate component search-box
    

    생성되는 파일은 총 4개입니다. option을 설정하면 파일이 만들어지지 않을수도 있습니다. 즉, CSS, HTML, SPEC파일을 생성하지 않을수도 있다는 말입니다. CSS와 HTML을 inline방식으로 사용할 수 있으니까요. SPEC은 테스트를 위한 파일입니다.

    그런데 만들어지는 파일의 이름이 좀 특이합니다. 다음과 같은 형태로 만들어졌습니다.

    search-box-component.css     
    search-box-component.html    
    search-box-component.ts
    search-box-component.spec.ts
    

    파일명이 모두 search-box.component.* 형태로 만들어집니다. Angular는 Naming의 혼란을 방지하기 위해 케밥 표기법(Kebab case)을 이용해서 Angular 구성요소의 이름을 붙이게 됩니다. 사실 우리에게 익숙한 표기법은 Camel case입니다. 각 단어의 첫글자를 소문자로 쓰고 붙어있는 단어들은 대문자로 시작하는 표기법입니다. Java의 기본 표기법이죠. 참고로 Pascal case도 있습니다. Camel case와 유사한데 Pascal case는 첫 글자도 대문자로 시작합니다. Kebab-case는 하이픈(-)을 이용한 표기법입니다. Angular는 기본적으로 Kebab case를 Angular 구성요소 이름을 붙일 때 사용한다는걸 기억하시면 됩니다. 참고로 class의 이름은 Pascal case를 이용합니다.

    이렇게 만들어진 search-box-component.ts 파일의 내용을 살펴보죠

    import { Component, OnInit } from '@angular/core';
      
    @Component({
      selector: 'app-search-box',
      templateUrl: './search-box.component.html',
      styleUrls: ['./search-box.component.css']
    })
    export class SearchBoxComponent implements OnInit {
      
      constructor() { }
      
      ngOnInit() {
      }  
    }
    

    위의 코드에서 selector가 어떤 역할을 하는지 아실겁니다. 이 selector에 명시된 이름의 tag를 다른 template에서 이용하면 해당 tag 위치에 우리 Component에서 지정한 template이 표시되게 됩니다. 이 selector에 명시된 이름이 결국 <app-search-box></app-search-box>형태로 어딘가에서 이용된다는 말이죠. 이 selector에 지정된 이름을 붙일 때 접두어 app을 이용해 Kebab case로 표현합니다. 기존의 HTML tag와 혼동되는걸 피하기 위해서라고 생각하시면 됩니다.

    참고로 이 접두어는 .angular-cli.json 설정파일에서 다른것으로 지정할 수 있습니다.

    우리는 CSS와 HTML을 따로 파일을 만들어서 사용했지만 inline형태로 이용할 수 있습니다. 아래와 같이 말이죠.

    import { Component, OnInit } from '@angular/core';
      
    @Component({
      selector: 'app-search-box',
      template: `<h1>Hello<h1>
                 <p>
                  this is a sample text
                 </p>
                `,
      style: `.myStyle {
                  color : red
              }
             `
    })
    export class SearchBoxComponent implements OnInit {
      
      constructor() { }
      
      ngOnInit() {
      }  
    }  
    

    여기서는 backquote ( ` ) 기호를 이용하는 template string을 사용했습니다. 다른 Angular 구성요소를 추가하는 방법과 이용법은 이후 포스트에서 하나씩 실습을 통해 알아보도록 하겠습니다.


  • 프로젝트 Build
    ng build
    

    위와 같은 명령을 이용하면 우리 프로젝트를 Angular CLI를 이용해 Build할 수 있습니다. 기존에는 SystemJS를 이용해서 bundling을 했지만 현재는 webpack을 이용해 bundling합니다. option을 따로 주지 않고 build를 진행하면 개발환경 build를 수행하게 됩니다. 만약 production build를 수행하시려면 --prod option을 이용하시면 됩니다. 또한 deploy를 위한 base url을 설정할 때는 --base-href option을 이용하시면 됩니다. Angular CLI Build에 관한 보다 자세한 option 사항은 여기를 참조하시면 됩니다.


이번 포스트는 기존에 설명하기 좀 난감(?)했던 성능문제라던지 Angular CLI의 Naming Rule에 대해 보충설명을 진행했습니다. 만약 Angular CLI에 대해 더 자세하게 알고 싶으시면 여기를 살펴보시면 됩니다.

728x90
반응형

+ Recent posts