IIS 7.0 인스퍼레이션 02.

드디어 윈도우 비스타 제품군에 뒤이어 원도우 서버 코드명 롱혼 베타 3 평가판이 지난 4월 말 일반인들을 대상으로 공개되었다. 여러 가지 보도 자료와 기술 분석 자료들을 살펴보면 롱혼에서 제공되는 핵심 기능의 하나로 매번 빠짐없이 거론되는 것이 바로 IIS 7.0임을 알 수 있다. 그러나, 아쉽게도 아직까지는 IIS 7.0의 기능이나 특징에 관해 구체적으로 설명된 자료들이 많이 부족하고, 그나마 존재하는 자료들도 대부분 영문으로 된 자료들인지라 언어적인 장벽으로 인해 대다수의 국내 개발자분들이 편안한 마음으로 쉽게 접근하기에는 다소 무리가 있는 것 또한 사실이다. 그래서, 본문을 비롯한 이후 몇 차례의 글들을 통해서 특정한 주제 없이 무작위로 선택한 IIS 7.0의 여러 가지 기능과 특징들을 살펴보는 기회를 갖고자 한다. 지난번 글에서 언급했던 명령 프롬프트를 통한 설치 방법이나 무인설치 방법 등과 같이 비교적 사용 빈도가 낮은 내용들에 대해서는 차후에 다시 살펴보는 시간을 갖도록 할 것이다. 마지막으로 본문에서 논의되는 모든 내용들은 지난번 글을 통해서 소개했던 설치 과정을 거쳐 설치된 IIS 7.0의 최종 상태를 기준으로 한다는 점을 참고하기 바란다.

IIS 7.0과 IUSR_머신이름 계정

마이크로소프트 플랫폼 기반의 웹 개발자분들이나 서버 관리자분들은 IIS의 설치와 함께 생성되는 IUSR_머신이름 계정에 대해서 이미 대부분 잘 알고 있을 것이다. IUSR_머신이름 계정은 웹 서비스와 FTP 서비스에서 익명 사용자를 위한 기본 신원 계정으로 사용된다. 그리고, 이 계정과 비슷한 유형의 계정에는 IWAM_머신이름 계정과 IIS_WPG 그룹이 있는데, 각각 전자는 IIS 5.0 이하의 버전 및 IIS 6.0의 'IIS 5.0 격리 모드'에서 서로게이트인 MTX.EXE 프로세스나 DLLHOST.EXE 프로세스의 기본 신원 계정으로, 그리고 후자는 IIS 6.0의 '작업자 프로세스 격리 모드'에서 응용 프로그램 풀의 신원 계정을 위한 그룹으로 사용된다. 필자는 이 계정들과 그룹에 대한 지식이 마이크로소프트 플랫폼 기반의 웹 개발자로서 초급 단계를 벗어나는 중요한 관문의 하나라고 믿고 있는데, 그 이유는 이에 대한 이해가 IIS 내부의 깊은 부분을 파악하는데 있어 필수적이기 때문이다. IUSR_머신이름 계정과 IWAM_머신이름 계정에 대해서는 COM+ 응용 프로그램과 IIS 버전 5.0의 웹 응용 프로그램에서 자세히 설명한 바 있으므로 관심있는 분들은 참고하기 바란다. 아마도 IUSR_머신이름 계정과 IWAM_머신이름 계정에 관한 거의 대부분의 궁금증들을 이 문서를 통해서 해소할 수 있을 것이므로 본문에서는 관련된 내용들에 대해서는 더 이상 설명하지 않겠다. 다만, 본문의 내용을 보다 수월하게 이해하려면 IIS_WPG 그룹에 관한 약간의 선수 지식이 요구되므로 잠시 관련된 내용들을 살펴보도록 하자.

반드시 이해하고 넘어가야 할 내용은 응용 프로그램 풀의 개념이다. 이 응용 프로그램 풀이라는 개념은 IIS 6.0에서 처음 소개된 개념으로, IIS 5.0까지 사용되던 응용 프로그램 보호 모드를 다시 한 단계 진일보시킨 결과물이다. 과거 응용 프로그램 보호 모드에서는 웹 응용 프로그램들을 격리하게 위해 비교적 제한적인 방법만 사용할 수 있었으나, 응용 프로그램 풀의 개념을 기반으로 한 작업자 프로세스 격리 모드에서는 제약 없이 관리자가 원하는 어떠한 조합으로든 각각의 응용 프로그램들을 격리시킬 수 있게 됐다. 사실, 이 개념을 이해하려면 반드시 COM+ 응용 프로그램과 IIS 버전 5.0의 웹 응용 프로그램의 내용을 이해하고 있어야만 한다. 그러나, 이미 설명했던 것처럼 본문에서는 이와 관련해서 다시 반복된 설명을 하지 않을 것이므로 간단하게 각 격리 모드간의 차이점만을 정리해보도록 하겠다.

