[MSDN] .NET Framework 구조

MSDN에 나와 있는 .NET Framework에 대한 설명을 읽고 있자면 '지루하다'. -_-

일단 모르는 단어들이 너무 많이 튀어 나와서 처음 읽는 사람으로 하여금 급거부감을 주게된다.

모르는 단어를 클릭해서 링크를 따라 들어가다 보면 어느새 어딘지 알수 없는 곳에서 또 다시 모르는 단어를 클릭 하려는 내 모습을 발견하고는 깊은 한숨과 함께 '프로그래밍은 나랑 잘 맞지 않습니다...'를 연발하게 된다. 슬픈 현실이다... ㅡ.ㅜ

개인적으로 영어를 쓸 일이 많다보니 아무래도 한국어로 된 MSDN보다 영어로 된 MSDN을 좋아하는데 원래 프로그래밍 언어가 영어인데다가 영어는 불분명한 의미가 없는 정확한 표현을 쓰기 때문에 오히려 한국어로 된 설명보다 이해가 더 쉽게 될때가 많다.

그래서 MSDN은 영어로 읽는 것이 더 나을 것이라고 말하고 싶지만 영어를 격하게 싫어하시는 분들은 아마도 한국어가 나을 듯하다...

이제 .NET Framework에 대해서 이야기 해보자. 이 놈은 내가 Visual Studio 를 이용하면서 부터 꾸준히 내 머리 속에 맴돌던 놈인데 단 한번도 제대로 들어다 본적은 없었다.

왜냐면 일단 내가 차후 설명하게 될 Common Language Runtime(CLR)을 전혀 사용하지 않았기 때문이고 둘째로 이 .NET Framework는 알게 모르게 내 컴퓨터의 구석에서 내가 하는 일들을 돕고 있었다.

비록 그 실체를 몰랐어도 저놈이 있다는 것은 알고 있었다. 요즘들어서 내 프로그램을 다른 컴퓨터에 돌릴일이 많아지다 보니 이놈에 대해서 자연스럽게 접근하게 되었고 몇몇 MSDN 문서를 읽게 되었다.

아마존 닷 컴에서 Ivor Horton's Beginning Visual C++ 2008 이라는 책을 검색해 보면 저 책의 1장을 볼수 있는데 여기에 많은 설명이 잘 되어 있다. (공짜다.. ㅋㅋ)

내가 개인적으로 .NET Framework를 잘 설명하고 있다고 생각하는 그림이 바로 위 그림이다. 일반적으로 C나 C++을 이용해서 간단히 작성해 오던 방식이 그림 제일 왼편에 있는 그림이다. 이것을 보게되면 Native C++코드를 컴파일러(gcc나 각종 컴파일러들)로 Object 파일로 생성하고 Link를 통해 실행 파일을 만들어서 돌리게 된다.

이후 MFC가 나오면서 가운데 한단계가 더 추가되었다. (중간 그림) 사실 이 MFC는 한번도 사용해 본적은 없지만 아주 쉽고 간편하면서도 다양한 형태의 함수를 제공했다는 걸 알수 있었다.

.NET Framework가 나오고 나서도 물론 MFC가 지원되지만 .NET Framework가 MFC보다 한수 위인 이유는 정확히는 몰라도 .NET Framework가 가지는 강력한 Cross-Platform 과 Cross-Language 특성 때문이 아닌가 싶다.

마지막으로 제일 오른편이 바로 .NET Framework를 제대로 사용하는 경우인데 뭔지 모를 2단계가 들어가 있는데 이것이 바로 .NET Framework를 구성하는 2개의 구성요소인 Common Language Runtime과 .NET Framework Library다.

간단하게 설명해서 .NET Framework Library는 걍 함수들의 집합이다. 이놈들은 전부 객체 지향적이므로 독립적으로 사용가능하며 독립적이므로 안전하고 아주 좋다... -_-

