Angular2에서 Typescript를 사용하는 이유

Angular2 코어 멤버인 victorsavkin의 글 “Angular2: Why TypeScript“을 허락을 받고 번역 하였습니다. 번역에 대한 피드백이나 오류는 주저없이 트윗이나 메일로 알려주세요.

This post is the translation version of the original post “Angular2: WhyTypeScript” with allowed to translate by the author victorsavkin.

Angular2, TypeScript 로고

Angular2는 TypeScript로 작성된 코드이다. 이 글에서는 왜 Angular2에서 TypeScript를 사용하기로 했는지 설명할 것이다. 더불어 TypeScript를 사용하면서 코드 작성과 리팩토링시 어떤 영향을 받았는지 느꼈던 경험들을 함께 나눌 것이다.

 

나는 TypeScript를 좋아하지만 여러분들도 그럴 필요는 없다.

Angular2는 TypeScript로 작성되었지만 여러분도 Angular2 애플리케이션을 TypeScript로 작성할 의무는 없다. Angular2 프레임워크는 ES5, ES6와 Dart 언어로도 훌륭하게 작업할 수 있다.

 

TypeScript는 훌륭한 도구가 있다.

TypeScript의 가장 큰 장점은 도구의 지원이다. TypeScript는 높은 수준의 코드 자동생성, 코드 탐색과 리팩토링을 제공한다. 이러한 도구들은 일정 규모 이상의 프로젝트에서는 거의 필수적인 요소이다. 도구의 지원이 없다는 것은 거의 수정하기 어려운 상태의 코드 베이스에 코드를 수정해야만 하는 두려움을 심는 일이고, 대규모의 리팩토링 시 큰 위험성과 비용을 감수해야한다는 것을 의미한다.

TypeScript만이 Javascript로 컴파일할 수 있는 유일한 타입언어는 아니다. 이론적으로 완벽하게 들어맞는 도구를 제공하는 강력한 타입 시스템을 갖춘 다른 언어들도 있다. 그러나 이러한 언어들은 실용적인 관점에서 대부분 컴파일러를 제외하면 아무 것도 가지고 있지 않다. 이러한 차이는 TypeScript팀은 시작부터 풍성한 개발도구를 만드는 것을 명확한 목표로 갖고 있었기 때문이다. 그래서 TypeScript팀이 에디터에서 타입체크 기능과 코드완성을 제공할 수 있도록 언어를 만든 이유이다. TypeScript 개발을 돕는 훌륭한 도구들이 여러 에디터에 즐비한 이유가 궁금했다면, 그 답은 바로 TypeScript 언어의 지원때문이다.

Intellisens, Rename과 같은 기본적인 리팩토링을 안정적으로 지원한다는 사실은 코드를 작성하는 과정과 리팩토링 할 때 매우 큰 영향을 미친다. 측정하기 어렵지만, 이전에 며칠씩 걸렸을 법한 리팩토링 작업이 이제는 하루도 안되는 시간안에 끝나는 것 같다.

TypeScript는 코드 수정의 경험을 극대화해주는 반면, 개발환경 구축은 특히 간단하게 페이지에 ES5스크립트를 떨어뜨리는 기존 방식과 비교할 때 좀 더 복잡해졌다는 측면이 있다. 게다가 Javascript 소스코드를 분석하는 도구류(예를 들면 JSHint)를 사용할 수 없다. 그러나 적절한 대안이 있다.

 

TypeScript는 JavaScript를 포함한 확장된 언어이다.

TypeScript는 JavaScript를 포함한 확장된 언어이기 때문에, 여러분은 TypeScript로 코드를 전환하기 위해 크게 코드를 재작성할 필요가 없다. 여러분은 시간을 고려하여 하나의 모듈씩 점진적으로 전환해도 된다.

하나의 모듈을 가볍게 골라 js 파일을 ts로 바꿔보자. 그리고 점차 하나씩 타입 정보를 추가하자. 작업이 끝나면 순차적으로 다른 모듈을 골라 똑같은 작업을 하면 된다. 일단 전체 코드베이스가 타입정보를 갖추게 되면, 그때 여러분은 TypeScript의 컴파일러 설정을 좀 더 엄격하게 조정할 수도 있다.

이러한 과정은 시간이 좀 필요할 수도 있지만 Angular2를 TypeScript로 전환했던 과정을 보면 그리 큰 문제가 아니었다. 점진적으로 이러환 과정을 진행하면서도 우리는 새로운 기능을 개발하면서 버그를 수정하는 일을 지속할 수 있었다.

 

TypeScript는 추상화를 명시적으로 지원한다.

좋은 설계는 거의 잘 정의된 인터페이스와 등치된다. 그리고 언어가 지원한다면, 인터페이스를 의도한대로 표현하는 것이 훨씬 더 쉬워진다.

예를 들어, 도서 판매 애플리케이션을 가정하고 UI나 API와 같은 류의 외부 시스템을 통해 등록된 사용자가 구매할 수 있다고 해보자.

Purchaser UI diagram

여러분이 보는 것과 같이, User, ExternalSystem 두 클래스는 모두 구매자의 역할을 한다. 구매자의 개념이 이 애플리케이션에서 매우 중요한 부분임에도 불구하고 코드로 명확하게 표현되지 않는다. purchase.js라는 이름의 파일도 없다. 결과적으로 누군가가 코드를 수정할 때 이러한 역할이 있다는 사실을 놓칠 가능성을 내포하게 된다.

위의 코드만 들여다 봐서는 어떤 객체가 구매자의 역할을 하고, 이 역할을 포함하는 메서드가 무엇인지 논하기가 쉽지 않다. 우리는 확실하게 알 수도 없고 도구의 지원을 받아도 많은 도움을 얻을 길이 없다. 우리는 이러한 정보를 매우 느리고 오류를 일으키기 쉽지만 수동으로 추론해야만 한다.

자, 이번에는 Purchaser라는 인터페이스를 명시적으로 정의한 버전과 이전 버전의 코드를 비교해 보자.

타입정보가 포함된 버전은 명확하게 Purchaser인터페이스를 갖고 있고 UserExternalSystem 클래스가 이를 구현하고 있음을 알 수 있다. 따라서 TypeScript의 인터페이스는 추상화, 프로토콜, 역할의 정의를 가능하게 한다.

