집사람이 자바 컨설턴트라서 그쪽 사정은 좀 알죠. (자바쪽에서 컨설턴트라는 타이틀은 그리 대단한 건 아닙니다)
분명히 SI쪽에서는 자바가 압도적인 대세인 것은 분명합니다. 보수도 좀 더 센 편이구요.

하지만 일반 개발자로서는 거기까지가 한계입니다. 같은 웹 계열이라도 php나 asp와는 달리 자바 프로젝트는 중/대규모 프로젝트인데, 여기서는 개발자는 코더일 뿐 대부분은 관리자가 될 수 없습니다. C++이나 델파이 프로젝트에서는 전체 설계와 함께 코딩 테크닉과 개인적인 경험이 많이 필요하지만, 자바 프로젝트에서는 오직 설계만이 핵심입니다. 구체화된 방법론 아래 체계적으로 짜여진 설계에 맞춰서 코딩하다보면 개발자 개인의 색깔이 전혀 나올 수가 없고, 그래서 개발자를 수시로 갈아치워도 표준 규격 나사처럼 며칠만 돌리면 프로젝트가 굴러갑니다. 자바가 일정과 설계가 중요한 SI에 유리한 것도 이런 이유입니다.

물론 자바에도 테크니컬한 부분이 꽤 많이 있습니다만, 절대적으로 SI에 의존하는 만큼 고급 테크닉들이 프로젝트에서 별로 인정을 받지는 못하는 것으로 알고 있습니다. SI에서 성능 최적화라든지 특이한 기능 구현 등의 테크닉은 전혀 중요하지 않을 뿐더러 어떤 경우에는 오히려 마이너스가 되기도 하거든요.

자바 개발자가 보수가 센 것도 약간의 거품이 있습니다. 자바 개발자 구인을 잘 보시면 아시겠지만, 대부분 계약직이거나, 정규직이라도 자주 교체되기 때문에 사실상 계약직에 가깝습니다. 개발자는 대부분 프로젝트 핵심이 아니라 코더로 쓰기 때문에 계약직으로만 100% 채워서 프로젝트를 할 수도 있습니다. 고용보장이 없는 계약직 개발자에게는 보통 정규직보다 몇십 퍼센트를 더 주는 걸 감안하면, 자바 개발자가 보수를 더 받는 데에는 거품이 많죠.

집사람도 자바 개발자는 필요하면 수시로 면접봐서 뽑고, 또 금방 나가면 또 면접봐서 뽑습니다. 집사람을 통해서 안면이 있는 여러 자바 엔지니어들중에는 개발자도 몇몇은 있지만 보통 대우를 제대로 받지도 못하고 크지도 못하더군요.

자바 SI쪽은 일거리는 충분히 많으니 당장 밥벌이에는 다른 어떤 분야보다도 압도적으로 유리한 것은 확실하지만, 성장하고자 하는 개발자에게는 별로 권하고 싶지 않네요. PM이나 모델러, 아키텍트 등 관리자로 성장하는 경우도 적고 또 고급 개발자라는 개념 자체가 별로 정립이 안되는 자바의 특성상 40대가 넘어서도 계속 코더에 준하는 개발자로 남아있기도 어렵지 않을까 싶습니다.

자바 얘기는 그만하고...

개발자.. 아니 엔지니어 모두에게 직장의 선택에서 가장 중요한 것은 커리어 패스입니다. 물론 다른 많은 분야보다 IT 업계의 역사가 훨씬 짧다보니 아직 커리어 패스가 제대로 정립이 안되어 있습니다만, 그래도 최소한의 경력 관리의 개념은 있습니다.

젊을 때는 돈 몇백쯤 더 받을 수도 있고 못받을 수도 있습니다. 하지만 30대로 넘어가면 사람을 키워주고 먹여살리는 것은 경력입니다. 이것저것 조금씩 해본, '발이 넓은' 경력은 초급 개발자로나 유리한 경력이지, 30대 중반을 넘어가면 자랑할 일도 못되고 유리하지도 않습니다. (물론 저 정도의 보통 개발자를 넘어서는 소수의 탁월한 개발자에게는 다를 수도 있겠습니다)

아주 특별하지 않은 거의 모든 개발자의 경우, 경력은 한 우물을 쭈욱 파나가야 합니다. 30대 중반쯤에 누가 경력 기술서를 보더라도 전문인으로서의 경력이 느껴지면 다른 약점이 조금씩 있더라도 선발하고 싶고 또 약간 과한 연봉을 요구하더라도 일단 협상을 해보고 싶은 인재가 되는 것입니다. 이 분야 저 분야 힐끗거리면서 조금씩 해보는 생활은 초급 개발자 시절에는 반드시 필요한 귀중한 경험이지만, 스스로 중급으로 올라왔다고 생각하거나 중급으로 가고 싶다면 경력 관리를 시작해야 합니다.

