RoughlyDrafted Magazine

casaubon · 2010-02-21, 02:36 AM

Saturday, February 20, 2010

Inside Apple's iPad: Adobe Flash

By Daniel Eran Dilger
Published: 12:00 AM EST

Apple's new iPad is being criticized for lacking the capacity to render interactive content built using Adobe's Flash platform, but the company shows no sign of reversing course.

2007년, 아이폰은 데뷔할 때부터 플래시를 지원하지 않았다. 그 때 이후로 어도비는 플래시에 대한 관심을 일깨우려는 캠페인을 활성화시키기 시작하였다. 윈도모바일과 노키아S60/심비안, Palm WebOS, 안드로이드용 플래시 10.1 런타임 발표도 여기에 해당된다. (그러나 RIM의 블랙베리는 여기에 끼지 않았다.) 즉, 플래시 지원이 없다 함이 아이패드에 문제가 될 수 있음을 주장하고자 하는 캠페인이다. 어도비는 또한 애플이 아이폰 플랫폼에서 플래시를 선택하지 않은 이유가 애플의 불공정한 제한때문이라는 분석가와 전문가들의 입을 빌고 있기도 하다.

또 있다. 어도비는 HTML5와 관련, 웹의 개방표준을 지원한다고 말을 하고 있긴 하지만, 플래시가 "웹이 매우 중요(critical)"하다는 입장을 견지하고 있다. 즉, 플래시 플랫폼의 폐쇄형 구조에 새로운 컨텐트를 확보함으로써 그 지위를 공고화하려고자 함이다. 이는 플래시 관련 플랫폼인 플렉스, 그리고 AIR 구상에도 이어진다.

Will being Flash-free hurt the iPad?

휴대기기 부문에서 플래시에 대한 어도비의 주장은 지지를 받기 힘들다. 아이폰은 플래시 지원 없이도 이미 대성공을 거두었기 때문이다. 애플 아이폰은 휴대폰용 웹브라우저에 대한 소비자들의 기대치를 한껏 올려 놓았다. 플래시 없이도 이렇게 해 놓았기 때문에, 애플은 웹이 어떻게 보여야 한다는 정의를 다시 내렸다고 할 수 있다. 적어도 휴대기기 부문에서 말이다.

데스크톱 PC용으로 디자인한 플래시 컨텐트를 렌더링할 수 있는 휴대기기들도 있기는 하다. 그러나 어도비의 휴대기기용 플래시 전략은 원래 아이폰보다도 먼저 나온 플래시 라이트(Lite)였다. 어도비의 옛날 플래시 7(MX 2004)와 액션스크립트 2.0 바이트코드에 기반하는 플래시 런타임의 일종이 바로 플래시 라이트이다. 그러나 여기에 문제가 있었다. 어도비의 플래시 9/10은 액션스크립트 3.0 바이트코드를 사용하기 때문에, 액션스크립트 가상머신이 완전히 뒤바뀐다는 점이다.

데스크톱 상에서 어도비는 예전 플래시는 물론 현대적인 컨텐트도 돌리기 위해 엔진 두 개를 포함시키기만 하였다. 그러나 휴대기기에서는 그렇게 단순한 해결책이 여의치 않다. 휴대기기의 제한적인 프로세서와 메모리 자원때문이다.

기본적으로 어도비의 플래시 라이트 전략은, 각 모바일 플랫폼별 플래시 런타임을 따로 만드는 대신, 휴대기기에서 플래시 컨텐트를 돌릴 수 있도록 하는데 있었다. 그러나 어도비는 리눅스나 PS3의 NetFront 브라우저, Wii의 오페라, 그 외 여러가지 모바일 플랫폼용은 고사하고, 윈도 PC와 맥오에스텐용 플래시를 지원하는 데에도 어려운 시간을 보내고 있는 지경이다.

어도비는 액션스크립트 3.0 바이트코드를 지원하는 플래시 11이 모든 데스크톱과 모바일 플랫폼(블랙베리와 아이폰, 아이포드 터치, 아이패드를 제외)에서 곧 돌아가기를 바라고 있다. 하지만 제일 빨리 자라나고 있는 모바일 플랫폼, 그리고 제일 대중적인 스마트폰 플랫폼 두 가지를 모두 제외했다는 점은 정말 문제를 일으킬 수 있다. 어도비 기술을 사용하다가는 최고순위의 모바일 플랫폼 컨텐트를 만들 수 없게 되어버리기 때문이다.

아이폰은 플래시를 지원하지 않는다. 그렇다고 해서 아이폰이 안팔리지는 않았다. 설사 다른 플랫폼이 플래시를 열광적으로 지원한다 하더라도, 오히려 휴대기기용 플래시의 중요성을 깎아내리는 역할을 수행하고말았다. 다른 플랫폼 개발자들이 플래시를 모바일 사용자들에게 보여주려 하더라도, 윈도모바일과 안드로이드, 심비안 등의 네이티브 소프트웨어를 만드는 대신 플래시로만 보여 주어야 한다. 즉, 여전히 애플의 우위다. 애플의 앱스토어가 다른 경쟁사들보다 한참 앞서 있기 때문이다.

Is Apple being unfair to Adobe and restricting choice?

아이폰 OS가 플래시를 지원하지 않는 데에 따르는 두 번째 문제가 있다. 애플과 같은 플랫폼 업체는 자기가 뭘 지원할지, 뭘 지원하지 않을지 정할 권리를 갖고 있기 때문이다. 어도비는 애플이 소비자들에게 선택권을 줘야한다는 입장이다. 즉, 웹을 사용하는 거의 모든 다른 기기들과 마찬가지로, 플래시 런타임을 아이폰이 포함시켜야 한다는 의미다.

흥미로운 주장이다. 플래시의 역사를 보면, 애플이 그저 약자를 박해하는 것이 아니라, 미디어 유통에 대한 자신의 지위를 다시금 재천명하고 있다고 볼 수 있기 때문이다. 1991년, 데스크톱 상 영상과 애니메이션, 멀티미디어를 퀵타임으로 소개한 곳은 애플이었다. 마이크로소프트가 윈도 PC에서 신뢰성 있는 오디오 재생력조차 보여주지 못하던 시절이었다.

The Origins of Flash

플래시는 원래 휴대용 펜 컴퓨팅 기기용 그리기 앱으로 구상했던 SmartSketch라 불렸었다. 이 스마트스케치는 매킨토시와 PC 플랫폼용으로 나와 어도비 일러스트레이터, 앨더스 프리핸드와 경쟁을 벌였다. 거대한 경쟁제품들과 싸우기 위해, 스마트스케치는 1996년, FutureSplash Animator라 불리우는 애니메이션툴과 합병하였다.

그리고 그 당시 웹이 새로운 플랫폼으로 나타나자, 개발사인 FutureWave는 썬 자바를 통해 애니메이션 툴을 만들려 했지만 속도가 엄청나게 느렸다. 당시 넷스케이프는 브라우저 플러그인용 API를 발표해 놓은 상태였고, FutureWave는 FutureSpalsh 컨텐트용 네이티브 플러그인을 만들어 놓았다. 애플은 이미 퀵타임 플러그인을 제공해오고 있었고, 이용자들은 퀵타임을 이용, 비디오나 웹 페이지의 다른 컨텐트를 볼 수 있었다.

Microsoft's war on the open web

웹이 대중화되어가자, 마이크로소프트는 개발자의 관심을 윈도 플랫폼으로 돌리기 위해 노력을 기울이기 시작한다. 일단 넷스케이프를 부수기 위해 인터넷 익스플로러를 활용하였고, 인터넷 익스플로러는 웹을 윈도에 묶어두는 역할을 하였다. 그 후 마이크로소프트는 썬과 파트너쉽을 맺은 다음, 썬 자바를 썬에게도 떼어내어 윈도에 의존하도록 하였다. 비디오 영역에서는 애플 퀵타임을 베끼려 시도하기도 하였다.

웹과 관련있는 이 세 가지 모두에게 있어서 마이크로소프트가 원수인 셈이지만, 퀵타임에 대해서만은 마이크로소프트가 죽일 수 없었다. San Francisco Canyon 스캔들 사건으로 인해 마이크로소프트가 애플 코드를 베꼈다는 점이 드러났기 때문이다. 덕분에 애플은 법적 근거를 갖고 마이크로소프트를 강하게 공격하였고, 마이크로소프트는 이에 반응하여 오피스를 윈도용으로만 집중한 채, 맥용 오피스 지원은 한참동안 하지 않았다.

이와 동시에 마이크로소프트는 인터넷 익스플로러를 통해 얻게 된 힘으로, 퀵타임 호환성 문제를 일으켰다. 퀵타임용 컨텐트가 있는 웹을 읽어들일 수 없도록 만든 것이다. 1996년, 마이크로소프트는 디즈니와 매크로미디어, 퓨처웨이브와 함께 개방형 웹을 폐쇄형 컨텐트로 만들기 위한 연합체를 발족시킨다. 그 결과 매크로미디어는 퓨처웨이브를 인수하였고, 플래시라는 제품이 나오게 된다.

Flash displaces QuickTime

1998년, 개방형 MPEG-4 사양으로 애플 퀵타임 컨테이너 사양을 채택하긴 했지만, 마이크로소프트는 인터넷 익스플로러를 통해 웹용 비디오와 애니메이션을 제공하는 폐쇄형 방식으로 플래시를 유통시켰다.

한 때 매크로미디어와 플래시에 대한 직접적인 경쟁사였던 어도비는 마이크로소프트-매크로미디어 연합체에 반격하기 위해 SVG를 웹애니메이션의 개방 사양으로 대응하였다. 단, 어도비는 플래시를 얻기 위해 매크로미디어를 인수하기에 이르른다.

비디오 재생에 있어서 플래시가 지배적인 방식으로 떠오르자, 마이크로소프트는 고유의 방식인 실버라이트 작업을 시작한다. 개방형 웹표준을 웹플러그인에 의존적인 바이너리로 바꾸려는 시도였다. 애플과 구글, 그 외 다른 기업들은 개방표준인 HTML5를 지지하였다. 플러그인 없는 멀티미디어 제공을 위한 표준이 HTML5이며, 브라우저 자신이 MPEG-4 개방사양에 따라 비디오를 렌더링한다.

이러한 역사를 보면, 플래시 지원을 반대하는 애플의 입장이 유명한 플러그인에 대한 공격이 아니다. 선택의 제한도 아니다. 웹상에서 개방표준을 사용하기 위한 노력일 따름이다. 그럴 경우 소비자 선택에 대한 진정한 시장이 열리기 때문이기도 하다. 어도비가 멀티미디어 재생 통제를 하는 것이 아닌, 정말로 개방표준에 흥미가 있다면, 플래시를 한 때 자사가 소유했던 PDF처럼 풀어 놓아야 한다.

그러나 HTML5를 지지하는 입장이라는 말을 하면서도, 어도비 CEO, 나라옌(Shantanu Narayen)은 HTML5에 대해 이런 말을 덧붙였다. "브라우저간에 HTML5를 어떻게 일관성있게 보여주느냐, 이것이 HTML5의 문제가 될 수 있으리라고 봅니다. 요새 많이들 거론하고 있는 현재의 계획을 보면 브라우저간 HTML5 표준화가 이뤄지기까지 10년은 걸릴 것 같더군요."

Is Flash critical to the web?

HTML5 표준이 앞으로 "10년" 더 남았다는 것이 어도비의 입장인 셈이다. 플래시가 앞으로도 주요 역할을 해야 하기 때문이다. 그러나 지난 3년간 아이폰과 아이포드 터치는 플래시 없이 대성공을 거둘 수 있음을 증명하였다. 즉, 아이패드가 굳이 플래시를 지원하지 않더라도 문제가 없으리라는 의미다.

다시 말해서, 어도비는 플래시 개발자 지원과 라이센스를 거론하지만, 플래시 컨텐트로서 중요한 지위를 차지하는 것은 데스크톱 이용자들일 따름이다. 플래시 라이트가 요새 플래시 컨텐트조차 돌리지 못하기 때문이다. 플래시가 그만큼 데스크톱에 초점을 기울였기 때문이며, 플래시 애니메이션 대부분은 휴대기기용으로 스케일-다운 디자인조차 해놓지 않고 있다. 플래시 컨텐트는 멀티터치 디스플레이보다는 마우스 포인트 위주로 디자인이 되어 있고, 런타임 또한 데스크톱-급의 컴퓨팅 리소스를 소모한다. 배터리 수명 보존을 위해 최대한 리소스를 절약해야 하는 휴대기기용이 아니다.

Activity Monitor를 한 번 돌려보시라. 플래시를 웹페이지 안에서 조금만 사용하더라도, 거대한 리소스를 잡아먹게 된다. 그린피스가 합법적인 환경지킴이라면, PVC나 BFR보다 플래시가 환경에 더 큰 위협이라는 점을 알아야 한다. 정말 가치 없는 것을 보는데 막대한 리소스를 사용하기 때문이다.

Flash on the wane in video delivery

웹에서 플래시의 비중은 감소중이다. 웹비디오 대부분은 한 때, FLV(플래시의 폐쇄형 네이티브 미디어 컨테이너) 안의 폐쇄형 코덱, On2를 사용하여 인코딩하였는데, 향후 개발은 MPEG-4 컨테이너(애플 퀵타임 컨테이너 포맷에 기반을 둔다) 안에서 H.264 코덱으로 이루어질 것이다.

어도비조차 F4V라 부르는 MPEG-4 컨테이너를 따로 마련하여 H.264 비디오를 지원하기로 하였다. 이 때문에 비디오를 전달하기 위해 꼭 플래시를 필요로할 이유가 없다. 구글도 유튜브의 플래시 영상을 H.264로 이주중이다.

Flash and Rich Internet Applications

어도비는 플래시를 RIA(Rich Internet Applications) 제공 방법으로서 플렉스와 에어, 그리고 전통적인 출력물의 인터랙티브 버전으로 밀고 있다.

이와 반대로 애플은 아이패드용 컨텐트 제작에 있어서, 출판업체들과 컨텐트 업체들이 HTML5를 사용하도록 독려하고 있다. 컨텐트에 인터랙티브 기능을 넣는 것만으로 어도비에 세금을 내지 않도록 말이다. 애플 자신이 HTML5의 거대한 후원자이기도 하며 MobileMe처럼 자바스크립트 프레임웍을 사용, RIA를 만들기도 하였다. (MobileMe의 경우, SproutCore를 사용하여 만든 웹앱이며, 그 외 음반사와 영화사들과 파트너를 맺어 아이튠스 LP, Extras를 만들고 있다.)

구글 또한 HTML5를 이용한 RIA 개발을 선도하고 있다. 이는 크롬OS의 전략이기도 하다. 구글 직원들은 안드로이드의 유사-자바 플랫폼을 결국 HTML5로 바꾸기 위한 디딤돌 정도로 묘사하고 있다. 애플이 Cocoa Touch 아이폰 OS 플랫폼을 묘사하는 바와 마찬가지의 장기적인 플랫폼 전략이다.

Apple's preference for open over Adobe Flash

애플은 아이폰과 아이포드 터치, 아이패드에서 플래시를 지원하지 않음으로써, 플래시와 실버라이트와 같은 폐쇄형 바이너리와 상관 없는 거대한 사용자층을 만들어냈다. 이는 애플 앱스토어 플랫폼, 그리고 개방형 웹으로 사용자들의 관심을 성공적으로 끌어냈으며, 개발자들을 표준에 기반한 RIA와 멀티미디어 개발로 이끌고 있기도 하다.

이와 반대로 구글은 웹 개방표준을 강력하게 지원하고 있기는 하지만, 안드로이드 기능으로 플래시 재생지원을 홍보하고 있기도 하다. 안드로이드용 네이티브 앱 개발 매력을 떨어뜨리는 조치이다. 마이크로소프트 역시 스타일러스에 의존적인 윈도모바일 앱을 지원하기 위해 플래시와 실버라이트를 동시에 홍보중이다. 노키아의 심비안과 리눅스 플랫폼 또한 자신의 네이티브 개발을 희생시킨만큼 플래시를 띄우고 있다.

애플은 경쟁사들이 플래시에 더 몰려들수록 휴대기기용 앱스토어에서 더 1위를 굳힐 수 있을 것임을 깨달은 것으로 보인다. 즉, 아이폰 OS 기기에서 플래시 런타임이 돌아갈 일은 앞으로 거의 없다고 봐도 될 것이다.

AppleInsider | Inside Apple's iPad: Adobe Flash

trexx · 2010-02-21, 06:32 AM

명쾌하군요. 정말 좋은 글입니다.

좋은 글 번역해 주신 까소봉님 감사합니다.

제작년 말에 연구원 대표 홈페이지 기획할때 제가 웹표준으로 가야한다고 말하니 웹 2.0으로 알아 듣고 플력스로 홈페이지를 제작하자고 하더군요. 그 업체는 제외시켰습니다.
우리나라 대부분의 에이전시의 문제이기도 하지만 아직까지 웹표준에 대한 인식이 별로 없다는 것이지요.

홈페이지 제작을 시작할때 쯤 개발자가 플래시 넣을 거냐고 물어 봤을 때 단호히 거절했습니다.

맥 사용자로서 버벅거리는 플래시를 더이상 보기 싫었고 외국에 출장갔을때 플래시때문에 로딩을 포기했었고 그 전해에 발표했던 아이폰에 플래시가 안돌아 간다고 생각하니 결론이 나왔습니다.

아무리 다른 커뮤니티에서 애플의 플래시 제외에 대한 온갓 말을 다 하지만 (정치적인 결정이내 하며)
전 애플이 영원히 플래시를 지원 안했으면 하는 사람입니다.

webkit이 더 자유로이 발전했으면 합니다.

casaubon · 2010-02-21, 09:33 AM

RoughlyDrafted Magazine

Daniel Eran Dilger in San Francisco

An Adobe Flash developer on why the iPad can’t use Flash
February 20th, 2010

Daniel Eran Dilger

Flash 구축에 대해 전문가라 할 수 있는 인터랙티브 컨텐트 개발자인 모건 아담스(Morgan Adams)가 플래시와 아이패드에 관한 흥미로운 글을 보내왔다. 나머지는 동 주제에 대한 그의 글이다.

전 왜곡되어 있다고 할만 합니다. 전문 플래시 개발자이자, 아이패드용 플래시 사이트 의뢰가 들어오면 행복해 할 테니까요. 정말 그러고 싶습니다만, 그것이 합리적이지는 않습니다. 아이패드용 플래시는 나오지 않을 것이며, 나와서도 안됩니다. 주된 이유는 그동안 거론이 안된 이유때문입니다.

현재 플래시 사이트들은 터치스크린 기기에서 잘 만들어질 수가 없어요. 애플이나 어도비는 커녕 마술과 같은 새 기기가 나오더라도 어쩔 수 없습니다.

즉, 이 이유는 느린 휴대기기의 성능이나 배터리 수명, 충돌현상때문이 아닙니다. 마우스오버, 혹은 호버(hover) 문제 때문입니다.

대다수가 아니라 하더라도, 수많은 플래시 게임과 메뉴, 심지어 비디오 플레이어에 이르기까지 플래시 컨텐트는 눈에 보이는 마우스 포인터를 필요로 합니다. 뭔가에 대한 호버링(마우스오버)과 실질적인 클릭 간의 관계에 의존하는 코딩이기 때문이지요. 이 차이는 흔한 겁니다. 인터랙티브 디자인에는 근본적이기도 하고, 널리 퍼져있기도 하지요. 플래시 컨텐트의 기본적인 사용에 있어서도 필수적입니다. 터치스크린용으로 디자인한 플래시 컨텐트를 새로 만들 수는 있겠지만, 사람들이 원하는 건 기존의 플래시 사이트입니다. 모두 다이죠. 여기는 되고 저기는 안되고, 그런 것이 아니에요. 그것도 사용할 수 있어야 합니다. 불가능한 일이에요.

