CTS, CLS에 대한 부가적 설명

CTS, CLS에 대한 설명을 하긴 했습니다만 이해가 잘 안가실 겁니다.(저도 잘 안갔습니다) 그래서 관계도를 올립니다.

CTS CLS 관계도

CLS는 개발자가 짜는 프로그래밍 언어가 어떤 것이던 간에 닷넷에서 동작하기 위한 최소한의 규약을 나타내는 것입니다. 이 부분에 대해서는 MS C++, C#, VB.NET을 배울 때 공통적으로 가르치는 부분입니다. 당연히 C++, VB, C#의 순수한 언어적인 측면을 배울 때는 눈에 띄지 않는 부분입니다. 스스로 직접 윈도우 환경에서 동작하는 프로그래밍을 하다보면 하나 둘 씩 등장하는 개념이니 천천히 배우면 됩니다.

CTS는 보시면 아시겠지만 언어에 상관 없는, 즉, 닷넷 프레임워크 환경에서 제공되는 데이터 형식, 런타임 구조 등등의 환경이 정의되어 있는 구조입니다. C++로 개발을 한다 하더라도 32비트 운영체제와 64비트 운영체제에 따라 데이터 형식이 달라지는 점이나, 플랫폼에 따라 데이터 형식에 약간의 차이가 발생할 수 있는 점 등등 여러가지 차이점이 있을 수 있습니다. 실행 환경에 대한 고려는 중요한 겁니다. 그런 환경에 대한 정의를 하고 있기 때문에 상당히 중요한 내용을 가지고 있는 것이죠. (프로그래밍을 시작하신 분들이나 일반 응용 프로그램 개발 시에는 데이터 형식에 대해 깊게 따지지 않는 경우가 많아 쉽게 넘어가는 경우가 많습니다. (것보다 따지면서 개발해야 하는 환경이 특수한 환경인데… 할 줄 아는 사람 많은가? ㅡㅅㅡ))

그리고 환경이 언어에 영향을 받지 않아야 하므로 모든 언어에 공통적으로 적용하고 있습니다. 그래서 여러 언어를 지원하면서도 동일한 형식을 이용할 수 있는 것이죠. ㅇㅅㅇ

.net Framework 간단히 보기

음… 닷넷 프레임워크를 무지 간단하게 볼 수 있는 방법이 뭐 있을까 했습니다만… 마침 좋은 게 떠올랐군요.

.net Framework. 핵심 요소만 보고 넘어가죠. 주 핵심 요소는 CLR, BCL, CTS, CLS로 정리할 수 있겠습니다.

  • CLR: 닷넷 프레임워크의 핵심 주으이 핵심입니다. 코드를 실행하고 메모리를 자동 관리하며 형식의 안정성을 보장하는 등 여러 가지 실행 환경을 제공합니다.
  • BCL: 닷넷이 제공하는 여러 가지(GUI, 웹, DB연결, 보안 등등) 클래스 라이브러리입니다.
  • CTS: 닷넷의 모든 데이터 형식이 기술되어 있으며, 런타임 프로그래밍 구조가 정의되어 있는 부분이다.
  • CLS: 닷넷의 모든 언어가 지켜야 하는 형식에 대한 일련의 규약으로써, CLS 규약을 지펴 만들어진 형식이라면 어떤 닷넷 언어에서도 사용할 수 있게 됩니다. 이전에 닷넷은 여러 언어가 쓰이지만 형식이나 방법만 제대로 지킨다면 어떤 언어를 써도 상관 없다고 했습니다. 그게 이겁니다. ㅇㅂㅇ

이걸 한 큐에 정리한 것이 아래의 구조입니다.

어셈블리(Assembly)

어셈블리 하면 다들 어셈블리어랑 어셈블러가 생각날지도 모르겠군요…ㅇㅂㅇ;;;

