아래는 조금 전에 볼랜드포럼에도 올렸던 글입니다. 아래의 “‘C++Builder vs. Visual C++’ 자료 만들기에 도움을 부탁” 글에 대해 여러 분들이 써주신 댓글을 읽고 쓴 감상이랄까.. 뭐 그런 잡생각들입니다.
——————————————————————————-

댓글도 많고 참고할 만한 내용도 많은데.. 원래 취지인 비교 자료로 활용할 만한 내용은 그다지 보이지 않네요. 역시 개발자분들이다보니… PT 성격의 자료에는 좀 약한 것이 아닌가 싶기도 하고…

어쨌든… 여러 의견들을 보고 생각나는 대로 써보겠습니다.

DirectX의 경우, 제가 아는 한에서는 DirectX SDK 자체가 Visual C++의 비표준 문법에 의존하고 있어서 C++Builder로 DirectX를 완벽하게 따라가자면 비표준 문법을 따라해야 하는 문제가 있습니다. 다만, 이번 2010 버전에서는 VCL 내에서 Direct2D를 구현했습니다. 이건 다음주쯤 2010 기능 소개 글들을 별도로 올리려고 합니다.

글구.. C++Builder의 기능 중에서 Delphi와 중복되는 기능은 Delphi의 기능일 뿐 C++Builder의 기능이 아니라고 생각하신다면.. 뭐 극단적으로는 그렇게 생각하실 수도 있겠지만, 사실 꽤 여러 해 전부터 VCL이나 IDE의 개발 단계에서 Delphi 뿐만 아니라 C++Builder를 미리 고려한 상태에서 개발하고 있습니다. 따라서 중복되는 기능이 Delphi로부터 빌려왔다는 생각은 사실이 아닙니다.

에… Visual C++의 관점에서 C++Builder를 바라보면 Visual C++보다 모자라는 부분만 보일 수밖에 없을 것입니다. Visual C++를 오래 사용하던 사람의 눈에는 당장 Visual C++에서 아쉬운 기능들이 C++Builder에서 구현되어 있다면 그게 가장 튀는 장점으로 보일 것이고, 반면 Visual C++에 있는 기능이 C++Builder에 없거나 기능이 미약하면 가장 튀는 단점으로 지적하고 싶을 겁니다.

하지만 C++Builder는 ‘더 나은 Visual C++’이거나 ‘더 못한 Visual C++’이 아닙니다. 그래서, 그런 관점에서 바라봤을 때 최소한 공평하려면, “C++Builder의 관점에서 Visual C++의 장단점”도 생각해야겠지요. 이건 “Visual C++ 관점에서의 C++Builder의 장단점”과는 완전히 다른 내용입니다. Visual C++의 관점에서는 연상조차 잘 되지 않기 때문입니다.

지금 출시되어 있는 2009 버전의 관점에서, 제 생각에 C++Builder의 가장 큰 장점은 RAD 보다는 표준을 더 깔끔하게 지키고 C++0x와 TR1, Boost 등의 차기 표준 사항들까지 훨씬 잘 지원된다는 것입니다. 특히 C++0x의 경우 비주얼 C++의 차기 예정 버전인 2010 버전에서 지원이 처음 시작되기는 하지만, 지원 스펙이 겨우 5가지에 불과한 미약한 수준입니다.

그냥 코딩하는 데에 이런 것이 별로 중요하지 않다고 생각하는 분들은 물론 그렇게 생각하실 수도 있겠습니다만, 기본 문법에서조차 종종 호환되지 않는 C++은 반쪽짜리 C++이라고 할 수 있습니다. 만약, 당장 개발만 해서 구현만 하면 그만이지 C++ 표준 같은 것은 중요하지 않다고 자신있게 말하는 Visual C++ 사용자가 있다면, 개인적인 생각으로 그 분은 Visual C++ 개발자이되 C++ 개발자는 아니라고 할 수 있겠습니다.