애플과 어도비가 할 수 있는 일이란 것이, 현재의 플래시 컨텐트를 보이게 만드는 것 뿐입니다. 그러면 보이긴 하겠죠. 하지만 종종 작동을 안할 겁니다. 그러면 이용자들은 이게 안보인다고 화를 내겠죠. 페이지 사이에 갭이 있다거나 배너광고가 안보이고, 플래시 게임 페이지를 방문할 때마다 다시 다운로드받는 대신 앱스토어에 가서 다운로드받아야 할 때 내는 짜증 이상일 겁니다.

Mouseover examples:

* 마우스오버가 있을 때 컨트롤이 나타나거나 숨는 비디오 플레이어. (사실상의 표준같아 보입니다만 영상 가운데를 클릭하면 보통은 멈춤이지요. Hulu를 해 보십시오.)

* 클릭 없이 마우스를 돌려서 하는 게임. (매우 일반적입니다.)

* 마우스를 메인버튼 위로 움직이면 하부 페이지 링크가 나타나는 메뉴. (클릭할 때 메인 카테고리 페이지로 직접 갈 때와는 다릅니다.)

* 마우스가 움직일 때 중요한 설명이나 요약이 나오는 버튼. 클릭하기 전에 무엇인지 이해해야 할 필요가 있을 때 나옵니다.

* 마우스오버를 통해 프리뷰를 보는 기능. 아바타용 머리 색깔을 고를 때와 같은 것입니다. 캐릭터가 마음에 들 때까지 색상을 마우스로 고르는 것이지요. 정해지면 클릭을 합니다.

* 클릭을 전혀 사용하지 않는 지도와 표. 하지만 마우스를 움직일 경우 나타나는 팝업 정보.

* 마우스만 있으면 "돌아가는" 개별 마우스오버 기능. 설명이 필요 없음.

이런 사례들을 손가락(혹은 전통적인 스타일러스)으로 올바르게 할 수가 없습니다. 터치스크린 상에서 클릭 없이 뭔가를 포인팅하는 것은 마우스오버가 아니지요. 그저 손가락을 허공상에서 움직이는 것과 마찬가지입니다. 기기가 인식하지 못하는 상황이죠.

또한 오른쪽-클릭에 의존하는 플래시 사이트도 있습니다. (보안설정과 같은 것을 위함이죠.) 물리적인 키보드를 요구하는 것도 있습니다. 특히 게임이 그러하죠. 플래시를 원하는 주된 이유 중 하나가 게임입니다. (비디오도 그럴 수 있겠지만, 비디오는 플래시 없이도 돌릴 수 있고, 그렇게 하는 사이트가 점차 늘어나고 있습니다. 플래시 비디오가 제일 아쉬울 곳은 아무래도 유튜브이겠죠.) 게임은 실질적인 키 컨트롤을 사용할 때가 종종 있습니다. 싱글 프레스(single press)와 롱홀드(long hold), 그리고 코딩(chording) 모두를 필요로 하죠. 가령 오른쪽 화살표를 누르고 있으면 계속 걸어갑니다. 이와 동시에 스페이스를 치면 불을 발사하는 식이죠. 위쪽 화살표를 치면 점프한다거나 위쪽 화살표를 계속 누르고 있으면 더 높게 점프하는 식입니다. 터치스크린 키보드는 그런 종류의 정확하고 빠른 동작을 할 수 없어요. 게다가 키보드가 게임 화면을 가리기도 할 겁니다. 터치스크린 상의 게임은 터치스크린에 어울리는 컨트롤을 넣어야 합니다.

The only potential “solutions” to the mouseover problem are terrible ones:

A) 최고의 경우: 모든 사이트의 모든 플래시 앱을 프로그래머들이 다시 디자인하고 코딩하는 것입니다. 터치스크린을 위해서이죠. 마우스오버를 더 이상 사용하지 않거나, 아예 이중 버전으로 해놓으면 되겠죠. 마우스오버가 필요한 경우 마우스를 사용할 수 있도록 말입니다. 상당한 작업이 필요할 것입니다. 수만 곳이 해야 할 일이죠. 즉, 불가능합니다. 게다가 마우스오버가 너무나 근본적이어서, 사이트 개념 자체를 바꿔야 할 곳도 많을 것입니다. 기존 이용자들이 완전히 바뀐 사이트를 사용해야 하겠죠. (그런데 단순히 플래시를 없애고 하는 디자인보다 쉬울까요 과연? 꼭 그렇지도 않습니다.)

B) 제스쳐나 손가락 움직임, 외장형 버튼으로 마우스오버를 시뮬레이션하는 것입니다. 마우스오버는 그 자체가 클릭/탭보다 더 간단하고 더 복잡하지 말아야 하기 때문에 멍청한 짓이죠. 자연스러워야 하며 새로 배울 필요도 없어야 합니다. 데스크톱을 쓰던 습관을 완전히 뒤바꿔서는 안되죠. 하지만 게임에 이르르면, 추가적인 수정도 결국 안돌아갈 겁니다. 빠르고 단순하게 반응해야 하니까요. 시뮬레이트 마우스오버 버튼을 누를 때가 언제인지, 손가락 세 개를 이용할 때가 언제인지를 기억해야 할 필요가 없어야 하는데 말입니다. 게임 자체가 매우 어려운 존재입니다. 그렇게 했다가는 재미를 상당히 빼앗아가겠죠.

C) 클릭 자체를 근본적으로, 끊임 없이 사용하는 것으로 보다 복잡하게 만드는 방안이 있습니다. 무엇이든 등록하기 전에, 더블-탭이나 두 손가락 탭을 필요로 하는 것이죠. (투 탭은 현재 모바일 사파리가 자바스크립트 팝업메뉴에 대해 사용하는 방식입니다. 첫 번째 탭을 하면 메뉴가 뜨고, 두 번째 탭으로는 메뉴를 선택하지요.) 하지만 플래시 앱과 게임 다수는 이미 더블-클릭(혹은 빠른 클릭)을 나름대로 목적으로 사용하고 있습니다. 별도의 탭은 특정 상황(메뉴 팝업)에서만 쓸모있을 따름이죠. 단순한 클릭도 아닙니다. 움직여줘야 합니다. 드래그 대 마우스오버 움직이기랄 수 있겠네요. 게임중에 시스템이 이 모든 것을 빠르고 단순하게 해낼 수 있다 하더라도, 특별한 규칙을 웹페이지의 어느 부분에 적용하는지 이용자가 어떻게 알 수 있을까요? 페이지의 일부는 스크롤이나 링크-클릭을 제대로 하고 다른 곳은 완전히 다르게 한다면요? (터치-기반의 앱이 어떻게 될지는 고사하고 말이죠.)

D) 손가락 근처에 눈에 보이는 마우스 포인터를 갖다 놓고, 직접적으로 인터랙트하지 않는 방안이 있습니다. 애플의 트랙패드 스타일이죠. VNC 클라이언트에서도 보이는 탭-드래그 제스쳐를 사용하는 겁니다. 이런 간적 컨트롤은 직접적인 터치형 조작의 원칙을 뒤흔들게 됩니다. 터치스크린이 "노트북"처럼, 그리고 노트북보다 더 안좋게 변하는 것이죠. 굳이 터치스크린을 쓸 이유가 사라지는 겁니다. 다시 말씀드리건데, 이 경우, 페이지의 어느 부분이 직접적인 터치모드인지, 아니면 "화살표 드래그" 모드인지를 계속 기억하고 있어야 합니다.

E) "리얼" 탭을 별도로 요구하는 방안이 있습니다. 즉, 가벼운 탭과 무거운 탭을 구분지어야 하게 되겠죠. 직관적이지 않아요. 오작동할 가능성도 높아집니다. (단순한 클릭만으로도 RIM 블랙베리 SurePress 실험이 실패했었습니다.) 브라우저 플러그인 하나 때문에 전체 기기를 복잡하게 만들어버리는 겁니다. 비용도 더 비싸지고요.

따라서 애플이 그냥 플래시를 거부한 것이 아닙니다. 논리적으로 지원을 할 수가 없어요. 손가락은 마우스가 아닙니다. 그런데 플래시 사이트들은 마우스 포인트(그리고 키보드)를 근본적인 방식으로 요구하는 디자인이죠. 언젠가는 바뀌겠죠. 모든 플래시 사이트를 터치스크린 친화적으로 바꿀 날이 올 겁니다만, 그렇다고 해서 지금 플래시 사이트가 돌아가지는 않을 겁니다.

성능이나 배터리 수명, 충돌 문제가 전혀 없다 하더라도(분명 문제가 있지요), 어느 회사의 터치스크린이건, 터치스크린용으로 현재의 플래시 사이트들을 제대로 즐길 수는 없을 겁니다. 불만을 가질만한 부분을 다 들어줄 수가 없어요.

그런데 저는 플래시 개발자입니다. 제가 만든 애니메이션 사이트가 최신 유행의 아이폰에서 안돌아갈 때 제 느낌이 어떻겠습니까! 그래서 전 WebKit의 CSS 애니메이션 기능을 이용하여 애니메이션을 새로 만들었습니다. 데스크톱 이용자들도 물론 adamsi.com에서 플래시를 보실 수 있죠. 아이폰 이용자들도 애니메이션을 볼 수 있습니다. 즉, 이 방식은 할 수 있는 방식입니다.

Morgan Adams, adamsimmersive
interactive design and games

Daniel Eran Dilger is the author of “Snow Leopard Server (Developer Reference),” a new book from Wiley available now from Amazon as a paperback or digital Kindle download.

An Adobe Flash developer on why the iPad can’t use Flash — RoughlyDrafted Magazine

firemanx · 2010-02-21, 06:35 PM

인터렉티브한 요구에 부응하기 위해서 플래쉬가 태어났다면 그나마 이해를 하겠습니다만, MS의 실버라이트까지 보아버린 이상, 정말 "이놈은 또 뭔가효?"라는 말을 외치게 되더군요.

진짜 악당은 역시나 MS라는 생각을 또 하게 되었지요.

상도덕이라는 말이 IT 세계에서도 먹힐지는 모르겠지만 하여튼 MS는 꼴통이 맞습니다. 그 와중에 또 뒷다리 들이 밀어서 구정물 일으키는 것을 보면요.
이제 어도비는 애가 타겠고. 애플은 상황보고 판세만 조절하면 될 듯 합니다.

플래쉬가 없어지는 것에는 여전히 찬성입니다.

잘 읽었습니다. ^^;

chansap2 · 2010-02-22, 01:32 AM

두번째 올려주신 컬럼 내용이 참 좋네요.
플래시가 무겁고 전력을 많이 소모한다는 이유보다 좀더 근본적인 이유로 느껴지네요 ^^

woozooso · 2010-02-22, 03:04 AM

언제나 빠르고 훌륭한 번역에 감사드립니다

drzekil · 2010-02-22, 07:17 AM

두번째 컬럼의 내용은 제가 여기 저기에서 많이 주장한 내용이네요..
비단 플래시만의 문제는 아닌것 같습니다.
아이패드가 아이폰 기반이 된 이유도 비슷한 이유가 아닐까 싶습니다.
맥OSX도 플래시보다는 괜찮지만 그래도 마우스 포인터가 필요하고 또한 보조클릭이 필요하게 디자인 되었으니까요..

casaubon · 2010-02-22, 07:39 AM

인용:

* 역자 주 : 2008년도 글이지만 여전히 의미가 있다고 생각하여 번역을 하였습니다. 관련 주제와 함께 생각해 볼만한 글입니다.

The new UI wars: Why there's no Flash on iPhone 2.0

TUE, JUN 17, 08

어도비는 맥오에스와 윈도 양측 모두에서 어도비 고유의 인터페이스를 지키는 것으로 알려져 있다. 그리고 맥 이용자들은 오랜동안 어도비를 비판해왔다. 어도비가 맥 네이티브 기술을 존중하지 않는다는 이유였다. 어도비는 10년이 넘게 포토샵에서 애플스크립트를 완전히 지원하지 않았으며, 윈도용 64비트 버전을 내놓을 때 맥오에스텐용 64-비트 버전도 내놓지 않았다.

Adobe's UI convergence

어도비의 목표는 언제나 플랫폼과 상관 없는 고유 UI 확립이었다. 맥과 윈도의 네이티브 UI가 아닌 세 번째의 대안인 셈이다. 이 과정 중에서 어도비는 네이티브 UI 패턴과 부딪히는 새로운 UI 컨벤션을 과감히 만들어왔다. 드림위버와 Thermo, Fireworks의 윈도 제목/메뉴바를 보면 알 수 있다.

어도비가 꽤 성공을 거두었다고 볼 수 있다. Creative Suite 4가 나오면, 어도비는 패키지 안에 있는 프로그램 대부분의 인터페이스를 두 플랫폼 모두에서 동일하게 나오게 만들 것이다.

그러나 어도비의 플랫폼 공통 웹미디어 런타임인 플래시처럼 공통적인 UI를 성공시킨 프로그램은 없을 것이다. 기괴한 "Skip Intros"에서부터 수수께끼같은 UI 위젯에 이르기까지, "정말 이런 디자인을 했단 말인가?"라는 질문을 할 수밖에 없다. 어도비는 그동안 꾸준히 플렉스 프레임웍 안의 UI 위젯과 컴퍼넌트를 확대시켜 왔으며, 웹 상의 RIA(Rich Internet Applications) 룩앤필을 정의내리는 수준까지 이르렀다. 물론 기본 플래시/플렉스 UI 컨트롤을 반드시 이용할 필요는 없다. 필요에 따라 커스텀 스킨을 사용할 수 있기 때문이다.

데스크톱 시장은 이미 성숙한 시장이다. 따라서 UI 통일화는 어도비에게 유리하게 작용할 수 있다. 하지만 어도비의 다음 싸움터는 플래시 라이트(플래시의 모바일 버전)를 심비안과 윈도모바일, 자바가 지배하고 있는 휴대기기 플랫폼용 런타임과 애플리케이션 개발 플랫폼으로 확립하는 일이다.

노키아는 올해 S60 series에 플래시 라이트 3.0을 설치해서 내놓았다.

Why not the iPhone?

수 백만 대 휴대폰에서 플래시 라이트를 돌릴 수는 있는데, 아이폰만은 플래시 라이트를 넣지 않았다.

아이폰에 플래시가 왜 좋은 선택이 아닌지에 대한 여러 가지 이유들이 떠돌고 있다. 플래시가 느리고, CPU를 잡아먹으며, 배터리를 소모시키고, 너무 자주 충돌하며, 맥오에스텐에 최적화되어 있지 않는 등의 이유가 있다. 물론 이 이유들은 타당하다. 그러나 당장 이 모든 문제를 오늘 해결한다손치더라도, 아이폰에 관련되는 한, 어도비와 애플 간에는 거대한 문제점이 놓여 있다. UI를 누가 통제하는가?

Adobe's conundrum

데스크톱 OS 고유의 UI 컨트롤을 피하고, 어도비 독자 크로스-플랫폼 UI 패러다임을 심어 놓는다. 그리고 멀티플랫폼에서 일관성 있게 런타임 엔진을 돌린다. 이것이 어도비의 데스크톱 인터페이스 전략이다.

그러나 어도비 입장에서는 불행히도, 애플은 현재 아이폰이라는 멀티터치 플랫폼을 최초로 대중화시켜 나아가고 있는 중이다. 그리고 아이폰은 이미 노트북 시장에 근접할 정도로 자라났다. 분명 애플은 (2005년, 애플은 FingerWorks와 그 특허권을 매입했었다) 멀티터치라는 제스쳐 패러다임을 더 넓게 확장시키고 싶을 것이다. 다른 기기도 포함해서 말이다.

아이폰이 나올 때, 아이폰을 다른 휴대기기와 분명 차별화시켜준 것은 아이폰이 가진 멀티터치 UI의 일관성이었다. 데스크톱의 WIMP(window, icon, menu, pointer)에서 직접 조작의 패러다임으로 크게 비약한 인터페이스라는 의미다. 컴퓨터와 소비자가전 업계에서 보아온 바와 같다.

즉시 다른 모든 휴대폰 업체들이 차세대 "아이폰 대항마"를 들고 나섰고, 실제로 출하한 회사도 있었다. 예상할 수 있는 일이다. 그러나 결과가 보여준다. 애플이 지닌 여러 가지 특허를 침해하거나, 아예 새로운 혁신을 만들지 않는 이상, 아이폰 UI의 유동성을 베끼기는 어렵다는 사실이 드러났다. 가령 대항마 기업들은 이정도밖에 안된다. 이 사례는 노키아 S60 휴대폰을 아이폰으로 "탈바꿈"시켜주는 플래시 라이트의 사례이다.

"두 번째" 페이지(영상 참조)를 가 보면, 터치 패러다임과 못난 WIMP 인터페이스의 합체를 볼 수 있다. 이 정도가지고 "아이폰 대항마"를 자칭하는 휴대폰이 절대 다수이다. 아예 멀티터치를 우회하려 하는 기업들도 있다. 가령 삼성은 제스쳐 기반의 UI를 특허화시켜 놓았다. 삼성 특허의 경우, 네비게이션과 상호반응을 위해, 휴대폰의 카메라가 손가락/손의 제스쳐를 추적하는 방식의 제스쳐 UI인데, 별로 실용성은 없어 보인다.

Apple: Not on my device!

애플은 아이폰을 선보이면서, 느리지만 확실하게 세 번째 규모이지만 메이저급 OS 플랫폼을 구축하고 있다. 적은 규모의 기기들이지만 멀티터치와 UI 미학을 덧붙인 플랫폼이 애플 플랫폼이다. 애플은 워낙에 UI와 사용감에 집착하는 회사다. 심지어 아이폰 2.0이 나올 때까지도 기본적인 베끼기/붙이기 기능을 소개하지도 않았을 정도다. 여기에 대해서는 적절한 UI 패턴을 못찾았기 때문이라는 루머가 있다.

스마트폰 시장은 차세대UI 패러다임의 확립을 두고, 경쟁이 매우 치열한 시장이다. 즉, 어도비는 물론 어느 회사에게도 애플은 크로스-플랫폼이나 공통 UI 기반에 애플 브랜드를 희석시키려하지 않을 것이다. 멀티터치에 대해 애플 고유의 방식을 밀고 나갈 것이라는 의미다. 그렇다면 어도비는 무엇을 선택할 수 있을까?

Adobe's iPhone choices

아이폰에 플래시를 집어 넣으려면 다음과 같은 방안을 생각해 볼 수 있다.

