.NET 그리고 개념

2002년10월30일에 쓴 글로서... (휴... 벌써 5년 전이구만..ㅎㅎ) 다음 신지식에 있는 것을 퍼 왔음.

 

이글은 비주얼 c++ 강좌란에 안재우 님이 쓰신글을 옮깁니다.. 제가 글을 쓰는것보다 좋은글이 더 있길래 올립니다. 질문이 더 있으시면 올려주시길 바랍니다.

오랜만에 쓰는 컬럼입니다. 이전에는 낙서판에다 썼는데 이건 강좌란에 쓰는게 어떨지 해서 써봅니다.
이 글의 일부내용은 Andrew Troelson이 쓴 C# and the .NET Platform이라는 책의 원문을 참조했습니다.
(C#이나 .Net을 공부하시는분들에겐 권장할만한 책입니다. ^_^)

---------------------------------------------------------------------------------------------
최근 개발자는 각종 기술의 홍수 속에서 허우적거리고 있습니다. 특히 새롭게 개발자로서의 시작하려고 하는 사람들에겐 도대체 어떤 언어(C++, VB, Java, Delphi 등등), 어떤 프레임웍(MFC, ATL, STL), 어떤 아키텍쳐(COM, CORBA)를 선택해야 하는지 선뜻 결정을 내리기 힘든 상황이겠지요. 심지어 운영체제마저 윈도우플랫폼에서 해야 할지, 유닉스/리눅스 플랫폼을 택해야 할지 고민하고 있을테구요.

각각은 서로 장단점을 가지고 있습니다. 하지만 적어도 여러분이 다음과 성향의 개발자라면 .Net을 추천하고 싶습니다.

* 윈도우 플랫폼을 선호하는 개발자
* 웹 또는 분산환경 엔터프라이즈 개발자
* 새롭고 이상적인 개발환경을 원하는 개발자

.Net의 장점을 열거하기 전에 먼저 우리는 기존의 상황들을 점검해 볼 필요가 있지 않을까 합니다. 그리고 난후 .Net이 개발자에게 제시하는 것이 무엇인가를 살펴본다면 왜 제가 .Net을 추천하는지 좀 더 쉽게 알 수 있지 않을까 하는 생각이 드는군요. 이미 이러한 상황들을 겪어 왔던 개발자라면 더욱더 공감할 수 있을테고, 겪어보지 못했다면 이러한 시행착오를 거치지 않아야 된다는 점에 대해 다행스럽게 생각해야 할것입니다.

@ DOS 개발자로서의 삶

말할 필요도 없이 이때는 처음부터 바닥까지 프로그래머가 모든 것을 개발하던 시기입니다. DOS라는 운영체제가 해주는 것이 너무 없었기 때문에(?), 모든 작업은 프로그래머의 일이었죠. 물론 라이브러리들이 있긴 했지만...

@ Win32/C 프로그래머로서의 삶

윈도우라는 운영체제가 나오면서 기존의 도스 환경에서의 개발하고는 개발 형태가 완전히 달라지게 되었습니다. C 프로그래머는 Win 16/32 API를 가지고 운영체제가 제공하는 여러가지 혜택을 누리면서 개발을 할 수 있게 된거죠. DOS에 비해서 보다 멋진 GUI를 가진 애플리케이션이 쏟아져 나오기 시작했고, 그것이 지금의 윈도우를 최고 인기를 누리는 운영체제로 만들었습니다.
그러나 여전히 API만 가지고 애플리케이션을 만드는 것은 어렵고 복잡했지요. 그 이유를 먼저 C언어 자체에서 찾아보자면, 메모리를 직접 건드릴 수 있다는 장점을 가지고 있긴 하지만, 메모리 관리를 프로그래머가 일일이 다해야 된다는 고통을 수반하기도 했고, 포인터의 난해함이라던지, 문법적으로도 다른 언어에 비해 다소 어렵고 헷갈린다는 점들이 있었습니다. 또한 C는 Structured 언어이기 때문에 OOP의 혜택을 받지 못하여 코드 가독성/재사용성 등이 떨어질 수 밖에 없었습니다.
그리고 수많은 API를 일일이 외우고 그 사용법을 숙달한다는 것은 너무나 어려운 것이었죠.

@ C++/MFC 프로그래머로서의 삶

C++를 사용함으로써 비로소 OOP의 혜택을 누릴 수 있게 되었습니다. 많은 사람들이 머리를 싸매고 난해한 OOP의 개념을 공부했습니다. 객체, 클래스, 캡슐화, 다형성, 상속...
그러나 개인적으로는 과연 C++를 사용함으로써 개발기간이 정말 단축되는가에 대해서는 의문입니다.
클래스화 한다고 하더래도 코드 재사용은 실제로 Copy & Paste로 이루어지는 것이 대부분이었으니까요.
결과적으로 C++가 개발속도나 유지보수를 아주 획기적으로 개선해주지는 못했습니다.
C++ 자체가 기존의 C언어에 OOP 레이어를 올려놓은 형태기 때문에 기존의 C언어가 가지는 결점들을 그대로 끌고 내려올 수 밖에 없었던 것이죠. malloc 대신 new를 사용하면 되긴 하지만 여전히 delete를 호출해서 직접 메모리 관리를 해야 했고, 포인터, 문법상의 난해함 등은 계속 남아있었죠.

MFC는 윈도우 프로그래머들에게는 상당히 획기적인 전환점을 제공했습니다. 잘 아시다시피 수많은
API 덩어리들을 래핑한 클래스를 제공했고, 각종 매크로와 VC++에서 제공되는 각종 Wizard들은 개발속도를 기존의 API만 쓰던 상황과는 비교되지 않게 개선시켰습니다. 그러한 이유가 지금도 MFC가 널리 쓰이고 있고, VC++하면 MFC를 연상하게 하는 상황이 되었죠.
하지만 MFC가 장점만을 제공하는 것은 아닙니다. VB나 Delphi 같은 RAD 툴에 비해 상대적으로 느린 개발속도와 편의성, 덩치큰 DLL, API 전체를 래핑하고 있지 못하기에 어차피 API도 섞어서 써야 한다는 점들 등등..

이런 점들이 여전히 C/C++/API/MFC는 어렵고 힘들다는 인식이 많은 사람들에게 남게된 원인일것입니다.

@ Visual Basic 프로그래머로서의 삶

C++에 질린 기존 개발자들이나 배우기 너무 어렵다고 생각한 사람들은 결국 RAD 툴쪽으로 눈을 돌렸습니다.
특히 VB는 상대적으로 간결한 문법, 쉬운 UI 구성, 많은 컴포넌트와 ActiveX 컨트롤 등을 제공하여 보다 손쉽고 빠른 개발 속도를 제공했습니다. 특히 DB 관련 작업에서는 C++에 비해 상대적으로 쉽고 더욱 빠른 개발이 가능했습니다.
그러나 VB가 OOP를 완전히 지원하지 못하고 있다는 점, C++에 비해 상대적으로 다소 낮은 퍼포먼스, VB로만은 부족하기에 간혹 API를 끌어다 써야 된다는 점들, 멀티쓰레딩이 안된다는 점들 등은 VB 프로그래머들이 지니는 약점으로서 존재했습니다. 그래서 VB로만은 완전하지 않다는 비난을 어느정도 감수해야만 했지요.

@ Java 프로그래머로서의 삶
(저는 솔직히 Java는 기초문법만 맛 봤습니다. 96년에 JDK 1.0을 가지고 끄적대본게 다군요.)

완벽한 OOP, 플랫폼 독립성을 내세우며 자바라는 언어가 등장했습니다. 자바는 C++와 유사하긴 하지만 C++에 비해서 보다 간결한 언어적 구조를 가지고 있습니다. 자바는 기존 C++의 클래스 라이브러리 개념에 비해 다소 진보된 "패키지"라는 개념을 제공합니다.(실제 이 개념은 .Net에 도입되었습니다.)
웹환경과 결합되면서 자바는 엄청난 각광을 받으면서 발전을 시작했고, 애플릿, 서블릿, JSP, 빈즈, EJB, J2EE 등 수많은 관련기술을 쏟아내었습니다.

자바 자체는 매우 훌륭한 언어입니다. (MS-썬 간의 정책 다툼 얘기를 빼자면..)
그러나 자바의 가장 큰 결점 중 하나는 처음부터 끝까지 자바로만 개발해야 한다는 점입니다. 자바의 디자인 목표 자체가 모든 플랫폼에서 사용될 수 있는 범용적인 언어(a single programming language for evey need)를 목표로 했기 때문에 다른 언어와의 호환성 등은 애초에 염두에 들어있지 않았던 것이죠.
이미 기존에 작성된 코드들을 버리고 자바로 완전히 새로 개발한다는 것은 너무나 어려운 문제입니다. 비용,개발자 재교육, 시간 등등에 대해 많은 문제가 산적해 있습니다. 또한 자바가 초기에 보여주었던 실망스러운 퍼포먼스 등은 자바에 관심을 가졌던 수많은 개발자들이 등을 돌리는 원인이 되었습니다.(물론 그럼에도 불구하고 자바는 많은 각광을 받았고 자바개발자는 늘어났다는 것은 분명한 사실입니다.)

퍼포먼스 문제 때문에 일부분은 C++로 작성하고 나머지는 자바로 작성하는 방법 등도 사용되긴 하지만, 자바 자체의 타 언어 호환성이 워낙 떨어지기 때문에 실제적인 프로젝트에선 어려움을 겪는 경우가 많습니다.

@ COM 프로그래머로서의 삶

기존 개발에서 충족되지 못했던 재사용성이라는 것을 해결하기 위해서 COM이 등장했습니다.
COM 아키텍쳐는 COM 규약대로만 개발한다면 바이너리 레벨의 재사용성을 제공합니다. 자바가 언어간 호환성을 제공하지 못하고 있는 것에 비해 COM 컴포넌트는 다른 언어에서 사용될 수 있습니다. C++로 작성한 컴포넌트를 VB에서 이용이 가능하다는 것이죠. 그외 델파이, 스크립트 등등 COM을 지원하는 언어간에는 서로호환성을 제공합니다.
(물론 COM의 재사용성이 완벽하지는 못합니다. COM 타입간의 계층적 상속이 안되는 점등이 예가 되겠죠.)
또한 COM은 컴포넌트간 통신 등에 대한 아키텍쳐를 제공하므로 C/S 환경 등에서 고려해야 될 모듈간 통신문제 등을 직접 다룰 필요가 없습니다.

COM은 기존의 문제를 개선한 좋은 모델이지만, 문제는 그 아키텍쳐를 이해하는데 너무 오랜 시간이 걸린다는 것입니다. 많은 사람들이 COM의 난해한 구조에 골치를 썩이는 경우가 많았습니다.
물론 개발툴에서 COM을 지원하면서 수동으로 IDL을 작성할 필요가 없다던지, ATL과 같은 COM 환경을 지원하는 템플릿 라이브러리가 나타나기도 했습니다. 또한 VB 같은 경우는 보다 많은 부분을 감추어서 쉽게 개발할 수 있게 되었지만, 여전히 COM의 기반구조를 모를 경우 문제점에 봉착할 우려가 많았습니다.
그리고 트랜잭션 문제점들도 기존 COM이 해결해주지는 못했습니다. MTS가 등장했지만 COM과 MTS를 결합시켜사용하는 점 또한 여전히 상당히 어려운 부분이었지요.

@ Windows DNA 프로그래머로서의 삶

인트라넷에서 인터넷으로서의 진화, n-tier 환경으로의 변화 등에 발맞추어 MS는 Windows DNA 아키텍쳐라는 것을 내놓았습니다. Windows 2000에서 도입된 COM+는 기존의 COM/MTS가 결합된 미들웨어로서 DNA의 핵심을 이루고 있습니다.
그러나 실제로 DNA 아키텍쳐는 아키텍쳐라고 부르기에는 다소 애매합니다. 좀 심하게는 DNA 아키텍쳐를 MS 백오피스 서버 제품군의 나열이라고 비판하는 사람들도 있지요.
개발자로서도 DNA 아키텍쳐를 구성하기 위해서는 ASP, HTML, XML, JavaScript, VBScript, COM+, ADO 등 수많은 기술을 조합해서 사용하므로 개발하고 구성하기가 상당히 힘들고 난해했습니다.
뿐만 아니라 기술상의 조합 문제 때문에 개발자가 일일이 새로운 문법, 타입 등을 공부해야 한다는 점은
어려운 문제 중의 하나였습니다. 분산환경의 특성상 다른 언어를 사용하는 개발자들이 만나서 공동작업을 해야 하는데 이러한 문제들은 서로간의 논의에서 혼란을 가중시키는 문제가 되었죠.

그렇다면, 과연 .Net은 지금까지의 이러한 문제점들에 대해 어떤 해결책을 제시할까요?
분명 이전의 개발환경과는 다르기 때문에 기존의 개발방법론과 지식들을 포기해야 하는 점도 있습니다만, 그 대신 .Net이 제공하는 많은 장점들을 얻을 수 있습니다.
아래는 .Net이 제공하는 주요한 장점들을 예로 든 것입니다.

* 기존코드와의 완벽한 호환
기존에 COM으로 작성된 컴포넌트를 그대로 .Net에서 재사용가능합니다. 물론 그 과정에는 이전에 비해
아주 극소한 퍼포먼스의 희생은 있습니다만...

* 언어간 호환성, 통합성 극대화
COM과는 달리 언어간 상속, 예외처리, 디버깅까지도 지원합니다.

* CLR (Common Library Runtime) 사용
자바의 VM과 유사한 런타임을 제공하여, 어떤 언어로 작성되던지 CLR이 설치되면 호환이 가능합니다.
즉 이 얘기는 .Net 환경에서는 어떤 언어로 작성하던지 결과물을 MSIL(Microsoft Intermediate Language)로 산출하므로 동일한 퍼포먼스를 얻을 수 있다는 장점과 함께, 어느 플랫폼이던지 CLR만 설치되면 앞으로 재컴파일 없이 호환이 가능하다는 결론을 제공합니다. 얼마전에 Free BSD 유닉스용으로 CLR이 포팅될것 이라는 얘기가 앞으로 .Net의 전망을 알 수 있게 해줍니다.
CLR은 내부에 CTS(Common Type System)을 제공하여 어떤 언어에서도 동일한 타입을 사용할 수 있습니다.
예를 들어 문자열을 나타내는 타입이 string, char*, char[], CString, wchar 등 다양한 종류가 있었지만
string 하나로 통합되었습니다. 기존에 BSTR이나 Variant의 처리 때문에 골치를 썩은 C 프로그래머에게는 더욱더 환영할만한 일입니다.
또한 CLR을 지원하는 언어로 포트란, 코볼, 파이썬 등등이 개발되고 있다는 점 또한 주목할만한 점입니다.
CLS(Common Language Specification)을 따르면 어떠한 언어도 .Net을 지원하도록 포팅이 가능합니다.

* Base Class Library의 제공
API를 추상화한 셋인 BCL을 제공하였습니다. BCL은 데이터액세스, GUI, 보안, XML/SOAP, 쓰레딩, 파일 I/O, 디버깅, 트랜잭션 등등 운영체제가 제공하는 모든 서비스를 제공합니다.
BCL의 사용은 자바의 패키지 개념과 유사한 namespace를 사용해서 접근가능합니다.
(예: using System.Console;)

* COM 사용의 간편화
더이상 IClassFactory, IUnknown, IDL, Variant 등을 신경쓸 필요가 없습니다.
HRESULT 또한 SEH(Structed Exception Handling)으로 예외처리가 가능합니다.

* 보다 손쉬운 배치(deploy) 모델
Self-registry 개념으로 .Net에서는 기존 COM 컴포넌트처럼 레지스트리에 등록할 필요가 없습니다.
이로써 DLL 버전 문제로 따른 DLL Hell도 자연스럽게 해결되었습니다.

이러한 장점 외에 .Net이 각광받는 또 하나의 점은 무엇일까요?
웹/분산환경으로 이동하면서 컴포넌트 기반 개발방법론이 많이 대두되었는데, .Net은 가장 이상적인 컴포넌트 기반 프레임웍을 제공하고 있다는 것이 가장 중요한 점일테구요...
XML/SOAP, 표준언어스펙의 C#, UDDI 등등 표준 기술을 프레임웍 안에 잘 융화시켰다는 점이 될 것입니다.
이러한 점들이 기존의 학계나 개발방법론 연구자, 시스템 아키텍쳐 설계자들이 .Net을 환영하는 이유입니다.

물론 지금 .Net을 시작한다는 것이 부담이 될 수도 있습니다.
아직까지 개발중인 기술이고, 얼마나 자리잡을 것인가하는 의구심이 들겠지요.
실제로 .Net Framework의 경우 베타1과 베타2 상에 CLR의 namespace가 많이 바뀌는 등의 변화로 베타1을 접했던 수많은 개발자들을 당황스럽게 한 것은 사실입니다.
그러나 .Net으로의 변화는 자연스러운 기존 개발방법론의 발전입니다.
또한 .Net에서는 누구나 출발선상 근처에 서 있다는 점 또한 시작하는 개발자에게는 커다란 장점입니다.
기존 개발방법론으로는 뒤따라 갈 수 밖에 없겠지만..
.Net에서는 선두주자로 나설 수 있는 기회가 더 많다는 점을 명심하십시오.

p.s.
이 글을 읽고 어떤 선택을 할 것인가는 여러분의 책임입니다