아래.. 패패루님이 알려주셨던, 데브피아의 폭스프로 사용자분의 글... 곰곰히 생각해봤습니다.
C++Builder도 역시 하나의 "특정 개발툴"일 뿐이고, 넘 집착하는 것은 좋지 않다는 얘기였는데..
정말 그런 거 같기도 하다...는 생각도 들구요.

사실 지금 프세에 소개할 C++Builder 6의 리뷰를 쓰고 있는 참인데..
(예상보다 요구된 양이 넘 불어나버려서.. 고생깨나 하고 있네요.)
이거야말로 특정개발툴의 특징들만 소개하는 글을 쓰고 있는 꼴이니.. 스스로 더 우습기도 하네요.

글빨도 제대로 안풀리고 하니... 허접한 잡설이나 좀 풀어놓고 가겠습니다.
(글빨이 잘 안풀려서 딴 글을 쓴다???)


-----------------------------------------------

사실, 첨에 그분의 글을 보고 기분이 좀 상했었습니다.
그런데 패패루님의 설명글을 보고 나니.. 필요할때는 부려먹고 필요없어지면 떨궈버리는 MS의
개발자 정책의 전형을 보는 것 같아 이해도 되고, 안스럽기도 합니다.

뭐, 볼랜드는 안그러냐? 하고 물으면, 어차피 다 똑같은 영리를 추구하는 회사일 뿐이라는 비관론으로
추락하기 십상이겠지만...
적어도 제 개인적인 관점에서는 MS와 볼랜드는 절대로 무시할 수 없는 중요한 한가지 차이점이 있습니다.

두 회사의 덩치가 엄청나게 차이난다.. 그런 썰렁한 개그를 하고 싶은 것은 아닙니다.
볼랜드는 벌써 10년도 훨씬 넘게 개발툴을 팔아서 먹고 살아온 회사인 반면,
MS는 OS와 오피스를 팔아서 먹고 살아온 회사라는 것입니다.

MS에서 개발툴을 팔아서 생기는 수익이 전체 수익의 몇 퍼센트나 될 것 같습니까.
5%? 10%? 절대로 10% 선은 넘지 않을 겁니다.
개발자 지원에 엄청나게 쏟아붓는 돈을 생각해보면, 어쩌면 마이너스일 수도 있다는 생각도 듭니다.

그러면서도 MS가 돈도 별로 안되는 개발툴에 엄청난 공을 쏟아붓고 있는 이유가,
최근에 엄청난 돈을 쏟아고 있는 X박스와 같이, 차후의 시장을 노리기 위해서는 아니겠지요?
이미 MS의 개발툴은 시장에서 포화상태에 있으니까요.
(적어도, 리눅스나 다른 OS용 개발툴을 출시하지 않는 한은 말이죠.)

MS가 개발툴에 정성을 쏟아붓는 이유는 너무나 간단합니다.
OS 플랫폼, 그리고 앞으로는 닷넷 플랫폼에서의 지배적인 위치를 계속 유지하기 위해서이지요.
플랫폼과 개발툴의 불가분의 관계는 MS가 윈도우를 처음 내놓을 때 겪어서 MS 스스로가 다른 누구보다도
잘 알고 있습니다.

비주얼베이직을 말하는 겁니다.
90년대 초반에(제 기억으로는 92년), 겨우 중소기업 티를 벗어가던 MS와 초대기업 IBM이 윈도우 3.1과
OS/2로 시장에서 정면으로 부딛혔을 때, MS가 IBM을 이겨낼 수 있을 가능성은 그리 커보이지 않았습니다.
기술적으로나 회사의 규모로나 IBM의 OS/2가 윈도우를 압도하고 있었으니까요.

그런데 그런 팽팽한 경쟁 상태에서 거의 1년만에 윈도우가 사실상 압도적인 우위로 승리한 것은,
윈도우 출시 이후 곧이어 출시되었던 비주얼베이직이라는 걸출한 개발툴 덕분이었습니다.
생산성에서 다른 모든 개발툴들과 비교되지 않는 본격적인 RAD의 첫 등장이었으니까요.

본격적인 시장에서의 경쟁이 시작된 후 1년만에 윈도우는 비주얼베이직의 후광 아래 엄청난 응용
프로그램들을 가지게 되었지만 OS/2는 그렇지 못했습니다.
이에 충격을 받았던 IBM이 비주얼에이지 시리즈를 개발하기 시작할 정도로.. 엄청난 사건이었습니다.

