며칠동안 어떻게 언급을 해야 하나.. 해서 고민을 많이 했습니다만...
일단, 의견을 나누어보는 것이 급선무라고 생각됩니다.

며칠전에 올린 오픈 레터의 내용으로 짐작해볼 때, 볼랜드는 이미 내부적으로 기존의 C++Builder 제품군을
대신하여, 크로스플랫폼 개발환경인 C++BuilderX로 집중할 계획을 세워놓고 있는 듯 합니다.
원래 이번 오픈레터에서는 기존 C++Builder 및 VCL 지원에 대한 언급이 있기로 했었는데...

더욱이 자바 기반 크로스플랫폼 IDE인 C++BuilderX에서도 VCL은 지원하지 않고, VCL .NET만이 지원될 전망입니다.
VCL 지원이 없어지는 대신 wxWindow라는 새로운 오픈소스 C++ 프레임워크가 지원되는데, 볼랜드에서는
이 프레임워크에 비주얼 디자이너를 붙여서 C++ RAD로서의 이전의 C++Builder를 대체하려는 것으로 보입니다.

따라서 Win32에서 VCL 기반으로 개발을 진행하는 대부분의 C++Builder 개발자에게는 사실상 C++Builder가
단종된다고 보시면 됩니다. 물론 C++Builder의 첫 버전이 등장할 때 기존의 볼랜드 C++을 대체한 것처럼
메이저 업그레이드라고 볼 수 있겠습니다만.

물론 어제 알려드린 것처럼 델파이8의 경우에도 Win32 VCL 지원은 이제 제공되지 않으므로, 이제 VCL이 아니라
VCL.NET의 시대로 접어드는 것이니 Win32 VCL에 너무 집착할 필요가 없다고 생각할 수도 있습니다.
하지만 델파이8의 경우에는 적어도 VCL.NET이 주류 프레임워크로 지원되지만, wxWindows를 메인 프레임워크로
하는 크로스플랫폼 C++ 개발툴인 C++BuilderX에 있어서는 매니지드 코드의 비호환성을 갖는 VCL .NET이
천덕꾸러기로 전락할 가능성이 아주 높습니다.


아, 물론 C++BuilderX는 역시 볼랜드라고 할 만큼 좋은 개발툴입니다.
크로스플랫폼 C++ 개발툴이라는 것은 C++ 개발에 있어 새로운 가치를 만들어내는 중대한 발전입니다.
또 최근 주목받고 있는 wxWindows라는 오픈소스 C++ 프레임워크를 도입하여 거기에 비주얼 디자이너를 붙여
RAD로 완성한다는 계획도 아주 매력적입니다.

문제는, 기존에 VCL이 있었고, 그 VCL이 언어로는 파스칼로 되어있기는 했으나 그 구조나 활용도, 성능 등
총체적인 평가로 볼 때 대단히 훌륭한 프레임워크였다는 것입니다. 또한 VCL의 형제뻘인 CLX를 통해 크로스
플랫폼도 가능합니다. 애초에 볼랜드가 CLX와 카일릭스를 만들어낼 때, 단순히 윈도우-리눅스 크로스플랫폼에
그치는 것이 아니라 유닉스나 맥OS 등 다른 OS로도 가능성을 열어놓지 않았습니까.

그런데 이제 와서 VCL과 CLX는 어디로 가고 난데없이 wxWindows라는 새로운 프레임워크를 익혀야 하는 상황이
된 것입니다. 물론 VCL.NET과 매니지드 코드 지원이 추가된다고는 하더라도 역시 크로스플랫폼 개발을 기치로
하는 C++BuilderX에서 닷넷 지원이 메인이 되기는 힘들 것이라고 생각됩니다.


현 시점에서, 제가 생각할 수 있는 가장 좋은 볼랜드의 대응 방법은, 비주얼스튜디오에 대응하는 거대
스튜디오 제품을 만들어 닷넷 시장에서 마이크로소프트와 정면으로 대치하는 겁니다.

예를 들어서, C#빌더와 델파이8은 IDE의 버전 차이가 있기는 하지만 둘 다 BDS라는 새로운 IDE를 사용하고,
대부분의 기능이 동일합니다. 차이점이라면 각각의 언어를 지원하기 위한 몇가지 위저드 정도입니다.
더 정확히 말하자면, BDS라는 거대 개발 플랫폼에 각각 C# 컴파일러와 델파이 닷넷 컴파일러 + VCL.NET이
얹혀져 있는 모양이죠.

그러면, BDS 위에 C#과 델파이 닷넷 컴파일러가 합쳐지고 VCL.NET을 탑재한 데에, 빌더의 C++ 컴파일러가
더해진다면 그야말로 비주얼스튜디오 닷넷과 정면으로 대결하는 거대 개발 플랫폼이 되는 겁니다.

