Programmazione di Ku0re

Angular 2를 공부하려 했더니 Angular 4 등장? 본문

Programmazione/Angular

Angular 2를 공부하려 했더니 Angular 4 등장?

ku0re kuore 2017. 4. 27. 22:35


Angular2 공부를 하려고 하자 갑자기 튀어 나온 Angular 4에 대하여


첫 포스팅은 요즘 가장 핫한 Frontend Framework 중 하나인 구글의 Angular를 공부하는 과정을 담을 생각이다.


사실 처음 Angular를 공부하려고 검색하는 중 Angular 2에서 Angular 3도 아닌 4가 나왔다는 말에 당황했다.


갑자기 Angular 3을 건너 뛰고 4가 나온 이유를 살펴보기 위해서 먼저 Angular js 1.x와 Angular 2에 대해 조사해보기로 했다.


먼저 인터넷 강의 중 가장 많은 것은 Angular js 1.x 이다. Angular 2가 더 핫하지만 Angular 2의 강의가 찾기 쉽지 않았다.


그래서 인프런의 강의 중 Angular js 1.x 강의를 봐야하나 했다.


하지만 여러 검색 중 알게 된 게 Angular js 1.x과 Angular 2는 엄밀히 다른 프레임워크라고 한다.


그래서 Angular js 1.x의 강의는 우선 보류하기로 했다.


그럼 Angular js1.x과 Angular 2의 차이는 무엇인가?


(아래 내용은 한장현님의 블로그의 내용이다.)




Angular js 1.x의 한계와 Angular 2로의 변화


Angular js 1.x의 한계


먼저 Angular js1.x의 한계는 아래와 같다.

 간단하게 말해서, 구글팀이 Angular 1.x를 맡은 이후, 개발자들이 원하던 최신 기법을 Angular에 도입하려고 하면서 Angular 1.x를 재작성할 수 밖에 없었다. 일부를 살펴보자면,

  • Angular 1.x는 서버렌더링을 할 수 없다.
  • Angular 1.x 코드는 네이티브 코드로 변환할 수 없다.
  • 어떤 환경에서는 잘 동작하지 않기도 한다.
 Angular 1.x의 한계에 대한 이야기에서 DOM을 처리하는 과정이 빠질 수 없다. Angular 는 이미 있는 DOM을 기반으로, 기능을 확장시키는 방식이었기 때문이다.

 Angular 2는 이런 한계를 극복하기 위해 만들어졌다. 기존에 있던 코드를 기반으로 새로운 API를 추가하는 것만으로는 구조적인 한계를 벗어나기 쉽지 않았고, Angular 2를 만들면서 코드의 기본 구조부터 크게 바꾸게 된다.



출처: http://han41858.tistory.com/25 [한장현입니다.]

출처: http://han41858.tistory.com/25 [한장현입니다.]

 간단하게 말해서, 구글팀이 Angular 1.x를 맡은 이후, 개발자들이 원하던 최신 기법을 Angular에 도입하려고 하면서 Angular 1.x를 재작성할 수 밖에 없었다. 일부를 살펴보자면,

  • Angular 1.x는 서버렌더링을 할 수 없다.
  • Angular 1.x 코드는 네이티브 코드로 변환할 수 없다.
  • 어떤 환경에서는 잘 동작하지 않기도 한다.
 Angular 1.x의 한계에 대한 이야기에서 DOM을 처리하는 과정이 빠질 수 없다. Angular 는 이미 있는 DOM을 기반으로, 기능을 확장시키는 방식이었기 때문이다.

 Angular 2는 이런 한계를 극복하기 위해 만들어졌다. 기존에 있던 코드를 기반으로 새로운 API를 추가하는 것만으로는 구조적인 한계를 벗어나기 쉽지 않았고, Angular 2를 만들면서 코드의 기본 구조부터 크게 바꾸게 된다.



출처: http://han41858.tistory.com/25 [한장현입니다.]

출처: http://han41858.tistory.com/25 [한장현입니다.]

