Bob Swart
C++Builder Developer's Journal 9월호

델파이와 C++빌더의 열렬한 팬 개발자인 저로서는, 볼랜드 컨퍼런스(BorCon)는 해마다 제게 가장 의미있는 행사입니다. 올해도 역시 다르지 않았습니다. 과거엔 BorCon이 좀 더 크고 화려했지만, 올해 역시 여러 종류의 사람들에게 각각의 컨퍼런스를 경험하게 해주는 세션들과 트랙들로 충분히 큰 행사였습니다. 메인 컨퍼런스의 주제가 소프트웨어 개발 최적화(Software Development Optimization: SDO)인데도, C++빌더 개발자들을 위한 기술 세션은 실망스러울 정도로 몇개 되지 않았습니다. 몇몇 델파이 세션은 C++빌더에도 해당되는 내용이긴 했지만, C++빌더 혹은 C++빌더X와 관련된 세션의 수는 정말 적었습니다.

하지만 이들 세션들 중에 놓쳐서는 안될 것이 있었습니다. Meet the C++ Team 세션이 화요일 저녁 8시 정각에(화요일의 테크 뮤지엄 이브닝 이벤트의 직후에, 더 정확히는 그 도중에) 있었던 겁니다. 전 늦고 싶지 않았기 때문에 가지고 있던 "Forces of Nature" 쇼의 무료 IMAX 티켓을 포기하는 결심까지 해야 했습니다. 세미나룸은 50여명의 사람들로 들어차있었고, 모두 C++빌더의 팬이자 사용자들이었습니다. (C++빌더X도 사용하는 사람들도 한두명 있었습니다) 그리고 우리 모두 C++빌더의 팬이었음에도, 시작부터 방안의 공기는 좀 무겁게 가라앉은 상태였습니다. 참석자들 중 적지 않은 사람들이 오픈레터가 아직도 나오지 않은 사실에 대해 실망하고 좀 화가 나 있기까지 하다는 것이 분명했기 때문입니다.

연단위의 사람은 존 레이 토마스("JT"라고 부릅니다)였고 그의 상사인 조지 파울리니도 함께였습니다. 청중 중에는 C++ 팀의 멤버들도 있었고, 데이비드 I(디벨로퍼 릴레이션 담당 임원), 마이클 스윈들, 대니 쏘프, 그리고 델파이 팀의 앨런 보이어도 있었습니다. JT는 조금 초조해 보였습니다. 그는 이제 마지막 결정이 다가오고 있다고 말했습니다. 그가 보여준 첫번째 슬라이드는 그가 말하려는 네가지 주제의 목차였습니다. 오픈 레터로부터 시작해서, C++빌더의 미래, C++빌더X의 현재 상황, 그리고 마지막으로 .NET에서의 C++ 지원이 각각의 주제였습니다.

오픈 레터

JT의 첫번째 주제는 청중들로부터 즉각적인 반응을 얻었습니다. (상당히 나쁜 반응이었습니다. 저로서는, 이렇게 열정적인 개발자들을 마주할 용기를 낼 수 있을지 자신이 없더군요.)

오픈 레터에 대해서, JT는 작년의 볼랜드의 조직도를 보여주면서 시작했습니다. 거기에는 JP 르블랑이 C++ 그룹을 이끌고 사이먼 쏜힐이 델파이 그룹을 이끄는 등의 내용이 포함되어 있었습니다. 하지만 그 당시부터 조직 개편은 이미 시작되고 있었습니다. 현재 JP와 사이먼은 떠난 상태이며, 조지가 C++, 델파이, 자바를 포함하는 개발툴 부문의 책임을 맡고 있습니다. 조직 개편 이후로, C++ 팀은 C++빌더의 새로운 버전에 대해 구상하고 있었고 실제로 추진할 계획이었습니다. JT가 이런 사실을 언급하자 방안에는 큰 환호성이 울려퍼졌습니다. 하지만, 모두에게 실망스럽게도, 다음 슬라이드가 보여준 것은 C++ 팀이 필드(볼랜드의 영업 파트)의 요구로 인해 이 프로젝트를 포기해야만 했다는 내용이었습니다. 그 요구의 내용은 C++빌더X의 시장에서 상당한 수입 기회가 예상된다는 거였습니다. (하지만 현재까지는 사실이 아닌 것으로 보입니다) 그 결과로, 모든 가용 C++ 인력은 C++빌더X의 개발에 투입되었고, 이런 상황이 C++ 팀이 C++빌더를 포기하게 강요했습니다. 그래서, C++ 팀이 C++빌더를 하고 싶음에도 불구하고 그들은 먼저 C+빌더X를 먼저 작업해야 하고, 지금도 작업중인 상태라는 것입니다.

