어떤 기술이든지, 그 작동 방식을 아는 것은 대단히 중요합니다. SOAP과 XML을 전혀 모르고 웹 서비스를 작성하는 것과 그렇지 않은 것의 차이는 매우 심하게 나듯이 스마트 클라이언트의 작동 방식을 아는 것 역시 매우 중요합니다. 이 글의 내용이 당장 이해가 잘 안되더라도 다음에 설명할 스마트 클라이언트 내용에서 자주 참조될 것이니 그 때 다시 읽어보시면 이해가 갈 수(?)도 있습니다. 이 글이 널리 도움이 되길 바리며 또 몇 자 씨부려 볼까 합니다...

• 스마트 클라이언트, 그것을 알려주마 (I) : 개요
• 스마트 클라이언트, 그것을 알려주마 (II) : 맛보기 예제
• 스마트 클라이언트, 그것을 알려주마 (III) : 작동 원리
• 스마트 클라이언트, 그것을 알려주마 (IV) : App Base Directory & Configuration
• 스마트 클라이언트, 그것을 알려주마 (V) : Trouble Shooting
• 스마트 클라이언트, 그것을 알려주마 (VI) : CAS Fundamentals
• 스마트 클라이언트, 그것을 알려주마 (VII) : CAS Deployment
• 스마트 클라이언트, 그것을 알려주마 (VIII) : Assembly Deployment (1)
• 스마트 클라이언트, 그것을 알려주마 (IX) : Assembly Deployment (2)

Smart Client (III) : Under the hood

서두에서 이야기 했듯이 닷넷 스마트 클라이언트의 자료를 찾기란 쉽지 않다. 기껏 찾은 자료는 지난 두 번째 포스트처럼 따라 하기 수준의 도입 글 수준에 머무르기 일쑤이며, 상세한 내용은 어쩌다가 그것도 우연히 발견하는 경우가 많다. 필자의 경우도 그렇다. 스마트 클라이언트 프로젝트는 해야겠는데 자료는 없는데다가, 스마트 클라이언트가 버그가 있다는 둥, 무조건 DLL이 다운로드 된다는 둥(치명적이다 !!)의 소문까지 떠돌았으니 말이다.

겨우 한두 가지 관련 정보를 찾은 필자는 이것을 실마리로 여러 가지 테스트를 수행해 보고, Reflector로 열심히 여러 DLL 들을 까본 다음에야 대충 감을 잡을 수 있었다. 물론 필자가 스마트 클라이언트의 작동 방식을 완전히 알고 있다는 것은 아니다. 여전히 특정 부분은 어떻게 이것이 작동하는지 필자도 알 수 없는 상황이다. 다만 필자가 알고 잇는 수준이라도 스마트 클라이언트에 농락당하는 여러 개발자들과 함께하고자 하는 마음에(오오... 드뎌 내가 미쳤나 보다... -_-;) 시간을 쪼개서 (맨날 놀잖아 !!!) 글을 써 본다.

Smart Client Engine: Mime Filter

웹 서버가 URL에 의해 콘텐트(content; 컨텐츠라고 하고 싶지만 이게 표준어란다)를 다운로드 해줄 때는 그것이 정적 .htm 파일이건 동적인 .aspx, .jsp 등 이건 관계 없이 콘텐트의 타입을 명시하도록 되어 있다. 콘텐트 타입이라 함은 HTTP Content-Type 헤더를 통해 콘텐트의 내용이 HTML 문서인지 XML 문서인지? Excel 파일인지 등을 명시하는 것을 말한다. 가끔 웹 서버에 따라서 Content-Type 헤더를 알려주지 않는 경우도 있는데, 이런 경우 IE는 콘텐트 타입을 결정하기 위해 몇 가지 작업을 거치게 된다. IE가 콘텐트 타입을 결정하는 것에 대한 상세한 내용은 MSDN 문서(MIME Type Detection in Internet Explorer)를 참고하기 바란다.

그건 그렇고... 이 콘텐트 타입은 MIME 타입이라고도 불리며 표준화된 이름을 가지고 있다. 예를 들어 HTML 문서의 MIME 타입 이름은 text/html 이며 XML 문서의 MIME 타입 이름은 text/xml 이다. 그런데 이러한 특정한 부류에 속하지 않는 바이너리 파일인 경우, 웹 서버는 MIME 타입을 applicaiton/octet-stream 으로 설정하곤 한다. 이는 웹 서버 마다 다를 수 있지만, 대개의 경우 application/octet-stream이 사용된다. IIS의 경우, DLL, EXE가 URL 링크에 의해 다운로드 될 때는 application/octet-stream MIME 타입이 사용되고 OBJECT 태그에 의해 DLL이 다운로드 될 때는 application/x-msdownload MIME 타입이 사용된다.