간단하게 말해서, 구글팀이 Angular 1.x를 맡은 이후, 개발자들이 원하던 최신 기법을 Angular에 도입하려고 하면서 Angular 1.x를 재작성할 수 밖에 없었다. 일부를 살펴보자면,

  • Angular 1.x는 서버렌더링을 할 수 없다.
  • Angular 1.x 코드는 네이티브 코드로 변환할 수 없다.
  • 어떤 환경에서는 잘 동작하지 않기도 한다.
 Angular 1.x의 한계에 대한 이야기에서 DOM을 처리하는 과정이 빠질 수 없다. Angular 는 이미 있는 DOM을 기반으로, 기능을 확장시키는 방식이었기 때문이다.

 Angular 2는 이런 한계를 극복하기 위해 만들어졌다. 기존에 있던 코드를 기반으로 새로운 API를 추가하는 것만으로는 구조적인 한계를 벗어나기 쉽지 않았고, Angular 2를 만들면서 코드의 기본 구조부터 크게 바꾸게 된다.



출처: http://han41858.tistory.com/25 [한장현입니다.]

간단하게 말해서, 구글팀이 Angular 1.x를 맡은 이후, 개발자들이 원하던 최신 기법을 Angular에 도입하려고 하면서 Angular 1.x를 재작성할 수 밖에 없었다. 일부를 살펴보자면,

  • Angular 1.x는 서버렌더링을 할 수 없다.
  • Angular 1.x 코드는 네이티브 코드로 변환할 수 없다.
  • 어떤 환경에서는 잘 동작하지 않기도 한다.
 Angular 1.x의 한계에 대한 이야기에서 DOM을 처리하는 과정이 빠질 수 없다. Angular 는 이미 있는 DOM을 기반으로, 기능을 확장시키는 방식이었기 때문이다.

 Angular 2는 이런 한계를 극복하기 위해 만들어졌다. 기존에 있던 코드를 기반으로 새로운 API를 추가하는 것만으로는 구조적인 한계를 벗어나기 쉽지 않았고, Angular 2를 만들면서 코드의 기본 구조부터 크게 바꾸게 된다.



출처: http://han41858.tistory.com/25 [한장현입니다.]

간단하게 말해서, 구글팀이 Angular 1.x를 맡은 이후, 개발자들이 원하던 최신 기법을 Angular에 도입하려고 하면서 Angular 1.x를 재작성할 수 밖에 없었다. 일부를 살펴보자면,

  • Angular 1.x는 서버렌더링을 할 수 없다.
  • Angular 1.x 코드는 네이티브 코드로 변환할 수 없다.
  • 어떤 환경에서는 잘 동작하지 않기도 한다.
 Angular 1.x의 한계에 대한 이야기에서 DOM을 처리하는 과정이 빠질 수 없다. Angular 는 이미 있는 DOM을 기반으로, 기능을 확장시키는 방식이었기 때문이다.

 Angular 2는 이런 한계를 극복하기 위해 만들어졌다. 기존에 있던 코드를 기반으로 새로운 API를 추가하는 것만으로는 구조적인 한계를 벗어나기 쉽지 않았고, Angular 2를 만들면서 코드의 기본 구조부터 크게 바꾸게 된다.



출처: http://han41858.tistory.com/25 [한장현입니다.]
    • Angular js 1.x는 서버 렌더링을 할 수 없다.
    • Angular js 1.x는 네이티브 코드를 변환할 수 없다.
    • 어떤 환경에서는 잘 동작하지 않기도 한다.


Angular js 1.x는 DOM을 처리하는 과정에서 그 기능을 확장하는 방식이었는데, 기존에 있던 코드를 기반으로 새로운 API를 추가하는 것 만으로는 구조적인 한계를 벗어나기 쉽지 않았고, Angular 2는 이런 한계를 극복하기 위해 만들어졌다.  따라서 Angular 2를 만들면서 코드의 기본 구조부터 크게 바꾸게 된다.



Angular 2

Angular 1.x의 한계에 대한 이야기에서 DOM을 처리하는 과정이 빠질 수 없다. Angular 는 이미 있는 DOM을 기반으로, 기능을 확장시키는 방식이었기 때문이다.
Angular 2는 이런 한계를 극복하기 위해 만들어졌다. 기존에 있던 코드를 기반으로 새로운 API를 추가하는 것만으로는 구조적인 한계를 벗어나기 쉽지 않았고, Angular 2를 만들면서 코드의 기본 구조부터 크게 바꾸게 된다.


출처: http://han41858.tistory.com/25 [한장현입니다.]