만약 이런 모든 사실이 오픈 레터를 통해 알려졌었더라면, 볼랜드 내부의 변화와 C++빌더X로 전환하라는 요구 때문에 여러 버전의 오픈 레터가 나와야 했을 수 있었습니다. 그 각각은 서로 다른 전략을 설명했겠지요. 볼랜드는 이런 방향 전환이 차라리 우리에게 아무것도 말하지 않는 것보다 더욱 심한 혼란을 초래할 것이라고 판단했습니다. 그래서 그들은 우리에게 아무런 말도 하지 않았으며, 오픈 레터는 공개되지 않았던 것입니다. 이런 식으로 그간의 일을 설명하는 데 대해 JT가 그다지 편한 입장이 아니었다는 것은 분명했지만, 적어도 그는 솔직했습니다.

C++빌더의 미래

이제 긍정적인 느낌의 주제로, C++빌더의 미래에 대한 내용이었습니다. JT는 C++ 팀이 아직 C++빌더를 믿고 있다는 사실과, C++ 팀이 새로운 C++빌더의 버전을 내놓아야 한다는 점을 분명히 했습니다. 문제는 어떻게, 언제냐, 라는 것입니다. 이 명제에 대한 해답은 신속히 나와야 합니다. 왜냐하면 볼랜드가 너무 오랫동안 기다릴 경우 기회는 사라져버리고 C++빌더는 영원히 죽어버릴 것이 분명하기 때문입니다.

C++ 팀이 모색하고 있는 가능성들 중 하나는 C++빌더를 볼랜드 디벨로퍼 스튜디오(BDS, 갈릴레오) IDE의 일부로 포함시키는 것입니다. BDS IDE는 C#빌더(BDS 1.0), 델파이 8 for .NET(BDS 2.0), 그리고 다이아몬드백(Win32용 델파이, .NET용 델파이와 C#을 포함: BDS 3.0)에도 사용되어왔습니다. 다이아몬드백은 다양한 개발툴을 포함하는 BDS의 첫번째 버전입니다. 이 아이디어는 다음 버전의 델파이(예를 들면 BDS 4.0)를 C++ 특성을 가지도록 확장하는 것이 가능한가의 문제입니다. 그 결과는 Win32용 델파이, .NET용 델파이와 C#과 함께 Win32용 C++ 개발툴이 모두 하나의 IDE에 탑재되는 형태가 될 것입니다. 물론, 이상한 모양새가 될 수도 있습니다.

우리를 조용히 하려고 말을 늘어놓는 것이 아니라는 것을 명확히 하기 위해, JT는 C++(VCL)이 내장된 특별한 버전의 BDS를 실행시켰습니다. 그는 잘 알려진 에디트박스, 리스트박스, 버튼 데모를 만들고 한줄의 C++ 코드를 작성하고는 애플리케이션을 실행시켰습니다. 그는 실제로 디버거가 동작하는 것까지 보여주었기 때문에 이것이 단순한 트릭이 아니라는 것을 알 수 있었습니다. 가장 반가웠던 사실은, 나중에 델파이 팀에 있는 사람들로부터 들은 사실인데, 이런 모든 작업이 C++ 팀 내에서 진행된 것이라는 것이었습니다. 이것이 좋은 소식인 이유는, C++(빌더)를 포함하는 다음 버전의 델파이로 인해 델파이 팀의 인력을 이미 필요한 이상으로 나누지 않아도 되기 때문입니다. 한가지 더 제가 들었던 소식은, 더 많은 인력을 투입하지 않아도 된다는 전제 아래 볼랜드의 경영진은 (차기 버전의 BDE IDE에 포함된다면) 확실히 C++빌더를 지원하고 싶어한다는 것입니다. C++ 팀과 델파이 팀은 이런 계획을 수행할 능력이 있지만, 추가적인 인력이나 자금 투입은 힘들 것 같습니다.

물론, 이 프로젝트는 양쪽 팀 모두의 조심스러운 계획과 고려가 필요합니다. 그러니 이 아이디어가 성공 가능성이 있을지 기다려봅시다. JT의 말에 따르면, 12월 15일(물론 올해)이 이 프로젝트를 진행할지 말지를 결정하는 마지막 날이 될 것이라고 합니다. 진행하는 쪽으로 결론이 날 경우, 이 단일 IDE 접근방식이 C++빌더의 미래를 보장하는 최고의 방법이 될 것입나다. 델파이 제품군에 완전히 통합되며, 잠재적으로 .NET으로의 진전 가능성도 제공하게 됩니다. 진행하지 않는 쪽으로 결론이 날 경우, 그것은 C++빌더의 공식적인 사망 선고가 될 것입니다. 현실적으로, 차후에 또다시 부활 시도가 있을 거라고 생각되지는 않습니다. 여러분이 이 글을 읽는 즈음에도 심판의 날까지는 아직 몇주가 남아있을 것입니다.

C++빌더X의 현재 상황