그 다음의 C++Builder의 장점이 생산성입니다. 물론 이 생산성의 상당 부분은 RAD 개발에서 옵니다. 하지만 단지 RAD라는 것이 전부는 아닙니다. 일단 RAD 측면만 보더라도, 업무 개발 프로젝트에서까지 실제로 사용할 수 있는 유일한 C++ 개발툴이 C++빌더입니다. 이 점에 있어서는 비주얼 C++은 물론 비교할 수 있는 C++ 개발툴이 없습니다.

생산성! 생산성이라는 명제는 정말 한가한 연구원이 아니라면 누구도 무시할 수 없는, SW 개발, 아니 모든 산업계에 있어 가장 중요한 가치들 중의 하나입니다. 그런데 비주얼 C++에서 생산성을 거론하는 것이 가능하기나 할까요. 생산성을 완전히 무시하고 설계되었다고 말할 정도의, 현존하는 개발툴들 중에서 가장 최악의 생산성을 보이는 개발툴이 비주얼 C++입니다. 그래서 생산성은 거론조차 할 수 없는 비주얼 C++ 사용자들은, 그 대신 더 최적화된 코드, 더 강력한 에디터 기능, 뭐 이런 것들을 내세웁니다. 반론의 여지가 충분함에도 불구하고 이런 것들을 다 인정한다고 해도, 과연 이런 것들이 생산성과 교환이 가능한 가치입니까.

아주 드물게 앞으로 비주얼 C++에서 RAD를 지원할 거라는 말이 나오던데… 정말로 근거가 있는 얘기인지요. MS 근처에서 그럴싸하게 흘러나온 얘기들 중 상당히 많은 것들이 아예 현실화가 되지 않고 사라졌기도 하구요. 설사 그게 사실이고, 또 MS가 그런 시도를 해서 성공한다고 해도, 그 결과물은 실제로 C++빌더와 비슷하게 적용하기엔 무리가 많은, 대단히 제한적으로 진행될 수밖에 없을 겁니다. MFC가 호환성의 복병으로 버티고 있기 때문에요.

C++빌더의 생산성 면에서 RAD 자체를 제외하고도 짚어볼 부분들이 많이 있습니다. 이 측면의 생산성 기능들은 RAD와 연관되어 있기는 하지만 RAD는 결과물일 뿐입니다. 예를 들어, C++빌더에서의 윈도우 비스타 에어로 UI 지원은 개발자가 전혀 알 필요가 없습니다. 그냥 기존과 동일한 코드를 컴파일하기만 하면 끝입니다. 최근에 추가된 리본 UI, 역시 그냥 컴포넌트 배치하고 오른쪽 클릭해서 밴드 추가하면 끝입니다. 추가로 어떤 클래스도 어떤 멤버 함수도 외우고 습득할 필요가 없습니다. C++빌더 2010 버전에서는 윈도우 7의 터치 UI와 제스추어 지원이 추가되지만, 역시 공부할 것은 그다지 많지 않습니다.

비주얼 C++에서도 그런가요? 새로운 UI가 추가되면 그걸 쓰기 위해 일일이 클래스를 공부하고 내부 동작을 이해해야 하고 문제점의 여지도 알아봐야 합니다. 최근에 윈도우 7이 곧 출시될 일정이 나오면서, MS에서는 또 열심히 터치와 제스츄어를 공부하라고 독려하고 있습니다. 그런데, 애플리케이션을 개발하는 개발자의 입장에서, 구현할 기능의 핵심이 아닌 윈도우 UI를 적지 않은 시간을 들여 별도로 공부해야 한다는 것은 바보짓이자 주객이 전도된 일입니다.

비스타이건 리본이건 터치이건 제스츄어이건, UI는 UI일 뿐 애플리케이션의 핵심 기능이 아닙니다. UI가 아무리 우아하고 예쁘다고 해도, 그리고 그 미려한 UI로 인해 고객을 끌 가능성을 높일 수 있다고 해도, 핵심 기능이 제대로 되어 있지 않으면 그냥 UI 기능에 대한 샘플 코드에 불과한 것입니다. 그럼에도 이런 방식에 올인하는 개발자는… 공구점에 흔히 파는 펜치를 직접 만들겠다고 산에 올라가 도 닦으면서 펜치를 만들고는, 결국 공구점 펜치보다도 형편없는 펜치나 만드는 셈이 아니겠습니까.