출처: http://han41858.tistory.com/25 [한장현입니다.]
 Angular 1.x의 한계에 대한 이야기에서 DOM을 처리하는 과정이 빠질 수 없다. Angular 는 이미 있는 DOM을 기반으로, 기능을 확장시키는 방식이었기 때문이다.

 Angular 2는 이런 한계를 극복하기 위해 만들어졌다. 기존에 있던 코드를 기반으로 새로운 API를 추가하는 것만으로는 구조적인 한계를 벗어나기 쉽지 않았고, Angular 2를 만들면서 코드의 기본 구조부터 크게 바꾸게 된다.



출처: http://han41858.tistory.com/25 [한장현입니다.]
Angular 1.x의 한계에 대한 이야기에서 DOM을 처리하는 과정이 빠질 수 없다. Angular 는 이미 있는 DOM을 기반으로, 기능을 확장시키는 방식이었기 때문이다.
Angular 2는 이런 한계를 극복하기 위해 만들어졌다. 기존에 있던 코드를 기반으로 새로운 API를 추가하는 것만으로는 구조적인 한계를 벗어나기 쉽지 않았고, Angular 2를 만들면서 코드의 기본 구조부터 크게 바꾸게 된다.



출처: http://han41858.tistory.com/25 [한장현입니다.]

출처: http://han41858.ti


Angular 2가 만들어진 것은 위에 있던 이유 외에 $scope 를 없애려는 것도 있었다. $digest 사이클을 통한 값 변경 체크 방식은 항상 성능의 약점으로 꼽혔기 때문에, 값 변경 체크 방식을 $digest 사이클 밖으로 빼내려고 했다. Angular 1.x의 코드 구조는 몇몇 중요한 이슈로 인해 그대로 사용하기 어려웠고 이후 버전을 위해 바뀌었다고 한다.


이러한 과정 때문에 Angular 2가 등장하게 된다. Angular2를 사용하면서 우리는 크로스 플랫폼의 렌더링 스케일 확장 문제, 속도, 성능 등 모든 것을 자유롭게 사용할 수 있다.


결론은 Angular js 1.x에서 Angular 2로 변하면서 코드를 재 작성했다고 할 정도로 크게 내용이 바뀐다. 새로운 개발 언어를 사용하거나 컴포넌트의 구성 방식이 바뀌고, 아키텍처, 사용하는 툴도 모두 다르다.



SemVer와 큰 변화(Breaking Changes)


Angular js 1.x


Angular 1.x는 몇 년 동안 수많은 버전들과 수많은 큰 변동 사항이 있었다. 1.x 변경 이력은 Angular js 1.x Github에서 찾아 볼 수 있다.



Angular 2와 Angular 3


이미 Angular 4가 나온지는 두 달이 다 되어간다.

나도 그랬지만 다른 분들도 처음엔 많이 혼란스러웠다고 한다.


먼저 Angular 2는 완전히 새로운 패러다임을 도입하기 위해 만들어졌다. 오프라인 컴파일이나 다른 렌더링 방식, 그 이외에 수많은 개선점들을 위해서 말이다.


Angular js 1.x는 기존의 DOM을 기반으로 하기 때문에 DOM이 로드될 때까지 기다리고, 거기에 뭔가를 붙이는 방식으로 동작했다. Angular 2는 반대로 프레임워크로서 템플릿에 대한 온전한 조정 권한을 갖고, 심지어 DOM을 만나지 않더라도 변화 자체를 처리한다.

(Angular js 1.x도 Angular 2도 써보지 않았지만 많은 변화가 있다는 것은 딱 봐도 알 것 같다.)


이 말이 무슨 뜻인지 설명하는 가장 간단한 예제는 컴포넌트가 DOM에 붙기 전에도 처리되는 클릭 이벤트가 있으며, 최종적으로 만들어진 DOM에서 (click)="fooFn()"과 같은 코드를 볼 수 없는 이유는 Angular 2는 자체적으로 이런 이벤트를 연결하고 처리하기 때문이다.


Angular 2 코드의 절반 정도는 내부 컴파일러가 차지하고 있다.(여기서 봐도 기존 DOM에 여러 기능들을 붙혀 사용하던 방식과 다르다는 것을 알 수 있다.)

초기 로드 시점의 성능 향상을 위해 지연 로딩 모듈을 사용하면서 "Ahead-of-Time"이라 불리는 컴파일 방식을 사용하는데, 이 때 사용하는 컴파일러다.


