델파이, 그 10년의 꿈틀거림

출처 

http://blog.naver.com/PostView.nhn?blogId=tristein&logNo=120135363154

델파이, 그 10년의 꿈틀거림

---

박후선( tristein@hotmail.com / tristein@naver.com)

델파이는 자타 공히 Win32 어플리케이션을 작성하는 최고의 도구로 자리매김하고 있었다. 감히 어느 누구도 그 아성에 도전장을 내밀지 못했다. 국내외 어지간한 어플리케이션들은 거의 델파이로 만들어졌다고 해도 과언이 아니었다. 양과 수준에서 타의 추종을 불허하는 강력한 컴포넌트들이 저격 위치에 자리를 틀고 앉아 추적하는 그림자라도 보이면 바로 헤드샷을 날렸다. 델파이는 적수가 거의 없는 개발 툴이었다.

"델파이는 땅을 기는 굼벵이 위를 유유히 나는 한 마리 용이었다"

집 떠난 아버지와 이복 혼혈 왕자

이복 형제의 탄생

C# - 그 강력한 유전자의 일부는 델파이의 것이다. C#을 처음 접했을 때 필자는 ‘C를 닮은 델파이’라고 나름의 정체성을 부여했다. 그 말이 무리가 아닌 것은 델파이 수석 설계자였던 헤즐스버그가 볼랜드를 떠나 마이크로소프트로 이적한 후 개발한 것이 바로 C#과 닷넷이기 때문이다. C#은 델파이와 자바와 C의 유전자를 모두 물려받은 유전자 조작 수준의 슈퍼 혼혈아였다. 보다 뛰어난 존재의 등장은 델파이의 앞날에 암울한그림자를 드리우는먹구름과 같은 것이었다

"혈통의 순수함이란 강력한 유전자 조합 앞에서는 빛 좋은 개살구에 지나지 않았다."

무모한 도전

믿거나 말거나 그 때까지만 해도 개발 툴로서 델파이는 마이크로소프트가 껄끄러워할 수 있는 수준의 저력을 지니고 있었다. 볼랜드가 델파이에 닷넷을 수용하겠다고 하자 마이크로소프트가 환영의 뜻을 비추던 그날의 기억이 필자의 뇌리에 선명히 남아 있다. 수석 개발자의 이탈과 C#및 닷넷 프레임워크의 등장으로 볼랜드가 느꼈을 위기감을 필자는 충분히 공감한다. 그 위기감으로 닷넷의 지원을 전격적으로 결정하였을 것이 분명하다. 하지만 결론적으로 델파이는 닷넷 프레임워크를 위한 개발도구로 C#의 상대가 될 수 없었다. 한마디로 좌충우돌에무리수였다. 누가 그런 강력한 유전자를 이어 받은 C#을 뒤로 하고 미래가 불안해 보이는 델파이로 닷넷을 개발할 것인가?

결국, 델파이에 닷넷이란 두루마리 안에 양복을 입혀놓은 것 같은 불협화음 그 이상도 그 이하도 아니었다. 의복 고유의 용도를 인정한다 하더라도 델파이는 결국 닷넷의 손을 들어 C#의 가치만 드높인 후 스스로는 말라 시들어 버린 것일지도 모른다. 반면 C#은 굳이 델파이가 손을 들어주지 않아도 성공할 수 밖에 없을 정도로 뛰어난 유전자를 지니고 태어난 존재였다.

"용은 사라지고 그 자리에 점보 제트기들이 날아 다녔다"

대략 난감 델파이 8

필자가 처음 델파이 8을 접하였을 때의 실망감은 이루 말할 수가 없었다. 닷넷의 지원 유무를 떠나 춤을 추듯 느린 반응을 보이는 Object Inspector는 부처도 화병에 걸리게 할 수준이었다. Visual studio를 쫓아 하다가 가랑이가 한 뼘 정도 찢어진 듯한 짝퉁 통합환경은 델파이의 미래에 대해 불안감을 지나 실망감 마저 느끼게 하였고 그 우려는 곧 현실로 다가왔다. 델파이는 점점 도태되어 갔고 개발자들도 눈에 띄게 줄어들었다. 어줍잖게 델파이 8을 내어놓은 것은 볼랜드의 치명적인 실수였다. 델파이 역사상 가장 비참한 참극은 델파이 8의 등장일것이다.

"델파이 8의 등장은 델파이의 쇠퇴를 예견하는 전주곡 같은 것이었다”

쇠퇴하는 왕국

환경의 변화

