C++ 개발자들이 대부분 iostream과 함께 C++을 공부하기 시작하지만, iostream을 개발하는 개발자는
극소수입니다. 이미 구현되어있는 것을 단순히 인스턴스를 만들어 사용하는 것과 클래스를 새로
만드는 것은 완전히 별개의 문제이지요. 리눅스 커널을 개발하는 개발자는 커널 개발자이지만,
커널을 포함해서 리눅스를 이용한다고 해서 커널 개발자라고 할수는 없는 거 아니겠습니까.

디자인패턴에 대해 맛도 제대로 못본 저이지만, 패턴중에 다중상속을 이용하는 예가 있다고 해서
다중상속이 반드시 사용해야 할 필수적인 기능이라는 얘기는 아니겠지요.
디자인패턴은 말 그대로 이런 식으로 할 수 있다는 패턴을 제시할 뿐이니까요. 따라서 디자인패턴에서
다중상속을 이용하는 예가 있다고 해서 다중상속의 해로운 점보다 이로운 점이 많다는 근거는 되지
못하겠죠.

그리고, '자바나 C#이 다중상속을 지원하지 않는 것은 기능을 추가하기 힘들어서가 아니다'는 말은,
너무 좁은 의미로 해석하신 듯 합니다. 썬이나 MS가 구현하기가 힘들어서 다중상속을 빼버린 것이
아니라는 말입니다. 설마 김백일님께서는 썬과 MS가 다중상속을 자바와 C#에서 구현하기가 힘들어서
빼버렸다고 생각하시는 것은 아니시겠지요?

하지만, 김백일님의 글을 보고 나니 '다중상속은 안쓰는 것이 이미 대세다'라는 제 말은 좀
오버였던 거 같네요. 다중상속에서 새로운 가능성을 모색하는 사람들도 상당히 많다는 것을 인정합니다.

그렇지만...
먼저도 말했듯이, 제가 아는 한에는 대부분이라고 할 만큼 많은 C++ 개발자들은 다중상속을
(다중상속의 결과물이 아니라) '이용'하지 않습니다.
아니, '대부분'이라고 말한 것은 과장일지도 모르겠습니다. 설문조사를 해본 것도 아니니까요.
하지만 솔직히 말씀드리면 제가 지금까지 직접 참여했거나 보거나 전해들었던 프로젝트에서 다중상속을
이용한 경우를 보지 못했습니다.

물론 김백일님이 말씀하신 것과 같이 제가 잘 모르는 분야 혹은 어떤 흐름으로 다중상속이 많이
사용되고 있을지도 모르겠습니다만, 그것이 다수로 보이지는 않는군요.
김백일님이 예를 든 참고서적의 제목에 왜 Exceptional이 붙어있는지도 생각해볼 일입니다.

제가 이전 글에서나 지금 말하는 것은, 다중상속이 전혀 쓸모가 없다든지 쓰지 말자는 얘기가 아닙니다.
'죽은 기능이나 마찬가지'라고 한 말은 C++ 개발자에게 쓰지 말라고 한 것이 아니라 다중상속을 부러워하는
델파이 개발자에게 한 말이지요. (역시.. 좀 과장스러웠다는 점은 인정합니다.)


김백일님과 마찬가지로, 저역시 가능한 모든 도구를 허용하는 C++의 철학 때문에 C++을 좋아합니다.
이런 면에서 자바나 C#과 같은 언어와의 차별성이 더욱 두드러지지요.
'문제를 피할 수 있다면 포함시킨다'와, '문제가 발생할 수 있다면 포함시키지 않는다'의 차이쯤
되겠지요.

그 추가적인 선택권을 누가, 어디에, 어떤 식으로 사용할 것이냐에 따라서 그 넓은 선택은 약이 될
수도, 독이 될 수도 있는 거죠. 그런데 그 선택 방법이 필수인 것처럼 강조된다면 그 해악은 더욱더
필요 이상으로 커지게 됩니다.

C와 C++의 시대가 끝나가는 것처럼 보여지는 요즘의 분위기를 볼 때,(그것이 사실이든 아니든!)
개인적으로 제가 가장 원망스러운 것은 입문서에서 C/C++의 까다롭고 복잡한 면들을 꼭꼭 집어넣고
강조하는 저자들입니다. 마치 포인터를 사용하지 않으면 C 개발자라고 말할 수 없다는 듯이,
마치 템플릿을 사용하지 않으면 C++ 개발자가 아니라는 듯이 말입니다.

C와 C++에서 포인터와 템플릿을 모르더라도 분명 대부분의 프로그램을 훌륭히 작성할 수 있으며,
그런 경우라면 C/C++ 언어는 자바나 C#과 비슷하거나 오히려 더욱 쉽습니다.
물론 성능이나 자원소모 등 효율 문제는 남겠지만, 대부분의 개발자들에게 이런 것은 그다지
크리티컬하지 않습니다.

저도 포인터를 대단히 좋아하고 적어도 포인터에 있어서만은 이 포럼의 어떤 분보다도 능란하게
갖구논다고 자부하지만, 효율이 크리티컬하지 않은 코드에는 절대 포인터를 사용하지 않습니다.
개발 자체부터 디버깅과 유지보수에 아무리 적더라도 조금의 시간은 더 들어가기 때문입니다.

