2008. 6. 30. 16:58ㆍSoftware Development/.NET Framework
최근 C#으로 프로젝트를 수행하면서 .NET에 관하여 관심이 많아졌다.
.NET 3.5를 경험하니 앞으로 등장할 WebService와 Application이 어떤 모습으로 달라질 지 조금씩 감이 잡히는 듯 하다.
쏟아져 나오는 MS의 신기술들을 머리 속에 쑤셔 넣으려고 하니 정리가 잘 안 되는 마당에
.NET의 역사와 미래에 대하여 잘 정리 해 놓은 글이 있어서 공유한다.
과연 MS의 프로그래밍 모델 통합은 언제까지 지속될까?
----------------------------------------------------------------------------------------------------------------------------------------
지난번 MSDN 세미나 후기에서 다음과 같은 얘기를 했던 적이 있었습니다.
세미나 종료 후에 저는 극소수의(?) MVP들과 함께 Scott Guthrie와 저녁 식사를 같이 했습니다. 어떻게 보면 세미나 세션에서 나왔어야 했을 법한 얘기가 이 자리에서 좀 나왔었는데요, 자세한 내용은 이번 주 토요일 세미나 준비로 바빠서 세미나 이후에 정리해서 올리도록 하겠습니다.
이 약속을 지키기 위해 내용을 정리해서 적어보도록 하겠습니다. 물론 여기에 나오는 내용은 Microsoft의 공식적인 입장이 아니며, 100% Scott이 한 얘기도 아닙니다. 오히려 그보다는 Scott과 나눈 얘기들을 바탕으로 제가 상당히 많은 살을 붙이고, 제 나름대로의 주관적인 해석 및 견해가 들어간 내용이라는 점을 유념하시고 읽어주시기 바랍니다.
우선 Soctt과 나눈 얘기의 주된 요지는 'Microsoft는 너무나 많은 선택의 기회를 고객에게 제공하는데, 이는 오히려 고객을 헷갈리게 만드는 것 아닌가? 이러한 점에 대한 Microsoft의 입장과 앞으로 개발 플랫폼에 있어서 Microsoft의 비전은 무엇인가?'라는 것이었습니다. 아시다시피 Microsoft는 해마다 수많은 신기술을 쏟아내고, 이를 따라 갈려면 상당히 벅찰 때가 많습니다. 또한 Microsoft가 '이렇게 하면 된다'라는 길을 제시하는 것이 아니라, '이렇게 해도 되고, 저렇게 해도 되고, 또 요렇게 해도 된다'라는 식으로 옵션을 너무 많이 제공한다는 것 역시 고객들과 개발자들을 혼란에 빠뜨리는 원인이 됩니다.
여기에 대한 답변을 짚어보기 위해서 우선 그 동안의 Microsoft의 행보, 즉 '닷넷의 오늘'을 먼저 살펴보고, 그에 따른 전망('닷넷의 내일')을 얘기해보도록 하겠습니다.
1. .NET Framework – 프로그래밍 모델의 통합
우선 .NET Framework가 등장한 의미는 무엇보다도 단일 프로그래밍 모델(Unified Programming Model)을 제시하게 되었다는 것입니다.
처음에는 Windows 응용프로그램을 작성하려면 Windows API를 사용해서 C언어로 작성하는 방법 밖에 없었습니다. 그런데 C++나 Visual Basic처럼 다양한 프로그래밍 언어를 사용하게 되면서 언어가 다양해진 것은 좋긴 하지만, 언어가 달라질 때마다 사용하는 프로그래밍 모델이나 라이브러리도 달라져버리게 되었습니다. 그러나 .NET Framework의 등장으로 어떠한 언어를 사용하던지, 단일한 프로그래밍 모델과 단일한 Base Class Library를 사용하게 되었습니다.
.NET Framework 자체는 2.0 버전까지는 다소의 변화가 있어왔습니다(물론 하위 호환성은 보장됨). 1.1 버전은 1.0의 보안 모델을 수정했고, 2.0 버전에서는 기존의 1.1의 BCL에서 제공되는 몇몇 클래스들이나 메서드를 대치하는 새로운 클래스나 메서드가 등장했습니다.
.NET 2.0 이후부터 BCL은 거의 변화가 없습니다. 대신 과거 WinFX로 불리던 WPF/WCF/WF/CardSpace 기능들이 합쳐져서 .NET 3.0이라고 불리게 되었습니다. 그리고 여기에 ASP.NET AJAX 및 LINQ 등 몇 가지 기능을 추가한 것이 현재의 .NET 3.5 버전입니다.
이 얘기는 .NET 2.0 이후부터는 프레임워크 자체가 안정화 단계에 접어들었으며, 기능의 추가가 있을 뿐 프레임워크 자체의 변화는 사실상 없다는 얘기입니다. 차후에 설명하게 되겠지만, 다음 버전인 .NET 4.0에는 Silverlight이 프레임워크 내에 통합되고, ASP.NET MVC Framework가 추가되며, WPF의 기능 향상이 이루어질 것으로 예상됩니다.
추가적으로 많은 사람들이 .NET Framework가 모든 환경에 적합하지는 않다고 생각하고 있습니다. Windows 기반의 PC나 서버에는 .NET Framework를 사용할 수 있지만, 그 외의 환경에서는 .NET Framework을 사용하지 못하므로, 사실상 프로그래밍 모델이 단일화된 것은 아니지 않냐고 반문합니다. 하지만, 사실 Windows CE나 Windows Mobile과 같이 모바일 및 임베디드 장치를 위한 .NET Compact Framework이 이미 존재합니다. 또한 하드웨어나 디바이스 드라이버와 같은 로우레벨 프로그래밍을 위해 MicroFramework이 개발되고 있습니다. MicroFramework을 사용하면 어셈블리를 사용하지 않고 하드웨어를 제어 가능합니다. 또한 Windows 플랫폼이 아닌 다른 플랫폼에서의 크로스 플랫폼 UI를 위한 Silverlight이 있는데, Silverlight 역시 .NET Framework 기반에 만들어져서 .NET Framework 서브셋과 같은 역할을 하게 됩니다.
2. 커뮤니케이션 모델
원격 통신을 위한 커뮤니케이션 모델 역시 이제 WCF라는 통합된 모델이 존재합니다.
과거에는 소켓, DCOM, Remoting, 웹 서비스, WS-E와 같은 다양한 원격 통신 수단이 있었지만, 각 기술들마다 장단점이 있고 모든 시나리오, 모든 상황을 충족시켜주는 기술은 없었습니다. 하지만 이제 WCF라는 통합 모델이 등장한 이후, 사실상 원격 통신에 있어서는 WCF 이외의 수단은 굳이 생각할 필요가 없게 되었습니다. 다만 이제 남은 일은 WCF가 호환되는 범위를 얼마나 넓혀 가느냐에 달려 있을 것 같습니다. 모든 디바이스나 플랫폼이 WCF를 지원한다면, 앞으로 모든 커뮤니케이션을 위해서는 WCF만 사용하면 만사형통이 되지 싶습니다.
3. Windows 애플리케이션 프로그래밍 모델
Windows 애플리케이션은 오랜 기간만큼 다양한 프로그래밍 모델이 존재해왔습니다.
초기에 Windows 애플리케이션은 WndProc에서 Windows 메시지를 처리하는 메시지 기반이었습니다. 이후 MFC에서는 Command Map 방식의 프로그래밍 모델, Document/View 기반의 모델이 등장했고, Visual Basic에서 폼 기반의 프로그래밍 모델, ATL Window와 같은 다양한 프로그래밍 모델이 생겨났습니다.
이러한 복잡한 프로그래밍 프로그래밍 모델은 .NET으로 넘어오면서 WinForm이라는 단일 프로그래밍 모델로 통합이 됩니다. WinForm은 VB와 같은 폼 기반 프로그래밍 모델을 제공하면서도 OOP 개념을 제공하여 다양한 확장 및 처리가 가능하게 되어 있습니다.
그런데 WinForm으로 애플리케이션을 개발을 하다 보면, WinForm의 원래 정의에 맞게 단순한 폼 형태의 애플리케이션(Simple Form Application)을 작성하는 경우와 Visual Studio와 같이 복잡한 UI를 가진 애플리케이션(Composite UI Application)을 작성해야 할 경우가 생깁니다. 기본 WinForm의 모델로는 이러한 문제에 대응하는 것이 쉽지 않기에 Microsoft는 Pattern & Practice를 통해 CAB(Composite UI Application Block)을 내놓습니다. 또한 보다 화려하고 강력한 UX를 위해 WPF(Windows Presentation Foundation) 역시 추가되었습니다.
이렇게 선택의 여지가 많다 보니, 고객 및 개발자는 어떠한 기술을 사용해서 Windows 응용프로그램을 개발해야 할지 혼동스러워집니다.
현재 단계로서는 UX가 화려할 필요가 없는 업무용 응용프로그램을 만든다면 WinForm을, 업무용 응용프로그램이 아닌 일반 사용자 대상의 UX가 중요한 응용프로그램을 만들 때는 WPF를 권장하고 있습니다. 사실 현재의 WPF는 업무용 응용프로그램을 만드는데 필요한 컨트롤(서드파티 포함)이 절대적으로 부족하여 업무용 응용프로그램을 만드는 데는 적합하지 않습니다. 업무용 응용프로그램 내부에서도 화면 단위로 처리하면 되는 단순 응용프로그램에는 일반 WinForm을, 각 화면이 다른 화면과 유기적으로 연동되는 복잡한 UI에는 CAB을 적용하게 됩니다.
이 문제를 보완하기 위해 우선은 다음과 같은 방향으로 나아가게 될 것입니다.
WPF에서도 업무용 응용프로그램을 만들 수 있도록 컨트롤을 보강한다.
한 애플리케이션 내에서 WPF와 WinForm을 혼합해서 사용한다.
WPF에서도 Composite UI를 지원한다.
하지만 궁극적으로는 이전의 프로그래밍 모델의 통합이나 커뮤니케이션 모델의 통합처럼, Windows 애플리케이션을 만드는 것 역시 하나의 모델로 통합이 될 가능성이 높습니다. 항상 그렇듯이 통합된 모델의 모습은 가장 마지막에 나온 것에 최대한 가까울 것입니다. 이를 예측해볼 때 WPF가 WinForm 및 CAB의 기능들을 흡수하는 형태로 진행될 것입니다.
4. Web 애플리케이션 프로그래밍 모델
웹 애플리케이션은 상당한 많은 기술들이 나왔지만, 웹의 기본적인 한계에 부딪쳐서 정체 상태이다가 최근에 AJAX나 RIA와 같이 웹의 한계를 극복하기 위한 다양한 방법들이 시도되고 있는 상황입니다.
우선 이를 위해 그 동안 Microsoft의 웹 애플리케이션 관련 기술들을 살펴보도록 합시다. 기술들의 계보를 그리면 대략 다음과 같습니다.
ISAPI라는 2세대 웹 애플리케이션 기술은 ISAPI 계보의 적자(?)인 ATL 서버와 여기서 보다 진화한 3세대의 스크립트 계열인 ASP로 분화됩니다. ATL 서버는 사실 높은 성능을 낼 수 있지만, 워낙 다른 개발 모델에 비해 상대적으로 불편하고 무엇보다 ATL을 다룰 줄 아는 C++ 웹 개발자를 찾기 힘든 턱에, Microsoft의 Live ID(구 Passport)를 빼고는 이제 찾기가 어렵게 되어 버렸습니다. (그 덕분인지 VS2008에서는 ATL Server라는 프로젝트 템플릿이 별도로 존재하지 않습니다. 아예 없어진 건 아니고 ATL Project 프로젝트 템플릿 안으로 통합된 듯 하네요)
ASP는 ASP.NET으로 발전하여, 잘 아시는 것처럼 코드 비하인드 모델, PostBack 개념, 서버 컨트롤 등과 같이 많은 향상을 가져옵니다. 1.0, 2.0을 거쳐, 코드명 Atlas라고 불리던 ASP.NET AJAX가 출시되고, ASP.NET 3.5에 통합이 됩니다. 현재 ASP.NET에는 ASP.NET에 MVC 패턴을 적용한 MVC(Model-View-Controller) Framework가 기획되고 있습니다. 여기에 대한 자세한 내용은 Scott의 블로그에 있는 ASP.NET MVC Framework를 참조하시기 바랍니다. 물론 MVC Framework 역시 ASP.NET 3.5와 통합되어 ASP.NET 4.0 등이 되지 않을까 싶습니다.
여기서 잠깐 Microsoft가 ASP.NET 2.0에서 순간의 선택을 잘못하면서 상당한 시행 착오를 겪게 된 얘기를 해봅시다. ASP.NET 2.0에서 가장 큰 실수 중 하나는 웹 사이트(Web Site) 모델이라는 것을 내놓았다는 것입니다. 물론 이걸 내놓은 것 자체가 잘못은 아니지만, 문제는 기존에 존재하던 웹 애플리케이션 프로젝트(Web Application Project) 모델을 없애버렸다는 것이었습니다. 이것 때문에 발생하는 일들에 대한 자세한 내용은 제 블로그에서 Visual Studio 2005 Web Application Project Preview라는 포스트를 읽어보시기 바랍니다. Scott 역시 이 얘기가 나오니 한숨을 푹푹 쉬면서 '그때 정말 왜 그런 결정을 내렸는지 후회한다'라고 하더군요.
그리하여 부랴부랴 Visual Studio 2005 Web Application Project Preview를 내놓아서 웹 애플리케이션 프로젝트 모델을 부활시키고, Visual Studio 2005 SP1에서 정식으로 포함시켰습니다. Visual Studio 2008 및 ASP.NET 3.5에는 당연히 이 모델이 포함되어 있으며, AJAX 역시 통합되어 있습니다. 따라서 현재 VS2008 및 ASP.NET 3.5에서는 웹 애플리케이션을 개발할 때 웹 애플리케이션, 웹 사이트, AJAX 웹 애플리케이션 중 어느 것을 만들지 선택해야 합니다.
위와 관련해서 컴파일 모델 및 코드비하인드 얘기도 잠깐 해봅시다. ASP는 코드를 인라인으로 작성하고, 해당 코드는 인터프리팅 방식으로 처리되었습니다. ASP.NET 1.0에서는 코드 비하인드라는 개념을 통해 별도의 파일에 코드를 작성하고, 애플리케이션 프로젝트 내의 코드 비하인드 코드는 컴파일되어서 단일한 어셈블리로 들어가게 되었습니다. 물론 ASPX에 인라인 형태로 코드를 작성하는 것 역시 가능하며, 이는 동적으로 컴파일 되게 됩니다.
그런데 ASP.NET 2.0에서는 웹 사이트 모델로 변경되면서 코드 비하인드가 아닌 코드 비사이드(Code Beside)라는 개념을 사용하게 됩니다. 즉 ASPX에 대응되는 ASPX.cs가 동적으로 컴파일되는 방식으로 바뀌었습니다(웹 사이트 모델에서는 동적 컴파일 모델을 사용할 수 밖에 없습니다). 이 문제는 역시 마찬가지로 VS2005 SP1부터 웹 프로젝트 모델이 다시 부활하면서 예전으로 돌아오게 됩니다.
사실 이 문제는 별 것 아닌 것 같지만, 수많은 기존 ASP.NET 개발자들을 혼란에 빠뜨렸습니다. 저 역시 1.x로 개발된 프로젝트를 2.0으로 옮겼다가 엄청난 낭패를 본 적이 있었습니다(웹 애플리케이션 프로젝트가 다시 나온 지금에는 문제가 없지만요). 그러다 보니 '1.x로 개발된 것을 2.0으로 옮기면 안 된다, ASP.NET 1.x와 2.0이 호환이 안 된다더라'라는 소문이 퍼지면서 지금도 ASP.NET 1.x를 사용 중인 많은 기업들이 2.0으로 전환하지 못하는 이유 중 하나가 되어 버렸습니다.
어찌되건 현재, 그리고 조만간 ASP.NET 개발자들은 페이지 프로그래밍 모델에 있어서도 3가지 중 하나의 선택을 해야 합니다. ASP의 단순 Get/Post 방식 모델은 ASP.NET에서 서버 컨트롤과 이벤트 기반 프로그래밍으로 변경되었습니다. 그런데 클라이언트 측에서의 사용자 동작을 서버 쪽 이벤트와 연동해서 처리하는 방식이 3가지가 된 것입니다.
첫번째, ASP.NET의 기본 모델에서는 이를 PostBack을 통해 처리하게 됩니다. PostBack 모델은 간편하긴 하지만, 페이지가 다시 재전송되고 ViewState 때문에 발생하는 문제 등이 존재합니다. 두번째로, AJAX 모델은 PostBack 모델의 문제를 보완하는 대신에 아무래도 프로그래밍이 다소 복잡하다는 문제가 있습니다. 아무리 ASP.NET AJAX와 같이 사용하기 쉬운 AJAX 프레임워크가 있다고 하더라도 이전에 비해 복잡한 것은 사실입니다. 마지막으로 곧 등장하게 될 MVC 모델도 있습니다. 이 모델은 개념 상으로는 좋지만, MVC 개념을 이해하지 못하는 개발자에게는 어려울 수도 있을 것 같습니다. 이렇게 볼 때 ASP.NET 역시 PostBack, AJAX, MVC 모델의 장점만을 취합하여 단일한 모델로 통합이 되지 않을까요?
마찬가지로 ASP.NET이 해결하고 있지 못한 문제 중 하나는 서버 측 프로그래밍 모델은 많은 개선을 했지만, 웹 클라이언트 쪽에 대해서는 개선을 하지 않고 있다는 점입니다. Microsoft는 웹 클라이언트 UI의 개선을 Silverlight을 통해 꾀하고 있는데, Silverlight 역시 클라이언트 측 단독보다는 서버 측의 ASP.NET과 유기적인 결합이 될 것으로 예상됩니다.
특히 Silverlight이 1.0에서 AJAX만 지원하던 것에 비해 1.1에서는 SOAP/REST/WCF 등을 지원하고 차기 2.0에서는 모바일 쪽에서도 구동이 될 것이라고 하더군요.
결론 : 닷넷의 내일은..?
지금까지 살펴본 내용들을 바탕으로 큰 그림을 한번 그려봤습니다. 이미 통합이 된 프레임워크 레벨에서의 프로그래밍 모델 통합이나, 커뮤니케이션 모델 통합은 제쳐두고 Windows와 Web이라는 환경을 기반으로 그려본 결과, 다음과 같습니다.
지금까지 .NET의 전략과 진행되어온 행보를 볼 때, 지금까지가 또 하나의 새로운 선택을 제공하는 과도기였다면, 다음은 이들의 장단점을 취합하여 보다 나은 통합을 이룩하는 것이라고 생각됩니다. 즉, Windows 쪽 기술, Web 쪽 기술이 각각 통합되고, 궁극적으로는 Windows 환경과 Web 환경의 통합 또는 자연스러운 결합이 Microsoft가 생각하는 비전이 아닌가 싶습니다.
앞에서도 언급했듯이, 아마 통합되는 것은 지금까지 나온 기술 중에 가장 최근의 기술에 가장 가까울 것입니다. 이 포스트에서 설명한 내용들을 읽어가다 보면 앞으로 메인 스트림이 될 기술이 어떤 것이 될지는 대략적으로 파악할 수 있지 않을까 싶습니다. 물론 메인 스트림 속에 있을지, 자기만의 길을 걸을지는 여러분의 선택이겠지요.
http://blog.naver.com/saltynut/120047488994
Written by 안재우(Jaewoo Ahn), 닷넷엑스퍼트(.netXpert)