변하는 것이 없는 듯 익숙하지만 되돌아 보면 많은 변화에 새삼 놀라는 것이 세월이다. 세월의 무자비함은 새로운 동향과 환경에 적응하지 못하는 모든 것을 도태시켜 버린다.

예를 들어 보자. 과거가 지금보다 업무용 어플리케이션을 사용한 업무 효율이 더 높았다고 한다면 믿을 사람이 있을까? 키보드와 단축키로 슈퍼맨 뺨을 칠 정도의 빠른 입력을 통해 업무를 신속하게 처리하는 경리 직원의 쉴 새 없는 손놀림과 화면이 따라오지 못하는 거짓말 같은 속도로 문서를 뽑아 내던 그 옛날의 숙련자들의 노련함은 더 이상 찾아보기 힘든 세상이 되었다.

언제부턴가 모든 사람이 느긋하고 편안하게 마우스를 클릭하고 있다. 어플리케이션들은 마우스를 앞세운 직관적인 시스템으로 대체 된지 오래고 사람들은 별다른 습득이나 숙련의 과정 없이 바로 업무에 투입되어 프로그램을 사용할 수 있다. 대신 전반적인 업무 처리 속도는 느려졌다.

심지어 개발자들 조차 저장이나 컴파일을 위해 마우스로 버튼을 누르는 경우를 심심찮게 본다. 필자는 여전히 키보드를 많이 쓰는 편이지만 그것은 왼손의 몫이고 많은 경우 오른손은 마우스를 잡고 있다. 역시나 생산성은 많이 떨어진다. 마우스는 직관적이지만 숙련을 요구하지도 않고 받아들이지도 않는다. 직관적 사용은 말 그대로 숙달 과정이 필요 없이 바로 사용하는 것이기 때문이다.

이런 현상의 시작점에는 웹의 보급이 있다. 하이퍼링크로 대변되는 웹 화면들은 링크들을 마우스로 누르는 것만으로 대부분의 작업을 완료할 수 있었고 새롭게 컴퓨터를 습득하는 모든 사람들은 마우스 클릭부터 시작했다.

"아득한 옛날, 지금보다 업무를 빠르게 처리하던 숙련자들의 시절이 있었다"

앞서 살펴본 이런 식의 환경 변화는 기존의 상식과 가치를 가볍게 짓이겨 버릴 수 있는 괴력을 지니고 있다. 하지만 환경의 변화에 적응하기 위해 환골탈태하는 과정은 단순한 용기와 의지만으로 이루어지는 것이 아니다. 과거를 버리고 새로운 것을 받아들이는 것에는 매우 지독한 수준의 위험과 희생 및 자기파괴가 요구되기 때문이다. 그런 이유로 기존의 환경에서의 강자가 새로운 환경에 적응하지 못하고 약자가 되는 경우가 많다. 그렇게 새로운 강자가 등장해 세상을 지배하는 동안 밀려난 구시대의 강자는 빛 바랜 역사 속으로 묻혀가는 것이다.

델파이는 오래 전에 이미 구시대적인 완벽함을 완성하였다. 그 완성이 너무 오래되었고 그 오랜 기간 동안 너무나 많은 것을 가지려 하였다. 자신을 허물고 새로운 완벽함을 구축하는 것은 이미 완성을 맛본 델파이로서는 쉽지 않는 도전이다.

델파이는 구시대적 완벽함에 묶인 채 새로운 환경에 적응하기 위해 부지런히 꿈틀거리는 모습만 보여주고 있었다. 결국 그 처절한 꿈틀거림은 쇠잔하는 왕국의 펄럭거리는 깃발 같은 것이었다.

"이미 완벽한 것만큼 불완전한 것은 없다. 변화를 꿈꿀 수 없기 때문이다."

웹 시대의 부적응자

환경이 변하고 웹이 본격화되는 2000년도부터 델파이의 쇠퇴는 시작되고 있었다. 필자는 이때 까지만 해도 델파이를 최고의 개발 툴로 여기고 있었다. 이즈음 델파이도 웹을 위해 많은 시도를 했지만 본격적인 웹 개발 툴로서는 2% 부족한 것이 사실이었다. ISAPI를 위시한 DLL 방식은 그 자체로는 훌륭하였고 필자도 감탄하는 바가 있었으나 넓은 사용자층이 형성되기는 힘들었다. Web Snap등 다양한 시도를 하였으나 필자의 경험상 까다로운 고객의 입맛에 대응할 수 없었다. 실용적인 면에서의 한계를 보여주었다. 자바와 닷넷이라는 강력한 상대 앞에웹 개발 툴로서 델파이의 위상이라는 것은 정말 보잘것없었다.

