[WebStorm] GUI 역사 및 ExtJS4 라이브러리 생성방법 및 기본 Node.js 디버그 Develop Tip

지난번 블로그에서 IntelliJ를 만든 jetbrains 라는 회사에서 Java Script 등의 개발을 위하여

이번에는 GUI에 대한 20년간의 변화에 대하여 나름 느낀 점을 기술해 보겠습니다.
물론 새로운 기술이 미국에서 언제 나왔냐 하는 것 보다는, 그래도 나름
중요 프로젝트나 그 당시의 여러 프로젝트를 진행했던 경험으로써 적용된 시점은
또 다를 수 있음을 미리 알려드리는 바입니다.

1) ~ 1990 : Text base GUI

87년까지 Apple-II 컴퓨터를 비롯하여 대우컴 등의 8-비트 컴퓨터가 있었고
여기에서 BASIC 언어로 개발을 하거나 터미널 실에 가서 라인 에디터로
Basic이나 Fortran을 해 보았던 기억이 있습니다. 이 시절에는 
GUI 라는 것이 거의 없었습니다.
88년에 인텔의 8086, 8087, 8088 등의 CPU와 허큘리스 비디오 카드와 하드도 없이
5.4" 플로피 디스크 드라이브를 장착한 컴퓨터가 세상에서 가장 좋은 컴퓨터였고,
노턴 아저씨의 인터럽트 벡터를 이용한 문자 박스와 상위 메뉴를 포함한 노턴 커맨더 등이 나오고
아래한글이 나오면서 Dot Graphic에 대한 관심도 가졌었던 것 같습니다.
90년 말에는 한글 오토마타를 만들어 나만의 한글 입출력기도 만들어 봤던 기억이 나네요.
이 당시만 하더라도 그냥 비기에 좋더라~ "Look & Feel" 정도의 개념만 있었습니다.

2) ~1995 : Windows 3.x

처음에는 X-Window에서 Xlib 혹은 Motif WIgit 등을 이용한 간단한 GUI를 해 보다가
드디어 윈도우 3.x 버전이 출시 되면서 쓸만한 GUI 환경이 등장하기 시작합니다.
개발자가 개발하기 좋은 GUI가 아니라 드디어 사용자가 쓸만한 정도의 윈도우 환경이 나타났다는 뜻입니다.
물론 그 당시 보았던 맥OSX의 원조 격인 NextStep의 모습은 충격적이었죠.
개발도 순수 Win32 API를 C로 이용한 개발 환경이었구요.
지금은 하늘나라로 간 선배가 지뢰찾기와 똑같은 프로그램을 만들었던 기억이 생생하네요.
아마도 MFC를 이용한 프로그램도 그 근방에 했던 것 같습니다.
MFC는 Win32의 C like한 개발환경을 OOP 개념으로 C++로 사용하기 좋게 만들었던 것인데,
이상하게도 MFC하면 아직도 개발에 무척 시간과 공이 많이 들었던 기억밖에 없습니다.
물론 ATL 이라는 템플릿 개발 방식도 조금 후에 나왔지만 지금은 대부분 기억에서 사라져버렸습니다.

3) ~ 2000 : RAD -> CGI -> WAS

그 다음 오년은 그 이전 오년에 비하여 새로운 변화가 가장 많이 일어났던 것 같습니다.
흡사 2005년 이후의 모습과도 어찌보면 닮았네요.
초기에는 RAD 삼총사인 파워빌더, 델파이, VisualBasic을 이용한 Thick Client 라 하는 CS 개발이 
주를 이루었습니다. 
그 이전에 DBF 로 만들던 비디오가게 프로그램도 RAD로 개발이 되고,
비트컴퓨터에서 열심히 교육을 시작하던 때 같기도 합니다.
그러다가 WWW 라는 것이 드디어 우리 곁에 등장을 합니다.
초기에는 CGI를 이용한 프로그램도 있었고, C로 개발된 웹 프레임워크인
사파이어웹을 최초로 이용하여 공공 프로젝트를 하기도 했습니다.
그러다가 나온 PHP, JSP, ASP 등의 서버-사이드 스크립트를 이용하면서
"우와 이렇게 훌륭한 스크립트도 있다니..." 하고 기존 Perl같은 CGI를 작성하던것
보다는 꽤 쓸만한 웹 페이지를 만들 수 있었습니다.
또한 WebLogic을 필두로 WAS를 이용한 JSP가 메인이 되기도 하였습니다.
이런 웹 페이지가 결국은 Thin Client 라 하여 기존에 RAD로 작성했던 것을
하나씩 둘씩 바뀌어져 갔습니다.

