90년대 주로 클라이언트의 응용 프로그램, 간혹 서버에서 CGI 프로그램을 개발하면서 많이 사용했었습니다. Visual Studio 환경에서 C++프로젝트에서, 완전히 Win32 API 함수들만 이용하여 응용 프로그램을 만드는 것이 쉬운 일은 아니었습니다. 프로그램에 사용자 인터페이스(GUI)를 위한 컨트롤이 추가되기라도 한다면, 해당 컨트롤에 대한 이벤트 메시지 처리를 일일이 구현해 주어야 했고, 어떤 Win32 API 함수를 사용하기 위하여 부가적으로 작성해야 하는 코드의 양도 상당히 많았습니다. 이런 환경에서 MFC 라이브러리는 매우 좋은 선택이 아닐 수 없었습니다. Win32 API 함수들을 자세히 알지 못하는 상황에서 좀 더 빠르게, 안전하고, 견고한 코드를 생성할 수 있는 탁월한 선택이었습니다.
세월이 흘러 .NET 프레임워크가 만들어 지고, 이전 개발 도구(Visual Studio 6.0)과는 전혀 다른 모양의 개발 도구와 개발 언어들이 나타나게 되었습니다. 당시 C++ 프로젝트를 주로 하던 상황에서 새로운 개발 환경은 매우 흥미로웠습니다. Win32 기반의 프로그램 언어에도 무엇인가 신선하고, 자극이 될만한 것들이 나타날 줄 알았습니다. 하지만, 기대가 크면 실망도 큰 것이었나요? MFC 라이브러리는 큰 변화가 없었습니다. Visual Studio 버전이 올라갈 때 몇 개의 클래스가 추가된 것을 빼면, 큰 변화가 없었습니다.
컴퓨터 사용환경이 점점 좋아지고, 날이 갈수록 증가되는 사용자들의 화려하고 편리한 인터페이스(GUI) 요구를 충족하기에 MFC 라이브러리는 너무도 빈약할 수 밖에 없었습니다. 할 수 있는 일이라고는 시스템에서 기본적으로 제공하는 컨트롤을 이용하는 것이 전부였습니다. 그래서, 많은 프로그래머들은 확장된 컨트롤들을 구매하거나, 스스로 제작하여 인터페이스를 구현하였습니다. 아마도 대부분의 사람들이 사용했었던 라이브러리가 “XTreme Toolkit(http://www.codejock.com/)”, “BCGControlBar(http://www.bcgsoft.com/)”, “Ultimate Toolbox(http://www.dundas.com/)”, “Prof-UIS (www.prof-uis.com) “, GuiToolkit(http://www.beyondata.com/”)……
현재 어떤 회사의 라이브러리들은 소스 코드를 포함하여, 무료로 공개까지 하기에 이르렀습니다.
Visual Studio 2008 버전이 발표되기 전부터, 많은 C++ 개발자들을 흥분 시킨 사건이 하나 발생됩니다. 당시 한국 마이크로소프트에서는 대대적인 홍보를 하고 세미나도 진행했습니다.
정말 10년 만에 획기적인 변화가 발생하는 줄 알았습니다. 그러나, 이번에는 제대로 실망을 하지 않을 수 없었습니다. MFC 라이브러리의 확장……
http://msdn.microsoft.com/ko-kr/visualc/bb892882(en-us).aspx
“BCGControlBar”, 이 라이브러리는 이미 Visual Studio 6.0 시절부터 줄기차게 GUI 응용 프로그램을 개발 하면서 사용했던 것입니다. 당시 OpenSource 기반으로 “BCGControlBar” 프로젝트가 존재하였고, 저 역시 미약하나마 코드 개발에 참여했었습니다. 그러던 어느날 BCGSoft 사에서 상용화 한다는 비보를 전달 받았습니다. 전 세계의 많은 개발자들에 의해서 하나씩 쌓아온 결과물을 이용하여, 돈을 벌겠다는 회사를 보면서 씁쓸하기 그지 없었습니다.
많은 개발자들이 MFC 라이브러리에 “BCGControlBar”가 포함되는 것에 대해 불만을 토로했습니다.
정작 개발자들이 원했던 것은 마이크로소프트에서 Office 응용 프로그램이나 Visual Studio 프로그램을 제작할 때 사용한 코드였습니다. (office 설치 디렉터리에서 종종 발견되는 OMFC.DLL 정체가 궁금했습니다., 저 역시 이 파일을 사용해 보려고 많은 시도를 했었습니다.)
사실 “BCGControlBar”보다 더욱 뛰어난 GUI 라이브러리가 많았습니다. 또, “BCGControlBar”에 의하여 증가되는 MFC90xxx.DLL 파일의 크기가 부담이 될 수도 있습니다. 기존의 “mfc42.dll” 파일의 크기가 995,383 바이트인데 비하여, “mfc90.dll(x86)” 파일의 크기는 무려 3,768,312 바이트나 됩니다. 사실 Visual Studio 2008 패키지에 넣거나 빼거나 하는 문제보다는 MFC90xxx.DLL 파일에서 분리해달라는 요구가 국내외적으로 상당히 많았습니다. 철저히 무시 당했습니다.
Visual C++ Team Blog:
http://blogs.msdn.com/vcblog/archive/2007/11/09/quick-tour-of-new-mfc-functionality.aspx
화려하고, 사용자의 요구에 부합하는 다양한 GUI 환경을 구현하기에 MFC 라이브러리는 한계가 상당히 많습니다. 마이크로소프트와 몇몇 MS 신봉자들은 고작 “BCGControlBar”를 MFC 라이브러리에 추가한 것을 가지고, 마치 MFC 라이브러리에 대단한 혁신이 있는 것처럼 이야기합니다.
그런 부가적인 라이브러리가 추가되지 않았더라도, 충분히 그런 GUI 구현은 가능했습니다.
부분적이긴 하지만 이미 오픈 소스로 작성된 MFC 확장 컨트롤이 상당히 존재하였고, 기존의 상용 코드를 소스까지 공개한 회사도 있습니다. (GuiToolkit MFC Extension, Ultimate ToolBox)
이렇게까지 된 것은, 대부분의 개발 환경의 패러다임은 이제 거의 .NET 프레임워크로 자리매김을 했기 때문일 것입니다. 특수한 분야가 아니면, 대부분은 더 이상 복잡하고 어려운 C/C++ 언어로 프로젝트를 수행하는 일이 거의 없습니다.
.NET Framework WinForm 또는 WPF GUI 응용 프로그램을 개발해보면, 더 이상 Win32, MFC GUI 응용 프로그램을 개발할 일이 없을 듯합니다.
그러나, 앞으로도 C/C++ 언어는 높은 성능과 견고함을 요구하는 응용프로그램의 개발에 사용될 것입니다. 만일 이런 프로그램에서 GUI 기능을 요구한다면, MFC 라이브러리는 하나의 좋은 대안이 될 수 있습니다. Microsoft 사에서 “BCGControlBar”를 MFC 라이브러리에 포함시킨 점에 대한 실망은 매우 크지만, 마이크로소프트의 거대한 헤게모니에 대항할 수 없기에 그저 사용하는 것입니다.
2000년대에 들어 C++ 프로젝트를 진행하면서, MFC 라이브러리의 사용은 매우 자제했습니다. MFC42.DLL 파일을 사용할 때에도 그랬지만, 가능하면 Win32 API 함수를 직접 사용했던 일이 많고, WTL 정도를 MFC 대용으로 사용했었습니다. 이렇게 하면, 사실 MFC 라이브러리를 사용할 때보다, 응용 프로그램은 더욱 최적화되기 때문입니다. 동일한 프로그램을 개발하여 보면 대부분Win32 > WTL >> MFC 순으로 그 성능이 나타날 것입니다.
토요일 오후에 뭐 할까하다가, 그냥 끄적댔습니다.
I'm on your side, when times get rough. 