어셈블리는 닷넷의 컴파일된 모듈로 버전 관리되는 배포의 단위입니다. 프로그램 시작 진입점(main 함수)을 가지고 있는 exe 파일과 다른 프로그램으로 시작되는 dll 확장자를 가지고 있습니다. 또 여러 파일로 이루어진 다중 파일 어셈블리와 하나의 파일로 이루어진 단일 파일 어셈블리로 나눌 수 있으며 하나의 응용 프로그램에서 사용하느냐 여러 응용 프로그램에서 사용하느냐에 따라 전용 어셈블리와 공용 어셈블리로 나눌 수 있습니다. 근데 대부분 보는 것은 단일 파일 어셈블리입니다. 이건 좀 더 나중에 다룰 수 있으면 좋겠군요.

위의 그림이 어셈블리 구조입니다.

  • 메니페스트: 어셈블리 자체의 정보를 갖는 메타데이터. 이 어셈블리가 또 다른 어떤 어벨블리를 참조하는지부터 사진에 대한 정보를 모두 담고있다.
  • 형식 메타데이터: 어셈블리에서 사용하는 모든 형식에 대한 구체적이고 자세한 정보를 가지고 있다. 형식 메타데이터 덕분에 리플렉션 기능이 가능하다.
  • CIL 코드: Common Intermediate Language의 약자로, 모든 닷넷 언어들이 만들어 내는 중간코드이다. 이 중간코드는 실행 시 Just-In-Time(JIT)에 의해 네이티브 코드로 변환된다.

닷넨 어셈블리는 CIL 코드라는 중간 코드를 가지고 있다고 했습니다. 그럼 이 구조도 한번 봐야죠. ㅇㅅㅇ

위의 구조가 각각의 닷넷 언어의 컴파일러와 Jitter 컴파일러 구조를 보여주는 구조도입니다. 각 닷넨 언어의 컴파일러는 동일한 어셈블리를 만들어 냅니다. 또 이 어셈블리를 어셈블러가 사용되는 시점(실행 시간)에 단 한번(캐싱) 네이티브 코드로 변환합니다. (이 말은 즉, 동일한 논리적, 구조적으로 프로그램을 작성한다면 작성 언어에 대해 굳이 따지지 않는다는 것도 있습니다. ㅇㅅㅇ)

이 외에도 외부에서 라이브러리를 참조하는 과정이 클래스 로더에 있습니다. 주로 사용되는 클래스 라이브러리는 Base Class Library라는 이름으로 닷넷이 있고, 추가적인 라이브러리는 다른 dll을 참조합니다. ㅇㅅㅇ

닷넷 바이너리(.net binary)와 네이티브 바이너리(native binary)

윈도우에서 흔히 쓰는 .exe 실행 프로그램이나 .dll 이란 동적 링크 라이브러리들을 가지고 바이너리라고 부릅니다. 보통은 그냥 똑같이 C:\에 존재하기 때문에 파일만 봐서는 구분이 되지 않습니다.

이 둘을 구분하는 건 바로 실행 환경을 보고 구분합니다. .net 응용 프로그램은 CLR(Common Language Runtime)이라는 닷넷의 구성 요소 중 하나에서 동작합니다. CLR 위에서 실행되며, CLR에 의해 관리됩니다. 메모리, 스레드, 원격 서비스, 보안, 형식 안정성 등의 거의 모든 관리가 CLR에 의해 관리됩니다. 그래서 .net 응용 프로그램은 Managed Program이라고도 합니다.

이쯤 되면 대충 뭐랑 비슷해 보이긴 하죠? JVM이 떠오르셨다면 정답입니다. CLR은 닷넷의 핵심 요소로써 JVM과 유사한 역할을 합니다.

C#

C#

공부하기 어려운 언어는 아닙니다. 특히 자바를 공부했던 분들이라면 더더욱 어렵지 않습니다. 객체 지향 언어들은 거의 공통적인 특성을 가지고 있기 때문에 공통적인 부분만 한 가지 언어로 익혀두고, 다른 언어를 배울 때는 그 차이를 매워가는 형식으로 알아두면 되기 때문입니다. 문법의 쓰임새는 그냥 보고 따라하기 나름입니다.

