[WebAppsCon 후기] 리치 웹 기술의 미래 토론(2)  에서 계속...

토론 중 첫 질문 시간에 RIA와 클라이언트 부하에 대한 이슈가 나왔는데요, RIA가 서버 입장에서는 온갖 자원을 클라이언트에게 떠넘김으로써 서버 부하는 줄겠지만 사용자 입장에서는 웹이 더 무거워지는게 아니냐...란 요지의 질문이었던 걸로 기억돼요.

물론 어떤 런타임은 최적화가 되지 않아서 동일한 표현이 다른 기술에 비해 특히 안좋을 수도 있어요. 하지만 웹사이트 부하의 대부분은 너무 많은 수의 이미지 파일과 잘못된 코드에서 기인한다고 생각해요. 그런 점에서 '사용자에게 부하를 떠넘기느냐?'보다는 '사용자에게 더 나은 경험을 제공한다'라는 관점이 더 유효할 것 같네요.

성능적인 관점에서 Silverlight은 로렌스씨의 데모에서도 강조되었지만 특히 미디어를 다루는데 있어서 다른 기술들에게 넘사벽(넘을 수 없는 4차원의 벽)을 선사하며 엄청난 효율을 보여주고 플렉스/플래쉬는 빌드가 swf 단일 파일로 되므로 배포가 용이하고 초기 파싱이나 코드 로딩이 빠른 장점이 있죠.

...그런데, 실제로 써보면 동적으로 XAML을 파싱하는 실버라잇도 별로 느리지 않고 되려 비슷한 수준의 오브젝트 구성이면 실버라잇 로딩이 더 빠르게 느껴지는건 기분탓 만은 아니겠죠? 이 부분은 넘어가구요.

여하튼 뭐 누가 좋네 나쁘네 얘기가 중요한게 아닌데 한가지, 어도비측 패널에선 매우 부적절한 예시를 든 것 같아요.

어떤 영화 사이트에서 이벤트 당첨자 몇명? 천명이었나 만명었나를 한 페이지에 게시를 했다가 웹사이트가 다운되었다...는 건데요. 이거야 말로 전형적으로 잘못된 코드 사용으로 인한 문제 아닐까 싶어요.

이 케이스에서 만명이라고 치고, 이 정도 숫자의 목록을 한 화면에 표시한다는 것 자체가 잘못된거죠. 당연히 검색기능을 넣든 페이징을 하는 것이 정답이죠.

설사 이걸 플래쉬든 뭐든 컴파일된 작은 용량으로 만들었고 이것이 한 화면에 아주 문제 없이 잘 나타났다고 해도 그건 잘못된 구성일 거에요.

예시는 별로 적절하지 않았지만 어쨌든 swf의 압축으로 인한 장점을 얘기한 것 같구요, 실버라잇은 swf에 비해 다소 복잡한 구성을 이루지만 개별 리소스의 관리 측면에서는 더 효과적이라고 생각해요. 게다가 실버라잇은 Downloader를 통한 ZIP 패키지도 지원하고 있으니 트래픽을 줄이는 방법도 제공하고 있구요.

RIA 기술들 간의 성능 비교는 http://bubblemark.com/ 이쪽을 참고해보세요.


토론의 마지막 질문은 바로, 거금 2만 2천원을 아낄 수 있게 한 댓글 이벤트에서 나온 그것! 히힛.

원래 제가 올렸던 질문은 좀 Silverlight에 치우친 거였는데 진행하시는 분께서 아주 적절하게 가공하셔서 질문의 수준마저 높아진 느낌이었죠.

질문의 요는, 적절한 보안 통제속에 사용할 수 있는 로컬 스토리지의 활용성과 향후 계획에 관한 것이었구요. 답은 약간은 뻔한 거였죠.