애플의 아이폰 UI 컨트롤과 인터랙션 패턴을 통째로 라이센스 받아서, 플래시와 플렉스, 에어 개발 패키지에 컴퍼넌트로 집어 넣는다. Halo의 현재 기본 셋과 매우 유사한 접근이다. 그러나 애플이 그런 라이센스 약정을 체결할 것 같지는 않다.
아이폰 UI를 그대로 베끼고, 애플 IP 법무팀의 위협을 무시해버린다. (한 때 UI 침해를 했다면서 매크로미디어를 고소한 회사가 어도비였다. 아이러니컬한 방안이다.)
아이폰 호환 플래시 컴퍼넌트 제작을 써드파티에 맡겨버린다. 법적인 문제도 그들이 해결하도록 놓아둔다.
하나는 아이폰 UI 패러다임을 따르고, 다른 하나는 다른 기기용으로 나누는 방안이 있다. 이렇게 할 경우 플래시 라이트로 만든 중요한 애플리케이션이 아이폰이나 다른 기기에서 깨질 수 있다(최소한, 깨져서 보일 수 있다). 드래깅이나 더블클릭과 같은 가장 간단한 플래시 UI 패턴조차도 멀티터치 플랫폼은 완전히 다른 개념이기 때문에 아이폰에서 제대로 작동하지 않을 것이다.
OS 네이티브 컨트롤을 무시하고 고유의 UI 패러다임을 쓰던 플래시의 오랜 "3자-플랫폼 전략"을 포기한다. 따라서 플래시 디자이너와 개발자들이 이제 OS에 특화된 문제를 해결해야 하는 상황이 된다. 이 경우 아이폰 멀티터치용으로 디자인한 UI가 아이폰보다 못한 기기에서는 부드럽게 돌아가지 못하게 될 것이다.
아이폰과 다른 플랫폼용으로 별도 버전을 만들도록(디자인하도록) 독려한다. 하지만 이렇게 해서야 멀티-플랫폼 앱을 지향하는 플래시의 목표가 사라지게 된다.
멀티터치 제스쳐 특허를 침해하지 않는 제스쳐 라이브러리를 플래시용으로 개발한다. 아이폰의 애플과 경쟁을 벌일 수도 있겠고, 아이폰을 무시하여 반-아이폰 멀티터치 플랫폼을 새로이 만들 수도 있겠다. (이를 위해서 구글에 접촉하여 안드로이드용 기술을 들여올 수도 있을 것이다.)

이론상 생각해본 이러한 방안은 물론 실용적이지 않다. 애플이 통제하는 "앱스토어"를 통과하지 않고서야, 아이폰에 합법적으로 써드파티 앱을 설치할 수 없기 때문이다.

Apple's Flash choices

다른 플랫폼과 너무나 차별화된 애플의 멀티터치, 그리고 직접-조작 방식의 아이폰 UI는 어도비 전략을 분명히 뒤흔들었다. 플랫폼과 기기들 간에 네이티브가 아니면서 일관성 있는 UI를 담보하자는 것이 어도비의 전략이었다. 최근 애플은 칩디자인 기업인 PA Semi를 인수하였다. 무슨 의미일까? 차후 나올 아이폰 플랫폼을 차별화시키겠다는 의미다. 애플 스스로 디자인한 SOC(system-on-chips)을 만들어서, 아예 써드파티나 클론 업체의 길을 막아버리겠다는 의도이기도 하다. 애플만이 부착 가능한 하드웨어 컴퍼넌트를 통해 아이폰 UI의 여러가지 기능이 개선될 것임은, 상상하기 그리 어렵지 않다. 따라서 어도비나 다른 업체들이 애플과 싸우기는 점점 더 어려워질 것이다.

그렇다면 아이폰용 플래시는 도대체 어떻게 될까? 아이폰이 플래시 없이 성공할 수 있을까? 애플의 숙제가 바로 여기에 있다.

전문가들은 아이폰에 "플래시"가 없기 때문에 일어날 수 있는 문제로, 보통 플래시 비디오 스트리밍을 예로 든다. 그러나 애플 입장에서 볼 때 유튜브는 해결하기 오히려 쉬운 문제다. 구글과의 약정에 따라 제일 거대한 플래시 비디오 업체인 유튜브가 비디오를 널리 퍼진 업계-표준, H.264 코덱으로 바꿔가고 있기 때문이다. 이 코덱은 퀵타임 영상으로도 볼 수 있다. 어도비 또한 플래시 플레이어 9에서 주요 비디오 코덱으로서 H.264를 채택하기도 하였다.

플래시가 없다는 의미는 브라우저 안에서 돌아가는 RIA(Rich Internet Applications) 런타임, .swf가 없다는 의미다. 데스크톱 상의 AIR가 없다는 의미이기도 하다. 이전에 논의했듯, 어도비 플래시나 마이크로소프트의 실버라이트, 썬의 자바FX와는 달리 애플은 멀티미디어/RIA 런타임을 갖고있지 않다. 이 세 회사가 모두 자신들의 런타임을 아이폰에서 돌리고 싶어함을 공개적으로 드러냈지만, 애플은 지금까지 전혀 그들에게 관심을 보이지 않고 있다. 전문가들의 압박은 거대하다. 그러나 스티브 잡스가 직접 나서서, 아이폰용 플래시는 "너무나 느려서 유용하지 않다"면서, 플래시 라이트는 "웹에서 사용할 정도도 못된다"며 일침을 해 놓았다.

애플의 "RIA 런타임"은 사실상 WebKit이다. 앞으로 나올 MobileMe 앱은 웹브라우저 안에서 Ajax-기반의 UI를 보일 텐데, 이 형태의 UI는 데스크톱용 프로그램이나 플래시를 통한 RIA만큼 효과적일 수 있다. 달리 말해서, 애플의 메시지는 이러하다. "아이폰용 앱을 네이티브로 만들고 싶으면 Cocoa Touch를 선택하시라. 크로스-플랫폼(사파리 모바일도 포함한다)을 노리고 있다면 Ajax를 선택하라." 복잡한 메시지가 아니다.

지난 해 한 애플 개발자 문서를 보면 플래시에 대해 다음과 같이 나와 있다. (아이폰용 웹 애플리케이션과 컨텐트 최적화라는 제목이다.) 플래시는 "지원하지 않는 기술" 섹션에 딱 하나의 아이템으로 올라와 있다.

"아이폰용 컨텐트로서 플래시와 자바는 비파게 될 것이다. 아이폰용 최신 플래시를 다운로드하도록 하지도 말아야 한다. 플래시나 다운로드 모두 아이폰용 사파리에서 지원하지 않기 때문이다."

어도비는 분명 아이폰용 플래시 런타임을 엔지니어링하여 애플을 설득시키려 노력할 것이다. 플래시가 꼭 필요하다면서 말이다.

The new UI wars: Why there’s no Flash on iPhone 2.0

trexx · 2010-02-22, 05:45 PM

매번 좋은 글 감사합니다. 플래시 지원에 대한 정보를 얻고 싶었는데 가려운 곳을 긁어 주셨습니다.

ssen · 2010-02-22, 06:43 PM

플래시 개발을 하고 있고, 동시에 디자인도 하고 있습니다.
사실 플래시에 대한 관점은 장님 코끼리 다리 만지기와 같아서 양쪽 모두 맞는 말이기에 논쟁이 쉽사리 꺼지지 않는 경향이 있습니다.

하지만, 몇가지 오류들을 정확히 되짚어보자면...

플래시가 웹 리소스를 과하게 잡아먹는다는 이야기는 사실 옳지는 않습니다. 리소스를 많이 잡아먹는 작업에 플래시가 어울려서 사용되는 것뿐이지, 플래시가 없어진다고해서 그 컨텐츠들이 사라지는 것은 아니니깐요... 쉽게 이야기해서 HTML5 를 많이 이야기하지만, 플래시가 없어지면 광고가 canvas 와 video 태그로 전환될 것이 분명하고, 그 때, 과연 플래시보다 빠를까? 과부하가 없을까? 라는 것에는 동의가 안되는 것이죠...

의외의 이야기일지도 모르겠지만 플래시는 굉장히 빠릅니다. 최신이 아닌 모든 브라우저에서 플래시가 현재 하고 있는 컨텐츠의 역할을 맡길때 어떤 사단이 일어나는지는 웹개발을 한다면 누구나 알고 있는 이야기라고 봅니다. 다른 기술들은 안되기 때문에 안하는거지... 그 기술이 착해서이거나 그 기술을 사용하는 개발자들이 착해서 안하는건 아니라는 거죠.

부하가 생기는 컨텐츠에 적합한 것이 플래시이고, 또, 디자이너와 개발자의 상호작용이 필수적인 작업에 있어서 플래시가 빠른 작업속도를 보장해주기 때문에 사용되어지는 것이죠. 같은 개발 목표를 HTML, javascript 를 사용해서 만들때와 플래시로 만들때는 성능의 튜닝과 불가능한 작업 리소스에 대한 포기 등을 고려했을때 플래시가 월등한 입장이기도 합니다... (적어도 3d 를 VGA 의 도움없이 비트맵 픽셀 작업만을 통해 에뮬레이션 할 정도의 성능이 있다는 것은 모두가 알아야 하는 문제이죠.)

그리고, 마우스오버의 경우 역시 호버링을 통한 뎁스의 제거를 위해서 자바스크립트가 사용된 UI 들에도 동일하게 적용되는 문제입니다. 비단 플래시에만 적용되는 것이 아니라 설계에 대한 문제이죠. 다만, 플래시에 이 문제가 빈번한 것은 "플래시까지 써서 만드는 것인데 HTML 의 버튼과 별반 차이 없으면 안된다는" 투자 대비 가치에 대한 문제였죠.

이 문제는 말 그대로 노가다 말고는 대안이 없죠. 하지만, 해결될 수 없는 문제는 아닙니다. 기술의 문제가 아니라 설계의 문제니깐요.

잡스가 이야기하는 "어도비가 게으르다." 라는 것에도 동의할 수는 없습니다. 이 문제를 이야기하자면 플래시가 웹에서 포지션된 상황 자체를 먼저 이야기해야 하는데...

플래시가 단순한 애니메이션, 인터렉티브의 구현체에서 지금처럼 거대 어플리케이션 개발도구로 까지 발전하게 된 것은 PC OS 의 어플리케이션 배포체계 문제가 있었습니다. 서비스 제공자 입장에서는 웹페이지처럼 지루한 도구 대신에 자사의 서비스를 보다 제대로 활용할 수 있는 도구를 배포해야 하는데, 이걸 어플리케이션으로 만들었을 때는 제작의 어려움이나 멋드러진 디자인 따위는 제쳐두고라도 배포체계 자체가 문제가 되었죠. 아이폰이 현재 플래시를 거절 할 수 있는 이유는 앱스토어라는 일관되고 단순화된 어플리케이션 배포 마켓이 있기 때문이지, 그렇지 않았다면 PC OS 들과 마찬가지로 웹브라우저를 실행시키기 위한 중간 파이프라인으로 전락할 가능성이 높았을겁니다.

플래시가 발전할 수 있었던 이유가 PC 의 어플리케이션 배포의 문제였기 때문에 플래시에 요구되는 것 역시도 상당한 과부하를 일으키면서 진행이 되었습니다. 업계의 주요화두가 1~2년 만에 완전히 뒤집어 엎어질 정도로 빠르게 (혹은 사람이 진이 빠질정도로) 발전하는 개발영역은 지난 10년간 흔치 않았죠. 그만큼 플래시에 대한 발전상황은 "최적화" 보다는 "기능 확장" 에 맞춰져 있었습니다. 결코, 잡스가 "게으르다" 따위의 이야기할 수 없을 정도로 플래시의 발전 상황과 그 발전을 뒷받침 하기 위해 진행된 수많은 백그라운드 작업들이 적지 않았죠. 보통 2~3년 주기를 가지던 어도비 제품군의 업데이트가 최근 1~2년 으로 줄어든 것 역시 플래시에 대한 기능 확장과 맞물려 있는 영역이 많습니다. 직접적이지는 않아도 각 제품군들이 인터렉티브 미디어 제작에 대한 워크플로우를 개선하기 위해 변경되고 재조립 되는 과정의 변화가 상당히 주요했죠.

제대로 만들었을때 플래시가 보여주는 퍼포먼스는 상당히 뛰어납니다. 하지만, 이런 발전의 역사를 봤을때 개발자들이 컨텐츠를 제대로 만들기 보다는 새로운 가능성에 목을 매어서 컨텐츠의 퍼포먼스가 저질화 되고, 그 저질화를 뒷받침 해줄 정도로 플래시의 퍼포먼스가 뛰어나다는 것 역시 현재의 상황을 만드는데 주요한 역할을 했죠. 정확히 이야기해서 플래시의 문제라기 보다는 플래시를 둘러싼 개발자나 디자이너, 시장상황등이 문제라고 보는 편이 옳습니다. 그리고, 플래시에 요구하는 클라이언트들의 요구사항 자체도 과부하를 만들어낼 수 밖에 없을 정도로 컸구요. (실제 일을 하다보면 알 수 있는건데, 거의 대부분이 웹페이지에서는 안되는 마법같은 일들이 플래시에서는 다 된다고 생각하거든요... 언젠가 한번은 PS3 에 돌아가는 소프트처럼 만들어달라는 이야기도 들었었죠...)

canvas 를 통해 Flash 를 대체하겠다는 이야기 역시 맞지는 않습니다. 저도 canvas 와 javascript 를 통해서 개발을 하고는 있지만... ㅡ ㄴ ㅡ;;; Flash 를 대체할만큼 기능이나 성능이 뛰어나지는 않습니다. PC OS 에서 돌아가는 어플리케이션의 대체와 인터렉티브 미디어 라는 거대한 요구를 비롯해서 자잘한 요구들까지 플래시에 주어지던 목표치를 해결하기 위해 발전해온 10년의 세월을 따라잡기에는 확실한 무리가 있죠... 더군다나 HTML5 가 각 업체들의 이해관계에 따라 표류하고 있는 상황에서는 더더욱이 어려운 문제입니다.

canvas 라는 것을 Flash 에 대응해서 이야기하지만 canvas 와 Flash 는 상호간에 목표로 하는 것 자체가 틀리다고 할 정도로 그 역할이 상당히 틀립니다. 그리고, canvas 가 Flash 처럼 되는게 웹의 전반적인 성능개선에 도움이 되지도 않구요. (플래시가 놀고 먹어서 성능이 나쁘게 나왔을리가 없잖아요... canvas 가 Flash 를 대체하면 오히려 더 끔찍한 상황이 될겁니다.)

둘 다 하는 입장에서 이야기하자면 HTML5 가 좋은 명문대 나와서 잘난척 하는 애송이 같은 느낌이라면, 플래시는 좀 능글능글 불법도 잘 저지르는 베테랑 같은 느낌입니다. 이상적으로야 HTML5 가 멋져 보이지만, 현실적으로 사용될 수 있는 문제에 있어서는 플래시가 압도적이고, 결코 쉽사리 따라오기 힘든 포스를 지니고 있다고 봐야겠죠...

그렇다고 플래시를 옹호할 수만은 없는 상황이기도 하죠. 플래시 라는 것 자체가 PC OS 의 "오류" 를 바탕으로 자라난 이독제독의 케이스라는 것을 생각하면, 새 부대를 필요로 하는 술인 모바일에는 어울리지 않는 면이 많으니깐요.

정확히 이야기해서 플래시가 없어져야 한다기 보다는 "웹페이지가 어플리케이션처럼 활약해야 하는" 시장의 문제점을 없애기 위해, "어플리케이션 배포의 문제를 해결해서 웹페이지 url 을 통해 웹 어플리케이션을 활용하게 되는 속도와 어플리케이션을 다운받고 설치해서 활용하게 되는 속도" 의 갭을 없앨 수 있어야 플래시에 주어진 "역할" 자체가 소멸될 수 있을겁니다. 그리고, 플래시가 주요하게 악평을 받는 광고 역시도 웹이 가진 비지니스 모델의 부재가 해결되지 않는 이상 아무리 기술이 바뀌어도 짜증은 여전할 거구요. 전 왜 애플이 앱스토어 같은 공용화된 어플리케이션 배포 체계를 Mac OS 에 넣지 않는지가 이해가 안되더군요... PC OS 에서 돌아가는 어플리케이션들이 컴퓨터에 익숙하지 않는 비전문 계층에게 적극적으로 활용되지 않는 이유에 대해서 충분히 인지하고 있다고 보는데 말이죠...

사실 애플이 이야기하는 HTML5 는 현재 표류중이라고 하는게 옳을 정도로 개판인 상황입니다. 결코 내일 당장 쓸 수 있는 녀석이 되지는 않죠. 그 반면에 PC OS 의 오류를 바탕으로 자라난 플래시가 성격 개선을 하는데도 충분한 시간이 필요하죠. 어짜피 둘 다 시간이 필요한 상황이고... 장점과 단점이 상호 보완되어야 하는 입장이라고 볼 수 있을 것 같습니다.

개인적으로는 웹용 플래시 보다는 AIR 가 모바일 시장에서 가지는 가치에 대해서 관심이 많습니다. 웹페이지는 그냥 "웹문서" 이면 될 뿐이지 어플리케이션일 필요는 없으므로 Flash 고 AJAX 고 나발이고 다 때려치는게 좋고, 어플리케이션 배포 체계가 좀 더 정상적이 되면 된다는 입장이거든요. 현재는 아이폰이 "완전한 시장장악" 이라고 볼 수 있을 정도니깐 그렇지, 안드로이드와 윈도우모바일7이 활성화 된다면 "개발하기 아주 쉽고, 모든 플랫폼에서 정상적으로 작동하고, 자바보다 스타일리쉬하기에 감성적으로 접근할 수 있는" AIR 와 같은 녀석이 필요해질 거라고 봅니다. 현재 앱스토어에서도 분명 "이따위걸 구지 빡세게 Objective-C" 까지 써가면서 만들어야 하나... 싶은게 많죠. 네이티브 어플리케이션에 필요없는 라이트한 어플리케이션에 대한 필요성에 AIR 가 상당히 필요하다고 봅니다.

물론... 매년 개발자들에게 10만원씩 거둬들이는 조공이 없어지기에 애플에게 곤란한 일이 되겠지만요... 이건 뭐 돈을 안내면 테스트도 할 수가 없으니...

그냥 이런저런 이야기를 했지만... 요새 "제가 좀 힘들어요. 애플, 어도비 이새키들아 좀 제대로 해..." 라는 이야기가 나올 뿐이죠. 그냥 아주 죽겠습니다. 뭐 플랫폼이 탄탄해야 개발을 할텐데, 요새 모바일이 등장하면서 개발 플랫폼이 아주 전국시대가 되어버린 상황이라...

skonmeme · 2010-02-22, 11:36 PM

1.
아도비와 플래시를 옹호하시는 많은 분들이 아무리 주장한 들 맥과 리눅스에서 플래시가 엉터리 퍼포먼스를 보인다는 것은 누구나 동의하고 있는 바입니다. 그걸 빠르다고 주장해보셔야 아무런 의미가 없다는 뜻입니다. 이건 스마트폰의 경우에도 마찬가지라고 봐야할 것입니다.

또한 이런 주장이 사실이라고 해도 의도가 뻔한만큼 아이폰과 아이패드에는 플래시가 안들어갑니다. 아무리 아도비가 사정한다해도 소용없는 일이죠.. 유일한 방법은 MS를 잘 구술려서 Window Phone 7이나 그 후속버전이라도 플래시가 들어가도록 협상하는 것이고, 안드로이드 폰에서 상당한 수준의 퍼포먼스를 직접 증명하는 수밖에 없습니다. 그래고 더욱 중요한 것은 지금 스마트폰 시장을 선도하는 아이폰의 위세를 꺾고 WP7이나 안드로이드가 압도적으로 치고 나가야하는만 합니다. 이것이 충족된다면 애플은 은근슬적 아이폰과 아이패드가 지원하도록 할지도 모릅니다.

2.
2~3년전만 하더라도 자바스크립트의 성능은 처참했습니다. 그중에서도 IE의 자바스크립트는 그냥 끼워팔기 수준이었습니다. Acid3 테스트가 일반화되고 브라우저 전쟁이 일어나면서 급격히 성능이 향상되기 시작했습니다. 곧 플래시가 보여주던 성능을 순식간에 압도했습니다. 플래시를 대체하자는 얘기는 이때와서야 나오기 시작한 것입니다. 이미 상당부분에서 플래시로 구현되던 부분이 자바스크립트로 대체되었습니다. (당연한 얘기이지만 전부는 아닙니다.)