모든 버전의 IIS를 비교하는 것은 현실적으로 의미 없을뿐만 아니라, 자료를 구하는 일도 만만치 않으므로 현재와 같은 구조와 외형의 IIS로 처음 자리잡기 시작한 IIS 4.0 버전의 응용 프로그램 격리 방법부터 살펴보도록 하자. NT 4.0 기반의 IIS 4.0에서는 관리자가 선택할 수 있는 웹 응용 프로그램 격리 방법이 극히 제한적이었다. 즉, 모든 웹 응용 프로그램은 기본적으로 웹 서비스 자체와 동일한 프로세스에서 실행되고, 구분 메모리 공간에서 실행(격리된 프로세스) 옵션이 선택된 웹 응용 프로그램들만 별도의 프로세스에서 실행되었던 것이다. 이 때까지만 해도 구성 요소 서비스가 담당하고 있는 역할은 MTS가 맡고 있었으며 지금은 매우 보편적인 개념으로 다뤄지고 있는 웹 응용 프로그램의 격리라는 개념도 그다지 알려지지 않았던 시기였다. 결과적으로 IIS 관리자들은 모 아니면 도라는 식으로 웹 응용 프로그램 격리를 애시당초 포기하던가, 또는 각각의 웹 응용 프로그램을 일일이 격리시키는 방법을 선택해야만 했다. 그러나, 윈도우 2000 제품군과 함께 IIS 5.0이 출시되면서 양상이 조금 개선된다. 바로, 웹 응용 프로그램 격리 수준을 응용 프로그램 보호라는 옵션을 사용해서 낮음(IIS 프로세스), 보통(풀링됨), 그리고 높음(격리됨)의 세 가지 방식으로 보다 세밀하게 설정을 할 수 있게 됐으며, 새로 생성되는 모든 웹 응용 프로그램은 기본적으로 실행 속도와 안정성의 타협점이라고 할 수 있는 보통(풀링됨)으로 설정되도록 개선되었던 것이다. 그 결과 IIS 5.0은 납득 가능한 수준의 실행 속도뿐만 아니라 웹 응용 프로그램의 오류로부터 웹 서비스 자체를 보호할 수 있는 비교적 안정적인 구조를 동시에 획득하게 되었다. 이 부분에 대한 보다 자세한 설명은 바로 위에서 소개한 문서를 참고하기 바란다.

그러나, IIS 5.0에서 제공하는 응용 프로그램 격리 방법은 특정 상황에서 다소 불합리한 면을 갖고 있다. 요컨데 10개의 웹 응용 프로그램을 호스팅하는 IIS 웹 서버를 한 번 가정해보자. 비교적 신뢰할 수 있고 빠른 속도가 요구되는 웹 응용 프로그램 2개를 낮음(IIS 프로세스)으로 설정하고, 다소 엄격한 격리가 필요한 웹 응용 프로그램 한 개를 높음(격리됨)으로, 그리고 나머지 7개의 웹 프로그램들을 보통(풀링됨)으로 설정했다고 가정해보면 상당히 그럴듯한 구성인 것처럼 느껴진다. 일단 이 가정에서 실제 숫자는 그리 중요한 부분이 아니므로 웹 응용 프로그램들이 전반적으로 적정한 비율로 분산 격리되었다는 점만 주목하도록 한다. 그런데, IIS 웹 서버가 호스팅하는 웹 응용 프로그램의 갯수가 10개가 아닌 100개라고 가정을 바꿔보면 다소 기형적인 분배가 나올 확율이 높다는 것을 쉽게 눈치챌 수 있다. 가령, 20개의 웹 응용 프로그램이 낮음(IIS 프로세스)으로 설정되고, 10개의 웹 응용 프로그램이 높음(격리됨)으로, 그리고 나머지 70개의 웹 응용 프로그램들이 보통(풀링됨)으로 설정된다고 생각해보자. 주된 문제는 보통(풀링됨)으로 설정된 70개의 웹 응용 프로그램에 있다. 오류가 발생한 단 하나의 웹 응용 프로그램이 나머지 69개의 웹 응용 프로그램들을 먹통으로 만들어버릴 수도 있고, 결국 이 얘기는 문제가 원점으로 돌아가버린다는 것을 의미한다. 더군다나 낮음(IIS 프로세스)으로 설정된 20개의 웹 응용 프로그램들도 결코 안심하고만 있을 수도 없을 뿐 아니라, 100개의 웹 응용 프로그램을 모두 높음(격리됨)으로 설정하는 것도 그다지 바람직한 해결책으로 볼 수는 없다. 게다가 이 문제는 IIS 웹 서버가 호스팅하는 웹 응용 프로그램의 갯수가 많으면 많을수록 더 심각해지게 되는데 웹 호스팅 서비스 업체 등과 같은 곳에서는 심각한 고민꺼리가 아닐 수 없다.

