(주의: 너무 긴 글!)

MFC를 쓴지도 10년 정도가 흘렀다. MFC 자체에 대해 호감을 많이 가지고 있는 것이 아니었다. 특히 Doc/View는 여전히 거추장스러운 구조이고, 예전 쓴 글에서도 말 했지만 MFC는 객체 지향적인 설계에서는 낮은 점수를 받을 수 밖에 없다. 태생적으로 전혀 객체 지향적이지 않은 Win32 API를 가볍게 감싼 형태가 MFC여서 Win32 API의 부족한 객체 지향적 인터페이스를 고스란히 포함하고 있다. 그래서 Windows Forms의 그것과 비교하면 한참이나 불편한 클래스 라이브러리이다. 메세지 처리 부분을 제외하고는 거의 Win32의 모습을 그대로 담고 있다고 볼 수 있다. 물론, 다시 MFC 코드를 제대로 들여다보니 욕만 했던 어린 시절의 내 모습이 부끄러워질 정도로 잘 만들어져있었다.

그러나 10년이 지난 지금도 많은 윈도우 프로그램들은 C#이나 Java가 아닌 Win32 Native 코드로 작성되고 있다. 또한 많은 프로그램이 여전히 MFC로 만들어지고 있다. Visual Studio .NET (7.0)이 등장하면서부터 MFC는 거의 버린 자식 취급을 받았고, 조금씩 업데이트가 되었지만 큰 변화는 없었다.

때마침 ActiveX 사건이 터지면서 ActiveX를 만드는데 자주 쓰였던 MFC도 먼지가 한참이나 쌓인 기술로 취급받게 되었다. ActiveX 만드는 개발자는 모두 자폭해야할 정도로 뭐도 모르는 사람들이 욕을 해데니 MFC를 쓰면 "내가 뒤떨어진 놈인가" 라는 자괴감이 들기 일쑤였다. 그냥 컴퓨터 사용하는 사람들이야 새로운 기술을 당장에 써야 그게 좋은 것으로 생각하지만 실상은 전혀 그러지 않다는 것을 몰라서 나온 망언들이다.

그런데, 내년에 나오는 Visual Studio 2008에는 Visual C++ 및 MFC에 대한 기능이 대폭 강화된다는 이야기를 여러 채널을 통해 들을 수 있었다. (참고 글) 이미 VC++ 개발자들이 한국에 다녀가서 많은 정보들이 나왔다. 일단 가장 눈에 띄는 것이 MFC 새로운 버전에 Office 2007의 리본 인터페이스 혹은 사용자 설정이 가능한 툴바와 같은 고급 인터페이스 요소들이 추가된다는 사실이었다. 정말 놀라운 일이 아닐 수가 없었다!

그러나 기대가 크면 실망도 큰 법:

• Quick Tour Of New MFC Functionality
• Pat Brenner: New Updates to MFC in Visual Studio 2008

Visual C++ Team Blog를 통해, 그리고 Channel 9 비디오를 통해 새로운 MFC에 대한 모습을 볼 수 있었다. 그러나... 이 새로운 UI 라이브러리가 Office 2007 그리고 Visual Studio의 소스를 리팩토링해서 만든 것이 아니라 BCGSoft에서 이미 판매 중인 BCG Library를 가져다 쓰는 것이었다. ㅠㅠ

일단, 비판은 뒤에서 하고 관련된 이야기부터 해보자.

윈도우 운영체제 자체의 인터페이스는 맥 같은 것에 비해 부족한 점이 있을 수 있다. 그러나 어플리케이션만 놓고 보면 마이크로소프트에서 나온 제품들의 인터페이스는 상당히 훌륭하다. 과거 Visual Studio 최신 버전이 나오면 사람들이 제일 관심있게 보는 것은 일단 인터페이스가 어떻게 바뀌었나를 보는 것이었다. 오피스 역시 그랬다 (그러다가 오피스 2003 정도에 와서 이 약발이 떨어지자 리본 인터페이스를 만들었다).

윈도우 기본 밋밋한 툴바 외에 사용자가 마음대로 버튼을 조절할 수 있는 툴바, 창들을 떼었다가 붙일 수 있는 docking container가 대표적이다. CodeGuru, Code Project와 같은 많은 윈도우 프로그래머 인터넷 싸이트에서는 이들 인터페이스 요소들을 모방한 클래스들로 넘쳐났다. 이런 고급 인터페이스 요소들을 모아 판매하는 곳까지 생겨났다. Codejock이 대표적이며 실제로 나도 회사에서 개발할 때 이 라이브러리를 구입해서 사용하였다. 그 만큼 Visual Studio 및 Office에서 보여준 인터페이스들은 훌륭한 것들이 많았다.