TypeScript가 추상화 정보를 추가로 포함하도록 강제하는 것이 아니라는 사실을 인지하는 것이 중요하다. Purchaser의 추상화된 정보는 명시적으로 정의되지 않았을 뿐 Javascript버전의 코드에서도 포함되어 있다.

정적타입 언어에서는 하위시스템 간의 경계가 인터페이스를 통해 정의된다. Javascript는 인터페이스가 없으므로, 순수한 Javascript로는 경계가 잘 표현되지 않는다. 명확하게 경계를 확인하기 어려운 경우에 개발자들은 추상화된 인터페이스가 아닌 구상타입에 의존하기 시작하고 이는 강력한 커플링으로 귀결된다.

나는 TypeSciprt를 적용하기 전과 전환된 후의 Angular2를 모두 사용하면서 이러한 믿음이 더 강화되었다. 인터페이스를 정의하는 작업은 내게 API의 경계를 고민하도록 강제하고, 하위시스템의 퍼블릭 인터페이스를 정의하도록 도우며 부수적으로 일어나는 커플링을 드러나게 한다.

 

TypeScript는 코드를 읽기 쉽게하며 이해를 돕는다.

그렇다. 나는 이 명제가 직관적이지 않다는 것을 알고 있다. 내 의견을 예제를 통해서 좀 더 상세하게 설명해 보겠다. jQuery.ajax() 함수를 살펴보자. 다음의 시그니쳐에서 우리는 어떤 종류의 정보를 얻을 수 있는가?

우리가 확실하게 말 할 수 있는 사실은 이 함수가 두가지 인수를 취한다는 것이다. 우리는 타입을 추론해야한다. 아마도, 첫번째 인수가 string이고 두번째는 설정을 위한 객체라고 가정일 것이다. 그러나 이는 단지 추론에 불과하며 틀릴 수도 있다. 우리는 어떤 옵션을 설정객체(설정정보의 이름이나 타입)에 넣어야 하는지, 이 함수가 무엇을 반환하는지 아무런 정보를 가지고 있지 않다.

소스코드를 확인하거나 문서를 보지 않는 이상 우리는 이 함수를 호출할 방법이 없다. 소스코드를 확인하는 것은 좋은 선택은 아니다. 왜냐하면 함수와 클래스를 사용한다는 것의 핵심은 어떻게 구현되었는지를 알지 않고도 이를 사용할 수 있어야 한다는 점이다. 다시 말하면, 우리는 구현체가 아닌 인터페이스를 활용해야 한다는 점이다. 우리는 문서를 확인할 수도 있지만 이 역시 개발자에게 유익한 경험은 아니다. 왜냐하면 이는 추가적인 시간을 소모하게 되고 때론 문서 자체가 옛 버전일 수 있기 때문이다.

jQuery.ajax(url, settings)이 읽는데 어려움이 없다고 하더라도, 정말로 이 함수를 어떻게 호출되는지 이해하려면 우리는 구현된 소스를 읽거나 문서를 봐야만 한다.

이제, 타입정보를 포함한 코드와 대조해 보자.

이 코드는 좀 더 많은 정보를 제공해 준다.

  • 이 함수의 첫번째 인수는 string이다.
  • 설정객체 인수는 선택사항이다. 우리는 이 함수에 전달된 옵션을 설정이름 뿐 아니라 타입까지 모두 확인할 수 있다.
  • 함수는 JQueryXHR객체를 반환하고, 우리는 이 객체의 속성과 함수도 알 수 있다.

타입 정보가 더해진 코드는 분명히 타입이 없을 때 보다 길어졌지만, :string, :JQueryAjaxSettings, JQueryXHR는 결코 혼란을 주는 불필요한 정보가 아니다. 이는 코드의 이해도를 높여주는 중요한 문서이다. 우리는 코드의 구현체나 문서를 읽지 않아도 좀 더 깊은 수준으로 코드를 이해할 수 있다. 내 개인적인 경험으로 비추어 보면 타입정보가 기술된 코드가 좀 더 많은 맥락을 제공하기 때문에 코드를 읽는 속도가 더 빠르다. 누구라도 타입정보가 코드의 가독성에 어떤 영향을 주는지에 대한 연구를 찾았다는 댓글로 알려주기를 부탁한다.

TypeScript가 Javascript로 컴파일되는 다른 여러 언어와 비교할 때의 한가지 차이점은 TypeScript에서 타입정보는 선택사항이라는 점이다. 따라서 jQuery.ajax(url, settings)는TypeScript에서 여전히 유효한 코드이다. 그러므로 TypeScript에서 타입정보는 온오프 스위치라기 보다는 다이얼에 더 가깝다. (역주: 필요에 따라 선택할 수 있는 버튼과 같다는 의미) 여러분이 봤을 때 타입정보가 읽고 이해하는데 진부하게 느껴지면 타입을 기술하지 않아도 되며, 타입이 필요한 때 타입 정보를 포함하면 된다.

 

TypeScript가 언어의 표현성을 제한하는가?

동적 타입 언어는 도구에 있어서는 부족함이 있지만, 좀 더 유연하고 표현력이 좋다. 내 생각에는 TypeScript는 여러분의 코드를 좀 더 엄격하게 만들 수 있지만 그러나 사람들이 생각하는 것보다는 그 정도가 그리 크지 않다. 정말로 그런지 살펴보자. 예제에서 나는 Person 레코드를 정의하기 위해서 ImmutableJS를 사용하였다.

우리가 어떻게 위 레코드에 타입 정보를 표기할 수 있을까? Person이라는 인터페이스를 정의하면서 시작하자:

만약 우리가 아래와 같이 코드를 작성했다고 한다면:

PersonRecord는 입력된 인수를 반영하여 생성되었기 때문에 실제로 Person과 호환되는지 알 수 없어 TypeScript 컴파일러는 경고를 여러분에게 보여줄 것이다. 여러분 중에 함수형 프로그래밍 경험이 있는 분이라면 다음과 같이 이야기 할수도 있다. “만약 TypeScript가 의존타입(Dependent Type)이라도 있었으면…” 그러나 TypeScript의 타입시스템은 가장 진보한 형태를 갖고 있는 것은 아니다. TypeScript의 목표는 좀 다르다. TypeScript는 프로그램의 100% 정확도를 보장하기 위한 것이 아니라 여러분들에게 좀 더 많은 정보와 훌륭한 도구의 사용을 제공하는 것이다. 따라서 타입 시스템이 충분히 유연하지 않을 때 손쉬운 방법을 써도 괜찮다. 따라서 우리는 생성된 레코드의 타입을 다음과 같이 캐스팅 할수 있다.:

