제가 정신없이 바빠서 게시판에 많이 관심을 가지지 못한 사이에..
자유게시판에 델파이와 C++빌더의 앞날에 대한 글들이 많이 올라왔었군요.
저도 한 마디 써보지요. 이번에도 변함없이 두서없는 잡생각입니다.

먼저.. 현실이 어떤지를 살펴보겠습니다. 물론 제 관점에서 바라본 것입니다.

2~3년, 혹은 4~5년 전과 비교했을 때 델파이와 C++빌더 모두 사용자나 채택한 회사는 명백히 늘어나고
있습니다. C++빌더 개발자들이 많이 모이는 볼랜드포럼은 물론이고, 델파이 관련 사이트 중 가장
사용자가 많이 모이고 있는 델마당의 경우에도 최근 사용자수가 늘어서 웹서버가 버벅일 정도입니다.

물론 1년 정도 전을 비교해서 단기적으로 바라본다면 좀 줄었을 수도 있고 하겠지만, 장기적인
관점에서는 분명히 늘어나고 있습니다.
그런데 왜 자꾸 C++빌더나 델파이 개발자들이 줄어들고 있는 것 같은 느낌이 드느냐..
그것은 "밀도"의 문제가 대부분이라고 봅니다.

3~4년, 혹은 5~6년 전과 비교했을 때 우리나라의 IT 산업, 특히 소프트웨어 업계는 적어도 규모
면에서는 엄청나게 성장했습니다. 업계의 전체 매출이나 업체 수, 개발자 수, 프로젝트 수 등등
어떤 기준으로 본다고 해도 굳이 수치를 볼 필요가 없지요.

그런데 이렇게 엄청난 소프트웨어 업계의 성장 규모의 많은 부분을 자바, 그리고 마이크로소프트
진영이 차지한 것입니다. 개발자 숫자 면을 보면 지난 수년간 자바 혹은 MS 관련 교육과정에서
수없이 양산해낸 초급 개발자들의 숫자를 떠올려보면 되겠습니다.

자바 혹은 MS 계열 개발자들의 양적 팽창이 워낙 폭발적이다보니, 델파이 혹은 C++빌더 개발자들은
계속 늘어나고 있는데도 불구하고 오히려 줄어들고 있는 것처럼 왜곡되어 느껴지는 겁니다.

이런 느낌은, 기업 입장에서 개발자를 구인할 때나 개발자 입장에서 구직할 때 더욱 과장되어
느껴지게 되는데요. 예를 들어 델파이 개발자를 구하는 기업의 입장일 경우, 4~5년 전보다 델파이
개발자의 숫자는 100% 정도가 늘었다고 한다면, 전체 개발자 숫자는 1000% 정도 성장해버린 겁니다.

그러니 구인하는 쪽이나 구직하는 쪽이나 양쪽 모두 델파이 개발자가 줄었다고 느껴지게 됩니다.
당장 구직 사이트에 가서 두어 페이지 정도를 보더라도 자바, MS 계열 개발자들만 드글거리는 듯한
느낌을 받게 되지요.


또 한편으로는, 이런 소외감의 느낌이 느껴지는 것도 업종에 따라 다르다고 봅니다.
소프트웨어 업계는 본질적으로 솔루션 업계와 엔터프라이즈 프로젝트 업계로 나뉘어집니다.
약간 옆길로 새서 설명을 해보겠습니다.

솔루션이라면 우리가 흔히 패키지라고 부르는 겁니다.
OS 패키지, DB 패키지, 게임, 오피스 소프트웨어, WAS, 미들웨어, 각종 유틸리티 등등이지요.
이런 것들을 패키지라고 부르는 이유부터가, 개별 고객에 따라 소프트웨어를 맞추는 커스터마이징이
전혀 없거나 아주 적기 때문입니다.