MS는, 그렇게 플랫폼에 있어서의 개발툴의 중요성을 체득해버렸습니다.
거꾸로 말하자면... MS에게 있어 개발툴이란, 그 자체가 제품으로서가 아니라, 다른 제품군의 마케팅
전략을 위한 보조적인 마케팅 수단이 되어버렸다고 할 수 있습니다.

반면에 볼랜드는 80년대 후반부터 계속 개발툴을 주력으로 해온 기업이죠.
MS의 개발툴들은 개발자들에게 실망을 안겨주더라도 플랫폼에서의 지배력 때문에 개발자들이
돌아서기가 쉽지 않습니다. 반면 볼랜드는, 개발자가 실망해서 돌아서려고 맘먹으면 끝장입니다.
여기에서 벌써 MS와 볼랜드의 개발자에 대한 배려가 얼마나 다를지를 짐작할 수 있을 겁니다.

이런 기본적인 마인드의 차이는 현실에서 여러가지로 나타날 수 있습니다.
이미 언급되었던 폭스프로에 있어서의 MS의 미지근한 정책이나, 닷넷 버전에서 개발자를 무시하고
마케팅에서의 필요에 따라 바뀌어버린 비주얼베이직에서 그 차이를 여실히 볼 수 있습니다.

프로그래밍 언어의 자연적인 진화를 고려했을 때 과연 C#이 필요했을까 하는 점도 의문이구요.
제가 보기엔, 아마 많은 분들이 동의하시겠지만, C#은 C++을 대체하기보다는 자바를 대체하기 위한
것으로 생각됩니다. 물론 반박하실 분도 있을 수 있지만.. 아무리 그렇다 하더라도, C#이 C++을
대신하지 못한다는 것은 자명하지 않습니까.

자바가 처음 IT 업계에 등장할 때였던 96년이었던가에, 많은 초중급 C++ 프로그래머들이 자바를
C++의 업그레이드로 오해를 하곤 했습니다. 그런데 썬에서는 자바를 C++의 업그레이드로 오해할
여지가 있는 말은 한번도 하지 않았습니다. 사실 문법이 닮았을 뿐 실제로 완전히 다른 언어니까요.
그런데 지금 MS는 C#이 C++의 업그레이드라고 자신있게 주장하고 있습니다.
물론 C#이 자바보다 시스템 접근성이 조금쯤은 나아진 것은 사실이지만, 그정도로 C#을 C++의 적자라고
주장하는 것은, 정말 뻔뻔스런 MS가 아니고서는 할 수 없는 일이겠지요.

제가 생각하기엔... C#은, 자바만큼, 아니 자바보다 더 C++과는 아무런 상관도 없는 전혀 다른
언어일 뿐입니다.

말이 한참 샜는데... (장황해지는 것도 병인가 봅니다)
꼭 특정 벤더를 씹으려는 의도를 가지지 않으려고 애를 써도, MS쪽의 툴에 익숙해진 분들에게서
"어차피 개발툴일 뿐" 이라는 말을 자주 듣는 것이 사실입니다.
그리고, 제가 지금까지 보아온 대로라면 볼랜드의 개발툴을 전문으로 써오신 분들에게서는 그런
말은 훨씬 덜 들었습니다. (제가 볼랜드쪽 개발자를 훨씬 많이 접했음에도 불구하고요.)

그 벤더에게 개발툴이 목적이냐 수단이냐의 차이는, 그 말 한마디의 차이보다 훨씬 엄청난 결과의
차이를 가져온다는 것입니다.


-----------------------------------------------

저는 C++Builder, 그리고 보조적으로는 델파이 프로그래머입니다.
하지만 저는 C++Builder 프로그래머이기 훨씬 이전부터 C, C++ 프로그래머였습니다.
그리고 프로그래밍을 C++Builder를 시작으로 공부하신 분들에게도, C++Builder 내에서 C++ 문법이
얼마나 중요한지는 어느정도 공부하시면 저절로 깨닫게 되실 일이라고 생각하고 있습니다.

말도 안된다고 생각하지만, 정말 극단적인 예를 들어서, 어느날 갑자기 볼랜드가 C++Builder를
접겠다고 한다면, 제가 밥벌이에 지장이 생길까요. 또 현재 놀고 있는 제가 만약 볼랜드와는 전혀
관련성이 없는 유닉스 소프트웨어 개발회사에 입사한다면 저는 할일이 없어질까요.