타입정보가 포함된 예제를 보자:

이 코드가 동작하는 이유는 TypeScript의 타입시스템이 구조적이기 때문이다. 생성된 객체가 정확한 필드를 소유하고 있는 것으로 (이 예제에서는 nameage) 충분하다.

TypeScript를 사용할 때 여러분에게 필요한 것은 위와 같이 간단한 방식을 취해도 된다는 태도이며 여러분은 즐겁게 언어를 사용할 수 있다는 점만 발견하게 된다. 예를 들면, 분명히 여러분이 정적으로 코드를 표현할 방법이 없는 어떤 애매한 메타프로그래밍 코드에 타입정보를 추가하려고 하지 마라. 다른 코드에 모두 타입을 추가하고 타입체커에게 애매한 부분을 무시하게 하면 된다. 이러한 경우에 여러분은 표현의 풍부함은 잃지 않으면서도 여러분의 코드의 일부는 여전히 도구의 지원을 받을 수 있고, 분석할 수 있게 된다.

이것은 100% 단위 테스트 커버리지를 이루려는 것과 유사하다. 95%의 커버리지를 달성하는 것은 그리 어렵지 않으나, 100%를 이루려는 것은 상당한 노력이 들고 어쩌면 여러분의 애플리케이션 아키텍쳐에 부정적인 영향을 끼칠 수 있다.

선택적으로 타입 시스템을 사용할 수 있다는 것의 의미는 기존의 Javascript 개발 워크플로우도 유지한다는 것을 말한다. 코드 베이스의 상당한 부분이 손상될수도 있지만, 여전히 애플리케이션을 실행할 수 있다. 그 이유는 TypeScript는 타입 체커가 에러나 경고를 보여주더라도 Javascript를 생성하는 작업은 유지하기 때문이다. 이러한 점은 개발 시에 매우 편리한 부분이다.

 

왜 TypeScript인가?

오늘날 프론트엔드 개발에는 ES5, ES6 (Babel), TypeScript, Dart, PureScript, Elm등 선택 가능한 옵션들이 너무나 많이 있다. 그럼에도 불구하고 왜 TypeScript인가?

ES5부터 살펴보자. ES5는TypeScript 대비 한가지 명백한 장점이 있는데 그것은 ES5는 transpiler가 필요 없다는 점이다. 이러한 점은 애플리케이션의 개발환경 셋팅을 단순화 시켜준다. 여러분은 파일 변화를 감지할 watcher, transpiler, source map 파일의 생성 등을 셋팅할 필요가 없다. 바로 개발하면 될 뿐이다.

ES6는 transpiler가 필요하기 때문에 개발환경 셋팅이 필요하다는 점에서 TypeScript와 크게 다르지 않지만 ES6는 Javascript 표준이고 이는 일반적인 모든 에디터와 빌드 툴에서 ES6를 지원하거나 지원하게 될것 임을 의미한다. 그렇지만 이러한 점은 현재 대부분의 에디터에서 TypeScript를 훌륭하게 지원하고 있다는 사실을 볼 때 약점이 되기도 한다.

Elm과 PureScript는 TypeScript보다 여러분의 프로그램의 관해서 더 많이 점검할 수 있는 강력한 타입시스템을 갖춘 우아한 언어들이다. Elm과 PureScript로 작성된 코드는 ES5로 작성된 코드보다 좀 더 간결하게 작성 가능하다.

위에서 열거한 언어들은 저마다 장단점을 가지고 있다. 그러나 나는 TypeScript가 대부분의 프로젝트에서 적절한 선택이 될 수 있는 상당히 매력적인 지점에 서 있다고 생각한다. TypeScript는 정적 타입 언어로부터 95% 가량의 특징을 취하여 이를 Javascript 생태계로 유입시켰다. 이는 TypeScript 개발이 마치 ES6로 코드를 짜는 것과 같은 느낌을 가져다 준다. 여러분은 변함없 이 ES6와 동일한 표준 라이브러리를 사용하며 동일한 서드파티 라이브러리를 사용할 수 있고, 관용적인 패턴과 (크롬 개발자도구와 같은) 동일한 도구도 그대로 사용할 수 있다. 이러한 사실은 TypeScript가 여러분을 Javascript 생태계로 부터 벗어나도록 강제하지 않고 기존의 특징을 그대로 안겨다 준다.

저자의 Angular2 Medium: https://vsavkin.com/

Angular2: QuickStart 따라하기

참고: angular2에 대한 연재는 여기를 참조해 주세요. 틀린 부분이나 의견, 피드백은 언제든지 환영합니다. 

들어가기

지난번 에서는 Angular2를 사용하기 위해서 필요한 최소한의 배경 개념을 다루었습니다. 이제 Angular2가 어떻게 생겼는지 눈과 손으로 확인을 해 볼 차례입니다. 첫 예제는 Angular.io 공식 매뉴얼에 있는  5Min QUICKSTART입니다. Angular2 개발환경 셋팅 후 “Hello World” 보는 것이 목표라고 생각하시면 됩니다.

 

매뉴얼대로 묻지도 따지지도 않고 따라하면 정말 5분 안에 뭔가 나오기는 합니다만, 내가 뭘 했는지 이해하기 쉽지 않습니다. 따라서 본 글에서는 퀵스타트 예제와 동일하게 내용을 다루면서도 조금 더 이해하기 쉽도록 내용을 풀어보고자 합니다. 일단은 있는 그대로 따라하며 브라우저에 화면을 띄워 본 후에 다시 처음으로 돌아와 설명을 읽어보시기를 권장합니다.

 

에디터 선택