델파이는 전통적으로 클라이언트의 강자였다. C/S 환경은 물론이고 미들웨어를 이용하는 멀티티어 환경까지 델파이는 애초에 클라이언트 작성에 특화된 듯한 모습을 보이고 있고 그 것이 볼랜드가 부여한 델파이의 주된 정체성이었다. 하지만 웹 시대에 접어들면서 모든 환경이 웹으로 이전되기 시작했다. 웹에도 전통적인 느낌의 클라이언트가 필요하게 되었지만 그것은 자바스크립트를 이용한 AJAX나 플래시의 몫이지 델파이가 발을 들이밀 곳은 아니었다.

지금의 국내의 현실을 보면 자바 개발자가 아니면 명함을 내밀기도 힘들다. 닷넷 조차 웹에서 설 자리를 제대로 확보하지 못하고 있는 상황에서 델파이로 개발하는 웹이라는 것은 언급할 가치조차 없어 보인다. 그것이 현실이다.

"패러다임이 변하였을 때 구시대의 것은 유물이 된다.
유물로 젓가락질 하는 사람은 없다."

태생적 한계와 몸부림

델파이는 개발 툴을 주도하던 명문세도였지만 땅을 떠나서는 살 수 없는 식물적 한계를 지니고 있었다. 땅 - Windows 환경이라는 토양에 뿌려진 델파이는 엄청난 번식력을 보여주며 뿌리를 뻗어 나갔다. 거기다가 컴포넌트 개발자들이 잔뿌리로 자라나 땅을 움켜잡았으니 마치 아바타에 나오는 원주민들의 거주지처럼 거대하고 확고한 자태를 뽐내는 것, 그것이 델파이였다.

하지만, 양분을 제대로 흡수할 수 없다면 뿌리 깊은 나무도 대책 없이 병약해질 수 있다. 허무하게도 그런 일은 델파이에게 일상적인 것이었다. 양분이 되는 각종 SDK가 바로 바로 공급되던 Visual Studio의 풍족한 환경과 달리 델파이 개발자는 해당 SDK의 C++ 버전을 보고 직접 구현하거나 몇몇 개발자가 공급하는 이식 버전에 만족해야 했다. 결국 새로운 버전업에는 속수무책인 채로 방치될 수 밖에 없었다. Windows에서 사용되는 SDK는 볼랜드가 적극적으로 나서서 다루어야 했지만 컴포넌트 개발자들의 수익성을 보장하려는 의도였는지는 몰라도 아무런행동도 취하지 않고 SDK 부재를 방관하기만 하였다. SDK의 부재는 델파이의 사용처를 한정시키는 족쇄의 역할을 하였다. 이에 더해 윈도우의 버전업에 따라 기능이 확장되는 컨트롤들의 경우 하위호환성 유지 때문인지 몰라도 컨트롤의 확장이나 새로운 컨트롤의 추가 등이 델파이에 바로 반영되지 않는 경우도 허다했다. 또한 델파이로 만들어진 어플리케이션의 인터페이스가 XP 이후의 테마 등을 바로 적용하지 못하여 다소 구식으로 보여지기도 하였다. 뒤늦게 XP Manifest를 지원하였으나 버그와 한정된 기능으로 제대로 역할을 못한 것이 사실이다

닷넷의 C#이나 JVM의 자바처럼 자기 땅에 곡식 뿌려먹는 자작농이 아니라 애초에 남의 땅에 소작을 붙여 먹던 델파이는 이렇듯 구동 환경과 라이브러리 자원을 100% 이용할 수 없는 태생적 한계에 직면한다. 화전이라도 일구려는 심정으로 카일릭스(Kylix)라는 도구를 통해 탈 Windows를 시도하였으나 거의 빛을 보지 못하고 사장되고 말았다. 필자에게 카일릭스란 CLX 라이브러리 때문에 Help가 지저분해졌다라는 점과 windows platform에 의존적이라는 Warning의 귀찮음 정도만 기억되는 존재다.

승산 없는 싸움

마이크로 소프트는 Windows 이외의 환경에서는 다른 것과 경쟁해 이겨온 역사가 별로 없다. VB를 통해 자바와 경쟁하려다 결국 시대의 흐름에 역행하지 못해 자바의 손을 들어 주었다. 플래시와 경쟁하기 위해 Silverlight에 힘을 실었으나 아직까지 플래시의 영역을 넘볼 수준은 아닌 것 같다. 아이리버를 손에 들고 이것이 미래라며 아이팟을 의식한 발언을 했던 빌 게이츠의 무안했던 과거도 있었고, iOS 진영 및 안드로이드 진영의 번영과는 달리 여태 별다른 동력을 끌어내지 못하는 윈도우폰도 있다.

