블루네쩜넷 :: .NET 과 .NET 프레임워크 I

.NET

.NET 이라는 개념자체는 상당히 모호한 개념임에는 틀림이 없다. 아마도 이것은 모호한 개념으로 하여금 하나의 무형의 메이커를 만들어내는 MS의 뛰어난 전략의 산물이 아닐까 싶다. 기술적으로 이야기하자면, .NET은 Microsoft의 다양한 기술들을 설명하는 포괄적인 용어이다. 16 비트 개발 플랫폼에서 32 비트로 전환한 이래, 마이크로소프트 개발 플랫폼 역사 상 가장 중대한 변화중의 하나이며 .NET은 윈도우즈 프로그래밍을 위한 전혀 새로운 개발환경이며, 새로운 API(Application Programming Interface)라고 볼 수 있다.

마이크로소프트는 근 10년이 넘는 기간동안 업그레이드되는 하드웨어 기술에 맞추어 그에 따르는 윈도우즈의 기술들을 계속적으로 발표해 왔다. 1990년 Windows 를 세상에 알린 이후, 계속적으로 이전 Windows와 버전을 호환하면서, 개발도구와 언어들을 확장시켜 온 것이다. 하지만, 그러한 확장작업을 언제까지 계속할 수는 없는 노릇이기에, 이제 Microsoft는 그러한 모든 것을 진화시킨, 새로운 강력한 개발도구와 언어를 내놓았다. 물론, 기존 버전들과의 호환성까지 유지하면서 말이다.

마이크로소프트가 내놓은 .NET에 포함되는 기술들은 크게 다음과 같이 분류할 수 있다.

물론, 바라보는 위치에 따라 이 분류는 달라질 수 있겠지만, 개발자의 관점에서라면 크게 무리는 없을 것이다. 그리고, 당연한 이야기이지만, 이러한 .NET 기술들은 기존보다 더욱 안정성 있고, 확장성 있고, 성능이 뛰어난 어플리케이션을 개발하는 데에 포커스를 두고 있다.

또한, .NET 이란 전략에 대해서 개념적으로는 이렇게 표현하기도 한다.

우리는 개발자이기에, 사실상 관심사는 .NET 이라는 것의 사업적인 개념보다는 기술적인 개념에 대해 관심을 가지고 있다. 해서, 많은 .NET 개발용 서적들에서는 .NET 이라는 것을 개발자의 관점에서는 .NET 프레임워크라고 이야기를 하기도 한다. 위에서 보았듯이 사실상 .NET 프레임워크는 .NET 의 일부일지라도, 개발자에게는 .NET 프레임워크를 .NET 이라고 이해해도 크게 문제가 되지는 않을 것이다. 그렇다손 치더라도 .NET 프레임워크가 .NET 자체가 아니라는 사실은 기억하고 우리의 관점을 기술적인 .NET의 구조로 돌려보자.

위의 그림은 .NET을 기술적으로 접근해서 보았을 경우의 그림으로, .NET 프레임워크와 .NET 언어, 그리고 개발도구의 연관성을 보여주고 있다. .NET의 개발 구조라고 볼 수 있는 이 그림을 이제 차근히 한번 살펴보도록 하자.

가장 밑단에는 Windows 라는 OS와 Windows의 핵심 서비스인 COM+ Services 가 자리하고 있으며,
.NET 프레임워크라는 가장 핵심적인 .NET의 기술은 그러한 OS와 서비스의 기반위에 자리하고 있는 것을 볼 수가 있다. 이는 .NET 프레임워크가 독립적으로 존재하는 OS 가 아닌, 플랫폼(Windows OS)기반 위에서 제공되어지는 프레임워크(골격), 구조라는 것이다.

참고로, Windows.NET Server 라는 새로운 OS가 출시를 앞두고 있는데, 이는 .NET 프레임워크를 탑재한 상태로는 최초(?)로 발표되는 OS이다. 고로, 여러분의 OS가 Windows.NET 이 아니라면 반드시 .NET 프레임워크를 설치하여야만 .NET 프로그램들이 동작할 수가 있게된다.

.NET 프레임워크는 Pink 색으로 둘러싸여져 있는 조금은 거대한 모습을 가지고 있다. 그림에서 알 수 있지만 .NET 프레임워크를 구성하는 것으로는 Common Language Runtime, Base Class library, Data & XML, ASP.NET & Web Services, Windows Forms 가 있다. 여기서 중요하게 알 수 있는 것 중에 하나는 우리가 현재 관심을 가지고 공부하고 싶어하는 ASP.NET은 .NET 프레임워크의 일부라는 것이다.