아무리 퀵스타트라지만 개발을 하려면 연장이 필요하겠지요? 필요한 도구는 Typescript를 지원하는 IDE나 에디터 하나만 있으면 됩니다. 대부분의 유명한 에디터나 IDE가 Typescript용 플러그인을 제공하고 있으므로, 가장 손에 익숙한 것을 사용하셔도 됩니다. 본 연재에서는 ATOM 에디터를 사용합니다. 공식 사이트에서 OS에 맞게 install 파일을 받으시고 정상적으로 설치가 완료되면 아래와 같은 화면을 만날 수 있습니다.

 

first_atom

 

그리고 우측 두번째 버튼 “Install a Package”을 눌러 “atom-typescript“만 설치해 주시면 됩니다.

 

typescript_atom

 

개발환경 구성

개발환경 구성은 다음의 순서로 이루어집니다.

  1. npm 활용을 위한 node 설치
  2. 프로젝트용 빈 폴더 생성
  3. tsconfig.json 파일 생성
  4. typings.json 파일 생성
  5. package.json 파일 생성
  6. npm, typings 패키지 설치

 

Node 설치

공식 사이트에 들어가서 자신의 OS에 맞는 installer를 받아서 설치합니다. node가 정상적으로 설치되면 터미널에서 node와 npm이 정상적으로 설치되었는지 확인합니다.

 

 

node_js

 

폴더 생성

퀵스타트 앱을 작성할 폴더를 하나 생성합니다. 이 글에서는 “follow-quickstart”라는 이름으로 폴더를 생성했습니다. 생성한 폴더를 에디터에서 엽니다.

 

기본 설정 파일 생성

생성한 프로젝트 폴더 follow-quickstart에 tsconfig.json 파일을 만들고 다음의 내용을 복사해서 붙여넣습니다.

 

 

tsconfig.json은 Typescript를 Javascript로 컴파일할 때 적용할 옵션설정을 명시해 둔 파일입니다. 컴파일 할 때 터미널에서 “tsc” 명렁어를 사용해서 컴파일을 하는데 만약 ES5 기준으로 컴파일 하고 싶을 경우 “tsc –target es5″를 입력하면 되는데요. 반복적인 컴파일 옵션은 tsconfig.json에 등록해 두면 터미널에서 불필요하게 파라미터를 추가할 필요가 없습니다. 자세한 컴파일 옵션과 관련해서는 아래의 링크를 참조하면 됩니다.

  • https://www.typescriptlang.org/docs/handbook/compiler-options.html (컴파일 옵션)
  • http://www.typescriptlang.org/docs/handbook/tsconfig.json.html (tsconfig.json 정의)

 

이어서 typings.json 파일을 만들고 역시 다음의 내용을 복사해서 붙여넣습니다.

 

typings는 Typescript를 사용할 때 따라 붙는 필수 툴입니다.  typings에서 대해서 설명하려면 지난 시간에 설명한 Typescript 정의에 대해서 복기해 볼 필요가 있습니다. 지난 글에서 Typescript는 ES5 + ES6 + 타입 등의 추가 Syntax로 이루어진 스크립트 언어라고 설명했습니다. 이 정의에서 중요한 부분은 ECMA에 없는 바로 타입입니다.

 

자 그럼, 질문을 하나 드려보겠습니다. 기존의 Javascript는 타입이 없는데 Typescript로 개발 시 어떻게 jQuery 등의 라이브러리를 어떻게 사용할 수 있을까요? 아니 이 질문 전에 Typescript로 개발하면 기존에 Javascript로 작성된 외부 라이브러리나 코드를 사용할 수가 있는건가요? 질문에 대한 대답은 당연이 “예”입니다. 다만 한 가지 추가적인 작업이 필요합니다. 바로 타입 정보인데요. 만약 우리 소스에 jQuery를 추가로 사용하기로 했는데 타입 정보가 주어지지 않는다면 여러분의 에디터에서는 가차없이 빨간 줄을 jQuery를 사용한 코드에 뿌려줄 겁니다. 아니면 컴파일 시점에 Typescript 컴파일러가 해당 라이브러리를 인식하지 못해 에러를 여러분에게 보여줄 겁니다.

 

Typescript로 개발하는 가장 큰 장점은 정적인 코드 분석 등 IDE와 같은 도구의 지원으로 배포 및 런타임 전에 사전의 발생할 버그나 오류를 잡을 수 있다는 것입니다. 어찌보면 타입이 있는 컴파일 언어에서 당연한 소리이겠지만, 타입이 없었던 Javascript 세상에서는 분명 새로운 이야기임에 틀림 없습니다.

 

처음에 던졌던 질문으로 돌아와서 빨간 줄을 없애기 위해서 추가로 해야할 일이 있다고 말씀 드렸는데요. 그 일은 바로 해당 라이브러리에 타입 정보를 직접 추가해 주는 것입니다. 예를 들어 jQuery의 datepicker를 쓴 다고 가정해 봅시다. 그러면 우리는 아래와 같은 type 정보를 어딘가 선언해 두어야 합니다.

 

 

겨우 하나의 메서드를 선언하는데는 큰 무리가 없지만 jQuery 하나만 해도 적지 않은 메서드가 있는데 일일이 타입정보를 만들려면 힘들겠지요. 다행히도 오픈소스 생태계에서 이러한 작업(이라고 하고 노가다…)를 함께 공유하는 생태계가 있으니 그것이 바로 typings 입니다. 사전 설명이 길었는데 typings는 기존 Javascript 라이브러리들의 타입 정보만을 선언한 파일들을 내려받을 수 있도록 도와주는 툴입니다.

 

NPM을 통해서 우리가 필요한 외부 라이브러리를 쉽게 내려받고 package.json으로 관리하듯이 우리가 필요한 외부 라이브러리의 타입 정보가 필요하다면 “typings install dt~jQuery –save –global” 명령어 하나면 알아서 타입 정보가 담긴 파일을 내려받게 됩니다. –global 옵션은 일단 무시해 주세요. 본 quickstart 예제에서는 typings를 실제로 쓸 일이 없어 다음에 좀 더 자세하게 설명하기로 합니다.

 

마지막으로 package.json 파일을 만들고 다음의 내용을 복사해서 붙여넣습니다.

 

필수 패키지 설치

