이런 상황에서 수시로 찍어대야 하는 스크린캡쳐의 파일이름이 한글로 나오면 바꾸는 작업 때문에 짜증이 나서 뒈질수 있다. 해서 스크린샷 찍을때 파일이름을 바꾸어주는 것이 정신건강에 이롭다.

일단, 터미널을 열고

sudo /Applications/TextEdit.app/Contents/MacOS/TextEdit /System/Library/CoreServices/SystemUIServer.app/Contents/Resources/ko.lproj/Localizable.strings

이와 같은 명령어를 입력해준다.

대충 ko.lproj 를 보면 알겠지만,

ls /System/Library/CoreServices/SystemUIServer.app/Contents/Resources/

의 명령어를 입력해주면, 언어별 포맷팅 파일들이 주르륵 있다. 영어의 경우엔 English.lproj 이다.

명령어를 입력해주면, Localizable.strings 라는 파일이 텍스트 에디터를 통해서 뜨게 되는데, 이 중에서 아래와 같이 되어있는 라인을 찾는다.

/* Format screencapture file names */
"%@ %@ at %@" = "%1$@ %2$@ at %3$@";

위와 같은 라인을 아래와 같이 바꿔준다.

/* Format screencapture file names */
"%@ %@ at %@" = "capture";

와 같이 바꿔준다. 이왕이면 "capture %2$@ %3$@" 과 같이 해서 날짜정보도 같이 보여주면 좋겠지만, 이게 되질 않더라... ㅡ ㄴ ㅡ;;; 이렇게 하면 대충 capture 스크린샷 2010-03-04 와 같이 되어버린다. 숫자에 대한 판별이 절대숫자가 아니라 상대숫자로 되어있어서 %2$@ %3$@ 이런 형식으로 해도, 2가 첫번째, 3이 두번째가 되어버리는 것 같다. (젠장...)

그렇기에 별수 없이 날짜정보는 포기하고, 파일이름이라도 영문자로 바꾸는데 만족을 해야할 것 같다. 어짜피 여러개의 파일이 만들어진다해도 뒤에 숫자를 붙여주기에 큰 무리는 없을 것 같다.

ActionScript 로 되어있던 부분들을 몽창 javascript 로 컨버팅 시키고, 더불어 크로스브라우징 맞춘다고 개지랄을 해서 겨우겨우 전체 모든 브라우저들에서 멀쩡히 돌아가는 문서를 만들었다.

그럭저럭 신경을 쓴 부분이 참 쓸데없긴 하지만... video 처리였는데, html5 와 h.264 지원이 가능한 브라우저들에서는 <video> 태그로 처리를 하고, 그렇지 않는 녀석들은 flash 를 통해서 처리를 했다. flash 자체가 h.264 로 된 mp4 포맷을 읽어들이고, h.264 mp4 의 경우 (ff 를 제외한) html5 지원 브라우저들에서 지원을 해주기 때문에 파일 하나로 여러 브라우저를 지원할 수 있었다. (현재 실용적인 측면에서 차세대 동영상 포맷은 h.264 가 좀 더 호환성이 높은 것 같다.)

대충 <script type="stutter"> 를 사용해서 Stutter Document를 선언시키고, 자바스크립트를 통해서 해석해서 뿌려주는 방식을 선택했다. 이러면 그럭저럭 검색엔진에도 정상적으로 걸리지 않을까 싶기도 하고...

일단의 기초적인 작업들은 끝났고, 이제 여러 브라우저에서 동일하게 돌아가도록 css 를 정리해주기만 하면 대충 클라이언트측은 완성이 될듯 싶다. 이 베이스를 가지고 대충 DB 를 연결해서 게시판 형식으로 만들어주고, 테스트로 recipe 사이트의 컨텐츠들을 stutter 베이스로 옮길 생각이다.

별 쓰잘데기 없는 프로젝트 가지고 참 오래도 삽질을 한다는 생각이 든다. 그만큼 공부가 되는 부분들이 많긴 하지만... 참 쓸데없다...

남들에게 보여지길 원하는 컨텐츠 에서의 원칙들

