혹자들은 관록있는 개발자라면 개발툴에 연연하지 않아야 한다고 하지만, 사실 이말은 귀신 씨나락 까먹는 소리나 다름 없다. 주변에서 내가 아는 뛰어난 개발자들은 C, C++, Power Builder, Visual Basic 이든 뭐든 간에 자신의 주종 밥벌이 언어(툴)를 가지고 있는 사람들이었다.

하나의 개발툴을 능수능란하게 다룰 수 있는 경지, 즉 의뢰자가 원하는 화면과 기능을 구현할 수 있는 정도의 수준이 되려면 상당한 개발 경험이 필요하다. 1부터 100까지 더하는 아주 간단한 프로그램이라면 몰라도, 매우 복잡한 기능을 가진 프로그램을, 두개 이상의 언어(툴)로 완벽하게 구현하는 사람을 나는 지금까지 본적이 없다. 아직은 내가 진정한 고수를 만나지 못했는지도 모르지만, 두개 이상의 언어를 완전히 자유자재로 구사할 수 있는 사람은 고수가 아니라 천재에 속하는 사람들이다. 아시다시피 고수와 천재는 전혀 다르다. 고수는 노력으로 이룰 수 있는 경지지만, 천재의 경지는 일반 사람이 쉽게 이룰 수 없는 경지다.

종종 자신이 3가지 이상의 개발툴을 자유자재로 다룰 수 있다면서 자기 실력을 자랑하는 개발자들을 본다. 그러나, 실제 이야기를 해보면 이런 인간들은 십중팔구 허접들이다. 자조스럽지만, 우리 분야만큼 허접들이 많은 분야가 또 있겠는가? 만일 어떤 개발자가 시샵도 귀신, 자바도 귀신, 델파이도 귀신이라고 자부한다면, 어느 것도 제대로 사용할 줄 아는게 없는 허접이라고 보면 십중팔구 거의 정확하다.

당연하지만, 별로 천재도 아닌 내가 지금까지 이 바닥에서 개발자로서 살아 남아 있을 수 있었던 이유는, 개발툴에 대한 현명한 선택 때문이었다고 생각한다. 초창기 도스 시절에 주종툴은 클리퍼였으며, 지금 윈도우 시대에는 델파이가 나의 주종툴이다. 여러 사람들이 인정한 바지만, 이 두 툴 모두 엄청난 개발 생산성을 가진 툴들이다. 그런데, 내가 운이 좋아서였던 현명해서였던 간에, 이 두 툴의 엄청난 개발 생산성을 대체 내가 어떻게 간파할 수 있었을까?

그 당시에는 몰랐지만, 나는 본능적으로 이 두 툴의 공통적 장점인 막강한 화면 처리 능력을 알아봤던 것이다. 클리퍼는 당시 대세 언어였던 코볼에 비해서, 화면 출력과 프린터 출력 기능 모두에서 월등히 뛰어난 툴이었다. 마찬가지로 델파이는 화면 출력과 프린터 출력에서 매우 뛰어난 언어이다. 가장 최신이라는 C#에 비해서도 델파이가 화면처리 즉 GUI 쪽에서는 더 뛰어나다고 나는 생각한다.

주로 클라이언트 프로그램을 많이 짜는 나로서는 화면 처리가 매우 중요한 요소임을 잘 알고 있었고, 본능이든 설레발이든 간에 두 툴의 뛰어난 화면 처리 능력을 간파했고 그 때문에 선택했던 것이었다.

혹자는 프로그램은 화면빨(GUI)의 현란함에 의존해서는 안된다라고 말하지만, 이 역시 귀신 씨나락 까먹는 소리이며, 실제 프로그램은 화면빨이 매우 중요하다. 믿거나 말건 간에, 도스에서 윈도우 3.1, 윈도우 95, 윈도우 엑수피 등등 이런 오에스 버전업에서 가장 중요한 요소 중 하나가 화면빨의 발전이다.

