수안이의 컴퓨터 연구실 :: 닷넷과 리치 클라이언트 이해 2

김경윤 (redstrato@elasticware.com)

지난 달에 윈도우 서버 2003과 비주얼 스튜디오 닷넷 2003이 출시됐다. 윈도우 서버 2003에는 닷넷 프레임워크 1.1 버전이 기본으로 포함되며 VS.NET 2003도 1.1 버전을 바탕으로 하고 있다. 지난 호에 이어 이번 호에서는 닷넷 WinForms 애플리케이션인 스마트 클라이언트에 대해 알아보고, 덧붙여 응용 프로그램 배포와 보안에 관련해 1.1 버전에서 변화된 부분을 함께 살펴보자.

자바 애플릿이 등장했을 때 많은 사람들이 열광했던 기억이 아직도 선하다. 사람들은 인터넷을 통해 자연스럽게 코드가 배포되어 수행되는 ‘분산 코드’ 환경을 보면서 이것이 인터넷이 나갈 길이라고 이야기를 했었다. 플랫폼에 구애받지 않는 *.class 파일이 서버나 클라이언트에서 동일하게 수행될 것을 기대했던 것이다. 그러나 요즘은 그런 기대가 많이 줄어든 것이 사실이며, 실제로 애플릿 개발 이슈가 점차 줄어들고 있다. 자바 애플릿은 액티브X와 경쟁을 해야 했고, 플래시 같은 고성능의 리치 클라이언트 환경에 밀리고, 닷넷의 스마트 클라이언트의 도전을 받고 있다.

보험사 영업사원 지원을 위한 스마트 클라이언트 시나리오
리치 클라이언트를 필요로 하는 곳은 매우 다양하겠지만, 실제 어떻게 적용될 수 있는지 좀더 구체적인 한 가지 예를 가지고 생각해 보려고 한다. ‘보험사 영업사원 지원’이라는 주제를 가지고 접근해 보자.
A보험사는 아주 다양한 보험 상품들을 가지고 있으며, 하루가 멀다 하고 새로운 상품이 설계되어 나온다. 이들 상품의 가격과 보험 요율은 고객의 특성과 조건에 따라 아주 다양한 방법으로 계산된다. 이 계산 방법은 몇 가지 요소만으로 계산될 수 없기 때문에 각 상품마다 매우 독특한 계산 로직이 따로 존재한다. 또한 매일매일 상품에 대한 조건이나 적용되는 요율이 변화하기 때문에 계산식과 계산에 필요한 수치 값을 항상 최신으로 유지해야 한다. 이 회사의 영업사원들은 매일 아침 회사에 출근하여 변화된 요율이나 새로운 상품에 대한 정보를 자신의 노트북에 업데이트한다. 이 회사의 영업사원들의 노트북에는 고객과 상담할 때 사용하는 프로그램이 들어 있는데, 이것은 매우 복잡한 애플리케이션이다. 자주 일어나는 일은 아니지만, 고객에게 다양한 그래프와 정보를 제공하기 위해 애플리케이션의 일부 기능이 업데이트돼야 하는 경우도 생긴다. 이 A보험사는 다음과 같은 요건을 충족하고 싶다.

① 응용 프로그램에서 사용하는 데이터가 항상 최신의 것이어야 한다 : 네트워크에 연결되면, 클라이언트 애플리케이션은 서버에 변화된 내용이 있는지 확인하고, 최신의 데이터를 자동으로 받아와 클라이언트 데이터베이스를 갱신해야 한다.
② 응용 프로그램의 배포와 버전 관리가 자동으로 이뤄져야 한다 : 네트워크에 연결되면, 클라이언트에 설치된 프로그램의 일부 기능을 업데이트해야 하는지를 자동으로 확인해 필요한 경우 일부 기능을 자동 업데이트해야 한다(전체를 다시 설치하면 너무 많은 시간이 소요되기 때문).
③ 보험 상품을 계산하는 데 필요한 로직이 데이터와 함께 배포될 수 있어야 한다 : 특정 보험 상품은 일반적인 몇 개의 공식만으로 계산되지 않는다. 상품별로 독자적인 계산 로직을 가질 수 있어야 한다.
④ 보험 상품을 계산하는 데 필요한 로직이 서버와 클라이언트 양쪽에 같이 사용될 수 있어야 한다 : 한 번 만들어진 로직은 별다른 절차 없이도 서버와 클라이언트에서 똑같이 쓰일 수 있어야 한다(서버의 계산 로직은 웹으로 서비스되는데 사용되며, 클라이언트의 계산 로직은 고객을 직접 응대할 때 사용된다).
⑤ 보안성이 있어야 한다 : 로직을 담은 코드나 데이터 송수신 등에 보안성이 보장돼야 한다. 또한 배포된 계산 로직은 사용 허가를 받은 클라이언트에서만 수행돼야 한다.
⑥ 오프라인 지원 : 항상 네트워크에 연결되어 있는 것이 아니므로, 연결되어 있지 않은 상황에서도 모든 기능이 수행될 수 있어야 하며, 이때 생성된 데이터는 인터넷에 연결시 서버에 반영된다.
⑦ 풍부한 그래픽 화면과 다양한 표현이 가능해야 한다 : 고객에게 보여주는 화면이므로 풍부하고 다양한 그래픽 표현이 가능해야 한다.