1. 컨텐츠에 접근하게 되는 방식들을 다양화 시켜라. 검색엔진, SNS, RSS 등 여러방식의 접근방식을 제공해라.
2. 그런 최종 목적지가 되는 컨텐츠엔 반드시 고정된 URL 이 존재해야 하고, 이는 HTML 형태로 제공되어야 한다. 그래야, SNS 등에서 링크로 접근이 가능하고, 검색엔진에서 연결될 수 있다. 최종 컨텐츠는 절대 AJAX, Flash 와 같은 웹 어플리케이션의 비동기 로딩으로 제공되어서는 안된다.
3. 문단의 대표가 되는 이미지를 좌,우측 정렬 형태로 제공해서 문단의 핵심을 설명하고, 중요도에 의해서 컨텐츠를 image, video, interactive media 의 레벨로 가공하라.
4. 컨텐츠에 대한 접근 방식 자체를 꾸미기 위해 노력하기 보다는, 컨텐츠 자체를 정보 시각화, 대화형 미디어로 가공해서 흡수율을 높여라. 컨텐츠 접근 방식 자체가 다양화 되는 시대에서는 네이게이션이 되는 UI 자체에 들어가는 품을 줄이고, 컨텐츠 자체를 고급화 시키는 것이 옳은 투자 방식이다.

현재 내가 느끼는 웹의 변화를 바탕으로 기준들을 정하고 바탕으로 원칙들을 정하고 있는데, 막상 현재까지의 플래시들이 대부분 컨텐츠 자체 보다는 컨텐츠를 찾아가는데 필요한 네비게이션 행위에 촛점을 맞춰 발전했었기 때문에, "실질적인 수익" 에 대한 가치관과 원론적인 가치관이 충돌하는 것 같다. (뭐 쉽게 이야기해서 맞는 말이긴 한데... 이게 돈벌이가 될까? 라는 느낌?)

일단... 내 홈페이지를 만드는데 있어서 에러가 생기네... 컨텐츠를 가공하는 작업 비율보다 홈페이지 자체를 멋드러진 UI 로 만드는 작업 비율이 높았었는데... 뭔가 골치가 지끈거린다.

모든 생각의 기준을 자신의 이야기를 들어주기 원하는 컨텐츠 제공자와 그 이야기를 듣는 컨텐츠 소비자의 관계 설정에 맞추려고 하고 있다. 현실적인 고정관념들을 버리고 그렇게 원론적인 단계에서 부터 다시 되짚어가려고 한다.

그것이 내가 플래시 개발자가 아니게 된다고 해도... 소비자에게 유리한 것이 플래시가 아니라면 그만두는 것이 옳겠지... 기술에 매이기 보다는 보다 원론적인 단계에서 서비스를 생각하고, 그것을 어떻게 제공할 것인가에 대한 기술적 관념을 가지기 위해서 노력하려 한다...

일단... 플래시라는 나에게 유리한 기술에 대한 집착부터 버리는게 첫 번째다. 첫 번째를 나에게 유리한 것 보다는 서비스에 유리한 것으로 재설정 해야만 옳게 생각할 수 있다. 잡념과 집착을 떨치자...

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 라는 툴 자체의 생명이 위험해질 수 있지 않을까 싶다...

이번에 개인적으로 사용할 플레이어를 만들기 위해서 어도비에서 진행중인 OSMF 를 사용해서 플레이어를 만드는데... 예전에 일하면서 겪었던 고생이 눈물이 날 정도로 쉽더라...

이건 뭐... 걍 model 이 되는 mediaPlayer 에 이벤트만 죽죽 걸어서 view 가 되는 GUI 디자인과 연결시키기만 하면 되니...

동영상 플레이어 하나 만드는게 이렇게 편리할지 예전엔 미처 생각하지 못했을 정도로 편하다.

좀 귀찮은 작업들이 있긴 하지만, OSMF 자체가 image viewer 역할과 sound player 역할까지를 동시에 해주기 때문에 원한다면 모든 미디어 관련 파일들을 통합처리하는 기능도 손쉽게 만들 수 있다. 아... 세상 많이 좋아졌네... 라는 느낌이 든다.

적어도 플래시에서 미디어 플레이어 만드는 일은 더이상 "돈될 거리" 가 되지 않을 것 같다. 가장 빈도 높게 터지던 일 중에서 하나가 오픈소스 라이브러리를 통해서 사라져버리는구나...

뭐 결과는 대충 쓰는데 불편함이 없다는 것이었다. 16:9 의 비율비를 맞추느라고 타블렛의 아랫면이 조금 잘린다는게 문제였지만 그다지 심각한 수준은 아니었다.