엔터프라이즈 프로젝트 업계는 우리가 과거에 흔히 SI라고 불렀던 것들입니다.
SI, ERP, CRM, SCM, 그룹웨어 구축 등등입니다. 이 업계에서는 솔루션을 사용하기는 하지만 외부의
제품을 사와서 커스터마이즈, 혹은 비즈니스 로직 모듈 개발로 밥을 먹는 업계입니다.
간혹 자체 솔루션을 만들어서 구축한다고 주장하는 업체들도 있지만 까놓고 보면 그 수준은 실제
우리가 솔루션이라고 부르는 수준에 한참 미달하는 경우가 대부분입니다.

최근 3~4년 사이에 취업을 목적으로 대량생산된 초급 개발자들을 예외라고 본다면, 개발자를
꿈꾸는 사람들의 꿈은 거의 대부분이 솔루션 개발자이거나 적어도 시작할 때는 그랬습니다.

'나는 국가 정보망이나 대기업의 사내 전산망 통합 프로젝트에 참여하는 개발자가 되고 싶어!'
라고 꿈꾸고 개발을 공부하기 시작한 개발자는 거의 없다는 겁니다.
제가 처음 프로그래밍을 시작할 때의 꿈이 PC tools였던 것처럼, 90년대 후반에는 오피스같은 SW를,
그리고 요즘은 게임 개발자를 꿈꾸는 사람이 많다지요.

혹자는, 극단적으로 엔터프라이즈 프로젝트는 개발이 아니다! 라고 주장하는 분도 있을 정도입니다.
물론 그쪽 업계에 속해있는 수많은 개발자들은 대단히 기분이 나쁘실 일입니다만.
하지만 이런 관점에 대해서도 분명히 짚어볼 필요는 있습니다.

여러분의 바로 주위에 있는 안면있는 개발자들을 제외하고, 여러분이 지향하는, 혹은 존경하는
유명한 개발자의 리스트에 엔터프라이즈 프로젝트 개발자가 있습니까.
제 집사람은 자바 기반의 엔터프라이즈 프로젝트 회사에 다니는데, 어제 퇴근해서 제게 얘기하기를,
회사에서 월 1천만원 이상을 요구하는 엔터프라이즈 개발자를 스카웃한다고 합니다.
하지만 집사람도 저도 그 사람을 전혀 존경하지도 대단하다고 생각하지도 않습니다.

여기서 반드시 짚어볼 것은... 자바와 MS 방식을 극단적으로 선호하는 쪽은 거의 엔터프라이즈
프로젝트 쪽이라는 것입니다. 물론 솔루션 업계 쪽에서도 자바 혹은 MS 쪽을 선호하는 기업이 아주
많지만, 이쪽 업계는 생산성과 효율, 성능과 같은 개발툴의 장점들을 잘 설명하면 수용하는 경우가
많습니다.

게다가, 국내 SW 업계의 폐단, 잘못된 점이라고 지적되는 점들은 90% 이상이 엔터프라이즈 업계에서
일어납니다. 3차, 4차에 이르는 지나친 하청으로 인해 프로젝트의 저가 수주, 질적 저하, 개발자 혹사,
수년 이상의 경력 개발자가 차후 진로를 찾지 못하고 영업직으로 넘어갈 수밖에 없는 문제 등등..

자바와 닷넷은 명백하게 엔터프라이즈 시장이 제1의 타겟입니다. 물론 양쪽 모두 모바일을 내세우기도
하고 뭐 별의 별 희한한 것도 다 통합하겠다고 하지만, 현재에 있어서 실제 시장은 엔터프라이즈쪽이
거의 100%에 가깝고 앞으로도 계속 전체 시장규모의 대부분을 엔터프라이즈쪽이 차지할 것은 뻔합니다.

결과적으로, 요즘 IT 업계를 술렁이게 하고 있는 자바와 닷넷의 전쟁은 거의 100% 엔터프라이즈
업계의 내부 분란이라고 할 수 있습니다. 솔루션 업계의 개발자에게는, 딴나라 이야기 정도라고
보면 될 겁니다.