근데 C#은 왠지 좀 다른 세계의 이야기를 하는 거 같은 책들이 많습니다. MS에서 만들어서 윈도우에서만 쓰이니깐요? 그런 것도 있지만.. C#이 객체 지향 프로그래밍을 위한 언어인 것 뿐만 아니라 닷넷(.net)에 대해서도 좀 더 잘 알아둬야 한다는 점이 있습니다. 이 점이 유명하게 작용하면서도 타 플랫폼 개발자들이 요즘 윈도우 프로그래밍을 할 때 어렵게 느끼는 점입니다.

MS는 윈도우의 환경을 점차 통합해 가는 시기를 계속 거쳐왔습니다. 그리고 그 중심에 있는 것이 바로 닷넷 프레임워크(.net Framework)입니다. 닷넷 프레임워크는 클라이언트용 윈도우 뿐만 아니라 윈도우 서버 및 클라우드(애저 서비스), XBox와 Windows Phone에까지 적용될 정도로 수많은 MS 플랫폼에 적용됩니다. 그만큼 사용 범위도 넓기 때문에 요즘의 윈도우 프로그래밍을 위해선 알아둬야 합니다.

저도 다시 쓰면서 복습해야 하니 천천히 보죠. ㅇㅅㅇ

WPF를 공부할 때 좋은 책

요즘 WPF를 쓰고 있습니다. win32 프로그래밍 할 시기는 아닌 거 같고(해도 상관은 없지만…. 요즘 윈도우 아키텍쳐의 추세 상 안쓰는 걸 권장합니다), MFC 다시 쳐다보고 싶진 않고… 뭐, 어쩌다 보니 그냥 UI는 WPF로 하자란 결론이 나서 하고 있습니다만…

근데 WPF에 대해서는 “그냥 공부 좀 해두면 좋은 것이다”란 의식들이 강해서 그런건지 어떤지는 모르겠습니다만… 서적이 적습니다. 뭐, 대부분의 자료가 MSDN에 나와 있어서 어렵지 않게 공부할 수 있지만…. “그래도 난 굳이 책이 있어야 한다!” 라고 하시는 분들을 위해서 제가 지금 보는 책을 올릴께요.

왜 저 두 책이냐고 물으면 이렇게 대답하겠습니다.

“이 글을 쓰고 있는 당시 교보문고에서 절판되지 않은 WPF 책임. ㅡㅅㅡ”

책을 사려는 입장에서는 중요하죠. ㅇㅅㅇ

우선 저 밑에 있는 찰스 페졸드 아저씨의 책은…. 다들 아실 껍니다. 진짜 어렵습니다. 만약 이 글을 보고 계신 분이 “:난 찴스 아저씨와 똑같은 성격의 프로그래밍 하는 게 좋아서 밑에껄 봐야겠어!” 라고 하기엔 본인 실력은 뭔가 부족하죠. 게다가 아는 것도 적어요. (저 아저씨의 평을 생각하면 당연한 이야기) 그걸 어느정도 채워주면서 빠른 사용을 할 수 있는 게 위에 있는 책입니다. 저 두 책을 병행하면 다이나믹한 UI를 개발하는 데 필요한 건 다 해보실 수 있을 것이라고 보고 있습니다.

MS가 확실히 C#을 밀고 있단 것이 느껴지는군요..ㅇㅂㅇ

뭐랄까…..이게 은근 자잘하게 사용되는 라이브러리(클래스)라 할지라도 C++에서 쓰는 것과 C#에서 쓰는 것이 차이가 거의 없어지는군요. 특히 닷넷 버전이 올라가면 올라가는 부분과 언어가 계속 발전하면 발전할수록 말이죠…