하지만, 이렇게 맥없어 보이는 마이크로소프트도 유독 Windows 환경에서는 자기네 앞 마당이라는 어드밴티지를 적극 활용해 상대를 고사시켜 버린다. 처음 나왔을 때 강좌의 샘플 프로그램 수준에 지나지 않아 비웃음의 대상이었던 Internet Explorer – 이렇게 허술해 보이던 상대에게 몇 년간 추격당하다 결국 벌집이 되어 백기를 들었던 Netscape가 있다, 당시에는 경쟁자가 없을 것 같았으나 Office 제품 군에 압사 당해 지금은 흔적도 찾아보기 힘든 수많은 워드 프로세서들과 스프레드시트들이 있다. 그리고 C#과 닷넷을 위시한 Visual Studio에 대항하다심한 내상을 입고 벼랑 끝으로 물러나 몇 년째 칼만 갈아대고 있는 델파이가 있다.

하나의 기술이 한 분야를 차지하고 좋은 시절을 누릴 수 있는 시간은 의외로 짧다. 자금력이 있으면 누구나 뛰어난 인재를 영입할 수 있고, 몇 년의 시간이던 쫓고 쫓아 현재 있는 것 보다 나은 것을 만드는 것은 어려운 일이 아니다. 그런 과정에서 우리가 알던 것들은 사라지고 우리가 모르던 것들이 태어난다.

Windows와 관련된 것이라면 마이크로 소프트와 경쟁해서는 승산이 별로 없다. 델파이도 그 희생양 중 하나이다. 다윗과 골리앗의 싸움은 성경에서나 가능한 이야기다. 역사가 그것을 증명한다. 다윗이 골리앗을 이길 수 있는 유일한 방법은 골리앗만큼 몸집을 키우는 것이다.

"Windows 환경에 국한한다면,
마이크로소프트와 맞대결을 펼쳐 승리한 경우는 거의 없다."

패망의 뒤안길

떠돌이 생활과 개발자의 이탈

지금 델파이의 상황과 입지를 한마디로 표현하면 ‘패망의 뒤안길, 폐위된 왕의 유배생활’ 정도가 적당하지 않을까? 델파이는 C#과 자바라는 발 빠른 후발주자에게 영광스러운 자리는 모두 넘겨주었다. 볼랜드에서 떨어져 나와 따로 살림을 차린 Code Gear라는 초가집 아래 굶주린 흥부 꼴로 여러 개발자들을 자식으로 거느리고 궁핍한 생활을 하더니 자식들이 다 가출해버리자 Embarcadero라는 생소한 타향으로 팔려가는 처지가 되었다.

부러운 옆집 아이

플래시의 약진을 생각하면 정말 통탄할 일이 아닐 수 없다. 플래시는 매크로미디어가 Adobe에 인수되면서 오히려 영광의 길을 걷고 있다. Adobe는 플래시를 가져다가 자바에 버금가는 유전자를 주입하였고 정말 환골탈태를 거듭하여 막강한 개발도구로 자리매김하고 있다. 하기야 잘나가는 것을 더 키우려고 욕심을 내어 흡수하는 것과 버리기 아까워 입에 넣고 우물거려 얼마 남지 않은 단물을 빨아 먹는 행위는 애초에 비교 대상이 아닐지 모른다.

Embarcadero로 흘러 들어간 델파이도 플래시처럼 환골탈태의 길을 걸어 옛 영광의 10분의 1이라도 되찾을 수 있으면 좋겠지만 필자의 개인적인 느낌으로는 델++이나 델# 이라도 나와야 가능한 일일지 도 모른다. 물론 Embarcadero가 비교적 인상적이고 공격적인 행보를 취하고는 있지만 조금 늦은 감이 있다. 델파이를 보며 조치를 취하기에는 늦어 버린 말기 암 환자의 무게를 느끼는 것이 필자만의 노파심이었으면 한다.

컴포넌트 개발자의 부재

더 심각한 문제는 델파이 진영에서 유능한 의사의 역할을 담당하던 컴포넌트 개발자들이 거의 남아 있지 않다는 것이다. 상처를 치료하기는커녕 기댈 언덕도 없어 보이는 것이 델파이다. 델파이는 독특하게 수많은 개발자들이 컴포넌트를 통해 그 명성을 쌓아 올린 개발 툴이었기에 그 저변의 붕괴가 곧 델파이의 붕괴라 해도 틀린 말은 아니다.