AoT 컴파일 방식을 사용하지 않고 'Just-in-Time" 컴파일 방식을 사용한다면 브라우저로 넘겨야 하고 이러면 전송되는 코드가 많아질 것이다. AoT 접근 방식은 React의 JSX와도 비슷한 점이 있는데, 결국 전처리의 문제다.


Angular 2의 코드 빌딩 방식은 Ahead-of-Time 방식으로 미리 전부 패키징하는 방식과 Just-in-Time 방식으로 필요할 때 필요한 모듈을 패키징하는 방식이 있다. 실제로는 같은 컴파일러를 사용하지만 타이밍과 활용 방식에 따라 구분한다. 클라이언트 입장에서 AoT 방식에서는 전체 코드를 다운 받아 오프라인에서 미리 렌더링하고 화면에 표시할 수 있고, JiT 방식에서는 필요한 라이브러리가 있을 때 해당 모듈을 컴파일해서 사용한다. (생각보다 복잡해보인다. 초보자로서는 대충 알듯 말듯하지만 직접 코딩을 해봐야 그 케이스를 알듯싶다.)


실제 버저닝

(Angular js 1.x에서 2로, 2에서 3, 4로 버전이 바뀐 진짜 이유)


일단. 구글의 버저닝 정책은 이렇다.


Angular 1.x에서는 버저닝 방식이 이랬다.

    • Angular 1.0
    • Angular 1.1 -1.2 지원을 위한 이전 버전
    • Angular 1.2
    • Angular 1.3 - IE8 지원 중단
    • Angular 1.4
    • Angular 1.5


Angular 2에서는 이렇다.

    • Angular 2
    • Angular 3
    • Angular 4
    • Angular 5
    • Angular 6
    • Angular 7


여기서 보면 알 수 있듯이 실제 코드나 구조의 변화와 관계 없이 Angular js 1.x와는 버저닝 전략 자체가 다르다. 구글 팀에서는 이 방싞이 좀 더 알아보기 쉽고, 명확하고, 코드 업데이트에 좀 더 나은 가이드를 줄 수 있다고 판단했기 때문에 이런 버저닝 전략으로 바꿨다고 한다.


Angular 2에서부터 SemVer를 따르면서 버전을 사용하는 철학이 달라지게 되는데, Major, Minor, Patch로 구분하는 SemVer에서 Angular가 2가 됐든 3, 4가 됐든 Major 버전이 바뀔 뿐 이라고 한다.



안정된 API와 실험적인 API


페이지를 방문해 보면, 현재 제공되는 안정된 API가 어떤 것이 있는지 확인할 수 있다. 이 페이지에서는 실험적인 API를 확인할 수 있다. 이 구분은 모든 Angular 문서에서도 확인할 수 있다. 예를 들어 FormGroup은 안정된 API로 구분한다.


구글은 실험적인 API SemVer를 사용하지만 API 관리 정책과는 조금 다릅니다. 실험적인 API를 사용한다면 그 API가 언젠가 변화가 있을 것이라 인지하고 있어야 하고, 어쩌면 실험적인 API로 분류되지 않을 수도 있습니다. 개발자들의 혼란을 막기 위해 이런 부분을 최소화하려고 하고 있고, 모든 API 변화에 대해 문서로 남기려고 합니다.


이런 내용으로 볼 때, 이후 버전의 업그레이드는 간단할 것이다. 구글은 어떤 기능이 실험적인지 좀 더 확실하게 나타내기 위한 방안도 생각하고 있으며 alpha, beta, RC 버전에서 봤던 내용을 쉽게 없애거나 재 작성하지 않을 것이라고 생각해도 좋을 것이다. 구현이 어떻게 되던지 관계없이 API 자체는 안정되었다고 봐도 좋다.


이렇게 적고 보니 크게 걱정할 필요없었구나 싶다.


만약 나와 같이 핫하다고 해서 배우려다가 혼란스러운 버저닝 때문에 망설이지 말고 바로 Angular 4를 배우길 권한다.

Angular 2와 4의 문법적인 차이는 크게 없다고 하니 말이다.


Angular 2에서 버저닝 정책의 변경으로 인해 Major 버전만 변경되는 방식을 사용하였기 때문에 버전이 Angular 2, 3, 4라는 것은 알았다. 그럼 Angular 3가 릴리즈되지 않고 4가 릴리즈 된 것은 왜 그런가?(권윤학님의 블로그 내용)


