아, 박지훈님께서 이런 글을 적어 놓고 나서 내심 생각을 해 보니 적을 게 많네요. ^^

처음 CBuilder를 접했을 때
정확히 몇년도인지는 기억이 나지 않지만(90년대 중반쯤) 아마 마이크로소프트웨어 잡지 CD로 나온 것으로 알고 있습니다. 해당 CD를 PC에 넣고 설치할 때의 설레임이란... 군대 가기 전에 C언어를 했었고, 제대를 하고 나서는 Delphi를 사용했었기 때문에 CBuilder에 대한 기대는 참으로 컸었습니다. 설치를 마치고 나서 ShowMessage("Hello World") 를 출력할 때의 감동은 지금도 잊을 수 없네요. ^^ 컴파일러는 직접 사용해 보면서, 잡지에 나오는 여러 Review들을 보면서 이제 대세는 CBuilder일 것이라는 추측을 했었습니다. 그런데 실제 현업에서 사용을 해 오면서는 뭐랄까... 아쉬운 부분들이 하나둘씩 보이더군요.

CBuilder vs VS 첫번째
수많은 컴파일러들이 존재하는 상황에서 CBuilder와 VS 2가지만 가지고 운운하는 것은 좁은 관점으로 볼 수도 있겠습니다만, 일단은 요 2개만 얘기해 보겠습니다. 예전에 어떤 음성 코덱 C 소스를 구했더랬죠. 음성 코덱은 압축과 해제만을 담당하기 때문에 처음 한번 잘 만들어 놓으면 나중에 다시 빌드를 할 일이 별로 없습니다. 그만큼 interface가 간단명료하다는 것이고, 당연히 별도의 독립 모듈(dll)로 만들어 놓으면 다른 언어와도 쉽게 호환이 가능합니다. 2000년대 초반에 간단한 테스트를 했더랬습니다. 컴파일 옵션을 모두 속도가 빠르게 설정해 놓고 C++Builder 및 VC로 컴파일을 한 다음에 속도 테스트를 한 것입니다. 그런데, 안타깝게도 VS모듈이 더 빠르더군요. 속도가 중요한만큼 결국 코덱 컴파일은 VS로 하자는 결론을 내렸습니다. 그리고 VS로 컴파일한 것이 더 빠를 것이라는 믿음(잘못된 편견을 수도 있겠지만)은 아직까지 변하지 않았습니다.

CBuilder vs VS 두번째
MFC와 VCL간의 대결 얘기입니다. 델파이가 초기에 설계될 때의 VCL 구조는 지금에 와서 봐도 참으로 훌륭한 구조라고 보여 집니다. OOP적인 관점에서 봤을 때 솔직히 게임이 되지 않습니다. 당연히 VCL이 훨씬 뛰어나죠. VCL이 리눅스로 포팅작업이 된 것만 봐도 그렇구요. DC(Device Context)와 Canvas라는 용어의 차이만 봐도 그렇습니다. Canvas... 얼마나 이해하기 쉽습니까? DC, 쉬벌 이거는 뭐 처음에는 들어도 무슨 말인지 잘 모르고, 이해를 하려고 하면 시간이 오래 걸리죠. 아무튼 OOP 적인 관점에서 봤을 때에는 VCL의 훨씬 뛰어나다라는 것은 분명합니다.

MFC는 그냥 Win32 OS에서 제공하는 API의 첫번째 handle이라는 인자를 encapsulate화해 놓았다는 느낌밖에 들지 않습니다. 그만큼 MFC는 Win32에 의존적으로 설계가 되었죠. 그런데 이게 장점일 수도 있고 단점일 수도 있는데 그만큼 OS에 친밀하다라는 얘기도 됩니다. 예전에 RTOS 기반에서 프로그래밍을 한 적이 있는데, 해당 RTOS에서 제공하는 API가 Win32 API와 비슷했습니다. 그만큼 RTOS 를 제공하는 벤더가 Win32 개발자들을 많이 신경을 쓴 흔적이 보이더라구요. 개인적인 결론을 내린다면 클래스 설계는 당연 VCL이 뛰어나고 Win32 환경을 이해하기 위해서는 MFC가 좀 더 좋을 수 있다라고 하는 정도로 하겠습니다(참고로 저는 MFC를 사용하지 않습니다. 필요하다면 Win32 API를 그냥 사용하죠).

CBuilder vs VS 세번째
CBuilder에서 제공하는 기능들을 보면 정말이지 훌륭한 기능들이 많습니다. 그런데 정작 정말 필요한 기능들이 빠져 있거나 컴파일러 자체가 약간 불안전하다라는 점은 시간이 지나도 해결되지 않는다는 느낌을 지을 수가 없습니다. 단적인 예로 저는 Library 프로젝트를 많이 생성하는데, VS에서는 Dependency를 주면 자동으로 링크를 해 주는 반면에, CBuilder에서는 자동 링크를 해 주는 기능이 없습니다, lib 파일을 명시적으로 링크시켜 줘야만 하죠. 이게 너무 불편합니다. 이차이는 아마도 상대적으로 많은 고객(개발자)를 가지고 있는 VS 영역의 수많은 개발자들의 피드백이 CBuilder 진영에서는 상대적으로 적다는 것에 그 원인이 있을 수 있다는 생각을 해 봅니다. 개인적인 느낌을 얘기해 보자면 CBuilder는 고속 주행을 하다가 도로 중간에서 가끔씩 시동이 꺼져 버리는 스포츠카이고, VS는 별로 튀지는 않지만 굴러 가는데에는 별로 문제가 없는 일반 중형차 정도로 느껴 집니다.

CBuilder vs VS 네번째
인터넷이 발달을 하여 요즘에는 프로젝트를 진행할 때 오픈 소스를 많이 이용을 하게 됩니다. 개발자 입장에서 이러한 오픈 소스를 이용하는 가장 첫번째 단계는 그냥 다운받아서 컴파일을 먼저 해 보는 것입니다. 이러한 오픈 소스중 상당한 부분이 플랫폼 독립적입니다. 같은 소스를 가지고 리눅스에서 컴파일하고, 솔라리스에서 컴파일하고... 그런데 Win32에 서 컴파일을 하는 방법에 대한 정보는 대부분이 VS기반입니다. CBuilder에서 컴파일하는 방법에 대한 정보는 상대적으로 많이 부족합니다. 당연히 오픈소스를 검토하거나 테스트할 때에는 VS를 많이 사용할 수 밖에 없습니다.

C++ vs Pascal
개인적으로 상용으로 컴포넌트 만들어서 팔고 있는 모듈이 있고 처음에는 Delphi 만 지원하다가 시간이 지나면서 VS로 지원을 하게 되었죠. 똑같은 모듈을 Delphi용과 VS용으로 만들어서 관리를 해 오고 있습니다.그런데, 이게 관리가 너무 어렵습니다. 한군데 수정을 하면 다른 모듈도 똑같이 수정을 해야 하는데 생각보다 많이 손이 갑니다. 오랜 고민을 하다가 결국 차기 버전에서는 2개의 언어중에 하나만을 사용하자라고 결론을 내렸고 결국 C++을 선택을 하였습니다. 왜냐? 이유는 아주 간단합니다. VS모듈이 더 많이 팔리기 때문입니다. 언어 자체의 기술적인 장담점이 이유가 아니라 상업적인 이유에 근거를 한 거죠. 그만큼 델파이(Pascal)의 보급이 아쉬운 대목입니다.

생각나는 대로 적어 봤습니다. 개인적인 생각이기 때문에 다른 분들과는 차이가 있을 수 있음을 양해바랍니다. ^^