16:9 비율의 모니터를 왜곡없이 타블렛 면에 맞추기 위해서는 위에 보이는 환경설정에서 우하단쯤에 보이는 "가로 세로비율을 유지" 에 체크를 해줘야 한다. 그러면 타블렛의 하단부분의 일부가 인식되지 않으면서 16:9 의 비율에 딱 맞게 맵핑이 되게 된다.

모든 답 안나오는 논쟁의 공통점은 장님 코끼리 만지듯 하기 때문이 아닐까 싶다. 플래시에 대한 논쟁이 열렬하면서 동시에 아무런 대책도 내놓지 못하는 이유는 플래시라는 코끼리에 대해 모두 단면적인 답안만을 내놓고 있기 때문이 아닐까 싶다.

애플(이라고 쓰고 스티브 잡스라고 읽는게 편한 원맨쇼 기업)이 주장하는 플래시의 단점은 충분히 이해할만한 일이다. 플래시, 플렉스를 개발하는 이들이라면 누구나가 "성능 때문에 미쳐돌겠다!!!" 라고 이야기한게 벌써 몇 년째이던가... 플래시를 개발하는 나 스스로도 성능이 낮은 컴퓨터에서는 플래시 차단 플러그인을 통해서 플래시를 막을 정도로 플래시의 성능은 지옥에 가깝긴 하다.

플래시를 "제대로" 쓰면 플래시는 전혀 문제 될 것이 없는 훌륭한 기술이다. 라는 플래시 관련 업계의 의견도 틀리지 않다. 플래시가 미쳐 돌만큼 돌아가는 것을 동영상과 자바스크립트를 통해 만든다고 생각해보라... 그것은 더더욱이 생각하기 섬뜩할 만큼의 지옥이 될 수도 있다. 자바스크립트로 단순히 alpha 트랜지션을 쓰는 것만으로도 IE6, IE7 과 같은 브라우저는 끔찍한 버벅임을 준다... 플래시가 "미쳐 돌아가는 컨텐츠" 를 소화 할 수 있는 것은 그만큼의 성능이 뒷받침 되기 때문일 수도 있다. 제대로 썼을때 플래시가 보여주는 퍼포먼스는 웹 클라이언트 스크립트의 그 어느것도 따라오기 힘든 수준을 보여준다.

하지만... 제대로 쓰이지 않는 것이 현실이기도 하고... (까놓고 이야기해서 플래시 관련 개발자들이 가장 많이 하는 소리가 "이렇게 만들면 정말 느려요!" 다... 지금껏 그 어느 프로젝트에서도 이 말을 하지 않았던 적이 단 한!번!도! 없었다.)

플래시가 사라져야 한다고 이야기 하는 사람들의 많은수가 "왜 웹에서 그런걸 보여줘야 하는데?" 라는 의견을 내세운다. 하지만... 이것은 틀린말이다. 필요성이 있기에 쓰이고 있는 것을 주관적인 입장에서 "그딴건 없어도 난 잘 살 수 있어" 라고 무시하는 것은 틀린 말이다. (이런 극단적 사고는 모든 논쟁에 있어서 불필요한 의견 단절만을 낳게 된다. 말그대로 배째라 라고 드러누워서 귀막고 있는 것과 다를바 없는 사고 방식이다...) 영화 프로모션 사이트가 html 로 심심하게 보여지면 누가 매력을 가질 수 있겠나... 웹을 소비하는 이들의 대다수가 단순하고 심플한 구글스러운 사이트만을 소비하는 것은 아니다. 소비를 충족시키지 못하는 기술은 그 의미가 없다... HTML5 는 훌륭한 기술이지만 플래시처럼 멀티미디어에 촛점이 맞춰진 기술은 아니다. canvas 가 RIA 를 대체할 수는 있어도, 인터렉티브 미디어의 많은 부분을 차지하는 플래시를 대체할 수 있는 기술은 전혀 되지 못한다. (왜 자꾸 html5 지랄을 하는지 모르겠지만... html5 가 훌륭하긴 하지만, 플래시와 종이 틀린 기술이라고 본다. 웹 어플리케이션, 멀티미디어 재생의 편리함을 목표로 하는 것이지, 플래시와 같은 인터렉티브 미디어의 극상을 추구하지는 않는다...)