30대 딱 중간에 이른 지금도 많이 느낍니다만, 40대, 50대에도 계속 개발자로 남아있고 싶은 저로서는 지금조차도 연봉은 별로 중요하지 않습니다. 그게 연봉으로는 별로 많이 받지도 못하는 지금 회사에 남아있는 이유입니다. 지금 다니는 회사의 경력은 다음에 할 일의 발판이니까요. 발판으로서 많은 경험을 할 수 있는 회사라고 생각하기 때문에 다니고 있는 거죠.

사실 말은 이렇게 해도 저도 그렇게 열심히 한 우물만 파지는 않았고 앞으로도 그럴 겁니다. 스스로 개발자로서 희망하는 비전이 있어서 개발자가 되기로 했던 만큼 기술적인 욕심은 많거든요. 하지만 어디까지나, 전공과 부전공 정도의 개념이지, 욕심많은 저로서도 이것저것 잡다하게 다 접해볼 생각은 없습니다. 그런 중구난방식 욕심부리기가 제 미래에 독이 될 거라는 건 알 만큼의 경험은 쌓았으니까요.


C++빌더와 델파이는 당장은 자바나 비주얼 C++같은 경쟁 언어, 기술에 비해 시장이 적은 것은 사실입니다. 하지만 현재는 잠깐의 정체기일 뿐이라고 봅니다. 여러가지 면에서 C++빌더/델파이는 성장 가능성이 아주 큽니다.

먼저 Win32 플랫폼. 아시다시피 C++빌더/델파이는 현재 Win32 개발을 계속 지원하고 있고 향후 수년간의 Win32/Win64 지원 로드맵까지 세워놓고 있을 정도로 윈도우 네이티브 개발에 있어서 현재로서는 가장 강력하게 지원하는 개발툴들입니다.

다음으로 리눅스. 리눅스는 닷넷보다 성장 속도가 빠르고 우리나라의 경우에는 정책적으로 리눅스 도입을 장려하고 있으며 최근들어 더욱 가속화되고 있습니다. 아시다시피 C++빌더/델파이는 같은 소스로 리눅스의 카일릭스에서 그대로 컴파일이 가능합니다(Win32 코드 직접 호출만은 제외). 볼랜드에서 개발툴로 분사하는 DevCo는 최근 몇년간 업그레이드가 중단되어 있던 카일릭스를 부활시키려고 계획하고 있고요. 게다가 카일릭스의 MacOS 지원 버전까지 거론되고 있는 상황입니다.

그리고 닷넷. 리눅스와 마찬가지로, 현재 델파이 소스는 닷넷에서 그대로 컴파일 가능합니다. C++빌더도 곧 닷넷을 지원할 예정이고요. MS쪽 개발툴에서는, VB의 경우에는 아예 호환이 전혀 안되고, VC의 경우 MFC가 닷넷에서도 사용가능하다고 듣기는 했으나 Win32 의존성이 강한 MFC의 특성상 허울뿐일 것은 뻔하죠. 반면 VCL의 경우 성능을 거의 희생시키지 않으면서도 Win32에 대한 추상화의 수준이 높아서 Win32/닷넷 상호간에 마이그레이션이 대단히 쉽습니다.

따라서 C++빌더와 델파이는 기본적으로 전혀 다른 세개의 메이저 플랫폼에서 소스 레벨 호환성이 생기는 겁니다. 이것은 엄청난 장점입니다. 리눅스 시장이 성장하면 할 수록, 또 닷넷 시장이 성장하면 할 수록 오히려 C++빌더/델파이의 장점이 더 빛나게 됩니다. 물론 완전히 다른 세가지 플랫폼을 다 익숙하게 활용할 개발자는 별로 많지 않겠지만, 자신의 경력이나 전문 분야에서 많이 쓰이는 둘 정도의 플랫폼에서 왔다갔다 하면서 개발을 하는 모델은 충분히 가능합니다. 또 개발업체의 입장에서도 동일 소스로 세 플랫폼용의 제품을 출시할 수 있게 되므로 역시 대단한 매력이 됩니다.

인생은 길지요. 3, 4년 정도야 쏜살같이 지나갑니다. 제 생각에는 3, 4년쯤 지나더라도 SI 개발에서의 자바의 압도적인 우위는 별로 변함이 없겠지만, 리눅스가 상당히 많이 성장해있을 것이고, 닷넷도 나름대로는 꽤 시장을 개쳑하겠지요. (지금까지 리눅스가 닷넷보다 성장속도가 빨랐고, 제 생각에는 앞으로도 그런 추세가 계속될 것으로 보입니다) 그래도 여전히 Win32 윈도우가 가장 많이 쓰이고 있을 겁니다. 지금처럼 압도적이진 않겠고요.