실버라잇은 '향후' 이러한 지원을 per Application, per Domain, per Service등 다양한 모델로 지원할 수 있을 것이라는 다소 희망적인 그러나 피상적인 답변이었고, 어도비쪽은 역시 기억에 안남고, OpenLaszlo쪽은 당연히 표준에서 제공하지 않는 기능이니 불가능이겠고요.

좀 더 덧붙이자면, 실버라잇은 웹 애플리케이션이 로컬의 암시적인 장소에 생성된 스토리지에 접근하여 기록하고 읽을 수 있는 IsolatedStorage를 지원하고 있어요. '암시적'이란 것은 이 스토리지(폴더)의 물리적 위치는 알 수 없고 단지 참조만 가능하며 상위 폴더로 올라가는 것도 불가능한, 그야말로 '격리된' 공간이죠.

어떻게 보면 쿠키의 확장인데요, 쿠키의 보안 이슈와 마찬가지로 당연히 로컬로 저장되는 내용에 보안에 영향을 주는 정보를 넣어선 안되겠죠. 제 생각엔 갈 수록 대용량화 되는 웹 사이트의 리소스를 보다 넓은 범위에서 캐슁하기 위한 용도로 좋을 것 같아요. 그러나 실버라잇은 아직 per Application 즉, 한 실버라잇 페이지 당 하나의 스토리지가 생성되어서 같은 서비스끼리 서로 그 스토리지를 공유할 수 가 없어서 비효율적이에요. 뭐 앞으론 더 넓은 범위의 지원을 한다니까 기다려 봐야죠.

또 MS의 황리건님과의 대화에서 알게 되었는데, 플래쉬의 경우는 Shared file(?? 이름은 정확히 기억 안납니다) 기능이 있는데 플래쉬가 설치된 경로에 각 도메인별 또는 애플리케이션별로 지정된 암호화된 파일 스토리지를 지원한다는군요.

여하튼, 현재로서는 커다랗고 많은 수의 미디어 파일(이미지, 음악, 동영상)의 캐슁은 순전히 브라우저의 캐슁 기능에 의존하는데 따라서 브라우저 별로, 그리고 시스템 환경에 따라 대용량 미디어가 많은 페이지의 표시 효율이 다르겠죠.

이런 점에서 각 애플리케이션이 보안 이슈에 독립적으로 사용할 수 있는 공간은 보다 안정적이고 효율적인 캐슁에 많은 도움이 되리라 생각해봅니다.


시간이 빡빡해서 정신 없이 돌아갔던 것 같네요. 한꺼번에 너무 많은 걸 준비하다 보니 그런 것 같아요. 남은 컨퍼런스들은 더 이상 집중하기 힘들 것 같아서 집에 왔습니다.

꽤 길게 후기를 썼지만 이번 컨퍼런스에서 가장 인상 깊었던 건 OpenLaszlo 프로젝트. 로 요약할 수 있겠네요;
나중에 Raju씨의 발표내용이 올라온다면 꼭 한번 보시길 권장해요!
신고
Posted by gongdo
워크샵이 끝난 후 점심을 외로이 먹어치우고 근처를 서성거리다가 아케이드에서 무시무시한 실력으로 하우스오브데드4를 플레이하는 분도 구경하고 옆 동네 SEK2007에도 들렀다가 하면서 빈둥빈동 시간을 보내고 왔는데도 아직 로렌스씨의 발표가 안끝났더군요.

그 전의 발표는 별로 흥미가 없어서 패스. 로렌스씨의 발표도 벌써 세번째 보는거라 패스.

이어 토론회는 리치 웹 기술의 미래...란 타이틀로 MS, Adobe, OpenLaszlo에서 오신 패널과 함께 진행되었습니다.

이 토론회는 무려 2만 2천원이란 거금의 참가비를 아낄 수 있는 이벤트에 선정되게된 바로 그것이라 놓칠 수가 없죠!

여기서 매우 흥미로운 관점의 변화를 관찰 할 수 있었어요.