템플릿도 포인터와는 약간은 다르지만 전체적으로는 마찬가지입니다. 단순히 STL 등의 이미 구축된
템플릿 라이브러리를 사용기 위한 정도라면 템플릿의 구현방법이나 동작방식 등 자세한 내용을 알
필요가 없습니다. 매뉴얼에서 한두 페이지의 설명만 보면 충분합니다. 사실 그렇게 쉽게 사용하려는
아이디어에서 출발한 것이 컴포넌트잖습니까.

일반적으로 어떻게 정의하는지 모르겠지만, 저는 그동안 개발자로 살아오면서 '좋은 프로그래밍 언어'의
3대 조건이라고 여기는 것이 있습니다. 성능 효율과 개발 효율, 학습 효율입니다.
(프로그래밍은 결코 예술이 아닌 만큼 효율의 관점에서 기준이 설정되해야 한다는 게 제 생각입니다)

이중 C/C++이 가장 강점을 보이는 것은 물론 성능 효율입니다.
그런데, 개발 효율과 학습 효율 면에서도 자바나 C#과 비슷한 레벨에 있다고 생각합니다.
자바나 C#에는 있지도 않은 선택가능한 방법들 때문에 C++이 더 어렵다는 말은 억지에 가깝죠.

다중상속으로 돌아가지요. 다중상속이 없더라도 할 짓 다 할 수 있습니다.
물론 다중상속을 능수능란하게 사용할 수 있다면 성능효율과 개발효율을 동시에 충족시키겠지요.
하지만 제가 생각하는 '좋은 프로그래밍 언어'의 기준에는 이 외에도 학습 효율이 있습니다.
다중상속이 사용될 수 있는 귀중한 기능이라면 당연히 학습효율을 무시하고 그만한 가치가 있습니다.
하지만 불행히도 다중상속이 꼭 필요한 일은 그다지 잦지 않습니다.

C/C++ 개발자 세계는 알게 모르게 '구루'들에 의해 지배되고 있습니다. 물론 전체 C/C++ 개발자들에게
구루들은 존경받을 만한 가치가 있고, 그들의 작업들도 마찬가지입니다. 하지만 모든 C/C++ 개발자들이
구루가 되어야 한다는 발상은 이미 구시대적인 발상이 되었으며, 자바와 C#에 많은 개발자들을
뺏기고 있는 현실이 그 결과입니다. 선배 C/C++ 개발자들이 포인터와 템플릿을 그토록 강조하지
않았다면, 애초에 자바에 그렇게 많은 C/C++ 초급자들이 눈을 돌릴 일도 없었을 거라고 생각합니다.

몇년전 자바 개발자인 집사람과 처음으로 프로그래밍 언어의 성능에 대해 이야기를 나누었을 때의
충격을 지금도 잊지 못합니다. 제가 C++의 성능을 강조했을 때, 집사람은 성능은 하드웨어 업그레이드나
증설로 해결하면 되지, 라고 대답했습니다. 물론 그렇지 못한 경우도 많고, 지금은 집사람도 그런
면들을 이해하는 듯 하지만, 그때 제가 받은 충격은 정말 황당하고 막막하면서도 신선했습니다.

지금은 성능 효율보다 개발 효율과 학습 효율이 더 강조되는 시대입니다.
그렇다고 C/C++이 개발 효율과 학습 효율 면에서 자바나 C#보다 그리 뒤쳐지지 않으며 오히려 뛰어난
부분도 있습니다. 그런데도 개발과 학습 효율 면에서 한참 뒤쳐지는 것처럼 비춰지는 것은,
'선택'을 마치 '필수'인 것처럼 제시해온 선배 C/C++ 개발자들의 책임이 크다고 생각합니다.

C++이 성능 크리티컬한 분야에서만 살아남아야 할 이유는 없습니다.
만약 그렇다고 한다면(성능 크리티컬한 분야에서만 살아남아야 한다면) C++ 개발자는 당연히 모든 고급
기능에 능숙해야 하겠지요. 하지만 C++은 자바나 C# 못지 않게 충분히 쉽고 편한 언어입니다.
적어도 제가 아는 한에서는, 당장 이 포럼에서 C++빌더를 사용하는 개발자들 대부분이 성능이 그다지
크리티컬하지 않은 작업에 대부분의 작업시간을 보내고 있습니다.

결론적으로 제가 말씀드리고 싶은 것은, 자유를 강조하는 C++의 철학만큼, C++이 사용되는 분야가
다양하고, 그 중에는 김백일님이 보시기엔 아주 단순한 코딩만을 반복하는 분야가 아주 많다는 것입니다.
그리고 그런 경우라도 C++보다 더 쉬운 언어로 델파이나 자바, C#을 찾을 필요가 없다고 생각합니다.
C++은 이미 충분히 쉽기 때문입니다.

그런만큼, 저는 C++ 개발자들에게 C++의 핵심이 포인터나 템플릿, 다중상속과 같은 기능인 것처럼
비추어지는 것에 대해 반대합니다. 굳이 그 관련으로 핵심을 꼽는다면, 선택의 자유겠지요.

반론이 좀 싱겁나요?
최근 몇년간 공부를 제대로 못하다보니... 쩝~~
열심히 공부를 하시는 김백일님을 보면 항상 존경스럽고 부럽네요.