델파이의 미래 -- 박지훈

[주정섭]

이글은 볼랜드포럼 시샵인 박지훈씨가 작성한 글입니다.

너무 좋은 글이기에 명예의 전당에 올립니다.

원문주소:

http://www.borlandforum.com/impboard/impboard.dll?action=read&db=free&no=10715

반갑습니다. 이기영님.
이기영님께 쓰는 글이기도 하지만, 국내의 모든 델파이, C++빌더 개발자들에게 쓰는 글이기도 합니다.
가려운 데를 긁어주셨다고나 할까요. 이기영님이 거론하신 문제들에 대해 한번쯤 써보려고 했었습니다.
하나 하나 구분해서 답변을 드리겠습니다.

사실 관계

먼저.. 자잘한 문제지만 사실관계가 이상한 부분부터 지적하고 넘어가지요.
"20% 이상 이던 볼랜드 개발자가 이제는 4%에 불과" 이게 어디서 나온 수치인가요? 물론 이기영님이 직접 쓰신 글이 아니고 퍼온 글이니까 이기영님께 따질 문제는 아닙니다.

델파이가 가장 잘나가던 시기보다 지금 점유율이 줄어든 것은 객관적인 사실이라고 보이지만, 20%? 4%? 누구도 낼 수 없는 통계입니다. 그리고 무엇의 퍼센트인지도 모르겠고요.

만약 전통적인 개발툴 시장 중에서의 점유율이라면 4%라는 비율은 말도 안되게 낮게 잡은 것이고, 전체 개발자 시장에서 따진 거라면 근거가 없는 통계입니다. 혹은, 전체 상용 개발 도구 시장에서의 볼랜드의 매출액 비율이라면 통계를 내는 것이 가능은 하겠지만, 별로 의미가 없습니다. 시기적으로도, 언제부터를 따지느냐에 따라 얘기가 팍팍 달라집니다.

도스 시절부터 따진다면 볼랜드 개발툴의 역대 최대 점유율은 아무리 적게 잡아도 50%를 넘어갑니다.

그리고 또 한가지, '오브젝트 브로커'라고 부른 것은 아마도 비지브로커를 말하는 거 같군요.
인용하신 글을 쓰신 분은 우습게 여기는 듯 썼습니다만 비지브로커는 국제적인 분산 프로그래밍의 표준 중 하나입니다.

반면 MS의 DCOM과 닷넷의 분산 프로그래밍 방식은 아직도 표준이 아닙니다. 볼랜드는 비지브로커로 코바 ORB 시장의 절대 비율을 점유하고 있습니다. 분산 아키텍처 전체로 보면 코바의 점유율은 조금씩 낮아지고 있긴 하지만, 적어도 아무것도 아닌 듯이 말할 수 있는 부분은 아닙니다.

델파이는 불안한가

믿지 않는다고 하셨지만, 먼저 과연 델파이의 수명이 얼마 안되어 끝날 것인가에 대해 먼저 써보겠습니다.

2000년에도 2년후, 2003년에도 2년후에는 델파이가 사라질 거라고 했다구요.
그 당시쯤에 한국 MS쪽에서 그렇게 마구 떠들고 다니던 모 인사가 생각나는군요.

별로 관계가 없다고 생각할 수도 있지만, 델파이의 역사를 짚어볼까요. 델파이는 83년에 첫 버전이 출시된 터보파스칼 로부터 시작되었습니다. 도스부터 시작한 거죠. 그리고 아시다시피 윈도우 버전이 있고.. 리눅스 버전인 카일릭스도 있습니다. 그리고 2003년에 닷넷 버전인 델파이8이 처음 출시되어 현재의 델파이2005에 이르고 있습니다. 한편, 파일럿 프로젝트이긴 했습니다만 97년에는 자바용 델파이가 만들어지기도 했습니다.

다시 말해서, C/C++을 제외하면 델파이(오브젝트 파스칼)는 상용 개발툴로는 가장 많은 플랫폼들에 포팅되면서 발전해온 언어입니다. 역사면에서 10주년밖에 안된 자바나 4년쯤 된 C#과는 비교가 안될 뿐더러, 그토록 많은 플랫폼을 거쳐왔다는 것은 다시 말해 언어 자체의 매력도 대단하다는 뜻일 뿐 아니라, 도스부터 닷넷 시대까지 업계가 원하는 모든 요구를 수용해온 유연성이 있다는 얘기입니다. 또 아시는 분들은 다 아는 것처럼, 델파이 언어는 C/C++과 거의 동일한 레벨의 프로그래밍이 가능한 시스템 프로그래밍 언어이기도 합니다.