바로 이런 이유들로 인해서 IIS 6.0의 응용 프로그램 풀이라는 개념이 등장하게 된다. 즉, 웹 응용 프로그램들 간의 격리라는 관점에서만 생각해보면 자연스럽게 다음과 같은 질문들을 던질 수 있을 것이다. 굳이 IIS 4.0이나 5.0 같이 구분 메모리 공간에서 실행(격리된 프로세스)라든가 낮음(IIS 프로세스), 보통(풀링됨), 높음(격리됨) 같은 미리 정의된 웹 응용 프로그램 격리 수준을 제공해줘야만 하는 것일까? 게다가 꼭 이렇게 두, 세 개의 제한적인 갯수로 격리 수준을 일일이 제공해줘야만 할까? 만약, 네 번째 혹은 그 이상의 격리 수준이 필요하게 된다면 그 때는 또 어떤 방식으로 새로운 격리 수준을 제공해줘야 하는 것일까? 매번 IIS의 버전을 올려가면서 새로운 격리 수준을 제공해야 되는 것일까? 아마도 이 질문들과 비숫한 고민을 IIS 개발팀에서도 했던 것으로 보인다. 근본적으로 웹 응용 프로그램들의 격리는 각각의 웹 응용 프로그램들을 프로세스 단위로 그룹핑하는 방식으로 이뤄진다. 그리고, IIS 5.0까지는 바로 이 그룹핑을 위한 프로세스를 IIS가 미리 만들어놓고 제공해주는 방식이었다. 그렇다면 문제를 해결하는 방법은 의외로 간단하다. 그룹핑을 위한 프로세스를 관리자가 임의대로 자유롭게 생성 가능하도록 기능을 제공해주면 되는 것이다. 요컨데 낮음(IIS 프로세스), 보통(풀링됨), 그리고 높음(격리됨) 같은 격리 그룹을 관리자가 마음대로 생성하고, 생성된 각각의 그룹에 적당한 웹 응용 프로그램들을 포함시킬 수 있도록 적절한 기능을 제공해주는 방식이다. 흔하디 흔한 관용구처럼 물고기를 잡아주는 것이 아니라 물고기를 낚는 방법을 제공해주는 셈인데, 여러분들도 이미 짐작하고 있는 것처럼 여기에서 얘기하고 있는 격리 그룹, 그리고 실질적으로는 이 그룹에 대한 프로세스가 바로 웹 응용 프로그램 풀이다.

물론 지금까지 설명한 응용 프로그램 풀의 개념은 어디까지나 웹 응용 프로그램 격리라는 관점에서 살펴본 것으로, 응용 프로그램 풀은 그 밖에도 응용 프로그램 풀 재생이나 웹 가든의 기본 단위가 되는 등 작업자 프로세스 격리 모드의 IIS 6.0에서 중추적인 역할을 담당하고 있는데, 이런 중요한 응용 프로그램 풀의 신원 계정을 위해 미리 준비되어 있는 계정 그룹이 바로 위에서 설명했던 IIS_WPG 그룹이다. 다음은 IIS 6.0의 응용 프로그램 풀 등록 정보 대화 상자 이미지로, 보통 이 이미지에서 볼 수 있는 것처럼 미리 정의된 보안 계정 옵션을 선택하고 네트워크 서비스, 로컬 서비스, 그리고 로컬 시스템 계정 중 하나를 선택하는 경우가 대부분이며, 대개의 경우 이것만으로도 충분하다. 그러나, 네트워크에 존재하는 리소스에 접근하기 위해서 특정 권한이 필요하다던지 하는 등과 같은 경우에는 별도의 사용자 계정을 새로 생성하고 필요한 권한을 부여한 다음, 아래 대화 상자에서 보안 계정 구성 옵션을 선택하고 사용자 이름 입력란에 새로 생성한 계정을 입력해서 응용 프로그램 풀의 신원 계정을 변경해줘야 하는데, 이 때 해당 계정은 반드시 IIS_WPG 그룹의 멤버여야만 한다. 만약, 이 계정이 IIS_WPG 그룹의 멤버가 아니라면 이 응용 프로그램 풀에 등록된 모든 웹 응용 프로그램들은 정상적으로 동작하지 않는다.

무엇 때문에 이런 제약 조건이 존재하는지 궁금하신 분도 계실 것이다. 그러나 잠시 생각해보면 이는 매우 합리적인 장치라는 것을 알 수 있다. 웹 응용 프로그램을 호스트하는 작업자 프로세스는 웹 응용 프로그램을 정상적으로 실행하기 위해서 그에 합당한 권한을 갖고 있어야 된다. 그리고, 그 권한은 작업자 프로세스의 신원 계정에 의해 결정되는데, 기본으로 제공되는 신원 계정에는 앞서 얘기했던 IIS_WPG 그룹과 네트워크 서비스 계정, 로컬 서비스 계정, 로컬 시스템 계정, 그리고 비교적 특수한 유형에 속하는 ASPNET 계정 등이 존재한다는 것을 우리는 이미 잘 알고 있다. IIS는 시스템에 설치됨과 동시에 이 계정들을 대상으로 필요한 시스템의 리소스, 가령 폴더나 레지스트리, 보안 정책 등에 대한 최소 권한 정보를 설정한다. 이는 다음의 기술 자료들에 잘 설명되어 있다.