나 역시도 플래시가 현재 데스크탑 베이스의 인터넷에서 모바일 디바이스로 이동해가는 시점의 인터넷에 어울리지 않는다고 본다. 그렇다고 플래시 자체가 사라져야 하는가? 라는 물음에는 그렇지 않다 라고 자신있게 대답할 수 있다.

쉽게 정리하자면 플래시는 사라져야 하는 기술인가? 라는 의문에는 yes 라고 이야기 하겠지만, 플래시와 같은 역할을 하는 기술이 사라져야 하는가? 라는 의문에는 no 라고 이야기를 한다는 것이다.

많은 이들이 원하는 대답은 "대안" 이 아닐까 싶다. 그것은 플래시가 보다 효과적으로 변화하든지, 아니면 플래시를 대체할 기술이 등장하든지... 둘 중 하나다. 어쨌든 플래시와 같은 기술은 필요하다. 플래시가 좋냐 나쁘냐 따위의 논쟁은 사실상 무의미 하다...

웃기는 이야기지만 많은 이들의 플래시의 단점으로 광고를 이야기한다... 플래시가 사라진다고 광고가 사라질 거라고 생각하는가? 플래시가 사라진다고 포털사이트에 덕지덕지 붙은 광고들이 모두 사라지거나 아니면 이미지 한장, 텍스트 한줄로 바뀔 거라고 생각하는가? 잘 생각해보라... 플래시가 사라진다면 그 자리에는 또다른 무언가를 통해 그와 같은 광고가 표현될 것이다. (그래 많은 이들이 그토록 찬양하는 html5 의 코덱을 내장해서 멀티미디어 기능이 표준화된 video 가 활성화 된다면 그나마 플래시로 표현되던 광고들의 자리가 몽땅 동영상이 될지도 모르지... 과연 그게 빠를까? 응? 그렇게 하면 브라우저 다운이 안될까?) 도대체 뭘로 장사하고 있다고 생각하는건가? 도대체 왜 광고가 쓰이고 있다고 생각하는건가?

플래시가 좀 심하다 싶을 정도로 웹의 공해를 만들어내고 있다는 점에는 동의가 안된다. 그것은 "계산이 맞아 떨어지기에 플래시가 사용되어지는 것이지 플래시 자체가 광고를 만들어내고 있는 것은 아니다."

플래시의 성능 문제는 플래시 플레이어의 개선을 어도비가 이루어나가든, 그 자리를 메꿀 다른 기술이 등장하든 해야하고, (물론 플래시가 가진 잡기의 제왕과 같은 포스를 쉽게 따라잡는 기술이 등장하기는 쉽지 않은 문제이긴 하지만...) 플래시의 보안 문제와 같은 것은 맥에서 자바가 표준업데이트에 포함되는 것처럼 OS의 업데이트에 포함이 되는 타협으로 해결해나갔으면 하는 바램이 있다. (사실 플래시 플레이어의 업데이트 문제는 정말 골치 아프다...)

플래시가 사랑받는 이유는 자유롭게 원하는 것을 표현할 수 있어서이다. 모태기술로서 플래시는 지금까지 아주 훌륭한 역할을 해냈다고 본다. 시대가 새로움을 원하고 있기에 플래시의 존재가 위태위태 해졌지만, 플래시가 해온 많은 새로운 시도들은 어쨌든 이후의 시대에 많은 영향을 미칠 것이다. 너무 자유로웠기 때문에 자유롭게 인터넷을 망치는 주역이 되기도 했지만...

플래시가 변화의 물결앞에 어떻게 변화해나갈지는 앞으로도 관심있게 지켜봐야 하는 문제가 아닐까 싶다. 그 역할을 대신할 다른 무엇인가가 등장할지도 관심있게 지켜봐야 할테고...

플래시는 사라져도... 어쨌든 인터렉티브 미디어 기술 자체가 사라지지는 않는다. 아니... 사라져서는 안된다.

관련글

Flash Interactive UI 의 전망은 승리 혹은 죽음…
아이패드와 플래시를 둘러싼 시장변화

대충 서식들을 정리하고 디자인을 맞췄는데, 이런식으로 가다간 꽤나 골아파 질수도 있겠구나... 기술적으로 어렵지 않더라도 시간이 소요되는 일에 대해서 명확히 파악을 해야겠구나... 라는 생각이 들었다.

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