이런 언어, 즉 강한 매력과 시대를 뛰어넘는 유연성, 그리고 시스템 레벨의 접근성까지 겸비한 언어는 쉽게 사장되지 않습니다. C/C++과 똑같은 이유입니다. 정말로 만에 하나 벤더인 볼랜드가 망하거나 인수된다고 하더라도 말입니다. 단적인 예를 들면 최근에 출시된 크롬이 있습니다. 크롬은 델파이용 컴포넌트 전문 회사인 RemObjects에서 만든 비주얼스튜디오용 오브젝트 파스칼 컴파일러입니다.

http://chromesville.com/

델파이가 건재하고 또 매 버전마다 혁신적으로 발전하고 있는 현재 상황에서 크롬이 그다지 크지는 못할 것이 뻔하긴 하지만, 그건 뭐 볼랜드가 도스 시절에 만들었던 터보베이직이 베이직의 종가나 다름없는 MS의 퀵베이직에 밀려서 제대로 빛을 보지 못했던 것과 마찬가지죠. 그 외에도 델파이를 타겟으로 만든 상당히 강력한 오픈소스 파스칼 컴파일러도 있습니다.

그러니 설사 볼랜드가 일부러 미친척하고 델파이 사업을 접는다고 해도 델파이 시장은 계속 이어질 수 밖에 없죠. MS는, 아마도 한국 지사와 미국 본사 사이에 개발툴 시장에서의 경쟁 정책에 있어 별로 공조가 안되고 있는 거 같습니다.

MS 본사에서 볼랜드를 여러면에서 지원하고 있던 2000년대 초반에, 한국MS의 몇몇 인사들은 볼랜드를 깎아내리지 못해 안달하고 있었으니까요. 본사에서는 볼랜드를 지원하는데 지사에서는 곧 망한다, 망한다 하는 주문을 외우고 있는... 웃기는 상황이죠.

왜 MS가 볼랜드를 지원할까요. 개발 부문에 있어, MS 자신을 제외하면 볼랜드는 MS 플랫폼에서 가장 막강한 영향력을 가지고 있습니다. 고객인 기업 입장에서 특정 솔루션을 선택하는 데 있어 가장 먼저 따져보는 요소는, 막다른 골목이냐 아니냐 하는 겁니다. 만약 닷넷을 선택하려 하는데 닷넷 개발에 사용할 수 있는 개발툴이 MS 자사의 것 하나뿐이라면 기업들은 닷넷으로의 이동을 피하게 됩니다. 따라서 MS는 최대한 많은 서드파티 개발툴 업체들을 닷넷으로 끌어들여야 하는 입장인데, 여기에 볼랜드가 빠지고 나면 아예 구색이 안납니다. 어차피 MS로서는 개발툴 판매가 주목적이 아니므로 비주얼스튜디오 닷넷 하나를 더 팔든 말든 그게 문제가 아니라 닷넷을 확산시키는 것이 최대의 명제입니다. 볼랜드가
닷넷쪽에서 힘을 가지면 가질 수록 그에 비례해서 MS는 어부지리를 얻게 됩니다. 그러니까 비주얼스튜디오 닷넷으로는 닷넷 개발툴 시장에서 주도권만 뺏기지 않을 정도로 시장 점유율을 다른 업체에 내어주어도 MS는 오히려 이익이죠.

이런 이유로 볼랜드는 망할래야 망할 수가 없습니다. 그런 말을 했다는 분은 비주얼스튜디오 닷넷을 과도하게 홍보하려다가 그런 MS의 정책과도 거꾸로 가는 말을 책임없이 함부로 내뱉었다고밖에는 생각되지 않는군요.

이미 몇달전에 알려진 사실이지만, 볼랜드는 올해 안에 출시될 델파이2006 외에도 두개의 버전이 이미 로드맵에 올라 있습니다. 델파이2007, 델파이2008의 로드맵이 진행중이고, C#빌더 이후로 주욱 그렇지만 MS의 지원을 받고 있습니다.

볼랜드의 델파이 개발팀은 닷넷 개발팀, 그리고 비주얼스튜디오 개발팀 양쪽과 직접적인 협력선이 구축되어 있죠. 비공식적인 정보이긴 하지만, 이미 닷넷 2.0과 롱혼 버전까지 초기 작업이 진행중입니다.

설령 MS의 닷넷 계획이 완전히 실패로 돌아가고 MS가 닷넷과는 완전히 다른 새로운 플랫폼을 차기 대안으로 내놓는다고 하더라도, 그렇게 되어서 C#이 완전히 사장되어버리는 상황이 되더라도(MS가 비주얼 J++을 단칼에 날려버렸떤 것처럼)