아직 SVG나 canvas가 성능이 부족하고 플래시가 가진 기능을 제대로 구현하기 힘들다고 해서 미래에도 그렇다고 (10년후?) 얘기할 수는 없습니다. 오픈된 환경에서의 경쟁은 아도비가 혼자 관리하는 기술정도는 쉽게 뛰어넘습니다. 이미 오페라, 사파리, 파이어폭스 등이 실증했습니다. Acid3를 통과시킨 웹엔진 개발팀들은 지금 뭘하고 있다고 생각하시나요.. 슬슬 도래할 Acid4에 대비해 SVG와 canvas의 구현과 성능 개선에 들어가고 있다고 봐야하지 않을까요? 몇년 걸리지 않아서 플래시가 가지는 기능과 함께 성능도 따라 잡힐거라고 봅니다.

3.
물론 앞으로도 광고등으로 인해 사이트가 무겁다는 점은 쉽게 해결이 되지 않을 것입니다. 하지만, 이런 무거움은 플래시로 가중되고 있다는 점을 생각해야 합니다. 그 가중됨을 온전히 웹엔진에서 처리하게 된다면 그 효율이 더 나아지면 나아졌지, 현재와 같은 수준은 아닐 거라고 생각됩니다.

4.
현실적으로 HTML5의 길을 보여준 것은 W3C의 표준화 모임이 아니라, Acid3 테스트와 자바스크립트 속도 경쟁이였다고 생각합니다. 어느 정도 동의된 기능에 대해 (말 그대로 산업표준) 테스트툴을 만든 이후로 개발자들은 Acid3 테스트를 통과하기 위해 주구장창 뛰었다고 볼 수 있습니다. 지지부진했던 자바스크립트 속도도 급격히 개선되었구요.. 특히 점수로 표현되는 Acid3 테스트는 개발자들에게 불을 질렀습니다.
HTML5은 당분간 표류할 것은 분명하지만, Acid4가 만들어지는 순간 웹엔진 개발자들은 다시 뛸 거라고 봅니다.

trexx · 2010-02-23, 02:07 AM

요즘 맥 환경에서는 click to flash를 사용합니다.
웬만한 사이트에서 플래시를 안보이게 하니 화면이 정갈해 보이기까지합니다.

홈페이지 메뉴를 플래시로 만들어진 경우 클릭하는 것이 유일합니다.

이건 사실 에러에 가깝지요...웹접근성이 전혀 고려없으니까요.

연구원 홈페이지 제작 기획을 했지만 홈페이지 효용성에 대해서는 글세요!?

온라인 상의 정보 수집의 패러다임이 바뀌었다는 것이 제 생각입니다.

각각의 회사 정보를 얻으려고 각각의 홈페이지를 접근하는 것 보다 검색엔진을 통해서 (외국의 경우) SNS 검색해서 즉각적이 정보 수집이 더 합리적입니다.

아이폰 국내 발표한다 안한다 했을때 KT에서 트위터를 통해 즉각적으로 반응하는 것을 예를 들 수 있겠지요...

검색엔진, 포털사이트, 블로그, 트위터... 사실 웹페이지의 효용성이 처음 웹이 나올때보다 줄어들지 않았나 싶습니다.

특히 중소기업의 경우 개별 홈페이지의 운영은 더욱 그렇지요.

첫째, 유지보수의 어려움(최신 정보 업데이트의 어려움)
둘째, 사용자 접근의 어려움 (홈페이지 홍보의 어려움)
마지막으로 홈페이지 효용가치의 변화(SNS 대체로 해결 가능)

사실 플래시가 필요없는 이유 중 하나는 바로 홈페이지 패러다임의 변화도 한몫하지 않을까 싶습니다.

그래서 디자인의 요소의 변화또한 무시할 수 없고요.. 화려한 볼거리의 필요성이 계속 사라지고 있지요..

소셜네트워크의 지각변동 또한 플래시 무용론에 힘을 주지 않을까 싶네요.

모바일 환경의 변화에 일등공신이 소셜 네트워크니까요.

(주제에는 어긋나지만 서울버스 등에서 화자되었던 공용 정보 DB 공개의 바람이 데스크탑에 한정된 인터넷을 거리로 나오게 했다고 생각합니다. 플래시요? 글세요. 필요할까요?)

인용:

ssen 님이 쓰신 글

플래시 개발을 하고 있고, 동시에 디자인도 하고 있습니다.
사실 플래시에 대한 관점은 장님 코끼리 다리 만지기와 같아서 양쪽 모두 맞는 말이기에 논쟁이 쉽사리 꺼지지 않는 경향이 있습니다.

하지만, 몇가지 오류들을 정확히 되짚어보자면...
-- 중략 --
그냥 이런저런 이야기를 했지만... 요새 "제가 좀 힘들어요. 애플, 어도비 이새키들아 좀 제대로 해..." 라는 이야기가 나올 뿐이죠. 그냥 아주 죽겠습니다. 뭐 플랫폼이 탄탄해야 개발을 할텐데, 요새 모바일이 등장하면서 개발 플랫폼이 아주 전국시대가 되어버린 상황이라...

ssen · 2010-02-23, 08:02 PM

@trexx
일단 저 역시 HTML 컨텐츠 내부의 메뉴바 등이 단순히 아름다움만을 위해서 플래시로 사용되는 것에는 반대하는 입장입니다.
플래시에 관련된 API 들이 존재하긴 하지만, 장애인 등을 고려하고, 포괄적인 웹접근성을 필요로 하는 상황에서는 옳지 못하죠.
그런 문제들을 인식하고 저 역시 사안에 따라 플래시 사용을 자제할 것을 권고하는 편입니다. (b, u 와 같은 스타일태그 보다는 strong, dfn 과 같은 시각장애인이 접근할 경우 유용한 태그를 권고 하기도 하죠.)

하지만, 플래시가 오남용 되는 사안들을 두고 "필요없다" 라고 단정짓기 보다는 관련된 기술이 가지는 본질적인 의미에 대해서 생각하는 것이 좀 더 옳은 방법이지 않을까 싶습니다. 그리고, 기술이 바른 자리를 차지하도록 이끄는 것이 좀 더 좋겠지요.

플래시의 경우 현재 오남용 되고 있는 메뉴바나 배너 같은 것 보다는 "interactive media" 에 긍정적인 영향을 미친다고 볼 수 있습니다. 원래 시작 자체가 이 interactive media 를 목표로 설계되었는데, 어느 순간 웹어플리케이션의 필요성 증대나 html 이 가지는 아름다움의 부재, 크로스 브라우징이 불가능하다는 문제등 때문에 오남용 되기 시작된 경향이 높죠.

말씀하시는 것처럼 "단순하고 내가 원하는 정보만을 보길 원하는" 사람들만이 웹을 사용하는 것은 아닙니다. 사용자들의 대부분이 홈페이지에 빼곡하게 들어찬 텍스트를 보는 순간 뒤로가기를 눌러버리는 경향을 보이는 것 역시 사실이구요. 사용자들에게 컨텐츠를 흡수시키기 위해서 노력하는 이들에게 interactive media 기술은 필수적이죠. 이미 관련 업계 (기존 방송 미디어 등을 제작하던 업계) 의 경우 이 interactive media 등을 주요한 화두로 설정하고 있습니다.

그런 "기존 미디어가 가지는 표현의 흡수력을 보장하면서, 동시에 대화형 타임라인을 가짐으로서 사용자에게 내용을 보다 정화히 전달하길 원하는" 업계와 그 수요자들이 원하는 것을 보장해주는 기술은 현재 플래시 말고는 존재하지 않는다고 하는 편이 옳습니다. 대안체로서 canvas 를 이야기하지만, canvas 의 내부 api 가 보장하는 기술은 이에 크게 미치지 못하고 (그래서 차트와 같은 data visualization 에 특화되었지, flash 와 같이 interactive media 에 특화된 것은 아니라고 글에서 설명했던 것입니다.) 가장 큰 중요성으로 canvas 에 접근할 수 있는 작업 도구 자체가 존재하지 않습니다.

쉽게 설명해서 해당하는 컨텐츠를 제작하는데 대안인 canvas 를 사용하라는 것은, 웹개발자들에게 "왜? html 이 필요한데, 그냥 c 로 프리젠테이션 단까지 개발하면 안돼?" 라고 이야기 하는 것과 비슷한 이야기가 됩니다.

그리고, 말씀하신 인터넷의 데이터 수집이 SNS 등으로 옮겨가고 있다는 이야기는 플래시와 같은 컨텐츠, 즉 내용의 도착점에는 어울리지 않는 이야기 입니다. 트위터를 통한 정보의 유통을 보아도 대부분이 "알림" 이라는 경로의 역할을 하지, 그 자체가 도착점인 "내용" 이 되지는 않습니다. SNS 를 통한 정보 유통은 기존 검색과 같이 "내가 도착점에 대해 인지를 해야 컨텐츠를 얻을 수 있는" 난제를 해결하는 "내가 (팔로잉을 통해) 관심있게 경청하는 이에게서 발생하는 정보의 알림" 이라는 경향이 높습니다. 어떻게 보면 RSS 와 같은 경향이 높다고 볼 수 있죠.

기존 컨텐츠 접근에 대해 보완체적인 역할을 하는것이지 "대체재" 로서 작용하지는 않습니다. 그렇기에 trexx 님이 말씀하시는 웹페이지, 웹사이트의 효용성에 대한 의문은 저는 다르게 생각합니다. SNS 의 "알림, 대화" 와 같이 정보 접근 방식의 다양화로 기존에 웹사이트가 가지던 기능들이 다른 유통체계로 일부 전환되긴 해도, 이것은 "역할의 재분배, 역할의 효율화, 역할의 보완" 에 가깝지, 웹페이지 컨텐츠 자체의 의미 상실을 이야기 하지는 않을 것입니다.

제 생각과 trexx 님이 생각하는 것 중에서 동일한 부분은 플래시가 메뉴바 등으로 오남용 되는 것에 반대한다는 것이고, 플래시가 필요하냐? 라는 의문에 대해서 반대하는 입장은 컨텐츠라는 것이 꼭 text, image, video 만을 통해 전달되는 시기가 이미 지나갔다는 것입니다. 많은 컨텐츠들이 목표로 하는것이 일방적인 주입형에서 이미 대화형인 interactive media 를 목표로 하는 상황에서 플래시와 같이 그런 컨텐츠형을 대표하는 기술 자체가 사라져야 옳다고 이야기 하는 것은 "수요" 에 대한 대체를 찾지 못한 상태에서 수요 자체를 없애는 것이 옳다고 이야기 하는 것과 마찬가지가 됩니다.

입장을 달리해서 trexx 님이 "고가의 자동차를 보다 품위있게 보여주면서, 동시에 text 나 image, video 의 나열과 같은 사용자가 쉽사리 포기해버릴 수 있는 정보 제공 방식이 아닌 게임과 같은 형식으로 사용자에게 이 제품의 중요성을 알리고자 한다면" trexx 님은 어떤 기술을 선택하시겠습니까?

플래시가 집중적인 화두가 되는 이유는 꼭 애플과 어도비의 정치적 싸움이나 단순한 기술적 오남용의 해소를 위해서만은 아닙니다. IT 적인 시선을 벗어나면 플래시라는 현재로서 대체 불가능한 기술이 "소멸" 되는 것에 대해 불편함을 느끼는 비 IT 업계의 이해관계가 오히려 더 크다고 볼 수 있죠. (위에서도 이야기했지만 관련한 컨텐츠를 만드는데 flash 를 사용하지 말라는 것은 html 없이 c 로 웹페이지 프리젠테이션을 렌더링 하라는 말과도 비슷할 정도로 일방적인 폭력성을 가지고 있습니다.)

모든 것이 웹표준이 제공하는 기술만으로 해결될 수 있다면 플러그인 기술 자체가 재평가 받아야 하겠죠. 하지만, 플러그인 기술이 필요한 이유는 웹표준이라는 가장 기본적이고 스탠다드한 기술이 제공할 수 없는, 그리고, 그렇게까지 표준이 방대해지고 난잡해져서는 안된다는 문제를 해결하기 위해서라고 봅니다.

기술에 대한 평가를 하는데 주관적이고 개인적인 입장만을 이유로 들면 안된다고 봅니다. interactive media 적 기술을 필요로 하는 업계는 어린아이들과 같이 text, image 정보를 흡수하기 어려운 대상을 상대로 하기에 게임의 형식을 만들기 원하는 업계도 있고, 공들인 제품에 대한 정보를 사용자가 그냥 대충 훌터보기를 원하지 않기에 보다 흡수력이 강한 컨텐츠 형식을 원하는 업계도 있습니다. 그리고, 그런 업계의 컨텐츠들 중에서는 "앱" 을 설치하는 것이 아닌 일회성 정보로서 작동해야 하기에 웹 자체의 표현능력이 강해야만 하는 업계도 많습니다. 일방적인 평가를 내릴수만은 없는 이야기이죠.

플래시에 대한 의미가 다시 재평가 되는것은 제 입장에서는 즐거운 이야기이기도 합니다. 플래시와 같은 컨텐츠를 제작하는 입장에서 "남용" 에 가깝게 사용되는 것은 분명 즐겁지 않은 일이니깐요. 하지만, "남용, 오용" 을 없애는 것에 대해 긍정적인 입장을 가지는 것과 반대로, 현재처럼 "긍정성" 마저 소멸시키려고 하는 것은 옳지 못한 이야기이기도 합니다. 그런것은 "삐뚫어질 수 있기에 자유를 제한하는 것이 옳다." 라는 폭력적 사고와 비슷하죠.

제 생각은 기술이 남용되는 부분을 제거해나가는 것이 옳지, 아예 그 기술의 수요와 공급 자체를 소멸시키려는 생각은 옳지 못하다는 것입니다. 도구라는 것은 사용자의 문제이지, 도구 자체가 없어질 문제는 아니지 않을까요?

많은 부분 웹표준을 중점으로 해서 발전해야 하는 부분들은 웹표준화 되고, interactive media 와 같이 현재로서는 대안을 찾기 어려운 부분에 대해서는 기술이 "긍정적" 으로 활용되어 갔으면 하는 바램이 있습니다. 그것이 보다 올바른 판단이지 않을까 싶구요.

그래서, 사용자들이 "플래시 광고 짜증나! 플래시 없어졌으면 좋겠어!" 라는 것은 그렇다치지만, 보다 원론적으로 생각해야 하는 기술자들의 경우에는 "기술의 올바른 활용과 그 대체" 에 대해서도 고민을 하면서 이야기를 나눴으면 하는 바램이 있습니다. interactive media 업계에도 몸을 담고 있는 저로서는 기술자들 마저 일방적인 시각만을 가지고 단순한 증오의 토론을 하는 것은 좀 거시기 하다는 느낌이 듭니다.

분명 다른 업계, 수요자들을 포용하는 시각을 가지면 플래시의 필요성에 대해서 단순하게만은 평가를 내리시기 어렵다고 봅니다. trexx 님도 제가 이야기한 업계와 수요자에 대해 한 번 생각하시면 좀 더 긍정적으로 검토해야 옳은게 아닌가 하는 생각을 하시게 될겁니다.

그리고, 추가적으로 이야기하고 싶은 것은...

말씀하신 플래시를 빼니 화면이 참 정갈해졌다는 이야기는 제가 이야기한 "광고" 에 대한 차악적 선택에 있습니다. 광고는 원래가 컨텐츠보다 집중받기 위해서 강제적으로 집중을 요구하는 형태로 제공됩니다. 플래시 광고를 차단해서 편하다고 이야기 한다면, 광고를 만드는 입장에서는 모바일이라면 최상단에 커다랗게 이미지를 배치해서 일단 광고를 보면서 스크롤을 내리도록 배치할 수도 있고, 기술적으로 좀 귀찮음이 있긴 하겠지만 (오히려 저같이 개발과 미디어 제작을 동시에 하는 입장에서는 경쟁력이 생기기에 오히려 반가운) 형태로 플래시를 자바스크립트를 사용해서 동일하게 구현할 수도 있습니다.

말씀하신 부분은 플래시가 사용자에게 불편한 형태로 사용되는 것인데, 이것은 제 원 글에서도 이야기했듯 비지니스 모델의 문제지, 플래시 자체가 가지는 문제는 아닙니다. 광고는 원래가 그렇게 사용되기 위해 만들어졌다는 것이죠. 사용자가 원하는 컨텐츠를 찾아가는 중간에 개입해서 "날 보세요" 라고 만들어지기 때문이지, 플래시가 문제가 되는 것은 아닙니다. 그 자리를 대체할 기술이나 전략적 방식은 얼마든지 있죠...

그렇다고 포털 사이트들이 모두 구글과 같은 비지니스 모델을 가져야만 하거나, 유료로 서비스를 제공해야 한다고 한다면 모든이들이 고개를 절래절래 흔들 것 아닐까 싶네요.

trexx · 2010-02-23, 11:40 PM

@ssen

^^ 네 ssen 님께서 말씀하신 내용에 대해 어느정도 긍정합니다. 통찰력 있는 글 감사합니다. interactive media에 대한 고찰에 대해서 전공하는 입장에서 상당부문 옳다고 생각하고 있습니다.

하지만 우리가 생각하는 interactive media에 대한 근본적인 생각을 해 볼 필요가 있지 않을까 싶습니다.

그 전에 앞서 제가 플래시를 부정적으로 생각하게 된 이유 중 하나에 대해 먼저 언급하겠습니다.

플래시가 좋은 기술이건 아니건 간에 플래시가 사장되어야 한다는 입장에 있게 된 것이 adobe의 욕심때문입니다. 어도브는 인터넷이라는 광야에서 본인의 기술에 대한 독점적 지위를 내세웠기 때문입니다. 그래서 plug-in 으로 구동하게 만들었고 결국 웹엔진에 포함 시킬 수 없는 기술이 되었습니다.
자바스크립트 또한 동일한 길을 갈 수 있었지만 (네스케이프의 지배력이 떨어져서 나온 결과지만) 웹엔진 안으로 들어와서 지금의 구글의 시장력과 애플의 기술(webkit)의 기반이 될 수 있었습니다.

플래시의 길은 어땠나요?
어도브는 스티브 잡스 말따라 너무 게을렀습니다. 플래시가 독점적 지위에 올라서자 윈도우 환경 말고는 플래시 기능개선을 거의 하지 않았습니다. 사실 제가 어도브 입장에 있더라도 기술 공개 결정을 쉽게 하지 못했을 겁니다.

하지만 작은 사이트들이 플래시를 이용해서 간편하게 웹페이지를 제작할때 구글 및 애플 등 웹을 선도하는 업체들은 왜 플래시를 배척하게 되었었까요?
왜 지금 어도브 플래시에서 선도기업들이 멀어져 가고 있을까요? 기술 공개를 해서 플러그인 형태가 아니라 웹엔진에 넣을 수 있었더라면 하고 생각해 봅니다.
자바스크립트! 그리 좋은 기술이 아닐 수도 있었습니다. 수많은 팝업으로 명예가 더렵혔었고 코드 남용으로 사이트를 병들게 했었습니다. 하지만 웹엔진에 안착시키고 W3C DOM으로 CSS 같이 정돈시킬 수 있는 분위기가 되자 엄청난 파괴력을 가진 기술이 되었습니다.

음.. 이제 본 주제에 대해 생각해 보겠습니다.

interactive media에 대하여 전 여전히 환상이 있다고 생각합니다. 15년전에 빌게이츠가 강연하는 비디오가 생각났는데요. 당시 빌게이츠는 인터넷의 미래를 비관하고 있었습니다. 그래서 당시는 TV 등 기존의 가전 제품에서 네트워크를 통한 인터렉트 미디어를 구현하는 모습을 시현 했었지요.(물론 현재도 이 기술은 아직 도전하고 있지요.)
근데 빌게이츠 예상은 완전히 벗어났습니다. 허접하지만 텍스트와 이미지가 하이퍼 링크를 만나자 수요는 폭발적으로 변했습니다.
하이퍼링크! 비약이지만 이 별거 없는 기술이 인터넷 혁명이 단초가 되었습니다. 모든 문서는 연결될 수 있다는 그 혁신성!

