개인적으로 수학에 관련된 지식이 많이 부족해서 여러번 수학공부에 도전하긴 했는데, 시간이 지나면 잊어먹고 시간이 지나면 잊어먹고 하기 때문에 많이 힘들었었다. 샘플 소스들을 만들면서 지식을 축적해두곤 했는데 소스파일 형태의 지식축적은 아무래도 시간지나 다시 보기 힘들다는 문제점이 있었고, 그래서 만드는 중인 stutter 를 통해서 "간단한 스크립트를 작성하는 것만으로 문서처럼 보여지게 할 수 있는" 기능을 찾았다.

canvas 를 이용해볼까도 싶었지만, actionscript 에 비해서 벡터 그래픽 드로윙이 너무 원시적인지라 코딩하기가 불편했다. 방법이 없을까 고민중에 찾게 된 Processing.js... 예전에 얼핏 봤던 프로젝트이긴 한데 지금 상황에서 딱 쓰기 좋다는 느낌이 들었다.

일단 벡터 그래픽 드로윙이 상당히 세련되었고, html5 canvas 를 통해 에뮬레이션 되는 녀석이라 action script 처럼 컴파일할 필요가 없다는 점이 마음에 들었다.

http://ssen.name/codeZone/stutter/math.html

그렇게 processing 언어를 통해서 간단하게 문서내부에 코딩을 하고, 코딩내역을 바로 브라우저상에 이미지로 표현할 수 있게 되었다.

이런 일련의 작업들을 하게 되면 Flash 가 가진 컴파일 언어로서의 장점과 단점에 대해서 생각하게 된다. 일단 단순한 챠트등을 그리는데도 너무 복잡한 퍼블리싱 절차 (제작 > 컴파일 > 업로드 > html 코드상에 삽입 > 백엔드와의 연동구조 만들기) 를 거치는 Flash 작업의 불필요함은 상당한 스트레스를 만들게 된다.

일단 Canvas 의 브라우저 연동문제는 둘째 치고라도, 그 외적인 단점들을 보자면 상당히 원시적인 수준의 API만을 제공하고, 그 성능도 낮기 때문에 Flash 와 같은 고수준의 애니메이션을 구현하기 힘들다는 것이다. 그리고, 더더욱이 큰 문제는 Flash 라는 미디어를 제작할 수 있는 도구가 없다는 것이고... Flash 가 난해하다고 하지만, 그 난해함은 개발자와 디자이너의 작업영역이 겹치면서 발생하는 난해함을 최대한으로 억제하고도 남은 수준의 난해함이라고 할 수 있다. (10년 동안 이것때문에 얼마나 많은 고민을 했겠는가...) 많은 개발자들이 Canvas 에 관심을 가지겠지만 사실상 디자이너가 리소스를 제작해 줄 수 있을만큼 만만하지가 않다. (일단 그래픽스 분야에서 가장 독보적인 어도비가 지원을 해주지 않을 가능성이 높으니...) 쉽게 이야기해서 Canvas 로는 어지간한 수준 이상의 그래픽스를 구현하는 것이 불가능하지 않을까 싶다.

미디어는 동영상을 쓰면 되지 않느냐고 하지만, 동영상과 같이 이미 퍼블리싱 되어 나오기 때문에 1차원적인 타임라인을 가지는 제작물은 Interactive Media 에 사용할 수가 없다. Interactive Media 에 필수적인 실시간 렌더링 성능과 실시간으로 드로윙을 구현하는데 필수적인 고수준의 그래픽스 API 가 존재해야 기본적인 개발이 가능해지고, 거기에 디자이너가 발생시키는 리소스가 얼마만큼 순조롭게 개발자가 사용할 수 있느냐도 중요한 문제가 된다. Canvas 의 존재 자체가 부각되고 있지만, Canvas 는 현재 10년의 세월에 걸쳐서 Macromedia 와 Adobe 가 고민해왔던 작업 통합의 문제를 고스란히 되풀이할 가능성이 높다.