델파이 만의 독특한 Call of duty는 지금까지도 델파이 개발자들의 귓전에 메아리 치고 있다. 다시 말해 델파이의 재건에 대한 열쇠는 Embarcadero 보다는 델파이를 아직 놓지 못하고 있는 여러분이 쥐고 있는지도 모르겠다. 다시 컴포넌트 개발이 불붙지 않는 한, 그리고 예전처럼 뛰어난 개발자들이 달라붙지 않는 한 델파이의 재건은 묘연하기만 하다.

"점보 제트기 위로 우주 왕복선이 날아다니는 시절에
누가 아직 날개 찢어진 용을 일컫는가?"

델파이의 미래

자바의 번영과 델파이의 폐허

현재의 리눅스 및 자바 진영의 번영은 과거 델파이 개발자들의 상호 협력이 현대적인 사회주의로 승화한 모습이다. 수많은 개발자들이 든든한 버팀목이 되어 라이브러리를 공급하는 그 찬란한 모습 앞에 델파이 신전의 폐허는 더욱 도드라진다.

하지만, 현재 수백만 원을 호가하는 델파이를 단순히 오픈 소스화 한다고 개발자들이 얼씨구나 하고 달려드는 것은 아닐 것이다. 어차피 델파이 만큼 오픈 된 개발환경은 거의 없다고 봐도 무방하고 그 덕분에 델파이가 한 때 큰 제국을 형성했던 것이다. 결국, 개발자들은 학구열에 불타는 연구생들이 아니라 밥벌이를 해야 하는 칼과 방패를 든 전사들이다. 무디어져 버린 칼과 구멍 뚫려 바람이 들락거리는 방패는 매력적이지 않다.

선택 받지 못하는 도구

더욱 심각한 것은 고객이 델파이를 꺼려한다는 것이다. 필자가 지금 델파이로 개발할 것이라고 고객들(주로 대기업에 속하는)에게 어필하면 바로 퇴짜를 맞는다. 필자는 델파이로 몇몇 프로젝트를 진행해왔고 최근까지도 델파이로 만든 어플리케이션을 납품하여 왔으나 그 때마다 상당한 반대에 부딪혀 왔다. 필자의 배째라 식의 대응이 있었기 때문에 가능했지만, 과연 얼마나 많은 개발자가 고객의 의견에 맞설 만큼 배짱이 두둑할까? 필자 역시 억지로 밀어붙이기는 해도 델파이 개발자가 없어서 유지보수가 힘들다는 데는 그럴싸한 대답이 떠오르지않는다. 필자는 델파이로 개발하려고 마음을 먹으면 Win32 어플리케이션이라고만 이야기하고 개발 툴은 언급하지 않는 편이다.

기는 재주 – 배포의 용이함

얼핏 델파이가 모든 면에서 참패인 듯 하지만 아직까지 딱 한가지 면에서는 C#과 C++ 앞에 으스댈 수 있는 것이 있다면 바로 배포의 용이함일 것이다. C#이나 C++이 델파이와 맞싸움을 벌일 때 아킬레스건으로 작용할 것이 있다면 닷넷 프레임워크와 Runtime 환경이 아닐까 한다. 10년 뒤에는 Visual Studio로 닷넷 어플리케이션을 작성해도 아무도 말릴 사람이 없어질 것이다. 하지만, 지금은 Windows XP라는 질긴 생명력의 노인이 하나 그늘에 버티고 앉아서 닷넷이 뭐냐며 가래침을 뱉어대고 있다. Win32 어플리케이션에서만큼은 아직은 C#을 이용한닷넷 어플리케이션 보다는 델파이가 한 수 위인 셈이다. 간단한 어플리케이션 하나 배포하는데 닷넷을 재 배포하는 Setup을 공급해야 한다는 것은 끔찍한 일이 아닐 수 없다. Visual C++ 사정도 크게 다르지 않아서 항상 Runtime을 Setup에 포함해 공급해야만 한다.

시한부 인생

하지만 10년 정도 뒤에는 지금의 Windows 95처럼 Windows XP도 사용량이 줄어 무시해도 되는 순간이 반드시 올 것이고 그렇게 되면 노른자는 어차피 C#과 Visual Studio의 몫이다. 델파이는 그렇게 무너져 버릴 것이다. 필자도 그쯤이면 델파이를 버릴 것이다. 몇 년 전까지만 해도 일부 코볼 개발자가 밥벌이를 하고 있는 경우가 있었듯 델파이도 그 정도의 명맥은 유지할 수 있을지 모른다. 10년 안에 델파이로 새로 개발되는 어플리케이션은 거의 없어질 것이라는 것이 필자의 생각이다.