지난 글에서 설명한 대로 NPM을 통해서 Angular2에 필요한 패키지 목록을 다운받을 수 있도록 package.json에 dependencies와 devDependencies가 선언되어 있습니다. package.json에 라이브러리가 선언되어 있으면 install 명령어로 간단하게 위에 열거된 라이브러리들을 설치할 수 있습니다. 명령을 실행하면 package.json에 등록된 패키지와 각 패키지가 의존하는 패키지까지 설치가 자동으로 진행이 됩니다.

 

 

매뉴얼에도 적혀 있지만 install 명령 시에 터미널에서 “npm WARN”은 무시해도 개발에 문제가 없지만 “npm ERR!”은 보이면 안되는 결과입니다. npm install을 할 때 모두에게 평화가 있기를 바랍니다. 정상적으로 설치가 되었다면 현재 폴더 기준으로 node_module이란 폴더가 생성되고 이 폴더 안에 설치된 패키지들이 위치해야 합니다. 만약 패키지가 로컬 폴더에 정상적으로 설치되었는지 확인하고 싶다면 다음의 명령어로 현재 로컬 폴더에서 사용하는 패키지 목록을 확인할 수 있습니다.

 

 

npm_list

 

이후에 jQuery 등과 같은 외부 패키지가 필요할 때에 NPM을 통해서 패키지 관리가 가능합니다.  다음 기회에 필요한 패키지 설치하는 법을 설명하도록 하겠습니다.

 

Hello Angular2

개발환경 설정에 생각보다 긴 시간이 흘렀습니다. 지금까지 제대로 따라오셨다면 ATOM 에디터에 다음과 같은 폴더 구조가 보여야 합니다.

 

dev_env

 

드디어 Angular2를 만나볼 차례입니다. 위에서 생성했던 폴더 follow-quickstart에 스크립트 소스가 자리할 “app” 폴더를 만들고, 여기에 app.component.ts 란 이름의 파일을 생성 후 아래 코드를 붙여 넣습니다. app.component.ts 파일의 확장자 ts는 Typescript 파일을 의미합니다. 드디어 우리는 첫 번째 Tyescript로 만들어진 Angular2 소스를 만나게 되었습니다.

 

 

ATOM 에디터 설치 후 “atom-typescript” 패키지가 정상 설치가 되었다면 에디터에서 자동으로 ts파일을 컴파일 하여 app.component.ts외에 app.component.js와 app.component.map 파일을 생성해 줍니다. 어떻게 ts 확장자의 스크립트 소스가 js로 변환되는지 궁금하신 분들은 한번 확인해 보셔도 됩니다. 우리에게 익숙한 ES5형태의 자바스크립트 소스를 만날 수 있습니다. (map 파일은 디버깅 용도를 위한 추가 정보로 필수 요건은 아닙니다.)

 

first_compile

 

우리는 방금 Typescript로 짠 최초의 Angular2 컴포넌트를 만들었습니다. Angular 앱은 기본적으로 Tree 구조를 갖고 있으며 따라서 반드시 적어도 하나의 최상위 부모 컴포넌트가 있어야만 합니다. 방금 여러분이 작성한 소스가 이 부모 컴포넌트에 해당합니다. 컴포넌트는 웹앱 개발 뷰 템플릿을 관리하는 하나의 독립된 정도로 생각하면 좋을 것 같습니다. “컴포넌트”의 의미에 대해서는 추후에 다시 설명하도록 하겠습니다.

 

첫 컴포넌트 작성에 사용된 소스를 한 번 살펴보도록 하겠습니다. 먼저 관례적으로 최상위 컴포넌트를 AppComponent라고 이름 짓습니다. 소스 내용을 보면 생소한 부분들이 많이 있는데요. 여기서 주의하셔야 할 부분이 위 소스의 대부분이 이번에 ES6에 새로 추가된 자바스크립트 문법 이라는 점입니다.  Typescript나 Angular2에서만 문법이 아니라는 뜻입니다.

 

먼저 첫 번째 줄의 import는 ES6에서 추가된 대표적인 문법으로, Javascript 모듈을 불러올 때 사용합니다. Javascript 진영에서 모듈화와 관련된 여러 개별적인 움직임들이 있어 왔는데요. 드디어 언어적으로는 ES6에서 공식 지원이 됩니다.  Angular 역시 모든 요소들이 모듈화 되어 있고, 필요한 것은 반드시 import한 후에 사용이 가능합니다. Javascript의 모듈과 관련한 자세한 내용은 이후에 다루도록 합니다.

 

@Component는 데코레이터라고 하며, 앞으로 Angular 앱 개발 시 자주 보게 될 부분입니다. @Component안에 정의된 객체가 Angular에게 어떤 뷰 템플릿을 사용할지, 어떻게 컴포넌트를 생성할 지 등 메타 정보를 담고 있습니다. 위에서 selector의 의미는 이 컴포넌트가 갖게될 tag의 이름을 지칭하고, template은 유추할 수 있듯이 실제 컴포넌트가 렌더링 될 템플릿 정보입니다.

 

마지막으로  export class AppComponent를 한 번 분석해 봅시다. 이 문장에 총 3개의 단어가 있는데요. 뒤에서 부터 다음과 같이 읽을 수 있습니다.

  1.  “AppComponent”라는 이름의
  2. 클래스를 선언하고
  3. 이 클래스를 외부에 모듈로 공개

클래스 역시 ES6에 정식으로 추가된 것입니다. 눈치가 빠르신 분들은 아실 수도 있겠지만 클래스 선언 앞에 export가 붙는 순간 다른 파일(모듈)에서 위에서 설명한 import가 가능합니다. 자 그럼 한 번 AppComponent를 import 해볼까요?

 

Bootstraping

위에서 생성한 AppComponent는 우리가 QuickStart에서 사용할 루트 컴포넌트임을 설명했습니다. 그런데 어떻게 이 루트 컴포넌트를 실행시킬까요? Angular의 최초 진입점이 어디일까요? 이제 우리는 진입점 역할을 하는 소스가 하나 더 필요합니다. 진입점 역할을 하는 파일 main.ts를 만들어 봅시다.

 

 

