저번에는 저와 의견이 거의 일치하셨는데, 이번에는 조금 다른 부분도 있군요. ^^
주정섭님과 토론하는 것이 즐거워 저도 가볍게 써보겠습니다. 혹시 다른 의견을 말하더라도 좋게 이해해주시면 좋겠습니다.

저도, 많은 초중급 경력을 가진 개발자들이 이것 저것 주종 언어 없이 조금씩 하는 모습은 보기가 안좋더군요. 프로그래밍 언어는 현실 세계에서의 언어와는 많이 달라서, 여러 언어를 할 줄 안다고 해서 장점은 그리 크지 않습니다. 대부분의 프로그래밍 언어들은 기본적인 기능은 거의 동일하고 문법도 유사합니다. 언어들 사이의 차이점을 강조하면 차이점이 아주 많게 느껴지지만, 사실 대부분의 언어는 80~90% 이상의 기능이 기본적으로는 동일한 기능을 가지고 있지요.

상당히 많이 다른 모양새를 하고 있는 C++과 델파이의 오브젝트 파스칼조차 문법의 차이점보다는 유사점이 압도적으로 많고, 하물며 앞다퉈 C++의 후계자를 주장하는 자바와 C#이 C++과 닮은 정도는 말할 필요도 없겠지요. 그러면 그런 작은 차이점이 엄청나게 중요하기 때문에 여러 언어를 공부할 필요가 있는 걸까요.

물론 그런 적은 차이점이 언어의 성격을 크게 바꾸는 경우도 있습니다. C++과 자바/C#의 관계가 그렇죠. 두가지 언어들은 많이 비슷해보이지만 포인터를 자유롭게 허용하느냐 제한하느냐의 여부만 따지더라도 실제로 사용할 때는 성격이 완전히 다른 언어입니다.

그러면 C++과 오브젝트 파스칼, 혹은 자바와 C#의 관계도 비슷하게 큰 차이가 있을까요? 전혀 그렇지 않습니다. C++과 오브젝트 파스칼은 문법의 모양새는 좀 달라도 다른 언어들과 비교할 때 실용적인 면에서 대단히 유사합니다. 두 언어는 거의 완벽하게 1:1로 대체가 가능한 언어들이죠. 종종 C++빌더와 델파이 두가지 중에서 어떤 것을 선택해서 공부할지를 물어보시는 분들에게, 저는 이렇게 대답합니다. C나 C++ 문법에 익숙하다면 C++빌더가 낫겠고 C/C++ 경험이 전혀 없다면 초기에 접근하기 쉬운 델파이가 낫다고 말입니다.

하물며 자바와 C#의 관계는 더욱 그렇습니다. 두 언어는 모두 C++의 후계자라고 우기고 있고(C++을 대체할 수 있는 기능이 안되는데도 그렇게 우기는 것이 참 웃깁니다만) 모양새도 유사합니다. 그리고 똑같이 C++의 막강한 시스템 접근 권한을 차단함으로써 차별성을 강조하고 있고, 또 두가지 언어가 두각을 나타내고 있는(혹은 그럴 수 있을 것으로 예상되는) 분야가 모두 업무 개발 쪽으로 동일합니다.

이런 자바와 C#을 두가지 모두 익힌다는 것은 무의미하기 짝이 없습니다. 유사한 면과는 달리 차이점들도 분명히 있지만, 그런 기능상의 차이점들은 대체로 좀더 고수준인 경우가 많고, 그래서 두가지 모두 익혀야 할 이유가 아니라 오히려 한가지 언어에 더 올인해야 할 이유가 될 뿐입니다.

그러면 C++/델파이와 자바/C#은 같이 공부해야 할 필요가 있을까요. 뭐 이건 상황에 따라 그럴 수도 있습니다. 아닐 수도 있구요. 왜냐하면, C++, 델파이, 자바/C#은 장단점이 확실히 존재하고 그래서 주로 쓰이는 분야가 다르기 때문입니다. 점점 더 자바가 많이고 있는 현재에도, C++의 사용이 오히려 늘어나는 분야가 있고 마찬가지로 델파이가 점유율을 높여가는 분야도 있습니다. 예를 들어 FA분야같이 하드웨어 인터페이스가 많은 분야라면 C/C++을 사용하는 경우가 압도적일 것이며 델파이도 만만치 않습니다. 이런 분야에서 자바나 C#은 거의 명함을 내밀기가 어렵죠.

