IIS 7.0 인스퍼레이션 01.

드디어 마이크로소프트의 새로운 운영체제 제품군인 윈도우 비스타가 각 에디션별로 정식 출시되었다. 그와 더불어 비스타 제품군을 통해 새롭게 제시된 다채로운 신기술들과 기반 구조들이 개발자들을 위시한 관련업계 종사자들의 폭넓은 주목을 받고 있는 중이다. 결과적으로 개발자들은 본인이 원하든 원하지 않든 간에 불가항력적인 변화의 물결을 이겨내야만 하는 시점이 다시 한 번 도래한 것이다. 그리고, 본문을 시작으로 앞으로 계속될 몇 편의 글들을 빌어 논의하고자 하는 IIS 7.0 또한 기존 버전과 비교하여 비약적인 발전이 이루어 졌으며 최종적으로는 개발자들과 서버 관리자들의 작업 환경에 무지막지한 파급 효과를 불러일으킬 것이라는 것이 필자의 판단이다. 미상불 우리 웹 개발자들도 거대한 물결의 흐름을 벗어날 수는 없는 것이다. 먼저, 이번 글에서는 기술적인 관점에서 IIS 7.0의 보다 깊은 부분들을 살펴보기 위한 전단계로, IIS 7.0을 설치하는 전반적인 방법을 살펴보고자 한다. 지금까지 IIS의 다른 버전들을 이미 능숙하게 다뤄오신 분들은 그리 별다를 것 없는 주제라고 생각하실 수도 있겠지만, 감히 단언컨데 그 생각은 절대로 오산이다. 아마 본문을 다 읽고 나면 과거 IIS 3.0에서 IIS 4.0으로 업그레이드 하고 나서 느꼈던 것과 비슷한 기분을 경험하게 되는 분들이 분명히 계시리라고 믿는다.

그러면 본격적인 논의를 진행해 나가기에 앞서, 먼저 현재 출시되어 있는 비스타와 코드네임 롱혼 서버 제품군의 개발 현황을 다시 한 번 되짚어보도록 하자. 2007년 3월 말 현재, 비스타 제품군은 이미 정식 출시되었으며, 비스타의 서버 제품군에 해당하는 코드네임 롱혼 서버는 바야흐로 베타 테스트와 개발이 한창 진행되고 있는 중이다. 그리고, 현재 MSDN Subscription을 통해서 다운로드 받을 수 있는 롱혼 서버의 가장 최신 버전은 x86을 기준으로 Windows Server Longhorn February 2007 CTP 버전이다. 그런데, 이 시점에서 한 번 주의 깊게 생각해봐야 될 부분이 있다. 너무도 당연한 얘기겠지만 현재 개발이 한창 진행되고 있는 롱혼 서버에도 IIS 7.0은 포함되어 있다. 그렇다면, 이 롱혼 서버에 포함된 IIS 7.0은 개발이 완료된 것일까? 다시 말해 비스타에서 제공되는 IIS 7.0과 롱혼 서버의 IIS 7.0은 동일한 버전이며 단지 서버 전용으로 약간의 기능들만이 확장된 버전에 불과한 것일 뿐일까? 아쉽게도 - 사실은 너무나도 행복하게도 - 정답은 '그렇지 않다.'가 맞다. 이는 필자가 IIS MVP의 자격으로 참가할 수 있었던 금년도 2007 MVP Global Summit에서 IIS 개발팀으로부터 직접 확인한 내용으로 롱혼 서버에 포함된 IIS 7.0은 현재도 많은 개선 작업과 조정 작업이 이루어지고 있는 중이다. IIS 개발팀의 말에 따르면 비스타에서 제공되는 IIS 7.0은 롱혼 서버의 정식 출시 시점에 즈음하여 서비스 팩 등의 방법을 통해 새롭게 업그레이드 될 예정이라고 한다.

그래서, 필자는 본문에서 IIS 7.0의 설치를 살펴보기 위해 사용할 운영체제의 버전을 비스타가 아닌 롱혼으로 결정했는데, 사실 이 롱혼은 마이크로소프트가 제공하는 일반적인 채널을 통해서 얻을 수 있는 버전은 아니며 2007 MVP Global Summit에서 IIS 프로덕트 유닛 프로그램 메니저인 크리스 애덤스(Chris Adams)씨로부터 제공받은 버전으로서 아마도 현재 시점에서 당분간은 롱혼 서버의 IIS 7.0의 가장 최신 모습을 살펴볼 수 있는 버전이지 않을까 하는 생각이다. 그리고, 한 가지 명확하게 밝히고 넘어갈 부분은 본문에서 이루어지는 모든 기술적 또는 비기술적인 논의는 필자의 개인적인 생각과 의견만을 반영하고 있을 뿐이며 마이크로소프트는 본문의 내용에 대한 그 어떠한 보증도 하지 않는다는 점이다.

