말씀하신.. 델마당에 올라왔던 그 글을 저도 봤고 좀 억지다 싶었습니다. 이미 델마당에 썼던 글이지만 참고하시라고 여기에 다시 썼던 글을 옮겨보지요. 논란이 델파이와 비주얼 C++을 대상으로만 한 것이라서 저도 그에 대해서만 썼고 아래 글에서 C++빌더는 논외의 문제입니다.


rrr 님이 올리신 글-----------------------
> 델파이의 가장 큰 장점이 빠른 속도로 애플리케이션을 개발할 수 있다...인데..
>
> 개발하는 프로그램의 규모가 어느정도 커지면..더이상 속도는 빨라지지 않습니다.
>
> 그 이유는..VCL을 버리고 개발하는 플그램에 맞는 라이브러리를 새롭게 개발해야 되는 시점이 오기 때문이죠..
>
> VCL이 없어지면..(정확하게 말하면..TComponent 이하 클래스들) 더이상 델파이의 장점은 존재하지 않습니다.
> 이 시점부터는 오히려..더많은 노하우와 샘플, 다규먼트들이 알려진 visual cpp가 더 크게 부각됩니다. 게다가 cpp는 하는 인력들이 많기 때문에 정보교환도 더 쉽고요..여러가지 면에서 비주얼 cpp가 더 낫습니다.


먼저 게임 개발... 게임 개발에서 델파이보다 비주얼 C++이 나은 건 사실이라고 할 수 있습니다. 그런데 규모나 성능과는 아무 상관이 없는 문젠데요? 델파이가 게임 개발에서가지는 마이너스 요소는 오직 다이렉트X의 API가 기본적으로
C++을 기준으로 되어 있기 때문입니다. 이걸 계속 델파이용으로 포팅하는 많은 분들이 있지만, 아무래도 MS에서 다이렉트X 관련 신기술을 발표한 후 시간이 좀 걸리는 것이 불편한 점입니다.

그리고... 규모가 커지면 델파이의 장점이 사라진다고 하셨는데요. 규모가 커지면 UI가 없는 프로그램이 되나요? 희한한 논리네요. 먼저, rrr님께서 말씀하신 논리 그대로를 검증해봅시다.

예를 들어 말이죠. 규모가 작은 상태에서 비주얼 C++ 기반의 프로젝트에서 3개월 걸릴 프로젝트가 있다고 가정합시다. 그리고 거기에 UI에 걸리는 시간이 1개월 반, UI와는 무관한 로직 개발에 1개월 반이 걸린다고 칩시다. 그 프로젝트를 똑같이 델파이로 했다면 UI 개발에 보름, 로직 개발에는 역시 1개월 반, 결과적으로 전체 프로젝트 기간이 1개월 줄어듭니다.

그럼 이 프로젝트가 규모가 커져서 로직 개발에 4개월 이상이 걸리게 되었다고 합시다. 규모가 커졌다면 UI도 어느 정도는 늘어나니까 비주얼 C++ 하에서 UI 개발에 2개월쯤 걸린다고 칩시다. 델파이로 바꾸면 보름에서 약간 늘어나서 3주쯤 걸린다고 합시다. 그러면 전체 프로젝트는 4개월 3주만에 끝납니다. 규모가 커졌을 때 비주얼 C++ 기반에서 5개월 반이 걸릴 것이 델파이에서 4개월 3주에 끝납니다. 3주의 차이가 나는 건데, 이 3주는 전혀 가치가 없다고 생각하시나요?

이번에는 rrr님의 논리가 처음 가정부터 잘못되었다는 얘기를 해보겠습니다. 님께서 말씀하신 것은 아예 C++이 쓰이고 있는 분야, UI에 비해 상대적으로 로직이 아주 많은 분야를 가정한 것입니다. UI가 많은 분야는 비주얼 C++이 아예 사용되고 있지 않다는 걸 무시한 겁니다. 아시죠? UI가 많으면 비주얼베이직으로 합니다. 만약 UI도 많고 로직도 많으면 어쩔 수 없이 VB와 VC를 섞어쓸 수밖에 없죠? 프로그램 구조상 OCX가 필요하지 않은 경우에도 어쩔 수 없이 OCX로 만들어야 하고 당연히 복잡도가 더 올라갑니다. 그래서 쓸데없이 공수가 더 많이 들어가죠.

