쎈과 서연이의 행방불명 난 이런 사람이야. 지금 이 시간에는 말이지…

23/100

Stutter with iphone

http://ssen.name/codeZone/stutter/test.php

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 베이스로 옮길 생각이다.

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

242/100

웹을 설계하는데 있어서의 몇가지 원칙들

나 스스로가 지키려고 노력할 웹의 설계원칙들이 필요할 것 같아서 정리 중이다.

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

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

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

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

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

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

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

222/100

Processing.js 가 보여주는 Flash 와 Canvas 의 미래

개인적으로 수학에 관련된 지식이 많이 부족해서 여러번 수학공부에 도전하긴 했는데, 시간이 지나면 잊어먹고 시간이 지나면 잊어먹고 하기 때문에 많이 힘들었었다. 샘플 소스들을 만들면서 지식을 축적해두곤 했는데 소스파일 형태의 지식축적은 아무래도 시간지나 다시 보기 힘들다는 문제점이 있었고, 그래서 만드는 중인 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 라는 툴 자체의 생명이 위험해질 수 있지 않을까 싶다...

202/100

OSMF

동영상 플레이어를 만든다는건 상당히 짜증나는 일이었다. (과거형으로 표현한다는 것 만으로도 내용을 짐작할 수 있을듯...) 예전에 일로 동영상 플레이어 하나를 만드는데 고려해야 할 점들이 상당히 많고 계산하기도 귀찮은면들이 많아서 만들기 상당히 피곤했었는데 이는 "디자인이 달라야 하지만, 만드는 플레이어 내용은 똑같은" 플래시에서 처리하기 상당히 귀찮은 반복작업 이었다.

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

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

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

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

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

FireStats icon Powered by FireStats