처음 AppComponent 소스 보다는 눈에 좀 더 들어오지 않나요? Angular에서는 최초 실행을 위해서 bootstrap 메서드를 제공하고 있고, 이를 사용하기 위해서 역시 bootstrap을 import하고 있는게 눈에 들어오네요. import의 출처를 보면 ‘@angular/platform-browser-dynamic’으로 되어 있는데요. 이는 angular2가 bootstrap 될 환경이 browser에만 국한되지 않는다는 것을 보여줍니다.즉  bootstrap될 환경에 따라 다른 bootsrap 메서드를 import할 수가 있습니다. 예를 들면, 현재 Angular2는 네이티브 앱 및 서버 렌더링까지 지원을 가지고 있습니다.

 

Index.html

마지막으로 지금까지 작성한 두 소스를 실제 웹페이지에서 실행해 봅시다. 우리가 작성한 AppComponent 실행을 위해 다음의 index.html 파일을 프로젝트 폴더에 하나 생성합니다. (app 폴더 밑이 아닙니다.)

 

 

주석에 이미 적혀 있듯 index.html 안에도 설명이 필요한 부분이 세가지가 있습니다.  먼저 Angular2에서 필요로하는 의존 스크립트를 로드하는 것입니다. 각각의 용도는 다음과 같습니다.

  • es6-shim: 지난 시간에 설명하였던 내용으로 브라우저에서 지원하지 않는 es6 기능 지원을 위한 스크립트
  • zone.js: Angular2 에서 이벤트 detecet를 위해 사용하는 필수 라이브러리, 추후에 자세히 설명
  • Reflect.js: Angular2 에서 사용하는 @(데코레이터)를 위한 필수 라이브러리
  • System.js: Angluar2 모듈 로더

 

System.js

System.js는 우리가 app 폴더 하위에 작성한 Angular2 앱 모듈을 브라우저에서 실제 로딩하기 위한 툴로 쓰입니다. Javascript에서 모듈의 개념은 AMD, CommonJS과 같은 방식으로 이미 있던 개념이지만 위에서 잠깐 맛 본 import, export와 함께 ES6를 통해서 이제 언어에서 공식적으로 지원하게 되었습니다. Angular2 에서는 특정 모듈 로더를 사용하도록 제한하고 있지 않지만 간단한 예제용으로  System.js를 사용하고 있습니다. 본 연재에서는 추후에 System.js대신 webpack을 설명할 예정입니다.

 

일단 모듈 로더가 정상적으로 동작하기 위해서도 필요한 설정이 있습니다. 이를 위해 프로젝트 루트 폴더에 systemjs.config.js  파일을 생성 후에 아래 내용을 붙여 넣습니다. systemjs.config.js 파일의 내용을 보면 결국 사용할 패키지 선언과 실행할 앱을 설정하는 내용에 불과합니다. 지금은 자세한 내용을 이해하려 하기 보다는 모듈을 로드하기 위한 설정이 필요하다는 점만 인식합니다.

 

지금까지 index.html의 1,2번 주석에 대한 내용을 설명하였고 이제 마지막으로 다음의 내용만 확인하면 됩니다.

 

 

body 태그 안에 “my-app”이란 태그는 우리가 제일 처음 작성한 AppComponent의 “selector”에서 선언한 태그명과 동일하다는 것을 알고 있습니다. 여러분이 예측하시는 것과 같이 my-app이란 태그는 Angular2는 selector에 있는 태그명과 연결되어 실제 렌더링 시에는 AppComponent의 템플릿이 my-app 태그 위치에 자리하게 됩니다.

 

마지막으로 index.html에 styles.css가 import되어 있는데, styles.css 파일을 생성 후 공식 사이트에 있는 css를 그대로 옮겨 놓습니다.

 

 

이제 모든 작업이 끝났습니다! 터미널 창에서 다음과 같은 명령어를 통해서 간단한 http 서버를 띄워서 결과를 확인할 수 있습니다.

 

 

package.json에 “scripts” 속성에 이미 “start”라는 명령 스크립트가 선언되어 있습니다. 이 명령은 “tsc” 명령으로 타입스크립트를 컴파일하면서 동시에 “concurrently” 명령을 통해서 “npm run tsc:w”와  “npm run lite”명령까지 병렬적으로 실행합니다.

“tsc:w”는 타입스크립트 컴파일을 watch 모드로 계쏙 실행하는 코드이고, “lite” 명령은 devDependency에 선언되어 있는 “lite-server”  http 서버를 실행하는 명령어 입니다. 따라서 명령을 수행하면 자동으로 http서버가 실행되고 매뉴얼에서 볼 수 있는 것과 동일한  화면을 만날 수 있습니다.

 

 

한번 AppComponent 안에 template을 여러분의 기호에 따라 변경해 보시고 실제 브라우저에 반영되는지 확인해 보시기 바랍니다.

여기까지 따라오셨으면 이 예제의 폴더 구조는 다음과 같을 것입니다.

first_app_structure

 

정리하기

오늘은 Angular2 공식 예제 첫 번째인 Quickstart를 함께 따라해 보았습니다. 영어가 편한 분들은 사실 직접 매뉴얼을 읽으셔도 무방합니다. 그러나 이 연재의 서두에서 말씀드렸던 것처럼 다양한 개념들이 한 꺼번에 쏟아져 나오기에 읽어도 내용이 한 눈에 들어오지 않을 수 있습니다. 따라서 본 글에서는 각 내용을 너무 깊이 다루지는 않으면서도 최소한 예제를 이해하는데 도움을 줄 수 있는데까지 설명하는 것을 목적으로 하고자 노력했습니다.

 

워낙 여러 개념들이 쓰이다 보니 부족한 부분이나 잘못된 부분이 있을수도 있습니다. 또한 현재 angular.io 사이트의 가이드라인도 수시로 업데이트 되고 있어 본 포스팅의 내용과 달라진 것도 있을 수 있기에 의견 및 질문은 언제든 환영입니다.

Angular2 글 목록보기

Angular2 시작하기

2016년 새해 Angular 2가  5월 3일 기준 Release Candidate 버전으로 변경이 되었습니다. 그래서 지난  3개월여 동안 실제 프로젝트에 적용한 경험을 바탕으로 Angular2 대한 글을  써보려고 합니다. 관련된 글 목록은 Angular2 글 목록보기 에서 확인해 주세요.

 