또한, Data & XML 즉, ADO.NET 도 .NET 프레임워크의 일부라는 것도 재미있다. 책으로 쓰자면 각각 족히 1000 여 페이지 이상의 책 한권일만한 ASP.NET 과 ADO.NET 이 .NET 프레임워크의 일부에 불과하다. 여기서 우리는 자못 현기증을 느낀다. 첫번째 현기증은 도대체 .NET 프레임워크라는 것이 얼마나 거대한 것인가라는 대목에서이고, ASP.NET과 ADO.NET이 각각 1000 여 페이지가 넘는 정도의 분량이라는 데에 또 한번 그러할 것이다.

그렇다손 치더라도 여러분이 .NET 프레임워크 자체를 공부하는 일은 그다지(?) 없을 것이다. 여러분은 .NET 프레임워크를 이루는 ASP.NET, ADO.NET, Windows Forms 등을 공부할 것이며, 그로 인해 저절로 .NET 프레임워크를 이해할 수 있게 될 것이다.

.NET 프레임워크에 대해서는 이후 구체적으로 알아볼 것이기에 지금은 잠시 넘어가도록 하고, .NET 프레임워크 윗단에 놓여있는 Common Language Specification(CLS) 을 알아보도록 하자. "공통 언어 명세"라고 번역하는 이는 여러분이나 제 3자가 .NET을 지원하는 타입을 작성하고자 할 경우, 그 기준이 되어주는 일종의 명세서라고 볼 수 있다.

해서 이 명세를 통해서 여러 언어들이 닷넷을 지원하도록 만들 수 있는 것이며 여러분이 실력만 된다면 이 명세에 맞추어 닷넷 지원 언어를 만들수도 있다는 이야기도 된다. 현재 닷넷을 지원하고자 하는 수많은 언어들이 나와있고, 또한 준비중에 있는데 파스칼, 코볼, 파이썬등등.. 한번쯤 들어보았음 직한 언어들이 .NET 버전으로 제공되고 있다.

이 CLS의 위치를 다시금 위의 그림에서 확인해 보자. 그 위치는 .NET 프레임워크와 .NET 언어 사이에 놓여져 있다. 이 이야기는 .NET 프레임워크에서 동작하려 하는 언어들은 모두 CLS 를 따라야 한다는 이야기이다. 사실상 개발하면서 우리가 CLS를 직접적으로 건드릴만한 일은 없을 것이다. 하지만, 역시나 개념적으로는 CLS의 역할에 대해서 기억해 둘 필요가 있다.

자... 이제 제일 윗단을 보도록 하자. 크게 설명이 필요없는 이 부분은 바로 .NET 언어들이 자리하고 있다. CLS를 따르는 .NET 언어들을 통해서 우리는 .NET 프레임워크 기반의 프로그래밍을 작성할 수가 있다. 대표적인 .NET 언어로는 Microsoft가 전폭적으로 지지하는 C# 과 VB.NET 등이 놓여져 있다. 그 외에도 많은 언어들이 현재의 시점에서 제공되어지지만, 대부분의 개발자의 선택은 C# 과 VB.NET 쪽으로 양분화 될 것으로 예상이 된다.

기존의 ASP 프로그래머들은 이미 VBScript를 통해서 VB 문법에 대단히 익숙해져 있기에 VB.NET 쪽으로 흐를 가능성이 상당하다. VB는 매우 공부하기 쉬운 언어였다는 특징이 더욱 그러한 흐름을 촉진할 것이다. 그러나, 여러분도 그렇게 생각하고 있다면 한가지 중요한 포인트를 잊지말자. 만일, 여러분이 쉬울 것이라는 기대로 인해 VB.NET을 선택한다면 그것은 조금은 잘못된 선택이다. VB.NET은 VB 처럼 쉽지 않다. 만만하게 보다간 프로그래밍의 재미를 떨어뜨릴 수 있다. 선입견을 버리라는 이야기를 하고 싶은 것이다.

태오가 추천하는 언어는 C# 이다. 모든 C# 책들이 그렇겠지만 태오도 C#을 최고의 언어라 믿어 의심치 않는 바이다. 이는 .NET 프레임워크의 많은 부분이 C# 으로 작성되어졌다는 보고때문일 수도 있지만, 그 외에도 여러가지 C# 언어만의 장점이 많기 때문이다. 물론, 개별적으로 각각의 .NET 언어들이 자신만이 가진 장점들을 가지고 있지만, C# 이 그중 가장 탁월하다는 생각은 때오만의 생각은 아닌 것 같다.