그렇다면 이젠 개발하는 데 있어서 생산성을 중시해야 한다면…? (예전에는 그다지 생각하지 않았던 항목이지만, 요 근래에는 무지하게 생각하게 되었습니다. 특히, 본인이 코어 개발을 하는 사람이 아니라면 특히 더더욱 생각해야 한다고 생각합니다.)

그렇다면 점점 C#으로 넘어가는 것이 윈도우 프로그래밍에서는 좀 더 빠른 개발을 할 수 있는 거 같습니다. 결과물이 생각 외로 빨리 나와요.  자바가 한참 유행하고, 점점 더 고급 언어를 선호하던 시절에 프로토타입을 빨리 내서 빠른 개발을 하던 것이 지금에서도 일어나고 있습니다. 이런 현상을 본다면 C#으로 빠르게 개발하는 걸 나쁘게 볼 수 없다고 할 수 있죠.

사실 C++이던 C#이던 엄청나게 익숙해지면 대단히 빠르게 프로토타입을 만들어 낼 수 있습니다. 근데 모든 개발자들이 다 그런 건 아니거든요. 뭐 개발자가 소수 정예로 키워져서 뭐든지 다 할 수 있는 무적의 상태라면 몰라도….ㅡㅅㅡ

그리고 그걸 MS는 확실하게 보고 C#을 다듬어 오는 거 아닌가 싶습니다. 처음에는 자바를 모방했느니 뭐 그런 소리도 많았지만… 요즘은 어디에나 다 쓰이는 규칙들이고 하다보니 오히려 닷넷 환경으로 통합시키면서도 대표로 밀어주는 언어로써의 자리는 확실히 잡은 것으로 보여집니다.

오랜만에 하는 윈도우 프로그래밍에 이런 재밌는 걸 배워가네요.

리눅스와 C

리눅스의 대부분이 C언어로 작성되었고, 리눅스 수많은 어플리케이션을 C로 작성한다. 실제로 C로 작성된 프로그램도 상당수 존재한다. 따라서 리눅스 프로그래밍은 C프로그래밍을 의미한다. (거의 일반화된 예기)

또한 C 프로그래밍을 위한 환경을 리눅스에서는 기본적으로 제공하고 있다. C 컴파일러인 gcc, C 디버깅 툴인 gdb, C 컴파일 자동화 툴인 make 등을 기본적으로 제공한다.

결국 리눅스 환경에서 프로그래밍을 한다면 C는 계속 이용하게 될 것이다.

요즘 많은 언어들이 있어도 C는 안쓸 수 없을 것이다.

C언어

C언어는 제디느 리치와 켄 톰슨이 벨 연구소에서 유닉스를 개발하던 중 1972년 데니스 리치에 의해 개발되었다. 그리고 유닉스도 C언어로 구현되었다. 이러한 C언어는 뛰어난 기능과 융통성을 제공함으로써 여러 곳으로 빠르게 보급되어 많은 프로그래머(특히 1학년들…)에 의해 사용되기 시작하였다. 그러나 많은 프로그래머들이 자신이 사용하기 편리하게 C언어를 수정하기 시작하여 프로그램간에 호환성이 결여되고 표준 라이브러리 함수마저도 조금씩 달라지는 문제가 발생하였다. 이런 문제점을 해결하기 위해 ANSI에서는 1983년에 C 표준화를 위한 위원회를 결정했고, 1989년 ANSI 표준 C라고 알려진 표준안을 발표했다.

이러한 C언어는 유닉스, 리눅스와 같은 대부분의 시스템 소프트웨어를 구현하는 언어로, 고급 언어이면서 저급 언어처럼 비트나 바이트 처리, 그리고 포인터에 의한 주소 처리를 한다. 그리고 PC에서부터 대형 컴퓨터에 이르기까지 모두 사용할 수 있는 이식성이 뛰어난 언어다. 또한 구조화되어 있어 같은 기능을 구현하는 다른 언어보다 프로그램 코드 길이가 짧다는 장점이 있다. 이러한 장점 때문에 C언어의 명성은 앞으로도 계속 갈 것이다.