대충 이전보다는 모양새가 다듬어졌다. 아직 크로스브라우징 체크를 안해봐서 좀 난감하긴 하지만...

바로 이 모양의 아이콘이 광고의 그림으로 올라왔었는데, 뭔가 자세히 생각을 해보니

내가 폴더 아이콘으로 쓰고 있는 그림이더라...;;; 뭔가 문서를 여러겹으로 쌓아놓은 아이콘 모양이라서 폴더 아이콘으로 쓰고 있었는데, 이 아이콘을 보게 되니 호기심이 생겨서 광고를 클릭하고 들어가 Things 에 대해서 알아보게 되었다.

대충 스케쥴 관리 프로그램인데 GTD 를 따르니 어쩌니 하길래 뭔소린가 해서, GTD 에 대해서도 검색해서 알아보았다.

프로그램의 구성은 아주 간단했다. Inbox, Today, Next, Scheduled, Someday, Projects 로 나뉘어져서 좀 복잡해 보이는데,

Inbox

일단 뭔가 할 일이 생각날때 바로 Inbox 를 통해 적으면 된다. 메일의 Inbox 라기 보다는 Temp 라는 것이 좀 더 어울릴 것 같은 느낌인데, 뭔가 할 일이 생각났을때 아무런 조건분류 없이 그냥 할 일에 대해서 죽죽 쓴다고 생각하면 된다.

Today, Next, Someday

이 세가지 기준은 "오늘 할 일", "모든 할 일", "언젠가 해야할 일" 이라고 볼 수 있다. Inbox 에서 생성된 할 일에 대해서 시점을 부여하는 일이라고 볼 수 있다. 그리고, 각각으로 분류된 할 일들은 리스트로 정렬되있고, UI 적으로 리스트의 순위를 변경 시킬 수 있는데, 이 순위변경은 "할 일의 우선순위" 가 된다.

할 일의 시점과 중요도가 이 작업을 통해 부여되게 된다.

Projects

이 것은 뭐 쉽게 이야기해서 할 일들의 그룹 이라고 볼 수 있는데, Today, Next, Someday 의 시점기준과는 다른 일의 분류적 기준이라고 볼 수 있다. 만들어진 할 일에 프로젝트 분류를 부여하면 그 할 일이 해당 프로젝트로 종속되게 되는 것.

Areas

뭐... 기준이 좀 모호하다. Projects 와 비슷한 의미의 그룹이긴 한데... 프로젝트와 할 일 모두를 포함 시킬 수 있다. 내 경우에는 거시적 기준 "목적" 을 Area 로 생성하고, 그 목적을 이루는데 필요한 해야하는 일들을 Project 로 생성해서 구분했다.

Logbook

뭐 끝을낸 할 일들이나 프로젝트들을 기록하는 곳이다. 내가 뭘 해왔는지 알 수 있는 그런 기록?

뭐 대충 "할 일"이 생각나면 Inbox 에 마구잡이로 적어버리고, 시간될때 그 할 일 들에 시점을 부여해주고, 시점이 부여되고 난 이후에는 순서를 바꿔서 우선순위를 정해주면 된다.

그리고, 나머지는 그 시점과 우선순위의 안내에 따라서 할 일들을 처리해나가면 되고... 이게 가장 핵심적인 방식이라고 볼 수 있다.

프로젝트 분류나 에어리어 분류는 부차적인 문제라고 볼 수 있다. 할 일들을 정리해서 보기 위한...

기존에 시점으로 접근해서 할 일을 적는 방식에서 거꾸로 할 일을 생각하고 시점을 부여하는 이런 방식은 나와 같이 "부여되는 일" 을 하지 않고, "일을 만들어서 해야하는" 사람에게 꽤나 잘 맞아 떨어진다는 느낌이 든다.

데이터가 싱크되는 아이폰용도 있다.

기존에 여기저기 산발적으로 흩어져 있던 task 들을 이 Things 로 통합시키기 시작했다. 기본적으로 (맥용 프로그램인) Things 가 존재하고, 아이폰에서 데이터를 싱크시켜 사용할 수 있는 Things for iphone 이 있다. 지금껏 구입한 프로그램 중에서 윈도우 시절 백신 빼고 제일 비싼듯... (Things 가 대략 5만 5천원, Things for iphone 이 대략 1만 2천원 정도이다...)