4) ~ 2005 : XInternet, RIA

최초에 RAD로 개발된 응용프로그램을 접했던 사용자들은 웹 프로그램을 보고
'가볍다'라고 이야기한 이유는 기존에 로컬에서 로컬 컴퓨터를 Fully 이용하는
프로그램에 비하여 웹 브라우져를 이용하고 매번 화면 (또는 화면의 일부)이
변경될 때마다 서버와 통신을 하는 웹 응용프로그램이 그렇게 즉답성이나
GUI 컴포넌트가 훌륭하지 못했던 것이 사실입니다.
다시 말해 사용자들은 이렇게 말하기 시작했습니다.
"기존에 CS 프로그램처럼 하는 일들도 (혹은 그런 GUI) 이제는 웹 브라우져에서
동일하게 지원해줘!" 이렇게 말이지요.
그래서 등장한 것이 X-Internet 입니다.
제가 아는한 X-Internet은 기존의 RAD 에서 제공했던 GUI 컴포넌트 등의
화면을 동적 혹은 수동으로 Active-X 등으로 만든 후,
부라우저의 껍데기를 입힌 것이지요.
즉 브라우저의 탈을 쓴, Active-X의 MFC GUI 등과 같이 이야기 하면됩니다.

그러다가 이런 요구사항이 우리나라만 있었던 것이 아닌가 봅니다.
(때로는 우리나라 사용자가 개발자 입장에서 너무한다.. 라고 생각든 적이 많은데
 결국 시대를 앞서서 더 좋은 SW를 바라는 순수한 입장... 이 아닌가 싶습니다)
RIA (Rich Internet Application) 이라는 용어가 등장합니다.
MacroMedia사가 개발했고, 95년 인가에 등장한 Falsh-Player가 de facto 
MSIE 프러그인으로 자리를 잡게되고, Adobe 사가 MacroMedia사를 인수함에 따라
어도비는 좀더 큰 그림을 그립니다.
RIA를 이 플래쉬 플레이어를 이용하여 X-Internet 같은 기능을 해 보자~는 것이었죠.
이게 될거 같으니까 M$ 사도 Silverlight를 출시합니다.

Silverlight를 이야기 하기에 앞서, DotNetFramework에 대해 언급을 해야되겠네요.
DotNetFramework 역시 JIC (Just In Time Compiler) 개념의 Sandbox VM을 따라
CLR을 만들어 놓은 것입니다. C#은 DotNetFramework를 위하여 나온 언어이고
C, C++도 이전에 순수 실행코드를 unmanaged code, 또한 CLR에서의 VM에서
돌면 managed code라고 이름하였습니다.
이 .net도 버전업이 됨에 따라 WCF라는 개념이 나와 MVC의 View를 독립시켜
브라우저에도 돌고 윈도우로도 돌 수 있도록 View 의 독립을 이야기 하면서
브라우저에서 돌만한 작은 크기의 dotNetFramework를 만드는데 이것이 바로 
Silverlight 였습니다.

하여간 2008년 당시만 하더라도 RIA가 앞으로 GUI 올바른 방향으로 생각을 하여
Flex Builder 3.0 으로 개발에 들어갔고 그 결과는 영 아니올시다... 였습니다.
그래픽 툴을 주로 개발해온 Adobe가 만든 개발자들을 위한 개발 툴이
그렇게 훌륭하지 못했다는 것과 (이클립스로 돌았는데 이 당시만 해도 
안정성 등이 문제 있었는 듯..) 메모리 관리와 멀티 쓰레드가 안되는 등,
잡스 아저씨가 이야기한 여러가지 문제점을 안고 있었던 것이 사실인 것 같았습니다.

결국 RIA 이총사도 무대의 뒷전으로 물러나게 되었습니다.

5) ~ 현재, NScreen, SPA

잡스 아저씨의 아이뻐가 공전의 대 히트를 치고 나서는 안드로이드 폰을 비롯하여
태블릿 기기 등 포스트 PC로의 이전에 계속되고 있습니다.
현재로서는 이렇게 다양하고 많은 디바이스마다 계속하여 새로운 앱을 개별적으로
만든다는 것은 거의 불가능하다는 것은 누구나 아는 사실입니다.
그래서 어느 기기에서나 동일한 결과의 앱을 이용할 수 있는
N-Screen 대응 WebApp 등에 대한 개발 방법론이 대두되고 있습니다.
구글이 크롬을 만들며서 발표한 V8 JavaScript를 이용한 이벤트 방식의
서비스 모델인 Node.js와 이를 이용한 웹서비스의 개발 방법론 등이 나타나고
최근에는 Wakanda 같은 순수 JavaScript 만을 이용한 개발 방법론도 있습니다.
또한 MVC에서의 View 에 해당되는 ExtJs 라는 것도 있지요.