원래 MS는 데스크탑 애플리케이션 플랫폼의 제왕이고 어도비는 웹 애플리케이션 플랫폼의 제왕이죠. 전통적으로 MS는 웹 기술에 취약하다란 평가가 많았고 어도비는 데스크탑 시장은 애초에 발도 못내미는 실정이었구요.

그런데!?

MS는 자꾸 웹 기술로의 새로운 시도와 역량을 강화하고 있는 반면, 어도비는 데스크탑 애플리케이션으로의 지향을 보여주고 있어요.

MS가 최근 들어 집중하고 있는 걸 보면, Live.com, ASP.NET AJAX, W2k8 Server & 혁신된 IIS7, Silverlight... 이제는 웹 플랫폼마져 집어 삼키겠다는 거대한 음모(?)가 도사리고 있죠. 특히 WPF가 전통적인 MS의 기술처럼 윈도우즈 온리의 .NET Framework 3.0 기반에서 동작하고 웹브라우저에서 돌리는 XBAP도 마찬가지인 반면, Silverlight을 보면 예전 MS의 정책에서는 상상도 할 수 없었던 크로스 플랫폼과 브라우저 지원으로 무장한데다가 다시는 ActiveX의 전철을 밟지 않겠다는 듯이 보안관련 기술들(크로스 도메인 접근, 로컬 자원 접근 등) 결연하게 사용할 수 없게 만들었죠.

그런데, 어도비가 최근 발표한 AIR는 기본적으로 Flash9에 기반하고 있는 만큼 크로스 플랫폼/브라우저를 지원하지만 내부적으로 OS-Dependency API를 지원한다고 합니다.
즉, 개발 옵션에 따라 특정 OS에 종속되는 애플리케이션으로도 빌드가 가능하다는 것이고 당연히 로컬 자원으로의 접근도 허용되는 거죠. -물론 Silverlight의 웹 애플리케이션과 AIR의 데스크탑 애플리케이션은 비교 대상이 아니라는 것은 알고 있지만요-

게다가, MS 측의 발표 내용은 WEB 2.0, Beyond the WEB, 뭐라고 부르던간에 플랫폼으로써의 웹 브라우저의 가능성을 인정하고 그것을 지원하기 위한 기술을 내세우고 있다는 인상을 받았지만 어도비 측의 발표에서는 웹 표준의 문제, 성능의 문제, 자원 접근성의 한계로 결국 데스크탑 애플리케이션으로 방향을 선회한 느낌이었어요.

이거 혹시 회사가 바뀐거 아냐? 싶을 정도의 관점 변화에요.

특히 RIA를 표방하는 많은 기술과 플랫폼의 난립에 대해 MS는 '상관 없다. 현재의 RIA는 아직 표준화로 정립되기엔 무리가 있는 역동의 시기이고 따라서 당장은 벤더에 의존적이지만 대신 빠르게 변화의 니즈를 피드백할 수 있는게 중요하다.'라는 MS다운 자신감을 드러냈고 OpenLaszlo에서는 기술에 있어서 표준의 중요성에 대해 완고한 관점을 드러냈는데, 어도비쪽의 관점은 기억에 안남아 있네요. 뭐랄까 그만큼 인상적인 비전을 보이진 못했다는 거죠.

조금 성급하게 MS의 전략을 추측해보자면 MS의 거대한 장점, 바로 데스크탑 플랫폼 장악과 함께 전방위 제품군간 연동이 가능한 엄청난 스펙트럼을 십분 활용해서 웹 개발 툴을 장악하고 그러면 자연스레 웹 플랫폼 자체를 장악할 수 있을 것이며, 이를 바탕으로 앞으로 다가올 표준화에 강력한 영향력을 행사하는 것이 아닐까요?