전망적으로 봐서 Interactive Media 와 같은 고수준의 그래픽스를 구현하는 작업은 Canvas 를 통해서는 이루어지기 힘들고, 기껏해봐야 단순한 규칙성의 그래픽스만을 구현하는 RIA 정도의 구현만이 가능하지 않을까 싶다.

하지만, 고수준의 개발물을 Flash 가 개발하기 좋다해서 Flash 가 월등히 사용되어지겠냐? 라는 질문에는 그렇다고 대답하기 힘들다. swf 라는 컴파일을 필요로 하고, html 상에서 격리되기에 여러가지 복잡한 절차를 필요로 하는 Flash 는 "적절히 낮은 수준을 구현하려 하는" 작은 개발물 시장을 뺏길 가능성이 굉장히 높다. 그리고, Flash 시장의 대부분은 그 작은 개발물들이 차지 하고 있고...

작은 개발물 시장을 뺏기고, Flash 가 고수준의 개발물을 담당하는 형태로 시장이 양분될 가능성은 그다지 높지 않다. 오히려 Flash 가 소멸됨으로서 브라우저 벤더들에게 그 대안이 될 고수준의 Canvas 성능을 요구하게 될 가능성이 더 높다고 할 수 있다. 이미 WebGL 과 같은 것들이 대기상태에서 "시장 필요성의 존재의미" 때문에 살아나지 못하고 있는데, Flash 가 작은 시장을 뺐기는 순간 밀물과 같이 이런 프로젝트들이 살아나게 되는 상황이 생길 수 있다. 그리고, 그 대안체들의 등장은 Flash 가 한순간에 소멸되는 우울한 결말을 내리게 될 수도 있다.

Flash 가 살아남기 위해서는 적어도 현재의 swf 에서 벗어날 필요가 있고, swf 로 통일된 아웃풋 포맷을 다양한 형태로 분할 시킬 필요가 있다. 그런 대안으로 Processing.js 가 상당한 참고가 되지 않을까 싶다.

Processing 이라는 JRE 를 통해 구현되는 언어를 canvas 와 javascript 를 통해 에뮬레이션 시키려 하는 이 프로젝트와 같이 Flash 자체가 swf 를 고집하지 말고, Canvas 를 포용할 필요가 있다.

Flash 라는 작업도구가 swf 포맷에 집중된 상황을 타개하고, 저수준의 개발물은 Flash 를 통해 Canvas 에 접근하고, 브라우저의 발전상황에 따라 swf 컴파일을 통해서 구현되는 작업물들을 Canvas 로 점진적으로 이전시키는 것이 좋은 방법이라고 보여진다. 그런 상황을 만들어나간다면 결과적으로 Flash 에 대한 현재의 의존도를 지속적으로 유지시킴으로서 swf 포맷의 가치 역시 유지시킬 수 있는 상황을 만들어나갈 수 있다.

하지만, 역으로 swf 포맷에만 의존하다가 저수준 개발물 시장을 빼앗긴다면 swf 포맷 자체가 위험할 가능성이 높아지고, swf 포맷의 소멸은 결국 Flex 와 Flash, 그리고, 그 후방을 지원하는 Photoshop, Illustrator 모두를 위험에 빠뜨릴 가능성이 높다.

현재로서 어도비가 선택할 수 있는 가장 최선의 방법은 swf 에 대한 집착을 포기하고, Flash 를 통해 Canvas 를 포용하는 방법밖에는 없다고 본다.

Canvas 시장은 아무래도 현재의 canvas API 자체가 상당히 구리기 때문에 processing.js 와 같은 랩핑 시키는 확장 API 들이 많아지게 되지 않을까 싶다. 마치 javascript 의 한계성을 극복시키기 위해 prototype 이나 jquery 들이 사용되듯이 canvas api 에 대한 확장 API 가 다수 등장하게 될 것이다.