흔히들 말하는 interact media에서 사용자가 추구했고 채택했던 것은 무엇일까요? 아무리 플래시에서 많은 기술이 된다고 하지만 실제로 우리의 선택은 공짜 미디어는 유튜브에서 고품질 미디어는 itunes 등 에서 구매하게 되었습니다. 사람들은 미디어에서 원하는 것이 영상통화 등 과 같은 어색한 쌍방향이 아니라 정보 습득은 wikipedia 같은 형태의 텍스트(그림)으로 영상, 음악 등 즐기는 쪽은 거의 일방향(유튜브, 아이튠즈)으로 포지션이 되어있고 이것은 쉽게 바뀌질 않을 것 같습니다.

지금까지 디자이너가 말하는 인터랙트 디자인은 어쩌면 기술 중독자들이 쉽게 빠지는 함정이 아닐까 싶습니다. (자주는 쓰일 수 없는 기술)

가장 단순한 욕구인 보고 즐기고 이해하고가 벗어나면 사용자들은 뭘 어떻게 해야할지 모릅니다. 결론은 컨텐츠라는 이야기 입니다. 아무리 인터랙트 미디어를 구현할 수 있다고 하여도 컨텐츠에 대한 면밀한 이해가 없다면 미디어는 죽은 것입니다.

또한 말씀하신 것 처럼 SNS가 관문 역할을 한다는 데 동의합니다. 하지만 그 링크를 따라가다 보면 인터랙트한 홈페이지와 연결되는 것이 아닌 보다 깊은 사유의 장(블러그 등)으로 연결된다는 것이 중요합니다. 즉 SNS에서 의문의 주제를 발견하고 링크된 글에서 더 깊은 사유를 할 수 있다는 것입니다.
전 트위터의 등장으로 블로그의 시대가 끝난 것이 아니라 오히려 확장 되었다고 생각합니다. 트위터를 통해 사유의 장을 더 활용하는 것이지요.

플래시가 일반인이 경험하는 인터렉트 미디어라는 것이 무엇일까요?
1. 영상(오늘 김연아 다들 보셨지요?^^)
2. 다채로운 효과로 연결된 미디어
3. 기타 등등

제가 많은 홈페이지를 가 보진 못했지만 솔직히 연예인 내지 영화 광고 등 플래시로 구동하는 사이트를 가서 보면 일회성에 그칠때가 많습니다.

정보의 가치는 일회성이 아니라 이용 가능성이 높아야합니다. 즉, 어떤 형태가 되었건 연결될 수 있어야 한다는 것이지요. 이것이 제가 생각하는 인터랙트입니다. 즉 컨텐츠 활용의 확대입니다.
컨텐츠를 활용할 수 있는 1차 미디어인 원 데이터 영화, 음악, 뉴스 등등에서 파생된 것이 제일 중요하고 이를 보다 완성된 형태로 인터랙트하는 것은 부차적인 것입니다. 플래시는 글세요. 제가 볼때 파생된 부분에 너무 많은 기술을 사용했다는 것입니다.

아이팟의 성공에 대한 다큐멘터리에 좋은 언급이 있었습니다. '아이팟이 성공한 배경에는 인간의 욕망이 담겨있다.' 즉 음악을 듣는 것은 컴퓨터를 하는 것과 달리 욕망에 가깝다는 것이지요. 컨텐츠는 인간의 본질적인 모습 욕망에 해당되지 않을까 합니다. 즉, 인터랙트에 인간에 대한 고찰이 플래시의 기술중에 어느것에 해당되는지 꼭 필요는 있는지에 대한 고민이 있어야 하지 않을까요?

음...
전 애플이 iTunes LP와 extras 를 보면서 인터렉트 미디어에 대한 새로운 방향을 제시했다고 봅니다. 이 기술은 현재 아이튠즈에 머물러 있지만 사실 이 것은 Webkit 기술로 기술공개가 되어 있기에 다른 누군가가 컨텐츠를 활용하는데 적극적으로 쓸 수 있습니다. 그리고 덧붙여 보고 즐기는 인간의 근본적인 욕망에 대한 고찰이 있다고 봅니다.

그래서 전 webkit이 플래시 기술에 많이 접근하길 기대하고 있습니다.

ssen님의 통찰력있는 좋은 글 감사합니다.

아참.. 광고에 대해서..
네 맞는 말씀입니다... 하지만 돌이켜 생각해 보면 플래시가 그런 광고에 자주 쓰였다는 것도 오명의 원인이 되어 플래시는 광고에 주로 쓰인다는 선입관을 심어 놓게 되었지요.
근데 유독 우리나라 사이트 들만 그런 것도 문제입니다.

djhan · 2010-02-24, 02:53 AM

업체 입장에서 보면 어도비는 게을러 터진 사기꾼 색희들입니다.

4년 전부터 어도비는 모바일용 플래쉬 라이트가 데스크탑용 플래쉬와 통합될 것이며, 하드웨어 가속까지 지원해서 퍼포먼스를 극적으로 향상시킬 거라고 떠들면서 여기저기 라이센스를 팔고 다녔죠. 그리하여 많은 휴대폰(피쳐폰)과 PMP, MP4 등이 플래쉬 라이트로 GUI를 만들게 됐는데....

그러나 그렇게 오랜 세월이 지났건만, 1) 라이트는 여전히 라이트일 뿐이고 2) 하드웨어 가속은 시궁창에 처박힌 지 오래일 뿐입니다. 그리고 많은 휴대폰과 PMP, MP4의 CPU 빠우어가 플래쉬로 구현된 GUI 애니메이션을 그리는 데 낭비되었죠. 참다 못한 업체들은 차례로 플래쉬를 버리고 다른 호환 엔진으로 갈아타 버렸죠, 뭐.

제가 보기엔 어도비, 게을러 터진 놈들 맞습니다. 개발 툴을 업그레이드해서 포토샵과 함께 팔아먹는 데 혈안이 된 놈들이죠. 이건 조공 수준이 아니라 강탈입니다, 강탈.

열혈 플래쉬 개발자들은 애플이 flex로 개발된 앱들이 개방된 앱스토어를 통해 시장을 장악할 것을 염려해 플래쉬를 올려주지 않는다고 주장하지만, 이건 완전 헛소립니다. 지금 플래쉬로 개발된 어플리케이션 중에서 돈벌이가 되는 거라곤 일본 코믹 마켓에서 팔리는 포르노 야게임 정도밖에 없을 텐데....... 뭐, 이것도 어떤 의미론 염려가 되긴 하겠군요, 흥.

웹사이트에서의 플래쉬 오남용에 관해선 이미 1년여 전에 일본 웹진 컬럼에서도 깐 적이 있으니 한 번 참고해 보시기 바랍니다. 아래는 그 컬럼의 번역 링크입니다.

Flash는 어째서 미움받는가? (번역)

2010-02-21, 02:36 AM	#1
casaubon Moderator Registered: Sep 2001 My Mac: iMac 24" 3.06GHz, Macbook Air 13", iPhone 4, iPad 1G Posts: 2,746 오프라인	아이패드 인사이드: 어도비 플래시 Saturday, February 20, 2010 Inside Apple's iPad: Adobe Flash By Daniel Eran Dilger Published: 12:00 AM EST Apple's new iPad is being criticized for lacking the capacity to render interactive content built using Adobe's Flash platform, but the company shows no sign of reversing course. 2007년, 아이폰은 데뷔할 때부터 플래시를 지원하지 않았다. 그 때 이후로 어도비는 플래시에 대한 관심을 일깨우려는 캠페인을 활성화시키기 시작하였다. 윈도모바일과 노키아S60/심비안, Palm WebOS, 안드로이드용 플래시 10.1 런타임 발표도 여기에 해당된다. (그러나 RIM의 블랙베리는 여기에 끼지 않았다.) 즉, 플래시 지원이 없다 함이 아이패드에 문제가 될 수 있음을 주장하고자 하는 캠페인이다. 어도비는 또한 애플이 아이폰 플랫폼에서 플래시를 선택하지 않은 이유가 애플의 불공정한 제한때문이라는 분석가와 전문가들의 입을 빌고 있기도 하다. 또 있다. 어도비는 HTML5와 관련, 웹의 개방표준을 지원한다고 말을 하고 있긴 하지만, 플래시가 "웹이 매우 중요(critical)"하다는 입장을 견지하고 있다. 즉, 플래시 플랫폼의 폐쇄형 구조에 새로운 컨텐트를 확보함으로써 그 지위를 공고화하려고자 함이다. 이는 플래시 관련 플랫폼인 플렉스, 그리고 AIR 구상에도 이어진다. Will being Flash-free hurt the iPad? 휴대기기 부문에서 플래시에 대한 어도비의 주장은 지지를 받기 힘들다. 아이폰은 플래시 지원 없이도 이미 대성공을 거두었기 때문이다. 애플 아이폰은 휴대폰용 웹브라우저에 대한 소비자들의 기대치를 한껏 올려 놓았다. 플래시 없이도 이렇게 해 놓았기 때문에, 애플은 웹이 어떻게 보여야 한다는 정의를 다시 내렸다고 할 수 있다. 적어도 휴대기기 부문에서 말이다. 데스크톱 PC용으로 디자인한 플래시 컨텐트를 렌더링할 수 있는 휴대기기들도 있기는 하다. 그러나 어도비의 휴대기기용 플래시 전략은 원래 아이폰보다도 먼저 나온 플래시 라이트(Lite)였다. 어도비의 옛날 플래시 7(MX 2004)와 액션스크립트 2.0 바이트코드에 기반하는 플래시 런타임의 일종이 바로 플래시 라이트이다. 그러나 여기에 문제가 있었다. 어도비의 플래시 9/10은 액션스크립트 3.0 바이트코드를 사용하기 때문에, 액션스크립트 가상머신이 완전히 뒤바뀐다는 점이다. 데스크톱 상에서 어도비는 예전 플래시는 물론 현대적인 컨텐트도 돌리기 위해 엔진 두 개를 포함시키기만 하였다. 그러나 휴대기기에서는 그렇게 단순한 해결책이 여의치 않다. 휴대기기의 제한적인 프로세서와 메모리 자원때문이다. 기본적으로 어도비의 플래시 라이트 전략은, 각 모바일 플랫폼별 플래시 런타임을 따로 만드는 대신, 휴대기기에서 플래시 컨텐트를 돌릴 수 있도록 하는데 있었다. 그러나 어도비는 리눅스나 PS3의 NetFront 브라우저, Wii의 오페라, 그 외 여러가지 모바일 플랫폼용은 고사하고, 윈도 PC와 맥오에스텐용 플래시를 지원하는 데에도 어려운 시간을 보내고 있는 지경이다. 어도비는 액션스크립트 3.0 바이트코드를 지원하는 플래시 11이 모든 데스크톱과 모바일 플랫폼(블랙베리와 아이폰, 아이포드 터치, 아이패드를 제외)에서 곧 돌아가기를 바라고 있다. 하지만 제일 빨리 자라나고 있는 모바일 플랫폼, 그리고 제일 대중적인 스마트폰 플랫폼 두 가지를 모두 제외했다는 점은 정말 문제를 일으킬 수 있다. 어도비 기술을 사용하다가는 최고순위의 모바일 플랫폼 컨텐트를 만들 수 없게 되어버리기 때문이다. 아이폰은 플래시를 지원하지 않는다. 그렇다고 해서 아이폰이 안팔리지는 않았다. 설사 다른 플랫폼이 플래시를 열광적으로 지원한다 하더라도, 오히려 휴대기기용 플래시의 중요성을 깎아내리는 역할을 수행하고말았다. 다른 플랫폼 개발자들이 플래시를 모바일 사용자들에게 보여주려 하더라도, 윈도모바일과 안드로이드, 심비안 등의 네이티브 소프트웨어를 만드는 대신 플래시로만 보여 주어야 한다. 즉, 여전히 애플의 우위다. 애플의 앱스토어가 다른 경쟁사들보다 한참 앞서 있기 때문이다. Is Apple being unfair to Adobe and restricting choice? 아이폰 OS가 플래시를 지원하지 않는 데에 따르는 두 번째 문제가 있다. 애플과 같은 플랫폼 업체는 자기가 뭘 지원할지, 뭘 지원하지 않을지 정할 권리를 갖고 있기 때문이다. 어도비는 애플이 소비자들에게 선택권을 줘야한다는 입장이다. 즉, 웹을 사용하는 거의 모든 다른 기기들과 마찬가지로, 플래시 런타임을 아이폰이 포함시켜야 한다는 의미다. 흥미로운 주장이다. 플래시의 역사를 보면, 애플이 그저 약자를 박해하는 것이 아니라, 미디어 유통에 대한 자신의 지위를 다시금 재천명하고 있다고 볼 수 있기 때문이다. 1991년, 데스크톱 상 영상과 애니메이션, 멀티미디어를 퀵타임으로 소개한 곳은 애플이었다. 마이크로소프트가 윈도 PC에서 신뢰성 있는 오디오 재생력조차 보여주지 못하던 시절이었다. The Origins of Flash 플래시는 원래 휴대용 펜 컴퓨팅 기기용 그리기 앱으로 구상했던 SmartSketch라 불렸었다. 이 스마트스케치는 매킨토시와 PC 플랫폼용으로 나와 어도비 일러스트레이터, 앨더스 프리핸드와 경쟁을 벌였다. 거대한 경쟁제품들과 싸우기 위해, 스마트스케치는 1996년, FutureSplash Animator라 불리우는 애니메이션툴과 합병하였다. 그리고 그 당시 웹이 새로운 플랫폼으로 나타나자, 개발사인 FutureWave는 썬 자바를 통해 애니메이션 툴을 만들려 했지만 속도가 엄청나게 느렸다. 당시 넷스케이프는 브라우저 플러그인용 API를 발표해 놓은 상태였고, FutureWave는 FutureSpalsh 컨텐트용 네이티브 플러그인을 만들어 놓았다. 애플은 이미 퀵타임 플러그인을 제공해오고 있었고, 이용자들은 퀵타임을 이용, 비디오나 웹 페이지의 다른 컨텐트를 볼 수 있었다. Microsoft's war on the open web 웹이 대중화되어가자, 마이크로소프트는 개발자의 관심을 윈도 플랫폼으로 돌리기 위해 노력을 기울이기 시작한다. 일단 넷스케이프를 부수기 위해 인터넷 익스플로러를 활용하였고, 인터넷 익스플로러는 웹을 윈도에 묶어두는 역할을 하였다. 그 후 마이크로소프트는 썬과 파트너쉽을 맺은 다음, 썬 자바를 썬에게도 떼어내어 윈도에 의존하도록 하였다. 비디오 영역에서는 애플 퀵타임을 베끼려 시도하기도 하였다. 웹과 관련있는 이 세 가지 모두에게 있어서 마이크로소프트가 원수인 셈이지만, 퀵타임에 대해서만은 마이크로소프트가 죽일 수 없었다. San Francisco Canyon 스캔들 사건으로 인해 마이크로소프트가 애플 코드를 베꼈다는 점이 드러났기 때문이다. 덕분에 애플은 법적 근거를 갖고 마이크로소프트를 강하게 공격하였고, 마이크로소프트는 이에 반응하여 오피스를 윈도용으로만 집중한 채, 맥용 오피스 지원은 한참동안 하지 않았다. 이와 동시에 마이크로소프트는 인터넷 익스플로러를 통해 얻게 된 힘으로, 퀵타임 호환성 문제를 일으켰다. 퀵타임용 컨텐트가 있는 웹을 읽어들일 수 없도록 만든 것이다. 1996년, 마이크로소프트는 디즈니와 매크로미디어, 퓨처웨이브와 함께 개방형 웹을 폐쇄형 컨텐트로 만들기 위한 연합체를 발족시킨다. 그 결과 매크로미디어는 퓨처웨이브를 인수하였고, 플래시라는 제품이 나오게 된다. Flash displaces QuickTime 1998년, 개방형 MPEG-4 사양으로 애플 퀵타임 컨테이너 사양을 채택하긴 했지만, 마이크로소프트는 인터넷 익스플로러를 통해 웹용 비디오와 애니메이션을 제공하는 폐쇄형 방식으로 플래시를 유통시켰다. 한 때 매크로미디어와 플래시에 대한 직접적인 경쟁사였던 어도비는 마이크로소프트-매크로미디어 연합체에 반격하기 위해 SVG를 웹애니메이션의 개방 사양으로 대응하였다. 단, 어도비는 플래시를 얻기 위해 매크로미디어를 인수하기에 이르른다. 비디오 재생에 있어서 플래시가 지배적인 방식으로 떠오르자, 마이크로소프트는 고유의 방식인 실버라이트 작업을 시작한다. 개방형 웹표준을 웹플러그인에 의존적인 바이너리로 바꾸려는 시도였다. 애플과 구글, 그 외 다른 기업들은 개방표준인 HTML5를 지지하였다. 플러그인 없는 멀티미디어 제공을 위한 표준이 HTML5이며, 브라우저 자신이 MPEG-4 개방사양에 따라 비디오를 렌더링한다. 이러한 역사를 보면, 플래시 지원을 반대하는 애플의 입장이 유명한 플러그인에 대한 공격이 아니다. 선택의 제한도 아니다. 웹상에서 개방표준을 사용하기 위한 노력일 따름이다. 그럴 경우 소비자 선택에 대한 진정한 시장이 열리기 때문이기도 하다. 어도비가 멀티미디어 재생 통제를 하는 것이 아닌, 정말로 개방표준에 흥미가 있다면, 플래시를 한 때 자사가 소유했던 PDF처럼 풀어 놓아야 한다. 그러나 HTML5를 지지하는 입장이라는 말을 하면서도, 어도비 CEO, 나라옌(Shantanu Narayen)은 HTML5에 대해 이런 말을 덧붙였다. "브라우저간에 HTML5를 어떻게 일관성있게 보여주느냐, 이것이 HTML5의 문제가 될 수 있으리라고 봅니다. 요새 많이들 거론하고 있는 현재의 계획을 보면 브라우저간 HTML5 표준화가 이뤄지기까지 10년은 걸릴 것 같더군요." Is Flash critical to the web? HTML5 표준이 앞으로 "10년" 더 남았다는 것이 어도비의 입장인 셈이다. 플래시가 앞으로도 주요 역할을 해야 하기 때문이다. 그러나 지난 3년간 아이폰과 아이포드 터치는 플래시 없이 대성공을 거둘 수 있음을 증명하였다. 즉, 아이패드가 굳이 플래시를 지원하지 않더라도 문제가 없으리라는 의미다. 다시 말해서, 어도비는 플래시 개발자 지원과 라이센스를 거론하지만, 플래시 컨텐트로서 중요한 지위를 차지하는 것은 데스크톱 이용자들일 따름이다. 플래시 라이트가 요새 플래시 컨텐트조차 돌리지 못하기 때문이다. 플래시가 그만큼 데스크톱에 초점을 기울였기 때문이며, 플래시 애니메이션 대부분은 휴대기기용으로 스케일-다운 디자인조차 해놓지 않고 있다. 플래시 컨텐트는 멀티터치 디스플레이보다는 마우스 포인트 위주로 디자인이 되어 있고, 런타임 또한 데스크톱-급의 컴퓨팅 리소스를 소모한다. 배터리 수명 보존을 위해 최대한 리소스를 절약해야 하는 휴대기기용이 아니다. Activity Monitor를 한 번 돌려보시라. 플래시를 웹페이지 안에서 조금만 사용하더라도, 거대한 리소스를 잡아먹게 된다. 그린피스가 합법적인 환경지킴이라면, PVC나 BFR보다 플래시가 환경에 더 큰 위협이라는 점을 알아야 한다. 정말 가치 없는 것을 보는데 막대한 리소스를 사용하기 때문이다. Flash on the wane in video delivery 웹에서 플래시의 비중은 감소중이다. 웹비디오 대부분은 한 때, FLV(플래시의 폐쇄형 네이티브 미디어 컨테이너) 안의 폐쇄형 코덱, On2를 사용하여 인코딩하였는데, 향후 개발은 MPEG-4 컨테이너(애플 퀵타임 컨테이너 포맷에 기반을 둔다) 안에서 H.264 코덱으로 이루어질 것이다. 어도비조차 F4V라 부르는 MPEG-4 컨테이너를 따로 마련하여 H.264 비디오를 지원하기로 하였다. 이 때문에 비디오를 전달하기 위해 꼭 플래시를 필요로할 이유가 없다. 구글도 유튜브의 플래시 영상을 H.264로 이주중이다. Flash and Rich Internet Applications 어도비는 플래시를 RIA(Rich Internet Applications) 제공 방법으로서 플렉스와 에어, 그리고 전통적인 출력물의 인터랙티브 버전으로 밀고 있다. 이와 반대로 애플은 아이패드용 컨텐트 제작에 있어서, 출판업체들과 컨텐트 업체들이 HTML5를 사용하도록 독려하고 있다. 컨텐트에 인터랙티브 기능을 넣는 것만으로 어도비에 세금을 내지 않도록 말이다. 애플 자신이 HTML5의 거대한 후원자이기도 하며 MobileMe처럼 자바스크립트 프레임웍을 사용, RIA를 만들기도 하였다. (MobileMe의 경우, SproutCore를 사용하여 만든 웹앱이며, 그 외 음반사와 영화사들과 파트너를 맺어 아이튠스 LP, Extras를 만들고 있다.) 구글 또한 HTML5를 이용한 RIA 개발을 선도하고 있다. 이는 크롬OS의 전략이기도 하다. 구글 직원들은 안드로이드의 유사-자바 플랫폼을 결국 HTML5로 바꾸기 위한 디딤돌 정도로 묘사하고 있다. 애플이 Cocoa Touch 아이폰 OS 플랫폼을 묘사하는 바와 마찬가지의 장기적인 플랫폼 전략이다. Apple's preference for open over Adobe Flash 애플은 아이폰과 아이포드 터치, 아이패드에서 플래시를 지원하지 않음으로써, 플래시와 실버라이트와 같은 폐쇄형 바이너리와 상관 없는 거대한 사용자층을 만들어냈다. 이는 애플 앱스토어 플랫폼, 그리고 개방형 웹으로 사용자들의 관심을 성공적으로 끌어냈으며, 개발자들을 표준에 기반한 RIA와 멀티미디어 개발로 이끌고 있기도 하다. 이와 반대로 구글은 웹 개방표준을 강력하게 지원하고 있기는 하지만, 안드로이드 기능으로 플래시 재생지원을 홍보하고 있기도 하다. 안드로이드용 네이티브 앱 개발 매력을 떨어뜨리는 조치이다. 마이크로소프트 역시 스타일러스에 의존적인 윈도모바일 앱을 지원하기 위해 플래시와 실버라이트를 동시에 홍보중이다. 노키아의 심비안과 리눅스 플랫폼 또한 자신의 네이티브 개발을 희생시킨만큼 플래시를 띄우고 있다. 애플은 경쟁사들이 플래시에 더 몰려들수록 휴대기기용 앱스토어에서 더 1위를 굳힐 수 있을 것임을 깨달은 것으로 보인다. 즉, 아이폰 OS 기기에서 플래시 런타임이 돌아갈 일은 앞으로 거의 없다고 봐도 될 것이다. AppleInsider \| Inside Apple's iPad: Adobe Flash __________________

