And Now NET Framework.
눈치 빠른 사람들은 이미 짐작했겠지만, 마지막 이야기는 닷넷이다.
C#이 주종툴인 회사에 입사해서, 이 회사 개발팀을 델파이팀으로 바꿀지 아니면 내가 시샵을 배워야할지 고민하다, 새로운 툴이나 한번 배워보자 하는 마음으로, 닷넷을 연구하기 시작했다. 정확히 말하자면 .NET Winform C# 개발환경이다. 그냥 줄여서, 여기서는 닷넷 시샵이라고 부르겠다.
호랑이 담배피던 시절에, 델마당에 내가 올렸던 글에서 적었듯이, 과거에 나는 닷넷에 대해서 매우 비판적 이었다. 닷넷의 런타임 환경도 싫고, 실행 속도도 느릴거 같고, 당시에 델파이 광신도였던 나에게, 닷넷 개발 환경은 별로 였다. 실제로 초기 닷넷은 매우 별로 였다. 그러다, 최근에 닷넷 시샵을 사용해보니, 와우! 닷넷이 발전을 해도 어마어마하게 했다.
예전에 델파이 IDE가 비주얼 스튜디오보다 훨씬 좋았던 적이 있었다. 그때는 통합개발환경은 역시 볼랜드란 말이 있을 정도였다. 그러나, 이제는 완전히 상황이 뒤집어 졌다. 비주얼 스튜디오가 델파이 IDE 보다 훨씬 좋다. 델파이 IDE는 비주얼 스튜디오에 비하면, 기능적으로 너무 초라하다. 노트패드 같은 순수 문서편집기로 코딩을 해본 사람들은, IDE가 얼마나 편리하고 중요한 존재인지 뼈저리게 알 것이다. 비주얼 스튜디오는 리팩토링, 소스 추적과 분석, 디버깅, 프로파일링 등등 모든 면에서 델파이를 압도한다.
현재 시점에서 비주얼 스튜디오가 델파이보다 훨씬 뛰어나다는 것은, 그냥 잠시 사용만 해보면 바로 알 수 있다. 델파이 IDE가 그동안 얼마나 뒤쳐졌었는지를 바로 느낄 수 있다.
시샵 언어와 닷넷 프레임 역시 그동안 매우 발전했다. 닷넷을 지원하는 오픈 소스나 툴 역시 델파이보다 훨씬 많다. 닷넷 기능 중 매우 마음에 드는 것은, Entity Framework, Data Binding, LINQ, Lamda, yield return, async/await, Task 라이브러리 등등인데, 이 기능들은 다소 복잡해 보이는 기능을 아주 간단하게 구현할 수 있게 해 준다. LINQ는 정말로 혁신적이다. 이는 inline sql 같은 놈으로 볼 수 있는데, 프로그램 소스 안에 바로 SQL 문을 삽입하는 기능과 더불어서, SQL 쿼리 문을 혁신적으로 단순화 시킨다.
async/await는 복잡한 멀티 스레드 처리를 아주 단순화 시킨다. 닷넷 시샵의 괜찮은 기능들을 열거하자면 끝이 없을 것이다. 결론적으로 말해서 닷넷 시샵은 델파이에 비해서 코딩량을 엄청나게 줄여 준다. 동일한 기능을 구현할 때, 닷넷 시샵은 델파이보다 거의 반이하로 코딩량이 줄어든다.
닷넷 시샵은 Winform, WPF, UWP 등 여러 UI 프레임웍을 제공한다. 이중 Winform의 델파이 VCL을 단순히 시샵용으로 바꿨다고 해도 무방할 정도로 VCL과 비슷하다. 닷넷 시샵은 거의 델파이와 비슷한 폼디자인 환경을 제공한다. 따라서 폼디자인 작업이 매우 쉽다.
처음에 나는 닷넷 시샵이 실행속도가 느리지 않을까 걱정했었다. 그러나 이것은 기우였다. 처음 로딩할 때 델파이 실행파일보다 좀 느린 느낌은 있었지만, 닷넷 실행파일은 일단 실행이 되면 매우 빨랐다. 이 회사 프로그램 대부분이 기계장비 신호를 처리하는 프로그램이라서, 실행속도가 느려서 문제가 되지 않을까 걱정했는데, 결코 그런 일은 없었다.
장비신호 처리때문에, 상당수 코드가 멀티 스테드에서 돌아가야 하는데, 닷넷 시샵은 async/await와 Task 라이브러리 때문에 그 처리가 매우 쉬웠다. 화면 갱신 속도가 느리지 않을까 걱정했는데, 델파이보다 화면 갱신 속도가 더 빠른거 같다. 이는 정확히 테스트해 본게 아닌, 나의 개인적 느낌이기에 단정을 내리긴 그렇다.
정말 다행인 것은 델파이 시절에 내가 애용했던 DevExpress 사의 GridControl이 닷넷에서도 있다는 것이다. 희안하게도 DevExpress Grid는 델파이보다 시샵의 것이, 월등하게 기능이 막강하고 더 빠른 것 같다.
어차피 닷넷은 런타임 환경이기에 배포에 불편함이 있고, 소스를 감추기 힘들고 등등의 고질적 단점이 있다. 그러나 닷넷 시샵의 코딩량 적음은 그 모든 것을 압도한다. 혹자는 코딩량이 적으면 대체 뭐가 좋은가라고 하는데, 코딩량이 많으면 많을 수록, 디버깅할 것이 많으며, 실수 또한 많아 진다. 또한 코딩량이 많으면 많을 수록 유지보수가 힘들어진다.
객체지향, LINQ, Lambda 등 현대 언어의 새로운 기능 대부분이, 이 코딩량 줄이기를 위해서 만든 개념이라고 해도 과언이 아니다. 따라서 나는 코딩량 줄이기는 매우 중요하다고 생각한다.
여담으로, 이런 식으로 코딩하면 좋겠다고 생각했는데, 문법적인 제한으로 인해서, 델파이에서는 구현이 힘든 것들이 있었다. 그런데 시샵에서는 왠간해서는 이런 문법적 제한을 잘 느낄 수가 없다. 시샵은 현대 프로그래밍 언어의 왠간한 문법은 대부분 지원하기 때문이다. 예를 들어, 다음과 같이 어떤 버튼을 클릭할 때, 두개 이상의 메서드를 동시에 실행하도록 이멘트를 설정할 떄이다.
SomeButton.OnClick += MethodOne();
SomeButton.OnClick += MethodTwo();
아시다시피 델파이에서는 이것이 안된다. 나는 이 기능을 델파이에서 구현하려고 매우 생노가다들 한적이 있었다. 당연스럽게도 시샵에서는 이런 밀티캐스트 이벤트 구현이 그저다. 델파이에서 함수 포인터 선언은 매우 짜증난다. 시샵의 함수 포인터 선언은 델리게이트라는 문법을 사용해서 델파이보다 훨씬 더 직관적이고 쉽다.
그 이외에도 uses 문의 짜증남과 번거로움, namespace 문법의 미지원 등등, 오브젝트 파스칼은 현대 언어들이 당연히 지원하는 상당수 기능들이 빠져있다.
델파이는 웹 개발기능이 거의 없다시피 하지만, 닷넷은 매우 훌륭한 웹 개발 기능이 있다. 자바스크립트를 전혀 사용하지 않고, 간단한 HTML과 시샵 코드만으로 웹 페이지를 구현하는 기능이 있다. 웹 개발할 때 ajax니 angular 같은 자바스크립트 라이브러리를 익힐 필요가 없다는 것이다.
혹시나 델파이의 대안을 찾고자 하는 개발자라면 닷넷 시샵을 연구해보라고 감히 권하고 싶다. 닷넷 윈폼은 델파이 VCL과 매우 유사하므로 비교적 쉽게 적응할 수 있다. 내 경험에 따르면, 그 개발툴의 언어, 즉 C#이나 C++ 자체는 배우기가 비교적 쉽다. 그러나, 그 툴의 프레임웍 라이브러리(VCL, Winform 등등) 사용법을 배우는 것이 더 힘들고 어렵다. 닷넷 윈폼은 다른 UI 프레임웍에 비해서, 델파이 개발자들에게 학습 부담이 훨신 덜하다.
두고 봐야할 문제이긴 하지만, 닷넷은 곧 Core 라는 프레임웍으로 멑티 플랫폼을 지원할 예정이다. Core 3.0 이 제대로 나온다면, 닷넷의 고질적 문제였던 배포 편의성과, 멀티 플랫폼(OS) 지원에서 획기적인 것임이 분명하다. Core 3.0이 성공한다면, 닷넷에서 단일 실행파일 배포와, IOS, 안드로이드, 리눅스, 윈도우 동시 지원이 가능하게 될 것이다.
결론적으로 기존 델파이 프로그램 유지보수 때문에 너무 일이 많은 상황이 아니라면, 닷넷 시샵을 시간을 내서 공부해 보기를 권하고 슆다. 델파이는 과거의 잔재인 Win 32 API와 GDI 에서 별로 발전하지 못했지만, 닷넷 시샵은 그렇지 않다는 것이여, 현시점에서 델파이보다 훨씬 더 많은 오픈 소스와 확장툴들이 닷넷 진영에는 존재한다.
과거에 닷넷에 대해서 비판적이고 회의적이었던 내가, 이런 할렐루야 급 닷넷 찬양글을 쓰다니, 참 아이러니하다. 그러나, 현재 시점에서 델파이로만 먹고 살기에는 여러 문제가 있다. 모바일 혹은 웹쪽 프로그램을 앞으로 할일이 있을지 모르겠지만, 그런 쪽의 어플을 만들 때 델파이 보다는 닷넷이 훨씬 더 좋은 선택으로 보인다.
And Now The End Is Near