비스타와 롱혼 서버에 IIS 7.0을 설치하는 방법으로는 일반적으로 세 가지 정도의 방법이 알려져 있다. 먼저, 비스타나 롱혼 서버가 자체적으로 제공해주는 사용자 인터페이스를 사용하여 설치하는 방법과 명령 프롬프트를 통한 설치 방법, 그리고 마지막으로 무인설치 방법이 바로 그것이다. 그리고, 그 밖에도 다소 특별한 형태인 IIS 6.0으로부터 업그레이드를 하는 시나리오도 생각해 볼 수 있을 것이다. 본문에서는 이미 설명했던 바와 같이, 그 중 롱혼 서버상에서 서버 관리자(Server Manager) 도구를 사용해서 IIS 7.0을 설치하는 가장 보편적인 형태의 시나리오를 중점적으로 살펴볼 것이다. 나머지 다른 설치 방법들에 대해서는 먼저 IIS 7.0에 어느 정도 친숙해진 뒤에 다시 한 번 자세하게 살펴보기로 하자. 아마도 개발자분들은 대부분 사용자 인터페이스를 사용하는 설치 방법을 사용하게 되겠지만, 다수의 서버를 동시에 관리하는 서버 관리자분들이나 일부 특수한 형태의 IIS 7.0 구성 설정을 고객들에게 제시할 필요가 있는 분들, 그리고 반복적으로 동일한 설치 작업을 빈번하게 수행하는 업무를 담당하는 분들과 같은 경우에는 명령 프롬프트를 통한 설치 방법이나 무인설치 방법도 사용자 인터페이스를 사용하는 설치 방법 못지 않게 대단히 중요한 비중을 차지할 것이다.

자유롭게 조립 가능한 모듈 기반의 웹 서버, IIS 7.0

IIS 7.0은 사용자가 원하는 대로 조립이 가능한 모듈 기반의 웹 서버로 완벽하게 다시 설계되었다. 이 말을 새로운 버전의 소프트웨어들이 늘상 버릇처럼 얘기하는 단순한 홍보문구 정도로 가볍게 생각하지 말기 바란다. 문장과 단어가 의미하는 바 그대로 기반 구조부터 완벽하게 다시 설계되었기 때문이다. 그리고, 바로 이 점이야말로 IIS 7.0의 가장 큰 특징인 동시에 다른 핵심적인 기능들을 전반적으로 지배하는 중핵이다. 그러면, 모듈 기반의 웹 서버가 가져다주는 장점을 직접 느껴보기 위해 한 가지 간단한 예를 들어 보도록 하자. 멀리에서 거창한 사례를 찾을 것 없이 여러분이 현재 관리하고 있거나 개발에 사용하고 있는 IIS 서버에서 어떤 인증 방법을 사용하고 있는지 각자 한 번 가만히 생각해보기 바란다. 아마 예상컨데 대부분 익명 접근이 가능하도록 설정된 상태에서 ASP.NET의 폼 인증 정도를 구현하는 경우가 거의 대다수일 것이다. 개인적인 경험을 미루어 짐작해보면 내부적으로 엑티브 디렉터리를 통한 인증이 이루어지는 경우와 같이 다소 특별한 경우에도 Windows 통합 인증을 사용하거나 하는 경우는 매우 드물고, 실제 구현은 코드에 의존한 채 폼 인증과 유사한 구성을 크게 벗어나지 않도록 설계된 경우가 거의 대부분이다. 사실, 아닌게 아니라 당장 필자만 해도 .NET Passport 인증과 같은 기술은 사용해본 경험이 거의 전무하다.

이 이미지는 필자의 노트북에 설치된 IIS 6.0에서 캡춰한 인증 방법 대화 상자의 모습이다. 그런데, 한 번 재미있는 가정을 해보도록 하자. 만약, 이 대화 상자에 존재하는 여러가지 기능들을 각각 분리해서, 그 중 사용자가 설치하고자 하는 기능들만 개별적으로 설치할 수 있다면 어떨까? 가령, 익명 인증 기능은 가장 기본적인 기능이므로 언제나 설치되도록 하고, 그 밖에 Windows 통합 인증 기능이나 Windows 도메인 서버의 다이제스트 인증 기능, 기본 인증 기능, 그리고 .NET Passport 인증 기능 등은 정말로 필요한 경우에만 개별적으로 설치할 수 있는 것이다. 만약, 이런식의 설치가 가능했다면 전국에 존재하는 거의 대부분의 IIS 서버에는 익명 인증 기능만 설치되어 있는 상황이 벌어져 있지는 않았을까? 구성하고자 하는 IIS 서버가 이미지만을 호스트하기 위한 이미지 서버인 경우라던가, ASP.NET 웹 응용 프로그램이 운영될 서버이긴 하지만 폼 인증 이외의 인증이 이루어질 이유가 전혀 없다면 필자는 주저하지 않고 IIS에서 익명 인증 이외의 기능들은 모조리 제거해 버릴 것이다. 왜냐하면 그로 인해 얻을 수 있는 이득이 들어가는 노력에 비해 너무나도 크기 때문이다. 반갑게도 IIS 7.0에서는 바로 이와 같은 식의 설치와 관리가 가능해졌다.