Angular2 프레임워크는 최신 웹프론드 기술을 기반으로 웹 개발을 좀 더 구조적으로 할 수 있는 환경을 제공해 줍니다. 따라서 기존에 서버 개발만 주로 하셨던 분들도 Angular2를 사용하면 좀 더 쉽고 재미있게 웹앱을 개발할 수 있습니다. 갈수록 뜨거워지는 프론트엔드 기술에 눈독 들이고 계셨다면 이번 기회에 Angular2를 학습해 보는 것도 좋은 기회가 될 것 같습니다.  글의 대상 독자가 HTML과 DOM, 자바스크립트 대한 기본적인 지식과 사용 경험을 가지고 있다는 것을 전제로 합니다.

 

오늘은 Angular2 기반의 웹 어플리케이션 개발을 하기 위해서 필수적으로 짚고 넘어가야 할 프론트엔드 웹기술의 배경을 다루는 것으로 시작합니다.

 

Background

Angular2를 공부하기로 마음 먹고 공식 사이트의 튜토리얼매뉴얼을 읽다 보면 “이거 무슨 소리지…” 하는 생각이 들지도 모르겠습니다. Angular2라는 고지를 제대로 점령하기 위해서는 Divide And Conquer의 전략적 접근이 필요합니다.  Angular2 프레임워크 안에 이미 최신의 프론트 엔드 기술과 개념들이 어우려저 사용되고 있기 때문에 우리는 이 개념들을 하나씩 이해하고 넘어가야 합니다. 따라서 Angular2를 사용하려면 적어도 아래와 같은 키워드를 한 번씩 훑어보지 않을 수 없습니다.

  • NPM
  • ES6와 Module(CommonJS, AMD…)
  • Transpiler(Polyfill, shim)
  • TypeScript, (typings, tsd)
  • Angular 프레임워크 관련 개념: MVVM, Change Detector, Observable, Immutable, Two-way Binding, Zone.js
  • RxJs
  • Webpack 등의 Bundler

위에서 열거한 키워드 중에서 본 글에서는 NPM부터 Typescript까지 Angular2를 맛보기 전 프론트엔드 웹 개발 환경을 살펴보도록 합니다.

 

NPM

NPM은 Node Package Management의 약자로 자바스크립트로 쓰여진 패키지 (혹은 라이브러리) 관리 도구 입니다. NPM에 Node가 붙어 있어서 NodeJs를 공부해야만 하는 것은 아닙니다.  또한 NPM은 Angular2 만을 위한 툴도 아닙니다. NPM은 광활한 오픈소스 세계에서 다앙햔 자바스크립트 패키지들을 버전별 의존성 이슈 없이 편리하게 관리하기 위한 툴입니다. Java 에 익숙하신 분들이라면 NPM을 메이븐이나 그래들 정도로 생각하셔도 됩니다.

 

NPM을 통해서 사용할 패키지는 package.json 파일에 정의 되어 있습니다. Angular2가 사용하는 핵심 패키지 정보 역시 package.json 파일에 있습니다. 대표적으로 SystemJs, RxJs 등이 그 예입니다. 다음은 실제 QuickStart에서 볼 수 있는 Angular2의  pacakge.json 파일 내용입니다.

 

 

설정에서 “dependencies”와 “devDependencies”에 각각 Angular2에서 필요로하는 패키지들이 선언되어 있습니다. 속성명에서 유추할 수 있듯이 “dependencies”에 등록된 패키지는 Angular2에 필수 의존 패키지이고 “devDependencies”는 개발에 부가적으로 필요하지만 실제 앱 결과물에는 필요하지 않은 패키지들을 넣습니다.

 

NPM은 패키지 관리 기능 외에 특정 작업을 수행할 스크립트 명령어를 등록할 수 있습니다. 이 명령어는 “scripts” 속성 안에 열거 합니다.  “scripts” 속성 안에 선언된 명령어는 “npm run (명령어)” 형태로 쉘에서 실행이 가능합니다. NPM과 관련된 기본 명령 스크립트는 이후에 다시 설명하기로 하고, 일단 지금은 NPM이 여러분이 만들 웹 애플리케이션에서 필요한 외부 자바스크립트 패키지들을 관리해주는 도구로 생각하는 걸로 합니다.

 

ES6

Java 언어에도 언어를 구성하는 스펙의 버전이 있는 것처럼 자바스크립트에도 버전이 있다는 것을 혹시 알고 계셨나요? ES6는 ECMA Script6의 약자로 현재 우리가 브라우저에서 사용하는 자바스크립트의 표준의 버전명입니다. 자바스크립트 표준을 제정하는 ECMA와 상당히 오랜만에 확정(작년 6월)된 ES6는 자바스크립트에 참 많은 변화를 가져왔는데요. 그래서 아직 ES6 스펙을 브라우저들이 100% 지원하고 있지는 않습니다. 그래서 각 브라우저마다 그리고 버전 별로 어느 정도 까지 ES6를 지원하는지를 나타내는주는 아래와 같은 사이트도 있습니다.

 

es6_browser_support

Transpiler

생각보다 ES6에 대한 구현이 아직은 충분하지 않은 상황인데요. 그렇다고 해서 ES6를 쓸 수 없는 것은 아닙니다. 아직 브라우저에서 미구현된 언어의 기능을 보완해 주기 위한 polyfill이나 shim이라는 postfix가 붙은 라이브러리들이 있습니다. 네이버 영어사전을 찾아보니 polyfill은 사전적 적의가 “충전솜”이고, shim은 “(두 사물 사이의 틈새 등에 끼우는) 끼움쇠”라네요. 이런 류의 라이브러리들은 대개 브라우저가 미지원하는 기능을 스크립트로 지원하기 위한 용도라는 것을 참고로 알아두시면 될 것 같습니다.

 

이런 라이브러리말고 직접 스크립트를 변경하는 transpiler가 있습니다. compiler는 익숙하지만 transpiler라는 용어는 익숙치 않을 수도 있는데요. 하나의 언어를 다른 형태의 언어로 변환해 주는 기능을 부각시키는 표현으로 compiler라는 표현보다 transpiler라는 표현을 쓰는 것으로 추측되는데, 실상 하는 일은 브라우저가 아직 지원하지 못하는 스펙의 자바스크립트 소스를 현재 브라우저가 지원하는 ES5 기준의 소스로 변환해주는 것입니다. 대표적인 transpiler로 React 덕을 좀 본게 아닌가 싶은 Babel이 있습니다. ECMA와 자바스크립트의 역사나 그 기원(?)이 궁금하신 분들은 온라인에서 무료로 볼 수 있는 Speaking Js 챕터 4장을 참조하시면 도움을 얻을 수 있습니다.

 