그렇다면, UI에 대해 개발자가 취할 수 있는 최선의 접근 방식은 이런 것이 아닐까요. 새롭고 인기를 끄는 UI를 최대한 활용하면 물론 너무나 좋지만, 그걸 공부하고 구현하기 위해 핵심 기능 구현에 필요한 시간을 심각하게 까먹을 정도여서는 안된다는 것입니다. 그리고 C++빌더의 방식이 바로 그 답입니다.

가끔씩 비주얼 C++의 방식에 갖혀있는 개발자들이 그러지요. UI 설계 기능이 좋은 건 인정하는데 UI는 UI일 뿐이고 그 이상의 가치는 없다, 라고요. 네, 저도 그런 주장에 100% 동감합니다. 그런데, 그렇게 주장하는 분들이 왜 UI 설계를 위해 왜 그토록 많은 시간을 들여서 노가다를 해야 하는 툴에 중독되어 있는 것일까요? 자기모순적이지 않은가요.

어떤 분들은 서버 개발에 있어서는 비주얼 C++과 C++빌더가 동일한 수준인데 그럴 거 같으면 비주얼 C++을 쓰는 게 더 낫지 않냐고 말씀하십니다. 그런 부분도 많겠지만, 그게 사실이 아닌 부분도 많습니다. C++빌더에서는 클릭 몇번에 코드 한두줄 정도면 간단히 끝나는 웹서비스 개발, 비주얼 C++에서는 얼마나 삽질을 해서 개발하는지 아시는지요.

멀티 티어 개발은 어떤가요. 비주얼 C++로 멀티티어 서버를 만든다는 얘기라도 들어보셨는지요. 멀티티어가 덜 고급스러워서? 덜 어렵고 성능이 덜 중요해서? 아니죠. 멀티티어 서버도 극단적인 높은 성능이 필요하고 더 많은 최적화가 필요해서, C++ 수준의 개발이 필요합니다. 그런데 비주얼 C++은 멀티티어 개발에 대해 뭘 할 수 있나요. 아, DCOM? COM+? 뭐… 거론할 가치도 없습니다.

ActiveX? C++빌더나 델파이만큼 액티브X를 간편하게 개발할 수 있는 개발툴은 MS에는 없습니다. 이건 뭐 폼에다 뚝딱해서 컴파일만 하면 되니까요. 액티브X의 내부에 대해 복잡하게 공부할 필요 없습니다. 물론 알면 더 좋지만, 대부분의 액티브X 개발자들에게는 그리 필요하지 않습니다. 이렇게 단순하고 쉽게 할 수 있는 작업을 왜 비주얼 C++을 써서 그 생노가다를 해야 할까요? 배포 크기를 좀 줄이기 위해서? cab으로 압축되면 초고속 인터넷 상황에서는 체감할 만큼 차이도 나지 않습니다.

어차피 더 깊이 들어가려면 따로 공부해야 한다, 라고 말하는 비주얼 C++ 사용자들도 있습니다. 네, 맞습니다. 그런데 대부분의 개발자들은 액티브X, 웹 서비스, 멀티티어 서버, 이런 개발에 있어 그렇게 깊이 들어갈 필요가 없습니다. 그리고 설령 그런 필요가 있는 경우에도 C++빌더에서 접근하는 방식이 더 빠르게 진행할 수 있는 경우가 많습니다.

그리고.. 서버에서는 DB를 액세스하지 않을까요? 게임 서버에서야 DB 액세스 코드를 거의 사용하지 않거나 아주 단순한 수준만 사용하지만, 서버 프로그래밍에서 게임 프로그래밍은 그냥 한 분야에 불과합니다. 클라이언트 못지 않게 DB 연동에 민감한 것이 서버쪽 개발입니다.