브라우저 임베디드 스마트 클라이언트 혹은 독립 스마트 클라이언트는 모두 IE의 콘텐트 다운로드 기능과 연관이 있다. 정확히 말하자면 COM의 URL 모니커를 통해 다운로드 되는데, IE가 URL 모니커를 통해 파일을 다운로드 하도록 되어 있기 때문이다. URL 모니커를 이야기 하자면 너무 복잡하기 때문에 더 이상 URL 모니커에 대해선 상세히 운운하지 않겠다. 그냥 그런 것이 있다고만 생각해도 좋다.

어찌 되었건 IE가 URL 모니커를 통해 콘텐트(파일)을 다운로드 하면 이 콘텐트의 MIME 타입을 분석하여, 등록된 MIME 필터가 존재하는가를 살핀다. MIME 필터는 말 그대로 특정 MIME 타입에 대해 필터링을 제공하여 콘텐트를 변경하는 등의 기능을 제공하는 IE의 기능을 말한다(MIME 필터는 Asynchronous Pluggable Protocol 기술의 한 종류로서 상세한 내용은 MSDN을 참고하도록 한다). 만약 해당 MIME 타입에 MIME 필터가 등록되어 있다면 URL 모니커는 이 MIME 필터에게 콘텐트를 액세스하도록 제어를 넘긴다. XML 문서가 브라우저에 표시될 때 XML 요소(element)가 트리뷰 처럼 펼쳐지도록 하는 것 역시 text/xml MIME 타입에 대한 MIME 필터가 수행해 주는 기능이다. MIME 필터는 레지스트리의 HKEY_CLASSES_ROOT\PROTOCOLS\Filter 키의 하위에 각 MIME 타입 별로 등록되어 있다.

닷넷 프레임워크가 설치되면 application/octet-stream, application/x-msdownload, application/x-complus 타입에 대한 MIME 필터를 등록한다. 이 MIME 필터는 다운로드 된 콘텐트가 닷넷 어셈블리 PE(Portable Executable) 파일, 즉 닷넷 DLL 혹은 EXE 인가를 확인한다. 만약 그렇다면 닷넷 CLR을 구동하여 스마트 클라이언트가 구동되게 되는 것이다! (뭐 닷넷 어셈블리가 아니라면 아무런 짓도 하지 않겠지?)

확인을 위해 HKEY_CLASSES_ROOT\PROTOCOLS\Filter 키의 하위에 등록된 application/octet-stream 타입에 대한 MIME 필터 설정을 살펴보자(화면1). CLSID 가 {1E66F26B-79EE-11D2-8710-00C04F79ED0D} 이라고 되어 있는데 이 COM 객체를 다시 레지스트리에서 찾아보면 HKEY_CLASSES_ROOT\CLSID\{1E66F26B-79EE-11D2-8710-00C04F79ED0D} 키에 등록되어 있으며, 이것의 이름은 Cor MIME Filter로서 닷넷 프레임워크 엔진(mscoree.dll)에 의해 제공되는 COM 객체임을 알 수 있다.

화면1. MIME 필터 등록 상황

굳이 이런 테스트까지 해볼 필요는 없지만, 등록된 세 MIME 필터(application/octet-stream, application/x-complus, application/x-msdownload)를 레지스트리에서 삭제하고(먼저 백업해두는 것은 필수닷!) 스마트 클라이언트 예제를 수행해 보면 전혀 작동하지 않음을 알 수 있다.

닷넷 프레임워크의 MIME 필터가 정확히 무엇을 하는가는 알려진 바가 없다. 필자 역시 이놈의 것이 정확하게 무슨 일을 하는가 알아낼 방법이 없었다. 다만, MIME 필터는 CLR을 적재하고 OBJECT 태그에 의해 MIME 필터가 작동했는지(브라우저 임베디드 스마트 클라이언트), URL 링크에 의해 MIME 필터(독립 스마트 클라이언트)가 작동했는지에 따라서 다른 행동을 한다는 것이다. 이제 각 시나리오 별로 어떻게 스마트 클라이언트가 구동되는지 살펴보자.

Starting Smart Client : Browser Embedded Scenario

