Skip to content →

Silverlight 1.0: Getting Started

갑자기 자다 깨는 바람에, DDJ의 지난 10월 기사인 Silverlight 1.0: Getting Started을 읽었다.

이 기사는 Silverlight의 소위 Hello, World를 수행하기 위한 과정을 설명하고 있는데, 쓸데없이 장황한 면이 있다. Microsoft가 제공하는 Silverlight 1.0 Quickstarts를 읽는 것이 나아보인다. 요점은 Silverlight 플러그인을 HTML 내에 삽입하기 위해서는 OBJECT나 EMBED/NOEMBED element를 사용하지말고, Silverlight SDK에서 제공되는 javascript(Silverlight.js)를 사용해야한다는 것이다.

한편, 요샌 RIA 기술에 별로 신경을 쓰지못해서 깨닫지 못하고 있었는데, Microsoft의 SilverlightXAML + Javascript(+.NET languages) 기술, Adobe의 FlexMXML + Actionscript 기술이 SDK와 다른 SDK들로부터의 지원, 개발 도구, 미디어 기술 등과 함께 포장되어나온 것이다. 오래 전에 강문식 군이 XAML을 가지고 놀던 기억이 난다.

Silverlight든 Flex든 XAML/MXML+Javascript/Actionscript의 장점을 고스란히 지니게 된다. 별다른 개발 도구 없이도 서버사이드에서 텍스트 파일을 살짝 수정하는 것만으로도 바로 브라우저에 UI 변경사항이 반영된다는 것이다. 기존의 RIA 기술인 ActiveX나 Flash와 비교해보면 RIA 개발 효율이 상당히 높아질 수 있을 것같다. C로 CGI를 만들던 시절과 Perl/PHP로 Web App을 개발하는 현재를 비교해보면 말이다. Web App을 만들 일이 생긴다면 한번 시도해보고 싶다.

섣불리 얘기하기는 꺼려지지만, XAML/MXML+Javascript/Actionscript들을 서버사이드에 두고 HTTP 프로토콜로 접근한다면, 이들의 용도는 한정될 수 밖에 없는 것 같다. 이를테면 중요한 비즈니스 제약들을 여기에(만) 넣을 수는 없다는 것이다. – 예전에 Flex Architecture를 흘끗 본 기억으로는 서버사이드에서 실행되는 컴포넌트 기술도 포함하고 있었던 것 같고, Silverlight를 아우르는 ASP.NET도 당연히 그러한 기술을 포함하고 있겠지만, 여기서는 Silverlight와 Flex의 핵심 기술들만 얘기하자. – 하지만, 궁극적으로는 클라이언트 상에서 동작하는 RIA 기술 자체가 그런 문제를 가지고 있는 것이지 이 기술들이 가지고 있다고 볼 수는 없는 것 같다. 실질적으로도 (적어도 현재는) RIA 기술들은 주로 Presentation 위주로 사용되며, 중요한 트랜잭션 (이를테면 신용카드 결제) 들은 다른 방법으로 (예를 들어, 서버사이드에서 실행되는 로직) 해결하는 것이 일반적인 상황인 것 같다. 다시 말하면, RIA 기술은 Presentation 위주로 사용하고, 중요한 비즈니스 로직은 서버사이드에서 실행하는 식으로 이러한 문제는 해결되고 있는 것 같다. 다른 해결책도 물론 있다. 정말 필요하다면 암호화와 신뢰를 보장하기 위한 보안 모델을 사용할 수도 있다. 이 방법 역시 ActiveX에서 사용하고 있는 것이다 (ActiveX의 인증서!). 하지만, 사람들은(개발자든 사용자든) 보안으로 인한 비용들(귀찮음이든 개발 비용이든)을 별로 좋아하지 않는다는 것이 이 방법의 문제점이다.

잡설이 길었다. RIA 기술들의 실제적인 필요성은 점점 부각되고 있다. Microsoft와 Adobe가 열정적으로 RIA 기술을 지원하고 있으며, 특정 부문에서 이들을 대체할만한 기술 (e.g. HTML 5)이 단기간 내 – 3년 내에 – 나오기는 하더라도 – 성숙하기는 힘들지 않을까 예상된다. 이런 환경에서 RIA와 관련이 없는 개발자라고 하더라도 Silverlight 또는 Flex는 한번쯤 주목해볼만한 기술일 것이다. 과연, 어느 쪽이 주도권을 잡을 것인가? 어쩌면 HTML 4일지도. 후훗.

부록 1: Silverlight는 Microsoft의 구현 만 있는 것이 아니라 Mono 팀의 구현인 Moonlight도 있다.

부록 2: XML의 응용인 XAML보다 IronRuby를 이용한 Silverlight DSL이 훨씬 읽기편하고 예뻐보인다. 인간이 읽고 써야하는 선언적 코드(e.g. Configuration, Markup, Schema, …)에서 XML보다는 Agile 계열의 언어를 활용한 DSL을 사용하는 프랙티스들이 요즘 많이 나오고 있다. 아직은 실험적인 단계라고 해야겠지만, 내겐 긍정적으로 보인다.

Published in Software Development

Comments

    답글 남기기

    이메일 주소는 공개되지 않습니다. 필수 항목은 *(으)로 표시합니다

    이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.