조금씩 얘기가 새고 있는 거 같은데, 얘기를 시작한 김에 자바와 C#이 일반적인 업무 개발에서 더 유리한 이유에 대해서도 간단하게나마 써볼까 합니다. 업무 개발과 대비되는 패키지, 솔루션 개발에서도 물론 일정의 준수는 중요하지만, 업무 개발에 있어서 일정의 준수는 거의 절대적인 가치입니다. 업무개발에서 지연보상금이라는 개념이 존재하고 실제로도 지연보상이 이루어진다는 것이 그 반증입니다.

일정의 준수를 위해서 무엇보다 중요한 것은, 프로젝트의 예측 가능성입니다. 예상치 못했던 버그, 예상치 못했던 오동작, 심지어는 개별 개발자가 예상치 못했던 알고리즘, 라이브러리나 루틴을 사용하는 것도 모두 프로젝트의 예측 가능성에 치명적입니다. 개발자가 더 많은 기술을 구사할 수 있거나 더 저수준의 기술을 구사할 수 있는 환경은 프로젝트의 예측 가능성을 떨어뜨리고, 단적으로 말하자면 개발자의 자유도가 곧 예측가능성의 저하로 연결된다는 것입니다.

C와 달리 표준 스트링 클래스를 도입한 C++에서, 더 편한 스트링 클래스가 추가된 것과는 별개로 저수준 char 포인터를 여전히 문자열로 사용할 수 있습니다. 표준 스트링 클래스만 사용하도록 강제한다면 생길 수가 없는 버그가, 개별 개발자가 char 포인터를 사용할 가능성 때문에 예측하지 못했던 버그가 생길 수 있고 일정의 측면에서 다른 위험성들도 생깁니다. 게다가 해당 개발자로서는 '성능을 위해서' 등등의 명분이 존재할 수 있기 때문에 더욱 그렇습니다. 여기서 문제는 업무 개발에서는 성능 혹은 UI 등등은 최우선의 가치가 아닌 데 반해, 일정의 준수는 절대적인 가치이기 때문입니다.

이런 기간 예측 가능성을 높이려면 필연적으로 기능의 제한이 뒤따를 수밖에 없는데, 언어의 기능을 제한함으로써 예측 가능성을 높인 것이 자바가 C++에 비해 업무 개발에 있어 지금과 같은 열풍을 일으키고 있는 근본적인 이유라고 생각합니다. 자바가 C++에 비해 추가로 더 가진 기능들도 있지만, 거의 모두 C++에서도 라이브러리 수준에서 지원을 추가할 수 있는 기능들입니다. 따라서 자바가 기능이 더 좋아서 C++보다 업무 개발에 적합한 것이 아니라, 반대로 기능을 제한했기 때문에 적합하다는 얘기입니다. 반면 C++에서 새로운 기능을 추가하더라도 여전히 저수준의 접근이 가능하기 때문에 그 가치가 반감된다고 할 수 있습니다. 예를 들어 가비지 컬렉션을 라이브러리로 추가하는 것이 불가능하지 않지만, C++에는 그렇게 추가된 가비지 컬렉션을 피해갈 수 있는 방법도 있기 때문이죠. 물론 여기서 거론한 C++의 기능은, 델파이에도 거의 100% 적용되는 이야기들입니다.

다시 원론, 복수의 언어를 익히는 것이 필요할 수 있느냐 아니냐의 문제로 돌아가죠. 저도 대부분의 개발자들에게는 복수의 언어를 익힐 필요는 없다고 생각합니다. 웬만큼 인정받는 기술의 레벨로 성장하려면 복수의 언어를 이것 저것 기웃거려서는 힘듭니다. 대부분의 개발자들에게는 거의 불가능에 가까울 겁니다.

그러면 왜 많은 개발자들이 여러 언어에 대해 욕심을 부리느냐... 이것은 대부분 프로그래밍 언어에 대해 기본적으로 이해를 잘 못하고 있기 때문이라고 생각됩니다. 앞에서 말했던 것처럼 프로그래밍 언어는 대부분 80~90%의 기능들이 유사하고 약간의 차이점만 있을 뿐이지만(물론 그 적은 차이점의 의미가 생각보다는 클 수도 있다고도 말씀드렸습니다) 프로그래밍 언어들을 마치 현실 세계의 민족들의 언어들처럼, 이것저것 가지수를 많이 알면 더 유리하다고 판단하는 것 같습니다.

