VC++ 6.0을 쓰지 말아야하는 이유

출처 : http://minjang.egloos.com/1783328

2008년 3월인 지금까지도 여전히 많은 프로젝트들이 10년 전에 출시된 VC++ 6.0으로 개발하고 있다는 사실이 다소 놀랍고 충격적이기까지 하다. 많은 분들이 토를 단다. 그런데 직접 십만 라인의 VC6 프로젝트를 2003년,VS 2003으로 이전한 경험이 있는 나로서는 그저 게을러서, 귀찮아서 라는 변명으로 밖에 들리지 않는다. 정말로 VC++ 6.0을 써야만 하는 절대절명의 이유가 있는지 정말 궁금하다. 왜 VC++ 6.0을 쓰지 말고 최소 VS 2005을 써야하는지 몇 가지만 써보자. (단, 이 이야기는 .NET을 사용하지 않는 Win32 기반의 C/C++ 프로젝트에만 적용된다.)

1. 보다 안전한 프로그래밍

2001년 온 세상을 골치아프게 했던 Code Red Worm을 기억할 것이다. 이건 대표적으로 heap buffer overflow의 결과인데, 이건 사소한 프로그래밍 실수 혹은 미비한 체크로 발생한다. 예를 들어, strcpy 같은 함수가 대표적이다. strcpy는 아시다시피 달랑 두 개의 스트링 인자만 받고 길이를 입력 받지 않는다. 그건 두 인자 모두 NULL로 안전하게 끝나는 것을 가정하기 때문이다. 그런데 의도적으로 할당된 버퍼보다 더 많은 문자열을 입력할 경우? 최악의 경우 재앙이 벌어질 수 있다. 실제 대부분의 버퍼 오버플로우는 이렇게 발생한다. VC++ 6.0에서는  strcpy를 써도 아무런 경고 따위 없다. 그러나 VS 2005 이상에서는 이런 함수는 쓰면 위험하다고 경고를 띄운다.

xxx.cpp(66) : warning C4996: ‘strcpy’: This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.

2. 유니코드 프로그래밍

아직까지도 유니코드가 아닌 MBCS로 시작하는 (윈도우) 프로그래머가 있으면 이건 기본도 모르는 사람이다. “아직 저희 제품이 윈도우 98을 지원 해야해서…” 라는 변명도 통하지 않는다. 그럴 경우에는 윈도우 95/98을 위한 Unicode Layer를 쓰면 된다. VS 2005에서 프로젝트를 하나 생성하면 디폴트가 유니코드이다. 이제 구닥다리 아스키 MBCS 기반의 프로그램을 짜야할 이유가 전혀 없다. 윈도우 NT 커널은 모두 유니코드로 짜여있어서 유니코드를 바로 쓰는 것이 성능에도 좋다. 예를 들어, CreateWindow라는 함수는 실제로 CreateWindowA라는 아스키 버전과 CreateWindowW라는 유니코드 버전이 있는데, 윈도우 NT 커널에서는 W 버전만 구현이 되어있다. 그리고 A 버전 함수가 불리면 입력 받은 스트링을 모두 유니코드로 바꾸는 과정을 거친 뒤, W를 실행시킨다. 참고로 윈도우 CE는 오직 유니코드만 지원한다. 따라서 아스키, MBCS를 써야할 이유가 이제는 없다. “윈도우 98 사용자들을 그래도…” 닥쳐라. 그냥 무시해라. 내 블로그 통계에 아예 Windows 98은 잡히지도 않는다.

영문 윈도우에서 non-Unicode 세팅을 영어로 했을 때, 여전히 ???와 같은 글씨가 보이는 프로그램들을 보면 한숨만 팍팍 나온다. 유니코드로 전환하는 것이 그렇게 어려운 것도 아니다. 사실, 제대로 공부 좀 했는 윈도우 프로그래머라면 10년 전 부터 이미 TCHAR, _T(x)와 같이 Unicode prepared된 코드를 만들었어야만 했다. 그러나 위에서도 말했듯이 이제는 모두 NT 기반 커널을 사용하기 때문에 TCHAR을 사용할 필요도 없다. 그냥 바로 wchar_t, L”Hello, World!”로 하면 된다.