델파이는 C++과 함께 살아남을 것입니다. 자바와는 달리 닷넷과 C#은 MS가 정책적으로 띄워온 기술들이기 때문에 MS가 필요하다고 판단하면 하루 아침에도 날려버릴 수 있습니다. MS는 이미 전처인 Win32 환경을 단칼에 날려버리고 닷넷에 올인하고 있지 않습니까. 아직도 Win32가 압도적으로 더 많이 쓰이는데도요. 지금도 닷넷의 확산이 MS의 당초 계획보다 많이 지연되고 있는 것 같지만, 만약 지금보다 더 지연되고, 닷넷보다 나은 다른 대안이 MS 내부에서 나온다면 닷넷도 Win32처럼 헌신짝이 될 겁니다. 제대로 보급도 안된 상태에서 지원이 끊기면 닷넷은 역사의 유물로만 남겠죠.

이쯤 되면, 오히려 델파이가 장기적으로 더 안정적이지 않습니까?

볼랜드는 아키텍처가 부족한가

그럼 아키텍처라는 측면에서 글을 써보지요.

먼저 MS의 아키텍처라고 소개하신 ASP, MTS, ADO를 생각해보면요.

위에서도 썼지만, 최근 2~3년을 보면 볼랜드는 거의 MS와 보조를 맞추고 있습니다. 현재 사용가능한 델파이의 최신 버전인 델파이 2005의 경우 MS의 아키텍처를 100% 다 지원합니다. 그리고 비보도 사항이긴 합니다만 내년에 출시될 델파이2007에서는 닷넷 2.0을 지원하고요. 2007년에 출시될 델파이2008에서는 롱혼을 전면 지원합니다. 닷넷 컴팩트 프레임워크(CF)는 올해 출시될 델파이2006부터 지원하기 시작합니다만 이것은 며칠 전에 제가 소개한 글에서 보다시피 볼랜드의 탓이라기 보다는 MS의 내부의 문제입니다.

그러면 지금은 이렇게 MS와 보조를 잘 맞추고 있는 볼랜드가 90년대에는 왜 그랬을까요?
윈도우 개발툴인 델파이와 C++빌더에서 MS의 아키텍처가 중요하지 않다고 생각하진 않았겠죠?
정말 희한한 우연의 일치인데... 이 단절된 두 시기, 그러니까 90년대와 2000년대 사이에는 중요한 사건이 있었습니다.

그것은 90년대 중반 이후 MS가 계속 볼랜드의 핵심 개발자들 여러명을 빼간 사실을 두고 소송중이던 볼랜드와 MS가 소송 중단에 합의했고, 연이어 MS가 볼랜드 주식 10%를 사들인 사실입니다.

이와 관련해서는, 몇년 전에 delphi.about.com의 운영자인 자코 개지크씨는 음모론을 제기하기도 했습니다.

http://www.borlandforum.com/impboard/impboard.dll?action=read&db=news&no=168

MS가 당시 볼랜드의 델파이 엔지니어였던 앤더스 헤즐스버그를 빼갈 당시, 헤즐스버그가 자바용 델파이를 개발하고 있었다는 점은 이런 음모론에 더욱 힘을 실어주는 사실입니다. 자바 플랫폼에서 메인 언어인 자바 언어가 아닌 델파이로 개발한다는 아이디어는 그대로 닷넷으로 연결되지 않습니까.

닷넷이 최초에 어디서 시작되었든 관계없이, 지금 MS가 볼랜드를 지원해주고 있는 것과는 반대로, 90년대말에 소송 타결 이전까지 MS가 볼랜드에게 기술 관련으로 협조를 해주지 않고 도리어 훼방을 놓았을 가능성은? 충분히 있을 뿐만 아니라 그럴 가능성이 높습니다. MS 개발툴은 볼랜드처럼 매년 업데이트하는 것이 아니라 3~4년마다 업데이트를 하는데, 그런데도 매번 MS의 신기술들은 자사의 개발툴에 가장 먼저 적용되었습니다. 왜 그렇습니까? 뻔한 겁니다. 플랫폼인 OS에서 신기술을 적용함과 동시에 새 버전의 개발툴을 출시했기 때문입니다. MS로서는 그게 당연한 것이, 개발툴이 아니라 플랫폼이 메인
이므로 플랫폼 기술의 소개가 주연이고 개발툴은 그 기술의 확산을 위한 목적으로 조연으로 나왔을 뿐이니까요.

볼랜드로서는 그런 기술이 개발중인지도 모르는 상태에서 새 기술이 비주얼스튜디오를 통해 공개되니 늦을 수밖에 없습니다. MS에서는 플랫폼 업데이트가 없을 때는 개발툴도 업데이트되지 않습니다.