사실 CLR이 참 재밌는 놈인데 마지막 단어인 Runtime에 주목할 필요가 있다. 즉, 실행중이란 의미인데 내가 프로그램을 더블 클릭해서 실행에 들어가는 직후부터 프로그램이 죽는 순간까지를 Runtime이라 보면 된다.

이 CLR은 그 런타임에 작동을 하는 놈으로써 다양한 작업을 하는데 예를 들면 보안을 높이고 메모리를 관리하면 타입을 관리하고 각종 시스템의 핵심 서비스들을 제공하기까지 한단다...

나도 프로그램에 입문한지 얼마 되지는 않았기 때문에 정확한 것은 알 수 없지만 .NET Framework의 CLR이 '이것은 새롭다! 이것은 좋다!'라고 Microsoft가 외치는 이유가 바로 Runtime 이라는 저 단어 하나 때문이 아닌가 싶다.

기존의 프로그램 컴파일과 실행의 과정을 보게 되면 컴파일을 수행하는 단계에서 이미 현재 컴퓨터에 종속적 (dependent) 이게 되고 Linker를 통해 실행파일을 만드는 과정에서도 역시 종속적이게 되는 것 같았다. (내 생각일 뿐임... 물론 자바가 이 원리를 깨뜨렸다.)

헌데 이 새로나온 .NET Framework에서는 중간에 CLR와 JIT(Just-In-Time Compiler)를 실행 파일을 만드는 과정에 집어 넣음으로써 큰 변화를 시도했다는 점이 다른 것 같다.

우선 .NET Framework에서 생성되는 실행 파일은 실행 파일을 더블 클릭 한 뒤의 시점(일명 Runtime)에 여러가지 일을 수행하는데 이 일들이 바로 플랫폼에 종속적이지 않도록 만들어주는 일이다.

즉, 이전에는 활용하지 못했던 Runtime이라는 새로운 시간적 공간을 이용해서 각종 다양한 추가 기능 및 편리한 기능을 제공하고 있다는 점이 .NET Framework가 뛰어나다라고 말하는 이유인 것 같다. 자바가 먼저인지 .NET이 먼저인지는 몰라도 자바의 Virtual Machine의 개념도 이와 같다.

물론 이건 내 개인적인 생각이지 이게 이유라고 설명한 글은 본적이 없다... -_-

사실 .NET Framework를 제대로 설명하려면 Common Language Runtime과 더불어 MSIL (Microsoft Intermediate Language), CTS (Common Type System), JIT (Just-In-Time Compiler)를 다 설명해야 하지만 이걸 다 설명하려면 너무 길어질 뿐더러 읽는 사람의 가독력과 흥미가 너무 반감될것 같아 여기서는 말 안해야 겠다....

줄여서 결론을 말하자면 .NET Framework는,

프로그래머가 프로그램을 짤때 사용할 수 있는 새로운 '뼈대 (Frame)' 이다.

그리고 이 새로운 뼈대의 장점들은 무수히 많지만 대표적인 것들이

1. 플랫폼 Independent (플랫폼에 종속되지 않는다.)
2. 프로그램에 대한 다양한 형태의 접근제어 및 컨트롤 방법을 제공한다. 즉, 내용물을 보여주되 복사하거나 그 소스를 못보게 하는 등의 접근제어를 말한다.
3. 강화된 보안을 제공한다. (접근제어도 일종의 보안 방법중 하나지요.)
4. Cross-Language를 제공한다. CLR에 근거하여 작동하는 모든 언어는 서로간에 정보 교환이 자유 자재로 된다는 의미. C#을 작성한 파일을 Visual Basic에서 불러와 사용가능하다는 말. (물론 코딩시 제약이 있다.)
5. Web 개발을 혁신적으로 개선했다. 이건 뭐 읽어보지 않았지만 ASP .NET이 바로 CLR에 기반을 두고 클라이언트가 서버의 컴퓨터에 접속하여 서버의 컴파일러에 의해 작동된다는 뭐 그런소리... 내가 사용할 일은 거의 없을 거라는...