그러나, 이것은 개인적인 추천일뿐, 언급했듯이 그 어떠한 언어라 할지라도 CLS을 따르는 언어는 .NET 프로그래밍에서 자유롭게 사용할 수 있다. ASP.NET 은 물론 윈도우즈 프로그래밍에서도 특정 언어에 대한 제약은 없다. 말 그대로 언어 독립적인 세상이 온 것이다.

마지막으로 그림의 우측에는 OS 단 부터 .NET 언어에 이르기까지 폭넓게 자리하고 있는 Visaul Studio.NET 이라는 것이 존재하고 있다. 통합 개발환경으로 등장한 VS.NET은 이렇게 전반적인 개발을 용이하게 해주는 Microsoft의 대표 개발 툴이다. 이를 통해 여러분은 쉽고, 빠르고, 안정적이며, 확장성있는 솔루션을 만들어 낼 수 있을 것이다.

전반적인 .NET의 개발환경에 대해서 알아보았다. 하지만, 조금은 미진한 부분이 있었으니 그 것은 바로 .NET의 핵심이며, 개발자에게있어 .NET 이라고 표현할 수 있는 .NET Framework 이다.

.NET 프레임워크

.NET 프레임워크도 사실상 간단하게 설명하기는 조금 곤란한 환경이다. 그렇다. 환경이라고 볼 수 있다. 개념적으로 .NET 프레임워크를 설명하자면 다음처럼 나타내 볼 수도 있다.

.NET 프레임워크가 ASP.NET 개발에 필수적인 기술임은 자명하다. 하지만, 이는 ASP.NET 뿐 아니라 윈도우즈 어플리케이션의 개발까지도 모두 관여하는 기본적인 시스템 서비스들을 제공한다. 다시 말해, .NET 프레임워크는 여러번 언급했다시피 OS 에 add-on 되어져서 .NET 기술에 대한 기본 지원 시스템 서비스들을 제공해 준다는 이야기이다.

이제 기술적으로 한번 바라보자. .NET 프레임워크는 크게는 두 부분으로 이야기할 수 있다.

다시 위의 그림에서 .NET 프레임워크 부분을 살펴보면, Common Language Runtime과 Base Class library 그리고, Data & XML 과 ASP.NET & Web Services, Windows Forms 로 구성되어져 있음을 확인할 수도 있다.

Base Class Library는 I/O, 문자열, 네트웍 보안, 스레딩, 텍스트, 리플렉션, 컬렉션등의 기본적인 클래스를 제공하는 기본 클래스 라이브러리이며, DATA & XML 은 데이터 액세스와 관계한 ADO.NET과 XML 부분을 제공하는 역할을 한다. ASP.NET과 웹 서비스는 분산 웹 어플리케이션을 구축하는 근간을 제공하며 또한, Windows Forms 는 윈도우즈 어플리케이션을 구축하는 기반이 되어준다. 이들 또한 매우 중요하지만, 이 들도 크게는 .NET 클래스 라이브러리에 포함되어진다고 볼 수 있다.

해서 필자는 .NET 프레임 워크를 크게 두 부분으로 나눌 수 있다고 이야기한 것이다.

.NET 프레임워크의 가장 중요한 부분중에 하나는 역시 C.L.R 이다. 그렇다고, .NET 클래스 라이브러리가 덜 중요하다는 것은 아니다. 만일, .NET 프레임워크 클래스 라이브러리가 제공되지 않는다면, .NET 프로그래밍을 포기할 수도 있을 정도로 이 또한 중요한 것이다. 이 라이브러리가 어쩌면 프로그래밍의 전부라고도 이야기 할 수 있으니 말이다.

둘은 각각 맡은 분야가 틀리다. CLR은 일종의 코드의 관리환경이다. 이러한 환경을 통해 여러분은 안정적이고, 확장성 있는 솔루션을 개발해 낼 수가 있다. 일종의 플랫폼의 실행 하부구조를 제공하는 의미라고 보면 되겠다. 클래스 라이브러리는 여러분이 프로그래밍에서 사용할 수 있는 모든 기본적인 클래스들을 제공해 주며, 이러한 클래스들을 .NET 언어로 잘 엮어서 멋진 솔루션을 또한 만들어 낼 수 있다.

그렇다면, 이제 이들에 대해서 조금씩 더 구체적으로 알아보도록 하자.

Commmon Language Runtime