또한 이제는 RIA 라는 용어가 더 이상 사용되지 않는 것 같습니다.
그 이유는 표준으로서의 용어가 아니라 벤더에서 이야기한 용어이지 않을까 짐작해 봅니다.

그에 반하여 SPA (Single Page Application) 이라는 용어가 나오더군요.
그동안의 웹 프로그램은 계속 HTTP 요청/응답으로 화면이 바뀌면서
결과를 보여주는 대신 HTML5 위짓이 첫 HTML 요청에 랜더링 되고
그 이후는 AJAX, JSONP 등으로 RESTful API 통신을 하면서
화면이 바뀌지 않고 UI 가 구성되어 그렇게 부르나 봅니다.


암튼 앞으로의 GUI 방향은 어느 누구도 장담할 수는 없지만
요구 사항은 비교적 결정되어 있습니다.
또한 시장이 요구하면 그에 부합하는 하드웨어는 계속하여 발전하기 마련이구요.
그런 의미에서 최근과 같은 JavaScript 만들 이용한 N-Screen 용 WebApp은
단순히 또다른 RIA를 대치한다.. 라고만은 볼 수 없을 듯 합니다.


서론이 길었습니다.
위와 같은 취지에서 최근에 다양한 JavaScript용 솔루션을 많이 찾다가
발견한 것 몇 가지 입니다.

Node.js : Node는 서버가 어떻게 작업해야 하는지에 대한 개념을 변화시킨 서버측 JavaScript 해석기입니다. 목표는 프로그래머가 고도로 확장 가능한 애플리케이션을 빌드하고 하나의 유일한 실제 머신만으로 수 만 개의 연결을 처리하는 코드를 쓰도록 사용하는 것입니다.

NPM : 우리가 리눅스에서 패키지를 새로 설치하기 위하여 apt-get 혹은 yum 같은 것들을 이용합니다. NPM은 말하자면 Node.js 의
필요 모듈들을 패키지 형식으로 원격 저장소에서 관리되어, 검색하고 설치하고 업데이트 하는 등의 역할을 수행하는 패키지 관리자 입니다.

Express : 워낙 Web 프로그램 이라는 것이 MVC (모델<DB추상화>-뷰<사용자GUI>-컨트롤러<프로그램로직>) 개념에서 VC가
서로 뒤섞여서 개발되는 난점이 존재합니다. 이것을 좀 더 제대로된 MVC로 나누자고 했던 것이 바로, Java의 SprintSource,
Ruby의 RubyOnRails나 Sinatra, Python의 Django, PHP의 Sympony나 Yii 등의 MVC 프레임워크가 등장한 결정적인 원인입니다.
Express는 위의 Sinatra를 JavaScript로 변환한 정도쯤으로 생각되는 Node.js의 NPM 설치가능한 패키지 중의 하나로 역시 MVC
프레임워크입니다.

ExtJs : ExtJs는 이미 버전 4가 되었을 정도로 상업으로 판매되고 그 사용자가 많이 있는 Client-Side JavaScript 언어로 되어있는
브라우저 독립적인 GUI 위짓 모음이라 생각하시면 됩니다. 최근에 jQuery 등을 비롯한 JavaScript의 개발 언어로서의 각광과
더불어 가장 쓸만한 화면 컴포넌트를 상용으로 제공하고 있습니다.

WebStorm : IntelliJ 상용 Java IDE를 개발한 회사에서 제공하는 Java Script로 웹 개발을 할 때 가장 적합한 IDE 입니다.


이제는 WebStorm을 이용하여 간단히 ExtJs를 사용 시작을 위한 준비 작업과 Node.js의 초간단 예제 및 디버깅 등에 대하여 살펴보도록 하겠습니다.


웹스톰을 띄우고 New Project를 하여 extjs_node 라고 이름을 넣고 OK 했습니다.

위와 같이 나타나면, 상단의 Settings를 눌러 설정창을 띄웁니다.

좌측의 JavaScript > Library 를 찾아,
오른 편에 이미 Predefined 혹은 Global로 뒤어 있는 JS 라이블러리가 존재합니다.
"Add..." 단추를 누릅니다.