물론 전혀 사실이 아닌 것은 아닙니다. 더 많은 언어를 구사할 수 있으면 더 많은 프로젝트에 참여할 기회가 있을 것이며 더 많은 기업에 이력서를 낼 수 있을 겁니다. 문제는, 주정섭님께서도 말씀하셨다시피 그만큼 더 전문화되기 어렵기 때문에 초보를 벗어나기가 훨씬 더 어렵다는 것입니다. 하지만 아주 한정적인 경우 가능할 수 있습니다. 그것은 전문화된 '코더' 개발자의 경우입니다.

업무 개발쪽에는 전문화된 코더가 생기기 시작하고 있고, 앞으로 그런 추세는 조금씩 더 높아질 것으로 생각됩니다. 특히 자바를 이용하는 업무 개발에는 아키텍처에 대해 전혀 결정권이 없는 코더가 지금도 존재합니다. 이런 코더 개발자들은 특정 언어의 세부적인 면을 자세히 숙지할 필요가 상대적으로 적습니다. 따라서 자바 코더가 C#의 문법 정도만 익혀서 C#으로 점프해서 프로젝트에 참여하는 것이 가능할 수 있을 것입니다.

하지만 프로젝트의 구성원에서 코더가 구분되는 것은 어디까지나 일부입니다. 지금도 모든 자바 프로젝트가 코더를 명확히 구분하는 방향으로 가고 있는 것도 아니고, 또 같은 업무 개발이라고 하더라도 자바와 닷넷의 개발 공식이 적용되는 경우에만 가능합니다. 다른 언어, 특히 C++이나 델파이같은 언어에서는 전혀 현실도 아니고 앞으로도 그렇게 되기 힘들다고 생각됩니다.

또한, 능동적이고 적극적인 개발자들 대부분은 이런 코더로서의 직책을 목표로 삼고 있지도 않을 것입니다. 따라서 개발자로서 크게 성장할 목표를 가진 대부분의 일반적인 개발자들에게, 여러 언어를 익히려고 욕심을 부리는 것은 현명한 일이 아닙니다.

잠깐 딴 얘기로 새는 것 같지만, 저는 업무 개발이 전문도 아니고 합니다만 지금은 회사에서 업무 프로젝트의 책임을 맡고 있습니다. 델파이와 C++빌더를 섞어서 쓰고 있구요. 지금으로서는 제가 모든 핵심 아키텍처를 개발하고 있고, 개발자들에게는 업무의 구현, 비교적 코더에 가까운 일들만을 맡기고 있습니다. 저희 개발자들을 모두 코더로 만들려는 목적이 있는 것이 아니라, 적어도 업무 개발에 있어서는 이런 식의 업무 분할이 필요하다고 생각하고 있고, 개발자들이 이런 식의 프로젝트 방식(아키텍트와 코더를 구분하는 방식)이 당연하다고 받아들여야 한다고 생각합니다. 그리고 제가 아키텍트로서의 작업을 떠날 때, 개발자들 중 더 능력있고 의욕적이며, 아키텍처에 대해 익숙하고 내부를 잘 이해하는 개발자에게 책임을 맡길 것입니다. 물론 기본적인 업무 구현이라는 코더에 가까운 작업에 비교적 만족하는 개발자들은 그대로 있을 수 있습니다.

이런 형식.. 그러니까 코더 중에서 뛰어난 사람을 아키텍트로 키우는 것은 델파이와 C++빌더이기 때문에 가능하다고 생각합니다. 자바의 경우 일단 코더로 일하기 시작하면 아키텍트로 크기 힘듭니다. 아니.. '코더'라고 표현하는 것은 지나치게 낮게 표현하는 것 같군요. 하급 개발자라고 할까요. 어쨌든, 여기서 중요한 것은, 적어도 업무 개발 프로젝트라면 아키텍트와 하급 개발자(코더)의 역할을 명확히 나눌 필요가 있다는 것입니다. 하급 개발자가 아키텍트로부터 요구되는 것 이상의 기술을 욕심내어 적용하려 하거나 하면 생산성과 예측가능성이 떨어집니다. 특정 기술의 사용 여부에 대해서는 아키텍트(혹은 아키텍트'들')이 절대적인 결정권을 가져야 하며 이렇게 해야 C++이나 델파이의 취약점, 예측 가능성이 낮은 점을 최소화시킬 수 있습니다.

