플렉스에서는 모듈화를 어떻게 구성해야 할까?

예전에 플렉스를 사용해서 작은 RIA Application을 개발한 적이 있다. 기존에 MS의 WPF를 통해 RIA에 대한 기본을 그릴 수 있었는데, 막상 플렉스를 접하고 나니 WPF처럼 화면을 추가하고 쉽게 객체로 생성할 수 있는 부분이 없었다.(MS의 Visual Studio는 그런 의미에서 참으로 뛰어나다.) 그래서 내가 가장 많이 고민한 것은 어떻게 하면 플렉스의 코드를 분할하고 화면을 분할할 수 있는가 였다. 하지만 내가 아는 것이라곤 팝업창을 띄울 때 MXML을 사용해서 include할 수 있다는 정도? 시간날 때 모듈화에 대해 한번쯤 공부해 보려고 했는데 이번 Flex 3 Training from the source를 통해 좀 더 자세히 알 수 있게 된 것 같다.

사용자 삽입 이미지보다시피 플렉스에서 파일 하나를 생성할 때에도 이와 같이 수 많은 케이스가 있다. 물론, 이에 대한 설명은 우수한 국내 플렉스 개발자들의 플랙스 문서 한글화 프로젝트 를 참조하면 좋다. 아래쪽에 플렉스에서 사용할 수 있는 리소스에 대한 설명이 나와있는데, 처음 시작하는 입장에서는 다른 것보다 “MXML Component” 와 “ActionScript Class”에 대해서 이해할 수 있다면 모듈화에 대해 보다 더 쉽게 접근할 수 있을 것 같다. 나도 이 책에서 처음에 이 두가지에 대한 설명을 듣고 나서는 모듈화에 대해 보다 더 쉽게 생각할 수 있었으니깐 말이다.

MXML Component : 화면의 모듈화
사용자 삽입 이미지

MXML Component는 플렉스에서 사용하는 MXML(아마 macromedia extensible markup language겠지?)의 화면을 분할하는 역할을 한다. 일종의 화면 모듈화 인데, 물론 화면에 독립되게 액션스크립트 코드를 사용할 수 있다.
이 컴포넌트는 부모 MXML코드의 <mx:Application> 테그의 xmlns:v=”views.*” 이런 식으로 선언되고 화면 내에서는 <v:Function_Name/> 형식으로 사용된다.
따라서 화면을 설계할 때에는 두 가지 방법이 있는데 하나는 전체 화면을 설계한 후, 컴포넌트 단위로 자르는 작업을 하던지 아니면 최초부터 자식들(컴포넌트)을 제작한 후 부모에게 덛붙히는 방법이 있는데, 둘 다 장단점이 있기 마련이다.
또한 컴포넌트를 만들었다고 해서 부모에서 꼭 그 객체를 당장 화면에 보여주라는 법은 없다. 때문에, 사용자에게 어떤 상황에 따라 미리 구성된 다양한 화면이 있다면 viewState에 따라 다양한 컴포넌트를 보여줄 수도 있고, 혹은 화면의 액션에 따라 다이나믹하게 컴포넌트를 통해 정보를 보여주고 감출 수 있다.

Action Script File/Class : 코드의 모듈화
Action Script 는 기존에 플래시에서 사용되던 일종의 언어이긴 한데, 2.0 까지는 사실 개발자인 내가 보면 “아니 이건 외계어구나.” 라는 생각이 들었다. 뭐 따지고 보면 거의 문법이 아주 심하게 다르다고 할 수는 없지만, 보통 플래시 개발자들이 사용하는 것을 보면 콜백 함수를 많이 사용한다.(내가 아는 개발자는 뭐 그냥 도배를 해댄다.) 내가 RIA의 이벤트 개념을 잘 모르는 상태에서는 정말로 외계어처럼 보였는데, 어떻게 보면 플래시라는 것 특성상 프로그래밍을 입히기 위해서는 그럴 수도 있다고 생각했다.
여하튼 플렉스 3 은 액션스크립트 3.0 부터 사용 가능하다. 내가 아직 플렉스랑 액션스크립트의 버전의 의미의 상관관계는 잘 모르겠지만, 플렉스 3 버전 기준에서는 <mx:script> 안에서 함수와 변수를 사용하게 된다. 나 같은 경우 플렉스 초창기 시절에는 액션 스크립트 자체를 모르고 접근하였는데, 왠지 액션스크립트 3.0이 자바+자바스크립트 랑 비스무리해서 코딩은 쉽게 될 수 있었지만 모듈화 자체를 모르다 보니 한 개의 MXML파일이 무려 1000줄에 달하는 일 까지 발생하게 되었다. 그저 그냥 <mx:script><![CDATA[]]></mx:script> 안에 다 넣다 보니 프로그램이 느린 것은 물론, 함수 하나 수정하려고 찾아 들어가면 이건 뭔 갑작스러운 삽질이 시작되고, 가독성 자체가 떨어졌다. 한 개만 바꾸면 되는 것을 실수해서 한번 잘못 바꾸게 되면 계속 삽질을 하게 되는 것이다.
AS 파일은 이러한 스크립트 코드의 모듈화와 사용자 정의 클래스를 사용할 수 있도록 한다. 앞에서 MXML 컴포넌트에 대해 말했는데, 액션 스크립트는 상속 개념을 통해 거의 대부분의 플렉스 개체를 상속받아 재 정의할 수 있다. MXML자체에서 지원되지 않는 것도 정의할 수 있다.
액션 스크립트 클래스는 하나의 클래스 객체를 제작하는 것인데, package를 통해 클래스를 묶고, 이를 객체로써 혹은 데이터 형으로써, 사용하는 것은 아주 일반적인 OOP적 프로그래밍의 형태이다. AS를 통한 사용자 정의 클래스를 모를 떄는 바보같지만, 내가 만드는 프로그램에서 사용되는 아주 일반적인 객체를 선언해서 사용할 줄도 몰랐다.


결국 이 MXML 컴포넌트와 Action Script파일을 통해 우리가 생각할 수 있는 것은 아주 보편적인 RIA의 설계 방식인데, 화면을 분할하고 이에 따라 표출할 데이터를 설계하고 레이아웃을 구상하게 되면 => 이에 따라 프로그램에서 공용으로 사용될 객체들은 무엇인지, 또 이것들이 사용자 정의 객체라면 어떤 메소드와 변수들을 묶고 다녀야 할 것인지, 어떤 화면에서 어떤 컴포넌트와 사용자 정의 클래스를 물고 갈 것인지를 설계해야 한다. 이렇게 back단 설계가 끝나면 프로그램에서 사용되는 외부 웹 서비스와 내부 서버단(DB 등) 설계를 통해 하나의 프로그램을 제작할 준비를 마치는 것이다.


웹의 RIA는 대부분이 view와 logic으로 이루어져 있다. 그리고 view도 여러 개가 사용되고 로직도 여러 객체가 사용되거나 사용되지 않는다. 따라서 이러한 웹 서비스의 특성을 올바르게 이해하고 설계할 수 있다면, 플렉스 뿐만 아니라 앞으로 등장하게 되는 다양한 RIA서비스들에 대해 보다 빠르게 이해하고 설계해 나갈 수 있을 것이다.