2010-02-21, 09:33 AM	#3
casaubon Moderator Registered: Sep 2001 My Mac: iMac 24" 3.06GHz, Macbook Air 13", iPhone 4, iPad 1G Posts: 2,746 오프라인	iPad에서 플래시가 안돌아가는 이유 RoughlyDrafted Magazine Daniel Eran Dilger in San Francisco An Adobe Flash developer on why the iPad can’t use Flash February 20th, 2010 Daniel Eran Dilger Flash 구축에 대해 전문가라 할 수 있는 인터랙티브 컨텐트 개발자인 모건 아담스(Morgan Adams)가 플래시와 아이패드에 관한 흥미로운 글을 보내왔다. 나머지는 동 주제에 대한 그의 글이다. 전 왜곡되어 있다고 할만 합니다. 전문 플래시 개발자이자, 아이패드용 플래시 사이트 의뢰가 들어오면 행복해 할 테니까요. 정말 그러고 싶습니다만, 그것이 합리적이지는 않습니다. 아이패드용 플래시는 나오지 않을 것이며, 나와서도 안됩니다. 주된 이유는 그동안 거론이 안된 이유때문입니다. 현재 플래시 사이트들은 터치스크린 기기에서 잘 만들어질 수가 없어요. 애플이나 어도비는 커녕 마술과 같은 새 기기가 나오더라도 어쩔 수 없습니다. 즉, 이 이유는 느린 휴대기기의 성능이나 배터리 수명, 충돌현상때문이 아닙니다. 마우스오버, 혹은 호버(hover) 문제 때문입니다. 대다수가 아니라 하더라도, 수많은 플래시 게임과 메뉴, 심지어 비디오 플레이어에 이르기까지 플래시 컨텐트는 눈에 보이는 마우스 포인터를 필요로 합니다. 뭔가에 대한 호버링(마우스오버)과 실질적인 클릭 간의 관계에 의존하는 코딩이기 때문이지요. 이 차이는 흔한 겁니다. 인터랙티브 디자인에는 근본적이기도 하고, 널리 퍼져있기도 하지요. 플래시 컨텐트의 기본적인 사용에 있어서도 필수적입니다. 터치스크린용으로 디자인한 플래시 컨텐트를 새로 만들 수는 있겠지만, 사람들이 원하는 건 기존의 플래시 사이트입니다. 모두 다이죠. 여기는 되고 저기는 안되고, 그런 것이 아니에요. 그것도 사용할 수 있어야 합니다. 불가능한 일이에요. 애플과 어도비가 할 수 있는 일이란 것이, 현재의 플래시 컨텐트를 보이게 만드는 것 뿐입니다. 그러면 보이긴 하겠죠. 하지만 종종 작동을 안할 겁니다. 그러면 이용자들은 이게 안보인다고 화를 내겠죠. 페이지 사이에 갭이 있다거나 배너광고가 안보이고, 플래시 게임 페이지를 방문할 때마다 다시 다운로드받는 대신 앱스토어에 가서 다운로드받아야 할 때 내는 짜증 이상일 겁니다. Mouseover examples: * 마우스오버가 있을 때 컨트롤이 나타나거나 숨는 비디오 플레이어. (사실상의 표준같아 보입니다만 영상 가운데를 클릭하면 보통은 멈춤이지요. Hulu를 해 보십시오.) * 클릭 없이 마우스를 돌려서 하는 게임. (매우 일반적입니다.) * 마우스를 메인버튼 위로 움직이면 하부 페이지 링크가 나타나는 메뉴. (클릭할 때 메인 카테고리 페이지로 직접 갈 때와는 다릅니다.) * 마우스가 움직일 때 중요한 설명이나 요약이 나오는 버튼. 클릭하기 전에 무엇인지 이해해야 할 필요가 있을 때 나옵니다. * 마우스오버를 통해 프리뷰를 보는 기능. 아바타용 머리 색깔을 고를 때와 같은 것입니다. 캐릭터가 마음에 들 때까지 색상을 마우스로 고르는 것이지요. 정해지면 클릭을 합니다. * 클릭을 전혀 사용하지 않는 지도와 표. 하지만 마우스를 움직일 경우 나타나는 팝업 정보. * 마우스만 있으면 "돌아가는" 개별 마우스오버 기능. 설명이 필요 없음. 이런 사례들을 손가락(혹은 전통적인 스타일러스)으로 올바르게 할 수가 없습니다. 터치스크린 상에서 클릭 없이 뭔가를 포인팅하는 것은 마우스오버가 아니지요. 그저 손가락을 허공상에서 움직이는 것과 마찬가지입니다. 기기가 인식하지 못하는 상황이죠. 또한 오른쪽-클릭에 의존하는 플래시 사이트도 있습니다. (보안설정과 같은 것을 위함이죠.) 물리적인 키보드를 요구하는 것도 있습니다. 특히 게임이 그러하죠. 플래시를 원하는 주된 이유 중 하나가 게임입니다. (비디오도 그럴 수 있겠지만, 비디오는 플래시 없이도 돌릴 수 있고, 그렇게 하는 사이트가 점차 늘어나고 있습니다. 플래시 비디오가 제일 아쉬울 곳은 아무래도 유튜브이겠죠.) 게임은 실질적인 키 컨트롤을 사용할 때가 종종 있습니다. 싱글 프레스(single press)와 롱홀드(long hold), 그리고 코딩(chording) 모두를 필요로 하죠. 가령 오른쪽 화살표를 누르고 있으면 계속 걸어갑니다. 이와 동시에 스페이스를 치면 불을 발사하는 식이죠. 위쪽 화살표를 치면 점프한다거나 위쪽 화살표를 계속 누르고 있으면 더 높게 점프하는 식입니다. 터치스크린 키보드는 그런 종류의 정확하고 빠른 동작을 할 수 없어요. 게다가 키보드가 게임 화면을 가리기도 할 겁니다. 터치스크린 상의 게임은 터치스크린에 어울리는 컨트롤을 넣어야 합니다. The only potential “solutions” to the mouseover problem are terrible ones: A) 최고의 경우: 모든 사이트의 모든 플래시 앱을 프로그래머들이 다시 디자인하고 코딩하는 것입니다. 터치스크린을 위해서이죠. 마우스오버를 더 이상 사용하지 않거나, 아예 이중 버전으로 해놓으면 되겠죠. 마우스오버가 필요한 경우 마우스를 사용할 수 있도록 말입니다. 상당한 작업이 필요할 것입니다. 수만 곳이 해야 할 일이죠. 즉, 불가능합니다. 게다가 마우스오버가 너무나 근본적이어서, 사이트 개념 자체를 바꿔야 할 곳도 많을 것입니다. 기존 이용자들이 완전히 바뀐 사이트를 사용해야 하겠죠. (그런데 단순히 플래시를 없애고 하는 디자인보다 쉬울까요 과연? 꼭 그렇지도 않습니다.) B) 제스쳐나 손가락 움직임, 외장형 버튼으로 마우스오버를 시뮬레이션하는 것입니다. 마우스오버는 그 자체가 클릭/탭보다 더 간단하고 더 복잡하지 말아야 하기 때문에 멍청한 짓이죠. 자연스러워야 하며 새로 배울 필요도 없어야 합니다. 데스크톱을 쓰던 습관을 완전히 뒤바꿔서는 안되죠. 하지만 게임에 이르르면, 추가적인 수정도 결국 안돌아갈 겁니다. 빠르고 단순하게 반응해야 하니까요. 시뮬레이트 마우스오버 버튼을 누를 때가 언제인지, 손가락 세 개를 이용할 때가 언제인지를 기억해야 할 필요가 없어야 하는데 말입니다. 게임 자체가 매우 어려운 존재입니다. 그렇게 했다가는 재미를 상당히 빼앗아가겠죠. C) 클릭 자체를 근본적으로, 끊임 없이 사용하는 것으로 보다 복잡하게 만드는 방안이 있습니다. 무엇이든 등록하기 전에, 더블-탭이나 두 손가락 탭을 필요로 하는 것이죠. (투 탭은 현재 모바일 사파리가 자바스크립트 팝업메뉴에 대해 사용하는 방식입니다. 첫 번째 탭을 하면 메뉴가 뜨고, 두 번째 탭으로는 메뉴를 선택하지요.) 하지만 플래시 앱과 게임 다수는 이미 더블-클릭(혹은 빠른 클릭)을 나름대로 목적으로 사용하고 있습니다. 별도의 탭은 특정 상황(메뉴 팝업)에서만 쓸모있을 따름이죠. 단순한 클릭도 아닙니다. 움직여줘야 합니다. 드래그 대 마우스오버 움직이기랄 수 있겠네요. 게임중에 시스템이 이 모든 것을 빠르고 단순하게 해낼 수 있다 하더라도, 특별한 규칙을 웹페이지의 어느 부분에 적용하는지 이용자가 어떻게 알 수 있을까요? 페이지의 일부는 스크롤이나 링크-클릭을 제대로 하고 다른 곳은 완전히 다르게 한다면요? (터치-기반의 앱이 어떻게 될지는 고사하고 말이죠.) D) 손가락 근처에 눈에 보이는 마우스 포인터를 갖다 놓고, 직접적으로 인터랙트하지 않는 방안이 있습니다. 애플의 트랙패드 스타일이죠. VNC 클라이언트에서도 보이는 탭-드래그 제스쳐를 사용하는 겁니다. 이런 간적 컨트롤은 직접적인 터치형 조작의 원칙을 뒤흔들게 됩니다. 터치스크린이 "노트북"처럼, 그리고 노트북보다 더 안좋게 변하는 것이죠. 굳이 터치스크린을 쓸 이유가 사라지는 겁니다. 다시 말씀드리건데, 이 경우, 페이지의 어느 부분이 직접적인 터치모드인지, 아니면 "화살표 드래그" 모드인지를 계속 기억하고 있어야 합니다. E) "리얼" 탭을 별도로 요구하는 방안이 있습니다. 즉, 가벼운 탭과 무거운 탭을 구분지어야 하게 되겠죠. 직관적이지 않아요. 오작동할 가능성도 높아집니다. (단순한 클릭만으로도 RIM 블랙베리 SurePress 실험이 실패했었습니다.) 브라우저 플러그인 하나 때문에 전체 기기를 복잡하게 만들어버리는 겁니다. 비용도 더 비싸지고요. 따라서 애플이 그냥 플래시를 거부한 것이 아닙니다. 논리적으로 지원을 할 수가 없어요. 손가락은 마우스가 아닙니다. 그런데 플래시 사이트들은 마우스 포인트(그리고 키보드)를 근본적인 방식으로 요구하는 디자인이죠. 언젠가는 바뀌겠죠. 모든 플래시 사이트를 터치스크린 친화적으로 바꿀 날이 올 겁니다만, 그렇다고 해서 지금 플래시 사이트가 돌아가지는 않을 겁니다. 성능이나 배터리 수명, 충돌 문제가 전혀 없다 하더라도(분명 문제가 있지요), 어느 회사의 터치스크린이건, 터치스크린용으로 현재의 플래시 사이트들을 제대로 즐길 수는 없을 겁니다. 불만을 가질만한 부분을 다 들어줄 수가 없어요. 그런데 저는 플래시 개발자입니다. 제가 만든 애니메이션 사이트가 최신 유행의 아이폰에서 안돌아갈 때 제 느낌이 어떻겠습니까! 그래서 전 WebKit의 CSS 애니메이션 기능을 이용하여 애니메이션을 새로 만들었습니다. 데스크톱 이용자들도 물론 adamsi.com에서 플래시를 보실 수 있죠. 아이폰 이용자들도 애니메이션을 볼 수 있습니다. 즉, 이 방식은 할 수 있는 방식입니다. Morgan Adams, adamsimmersive interactive design and games Daniel Eran Dilger is the author of “Snow Leopard Server (Developer Reference),” a new book from Wiley available now from Amazon as a paperback or digital Kindle download. An Adobe Flash developer on why the iPad can’t use Flash — RoughlyDrafted Magazine __________________ casaubon 님께서 2010-02-21 06:59 PM 에 수정하셨습니다..

2010-02-21, 06:35 PM	#4
firemanx Elite Member Registered: Feb 2006 My Mac: iMac Intel Core Duo 20"(2006), MacBook 2.0 White(2006), Mac Mini Core 2 Duo(2010), iPod Video 30G, iPhone 4G, iPad Wifi 64G, AppleTV 2G. Posts: 1,007 오프라인	인터렉티브한 요구에 부응하기 위해서 플래쉬가 태어났다면 그나마 이해를 하겠습니다만, MS의 실버라이트까지 보아버린 이상, 정말 "이놈은 또 뭔가효?"라는 말을 외치게 되더군요. 진짜 악당은 역시나 MS라는 생각을 또 하게 되었지요. 상도덕이라는 말이 IT 세계에서도 먹힐지는 모르겠지만 하여튼 MS는 꼴통이 맞습니다. 그 와중에 또 뒷다리 들이 밀어서 구정물 일으키는 것을 보면요. 이제 어도비는 애가 타겠고. 애플은 상황보고 판세만 조절하면 될 듯 합니다. 플래쉬가 없어지는 것에는 여전히 찬성입니다. 잘 읽었습니다. ^^; __________________ 맥도리의 블로그 : http://macdory.blogspot.com

2010-02-22, 07:17 AM	#7
drzekil Veteran Member Registered: Dec 2006 My Mac: NMBA 13", iMac 20" Posts: 704 오프라인	두번째 컬럼의 내용은 제가 여기 저기에서 많이 주장한 내용이네요.. 비단 플래시만의 문제는 아닌것 같습니다. 아이패드가 아이폰 기반이 된 이유도 비슷한 이유가 아닐까 싶습니다. 맥OSX도 플래시보다는 괜찮지만 그래도 마우스 포인터가 필요하고 또한 보조클릭이 필요하게 디자인 되었으니까요.. __________________ drzekil의 Talk about Apple 놀러오세요..^^

2010-02-22, 11:36 PM	#11
skonmeme Elite Member Registered: Dec 2005 My Mac: Macbook Posts: 1,013 오프라인	1. 아도비와 플래시를 옹호하시는 많은 분들이 아무리 주장한 들 맥과 리눅스에서 플래시가 엉터리 퍼포먼스를 보인다는 것은 누구나 동의하고 있는 바입니다. 그걸 빠르다고 주장해보셔야 아무런 의미가 없다는 뜻입니다. 이건 스마트폰의 경우에도 마찬가지라고 봐야할 것입니다. 또한 이런 주장이 사실이라고 해도 의도가 뻔한만큼 아이폰과 아이패드에는 플래시가 안들어갑니다. 아무리 아도비가 사정한다해도 소용없는 일이죠.. 유일한 방법은 MS를 잘 구술려서 Window Phone 7이나 그 후속버전이라도 플래시가 들어가도록 협상하는 것이고, 안드로이드 폰에서 상당한 수준의 퍼포먼스를 직접 증명하는 수밖에 없습니다. 그래고 더욱 중요한 것은 지금 스마트폰 시장을 선도하는 아이폰의 위세를 꺾고 WP7이나 안드로이드가 압도적으로 치고 나가야하는만 합니다. 이것이 충족된다면 애플은 은근슬적 아이폰과 아이패드가 지원하도록 할지도 모릅니다. 2. 2~3년전만 하더라도 자바스크립트의 성능은 처참했습니다. 그중에서도 IE의 자바스크립트는 그냥 끼워팔기 수준이었습니다. Acid3 테스트가 일반화되고 브라우저 전쟁이 일어나면서 급격히 성능이 향상되기 시작했습니다. 곧 플래시가 보여주던 성능을 순식간에 압도했습니다. 플래시를 대체하자는 얘기는 이때와서야 나오기 시작한 것입니다. 이미 상당부분에서 플래시로 구현되던 부분이 자바스크립트로 대체되었습니다. (당연한 얘기이지만 전부는 아닙니다.) 아직 SVG나 canvas가 성능이 부족하고 플래시가 가진 기능을 제대로 구현하기 힘들다고 해서 미래에도 그렇다고 (10년후?) 얘기할 수는 없습니다. 오픈된 환경에서의 경쟁은 아도비가 혼자 관리하는 기술정도는 쉽게 뛰어넘습니다. 이미 오페라, 사파리, 파이어폭스 등이 실증했습니다. Acid3를 통과시킨 웹엔진 개발팀들은 지금 뭘하고 있다고 생각하시나요.. 슬슬 도래할 Acid4에 대비해 SVG와 canvas의 구현과 성능 개선에 들어가고 있다고 봐야하지 않을까요? 몇년 걸리지 않아서 플래시가 가지는 기능과 함께 성능도 따라 잡힐거라고 봅니다. 3. 물론 앞으로도 광고등으로 인해 사이트가 무겁다는 점은 쉽게 해결이 되지 않을 것입니다. 하지만, 이런 무거움은 플래시로 가중되고 있다는 점을 생각해야 합니다. 그 가중됨을 온전히 웹엔진에서 처리하게 된다면 그 효율이 더 나아지면 나아졌지, 현재와 같은 수준은 아닐 거라고 생각됩니다. 4. 현실적으로 HTML5의 길을 보여준 것은 W3C의 표준화 모임이 아니라, Acid3 테스트와 자바스크립트 속도 경쟁이였다고 생각합니다. 어느 정도 동의된 기능에 대해 (말 그대로 산업표준) 테스트툴을 만든 이후로 개발자들은 Acid3 테스트를 통과하기 위해 주구장창 뛰었다고 볼 수 있습니다. 지지부진했던 자바스크립트 속도도 급격히 개선되었구요.. 특히 점수로 표현되는 Acid3 테스트는 개발자들에게 불을 질렀습니다. HTML5은 당분간 표류할 것은 분명하지만, Acid4가 만들어지는 순간 웹엔진 개발자들은 다시 뛸 거라고 봅니다. __________________ 멍멍 :P