이런 모듈 기반의 웹 서버가 갖고 있는 장점은 대단히 명확하다. 무엇보다도 사용자가 필요로 하는 기능 모듈들만을 조합하여 가볍고 안정적인 웹 서버를 구성하는 것이 가능해진다. 방금 살펴봤던 것과 같이 전혀 사용하지도 않는 기능들이 설치될 하등의 이유가 없는 것이다. 물론 구 버전의 IIS에서도 어느 정도까지는 설치할 기능들을 사용자가 선택하는 것이 가능했지만 대단히 제한적이었으며 대부분의 기능들은 그나마 선택의 여지도 존재하지 않았다. 그 가장 좋은 사례가 위와 같은 인증 기능들과 ISAPI 관련 기능들, 그리고 CGI 관련 기능 등이다. 극단적으로 말해서 이런 기능들을 설치하지 않을 수 있는 방법은 오직 IIS 그 자체를 설치하지 않는 길 뿐이었다. 어떤 분들은 이렇게 반문할지도 모른다. IIS 6.0에서는 비록 ISAPI 관련 기능들과 CGI 기능이 설치되기는 하지만 기본적으로는 비활성화되어 있으므로 그 점만 놓고 본다면 그다지 달라진 점도 없지 않느냐라고 말이다. 그러나, 일단 설치가 되고 사용되지 않는 것과 아예 설치조차 되지 않는 것에는 많은 차이점이 존재한다. 즉, 웹 서버에 어떤 임의의 기능이 설치는 되어 있지만 비활성화되어 있다고 가정해볼 때, 그래도 여전히 해당 기능은 서버의 메모리에 로드되며 비교적 적은 양에 불과하겠지만 어느 정도까지는 별다른 의미도 없는 헛된 CPU 싸이클을 소모할 수 밖에 없다. 더군다나 이 기능의 코드 블럭은 엄연히 웹 서버의 요청 파이프라인에 존재하게 되므로 결과적으로 성능 감소로 이어질 수 밖에 없는 것이다. 간단하게 말해서 모듈이 십 여개 내외만 올라가 있는 웹 서버와 수 십 여개의 모듈이 올라가 있는 웹 서버 중에서 어떤 웹 서버의 성능이 더 뛰어날지는 물어볼 필요도 없는 것이다. 그리고, 지금까지 얘기한 내용들보다도 더 중요한 점은 악의적인 사용자로부터 공격받을 수 있는 잠재적인 접근점이 여전히 남아있게 되며, 사용하지도 않는 기능으로 인한 패치와 업데이트 작업 등의 서버 관리가 뒤따르게 된다는 점이다.