세미나룸 내의 다수가 관심을 갖고 있었던 C++빌더와는 별개로, C++ 팀이 현재 볼랜드의 또다른 C++ 개발환경인 C++빌더X의 작업에 전념하고 있다는 것을 잊을 수 없습니다. 현재, 기존의 C++빌더X 고객들을 위한 프리 업데이트가 작업중이고(코드네임 부메랑) 여기에는 코드 컴플리션 등 새로운 기능들이 추가될 예정입니다. 이 업데이트의 뒤를 이어 C++빌더X의 새 버전이 출시될 예정입니다. (2005년이라고 들은 것 같습니다) JT는 wxWidget 디자이너에 대한 지원은 연기되었다고 말했으며, 이 사실은 방안에 있던 (두명의) C++빌더X 개발자들을 뒤집어놨습니다. 그들은 이 결정이 C++빌더X가 윈도우에서 사용할 수 있는 비주얼 디자이너가 없는 채로 남겨진다는 의미라는 것을 이해했습니다. 이 문제가 어떻게 처리될지 시간이 지나봐야 알겠지만, 현재로서는 제가 C++빌더X를 사용하지 않는다는 사실에 기쁠 따름입니다.

아직도 볼랜드의 영업 파트는 자신들이 C++빌더X로 새롭고 성장하는 시장을 개척하여 볼랜드에 거대한 수익을 가져다줄 수 있을 거라고 확신하고 있습니다. 따라서 크게 C++ 팀의 입장에서 바라본다면, 우리는 C++빌더의 미래를 이끌어줄지도 모르는 C++빌더X의 성공을 기원해야 합니다. 만약 C++빌더X의 다음 버전이 성공하지 못한다면, 솔직히 남겨진 C++ 팀이 어떻게 될지 모르겠습니다.

폴 거스타브슨(임프주: 청중중 한명으로 이 세션 관련 블로그를 먼저 썼던 분)은 "C++빌더"와 "C++빌더X"라는 이름이 너무 비슷해서 혼란을 일으킨다고 지적했습니다. 그는 "C++빌더X"라는 이름을 "터보C++X"로 바꿀 것을 제안했습니다. JT도 이름은 바뀔 수 있다고 동의했습니다. (개인적으로 그 이름이 "터보C++X"로 바뀌기를 바라지는 않지만.)

.NET에서의 C++ 지원

JT의 세션에서 마지막 주제는 .NET에서의 C++ 지원에 대한 것이었습니다. 작년에는 이 문제는 그다지 이슈가 되지 않았지만, 현재 마이크로소프트는 매니지드 C++을 지원하기 시작했습니다. 마이크로소프트는 .NET을 위한 매니지드 C++ 컴파일러를 작업중이며, 볼랜드는 표준화 과정에 실질적으로 참여하고 있습니다. (볼랜드의 C++ 언어 확장이 매니지드 C++에 쉽게 매핑될 수 있도록.) 이런 노력의 결과로 마이크로소프트의 C#이나 VB.NET, 볼랜드의 델파이 .NET과 같은 새로운 .NET 컴파일러가 될 것으로 보이고, 볼랜드 디벨로퍼 스튜디오와 연동될 수 있습니다. 델파이 .NET에서 VCL for .NET이 이미 제공되고 있는데다, C++(빌더)의 .NET 에디션은 그다지 많은 노력을 필요로 할 것으로 보이진 않습니다. 특히 C++(빌더)가 볼랜드 디벨로퍼 스튜디오에 내장된다면 더욱 더 그럴 것입니다. 이런 진행 방식은 매니지드 C++의 잠재적인 시장이 C++빌더의 미래에도 이득이 될 것으로 보입니다. C++빌더를 사용하는 개발자들은 .NET으로 이전하는 빈틈없는 마이그레이션 통로를 갖게 되니까요.

C++빌더에 새로운 희망이?

C++빌더 개발자중의 한사람으로서(죄송하지만 C++빌더X에는 그다지 관심이 없습니다), 12월 15일은 제게 대단히 중요한 날입니다. C++빌더가 미래를 갖게 되든(매니지드 C++과 같은 확장까지 포함한 미래), 혹은 영원히 저승으로 가버리게 되든 말입니다.

한가지 잊지 말아야 할 것이 있습니다. C++ 팀은 C++빌더에 대해 확고하게 믿고 있으며, 설득이 필요한 것은 볼랜드의 경영진(혹은 아마도 조직상의 여러 직급)입니다. Meet The C++ Team 세션에서, 폴 거스타브슨은 C++빌더 개발자들에게 C++ 팀을 도와 볼랜드의 경영진에게 오픈 레터를 쓸 것을 제안했었습니다. C++빌더 뉴스그룹, 폴의 블로그, 혹은 제 사이트인 C++빌더 게이트에서 이 오픈 레터에 대한 소식이 나오길 기다려주십시오.

볼랜드의 영업 파트는 새로운 시장에서의 C++빌더X를 믿고 있지만, C++ 팀과 델파이 팀은 C++빌더에 새로운 미래와 새로운 희망을 주기를 바라고 있습니다. C++빌더 개발자들에게 미래를 가져다줄 새로운 희망을 말입니다. 2004년 12월 15일, 지켜봅시다!


원문: http://cppbuilderdevjournal.com/current_issue/vol8_num9.4.htm
번역: 박지훈.임프 cbuilder@borlandforum.com