반드시 알아야할 내용: http://eslife.tistory.com/entry/유니코드로-개발하기

3. 보다 뛰어난 인텔리센스

VC++ 2008은 아직도 안 써봐서 잘 모르겠지만, VC++ 2005의 인텔리센스만 해도 상당히 우수한 편이다. 물론 C#에서 지원되는 인텔리센스에 비하면 한참이나 모자라지만 기타 다른 모든 C/C++ 인텔리센스 중에서는 최고의 성능을 자랑한다고 확신한다 (이클립스, 소스인사이트 등등 모두 능가함). VC6 에서는 인텔리센스 기능이 초창기 버전이라 부족한 점이 매우 많았다. 대표적으로 #define으로 정의된 것들은 목록에 뜨지 않는다. 그리고 2003에 비해서도 성능이 많이 개선이 되었다. 여기에 적기에는 너무 장황해질 것 같아 생략하겠지만 2003에서는 처리가 안되어서 아쉬웠던 것이 2005에서 지원이 된 케이스가 있다. (이거 확인하고 바로 VS 2003 언인스톨)

VC++ 6.0 (사실 난 2002년부터 쓰지 않았다)을 쓸 때는 Visual Assist가 필수품이었는데 이제는 이걸 쓸 이유가 없다. Visual Studio가 지원하는 인텔리 센스만 해도 충분하기 때문이다.

4. STL의 (거의) 완벽한 지원

STL을 사용한다면 당장에 VC++ 6.0은 언인스톨 해야한다. 역시 eslife님이 아주 잘 정리를 해주셨기에 링크로 대체: http://eslife.tistory.com/entry/Visual-Studio-버전-별-STL-지원. 링크 글에도 나오지만 VS 2005의 STL 디버깅은 환상적이다. 예전에 STL 내용물 보기 위해 계속 노가다 뛰었던 걸 기억하면 눈물 날 정도다 (gdb에서는 dump 함수를 짜서 실행시키면 되긴 하지만 여전히 불편했다).

5. 뛰어난 IDE 매크로 사용

VC++ 6.0에서도 매크로가 되긴 된다. 그러나 Visual Studio .NET (7.0 버전)에서 부터 매크로가 매우 강력해졌다. IDE 하나가 DTE라는 객체로 접근이 되고 모든 IDE 객체 및 요소가 접근이 되고 매크로화 할 수 있다. 대표적으로 예를 하나 적어보면 .cpp와 .h를 연결해주는 매크로도 쉽게 만들 수 있다.

6. 더 훌륭해진 컴파일러

컴파일러만 놓고봐도 VS 2005 이상을 써야할 이유가 충분하다. MS compiler extension이긴 하지만 편리한 키워드도 추가가 되었으며, profile-guided 최적화도 가능하고, 컴파일러 메세지도 보다 친절해졌으며, OpenMP도 그냥 지원이 된다. C99 기능들은 지원하지는 않지만 훨씬 C++ 표준에 부합된 프론트엔드를 가지고 있다.

7. 더 괜찮아진 IDE

IDE만 놓고 보면 VC++ 6.0보다 많이 무겁다. 그러나 메모리 요즘 엄청나게 저렴하고 듀얼 코어 CPU도 저렴하니 그거 달면 가볍다. 회사에서 좋은 컴퓨터 안 사주면 회사 때려치던가 아니면 자기돈 들여서라도 좋은 컴퓨터로 바꿔야 한다. 남들 3분만에 컴파일할 것, 5분 동안 컴파일하면 그건 시간 낭비. 남은 2분 동안 최소 잠자거나 인터넷 서핑해도 남는 장사다. 그러니 최신 Visual Studio가 메모리 많이 먹는다는 것은 그다지 핑게거리가 되지 않는다.

VC++ 6.0의 IDE는 뭐랄까 애증이 교차한다. 희한하게도 이 IDE는 MFC로 만들어져 있어서 많은 호기심을 자아냈다. (단순하게 Spy++로 확인해보면 Afx:… 로 시작하는 Window Class Name이 확인 가능하다) 아마 마이크로소프트 내부에서 만든 프로그램 중 MFC를 쓴 것은 VC6과 Wordpad 정도가 아닐까? 그러나 VC++ 6.0의 IDE는 그다지 우수하지 않다. 일관성이 없다고 할 수 있다. 반면, Visual Studio .NET 부터는 모든 언어들이 공통적인 IDE로 통합이 되어 훨씬 일관성이 있는 UI로 바뀌었다. 물론 “ClassWizard가 사라졌어요!” 라는 비명이 잠시 들리지만 걱정 마시라, 다 있다. (물론 요즘 컴퓨터에서는 매우 가벼워진 VC6 덕택에 이 녀석을 에디터로 쓰시는 분들도 봤다)