• KB187506 : IIS 4.0 실행에 필요한 NTFS 권한 및 사용자 권한
• KB271071 : IIS 5.0 웹 서버에 필요한 NTFS 권한 및 사용자 권한을 설정하는 방법
• KB812614 : IIS 6.0의 기본 사용 권한 및 사용자 권한

문제는 미리 정의된 계정이 아닌 관리자가 새롭게 생성한 계정을 사용할 때 나타난다. 즉, 새로 생성된 계정에 대해서는 당연히 위의 기술 문서들에서 설명하고 있는 것 같은 권한 설정이 전혀 이루어져 있지 않기 때문에 웹 응용 프로그램이 의도한 대로 정상적인 동작을 하지 않는 것이다. 바로 이 때, IIS_WPG 그룹의 진가가 발휘된다. IUSR_머신이름 계정이나 IWAM_머신이름 계정을 관리자가 생성한 새로운 계정으로 대체하는 경우에는 IIS_WPG 그룹과 같은 대안이 전혀 존재하지 않기 때문에 권한을 일일이 수작업으로 설정해줘야만 한다. 반면, 응용 프로그램 풀의 신원 계정을 관리자가 생성한 계정으로 대체하는 경우에는 생성된 계정을 IIS_WPG 그룹에 멤버로 포함시키기만 하면 필요한 모든 권한 설정이 끝나는 것이다. 결국, 이런 점을 고려해본다면 응용 프로그램 풀의 신원 계정이 반드시 IIS_WPG 그룹의 멤버여야만 한다는 제약 조건은 제약 조건이 아니라 오히려 축복인 셈이다.

그런데 IIS 7.0에서는 이 계정들과 그룹에 약간의 변화가 생겼다. 서버 관리자를 실행하고, 좌측 패인의 트리뷰에서 Configuration 노드 하위의 Local Users and Groups 노드를 선택하고, 다시 Users 노드를 선택해보자. 다음 이미지가 바로 그 화면인데 분명히 IIS 7.0을 정상적으로 설치했음에도 불구하고 어찌된 영문인지 IUSR_머신이름 계정이나 IWAM_머신이름 계정이 눈에 띄지 않는다. 혹시 IIS 7.0의 설치가 뭔가 잘못된 것일까? 아마 전혀 예상하지 못한 상황일 것이다. (설치한 IIS 7.0의 세부 항목에 따라 IUSR_머신이름 계정은 존재하고 IWAM_머신이름 계정은 존재하지 않는 경우도 있을 것이다. 그 이유에 대해서는 바로 뒤에서 설명한다.)

그렇다면 IIS_WPG 그룹의 경우는 어떨까? 응용 프로그램 풀은 IIS 7.0에서도 여전히 핵심적인 구성 요소로 자리잡고 있으므로 IIS_WPG 그룹도 당연히 존재해야 될 것 같다. 확인을 위해 이번에는 서버 관리자의 트리뷰에서 Groups 노드를 선택해보자. 그런데 이번에도 예상과는 달리 IIS_WPG 그룹은 찾아볼 수 없고, 대신 IIS_IUSRS라는 이름을 가진 뭔가 관계가 있어 보이는 듯한 처음보는 그룹만 보일 뿐이다.

단도직입적으로 말하자면 IUSR_머신이름 계정은 이제 더 이상 웹 서비스의 익명 사용자를 위한 기본 신원 계정으로 사용되지 않는다. 그리고, IUSR라는 새로운 내장 계정이 그 역할을 대신하게 된다. 그러나, IUSR_머신이름 계정이 완전히 사라진 것은 아니며 FTP 서비스에서는 여전히 그 역할을 유지하게 된다. 여러분도 이미 눈치를 챘을테지만 앞에서 IUSR_머신이름 계정을 찾을 수 없었던 이유가 바로 FTP 서비스를 설치하지 않았기 때문이다. 이와 마찮가지로 IIS_WPG 그룹도 더 이상 존재하지 않으며 그 역할은 새로운 내장 그룹인 IIS_IUSRS 그룹이 대신하게 된다. 마지막으로 IWAM_머신이름 계정과 ASPNET 계정은 이제 더 이상 존재하지 않는다. 다음은 이런 계정들과 그룹의 변화를 간단하게 정리한 목록이다.

