1. HTML 은 정적인 자료이다.
HTML 은 과학자들이 서로 정보를 공유하기 위해 만들어 졌다.
과학자들이 논문적인 내용을 서로 공개하는 용도였기에 예쁘고 화려한 거 그런 거 없다. 그저 제목, 본문, 이미지 그리고 약간의 스타일 정도가 전부이다. 이를 비유로 이야기 하자면 HTML 는 그저 논문집[책]을 만들기 위한 것이었다.
그런데 WWW 이 인기를 얻고 일반인들은 정적인 책과 같이, 필자가 독자에게 일방적으로 지식을 전달하는 방식을 넘어 상대에 따라 다르게 반응하는 웹페이지가 필요하게 된다.
이때 서버 사이드에서는 CGI, Servlet/JSP, ASP, PHP 등의 기술이 등장한다.
클라이언트 사이드에서는 JavaScript 가 등장한다.
2. 동적인 페이지를 위한 기술 JavaScript
대부분 사용자와의 동적인 작업은 DB에 저장되어 있는 정보를 필요로 했다. 때문에 서버사이드의 동적 스크립트 기술들이 대부분의 일을 하게 된다.
JavaScript 는 단순히 if, for, while 등의 제어문과 alert, confirm, prompt 등의 알림창, 그리고 Form 태그 지원과 간단한 브라우저 이벤트 처리를 위한 단순 기술로만 활용되는 시대였다.
하지만 간단한 작업임에도 JavaScript 는 웹페이지 작성의 필수 기술로 인기를 얻게 되고 아류(?)인 VBS(Visual Basic Script)의 도전을 받게 된다.
더불어 각 브라우저 벤더마다 고유의 기능을 추가한 JavaScript 방언들을 만들게 된다. 또 각각의 브라우저는 JavaScript 를 실행을 위해 서로 다른 자바스크립트 엔진을 사용하게 되니 자바 스크립트 춘추전국시대가 도래한다. 이에 브라우저 마다 자바스크립트를 쓰는 방식이 달라서 익스플로러, 사파리, 파이어폭스, 크롬 등등 각 브라우저에 맞게 자바스크립트를 조금씩 수정해야만 했으니 이를 크로스 브라우징 문제라 한다.
3. JavaScript 표준화하자. ECMASciprt
다양한 자바스크립트 사투리(?)가 난무하자 결국 표준화에 대한 욕구가 발행하니 유럽전자전기협회(ECMA)에 표준을 위한 위원회가 생겨나고 자바스크립트를 표준화해서 발표하니 이것이 바로 ECMASCript 이다.
하지만 문제가 있었다. 표준화 하면 뭐하나 각 브라우저 벤더들이 사용하는 고유의 자바스크립트 엔진들이 ECMAScriipt 를 완벽히 지원하지 못했으니 크로스 브라우징을 지원하기 위해서는 결국 브라우저별로 자바스크립트를 최적화하는 수 밖에 없었다.
4. 크로스 브라우징을 완벽히 해결해 줄 영웅의 등장, jQuery 라이브러리
크로스 브라우징을 위해서는 수 많은 if 문이 필요했고 이는 개발자의 노가다를 더하는 것이 었다. 이때 jQuery 라이브러리가 수 많은 if 문을 블랙박스화 해서 개발자가 단일한 방법을 사용해도 대부분의 메이저급 브라우저들에서 전혀 문제없이 자바스크립트를 구동하게 해주니 jQuery는 춘추전국시대라는 난세에 천하통일의 위업을 달성하여 클라이언트 사이드 개발자들에게 영웅으로 등극한다.
또한 jQuery 는 CSS 와 같은 형식의 선택자를 사용하여 DOM - 문서 객체 모델 (Document Object Model)을 손쉽게 선택하고, 이를 제어할 수 있는 방법까지 제공하게된다. 이에 jQuery 를 향한 칭송은 하늘 아래 따를 자가 없더라.
5. 라이브러리 넘어 프레임워크로 AngularJS
jQuery 는 라이이브러리 즉 개발자가 가져다 쓰는 툴이다. 개발자가 건물을 기초 공사부터 하나 하나씩 올릴 때 가져다 쓰는 툴이나 자원과 같은 것이다.
프레임워크는 이와 달리 모든 기본 구조를 제공하고 개발자는 그 기본 구조 위에 필요한 기능을 삽입하기만 하면 된다.
이는 내가 집을 건축할 것이냐 vs. 아파트에 입주할 것이냐 정도의 차아기 된다.
당연히 집을 건축할 때는 신경 쓸 것이 많치만 아파트에 입주할 때는 내가 신경 쓸 것이 그 보다 적다.
이렇게 라이브러리를 쓸 것인가? 프레임워크를 쓸 것인가? 에 대한 고민은 이미 서버 사이드 스크립트이니 JSP, ASP, PHP, ASP.NET 등에서 많은 고민이 있었고 서버 사이드는 이미 프레임워크로 대세가 기울어 있었다. 그 대세 프레임워크가 바로 MVC (Model - View - Controller) 패턴을 이용한 것들이 이었고, JSP/Java 진영에서는 Spring Framework 가, ASP.NET 진영에서는 ASP.NET MVC 프레임워크가 그 왕좌를 차지하게 된다.
이러한 서버 사이드의 역사적 교훈을 클라이언트 사이드 스크립트 진영에서도 적극적으로 활용하고자 하는 움직임이 생겨나니 결국 클라이언트 사이드용 MVC 프레임워크들의 봇물 터지듯 등장한다.
Backbone.js, Ember.js, javascriptMVC, Knockout.js 등이 등장하고 이에 대한 호불호가 갈리고 있을 때 혜성 같이 AngularJS 가 등장하니 이를 사용해 본 모든 이들이 AngularJS 에 대해 칭송을 아끼지 아니하게 되었다.
AngularJS 는 MVW (Model - View - Whatever)를 표방하고 뷰와 모델의 양방향 바인딩. SPA (단일 페이지 어플리케이션 Single Page Application), Promise/A 스펙 비동기 지원 등 클라이언트 사이드 자바스크립트 개발자의 가려운 곳을 긁어주고 또 SPA 에서 표방하듯 싱글이 많기로 유명한 ICT 업계의 개발자들의 마음을 알아주니....
6. AngularJS 2.x 는 AngularJS 1.x 와는 별개가 될 것이요 - Google AngularJS Team
2015년 02월 26일 기준으로 AngularJS 는 1.13.1 버전을 배포하고 있으나 이미 2014년에 구글 Angular 팀은 2.x 버전에 대한 구상을 발표하고 하위 호환성을 개나 주라며... 2.x 버전은 더 편한 개발을 지원을 위해 1.x 와의 호환을 보장하지 않는다 발표하니... AngularJS 1.x 를 사용하던 개발자들은 멘붕 + 저주까지 하고 있다는 소식이 간혹 들려오고 있다.
다만 2.x 의 출시일은 고추장 담그는 비밀은 며느리도 모른다 하였던 한국 CF보다 한 술 더 떠서 시어머니에 해당하는 구글 팀마저 정확한 로드맵은 안 나왔다고 하니 비정기적으로나마 AngularJS 공식 사이트를 방문해 보는 것이 좋을 듯 하다.
7. 결론 - 개발자는 3년마다 초급!!!
jQuery 라이브러리에 람보가 되었다 자만할 쯤에 AngularJS 의 등장으로 다시 자바스크립트와 이를 기반으로 하는 개발 세상에서 초급으로 전략하는 감이 없지 않다. 하지만 잠시 써본 AngularJS 는 정말이지 환상이고 1.x 버전으로도 충분히 코딩의 양이 현격히 줄어드는 경험을 하게 된다.
결론 AngularJS 1.x 의 세상으로 Go Go Sing... 가자 가자 노래하며 가자....
그리고 기억할 것은 자바스크립트는 객체지향을 지원하는 언어라는 것이다. 그것도 클래스 기반이 아닌 프로토타입 기반으로... 공부합시다.