또 무언가 장점이 있을텐데 기억이 안나는 관계로 여기까지만 적자.

Update
시간이 많이 흘러서 다시 이글을 보니 좀 부족한 설명이 있는 것 같아 추가로 몇자 적어 놓는다.

우선 가장 기본이 되는 CLI를 언급해야 할 것 같다. CLI는 Common Language Infrastructure의 줄임말로 하나의 '규약'을 명시해 놓은 '조립 설명서' 같은 거다.

이 CLI는 고레벨의 프로그래밍 언어 (C++/ C# 같은거)들이 다른 오퍼레이팅 시스템 환경에서 재 컴파일이나 소스 코드를 바꾸지 않고도 문제 없이 균일하게 같은 방식으로 동작할 수 있도록 만들어주는 Virtual Machine을 위한 '규약 설명서'이다. 

즉, 이 CLI 규약대로만 구현을 하면 어느 컴퓨터에서나 돌아갈 수 있는 Virtual Machine을 만들어 낼수 있다는 말인데 이 Virtual Machine의 대표적인 예가 바로 CLR이다. CLR은 Common Language Runtime으로써 CLI 규약 대로 만든 윈도우즈 용 CLI의 구현이다.

이 CLI 규약을 보면 Virtual Machine (CLR 같은 놈)을 위한 중간 단계의 언어를 명시하고 있는데 이것이 바로 MSIL (Microsoft Intermediate Language)이다. 이렇게 만들어진 중간 단계의 언어는 프로그램이 시작하는 시점에 작동을 하는 JIT (Just-in-time) 컴파일러에 의해서 이해되고 분석되어 진 후 내가 현재 사용하고 있는 컴퓨터의 환경에 맞는 적합한 machine code(실행 코드)를 생성해 낸다. 고로 어떤 언어로 내가 프로그램을 작성했건 간에 그 코드는 CLI 규약에 따라 구현된 눈에 보이지 않는 .NET Framework의 CLR과 같은 놈을 통해 중간 언어 (MSIL)로 바뀌어진 다음 실행이 이루어지는 그 순간 (마우스 더블 클릭하는 순간) JIT라 불리우는 컴파일러에 의해 내 환경에 맞는 코드로 재 생성되서 나와서 실행이 이루어 진다는 말.

또한 .NET Framework에는 CTS (Common Type System)이라 불리우는 것이 있는데 이것은 말 그대로 CLI 명세를 따라 구현된 모든 언어가 공통으로 가지는 기본 타입의 구현 및 임의 타임의 구현 약속이다. 고로 C#으로 작성한 코드의 기본 타입들은 Visual Basic이나 C++과 같은 다른 언어로 작성된 기본 타입과 기본적으로 일맥상통하므로 CLR의 입장에서는 다른 언어를 이용한 두 소스 코드를 이해하는데 아무런 문제가 없다는 말.

고로 고 레벨 언어간의 융화와 결합이 용이하고 보다 높은 수준의 안전성 체크 및 형변환을 지원함으로써 한 단계 높은 수준의 프레임워크를 제공한다는 것. 게다가 CLR은 기본적으로 강화된 보안 옵션 (예를 들자면 어셈블리를 공개키와 개인키로 묶는 것)을 제공하며 눈에 띄는 변화가 바로 GC (Garbage Collector)의 등장이다. 

가비지 컬렉터의 등장으로 과거에 사용자에게 메모리 해제의 책임을 전가하는 것에서 벗어나 이제 사용자는 두다리 쭈욱 뻣고 마음껏 새로운 인스턴스를 남발해도 되는 상황이 왔다는 것. 물론 100% 그렇다는 건 아니고... 아직도 여전히 사용자에게 많은 책임이 있으므로 메모리 해제는 늘 머릿 속에 염두해두어야 할 문제다. 어쨌든 가비지 콜렉터는 착하다는 거... ㅋㅋ