그러면, 이정도로 얘기했으면, 이유야 어쨌든 볼랜드가 '아키텍처 지원'에 있어 항상 느렸다는 말은 사실이 되는 걸까요?

아키텍처라는 것이 MS의 기술만을 말하는 거라고 한정하면 그럴 수도 있겠습니다. 그런데 개발툴의 입장에서 아키텍처가 MS의 기술, 그것도 플랫폼 관련 기술만 아키텍처로 봐야 할까요.

개발툴에 있어 아키텍처는 플랫폼 아키텍처만 있는 것이 아닙니다. 개발언어 측면의 아키텍처도 있고 개발툴 IDE 측면의 아키텍처, 그리고 프레임워크의 아키텍처도 있습니다. 또 개발 방법론상의 아키텍처도 있습니다.

먼저 언어면을 봅시다. 비주얼C++ 6.0이 표준을 제대로 지원하지 못해서 STL 지원이 제대로 안되는 것을 무엇으로 변명할 수 있습니까. STL은 C++만을 위해서 만들어진 C++ 표준의 일부인데 시장 점유율 1위인 비주얼C++이 이 표준을 제대로 지원하지 못해서 개발자들을 고생시킨다는 것은 정말 우습기 짝이 없지 않습니까.

그리고 개발 IDE 측면의 아키텍처. MS는 IDE 관련의 여러가지 기술면에서 볼랜드로부터 꽤 오랫동안 소송에 시달리다가 90년대 말의 개발자 빼가기 소송의 합의에서 일괄 타결을 보면서 겨우 벗어났습니다. 당연한 것이, 요즘은 우리가 별 생각없이 쓰는 통합개발환경, 즉 IDE 자체가 80년대 후반에 볼랜드가 처음 창안해서 대히트를 쳤던 것이고, 그 외에도 볼랜드는 MS가 개발툴에 그다지 신경을 쓰지 않던 상당 시간동안 개발툴 관련 특허들을 많이 보유하고 있었습니다.

다음으로 프레임워크 측면. 닷넷 프레임워크가 기존의 비주얼베이직 런타임이나 MFC와는 유사점이 적고 오히려 델파이의 VCL과 대단히 유사하다는 것은 무엇으로 설명하겠습니까. MFC보다 VCL이 더 뛰어나다는 백마디의 말보다 이 사실이 역설적으로 증명하는 것입니다. 물론 델파이의 핵심 개발자였던 앤더스 헤즐스버그가 총 지휘를 맡았기 때문이라는 변명도 가능하긴 하지만 MS가 단지 총책임자가 선호하는 구조라고 해서 개인의 선호도에 따라 만들었다고 생각되지는 않죠.

또 한가지, 델파이는 과거의 구조를 그대로 가지고 예전의 프로그래밍 방법을 계속 지원하면서도 닷넷 등 새 아키텍처를 별 충돌없이 추가적으로 지원하고 있습니다. MS의 경우 개발툴 역사가 따로 있다고 보기보다는 플랫폼이 변함에 따라 개발툴 따위는 마구 뜯어고쳐진... 플랫폼의 역사만이 있을 뿐입니다. 그럼, 어느 개발툴이 우수합니까. 매번 플랫폼이 바뀔 때마다 개발자에게 그동안 배웠던 것은 다 무시하고 새로 공부할 것을 강요하는 개발툴, 기존의 소스는 '당연히' 호환되지 않으니 처음부터 새로 개발하는 것이 정상이라고 쇄뇌시키는 개발툴이 우수한 개발툴입니까.

원문을 쓰신 분이 전혀 생각하지 못했던 중요한 아키텍처, 모델링에 있어서는 볼랜드의 우위를 말할 필요도 없습니다. MS는 모델링 툴이라고 부를 만한 것이 아예 없고, 루머로는 자체적으로 개발중일 것이다, 라는 말도 있기는 합니다만 볼랜드의 투게더를 따라가려면 몇년이나 걸릴까요. 투게더는 모델링 부문에서 래셔널보다 한참 후발주자임에도 모델링의 원조인 래셔널 로즈의 점유율을 턱밑까지 위협하고 있는 상태입니다. 모델링이야 말로 개발에 있어 정말 중요한 아키텍처 중 하나이고, 당장도 대단한 영향력을 가지고 있습니다만 앞으로 끝도 보이지 않을 정도의 잠재력을 가지고 있습니다.