• 웹 서비스의 기본 신원 계정 : IUSR 내장 계정
• FTP 서비스의 기본 신원 계정 : IUSR_머신이름 계정 (FTP 서비스가 설치될 때 함께 생성된다.)
• 응용 프로그램 풀을 위해 미리 마련된 그룹 : IIS_IUSRS 내장 그룹
• 더 이상 존재하지 않는 계정 및 그룹 : IWAM_머신이름 계정, ASPNET 계정, IIS_WPG 그룹

여기서 우리가 한 가지 놓치지 말아야 될 사실은 새롭게 등장한 IUSR 계정과 IIS_IUSRS 그룹을 지칭할 때 모두 '내장(Built-In)'이라는 단어가 사용되고 있다는 점이다. 이 점이 시사하고 있는 바처럼 IUSR 계정과 IIS_IUSRS 그룹은 지금까지의 IUSR_머신이름 계정이나 IIS_WPG 그룹과는 달리 시스템으로부터 제공되는 내장 계정과 그룹이다. 결과적으로, IUSR 계정과 IIS_IUSRS 그룹은 비스타 제품군이나 롱혼 제품군이 설치된 모든 시스템에서 언제나 동일한 SID 값을 갖게 되는데, 얼핏 느끼기에는 그다지 특별한 변화가 아니라고 생각될지도 모르겠지만 바로 이 간단한 변화로 인해서 오랜 시간동안 수 많은 관리자들을 괴롭혀왔던 고질적인 고민거리가 하나 사라지게 된다. 즉, IIS 7.0들 간에는 단순히 웹 컨텐츠를 구성하는 폴더와 파일들을 XCopy 명령에 /O 옵션을 사용해서 복사하는 것만으로도 소유권 정보와 ACL 정보까지 모두 고스란히 복사된, 바로 실행 가능한 사본이 생성되는 것이다. 바로 이 점이 IIS 7.0에서 새로 등장한 IUSR 계정과 IIS_IUSRS 그룹이 갖고 있는 가장 큰 특징이다. 또 한 가지 개선된 점은 관리자가 응용 프로그램 풀의 신원 계정으로 사용하기 위해 생성한 계정을 이제 명시적으로 IIS_IUSRS 그룹에 멤버로 포함시킬 필요가 없다는 점이다. IIS가 작업자 프로세스를 생성할 때, 작업자 프로세스의 보안 토큰에 알아서 IIS_IUSRS 그룹의 권한을 추가해주기 때문인데, 계정 자체가 자동적으로 IIS_IUSRS 그룹에 멤버로 포함되는 것은 아니라는 점에 주의한다. IUSR 계정과 IIS_IUSRS 그룹에 대한 보다 많은 정보는 IIS7의 사용자 계정과 그룹에 대한 이해 문서를 참고하기 바란다.

IIS 7.0과 FTP 서비스, 그리고...

그러면 이번에는 FTP 서비스를 한 번 살펴보도록 하자. 가장 먼저 살펴볼 내용은 FTP 서비스를 설치하는 방법이다. IIS 7.0을 설치하는 가장 보편적인 방법에 관해서는 이미 지난번 글에서 살펴봤으므로, 이번에는 FTP 서비스를 설치해보면서 이미 설치되어 있는 IIS 7.0에 새로운 기능을 추가하거나 반대로 기존에 설치되어 있는 기능을 제거하는 방법을 살펴보도록 하자. 먼저, 서버 관리자를 실행하고 좌측 패인의 트리뷰에서 Roles 노드 하위에 위치한 Web Server (IIS) 노드를 선택한다. 그런 다음, 우측 패인의 스크롤 바를 아래로 내려보면 다음 그림과 같이 Role Services 영역이 나타난다. 이 영역에는 IIS 7.0에서 제공해주는 모든 기능들의 목록이 설치 여부와 함께 출력되며, 그 우측에는 Add Role Services 링크와 Remove Role Services 링크가 제공되는데, IIS 7.0에서는 이미 설치된 기능들 중 일부 항목을 제거하고 싶다거나 반대로 기능을 새로 추가하고 싶은 경우, 바로 이 링크들을 사용해서 작업을 처리하게 된다. 지금 우리는 FTP 서비스를 설치하고자 하므로, 이 중 Add Role Services 링크를 클릭한다.

그러면 다음처럼 역할 추가 마법사가 나타나는데, 이제 어느 정도 친숙한 대화 상자일 것이라고 생각한다. 아래의 이미지를 자세히 살펴보면 알겠지만, 이 역할 추가 마법사는 Add Role Services 링크를 클릭해서 나타났기 때문에, 지금까지 살펴봤던 역할 추가 마법사와 완전히 동일한 마법사임에도 불구하고 이미 설치된 항목들은 제거할 수 없으며 새로운 항목만 선택할 수 있도록 기능이 제한되어 있다. 물론 반대로 Remove Role Services 링크를 클릭해서 역할 추가 마법사가 나타났다면 기존에 설치된 항목들을 제거만 할 수 있도록 기능이 제한되어 있었을 것이다. 목록의 스크롤 바를 끝까지 내려보면 마지막 부분에 FTP 서비스와 관련된 항목들이 존재하는데, 본문에서는 FTP 서비스와 관련된 항목들을 모두 설치한다고 가정한다.