OBJECT 태그에 의해 닷넷 스마트 클라이언트가 구동되는 시나리오를 살펴보면, IE가 DLL을 다운로드 하고 MIME 필터에 의해 CLR이 구동된다는 것은 이미 설명하였고... URL 모니커와 닷넷 MIME 필터의 알려지지 않은 메카니즘(아무리 알아보려 해도 한계가 있었다. 쓰바... -_-)을 통해 IEHost.dll 어셈블리가 구동된다. IEHost.dll 은 Reflector로 까볼 수 있는 닷넷 어셈블리로서 닷넷 프레임워크와 함께 설치된다. IEHost.dll 의 주요 임무는 스마트 클라이언트가 수행될 어플리케이션 도메인(AppDomain; application domain)을 생성하고 이 AppDomain에 스마트 클라이언트 클래스의 인스턴스를 만드는 일이다. 즉, OBJECT 태그의 clsid 속성이 나타내는 클래스의 인스턴스를 만든다는 것이다. 지난 포스트의 예라면 ClientModule.UIControl 클래스의 인스턴스가 되겠다.

왜 IEHost.dll 은AppDomain을 작성할까? 모든 닷넷 어플리케이션은 디폴트 AppDomain을 가지고 있기 때문에 이 AppDomain을 사용해도 될 것 같은데 말이다. 이는 서로 다른 사이트에서 다운로드 받은 스마트 클라이언트가 서로를 액세스 하지 못하도록 하기 위함이다. 예를 들어, somebank.com 에서 다운로드 한 스마트 클라이언트가 신용카드 정보를 메모리에 보유한다고 가정해 보자. 그런데, badguy.com 에서 다운로드 받은 DLL이 같은 AppDomain에 적재된다면 충분히 신용카드 정보를 읽을 수 있기 때문이다. 브라우저에 호스팅 되는 스마트 클라이언트는 하나의 프로세스를 공유하고 있음을 기억하자. 이런 이유로 IEHost.dll은 다운로드 받은 DLL의 사이트 별로 AppDomain을 생성한다. 즉, somebank.com 에서 다운로드 한 DLL은 이름이 somebank.com 인 AppDomain에 로드 되고, badguy.com 에서 다운로드 한 DLL은 이름이 badguy.com 인 AppDomain에 로드 되는 것이다. 서로 다른 도메인에 존재하는 어셈블리는 서로를 직접적으로 액세스 할 수 없기 때문에 안전할 수 있는 것이다. 이는 브라우저가 한 사이트에서 수신한 쿠키(cookie)를 다른 사이트로 전송하지 않거나, 한 사이트의 콘텐트에 포함된 스크립트가 다른 사이트에 대한 쿠키를 액세스할 수 없는 것과 동일한 이유라고 보면 되겠다.

IEHost.dll 이 AppDomain을 만드는 이유는 보안적인 이유 외에도 AppDomain의 베이스 디렉터리를 설정하는 중요한 작업을 수행해야 하기 때문이다. AppDomain의 베이스 디렉터리는 CLR이 어셈블리를 찾을 때 기준이 되는 디렉터리를 말한다. CLR이 어셈블리를 로드 할 때 어셈블리가 강력한 이름(strong name)을 갖고 있다면 먼저 GAC(Global Assembly Cache)을 찾는다. 그리고 GAC에서 어셈블리를 찾지 못한 경우, AppDomain의 베이스 디렉터리를 기준으로 해당 어셈블리를 찾게 되는 것이다. 일반적으로 EXE 어셈블리가 존재하는 디렉터리가 베이스 디렉터리로 설정되곤 한다. 하지만 브라우저 임베디드 스마트 클라이언트는 AppDomain을 새로 생성하면서 베이스 디렉터리를 DLL을 다운로드 한 사이트 URL을 베이스 디렉터리로 설정한다. 정확히 어떤 URL이 베이스 디렉터리로 설정되는 가에 대해서는 다른 포스트에서 설정 파일(configuration file)을 설명하면서 다시 언급하기로 하고, 어찌 되었건 IEHost.dll의 중요한 임무 중 하나가 AppDomain 생성과 더불어 이 AppDomain의 베이스 디렉터리를 URL로 설정함에 유의하자. AppDomain의 베이스 디렉터리가 URL로 설정됨에 따라서, 스마트 클라이언트 어셈블리가 참조하는 다른 어셈블리를 찾을 때, 베이스 디렉터리로 설정된 URL에 다운로드가 시도된다는 점도 알아 두자. 나중에 다시 상세히 설명할 것이니 오늘은 이 정도만 알아두고 넘어가자.