실제로 오감 중에서 인간이 가장 의지하는 감각이 시각이며, 당연히 화면빨은 프로그램에서 중요한 요소 중의 하나이다. 그렇다면 화면 처리 기능이 뛰어난 개발 툴은 당연히 생산성이 뛰어나다는 결론이 나온다. 왜냐하면 인정하던 말던 간에 화면 처리에 필요한 코드량은 엄청나기 때문이다. 델파이로는 거저 먹기인 화면 처리 기능이 비주얼 씨 뿔뿔로는 엄청난 노가다 코딩을 해야 된다는 사실을 아시는가?

혹시 내말을 기능은 엉망이고 버그 투성이지만, 화면빨만 화려하면 좋은 프로그램이고 잘팔리는 프로그램이란 말로 오해하지는 마시라.  만일 그렇게 단순하게 생각했다면 귀하는 개발자 생활을 때려 치우고 조속하게 다른 직업을 알아봐야 한다.

지난번에 이야기했지만, 개발툴을 선택할 때 대세가 중요한 것이 아니라, 본인이 앞으로 만들 프로그램을 얼마나 신속하게 만들어줄 수 있는 툴인가가 더 중요하다고 했다. 시샵이든 자바든 간에 껄쩍거릴 수 있다가 아니라 제대로 동작하는 프로그램을 신속하게 코딩할 수 있어야 살아 남을 수 있다는 것이다.

자! 그렇다면, 앞으로 본인이 개발할 프로그램이 화면 처리 기능이 중요한 기능인지 면밀하게 판단해볼 필요가 있고 그에 따라서 개발툴을 선택해야 한다는 것이다. 직접적인 화면 처리 기능이 필요 없는 프로그램이라면, 즉 웹이나 어플 서버같은 것이라면, 자바나 php같이 화면 처리 기능이 미미한 툴을 선택해도 아무런 문제가 없다.

그러나 주식 분석 프로그램같이 매우 복잡한 화면 처리 기능이 필요한 프로그램이라면, 과연 php나 자바로 쉽게 해결할 수 있을까? 화면 처리 기능은 개발에서 의외로 시간을 많이 깨어 먹는 부분이다. 이 부분의 코딩량을 절대로 간과하면 안된다. 이는 타 언어로 작성된 소스를 다른 언어로 변경할 때도, 화면 처리 코딩 부분은 새로 짜는게 나을 만큼 거의 불가능에 가깝다. 차라리 1부터 100까지 더하는 식의 순수 알고리즘 쪽은 파스칼에서 C로 혹은 그 반대로 컨버전하는 것이 월등히 쉬운 편이다.

혹자는 델파이의 화면 처리 기능이 우수함은 잘 알지만, 프린터 출력 기능은 다른 툴에 비해서 델파이가 한참 후지다라고 생각할지도 모른다. 특히나 파워빌더의 데이타윈도우 기능을 사용해본 사람이라면 델파이의 리포트 기능이 매우 후지다고 생각할 것이다. 그러나, 믿거나 말거나 델파이는 이미 엄청난 프린터 출력 엔진을 탑재하고 있다. 못 믿겠으니, 근거를 대어 보라고? 델파이용 모든 출력 콤포넌트, 혹은 리포트 툴들은 모두 델파이로 만들어진 것들이다. 유명한 Report Builer이건 RAVE이건, 심지어 다소 후진 퀵리포트던간에 모두 순수 오브젝트 파스칼로 만들어진 출력 엔진들이다. 국산인 Object Printer도 역시 델파이로 작성된 것으로 알고 있다.

이런 뛰어난 상용 프린터 출력 콤포넌트들이 모두 델파이로 만들어진 것임에도 불구하고, 델파이는 프린터 출력 기능이 미미하다고 할 수 있겠는가? 왜 델파이는 프린터 출력 부분에서 후지다고 생각하는 것일까? 사실 심지어 나 조차도 델파이에는 이미 막강한 프린터 출력 엔진을 탑재하고 있음을 간과, 사실 무시하고 있었다가 맞는 표현일 것이다. 

그 엔진은 믿거나 말거나 TPrinter이다. 혹자는 이 TPRinter을 노가다성 출력 엔진이라고 생각할지 모르지만, 가장 빠르고, 가장 다재다능한 프린터 출력 엔진이다. 지금까지 다른 프린터 출력 콤포넌트들의 위장에 속아서 이 TPrinter의 위력을 파악하지 못했을 뿐이다.