WinFX와 닷넷 프레임워크 3.0의 관계
WCF, WPF, WWF 개념 잡기
WinFX와 닷넷 프레임워크 3.0의 관계
우리는 변화의 시대에 살고 있다. 정치 사회적인 변화 같은 어려운 이야기를 꺼내지 않더라도 우리 주위의 일상적인 생활 역시 매일매일 변해가는 것을 느낄 수 있을 것이다. 불과 몇 년 전만 해도 핸드폰은 구경하기도 힘든 고가 제품이었다. 지금은 길거리에서 단돈 몇 만원에 살 수 있을 정도로 흔한 생활 필수품이 되어 버렸다. 이런 점에서 개발자도 예외는 아니다. 개발자는 더욱 더 빠른 기술 변화에 노출되어 있다. 터보 C 정도만 다룰 줄 알면 취업에는 큰 지장이 없었던 몇 년 전의 상황과는 너무나도 달라졌다. 요새 개발자는 기본적으로 PHP, JSP, ASP.NET와 같은 기본적인 웹 개발 지식과 AJAX나 ATLAS 등 최신 웹 관련 기술 정도는 알아야만 어디라도 이력서를 넣어볼 수 있을 정도가 되었다. 이처럼 개발자들에게 요구되는 프로그래밍 지식이 기하급수적으로 늘어나 버렸다.
마이크로소프트 닷넷 기술을 다루는 개발자라면 최근 1-2달의 상황이 이러한 기술 변화를 다시 한번 실감하게 만들었다. WinFX라는 닷넷의 차기 기술에 대한 이야기가 몇 년이 넘도록 떠돌다가 뜬금없이 닷넷 프레임워크 3.0 버전이 등장했기 때문이다. 닷넷 프레임워크 2.0이 정식 발표된지 채 6개월도 지나지 않아서 다음 버전인 3.0 이야기가 나온 것은 무슨 연유일까? 그리고 WinFX와는 도대체 어떤 관계일까? 이번 호에는 닷넷 프레임워크의 차기 버전인 3.0에 대해서 살펴보고 이어서 WinFX와는 어떤 관계가 있는지 알아보자. 또한 이들을 위한 개발환경은 어떻게 구축 할 수 있는지 살펴보기로 한다. 이번 내용은 아직 정식으로 출시되지 않은 베타 버전을 기준으로 구성했으므로 최종 버전에서 명칭 및 내용이 바뀔 수 있음을 주의하자.
WinFX 란 무엇인가?
닷넷 프레임워크 3.0에 대해서 이야기를 하자면 먼저 WinFX 이야기를 하지 않을 수 없다. WinFX는 2003년 마이크로소프트의 PDC(Professional Developers Conference)에서 처음 언급된 개발 API 이다. 그 후 2004년 롱혼(Longhorn)이라는 코드명의 운영체제인 Windows Vista가 베타로서 일부 사용자에게 배포되면서 조금씩 그 실체가 들어났다. 지금은 베타2 버전을 누구나 다운로드 받아 사용할 수 있는 상황이다.
WinFX가 처음 언급되었을 때는 Windows Vista에서 Win32 API를 대체할 새로운 개발 API쯤으로 이야기 되었었다. 필자 역시 WinFX 자료를 처음 접했을 때 그런 인상을 강하게 받았으니 말이다. 정확하게 말하자면 그렇지가 않다. WinFX는 닷넷 프레임워크 상에서 작동하는 새롭게 추가된 애플리케이션 개발 프레임워크이다. 여기서 WinFX가 닷넷 프레임워크 상에서 작동한다는 말은 중요한 의미를 갖는다. 닷넷 프레임워크 없이는 WinFX가 작동하지 않는다는 것을 의미하기 때문이다.
이는 곧 WinFX가 Win32를 대체하는 API가 아니라는 뜻이다. 물론 Windows Vista 에는 다양한 새로운 운영체제 요소들과 새로운 UI 기능이 많이 추가되었다. 이들과 관련된 새로운 수백 개의 API 함수가 추가되었음은 물론이다. 하지만 이들 API가 WinFX를 지칭하는 것이 아니라는 점이다. 실제로 베타2 버전의 Windows Vista는 WinFX를 기본으로 설치하지 않고 추가 옵션으로 설치할 수 있도록 되어 있었다.
그렇다면 WinFX란 정말 무엇이란 말인가? WinFX는 닷넷 프레임워크 2.0 상에 새로이 추가된 메시징(messaging) 프레임워크(WCF; Windows Communication Foundation), UI 프레임워크(WPF; indows Presentation Foundation), 워크플로우 프레임워크(WWF; Windows Workflow Foundation)를 모두 합쳐서 지칭하는 말이 되겠다. 그림 1은 닷넷 프레임워크 2.0과 WinFX의 관계를 보여주고 있다.
그림 1을 찬찬히 뜯어보면 WinFX가 구동되는 운영체제에는 Windows 2003과 Windows XP도 포함되어 있음을 알 수 있을 것이다. 그렇다. WinFX는 반드시 Windows Vista를 요구하지 않는다. 따라서 닷넷 프레임워크 2.0을 설치한 Windows XP, Windows 2003, Windows Vista에서 WinFX의 설치가 가능하고 작동된다는 것을 알 수가 있다.
WinFX는 닷넷 프레임워크 1.1에서 2.0으로의 변화와 같은 프레임워크의 변화가 없었다는 점에도 주목할 필요가 있다. WinFX는 순전히 닷넷 프레임워크 2.0에 애드온 되는 추가 프레임워크이다. 이제 WinFX를 구성하는 WCF, WPF, WWF 가 무엇인지 간단히 살펴보기로 하자.
<그림 1> 닷넷 프레임워크와 WinFX와의 관계
WCF; Windows Communication Foundation
WCF(Windows Communication Foundation)는 인디고(Indigo)라는 코드네임으로 알려졌던 차세대 메시징 프레임워크를 말한다. WCF에 대응되는 현존하는 닷넷 기술은 XML 웹 서비스와 닷넷 리모팅이다. WCF는 웹 서비스가 제공하는 상호 운영성과 닷넷 리모팅이 제공하는 성능상의 우위를 모두 제공할 뿐만 아니라 웹 서비스와 닷넷 리모팅이 갖는 단점을 거의 대부분 보완한다.
닷넷이 원격 서비스 혹은 원격 컴포넌트/ 클래스를 호출하는 방법은 웹 서비스와 닷넷 리모팅으로 이원화 되어 있었다. 웹 서비스는 SOA(Service Oriented Architecture)를 지향하고 보다 높은 상호 운영성(interoperability)이 요구되는 환경에서 주로 사용되고 있다. 닷넷 리모팅은 클라이언트와 서버가 모두 닷넷 플랫폼인 경우 사용되는 원격 컴포넌트 호출 메커니즘이다. 상호 운영성 보다 성능이 중요시되는 환경에서 사용되었다. 이들 두 메시징 기술의 단점은 비슷한 기능을 수행함에도 불구하고 그 내부 메커니즘과 프로그래밍 방식에 공통점이 별로 없다는 점이다. 일단 두 기술 중 하나를 선택한 경우, 다른 기술로 애플리케이션을 바꾸는 것은 디자인부터 다시 생각해야 할 정도의 커다란 프로그래밍 방식의 변화를 가져오곤 했다. 또한 이들 두 기술은 트랜잭션 지원이나 신뢰도 높은 세션 기능 등 기능면에서도 부족하다는 한계를 가지고 있다.
<화면 1> Visual Studio 2005의 WCF 서비스 참조 기능
WinFX의 요소인 WCF는 이러한 단점들을 극복하고자 등장한 차세대 메시징 프레임워크이다. WCF는 W3C 표준을 준수하는 웹 서비스 스타일의 메시징과 더불어 닷넷 리모팅과 같은 성능적인 면을 모두 지원할뿐더러, WCF를 통해 분산 트랜잭션, 신뢰도 높은 세션 기반의 통신, MSMQ와 같은 레거시 시스템 통합을 모두 지원하고 있다. 무엇보다도, WCF는 단일한 프로그래밍 방식으로 웹 서비스 스타일 혹은 닷넷 리모팅 스타일의 통신을 지원한다.
WCF는 원격 통신의 서버 역할을 수행하는 서비스(service)를 작성하고 이 서비스를 호출하는 클라이언트를 위한 다양한 클래스들을 System.ServiceModel 네임스페이스에서 제공한다. 이 네임스페이스 및 하위 네임스페이스에서 제공되는 다양한 특성(attribute)과 클래스를 통해 서비스를 작성하고 이 서비스를 ASP.NET 웹 애플리케이션 혹은 호스트 애플리케이션(닷넷 리모팅의 호스트처럼)을 작성하여 서비스할 수 있다. 또한 클라이언트는 Visual Studio 2005의 서비스 참조(화면 1 참고)를 통하거나 svcutil.exe(wsdl.exe를 사용하는 것처럼) 유틸리티를 이용하여 손쉽게 개발할 수 있다.
지면 관계상 보다 상세한 내용을 다룰 수 없음을 독자들은 이해해 주기 바란다. 다음 기회에 WCF에 대한 기본적인 프로그래밍 방법을 다룰 것을 약속하는 바이다.
WPF; Windows Presentation Foundation
WPF(Windows Presentation Foundation)은 아발론(Avalon)이라는 코드 네임으로 유명했던 WinFX에서 지원하는 차세대 윈도우 UI 프레임워크이다. WPF가 제공하는 UI가 어떤 것인지 가장 빠르게 이해하는 방법은 가장 비슷한 UI를 제공하는 Flex 류의 기술을 생각하면 쉽다. WPF의 가장 큰 특징은 UI를 정의할 때 윈폼(WinForm)처럼 코드를 사용하지 않고(Visual Studio의 디자이너는 코드를 생성하는 도구일 뿐 실제는 코드에 의해 UI가 정의 된다), XAML(eXtensible Application Markup Language; Zammel 이라고 읽는다.) 이라는 XML 을 이용하여 UI를 정의한다는 점이다. XAML을 이해하는 가장 빠른 방법은 ASP.NET이 작동하는 방식을 비교해 보면된다.
ASP.NET의 WebForm 페이지(.aspx)는 런타임에 <asp:Button>, <asp:Label> 과 같은 ASP.NET 태그들이 웹 서버 컨트롤과 관련된 C# 혹은 VB.NET 코드로 변환 되고 컴파일 되어 수행된다. 마찬가지로 XAML은 윈도우 UI를 정의하는 드로잉 객체를 정의하고 이것이 WPF 컨트롤과 코드로 변환되어 수행되도록 하는 UI 프레임워크인 것이다. 그렇다면 ASP.NET 과 비슷하게 코드 비하인드(Code-Behind)와 같은 것도 있을까? 물론 그렇다. 이벤트 핸들러와 같은 UI에 관련된 코드는 별도의 .cs 혹은 .vb 파일 내에 별도로 존재하며 XAML과 함께 작동한다.
리스트 1은 간단한 XAML의 예를 보여준다. 마치 HTML로 웹 페이지의 UI를 기술하듯이 XAML을 이용하여 윈도우 UI를 정의하고 있는 것을 보여준다. 화면 2는 리스트 1이 수행될 때 나타나는 모습을 보여주고 있다.
WPF는 단순히 윈도우의 UI 컨트롤을 XAML을 통해 기술하는 것만을 의미하지 않는다. WPF에서 제공하는 컨트롤은 윈폼에서 제공하는 컨트롤과 전혀 다르다. 화면에 렌더링(Rendering) 되는 것도 GDI를 사용하지 않는다. WPF의 컨트롤들은 새로이 제공되는 UI 렌더링 인프라인 MilCore라는 것을 사용한다. MilCore는 DirectX를 직접 제어하여 UI 요소들을 렌더링 하는 역할을 담당하고 있다. 즉, WPF는 Win32의 윈도우와 윈도우 메시지(WM_SIZE, WM_PAINT 등)에 의존하지 않고 직접적으로 화면에 UI를 렌더링하고 있다.
이런 이유로 WPF는 윈폼에서는 구현하기 힘들거나 불가능한 작업을 수행할 수 있다. 예를 들어 하나의 윈폼 라벨 컨트롤에서 여러 종류의 폰트를 사용하거나 굵은 서체, 이탤릭 서체를 사용할 수는 없다. 하지만 WPF는 다음과 같이 단일 TextBlock 컨트롤을 통해 이러한 작업을 간단히 수행할 수도 있다(화면 3 참조). 이 외에도 WPF는 Flex 류의 기술처럼 애니메이션 등을 XAML를 통해 표현 할 수 있다. 2D 그래픽 요소들에 대한 회전, 확대, 축소뿐만 아니라 3D 그래픽적인 요소들도 쉽게 표현할 수 있다.
<TextBlock FontFamily="Calibri"FontSize="11pt">
Hello, <Bold>world!</Bold>
<Span FontFamily="Old English Text MT" FontSize="24pt">This</Span>
is a
<Italic>single</Italic>
<Span FontFamily="Consolas"Foreground="Blue">
<<Span Foreground="DarkRed">TextBlock</Span>/>
</Span>
<Hyperlink>element</Hyperlink>.
</TextBlock>
<화면 2> 리스트1의 XAML을 Windows XP에서 수행한 결과
<화면 3> 단일 TextBlock 컨트롤을 사용하여 다양한 폰트 사용
또한, WPF는 스마트 클라이언트와 비슷한 Web Browser Application(WBA) 기능을 지원한다. 플래시나 Flex와 같이 브라우저 상에서 보다 역동적이고 화려한 UI를 제공하고자 하는 경우, XAML 과 코드를 컴파일 하여 웹 서버를 통해 배포할 수 있다. WPF의 이러한 기능은 닷넷 스마트 클라이언트와는 달리 WinFX가 설치되어 있다면 브라우저에 관계없이 표시될 수 있을 것으로 예상된다.
<화면 4> WPF의 Web Browser Application 예제 화면
그렇다면 WinFX를 사용하면 윈폼 대신 WPF로 애플리케이션을 작성해야 하는가? 그렇지 않다. 그림 1에서 살펴본 대로 윈폼과 WPF는 병렬적으로 존재한다. 즉, 윈폼을 이용할 것인가 WPF를 이용할 것인가는 순전히 독자 여러분의 손에 달려 있다는 말이다. 어떤 윈도우 UI 프레임워크를 사용할 것인가의 결정은 해당 애플리케이션이 어떤 UI를 요구하는가에 따라서 결정하면 된다. 기업의 업무 화면을 다루는 UI라면 윈폼이 좀 더 적당할 것이지만, 3차원 그래픽을 포함한 애니메이션이나 보다 미려한 UI를 요구한다면 WPF가 대안이 될 것이다. WPF를 위해 윈폼을 포기하지는 말자.
WWF; Windows Workflow Foundation
WCF나 WPF는 그에 대응되는 닷넷 기술이 있다. WCF는 XML 웹 서비스와 닷넷 리모팅에 대한 차세대 프레임워크로서, WPF는 윈폼에 대한 차세대 프레임워크로서 간주할 수 있다. 이에 반해 WWF(Windows Workflow Foundation)는 이전의 마이크로소프트 기술에서 찾아볼 수 없는 새로운 워크플로우 프레임워크이다.
WWF는 전자결재와 같이 워크플로우 방식을 따르는 다양한 애플리케이션을 위한 워크플로우 엔진을 제공한다. WWF는 워크플로우를 처리하기 위한 다양한 액티비티(Activity)를 기본으로 제공하고 이러한 액티비티에 의해 정의되는 워크플로우를 수행하는 워크플로우 엔진을 제공한다. 개발자는 특정 워크플로우를 기본 액티비티들과 커스텀 액티비티를 통해 정의할 수 있다. 정의된 워크플로우는 워크 플로우 엔진에 의해 구동되게 된다. 이러한 워크플로우를 설계하기 위해 Visual Studio 2005에서 사용할 수 있는 워크플로우 디자이너와 윈폼에서 사용할 수 있는 워크플로우 디자이너 컨트롤이 제공될 것이라고 한다(화면5 참조).
WWF는 그 자체로서는 아무짝에도 쓸모가 없다. WWF만 있으면 전자결재 엔진을 작성하지 않아도 되는 것이 아니다. WWF를 기반으로 전자결재 워크플로우를 설계하고 개발해야만 WWF 기반의 전자결재 엔진이 생성되는 것이다. 이처럼 WWF는 다양한 워크플로우 기반 애플리케이션이 사용할 수 있는 워크플로우 프레임워크일 뿐이지 그 자체로서 특정 워크플로우를 처리할 수 있는 것이 아님을 명심해야 한다. WWF를 사용하는 최초의 상용 제품은 아마도 Microsoft Office Sharepoint Server 2007(MOSS 2007)이 될 것 같다. MOSS 2007은 기본적으로 간단한 결재(approval)를 처리하는 기능을 탑재하고 있는데 이 결재 기능이 WWF를 사용하여 작성된 것이다.
<화면 5> WWF의 기본 Activity 들과 VS 2005의 워크플로우 디자이너
WWF가 상당히 생소하기 때문에 어렵게 생각할 개발자들이 많을 것이다. 필자 역시 그랬다. 하지만 전혀 어렵게 생각할 필요가 없다. 일단 WinFX 개발환경이 갖추어지면 WWF를 이용하여 워크플로우를 개발하는 것이 얼마나 쉬운 일이 되어 버리는가를 실감하게 될 것이다. 멀티 스레드 방식으로 작동하는 WWF의 워크플로우 엔진은 워크플로우의 상태를 저장하는 능력을 갖고 있다. Visual Studio 2005가 제공하는 워크플로우 디자이너는 워크플로우를 설계하는 직관적인 UI를 제공한다. 필자의 개인적인 생각으로 WWF는 기업 고유의 워크플로우를 구축하고자 하는 수많은 기업들에게 희소식이 될 듯 싶다.
그렇다면 .NET Framework 3.0은 ?
지금까지 WinFX에 대해서 간단히 살펴보았다. WinFX만으로도 벅찬 작금의 상황에서 쌩뚱맞게(?) 닷넷 프레임워크 3.0은 웬 말인가 싶은 독자가 있을는지 모르겠다. 결론부터 말하자면 지난 2006년 6월 마이크로소프트는 WinFX의 이름을 닷넷 프레임워크 3.0으로 지칭하기로 했다. 좀 허탈하지만 닷넷 프레임워크 3.0은 정확하게 WinFX가 이름만 바꾼 것이 되겠다. 물론 WinFX에 포함시키기로 했었지만 포함되지 않았었던 WCS(Windows CardSpace; InfoCard라 불렸었다)가 명시적으로 닷넷 프레임워크 3.0에 포함된 것 외에는 WCF, WPF, WWF는 WinFX의 그것과 전혀 다르지 않다.
그렇다면 닷넷 프레임워크 3.0은 닷넷 프레임워크 2.0에서 돌아가게 되는 것인가? 그렇다. 닷넷 프레임워크 3.0이 설치되기 위해서는 닷넷 프레임워크 2.0이 필요하다. 대개의 경우 새로운 버전이 등장하면 이전 버전과 하위 호환성을 갖지만 이전 버전을 요구하지 않았었다. 닷넷 프레임워크 2.0이 닷넷 프레임워크 1.0/1.1과 무관하게 설치되고 사용될 수 있었듯이 말이다.
하지만 닷넷 프레임워크 3.0은 반드시 닷넷 프레임워크 2.0이 설치되어 있어야만 한다. 이는 닷넷 프레임워크 3.0이 사용하는 CLR의 버전이 2.0임을 의미하고, 닷넷 프레임워크 3.0이 사용하는 클래스 라이브러리 역시 2.0의 클래스 라이브러리이기 때문이다. 이것이 복잡하게 느껴지거나 혼란스럽게 여겨진다면 닷넷 프레임워크 3.0이 단순히 WinFX의 이름을 바꾼 것으로만 생각하면 좀 더 자연스러울 것이다. 그림 2를 살펴보면 개념이 혼란스러운 독자에게 도움이 되리라 생각한다.
<그림 2> 닷넷 프레임워크 3.0 구조
그럼 왜 마이크로소프트는 WinFX의 이름을 닷넷 프레임워크 3.0으로 바꾼 것일까? 빌 게이츠 형한테 물어보지 않아서 정확하진 않지만, 일단 WinFX라는 이름만으로 WinFX가 닷넷과 어떤 연관이 있을 것이라는 생각을 갖기가 매우 어렵다. 필자 역시 Win32의 후계자 쯤으로 생각했으니까 말이다. 게다가 WinFX가 닷넷 프레임워크를 기반으로 하는 차세대 애플리케이션 프레임워크이기 때문에 보다 직관적인 이름으로 닷넷 프레임워크 3.0 이라는 이름을 가지게 되었을 것으로 생각한다. 하지만 닷넷 프레임워크 3.0이 이전 버전으로 생각되는 닷넷 프레임워크 2.0에서 작동하는 것은 여전히 개발자나 IT 프로에게는 혼동을 주게 될 가능성이 높다.
.NET Framework 3.0 개발환경
.NET Framework 3.0에 대해 자료를 찾고자 한다면 http://msdn.microsoft.com/winfx 에 가보는 것이 좋다. 자료도 중요하지만 개발자라면 개발환경을 갖추고 WCF, WPF, WWF에 대한 HelloWorld 프로그램이라도 작성해 보는 것이 더욱 더 중요하다고 본다. 닷넷 프레임워크 3.0을 위해서 Windows Vista가 필요하지 않다. Windows 2003 SP1 혹은 Windows XP SP2를 갖고 있다면 충분하다. 사전에 필요한 소프트웨어로서 닷넷 프레임워크 2.0이 설치되어 있다면 충분하지만 개발 환경을 꾸미기 위해 Visual Studio 2005를 설치하는 것이 좋다. 정식 제품이 아니더라도 무료로 사용할 수 있는 Express Edition을 설치해도 된다. 3.0을 위한 개발환경을 갖추기 위해 베타 버전들이 필요한 독자는 http://msdn.microsoft.com/windowsvista/downloads/products/getthebeta/에서 다운로드 받을 수 있다. 다음 순서대로 설치를 하면 문제 없이 개발 환경을 꾸밀 수 있을 것이다.
* .NET Framework 3.0 Runtime
* Windows SDK
* CodeName “Orcas"Add-in (Visual Studio 2005 용 WPF 디자이너)
* Visual Studio 2005 Extension for WWF (WWF 디자이너 및 디버거 등)
* 옵션 : Microsoft Expression Interactive Designer May 2006 CTP
Windows SDK는 예전에 플랫폼 SDK라 불리던 SDK가 이름이 바뀐 것이다. WPF, WCF, WWF에 대한 도움말과 빌드 환경(VS 2005와 무관하게)을 갖추기 위해서는 Windows SDK를 반드시 설치해야 한다. 이외에 Visual Studio 2005에서 WPF와 WWF에 대한 디자이너 등의 기능을 사용하고자 한다면 두 개의 애드인을 추가로 설치해야 한다.
마지막으로 Microsoft Expression 은 WPF를 위한 디자이너로서 Visual Studio 2005의 디자이너가 제공하지 않는 애니메이션이나 진보된 기능을 손쉽게 디자인하도록 해주는 도구이다. 반드시 필요하지는 않지만 WPF의 다양한 기능을 체험해보고 싶다면 설치를 두려워하지 말자.
세상에는 두 종류의 개발자가 있다. 변화를 귀찮게 생각하고 현재의 기술에 안주하려는 개발자와 변화를 새로운 기회로 삼고 자신의 가치를 높이는 기회로 삼는 개발자. 일찍 일어나는 새가 벌레를 잡는다는 말이 있듯이 개발자들의 세계에서도 빨리 준비하는 개발자가 몸값을 올린다는 말이 있다(필자가 지어낸 말이다. ^^). 짬짬이 시간을 내서 먼저 준비하는 개발자는 그렇지 못한 개발자에 비해 보다 높은 가치를 갖게 될 것임은 당연하지 않은가?
출처 : 마이크로소프트웨어 2006년 10월호
WinFX와 닷넷 프레임워크 3.0의 관계
우리는 변화의 시대에 살고 있다. 정치 사회적인 변화 같은 어려운 이야기를 꺼내지 않더라도 우리 주위의 일상적인 생활 역시 매일매일 변해가는 것을 느낄 수 있을 것이다. 불과 몇 년 전만 해도 핸드폰은 구경하기도 힘든 고가 제품이었다. 지금은 길거리에서 단돈 몇 만원에 살 수 있을 정도로 흔한 생활 필수품이 되어 버렸다. 이런 점에서 개발자도 예외는 아니다. 개발자는 더욱 더 빠른 기술 변화에 노출되어 있다. 터보 C 정도만 다룰 줄 알면 취업에는 큰 지장이 없었던 몇 년 전의 상황과는 너무나도 달라졌다. 요새 개발자는 기본적으로 PHP, JSP, ASP.NET와 같은 기본적인 웹 개발 지식과 AJAX나 ATLAS 등 최신 웹 관련 기술 정도는 알아야만 어디라도 이력서를 넣어볼 수 있을 정도가 되었다. 이처럼 개발자들에게 요구되는 프로그래밍 지식이 기하급수적으로 늘어나 버렸다.
마이크로소프트 닷넷 기술을 다루는 개발자라면 최근 1-2달의 상황이 이러한 기술 변화를 다시 한번 실감하게 만들었다. WinFX라는 닷넷의 차기 기술에 대한 이야기가 몇 년이 넘도록 떠돌다가 뜬금없이 닷넷 프레임워크 3.0 버전이 등장했기 때문이다. 닷넷 프레임워크 2.0이 정식 발표된지 채 6개월도 지나지 않아서 다음 버전인 3.0 이야기가 나온 것은 무슨 연유일까? 그리고 WinFX와는 도대체 어떤 관계일까? 이번 호에는 닷넷 프레임워크의 차기 버전인 3.0에 대해서 살펴보고 이어서 WinFX와는 어떤 관계가 있는지 알아보자. 또한 이들을 위한 개발환경은 어떻게 구축 할 수 있는지 살펴보기로 한다. 이번 내용은 아직 정식으로 출시되지 않은 베타 버전을 기준으로 구성했으므로 최종 버전에서 명칭 및 내용이 바뀔 수 있음을 주의하자.
WinFX 란 무엇인가?
닷넷 프레임워크 3.0에 대해서 이야기를 하자면 먼저 WinFX 이야기를 하지 않을 수 없다. WinFX는 2003년 마이크로소프트의 PDC(Professional Developers Conference)에서 처음 언급된 개발 API 이다. 그 후 2004년 롱혼(Longhorn)이라는 코드명의 운영체제인 Windows Vista가 베타로서 일부 사용자에게 배포되면서 조금씩 그 실체가 들어났다. 지금은 베타2 버전을 누구나 다운로드 받아 사용할 수 있는 상황이다.
WinFX가 처음 언급되었을 때는 Windows Vista에서 Win32 API를 대체할 새로운 개발 API쯤으로 이야기 되었었다. 필자 역시 WinFX 자료를 처음 접했을 때 그런 인상을 강하게 받았으니 말이다. 정확하게 말하자면 그렇지가 않다. WinFX는 닷넷 프레임워크 상에서 작동하는 새롭게 추가된 애플리케이션 개발 프레임워크이다. 여기서 WinFX가 닷넷 프레임워크 상에서 작동한다는 말은 중요한 의미를 갖는다. 닷넷 프레임워크 없이는 WinFX가 작동하지 않는다는 것을 의미하기 때문이다.
이는 곧 WinFX가 Win32를 대체하는 API가 아니라는 뜻이다. 물론 Windows Vista 에는 다양한 새로운 운영체제 요소들과 새로운 UI 기능이 많이 추가되었다. 이들과 관련된 새로운 수백 개의 API 함수가 추가되었음은 물론이다. 하지만 이들 API가 WinFX를 지칭하는 것이 아니라는 점이다. 실제로 베타2 버전의 Windows Vista는 WinFX를 기본으로 설치하지 않고 추가 옵션으로 설치할 수 있도록 되어 있었다.
그렇다면 WinFX란 정말 무엇이란 말인가? WinFX는 닷넷 프레임워크 2.0 상에 새로이 추가된 메시징(messaging) 프레임워크(WCF; Windows Communication Foundation), UI 프레임워크(WPF; indows Presentation Foundation), 워크플로우 프레임워크(WWF; Windows Workflow Foundation)를 모두 합쳐서 지칭하는 말이 되겠다. 그림 1은 닷넷 프레임워크 2.0과 WinFX의 관계를 보여주고 있다.
그림 1을 찬찬히 뜯어보면 WinFX가 구동되는 운영체제에는 Windows 2003과 Windows XP도 포함되어 있음을 알 수 있을 것이다. 그렇다. WinFX는 반드시 Windows Vista를 요구하지 않는다. 따라서 닷넷 프레임워크 2.0을 설치한 Windows XP, Windows 2003, Windows Vista에서 WinFX의 설치가 가능하고 작동된다는 것을 알 수가 있다.
WinFX는 닷넷 프레임워크 1.1에서 2.0으로의 변화와 같은 프레임워크의 변화가 없었다는 점에도 주목할 필요가 있다. WinFX는 순전히 닷넷 프레임워크 2.0에 애드온 되는 추가 프레임워크이다. 이제 WinFX를 구성하는 WCF, WPF, WWF 가 무엇인지 간단히 살펴보기로 하자.
<그림 1> 닷넷 프레임워크와 WinFX와의 관계
WCF; Windows Communication Foundation
WCF(Windows Communication Foundation)는 인디고(Indigo)라는 코드네임으로 알려졌던 차세대 메시징 프레임워크를 말한다. WCF에 대응되는 현존하는 닷넷 기술은 XML 웹 서비스와 닷넷 리모팅이다. WCF는 웹 서비스가 제공하는 상호 운영성과 닷넷 리모팅이 제공하는 성능상의 우위를 모두 제공할 뿐만 아니라 웹 서비스와 닷넷 리모팅이 갖는 단점을 거의 대부분 보완한다.
닷넷이 원격 서비스 혹은 원격 컴포넌트/ 클래스를 호출하는 방법은 웹 서비스와 닷넷 리모팅으로 이원화 되어 있었다. 웹 서비스는 SOA(Service Oriented Architecture)를 지향하고 보다 높은 상호 운영성(interoperability)이 요구되는 환경에서 주로 사용되고 있다. 닷넷 리모팅은 클라이언트와 서버가 모두 닷넷 플랫폼인 경우 사용되는 원격 컴포넌트 호출 메커니즘이다. 상호 운영성 보다 성능이 중요시되는 환경에서 사용되었다. 이들 두 메시징 기술의 단점은 비슷한 기능을 수행함에도 불구하고 그 내부 메커니즘과 프로그래밍 방식에 공통점이 별로 없다는 점이다. 일단 두 기술 중 하나를 선택한 경우, 다른 기술로 애플리케이션을 바꾸는 것은 디자인부터 다시 생각해야 할 정도의 커다란 프로그래밍 방식의 변화를 가져오곤 했다. 또한 이들 두 기술은 트랜잭션 지원이나 신뢰도 높은 세션 기능 등 기능면에서도 부족하다는 한계를 가지고 있다.
<화면 1> Visual Studio 2005의 WCF 서비스 참조 기능
WinFX의 요소인 WCF는 이러한 단점들을 극복하고자 등장한 차세대 메시징 프레임워크이다. WCF는 W3C 표준을 준수하는 웹 서비스 스타일의 메시징과 더불어 닷넷 리모팅과 같은 성능적인 면을 모두 지원할뿐더러, WCF를 통해 분산 트랜잭션, 신뢰도 높은 세션 기반의 통신, MSMQ와 같은 레거시 시스템 통합을 모두 지원하고 있다. 무엇보다도, WCF는 단일한 프로그래밍 방식으로 웹 서비스 스타일 혹은 닷넷 리모팅 스타일의 통신을 지원한다.
WCF는 원격 통신의 서버 역할을 수행하는 서비스(service)를 작성하고 이 서비스를 호출하는 클라이언트를 위한 다양한 클래스들을 System.ServiceModel 네임스페이스에서 제공한다. 이 네임스페이스 및 하위 네임스페이스에서 제공되는 다양한 특성(attribute)과 클래스를 통해 서비스를 작성하고 이 서비스를 ASP.NET 웹 애플리케이션 혹은 호스트 애플리케이션(닷넷 리모팅의 호스트처럼)을 작성하여 서비스할 수 있다. 또한 클라이언트는 Visual Studio 2005의 서비스 참조(화면 1 참고)를 통하거나 svcutil.exe(wsdl.exe를 사용하는 것처럼) 유틸리티를 이용하여 손쉽게 개발할 수 있다.
지면 관계상 보다 상세한 내용을 다룰 수 없음을 독자들은 이해해 주기 바란다. 다음 기회에 WCF에 대한 기본적인 프로그래밍 방법을 다룰 것을 약속하는 바이다.
WPF; Windows Presentation Foundation
WPF(Windows Presentation Foundation)은 아발론(Avalon)이라는 코드 네임으로 유명했던 WinFX에서 지원하는 차세대 윈도우 UI 프레임워크이다. WPF가 제공하는 UI가 어떤 것인지 가장 빠르게 이해하는 방법은 가장 비슷한 UI를 제공하는 Flex 류의 기술을 생각하면 쉽다. WPF의 가장 큰 특징은 UI를 정의할 때 윈폼(WinForm)처럼 코드를 사용하지 않고(Visual Studio의 디자이너는 코드를 생성하는 도구일 뿐 실제는 코드에 의해 UI가 정의 된다), XAML(eXtensible Application Markup Language; Zammel 이라고 읽는다.) 이라는 XML 을 이용하여 UI를 정의한다는 점이다. XAML을 이해하는 가장 빠른 방법은 ASP.NET이 작동하는 방식을 비교해 보면된다.
<리스트 1> WPF의 XAML 예제
<Window
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Hello WPF">
<Grid>
<Button Name="button1" Margin="124,73,20,80" Width="160" Height="30">
This is Button !
</Button>
<Button Name="button2" Margin="131,141,236,0" Width="160" Height="80">
<StackPanel>
<Ellipse Fill="Green" Stroke="Yellow" Width="30" Height="20" />
<TextBlock>This is Button !</TextBlock>
</StackPanel>
</Button>
</Grid>
</Window>
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Hello WPF">
<Grid>
<Button Name="button1" Margin="124,73,20,80" Width="160" Height="30">
This is Button !
</Button>
<Button Name="button2" Margin="131,141,236,0" Width="160" Height="80">
<StackPanel>
<Ellipse Fill="Green" Stroke="Yellow" Width="30" Height="20" />
<TextBlock>This is Button !</TextBlock>
</StackPanel>
</Button>
</Grid>
</Window>
ASP.NET의 WebForm 페이지(.aspx)는 런타임에 <asp:Button>, <asp:Label> 과 같은 ASP.NET 태그들이 웹 서버 컨트롤과 관련된 C# 혹은 VB.NET 코드로 변환 되고 컴파일 되어 수행된다. 마찬가지로 XAML은 윈도우 UI를 정의하는 드로잉 객체를 정의하고 이것이 WPF 컨트롤과 코드로 변환되어 수행되도록 하는 UI 프레임워크인 것이다. 그렇다면 ASP.NET 과 비슷하게 코드 비하인드(Code-Behind)와 같은 것도 있을까? 물론 그렇다. 이벤트 핸들러와 같은 UI에 관련된 코드는 별도의 .cs 혹은 .vb 파일 내에 별도로 존재하며 XAML과 함께 작동한다.
리스트 1은 간단한 XAML의 예를 보여준다. 마치 HTML로 웹 페이지의 UI를 기술하듯이 XAML을 이용하여 윈도우 UI를 정의하고 있는 것을 보여준다. 화면 2는 리스트 1이 수행될 때 나타나는 모습을 보여주고 있다.
WPF는 단순히 윈도우의 UI 컨트롤을 XAML을 통해 기술하는 것만을 의미하지 않는다. WPF에서 제공하는 컨트롤은 윈폼에서 제공하는 컨트롤과 전혀 다르다. 화면에 렌더링(Rendering) 되는 것도 GDI를 사용하지 않는다. WPF의 컨트롤들은 새로이 제공되는 UI 렌더링 인프라인 MilCore라는 것을 사용한다. MilCore는 DirectX를 직접 제어하여 UI 요소들을 렌더링 하는 역할을 담당하고 있다. 즉, WPF는 Win32의 윈도우와 윈도우 메시지(WM_SIZE, WM_PAINT 등)에 의존하지 않고 직접적으로 화면에 UI를 렌더링하고 있다.
이런 이유로 WPF는 윈폼에서는 구현하기 힘들거나 불가능한 작업을 수행할 수 있다. 예를 들어 하나의 윈폼 라벨 컨트롤에서 여러 종류의 폰트를 사용하거나 굵은 서체, 이탤릭 서체를 사용할 수는 없다. 하지만 WPF는 다음과 같이 단일 TextBlock 컨트롤을 통해 이러한 작업을 간단히 수행할 수도 있다(화면 3 참조). 이 외에도 WPF는 Flex 류의 기술처럼 애니메이션 등을 XAML를 통해 표현 할 수 있다. 2D 그래픽 요소들에 대한 회전, 확대, 축소뿐만 아니라 3D 그래픽적인 요소들도 쉽게 표현할 수 있다.
<TextBlock FontFamily="Calibri"FontSize="11pt">
Hello, <Bold>world!</Bold>
<Span FontFamily="Old English Text MT" FontSize="24pt">This</Span>
is a
<Italic>single</Italic>
<Span FontFamily="Consolas"Foreground="Blue">
<<Span Foreground="DarkRed">TextBlock</Span>/>
</Span>
<Hyperlink>element</Hyperlink>.
</TextBlock>
<화면 2> 리스트1의 XAML을 Windows XP에서 수행한 결과
<화면 3> 단일 TextBlock 컨트롤을 사용하여 다양한 폰트 사용
또한, WPF는 스마트 클라이언트와 비슷한 Web Browser Application(WBA) 기능을 지원한다. 플래시나 Flex와 같이 브라우저 상에서 보다 역동적이고 화려한 UI를 제공하고자 하는 경우, XAML 과 코드를 컴파일 하여 웹 서버를 통해 배포할 수 있다. WPF의 이러한 기능은 닷넷 스마트 클라이언트와는 달리 WinFX가 설치되어 있다면 브라우저에 관계없이 표시될 수 있을 것으로 예상된다.
<화면 4> WPF의 Web Browser Application 예제 화면
그렇다면 WinFX를 사용하면 윈폼 대신 WPF로 애플리케이션을 작성해야 하는가? 그렇지 않다. 그림 1에서 살펴본 대로 윈폼과 WPF는 병렬적으로 존재한다. 즉, 윈폼을 이용할 것인가 WPF를 이용할 것인가는 순전히 독자 여러분의 손에 달려 있다는 말이다. 어떤 윈도우 UI 프레임워크를 사용할 것인가의 결정은 해당 애플리케이션이 어떤 UI를 요구하는가에 따라서 결정하면 된다. 기업의 업무 화면을 다루는 UI라면 윈폼이 좀 더 적당할 것이지만, 3차원 그래픽을 포함한 애니메이션이나 보다 미려한 UI를 요구한다면 WPF가 대안이 될 것이다. WPF를 위해 윈폼을 포기하지는 말자.
WWF; Windows Workflow Foundation
WCF나 WPF는 그에 대응되는 닷넷 기술이 있다. WCF는 XML 웹 서비스와 닷넷 리모팅에 대한 차세대 프레임워크로서, WPF는 윈폼에 대한 차세대 프레임워크로서 간주할 수 있다. 이에 반해 WWF(Windows Workflow Foundation)는 이전의 마이크로소프트 기술에서 찾아볼 수 없는 새로운 워크플로우 프레임워크이다.
WWF는 전자결재와 같이 워크플로우 방식을 따르는 다양한 애플리케이션을 위한 워크플로우 엔진을 제공한다. WWF는 워크플로우를 처리하기 위한 다양한 액티비티(Activity)를 기본으로 제공하고 이러한 액티비티에 의해 정의되는 워크플로우를 수행하는 워크플로우 엔진을 제공한다. 개발자는 특정 워크플로우를 기본 액티비티들과 커스텀 액티비티를 통해 정의할 수 있다. 정의된 워크플로우는 워크 플로우 엔진에 의해 구동되게 된다. 이러한 워크플로우를 설계하기 위해 Visual Studio 2005에서 사용할 수 있는 워크플로우 디자이너와 윈폼에서 사용할 수 있는 워크플로우 디자이너 컨트롤이 제공될 것이라고 한다(화면5 참조).
WWF는 그 자체로서는 아무짝에도 쓸모가 없다. WWF만 있으면 전자결재 엔진을 작성하지 않아도 되는 것이 아니다. WWF를 기반으로 전자결재 워크플로우를 설계하고 개발해야만 WWF 기반의 전자결재 엔진이 생성되는 것이다. 이처럼 WWF는 다양한 워크플로우 기반 애플리케이션이 사용할 수 있는 워크플로우 프레임워크일 뿐이지 그 자체로서 특정 워크플로우를 처리할 수 있는 것이 아님을 명심해야 한다. WWF를 사용하는 최초의 상용 제품은 아마도 Microsoft Office Sharepoint Server 2007(MOSS 2007)이 될 것 같다. MOSS 2007은 기본적으로 간단한 결재(approval)를 처리하는 기능을 탑재하고 있는데 이 결재 기능이 WWF를 사용하여 작성된 것이다.
<화면 5> WWF의 기본 Activity 들과 VS 2005의 워크플로우 디자이너
WWF가 상당히 생소하기 때문에 어렵게 생각할 개발자들이 많을 것이다. 필자 역시 그랬다. 하지만 전혀 어렵게 생각할 필요가 없다. 일단 WinFX 개발환경이 갖추어지면 WWF를 이용하여 워크플로우를 개발하는 것이 얼마나 쉬운 일이 되어 버리는가를 실감하게 될 것이다. 멀티 스레드 방식으로 작동하는 WWF의 워크플로우 엔진은 워크플로우의 상태를 저장하는 능력을 갖고 있다. Visual Studio 2005가 제공하는 워크플로우 디자이너는 워크플로우를 설계하는 직관적인 UI를 제공한다. 필자의 개인적인 생각으로 WWF는 기업 고유의 워크플로우를 구축하고자 하는 수많은 기업들에게 희소식이 될 듯 싶다.
그렇다면 .NET Framework 3.0은 ?
지금까지 WinFX에 대해서 간단히 살펴보았다. WinFX만으로도 벅찬 작금의 상황에서 쌩뚱맞게(?) 닷넷 프레임워크 3.0은 웬 말인가 싶은 독자가 있을는지 모르겠다. 결론부터 말하자면 지난 2006년 6월 마이크로소프트는 WinFX의 이름을 닷넷 프레임워크 3.0으로 지칭하기로 했다. 좀 허탈하지만 닷넷 프레임워크 3.0은 정확하게 WinFX가 이름만 바꾼 것이 되겠다. 물론 WinFX에 포함시키기로 했었지만 포함되지 않았었던 WCS(Windows CardSpace; InfoCard라 불렸었다)가 명시적으로 닷넷 프레임워크 3.0에 포함된 것 외에는 WCF, WPF, WWF는 WinFX의 그것과 전혀 다르지 않다.
그렇다면 닷넷 프레임워크 3.0은 닷넷 프레임워크 2.0에서 돌아가게 되는 것인가? 그렇다. 닷넷 프레임워크 3.0이 설치되기 위해서는 닷넷 프레임워크 2.0이 필요하다. 대개의 경우 새로운 버전이 등장하면 이전 버전과 하위 호환성을 갖지만 이전 버전을 요구하지 않았었다. 닷넷 프레임워크 2.0이 닷넷 프레임워크 1.0/1.1과 무관하게 설치되고 사용될 수 있었듯이 말이다.
하지만 닷넷 프레임워크 3.0은 반드시 닷넷 프레임워크 2.0이 설치되어 있어야만 한다. 이는 닷넷 프레임워크 3.0이 사용하는 CLR의 버전이 2.0임을 의미하고, 닷넷 프레임워크 3.0이 사용하는 클래스 라이브러리 역시 2.0의 클래스 라이브러리이기 때문이다. 이것이 복잡하게 느껴지거나 혼란스럽게 여겨진다면 닷넷 프레임워크 3.0이 단순히 WinFX의 이름을 바꾼 것으로만 생각하면 좀 더 자연스러울 것이다. 그림 2를 살펴보면 개념이 혼란스러운 독자에게 도움이 되리라 생각한다.
<그림 2> 닷넷 프레임워크 3.0 구조
그럼 왜 마이크로소프트는 WinFX의 이름을 닷넷 프레임워크 3.0으로 바꾼 것일까? 빌 게이츠 형한테 물어보지 않아서 정확하진 않지만, 일단 WinFX라는 이름만으로 WinFX가 닷넷과 어떤 연관이 있을 것이라는 생각을 갖기가 매우 어렵다. 필자 역시 Win32의 후계자 쯤으로 생각했으니까 말이다. 게다가 WinFX가 닷넷 프레임워크를 기반으로 하는 차세대 애플리케이션 프레임워크이기 때문에 보다 직관적인 이름으로 닷넷 프레임워크 3.0 이라는 이름을 가지게 되었을 것으로 생각한다. 하지만 닷넷 프레임워크 3.0이 이전 버전으로 생각되는 닷넷 프레임워크 2.0에서 작동하는 것은 여전히 개발자나 IT 프로에게는 혼동을 주게 될 가능성이 높다.
.NET Framework 3.0 개발환경
.NET Framework 3.0에 대해 자료를 찾고자 한다면 http://msdn.microsoft.com/winfx 에 가보는 것이 좋다. 자료도 중요하지만 개발자라면 개발환경을 갖추고 WCF, WPF, WWF에 대한 HelloWorld 프로그램이라도 작성해 보는 것이 더욱 더 중요하다고 본다. 닷넷 프레임워크 3.0을 위해서 Windows Vista가 필요하지 않다. Windows 2003 SP1 혹은 Windows XP SP2를 갖고 있다면 충분하다. 사전에 필요한 소프트웨어로서 닷넷 프레임워크 2.0이 설치되어 있다면 충분하지만 개발 환경을 꾸미기 위해 Visual Studio 2005를 설치하는 것이 좋다. 정식 제품이 아니더라도 무료로 사용할 수 있는 Express Edition을 설치해도 된다. 3.0을 위한 개발환경을 갖추기 위해 베타 버전들이 필요한 독자는 http://msdn.microsoft.com/windowsvista/downloads/products/getthebeta/에서 다운로드 받을 수 있다. 다음 순서대로 설치를 하면 문제 없이 개발 환경을 꾸밀 수 있을 것이다.
* .NET Framework 3.0 Runtime
* Windows SDK
* CodeName “Orcas"Add-in (Visual Studio 2005 용 WPF 디자이너)
* Visual Studio 2005 Extension for WWF (WWF 디자이너 및 디버거 등)
* 옵션 : Microsoft Expression Interactive Designer May 2006 CTP
Windows SDK는 예전에 플랫폼 SDK라 불리던 SDK가 이름이 바뀐 것이다. WPF, WCF, WWF에 대한 도움말과 빌드 환경(VS 2005와 무관하게)을 갖추기 위해서는 Windows SDK를 반드시 설치해야 한다. 이외에 Visual Studio 2005에서 WPF와 WWF에 대한 디자이너 등의 기능을 사용하고자 한다면 두 개의 애드인을 추가로 설치해야 한다.
마지막으로 Microsoft Expression 은 WPF를 위한 디자이너로서 Visual Studio 2005의 디자이너가 제공하지 않는 애니메이션이나 진보된 기능을 손쉽게 디자인하도록 해주는 도구이다. 반드시 필요하지는 않지만 WPF의 다양한 기능을 체험해보고 싶다면 설치를 두려워하지 말자.
세상에는 두 종류의 개발자가 있다. 변화를 귀찮게 생각하고 현재의 기술에 안주하려는 개발자와 변화를 새로운 기회로 삼고 자신의 가치를 높이는 기회로 삼는 개발자. 일찍 일어나는 새가 벌레를 잡는다는 말이 있듯이 개발자들의 세계에서도 빨리 준비하는 개발자가 몸값을 올린다는 말이 있다(필자가 지어낸 말이다. ^^). 짬짬이 시간을 내서 먼저 준비하는 개발자는 그렇지 못한 개발자에 비해 보다 높은 가치를 갖게 될 것임은 당연하지 않은가?
출처 : 마이크로소프트웨어 2006년 10월호