그림1. IExplore.exe 프로세스 내에서 스마트 클라이언트 AppDomain 상황

그림1은 브라우저에 임베딩 된 스마트 클라이언트의 AppDomain 상황을 보여주고 있다. 서로 다른 두 사이트(localhost.com, www.simpleisbest.com)에서 스마트 클라이언트를 다운로드 한 경우, 2개의 AppDomain이 생성되며 각각의 AppDomain은 자신만의 고유한 힙과 어셈블리 등을 갖고 있다. 또한 각 AppDomain의 베이스 디렉터리 역시 서로 다름에 유의하자.

일단 생성된 AppDomain은 웹 페이지의 내용이 바뀌거나 심지어 다른 사이트로 이동하더라도 브라우저 프로세스가 종료되기 전까지는 계속 남아 있게 된다. 즉, AppDomain 이 Unload 되는 경우는 없다. AppDomain이 Unload 되지 않는 다는 것은 여러 가지 중요한 의미를 갖는다. 첫째로, 로드 된 어셈블리는 AppDomain이 Unload 되는 경우에만 메모리에서 제거된다. 이는 서버상에 아무리 새로운 버전의 스마트 클라이언트 DLL을 올려놓더라도 이미 수행중인 브라우저 프로세스 상에서는 새로운 버전이 적용되지 않음을 의미한다. 둘째로, AppDomain의 힙(heap) 역시 제거되지 않은 채로 존재하기 때문에 클래스의 static 멤버들의 값 역시 그대로 남아 있게 된다. 브라우저가 다른 페이지로 이동한 후, 다시 원래 페이지로 이동하는 경우를 생각해 보자. 이 때, OBJECT 태그에 의해 명시된 스마트 클라이언트 클래스의 인스턴스가 새로이 생성되겠지만 클래스의 static 멤버는 여전히 이전 값을 유지한다는 말이다.

그렇다면 이미 특정 사이트에 대한 AppDomain이 생성된 상태라면 IEHost.dll 은 무슨 일을 할까? 당연 빤쑤로 이미 만들어진 AppDomain에 다운로드 받은 어셈블리(OBJECT 태그의 clsid 속성이 나타내는 어셈블리)를 로드하고, 해당 AppDomain 안에다 스마트 클라이언트 클래스의 인스턴스를 생성할 것이다. 물론 어셈블리가 이미 로드 되어 있다면, 이미 로드 된 어셈블리가 사용될 것이다.

생성된 인스턴스는 브라우저에게 반환되며, 브라우저는 이제 표준적인 OBJECT 태그 처리와 똑같은 작업을 수행한다. 이 말 역시 중요한 의미를 갖는데, 브라우저에게 있어서 스마트 클라이언트는 일반적인 ActiveX 컨트롤과 다를 게 전혀 없다는 것이다. 브라우저는 ActiveX 컨트롤을 제어할 때와 완전히 동일한 방법으로 화면에 스마트 클라이언트를 표시할 것이다. 따라서 스마트 클라이언트로 표시될 닷넷의 인스턴스는 ActiveX에 관련된 구현을 포함하고 있어야 한다. 멋지게도 System.Windows.Forms.Control 클래스는 ActiveX 컨트롤이 갖추어야 할 모든 COM 인터페이스를 모두 구현하고 있다. 그리고 UserControl 클래스는 Control 클래스에서 파생된 클래스 임을 생각해 보면, 브라우저 내부에서 닷넷 UserControl이 나타나는 것은 자연스러운(?) 일이 되는 것이다.

Starting Smart Client: Stand-alone Scenario

브라우저 주소 창에 EXE에 대한 URL을 직접 입력하거나, EXE에 대한 링크(A 태그)를 클릭하는 경우 역시, 닷넷의 MIME 필터에 의해 독립 스마트 클라이언트가 구동되는 것은 동일하다. 브라우저 임베디드 시나리오와 다른 점은 브라우저 내부가 아닌 별도의 프로세스가 수행된다는 점인데, 어떻게 MIME 필터가 별도의 프로세스를 구동하는 지는 필자도 정확하게 말할 수 없다(아무리 짱구를 굴리고 몇가지 테스트를 해봐도 잘 모르겠다... 더 테스트 해볼 수도 있지만 귀차니즘이 엄습해 와서리... -_-). 아무튼 MIME 필터에 의해 IEExec.exe 프로세스가 구동된다는 것만 만은 확실하다. 그리고 IEExec.exe 프로세스가 독립 스마트 클라이언트 시나리오의 핵심적인 역할을 수행한다.