예를 들어서, 닷넷이 완전히 정착하고 나면 MS가 윈도우 닷넷 서버(닷넷이름을 안쓰고 2003이라고
하기로 했다지요)의 내부를 C#으로 몽땅 포팅할까요? 뭐, 하드웨어 성능이 지금보다도 훨씬 더
발전하는 상당한 시간이 흐른 후가 되면 그런 일도 있을지 모르겠지만, 적어도 앞으로 수년간은
MS조차도 솔루션을 C#으로 만들지는 않을 것은 뻔합니다. 오피스를 닷넷과 C#으로 포팅해서 업그레이드
한다고 생각해보세요. 누구도 기존 버전에서 업그레이드하지 않을 겁니다.

작년에 마소 몇월호인가에 보니깐 메일 서버를 C#으로 만들어보겠다고 하는 연재기사가 있던데,
메일 서버가 얼마나 성능과 안정성이 중요한지를 아는 개발자라면 그것이 단순히 그럴 수도 있다는
예제일 뿐 전혀 현실성이 없는 미친 짓이라는 것을 아실 겁니다.

또 마찬가지로 자바로 메일서버나 웹서버를 만들지도 않습니다. 썬조차도요.
넷스케이프에서 수년전에 2년에 걸쳐 네비게이터를 퓨어 자바로 포팅하고는 결국 출시하지 않고
포기해버린 적도 있습니다. C#이나 자바로 게임 만든다는 얘기 들어보셨습니까.
물론 보드게임이나 포트리스 수준의 단순한 게임은 가능하고 실제로도 만들어지고 있지만, 그 이상
수준의 게임을 만든다는 것은 역시 미친짓입니다.

자바나 닷넷은 본질적으로 하드웨어 성능을 기본적으로 상당히 잡아먹고 들어가고, 추가로
충분한 여유 리소스가 투입되어야 봐줄만한 성능이 나옵니다. 그래서 현재에도 엔터프라이즈쪽에만
적용되고 있는 겁니다. 그래서 엔터프라이즈 업계에서는 원하는 성능이 안나오면 소프트웨어를
개선하는 쪽보다는 하드웨어 서버를 증설하는 등으로 풀어가려고 하는 것이 보통입니다.


물론 이런 면도 있습니다. 국내의 솔루션 업계는 엔터프라이즈 업계에 비해 대체로 규모가 작고
숫자도 적은 편입니다. 그래서 솔루션 업계로만 찾아다니려고 한다면 취업의 문은 꽤 좁아지게 되는
면도 있습니다.

하지만  이런 면도 생각해보십시오.
반드시 그런 것은 아니지만, 대체로 국내에서 솔루션 업계와 엔터프라이즈 업계는 인력의 이동이
별로 많지 않습니다. 더 구체적으로 말하자면, 두 업계가 서로 다른 한쪽 업계의 인력을 원하지
않는다는 것입니다. ERP 전문 기업이 보안 솔루션 개발자나 게임 개발자를 원하는 일도 없을 테고,
거꾸로 보안 솔루션 업계나 게임 업계에서 ERP 개발자를 찾지도 않습니다.
이렇게 업계 경력을 건너뛰어서 교차지원(?)을 하려고 한다면, 아마 대부분의 경우 기존 경력을
대부분 무시당하고 평사원부터 시작해야 할 겁니다.

하지만 적어도 같은 솔루션 업계나 엔터프라이즈 업계 내에서는 세부적인 경력사항이 달라도
경력을 상당한 정도는 인정해줍니다. ERP 전문 개발자라면 CRM쪽에서도 상당히 인정을 받을 것이고,
솔루션 업계 내에서도 서로 다른 분야에 대해서 상당 부분 인정해줍니다.

이럴 수밖에 없는 것이, 두 업계의 스타일이 여러가지 면에서 많이 다르기 때문입니다.
솔루션 업계에서는 대체로 산출물의 질이 종료일자보다 중요하게 여겨집니다.
창업 단계의 조그만 회사일 때는 형편없는 대우를 받는 경우가 많지만 일단 개발한 솔루션이 성공하면
그에 상당한 대우를 받습니다. 대체로 개발자가 자신의 일처럼 자부심으로 일하는 경우가 많고,
또 단점으로는 방법론이나 설계 같은 것은 종종 무시하거나 가볍게 생각합니다.