일단, CLR을 이해하려면 그 구조를 먼저 살펴보아야 한다. CLR은 무엇을 하는 것인가라는 질문의 답은 CLR이 어떠한 것들로 구성되어져 있는가를 통해서 얻어낼 수 있는 것이니 말이다. 다음 그림은 이러한 CLR의 구성을 이해하기 쉽게 나타낸 그림이다.

일단 첫 모습은 만만치 않아보인다. 하지만, 속을 들여다보면 반드시 그렇지 만도 않다. 이들 자체에 대한 깊은 내용은 여러분이 .NET 프레임워크 관련 서적을 통해서 구체적으로 배울 수 있을 것이다. 이 강좌는 ASP.NET 관련이라는 것을 기억해내라. 언제나 중용은 어려운 법이다. 태오는 이 강좌에서 너무 많은 욕심을 부리는 모습은 보이고 싶지 않다.

CLR은 MFC나 ATL 같은 개발을 돕는 라이브러리가 아니라, 프로그램이 실행되고, 관리되는 환경이다. 이 이야기는 무엇보다 중요하다. MFC나 ATL 같은 개발을 돕는 라이브러리의 역할은 .NET 프레임워크 클래스 라이브러리와 Windows Forms 쪽에서 담당한다. 이 둘을 헛갈리는 것은 곤란하다. CLR은 어플리케이션의 개발을 쉽게 하고, 튼튼하고 안전한 실행환경을 제공한다. 또한, 다중 언어들을 지원하며, 어플리케이션의 배포와 관리를 쉽게 해준다는 장점을 가지고 있다.

자.. 그럼 CLR을 구성하는 요소들 각각에 대해서 알아보자. CLR의 모든 구성요소들에 대해서 알게되면 CLR이 무엇을 하는 친구인지 더 잘 이해가 될 것이다.

CLR의 가장 밑단에는 Class Loader가 위치하고 있다. 이는 메타 데이터(데이터를 나타내는 데이터, 차후 이야기될 것이다)를 관리하며, 클래스들의 레이아웃과 로드를 관리하는 역할을 한다.

그 위로는 IL to Native Compiler 가 위치하고 있는데, 이는 코드가 컴파일되어져 만들어진 중간언어를 Native 코드로 컨버트 시켜주는 역할을 담당한다. 지금 여기서 잠시 엉? 하시는 분들이 있다. 그도 그럴 것이 여러분은 아직 컴파일을 하는데 왜 중간언어라는 것이 만들어지는지, 중간언어라는 것은 무엇인지에 대한 그 어떠한 이야기도 이 강좌의 전에서는 들어본 적이 없기 때문이다.

간단하게 이야기하면, 여러분이 .NET 언어로 작성한 모든 코드들은 컴파일되어지면, 그 때 실행파일이 만들어지는 것이 아니라, Common Language Runtime내의 JIT(Just-In-Time) 라는 컴파일러에 의해 재 컴파일이 되어질 수 있는 중간적인 언어(IL 혹은 MSIL : Microsoft Standard Intermediate language) 로 만들어지게 된다. 여러분이 작성한 코드는 각 언어 컴파일러에 의해 중간 언어로 컴파일되며, 이 MSIL은 런타임에 의해 또는 처음 실행될 때 Just-In-Time(JIT)에 의해 원시 코드(native code)로 컴파일된다.

해서 그렇게 개발자가 작성해서 컴파일 해 놓은 중간언어를 원시코드로 컨버트시키는 역할을 담당하는 역할을 CLR의 IL to Native Compiler 가 담당하는 것이다. 이해가 조금 어려울 수도 있다. 자 ~ 그러한 궁금증은 조만간 풀릴 것이다. 그러므로 조금은 답답한 면이 있다하더라도 지금은 각각의 설명에 집중하도록 하자.

관리 코드(Managed Code)란?

MSIL로 컴파일되어 CLR 에 의해 관리되는 코드를 관리 코드(managed code)라고 한다. 관리 코드는 런타임에 의해 개체의 생성과 초기화, 메모리 할당, 가비지 컬렉션과 같은 코드 실행이 전반적으로 관리되어 진다.

그 옆으로는 Code Manager와 Garbage Collector가 존재하고 있다. 코드 매니저는 말 그대로 코드의 실행을 관리하는 역할을 하며, 가비지 컬렉터는 어플리케이션을 위해 자동으로 메모리를 관리하는 역할을 한다. 이는 매우 중요한 CLR의 역할 중에 하나인데, 이를 통해서 모든 메모리는 자동적으로 관리가 이루어지게 된다. 가비지 컬렉터의 제공으로 개발자들은 객체를 생성한 후에, 자원을 해제할 필요가 없어졌다. 이전 컴포넌트 개발시 자원을 미처 해제하지 못한 코드들로 인해 발생했던 메모리 누수를 겪어본 개발자들이라고 한다면 이 기능이 매우 반가울 것이다.