기술적으로 아쉬운 점

아쉬운 점이라면 아무래도 "알림" 과 "Eclipse Mylyn" 을 통한 SVN, Task 통합이 아닐까 싶다.

iCal 처럼 알림을 지원해준다면 좋겠지만... 그렇지가 않다. 뭐... 내 행동의 기준을 모두 이 Things 에 맞춰서 움직이게 될테니 별 상관이 없긴 하지만... 정확한 시점에 뭘 해야하는지 알려주는 달력 기반의 스케쥴 관리가 조금 아쉽기도 하긴 하다. (하지만... Things 자체가 날짜 까지만 입력하게 되는 방식이라서... 어짜피 알림을 지원할 가능성도 없다.)

가장 아쉬운건 역시나 Mylyn 을 통한 task / source 통합... 이건 뭐 방법이 없으니... 별 수가 없을 것 같고... 어짜피 귀찮기도 했으니 다 때려치고 SVN 만 쓰련다.

당분간 약속 같은 시간이 정확해야 하는 스케쥴은 iCal(with Google calendar) 를 쓰고, 하루를 기준으로 뭘 해야하는지를 확인하는 것은 Things 로 관리를 할 생각이다. 어짜피 시간 스케쥴 보다는 할 일을 기준으로 하는 스케쥴이 많은 나인지라 거의 Things 만 쓰게 될 것 같긴 하지만...

그리고, 서버상에 데이터를 저장하는 클라우드 데이터베이스 형식이 아닌, Mac 과 iphone 을 직접 싱크하는 방식이라는 점이다. 정보량이 그다지 크지도 않은 서비스인데 이왕이면 EverNote 와 같이 어플리케이션은 무료이고, 서버 스토리지를 임대하는 형식의 서비스가 되었어도 괜찮지 않았을까 싶은데... 뭔가 잘 이해가 안된다는 느낌이 들긴한다.

논리적으로 아쉬운 점

가장 가장 심하게 아쉬운 점은 "할 일" 에 대해서 처리된 결과를 "Complete" 만을 지원한다는 것이다. "성공" 과 "실패" 의 두가지 기준으로 결과를 남길 수 있다면 좀 더 큰 활용도를 만들 수 있을 것이라고 생각하는데...

그것이 지원되지 않는 것이 꽤나 아쉽다.

프로그램도 간단한데... 언제 시간나면 만들어버려야지...;;;

Textile 이나 Markdown 과 비슷하게 작동하는 녀석이고, 개인적으로 만든 이유는 HTML 중심의 설계가 된 여타의 마이크로 포맷과 다르게 Flash 에서도 쉽게 파싱할 수 있고, 모듈을 통해서 문법을 구조적으로 확장 할 수 있게 했다. (뭐 좀 더 쉽게 이야기해서 범용성을 고려해서 자유도가 높게 만들어진 다른 포맷들과 다르게 좀 더 규칙이 단순하면서 까다롭게, 그 대신 구조는 쉽기에 확장이 쉽게 만들었다.)

프로젝트의 서브 프로젝트라서 대충 작업하려고 했는데, 작업을 진행하다 보니 의외로 분량이 꽤 되어서 시간이 꽤 걸렸다. 이제 겨우 as3 버전의 기본 파서를 작업했고, 앞으로 css 룰과 몇 가지 모듈들을 추가 작업한 뒤에 as3 버전의 DisplayObject 로 파싱하는 녀석을 하나 만들고, js 버전으로 포팅을 시키면 끝이 날듯 싶다. (아직 까마득하다는 이야기...)

http://code.google.com/p/stutter-as/

http://ssen.name/codeZone/stutter/sample.txt
이와 같은 문서를

http://ssen.name/codeZone/stutter/StutterHTMLTest.html
이런 식으로 해석해주게 된다.

이전에 Textile 파서를 만들면서도 그렇고, 이번 Stutter 를 작업 하면서도 그렇고 마이크로 포맷의 파서를 만드는 일이 거의 정규식으로 도배를 하는 일이라서, 정규식을 정말 원없다 싶을 정도로 공부하게 된 것 같다. 이젠 어지간한 정규식 룰은 아주 쉽게 만들 수 있지 않을까 싶을 정도로...;;;;