반대로 엔터프라이즈 업계에서는 종료일자가 질보다 우선됩니다.
또 회사가 성공해도 개발자가 받는 보수는 고만고만합니다. 대신 회사가 쉽게 망하진 않습니다.
하지만 자부심 면에서는 솔루션 업계보다 떨어지기 쉽구요. 코딩 자체보다는 방법론이나 설계에
치중을 많이 하게 됩니다. 그리고 전반적으로 밥먹고 살기에는 솔루션 업계보다 낫습니다.

그리고 결정적으로, 엔터프라이즈 업계에서는 프로젝트에 참여하는 멤버들간에 동종의 툴을 사용하는
것이 대단히 중요해집니다. 왜냐하면... 기분나쁘게 들리시겠지만, 이 업계에서는 개발자는 현실적으로
소모품에 불과하기 때문에 자의든 타의든 언제든 개발자를 갈아치울 수 있어야 하기 때문입니다.


그래서, 개발자는 반드시 자신의 개발 경력의 초기 단계에서 두 업계 중에서 어느쪽을 진로로 삼을
지를 결정해야 합니다. 만약 엔터프라이즈쪽으로 결정한다면 델파이나 C++빌더는 별로 도움이 되지
않습니다. 델파이나 C++빌더가 가진 여러가지 장점도 반감될 뿐 아니라 업계 자체에서 네임밸류가
높은 쪽을 원할 수밖에 없는 구조가 있습니다.

그러니 엔터프라이즈쪽을 일시적인 밥벌이가 아닌 평생의 업으로 삼을 생각이라면, 자바나 닷넷을
선택하세요. 분명히 후회없는 선택이 될 겁니다. 그리고 자바와 닷넷을 이을 새로운 브랜드 기술이
나오면 남들 따라서 그것도 열심히 공부하세요. 플랫폼과 솔루션에 절대적으로 종속되게 되는 현실은
엔터프라이즈 개발자들의 어쩔 수 없는 숙명입니다.

그리고 솔루션 업계를 선택한다면, 델파이나 C++빌더는 아주 멋진 선택입니다.
아시다시피 생산성과 성능을 동시에 극대화시킬 수 있으니까요. 그리고 이쪽 업계는 대체로 마인드가
열려있는 관리자가 상대적으로 많기 때문에 델파이나 C++빌더를 사용하지 않는 업체라고 해도
논리적인 설득이나 실제의 예를 보여줌으로써 설득할 수 있는 여지가 많습니다.
실제로도, 국내에서 C++빌더나 델파이를 사용하는 업체는 상대적으로 솔루션 업계쪽이 많습니다.

물론 예외적으로 고려할 부분도 있습니다. 엔터프라이즈쪽이라고 해도 솔루션 성격이 강할 경우,
즉 반복되는 부분으로서 성능이 많이 고려될 경우에는 델파이와 C++빌더가 훌륭한 대안이 될 수
있습니다. 또 올해 1/4분기 내에 어떤 형태로든 구체화될 것이 확실한 닷넷 버전의 가능성도 무시할
수 없겠지요. 이 볼랜드의 닷넷 버전이 높은 평가를 받게 될 경우 엔터프라이즈쪽에서도 중요한
역할을 하게 될 테니까요.


이번엔 델파이와 C++빌더의 미래에 대해서 생각해보지요.
델파이와 C++빌더를 사용하는 개발자의 수는 업체의 수에 좌우되는 면이 크지만, 거꾸로 업체의 숫자가
개발자의 숫자에 좌우되는 면도 아주 큽니다. 다시 말해서, 지금 델파이나 C++빌더를 사용하고 있는
개발자의 수가 현저히 적어지지 않는 한은 델파이와 C++빌더가 시장에서 사라지는 일은 결코 없을
것이란 겁니다.