가바지 컬렉터는 개체가 더 이상 참조되지 않거나 사용되지 않으면 자동으로 그것들을 버려서 메모리 누수(Memory leak)현상을 방지하는 역할을 한다. 이는 사실상 수시로 그러한 수집작업을 하는 것은 아니고, 메모리가 일정치이상 높아질 경우 수집작업을 수행한다. 가비지 컬렉터에 대한 심화는 고급 프로그래밍쪽의 서적에서 다룰 만한 이야기이므로 메모리와 관계된 깊숙한 이야기가 궁금하신 분들은 C# 관련 M.O.C 교재나 .NET 프레임워크와 관계된 전문적인 서적을 참고하시기 바란다.

그리고 또한, CLR은 Security Engine과 Debug Engine를 제공하고 있다. 보안 엔진은 사용자뿐 아니라 코드 자체를 기반으로 하는 보안까지 제공하는 엔진을 나타내며, 디버그 엔진은 코드의 실행을 추적하거나 어플리케이션을 디버그할 수 있도록 해주는 엔진을 의미한다.

그리고, Type Checker은 강력한 형의 안정성을 체크하는 기능을 제공하며, 초기화 되지 않은 변수나 불안전 형 변환을 막도록 해주는 역할을 하며, Exception Manager는 강력하게 예외 및 에러를 관리하는 기능을 제공한다.

Thread Support는 멀티 쓰레드를 가진 프로그래밍이 가능하도록 클래스와 인터페이스를 제공해 주는 역할을 가지고 있으며, COM Marchaller 를 통해서 COM으로의 마샬링(서로 다른 프로세스간의 COM 개체의 통신)을 가능하게 해준다.

이 모든 기능이 CLR 에서 제공하는 기능이다. 이제서야 여러분은 CLR이라는 것이 코드의 실행을 관리하는 런타임 환경이라는 말을 이해할 수 있을 것이며, 이러한 기능이 얼마나 중요한 것인지 새삼 느낄 수 있을 것이다. .NET 코드들이 아주 원할하고, 강력하게 동작할 수 있도록 안정성있는 환경을 제공하는 공통 언어 런타임을 제일 상단에 .NET 기본 클래스 라이브러리를 지원할 수 있도록 하는 Base Class Library Support를 제공하고 있어서, 모든 .NET 언어가 .NET 기본 클래스 라이브러리를 사용할 수 있도록 해주고 있다.

.NET Framework Class Library

기본 클래스 라이브러리와 ASP.NET, ADO.NET, Windows Forms를 포함하는 .NET 프레임워크 클래스 라이브러리는 이전의 Windows API에 의해서 가능했던 모든 작업들에 관한 기능들을 제공하는 클래스들의 거대한 집합이며, 매우 사용하기 쉽고, 문서화도 잘 되어 있다. 사실상 .NET 언어의 몫이라는 것이 .NET 클래스 라이브러리를 가져다가 꾸밈을 넣어 사용하는 것에 불과하다라고 말할 수 있을 정도로 이 클래스 라이브러리는 중요하다. 간단하게 이러한 .NET 클래스 라이브러리에는 어떠한 것들이 포함되어져 있는지 확인해 보자. 그들을 보면 아마도 .NET 클래스 라이브러리없이는 그 어떠한 프로그램도 작성하고 싶지 않아질 것이다.

거의 모든 부분에 클래스 라이브러리는 관여하고 있다. 만일 모든 클래스들과 그 클래스들의 목록을 알고 싶다면, 여러분은 다음 사이트에서 그 클래스들을 브라우징 할 수 있다.

http://samples.gotdotnet.com/quickstart/aspplus/samples/classbrowser/vb/classbrowser.aspx

만일, 여러분이 Vosual Studio.NET을 설치한 뒤, [시작] [모든 프로그램] [Microsoft .NET Framework SDK] 의 "샘플 및 퀵 스타트 자습서" 를 통해서 QuickStart 를 여러분의 개발 PC에 설치했다면 로컬의 다음 경로에서도 .NET Framework Class Browser 를 확인해 볼 수 있다.

http://localhost/QuickStart/aspplus/samples/classbrowser/cs/classbrowser.aspx

출처 : (taeyo.pe.kr)

일	월	화	수	목	금	토
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31