 TechNet Magazine November 2007

TechNet Magazine November 2007

Windows Administration: Windows Vista의 오프라인 파일 변경 내용

연결이 불안정하거나 없는 사용자가 네트워크에 저장된 파일로 작업하도록 허용하면서 버전 관리 문제를 방지하려면 어떻게 해야 하는가는 흔히 마주치는 문제입니다. 매끄러운 환경을 제공하려면 이러한 연속성이 반드시 필요합니다. Windows Vista에서 개선된 기능이 얼마나 더 나은 오프라인 파일 작업 방법을 제공하는지 알아보십시오.

Jeremy Moskowitz Desktop Deployment: BDD 2007을 사용한 간단하고 확장 가능한 배포

SMS 2003이 없다고요? 걱정하지 마십시오. 간단한 데스크톱 배포를 만들 수 있는 다른 솔루션이 있으니까요. 여기에서는 BDD 2007과 SQL Server를 사용하여 수동 입력이 전혀 또는 거의 필요 없는 확장 가능한 배포를 만드는 방법을 자세히 알아봅니다.

Adam Shepherd Communications: Microsoft의 Exchange Edge 전송 서버: 2부

Exchange Edge 전송 서버를 사용하면 더욱 안정적이고 안전한 메시징 환경을 만들 수 있습니다. 1부에서는 이러한 서버를 구성하는 방법을 알아보았으므로 이제 주요 기능을 사용하여 메시징 환경을 개선하는 몇 가지 자세한 예를 살펴보겠습니다.

Kay Unkroth Networking: ISA Server 2006으로 VPN 원격 액세스 구성

가상 사설망은 개선된 연결과 향상된 생산성을 제공할 수 있으며 구현 및 관리가 비교적 용이합니다. ISA Server 2006을 사용하여 두 가지 일반 VPN 시나리오를 구현하는 방법에 대해 알아보십시오.

Alan Maddison SQL Server: SQL Server 쿼리 성능 최적화

데이터베이스의 성능을 최적화할 때 개별 쿼리의 튜닝은 서버 하드웨어와 소프트웨어 구성의 튜닝만큼 중요합니다. 제어하지 못한 쿼리 하나가 데이터베이스 전체를 무력화시킬 수 있습니다. SQL Server 쿼리의 성능을 최적화하기 위해 실행 계획을 생성, 분석, 조정하는 지침을 설명합니다.

Maciej Pilecki From the Editor: 그린 컴퓨팅

Joshua Hoffman Toolbox: IT 전문가를 위한 새로운 제품

Greg Steen Exchange Queue & A: 보안 전자 메일 프로토콜, 알 수 없는 스팸 등

이달 기사에서는 Exchange 팀과 함께 SMTP의 전송 계층 보안, 스푸핑된 NDR이 큐에서 정체를 일으키지 않도록 방지하는 방법, 그리고 다양한 설치 문제를 해결하는 방법을 살펴보겠습니다.

Nino Bilic and Scott Landry Utility Spotlight: Windows PowerShell용 SMS Cmdlet

Windows PowerShell cmdlet을 사용하여 명령줄에서 SMS 2003 클라이언트를 관리하는 방법을 배워 봅니다.

Don Brown The Cable Guy: 무선 SSO(Single Sign-On)

SSO(Single Sign On)는 최종 사용자와 관리자 모두에게 많은 장점을 제공합니다. 이 글에서는 SSO를 사용하여 네트워크의 무선 인증 환경을 간소화하는 방법을 살펴보겠습니다.

Joseph Davies Research Notes: HPC(고성능 컴퓨팅)을 활용한 HIV 치료법 개발

Microsoft Research의 eScience 팀이 의학 연구원들과 함께 고성능 컴퓨팅을 통한 HIV 치료법 개발을 위해 협력하는 과정을 살펴봅니다.

Kristin Firth and Mia Matusow Windows PowerShell: 정규식 작성

Windows PowerShell 스크립트에서 잘 작성된 정규식을 사용하면 데이터가 올바른 형식에 맞는지 여부를 확인할 수 있습니다. Windows PowerShell에서 정규식을 사용하는 방법을 대략적으로 살펴보겠습니다.

Don Jones Hey, Scripting Guy!: 무덤에서 일어난 데스크톱 관리

Scripting Guys는 Windows Remote Management를 이용하여 원격 컴퓨터에 있는 클래스의 인스턴스와 속성을 조회하는 방법을 보여드립니다. 물론 근사한 퍼즐도 있습니다.

The Microsoft Scripting Guys Security Watch: 어디서든 안전하게 액세스

터미널 서비스 구성 요소를 사용하여 어디서든 액세스 가능한 솔루션과 관련한 네트워크 및 보안 설계 고려 사항을 살펴보고 Windows Server 2008을 사용하여 솔루션을 작성하는 몇 가지 실용적 기법과 최상의 방법을 알아봅니다.

John Morello The Desktop Files: 조각 모음에 관한 진실

조각 모음에 대한 오해 때문에 중요한 유지 관리 작업의 하나인 조각 모음을 기피해온 관리자들이 많습니다. 사실은 무엇이고 잘못 알려진 것은 무엇인지 그리고 진짜 문제를 방지하는 방법은 무엇인지 알아보겠습니다.

Wes Miller Field Notes: 사용 규정

커뮤니티 회원이 활동을 시작하면 사용 규정이 필요하게 됩니다. 사회 공학이 Live QnA에 일조하게 된 이야기를 들어 보십시오.

Betsy Aoki Windows Confidential: 파일 시스템의 모순

이 중요한 부팅 파일에 기본으로 제공되는 간단한 파일 시스템 드라이브가 왜 필요한지 궁금한 적이 있었습니까?

Raymond Chen


 Windows Administration: Windows Vista의 오프라인 파일 변경 내용
Windows Administration Jeremy Moskowitz

Windows Vista의 오프라인 파일 변경 내용
한 눈에 보기:
  • 온라인 및 오프라인 연속성
  • 파일 가용성
  • 오프라인 폴더의 진화 방식

데스크톱 관리에서 가장 힘든 문제 중 하나는 오프라인 사용자에게 온라인에서 작업할 때와 동일한 작업 환경을 제공하는 것입니다. 5년 전에 비해서도 훨씬 더 복잡한 모바일 환경이 사용되고 있어 생각보다 더 많은 것이 필요합니다. 오프라인으로 작업해야 하는 경우가 많이 있지만
가장 일반적인 세 가지 경우로는 이동 중에 랩톱과 사무실 네트워크 간의 연결을 끊는 경우, 느리거나 간헐적으로 끊기는 링크를 통해 연결하는 경우, 지사와 본사 간의 연결이 끊기는 경우를 들 수 있습니다.
이러한 상황에서 파일 원본이 주 서버에 있는 동안 오프라인 컴퓨터에 있는 복사본을 유지 관리하려면 어떻게 할까요? 더욱 중요한 것은 집에서 일하는 누군가와 이동 중인 다른 누군가가 동시에 서버의 파일을 변경할 경우 충돌을 처리하는 방법입니다. 다행히도 이러한 문제는 Windows® 2000, Windows XP 및 Windows Vista®에 기본 제공된 오프라인 파일 엔진으로 처리됩니다.

캐시가 해답
오프라인 파일 엔진은 정말로 거대한 캐시 시스템입니다. 실제로 이면에서 그리고 Microsoft 내부에서는 이 엔진을 CSC(클라이언트 쪽 캐시)라고 합니다. 오프라인 파일 엔진은 구성이 가능하고 유연하기 때문에 관리자 여러분이 원하는 방식으로 시스템 캐시를 설정할 수 있을 뿐만 아니라 사용자가 원하는 캐시 항목을 직접 결정할 수도 있습니다. 이 엔진을 사용하면 온라인에서와 같은 파일에 오프라인으로 액세스할 수 있으며 네임스페이스가 바뀌지 않습니다. 즉, 온라인으로 작업하든 오프라인으로 작업하든 같은 UNC 경로나 드라이브를 사용하여 파일이 액세스됩니다.
수동으로 또는 자동으로 캐시할 파일을 설정할 수 있습니다. 이동 중에 특정 파일이나 폴더를 자주 사용할 경우에는 가지고 다닐 파일이나 폴더로 지정하면 됩니다. 이렇게 하려면 Windows XP 사용자는 로컬로 저장되거나 네트워크 공유에 저장된 파일을 마우스 오른쪽 단추로 클릭하고 파일을 오프라인으로 사용할 수 있도록 만드는 옵션(그림 1 참조)을 선택합니다. Windows Vista에서는 이 옵션을 항상 오프라인 사용 가능이라고 합니다. 수동으로 파일을 오프라인으로 사용할 수 있도록 만드는 것을 파일 고정(Pinning)이라고도 합니다.
그림 1 파일을 오프라인으로 사용할 수 있도록 만들기
그림 1 파일을 오프라인으로 사용할 수 있도록 만들기
그림 1a 오프라인 파일 폴더
그림 1a 오프라인 파일 폴더
사용 중인 공유는 UNC 경로를 통해 연결하거나 드라이브 문자로 매핑할 수 있습니다. 실제로 파일은 Windows Server®를 실행 중인 시스템에 저장된 것이 아니어도 됩니다. SMB 프로토콜도 준수하는 Samba 서버나 NAS 장치(드물지만 약간의 예외가 있음)와 같이 SMB(서버 메시지 블록) 프로토콜을 따르는 모든 시스템에 상주할 수 있습니다.
처음으로 파일을 고정하도록 선택하면 Windows XP에서 일련의 마법사 화면을 차례로 안내하면서 동기화할 시기를 묻습니다. 모든 화면에서 다음을 클릭하고 기본값을 그대로 사용하면 로그온 또는 로그오프할 때마다 동기화가 발생하는데, 유휴 상태일 때는 백그라운드에서도 동기화가 발생합니다. 마법사가 완료되면 아이콘이 변경되어 이제 파일을 오프라인으로 사용할 수 있다고 알려 줍니다.
네트워크 연결을 끊은 후에는 오프라인으로 사용할 수 있도록 선택한 파일을 제외하고 공유에 있는 다른 모든 파일이 사용 불가능해집니다. 이로 인해 문제가 발생하는 경우가 있습니다. 즉, 항상 오프라인으로 사용할 수 있는 파일은 아이콘으로 알 수 있지만 다른 모든 파일은 연결을 끊은 후에야 사용할 수 없다는 것을 분명히 알 수 있습니다. 이에 대해서는 뒷부분에서 자세히 살펴보겠습니다.
수동으로 파일을 오프라인으로 사용할 수 있도록 만드는 것에도 나름의 장점이 있지만 이 작업을 보다 자동화된 방식으로 수행하는 편이 더 나은 경우가 있습니다. 다음에 자동 캐시라고도 하는 방법을 사용하여 이러한 시나리오를 살펴보겠습니다.

자동 캐시가 수동 캐시보다 더 나은 경우
자동 캐시는 서버에서 공유별로 설정됩니다. 따라서 Sales라는 공유가 있는 경우 판매원이 이동 중에 파일을 가지고 다닐 수 있도록 하려면 CSC 엔진에 그렇게 하라고 지시할 수 있습니다. 그림 2는 Windows Server 2003에서 캐싱 탭을 클릭할 때 나타나는 오프라인 설정 대화 상자를 보여 줍니다. 설정은 그림 3에서 설명합니다.
Figure 3 자동 캐시 설정 (Close Figure 3)

설정 | 설명
사용자가 지정하는 파일과 프로그램만 오프라인으로 사용할 수 있습니다. | 오프라인으로 사용할 파일을 사용자가 수동으로 지정할 수 있습니다. 이것이 기본값입니다.
사용자가 공유에서 여는 모든 파일과 프로그램을 자동으로 오프라인으로 사용할 수 있습니다. | Windows 탐색기가 건드리는 모든 파일과 프로그램을 자동 캐시할 수 있습니다. 성능 최적화 설정은 문서가 아닌 프로그램을 캐시할 때 사용되지만 일반적으로 성능에 아무 효과가 없으며 대부분의 경우 무시해도 안전합니다.
공유에 있는 파일이나 프로그램을 오프라인으로 사용할 수 없습니다. | Windows 2000, Windows XP 또는 Windows Vista 클라이언트에서 사용할 경우 오프라인 사용 가능 항목에 대한 사용자 액세스를 차단합니다.
그림 2 Windows Server 2003의 오프라인 설정 대화 상자
그림 2 Windows Server 2003의 오프라인 설정 대화 상자
자동 캐시의 작동 방식을 보기 위해 Sales01.txt에서 Sales10.txt까지 10개의 파일이 들어 있는 Sales 공유가 있고, 사용자가 공유에서 여는 모든 파일 및 프로그램을 자동으로 오프라인에서 사용할 수 있게 해주는 설정을 활성화했다고 가정하겠습니다. 결과가 즉시 명확해지는 것은 아닙니다. 사용자 측면에서 볼 때 갑자기 오프라인으로 더 많은 파일을 사용할 수 있게 되었음을 알려 주는 외형적인 신호가 없습니다. 또한 Windows에서 열어 캐시한 파일만 나중에 오프라인으로 사용할 수 있습니다. 간단히 말해 네트워크 연결을 실제로 끊기 전에 오프라인으로 사용할 파일을 온라인으로 실제로 열어야 합니다. 그렇지 않으면 필요할 때 오프라인으로 사용할 수 없습니다.
더욱이 자동 캐시된 파일이 캐시에 영구적으로 머물지 않을 수도 있습니다. Windows XP와 Windows Vista의 캐시 처리 방식은 약간 다르지만 핵심은 공간 제약에 따라 캐시에서 파일을 방출할 수 있다는 점입니다. 파일은 사용 시점을 기준으로 보관됩니다. 한동안 열지 않은 파일은 새로 연 파일에 필요한 공간을 확보하기 위해 방출됩니다. 따라서 최근에 작업한 파일이 캐시에 여전히 머물러 있을 확률이 높지만 자동 캐시가 파일의 가용성을 보장한다고는 가정하지 마십시오. 파일의 가용성을 보장하려면 파일을 고정해야 합니다. 관리자는 그룹 정책을 사용하여 관리적으로 지정된 오프라인 파일이라는 설정을 사용하여 파일을 고정할 수도 있습니다.
실제 작업 예를 살펴보겠습니다. EastSalesUser1이라는 Windows XP 사용자는 Sales05.txt 파일을, EastSalesUser2라는 Windows Vista 사용자는 \\server\sales 공유에 있는 Sales05.txt 파일을 열었다고 가정해 봅시다.
Sales 공유에 자동 캐시가 설정되었기 때문에 Windows XP의 EastSalesUser1과 Windows Vista의 EastSalesUser2가 오프라인으로 전환되더라도 여전히 이들 파일에 대해 작업할 수 있습니다. Windows에서 이들 파일의 복사본을 오프라인 파일 캐시에 저장했습니다. 그러나 사용자가 아직 사용하지 않은 다른 파일은 어떨까요?
그림 4와 5에 표시된 바와 같이 사무실에 남겨진 파일에 대한 Windows XP와 Windows Vista의 반응은 서로 다릅니다. Windows XP에서는 캐시되지 않은 채로 남겨진 파일의 존재 여부조차 알 수 없습니다. 오프라인으로 전환할 때 이들 파일이 사라질 뿐이므로 잠재적으로 혼란을 야기할 수 있습니다. 반대로 Windows Vista에서는 아이콘 오버레이가 발생하며 캐시되지 않은 파일에 대해 약간 희미한 X 표시가 나타나는데, 이는 오프라인으로 사용할 수 있는 파일을 표시함에 있어 비약적인 발전입니다. 유일한 문제는 온라인 세션 중에는 볼 수 없고 연결을 끊은 후에야 볼 수 있다는 것입니다. 따라서 파일 상태를 더욱 명시적으로 만드는 것은 아주 환영할만한 추가 기능입니다.
그림 4 Windows XP - 오프라인으로 전환한 후 사용할 수 있는 파일만 표시
그림 4 Windows XP - 오프라인으로 전환한 후 사용할 수 있는 파일만 표시
그림 5 Windows Vista - 오프라인인 동안 사용할 수 없는 파일 표시
그림 5 Windows Vista - 오프라인인 동안 사용할 수 없는 파일 표시

사용 가능 또는 사용 불가능
오프라인으로 분명히 사용할 수 있는 파일과 사용할 수 없는 파일 그리고 이들을 구별하는 방법 등에 대한 잠재적인 혼란 때문에 오프라인 파일 활용을 주저하는 관리자가 있습니다. 그림 5에서 sales01.txt 위의 녹색 원 아이콘은 파일의 가용성이 보장됨을 나타냅니다. 다시 말해 파일이 고정되면 오프라인에서의 가용성이 보장됩니다.
하지만 앞서 설명한 바와 같이 Windows XP와 Windows Vista 모두 자동 캐시를 통해 오프라인 사용을 설정한 Sales05.txt는 오프라인에서 사용하지 못할 수도 있습니다. 작업한 파일만 오프라인으로 사용할 수 있습니다. 따라서 시스템에서 파일이 오프라인으로 임시로 사용할 수 있거나 오프라인으로 사용할 가능성이 있음을 나타내는 편이 더 낫습니다. 아이콘에 차이가 나지 않으므로 오프라인으로 사용할 수 있는 파일을 결정하기가 혼란스러울 수 있습니다. Windows Vista UI가 더 낫지만 여전히 세심한 주의가 필요합니다. Windows Vista에서는 오프라인 사용 가능이라는 탐색기 속성이 가용성 정보를 제공합니다. 이 속성은 항목 선택 시 미리 보기 창에 표시됩니다. 항목이 고정된 경우 값은 "항상 가능"입니다. 고정되지 않았지만 캐시된 경우에는 값이 "사용 가능"입니다.
오프라인 임시 사용 가능의 원리는 Windows XP와 Windows Vista에서 비슷하지만 구현은 약간씩 다릅니다. 그림 6은 Windows XP와 Windows Vista의 오프라인 파일 처리 방법을 보여 줍니다.
그림 6 Windows XP와 Windows Vista의 오프라인 파일 영역
그림 6 Windows XP와 Windows Vista의 오프라인 파일 영역
단순화하기 위해 Windows XP와 Windows Vista 모두 오프라인 파일을 한 곳에 보관하지만 항상 오프라인 사용 가능 파일과 오프라인 임시 사용 가능 파일은 운영 체제마다 약간씩 다르게 저장됩니다.
Windows XP의 경우 항상 오프라인 사용 가능 파일(그림 1에 표시된 바와 같이 바뀐 아이콘으로 알 수 있음)은 영구적으로 머무는 곳에 저장됩니다. 수동으로 10GB의 파일을 고정하여 항상 오프라인 사용 가능으로 만들면 항상 10GB를 모두 사용할 수 있습니다. 최대 파티션 크기를 빼고는 사용자가 고정할 수 있는 파일 개수에 제한이 없습니다. 하지만 Windows XP에서는 자동 캐시된 파일 크기가 최대 2GB입니다. 원리에 따르면 정기적으로 열리는 파일만 여기에 저장되고 한동안 사용하지 않은 파일은 필요할 때 방출됩니다. 기본적으로 임시 사용 가능 캐시에는 그림 7에 표시된 바와 같이 사용 가능한 하드 드라이브 공간의 10%가 할당되어 있습니다. Windows XP에서는 관리자만 이 설정을 사용할 수 있습니다.
그림 7 Windows XP에서 오프라인 파일의 디스크 공간 설정
그림 7 Windows XP에서 오프라인 파일의 디스크 공간 설정
Windows Vista에서도 파일을 영구적으로 또는 임시로 저장할 수 있습니다. 그러나 차이가 있습니다. 임시 파일 캐시는 전체 캐시 내에 포함됩니다. 기본적으로 전체 캐시(임시 파일과 항상 오프라인 사용 가능 파일을 모두 포함)는 사용 가능한 하드 드라이브 공간의 25%로 제한됩니다. 이것이 변경된 이유는 Windows XP에서는 사용자가 수동으로 파일 캐시를 유지하여(수십 기가바이트까지) 결국 하드 드라이브 공간을 모두 소모할 수 있기 때문입니다. 새로운 체계에서는 관리자가 전체 캐시에 대한 공간을 할당하여 이러한 현상이 발생하지 않도록 할 수 있습니다. 그림 8을 보면 사용 가능한 드라이브 공간의 25%가 혼란스럽게도 전체 드라이브의 15.2%로 표시되어 있습니다. 또한 임시 공간을 설정하는 두 번째 슬라이더는 모든 오프라인 파일의 최대 공간을 설정하는 첫 번째 슬라이더보다 높게 설정될 수 없습니다. 이들 오프라인 파일 디스크 사용 한도 슬라이더는 한도 변경 옵션을 클릭하여 액세스되지만 이렇게 하려면 관리자 자격 증명이 있어야 합니다.
그림 8 Windows Vista에서 오프라인 파일에 사용할 수 있는 공간
그림 8 Windows Vista에서 오프라인 파일에 사용할 수 있는 공간

과도한 캐시 방지
폴더 리디렉션이라는 또 다른 Windows 기능을 사용하면 대개 시스템에 로컬로 존재하는 특정 주요 폴더가 실제로 서버에 저장되도록 할 수 있습니다. 이 개념은 로컬 시스템이 망가지는 경우를 걱정할 필요가 없도록 중요한 파일을 네트워크 공유에 복사본으로 유지하는 것입니다.
리디렉션된 내 문서 폴더(Windows XP의 경우)나 문서 폴더(Windows Vista의 경우)가 있다고 가정해 봅시다. 이 경우(실제로는 임의의 폴더가 리디렉션된 경우) 운영 체제에서는 사용자가 파일을 오프라인으로 항상 사용할 수 있기를 바란다고 간주하며 그림 1에 표시된 기호가 리디렉션된 폴더 내의 모든 파일에 수신됩니다. 단점은 잘 연결되어 항상 온라인 상태인 네트워크에 있을 때 새 시스템으로 로밍하면 하나의 세션에만 사용할 계획이더라도 리디렉션된 폴더의 전체 내용이 새 시스템에 캐시된다는 것인데, 이는 공간 낭비일 뿐 아니라 제대로 처리하지 않을 경우 보안 위험이기도 합니다.
파일이 알지 못하는 사이에 자동으로 캐시되는 또 다른 사례는 Windows 탐색기를 사용하여 공유에 있는 파일을 찾아보는 경우입니다. 자동 캐시가 설정된 경우 탐색기로 네트워크 공유에 있는 그래픽 파일들을 보기만 해도 해당 파일들이 자동으로 다운로드되어 캐시에 저장될 가능성이 매우 높은데, 이는 탐색기를 사용하여 파일을 건드리면 임시 오프라인 캐시에 저장될 가능성이 높기 때문입니다. 이미지의 미리 보기나 파일 크기와 같은 메타데이터를 가져오기 위해 공유에 있는 모든 파일을 건드리는 경우가 있습니다. 이것이 잘 연결된 빠른 링크를 통해 발생하면 별 문제가 없습니다. Windows에서 나중에 사용할 수 있게 파일을 빠르고 조용하게 캐시합니다. 그러나 느린 링크를 통해 자동 캐시가 있는 네트워크 공유에 연결되어 있을 때는 정말로 문제가 커질 수 있습니다. Windows XP 탐색기와 Windows Vista 탐색기의 경우에도 기본적으로 상황이 바뀌지 않았습니다. 다만 좋은 소식이라고 한다면 Windows Vista의 오프라인 캐시 엔진은 학습을 통해 느린 링크 인식 기능을 향상시킬 수 있다는 점입니다.

그룹 정책이 있는 오프라인 파일
Windows Vista 오프라인 파일의 주요 변경 내용
오프라인 파일 팀원들마다 각기 독자들에게 알리고 싶은 변경 사항이 있었지만 지면 부족으로 모두 싣지는 못했습니다. 따라서 아래에서 오프라인 파일의 주요 변경 내용을 간략히 소개하겠습니다.
  1. 열린 핸들이 더 이상 전환을 차단하지 않으므로 오프라인에서 온라인으로 매끄럽게 전환됩니다.
  2. 파일 단위 오프라인 세분성. 하나의 오프라인 공유가 더 이상 오프라인으로 전체 서버를 책임지지 않습니다.
  3. Windows 탐색기의 온라인으로 작업\오프라인으로 작업 단추를 통한 강제 오프라인 모드
  4. 캐시된 콘텐츠의 사용자 단위 암호화
  5. 변경 내용 검색 및 분석 시 훨씬 더 빠른 새 동기화 엔진
  6. Windows 검색과의 통합. 리디렉션된 폴더를 인덱싱할 수 있습니다.
  7. 로컬-원격 동기화에서 차등 비트맵 전송 기능을 활용할 수 있습니다.
  8. 동기화 센터를 통한 지연된 충돌 해결
  9. 알림 영역 풍선이 사라져서 더 이상 사용자를 괴롭히지 않습니다.
  10. 관리를 위한 새 종합적인 COM API 및 WMI 지원. MSDN®(msdn2.microsoft.com/bb530662)에 문서화되어 있습니다.
  11. WMI 공급자를 통한 스크립트 지원. MSDN에서 곧 문서화됩니다.
  12. 새 셸 항목 속성인 오프라인 상태 및 오프라인 사용 가능
  13. 오프라인인 동안 사용할 수 없는 네임스페이스 요소를 나타내는 고스트 기능. 탐색기에서 이러한 요소는 회색 X 표시가 겹쳐진 희미한 항목으로 표시되어 온라인에서 오프라인으로 전환할 때 급격한 셸 폴더 보기 변경을 방지할 수 있도록 합니다.
  14. 새 제어판 설정 애플릿
원할 경우 필자가 집필한 책과 Microsoft 설명서에서 자세한 정보를 찾을 수 있습니다.

앞서 설명한 바와 같이 사용자나 탐색기가 파일을 건드릴 때마다 전체 파일이 캐시에 저장됩니다. 해당 파일이 80MB의 Visio® 또는 Word 문서여도 마찬가지입니다. Windows XP와 Windows Vista 모두 느린 링크가 무엇인지 이해합니다. 실제로 Windows XP에서는 기본적으로 느린 링크가 64Kbps라고 간주합니다. 연결 속도가 이보다 빠르더라도 클라이언트가 Windows XP이면 로그온할 때 이 느린 파이프라인을 통해 해당 파일이 다운로드되어 사용자를 매우 당황스럽게 만듭니다. 따라서 느린 링크를 통해 수행할 작업을 더 잘 관리하도록 Windows를 구성하는 것이 가장 좋습니다. 잠시 후 살펴볼 테지만 이 작업은 대상 계정(Windows XP 또는 Windows Vista)을 포함하는 OU(조직 구성 단위)에 연결될 GPO(그룹 정책 개체)를 만들어 그룹 정책을 통해 수행할 수 있습니다.
사용자가 느린 링크를 통해 연결하면 Windows XP에서는 네트워크 복사본을 사용하기 전에 로컬로 캐시된 파일을 사용하려고 합니다. 이는 적절한 동작입니다. 그러나 Windows XP에서는 여전히 예상할 수 없는 무언가를 수행합니다. 즉, 사용자가 네트워크에서 열거나 탐색기가 건드리면 아직 해당 사용자의 캐시에 없는 큰 파일이 다운로드됩니다. 애석하게도 말입니다. 그리고 필자의 테스트에서 로그오프할 때 발생하도록 동기화 일정을 잡은 경우(기본값) 해당 파일의 나머지는 느린 링크를 통해 다운로드되어 캐시에 저장되었습니다. 아주 애석하게도 말입니다.
Windows Vista의 동작은 다릅니다. 기본적으로 어떠한 상황도 느린 것으로 인식하지 않습니다. 깡통과 실로 연결하여 초당 1비트를 가져온다 해도 Windows Vista는 이 연결을 빠른 연결로 취급하고 네트워크의 파일 복사본을 사용합니다. 그러나 Windows Vista는 학습을 통해 연결이 느린 경우에 어떤 공유로 전환해야 할지 파악할 수 있습니다. 따라서 그와 같은 경우가 발생할 때 전보다 상황이 호전됩니다. 그룹 정책을 사용하여 구성한 후에는 일반 파일과 탐색기 작업을 사용하여 느린 링크를 통해 slow-link-defined 공유의 콘텐츠를 사용할 수 없도록 Windows Vista가 작동합니다.
오프라인 파일 서비스가 수행하는 백그라운드 동기화는 느린 연결을 통해 발생하지 않습니다. 하지만 수동 동기화는 동기화 센터를 통해 수행할 수 있습니다.
느린 링크 처리를 수정하도록 Windows Vista를 구성하는 작업은 느린 링크 모드 구성(비슷한 이름의 Windows XP 설정인 저속 링크 구성과 혼동하지 말 것)이라는 그룹 정책 설정을 통해 수행됩니다. 느린 링크 모드를 구성하는 데는 연결이 느릴 때 자동으로 오프라인으로 전환할 서버 및 공유 이름, 그리고 해당 서버\공유 조합이 오프라인으로 전환되는 느린 연결 속도의 기준이 값으로 사용됩니다. 서버\공유 조합은 임의의 \\서버\공유 조합이 될 수도 있고 모든 서버의 모든 공유를 나타내는 단일 별표(*)가 될 수도 있습니다. 두 번째 값 집합은 느린 연결 선언을 위한 임계점으로 사용되는 처리량(kbps)과 대기 시간(밀리초)을 선언합니다. 한 가지 알아 둘 점은 두 가지 중 더 유용한 값, 즉 처리량은 파일을 다운로드할 때 검사되지 않는다는 것입니다. 따라서 리디렉션된 문서 폴더에 10GB의 파일이 있고 아직 해당 파일을 포함하지 않는 랩톱에서 느린 링크를 통해 연결하는 경우에는 오래 기다릴 준비를 하십시오. 그러나 대기 시간 검사와 쌍으로 묶은 경우 대기 시간이 규정된 값 아래로 떨어지면 공유가 오프라인으로 전환되어 사용자가 해당 파일을 기다려야 하는 고통스러운 지연 시간이 없어집니다.
기술 자료 문서 934202에 설명된 Windows Vista 핫픽스(Windows Vista 서비스 팩 1에 포함할 예정임)를 사용하면 특정 느린 VPN 조건에서 성능이 개선됩니다. 이 문서는 support.microsoft.com/kb/934202에서 온라인으로 볼 수 있습니다. 실제로 이 핫픽스는 느린 링크를 통해 다운로드가 발생할 때 처리량 값을 검사하도록 설정합니다.

동기화 충돌
아마도 비행기에 타고 있는 누군가가 오프라인으로 파일을 변경함과 동시에 본사에 배선으로 연결된 다른 사용자가 온라인으로 해당 파일을 변경하면 어떻게 될지 궁금할 것입니다. 이 상황은 클라이언트 수준에서 처리됩니다. 오프라인에서 온라인으로 전환하면 Windows Vista의 오프라인 파일 백그라운드 동기화가 즉시 발생합니다. 그런 다음 작업 표시줄의 알림 영역에 아이콘이 표시된 후 동기화 센터에 있는 항목을 통해 무엇을 수행할지 묻는 메시지가 표시됩니다. 하나의 파일을 최신 파일로 표시하고 충돌에 대한 자세한 정보를 표시하도록 사용자 인터페이스가 다시 설계되었습니다. 그림 9와 같이 사용자가 서버에 다시 저장할 때 현재 자신의 시스템에만 있는 파일의 이름을 바꾸어 충돌이 발생한 파일을 보존할 수 있습니다.
그림 9 Windows Vista의 파일 변경 충돌 알림
그림 9 Windows Vista의 파일 변경 충돌 알림

자세한 정보
오프라인 파일은 관리자와 사용자 모두에게 멋진 기능입니다. 실제로 폴더 리디렉션을 사용하고 있으면 오프라인 파일도 이미 사용하고 있는 것이므로 오프라인 파일을 더욱 잘 파악하는 것이 가장 큰 관심사입니다. Windows Vista의 많은 오프라인 파일 변경 내용을 설명했지만 모두 설명한 것은 아닙니다. 자세한 내용은 "Windows Vista 오프라인 파일의 주요 변경 내용" 추가 기사를 참조하십시오.
go.microsoft.com/fwlink/?LinkId=98141(Windows XP의 경우)과 go.microsoft.com/fwlink/?LinkId=98138(Windows Vista의 경우)에서 오프라인 파일에 대해 자세히 알아볼 수 있습니다.
또한 필자가 집필한 책(기사 끝부분의 약력 참조)에는 모든 그룹 정책 설정의 세부적인 사항을 포함한 오프라인 파일에 대한 내용이 많은 페이지에 걸쳐 설명되어 있습니다. 마지막으로 더 많은 정보가 필요하고 다른 사용자와 오프라인 파일에 대해 얘기해 보고 싶으면 GPanswers.com에서 이 주제만 다루는 섹션이 있는 커뮤니티 포럼을 방문하십시오.

Jeremy Moskowitz는 그룹 정책 분야의 MCSE이자 MVP로, 그룹 정책과 관련된 커뮤니티 포럼인 GPanswers.com을 운영하고 있으며 그룹 정책에 관한 집중적인 교육 워크숍도 진행하고 있습니다. 그의 최근 저서로는 Group Policy: Management, Troubleshooting, and Security(Sybex, 2007)가 있습니다. www.GPanswers.com에서 Jeremy에게 문의하거나 자세한 내용을 볼 수 있습니다.
© 2007 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


 Desktop Deployment: BDD 2007을 사용한 간단하고 확장 가능한 배포
Desktop Deployment Adam Shepherd

BDD 2007을 사용한 간단하고 확장 가능한 배포
한 눈에 보기:
  • BDD 2007의 핵심 기능
  • SQL Server와의 통합
  • 확장 가능한 배포 솔루션 구축

Windows 배포에 관여하고 있는 사람은 대부분 Microsoft Solution Accelerator for Business Desktop Deployment에 대해 들어보았을 것입니다. BDD라고도 알려진 이 솔루션은 클라이언트 데스크톱에 Windows®를 쉽게 배포할 수 있도록
개발된 도구와 최상의 방법 지침을 모아 놓은 솔루션입니다. Windows Vista®에는 BDD 2007이라는 Solution Accelerator의 업데이트가 포함되어 있습니다. 이 버전에는 Systems Management Server(SMS) 2003의 후속 버전인 System Center Configuration Manager 2007을 기반으로 하는 새로운 Microsoft® Management Console(MMC)과 Task Sequencer가 포함되어 있습니다.
BDD 2007의 기능 중 완벽한 배포 솔루션으로서 작동하는 기능은 잘 알려져 있지 않습니다. 이전 버전의 BDD는 관리 및 반복 가능한 방식으로 데스크톱 이미지를 만들고 유지 관리하는 데 필요한 기능을 제공했습니다. BDD 2007에서는 BDD와 Windows 배포 서비스(WDS), SQL ServerTM 및 Windows Server® 2003 분산 파일 시스템 복제(DFS-R)를 결합하여 확장 가능한 배포 솔루션을 구축할 수 있는 추가 기능도 제공합니다.
잠깐! 그런데 지금까지는 Operating System Deployment(OSD) Feature Pack을 SMS 2003과 함께 사용하는 것이 권장되는 Windows 클라이언트 배포 방식이 아니었습니까?
맞습니다. SMS 2003 인프라가 이미 구축되어 있다면 BDD 2007, SMS 2003 및 OSD Feature Pack을 배포에 사용해야 합니다. 현재로서는 이 방식이 무인 배포를 구현할 수 있는 가장 포괄적인 방법이며, 이를 통해 조직에서 Windows를 구성, 설치 및 관리하는 비용을 실질적으로 절감할 수 있습니다.
그러나 SMS 2003이나 이와 동일한 기능의 소프트웨어 배포 솔루션을 보유하지 못한 고객이 많습니다. 이러한 고객은 이 기사에서 소개하는 다른 방법을 사용할 수 있습니다.

BDD 2007 핵심 개념
BDD 2007에서는 두 가지 기본 배포 방법을 제공합니다. 첫 번째 방법은 BDD 2007만 사용하여 클라이언트를 배포하는 Lite Touch Installation 방식입니다. 이 기능은 기본적으로 빌드 시에 클라이언트에 할당할 컴퓨터 이름(그림 1 참조), 사용할 자판 배열 및 표준 시간대 등 배포와 관련한 정보를 캡처하는 여러 가지 마법사를 제공합니다. 이 방식을 "Lite Touch"라고 하는 이유는 일반적으로 빌드 프로세스를 시작하기 전에 이 정보를 수집하는 데 최소한의 수동 입력이 필요하기 때문입니다.
그림 1 BDD 2007 Lite Touch 배포 마법사
그림 1 BDD 2007 Lite Touch 배포 마법사
두 번째 방법은 BDD 2007과 통합된 SMS 2003 및 OSD Feature Pack에 기반을 두는 Zero Touch Installation 방식입니다. 이 구성은 완전히 자동화되고 확장 및 관리 가능한 무인 배포 솔루션을 제공할 수 있습니다.
빌드 시에 클라이언트 OS 배포의 첫 단계에서 BDD 2007은 여러 출처에서 정보를 수집합니다. 이러한 정보 출처에는 WMI 호출, BDD 2007 구성 파일(Bootstrap.ini 및 CustomSettings.ini) 등이 있습니다. 수집된 정보는 배포 프로세스 전반에 걸쳐 사용될 수 있도록 변수로 저장됩니다. Lite Touch 시나리오의 경우 배포 마법사에 수동으로 입력하여 수집해야 하는 모든 정보를 Bootstrap.ini 파일과 CustomSettings.ini 파일에 미리 정의해 둘 수 있습니다.
빌드 시에 Lite Touch 마법사에서 캡처해야 할 모든 정보를 미리 지정함으로써 SMS 2003이 지원하지 않는 환경에서 전체 Lite Touch 프로세스를 자동화하여 Zero Touch 솔루션으로 전환할 수 있습니다. 미리 정의할 수 있는 정보로는 RDG0001VDT라는 이름을 컴퓨터에 할당하는 ComputerName=RDG0001VST, 컴퓨터 표준 시간대를 그리니치 표준시로 설정하는 TimeZoneName=GMT Standard Time 등이 있습니다. BDD를 사용한 배포에 사용할 수 있는 모든 속성은 technet.microsoft.com/library/bb490302.aspx의 구성 참조에 자세히 나와 있습니다.
BDD 2007 설치 및 사용에 대한 자세한 내용은 TechNet Magazine 2007년 9월호에서 "BDD 2007을 사용한 Windows Vista 배포"(technetmagazine.com/issues/2007/09/BDD) 기사를 참조하십시오.

BDD 및 SQL Server
왜 데이터베이스를 BDD 2007과 같이 사용할까요? 이 질문에 대한 답은 Lite Touch Installation 마법사를 통해 수동으로 입력해야 할 정보를 배포 시에 동적으로 제공하는 방법과 관련이 있습니다. 앞서 설명했듯이 이러한 정보는 CustomSettings.ini 파일을 사용하여 제공할 수 있습니다. 그런데 문제는 실제 배포 시나리오에서는 배포 대상 컴퓨터에 따라 이러한 정보가 달라진다는 것입니다. 게다가 500개의 서로 다른 컴퓨터에 대한 구체적인 옵션과 설정을 정의하려고 하면 CustomSettings.ini 파일이 금방 관리할 수 없을 만큼 커져버릴 수 있습니다. 그런데 BDD 콘솔에 백 엔드 데이터베이스를 연결하면 동적이고 확장 가능하면서 훨씬 관리하기 쉬운 솔루션을 추가할 수 있습니다.
SQL Server를 BDD 2007과 통합하는 방법에 대해 조금 더 알아봅시다. 먼저 SQL Server(SQL Server 2005 이상 권장)가 배포 서버에 설치되어 있는지 확인해야 합니다. 다행스럽게도 BDD 2007에 데이터베이스를 만드는 단계는 매우 간단합니다. 즉, BDD 2007 Deployment Workbench(배포 워크벤치)에서 Database(데이터베이스) 노드를 마우스 오른쪽 단추로 클릭하고 New(새로 만들기)를 클릭한 다음 화면의 지시에 따르기만 하면 됩니다(그림 2 참조). BDD 팀에서는 시작 및 실행을 빠르고 쉽게 수행할 수 있는 뛰어난 마법사를 개발했습니다.
그림 2 BDD 2007 배포 데이터베이스 구성
그림 2 BDD 2007 배포 데이터베이스 구성
데이터베이스를 만들었으므로, 이제 기능을 살펴볼 차례입니다. 데이터베이스의 항목은 Computer(컴퓨터), Role(역할), Location(위치) 및 Make and Model(제조업체 및 모델)이라는 네 가지 기본 범주로 분류됩니다. 각 범주별로 항목을 정의하고, 정의하는 각 항목에 대해 BDD 2007 변수로 채우고, 응용 프로그램을 할당하고, 기타 주요 설정을 구성할 수 있습니다(그림 3 참조).
그림 3 배포 속성 할당
그림 3 배포 속성 할당
이 네 가지 범주는 두 개의 그룹으로 살펴보는 것이 좋습니다. Computer(컴퓨터), Location(위치) 및 Make and Model(제조업체 및 모델) 범주는 각각 빌드 시에 컴퓨터를 식별하는 고유한 방법을 제공합니다. 식별된 각 컴퓨터는 데이터베이스에서 영업, 마케팅, 재무 등의 특정한 역할에 연결하여 특정 용도로 제공할 수 있습니다. 이때 각 역할별로 관련 기간 업무(LOB) 응용 프로그램이 설치되어 있어야 합니다.
Computer(컴퓨터) 구역을 통해서는 MAC 주소, 자산 태그, UUID(Universal Unique Identifier) 또는 일련 번호로 컴퓨터를 식별할 수 있습니다. 이 구역에서는 항목이 많이 생성될 수 있으므로 조직에서 컴퓨터별로 하나의 항목만 생성하고, ComputerName과 같은 고유한 속성만 각 항목에 추가해야 합니다.
Location(위치) 구역을 통해서는 조직과 관련 있는 특정한 지리적 위치별로 항목을 만들 수 있습니다. 각 항목은 해당 위치의 기본 게이트웨이로 식별됩니다. 이는 Active Directory®에 위치 기반 OU(조직 구성 단위)가 있고 특정 위치에 구축된 컴퓨터를 그 위치에 해당하는 OU의 도메인에 추가해야 하는 경우에 특히 유용합니다.
Make and Model(제조업체 및 모델) 구역을 통해서는 배포에서 지원해야 하는 하드웨어 종류별로 항목을 만들 수 있습니다. BDD 2007은 이 정보를 WMI 호출을 통해 검색된 정보와 비교합니다. 배포 환경에서 Make and Model(제조업체 및 모델) 구역은 Make and Model(제조업체 및 모델) 속성이 "Microsoft Corporation"인지 또는 "Virtual Machine"인지를 검사하여 컴퓨터가 Virtual PC 2007인지, Virtual Server 2005 가상 컴퓨터인지를 확인할 수 있는 항목을 만드는 데 일반적으로 사용됩니다. 빌드 시에 이러한 속성을 확인하는 경우 Make and Model(제조업체 및 모델) 항목에 가상 컴퓨터용 추가 프로그램을 추가하기만 하면 배포 시에 이러한 응용 프로그램을 설치하도록 BDD에 지시할 수 있습니다.
지금까지 컴퓨터 식별 방법을 살펴보았으므로 이제 Roles(역할) 구역을 사용하여 제공할 각 배포 역할별로 항목을 만들어 봅니다. 예를 들어 BDD에 정의된 Windows XP 또는 Windows Vista 빌드에 해당하는 BuildID 속성을 각 항목에 추가하여 Windows XP 역할 및 Windows Vista 역할에 대한 항목을 구성할 수 있습니다. 또한 회계, 영업 또는 재무와 같은 부서 역할을 지정할 수도 있습니다. 필자는 이 구역에 표준 시간대, 국가별 설정, 조직 정보 등 대부분의 BDD 속성을 채웁니다. 이렇게 하면 항목이 특정 컴퓨터, 하드웨어 또는 위치에 한정되지 않으므로 데이터베이스 관리 부담이 최소화됩니다.
배포 시에 데이터베이스에서 현재 빌드 중인 컴퓨터에 해당하는 항목이 있는지 검색하도록 BDD 2007에 지시해야 합니다. 배포 시에 데이터베이스를 사용하도록 BDD를 구성하려면 배포 지점을 마우스 오른쪽 단추로 클릭하고 Configure DB(DB 구성)를 클릭합니다. 그러면 Lite Touch Installation 프로세스에서 데이터베이스에 정보를 쿼리하도록 하는 항목을 CustomSettings.ini 파일에 채우는 일련의 마법사가 실행됩니다.

확장 가능한 배포 만들기
이제 Lite Touch Installation을 자동화하고 특정 업무 역할에 맞게 작동하도록 각 컴퓨터를 동적으로 제공할 수 있는 배포 서버가 준비되었습니다. 하지만 이 솔루션을 확장하려면 어떻게 해야 할까요?
솔루션의 아키텍처는 그림 4와 같이 허브 및 스포크 토폴로지를 기반으로 합니다. 설치하는 첫 번째 배포 서버가 허브인 동시에 부모 배포 서버가 되며 각 자식 배포 서버는 스포크 역할을 합니다.
그림 4 허브 및 스포크 배포 아키텍처
그림 4 허브 및 스포크 배포 아키텍처
이 아키텍처를 사용하려면 DFS-R을 이용하여 배포 공유를 각 배포 서버에 복제해야 합니다. 그런 다음 SQL Server 스냅숏 복제를 사용하여 BDD 배포 데이터베이스의 복사본을 각 자식 배포 서버에 제공합니다. 이 솔루션의 장점은 자식 배포 서버의 요구 사항이 최소화된다는 점입니다. 즉, 각 컴퓨터에 SQL Server Express, WDS 및 DFS-R만 설치되어 있으면 배포가 가능합니다.
BDD 2007 배포 공유에는 많은 양의 데이터가 저장될 수 있기 때문에 이전 버전의 Windows Server에서 제공되는 파일 복제 서비스 대신 Windows Server 2003 R2의 DFS-R을 사용하는 것이 좋습니다. DFS-R은 RDC(원격 차등 압축)를 사용하여 복제 그룹 구성원 파일 간의 차등(델타) 변경 내용만 복제합니다. 이는 새 드라이버와 같은 사소한 변경 내용이 사용자 지정 이미지 파일에 적용된 경우 복제 트래픽의 양에 큰 영향을 줄 수 있습니다. DFS-R을 사용하면 전체 이미지 파일을 다시 배포하는 대신 변경 내용의 크기에 해당하는 복제 트래픽만 발생합니다.
DFS와 관련한 정보는 Microsoft 웹 사이트에서 많이 볼 수 있지만(기본적인 정보의 예로 microsoft.com/windowsserver2003/technologies/storage/dfs를 들 수 있음) BDD 기반 배포와 관련한 프로세스의 개요를 살펴볼 수 있도록 기본 설치 및 구성 단계를 소개하도록 하겠습니다.
서버에서 R2 이전 버전의 Windows Server 2003 설치를 기반으로 하는 Active Directory를 실행하는 경우 복제 서비스에 새 개체 클래스가 필요하므로 DFS-R을 허용하려면 Active Directory 스키마를 업데이트해야 할 수 있습니다. Windows Server 2003 R2에서 Active Directory 스키마를 확장하는 데 대한 자세한 내용은 go.microsoft.com/fwlink/?LinkId=99936을 참조하십시오.
첫 번째 단계로 Windows Server 2003 R2 배포 서버에 DFS 구성 요소를 설치해야 합니다. 이 구성 요소는 여러 가지 방법으로 설치할 수 있습니다. 가장 간단한 방법으로는 Windows 구성 요소 추가/제거 마법사를 사용하는 방법이 있습니다. 설치가 끝나면 그림 5에 나와 있는 DFS Management(DFS 관리) 콘솔을 사용하여 복제 그룹을 설정해야 합니다.
그림 5 DFS 관리 콘솔
그림 5 DFS 관리 콘솔
BDD 2007 배포 솔루션을 확장하려면 폴더 두 개를 복제해야 합니다. 그 중 첫 번째는 BDD 원본 파일과 구성 파일이 모두 들어 있는 BDD 2007 배포 공유입니다. 이 폴더에 있는 파일은 각 배포 서버에 제공되어야 합니다.
복제할 두 번째 폴더는 WDS에서 LiteTouch_x86.wim 파일을 보관하는 데 사용하는 Boot 폴더입니다. 이 파일은 배포 프로세스를 시작하기 위해 WDS에서 데스크톱 클라이언트 컴퓨터로 전달하는 BDD 부팅 환경입니다. 이 파일을 복제하여 부모 배포 서버의 부팅 환경이 변경되면 나머지 배포 인프라에도 변경 내용이 복제되도록 해야 합니다.
복제할 경로는 X:\Distribution과 Y:\RemoteInstall\boot입니다. 여기서 X와 Y는 각각 BDD 2007 설치 시에 지정한 드라이브 문자와 WDS RemoteInstall 공유가 있는 볼륨의 드라이브 문자입니다.
DFS-R의 복제 기능은 다중 마스터 복제 모델을 따르기 때문에 단방향 복제 토폴로지는 만들 수 없습니다. 따라서 배포 공유를 중앙 집중식으로 관리하려면 각 자식 배포 서버의 Distribution 폴더를 읽기 전용으로 구성해야 합니다. 이렇게 하면 백업 및 복원 권한을 사용하는 DFS-R 복제 기능만 폴더에 쓸 수 있습니다. 이러한 자식 서버에서 빌드되는 클라이언트 컴퓨터는 이 폴더에 쓸 일이 없기 때문에 읽기 권한보다 높은 수준의 권한을 부여할 필요가 없습니다.
DFS-R을 사용하여 데이터를 복제하는 데 필요한 마지막 구성 단계는 WDS에서 BCD(부팅 구성 데이터) 저장소 새로 고침 정책을 설정하는 것입니다. 이렇게 하면 부팅 환경이 변경된 경우 각 자식 배포 서버에도 변경 내용이 반영됩니다. 이 구성 변경 설정은 모든 WDS 서버에 설정해야 하며, 배포 서버를 제공하는 빌드와 구성 프로세스에 이 설정을 포함하는 것이 좋습니다.
각 배포 서버에서 다음 명령을 실행합니다.
WDSUTIL /set-server /BCDRefreshPolicy /Enabled:yes /RefreshPeriod:<time in minutes>
새로 고침 간격은 배포 서버에서 얼마나 자주 데이터를 새로 고치는지에 따라 결정됩니다. 한 시간마다 복제하도록 DFS-R을 구성한 경우 60분마다 새로 고치도록 BCD 저장소 새로 고침 정책을 구성하는 것이 좋습니다.

SQL Server 복제
지금까지 주 배포 서버에서 각각의 자식 배포 서버로 BDD 배포 공유와 WDS 부팅 이미지를 복제하도록 BDD 2007을 확장해 보았습니다. 이제 프로세스를 완료하고 각 배포 서버에서 로컬로 사용할 수 있도록 BDD 2007 Deployment Workbench(배포 워크벤치) 데이터베이스를 복제해야 합니다.
SQL Server는 제품 설명서에서 설명하듯이 잡지 게시 방법과 유사한 복제 방식을 사용합니다. 잡지의 경우 잡지를 제작하는 게시자, 게시자를 대신해 잡지를 배포하는 배포자, 잡지를 구독하고 받아보는 구독자가 있습니다. SQL Server의 기본 제공 복제 기능에도 이와 동일한 용어가 사용됩니다.
SQL Server 데이터베이스 게시자가 되려면 서버에서 SQL Server Express Edition을 실행해서는 안 되며, 반드시 SQL Server의 정식 버전을 사용해야 합니다. 필자는 주 배포 서버에 SQL Server 2005(SQL Server 2000도 지원됨)를 사용합니다. 각 자식 배포 서버에는 SQL Server 2005 또는 SQL Server 2005 Express를 사용할 수 있습니다.
SQL Server 복제를 구성하기 전에 먼저 SQL Server가 복제를 지원하도록 올바르게 구성하는 데 필요한 몇 가지 단계를 수행해야 합니다. 배포 서버를 제공할 때에는 SQL Server 2005 또는 SQL Server 2005 Express Edition 설치 시 복제 구성 요소를 포함해야 합니다. 기본적으로 SQL Server Express는 복제 구성 요소를 설치하지 않습니다.
다음으로 Lite Touch 부팅 환경에서 SQL Server에 원격으로 연결할 수 있도록 하려면 SQL Server에서 원격 연결을 사용하도록 설정해야 합니다. 원격 연결이 가능하도록 SQL Server을 구성하려면 SQL Server 노출 영역 구성 도구를 시작하고, 서비스 및 연결에 대한 노출 영역 구성을 선택하고, TCP/IP 및 명명된 파이프로부터의 로컬 연결과 원격 연결을 모두 허용하도록 서버를 구성합니다.
그런 다음 주 배포 서버에서 각 자식 배포 서버의 복제 에이전트에서 읽을 복제 스냅숏 데이터를 보관할 공유 폴더를 만듭니다. 이 공유 폴더에 대해서는 나중에 설명하도록 하겠습니다. 필자는 이 폴더를 주로 나머지 배포 콘텐츠와 동일한 볼륨에 둡니다.
마지막 설치 단계는 자식 배포 서버에 SQL Server Express Edition이 설치된 경우에만 필요합니다. SQL Server Browser 서비스는 기본적으로 해제되어 있습니다. 복제를 허용하려면 이 서비스가 자동으로 시작되도록 설정해야 합니다. 이 서비스는 SQL Server 구성 관리자 도구를 사용하여 구성할 수 있습니다. 또한 자식 서버에 복제한 콘텐츠를 저장할 데이터베이스를 만들어야 합니다. 필요한 추가 구성 작업을 최소화하려면 이 데이터베이스의 이름을 주 배포 서버의 BDD 2007 데이터베이스 이름과 동일하게 유지해야 합니다.

복제 설정
이제 SQL Server 복제를 구성할 준비가 되었습니다. 먼저 SQL Server 2005의 정식 버전을 실행하는 마스터 배포 서버에서 SQL Server Management Studio를 시작합니다. 그리고 첫 단계로 배포를 만들고 구성합니다. 이 작업을 수행하려면 그림 6과 같이 관리 콘솔의 Replication(복제) 폴더로 이동합니다. Replication(복제) 폴더를 마우스 오른쪽 단추로 클릭하고 Configure Distribution(배포 구성)을 선택하여 배포 마법사를 시작합니다.
그림 6 SQL Server Management Studio: 복제
그림 6 SQL Server Management Studio: 복제
마법사에서 주 배포 서버가 자체 배포자 역할을 하도록 합니다. 루트 스냅숏 폴더를 앞서 만든 SQL Server 복제 공유의 UNC 경로로 설정합니다. 마지막으로 게시자로 구성되도록 주 배포 서버를 설정합니다.
이 마법사가 서버를 게시자 및 배포자로 구성하면 SQL Server에 게시할 데이터베이스를 알려야 합니다. 이를 위해서는 복제 폴더를 마우스 오른쪽 단추로 클릭하고 게시자 속성을 클릭합니다. 그림 7과 같이 속성 대화 상자에서 Publication Databases(게시 데이터베이스)를 선택하고 트랜잭션 복제에 사용할 BDD 2007 데이터베이스를 선택합니다. 지금은 사실 트랜잭션 복제를 사용하는 것이 아니지만 스냅숏 복제이든, 트랜잭션 복제이든지에 관계없이 같은 옵션을 선택합니다.
그림 7 데이터베이스 게시
그림 7 데이터베이스 게시
이제 자식 배포 서버가 구독할 수 있는 게시를 만들어야 합니다. 복제 폴더에서 로컬 게시를 마우스 오른쪽 단추로 클릭하고 새 게시를 클릭하여 게시 마법사를 시작합니다. BDD 데이터베이스를 게시할 데이터베이스로 선택합니다. 게시 유형으로 스냅숏 복제를 선택하고 모든 테이블, 저장 프로시저 및 보기를 복제하도록 지정합니다. 이때 초기 스냅숏이 즉시 생성되도록 선택해야 합니다. 스냅숏 에이전트 실행을 예약하는 경우 데이터베이스를 자주 변경하지 않는다면 기본적으로 하루에 한 번만 실행해도 충분합니다.
마지막 단계로, 각 자식 배포 서버가 이 게시를 구독하도록 해야 합니다. 이렇게 하면 SQL Server가 지정된 간격으로 데이터베이스의 복사본을 각 자식 배포 서버로 밀어넣게 됩니다. 복제 폴더의 로컬 게시 하위 폴더에서 방금 생성된 게시를 찾아 마우스 오른쪽 단추로 클릭한 다음 새 구독을 선택하여 구독 마법사를 시작합니다. 이 마법사에서 이전 단계에서 만든 BDD 게시를 선택합니다. 배포 시에 모든 에이전트를 실행하도록 선택하여 복제 토폴로지를 밀어넣기 구독으로 사용하도록 합니다. 그런 다음 각 자식 배포 서버를 구독자로 추가하고 각 서버에 만든 데이터베이스가 복제된 데이터의 복사본을 수신하도록 설정합니다. 이때 이 데이터베이스의 이름은 주 배포 데이터베이스의 이름과 동일하게 지정해야 합니다. 마지막으로 연결에 사용할 계정을 구성하고 복제 일정을 정의합니다. 이 일정은 스냅숏 에이전트에 대해 선택한 일정을 따라야 합니다. 지금까지 SQL Server 복제를 시작하고 실행하는 데 필요한 단계를 간단하게 살펴보았습니다. 이제 데이터가 너무나도 빠르게 복제되는 놀라운 경험을 직접 확인할 일만 남았습니다!

BDD 2007 구성
지금까지 데이터베이스를 사용하도록 BDD 2007을 구성하고 자식 배포 서버에 데이터베이스 복제와 BDD 2007 배포 공유를 설정했습니다. 이제 배포 솔루션을 완성하려면 클라이언트에서 BDD 부팅 환경을 다운로드할 때 로컬 배포 서버에 자동으로 연결하도록 BDD 2007을 구성해야 합니다.
Lite Touch Windows PE 환경에 부팅할 때 WDS 서버에서 클라이언트를 부팅한 경우 클라이언트에서 부팅 환경을 다운로드한 서버의 이름을 저장하는 레지스트리 값이 Windows PE에 설정됩니다. 초기 BDD 2007 배포 스크립트는 이 값을 가져와 %WDSServer%라는 환경 변수에 저장합니다.
초기 BDD 2007 릴리스를 사용하는 경우 Windows PE 레지스트리에 이 값이 올바르게 채워지지 않을 수 있습니다. 이러한 동작을 수정하는 업데이트는 support.microsoft.com/kb/937191에서 다운로드할 수 있습니다.
BDD 2007을 구성하려면 배포 서버에 대한 모든 참조가 %WDSServer%로 대체되도록 BootStrap.ini 및 CustomSettings.ini 구성 파일을 편집하기만 하면 됩니다. 일반적으로 이 과정에서는 SQL Server 인스턴스 이름의 값과 배포 공유를 저장하는 서버의 DeploymentRoot 값을 바꿉니다. 그림 8 및 그림 9에는 샘플 Bootstrap.ini 파일과 CustomSettings.ini 파일의 일부가 나와 있습니다.
Figure 9 CustomSettings.ini (Close Figure 9)
[Settings]
Priority=MMSettings, MMApps, CSettings, CRoles, RSettings, RApps, Default
Properties=Manufacturer

[Default]
OSInstall=Y
DeployRoot=\\%WDSServer%\Distribution$
UserDomain=BUILDLAB
UserID=BddAdmin
UserPassword=Password1234

[CSettings]
SQLServer=%WDSServer%
Database=BDD_DB1
Netlib=DBNMPNTW
Table=ComputerSettings
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR

[CRoles]
SQLServer=%WDSServer%
Database=BDD_DB1
Netlib=DBNMPNTW
Table=ComputerRoles
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
Figure 8 Bootstrap.ini (Close Figure 8)
[Settings]
Priority=Default

[Default]
DeployRoot=\\%WDSServer%\Distribution$
UserDomain=BUILDLAB
UserID=BddAdmin
UserPassword=Password1234
SkipBDDWelcome=YES
이 솔루션에서는 WDS가 BDD 2007에서 복제한 데이터베이스 및 배포 공유를 저장하는 동일한 서버에 설치되어야 합니다. 그 이유는 %WDSServer% 변수를 사용하여 클라이언트 컴퓨터에 로컬 배포 서버 위치를 알리고 컴퓨터가 WAN을 통해 다시 통신하지 않도록 간단한 안전 장치를 제공하기 위함입니다.

추가 고려 사항
BDD 2007의 가장 큰 장점은 확장이 가능하다는 점이므로, 이 솔루션을 확장하는 것과 관련하여 여러 가지 측면을 추가로 고려할 수 있습니다. 예를 들어 기본 제공 기능을 사용하여 SQL Server와 DFS-R을 모니터링하거나, 자산 관리 데이터베이스의 정보를 사용하여 환경 내 컴퓨터를 채우는 방법을 설계하거나, SQL 저장 프로시저를 사용하여 해당 정보를 검색할 수도 있습니다. 아쉽게도 지면이 부족하여 여기서 이 주제에 대해 다룰 수는 없지만 조직에서 BDD의 기능을 활용하는 방법에 대해 기본적인 개념을 파악하는 계기가 되었기를 바랍니다.

Adam Shepherd는 영국의 Microsoft Consulting Services에서 컨설턴트로 일하고 있습니다. Adam의 전문 기술 분야는 Windows 클라이언트의 배포, 유지 및 관리입니다. Adam에게 문의 사항이 있으면 adamshep@microsoft.com으로 연락하시기 바랍니다.


 Communications: Microsoft의 Exchange Edge 전송 서버: 2부
Communications Kay Unkroth

Microsoft의 Exchange Edge 전송 서버: 2부
한 눈에 보기:
  • Edge 전송 로그 및 추적 사용
  • 스크립트로 스팸 방지 구성
  • 일반적인 스팸 시나리오 테스트
이 기사의 코드 다운로드: Edge2007_11.exe (161KB)

인터넷을 통해 스팸과 기타 악의적인 콘텐츠가 대량으로 침투할 경우 조직 내의 사용자에게 안정적이고 안전한 메시징을 보장하려면 어떻게 해야 할까요? 지난달에 시작한 이 연재 기사의 1부에서 설명한 한 가지 방법으로
인터넷과 조직의 프로덕션 환경 사이에 있는 경계 네트워크에 Exchange Server 2007 Edge 전송 서버와 Forefront Security for Exchange Server를 배포하는 방법이 있습니다.
이 연재 기사 2부에서는 Exchange Server 2007의 표준 에이전트 로깅 및 추적 기능을 사용하여 작동 중인 Edge 전송 에이전트를 분석하는 방법을 설명합니다. 또한 사용자 지정 메서드를 사용하여 전송 파이프라인에서 XML 기반 파일로 모든 이벤트 개체를 덤프한 다음, Microsoft의 사내 프로덕션 환경에서 사용하는 구성에 따라 스팸 방지 설정을 Edge 전송 테스트 환경에 적용하는 방법에 대해 알아보겠습니다. 마지막으로 Edge 전송 에이전트가 다양한 스팸 상황에 대응하는 방법을 보여 주는 실제적이고 흥미로운 테스트 시나리오로 결론을 짓겠습니다.
Edge 전송 테스트 환경 설치와 일반 Edge 전송 아키텍처에 대한 자세한 내용은 TechNet Magazine 2007년 10월호에서 본 연재물의 1부(technetmagazine.com/issues/2007/10/Edge)를 참조하십시오.
필자는 스크립트와 배치 파일을 많이 사용하여 가장 중요한 구성 작업을 자동화하는데, 이러한 스크립트는 본 기사와 함께 제공되는 코드 다운로드(technetmagazine.com/code07.aspx 참조)에서 확인할 수 있습니다. 또한 Microsoft IT의 Edge 전송 에이전트 구성에 대한 자세한 배경 정보는 Microsoft IT Showcase용으로 작성된 기술 백서 "Microsoft® Exchange Server 2007 Edge 전송 및 메시징 보호"를 참조하십시오. 이 IT Showcase 백서는 microsoft.com/technet/itshowcase/content/edgetransport.mspx에서 다운로드할 수 있습니다.

로깅 및 추적
Exchange Server 2007에는 프로토콜 로깅, 에이전트 로깅, 파이프라인 추적을 포함하여 전송 에이전트 문제의 진단과 문제 해결을 돕는 다양한 로깅 및 추적 기능이 포함되어 있습니다. 이 기사가 전송 에이전트 문제를 해결하기 위한 것은 아니지만 로깅 및 추적 정보는 Edge 전송 에이전트의 작동 방식을 조사할 때 유용합니다.
SMTP 송수신 작업에 대한 정보를 추적하려면 송신 커넥터와 수신 커넥터에 프로토콜 로깅을 사용해야 합니다. 본 연재물의 1부에서 설정한 테스트 환경(그림 1 참조)을 사용하여 필자는 New-SendConnector 및 New-ReceiveConnector cmdlet에서 다음 설정을 통해 프로토콜 로깅을 사용하도록 구성했습니다.
그림 1 테스트 환경
그림 1 테스트 환경
–ProtocolLoggingLevel: Verbose
기본적으로 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog 아래의 하위 폴더에서 결과 SMTP 로그 파일을 찾을 수 있습니다.
프로토콜 로깅은 SMTP 대화를 분석하려는 경우에 유용하지만, 스팸 방지 에이전트가 항상 SMTP 세션을 방해하는 것은 아닙니다. 예를 들어 콘텐츠 필터 에이전트가 SCL(스팸 지수) 값으로 인바운드 메시지를 스탬프 처리만 할 수 있습니다. SCL 등급이 지정된 임계값(기본값: 7)보다 낮기만 하면 콘텐츠 필터 에이전트는 Edge 전송 프로세스가 메시지를 거부하도록 하지 않습니다. 따라서 SMTP 대화가 영향을 받지 않고 진행됩니다.
스팸 방지 에이전트(연결 필터, 콘텐츠 필터, Edge 규칙, 받는 사람 필터, 보낸 사람 필터, 보낸 사람 ID)가 전송 파이프라인을 통과하는 메시지에서 수행하는 작업을 분석하려면 프로토콜 로그 대신 에이전트 로그를 검사해야 합니다. 에이전트 로깅은 대개 EdgeTransport.exe.config 파일의 AgentLogEnabled 매개 변수에 따라 활성화됩니다. 기본적으로 에이전트 로그는 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\AgentLog 폴더에 있습니다. 이 로그는 메모장에서 열 수 있지만 Get-AgentLog cmdlet을 사용하면 Exchange 관리 셸에 더욱 알기 쉽게 에이전트 로그 정보가 표시됩니다.
또 다른 유용한 기능인 파이프라인 추적을 사용하면 특정한 보낸 사람이 보낸 메시지가 전송 파이프라인을 통과할 때 해당 메시지의 스냅숏을 캡처할 수 있습니다. 개념은 비교적 간단합니다. 즉, Edge 전송 프로세스는 OnEndOfHeaders, OnEndofData, OnSubmittedMessage 및 OnRoutedMessage 이벤트에 대해 등록된 SMTP 수신 및 라우팅 에이전트를 호출하기 전과 후에 각 메시지의 스냅숏을 만듭니다. 메시지 스냅숏을 비교하면 개별 에이전트가 각 메시지를 어떻게 수정하는지 알 수 있습니다. 물론 테스트 환경에서 이 중요한 기능을 사용하도록 설정해야 합니다.
다음과 같이 Set-TransportServer cmdlet을 사용하면 테스트 사용자의 파이프라인 추적이 활성화됩니다. 예상할 수 있겠지만 PipelineTracingEnable 매개 변수를 $true로 설정하면 파이프라인 추적이 사용됩니다. 테스트 사용자의 전자 메일 주소는 PipelineTracingSenderAddress 매개 변수에서 설정됩니다.
Set-TransportServer –Identity EDGE01
–PipelineTracingEnabled $true
-PipelineTracingSenderAddress Contoso.User@contoso.com
파이프라인 추적을 사용할 경우 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing\MessageSnapshots 폴더에서 지정된 보낸 사람(이 경우 Contoso.User@contoso.com)이 보낸 각 메시지의 메시지 스냅숏 파일을 찾을 수 있습니다. 이는 기본 폴더입니다. 각 메시지의 스냅숏 파일은 해당 메시지에 할당된 GUID에 따라 이름이 지정된 하위 디렉터리에 있습니다. 원본 메시지는 Original.eml이라는 파일에서 찾을 수 있고 메시지 복사본은 발생한 이벤트와 설치된 에이전트에 따라 SmtpReceive나 Routing으로 시작하는 .eml 파일에서 찾을 수 있습니다. SMTP 수신 이벤트 OnEndofData와 OnEndOfHeaders용으로 등록된 스팸 방지 에이전트의 처리를 분석하려면 SmtpReceive*.eml 파일을 검사합니다. 라우팅 이벤트 OnSubmittedMessage와 OnRoutedMessage용으로 등록된 바이러스 백신 및 기타 에이전트의 처리를 분석하려면 대신 Routing*.eml 파일을 분석합니다.

사용자 지정 파이프라인 덤프
Exchange Server 2007의 표준 에이전트 로깅 및 추적 기능이 모든 문제 해결 요구를 처리하지만 표준 기능이 모든 전송 이벤트를 다루지는 않습니다. 예를 들어 송신 호스트가 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing 폴더에 기록될 수 있는 메시지를 아직 전송하지 않았기 때문에 파이프라인 추적은 OnConnectEvent, OnEhloCommand, OnMailCommand, OnRcptCommand, OnDataCommand 및 이와 유사한 전송 이벤트에 대한 정보를 캡처할 수 없습니다. 이러한 이벤트에 대한 자세한 정보를 캡처하려면 이벤트 데이터를 파일 시스템의 파일로 덤프하는 사용자 지정 에이전트를 구현해야 합니다.
1부에서 설명한 바와 같이 사용자 지정 에이전트를 만드는 것은 복잡하지 않으므로 전송 파이프라인에서 XML 파일로 모든 이벤트 개체를 덤프하는 SMTP 수신 에이전트와 라우팅 에이전트를 만들 수 있습니다. 이 기사에서 제공하는 다운로드 파일에서 PipelineXMLDump라는 해당 Microsoft Visual Studio® 2005 프로젝트를 확인할 수 있습니다. 이 프로젝트에서 중요한 두 개의 파일에는 에이전트 팩터리 및 에이전트를 구현하는 DumpAgents.cs와 System.Reflection 메서드를 통해 이벤트 원본 및 이벤트 인수 개체의 필드를 XML 파일에 기록하는 도우미 클래스를 구현하는 XMLDump.cs가 있습니다. 소스 코드를 컴파일하고 결과 PipelineXMLDump.dll 파일을 Edge 전송 테스트 서버의 C:\PipelineXMLDump라는 폴더에 복사하면 RegisterPipelineXMLDump.ps1 및 EnableDumpAgents.ps1 스크립트를 사용하여 사용자 지정 에이전트를 등록하고 사용할 수 있습니다. 스크립트는 다운로드 파일의 PipelineXMLDump 프로젝트 폴더에 포함되어 있습니다. 물론 필자의 사용자 지정 에이전트는 설명 용도로만 만들어졌고 충분히 테스트되지 않았으며 프로덕션 서버에 설치하면 안 됩니다. 이러한 에이전트 사용 결과에 대한 모든 책임은 해당 사용자에게 있습니다.
DumpAgents.cs는 전송 파이프라인에서 지원하는 모든 SMTP 수신 및 라우팅 이벤트 처리기를 구현하는 방법을 보여 줍니다. 이 스크립트는 사용자 지정 에이전트를 직접 구현하려는 경우에 좋은 출발점이 될 수 있습니다. 필자의 덤프 에이전트는 SMTP 세션 식별자(SMTP 수신 에이전트)나 메시지 식별자(라우팅 에이전트)에 해당하는 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineXMLDump 아래의 하위 폴더에 XML 파일을 기록합니다. 그림 2에는 OnConnectEvent 처리기에서 SMTP 수신 에이전트에 전달된 이벤트 인수 정보를 보여 주는 예가 나와 있습니다. 이 예에서 받는 연결 요청을 수락한 로컬 IP 끝점(IP 주소 및 포트)을 알 수 있습니다.
그림 2 OnConnect 이벤트 중에 덤프된 인수 정보
그림 2 OnConnect 이벤트 중에 덤프된 인수 정보

테스트 실행 준비
로깅, 추적 및 덤프에 대한 이론을 충분히 살펴보았으므로 이제 스팸 방지 에이전트의 실제 작동을 보여 주는 몇 가지 테스트 실행을 준비해 보겠습니다. 다음은 Microsoft IT의 구성과 최대한 유사하게 사용자의 테스트 환경에서 구성하는 방법에 대한 간략한 설명입니다. 앞서 설명한 바와 같이 배경 정보는 기술 백서 "Microsoft Exchange Server 2007 Edge 전송 및 메시징 보호"에서 확인할 수 있습니다.
먼저, 함께 제공되는 다운로드 파일에서 EDGE01_disable_agents.ps1 스크립트를 실행하여 주소 다시 쓰기 인바운드 에이전트, 첨부 파일 필터 에이전트 및 주소 다시 쓰기 아웃바운드 에이전트를 비활성화합니다. 받는 사람이 내부와 외부에서 동일한 전자 메일 주소를 사용하기 때문에 주소 다시 쓰기는 필요 없습니다. Forefront Security에서 대체 첨부 파일 필터링 기능을 사용할 수 있으므로 필자는 첨부 파일 필터 에이전트를 사용하지 않습니다.
테스트 환경은 인터넷에 연결되어 있지 않으므로 연결 필터 에이전트를 테스트하기란 어렵습니다. 이 문제를 해결하기 위해 INTERNET01_create_IP_block_list.bat 파일을 실행하여 인터넷 호스트에 IP 차단 목록을 만들 수 있습니다. DNS 명령줄 도구(dnscmd.exe)가 포함된 Windows® 지원 도구를 설치해야 합니다. 그렇지 않으면 DNS 콘솔을 사용하여 수동으로 DNS 레코드를 만드느라 시간을 허비해야 합니다.
이제 EDGE01_add_block_list_provider.ps1 스크립트를 실행하여 연결 필터 에이전트를 구성할 수 있습니다. 이 스크립트는 ip-bl.consolidatedmessenger.com의 IP 차단 목록 공급자를 추가합니다. 이 목록은 앞서 언급한 바와 같이 인터넷 호스트에서 INTERNET01_create_IP_block_list.bat 파일을 실행하여 테스트 환경에 이미 만들어 놓은 통합 메신저의 IP 차단 목록입니다. Microsoft IT에서는 로컬 IP 차단 목록과 IP 허용 목록도 사용하지만 이들 기능에는 수동 구성이 필요하지 않습니다. Microsoft IT는 IP 허용 목록 공급자를 사용하지 않는다는 점을 알아야 합니다.
그런 다음 EDGE01_recipient_filter.ps1 스크립트를 실행하여 존재하지 않는 받는 사람에 대한 메시지 및 내부 또는 아웃바운드 전용 사서함과 전체 메일 그룹에 대한 메시지를 차단하도록 받는 사람 필터 에이전트를 구성합니다.
보낸 사람 필터 에이전트에도 구성 업데이트가 필요합니다. Microsoft IT에서는 보낸 사람 필터링을 특정 보낸 사람 주소에서 전송되는 메일 폭탄 공격에 대한 대응책으로 사용하고 업무와 관련이 없는 것으로 간주되는 특정 목록 서버와 유사 원본을 차단하는 용도로도 사용합니다. 또한 Microsoft IT에서는 보낸 사람 필터링을 사용하여 보낸 사람 정보가 잘못되었거나 누락된 메시지를 차단합니다. Edge 전송 서버에서 EDGE01_sender_filter.ps1 스크립트를 실행하여 이 구성을 테스트 환경에 적용해 보겠습니다.
Microsoft IT의 구성과 유사하게 구성하려는 경우에는 DNS에서 SPF(Sender Policy Framework) 레코드도 구성해야 합니다. adventure-works.com 도메인에서 보낸 메시지에 대해 Edge 전송 서버의 권한을 증명하는 SPF 레코드를 생성하기 위해 microsoft.com/mscorp/safety/content/technologies/senderid/wizard에서 제공하는 Microsoft Sender ID Framework SPF Record Wizard를 사용할 수 있습니다. 이 마법사를 사용하여 기존 인터넷 도메인 이름을 지정해 봅니다. 테스트 환경의 경우 인터넷 호스트에서 INTERNET01_create_SPF_record.bat 파일을 실행할 수 있습니다.
이제 다 되었습니다. 대부분의 에이전트가 적절한 기본값으로 설정되어 제공되기 때문에 추가로 구성해야 할 매개 변수는 없습니다. Edge 규칙, 보낸 사람 ID, 프로토콜 분석 및 콘텐츠 필터 에이전트의 가장 중요한 기본 설정을 빠르게 검사하려면 Edge 전송 서버에서 EDGE01_check_defaults.ps1 스크립트를 실행합니다.

Edge 전송 에이전트 실제 적용
이제 몇 가지 실제 메시징 시나리오에서 Edge 전송 에이전트를 실행해 보겠습니다. Edge 전송 서버에 테스트 메시지를 보내기 위해 필자는 Windows Server 2003에 포함된 SMTP 및 POP3 서비스를 사용했으며 Outlook® Express를 메시징 클라이언트로 사용했습니다. 이때 로깅을 사용하도록 설정한 것을 제외하고 다른 부분은 대부분 기본 설정을 사용합니다.
그러나 먼저 테스트 환경이 프로덕션 시스템이나 인터넷에 연결된 경우에는 이 섹션에 설명된 단계를 따르거나 이 섹션에 설명된 스크립트를 실행하지 마십시오. 테스트 결과에 대한 책임은 해당 사용자에게 있습니다.
가장 먼저 테스트할 에이전트는 연결 필터 에이전트입니다. 이 에이전트는 Edge 전송 서버에서 가장 많이 작동하는 에이전트이므로 맨 먼저 테스트할 가치가 있습니다. Microsoft에서 연결 필터 에이전트는 모든 인터넷 메시지 전송의 약 88%를 차단합니다. 업무일 기준으로 하루 1,300만 건의 전송 시도 중에서 합법적인 보낸 사람이 보낸 메시지는 약 150만 건입니다.
이제 Fabrikam.User@Fabrikam.com이라는 계정으로 Administrator@adventure-works.com에 전자 메일을 보내겠습니다. 제대로 작동할 경우 Administrator가 메시지를 수신하면 안 됩니다. 대신에 Fabrikam.User가 받는 사람에게 배달하지 못했다는 DSN(배달 상태 알림)을 수신해야 합니다. Fabrikam.User는 전자 메일 주소가 올바른지 확인하고 동일한 메시지를 다시 보내지만 이번에도 다시 DSN을 수신합니다. 그러자 Fabrikam.User는 지원 부서에 전화를 걸어 문제를 보고합니다. Fabrikam.User에게만 이 문제가 발생한 것은 아닙니다. 실제로 Fabrikam의 어떤 사용자도 Adventure Works와 더 이상 통신할 수 없습니다. 어떠한 문제가 발생한 것입니다. 긴급히 해결해야 할 문제입니다. 신속히 해결하기 위해 INTERNET01의 %systemroot%\system32\Logfiles\SMTPSVC1 폴더에서 SMTP 로그를 검사하면 그림 3에 빨간색 텍스트로 표시된 것처럼 문제를 확인할 수 있습니다.
Figure 3 문제를 보여 주는 SMTP 로그 (Close Figure 3)
... 220 mail.adventure-works.com Microsoft ESMTP MAIL Service ready at Thu,
31 May 2007 12:21:33 -0700,
... EHLO, -, INTERNET01,
... 250-mail.adventure-works.com Hello [192.168.1.100],
... MAIL, -, FROM:<Fabrikam.User@fabrikam.com> SIZE=840,
... 250 2.1.0 Sender OK,
... RCPT, -, TO:<Administrator@adventure-works.com>,
... 550 5.7.1 E-mail rejected because your IP address is listed by
ip-bl.consolidatedmessenger.com. Please visit
http://www.consolidatedmessenger.com/ip-bl for more information.
If you still need assistance, contact cmipbl@adventure-works.com.,
... RSET, -, -,
... 250 2.0.0 Resetting,
... QUIT, -, -,
... 221 2.0.0 Service closing transmission channel,
550 오류 응답은 통합 메신저가 사용자의 인터넷 호스트 IP 주소를 IP 차단 목록에 넣었다는 것을 나타냅니다. 이것만 해결하면 되겠네요. 통합 메신저의 차단 목록에서 해당 IP 주소가 제거되도록 하면 됩니다. 알다시피 통합 메신저의 차단 목록에 넣는 것이 이 목록에서 제거하는 것보다 쉽습니다. 이것을 정리하려면 몇 주는 아니더라도 며칠 정도 걸릴 것입니다.
더욱 신속한 도움이 필요하므로 전자 메일 주소 cmipbl@adventure-works.com을 통해 Adventure Works에 연락합니다. Fabrikam.Admin@Fabrikam.com 계정을 사용하여 상황을 설명하고 호스트 인터넷 IP 주소(이 경우 192.168.1.100)에 대한 차단을 해제해 달라고 요청하는 전자 메일을 보냅니다. 그러면 Adventure Works는 ID를 확인한 후 다음 명령을 사용하여 30일 후 자동으로 만료되는 임시 예외를 부여하여 주소 차단을 해제합니다.
Add-IPAllowListEntry -IPAddress 192.168.1.100
-ExpirationTime (get-date).AddDays(30)
30일이면 통합 메신저와의 설정을 정리하는 데 충분하므로 Adventure Works가 수동으로 예외를 유지 관리하느라 시간을 허비하지 않아도 됩니다. Adventure Works는 자동으로 만료되는 예외를 부여함으로써 IP 허용 목록을 유지 관리하는 것과 관련된 관리 오버헤드를 최소한으로 유지합니다.

수신 허용 - 보낸 사람
이제 스팸 필터링의 정확도를 높여 주는 흥미로운 새 기능인 콘텐츠 필터링의 수신 허용 - 보낸 사람 인식 기능을 테스트해 보겠습니다. EdgeSync는 해시되고 암호화된 형식으로 내부 환경에서 Edge 전송 서버로 수신 허용 - 보낸 사람 정보를 전달합니다. 콘텐츠 필터 에이전트는 필터링 과정에 이 정보를 사용하여 올바른 의사 결정을 내립니다. Update-SafeList cmdlet을 사용한 다음 Start-EdgeSynchronization cmdlet을 통해 정보를 Edge 전송 서버에 복제하여 수신 허용 - 보낸 사람 정보(즉, 수신 허용 - 보낸 사람 목록, 수신 허용 - 받는 사람 목록, 수신 거부 목록 및 외부 연락처)를 Active Directory®에 제공하기만 하면 됩니다. Microsoft IT에서는 사용량이 적은 시간에 정기적으로 Update-SafeList cmdlet을 실행합니다. 테스트 환경에서는 해당 스크립트(HUB-MBX-01_update_safelist.ps1)를 수동으로 실행하는 것으로 충분합니다.
먼저 Edge 전송 서버에서 EDGE01_clean_up.ps1 스크립트를 실행하여 앞서 만든 IP 허용 목록 항목을 제거하도록 테스트 환경을 정리합니다. 이 작업이 필요한 이유는 콘텐츠 필터 에이전트가 이 목록에 있는 원본에서 보낸 메시지에 대해 작동하지 않기 때문입니다. 그런 다음 인터넷 호스트에서 INTERNET01_clean_up.bat 파일을 실행하여 통합 메신저 차단 목록에서 100.1.168.192.ip-bl.consolidatedmessenger.com의 IP 차단 목록 항목을 제거합니다. 그렇지 않으면 앞서 설명한 바와 같이 시뮬레이션된 인터넷 호스트에서 메시지를 보낼 수 없게 됩니다.
마지막으로 콘텐츠 필터 에이전트가 스팸으로 간주할 가능성이 매우 높은 메시지를 보냅니다. 콘텐츠 필터 에이전트가 기본 SCL 거부 임계값을 통해 대부분의 메시지를 사용자에게 배달하여 가양성(False Positive)을 최소화하기 때문에 이렇게 하는 것은 쉽지 않습니다. 그러나 약간의 테스트를 수행한 후 필자는 SCL 등급을 거부 수준으로 올리는 메시지 버전을 하나 발견했습니다. Contoso.User@Contoso.com 계정을 사용하여 메시지를 보내려면 인터넷 호스트에서 INTERNET01_contoso_msg.vbs 스크립트를 실행합니다.
필자의 스크립트는 익명 SMTP 연결을 사용하여 메시지를 INTERNET01의 SMTP 서비스에 전송합니다. 이렇게 하려면 익명 사용자의 메시지를 릴레이하도록 SMTP 서비스를 구성해야 합니다. IIS 관리자에서 기본 SMTP 가상 서버의 속성을 엽니다. 액세스 탭에서 릴레이 단추를 클릭한 다음 아래 목록을 제외한 모든 항목을 선택합니다. 이 구성이 의미하는 것은 잠시 후 다루게 됩니다.
스크립트를 실행하여 이 메시지를 보내면 Contoso.User는 "Diagnostic-Code: smtp;550 5.7.1 Message rejected due to content restrictions(진단 코드: smtp;550 5.7.1 콘텐츠 제한으로 인해 메시지가 거부됨)"와 함께 배달하지 못했음을 알리는 DSN을 수신합니다. 인터넷 호스트의 SMTP 로그에서 이 응답을 볼 수도 있으며, Edge 전송 서버에서 Get-AgentLog | Select-Object -Last 1 명령을 실행하여 에이전트 로그의 마지막 항목을 표시하는 경우 그림 4와 같이 해당 SCL 등급이 7이기 때문에 메시지가 거부되었음을 알 수 있습니다.
그림 4 콘텐츠 제한으로 인해 메시지가 거부됨
그림 4 콘텐츠 제한으로 인해 메시지가 거부됨
이제 Contoso.User는 스패머가 아닙니다. 아쉽게도 이 경우에는 Contoso.User의 메시지가 통과하지 않았지만 일반적으로 Contoso.User는 Adventure Works에 있는 받는 사람과 통신할 수 있습니다. 따라서 Contoso.User는 Administrator에게 자신의 원본 메시지가 실수로 차단되었다고 또 다른 전자 메일을 통해 알립니다. Administrator는 Contoso.User를 알고 있으며 스팸 필터가 향후 더 이상 Contoso.User의 메시지를 차단하지 않도록 하기 위해 Contoso.User를 수신 허용 - 보낸 사람 목록에 추가합니다. Office Outlook 2007에서 이 작업을 수행하려면 Contoso.User로부터 수신된 메시지를 마우스 오른쪽 단추로 클릭하고 정크 메일을 가리킨 다음 수신 허용 - 보낸 사람 목록에 보낸 사람 추가를 클릭합니다.
이제 평상시 간격에 따라 Update-SafeList cmdlet이 실행되어 Active Directory의 수신 허용 목록 정보를 새로 고치며, 다음 Edge 동기화 후 Contoso.User는 가양성 없이 Administrator와 통신할 수 있습니다. 이 과정을 시뮬레이션하려면 HUB-MBX-01_update_safelist.ps1 스크립트를 실행합니다.
이제 INTERNET01_contoso_msg.vbs 스크립트를 실행하여 Contoso.User의 메시지를 다시 보냅니다. 나중에 Get-AgentLog | Select-Object -Last 1 명령을 사용하여 Edge 전송 서버의 에이전트 로그를 검사하면 ReasonData 아래에서 콘텐츠 필터링이 무시되었음을 알 수 있습니다. Contoso.User의 경우 더 이상 가양성이 나타나지 않습니다.

스팸 공격
테스트 실행을 마무리하기 위해 해외로 나가 보겠습니다. 이미 살펴봤듯이 필자는 이전 테스트를 실행하는 동안 인터넷 호스트를 오픈 릴레이로 구성했습니다. 따라서 스패머에게 문이 열립니다. 이제 Spam.Sender@cohovineyards.com이 이러한 취약한 구성을 알아채고 호스트를 악용하여 수천 건의 스팸 메시지를 Adventure Works에 보내면 어떻게 되는지 알아보겠습니다. INTERNET01_spam_msg.vbs 스크립트는 하나의 스팸 메시지만 전송하지만 이 스크립트를 편집하여 max_loop 값을 변경하면 더 많은 스팸 메시지를 생성할 수 있습니다.
스팸 공격을 시뮬레이션하기 위해 필자는 Edge 전송 서버로의 릴레이를 위한 1,000건의 메시지를 손상된 호스트에 전송했습니다. SMTP 서비스가 아웃바운드 연결당 메시지 수를 20개로 제한하므로 Edge 전송 서버의 프로토콜 분석 에이전트가 투입되기 전에 충분한 개수의 스팸 메시지를 릴레이하려면 약간의 시간이 걸립니다.
프로토콜 분석 에이전트는 SMTP 프로토콜 분석과 Microsoft Update의 IP 신뢰도 업데이트를 기반으로 IP 차단 목록 항목을 자동으로 유지 관리하여 연결 필터 에이전트를 지원합니다. 이 경우 SMTP 프로토콜 분석이 스팸 전자 메일 메시지를 발견했습니다. 프로토콜 분석 에이전트는 각 메시지의 SCL 등급을 계속 추적하여 SRL(보낸 사람 신뢰도 수준) 결정에 사용할 평균 SCL 값을 계산합니다. 시뮬레이션된 스팸 활동 기간 동안 전송되는 불법적인 메시지의 수가 점차 늘면서 인터넷 호스트의 SRL도 증가하고 결국 SRL 차단 임계값을 초과하게 됩니다. 따라서 호스트는 IP 차단 목록에 24시간 동안 유지되었습니다. 더 이상은 이 호스트에서 스팸이 수신되지 않습니다. 이것은 자동으로 수행되었으며 관리자의 작업이 필요하지 않았습니다.
그림 5에서는 결과 IP 차단 목록 항목과 메시지 처리의 해당 변경 내용을 보여 줍니다. Edge 전송 서버는 SCL 임계값(그림 4 참조)을 기반으로 각 메시지에 대해 작동하는 콘텐츠 필터 에이전트이기 때문에 호스트를 차단하기 전에 OnEndOfData 이벤트 동안 각 스팸 메시지를 거부했습니다. 메시지는 실패하기는 했지만 전송되었습니다. 호스트를 차단한 후 OnMailCommand 이벤트 동안 연결 필터 에이전트가 연결을 거부했습니다. 메시지는 더 이상 전송되지 않았습니다. 스패머가 메시지를 전송하기 전에 해당 연결이 끊겨서 네트워크 대역폭과 처리 리소스가 절약됩니다.
그림 5 공격하는 인터넷 호스트 중지
그림 5 공격하는 인터넷 호스트 중지

추가 테스트
물론 더 많은 에이전트 기능과 시나리오를 테스트할 수 있습니다. 예를 들어 Blocked.User@Contoso.com 또는 Blocked.User@Fabrikam.com 계정을 사용하여 메시지를 보내서 보낸 사람 필터링을 테스트할 수 있습니다. Blocked.User@adventure-works.com에게 메시지를 보내서 받는 사람 필터링을 테스트할 수 있습니다. 텔넷을 사용하여 타피팅 간격을 달리하면서 디렉터리 수집 공격을 시뮬레이션할 수도 있습니다. Microsoft IT에서는 5초의 기본 간격을 인터넷에 연결된 수신 커넥터의 SMTP 5yz 응답에 사용하는데, 이는 Microsoft IT가 스패머의 디렉터리 수집 공격을 무력화하기에 충분한 시간입니다. 그러나 EDGE01_tarpitting.ps1 스크립트에서 설명한 바와 같이 Set-ReceiveConnector cmdlet을 사용하여 다른 값을 적용할 수 있습니다.
더 자세히 들어가서 Contoso.User@Contoso.com에서 보낸 메시지에 대해 파이프라인 추적이 만드는 스냅숏 파일을 검사할 수도 있습니다. Forefront Security가 메시지를 검사한 것으로 표시하는 데 사용하는 바이러스 백신 스탬프인 X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0을 살펴봅니다. 허브 전송 서버의 Forefront Security가 최신 버전 정보가 있는 이 스탬프를 찾는 경우 메시지를 다시 검사하지 않아도 됩니다. 가짜 바이러스 백신 스탬프를 테스트 메시지에 삽입하여 Forefront Security를 속이려고 하면 실행되고 있는 헤더 방화벽이 이를 검색합니다. 이 헤더 방화벽은 FSE 라우팅 에이전트를 호출하는 OnSubmittedMessage 이벤트가 트리거되기 훨씬 전인 OnDataCommand 이벤트 직후에 이 스탬프를 제거합니다.
스냅숏 파일에서 메시지 헤더를 확인하는 동안 아마도 Contoso.com에 대해 잘못된 IP 주소를 합법적인 보낸 사람으로 식별하는 SPF 테스트 레코드를 만들 수도 있습니다. 이렇게 하는 방법 중 하나는 인터넷 호스트에서 INTERNET01_wrong_SPF_record.bat 파일을 실행하는 것입니다. 그런 다음 Contoso.User@Contoso.com 계정을 사용하여 테스트 메시지를 보내고 X-MS-Exchange-Organization-SenderIdResult 및 Received-SPF 헤더를 살펴보아야 합니다.
X-MS-Exchange-Organization-SenderIdResult: SoftFail
Received-SPF: SoftFail (EDGE01.extranet.adventure-works.com: domain of transitioning
Contoso.User@Contoso.com discourages use of 192.168.1.100 as permitted sender)

결론
본 연재물의 1부와 2부에서 살펴보았듯이 Exchange Server 2007 Edge 전송 서버는 연결 필터링, 프로토콜 분석 및 콘텐츠 필터링을 포함하여 안정적이고 정확도가 뛰어난 스팸 방지 기능을 구현하는 종합적인 전송 에이전트를 제공합니다. 전송 아키텍처는 확장이 가능하며 추가 기능을 위한 추가 에이전트 구현을 지원합니다. FSE 라우팅 에이전트는 Forefront Security for Exchange Server를 전송 아키텍처에 통합하는 추가 에이전트의 좋은 예가 됩니다.
연결 타피팅, 헤더 방화벽, TLS 및 인증과 같은 추가 기능을 사용하여 Edge 전송 서버는 여러 수준에서 단일 장애 지점 없이 매우 높은 수준으로 메시징을 보호하는 데 필요한 방법을 제공합니다. 내부 Exchange Server 조직과 엄격히 구분된 경계 네트워크에 Edge 전송 서버와 Forefront Security를 배포하여 악의적이고 합법적이지 않은 콘텐츠가 메시징 환경에 침투하지 못하게 하면서 합법적인 메시지는 매우 낮은 가양성 발생 비율로 사용자에게 전달할 수 있습니다.

Kay Unkroth는 15년 이상 Microsoft 서버 기술 분야에서 기술 지원 엔지니어, 시스템 개발자, 컨설턴트, 강사 및 저술가로 활동하고 있으며 문서화 및 지역화 관리 서비스를 전문적으로 제공하는 회사인 Biblioso Corporation의 공동 창업자이자 회장입니다.


 Networking: ISA Server 2006으로 VPN 원격 액세스 구성
Networking Alan Maddison

ISA Server 2006으로 VPN 원격 액세스 구성
한 눈에 보기:
  • VPN 프로토콜
  • 사이트 간 VPN 연결 구성
  • 원격 액세스 VPN 연결 구성
  • ISA Server 2006의 새로운 기능

VPN(가상 사설망)은 높은 수준의 적응성, 확장성 및 네트워크 연결 제어 성능을 제공하고 보안을 강화할 뿐 아니라 기존의 전용 지점 간 연결에 비해
상당한 비용 절감 효과를 가져올 수 있으며 융통성이 뛰어납니다.
VPN에는 여러 가지 유형이 있습니다. 그 중에는 모바일 사용자를 회사 네트워크에 연결하는 데 사용되는 것도 있고 지리적으로 분산된 두 네트워크를 연결하는 데 사용되는 것도 있습니다. 이러한 VPN마다 사용하는 프로토콜과 제공하는 기능이 다릅니다. 인증 및 암호화와 같은 보안 기능을 제공하는 것도 있고 기본 제공 보안 기능을 전혀 제공하지 않는 것도 있으며 다른 유형에 비해 설정과 관리가 훨씬 쉬운 VPN도 있습니다.
이 기사에서는 Internet Security and Acceleration(ISA) Server 2006을 사용하여 VPN을 구현하는 방법을 살펴보겠습니다. 특히 ISA VPN 기능을 사용자에게 VPN 원격 액세스 연결을 제공하는 수단으로 사용하는 경우와 사이트 간 VPN 연결을 제공하는 수단으로 사용하는 경우, 이 두 가지 일반 시나리오를 중점적으로 다룹니다. 두 가지 구현 모두에 데이터 정보 보호를 보장하고 내부 네트워크 리소스를 보호하기 위한 보안 기능이 포함됩니다.
첫 번째 시나리오인 원격 액세스 VPN 연결에서는 원격 클라이언트가 인터넷을 통해 ISA Server에 대한 VPN 연결을 시작합니다. 그러면 ISA Server가 원격 클라이언트를 내부 네트워크에 연결하여 사용자에게 데이터와 응용 프로그램을 포함한 내부 네트워크 리소스에 대한 원활한 액세스를 제공합니다. 두 번째 시나리오인 사이트 간 VPN 연결은 ISA 자체가 될 수도 있는 라우터를 사용하기 때문에 약간 더 복잡합니다. 그러나 이 연결 유형을 사용하면 다른 사무실 또는 지사를 서로 원활히 연결하거나 본사에 연결할 수 있습니다.
ISA Server 2006을 사용하여 VPN을 구현하면 여러 가지 이점을 추가로 얻을 수 있습니다. 가장 중요한 이점 중 하나는 ISA Server의 통합 특성에 기인합니다. 즉, VPN 기능과 방화벽 기능이 서로 유기적으로 작동합니다. 또한 ISA Server는 서버 쪽 스크립트에 의해 구성이 검증될 때까지 Windows Server® 2003의 네트워크 액세스 격리 제어 기능을 이용하여 원격 액세스 컴퓨터를 격리하는 VPN 격리 기능을 제공합니다. 이 기능은 내부 네트워크 리소스에 대한 액세스를 허용하기 전에 원격 컴퓨터에서 바이러스 백신 정의 상태, 로컬 방화벽 정책 등을 검사할 수 있는 수단을 제공하여 보호 수준을 높입니다.
ISA Server가 VPN 솔루션으로서 제공하는 주된 관리 이점에는 정책 중앙 관리, 모니터링, 로깅, 보고 등이 있습니다. 일상적인 관리 작업에 있어서 이러한 기능의 가치는 헤아릴 수 없습니다. 특히 실시간 모니터링 및 로그 필터링 기능을 사용하면 ISA Server를 통과하는 네트워크 트래픽과 연결에 대한 주요 정보를 파악할 수 있습니다.

VPN 프로토콜
ISA VPN 연결에 사용되는 핵심 터널링 프로토콜은 제일선에서 연결 보안을 제공합니다. ISA Server는 IPsec을 통한 L2TP(Layer 2 Tunneling Protocol), PPTP(Point-to-Point Tunneling Protocol), IPsec 터널 모드의 세 가지 프로토콜을 지원합니다. 이 중 IPsec 터널 모드는 사이트 간 연결에 대해서만 지원되며 주로 L2TP나 PPTP를 지원하지 않는 다른 운영 체제 및 라우터와의 상호 운용성을 위해 사용됩니다.
L2TP는 데이터 정보 보호 기능을 제공하는 자체 메커니즘이 없기 때문에 IPsec과 짝을 이루어 사용됩니다. L2TP를 강력한 인증 및 암호화 방식을 제공하는 IPsec과 함께 사용했을 때, 강력한 솔루션이 구현됩니다. PPTP는 MS CHAP(Microsoft® Challenge Handshake Authentication Protocol) 버전 2나 EAP-TLS(Extensible Authentication Protocol-Transport Layer Security)를 인증에, MPPE(Microsoft Point-to-Point Encryption)를 암호화에 사용합니다.
조직에서 IPsec을 통한 L2TP와 PPTP 중 어떤 프로토콜을 선택할지는 해당 조직 고유의 요인에 따라 결정되곤 합니다. IPsec을 통한 L2TP를 사용하면 보다 복잡하고 정교한 암호화 방식을 사용할 수 있을 뿐만 아니라, 더 많은 유형의 네트워크(IP, X.25, 프레임 릴레이, ATM 등)가 지원됩니다. 하지만 PPTP는 구현하기가 더 쉽고 대개 요구 사항이 더 적습니다. 즉, 조직에서 적용하는 제약 조건이 없을 경우 통상 IPsec을 통한 L2TP를 구현하는 것이 최선의 방법이라 할 수 있습니다.

사이트 간 VPN 연결
ISA Server 2006에서는 사이트 간 VPN 설정을 단순화하는 데 있어 상당한 진전을 이루었습니다. 이전 버전에서는 사이트 간 VPN 설정이 훨씬 많은 단계로 이루어졌습니다. 이에 대한 예로, IPsec을 통한 L2TP를 사용하여 본사에 연결하는 단일 원격 사이트에 대해 설명하도록 하겠습니다. 이 예에서는 두 위치 모두에서 ISA Server를 사용합니다. 이 프로세스를 진행하려면 원격 사이트를 구성하기 전에 본사 ISA Server를 구성해야 합니다.
첫 단계로, 두 ISA Server 모두에 필요한 로컬 사용자 계정을 구성해야 합니다. 이 사용자 ID는 원격 또는 주 ISA Server에 연결할 수 있도록 보안 컨텍스트를 제공합니다. 이 계정의 이름은 ISA 관리 콘솔에서 만드는 VPN 연결의 이름과 일치해야 합니다. 예를 들어 본사의 ISA Server에는 원격 사이트를 가리키는 사용자 이름 "Site VPN"을 설정하고, 원격 ISA Server에는 "HQ VPN"을 설정하는 명명 규칙을 사용하는 것이 좋습니다. 이러한 계정을 만들었으면 계정 속성에 액세스하고 전화 접속 탭을 연 다음 액세스 허용 옵션이 선택되었는지 확인해야 합니다.
로컬 사용자 계정을 만든 후에는 다음 단계로 두 사이트 간 인증에 사용할 PKI(공개 키 인프라) 인증서를 만들어야 합니다. 미리 공유한 키를 사용하는 옵션이 제공되지만 인증서를 사용하는 방법이 항상 더 바람직합니다. VPN 연결용 인증서를 설치하는 가장 간단한 방법은 조직의 고유한 엔터프라이즈 인증 기관에 직접 연결하여 인증서 서버의 웹 사이트를 통해 인증서를 요청하는 것입니다. 그러나 이렇게 하려면 ISA Server가 HTTP를 통해 인증서 서버에 연결할 수 있도록 하는 액세스 규칙을 만들어야 합니다.
이전 버전의 ISA Server에 익숙하다면 그림 1에 나와 있는 ISA Server 2006 인터페이스가 훨씬 더 직관적일 것입니다. 왼쪽 창에서 VPN을 선택하면 상황에 맞는 구성 및 작업 옵션이 가운데 창과 오른쪽 창에 표시됩니다.
그림 1 보다 직관적인 인터페이스를 제공하는 ISA Server 2006
그림 1 보다 직관적인 인터페이스를 제공하는 ISA Server 2006
오른쪽 창에서 사이트 간 VPN 연결 만들기 작업을 클릭하면 사이트 간 VPN 연결 만들기 마법사가 시작됩니다. 마법사가 시작되면 사이트 간 네트워크 이름을 입력해야 하는데, 이 이름은 앞서 만든 사용자 계정의 이름과 일치해야 합니다. 이름을 입력한 후 다음 단추를 누릅니다. 다음 화면(그림 2 참조)에서 사용할 VPN 프로토콜을 선택합니다. 이 예의 경우 IPsec을 통한 L2TP를 선택했습니다. 다음을 누르면 네트워크 이름과 일치하는 사용자 계정을 제공해야 한다는 경고가 표시됩니다. 이 예의 경우 그냥 확인을 눌러 다음 화면으로 이동하면 됩니다.
그림 2 사용할 VPN 프로토콜 선택
그림 2 사용할 VPN 프로토콜 선택
이제 IP 주소 풀을 만들어야 합니다. 두 가지 옵션 중 하나를 선택할 수 있습니다. 즉, ISA Server에 고정 주소 풀을 만들 수도 있고 기존 DHCP 서버를 사용하여 주소 할당을 처리할 수도 있습니다. 두 가지 방법 모두 가능하므로 이 옵션과 관련한 회사의 절차에 따라 결정해야 합니다. 이제 화면에 원격 서버 이름을 입력해야 합니다. 원격 서버의 FQDN(정규화된 도메인 이름)을 입력한 다음 연결에 사용할 사용자 자격 증명을 입력합니다. 이때 원격 ISA Server에서 만든 사용자 계정 이름을 입력해야 한다는 사실을 잊지 마십시오. 이 예의 경우 그림 3과 같이 사용자 계정 HQ VPN을 입력하면 됩니다.
그림 3 원격 서버의 FQDN 입력
그림 3 원격 서버의 FQDN 입력
다음 화면에서 나가는 인증 방법을 선택합니다. 앞서 설명한 바와 같이 인증서를 사용하는 것이 항상 더 바람직합니다. 다음으로, 원격 사이트의 내부 네트워크에 사용하고 있는 IP 주소 범위를 입력합니다.
ISA Server 2006 Enterprise Edition을 사용하고 있으면 마법사의 다음 단계에서 원격 사이트의 네트워크 부하 분산 전용 IP 주소를 구성할 수 있습니다. ISA Server 2006 Standard Edition을 사용하고 있으면 부하 분산 단계를 생략하고 다음 화면(그림 4 참조)으로 곧장 이동합니다. 이 화면에서는 원격 사이트에서 로컬 네트워크로 트래픽을 라우팅하는 데 사용되는 네트워크 규칙을 만들 수 있습니다.
그림 4 트래픽을 라우팅하는 네트워크 규칙 만들기
그림 4 트래픽을 라우팅하는 네트워크 규칙 만들기
프로세스의 다음 단계로 액세스 규칙도 만들어야 합니다. 액세스 규칙을 구성할 때에는 프로토콜을 사용할 수 있도록 허용하는 세 가지 옵션이 제공됩니다. 즉, 모든 아웃바운드 트래픽을 허용할지, 특정 프로토콜을 제외한 모든 아웃바운드 트래픽을 허용할지, 아니면 특정 프로토콜만 허용할지를 선택할 수 있습니다. 대부분의 경우 모든 아웃바운드 트래픽을 허용하는 옵션을 선택해야 합니다.
이제 거의 마쳤습니다. 이 시점에서 구성 요약이 제공되고 마침 단추를 누를 경우 사이트 간 VPN 연결이 생성됩니다. 인증서 해지 목록 다운로드를 위해서는 시스템 정책 규칙을 사용해야 한다는 대화 상자가 나타나면 예를 눌러 이 규칙을 사용하도록 설정합니다. 추가로 필요한 구성 단계가 있을 경우 해당 단계에 대한 정보가 제공됩니다. 주 사이트의 ISA Server 구성을 완료한 후에는 동일한 단계에 따라 원격 사이트를 구성해야 합니다. 두 원격 사이트 구성 프로세스가 모두 완료되면 두 사이트의 사용자가 VPN을 통해 통신할 수 있습니다.

원격 액세스 VPN 연결
클라이언트 액세스용으로 원격 액세스 VPN 연결을 구성하는 방법은 훨씬 쉽습니다(그림 5 참조). 첫 단계로, ISA Server 관리 콘솔의 왼쪽 창에서 VPN을 선택합니다. 그런 다음 오른쪽 창에서 VPN 클라이언트 액세스 사용 작업을 선택하면 라우팅 및 원격 액세스 서비스가 다시 시작될 수 있다는 경고가 나타납니다. 연결 문제가 초래될 수 있으므로 예약된 유지 관리 기간 동안 이 변경 내용을 구현해야 합니다. 확인을 클릭하여 이 경고를 닫습니다. 그러면 VPN 클라이언트 트래픽이 ISA Server에 액세스할 수 있도록 하는 시스템 정책이 설정됩니다. ISA Server 관리 콘솔에서 방화벽 정책을 선택한 다음 시스템 정책 규칙 표시 작업을 선택하여 이 규칙을 확인할 수 있습니다.
그림 5 원격 액세스 VPN 연결 구성
그림 5 원격 액세스 VPN 연결 구성
내부 네트워크와 두 VPN 네트워크(VPN 클라이언트 및 격리된 VPN 클라이언트) 간의 라우팅을 허용하는 기본 네트워크 규칙도 사용됩니다. 왼쪽 창에서 네트워크를 선택한 다음 가운데 창에서 네트워크 규칙 탭을 열어 이 네트워크 규칙을 보거나 편집할 수 있습니다.
이제 VPN 클라이언트 액세스를 구성해야 합니다. 이때에는 액세스가 허용되는 Windows 보안 그룹, 클라이언트가 사용할 수 있는 프로토콜, 사용자 매핑의 세 가지 매개 변수를 구성해야 합니다. 이러한 매개 변수를 구성하기 위한 대화 상자가 그림 6에 나와 있습니다.
그림 6 VPN 클라이언트 액세스 구성
그림 6 VPN 클라이언트 액세스 구성
그룹 탭에서는 VPN을 통한 원격 액세스가 허용되는 Windows 그룹을 선택하면 됩니다. 관리자 입장에서 보면 사용 권한이 주어져 있는 단일 그룹을 만드는 것이 좋습니다. 이렇게 하면 원격 액세스를 매우 쉽게 관리할 수 있습니다.
프로토콜 탭에는 기본적으로 PPTP만 사용하도록 설정되어 있습니다. 환경에서 사용 가능하다면 당연히 IPsec을 통한 L2TP를 사용하도록 설정해야 합니다.
사용자 매핑을 통해 RADIUS(Remote Authentication Dial-In User Service)와 같은 네임스페이스의 사용자 계정을 Windows 계정에 매핑하여 액세스 정책이 올바르게 적용되도록 할 수 있습니다. 구성 옵션을 완료하고 변경 내용을 ISA Server에 적용했으면 프로세스를 마친 것입니다. 이제 클라이언트가 VPN 연결을 사용하여 내부 네트워크 데이터와 응용 프로그램에 원활히 액세스할 수 있습니다.

ISA Server 2006의 향상된 기능
ISA Server 2006은 이전 버전보다 높은 성능을 제공하도록 많은 기능이 향상되었습니다. HTTP 압축, BITS(Background Intelligent Transfer Service) 지원, QoS(서비스 품질) 등의 향상된 기능을 통해 제공되는 다양한 기법을 활용하여 네트워크 사용량을 최적화할 수 있습니다. 물론 이러한 기법을 사용하는 경우에도 ISA Server의 핵심 기술인 일반 대역폭 최적화 기술(예: 캐싱)은 계속 사용해야 합니다.
HTTP 압축 기능은 다양한 Microsoft 제품에서 지원되어 왔습니다. 구체적으로는 Internet Explorer®에서는 버전 4부터, 그리고 Windows Server에서는 Windows® 2000부터 지원되고 있습니다. 하지만 HTTP 압축과 업계 표준 GZIP 및 Deflate 알고리즘을 지원하는 ISA Server는 이 버전이 처음입니다.
이는 어떤 의미가 있을까요? HTTP 압축에 대한 지원 덕분에 HTTP 1.1과 호환되는 웹 브라우저가 모든 웹 사이트에서 압축된 콘텐츠를 요청할 수 있습니다. 그러나 응답만 압축될 뿐, 클라이언트에서 나가는 초기 연결은 압축되지 않습니다.
특정 네트워크 규칙과 연결된 것과는 반대로 HTTP 압축은 ISA Server를 통과하는 모든 HTTP 트래픽에 적용되는 글로벌 HTTP 정책 설정입니다. 하지만 수신기별로 HTTP 압축을 구현하는 옵션이 제공되는데, 이는 웹 수신기 마법사를 통해 구성됩니다.
왼쪽 창의 일반 옵션을 통해 액세스할 수 있는 HTTP 압축은 기본적으로 사용됩니다. 그러나 그림 7과 같이 압축을 사용할 네트워크 요소를 구성해야 합니다. 사이트 간 VPN 예제의 경우 압축된 데이터 반환 탭을 선택하고 앞서 만든 Site VPN이라는 네트워크 요소를 선택해야 합니다. 이때 압축할 콘텐츠 형식을 구성하는 옵션도 제공됩니다. ISA Server 2006에는 표준 콘텐츠 형식 목록이 포함되어 있지만, 도구 상자 탭의 방화벽 정책 작업창을 통해 사용자 지정 콘텐츠 형식을 추가할 수도 있습니다. 압축된 데이터 반환 탭은 클라이언트에 데이터를 반환되기 전에 ISA Server가 해당 데이터를 압축하도록 하는 것과 관련이 있습니다. 데이터를 ISA Server에 보내기 전에 웹 서버가 데이터 압축을 처리하도록 요청하려면 압축된 데이터 요청 탭을 사용해야 합니다.
그림 7 HTTP 압축 구성
그림 7 HTTP 압축 구성
BITS(Background Intelligent Transfer System)는 HTTP 및 HTTPS 트래픽의 비동기 파일 전송 서비스입니다. Windows Server 2003에는 다운로드와 업로드를 지원하는 BITS 버전 1.5가 포함되어 있지만 업로드를 사용하려면 IIS(인터넷 정보 서비스) 버전 5.0 이상도 필요합니다. 지능형 파일 전송 서비스로서 BITS에는 네트워크 트래픽을 조사하여 네트워크 대역폭의 유휴 부분만 사용하는 기능이 있습니다. 또한 파일 전송이 동적으로 이루어지고, 네트워크 사용량을 제한하여 일반 네트워크 트래픽의 급격한 상승에 대응합니다. 여기서 얻을 수 있는 이점은 큰 파일의 다운로드 및 업로드 작업이 다른 네트워크 사용 작업에 부정적인 영향을 미치지 않도록 BITS가 제어한다는 점입니다. 관리자 입장에서 보면 열악한 네트워크 성능에 대해 전화로 불만을 토로하는 사용자가 줄어든다는 점에서 매우 바람직합니다.
BITS는 사용자 환경을 개선하고 네트워크 성능을 높이는 데 도움이 되는 다른 이점도 제공합니다. 예를 들어 BITS를 사용한 파일 전송은 이진 방식이므로 BITS는 네트워크 중단 등으로 인해 중단된 파일 전송을 처음부터 새로 시작하지 않고 이어서 다시 시작할 수 있습니다. ISA Server 2006은 BITS 캐싱을 이용하여 업데이트를 최적화하는 Microsoft Update 캐싱 기능을 기본 지원합니다.
DiffServ(Differentiated Services) 프로토콜을 사용하면 HTTP 및 HTTPS 트래픽에 대해 패킷 우선 순위를 지정(또는 QoS)할 수 있습니다. 즉, ISA Server 구성에 따라 특정 트래픽이 우선 처리됩니다. 이 기능은 트래픽 양이나 네트워크 연결 속도로 인해 대역폭이 제한된 네트워크에 유용합니다. IETF(Internet Engineering Task Force)는 DiffServ를 클래스 기반 트래픽 관리 메커니즘으로 정의하고 있습니다. 즉, DiffServ는 트래픽 유형을 구별하고 그에 따라 관리하여 우선 순위가 높은 트래픽이 먼저 처리되도록 할 수 있습니다.
이 기능을 제공하기 위해 ISA Server는 QoS를 지원하는 라우터와 함께 작동합니다. 동일한 우선 순위에 따라 패킷을 라우팅하려면 ISA Server DiffServ 비트가 라우터의 우선 순위와 일치하는지 확인해야 합니다.
ISA Server에서 이러한 유형의 패킷 우선 순위는 글로벌 HTTP 정책 설정으로 구현되며, DiffServ 웹 필터를 사용하여 ISA Server 2006을 통과하는 모든 HTTP 트래픽에 적용됩니다. 즉, ISA Server는 다른 프로토콜에 대해 DiffServ를 지원하지 않으며 실제로 HTTP 트래픽이 아닌 트래픽에서 기존 DiffServ 비트를 삭제할 수 있습니다.
그림 8과 같이 DiffServ는 웹 필터로 구현되며 왼쪽 창에서 추가 기능을 선택하여 액세스할 수 있습니다. 처리 시 ISA Server가 요청/응답 크기를 검사해야 하므로 DiffServ 필터의 우선 순위나 기본 설정을 변경하지 않는 것이 중요합니다.
그림 8 DiffServ 웹 필터 보기
그림 8 DiffServ 웹 필터 보기
그림 8을 자세히 살펴보면 DiffServ 필터가 기본적으로 사용되지 않는다는 것을 알 수 있습니다. 이 필터를 사용하려면 작업 창에서 선택한 필터 사용을 선택한 다음 필터를 구성하면 됩니다. ISA Server의 DiffServ 패킷 우선 순위는 특정 URL이나 도메인을 기준으로 하기 때문에 이 정보를 DiffServ 기본 설정에 추가해야 합니다. 이렇게 하려면 관리 콘솔의 왼쪽 창에서 일반을 선택한 다음 글로벌 HTTP 정책 설정에서 DiffServ 기본 설정 지정을 선택합니다. 기본 설정을 지정할 때는 우선 순위를 지정할 URL 및 도메인, 그리고 우선 순위를 정의해야 합니다. ISA Server 2006은 VPN 클라이언트의 원격 액세스를 설정하거나 사이트 간 VPN을 만드는 데 사용할 수 있는 강력한 새 기능을 제공하는 솔루션으로, 구현할 VPN 솔루션을 결정할 때 최우선으로 고려하기에 손색이 없습니다.

Alan Maddison은 MTI Technology Corporation의 Microsoft 기술 담당 수석 컨설턴트로, Active Directory, Exchange Server 및 가상화 관련 업무를 중점적으로 수행하고 있습니다.


 SQL Server: SQL Server 쿼리 성능 최적화
SQL Server Maciej Pilecki

SQL Server 쿼리 성능 최적화
한 눈에 보기:
  • 실행 계획의 분석
  • 쿼리 최적화
  • 튜닝할 쿼리 식별

데이터베이스 서버를 최적화할 때는 개별 쿼리의 성능을 튜닝해야 합니다. 이것은 하드웨어 및 소프트웨어 구성처럼 성능에 영향을 미치는 서버의 여타 다른 측면을 튜닝하는 것만큼, 나아가 오히려 그보다 더 중요할 수 있습니다.
데이터베이스 서버의 하드웨어가 가장 강력한 것이라 해도, 아주 약간의 쿼리가 잘못 동작하는 것만으로 성능에 부정적 영향이 야기될 수 있습니다. 실제로, 잘못된 쿼리 또는 일명 '제어 불능 쿼리' 하나로도 데이터베이스에 심각한 성능 문제를 야기할 수 있습니다.
역으로, 비용이 가장 높거나 가장 자주 실행되는 쿼리 집합을 튜닝하는 것으로도 데이터베이스의 전반적 성능이 크게 향상될 수 있습니다. 이 글에서는 서버에서 비용이 가능 높고 가장 성능이 나쁜 쿼리를 식별, 튜닝할 때 활용할 수 있는 몇 가지 기법을 살펴보겠습니다.

실행 계획의 분석
개별 쿼리를 튜닝할 때는 일반적으로 그 쿼리의 실행 계획을 살펴보는 것부터 시작합니다. 실행 계획에는 SQL ServerTM에서 쿼리를 실행하여 원하는 결과 집합을 산출하기 위해 수행할 물리적, 논리적 연산의 순서가 기술됩니다. 실행 계획은 쿼리 처리의 최적화 단계에서 쿼리 최적화 프로그램이라는 데이터베이스 엔진 구성 요소에 의해 만들어지며, 이 작업에는 쿼리에 사용되는 검색 조건자, 관련된 테이블과 해당 조인 조건, 반환된 열의 목록, 데이터에 대한 효율적인 액세스 경로의 역할을 할 수 있는 유용한 인덱스의 존재 등 다양한 요소가 고려됩니다.
복잡한 쿼리의 경우, 모든 가능한 순열의 수가 매우 클 수 있으므로 쿼리 최적화 프로그램은 모든 가능성을 평가하지 않고 주어진 쿼리에 '충분한' 계획을 찾게 됩니다. 이것은 완벽한 계획을 찾는 것이 항상 가능하지는 않기 때문이며, 그것이 가능하더라도 완벽한 계획을 찾기 위해 모든 가능성을 평가하는 데 따르는 비용이 그로 인한 성능상의 이득을 쉽게 상회할 정도로 크기 때문입니다. DBA의 관점에서 볼 때, 프로세스와 한계를 이해하는 것이 중요합니다.
쿼리의 실행 계획을 검색하는 방법은 여러 가지가 있습니다.
  • Management Studio에서 제공하는 실제 실행 계획 표시 및 예상 실행 계획 표시 기능은 계획을 그래픽 방식으로 표현합니다. 이 기능들은 직접 검사에 가장 적합한 솔루션이며 실행 계획의 표시와 분석에 압도적으로 가장 자주 사용되는 방식입니다. 이 글에서는 이러한 방식으로 생성된 그래픽 계획을 사용하여 예제를 설명하겠습니다.
  • SHOWPLAN_XML 및 SHOWPLAN_ALL과 같은 다양한 SET 옵션은 실행 계획을 특수 스키마를 사용하여 계획을 설명하는 XML 문서 또는 실행 계획의 각 작업에 대한 텍스트 설명이 있는 행 집합으로 반환합니다.
  • Showplan XML과 같은 SQL Server 프로파일러 이벤트 클래스를 이용하면 추적을 통해 수집된 구문의 실행 계획을 모을 수 있습니다.
실행 계획의 XML 표현은 사람이 읽기 쉬운 형식은 아니지만, 이 옵션을 이용하면 실행 계획을 분석하여 성능 문제의 징후와 최적화되지 않은 계획을 조사하는 프로시저와 유틸리티를 만들 수 있습니다. XML 기반 표현 역시 확장명이 .sqlplan인 파일로 저장한 다음 Management Studio에서 열어 그래픽 표현으로 만들 수 있습니다. 또한 이 파일들을 저장하여 나중에 분석할 수 있으므로, 분석할 때마다 실행 계획을 다시 만들 필요가 없습니다. 이 점은 시간의 흐름에 따라 계획이 어떻게 변했는지 비교하고자 할 때 특히 유용합니다.

예상 실행 비용
실행 계획에 대해 가장 먼저 이해해야 할 것은 그 생성 방식입니다. SQL Server는 비용 기반 쿼리 최적화 프로그램을 사용합니다. 즉, 예상 비용이 가장 낮은 실행 계획을 생성하려고 합니다. 이 예상은 최적화 프로그램이 쿼리에 관련된 각 테이블을 평가할 때 제공되는 데이터 분포 통계에 근거합니다. 그와 같은 통계가 누락되거나 너무 오래된 것이라면, 쿼리 최적화 프로그램이 쿼리 최적화에 필요한 중요 정보를 확보하지 못한 셈이므로 예상이 맞게 않게 됩니다. 이러한 경우 최적화 프로그램에서는 다양한 계획의 실행 비용을 과대 평가 또는 과소 평가하여 최적이 아닌 계획을 선택하게 됩니다.
예상 실행 비용에 대한 몇 가지 잘못된 가정이 일반적으로 통용되고 있습니다. 특히 예상 실행 비용이 쿼리의 예상 실행 시간을 알 수 있는 좋은 지표이며 이 예상치를 통해 양호한 계획과 잘못된 계획을 구분할 수 있다고 생각하는 경우가 많습니다. 그것은 사실이 아닙니다. 첫째, 예상 비용을 나타내는 단위는 무엇이며 실행 시간과 직접적 관련이 있는지 여부는 충분히 문서화되어 있습니다. 둘째, 이것은 예상치이며 맞지 않을 수 있으므로 예상 비용이 더 높은 계획이 CPU, I/O, 실행 시간 측면에서 훨씬 더 효율적인 경우도 있습니다. 특히 테이블 변수를 포함하는 쿼리에서 이런 일이 자주 발생합니다. 테이블 변수에 대한 통계는 없기 때문에 쿼리 최적화 프로그램은 테이블 변수 하나에 실제로 행이 여러 개 들어 있더라도 하나만 포함되어 있다고 가정합니다. 따라서 쿼리 최적화 프로그램은 부정확한 예상치를 기반으로 계획을 선택하는 것입니다. 그러므로 쿼리의 실행 계획을 비교할 때는 예상 쿼리 비용 하나만을 기준으로 해서는 안 됩니다. 대신 STATISTICS I/O 및 STATISTICS TIME 옵션의 결과를 분석에 포함시켜 I/O 및 CPU 시간의 측면에서 그 실행의 실제 비용을 파악해야 합니다.
병렬 계획이라는 특수한 유형의 실행 계획을 언급할 필요가 있습니다. CPU가 두 개 이상인 서버에서 쿼리를 실행하고 있고 이 쿼리가 병렬화가 가능하다면 병렬 계획을 선택할 수 있습니다. 일반적으로, 쿼리 최적화 프로그램은 비용이 설정 가능한 특정 임계값을 초과하는 쿼리에 대해서만 병렬 계획을 고려합니다. 여러 병렬 스레드 실행을 관리하기 위한 오버헤드(즉, 여러 스레드에 걸친 작업 배분, 동기화 수행, 결과 수집 등)로 인해 병렬 계획의 실행 비용은 더 높으며 예상 비용에 이러한 부분이 반영됩니다. 그렇다면 비용이 더 높은 병렬 계획을 사용하는 이유는 무엇일까요? 병렬 계획은 여러 CPU의 처리 능력을 활용할 수 있기 때문에 표준 계획보다 결과를 빨리 산출합니다. 가용 자원과 다른 쿼리로부터의 동시 로드 등의 변수들을 포함한 구체적 시나리오에 따라 병렬 계획이 더 바람직할 수 있습니다. 그와 같은 경우에는 쿼리 중 어느 것이 병렬 계획을 산출할 수 있는지, 그리고 각각이 몇 개의 CPU를 활용할 수 있는지 등을 제어해야 합니다. 이렇게 하려면 서버 수준에서 최대 병렬 처리 수준 옵션을 설정하고 필요에 따라 OPTION(MAXDOP n)을 통해 개별 쿼리 수준에서 이를 재정의하면 됩니다.

실행 계획의 분석
이제 간단한 쿼리와 그 실행 계획, 그리고 그 성능 향상을 위한 몇 가지 방법을 살펴보겠습니다. SQL Server 2005의 Adventure Works 예제 데이터베이스에서 실제 실행 계획 포함 옵션을 켜고 Management Studio를 사용하여 이 쿼리를 실행한다고 하겠습니다.
SELECT c.CustomerID, SUM(LineTotal)
FROM Sales.SalesOrderDetail od
JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
JOIN Sales.Customer c ON oh.CustomerID=c.CustomerID
GROUP BY c.CustomerID
그 결과로 생성된 실행 계획을 그림 1에서 볼 수 있습니다. 이 간단한 쿼리는 Adventure Works의 각 고객들이 낸 주문의 총량을 계산하고 있습니다. 이 실행 계획을 보면 데이터베이스 엔진이 어떻게 쿼리를 처리하고 결과를 산출하는지 알 수 있습니다. 그래픽 실행 계획은 위에서 아래로, 오른쪽에서 왼쪽으로 읽어야 합니다. 각 아이콘은 수행된 논리적/물리적 작업을 나타내며 화살표는 작업 사이의 데이터 흐름을 나타냅니다. 화살표의 두께는 작업 사이를 오가는 행의 수를 나타냅니다. 화살표가 두꺼울수록 포함된 행이 더 많습니다. 포인터를 연산자 아이콘 중 하나 위로 올려 놓으면 노란색 도구 설명(그림 2에서 보이는 것과 유사한 것)을 통해 해당 작업의 세부 내용이 표시됩니다.
그림 1 샘플 실행 계획
그림 1 샘플 실행 계획
그림 2 연산에 대한 세부 정보
그림 2 연산에 대한 세부 정보
각 연산자를 살펴보면 수행된 절차의 순서를 분석할 수 있습니다.
  1. 데이터베이스 엔진은 Sales.Customer 테이블에서 Clustered Index Scan 작업을 수행하고 해당 테이블의 모든 행에 대한 CustomerID 열을 반환합니다.
  2. 그리고 Sales.SalesOrderHeader 테이블의 인덱스 중 하나에 대해 Index Scan(비클러스터형 인덱스 스캔을 의미함)을 수행합니다. 이것은 CustomerID 열의 인덱스이지만 또한 암시적으로 SalesOrderID 열(테이블 클러스터링 키)을 포함합니다. 이 두 열 모두의 값이 스캔에 의해 반환됩니다.
  3. 두 스캔의 결과는 Merge Join 물리 연산자를 이용하여 CustomerID 열에서 조인됩니다. 이것은 논리적 조인 작업을 수행할 수 있는 세 가지 물리적 방법 가운데 하나입니다. 빠르지만 조인된 열에서 두 입력 모두 정렬되어야 합니다. 이 경우, 두 스캔 연산 모두 이미 CustomerID에서 정렬된 행들을 반환했으므로 추가로 정렬 연산을 수행할 필요가 없습니다.
  4. 다음으로, 데이터베이스 엔진은 Sales.SalesOrderDetail 테이블에서 클러스터형 인덱스의 스캔을 수행하고 이 테이블의 모든 행으로부터 네 열(SalesOrderID, OrderQty, UnitPrice, UnitPriceDiscount)의 값을 검색합니다. 이 작업에서는 123,317개의 행이 반환될 것으로 예상되었으며 그림 2의 예상 행 수 및 실제 행 수 속성에서 보이듯이 실제로도 그만큼 반환되었습니다. 따라서 이 예상은 매우 정확했습니다.
  5. Clustered Index Scan으로 생성된 행은 첫 번째 Compute Scalar 연산자로 전달되어 수식에 포함된 OrderQty, UnitPrice 및 UnitPriceDiscount 열을 기반으로 각 행에 대해 계산 열 LineTotal의 값을 계산할 수 있게 됩니다.
  6. 두 번째 Compute Scalar 연산자는 계산 열 수식에서 요구하는 대로 ISNULL 함수를 이전 계산의 결과에 적용합니다. 그에 따라 LineTotal 열의 계산이 완료되어 SalesOrderID 열과 함께 다음 연산자로 반환됩니다.
  7. 3단계의 Merge Join 연산자의 출력은 Hash Match 물리 연산자를 사용하여 6단계의 Compute Scalar 연산자의 출력과 조인됩니다.
  8. 그러면 또 하나의 Hash Match 연산자가, CustomerID 열 값과 LineTotal 열의 계산된 SUM 합에 의해 Merge Join으로부터 반환된 그룹 행에 적용됩니다.
  9. 마지막 노드인 SELECT는 물리적 또는 논리 연산자가 아니라 전체 쿼리 결과와 비용을 나타내는 자리 표시자입니다.
필자의 노트북에서 이 실행 계획의 예상 비용은 3,31365로 나타났습니다(그림 3 참고). STATISTICS I/O ON과 함께 실행했을 때 이 쿼리는 포함된 세 개의 테이블에서 총 1,388회의 논리적 읽기 작업을 수행한 것으로 보고했습니다. 각 연산자 아래에 표시되는 백분율은 전체 실행 계획의 총 예상 비용에 대한 각 개별 연산자의 비용의 비율을 나타냅니다. 그림 1의 계획을 보면 전체 실행 계획의 총 비용 대부분이 Sales.SalesOrderDetail 테이블의 Clustered Index Scan 연산자와 2개의 Hash Match 연산자 등의 세 연산자와 관련되어 있음을 알 수 있습니다. 그러나 이들을 모두 최적화하기 전에, 쿼리에 매우 간단한 변화로도 2개의 연산자를 모두 없앨 수 있다는 점을 지적하고자 합니다.
그림 3 쿼리의 총 예상 실행 비용
그림 3 쿼리의 총 예상 실행 비용
Sales.Customer 테이블로부터 반환된 유일한 열이 CustomerID이고 이 열은 Sales.SalesOrderHeaderTable에도 외래 키로 포함되어 있으므로, 논리적 의미 또는 쿼리에 의해 만들어진 결과를 변경하지 않고 아래와 같은 코드를 사용하여 쿼리에서 Customer 테이블을 완전히 제거할 수 있습니다.
SELECT oh.CustomerID, SUM(LineTotal)
FROM Sales.SalesOrderDetail od JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
GROUP BY oh.CustomerID
그 결과, 그림 4와 같이 다른 실행 계획이 도출되었습니다.
그림 4 쿼리에서 Customer 테이블을 제거한 이후의 실행 계획
그림 4 쿼리에서 Customer 테이블을 제거한 이후의 실행 계획
두 개의 작업(Customer 테이블의 Clustered Index Scan과 Customer와 SalesOrderHeader 사이의 Merge Join)이 완전히 제거되었으며 Hash Match 조인은 훨씬 더 효율적인 Merge Join으로 교체되었습니다. 그러나 SalesOrderHeader와 SalesOrderDetail 테이블 사이의 Merge Join을 사용하기 위해 두 테이블의 행들은 조인 열 SalesOrderID에 의해 정렬, 반환되어야 했습니다. 이를 위해 쿼리 최적화 프로그램은 Non-Clustered Index Scan을 사용하지 않고 I/O의 관점에서 더 저렴한 방법으로, SalesOrderHeader 테이블에서 Clustered Index Scan을 수행하기로 했습니다. 이것은 쿼리 최적화 프로그램이 실제 어떻게 작동하는지 보여 주는 좋은 사례입니다. 조인 작업을 수행하는 물리적 방법을 변경함으로써 발생하는 비용 절감의 크기가 Clustered Index Scan에 의해 생성되는 추가 I/O 비용보다 크므로 총 예상 실행 비용이 가장 낮기 때문에 쿼리 최적화 프로그램이 그와 같은 연산자 조합을 선택하는 것입니다. 필자의 노트북에서는 논리적 읽기 수가 증가(1,941까지)하더라도, 사용되는 CPU 시간은 실제로 더 줄었으며 이 쿼리의 예상 실행 비용은 약 13%(2,89548) 감소했습니다.
그러면 이 쿼리의 성능을 더 높이려 한다고 가정하겠습니다. 이제 이 실행 계획에서 가장 비용이 높은 연산자가 된 SalesOrderHeader 테이블의 Clustered Index Scan을 살펴봅니다. 쿼리 실행을 위해선 이 테이블로부터 두 개의 열만 필요하므로, 그 두 개의 열만 담고 있는 비클러스터형 인덱스를 만들고, 전체 테이블의 스캔을 훨씬 적은 비클러스터형 인덱스의 스캔으로 교체합니다. 인덱스 정의의 형태는 다음과 같을 것입니다.
CREATE INDEX IDX_OrderDetail_OrderID_TotalLine
ON Sales.SalesOrderDetail (SalesOrderID) INCLUDE (LineTotal)
필자가 만든 인덱스에 계산된 열이 포함되어 있음에 유의하십시오. 이것은 항상 가능한 것이 아니고, 계산된 열의 정의에 따라 다릅니다.
이 인덱스를 만들고 동일한 쿼리를 실행한 후에, 그림 5와 같은 새로운 실행 계획을 얻습니다.
그림 5 최적화된 실행 계획
그림 5 최적화된 실행 계획
SalesOrderDetail 테이블에 대한 Clustered Index Scan은 I/O 비용이 매우 낮은 비클러스터형 인덱스 스캔으로 교체되었습니다. 또한 필자의 인덱스에는 이미 계산된 LineTotal 열의 값이 포함되어 있으므로, Compute Scalar 연산자 중 하나를 제거했습니다. 이제 예상 실행 계획 비용은 2,28112이며 이 쿼리는 실행되면 1,125회의 논리적 읽기를 수행합니다.

커버 인덱스
고객 주문 쿼리 연습
Q: 다음은 고객 주문 쿼리 연습입니다. 인덱스 정의를 생각해 보십시오. 이 쿼리의 커버 인덱스가 되려면 어느 열을 포함해야 하는지, 그리고 인덱스 정의 안의 열 순서에 따라 성능 차이가 발생할지를 생각해 보십시오.
A: 필자는 예로 든 쿼리에 대해 Sales.SalesOrderHeader 테이블에 만들 수 있는 가장 최적의 커버 인덱스를 알아내라는 과제를 냈습니다. 이를 위해 가장 유의해야 할 것은 그 쿼리가 그 테이블에서 오직 두 개의 열 CustomerID와 SalesOrderID만 사용한다는 점입니다. 필자의 설명을 주의 깊게 읽었다면 SalesOrderHeader 테이블의 경우, 언제나 이 쿼리를 커버하는 기존 인덱스가 있다는 것을 알 것입니다. 그것은 CustomerID의 인덱스이며 그것은 암시적으로, 테이블의 클러스터링 키인 SalesOrderID 열을 포함합니다.
필자는 쿼리 최적화 프로그램에서 이 인덱스를 사용하지 않기로 결정한 이유도 설명했습니다. 물론, 쿼리 최적화 프로그램에서 이 인덱스를 사용하도록 강제할 수 있지만 그 방법은 Clustered Index Scan과 Merge Join 연산자를 사용하는 기존 계획보다 효율성이 떨어질 것입니다. 그것은 여러분이 쿼리 최적화 프로그램으로 하여금, 여전히 Merge Join을 사용할 수 있도록 추가 Sort 연산을 수행하는 방법 또는 덜 효율적인 Hash Join을 사용하는 것으로 후퇴하는 방법 중 하나를 선택하도록 강제할 것이기 때문입니다. 두 옵션 모두 기존 계획보다 예상 실행 비용이 높습니다(Sort 연산을 사용하는 옵션이 특히 성능이 나쁨). 따라서 쿼리 최적화 프로그램은 강제가 없는 한 이러한 옵션을 사용하지 않을 것입니다. 그러므로 이 상황에서 Clustered Index Scan보다 성능이 좋은 유일한 인덱스는 SalesOrderID의 비클러스터형 인덱스, 즉 CustomerID입니다. 그러나 그 열의 순서가 정확해야 한다는 점에 유의해야 합니다.
CREATE INDEX IDX_OrderHeader_SalesOrderID_CustomerID
ON Sales.SalesOrderHeader (SalesOrderID, CustomerID)
이 인덱스를 만든다면, 그 실행 계획에는 Clustered Index Scan 연산자보다는 Index Scan 연산자가 들어갈 것입니다. 이것은 상당한 차이가 있습니다. 이 경우, 단 두 개의 열만 포함하고 있는 비클러스터형 인덱스는 클러스터 인덱스 형태의 전체 테이블보다 훨씬 작습니다. 따라서 필수 데이터를 읽는 데 필요한 I/O가 훨씬 적습니다.
또한 이 예는 인덱스의 열 순서가 쿼리 최적화 프로그램에서 인덱스의 유용성에 큰 영향을 미치는 원리도 보여 줍니다. 열이 다수인 인덱스를 설계할 때는 이 점을 반드시 기억하시기 바랍니다.

SalesOrderDetail에 필자가 만든 인덱스는 소위 "커버 인덱스(covering index)"의 한 예입니다. 이것은 쿼리 실행에 필요한 모든 열을 포함하고 있는 비클러스터형 인덱스로서, Table Scan 또는 Clustered Index Scan 연산자를 사용하여 전체 테이블을 스캔할 필요가 없습니다. 이 인덱스는 테이블의 열 일부를 담고 있는, 본질적으로 테이블의 소규모 사본입니다. 쿼리에 답하는 데 필요한 열만 인덱스에 포함됩니다. 달리 말해, 쿼리를 '커버'하는 데 필요한 것만 포함됩니다.
가장 자주 실행되는 쿼리에 대해 커버 인덱스를 만드는 것은 쿼리 조정에 사용되는 가장 쉽고 가장 흔한 기법입니다. 이 기법은 테이블에 다수의 열이 들어 있지만 그 중 일부만 쿼리에 의해 자주 참조되는 상황에 특히 효과적입니다. 하나 또는 여러 개의 커버 인덱스를 만들면, 액세스하는 데이터의 양이 훨씬 적어지므로 수반되는 I/O의 양도 줄어, 영향받는 쿼리의 성능을 대폭 높일 수 있습니다. 그러나 데이터 수정 작업(INSERT, UPDATE, DELETE) 중에는 추가 인덱스 유지라는 숨은 비용이 있습니다. 여러분의 환경, 그리고 SELECT 쿼리와 데이터 수정 사이의 비율에 따라, 이러한 인덱스 유지 관리 부담의 증가가 쿼리 성능 향상으로 충분히 정당화될 것인지 면밀히 판단해야 합니다.
단일 열 인덱스와는 반대로 다수 열 인덱스를 만드는 것을 두려워하지 마십시오. 다수 열 인덱스는 단일 열 인덱스보다 훨씬 유용성이 높으며 쿼리 최적화 프로그램에서는 쿼리 커버를 위해 다수 열 인덱스를 더 많이 사용할 것입니다. 대부분의 커버 인덱스는 다수 열 인덱스입니다.
이 글에서 사용한 샘플 쿼리의 경우, 여전히 향상의 여지가 있으며 SalesOrderHeader 테이블에 커버 인덱스를 배치하여 더 최적화할 수 있습니다. 이 방법은 Clustered Index Scan을 제거하고 비클러스터형 Index Scan을 사용합니다. 이것은 여러분에게 연습으로 남겨 두겠습니다. 인덱스 정의를 생각해 보십시오. 이 쿼리의 커버 인덱스가 되려면 어느 열을 포함해야 하는지, 그리고 인덱스 정의 안의 열 순서가 성능에 어떤 영향을 줄지 생각하십시오. 해답은 "고객 주문 쿼리 연습" 추가 기사에서 확인하십시오.

인덱싱된 뷰
예로 든 쿼리의 성능이 매우 중요하다면, 한 단계 더 나아가 쿼리의 구체화된 결과를 물리적으로 저장하는 인덱싱된 뷰를 만들 수 있습니다. 인덱싱된 뷰에는 일정한 전제 조건과 한계가 있지만, 일단 사용할 수 있다면 성능을 대폭 향상시킬 수 있습니다. 인덱싱된 뷰는 표준 인덱스보다 유지 관리 비용이 높다는 점을 기억하십시오. 따라서 사용할 상황을 신중히 판단해야 합니다. 이 경우, 인덱스 정의는 다음과 같습니다.
CREATE VIEW vTotalCustomerOrders
WITH SCHEMABINDING
AS
SELECT oh.CustomerID, SUM(LineTotal) AS OrdersTotalAmt, COUNT_BIG(*) AS TotalOrderLines
FROM Sales.SalesOrderDetail od
JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
GROUP BY oh.CustomerID
그와 같은 뷰에 대한 인덱스 생성의 전제 조건인 WITH SCHEMABINDING 옵션과, 인덱스 정의에 집계 함수(이 예에서는, SUM)가 포함되어 있다면 필수적인 COUNT_BIG(*) 함수에 유의하십시오. 이 뷰를 만든 후에는 다음과 같이 그에 대한 인덱스를 만들 수 있습니다.
CREATE UNIQUE CLUSTERED INDEX CIX_vTotalCustomerOrders_CustomerID
ON vTotalCustomerOrders(CustomerID)
이 인덱스를 생성할 때, 뷰 정의에 포함된 쿼리의 결과가 구체화되고 인덱스의 디스크에 물리적으로 저장됩니다. 그러면 기본 테이블의 모든 데이터 수정 연산이 뷰의 값을 그 정의에 따라 자동으로 업데이트한다는 점에 유의하십시오.
쿼리를 지금 다시 실행했을 때 어떤 일이 발생할지는 실행 중인 SQL Server의 버전에 따라 다릅니다. Enterprise 또는 Developer Edition의 경우, 쿼리 최적화 프로그램은 이 쿼리를 인덱싱된 뷰 정의와 자동으로 일치시키고 관련된 기본 테이블을 쿼리하는 대신 인덱싱된 뷰를 사용합니다. 그림 6에서는 이 경우에 생성된 실행 계획을 보여 줍니다. 이 계획은 단 하나의 연산, 즉 필자가 뷰에 만든 인덱스의 Clustered Index Scan만으로 구성됩니다. 예상 실행 비용은 불과 0,09023이며 단 92회의 논리적 읽기만 수행됩니다.
그림 6 인덱싱된 뷰를 사용할 때의 실행 계획
그림 6 인덱싱된 뷰를 사용할 때의 실행 계획
다른 SQL Server 버전에서도 이러한 인덱싱된 뷰를 만들 수 있지만, 동일한 효과를 얻으려면 다음과 같이 NOEXPAND 힌트를 사용하여 직접 그 뷰를 참조하도록 쿼리를 변경해야 합니다.
SELECT CustomerID, OrdersTotalAmt
FROM vTotalCustomerOrders WITH (NOEXPAND)
여기서 알 수 있듯이 인덱싱된 뷰는 적절히 사용될 경우 매우 강력한 기능이 될 수 있습니다. 인덱싱된 뷰는 대량의 데이터를 대상으로 집계를 수행하는 쿼리를 최적화하는 데 가장 유용합니다. Enterprise Edition에서 사용하는 경우 코드를 변경하지 않고도 많은 쿼리에 유익한 효과를 줄 수 있습니다.

튜닝할 쿼리 식별
튜닝할 가치가 있는 쿼리를 어떻게 알아볼 수 있을까요? 자주 실행되는 쿼리를 찾아 봅니다. 단일 실행 비용은 그리 높지 않을 수도 있지만 실행의 집계 비용은 실행 빈도가 매우 낮은 큰 쿼리의 실행 집계 비용보다 훨씬 높을 수 있습니다. 큰 쿼리는 튜닝할 필요가 없다는 말이 아니라 실행 빈도가 높은 쿼리에 먼저 집중해야 한다는 뜻입니다. 그러면 이것들을 어떻게 알아볼 수 있을까요?
아쉽게도 가장 신뢰할 수 있는 방법은 다소 복잡하며 서버에 대해 실행된 모든 쿼리를 추적하고 용법에 따라 분류하는 작업이 포함됩니다. 즉, 다른 매개 변수 값으로 실행되었더라도 동일한 쿼리 유형을 식별할 수 있도록 자리 표시자로 교체된 실제 매개 변수 값으로 텍스트를 쿼리합니다. 쿼리 용법은 생성하기 까다롭기 때문에 이것은 복잡한 프로세스입니다. Itzik Ben-Gan은 그의 저서 Inside Microsoft SQL Server 2005: T-SQL Querying에서 CLR 사용자 정의 함수와 정규식을 이용하는 해결책을 설명했습니다.
그리고 다소 신뢰성은 떨어지지만 훨씬 간단한 방법이 있습니다. 실행 계획 캐시에 모든 쿼리에 대해 보관된 통계치를 활용하여 동적 관리 뷰를 통해 쿼리할 수 있습니다. 그림 7에는 가장 큰 논리적 읽기 누적 수와 함께 캐시의 20개 쿼리의 실행 계획과 텍스트를 모두 보여 주는 샘플 쿼리가 들어 있습니다. 이 쿼리는 가장 큰 논리적 읽기 수를 생성하는 쿼리를 신속히 식별하는 데 매우 편리하지만 여러 가지 제약이 있습니다. 즉, 쿼리 실행 시점에 계획이 캐시에 저장된 쿼리만 보여 줍니다. 캐시에 저장되지 않은 것이 있다면 놓치게 됩니다.
Figure 7 읽기 I/O의 측면에서 비용이 가장 높은 쿼리 20개 찾기 (Close Figure 7)
SELECT TOP 20 SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
        ((CASE qs.statement_end_offset
          WHEN -1 THEN DATALENGTH(qt.text)
         ELSE qs.statement_end_offset
         END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, qs.last_logical_reads,
qs.min_logical_reads, qs.max_logical_reads,
qs.total_elapsed_time, qs.last_elapsed_time,
qs.min_elapsed_time, qs.max_elapsed_time,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE qt.encrypted=0
ORDER BY qs.total_logical_reads DESC
이러한 성능 저하 요소를 파악하게 되면 그 쿼리 계획을 살펴보고 이 글에 설명된 인덱싱 기법 중 일부를 활용하여 그 성능을 높일 수 있는 방법을 찾아보십시오. 성공한다면, 시간을 들인 만큼 효과는 있을 것입니다.
튜닝의 재미를 느껴보세요!

Maciej Pilecki는 교육, 지도, 컨설팅을 전문으로 하는 전 세계적인 기관인 Solid Quality Mentors의 Associate Mentor입니다. 그는 MCT(Microsoft Certified Trainer)이자 MVP(SQL Server Most Valuable Professional)로 SQL Server와 응용 프로그램 개발에 대한 다양한 주제로 활발하게 강의 및 강연 활동을 하고 있습니다.


 From the Editor: 그린 컴퓨팅
From the Editor
그린 컴퓨팅

지난 달 기사에서 그린 컴퓨팅(Green computing)이라는 주제에 대한 논의를 시작했습니다. 그러나 아직 이 주제 자체에 대해서도 명확히 정의하지 않은 것 같습니다. 그린(Green)이란 과연 무엇을 의미할까요? 자동차 연비가 리터당 10km가 아닌 13km에 달하면 그린 자동차라 할 수 있는 것일까요? 뭐, 차도 한 대 없는 필자에게 이것은 별 의미도 없습니다. 뉴욕에서는 걷는 편이 훨씬 나으니까요.
또한 일정 수준 이상인 회사라면 너나없이 자사의 제품이나 서비스에 "그린"이라는 표시를 사용하려 하는 것 같습니다. 그런데 이렇게 하는 데는 다 이유가 있습니다. 잠재적인 효과가 엄청나다는 것이지요. 지난 달에 이 주제가 표지를 장식한 것도 그러한 까닭입니다.
환경 보전도 수익을 창출하는 것만큼 중요하다는 사실은 누구나 알고 있습니다. 실제로 환경 친화적이라는 요소는 실질적인 결과로 이어지는 중요한 영업 주안점이 된지 오래입니다. 연비가 높은 자동차를 만드는 회사가 더 큰 실적을 올리는 것은 바람직한 현상입니다. 언젠가는 건강하게 유지되는 환경 속에서 건전한 경제 체계가 만들어지기를 바랄 뿐이죠.
그렇다면 이러한 사실이 IT 전문가와는 어떤 관련이 있을까요? 로렌스 버클리 국립 연구소(Lawrence Berkeley National Laboratory)에서 과학자로 일하고 있고 Stanford 대학에서 자문 교수직을 맡고 있는 Jonathan Koomey 박사는 최근 미국과 전 세계에 있는 서버의 총 전력 소비량을 추정한 연구 결과를 발표했습니다. 2005년, 데이터 센터(서버와 해당 서버를 지원하는 냉각 시스템 등의 인프라 포함)에서 소비된 전력은 미국 내 전체 전력 소비량 중 1.2%를 차지했습니다. 이는 1,000MW(메가와트) 규모의 5개 발전소의 총 출력에 해당하며, 금액으로는 27억 달러에 달합니다. 전 세계적으로 보면 비용이 72억 달러(1,000MW 규모의 14개 발전소의 총 출력)에 이릅니다. 데이터 센터 내에서만 막대한 금액(전력)을 절감할 수 있는 셈입니다.
보통 데이터 센터 용량은 어떻게 계획합니까? 항상 100% 가동해야 하는 상황이 발생하지 않도록 요구량에 따라 적절히 용량을 조절하려면 어떻게 해야 할까요? 한 가지 힌트를 드리자면, 가상화를 떠올려 보십시오. 서버에서 네트워크 연결, 메모리 사용 등을 모니터링하지만 전력 소모에 대해서는 간과하지 않습니까? 구형 서버의 전력 소비량이 신형 컴퓨터에 비해 훨씬 많지 않습니까? 이로 인해 컴퓨터 교체 비용보다 많은 비용이 낭비되지는 않습니까?
앞으로 매월 Microsoft의 전문가 중 한 명인 Dave Ohara(현재 technetmagazine.com에 게시되어 있는 지난 달 기사의 저자)가 워싱턴주 퀸시 및 텍사스주 샌 안토니오에서 자체 "그린" 데이터 센터를 구축하기 위한 Microsoft의 작업 현황과 몇 가지 질문에 대한 답을 제공할 예정입니다. 그린 데이터 센터 구축과 관련한 독자 여러분의 이야기도 기다리고 있습니다. 그린 데이터 센터를 구축하지 않기로 결정한 경우에도 그 이유를 들려주십시오. tnmag@microsoft.com으로 메일을 보내거나 blogs.technet.com/tnmag를 방문해 주시기 바랍니다. —Joshua Hoffman

도움을 준 Tim Carroll, Omesh Desai, Steve Jenness, Sam Kroonenburg, Mutlu Kurtoglu, KC Lemson, Tim Mintner, Jim Truher, Buck Woody, Sudarshan Yadav를 비롯한 Microsoft 기술 전문가들에게 감사를 전합니다.


 Toolbox: IT 전문가를 위한 새로운 제품
Toolbox
IT 전문가를 위한 새로운 제품
Greg Steen

비디오 화면 캡처
My Screen Recorder Pro
deskshare.com/msrpro.aspx
20분 후에 회의가 있는데 새 시스템 구성에 대한 프레젠테이션을 아직 완성하지 못했다고 생각해 보십시오. 아니면 거의 매일 다른 사용자에게 똑같은 응용 프로그램 교육을 실시한다고 생각해 보십시오. 이러한 상황에 있다면 DeskShare에서 제공하는 My Screen Recorder Pro를 한번 살펴보시기 바랍니다.
이름에서 알 수 있듯이 My Screen Recorder Pro는 바탕 화면에서 수행하는 작업을 비디오로 기록할 수 있는 응용 프로그램으로, 즉석에서 프레젠테이션을 만들거나 고객을 위해 다시 사용 가능한 자습서를 구성할 수 있습니다. 또한 오디오 녹음 기능도 지원하므로 설명을 녹음하여 추가할 수도 있습니다. 한 가지 힌트를 드리자면, 녹음/녹화를 시작하기 전에 원고 또는 개요를 작성하면 편리합니다.
새 비디오는 전체 바탕 화면, 바탕 화면의 사용자 지정 가능 영역, 바탕 화면의 고정된 부분, 특정 응용 프로그램 창 등 기록할 영역을 선택하고 Record 단추를 누르기만 하면 간단히 만들 수 있습니다.
기록된 파일은 AVI, WMV(Windows Media® 비디오) 또는 Flash로 저장되므로 작업 결과를 비교적 손쉽게 배포할 수 있을 뿐만 아니라 웹 페이지에 비디오를 포함하거나 스트리밍하여 다른 여러 사람과 공유할 수 있습니다. 또한 대부분의 Windows® PC에서 로컬로 재생할 수 있도록 실행 파일을 만들 수도 있습니다. 이 경우 실행 파일에 비디오가 포함되어 배포하기가 쉽고 최종 사용자가 간편하게 재생할 수 있습니다.
자습서나 프레젠테이션이 여러 부분으로 구성된 경우 여러 비디오를 하나의 비디오로 합칠 수 있습니다. 비디오를 편집해야 할 때에는 필요에 맞게 녹화된 비디오를 분할하거나 자를 수 있습니다.
대부분의 경우에 기본 구성을 사용하면 되지만 특정한 환경에 맞게 프레임 속도, 오디오 음질, 압축 설정 등을 조정할 수도 있습니다. 이와 같이 조정함으로써 크기 또는 대역폭에 제약이 있는 경우 문제를 손쉽게 해결할 수 있습니다. 간단히 시간 경과 모드로 녹화할 수도 있습니다. 이 모드에서는 느린 진행률 표시줄과 같이 오래 실행되는 녹화 부분을 압축할 수 있습니다. 또 다른 유용한 기능으로는 녹화에 사용되는 마우스 커서를 변경하고 녹화 세션이 진행되는 동안 나타나는 동작에 이목을 끌 수 있도록 마우스 포인터 효과를 추가하는 등의 옵션이 있습니다. 예를 들어 마우스 단추를 클릭할 때마다 포인터가 커지거나 포인터 주위에 원이 표시되도록 할 수 있습니다. 또한 보관용 비디오에 캡션과 타임스탬프를 추가할 수도 있습니다.
평범하지 않은 성향의 사용자들을 위해 My Screen Recorder Pro는 녹화를 예약하는 기능도 제공하며 명령줄에서 프로그램 실행이 가능하므로 워크스테이션의 작업을 조심스럽게 모니터링할 수도 있습니다. 마지막으로 이 응용 프로그램에는 비디오를 FTP 사이트에 게시하는 기능이 기본으로 제공됩니다. 이 기능을 스케줄러와 함께 사용하면 감사 용도로 유용할 수 있습니다.

가격: 단일 라이선스당 99달러
바탕 화면의 작업을 녹화하여 프레젠테이션 만들기
바탕 화면의 작업을 녹화하여 프레젠테이션 만들기

디스크 조각 모음
PerfectDisk 8
raxco.com/products/PerfectDisk2k
모든 Windows 시스템에서는 하드 디스크 조각 모음이 필수적입니다. 필자처럼 응용 프로그램, 기능, 소프트웨어 업데이트 등을 자주 추가했다가 제거하는 사용자라면 다양한 디스크 조각 모음 유틸리티 중 하나를 선택해 사용하는 것이 좋습니다. 사실 지난달에도 하나를 소개한 바 있습니다. 하지만 조각 모음은 매우 중요하므로 Raxco Software의 PerfectDisk 8을 살펴보는 것도 충분히 가치가 있습니다. Windows의 모든 버전에는 조각 모음 도구가 포함되어 있지만 조각 모음 작업을 보다 세부적으로 제어할 수 있는 유틸리티가 필요한 경우도 있습니다. 그러한 맥락에서 PerfectDisk라는 도구를 한번 살펴보겠습니다.
모든 Windows 조각 모음 도구와 마찬가지로 PerfectDisk 8도 FAT16, FAT32 및 NTFS 드라이브를 조각 모음할 수 있으며 RAID 드라이브의 조각 모음까지도 지원합니다. 데스크톱 및 서버 버전으로 제공되는 PerfectDisk 8은 Windows Vista® 인증을 받았으며 Windows Server® 2003, Windows 2000 등 다른 Windows 버전도 지원합니다. 게다가 Exchange용 버전까지 있습니다.
Raxco Software는 액세스 속도를 높이기 위해 디스크의 파일 구조를 정리하는 SMARTPlacement 기술을 이 제품에 적용하고 있습니다. 예를 들어 Windows XP 시스템에서 SMARTPlacement 기술은 boot 및 layout.ini 파일을 관리하고 시스템 시작 시 디스크 검색 시간을 줄일 수 있도록 해당 파일을 정렬하는 역할을 합니다. 전체 드라이브를 조각 모음할 수도 있으며 단일 파일을 조각 모음하도록 선택할 수도 있습니다. 예를 들어 크기가 큰 ISO 파일을 다운로드한 경우에는 이 옵션이 유용합니다.
일반적으로 OS가 실행 중일 때 손댈 수 없는 다루기 힘든 시스템 파일을 처리하기 위해 이 응용 프로그램은 다음 시스템 시작 시 실행되는 오프라인 모드를 사용하여 조각 모음을 실행하거나 디스크를 분리할 수 있는 적절한 조건하에서 조각 모음을 실행합니다. PerfectDisk의 또 다른 유용한 기능으로는 화면 보호기가 실행될 때 자동으로 조각 모음을 시작하는 화면 보호기 조각 모음 모드가 있습니다.
이 외에도 PerfectDisk에는 주로 사용하는 작업 스케줄러에서 손쉽게 조각 모음을 예약하고 시스템에서 실행하는 모든 시스템 관리 에이전트를 통해 원격으로 실행할 수 있도록 하는 명령줄 버전도 포함되어 있습니다. 대규모 배포의 경우 PerfectDisk Command Center를 무료로 다운로드하여 원격으로 워크스테이션 응용 프로그램을 회사 전체에 배포, 업데이트, 예약 및 구성할 수 있습니다.

가격: 데스크톱용 PerfectDisk 8 Professional(단일 라이선스당 39.99달러~) PerfectDisk 8 Server(단일 라이선스당 239.99달러~)
다양한 구성 옵션을 제공하는 PerfectDisk
다양한 구성 옵션을 제공하는 PerfectDisk

서평
Network Warrior
oreilly.com
Cisco 장비를 다루는 경우라면 Gary Donahue의 Network Warrior(O'Reilly, 2007)를 읽어 보는 것이 좋습니다. 이 책은 네트워킹 분야를 처음 접하는 독자, 최근 CCNA 자격증을 획득한 독자, 새로운 네트워킹 지식을 얻으려는 숙련된 시스템 관리자 등 폭넓은 독자에게 유용한 리소스가 될 수 있습니다.
실제 활용되고 있는 네트워킹 기술을 중심으로 한 내용이고 네트워크 전문가들이 일상적으로 자주 수행하는 많은 작업에 대한 빠른 참조를 제공하기 때문에 개인적으로는 이 책을 특히 좋아합니다. 이 책에서는 네트워크의 근간을 이루는 구성 요소에 대해 기본적인 수준에서 시작하여 허브, 스위치, VLAN, 트렁킹, VTP(VLAN Trunk Protocol) 등에 대해 개괄적으로 설명하고 STP(Spanning Tree Protocol)를 사용한 확장 트리 및 Cisco System의 EtherChannel 기술까지 다룹니다.
Network Warrior 전반에 걸쳐 Cisco의 IOS(Internetwork Operating System) 및 CatOS CLI(명령줄 인터페이스) 명령을 사용한 기본 예제와 함께 사용 방식 및 기술에 대한 설명이 제공됩니다. 이 책에서 현재 사용되는 여러 방식에 대한 배경을 간단히 설명하여 조금 더 넓은 안목을 가질 수 있게 하는 것도 마음에 듭니다. 예를 들어 왜 IOS 대신 CatOS가 아직 사용되고 있는지에 대한 설명이 있습니다.
이 책에는 라우터와 라우팅에 대한 일반적인 내용도 포함되어 있어 메트릭에서 여러 가지 라우팅 프로토콜의 AD(Administrative Distance)에 이르기까지 라우팅과 관련한 기본 사항을 배울 수 있습니다. OSPF(최단 경로 우선 프로토콜), BGP(Border Gateway Protocol) 및 RIP(Routing Information Protocol)와 같은 프로토콜에 대한 개요도 나와 있습니다.
Cisco의 HSRP(Hot Standby Router Protocol)에 대한 섹션에서 저자는 주소 지정 기능에 대해 자세히 설명하고 네트워크 인프라에서 가동 중지 시간을 방지하는 몇 가지 기본 구성을 제공합니다. 그리고 이어지는 섹션에서는 Cisco 6500, Catalyst 3750 등 Cisco의 몇 가지 다중 계층 스위치의 기능을 소개하고 사용자가 접할 수 있는 몇 가지 기본 구성을 설명합니다.
통신 분야 관련 정보가 특히 유용합니다. 이 책에서는 전문 용어도 몇 가지 알려 주므로 다음에 그러한 말을 들었을 때 더 이상 아는 척 고개만 끄덕이지 않아도 됩니다. 또한 통신 기술자들이 실제로 사용하는 CSU/DSU(Channel Service Unit/Data Service Unit), DS3 연결 구성 및 다중 노드 프레임 릴레이에 대해서도 충분히 설명되어 있습니다.
보안과 방화벽이 잘 설명되어 있는 섹션에서는 ACL(액세스 제어 목록) 디자인 및 구성 방법을 확인할 수 있고 인증, DMZ, 특정 PIX 방화벽 구성 옵션에 대한 정보를 얻을 수 있습니다. "필요한 것만 빼고 모두 거부하라", "보안은 편의성과 편집증 간의 균형을 유지하는 것" 등의 네트워크의 원칙을 강조한 짤막한 방화벽 이론도 필자가 좋아하는 부분입니다.
Network Warrior의 마지막 섹션에서는 네트워크 디자인을 전반적으로 다루면서 3계층 전자 상거래 구성, 배포 계층이 없는 축소된 핵심 네트워크 등 일반적인 네트워크 인프라 설계의 기본 사항을 소개하고 문서화 및 명명 규칙의 중요성을 강조하고 있습니다.

가격: 정가 44.99달러

파일 잠금 관리
WhoLockMe
dr-hoiby.com/WhoLockMe
모든 응용 프로그램에서 파일이 정상적으로 닫힌다면 좋겠지만, 아쉽게도 현실은 그렇지 못합니다. 공유 위반은 매우 불유쾌한 경험이며, 현재 어느 프로세스에서 파일을 잠갔는지 확인하는 과정은 더더욱 성가십니다. 독자 여러분은 어떤지 모르지만 필자는 파일을 제어할 수 있을 때까지 응용 프로그램을 하나씩 닫는 상황을 몹시 싫어합니다. 다행히 이러한 경우에 WhoLockMe라는 간단한 무료 Windows 탐색기 확장 프로그램을 사용하면 큰 도움이 됩니다.
Windows NT®, Windows 2000, Windows Server 2003 및 Windows XP에서 사용할 수 있는 이 응용 프로그램은 현재 해당 파일을 잠그고 있는 프로세스를 찾을 수 있도록 해 줍니다. 사용도 간편해서, 마우스 오른쪽 단추로 클릭하고 Windows 탐색기의 상황에 맞는 메뉴에서 선택하기만 하면 됩니다.
WhoLockMe는 파일을 잠그고 있는 프로세스의 이름, 해당 PID(프로세스 식별자), 열려 있는 파일의 경로, 프로세스 실행 컨텍스트의 도메인 및 사용자, 원인 제공 프로그램의 전체 경로를 표시합니다. 또한 과감히 UI에서 직접 프로세스를 중단하도록 선택할 수도 있습니다.
아쉽게도 WhoLockMe는 상당한 기간 동안 업데이트되지 않아 Windows Vista에서는 작동하지 않습니다. 그러나 이전 버전의 Windows를 실행한다면 이동, 삭제 또는 편집해야 하는 파일을 잠근 프로세스를 빠르고 효과적으로 찾아내는 데 유용한 도구가 될 것입니다.

가격: 무료

DNS 도구
DNSStuff.com
www.dnsstuff.com
인터넷에 연결되는 응용 프로그램이나 네트워크와 관련하여 작업을 실행하는 경우 해당 응용 프로그램 또는 네트워크를 관리하고, 원활한 실행을 보장하고, 사용자와 응용 프로그램의 위치를 외부에 알리는 데 십중팔구 DNS를 사용하게 될 것입니다. 필자는 DNS 문제가 발생할 때 DNSstuff.com에서 제공하는 도구 집합을 사용합니다. 이 웹 기반 도구 모음은 인프라 구성을 확인하고 문제를 해결하는 데 유용한 리소스가 될 수 있습니다.
이 사이트에서는 도메인, IP, 호스트 이름, 전자 메일, 웹 사이트 등과 관련한 문제와 일반적인 네트워크 문제를 해결하는 데 필요한 도구를 제공합니다. 메일 서버 구성 유효성 검사부터 DNS 호스팅 속도 확인에 이르기까지 모든 측면을 지원하는 45가지 이상의 쿼리 도구가 포함되어 있습니다. 물론 여러분의 인프라에도 이러한 기능을 제공하는 도구가 이미 설치되어 있겠지만 이 도구를 사용하면 외부 유효성 검사를 통해 문제 해결의 열쇠가 되는 정보를 얻을 수도 있습니다. 또한 회사의 옆 사무실에 있는 동료에게 역방향 DNS 조회를 부탁하지 않아도 됩니다.
이 사이트에서 제공하는 가장 강력하고 종합적인 도구 중 하나는 DNSreport입니다. 도메인 이름을 입력하고 단추를 클릭하기만 하면 설정과 관련하여 풍부한 정보를 얻을 수 있습니다. 각 테스트 항목에는 색으로 구분된 상태가 표시되므로 테스트 결과를 빠르게 살펴보면서 문제가 없는지 확인할 수 있습니다. 이 보고서는 도메인의 부모 영역을 검사하여 NS(이름 서버) 레코드 등에 대한 자세한 정보와 호스트 이름과 IP 주소를 보내는지 여부를 표시합니다. 또한 DNS 서버가 개방 서버가 아닌지, NS 레코드가 모두 동일한지, 비NS 요청에서 "숨김" NS 레코드 누수가 발생하는지 확인하여 잠재적인 보안 허점을 검사합니다.
DNSreport는 단일 오류 지점을 검사하면서 여러 이름 서버, 공용 IP 바인딩 및 누락된 이름 서버에 대한 테스트도 실행하므로 설정의 가용성도 살펴볼 수 있습니다. 또한 SOA(권한 시작) 정보를 확인하여 SOA 일련 번호, 새로 고침, 만료, 다시 시도 및 최소 TTL(Time-To-Live) 값을 반환하고 MNAME 및 RNAME 레코드에 대한 검사를 수행합니다.
보고서의 MX(메일 교환기) 레코드 검사는 역방향 DNS 항목의 유효성을 검사하고 중복된 레코드가 없는지, 레코드의 호스트 이름이 올바른지 확인합니다. 뿐만 아니라 메일 서버 연결을 시도하여 인사말에 메일 서버의 호스트 이름이 있는지, 다양한 RFC에 지정되어 있는 abuse@yourdomain 메시지를 수락하는지, 그리고 SMTP 서버가 현재 스패머에게 악용되기 쉬운 오픈 릴레이로 구성되어 있는지를 확인합니다. 마지막으로 DNSreport는 www A 레코드를 반환하고, 모든 IP가 공용인지 확인하고, CNAME 구성으로 인해 추가 DNS 조회가 발생하지 않는지를 확인합니다.
DNSreport로 부족하다면 이 사이트에서 메일 서버가 알려진 스팸 데이터베이스의 목록에 있는지 확인하는 도구와 도메인에 대한 악의적인 연결을 찾는 도구도 사용할 수 있습니다. IP Whois 조회, traceroute, ping을 수행할 수 있을 뿐만 아니라 주요 ISP에서 일반적인 DNS 조회와 캐시된 DNS 조회를 실행할 수 있습니다. 사이트에 가입하면 NETGEO IP 조회, MAC 주소 확인 및 전체 영역 파일 덤프까지 실행 가능합니다. 한마디로 매우 가치 있는 도구 집합이라 할 수 있습니다.

가격: 단일 사용자 회원(모든 액세스 권한 및 무제한 조회)의 경우 월 3달러
유용한 모니터링 도구 집합을 제공하는 DNSstuff.com
유용한 모니터링 도구 집합을 제공하는 DNSstuff.com

Greg Steen은 열성적인 기술 전문가로, IT 전문가의 운영, QA 및 개발 작업에 도움을 줄 수 있는 새로운 도구를 끊임없이 연구하고 있습니다.


 Exchange Queue &amp; A: 보안 전자 메일 프로토콜, 알 수 없는 스팸 등
Exchange Queue & A
보안 전자 메일 프로토콜, 알 수 없는 스팸 등
Nino Bilic and Scott Landry
이 칼럼은 부분적으로 Windows Server 2008 시험판 버전을 기준으로 작성되었으며 여기서 설명하는 내용은 변경될 수 있습니다.

Q: 보안 SMTP를 사용하고 싶은데 Exchange Server가 포트 465에서 SMTP를 수신하도록 하려면 어떻게 합니까?
A: 유감이지만 그건 불가능합니다. 포트 465에서 수신하는 SMTP 가상 서버나 수신 커넥터를 만들 수 있지만 그렇게 한다고 해도 보안 SMTP(SMTPS)라는 목적은 달성되지 않습니다.
이유를 간단히 살펴보겠습니다. SSL에는 명시적 SSL과 암시적 SSL이라는 두 가지 종류가 있습니다. 초기에는 대부분의 SSL이 암시적이었으므로, SSL 전용 포트가 사용되었습니다. 예를 들어 HTTP는 기본적으로 포트 80을 사용하지만 HTTPS(SSL 기능이 있는 HTTP)는 포트 443을 사용합니다. 하지만, 몇 년 전에 인터넷 커뮤니티는 SSL 전용 포트가 필요 없다고 결정했습니다. 따라서 명시적 SSL이 탄생했습니다.
Netscape에서는 이미 465를 SMTPS 포트로 선택했지만 Exchange Server의 SMTP에는 SSL 기능이 없었습니다. 하지만 Exchange 팀은 명시적 SSL의 장점, 즉 클라이언트와 서버가 동등하게 사용할 수 있다는 것에 주목하고 SMTP에 대해 명시적 SSL을 지원하기로 결정했습니다.
SMTP의 경우 명시적 SSL은 기존 소켓에 보안을 적용하기 직전에 STARTTLS ESMTP 명령을 사용하여 이를 알립니다. 대부분의 다른 SMTP 서버 및 클라이언트 공급업체에서 STARTTLS 명령도 구현했으므로 어차피 공식 인터넷 표준이 아닌 포트 465를 지원할 필요가 거의 없었습니다.
현재까지 SMTP에 대해 암시적 SSL을 지원하는 Exchange Server 버전은 없습니다. Exchange 수신 커넥터나 SMTP 가상 서버에 포트 465에서 수신하라고 지시한다고 해도 이 사실은 바뀌지 않습니다. 따라서 포트 25에서 STARTTLS를 지원하는 클라이언트를 사용해야 합니다. 포트 25를 사용할 수 없는 경우에는 클라이언트 SMTP 제출용 표준 포트인 587을 선택하는 것이 좋습니다. 포트 25에서 STARTTLS를 지원하지 않는 최신 클라이언트가 별로 없으므로 암시적 SSL에 대한 지원을 추가할 필요가 없었습니다.
그런데 Exchange POP3 프로토콜과 IMAP4 프로토콜은 항상 암시적 SSL을 지원했습니다. 그러나 Exchange Server 2007에서는 이 두 프로토콜에 대해서도 명시적 SSL에 대한 지원이 추가되어 있습니다. 하지만 이 최신 표준을 지원하는 클라이언트가 아직 많지 않으므로 앞으로 얼마인지 알 수 없지만 당분간은 암시적 SSL이 계속해서 사용될 것입니다.

Q: 엄청난 수의 메일이 여러 도메인의 큐에서 대기 중인데 우리 사용자가 보낸 메일이 아닙니다. 어찌된 일이고 이를 방지하려면 어떻게 해야 합니까?
A: 여러분만 그런 게 아닙니다. 인터넷 서버가 있는 사람이라면 누구든지 이 문제를 겪을 수 있습니다. 기본적으로 두 가지의 가능한 원인이 있습니다. 첫 번째는, 어떤 이유로 사용자의 서버가 릴레이용으로 열린 것입니다(support.microsoft.com/kb/304897 참조). 물론 의도한 것은 아닐 것입니다. Exchange Server 2000 이후부터 오픈 릴레이는 기본적으로 사용되지 않기 때문에 배달 못 함 보고서(NDR) 스팸이라는 현상이 나타날 가능성이 높아졌습니다. 스패머가 UCE(원치 않는 상업용 전자 메일)를 보내는 과정에서 사용자의 도메인에 존재하지 않는 주소로 보내는 경우가 많습니다. 서버에서는 스패머에게 해당 사용자가 존재하지 않음을 알리려고 하지만 스패머는 반송 주소도 스푸핑합니다. 스패머가 잘못된 주소를 스푸핑하고 있거나(이 경우 시간이 초과될 때까지 얼마 동안 NDR이 나타남), 서버로 하여금 스패머 자신을 대신하여 서버에서 생성한 NDR의 첨부 파일로 다른 도메인에 스팸을 보내도록 하려고 시도하고 있을 수 있습니다.
NDR을 사용하지 않도록 설정할 수 있지만 이 경우 합법적인 사용자가 실수로 주소를 잘못 입력한 경우에도 서버가 해당 사용자에게 전자 메일을 보내지 않았다는 것을 알리지 않으므로 중요한 메시지가 손실될 수 있습니다. 더 나은 솔루션이 있습니다.
먼저 서버를 릴레이용으로 열지 말아야 합니다. 그런 다음 IMF(지능형 메시지 필터)나 Exchange Server 2007 콘텐츠 필터와 같은 몇 가지 종류의 스팸 방지 필터링 기능과 일부 RBL(실시간 차단 목록)을 설정하십시오. 이러한 기능을 Edge 전송 역할이나 Hub 전송 역할에 설정할 수 있지만, 메일 양의 90% 이상이 스팸인 경향이 있고 이런 정크 메일을 처리하는 것 때문에 서버 사용량이 늘어나는 것은 바람직하지 않으므로 맨 처음 홉에서 기능을 설정해야 합니다.
마지막으로 해당 환경에 메일을 받아들이는 첫 번째 Exchange Server에서 받는 사람 필터링을 사용하도록 설정하십시오. 이렇게 하면 메시지가 네트워크에 들어오기 전에 서버에서 거부할 수 있습니다. 실수로 주소를 잘못 입력해도 여전히 NDR이 수신되지만 이 NDR은 보낸 사람의 서버에서 생성된 것입니다.

Q: 각각 인터넷으로 메일을 성공적으로 보내고 있는 Exchange Server 2000 서버와 Exchange Server 2003 서버가 한 대씩 있는데 Exchange Server 2007을 설치하자 이제 각 서버의 사서함에서 메일을 보낼 수 없습니다.
A: 이전에 Exchange Server가 한 대밖에 없었다면 커넥터라는 개념을 잘 모를 것입니다. Exchange 커넥터는 전자 메일을 보낼 위치를 Exchange에 알려 주는 논리 라우팅 구성 개체입니다. 기존 조직에 Exchange Server 2007을 도입할 때 메일을 라우팅하려면 반드시 라우팅 그룹 커넥터와 SMTP 커넥터가 있어야 합니다.
두 개의 라우팅 그룹 커넥터, 즉 Exchange Server 2007 라우팅 그룹에서 Exchange Server 2003 라우팅 그룹으로 향하는 라우팅 그룹 커넥터와 Exchange Server 2003 라우팅 그룹에서 Exchange Server 2007 라우팅 그룹으로 향하는 라우팅 그룹 커넥터가 필요합니다. 이것은 설치 과정의 일부로 설정할 수 있지만 시기를 놓쳤거나 확실하지 않은 경우 Exchange 관리 셸을 통해 검사하여 문제를 해결할 수 있습니다. 그렇지 않으면 서버 간에 메일을 보낼 수 없게 되고 메시지가 결과적으로 대상에 연결할 수 없는 메시지 큐에서 대기하게 됩니다.
인터넷 메일을 라우팅하려면 Exchange Server 2007에서 송신 커넥터라고도 하는 SMTP 커넥터가 하나만 있으면 됩니다. Exchange Server 2000과 Exchange Server 2003에 하나가 있지만 모르고 지나쳤을 수 있습니다. 주소 공간은 모든 도메인에 대해 SMTP:*여야 하며 메일 배달에 스마트 호스트나 DNS를 사용하도록 지정할 수 있습니다. 보내는 인터넷 메일을 Exchange Server 2007 서버에서 처리하도록 할지 이전 버전의 서버에서 처리하도록 할지 선택합니다. 보내는 인터넷 메일을 각 서버에서 자체적으로 처리하도록 할 경우에는 두 라우팅 그룹 모두에 하나씩 만들 수 있습니다. Edge 전송 서버 역할을 설치한 경우 이들 중 하나를 Edgesync 프로세스의 일부로 만들 수도 있습니다.
스마트 호스트를 SMTP 가상 서버에 설치했다면 지금 제거하는 것이 좋습니다. 스마트 호스트가 가상 서버에 있어서는 안 되며 SMTP 커넥터에만 있어야 합니다. 그렇지 않으면 라우팅 그룹 커넥터가 손상됩니다.
인바운드 전자 메일이 MX 레코드나 방화벽이 전달하고 있는 IP로 제어된다는 것도 알아야 합니다. Exchange 쪽에서는 구성할 것이 별로 없지만 그래도 문제가 발생할 경우 msexchangeteam.com/archive/2006/11/17/431555.aspx 문서를 참조하면 도움이 됩니다.

Q: Exchange Server 2007에서 같은 메시지에 대해 여러 저널 보고서가 수신되는 이유는 무엇입니까?
A: Exchange Server 2007 전송 저널링 에이전트는 분류 후 메시지를 저널링합니다. 분류기는 메시지를 두 부분으로 나누어, 메시지 본문을 복사하고 복사본마다 다른 봉투 받는 사람을 넣는데 여기에는 많은 이유가 있습니다. 예를 들어, 이제 저널링에는 메시지 송신 당시의 메일 그룹 멤버 자격을 알려 주는 기능이 있으므로 메일 그룹이 중첩된 경우 여러 보고서가 수신될 수 있습니다.
이 풍부한 추가 보고 기능은 같은 메시지에 대해 제각기 고유한 보고서가 있는 복사본이 여러 개 수신될 수 있음을 의미합니다. 한 메시지에 대해 모든 보고서가 도달했는지 알 수 있는 보장된 방법은 없지만 보관을 할 경우 해당 아카이브 공급업체와 협력하여 변경 내용을 인식하고 있는지 확인해야 합니다.

Q: Exchange Server 2007에서는 확인되지 않은 메시지를 호스트에 전달하는 기능이 어디로 갔습니까? 이제 어떻게 하죠?
A: 개가 먹어버렸습니다.
실제로 Exchange Server가 둘 이상이면 이 특정 기능이 그다지 잘 작동하지 않습니다. Exchange에 이미 같은 일을 완료하는 다른 방법이 있으며 이 방법이 훨씬 더 강력합니다. 특히 개별 SMTP 도메인을 다른 시스템과 공유하는 기능이 있습니다. 따라서 "확인되지 않은 메시지를 전달하는" 기능이 삭제되었고 공유 도메인 개념이 향상되어 단순화되었습니다. Exchange Server 2007에서 조직 | Hub 전송 | 허용 도메인으로 이동하고 도메인 종류를 신뢰할 수 있음에서 인터넷 릴레이로 변경하면 됩니다. 실제로 일부 환경의 경우 이보다 약간 더 복잡하며 설명서의 일부를 업데이트하는 작업이 진행되고 있습니다. 그러나 한동안은 이렇게 해도 도움이 됩니다.

Q: Exchange Server 2007 설치에 사용할 루트 도메인을 준비하려고 합니다. Exchange Server 2007 설치 프로그램을 실행하려고 하는 서버에 Exchange Server 2003 ESM(Exchange 시스템 관리자)이 설치되어 있는데 설치가 실패하고 있습니다. 무엇이 문제일까요?
A: Exchange Server 2000 또는 2003 구성 요소가 설치되어 있는 시스템에서 Exchange Server 2007 설치 프로그램의 일부를 실행하는 것은 지원되지 않습니다. Exchange Server 2003 ESM이 설치되어 있으면 Exchange Server 2007 설치 프로그램에서 해당 사실을 확인하기 때문에, 설치 프로그램 필수 구성 요소 검사가 실패하면서 "이 컴퓨터에는 이전 버전의 Exchange Server가 이미 설치되어 있습니다. 다른 컴퓨터에서 Exchange Server 2007 설치 프로그램을 실행하거나 이전 버전의 Exchange Server를 제거하십시오."라는 메시지가 표시됩니다.
아마도 이 문제를 가장 쉽게 해결하는 방법은 루트 도메인의 다른 서버에서 Exchange Server 2007 설치 프로그램을 실행하고 이에 맞게 도메인을 준비하는 것입니다. 이 방법을 실행할 수 없으면 Exchange Server 2003 구성 요소를 제거하고 Exchange Server 2007 설치 프로그램을 계속 실행할 수 있습니다.
32비트 버전의 Exchange Server 2007을 사용하여 도메인을 준비할 수 있으므로 일반적으로 루트 도메인에 있는 임의의 32비트 서버를 사용하면 충분합니다. 이 주제에 대한 자세한 내용은 technet.microsoft.com/library/bb232170.aspx를 참조하십시오.
이것은 Exchange Server 2003과 Exchange Server 2007 관리 도구가 같은 시스템에 공존하는 것이 지원되지 않기 때문에 Exchange Server 2003 ESM과 Exchange Server 2007 Exchange 관리 콘솔을 설치할 수 없음을 의미합니다. Exchange Server 2000 또는 Exchange Server 2003 구성 요소가 설치되어 있는 시스템에 Exchange Server 2007을 설치하려고 하면 설치 프로그램이 중단됩니다.
마지막으로, Exchange Server 2007 관리 도구를 먼저 설치한 다음 같은 시스템에 Exchange Server 2003 도구를 설치해서는 안 됩니다. 이렇게 하면 테스트되지 않은 구성이 만들어지고 서버를 관리하려고 할 때 예상치 않은 결과가 발생할 수 있습니다. 단일 시스템에서 두 서버 버전을 모두 관리해야 할 경우에는 원격 데스크톱을 사용하여 한 버전에 연결하거나 가상 시스템을 사용하여 격리된 환경에서 관리 도구의 다른 버전을 호스팅할 수 있습니다.

Q: 언제가 되어야 내 Windows Vista® 워크스테이션에서 Exchange Server 2007 관리 도구를 실행할 수 있을까요?
A: Exchange Server 2007 관리 도구에 대한 Windows Vista 공식 지원은 Exchange Server 2007 SP1 릴리스와 함께 제공될 예정입니다. Exchange Server 2007 SP1 관리 도구가 포함된 패키지는 Exchange Server 2007 SP1이 출시된 후에 다운로드할 수 있습니다.

Q: Windows Vista나 Windows Server 2008의 Exchange Server 2003 ESM은 어떻습니까? 역시 실행할 수 있을까요?
A: 아니오, 불행히도 그럴 수 없습니다. Exchange Server 2007 SP1 이전의 모든 Exchange Server 버전에 대한 관리 도구는 Windows Vista나 Windows Server 2008에서 지원되지 않습니다. 즉, Windows Server 2008이 출시된 후에도 Windows Vista나 Windows Server 2008에 Exchange Server 2003 ESM을 설치하는 것은 지원되지 않습니다. Exchange Server 2003 서버의 관리는 Windows Server 2003이나 Windows XP 워크스테이션에서 수행해야 합니다. 또는 임의의 OS에서 원격 데스크톱 연결을 사용할 수 있습니다.

Q: 내 도메인에서 여러 대의 Exchange Server 2003 서버가 실행되고 있는데 내 도메인 컨트롤러를 Windows Server 2008 도메인 컨트롤러로 업그레이드할 수 있을까요?
A: 예, Windows Server 2008 도메인 컨트롤러가 있는 도메인에서 Exchange Server 2003 SP2를 실행하는 것은 지원됩니다. Exchange Server는 Windows Server 2008 RODC(읽기 전용 도메인 컨트롤러)나 ROGC(읽기 전용 글로벌 카탈로그 서버)를 사용할 수 없습니다. Windows Server 2008 RODC/ROGC를 사용하도록 Exchange Server를 수동으로 지정(하드코딩)하면 예상치 않은 결과가 발생할 수 있습니다.

Nino Bilic은 Exchange Server 팀의 지원 기능 프로그램 관리자로, 잠자리에 들기 전까지 엄청난 양의 Netmon 추적을 읽으면서 서버 간 통신의 아름다움을 발견하는 것이 취미입니다.
Scott Landry는 Exchange Server 팀의 지원 향상 엔지니어로, 수건, 안내서와 믿음직한 Windows Mobile 전화 없이는 어디에도 가지 않습니다.


 Utility Spotlight: Windows PowerShell용 SMS Cmdlet
Utility Spotlight
Windows PowerShell용 SMS Cmdlet
Don Brown
이 기사의 코드 다운로드: Utility2007_11.exe (1211KB)

예전에는 Microsoft System Management Server(SMS) 2003 클라이언트를 명령줄에서 관리할 방법이 없었습니다. 다행히 관리자가 복잡성, 변경 및 구성을 효과적으로 관리할 수 있도록 최근 개발된 여러 가지 기술 덕분에 결국 Windows PowerShell에서 이 문제가 해결되었습니다.
이 기술을 이용하기 위해 필자는 SMS2003PowerShellSnapinSample이라는 간단한 "유틸리티"를 작성했습니다. 이 유틸리티는 칼럼과 함께 제공되는 코드 다운로드(technetmagazine.com/code07.aspx)에 포함되어 있습니다. 이 유틸리티는 사실상 여섯 가지 cmdlet의 컬렉션을 하나의 Windows PowerShellTM 스냅인으로 구성한 것이라 할 수 있습니다. 이러한 cmdlet을 사용하면 Windows PowerShell에서 로컬 컴퓨터 또는 원격 컴퓨터 그룹에 사용할 SMS 클라이언트 로컬 정책을 구성할 수 있습니다.
SMS 클라이언트 로컬 정책을 사용하면 할수록 효과적인 방식이라는 것을 알 수 있었습니다. 또한 SMS 작동 방식에 대해 이해의 폭을 넓히는 계기가 되기도 했습니다. SMS 클라이언트 로컬 정책을 신중히 사용하면 SMS 클라이언트를 완전히 새로운 방식으로 제어할 수 있습니다. 즉, 동일한 사이트에 보고하는 모든 컴퓨터를 동일하게 구성할 필요가 없어집니다. 이러한 개념을 바탕으로 특정 컴퓨터는 사용 권한 없이도 원격으로 제어할 수 있도록 설정하는 것부터, 클라이언트에서 새 정책을 확인하는 빈도를 변경하거나 하루 중 다양한 시간에 특정 구성 요소를 사용할 수 없도록 하는 등 SMS 클라이언트 로컬 정책의 용도에는 제한이 없습니다. 그럼 자세히 살펴보도록 하겠습니다.

SMS 고급 클라이언트 로컬 정책
프로그래밍 리소스
  • Windows PowerShell 소개 Windows PowerShell를 처음 사용하는 사용자에게 유용한 정보
  • 로컬 정책을 사용한 SMS 사용자 지정 TechNet 포럼 SMS 고급 클라이언트 로컬 정책의 MOF 기반 사용
  • 처음으로 Cmdlet 만들기
  • Windows PowerShell 스냅인을 만드는 방법
  • Windows Server 2008용 NAP(네트워크 액세스 보호)
  • Windows PowerShell 프로그래머 가이드 cmdlet, 스냅인, 호스트 작성 관련 추가 정보와 기타 Windows PowerShell에 대한 프로그래밍 도움말
  • Windows Server 2008 베타 3 단계별 가이드

제대로 작동하는 모든 SMS 2003 고급 클라이언트에는 구성 정책이 있습니다. 기본적으로 이 정책은 다양한 구성 요소를 제어하는 설정의 목록이라고 할 수 있습니다. 그리고 이러한 구성 정책에는 클라이언트, 인벤토리 컬렉션, 소프트웨어 배포 설정 등이 모두 포함되어 있습니다. 정책 자체는 사이트 서버에 생성되고 SMS 관리 지점을 통해 고급 클라이언트로 전달됩니다.
SMS 정책의 실제 내용은 고급 클라이언트에서 \\.\root\CCM WMI (Windows® Management Instrumentation) 네임스페이스로 컴파일되는 인스턴스의 집합을 포함한다는 점에서 MOF(Managed Object Format) 파일과 비슷합니다. 다양한 에이전트가 \\.\root\ccm\policy\machine\requestedconfig 네임스페이스에서 이러한 설정을 읽게 됩니다. 그러나 MOF를 통해 로컬 정책을 적용할 때에는 단일 컴퓨터에서만 MOF를 컴파일할 수 있으며 로컬로만(더 정확히 말하자면 컴퓨터에 직접 로그온한 경우에만) 실행해야 합니다. 그러나 WMI의 경우 고유한 분산 특성으로 인해 로컬로도, 원격으로도 액세스할 수 있기 때문에 SMS 관리자를 위한 다양한 옵션이 지원됩니다. 다시 말해, 적절한 관리 권한만 있으면 원격 컴퓨터에서도 로컬 컴퓨터와 마찬가지로 손쉽게 WMI에 연결할 수 있습니다.
SMS 클라이언트 정책은 여러 가지 클라이언트 구성 요소의 구성 설정으로 이루어지지만 소프트웨어 패키지 콘텐츠 실행 명령을 포함할 수도 있습니다. Active Directory® 그룹 정책과 마찬가지로 SMS 관리 지점에서 가져온 SMS 2003 고급 클라이언트 정책은 SMS 클라이언트 로컬 정책에 의해 재정의될 수 있습니다. 정책의 모든 부분을 재정의할 수는 없지만 몇 가지 유용한 핵심 속성을 재정의할 수 있습니다. 따라서 SMS 관리자가 SMS 사이트에 적용된 표준 구성에 예외를 허용하는 방법으로 SMS 클라이언트의 구성과 작동을 더 큰 폭으로 제어할 수 있습니다.
SMS 관리자가 서버와 워크스테이션을 모두 단일 SMS 주 사이트의 클라이언트로 관리하는 안전하고 통합된 환경을 예로 들어 보겠습니다. 이 가상 환경의 보안 정책에는 기술 지원 엔지니어가 사용자의 컴퓨터를 원격으로 제어하기 전에 사용자에게 사용 권한 부여 여부를 물어야 한다는 내용이 포함될 수 있습니다. 이는 기술 지원 엔지니어가 원격 제어를 통해 서버에 연결하려 할 때 문제가 됩니다. 일반적으로 서버에는 사용자가 로그온되어 있지 않으므로 원격 제어 권한을 부여할 사용자가 없습니다. 하지만 로컬 정책을 잘 사용하면 특정 클라이언트에서 사용자 권한이 필요하지 않도록 할 수 있습니다. 특정 SMS 클라이언트 에이전트의 구성에 예외를 허용하는 데 SMS 로컬 정책을 유용하게 사용할 수 있는 경우는 이 외에도 많습니다.

Windows PowerShell 스냅인 살펴보기
Windows PowerShell의 기본 개념에 어느 정도 익숙해지면 명령줄에서 이 칼럼과 함께 제공되는 샘플 소스 코드에 코드를 추가하여 SMS 클라이언트 로컬 정책의 기능을 확장할 수 있습니다. Windows PowerShell에 노출하기 전에 클래스에 적용해야 하는 몇 가지 특성이 있습니다. 먼저, cmdlet이 어떤 유형이며 어떠한 작업을 수행하는지를 결정해야 합니다. 이를 "동사-명사" 쌍이라고 합니다. Windows PowerShell에서 많이 사용되는 동사로는 Add, Get, Set 등이 있습니다. 명사 부분은 작업 대상 개체를 설명합니다. 일반적으로 cmdlet에는 cmdlet 클래스에 다양한 형식의 공용 속성으로 선언되는 매개 변수가 있습니다. 마지막으로, 주 작업 대상이 되는 ProcessRecord 함수가 있습니다. 그림 1에는 cmdlet을 직접 작성하는 데 사용할 수 있는 일반 템플릿이 나와 있습니다.
Figure 1 Cmdlet 템플릿 (Close Figure 1)
[Cmdlet( "Verb", "Noun", SupportsShouldProcess = true )]
public class Verb_Noun : PSCmdlet
{
    [Parameter( ValueFromPipeline = true, ValueFromPipelineByPropertyName = true,
        HelpMessage = "Parameter" )]
    [ValidateNotNullOrEmpty]
    [Alias( "param" )]
    public string Parameter
    {
        get { return MyParameter; }
        set { MyParameter = value; }
    }
    private string MyParameter;

    protected override void ProcessRecord( )
    {
        //Do your stuff here!
    }
}
스냅인을 컴파일한 후에는 RunInstaller 특성이 설정되고 특정 속성이 정의된 클래스를 프로젝트에 포함하여 Windows PowerShell에서 해당 스냅인을 등록해야 합니다. 자세한 내용은 이 기사와 함께 제공되는 소스 코드를 참조하십시오. 스냅인을 등록하려면 Microsoft® .NET Framework에 포함된 InstallUtil.exe 도구를 사용해야 합니다. 그림 2는 스냅인 등록에 사용되는 구문을 보여 줍니다. Windows Vista®의 경우 이 작업을 위해서는 권한 상승이 필요하므로 "관리자로 열기" 옵션을 사용하거나 technetmagazine.com/issues/2007/06/UtilitySpotlight에서 다운로드 가능한 Script Elevation PowerToys for Windows Vista를 사용하여 Windows PowerShell을 열어야 합니다.
Figure 2 Windows PowerShell에서 스냅인 설치 (Close Figure 2)
PS> set-alias installutil $env:windir\Microsoft.NET\Framework\v2.0.50727\installutil
PS> installutil C:\MySMSTools\SMS2003PowerShellSnapinSample.dll
Microsoft (R) .NET Framework Installation utility Version 2.0.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
Running a transacted installation.
...
The transacted install has completed.
다음 단계로, Windows PowerShell에서 스냅인이 승인되는지 확인해야 합니다. Get-PSsnapin cmdlet을 Registered 매개 변수와 함께 사용하면 Windows PowerShell에 현재 로드된 스냅인이 추가할 등록된 스냅인 목록과 함께 요약됩니다. 이 목록에 해당 스냅인이 포함되어 있어야 합니다.
PS> Get-PSsnapin -registered
이제 다음과 같이 Add-PSsnapin cmdlet을 사용하여 셸에 Windows PowerShell 스냅인을 추가할 수 있습니다.
PS> add-pssnapin SMS2003PowerShellSnapinSample
이 작업에 성공하면 Windows PowerShell 스냅인에서 cmdlet을 실행할 수 있습니다.
Windows PowerShell 스냅인에서 사용할 수 있는 cmdlet을 모두 보려면 Get-Command cmdlet으로 특정 스냅인을 지정하고 스냅인의 이름을 PSsnapin 매개 변수의 값으로 전달하면 됩니다. 이 칼럼과 함께 제공되는 샘플 스냅인은 그림 3과 같이 동사-명사 cmdlet 템플릿을 비롯하여 여섯 가지 cmdlet을 표시합니다.
그림 3 스냅인의 cmdlet 표시
그림 3 스냅인의 cmdlet 표시
샘플 소스 코드에서는 구성 방법을 보여 주기 위해 Get-SMSServerConnection cmdlet에 대한 도움말만 작성했습니다. 도움말을 확장하는 데 대한 예제는 나중에 XML 파일로 소개하겠습니다. 그림 4에는 도움말 출력이 나와 있습니다.
Figure 4 샘플 Get-Help 출력 (Close Figure 4)
PS > get-help Get-SMSServerConnection

NAME
    Get-SMSServerConnection

SYNOPSIS
    This cmdlet establishes a connection to the specified SMS primary site server using your current credentials. An object of type "SMSProvider" is returned through the pipeline.

SYNTAX
    Get-SMSServerConnection [-SMSServerName] [<string>] [<CommonParameters>]

DETAILED DESCRIPTION
    This Cmdlet makes a connection to the specified SMS primary site server.  An object of type "SMSProvider" is returned. The "SMSProvider" object is not serializable and is used only to forward on through the pipeline to other cmdlets.

RELATED LINKS
Windows PowerShell 스냅인 설치 방법, 스냅인의 명령을 찾는 방법 및 일반적인 cmdlet에 대한 도움말을 보는 방법을 살펴보았으므로 이제 실제로 cmdlet을 사용해 보도록 하겠습니다. SMS 주 사이트 서버에 모든 컬렉션의 목록을 표시하려면 다음 명령을 사용합니다.
PS > Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | Format-Table Name
파이프라인을 살펴보십시오. 이 파이프라인이 Windows PowerShell 작동에서 핵심적인 부분이며 강력한 도구입니다. Windows PowerShell에서는 코드 한 줄로 거의 모든 작업이 가능합니다. Get-SMSServerConnection cmdlet은 SMS 서버와의 연결을 설정합니다. Get-Collections cmdlet에는 Get-SMSServerConnection에 의해 반환되는 형식의 입력 매개 변수가 하나 있으므로 Get-SMSServerConnection cmdlet에서 Get-Collections cmdlet으로 간단히 출력을 전달할 수 있습니다. 이는 파이프라인의 작동 방식을 보여 주는 예로, cmdlet 간에 복잡한 개체를 전달하는 방법을 잘 보여 줍니다. 개체를 변수에 저장할 수도 있으며, Windows PowerShell 스크립트를 사용하는 경우 코드가 다음과 같이 됩니다.
$SMS = Get-SMSServerConnection
     -server MYSMSSERVER
Get-Collections -SMSServerProvider $SMS
Get-Collections는 SMSCollections 형식(기본적으로 SMSCollection 형식의 개체 배열)의 개체를 반환하므로 출력의 형식을 잘 지정하지 않으면 읽기가 어려울 수 있습니다. 간단히 말해 내용을 간결하게 보려면 표시할 컬렉션을 필터링하거나 원하는 속성만 포함된 표로 표시해야 합니다. 이를 위해서는 파이프라인을 통해 Get-Collections cmdlet에서 Format-Table cmdlet으로 출력을 전달해야 합니다. 이 경우 지정한 속성만 표시됩니다. 예를 들어 | Format-Table Name, Member를 추가할 수 있습니다.
하지만 특정 컬렉션의 멤버를 모두 표시하는 더 효과적인 방법이 있습니다. 이 예제의 경우 Get-CollectionMembers를 사용하면 됩니다. 이 cmdlet은 컬렉션의 각 멤버 이름을 나타내는 문자열의 배열을 반환합니다. 이미 눈치챘겠지만 이는 다음 cmdlet으로 파이프라인을 전달하는 좋은 예입니다.
지금까지는 SMS 고급 클라이언트 로컬 정책이 사용되지 않았습니다. SMS 주 사이트 서버에 연결하고 컬렉션과 컬렉션 멤버를 열거했을 뿐입니다. 이 샘플 Windows PowerShell 스냅인에는 마지막으로 Enable-SoftwareDistribution 및 Disable-SoftwareDistribution이라는 두 가지 cmdlet이 사용됩니다. 이 두 cmdlet에 SMS 클라이언트 로컬 정책이 사용됩니다. 이 두 cmdlet은 SMS 고급 클라이언트의 소프트웨어 배포 클라이언트 에이전트 구성 요소에 대한 SMS 클라이언트 로컬 정책을 조작합니다. cmdlet의 동사 부분에서 알 수 있듯이 Disable은 소프트웨어 배포 클라이언트 에이전트도 해제하도록 클라이언트 로컬 정책을 재정의합니다. 마찬가지로 Enable이라는 동사는 모든 클라이언트 로컬 정책 재정의를 제거하고 소프트웨어 배포 클라이언트 에이전트를 SMS 관리 지점에서 전달되는 SMS 정책에 정의된 정상 상태로 되돌립니다. 그림 5에는 Windows PowerShell 한 줄 코드가 나와 있습니다. 이 코드는 Windows Server 2003 Systems 사용자 지정 컬렉션의 모든 멤버를 강제로 해제하는 소프트웨어 배포 클라이언트 에이전트에 대한 SMS 클라이언트 로컬 정책 재정의와 유사합니다. 이 한 줄 코드는 동일한 컬렉션이 나열된 소프트웨어 배포 클라이언트 에이전트에 대한 모든 SMS 클라이언트 로컬 정책 재정의를 제거합니다. SMS 클라이언트 로컬 정책을 조작할 컴퓨터 수가 적은 경우 Disable-SoftwareDistribution 및 Enable-SoftwareDistribution cmdlet을 그 자체만으로 사용할 수도 있습니다.
Figure 5 cmdlet 어셈블 예제 (Close Figure 5)
PS >Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | where-object {$_.Name -eq "Windows Server 2003 Systems"} | Get-CollectionMembers | Disable-SoftwareDistribution
PS >
PS > Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | where-object {$_.Name -eq "Windows Server 2003 Systems"} | Get-CollectionMembers | Enable-SoftwareDistribution
PS >
PS >Disable-SoftwareDistribution –hosts SMSCLIENT1, SMSCLIENT2, SMSCLIENT3
PS >
PS >Enable-SoftwareDistribution –hosts SMSCLIENT1, SMSCLIENT2, SMSCLIENT3

다음 단계
이 기사와 함께 제공되는 샘플 소스 코드는 여러 컴퓨터에 SMS 클라이언트 로컬 정책 재정의를 적용할 때 기반으로 사용할 수 있습니다. 여기서 소개하는 샘플은 SMS 소프트웨어 배포 클라이언트 에이전트의 Enabled 속성에 대해서만 다룹니다. 다른 클라이언트 에이전트에는 이와 같은 방법으로 재정의를 적용할 수 있는 속성이 많습니다. 이제 기초 사항을 배웠으므로 SMS 클라이언트 로컬 정책의 다른 부분을 살펴보시기 바랍니다. 관리 시스템의 그룹에도 SMS 클라이언트 로컬 정책 재정의를 유용하게 사용할 수 있습니다. 마지막으로 하나 덧붙이자면 항상 코드가 어떻게 진행되는지 잘 파악하는 것이 중요하므로 테스트 환경에서 철저히 테스트해야 합니다.

Don Brown은 Microsoft의 수석 필드 엔지니어로, 오랫동안 SMS(SCCM) 개발 및 지원 업무를 담당해 왔습니다. 문의 사항이 있으면 donbrown@microsoft.com으로 연락하십시오.


 The Cable Guy: 무선 SSO(Single Sign-On)
The Cable Guy
무선 SSO(Single Sign-On)
Joseph Davies

무선 연결을 설정한 다음 사설 네트워크에 인증하는 환경은 사용자와 관리자 모두에게 또 다른 부담이 될 수 있습니다. Active Directory 도메인의 구성원인 Windows 기반 무선 클라이언트는 반드시 IEEE 802.1X-기반 인증을 수행해야 보호된 무선 연결과 도메인 로그온을 얻을 수 있습니다.
인증 과정에는 사용자 또는 컴퓨터의 자격 증명이 필요하고 도메인 로그온은 네트워크 연결에 달려 있기 때문에, 인증이 수행될 순서를 구성할 때와 어느 자격 증명을 사용할지 지정할 때 문제가 발생합니다. 이러한 모든 부분이 도메인 로그온에 영향을 줄 수 있으며 한 사용자가 여러 차례 자격 증명을 입력해야 하는 경우가 발생할 수 있습니다.
다행히 Windows Vista®의 무선 SSO에서는 WPA2(Wi-Fi Protected Access 2)-Enterprise 및 WPA-Enterprise에 대한 IEEE 802.1X 인증, WEP(Wireless Equivalency Privacy)에 대한 802.1X 인증이 사용자 로그온 프로세스 이전에 이루어지도록 지정할 수 있습니다. 이렇게 하면 특정 구성의 도메인 로그온 문제를 해결할 수 있습니다. 무선 SSO는 또한 Windows® 로그온 과정에 무선 인증을 완벽하게 통합함으로써 사용자들의 전반적 만족도를 향상시켰습니다. 이러한 이유로, 이번 달에는 무선 SSO의 기능과 구성 방법, 사용자 로그온 과정에서 무선 SSO가 작동하는 방식 등을 살펴보고자 합니다.

SSO의 기초
Windows 무선 클라이언트는 컴퓨터 또는 사용자 자격 증명 중 하나만 사용하거나 둘 모두를 조합하여 무선 네트워크 인증을 수행할 수 있습니다. 컴퓨터 자격 증명만 사용할 경우, Windows에서는 Windows 로그온 화면을 표시하기 전에 802.1X 인증을 수행합니다. 따라서 무선 클라이언트 컴퓨터는 Active Directory® 도메인 컨트롤러와 같은 네트워크 자원에 일찍 액세스할 수 있습니다.
사용자 자격 증명만 사용할 경우, SSO가 없는 Windows는 사용자 로그온 과정이 완료된 이후에 802.1X 인증을 수행합니다. 그림 1은 이 시나리오의 시작 및 로그온 시간 표시줄을 보여 줍니다.
그림 1 무선 인증에 사용자 자격 증명만 사용할 경우의 시간 표시줄
그림 1 무선 인증에 사용자 자격 증명만 사용할 경우의 시간 표시줄
무선 인증에 사용자 자격 증명만 사용하게 되면 컴퓨터에 대한 초기 도메인 로그온을 수행할 수 없게 됩니다. 그것은 그 사용자의 계정에 대한 자격 증명이 로컬 캐시에 저장되어 있지 않고 새로운 로그온 자격 증명을 인증할 도메인 컨트롤러에 대한 연결이 없기 때문입니다. 더욱이 이 시점에서는 Active Directory 도메인의 도메인 컨트롤러에 대한 연결이 없기 때문에 일부 도메인 로그온 작업은 실패합니다. 로그온 스크립트, 그룹 정책 업데이트, 사용자 프로필 업데이트 등이 실패하여 Windows 이벤트 로그 오류가 발생합니다.
사용자 자격 증명과 컴퓨터 자격 증명을 조합하게 되면 Windows에서는 Windows 로그온 화면이 표시되기 전에 컴퓨터 자격 증명으로 802.1X 인증을 수행합니다. 이 사용자가 로그온한 후, Windows는 사용자 자격 증명으로 또 다른 802.1X 인증을 수행합니다. 일부 네트워크 인프라에서는 컴퓨터 자격 증명을 통해 인증된 컴퓨터와 사용자 자격 증명을 통해 인증된 컴퓨터에 대해 서로 다른 가상 LAN(VLAN)을 사용합니다. 사용자 자격 증명을 이용한 무선 네트워크 인증과 사용자 인증이 이루어진 VLAN으로의 전환이 사용자 로그온 프로세스 이후에 이루어지면, Windows 무선 클라이언트는 사용자 로그온 프로세스 중에는 사용자 인증 VLAN의 Active Directory 도메인 컨트롤러와 같은 네트워킹 리소스를 액세스할 수 없게 됩니다. 이 경우에도, 도메인 로그온 작업이 실패로 돌아갑니다.
사용자 자격 증명을 이용한 무선 인증에서 사용자 로그온 자격 증명과는 다른 보안 자격 증명 세트를 사용하면 또 다른 문제가 발생합니다. 그러한 구성을 위해 Windows에서는 무선 인증 과정이 시작되면 사용자 자격 증명을 추가로 묻는데, 이것이 혼란과 번거로움을 야기할 수 있습니다.
Windows Vista의 SSO 기능은 도메인 로그온 문제, 컴퓨터 인증과 사용자 인증이 분리된 VLAN의 문제, 사용자에게 상이한 시점에 상이한 자격 증명을 묻는 문제 등을 해결하기 위해 개발되었습니다. SSO 기능을 통해, 네트워크 관리자들은 사용자 자격 증명을 이용한 무선 인증 작업이 사용자 로그온 과정 이전에 이루어지도록 지정할 수 있습니다. 사용자 로그온에 필요한 사용자 자격 증명과 무선 인증에 필요한 사용자 자격 증명이 서로 다를 경우, 필요한 자격 증명이 모두 요청되며 Windows 로그온 화면에 수집됩니다.
SSO를 이용하면, 사용자 로그온 과정 이전에 사용자 자격 증명을 통해 무선 네트워크 인증을 수행하도록 Windows Vista 무선 클라이언트를 구성할 수 있습니다. 그림 2는 새로운 시작 및 로그온 시간 표시줄을 보여 줍니다.
그림 2 사용자 로그온 이전에 사용자 자격 증명을 통해 무선 네트워크 인증이 이루어질 경우의 시간 표시줄
그림 2 사용자 로그온 이전에 사용자 자격 증명을 통해 무선 네트워크 인증이 이루어질 경우의 시간 표시줄
이렇게 하면 기능 손실 없이, 서로 구분된 VLAN에 사용자 자격 증명만 사용하거나 사용자 및 컴퓨터 자격 증명 조합을 사용하는 구성이 가능합니다. 이를 통해 무선 클라이언트는 사용자 로그온 프로세스가 시작되기 전에 네트워크 연결 또는 사용자 인증 VLAN에 대한 연결을 활용하여 도메인 로그온 작업을 성공적으로 완료할 수 있습니다. "Windows Vista 무선 클라이언트의 도메인 참가"(microsoft.com/technet/network/wifi/vista_bootstrap_wireless.mspx)에 그 예가 나와 있습니다.
무선 프로필의 구성을 기반으로, SSO는 무선 인증에 필요한 사용자 자격 증명의 입력 필드를 통합하여 Windows 로그온 화면에 추가합니다. 따라서, 사용자 로그온을 위한 모든 사용자 자격 증명과 사용자 자격 증명을 이용한 무선 인증을 사용자가 동시에 제공합니다.
Windows Vista의 새로운 EAPHost 아키텍처를 위해 작성된 EAP(Extensible Authentication Protocol) 메서드는 EAP PLAP(Pre-Logon Authentication Provider) Support API를 사용하여 인증에 필요한 입력 필드를 Windows 로그온 화면에 포함시킬 수 있습니다. 더 자세한 정보는 msdn2.microsoft.com/bb530584의 SSO 및 PLAP API를 참고하십시오.
SSO 세션의 한 예로서, 도메인 로그온과 802.1X 인증 모두에 사용자 자격 증명과 사용자 이름 및 암호만 사용하여 인증을 수행하도록 구성된 Windows Vista 무선 클라이언트를 고려해보겠습니다. Windows Vista 초기 화면에서 Ctrl+Alt+Del을 누르면 SSO에서는 사용자 로그온 이전에 반드시 802.1X 인증이 이루어져야 하는 것으로 판단합니다. 사용자 이름과 암호를 입력하면 SSO는 사용자 기반 무선 네트워크 인증을 먼저 수행하고 이름을 이용하여 무선 네트워크에 연결하는 중이라는 메시지를 표시합니다. 무선 인증 이후, Windows Vista는 사용자 로그온을 수행하고 사용자의 바탕 화면을 표시합니다.

Single Sign-On 구성
배후 작업
무선 인증 프로세스에 대한 이해를 더욱 돕기 위해, 사용자가 적극적으로 로그온을 시도할 경우 어떤 일이 벌어지는지 더 자세히 살펴보겠습니다. Windows Vista를 실행하는 무선 클라이언트에서 사용자 로그온을 위해 Ctrl+Alt+Del을 누르면 다음과 같은 절차가 실행됩니다.
  1. '무선 자동 구성'에서 사용할 무선 네트워크 프로필을 결정합니다. 무선 클라이언트에서 이미 컴퓨터 자격 증명을 통해 인증을 성공적으로 수행했다면 현재 연결된 무선 네트워크 프로필이 사용됩니다. 결정된 무선 프로필이 컴퓨터 자격 증명만 사용하여 인증을 수행하도록 구성되어 있다면 사용자 자격 증명을 이용한 무선 인증은 추가로 필요하지 않습니다. 2단계에서 6단계까지는, 선택된 무선 프로필이 사용자 자격 증명을 통해 인증을 수행하도록 구성되어 있고, SSO 기능이 켜져 있으며, '사용자 로그온 전에 즉시 수행' 설정이 선택된 것으로 가정합니다.
  2. 사용자는 사용자 로그온과 (필요한 경우) 무선 인증을 위해 자신의 자격 증명을 입력하고 사용자 로그온을 시작합니다.
  3. Windows는 무선 네트워크 이름으로 연결을 시도하고 있음을 사용자에게 메시지로 알립니다.
  4. Windows는 사용자 자격 증명을 통해 무선 네트워크 인증을 시도합니다. 'SSO 중 추가 대화 상자 표시 허용' 설정이 켜져 있고 EAP 유형이 사용자에게 추가 대화 상자의 표시를 필요로 할 경우, Windows는 그 대화 상자를 표시합니다. '연결의 최대 지연 시간(초)' 안에 무선 인증이 올바로 이루어지지 않으면 무선 인증을 포기합니다. '이 네트워크에서 컴퓨터와 사용자 자격 증명 인증에 다른 VLAN 사용' 설정이 선택되면 Windows는 무선 인증에 성공했을 때 무선 네트워크 어댑터의 IP 주소 구성에 대한 DHCP 갱신을 수행합니다.
  5. Windows에서 사용자 로그온 프로세스를 수행합니다.
  6. Windows에서 바탕 화면을 표시합니다.
'사용자 로그온 후에 즉시 수행' 설정이 선택되면 Windows에서는 1, 2, 5, 3, 4, 6의 순서로 각 단계를 수행합니다.

SSO 기능을 켜고 구성하려면 무선 네트워크(IEEE 802.11) 정책 그룹 정책 확장을 사용하고 Windows Vista 정책의 무선 프로필에 대한 고급 보안 설정을 구성하면 됩니다. 이에 대한 자세한 정보는 "Windows Vista의 무선 그룹 정책 설정"(technetmagazine.com/issues/2007/04/CableGuy)을 참고하십시오.
고급 보안 설정 대화 상자에서 '이 네트워크에 SSO 사용'을 선택하고 필요에 따라 SSO 옵션을 구성하십시오. 그림 3에는 기본 설정으로 SSO를 사용하는 예가 나와 있습니다.
그림 3 기본 SSO 설정
그림 3 기본 SSO 설정
사용자 로그온 프로세스 이전 또는 이후에 즉시 802.1X 무선 인증을 수행하는 SSO 설정과 사용자 로그온 프로세스 시작 전에 802.1X 인증 완료에 걸리는 지연 시간을 지정하는 SSO 설정이 있습니다. Windows 로그온 화면에 입력 필드가 통합된 이후에도 대화 상자를 표시할 것인지 여부도 지정할 수 있습니다. 예를 들어 EAP 유형이 인증 과정에서 RADIUS(Remote Authentication Dial-in User Service) 서버로부터 전송된 인증서를 사용자가 확인하도록 요구할 경우, EAP 유형은 그 대화 상자를 표시할 수 있습니다.
또한 사용자 기반 인증을 수행한 이후 무선 클라이언트가 무선 어댑터의 TCP/IP 구성에 대한 DHCP(동적 호스트 구성 프로토콜) 갱신을 반드시 시작하도록 지정할 수도 있습니다. 컴퓨터 기반 인증 및 사용자 기반 인증 무선 클라이언트에 대해 각기 별도의 VLAN이 있고 그 VLAN들이 서로 다른 IPv4 또는 IPv6 서브넷일 경우에 이 옵션을 선택하십시오.
정책 내에서 SSO 설정이 들어 있는 무선 프로필을 만든 후에는 프로필을 XML 파일로 내보낸 다음 Windows Vista 무선 클라이언트에서 XML 프로필 가져오기를 수행하여 Windows Vista 무선 클라이언트도 구성할 수 있습니다.
SSO XML 무선 프로필을 만들려면, 적절한 SSO 설정이 있는 무선 프로필을 만드십시오. Windows Vista 무선 정책의 '일반' 탭에서 SSO 설정이 있는 무선 프로필을 클릭한 다음, '내보내기'를 클릭합니다. 화면 표시에 따라 프로필 XML 파일 이름과 위치를 지정합니다.
이 SSO XML 프로필을 이용하여 다른 Windows Vista 무선 클라이언트를 구성하려면 다음 명령을 사용하여 XML 프로필을 가져옵니다.
netsh wlan add profile filename=
    "[FileName].xml"
무선 프로필에서 SSO를 사용하는지 파악하려면 다음을 이용합니다.
netsh wlan show profile=[ProfileName]
SSO 설정은 netsh wlan show profile 명령 표시의 "보안 설정" 섹션과 Windows 이벤트 로그에 있는 무선 연결 이벤트의 텍스트에 수록되어 있습니다. 또한 이벤트 뷰어 스냅인을 사용하여 응용 프로그램 및 서비스 로그의 Microsoft\Windows\WLAN-AutoConfig 폴더에서 원본이 "WLAN-AutoConfig"이고 이벤트 ID가 13001, 13002, 13003 및 13004인 이벤트를 볼 수 있습니다.
무선 네트워킹 웹 페이지(microsoft.com/wifi)에서 더 자세한 내용을 확인할 수 있습니다. 또한 "배후 작업" 추가 기사에서 SSO 프로세스에 대한 더 자세한 내용을 확인할 수 있습니다.

Joseph Davies는 Microsoft의 테크니컬 라이터로 1992년부터 Windows 네트워킹을 주제로 글을 쓰고 가르치는 일을 하고 있습니다. Microsoft Press에서 5권의 책을 저술한 그는 월간 TechNet Magazine Cable Guy 칼럼의 저자이기도 합니다.


 Research Notes: HPC(고성능 컴퓨팅)을 활용한 HIV 치료법 개발
Research Notes
HPC(고성능 컴퓨팅)을 활용한 HIV 치료법 개발
Kristin Firth와 Mia Matusow

의학 연구에 종사하는 사람들이라면 흰색 가운을 걸치고 시험관과 현미경을 열심히 사용하는 모습을 떠올리기 마련입니다. 대학이나 제약회사의 약제사를 쉽게 떠올릴 수 있겠죠. 물론 전형적이고 현실적인 의학 연구원들의 모습이긴 하지만,
이러한 모습은 의학 분야의 한 단면에 지나지 않습니다. 사실 의학 연구원들은 매우 다양한 환경에서 일하고 있습니다.
앞서 말한 선입견으로 인해 Microsoft Research가 HIV(후천성 면역 결핍증) 백신 개발에 있어서 중요한 역할을 하고 있다는 사실은 다소 놀라울 것입니다. 게다가 현미경이나 시험관 하나도 사용하지 않고 여느 사무실과 같이 평범한 책상과 PC가 즐비한 환경에서 말입니다.
대체 Microsoft는 이 연구에서 어떤 역할을 하고 있을까요? 흰 가운을 입은 사람들, 즉 보스턴의 Mass General, University of British Columbia, University of Washington, Fred Hutchinson Cancer Research Center, 오스트레일리아의 Murdoch University 등 다양한 대학과 연구 기관에서 일하는 과학자들은 막대한 양의 프로젝트 데이터를 수집합니다. 그러면 뉴멕시코에 있는 한 명을 제외하고 대부분 워싱턴 주 레드먼드에서 일하는 직원 대여섯 명으로 이루어진 Microsoft Research의 eScience 팀에서 연구원들이 방대한 데이터를 처리하고 분석할 수 있도록 돕습니다. Microsoft Research는 지난 2003년에 처음 이 프로젝트에 참여했으며, 현재 eScience 팀은 여러 가지 사회 문제를 해결하기 위해 다양한 프로젝트에서 과학자들과 협력하고 있습니다. 그 과정에서 주로 외부 과학자들과의 긴밀한 협력을 통해 여러 가지 프로젝트에 맞는 솔루션을 개발하고 수치를 처리하고 결과를 분석하는 작업을 담당합니다.
많은 프로젝트 중에서도 Microsoft는 HIV 변이 패턴과 관련한 데이터 분석에 큰 비중을 두고 있습니다. Microsoft의 수석 연구원인 의학 박사 David Heckerman에 따르면, HIV는 감염자의 면역 체계로부터 공격을 받으면 빠르게 변이합니다. "숙주의 면역 체계에 대항하기 위한 HIV의 변이 양상을 밝히는 연구를 진행 중입니다. 이를 위해 개인의 면역 체계 유형과 감염을 일으키는 HIV 단백질 서열 간의 상관 관계를 조사하고 있습니다."
과학자들은 HIV에 감염된 환자로부터 샘플을 채취해 환자의 면역 체계 유형과 HIV 서열을 확인합니다. 이때 바로 수치 처리가 필요합니다. 3천 가지 HIV 아미노산과 수천 명의 환자에게서 채취한 수백 가지 면역 체계 유형을 조사해야 하기 때문입니다. Microsoft의 연구용 소프트웨어 개발 책임 엔지니어인 Carl Kadie 박사는 "가양성이나 가음성을 최대한 줄이고 정확한 상관 관계를 밝혀내기 위해 통계적 테스트 방법을 고안했습니다. 하지만 이러한 테스트에는 강력한 계산 성능이 필요하며, 결과의 정확성을 높이려면 테스트 대상을 최대한 많이 확보해야 합니다. 수백만 가지 시뮬레이션을 실행하여 가장 신뢰할 만한 상관 관계를 밝혀내는 것이죠"라고 설명합니다.

HPC를 활용한 HIV 치료법 개발
몇 년 전만 해도 프로세싱 성능의 제한 때문에 연구가 지연되는 경우가 많았습니다. 이 프로젝트에 참여한 Microsoft 연구원들도 대여섯 대의 컴퓨터 만으로는 처리 성능이 부족하여 제시간 내에 분석을 수행하기 어렵다는 것을 알게 되었습니다. 표본이 200개에 불과한 경우에도 백신의 게놈에서 모든 위치를 살펴보고 다양한 면역 체계를 분석하는 데에만 꼬박 1년이 걸릴 형편이었으니까요. 이 분석에만 사용할 전용 컴퓨터 20대가 있다고 해도 각 20대의 컴퓨터에 나누어 직접 테스트를 실행해야 한다는 기본적인 문제에 봉착하게 됩니다. 즉, 20가지 결과 집합이 산출되면 다른 프로그램을 사용하여 개별 결과 집합을 규합하는 데 또 많은 시간을 투자해야 합니다. 그 과정에서 여러 작업을 관리하고 부분적인 출력을 수집하는 등의 관련 개별 작업에도 상당한 시간이 소요됩니다. 이러한 이유로 연구원들은 Microsoft의 HPC(고성능 컴퓨팅) 부서에 도움을 요청했습니다.
2006년, 연구원들은 Windows® Compute Cluster Server 2003을 구현했습니다. 이 HPC 솔루션을 사용하면 함께 작동하는 컴퓨터 여러 대의 성능을 쉽게 활용할 수 있습니다. 간단히 말해 Windows Compute Cluster Server는 작업을 병렬로 실행되는 여러 서버 노드에 분산해 주는 솔루션으로, 노드에 데이터를 분산하고 데이터를 관리하고 결과를 통합하는 모든 작업을 자동화합니다. 또한 설치 절차, 다양한 관리 도구, 통합 작업 스케줄러도 솔루션에 포함되어 있습니다.
무엇보다 이 솔루션을 통해 컴퓨터 성능의 한계를 해결하고 작업 분산 및 데이터 관리 프로세스를 자동화함으로써 가장 중대한 기술적 장애를 극복할 수 있었습니다.

설치
Microsoft Research로서는 계산 클러스터 방식이 최적이었습니다. Windows Compute Cluster Server 2003은 동일한 작업을 반복 수행하는 응용 프로그램과 관련된 프로젝트에 적합합니다. 작업을 병렬로 실행함으로써 문제 해결 및 분석 과정을 가속화할 수 있는 프로젝트가 대표적인 예입니다. 그러나 고성능 컴퓨팅에는 특히 전력 및 냉각과 관련하여 막대한 비용이 소요될 수 있으므로 이러한 솔루션을 배포하는 것은 간단한 문제가 아닙니다. 일주일 내내 CPU 사용률이 100%인 상태로 실행되는 경우가 빈번한 여러 서버에 배포해야 하니까요.
다음 단계로 조직에 설치 가능한 클러스터의 규모와 설치 장소를 결정해야 합니다. Active Directory®를 사용하는 Windows 기반 환경이 이미 구성되어 있다면 관리자가 클러스터를 설치, 배포 및 지원하는 데 필요한 인프라를 갖춘 셈입니다. 그러나 Active Directory를 사용하지 않는 환경의 경우에는 추가 구성 단계가 필요합니다.
컴퓨터 클러스터 내에 노드를 제공하는 방법, 즉 Windows Compute Cluster Server 2003에 포함된 도구를 사용할지, 아니면 사내 개발 기술을 이용할지도 결정해야 합니다. Windows Compute Cluster Server 2003 자체는 클러스터에서 실행해야 할 소프트웨어 응용 프로그램 중 하나입니다. 또한 사용자가 솔루션에 포함된 그래픽 UI 또는 명령줄 인터페이스를 통해 클러스터에 연결하여 작업을 전송할 수 있도록 클러스터에 대한 사용자 액세스도 구현해야 합니다.
Windows Compute Cluster Server 2003은 64비트 운영 체제입니다. Windows Compute Cluster Server 2003 환경의 일반적인 아키텍처는 그림 1에 나와 있는 것과 같습니다. 이 칼럼을 작성하는 2007년 6월 현재, Microsoft Research는 IBM eServer 326 서버 25대에 구축된 클러스터에서 여러 가지 프로그램을 실행하고 있습니다. 그리고 각 서버에는 2개의 AMD Opteron 프로세서가 2.6GHz의 처리 속도로 작동합니다.
그림 1 Windows Compute Cluster Server 2003을 통한 성능 활용
그림 1 Windows Compute Cluster Server 2003을 통한 성능 활용
Windows Compute Cluster Server를 배포한 후에는 클러스터에서 유전적 상관 관계 분석을 실행하는 데 사용할 응용 프로그램을 업데이트했습니다. 계산 클러스터에 응용 프로그램을 배포하는 과정의 복잡성은 경우에 따라 다를 수 있습니다. 이러한 응용 프로그램은 필요한 프로그래밍 작업의 양에 영향을 미칩니다.
우선 팀에서는 Windows Compute Cluster Server에서 기본 제공하는 도구를 사용하여 일반 UI를 빠르게 구현했습니다. 이는 실질적으로 간단한 수정 작업에 지나지 않았고, 이후 팀에서는 곧 자체 사용자 지정 웹 응용 프로그램을 만들었습니다. 이 응용 프로그램으로 유연성을 높이고 Microsoft 외부에 있는 과학자들에게 일부 클러스터 노드를 제공하는 옵션을 지원할 수 있게 되었습니다. 뿐만 아니라 Open Grid Forum에 참여하고 있는 Microsoft는 Microsoft Research 클러스터 중 일부를 전세계 여러 대학의 사용자에게 공개하여 연구원들이 공동 작업을 수행하고 작업을 공유하는 데 이용하도록 했습니다.
Windows Compute Cluster Server는 그래픽 UI 외에 명령줄 작업도 지원하기 때문에 사용자가 스크립트를 작성할 수 있습니다. 또한 Windows Compute Cluster Job Scheduler(작업 스케줄러)와 직접 상호 작용하도록 프로그램을 작성할 수 있는 다양한 API도 제공합니다. 이는 Microsoft Research에서 선택한 기법이기도 합니다.

결과 산출
고성능 컴퓨팅을 활용한 덕분에 Microsoft Research의 eScience 팀은 HIV 백신 개발 프로젝트에서 순조로운 진척을 보이고 있습니다. Heckerman은 "고성능 컴퓨팅을 활용하면서 분석 시간이 크게 줄었습니다. 저희와 함께 일하는 몇몇 외부 팀에서도 이제 이러한 통계적 기법을 활용하여 그 연구 결과를 공유하고 있습니다. 그 결과 과학자들은 이미 저희가 테스트할 새로운 가설을 얻어냈습니다. 이전에는 프로세스의 모든 단계에서 결과를 얻는 데 1년씩 걸리곤 했지만 이제 하루 만에 끝낼 수 있습니다"라고 성과를 소개했습니다.
Windows Compute Cluster Server를 도입하기 전, Microsoft Research에서 사용한 방법은 분석 수행에 막대한 시간이 소요되었으므로 실용성이 없었습니다. Kadie의 설명에 따르면 Windows Compute Cluster Server를 사용할 경우 이전에는 한 개의 작업을 실행하던 시간에 2만 개의 작업 항목이 포함된 50개 작업을 실행할 수 있습니다.
이제 eScience 팀은 막대한 계산 성능을 활용하여 시뮬레이션된 데이터에 대해 수많은 횟수의 테스트를 수행할 수 있게 되었습니다. 시뮬레이션된 데이터에 대한 테스트 실행 횟수는 실제 데이터에 대한 결과 중 의미 있는 결과를 찾는 데 중요합니다. 즉, 시뮬레이션을 많이 수행할수록 결과의 신뢰도가 높아집니다.

교훈
Microsoft Research는 Windows Compute Cluster Server 사용을 통해 확실한 효과를 얻었지만 사실 둘은 공생 관계라고 할 수 있습니다. Windows Compute Cluster Server의 차기 버전을 개발 중인 고성능 컴퓨팅 팀의 개발자들은 eScience 팀에서 제공한 피드백을 통해 지속적으로 개선 사항을 파악하고 있습니다.
구체적으로 살펴보자면, HPC 팀은 Microsoft Research 클러스터의 동작을 모니터링하고 분석하면서 여러 사용자에게 균등하게 클러스터의 리소스를 분배하는 최적의 방법을 결정하는 데 필요한 리소스 할당 관련 정보를 얻을 수 있었습니다. 예를 들어 이 프로젝트에서 대개 사용자는 한 번에 작업을 하나씩 만들게 됩니다. 그리고 각 작업은 평균 50개의 하위 작업 항목으로 이루어집니다. 사용자가 작업을 전송하면 Windows Compute Cluster 작업 관리자가 50개 하위 작업 항목을 모두 관리하는 데 필요한 리소스를 할당합니다. 이를 위해 작업 관리자는 작업이 전송되는 즉시 작업 항목을 수행할 클러스터에서 사용 가능한 모든 노드를 확보합니다. 단일 사용자 환경의 경우 이러한 시나리오에서도 문제가 발생하지 않지만 프로젝트를 동시에 진행해야 하는 다중 사용자 환경에서는 문제가 됩니다.
현재는 특정 작업의 50개 작업 항목 중 10개가 완료되더라도 10개의 서버가 가용 상태로 해제되지는 않습니다. 작업 관리자는 작업의 50개 하위 작업 항목이 모두 완료될 때까지 기다린 후 다른 작업을 실행할 수 있도록 서버를 해제합니다. 때문에 HPC 개발자들은 전체 작업이 아니라 각 하위 작업 항목이 완료될 때마다 리소스를 다시 할당하는 방법을 찾고 있습니다.
Microsoft Research에서는 연구원들이 원하는 Windows Compute Cluster Server 사용 방식과 관련해서만 발생하는 특정 문제도 HPC 팀이 해결해 줄 것으로 기대하고 있습니다. 단적인 예로, 연구원들은 웹 프런트 엔드에서 계산 클러스터로 사용자 자격 증명이 자동으로 전파되는 보안 설정을 원합니다. 이 문제는 사용자가 작업을 전송할 때마다 웹 응용 프로그램이 클러스터 노드에 모든 권한이 있는 사용자 자격 증명을 제공할 수 있도록 Microsoft® .NET Framework에서 ASP.NET 폼 인증을 확장하는 방법으로 해결했습니다.
현재 Microsoft Research에서 일하는 eScience 팀원과 전 세계의 연구원들은 프로젝트에서 가장 중요한 부분에만 전념하고 데이터 처리 및 관리와 관련한 작업은 모두 컴퓨터에 일임하고 있습니다. Heckerman은 이에 대해 다음과 같이 평가했습니다. "그 결과 팀의 프로젝트 진행을 가속화할 수 있게 되었습니다. 현재 한정적으로만 밝혀진 HIV에 대한 지식의 폭을 넓혀 이 질병의 퇴치라는 목표를 향한 큰 진척을 이루고 있습니다."

Kristin Firth와 Mia Matusow는 현재 Blue Line Writing & Editing에서 일하고 있으며, 지난 10년 동안 세 개 대륙에 걸쳐 다양한 공공기관 및 사기업을 대상으로 전략 콘텐츠를 작성해 왔습니다.


 Windows PowerShell: 정규식 작성
Windows PowerShell
정규식 작성
Don Jones

192.168.4.5. \\Server57\Share. johnd@contoso.com. 이 세 항목이 IP 주소, UNC(범용 명명 규칙) 경로, 그리고 전자 메일 주소라는 사실을 모르는 독자는 없겠죠. 뇌에서 각각의 형식을 인지하는 것입니다. 네 부분으로 이루어진 숫자, 백슬래시, @ 기호 및 기타 형식이 이 문자열이 어떤 데이터를
나타내는지 말해 줍니다. 그리고 조금만 생각해보면 192.168만으로는 유효한 IP 주소가 아니고, 7\\Server2\\Share가 유효한 UNC가 아니고, joe@contoso가 유효한 전자 메일 주소가 아니라는 사실도 쉽게 알 수 있습니다.
안타깝게도 컴퓨터의 경우 이렇게 복잡한 형식을 "이해"하려면 다소 노력이 필요합니다. 이때 바로 정규식이 필요한 것입니다. 정규식은 특수한 정규식 언어를 사용하여 작성된 문자열로, 컴퓨터에서 IP 주소, UNC 또는 전자 메일 주소와 같은 특정 형식의 문자열을 식별하는 데 사용됩니다. 잘 작성된 정규식은 Windows PowerShellTM 스크립트에서 유효한 데이터를 수락하거나 지정한 형식에 맞지 않는 잘못된 데이터를 거부하도록 할 수 있습니다.

간단한 match 만들기
Windows PowerShell –match 연산자는 문자열을 정규식(또는 regex)과 비교한 다음 문자열이 정규식과 일치하는지 여부에 따라 True 또는 False를 반환합니다. 아주 간단한 정규식의 경우 특수한 구문을 사용할 필요 없이 리터럴 문자만으로도 충분합니다. 예를 들면 다음과 같습니다.
"Microsoft" –match "soft"
"Software" –match "soft"
"Computers" –match "soft"
첫 번째 식을 Windows PowerShell에서 실행하면 True가 반환되고 세 번째 식을 실행하면 False가 반환됩니다. 각각의 식은 문자열, –match 연산자, 정규식으로 이루어져 있습니다. 기본적으로 정규식은 문자열을 따라 흐르듯이 일치하는 결과를 찾습니다. "soft"라는 문자열은 Software와 Microsoft에 모두 포함되어 있지만 위치가 다릅니다. 또한 기본적으로 정규식에서는 대/소문자가 구분되지 않습니다. 따라서 대문자 S로 시작하는 "Software"에서도 "soft"가 검색됩니다.
필요에 따라 다음과 같이 –cmatch 연산자를 사용하여 대/소문자를 구분하는 정규식을 작성할 수 있습니다.
"Software" –cmatch "soft"
이 식의 경우 대/소문자를 구분하므로 "soft"가 "Software"에서 검색되지 않아 False가 반환됩니다. 대/소문자를 구분하지 않는 명시적인 옵션으로 –imatch 연산자를 사용할 수도 있습니다(–match의 기본 동작과 동일).

와일드카드 및 반복기
정규식에는 와일드카드 문자를 몇 개 사용할 수 있습니다. 예를 들어 마침표는 한 문자를 나타내고 물음표는 문자가 없거나 하나 있는 경우를 나타냅니다. 다음은 몇 가지 예제입니다.
"Don" –match "D.n" (True)
"Dn" –match "D.n" (False)
"Don" –match "D?n" (True)
"Dn" –match "D?n" (True)
첫 번째 식에서 마침표는 한 문자만 나타내므로 검색 결과가 True가 됩니다. 두 번째 식의 경우 마침표에 해당하는 한 문자가 없으므로 검색 결과가 False가 됩니다. 세 번째와 네 번째 식에서 보듯이 물음표는 알 수 없는 문자 하나 또는 문자가 없는 경우에 해당합니다. 마지막으로, 네 번째 식에서는 "D"와 "n"이 모두 있고 그 사이에 문자가 없으므로 결과가 True가 됩니다. 즉, 물음표는 선택적인 문자를 나타내는 데 사용할 수 있으므로 해당 위치에 문자가 없더라도 결과가 True가 됩니다.
또한 정규식에서는 * 및 + 기호가 반복기로 인식됩니다. 이러한 반복기는 하나 이상의 특정 문자 뒤에 사용해야 합니다. *는 0개 이상의 지정된 문자를 나타내고, +는 하나 이상의 지정된 문자를 나타냅니다. 다음은 몇 가지 예제입니다.
"DoDon" –match "Do*n" (True)
"Dn" -match "Do*n" (True)
"DoDon" -match "Do+n" (True)
"Dn" -match "Do+n" (False)
*와 +는 모두 "o"만이 아니라 "Do"를 검색합니다. 이러한 반복기는 특정 문자가 아니라 일련의 문자를 검색하기 때문입니다.
마침표, *, ? 또는 + 기호 자체를 검색할 경우에는 어떻게 해야 할까요? 이 경우 해당 기호 앞에 정규식 이스케이프 문자인 백슬래시를 추가하면 됩니다.
"D.n" -match "D\.n" (True)
이는 Windows PowerShell 이스케이프 문자(역아포스트로피)와는 다르지만 업계 표준 정규식 구문을 따릅니다.

문자 클래스
문자 클래스는 전체 문자 그룹을 나타내는 확장된 형태의 와일드카드입니다. Windows PowerShell에서는 다음과 같은 몇 가지 문자 클래스가 인식됩니다.
  • \w는 문자 및 숫자를 포함한 모든 단어 문자를 나타냅니다.
  • \s는 탭, 공백 등의 모든 공백 문자를 나타냅니다.
  • \d는 모든 숫자를 나타냅니다.
부정 문자 클래스도 있습니다. 예를 들어 \W는 모든 비단어 문자를, \S는 비공백 문자를, \D 비숫자 문자를 나타냅니다. 이러한 클래스 뒤에는 복수의 검색 결과가 허용됨을 나타내는 * 또는 +를 사용할 수 있습니다. 다음은 몇 가지 예제입니다.
"Shell" -match "\w" (True)
"Shell" -match "\w*" (True)
이달의 Cmdlet
Write-Debug cmdlet는 Debug 파이프라인에 텍스트 문자열과 같은 개체를 작성하는 데 매우 유용합니다. 그러나 셸에서 이 cmdlet를 사용하면 별다른 효과가 없는 것처럼 보이기 때문에 다소 실망스러울 수 있습니다.
그 이유는 Debug 파이프라인이 기본적으로 차단되기 때문입니다. 즉, $DebugPreference 변수가 "SilentlyContinue"로 설정됩니다. 이 변수를 "Continue"로 설정하면 Write-Debug를 사용하여 전송하는 내용이 모두 콘솔에서 노란색 텍스트로 나타납니다. 복잡한 스크립트의 실행 상태를 추적할 수 있도록 스크립트에 추적 코드를 추가할 때에는 이보다 좋은 방법이 없습니다. 노란색은 추적된 내용과 스크립트의 일반 출력을 서로 구분하는 데 도움이 되며, 언제든지 Write-Debug 문을 모두 제거하지 않고도 디버그 메시지를 숨길 수 있습니다. 즉, $DebugPreference = "SilentlyContinue"로 다시 설정하면 디버그 텍스트가 사라집니다.

두 식은 모두 True를 반환하지만 검색되는 내용은 크게 다릅니다. 다행히 검색 결과가 발견될 때마다 $matches라는 변수에 검색 결과가 채워지므로 –match 연산자의 작동 상태를 확인할 수 있습니다. 다시 말해 정규식에 따라 연산자에 의해 검색된 문자열의 문자가 모두 이 변수로 보내집니다. $matches 변수는 –match 연산자를 사용하여 다른 정의 검색 결과가 발견될 때까지 결과를 유지합니다. 그림 1은 방금 살펴본 두 식의 차이점을 보여 줍니다. 여기서 보듯이 \w는 "Shell"에서 "S"에 해당하고 \w*는 전체 단어에 해당합니다.
그림 1 *의 기능
그림 1 *의 기능

문자 그룹, 범위 및 크기
정규식에는 문자의 그룹 또는 범위를 대괄호로 묶어 사용할 수 있습니다. 예를 들어 [aeiou]는 a, e, i, o 또는 u 중 해당하는 문자를 모두 검색합니다. [a-zA-Z]는 a-z 또는 A-Z 사이의 문자를 모두 검색합니다. 대/소문자를 구분하지 않는 –match 연산자를 사용하더라도 a-z 또는 A-Z 자체로도 대/소문자가 구분됩니다. 예를 들면 다음과 같습니다.
"Jeff" -match "J[aeiou]ff" (True)
"Jeeeeeeeeeeff" -match "J[aeiou]ff" (False)
중괄호를 사용하여 최소 문자 수 또는 최대 문자 수를 지정할 수도 있습니다. {3}은 지정한 세 문자만 정확히 검색하라는 의미이고, {3,}은 문자를 3개 이상 검색하라는 의미이며, {3,4}는 3개 이상 4개 이하로 검색하라는 의미입니다. 이는 IP 주소를 검색하는 정규식을 만드는 데 적합합니다.
"192.168.15.20" -match "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" (True)
이 정규식은 각각 1-3개의 숫자로 이루어지고 서로 리터럴 마침표로 구분된 4개의 숫자 그룹을 검색합니다. 그런데 다음 예제를 살펴보십시오.
"300.168.15.20" -match "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" (True)
이 예제는 정규식의 한계를 보여 줍니다. 즉, 이 문자열의 형식은 IP 주소처럼 보이지만 유효한 IP 주소가 아닙니다. 정규식은 데이터가 실제로 유효한지를 확인하지는 못하고 데이터의 형식이 올바른지만 확인합니다.

흐르지 않게 하기
정규식과 관련한 문제는 해결하기가 까다로울 수 있습니다. 예를 들어 \\Server2\Share라는 형식의 UNC 경로를 테스트하는 다음 정규식을 살펴보십시오.
"\\Server2\Share" -match "\\\\\w+\\\w+" (True)
여기서 테스트할 모든 리터럴 백슬래시는 다른 백슬래시로 이스케이프해야 하므로 정규식 자체를 읽기가 어렵습니다. 제대로 작동할 것 같지만 사실은 그렇지 않습니다.
"57\\Server2\Share" -match "\\\\\w+\\\w+" (True)
우리는 이 두 번째 예제가 유효한 UNC 경로가 아니라는 것을 쉽게 알 수 있지만 정규식에서는 유효한 것으로 나타납니다. 이유가 무엇일까요? 정규식은 기본적으로 흐르듯이 실행됩니다. 이 정규식은 2개의 백슬래시, 하나 이상의 문자와 숫자, 다른 백슬래시, 그리고 추가 문자와 숫자를 검색할 뿐입니다. 해당 문자열에는 이러한 패턴이 존재하지만 앞에 불필요한 숫자가 더 있으므로 유효한 UNC가 아닙니다. 이러한 문제를 해결하려면 문자열을 따라 흐르듯이 검색하지 않고 문자열의 시작 부분에서 검색을 시작하도록 해야 합니다. 이를 위해서는 다음과 같이 작성하면 됩니다.
"57\\Server2\Share" -match "^\\\\\w+\\\w+" (False)
^ 문자는 문자열이 시작되는 위치를 나타냅니다. 이 문자를 추가하면 정규식이 처음 두 문자가 백슬래시인 문자열을 찾으므로 이 경우와 같이 잘못된 UNC 경로는 검색되지 않습니다.
이와 유사하게 $ 기호를 사용하여 문자열의 끝을 나타낼 수 있습니다. UNC 경로에는 \\Server2\Share\Folder\File과 같이 경로 부분이 추가될 수 있으므로 이 문자가 그다지 유용하지 않습니다. 그러나 문자열의 끝을 지정해야 하는 경우는 수도 없이 많습니다.

정규식 관련 도움말
Windows PowerShell의 about_regular_expressions 도움말 항목에 정규식 언어에 대한 기본 구문 설명이 나와 있지만 온라인 리소스를 통해 보다 자세한 정보를 얻을 수 있습니다. 예를 들어 필자가 애용하는 www.RegExLib.com 웹 사이트에는 다양한 용도로 작성된 무료 정규식 라이브러리가 공개되어 있습니다. 이 사이트에서 "e-mail" 또는 "UNC"와 같은 키워드를 검색하면 필요에 맞는 정규식이나 필요한 정규식을 만드는 기반으로 사용할 정규식을 쉽게 찾을 수 있습니다. 뛰어난 정규식을 작성했다면 다른 사람들이 이용하도록 라이브러리에 게시할 수도 있습니다.
RegexBuddy(www.RegexBuddy.com)도 필자가 즐겨 사용하는 리소스입니다. 이 저렴한 도구는 그래픽 정규식 편집기를 제공합니다. RegexBuddy를 사용하면 복잡한 정규식을 쉽게 작성할 수 있을 뿐만 아니라, 정규식이 제대로 유효한 문자열을 허용하고 잘못된 문자열을 거부하는지 테스트할 수 있습니다. 다른 소프트웨어 개발자들도 무료 소프트웨어, 쉐어웨어 또는 상용으로 사용자에게 유용한 정규식 편집기와 테스터를 제공하고 있습니다.

정규식 사용
정규식이 실용성이 있는지 의문을 가질 수도 있습니다. CSV 파일에서 정보를 읽어 Active Directory®에 새 사용자를 만드는 데 사용한다고 생각해 보십시오. 다른 사람이 CSV 파일을 작성했다면 들어 있는 데이터의 형식이 올바른지 확인해야 할 수 있습니다. 이 작업에는 정규식이 이상적입니다. 예를 들어 \w+와 같은 간단한 정규식으로도 첫 번째 이름과 마지막 이름에 특수 문자 또는 기호가 없는지를 확인할 수 있으며, 조금 더 복잡한 정규식을 사용하면 전자 메일 주소가 회사 표준에 맞는지도 확인할 수 있습니다. 예를 들어 다음과 같은 정규식을 사용할 수 있습니다.
"^[a-z]+\.[a-z]+@contoso.com$"
이 정규식은 don.jones@contoso.com의 전자 메일 주소만 검색합니다. 여기서 첫 번째 이름과 마지막 이름에는 문자만 포함될 수 있고, 각 이름은 마침표로 구분되어야 합니다. 전자 메일 주소에 대한 정규식은 작성하기가 가장 까다롭습니다. 그러나 특정 회사 표준에 맞도록 범위를 한정하면 작성하기가 수월해집니다.
contoso.com 뒤에는 문자가 없고 사용자의 이름에 해당하는 문자 앞에는 다른 문자가 없음을 나타내는 시작 앵커와 끝 앵커(^ 및 $)를 잊어서는 안 됩니다.
사실 Windows PowerShell에서 정규식은 어렵지 않게 사용할 수 있습니다. $email 변수에 CSV 파일에서 읽은 전자 메일 주소가 들어 있다면 다음과 같은 정규식으로 해당 주소가 유효한지 여부를 확인할 수 있습니다.
$regex = "^[a-z]+\.[a-z]+@contoso.com$"
If ($email –notmatch $regex) {
  Write-Error "Invalid e-mail address $email"
}
이 예제에는 -notmatch라는 새로운 연산자가 사용되었습니다. 이 연산자는 문자열이 제공한 정규식과 일치하지 않는 경우 True를 반환합니다. 또한 대/소문자를 구분하여 검색하는 –cnotmatch 연산자도 사용되었습니다.
추가 문자 클래스, 고급 연산자, 한두 가지 다른 연산자 등 정규식과 관련하여 이 기사에서 다루지 않은 내용도 많습니다. 또한 Windows PowerShell에서는 [regex]라는 개체 형식도 지원됩니다. 그러나 정규식을 처음 접하는 독자에게는 여기서 대략적으로 다룬 내용만으로도 충분하리라 믿습니다. 매우 어려운 정규식 관련 문제에 봉착한 경우 언제라도 www.ScriptingAnswers.com을 방문해 주십시오.

Don Jones는 TechNet Magazine의 객원 편집자이자 Windows PowerShell: TFM(SAPIEN Press)의 공동 저자입니다. Windows PowerShell(www.ScriptingTraining.com) 강사이기도 한 그는 ScriptingAnswers.com 웹 사이트를 통해 연락할 수 있습니다.


 Hey, Scripting Guy!: 무덤에서 일어난 데스크톱 관리
Hey, Scripting Guy!
무덤에서 일어난 데스크톱 관리
Microsoft Scripting Guys
이 기사의 코드 다운로드: HeyScriptingGuy2007_09.exe (151KB)

압도적인 대중의 요구에 따라 우리는 이번 달에는 좀 색다른 일을 할 수 있겠다고 생각했습니다. 시스템 관리 스크립팅에 관한 논의 대신 - 음산한 음악 넣어주시고 - 귀신 이야기로 시작해보고자 합니다.
참고로, 그래요. 물론 굳이 말하자면 이번 달에 우리가 진짜로 좀 다르게 해보겠다면 평소와 달리 진지하게 실제 시스템 관리 스크립팅에 관한 설명으로 들어가야겠지만, 그냥 평소 하던 대로 가는 게 낫겠죠? 감사합니다!
오랜 옛날, 스크립팅계의 몇 대조뻘 되는 할머니께서 타계하셨습니다. 할머니가 검소한 목관에 안치된 직후부터 할아버지는 사랑스러운 아내가 무덤 밖으로 나오려고 필사적으로 애쓰는 끔찍한 악몽에 시달리게 되었습니다. 반복되는 악몽과 여러 번의 탄원을 거쳐 할아버지는 마침내 지역 관계 당국에 시신 발굴을 설득시켰습니다. 관을 열어 본 사람들은 할머니의 손톱이 뒤쪽으로 구부러져 있고 관 안쪽이 온통 할퀸 자국으로 덮여 있는 것을 보고 오싹해졌습니다!
그렇습니다. 이 이야기는 완전한 사실이 아닐 수도 있습니다. 사실 생각하면 할수록 사실에 가까운 부분이 거의 없다는 것을 알 수 있습니다. 그럼에도 불구하고 이 이야기는 중요한 교훈을 담고 있습니다. 그 내용은 잘 모르겠는데 이 이야기 어딘가에는 그 교훈이 있습니다.
잠깐, 이제 기억이 나네요! 관은 본디 자연 작용으로부터 고인을 보호하고 시신의 부패를 방지하기 위해 만들어진 것입니다. 그러나 공교롭게도 관은 의도하지 않은 결과를 초래하였습니다. 적어도 이론적으로는 사람을 산 채로 묻어서 절대 빠져나오지 못하게 할 수도 있는 것입니다. 스크립팅계 몇 대조 할머니의 이야기가 확실히 보여주듯이, 신이 아닌 이상 아무리 잘 짜여진 계획이라도 생매장처럼 의도하지 않은 사태를 낳을 수 있다는 것입니다(음산한 음악 한 번 더).
참고로, 1860년대에 Franz Vester가 고안안 개량식 관(Improved Burial Case)을 택할 수도 있겠습니다. 이 관에는 끈이 하나 들어 있는데 이 끈은 땅 위의 벨에 연결되어 있어서 혹시나 생매장이 이루어졌을 경우 '망자'가 벨을 울려 도움을 청할 수 있게 되어 있습니다. 이 개량식 관에는 접이식 사다리도 들어 있었는데, 땅 아래로 6피트 깊이에 묻혀 있는 관에서 탈출하는 데 접이식 사다리가 어떻게 도움이 될 것인지는 저희도 잘 모르겠습니다. 만일 누군가의 차고 위에 묻히게 된다면 접이식 사다리가 도움이 될 수도 있겠지만, 그게 아니라면....
이와 똑같은 교훈, 그러니까 아무리 잘 짜여진 계획도 의도하지 않은 사태를 불러올 수 있다는 교훈은 인터넷 방화벽에서도 그대로 적용됩니다. 일반적으로, 방화벽은 원래 악의적 침입을 막기 위해 고안되었습니다. 방화벽은 네트워크 트래픽의 유입을 차단하여 해커와 침입자가 컴퓨터에 들어오는 것을 막는 데 도움이 됩니다. 그 자체로는 훌륭합니다. 그러나 생매장의 문제와 마찬가지로, 여기서도 의도하지 않은 결과가 발생합니다. 방화벽은 문제가 없는 트래픽도 차단합니다. 이것은 DCOM을 이용하여 원격 컴퓨터에서 관리 작업을 수행하는 WMI(Windows® Management Instrumentation)의 경우에 특히 두드러집니다. 방화벽은 유입되는 모든 DCOM 트래픽을 차단하기 때문에 컴퓨터를 인터넷을 통해 프로그램 방식으로 관리하는 것을 (완전히 불가능하지는 않더라도) 매우 어렵게 합니다. 사실 방화벽에서 추가로 포트를 열어 해커와 크래커의 공격에 더 취약한 상태가 되지 않고서는, 그것은 절대 불가능합니다. 물론, WinRM(Windows 원격 관리)(접이식 사다리는 없음)을 사용할 수 있습니다.

Windows 원격 관리(WinRM)란 무엇일까요?
WinRM SDK(msdn2.microsoft.com/aa384426)에 따르면 WinRM이란 "서로 다른 업체에서 제공한 운영 체제와 하드웨어의 호환을 가능케 하는 방화벽 친화적인 표준 SOAP 기반 프로토콜인 WS 관리 프로토콜을 Microsoft식으로 구현한 것"입니다. 멋있지 않습니까? 이번 달 칼럼에서는 WS 관리 프로토콜을 자세히 다루지 않을 것이므로 상세한 내용이 궁금하시면 WinRM SDK를 읽어보시기 바랍니다. 현재 우리가 관심을 갖는 것은 오로지, WinRM을 Windows Server® 2003 R2, Windows Vista®, Windows Server 2008에서 사용할 수 있다는 점, 그리고 그것이 인터넷을 통해 컴퓨터를 관리할 수 있게 한다는 점입니다. WinRM은 대부분의 방화벽에서 열어두는 표준 인터넷 서비스 포트인 포트 80을 이용해서 이러한 기능을 제공합니다. 그러나 WinRM에서 사용하는 포트와 기본 전송 메커니즘인 HTTP는 필요에 따라 변경할 수 있습니다.
이번 칼럼에서는 또한 WinRM의 설치와 구성 방법의 설명에도 시간을 들이지 않겠습니다. 그에 관해서는 이미 충분한 정보가 제공되어 있습니다(msdn2.microsoft.com/aa384372). 그러나 한 가지 중요한 사항은 잠시 강조하고 넘어가야겠습니다. WinRM을 이용하여 원격 컴퓨터에서 정보를 불러오려면(물론, 이것이 WinRM을 사용하는 가장 우선적인 이유임), 로컬 컴퓨터와 원격 컴퓨터 양쪽에서 WinRM이 실행되어야 합니다.
이것이 의미하는 바가 무엇일까요? 즉, 여러분이 아직 클라이언트 컴퓨터를 Windows Vista로 업그레이드하지 않았거나(그렇지 않다고 말해주세요!), 서버를 Windows Server 2003 R2 또는 Windows Server 2008로 업그레이드하지 않았다면 WinRM은, 최소한 현재까지는, 그다지 실용성이 없다는 것입니다. 그러나 말할 필요도 없이 앞으로는 그렇지 않을 것입니다. 그리고 물론, 방화벽에서 허용하는 것으로 가정한다면 언제든 WMI와 DCOM을 이용하여 원격 컴퓨터를 관리할 수 있습니다.

클래스의 모든 속성과 인스턴스의 반환
그러나 면책 조항을 누가 다 일일이 신경 쓰겠습니까? 알 수 없는 어려운 법률 용어들은 뒤로 하고, WinRM을 활용하는 스크립트의 작성 방법을 우리가 파악할 수 있는지만 살펴봅시다. 우연히도 때마침, HTTP 프로토콜과 포트 80을 사용하여 atl-fs-01.fabrikam.com이라는 컴퓨터에 접속한 다음, 그 컴퓨터에 설치된 모든 서비스에 대한 모든 정보를 반환하는 작고 간단한 스크립트를 갖게 되었다고 합시다. 그림 1에서 이 스크립트의 아름다운 면모를 감상할 수 있겠습니다.
Figure 1 Silverlight 프로젝트 구성 요소 (Close Figure 1)

파일 | 설명
CreateSilverlight.js | 사용자 인터페이스와 그래픽 개체의 구성에 사용되는 XAML 파일 등을 비롯하여, 초기 Silverlight 시작 설정을 지정하는 데 사용되는 JScript 스크립트(Silverlight 초기 릴리스에서는 JScript 스크립트만 지원)입니다.
SampleProject.js | JScript 함수를 넣을 수 있는 빈 파일입니다.
Silverlight.js | Silverlight 컨트롤을 초기화할 때 사용되는 파일입니다.
SampleProject.html | 모든 효과가 이루어지는 곳입니다. SampleProject.html은 세 .js 파일에서 읽을 코드가 들어 있는 단순한 HTML 파일입니다. 또한 Silverlight 컨트롤을 인스턴스화하는 코드도 들어 있습니다.
SampleProject.xaml | 이 파일은 어디에 사용될까요? 알고 싶다면 이 칼럼을 다시 읽어 보십시오.
Figure 1 원격 컴퓨터의 서비스 목록 표시 (Close Figure 1)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service"

Set objResponse = objSession.Enumerate(strResource)

Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop

Sub DisplayOutput(strWinRMXml)
    Set xmlFile = CreateObject("MSXml2.DOMDocument.3.0")
    Set xslFile = CreateObject("MSXml2.DOMDocument.3.0")
    xmlFile.LoadXml(strWinRMXml)
    xslFile.Load("WsmTxt.xsl")
    Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
그림에서 알 수 있듯이 우선 컴퓨터의 DNS 이름(atl-fs-01.fabrikam.com)을 strComputer라는 변수에 할당하는 것부터 시작하겠습니다. 아니면 컴퓨터의 IP 주소를 사용해서 (또는 그 IPv6 주소를 사용해서라도) 연결을 구성할 수 있겠습니다. 예를 들면 다음과 같습니다.
strComputer = "192.168.1.1"
strComputer에 값을 할당한 후 WSMan.Automation 개체의 인스턴스를 만든 다음, CreateSession 메서드를 호출하여 원격 컴퓨터에 접속합니다. 이 경우에는 (우리가 그렇게 하겠다고 말한 것처럼) HTTP 프로토콜을 사용합니다.
Set objSession = objWRM.CreateSession _
    ("http://" & strComputer)
앞서 언급했듯이, 우리는 원격 컴퓨터에 설치된 서비스에 관한 정보를 반환하고자 합니다. 또한, 그리고 최소한 이 첫 번째 예에 대해서만큼은 모든 서비스의 모든 속성에 대한 정보를 반환하고자 합니다. 이것이 의미하는 바는 과연 무엇일까요? 그것은 원격 컴퓨터의 Win32_Service 클래스로 바인딩해주는 URI Resource를 명시해야 한다는 것을 의미합니다.
strResource = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/wmi/root/cimv2" & _
  "/Win32_Service"
인정합니다. 그리 보기 예쁜 URI는 아니지요. 하지만 생각해보면 예쁜 URI를 한 번이라도 본 적이 있는지 잘 모르겠군요. 그러나 다행히도 대부분의 URI는 항상 반복되는 동일한 내용으로 되어 있습니다. 맨 마지막의 WMI 경로만 신경 쓰시면 됩니다.
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service
무척 간단합니다. 그런데 root/cimv2/Win32_Process 클래스로 연결하고자 한다면 어떻게 해야 할까요? 그 때는 그에 맞게 URI 경로만 수정해주면 됩니다.
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Process
root/default/SystemRestore 클래스에 관심이 있습니까? 그 경우에도 URI 클래스만 수정하면 되는데, 위의 cimv2 네임스페이스가 아닌 기본(default) 네임스페이스를 지정하도록 유의해야 합니다.
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/default/SystemRestore
그리고 기타 등등... URI의 http://schemas.microsoft.com/wbem/wsman/1/wmi 부분도 넣어야 한다는 것이 다소 유감이지만 그러나,
이 지점에서 일부 데이터를 얻을 준비가 됩니다. 이를 위해서는 Enumerate 메서드를 호출, strResource 변수를 유일한 메서드 매개 변수로서 보내기만 하면 됩니다.
Set objResponse = _
  objSession.Enumerate(strResource)
이 코드는 atl-fs-01 컴퓨터에 설치된 서비스에 대한 정보를 objResponse에 채우게 될까요? 물론입니다. 그러나 다른 표준 WMI 스크립트와 달리 각기 고유의 속성과 속성 메서드를 갖는 일련의 개체를 얻지 못합니다. 대신, 그림 2의 것과 유사한 거대한 XML 덩어리를 얻게 됩니다.
Figure 2 예쁜 색 (Close Figure 2)
<Canvas
 xmlns="http://schemas.microsoft.com/client/2007"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Width="800"
 Height="300">

 <Canvas.Background>
 <LinearGradientBrush>
 <GradientStop Color="Blue" Offset="0.0" />
 <GradientStop Color="Black" Offset="1.0" />
 </LinearGradientBrush>
 </Canvas.Background>

</Canvas>
Figure 2 거대한 XML 덩어리 (Close Figure 2)
<p:Win32_Service xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service" xmlns:ci
m="http://schemas.dmtf.org/wbem/wscim/1/common" xsi:type="p:Win32_Service_Type"
xml:lang="en-US"><p:AcceptPause>false</p:AcceptPause><p:AcceptStop>false</p:Acce
ptStop><p:Caption>Windows Media Center Service Launcher</p:Caption><p:CheckPoint
>0</p:CheckPoint><p:CreationClassName>Win32_Service</p:CreationClassName><p:Desc
ription>Starts Windows Media Center Scheduler and Windows Media Center Receiver
services at startup if TV is enabled within Windows Media Center.</p:Description
><p:DesktopInteract>false</p:DesktopInteract><p:DisplayName>Windows Media Center
XML 전문가라면 그리 큰 문제는 아닙니다. XML에 익숙한 사람이라면 누구라도 큰 어려움 없이 이 정보를 구문 해석해서 결과를 출력할 수 있을 것입니다(그럼에도 불구하고, WinRM SDK의 표현을 빌리자면 이 정보는 '사람이 읽을 수 있는 형식'이 아님). 그런데 XML 전문가가 아닌 경우에는 어떻게 해야 할까요? 그 경우에는 두 가지 선택이 가능합니다. 첫째, 다음 달까지 기다리는 방법입니다. 다음 달에는 저희가 WinRM의 XML을 다루는 몇 가지 트릭을 알려드리겠습니다. 아니면 두 번째 방법으로, 저희가 샘플 스크립트에서 했던 것처럼 WinRM과 함께 설치되는 XSL 변환을 채택하는 것입니다.

XSL 변환이란?
XSL 변환은 XML 파일이 어떻게 표시되어야 하는가를 기술한 템플릿일 뿐입니다. XSL 파일에 대한 모든 내용을 다루려면 이 달 칼럼으로는 형편없이 부족합니다. 실제로, XSL 파일을 피상적으로만 다루려 해도 이 달 칼럼의 분량을 훨씬 넘어설 것입니다. 따라서 WsmTxt.xsl(기본 제공되는 변환의 이름)이 실제로 어떻게 작동하는지는 설명하지 않겠습니다. 대신, 스크립트에서 그 변환을 어떻게 사용할 수 있는지만 보여드리겠습니다.
Enumerate 메서드를 호출하면 WinRM에서는 XML 데이터 스트림을 돌려보냅니다. 이 데이터를 처리하는 가장 쉬운 방법은 데이터 스트림의 끝에 도달할 때까지 계속 실행되는 Do Until 루프를 설정하는 것입니다. 아래 저희가 한 것처럼 말입니다.
Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop
코드에서 볼 수 있듯이, 루프 내부에서 저희는 DisplayOutput이라는 서브루틴을 호출했습니다. 그 서브루틴을 호출할 때 그 스트림의 ReadItem 메서드의 값을 서브루틴 매개 변수로 하여 함께 보냅니다. 이 접근 방식 전체를 통해 알 수 있듯이 XML 스트림은 하나의 큰 데이터 덩어리가 아닌 여러 개로 나뉜 조각으로 반송됩니다. 그러면 우리의 스크립트는 이 XML 데이터를 한 번에 하나의 덩어리 또는 한 품목으로 읽어냅니다.
한편 DisplayOutput 서브루틴은 다음과 같은 형태를 갖습니다.
Sub DisplayOutput(strWinRMXml)
  Set xmlFile = _
    CreateObject("MSXml2.DOMDocument.3.0")
  Set xslFile = _
    CreateObject("MSXml2.DOMDocument.3.0")
  xmlFile.LoadXml(strWinRMXml)
  xslFile.Load("WsmTxt.xsl")
  Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
요약하자면 MSXml2.DOMDocument.3.0 개체의 인스턴스를 2개 만드는 것으로 시작했습니다. 한 개체에 XML 데이터 스트림(strWinRMXML)을 로딩하고 다른 개체에는 XSL 파일(WsmTxt.xsl)을 로딩했습니다. 이 시점에서 TransformNode 메서드를 호출, XSL의 정보를 사용해서 XML 스트림으로부터 포착한 데이터에 형식을 부여하고 표시하도록 했습니다.
그렇죠. 약간은 혼란스럽습니다. 그러나 최소한 그 출력 결과는 (완벽과는 거리가 멀더라도) 다소 읽기 쉽습니다(그림 3 참고).
Figure 3 텍스트 칠하기 (Close Figure 3)
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">

 <TextBlock.Foreground>
 <SolidColorBrush Name="test_brush" Color="red"/>
 </TextBlock.Foreground>

</TextBlock>
Figure 3 좀더 정돈된 형태의 XML (Close Figure 3)
Win32_Service
    AcceptPause = false
    AcceptStop = true
    Caption = User Profile Service
    CheckPoint = 0
    CreationClassName = Win32_Service
    Description = This service is responsible for loading and unloading user profiles. If this service is stopped or disabled, users will no longer be able to successfully logon or logoff, applications may have problems getting to users' data, and components registered to receive profile event notifications will not receive them.
앞서 말했듯이 이 정도라면 괜찮은 편이지만 그리 훌륭하다고 할 수는 없으므로, 우리는 다음 달에 이를 더 다듬어 여러분 혼자 XML 출력을 다룰 수 있는 몇 가지 방법을 보여드리겠습니다.

클래스의 일부 선별된 인스턴스와 속성의 반환
말할 필요도 없이 이것은 단 한가지만 빼고는 매우 멋진 착상입니다. 그것은 여러분의 일반적인 작업 처리 방식을 온전히 반영하는 것이 아닐 수도 있다는 점입니다. 그렇죠, 클래스의 모든 인스턴스의 모든 속성을 반환하고자 할 경우도 있겠지만, 클래스의 일부 속성 또는 인스턴스만 반환하고자 할 경우도 (오히려 더 많이) 있을 수 있습니다. 예를 들어, 정규 WMI 스크립트에서 다음과 유사한 코드를 사용하여 수행하는 것처럼 실행 중인 서비스에 관한 정보만 반환되도록 하고자 할 수 있습니다.
Set colItems = objWMIService.ExecQuery _
  ("Select * From Win32_Service " & _
   "Where State = 'Running'")
멋집니다. 그러나 Resource 문자열을 대체 어떻게 수정해서 그와 동등하게 만들겠습니까?
물론, 완전히 솔직하게 말하자면 ExecQuery 구문과 동등하게 만들기 위해 Resource 문자열을 수정하지는 않을 것입니다. 분명히 Resource 문자열은 수정해야 하겠지만, 다른 일도 몇 가지 해야 할 것입니다.
이 점을 염두에 두고 그림 4을 살짝 살펴보겠습니다. 이것은 어느 컴퓨터에서 실행 중인 서비스(설치된 모든 서비스가 아닌)에 대한 정보를 반환하는 WinRM 스크립트입니다.
Figure 4 TextBlock 트릭 (Close Figure 4)
<TextBlock.Triggers>
 <EventTrigger RoutedEvent=
     "TextBlock.Loaded">
 <BeginStoryboard>
 <Storyboard>
 <DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
 </Storyboard>
 </BeginStoryboard>
 </EventTrigger>
</TextBlock.Triggers>
Figure 4 실행 중인 서비스 찾기 (Close Figure 4)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/*"
strFilter = "Select * From Win32_Service Where State = 'Running'"
strDialect = "http://schemas.microsoft.com/wbem/wsman/1/WQL"

Set objResponse = objSession.Enumerate(strResource, strFilter, strDialect)

Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop

Sub DisplayOutput(strWinRMXml)
    Set xmlFile = CreateObject("MSXml2.DOMDocument.3.0")
    Set xslFile = CreateObject("MSXml2.DOMDocument.3.0")
    xmlFile.LoadXml(strWinRMXml)
    xslFile.Load("WsmTxt.xsl")
    Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
일견 이것은 앞서 보여드린 첫 번째 WinRM 스크립트와 완전히 동일해 보이지만 몇 가지 중요한 차이점이 있습니다. 우선 한 가지로, Resource 문자열에 할당한 값을 살펴보겠습니다.
strResource = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/wmi/root/cimv2/*"
유의할 점은 필터링된 쿼리를 작성할 때는 다루고자 하는 클래스의 실제 이름(Win32_Service)을 명시하지 않고 그 클래스가 있는 네임스페이스(root/cimv2)로 연결하기만 한다는 점입니다. 마지막에 별표(*)를 붙이는 것만 기억하십시오. 그렇게 하지 않으면 스크립트가 오류를 일으키고 "... the class name must be '*' (star)"라는 결과 메시지가 나타납니다. 이것은 단지 클래스 이름을 *로 해야 한다는 것을 의미합니다.
또한 Filter와 Dialect를 정의해야 합니다.
strFilter = _
  "Select * From Win32_Service " & _
  "Where State = 'Running'"
strDialect = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/WQL"
Filter는 이해하기 쉬워야 합니다. 여기에 WQL(Windows Management Instrumentation Query Language) 쿼리("Select * From Win32_Service Where State = 'Running'")를 놓기 때문입니다. 한편 Dialect는 Filter를 만들 때 사용하는 쿼리 언어입니다. 현재로서 허용된 쿼리 언어는 WQL 하나뿐입니다. 그럼에도 불구하고 Dialect는 반드시 명시되어야 하며, 그렇지 않으면 스크립트는 "filter dialect ... is not supported."라는 메시지와 함께 오류를 일으킵니다.
참고로, 재미있게도 이 오류 메시지는 Enumerate 메서드를 호출할 때는 Dialect를 제거하라는 뜻을 제시합니다. 여러분은 이 권고안을 따르지 말아야 합니다. 필터링된 쿼리를 수행할 때는 Dialect가 반드시 명시되어야 하며 반드시 WQL이어야 합니다. 끝.
유일하게 필요한 변경은 Enumerate 메서드를 호출하는 경우에 발생합니다. 이 지점에서 Resource(strResource)를 나타내는 변수뿐만 아니라 Filter(strFilter)와 Dialect(strDialect)를 나타내는 변수도 따라 보내야 합니다.
Set objResponse = _
  objSession.Enumerate _
  (strResource, strFilter, strDialect)
직접 결과를 확인하십시오.
그러면 클래스의 일부 선별된 속성만 반환하는 것은 어떨까요? 예를 들어 어느 컴퓨터에서 실행되는 모든 서비스의 Name 및 DisplayName만 반환하고자 한다고 가정합시다. 그러면 어떻게 해야 할까요?
그와 같은 경우에는 Name 및 DisplayName만 표시되도록 XML을 조작할 수 있습니다. 가능하지만 확실히 까다로운 방법입니다. 더 쉬운 방법은 Filter를 할당할 때 그러한 속성들만 명시하는 것입니다.
strFilter = _
  "Select Name, DisplayName " & _
  "From Win32_Service " & _
  "Where State = 'Running'"
그렇게 하면 다음과 같이 각 서비스의 Name 및 DisplayName만 얻게 될 것입니다.
XmlFragment
    DisplayName = Windows Event Log
    Name = EventLog

XmlFragment
    DisplayName = COM+ Event System
    Name = EventSystem
인정합니다. 형식이 다소 엉뚱하지요. (XmlFragment 따위는 대체 뭘까요?) 그래서 다음 달에 더 다듬겠다는 얘깁니다.

기대하시라
아주 운이 없지만 않다면, WinRM의 거칠고 놀라운 세계의 탐험을 시작하는 데에는 이 정도로 충분합니다. 물론 과거 독일에서 유행했던 '대기 영안실'에 관해 언급하지 않고 WinRM에 관한 칼럼을 마칠 수는 없을 것입니다. 대기 영안실이 있는 도시에서는 시체가 즉시 매장되지 않았습니다. 대신 손가락과 발가락에 여러 개의 줄과 철사를 감고 따뜻한 방 안에 안치되었습니다. 물론, 그 발상은 아주 작은 동작으로도 경보를 울리고 도움을 청할 수 있게 한다는 것이었습니다. 이 사람들이 전혀 살아날 가망이 없으며 결코 아무 것도 할 수 없다는 것이 명백해질 때까지 이 시체들은 대기 영안실에 보관되었습니다.
그러고 보면 대기 영안실이라는 것은 Scripting Guys 팀에 배속되는 것과 매우 유사한 면이 있습니다. 아닌가요? 물론, 대기 영안실에서 다시 살아 나온 사람은 전혀 없습니다만, Scripting Guys 팀에 배속되었던 사람들은...

Dr. Scripto의 Scripting Perplexer
2007년 6월, Scripting Guys는 플로리다 올랜도에서 열린 Tech•Ed 2007 컨퍼런스에 참석했습니다. 컨퍼런스 참석에만 그치지 않고 우리는 좀 즐겨보기로 했습니다. 우리는 다른 사람들도 역시 즐길 수 있을 것이라고 생각했습니다. 이러한 생각으로 우리는 스크립팅 관련 퍼즐과 기타 다양한 정보를 수록한 소책자, Dr. Scripto's Fun Book을 들고 나왔습니다. 우리는 TechNet Magazine과 협력하여, 즉 Expo Hall에 설치된 이들의 부스에서 아주 작은 구석 자리 하나를 달라고 해서 지나가는 사람들에게 그 Fun Book을 나눠주었습니다.
결과적으로, 그 Fun Book은 매우 인기 있는 품목이었습니다(Dr. Scripto 버블 머리 인형보다는 못했지만 거의 근접했지요). 기회를 놓칠 리 없는 영리한 TechNet Magazine 사람들은 Scripting Guys의 성공을 활용할 수 있는 방법을 하나 더 포착해서(Scripting Guys 스스로는 자신의 성공을 제대로 활용할 수 없을 것 같으므로), 자신들을 위한 퍼즐을 몇 개 만들어 달라고 부탁해왔습니다. Scripting Guy 팀원인 Jean Ross가 잠시 돌아선 사이, 같은 팀원인 Greg Stemp가 말해 버렸습니다. "하죠, 뭐!" 그래서 나왔습니다. Dr. Scripto의 Scripting Perplexer입니다. 즐겨보세요.

Drop-In Scripting
이 퍼즐에서 맨 위의 모든 문자들을 해독하면 스크립트가 만들어집니다(VBScript). 그러나 걱정하지 마십시오. 전부를 한 번에 해독할 필요는 없습니다. 한 번에 한 열씩 해독하면 됩니다. 맨 위 섹션 각 열의 문자가 맨 아래 섹션 동일 열의 빈 공간에 채워집니다. 예를 들면 다음과 같습니다.
예에서 보듯이, 열 1에는 문자 S, C, T가 있습니다. 이 세 문자는 알 수 없는 순서로 아래의 격자 모양 표에 속합니다. 그러나 모든 문자가 적절한 순서로 내려가면, 맨 아래 격자는 왼쪽에서 오른쪽으로 읽을 때 논리적인 의미를 나타냅니다. 해답을 살펴보십시오.
열 1의 문자 S, C, T가 T, S, C의 순서로 내려옵니다. 이것은 "The Script Center"의 각 단어 첫 문자입니다. 실제 퍼즐은 이보다 더 어렵습니다. 더 길 뿐더러 최종 결과가 하나의 완전한 스크립트를 구성하기 때문입니다.
한 가지 힌트를 드리자면, 최종 스크립트는 한 파일의 전체 경로로 시작되어 구문 분석을 진행하고 단지 파일 이름만 표시합니다.
행운을 기원합니다!

Dr. Scripto의 Scripting Perplexer
답: 드롭인 스크립팅(Drop-In Scripting), 2007년 11월
이 퍼즐에서는 한 열 안의 문자들을 아래의 정확한 칸으로 떨어뜨려 맨 아래 행이 하나의 스크립트를 구성하도록 해야 합니다. 완성된 스크립트는 다음과 같습니다.
name = "C:\Scripts\Test.txt"
arr = Split(name, "\")
index = Ubound(arr)
Wscript.Echo "Filename: " _
& arr(index)
퍼즐 격자의 모양은 다음과 같습니다.

Microsoft Scripting Guys는 Microsoft에서 고용되어 일하고 있는 Microsoft의 직원들입니다. 이들은 좋아하는 야구 경기와 기타 여러 활동을 하는 시간을 제외하고는 항상 TechNet 스크립트 센터를 운영합니다. 자세한 내용은 www.scriptingguys.com에서 확인하십시오.


 Security Watch: 어디서든 안전하게 액세스
Security Watch
어디서든 안전하게 액세스
John Morello

네트워크에 연결된 모바일 사용자의 증가는 오늘날 기술 분야에 있어서 확실히 나타나는 추세 중 하나입니다. 대부분의 기업에는 원거리 지사 근무 또는 재택 근무를 하거나 고객 방문을 위한 출장이 잦은 직원이 있습니다. 생산성을 높이려면 이러한 사용자가 위치에 관계없이 응용 프로그램과 데이터에 쉽게 액세스할 수
있도록 해야 합니다. 그러나 최근까지도 원격으로 안전하게 액세스하려면 클라이언트 소프트웨어를 설치하고 복잡한 명령을 입력해야 하며 연결 시간도 많이 걸리는 경우가 많았습니다.
지난 몇 년 사이에 원격 액세스를 보다 간단하고 이용하기 쉬운 기술로 만들기 위한 다양한 방식이 등장했습니다. 예를 들어 Outlook® Web Access(OWA)는 사용자가 복잡한 계층 3 VPN(가상 사설망) 없이도 단일 브라우저를 통해 전자 메일, 일정 및 연락처에 간단하게 액세스할 수 있도록 합니다. OWA와 같은 기술은 "어디서든 액세스 가능한" 솔루션에 있어 중요한 부분을 차지하지만 대부분의 조직에서는 이러한 통합 브라우저 환경을 허용하지 않는 핵심 응용 프로그램을 많이 사용하고 있습니다. 이러한 경우 터미널 서비스와 같은 솔루션이 사용자가 어디서든 응용 프로그램에 액세스할 수 있는 효과적인 방법이 될 수 있습니다.
Microsoft는 Windows Server® 2008에서 터미널 서비스의 기본 기능 집합을 크게 개선했습니다. 그 결과 이제 터미널 서비스에는 완벽한 창, RemoteApp라는 응용 프로그램별 게시 기능, EasyPrint의 범용 인쇄 드라이버 기능, TS Web Access라는 브라우저 기반 포털 등이 추가되었습니다. 또한 Windows Server 2008에는 어디서든 액세스 가능한 솔루션의 핵심이 되는 TS 게이트웨이 구성 요소도 포함되었습니다. 이 구성 요소는 RDP(원격 데스크톱 프로토콜)에 대해 SSL 캡슐화를 제공하여 방화벽과 NAT(Network Address Translation) 장치를 쉽고 안전하게 통과할 수 있도록 합니다. TS 게이트웨이 기능은 NAP(네트워크 액세스 보호)라는 Windows Server 2008의 새로운 기술과 통합되어 끝점 클라이언트 상태 검사 기능도 제공합니다. 조직에서 이 모든 구성 요소를 결합하면 어디서든 쉽고 안전하게 응용 프로그램과 데이터에 액세스할 수 있는 솔루션을 구축할 수 있습니다.
이 칼럼에서는 터미널 서비스 구성 요소의 관리에 대한 자세한 내용보다는 어디서든 액세스 가능한 솔루션의 네트워크 및 보안 설계 측면에 중점을 두고, Windows Server 2008에 포함된 기술을 기반으로 이러한 솔루션을 작성하는 방법과 최상의 방법을 설명합니다.

계층 3 가상 사설망의 문제점
새 기술에 대해 생각해 볼 때는 현재 사용 중인 방식과 비교하여 어떤 이점이 있는지를 파악하여 새 모델의 가치를 정확히 평가하는 것이 중요합니다. 기존 계층 3 VPN에는 일반적으로 보안과 사용의 용이성과 관련하여 해결해야 할 두 가지 중대한 문제가 있습니다.
최신 계층 3 기반 VPN에서 보안이 문제가 된다는 사실이 다소 의아하게 들릴 수 있습니다. VPN의 궁극적인 목적이 바로 인터넷을 통해 안전한 터널을 제공하는 것이니까요. 이를 이해하기 위해 일반적으로 VPN 위협 요소가 될 수 있는 사항을 종합적으로 살펴보겠습니다. 그렇다고 VPN을 통해 전달하는 데이터가 가로채기나 변조의 위험에 노출된다는 의미는 아닙니다. 대부분의 최신 계층 3 VPN은 뛰어난 데이터 스트림 암호화 기능을 제공합니다. 그보다는 조직 네트워크에 "모든 포트, 모든 프로토콜"을 통해 액세스할 수 있는 모든 권한이 부여된 원격 컴퓨터로 인해 발생하는 위협을 생각해 볼 수 있습니다. 문제는 계층 3 VPN에서 암호화되어 네트워크를 통해 전달되는 데이터 스트림이 아니라 이러한 터널을 통한 원격 클라이언트 연결에 있습니다. 이러한 연결은 내부 네트워크의 위험성을 높입니다. Slammer나 Blaster와 같은 맬웨어로 피해를 입은 대부분의 조직이 내부 네트워크의 컴퓨터나 방화벽을 통과한 해커에 의해 손상을 입은 것이 아니었다는 점을 기억해 보십시오. 그보다는 오히려 감염된 컴퓨터에서 VPN을 통해 네트워크에 연결하는 원격 사용자를 통해 이러한 피해가 발생한 것입니다. 이러한 VPN에서 완전히 라우팅된 계층 3 기반 연결을 만들면 원격 컴퓨터가 데이터센터에 설치된 컴퓨터와 마찬가지로 내부 리소스에 대한 액세스 권한을 가지게 됩니다. 이러한 액세스 권한은 좋은 의도로 사용될 수도 있지만 악용될 소지도 있습니다.
게다가 계층 3 VPN을 위해서는 조직의 IT 부서에서 관리하지 않는 컴퓨터에 소프트웨어를 설치하고 구성해야 하므로 운영 비용이 높아질 수 있습니다. 예를 들어 사용자의 가정용 컴퓨터에 VPN 클라이언트를 설치하려면 사용자 지정 설치 패키지를 만들고, 사용자가 따라야 하는 자세한 설치 지침을 작성하고, 사용자의 컴퓨터에 설치된 응용 프로그램과의 충돌 문제를 해결해야 합니다. 뿐만 아니라, 새로운 버전의 클라이언트를 배포해야 하거나 새 VPN 끝점을 추가하는 경우와 같이 구성 데이터가 변경되는 경우 막대한 관리 비용이 소요될 수 있습니다. 사용자의 입장에서는 이 VPN을 통한 작업이 직관적이지 않게 느껴지는 경우가 많습니다. 계층 3 연결밖에 제공되지 않으므로 사용자의 업무용 응용 프로그램과 데이터를 쉽게 액세스하여 확인할 수 없습니다.

터미널 서비스를 통한 문제 해결
터미널 서비스와 계층 7 또는 응용 프로그램 계층 VPN이라는 다른 기술에서는 사용자가 액세스할 수 있는 리소스 및 프로토콜에 대한 효과적인 제어 기술을 제공하고 최종 사용자 환경을 이전보다 간단하고 직관적으로 만들어 이 두 가지 문제를 해결합니다.
보안의 관점에서 보면 계층 3 VPN 방식과 터미널 서비스 및 TS 게이트웨이를 사용하는 다른 방식 사이의 가장 중요한 기능 차이점은 내부 네트워크에 대한 연결이 완전히 개방된 파이프라인이 아니라는 점입니다. 특히 계층 3 방식에서는 내부 네트워크에 대한 모든 라우팅 기능을 가진 가상 인터페이스를 로컬 컴퓨터에 만드는 반면, TS 게이트웨이 방식에서는 RDP 기반 패킷만 내부 네트워크에 전달되도록 허용합니다. 따라서 전반적인 공격 노출 영역이 크게 줄고 RDP 내에서 보다 세부적으로 제어할 수 있습니다. 예를 들어 RDP는 드라이브 리디렉션에 대한 기본 지원을 제공하지만 조직에서 TS 게이트웨이를 NAP와 통합하여 원격 컴퓨터가 최신 바이러스 백신 소프트웨어가 설치되어 있음을 증명하는 경우에만 이 기능을 허용하도록 구성할 수 있습니다.
최종 사용자의 관점에서 계층 3 VPN과 터미널 서비스 기반 방식 간의 가장 명백한 차이는 설치가 훨씬 간단하다는 점(설치가 전혀 필요하지 않은 경우도 많음)과 응용 프로그램 및 데이터에 훨씬 쉽고 직관적으로 액세스할 수 있다는 점입니다. 원격 데스크톱 연결 클라이언트가 Windows에서 기본 제공되고 Windows® Update와 같은 일반 서비스 기술을 통해 최신으로 유지되므로 대개 별도로 설치할 클라이언트 소프트웨어가 없습니다. 또한 TS 웹 액세스를 활용함으로써 사용자가 단일 URL에서 모든 응용 프로그램과 데이터를 찾을 수 있습니다. 응용 프로그램을 간단히 클릭하면 TS 게이트웨이에서 인터넷을 통한 연결을 안전하게 터널링하여 해당 응용 프로그램이 사용자의 데스크톱에 완벽하게 전달됩니다. 다시 말해 복사하여 붙여넣기 기능이 지원되고 작업 표시줄에 최소화되는 등 응용 프로그램이 로컬로 설치된 것처럼 보이고 동작합니다. 터미널 서버 기반의 원격 액세스 방식은 응용 프로그램과 데이터를 검색하기 용이하게 하고 설치가 즉각적으로 이루어지게 함으로써 성공적으로 사용자 만족도를 높이고 지원 비용을 절감해 줍니다.

네트워크 아키텍처 선택
인터넷을 통해 TS 게이트웨이 서버를 사용할 수 있도록 하는 데에는 두 가지 기본 네트워크 설계 방식을 이용할 수 있습니다. 첫째는 TS 게이트웨이를 경계 네트워크의 계층 3/4 방화벽 사이에 배치하는 방식이고, 둘째는 TS 게이트웨이를 내부 네트워크에 배치하고 Microsoft® ISA Server, Microsoft Intelligent Application Gateway, 기타 다양한 타사 솔루션과 같은 응용 프로그램 계층 방화벽을 경계 네트워크에 배치하여 인바운드 HTTPS 프레임을 검사하는 방식입니다. 여기서는 이러한 인바운드 세션이 분석된 후에만 패킷이 내부 TS 게이트웨이 서버로 전달됩니다.
조직에 기본 상태 기반 패킷 검사만 실행하는 계층 3/4 방화벽밖에 없으면 그림 1과 같이 TS 게이트웨이 장치를 경계 네트워크에 직접 배치할 수 있습니다. 이 설계에서는 인터넷 쪽 방화벽이 인터넷을 통해 HTTPS 트래픽만 전달되도록 TS 게이트웨이에 대한 연결을 제한합니다. 그러나 방화벽은 응용 프로그램 계층에서는 이 트래픽에 대한 검사를 수행하지 않고 TS 게이트웨이로 전달하기만 합니다. 그러면 TS 게이트웨이 서버가 HTTPS 패킷에서 RDP 프레임을 추출하여 해당 백 엔드 서버로 전달합니다. 이러한 백 엔드 서버는 대체로 TS 게이트웨이에서 전달된 RDP 프레임이 해당 내부 서버에 전달되도록 허용하는 다른 방화벽에 의해 경계 네트워크와 분리됩니다.
그림 1 계층 3/4 방화벽을 사용하는 경우 경계 네트워크에 배치된 TS 게이트웨이
그림 1 계층 3/4 방화벽을 사용하는 경우 경계 네트워크에 배치된 TS 게이트웨이
이러한 시나리오는 완벽하게 지원되고 많은 조직에서 유용할 수도 있지만 두 가지 중대한 단점이 있습니다. 첫째, TS 게이트웨이가 인터넷에서 직접 트래픽을 수신하기 때문에 외부의 악의적인 공격자에게 더 많이 노출되는 위험이 있습니다. 이러한 악의적인 공격자는 SSL 세션을 통해 게이트웨이에 대한 공격을 시도할 수 있을 뿐만 아니라 프런트 엔드 방화벽이 헤더만 검사하고 페이로드는 검사하지 않기 때문에 이러한 세션이 게이트웨이까지 도달할 수 있습니다. 그렇다고 TS 게이트웨이가 취약한 구성 요소라는 뜻은 아닙니다. 사실 TS 게이트웨이는 다른 Windows Server 2008 제품과 마찬가지로 엄격한 보안 설계와 테스트를 거쳤습니다. 그러나 이 시나리오에서만큼은 인터넷에서 직접 수신된 필터링되지 않은 트래픽을 처리할 수도 있기 때문에 위험 수준이 상대적으로 높습니다. 두 번째 중대한 단점은 게이트웨이와 백 엔드 방화벽 간에 허용되어야 하는 트래픽의 양이 증가한다는 점입니다. 사용자를 인증하기 위해 TS 게이트웨이는 Active Directory®와 통신해야 합니다. 이러한 통신을 가능하게 하려면 백 엔드 방화벽에서 HTTPS보다 훨씬 광범위한 포트와 프로토콜에 대해 예외를 적용해야 합니다. 이렇게 허용되는 통신이 증가함에 따라 또 다시 설계적인 측면에서의 상대적 위험 수준이 높아지게 됩니다.
TS 게이트웨이를 인터넷에 노출하기 위해서는 인바운드 HTTPS 세션이 게이트웨이에 도달하기 전에 응용 프로그램 계층(계층 7) 방화벽을 사용하여 처리하는 방식이 더 효과적입니다(그림 2 참조). 이 설계에서도 기존 계층 3/4 방화벽이 경계 네트워크를 구성할 수 있습니다. 그러나 TS 게이트웨이 대신 계층 7 방화벽이 경계에 배치됩니다. 트래픽이 외부와 접한 방화벽에 도달하면 방화벽에서 HTTPS 프레임을 제외한 모든 데이터를 필터링하여 계층 7 방화벽에 HTTPS 프레임만 전달합니다. 이때 계층 7 방화벽은 SSL 세션을 종료하고, 스트림에서 암호화되지 않은 콘텐츠를 검사하고, 악의적인 트래픽을 차단한 다음 백 엔드 방화벽을 통해 RDP 프레임을 TS 게이트웨이로 전송합니다. 원하는 경우 계층 7 방화벽에서 프레임을 TS 게이트웨이로 보내기 전에 다시 암호화할 수도 있습니다. 이 방식은 조직의 전용 네트워크에는 그다지 필요하지 않지만 호스팅되는 데이터 센터나 공유 네트워크에는 매우 유용할 수 있습니다.
그림 2 TS 게이트웨이 장치와 응용 프로그램 계층 방화벽 사용
그림 2 TS 게이트웨이 장치와 응용 프로그램 계층 방화벽 사용
이 설계를 통해 이전 솔루션의 단점을 모두 해결할 수 있습니다. TS 게이트웨이 서버가 계층 7 방화벽에서 검사된 트래픽만 수신하므로 인터넷을 통한 공격이 차단되지 않을 위험성이 낮아집니다. 계층 7 방화벽이 이러한 공격을 필터링하고 검사를 통과한 정상 트래픽만 게이트웨이로 보내기 때문입니다.
이 솔루션의 다른 주요 장점으로, 내부 네트워크에 따라 게이트웨이가 배치된다는 점을 들 수 있습니다. 인터넷에서 수신되는 트래픽이 게이트웨이에 도달하기 전에 계층 7 방화벽에서 검사되므로 게이트웨이를 내부 네트워크에 배치하여 사용자 세션의 인증과 RDP 호스트를 위해 도메인 컨트롤러에 직접 액세스하도록 할 수 있습니다. 게다가 백 엔드 방화벽에 훨씬 엄격한 정책을 적용할 수도 있습니다. RDP 및 디렉터리 인증 트래픽을 모두 허용하는 대신 계층 7 방화벽에서 전달된 RDP 세션만 TS 게이트웨이에 도달하도록 허용해야 합니다. 계층 7 방화벽을 기반으로 TS 게이트웨이 배포를 진행하면 기존 경계 네트워크를 다시 설계하지 않고도 관리가 용이하고 보다 안전한 솔루션을 제공할 수 있습니다.

NAP 통합
터미널 서비스 리소스
  • Windows Server 2008의 터미널 서비스
  • Windows Server 2008 터미널 서비스 TechNet 포럼
  • 터미널 서비스 팀 블로그
  • Microsoft Intelligent Application Gateway 2007
  • Windows Server 2008용 NAP(네트워크 액세스 보호)
  • NAP(네트워크 액세스 보호) 블로그
  • Windows Server 2008 베타 3 단계별 가이드

뛰어난 경계 설계가 어디서든 액세스 가능한 솔루션의 핵심 요소이기는 하지만 규정을 준수하고 끝점 장치의 보안을 유지하는 것도 중요합니다. RDP는 RDP 세션 및 프린터와 같은 다양한 유형의 장치 리디렉션을 허용하는 기능이 풍부한 프로토콜이므로 솔루션에 연결하는 클라이언트가 조직의 보안 정책을 따르도록 하는 것이 중요합니다. 예를 들어 앞서 살펴본 것과 같은 최상의 방법에 따른 안전한 네트워크 토폴로지를 사용하더라도 안전하지 않은 컴퓨터에서 터미널 서버에 연결하는 최종 사용자가 기밀 데이터를 잃거나 악의적인 파일을 터미널 서버로 가져올 수 있습니다. 사용자가 계층 3 VPN을 통해 연결하는 경우보다는 연결할 수 있는 경우와 피해를 입을 수 있는 가능성이 매우 적지만 데이터 손실의 위험성을 관리하고 IT 정책을 준수하도록 하는 것은 여전히 중요합니다.
NAP(네트워크 액세스 보호)는 네트워크에 연결할 수 있는 사용자뿐만 아니라 이러한 사용자가 연결에 사용할 수 있는 시스템의 종류까지 제어할 수 있는 Windows Server 2008의 새로운 기술입니다. 예를 들어 NAP를 사용하면 방화벽을 실행 중이고 최신 바이러스 백신 소프트웨어가 설치된 컴퓨터만 네트워크에 연결하도록 제한할 수 있습니다. 또한 NAP는 조직의 내부 네트워크는 물론, 계층 3 VPN을 통해 연결하는 사용자와 TS 게이트웨이를 통해 연결하는 사용자를 비롯한 원격 사용자까지 제어하도록 확장할 수 있는 솔루션입니다. NAP를 TS 게이트웨이 설계에 통합하면 보안 정책에 부합하는 시스템만 연결하도록 할 수 있습니다. NAP에 대한 자세한 내용은 2007년 5월호 TechNet Magazine에서 필자의 Security Watch 칼럼(technetmagazine.com/issues/2007/05/SecurityWatch)을 참조하십시오.
NAP는 설계에 서비스 하나만 추가하는 간단한 방식으로 TS 게이트웨이 배포에 통합할 수 있습니다. 이 서비스는 NPS(네트워크 정책 서버)로 TS 게이트웨이 서버 자체에 설치하거나 별도의 운영 체제 인스턴스에 설치할 수 있습니다. 그런 다음 TS 게이트웨이 MMC를 사용하여 특정 상태에서 허용할 RDP 기능을 정의하는 CAP(연결 권한 부여 정책)를 만듭니다. TS 게이트웨이 서버는 새 연결이 시도될 때마다 NPS로 검사하고 해당 연결에 대한 SoH(상태 설명)를 NPS로 전달하도록 구성됩니다. 그러면 네트워크 정책 서버가 SoH를 정책과 비교하여 클라이언트 상태에 따라 연결을 허용해야 할지 여부를 TS 게이트웨이에 알립니다.
그림 3에서 보듯이 조직의 보안 정책에서 자동 업데이트 사용을 요구하나 시스템이 Windows Update를 사용하지 않도록 구성되어 정책에 부합하지 않는 경우 사용자가 TS 게이트웨이에 연결을 시도하면 컴퓨터에서 SoH를 생성하여 전달합니다. 이 SoH의 내용은 "방화벽을 사용 중이며 바이러스 백신이 최신이지만 자동 업데이트를 사용하지 않습니다."와 같습니다. 이 경우 TS 게이트웨이에는 SoH를 디코딩하는 자체 논리가 없으므로 TS 게이트웨이는 이 SoH를 NPS에 전달하고 NPS에서 SoH를 관리자가 정의한 정책과 비교합니다. 자동 업데이트를 사용하지 않으므로 NPS는 연결이 "비준수" 정책에 해당하는 것으로 판단하여 TS 게이트웨이에 연결을 허용하지 않도록 지시합니다. 그러면 TS 게이트웨이가 연결을 끊고 사용자에게 컴퓨터가 조직의 보안 정책에 부합하지 않음을 알립니다. 사용자는 필요한 조치(이 경우 자동 업데이트 설정)를 취하고 연결을 다시 시도할 수 있습니다. 그 결과 새 SoH가 생성되고 NPS는 컴퓨터가 정책을 준수하는 것으로 판단하므로 TS 게이트웨이가 연결을 허용하게 됩니다.
그림 3 정책을 준수하는 시스템만 연결 가능
그림 3 정책을 준수하는 시스템만 연결 가능

결론
Windows Server 2008에는 안전하면서 어디서든 액세스 가능한 솔루션의 핵심이 되는 기초 구성 요소가 포함되어 있습니다. TS 게이트웨이는 인터넷을 통해 원격 데스크톱 세션을 안전하게 터널링하는 방법을 제공하며 조직에서 이 게이트웨이를 기존 네트워크에 통합할 수 있는 여러 옵션을 제공합니다. 선택할 수 있는 옵션으로는 TS 게이트웨이를 경계 네트워크에 직접 배치하거나, TS 게이트웨이의 전면에 ISA Server 또는 Intelligent Application Gateway와 같은 계층 7 방화벽을 사용하는 방식이 있습니다. NAP를 TS 게이트웨이와 결합하면 솔루션에 끝점 상태 검사 기능을 추가할 수 있습니다. 조직에서는 끝점 검사를 통해 유효한 사용자가 원격 연결을 했는지 여부뿐만 아니라 해당 연결이 IT 보안 정책을 준수하는 컴퓨터에서 이루어졌는지도 확인할 수 있습니다. 이 두 기술을 함께 사용하는 경우 보다 안전하고 효율적으로 작동하며 최종 사용자에게 보다 나은 환경을 제공하는 원격 액세스 기능의 구현이 가능합니다. "터미널 서비스 리소스" 추가 기사에 나열된 사이트에서 더 많은 정보를 얻을 수 있습니다.

John Morello는 2000년부터 Microsoft에서 일해왔습니다. 수석 컨설턴트로서 Fortune 100대 기업과 미국 민간 및 군사 부문 고객을 위한 보안 솔루션을 설계하였으며, 현재는 Windows Server 그룹의 수석 프로그램 관리자로 어디서나 액세스할 수 있는 기술을 담당하고 있습니다. Morello가 속한 팀의 블로그(blogs.technet.com/WinCAT)도 살펴보시기 바랍니다.


 The Desktop Files: 조각 모음에 관한 진실
The Desktop Files
조각 모음에 관한 진실
Wes Miller

하드 디스크가 존재하는 한, 디스크 조각화 문제는 사라지지 않을 것입니다. 따라서 시스템에 조금이라도 관심이 있다면 디스크 조각 모음을 정기적으로 수행해줘야 합니다. 아마도 매년 치과 의사와 나누던 이야기가 생각날 수도 있겠습니다. 그렇습니다. 치석을 제거하는 것처럼 디스크 조각 모음도 정기적으로 수행하는 것이 중요합니다.
컴퓨터를 전혀 켜지 않는 경우가 아니라면 디스크는 갈수록 조각화되기 마련입니다. 조각화가 어떻게 발생하는지는 잠시 뒤에 설명하기로 하고 먼저 디스크 조각 모음의 역사를 간략히 살펴보겠습니다.

디스크 조각 모음과 Windows NT
Windows NT®에는 디스크 조각 모음 유틸리티가 내장되어 있지 않았으며, 굳이 필요 없다는 것이 당시의 통념이었습니다. 어쨌든 NTFS는 처음부터 최적화를 염두에 두고 만들어졌으므로 조각화로 인한 문제가 FAT 볼륨의 경우만큼 크지는 않습니다. 그러나 시간이 흐를수록 NTFS에도 최적화되지 않은 파일 배치로 인한 성능 저하가 나타날 수 있습니다. 덕분에 타사 디스크 조각 모음 도구 시장이 번성했습니다. IT 전문가들 사이에서 가장 인기 있었던 제품 가운데 하나는 Executive Software(현 Diskeeper Corporation)의 Diskeeper 제품이었습니다. Windows 2000에 디스크 조각 모음 기능을 도입할 때, Microsoft는 Executive Software로부터 해당 기술을 라이선스했습니다. Windows® 2000 디스크 조각 모음 기능은 Microsoft® 관리 콘솔(MMC) 스냅인(dfrg.msc)에서 사용할 수 있었으며 볼륨을 클릭하거나 명령줄에서 직접 defrag.exe를 입력해서 실행할 수 있었습니다. 일정 지정 기능도 없고 제약이 많은 명령줄만 제공되었지만 그래도 많은 IT 전문가들은 기능 스크립트를 만들어 이 기본 버전을 이용해서 디스크 조각 모음 작업을 자동화했습니다. Windows XP와 Windows Server® 2003의 Defrag.exe는 기존 버전보다 다소 개선되었지만 자동화 기능이 제한적이어서 여전히 스크립트 작업이 필요했습니다.
필자의 전 직장이었던 Winternals Software를 포함한 여러 공급업체에서 기업용 디스크 조각 모음 시장을 노린 소프트웨어를 제작하기도 했습니다. 이러한 제품들은 대부분 같은 방식으로 작동했습니다. 즉, 중앙에 콘솔이 있고 클라이언트 시스템에 에이전트 프로그램이 있어서(상주 또는 요구 시 실행) 중앙의 콘솔이 디스크 조각 모음 작업의 시기와 방법을 지시하는 구조로 되어 있습니다.
Windows Vista®는 대체로 단일 시스템 디스크 조각 모음의 추세를 따르는 한편, 디스크 조각 모음 도구를 최적화하고 작은(64MB 이하) 파일 조각을 모으는 옵션을 포함시켰습니다. 이 옵션을 이용하면 디스크 조각 모음 속도는 빨라지지만 그보다 큰 파일 조각들은 디스크에 분산된 채로 남게 됩니다. 디스크 조각 모음 엔진 자체는 Windows Vista와 Windows Server 2008이 기존 버전의 Windows보다 강력합니다. 또한 자동으로 실행되며 수작업을 통한 일정 지정이 필요 없습니다. 그러나 대규모 조직을 관리하고 있거나 defrag.exe에서 기본적으로 제공하지 않는 방식으로 시스템을 최적화하고자 한다면 여전히 타사 소프트웨어를 라이선스해야 합니다. 그리고 기존 버전에서와 같이, NTFS 압축 기능이 폭넓게 사용되는 볼륨의 경우 디스크 조각 모음이 어려울 수도 있습니다. 그러한 경우에도 타사 도구가 도움이 될 것입니다.

조각화는 어떻게 발생하는가?
조각화는 시간의 흐름에 따라 파일들이 바뀌기 때문에 발생합니다. 이상적으로 볼 때, Windows 파일 자체는 바뀌지 않습니다. 최소한 자주 바뀌지는 않으며, 사실 서비스 팩과 소프트웨어 업데이트가 설치되는 경우에만 바뀝니다. 그 외의 경우, 시스템 파일은 비교적 일정한 상태를 유지합니다. 서비스 팩 설치와 같은 대대적인 업데이트를 수행하게 되면, 업데이트되는 파일들을 디스크의 제 위치에서 덮어쓸 수 없는 경우가 일반적이므로 조각화가 자연스럽게 발생하며, 부팅을 다시 해야 업데이트가 가능한 경우도 있어 조각화가 더 심해집니다.
반면 사용자 파일과 데이터, 그리고 Windows 레지스트리는 항상 변화에 노출되어 있습니다. 파일 읽기, 쓰기, 편집, 복사 및 삭제 등은 항상 상당한 조각화를 야기하며, 드라이브 용량이 채워질수록 특히 더 심해집니다.
이를 시각화하려면, 완벽하게 배열된 디스크를 상상해 보면 됩니다. 파일들이 서로 간 아무런 공간 없이 인접하게 공간을 차지하고 있는 상태 말입니다. 그런데 파일을 하나 열어 편집하고 그것을 저장하려 한다고 가정합시다. 그 파일의 크기가 커졌다면 Windows에서는 그 파일 전체를 디스크의 어딘가 다른 곳(파일 N 뒤로 가정)에 저장하거나 새로운 데이터 부분을 파일 N 뒤에 저장할 수 밖에 없습니다. 따라서 이제 파일 2가 조각화된 것입니다. 이제 파일 1을 편집한다면 조각화된 파일은 2개가 됩니다. 이런 일이 오랜 시간 반복되면 결국 시스템은 파일 하나를 찾기 위해 드라이브의 여러 곳을 찾아봐야 할 정도로 매우 조각화됩니다. 큰 데이터베이스 파일들을 사용하거나, 가상 컴퓨팅 기술로 인해 하드 디스크 파일이 크게 확대되거나 일반적인 디스크에 많은 양의 비디오 및 오디오가 저장되어 있는 경우, 조각화는 흔한 현상입니다. 물론 갈수록 커지고 있는 현재의 하드 디스크 크기를 감안할 때 조각화가 그리 큰 문제는 아닐 수 있으나 그렇다고 완전히 잊어버릴 수 있는 문제도 아닙니다. 게다가 하드 디스크 용량이 작은 구형 노트북의 경우 갈수록 반응 속도가 떨어질 것이고 부팅도 느려지고 파일을 열고 저장하는 데 걸리는 시간도 늘어날 것입니다.
중요한 것은 시스템의 조각화가 아니라 개별 파일의 조각화가 어느 정도냐 하는 것입니다. 다채로운 색상으로 상태를 표시하는 디스크 조각 모음 도구가 처음 등장한 이래, 이 도구의 보고 결과를 본 사용자들은 '색상을 질서 있게 정리해야겠다'는 생각을 하게 됩니다. 하지만 실제로 그것은 사용자의 의도에 거의 부합하지 않습니다. 일부 제품들은 디스크를 두 개의 블록, 즉 파일 데이터를 나타내는 색상 있는 블록과 빈 공간을 나타내는 일반적으로 흰색의 블록으로 표시하고자 했습니다. 유감스럽게도 이 방법은, 디스크 조각 모음의 빈도와 비용을 최소화하려는 것이 목적이라면 가장 좋지 않은 방법입니다. 모든 파일 데이터를 디스크의 맨 앞으로 과감하게 압축했는데, 어느 파일에 추가로 편집을 가할 때 그 사이의 빈 공간의 대부분이 제거되었다면, 그 편집 내용은 모두 파일 데이터의 맨 끝에 기록될 수 밖에 없습니다. 따라서 그런 식으로 조각 모음을 수행하면 실제로는 바로 다음 파일 편집 때부터 오히려 조각화를 더 야기하는 결과를 낳습니다. 양호한 방식의 조각 모음 이미지는 말끔하게 정리된 파일 데이터 블록 2개의 형태가 아니라 그다지 완벽하지 않은 형태로 나타납니다. 예를 들어 그림 1은 조각 모음 이전 테스트 시스템의 모습입니다. 그리고 그림 2는 같은 시스템이지만, Windows에서 조각 모음을 완료한 이후의 모습입니다.
그림 1 조각 모음 이전의 드라이브
그림 1 조각 모음 이전의 드라이브
그림 2 조각 모음 이후의 드라이브
그림 2 조각 모음 이후의 드라이브
참고로, Windows에서는 디스크 여기저기에 분산된 여러 파일의 조각화가 아니라 개별 파일의 조각화를 더 중시합니다. 그림 3의 조각 모음 보고서에서는 시스템의 조각을 모으기 전에 '가장 조각화된 파일'에 대한 섹션을 확인할 수 있습니다.
그림 3 조각 모음 보고서
그림 3 조각 모음 보고서
따라서, 조각 모음 이후에도 Windows에서는 파일 데이터 집합이 디스크 맨 앞에 완전히 압축된 것을 보여 주지 않습니다. 또한 그림 1과 2의 녹색 데이터가 큰 부분을 차지하고 있는 것을 확인하십시오. 그것은 Windows 페이지 파일로서, 곧 설명할 것입니다. Windows 시스템에서 최대 절전 모드를 사용 중이라면 조각 모음에서 유사하게 나타날 것입니다.

정기적 조각 모음은 필수
치과 치료에서와 마찬가지로, 조각 모음을 정기적으로 수행하는 것이 중요합니다. 서버와 같이 사용 빈도가 높은 시스템에서 정기적인 조각 모음의 중요성은 갈수록 커지고 있습니다. 조각 모음을 미룬다면, 이후 조각 모음에 걸리는 시간이 너무 늘어나 사용자들이 서버를 이용할 수 없게 되거나 서버가 응답을 멈추게 될 수 있습니다. 조각 모음에는 상당한 시간이 걸리고 조각 모음의 어느 단계에서는 CPU 사용량도 매우 늘어나기 때문입니다.
최고의 실시간 조각 모음 도구도 모든 조각을 완벽히 모을 수는 없습니다. 예를 들어 페이지 파일이나 레지스트리 파일처럼 열려 있는 파일이나 잠긴 파일은 조각 모음이 안 되는 경우가 있으며 최대 절전 모드 파일이 있는 경우에는 우회적인 방법을 사용해야 합니다. 최대 절전 모드 파일의 크기는 시스템에서 사용 중인 RAM의 크기와 같습니다. 잠긴 파일을 최적화하려면 다음에 실릴 조각 모음 트릭에 대한 섹션을 확인하시기 바랍니다.
필자는 조각 모음과 관련된 근거 없는 통념과 올바른 사실을 정확히 이해하는 것이 중요하다고 생각합니다. 그림 4와 그림 5에서는 조각 모음에 대한 논의 과정에서 필자가 들어온 일반적인 화제거리 몇 가지를 나열하고 그러한 문제들이 발생할 실제 가능성을 설명하고 있습니다.
Figure 5 조각 모음에 관한 통념 (Close Figure 5)

통념 | 가능성
시스템이 충돌합니다. | 희박—충돌은 일반적으로 드라이버 또는 하드웨어 문제로 인해 발생합니다(메모리 손상, 열 문제로 인한 다시 부팅, 디스크 과열로 인한 디스크 장애).
응용 프로그램이 충돌합니다. | 희박—전체 시스템의 경우와 마찬가지로, 올바로 제작된 응용 프로그램은 조각화로 인해 충돌이 생기지는 않으므로 억지로 강제되지 않는다면 조각화가 충돌을 야기하는 것으로 가정할 수는 없습니다.
레지스트리가 손상됩니다. | 희박(위 내용 참고)—조각화는 레지스트리 손상을 일으키거나 야기하지 않습니다.
조각 모음을 수행했으면 디스크를 어떤 식으로 시각화하든 단일 색상 막대로 표시되어야 한다. | 희박—빈 공간을 남겨두지 않거나 파티션을 축소 또는 분할하는 섹터 기반 이미지 도구로 시스템의 이미지를 만들 계획이 아니라면 시스템의 모든 파일을 일반적으로 압축하지 말아야 합니다. 파일을 디스크의 앞쪽으로 가져갈 필요는 있지만, 그 외에 공격적인 파일 통합은 조각화를 더 심화할 뿐입니다.
Figure 4 조각 모음에 관한 일반적인 우려 (Close Figure 4)

우려 | 가능성
시스템 성능이 저하됩니다. | 높음—특히 시스템 사용량에 따라 다릅니다.
실수로 삭제한 파일의 복구가 어려워지거나 불가능해집니다. | 높음—대부분의 파일 복구 도구는 (데이터 유형을 파악하기 위해) 발견적 방법과 파일 클러스터 근접성에 의존합니다. 파일이 흩어지면 복구 작업이 더 복잡하거나 불가능합니다.
시스템 조각 모음에는 많은 비용이 따릅니다. | 중간—시스템 사용량과 그 시스템에서 시간의 흐름에 따라 파일들이 변경되는 정도 사이에는 직접적인 상관 관계가 있습니다. 사용자들이 파일을 매우 활발하게 수정하더라도, 예를 들어 그 파일을 서버 공유 영역에만 저장한다면 시간이 흘러도 성능 저하는 크게 발생하지 않습니다.
디스크 손상이 발생합니다. | 낮음—실제로는 발생할 가능성이 별로 없습니다. 물론, 시스템을 혹사할수록(항상 켜두고 디스크를 작동시키며, 파일 편집이나 수정, 삭제 등을 많이 수행할수록) 디스크 손상 가능성은 커집니다. 그러나 오늘날의 하드웨어에서는 단순히 파일 편집으로 인해 디스크 손상이 발생할 가능성은 없습니다.

인프라의 일부로서의 조각 모음
모든 시스템에서 정기적으로 조각 모음 도구를 실행하는 것을 진지하게 고려해봐야 합니다. Windows에 기본 제공된 조각 모음 도구를 사용하는 방법과 타사의 옵션을 찾아보는 방법이 있습니다. 그것은 기본적으로 여러분이 어느 정도의 엔지니어링을 수행하고자 하느냐에 달려 있습니다. Windows XP 및 그 이후 버전에서는 defrag.exe를 '예약된 작업'으로 추가할 수 있습니다. support.microsoft.com/kb/555098의 기술 자료 문서에는 그 방법이 설명되어 있습니다. 노트북 컴퓨터의 디스크 조각 모음에는 몇 가지 특별히 고려할 사항이 있습니다. 사용자의 시스템에 전원이 켜졌을 때(이상적으로는 AC 전원) 디스크 조각 모음을 수행하고 싶겠지만, 또한 동시에, 모바일 사용자가 어떤 작업을 완수하려 할 때 조각 모음 작업으로 CPU 또는 디스크 사이클을 차지하고 싶지는 않을 것입니다. 그러나 유감스럽게도, 모바일 사용자가 자신의 시스템을 사용하지 않을 때는 시스템에 AC 전원이 꼽혀 있지 않고 대기 모드이거나 최대 절전 모드(전원 관리 및 '예약된 작업'의 관점에서 볼 때는 전원이 꺼진 상태)일 가능성이 높습니다. Winternals에서는 (다른 회사와 마찬가지로) 이상적인 모바일 사용자 시나리오를 설계하기 위해 상당한 노력을 들였습니다. 기본 내장된 조각 모음 도구와 '예약된 작업'을 사용하며 이전 버전보다 전원 인식 기능이 훨씬 향상된 Windows Vista만으로도 충분한 솔루션이 될 수 있습니다. 그렇지 않다면 모바일 시스템을 위한 타사 솔루션이 필요할 것입니다. 그 가운데 일부는 실제 조각 모음 작업을 시작하면서 실행되었음을 사용자에게 알려주고, 언제 얼마나 자주 실행되며 얼마나 오래 걸리는지도 알려 줍니다.
모바일 시나리오 외에도, 파일 시스템 이상의 조각화에 대해서도 생각해봐야 할 것입니다. 이것은 데스크톱 컴퓨터나 모바일 컴퓨터에서는 일반적으로 고려할 필요성이 있는 사항은 아닐 것입니다. 그러나 서버나 Microsoft Exchange, SQL ServerTM, 또는 기타 데이터 저장소는 고유의 조각 모음을 필요로 할 수 있습니다. 그러한 경우에는 해당 조각 모음을 파일 시스템 조각 모음 수행 이전에 해야 하는지 또는 이후에 해야 하는지를 판단해야 합니다.
타사 조각 모음 도구를 사용 중이라면 그것이 Windows 조각 모음 API를 사용하고 있는지 확인해 볼 필요가 있습니다. Windows NT 4.0 이래로, Windows는 예상치 못한 데이터 손실을 방지하기 위해 고유의 조각 모음 API를 채용해왔습니다. 예를 들어 파일을 이동하는 도중에 시스템 전원이 나가면 최악의 경우, 불완전한 조각 이동으로 인해 데이터 손실은 물론 시스템의 부팅이 불가능한 상황도 발생할 수 있습니다.
마지막으로, 가상 컴퓨팅 기술을 사용 중이라면 가상 디스크의 조각 모음을 관리하는 방법도 알아보고자 할 것입니다. 가상 디스크도 물리적 디스크와 마찬가지로 조각화가 발생할 수 있는데, 크기 제약으로 인해 여러 의미에서 더 심각할 수 있습니다. 또한 가상화 솔루션에서 디스크 또는 파티션의 축소가 가능하다면, 공간을 비우기 위해 또는 최소한 축소 작업에 걸리는 시간을 줄이기 위해서라도 조각 모음을 먼저 수행해야 할 것입니다.

추가 도구
지금쯤은 조각 모음이 매우 중요한 기능이라는 사실을 이해하셨을 것입니다. 조각 모음 자체를 목적으로 타사 도구를 사용하지 않는다 하더라도 Mark Russinovich의 PageDefrag라는 도구는 고려해볼 만합니다. 이 도구는 Microsoft Sysinternals 도구 사이트(microsoft.com/technet/sysinternals/FileAndDisk/PageDefrag.mspx)에서 구할 수 있습니다. 앞서 언급했듯이 Windows 페이지 파일은 Windows가 온라인 상태인 동안에는 조각 모음할 수 없습니다. 그것은 Windows 레지스트리 파일과 이벤트 로그의 경우에도 마찬가지입니다. PageDefrag는 작은 드라이버를 사용하여, Windows가 부팅을 마치고 이러한 파일들을 잠그기 전에 조각 모음을 수행할 수 있게 해줍니다. PageDefrag를 실행하고 다음번 다시 부팅 또는 다시 부팅할 때마다 실행되도록 설정하면 됩니다. 시스템이 다시 부팅되면, (부팅 프로세스 중 전에 디스크 검사가 실행되던 지점에서) 목록에 명시된 파일들의 조각을 모으게 됩니다(그림 6 참고).
그림 6 PageDefrag에서 조각 모음을 수행할 파일들
그림 6 PageDefrag에서 조각 모음을 수행할 파일들
PageDefrag가 완료되면 시스템은 부팅 과정을 정상적으로 마무리합니다. PageDefrag에 대한 자세한 내용은 Lance Whitney가 작성한 9월호 Utility Spotlight를 참고하십시오(technetmagazine.com/issues/2007/09/UtilitySpotlight). 참고로, PageDefrag는 Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003에서만 지원되며 Windows Vista에서는 아직 지원되지 않고 있습니다.
PageDefrag 외에도 Sysinternals에서는 Contig라는 도구도 제공하고 있습니다. 이 도구는 특정 파일을 수작업으로 조각 모음할 수 있게 해줍니다(microsoft.com/technet/sysinternals/FileAndDisk/Contig.mspx). 이 기능은 특정 파일이 일반적인 조각 모음 작업을 통해서는 조각 모음되지 않거나 조각 모음을 완료한 후에 특정 파일만 조각화된 경우에 유용하게 활용할 수 있습니다.
Contig는 또한 와일드카드를 사용하여 디렉터리 또는 하위 디렉터리 전체를 대상으로 조각 모음을 수행할 수 있습니다. 다음 명령은 구체적 위치에 관계없이 Windows 디렉터리 아래의 모든 파일에 대한 조각 모음을 수행합니다.
Contig –s c:\Windows\*.*
–v 스위치를 사용하면 화면에 자세한 정보가 표시되면서 작업이 진행되고 –q 스위치를 사용하면 정보 표시 없이 진행됩니다.

Wes Miller는 텍사스 오스틴에 있는 Pluck(www.pluck.com)의 개발 관리자입니다. 이전에는 오스틴에 위치한 Winternals Software에서 근무했으며 Microsoft에서 프로그램 관리자 및 Windows 제품 관리자로 일하기도 했습니다. 문의 사항이 있으면 technet@getwired.com을 통해 연락하십시오.


 Field Notes: 사용 규정
Field Notes
사용 규정
Betsy Aoki

경우에 따라 사이트 운영자로서 여러분에게 필요한 것은 더 큰 서버나, 주말을 즐기려고 막 떠나기 전에 예의 없이 마구 호출해 대지 않는 양식 있는 사용자가 아닐 수 있습니다. 또는 정작 중요한 문제는 규정을 어떻게 관리하느냐가 아닐 수 있습니다. 이상하게 들리겠지만 이런 경우에는 "큰 물고기"가 필요합니다.
일 년쯤 전에 필자는 Live QnA 사이트(qna.live.com)의 악용 사례 신고 기능에 대한 작업을 진행하고 있었습니다. Delete 단추를 준비해 둔 다음 사이트에서 인신 공격과 부적절한 행위를 모니터링하고 있었습니다. 내부 도구도 있었고, 외부 정책도 있었습니다. 악의적인 콘텐츠로 질문 게시판을 어지럽히는 정신 나간 사람들도 몇 명 경험했습니다.
그러는 와중에 슬슬 지쳐갔습니다. 어쨌든 커뮤니티의 건전성은 필자의 책임이었으니까요. 그리고 사이트의 분위기를 결정하는 사용 규정 작성을 도운 것도 필자였습니다. 사이트의 문지기로서 사용자들이 "예의 바르게" 행동해 주기만을 기대했지요.
안타깝게도 실상은 전혀 달랐습니다. 사람들이 모이면 어쩔 수 없죠. 그 중에는 엄청난 배신 행위를 하는 사람도 있고 마치 성자와 같이 행동하는 사람도 있기 마련입니다. 그리고 다른 사용자를 "병신"이라고 부르는 사람에게 필자의 바람이 무슨 소용이겠습니다.
그러던 어느 토요일에 부엌에 앉아 필자가 지켜내기 위해 안간힘을 쓰고 있는 사용 규정이라는 것에 대해 생각해 보았습니다. 그리고 낙서를 끼적거리다 갑자기 엉뚱한 생각이 떠올랐습니다. "사용 규정(Code of Conduct)" 대신 "선행의 대구(Cod of Conduct)"가 있다면 어떨까? 이 대구는 어떤 모습이고 어떻게 행동할까? 필자가 유년 시절을 보냈던 뉴잉글랜드에서는 대구를 먹습니다. 희고 얇고 특별할 것이 없는 대구. 이 보잘것없고 평범한 대구를 내세워 QnA 회원들을 꾸짖으며 타이르고 싶었습니다. 항상 고민하다가 뒤늦게 사용하게 되는 Delete 단추라는 최후의 수단만을 고집하기보다, 누군가를 웃게 할 수 있는 기발한 재치로 문제 행위를 되풀이하지 않도록 만들 수 있다면 멋질 것이라고 생각한 겁니다. 그렇게, Norbert라는 "선행의 대구"가 탄생하게 되었습니다. Norbert에게 파이프까지 물리고 싶었지만, 나비넥타이만으로도 충분했습니다.
선행의 대구
필자가 그린 물고기 그림을 새 LiveID에 업로드하고 Norbert라는 QnA 사용자 이름을 붙임으로써 QnA 선행의 대구가 활동할 준비를 마쳤습니다. 아, Norbert의 뒤에 필자만 있는 것은 아닙니다. 때로는 다른 팀원이 대구 가면을 쓰고 적발된 사람들을 꾸짖을 수도 있습니다. 선행의 대구가 누구인지 궁금하다고요? go.microsoft.com/fwlink/?LinkId=99044에서 확인해 보십시오. 선행의 대구가 사람들의 기분을 상하게 할까요? go.microsoft.com/fwlink/?LinkId=99045에서 확인하십시오.
QnA 커뮤니티 회원들은 마치... 음... 바다로 나가는 물고기와 같이 Norbert에게 몰려듭니다. 함께 농담을 즐기기도 하고, 급하게 부르기도 하고, 그에게 화를 내기도 하죠. Norbert는 신입 회원을 교육하고, 적절한 훈계를 통해 어둠에서 밝은 세상으로 구원해낼 여지가 있는 사용자들을 꾸짖고, 난해한 법률 용어로 가득한 웹 페이지를 읽는 대신 재미있는 방식으로 규칙을 확인할 수 있도록 합니다.
회사 정책이든, 어느 집단의 법이든, 놀이터의 서열이든, 모든 규칙의 존재 가치는 그 강제성을 느끼는 사람들의 선의에 달려 있습니다. IT 담당자나 커뮤니티 웹 사이트 개발자로서, 규칙 적용을 지원할 도구를 만들 수도 있지만 때로는 사용자 자신의 인간성이나 해당 집단 내에서 자연스럽게 형성된 공통의 도덕 기준이 최상의 도구가 될 수 있습니다. 기술 공학보다 약간의 사회 공학적 손질이 더 효과적일 수 있습니다. 우리의 경우에는 손질과 물고기가 되겠지요.

Betsy Aoki는 Microsoft의 커뮤니티 프로그램 관리자로 Xbox 팀을 담당하고 있습니다. XNA Framework에 대한 그녀의 열정은 전자 메일이나 블로그 게시물에 잘 나타나 있습니다.


 Windows Confidential: 파일 시스템의 모순
Windows Confidential
파일 시스템의 모순
Raymond Chen

하드 드라이브를 살펴보면 아마도 많은 운영 체제 파일이 부팅 드라이브의 루트 디렉터리에 있음을 알 것입니다. 이러한 파일을 더욱 자세히 살펴보면 boot.ini, NTLDR 및 NTDETECT.COM은 중요한 부팅 파일이고 hiberfil.sys는 최대 절전 모드 파일이라는 것을 알 수 있습니다. 이들은 모두 운영 체제 부팅이나 최대 절전 모드 해제(hiberfil.sys의 경우)의 중요한 첫 번째 단계에 사용되는 파일로 부팅 드라이브의 루트에 있어야 합니다. 이러한 파일을 다른 위치로 이동할 수 없는 이유는 무엇일까요?
필자의 동료인 Adrian Oney의 설명에 따르면 디스크에서 부팅 파일을 읽으려면 파일 시스템 드라이버가 필요한데, 파일 시스템 드라이버는 파일 시스템 드라이버를 로드한 후에야 읽을 수 있는 디스크에 있다고 합니다. 이런 모순이 있을까요?
이렇게 순환되는 불합리적 문제는 간단한 파일 시스템 드라이버가 중요한 부팅 파일에 기본 제공됨으로써 해결됩니다. 이 간단한 드라이버는 루트 디렉터리에서 파일을 찾아 메모리에 로드할 수 있을 만큼의 정보만 알고 있습니다. 그런 다음 이러한 파일에서 운영 체제를 시작할 수 있는데, 이때 실제 파일 시스템 드라이버가 인계를 받아서 하위 디렉터리와 같은 훨씬 더 세분화된 위치에서 파일을 찾을 수 있습니다.
최대 절전 모드도 비슷한 양상을 따릅니다. 운영 체제를 최대 절전 모드로 전환하면 메모리의 전체 콘텐츠가 최대 절전 모드 파일에 덤프되고, 최대 절전 모드를 해제하면 해당 파일이 메모리에 다시 로드되고 아무 일도 일어나지 않은 듯이 정상적으로 작동합니다. 이것은 또 다른 닭과 달걀의 문제입니다. 즉, 최대 절전 모드 파일을 로드하려면 파일 시스템 드라이버가 필요한데, 파일 시스템 드라이버는 최대 절전 모드 파일에 있습니다. 최대 절전 모드 파일을 부팅 드라이브의 루트 디렉터리에 보관하면 간단한 파일 시스템 드라이버를 대신 사용할 수 있습니다.
MS-DOS®의 초기 버전을 사용했다면 운영 체제 부팅 파일의 위치에 대한 이러한 제약 조건을 잘 알고 있을 것입니다. 이전 SYS 명령을 사용하면 평범한 플로피 디스크를 놀라운 부팅 가능 플로피 디스크로 만들 수 있었습니다. 하지만 이미 데이터가 들어 있는 플로피 디스크에서 실행한 경우 MS-DOS의 초기 버전에서는 부팅 파일이 플로피 디스크 상의 특정 위치에 있어야만 부팅 섹터가 해당 파일을 찾을 수 있었기 때문에 변환이 실패할 가능성이 있었습니다. MS-DOS의 후기 버전에서는 부팅 로더를 개선하여 이러한 요구 사항을 완화했지만 개선된 버전의 경우에도 시스템 파일이 여전히 루트 디렉터리에 있어야 합니다.
"최대 절전 모드 파일을 하위 디렉터리로 이동할 수 있나요?"라고 묻는 고객이 있었습니다. 이러한 경우 파일 위치는 문제가 되지 않습니다. 파일을 어디에 저장하든 파일의 ACL은 같을 것입니다. 그러나 이러한 질문을 한 사람들은 부팅 드라이브와는 다른 드라이브에 파일을 저장하기를 원했고 결국 그렇게 할 수 없다는 대답을 들었습니다. 이들은 정말로 이 제한 사항의 이유를 이해하지 못하고 교묘히 회피하려고 했습니다. 필자는 어쨌든 최대 절전 모드 파일을 하위 디렉터리로 이동할 수 있다는 가정하에 디렉터리를 만들어 정말로 최대 절전 모드 파일을 저장할 위치를 가리키는 연결 지점으로 지정했습니다. 놀랍게도 최대 절전 모드 파일이 다른 위치로 옮겨졌습니다.
물론 탑재 지점은 디스크 관리 서비스와 통신함으로써 알 수 있기 때문에 간단한 파일 시스템 드라이버는 탑재 지점을 파악하지 못합니다. 그리고 시스템이 부팅될 때 운영 체제가 컴퓨터에 미처 로드되지 않은 상태이고 드라이브 문자를 ARC 경로에 다시 매핑하는 방법을 알고 있는 뛰어난 기능의 고급 서비스가 거의 없으며 어떻게 해서든지 이러한 서비스를 실행 중인 상태로 만들었다고 해도 여전히 이러한 다른 하드 드라이브의 장치 드라이버를 찾고 해당 파일 시스템 드라이버를 로드해야 합니다.
누군가가 최대 절전 모드 파일을 DFS 연결 지점에 넣는 방법을 요청하는 것은 시간 문제일 뿐입니다.

Raymond Chen은 The Old New Thing 웹 사이트와 동명의 저서(Addison-Wesley, 2007)에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있습니다. 그의 Web 2.0 이름은 Raymond 또는 Chester일 것입니다.