그런데 이런 시나리오는 좀 난망하지 않을까 싶습니다. 일단 볼랜드의 제품 전략이 모든 개발툴을 통합하는
거대 툴 전략이 아니라, 개별 제품 전략이고.. 또 제 개인적인 생각입니다만, 마이크로소프트와 닷넷 지원
관련으로 계약을 맺을 때 모종의 이면 협약이 있지 않았을까 싶습니다.
"언어별 통합 스튜디오를 만들어서 MS와 정면 대결하지 않는다" 라든지, "Win32는 더이상 지원하지 않는다" 라든지
말입니다.


어쨌든.

저는 지금 볼랜드가 구상하는 C++ 전략이 아주! 맘에 안듭니다.
일단 C++ 개발툴을 위한 자바 기반 IDE라는 것이 크로스플랫폼 C++ 개발툴이라는 전무후무한 작품을 만들어
냈다고는 하지만, OpenTools API마저 자바로 작성해야 하는 것은 황당할 뿐 아니라.. VCL.NET 기반으로
닷넷 애플리케이션을 만드는데 자바 기반 IDE를 사용한다는 웃지 못할 모양새가 되는 겁니다.
(여기서 폼 디자이너가 가능할 지도 의문입니다. 아마 디자이너를 통째로 빼버리고 코드만의 지원이 될 가능성이
많을 듯)

또, 개인적으로(혹은 C++ 개발자들의 성향상) 자바가 C++ 개발에 개입하는 것은 그리 유쾌하지 않습니다.
C++과 자바는 분명히 언어 철학이 다르지 않습니까. C++은 "모든 것을 가능하게", 그리고 성능을 중시하는
언어인 반면 자바는 쉽게 개발하는 것이 주 관심사입니다. for 루프 하나에 CPU 클럭이 몇번 더 들어가느냐
마느냐를 따질 수 있는 C++ 개발을 위해, "메모리 최소 요구량 512메가바이트"라는 묵직한 자바 IDE는 도무지
어울리지 않습니다.

또 볼랜드가 진정 C++ 개발 시장에 대해 의지가 있었다면 애초에 VCL을 억지로라도 C++로 포팅했어야 마땅할
것을, 이제 와서 wxWindows라는 새로운 프레임워크를 들이고 VCL은 쪽방살이를 시키는 것도 맘에 안듭니다.


그래서.

저는 어떤 식으로든 볼랜드에 제 의견을 전달하려고 합니다. 문제는 대안이 쉽지 않다는 것입니다.
볼랜드도 당연히 여러 방법들 중에서 각고의 고민 끝에 힘들게 결정한 것이 현재의 상황일 것입니다.
이미 C++BuilderX의 첫 버전이 발표된 상황에서(아직 출고는 안되었습니다) 무작정 기존 계획을 백지화하고
전면 재고하라, 라는 것은 대안이 아니죠. 또한 개발툴 시장의 현 상황에서 C++Builder의 시장은 볼랜드에게
계륵과도 같을 것이란 것도 짐작할 수 있습니다.

어떤 것이 우리 개발자에게, 그리고 볼랜드에게도 '상생'의 길이 될 지 한번 의견을 나누어봅시다.
제 생각과는 달리 C++BuilderX의 순수 C++ 지원이 더욱 매력적일 분도 있을 것이고, CLX가 중심이 되어야 한다는
생각을 가지신 분도 있을 수 있습니다. 또 반드시! VCL 지원이 계속되어야 한다는 분도 있을 것이고, 그중에는
기존의 C++Builder 제품군을 무조건 고수해야 한다는 분과, C++BuilderX에서 VCL 지원이 추가되는 정도면
좋다는 분도 있을 것입니다. 중요한 것은 역시, "현실적인" 대안이 있어야 볼랜드에 관철시킬 수 있다는 것입니다.
불가능하다, 혹은 우리의 능력을 벗어난 일이라고 생각하실지 모르겠습니다만, 저는 분명히 그 가능성을
믿습니다.

C++Builder가 앞으로 어떻게 되어도 상관없다는 분이 아니면, 이 글을 읽고 어떤 조그만 생각이라도 있다면,
의견을 모아봅시다. 단순히 좋다, 싫다, 혹은 조금 이렇게, 조금 저렇게 정도라도 말입니다.
의견이 적거나 무시할 수준이면 오늘밤이나 내일 정도에 제 생각만으로 볼랜드에 메일을 보낼 생각입니다.
의견이 많이 개진되고 활발히 논의가 되면 3~4일 정도 의견을 모은 후에 수렴된 의견으로 몇가지 대안들을
만들어 볼랜드로 역시 메일을 보내겠습니다.

그럼...