2010-02-21, 06:32 AM	#2
trexx Senior Member Registered: Nov 2001 My Mac: MacBookPro 1st 2.0 Core Duo 15inch(2006), iMac 2.4 24inch (2007), Macbook Air 2nd 1.6 SSD 128GB (2008), iMac i7 2.93 27inch(2010), iPod 4th 40GB(2005), iPod 5th Black 30GB(2006), iPod nano 2nd RED 8GB(2006), iPhone 4 32GB(2010), iPad 1st 32GB(2010) Posts: 218 오프라인	명쾌하군요. 정말 좋은 글입니다. 좋은 글 번역해 주신 까소봉님 감사합니다. 제작년 말에 연구원 대표 홈페이지 기획할때 제가 웹표준으로 가야한다고 말하니 웹 2.0으로 알아 듣고 플력스로 홈페이지를 제작하자고 하더군요. 그 업체는 제외시켰습니다. 우리나라 대부분의 에이전시의 문제이기도 하지만 아직까지 웹표준에 대한 인식이 별로 없다는 것이지요. 홈페이지 제작을 시작할때 쯤 개발자가 플래시 넣을 거냐고 물어 봤을 때 단호히 거절했습니다. 맥 사용자로서 버벅거리는 플래시를 더이상 보기 싫었고 외국에 출장갔을때 플래시때문에 로딩을 포기했었고 그 전해에 발표했던 아이폰에 플래시가 안돌아 간다고 생각하니 결론이 나왔습니다. 아무리 다른 커뮤니티에서 애플의 플래시 제외에 대한 온갓 말을 다 하지만 (정치적인 결정이내 하며) 전 애플이 영원히 플래시를 지원 안했으면 하는 사람입니다. webkit이 더 자유로이 발전했으면 합니다.

2010-02-22, 01:32 AM	#5
chansap2 Senior Member Registered: Jun 2009 My Mac: Macbook Core duo(2006), MacBook Pro 15' (2010, mid), iPad2, Mac Mini (2011) Posts: 119 오프라인	두번째 올려주신 컬럼 내용이 참 좋네요. 플래시가 무겁고 전력을 많이 소모한다는 이유보다 좀더 근본적인 이유로 느껴지네요 ^^

2010-02-22, 03:04 AM	#6
woozooso New Member Registered: Dec 2009 My Mac: mac pro 2009, 2x 2.26 Quad Posts: 13 오프라인	언제나 빠르고 훌륭한 번역에 감사드립니다

2010-02-22, 05:45 PM	#9
trexx Senior Member Registered: Nov 2001 My Mac: MacBookPro 1st 2.0 Core Duo 15inch(2006), iMac 2.4 24inch (2007), Macbook Air 2nd 1.6 SSD 128GB (2008), iMac i7 2.93 27inch(2010), iPod 4th 40GB(2005), iPod 5th Black 30GB(2006), iPod nano 2nd RED 8GB(2006), iPhone 4 32GB(2010), iPad 1st 32GB(2010) Posts: 218 오프라인	매번 좋은 글 감사합니다. 플래시 지원에 대한 정보를 얻고 싶었는데 가려운 곳을 긁어 주셨습니다.

2010-02-22, 06:43 PM	#10
ssen Member Registered: Jun 2009 My Mac: mac pro, macbook pro, iphone Posts: 86 오프라인	플래시 개발을 하고 있고, 동시에 디자인도 하고 있습니다. 사실 플래시에 대한 관점은 장님 코끼리 다리 만지기와 같아서 양쪽 모두 맞는 말이기에 논쟁이 쉽사리 꺼지지 않는 경향이 있습니다. 하지만, 몇가지 오류들을 정확히 되짚어보자면... 플래시가 웹 리소스를 과하게 잡아먹는다는 이야기는 사실 옳지는 않습니다. 리소스를 많이 잡아먹는 작업에 플래시가 어울려서 사용되는 것뿐이지, 플래시가 없어진다고해서 그 컨텐츠들이 사라지는 것은 아니니깐요... 쉽게 이야기해서 HTML5 를 많이 이야기하지만, 플래시가 없어지면 광고가 canvas 와 video 태그로 전환될 것이 분명하고, 그 때, 과연 플래시보다 빠를까? 과부하가 없을까? 라는 것에는 동의가 안되는 것이죠... 의외의 이야기일지도 모르겠지만 플래시는 굉장히 빠릅니다. 최신이 아닌 모든 브라우저에서 플래시가 현재 하고 있는 컨텐츠의 역할을 맡길때 어떤 사단이 일어나는지는 웹개발을 한다면 누구나 알고 있는 이야기라고 봅니다. 다른 기술들은 안되기 때문에 안하는거지... 그 기술이 착해서이거나 그 기술을 사용하는 개발자들이 착해서 안하는건 아니라는 거죠. 부하가 생기는 컨텐츠에 적합한 것이 플래시이고, 또, 디자이너와 개발자의 상호작용이 필수적인 작업에 있어서 플래시가 빠른 작업속도를 보장해주기 때문에 사용되어지는 것이죠. 같은 개발 목표를 HTML, javascript 를 사용해서 만들때와 플래시로 만들때는 성능의 튜닝과 불가능한 작업 리소스에 대한 포기 등을 고려했을때 플래시가 월등한 입장이기도 합니다... (적어도 3d 를 VGA 의 도움없이 비트맵 픽셀 작업만을 통해 에뮬레이션 할 정도의 성능이 있다는 것은 모두가 알아야 하는 문제이죠.) 그리고, 마우스오버의 경우 역시 호버링을 통한 뎁스의 제거를 위해서 자바스크립트가 사용된 UI 들에도 동일하게 적용되는 문제입니다. 비단 플래시에만 적용되는 것이 아니라 설계에 대한 문제이죠. 다만, 플래시에 이 문제가 빈번한 것은 "플래시까지 써서 만드는 것인데 HTML 의 버튼과 별반 차이 없으면 안된다는" 투자 대비 가치에 대한 문제였죠. 이 문제는 말 그대로 노가다 말고는 대안이 없죠. 하지만, 해결될 수 없는 문제는 아닙니다. 기술의 문제가 아니라 설계의 문제니깐요. 잡스가 이야기하는 "어도비가 게으르다." 라는 것에도 동의할 수는 없습니다. 이 문제를 이야기하자면 플래시가 웹에서 포지션된 상황 자체를 먼저 이야기해야 하는데... 플래시가 단순한 애니메이션, 인터렉티브의 구현체에서 지금처럼 거대 어플리케이션 개발도구로 까지 발전하게 된 것은 PC OS 의 어플리케이션 배포체계 문제가 있었습니다. 서비스 제공자 입장에서는 웹페이지처럼 지루한 도구 대신에 자사의 서비스를 보다 제대로 활용할 수 있는 도구를 배포해야 하는데, 이걸 어플리케이션으로 만들었을 때는 제작의 어려움이나 멋드러진 디자인 따위는 제쳐두고라도 배포체계 자체가 문제가 되었죠. 아이폰이 현재 플래시를 거절 할 수 있는 이유는 앱스토어라는 일관되고 단순화된 어플리케이션 배포 마켓이 있기 때문이지, 그렇지 않았다면 PC OS 들과 마찬가지로 웹브라우저를 실행시키기 위한 중간 파이프라인으로 전락할 가능성이 높았을겁니다. 플래시가 발전할 수 있었던 이유가 PC 의 어플리케이션 배포의 문제였기 때문에 플래시에 요구되는 것 역시도 상당한 과부하를 일으키면서 진행이 되었습니다. 업계의 주요화두가 1~2년 만에 완전히 뒤집어 엎어질 정도로 빠르게 (혹은 사람이 진이 빠질정도로) 발전하는 개발영역은 지난 10년간 흔치 않았죠. 그만큼 플래시에 대한 발전상황은 "최적화" 보다는 "기능 확장" 에 맞춰져 있었습니다. 결코, 잡스가 "게으르다" 따위의 이야기할 수 없을 정도로 플래시의 발전 상황과 그 발전을 뒷받침 하기 위해 진행된 수많은 백그라운드 작업들이 적지 않았죠. 보통 2~3년 주기를 가지던 어도비 제품군의 업데이트가 최근 1~2년 으로 줄어든 것 역시 플래시에 대한 기능 확장과 맞물려 있는 영역이 많습니다. 직접적이지는 않아도 각 제품군들이 인터렉티브 미디어 제작에 대한 워크플로우를 개선하기 위해 변경되고 재조립 되는 과정의 변화가 상당히 주요했죠. 제대로 만들었을때 플래시가 보여주는 퍼포먼스는 상당히 뛰어납니다. 하지만, 이런 발전의 역사를 봤을때 개발자들이 컨텐츠를 제대로 만들기 보다는 새로운 가능성에 목을 매어서 컨텐츠의 퍼포먼스가 저질화 되고, 그 저질화를 뒷받침 해줄 정도로 플래시의 퍼포먼스가 뛰어나다는 것 역시 현재의 상황을 만드는데 주요한 역할을 했죠. 정확히 이야기해서 플래시의 문제라기 보다는 플래시를 둘러싼 개발자나 디자이너, 시장상황등이 문제라고 보는 편이 옳습니다. 그리고, 플래시에 요구하는 클라이언트들의 요구사항 자체도 과부하를 만들어낼 수 밖에 없을 정도로 컸구요. (실제 일을 하다보면 알 수 있는건데, 거의 대부분이 웹페이지에서는 안되는 마법같은 일들이 플래시에서는 다 된다고 생각하거든요... 언젠가 한번은 PS3 에 돌아가는 소프트처럼 만들어달라는 이야기도 들었었죠...) canvas 를 통해 Flash 를 대체하겠다는 이야기 역시 맞지는 않습니다. 저도 canvas 와 javascript 를 통해서 개발을 하고는 있지만... ㅡ ㄴ ㅡ;;; Flash 를 대체할만큼 기능이나 성능이 뛰어나지는 않습니다. PC OS 에서 돌아가는 어플리케이션의 대체와 인터렉티브 미디어 라는 거대한 요구를 비롯해서 자잘한 요구들까지 플래시에 주어지던 목표치를 해결하기 위해 발전해온 10년의 세월을 따라잡기에는 확실한 무리가 있죠... 더군다나 HTML5 가 각 업체들의 이해관계에 따라 표류하고 있는 상황에서는 더더욱이 어려운 문제입니다. canvas 라는 것을 Flash 에 대응해서 이야기하지만 canvas 와 Flash 는 상호간에 목표로 하는 것 자체가 틀리다고 할 정도로 그 역할이 상당히 틀립니다. 그리고, canvas 가 Flash 처럼 되는게 웹의 전반적인 성능개선에 도움이 되지도 않구요. (플래시가 놀고 먹어서 성능이 나쁘게 나왔을리가 없잖아요... canvas 가 Flash 를 대체하면 오히려 더 끔찍한 상황이 될겁니다.) 둘 다 하는 입장에서 이야기하자면 HTML5 가 좋은 명문대 나와서 잘난척 하는 애송이 같은 느낌이라면, 플래시는 좀 능글능글 불법도 잘 저지르는 베테랑 같은 느낌입니다. 이상적으로야 HTML5 가 멋져 보이지만, 현실적으로 사용될 수 있는 문제에 있어서는 플래시가 압도적이고, 결코 쉽사리 따라오기 힘든 포스를 지니고 있다고 봐야겠죠... 그렇다고 플래시를 옹호할 수만은 없는 상황이기도 하죠. 플래시 라는 것 자체가 PC OS 의 "오류" 를 바탕으로 자라난 이독제독의 케이스라는 것을 생각하면, 새 부대를 필요로 하는 술인 모바일에는 어울리지 않는 면이 많으니깐요. 정확히 이야기해서 플래시가 없어져야 한다기 보다는 "웹페이지가 어플리케이션처럼 활약해야 하는" 시장의 문제점을 없애기 위해, "어플리케이션 배포의 문제를 해결해서 웹페이지 url 을 통해 웹 어플리케이션을 활용하게 되는 속도와 어플리케이션을 다운받고 설치해서 활용하게 되는 속도" 의 갭을 없앨 수 있어야 플래시에 주어진 "역할" 자체가 소멸될 수 있을겁니다. 그리고, 플래시가 주요하게 악평을 받는 광고 역시도 웹이 가진 비지니스 모델의 부재가 해결되지 않는 이상 아무리 기술이 바뀌어도 짜증은 여전할 거구요. 전 왜 애플이 앱스토어 같은 공용화된 어플리케이션 배포 체계를 Mac OS 에 넣지 않는지가 이해가 안되더군요... PC OS 에서 돌아가는 어플리케이션들이 컴퓨터에 익숙하지 않는 비전문 계층에게 적극적으로 활용되지 않는 이유에 대해서 충분히 인지하고 있다고 보는데 말이죠... 사실 애플이 이야기하는 HTML5 는 현재 표류중이라고 하는게 옳을 정도로 개판인 상황입니다. 결코 내일 당장 쓸 수 있는 녀석이 되지는 않죠. 그 반면에 PC OS 의 오류를 바탕으로 자라난 플래시가 성격 개선을 하는데도 충분한 시간이 필요하죠. 어짜피 둘 다 시간이 필요한 상황이고... 장점과 단점이 상호 보완되어야 하는 입장이라고 볼 수 있을 것 같습니다. 개인적으로는 웹용 플래시 보다는 AIR 가 모바일 시장에서 가지는 가치에 대해서 관심이 많습니다. 웹페이지는 그냥 "웹문서" 이면 될 뿐이지 어플리케이션일 필요는 없으므로 Flash 고 AJAX 고 나발이고 다 때려치는게 좋고, 어플리케이션 배포 체계가 좀 더 정상적이 되면 된다는 입장이거든요. 현재는 아이폰이 "완전한 시장장악" 이라고 볼 수 있을 정도니깐 그렇지, 안드로이드와 윈도우모바일7이 활성화 된다면 "개발하기 아주 쉽고, 모든 플랫폼에서 정상적으로 작동하고, 자바보다 스타일리쉬하기에 감성적으로 접근할 수 있는" AIR 와 같은 녀석이 필요해질 거라고 봅니다. 현재 앱스토어에서도 분명 "이따위걸 구지 빡세게 Objective-C" 까지 써가면서 만들어야 하나... 싶은게 많죠. 네이티브 어플리케이션에 필요없는 라이트한 어플리케이션에 대한 필요성에 AIR 가 상당히 필요하다고 봅니다. 물론... 매년 개발자들에게 10만원씩 거둬들이는 조공이 없어지기에 애플에게 곤란한 일이 되겠지만요... 이건 뭐 돈을 안내면 테스트도 할 수가 없으니... 그냥 이런저런 이야기를 했지만... 요새 "제가 좀 힘들어요. 애플, 어도비 이새키들아 좀 제대로 해..." 라는 이야기가 나올 뿐이죠. 그냥 아주 죽겠습니다. 뭐 플랫폼이 탄탄해야 개발을 할텐데, 요새 모바일이 등장하면서 개발 플랫폼이 아주 전국시대가 되어버린 상황이라...