"인정하고 싶지 않지만, 10년에 못 미치는 시한부 인생 - 그것이 델파이의 미래다."

델파이 개발자가 가야 할 길

그렇다면 델파이의 수명이 다하면 델파이 개발자는 어찌하는가?

자신감을 가지자. 여러분이 델파이를 능숙하게 다루는 사람이라면 자바와 C# 및 액션스크립트로 옮겨 타는데 전혀 무리가 없다. 필자가 알려줄 수 있는 비밀 하나는 서로 정말 무섭도록 비슷하다는 것이다. 필자는 가끔 델파이를 하는지 C#을 하는지 자바를 하는지 Flash 액션스크립트를 하는지 느끼지 못할 때가 있다. 부작용으로 간혹 델파이를 하다가 블록을 만들 때 begin .. end 대신에 { .. } 를 잘못 사용할 경우가 있을 뿐이다.

"믿어라! 델파이를 확실하게 다룬다면 C#과 자바와 플래시가 거저먹기로 따라온다."

델파이로 할 수 있는 것이라면 C#이나 자바 혹은 액션스크립트나 자바스크립트 등 어떤 언어로든 동일한 것을 구현해 낼 수 있다는 것이 필자의 생각이다. 기억하자. 프로그래머의 수준이라는 것은 언어가 아닌 그 사람의 사상과 안목, 경험과 열정, 그리고 궁극적으로는 명석하고 오차 없는 문제 해결 능력으로 결정되는 것이다. 거기에 라이브러리 기반에 대한 약간의 지식과 불과 하루가 채 걸리지 않는 문법에 대한 이해가 곁들여지는 것일 뿐이다. 프로그래머의 실력이라는 것은 프로그래밍 “언어”에 대한 감각이 높아지는 것이 절대 아니다. 프로그래밍자체에 대한 설계 능력과 구현 능력 및 문제에 대한 노하우가 쌓여가는 것이다. 결국, 자바로 할 수 없다면 델파이로도 할 수 없고 C#으로 할 수 있다면 델파이로 못할 이유가 없다. 그것이 프로그래머의 수준이고 실력이다.

"개발언어나 툴은 말 그대로 도구다. 
잘 들기만 한다면 어떤 칼로도 훌륭한 요리를 만들 수 있다.

관건은 요리 실력이지 칼의 종류가 아니다."

어떤 언어가 최고고 어떤 개발 툴이 최고라는 식의 망상에서 벗어나자. 어떤 것도 옹호할 필요가 없고 어떤 것도 맹종할 필요가 없다. 개발 툴은 우리가 추종하는 대상이 아니라 이용하는 대상이다. 필요에 따라 쓰고 그 결과를 누리면 그만이다.

"우리 아빠가 세상에서 최고라는 애교 넘치는 오해는
초등학교 저학년까지로 충분하지 않은가?”

개발 툴이나 언어 마다 각자의 강점을 지니고 있으니 C#과 자바는 웹이나 서버 프로그래밍을 위해, 액션스크립트와 자바스크립트는 웹 클라이언트를 위해, 그리고 우리가 사랑하는 델파이로는 Win32 어플리케이션을 작성하면 되는 것이다.

"우리가 델파이를 버리지 않는 이유는 델파이가 최고라서가 아니라 
델파이가 아직은 쓸모 있기 때문일 것이다.

델파이 XE 따라잡기

델파이 7 버리기

델파이 8에 실망을 느낀 필자는 이런 저런 이유들 때문에 델파이 7으로 회귀하였던 것 같다. 그 이후 Visual Studio와 C# 그리고 닷넷 개발자로 전향하였고 이어 자바 개발자 및 플래시 개발자로 살아왔다. 최근에 몇몇 개발을 델파이 XE로 진행했지만 여전히 필자에게 델파이는 델파이 7으로만 기억되고 있는 측면이 있다. 필자는 가장 안정적이고 가벼우며 델파이가 델파이 다운 버전이 바로 델파이 7이라고 생각한다.

따라서, 필자가 경험했던 것과 비슷한 느낌을 가지고 아직도 델파이 7을 사용하고, 그것으로 충분함을 느끼는 사람이 있다면 그 생각이 틀리지 않았다는 것을 인정한다. 단지, 델파이 7으로 충분하다고 느끼는 그 사람이야말로 모닥불이 일렁이는 동굴 속에서 자위하고 있는 우물 안 개구리라는 점만 빼면 그렇다. 숯을 짓이겨 물소 그림이나 그리고 있을 그 원시시대의 토인에게 깨어진 돌 조각이 주어졌고 그것만으로 충분히 사냥감을 도륙할 수 있다는데 무슨 말이 더 필요하겠는가? 무지를 통해 어떤 종류의 행복감을 얻고 있다면 그것은 개인의 자에 속하는 부분이며 계몽의 대상은 아니다.

