닷넷 프레임웍과 델파이의 미래에 대해서(2)

[주정섭]

닷넷 프레임웍과 델파이의 미래에 대해서(2)

닷넷과 델파이 미래에 대해서 두번째 글을 쓸려다, 볼랜드 개발자 사이트에 올라온 글을 먼저 소개하고자 합니다. 이글은 볼랜드 델파이 컴파일러 개발자가 쓴 글이기 때문에 델파이 닷넷에 대한 편파적인 일방 옹호적 글로 보일수도 있습니다만, 옳은 말이 상당히 많다고 판단됩니다.

다음 글은 볼랜드 개발자 사이트에 올라온, 델파이 수석 개발자가 쓴 글입니다. 이글을 읽어보면 델파이의 미래를 유추해볼 수 있는 많은 힌트들이 있습니다. 가급적 원문 그대로 번역하려 애썻습니다만, 짧은 영어실력인지라 오류가 있을 수도 있습니다. 그러한 오류가 있다면 지적해 주십시요.

원문의 url은 다음과 같습니다.

http://bdn.borland.com/article/0,1410,31983,00.html

읽어 보시고 많은 의견 첨부해 주시면 감사하겠습니다. 게시판은 좋은 의견과 반론들이 꼬리를 물때 진정한 위력을 발휘하기 때문입니다.


제목 : 왜 VCL for .NET 인가
부연 : 왜 볼랜드는 VCL for .NET을 만들었는가? 그리고 언제 WIndows Forms 프레임웍 대신에 VCL for .NET을 사용해야 하는가?

(역주) 델파이 8에는 기존 델파이 프로그램 작성 방식으로 닷넷 어플을 만드는 방법과, Windows Form(윈폼) 방식, 즉 C# 방식으로 닷넷 어플을 만드는 방법이 있습니다. 전자는 기존 델파이 프로그램을 거의 수정없이 닷넷용으로 전환할 수 있다는 것입니다. 단, 지나치게 Windows API에 의존하지 않는 코드라야 하고, 포인터를 사용하지 않은 경우입니다. (역주끝)

델파이 8 닷넷 버전은 델파이 커뮤너티에서 많은 흥분을 유발하고 있다. 뉴스그룹, 채트룸에서는 닷넷 인프라스트럭쳐와 이미 익숙한 WIn32 플래폼 간에 어떤 관계를 가지는지 의견이 분분하다.

매우 열띤 주제 중 하나가 델파이 8의 VLC for .NET에 관해서이다. 대부분은 VCL for .NET의 목적이 뭔가에 대해서다. 대략 다음과 같은 내용들이다.

"VCL for .NET은 델 개발자들의 기존 소스를 닷넷용으로 전환하기 위해 사용할 단기적 미봉책인가? 아니면 장기적인 어플리케이션 프레임웍인가? 왜 볼랜드는 마이크로소프트의 WinForms와 경쟁할 무엇(VCL for .NET)을 만들려고 하는가?"

진정하시고, 흥분을 가라않히시라. 그 진실을 알려 주겠다.

.....배경.....