여하튼, 현재 RIA는 기술적으로 정립되지 않았고 각 벤더는 치열하게 각축전을 벌이겠죠.
그리고 그 틈바구니에서 개발자들은 죽어나가겠지만, 한가지 희망적인건 각 기술들의 큰 틀은 별로 달라보이지 않아요. 대체로 프리젠테이션은 XML에 기반한 마크업 랭귀지이고 XML 특성상 이름만 보면 대략 뭘 하려는 건지 쉽게 이해할 수 있잖아요?
 
그리고 로직영역은 기본적으로 JavaScript나 ECMAScript(같다고 보셔도 무방)를 통해 웹에 전달될 수 있죠. 그리고 벤더 별로는 Silverlight은 CLR환경으로 컴파일된 DLL과 XAML을 분리한 모델을, FLEX는 SWF로 컴파일된 단일 배포 모델을 선택했구요.

요는 자신이 어떤 기술이 더 익숙하느냐인 것 같네요. 제 경우는 VB6를 깊게 다뤘는데 JavaScript보다는 C#에 쉽게 접근할 수 있었던 것 처럼 말이죠.

하지만 이 와중에 Silverlight에, MS의 비전에 깊게 공감할 수 밖에 없는건 'MS의 기술은 개발자의 커리어와 로드맵을 고려한다'는 점이에요. 무슨 얘기냐면, Silverlight이든 뭐든 MS의 기술들은 .NET Framework 이라는 커다란 프레임웍 안에 통합되어 가고 있어요. 특히 3.0의 발표 이후로 이러한 통합은 더욱 가속화 되고 있고 새로운 MS의 기술을 접했을 때 개발자는 특별한 배경 지식 없이도 기존의 개발 지식을 고스란히 적용해볼 수 있는 환경이 마련되었다는 거죠. 즉, 유저 뿐만 아니라 개발자의 경험도 배려하는 정책이란 거죠. (DX라고 불러야할까요? ^^)

저는 플래쉬에 대해 전혀라고 말해도 좋을 정도로 지식이 없기 때문에 잘못 생각하고 있을 지 모르겠지만, 평소에 액션 스크립트의 악명(?)이랄까 원성이 자자한걸 봐와서 플래쉬쪽은 손도대고 싶지 않아요. 왜냐면 위와 관련해서, 만약 액션 스크립트를 삽질 끝에 손에 익혔다고 해도 플래쉬 외에 써먹을 데가 없잖아요? 개발자로서 이렇게 허무한 경험은 하고 싶지 않죠.(죽은 자식이 된 VB6를 생각하면 안습이에요)

계속...
신고
Posted by gongdo
비도 시원~하게 내리는 오늘, 웹앱스콘에 다녀왔습니다.
원래 비전 나잇까지 가서 뭔가 사람도 좀 만나보고 싶었는데, 저에겐 다행하게도 MS의 황리건님과 김국현님과 잠깐이나마 인사하고 대화를 할 수 있어서 다른건 가볍게 포기하고 집에왔네요. 스프링노트는 관심있었는데 그것까지 듣고 올걸 하는 후회도 쬐끔...

방금전까지 담소(?)를 나누다 온 황리건님께는 연이어 아픈 얘기지만 실버라잇이 준비가 제일 부족해보였어요 ㅠ.ㅜ 물론 오늘 발표된 기술들 중에서 베타 심지어 알파딱지도 아직 떼지 못한 것이기도 하지만요.

실버라잇에 집중하고 있으니 좀 더 자세히 얘기해보자면 실버라잇이 관심을 못받는 가장 큰 이유는 아마도 디자이너의 저변 부족이 아닐까 생각해봅니다. 두번째 세션인 쇼핑몰 예에서도 아주 적절하게 짚어 주셨듯이 Rich한 사용자 인터페이스는 XHR도 벡터 그래픽도 프로그래머빌리티도 아닌 단지 버튼아래 적절한 그림자 표현이 더 크게 다가온다는 점이에요.