물론 델파이 7이 아직 쓸만한 것이 사실이지만 돌도끼 보다는 활이, 활 보다는 총이 더 효과적인 사냥 도구임을 부정하는 사람은 없을 것이다. 무려 10년의 세월이 흘렀다. 스타크래프트도 아직 하는 이가 있고 윈도우 XP도 아직 쓰는 사람이 있다. 델파이 7도 아직 쓰는 사람이 있다. 그래도 Windows XP가 Windows 7보다 좋고 스타크래프트가 스타크래프트2보다 좋다는 사람은 흔하지 않을 것이다.

"워낭소리 같은 다큐멘터리를 찍고 싶은 것이 아니라면
델파이 7은 이제 쉴 때가 되었다."

델파이는 십 년의 세월 동안 참 많이도 꿈틀거렸다. 근래에는 Rad Studio라는 타이틀 아래 PHP까지 손대고 있으니 생존을 위한 그 처절한 꿈틀거림에 찬사를 보내지 않을 수 없다. 이런 저런 형태로 델파이 XE에는 생존을 위한 치열한 몸부림의 흔적이 10년의 나이테만큼 두텁게 녹아 있다.

새로운 치즈를 찾아서

델파이 7을 쓰다가 델파이 XE를 처음 접하면서 여러분이 가지게 되는 생각은 필자가 가졌던 생각과 크게 다르지 않으리라 본다.

•   용도를 알 수 없고 별로 알고 싶지도 않는 컴포넌트들이 잔뜩 들어있다.
•   개발도구가 한창에 엉겨 있어서 불편하다.
•   컴포넌트 팔레트는 어디 있는 것인가?
•   뭐가 바뀐 건지 똑 같아 보인다.

필자의 이런 의구심은 곧 해소가 되었다. 이런 선입견은 이해의 부재와 귀찮음에서 온다. 결국 적응의 문제인 것이다

선입견을 가지고 왜 델파이 XE로 갈아타야 하는가라는 의문을 가지는 사람에게 필자가 말할 수 있는 다른 동기 하나는 흐리지 않는 물은 썩는다는 것이다. 도태란 별 것이 아니다. 자리에 앉아서 단물이 빠져 향만 남은 것을 아직도 빨고 있는 것이 바로 도태다. 창고에 한 가득 치즈가 쌓여 있더라도 새로운 치즈를 찾아 나서지 않으면 그 치즈는 언젠가는 바닥을 보인다. 치즈가 바닥나고 나서는 다른 치즈를 찾을 시간적 여유를 가지지 못하고 굶어 죽을지 모른다. 적당히 배를 불렸다면 새로운 치즈를 찾아 나서야 한다.

"허물을 벗지 않는 애벌레는 나비가 되어 날아 오를 수 없다. 
안락은 때때로 그렇게 독이 되기도 한다."

구분 안가는 성형 미인들의 세상

십 년의 세월 동안 델파이가 제자리에 주저앉아 있지는 않았다. 몇 년간에 걸쳐 제법 재미 있는 일들이 델파이에 일어나고 있다. 후진들에게 적잖이 영향을 준 델파이가 이제는 반대로 C#과 자바의 유전자를 흡수하고 있는 것이다. 처음 C#이 델파이와 자바를 따라 하였고 세월이 변하자 델파이가 그런 C#을 따라 하는 형국이다. 델파이가 C#이나 자바를 따라 하고 있는 몇 가지 예는 다음과 같다.

•  IDE가 Eclipse나 Visual Studio의 그것과 닮아 간다.
•  Windows 7과 관련된 각종 컨트롤 지원
  (Ribon, Dialog, Button, Listview, TreeView, BalloonHint, CategoryPanelGroup, CategoryButtons, TrayIcon)
•  자바에서 볼 수 있던 for ... in … do 루프가 지원된다. (2005)
•  C#에서 처음 도입되고 자바에서 따라 했던 Refactoring을 델파이가 지원 (2005)
•  C#과 자바처럼 전격 유니코드 채용 (2009)
•  Generic (List등의 Collection에 들어갈 종류를 한정함)이 지원된다 (2009)
•  자바나 C#에서나 보이던 Collection 지원 List, Dictionary(해시테이블) 등
•  파일 관리를 위한 클래스 지원 - TDirectory, TPath, TFile (2010)
•  여러 파일에서의 검색 지원 (프로젝트에 속한 모든 파일에서 검색함)
•  소스의 변경에 대한 History가 관리된다.
•  연산자 오버로딩 지원