기술에 초보일 수록 새로운 기술이나 이전에 해보지 않았던 기술에 대한 의욕이 많습니다. 이건 당연한 인간의 심리입니니다. 한마디로 상대적인 빈곤감 때문에 생기는 욕심이죠. 하지만 적어도 업무 프로젝트 필드(실무)에서는 이런 욕심을 아키텍트가 제어해야 합니다. 익숙하지 않은 기술에 욕심을 많이 내면 많이 낼 수록 프로젝트는 산으로 가는 것이 당연합니다. 이것은 자존심 따위가 걸린 문제가 아니라, 프로젝트의 성공 여부에 직접 영향을 주는 중요한 문제입니다. 그런데 델파이나 C++빌더로 이루어지는 많은 업무 프로젝트들에서 이런 원칙이 잘 지켜지지 않고 있는 듯 하더군요.

얘기가 또 이상하게 샌 거 같네요. 제가 글을 쓸 때의 최대의 단점은 본론을 벗어나 엉뚱하게 흘러간다는.. --;;

개발툴을 선택하는 자체의 문제에 있어서는 제가 지난 마이크로소프트웨어 11월호에 기고했던 적이 있구요.
또 이전에도 이 자유게시판에서도 여러번 비슷하게 다룬 적이 있습니다.
http://www.borlandforum.com/impboard/impboard.dll?action=read&db=free&no=3248
http://www.borlandforum.com/impboard/impboard.dll?action=read&db=free&no=4006

마무리하기에 앞서... 주정섭님 글에 댓글로 BloodWolf님께서 쓰시길, 개발툴은 도구일 뿐이라고 하셨더군요. 물론 원론적으로 맞는 말씀입니다. 그런데 현실에는 완전히 그렇지만도 않습니다. 예를 들어 똑같은 언어인 C++을 사용하더라도 비주얼 C++과 C++빌더의 차이는 엄청납니다. 물론 한쪽에서 할 수 있는 일을 다른쪽에서 할 수 없는 것은 아닙니다. 하지만 그 생산성의 차이가 하늘과 땅 차이죠.

또, 현대의 개발툴들은 개발툴만의 독자적인 존재가 아니라 전용의 프레임워크와 함께 존재합니다. 현실적으로 따져볼 때 VCL은 델파이 혹은 C++빌더의 일부이고 MFC는 비주얼 C++의 일부입니다. 마찬가지로 자바에도 J2SE, J2EE, J2ME 등의 기본 프레임워크가 있습니다. 이들 개발툴, 언어를 전용 기본 프레임워크와 떼어내어서 생각할 수는 거의 없죠. 물론 C++에서 가능은 합니다. Win32 API만으로 개발을 한다든지 도스나 콘솔 기반 개발을 한다면 가능은 합니다. 하지만 이것은 현실에서 대부분의 경우 좋은 선택이 아닙니다.

전용 프레임워크와 함께 생각하게 되면 개발툴은 단지 도구이기만 한 것이 아닙니다. 개발자에게 프로그래밍 언어가 하나의 플랫폼이듯이, 전용의 프레임워크도 역시 하나의 플랫폼입니다. 한번 익숙해지면 쉽게 떠나기 어렵고, 또 그 프레임워크의 성능이나 생산성에 개발자의 성능, 생산성이 절대적으로 좌우되어버립니다. 따라서 '개발툴은 도구일 뿐이다'라는 말은, 원칙적으로는 맞지만 현실에서는 오히려 틀린 말에 가깝습니다. 단적으로 말하자면, 비주얼 C++ 개발자들 중에서 C++빌더로 전향하는 개발자가 꾸준히 나오는 이유는 VCL 프레임워크의 뛰어난 생산성 때문이고, 반면 C++빌더의 뛰어난 생산성을 알면서도 비주얼 C++을 떠나지 못하는 개발자가 많은 이유도 역시 MFC 프레임워크에 익숙해졌기 때문입니다. 개발툴에 포함되어 있는 프레임워크가 개발자의 운명을 상당부분 좌우하고 있는 것입니다.

