Windows Form 이후, WPF라는 물건을 접하면 대단히 놀라게 된다. 일단, WPF를 위시한 .NET Framework 3.0이 과거 WinFX로 알려졌던 것처럼, 20년간 윈도우 프로그래밍을 지배해온 Win32 기반의 프로그래밍이 드디어 대체되나 하는 기대를 했으니 말이다. WinFX라는 단어를 처음 들었을 때는, 확실히 그 이름에서 Win32의 후계자라는 느낌이 강했으니 무리는 아니다. 결국, WinFX는 Win32의 후계자가 아니라 .NET Framework에서 돌아가는 녀석이라는 것을 알았을 때 그 아쉬움이란..
그동안 윈도우에서 뭔가 UI 작업을 하려면 귀찮음의 연속이었다. 사실 경험있는 개발자라면, C#으로 .NET Framework에서 Windows Form 이벤트 핸들러를 추가하나 MFC의 Framework에서 핸들러를 추가하나 별 차이는 없다. 작업량이 조금 늘어나던지, 줄어들던지 하는 문제일 뿐이지, 근본적인 차이는 없다. 하지만, WPF는 조금 다르다. WPF에서 가장 끌리는 기능이라고 한다면, 로컬 클라이언트에서 독립적으로 실행될 수도 있고, 브라우저에서 호스팅 될 수도 있다는 것이다. 앞으로의 웹 서비스라는 것을 생각해본다면, 이것은 대단한 장점이 아닐 수 없다.
즉, 이때까지는 웹 기반의 뭔가를 개발하는 것과, 완전히 윈도우 응용 프로그램을 작성하는 것은 두가지 다른 기술을 요구했고, 이 말은 나쁜 경우 두 명의 개발자를 필요로 한다는 것이다. 그렇지만, WPF로 작업한다면, 같은 코드가 독립적으로, 그리고 브라우저에서도 호스팅된다는 말이므로 한 명의 개발자가 코드를 관리한다는 말이 된다. 여기에, MS의 약속대로 WPF/E가 다른 플랫폼에도 구현된다면.. 그야말로 엄청난 가능성을 가지는 것이다. 강력한 벡터 기반의 그래픽 엔진, 3D 표현 기능.. 놀랍지 않은가? Win32 기반의 프로그래밍 방식이 지난 20년간 윈도우 프로그래밍을 지배해왔다면, WPF라는 새로운 UI 접근법은 MS에서 말하는대로, 향후 20년간 윈도우 프로그래밍을 지배할 새로운 패러다임인 것이다!
Windows Forms이라는 것도 기존의 MFC 기반의 개발 방식과 비교해봤을 때 근본적으로 엄청난 변화를 가져온 것은 아니었다. GDI+의 기능도 좋긴 하지만, 기존의 GDI를 자체적으로 확장해서 사용해도 충분했고, GDI+가 GDI와 비교해서 획기적으로 변한 것은 아니었기 때문에 Win32API / MFC 방식에서 옮겨갈 필요성을 굳이 느끼지 못했다.
WPF라는 것이 엄청난 물건이기는 하지만, 단 한가지, 최대의 장벽은 바로 기존 윈도우 사용자층이 .NET이란 패러다임의 변화를 몸으로 느끼지 못하고 있다는 점이다. 다시 말해, XP 환경에 만족하는 사용자가 대부분이다. 비스타가 화려한 에어로 인터페이스로 기존 사용자를 유혹하고 있지만, 태생적으로 공룡과 같은 몸집이라 가볍지 않고, 오히려 하위 호환성에서 XP를 따라가지 못하는만큼 (당연하다) 확산에 실패하고 있는 모습이다. 그리고, 더 중요한 것은 비스타가 요구하는 하드웨어 스펙을 대부분의 사용자가 부담스러워 하고 있는 것이다. 에어로 인터페이스를 만끽하기 위해서는 최소 128MB의 비디오 메모리를 장착한 그래픽 카드가 필요하며, 메모리도 4GB 정도가 있어야 불편함이 없다는 것이 중론이다. 비스타가 출시된지 1년이 지난 지금, 하이엔드 사용자들은 이 사양을 대부분 만족하겠지만, 대부분의 사용자들의 컴퓨터에게는 아직도 버겁기만 한 사양이다.
그리고, 개발자의 관점에서 봤을 때, WPF가 구동되기 위한 라이브러리는, MFC가 필요로 하는 라이브러리 크기와 비교할 바가 안된다. 942KB라는 MFC 라이브러리 크기는 없는 것과 같을 정도이다. 거기에, .NET Framework기반이라 중간언어로 컴파일되며, JIT의 존재를 생각한다고 하더라도 Native Win32 프로그램에 비교하면 확실히 느리다. 물론, 그 강력한 UI 구성 기술과 그 장점을 생각한다면 충분히 트레이드-오프 관계가 될 수 있겠지만, 개발자들 사이에서도 WPF라는 존재로 언제 넘어가야 하는가는 논란거리다.
하지만, 분명히 생각하건데, WPF는 일반적인 모든 UI 프로그래밍을 대체할 수 있을 정도로 강력하다. 시간 문제일 뿐, 어느 플랫폼에서나 실행 가능하고, 기존 개발 방식보다 더 직관적이며 통합적인 WPF는 대부분의 윈도우 UI 프로그래밍을 대체할 것이다. 아직 '죽여주는 WPF 프로그램'이 나오지 않아서 그렇지, 이것이 출현한다면 사용자들이 급속하게 플랫폼을 .NET에 최적화된 비스타 이상의 윈도우 운영체제로 이동할 것이다. 그리고, 비스타가 요구하는 하드웨어 사양도, 하드웨어 발전 속도를 생각한다면 앞으로 그렇게 무리한 사양은 아니다. 또, 무엇보다 개발자 입장에서 WPF로 구현할 수 있는 것을 기존 방식으로 구현하려면 너무나 힘들기 때문이다.
다만, WPF가 대세를 장악하더라도 가볍고 빠른 Native Win32 프로그램에 대한 수요는 있을 것이다. MFC는 더 이상 MS에서 전략적인 개발환경이 아니기 때문에 이 요구에 대응할지 안할지는 모르겠지만, MFC가 여전히 이런 요구에 대해 검증된 물건이다. 물론, ATL/WTL과 같은 현대적이고, 가벼운 라이브러리에 비한다면 MFC는 완전한 해결책은 아니며. MS는 .NET이 모든 것을 해결할 수 있다는 생각일지도 모르겠다. 하지만, 결국 가볍고 빠르면서도, .NET보다 저수준에서 동작하는 SDK / MFC보다 더 나은 방법에 대한 요구가 .NET으로 해결되지 않는다는 것을 깨닫는다면, 뭔가 새로운 솔루션이 나올지도 모르겠다. Win64 API 팀에서 뭔가 새로운 것을 내놓았으면 좋겠지만, 그럴 가능성은 대단히 낮아 보인다.
그동안 윈도우에서 뭔가 UI 작업을 하려면 귀찮음의 연속이었다. 사실 경험있는 개발자라면, C#으로 .NET Framework에서 Windows Form 이벤트 핸들러를 추가하나 MFC의 Framework에서 핸들러를 추가하나 별 차이는 없다. 작업량이 조금 늘어나던지, 줄어들던지 하는 문제일 뿐이지, 근본적인 차이는 없다. 하지만, WPF는 조금 다르다. WPF에서 가장 끌리는 기능이라고 한다면, 로컬 클라이언트에서 독립적으로 실행될 수도 있고, 브라우저에서 호스팅 될 수도 있다는 것이다. 앞으로의 웹 서비스라는 것을 생각해본다면, 이것은 대단한 장점이 아닐 수 없다.
즉, 이때까지는 웹 기반의 뭔가를 개발하는 것과, 완전히 윈도우 응용 프로그램을 작성하는 것은 두가지 다른 기술을 요구했고, 이 말은 나쁜 경우 두 명의 개발자를 필요로 한다는 것이다. 그렇지만, WPF로 작업한다면, 같은 코드가 독립적으로, 그리고 브라우저에서도 호스팅된다는 말이므로 한 명의 개발자가 코드를 관리한다는 말이 된다. 여기에, MS의 약속대로 WPF/E가 다른 플랫폼에도 구현된다면.. 그야말로 엄청난 가능성을 가지는 것이다. 강력한 벡터 기반의 그래픽 엔진, 3D 표현 기능.. 놀랍지 않은가? Win32 기반의 프로그래밍 방식이 지난 20년간 윈도우 프로그래밍을 지배해왔다면, WPF라는 새로운 UI 접근법은 MS에서 말하는대로, 향후 20년간 윈도우 프로그래밍을 지배할 새로운 패러다임인 것이다!
Windows Forms이라는 것도 기존의 MFC 기반의 개발 방식과 비교해봤을 때 근본적으로 엄청난 변화를 가져온 것은 아니었다. GDI+의 기능도 좋긴 하지만, 기존의 GDI를 자체적으로 확장해서 사용해도 충분했고, GDI+가 GDI와 비교해서 획기적으로 변한 것은 아니었기 때문에 Win32API / MFC 방식에서 옮겨갈 필요성을 굳이 느끼지 못했다.
WPF라는 것이 엄청난 물건이기는 하지만, 단 한가지, 최대의 장벽은 바로 기존 윈도우 사용자층이 .NET이란 패러다임의 변화를 몸으로 느끼지 못하고 있다는 점이다. 다시 말해, XP 환경에 만족하는 사용자가 대부분이다. 비스타가 화려한 에어로 인터페이스로 기존 사용자를 유혹하고 있지만, 태생적으로 공룡과 같은 몸집이라 가볍지 않고, 오히려 하위 호환성에서 XP를 따라가지 못하는만큼 (당연하다) 확산에 실패하고 있는 모습이다. 그리고, 더 중요한 것은 비스타가 요구하는 하드웨어 스펙을 대부분의 사용자가 부담스러워 하고 있는 것이다. 에어로 인터페이스를 만끽하기 위해서는 최소 128MB의 비디오 메모리를 장착한 그래픽 카드가 필요하며, 메모리도 4GB 정도가 있어야 불편함이 없다는 것이 중론이다. 비스타가 출시된지 1년이 지난 지금, 하이엔드 사용자들은 이 사양을 대부분 만족하겠지만, 대부분의 사용자들의 컴퓨터에게는 아직도 버겁기만 한 사양이다.
그리고, 개발자의 관점에서 봤을 때, WPF가 구동되기 위한 라이브러리는, MFC가 필요로 하는 라이브러리 크기와 비교할 바가 안된다. 942KB라는 MFC 라이브러리 크기는 없는 것과 같을 정도이다. 거기에, .NET Framework기반이라 중간언어로 컴파일되며, JIT의 존재를 생각한다고 하더라도 Native Win32 프로그램에 비교하면 확실히 느리다. 물론, 그 강력한 UI 구성 기술과 그 장점을 생각한다면 충분히 트레이드-오프 관계가 될 수 있겠지만, 개발자들 사이에서도 WPF라는 존재로 언제 넘어가야 하는가는 논란거리다.
하지만, 분명히 생각하건데, WPF는 일반적인 모든 UI 프로그래밍을 대체할 수 있을 정도로 강력하다. 시간 문제일 뿐, 어느 플랫폼에서나 실행 가능하고, 기존 개발 방식보다 더 직관적이며 통합적인 WPF는 대부분의 윈도우 UI 프로그래밍을 대체할 것이다. 아직 '죽여주는 WPF 프로그램'이 나오지 않아서 그렇지, 이것이 출현한다면 사용자들이 급속하게 플랫폼을 .NET에 최적화된 비스타 이상의 윈도우 운영체제로 이동할 것이다. 그리고, 비스타가 요구하는 하드웨어 사양도, 하드웨어 발전 속도를 생각한다면 앞으로 그렇게 무리한 사양은 아니다. 또, 무엇보다 개발자 입장에서 WPF로 구현할 수 있는 것을 기존 방식으로 구현하려면 너무나 힘들기 때문이다.
다만, WPF가 대세를 장악하더라도 가볍고 빠른 Native Win32 프로그램에 대한 수요는 있을 것이다. MFC는 더 이상 MS에서 전략적인 개발환경이 아니기 때문에 이 요구에 대응할지 안할지는 모르겠지만, MFC가 여전히 이런 요구에 대해 검증된 물건이다. 물론, ATL/WTL과 같은 현대적이고, 가벼운 라이브러리에 비한다면 MFC는 완전한 해결책은 아니며. MS는 .NET이 모든 것을 해결할 수 있다는 생각일지도 모르겠다. 하지만, 결국 가볍고 빠르면서도, .NET보다 저수준에서 동작하는 SDK / MFC보다 더 나은 방법에 대한 요구가 .NET으로 해결되지 않는다는 것을 깨닫는다면, 뭔가 새로운 솔루션이 나올지도 모르겠다. Win64 API 팀에서 뭔가 새로운 것을 내놓았으면 좋겠지만, 그럴 가능성은 대단히 낮아 보인다.