Flex 에반젤리스트 제임스워드_How I Overcame My Fear of Flash
제임스워드
여러분들 중에도, Flash가 주는 효과가 과도하다고 생각되고 팝업, 팝오버, 건너뛰기 인트로 등에 짜증을 느껴본 적이 있나요? Flex Technical Evangelist인 James Ward는 Flex의 매력을 느낀 후에도 Flash에 대한 편견 때문에 자칫 Flex를 멀리할 뻔 했다고 합니다. James Ward의 동의 하에, 그가 자신의 블로그에 작성한 글을 번역해 소개합니다.
처음 본 Flash 사이트를 아직도 잊을 수가 없다.
지루한 네비게이션은 빠르게 회전하는 모양으로 대체되었고 사운드가 이전의 침묵하던 웹에 생명을 불어 넣고 있었다. 며칠 동안 Flash Professional로 이것 저것 시도해 봤지만 내 수학적 성향의 머리로는 Flash 웹과 같은 예쁘고 아기자기한 웹을 만들 수 없다는 결론을 내렸다.
시간이 지나 ‘쿨하다’고 생각하던 Flash에 대한 생각도 바뀌어 Flash 웹에 들어가면 맨 처음 표시되는 "건너뛰기" 페이지가 짜증나기 시작했다. 또 점점 커져 가던 자유에 대한 갈망으로 운영 체제를 리눅스로 전환한 이후에는 Flash 사이트 제작 방법을 배우고자 하는 열망도 이내 사라져 버렸다. Flash로 만든 간단한 웹 양식을 처음 보고 "누가 이런 유형의 애플리케이션을 Flash로 만들겠느냐?"고 웃었던 기억이 있다.
2005년으로 돌아가, 필자가 몸담고 있던 직장의 상사는 기업 마케팅 웹 사이트를 정적인 인쇄용 브로셔가 아니라 Hildago 영화 사이트처럼 신선한 웹 사이트로 만들고 싶어하던 매우 창의적인 사람이었다. 그녀가 Flex 설명회에 참석한 다음 날 아침 해답을 찾았다면서 한 말이 바로 "Flex를 이용해 구축하자!"라는 것이었다. 나는 도대체 Flex라는 게 뭐냐고 되물었다. 그래서 우선 시험버전을 다운로드하여 사용해 보기 시작했다.
HTML에서는 몇 주 걸리던 작업이 한 시간도 걸리지 않아 백 엔드 데이터를 추출하여 데이터 그리드에서 이 데이터를 표시할 수 있게 되었고, 며칠이 지나서는 구축하기 시작한 포탈의 POC를 다 완료할 수 있었다. 필자는 Flex를 익힌 속도와 시각적으로 돋보이는 기능적인 사이트를 구축할 수 있었다는 사실에 깊은 인상을 받았다. Flex에 이내 매료되었지만 Flash를 사용하는 데 대한 두려움은 여전히 가시지 않았다.
그러면 지금부터 어떻게 Flash에 대한 두려움을 극복하고 Flash/Flex 세계에 '올인'하여 결국 Flex의 추종자가 되었는지를 설명해보겠다. 이야기를 시작하기 전에 다음에 설명하는 것은 Flash나 Flex를 사용해야 하는 당위성에 대한 논쟁이 아니라는 점을 밝혀두고 싶다. 또 다음에 열거된 내용은 독자의 활용 사례에 적용될 수도, 적용되지 않을 수도 있는 필자만의 독특한 활용 사례라고 할 수 있다.
두려움 #1: Flash는 독점 제품이다.
소스부터 시작하여 거의 모든 것을 시스템에 컴파일하는 리눅스 마니아에게 있어서는 독점 제품이라는 사실이야 말로 Flash를 플랫폼으로 채택하는 데 가장 큰 저해 요인이라고 할 수 있다. 크게 세 가지 의구심이 있었는데, 하나는 어도비 소프트웨어 없이도 Flash 컨텐츠를 분해할 수 있을까? 두번째는 어도비 소프트웨어 없이도 Flash 컨텐츠를 작성할 수 있을 것인가? 그리고 마지막으로 Flash 플랫폼의 혁신과 방향이 얼마나 긴밀하게 조율되고 있는가? 이다.
Flash 컨텐츠를 분해하는 측면에서 볼 때 SWF(Flash 바이트 코드) 파일 사양이 공개되고 적어도 세 가지 오픈소스 Flash 브라우저 플러그인이 있다는 사실을 알게 되어 매우 기뻤다. SWF 컨텐츠를 구축하는 데에 있어서는 Laszlo라는 Flex와 유사한 프레임워크를 비롯하여 여러 가지 오픈소스 프로젝트가 존재한다. 그리고 커뮤니티의 참여도에 관한 한 Flash를 비롯한 많은 매크로미디어/어도비 제품들이 Customer Advisory Boards와 일반 사용자의 피드백을 바탕으로 만들어지고 있다는 사실은 매우 반가운 일이었다.
이러한 사실만으로도 필자의 두려움 #1을 극복하기에 충분했다. Flash가 오픈 소스가 아니라고 해도 괜찮은 이유는 어도비가 바람직한 방향으로 나아갈 것이라는 데에 대한 믿음이 있고 결국 Flash가 오픈 소스가 될 것이라는 데에 대한 믿음이 있기 때문이다.
두려움 #2: Flash는 짜증을 불러 일으킨다.
두말할 나위 없이 Flash의 강력한 성능이 남용되고 있다. 팝업, 팝오버, 건너뛰기 인트로 등 짜증나는 광고는 컴퓨터 화면 전체를 장식하고 있다. 남용으로 종교를 판단하지 말라는 말을 들은 적이 있다. 이와 같은 격언은 기술에도 예외는 아니다. 사람들이 Flash를 짜증나는 곳에 사용한다고 해서 피해서는 안 된다. 스팸머가 이메일을 남발한다고 해서 이메일을 피하지 않는 것처럼 말이다.
이러한 남용을 해결할 수 있는 창의적인 방법을 찾아야 한다. 필자는 개인적으로 이메일 RBL과 같이 커뮤니티의 주도 하에 Flash 및 DHTML 남용 블랙리스트가 만들어지기를 바란다. 기술이 유용하면 할수록 그 기술은 남용되기 마련이지만 그렇다고 해서 유용한 기술의 사용을 멈추어야 한다는 의미는 아닌 것이다.
두려움 #3: Flash는 인덱스 검색이 불가능하다(소위 "Web 1.0과의 통합″).
웹이 주로 문서로 구성되어 있는 경우에는 인덱스 검색 기능이 잘 작동했다. 스파이더는 URL을 잘도 기어 다니면서 존재하는 모든 문서를 얻어다 줄 수 있었다. 웹이 애플리케이션 플랫폼의 성향을 띄면서 이러한 방식은 점차 힘을 잃어가기 시작했고, 그것이 Ajax이건 Flash 또는 XUL이건 간에 애플리케이션이 상태 및 코드 실행을 클라이언트로 이양하면서 검색 엔진의 인덱스 검색 기능이 점점 어려워지고 있다.
Flex를 이용하여 필자가 구축한 사이트의 경우 인덱스 검색은 매우 중요한 문제였지만 Lynx 호환 버전의 사이트를 구축함으로써 이 문제를 해결했었다. 컨텐츠 관리 시스템에 사이트의 모든 컨텐츠가 들어있어 이 문제는 간단히 해결되었다. 그러나 여전히 해결 과제는 많이 남아 있다. 검색 엔진은 애플리케이션 인덱스 검색이 가능한 웹 서비스 인터페이스를 제작함으로써 이 부분을 혁신해야 한다고 본다. 현대 검색 엔진이 페이지의 상호 연결성에 의존하고 있어 인덱스 검색이 가능한 서로 다른 버전의 사이트를 구축하면 검색 엔진 순위가 떨어지게 된다. 그러나 Digg과 Delicious와 같은 사이트를 참조하여 새로운 "애플리케이션 인덱스"의 유용성과 무결성의 등급을 매기고 절제할 수 있는 몇 가지 방식을 찾는 것이 쉬운 방법일 것이다.
그러면 뒤로 버튼 지원은 어떤가? Flex에서 뒤로 버튼 지원은 내장되어 있고 손쉽게 맞춤형으로 만들 수 있어 결코 문제가 되지 않는다. 또한 Flex는 # URL(또는 이름이 있는 앵커)을 수행할 수 있는 간편한 방식을 제공하므로 애플리케이션 상태가 변경되면 URL도 변경된다. 또 다른 Web 1.0 통합 문제가 해결된 것이다.
두려움 #4: 매크로미디어는 리눅스 친화적이지 않다
지금까지 리눅스 릴리스를 위한 Flash Player가 윈도우 릴리스에 비해 뒷전이었던 것은 사실이며 리눅스 시스템에서 SWF를 구축할 수 있는 방법은 극소수에 불과했다. 일부 사용자의 경우 내장된 64비트 리눅스 Flash Player가 없는 것이 큰 문제가 되었다. 이러한 점들은 필자를 포함한 리눅스 사용자의 대다수가 Flash 세계에서 이류 시민으로 취급당하는 느낌을 지울 수 없게 한 주요 요인이었다.
필자가 매크로미디어에 입사하기 전 Flash Player 9 개발 계획이 준비 중이었다. 이 때 담당자와 만났을 때, 리눅스 기반의 Flash Player 9을 제공하는 것이 가장 우선 순위라는 말을 했으며, 또한 리눅스 기반에서 Flash Player 9을 이식/구축할 실력 있는 리눅스 프로그래머를 찾는 것이 과제라고 했다. 결국 윈도우 및 맥 버전이 출시된 후 몇 개월 뒤에 리눅스 기반 Flash Player 9 일반 베타 버전이 발표되었고 리눅스용 Flash Player 9이 2007년 1월 17일 공식 출시되었다. 64비트 리눅스 기반의 시스템을 보유한 사용자의 경우 nspluginwrapper를 이용하여 32비트 Flash 플러그인을 실행할 수 있다.
또한 어도비는 리눅스 사용자가 Flash 컨텐츠를 작성까지 할 수 있도록 하기 위해 노력의 고삐를 늦추지 않고 있다. 필자가 리눅스상에서 매일 사용하고 있는 무료 Flex 2 SDK와 같은 툴을 사용해 Flash의 모든 기능을 적극 활용하고 리눅스, 맥 및 윈도우상에서도 같은 방식으로 실행되는 Flash 기반의 애플리케이션을 구축할 수 있다.
두려움 #5: Flash는 브라우저 플러그인이다
브라우저 플러그인의 개념은 브라우저 자체의 매우 느린 속도를 극복하고자 하는 노력의 일환으로 채택된 것이라고 한다. 브라우저 플러그인은 HTML의 영역을 벗어나 HTTP를 통해 액세스되는 페이지에서 신기한 것들을 경험할 수 있는 기능을 웹 사용자에게 제공하고 있다. Flash는 아직까지 브라우저 내에서만 일관된 경험을 제공하고 있으며 HTML의 한계를 뛰어넘지는 못한 실정이다. 이제 전세계 PC 사용자의 98퍼센트에 달하는 PC에 Flash 6 이상 버전이 설치되어 있다.
그렇다면 브라우저 플러그인에 의존하는 데에 대한 반감은 왜 있는 것일까? 일전에, 필자가 확인한 바로는 시스템에 JavaScript가 활성화되어 있는 사용자보다 Flash가 활성화되어 있는 사용자가 훨씬 많았다. 그렇다면 JavaScript에 의존해서는 안 되는 것일까? 그러면 브라우저 호환성 문제는 어떤가? Flash와 마찬가지로 플러그인은 웹 개발자가 브라우저 간 호환성 및 OS 간 호환성 문제를 고민하지 않게 해주고 있다. 웹 개발자의 관점에서 보았을 때 세 개의 서로 다른 운영 체제와 20개 이상의 브라우저에서 테스트하는 것보다, 코드를 작성하고 디버그하고 이를 어디에서나 실행할 수 있을 때 필자는 직업적인 자긍심을 더 느낀다. 많은 이들은 프레임워크가 이러한 크로스 X(cross-X) 문제로부터 우리를 보호해주고 있다고 말한다. 필자는 이들 생각과는 다르다. 그 이유는 필자가 작성한 소프트웨어의 80%가 프레임워크이고 20%는 수동으로 작성된 코드이기 때문이다. 사람들은 결국 프레임워크 외에 수행하는 작업에 대한 호환성 문제를 해결해야 하는 상황에 처하고 만다.
Flex에 대해 한 가지 더 덧붙이자면, Flex 프로그래밍 모델은 컴포넌트가 확장 가능하고 속성, 메서드, 스타일 및 이벤트를 포함하는 컴포넌트 프레임워크로 이해되었다. 필자의 경험상 이러한 요소를 프레임워크로 캡슐화하면 Flex 프레임워크의 테두리 밖에서 처리해야 하는 경우가 거의 없다. 반면 HTML이나 Ajax 프레임워크를 사용하면 프레임워크 밖에서 더 낮은 수준의 코드로 다시 가서 작업해야 했다. 보통 처음에는 프레임워크에서 필요한 모든 것을 다 제공해준다. 그런 다음 디자이너는 프레임워크가 즉시 제공할 것 같지 않은 것을 주고 프레임워크 주변을 이리 저리 맴돌다가 경우에 따라서는 프레임워크 자체를 수정해야 하는 경우도 생긴다. 이러한 방법은 코드를 유지 관리할 수 있는 방법이 전혀 아니다. Flex를 사용하면 디자이너에게 디자이너 친화적인 툴을 이용해 디자인 요소를 만들라고 말하면 되고 그런 다음 이 디자인 요소를 스킨으로 Flex 애플리케이션에 가져오기만 하면 된다.
두려움은 모두 해소되었다.
중요한 점은 Flash Player가 유비쿼터스 크로스 브라우저, 크로스 OS 가상 머신으로 차세대 웹 경험을 구현한다는 것이다. Flex는 개발자가 Flash 가상 머신에서 실행하는 애플리케이션을 구축하기 위해 사용하는 툴에 불과하다. 대부분의 사례에서 Flex 애플리케이션은 구축 시간이 적게 들고 보다 나은 사용자 경험을 제공한다. Flex가 모든 사람을 위한 것이거나 모든 사례에 적합한 것은 아니지만 필자의 경험이 Flex 및 Flash가 독자 여러분에게 적합한 기술인지 판단하는 데 많은 도움이 되기를 바란다.