여러 플랫폼이 누구도 압도적인 우위를 점하지 못하고 혼재되는 상황에서는, C++빌더/델파이의 멀티 플랫폼 지원이라는 장점이 더욱 더 주목받게 될 것임은 뻔하겠지요? 장담할 정도는 아니지만, C++빌더/델파이가 차세대 주류 개발툴이 될 가능성도 무시할 수 없을 정도로 충분히 있다고 생각됩니다.


진로 선택에 있어서, MFC는 최악의 선택이라고 생각됩니다. 그야말로 사장될 기술이니까요. MS가 기를 쓰고 죽이려는 Win32의 '화신'인데다가, Win32에서 대표주자였던 VC의 위치는 닷넷에서는 엑스트라로 전락해버렸습니다. 여러 기사들을 보면 MS에서조차도 그런 질문을 받고는 부인하지 않더군요(심지어 지난달 마소에 실린 기사에서는 수년전까지 우리나라에서 가장 유명한 VC 개발자들 중 한사람이었던 사람이 그런 얘기를 하더군요. 그것도 VC의 닷넷 매니지드 확장을 소개하는 기사에서 말입니다). Win32에서의 VC나 VB 개발자는 모두 닷넷 C#으로 끌어가기 위한 '집중 영업 대상'일 뿐, 지금의 MS에게는 아무런 의미가 없습니다.

VC 개발자들이 C#으로 많이 넘어가고 반발이 좀 사그라들면 VC 툴 자체를 단종시키고 C#으로 '후보 단일화'를 단행할 것은 뻔하게 보이는 스토리입니다. (이런 걸 '안봐도 비디오'라고 하죠) C# 개발자들야말로 닷넷의 숙적인 자바와 박치기를 시킬 MS의 도구로서 대단한 가치가 있거든요. 또 MS의 그런 모습은 과거에 폭스프로에서도 봤고, VB에서도 봤고, 다른 사례도 수없이 많죠.

MS가 VC를 버리는 시점은 '언젠가' 닷넷이 완전히 대세가 된 후가 아닐 겁니다. 적당한 시점에 전격적으로 추진할 겁니다. MS는 VC 개발자들을 우선 고려하는 것이 아니라 닷넷 확산이 최우선이기 때문에, VC 개발자가 완전히 소수가 되거나 반발이 거의 없어질 시점이 아니라, 닷넷을 위해 필요한 시점에 결행할 것입니다. 닷넷이 대세가 되는 것은 아주 먼 미래일 수 있지만, VC 개발자들이 깡통차고 첨부터 새로 공부해야 하는 시점은 머지 않을 수가 있는 겁니다.

딴 얘기지만... 아직도 VB닷넷을 VB라고 우기는 사람도 가끔씩 있긴 하더군요. 아무리봐도 VB닷넷은 C#의 배리에이션, 변주곡 정도밖에 안되는데 말입니다. 하지만 아직도 완전히 다른 언어인 VB 닷넷이 아닌, 원래의 VB를 계속 출시해달라는 탄원 서명 운동이 계속되고 있지요. 과거에 MS의 매몰차게 제품을 단종시킨 많은 사례들을 알고 있으면서도 수년째 MS에게 졸라댈 수밖에 없는 그 심정, 참 불쌍하기 그지없습니다. 업계 전체에 엄청난 이슈가 되었는데도 MS는 오로지 모르쇠입니다. 다수 고객들이 간청을 하든 말든 전략에 맞지 않으면 여지없이 단종시켜버리는 기업, 그게 MS입니다.
http://classicvb.org/petition/

MS가 닷넷 2.0에 제네릭을 왜 추가했을까요? VB 개발자들이 원했나요? 경쟁 진영인 자바쪽 개발자들이 제네릭에 목을 걸었나요? 아니죠. 많은 VC 개발자들이 C#을 무시하는 많은 이유들 중 하나가 STL이기 때문입니다. 그것만 봐도 MS가 VC 개발자들을 C#으로 유도하려고 많은 노력을 하고 있다는 걸 알 수 있죠. MS가 현재 VC에 들이고 있는 노력들은 두가지의 목적이 있습니다. 첫번째, Win32의 주역이 닷넷에서 엑스트라가 되어버린 마당에 VC 개발자들의 이탈을 최대한 막는 것. 두번째, 일단 바짓가랑이를 붙잡아놓은 개발자들을 최대한 C#으로 이동시키는 것.


주저리주저리..
둥이네님의 진로선택에 조언 한마디한다는 게 오랜만에 잡썰을 한참 늘어놔버렸네요.
그래도 좀 참고는 되겠지요. ^^;;;;