그런데 여기에는 절대 간과하고 넘어갈 수 없는 대단히 흥미로운 사실이 한 가지 존재한다. 문제는 지금처럼 FTP 서비스를 설치하고자 할 때, 메타베이스 호환성 기능이 이미 설치되어 있거나 FTP 서비스와 함께 선택되지 않으면, 아래의 첫 번째 이미지 같이 지난번 글에서 살펴보았던 것과 비슷한 종속성 정보 대화 상자가 나타난다는 것이다. 그 반대로 FTP 서비스와 메타베이스 호환성 기능이 같이 설치되어 있는 상태에서 메타베이스 호환성 기능을 제거하려고 시도하면, 역시 이 경우에도 아래의 두 번째 이미지 같은 종속성 정보 대화 상자가 나타난다. 즉, FTP 서비스를 설치하기 위해서는 반드시 메타베이스 호환성 기능이 설치되어 있어야 하는 것이다. 결국 이런 상황을 종합해 봤을 때 내릴 수 있는 결론은 FTP 서비스가 메타베이스 호환성 기능에 종속된다는 것, 이 한 가지 뿐이다. 그런데 만약 그게 사실이라면 뭔가 이상하지 않은가? 도대체 무슨 이유 때문에 IIS 7.0에서 제공해주는 새로운 FTP 서비스가 구버전의 메타베이스 호환성에 종속되야만 하는 것일까? 그 이유에 대해서는 잠시 뒤에 다시 살펴보기로 하고, 일단 FTP 서비스 관련 기능들을 모두 선택하고 다음 단계로 이동한다.

나머지 단계들에서는 지난번 글에서 살펴봤던 일반적인 과정들을 동일하게 반복하는 것 뿐이다. 내역 목록을 검토하고 Install 버튼(기능 제거시에는 Remove 버튼)을 눌러서 설치를 진행한다.

지정한 설치 또는 제거 작업이 진행된다.

잠시 기다리면 모든 작업이 끝나고 그 결과가 출력된다. 추가로 기능을 설치하는 경우에는 재부팅을 요구하는 경우가 드물지만, 설치되어 있는 기능을 제거하는 경우에는 종종 재부팅을 요구하므로 참고하기 바란다.

작업이 완료된 역할 추가 마법사를 닫고 다시 서버 관리자에서 Users 노드로 이동해보면, 앞에서 설명했던 것처럼 IUSR_머신이름 계정이 생성된 것을 확인할 수 있을 것이다.

이번에는 인터넷 정보 서비스 관리자를 실행하고, FTP 서비스가 제공해주는 특징들을 살펴보자. 인터넷 정보 서비스 관리자의 좌측 패인 트리뷰를 살펴보면 기존에는 존재하지 않았던 FTP Sites 노드가 새롭게 추가된 것을 볼 수 있다. 여기까지는 여러분들이 기대한 바에서 그다지 크게 벗어나지 않은 상태일 것이라고 믿는다.

그런데 막상 FTP Sites 노드를 선택해보면 다음과 같이 전혀 예상하지 못했던 결과가 나타난다. 게다가 화면 중앙에 나타난 메시지의 내용은, FTP 관리 기능이 인터넷 정보 서비스 6.0 관리자에 의해서 제공되므로 링크를 클릭해서 인터넷 정보 서비스 6.0 관리자를 실행시키라는 뜻이다. 도대체 느닷없이 이게 무슨 소리일까? 분명히 IIS 7.0에서 제공하는 FTP 서비스를 철치했는데 인터넷 정보 서비스 6.0 관리자라니 말이다.

어쨌거나 일단은 메시지의 지시대로 링크를 클릭해보자. 그러면 정말로 다음과 같이 친숙한 인터넷 정보 서비스 6.0 관리자가 실행된다. 혹시나 싶어서 기본 FTP 사이트의 등록 정보 대화 상자를 띄우고 요모조모 살펴봐도 역시 결과는 마찮가지로 IIS 6.0의 FTP 서비스와 별다르게 차이가 나는 부분을 찾을 수가 없다.

여기까지 살펴보고 나면 눈치 빠르신 분들은 아마 FTP 서비스를 추가 설치하려고 할 때 나타났던 메타베이스 호환성 기능 관련 종속성 정보 대화 상자가 생각나실 것이다. FTP 서비스를 설치하려면 반드시 메타베이스 호환성 기능이 필요한데다가, 인터넷 정보 서비스 6.0 관리자까지 나타났다. 그렇다면 당연히 메타베이스도 남아있지 않을까? 직접 확인해보면 간단히 알 수 있는 문제다. 탐색기를 실행한 다음, IIS의 설치 폴더인 System32 폴더 하위의 inetsrv 폴더로 이동해보자. 놀랍게도 이제는 사라진 것으로만 믿었던 IIS 6.0의 MetaBase.xml 파일이 척하니 자리잡고 있는 것을 볼 수 있을 것이다.

