MFC

 



'''M'''icrosoft '''F'''oundation '''C'''lasses
MSDN의 MFC 페이지
1. 개요
2. 사용 목적
3. 단점
4. 대안


1. 개요

Microsoft Windows 운영체제 환경에서 작동하는 GUI 응용프로그램을 개발하기 위한 C++ 언어 기반의 라이브러리로, 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이 포함되지 않는다.

2. 사용 목적

Microsoft Windows용 GUI 응용프로그램을 개발하기 위해 사용된다. C언어기반의 Windows API를 직접 사용할 수도 있으나, C++언어 기반의 MFC를 사용할 경우 보다 구조적이고 간편하며 대규모의 어플리케이션 개발이 용이하다.
90년 초반부터 2000년 중반 사이의 윈도우즈용 GUI 응용프로그램 개발을 위한 라이브러리로 널리 사용되었다[1]. 현재는 과거 개발된 어플리케이션의 유지보수가 주된 용도이다. 웹과 모바일환경이 대두되었을 뿐만아니라, 데스크톱 응용프로그램의 개발 환경도 .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로 개발되고 있다.
사실 MFC를 사용하는 가장 큰 이유는 줄곧 Visual Studio에 포함되어 있었기 때문이라는 말이 있다. 더 좋은 라이브러리들이 존재하지만(혹은 존재를 잘 몰라서) 굳이 찾지 않고 포함되어 있는 것을 사용한다는 것. 근거 없는 말이 아닌 것이, 타인에게 작업물을 전달한다거나, 라이브러리를 GUI 예제 프로그램과 함께 외부 공개한다거나 할 때에는 MFC의 경우 비주얼 스튜디오 버전만 맞춰주면 보통 별 문제가 없지만, 비주얼 스튜디오에서 기본지원하지 않는 외부 기술을 사용했을 경우에는 그것에 대한 설치와 설정방법도 함께 제공해야 하는데 이것이 귀찮기 때문이다.

3. 단점

  • 비주얼 스튜디오 2019 버전에서도 여전히 사용 가능하나, 메이저 버전은 비주얼 스튜디오 2015 시절의 MFC 14에서 멈춰있고 마이너 업데이트만 제공되는 상황이다. 2015년 이후 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 등과 비교하면 이뭐병 소리가 절로 나온다.
  • 닷넷 출시 이후로 MS로부터 버려졌다는 소문이 있다. 실제로 VS2008 이후부터 MFC에 큰 변화가 없어졌고, VS2012까지는 MFC가 탑재되어 릴리스 되었지만 VS2015부터는 따로 패키지를 설치해서 사용해야 한다.
  • 지난 몇년 새 MFC에 속한 라이브러리 수가 굉장히 방대해져서 현재는 MS에서 MFC를 유지/개보수하는 AFX 팀에서도 포기했다고 할 정도로 여러 면에서 꼬였다고 한다. MFC 프로젝트를 만들 때 작성되는 설정들이 제대로 설정되지 않는다던지, 리소스를 수정한 후 코드창에서 저장을 하면 리소스 헤더파일의 인코딩이 문제가 된다던지... 각종 오류가 난무하는 중. 이러한 문제로 MS/AFX 팀이 신랄하게 까이지만 그들도 인간인지라 어쩔 수 없는 부분[2]이다.
C++ 언어와 윈도우 운영체제에 대한 이해가 있다면 못 써먹을 정도의 물건은 아니다. MFC는 C++ 라이브러리이며, 윈도우 운영체제를 다루기 위한 것이므로 이 둘에 대한 선행 학습이 이루어져야 한다.
하지만 MFC의 클래스/함수/변수들의 네이밍 센스, Visual Studio가 자동 생성해주는 Template들의 구조는 정말 최악이다. 그런 코드들에 물들면 스파게티 코드가 탄생한다. 그리고 MFC는 C++ 표준에서 벗어난 MS의 비표준 함수들을 굉장히 많이 사용하기 때문에, 이런 코드가 많아지면 차후 다른 프레임워크나 컴파일러를 사용할 수 있는 여지도 없어진다.

4. 대안