물론 벤더인 볼랜드가 지속적으로 업그레이드해야 하는 면도 있지만, 볼랜드가 MS처럼 플랫폼 지향의
전략적인 면으로 개발툴을 다루고 있지는 않는 만큼, 일단 델파이와 C++빌더를 사용하는 개발자가
어느정도 이상의 숫자만 유지하고 또 팔리기만 한다면 델파이와 C++빌더를 계속 업그레이드할 것은 당연합니다.
(정품을 사용합시다! ^^)

또한 볼랜드 스스로도 최소한 2007년까지는 델파이가 시장에서 유효할 것이라고 전망한 바 있습니다.
(C++빌더는 언급할 필요도 없죠? 아무리 자바와 C#을 떠들어대도 아직 C++은 성능면에선 최강의 언어니까요.)
VB닷넷이 2007년까지 유효할까요? 제 생각엔 그렇지 못할 겁니다.


마지막으로, 최악의 경우를 생각해보지요. 볼랜드 입장에서 도저히 수지타산이 안맞아서
델파이나 C++빌더를 더이상 업그레이드하지 않고 단종시킬 경우를 생각해봅시다.
뭐, 도무지 이런 일은 일어날 수가 없을 거 같습니다만.

아시다시피, MS는 자사의 플랫폼 전략에 따라 개발툴을 마구 뜯어고치기로 악명이 높습니다.
이번 VB닷넷 버전의 경우 VB를 좋아하는 많은 개발자들을 경악시켰지요.
그래서 매 버전마다 반드시 새 버전을 다시 공부해야 하고, 그런 만큼 새로운 책이 필요합니다.

장담하건대, 길어도 2~3년 안에 닷넷 구조의 대대적인 보완이 있을 것이고, 또 5~6년 내에 닷넷 구조가
근본적으로 뜯어고쳐져서 더이상 닷넷이라고 부르기도 뭣한 상태가 올 것입니다. 독점 상태에서 MS의
고성장을 계속 유지하려면 플랫폼을 계속 갈아치워야 하기 때문입니다.
그 단계마다 MS 개발자들은 완전히 새로운 개념을 처음부터 다시 공부해야 합니다.

반대로 볼랜드의 개발툴은 최대한 기존의 프로그래밍 인터페이스는 유지시킵니다.
새로운 기술이 추가되거나 기존의 구조보다 더 좋은 구조가 나올 때에도, 델파이와 C++빌더의 기반
프로그래밍 인터페이스는 거의 변함없이 계속 유지되어왔습니다. 개발자가 최대한 버전업 전후에서
고민하지 않도록 노력을 하고 있는 겁니다. 덕분에, 델파이와 C++빌더는 모두 초기버전용으로 나온 책을
지금 보고 공부를 한다고 해도 그다지 무리가 없을 정도의 상태입니다.

거꾸로 말하자면, 설사 볼랜드의 C++빌더나 델파이가 단종되어서 MS 혹은 다른 벤더의 개발툴을 새로
공부해야 하는 상황이 벌어지더라도, 어차피 수년마다 새로 공부해야 하는 MS쪽 개발자보다 그리
손해볼 것은 없다는 말입니다. 그리고 현재 MS의 개발툴이 계속 볼랜드의 개발툴을 모방하고 있는 만큼,
그 마이그레이션조차도 그리 어렵지 않을 겁니다.


결과적으로...
당장 델파이와 C++빌더가 뛰어나고 만족스러운데 미래에 일어날지 어떨지도 모르는 사태를 미리
가정을 해가면서 걱정을 하는 것은 정말 쓸데없는 걱정입니다.
그리고 자바냐 닷넷이냐는 솔루션 업계와는 상당히 동떨어진 논쟁입니다. 피터지게 대판 싸운다고
남들 싸움에 괜히 참견해서 걱정하지 마세요.

또 위에서 말했다시피, 최악의 경우로 델파이와 C++빌더가 시장에서 사라지는 사태가 벌어진다고
하더라도 손해볼 것은 거의 없고, 현재로서는 델파이나 C++빌더가 정말 만족스러우면 그만큼 이익
아닙니까.