그런데 MFC가 기본으로 제공해주는 인터페이스는 윈도우 98 혹은 윈도우 2000의 그것과 다름이 없다. 아무리 자기네들 프로그램에 고급 인터페이스 요소들이 넘쳐나도 MFC와는 거리가 먼 녀석들이었다. 아래 그림은 MFC Wizard에서 SDI (Single Document Interface)로 만들었을 때 만들어지는 프로그램의 전형적인 모습이다.

툴바의 아이콘은 16색이며(!), 하단의 Status bar (상태줄)은 정말 Win32 API가 제공해주는 기능 그대로만 있다. 보통 최근 프로그램들의 status bar에는 예쁜 아이콘들도 올라가고 progress bar 및 버튼 컨트롤도 올라간다. 물론 MFC로 그렇게 만들 수 있지만 MFC가 기본으로 지원해주는 CStatusBar에는 그런 기능이 없다. (물론 Win32가 제공해주는 Status Bar 관련 API도 그러한 기능이 없다. 그래서 MFC도 없는 것이다.)

사실 MFC에 리본 및 customizable 툴바가 포함되리라고는 생각하지 않았다. 왜냐면 그러한 요소들이 MS 제품들의 강점 중 하나인데 그것을 공개하는 것이 쉽지 않으리라 생각했기 때문이다. 그래서 이번 MFC 업데이트가 상당히 기다려졌던 것이다. 일종의 MS 내부 소스를 공개하는 일이기 때문이다. 물론 리본이나 customizable toolbar의 소스가 MFC로 짜여있지는 않을 것이다. 그래도 C/C++로 만들어져있을 것이고 그렇다면 크게 어렵지 않게 MFC에도 적용시킬 수 있으리라 생각했다. (그런데 만약 이들이 다 C#이나 managed 환경에서 만들어졌다면... 좀 어려울 수도 있겠으나) 그러나 무엇보다:

튜닝의 끝은 순정이다!

라는 말이 있듯이 이제 짝퉁 인터페이스 말고 정말 진짜 똑같은 인터페이스를 사용할 수 있겠구나라는 기대감이 부풀어있었다.

그러나... 내가 너무 순진한 것 같았다. 아쉽게도 *진짜* 리본은 사용할 수 없다. 여전히 짝퉁 리본을 사용하는데 다만 마이크로소프트가 그것을 보증하는 것과 공짜로 쓸 수 있다는 점이 차이일 뿐이다. 물론, 이 정도만 하더라도 매우 훌륭한 진척일 수 있다. 무엇보다 MS가 더 이상 native C/C++ 쪽을 홀대하지 않고 열심히 지원해주겠다는 의지의 반영으로 볼 수 있기 떄문이다.

그렇다면 내가 왜 이렇게 BCGSoft의 라이브러리가 MFC로 들어오는 것에 실망을 하는지 좀 욕을 해보자.

2002년부터 주로 했던 일이 Visual Studio와 같은 에디터 툴을 만드는 것이어서 고급 툴바 및 docking windows는 필수였다. 그래서 그 때 부터 여러 상용 라이브러리를 써왔다. 대표적으로 이번에 MFC로 통합된 BCGLibrary가 있고 또 하나는 Codejock의 Xtreme Toolkit이 있다. (Prof-UI라는 툴도 있는데 너무 허접해서 생략) 그런데 나는 항상 Codejock의 제품을 써왔다. 왜냐면 이 제품이 BCG보다는 *훨씬* 우수하기 때문이다. Xtreme 툴킷은 실제로 소스를 오랫동안 봐왔고 내부적으로 고쳐서 사용한 적도 있기 때문에 꽤 잘 안다고 할 수 있다.

인터페이스는 정말 미묘해서 1픽셀의 차이 조금의 딜레이도 사용자에게 바로 인지되어 프로그램의 완성도를 떨어뜨린다. 특히 이런 모방한 클래스 라이브러리들은 조그마한 상이함도 바로 *짝퉁*임을 강하게 느끼게 하여 이질감을 자아내게 만든다.

솔직히 BCGLibrary 내부를 많이 보지는 않았다. 그러나 XTreme과 큰 차이가 없으리라 생각한다. 그러나 무엇보다 문제는 BCG 제품은 그렇게 성능이 뛰어나지 못하고 완벽히 모방을 하지도 못하고 있다.

일단 두 회사 홈페이지에 가서 데모 exe들을 받아서 실행시켜보자:

• Codejock: http://www.codejock.com/downloads/samples/
• BCGSoft: http://www.bcgsoft.com/download.htm

리본은 아직까지 많이 써보지를 않아서 잘 모르겠고, 일단 Visual Studio 인터페이스를 모방한 데모 프로그램들을 각각 진품과 비교해보자.

맨 위가 BCG, 그 다음이 Codejock, 마지막으로 진짜 VS 2005가 있다. 일단, 한 눈에 BCG 제품의 메뉴 폰트가 한 픽셀 작음을 알 수 있다. 메뉴 뿐만 아니라 툴바 아이콘도 가로 폭이 1픽셀 작은 것 같고, "Solution Explorer"의 글씨도 작다. 그리고 XP부터 디폴트로 File, Edit와 같은 메뉴 항목에 밑줄이 그여지지 않는다. Alt 키를 눌러야만 밑줄이 보인다. 그러나 BCG는 디폴트로 밑줄을 보여주고 있다! 물론 이걸 수정할 수는 있을 것이다. 그런데 이런 매우 기초적인 폰트 크기부터 틀리다는 것은 다른 곳에도 이런 허점이 많다는 것을 뜻한다.

딱 하나만 더 살펴보자. Property Grid는 매우 유용한 인터페이스 요소로 모두 필수적으로 구현하고 있다.

빨간 줄을 친 두 버튼은 정렬 방식을 나타내는데, 하나는 category로 보여주는 것이고 옆에 것은 category 무시하고 ABC 순으로 보여주는 것이다. 만약 위 그림과 같이 File Type을 선택하고 있는 상태에서 정렬 방식을 바꾸더라도 File Type이 그대로 선택되어있어야 하는 것이 상식적이다. 그러나 아쉽게도 BCG의 컨트롤은 그냥 선택된 것이 사라진다. 알고 있다. 이거 솔직히 소스 고치는 것이 어렵지 않다는 것을. 그러나 데모 프로그램 다운 받고 단 3분 동안 들여다 봤는데도 벌써 이상한 점 서너개가 나왔다. 그러니 BCG 제품을 믿지 못하겠고 사용하기가 꺼려지는 것이다.

또 하나 성능에 대해 이야기 해보자. Alt를 누르고 아랫쪽 방향키를 누르면 풀다운 메뉴가 뜨는데, 여기서 오른쪽 혹은 왼쪽 방향키를 계속 눌러보자. 메뉴가 빠르게 움직이게 된다. 이러한 행동을 시켜보면 BCG 제품이 가장 느린 것이 한 눈에 바로 알 수 있다.

차라리 MFC가 XTreme 툴킷을 채용했으면 조금 덜 화가 났을 수도 있다. 그래도 가장 근접하게 구현하였고 코드도 꽤나 깔끔한편이다. 그러나 얘들도 완벽하지 않다. 특히 MFC의 복잡한 command message routing과 맛물려 좀 짜증나는 행동을 보일 때가 있다.

예를 들어, VS 인터페이스에서 Solution Explorer와 같은 docking window가 비활성화 되어있는 가운데에서, 마우스 *우클릭*으로 바로 Solution Explorer의 항목을 선택하는 경우: 이 아이템을 RButton Down에서 선택을 하면서 Solution Explorer 창을 활성화 시키고, RButton up이 될 때, 이 아이템에 해당하는 context menu를 띄어주는 것이 합리적인 행동이다. 그런데, XTreme 툴킷으로 짜보면 이러한 부분이 잘 안된다. 그래서 처리하기 상당히 힘들었다. 꼼수를 부려야만 했다.

어떻게 보면 내가 트집잡는 것이 굉장히 사소하고 진짜 이런 것까지 트집잡으니 넌 미친놈이야~ 라고 욕할 수도 있겠다. 그러나 UI 구현은 정말로 엄밀해야 한다. 대충 짜다보면 그야말로 거지 프로그램 된다. 그래서 정말 한치의 타협도 없이 만들어야하는 것이 UI인데, MFC가 공식적으로 그렇지 못한 라이브러리들을 자기네 영역으로 가지고 왔다는 것이 너무 아쉽다.

비록 MFC가 공식적으로 지원하기 위해 내부적으로 소스 튜닝도 하고 많은 보완이 있으리라 믿는다. 그러나 여전히 2%는 부족할 것이다.

아, 쓰고 보니 진짜 무진장 길다. 그냥 아쉬움이 너무 커서 주절거리다 보니 너무 길어졌다는.. 죄송합니다.

* 긴 글에 이은 업데이트 *

왜 MS가 직접 구현하거나 오피스 소스를 가져다 쓰지 않고 다른 곳에서 사왔는지에 대한 설명을 Herb Sutter의 블로그에서 볼 수 있었다. 두 가지 질문에 대한 답변을 해주고 있다. Herb는 현재 MS 소프트웨어 아키텍트로 일하고 있으니 그의 답변은 꽤 정확하다고 볼 수 있겠다.

1. 다른 회사에서 사온 코드가 문제가 되지 않는가?

- 그렇지 않다. 그전에도 이미 C++ STL 같은 경우 Dinkunware에서 사온 것과 같이 종종 라이센스를 받아 타 회사의 코드를 사용한 적이 있다.

2. 오피스팀에서 사용하는 코드를 쓰지 않는 것이 문제가 되지 않는가? 왜 마이크로소프트는 자신들의 코드를 쓰지 않았는가?

- 오피스팀에서 사용하는 내부 코드가 일반적인 프로그램에 사용하기에 적합한 수준이 아니기 때문이다. (일반화되어있지 않고 오피스에 맞춘 특수한 코드가 많다는 뜻으로 해석할 수 있음).

오피스 팀을 독립적인 윈도우 응용 프로그램을 만드는 회사로 생각하면 된다. 오피스 팀은 그들만의 새롭고 진보된 UI를 윈도우, Visual Studio와 별개로 개발해왔다. 그리고 윈도우와 Visual Studio도 차례로 오피스에서 선 보인 고급 기술들을 따라하여, 윈도우 쉘이나 기타 프로그램에서도 오피스와 비슷한 느낌의 인터페이스를 구현해왔다. 그리고 이런 구현들은 대게:

1) 오피스 팀의 개발보다 늦다. 그들이 보통 앞서고 플랫폼과 기타 툴들은 그것을 뒤 따른다.