무슨 얘기냐면 제 아무리 훌륭하고 멋드러진 기능으로 무장하더라도 디자인 감각 없는 개발자가 그걸 활용해봤자 일반 사용자에겐 아무런 감성도 전달할 수 없다는 것이고 RIA의 구현에서 가장 핵심적인 것은 아주 기초적인 디자인, 나아가 사용자가 쉽게 접근할 수 있는 인터페이스가 아닐까요?

다음으로 개발적인 측면에서 아직 공식 버전이 런칭되지 않았기 때문이겠죠. 프로덕션을 위한 런타임에 'Beta' 'Alpha'가 뜨는건 일반 유저에게 썩 기분좋은 일이 아닐거에요. 이것만으로도 큰 감점요인이죠. 물론 1.0 Beta는 올여름 느즈막히 공식 버전으로 런칭한다고 하지만, 1.1 Alpha는 연말로 미뤄진 것 같네요. 사실 개발자로써 1.0 Beta, JavaScript버전은 별 활용가치가 없다고 생각해요. 실버라잇의 진짜 위력은 1.1 Alpha, CLR 버전에 있고 실제 실버라잇 코드 작성에 있어서 JavaScript 개발 환경이 CLR 혹은 DLR 개발환경보다 우위에 있는 점이라곤 눈꼽만큼도 없다고 장담할 수 있어요. 이 얘긴 나중에 따로 하기로 하죠.

다음 세션으로 쇼핑몰 구축 사례인데요, 집에 와서 좀 둘러봤지만 사이트 자체는 썩 마음에 들진 않지만 개발 사례와 경험 그리고 사이트 구축에 대한 식견은 만점을 줄 수 있어요.

사이트 자체에 높은 평가를 못내리는 가장 큰 이유는! 일단 접속하자마자 반겨주는 '오류가 있습니다. 디버그 하시겠습니까?' 메시지. 아마 어도비 쪽 기술을 사용하는 웹 개발자들은 비주얼 스튜디오를 사용하지 않으시겠지만 비주얼 스튜디오 사용자들은 자바스크립 오류가 있는 사이트를 무지 싫어해요. 편집증 말기의 과민성 환자인 디버거가 사소한 오류에도 반응하거든요. 실수로라도 '예'를 눌렀다간 한참동안 디버거 띄우고 취소하고 어쩌고 짜증이 밀려오죠.

뭐 그래봤자 이런 개발자는 애초에 고객으로도 무시당할 만한 한국 최악의 계층이니까 상관 없겠지만(하아... 이런 말에 일일이 농담이에요~^^* 이렇게 쓰지 않아도 되면 좋겠습니다) 제 취향에도 좀 안맞는거라 별로 좋아보이지가 않았어요. 그래봤자 이것도 '개편후 매출이 늘었습니다!'란 한마디에 그냥 제 취향이 이상한게 되는거죠.

이게 중요한게 아니고 쇼핑몰 사례의 핵심은 RIA RIA 입으로만 떠들어봤자 고객들에겐 아무런 영향이 없고, 기존사이트와 99.9% 똑같은 구성을 하더라도 버튼 하나, 장면 전환 하나하나에 새로운 기술들을 도입해 나가는게 보다 고객에게 어필할 수 있다는 점이죠.

그런 자연스러운 기술 전환에 대해서는 좋은 평가를 받을만 한 것 같아요.


마지막 세션인 Raju Bitter씨의 OpenLaszlo는 정말 정말 정말 정말 정말 정말 정말 x 100 훌륭했어요.
아니 여태 이런걸 모르고 있었지? 란 생각이 머리속을 가득 채우네요.
사실 AJAX도 기술적인 관점에서는 그야말로 역사에 남을 뒷북이었는데 OpenLaszlo를 여태 몰랐다는게 엄청나게 부끄러워요. 아 어디가서 RIA니 웹 2.0이니 안다고 나불거리지 말아야지;;;

우선 링크부터 갑니다.
http://www.openlaszlo.org/

