기본적인 Win32API 사용법을 좀 더 쉽게 wraping 해 놓은 MFC(Microsoft Foundation Component) 라이브러리는 윈도우 어플리케이션의 개발을 편하게 해 준다는 이유로 많은 인기를 끌었었다.
하지만 이당시만 해도 MFC 의 크기는 정말 부담스럽게 큰 크기였으며 , 기본적으로 메모리를 사용하는 소모량도 적진 않았었다. 개발 된 이후 지속적으로 ServicePack 을 제공하여 새로운 플랫폼에 대한 지원이나 버그 사항 등을 고려 해 왔었지만 새로운 제품인 (MFC 보다 더 무거운) .NET framework 라는 걸 내놓게 되면서 지원은 끟긴 상태 이다.
C++ 이 추구하는 OOP (Object Oriented Programing : 객체지향프로그래밍) 과는 좀 거리가 먼 변태적인 MFC 방법이 점점 나아지는 편 이긴 하지만 여전히 비주얼스튜디오 의 변태적인 구성은 변함이 없다고 봐 진다.
그나마 비주얼스튜디오6 로 제품을 만드는 것이 가볍게 느껴지게 된 것 자체가 다 .NET 의 역활이 크지 않았을까?
개발 당시엔 혁신적인 인터페이스의 IDE 제공에 많은 찬사를 받은 바 있는 비주얼스튜디오6.
하지만 다양한 다른 컴파일러 슈트의 개발로 인해 마이크로소프트의 개발툴들도 개선되기 시작했다.
개인적인 평가로는 가장 진보적이고 개발자 중심의 개발툴은 바로 코드기어(볼랜드) 제품들이 아닌가 한다.
매번 비슷한때에 나온 IDE 만 따지고 보면 마이크로소프트사의 제품 보다는 코드기어(볼랜드) 사의 제품들 이 더 나은 개발 환경을 제공했다고 생각된다.
좀 더 직관적이고 실제 컴퍼넌트에 대한 action 접근이 용이 하며 , OOP 에 좀 더 적합한 각 컴퍼넌트 구조등은 비주얼스튜디오 씨리즈 보다 더 나은 모습이었다고 과감히 말할 수 있다.
여기서 문제는 바로 시장점위율 이라는 것이다.
대부분 쓰는 운영체제가 마이크로소프트 제품이기 때문에 개발툴 역시 마이크로소프트 의 것이 된다고 생각하게 되는 것이 일반적일 것이다 (하지만 기본적으로 윈도우 핵심 기능들은 전혀 비주얼스튜디오로 만들어 진것이 없다는 사실은 진실은 다른 것이라는 점 을 알려 준다)
대부분의 윈도우어플리케이션은 다양한 UI(Uesr Interface : 사용자 인터페이스) 제공을 위해 단독적인 라이브러리를 필요로 하게 되는 경우가 많다. 이런 경우 요즘의 .NET 에 비해서는 오히려 VisualStudio6 가 더 가벼워 진 이유가 아직도 VS6 를 많은 업체들이 새로운 제품을 만드는경우에도 택하게 되는 이유가 아닐까 한다 .
기존에 만들어진 많은 어플리케이션이 VS6 로 만들어 진 것이 있고, 이전의 소스코드를 이용해 새로운 제품을 만들기 위해서는 수정해야 하는 것이 많아지는 같은 제품군의 상이한 다른 점으로 인해 (이는 같은 제품군의 소스코드에 대한 연속 하위 호환성을 무시하게 되는 일이다) 같은 제품군 이라도 상이한 사용법등과 호환성 저하로 인한 문제로 새로운 개발툴 제품 사용을 어렵게 만드는 것이라 볼 수 있을 것이다.
이런 모습은 어느 개발툴이나 있는 부분이지만 그 변경점에 대해 얼마나더 빠르게 대처 할 수 있는 방법을 제공해 주는 것인가를 핵심적인 부분이라 하고 싶다.
윈도우는 16비트 커널에서32비트를 넘어 64비트로 넘어 가고 있다.
그럼에도 아직 32비트 초기제품을 버리지 못하는 것은 바로 마이크로소프트의 저질적인 방법에 책임이 있다고 생각한다.
그리고 그 저질적인 방법을 그대로 계승하는 각 개발사들 또한 책임이 크다고 할 수 있을 것이다.
또한 자신들이 배포한 라이브러리가 없으면 구동조차 불가능한 개발툴을 제공하는 마이크로소프트가 가장 큰 문제의 원흉이라고 정의 하고 싶다.
기본적인 윈도우만 띄어 놓은 상태로 VS6 로 만든 일반 어플리케이션을 돌려 보려 해 보면 거의 불가능 하게 된다.
바로 MFC 모델로 만들어진 어플리케이션이 그 이유가 된다.
윈도우엔 기본적으로 각 컴퍼넌트와 윈도우를 만들 수 있는 기능이 다 포함되어 있다.
그럼에도 MFC 로 만든 (심지어 Hello world 만 출력하더라도) 어플리케이션은 MFCxx.DLL 이 없으면 구동조차 안된다.
그마나 VS6 의 MFCxx.DLL 은 신사다.
.NET framework 를 사용한 어플리케이션은 그 무시무시한 덩치의 .NET framework 를 사용자 PC 에 설치 해야 한다.
버젼도 하위호환성이 없으므로 개발사가 2.0 을 썻으면 사용자도 2.0 을 설치 해야 하며 , 3.0 을 쓴 프로그램엔 3.0 을 깔아야 한다. 마이크로소프트가 기본적으로 배포판을 제공하고, 개발사가 그 배포판을 다시 배포할수 있다고 하더라도 그 무거운 framework 를 내 PC 에 설치 해야 하는 번거러움은 어떻게 보면 고통스러운 일이라 할 수 있을 것이다.
그나마 VS6 는 MFC 를 static 으로 실행파일에 포함시켜 빌드 하여 배포 할 수 있다.
그럼 사용자는 단지 엄청난 크기의 실행파일을 실행해 주면 되는 것일 것이다.
이에 반면 .NET 을 쓴 어플리케이션은 그런 선택조차 불가능 하게 된다.
심지어 개발 모델을 WinAPI 로만 만들어도 .NET 이 필요하다는 경우를 보게 되니 어떻게 보면 개발된 제품의 독립성 자체가 불가능 한 것이 아닌가 한다.
가장 큰 문제는 표준에 맞는 C++ 을 사용하지 않는 VS6 에서 발생된 수많은 것들이 상위 VS 에 맞지 않은 것이 많이 존재 한다는 것과, .NET 을 쓰는 VS 들의 모습에 거부감을 느끼는 개발자들로 인해 VS6 에서 파생된 것들이 유지될수 밖에 없는 모습을 가지게 된다는 점이 문제점이 아닐까 한다.
10년이 넘은 구형 컴파일러를 쓸 수 밖에 없는 상황.
이런 점들은 누구의 탓도 아닌 바로 마이크로소프트의 문제라 생각한다.
필자는 10년전에 만든 DELPHI 프로젝트를 컴파일러가 기본으로 채택한 컴퍼넌트를 분리하거나 수정을 하는 간단한 일만 해서 최신의 컴파일러에서 성공적으로 컴파일을 할 수 있었으며 정상적인 구동을 보장 받을 수 있었다.
게다가 static 으로 개발 라이브러리를 묶어도 1MB 를 넘는 일이 없는 어플리케이션을 만들 수 있으며, 각종 라이브러리가 없는 상태의 윈도우에서도 정상 구동 되었다.
static 으로 실행파일을 묶어서 빌드하면 기본 2MB 를 넘는 크기의 파이이 나오는 VS6 결과와 비교되는 부분이 아닌가 한다.
필자 역시 회사에서는 VS6 로 작업을 하고 있다.
회사에서 VS6 를 통해 개발을 원하기 때문이다.
과연 내가 지금 C++ 을 통해서 개발을 하고 있는 것일까? 라는 의문이 드는 부분이 너무 많이 보이더라도 그건 그저 나만의 불만인 것이다. 차라리 minGW 를 사용해서 어플리케이션을 만드는 것이 더 나은게 아닐까 하는 생각을 한두번 하는 것이 아니다.
심지어 단말기와 간단히 시리얼통신을 하도록 만든 프로그램을 비교 하더라도 크기와 성능 모두 차이가 발생한다.
오히려 CreateWindow(); 와 WinMain() 에서 메시지 처리를 해서 만든 어플리케이션이 VS6 로 만든 어플리케이션 보다 빠르고 작은크기, 적은메모리 사용량을 보여 준다는 것이다.
다만 디버깅의 이점및 검증받은 라이브러리 들로 인해 VS6 를 쓰는 것 보다는 어려운 작업이라 회사에서 여러사람이 같은 소스로 작업을 하는 일에는 적합하지 않은 비교대상이긴 하지만 같은 제품군인 VS 간의 호환성저조 등의 문제는 모두 마이크로소프트가 스스로 벌인 문제점이라 생각 된다.
GCC 를이용한 개발이 Visual Studio 의 장점들을 가지게 된다면 큰 혁신을 이룰 수 있을 것이라 생각된다.
사실 Visual Studio 와 같은 편리한 디버깅 환경이 없더라도 Linux의 한 종류인 Ubuntu 에서는 수많은 어플리케이션이 존재한다. 그저 VS 에 길들어진 개발자의 핑계가 VS를 못 벋어나게 하는 문제점중 하나는 아닐까 한다.
이런 저런 이유로 인해 앞으로 몇년간 VS6 로 만들어진 것들이 돌수가 없는 상황이 오기 전 까진 VS6 로 만들어지는 많은 것들은 여전히 존재할 수 밖에 없을 것이다.
모든 것이 마이크로소프트의 친절한 독점에 따른 폐단일 것이다.
스스로 마이크로소프트를 거부하면서 벗어나지 못하는 개발자들 역시 마찬가지일 것이고.