그럼...


주정섭 님이 쓰신 글 :
: 많은 개발자들이 자신의 주종 개발 언어(혹은 툴)을 선택하거나 바꿀 때, 앞으로 자신이 주로 작성해야할 프로그램의 종류와 성격, 문법의 간결성이나 체계성, 현대성, 생산성 등을 파악하여 고르기 보다는, 유행을 따라서 선택한다. 잘라 말해서 "앞으로 이 언어 혹은 툴이 돈 될 거랍니다"란 말에 따라서 결정한다는 것이다. 이는 매우 불행한 선택 방법이다. 현재 가장 유행인 툴 혹은 언어를 선택했다고 해서 개발자로서 밥벌이가 절대로 보장되지는 않는다. 예전 내글에서 여러번 지적했지만 개발자는 어떤 언어를 쓰느냐가 아니라 "어떤 프로그램을 제대로 만들 수 있느냐"가 더 중요한 밥벌이 보장 수단이다.
:
: 처음에는 이 새로운 유행 언어를 선택했다는 덕을 몇번 볼 수도 있을 것이다. 이 나라에는 희안한 개발 관행을 가진 회사들이 있는데, 멀쩡히 현재 업무를 잘 처리하고 있는 프로그램을 시대에 뒤진다는 희안한 이유 하나만으로, 자바나 닷넷같은 신 유행 언어로 다시 만드는 회사들이 종종 있다. 어찌보면 우리같은 개발자 관점에서는 좋은 기회다. 경기가 가뜩이나 안좋아서 신규 개발 프라젝트가 별로 없는 요즘에 이런 돈 낭비하기 좋아하는 황당한 회사들이 있다는 것은 매우 고마운(?) 일이다. 따라서 "요즘 뜬다는 어떤 언어를 나는 쓸 줄 압니다"라는 말로 신규 프라젝트에 참여할 기회를 얻는데 도움이 될 수도 있을 것이다.
:
: 그러나, 확고한 자신의 주종 언어(툴) 없이, 시대 유행을 따라서 이런 저런 툴로 말을 갈아타는 개발자는 조만간 이 업계에서 버티지 못한다. 왜냐하면 여러 언어를 알긴 하지만, 어떤 언어도 깊이 있게 알지 못하고, 겉껍질만 아는 개발자가 되기 때문이다. 어떤 언어도 깊이 알지 못하면서 제대로 돌아가는 프로그램 작성이 가능하다고 생각하는가? 물론, 여러 언어를 모두 잘 사용하는 천재적인 능력을 가진 소수의 개발자들이 있을 수도 있다. 그러나 실제 이런 사람들은 매우 보기 힘들다. 대부분 뛰어난 개발자들은, 몇가지 언어를 동시에 사용하긴 하지만, 자신의 주종 언어 즉 주종 밥벌이 언어를 반드시 가지고 있다. 보조 언어는 주종 언어의 단점을 보완하는 수단으로만 사용한다.
:
: 다시 말해서 성공한 개발자의 대부분은 컴 언어를 연구할 때 "집중과 분산의 원칙"을 어떻게 구사할지 잘 아는 사람들이란 것이다. 불행스럽게도 상당수의 개발자들은 집중의 원칙은 잊어버리고 돈 된다는 말에 따라서 "분산"에만 전념하는 경우를 많이 본다. 사실 나도 예전에 이 분산 원칙만 믿고 주종 언어에 대한 중요도를 망각하여, 힘들게 살았던 시절이 있었다.
:
: 간혹 구인 구직 광고를 보면 기막힌 문구들을 발견한다. 어떤 개발자가 구직란에 올린 자기 소개를 보면, 경력 5년차인데 Java, C++, Delphi, ASP, PowerBuilder 등등의 언어를 능숙하게 구사할 줄 안다고 적혀 있다. 내 경험에 의하면, 정말 천재적인 능력의 소유자가 아닌 한, 한 언어에 전념하여 그 언어를 자신의 주종 언어로 만드는 기간을 최소 3년으로 본다. 나의 이 계산 방식에 의하면 5년간 무려 5가지의 언어를 모두 섭렵했다는 이 개발자는 어떤 언어도 제대로 할 줄 아는게 없다는 것이 나의 결론이다. 만일 이력서에 이렇게 적혀 있다면 나는 거들떠 보지도 않는다.
:
: 반대로 Java, C++, Delphi, ASP, PowerBuilder를 능숙하게 사용할 줄 아는 개발 신입 사원 구함이라는 구인 광고나, 3년차 경력 개발자를 요구하면서 요구 스킬에는 도저히 3년으로는 불가능한 여러 언어와 툴에 대한 스킬을 요구하는 회사도 마찬가지다. 결론인즉 이딴 식의 구인 구직 광고를 하는 개발자나 회사와는 접촉하지 말라는 것이다.
:
: 델파이나 비주얼 베이직 같은 비주얼 툴들이 등장하면서, 개발 과정이 많이 편리해진 순기능도 있지만, 역기능으로 껍데기 개발자들을 매우 많이 산시켰다. 껍데기 개발자들이란 어떤 언어나 툴의 기능 일부 밖에 사용 못하는 개발자들을 말한다. 예를 들어 폼 디자인 밖에 할 줄 모르는 개발자를 말한다. 즉 폼에 콤포넌트를 놓고 속성만 세팅할 줄 알지, 내부 처리 과정은 전혀 못하는 개발자를 말한다. 불행스럽게도 사실 개발자라고 불러줄 수도 없는 이런 개발자들이 도처에 넘쳐나고 있다. 껍데기 개발자의 또 다른 부류로, 화면 디자인과 더불어 입력 화면까지는 만들 수 있지만, 내부 데이타 처리 로직 코드는 전혀 구사못하는 개발자들이 있다.
:
: 얼마전에 타 업체의 소스 하나를 받았는데, 이런 껍데기 소스였다. 무려 6개월간 개발했다는 프로그램의 소스 내용이  어떤 처리 로직도 없고 단순히 입력 폼만 보여주는 코드만 존재했다. 이런 껍데기 개발자들이 도처에 넘쳐나고 있는 이유는 주종 언어 선택에 대한 확고한 판단이 없다는 것이다. 다시 말해서 개발 환경은 주종 언어의 몇가지 기능을 편리하게할 뿐이지, 데이타 처리 로직을 구현하려면 주종 언어에 대한 깊은 이해가 필요하단 사실을 전혀 깨닫지 못한 탓이다. 프로그램은 입력과 처리, 출력 작업으로 이뤄진다는 것을 잘 알 것이다. 이 입력 부분 즉, 화면 밖에 그리지 못하는 개발자들을 과연 개발자라고 할 수 있을 것인가?
:
: 여러 개발자들 게시판에는 질의응답 게시판이 있다. 내 사이트에도 이 게시판이 있지만, 조만간 없애버릴 작정이다. 내가 보기엔 질의응답 게시판은 별로 제대로된 질문과 답변도 잘 없지만, 질의응답 게시판은 초보 개발자들에게 매우 중요한 원칙인, 코딩은 스스로 해야 하며 쉽게할 수 있는 것이 아니다란 사실을 망각하게 만들기 때문이다.
:
: 질의 응답 게시판에 올라오는 상당수 질문들을 보면 내가 느끼는 생각은 이렇다.
:
: "델파이 매뉴얼을 대체 보기나 한 것인가?"
:
: "자신의 밥벌이므로 스스로 짜야할 프로그램을 남한테 짜달라고 할 작정인가? "
:
: "코드는 없고 장황하게 말한 뒤 안 돌아가더라.. 에러좀 찾아주세요.. 내가 귀신인가? 코드도 없고 실행해볼 수도 없는 프로그램을 천재적인 상상력을 총동원해서 에러를 찾아달라는 이야긴가?"
:
: "이렇게 어려운 질문을 한방에 답변해 줄 만큼 시간 널널한 사람이 많다고 생각하고 이런 질문을 올린것인가?"
:
: 해외 사이트를 보면 팁이나 개발에 관한 문서를 제공하는 곳은 많으나 질의응답 게시판은 잘 찾아 보기 힘들다. 개발자는 혼자서 해결하는 능력을 키워야 하지, 남에게 코딩을 구걸하는 방식에 익숙해져 버리면 개발자로서 살아가기 무지 힘들어질 것이다.