영욱닷컴(http://youngwook.com)

WPF와 Silverlight와 같은 UX기술들을 이야기 하다 보면 아래와 같은 질문들을 많이 받게 됩니다.

"저희는 디자이너가 없어요"
"저희 회사에서 원하는 것은 화려한 UI가 아니라 미려한 UI에요"

일반적인 회사에서 소위 말하는 전사 시스템 혹은 업무 시스템이라고 부르는 Application들은 대부분 화려한 UI와는 상관없는 시스템이 많습니다. 오히려 그 반대로 지나치게 화려하고 역동적인 UI가 사용자의 편의성과 데이터에 대한 접근을 방해하기 까지 하는 경우도 있습니다.

절제된 UI를 제공과 디자이너가 없는 환경의 개발자들은 WPF가 가지고 있는 장점을 활용하기 위해서 다각도로 고민하고 있는 모습들을 보여주고 있습니다. 그런 시도중에 하나가 바로 WPF Themes pack 입니다. WPF themes pack은 대표적인 오픈소스 사이트인 codeplex에서 진행되고 있는 오픈 소스중에 하나 입니다.

다양한 스킨의 테마가 제공되고 있으며 소스도 받아보면 간단하기 때문에 쉽게 실 프로젝트에 적용할 수 있습니다. 관련된 내용은 http://blogs.msdn.com/jaimer/archive/2008/11/12/eight-wpf-themes-released.aspx 에서 보실 수 있습니다.

지금은 총 12가지의 스킨이 제공되고 있습니다. 특히 몇 몇 스킨은 상당히 특이한 모습을 보여주고 있습니다. ^^

김영욱 iwinkey@hotmail.com: 국내 유수의 대기업 프로젝트에 참여했던 풍부한 경험과 마이크로소프트 MVP로서 다양한 활동을 바탕으로 WPF 및 Silverlight와 같은 UX 기술에 전념하고 있다. 현재 한국 마이크로소프트에서 개발 전도사로 활발히 활동하고 있다.

라디오가 제일 처음 출현했을 때 세상은 깜짝 놀라면서 세상이 라디오를 통해서 바뀔 것이라고 생각했다. 그리고 TV가 나왔을 때 세상은 TV로 인해서 크게 바뀔 것이라고 주장하기 시작했고 이런 현상은 컴퓨터의 등장과 인터넷의 등장에도 불구하고 계속해서 사람들은 그것들이 세상을 바꿀 것이라고 주장했지만 지금 우리 주위를 돌아보면 라디오, TV, 컴퓨터, 그리고 인터넷까지 어느것 하나 사라지거나 하지 않고 각각 다 자기 영역을 지켜면서 잘 살아있는 것을 볼 수 있다.

진화와 공존을 거듭하는 클라이언트 기술

옛날 ‘별이 빛나는 밤에’와 같은 한 밤중의 음악 프로그램에 청취자가 참여하기 위한 유일한 방법은 우편엽서를 최대한 예쁘게 꾸며서 보내는 방법이었다. 하지만 요즈음은 인터넷 게시판과 핸드폰의 문자 메시지를 통해서 참여할 수 있고 더 나아가서 인터넷과 연계해서 보이는 라디오까지 출현하고 있는 것을 보면 이전의 라디오와는 많이 다르다는 생각을 누구나 할 수 있게 된다.

소프트웨어도 이전의 환경과 더불어 많은 변화가 있었지만 이전의 기술들과 현재의 기술이 공존하고 있고 공존하기만 하는 것이 아니라 서로 서로 영향을 끼치면서 단단하거나 느슨한 기술의 고리를 가지고 연결되어 있다. 이전의 환경은 단순히 비지니스 모델을 파일 시스템으로 표현했다. 이 시기에는 파일 시스템이 곧 비지니스 모델의 추상화 였다. 물론 이 시기의 비지니스 모델은 단순하기도 했지만 사람들은 IT를 적극적인 비지니스의 도구로 생각하지는 못했고 단순히 자료의 축척이라는 개념에서 크게 벗어나지 못하고 있었기 때문에 이런 모델이 잘 소화해 낼 수 있었다. 하지만 비지니스 모델은 정적인 모델에서 가변적이고 변화의 시기가 짧은 모델로 변화하고 있었고 이 때문에 정적인 데이터 구조를 벗어나지 못하고 있는 파일 시스템의 모델로는 금방 한계에 다다를 수 밖에 없었다.

이때 문제의 해결책은 비지니스 모델과 데이터의 분리였고 이와 더불어 데이터베이스가 출현했다. 좀더 개념이 발전하면서 비지니스 모델을 잘 표현하기 위해서 N-Tier와 같은 아키텍쳐가 잘 자리잡기 시작했고 위치의 제약을 벗어나기 위해서 웹이 도입되기 시작했다. 크게 생각해보면 데이터베이스와 N-Tier 구조가 정의되어 있는(혹은 유사한 형태의) 구조를 서비스라고 정의하고 이 서비스를 웹으로 노출 시키기 위해서 웹 서버와 파이프 라인으로 연결한 구조가 현재 가장 전형적인 아키텍쳐 구조라고 이야기 할 수 있다. 물론 그렇지 않는 단순한 서비스도 다수 존재하겠지만 여기서는 일반적인 엔터프라이즈 환경을 기준으로 생각해 볼 때 그렇게 정의할 수 있겠다.

서비스가 웹이든 혹은 로컬 네트워을 통하든 어떠한 방법으로 노출이 될 때 이 서버스를 사용자들이 이용할 수 있게 주는 것이 바로 클라이언트이다. 클라이언트를 설명하기 위해서 서비스 구조를 먼저 설명한 것도 서비스에 따라서 클라이언트가 달라지기 때문이다.

<그림1> 현재 아키텍쳐의 전형

클라이언트 역시 터미 터미널의 문자 위주의 클라이언트 환경에서 부터 DOS기반을 거쳐서 매킨토시나 원도우즈 환경으로 넘어오면서 GUI로 넘어오게 되었다. GUI 환경에서는 주로 델파이, 파워빌더, 비주얼 베이직과 같은 걸출한 개발툴 들이 태동하던 시기였다. 사실 필자도 이 시기에 IT에 입문해서 비주얼 베이직 3.0 혹은 터보C이런 언어로 컴퓨터의 기초를 배웠다. 그리고 얼마 지나지 않아서 웹이라는 거센 물결이 흘러왔고 웹이 모든 클라이언트의 표준이 되었다. 모든 것이 웹 브라우저를 통해서 다 해결될 것만 같았고 모든 시스템을 웹 브라우저 기반으로 마이그레이션 하지 않으면 안될 것 같은 생각들을 했다.

하지만 웹 브라우저를 이용해서 접근할 수 있는 서비스나 시스템이 폭팔적으로 늘어나기는 했지만 이는 시장의 팽창을 불러왔을 뿐 기존의 클라이언트 기술의 종말을 의미한 것은 아니다. 오히려 기존의 클라이언트는 웹 프로토콜인 HTTP를 사용해서 네트웍을 할 수 있도록 발전했을 뿐 아니라 웹 환경 보다 더 나은 인터페이스를 제공하기 시작했다. 웹 브라우저 기반의 서비스는 접근성 면에서는 향상되었지만 기본적으로 보안 및 대량의 데이터를 다루는 클라이언트로는 기본적으로 적합하지 않았으며 또 인터페이스만 하더라도 기존의 클라이언트 기술에 비해서 많이 불편한 것도 분명한 사실이었다.

웹 브라우저의 접근성과 더불어 응용프로그램으로 구성된 기존의 클라이언트 기술의 편리함을 동시에 제공하려고 했던 시도가 바로 ActiveX 기술이다. ActiveX기술은 웹 브라우저를 통해서 다운로드 받아서 웹 브라우저 안에서 실행되는 구조로 보이지만 사실은 웹 브라우저와는 별도로 클라이언트에서 실행되는 하나의 응용프로그램과 같은 형태로 실행되기 때문에 인터페이스 및 대용량의 데이터 그리고 복잡한 알고리즘의 구현등에 있어서 꼭 필요한 기술이 되었다.

한 동안 많이 나왔던 솔류션이 바로 X internet 솔류션이다. 기존의 표준적인 웹의 단점을 해결하기 위해서 주로 나온 솔류션들이 바로 X internet 솔류션인데 대부분의 경우 그 속을 열어보면 ActiveX로 구성된 클라이언트를 제공하고 서버쪽에 미들웨어를 구성한 경우가 대부분 이었다.

RIA기술의 출현

웹 브라우저와 클라이언트 응용 프로그램으로 양분된 시장의 틈세에 웹에서 실행되는 별도의 플랫폼 기술이 나타나게 되었데 이 기술을 RIA라고 부르는 것이 일반화 되었다. RIA는 Rich Internet Application혹은 Rich Interactive Application의 약자로 부르는데 둘 다 Rich라는 단어가 중요하다. Rich의 의미는 기존에 HTML기반의 표준적인 웹에 비해서는 풍부하고 멋진 인터페이스를 제공한다는 의미에서 사용하고 있는 단어이다.

RIA와 관련해서 시장에 많은 영향을 끼친 것은 Macromedia사의 Flash기반의 기술이었다. Flash는 지금도 많은 부분에서 사용되고 있으며 Flash와 Flex, 그리고 Air 기술로 계속해서 수평적으로 확장하고 있다. 최근에는 이 분야에 MS에서도 실버라이트라는 RIA기술을 제공하고 있으며 실버라이트 2가 정식으로 런칭하면서 국내 대기업들과 언론사 그리고 포탈에서 채용되는등 가속도가 붙고 있다.

<그림2> 클라이언트 아키텍쳐

어찌되었던 현재는 <그림2>에서 보는 바와 같이 클라이언트 아키텍쳐를 3개층으로 나누어서 분류하게 되었다. 일반적인 웹 인터페이스와 RIA 그리고 클라이언트 응용 프로그램이 바로 그것이다. 이전에는 기술이 사용자들을 시장에서 리드해 나갔지만 요즘은 확연히 사용자들이 기술을 리드해 나가는 시장으로 바뀌었다. 클라이언트 아키텍쳐의 모양이 3개층으로 분류되어 있기는 하지만 이는 분류를 위한 구분일 뿐 사용자들은 각 층을 넘나드는 요구사항을 내놓는게 일반화 되었다. 따라서 이를 수용하기 위한 기술적인 유연함이 필요하다.

요구사항에 맞는 클라이언트 기술의 선택이 관건

국내에서 다수의 프로젝트를 수행하다 보면 잘못된 분석에 의해서 모든 요구사항을 웹 브라우저 기반의 클라이언트 기술로 해결하려는 경우를 다수 보게 되는데 이것은 상당히 위험한 생각이다. 최근에는 Flash기반이나 실버라이트 기반의 RIA기술로 우선 선택하려는 경우도 종종 있는데 이 역시 위험한 발상이라고 볼 수 있다. 그 이유는 웹이라는 환경은 기본적으로 텍스트 기반의 전송을 통해서 상호 운영성을 극대화하는데 그 목적이 있는 것이지 모든 요구사항을 고려해서 나온 아키텍처가 아니기 때문이다. 또 RIA기술의 경우 웹 브라우저 안에서 메모리를 할당 받고 프로세스를 할당 받기 때문에 일반적인 클라이언트 응용 프로그램에 비해서는 성능 및 사용할 수 있는 데이터 양에 있어서 다수의 제약이 뒤따를 수 밖에 없다. 또한 사용자들의 증가하는 요구사항을 수용하기 위해서 클라이언트의 자원에 접근에도 한계가 있다는 점은 상당히 치명적인 부분이다. 국내 모 대기업에서 내부 시스템을 Flex기반으로 구축했다가 최근에 닷넷 기반의 클라이언트 응용 프로그램으로 되돌리는 사례가 있었는데 이 경우도 역시 성능 및 기존에 개발해 두었던 소프트웨어와의 호환성 문제 및 오피스 파일과의 연계와 같은 요구사항들이 새롭게 발생했기 때문이다.

따라서 시작은 RIA기술로 했지만 언제 웹 브라우저로 혹은 클라이언트 응용 프로그램으로 확장해야 할찌 모르는 점을 항상 염두해 두고 선택해야 한다. 아주 엉뚱하게 모바일 플랫폼으로 확장해야 하는 경우가 발생할 지도 모른다면 어떻게 할 것인가 하는 고민도 하게 될 것이다. 이런 경우 어떻게 해야 할까?

클라이언트를 다른 계층의 클라이언트 기술로 이동 하더라도 최소한의 노력과 비용으로 확장이 가능한 아키텍쳐와 기술을 가져가는 것이 주요 포인트가 된다.

<그림3> MS의 클라이언트 기술

MS의 경우 RIA기술인 실버라이트 그리고 클라이언트 응용 프로그램 기술인 WPF. 그리고 곧 출시될 실버라이트 모바일이 같은 기반의 기술로 구성되어 있다. 따라서 필요에 따라 다른 계층의 클라이언트로 전이하는데 있어서 최소한의 노력으로 구현이 가능하며 모든 기술인 닷넷 기반의 아키텍쳐로 통합하는게 가능하다.

클라이언트 기술은 앞으로도 계속 발전하고 더 세밀하고 치밀하게 분류되고 발전한 것이다. 아이폰만 보더라도 하드웨어 기술보다는 인터페이스를 담당하고 있는 소프트웨어로 성공하고 있으며 이는 자동차나 다른 산업 전반에도 쉽게 발견할 수 있는 사례가 될 것이다.

클라이언트 기술을 잘 선택하고 사용자에게 어필할 수 있는 적합한 인터페이스는 앞으로 점점더 많은 고민과 해결책이 제시될 것이다. ---(*)---

저는 올해 상반기에 국책 프로젝트인 디지털 교과서를 SKC&C에서 PL의 Role을 가지고 작업을 진행 했었습니다. 프로젝트를 하면서 가장 이상하게 생각했던 점 중에 하나가 바로 WPF에는 DataTimePicker, Calendar 같은 기본 컨트롤이 없다는 점이었습니다. 그리고 DataGrid도 마찬가지 입니다.

아무튼 일반적인 닷넷 기반의 UI에서는 너무 당연하게 있는 것이라서 없다는 게 오히려 신기할 지경이었습니다. 이번에 나온 WPF Toolkit으로 이런 점들이 모두 해소가 될 예정입니다. WPF Toolkit 안에서 아래와 같은 것들이 제공됩니다.

• V1 of the WPF DataGrid
• V1 of the DataPicker/Calendar
• Preview of VisualStateManager(VSM)

WPF Toolkit의 공식 링크는 http://www.codeplex.com/wpf/Release/ProjectReleases.aspx?ReleaseId=15598 입니다.
 
사이트에서 바이너리 파일이나 혹은 소스 코드를 모두 다운로드 받을 수 있습니다. 관심있는 분들은 소소코드를 받아서 하나씩 열어보는 재미가 솔솔할 것 같습니다. 바이너리 파일을 다운로드 받아서 열어보면

일반적인 설치 화면이 하나 나타 납니다. 설치하는 방법은 거의 비슷하게 라이센스에 동의를 해주고 열심히 Next를 누르다 보면 설치가 성공적으로 끝나게 됩니다.

설치를 끝내고 나서 Visual Studio를 실행시켜 보면 그 동안 아쉬웠던 Calendar, DataGrid, DatePicker등이 추가 되어 있는 것을 볼 수 있습니다.
여기서 중요한 포인트가 하나 있습니다. WPFToolKit은 기본적으로 .NET Framework 3.5 SP1 상에서 실행되는 것을 전재로 하고 있습니다. 따라서 개발자의 PC환경과 사용자의 PC환경에 .NET Framework 3.5 sp1이 설치되어 있어서 실행이 가능합니다. 따라서 WPF Toolkit을 사용하기 위해서는

.NET Framework 3.5 sp1 http://www.microsoft.com/downloads/details.aspx?displaylang=ko&FamilyID=ab99342f-5d1a-413d-8319-81da479ab0d7
Visual Studio 2008 sp1 http://www.microsoft.com/downloads/details.aspx?familyid=FBEE1648-7106-44A7-9649-6D9F6D58056E&displaylang=ko

이렇게 두 가지 요소가 우선 설치되어 있어야 합니다.
사이트에서는 새 프로젝트에서 사용하기 위해서는 WPFToolkit.dll을 참조로 링크시키고 하는 몇 가지 작업을 수동으로 해달라는 이야기를 쓰고 있지만 실제로는 그렇게 하지 않고도 툴 바에서 해당 컨트로를 추가시키는 것만으로도 필요한 작업이 다 반영되는 것을 볼 수 있습니다.

 
실제로 새 프로젝트에 컨트롤들을 추가해서 실행을 시켜보면 잘 실행되는 것을 볼 수 있습니다.

Silverlight 버전이 올라가면서 Silverlight를 이용해서 개발했거나 개발하려고 하는 개발자들이 좀 더 탄력을 받고 있는 분위기가 대세 입니다. 실제로 대기업이나 중소 기업에 도입하고 있는 사례와 문의가 많아지는 것을 보면 확실히 그런것 같습니다.

Silverlight 1.0로 개발된 웹 페이지들은 어떻게 대쳐해야 할까요? 기본적으로 Silverlight 2는 Silverlight 1과의 호환성을 염두해 두고 있습니다. 그래서 최소한의 영향으로 변경할 수 있게 되어 있습니다. 관련된 내용은 아래의 주소를 참조하시면 좋습니다. 아래의 주소는 로렌스 모르니의 블로그 입니다.
http://blogs.msdn.com/webnext/archive/2008/10/21/ensuring-that-your-javascript-silverlight-applications-work-with-silverlight-2.aspx

그리고 Siliverlight 2의 정식버전이 나왔습니다.  정식버전이 나오면서 아래와 같은 메시지를 보신 분들이 있을 것 같습니다. 기본적으로 이번에 출시된 정식버전의 경우 Silverlight 2 Beta와 파일 수준에서 호환성은 없습니다. (좀 더 닷넷스럽게 이야기 하자면 어셈블리 수준의 호환성은 없습니다.) 호환성이 없기 때문에 필요한 도구들을 설치하고 다시 컴파일 해서 재 배포해야 합니다.

이와 같은 이야기를 하면 "앗 그럼 새버전이 나올 때 마다 이런 일을 반복해야 하는 거야?" 라는 생각을 할지도 모르지만 베타에서 정식으로 넘어오는 과정일 뿐 정식버전의 버전업과는 다른 이야기 입니다. 현재 서비스 되고 있는 Silverlight를 버전하기 위해서는 우선 필요한 툴 들을 다시 정식버전으로 업그레이드 해야 합니다. 설치해야 하는 툴과 관려된 내용은 UX Factory를 운영하고 있는 황리건 과장이 잘 정리했습니다.

http://www.uxfactory.com/455

내용을 보면 설치해야 하는 것이 Runtime과 Silverlight Tools for Visual Studio 2008 SP1, Expression Blend 2 SP1을 설치해야 한다고 합니다.  처음에는 영문 버전 위주로 제공되었지만 지금은 한국어 버전들도 잘 지원하고 있습니다. 개발 소스 레벨에서 달라진 점은 공도소프트의 공인석씨가 잘 정리했습니다.

http://gongdosoft.com/321

특히 Silverlight 2 Runtime을 설치하고 나면 아래와 같은 정보 창을 보실 수 있습니다.

버전 정보에 다른 글짜 (beta, rtm)이런 글자가 떨어져 나간 것을 볼 수 있습니다.

개발자들이 한 가지 주의 할 점은 같은 버전이라고 할지라도 Runtime 버전은 두 가지 버전이 있다는 점입니다. 일반적인 End User들이 사용한 Runtime이 있는가 하면 개발자들이 사용할 수 있는 Runtime이 있습니다. 개발자들이 사용하는 Runtime은 용량도 2메가 가량 더 크고 더 많은 요소들이 개발자들을 위해서 포함되어 있기 때문에 개발자들은 꼭 개발자용  Runtime을 사용하는게 좋습니다.  이와 관련해서는 아래의 링크를 참고하시기 바랍니다.

http://gongdosoft.com/329

Silverlgiht 기본 강좌 11개 입니다. 모두 한국어(?!)로 구성되어 있고 그리고 구현된 소스를 함께 제공하고 있습니다.
기본적인 개념과 환경 설정 그리고 프로그래밍을 다루고 있습니다.