2010-02-23, 08:02 PM	#13
ssen Member Registered: Jun 2009 My Mac: mac pro, macbook pro, iphone Posts: 86 오프라인	@trexx 일단 저 역시 HTML 컨텐츠 내부의 메뉴바 등이 단순히 아름다움만을 위해서 플래시로 사용되는 것에는 반대하는 입장입니다. 플래시에 관련된 API 들이 존재하긴 하지만, 장애인 등을 고려하고, 포괄적인 웹접근성을 필요로 하는 상황에서는 옳지 못하죠. 그런 문제들을 인식하고 저 역시 사안에 따라 플래시 사용을 자제할 것을 권고하는 편입니다. (b, u 와 같은 스타일태그 보다는 strong, dfn 과 같은 시각장애인이 접근할 경우 유용한 태그를 권고 하기도 하죠.) 하지만, 플래시가 오남용 되는 사안들을 두고 "필요없다" 라고 단정짓기 보다는 관련된 기술이 가지는 본질적인 의미에 대해서 생각하는 것이 좀 더 옳은 방법이지 않을까 싶습니다. 그리고, 기술이 바른 자리를 차지하도록 이끄는 것이 좀 더 좋겠지요. 플래시의 경우 현재 오남용 되고 있는 메뉴바나 배너 같은 것 보다는 "interactive media" 에 긍정적인 영향을 미친다고 볼 수 있습니다. 원래 시작 자체가 이 interactive media 를 목표로 설계되었는데, 어느 순간 웹어플리케이션의 필요성 증대나 html 이 가지는 아름다움의 부재, 크로스 브라우징이 불가능하다는 문제등 때문에 오남용 되기 시작된 경향이 높죠. 말씀하시는 것처럼 "단순하고 내가 원하는 정보만을 보길 원하는" 사람들만이 웹을 사용하는 것은 아닙니다. 사용자들의 대부분이 홈페이지에 빼곡하게 들어찬 텍스트를 보는 순간 뒤로가기를 눌러버리는 경향을 보이는 것 역시 사실이구요. 사용자들에게 컨텐츠를 흡수시키기 위해서 노력하는 이들에게 interactive media 기술은 필수적이죠. 이미 관련 업계 (기존 방송 미디어 등을 제작하던 업계) 의 경우 이 interactive media 등을 주요한 화두로 설정하고 있습니다. 그런 "기존 미디어가 가지는 표현의 흡수력을 보장하면서, 동시에 대화형 타임라인을 가짐으로서 사용자에게 내용을 보다 정화히 전달하길 원하는" 업계와 그 수요자들이 원하는 것을 보장해주는 기술은 현재 플래시 말고는 존재하지 않는다고 하는 편이 옳습니다. 대안체로서 canvas 를 이야기하지만, canvas 의 내부 api 가 보장하는 기술은 이에 크게 미치지 못하고 (그래서 차트와 같은 data visualization 에 특화되었지, flash 와 같이 interactive media 에 특화된 것은 아니라고 글에서 설명했던 것입니다.) 가장 큰 중요성으로 canvas 에 접근할 수 있는 작업 도구 자체가 존재하지 않습니다. 쉽게 설명해서 해당하는 컨텐츠를 제작하는데 대안인 canvas 를 사용하라는 것은, 웹개발자들에게 "왜? html 이 필요한데, 그냥 c 로 프리젠테이션 단까지 개발하면 안돼?" 라고 이야기 하는 것과 비슷한 이야기가 됩니다. 그리고, 말씀하신 인터넷의 데이터 수집이 SNS 등으로 옮겨가고 있다는 이야기는 플래시와 같은 컨텐츠, 즉 내용의 도착점에는 어울리지 않는 이야기 입니다. 트위터를 통한 정보의 유통을 보아도 대부분이 "알림" 이라는 경로의 역할을 하지, 그 자체가 도착점인 "내용" 이 되지는 않습니다. SNS 를 통한 정보 유통은 기존 검색과 같이 "내가 도착점에 대해 인지를 해야 컨텐츠를 얻을 수 있는" 난제를 해결하는 "내가 (팔로잉을 통해) 관심있게 경청하는 이에게서 발생하는 정보의 알림" 이라는 경향이 높습니다. 어떻게 보면 RSS 와 같은 경향이 높다고 볼 수 있죠. 기존 컨텐츠 접근에 대해 보완체적인 역할을 하는것이지 "대체재" 로서 작용하지는 않습니다. 그렇기에 trexx 님이 말씀하시는 웹페이지, 웹사이트의 효용성에 대한 의문은 저는 다르게 생각합니다. SNS 의 "알림, 대화" 와 같이 정보 접근 방식의 다양화로 기존에 웹사이트가 가지던 기능들이 다른 유통체계로 일부 전환되긴 해도, 이것은 "역할의 재분배, 역할의 효율화, 역할의 보완" 에 가깝지, 웹페이지 컨텐츠 자체의 의미 상실을 이야기 하지는 않을 것입니다. 제 생각과 trexx 님이 생각하는 것 중에서 동일한 부분은 플래시가 메뉴바 등으로 오남용 되는 것에 반대한다는 것이고, 플래시가 필요하냐? 라는 의문에 대해서 반대하는 입장은 컨텐츠라는 것이 꼭 text, image, video 만을 통해 전달되는 시기가 이미 지나갔다는 것입니다. 많은 컨텐츠들이 목표로 하는것이 일방적인 주입형에서 이미 대화형인 interactive media 를 목표로 하는 상황에서 플래시와 같이 그런 컨텐츠형을 대표하는 기술 자체가 사라져야 옳다고 이야기 하는 것은 "수요" 에 대한 대체를 찾지 못한 상태에서 수요 자체를 없애는 것이 옳다고 이야기 하는 것과 마찬가지가 됩니다. 입장을 달리해서 trexx 님이 "고가의 자동차를 보다 품위있게 보여주면서, 동시에 text 나 image, video 의 나열과 같은 사용자가 쉽사리 포기해버릴 수 있는 정보 제공 방식이 아닌 게임과 같은 형식으로 사용자에게 이 제품의 중요성을 알리고자 한다면" trexx 님은 어떤 기술을 선택하시겠습니까? 플래시가 집중적인 화두가 되는 이유는 꼭 애플과 어도비의 정치적 싸움이나 단순한 기술적 오남용의 해소를 위해서만은 아닙니다. IT 적인 시선을 벗어나면 플래시라는 현재로서 대체 불가능한 기술이 "소멸" 되는 것에 대해 불편함을 느끼는 비 IT 업계의 이해관계가 오히려 더 크다고 볼 수 있죠. (위에서도 이야기했지만 관련한 컨텐츠를 만드는데 flash 를 사용하지 말라는 것은 html 없이 c 로 웹페이지 프리젠테이션을 렌더링 하라는 말과도 비슷할 정도로 일방적인 폭력성을 가지고 있습니다.) 모든 것이 웹표준이 제공하는 기술만으로 해결될 수 있다면 플러그인 기술 자체가 재평가 받아야 하겠죠. 하지만, 플러그인 기술이 필요한 이유는 웹표준이라는 가장 기본적이고 스탠다드한 기술이 제공할 수 없는, 그리고, 그렇게까지 표준이 방대해지고 난잡해져서는 안된다는 문제를 해결하기 위해서라고 봅니다. 기술에 대한 평가를 하는데 주관적이고 개인적인 입장만을 이유로 들면 안된다고 봅니다. interactive media 적 기술을 필요로 하는 업계는 어린아이들과 같이 text, image 정보를 흡수하기 어려운 대상을 상대로 하기에 게임의 형식을 만들기 원하는 업계도 있고, 공들인 제품에 대한 정보를 사용자가 그냥 대충 훌터보기를 원하지 않기에 보다 흡수력이 강한 컨텐츠 형식을 원하는 업계도 있습니다. 그리고, 그런 업계의 컨텐츠들 중에서는 "앱" 을 설치하는 것이 아닌 일회성 정보로서 작동해야 하기에 웹 자체의 표현능력이 강해야만 하는 업계도 많습니다. 일방적인 평가를 내릴수만은 없는 이야기이죠. 플래시에 대한 의미가 다시 재평가 되는것은 제 입장에서는 즐거운 이야기이기도 합니다. 플래시와 같은 컨텐츠를 제작하는 입장에서 "남용" 에 가깝게 사용되는 것은 분명 즐겁지 않은 일이니깐요. 하지만, "남용, 오용" 을 없애는 것에 대해 긍정적인 입장을 가지는 것과 반대로, 현재처럼 "긍정성" 마저 소멸시키려고 하는 것은 옳지 못한 이야기이기도 합니다. 그런것은 "삐뚫어질 수 있기에 자유를 제한하는 것이 옳다." 라는 폭력적 사고와 비슷하죠. 제 생각은 기술이 남용되는 부분을 제거해나가는 것이 옳지, 아예 그 기술의 수요와 공급 자체를 소멸시키려는 생각은 옳지 못하다는 것입니다. 도구라는 것은 사용자의 문제이지, 도구 자체가 없어질 문제는 아니지 않을까요? 많은 부분 웹표준을 중점으로 해서 발전해야 하는 부분들은 웹표준화 되고, interactive media 와 같이 현재로서는 대안을 찾기 어려운 부분에 대해서는 기술이 "긍정적" 으로 활용되어 갔으면 하는 바램이 있습니다. 그것이 보다 올바른 판단이지 않을까 싶구요. 그래서, 사용자들이 "플래시 광고 짜증나! 플래시 없어졌으면 좋겠어!" 라는 것은 그렇다치지만, 보다 원론적으로 생각해야 하는 기술자들의 경우에는 "기술의 올바른 활용과 그 대체" 에 대해서도 고민을 하면서 이야기를 나눴으면 하는 바램이 있습니다. interactive media 업계에도 몸을 담고 있는 저로서는 기술자들 마저 일방적인 시각만을 가지고 단순한 증오의 토론을 하는 것은 좀 거시기 하다는 느낌이 듭니다. 분명 다른 업계, 수요자들을 포용하는 시각을 가지면 플래시의 필요성에 대해서 단순하게만은 평가를 내리시기 어렵다고 봅니다. trexx 님도 제가 이야기한 업계와 수요자에 대해 한 번 생각하시면 좀 더 긍정적으로 검토해야 옳은게 아닌가 하는 생각을 하시게 될겁니다. 그리고, 추가적으로 이야기하고 싶은 것은... 말씀하신 플래시를 빼니 화면이 참 정갈해졌다는 이야기는 제가 이야기한 "광고" 에 대한 차악적 선택에 있습니다. 광고는 원래가 컨텐츠보다 집중받기 위해서 강제적으로 집중을 요구하는 형태로 제공됩니다. 플래시 광고를 차단해서 편하다고 이야기 한다면, 광고를 만드는 입장에서는 모바일이라면 최상단에 커다랗게 이미지를 배치해서 일단 광고를 보면서 스크롤을 내리도록 배치할 수도 있고, 기술적으로 좀 귀찮음이 있긴 하겠지만 (오히려 저같이 개발과 미디어 제작을 동시에 하는 입장에서는 경쟁력이 생기기에 오히려 반가운) 형태로 플래시를 자바스크립트를 사용해서 동일하게 구현할 수도 있습니다. 말씀하신 부분은 플래시가 사용자에게 불편한 형태로 사용되는 것인데, 이것은 제 원 글에서도 이야기했듯 비지니스 모델의 문제지, 플래시 자체가 가지는 문제는 아닙니다. 광고는 원래가 그렇게 사용되기 위해 만들어졌다는 것이죠. 사용자가 원하는 컨텐츠를 찾아가는 중간에 개입해서 "날 보세요" 라고 만들어지기 때문이지, 플래시가 문제가 되는 것은 아닙니다. 그 자리를 대체할 기술이나 전략적 방식은 얼마든지 있죠... 그렇다고 포털 사이트들이 모두 구글과 같은 비지니스 모델을 가져야만 하거나, 유료로 서비스를 제공해야 한다고 한다면 모든이들이 고개를 절래절래 흔들 것 아닐까 싶네요.

2010-02-23, 11:40 PM	#14
trexx Senior Member Registered: Nov 2001 My Mac: MacBookPro 1st 2.0 Core Duo 15inch(2006), iMac 2.4 24inch (2007), Macbook Air 2nd 1.6 SSD 128GB (2008), iMac i7 2.93 27inch(2010), iPod 4th 40GB(2005), iPod 5th Black 30GB(2006), iPod nano 2nd RED 8GB(2006), iPhone 4 32GB(2010), iPad 1st 32GB(2010) Posts: 218 오프라인	@ssen ^^ 네 ssen 님께서 말씀하신 내용에 대해 어느정도 긍정합니다. 통찰력 있는 글 감사합니다. interactive media에 대한 고찰에 대해서 전공하는 입장에서 상당부문 옳다고 생각하고 있습니다. 하지만 우리가 생각하는 interactive media에 대한 근본적인 생각을 해 볼 필요가 있지 않을까 싶습니다. 그 전에 앞서 제가 플래시를 부정적으로 생각하게 된 이유 중 하나에 대해 먼저 언급하겠습니다. 플래시가 좋은 기술이건 아니건 간에 플래시가 사장되어야 한다는 입장에 있게 된 것이 adobe의 욕심때문입니다. 어도브는 인터넷이라는 광야에서 본인의 기술에 대한 독점적 지위를 내세웠기 때문입니다. 그래서 plug-in 으로 구동하게 만들었고 결국 웹엔진에 포함 시킬 수 없는 기술이 되었습니다. 자바스크립트 또한 동일한 길을 갈 수 있었지만 (네스케이프의 지배력이 떨어져서 나온 결과지만) 웹엔진 안으로 들어와서 지금의 구글의 시장력과 애플의 기술(webkit)의 기반이 될 수 있었습니다. 플래시의 길은 어땠나요? 어도브는 스티브 잡스 말따라 너무 게을렀습니다. 플래시가 독점적 지위에 올라서자 윈도우 환경 말고는 플래시 기능개선을 거의 하지 않았습니다. 사실 제가 어도브 입장에 있더라도 기술 공개 결정을 쉽게 하지 못했을 겁니다. 하지만 작은 사이트들이 플래시를 이용해서 간편하게 웹페이지를 제작할때 구글 및 애플 등 웹을 선도하는 업체들은 왜 플래시를 배척하게 되었었까요? 왜 지금 어도브 플래시에서 선도기업들이 멀어져 가고 있을까요? 기술 공개를 해서 플러그인 형태가 아니라 웹엔진에 넣을 수 있었더라면 하고 생각해 봅니다. 자바스크립트! 그리 좋은 기술이 아닐 수도 있었습니다. 수많은 팝업으로 명예가 더렵혔었고 코드 남용으로 사이트를 병들게 했었습니다. 하지만 웹엔진에 안착시키고 W3C DOM으로 CSS 같이 정돈시킬 수 있는 분위기가 되자 엄청난 파괴력을 가진 기술이 되었습니다. 음.. 이제 본 주제에 대해 생각해 보겠습니다. interactive media에 대하여 전 여전히 환상이 있다고 생각합니다. 15년전에 빌게이츠가 강연하는 비디오가 생각났는데요. 당시 빌게이츠는 인터넷의 미래를 비관하고 있었습니다. 그래서 당시는 TV 등 기존의 가전 제품에서 네트워크를 통한 인터렉트 미디어를 구현하는 모습을 시현 했었지요.(물론 현재도 이 기술은 아직 도전하고 있지요.) 근데 빌게이츠 예상은 완전히 벗어났습니다. 허접하지만 텍스트와 이미지가 하이퍼 링크를 만나자 수요는 폭발적으로 변했습니다. 하이퍼링크! 비약이지만 이 별거 없는 기술이 인터넷 혁명이 단초가 되었습니다. 모든 문서는 연결될 수 있다는 그 혁신성! 흔히들 말하는 interact media에서 사용자가 추구했고 채택했던 것은 무엇일까요? 아무리 플래시에서 많은 기술이 된다고 하지만 실제로 우리의 선택은 공짜 미디어는 유튜브에서 고품질 미디어는 itunes 등 에서 구매하게 되었습니다. 사람들은 미디어에서 원하는 것이 영상통화 등 과 같은 어색한 쌍방향이 아니라 정보 습득은 wikipedia 같은 형태의 텍스트(그림)으로 영상, 음악 등 즐기는 쪽은 거의 일방향(유튜브, 아이튠즈)으로 포지션이 되어있고 이것은 쉽게 바뀌질 않을 것 같습니다. 지금까지 디자이너가 말하는 인터랙트 디자인은 어쩌면 기술 중독자들이 쉽게 빠지는 함정이 아닐까 싶습니다. (자주는 쓰일 수 없는 기술) 가장 단순한 욕구인 보고 즐기고 이해하고가 벗어나면 사용자들은 뭘 어떻게 해야할지 모릅니다. 결론은 컨텐츠라는 이야기 입니다. 아무리 인터랙트 미디어를 구현할 수 있다고 하여도 컨텐츠에 대한 면밀한 이해가 없다면 미디어는 죽은 것입니다. 또한 말씀하신 것 처럼 SNS가 관문 역할을 한다는 데 동의합니다. 하지만 그 링크를 따라가다 보면 인터랙트한 홈페이지와 연결되는 것이 아닌 보다 깊은 사유의 장(블러그 등)으로 연결된다는 것이 중요합니다. 즉 SNS에서 의문의 주제를 발견하고 링크된 글에서 더 깊은 사유를 할 수 있다는 것입니다. 전 트위터의 등장으로 블로그의 시대가 끝난 것이 아니라 오히려 확장 되었다고 생각합니다. 트위터를 통해 사유의 장을 더 활용하는 것이지요. 플래시가 일반인이 경험하는 인터렉트 미디어라는 것이 무엇일까요? 1. 영상(오늘 김연아 다들 보셨지요?^^) 2. 다채로운 효과로 연결된 미디어 3. 기타 등등 제가 많은 홈페이지를 가 보진 못했지만 솔직히 연예인 내지 영화 광고 등 플래시로 구동하는 사이트를 가서 보면 일회성에 그칠때가 많습니다. 정보의 가치는 일회성이 아니라 이용 가능성이 높아야합니다. 즉, 어떤 형태가 되었건 연결될 수 있어야 한다는 것이지요. 이것이 제가 생각하는 인터랙트입니다. 즉 컨텐츠 활용의 확대입니다. 컨텐츠를 활용할 수 있는 1차 미디어인 원 데이터 영화, 음악, 뉴스 등등에서 파생된 것이 제일 중요하고 이를 보다 완성된 형태로 인터랙트하는 것은 부차적인 것입니다. 플래시는 글세요. 제가 볼때 파생된 부분에 너무 많은 기술을 사용했다는 것입니다. 아이팟의 성공에 대한 다큐멘터리에 좋은 언급이 있었습니다. '아이팟이 성공한 배경에는 인간의 욕망이 담겨있다.' 즉 음악을 듣는 것은 컴퓨터를 하는 것과 달리 욕망에 가깝다는 것이지요. 컨텐츠는 인간의 본질적인 모습 욕망에 해당되지 않을까 합니다. 즉, 인터랙트에 인간에 대한 고찰이 플래시의 기술중에 어느것에 해당되는지 꼭 필요는 있는지에 대한 고민이 있어야 하지 않을까요? 음... 전 애플이 iTunes LP와 extras 를 보면서 인터렉트 미디어에 대한 새로운 방향을 제시했다고 봅니다. 이 기술은 현재 아이튠즈에 머물러 있지만 사실 이 것은 Webkit 기술로 기술공개가 되어 있기에 다른 누군가가 컨텐츠를 활용하는데 적극적으로 쓸 수 있습니다. 그리고 덧붙여 보고 즐기는 인간의 근본적인 욕망에 대한 고찰이 있다고 봅니다. 그래서 전 webkit이 플래시 기술에 많이 접근하길 기대하고 있습니다. ssen님의 통찰력있는 좋은 글 감사합니다. 아참.. 광고에 대해서.. 네 맞는 말씀입니다... 하지만 돌이켜 생각해 보면 플래시가 그런 광고에 자주 쓰였다는 것도 오명의 원인이 되어 플래시는 광고에 주로 쓰인다는 선입관을 심어 놓게 되었지요. 근데 유독 우리나라 사이트 들만 그런 것도 문제입니다. trexx 님께서 2010-02-23 11:55 PM 에 수정하셨습니다..

2010-02-24, 02:53 AM	#15
djhan Veteran Member Registered: Oct 2001 My Mac: Powermac G4 MDD 1.25 DP Posts: 949 오프라인	업체 입장에서 보면 어도비는 게을러 터진 사기꾼 색희들입니다. 4년 전부터 어도비는 모바일용 플래쉬 라이트가 데스크탑용 플래쉬와 통합될 것이며, 하드웨어 가속까지 지원해서 퍼포먼스를 극적으로 향상시킬 거라고 떠들면서 여기저기 라이센스를 팔고 다녔죠. 그리하여 많은 휴대폰(피쳐폰)과 PMP, MP4 등이 플래쉬 라이트로 GUI를 만들게 됐는데.... 그러나 그렇게 오랜 세월이 지났건만, 1) 라이트는 여전히 라이트일 뿐이고 2) 하드웨어 가속은 시궁창에 처박힌 지 오래일 뿐입니다. 그리고 많은 휴대폰과 PMP, MP4의 CPU 빠우어가 플래쉬로 구현된 GUI 애니메이션을 그리는 데 낭비되었죠. 참다 못한 업체들은 차례로 플래쉬를 버리고 다른 호환 엔진으로 갈아타 버렸죠, 뭐. 제가 보기엔 어도비, 게을러 터진 놈들 맞습니다. 개발 툴을 업그레이드해서 포토샵과 함께 팔아먹는 데 혈안이 된 놈들이죠. 이건 조공 수준이 아니라 강탈입니다, 강탈. 열혈 플래쉬 개발자들은 애플이 flex로 개발된 앱들이 개방된 앱스토어를 통해 시장을 장악할 것을 염려해 플래쉬를 올려주지 않는다고 주장하지만, 이건 완전 헛소립니다. 지금 플래쉬로 개발된 어플리케이션 중에서 돈벌이가 되는 거라곤 일본 코믹 마켓에서 팔리는 포르노 야게임 정도밖에 없을 텐데....... 뭐, 이것도 어떤 의미론 염려가 되긴 하겠군요, 흥. 웹사이트에서의 플래쉬 오남용에 관해선 이미 1년여 전에 일본 웹진 컬럼에서도 깐 적이 있으니 한 번 참고해 보시기 바랍니다. 아래는 그 컬럼의 번역 링크입니다. Flash는 어째서 미움받는가? (번역) __________________ - 사랑과 평화와 정의의 DJ.HAN - 블로그: DJ's Paradise djhan 님께서 2010-02-24 03:55 AM 에 수정하셨습니다..