모델링 외에도 개발 방법론 면에서 볼랜드의 우위는 일방적입니다. ALM, SDO 등은 조금도 과장없이 개발 방법상의 미래로 여겨지고 있지만, 이런 부분에서 MS는 거의 아무것도 제공해주지 못하고 있습니다. MS는 닷넷 개발을 위한 개발툴만을 가지고 있을 뿐이지만, 볼랜드는 닷넷 개발을 위한 토탈 솔루션, 시작부터 끝까지의 모든 솔루션을 제공합니다. 이것이 애플리케이션 라이프사이클 관리, ALM입니다.

이런 예 외에도 많습니다. 웹서비스. 델파이와 C++빌더는 웹 서비스의 개념이 등장한 이후로 최초로 웹서비스 지원 기능을 내놓은 개발툴들입니다. 리눅스. 처음으로 리눅스에서 RAD 개발을 지원하는 개발툴 카일릭스도 볼랜드 제품입니다. 코바. 볼랜드의 ORB 비지브로커는 코바 시장에서 절대적인 점유율을 가지고 있습니다. 자바. J빌더는 최초의 자바 IDE 개발툴이며 지금까지 상용 자바 개발툴 중 가장 높은 시장점유율을 가지고 있으며, 심지어 자바의 리눅스 버전의 경우 볼랜드에서 만들어서 썬에 주기도 했습니다.

90년대 말 소송이 마무리되기 전까지 MS 아키텍처의 수용이 늦었을 뿐, 그 외의 모든 소프트웨어 아키텍처에 있어 볼랜드는 가장 빠른 선두 그룹에 속했습니다. 그리고 MS 아키텍처가 늦게 채용되는 문제는 2000년대 들어서는 완전히 사라졌습니다.

닷넷 CF의 경우처럼 MS 개발팀간의 협조 미비로 늦게 수용되는 경우도 있기는 합니다만 최근 수년간의 진행 상황과 볼랜드의 로드맵을 볼 때 MS와 볼랜드의 기술 수용 시차는 1년 이내로 좁혀졌습니다. 예를 들어 롱혼 버전의 비주얼스튜디오 닷넷은 내년에 발표될 예정이지만 롱혼 자체가 내후년인 2007년에 발표될 예정이기 때문에 역시 2007에 발표될 예정인 델파이 2008은 롱혼에 있어 전혀 뒤쳐지지 않습니다.

만약, 아키텍처의 부재를 '자신의 아키텍처'라는 부분으로 한정해서 본다면...

그 말이 의미가 있으려면 문맥으로 볼 때 여기서 말한 자신의 아키텍처는 플랫폼 아키텍처라는 말인데요. 플랫폼 팔아먹으려는 회사가 플랫폼 기술을 만들지 개발툴 회사가 플랫폼 기술을 만들기를 기대라도 한다는 뜻인지...? 뭐, 어처구니가 없네요.

닷넷과 자바

반박의 여지가 없는 것은 아니지만 설령 몇번 양보해서 닷넷이 자바를 능가하는 아키텍처를 가지고 있다고 가정해도, 그건 당연할 수밖에 없습니다. 자바보다 6년이나 늦게 나왔으며 그 태생 자체가 자바 시장을 노리고 설계된 닷넷 환경이 자바보다 못하다면 MS의 개발자들이 아주 바보들이던가 아주 태만하던가 둘중의 하나겠지요. 그리고 더 웃기는 사실은, 닷넷이 자바보다 더 뛰어나다고 아무리 주장해도 적어도 기업 시장은 이미 자바의 독점 시장이 되어버렸다는 것입니다.

이 현실을 닷넷이 어느정도라도 극복하려면 앞으로 적어도 3~4년은 더 걸릴 텐데, 아키텍처가 앞선다는 것만으로 버티기엔 닷넷 개발자들이 안쓰럽네요. 원문을 쓰신 분은 마치 볼랜드가 과거에 가졌던 높은 점유율이 마치 MS쪽으로 넘어간 것처럼 썼는데, 그 점유율의 대부분은 MS가 아니라 오히려 자바, 그리고 리눅스(php와 아파치를 포함해서)로 넘어갔다는 겁니다. CS 시장이 줄어들 면서 피해를 입은 것은 것은 MS가 볼랜드보다 더하면 더했지 덜하진 않을 겁니다. '분산 웹 프로그래밍'을 거론하면서
마치 MS가 그 '분산 웹 프로그래밍' 시장을 먹고 있는 것처럼 썼는데, asp로 '분산 웹 프로그래밍'을 한다는 말은 듣도 보도 못했습니다. 해보신 분들은 다 아시겠지만 asp는 모양만 달라졌을 뿐이지 프로그래밍 방식은 예전의 CS 방식과 다를 것이 없습니다. MTS/COM+ 객체를 쓰면 ASP에서도 그나마 분산 개발의 모양새라도 나오긴 합니다만...

