나.닷넷의 구성요소

닷넷은 플랫폼 독립성과 언어 독립성을 확보하기 위해 다음과 같은 여러 가지 장치들을 제공한다. 대부분 Common으로 시작하는데 그만큼 닷넷이 공용성과 일반성을 역점에 두었다는 뜻이다.

CLR(Common Language Runtime)

직역하자면 공용 언어 런타임이라는 뜻인데 닷넷 실행 엔진을 의미한다. 자바의 가상 머신(JVM)과 개념적으로 동일하다. 런타임이란 프로그램이 실행되기 위한 핵심 모듈들의 집합이다. 윈도우즈에서 실행되는 모든 프로그램은 kernel, user, gdi 모듈이 필요하고 MFC로 만든 프로그램은 mfcxx.dll이 꼭 필요한데 이런 모듈들을 런타임이라고 한다. CLR은 닷넷 프로그램 실행에 필수적인 런타임들의 집합이되 이름이 의미하듯에 모든 언어에 공용으로 사용된다. 어떤 언어로 만든 프로그램이든지 IL을 JIT로 컴파일한 후 CLR과 연결되므로 제작 언어에 상관없이 CLR의 서비스를 받을 수 있다.

CLR은 닷넷의 핵심 커널이다. 응용 프로그램이 실행되면 CLR이 권한을 확인하고 프로세스를 생성하며 코드의 안전성을 검사한다. 보안 점검이 완료되면 첫 번째 스레드를 생성하여 응용 프로그램의 코드를 실행시킨다. 실행 중에 응용 프로그램의 요청을 받아 때로는 직접 처리하기도 하고 때로는 호스트 운영체제와 통신을 주선하기도 한다. CLR은 운영체제와 닷넷 응용 프로그램 사이에 위치하며 한마디로 닷넷 프로그램 실행을 위한 모든 서비스를 제공하는 실행 주체라고 할 수 있다.

닷넷 응용 프로그램은 운영체제와 직접 통신하지 않으며 반드시 CLR을 거쳐야 한다. CLR은 물론 플랫폼별로 따로 제공된다. CLR이 호스트 운영체제와의 통신을 책임지므로 응용 프로그램은 운영체제에 대해서 독립적이다. 응용 프로그램은 호스트 운영체제는 거의 신경 쓸 필요가 없고 오로지 CLR과의 약속만 잘 지키면 된다.

CTS(Common Type System)

CTS는 모든 닷넷 언어들이 공동으로 사용하는 타입 체계를 정의한다. 언어끼리 함수를 호출하려면 인수나 리턴값에 대해 서로의 타입을 알 수 있어야 한다. 예를 들어 C++에서 int 형의 값을 넘기면 VB에서는 Integer 타입으로 이 값을 받아들일 것이다. 이때 int와 Integer는 같은 타입이라는 것을 두 언어가 모두 알고 있어야 하며 물리적인 포맷이 같아야 한다. 두 타입의 길이나 형태가 다르다면 서로 다른 언어끼리 원활하게 통신할 수 없을 것이다.

함수 호출뿐만 아니라 다른 언어가 정의한 객체를 포함한다거나 다른 언어가 정의한 클래스를 상속받을 때도 똑같은 문제가 있다. 진정한 언어 독립성을 확보하고 언어간의 교차 프로그래밍이 가능하기 위해서는 개별 언어가 타입을 마음대로 정의해서는 안되며 플랫폼 차원에서 공통의 타입을 정의할 필요가 있는데 이 타입 체계가 바로 CTS이다.

CTS는 닷넷 지원 언어들이 공동으로 사용하는 타입에 대한 약속이며 IL에서 사용 가능한 타입들의 집합이다. CTS에는 정수, 실수같은 기본형 뿐만 아니라 클래스, 배열 같은 좀 더 복잡한 타입까지 계층이 잘 정의되어 있다. CTS에 구체적으로 어떤 타입들이 정의되어 있는가는 다음 장에서 상세하게 살펴볼 것이다.

각 언어들은 CTS가 정의한 닷넷 내장 형식을 사용할 수 있는데 편의상 언어별로 고유한 키워드를 정의하기도 한다. 닷넷 지원 언어들은 CTS의 모든 타입을 의무적으로 지원할 필요는 없다. 예를 들어 비주얼 베이직은 부호없는 정수형을 지원하지 않는다. 따라서 비주얼 베이직과 같이 동작해야 하는 언어들은 부호없는 정수 타입을 외부 통신용으로 사용해서는 안된다. 물론 내부적인 용도로만 사용하는 것은 문제가 없다.

CLS(Common Language Specification)