더욱더 정확한 확인을 위해 파일을 메모장으로 열어서 그 내용을 살펴보도록 하자. 비록 FTP와 관련된 내용들로만 구성되어 있기는 하지만 IIS 6.0 형태의 메타베이스 파일이 맞다는 것을 알 수 있을 것이다.

이게 도대체 어떻게 된 일일까? 이제 더 이상 메타베이스가 존재하지 않는다는 필자의 말이 무색할 지경이다. 마이크로소프트는 왜 IIS 7.0에서 IIS 6.0 기반의 FTP 서비스를 제공하고 있는 것일까? 더군다나 지금 본문에서는 롱혼 서버를 살펴보고 있지만 비스타에서도 이와 같은 사정은 별반 다르지 않다. 이런저런 얘기할 것 없이 결론부터 얘기하도록 하겠다. 2007년 5월 중순 현재, 이미 출시된 비스타 제품군 및 롱혼 서버 베타 3 버전, 즉 최근 윈도우 서버 2008로 정식 명칭이 결정된 서버 제품군의 베타 3에 포함된 IIS 7.0에는 IIS 6.0을 기반으로 하는 FTP 서비스가 포함되어 있다. 그리고, 명실공히 IIS 7.0에 걸맞는 새로운 FTP 서비스인, 이른바 FTP7은 현재 개발이 한창 진행중에 있다. 바야흐로 드디어 FTP7에 대해서 알아볼 시간이 왔다.

진정한 도약, FTP7 !

이처럼 두 종류의 FTP 서비스가 제공되는 이유는 사실 그리 대단한 것이 아니다. 개발팀원들의 블로그나 기타 여러 가지 내용들을 종합해보면 단지 비스타 제품군이 출시될 때까지 IIS 개발팀에서 FTP7의 개발을 미처 완료하지 못했던 것이 그 근본적인 원인인 듯 하다. 결과적으로 서버 관리자분들은 머리 속이 상당히 복잡해진 느낌을 받고 있겠지만, 한 가지 확실한 점은 필자가 감히 단언하건데 이 FTP7 이야말로 바로 우리들이 기다리고 있던 바로 그 물건이라는 점이다. 그 동안 구버전의 IIS에서 제공되던 FTP 서비스를 사용하면서 느꼈던 여러가지 아쉬운 점들이 비록 전부는 아닐지라도 상당 부분 해결되었으며, 몇 가지 기능들은 아예 기대하지도 않던 것들이다. 한 마디로 말해서 그 정도는 참고 기다릴 만큼 가치가 있다는 것이다. FTP7은 윈도우 서버 2008 제품군이 출시되는 시점에 즈음해서 또는 동시에 제공될 계획으로 있으며, 현재까지 베타 상태인 FTP7의 설치 파일은 다음의 경로에서 다운로드 받을 수 있다. 그러나 안타깝게도 x64 등 다른 버전들은 아직까지 제공되지 않는 듯 하다. 본문에서는 이 중, x86 버전을 기준으로 살펴보기로 한다.

FTP7 Server Beta (x86)
FTP7 Server Beta (amd64)

다운로드 받은 설치 파일은 .msi 파일의 형태를 띄고 있으며, 롱혼 서버 베타 3에서 단순히 관리자 권한으로 실행시키기만 하면 설치가 진행된다. 당연한 얘기겠지만 FTP7은 IIS 7.0에서만 동작하므로 혹시라도 IIS 6.0 이하의 버전에도 설치할 수 있을까 하고 살짝 기대하셨던 분들은 기대를 접으시기 바란다. 게다가 롱혼 서버에 설치하는 경우에도 일단은 베타 3 버전 이상을 권장하고 있으며, 심지어 현재의 베타 버전은 비스타에도 설치가 불가능하므로 이 점을 감안하기 바란다. IIS 개발팀의 블로그에 따르면 비스타 지원 버전은 곧 추가로 제공될 예정이라고 한다. 그 밖에도 IIS 개발팀에서는 IIS 7.0에 기본적으로 포함된 IIS 6.0 기반의 FTP 서비스가 이미 설치되어 있다면 이를 먼저 제거한 뒤에 FTP7을 설치하는 것을 권장하고 있다. 그렇지만 필자가 테스트 해 본 바에 따르면 두 FTP 서비스를 동시에 설치해도 별다른 문제는 없었다. 다만, 두 서비스가 동일한 포트를 사용하게 될 것이 명약관화하므로, 둘 중 하나의 서비스는 중지시켜 놓는 것이 현명할 것이다. 마지막으로, 아마도 벌써부터 이런 환경을 구축해 놓은 분들은 별로 안계시겠지만, IIS7이 새롭게 제공해주는 기능인 구성 설정 공유 환경(Shared Configuration Environment)이 설정되어 있다면, 반드시 먼저 제거한 다음에, 웹 팜에 존재하는 각각의 서버에 FTP7을 설치하고 나서 다시 이를 복구해야 한다.

