#076_닷넷(.NET)_.Net Framework 기본 - 어플리케이션 도메인

안녕하세요 삽잡이입니다.

프로그램을 나누라고 한다면 '응용 프로그램'과 'OS'로 나눌 수 있습니다.

여기서 응용프로그램을 이전에는 해당 어플리케이션에서 직접 로드를 했었습니다.

그런데, 닷넷에서는 기존의 Win32 응용 프로그램과 다르게,

실행 파일이 프로세스 내에 직접 호스팅 즉, 로딩되지 않습니다.

.Net의 실행파일은 바로 응용프로그램 도메인이라는 

논리적으로 격리된 프로세스에 호스팅 즉, 로드가 되지요.

응용프로그램 도메인을 어플리케이션 도메인이라고 부르는데,

도메인이라는 단어는 컴퓨터 용어에서 많이 사용됩니다.

공통적으로 도메인이라는 용어의 의미는 바로 '영역'을 뜻합니다.

즉, 어떤 틀을 짓는다는 느낌이지요.

그래서 어플리케이션 도메인이란 뭐냐?

프로세스란, 메모리상에 올라와 있는 프로그램이죠.

그런데 이 프로세스가 이전에는 항상 OS위에서 동작했었는데,

닷넷에서는 'CLR 이라는 런타임 위에서 프로세스가 동작한다' 로부터 나온 개념입니다.

닷넷에서의 어플리케이션은 진짜 프로세스가 아닙니다.

오해를 하시면 안되는데... 뭔말이냐하면... 

CLR을 통해서 OS에 맞도록 번역이 되는 것이지요.

OS에서 어플리케이션(이하 APP)이 동작할 때

CLR 입장에서 APP은 CLR위에서 동작하는 것처럼 보이지만,

실제로는 OS의 바이너리로 번역되지 않으면 동작하지 않습니다.

즉, OS 입장에서 CLR은 APP이 돌아가도록 도와주는 것일뿐

CLR에는 관심없고 실제로는 APP 하나를 동작시키는 것입니다.

단지 APP이 OS의 프로그램으로 동작하는 것인데,

OS의 바이너리로 APP이 변환이 되어야하기 때문에,

CLR 이 해당 바이너리로 변환작업을 해주는다는 것이죠.

따라서 OS의 입장에서는 APP이 CLR이 주물럭거리는 것을 모릅니다.

OS는 그냥 단지 CLR이 뭘 하는지를 모르고

APP이 동작하는 것만을 인지한다는 것입니다.

즉, 중간언어로 이루어진 프로세스가 CLR이라는 가상머신을 통해

해당 OS의 프로세스처럼 보이도록 만들어주는 것입니다.

그림은 저렇게 그렸어도,

사실 OS 입장에서는 CLR 위에 프로그램? 이라는 건 상상할 수 없는 일인것이지요.

그렇다는 의미는 APP을 CLR이 감추게 된다면 OS는 모른다 이겁니다.

왜냐? 닷넷에서 처음 만들어진 바이너리는 OS의 바이너리가 아닌 

Virtual 바이너리이기 때문입니다.

이 바이너리가 단지 CLR에 의해서 번역되어 실행되는 것이지요.

계속 반복하고 있습니다....

그런데, 위의 말을 이해하셨다면 한번 생각해봅시다.

CLR이 OS에게 APP을 감출 수 있다고 했으니,

그렇다는 것은, OS가 봤을 때는 프로세스가 하나일지라도,

CLR 내에서는 프로세스가 여러개가 될 수 있지 않겠습니까?

이전에 OS 바로 위에서 프로세스들이 동작할 때에는

.exe 파일 하나를 실행하면 한개의 프로세스가 되는 것이었습니다.

하지만, 닷넷에서는 CLR에 의해서 프로세스가 여러개가 될 수 있다 이것입니다.

이를 '어플리케이션 도메인'이라고 부르는 것이지요.

이전에는 프로프램을 실행시켜 메모리에 올라가게 되면 프로세스라고 불렀습니다.

이 때는 프로세스가 독립적으로 유지가 된다는 장점이 있었지요.

그런데 닷넷에서는,

APP이 실행되면 OS가 봤을 때에는 하나의 프로세스이지만,

닷넷의 프로세스로 보게 될 때에는 하나 이상의 프로세스가 될 수 있게됬습니다.

즉, n개 이상의 독립적인 메모리를 제공될 수 있다 이겁니다.

따라서, 해당 프로세스내에 하나의 메모리가 죽어도 

다른 메모리들은 살아있게 되지요.

중요한 것은 OS가 봤을 때에는 프로그램이 하나라는 것입니다.

닷넷에서 봤을 때에는 여러개로 나누어 사용할 수 있는데 말입니다.

이를 닷넷의 프로세스라고 부르며,

이를 지칭하는 용어롤 '어플리케이션 도메인'이라고 부른다는 것입니다.

반복적으로 설명을 드리고 있는데 어찌... 이해가 가십니까?

정리하면 '독립적으로 동작하는 닷넷의 프로세스'라고 할 수 있겠군요.

닷넷의 프로세스 내에 독립적이라는 것입니다.

우선 프로그램을 실행을 시키게 되면, 

default APP 도메인으로써, 프로세스 하나가 기본적으로 띄워지는 것이고

해당 프로세스가 또 sub APP 도메인들들인 프로세스를 띄울 수 있다 이겁니다.

기존에는 OS의 다른 프로세스끼리 통신하거나,

다른 PC의 프로세스와 통신을 하는 경우가 있었습니다.

그런데, 닷넷에서는 이제 하나의 경우가 더 추가가 된 것입니다.

그림을 보셔도 충분히 이해하실 수 있을것이라 믿습니다.

정리해봅시다.

어플리케이션 도메인이 뭘까요?

바로, '닷넷의 논리적인 프로세스'입니다.

OS가 봤을 때에는 진짜 프로세스가 아니라 닷넷의 프로세스이지요.

따라서 닷넷이 봤을 때는 프로세스 partition이라고 부를 수도 있겠군요.

왜 APP 도메인이라는 기능을 제공하는 것일까요?

닷넷은 기존의 것들보다 보다 '안정성'을 추구하기 때문에,

변수가 많은 네트워크, DB등의 작업을 처리하다가 프로세스가 죽어버릴 수 있기 때문에

이러한 것들을 APP Domain을 제공해줌으로써,

보다 안정적으로 프로세스가 동작할 수 있도록 도와주는 것입니다.

n개의 APP Domain이 있다면, 

1개의 APP Domain이 죽을지라도 나머지는 독립적으로 살아있기 때문에

OS의 입장에서는 프로세스가 살아있다고 판단하는 것이지요.

왜냐하면, CLR위에서 n개의 APP Domain으로 나눠놨기 때문이지요.

이 뜻은,

APP 도메인에 어셈블리가 하나 로드되더라도,

하나의 APP 도메인에서만 실행이 되는 것이기 때문에,

완벽하게 독립적으로 APP 도메인을 나눌 수 있다는 것을 의미하는 것입니다.

따라서 '격리 수준'이 높다고 할 수 있는 것이지요.

이번 시간은 여기까지 하도록 하겠습니다.

이상 삽잡이였습니다!