각각의 언어들은 다른 언어와 구분되는 아주 고유한 특성들을 가지기도 한다. 예를 들어 명칭의 대소문자를 구분하는가, 다중 상속은 지원하는가, 연산자 오버로딩이 가능한가 등은 언어마다 다르다. 이렇게 언어마다 특성이 각각 다르면 언어 상호 운용이 아주 어려워진다. 그래서 닷넷은 언어들이 지켜야 하는 최소한의 사양을 정의하는데 이를 CLS라고 한다. CLS의 몇 가지 예를 들어 보자.

■ 전역 함수나 변수는 정의할 수 없다.

■ 부호없는 정수형은 인정하지 않는다.

■ 명칭은 대소문자를 구분하지 않는다.

■ 포인터를 사용할 수 없다.

■ 연산자 오버로딩을 지원하지 않는다.

CLS는 닷넷용 언어가 되기 위한 최소한의 규정이다. 그래서 주로 기능을 제약하는 규칙들이 많은데 각양 각색의 언어를 지원하기 위해 약간의 제한을 두는 것은 불가피하다. 닷넷용 언어들은 CLS의 모든 규칙을 다 만족하지 않아도 상관없다. 닷넷 전용 언어라고 하는 C#조차도 CLS를 완전히 만족하지는 못한다. 오로지 외부로 공개되는 부분에 대해서만 CLS를 만족하면 될 뿐이며 내부적인 처리를 위해서는 CLS를 만족하지 않는 기능도 얼마든지 사용할 수 있다.

예를 들어 부호없는 정수형은 CLS에 정의되어 있지 않으므로 외부에서 호출되는 함수가 부호없는 정수형을 리턴하는 것은 규칙에 맞지 않다. 그러나 함수 내부의 지역 변수에 부호없는 타입을 사용하는 것은 상관없다. 또 CLS는 명칭의 대소문자 구분을 하지 말 것은 권장하고 있으므로 외부로 공개되는 명칭을 대소문자만 다르게 작성해서는 안된다. C#으로 만든 프로그램이 Calc, calc, CALC 이런 메서드를 외부로 엑스포트하면 대소문자 구분을 하지 못하는 비주얼 베이직은 이 메서드를 제대로 호출하지 못할 것이다. 임의의 언어에서 사용 가능한 클래스를 만들고 싶다면 CLS를 잘 준수해야 한다. 하지만 C# 내부에서만 호출된다면 이런 메서드의 집합도 얼마든지 정의할 수 있다.

CLS는 언어를 만드는 사람들을 위한 명세이므로 응용 프로그램 개발자가 CLS의 모든 면을 자세히 알 필요는 없다. 닷넷을 좀 더 잘 이해하기 위한 참고 정보일 뿐이다. 각 언어의 컴파일러 제작사들은 CLS가 요구하는만큼만 컴파일러를 만들면 된다. 최소한의 규약만 지킨다면 C#이나 C++처럼 덩치가 크지 않아도 상관없고 기능이 아주 단순해도 상관없다.

BCL

닷넷에는 여러 가지 복잡한 기능을 제공하는 방대한 기본 클래스 라이브러리(BCL)가 탑재되어 있다. 닷넷은 플랫폼이면서 라이브러리라고 할 수 있는데 사실 플랫폼은 응용 프로그램 제작을 위한 라이브러리를 포함할 수밖에 없다. 플랫폼이 라이브러리를 제공하지 않으면 응용 프로그램 개발자들이 해야 할 일들이 너무 많아지기 때문이다. 마치 윈도우즈가 방대한 Win32 API를 제공하는 것처럼 닷넷도 같은 개념의 BCL을 제공한다.

BCL은 마이크로소프트가 미리 작성하여 제공하는 잘 정리된 클래스들의 거대한 집합이다. 제공되는 클래스들의 규모가 엄청날 뿐만 아니라 객체 지향적이고 문서화도 잘 되어 있어서 잡스러운 처리들의 대부분은 BCL을 호출하기만 하면 된다. 닷넷을 공부한다는 것은 BCL의 클래스들을 하나 둘씩 정복해 나가는 과정이라고 할 수 있다. BCL에 포함된 클래스의 목록과 기능을 대충 정리해 보자.

■ 기본 타입에 대한 정보 제공

■ 배열, 연결 리스트, 큐 등의 컬렉션 클래스

■ 그래픽 라이브러리(GDI+)

■ 스레드와 동기화 클래스

■ 각종 컨트롤

■ 파일 입출력

■ 네트워크와 인터넷 프로그래밍

■ 데이터베이스 액세스

응용 프로그램 제작에 필요한 기능들의 대부분이 BCL에 이미 구현되어 있으므로 공짜로 쓸 수 있는 기능들이 아주 많다. 더구나 BCL은 언어 차원이 아니라 닷넷이 플랫폼 차원에서 제공하는 라이브러리이므로 모든 언어들이 공유할 수 있다는 면에서 더 매력적이다. C#에서 BCL 사용법을 제대로 익혔다면 VB에서 BCL을 활용하는 것은 식은 죽 먹기라는 얘기다.