이게 현재까지 MS가 제안하는 Win32 개발 방식의 결정적인 문제입니다. 개발자를 저급 개발자(VB)와 고급 개발자(VC)로 나눠서 공략한 것은 마케팅 측면에서는 아주 잘 먹혔는데, 실무에서 사용하는 개발자에서는 정말 불편합니다. 한 개발자가 전혀 비슷하지도 않은 두 언어를 모두 알아야 하든지, 아니면 간단한 일에도 개발자 두명을 고용해야 합니다.

그게 안되니까 VB밖에 모르는 개발자가 C++에서는 정말 쉽게 할 수 있는 일을 어떻게든 해결하려고 온갖 희한한 편법을 동원합니다. 반면 VB를 언어 취급도 안하는 고매한(?) C++ 개발자분들께서는 어떻게든 VB를 통하지 않고 해보려고 C++로 복잡한 UI를 만드는 노가다짓을 서슴치 않습니다. 이게 좋은 현실인가요?

더 많은 노하우... 얘기하셨는데, 그렇다면 델파이에는 풍부한 컴포넌트가 있습니다. 액티브X로도 좋은 기술을 잘 포장한 컴포넌트가 적지 않지만, VCL 컴포넌트의 방대한 양에 비하면 새발에 피입니다. 그리고 그중에는 무료인 것도 널리고 널렸습니다. VCL 컴포넌트가 방대한 이유도, 하나의 개발툴에서 VB와 VC의 역할을 모두 할 수 있기 때문입니다. UI 개발을 하던 개발자가 실력만 된다면 자기가 실무에서 몸소 필요성을 느꼈던 컴포넌트를 직접 만들게 됩니다. VB/VC에서는 OCX 컴포넌트 개발자인 VC 개발자와 그걸 사용하는 VB 개발자가 나뉘어져 있기 때문에 사용하는 사람의 실무적인 필요가 개발하는 사람에게 직접적으로 와닿지 않습니다. 그래서 OCX 컴포넌트보다 VCL 컴포넌트가 압도적으로 많은 겁니다.

VCL에서 지원하지 않는 기능이나 더 성능을 높여야 하는 경우를 말씀하셨는데, 개발일을 해보셨으면 아시겠지만 최적화를 한다고 해서 프로젝트 전체 소스코드를 다 최적화하지는 않습니다. 실제로 시간을 많이 잡아먹는 병목 구간은 일부이기 때문에 성능 최적화가 필요해도 그 부분만 하지 않나요?

C++ 인력이 많으니까 정보 교환도 쉽다고 하셨는데요. 지금까지 비주얼 C++을 공부해오시면서 C++ 문법을 공부하는 데 시간이 더 많이 걸리던가요 아니면 MFC 공부하는 데 시간이 더 많이 걸리던가요? C++ 개발자가 많기는 하지만, 그리고 C++ 개발자들 중에서 win32에선 비주얼 C++ 개발자가 가장 많기는 하지만, 그렇다고 모든 C++ 개발자가 그대로 비주얼 C++ 개발자인 건 아닙니다. 그냥 C/C++만 하던 개발자가 눈앞에 MFC가 주어졌을 때, 'MFC 정도야!'하면서 순식간에 습득해서 실무를 할 수 있나요?

자 그럼, 그 많은 C++ 개발자들 중에서 델파이로 쓱싹쓱싹 폼 개발하는 것 만큼 MFC를 능숙하게 다룰 수 있는 개발자가 얼마나 되지요? 델파이 개발자보다 많을까요? 제 생각에는 턱도 없습니다. C++ 개발자들은 많아도 비주얼 C++ 개발자들은 경쟁력이 없습니다.

이게 비주얼 C++의 함정입니다. 장점이 있는 건 엄밀히 말해서 C++이지 MFC가 아닙니다.
무슨 정보 교환이 쉽다는 거지요? 예를 들어 데브피아에서 생각해봅시다. 델파이에서는 너무나 쉽게 해결되는 문제로 고민하고 있는 그 많은 질문, 답변을 제외하고, 델파이에서도 역시 어려운 복잡하 문제의 갯수가 과연 델파이 사이트들에서 쌓인 질문, 답변보다 그렇게 압도적으로 많을까요? 비주얼 C++ 개발자라고 자처하는 많은 개발자들이 델파이에서는 너무나 쉽게 해결될 문제로 허덕이고 있지 않습니까?