이렇게 다양하고 다소 복잡해 보이는 요구사항이 어떻게 닷넷의 리치 클라이언트로 가능한지 보안 문제를 시작으로 차근차근 살펴보자.

코드 액세스 보안
닷넷 환경에서 실행되는 모든 코드에 코드 액세스 보안이 적용된다. 이는 닷넷 런타임이 신뢰 수준에 따라 코드를 관리하여 악의적인 코드의 실행을 미연에 방지하고 이를 확신하게 해주는 것이다. 예를 들어 네트워크 드라이브나 인터넷에서 실행한 코드가 로컬의 파일 시스템에 접근하려 한다든가 레지스트리를 조작하려 한다면 SecurityException이 발생한다. 우리들이 인터넷에서 액티브X 등의 실행 코드를 다운받아 설치하면서 뭔가 꺼림직함을 느끼는 것은 우리가 ‘OK’ 하는 순간 그 코드가 무슨 악의적인 행동을 해도 막을 수가 없기 때문이다. 물론 서명을 받은 것이라고 해도 그런 느낌은 지울 수가 없었다. 하지만 닷넷의 관리되는 코드로 작성된 애플리케이션은 어떠한 악의적인 코드도 수행할 수 없는 보호된 환경에서 그 코드를 수행할 수 있음을 의미한다. System.Windows.Forms, System.Drawing 네임스페이스 등을 이용한 풍부한(rich) 기능을 활용할 수가 있다는 것이 관리되는 코드의 큰 이점이라고 할 수 있다.
코드 액세스 보안은 코드 그룹과 권한 개념에 기반을 두고 있다. 각각의 코드 그룹은 그에 해당하는 권한 집합을 갖고 있으며 실행되는 코드는 자신이 속하는 코드 그룹에 따라 실행할 수 있는 권한이 정해진다. 코드 그룹은 영역(zone), 사이트(site), Strong name, 게시자 등의 멤버십 조건을 가지는데, 가장 흔히 사용되는 조건이 영역이다.
지난 호의 예제에서 여러분은 많은 의문점을 발견했을 것이다. WinForms 컨트롤이 임베딩된 웹 페이지를 요청할 때 http:// localhost~로 시작했을 때와 http://[로컬 머신 이름]/~로 시작했을 때, 그리고 http://127.0.0.1/~ 등 여러 가지로 테스트해 보았다면 어떤 때는 컨트롤이 제대로 보이고 어떤 때는 안보이는 경우를 접했을 것이다. 또 이 페이지와 컨트롤을 다른 컴퓨터의 웹 서버에 올려서 테스트했을 때도 여러 가지 경우를 겪었을 것이다. 이것은 인터넷 익스플로러 하단의 상태 바(<화면 1>)를 보면 바로 확인할 수 있는데, 앞의 두 경우(localhost, 로컬 머신 이름)에는 ‘로컬 인트라넷’이라고 표시되고, 127.0.0.1의 IP 주소를 사용했을 경우 ‘인터넷’이라고 표시된다.
이와 같이 영역에 따라 코드 그룹이 결정되는데, IP 주소를 사용해 ‘인터넷’ 코드 그룹에 속한 경우에는 닷넷 프레임워크 1.0에서는 기본으로 실행 권한이 없다. 하지만 닷넷 프레임워크 1.1 버전에서는 코드 그룹이 ‘인터넷’인 경우에도 부분적인 실행 권한을 가진다. <화면 2>에서 보듯 닷넷 프레임워크 컴포넌트에 대한 설정이 인터넷 익스플로러의 보안 설정에 추가된 것을 볼 수 있다. 필자의 생각으로는 버전 1.1에서 코드 액세스 보안의 기능이 더욱 강화되었기 때문에 그렇게 정책이 바뀐 것 같다. 이는 코드 액세스 보안 정책 도구(caspol.exe)를 통해 확인해 볼 수 있다. 그리고 이 도구를 사용하여 좀더 세밀한 보안 정책을 수립할 수 있다. 하지만 이번 연재의 범위에서 벗어나는 내용이므로 관련 서적이나 닷넷 프레임워크 설명서 등을 통해 확인하기 바란다.