너무나 당연하지만, C++Builder 프로그래머는 필연적으로 C/C++ 프로그래머입니다.
제가 C++Builder를 사용해오면서 이 개발툴에만 한정적인 특징에 익숙해진 것이 있다면...
컴퍼넌트를 이리저리 놓아 폼을 디자인하는 약간의 디자인 감각을 제외하면, VCL 라이브러리뿐입니다.

C++Builder 프로그래머들이 자주 찾는, http://www.bcbdev.com 라는 사이트의 운영자인 Harold Howe를
예로 들어보지요. 이 사람, TeamB의 일원이면서 유명한 C++Builder 책 두권의 집필에도 참여한 꽤
이름있는 C++Builder 프로그래머입니다.
이 분이 최근에, 재밌게도 사이트 홈페이지에 직장을 구한다고 글을 올려놨는데... 이력서가 볼만합니다.
스스로를 소개한 글에 C++Builder에 대한 언급은 하나도 없이, C++ 프로그래머라고만 소개하고 있습니다.

분명 C++Builder는 "특정 개발툴" 입니다.
하지만 그분이 지적하신 것과 같은 개발툴 의존성은 그리 높지 않습니다.
그것은, C++이 완전한 표준을 가진 크로스플랫폼 언어이기 때문이기도 하고, C++ 본연의 프로그래밍
방법을 벗어나지 않으려고 고심한 볼랜드의 배려덕분이기도 하다고 생각하고 있습니다.

폭스프로에 빗대어 특정 개발툴론을 말씀하신 그분께는 너무나 죄송한 말씀이지만..
말그대로 "특정 개발툴"임을 벗어날 수 없는 폭스프로나 비주얼베이직에 C++Builder를 비교한
결과 생긴 말의 모순이겠지요.


-----------------------------------------------

자꾸 꼬투리를 잡게 되는 것 같은 느낌도 드는데...
일단 일부러 그러는 것은 아니라는 말부터 해두고요.
개발툴/언어에 연연하지 말고 OOP나 UML 등 기본에 충실하자...는 말에 대해서도 한마디 하지
않을 수가 없습니다.
전 이론적인 베이스보다는 실전을 통해 프로그래밍을 익혀온 넘이라서 더욱 그럴지도 모르겠습니다만.

OOP나 UML... 이런 것들을 프로그래밍에 있어 방법론이라고 해도 좋을지 모르겠는데요.
(프로그래밍 방법론이라고 부르기로 합시다.)
프로그래밍 방법론이 언어 자체보다 기본일 수는 없습니다. 닭이 먼저냐 달걀이 먼저냐 하는 문제도 아닙니다.
이것은 마치, 실생활에서 각 민족의 언어가 먼저냐 언어학이 먼저냐 하는 것과 같으니까요.

왜 이런 쓰잘데기 없는 것을 갖고 트집(?)을 잡는지 잘 이해가 안되실지 모르겠지만...
제가 지금까지 겪어온 프로그래밍의 경험에서는, 하나의 언어(혹은 개발툴)에 정말 익숙하지 않은
상태에서라면 어떤 프로그래밍 방법론도 이론적으로만 머리에 들어가지 제대로 활용할 수는 없다는 것입니다.

C++ 언어이든 자바이든 C#이든, 하나의 언어를 정말 확실하게 알지 못한다면 프로그래밍 방법론은
제대로 적용될 수가 없습니다.
이론적인 OOP를 완벽하게 지원하는 것은 스몰토크밖에 없다는 것을 감안한다면, C++에서 OOP를 구현하려면
순수 OOP가 아닌 C++ 방식의 OOP를 써야 하고, 그러려면 C++의 특징을 정말 제대로 이해하지 못하면
불가능하기 때문입니다.
다시 말해, 언어가 우선이고, 프로그래밍 방법론은 그 뒤의 문제라고 할 수 있겠습니다.

물론 둘 이상의 언어에 정통하다면 더욱 좋겠지만... 적어도 제가 지금까지 보아온 평범하기만 한(?)
프로그래머들 중에서는, 그분들이 내세우는 말만큼은 둘 이상의 언어를 제대로 잘 이해하고 있는
프로그래머는 없었습니다.
(상당한 경력을 자랑하는 자바 프로그래머분들에게서 그런 경우를 많이 봤습니다)

