Microsoft Foundation Classes
MSDN의 MFC 페이지
1. 개요
Microsoft Windows 운영체제 환경에서 작동하는 GUI 응용프로그램을 개발하기 위한 C++ 언어 기반의 GUI 라이브러리로, 1992년 발표되었다.Windows API의 C언어 함수들을 Wrapping 하여 C++ 언어의 클래스화 한 라이브러리이다. 윈도우 환경에서 COM(Component Object Model) 개발을 위한 라이브러리인 ATL(Active Template Library)과 CString 등의 기반 클래스를 공유하는 등 매우 밀접한 관련이 있다.
별도의 라이브러리 없이 윈도우즈용 GUI 응용프로그램을 개발하려면 운영체제가 제공하는 C언어 기반의 Windows API를 써야 하는데, 단순히 운영체제의 여러 기능들을 노출시켜주는 C 함수들의 집합일 뿐이기 때문에 복잡한 UI를 작성하는 등의 고차원적인 작업을 할 때에는 필연적으로 코드 노가다가 수반된다. 그리고 최신의 윈도 컨트롤과 같은 고차원적인 기능들은 Windows API가 아닌 COM 라이브러리로만 쓸 수 있기 때문에 Windows API만으로는 한계가 있다. 그래서 이걸 그나마 좀 편하게 클래스 형태로 쓸 수 있도록 해주는 것이 바로 MFC이다.
비주얼 스튜디오의 유료 버전과 Community(개인 사용자용)에는 기본으로 포함되어 있다. 무료인 'Express' 버전에는 MFC와 ATL이 포함되지 않으나 Express 버전 자체가 단종되었다.
2. 사용 목적
Microsoft Windows용 GUI 응용프로그램을 개발하기 위해 사용되었다. C언어 기반의 Windows API를 직접 사용할 수도 있으나, C++언어 기반의 MFC를 사용할 경우 Win32 API로 C 프로그래밍을 하는것보다는 쉽기 때문에 1990년대 부터 2000년대 중반까지 윈도우즈용 GUI 응용프로그램 개발을 위한 라이브러리로 사용되었었다[1].현재는 과거 개발된 어플리케이션 및 라이브러리의 유지보수가 주된 용도이다. 해외의 경우 MFC 개발자 수요가 아직도 약간 있으나 국내에는 MFC 프로그래머에 대한 수요는 유지보수를 제외하곤 없다. 웹과 모바일 환경이 대두되었을뿐만 아니라, 데스크톱 응용프로그램의 개발 환경도 .NET Framework를 기반으로 하는 WinForms, WPF 등과 웹을 기반으로 하는 Electron 등이 등장하면서 더이상 신규 개발 프로그램에서 굳이 MFC를 선택할 필요는 없게 되었다.
MS에서 개발하는 프로그램 중 Microsoft Office나 윈도 운영체제 자체 등 일반 사용자에게 제공되는 제품은 MFC를 사용하지 않는다. MFC를 사용하여 개발된 것 중 가장 유명한 것은 Visual Studio 6.0에 포함되어 있는 Visual C++ 6.0 IDE일 것이다. 하지만 .NET Framework가 발표되면서 현재의 Visual Studio는 닷넷의 WPF로 개발되고 있다.
3. 단점
- 비주얼 스튜디오 2022 버전에서도 여전히 사용 가능하나, 메이저 버전업은 비주얼 스튜디오 2015 시절의 MFC 14에서 멈춰있고 마이너 업데이트만 제공되는 상황이다.
- 과거에는 델파이나 VB에 비해 윈도 응용프로그램 개발기간이 상대적으로 긴 대신 퍼포먼스에 비교적 유리했기 때문에 수요가 많았으나, 시간이 갈수록 컴퓨터 환경의 발전으로 퍼포먼스 문제가 상대적으로 덜해지고, 생산성 측면에서 유리한 C#, Electron 같은 강력한 대체재가 등장함으로서 현재는 채용 시장에서 순수 MFC 개발자를 찾는 수요가 국내외를 막론하고 많이 줄어들었고, 점점 더 줄어드는 추세이다.
- 순수하게 C언어로 Win32 API를 사용하여 개발한 프로그램에 비하면 무겁다. 물론 Qt나 GTK+와 비교한다면야...
- ATL과 공유되는 CString, CList 등의 클래스는 매우 강력하지만, GUI를 위하여 제공되는 기능은 Windows API의 매우 얇은 Wrapper 정도이다. 게다가 MFC로 개발한다고 해서 Windows API를 쓰지 않을 수도 없다.
- Visual C++ 2008 Feature Pack에서 추가된 리본 인터페이스는 Microsoft Office와 비교해 보면 매우 엉성하고 조잡한 티가 난다. 이는 해당 클래스들이 MS에서 제작된 것이 아니라 타사(http://www.bcgsoft.com/)에서 제작한것을 MS가 구입하여 포함시켰기 때문이다.
- GUI 디자인 기능이 매우 부실하다. 직접 UI를 그려서 설계할 수 있는 부분은 "윈도 리소스"라는 매우 특이한 형식으로 처리되는 다이얼로그(대화상자)만 가능하며, 일반적인 화면은 직접 코드로 구현해야 한다. VB6.0이나 닷넷의 WinForm/WPF, Qt의 QtDesigner 등과 비교하면 이뭐병 소리가 절로 나온다.
물론 웬만한 C++ 무료 GUI라이브러리가 이런 편집 툴도 없는걸 생각하면 선녀다 - 닷넷 출시 이후로 MS로부터 버려졌다는 소문이 있다. 실제로 VS2008 이후부터 MFC에 큰 변화가 없어졌고, VS2012까지는 MFC가 탑재되어 릴리스 되었지만 VS2015부터는 따로 패키지를 설치해서 사용해야 한다. 다만 VS2017부터는 인스톨러에서 간단하게 추가가 가능하기 때문에 설치에 문제는 없다.
- 지난 몇년 새 MFC에 속한 라이브러리 수가 굉장히 방대해져서 현재는 MS에서 MFC를 유지/개보수하는 AFX 팀에서도 포기했다고 할 정도로 여러 면에서 꼬였다고 한다. MFC 프로젝트를 만들 때 작성되는 설정들이 제대로 설정되지 않는다던지, 리소스를 수정한 후 코드창에서 저장을 하면 리소스 헤더파일의 인코딩이 문제가 된다던지... 각종 오류가 난무하는 중. 이러한 문제로 MS/AFX 팀이 신랄하게 까이지만 그들도 인간인지라 어쩔 수 없는 부분이다.[2]
- HiDPI와 같은 모던 데스크탑 환경의 지원이 없다시피하다. HiDPI 환경에서 주로 사용되는 Per-Moniter DPI Aware 는 지원하지도 않아 사실상 Native Win32를 다루듯이 직접 스케일링해서 사용해야 한다. MS의 XAML기반 UI나 wxWidgets, Qt와 같은 서드파티 UI 라이브러리들에 비하면 사실상 없다시피한 수준이다.
- MFC의 클래스/함수/변수들의 네이밍 센스, Visual Studio가 자동 생성해주는 Template들의 구조는 정말 최악이다. 그런 코드에 물들면 나중에는 스파게티 코드를 만드는 개발자가 되어버린다. 그리고 MFC는 C++ 표준에서 벗어난 MS의 비표준 함수들을 굉장히 많이 사용하기 때문에, 이런 코드가 많아지면 차후 다른 프레임워크나 컴파일러를 사용할 수 있는 여지도 없어진다.
C++ 언어와 윈도우 운영체제에 대한 이해가 있다면 못 써먹을 정도의 물건은 아니다. MFC는 C++ 라이브러리이며, 윈도우 운영체제를 다루기 위한 것이므로 이 둘에 대한 선행 학습이 이루어져야 한다.
4. MFC 대체 및 후속 GUI SDK
MFC는 2015년 기점으로 사실상 개발이 중지되었다고 할수 있으며 2000년초 개발된 MFC 유지보수 정도나 하고 있는 소프트웨어 개발사들은 앞으로 경쟁력을 갖추기가 더욱 어려워지고 있다. 신규 프로그램을 MFC로 시작하는 업체는 국내외를 찾아봐도 없다.MFC는 1990년대 시작한 1세대 GUI SDK라고 할 수 있으며 그 이후 다수의 GUI SDK가 출시 되고 있다. GUI 라이브러리 문서 참조.
[1] 비슷한 시기 대체제로는 Object Pascal 언어 기반의 델파이와 Visual Basic이 있었다.[2] AFX 팀에서 관리하는 함수가 얼마나 많냐면 윈도우가 한번 업그레이드 되었을 때, MFC는 반년 뒤에 업그레이드가 될 정도라고 하니...