VS 2003 시절까지만 해도 디버깅 심볼 서버 쓰기 위해서 삽질 좀 해야했던 것도 VS 2005에서는 그냥 된다. 또, VS 2003 까지만 해도 툴바 설정, 폰트 색깔 설정을 새 컴퓨터로 이동하기 위해 레지스트리도 백업해야하고 파일들도 카피해야했던 것에 비해, 세팅을 이전할 수 있는 기능을 built-in으로 지원한다. Team 버전은 사용하지 않았지만 거기에는 프로파일링, 유닛 테스트 등이 모두 포함되어있다고 한다. 마지막으로 VC6의 16색 썰렁한 아이콘에 비해 2005의 256색 아이콘은 더 이쁘다…

8. 멀티 코어의 사용

좀 와전된 내용이 있는 것 같은데, 최신 VC++ 컴파일러가 멀티 코어를 인식해서 뭔가 새로운 수준의 최적화나 컴파일을 하는 것은 아니다. 단순히 컴파일을 할 때, 멀티 코어를 다 활용하여 컴파일 시간을 단축시키는 것에 불과하다. 그래도 어쨌든 요즘 거의 기본인 듀얼 코어 환경에서 보다 빠르게 컴파일을 할 수 있다. VS 2005는 이 기능이 사실 미약해서 단순히 독립적인 두 프로젝트를 동시에 컴파일하는 수준이었는데, VS 2008은 모르겠다. 사실 컴파일은 그 자체가 embarrassingly parallel한 작업이라서 파일 수준으로 동시에 병렬적으로 컴파일을 할 수 있다.

9. MFC/ATL의 변화

VC++ 2008에는 제법 많은 MFC의 변화가 있다. 그러나 VS.NET부터도 변화가 적지 않게 있었다고 볼 수 있다. 바로 MFC와 ATL 중 공통적인 클래스들은 이들에 의존적이지 않고 사용할 수 있도록 된 것이다. 대표적으로 CString을 들 수 있다. VC++ 6에서는 CString 하나만 쓰려고 해도 MFC를 들고 다녀야만 했다. 그러나 버전 7, 그러니까 VS.NET 부터 (mfc70*.dll)는 CString, CRect, CPoint와 같은 타입들은 죄다 독립적으로 빠져 일반적인 Win32 프로젝트에도 붙여 쓸 수 있다.

또 뭐가 있을까. 정말 VC6을 아직도 쓰는 사람들이 있으면 도시락 싸가면서 말리고 싶다. 그 만큼 얻는 이득이 많다. 딱 하나 불편한 점이 있다면, MFC/ATL dll을 따로 배포해야 한다는 점 정도만 있을 것이다. 글쎄다. 정말 어떤 점이 VC6에서 VS 2005 혹은 VS 2008의 이전을 가로 막는지 궁금하다. VS 2008의 C/C++ 기능은 보다 많이 강화가 되었기 때문에 바꾸어야할 이유는 더 많아졌다.

운영체제야 비스타를 쓰라고 강요할 이유가 없다. 그러나 개발툴은 보다 안전하고 보다 빠르고 보다 효율적인 개발을 할 수 있다는 점에서 새 버전이 나오면 적극적으로 이전할 필요가 있다.

과거 십만 라인 프로젝트들을 바꿀 때, 쉽지는 않았다. 그런데 일주일 정도면 충분히 이전할 수 있었다. 오히려 컴파일러가 더 좋아지고 CString의 특정 함수의 프로토타입이 더 좋게 바뀌어서 잠재된 버그까지 잡을 수 있었다. 반복적인 노가다가 필요했지만 충분히 보상되고도 남는다. 그래서 더더욱 최소 VS 2005의 업그레이드를 추천한다.