그럴 수밖에 없는 것이, 정말 프로그래밍 언어 연구소와 같은 것이 있어서 수년 이상 프로그래밍
언어 자체만을 연구하고 있는 분이라면 몰라도(하긴 그렇다면 프로그래머라고 할수도 없겠지만)
실무를 뛰는 프로그래머에게는 한 언어에서 새롭게 등장하는 기술들만 해도 숨가쁠 정도로 따라가기가
쉽지가 않기 때문이겠죠.

전 집사람이 오랫동안 썬에서 자바 강사를 했던 관계로 자바에는 필요 이상으로 익숙한데요.
실제로 방안에 굴러다니는 책들을 보면 제 C/C++ 책보다 집사람의 자바 책이 훨씬 많습니다.
하도 자주 봐서 레퍼런스 같은 것을 뒤져서 필요한 패키지 이름만 찾아내면 웬만한 자바 코드는
작성할 수 있다고 자신하고 있습니다만.

그렇다고 제가 자바 프로그래머가 될 수 있냐고 하면, 천만에 말씀입니다. 택도 없죠.
단지 코드 작성 시간이 더 걸려서가 아닙니다.
아무리 문법이 비슷하고 코드의 형태에 익숙하다고 하더라도, C++의 방법과 자바의 방법이 너무나
다르기 때문입니다. 10년 넘게 C/C++을 다룬 제가 자신있게 자바 프로그래머라고 자부할 정도가 되려면
아마 아무리 못잡아도 1년 정도는 걸릴 겁니다.

물론 프로그래밍 방법론을 무시하려고 이런 위험한(?) 언사를 일삼고 있는 것은 아닙니다.
저도 모델링에 관심을 가지고 있기 땜에 짬짬이 래셔널 로즈같은 것도 돌려보고, 화장실에선 집사람의
디자인 패턴 교재도 자주 들쳐봅니다. (단지 정독할 시간이 없어서입니다.)
그러다가도, 제 가물거리는 C++ 지식이 한계를 드러내면 거기서 책을 덮고 다시 C++ 문법을 뒤져봐야
합니다.

이렇게 장황하게, 프로그래밍 방법론보다는 언어가 더 우선이라고 주장하는 이유는..
최근에 마치 유행처럼 등장하는 각종 프로그래밍 방법론에 눌려 갈피를 못잡는 분들에게 하나의
길을 제시해드리기 위해서입니다.


-----------------------------------------------

말이 나온 김에, C++언어에 대한 이야기를 좀 더 풀어보지요.

많은 분들이 오해를 하고 있는 듯 한데... C와 C++은 프로그래밍 방법론과는 상당히 무관하게 개발된
언어라는 점을 잊지 말아야 합니다.
C/C++을 프로그래밍 학문의 관점에서 보는 분들(순수한 의미의 프로그래머가 아닌)은 C++이 완전한
OOP를 구현하지 못했다느니, C 언어의 기반위에 세워져서 절차적 방법론을 탈피하지 못하는 문제가
된다느니 하는 말들을 하는 것을 자주 보아왔는데요.

역시 제 생각에서는... 정말 웃기기 짝이 없는 일입니다.
자동차에 대고 왜 날개가 없느냐, 혹은 비행기에 대고 왜 변속기어가 없느냐고 하는 꼴입니다.

C언어는 철저하게 실무적인 필요에 의해 만들어진 언어입니다. 그리고 그 뒤를 이은 C++도
역시 기존의 C에서의 생산성을 재고하는 정도에서 OOP를 적절하게 도입했을 뿐이지, OOP라는
거창한 개념의 지상 구현을 위해 C++을 창안한 것이 아닙니다.

이러한 C++의 설계 철학은 스트로스트럽의 수많은 인터뷰에서 조금도 숨기지 않고 잘 나타나 있습니다.
확인해보고 싶으시다면.. http://www.research.att.com/~bs/interviews.html

그런 이유로, C++에서는 OOP를 강요하지 않습니다.
C++에서 OOP는 필요하면 쓰고 필요없으면 쓸 필요가 없는 선택적인 방법일 뿐입니다.
그러니 제발, C++에서 C언어의 절차적인 프로그래밍을 자주 쓴다고 자조하지 마십시오.

반면 자바와 C# 등 OOP의 순수성을 강조하는 언어들에서는 OOP는 프로그래밍 방법의 선택권을 떠나
종교적인 신념처럼 보일 만큼 OOP적인 방법을 사용하도록 강요하고 있습니다.
클래스를 만들지 않으면 아무것도 할수가 없지요.

