어드민 6월 13일, 2022에 포스트됨 공유하기 6월 13일, 2022에 포스트됨 LearnDelphi.org에 게시된 "WHY I KEEP CHOOSING DELPHI"를 번역한 글 (번역 최종 업데이트 일자: 2022년 6월 13일) 터보 파스칼을 일찍 배우면서 나는 베이직과 배치 파일 프로그래밍에서 벗어나서 개발자로서 한 단계 크게 도약했고 개발 전문가로 성장하기 시작했다. 델파이가 나왔을 때는 정말 끝내준다고 생각했고 바로 사랑에 빠졌다. 다른 언어나 도구를 배우는 데에는 관심이 없었다. 델파이는 무엇이든 할 수 있었고 훌륭했다. 어느새 나는 수많은 작업을 하고 있었고, 관심있는 것들을 충분히 잘 했다. 다른 프로그래밍 언어에 대해 학문적인 호기심이 생기자, 나는 Assembly 에서 진행되던 야간 학교 과정을 수강했다. C와 C++는 이때 살짝 알게 되었다. 루비(아직 유행하기 전이었다), 자바, 자바스크립트 등등도 들여다 봤었다. 결국 어느 때 부터인지 나는 리눅스 플랫폼에서 C/C++/COM이 한데 어우러져서 작동하는 레이저 프린터를 디버깅하면서 몇년을 보내고 있었다. 그후 나는 다시 전업 델파이 개발자로 돌아갔다. 하지만 새로 들어간 회사는 “델파이 개발자가 충분히 있지 않다”라는 근거 없는 항간의 이야기를 믿고 C#과 WinForms로 전향을 결정했다. 우리는 C# 개발자를 즉시 채용할 수 있었는데 알고 보니 그들은 델파이 경력이 C#보다 더 많았다. 그들은 “델파이 개발자를 찾는 곳이 없다”는 근거 없는 말을 믿고, 자신들에게 C# 개발자 타이틀을 붙였던 것이다 (일종의 순환 인수 또는 자기 실현 예언이다. 즉, 잘못된 믿음을 시작함에 따라 잘못된 결론에 도달하고 그 결론으로 인해 처음의 잘못된 믿음이 다시 확고해지는 현상). 결국, C#으로 진행된 프로젝트는 당연히 끝내야 할 기간보다 4배나 더 오래 걸렸다. 개발자도 더 많이 투입되었고, 도구도 더 최신이었는데도 말이다. 정말이지 그 회사는 델파이를 유지하는 것이 더 옳았다. 나는 온종일 델파이 개발 만 할 수 있는 곳으로 옮겼는데, 얼마 후 그 회사는 C#과 실버라이트가 미래라고 믿었다. 나는 C# 경력이 있었으므로, 그곳에서 실버라이트로 프론트엔드를 새로 구현하는 작업을 시작했다. 백엔드와 데스크탑 앱은 그대로 델파이 (그리고 약간의 C++)로 유지되었다. (만약 아직 기억하는 사람들이 있다면) 결국 실버라이트가 어떻게 되었는지는 잘 알것이다. 그 후 난 완전히 다른 곳들로 뻗어 나갔다. C#, 자마린, 자바, 자바스크립트, 오브젝티브C, (당시에 델파이 프리즘으로 불리던) 옥시즌, 등등을 사용하여 많은 작업을 했다. 그 중에는 델파이 작업 역시 여전히 있었다. 안드로이드 개발을 자바로 하는 강의와 워크샵에서 가르치기도 했다. 그러면서 나는 각각의 장점, 강점, 특성에 대해 이해하는 법을 배웠다. 그리고 내가 좋아했던 모든 것들(오브젝티브C는 그 정도 까지는 아니었지만)에서 뭔가를 알게 되었다. 그때부터 나는 개발자의 스킬 (기술과 실력) 대부분은 언어, 도구, 플랫폼 영역을 넘나든다는 점을 알게 되었다. 여러가지 언어를 알고 있고 또 사용하는 것은 그만한 가치가 있다. 각 언어의 기본 요소들을 알고 있으면, 다른 언어로 작업할 때에도, 긍정적인, 영향이 있다. 문제를 다른 방식으로 바라볼 수 있도록 해주기 때문이다. 프로젝트, 플랫폼, 문제들 중 몇몇은 각자에게 가장 적합한 프로그래밍 언어나 도구가 따로 있기도 하다. 예를 들어 웹 작업을 한다면 적어도 자바스크립트, HTML, CSS (뒤에 두개는 프로그래밍 언어라고 할 수는 없지만)를 어느 정도 알아야 한다. 추상화된 계층을 사용한다고 해도 마찬가지이다. 이 모든 과정을 거치면서, 개인 프로젝트를 할 때에 나는 여전히 델파이를 선택하곤 했다. 가끔 개인 프로젝트에서 다른 도구와 언어를 시도하는 경우도 있었는데 그것들을 좀 더 알고 싶다는 이유 때문이었을 뿐이고, 일반적인 목적의 프로젝트 대부분에서 델파이는 나에게 여전히 더 좋은 해결책이었다. 나를 델파이로 계속 돌아오게 한 델파이의 대표적인 특징은 일반적인 공통 작업이 정말 정말 쉽고, 그 밖의 작업 역시 간편하면서도 못하는 것이 없다는 점이다. 생산성에 주력하는 다른 도구들을 사용하면, 일부 단위 작업을 델파이만큼 쉽게 할 수 있다. 하지만 정해진 작업 수준 이상 또는 "이상적인" 상황에 도달하기가 어렵거나 불가능하다. 반면에, 범용 도구에는 일반적인 상황을 최적화하기 위한 장치가 없기 때문에 간단한 작업 하나를 할 때에도 필요 이상으로 복잡하다. 이제 멀티-플랫폼 개발 능력까지 갖추게 되면서, 델파이는 어느때 보다 더 중요해졌다. 델파이와 파이어몽키 방식은 일반적인 작업 대부분을 빠르고 쉽게 하면서도, 각 플랫폼의 모든 API와 기능에 접근할 수 있다. 내가 아는 한 써드-파티 컴포넌트 시장을 진정 처음으로 고안한 것은 델파이다. 처음부터, 델파이 안에는 VCL 소스 코드 전체가 들어있었고, 견고한 오픈툴스 API와 컴포넌트 모델이 들어 있어서 다른 사람들이 쉽게 개발 환경을 확장하고, 재사용 할 수 있는 컴포넌트와 라이브러리를 만들 수 있었다. 델파이 기술 파트너 모두가 내가 델파이를 선택하는 이유의 큰 부분이다. 또한, 델파이는 우리가 개발자로서 개발하고 있는 코드에 대한 보장을 상당히 잘 한다. 나는 꽤 많은 소프트웨어 개발 조직에 참여한다. 개발자들을 만나다 보면, 자신들이 사용하는 도구의 새 버전을 사용하기 위해 코드 이식을 겨우 끝냈다는 불평이나, 델파이가 아닌 프로그래밍 언어나 프레임워크에서는 새 버전이 나올 때 마다 코드가 깨진 다는 이야기를 듣는 경우가 흔하다. 종종 기존 코드를 아예 모두 버리고 새로 작성해서 새 버전을 지원하는 경우도 있다. 델파이도 물론 완벽한 것은 아니라서, 버전 간에 호환성이 지켜지지 않거나 변경으로 인해 기존 코드가 깨지는 경우가 있다. 하지만 델파이는 지금껏 내가 본 어느 다른 언어나 플랫폼보다 이런 면에서 훨씬 더 좋다. 인용하기 “시작할 때는 내가 아는 게 델파이라서 선택했다. 지금은 델파이가 어느 다른 것보다 작업을 더 잘 할 수 있게 해주기 때문에 델파이를 선택한다. 델파이가 개발할 때 더 빠르다는 사실은 좋다. 하지만 그것은 일부에 불과하다. 내가 쓰고 다니던 모자에는 “델파이는 모든 것을 한다. 특히 윈도우 라면!”이라고 적혀있다. 당신은 델파이를 왜 선택하는가? 그 이야기를 주석으로 남겨주거나 블로그에 #WhyIChooseDelphi 태그를 달아서 적어주면 좋겠다. 인용하기 이 댓글 링크 다른 사이트에 공유하기 더 많은 공유 선택 사항
Recommended Posts
이 토의에 참여하세요
지금 바로 의견을 남길 수 있습니다. 그리고 나서 가입해도 됩니다. 이미 회원이라면, 지금 로그인하고 본인 계정으로 의견을 남기세요.