그러면 거꾸로 생각해봅시다. 클라이언트쪽 개발에서는 C++빌더가 유리하지만 서버에서는 동등하다, 그래서 서버 전문 개발자에게는 비주얼 C++로도 무방하다, 라는 논리라면요. 서버쪽에서도 C++빌더가 더 유리한 경우가 흔하다는 것을 납득하기만 하면, 결국 왜 두배의 노력과 시간을 들여 두 가지 툴을 공부해서 사용할 필요가 있느냐는 논리가 더 힘을 얻습니다. C++빌더는(사실 델파이도) 하나의 툴을 배워서 모든 것을 다 커버하는데 말입니다. 그것도, 배우기가 쉬운 다른 툴도 아닌, 가장 비생산적이고 가장 배우는 시간도 오래 걸리는 비주얼 C++을 말입니다.

델파이와의 연동에 대해서는 어떻게 생각하십니까. MS 개발툴의 시각에서 바라보자면, C++빌더와 델파이와의 관계는 비주얼 C++과 VB(혹은 닷넷)과의 관계와 비슷하다고 생각할 것입니다. 하지만 C++빌더의 시각에서는 전혀 다른 문제입니다.

C++빌더와 델파이는 오브젝트 레벨에서 완전히 호환되므로 두 언어를 섞어서 하나의 프로젝트에서 하나의 바이너리 실행파일로 링크할 수 있습니다. 이게 VB나 닷넷에서도 가능합니까. 비주얼 C++과 VB의 조합, 비주얼 C++과 닷넷의 조합은, 그 조합 방식이 깔끔하지도 않고 최적화되지도 않으며 한마디로 너저분합니다. 그에 비교하면 C++빌더와 델파이의 조합은, 한마디로 우아할 정도입니다. 원하는 어떤 방식과 레벨로도 연동시킬 수 있으니까요.

더 나아가볼까요…?

미래의 비전을 보면, C++빌더는 비주얼 C++을 더더욱 압도합니다. 비주얼 C++의 미래에 어떤 비전이 있습니까. 지금보다 조금 더 표준을 잘 지키고, C++0x에 남겨진 더 많은 스펙들을 하나 둘씩 추가해나가고, 그게 모두 아닙니까.

C++빌더는 어떨까요. C++빌더는 델파이와 함께 멀티 플랫폼으로 가고 있습니다. MacOSX 버전과 리눅스 버전이 나올 것이며, 모바일(iPhone 혹은 WindowsMobile, 혹은 둘 다) 버전이 나올 것이며, RIA 버전 등 추가적인 플랫폼 지원도 검토중입니다. Delphi Anywhere. C++Builder Anywhere. 비주얼 C++이 천년 만년 윈도우에 갖혀서, 기껏해야 ‘매니지드 코드에도 써먹을 수 있다!’를 외치고 있을 때(도대체 C++로 매니지드 코드를 만든다는 기발하고 어처구니 없는 발상은 누가 했는지 모르겠습니다만), C++빌더와 델파이는 윈도우 이외의 다른 대부분의 플랫폼들까지 주름잡고 있을 겁니다.

비주얼 C++로 닷넷 매니지드 코드를 개발한다! 멋지게 들릴 수도 있습니다. 하지만 그게 얼마나 실제로 효용이 있을까요? VB.NET 조차도 2류 언어로 매장되고 있는 것이 닷넷입니다. 오직 C#만 살아남을 뿐, MS가 설계한 닷넷의 구도 안에서는 비주얼 C++도 잠깐 등장했다 스쳐가는 엑스트라에 불과할 수밖에 없습니다.

과연 비주얼 C++에 비전이 있습니까. 지금 가는 방향대로 그대로 간다면, 그냥 과거에 묻혀버릴 개발툴입니다. 지난 8년간처럼 MS가 닷넷에 올인하면 할수록, 비주얼 C++은 원하지 않았던 사생아같이 될 수밖에 없는 운명입니다. 비주얼스튜디오의 엑스트라, 폭스프로는 지금 어떻게 되었습니까.