Angular 3는 @angular/router의 major 버전이 3로 시작되면서 베타 버전으로 준비되고 있었다고 한다. 이건 정확하지 않지만 아마 이 부분 때문에 4부터 다음 major 버전으로 채용된 게 아닌가 싶다.


Angular 버전 업데이트 규칙

    • 매주 패치 릴리즈
    • 각 주요 릴리즈 매월 3회 마이너 릴리즈
    • 마이너 릴리즈가 6개월마다 변경된다.


정말 괜한 걱정을 했구나 싶다.. 사실 핑계일 수도 있는 말이지만 이런 이유 때문에 이전부터 배워야지 생각만 하고 알아보기만 알아보다가 이제서야 시작했다고 할 수 있다. 나는 지금 포트폴리오도 없고 포트폴리오를 하나 만들던 뭐라도 빨리 배워야 겠다 라는 생각만 가득하던 찰나에 스타트업이라도 들어가서 현장에서 해보는 게 더 낫겠거니 하고 몇 군데 찔러봤다. 제일 큰 생각은 사실 취업 먼저 해야겠다는 생각에 찔러봤으나 과제(?), 그 기업에서 필요한 기술 스택 예시 같은 사이트를 알려주며 그런 비슷한 웹사이트를 개발할 수 있는 웹 개발자가 필요하더랬다.


그래서 그 사이트에 들어간 요소들을 이것 저것 조사해서 찾아 붙이고 혼자 조금씩 손 봐서 겨우 하나 첫 개인 프로젝트를, 첫 웹 개발 포트폴리오를 하나 드디어 만들었다. 생각보다 그럴 듯 하다. 물론 내 개인적인 생각엔 :)

(이 포트폴리오는 추후 포트폴리오 카테고리에 포스팅 할 예정)


사실 그 때문에 Angular를 배우는 시간도 늦춰진게 사실이다.(예비군, 누나의 이사 도움 등 개인 사정 포함)

요즘 핫하다는 Angular와 React와 vue.js 모두 배워보고 싶지만 하나도 잘하지 못해서는 이도저도 아닐 듯 싶었다.


나는 아직 하나도 못하지만 주제에 Full Stack 개발자를 목표로 두고 있다. 물론 그래도 밤낮없이 열심히 하고는 있다.

꾸준히 프론트엔드에 대한 포스팅 뿐만 아니라 백엔드, 이전에 공부하던 네트워크, 모의해킹 부분에 대해서도 포스트를 할 계획이다.

첫 포스팅이라 거의 다른 분들의 블로그를 베껴쓴 듯하지만.. 쓰면서 읽는것도 더 공부가 잘 되는 것도 같다.. (언젠간 필력도 좋아지고 내 머릿속의 내용만으로도 저런 글도 쓸 수 있는 날이 오겠지..)


서론이 길고 쓸 데 없는 말이 많았지만 결론은 나처럼 Angular와 React 중 고민하시는 분이 분명히 있을 거다.

나도 아직 공부하진 않았지만 주워 들은 말로는 Angular가 React에 비해서 조금 더 어렵고 복잡하다고 한다. 물론 비교적 말이다.

따라서 React를 먼저 공부한다면 React로 여러가지 할 수 있는데 Angular 까지는 궂이 배우고 싶지 않아진다고 하는 카더라 이다.

만약 고민하시는 분이 있다면 Angular를 공부하고 나중에 React를 공부하는 것을 추천한다.(필자도 그럴 생각이다.)


React 인터넷 강의는 velopert 님 강의가 좋은 것 같다. 목소리도 특이하신데 들을 수록 매력 있더라..(물론 나는 남자다.)

그리고 무려 나보다도 어리시다.. 나만 빼고 대단하셔 다들..


그리고 Angular 2와 4의 문법적 차이는 크지 않다고 하니 4에 대한 자료가 별로 없다면 우선 2를 공부해도 될 것 같다.

단, Angular 1.x 와는 큰 차이가 있으니 가능하면 Angular 2 이상의 자료들로 공부하도록 하자.


모두 열공합시다 :)


마지막으로 제가 베껴쓴(?) 블로그인 한장현 님과 권윤학 님 혹시나 이 글이 문제된다면 수정 및 삭제 하겠습니다.

좋은 정보 감사합니다! (나따위 신경도 안쓰실듯..ㅋㅋ)

0 Comments
댓글쓰기 폼