MS 개발툴을 사용하는 분들은 MTS가 대단한 분산 아키텍처인 줄 알고 있는 분이 있는 거 같은데, 정작 분산 프로그래밍이 핵심적으로 쓰이는 프로젝트에는 MTS, COM+ 안씁니다. MS 기술밖에 모르는 개발자들이 소규모 사이트에서 구색 맞추기로 쓰는 정도입니다. 실제로 어느 정도 규모 이상의 기업에서 핵심적인 업무에서의 분산 아키텍처로 쓰이는 것은 TP모니터, 자바 미들웨어(WAS), 코바 ORB입니다. MS가 닷넷으로 이 분산 프로그래밍을 강조하는 것은 그동안 기업 시장의 핵심인 이런 분산 아키텍처 시장에서 MS가 죽을 쒀왔기 때문입니다. MS가 닷넷의 핵심 레퍼런스로 자주 거론하는 우리은행의
경우, 핵심업무인 기간 부문에는 유닉스 기반의 아키텍처들을 그대로 씁니다.

그러니까 MS 개발툴을 사용하는 개발자가 볼랜드와의 비교우위로 분산 아키텍처를 거론하는 자체가 웃기는 겁니다. MS쪽 개발자들이 아무리 자바 개발자들을 비웃어도, 당장 밥벌이에는 자바 개발자들이 훨 형편이 낫고 또 적어도 앞으로 3~4년 동안은 이런 압도적인 우세가 바뀌지 않을 거란 것이 중요합니다. 그리고 3~4년이 지난다고 해서 닷넷이 지금 자바가 절대적으로 점유하고 있는 기업 시장을 반 정도라도 탈환한다는 보장도 없습니다. MS가 기존의 비주얼베이직과 비주얼C++ 개발자들을 닷넷으로 아무리 끌어당기려고 애를 써도 MS 맘처럼 잘 안되는 것처럼, 개발자들은 당장 문제가 없는 한 다른 아키텍처로 잘 안움직입니다. 3~4년 이후라고 해서 자바 개발자들이 "우와~ 알고보니 닷넷이 훨 낫네!!!"하면서 감동하는 얼굴로 너도나도 닷넷으로 옮겨탈 거라고 생각한다면...

그야말로 한편의 판타지 소설입니다.

대세가 MS인가?

비록 제가 지금 MS의 ASP 기반으로 된 기업의 인프라를 델파이 기반으로 다 뜯어고치고 있지만, 분명히 대세는 네이티브 개발툴에서 웹으로 넘어간 것은 사실입니다. 하지만 대세라는 말이 전부라는 의미는 절대 아닙니다. 아직도 웹으로는 손을 댈 수 없는 분야가 적지 않습니다. 실시간으로 주가를 조회하는 증권사의 HTS 프로그램을 웹으로 짜겠습니까. 혹은 전화 CTS 모듈이 연동되어야 하는 콜센터 솔루션을 웹으로 짜겠습니까. 교통망 관련 기기들과 연동해야 하는 ITS 솔루션에서 웹을 쓰겠습니까. 재미있게도, 이런 전통적인 네이티브 개발툴의 분야들에서는, 델파이와 C++빌더 등 볼랜드의 점유율이
과거의 CS 전성기보다 오히려 더 높습니다. 왜? MS는 Win32 지원을 안해주니까요.

그런데, 웹이 대세라고 것이 사실이더라도, 그렇다고 해서 그 대세를 MS가 가져갔습니까? ASP와 PHP는 소규모 웹 개발에서 서로 경쟁 상대인데, 정확한 수치는 아니겠지만 랭키에서 ASP 개발 사이트보다 PHP 개발 사이트가 훨씬 점유율이 높은 것처럼, ASP 개발자보다 PHP 개발자가 더 많습니다. 그리고 그 이상의 대규모 개발 프로젝트에서는 ASP가 아니라 JSP와 자바를 씁니다. 어딜 봐서 ASP가 대세입니까. 아시다시피 ASP 닷넷 기반 레퍼런스는 손에 꼽을 정도로 적습니다.

ASP 개발자들이 ASP 닷넷을 배울 필요를 못느끼고 있기 때문입니다. 이런 현상은 MS쪽의 CS툴 개발자들이 더 심합니다. 기존에 비주얼스튜디오 6.0 기반으로 개발되었던 프로젝트들, 지금 순조롭게 비주얼스튜디오 닷넷 기반으로 넘어가고 있을 거 같습니까. 택도 없습니다. 그나마 ASP에서는 서버쪽에만
닷넷 프레임워크를 깔면 되기 때문에 몇개라도 레퍼런스가 나오지만, CS 프로그램에서 클라이언트인 데스크탑마다