상단과 같이 ExtJs 정보 및 ext-all-debug-w-comments.js 라는 것을 지정해 줍니다.

하단의 "Specify..."를 눌러 디폴트 정보로 OK를 눌렀습니다.

그 결과 위와 같이 설정되었음을 알 수 있습니다.

ExtJs가 글로벌로 추가되었음을 확인하구요~

오른편의 "Manage Scopes..."를 눌러 현재 프로젝트에 적용할 JS 라이브러리를 지정합니다.

이제는 테스트를 위하여 New>File을 선택하고,

app.js 라고 입력한 후 OK 합니다.

이제는 Ext. 까지만 입력하자 마자 하위 메소드 등이 도움말로 쭉~ 나옵니다.
(자바로 이렇게 까지 훌륭한 IDE 가 나오다니 놀랍습니다)


이제는 Node.js를 해 볼 차례입니다.

역시 새로운 프로젝트로 NodeJS-Tutorial 이라고 프로젝트를 하나 만든 다음,

해당 프로젝트에서 Node.js 를 사용하도록 합니다. (디폴트로 거의 모두 선택되어 있으니 필요한 것만 선택하면 되겠군요...)

외부 라이브러리 목록이 보입니다.

역시, New>File을 선택해서,

아무 이름이나 넣고,

위와 같이 입력을 시작합니다. 캬하~ JS도 이렇게 잘 나오다니...

위와 같은 초간단, 웹 서비스를 만들었습니다.

실행을 해 보면...

실행되었다 나타나면서...

위와 같이 잘 웹서비스가 돌고 있음을 알 수 있습니다.

이제는 브레이크포인트를 하나 설정하고,

디버그를 시작하면,

크흐~~~ 훌륭한 디버깅 환경이 됩니다.


아마도 WAS를 이용한 JSP, 혹은 FlexBuiler 등을 사용해 보신 분들은,
위와 같은 단순 자바스크립트로 보다 훌륭한 일을 할 수 있다는 것에
바로 경이로움을 느끼실 수 있을 것입니다.


어느분께는 도움이 되셨기를...

핑백

  • 지훈현서 : [WebStorm] HelloWorld (Html + JavaScript) 2012-12-10 22:48:43 #

    ... 지난번의 [WebStorm] GUI 역사 및 ExtJS4 라이브러리 생성방법 및 기본 Node.js 디버그 내용에 이어,이번에는 간단한 HelloWorld 웹 프로그램을 직접 해 봅니다.JetBrains에는 PhpSt ... more

  • 지훈현서 : [Node.js] PyCharm + Node.js 2013-12-02 23:55:39 #

    ... JetBrain에서 만든 PyCharm이라고 파이썬 언어의 제일 좋다고 느끼는 IDE가 있습니다.그런데 그것 말고도 Node.js 등의 JavaScript 를 개발하려면 꼭 WebStorm 같은 것이 있어야만 되는 줄 알고 있었습니다. 그런데 역시나... PhpStorm에서도 JavaScript의 개발 환경이 있었듯이, ... more

덧글

  • 삼보리 2013/02/19 09:46 # 삭제 답글

    너무 잘보고 갑니다.
    감사합니다
  • 지훈현서아빠 2013/02/19 10:18 #

    도움이 되셨다니 저의 보람입니다~ ^^
  • kkds.jin 2013/12/13 10:37 # 삭제 답글

    친절한 설명과 수고에 감사드립니다.
  • 지훈현서아빠 2013/12/13 11:32 #

    도움이 되셨다니 저의 보람입니다~ ^^
  • 명랑폐인 2014/03/02 12:18 # 삭제 답글

    많은 도움 되었습니다. 감사드려요.
    뭐든지 처음 시작할땐, 쉬운 내용을 친절하게 설명해주는 가이드가 있어야
    포기하지 않게 되더라구요.
  • 지훈현서아빠 2014/03/02 19:09 #

    그쵸? 저의 바램이 그런 시행착오를 줄이시고 어느 분야던지 전문가가 되셔서,
    또 다른 분들꼐 나누어 주십사 하는 바램입니다~~ ^^
  • 이행선 2016/11/27 14:49 # 삭제 답글

    덕분에 UI history를 한눈에 알 수 있었습니다.
  • 지훈현서아빠 2016/11/27 22:56 #

    ㅎㅎ 역사는 쭈욱 계속됩니다~ ^^
    도움이 되셨다면 저의 보람입니다. 이전임님 ~~
댓글 입력 영역

구글애드텍스트