윈도우 응용프로그램을 만들기 위해 반드시 Win32 API 또는 MFC를 사용해야 하는 것은 아니다.
  • C++를 사용해 강력하고 다양한 기능을 가진 UI를 개발하고 싶은가?
    • 그렇다면 Qt 라이브러리를 사용해 보자.
      • Qt는 Windows, macOS, Linux를 모두 지원하는 C++ 프레임워크로, 단순한 GUI 라이브러리가 아니라 자체적으로 네트워크, 파일 및 DB 처리, XML 지원, 강력한 String 클래스 등 방대한 기능들을 가지고 있다.
      • 윈도우 시스템 함수를 호출하는 것도 가능하다.[3]
      • 한번만 써 보면 MFC의 다이얼로그 편집기는 쓰레기로 보이게 될 GUI Designer를 제공하며, 비주얼 스튜디오와 훌륭히 연동된다. 홈페이지
      • 닷넷의 WPF와 비슷한 QtQuick을 제공한다. QML을 시작합니다.
    • C++ Builder는 훌륭한 GUI 개발 환경을 가진 IDE이며, C++를 이용하여 동일한 편의성을 누릴 수 있다. 다만 사용률이 적어 자료를 찾기가 힘들다. 또한, IDE가 한국어팩을 지원하지 않으므로 영어에 익숙하지 않으면 개발하는데 시간이 걸릴 수 있다.
    • 리눅스에서 빛나는 크로스폴랫폼을 지원하는 GTK가있다. C,C++,Python,C#과유사한Vala등을 모두지원한다. wxWidgets도 있다.
  • 다른 언어는 어떤가? 반드시 C++를 사용할 필요가 없다면?
    • .NET Framework 플랫폼에는 Windows Forms와 WPF의 두 가지 GUI 라이브러리가 포함되어 있다. Windows Forms는 쉬운 난이도 덕분에 초보자가 접하기에도 용이하다. 또한 C\#은 C++과는 비교도 되지 않는 높은 생산성을 자랑하는 언어이다. 기존 윈도용 C/C++ 프로젝트나 라이브러리와의 연동도 수월하므로 일단 핵심 코드는 그대로 둔 채 껍데기부터 차차 교체할 수도 있다. 닷넷 프레임워크로 개발된 프로그램의 대표작이라면 비주얼 스튜디오 중 2008 이후의 버전들(WPF로 개발되었다)을 들 수 있을 것이다. 커다란 용량의 닷넷 런타임 배포가 부담스럽다면, 개인적으로 사용하는 프로그램의 개발에서부터 활용해 보자. 또한 웹 인스톨러 등을 이용하거나 인스톨러가 닷넷 설치 웹사이트를 띄워주는 등의 방법으로 배포에 대한 부담을 줄일 수도 있다. 어차피 윈도우 7부터는 닷넷 프레임워크 3.5가, 윈도우 8부터는 4.5가 기본적으로 포함돼 있기도 하고, ATI 카탈리스트 컨트롤 센터처럼 장치 드라이버 관련 유틸리티가 닷넷 기반으로 개발되기도 하는 등, 완전히 닷넷이란 것과 담을 쌓다가 갑자기 설치해야 되는 일은 많이 줄어들었다.
    • Python은 Tcl/Tk, PyQt, PyGTK 등 다양한 GUI 라이브러리와의 연결 기능을 제공한다.
    • Java에는 JavaFX와 SWT[4], SwingX 등의 GUI 라이브러리가 존재한다. AWT나 Swing은 MFC와 비슷한 개발 난이도를 자랑하기에 별로 추천하지는 않는다.
    • 파스칼 언어를 사용하는 델파이 환경은 MFC와 얼마 차이나지 않는[5] 역사를 자랑하지만, macOS와 Linux 뿐만 아니라 안드로이드, iOS 환경도 지원하며 RAD 툴로서 빠르게 강력한 GUI 개발이 가능하다.
    • Electron을 사용하면 HTML + CSS + JavaScript(Node.js)로 데스크톱 환경을 만들 수 있다! 당장 Atom과 비주얼 스튜디오 코드가 실기로 나와 있다. 단점은 구현 방식이 일단 브라우저 하나를 띄워놓고 시작하는 것이기 때문에 기본 용량이 크고 퍼포먼스가 떨어진다는 점. 이 부분은 PC의 평균 스펙이 올라가면 차차 해결될 듯하다. 위에서 예로 든 닷넷 플랫폼과 비교했을 때, 다양한 운영체제를 지원하는 크로스플랫폼 프레임워크라는 것이 상당한 장점이다. 필요하다면 프론트엔드에만 Electron을 쓰고, IPC와 FFI 혹은 wasm을 이용해 백엔드는 C/C++ 등으로 대체하는 것도 가능하다. MS가 GitHub를 인수한 이후부터는 이 Electron을 밀어주고 있다.
    • 2010년대의 대세인 웹을 통해 UI를 구현할 수도 있다. 서버 통신이 필요없는 로컬 프로그램인데도 웹으로 구현된 애플리케이션이 점점 늘어나고 있으며, 시스템을 만져야 하거나 퍼포먼스가 필요한 부분은 따로 웹 API 서버 노릇을 하는 서비스 프로세스로 분리시킨 뒤 UI와 통신하는 식으로 해결한다.[6] 일례로 크루셜의 SSD 관리 프로그램(Crucial Storage Executive)이 이런 식. 기존 프로그램의 UI와 코어부가 잘 분리돼 있다면 생각해볼만 하다.

[1] 비슷한 시기 대체제로는 Object Pascal 언어 기반의 델파이와 Visual Basic이 있었다.[2] AFX 팀에서 관리하는 함수가 얼마나 많냐면 윈도우가 한번 업그레이드 되었을 때, MFC는 반년 뒤에 업그레이드가 될 정도라고 하니...[3] 당연하겠지만 윈도우 외 운영체제에서는 사용 불가능하다.[4] 이클립스에서 사용된다. 홈페이지[5] 1995년 최초 공개되었다[6] 위에 서술된 일렉트론도 내부적으로는 이런 구조이다.

분류