닷넷을 까는 것은 아직 너무나 머나먼 이야기입니다. MS쪽 개발자들 스스로조차 데스크탑 버전의 롱혼이 나와야 닷넷 클라이언트를 일반적으로 쓰는 것이 가능해질 거라고 말합니다. 이것도 아주 해피(?)한 경우를 가정한 건데...

과연 롱혼이 나오면 클라이언트에 닷넷을 안심하고 쓸 수 있게 될까요. 얼마전에 보도된 것처럼 출시된지 4년이 다되어가는 윈도우XP가 아직도 데스크탑 윈도우 시장에서 점유율이 절반도 안됩니다. 롱혼이 절반의 점유율을 가지는 데는 얼마나 걸릴까요. 4년보다 더 걸릴 가능성이 높습니다. 데스크탑 윈도우 시장은 가정용보다는 기업용 업무 PC 시장이 주류인데, 기업에서는 롱혼의 번지르르한 기능 대부분이 필요가 없을 뿐더러 지금의 XP에도 충분히 만족하고 있습니다.

윈도우98 이후로 윈도우 업그레이드는 점점 더 더뎌지고 있고, 윈도우98이나 ME에 비해 안정성이 훨씬 만족스러운 윈도우XP에서 롱혼으로 넘어가기를 기다린다는 것은... 하세월이겠죠.

이렇듯... MS의 닷넷 시장은 아직 초기임에도 자연스럽게 클 수 있는 것보다 너무 과도하게 마케팅을 하는 바람에 닷넷 시장 전체가 모순으로 가득차있습니다. 지금 현업에서 쓸 개발툴을 구입해야 하는 기업들은 어떻게 하고 있을까요.

대부분의 기업들이 당장 쓰지도 않는 비주얼스튜디오 닷넷을 과연 덥썩 구입할까요?

볼랜드는 어디 있나

그럼 볼랜드는 어떤가요.

델파이2005부터 Win32와 닷넷을 동시에 지원하기 시작한 것은 탁월한 선택입니다. 델파이2005로 win32 개발을 계속하면서도 닷넷이 일반화되는 시점이 오면 그 소스를 그대로 닷넷으로 옮길 수 있습니다.

비주얼스튜디오 닷넷도 이렇게 할 수 있습니까. Win32 개발은 아예 불가능하며, Win32 버전의 비주얼스튜디오를 따로 구입할 수조차 없습니다. 올해 내로 출시될 델파이2006에서 C++빌더와 델파이를 통합하기로 한 것도 늦기는 했습니다만 역시 탁월한 선택입니다.

MS의 비주얼스튜디오가 가지고 있었던 '스튜디오'로서의 비교 우위는 올해 안으로 없어집니다. 또 그동안 C++빌더 프로젝트 내에서 델파이 유닛을 사용할 수는 있었지만 고의적으로 제한했던 부분도 당연히 풀릴 것으로 예상됩니다.

비주얼스튜디오닷넷에서는 비주얼C++과 비주얼베이직으로 단일 프로젝트로 만들 수 있습니까. 델파이에서는 가능해집니다. 단순히 IDE 하나에 두 언어를 얹는 정도의 수준이 아니라, C++과 델파이 두 언어가 소스 파일 단위로 융합되는 것입니다.

아직 국내 발표는 안되었지만 며칠전 투게더의 신 버전이 발표되었습니다. 대대적으로 기능이 개선된 버전이라고 하는군요.

그리고 어떤 형식으로 패키징될지는 아직 모르지만 올해 출시될 델파이2006과 투게더는 완벽하게 통합되게 됩니다.

UML 모델과 델파이 코드가 실시간으로 전환되는 것입니다. 앞으로 델파이 개발에 있어 혁신적인 변화가 있다고 하면, 그중 가장 큰 변화중 하나는 업무 개발에 있어 델파이와 투게더를 함께 사용함으로써 모델 기반 개발이 일반화될 수 있다는 것입니다.

좀 칭찬을 하고 싶을 정도로, 볼랜드가 이제야 정신을 좀 차리는구나 싶습니다.
델파이2005를 설치하는데 아무 관계도 없는 비주얼J#까지 같이 깔아주는 것처럼 볼랜드가 MS에 과하게 협력해주는 게 아닌가 싶은 점이 좀 불만스럽기도 합니다만, 지적된 것과 같이 MS 아키텍처를 빨리 수용할 수 있느냐 하는 문제와 직결되는 것이므로 이해가 되고요. 또 그렇다고 해서 볼랜드가 자바나 리눅스는 완전히 버리고 MS 플랫폼에만 올인하는 것이 아닌 이상 개발툴 전문업체로서의 자존심과 위상은 그대로라고 생각합니다.

