2009년 세계천문의 해를 맞이해서 재미있는 행사를 합니다. 오는 토요일에 서울 올림픽 공원에서 천체망원경 400대를 한곳에 모아 기네스 기록에 도전한다고 합니다.
• 일 시 : 2009년 10월 31일 14:00 ~ 22:00
• 장 소 : 서울 올림픽공원 평화의 광장
• 주 최 : 국회의원 박영아, 기초기술연구회, 한국과학창의재단
• 주 관 : 한국천문연구원, 한국항공우주연구원, 2009 세계 천문의 해 한국조직위원회
• 후 원 : 교육과학기술부, 한국아마추어천문학회, 부산과학기술협의회
기네스 기록 측정 시간은 16:00~17:30으로 만약 기네스 기록 도전에 성공하면 영국 기네스월드레코드사에서 참가인증서를 발급해준답니다. wow~
천체망원경을 굳이 400대를 모으는 이유는 갈릴레이가 처음 망원경을 통해 밤하늘을 관측한지 400주년이 되는 해가 바로 올해이기 때문입니다. 참 뜻깊은 일이죠.
천체망원경이 없어도 다채로운 행사도 많이 준비되어 있기 때문에 남녀노소할 것없이 찾아오시면 재미있는 행사를 즐길 수 있을 겁니다. 꼭 놀러오세요. ^^
지난 2009년 10월 5일부터 7일까지 3일간 어도비(Adobe)에서 주최하는 컨퍼런스인 Adobe MAX 2009행사에 참여하기 위해 일주일간의 일정으로 미국 LA에 다녀왔다. ACC(Adobe Community Champion)의 구성원 중에 올해는 필자를 포함한 3명이 발탁되어 이번 행사에 행사참여비를 비롯한 모든 여행경비를 거의 전액 무료로 참여하게 되었다. Adobe MAX는 Adobe의 새로운 기술과 트렌드를 공개하는 큰 행사이다. Adobe Flash Platform에 관련된 기술에 항상 관심을 가지고 지켜본터라 이번 행사의 참여는 개인적으로 매우 즐겁고 흥미로운 경험이였다.
행사 일정은 3일이였으나 전체 미국에서의 일정은 1주일이였기 때문에 행사 일정을 제외한 나머지 시간은 LA를 둘러보는 시간도 가질 수 있었다. 개인적으로 LA에 동서댁이 살고 있어서 행사끝나고 가족상봉도 이룰 수 있어서 정말 좋은 시간이였다.
3일간 열리는 이번 Adobe MAX 2009행사는 노키아 극장에서 열리는 2번의 키노트 행사와 LA 컨벤션 센터에서 주제별 세션이 있었다. 키노트는 한 장소에서 모든 행사 참여자가 경청할 수 있으며 전체 흐름과 주제를 파악하는데 필요한 거의 모든 내용을 다룬다. 키노트 행사에는 수천명의 사람들이 참여한다. 반면 주제별 세션은 많게는 100명 적게는 30~40명 정도 들을 수 있는 방에서 자신이 원하는 세부적인 내용을 들을 수 있는 자리이다. 세션은 제품군, 주제, 난이도 등으로 나눠서 입맛에 맞게 골라 경청하거나 실험해 보는 자리로 꾸며진다.
Adobe MAX 행사 참여로 누구보다 가장 빠르게 Adobe 신기술을 접할 수 있으며 또한 미국 또는 세계에서 온 각계각층의 다양한 사람들이 이 행사에 참여하기 때문에 안목을 높힐 수 있는 계기를 만들어주었다고 생각한다.
이 글은 이번 행사를 통해 필자가 알게된 Adobe의 신기술 및 트렌드를 소개하는 것을 목적으로 한다.
내용중에 필자의 주관적 진술이 많이 포함되어 있다. 즉 Adobe의 정책이나 방향을 말하고 있지만 그에 대한 전망에 대한 개인적인 의견이지 Adobe의 실질적인 정책은 아님을 미리 말해둔다.
오픈 스크린 프로젝트 - 디지털 기기간에 장벽제거
이번 Adobe MAX에서 Flash Platform에 관심이 있는 개발자라면 바로 Flash Player 10.1과 AIR 2.0에 대한 언급이 아니였을까 생각한다. 이들 기술은 더욱 다양하고 강력한 API를 제공할 수 있게 되었다. 그러나 이 기술 자체만 관심가지는 것보다 그 기술에 어째서 만들어졌는가? 더 나아가 Adobe는 왜 이런 기술을 만들어냈는가 관심을 가져야할 것이다.
Flash Player 10.1과 AIR 2.0은 오픈 스크린 프로젝트(Open Screen Project)의 첫번째 결실이다. 오픈 스크린 프로젝트는 지금까지 데스크탑 컴퓨터 환경을 뛰어 넘어 텔레비전, PC, 모바일 장비, 각종 소비자 가전제품등의 디지털 기기간에 호환성을 보장해주고 다양한 사용자 경험을 선사하기 위한 프로젝트이다. 이 말을 쉽게 이야기 하자면 다양한 기기에 Flash 및 AIR 애플리케이션이 운용될 수 있도록 각종 디지털 기기 업체와 협력하는 프로젝트인 것이다. 애초부터 Adobe Flash Platform 기술은 웹에서 시작해 데스크탑으로 또 각종 운영체제(Windows, Mac, Linux 등)를 지원해왔다. 하나의 애플리케이션이 다양한 환경에서도 동작하게 하기 위한 전략을 세웠던 Adobe가 이를 더 확장하기 위한 정책으로 만든 프로젝트가 바로 오픈 스크린 프로젝트인 것이다.
오픈 스크린 프로젝트에 참여한 기업은 한국의 삼성, LG를 비롯해 Nvidia, 노키아, 모토로라, 인텔등 다양한 기기 업체들을 포함한다. 또한 각종 컨텐츠 업체들도 참여했는데 대표적으로 구글이 있겠고 BBC, MTV Networks, NBCUniversal 등도 이 프로젝트에 참여했다.
Adobe는 자사의 기술을 널리 활용될 수 있도록 다음과 같은 적극적인 오픈 정책을 실현해왔다.
SWF, FLV/F4V 스팩 사용 제한을 없앰.
어도비 플래시 플레이어용 모바일 단말기 포팅 레이어(APIs)를 퍼블리싱.
어도비 플래시 케스트 프로토콜 및 대용량 데이터 서비스용 AMF 프로토콜을 퍼블리싱.
디바이스용 어도비 플래시 플레이어와 AIR 제품의 차기 버전의 라이센스를 무상 제공.
오픈 스크린 프로젝트의 첫번째 결실이 Flash Player 10.1과 AIR 2.0 이라고 이미 언급했다. 그럼 어째서 이 기술이 이 프로젝트의 결실물이 되는 것인가? 가장 중요하게 보아야 할 것을 뽑는다면 기능, 메모리, 속도, 전력소비량이 아닌가 생각한다.
기능적 측면으로 Flash Player 10.1는 멀터터치가 지원되고 AIR 2.0의 경우 다양한 USB 디바이스 지원, 소켓서버, UDP통신 다양한 설치 포멧(dmg, exe등)등을 지원하게 된다. 이러한 기능이 지원된데에는 기존의 부족한 기술을 업그레이드 시키는 것외에도 오픈 스크린 프로젝트와 연관되어 사용자에게 다양한 경험을 주기 위한 것이다. 가령 요즘 모바일에 멀티터치는 기본기능으로 들어간다. 이러한 기능을 Flash 애플리케이션으로 사용할 수 있도록 한것이다. 기능은 단순히 기술을 돋보이게 하는 것이 아니라 철저한 정책 바탕위에 만들어진다.
다양한 기기에서 Flash 컨텐츠가 문제없이 돌아가야 하므로 메모리, 속도, 전력소비량을 생각하지 않을 수 없을 것이다. 특히나 모바일과 같은 기기에서는 메모리, 속도, 전력소비량을 어떻게 최적화 시키느냐가 관건이 된다. 이는 오픈 스크린 프로젝트를 실현하기 위한 중대한 기술적 이슈로 Adobe의 노력의 결실이 이번 Adobe MAX를 통해 공개된 것이다.
메모리의 경우 매우 괄목할 만한 성장을 보였다고 할 수 있다. 아래 그림은 키노트 당시 화면으로 각종 애플리케이션에서 기존의 Flash Player 10과 새 Flash Player 10.1 간에 메모리 사용량을 비교하고 있다. 2~3배의 메모리 사용량을 줄였음을 볼 수 있다.
다음으로 전력소비량이다. 전력소비량도 다음 키노트 영상에서 볼 수 있듯이 모바일 기기에서 운영되는 Flash 컨텐츠가 얼마나 전력을 소비하는가 절대적 수치로 보여주고 있다. 일반적인 동영상의 경우 3.4시간, 애니메이션이 들어간 컨텐츠의 경우 6.5시간, 마지막으로 저전력 모드에서 14.5시간까지 유지할 수 있다고 한다.
마지막으로 빼놓을 수 없는 것이 속도이다. 다양한 기기들 중에 모바일에서 움직여야하는 컨텐츠의 경우에는 적은 CPU연산으로 속도를 빠르게 하거나 GPU 가속이 필요할 것이다. 오픈 스크린 프로젝트에 참여한 Nvidia가 그것을 실현하는데 결정적인 역할을 하게 되었다. 노트북, 넷북, 스마트폰, 스마트북 등 Nvidia 지포스와 아이온, 테그라 플랫폼 등에 쓰이는 Nvidia GPU의 지원으로 낮은 전력과 CPU점유율을 Flash Player 10.1부터 가능하게 해주었다. 이로써 모바일 기기에서도 HD급 영상을 부드럽게 재생할 수 있게 되었다. 다음 동영상은 이번 키노트를 통해 공개된 속도의 최적화를 단적으로 보여준 동영상이다.
이처럼 Adobe는 오픈 스크린 프로젝트를 통해 Flash Player 10.1과 AIR 2.0을 탄생되었으며 이들 기술은 기능, 메모리, 전력소비량, 속도등의 개선에 큰 성과를 거두었다.
세계 전 PC에 99%이상 Flash Player가 설치되었으며 이미 두터운 사용자 층을 다지고 있는 Flash Platform 기술이 이제 Flash 애플리케이션이 모바일, 텔레비전등에도 동작하게 하는 것은 Adobe가 오래전부터 바래왔던 RIA(Rich Internet Application)의 참모습을 보여주기 위한 것이 아닌가 생각된다.
오픈 스크린 프로젝트의 가장 큰 성과는 바로 엄청난 수의 디자이너와 개발자들이 그들이 가진 자산과 자원을 그대로 사용할 수 있다는 것에 있다. 이로써 Flash Platform 기술을 이용하는 업체들에게 시간과 자본을 매우 줄이는 결정적인 역할을 하게 된 것이다. 이전에 모바일의 Flash 컨텐츠는 Flash Lite로 ActionScript 2.0 기반하에서만 개발할 수 밖에 없는 한계가 있었다. 그러나 이 한계를 기존 Flex, Flash, ActionScript 3.0 기술을 그대로 이용해 데스크탑 뿐 아니라 각종 다양한 기기에도 운영할 수 있는 애플리케이션을 만들 수 있도록 기술적, 정책적 문제를 오픈 스크린 프로젝트를 통해 해결한 것이다. Adobe는 이제 Cross OS, Cross Browser를 넘어 Cross Device를 실현하기 위한 디딤돌을 제대로 만든 셈이다.
불행히도(?) Apple은 오픈 스크린 프로젝트에 참여하지 않았다. 하지만 Adobe는 Adobe Flash Professinal CS5 베타버전을 선보이며 ActionScript 3.0 기반으로 iPhone용 애플리케이션을 만들어 시연하는 모습을 보여줌으로써 Flash Player가 iPhone에 탑제되어야 한다는 문제를 말끔히 씻었다. Adobe Labs에서는 CS5에 대한 설명 및 이를 이용해 만든 iPhone 애플리케이션을 소개하고 있다.
Adobe가 오픈 스크린 프로젝트 프로젝트를 통해 다양한 기기, OS등에 지원하도록 하는 것은 단순히 Flash컨텐츠를 공급하여 자사의 컨텐츠 제작도구를 팔기 위한 것만은 아니라고 생각한다. 물론 지금까지 Adobe는 PhotoShop, CS4, Flex Builder, LCDS등의 다양한 제품을 팔아 이윤을 남겨 회사를 운영했다고 본다. 그런데 몇년전부터 Adobe는 자사의 핵심 기술을 무료로 공개하기 시작했다. 물론 그것이 컨텐츠 제작도구는 아니지만 제품 외에 다양한 기술을 아무 댓가가 없는 것 마냥 공개하기 시작한 것이다. 이미 실시간 메세지 전송 프로토콜인 RTMP과 데이터 통신의 핵심의 일부를 BlazeDS등를 제작해 오픈 소스로 공개하고 있다. 누구든지 오픈소스 홈페이지를 통해 Adobe에서 제작한 소스를 볼 수 있다.
요즘은 공개가 주요 덕목이라고는 하지만 Adobe가 자사의 기술을 이렇게 공개하는 이유는 무엇일까? 또한 오픈 스크린 프로젝트를 통해 Flash 컨텐츠가 다양한 자원, 기기들을 지원할 수 있도록 한 배경은 무엇일까? 이 이유에 대한 답은 이외로 간단하다. 회사는 영리를 목적으로 한다. Adobe도 건실한 하나의 회사이므로 당연히 영리를 목적으로 한다. 영리를 취하기 위한 방편으로 Adobe가 생각한 것은 바로 유통이다.
iPhone, iPod을 사용하는 사용자라면 Apple Store에 대해서는 너무도 잘 알것이다. iPhone이라는 매우 훌륭한 기기를 만든 것도 사실이지만 Apple은 더 앞서 이들 기기에 사용할 애플리케이션이 널리 보급되고 공개될 수 있는 유통 채널을 Apple Store를 통해 확보했다. 애플리케이션 개발업체 및 개인 개발자는 Apple Store를 통해 자신의 애플리케이션을 팔 수 있고 그 이윤의 일부를 Apple이 가진다. 얼마 안되는 액수이긴 하지만 이것이 쌓이면 엄청나다. 이런 유통 채널로 무수한 애플리케이션이 만들어졌고 미려한 iPhone의 디자인에 흠뻑 반한데다가 다양한 컨텐츠까지 접할 수 있는 고객입장에서는 iPhone을 선택하지 않을 수 없게 되었다. 어디 그뿐인가? 이것으로 Apple의 매출을 최고조를 이루고 있고 자사의 회사 이미지도 상승하여 다른 제품군들의 매출도 상승하게 되었다. 이 점에서 필자가 생각하는 Apple의 가장 큰 성공요인은 유통이라고 생각한다.
Adobe는 Apple보다 늦었지만 분명 유통의 강점을 잘 알고 있었을 것이라 생각한다. 유통을 적절하게 해서 성공한 Apple의 사례는 Adobe에게 좋은 간접 경험이 되었으리라 판단한다. 그럼 구체적으로 Adobe는 어떻게 유통을 하겠다는 것인가?
플래시 플랫폼 서비스(Flash Platform Services)는 Apple Store처럼 유통채널을 만들기 위한 첫단추라고 생각한다. 이번 Adobe MAX 2009 키노트에서는 이에 대해 많은 부분 소개하진 않았다. 하지만 이번에 Flash Platform Service을 공개함으로서 Adobe도 Flash 컨텐츠 유통 시스템을 만들고 있다는 것을 예상할 수 있게 되었다.
플래시 플랫폼 서비스는 배포(Distribution), 협업(Collaboration), 소셜(Social)이라는 3가지 키워드로 요약된다.
배포 서비스는 말그대로 Flash Platform 애플리케이션이 배포될 수 있는 공간을 만들어 준다는 것이다.
이 서비스는 만들어진 Flash애플리케이션을 마이스페이스나 페이스북과 같은 소셜 서비스와 모바일 기기, 데스크톱등에 배포하기 위한 일련의 복잡한 절차를 해소 시켜주고 각종 프로모션 및 광고를 쉽게 해주고 각종 통계까지 내준다. 배포 서비스에 대해 더욱 자세히 알기 위해 다음 링크와 동영상을 참고한다.
협업 서비스는 Adobe가 Adobe자체 기술을 지원해준다는 말이다. 가령, 채팅, 오디오, 비디오 서비스등은 일반 개발자뿐 아니라 회사에게 자체 서버가 있어야하는 기술적, 자금적 부담감이 존재한다. 이런 어려운 부분을 Adobe에서 지원해준다는 이야기이다. 다음 링크로 부터 이 협업 시스템의 형태와 Showcase를 볼 수 있겠다.
소셜 서비스은 페이스 북과 마이 스페이스와 같은 소셜 네트워크와 통합해서 이를 가지고 개발할 수 있도록 하는 서비스이다. 하지만 현재 공개되어 있지 않다. 이미 Open API를 통해 매쉬업 애플리케이션들이 만들어져 있고 그 중요성 또한 높아지고 있다. 이것을 더욱 쉽고 강력하게 할 수 있도록 소셜 서비스를 통해 지원해준 다는 것을 의미한다.
위에서 언급한 3가지 키워드를 바탕으로 플래시 플랫폼 서비스로 하여금 유통채널을 만들어 가겠다는 의미로 필자는 받아 들였다. 아직 많은 부분 완성되지 않았지만 앞으로 Flash Player 10.1 및 AIR 2.0 배포되고 이를 지원하는 다양한 디지털 기기들이 판매되며 또한 플래시 플랫폼 서비스의 3가지 키워드가 완성이 된다면 새로운 Flash 컨텐츠 유통채널이 만들어져서 기존 Flash Platform 개발자의 유입이 증대될 것이고 더불어 관련 애플리케이션도 많아져 결국 사용자의 경험을 극대화 시키는 효과와 함께 이것을 수용한 기술 및 제품이 잘 팔리게 되는 효과를 기대할 수 있을 것이라 생각한다. 결국 자사 만족, 개발자만족, 고객만족을 위한 Adobe의 정책이라 할 수 있다.
이미 두텁케 형성된 Flash 컨텐츠 개발자들은 플래시 플랫폼 서비스를 통해 기존 기술을 맘껏 이용해 개발과 배포를 쉽게 할 수 있다. 그리고 각종 기기 및 기술적 어려운 부분은 오픈 스크린 프로젝트를 통해 그 문제를 해결한다. 이들 모두가 결국 Flash 컨텐츠의 유통을 실현하기 위한 정책의 일환임을 알 수 있다.
정리하며
Adobe MAX 2009 행사는 개인적으로 어떤 기술적인 답변을 얻었다것 외에 Adobe가 지향하는 정책에 대한 로드맵을 더욱 이해하는데 도움이 된 자리였다고 생각한다. 어짜피 기술은 계속 발전한다. 기술이 기술자체로 끝나는 것이 아니라 그 방향성이 더 중요하고 결국 사용자에게 감동을 주어야 그 기술이 빛을 발할 것이라 생각한다.
Adobe가 Flash Platform의 확산을 위해 오픈 스크린 프로젝트(Open Screen Project)와 플래시 플랫폼 서비스(Flash Platform Services)라는 여러가지 대안을 마련하여 이에 기술이 뒷받침 되도록 방향성을 맞추어가고 있다는 것을 염두한다면 Flash Platform 관련 기술 적용에 더욱 도움이 될 것이라 생각한다.
독립형 FB4(Flash Builder 4)를 사용하지 않고 굳이 Eclipse에 FB4 plugin을 설치하는 이유는 독립형 FB4는 기능의 제약점이 있기 때문이다. 물론 FB4로도 충분히 개발이 가능하지만 Eclipse와 연동하는 것은 이 편이 실무에 더욱 적합하다. 그 이유는 hika님의 글 Flex Builder는 반드시 Plug in 으로 설치 글을 읽어보면 알 수 있다.
하지만 이러한 설치법은 처음 해보는 사람에게는 단순하지 않다. 한방에 설치하는 독립형 FB4에 비해 이것저것 고려할 것이 많은 것 같은 생각이 들기 때문이다. 이 글을 쓰는 목적은 FB4 plugin을 설치를 하는데 있어서 다소 어려움을 쉽게 극복하기 위한 방법을 소개하기 위함이다.
원래 eclipse.ini에서 수정된 부분은 -vmargs의 위치가 -Xms40m 바로 위로 이동된 것이며 추가된 부분은 -vm 부분이 들어간 것이다. 이때 javaw.exe 경로는 각자 jdk또는 jre 설치 경로를 따라 설정하면 되겠다. 이렇게 해도 같은 에러가 난다면 검색을 통해 다른 방법을 찾길 바란다.
3. Flash Builder 4 plug in을 설치시 반드시 Eclipse 설치경로를 지정해줄것!
FB4 plug in을 설치하면 중간에 Eclipse설치 경로를 지정하는 순서가 있다. 이 부분을 잊지 말고 Eclipse 경로를 지정하기 바란다.
4. FB4를 실행할때는 Eclise를 실행하거나 FB4에 설치된 Run FB Plug-in with alternate Eclipse를 실행한다.
FB4 plug-in에서 Run FB plug-in 을 실행하면 eclipse-host-distro의 Eclipse가 실행되므로 이것을 사용하지 말자.
5. 바로가기를 FB4 아이콘으로 바꾸기 일반적으로 Eclipse를 실행하기 위해 바탕화면에 바로가기를 만들거나 빠른실행아이콘으로 등록해서 사용할 것이다. 하지만 이 바로가기는 기본 아이콘이 이클립스이다. 그러므로 기존에 사용하는 이클립스 아이콘이 있다면 무엇이 Flash Builder이고 무엇이 Eclipse인지 잘 분간이 안갈터...
바로가기의 아이콘을 Flash Builder 아이콘으로 바꿔보자.
1. Flash Builder Plug-in이 설치된 폴더로 가서 eclipse-host-distro 폴더에 가면 Eclipse.ico 파일이 있다. 이것을 복사해서 Eclipse 설치 폴더에 복사한다.
2. 다음으로 바탕화면 또는 빠른실행아이콘을 선택해 마우스 오른쪽 버튼을 눌러 속성을 선택한다.
3. 아이콘 변경 버튼을 눌러 Eclipse 설치 폴더에 복사한 Eclipse.ico로 바꿔준다.
7. 이전 워크스페이스의 SDK경로는 따로 빼자!
Flash Builder의 SDK가 아닌 기존에 원래 사용하던 SDK를 참조할 필요가 있는 경우가 있다. 이런 문제를 해결하기 위한 방법은 여러가지가 있겠지만 본인은 C나 D 드라이브로 SDK폴더를 따로 만들어 FB가 이 SDK를 참조하도록 하고 있다.
다음과 같이 진행한다.
1. C나 D 드라이브등에 사용할 SDK를 복사한다.(새 FB의 설치경로에 sdks에 있는 파일을 복사할 수 있다.)
2. FB를 실행한다.
2. 메뉴에서 Window > Preference를 선택한다.
3. 창이 뜨면 좌측에 Flash Builder를 열어 Installed Flex SDKs를 선택한다.
4. 우측에 Flex 3.4, Flex 4.0이 이전 FB버전의 경로를 참고하고 있을 것이다. 이를 C나 D드라이브에 복사한 SDK를 참조하도록 한다.
8. 기본 플러그인 설치는 기본!
독립형 FB4에는 설치되지 않는 플러그인이 Eclipse에는 언제든지 설치가 가능하다. 주로 협업이 이뤄지므로 SVN등을 설치해야하고 다양한 배포 경로를 확보하기 위해 ANT관련 설정이 필요할 것이다. C/C++개발을 위한 CDT, PHP개발을 위한 PDT등 플러그인을 제한없이 설치할 수 있으니 Eclipse의 FB4 plugin을 설치하는 편이 훨씬 득이라는 것을 느낄 수 있을 것이다.
Flex 2 기반으로 근 2년 이상 한글문서를 담당했던 Flexdocs.kr 서비스를 하지 못하게 되었습니다. 그동안 Flexdocs.kr은 제 개인서버에서 서비스 했습니다. 한글작업을 위해 몇몇분들이 관심을 가지고 지속적으로 수정했지만 개인서버라는 제약과 관심부족 그리고 그 서버를 유지하는데 있어서 필요이상의 개인자본을 넣어야한다는 부담이 있었습니다. 그래서 집에서 간단한 서버 구축으로 유지하려고 했으나 인터넷공급업체에서 80번 포트를 막아놓아 더 이상 서비스를 하기에는 불가능하게 되었습니다.(요즘 대부분 인터넷 공급업체는 80번 포트 이용을 막고 있습니다.)
flexdocs.kr의 문서는 모두 제가 가지고 있습니다. 만약 flexdocs.kr을 계속 유지해야한다고 생각하시고 서버 호스팅을 무료로 해주실 수 있는 분이 있으시다면 연락부탁드리겠습니다. flexdocs.kr은 Apache, php, mysql이 지원되야하며 svn과 mod_rewrite등이 지원되면 되겠습니다.
참석한 Adobe MAX는 Adobe의 가장 큰 행사중에 하나로 1년에 한번씩 미국의 주요 도시를 돌면서 열립니다. 이번 행사 참여로 Adobe 로드맵에 대해서 어느 정도 알 수 있게 되었습니다.
이 로드맵의 첫번째 단추는 Adobe의 기술의 핵심인 Flash Player을 모든 플랫폼에 적용하는 겁니다. 이 플랫폼이라는 것은 모바일이 될 수 있고 각종 다른 기기들이 될 수 있을겁니다. 이것이 가능하게 하기 위해 Adobe는 Open Screen Project(http://www.openscreenproject.org/) 라는 것에 참여하고 있습니다. 이 프로젝트로 각종 기업에서 만들어지는 모바일등의 디바이스에 Flash Player가 설치되고 이미 엄청나게 보급화 되어 있는 Flash 개발인력을 어렵지 않게 흡수 시킬 수 있게 됩니다.
Open Screen Project를 반영하여 탄생된 것이 바로 Flash Player 10.1 입니다. 이 Flash player 10.1은 데스크탑 뿐 아니라 모바일에도 최적화되어 돌아갈 수 있도록메모리 및 속도 향상에 큰 변화를 가져왔습니다. 그리고 기존에 Flash Lite로만 개발했던 인력을 ActionScript 3.0, Flex 개발자들까지 모바일 프로그램을 할 수 있도록 된거지요. 메모리,속도향상등에 더욱 자세한 내용을 보고 싶다면 제 블로그를 보세요.
대부분의 개발자의 주요 관심사인 Apple의 경우 Open Screen Project에 참여하지 않고 있습니다. 그래서 Adobe는 Flash로 개발하고 아에 iPhone용 애플리케이션이 나오도록 해버렸습니다. 이미 어도비 Labs에 Flash로 만든 iPhone용 애플리케이션이 애플스토어에 올라왔다는 것을 확인할 수 있습니다. 현재 직접 아이튠즈에서 다운로드 받아볼 수 있습니다.
Open Screen Project를 통해 대부분의 디바이스 및 각종 플랫폼에 Flash Player가 설치될 수 있도록 하여 Adobe가 얻을 수 있는 것은Flash 애플리케이션의 유통일겁니다. Adobe가 내놓은 모든 것들이 이제는 모두 이 유통에 집중될 모양입니다. 이에 대한 구체적인 시스템이 바로 Flash Platform Service(http://www.adobe.com/devnet/flashplatform/services/index.html) 입니다. 아래링크는 제 블로그에 올린 Flash Platform Service에 대한 전문입니다.
여러분은 지금 Flash로 만든 iPhone, iPod 용 애플리케이션을 애플 스토어에서 다운로드 받을 수 있습니다. Adobe Lab(http://labs.adobe.com)에서 올해 말에 나올 Flash Professional CS5를 홍보하기 위해 떡밥 제대로 내놯습니다. ^^
이번에 Adobe MAX 2009에서 공개한 Flash Platform Services이 바로 그것인데요. 제작한 Flash 애플리케이션을 Adobe가 지원하는 이 Flash Platform Services에 배포하면 자동으로 오픈 스크린 프로젝트에 등록된 회사에서 나오는 각종 모바일 및 다양한 플랫폼에 노출되어 많은 이용자들이 사용할 수 있게끔 하는 겁니다. 가령 Apple Store같은 역할을 한다고 보면 됩니다.
Flash Platform Services는 배포만 하는 것은 아닙니다. 여기에 각종 통계도 내줍니다. 자신이 만든 애플리케이션이 어떻게 배포되는지 알려주죠.
또한 배포된 것은 사용자가 구입하는 형태로 그에 대한 수입은 Adobe와 개발자가 일정한 비율로 나눠가지는 식이 될 겁니다.
또한 공식적인 발표가 이뤄지지 않았지만 MySpace 및 Facebook과 같은 소셜 네트워크(Social Network)도 지원해줍니다. 이에 관련되서는 다음 글을 읽으면 좋겠네요. 모바일 시장의 판도를 바꿀 소셜네트워킹은?
게다가 협업시스템도 갖췄는데요 가령, 채팅, 오디오, 비디오등의 어느정도 서버기반을 구축해야하는 부분도 쉽게 개발자가 이용할 수 있도록 해줍니다.
그래서 Flash Platform Services의 주요 키워드는 배포, 협업, 소셜(Distribution, Collaboration, Social)이 되겠습니다.
Adobe MAX 2009는 미국 LA에서 현지 날짜 2009년 10월 5일부터 7일까지 열립니다. 이 행사를 통해서 Adobe에 추진하는 가장 새로운 소식을 접할 수 있습니다. 저처럼 직접 참석해서 들을 수 있지만 참석하지 못한 사람도 현장 분위기를 느낄 수 있는 방법이 있습니다. 바로 Adobe TV를 이용하는 방법입니다.
주요행사인 키노트 및 각종 세션을 이곳을 통해 들을 수 있습니다.(아직 행사 진행중이므로 지금도 계속 업데이트되고 있습니다.) 꼭 한번 참조하셔서 관심있는 분야를 들어보세요. 들으시고 나름대로 정리하셔서 블로깅도 해주시면 좋겠어요. 저기 있는 내용 다 블로깅하고 싶지만... 어휴~ 정말 너무 많아요 ㅎㅎ
제 생각에 세세한 조절을 위해 코드를 수정할 때일겁니다. 가령, 100px 움직여야하는 디스플레이 객체를 90,80,70씩 움직여가며 가장 좋은 결과를 보여준다던가 하는 일을 해야할 경우 코딩후 실행, 종료후 코드 수정다음 다시 실행하는 작업을 반복해야할 겁니다.
Adobe MAX 2009 둘째날 저녁에 열린 MAX Bash@LA Live 행사에서 공개한 Flash Builder는 위의 문제를 해결하기 위해 Edit/Continue 기능을 소개했스니다. 듣기로 이 기능은 이미 일본의 Spark 프로젝트 팀에서 먼저 한걸로 알고 있는데요. Anyway....
Edit/Continue 기능은 디버깅 중간에 코드를 수정하면 바로 실행중간에 결과가 반영된다는 겁니다! olleh!!!
Flash Platform 개발자들의 수고를 한층 덜어주는 기능이군요. 제 생각에 이 기능은 Flash Builder 정식버전 및 Flash CS5에서 적용되지 않을까 생각됩니다. 아주아주 기대가 큰 기능입니다.
이 기능이 가능한 것은 어짜피 컴파일 결과물이 AVM2상 메모리에 올라가고 변경된 코드와 대응하는 메모리상의 위치의 값을 변경하는 일이기 때문입니다.
미국 LA에서 열리는 Adobe MAX 2009 행사 키노트에서 요즘 한국에서도 급부상하고 있는 아이폰(iPhone) 애플리케이션을 Flash로 제작할 수 있게 되었다고 최초로 공개했다. Flash CS5부터 Flash IDE에서 제작한 결과물을 iPhone용으로 컴파일하는 기능이 추가될 예정이다.
아래 그림 하나로 모든게 설명되는.... ^^
아래는 키노트 시에 공개된 동영상이다.
Adobe 사장, 부사장 둘이서 아이폰을 어떻게 구워삼을까 고민하다가 결국 개발자에게 넘긴다. 한방에 해결된다는... 뭐... 그런거?
Adobe MAX 행사는 키노트 외에도 각종 세션이 있습니다. 행사 참여자는 자신이 듣고 싶은 세션을 선택해서 언제든지 들을 수 있지만 다른 세션과 중복되는 경우에 각 세션에서 진행한 내용을 Adobe TV를 통해 못봤던 세션을 볼 수 있습니다.
Building Applications for iPhone with Flash Professional CS5
Flex for mobile devices
아래는 위 동영상에서 Flex로 만든 애플리케이션을 iPhone에서 구동 시연을 캡쳐한 사진입니다.
결론 : Flash Platform 개발자들이여! 이것저것 다하려 하지 말고 Flash하나만 잘해서 향후 10년 밥줄이어갑시다. ㅋ
호텔에서 Adobe에서 제공하는 셔틀버스를 타고 Adobe MAX 행사장인 LA 컨벤션 센터에 왔습니다. 오늘부터 3일간 행사에 참가하게 됩니다. 등록을 마치고 제공해주는 간단한 아침식사(빵과 커피)를 먹고 첫날 키노트 행사에 가기 위해 근처 Nokia Theater에 갔습니다. 전 ACC라 Adobe Community Leader라 태그가 붙은 명찰을 받았습니다. 이 마크가 달려있으면 주요인사, 기자단, 주요발표자 다음으로 자리배치 해줍니다.
이 키노트 행사에 무려 3500명 정도가 왔다고 하네요. 다들 무슨 이야기가 올까 궁금해하는 것 같았습니다.
마이크 챔버스 아저씨도 왔네요. 초상권 침해나? ^^
어도비의 윤미선님과 우야꼬와 나~~ 행사중에 있을 3D영화를 보기 위해 준 안경을 쓰고 함께 찰칵
그나마 잘나온 야꼬와 내 사진.. ㅋ
오픈 공연을 시작했네요.... 아무튼 이렇게 Adobe MAX가 시작되었습니다. ^^
이날 Adobe MAX에서 Flash Player 10.1과 AIR 2.0등 각종 최신정보를 들을 수 있었고 기억에 남는 것은 플래시가 iPhone 애플리케이션으로 컨버팅해주는 기능을 CS5 부터 넣겠다는 것과 Flash Player가 오픈 스크린 프로젝트하에 많은 회사에서 제작하는 모바일등 다양한 플랫폼에서 동작하도록 지원한다는 것, 그리고 더욱 강력해지는 AIR 2.0에서 USB 지원 및 소켓서버, 멀티터치 지원등입니다.
키노트 마지막쯤에 AVATAR라는 3D영화 제작과정과 각종 씬을 보여주었는데....3D안경을 끼고 보는 이 영화는 정말 실세계 3D에 빠지는 듯 했다. 영화내용도 너무 실감나더군요. 이 영화가 아마도 올해말에 미국에 개봉할 터인데 한국에서도 크게 인기를 끌지 않을까 생각합니다.
Flex 4 컴포넌트와 AIR 2.0에 대한 세션을 듣고 저녁에는 Adobe 관계자 및 기자들과 만나 식사를 같이 했습니다. 시차적응 못해서 전날 1시간 밖에 못잤는데 오늘은 푹 자야겠네요.
이번 Adobe MAX 2009에서 Flash Player 10.1을 공개했습니다. 이번 키노트를 통해 더욱 최적화되고 강력해진 Flash player에 대해 설명을 들을 수 있었는데요, 주목할 점은 다양한 모바일등의 다양한 플렛폼 지원과 최적화 부분이겠네요.
MAX현장에서 직접 찍은 사진입니다. ^^
위 화면에서 Flash Player 10.1의 추가 및 향상된 기능을 보실 수 있습니다. 스마트 폰을 지원하며 멀티터치 기능이 가능해집니다. 또한 메모리, 전력, 하드웨어 가속에 대해서 최적화 했으며 Http 비디오 스트리밍등을 지원하게 됩니다.
각종 스마트폰에 지원이 되는 만큼 애플리케이션의 저전력 구동은 핵심이 될겁니다. 일반 비디오는 3.4시간, 활동적인 에니메이션이 들어간 애플리케이션인 경우 6.5시간, 저전력 모드에서는 14.5시간 볼 수 있다고 언급하고 있습니다.
Flash Player 10.1과 기존 Flash Player 10의 메모리 사용양을 나타냅니다. 같은 자원을 쓰고서도 거의 1/2~2/3가량 용량이 줄어들었습니다. Flash Player 10.1이 모바일에 지원되기 위한 최적화의 노력의 성과겠네요.
Adobe는 이번 키노트를 통해 Flash Player가 더이상 데스크탑이 아닌 모바일에서도 같은 동작을 한다는 것을 강조하고 있습니다. 지금까지 Flash Lite로만 모바일 기기 애플리케이션을 만들었지만 Flash Player 10.1부터는 일반 Flash로도 충분히 모바일에서 돌아가는 플래시 컨텐츠를 생산할 수 있게 되었습니다. 이렇게 Flash Player가 다양한 모바일에 지원된데에는 오픈 스크린 프로젝트(Open Screen Project)의 추진과 관련 있습니다. 흥미로운 점은 이 프로젝트에 구글이 동참했다는 점입니다. 오픈 스크린 프로젝트는 더이상 PC, 모바일만을 뜻하지 않으며 다양한 플렛폼에서 다양한 경험을 제공하는 것을 목표로 합니다. 이 오픈 스크린 프로젝트는 구글, 삼성, LG를 비롯해 노키아, NVIDIA등 수많은 회사가 참여하고 있으며, 앞으로 이들이 내높는 다양한 플랫폼에 Flash Player를 지원하게 되어 어디서든 Flash 컨텐츠를 접할 수 있게 됩니다. 하지만 아쉽게도 아이폰의 제작 회사인 Apple은 이 프로젝트에 포함되지 않았군요.
하지만 가만히 있을 Adobe가 아니죠.
위 그림 하나로 다들 쓰러졌다는....
그러니깐 Flash IDE에서 Flash컨텐츠를 개발해서 그대로 iPhone용으로 익스포트 시켜주는 기능이 CS5부터 추가된다고 합니다. 멀티터치 기능도 추가되겠다. 결국 이 기능도 iPhone을 겨냥한듯합니다. ㅎㅎ
저는 새로 리뉴얼 되는 스타플(http://starpl.com)의 타임라인과 키워드에 대해서 서비스차원에서 접근을 하려고 합니다. 저는 스타플을 만든 회사 위콘 직원입니다. 단순히 회사차원에서만 보는게 아니라 사용자 입장과 또 서비스적인 측면에서 바라보겠습니다. (결국 이런 말의 의미는 스타플이 활성화 되는 마음에서 왔다는 겁니다.)
지금 타임라인은 시간순별로 글의 제목이 나열되는 형태입니다. 물론 스타플 초기의 타임라인은 다른 어느 서비스보다 먼저한 형태입니다. 하지만 지금의 타임라인은 스타플 서비스에 잘 융합시켜놓은 것은 사실이지만 스타플이 최초가 아니며 비슷한 타임라인이 다른 서비스에도 존재합니다. 즉, 지금 타임라인은 스타플 고유의 것은 아니라는 것이지요. 그래서 스타플의 가장 독특하고 스타플 서비스의 중심이 타임라인이다라는 말은 지금의 타임라인으로서는 적절치 못합니다. 여기서는 스타플 만의 경쟁력을 찾기 힘들어지죠.
지금 타임라인은 카테고리별 시간순에 대한 글의 나열형태로 되어 있는 형태이기 때문에 서비스 차원의 SNS는 기대하기 힘듭니다. 지금 형태의 타임라인이 좋다고 하시는 분도 계시지만 시간순으로 가시화 시킨것 외에는 개인블로그와는 다를바 없다고 생각합니다. 나쁘지 않지만 더이상 확장하기 힘든 형태는 서비스의 정체를 일으키는 주요인이라고 생각합니다. 저는 타임라인이 SNS로의 확장이 반드시 필요하다고 생각합니다.
스타플은 SNS가 되길 바랍니다. SNS는 사람들과 사람들의 관계를 엮어주는 것을 기본으로 합니다. 왜 엮어줄까요? 그것은 사람은 기본적으로 사회적 동물이기 때문입니다. SNS는 바로 그 사회성을 최대한 극대화 시키는 것을 목표로 한다고 생각해요. 그래서 저는 SNS는 기본적으로 정보중심이 되어야한다고 생각합니다. 특별히 내가 원하는 정보를 매우 쉽게 찾을 수 있고 공유할 수 있어야한다고 생각해요. 결국 관심분야를 가진 사람들과 묶어줄 수 있어야 한다고 생각합니다. 하지만 지금의 타임라인은 그것을 해주는데 역부족입니다. 추억공유기능이라는 색다르고 재미있는 기능이 있지만(저도 실제로 잘 사용했습니다.) 그것만 가지고는 SNS라고 하기에는 부족하지요.
SNS가 나왔으니 알림이를 빼놓을 수 없겠군요. 알림이도 스타플의 참 좋은 서비스임에 틀림없다고 생각합니다. 하지만 알림이는 SNS가 되기위한 도구로는 부족합니다. 친구맺고 친구들의 소식을 들 수 있는 좋은 도구이긴 하지만 진정으로 정보 및 관심분야의 공유는 안되죠. 결국 개인적인 관심에 어긋나는 내용은 더 보고 싶지 않게 될 것이고 결국 서비스를 이용하지 않게 됩니다. 사실 친구도 지인과 그냥 서비스 상에서 만난 친구등으로 나눠서 내가 진정으로 소식을 듣고 싶은 친구만 알림이를 통해 봤으면 하는 소망이 있습니다.
사람들마다 차이가 있습니다. 내 정보가 마구 공유되었으면 하는 사람, 그리고 공유가 되지만 내별에 방문자나 친구만 볼 수 있도록 하면 좋겠다는 사람, 마지막으로 혼자만의 타임라인을 구성하고 싶은 사람... 네! 서비스라면 이런 모든 사람을 다 수용하면 좋습니다. 하지만 서비스가 서비스의 가장 독특하면서 경쟁력을 갖추지 않는 상태에서는 무조건 다 수용하는 것은 바람직하지 않다고 생각합니다. 타임라인도 마찬가지 입니다. 지금의 타임라인이 근본적인 경쟁력을 갖추지 않은 상태에서 모든 사람의 요구는 들어주기는 힘들다고 생각해요.
진정으로 사용자들을 위한다는 것은 무엇일까요? 서비스는 기본적으로 사용자의 의견을 듣는 것이 중요하다고 생각합니다. 하지만 무조건 수용은 안됩니다. 서비스를 만드는 것은 사용자들이 아닙니다. 새로운 것을 내고 새로운 패러다임을 구축하는 일은 결국 서비스를 만드는 회사가 될 것이라 생각해요. 회사는 새롭고 경쟁력있는 SNS 를 만들면서 사용자의 요구를 받아야 한다고 생각합니다. 즉 결국 서비스는 고객만족을 주요목표로 하며 실천하는 겁니다. 이것이 바로 회사가 선택할 수 있는 사용자를 위한 길입니다.
새 타임라인에 대해서 언급하겠습니다.
새 타임라인의 중요한 컨셉은 바로 키워드입니다. 이것은 타임라인뿐 아니라 스타플 서비스 전체에 걸쳐서 키워드가 도입되었습니다. 키워드는 글안으로 숨어있는 태그를 더욱 극대화 시키기 위한 겁니다. 태그가 글에 속하는 반면 키워드는 글을 포함합니다. 단순한 차이지만 SNS로 확대를 위해 필요한 선택이라고 생각합니다. 키워드는 SNS를 만들기 위한 스타플의 주요 컨셉이 된 겁니다. 스타플의 별이 감성적으로 접근하여 관계를 만들어준다면 키워드는 정보성을 극대화 시키기 위한 겁니다. 그 키워드를 표현하기 위해 타임라인을 사용한 것입니다. 사람은 인생을 살고 인생은 시간개념이 들어갑니다. 시간과 인생은 별개가 아닙니다. 그리고 사람은 어떤 사람을 만나고 정보공유를 합니다. 시간과 정보(키워드)를 하나의 시각화 객체에 담은 것이 바로 타임라인이지요. 개인의 시간과 키워드를 표현하기 위해 타임라인은 아주 적절한 도구인겁니다.
새로운 타임라인의 키워드 도입으로 내 주요 관심사, 학교, 직장, 사는곳등의 다양한 주제로 키워드를 만들고 다른 사람과 공유할 수 있게 됩니다. 키워드 도입은 SNS로서의 도약을 위해 스타플 서비스의 선택인것입니다. 기존의 타임라인이라면 사실 이런 표현이 매우 어려워진다는 것을 이해할 필요가 있을 것 같아요.
카테고리와 키워드는 다릅니다. 카테고리는 블로그 카테고리라고 생각하면됩니다. 키워드는 말한것처럼 태그의 개념을 좀더 다른 방식으로 확대한 겁니다. 카테고리, 태그, 키워드 모두 무엇을 위해 존재하는 것일까요? 그것은 분류입니다. 나름대로 글에 대해서 분류하기 위해 사용하는 것이지요. 태그와 키워드의 비교는 이미 언급했으니 생략하고 카테고리와 키워드의 차이점을 말해야겠네요. 일반적으로 카테고리는 자기 자신만의 분류입니다. 이것으로 다른 사람과 공유는 안하지요. 하지만 키워드는 자신의 키워드이면서도 다른사람과의 연결 통로입니다. 카테고리는 누구나 알겠지만 분류로 인해 고민이 많게됩니다. 하지만 키워드는 그럴 걱정이 별로 없습니다. 어짜피 태그처럼 사용해도 됩니다. 더 한가지... 스타플의 키워드는 시간개념이 도입되었습니다. 하지만 카테고리는 시간개념이 없습니다. 어떠신가요? 완전 다르죠? 다르다 못해 무한한 확장이 가능해집니다. 카테고리는 이미 많은 서비스에서 사용합니다. 새롭고 참신한 서비스를 원하는 스타플 사용자들에게 키워드는 이러한 의미에서 좋은 경험을 선사할 것이라고 생각해요.
이것저것 타임라인과 키워드 이야기를 했지만 이러한 모든 것이 사용자들에게 쉽고 재미있게 다가가지 않으면 안된다고 생각합니다. 사용자들이 사용할 수 있는 환경을 제공하기 위해 이제 무단히 노력해야하고 첫단추를 이번 리뉴얼을 통해 끼었다고 생각합니다. 이번 리뉴얼이 100% 맞다라는 보장은 못하지만 방향성은 옳다라고 감히 주장합니다.
스타플은 앞으로 국내 대표 SNS뿐 아니라 국외 대표 SNS를 꿈꾸고 있습니다. 별이라는 색다르고 감성적인 메타포와 나의 시간을 담은 타임라인, 그리고 사람들과의 관계를 엮어주는 키워드로 스타플은 그 꿈을 이룰거라 의심하지 않습니다. 그래서 국제적으로 대한민국의 자랑스런 대표 서비스가 되길 희망합니다.
구를 표현하는데 있어서 많은 3D 예제들이 그냥 경도, 위도로 나눠서 텍스쳐 입히는 것이 대부분입니다. 사실 그게 가장 쉬운 방법이고 완성된 구를 표현할 것 같으면 그편이 좋습니다.
Geodesic Sphere에 대한 프로그램 코드는 그리 많지 않은 것 같더군요. 대신 건축물은 왜 이렇게 많은지.. ㅎㅎ 이 형태의 구로 만든 건축물이 매우 이쁘고 독특해보이죠. 디즈니랜드의 Epcot Dom이 매우 유명한 Geodesic Sphere의 한종류이죠.
응용하면 아래처럼 의자도 만들 수 있네요. 왠지 세련되어 보입니다.
Geodesic이라는 말은 두점간에 최단선(측지선)을 의미합니다. 이 원리를 이용해 만든 구가 바로 Geodesic 구라는 것이지요.
구글 어스(Google Earth)와 같은 3D 프로그램에서 구의 형태를 어떻게 표현했다고 생각하시나요? 정확히는 모르겠지만 Geodesic Sphere 기법을 이용했을 거라 추측합니다. 구글어스에 보이는 지도는 타일 이미지들의 모임입니다. 만약 경도,위도로 그 타일 이미지를 나눠버리면 결국 극쪽(북극, 남극)쪽에 불러와야할 타일 이미지는 엄청 많아지겠죠. 확대할수록 더할 겁니다. 이런 점에 비춰볼때 3D에서 Geodesic Sphere의 선택이 필요할 것 같아집니다.
Geodesic Sphere를 표현하는 방법은 다양합니다. TETRAHEDRON, OCTAHEDRON, ICOSAHEDRON 기반등을 이용해 그려나갈 수 있지요. 아래처럼요.
아직 3D 지도에 어떤 방식이 좋을지 명확히 판단하지 못했지만 OCTAHEDRON 또는 ICOSAHEDRON 기반이 아닐까 생각합니다.
회전 : 마우스 드래그
폴리곤수 조절 : 방향키 Up/Down
Flash 3D API의 drawTriangle 메소드 기반으로 그려본겁니다. 일반 경도, 위도만을 가지고 그릴때보다 복잡한 편이라 애를 먹었습니다. 극부분이 이미지가 찌그러져보이는 것은 UV설정이 잘못되었기 때문입니다. 이부분에 대한 보완이 필요합니다. 어쨌든 3D 지도 기반을 만들기 위한 첫단추를 꽨 셈이군요. ^^
Flash에서 이미지 처리는 지금까지 BitmapData 조작이였다. 싱글스레드 기반의 Flash Player는 이미지 조작을 하기에 좋은 퍼포먼스를 가지기 어려웠다. 하지만 Flash Player 10부터 멀티스레드를 기반으로하는 Adobe Pixel Bender를 지원함에 따라 이제 이미지 프로세싱에 Flash의 막강화력을 보여줄 수 있게 되었다. Adobe Pixel Bender에 대한 국내 문서는 그다지 많지 않은 편이지만 앞으로 Flash/Flex/ActionScript 개발자들에게 각광받는 기술이 될 것임에 틀림없겠다.
앞서 나는 천문학에서 사용하는 좌표계에 대해서 소개했었다.(http://blog.jidolstar.com/584) 여기서는 이들 좌표계 변환을 위해 몇 가지 표기법에 대해서 알아보고 좌표변환하는 식에 대해 설명하도록 하겠다.
α = 적경(right ascension). 이 값은 일반적으로 시(hours), 분(minutes), 초(seconds)로 표현된다. 필요하다면 어떤 공식에 사용하기 위해 degree값이나 radian값으로 변환해서 사용한다. degrees값을 시(hours)값으로 표현하기 위해 15로 나누어서 시, 분, 초로 변환할 수 있겠다.
δ = 적위(declination), 천구 적도의 북쪽이라면 +, 천구 적도의 남쪽이면 - 값을 가진다.
α1950 = B1950.0의 평균 분점(춘,추분점)을 기준으로 하는 적경
δ1950 = B1950.0의 평균 분점(춘,추분점)을 기준으로 하는 적위
α2000 = J2000.0의 평균 분점(춘,추분점)을 기준으로 하는 적경
δ2000 = J2000.0의 평균 분점(춘,추분점)을 기준으로 하는 적위
λ = 황경(ecliptical longitude), 춘분점(vernal equinox)으로부터 황도를 따라 측정한 경도
β = 황위(ecliptical latitude), 황도의 북쪽이면 +, 남쪽이면 -
l = 은경(galactic longitude)
b = 은위(galactic latitude)
h = 고도(altitude), 지평면 위는 +, 지평면 아래는 -
A = 방위각(Azimuth), 남점 또는 북점을 기준점으로 시계방향으로 잰 각. 기상학자나 항해자들은 방위각의 기준점을 북점으로 하여 북점(0˚), 동점(90˚), 남점(180˚), 서점(270˚)로 측정한다. 하지만 일부 천문학자들은 이 방법에 동의하지 않는다. 왜냐하면 적어도 북반구에 있는 관측자들이 시간각(hour angles)를 측정하기 위해 남쪽의 자오선을 기준으로 측정하기 때문이다. 내가 볼 때는 그건 별로 중요치 않다고 생각한다. 어느 관점에서 보느냐가 다를 뿐이다. 하지만 기준은 정해야겠지? 어쨌든 만약 남쪽 자오선을 기준으로 한다면 그 위에 올라온 천체는 시간각(H)과 방위각(A)가 모두 0˚가 된다.
ε = 황도의 기울기(obliquity of ecliptic). 황도와 천구의 적도 사이 각(angle)이다. 국제표준협회(International Astronomical Union, IAU)에서 평균기울기는 은 다음과 같이 정의하고 있다.
하지만 수차(aberration) 와 장동(nutation)의 영향을 받아 겉보기 적경과 적위를 사용한다면 ε + Δε 를 사용해야 한다. (이에 대한 자세한 내용은 다음에 언급하겠다.) 만약 α와 δ가 J2000.0의 표준 춘분점을 참고한다면 ε2000 = 23˚26´21˝.448 = 23˚.4392911 값을 사용해야 한다. B1950.0의 표준 춘분점을 참고한다면 ε1950 = 23˚.4457889 를 사용하면 되겠다.
L = 관측자의 경도, 그리니치(Greenwich) 자오선으로부터 적도를 따라 관측자의 위치까지 잰 각으로 앞으로 나오는 식은 서쪽을 +, 동쪽을 -로 한다. 서쪽이 +라고 하는 것은 사람들마다 시각이 다르다.
φ = 관측자의 위도, 북반구면 +, 남반구면 - 이다.
H = 지방시간각(the local hour angle), 자오선(meridian)으로부터 천구의 적도를 따라 서쪽방향으로 천체의 발까지 잰 각
θ = 지방항성시(the local sidereal time), 남중한 별의 시간각 또는 춘분점의 적경
θ0는 영국 그리니치(Greenwich)에서의 항성시이다.
시간각과 지방항성시 또는 그리니치 항성시, 관측자의 경도의 관계는 다음과 같다.
H = θ - α 또는 H = θ0 - L - α
만약 α가 장동(nutation)에 영향을 받는다면 항성시도 이에 영향을 받는다. 장동에 관련된 부분은 다음에 언급하겠다.
다음에 나오는 식은 각각의 좌표계에서 다른 좌표계로 변환하는 식이다. 식을 유도하는 과정은 생략하도록 하겠다.
1. 적도좌표계에서 황도좌표계로 변환
2. 황도좌표계에서 적도좌표계로 변환
3. 적도좌표계에서 지평좌표계로 변환
앞서 설명했던 시간각과 적경간에 변환 공식을 통해 시간각을 계산하여 방위각과 고도를 계산할 수 있다.
만약 남점 대신 북점을 기준으로 하는 방위각을 계산할려면 계산된 방위각에 180˚을 더하면 되겠다.
4. 지평좌표계에서 적도좌표계로 변환
5. 적도좌표계와 은하좌표계간 변환
은하좌표계는 국제천문협회(IAU)에 1959년에 정의했다. B1950.0의 평균 적도좌표계에서 은하(galactic, Milky Way)의 북극의 좌표는 다음과 같다.
α1950 = 12h49m = 192˚.25, δ1950 = +27˚.4
은하좌표계에서 은경의 기준점(궁수자리 서쪽부근)은 B1950.0 적도좌표계의 적도에서 은하좌표계 승교점(ascending node, 독수지자리 서쪽부근)과 약 33˚ 떨어져 있다.
이 값은 B1950.0 춘분점을 기준으로 정확하게 고정되어 있어 편리하게 사용할 수 있다.
B1950.0을 기준으로 하는 적도좌표계에서 은하좌표계로 변환하는 식은 다음과 같다.
B1950.0을 기준으로 하는 은하좌표계에서 적도좌표계로 변환하는 식은 다음과 같다.
1950.0 기준대신, 2000.0 기준으로 하는 식은 다음에 언급하겠다.
프로그래밍을 통하여 tan에 대한 계산을 할 때 주의할 점은 atan()가 아닌 atan2()를 사용해야한다. 왜냐하면 atan의 결과값은 -90˚~90˚인데 반해, atan2의 결과는 -180˚~180˚이기 때문이다.
천문학에서 천체의 위치를 나타내기 위해서 여러 좌표계(coordinate system)를 사용한다.
대표적인 좌표계로 다음과 같은 것이 있다.
1. 지평좌표계(Horizontal Coordinate System)
지금 내가 서있는 지평면이 기준면이 되고 북점(자전축방향) 또는 남점이 기준점이 되는 좌표계이다. 이 좌표계는 관측자 기준으로 별의 위치를 나타내는데 유용하다. Starpl에서 오른쪽 하단에 마우스를 오버했을때 보여주는 방위각,고도가 바로 이 좌표계에서 나타내는 방식이다.
방위각(azimuth)은 북점 또는 남점에서 시계방향으로 천체의 발까지 잰 각이고
고도(altitude)는 천체의 발로부터 천체까지 잰 각이다.
2. 적도좌표계(Equatorial Coordinate System)
지평좌표계의 한계는 지구위에 관측자가 바라보는 천체의 좌표이므로 지구의 공전과 자전, 그리고 관측자가 어디에 있느냐에 따라 그 위치가 계속 변한다는 단점이 있다. 그래서 고정된 천체(여기서는 항성=별을 의미)의 위치를 나타내기 위한 좌표계가 필요하다. 그것이 바로 적도좌표계이다.
적도좌표계는 지구의 적도를 천구상에 연장한 천구의 적도를 기준면으로 한다. 그리고 춘분점(vernal equinox point)이 기준점이 된다.
적도좌표계에서는 춘분점에서 천구의 적도를 따라 시계반대방향으로 천체의 발까지 잰 각을 적경(right ascension)이고 천체의 발로 부터 천체까지 지구의 자전축을 연장한 천구의 북극을 +방향으로 잰각을 적위(declination) 이라고 한다.
3. 황도좌표계(Ecliptic Coordinate System)
지구를 비롯한 행성은 태양을 중심으로 공전한다. 그래서 행성의 회전에 기준이 되는 좌표계가 필요하다. 그래서 만들어진 것이 바로 황도좌표계이다. 황도좌표계의 기준면은 바로 지구공전면(황도면)이며 기준점은 춘분점이다. 적도좌표계와 약 23.5도 기울어져 있으며 지구중심에서볼때 지심황도좌표계, 태양중심에서 볼때 일심황도좌표계로 분류된다. 춘분점을 기준으로 지구공전방향(황도)를 따라 잰각은 황경(celestial longitude), 천체의 발부터 천체까지 북쪽으로 +, 남쪽으로 -로 잰각을 북 황위(celestial latitude)라고 명한다.
4. 은하좌표계(Galatic Coordinate System)
위 3개의 좌표는 태양계에서 이뤄지는 좌표이다. 그렇기 때문에 은하를 중심으로하는 별들의 위치를 표현하는데는 한계가 있다. 우리 은하면을 기준면으로 하고 은하중심(궁수자리부근)을 기준점으로 하는 은하좌표계는 은하에서의 절대적 위치를 표현하는데 적합하다. 은하의 적도를 따라 시계반대방향으로 은하중심으로부터 천체의 발까지 잰각은 은경(galactic longitude), 천체의 발부터 천체까지 잰각을 은위(galactic latitude) 라고 한다.
은하좌표계는 1959년 국제천문단체(IAU)에서 정의했다. B1950.0 표준 적도좌표계에서 은하 북극(the galactic North Pole)는 적경 192.25도, 적위 +27.4도 이다.
필요에 따라 위의 4개의 좌표계를 서로 변환할 필요가 있다.
가령 서울에서 목성의 위치를 알고 싶을 때는 먼저 황도좌표계에서 목성의 위치를 계산한다음 적도좌표계로 변환한다. 그리고 관측지와 관측시간정보를 이용해 지평좌표계로 변환하면 관측지를 기준으로 목성의 위치가 어디에 있는지 확인할 수 있겠다.
이러한 계산을 하기 위해서 사전에 필요한 지식은 좀 많은 편이긴 하다.
왜냐하면 위 4개의 좌표계를 이해하는 것도 중요하지만 용어에 대한 정확한 이해가 필요하기 때문이다.
한글 에러 : ArgumentError: Error #2180: AVM1 내용(AS1 또는 AS2)이 AVM2(AS3) 내용으로 로드된 경우 AVM1 내용을 displayLis의 다른 부분으로 이동할 수 없습니다."
영문 에러 : ArgumentError: Error #2180: It is illegal to move AVM1 content (AS1 or AS2) to a different part of the displayList when it has been loaded into AVM2 (AS3) content.
위와 같은 에러를 본 적이 있는가?
이것은 Flash Player 9 버전으로 만들어진 애플리케이션에서는 발생하지 않는다. Flash Player 10 버전으로 만들어진 애플리케이션에서 위와 같은 문제가 발생한다.
위 에러가 발생하는 조건은 다음과 같다.
AVM2(ActionScript Virtual Machine 2)기반으로 만들어진 Flash 애플리케이션 AVM2 기반이라는 것은 ActionScript 3.0 기반으로 만들어진 애플리케이션을 의미한다.
Flash Player 10 기반으로 컴파일한다. 컴파일 옵션에서 Flash Player 버전을 9.0.124 등이 아닌 10.0.0을 기반으로 한다.
위 두 조건하에서 AVM1기반으로 만들어진 SWF파일을 flash.display.Loader를 이용해 로드한다. AVM1 기반이라는 것은 ActionScript 1.0 또는 ActionScript 2.0 기반으로 만든 SWF파일을 의미한다.
Loader.contentLoaderInfo.content를 addChild() 한다. Loader는 외부의 이미지, 플래시 파일등을 로드해서 디스플레이 객체로 등록하는 일종의 wrapper역할을 담당한다. 이들을 로드완료하면 Loader.contentLoaderInfo.content에 해당 객체의 참조를 얻을 수 있다. 일반적으로 화면에 출력하기 위해 addChild( Loader ) 식으로 하면 되는데 이렇게 안하고 addChild( Loader.contentLoaderInfo.content ) 를 하는 경우다. 이것이 가능한 이유는 Loader.contentLoaderInfo.content 도 DisplayObject이기 때문이다.
위 조건에 맞춰서 ActionScript 3.0 기반으로 코딩을 아래와 같이 해보겠다.
package
{
import flash.display.DisplayObject;
import flash.display.Loader;
import flash.display.LoaderInfo;
import flash.display.Sprite;
import flash.events.Event;
import flash.net.URLRequest;
public class AVM1LoadTest extends Sprite
{
private var loader:Loader;
public function AVM1LoadTest()
{
loader = new Loader();
loader.contentLoaderInfo.addEventListener(Event.COMPLETE,onLoadComplete);
loader.load( new URLRequest("avm1asset.swf") );
}
private function onLoadComplete( event:Event ):void
{
var loaderInfo:LoaderInfo = event.target as LoaderInfo;
trace( loader.numChildren );
trace( loaderInfo.content.parent );
var avm1asset:DisplayObject = loaderInfo.content;
addChild( avm1asset );
trace( loader.numChildren );
trace( loaderInfo.content.parent );
}
}
}
위 프로그램을 Flash Player 9 버전으로 컴파일하고 실행해보자. (실행되는 Flash Player 버전은 10이어야 한다. 당연히 실험 애플리케이션이 Flash Player 9버전 뿐 아니라 10버전도 만들 것이기 때문이다.)
아래 화면과 같이 AVM1 기반 SWF를 예쁘게 출력해준다.
onLoadComplete() 안을 살펴보면 addChild() 앞뒤로 똑같은 trace()문이 있다. 이것은 addChild() 전후로 loader.numChildren과 loaderInfo.content.parent(이것은 loader.content.parent와 같다)의 변화를 살펴보기 위함이다. loader.numChildren은 Loader 객체에 로드된 AVM1객체가 자식으로 등록되어 있는 경우에는 1이 출력되고 그 반대는 0이 된다. loaderInfo.content.parent는 로드된 AVM1객체의 부모가 무엇인지 가리킨다.
결과는 다음과 같다.
1 [object Loader] 0 [object AVM1LoadTest]
무엇을 의미하는가? addChild()를 하기 전에는 AVM1객체는 Loader의 자식이지만 addChild() 후로는 AVM1LoadTest객체의 자식이 된다. AVM1LoadTest는 위 프로그램의 메인 클래스이다. 이것은 당연한 결과로 자식은 두개 이상의 부모를 가질 수 없는 것을 의미한다. Flash Player 9버전으로 만든 경우에는 이러한 코딩이 가능했다.
조건을 바꿔보자. 이제 위 프로그램을 Flash Player 10 버전으로 컴파일하고 실행해보자. 언급했던 에러가 발생한다.
"ArgumentError: Error #2180: AVM1 내용(AS1 또는 AS2)이 AVM2(AS3) 내용으로 로드된 경우 AVM1 내용을 displayLis의 다른 부분으로 이동할 수 없습니다."
무엇을 의미하는가? Flash Player 10 기반으로 만들어진 애플리케이션은 AVM1 객체를 AVM2 기반의 디스플레이 객체로의 이동을 불허한다. 즉 Loader에서 떠나지 못함을 의미한다.
Flash Player 10기반에서 AVM2 SWF를 로드한 경우는 addChild( loader.contentLoaderInfo.content ) 가 가능할까? 이것은 된다!
Flash Player 10에서 AVM1기반의 SWF는 부모로 Loader이어야만 하는 이유는 무엇일까? 사실 여기에 대한 답변을 나는 아직 찾지 못했다. 혹시 아시는 분은 댓글 및 트랙백을 부탁한다.
일본에서는 이미 이 문제로 고민한 사람이 꽤 있었다. 재미있게도 AVM1을 AVM2로 강제로 바이트 단위로 버전을 수정해 버려 로드해버리는 커스텀 Loader까지 만들어 배포하는 사람이 있었다. 좋은 방법인지는 모르겠지만 아무튼 이런 연구가 활발히 진행되는 일본이 부럽당.. ㅡㅡ
invalid-file