Typescript

Angular2는 아래 매뉴얼에서 볼 수 있듯이 Javascript, Dart, Typescript, 까지 총 3가지 언어로 개발할 수 있도록 지원합니다. 선택한 언어에 따라 매뉴얼의 예제도 당연히 다르게 나옵니다.

 

angular2_doc_type

Dart는 구글에서 야심차게 내놓은 언어지만 적어도 국내에서의 사용자가 많지 않으니 (라기 보다는 제가 잘 모르니…) 앞으로 이 블로그 포스트에서는 논외로 합니다. 그럼 이제 자바스크립트 말고 남은 하나 Typescript가 있네요!

 

Typescript는 Microsoft에서 만든 언어입니다. 공식 사이트에서는 Typescript를 이렇게 소개하고 있습니다.

Typescript is typed super set of Javascript that compiles to plain Javascsript.

공식적인 정의는 그렇고 3개월 정도 써보면서 느낀 점은자바스크립트에 “타입”을 추가해서 만든 확장형 자바스크립트 언어라고 볼 수 있습니다.  (똑같은 말인가?..) 자! 이쯤에서 Angular2 개발하기도 전에 Javascript냐 Typescript냐 선택을 해야하는 상황이 놓여있는데요. Angular2 하나 써 보자고 Typescript라는 새로운 언어를 배워야 하는거냐는 질문을 하실 수도 있으시겠지만, 우리는 Typescript를 선택해서 앞으로 Angular2를 개발하기로 합니다. 새로운 것을 배운다면 그에 따른 이점이 있어야 할텐데요. 일단은 Typescript를 만든 사람들이 설명하는 Typescript에 대한 소개 영상을 참고로 한번 보시면 동기부여가 됩니다.

 

 

다만 아쉬운 점은 영상이 영어라서 한글 자료는 없는데요. 아래 그림을 보면 훨씬 Typescript의 위치가 어디에 있는지 도움이 될 것 같습니다.

 

참조: Typescript Won (링크는 하단 참조)

 

보시다시피 Typescript는 새로운 언어라기 보다는 기존의 자바스크립트(ES5)와 위에서 설명한 ES6 스펙에 type과 관련된 추가적인 syntax가 추가된 언어입니다. 따라서 학습곡선이 그렇게 높지 않아 꼭 권하고 싶습니다. 왜냐하면 그림이 이미 설명하듯이 Typescript를 쓰다 보면 자연스럽게 최신의 자바스크립트 Syntax에 익숙해 질 수 있기 때문입니다. 시간날 때 틈틈히 매뉴얼 한 번 읽으면 누구나 Typescript를 쓸 수 있습니다. Typescript를 사용해야 하는 또 다른 이유는 실제로 Angular2 프레임워크 자체도  Typescript로 쓰여져 있기 때문입니다.  이 내용이 지난해 3월 MSDN에 공식 발표되기도 했었지는데요. 오프라인 상에서도 Angular 개발팀과 Typescript 팀이 활발하게 교류하고 있다고 합니다. Angular2에서 Typescript를 얼마나 활발하게 쓰는지 보여주는 단적인 예가 데코레이터라고 하는 문법입니다.  하단의 코드 샘플에서 @Component… 문법이 데코레이터라고 하는 것인데, 아직 Typescript 정식 문법은 아니고 실험버전이라 반드시 Typescript 컴파일 설정에 emitDecoratorMetadata를 “true”로 해줘야 합니다.

 

 

지금은 무슨 내용인지 이해하려고 노력하지 않으셔도 됩니다. 요지는 Angular2는 Typescript를 아주 깊게 사용하고 있으며, Typescript가 가진 장점이 많기 때문에 우리도 Typescript로 Angular2를 개발하자는 것입니다.

 

이번 글에서는 Angular2를 본격적으로 개발하기에 앞서 Angular2를 둘러싼 기반 기술과 개념 중 일부인 NPM, ES6, Transpier, Typescript까지 살펴보았습니다. 이어지는 포스팅에서 본격적으로 Typescript를 사용하여 간단한 Todo App을 작성해 보고, Angular2의 기본 배경 및 개념을 다루도록 하겠습니다. 추가로 아래는 3개월여 공부하면서 참조한 자료들을 첨부하였습니다. 그럼 다음 포스팅에서 뵙겠습니다.

Angular2 글 목록보기

참고 링크

  • http://ngcourse.rangle.io/handout/why_angular_2.html (Angular2 학습에 필요한 전반적인 기술 다룬 내용, 강추)
  • https://angular.io/docs/ts/latest/tutorial/ (공식 튜토리얼)
  • http://victorsavkin.com/ (angular2 개발 커밋 1등공신의 블로그, angular2 동작원리 잘 설명되어 있음
  • http://blog.thoughtram.io/categories/angular-2/ (angular 전문 컨설팅 독일 회사 블로그 내용 설명 좋음)
  • http://seokjun.kr/ecmascript-6-features/ (ECMA6 간략 설명)
  • http://xgrommx.github.io/rx-book/ (Rx.js 설명: Angular2 에서 아주 열심히 Rx.js 씀)
  • http://rxmarbles.com/ (Rx 이해를 돕는 애니매이션 사이트)
  • http://mobicon.tistory.com/category/Angular.io (한글 개인 블로그)
  • http://es6-features.org/#StatementBodies (ES6 와 ES5 코드 비교)
  • https://kangax.github.io/compat-table/es6/ (ES6 브라우저호환성)
  • http://han41858.tistory.com/3
  • http://sculove.github.io/slides/2016_FETrend/#/
  • https://kangax.github.io/compat-table/es6/
  • https://medium.com/@basarat/typescript-won-a4e0dfde4b08#.2xxoq0vo8 (Typescript Won)
  • https://www.gitbook.com/book/basarat/typescript (Typescript 학습자료)

영상 참고

2015년 angular 컨퍼런스에서 창시자가 angular2의 개념에 대한 설명