사실 업무 개발에 델파이2005를 사용하고 있는 입장에서 불만스러운 점이 전혀 없는 것은 아닙니다만...
예를 들어 최근에 거의 패치가 다 되긴 했습니다만 출시 초기에 개발툴 자체의 안정성에서 좀 문제가 있었죠. 하지만 델파이2005는 개발툴의 진보라는 면에서 델파이의 역사에서 터보 파스칼의 첫 출시와 델파이의 출시에 이어 세번째로 큰 진전을 이룬 것은 틀림없는 사실입니다. 하나의 개발툴에서 현재의 플랫폼인 Win32와 미래의 플랫폼인 닷넷, 두개의 플랫폼을 동시에 지원하는 것은 초유의 일인데다가, C++빌더가 통합되는 2006 버전 이전에도 이미 C#빌더를 통합하여 통합 스튜디오 형식의 개발툴로 만들어낸 것도 볼랜드로서는 처음이니까요.

이만하면 델파이의 앞날을 생각하면서 불안해할 이유는 전혀 없지 않을까요? ^^

이기영 님이 쓰신 글 :

: 저는 델파이를 참 좋아하고, 볼랜드 툴에 대해 애정을 갖고 있습니다. 물론 저는 하드웨어 제어쪽에 가까운 사람이고, 따라서 실력이 그다지 좋진 못하지만... 왠만한 프로그램 작성은 델파이나 빌더로 하곤 합니다.^^;
:
: 그러나 그런 저에게 사람들이 모두들 델파이는 곧 사장될 랭귀지라고 합니다. 물론 그 말을 하는 분들이 데브피아나 다른 여러곳의 VC 사용자들이기에 귀기울이지 않지만, 그중 어떤 한 분의 말씀은 충분히 저에게 공감을 이끌어 내더군요.
:
: ----- 글중 일부입니다 ----
: 볼랜드의 문제는 자신의 아키텍처가 하나도 없다는 것입니다. 물론 마이다스라는 것도
: 내 놓고 Object Broker와 미들웨어 회사를 인수하면서 시도를 했지만 MS 진영의 아키텍
: 처를 너무 무시하고 있었습니다. ASP, MTS, ADO 등등의 기술도 2년 이상 뒤 늦게 지원했
: 죠.
:
: 단순한 클라이언트/서버 환경에서는 볼랜드의 개발툴은 최고가 될 수 있습니다. 그렇지
: 만 분산 웹 환경에서는 볼랜드의 개발툴은 전혀 고려 대상이 되지 않습니다. 그렇기 때
: 문에 20% 이상 이던 볼랜드 개발자가 이제는 4%에 불과한 것입니다.
:
: MS의 개발툴의 강점은 풍부한 도움말과 지원이 아니라 아키텍처에 있습니다. 자바 개발
: 자들이 MS의 아키텍처에 대하여 아직도 비웃고 있지만, 그것은 3,4년 전 지식을 가지고
: 있는 사람들의 생각입니다. 이제는 J2EE를 능가하는 아키텍처를 가지고 있습니다.
: -----------------------
:
: 저분이 2000년에 2년후엔 델파이가 사라질것이라 하셨고, 2003년엔 2년만 더 기다려 보라고 하셨지만 이젠 2005년입니다. 어느덧 시간은 흘렀고 델파이는 시대의 흐름을 따라 더욱 발전했지요. 따라서 사장된다는 말은 믿지 않으려 합니다.
: 다만 '볼랜드사의 아키텍쳐 부재'에 대한것은 이곳 포럼 분들께 말씀을 듣고 싶습니다.
:
:  저는 엄밀히 말해서 프로그래머라기 보다는 땜장이 이기 때문에, 아키텍쳐라는, 제가 짐작키 어려운 그런 일에 대해 걱정을 하진 않습니다만 프로그래머 길을 선택한 아들 녀석이(델파이는 저에게 배웠지요^^) 취직할때 제가 권해준 길이 잘못되진 않았을지 걱정되어 이렇게 글을 쓰게 되네요. (물론 진정한 프로그래머 라면, 도구와는 상관없이 프로그래밍이 가능해야 된다고 생각하지만, 주력이 무엇이 되느냐는 중요한 문제인것 같습니다.)
:
:
: P.S 게시판의 성격에 맞지 않는다던가, 문제가 있다면 삭제해주셔도 됩니다.