이런 저런 노력 끝에 델파이는 이제 XE 무렵에 와서는 최신의 동향과 유행에 뒤쳐지지 않은 살아 있는 개발 툴에 속한다. 개발 언어들은 스스로 진화하면서도 서로 모방한다. 좋은 점이란 좋은 점은 서로 주고 받으며 흡수해 놀랍도록 닮아 있다. Delphi, C#, 액션스크립트 모두 같은 언어 구조에 같은 라이브러리를 쓰고 있다. 이제 이들 언어들의 최신 버전은 서로 다른 외국어가 아니다. 기껏해야 방언들에서 느낄 수 있는 정도의 차이만 존재한다.

"다들 같은 모양으로 성형하는 이런 훈훈한 분위기 속에
잡스 형님 집안의 고명딸은 예외로 제쳐 놓자,
그 집안에서 독특한 가정 교육을 받은 Objective-C는
갈라파고스 군도에서 독자적으로 자라난 외계 언어에 가까운 모습이다."

비록, 개발 툴의 차이는 확연하지만 프로그래밍의 근간에 코딩이 있고 그 코딩 상의 라이브러리나 언어 구조가 유사하다면 확실히 상호 적응하기가 더 쉬울 수 있다는 것이다. 부작용이 있다면 서로 너무 비슷해 가끔 독특한 방언적 차이를 헛갈려 하는 정도일 것이다. 이렇게 다들 닮는 이유는 서로 최신의 동향에 대해 민감하게 반응하기 때문이다. 다행히 델파이의 패션 감각이 둔하지 않다는 것이 위안이라면 위안이겠다.

심장은 뛰고 있다

현재까지도 델파이는 자신이 뿌리를 박고 있는 토양 - Windows의 변화에 나름 빠르게 대응하는 모습을 보여주고 있다. SDK의 부족은 여전하지만 많이 노력해 주고 있는 것이 사실이다. 이런 발 빠른 대응의 몇 가지 예를 들어보자.

•  Direct 2D 지원
•  Windows 7과 관련된 각종 컨트롤 지원
  (Ribon, Dialog, Button, Listview, TreeView, BalloonHint, CategoryPanelGroup, CategoryButtons, TrayIcon)
•  윈도우 테마와의 연동
•  Inline 지원 (procedure나 function이 호출되는 것이 아니라 코드가 직접 복사되는 형태)
•  Cloud Computing 지원(Windows Azura, Amazon EC2)

실제 이런 것들이 크게 쓸모 있는 것들이 아닐지 몰라도 부단한 노력을 기울이고 있다는 점에서 왠지 안심이 된다.

자, 지금부터 우리는 델파이7에서 델파이 XE까지의 시간을 KTX 운행속도의 10배쯤 되는 속도로 질주해 따라잡을 것이다. 10년의 변화를 강좌 몇 회로 다루는 데는 아무래도 무리가 따를 것이다. 지금은 완벽한 이해보다는 어떤 것이 바뀌었구나 라는 정도의 감을 가지는 것이 목표다. 무엇이 변했는지 정도는 머리에 넣어두어야 한다. 우리가 모르는 것을 사용할 수는 없다. 알고 있어야 나중에 이곳 저곳을 뒤져서라도 사용할 수 있는 여지가 있기 때문이다.

[공지] 죄송하게도 제가 최근 프로젝트의 영향으로 델파이를 만지지 못하고 있습니다. 델파이 XE3가 나온 시점까지 본 강좌를 연재하지 못해서 대단히 죄송하게 생각합니다.

이 강좌를 진행하면서 구세대적인 방식을 탈피해 모던한 인터페이스를 구성할 수 있는 강력한 컴포넌트까지 작성하고 있었고 이어지는 강좌에서 다룰 예정이었으나 필자가 WPF를 보고 말았습니다.

필자는 요즘 윈도우즈 프로그램 개발에 Visual Studio의 WPF(Windows Presentation Foundation)와 C#을 이용하고 있습니다. 하드웨어 가속에 장치 비의존적 좌표 및 애니메이션까지 지원되는 WPF의 강력한 확장성을 한번 맛보고 난 후 델파이로는 더 이상 개발을 하기가 싫어집니다.  WPF에서는 델파이 수준의 컴포넌트도 작성이 가능합니다. 필자는 앞으로 Delphi를 놓고 Visual Studio로 넘어갑니다. 이제는 그래야할 시점이 온 것 같습니다.

[출처] 델파이, 그 10년의 꿈틀거림|작성자 트리스틴