다음은 FTP7 설치 마법사의 첫 화면이다. 지금부터 보게 되겠지만 FTP7의 설치 과정은 무척 단순한 편이다. 버튼을 눌러 다음 화면으로 이동한다.

라이센스 관련 화면이 나타난다. 역시 버튼을 눌러 다음 화면으로 이동한다.

다음 화면에서는 설치할 구성 요소들을 선택할 수 있다. 본문에서는 모든 구성 요소들을 설치한다.

다음 화면에서는 실제로 FTP7을 설치하기 전에 이전 화면에서 선택한 구성 요소를 변경할 수 있는 기회를 마지막으로 제공해준다. 별다른 문제가 없다면 Insatll 버튼을 눌러서 설치를 시작한다.

이제 설치 작업이 진행된다. 실제로 설치 작업에 걸리는 시간은 그리 길지가 않다.

기본적인 설치 작업은 모두 완료되었으나 FTP7이 정상적으로 동작하기 위해서는 먼저 IIS를 재시작해줘야만 한다. Restart IIS 버튼을 클릭하면 명령 프롬프트 창이 실행되고 잠시 기다리면 IIS가 재시작 될 것이다.

모든 작업이 완료 되었다. Finish 버튼을 클릭하여 마법사를 종료한다.

정상적으로 FTP7을 설치했다면 관리 도구 메뉴나 서버 관리자를 통해서 서비스 스냅인을 실행시켜 보자. 그러면, 두 종류의 FTP 서비스가 동시에 공존하고 있는 것을 직접 확인할 수 있을 것이다. 이 중, 파란색으로 하이라이트 되어 있는 Microsoft FTP Service가 바로 새로운 FTP7 서비스이고, 서비스 목록에서 두 번째 줄에 위치한 FTP Publishing Service가 기존의 FTP 서비스인데, 만약 이 기존 FTP Publishing Service가 '시작됨 (Started)' 상태라면 일단 서비스를 중지하고 시작 유형도 '수동 (Manual)'으로 변경해 놓도록 하자. 이는 두 개의 서비스가 동일한 포트를 사용함으로서 발생할 수도 있는 문제를 조금이라도 줄이기 위한 것이다. 게다가 사실 FTP 서비스를 두 개씩 운영할 필요도 없으니까 말이다.

그런데 막상 잔뜩 기대를 하고서 인터넷 정보 서비스 관리자를 실행시켜보면 다음과 같이 그리 달라진 점이 눈에 띄지 않는다. 기존의 FTP 서비스를 위한 노드외에는 별다른 FTP 관련 노드도 보이지 않을 뿐더러, 이 노드 자체도 그다지 달라진 것 같지는 않다. 아직도 뭔가 또 남아 있는 작업이 있는 것일까?

다행스럽게도 그런 것은 아니므로 안심하기 바란다. 남은 일은 FTP7의 기능들을 하나씩 살펴보는 것 뿐이다. 다만 지면 관계상, 그리고 업데이트 관계상 본문에서는 FTP7을 설치하는 방법까지만 알아보고 실제로 FTP7이 제공해주는 각각의 기능들은 다음글에서 살펴보고자 한다. 만약 본문에서 이 부분들까지 모두 다루려고 한다면 필자가 글을 작성하는 패턴을 미루어 짐작해보건데 업데이트가 한 달은 더 걸릴 것이 뻔한데다가, 내용이 부실해질 가능성도 매우 높다. 더군다나 FTP7의 일부 기능들은 각각 그 자체만으로도 하나의 문서가 필요할 정도로 방대하기도 하다. 그 대신 FTP7에서 제공해주는 새로운 기능들이 궁금한 분들을 위해서 한국 마이크로소프트 백승주 대리님의 다음 글들을 소개해드리고자 한다. 사실 이 링크의 글들에는 필자의 다음글을 이해하기 위해 거의 필수적으로 한 번쯤은 미리 읽어봐야 될 내용들이 담겨 있다.

• 꼬알라의 하얀집... : FTP 서비스를 사용자 별로 제공하고 싶다면?!
• 꼬알라의 하얀집... : Windows Server 2008이 나오면... (24) - FTP on IIS 7.0

이 문서들은 필자가 본 FTP7 관련 한글 자료들 중 가장 일목요연하고 심플하게 정리가 잘 된 자료들이다. 게다가 FTP7 말고도 서버 관련 분야의 다양하고 훌륭한 정보들이 많이 제공되는 블로그이므로 서버 관리자 분들이라면 반드시 즐겨찾기에 추가해 놓아야 될 블로그라고 생각한다.