플렉스 2가 등장하기 이전까지 필자는 개인적으로 플렉스가 마음에 들지 않았습니다. 컴포넌트 방식의 개발을 지향하는 플렉스는 어차피 플래시 오쏘링 툴(이하 플래시)이 가진 능력의 일부분만을 차용한 것이란 생각이 지배적이었습니다. 컴포넌트 방식의 개발은 런타임에 매우 느리고 디자이너의 작업물을 토대로 개발하는데 있어서 결국 플래시의 도움을 받을 수 밖에 없다고 생각했었습니다.
플래시란 용어는 최근 들어 3가지 의미가 혼재되어 있습니다. 플래시 제작에 있어서의 ‘플래시 오쏘링 툴’과 제작 결과물로서 웹에서 재생되는 ‘SWF 파일’을 지칭하기도 하며, 플렉스나 아폴로 등을 포함하는 플랫폼으로서의 플래시가 있습니다.
그러나 플렉스 2와 함께 무료로 공개된 Flex SDK를 살펴보면서 개발 툴로써의 플렉스의 장점이 존재하며 어플리케이션 제작에 있어서 플래시 개발 프로세스를 개선할 수 있으리라는 기대감이 증가했습니다. 왜냐하면 인터랙티브 무비가 아닌 플래시 어플리케이션 개발은 단일 프레임만을 사용하며 디자인과 협업과정에서 그래픽 심볼만을 필요로 합니다. 이것은 디자인과의 협업 형태에서 Fla 파일을 주고받으며 수많은 변종 파일을 양산하고, 프레임에 삽입한 개발코드(stop이나 gotoAndPlay와 같은)로 인해 무비클립의 개별 프레임을 뒤져야 하는 부담에서 탈출할 수 있는 방법을 제공합니다.
그동안 플래시는 유연한 개발 방법론을 제공해왔습니다. 그것은 디자인과 개발 툴의 밀접한 결속력으로 인해 빠른 프로토타이핑과 손쉬운 업데이트 환경을 갖추었기 때문입니다. 하지만 여타 개발 분야에 있어서 외면을 받은 이유이기도 합니다. 이런 장점은 디자이너가 되지도 못하고 개발자가 되지도 못한 어정쩡한 액션스크립트 개발자의 모습이 생겨날 수 밖에 없었던 원인이기도 합니다. 물론 타 분야에서 제대로 플래시 개발 환경을 이해할 수 없던 부분도 있으며, 실제로 개발 툴로써는 부족한 면이 많았던 점도 사실입니다. 하지만 보다 견고한 액션스크립트 3.0의 등장과 플렉스 SDK와 같은 공개 소프트웨어, 그리고 최근 들어 차기 버전의 플렉스 SDK를 오픈소스화 한다는 방향과 함께 플래시 개발 툴로써 플렉스를 주목해볼 필요가 있습니다.
플렉스의 가치는 본 문서에서 언급한 것 이상으로 다양한 RIA 환경을 구축할 수 있습니다. 본 문서에서 다룰 내용은 SWF 결과물을 제작하는 툴로써의 플렉스 개발 환경에 대해서만 언급합니다.