2) 그리고 오피스 자체 버전과 다르다. 왜냐면 "오직 내부 사용"으로 만들어진 코드와 별도의 문서와 테스팅 등이 요구되는 "제품화된" 코드들 사이에는 상당히 큰 차이가 있기 때문이다.

에.. 그 뒷 부분은 번역하려고 하니 뉘앙스를 제대로 못 옮기겠음 (원문발췌):

The fact that we have an internal and an external "real" implementation for the same thing doesn't matter. We've always done it that way, and the"real" implementation is equal and fully supported. (I think it's funny that some worry that they're not getting Office's original internal 'real' implementation; the real "real" implementation is the one that's not just for internal use, almost by definition!) Once a UI innovation gets into the Windows UI and/or especially the Visual Studio tool set, it's first-class and here to stay.

이어지는 의역: 같은 기능을 위해 internal (즉, 오피스 팀이 쓰는 것)과 external "real" implementation (다른 윈도우나 VS팀이 만든 것)이 같이 존재하는 것은 큰 문제가 되지 않는다. 왜냐면 지금까지 그래왔기 때문이다. 그리고 external "real" implementation도 동일하고 완전히 지원이 된다. 어떤 이들이 오피스의 진짜 internal 'real' 구현을 사용하지 않는 것에 대해 걱정하는 것은 다소 웃기다고 생각한다 (ㅎㅎ); 진짜 'real' 구현은 그저 내부에서 사용되는 것만을 가리키지 않는다.

그러고보니 예전 면접볼 때 만났던 친구가 오피스팀에서 7~8년 동안 일했다고 했었는데, 내가 그 때 이런 비슷한 질문을 했었다. Customizable toolbar와 같은 것을 너희가 만들었는데, 그런 코드를 다른 팀에도 배포를 하는지라고. 그랬더니 그의 답변은 그런 것은 아니다라고 답변해서 의외네.. 라고 생각했던 기억이 나는구나 -_-;