RIA, WEB 2.0 이딴거 다 집어치우고 웹쪽에 관심있다고 하시는 분은 무조건 들어가서 20분만 둘러보세요. 아 이래서 영어를 잘해야 하는데... ㅠ.ㅜ

그 중에서도 제가 얘기하고 싶은, 또 지향하는 핵심 구현 사례는 바로 이것.
http://www.click-shirt.com/

진짜 사용자 친화적인, 쉬운, 직관적인, 그러면서도 Rich한 UX가 무엇인가를 단 세페이지로 '구현'하고 있습니다.

Raju씨도 중간에 언급했지만 컴퓨터에 대한 지식이 없는 사용자들은 화면 전환이 일어나면 쉽게 내비게이팅을 하지 못한다는 점, 화면에 어떤게 메뉴고 어떤게 무슨일을 하는지 파악하는데 시간이 많이 걸린 다는 점을 잘 고려해야 합니다.

언제까지나 '국내 정서에는 안맞다' 라고 틀에 박힌 포털식 사이트만 만드는게 능사가 아니란거에요. 또 앞으로 다가올 IPTV시대, 즉 리모콘으로 조작하는 웹에 대한 비전도 좀 더 현실적으로 다가오고 있구요.

물론 이 데모는 단지 티셔츠라는 단순한 컨텐트만을 표현하는 게 전부지만, 초기 화면은 포털식 구성을 하더라도 개별 상품 카테고리 내에서는 이런 식의 직관적인 인터페이스로 구현하는게 어떨까 생각해봅니다.

제가 잘 이해하고 있는건지 확신이 안가지만, OpenLaszlo는 XML기반의 마크업과 ECMAScript(Javascript의 기초 언어) 문법으로 작성되어 이것을 컴파일하면 옵션에 따라 Flash 7, 8, 9 또는 DHTML로 결과물이 빌드되는 아키텍쳐를 가지고 있어요.

OpenLaszlo의 사용 편의성이나 개발자 지원, 도큐멘팅 이런걸 떠나서 이러한 중간언어적인 시도는 웹 표준화에 크게 기여하면서도 동시에 개발 플랫폼의 다양성도 양립할 수 있는 가능성을 보여준다는 점에 가장 높은 점수를 주고 싶어요.

이와 관련해서, .NET Framework는 애초에 개발 랭귀지에 관계없이 중간 언어로 컴파일한 뒤 .NET 런타임하에서 평등하게 실행되는 개념인데 바로 이런 개념과도 유사하다고 볼 수 있겠죠.

다시 실버라잇으로 돌아와서, 제가 Silverlight 1.1 alpha를 보고 턱 빠지게 놀랐던 건 CLR환경 뿐만 아니라 DLR이라는 이름으로 다른 언어들까지도 지원을 할 수 있는 가능성을 열어둔 점이었어요. 대표적으로 JScript, 파이썬.

실버라잇 1.1이 애초에 이러한 멀티 랭귀지 환경을 고려하고 있는 만큼 경우에 따라선 OpenLaszlo의 컴파일 결과물이 Silverlight이 될 수도 있겠고 반대로 Silverlight에서 OpenLaszlo의 문법을 수용하는 중간 언어가 만들어 질 가능성도 있다는 거죠. 물론 이런 가능성은 정치적인 이유로 성사되지 않을 가능성도 농후하지만요.

과장해서 말하자면, 프로그래밍 랭귀지간 매쉬업까지도 생각해 볼 수 있다는 거에요!

OpenLaszlo는 그 역사에 비해 오랫동안 몰랐다가 처음 접한 것도 있고 해서 약간은 흥분 상태에서 포스팅을 해서 오바가 심하긴 하지만, 웹의 미래에 대해 상당히 의미있는 생각들을 제게 던져준 것 같아요.

포스팅이 길어진데다가 컨퍼런스 내용과 겹쳐서 다음 글에 계속...
신고
Posted by gongdo


티스토리 툴바