그렇다면 남은 문제는 과연 얼마나 다양한 모듈들이 얼마나 많이 제공되는지가 관건일 것이다. 먼저, 각자 아래의 이미지를 클릭해서 큰 원본 이미지를 한 번 자세히 살펴보기 바란다. 참고로 이 이미지는 IIS 개발팀의 공식 사이트인 IIS.net(http://www.iis.net/)으로부터 링크해 온 것으로 IIS 7.0에서 기본적으로 제공해주는 모듈들을 체계적으로 잘 정리하여 일목요연하게 나타내주고 있다. IIS 7.0은 여러분이 이미지를 통해서 살펴볼 수 있는 바와 같이 웹 서버 코어와 약 40 여 개의 모듈들로 구성된다. 그리고, 기본적으로 제공되는 모듈의 대부분은 기존의 기능들이 모듈화 된 것이지만 요청 필터링(Request Filtering) 모듈 같이 외부의 기능이 모듈화되어 흡수된 경우도 존재한다. 고무적인 사실은 이 각각의 모듈들이 서드 파티 모듈이나 커스텀 모듈로 대체되거나 동시에 실행될 수 있을 뿐만 아니라, C 나 C++ 언어에 익숙하지 않은 ASP.NET 개발자들도 HTTP 모듈의 형태로 커스텀 모듈을 개발하여 C나 C++ 언어를 사용하여 작성한 네이티브 서버 API 모듈과 동일한 형태와 동일한 방식으로 사용할 수가 있다는 점이다. 바야흐로 ASP.NET 개발자가 곧 IIS 서버 개발자인 시대가 다가온 셈이다. 이 커스텀 모듈 개발에 관해서는 나중에 다시 자세하게 살펴보기로 한다.

이제 필요한 기반 지식이 어느 정도 갖춰졌으므로 실제의 설치 작업을 한 단계씩 살펴도록 하자. 롱혼 서버에서 IIS 7.0의 설치와 관련된 모든 작업은 새로운 관리 도구인 서버 관리자(Server Manager)를 통해서 이루어진다. 비스타를 생각하고 제어판에서 Windows 기능 사용/사용 안 함 을 실행시켜봐도 역시 서버 관리자가 실행된다. 서버 관리자는 그 이름이 뜻하는 바 그대로 롱혼 서버를 관리하기 위한 기능들을 제공해주는 도구로, 얼핏 생각하기에는 2003 제품군에서 제공해주던 사용자 서버 관리 도구와 비슷한 것처럼 보일 수도 있겠지만 그 내용과 질적인 면에서 비교가 되지 않는 강력한 도구다. 물론 IIS 7.0을 관리하기 위한 가장 중추적인 도구는 인터넷 정보 서비스 관리자이지만 서버 관리자는 조금 더 포괄적인 시점에서 롱혼 서버 전체를 관리할 수 있게 도와주며, 롱혼 서버를 설치하고 나서 로그인을 하면 기본적으로 자동 실행된다. 아니면 시작 메뉴나 빠른 실행의 아이콘 등을 이용하여 실행시킬 수도 있다. 다음은 필자의 가상 서버에 설치된 롱혼 서버에서 서버 관리자를 실행시킨 모습이다. 본문에 첨부된 이미지 대부분은 마우스로 클릭을 하면 큰 크기의 이미지를 볼 수 있으므로 참고하기 바란다.

이 이미지에서 볼 수 있는 것처럼 서버 관리자의 좌측 패인에는 각각의 관리 요소들에 대한 카테고리들이 트리뷰 형태로 제공되며 그 우측 패인에는 좌측 트리뷰에서 선택된 항목에 대한 구체적인 정보와 실제 작업 처리를 위한 링크들이 제공된다. 예상컨데 서버 관리가 주업무이신 분들은 앞으로 이 화면을 지겹도록 보게될 것이다. 좌측의 트리뷰에서 Roles 노드를 선택해보자. 그러면, 다음과 같은 화면이 나타나는데, IIS 7.0의 설치를 위해서는 여기에서 롱혼 서버가 제공해주는 17가지 종류의 역할들 중 하나인 Web Server (IIS) 역할을 추가해야 한다. 현재는 서버에 추가되어 있는 역할이 하나도 없기 때문에 도움이 될만한 정보가 거의 전무하지만 일단 어떤 역할이 추가되고 나면 이 화면에 다양한 정보들이 출력된다. 이 정보들에 대해서는 역할 추가 작업이 모두 마무리되고 난 뒤에 다시 한 번 자세히 살펴보도록 하겠다. 자 그러면 이제 Add Roles 링크를 클릭하여 역할 추가 마법사(Add Roles Wizard)를 실행시킨다.

역할 추가 마법사의 첫 화면에서는 그저 약간의 설명과 간단한 주의사항만 나타날 뿐이다. 한 번 부담없이 읽어보고 다음 단계로 이동한다. 'Do not show this page again' 체크 박스를 체크해서 다음부터는 이 화면이 나타나지 않게 설정하는 것도 좋을 것이다.

다음 단계는 서버에 추가할 역할들을 선택하는 단계다. 각각의 항목들을 한 번 천천히 살펴보기 바란다. 너무나 당연한 얘기겠지만 우리들은 그 중 Web Server (IIS) 역할을 체크하여 선택해야 한다.

그런데, 이 시점에 대단히 흥미로운 일이 한 가지 발생한다. 비록 표면적으로는 조그마한 대화 상자가 하나 나타나는 것에 불과하지만 이것이 내부적으로 시사하는 바는 꽤나 복잡하다. Web Server (IIS) 역할을 체크해서 선택하면 다음과 같은 대화 상자가 나타나는데, 이 대화 상자의 내용은 Windows 프로세스 활성화 서비스라는 일련의 기능 집합을 함께 설치하지 않으면 웹 서버를 설치할 수 없다는 경고성 메시지이다. 실제로도 이 기능의 설치에 동의하지 않으면 Web Server (IIS) 역할의 설치를 계속 진행할 수가 없게 된다. 눈치 빠르신 분들은 이미 알고 계시겠지만 Windows 프로세스 활성화 서비스(이하 WAS)는 앞에서 살펴본 설치 모듈 이미지의 가장 하단 부분에서 이미 살펴본 것이다. 이 WAS는 대체 어떤 역할을 하는 것일까?

이 기능은 서비스의 형태로 구현되어 있으며 과거 버전에서 World Wide Web 게시 서비스(W3SVC 서비스 또는 WWW 서비스)가 담당하던 응용 프로그램 풀 구성 설정과 작업자 프로세스 관리를 대신 처리해준다. WAS의 가장 큰 특징은 WWW 서비스와는 달리 HTTP 프로토콜 이외에도 TCP나 명명된 파이프와 같은 비 HTTP 프로토콜까지 지원해주며, 이런 프로토콜 모두에 대해서 같은 구성 설정 방법과 프로세스 모델을 사용할 수 있게 해준다는 점이다. 한 가지 주의해야 할 점은 IIS는 WAS에 종속되지만 WAS는 IIS에 종속되지 않는다는 점이다. 가령, 이 WAS는 WCF 호스팅을 위한 기반 구조 중 하나로 사용되기도 하는데(WCF 호스팅 형태에는 1. WAS 환경, 2. 콘솔 또는 윈폼 스타일의 .exe 파일 형태, 그리고 3. 서비스 형태가 있다), 문제는 비스타의 에디션에 따라 IIS의 설치가 불가능한 경우가 존재한다는 것이다. 즉, 비스타 제품군 중에서 스타터 에디션과 홈 베이직 에디션에는 IIS의 설치가 불가능하며, 따라서 만일 WAS 가 IIS 에 종속적이었다면 이 두 가지 에디션에서는 WAS 환경하에 호스팅되는 WCF 의 구현이 어려웠을 것이다. 그러나, 비스타 스타터 에디션과 홈 베이직 에디션에서도 WAS는 IIS와는 독립적으로 설치가 가능하며 WCF를 설치할 때 필요에 따라 자동적으로 설치되므로 사용자가 직접 명시적으로 설치해줄 필요도 없는 것이다. 재미있는 것은 이런 경우에도 동시 처리 제한값이 존재한다는 점인데 그 값은 3개다. WAS에 대한 보다 자세한 정보는 마이크로소프트 테크넷에 게제된 관련 문서를 참고하기 바란다. 이제 대화 상자에서 Add Required Features 버튼을 클릭하면 다음과 같이 Web Server (IIS) 역할이 선택된다.

다음 단계로 이동한다. 이 화면에서는 선택한 역할에 대한 간단한 정보를 제공해준다. 그다지 특이한 내용은 없으므로 한 번 읽어보고 다시 다음 단계로 이동한다.

다음 단계에서는 설치하고자 하는 IIS 7.0의 세부 기능들을 선택할 수가 있다. 아마도 이 화면이 바로 여러분들이 가장 보고 싶어했던 화면이 아닐까 싶다.

다음 이미지는 위의 화면을 여러 번 캡춰해서 IIS 7.0이 제공하는 기능들의 전체 목록을 살펴보기 쉽도록 필자가 정리한 것이다. 즉, 이 이미지에 나타나 있는 선택 상태가 기본적으로 선택되어져 있는 IIS 7.0의 기능들인 셈이다. 이 상태로 IIS 7.0을 설치하면 정적인 컨텐츠 외에는 서비스가 불가능하다. 그러면, 이 목록에서 설치시 대표적으로 주의해야 될 몇 가지 내용들을 살펴보도록 하자.

개발자나 서버 관리자가 가장 주의 깊게 살펴봐야 될 항목들 중 하나가 바로 IIS 6 Management Compatibility 항목이다. IIS 7.0에서 가장 근본적으로, 그리고 극적으로 변경된 부분들 중 하나가 IIS의 설정 정보 저장소였던 메타베이스로, IIS 7.0에서는 이 메타베이스 그 자체가 아예 없어져버렸다. IIS 4.0에서 최초로 이진 파일의 형태로 등장했으며, 이어 IIS 6.0에서는 XML 파일의 형태로 변경되었던 메타베이스는 비로소 IIS 7.0에서는 완전히 사라졌으며, 그 대신 IIS 7.0 구성 설정을 위한 디렉터리인 %WinDir%\System32\inetSrv\config에 존재하는 applicationHost.config 파일과 각각의 web.config 파일들이 기존에 메타베이스가 담당하던 역할을 대신하게 된다. 그런데, 여기서 한 가지 궁금한 점이 생기신 분들도 계실 것이다. 지금 설명한 web.config 파일이 웹 개발자들이 익히 알고 있는 ASP.NET의 그 web.config 파일을 말하고 있는 것일까? 그렇다. 바로 그 web.config 파일이다. IIS 7.0과 ASP.NET 2.0은 이제 한 몸이라고 말해도 될 정도로 깊게 통합되었다. 이 주제에 대해서는 나중에 다시 살펴보기로 한다.

이렇듯 메타베이스 자체가 사라졌기 때문에, 메타베이스가 존재한다는 기본 전제하에 메타베이스를 이용하도록 만들어진 기존의 응용 프로그램들과 여러가지 관리 스크립트들은 모두 정상적으로 작동하지 않게 된다. 그 가장 대표적인 사례가 바로 비주얼 스튜디오이며 그 밖에도 내부적으로 ADSI나 WMI, 그리고 ABO를 사용하여 메타베이스에 접근하려고 시도하는 프로그램들은 모두 같은 상황에 접하게 된다. 바로 이런 경우에 메타베이스에 대한 프로그램의 호출을 받아 IIS 7.0이 제공해주는 새로운 구성 설정 시스템으로 다시 전달해주는 IIS 6 Management Compatibility가 필요한 것이다. 그러므로, 대부분의 개발자분들이나 서버 관리자분들은 이 항목을 선택하여 설치할 수 밖에는 없을 것이다. IIS 6 관리 호환성에 대한 더 자세한 정보는 필자가 번역한 IIS7 구성 설정 호환성 문서를 참고하기 바란다. 이 문서에서는 내부적으로 ABO를 사용하는 MBExplorer라는 도구를 사용해서 IIS 6 Management Compatibility를 통해 메타베이스가 아닌 applicationHost.config 파일에 정보를 기록하거나 반대로 읽어오는 과정을 보여주고 있다.

또 다른 주의 깊게 살펴볼만한 항목은 Request Filtering 항목이다. 이는 지금까지 애드온 형태로 제공되어오던 URLScan 도구가 IIS 7.0의 일부로 통합된 모듈로, 개별적인 설치가 필요 없고 '숨겨진 네임스페이스' 같은 새로운 기능도 일부 추가되었다. URLScan 도구에 그다지 친숙하지 않은 분들은 마이크로소프트의 기술 자료 KB326444나 KB307608 등을 반드시 한 번씩 살펴보기 바란다. 웹 서버의 보안과 관련하여 매우 강력한 기능들을 제공해주므로 IIS 6.0 이하의 환경에서는 여전히 유용하게 활용이 가능할 것이다. 그리고, Request Filtering의 사용 방법에 대한 보다 많은 정보는 요청 필터링 사용 방법 문서를 참고하기 바란다. 이 문서에서는 간단한 기능 설명과 함께 실제로 사용하는 방법을 보여주고 있다.

그리고, 특이한 점 한 가지는 언제나 IIS와 함께 제공되던 SMTP 관련 항목들이 위의 목록에는 전혀 존재하지 않는다는 것이다. 이 점에 대해서 결론부터 얘기하자면 비스타 제품군에서는 더이상 SMTP가 제공되지 않으며, 롱혼 서버에서는 이 목록에 SMTP와 관련된 내용이 나타나지는 않지만 IIS가 설치되고 나면 SMTP 관련 관리 항목이 나타나게 된다. 그러나, 롱혼 서버의 경우 최종 출시될 때도 이런 형태가 유지될지는 장담할 수는 없을 것 같다. IIS 개발팀의 블로그에서 제공된 정보에 따르면 비록 지금까지 SMTP가 IIS의 일부로 제공되기는 했지만 SMTP 그 자체에 대한 결정권은 IIS 개발팀이 갖고 있지 않다는 사실이 이런 결과가 발생하게 된 근본적인 이유라고 한다. 필자의 영어 회화 실력이 많이 부족하기 때문에 잘못 이해한 것일 수도 있지만 우연히 2007 MVP Global Summit에서 들은 바에 따르면 아마도 SMTP는 익스체인지 서버 개발팀의 영역에 속하는 것 같다. 참고로 또 다른 IIS MVP인 Steve Schofield는 자신의 블로그에서 이 문제에 대한 비스타 사용자들의 대안 중 하나로 무료로 배포되는 SMTP 제품을 두 가지 정도 소개하고 있다.

그리고, 목록의 일부 항목들은 다른 항목에 종속되기도 하는데, 지금 본문을 통해서 살펴보고 있는 것처럼 비스타나 롱혼에서 제공해주는 사용자 인터페이스를 통해서 IIS 7.0을 설치하는 경우에는 종속되는 항목이 선택되는 경우, 다음 이미지 같은 종속성 정보 대화 상자를 출력해주는 등의 방법으로 종속성을 관리해준다. 이를테면, 이 대화 상자는 목록에서 ASP.NET 항목을 선택한 경우 출력되는 대화 상자를 캡춰한 것으로 ISAPI 익스텐션 및 필터에 대한 종속성 정보를 제공하고 있으며, 본질적으로는 우리들이 앞에서 살펴본 WAS 관련 대화 상자와 완벽하게 동일한 것이다. 즉 내부적으로는 WAS 역시도 종속 관계의 범주에 포함될뿐만 아니라, 사실상 종속성의 최상층에 자리잡고 있다. 그리고, 명령 프롬프트를 통한 설치 방법이나 무인설치 방법으로 IIS 7.0을 설치하는 경우에는 이 종속성에 관한 정보들을 설치자가 명시적으로 관리해줘야만 하는데, 이 주제를 본문에서 다루게 되면 본문의 범위를 과도하게 넘어서게 되므로 이 부분에 대해서는 나중에 다시 살펴보기로 한다.

필요한 항목들을 모두 선택하고 다음 단계로 이동하면 선택 내역을 확인하기 위한 목록이 나타난다. 목록의 내용을 확인하고 Install 버튼을 눌러 설치를 진행한다.

매우 심플한 형태의 진행 상태바가 나타난다. WAS가 먼저, 그리고 그 다음 IIS의 순서로 설치가 진행된다.

모든 설치 과정이 끝나고 결과가 출력된다. 필자의 경우에는 기본 항목에 추가적으로 ASP.NET과 관련된 몇 가지 항목들, 그리고 IIS 6 관리 호환성 항목들을 더 설치했다. Close 버튼을 눌러 마법사를 종료한다.

마법사가 종료되면 다시 서버 관리자로 돌아가게 된다. 그리고, 서버 관리자의 우측 패인에는 아까와는 달리 다음 이미지와 같은 다양한 정보들이 출력되어 있을 것이다. 여기에는 각각의 역할들에 대한 서비스 상태, 그리고 실제 설치된 기능들 등의 정보들이 나타나며, 좌측 패인의 트리뷰에는 막 설치된 Web Server (IIS) 역할에 대응하는 트리 노드가 추가된다.

트리뷰에 새로 추가된 Web Server (IIS) 노드를 클릭해보면 우측 패인에 이 역할에 대한 보다 자세한 정보가 나타난다. 여기에 나타나는 정보들은 방금 살펴봤던 Roles 노드의 정보와 크게 다르지 않지만 이벤트 등의 정보들을 추가적으로 제공해준다. 그리고, 역할이 추가된 직후에는 나타나지 않지만 서버 관리자를 재시작하면 이 노드 하위에 인터넷 정보 서비스 관리자 노드가 추가되어 나타날 것이다. 서버 관리자를 사용하는 작업은 모두 마무리되었으므로 이제 서버 관리자는 닫아버려도 무방하다.

드디어 우리들이 기다리던 순간이 왔다. 인터넷 익스플로러를 실행하고 주소창에 http://localhost/를 입력하면 다음과 같은 IIS 7.0의 환영 페이지가 나타나게 된다. 이 페이지가 정상적으로 나타나면 모든 설치가 마무리 된 것이다.

그러면, 이번엔 인터넷 정보 서비스 관리자를 살펴보기로 하자. 인터넷 정보 서비스 관리자가 제공하는 여러 가지 기능들에 관해서는 나중에 다시 한 번 자세하게 살펴보기로 하고 본문에서는 전반적인 변화에 대해서만 알아본다. 너무나 당연한 일이겠지만 파격적으로 바뀐 IIS 7.0의 아키텍처는 인터넷 정보 서비스 관리자에도 대단히 큰 영향을 미쳤다. 사실상 인터넷 정보 서비스 관리자는 IIS 4.0 이후로부터 현재에 이르기까지 그다지 크게 변경된 부분이 없었고, 그런 면에서 나름대로 편했던 부분도 없지는 않았지만 바로 동일한 이유로 인해서 아쉬움을 느끼게 되는 경우도 적지 않았다. 다시 말해 관리적인 관점에서 현재보다 강력하고 편리해질 수도 있는 부분들이 MMC가 제공해주는 기본적인 범위를 벗어나지 못한채 제약을 받는 상황이었던 것이다. 그러나, IIS 7.0에서는 그간의 정체를 만회라도 하려는 듯이 전반적인 부분에 있어 혁신적인 변화가 일어났다. 과연 어떤 부분들이 어떻게 바뀌었는지, 그리고 그 변화가 우리들에게 어떠한 영향을 주게 될지 지금부터 간단하게 살펴보자. 아래 이미지는 인터넷 정보 서비스 관리자의 새로운 시작 화면이다. 마치 비주얼 스튜디오를 처음 실행시키면 나타나는 시작 화면과 같이 몇 가지 정보들과 IIS와 관련된 온라인 정보가 나타난다. 지금은 이 온라인 뉴스에 아무런 내용도 표시되지 않지만 추후에 롱혼 서버가 정식으로 출시되고 나면 이 영역을 통해서 여러 가지 정보들이 제공될 것으로 생각된다.

다음 세 개의 이미지들은 모두 기본 웹 사이트에 대한 인터넷 정보 서비스 관리자 화면으로, 중앙부의 항목들을 영역별로 구분하여 세 번에 걸쳐 캡춰한 것이다. 여전히 좌측 패인의 노드를 마우스 오른쪽 버튼으로 클릭하면 팝업 메뉴가 나타나고, 나타난 팝업 메뉴에는 여러 가지 작업을 처리할 수 있는 하위 메뉴가 나타나지만, 더 이상 등록 정보나 속성 메뉴가 나타나지는 않는다. 그 대신 가운데 부분에 보이는 항목들을 이용하여 각각 해당하는 설정 작업들을 처리하게 된다. 그리고, 과거와는 달리 화면 우측에 패인이 하나 더 나타나게 되는데, 여기에는 현재 선택된 노드를 대상으로 수행할 수 있는 작업들의 명령이 분류되어 링크 형태로 제공된다.

다음은 ASP.NET 영역의 항목들이다.

그리고, 다음은 IIS 영역의 항목들이다.

마지막으로, 관리 영역의 항목이다.

아마도 겉보기에 가장 두드러진 변화는 관리를 위한 세부 항목들이 모두 아이콘 형태로 제공된다는 점일 것이다. 이 부분은 조금만 생각해보면 아주 쉽게 이해가 가능한 부분이다. IIS 7.0의 모든 기능들은 각각 분리된 모듈 형태로 제공된다. 따라서, 각각의 기능들을 관리하기 위한 사용자 인터페이스도 분리된 형태로 제공되어야만 설치되지 않은 기능들을 위한 사용자 인터페이스를 유연하게 제거하는 것이 가능해지는 것이다. 그리고, 그 보다 더 중요한 점은 IIS 7.0이 제공하는 향상된 기능인 관리 위임 기능을 사용하는데 있어 이와 같이 기능별로 분리된 형태의 사용자 인터페이스가 더욱 유리하고 직관적이라는 점이다. IIS 7.0에서는 각각의 기능별로 권한을 구분하여 다른 사용자에게 관리를 위임하는 것이 가능한데, 예를 들어서 IIS의 마스터 관리자인 사용자 A가 필요에 따라서 사용자 B와 사용자 C에게 각각 필요로 하는 부분들의 관리를 위임하는 것이 가능한 것이다. 이 때, 사용자 B나 사용자 C가 IIS 7.0을 관리하기 위해 인터넷 정보 서비스 관리자로 로컬이나 원격으로 IIS에 접근하면 해당 사용자의 인터넷 정보 서비스 관리자에는 각각 자신에게 관리 위임된 기능들에 대한 항목들만 아이콘으로 나타나게 되는 것이다.

이처럼 인터넷 정보 서비스 관리자가 지금과 같은 모습으로 진화하게 된 데에는 그에 걸맞는 이유가 존재하고 있는데, 더욱 재미있는 부분은 앞에서도 이미 간단하게 설명했던 것처럼 이제 ASP.NET 개발자들도 자신들에게 필요한 IIS의 서버 모듈과 그에 해당하는 인터넷 정보 서비스 관리자의 관리 항목들을 직접 개발할 수 있다는 것이다. 실례로 IIS 개발팀이 개발해 놓은 추가적인 관리 항목을 IIS 개발팀의 공식 사이트에서 다운로드 받을 수도 있다. 필자의 생각으로는 새로운 서드파티 시장이 전문 업체들에게 열린 것이라고 여겨진다. 그리고 .NET 개발자들에게도 새로운 역량을 제공해주는 좋은 기회가 될 것이다.

지금까지 우리는 본문을 통해서 IIS 7.0의 가장 기초적인 부분들을 몇 가지 살펴봤다. 아직까지는 알려지지 않은 정보들도 많고 공식적으로 제공되는 정보들도 그다지 많지 않은듯 하다. 게다가 그나마 존재하는 자료들도 대부분 영문 자료이기 때문에 국내 개발자들은 더욱 불리한 위치에 놓여져 있다. 그러나 한 가지 확실한 점은, IIS 7.0이 ASP.NET 개발자들과 서버 관리자들의 일상을 크게 바꾸어 놓게 될 것이며, 이제 천천히 준비를 시작해야 될 때가 다가오고 있다는 점이다.