물론 C++빌더에 실질적인 단점, 약점들도 많이 있습니다. 오픈MP, C++빌더에서 아직 지원되지 않습니다. 아쉽습니다. 64비트, 아직 지원되지 않습니다. 많이 아쉽습니다. 코드 인사이트 느린 거 맞습니다. 답답합니다. 다들 상당히 중요한 이슈들입니다.

오픈MP의 경우 C++0x와 같은 메이저 기능 업글에 비하면 비교적 가벼운 이슈입니다. 곧 로드맵에 추가될 가능성이 높구요. 64비트 지원 버전은 가까운 로드맵상에 있으니 머지 않아 출시될 겁니다.

하지만, 많은 C++빌더 개발자들이 토로하는 ‘단점’들 중에서는 불공평한 비교이거나 억지스러운 내용도 종종 있습니다.

예를 들어, 최신 버전의 IDE가 무겁고 불안하다고 합니다. 최신 버전에 있어서는 비주얼 스튜디오도 비슷하거나 더 불안합니다. 그만큼 기능이 더 많아져서 무거워졌기 때문입니다. 특히 비주얼 스튜디오 2010은, WFP로 전면 재개발되면서 개발자들의 원성이 자자하다고 하더군요. 엄청나게 무겁고 느려져서요. 그런데 간혹 C++빌더의 최신버전을 비주얼 C++ 6.0과 같은 가벼운 구버전과 비교해서 무겁다고 하는 분들이 있습니다. 불공평한 비교죠.

C++빌더의 에디터 기능이 떨어진다고 하는 분들이 많이 있습니다. 이런 말씀을 하시는 분들중 상당수는 C++빌더 구버전을 사용하고 계십니다. 최신버전에서도 물론 비주얼 C++의 에디터 기능을 다 따라가는 것은 아니지만, 반대로 비주얼 C++에도 없는 아주 멋지고 편리한 에디터 기능들도 있습니다. 역시 불공평한 비교입니다. 매 버전마다 눈에 띄게 IDE 기능들이 강화되고 있고, 어제 첫번째 프리뷰 동영상이 공개된 2010 버전에서는 또한번 눈부시게 발전했습니다.

델파이 쪽도 그렇지만, C++빌더 개발자분들도 알게 모르게 피해의식에 젖어 있는 경우를 자주 봅니다. 네, 당연하죠. 피해가 있으면 피해 의식도 있게 마련입니다. 하지만 자신의 비관적 판단이 피해의식으로 인해 더 과장되고 있는데도 그걸 스스로 깨닫지 못한다면 문제 해결은 점점 더 어려워집니다. 벤더로서 많은 책임을 지고 있지만, 아무리 더 뛰어난 제품을 내놓고 개선하더라도, 편견에서 벗어나 생각을 바꾸는 것은 결국 개발자들 개개인의 몫입니다.

물론 저도 할 수 있는 최대한을 해나가고 있습니다. 오늘도 그랬고, 내일도 그럴 겁니다. 제가 그리 대단한 능력을 가진 사람은 아니지만, 바깥에서 문제점을 인식하고 외쳐왔던 그대로 벤더에서 행동할 수 있는 사람이라고 믿기 때문에, 제가 조인하기 전과 이후는 많이 다를 수밖에 없다고 생각합니다. 또, 그런 일들을 실행해나가기 위해서, 단순한 직원이 아니라 데브기어 오너의 한명으로서 정책에 대한 권한도 강력합니다. 이제 문제는, 나아지느냐 아니냐의 문제가 아니라, 언제쯤 되면 체감할 만큼 나아지게되겠느냐 하는, 오직 시간의 문제일 뿐입니다. 그리고 그 시간을 더욱 앞당기는 것이 저의 최대의 과제이구요.