마이크로소프트의 닷넷 프레임웍은 하드웨어 독립적인 실행환경과 언어 중립적인 타입 시스템을 제공한다. 요거 매우 좋은 거다. 그러나, 윈도우에서 동작하는 클라이언트 어플리케이션을 만들기에는 부족한 점이 있다. 물론 닷넷은 Win32용 GUI 어플을 만드는데 사용하는 Windows Forms(WInForms) 프레임웍을 가지고 있다. 델파이나 C 빌더의 VCL 어플에 익숙한 개발자들은, 닷넷 윈폼 프레임웍이 VCL과 여러모로 비슷한 설계 방식을 취함을 알 수 있을 것이다. 이는 별로 놀랄만한 사항이 아니다. 안델스 헤이젤버그(C# 수석 개발자)의 말처럼, "좋은 아이디어는 그냥 사라지지 않는다"

VCL과 윈폼간에 여러 유사점이 있음에도 불구하고, 기존 Win32 VCL 어플을 윈폼으로 전환하기에는 두 플랫폼간의 근본적 차이점 때문에 매우 어렵다. 어렵다는 것은 고통스럽다는 것을 의미한다. 고통은 새로운 아이디어 채택을 금지하게 한다. ..as well as sales of tools to take you there.

닷넷은 새로운 플랫폼이다. 이제 소프트웨어 산업에서 모든 새로운 움직임은 닷넷으로 향하고 있지만, 닷넷 어플 개발은 기존 혹은 진행중인 WIn32 개발에 비하면 여전히 극히 일부일 뿐이다. 닷넷 플랫폼에 대한 관심사항을 알아보기 위해 행한 설문에 의하면, 많은 볼랜드 고객(개발자)이 닷넷에 지대한 관심을 가지긴 하지만, Win32 개발에 투자한 모든 것을 포기하고,  닷넷에서 완전히 새로 시작하기를 원하지는 않는다는 것이 명백했다. 이는 여전히 사실이며, 수년이 지나도 마찬가지일 것이다.

델파이 8로 윈폼 어플 만들기는 매우 쉽다. 그런데, 기존 델파이 개발자들은 우리에게 말하길, "그거 끝내주는 기능이여. 근디, 지금까지 고생해서 만들어서 우리 회사 업무가 돌아가는 모든 VCL 코드는 우야란 말이고?"

기존 델파이 개발자들에게 닷넷 플랫폼을 더욱더 매력적이게 하고 잘팔게 하기 위해서, 기존 WIn32 개발환경과 닷넷 개발환경의 간격을 메우는 뭔가가 필요하였다. 그것은 닷넷 프레임웍 그 자체 만큼 순수해야 하며, 기존 Win32 VCL 구조와 매우 유사한 환경을 제공할 필요가 있다. 기존 VCL개발자들을 꼬시기 위해 델파이 for 닷넷이 필요한 것은, 닷넷 플랫폼에서 동작하는 VCL을 구현하는 것이다.

처음에 우리(볼랜드 델파이 개발자들)는 윈폼 프레임웍 위에서 동작하는 VCL 구현을 고려했었다. 연구결과, VCL 어플을 윈폼으로 전환하는 것을 어렵게 하는 구조적 차이점 때문에, 윈폼 위에서 동작하면서 여전히 VCL방식으로 동작하는 VCL 계층을 구현하는 것은 어렵다는 것이 점차 명백해 졌다.

윈폼을 평가하면서 우리가 느낀 점은, 윈폼이 Win32 API 호출 바로 위에 존재한다는 것이었다. 윈폼 윈도우즈 클래스들은 Win32 윈도우 핸들을 생성하기 위해, CreateWindow()를 호출한다. 이들은 Win32 환경의 WndProc을 훅하고 윈도우 메시지를 기다리고, 적절한 이벤트를 실행하고 등등의 일을 한다.

VCL 역시 사실 이런 방식으로 동작한다.

만일 managed 닷넷 코드에서 Win32 API 호출이 닷넷 프레임웍에서 문제가 없다면, 이는 VCL에서도 문제가 없다는 것이 된다. 그렇다면, 닷넷 플랫폼에서 VCL을 구현하는 작업이란, 기존 VCL이 의존하는 WIn32 API호출을 어떻게 할지를 알아내고, VCL 코드 자체 변경을 어떻게 최소화할지를 알아내는 것이다.

.........VCL for 닷넷의 경우..........

VCL for 닷넷은 마이크로소프트 윈폼 구조와 나란히 걷는, VCL 구조의 진화이며 연속이다. 윈폼과 VCL for 닷넷 둘다 Win32 API 호출 위에 존재한다. 따라서 유사한 플랫폼 제약사항과 유사한 성능적 특성을 가진다. VCL이 윈폼보다 더 나은 성능을 보이는 부분도 있다. 왜냐하면 VCL은 Pen과 Brush, DC 의 핸들 공유를 구현해 두었기 때문이다. 윈폼은 그렇지 않다. 성능 향샹 방법을 찿는 것은 델파이 개발 팀들한테는 지속적인 작업이다. 이는 마이크로소프트가 윈폼을 지속적으로 성능 향상 시키는 것과 마찬가지다.

VCL은 플랫폼 변화에 대해 적응력이 좋다는 것을 이미 증명하였다. 그 증거로 16 bit Windows뿐만 아니라, 32 bit WIndows인 NT, 95, 심지어 리눅스의 QT 등에서 VCL은 동작한다. 반면 윈폼은 천성적으로 .NET에 밀접하게 결합되어 있고, 결국 Win32와 매우 밀접하게 결합되어 있다.

호언장담: 닷넷 콤팩트 프레임웍은 윈폼 네임스페이스의 여러 클래스들을 구현하지만, 콤팩트 프레임웍은 여러면에서 다르고, 콤팩트 윈폼 프레임웍은 윈폼과 호환성이 있다고 판단하기에는 적당하지 않다. 마이크로소프트는 이런 점을 명백하게 인정한다. 왜냐하면 마이크로소프트는 닷넷 콤팩트 프레임웍 실행 환경을, 바이너리(binary) 차원에서 Win32 닷넷 exe와 호환성이 없게 만들었기 때문이다.  닷넷 콤팩트 프레임웍 시스템 어셈블리들은, Win32 닷넷 시스템 어셈블리와는 다른 키를 사용하여 strong name되어져 있다. 따라서 Win32 닷넷 실행파일들은 콤팩트 디바이스에서 실행할 수 없다. 닷넷 콤팩트 프레임웍에서 실행하려면 콤팩트 어셈블리 차원에서 소스를 재컴파일해야만 한다.

(역주) 닷넷 프레임웍에 대해서 깊은 부분까지 모르지만, 콤팩트 프레임웍은 닷넷을 휴대폰같은 소형 장치에서 동작하게 하는 것으로 추정됨(역주끝)

Win32 VCL에서 VCL for 닷넷으로 코드를 전환하는 것은, 어플리케이션 코드 차원에서는 비교적 쉽다. 그러나, Win32 API과 밀접하게 연계된 콤포넌트들은 다소 많은 작업을 요할 수도 있다. 하지만 델파이 개발자들은, VCL for 닷넷이 Win32 VCL을 CLX로 바꾸는 것 보다는, Win32 VCL을 닷넷으로 전환하는 것은 더 쉽다는 것을 깨달을 것이다. VCL for 닷넷은 실행환경을 상당 부분 수정했지만, Win32 VCL 만큼 거의 동일한 메시지 핸들링, 예외 처리, Win32 API를 지원한다. CLX는 리눅스 플랫폼에서 동작하기 위해 메시지 핸들링과 Win32 API 지원을 포기해야만 했었다.

VCL for 닷넷은 일방통행이 아니다. VCL for 닷넷용으로 작성된 어플리케이션 코드는 적절한 범위에서 Win32 VCL 용으로 되돌릴 수도 있다. Win API와 밀접하게 동작하는 코드와 non-exotic 문법으로 작성된 코드는, 업무 처리 코드에 비해서 동일 소스로 여러 플랫폼에 동작 가능하게 하는 것이 더 어려울 것이다. (non exotic 이란, 모호한 강제형변환과 포인터 연산을 의미한다).

C#으로 어플리케이션을 작성하려면 개발자는 자신의 기존 코드와 개발 경험을 완전히 버리고, 닷넷 환경에서 새로이 시작해야 한다. C#은 개발자가 닷넷 플랫폼에 완전히 복종하기를 요구한다. 다른 플랫폼(OS환경)에서 동작하는 C# 컴파일러는 전혀 없다. 물론 리눅스에는 Mono가 있다. 그러나 모노는 GUI/윈폼 지원을 구현하지 않았으며, 따라서 모노는 클라이언트 어플리케이션 개발환경은 아직 아니다. VB닷넷 역시 같은 배를 타고 있다. VB닷넷과 VB6 코드 간의 코드 전환은 너무 위험하며, 새로이 재작성하는 것이 더 나을 정도로 근본적인 언어 비호환성이 존재하므로, VB개발자들은 이에 대해 많이 불평해왔다.

델파이 포 닷넷으로 코드를 작성하면, 그 코드를 윈도우와 리눅스 같은, 비 닷넷 플랫폼으로 전환할 수 있는 선택의 여지를 제공한다. VCL for 닷넷으로 어플리케이션을 작성하면, 어떤 다른 닷넷 언어도 제공하지 못하는, 코드 전환 옵션 혜택을 얻는다.

......VCL for 닷넷은 델파이 개발자를 위한 것이다......

VCL은 다른 닷넷 언어에는 거의 찾아 볼 수 없는 델파이 언어의 몇몇 강력한 기능에 의존한다. 따라서, C#이나 VB 개발자들이 VCL for 닷넷에 지대한 관심을 두리라고 기대하지는 않는다. C# 코드에서 VCL for 닷넷을 사용할 수도 있다. 그러나, 가상 생성자(virtual constructor)같은 VCL의 어떤 기능은, C#의 측면에서 보면 이상하고 비직관적이다.

VCL for 닷넷이 구현한 GUI 콘트롤들은 델파이 개발자들만 관심을 가질 것이며, C#이나 VB 닷넷 개발자들은 별로 관심이 없을 것이다.

만일 델파이 개발자가, virtual class method, virtual constructor, sets, AnsiStrings, class reference 같은,  델파이에서만 유일하고 C#과 다른 닷넷 언어에는 없는 문법만 조심해서 사용한다면, Non visual 콤포넌트, 유틸러티 클래스, 비지니스 로직은 델파이로 구현가능하며,C#이나 VB닷넷 개발자들이 이것을 쉽게 사용할 수 있다.

VCL for 닷넷 폼은 윈폼 콘트롤을 가질 수 있다. VCL for 닷넷으로 코딩하는 델파이 개발자들은, VLC for 닷넷 콤포넌트와 콘트롤 뿐만 아니라, 모든 윈폼 콤포넌트와 콘트롤을 사용할 수 있다.

물론 소스 코드 호환성보다 훨씬 더 중요한 것은 개발자 숙련도 호환성이다. VCL에 익숙한 개발자는 즉시 VCL for 닷넷에 즉시 익숙할 수 있다. 어떻게 어플리케이션을 만드는지, 콤포넌트를 만드는지, 메시지 핸들러를 만드는지, 이 모두가 Win32 VCL과 VCL for 닷넷은 같은 방법을 사용한다. VCL for 닷넷은 경험있는 델파이 개발자를 닷넷 플랫폼에서 즉시 생산적이게 하며, 다른 어플리케이션 프레임웍 구조를 교육받는데 소모되는 3-6개월간의 공백 시간을 피할 수 있다.

.....델파이 언어는 VCL에 대해 독립적이다.

VCL for 닷넷은 델파이 언어 기능에 의존한다. 그러나 델파이 언어는 VCL을 필요로 하지 않는다. VCL for 닷넷을 어플리케이션에 포함하지 않고, 델파이 문법 만을 사용해서 윈폼 어플리케이션을 만들 수도 있다. 또한 익숙한 델파이 런타임 유틸러티 함수들과 클래스를 사용해서 윈폼 어플리케이션을 만들 수도 있고 따라서, IntToStr과 동일한 기능을 가진 닷넷 함수가 뭔지 찾아야 하는 시간을 벌 수 있다.

모든 프로그래밍 언어는, 하부 플랫폼에 존재하는 구조에, 자신의 언어 개념을 어떻게 결합할 지 정의해야만 한다. 닷넷에서 이러한 하부 구조는 핵심 언어 타입과 더불어 코드를 포함할 수도 있다. 델파이 언어는 CLR이 구현하지 않은 개념과 언어체계도 포함하기 떄문에, 델파이는 닷넷이 지원하지 않는 기능을 구현하기 위해 약간의 코드를 언어에 결합한다. 이런 언어 결합은 델파이 어플리케이션이나 어셈블리에 직접적으로 링크할 수도 있고, Borland.Delphi.Dll같은 외부 어셈블리에 링크할 수도 있다.

(역주) 다음 글에서 JXcript는 J스크립트로 읽어 주십시요. 이 게시판이 스크립트라는 단어를 부적절한 단어로 간주하는지라...(역주 끝)

모든 닷넷 언어들은 이러한 언어 결합 라이브러리를 가진다. VB 닷넷의 Microsoft.VisualBasic.dll은 이런 언어 결합의 일종이며 그 크기는 300k 정도이다. JXcript의 Microsoft.JXcript.dll은 700k 정도의 파일 크기를 가진다. C# 언어 결합 라이브러리는, mscorlib.dll와 System.dll 으로 라인을 그리는지, 혹은 C#의 최소 설치에서 요구되는 닷넷 프레임웍 크기에 따라서 3-20MB 정도다. 델파이의 Borland.Delphi.dll은 64k 정도의 크기 밖에 안된다.

닷넷 플랫폼에서만 동작할 새로운 프라젝트를 시작하는데 관심있는 사람들 뿐만 아니라, VCL 소스 개발 경험이 있는 개발자들 양측 모두를, VCL for 닷넷은 고려하고 있다.

.... 미리 변화하자...

마이크로소프트의 장기적 플랫폼 os 로드맵에 따르면, 차기 윈도우 버전에서 중대한 변화가 있을 것임을 암시한다. 특히 롱혼이라 불리는 마소의 OS는 UI 구현부와 저변 구현부에서 중대한 변화를 포함하고 있다. Win32 API는 기존 Win32 어플들과 실제 OS presentation 계층 사이에서 위치하는 호환성 유지 계층이 될 것이다. 마이크로소프트는 롱혼에 대해서 이미 새로운 어플리케이션 프레임웍을 구축 중이다. MSDN에서 여기에 대해서 더 잘 알 수 있다.

변화는 때때로 두렵지만, 마이크로소프트는 윈폼 어플리케이션은 롱혼과 그 이후 버전에서도 계속 동작할 것이라고 하므로 이는 다행스럽기도 하다. VCL for 닷넷은 윈폼과 동일한 바탕에서 만들어 졌다. 따라서 VCL for 닷넷 어플리케이션은 롱혼과 이후 버전에서 계속 동작할 것이다. VCL은 윈폼보다 더한 플랫폼 이전이라는 가혹한 경험을 수차례 겪었다(Win16, Win32, Linux, 마침내 Win32 to 닷넷까지) . 따라서 VCL for 닷넷은 윈폼보다, 롱혼에서 있을 수 있는 변화에 잘 적응할 수 있을 것이다.

이는 VCL for 닷넷이 윈폼 아키텍쳐에서 더 우수한 존재이게 할 것이다. VCL for 닷넷은 임시적인 일방 통행 다리 보다는 훨씬 긴 생명을 가지며, 윈폼 방식으로 새로이 작성하는 것 보다, 기존 VCL 어플리케이션들에 대해 우수한 투자 회수 효과를 가진다.

왜 어플리케이션을 재개발하려 하는가? 기존의 VCL 어플리케이션을 VCL for 닷넷으로 이전해서 별다른 노력없이 동등한 마일리지 효과를 얻기 바란다. 윈폼이 좌초하여(닷넷 자체가 망함을 의미) VCL for 닷넷도 같이 끝나버릴지라도, VCL for 닷넷이 윈폼보다 더 나은 투자 회수 효과를 가짐을 의미한다.

왜 우리가 VCL for 닷넷을 만든지는 바로 이러한 이유 때문이다.

.......결론..........

단넷 플랫폼의 마이크로소프트 윈폼 어플리케이션 아키텍쳐는 새로운 어플리케이션 개발을 위한 견고한 아키텍쳐이다. 하지만 윈폼 환경에 들어가는 것은 대가가 크다. 왜냐하면 기존 소스에 대해서 이전할 방법이 없기 때문이다.

닷넷 아키텍쳐에 대한 볼랜드 VCL for 닷넷은 델파이 개발자에게 두 환경 모두에서 최선을 제공한다. VCL for 닷넷은 점점 커지고 있는 닷넷 플래폼을 준비하기 위해서, 새 개발툴을 배우고 교육을 새로 해야 하는 시간 부담을 최소화하면서, 기존 소스 코드와 개발 경험을 버리지 않게 할 수 있다.


작성자 : Danny Thorpe 델파이 컴파일러 아키텍쳐 닷넷 팀 리더