IEExec.exe 프로세스는 닷넷으로 구현된 어셈블리이다. MIME 필터는(혹은 그 뒤에 감추어진 어떤 것이) 이 프로세스를 구동할 때 커맨드 라인(command line) 매개변수로 다운로드 받은 EXE 파일의 URL을 넘겨주도록 되어 있다. IEExec.exe 내의 Main 메쏘드는 이 URL을 기반으로 자신의 작업을 수행할 것이다. 한 닷넷 한다는 독자나 호기심이 많은 독자라면 IEExec.exe 를 Reflector로 까보는 것도 재미있는 작업일 것이다.

IEExec.exe는 먼저 AppDomain을 생성한다. AppDomain을 생성하는 이유는 브라우저 임베디드 시나리오를 설명할 때 이미 설명했다. 다른 점은 보안의 이유보다는 베이스 디렉터리를 설정하기 위해 AppDomain을 생성한다고 봐야 한다. 왜냐 하면 URL이 주어질 때마다, 혹은 링크를 클릭할 때 마다 별도의 IEExec.exe 프로세스가 여러 개 수행되므로 프로세스 보호와는 무관하기 때문이다. AppDomain을 생성하고 IEExec.exe는 생성한 AppDomain에 대해 다운로드 받은 어셈블리를 로드 하는데, 이 때 호출되는 메쏘드는 AppDomain.LoadFrom() 메쏘드이며, 매개변수로는 IEExec.exe의 커맨드 라인으로 넘겨받은 URL을 사용한다. 이 때문에, 스마트 클라이언트 EXE는 다운로드를 한번 더 하게 된다. 물론, 브라우저 캐시에 의해 물리적으로 다운로드가 안 될 가능성이 높지만 웹 서버를 한 번 더 호출하는 수고를 IEExec.exe는 마다하지 않는다.

이미 다운로드 받은 EXE를 왜 또 LoadFrom을 호출하여 한 번 더 다운로드 받을까? 다운로드 받은 EXE는 이미 로컬 컴퓨터의 브라우저 캐시 디렉터리에 존재할 텐데 말이다. 이유는 간단하다. CAS 보안 때문이다. 로컬 캐시에 존재하는 EXE 파일에 대해 LoadFrom을 호출해버리면 어셈블리는 로컬 컴퓨터에서 로드 되게 될 것이다. 그러나 로컬 컴퓨터에서 로드 된 어셈블리는 CAS 기본 설정상 FullTrust가 되어 버리기 때문에 CAS 보안 설정을 적용시킬 수 없게 된다. 이 때문에 IEExec.exe는 주어진 URL을 이용하여 LoadFrom을 호출하는 것이다. 이 과정을 확인하고 싶다면 Fiddler를 사용하면 된다. Fiddler를 사용하여 독립 스마트 클라이언트가 구동될 때 주어진 EXE를 다운로드 하기 위해 몇 번의 웹 서버 호출이 이루어지는지 살펴보기 바란다. 그림2는 독립 스마트 클라이언트 상황에서의 AppDomain 상황을 보여주고 있다.

그림 2. 독립 스마트 클라이언트와 AppDomain

What's Next

닷넷 스마트 클라이언트가 작동할 수 있는 근본은 닷넷 프레임워크에서 제공하는 특수한 MIME 필터에 의해서이다. 이 MIME 필터는 다운로드 되는 파일이 닷넷 어셈블리 PE 파일이라면 적절한 스마트 클라이언트 구동 코드를 수행 시킬 것이다. OBJECT 태그에 의해 닷넷 어셈블리가 로드 된다면 IEHost.dll 에 의해, URL 링크에 의해 닷넷 EXE가 로드 된다면 IEExec.exe 에 의해 어플리케이션을 수행시킬 AppDomain이 생성되고 스마트 클라이언트가 구동되게 된다. 생성된 AppDomain은 CAS 보안 설정을 따르도록 설정이 강제되며, 어셈블리 로드를 위해 베이스 디렉터리 역시 URL로 설정되게 된다.

다음 포스트에서는 생성된 AppDomain의 베이스 디렉터리가 어떤 의미를 갖는지 살펴보도록 하겠다. 또한 생성된 AppDomain은 어떤 configuration 파일을 사용하는지 역시 살펴보도록 하겠다. 다음 포스트에서 다룰 내용은 스마트 클라이언트 시나리오를 통해 배포할 DLL 들을 웹 서버의 어디에 두어야 할 것인가를 결정하는데 중요한 의미를 가지므로 잘 이해를 해야만 한다.