각각의 특성에 따라 틀리겠지만 interaction 이 필요하지 않은 실시간 렌더링의 챠트와 같은 data visualization 분야에 있어서는 현재 가장 뛰어난 수준을 보여주는 processing.js 가 한자리를 차지하게 되지 않을까 싶다. (애초에 그렇게 만들어진 녀석이고... 애초에 디자이너와 같은 비전문 프로그래머들을 위해 만들어진 녀석이라서 난이도 자체가 엄청나게 낮다...) 문제는 이 processing.js 를 통해 발전된 개발자, 디자이너들이 원류인 jre 를 통해 구현되는 오리지널 processing 에 흡수될 수 있다는 것인데...

이런 발전모델은 Flash 역시 동일한 형태로 따라갈 수 있지 않을까 싶다.

아... 머리가 복잡한데 어쨌든 결론은 Flash 가 swf 에 집착해서 Flash, Flex builder 의 운명 역시 위기에 놓으려 한다면 어도비의 입지 자체가 위태해질 가능성이 높다고 본다. 하지만, 그렇지 않고 Flash 를 통해 Canvas, html5 를 포용하려 한다면 "어도비 말고는 디자이너들에게 선택권이 존재하지 않는 시장상황" 의 권력을 통해 시장을 컨트롤 할 수 있는 위치를 차지할 수 있다는 것이다.

그리고, Flash 를 그렇게 다양한 형태로 세분화 하기 위해서는 RIA 인지 나발인지 모를 "존나 고수준" 에만 집착해서 Flash 를 발전시키던 현재의 정책을 재고하고, 애니메이션, 작은 개발물 등의 기존에 너무 성장주의에만 얽혀서 발전시키지 않았던 분야들을 재고할 필요가 있다. 솔직히 html5 를 구현하는 브라우저들의 시장상황을 무시하고 순수하게 기술만으로 챠트를 processing.js 나 canvas 로 그릴래? 아니면, Flash 와 Actionscript 로 그릴래? 라고 한다면 절대 Flash 를 선택하지는 않을 것이다. 그마만큼 고수준의 개발을 하기에야 Flash 가 편하지만 저수준의 개발을 하는데는 편하지 않다라는 것이다.

C를 에뮬레이션 하려고 지랄을 하기 보다는 Processing 을 에뮬레이션 하려고 애쓰고, Flash Catalyst 니 뭔지 해서 고수준의 RIA 제작을 편하게 하려고 지랄을 하기 보다는 SimpleButton 에 Disable 모드나 추가하고 Bitmap 에 scale9Grid 나 추가할 것을 원하며, Graphics 의 드로윙 API 에 벡터를 넣는 것 보다는 삼각형 그리기 메서드나 넣어주길 원하고, BlazeDS 프로젝트로 flash remoting 에 애쓰기 보다는 제발 제대로된 수준의 soap, xml-rpc 나 넣어주길 원한다... 이 씨부럴 개새끼들은 도대체 대중적으로 사용되는 기능들은 개무시하고, 달나라 떡방아 찧는 짓거리만 맨날 하고 있으니 개발이 도통 편해지질 않잖아... (비트맵 skew 기능만 해도 만드니깐 존나 쉽게 만들어지던데 씨발새끼들 API 에 넣지도 않고... 아놔...)

적어도 processing.js 의 발전형태로 봐서 Flash 가 죽어나간다고 해도, Interactive Media 나 RIA 시장 자체가 붕괴될 일은 없지 않을까 싶다. 오히려 다양한 Canvas 에뮬레이션 API 들을 통해서 더 최적화된 시장이 등장하면 등장하지...

어도비에게 남은 것은 그런 시장의 변화에서 나와 같은 개발자들이 지속적으로 Flash 를 사용하게 만들것이냐, 아니면, 다른 개발툴로 이동을 할 것이냐... 의 문제이지 않을까 싶다. 적당히 작작하고 시장에 적응해나가려는 노력없이 "내 것 좀 사용해줘어~" 하면서 징징대기만 해서는 swf 라는 너무 난해하고 높은 복잡성을 요구하는 포맷의 소멸과 함께 그렇게 공들이고 있는 Flash 라는 툴 자체의 생명이 위험해질 수 있지 않을까 싶다...