C++을 이렇게 설계한 이유에 대해, 스트로스트럽은 몇가지로 언급하고 있는데요.
오버헤드를 없애기 위해, 다양한 프로그래밍 패러다임(OOP 혹은 procedual)을 모두 껴안기 위해,
그리고 많은 사람들이 원했기 때문이라고 말하고 있습니다.
그야말로 실용적인 관점이라고 밖에 말할 수가 없지요.

이러한 설계철학에서의 실용적인 관점이, 수십년동안 C++을 사랑받게 만든 근본적인 원인입니다.
쓰면 쓸 수록 손에 착 붙는 도구라고 말할 수 있습니다.
물론 어느정도 익숙해지기까지는 상당한 고난을 겪어야 하는 것이 치명적인 약점이긴 하지만요.


-----------------------------------------------

몇달전 마이크로소프트웨어였던가에서, 10년을 사용할 언어? 개발툴? 에 대한 개발자의 목마름과
갑갑함에 대한 글을 읽었습니다.

그런 목마름의 원인은 아주 단순한 것입니다. 개발자가 유행을 쫓아가고 있기 때문입니다.
C++에서 자바로 넘어간 개발자가, 또다시 MS의 막대한 홍보규모에 눌려서 C#을 기웃거리게 되니
그렇게 되지 않겠습니까. 그야말로 스스로 판 무덤에 빠진 꼴입니다.

자바와 C#은 분명 현재, 그리고 가까운 미래에는 더욱더 IT 업계의 막대한 부분을 차지하게 될 겁니다.
하지만 그 힘은 이미 증명된 언어의 능력이나 신뢰도가 아니라, 업계를 쥐고 흔드는 몇개 업체의
입김입니다.

몇개의 성공적인 실례를 들어서 자바와 C#이 이미 증명되었다고 주장할 생각이 든다면,
C와 C++의 40년 역사와 비교해보십시오. 거기에 대해 다시, 구세대 기술이 아니냐고 말하고 싶다면,
그런 대형 벤더들이 주장하는 새로운 기술들이 과연 C++에서 구현될 수 없거나 복잡한가를 생각해보십시오.

C/C++을 염두에 두고 자바나 C#을 바라보면, 아직 햇병아리같은 실험적인 시도일 뿐입니다.
개발자들의 자발적인 선택이 아닌 업체의 주도로 선택이 강요된 기술은, 그 업체들의 영향력이
줄어들거나, 더 새로운 기술에 의해 쉽게 대체되어 버리는 것이 당연합니다.


이제 프로그래밍을 시작하는 분들께 C++로 시작하라고 권하고 싶은 생각은 전혀 없습니다.
자바나 C#은 분명히 개발자를 편하게 해주는 또하나의 선택가능한 방법입니다.
하지만 이미 C++에 익숙해진 분들이 억지로 자바와 C#의 싸움에 끼어들 필요는 없다고 생각합니다.

거대한 흐름에 동참해야 할 것 아니냐.. 하고 성급하게 대세론을 펴고 싶으신 분들께는...
결코 C/C++ 시장이 줄어들지 않는다는 것을 강조하고 싶습니다.

IT 업계는 본질적으로 끊임없이 성장합니다. 더욱이 MS나 썬 같은 대형 벤더들은 그 시장에도
만족하지 못하고 억지스럽게 새로운 시장을 만들어내려고 노력하고 있습니다.
하지만 아무리 자바와 C#, 그리고 그 이후의 언어가 판을 친다고 하더라도, C/C++에 대한 요구는
줄어들지 않습니다.
적어도 "정말로 C++을 대체할 수 있는 언어"가 나타나기 전까지는요.

어셈블리나 코볼과 같은 언어는 거의 사라져가고 있지 않느냐라고 말씀하신다면...
그런 언더들은 C/C++로 대체가 가능하지만 자바나 C#은 C/C++을 대체하지 못한다는 것을 다시 상기시켜
드리고 싶습니다.


-----------------------------------------------

잠깐 머리좀 식히려고 쓰기 시작한 글인데.. 너무 구질구질, 장황한 글이 되어버렸네요.
졸려서 무슨 내용을 썼는지 잘 기억도 안나는데...

요즘 제 글이 다른 사이트에 인용되는 경우가 몇번 있었는데... 뭐 그래도 상관은 없습니다만,
이 글은 가급적 다른 곳에 올려지지 않았으면 합니다.
보셨으면 아시겠지만, 논란을 불러일으킬만한 소지가 많지 않습니까? ^^
공연히 싸움을 벌이고 싶어서 쓴 글은 아니니까요.

기럼...