 TechNet Magazine January 2007
TechNet Magazine January 2007
JANUARY 2007
SharePoint

이달의 TechNet Magazine은 SharePoint 및 새로 출시된 제품에서 새롭게 제공되는 여러 기능에 전면을 할애합니다. SharePoint Server 2007을 소개하며 보다 쉽게 뛰어난 공동 작업 사이트를 구축할 수 있는 새로운 기능을 안내합니다. 개요 기사에서는 엔터프라이즈 수준의 검색 및 문서 관리 이외에 다양한 내용을 다룹니다. 또한 SharePoint에서의 보안, 빠른 명령줄 관리 작업, SharePoint를 사용하는 조직을 위한 Wiki 구축 관련 기사도 제공합니다. 뿐만 아니라 Raymond Chen의 'DLL 지옥 탈출' 및 .NET Framework의 DataList.Sort 메서드를 사용한 VBScript 정렬을 다룬 'Scripting Guys' 같은 인기 칼럼도 소개합니다.

주요 기사
SharePoint Microsoft Office SharePoint Server 2007 개요

새 버전의 SharePoint는 공동 작업 및 정보 관리에 필요한 모든 기능을 하나의 통합된 플랫폼에서 제공하도록 만들어졌습니다. 여기에서는 기업 작업 환경에 큰 변화를 가져올 MOSS의 새로운 기능 및 도구에 대해 살펴봅니다.

Thomas Rizzo 보안을 강화하는 SharePoint의 7가지 새로운 기능

SharePoint가 더 많은 엔터프라이즈 데이터에 관여하고 비즈니스 워크플로의 필수적인 요소로 자리잡으면서 보안의 중요성도 훨씬 높아지고 있습니다. MOSS의 새로운 7가지 기능을 사용하여 더 신속하게 조직의 보안을 강화하는 방법을 확인해 보십시오.

Adam Robert Buenz SharePoint 엔터프라이즈 검색을 사용한 정보 검색

직원이 정보를 찾는 동안 기업의 시간과 비용이 낭비되고 있습니다. 이를 해결할 수 있는 방법이 바로 엔터프라이즈 검색입니다. MOSS는 인트라넷 사이트에 숨겨져 있거나 업무용 응용 프로그램에 사용되거나 심지어 직원 개개인이 소유한 모든 정보를 빠르게 찾을 수 있는 엔터프라이즈 검색 도구를 제공합니다.

Matt Hester SharePoint를 위한 강력한 명령줄 관리

GUI에 얽매일 필요는 없습니다. SharePoint를 관리하는 더욱 강력하고 빠른 방법이 있습니다. 이 방법을 사용하면 명령 프롬프트에서 관리 작업을 수행할 수 있고 공통적으로 사용되는 절차를 스크립트로 작성할 수도 있습니다.

Todd Klindt 작업에 Wiki 활용

Wiki는 공동 작업의 융통성을 높일 수 있는 새로운 방법으로, Wiki를 활용하면 구조화되지 않은 방식으로 새로운 아이디어를 생각해내고 이를 교환할 수 있습니다. 이러한 Wiki는 MOSS 2007을 사용하여 조직 내에 쉽게 구현할 수 있습니다. 조직에서 Wiki를 구축하고 사용하려면 다음과 같은 점을 알아야 합니다.

Mauro Cardarelli
칼럼
From The Editor

Joshua Trupin Toolbox

IT 전문가를 위한 새로운 제품

Greg Steen Utility Spotlight

Internet Explorer Administration Kit

Lance Whitney SQL Q+A

데이터 보관, 연결된 서버, 대역폭 측정 및 기타 정보

편집자: Nancy Michell The Cable Guy

TCP 수신 창 자동 조정

Joseph Davies Windows PowerShell

Windows PowerShell 구문

Don Jones 		Hey, Scripting Guy!

말 조심하세요

Microsoft Scripting Guys Exchange Queue & A

우리는 모든 답을 알고 있어요. 바로 우리가 질문한 거거든요.

KC Lemson 및 Paul Bowden Security Watch

Windows Vista의 서비스 보안 강화

Wole Moses The Desktop Files

Windows Automated Installation Kit

Wes Miller Field Notes

처가 식구들에 대한 기술 지원

James Snell Windows Confidential

DLL 지옥 탈출

Raymond Chen


 SharePoint: Microsoft Office SharePoint Server 2007 개요
SharePoint Thomas Rizzo

Microsoft Office SharePoint Server 2007 개요
한 눈에 보기:
  • SharePoint 웹 통합
  • 콘텐츠 관리
  • 비즈니스 인텔리전스

Microsoft가 정의하는 "차세대 업무 환경"에서는 크게 두 가지 현상으로 인해 비즈니스 운영 방식이 달라지고 있습니다.
첫 번째는 공동으로 작업하는 팀 구성원들이 서로 다른 위치, 그리고 서로 다른 시간에 작업하는 경우가 늘어나고 있다는 점입니다. 따라서 전세계적으로 분산된 작업 환경을 하나로 연결하기 위한 공동 작업 소프트웨어의 중요성이 증가하고 있습니다. 다른 한 가지는 디지털 정보의 사용이 폭발적으로 증가하면서 이러한 비즈니스 데이터와 관련하여 준수해야 할 규칙도 더욱 복잡해지고 있다는 점입니다. 이로 인해 각 회사에서는 공동 작업 및 공유를 가능하게 하는 동시에 정보의 보안을 유지하고 개인 정보를 보호하기 위해 많은 노력을 기울이고 있습니다. 따라서 회사의 정보 및 인적 자원을 최대한 활용하기 위해서는 시간대와 지리적인 장벽을 초월한 통신, 효과적인 공동 작업 도구, 안전한 데이터 처리 기능 등의 요구 사항을 모두 충족하는 솔루션이 절대적으로 필요합니다.
Microsoft® Office SharePoint® Server(MOSS) 2007은 다양한 기술을 하나의 통합된 플랫폼과 엔터프라이즈 서비스로 제공합니다. 이러한 기술은 공동 작업부터 포털, 엔터프라이즈 검색 및 워크플로와 비즈니스 프로세스에 이르기까지 매우 다양합니다. MOSS는 Windows® SharePoint Services(WSS)를 기반으로 하는 차세대 SharePoint Portal Server(SPS)입니다. 그림 1의 원형 차트는 MOSS와 WSS가 함께 작동하는 방식을 이해하기 쉽게 보여 줍니다. 이 그림에서 녹색 영역은 WSS에서 제공하는 것이며 MOSS는 WSS를 기반으로 하기 때문에 차트에 있는 전체 기능은 MOSS에서 제공합니다. 여기서 볼 수 있듯이 MOSS에서는 포털, 검색, 엔터프라이즈 콘텐츠 관리, 비즈니스 프로세스와 양식 및 비즈니스 인텔리전스 부분을 제공합니다.
그림 1 MOSS 및 WSS의 서비스
그림 1 MOSS 및 WSS의 서비스 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 MOSS 및 WSS의 서비스
그림 1 MOSS 및 WSS의 서비스 (더 크게 보려면 이미지를 클릭하십시오.)
이 문서의 나머지 부분에서는 MOSS의 주요 기술을 하나씩 살펴보고, 이러한 향상된 기능을 통해 사용자의 생산성을 높일 수 있는 방법을 설명합니다.

SharePoint와 Web 2.0의 통합
AJAX, RSS, 블로그, Wiki 등과 같은 인터넷 기술은 Web 2.0, Enterprise 2.0, 복합 응용 프로그램, 커뮤니티 기반 콘텐츠 등 여러 가지로 불리지만 모두 사용자가 콘텐츠, 공동 작업, 데이터 흐름 방식 등을 효과적으로 제어하는 데 유용합니다. 더 나아가 사용자는 Windows의 대화형 작업 방식과 웹이 제공하는 배포 및 사용의 용이성을 동시에 원합니다. 그러나 인터넷의 개념을 엔터프라이즈 환경에 그대로 적용한다면 새로운 문제가 발생할 것입니다. 예를 들어 서비스의 원본을 확인하고 신뢰할 수 있는지 또는 기존 인프라에 서비스를 아무 문제 없이 통합할 수 있는지 한번 생각해 볼 필요가 있습니다.
MOSS 2007은 몇 가지 새로운 기능을 제공하며, 문서 관리, 경고 등의 기본 제공 기능 및 블로그(그림 2 참조)와 Wiki, RSS 피드를 게시하고 받는 데 사용되는 웹 파트 등과 같이 새로 추가된 기능을 통해 기존의 공동 작업 플랫폼의 기능을 향상했습니다. Microsoft Office Outlook® 2007을 사용하는 경우에는 Outlook과 Microsoft SharePoint 사이에 일정, 작업, 연락처 등의 공동 작업 데이터를 양방향으로 동기화할 수 있습니다. 연락처나 약속을 변경해야 할 경우 Outlook 또는 SharePoint 중 하나에서 내용을 수정하면 상대 프로그램에 변경 내용이 자동으로 표시됩니다.
그림 2 MOSS 2007에서 지원하는 블로그 및 Wiki
그림 2 MOSS 2007에서 지원하는 블로그 및 Wiki (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 MOSS 2007에서 지원하는 블로그 및 Wiki
그림 2 MOSS 2007에서 지원하는 블로그 및 Wiki (더 크게 보려면 이미지를 클릭하십시오.)
Outlook에서도 문서 라이브러리를 오프라인 상태로 사용할 수 있습니다. 즉, 네트워크에 연결되어 있지 않은 상태에서 문서를 변경한 후 나중에 온라인 상태가 되었을 때 해당 변경 내용을 동기화할 수 있습니다.
또한 MOSS에는 이러한 새 기능으로 인해 관리 및 보안 기능이 저하되지 않도록 커뮤니티 기반 콘텐츠와 관련하여 준수해야 할 규칙을 감사하고 적용하는 기능도 포함되어 있습니다.
포털 환경에서의 향상된 개인 설정 기능은 MOSS 2007의 주요 개선 사항 중 하나입니다. MOSS에는 SharePoint 사이트의 모든 기능을 완벽히 활용하는 새롭게 개선된 내 사이트가 추가되었습니다. 사용자는 자신의 내 사이트에 목록, 문서 라이브러리 또는 하위 사이트를 만들 수 있고 이러한 사이트의 개인 보기 및 작업 그룹 보기 방식을 사용자 지정할 수 있습니다. 내 사이트에서는 동료의 메타데이터(예: 전화 번호, 직함, 사무실 위치 등의 정보)가 변경된 경우에 경고 메시지를 표시하는 기능을 비롯하여 동료 추적 및 조직 계층 구조에 사용할 수 있는 새로운 웹 파트도 제공합니다. 그림 3에서는 MOSS의 사용자 지정 내 사이트를 보여 줍니다.
그림 3 다양한 SharePoint 주요 기능을 지원하는 내 사이트
그림 3 다양한 SharePoint 주요 기능을 지원하는 내 사이트 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 다양한 SharePoint 주요 기능을 지원하는 내 사이트
그림 3 다양한 SharePoint 주요 기능을 지원하는 내 사이트 (더 크게 보려면 이미지를 클릭하십시오.)

엔터프라이즈 검색
하드 드라이브가 작았을 때는 여러 가지 데이터가 어디에 저장되었는지 기억하는 데 별 문제가 없었습니다. 그러나 저장소가 커지고 이러한 저장소에 데이터를 저장하는 사용자가 셀 수 없을 만큼 늘어나면서 검색 기능은 모든 정보 설계에 있어 중요한 구성 요소가 되었습니다. MOSS에서는 SPS 2003에 처음 도입된 검색 플랫폼을 기반으로 하여 향상된 엔터프라이즈 리포지토리 검색 기능을 제공합니다. MOSS 2007에서도 파일 공유, 웹 사이트, Exchange Server, Lotus Notes 리포지토리 등의 구조화되지 않은 데이터 리포지토리에 대해 크롤링을 수행합니다.
SPS 초기 버전에서는 비즈니스 응용 프로그램이나 관계형 데이터베이스같이 구조화된 리포지토리를 검색하는 것이 쉽지 않았습니다. 또한 구조화된 리포지토리와 구조화되지 않은 리포지토리는 각 직원이 조직에 제공하는 메타데이터와 전문적인 지식으로 채워졌습니다. 그러나 MOSS에서는 BDC(비즈니스 데이터 카탈로그)라고 하는 새로운 기술을 통해 구조화된 리포지토리를 검색하고 새로운 지식 네트워크를 통해 사람 및 전문적인 지식을 검색합니다.
BDC를 사용하면 ADO.NET 공급자나 웹 서비스를 통해 데이터를 제공하는 시스템에 연결하여 크롤링하고 검색할 수 있습니다. BDC를 사용하려면 연결하려는 대상 시스템에 대한 정보가 들어 있는 XML 구성 파일을 만들어야 하는데 이 파일에는 서버 또는 연결 대상의 이름, 대상 시스템에서 개체를 열거하고 가져오는 방법, 백 엔드 시스템에서 지원하는 필터링 기능, 백 엔드 데이터를 SharePoint 데이터에 매핑하는 방법 등을 포함할 수 있습니다. XML 구성 파일이 준비되면 다른 엔터프라이즈 리포지토리를 크롤링할 때와 마찬가지로 SharePoint의 엔터프라이즈 검색 기능을 사용하여 BDC 데이터를 검색할 수 있습니다.
기본적으로 SharePoint는 백 엔드 시스템에서 검색한 각 비즈니스 엔터티에 대해 프로필 페이지를 만듭니다. 이러한 프로필 페이지도 SharePoint의 다른 페이지를 사용할 때와 마찬가지로 사용자 지정할 수 있습니다. 그림 4에서는 비즈니스 데이터와 기타 정보를 함께 반환하는 사용자 지정 프로필 페이지를 보여 줍니다. SharePoint에 포함된 다양한 비즈니스 데이터 웹 파트를 사용하면 페이지에 BDC 데이터를 표시하고, 필요한 경우에는 사용 가능한 메타데이터를 기준으로 해당 페이지에서 데이터를 필터링할 수 있습니다. 비즈니스 데이터는 SharePoint에 매핑되기 때문에 새로 추가된 비즈니스 데이터 열 형식을 사용하여 SharePoint 목록에서 비즈니스 데이터를 액세스할 수 있습니다. 또한 목록에 있는 데이터는 신뢰할 수 있는 백 엔드 시스템에서 가져온 것이므로 데이터 입력 오류나 데이터 정리 작업이 더 이상 발생하지 않습니다.
그림 4 백 엔드 서비스에서 SharePoint 페이지로 비즈니스 데이터 가져오기
그림 4 백 엔드 서비스에서 SharePoint 페이지로 비즈니스 데이터 가져오기 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 백 엔드 서비스에서 SharePoint 페이지로 비즈니스 데이터 가져오기
그림 4 백 엔드 서비스에서 SharePoint 페이지로 비즈니스 데이터 가져오기 (더 크게 보려면 이미지를 클릭하십시오.)
지식 네트워크를 사용하면 사람과 전문적인 지식을 효과적으로 검색할 수 있습니다. 지식 네트워크 기능은 엔터프라이즈 내의 인적 네트워크를 기초로 이러한 검색 작업을 수행합니다. 대부분의 경우 자신이 현재 담당하는 업무에 도움을 줄 수 있는 전문가가 있으면 각 직원은 생산성을 훨씬 높일 수 있을 것입니다. 그러나 주변에 이러한 지식을 가진 동료가 없으면 이와 같은 지식을 찾는 것을 포기하기 쉽습니다. 지식 네트워크는 엔터프라이즈의 실제 조직 네트워크를 사용하는 대신 조직의 인적 지도를 작성하여 이 인적 네트워크 검색할 수 있도록 합니다. 필요한 경우 사회적 거리를 기준으로 결과를 정렬하고 직함이나 부서 같은 메타데이터 속성을 기준으로 필터링할 수도 있습니다.
지식 네트워크는 사람과 그 사람의 개인 식별 정보를 사용하는 다른 솔루션과 마찬가지로 사용자가 네트워크에 직접 등록하고 네트워크에 표시할 정보와 해당 정보를 볼 수 있는 대상을 제어할 수 있도록 강력한 보안 및 개인 정보 보호 모델을 제공합니다. 지식 네트워크는 사용자의 서버 측 정보(예: SharePoint 내 사이트)를 크롤링하고 Outlook과 인스턴트 메시징에 연결하는 클라이언트 측 구성 요소를 통해 사용자 전자 메일과 연락처를 크롤링합니다. 클라이언트 측에서는 크롤링 일정 및 클라이언트 크롤링을 통해 서버 프로필에 게시할 내용을 사용자가 제어할 수 있습니다. 전문 지식 검색 시스템의 결점 중 하나는 인적 정보가 항상 최신 상태로 업데이트되어 있어야 한다는 점인데 지식 네트워크를 사용할 경우에는 소프트웨어가 모든 정보 업데이트를 관리하므로 사용자는 해당 데이터의 표시 여부와 액세스 가능 여부만 제어하면 됩니다.

엔터프라이즈 콘텐츠 관리
MOSS 2007에서는 문서 관리 기능 이외에 레코드, 웹 콘텐츠, 전자 양식 등에 대한 관리 기능을 추가하여 강력한 엔터프라이즈 콘텐츠 관리 솔루션을 제공합니다. SharePoint 레코드 관리 기능에는 콘텐츠 보관, 감사, 바코드 지정, 레이블 지정 등과 같이 조건에 맞는 관리 리포지토리를 만들 수 있는 기능이 있습니다. Exchange Server와의 긴밀한 통합으로 레코드 리포지토리에는 SharePoint에서 만들고 저장한 정보뿐 아니라 전자 메일 메시지도 정식 레코드로 포함할 수 있습니다. 레코드 관리 기능을 사용하면 레코드를 검색하여 법적 증거를 손쉽게 제시할 수 있습니다. 또한 법적 절차로 인해 보관 정책에 지정된 기간보다 콘텐츠를 오랫동안 보관해야 하는 경우 보관 정책에 관계없이 콘텐츠를 법적 콘텐츠로 따로 보관할 수 있습니다.
MOSS 2007은 웹 콘텐츠 관리 측면에서 Microsoft Content Management Server 2002를 대신합니다. 따라서 이제는 SharePoint를 사용하여 인트라넷부터 익스트라넷과 인터넷 사이트에 이르기까지 다양한 웹 관련 작업을 수행할 수 있습니다. SharePoint에는 이러한 기능이 모두 포함되어 있으므로 SharePoint 하나만 인프라 전체에 적용하면 됩니다. SharePoint에는 콘텐츠 배포 기능이 있어 테스트 서버와 배포 서버를 따로 둘 수 있습니다. 뿐만 아니라 SharePoint는 ASP.NET 2.0 마스터 페이지를 지원하기 때문에 사이트를 사용자 지정하기도 훨씬 쉽습니다. 또한 SharePoint는 사이트 변형 기능을 지원하므로 다중 언어 시나리오를 구현해야 할 경우 단일 사이트에 대해 변형 사이트를 여러 개 만든 후, 페이지를 보는 브라우저 클라이언트의 언어 설정에 따라 적절한 언어 버전으로 자동으로 리디렉션할 수 있습니다.
SharePoint에 새로 추가된 InfoPath® Forms Services 기능을 사용하면 InfoPath 양식을 전자 양식으로 변환할 수 있습니다. InfoPath 양식을 전자 양식으로 변환하려면 InfoPath 양식을 만들고, 웹에서 사용할 수 없는 기능을 사용할 경우 경고 메시지를 표시하도록 설정하는 확인란을 디자이너에서 선택한 다음 SharePoint 목록의 신뢰할 수 있는 위치에 양식을 저장해야 합니다. 이렇게 하면 다른 사용자가 웹 브라우저만으로 양식을 보고 편집하거나 전송할 수 있습니다.
SharePoint에 저장하는 콘텐츠에 워크플로를 포함할 수 있는 기능을 원하는 고객이 많은 것에서 알 수 있듯이 SPS 2003 사용자가 기능에 대해 주로 요청한 사항은 워크플로의 기능을 개선하라는 것이었습니다. MOSS는 향상된 워크플로를 제공하는 데 그치지 않고 .NET Framework 3.0의 새로운 Windows Workflow Foundation 기능도 제공합니다. 따라서 Windows Workflow Foundation을 기반으로 워크플로를 만들어 SharePoint에서 활용할 수 있습니다. SharePoint에는 Windows Workflow Foundation을 호스팅하는 기능 외에 문서 승인 워크플로, 문서 서명 워크플로 등과 같은 기본 워크플로도 다수 포함되어 있습니다. 그림 5에서는 MOSS에서 기본 워크플로를 구성하는 방법을 보여 줍니다.
그림 5 MOSS에서 워크플로 설정
그림 5 MOSS에서 워크플로 설정 (더 작게 보려면 이미지를 클릭하십시오.)
그림 5 MOSS에서 워크플로 설정
그림 5 MOSS에서 워크플로 설정 (더 크게 보려면 이미지를 클릭하십시오.)
MOSS에서는 워크플로 모니터링을 통해 현재 작업 상태는 물론 작업 기록도 볼 수 있습니다. 또한 SharePoint와 Office 클라이언트와의 통합을 통해 최종 사용자는 사용 중인 Office 응용 프로그램에서 워크플로를 시작할 수 있습니다. 뿐만 아니라 Office 응용 프로그램에서 자신에게 할당된 워크플로 작업을 신속하게 확인하고 해당 작업을 완료할 수 있습니다.
MOSS의 기능은 비즈니스 인텔리전스 포털까지도 확장됩니다. 일반적으로 이러한 포털에는 보고서, 차트, 정렬하고 필터링할 수 있는 데이터 테이블 및 데이터 상태를 시각적으로 표시하는 데 도움이 되는 그래픽이 포함될 수 있습니다. MOSS를 사용하면 BI(비즈니스 인텔리전스) 대시보드 서식 파일을 사용하여 새 페이지를 만드는 것으로 비즈니스 인텔리전스 포털을 매우 손쉽게 만들 수 있습니다. 기본적으로 BI 대시보드에는 KPI(핵심 성과 지표) 목록과 Excel® 웹 액세스 웹 파트가 포함되어 있습니다.
KPI 목록은 MOSS에 새로 추가된 목록 형식으로, 이 목록을 사용하면 Excel, SQL Server™ Analysis Services, SharePoint 목록, 직접 입력한 정보 등의 정보 원본에 연결하고 이러한 데이터 원본에서 KPI를 추적할 수 있습니다. KPI 목록에는 표시기를 사용하여 현재 값, 목표 값, 추세 및 상태가 표시됩니다.
Excel 웹 액세스는 MOSS에 포함된 Excel 서비스의 일부로, Excel 서비스는 웹 브라우저를 통해 Excel 정보를 계산하고 표시하는 데 사용할 수 있는 서버 측 버전의 Excel입니다. Excel 서비스를 사용하려면 Excel 데스크톱 응용 프로그램에서 SharePoint의 신뢰할 수 있는 위치에 스프레드시트를 직접 게시해야 합니다. 그러면 다른 사용자가 웹 브라우저를 통해 Excel 스프레드시트나 차트를 볼 수 있습니다. 매개 변수나 필터링이 사용된 경우에는 이러한 기능을 적용하여 웹 브라우저에서 렌더링하는 Excel 정보를 수정할 수 있습니다.

추가 정보
이 문서에서 설명한 기능은 MOSS에 새로 도입된 다양한 기능 중 극히 일부에 불과하므로 필요한 경우 다른 온라인 리소스를 통해 더 많은 정보를 확인할 수 있습니다. MOSS에 대한 자세한 내용을 보려면 SharePoint Team Blog(영문) 및 SharePoint Server TechCenter(영문)를 참조하십시오.

Thomas Rizzo는 Microsoft에서 SharePoint 그룹의 책임자로 일하고 있습니다. 이전에는 SQL Server 및 Exchange Server 그룹에서 근무했으며 지금까지 4권의 책을 저술했습니다. 문의 사항이 있으면 thomriz@microsoft.com으로 연락하십시오.
© 2007 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


 SharePoint: 보안을 강화하는 SharePoint의 7가지 새로운 기능
SharePoint Adam Robert Buenz

보안을 강화하는 SharePoint의 7가지 새로운 기능
한 눈에 보기:
  • 인증 공급자
  • 네이티브 암호화 기능
  • 대체 액세스 매핑 및 영역
  • 정보 권한 관리

Microsoft Office SharePoint Server(MOSS) 2007 환경에 효과적인 보안 기능을 구현하면 관리 부담을 현저하게 줄일 수 있을 뿐만 아니라
팀이 안전한 환경에서 공동 작업을 수행하고 비즈니스 데이터를 공유할 수 있습니다. MOSS 2007이 기본적으로 제공하는 혁신적인 인증 기능을 사용하면 사용자 지정 인증 공급자를 통한 웹 기반의 보안 표준, 인터넷 스타일의 폼 기반 인증 및 웹 SSO(Single Sign-On)를 구현할 수 있습니다. 더 나아가 MOSS는 2007 Microsoft® Office system 파일과 같은 비즈니스 자산에 대한 세부적인 권한 관리 및 네이티브 암호화 기능을 제공하고 클라이언트 인증 의무를 완화합니다.
다음은 신속하게 적용할 수 있는 MOSS 2007의 7가지 보안 기능입니다.
1. 플러그형 인증 공급자 인증 공급자는 사용자 자격 증명을 확인하는 데 사용할 수 있는 구성 요소입니다. 인터넷 스타일의 SharePoint® 인증을 설정하는 경우 MOSS 환경에 사용할 인증 공급자를 구성하는 작업은 보안상 매우 중요한 결정 사항입니다. MOSS는 실제 Windows ID로 사용자를 확인하는 통합 인증 및 기본 인증을 비롯하여 이전 버전의 SharePoint에서 사용할 수 있는 Windows® 기반 인증 방식을 계속해서 지원하며, 이번 버전에는 다이제스트 인증이 추가되었습니다. 그러나 이제는 Windows ID 확인 외에 선택의 폭이 넓어졌습니다. 또한 필요한 경우 인증 공급자를 여러 개 적용하여 내부 사용자는 Windows 인증을 사용하여 로그인하고 외부 사용자는 별도의 플러그형 공급자를 사용하여 로그인하도록 구성할 수도 있습니다.
MOSS는 ASP.NET 2.0을 기반으로 구축되어 플러그형 인증 공급자도 지원하기 때문에 구성원 데이터 저장소에 해당하는 ASP.NET 2.0 그룹 등록 공급자와 역할 공급자(선택 사항)가 있으면 구성 가능한 디렉터리에 사용자 정보를 저장할 수 있습니다. machine.config 파일에서 그룹 등록 공급자에 해당하는 노드 값에 따라 플러그형 공급자 자격 증명을 해시 또는 암호화하거나 일반 텍스트 형식으로 저장할 수 있습니다. MOSS에서는 LDAP V3 그룹 등록 공급자(기본 제공), SQL Server™ 그룹 등록 공급자, ASP.NET 2.0과 함께 사용할 수 있는 Active Directory® 그룹 등록 공급자 등을 포함하여 다양한 그룹 등록 공급자를 사용할 수 있습니다.
기본 제공되는 그룹 등록 공급자와 역할 공급자 외에 다른 공급자를 구현할 수도 있습니다. 예를 들어 ASP.NET 2.0 그룹 등록 아키텍처를 사용하면 Microsoft Access™ 또는 Oracle 데이터베이스, XML 파일, 기본 텍스트 파일 등의 그룹 등록 저장소를 사용하는 사용자 지정 공급자를 만들 수 있습니다. 사용자 지정 인증 공급자는 ProviderBase 클래스에서 상속되는 ASP.NET MembershipProvider 인터페이스에서 상속됩니다(그림 1 참조).
그림 1 .NET 그룹 등록 클래스 계층 구조
그림 1 .NET 그룹 등록 클래스 계층 구조
MOSS에서 ASP.NET 2.0 인증을 사용할 경우에는 Windows 인증과 비교하여 몇 가지 차이점을 고려해야 합니다. 대부분의 사용자가 느끼는 가장 큰 차이점은 Microsoft Office 클라이언트 상호 운용이 감소한다는 점인데 이는 MOSS와 Office 클라이언트 간의 웹 서비스 통신이 원래 Windows ID에 사용하도록 만들어졌기 때문입니다.
또한 콘텐츠 크롤링 및 인덱싱 관련 서비스를 비롯한 일부 MOSS 서비스는 플러그형 공급자를 사용하는 경우에도 Windows 계정을 사용해야 합니다. Windows ID를 확인하지 않는 인증 형식을 사용하여 이와 같이 하려면 Windows 인증을 사용하는 별도의 MOSS 영역을 만들어야 합니다. 영역에 대해서는 이 문서의 뒷부분에서 설명하겠습니다.
스마트 카드처럼 공개 키나 인증서가 클라이언트에 저장되는 보안 메커니즘을 기반으로 하는 PKI 인프라를 사용할 경우 구현 방식에 따라서는 Windows ID를 확인해야만 제대로 클라이언트 인증서를 허용하고 권한을 부여할 수 있습니다. 이 경우 MOSS 영역을 추가로 만들거나 다른 인증 구성을 사용해야 할 수 있습니다.
2. 폼 기반 인증 및 웹 SSO(Single Sign-On) MOSS 2007에서 사용할 수 있는 또 다른 인증 메커니즘으로는 ASP.NET 2.0을 기반으로 하는 폼 기반 인증이 있습니다. 이전 버전의 SharePoint에서는 사용자 지정 ISAPI(인터넷 서버 응용 프로그래밍 인터페이스) 확장을 사용하거나 IIS 6.0 도구 키트의 CustomAuth ISAPI 확장을 적용하는 방법으로만 이 인증 메커니즘을 구현할 수 있었습니다. 그러나 이러한 방법으로 구현하더라도 SharePoint에서는 Windows 사용자 ID를 통해 계정을 다시 확인해야 하기 때문에 경계 네트워크에 배포하는 데 제약이 있습니다.
폼 기반 MOSS 인증에서는 플러그형 인증 및 역할 공급자를 사용하여 기존의 NT 로그인 프롬프트 방식에서 벗어나 인터넷 스타일의 보안 메커니즘을 구현할 수 있습니다. 폼 기반 인증을 사용하면 사용자의 필요에 맞게 사용자 지정된 로그인 프로세스를 만들 수 있습니다. 이때 인증 프로세스를 보호하기 위해 암호화되고 변조가 불가능한 폼 인증 쿠키와 인증 티켓이 사용됩니다.
폼 ID 공급자는 로컬 위치에 있을 필요 없이 외부 ID 관리 시스템에 플러그 인할 수 있고, 이 경우 해당 외부 ID 관리 시스템에서 사용자 자격 증명을 확인합니다. 웹 Single Sign-On이라고 하는 이 기능은 HTTP 모듈을 사용하여 외부 인증을 수행합니다. 이러한 시나리오에서는 사용자의 조직과 비즈니스 파트너 간에 ID를 연결하여 해당 사용자가 자신이 속한 조직의 로그인 정보를 통해 MOSS에 로그인할 수 있습니다.
3. MOSS 응용 프로그램 연결 문자열 암호화 중요한 연결 문자열 정보를 web.config 파일에 일반 텍스트로 저장하는 것은 보안상 매우 위험합니다. 이렇게 정보를 노출하면 다른 사용자가 SQL 데이터베이스 서버에 대한 개체 인스턴스를 만들어 중요한 데이터를 조작할 수 있습니다. 그러나 기본 ASP.NET 2.0 기능을 사용하면 두 가지 기술, 즉 Windows DPAPI(데이터 보호 API) 또는 RSA 암호화 중 하나를 사용하여 데이터를 암호화할 수 있습니다. DPAPI는 Windows에 기본 제공되는 암호화 기능을 활용하여 MOSS 서버 시스템 키로 암호화/암호 해독을 실행합니다. RSA 암호화를 사용하면 공개 키 알고리즘을 사용할 수 있지만 암호화 키를 저장할 컨테이너가 필요하므로 추가적인 오버헤드가 발생합니다.
MOSS 2007, 구체적으로 말하자면 플러그형 ASP.NET 2.0 SQL Server 인증 공급자의 경우 가장 심각한 보안 위반이 발생할 가능성이 있는 <connectionStrings> 노드를 암호 텍스트로 암호화하는 것이 좋습니다.
<connectionStrings>
<add name="MembershipConnectionString"
     connectionString="connectionString"/>
</connectionStrings>
DPAPI 암호화는 사용 방법이 비교적 간단하며 가상 디렉터리나 실제 디렉터리 모두에 대해 네이티브 시스템 키 암호화를 사용하기 때문에 구현하기 가장 쉽습니다. 다른 방법을 사용하여 이 암호화를 프로그래밍 방식으로 구현할 수도 있지만 명령 프롬프트에서 다음 명령을 사용하는 방법이 가장 쉽고 간단합니다.
aspnet_regiis.exe -pe section -app MOSS_virtual_directory -prov provider

aspnet_regiis.exe -pef section MOSS_physical_directory -prov provider
이 경우에는 연결 문자열 노드를 암호화해야 하므로 다음과 같이 섹션 매개 변수를 지정하여 특정 섹션을 암호화할 수 있습니다.
aspnet_regiis.exe -pef "connectionStrings" "C:\Inetpub\wwwroot\WssVirtual " -prov "Provider"

aspnet_regiis.exe -pe "connectionStrings" -app "/MOSSAppinstance" -prov "Provider"
암호화를 구현하면 다음과 같이 중요한 정보가 포함된 노드가 올바른 형식의 XML 암호 값으로 바뀝니다.
<connectionStrings confiProtectionProvider=
"EncryptionProvider">
<EncryptedData>
<CipherData>
<CipherValue>XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
</CipherValue>
<CipherData>
</EncryptedData>
</connectionStrings>
이 모델은 고유한 암호화 공급자를 만들어 적절한 MOSS 구성 파일(web.config 또는 machine.config)의 암호화 텍스트를 관리할 수 있고, RSA나 DPAPI 암호화 외에도 다양한 암호화 방식을 사용할 수 있다는 점에서 전반적인 MOSS 아키텍처와 마찬가지로 플러그형입니다.
그러나 암호화를 사용하는 데는 단점도 있습니다. 로컬 시스템 키를 사용하여 암호화하기 때문에 이 구성 노드를 만든 MOSS 서버에서만 해당 구성 노드를 사용할 수 있고, 그렇지 않으면 암호화 프로세스가 실패합니다. 침입자가 서버에 대한 액세스 권한을 획득한 경우 시스템 키를 찾아 연결 문자열의 암호를 해독할 수 있습니다. 또한 이와 같은 암호 해독 프로세스로 인해 응용 프로그램 성능이 약간 저하될 수 있습니다.
4. 대체 액세스 매핑 및 영역 AAM(대체 액세스 매핑)은 SharePoint 환경에 진입점을 둘 이상 설정하는 경우에 특히 중요합니다. AAM을 사용하면 하나의 실제 사이트에 액세스하는 데 사용되는 다양한 URL을 지정할 수 있습니다(그림 2 참조). AAM은 서로 다른 인증 공급자와 웹 응용 프로그램 보안 정책을 통해 사용자를 MOSS 사이트의 동일한 실제 경로에 연결할 수 있습니다. AAM은 서로 다른 도메인, 역방향 프록시 및 기타 URL 리디렉션 메커니즘 사용을 보완합니다. MOSS에서 사용하는 URL은 기본적으로 자동 매핑되지만, 다른 진입 방식을 처리하기 위해 SharePoint 설계자가 명시적으로 만든 추가 URL을 사용하도록 이 기본 URL을 확장할 수 있습니다. AAM은 올바른 내부 URL 및 공용 URL 매핑이 제대로 작동하도록 하는 데 필요합니다.SQL Server 인증 공급자
지금부터 플러그형 ASP.NET 2.0 SQL Server 인증 공급자를 구현하는 과정을 단계별로 살펴보겠습니다. 이 공급자는 암호화된 web.config 연결 문자열을 사용하는 폼 기반 인증 방식을 사용하는데 이 인증 방식은 경계(엑스트라넷)에 MOSS 배포를 구현할 때 가장 일반적으로 사용됩니다.
플러그형 SQL Server 공급자를 사용하려면 먼저 사용자 자격 증명 저장소로 사용할 데이터베이스를 적절한 SQL Server 인스턴스에 만들어야 합니다. 그래야만 서비스 공급자가 해당 데이터베이스를 그룹 등록 데이터 저장소로 사용할 수 있습니다. 이렇게 하려면 명령 프롬프트 또는 실행 대화 상자에서 다음 명령을 실행하십시오.
%WINDIR%\Microsoft.NET\Framework\v2.0.50727\aspnet_regsql
이 명령을 실행하면 구성원 데이터를 저장할 데이터베이스를 구성할 수 있는 SQL Server 마법사가 나타납니다.
데이터베이스 저장소에 대해 그룹 등록 공급자를 아직 설정하지 않은 경우에는 응용 프로그램 서비스에 사용할 SQL Server를 구성하여 새 데이터베이스를 만듭니다. 기존 데이터베이스가 있는 경우에는 관련 정보를 추가합니다(조직에서 데이터베이스를 통합하려는 경우).
SQL 연결 문자열은 이 SQL 인스턴스에 연결하게 되므로 SQL Server 인증을 사용하도록 이 데이터베이스를 설정해야 합니다(그림 A 참조). 정보가 노출되는 것을 방지하기 위해 네이티브 ASP.NET 2.0 암호화 기능을 사용하여 개인 연결 정보를 암호화 텍스트로 변환하는 방법은 뒷부분의 설정 프로세스에서 설명할 예정이므로 이 단계에서는 일반 텍스트 사용자 이름과 암호를 사용하겠습니다.

로그인 폼 만들기
폼 기반 인증은 경계 네트워크에 위치하면서 모든 인터넷 사용자에게 공개적으로 노출되는 사이트에 주로 사용됩니다. 따라서 엑스트라넷 사이트 모음을 만들 때는 인터넷 현재 상태 MOSS 서식 파일을 사용하는 것이 가장 좋습니다. 이 서식 파일을 사용하면 로그인 폼을 직접 만들지 않아도 됩니다. 현재 사이트를 확장하는 경우나 사용자 지정 로그인 폼을 구현하려는 경우에는 Microsoft Visual Studio® 2005를 사용하여 약간의 코딩만으로 로그인 폼을 직접 만들 수 있습니다.
먼저 Visual Studio에서 사이트 모음의 실제 디렉터리를 웹 사이트로 엽니다. 일반적으로 디렉터리는 다음과 같은 위치에 저장되어 있습니다.
C:\Inetpub\wwwroot\wss\VirtualDirectories\<GUID>
default.aspx 페이지는 IIS 가상 서버 설정의 기본 문서이기 때문에 먼저 이 페이지를 추가해야 합니다. 솔루션 탐색기에서 "항목 추가" 명령을 사용하여 페이지를 추가한 다음 Visual Studio 도구 상자를 사용하여 새로 만든 웹 폼에 로그인 컨트롤을 추가합니다.
그림 A SQL Server 인증 설정
그림 A SQL Server 인증 설정 (더 작게 보려면 이미지를 클릭하십시오.)
그림 A SQL Server 인증 설정
그림 A SQL Server 인증 설정 (더 크게 보려면 이미지를 클릭하십시오.)

그림 B 응용 프로그램 관리 화면에서 인증 공급자 선택 (더 작게 보려면 이미지를 클릭하십시오.)
그림 B 응용 프로그램 관리 화면에서 인증 공급자 선택
그림 B 응용 프로그램 관리 화면에서 인증 공급자 선택 (더 크게 보려면 이미지를 클릭하십시오.)
같은 페이지의 그룹 등록 공급자 구역에 인증에 사용되는 공급자로 AspNetSqlMembershipProvider가 지정되고 역할 관리자 이름이 AspNetSqlRoleProvider인지 확인합니다. /_layouts/setanon.aspx로 이동한 후 사이트 전체를 선택하거나 필요에 가장 맞는 보안 설정을 선택하여 최종 사용자가 익명으로 액세스할 수 있는 위치를 지정합니다.
이제 web.config를 수정하여 중요한 변경 작업을 하겠습니다. <authentication> 요소가 <forms> 요소를 사용하도록 설정되었는지 확인합니다. 일반적으로 이 설정은 Windows 인증에서 폼 인증으로 전환하면 자동으로 구성되며 사용자 인증 티켓에 대한 데이터가 여기에 포함되므로 로그인 프로세스에서 매우 중요합니다. 사용자 인증 티켓은 ASP.NET 2.0 인증 방식을 통해 페이지 포스트백의 사용자 자격 증명을 확인합니다. web.config에는 사용자 저장소에 대한 SQL 연결 정보가 아직 없으므로 다음과 같이 그룹 등록 데이터베이스에 연결하는 데 사용할 연결 문자열을 추가해야 합니다.
<connectionStrings>
<remove name="LocalSqlServer" />
<add name="LocalSqlServer" connectionString="Server=SQLserver;
Database=aspnetdb;uid=username;
pwd=password;" providerName="System.Data.SqlClient" />
</connectionStrings>
중앙 관리 사이트 web.config 파일도 같은 방법으로 수정합니다. 이렇게 하면 인증 형식을 동일하게 유지할 수 있으며 PeoplePickerWildCard가 AspNetSqlMembershipProvider로 확인되도록 하여 사용자를 추가하기 위한 조회 컨트롤이 검색을 실행할 올바른 경로를 인식하도록 할 수 있습니다.
백 엔드 XML 파일을 변경할 것이므로 IIS를 다시 설정해야 합니다. SQL Server 데이터베이스에 연결된 후에는 웹 사이트를 쉽게 탐색할 수 있지만 사이트 콘텐츠를 관리하는 사이트 모음 소유자가 아직 없습니다. WAT의 "보안" 탭에서 사용자를 추가한 다음 "SharePoint 사이트 관리"로 이동하여 "사이트 모음 관리자" 아래에 적절한 사용자를 추가하여 이 사용자를 사이트 모음 관리자로 만듭니다. 앞에서 web.config의 peoplepicker 노드를 수정했으므로 올바른 이름이 표시될 것입니다.
마지막으로 실행 대화 상자를 열고 다음을 실행하여 DPAPI로 연결 문자열을 암호화합니다.
aspnet_regiis.exe -pef "connectionStrings"
"C:\Inetpub\wwwroot\WssVirtual\<GUID> "
£prov "DataProtectionConfigurationProvider"
작업을 성공적으로 마치면 다음의 확인 대화 상자가 나타납니다.

그림 2 URL 매핑 및 영역
그림 2 URL 매핑 및 영역 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 URL 매핑 및 영역
그림 2 URL 매핑 및 영역 (더 크게 보려면 이미지를 클릭하십시오.)
영역은 MOSS에 추가된 새로운 기능으로, AAM에서 제공하는 사이트 매핑을 보다 강력하게 제어할 수 있도록 도와줍니다. 영역을 사용하면 사용자가 콘텐츠에 연결하는 데 사용하는 AAM URL 매핑에 따라 서로 다른 인증 공급자를 동일한 실제 경로와 MOSS 콘텐츠에 매핑할 수 있습니다. AAM URL 매핑을 지정할 때는 가급적 영역을 인증 메커니즘에 바인딩하는 것이 좋습니다. 인증 공급자 페이지에 정의되어 있지 않은 영역에 AAM URL을 매핑하면 기본 영역의 보안 설정이 사용됩니다.
영역은 여러 URL 진입점의 포털에서 사용자가 인증되고 라우팅되는 방법에 상당한 영향을 주기 때문에 미리 계획하는 것이 좋습니다. 새 웹 응용 프로그램을 확장하는 경우 이 설정의 "부하 분산 URL" 구역 아래에서 사용할 영역을 지정할 수 있습니다(그림 3 참조). 기본 영역에서 지정하는 URL은 현재 영역을 제대로 확인할 수 없는 경우에 사용되므로 여기에는 가장 쉽게 액세스할 수 있는 URL(예를 들어 인터넷에 공개할 URL)을 입력하는 것이 좋습니다.
그림 3 MOSS 영역 구성
그림 3 MOSS 영역 구성 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 MOSS 영역 구성
그림 3 MOSS 영역 구성 (더 크게 보려면 이미지를 클릭하십시오.)
각 영역에서는 해당 영역의 사용자에 대한 권한 설정을 정의하는 글로벌 웹 응용 프로그램 보안 정책을 바인딩할 수 있습니다. 이렇게 하면 대규모의 사용 권한 수정 작업을 한 곳에서 관리할 수 있습니다. 일반적으로 웹 응용 프로그램은 다양한 사이트 모음에 여러 개의 사이트를 포함하는데 응용 프로그램의 규모가 커지고 복잡하게 될수록 이러한 사이트의 사용 권한을 관리하는 것이 어려워질 수 있습니다. MOSS 2007에서는 모든 권한, 모든 읽기 권한, 쓰기 권한 거부 또는 모든 권한 거부와 같은 정책 설정을 응용 프로그램 내의 특정 사용자나 그룹에 바인딩하는 글로벌 보안 정책을 사용할 수 있습니다. 이러한 정책은 MOSS에서 제공하고 SharePoint 중앙 관리 인터페이스에서 관리하는 세부적인 권한 설정보다 우선 적용되므로 구성을 신중하게 계획해야 합니다.
종합적으로 볼 때 외부와 접한 사이트의 AAM 설정에는 회사 사용자가 액세스하는 데 사용하는 URL 하나와 외부 사용자가 액세스하는 데 사용하는 URL 하나씩 총 두 개의 URL을 정의할 수 있습니다. 각 URL에는 contoso.com(내부 사용자용) 및 extranet.contoso.com(신뢰할 수 있는 외부 파트너용)과 같이 고유한 URL을 사용할 수 있습니다. 이 두 URL은 동일한 콘텐츠에 매핑되지만, 각 URL은 고유한 인증 공급자와 응용 프로그램 보안 정책이 있는 개별 영역을 통해 사이트에 액세스할 수 있습니다. 내부 URL의 인트라넷 영역을 구성하면 내부 사용자가 자신의 도메인 인증된 Windows ID를 사용하여 로그인할 수 있고, 외부 파트너는 엑스트라넷 영역을 통해 웹 Single Sign-On 인증을 사용함으로써 자신이 속한 조직의 사용자 자격 증명으로 로그인할 수 있습니다. 웹 응용 프로그램 보안 정책을 영역에 바인딩하는 기능을 잘 활용하면 개체별로 액세스 권한을 직접 설정하지 않고도 신뢰할 수 있는 모든 외부 사용자에게 모든 읽기 액세스 권한을 부여할 수 있습니다.
5. 안전한 공동 작업을 위한 대상 콘텐츠 SharePoint 사이트 모음을 잠그면 사용자는 자신에게 액세스 권한이 부여된 정보만 처리할 수 있습니다. 유연하게 활용할 수 있는 새로운 권한 메커니즘을 사용하면 MOO 환경에 저장된 다양한 유형의 비즈니스 정보를 더욱 강력하게 제어할 수 있습니다.
MOSS 2007에서는 사이트 모음, 개별 사이트, 문서 라이브러리, 하위 폴더, 목록 또는 개별 문서나 목록 항목과 같은 특정 개체에 ID를 바인딩할 수 있습니다. 이렇게 하면 항목에 대해 세부적인 액세스 권한과 명시적인 그룹 등록이 적용되어 해당 항목에 대한 액세스를 거부하고 사용자에게 액세스 권한이 부여되지 않은 항목은 표시되지 않도록 사용자 인터페이스를 조정할 수 있습니다. MOSS에서는 이 기능을 ILS(항목 수준 보안) 또는 SO(보안 개체)라고 합니다. MOSS 개체 사용 권한은 기본적으로 계층적 구조이기 때문에 목록 항목과 같은 개별 개체에서 목록 또는 문서 라이브러리 등 규모가 더 큰 항목에 이르기까지 권한을 확장할 수 있습니다. 또한 권한 상속을 구현하여 하위 수준에 있는 자식 개체에 상위 수준에 있는 부모 개체의 권한을 선택적으로 상속할 수 있습니다. 33개의 고유한 기본 사용 권한 중에서 선택하여 사용자 또는 SharePoint 그룹에 지정할 수 있으며 각 권한은 개체에 바인딩될 수 있습니다. 필요한 경우에는 새 권한 수준을 만들 수도 있습니다.
예를 들어 프로젝트 관리 사이트에서 중요한 개발 자료(예: Microsoft Word 문서로 작성하여 문서 라이브러리에 저장한 디자인 사양 및 코딩 기술)에는 개발자와 프로젝트 관리자만 액세스할 수 있도록 설정할 수 있습니다. 라이브러리에 대한 권한은 기본적으로 사이트 권한에서 상속되지만 개발자와 프로젝트 관리자에게만 액세스 권한을 부여하거나 각 Word 문서를 특정 프로젝트 관리자와 개발 팀에서만 보고 액세스할 수 있도록 권한을 수정할 수 있습니다. 이와는 반대로 중요하지 않은 자료는 항목, 폴더 또는 문서 라이브러리 수준에서 모두 공개할 수 있습니다.
이벤트 항목(예: 이벤트 목록의 프로젝트 기한)에 대해 사용 권한을 지정하여 특정 구성원만 특정 이벤트를 볼 수 있도록 구성할 수도 있습니다. 또한 ILS 기능을 반환되는 검색 결과에도 적용할 수 있으므로 검색을 실행한 사용자의 보안 컨텍스트에 맞는 개체만 반환되도록 할 수 있습니다. 결과적으로 이러한 모든 제어 기능은 개별 사용자 컨텍스트에 맞게 사용자 인터페이스를 조절합니다.
MOSS 2007에서는 사용 권한 관리 아키텍처가 대폭 향상되어 SharePoint 그룹과 도메인 그룹뿐만 아니라 개별 사용자 수준에서 사용 권한을 설정할 수 있습니다. 소유자(모든 권한), 방문자(참가자 권한), 구성원(읽기 권한) 등을 비롯한 몇몇 그룹은 기본적으로 롤아웃됩니다. 개별 사용자나 도메인 그룹을 이러한 기본 그룹에 할당하거나 사이트 모음 수준에서 만들고 관리하면서 다양한 고유 권한 수준을 지정할 수 있는 사용자 지정 그룹에 할당할 수도 있습니다.
역할을 기반으로 그룹을 만들 경우에는 "개발자" 및 "프로젝트 관리자" 그룹을 만든 후 세부적인 사용 권한을 할당할 수 있습니다. 예를 들어 개발자에게는 관련 코딩 문서를 업로드할 수 있는 권한을 부여하고, 프로젝트 관리자에게는 이러한 문서를 평가하고 승인할 수 있도록 읽기 및 승인 권한을 부여할 수 있습니다. 그룹 등록은 사이트 모음 전체에서 일관되게 유지되므로 기존에 만든 그룹을 여러 프로젝트 사이트에 다시 사용할 수 있습니다.
6. 플러그형 Single Sign-On 통합 일반적인 컴퓨팅 환경에서 사용자는 각기 고유한 인증 기준을 사용하는 다양한 타사 응용 프로그램에 액세스할 수 있는데, 이 경우 여러 가지 보안 문제가 발생할 수 있을 뿐만 아니라 관리해야 하는 암호가 너무 많아질 수 있습니다. MOSS SSO 서비스는 연결된 업무용 시스템에 매핑하는 데 필요한 사용자 자격 증명의 암호화된 백 엔드 캐시를 제공함으로써 이와 같은 문제를 줄이는 데 도움을 줍니다. 이 서비스를 사용하면 업무상 중요한 정보를 검색하여 BDC(비즈니스 데이터 카탈로그) 또는 SharePoint DVWP(DataView 웹 파트)와 같은 MOSS 메커니즘을 통해 표시할 수 있습니다.
MOSS SSO 공급자는 앞에서 설명한 다른 응용 프로그램 아키텍처 기능과 마찬가지로 플러그형이므로 MOSS에 기본 제공되는 SSO 공급자(SpsSsoProvider) 이외에 다른 고유한 SSO 공급자를 지정할 수 있습니다. 그러나 MOSS 환경에서는 업무용 시스템별로 SSO 공급자를 한 번에 하나만 등록할 수 있습니다.
7. IRM(정보 권한 관리) California Senate Bill No. 1386, SOX(Sarbanes-Oxley) Compliance 및 HIPAA(Health Insurance Portability and Accountability Act)와 같은 법규의 제약을 받는 중요한 데이터를 주로 다루는 회사에서는 비즈니스 정보를 오프라인 상태에서 사용할 경우에도 클라이언트 수준에서 정보를 보호하는 것이 매우 중요합니다. 서버 쪽 IRM(정보 권한 관리)은 MOSS 리포지토리에 통합되어 Windows Rights Management(WRM) 프레임워크를 기반으로 하는 공통의 솔루션을 제공합니다. IRM을 사용하면 문서가 저장된 위치나 문서를 열려는 사용자에 관계없이 문서 수준에서 액세스 제한을 적용하여 비즈니스 데이터를 보다 세밀하게 제어할 수 있습니다. 일반적인 IRM 구현 시나리오에서는 적절한 사용 권한이 있는 경우에만 보기 및 인쇄를 허용하는 정도로 데이터 액세스를 제어할 수 있지만 일정한 시간이 경과한 후 사용자 자격 증명 확인을 요구하거나, IRM을 사용하지 않는 자산은 업로드할 수 없도록 제한하거나, 제한 정책을 삭제하는 예약된 만료 태그를 사용하거나, 조직의 글로벌 IRM 사용 권한 정책에 바인딩하는 것처럼 기본적인 IRM 시나리오를 확장하여 더욱 복잡한 시나리오를 구현할 수 있습니다.
IRM 기능은 보호 기능을 통해 제공되는데 MOSS 2007에는 몇 가지 보호 기능이 기본적으로 설치됩니다. 보호 기능은 특정 파일 형식에 대한 암호화 프로세스를 관리하는 응용 프로그램으로, 일반적으로 MOSS 내에서 저장하는 모든 파일에 대해서는 지정된 기본 보호 기능이 있습니다. 예를 들어 Microsoft Office system 파일 및 OpenXML 파일 형식은 기본적으로 지원됩니다. 그러나 보호 기능의 응용 프로그램 아키텍처는 MOSS에서 제공하는 다른 공급자와 마찬가지로 플러그형으로 설계되었기 때문에 다른 파일 형식에 대해 사용자 지정 보호 기능을 구현할 수 있습니다.
IRM을 구현하려면 MOSS 환경의 모든 요구 사항을 충족하는지 여부를 가장 먼저 확인해야 합니다. 즉, 모든 MOSS 프런트 엔드 웹 서버에 WRM Services Client가 설치되어 있어야 하고 MOSS 프런트 엔드 웹 서버에 Microsoft Rights Management Services(RMS)가 연결되어 있어야 합니다. 그런 다음 MOSS에서 SharePoint 중앙 관리를 통해 사용할 수 있도록 RMS 서버를 지정해야 합니다. 이때 Active Direcotry의 기본값을 사용하거나 위치를 직접 지정할 수 있습니다.
IRM은 문서 라이브러리와 같은 SharePoint 데이터 저장소 구조를 직접 사용하여 사용 권한을 관리합니다. 사용자가 IRM이 설정된 문서 라이브러리로 이동하여 문서 다운로드를 시도하면 MOSS는 문서 라이브러리에 대해 구성된 사용 권한을 문서에 바인딩합니다(그림 4 참조). 이렇게 하면 MOSS와 문서 사용 권한이 일대일로 매핑되어 문서와 관련된 SharePoint 역할이 문서 자체의 IRM 사용 권한 수준으로 변환됩니다.
그림 4 문서 라이브러리의 IRM 사용 권한 전환
그림 4 문서 라이브러리의 IRM 사용 권한 전환 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 문서 라이브러리의 IRM 사용 권한 전환
그림 4 문서 라이브러리의 IRM 사용 권한 전환 (더 크게 보려면 이미지를 클릭하십시오.)
오프라인 상태에서 문서를 보호하기 위해 로컬 위치에서 문서가 암호화되고, 해당 문서를 문서 라이브러리에 다시 업로드할 때까지 이 상태가 유지됩니다. 문서를 업로드하면 전체 텍스트 검색을 위해 SharePoint Gatherer가 해당 문서의 콘텐츠를 인덱싱할 수 있도록 문서가 암호화되지 않은 형태로 유지됩니다. 그러나 암호화되지 않은 형태에서는 어떤 사용자 계정도 문서 콘텐츠에 액세스할 수 없습니다.
MOSS 2007은 추가적인 관리 부담 없이 조직의 보안을 효과적으로 구현하는 데 도움을 주는 다양한 기능을 제공합니다. 뿐만 아니라 이러한 기능은 사용자가 필요한 정보에만 액세스할 수 있도록 세부적으로 사용자 지정할 수 있으므로 매우 다양하게 활용할 수 있습니다. 간단한 예제를 보려면 "SQL Server 인증 공급자" 추가 기사를 참조하십시오.

Adam Robert Buenz는 ARB Security Solutions LLC(sharepointsecurity.com)에서 SharePoint 설계자 및 개발자로 일하고 있으며 보안 중심의 공동 작업 환경을 담당하고 있습니다. 문의 사항이 있으시면 adam@sharepointsecurity.com으로 연락하십시오.


 SharePoint: SharePoint 엔터프라이즈 검색을 사용한 정보 검색
SharePoint Matt Hester

SharePoint 엔터프라이즈 검색을 사용한 정보 검색
한 눈에 보기:
  • 엔터프라이즈 검색 솔루션의 아키텍처
  • 비즈니스 데이터 인덱싱 및 쿼리
  • LOB 데이터 및 사용자 지식

시스템 관리자들은 종종 서버 가동 시간과 가용성, 소프트웨어 업데이트, 보안 등의 일을 고민하느라 많은 시간을 소모합니다. 하지만 인프라가 완벽하게 실행되어 네트워크를 통해 모든 응용 프로그램과
모든 파일을 사용할 수 있는 경우라도 여전히 사용자의 생산성은 떨어질 수 있습니다. 사용자는 필요한 모든 데이터를 사용할 수 있지만 문제는 그 데이터를 찾는 데 걸리는 시간입니다.
따라서 사용자의 정보 처리 오버로드를 줄이려는 노력이 계속되고 있습니다. 데스크톱 검색 도구를 사용하면 시스템에 저장된 다양한 데이터에 숨어 있는 정보를 쉽게 찾을 수 있습니다. 이와 관련된 자세한 내용은 필자의 2006년 8월 기사인 "Find Anything with Windows Desktop Search"(영문)를 참조하십시오. 하지만 직원들의 머리 속에 저장되어 있는 귀중한 정보는 차치하더라도, 포털에서 제공되는 데이터, 공유 위치에 저장되어 있는 데이터, 업무용 응용 프로그램에 저장되어 있는 데이터는 어떻게 찾을 수 있을까요? 이러한 정보는 사용자에게 필수적입니다. 이러한 데이터가 있어야 업무를 처리하고 시의 적절하면서도 정확한 비즈니스 의사 결정을 내릴 수 있습니다. 그러나 사용자가 네트워크에 분산되어 있는 데이터를 찾고 수집하는 데 걸리는 시간을 생각해 보십시오. 이제 이러한 시간이 기업의 수익에 미치는 영향을 고려할 때입니다.
사용자가 엔터프라이즈 도처에 저장되어 있는 정보를 추적하는 데 걸리는 시간을 줄일 필요가 있습니다. 이렇게 하려면 어떻게 해야 할까요? 답은 무척 간단합니다. 바로 엔터프라이즈 검색 기능이 있는 검색 엔진을 사용하는 것입니다.
엔터프라이즈 검색을 사용하면 조직에 분산 저장되어 있는 대부분의 정보를 찾을 수 있습니다. 데스크톱에 저장되어 있거나, 인트라넷 사이트에 숨겨져 있거나, 업무용(LOB) 응용 프로그램에 저장되어 있거나, 심지어 개인의 머리 속에 있는 데이터를 찾을 때 엔터프라이즈 검색 도구가 도움이 됩니다. 그렇다고 사용자 머리 속에 칩을 장착해야 하는 것은 아니니 걱정하지 마십시오.
엔터프라이즈 검색 솔루션은 데스크톱 검색과 고속 인트라넷 검색 기능을 결합합니다. 궁극적으로 엔터프라이즈 검색 도구는 단일 쿼리로 여러 데이터 원본에 액세스할 수 있는 통합 검색을 수행할 수 있어야 합니다. 사용자 입장에서 볼 때는 쿼리를 입력하는 단일 인터페이스에 불과하지만 그 이면에서는 쿼리를 여러 다양한 검색 엔진으로 전송한 뒤 결과를 집계하여 하나의 보기에 표시하는 복잡한 작업이 수행됩니다.
본 기사에서는 차세대 Microsoft SharePoint 솔루션인 Microsoft® Office SharePoint® Server 2007(MOSS 2007)이 조직의 정보 저장소를 빠짐없이 검색하도록 지원하는 강력한 검색 엔진을 어떻게 제공하는지 살펴봅니다. MOSS 2007은 이전 버전과 비교하여 대폭 향상되었을 뿐 아니라 완전히 새로 개발된 구성 요소와 몇 가지 새로운 기능도 제공합니다. 여기서는 인덱싱, 전파, 관련성, 콘텐츠 원본과 같은 몇 가지 핵심 구성 요소에 대해 설명하고 이러한 구성 요소를 통해 사용자에게 뛰어난 엔터프라이즈 검색 기능을 어떻게 제공할 것인지 알아봅니다.

SharePoint를 사용한 엔터프라이즈 검색
엔터프라이즈 검색은 각기 기능이 다른 Microsoft Office SharePoint Server 2007 for Search Standard Edition, Microsoft Office SharePoint Server 2007 for Search Enterprise Edition, Microsoft Office SharePoint Server 2007 Standard 및 Microsoft Office SharePoint Server 2007 Enterprise의 4가지 버전으로 제공됩니다.
두 Search Edition 버전과 정식 SharePoint Server 버전 사이의 주요한 차이점은 두 Search Edition 버전에는 사용자 검색 기능(MOSS 2007용 지식 네트워크와의 통합도 포함), 비즈니스 데이터 카탈로그 또는 사용자 지정 가능한 탭이 있는 향상된 검색 센터가 포함되지 않는다는 것입니다. 그림 1 주요 차이점 설명
Figure 1 4가지 검색 버전의 주요 차이점 (Close Figure 1)

 | Microsoft Office SharePoint Server 2007 for Search Standard Edition | Microsoft Office SharePoint Server 2007 for Search Enterprise Edition | Microsoft Office SharePoint Server 2007 Standard Edition | Microsoft Office SharePoint Server 2007 Enterprise Edition
인덱스 | 기본적으로 40개 파일 형식(확장 가능) | 기본적으로 40개 파일 형식(확장 가능) | 기본적으로 40개 파일 형식(확장 가능) | 기본적으로 40개 파일 형식(확장 가능)
기본적으로 파일 공유, 웹 사이트, SharePoint 사이트, Exchange 공용 폴더, Notes 데이터베이스 파일에서 검색 지원 |  |  |  |
타사 문서 저장소 검색 지원 |  |  |  |
사용자 및 전문 기술 검색 지원 |  |  |  |
구조적 데이터 원본 검색 지원 |  |  |  |
보안 콘텐츠 액세스 제어 제공 |  |  |  |
향상된 검색 센터 UI 제공 |  |  |  |
문서 제한 | 400,000 | 제한 없음 | 제한 없음 | 제한 없음
UI에서는 "다음 단어를 찾으려고 했습니까?" 기능을 비롯한 여러 가지 새로운 기능을 제공합니다. 인터넷 검색 엔진의 핵심인 이 기능은 사용자가 일반적인 검색 용어를 잘못 입력했을 경우에 대비하여 다시 한 번 확인합니다(그림 2 참조). 또한 인터페이스에서는 검색 일치 항목이 강조 표시되며 "최상의 선택"이 완벽하게 지원됩니다. 하지만 이러한 인터페이스는 새로운 검색 기능의 극히 일부에 불과합니다.
그림 2 SharePoint 검색의 새로운 '다음 단어를 찾으려고 했습니까?' 기능
그림 2 SharePoint 검색의 새로운 '다음 단어를 찾으려고 했습니까?' 기능 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 SharePoint 검색의 새로운 '다음 단어를 찾으려고 했습니까?' 기능
그림 2 SharePoint 검색의 새로운 '다음 단어를 찾으려고 했습니까?' 기능 (더 크게 보려면 이미지를 클릭하십시오.)

사용자 지식 찾기
가장 눈에 띄는 새로운 기능 중 하나는 특정 지식과 전문 기술이 있는 사람을 검색하는 기능입니다. 이 기능을 사용하면 전 조직의 직원이 보유한 지식을 찾아 이용할 수 있는데, 이는 정보를 탐색할 때 가장 중요한 단계입니다.
이러한 검색이 가능하도록, Active Directory® 분산 목록과 SharePoint 사용자 그룹을 비롯한 모든 LDAP(Lightweight Directory Access Protocol) 디렉터리에서 인덱싱과 검색을 수행할 수 있습니다. 실제로는 MOSS가 LDAP 디렉터리를 직접 검색할 수 없기 때문에 사용자 검색이 가능하려면 MOSS로 LDAP 정보를 가져와야 합니다. 또한 전체 엔터프라이즈 인프라 내에서 검색을 수행할 수도 있습니다.
검색 결과를 개인의 "사회적 거리"에 따라 그룹화할 수 있는데, 사회적 거리란 사용자의 위치(판매 상담원이 CFO에게 전화하는 일은 거의 없음)와 공통 관심사로부터의 거리를 나타냅니다. 그림 3은 사용자 검색 결과를 보여 줍니다.
그림 3 관련 지식이 있는 동료 찾기
그림 3 관련 지식이 있는 동료 찾기 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 관련 지식이 있는 동료 찾기
그림 3 관련 지식이 있는 동료 찾기 (더 크게 보려면 이미지를 클릭하십시오.)

비즈니스 데이터 검색
SharePoint는 다양한 종류의 비즈니스 데이터를 인덱싱할 수 있습니다. 여기에는 HR 응용 프로그램, CRM, 비용 보고 등과 같은 업무용(LOB) 응용 프로그램이 포함됩니다. 일반적으로 이러한 종류의 데이터는 LOB 응용 프로그램의 정상적인 인터페이스 밖에서는 액세스하기 어렵기 때문에 대부분의 직원들은 이 데이터를 찾거나 사용하기 힘듭니다.
하지만 이제 MOSS 검색 덕분에 ADO.NET 또는 웹 서비스를 통해 액세스 가능한 모든 LOB 응용 프로그램의 데이터(예: 관계형 데이터베이스나 Lotus Notes 데이터베이스)를 검색할 수 있게 되었습니다. 이 기능의 특별한 점은 사용자 지정 코드를 작성할 필요가 없다는 것입니다. 비즈니스 데이터 카탈로그 기능을 사용하면 문서나 웹 사이트에 액세스하는 것처럼 쉽게 비즈니스 데이터를 사용할 수 있습니다. 이러한 비즈니스 데이터 카탈로그 기능은 검색 센터가 제공하는 속성 관리 및 사용자 지정 범위에 쉽게 통합할 수 있습니다.

관련성 반환
정확한 결과를 얻을 수 없다면 새로운 기능이 아무리 많아도 소용없을 것입니다. 다행히 MOSS에서는 관련성에 있어 몇 가지 점이 획기적으로 향상되었습니다. 이러한 개선점에 대해 설명하기 전에 먼저 엔터프라이즈의 관련성과 인터넷의 관련성이 어떻게 다른지 짚고 넘어가는 것이 좋을 것 같습니다.
이쯤 되면 인트라넷 검색에서 인터넷 검색과 동일한 도구 및 동일한 정확도를 사용할 수 없는 이유가 궁금할 것입니다. 간단히 말하자면 인트라넷과 인터넷은 필요성과 요구 사항이 엄청나게 다른 환경입니다. 이러한 차이점은 보안, 구조 및 계층의 세 가지 주요 범주로 그룹화할 수 있습니다.
보안의 경우 엔터프라이즈에 비해 인터넷은 상당히 단순합니다. 인터넷의 데이터는 대개 익명으로 액세스할 수 있으며 인덱싱과 검색에 인증이나 보안 처리(자르기)가 필요하지 않습니다. 하지만 엔터프라이즈 환경에서는 검색자의 권한에 맞게 결과를 필터링하는 등, 엄격한 보안 모델을 따라야 합니다.
구조의 영향은 밀도와 관계가 있습니다. 인터넷은 다른 사이트를 링크하여 사이트 내용을 보충하기 때문에 매우 풍부하고 다층적입니다. 하지만 엔터프라이즈에서는 링크가 대개 탐색 용도로 사용되고 구조가 훨씬 단순합니다.
사이트 계층 요소는 링크 구조에 느슨하게 연결되어 있습니다. 인터넷의 경우 일반적으로 사이트 간의 계층 구조가 없으며 최상위 사이트는 매우 적습니다. 하지만 엔터프라이즈 인트라넷은 주로 계획적이며 근본적으로 계층적입니다. 엔터프라이즈에 기본 루트 수준이 여러 개 존재하는 경우에도 조직에서 사용하는 기본 포털은 대개 하나입니다.
이러한 근본적인 차이점 때문에 엔터프라이즈 검색 솔루션이 데이터를 인덱싱하고 결과를 반환하는 방식이 달라집니다. MOSS 2007의 목표는 엔터프라이즈의 다양한 요구 사항을 충족시키는 것입니다. 이 솔루션의 특징은 Microsoft Research 팀 및 MSN® 팀의 축적된 성과가 담겨 있는 기존 기술을 사용하여 개발된 새로운 순위 엔진입니다. 또한 검색하는 문서와 업무용 데이터에 대한 내부 정보와 외부 정보를 모두 수집하는 일련의 관련성 알고리즘을 통해 관련성도 높였습니다. 엔터프라이즈 데이터를 인덱싱할 때는 200개 이상의 문서 유형을 검색한 뒤 언어를 탐지하고 메타데이터를 추출하고 텍스트 분석을 수행하는 다양한 알고리즘을 적용합니다. 이러한 새로운 알고리즘은 엔터프라이즈 데이터와 LOB 응용 프로그램의 요구에 따라 특별히 조정되기 때문에 결과의 정확도가 획기적으로 향상됩니다.
관련성 계산에는 몇 가지 메타데이터 태그가 포함됩니다. 다음과 같은 몇몇 사항을 고려해야 합니다.
  • 클릭 횟수 - 신뢰할 수 있는 사이트로부터의 검색 거리입니다. 거리가 짧을수록 관련성이 큰 경향이 있습니다.
  • 앵커 텍스트 - 하이퍼링크는 대상에 대한 주석 역할을 합니다. 또한 대상을 설명하는 경우가 많습니다.
  • URL 깊이 - 계층 구조에서 상위에 있는 URL일수록 관련성이 큰 경향이 있습니다.
  • URL 일치 - URL에 있는 텍스트와 직접 일치합니다.
  • 메타데이터 추출 - 제목 및 작성자 정보가 없는 경우 문서 텍스트에서 자동으로 추출합니다.
  • 자동 언어 감지 – 해당 언어의 결과에 대한 기본 설정을 만들 수 있습니다.
  • 파일 형식 편향성 - 특정 파일 형식이 관련성이 큰 경향이 있습니다. 예를 들면 대개 XLS 파일보다 PPT 파일의 관련성이 큽니다.
  • 텍스트 분석 - 용어 일치, 용어 빈도, 단어 변형 등의 요소를 기준으로 한 일반적인 텍스트 순위입니다.

인덱싱 작동 방식
MOSS 2007에서는 인덱싱 서비스가 작동하는 방식과 콘텐츠를 관리하는 방식에서 상당한 발전이 이루어졌습니다. 먼저 콘텐츠 원본이 SharePoint 서버, 웹 사이트, 파일 공유, Exchange 공용 폴더, Lotus Notes 데이터베이스 또는 LOB 응용 프로그램 중 어느 것인지 지정할 수 있습니다. 전반적인 인덱싱 관리 환경이 효율적으로 개선되어 여러 콘텐츠 원본에서 인덱싱할 대상, 방법 및 시기를 자유롭게 선택할 수 있습니다. 이 경우 포함하거나 제외할 경로를 지정하는 크롤링 규칙을 통해 처리가 이루어집니다. 심지어 크롤러가 URL의 링크를 따라 이동하는 방식도 구성할 수 있습니다. 기본적으로 제공되는 로그를 통해 크롤링한 사이트의 수 및 인덱싱 방법을 전체적으로 볼 수 있습니다.
인덱스는 Windows® 데스크톱 검색에 사용되는 인덱스 기술과 유사한데, 인덱스를 구성하는 두 가지 구성 요소는 콘텐츠 인덱스와 속성 저장소입니다. 인덱스는 데이터를 처리하는 매우 효율적인 방법입니다. 콘텐츠 인덱스에는 파일에 들어 있는 실제 텍스트뿐만 아니라 엔터프라이즈 인덱스에 있는 단어와 관련된 반전된 인덱스도 포함됩니다. 속성 저장소 데이터베이스는 결과 처리에서 중요한 역할을 합니다. 속성 저장소 데이터베이스에는 저장소의 모든 문서에 대한 추가 메타데이터 속성(작성자, 만든 날짜, 문서 유형 등)이 들어 있습니다. 구조적으로 속성 저장소는 속성 테이블과 해당 값으로 구성되어 있습니다. 테이블의 각 행은 전체 텍스트 인덱스의 개별 문서에 해당합니다. 또한 속성 저장소는 문서를 인덱싱할 때 수집된 문서 수준의 보안을 유지하고 강화하는 역할도 합니다.
인덱싱 및 저장소 프로세스는 콘텐츠 원본의 크롤링을 담당하는 인덱스 엔진과 함께 시작됩니다. 엔진은 콘텐츠 원본을 읽는 적절한 프로토콜 처리기가 있는지 확인한 후 크롤링을 시작합니다. 콘텐츠 원본에 대한 올바른 프로토콜 처리기가 로드되면 프로토콜 처리기와 필요한 IFilter가 콘텐츠 원본에서 항목을 추출하고 필터링합니다. IFilter는 인덱스 엔진이 새 파일 형식의 콘텐츠를 열고 읽고 인덱싱할 수 있게 하는 추가 기능입니다. 인덱스 엔진은 이 추가 기능이 없으면 완벽한 인덱싱 기능을 수행할 수 없습니다. IFilters는 각 문서의 텍스트와 메타데이터를 추출하여 이 스트림을 인덱스 엔진으로 다시 전달합니다.
그러면 문서 속성이 속성 저장소에 저장되고 문서의 실제 텍스트는 콘텐츠 인덱스에 추가됩니다. 이 작업이 수행되기 바로 전에 인덱스 엔진은 "노이즈" 단어를 제거합니다. 또한 엔진은 보다 효율적인 쿼리 실행을 위해 정보를 처리할 때 단어 분리기와 형태소 분석기를 사용하여 데이터를 정리합니다. 단어 분리기는 텍스트를 단어와 구로 분리하고, 형태소 분석기는 주어진 단어의 활용형을 생성합니다.
인덱스 엔진은 연속적인 전파를 사용하여 인덱스를 바로 구축할 수 있습니다. 연속적인 전파를 사용하면 크롤링 프로세스가 콘텐츠 원본을 통해 이동하는 동안에도 인덱스가 계속 구축됩니다. 거의 눈 깜짝할 사이에 결과를 제공하는 이 기능은 대규모 콘텐츠 크롤링에 수 일이 걸리고 크롤링이 완료된 후에야 인덱스가 전파되던 SharePoint Portal Sever 2003과 비교할 때 그야말로 획기적인 것입니다.

쿼리 작동 방식
사용자가 쿼리를 입력하거나 사용자 지정 응용 프로그램에서 인덱스를 호출하면 쿼리 엔진은 요청을 처리합니다. 쿼리 엔진은 먼저 쿼리를 해당 언어의 단어 분리기로 전달합니다. 언어를 식별할 수 없는 경우 중립 단어 분리기가 호출됩니다. 쿼리를 분해한 후 엔진은 정보를 형태소 분석기(형태소 분석을 사용하는 경우)로 전달하여 추가적인 처리를 수행합니다. 이처럼 2단계로 나누어 처리함으로써 쿼리 반환 결과의 관련성과 효율성을 높일 수 있습니다.
쿼리에 속성 정보가 지정된 경우 먼저 콘텐츠 인덱스를 확인하여 속성 저장소의 문서와 일치하는 쌍을 찾은 다음 쿼리의 속성을 다시 확인하여 일치를 확인합니다. 쿼리 엔진은 추가 필터링 단계를 수행하여 사용자에게 액세스 권한이 없는 결과는 제거합니다. 일치하는 결과가 관련성순으로 정렬되어 목록으로 반환됩니다. 인덱싱 및 쿼리의 모든 구성 요소가 어떻게 상호 작동하는지를 개괄적으로 보여 주는 그림이 바로 그림 4입니다.
그림 4 MOSS 2007 엔터프라이즈 검색 환경의 아키텍처
그림 4 MOSS 2007 엔터프라이즈 검색 환경의 아키텍처 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 MOSS 2007 엔터프라이즈 검색 환경의 아키텍처
그림 4 MOSS 2007 엔터프라이즈 검색 환경의 아키텍처 (더 크게 보려면 이미지를 클릭하십시오.)

향상된 관리 기능
관리자가 검색 환경을 더욱 쉽게 관리할 수 있습니다. 최종 사용자와 관리자를 위한 공용 도구 집합이 향상되었으므로 이를 사용하면 플랫폼의 다양한 연결 지점으로 인해 발생하는 복잡함을 줄일 수 있습니다. 아울러 검색 엔진은 MOSS 2007의 새 관리 모델을 최대한 활용합니다. 그림 5에서는 검색 설정 수정에 사용되는 기본 페이지를 보여 줍니다.
그림 5 검색 설정 구성
그림 5 검색 설정 구성 (더 작게 보려면 이미지를 클릭하십시오.)
그림 5 검색 설정 구성
그림 5 검색 설정 구성 (더 크게 보려면 이미지를 클릭하십시오.)
다양한 검색 기능을 제어할 수 있는 범위 기능도 향상되었습니다. 범위를 사용하면 콘텐츠 원본 내에서 쉽게 검색할 수 있으므로 인덱스를 더 작은 청크로 관리할 수 있습니다. SharePoint Portal Server 2003에서는 범위가 콘텐츠 원본에 연결되므로 융통성이 떨어지고 관리하기가 다소 힘들었습니다. 하지만 MOSS 2007에서는 범위가 콘텐츠 원본과 분리되어 융통성이 크게 좋아졌습니다. 이제 URL, 형식, 작성자 등과 같은 임의의 콘텐츠 속성을 기준으로 범위를 정의할 수 있으며 여러 규칙을 조합하여 범위를 정의할 수도 있습니다(예: 특정 작성자의 모든 기술 문서).
관리자가 검색 엔진의 성능을 높이려는 경우 수행해야 하는 가장 중요한 작업 중 하나가 인덱스의 현재 사용 현황을 파악하는 것입니다. 관리 도구 모음에 새로 추가된 가장 유용한 기능 중 하나는 쿼리 보고 기능입니다. 기본적으로 제공되는 쿼리 보고 기능을 사용하면 쿼리 용량 추세, 자주 사용되는 쿼리, 클릭 방문 비율, 결과가 없는 쿼리 등 쿼리에 대한 정보를 빠르게 찾을 수 있습니다. 쿼리 보고 기능은 사이트 수준 및 핵심 서비스 공급자 수준의 세부 정보를 제공할 수 있습니다. 그림 6은 보고서의 예입니다. 이 정보를 Microsoft Excel®로 내보내서 데이터를 추가적으로 분석하거나 피벗할 수 있습니다.
그림 6 MOSS 2007의 쿼리 보고서
그림 6 MOSS 2007의 쿼리 보고서 (더 작게 보려면 이미지를 클릭하십시오.)
그림 6 MOSS 2007의 쿼리 보고서
그림 6 MOSS 2007의 쿼리 보고서 (더 크게 보려면 이미지를 클릭하십시오.)

보안 및 권한
앞서 언급한 것처럼 쿼리 엔진은 사용자에게 표시되는 목록에 사용자가 액세스할 수 있는 문서만 포함되도록 결과를 필터링합니다. SharePoint Portal Server 2003에서는 사용자에게 방문 권한이 없는 링크도 표시되었습니다. 보안 조치(자르기)와 관련하여 주의해야 할 사항 한 가지는 MOSS 2007이 웹 크롤링에 대해 보안 자르기를 수행하지 않는다는 것입니다. HTTP 프로토콜에는 액세스 제어 정보를 다시 읽어 올 방법이 없기 때문에 웹 사이트를 자를 수 없습니다. 또한 MOSS 2007은 비즈니스 데이터 카탈로그나 사용자 검색에 대해서도 보안 자르기를 수행하지 않습니다.
MOSS 2007은 기존 ACL(액세스 제어 목록)을 참조하여 인덱스의 문서 보안을 유지합니다. 이 점이 다른 여러 검색 도구와 크게 다른 점입니다. 구성 파일을 사용하여 수동으로 파일에 대한 권한을 설정하는 일부 검색 엔진과 달리 MOSS 2007을 사용하면 현재 권한과 동기화할 수 있습니다.
인덱스는 단일 문서에 대한 ACL 변경 내용을 신속하게 반영할 수 있습니다. 예를 들어 현재 인덱스에 저장되어 있는 Excel 스프레드시트의 ACL이 제한적인 상태로 변경된 경우 관리자는 해당 문서만 다시 인덱싱하고 크롤링할 수 있으며 바로 보안 처리(자르기)가 이루어집니다. 필요한 경우 인덱스에서 문서를 완전히 제거할 수도 있습니다.
또한 개별 문서에 고유한 권한을 지정하거나 문서 라이브러리 또는 상위 디렉터리의 권한 설정을 상속하도록 설정할 수 있습니다. 이렇게 하면 문서 보기, 편집 및 저장을 수행할 수 있는 그룹이나 개인을 선택하는 작업을 훨씬 간단하게 수행할 수 있습니다.
인증과 Sign-On 관리도 향상되었습니다. 이제 보안 자격 증명 캐시를 확장할 수 있으므로 MOSS가 타사 원본이나 사용자 지정 코드의 추가 기능에서 제공하는 Single Sign-On 자격 증명 캐싱 시스템을 승인할 수 있습니다. 또한 코어 인증에서 타사 시스템을 승인할 수 있게 되었습니다. 이 두 가지 향상된 기능은 새 ASP.NET 공급자 모델을 기반으로 이루어졌으므로 다른 디렉터리 서비스를 사용할 수도 있습니다.

사용자 지정
MOSS 2007에는 사용자 인터페이스를 수정하는 다양한 옵션이 있습니다. 웹 사이트를 수정하는 데 사용했던 기존 도구를 사용하여 UI를 사용자 지정할 수 있을 뿐 아니라, 마스터 페이지(브랜드 사이트를 구축하는 쉬운 방법을 제공함)를 쉽게 구축할 수 있는 Office SharePoint Designer와 같은 새로운 도구가 추가되었습니다. 그림 7은 편집 중인 검색 결과 페이지를 보여 줍니다.
그림 7 검색 결과 페이지 모양 사용자 지정
그림 7 검색 결과 페이지 모양 사용자 지정 (더 작게 보려면 이미지를 클릭하십시오.)
그림 7 검색 결과 페이지 모양 사용자 지정
그림 7 검색 결과 페이지 모양 사용자 지정 (더 크게 보려면 이미지를 클릭하십시오.)
기본적으로 제공되는 MOSS 2007의 검색 센터 인터페이스에는 모든 사이트와 사용자의 두 탭이 있습니다. 사용자가 자주 검색하는 다양한 유형의 정보를 반영하여 다른 탭을 추가할 수도 있습니다. 예를 들면 엔터프라이즈 응용 프로그램, 데이터베이스 또는 디렉터리 서비스에 직접 연결되는 항목도 제공할 수 있습니다. 나아가 탭을 범위와 연관시킬 수도 있습니다. 이렇게 하면 특정 콘텐츠의 컨텍스트에서 검색할 수 있는 검색 탭을 쉽게 만들 수 있습니다. 검색 전용 버전은 검색 탭에 대한 사용자 지정을 지원하지 않습니다.

결론
지금까지 살펴본 것처럼 MOSS 2007은 엔터프라이즈 검색 측면에서 주목할 만한 향상된 기능을 제공하므로 이제 사용자는 보다 효율적이며 생산적으로 작업할 수 있습니다. 자세한 내용은 Microsoft Office SharePoint Technologies를 참조하십시오.

Matt Hester는 Microsoft Across America 팀의 TechNet 프레젠테이션 담당자입니다. Matt의 프레젠테이션을 실시간으로 보려면 www.technetevents.com/mhester(영문)를 방문하십시오. blogs.technet.com/matthewms(영문)에 있는 Matt의 블로그도 살펴보십시오.


 SharePoint: SharePoint를 위한 강력한 명령줄 관리
SharePoint Todd Klindt

SharePoint를 위한 강력한 명령줄 관리
한 눈에 보기:
  • STSADM으로 SharePoint 구성
  • 일상적인 관리 업무 스크립팅
  • 고급 STSADM 작업

Windows나 Microsoft Office를 사용하는 방식을 생각해 보십시오. 어떤 사람들은 마우스를 사용해서 포인터로 메뉴와 도구 모음을 탐색하면서 일반적인 작업을 수행하는 것을 매우 좋아하지만 키보드를 사용하여
빠르게 단축키를 입력하거나 바로 가기를 실행하는 것을 좋아하는 사람들도 있습니다. 작업을 수행하는 방법은 한 가지가 아닌 경우가 대부분입니다.
사실 그래픽 인터페이스가 사용하기 쉽기는 하지만 같은 과정을 반복해야 하는 성가신 부분도 있습니다. 실제로 어떤 작업은 키보드를 사용하는 것이 더 쉽습니다. SharePoint® 관리 작업을 수행할 때도 그래픽 인터페이스 때문에 작업이 지체되는 일을 많이 경험하실 것입니다. 그렇지만 SharePoint에는 작업을 수행하는 보다 강력한 방법이 있습니다.
Windows® SharePoint Services(WSS)와 Microsoft® Office SharePoint Server 2007(MOSS)을 관리하는 기본적인 인터페이스는 GUI 기반의 SharePoint 중앙 관리입니다. 하지만 SharePoint에는 더욱 강력한 관리를 위한 명령줄 도구인 STSADM.exe도 포함되어 있습니다. STSADM.exe는 SharePoint 중앙 관리의 모든 기능을 제공할 뿐만 아니라 많은 관리자가 바라는 융통성 있는 명령줄 기능도 제공합니다. 이 문서에서는 STSADM을 사용하여 WSS 및 MOSS를 관리하는 방법을 집중적으로 소개합니다. 또한 환경 구성 방법에 대한 몇 가지 팁을 제공하고 몇 가지 일반적인 STSADM 명령에 대해 설명합니다. 덧붙여 적절한 때에 사용한다면 회사에서 영웅이 될 수 있을 만한 고급 STSADM 명령 몇 가지도 소개하려고 합니다.

시작
지금까지 STSADM을 본 적이 없다면 그것은 STSADM이 찾기 어려운 곳에 숨어 있기 때문입니다. Windows SharePoint Services 2.0에서 STSADM은 기본적으로 c:\program files\common files\microsoft shared\web server extensions\60\bin에 있습니다. 버전 3.0에서의 기본 위치는 c:\program files\common files\microsoft shared\web server extensions\12\bin입니다.
필자는 이 도구에 쉽게 액세스하기 위해 두 가지 방법을 사용합니다. 첫 번째 방법은 이 디렉터리를 PATH 환경 변수에 추가하는 것입니다. 이렇게 하면 파일 시스템 어디에서라도 STSADM을 사용할 수 있습니다. 하지만 항상 이 방법을 사용하기는 어렵습니다. 두 번째 방법은 CMD.EXE에 대한 바로 가기를 만들고 초기 디렉터리로 STSADM의 위치를 설정하는 것입니다. STSADM을 직접 가리키는 바로 가기를 만들지 않는 이유는 무엇일까요? STSADM은 대화식 도구가 아니기 때문이 직접 바로 가기를 만들면 작동하지 않습니다. 따라서 STSADM을 직접 가리키는 바로 가기를 만들면 STSADM의 간단한 사용법이 표시되었다가 즉시 사라집니다.
STSADM을 실행하려면 웹 서버에서 로컬 Administrators 그룹의 구성원이어야 하며 응용 프로그램을 로컬에서 실행해야 합니다. 이는 STSADM을 사용하여 SharePoint 서버를 원격으로 관리할 수 없다는 것을 의미합니다.
STSADM으로 수행할 수 있는 작업을 보려면 명령 프롬프트에서 stsadm.exe -help를 입력하십시오. SharePoint 업데이트와 핫픽스를 적용한 후에는 새로운 명령이 추가될 수 있으므로 항상 이 목록을 확인해야 합니다. go.microsoft.com/fwlink/?LinkId=77516에서 stsadm.exe의 요약 안내서(영문)를 참조할 수도 있습니다.

STSADM 기본
먼저 SharePoint 설치 환경을 조정하는 데 사용할 수 있는 몇 가지 명령을 살펴보겠습니다. STSADM을 사용하면 SharePoint에 기능을 추가하고 구성 설정을 수정할 수 있습니다.
STSADM을 사용할 때는 -o 매개 변수 다음에 수행할 명령을 입력해야 합니다. STSADM -operationname만 입력하면 작동하지 않습니다. 예를 들어 설치 환경에 사이트 템플릿을 추가하려면 다음 명령을 사용합니다.
Stsadm -o addtemplate -filename <filename of the template>
-title <title of template> -description <description of template>
웹 파트 패키지를 추가하려는 경우에는 다음 명령을 사용할 수 있습니다.
Stsadm -o addwppack -filename <filename of the Web Part Package>
특정 명령의 자세한 사용 방법을 보려면 매개 변수 없이 명령을 입력하십시오. 그러면 입력해야 하는 내용이 표시됩니다. STSADM -help operationname은 해당 명령의 사용 방법에 대한 정보를 표시합니다.
템플릿을 관리할 경우 enumtemplates 명령을 사용하면 추가된 템플릿을 확인할 수 있으며 deletetemplate 명령을 사용하면 설치된 템플릿을 제거할 수 있습니다. 유사한 형태로 웹 파트 패키지에 사용할 수 있는 명령도 있습니다. enumwppacks 명령을 사용하여 각 가상 서버나 웹 응용 프로그램에 설치된 웹 파트 패키지를 나열할 수 있으며 deletewppack 명령을 사용하면 추가된 웹 파트를 제거할 수 있습니다.
STSADM에서 SharePoint 설정을 처리하는 두 가지 명령은 setproperty와 getproperty입니다. 이러한 명령을 매개 변수 없이 실행하면 해당 명령으로 표시하거나 조작할 수 있는 속성 목록이 표시됩니다. STSADM 자체와 마찬가지로 이 목록도 업데이트와 핫픽스로 변경됩니다. 이러한 속성 중에는 다른 속성보다 자주 사용되는 속성이 있습니다. 그림 1에는 SharePoint 관리자가 자주 문의하는 가장 일반적인 속성을 비롯한, SharePoint를 설치한 후에 설정할 수 있는 몇 가지 속성이 나열되어 있습니다.
Figure 1 유용한 SharePoint 속성 설정 (Close Figure 1)

속성 | 기능
Alerts-enabled | 가상 서버나 웹 응용 프로그램의 알림을 설정하거나 해제합니다.
Alerts-limited | 가상 서버나 웹 응용 프로그램에서 사용자가 설정할 수 있는 알림 수를 제한할 것인지 여부를 지정합니다.
Alerts-maximum | 알림 제한을 설정한 경우 사용자가 설정할 수 있는 최대 알림 수입니다.
Days-to-show-new-icon | 웹 사이트에 추가된 항목(예: 알림 게시물) 옆에 "새 항목" 아이콘을 표시하는 기간을 설정합니다.
Job-immediate-alerts | 전송할 알림을 SharePoint에서 검색하는 간격을 지정합니다. SharePoint 2.0의 기본값은 5분입니다. 여기에서 간격을 조정할 수 있습니다. 시간을 줄이면 웹 및 데이터베이스 서버의 부하가 증가하므로 이 속성을 변경할 때는 주의해야 합니다.
Job-daily-alerts | 매일 알림을 보내는 시간을 지정합니다. SharePoint 2.0 기본값은 "22:00에서 06:00 사이"입니다. 서버와 다른 표준 시간대에 있는 사용자가 있다면 이 속성을 수정할 수 있습니다.
Job-weekly-alerts | 여기에는 주간 알림의 예약 패턴이 표시됩니다.
이러한 속성 중 하나를 간략하게 살펴보겠습니다. 다음 명령은 SharePoint에서 10분마다 경고를 보내도록 설정합니다.
Stsadm -o setproperty -pn job-immediate-alerts -pv "Every 10 minutes"
-propertyname 및 -propertyvalue 대신 -pn 및 -pv를 사용했다는 것에 주의하십시오. 전체 단어를 입력하기 싫을 때 사용할 수 있는 바로 가기가 있습니다. 이 단원에서 설명하는 모든 예제와 명령은 Windows SharePoint Services 버전 2.0과 3.0 모두에서 작동한다는 것도 참고하십시오.

일상적인 관리
일상적인 SharePoint 관리는 매우 쉽습니다. 대부분의 SharePoint 관리자가 매일 수행하는 대부분의 업무는 사용자와 사이트 관련 업무로 구성되어 있습니다. STSADM에는 이러한 업무를 원활하게 처리할 수 있는 몇 가지 명령이 있습니다.
먼저 사이트 및 웹 작업부터 설명하겠습니다. 일관성을 위해 사이트 모음은 "사이트"라고 부르고 하위 사이트(하위 웹)는 "웹"이라고 부르겠습니다. 이해하기 어려운 용어도 있지만 STSADM에서 사용하는 용어를 따르면 필요한 명령을 더 쉽게 찾을 수 있습니다.
대규모 SharePoint 설치 환경의 경우 사용자를 위한 새로운 사이트를 구축하는 데 많은 시간이 들 것입니다. 필자도 이 작업을 반복적으로 수행했습니다. SharePoint 중앙 관리를 사용하여 새 사이트를 매우 쉽게 만들 수 있지만 이 작업을 자주 수행해 본 결과 STSADM을 사용하여 작업을 수행하는 것이 더 빠르다는 것을 알게 되었습니다.
필자는 createsite 명령을 사용합니다. 이 명령은 매우 단순하며 다음과 같은 매개 변수가 사용됩니다.
  • url <url>
  • ownerlogin <DOMAIN\name>
  • owneremail <someone@example.com>
  • ownername <display name>
  • lcid <language>
  • sitetemplate <site template>
  • title <site title>
  • description <site description>
  • quota <quota template>
명령 프롬프트에서 stsadm -help createsite를 입력하면 이러한 매개 변수 설명을 볼 수 있습니다(그림 2 참조). 이 9개 매개 변수 중에 필수 필드는 URL, ownerlogin 및 owneremail입니다.
그림 2 Createsite 매개 변수
그림 2 Createsite 매개 변수 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 Createsite 매개 변수
그림 2 Createsite 매개 변수 (더 크게 보려면 이미지를 클릭하십시오.)
일정한 규칙에 따라 만드는 사이트가 있는 경우 다음 단계에 따라 STSADM으로 작업을 자동화하는 래퍼 스크립트를 작성하여 프로세스를 효율적으로 처리할 수 있습니다. 예를 들어 개인 사이트 생성을 자동화하려면 다음 명령을 createpersonalsite.cmd라는 텍스트 파일로 저장합니다.
stsadm -o createsite -url http://localhost/users/%1 -ownerlogin contoso\%1
-owneremail %1@contoso.com -sitetemplate usersite.stp
-title "Personal site for %1" -description "Personal site for %1" -quota "500 MB"
그런 다음 jsmith라는 사용자의 사이트를 만들려면 다음 명령을 실행하면 됩니다.
createpersonalsite.cmd jsmith
사이트를 만드는 과정을 스크립트로 처리하면 입력해야 하는 정보의 양이 줄어들 뿐 아니라 새로 만드는 모든 사이트에서 일관성을 유지할 수 있습니다. createweb 명령은 웹 수준에서도 동일한 기능을 제공합니다.
Windows SharePoint Services 2.0에서 특정 가상 서버에 있는 사이트 모음의 모든 목록을 쉽게 가져올 수 있는 유일한 방법은 STSADM을 사용하는 것뿐입니다. enumsites 명령은 특정 가상 서버나 웹 응용 프로그램에 있는 모든 사이트 모음을 XML 형식으로 나열합니다. 이 명령과 데이터 뷰 웹 파트를 결합하면 사이트 모음 목록을 쉽게 볼 수 있습니다. 자세한 내용은 추가 기사의 "Working with a Data View Web Part"(영문)를 참조하십시오.
STSADM에는 deletesite 명령이 있습니다. 이름에서 알 수 있는 것처럼 이 명령은 사이트를 제거합니다. 이 명령을 사용할 때는 URL만 제공하면 되지만 -deleteadaccounts를 전달하여 Active Directory®에서 계정을 삭제할 수도 있습니다. 웹 작업 시에는 deleteweb 명령을 사용할 수 있습니다.
사이트 또는 웹의 사용자를 추가, 삭제 및 열거할 수 있습니다. 이와 관련된 명령은 adduser, deleteuser 및 enumusers입니다. 사이트에 많은 사용자를 추가해야 하거나 감사 용도로 사이트에 액세스할 수 있는 사용자 목록을 유지 관리해야 할 경우 이러한 명령을 유용하게 사용할 수 있습니다.
웹에서 작업할 때는 웹 이름 및 URL을 변경할 수 있는 renameweb이라는 명령을 사용할 수 있습니다. 예를 들어 웹 이름을 "oldname"에서 "coolnewname"으로 변경하려면 다음 명령을 사용합니다.
Stsadm -o renameweb -url http://localhost/oldname -newname coolnewname
프로젝트 이름이 변경되거나 부서가 조정되는 상황이라면 이 명령이 큰 도움이 될 것입니다. Windows SharePoint Services 2.0에서는 유일한 해결 방법이 SMIGRATE.exe를 사용하여 웹을 마이그레이션하는 것이었으므로 구성원 자격이나 경고 같은 사용자 관련 설정이 유지되지 않았기 때문에 이 같은 상황이 큰 문제가 되었지만, Windows SharePoint Services 3.0에서는 STSADM으로 웹과 사이트를 백업하고 복원할 수 있으므로 그다지 큰 문제가 아닙니다.

백업 및 복원
STSADM의 가장 유용한 기능 중 하나는 사이트와 웹을 백업하고 복원하는 기능입니다. 중소 규모의 설치에서는 이 기능을 장애 복구 계획의 초석으로 사용할 수 있습니다. backup 명령은 설명이 필요 없이 명확하므로 매우 사용하기 쉽습니다. 다음과 같이 STSADM에 백업할 사이트와 백업 파일을 기록할 위치를 지정하기만 하면 됩니다.
Stsadm -o backup -url http://localhost -filename site.bak
이 명령은 전체 사이트 모음을 site.bak 파일에 덤프합니다. 여기에는 웹, 문서 버전, 목록 및 사용자 같은 모든 사이트 콘텐츠가 포함되지만 사이트 정의나 서버의 파일 시스템 수준에서 변경한 내용은 백업에 포함되지 않습니다.
backup 명령은 매우 중요하므로 몇 가지 사항에 주의해야 합니다. 먼저, 사이트가 비교적 큰 경우 백업 작업 중에 콘텐츠 데이터베이스에 잠금이 설정될 수 있습니다. 그러면 backup 명령이 완료될 때까지 사용자들은 해당 데이터베이스에 있는 모든 사이트에 액세스할 수 없게 됩니다. 이 문제는 서비스 팩으로 완화되었지만 사이트가 커지면 여전히 주의해야 합니다. 또한 STSADM은 백업 및 복원을 수행할 때 서버의 임시 디렉터리를 사용하므로 드라이브 공간도 모니터링해야 합니다.
데이터 뷰 웹 파트 사용
enumsites 명령과 데이터 뷰 웹 파트를 결합하면 간편하게 사이트 모음 목록을 만들고 확인할 수 있습니다. 이제부터 그 방법을 살펴보겠습니다.
먼저 다음을 실행하는 예약 작업을 만듭니다.
stsadm –o enumsites –url http://localhost
>c:\inetpub\wwwroot\excludedsite\sites.xml
XML 파일이 IIS로 게시되었으며 SharePoint로 관리되지 않는 디렉터리에 작성되는지 확인하십시오. 그런 다음 Microsoft FrontPage®(또는 FrontPage 후속 버전인 Microsoft Office SharePoint Designer 2007)를 사용하여 웹 파트 페이지에 데이터 뷰 웹 파트를 추가하고 XML 파일의 URL을 가리키도록 설정합니다.
데이터 뷰 웹 파트는 정렬, 필터 및 그룹화 기능을 제공합니다. 또한 URL 필드가 해당 사이트로 직접 연결되게 설정할 수 있습니다. 웹 목록을 처리하려는 경우에는 enumsubwebs 명령을 사용하여 사이트 모음이나 웹의 하위 웹을 XML로 출력할 수 있습니다.

마지막으로, STSADM 백업이 중소 규모 사이트에는 잘 작동하지만 확장성이 그다지 뛰어나지 않아 수 기가바이트 이상의 대규모 사이트에서는 백업 및 복원 프로세스가 상당히 느려질 수 있다는 점에 주의하십시오.
사이트 복원도 매우 간단합니다. STSADM -o restore는 STSADM -o backup으로 작성된 파일을 가져와 SharePoint의 사이트로 복원합니다. 이 명령은 융통성이 많습니다. 사이트를 원래 위치에 복원하거나(사이트를 실수로 삭제한 경우), 동일한 가상 서버의 다른 사이트로 복원하거나(데이터 손상 위험 없이 사이트에서 프로세스를 테스트하려는 경우), 사이트를 전혀 다른 서버나 가상 서버에 복원할 수 있습니다.
다른 사이트나 서버에 복원하면 개별 문서를 복구하는 작업이 좀 더 손쉬울 수 있습니다. 사이트를 백업했고 문서를 복원하는 경우 전체 사이트를 복원할 필요는 없습니다. 그렇게 하면 백업을 저장한 후에 사이트에서 변경한 모든 내용이 사라집니다. 그렇게 하는 것보다 사이트를 다른 URL로 복원하고 문서를 찾은 후 해당 문서만 원래 사이트에 복원하는 것이 현명합니다.
Windows SharePoint Services 2.0의 STSADM에는 사이트만 백업할 수 있고 웹은 백업할 수 없다는 상당히 심각한 제한이 있습니다. 많은 관리자가 불만을 제기했고 Microsoft가 이를 받아들여 Windows SharePoint Services 3.0에서는 backup 및 restore 명령에서 웹을 처리할 수 있게 되었습니다. 또한 import와 export 명령이 새롭게 추가되었습니다.
웹을 내보내려면 다음과 같은 간단한 명령을 사용합니다.
Stsadm -o export -url http://localhost/web -filename backup.dat
export에는 편리한 옵션이 있습니다. 그 중 하나인 -versions 스위치를 사용하면 백업할 파일 버전을 제한하여 백업 파일의 크기를 제어할 수 있습니다.
웹을 다시 서버로 가져오려면 다음과 같은 명령을 사용합니다.
Stsadm -o import -url http://localhost/web2 -filename backup.dat
사이트가 큰 경우에는 백업 파일이 여러 개로 분할되어 있을 수 있습니다. 이 경우에는 STSADM -o import로 첫 번째 파일을 가리키면 후속 파일이 자동으로 검색됩니다.

전문가 명령
이제 STSADM이 편안하게 느껴지실 것입니다. 계속해서 어려움을 해결할 수 있는 몇 가지 명령을 알려 드리겠습니다. 먼저 새로 추가된 migrateuser 명령입니다. 버전 2.0에는 Active Directory 동기화 기능이 없기 때문에 계정 이름이 바뀌면 해당 계정으로 SharePoint에 로그인할 수 없게 됩니다. 또한, 한 도메인 사용자에서 다른 도메인 사용자로 사용자 액세스 권한을 마이그레이션하는 방법도 없었습니다. 따라서 Windows SharePoint Services 2.0 서비스 팩 2(SP2) 이전에는 각각의 웹에서 사용자를 제거하고 새 계정을 수동으로 추가해야 했습니다.
그러나 SP2에는 새로운 API가 도입되었고 STSADM은 해당 API를 이용합니다. 예를 들어 jsmith 계정의 이름이 jjones로 바뀐 경우 다음 명령을 사용할 수 있습니다.
Stsadm -o migrateuser -oldlogin domain\jsmith -newlogin domain\jjones -ignoresidhistory
실제로 계정을 마이그레이션하는 것이 아니므로 Windows 보안 ID(SID) 기록은 무시할 수 있습니다. 이 명령에는 URL이 필요 없으며, 사이트 또는 웹에 관계없이 콘텐츠 데이터베이스 전체를 변경합니다.
문제를 해결하는 또 다른 명령은 unextendvs입니다. SharePoint로 가상 서버나 웹 응용 프로그램을 렌더링하지 않는 경우 SharePoint 확장을 취소할 수 있습니다. 일반적으로 SharePoint Configuration Analyzer(구성 분석기)에서 이 작업을 수행합니다. 하지만 웹 팜의 경우에는 모든 서버에 동일한 수준으로 패치가 적용되어 있어야 SharePoint Configuration Analyzer(구성 분석기)를 사용할 수 있습니다. 팜의 다른 서버와 동기화되지 않은 서버가 있으면 SharePoint Configuration Analyzer(구성 분석기)에서 확장 취소 옵션을 사용할 수 없습니다. 하지만 STSADM을 사용하면 다음 명령으로 가상 서버의 확장을 취소할 수 있습니다.
Stsadm -o unextendvs -url http://localhost
서버가 웹 팜에 속하지 않게 되면 필요한 유지 관리 작업을 수행할 수 있습니다.
웹 팜의 관리를 쉽게 하기 위해 모든 서버의 SharePoint Configuration Analyzer(구성 분석기)를 동일한 포트로 설정할 수 있습니다. 포트는 SharePoint를 설치할 때 임의로 설정되지만 STSADM에는 포트를 지정한 포트로 변경하는 명령이 있습니다.
Stsadm -o setadminport -port 1026
이렇게 하면 모든 필수 데이터베이스가 변경되고 IIS가 변경되며 관리 도구에서 SharePoint Configuration Analyzer(구성 분석기) 바로 가기가 수정됩니다.

결론
Windows SharePoint Services는 강력한 솔루션이며 뛰어난 관리를 필요로 합니다. STSADM을 사용하면 SharePoint를 쉽게 관리할 수 있을 뿐 아니라 구성 작업과 일상적인 작업을 자동화할 수 있습니다. 실제로 STSADM을 사용해야만 수행할 수 있는 작업도 있습니다.

Todd Klindt는 UGS의 시스템 분석가로, 하루 종일 SharePoint로 작업하고 있으며 그것으로 월급도 받고 있습니다. 그는 Windows SharePoint Services MVP이며 탄생 별자리는 물병자리입니다.


 SharePoint: 작업에 Wiki 활용
SharePoint Mauro Cardarelli

작업에 Wiki 활용
한 눈에 보기:
  • Wiki의 정의
  • SharePoint에서 Wiki 구축
  • 변경 사항 편집 및 추적

Wiki라는 개념이 등장한 지는 10년이 넘었습니다. 가장 단순한 형태의 Wiki(하와이어로 "빠르다"는 의미)는 사용자들이 자유롭게 웹 페이지 콘텐츠를 만들고 편집할 수 있는 온라인 공간으로,
브라우저에서만 사용할 수 있습니다. Wiki의 목적은 가상 커뮤니티 구성원들이 어떤 페이지든 자유롭게 편집하여 다른 사람들이 이전에 만든 콘텐츠를 비롯한 모든 콘텐츠를 소개하고, 변경하고, 필요한 경우 추가한 내용을 제거할 수 있는 공간을 제공하는 것입니다. 보다 구조화된 지식 교환과 일대다 커뮤니케이션에 맞게 설계된 블로그와 달리 Wiki에서는 좀 더 활발한 공동 작업이 가능합니다.
최근 Web 2.0이라는 이름으로 등장한 차세대 온라인 도구에 많은 관심이 집중되고 있습니다. Web 2.0은 콘텐츠 제작을 둘러싼 장벽을 낮춰 사용자들이 온라인 정보의 소비자인 동시에 제작자가 될 수 있도록 합니다. 이러한 현상은 인터넷 세상만이 아니라 기업 방화벽 내에서도 일어나고 있습니다. Web 2.0은 모든 직원들이 보다 쉽게 콘텐츠를 제작할 수 있는 Enterprise 2.0과 같은 도구로 생각할 수 있습니다. 블로그나 Wiki 같은 기술은 앞으로 오랜 시간 회사들이 기업 지식을 생산하고, 저장하고, 재활용하는 방식에 변화를 가져올 것입니다.
Microsoft에서는 인기 있는 SharePoint 기술의 세 번째 버전인 Microsoft® Office SharePoint® Server(MOSS) 2007의 등장과 함께 이 차세대 기능을 더욱 적극적으로 활용하고 있습니다. MOSS 2007에서는 보다 폭넓은 공동 작업 및 커뮤니케이션 기능과 함께 블로그 및 Wiki 구축도 지원합니다. 이 문서에서는 MOSS 2007을 활용하여 Wiki를 구축하는 방법에 대해 설명합니다.

시작
기존에 SharePoint Portal Server 2003을 사용해 왔다면 사이트 템플릿 사용에 매우 익숙할 것입니다. 사이트 템플릿은 특정 유형의 페이지(팀, 모임, 친목 행사 등) 레이아웃에 사용되는 프레임워크로, 특정 콘텐츠의 자리 표시자를 사전에 설정해 둔 것입니다. MOSS 2007에서는 새로운 템플릿 유형이 도입되어 사이트 템플릿을 보다 폭넓게 사용할 수 있습니다. 이 중 하나가 Wiki를 위한 템플릿입니다.
그림 1은 SharePoint 사이트를 만드는 데 사용되는 New SharePoint Site(새로운 SharePoint 사이트) 페이지입니다. 템플릿 목록에 Wiki 사이트를 위한 항목이 있는 것을 볼 수 있습니다. 이 템플릿을 선택하면 첫 번째로 만드는 Wiki를 쉽고 빠르게 만들 수 있습니다. 그림 2는 새로 만들어진 Wiki의 기본적인 모습입니다. Wiki는 이 기본 페이지를 홈 페이지로 삼는 구조입니다. 여기 나타나는 모든 내용은 편집할 수 있습니다. 적절한 권한이 있는 사용자(작성자의 가상 커뮤니티)는 이 페이지를 수정하거나 새 페이지를 만들 수 있습니다.
그림 1 새 사이트에 사용할 Wiki 템플릿 선택
그림 1 새 사이트에 사용할 Wiki 템플릿 선택
그림 2 편집을 기다리고 있는 새 SharePoint Wiki
그림 2 편집을 기다리고 있는 새 SharePoint Wiki (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 편집을 기다리고 있는 새 SharePoint Wiki
그림 2 편집을 기다리고 있는 새 SharePoint Wiki (더 크게 보려면 이미지를 클릭하십시오.)
다음 단계로 넘어가기 전에 잠시 Wiki를 사용자에게 소개하는 방법에 대해 알아보겠습니다. 앞서 언급했듯이 Wiki가 인터넷과 타사 도구를 통해 등장한 지는 꽤 오래되었습니다. 하지만 대부분의 경우에 Wiki는 전문적인 기술이 있어야만 사용할 수 있었기 때문에 사람들의 입을 통해 느린 속도로 퍼져 나갔습니다. MOSS 2007은 모든 인트라넷 사용자에게 Wiki 기능을 제공하여 이러한 상황을 변화시키려 하고 있습니다. 이는 막강하고도 두려운 계획입니다. 여러분은 전문 기술도 없고 인터넷도 잘 모르는 직장 동료에게 Wiki의 가치를 어떻게 설명하시겠습니까? 여러분이 말해 주어야 하는 것은 Wiki가 모든 사용자들이 자신의 의견을 낼 수 있을 만큼 자유로운 환경에서 의견과 아이디어를 독창적으로 교환할 수 있게 하려는 목적으로 만들어졌다는 것입니다. Wiki를 사용하면 콘텐츠 공동 작업이 수월해지기도 하지만 실제로는 훨씬 많은 장점이 있습니다. Wiki의 최종 결과물은 하나의 문서나 하나의 단원이 아니라 책 전체입니다. 단, 언제든지 필요할 때마다 수정이 가능하기 때문에 결코 완결할 필요가 없는 책입니다.
이제 업무와 관련지어 살펴보겠습니다. Wiki를 처음 접하는 사용자의 경우, How to Use This Wiki Site라는 하이퍼링크를 통해 설명을 접할 수 있습니다. 기본 Wiki 템플릿은 초보 사용자들이 Wiki를 빨리 익히고 사용할 수 있도록 충분한 설명서와 함께 제공됩니다.

Wiki의 작동 방식
모든 Wiki 페이지의 오른쪽 위에는 작업 단추가 있습니다. "Edit"(편집) 단추를 클릭하면 콘텐츠 편집과 연관된 페이지로 이동합니다. 그림 3은 그 예입니다. 모든 편집은 브라우저에서 이루어지므로 Microsoft Word 같은 외부 도구를 사용할 필요가 없습니다. 또한 편집은 온라인에서 실시간으로 이루어집니다(저장한 경우). 뿐만 아니라 웹 디자인이나 개발 기술이 필요하지도 않습니다. 편집 인터페이스에서는 굵은 글꼴, 색상 지정, 글머리 기호, 이미지 등 다양한 서식이 지정된 텍스트를 표준 단추만 사용하여 작성할 수 있습니다. 사용자는 기존 페이지를 편집 모드로 열어서 콘텐츠를 추가하거나 수정하기만 하면 됩니다. 이게 다입니다.
그림 3 브라우저 내에서 전체 Wiki 콘텐츠 편집
그림 3 브라우저 내에서 전체 Wiki 콘텐츠 편집 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 브라우저 내에서 전체 Wiki 콘텐츠 편집
그림 3 브라우저 내에서 전체 Wiki 콘텐츠 편집 (더 크게 보려면 이미지를 클릭하십시오.)
콘텐츠가 끊임없이 변하는 환경에서는 어떻게 변경 사항을 관리해야 할까요? 반드시 모든 변경 사항을 단속할 필요는 없지만 변경 사항을 추적하고 버전 기록을 관리할 방법은 필요할 수 있습니다. MOSS 2007에서는 이것이 가능합니다. 그림 4는 'History"(기록) 단추를 클릭한 후 나타나는 표준적인 페이지의 모습입니다. 중앙에는 현재까지 추적된 텍스트 변경 사항이 표시됩니다. 왼쪽에는 변경이 이루어진 시간별로 추적된 변경 내역이 표시됩니다. 커뮤니티는 자유자재로 변경 사항을 검토하고 추적하고 롤백할 수 있습니다. 그야말로 막강한 기능이라고 할 수 있습니다. Wiki를 새로 구축하고 변경하면 MOSS 2007에서 이러한 과정을 추적하게 됩니다.
그림 4 시간에 따라 Wiki 항목 변경 사항 추적
그림 4 시간에 따라 Wiki 항목 변경 사항 추적 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 시간에 따라 Wiki 항목 변경 사항 추적
그림 4 시간에 따라 Wiki 항목 변경 사항 추적 (더 크게 보려면 이미지를 클릭하십시오.)
앞서 설명했지만 Wiki는 웹 페이지가 아닙니다. Wiki는 한계가 없는 페이지들의 집합입니다. Wiki 커뮤니티의 구성원은 새로운 아이디어나 논점을 제시할 수 있습니다. 기존 페이지에 텍스트를 추가하지 않고 기존 페이지에서 갈라져 나온 새로운 페이지를 만들 수도 있습니다. MOSS 2007에서는 Wiki 페이지를 쉽게 추가할 수 있기 때문에 이것이 가능합니다. "New"(새로 만들기)를 클릭하기만 하면 새 Wiki 페이지가 만들어집니다. 콘텐츠를 추가해 보십시오. 절대 어렵지 않습니다!

결론
MOSS 2007에 Wiki의 개념이 도입되지 않았더라도 그 폭넓은 가용성을 생각하면 매력적인 솔루션이라는 것은 분명합니다. Wiki는 조직 내 작업자의 공동 작업 방식을 변화시킬 수 있습니다. 작업자들은 더 이상 문서의 한계에 얽매이지 않아도 됩니다. Wiki는 구조화되지 않은 사고와 폭넓은 공동 작업을 가능하게 하며, 이는 Enterprise 2.0의 철학과 연관된 보다 광범위한 개념과 결합됩니다. Wiki는 모든 것을 가능하게 합니다. 모든 사용자들이 참여할 수 있고, 정해진 길을 따라갈 수 있을 뿐만 아니라 새로운 길을 개척할 수도 있습니다.

Mauro Cardarelli는 보스턴에 위치한 Jornata라는 IT 컨설팅 서비스 회사의 관리 담당 파트너로, 기술 교육, 아키텍처 설계, 소프트웨어 개발 업무를 맡고 있습니다. 문의 사항이 있으면 mauro.cardarelli@jornata.com으로 연락하시기 바랍니다.


 From The Editor: 때로는 업계가
From The Editor

때로는 업계가 큰 변화를 겪기도 합니다. 이는 비단 기술 분야뿐만 아니라 정치, 패션을 비롯한 모든 분야가 마찬가지입니다. 몇 주 전 라스베이거스에서 열린 Windows Connection 컨퍼런스에서 연설을 할 때 저는 이 문제에 대해 생각하고 있었습니다. 5년 전 11월이라면 저는 아마 Comdex에 있었을 것입니다. Comdex는 전 세계 모든 기술 부문의 구매자와 새로운 것을 받아들이려는 사람들이 모이는 대규모 박람회였습니다. 하지만 20년에 가까운 기간 동안 꾸준히 성장했던 이 박람회는 거의 하룻밤 사이에 사라지고 말았습니다. 그래서 저는 많은 관심을 받았던 대규모 박람회에 참가하는 대신 소수의 개발자와 IT 제품을 대상으로 하며 한정된 지역에만 방송되었지만 매우 성공적이었던 박람회에서 연설을 했습니다. 저의 말은 같은 장소에 있는 사람들에게만 전달되었지만 참가한 모든 사람에게는 그 규모가 더욱 의미가 있었습니다.
제가 강연한 내용은 모두 기술 문서를 어떻게 작성하고, 언제 작성하고, 왜 작성해야 하는지에 관한 것이었습니다. 우리 업계의 변화는 Comdex의 역사뿐만 아니라 기술 커뮤니케이션의 세계에서도 나타나고 있습니다. 5년 전에도 저는 유사한 연설을 한 적이 있는데 그것은 잡지에 관한 것이었습니다. 그때만 해도 블로그에 대해 아는 사람은 거의 없었습니다. 커뮤니티 사이트는 지금과 비교하면 매우 초라했습니다. 지난 5년 동안 우리는 글로 쓰여진 말이 전달되는 방식이 과거와는 비교할 수 없을 정도로 엄청나게 변화하는 것을 보아 왔습니다.
물론 이것은 여러 가지 면에서 축복입니다. 다양한 형식의 커뮤니케이션이 다양한 목적으로 사용되고 있습니다. 사람들은 자신들의 생각을 자유롭게 온라인에 게시할 수 있지만, 그러한 생각을 잡지에 싣는다는 것은 대개 편집과 전문적인 검증 과정을 거친다는 것을 의미합니다. 블로그에 게시된 글을 삭제할 수는 있지만 모든 사람들의 집을 일일이 찾아다니면서 28페이지의 섹션을 삭제하라고 말할 수는 없습니다.
제가 지금 이러한 변화에 대해 이야기하는 데는 이유가 있습니다. 수많은 독자들이 저희 잡지에 보내 주신 의견에 따라 저희는 칼럼 편성을 늘리고 있습니다. 이번 호에는 온라인에서의 인기에 힘입어 이제는 오프라인까지 진출한 TechNet 인기 칼럼 The Cable Guy가 처음으로 게재됩니다. 또한 포스트마스터들의 의견을 듣고 Exchange Server 2007이 커다란 이슈가 될 것이라고 판단하여 Exchange Queue & A라는 칼럼도 정기적으로 게재할 계획입니다. (기발한 이름 아닌가요!)
잡지에서 Microsoft 기술에 관한 글을 보고 싶으시다면 말씀해 주십시오. 저희가 할 수 있는 최상의 서비스는 여러분이 필요로 하는 것을 제공하는 것입니다. £Joshua Trupin

많은 Microsoft 기술 전문가들께서 도움을 주셨습니다. Puneet Arora, Jeff Bienvenu, Nino Bilic, Eric Broberg, Ramesh Chinta, Matt Cohen, Michael Dalton, George Irimescu, Bryan Jeffries, Dave Kong, Vijay Krishna, Rob Lefferts, Lawrence Liu, Bob Ma, Manu Namboodiri, Joel Oleson, Arpan Shah, Troy Starr, James Sturms, Jim Truher, Blaine Young에게 감사의 말을 전합니다.


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

서버 관리
Windows Server 2003 Resource Kit 도구
go.microsoft.com/fwlink/?LinkId=77796(영문)
Microsoft Windows Server 2003 Resource Kit 도구는 관리 작업을 간소화하고 자동화하는 데 필요한 100개 이상의 유틸리티로 구성된 중요한 유틸리티 모음입니다. 이 도구에는 Active Directory® 도구부터 네트워크 문제 해결 유틸리티와 CD/DVD 이미지 버너에 이르기까지 모든 유틸리티가 포함되어 있습니다.
Custom Reason Editor(custreasonedit.exe)는 시스템 종료 이벤트 추적기를 구성하는 데 매우 유용한 도구입니다. Windows Server® 2003의 구성 요소인 시스템 종료 이벤트 추적기는 시스템이 종료된 이유를 이벤트 로그에 기록합니다. Custom Reason Editor 도구를 사용하면 구성 가능한 매개 변수의 사용자 지정 목록을 만들어 기본적으로 설정된 기본 제공 이유를 다시 정의할 수 있습니다. 이 도구를 사용하면 이벤트 항목을 논리적으로 잘 정리하여 시스템 종료의 원인이 될 수 있는 문제 프로세스, 응용 프로그램 또는 시스템 상태를 손쉽게 집계하여 파악할 수 있습니다.
DNS Resolver Tool은 SMTP 서비스의 DNS 확인과 비슷한 작업을 실행하는 명령줄 유틸리티이며 명령 매개 변수로 지정한 DNS 쿼리의 상태 메시지를 표시합니다. 이 유틸리티는 SMTP 서비스가 설치되어 있는 모든 Windows Server 2003 호스트에서 실행되며 배치 파일에 사용할 수 있는 오류 코드를 반환합니다. CDBurn.exe 및 DVDburn.exe는 ISO 이미지에서 CD와 DVD를 만드는 명령줄 유틸리티이며, 새 디스크 이미지를 적용하기 전에 미디어를 정리하는 /Erase 스위치를 사용하여 RW 미디어를 제한적으로 지원합니다. 이러한 유틸리티는 인프라에서 보관 프로세스를 자동화하는 데 사용할 수 있습니다.
Windows Server 2003 Resource Kit
Windows Server 2003 Resource Kit (더 작게 보려면 이미지를 클릭하십시오.)
Windows Server 2003 Resource Kit
Windows Server 2003 Resource Kit (더 크게 보려면 이미지를 클릭하십시오.)
특정 계정이 올바르게 잠겼는지 확인해야 할 경우 Account Lockout Status 도구를 사용하면 명령줄 또는 GUI 옵션 중 한 가지 방법을 선택하여 잠금 상태를 쉽고 빠르게 확인할 수 있습니다. 이 도구는 액세스 가능한 모든 도메인 컨트롤러에 쿼리하여 대상 사용자의 계정 상태를 확인합니다. 자동화하는 데 가장 효과적인 도구 중 하나인 Robust File Copy Utility(Robocopy.exe)는 파일을 이동하거나 복사하는 데 사용할 수 있는 여러 가지 옵션을 제공합니다. 이 도구를 사용하면 와일드카드 문자와 파일 특성을 사용하여 복사할 대상을 지정할 수 있으며 복사 작업을 반복하도록 설정할 수도 있습니다. 또한 이 도구를 동기화 작업에도 사용하여 원본 디렉터리에서 삭제된 대상 파일이나 디렉터리를 모두 제거하도록 설정할 수 있습니다.
Tail(tail.exe)이라고 하는 간단한 도구도 개인적으로 즐겨 사용하는 유틸리티 중 하나입니다. 이 도구는 Linux/UNIX 유틸리티와 마찬가지로 파일에서 마지막 'N'개의 줄을 표시하고 새 줄이 추가될 때마다 화면을 새로 고칩니다. 이 방법은 로그 파일에 기록하는 모든 작업을 디버깅하거나 모니터링할 경우에 매우 유용합니다.
Time It(timeit.exe)을 사용하면 명령 실행 시간을 확인할 수 있고 데이터가 개별 데이터베이스 파일에 저장되기 때문에 관리 작업에 소요되는 실제 시간을 테스트할 수 있습니다.
이러한 도구는 영어로만 작성 및 테스트되었고 아직 다른 언어 버전으로 지역화되지 않았으므로 실행 시 "예기치 않은 결과"가 나타날 수 있습니다. 프로덕션 환경에서 이러한 유틸리티 중 하나를 사용하려면 먼저 영어 이외의 언어 기반 시스템에서 반드시 테스트하십시오.
가격: 무료 다운로드

문제 추적
ASP.NET Issue Tracker
www.ASP.NET/StarterKits/WhitePapers/Issue%20Tracker%20Whitepaper.htm(영문)
응용 프로그램을 더욱 유용하게 만드는 데는 크게 두 가지 요소가 영향을 준다고 생각합니다. 즉, 응용 프로그램이 무료로 제공되고 사용자 지정 가능한 경우가 바로 그것입니다. ASP.NET 온라인 개발자 커뮤니티를 통해 제공되는 ASP.NET Issue Tracker는 이 두 가지 요소를 모두 충족합니다. ASP.NET 1.1 프레임워크에서 웹 응용 프로그램을 프로그래밍하는 방법을 배울 수 있도록 설계된 Issue Tracker는 단순하지만 프로젝트와 관련된 문제를 추적하는 데 매우 유용한 도구입니다.
이 도구는 인터페이스가 매우 간단하며 프로젝트, 사용자 및 문제점을 쉽게 만들 수 있도록 도와줍니다. 이 응용 프로그램은 역할 기반의 사용 권한을 가진 여러 명의 사용자를 지원하며 권한 있는 사람만 액세스할 수 있도록 하는 보호 기능도 제공합니다. 각 프로젝트에 대해 사용자 지정 문제점 카탈로그를 만들고 다양한 형식의 사용자 지정 데이터 필드를 만들 수도 있습니다. 또한 작업에 대해 상태, 우선 순위 및 중요 시점을 지정하여 프로젝트를 구성할 수 있습니다.
또 다른 유용한 기능은 프로젝트를 만들 때 각 프로젝트에 대해 상태 코드, 우선 순위 및 중요 시점을 사용자 지정하고 프로젝트를 나타내는 이미지를 지정할 수 있다는 것입니다. 모든 코드를 다운로드할 수 있으므로 .NET 개발자가 있거나 기존 코드를 직접 사용할 수 있는 경우에는 이 시작 키트를 사용하여 필요한 사용자 지정 기능을 만들 수 있습니다.
가격: 무료

시스템 모니터링
NetHealth Sentinel Professional
www.nethealthsys.com
네트워크 및 시스템 모니터링은 반드시 필요한 기능이기 때문에 필자는 원격에서 컴퓨터 상태 정보를 확인할 수 있는 응용 프로그램에 많은 관심을 가지고 있습니다. NetHealth Systems의 NetHealth Sentinel Professional은 바로 이러한 기능을 제공합니다.
에이전트 기반 솔루션인 Sentinel Professional을 사용하면 모니터링 대상 호스트 컴퓨터를 자세하게 분석할 수 있습니다. 이 응용 프로그램은 Admin Server, Admin Console, Connection Manager 및 Remote Agent의 네 가지 구성 요소로 이루어져 있습니다. Admin Server는 예약된 작업을 실행하고 구성 정보를 저장하고 Connection Manager를 통해 경고를 수집합니다.
Admin Console은 Admin Server의 그래픽 인터페이스로, 모니터링 대상 시스템을 보고 구성하는 것뿐만 아니라 예약된 작업 또는 이벤트를 설정할 수 있는 기능을 제공합니다. Connection Manager는 Remote Agent(모니터링 대상 시스템에 있는 호스트 에이전트)로부터 모든 데이터를 수집합니다. Remote Agent는 Windows 서비스로 실행되며 보안 연결을 통해 Connection Manager와 안전하게 통신합니다. 하나 이상의 Connection Manager에 경고를 보내도록 각 Remote Agent를 구성할 수 있습니다.
NetHealth Sentinel Professional
NetHealth Sentinel Professional (더 작게 보려면 이미지를 클릭하십시오.)
NetHealth Sentinel Professional
NetHealth Sentinel Professional (더 크게 보려면 이미지를 클릭하십시오.)
한 가지 편리한 기능은 지정한 모니터링 그룹에 속한 모든 컴퓨터에서 발생한 이벤트를 집계할 수 있다는 것입니다. 또한 효율적인 GUI를 통해 Event 보기의 데이터 열을 끌어서 놓는 방법으로 데이터를 항목별로 그룹화할 수 있습니다.
이 응용 프로그램에는 모니터링하려는 통계 자료에 대한 개요를 제공하는 Vital Signs 패널도 있습니다. 기본적으로는 이 패널에는 CPU, 디스크 및 메모리 사용률이 표시되지만 Monitor 탭을 통해 원하는 카운터를 추가할 수 있습니다.
NetHealth Sentinel Professional은 사용자가 컴퓨터의 "일반적인" 작업 수준을 설정하면 특정 작업이 이러한 기본값을 초과할 경우 자동으로 경고를 실행하는 기준 설정 기능도 제공합니다.
가격: $495(10 클라이언트 액세스 라이선스 팩)

데이터 암호화
TrueCrypt
www.truecrypt.org
TrueCrypt Foundation에서 제공하는 TrueCrypt는 바로 사용할 수 있으며 소스가 공개된 무료 암호화 도구입니다. 올바른 암호나 암호화 키만 있으면 암호화된 볼륨을 대상으로 메모리에서 원하는 정보의 암호를 해독하거나 기록할 데이터를 암호화할 수 있습니다. 볼륨은 항상 암호화된 상태로 존재하므로 데이터가 노출될 염려가 없습니다. 단, 이 응용 프로그램이 메모리에 있는 데이터의 암호를 해독하는 동안 메모리 덤프가 발생하는 경우에는 보호하려는 정보가 공격자에게 노출될 수 있습니다. 그러나 어느 시점이든 암호화되지 않은 상태로 메모리에 존재할 수 데이터의 양은 매우 적을 뿐만 아니라 시스템에서 메모리 덤프를 사용하지 않도록 설정하면 이러한 문제 자체를 방지할 수 있습니다.
이 응용 프로그램은 가상 볼륨과 실제 파티션/장치를 모두 지원합니다. "파일 컨테이너"라고 하는 가상 볼륨을 만들 때는 파일 확장명을 마음대로 선택하거나 파일 확장명을 아예 지정하지 않을 수도 있기 때문에 이러한 중요한 데이터가 공격자에게는 임의의 데이터로 보일 수 있습니다. 간단하게 말하자면 TrueCrypt는 고유의 "파일 서명"을 사용하지 않습니다.
TrueCrypt
TrueCrypt (더 작게 보려면 이미지를 클릭하십시오.)
TrueCrypt
TrueCrypt (더 크게 보려면 이미지를 클릭하십시오.)
TrueCrypt는 "이동 모드"로도 실행할 수 있습니다. 즉, USB 키에 파일 컨테이너와 응용 프로그램 파일을 만들면 원하는 곳으로 이동한 후 호스트 시스템에 TrueCrypte 응용 프로그램을 설치하지 않고도 암호화된 데이터를 사용할 수 있습니다. 그러나 메모리에 읽거나 쓰는 기능을 사용하려면 휴대용 디스크를 사용할 시스템에 대한 관리자 권한이 필요합니다.
TrueCrypt는 휴대용 디스크를 설정할 수 있는 간단한 마법사도 제공합니다. 이 기능은 중요한 회사 데이터가 노출될 가능성을 최소화하면서 시스템 관리 정보를 휴대해야 할 경우에 매우 유용합니다.
TrueCrypt를 사용하면 파일 컨테이너 내에 숨겨진 볼륨을 만들어 보안을 더욱 강화할 수 있습니다. 이 경우 침입자가 외부 볼륨에 액세스하더라도 디스크 안에 숨겨진 볼륨이 있다는 사실을 알 수 없습니다. 각 볼륨은 임의의 데이터로 초기화되기 때문에 외부 볼륨의 "여유 공간"에 있는 숨겨진 볼륨을 찾기가 매우 어렵습니다.
TrueCrypt는 AES, Blowfish, CAST5, Serpent, Triple DES, Twofish 및 이러한 알고리즘의 몇 가지 조합을 사용하여 데이터를 암호화할 수 있습니다. 이 응용 프로그램은 데이터를 암호화할 때 섹터 기반 저장소 암호화에 대한 IEEE 표준으로 채택될 LRW 모드를 사용합니다. 헤더 해시 알고리즘으로는 Whirlpool, SHA-1 또는 RIPEME-160 중에서 선택할 수 있으며 이 경우 응용 프로그램에서는 강력한 데이터 보호를 위해 시스템에 해시를 저장하지 않습니다. TrueCrypt는 FAT12, FAT16, FAT32 및 NTFS 파일 시스템을 지원하지만 다른 Windows 기반 섹터 암호화 유틸리티와 마찬가지로 Windows 부팅 파티션은 암호화하지 않습니다.
가격: 무료

서평
Hacking Web Services
www.charlesriver.com
Shreeraj Shah가 저술한 Hacking Web Services(Charles River Media, 2006년)는 웹 서비스 개발, 배포 또는 지원에 관여하는 사용자에게 매우 유용한 책입니다. 이 책은 웹 서비스 및 웹 서비스 구성 요소 기술에 대한 훌륭한 보안 참조 가이드이며 조직의 인프라 및 실제 개발 과정에서 웹 서비스와 그 구성 요소를 보호하는 여러 가지 방법을 자세하게 설명합니다.
웹 서비스에 대한 심도 있는 소개를 시작으로 "The Consequences of Procrastination"이라는 제목의 사례 연구를 통해 사전 대비식 보안 절차의 이점과 사후 대응식 시스템의 단점을 설명합니다. "Web Services Scanning and Enumeration" 장에서는 Net-Square(net-square.com/wschess/index.shtml)에서 제공하는 .NET 기반 웹 서비스 보안 도구 키트인 wsChess를 사용하여 웹 서비스를 개괄적으로 파악하고 적용 범위를 설정하는 방법을 설명합니다.
이 책에는 예제 .NET 기반 응용 프로그램인 SOAPWall이 들어 있는 유틸리티 CD도 함께 제공됩니다. 이 응용 프로그램은 .NET 웹 서비스에서 주입 문자와 버퍼 오버플로를 차단하는 방법을 보여 줍니다. 또한 이 CD에는 다양한 웹 서비스 공격 유형을 보여 주는 데모도 들어 있습니다.
가격: $49.95.
Shreeraj Shah가 저술한 Hacking Web Services(Charles River Media, 2006년)는 웹 서비스 개발, 배포 또는 지원에 관여하는 사용자에게 매우 유용한 책입니다. 이 책은 웹 서비스 및 웹 서비스 구성 요소 기술에 대한 훌륭한 보안 참조 가이드이며 조직의 인프라 및 실제 개발 과정에서 웹 서비스와 그 구성 요소를 보호하는 여러 가지 방법을 자세하게 설명합니다.
웹 서비스에 대한 심도 있는 소개를 시작으로 "The Consequences of Procrastination"이라는 제목의 사례 연구를 통해 사전 대비식 보안 절차의 이점과 사후 대응식 시스템의 단점을 설명합니다. "Web Services Scanning and Enumeration" 장에서는 Net-Square(net-square.com/wschess/index.shtml)에서 제공하는 .NET 기반 웹 서비스 보안 도구 키트인 wsChess를 사용하여 웹 서비스를 개괄적으로 파악하고 적용 범위를 설정하는 방법을 설명합니다.
이 책에는 예제 .NET 기반 응용 프로그램인 SOAPWall이 들어 있는 유틸리티 CD도 함께 제공됩니다. 이 응용 프로그램은 .NET 웹 서비스에서 주입 문자와 버퍼 오버플로를 차단하는 방법을 보여 줍니다. 또한 이 CD에는 다양한 웹 서비스 공격 유형을 보여 주는 데모도 들어 있습니다.
가격: $49.95.

Toolbox 칼럼에 대한 의견 보내기
이 칼럼에서 다루기를 희망하는 도구나 유틸리티가 있으시면 tntools@microsoft.com으로 연락하십시오.

이 기사에 언급된 의견은 전적으로 저자의 개인적인 의견이며 항상 Microsoft의 의견을 반영하지는 않습니다. 모든 가격은 기사를 게시한 시점에 확인한 것이며 변경될 수 있습니다.

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


 Utility Spotlight: Internet Explorer Administration Kit
Utility Spotlight
Internet Explorer Administration Kit
Lance Whitney
이 기사의 코드 다운로드: Utility Spotlight: Internet Explorer Administration Kit 7 (KB)

CIO에게 회사 전체에 최신 버전인 Internet Explorer 7을 설치하라는 지시를 받았다고 가정해 봅시다. 기한이 촉박할 뿐 아니라 예산도 빠듯하고 요구 사항도 많습니다. 이 경우 모든 사용자에게 동일한 기능과 설정을 적용하는 사용자 지정 패키지가 필요합니다. 또한 필요할 때마다 설정을 변경할 수도 있어야 합니다.
뿐만 아니라 사용자가 설정을 변경할 수 없도록 Internet Explorer®를 잠그는 기능도 필요합니다. 어떻게 하면 이러한 상황에서 Internet Explorer 설치 패키지를 빠르고 쉽게 만들어 제공할 수 있을까요?
Microsoft는 여러분의 이러한 고민을 덜어주기 위해 IEAK라는 Internet Explorer Administration Kit를 내놓았습니다. 이 무료 구성 도구는 IT 관리자, 개발자, ISP 및 기타 관계자들이 보다 쉽게 Internet Explorer용 사용자 지정 설치 패키지를 만들 수 있도록 지원하기 위해 개발되었습니다. 실제로 Yahoo!에서는 IEAK 7 베타 버전을 사용하여 Yahoo! 웹 사이트에서 다운로드할 수 있는 사용자 지정 Internet Explorer 7 패키지를 만들었습니다.
IEAK를 이용하여 만든 Internet Explorer 7 빌드에는 사용자가 지정한 기능과 옵션만 포함되어야 합니다. 특정 보안 설정을 사용하면 다른 사용자가 액세스해서는 안 되는 컨트롤을 모두 잠글 수 있습니다.
물론 Active Directory®를 사용하는 경우에는 Internet Explorer를 배포한 후에 그룹 정책을 사용하여 브라우저 설정을 제어하고 업데이트할 수 있습니다. 그렇지 않은 경우 IEAK를 사용하여 다양한 Internet Explorer 설정을 관리할 수 있습니다.
IEAK 7은 이전 버전에 비해 더욱 사용자에게 친숙하도록 설계되었으므로 간단한 그래픽 인터페이스를 통해 Internet Explorer 패키지를 만들 수 있습니다. 단계별 화면을 통해 빌드에 추가할 기능과 옵션을 선택할 수 있습니다.
IEAK의 새 릴리스에서는 일부 옵션이 추가되거나 제거되어 이전 버전과는 다른 몇 가지 기능을 제공합니다. 이제 Internet Explorer 빌드에 기본 RSS 웹 피드를 추가하고 하나 이상의 홈 페이지 및 검색 페이지를 지정할 수 있으며 피싱 필터 지원 기능을 추가할 수 있습니다. 또한 Microsoft® Windows® 악성 소프트웨어 제거 도구를 실행하고 업데이트하도록 설정할 수 있습니다. 그러나 Outlook® Express와 Windows Media® Player는 더 이상 Internet Explorer 7에 포함되지 않으므로 IEAK를 사용하여 이러한 응용 프로그램을 사용자 지정할 수 없습니다.
32비트 또는 64비트 플랫폼 기반의 Windows XP 서비스 팩 2(SP2), Windows Server® 2003 SP1, Windows Vista™(x86, x64 또는 Itanium 기반)용 Internet Explorer 패키지를 만들 수 있습니다. IEAK 7을 실행하려면 패키지를 만들 때 사용할 PC에 Internet Explorer 7이 설치되어 있어야 합니다. 호환성을 유지하려면 빌드를 적용할 컴퓨터와 동일한 OS가 설치된 컴퓨터에서 IEAK를 실행해야 합니다.
이 칼럼에서는 IEAK를 사용하여 Internet Explorer 7 설치 빌드를 만들고 브라우저 설정을 유지 관리 및 업데이트하는 방법에 대해 설명합니다.

IEAK 7을 구하는 방법
microsoft.com/technet/prodtechnol/ie/ieak7(영문)에서 최신 버전인 IEAK 7을 무료로 다운로드할 수 있습니다. 또한 이 페이지에서는 읽어 볼 가치가 있는 IEAK 설명서 및 릴리스 정보도 제공합니다.
다운로드한 ieak.msi 파일을 사용하여 IEAK 7을 설치할 때 역할(ISP, 콘텐츠 공급자, 개발자)에 따라 또는 회사 인트라넷을 통해 사용할 라이선스 유형을 묻는 메시지가 표시됩니다. 표시되는 화면과 구축할 패키지 유형은 선택한 역할에 따라 다릅니다. 따라서 비즈니스 환경에 사용할 빌드를 만드는 경우 회사 인트라넷에 맞는 역할과 라이선스를 선택해야 합니다. IEAK가 설치되면 IEAK 도움말, IEAK 프로필 관리자, Internet Explorer 사용자 지정 마법사가 포함되어 있는 Microsoft IEAK 7이라는 프로그램 그룹이 시작 메뉴에 만들어집니다.
Internet Explorer 사용자 지정 마법사를 사용하여 설치 패키지를 만듭니다. 이 마법사는 각각의 화면을 통해 패키지 설계 과정을 안내하므로 사용 방법이 간단합니다. 그렇다면 주의할 점은 무엇일까요? 각각의 옵션을 구성하는 방법을 알려면 Internet Explorer의 기능 및 컨트롤을 명확하게 이해하고 있어야 합니다. 다행히 IEAK 7은 이러한 부분에 대한 지원도 제공합니다. 도구에서 기본 제공하는 도움말에는 이전 버전보다 훨씬 자세한 설명이 나와 있습니다. 사용자 지정 마법사의 각 화면에는 화면의 설정과 옵션을 설명하는 도움말 단추가 표시됩니다. 전체 IEAK 도움말 파일은 IEAK 도움말 바로 가기 또는 C:\Program Files\Microsoft IEAK 7의 IEAKHelp.chm 파일을 통해 액세스할 수 있습니다. 빌드를 만들기 전에 각 구성 요소를 이해하고 필요한 옵션을 계획할 수 있도록 설명서를 읽어 보는 것이 좋습니다.
사용자 지정 마법사는 패키지 작성을 다음과 같은 5가지 단계로 분류합니다.
  1. 정보 수집
  2. 설치 매개 변수 지정
  3. 설치 환경 사용자 지정
  4. 브라우저 사용자 지정
  5. 추가 사용자 지정
Microsoft에서는 IEAK 7에서 사용자가 거쳐야 할 화면 수를 줄였으므로 프로세스가 이전 버전보다 훨씬 간단해졌습니다. 그러나 사용자 지정 마법사에서는 아직도 다수의 화면을 통해 패키지 옵션을 선택해야 합니다. 대부분의 화면이 금방 이해할 수 있을 만큼 명확하고, 복잡한 화면이 나타날 경우 도움말에 액세스하는 방법도 이미 설명했으므로 이 칼럼에서는 모든 화면을 일일이 다루지 않겠습니다. 그 대신, 각 단계에서 이루어지는 작업에 대해 간단히 설명하고 중요한 몇 가지 화면에 대해 살펴보겠습니다.
1단계 정보 수집. 여기서는 설치 패키지 저장 위치, 실행할 OS 및 플랫폼, Internet Explorer 배포 방식, 사용자 지정할 옵션을 결정합니다. 이 단계에서는 그림 1에 표시된 세 가지 Internet Explorer 7 배포 방법 중 하나를 지정할 수 있습니다. 이 세 가지 방법이란 빌드를 구성하는 파일이 포함된 플랫 디렉터리 구조를 생성하는 파일 설치, 설치 디스크를 생성하는 CD-ROM(원격 사용자를 지원할 경우 유용), 기존에 설치한 Internet Explorer 7에 사용자 지정 설정을 적용하는 구성 전용 또는 브랜딩 전용 패키지를 말합니다. Internet Explorer 7이 이미 설치되어 있고 직접 사용자 지정을 적용하려는 경우 마지막에 설명한 옵션을 Windows Vista에 사용할 수 있습니다.
그림 1 배포 방법 지정
그림 1 배포 방법 지정 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 배포 방법 지정
그림 1 배포 방법 지정 (더 크게 보려면 이미지를 클릭하십시오.)
또한 이 단계에서는 빌드에 사용할 언어도 지정합니다. 지원해야 하는 언어마다 지역화된 Internet Explorer 7 버전을 만들 수 있습니다.
2단계 설치 매개 변수 지정. 여기서는 Internet Explorer 업데이트 및 최신 구성 요소를 다운로드하여 패키지를 만듭니다.
3단계 설치 환경 사용자 지정. 이 단계에서는 사용자에게 제공할 설치 옵션을 선택합니다. 즉, 대화형 설치(설치 도중 사용자에게 옵션 제공), 자동 설치(사용자가 설치 과정을 볼 수 있으나 조작할 수는 없음), 전자동 설치(사용자 개입 없이 설치가 백그라운드에서 완벽하게 실행됨) 중 한 가지를 선택합니다. CD-ROM을 만드는 경우 이 단계에서 시작 페이지와 기타 CD에 필요한 요소를 만들라는 메시지가 표시됩니다.
4단계 브라우저 사용자 지정. 여기서는 Internet Explorer 모양 사용자 지정, 홈 페이지, 지원 페이지 및 즐겨찾기 URL 설정, 프록시 설정 구성, 개인 정보 보호 내용 구성 및 브라우저 보안 설정 작업을 수행합니다. 또한 이 단계에서는 자동 구성 파일 또는 그룹 정책 사용 계획이 없을 경우 브라우저 설정을 관리할 수 있는 인터넷 설정(INS) 파일의 이름과 위치를 지정할 수 있습니다.
INS 파일은 홈 페이지에서 즐겨찾기, 보안 옵션, 프록시 구성에 이르는 중요한 브라우저 설정이 들어 있는 간단한 텍스트 파일입니다. 이 INS 파일을 내부 웹 서버에 저장합니다. 그러면 각 PC에서 이 파일을 검색하여 브라우저 설정을 가져옵니다. 이후 설정을 수정해야 할 경우 INS 파일만 편집하면 변경 사항이 자동으로 사용자에게 전송됩니다. 여기서는 설정이 업데이트 및 적용되는 빈도를 지정할 수 있습니다.
이 단계에서는 IP 주소와 포트 번호를 수동으로 입력하거나 JScript®(JS), JavaScript(JVS) 또는 프록시 정보가 포함된 PAC(프록시 자동 구성) 파일을 만들고 이름을 지정하여 프록시 서버를 구성할 수도 있습니다. IEAK 도움말에서는 이러한 파일을 만드는 데 사용할 수 있는 코드 예를 제공합니다.
또한 Windows Vista 내에서나 Windows Vista용으로 Internet Explorer 7 패키지를 설계하는 경우 보호 모드를 사용할 수 있습니다. 참조 PC에서 Internet Explorer 7의 보호 모드를 켠 다음 IEAK로 설정을 가져오기만 하면 됩니다.
5단계 추가 사용자 지정. 마지막으로 이 단계에서는 빌드에 적용할 사용자 정책 및 보안 제한을 설정합니다. 사용자가 보거나 수정하지 못하도록 원하는 개별 설정만 선택하여 잠글 수 있습니다. 그림 2는 다섯 가지 범주의 컨트롤을 활성화 또는 비활성화할 수 있는 추가 설정 화면입니다. 이러한 화면의 설정은 Internet Explorer 7에 사용할 수 있는 다섯 가지 ADM 템플릿에서 가져온 것으로, ADM 템플릿은 마법사의 2단계에서 최신 브라우저 구성 요소를 다운로드하면 설치됩니다. 그룹 정책을 사용하는 경우에는 이 단계를 건너뛸 수 있습니다. 그렇지 않은 경우 다섯 가지 범주의 옵션을 구성합니다. 이러한 범주는 ADM 템플릿에서 직접 가져오기 때문에 텍스트 편집기에서 각 ADM 파일을 편집하여 사용자 지정 컨트롤을 직접 추가하는 방식으로 템플릿을 수정할 수도 있습니다. ADM 파일은 C:\Program Files\Microsoft IEAK 7\pol-icies에서 각 Windows 운영 체제 및 플랫폼마다 다른 하위 디렉터리 아래에 있습니다. 그림 3에는 다섯 가지 범주와 각 범주에 대한 간략한 설명이 나와 있습니다.
Figure 3 추가 설정 화면의 범주 (Close Figure 3)

범주 | 설명
컨트롤 관리 | 이 범주에서는 특정 ActiveX 컨트롤을 활성화하거나 비활성화할 수 있습니다. 이 범주의 설정은 Windows Vista에는 적용되지 않고 Windows XP 및 Windows Server 2003에만 적용됩니다.
사용자 지정 설정 | 이 범주에서는 보안 설정을 표시합니다. 특정 컨트롤 및 작업을 영역(인터넷, 인트라넷, 신뢰할 수 있는 사이트 또는 제한된 사이트)별로 활성화하거나 비활성화할 수 있습니다.
회사 설정 | 이 범주에서는 브라우저 캐시의 크기와 매개 변수를 설정할 수 있습니다.
회사 제한 | 여기서는 사용자가 볼 수 없도록 Internet Explorer의 특정 컨트롤 및 화면을 잠글 수 있습니다. 이러한 설정은 Windows Vista에는 적용되지 않고 Windows XP 및 Windows Server 2003에만 적용됩니다.
인터넷 설정 | 이 범주에서는 자동 완성, 표시 크기, Internet Explorer의 인터넷 옵션 메뉴에 표시되는 고급 설정 옵션을 제공합니다.
그림 2 Internet Explorer 기능 사용자 지정
그림 2 Internet Explorer 기능 사용자 지정 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 Internet Explorer 기능 사용자 지정
그림 2 Internet Explorer 기능 사용자 지정 (더 크게 보려면 이미지를 클릭하십시오.)

빌드 확인
사용자 지정 마법사의 단계를 모두 완료하면 1단계에서 지정한 위치 또는 기본 위치 c:\builds에 패키지가 만들어집니다. 이 디렉터리 아래에 대상 디렉터리가 생성됩니다. IEAK는 이 디렉터리 이름으로 현재 날짜를 사용합니다(예: 2007년 1월 1일인 경우 01012007). 그 아래에는 INS라는 하위 디렉터리 경로와 선택한 배포 방법(FLAT, CD 또는 BrndOnly)의 이름을 딴 하위 디렉터리 경로가 생성됩니다.
INS 디렉터리는 패키지를 구축할 때 사용자 지정한 내용을 추적하는 작업 영역 또는 리포지토리의 역할을 합니다. 이 디렉터리에 있는 install.ins라는 텍스트 파일에 사용자가 만든 설정이 모두 저장됩니다. 사용자 지정 마법사를 다시 시작하면 이전에 선택한 내용이 자동으로 이 파일에서 선택됩니다.
FLAT, CD 또는 BrndOnly 디렉터리에는 실제 설치 파일이 저장됩니다. 이 세 위치 중 하나에 OS 및 플랫폼 이름이 붙은 하위 디렉터리가 생성됩니다(예: 32비트 Windows XP 또는 Windows Vista의 경우 WIN32). 마지막 하위 디렉터리의 이름은 패키지에 사용된 언어로 지정됩니다(예: 영어의 경우 EN). 예를 들어 2007년 1월 1일에 32비트 Windows에 Flat 배포를 사용하여 영어로 빌드를 만들었다면 빌드의 디렉터리 경로는 c:\builds\01012007\FLAT\WIN32\EN이 됩니다.
Flat 배포 방법으로 만든 설치 파일을 찾으려면 언어 하위 디렉터리에서 IE7Setup.exe 파일이 나타날 때까지 FLAT 디렉터리 구조를 드릴다운합니다. 이 파일은 빌드를 구성하는 모든 바이너리 및 구성 파일이 포함되어 있는 자동 압축 풀기 실행 파일입니다. 이 파일만 있으면 Internet Explorer 7 패키지를 배포할 수 있습니다(INS 디렉터리에 있는 파일은 설치에 필요하지 않음). 이 파일을 배포 서버에 복사하여 패키지를 테스트한 후 준비가 되면 사용자에게 배포할 수 있습니다.
CD-ROM 배포를 선택한 경우 CD 디렉터리의 모든 항목을 CD에 복사해야 합니다. 자동으로 생성되는 autorun.inf 파일과 CD에서 Internet Explorer를 설치하는 실행 파일이 포함된 디렉터리도 복사해야 합니다.
구성 전용 또는 브랜딩 전용 패키지를 만든 경우 언어 하위 디렉터리에서 Setup.exe 파일을 찾을 때까지 BrndOnly 디렉터리 구조를 드릴다운합니다. 이 파일은 배포 시 배포 서버에 복사할 수 있는 자동 압축 풀기 실행 파일입니다.

설정 관리
Internet Explorer 7 패키지에는 필요한 모든 기능과 설정이 처음부터 포함되어 있습니다. 그렇다면 옵션을 변경해야 할 경우에는 어떻게 해야 할까요? 두 가지 방법이 있습니다. Active Directory를 사용하는 경우 그룹 정책을 사용하여 브라우저 설정을 업데이트할 수 있습니다. 그렇지 않은 경우 IEAK에서 제공하는 Profile Manager라는 도구를 사용하여 설정을 수정할 수 있습니다. 먼저 그룹 정책에 대해서 간략하게 살펴보겠습니다.
그룹 정책 사용. 그룹 정책은 모든 브라우저 설정을 지원하므로 Internet Explorer 관리에 가장 적합한 방법입니다. 이전 버전의 IEAK 및 Internet Explorer에서는 그룹 정책 콘솔에 ADM 파일 및 IEM(Internet Explorer 유지 관리) 파일을 추가하여 모든 Internet Explorer 설정을 통합해야 했습니다. 그러나 Internet Explorer 7의 경우 Windows XP SP2와 Windows Vista에 브라우저 유지 관리 및 업데이트에 필요한 모든 그룹 정책 설정이 포함되어 있습니다.
그룹 정책 편집기(gpedit.msc)를 열면 관리 템플릿 | Windows 구성 요소 | Internet Explorer 아래에 Internet Explorer 7에 필요한 모든 설정이 있습니다.
IEAK Profile Manager 사용. IEAK Profile Manager로 autoconfiguration 또는 INS 파일을 구성하고 만들어 Internet Explorer 7 설정을 저장할 수 있습니다. Profile Manager를 처음 사용할 경우 새 INS 파일을 로드하거나 만들어야 합니다. 사용자 지정 마법사에서 구성한 설정과 동일한 설정을 사용하여 INS 파일을 처음부터 새로 만들 수 있습니다. 그러나 굳이 작업을 반복할 필요가 있을까요? 패키지를 만들 때 IEAK에서는 브라우저 설정을 저장하기 위해 기본 install.ins 파일을 만듭니다. 따라서 Profile Manager에서 새 INS 파일을 만들지 말고 이 install.ins 파일을 사용하십시오. 이 파일을 로드하려면 빌드 디렉터리에서 INS 경로를 찾습니다(예: c:\builds\01012007\IN). 그런 다음 install.ins 파일을 찾을 때까지 나머지 하위 디렉터리를 드릴다운합니다.
Profile Manager에서는 그림 4와 같이 설정이 두 가지 섹션으로 구성되어 있습니다. 마법사 설정에는 홈 페이지, 프록시 설정, 보안 영역과 같은 브라우저 옵션이 포함됩니다. 이는 사용자 지정 마법사의 3-5단계 설정에 해당합니다. 사용자 제한을 제어하는 정책 및 제한 섹션은 사용자 지정 마법사의 5단계에 나타나는 다섯 가지 정책 및 제한 범주에 포함된 설정에 해당합니다.
그림 4 Profile Manager를 이용한 Internet Explorer 구성
그림 4 Profile Manager를 이용한 Internet Explorer 구성 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 Profile Manager를 이용한 Internet Explorer 구성
그림 4 Profile Manager를 이용한 Internet Explorer 구성 (더 크게 보려면 이미지를 클릭하십시오.)
이러한 설정은 패키지를 만들 때 이미 정의했으므로 수정하지 않아도 됩니다. 그러나 여기서 패키지를 만들 때 선택한 모든 설정이 정확한지 검토하는 것이 좋습니다.
Profile Manager 설정을 모두 확인했으면 install.ins 파일을 원하는 위치에 저장한 다음 내부 웹 서버에 복사합니다. 그러려면 서버의 UNC(Universal Naming Convention) 경로를 입력해야 합니다. 이때 사용자 지정 마법사 4단계의 자동 구성 화면에서 지정한 경로와 동일한 경로를 입력합니다. 또한 그림 5와 같이 INS 파일과 함께 CAB 파일을 저장하라는 메시지가 표시됩니다. 이는 Profile Manager를 사용하여 Internet Explorer 7 설정을 수정할 경우 레지스트리 항목을 Windows 클라이언트에 다운로드해야 하는 경우가 종종 있기 때문입니다. 이러한 항목은 INF 파일에 저장되고, INF 파일은 CAB 파일에 저장됩니다. 새로운 수정 작업으로 인해 INS 파일의 버전 번호가 변경되면 새로 다운로드할 수 있는 CAB 파일이 생성됩니다. 웹 서버에서 INS 파일이 있는 동일한 위치에 CAB 파일을 저장합니다.
그림 5 자동 구성 파일 저장
그림 5 자동 구성 파일 저장 (더 작게 보려면 이미지를 클릭하십시오.)
그림 5 자동 구성 파일 저장
그림 5 자동 구성 파일 저장 (더 크게 보려면 이미지를 클릭하십시오.)
그런 다음 INS 파일과 CAB 파일의 복사본을 만들어 웹 서버의 각기 다른 위치에 저장하는 것이 좋습니다. 이는 백업 복사본과 테스트 복사본을 만드는 것과 비슷합니다. 이후 Profile Manager를 사용하여 Internet Explorer 설정을 수정할 경우 테스트 INS 파일을 로드하여 수정하면 실제 INS 파일을 수정하기 전에 변경 사항을 테스트해 볼 수 있습니다.
Profile Manager를 통해 브라우저 설정이나 컨트롤을 변경하는 작업은 간단합니다. 적절한 범주만 선택하면 해당 옵션을 활성화하거나 비활성화할 수 있습니다. 변경 작업을 완료한 후에는 INS 파일을 다시 저장하고 복사본을 다시 서버에 복사합니다.
권장 사항: INS 파일은 간단한 텍스트 파일입니다. 따라서 메모장에서 열어 설정을 볼 수 있습니다. 메모장에서 INS 파일을 편집할 수도 있습니까? 물론, 가능하며 편집한 설정은 적용됩니다. 그러나 Profile Manager를 사용하여 INS 파일을 수정하면 두 가지 이점을 얻을 수 있습니다. 즉, Profile Manager는 CAB 파일이 필요한 경우 자동으로 생성할 뿐 아니라 INS 파일을 수정할 때마다 새 버전 번호를 기록합니다. 그러므로 항상 Profile Manager를 사용하여 INS 파일을 수정하는 것이 좋습니다.

결론
IEAK는 Internet Explorer 7 빌드를 신속하고 효율적으로 만들고 사용자 지정할 수 있는 유용한 도구입니다. IEAK 7 최신 버전은 이전 버전에 비해 설치 패키지 설계에 사용할 수 있는 여러 가지 향상된 기능(보다 간단한 화면, 유용한 도움말)을 제공합니다. IEAK의 사용법을 이해하고 사용한다면 사용자에게 안정적인 Internet Explorer 7 설치를 제공할 뿐만 아니라 CIO에게도 만족을 줄 수 있을 것입니다.
Internet Explorer 7 자동 배포
Microsoft에서는 Internet Explorer 7 최종 버전이 출시된 후 바로 자동 업데이트와 Windows Update 및 Microsoft Update 사이트를 통해 Internet Explorer 7을 가장 높은 우선 순위 업데이트로 배포하기로 계획했습니다. 하지만 이러한 계획이 관리자에게는 환경에 따라 문제가 될 수도 있습니다. 로컬 관리자 권한이 없는 사용자는 이 업데이트를 받을 수 없습니다. 또한 Microsoft Systems Management Server(SMS) 또는 Windows Server Update Services(WSUS)로 환경을 관리하는 경우에는 관리자에게 사용자가 받는 업데이트를 제어할 수 있는 권한이 이미 부여되어 있지만 일부 사용자 또는 모든 사용자에게 로컬 관리지 권한이 있고 업데이트를 관리할 시스템이 없는 경우에는 Internet Explorer 7 업데이트를 차단해야 할 수 있습니다. 이를 위해 Microsoft에서는 Internet Explorer 7 Blocker Toolkit을 제공하고 있습니다. 이 도구 키트(Microsoft 다운로드 센터(영문)에서 제공)에는 Internet Explorer 7 업데이트 실행을 차단하도록 레지스트리 키를 설정하는 스크립트와 그룹 정책 템플릿이 포함되어 있습니다.

Lance Whitney는 IT 컨설턴트 겸 강사이자 테크니컬 라이터입니다. 또한 Internet Explorer 4.0 이후 버전들에 대한 설치 패키지를 만들고 지원해 오고 있습니다. 원래 저널리스트였던 Lance는 약 15년 전 IT 업계에 무작정 뛰어들었습니다.


 SQL Q+A: 데이터 보관, 연결된 서버, 대역폭 측정 및 기타 정보
SQL Q+A
데이터 보관, 연결된 서버, 대역폭 측정 및 기타 정보
편집자: Nancy Michell

데이터 보관
Q: 그룹에서 사용할 완벽한 데이터 보관 전략이 필요합니다. 현재는 데이터를 백업한 다음 유틸리티를 실행하여 기록 데이터를 삭제하는 표준 모델 기반의 방법을 사용하고 있습니다. 삭제된 데이터를 검색해야 하는 경우 해당 환경과 데이터베이스가 복원됩니다.
단계별로 수행할 수 있는 보관 솔루션을 찾고 있습니다. 1단계에서는 데이터가 데이터베이스에서 삭제되기는 하지만 실시간으로 해당 데이터에 액세스할 수 있어야 합니다. 즉, 프로덕션 데이터베이스의 크기를 관리하기 쉽도록 유지하기 위해 데이터를 제거하기는 하지만 최종 사용자는 계속 데이터에 액세스할 수 있어야 합니다. 2단계에서는 데이터가 완전히 제거되고 해당 데이터에 액세스하려면 먼저 복원 작업을 수행해야 합니다. 이렇게 하려면 어떻게 해야 합니까?
A: 가장 간단한 방법은 데이터베이스의 보관 복사본을 복원한 다음 응용 프로그램을 수정하여 용량이 줄어든 새 데이터베이스에 액세스하거나 사용자가 원하는 경우 용량이 줄어들지 않은 기존 데이터베이스에 액세스하는 것입니다. 결과적으로 각각의 제거 기간 동안에는 데이터베이스 복사본을 유지하게 됩니다.
데이터 변경이 느리게 진행되고 제거 간격 사이에 대부분의 데이터가 변경되지 않는 경우에는 중복되거나 낭비되는 공간이 많아질 수 있습니다. 한편 데이터 액세스가 자주 발생하지 않기 때문에 보관된 데이터를 여러 개의 빠르고 비싼 소용량 드라이브 대신 소수의 느리고 저렴한 대용량 드라이브에 저장할 수도 있습니다. 각 기간 동안에 데이터가 완전히 새로 고쳐지는 경우 이 방법이 적합할 것입니다. 이 프로세스는 관리하기가 매우 쉬우며 대체로 안전합니다.
또한 기존 데이터베이스의 용량을 줄이기 전에 지정 시간 복제본을 만드는 방법을 제공하는 데이터베이스 스냅숏을 사용할 수 있는지 알아 보십시오. 스냅숏이 일부 시나리오에서 잘 작동하기는 하지만 여러 가지 고려할 점이 있습니다. 데이터베이스 스냅숏은 "기록 중 복사"이며 원래 데이터베이스와 스냅숏이 만들어진 지정 시간 사이에 변경된 내용을 지속적으로 유지 관리합니다. 원래 데이터베이스의 변경 내용이 많으면 스냅숏 용량이 매우 커질 수 있습니다.
어떤 의미에서 데이터베이스 스냅숏은 백업 및 복원과 반대됩니다. 데이터베이스 스냅숏은 변경 내용만을 저장하기 때문에 변경이 많지 않을 것으로 예상될 경우에 적합한 반면, 백업 및 복원은 변경이 많을 것으로 예상되는 경우에 더 적합합니다. 이 경우 "기록 중 복사" 공간 절약의 이점은 사라지고 스냅숏 관리의 어려움만 지속됩니다.
또는 테이블 분할(영문)을 사용할 수도 있습니다. 테이블 분할을 사용하면 특정 테이블에서 키 값 범위를 다른 파티션에 속한 것으로 지정한 다음 해당 파티션을 다른 파일 그룹에 배치할 수 있습니다. 한 테이블 내에서 어느 데이터가 어느 파일 그룹으로 이동하게 되는지를 제어하게 되면 관련 비용을 효과적으로 관리할 수 있습니다. 어느 파일 그룹을 어떤 물리적 드라이브에 저장할 것인지(저가 및 고가 드라이브를 비교한 앞의 설명 참조), 그리고 어느 파일 그룹을 얼마나 자주 백업해야 하는지 등을 선택할 수 있습니다. 이러한 파일 그룹을 읽기 전용으로 설정하면 부분 백업을 사용할 수도 있습니다.

데이터베이스 개수
Q: 약 5,000곳의 고객업체에 서비스를 제공할 응용 프로그램을 구현하여 호스팅할 계획입니다. 기밀 유지를 위해 고객별로 하나의 데이터베이스를 구현하고 싶습니다. 서버에 1개 또는 5,000개의 데이터베이스가 있다면 어느 경우에 지정된 데이터 및 인덱스 크기, 사용자 연결 수 및 작업 부하에 대해 서버 리소스가 비효율적으로 사용됩니까?
A: 직원의 수와 관계없이 데이터베이스 간에 동일한 코드 베이스를 유지하기는 어렵습니다. 데이터베이스 코드에서 버그 하나를 수정한다면 수정한 내용을 5,000번 롤아웃해야 합니다. 또한 데이터베이스 복구 시간이 매우 길어질 뿐만 아니라 백업 및 데이터베이스 일관성 검사와 같은 작업의 수행 시간도 길어집니다. 이렇게 한번 생각해 봅시다. 당좌 예금 계좌를 갖고 있는 고객별로 개별 데이터베이스를 호스팅하는 은행이 있습니까?
SQL Server™에서는 원하는 만큼 데이터베이스를 만들 수 있지만 이 방법이 항상 최선의 선택은 아닙니다. 동일한 기간 동안 각 데이터베이스에서 하나의 트랜잭션을 수행해야 하는 작업이 있고, 각 데이터베이스별로 자체 트랜잭션 로그가 있는 경우를 생각해 봅시다. 모두 알다시피 OLTP(Online Transaction Processing) 성능을 결정하는 요소 중 하나는 트랜잭션 로그를 기본 디스크에 순차 쓰기할 수 있는 환경을 유지하는 것입니다. 이러한 데이터베이스에서 읽기 작업보다는 트랜잭션을 수행하려는 경우에는 이 방법을 사용하지 마십시오.

연결된 서버 쿼리
Q: SQL Server 2005 서비스 팩 1(SP1)에서 데이터 웨어하우스를 개발하고 있습니다. 원본 서버는 파트너의 도메인에 있고 대상 서버는 우리 도메인에 있습니다. 연결된 서버를 통해 원본 서버에 있는 레코드를 인출하고 있습니다. 원본 테이블 간의 조인을 사용하여 원본에서 쿼리를 실행하면 쿼리가 매우 빠르게 실행됩니다. 그러나 대상 테이블과의 간단한 조인만 있더라도 쿼리의 실행 속도가 심각하게 느려집니다. 왜일까요?
A: 서버 간 조인은 사용하지 않는 것이 가장 좋은 방법입니다. 특히 도메인이 다른 경우에는 더욱 그렇습니다. 즉, 파트너는 귀사의 도메인을 신뢰하는데 귀사에서는 파트너의 도메인을 신뢰하지 않기 때문에 특정 결과에 따라 이 문제가 발생할 수 있습니다. 쿼리를 리팩터링한 후 원본에서 실행한 다음 결과를 대상에 복사하십시오. 이렇게 하면 더 나은 결과를 얻을 수 있을 것입니다.

대역폭 측정
Q: 데이터베이스 미러링에 사용된 대역폭을 측정하는 가장 유용한 방법이 있습니까? 로그 생성 속도에 약 3배가 되어야 한다는 요구 사항을 이해하기는 하지만 중요한 요청이 아닌 경우 웹상의 광대역 연결을 통해 데이터베이스 미러링을 수행할 수 있습니까?
A: 원시 처리량 외에도 왕복 메시지 대기 시간(safety=full인 경우 더욱 중요함)과 링크 안정성을 고려해야 합니다. 데이터베이스 미러링은 안정적인 네트워크 연결에 최적화되어 있으므로 다시 연결해야 하는 상황에서는 상당한 양의 오버헤드가 발생할 수 있습니다. 광대역 연결이 안정적이지 않은 경우(연결이 끊어지거나 지연 시간이 긴 경우) 연결을 유지하지 못할 수 있습니다. 자세한 내용은 미러링 성능 고려 사항에 대한 백서(영문)를 참조하십시오.
SQL Server 액세스 보안
프로덕션 환경의 SQL Server에 대한 액세스 보안과 관련된 권장 사항을 찾고 계십니까? Microsoft patterns & practices Developer Center(영문)를 참조하십시오. 다음 세 가지 패턴을 주의 깊게 살펴보십시오.
  • Security Engineering Index(영문)
  • Security Guidance for Applications Index(영문)
  • Threat Modeling Web Applications(영문)

전체 운영 환경을 구성하는 방법을 자세히 알고 싶으십니까? 다음을 참조하시면 많은 도움이 될 것입니다.
  • Windows Server System Reference Architecture(영문)
  • Data Services Implementation Guide(영문)

많은 Microsoft 기술 전문가들께서 도움을 주셨습니다. Denis Altudov, Jayashree Anand, Gus Apostol, Bhavana Bartholf, Mike Blaszczak, Dibyendu Chakraverty, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Nakul Garg, Phil Hummel, Steve Lindell, Kaloian Manassiev, Al Noel, Ward Pond, Paul Randal, Remus Rusanu, Mike Shelton, Christy Sutton, Kevin Tsai, Peter Ty, Val Wittenberg, Steven Wort, Kalyan Yella와 Frankie Yuen에게 감사의 말을 전합니다.


 The Cable Guy: TCP 수신 창 자동 조정
The Cable Guy
TCP 수신 창 자동 조정
Joseph Davies

TechNet Magazine의 첫 번째 The Cable Guy 칼럼에 오신 것을 환영합니다. TechNet 웹 사이트 칼럼을 즐겨 구독하시는 분들은 이미 우리가 네트워킹과 관련된 모든 주제를 다룬다는 것을 알고 있습니다. 이 컬럼에서도 매월 이러한 내용을 다루고자 합니다. 처음 방문하셨거나 이전 칼럼을 찾아보려면 Cable Guy 사이트(영문)를 참조하십시오.
이제 첫 번째 주제인 TCP 수신 창에 대해 살펴보겠습니다.
TCP 연결의 처리량은 송신 및 수신 응용 프로그램, TCP 송신 및 수신 구현 방식, TCP 피어 간의 전송 경로에 의해 제한될 수 있습니다. 이 칼럼에서는 TCP 수신 창과 이 창이 TCP 처리량에 미치는 영향, TCP 창 배율 사용 및 수신된 데이터에 대한 TCP 처리량을 최적화하는 Windows Vista™의 새로운 수신 창 자동 조정 기능에 대해 설명합니다.

TCP 수신 창
TCP 연결에는 중요한 특징이 많이 있습니다. 첫째로, 두 응용 프로그램 계층 프로토콜 간에 논리적인 지점 간 회선이 있습니다. TCP는 일대다 전송 서비스를 제공하지 않으며 일대일 전송만 제공합니다.
둘째로, TCP 연결은 연결 지향적입니다. 데이터를 전송하기 전에 두 응용 프로그램 계층에서 TCP 연결 설정 프로세스를 통해 TCP 연결을 정식으로 협상해야 합니다. 마찬가지로 TCP 연결은 TCP 연결 종료 프로세스를 통해 협상한 후 정식으로 닫힙니다.
셋째로, TCP 연결에서는 데이터의 순서가 지정되어 안정적으로 전송되며 수신 측의 긍정적 승인을 기다립니다. 긍정적 승인이 수신되지 않으면 세그먼트가 다시 전송됩니다. 수신 측에서는 중복된 세그먼트가 제거되고 잘못된 순서로 수신된 세그먼트는 올바른 순서로 위치가 되돌려집니다.
넷째로, TCP 연결은 전이중 방식입니다. 각 TCP 피어 간의 TCP 연결은 송신 파이프와 수신 파이프라는 두 개의 논리적 파이프로 구성됩니다. TCP 헤더에는 송신 데이터의 시퀀스 번호와 수신 데이터의 승인(ACK)이 들어 있습니다.
또한 TCP에서는 송신 및 수신 논리적 파이프를 통해 전송되는 데이터를 연속적인 바이트 스트림으로 간주합니다. 각 TCP 헤더의 시퀀스 번호와 승인 번호는 바이트 단위에 따라 정의됩니다. TCP는 바이트 스트림 내의 레코드 또는 메시지 단위를 인식하지 않습니다. 응용 프로그램 계층 프로토콜에서는 수신 바이트 스트림을 올바르게 구문 분석해야 합니다.
TCP 피어는 한 번에 전송할 수 있는 데이터의 양을 제한하고 수신 측 흐름 제어를 제공하기 위해 창을 사용합니다. 이 창은 송신 측이 수신 측에 보낼 수 있도록 허용된 바이트 스트림상의 데이터 범위를 나타냅니다. 송신 측은 이 창의 범위에 맞는 바이트 스트림의 바이트만 보낼 수 있습니다. 이 창은 송신 측의 아웃바운드 바이트 스트림과 수신 측의 인바운드 바이트 스트림에 따라 이동합니다.
지정된 논리적 파이프(전이중 TCP 연결에서 한쪽 방향)에 대해 송신 측은 전송 창을 유지하고 수신 측은 수신 창을 유지합니다. 전송되는 데이터 또는 ACK 세그먼트가 없으면 논리적 파이프의 전송 및 수신 창이 일치하게 됩니다. 즉, 송신 측에서 보내도록 허용된 아웃바운드 바이트 스트림의 데이터 범위가 수신 측에서 받을 수 있는 인바운드 바이트 스트림의 데이터 범위와 일치하는 것입니다. 그림 1에서는 송신 및 수신 관계를 보여 줍니다.
그림 1 전송 및 수신 창 일치
그림 1 전송 및 수신 창 일치 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 전송 및 수신 창 일치
그림 1 전송 및 수신 창 일치 (더 크게 보려면 이미지를 클릭하십시오.)
수신 창의 크기를 지정하기 위해 TCP 헤더에는 16비트의 Window 필드가 들어 있습니다. 데이터를 받은 수신 측에서는 송신 측에 ACK를 보내 성공적으로 수신된 바이트를 알려 줍니다. 각 ACK의 Window 필드에는 수신 창에 남아 있는 바이트 수가 들어 있습니다. 응용 프로그램에서 데이터를 보내고 승인하고 검색하면 전송 및 수신 창도 오른쪽으로 이동합니다. 수신 창은 송신 측에서 수신 측으로 보낼 수 있는 승인되지 않은 데이터의 양을 제어하는 창입니다.
수신 창에는 응용 프로그램에서 아직 검색하지 않은 데이터와 수신은 되었지만 승인되지는 않은 데이터가 있을 수 있으므로 TCP 수신 창은 그림 2와 같은 구조를 갖게 됩니다.
그림 2 TCP 수신 창의 데이터 형식
그림 2 TCP 수신 창의 데이터 형식 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 TCP 수신 창의 데이터 형식
그림 2 TCP 수신 창의 데이터 형식 (더 크게 보려면 이미지를 클릭하십시오.)
최대 수신 창과 현재 수신 창 간에는 다른 점이 있습니다. 최대 수신 창은 고정된 크기입니다. 현재 수신 창은 가변 크기이며, 이 크기는 송신 측이 수신 측에 보낼 수 있도록 허용된 남은 데이터 양에 해당합니다. 현재 수신 창의 크기는 송신 측에 전송된 ACK에 들어 있는 Window 필드의 값이며, 응용 프로그램에서 수신하고 승인했지만 아직 검색하지 않은 데이터의 양을 최대 수신 창 크기에서 뺀 값과 같습니다.

TCP 수신 창 및 TCP 처리량
전송 경로에 오류가 없는 것으로 가정할 경우 TCP 처리량을 최적화하려면 송신 측에서 송신 측과 수신 측 간의 논리적 파이프를 충분히 채울 수 있을 정도의 패킷을 보내야 합니다. 논리적 파이프의 용량은 다음 수식을 통해 계산할 수 있습니다.
Capacity in bits = path bandwidth in bits per second * round-trip time (RTT) in seconds
용량은 BDP(Bandwidth-Delay Product)라고도 합니다. 파이프는 두껍거나(높은 대역폭) 얇거나(낮은 대역폭) 짧거나(낮은 RTT) 길(높은 RTT) 수 있습니다. 두껍고 긴 파이프의 경우 BDP가 가장 높습니다. BDP가 높은 전송 경로의 예로는 위성 통신 또는 대륙 간 광 섬유 링크가 구축되어 있는 기업의 WAN(Wide Area Network) 등이 있습니다.
높은 BDP 전송에 대한 송신 측 성능 향상
새로운 수신 창 자동 조정 기능은 높은 BDP 링크를 통해 향상된 데이터 수신 성능을 제공하지만 송신 측 성능의 경우에는 어떤 효과가 있을까요?
전송 TCP 피어가 네트워크를 독점하지 못하도록 설계된 기존 알고리즘은 느린 시작(Slow Start) 및 정체 회피(Congestion Avoidance)로 잘 알려져 있습니다. 이 알고리즘은 연결에서 처음 데이터를 보낼 때와 손실된 세그먼트를 복구할 때 전송 창(송신 측에서 보낼 수 있는 세그먼트 수)을 늘립니다.
느린 시작(Slow Start)은 수신된 각 승인 세그먼트(Windows XP 및 Windows Server 2003 TCP의 경우) 또는 승인된 각 세그먼트(Windows Vista 및 Windows Server "Longhorn" TCP의 경우)에 대해 하나의 전체 TCP 세그먼트만큼 전송 창을 늘립니다. 정체 회피(Congestion Avoidance)의 경우 승인된 전체 데이터 창 각각에 대해 하나의 전체 TCP 세그먼트만큼 전송 창을 늘립니다.
이 알고리즘은 BDP가 낮거나 수신 창 크기가 작을수록 잘 작동합니다. 그러나 RTT(왕복 대기 시간)이 100ms인 고속 WAN 링크로 연결된 두 서버 간에 데이터를 복제하는 경우처럼 수신 창 크기가 크고 BDP가 높은 TCP 연결에서 이 알고리즘은 연결의 대역폭을 충분히 활용할 수 있을 정도로 빠르게 전송 창을 늘리지 않습니다.
이러한 상황에서 TCP 연결 대역폭을 효율적으로 활용하기 위해 차세대 TCP/IP 스택에는 CTCP(Compound TCP)가 포함됩니다. CTCP는 수신 창 크기가 크고 BDP가 높은 연결에 대해 전송 창을 보다 적극적으로 늘립니다. CTCP는 지연 시간의 변화와 손실된 패킷을 모니터링하여 이러한 유형의 연결에 대한 처리량을 극대화하려고 시도합니다. 또한 CTCP의 동작은 다른 TCP 연결에 부정적인 영향을 주지 않습니다.
Microsoft 내부적으로 수행된 테스트에서 RTT가 50ms인 1Gbps 연결의 경우 대용량 파일 백업 시간이 거의 절반으로 단축되었습니다. BDP가 높은 연결일수록 더 나은 성능을 기대할 수 있습니다. CTCP 및 수신 창 자동 조정 기능을 함께 사용하면 링크 사용률을 높이고 BDP가 높은 연결의 성능을 크게 향상시킬 수 있습니다.
CTCP는 Windows Server "Longhorn"이 실행되는 컴퓨터의 경우 기본적으로 활성화되고 Windows Vista가 실행되는 컴퓨터의 경우 기본적으로 비활성화되어 있습니다. "netsh interface tcp set global congestionprovider=ctcp" 명령을 사용하여 CTCP를 활성화할 수 있습니다. "netsh interface tcp set global congestionprovider=none" 명령을 사용하여 CTCP를 비활성화할 수 있습니다.

TCP 헤더의 Window 필드 크기는 16비트이므로 TCP 피어는 이 필드를 사용하여 65,535바이트의 최대 수신 창 크기를 알릴 수 있습니다. 다음 수식을 사용하여 지정된 TCP 창 크기에 대한 대략적인 처리량을 계산할 수 있습니다.
Throughput = TCP maximum receive windowsize / RTT
예를 들어 65,535바이트의 수신 창을 사용할 경우 전송 경로의 실제 대역폭에 관계없이 100ms RTT 경로에서 초당 5.24메가비트의 대략적인 처리량만 얻을 수 있습니다. 오늘날과 같이 BDP가 높은 전송 경로에서는 원래 설계된 TCP 창 크기를 최대값으로 사용하더라도 처리량 병목 현상이 발생합니다.

TCP 창 배율
고속 전송 경로에 적합한 대용량 창 크기에 대해 RFC 1323(ietf.org/rfc/rfc1323.txt)에서는 수신 측이 65,535바이트 이상의 창 크기를 알릴 수 있도록 하는 창 배율을 정의합니다. TCP 창 배율 옵션에는 TCP 헤더의 16비트 Window 필드와 결합될 경우 수신 창 크기를 최대 약 1GB로 늘릴 수 있는 창 배율 인수가 있습니다. 창 배율 옵션은 연결 설정 프로세스 동안에 동기화(SYN) 세그먼트로만 전송됩니다. 양쪽 TCP 피어는 수신 창 크기에 사용할 창 배율 인수를 서로 다르게 지정할 수 있습니다. TCP 창 배율을 사용하면 송신 측에서 연결을 통해 더 많은 데이터를 보낼 수 있으므로 TCP 노드에서 BDP가 높은 몇 가지 유형의 전송 경로를 더 효율적으로 활용할 수 있게 됩니다.
수신 창 크기도 TCP 처리량에 중요하지만 최적의 TCP 처리량을 결정하는 중요한 요소는 응용 프로그램에서 수신 창에 누적된 데이터를 검색하는 속도(응용 프로그램 검색 속도)입니다. 응용 프로그램이 데이터를 검색하지 않으면 수신 창이 채우기를 시작할 수 있으므로 수신 측에서는 작아진 현재 창 크기를 알리게 됩니다. 극단적인 경우를 가정할 때 최대 수신 창이 모두 채워지면 수신 측에서는 0바이트의 창 크기를 알리게 됩니다. 이 경우 송신 측에서는 수신 창이 비워질 때까지 데이터 전송을 중단해야 합니다. 따라서 TCP 처리량을 최적화하려면 연결의 전송 경로 BDP와 응용 프로그램 검색 속도가 반영된 값을 연결에 대한 TCP 수신 창의 크기로 설정해야 합니다.
BDP와 응용 프로그램 검색 속도를 올바르게 결정한 경우라도 이 값은 시간이 지남에 따라 변경될 수 있습니다. BDP 속도는 전송 경로의 정체에 따라 달라질 수 있으며 응용 프로그램 검색 속도는 응용 프로그램에서 데이터를 받고 있는 연결의 수에 따라 달라질 수 있습니다.

Windows XP의 수신 창
Windows XP(및 Windows Server® 2003) TCP/IP 스택의 최대 수신 창 크기에는 중요한 특성이 많이 있습니다. 첫째로, 전송 인터페이스의 연결 속도에 따라 기본값이 결정됩니다. 실제 값은 TCP 연결 설정 중에 협상된 MSS(최대 세그먼트 크기)의 증분으로 자동 조정됩니다.
둘째로, 최대 수신 창 크기를 수동으로 구성할 수 있습니다. HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize 및 HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\InterfaceGUID\TCPWindowSize 레지스트리 값을 최대 65,535바이트(창 배율을 사용하지 않은 경우) 또는 1,073,741,823바이트(창 배율을 사용하는 경우)로 설정할 수 있습니다.
셋째로, 최대 수신 창 크기에서 창 배율을 사용할 있습니다. HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts 레지스트리 값을 1 또는 3으로 설정하여 창 배율을 사용할 수 있습니다. 기본적으로 창 배율은 수신된 SYN 세그먼트에 창 배율 옵션이 들어 있는 연결에서만 사용됩니다.
마지막으로 연결을 시작할 때 응용 프로그램이 SO_RCVBUF Windows 소켓 옵션을 사용하여 최대 수신 창 크기를 지정할 수 있습니다. 창 배율의 경우 응용 프로그램에서는 창 크기를 65,535바이트 이상으로 지정해야 합니다.
Windows XP에서는 창 배율 기능을 지원하지만 최대 수신 창 크기는 응용 프로그램에서 지정하지 않는 한 모든 TCP 연결에 대해 최대 크기로 고정되므로 처리량이 제한될 수 있습니다. 이 경우 일부 연결의 처리량은 높아지고 다른 연결의 처리량은 낮아지는 현상이 발생할 수 있습니다. 또한 TCP 연결에 대한 고정된 최대 수신 창 크기는 응용 프로그램 검색 속도나 전송 경로의 정체에 따라 바뀌지 않습니다.

Windows Vista의 수신 창 자동 조정
특히 BDP가 높은 전송 경로의 경우 TCP 처리량을 최적화하기 위해 Windows Vista 및 Windows Server "Longhorn"의 차세대 TCP/IP 스택에서는 수신 창 자동 조정 기능을 지원합니다. 이 기능은 BDP와 응용 프로그램 검색 속도를 측정한 다음 사용 중인 전송 경로와 응용 프로그램의 조건에 맞게 창 크기를 조정하여 최적의 수신 창 크기를 결정합니다.
수신 창 자동 조정은 기본적으로 TCP 창 배율 기능을 활성화하여 최대 수신 창 크기를 16MB까지 확장합니다. 연결을 통해 데이터가 전송될 때 차세대 TCP/IP 스택은 연결을 모니터링하고 연결의 현재 BDP 및 응용 프로그램 검색 속도를 측정한 다음 수신 창 크기를 조절하여 처리량을 최적화합니다. 차세대 TCP/IP 스택에서는 더 이상 TCPWindowSize 레지스트리 값을 사용하지 않습니다.
수신 창 자동 조정 기능은 여러 가지 이점을 제공합니다. 이 기능은 각 연결에 대해 최적의 수신 창 크기를 자동으로 결정합니다. Windows XP에서는 TCPWindowSize 레지스트리 값이 모든 연결에 적용됩니다. 응용 프로그램에서 더 이상 Windows 소켓 옵션을 통해 TCP 창 크기를 지정하지 않아도 됩니다. 또한 IT 관리자는 특정 컴퓨터의 TCP 수신 창 크기를 수동으로 구성할 필요가 없습니다.
수신 창 자동 조정을 사용하는 Windows Vista 기반의 TCP 피어는 일반적으로 Windows XP 기반의 TCP 피어보다 훨씬 큰 수신 창 크기를 알립니다. 수신 창 크기가 크기 때문에 다른 TCP 피어는 TCP 정체 제어에 따라 ACK를 기다릴 필요 없이 더 많은 TCP 데이터 세그먼트를 보내서 Windows Vista 기반 TCP 피어로 연결되는 파이프를 채울 수 있습니다. 웹 페이지나 전자 메일과 같은 일반적인 클라이언트 기반 네트워킹 트래픽의 경우 웹 서버나 전자 메일 서버에서 클라이언트 컴퓨터에 더 많은 TCP 데이터를 더욱 빠르게 보낼 수 있으므로 결과적으로 네트워크 성능이 전반적으로 향상됩니다. 연결에 대한 BDP와 응용 프로그램 검색 속도가 높을수록 더 나은 성능을 얻을 수 있습니다.
네트워크에 미치는 영향은 일반적으로 낮게 측정되는 속도로 전송되는 TCP 데이터 패킷 스트림이 보다 빠르게 전송되기 때문에 데이터 전송 중 네트워크 사용률이 더 높아진다는 것입니다. 두껍고 긴 파이프를 통해 동일한 데이터를 전송하는 Windows XP 및 Windows Vista 기반 컴퓨터의 경우 동일한 양의 데이터가 전송됩니다. 그러나 Windows Vista 기반 클라이언트 컴퓨터의 경우 수신 창 크기가 커지고 서버에서 클라이언트로 이어지는 파이프를 채우는 서버의 성능이 향상되었기 때문에 데이터 전송 속도가 더 빨라집니다.
수신 창 자동 조정은 BDP가 높은 전송 경로의 네트워크 사용률을 높이기 때문에 최대 용량을 거의 모두 사용하는 전송 경로의 경우 서비스 품질(QoS) 또는 응용 프로그램 전송 속도 제한을 사용하는 것이 중요해질 수 있습니다. 이러한 요구를 해결하기 위해 Windows Vista는 IP 주소 또는 TCP 포트 단위로 전송된 트래픽의 제한 속도를 정의할 수 있는 그룹 정책 기반의 QoS 설정을 지원합니다. 자세한 내용은 정책 기반 QoS의 리소스(영문)를 참조하십시오.
손실률이 높은 네트워크의 TCP 처리량 향상
손실률이 높은 네트워크의 경우 잦은 시간 제한 만료와 재전송으로 인해 TCP 처리량이 급격하게 떨어질 수 있습니다. 손실률이 높은 네트워크의 예로는 IEEE 802.11, GPRS(General Packet Radio Service) 또는 UMTS(Universal Mobile Telecommunications System) 기반의 무선 네트워크 등이 있으며, 이러한 네트워크에서는 네트워크 조건, 신호 감쇠, 전자기 간섭 및 컴퓨터 위치 변경 등에 따라 패킷 손실률이 높아질 수 있습니다.
차세대 TCP/IP 스택은 손실률이 높은 환경의 처리량을 최적화하기 위해 다음 네 가지 RFC를 지원합니다.

RFC 2582: The NewReno Modification to TCP's Fast Recovery Algorithm
RFC 2001에 정의된 빠른 복구(Fast Recovery) 알고리즘은 빠른 재전송 이벤트로 인해 세그먼트가 다시 전송될 때 송신 측에서 보낼 수 있는 데이터의 양을 늘려주는 Reno 알고리즘을 기반으로 합니다. Reno 알고리즘은 단일 손실 세그먼트의 경우 제대로 작동하지만 손실 세그먼트가 많을 경우에는 잘 작동하지 않습니다. NewReno 알고리즘은 데이터 창의 여러 세그먼트가 손실되고 송신 측에서 부분 승인(일부 성공적으로 수신된 데이터만 승인)을 받은 경우 빠른 복구 동안 송신 측이 전송 속도를 높이는 방법을 변경하여 처리량을 높여 줍니다.

RFC 2883: An Extension to the Selective Acknowledgment (SACK) Option for TCP
RFC 2018에 정의된 SACK는 수신 측에서 SACK TCP 옵션을 사용하여 수신 데이터 중 불연속적인 블록을 4개까지 나타낼 수 있도록 허용합니다. RFC 2883에서는 SACK TCP 옵션의 필드를 추가로 사용하여 중복 패킷을 승인할 수 있도록 정의합니다. 이렇게 하면 송신 측에서 세그먼트 재전송이 필요 없는 경우를 파악하여 향후 불필요한 재전송을 방지할 수 있습니다. 재전송 횟수가 줄어들수록 전반적인 처리량은 향상됩니다.

RFC 3517: A Conservative Selective Acknowledgment-based Loss Recovery Algorithm for TCP
Windows Server 2003 및 Windows XP에 현재 구현되어 있는 TCP/IP에서는 대상에 도달하지 TCP 세그먼트를 확인하는 데만 SACK 정보를 사용합니다. RFC 3517에서는 중복 승인이 수신된 경우 SACK 정보를 사용하여 손실 복구를 수행하는 방법을 정의합니다. 이 방법은 연결에서 SACK가 활성화된 경우 기존의 빠른 복구 알고리즘을 대체합니다. 차세대 TCP/IP 스택에서는 여러 세그먼트가 대상에 도달하지 않은 경우 더 빠르게 복구할 수 있도록 하기 위해 연결 단위로 SACK 정보를 추적하고 들어오는 승인 및 중복 승인을 모니터링합니다.

RFC 4138: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)
TCP 세그먼트의 의사 재전송으로 인해 RTT가 갑자기 높아질 수 있습니다. 그 이유는 이전에 보낸 세그먼트의 RTO(재전송 시간 제한)가 만료되어 TCP에서 해당 세그먼트를 다시 전송하기 때문입니다. 전체 데이터 창을 보내기 전에 이와 같이 RTT가 증가하는 경우 송신 측에서는 전체 데이터 창을 다시 전송할 수 있습니다. F-RTO 알고리즘은 다음과 같은 동작을 통해 TCP 세그먼트의 의사 재전송을 방지합니다.
여러 세그먼트에 대한 RTO가 만료되면 TCP가 첫 번째 세그먼트만 다시 전송합니다. 첫 번째 승인이 수신되면 TCP가 새 세그먼트를 보내기 시작합니다(알려진 창 크기에서 허용된 경우). 다음 번 승인에서 시간 제한이 만료되었지만 다시 전송되지 않은 다른 세그먼트가 있는 것을 확인한 경우 TCP는 시간 제한이 잘못되었다고 판단하고 시간 제한이 만료된 다른 세그먼트를 재전송하지 않습니다.
결과적으로 무선 클라이언트가 한 액세스 지점에서 다른 액세스 지점으로 로밍하는 경우와 같이 RTT가 갑자기 일시적으로 증가하는 환경에서 F-RTO는 세그먼트의 불필요한 재전송을 방지하고 정상적인 전송 속도로 빠르게 돌아올 수 있습니다. SACK 기반 손실 복구 및 F-RTO는 GPRS 연결을 사용하는 연결에서 사용하는 데 가장 적합합니다.

Joseph Davies는 Microsoft의 기술 전문 저술가로 1992년부터 Windows 네트워킹을 주제로 글을 쓰거나 가르치고 있습니다. Microsoft Press에서 5권의 책을 저술한 그는 월간 TechNet Cable Guy 칼럼(영문)의 저자이기도 합니다.


 Windows PowerShell: Windows PowerShell 구문
Windows PowerShell
Windows PowerShell 구문
Don Jones

지난 달에는 스크립트를 실제로 작성하지 않고 Windows PowerShell을 직접 사용하여 관리 작업을 처리하는 몇 가지 방법에 대해 살펴보았습니다. 그러나 Windows PowerShell은 뛰어난 대화형 셸이기 때문에 강력하면서도 단순한 스크립트 언어를 사용함으로써 기능을 보다 적절히 활용하고 복잡한 작업을 자동화할 수 있습니다.
무엇보다도 먼저 Microsoft에서 다른 스크립트 언어를 정말로 필요로 하는지 생각해 보십시오. Microsoft는 로그온 스크립트 프로세서인 KiXtart와 Visual Basic® Scripting Edition(VBScript)을 제공합니다. 그럼에도 불구하고 대답은 예입니다. Microsoft에서는 다른 스크립트 언어가 정말로 필요했습니다. 지금부터 그 이유를 설명하겠습니다.
관리자가 많은 교육을 받지 않고도 사용할 수 있도록 하기 위해 Windows PowerShell™ 언어는 간단하면서도 직관적이어야 했습니다. 또한 Windows PowerShell 자체의 모든 강력한 기능을 사용자에게 제공할 수 있기 위해서는 유연성이 매우 높아야 했습니다.
Windows PowerShell은 Microsoft® .NET Framework를 기반으로 하기 때문에 스크립트 구문이 .NET 친화적이어야 했습니다. Windows PowerShell 스크립트 언어를 어셈블하기 위해 설계자는 기본적으로 매우 간단한 C#(C 샵이라고 읽으며 .NET Framework와 함께 제공되는 언어 중 하나) 구문을 선택했습니다. 왜 VBScript 형태의 구문을 고수하지 않았을까요? Windows PowerShell 스크립트 언어는 실제로 VBScript와 완전히 다르지는 않지만 C# 구문에 보다 가까운 언어입니다. PowerShell은 .NET Framework 프로그래밍을 배우는 데 일종의 디딤돌로서의 역할을 합니다. 나중에 Visual Studio®를 사용하여 C# 응용 프로그램을 작성하게 되더라도 대부분의 Windows PowerShell 스크립트 구문을 활용할 수 있습니다.
Windows PowerShell 스크립트 언어 또는 모든 스크립트 언어에서 가장 중요하게 고려되는 요소 중 하나는 바로 구문입니다. 구문이란 Windows PowerShell에서 논리 비교를 수행하여 비교 결과에 따라 각기 다른 작업을 수행하거나 하나 이상의 명령을 반복해서 수행하는 데 필요한 특별한 언어 요소입니다.

논리적으로 생각하기
논리 비교는 많은 스크립트 언어 구문의 핵심이며, Windows PowerShell의 경우에도 예외는 아닙니다. 비교는 기본적으로 두 개의 값이나 개체를 확인하여 비교 결과가 True와 False 중 어느 것인지 평가합니다. 예를 들어 "이 사용자의 암호 만료 날짜가 오늘인가?"라는 질문의 결과는 오늘이 만료 날짜이면 True이고 그렇지 않으면 False일 것입니다. 여기에서 True와 False의 첫 번째 문자를 대문자로 쓴 이유는 이 용어들이 Windows PowerShell에서 특별한 의미를 갖고 있기 때문입니다.
다음은 Windows PowerShell에서 수행할 수 있는 실제 논리 비교의 예입니다.
PS C:\> $a = 1
PS C:\> $b = 2
PS C:\> $a -eq $b
False
$a라는 변수를 만들어 값을 1로 설정했습니다. Windows PowerShell에서는 변수 이름이 항상 달러 기호로 시작하기 때문에 쉽게 알아볼 수 있습니다. =는 값을 할당하는 데 사용되기 때문에 기술적으로 대입 연산자라고 합니다. 그런 다음 두 번째 변수 $b를 만들고 2라는 값을 할당했습니다. 마지막으로 실제 논리 비교가 수행됩니다. 즉, Windows PowerShell이 -eq(같음) 연산자를 사용하여 $a와 $b의 내용을 비교합니다. PowerShell은 비교를 수행하여 두 값이 같지 않은 것을 확인한 다음 False라는 결과를 표시합니다.
Windows PowerShell 연산자는 지금까지 다른 스크립트 언어에서 보던 연산자와 조금 다를 뿐만 아니라 C#과도 다릅니다. 대부분의 언어에서는 = 연산자가 값이 같은지 검사하거나 값을 대입하는 데 사용되지만 Windows PowerShell에서는 각 함수에 대한 전용 연산자를 사용하여 혼란을 줄였습니다. 그림 1에서는 Windows PowerShell 비교 연산자와 이미 알고 있는 다른 언어(예: VBScript)의 같음 연산자를 보여 줍니다.
Figure 1 PowerShell 비교 연산자 (Close Figure 1)

연산자 | 이름 | 설명
-eq | 같음 | 값이 동일한지 테스트합니다. 다른 언어에서는 = 또는 ==를 사용하여 값이 동일한지 테스트합니다.
-ne | 같지 않음 | 값이 같지 않은지 테스트합니다. 다른 언어에서는 <> 또는 !=를 사용하여 값이 같지 않은지 테스트합니다.
-gt | 보다 큼 | 한 값이 다른 값보다 큰지 테스트합니다. 다른 언어에서는 > 문자를 사용합니다.
-lt | 보다 작음 | 한 값이 다른 값보다 작은지 테스트합니다. 다른 언어에서는 < 문자를 사용합니다.
-ge | 크거나 같음 | 한 값이 다른 값보다 크거나 같은지 테스트합니다. VBScript 및 다른 언어의 >=와 비슷합니다.
-le | 작거나 같음 | 한 값이 다른 값보다 작거나 같은지 테스트합니다. VBScript 및 다른 언어의 <=와 비슷합니다.
이러한 비교 연산자에는 또 다른 흥미로운 특징이 있습니다. 다음 비교를 살펴봅시다.
PS C:\> $a = "TechNet"
PS C:\> $b = "technet"
PS C:\> $a -eq $b
True
기본적으로 비교 연산자는 대/소문자를 구분하지 않습니다. 즉, 대문자가 포함된 TechNet이 "technet"과 같다고 인식합니다. 대부분의 관리 작업에서는 대/소문자를 구분할 필요가 없기 때문에 편리한 방법입니다. 그러나 필요한 경우에는 비교 연산자 앞에 문자 c를 추가하여 대/소문자를 구분하는 비교를 수행할 수 있습니다.
PS C:\> $a -ceq $b
False
마찬가지로 Windows PowerShell이 비교 작업에서 대/소문자를 구분하는지 여부가 혼동될 경우에는 문자 i를 앞에 추가하여 대/소문자를 구분하지 않도록 할 수 있습니다.
PS C:\> $a -ieq $b
True
논리 비교의 결과는 항상 True와 False 중 하나라는 것을 기억하십시오.

결정
지금까지 논리 비교를 작성하는 방법을 배웠으므로 이제 논리 비교를 구문에 사용할 수 있습니다. 첫 번째 구문에서는 Windows PowerShell에서 비교 결과에 따라 결정을 내리는 방법을 보여 줍니다. 이 구문에서는 If 구문이 호출되며, 여기에는 몇 가지 변형이 있습니다. 다음은 가장 간단한 예입니다.
PS C:\> if ($a -eq $b) {
>> Write-Host "They are equal"
>> }
>>
They are equal
여기에는 몇 가지 흥미로운 점이 있습니다. 먼저 변수 $a와 $b에는 "TechNet"과 "technet"이라는 값이 여전히 들어 있으며 If 키워드를 사용하여 구문을 시작했습니다. 그런 다음 수행하려는 논리 비교를 괄호 안에 입력했습니다. 괄호 뒤에 호출하게 될 조건 코드의 시작을 뜻하는 중괄호를 입력했습니다. 이 경우 조건 코드는 비교 연산에서 반환된 결과가 True일 때 실행됩니다. 앞의 예제에서 보았듯이 이 비교 연산은 True를 반환하므로 조건 코드가 실행될 것으로 예상할 수 있습니다. Write-Host "They are equal"을 조건 코드로 입력하고 Enter 키를 누릅니다. 마지막으로 닫는 중괄호를 입력하여 조건 코드 섹션을 완료하고 Enter 키를 두 번 누릅니다. 빈 줄에 입력되는 두 번째 Enter 키를 통해 파서는 코드 작성이 완료되었다는 것을 인식하고 코드 실행을 준비합니다.
이 구문은 스크립트 파일에서 실행하고 있는 것이 아닙니다. 이 구문은 단순히 Windows PowerShell 명령줄에 입력한 것입니다. 이 기능은 Windows PowerShell을 다른 Windows 스크립트 언어와 차별화하는 요소로, 스크립트를 대화형으로 작성할 수 있을 뿐만 아니라 영구적인 저장을 위해 파일로 저장할 수도 있습니다.
여는 중괄호를 입력하고 Enter 키를 누르면 바로 Windows PowerShell에 >> 프롬프트가 표시됩니다. 이 프롬프트의 의미는 "구문이 시작되었으므로 구문에 넣을 내용을 입력하십시오."라는 뜻입니다. 닫는 중괄호를 입력하고 Enter 키를 두 번 누른 즉시 Windows PowerShell은 구문을 실행하여 논리 비교가 True임을 확인하고 조건 코드를 실행합니다. PowerShell이 정상 프롬프트로 돌아오기 전에 "They are equal"이 표시되는 것을 보고 조건 코드가 실행되었음을 알 수 있습니다. Windows PowerShell을 사용하여 대화형으로 스크립트를 작성하면 코드를 영구적인 스크립트로 어셈블하기 전에 빠르게 테스트할 수 있기 때문에 배우기도 쉽고 디버깅도 쉽게 수행할 수 있습니다.
Windows PowerShell은 Enter 키를 누르는 것에 대해 특별히 까다롭지 않습니다. 예를 들어 다음 코드는 앞의 예제와 동일하게 작동합니다.
PS C:\> if ($a -eq $b) { Write-Host "They are equal" }
They are equal
이 경우에는 한 줄에 모든 내용을 입력했기 때문에 Windows PowerShell에서 >> 프롬프트를 표시하지 않으며 줄의 끝에서 Enter 키를 누를 때 구문이 바로 실행됩니다. Windows PowerShell은 구문을 실행해도 좋다는 것을 어떻게 알 수 있을까요? 그것은 바로 닫는 중괄호가 입력되는 순간에 구문이 완료되기 때문입니다.
필자는 앞에서 If 구문의 변형에 대해 언급했었습니다. 다음은 셸 대신 PS1 스크립트 파일에 사용된 전체 예제입니다.
if ($a -eq $b) {
  Write-Host "They are equal"
} elseif ($a -lt $b) {
  Write Host "One is less than the other"
} else {
  Write Host "One is greater than the other"
}
이 구문도 마찬가지로 If 키워드로 시작됩니다. 그러나 비교 결과가 False인 경우를 위해 Elseif 키워드를 사용하여 다른 비교를 추가했습니다. 두 번째 비교 결과도 False이면 마지막 키워드 Else가 마지막으로 실행될 코드 집합을 제공합니다.

반복
Windows PowerShell에는 비교 결과가 True나 False가 될 때까지 반복해서 코드를 실행할 수 있는 여러 구문이 있습니다. 프로그래머는 이러한 구문을 루프 구문이라고 합니다. 또한 가장 유용한 루프 구문 중 하나는 컬렉션의 개체를 열거하고 한 줄 이상의 코드를 각 개체에 대해 실행할 수 있는 기능을 제공합니다. 이 구문이 바로 foreach 구문이며, 다음과 같이 사용됩니다.
PS C:\> $names = get-content "c:\computers.txt"
PS C:\> foreach ($name in $names) {
>> Write-Host $name
>> }
>>
don-pc
testbed
먼저 Windows PowerShell Get-Content cmdlet을 실행하여 c:\computers.txt 파일의 내용을 검색합니다. 이 파일은 저자가 직접 만든 파일로 각 줄에 하나의 컴퓨터 이름이 들어 있습니다. Windows PowerShell에서는 각 줄이 하나의 개체로 취급되므로 파일은 기본적으로 그러한 개체의 모음입니다. 이 개체 모음이 $names 변수에 할당됩니다. Foreach 키워드를 사용하여 $names 모음을 열거하도록 지정하고, 루프가 실행될 때마다 현재 개체를 나타내기 위해 $name 변수를 사용합니다. 루프 코드는 중괄호 안쪽으로 진행됩니다. 이제 파일에 있는 각 이름을 명령줄에 출력합니다. 알고 있는 바대로 구문 뒤에 표시된 출력은 Windows PowerShell에 의해 수행된 작업입니다. 이 기능을 통해 관리 스크립트 작업에서 얻을 수 있는 장점을 확실히 알 수 있을 것입니다. 예를 들어 서버 이름 목록을 작성한 다음 Windows PowerShell에서 각 서버 이름을 순서대로 검색할 수 있습니다.

실제 구문
이제 논리 비교, If 구문 및 foreach 구문을 사용하여 유용한 작업을 수행해 보겠습니다. 일련의 서버에 있는 Messenger 서비스의 상태를 빠르게 확인하려는 경우를 예로 들어 보겠습니다. 대부분의 서버에서 서비스가 중지되어 있을 것으로 생각되므로 서비스가 중지된 서버를 모두 나열하는 것보다는, Messenger 서비스가 실제로 시작된 서버에 대해 작업을 수행해야 하므로 이러한 서버만을 나열하려고 합니다.
Windows PowerShell Get-Service cmdlet을 사용하면 필요한 로컬 컴퓨터 정보를 검색할 수 있지만 불행히도 우리가 목표로 하는 원격 컴퓨터의 정보는 검색할 수 없습니다. 그러나 다행스럽게도 원격 컴퓨터와의 통신을 지원하는 Get-WMIObject cmdlet을 사용하여 WMI(Windows Management Instrumentation)를 통해 이 정보에 액세스할 수 있습니다. 다음 스크립트에서 이 작업을 수행합니다.
$names = get-content c:\computers.txt
foreach ($name in $names) {
  $svc = get-wmiobject win32_service '
   -computer $name -filter "name='messenger'"
  if ($svc.started -eq $True ) {
    write-host "$name has Messenger running"
  }
}
세 번째 줄에 있는 ' 문자가 보이십니까? 이 문자는 다음 줄이 연결되는 줄이라는 것을 나타냅니다. 이 기능은 줄바꿈을 하지 않으면 전체 줄을 Magazine에 표시하기 힘든 지금과 같은 경우에 유용합니다. 또한 If 구문에서 $svc.started와 $True가 비교됩니다. $True 변수는 Windows PowerShell에서 부울 값 True를 나타내는 특수 변수입니다. 마찬가지로 $False 변수는 부울 값 False를 나타냅니다. 실제로 간단하게 작업을 수행할 수 있었습니다.
$names = get-content c:\computers.txt
foreach ($name in $names) {
  $svc = get-wmiobject win32_service '
   -computer $name -filter "name='messenger'"
  if ($svc.started) {
    write-host "$name has Messenger running"
  }
}
If 구문의 조건은 True와 False 중 하나여야 한다는 것을 기억하십시오. 이 스크립트의 첫 번째 버전에서 설명한 것처럼 일반적으로 두 값을 비교하면 True나 False가 반환됩니다. 그러나 Started 속성의 값은 True나 False이기 때문에 True나 False를 실제로 비교할 필요가 없습니다.

유용한 도구
이제 구문을 사용해서 작업을 수행할 수 있는 간단하고 유용한 관리 도구가 완성되었습니다. Windows PowerShell에서 대화형으로 구문을 입력하든지 아니면 손쉬운 재사용을 위해 구문을 PS1 파일로 저장하든지 이 도구는 다양한 컴퓨터에서 실행되고 있는 서비스의 상태를 확인할 수 있는 간편한 도구이며, 구문을 사용하여 관리 작업을 자동화하는 방법을 보여 주는 훌륭한 데모입니다.

Don Jones는 SAPIEN Technologies의 프로젝트 및 서비스 담당 이사이자 Windows PowerShell: TFM(SAPIEN Press, 2006)의 공동 저자입니다. 문의 사항이 있으면 ScriptingAnswers.com으로 연락하십시오.


 Hey, Scripting Guy!: 말 조심하세요
Hey, Scripting Guy!
말 조심하세요
Microsoft Scripting Guys

남북 전쟁(구체적으로 Spotsylvania 전투) 중 북군의 John Sedgwick 장군은 남군의 저격수가 가끔씩 총을 쏘아대는 통에 부하들이 위축된 것을 보고 크게 실망했습니다. 전해져 오는 이야기에 따르면 Sedgwick이 부하들에게 "나는 그렇게 숨어 있는 제군들이 부끄럽다. 이 거리에서는 코끼리도 맞추지 못한다."라고 말했다고 합니다. 그렇게 말하고 난 잠시 후에 그는 전쟁 중에 전사한 최고 서열의 북군 장군이 되었다고 합니다. 남군의 저격수가 그 거리에서 코끼리를 맞추지는 못했을 것입니다. 그러나 불행하게도 Sedgwick 장군은 그들의 총에 맞고 말았습니다.
물론 이 이야기의 교훈은 두 말할 나위 없이 "누군가 너를 노리고 있으면 몸을 낮춰라."라는 것입니다. 그렇지 않습니까? 그렇지만 우리는 그렇게 생각하지 않습니다. 대신 우리가 얻은 교훈은 "내뱉은 말이 나를 따라다닐 수 있으므로 말 조심해야 한다."라는 것입니다. 이 교훈은 John Sedgwick 장군뿐만 아니라 다른 많은 사람들에게도 들어 맞는 이야기입니다. 예를 들어, 장기간 IBM 회장을 역임했던 Thomas Watson을 미국 역사에 남을 위대한 기업가 중 한 사람으로 기억하는 사람은 아무도 없습니다. 그 대신 Watson은 "컴퓨터에 대한 수요는 전세계적으로 5대 정도에 불과할 것이다."라고 말한 사람으로 기억되고 있습니다.
흥미롭게도 Watson이 실제로 이렇게 말했다는 증거는 없습니다. 기껏해야 다른 사람의 생각을 단순하게 언급했을 것이라고 추측하는 정도입니다. 그러나 누가 신경 씁니까? 결국 IBM 회장이 '컴퓨터 시장은 없다.'라고 말했을 것이라는 생각에서 우리는 이러한 우스운 일이 퍼지는 것은 막을 수 없다는 좋은 교훈을 얻었습니다.
Watson은 "성공하는 비결은 실패율을 두 배로 높이는 것이다."라는 말도 했습니다. Scripting Guy는 이 충고를 진심으로 받아들이고 있습니다.
그러니까 실패율을 두 배로 높이라는 말만큼은 중요하게 생각한다는 거죠.
이제 "VBScript 스크립트를 작성할 때는 .NET Framework에 액세스할 수 없다."는 말을 살펴봅시다. 스크립트 작성자는 Microsoft® .NET Framework에 액세스할 수 없다라는 말은 "이 거리에서는 코끼리도 맞추지 못한다."라는 말이나 "컴퓨터에 대한 수요는 전세계적으로 5대 정도에 불과할 것이다."라는 말과는 달리 그리 기억에 남을 만한 말은 아닙니다만, 사실과 거리가 멀다는 점만은 동일합니다. 물론 .NET Framework가 C# 및 Visual Basic® 개발자를 염두에 두고 설계되었다는 것과 VBScript에서 네이티브 .NET Framework 클래스를 인스턴스화할 수 없다는 것은 사실입니다. 그렇다고 해서 스크립트 작성자가 .NET Framework에 전혀 액세스할 수 없는 것은 아닙니다.
맞습니다. 여러분의 말처럼 대부분의 .NET Framework 클래스는 VBScript로 직접 가져올 수 없는 클래스입니다. 그러나 COM 호출 가능 래퍼를 갖고 있는 .NET 클래스가 상당히 많이 있습니다. 이는 곧 이러한 클래스에 COM 인터페이스가 있어 VBScript와 같은 스크립트 언어에서 액세스할 수 있다는 것을 뜻합니다. 믿기 어렵습니까? 그림 1에 표시된 레지스트리의 HKEY_CLASSES_ROOT 부분에서 System으로 시작하는 모든 종류의 클래스를 살펴보십시오.
그림 1 레지스트리에 있는 System 클래스
그림 1 레지스트리에 있는 System 클래스 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 레지스트리에 있는 System 클래스
그림 1 레지스트리에 있는 System 클래스 (더 크게 보려면 이미지를 클릭하십시오.)
이들 클래스의 대부분은 .NET Framework 클래스이며 VBScript를 통해 인스턴스화할 수 있습니다.
앞에서 말했던 것처럼 말입니다.
물론 전날 밤 TV 광고를 보고 제품을 구매한 적이 있는 사람이라면 누구나 알 수 있듯이 무언가를 '할 수 있다'는 것이 그것을 반드시 해야 한다는 것을 의미하지는 않습니다. 일반적으로 그러한 제품을 매장에서 판매하지 않는 이유가 있는 것처럼 말이죠. 즉, 스크립트에서 System.ContextMarshalException 클래스의 인스턴스를 만들 수 있습니다. 그러나 우리는 여러분이 인스턴스를 왜 만들려고 하는지 그리고 인스턴스를 만들어 무슨 작업을 수행하려는 것인지 모르겠습니다.
그러나 일부 .NET Framework 클래스에서는 인스턴스를 만드는 것이 유용한 경우도 있습니다. 예를 들어, 스크립트 세계에 근거 없이 떠도는 이야기 중 하나는 항목 목록을 쉽게 정렬할 수 있는 방법이 없다는 것입니다. 목록을 사전순으로 정렬하려면 연결이 끊어진 레코드 집합을 사용하거나 다음 버블 정렬 코드와 같이 매우 복잡한 정렬 함수를 직접 만들어야 합니다. 속이 뒤틀리는 사람은 다음 단락으로 이동해도 좋습니다.
For i = (UBound(arrNames) - 1) to 0 Step -1
    For j= 0 to i
        If UCase(arrNames(j)) >
          UCase(arrNames(j+1)) Then
            strHolder = arrNames(j+1)
            arrNames(j+1) = arrNames(j)
            arrNames(j) = strHolder
        End If
    Next
Next
머리 아프게 들여다볼 필요는 없습니다. 우리가 작성한 코드이기는 하지만 우리도 뭐가 뭔지 잘 모르겠습니다.
이런 상황에서 .NET Framework를 어떻게 사용할 수 있겠습니까? 그 대답을 찾기 위해 다음과 같은 매우 간단하고 짧은 스크립트를 살펴보겠습니다.
Set DataList = CreateObject _
      ("System.Collections.ArrayList")

DataList.Add "B"
DataList.Add "C"
DataList.Add "E"
DataList.Add "D"
DataList.Add "A"

DataList.Sort()

For Each strItem in DataList
    Wscript.Echo strItem
Next
위에서 볼 수 있는 것처럼 이 코드에서는 .NET Framework 클래스인 System.Collections.ArrayList의 인스턴스를 만듭니다. 그런 다음 Add 메서드를 사용하여 항목 5개를 목록에 추가합니다. 이 코드는 모든 것이 올바르고 아무 문제 없는 것으로 보이나 순서에 상관없이 무작위(B, C, E, D, A)로 항목을 추가했기 때문에 항목을 사전순(A, B, C, D, E)으로 표시해야 할 필요가 있습니다. 이제 버블 정렬 코드를 추가하면 될 것 같은데 맞습니까?
틀렸습니다. 미안하지만 틀린 것은 틀린 것입니다. 버블 정렬 코드를 추가할 필요 없이 다음과 같이 ArrayList의 Sort 메서드를 호출하기만 하면 됩니다.
DataList.Sort()
이게 다입니다. 단 한 줄의 코드로 배열 목록의 모든 항목을 정렬할 수 있습니다.
확인해 볼까요? 정말 확인해 보라구요? 좋습니다. 여러분 중에 의심 많은 분들이 있을 거라 생각하고 목록의 모든 항목에 대해 루프를 돌면서 각 항목의 값을 화면에 표시하는 For Each 루프를 스크립트에 넣어 보겠습니다.
For Each strItem in DataList
    Wscript.Echo strItem
Next
이제 까다로운 질문을 하나 하겠습니다. 이 스크립트를 실행하여 어떤 결과를 얻을 것 같습니까?
바로 아래와 같이 나타납니다.
A
B
C
D
E
문제 없이 잘 되었네요. 그렇죠?
여기에 만족하지 않는 분도 계시는 것 같군요. 문제 없이 잘 되었다고 말하고 있기는 하지만 여러분이 진짜로 원했던 것은 이 값들을 내림차순으로 표시하는 것이었군요. 즉, A-Z 순서로 된 목록이 아니라 Z-A 순서로 된 목록을 원하는 것이죠? 내림차순 정렬이 잘 안 된다면 한번 생각해 보죠.
좋아요, 문제 없습니다. 모든지 주문만 하십시오.
Set DataList = CreateObject _
      ("System.Collections.ArrayList")

DataList.Add "B"
DataList.Add "C"
DataList.Add "E"
DataList.Add "D"
DataList.Add "A"

DataList.Sort()
DataList.Reverse()

For Each strItem in DataList
    Wscript.Echo strItem
Next
맞습니다. 이 코드는 조금 전에 본 스크립트와 거의 동일합니다. 그러나 한 가지 중요한 부분이 추가되었습니다. 추가된 한 줄을 찾아 보십시오. Sort 메서드 바로 뒤에 다음과 같은 한 줄이 추가되었습니다.
DataList.Reverse()
보이십니까? 오름차순으로 목록을 정렬한 후 배열에 있는 모든 항목의 순서를 역순으로 바꿔주는 Reverse 메서드를 호출했습니다. 어떤 결과가 나올까요? 그 결과는 다음과 같습니다.
E
D
C
B
A
정말 신기하지 않습니까?
잠깐만! 또 있습니다. VBScript 배열에서 항목을 제거해 본 적이 있습니까? 없다고요? 괜찮습니다. 항목을 제거하라고는 하지 않겠습니다. 대신 .NET Framework ArrayList에서 항목을 제거하는 것이 얼마나 쉬운지 보여 드리겠습니다. 문자 D가 마음에 들지 않으세요? 제거하죠, 뭐. 다음 스크립트에서는 배열 목록을 만들고 정렬한 다음 D 항목을 제거합니다.
Set DataList = CreateObject _
  ("System.Collections.ArrayList")

DataList.Add "B"
DataList.Add "C"
DataList.Add "E"
DataList.Add "D"
DataList.Add "A"

DataList.Sort()
DataList.Remove("D")

For Each strItem in DataList
    Wscript.Echo strItem
Next
다시 한번 Sort 메서드 바로 뒤에 있는 줄을 살펴보십시오.
DataList.Remove("D")
여기에서는 Remove 메서드를 사용하여 D와 동일한 항목을 제거했습니다. 다음은 스크립트가 실행된 결과입니다.
A
B
C
E
이제 D가 삭제되었죠?
그리고 가장 중요한 부분을 간과하지 마십시오. 바로 배열의 크기나 차원을 변경하지 않고도 항목을 제거할 수 있다는 것입니다. 정말 멋지지 않습니까? 물론 배열의 크기나 차원을 변경하지 않고도 배열에 항목을 추가할 수도 있습니다. 스크립트 작업이 수월해지지 않았습니까?
안 믿을 수도 있겠지만 지금까지의 내용은 .NET Framework ArrayList로 수행할 수 있는 작업의 일부에 불과합니다. 자세한 내용은 .NET Framework SDK의 ArrayList 항목(영문)을 참조하십시오.
ArrayList가 스크립트 작성자에게 그렇게 유용합니까? 이렇게 말하고 싶군요. .NET Framework ArrayList가 있는데 기본 제공 VBScript 배열을 왜 굳이 사용하려고 하는지 모르겠습니다. 여기에서 사용한 목록과 같이 매우 간단한 항목 목록만 아니라면 ArrayList가 매우 유용할 것입니다.
그동안 Scripting Guy는 스크립트 작성자에게 유용하거나 유용하지 않은 클래스를 찾기 위해 .NET Framework를 꼼꼼히 살펴보지는 않았지만 현재 열심히 조사 중입니다. 자세한 내용은 전체 .NET Framework SDK(영문)를 참조하십시오. SDK를 볼 때마다 스크립트 작성자가 사용할 수 있는 새롭고 흥미로운 것을 발견하게 됩니다.
예를 들어 임의 번호를 생성할 수도 있습니다. VBScript 임의 번호 생성기를 사용하여 1-100 사이의 임의 번호를 생성하고 싶습니까? 다음과 같은 코드를 사용하면 쉽게 해결할 수 있습니다.
Randomize
Wscript.Echo Int((100 - 1 + 1) * Rnd + 1)
수식을 외우셨습니까? 외우지 않았더라도 걱정하지 마십시오. .NET Framework의 System.Random 클래스를 사용하면 훨씬 간단하고 쉽게 해결할 수 있습니다.
Set objRandom = CreateObject("System.Random")
Wscript.Echo objRandom.Next_2(1,100)
설명하지 않아도 바로 알 수 있을 것입니다. 그렇다고 하더라도 TechNet Magazine에서는 칼럼니스트가 매월 정보를 기재해야 한다고 생각하기 때문에 간단하게 설명하겠습니다. TechNet Magazine의 정책 때문에 우리가 고생해야 하는 이유를 모르겠습니다.
위에서 볼 수 있는 것처럼 이 코드에서는 System.Random 클래스의 인스턴스를 만든 다음 2개의 매개 변수를 전달하는 Next_2 메서드를 호출합니다.
  • 1은 범위의 첫 번째 숫자입니다. 앞에서 1-100 사이의 임의 번호를 생성하기로 한 것을 기억하시죠?
  • 100은 범위에서 가장 큰 숫자입니다.
이제 다 했습니다.
마지막 질문에 대한 답을 할 시간이 된 것 같군요. 예, 마음에 드셨군요. 도대체 스크립트 작성자가 .NET Framework에 액세스할 수 없다고 말한 사람이 누구입니까? 솔직히 처음 시작할 때 시간이 부족할 것이라고 생각했는데 정말 그렇네요. 다음 달에 뵙겠습니다.
기다리고 기다리던 시간
2월이 다가오는데 무엇이 생각나십니까? 발렌타인 데이? 아니요. 오, 이런... 구정이 생각나신다고요? 아니죠. 2월에는 우리가 그렇게도 기다리던 세계 제1의(아마도 세계에서 유일한) 국제 스크립트 경쟁 대회인 2007 Winter Scripting Games가 열립니다. 올해의 행사는 그 어느 때보다도 성대하게 열릴 것이며, 다음 4가지 부문으로 진행될 것입니다.
  • 초급 VBScript
  • 고급 VBScript
  • 초급 Windows PowerShell™
  • 고급 Windows PowerShell
자세한 내용은 2007 Winter Scripting Games 홈 페이지(영문)를 참조하십시오.
뭐라고요? 아, 감사합니다. 여러분도 새해 복 많이 받으세요.

Windows PowerShell 다운로드
이제는 Windows PowerShell 1.0을 다운로드할 수 있습니다. 그것도 무료로 말입니다. 정말 좋은 기회 아닌가요? 지금 바로 소프트웨어를 다운로드(영문)하십시오.

Microsoft Scripting Guys는 Microsoft의 업무를 담당하는, 정확히 말하면 Microsoft에 고용된 직원입니다. 이들은 야구를 하거나, 감독하거나, 관람하는 등의 일상적인 다른 활동을 하지 않을 때 TechNet 스크립트 센터를 운영합니다. 자세한 내용은 http://www.microsoft.com/korea/technet/scriptcenter/default.mspx에서 확인하십시오.


 Exchange Queue &amp; A: 우리는 모든 답을 알고 있어요. 바로 우리가 질문한 거거든요.
Exchange Queue & A
우리는 모든 답을 알고 있어요. 바로 우리가 질문한 거거든요.
KC Lemson and Paul Bowden

안녕하세요. 이번 호부터 새롭게 게재되는 Exchange Queue & A입니다. 처음 소개할 질문들은 사실 우리가 직접 작성한 것이기 때문에 진정한 의미의 질문과 대답(Q&A) 칼럼으로 보기에는 다소 부족한 면이 있을 수도 있습니다.
우리 스스로 질문을 작성하고 그에 대해 대답하는 것은 고객이 진정으로 원하는 Q&A가 아닐 수도 있기 때문입니다. 하지만 우리는 이러한 질문들이 Microsoft® Exchange Server 고객들이 궁금해 하는 사항일 것이라고 믿기 때문에 교훈적 근거는 충분하다고 생각합니다. 물론 향후에는 고객들의 질문을 받을 것이므로 질문이 있으면 언제든지 queuea@microsoft.com으로 보내 주시기 바랍니다.
현재로서는 여러 작성자들이 돌아가면서 칼럼을 작성해 보도록 하려고 합니다. 그러니까 여러 작가들에게 질문과 답변을 작성하도록 해서 어떤 작가가 유용한 질문과 답변을 작성하는지 알아보려는 것이지요. 하지만 이들은 모두 수년간 Exchange와 관련된 업무를 해 왔습니다. 이 달의 답변(그리고 질문!)은 Microsoft의 Exchange 제품 팀에서 선임 프로그램 관리자로 일하고 있는 KC Lemson과 Paul Bowden이 공동으로 작성하였습니다. 우리 둘 모두 Exchange 개발에 있어서는 고참이라고 할 수 있습니다. 우리는 이곳저곳을 상당히 많이 돌아다녔지만 메시징에서 벗어날 수 있었던 적은 한 번도 없었습니다.
KC는 지난 6년간 Exchange 그룹에서 Microsoft Outlook® Web Access(OWA) 프로그램 관리자와 Exchange 시험판 고객 프로그램을 담당하는 선임 프로그램 관리자 등 다양한 업무를 맡아 왔습니다. 현재는 Exchange의 사용자 환경 관리자로 제품 디자인 및 고객 조사를 담당하고 있습니다. Exchange 팀에 합류하기 전에는 3년간 Outlook 테스터로 일하면서 사람들이 전자 메일에 첨부된 실행 파일을 차단하는 것이 어렵고 힘든 일이라고 생각하던 시기에 첨부 파일을 테스트하는 일을 맡았습니다. KC는 blogs.technet.com/kclemson(영문)에서 블로그를 운영하고 있습니다.
Paul은 지난 3년간 규모는 작지만 기능이 뛰어난 Exchange Best Practices Analyzer(ExBPA) 도구에 대한 업무를 담당해 오고 있습니다. 사실 그는 몇 달 전 ExBPA 도구로 상을 받았으며 Bill Gates와 사진도 촬영했습니다. 하지만 Exchange Server 2007 프로젝트가 마무리되어 가는 지금 이제는 역할을 바꿀 때가 왔습니다. Paul은 XML에 대한 환상에서 벗어나 현실로 돌아와야 합니다. 그는 Exchange Server 2007 출시 즉시 작업에 들어가게 될 버전인 다음 Exchange 버전의 릴리스 관리자로 활동할 예정입니다.
그나저나 이 재치 넘치는 칼럼 제목은 어떻게 보셨나요? 이 제목은 우리가 만든 것이 아니라 KC의 블로그를 방문한 한 독자가 제안한 것입니다. (셔츠 잘 입으세요, Tim!) 아쉽게 선정되지 못한 제목으로는 "새로운 한계에 도전하다(Pushing the Envelope)"와 "내가 만약 X64 버전이라면...(When I'm X64)"이 있었습니다. 특히 후자를 너무 마음에 들어 한 KC는 www.whenimx64.com이라는 도메인을 등록하고 자신의 블로그를 이 도메인에 연결했습니다. 우리가 살아가면서 이렇게 모든 것을 할 수 있는 능력을 가진다면 얼마나 좋을까요.
참고: KC는 처음에 이 칼럼의 이름을 "이번 달의 질문과 대답"으로 하자고 제안했지만 편집자는 아직 그 분량이 얼마나 될지, 우리가 일정에 맞추어 칼럼을 제공할 수 있을지 확신할 수가 없다는 점을 지적했습니다. 여기 우리보다 그의 대답은 훨씬 정중하고 퉁명스럽지 않았지만 우리는 그의 생각이 무엇인지 알고 있었습니다. 뿐만 아니라 이 칼럼을 읽은 독자들이 어떤 의견을 보내줄지, 이 칼럼을 계속 게재할 가치가 있는지도 확실히 알 수 없습니다. 따라서 우리는 그 중간쯤 되는 이름을 선택한 것입니다. 여러분의 의견을 queuea@microsoft.com으로 보내 주십시오.
이제 칼럼 제목에 대한 이야기는 여기서 접고 질문으로 넘어가겠습니다.

질문: Exchange Server 2007의 기대되는 특징으로는 무엇이 있습니까?
대답: 첫 번째 칼럼을 마케팅 냄새가 나는 질문으로 시작하는 것은 위험의 소지가 있다는 걸 알지만 Exchange Server 2007에 대한 기대가 너무 커서 정말로 여러분과 함께 나누고자 합니다. 이에 따라 마케팅적인 강연은 가급적 삼가고 Exchange 관리자 또는 사용자가 Exchange 2007을 기대해야 하는 수많은 기술적 이유를 몇 가지만 이야기하려고 합니다.

확장성 및 성능 향상
첫 번째 특징은 확실합니다. 바로 64비트라는 점입니다. 그게 뭐 그리 대단하냐고요? 그러니까 32비트 Windows®는 총 4GB(232바이트)의 메모리밖에 지원하지 못합니다. 그 중 2GB는 커널이 기본적으로 차지하고 나머지 2GB만 응용 프로그램이 사용할 수 있습니다. 현재 버전의 Windows는 boot.ini에서 /3GB 스위치를 지원하여 응용 프로그램에 최고 3GB의 메모리 공간을 제공하지만 이 스위치를 사용하면 Windows 커널에 작은 문제가 발생하게 되므로 서버를 재부팅하고 리소스를 회수하도록 결정하는 데 그리 오래 걸리지 않게 됩니다.
하지만 다행히도 Exchange에서는 64비트를 지원할 뿐만 아니라 기본 데이터베이스 엔진(JET)도 많이 변경되었으므로 이러한 문제가 해결되었습니다. Exchange Server는 지금까지 CPU와 같은 다른 시스템 리소스보다는 디스크 I/O 때문에 제한을 받는 경우가 훨씬 더 많았기 때문에 시스템에 메모리를 추가한다는 것은 디스크를 읽지 않고 메모리에 더 많은 정보를 보관함으로써 디스크 I/O를 상당히 줄일 수 있다는 것을 의미합니다. 결과적으로 Exchange 2007에서는 Exchange 2003과 유사한 물리적 하드웨어를 사용하더라도 Exchange 2003보다 훨씬 큰 사서함을 사용자에게 제공할 수 있습니다. 예를 들어, 현재 Microsoft에서 사용하고 있는 메일 서버는 2GB 사서함 용량으로 4,000명의 사용자를 지원하며 6TB(테라바이트)의 데이터를 보관합니다. 확실히 말해 두지만, Exchange 2007이 더 많은 메모리를 활용할 수 있다고 해서 그만큼 많은 메모리를 필요로 한다는 것은 아닙니다. 우리는 메모리가 4GB 이하인 32비트 Windows Server® 2003과 Exchange 2003을 실행하는 제품을 테스트해 본 후 64비트 Windows Server 2003과 Exchange 2007을 설치해 봤는데 성능이 비슷하게 나타났습니다.
Exchange 2007은 또한 CCR(Clustered Continuous Replication)과 LCR(Local Continuous Replication)이라는 두 가지 획기적인 방법으로 가용성을 높입니다. 이러한 기술은 심각한 문제를 야기하는 저장소 오류의 위험을 줄입니다. LCR은 데이터베이스의 로컬 복사본을 동일한 시스템에 보관하지만 이를 다른 저장소 미디어로 옮길 수도 있습니다. CCR은 네트워크를 통해 두 시스템 사이에서 동일한 작업을 수행할 수 있습니다. 이 CCR이 칼럼 초반부에 잠깐 설명했던 디스크 I/O 기능 개선과 맞물리면서 새로운 저장소 하드웨어 옵션을 제공하게 되었습니다. 다시 말해, SATA 또는 SCSI 드라이브와 같은 DAS(Direct Attached Storage) 미디어를 사용하고 싶은 경우 이제는 훨씬 경제적이고 성능이 좋은 옵션을 선택할 수 있습니다.

관리
Microsoft는 Exchange 2007에서 그림 1과 같은 명령줄 인터페이스가 포함된 새로운 관리 환경을 개발하기 위해 엄청난 투자를 했습니다. EMS(Exchange 관리 셸)라고 불리는 이 기술은 Windows PowerShell™에 기반을 두고 있습니다. GUI가 계속해서 제공되므로 명령줄을 선호하지 않아도 상관없습니다. 다만 이제는 GUI가 EMC(Exchange 관리 콘솔)라는 이름으로 제공되며 이는 과거의 시스템 관리자에 비해 훨씬 직관적인 인터페이스입니다(그림 2 참조). 명령줄 인터페이스를 사용해 왔거나 앞으로 그럴 계획이라면 Exchange 2007의 EMS를 확인해 보십시오.
그림 1 EMS(Exchange 관리 셸)의 저장소 그룹 상태
그림 1 EMS(Exchange 관리 셸)의 저장소 그룹 상태 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 EMS(Exchange 관리 셸)의 저장소 그룹 상태
그림 1 EMS(Exchange 관리 셸)의 저장소 그룹 상태 (더 크게 보려면 이미지를 클릭하십시오.)
그림 2 EMC(Exchange 관리 콘솔)의 동일한 상태
그림 2 EMC(Exchange 관리 콘솔)의 동일한 상태 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 EMC(Exchange 관리 콘솔)의 동일한 상태
그림 2 EMC(Exchange 관리 콘솔)의 동일한 상태 (더 크게 보려면 이미지를 클릭하십시오.)
Exchange 2003에서는 WMI(Windows Management Instrumentation) 스크립트를 사용하여 보다 복잡한 관리 작업을 수행해야 했을 것입니다. 하지만 EMS를 사용하면 "CD C:\TEMP"의 내용을 어느 정도 이해할 수 있는 사용자라면 누구나 이러한 관리 작업을 수행할 수 있습니다. 우리 중 하나는 이전에 UNIX sysadmin 역할을 했고 그래서 객관성이 문제가 될지 모르지만, 과거에 명령줄을 한 번도 사용해 보지 않은 사람에게도 이 셸은 믿을 수 없을 만큼 직관적이라고 보증해 줄 객관적인 다른 사람들을 얼마든지 알려드릴 수 있습니다. 자세한 내용은 다음 Exchange Queue & A 칼럼에서 논의하겠습니다.
Windows PowerShell의 강점은 개체 지향이라는 것입니다. 서버에서 사서함이나 SMTP 커넥터 목록 등의 정보를 검색하면 이 정보는 자동으로 개체나 변수에 저장되고 쉽게 읽을 수 있도록 텍스트로 stdout에 스트리밍됩니다. 그러면 이 개체는 다른 명령으로 직접 전달되어 파이프라인에서 작동됩니다. 이 경우 텍스트가 아닌 개체를 따라 전달되므로 데이터를 수정하거나 데이터 일부를 작업하기가 쉽습니다. 간단한 예를 들어 보겠습니다.
Get-Mailbox | Set-Mailbox -ProhibitSendQuota 250MB
Get-Mailbox 명령은 시스템에서 사서함 목록을 검색합니다. 파이프 기호라고 하는 |는 왼쪽에 있는 명령의 출력이 오른쪽에 있는 명령으로 전달되어야 한다는 것을 나타냅니다. 그 다음 부분인 "Set-Mailbox-ProhibitSendQuota 250MB"는 사서함 전체의 크기가 250MB에 도달하면 더 이상 전자 메일을 보낼 수 없다는 것을 의미합니다. 셸은 데이터를 처리하는 방식이 매우 유연하므로 할당량을 250000000, 250000KB 또는 0.25GB로 설정할 수도 있습니다.
Exchange 2007에서 향상된 또 다른 유용한 관리 기능은 Outlook에 있는 것과 매우 유사한 규칙 마법사를 사용하여 비즈니스 논리를 시스템을 통해 전달되는 메시지에 적용하는 전송 규칙을 생성할 수 있는 기능입니다. 정규식을 바탕으로 본문에 주민 등록 번호가 포함되어 있는 것으로 보이는 전자 메일을 차단하고 싶으세요? 선택만 하세요. 조직 내 두 부서가 서로 전자 메일을 주고 받지 못하도록 교신 차단 영역을 설정하고 싶으세요? 선택만 하세요. 조직 외부로 나가는 모든 전자 메일에 법적 고지 사항을 추가하고 싶으세요? 선택만 하세요.
우리가 큰 기대를 갖고 있는 마지막 관리 기능은 사용자 지정이 가능한 시스템 메시지입니다. 이제는 기본적으로 사용자 지정 텍스트를 배달 못 함 보고서에 추가할 수 있을 뿐만 아니라 드디어 저장소 할당량을 초과할 때 사용자에게 표시되는 메시지도 추가할 수 있게 되었습니다.

기술 지원 부서 지원
많은 고객들이 가장 많이 지출하는 비용 중 하나가 Outlook에서 새 프로필을 구성하는 것과 관련된 기술 지원 부서 비용입니다. Outlook 2007에는 자동 검색이라는 기능이 있어서 Outlook을 시작하기만 하면 서비스 연결 지점을 통해 자동으로 전자 메일 주소가 조회되고 Active Directory®에서 Exchange Server 정보가 검색됩니다. Active Directory에 연결되어 있지 않더라도 전자 메일 주소와 암호만 입력하면 자동 검색 조회를 통해 http://autodiscover.contoso.com과 같은 지정된 웹 서버에서 RPC over HTTP(현재는 '외부에서 Outlook 사용'이라고 함)에 사용할 서버 등의 기본적인 구성 정보가 들어 있는 XML 파일을 다운로드할 수 있습니다.
또한 스팸 필터에서 메시지가 잘못 걸러지는 피할 수 없는 문제를 관리하는 데에도 많은 기술 지원 부서 비용이 지출됩니다. 사용자는 콘텐츠 필터링에서 걸러지지 않아야 하는 메시지를 보낸 사람들의 목록을 Outlook에 안전하게 보관할 수 있지만 Exchange 2007 이전 버전에서는 이러한 목록에서 메시지가 Outlook 필터만 그냥 통과하도록 합니다. 하지만 Outlook이 메시지를 보기 전에 Exchange 필터가 그러한 메시지를 처리하므로 사용자는 여전히 신뢰할 수 있는 사람들이 보낸 전자 메일을 놓칠 가능성이 있었습니다.
Exchange 2007은 여기서도 도움이 됩니다. 사용자가 Exchange 2007에서 Edge 또는 Hub 서버 역할을 통해 스팸 콘텐츠를 걸러내는 필터를 사용할 경우 사용자의 수신 허용 목록을 해당 서버에 전파하여 그러한 보낸 사람이 보낸 메시지가 스팸 콘텐츠 필터에서 걸러지지 않도록 구성할 수 있습니다. 물론 어떤 사용자에게는 스팸인 전자 메일이 다른 사용자에게는 회보가 될 수도 있기 때문에 수신 허용 목록은 사용자 각각을 기준으로 작성됩니다.

최종 사용자 혜택
Exchange 2007의 UM(통합 메시징) 기능을 사용하여 받은 편지함을 통해 인바운드 음성 메일과 팩스를 받을 수 있습니다. 과거에 이 기능을 사용해 본 적이 없다면 무엇을 놓치고 있는지도 모를 것입니다. 또한 Exchange Server를 호출하여 오전 8시 모임의 모든 참석자에게 자신이 늦을 거라는 사실을 알려주도록 설정할 수도 있습니다. 아무리 작은 조직도 쉽게 자동 전화 교환을 사용자 지정하고 브랜딩하여 고객이 전화를 걸었을 때 시스템이 자동으로 적절한 곳으로 전화를 연결하도록 할 수 있습니다. UM 기능을 사용하려면 IP 기반 PBX(IP/PBX)를 사용하거나 전통적인 회로-스위치 기반 PBX를 VoIP(Voice over IP) 게이트웨이에 연결해야 합니다.
링크 액세스는 OWA 2007의 새로운 기능입니다. 이동 중인 경우 VPN 클라이언트가 설치되어 있지 않은데 파일 공유에 있는 Microsoft Word 문서를 봐야 하거나 회사 네트워크에 있는 SharePoint® 사이트를 확인해야 할 경우에는 어떻게 해야 할까요? 아무 문제 없습니다. OWA 2007을 로드해서 문서 링크로 이동한 다음 공유 또는 SharePoint 사이트(http://mysharepointsite 및 \\server\share) 이름을 입력하고 파일을 찾아서 열면 됩니다. 물론 관리자는 풍부한 보안 기능을 통해 파일에 액세스하지 못하도록 잠글 수 있습니다. 이뿐만 아니라 특정 목록을 제외한 모든 서버를 허용하거나, 특정 목록을 제외한 모든 서버를 거부하거나, 사용자가 개인 컴퓨터에서 OWA에 로그인할 때 문서 액세스만 허용하는 등 원하는 대로 액세스를 통제할 수 있습니다.
OWA에는 WebReady 문서 보기(전문가들은 이를 "트랜스코딩"이라고 부름)이라는 기능이 있어서 로컬에 올바른 응용 프로그램이 설치되어 있지 않을 경우 특정 형식의 파일을 HTML로 렌더링하도록 Exchange에 명령할 수 있습니다. Exchange 2007은 DOC, DOT, RTF, WBK, WIZ, XLS, XLK, PPT, PPS, POT, PWS, PDF 등과 같은 파일 형식의 트랜스코딩을 기본적으로 지원할 예정입니다. 트랜스코딩 엔진에는 새로운 파일 형식에 대한 지원을 서비스 팩에 추가할 수 있도록 플러그형 아키텍처를 채택했습니다. 또한 사용자에게 트랜스코딩을 허용할 파일 형식이나 완전히 트랜스코딩을 금지할 파일 형식을 결정할 수 있도록 관리 옵션도 포함되어 있습니다.
Exchange ActiveSync®를 사용하여 Exchange와 동기화되는 모바일 장치가 있는 경우 전자 메일 스레드에 회신하거나 이를 전달하면 메시지가 더 이상 일반 텍스트로 변환되지 않습니다. 텍스트는 맨 위에 추가되지만 메시지 나머지의 HTML 본문은 그대로 남아 있습니다. 이는 ActiveSync를 지원하는 모든 장치에서 마찬가지입니다. 이 경우 클라이언트의 기능은 필요하지 않습니다.

질문: Exchange 2007이 "프로덕션 목적일 때만 64비트"라는 말을 들었는데 이게 무슨 뜻입니까?
대답: Exchange 2007은 32비트나 64비트로 모두 사용할 수 있습니다. 64비트 버전은 핵심 서버 역할(사서함, Hub 전송, Edge 전송, 클라이언트 액세스, 통합 메시징)의 프로덕션 "라이브" 사용을 목적으로 설계되었습니다. 32비트 버전은 Exchange 2007의 새로운 기능을 평가할 목적으로 설계되었습니다. 또한 관리 도구를 프로덕션 환경에서 32비트로 사용할 수도 있기 때문에 32비트 Windows XP 데스크톱 시스템에서 64비트 Exchange 2007 프로덕션 서버를 관리할 수 있습니다. 또한 Exchange 2007 스키마는 루트 도메인의 시스템에서 설치해야 합니다. Exchange 자체는 루트 도메인에 설치할 필요가 없지만 스키마 마스터와의 양호한 네트워크 연결을 위해 스키마 확장은 루트 디렉터리에서 이루어져야 합니다. 도메인에 64비트 서버가 없다면 32비트 버전의 setup.exe를 사용하여 스키마를 확장할 수 있습니다.
32비트 서버는 뭐가 문제냐고요? 한 대의 서버로 수천 명의 사용자를 지원해 왔다면 앞서 설명한 메모리 제한으로 인해 성능과 안정성 사이에 균형을 맞추는 작업이 상당한 작업이라는 사실을 알 것입니다. 지난 2년 사이에 새 컴퓨터를 구입했다면 이미 x64 확장을 지원하고 있을 수 있습니다. 사실 요즘에는 64비트 모드를 지원하지 않는 새 컴퓨터를 산다는 것이 상당히 어렵습니다. 따라서 현재 환경에서 이미 Exchange를 실행하고 있는 시스템은 64비트를 지원할 가능성이 있습니다. 다만 32비트 운영 체제를 실행하고 있을 뿐입니다. 그렇다면 어떻게 해야 할까요? 64비트를 지원하는 새 컴퓨터를 구입한 후에 64비트 버전의 Windows Server 2003 SP1을 설치해야 합니다.
그렇다면 프로덕션 환경에서 설치할 때 32비트 설치를 사용하지 않는다면서 경고가 나타나는 이유는 무엇일까요? Exchange는 여러 가지 방식으로 컴파일하기가 상당히 쉽지만 각 구성 요소는 64비트에 대해서만 100% 최적화되고 조정됩니다. 64비트 시스템에서 디스크 I/O 기능을 개선하기 위해 선택했던 코드 경로 일부가 실제로는 32비트 환경에서 성능 저하를 가져오기도 합니다. 32비트로 사전 점검을 하려고 한다면 시뮬레이션이든 뭐든 Exchange가 별 무리 없이 실행될 것이라고 생각하지 마십시오. 현실적으로는 64비트 시스템에서 Exchange가 어떻게 작동할지 또는 얼마나 많은 사용자를 서버에서 처리할 수 있을지 알지 못할 것입니다.
모두 이해되셨나요? 32비트 버전의 Exchange 2007로는 다음과 같은 작업을 할 수 있습니다.
  • 사용 중인 사용자 사서함이 없는 테스트 서버에서 새 기능을 평가할 수 있습니다.
  • 새로운 관리 콘솔, 셸 또는 OWA 인터페이스를 살펴볼 수 있습니다. 그렇다고 이러한 기능에 너무 놀라지는 마십시오.
  • Exchange 2007 서버를 관리할 수 있습니다.
  • Active Directory 포리스트의 스키마를 확장할 수 있습니다.
사서함을 옮길 준비가 되면 서버에서 64비트 Exchange 2007이 설치된 64비트 운영 체제를 실행해야 합니다. 그렇지 않을 경우 설치 프로그램 및 ExBPA 때문에 번거로운 일이 많이 생길 것입니다(그림 3 참조). Paul은 이것이 빈말이 아니라는 것을 잘 압니다. 그가 바로 코드를 작성했으니까요!
그림 3 64비트만 지원되는 시스템에 32비트를 설치하려는 경우
그림 3 64비트만 지원되는 시스템에 32비트를 설치하려는 경우 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 64비트만 지원되는 시스템에 32비트를 설치하려는 경우
그림 3 64비트만 지원되는 시스템에 32비트를 설치하려는 경우 (더 크게 보려면 이미지를 클릭하십시오.)

질문: Exchange 2007을 실행하려면 메모리가 얼마나 필요합니까?
대답: 기본 설치에는 최소 1GB의 RAM이 필요합니다. 앞서 언급했듯이 서버 역할 중 일부는 메모리를 많이 필요로 합니다. 사서함, 클라이언트 액세스, Hub 전송 및 통합 메시징과 같은 통합 서버를 설치하려고 한다면 2GB의 RAM으로 시작해서 사서함의 수와 사용량에 따라 확장하는 것이 좋을 것입니다. Edge 역할 또는 클러스터를 설치하려고 한다면 이는 별도의 시스템에 설치해야 합니다. 클러스터에는 사서함 역할만 설치할 수 있습니다. 다른 역할은 설치할 수 없습니다.
드디어 Exchange Server에 4GB 이상의 RAM을 설치할 수 있다는 사실을 알면 기뻐하는 사람들이 많을 것입니다. 현재 시스템의 대다수는 6GB 또는 8GB가 표준이기 때문에 항상 울며 겨자 먹기 식으로 DDR(Double Data Rate) 모듈을 빼내거나 /BurnMemory를 사용하여 RAM을 4GB로 줄여야 했습니다. 더군다나 Exchange 2003의 경우 RAM이 4GB를 초과하면 성능과 안정성이 떨어집니다. 자세한 내용은 go.microsoft.com/fwlink/?LinkId=76537(영문)을 참조하십시오.
Hub, 클라이언트 액세스 등의 인프라 서버의 경우 RAM이 4GB 미만이어도, 심지어 부하가 최고조에 다다른 경우에도 괜찮습니다. 비용을 들여야 할 곳은 사서함 서버입니다. 새롭게 최적화된 이 64비트 JET 캐시는 메모리를 던져주는 대로 다 사용하려고 할 것입니다. 물론 Exchange 2003과 달리 Exchange 2007에서는 최고 50개의 저장소 그룹을 지원합니다.
각 저장소 그룹은 여러 개의 데이터베이스를 지원할 수 있지만 이러한 사실은 아무 도움도 되지 않습니다. 특히 LCR과 CCR(앞서 설명했던 두 가지 유형의 데이터베이스 복제)은 단일 데이터베이스가 있는 저장소 그룹에서만 작동할 수 있기 때문에 더욱 그렇습니다. 많은 수의 저장소 그룹을 만들 생각이거나 각 사용자마다 2GB 이상의 사서함을 제공할 꿈을 꾸고 있다면 반드시 이에 대한 RAM을 추가해야 할 것입니다. RAM 크기 지정에 대한 내용은 Exchange 팀 블로그(영문)에 자세히 나와 있지만 그림 4 및 5에서 참고 자료를 미리 확인하십시오.
Figure 5 RAM 및 저장소 그룹 (Close Figure 5)

실제 RAM | 최대 권장 저장소 그룹
2GB | 2
4GB | 8
8GB | 24
12GB | 40
16GB 이상 | 50
Figure 4 사용자 유형별 RAM (Close Figure 4)

사용자 유형 | 사서함 역할 메모리 권장 사항
소규모 | 기본 2GB + 사서함당 2MB
평균 규모 | 기본 2GB + 사서함당 3.5MB
대규모 | 기본 2GB + 사서함당 5MB
한편, Microsoft IT는 반복되는 백업 일정을 가지고 있지만 특정 날에는 그 중 일부 저장소 그룹만 백업하기 때문에 7의 배수로 된 많은 저장소 그룹을 사용합니다. 백업 일정이 나와 있는 Excel 스프레드시트에는 특정 날에 백업되는 저장소 그룹이 계단식으로 빨간색으로 표시되기 때문에 우리는 이 일정을 "지팡이 사탕 백업"이라고 부릅니다. 이번 칼럼이 도움이 되었기를 바랍니다. 다음 호에 실을 "진짜" 질문을 보내 주시기 바랍니다.

KC Lemson은 Exchange Server 팀의 선임 프로그램 관리자로서, 여유 시간에는 나이지리아 왕족의 자금 보호를 돕고 있습니다.
Paul Bowden도 Exchange Server 팀의선임 프로그램관리자로서, 주문이 있을 때마다 자신의 PayPal 계정 정보를 재확인하는 데 여유 시간의 대부분을 보냅니다.


 Security Watch: Windows Vista의 서비스 보안 강화
Security Watch
Windows Vista의 서비스 보안 강화
Wole Moses

Microsoft는 Windows 시스템을 파괴하고 IT 부서를 마비시키고 기업과 일반 소비자에게 막대한 복구 비용을 초래하며 악명을 떨친 여러 바이러스와 웜에 대응하여 2002년 초에 신뢰할 수 있는 컴퓨팅(Trustworthy Computing) 이니셔티브를 발표했습니다. 이 이니셔티브에 따라 Microsoft는
보안 문제에 대한 책임을 인정하고, 다양한 기능과 사용 편의성에 중점을 두는 쪽에서 보안과 무결성을 최우선으로 삼는 쪽으로 소프트웨어 개발 방향을 신속하게 선회했습니다. 2003년 8월을 강타한 Blaster 웜은 보안 이니셔티브에 한층 강한 동기를 부여했습니다. Blaster 웜에 대한 자세한 내용은 "클론의 습격" 추가 기사를 참조하십시오.
신뢰할 수 있는 컴퓨팅 이니셔티브는 보안을 고려한 코딩 방침을 강조하는 "디자인 단계부터 보안 적용", Windows® 구성 요소에 기본적으로 가장 안전한 설정을 적용하는 "기본적으로 보안 적용", 그리고 기업과 일반 사용자가 Windows 인프라를 안전하게 보호할 수 있도록 돕는 도구와 지침을 마련하는 것과 관련된 "배포 단계에서 보안 적용"으로 세분화될 수 있습니다.
신뢰할 수 있는 컴퓨팅 이니셔티브는 전반적인 보안 수준을 크게 향상시켰지만 Windows XP는 아쉽게도 이 이니셔티브가 시행되기 2년 전에 릴리스되었기 때문에 이러한 방침이 완벽하게 적용되지 않았습니다. Windows XP의 경우 서비스 팩 2(SP2)를 통해 이러한 철학의 많은 부분을 도입했지만 이니셔티브에 맞게 완전히 수정할 수는 없었습니다.
따라서 신뢰할 수 있는 컴퓨팅이라는 목표를 완벽하게 구현하는 Microsoft의 첫 번째 데스크톱 운영 체제는 바로 Windows Vista™입니다. 신뢰할 수 있는 컴퓨팅 이니셔티브 중 "기본적으로 보안 적용" 원칙(그림 1 참조)을 실제로 구현한 Windows Vista의 서비스 보안 강화는 현존하는 대부분의 맬웨어가 유발할 수 있는 악의적인 서비스 동작을 차단하도록 설계된 중요한 새 기능입니다. Microsoft는 서비스 보안 강화를 통해 Windows 서비스의 기본 동작과 보안 프로필을 변경하는 큰 변화를 실현했습니다.
Figure 1 기본적으로 보안 적용: Windows 서비스 (Close Figure 1)

기능 | 설명 | 결과
최소 권한 | Windows Vista 서비스가 실행에 필요한 최소 권한만 사용하도록 구성됩니다. | Windows Vista에서는 Windows 서비스가 사용할 수 있는 기본 보안 권한을 낮추어 맬웨어의 공격 가능성을 줄입니다.
서비스 격리 | 낮은 권한의 계정으로 서비스를 실행할 수 있도록 서비스 SID를 이용합니다. | Windows Vista에서는 서비스 SID를 기반으로 리소스에 대한 액세스를 제한하여 맬웨어를 차단합니다.
제한된 네트워크 액세스 | 모든 Windows Vista 서비스는 기본적으로 네트워크 제한 상태로 구현됩니다. | Windows Vista에서는 맬웨어가 서비스를 이용하여 부적절한 네트워크 작업을 수행하는 것을 차단합니다.
세션 0 격리 | 세션 0은 서비스용으로 예약됩니다. | Windows Vista에서는 높은 권한의 서비스가 동일한 세션에서 실행되지 않으므로 메시지 기반 공격을 통해 높은 권한의 서비스를 가로채려는 악의적인 응용 프로그램이 차단됩니다.

위험한 서비스
과거에 NT 서비스라고 불리던 Windows 서비스는 고유한 Windows 세션에서 장시간 실행되는 응용 프로그램입니다. 이러한 서비스는 컴퓨터를 부팅할 때 자동으로 시작하거나 일시 중지하고 다시 시작할 수 있습니다. 일반적으로 서비스에는 사용자 인터페이스가 없으며 로그온한 사용자나 기본 컴퓨터 계정과는 다른 계정의 보안 컨텍스트에서 실행할 수 있습니다. 특정 유형의 응용 프로그램을 개발하거나 해당 응용 프로그램을 사용해야 하는 최종 사용자에게 Windows 서비스는 매우 유용한 기능입니다. 그러나 Windows 서비스의 강력한 기능과 융통성은 다음과 같은 이유로 악용되는 경우가 많았습니다.
첫째, 과거에는 일반적으로 Windows 서비스가 권한이 높은 Windows 계정(예: 로컬 시스템 계정)으로 실행되었습니다. 로컬 시스템 계정으로 실행되는 서비스가 맬웨어에 의해 손상될 경우 맬웨어가 해당 시스템에서 거의 모든 작업을 실행할 수 있게 됩니다. 예를 들어 Windows XP의 Remote Procedure Call (RPC) 서비스의 경우 Windows XP SP2 이전에는 RPC 서비스가 로컬 시스템 계정에서 실행되었기 때문에 Blaster, Welchia와 같은 웜이 RPC 취약점을 악용하여 관리 작업을 수행할 수 있었습니다.
둘째, 많은 서비스가 네트워크에 연결되므로 맬웨어가 이를 악용하여 네트워크를 통해 해당 서비스에 대한 인바운드 연결을 만들거나, 감염된 서비스에서 아웃바운드 연결을 만들어 다른 시스템을 감염시키거나, 키보드 입력을 모니터링하여 전달하는 등의 불법적인 동작을 수행할 수 있습니다. 오늘날 대부분의 웜 및 맬웨어 감염은 네트워크 연결을 통해 이루어집니다.
마지막으로, 서비스는 시스템이 부팅될 때부터 종료될 때까지 오랜 시간 실행되는 경우가 많습니다. 맬웨어 작성자에게 이러한 점은 시스템이 실행되는 동안에는 항상 서비스에 결함이 있는지 조사할 수 있으며 악의적인 활동을 수행할 충분한 시간이 있음을 의미합니다.

클론의 습격
이것은 엄청난 재앙을 가져올 수 있었습니다. 모든 것이 계획대로 되었다면 곧 전 세계 수십만 대의 Windows 시스템을 장악하여 어떤 명령이라도 지시한 다음 명령이 순조롭게 실행되는 것을 느긋하게 앉아 감상할 수 있었을 것입니다.
공격자는 끈질기면서도 교묘한 방법으로 은밀하게 여러 컴퓨터 시스템을 조사하여 취약한 진입점을 찾는 것부터 시작했습니다. 하지만 원하는 것을 찾는 데는 오랜 시간이 걸리지 않았습니다. 알려진 취약점에 대해 패치가 적용되지 않은 시스템이 공격 목표입니다. 이 취약점을 공략하는 방법은 익히 알고 있습니다.
이러한 종류의 취약점이 더욱 매력적으로 다가오는 이유는 이 취약점을 제대로 이용하면 시스템에 대한 모든 관리 권한을 얻을 수 있기 때문입니다. 이것은 단순히 한 계정을 제어하는 것을 넘어 Windows에서 가장 강력한 관리 계정을 조작할 수 있다는 의미였습니다. 그 이후부터는 모든 것을 마음대로 하면 됩니다.
잠시 숙고의 시간을 가진 후 공격자는 패치가 적용되지 않은 취약한 컴퓨터를 대상으로 자신의 공격 코드를 테스트했습니다. 결과는 성공적이었고 너무도 쉽게 컴퓨터에 대한 무제한적인 권한을 얻게 되었습니다. 이렇게 얻은 관리 권한을 통해 트로이 목마 코드를 다운로드하여 컴퓨터에 설치하고, 레지스트리를 수정한 후 다시 부팅함으로써 감염된 시스템이 언제라도 자신의 명령을 수행할 수 있는 상태가 되도록 만들었습니다. 레지스트리 수정으로 인해 컴퓨터를 다시 시작할 때마다 맬웨어가 실행되었습니다.
이제 목표는 분명해졌습니다. 감염된 컴퓨터로 네트워크에 있는 다른 모든 컴퓨터의 특정 네트워크 포트를 탐지하여 해당 네트워크 포트가 열려 있고 컴퓨터가 취약하면 새로운 대상 컴퓨터에 트로이 목마 코드를 다운로드하고 설치하는 것입니다. 레지스트리가 똑같은 방법으로 수정되었습니다. 이러한 과정이 모든 컴퓨터에서 반복되므로 클론 부대는 기하급수적으로 늘어났습니다. 하루가 끝날 무렵 지구상의 수천 대의 Windows 시스템이 공격자 이외에는 누구의 명령도 따르지 않는 클론 부대에 합류하게 되었습니다.
그것으로 충분하지 않았는지 공격자는 Microsoft Windows Update 사이트로 관심을 돌렸습니다. 전 세계 어디에 있는 컴퓨터도 취약점 수정 프로그램을 다운로드하지 못하도록 클론 부대에게 2003년 8월 15일 Microsoft Windows Update 사이트에 대한 DoS(서비스 거부) 공격을 가하도록 지시했습니다. 재미있는 것은 이 취약점 수정 프로그램은 이미 수 개월 전부터 공개되어 있었다는 것입니다.
이제 필자가 2003년 8월 전 세계의 Windows 컴퓨터를 강타한 MS Blaster 웜 감염 사건을 설명하고 있다는 것을 깨달았을 것입니다. 수십억 달러의 손실을 초래한 Blaster가 Windows 역사상 가장 심각한 공격 중 하나였다는 것을 부정할 사람은 없을 것입니다. 아이러니한 사실은 MS Blaster가 감염된 컴퓨터를 강력하게 제어했지만 실제로 구현된 내용은 대단히 단순했다는 것입니다.

Blaster 작동 방식
Blaster와 그 파생 프로그램은 Windows RPC 서비스의 취약점을 이용하여 버퍼 오버플로를 유도합니다. 이 취약점 공격에 성공한 공격자는 감염된 시스템에서 로컬 시스템 권한으로 코드를 실행할 수 있기 때문에 프로그램 설치, 데이터 보기, 변경 및 삭제, 모든 권한이 있는 새 계정 만들기 등 원하는 모든 작업을 수행할 수 있게 됩니다.
Blaster 웜은 자동으로 네트워크를 스캔하여 TCP 포트 135가 열려 있는 컴퓨터를 찾습니다. 대상이 발견되면 RPC 취약점 공격을 시도합니다. 공격이 성공하면 대상 컴퓨터의 포트 4444에 연결하여 TFTP(Trivial File Transfer Protocol)를 실행한 후 감염된 시스템에서 MSBLAST.EXE라는 웜 복사본을 다운로드하도록 지시합니다. TFTP는 Windows 2000, Windows XP 및 Windows Server 2003 운영 체제에 포함되어 있는 프로토콜입니다. 계속해서 공격 시스템은 새로 감염된 시스템에 MSBLAST.EXE를 시작하도록 지시하고, 대상 컴퓨터는 새로운 공격 컴퓨터가 됩니다. 또한, 블래스터는 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \Windows\CurrentVersion\Run 레지스트리 키를 수정하여 컴퓨터를 다시 시작할 때마다 자신이 실행되도록 만듭니다.

서비스 보안 강화
Windows Vista의 서비스는 네 가지 방식으로 보안이 강화되었습니다. 즉, 최소 권한으로 서비스 실행, 서비스 격리, 제한된 네트워크 액세스 및 세션 0 격리가 그것입니다. 계속해서 각 항목에 대해 자세히 설명하겠습니다.
최소 권한으로 실행 이전에는 많은 Windows 서비스가 Windows의 가장 강력한 계정인 로컬 시스템 계정의 컨텍스트에서 실행되었습니다. 로컬 시스템 계정에는 거의 모든 시스템 개체나 다른 사용자 프로필에 액세스할 수 있으며, 사용자를 가장하고, HKLM\SECURITY와 같은 중요한 레지스트리 키를 열고, 원격 서버에 컴퓨터의 자격 증명을 제공하는 등의 작업을 수행할 수 있는 사용자 권한이 있습니다. 맬웨어 작성자가 원하는 것은 Windows에 대한 이러한 수준의 액세스와 제어이므로 로컬 시스템 보안 컨텍스트에서 실행되는 서비스가 공격자의 좋은 목표가 되는 것은 당연합니다.
다수의 Windows 서비스가 로컬 시스템 계정으로 실행되도록 구성되어 있지만 그 중 상당수는 로컬 시스템 계정의 고유 권한 중 일부분만 필요로 합니다. 아쉽게도 Windows XP와 그 이전 버전의 Windows는 "전부 아니면 없음" 방식으로 작동하기 때문에 필요한 권한을 선택적으로 고르는 메커니즘이 없습니다. 따라서 많은 Windows 서비스는 불가피하게 과도한 보안 권한으로 실행되게 됩니다.
Windows Vista 서비스 보안 강화는 서비스 구성에 대한 최소한의 권한 개념을 도입하여 이 문제를 해결합니다. 최소 권한을 사용하면 로그온한 계정에 지정된 모든 기본 권한을 사용하여 서비스를 실행하는 대신에 기능 사용에 필요한 최소한의 권한으로 서비스를 실행할 수 있습니다.
예를 들어 운영 체제의 일부로 작동해야 하지만 보안 토큰을 만들 필요가 없는 서비스가 있을 수 있습니다. 최소 권한을 사용하면 토큰 만들기 권한을 제거할 수 있습니다. 결과적으로 서비스가 향후 공격에 취약해지더라도 공격자가 가할 수 있는 손상 범위를 줄일 수 있습니다. 개발자는 SC.exe(그림 2 참조)와 같은 명령줄 도구를 사용하거나 프로그래밍 방식을 사용하여 특정 서비스에 필요한 권한을 정의하고 지정할 수 있습니다. 기본적으로 Microsoft에서는 최소 권한을 적용하여 사전에 설치되는 모든 Windows Vista 서비스의 기본 권한을 제한합니다.
그림 2 Windows Vista 서비스 권한을 정의하는 SC 명령 옵션
그림 2 Windows Vista 서비스 권한을 정의하는 SC 명령 옵션 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 Windows Vista 서비스 권한을 정의하는 SC 명령 옵션
그림 2 Windows Vista 서비스 권한을 정의하는 SC 명령 옵션 (더 크게 보려면 이미지를 클릭하십시오.)
서비스 격리 Windows Vista 이전의 Windows 버전에서는 서비스가 중요 레지스트리 키나 파일 같이 권한이 필요한 개체에 액세스할 때 로컬 시스템 계정을 사용하여 개체에 액세스하거나, 레지스트리 키나 파일의 보안 수준을 낮추어 낮은 권한의 서비스 계정으로 액세스할 수 있게 만들거나, 서비스용으로 계정을 만들어 해당 계정으로만 개체에 액세스할 수 있게 하는 세 가지 방식을 통해 액세스 권한을 얻습니다.
이러한 방식은 모두 잘 동작하지만 기본적으로 문제가 있습니다. 처음 두 방법은 위험이 내재되어 있고 마지막 방법은 새 계정의 암호를 수동으로 관리해야 하는 부담이 있습니다.
예를 들어 바이러스 백신 프로그램이 바이러스 백신 소프트웨어와 관련한 바이러스 서명 파일과 레지스트리 항목 등 여러 중요한 시스템 개체에 액세스해야 하는 서비스를 설치한다고 가정해 봅시다. 바이러스 백신 서비스가 로컬 시스템 계정을 사용하거나 다른 기본 제공 보안 계정을 사용하여 해당 개체에 액세스하도록 구성되어 있는 경우 해당 계정을 사용하는 다른 Windows 서비스가 맬웨어에 감염되면 해당 맬웨어가 바이러스 백신 서명 파일에 액세스하여 수정하거나, 바이러스 백신 소프트웨어가 작동하는 방식에 영향을 주는 레지스트리 설정을 변경하거나, 바이러스 백신 서비스를 종료할 수 있는 위험이 있습니다. 실제로 최근의 맬웨어는 이러한 방법 중 몇 가지를 사용하여 자신을 은폐한 채로 작동합니다.
Windows Vista는 서비스 격리를 통해 이러한 보안 및 관리 효율성 문제를 해결합니다. 서비스 격리를 사용하면 서비스 보안 식별자(SID)가 들어 있는 액세스 제어 항목으로 파일이나 레지스트리 키 액세스 등의 리소스를 보호함으로써 서비스가 개체를 독점적으로 사용하도록 예약할 수 있습니다. 따라서 예제에서 설명한 바이러스 백신 서비스는 낮은 권한의 계정으로 실행될 수 있지만 중요한 서명 파일이나 레지스트리 키에 계속 액세스할 수 있게 됩니다. 이러한 액세스가 가능하도록 낮은 권한의 계정으로 실행되는 바이러스 백신 서비스에 Windows Vista가 부여한 SID가 지정됩니다. SID가 지정되면 바이러스 백신 프로그램이 해당 파일 시스템과 레지스트리 개체의 액세스 제어 목록(ACL)을 수정하여 바이러스 백신 서비스에 대한 독점적인 액세스 권한을 부여할 수 있습니다.
또 다른 예가 있습니다. 2003년의 Welchia 웜은 RPC 취약점을 이용하여 자신을 %System%\Wins\Dllhost.exe로 복사합니다. 또한 감염된 Windows 시스템에 자신을 서비스로 설치하기 위해 HKLM\SYSTEM\CurrentControlSet\Services에 키를 추가합니다. 그러나 Windows Vista에서는 두 위치 모두에 대한 액세스를 특정한 관련 서비스로 제한하며 낮은 권한의 계정을 통해 이러한 서비스의 액세스 권한을 지정하므로 Welchia 웜이 작동할 수 없습니다.
제한된 네트워크 액세스 Windows Vista에는 Windows XP SP2 방화벽이 제공하는 기능을 바탕으로 구축된 새로운 방화벽이 포함되어 있습니다. 새로운 주요 기능으로는 아웃바운드 필터링과 IPsec 통합이 있습니다. 또한 새로운 방화벽은 Windows Vista 서비스 보안 강화와의 통합을 통해 취약한 Windows 서비스를 이용하여 실행되는 맬웨어가 부적절한 네트워크 동작을 수행하기 더욱 어렵게 만듭니다.
Windows Vista 방화벽에서 Windows 서비스에는 서비스 동작에 대한 제한과 한계를 지정하는 네트워크 방화벽 정책이 적용됩니다. 예를 들어 네트워크 포트를 통해 통신할 필요가 없는 플러그 앤 플레이와 같은 서비스에는 "네트워크 액세스 없음" 제한이 지정될 수 있습니다. 이 제한이 지정된 경우 플러그 앤 플레이 서비스를 대상으로 하는 공격은 네트워크를 통해서는 이 서비스에 도달할 수 없습니다. 이렇게 제한된 서비스를 이용하는 모든 인바운드 또는 아웃바운드 통신 시도는 방화벽에서 차단됩니다. 네트워크에 액세스해야 하는 다른 서비스도 특정 포트만 사용하도록 구성할 수 있습니다. 개발자는 이 기능을 사용하여 특정 서비스의 네트워크 액세스를 제한할 수 있습니다.
네트워크 제한 기능은 서비스 보안 강화와 결합되어 잠재적인 서비스 기반 공격에 대해 강력한 방어벽을 구축합니다. 이것은 이전 버전의 Windows에 비해 크게 향상된 기능입니다. 이전에는 Windows가 네트워크를 통해 통신하는 방법, 위치 및 허용된 서비스를 결정할 방법이 없었습니다. 그러나 Windows Vista 방화벽의 RPC 서비스에 대한 네트워크 제한을 사용함으로써 Blaster, Sasser, Welchia와 같은 바이러스가 감염된 서비스를 사용하여 다른 컴퓨터와 통신하는 것을 차단할 수 있습니다.
세션 0 격리 Windows XP의 빠른 사용자 전환은 각 사용자에게 별도의 Windows 세션을 제공함으로써 여러 사용자가 동시에 로그온할 수 있게 해 줍니다. 시작 시 세션 0이 만들어지고 필요에 따라 다른 세션이 추가됩니다. 서비스는 항상 세션 0에서 실행되며 Windows Vista 이전에는 사용자 응용 프로그램도 세션 0에서 실행될 수 있었습니다. 하지만 사용자 응용 프로그램과 Windows 서비스를 동일한 세션에서 실행하는 경우 높은 권한에서 실행되는 서비스가 권한을 높일 수단을 찾고 있는 악의적인 소프트웨어의 공격 목표가 될 수 있기 때문에 보안상의 위험이 있습니다.
Windows Vista의 경우 세션 0에는 서비스만 실행되고, 응용 프로그램은 다른 세션에서 실행되며, 세션 0을 비대화형(대화 상자나 프롬프트와 같이 최종 사용자가 액세스할 수 있는 사용자 인터페이스를 서비스가 만들지 않음)으로 만들어 이러한 문제를 해결합니다. 이러한 변화로 인해 세션 0 격리는 Windows 서비스나 드라이버를 개발하는 개발자의 응용 프로그램 호환성에 영향을 미칩니다.

요약
Windows Vista는 Microsoft의 신뢰할 수 있는 컴퓨팅 이니셔티브가 완벽하게 반영된 최초의 데스크톱 운영 체제이며 기능이 대폭 향상되어 Windows 사용자 보호에 상당한 진전을 가져옵니다. 물론, 컴퓨터 보안은 계속 발전하고 있는 분야이며 맬웨어 작성자가 Windows를 공격할 새로운 방법을 찾고 탐색하고 연구하리라는 것은 자명합니다. 그러나 Windows Vista의 새로운 서비스 보안 강화 기능은 기본 보안 설정을 향상시키고 잠재적인 공격 대상 지점을 최소화함으써 방어벽을 상당히 높였습니다. 이러한 향상된 기능에 대한 자세한 내용은 microsoft.com/whdc/system/vista/Vista_Services.mspx(영문)를 참조하십시오.

Wole Moses는 Microsoft Regional Windows Lead이며 8년 경력의 Microsoft 전문가입니다. 현재 터키 이스탄불에 거주하는 Wole는 중동과 아프리카 지역의 가장 큰 신흥 시장에서 고객이 IT 인프라를 최적화하는 동시에 보안을 강화하는 Microsoft 기반 솔루션을 구상하고 설계할 수 있도록 돕고 있습니다.


 The Desktop Files: Windows Automated Installation Kit
The Desktop Files
Windows Automated Installation Kit
Wes Miller

Microsoft는 지금까지 Windows 배포 팀에서 만든 두 가지 버전의 배포 도구를 제공해 왔습니다. 첫 번째 버전은 deploy.cab 파일의 형태로 수년간 Windows CD에 실려 제공되어 왔습니다. 여기에는 무인 설치 파일을 만드는 데 사용되는 설치 관리자 등의 도구와 설명서가 포함되어 있었습니다.
또한 여기에는 데스크톱 배포를 준비하기 위해 사용되는 Sysprep 도구도 포함되어 있었습니다. 다른 버전의 배포 도구는 OPK(OEM 사전 설치 키트)로서, 특히 OEM 시스템 제조업체의 필요에 맞게 제작되어 해당 업체에만 제공되었습니다. 이 방식이 초기에 Windows® PE가 배포되었던 방법입니다. Windows Vista™용으로 나온 새 OPK 버전이 있기는 하지만 종전과 같이 OEM에게만 제공될 예정입니다.
하지만 다행히도, Windows XP 시기에 Windows PE를 구입할 수 없었던 Microsoft 고객을 비롯한 대부분의 다른 Microsoft 고객들은 WAIK(Windows Automated Installation Kit)라는 OPK와 비슷한 도구를 사용할 수 있을 것으로 보입니다. WAIK는 Windows Vista 출고 후 microsoft.com/downloads에서 무료로 다운로드할 수 있으며 여기에 포함될 구성 요소로는 Windows PE 2.0, WDS(Windows 배포 서비스), ImageX 및 Windows 시스템 이미지 관리자(이전에 언급한 적은 없지만 unattend.xml 파일을 만들어 설치를 자동화할 수 있는 도구)가 있습니다. 또한 모든 도구에 대한 전체 설명서도 포함됩니다.
WAIK를 구할 때는 www.microsoft.com/korea/technet/desktopdeployment/default.mspx에서 정식 BDD(Business Desktop Deployment Solution Accelerator)를 다운로드하는 것이 좋습니다. 여기에는 WAIK뿐만 아니라 USMT(사용자 상태 마이그레이션 도구)와 ACT(응용 프로그램 호환성 도구 키트)까지 포함되어 있습니다. BDD에는 성공적인 Windows Vista 배포를 위한 추가 도구와 지침도 들어 있습니다.

Windows PE 2.0
Windows PE 2.0에 대해서는 TechNet Magazine 2006년 11월호에서 상당히 깊이 있게 다루었으므로 여기서는 너무 자세히 들어가지 않겠습니다. 다만 WAIK가 Windows Vista용 새 Windows PE 빌드의 공식 릴리스를 제공할 것이라는 점만 짚고 넘어가겠습니다. WAIK의 다른 모든 도구는 어떤 측면에서 Windows PE를 사용하거나 Windows PE를 가지고 작업하기 때문에 Windows PE를 잘 알아 두는 것이 중요합니다. Windows PE 2.0에 대한 제 글은 여기에서 찾을 수 있습니다. .

ImageX
지난 칼럼에서는 WIM(Windows 이미징) 파일 형식을 다루는 데 상당한 시간을 할애했습니다(www.microsoft.com/technet/technetmag/issues/2006/12/desktopfiles(영문) 참조). 이번 칼럼에서는 작지만 강력한 명령줄 도구로서 Windows Vista의 기본 제공 이미징을 가능하게 하는 ImageX에 대해 살펴보겠습니다. 당초 ImageX를 계획할 때는 GUI 기반 도구를 만들려고 했지만 중요한 요소가 이미징 프로세스의 자동화였기 때문에 명령줄에 초점을 맞추기로 결정했습니다. ImageX의 명령줄 옵션은 그림 1을 참조하십시오.
그림 1 실행 중인 ImageX 명령줄 도구
그림 1 실행 중인 ImageX 명령줄 도구 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 실행 중인 ImageX 명령줄 도구
그림 1 실행 중인 ImageX 명령줄 도구 (더 크게 보려면 이미지를 클릭하십시오.)
나중에 설명할 WDS(Windows 배포 서비스)도 손쉽게 이미지를 캡처할 수 있는 간편한 GUI 도구를 제공하지만 ImageX 기능을 완벽하게 제공하지는 않습니다. ImageX는 Windows PE에서 배포할 이미지를 캡처하도록 설계되고 테스트되었다는 사실을 알아두는 것도 중요합니다. ImageX는 실행 중인 Windows 시스템의 이미지를 “실시간”으로 캡처하도록 설계되지는 않았습니다.
다른 시스템의 이미징 도구에 익숙하다면 ImageX도 어느 정도 익숙할 것입니다. ImageX는 이미지를 간단히 캡처하고 적용할 수 있도록 사용하기 쉽게 설계되어 있으면서도, 과거에 많이 사용되었던 배포 도구에서 빠졌거나 완벽하게 지원하지 않았던 중요한 기능을 가지고 있습니다. 뒤에서 잠깐 다루겠지만 일단 한 가지 예로서, 이미지를 로컬 파일 시스템의 일부로 쉽고 투명하게 탑재하여 기존 이미지 내에서 파일을 보거나 수정하거나 삭제할 수 있다는 점을 들 수 있습니다.
ImageX는 그림 2와 같은 이미지 조작 스위치를 제공합니다. 구체적인 명령 몇 개를 골라 좀 더 깊이 있게 설명해 보겠습니다.
Figure 2 이미지 조작 스위치 (Close Figure 2)

스위치 | 설명
IMAGEX /APPEND | 기존의 볼륨 이미지가 이미 포함되어 있는 WIM 파일에 새 볼륨 이미지를 추가합니다.
IMAGEX /APPLY | 파티션을 나누고 포맷한 볼륨에 볼륨 이미지를 적용합니다.
IMAGEX /CAPTURE | 최초의 볼륨 이미지를 WIM 파일에 캡처합니다.
IMAGEX /DELETE | WIM 파일에서 볼륨 이미지에 대한 참조를 영구적으로 삭제합니다. 이는 메타데이터를 삭제하는 것이므로 압축된 파일 데이터는 제거되지 않습니다. 데이터를 완전히 제거하려면 /export 스위치를 사용하여 완전히 새로운 WIM을 만들어야 합니다.
IMAGEX /DIR | WIM 파일에서 지정된 볼륨 이미지의 디렉터리 트리를 표시합니다.
IMAGEX /EXPORT | 하나의 WIM 파일 또는 여러 SWM(Split WIM) 파일에서 볼륨 이미지를 내보냅니다.
IMAGEX /INFO | 특정 볼륨 이미지 또는 WIM 파일에 대한 세부 정보를 표시합니다. Windows PE가 포함된 특정 볼륨 이미지에 대해 /boot 옵션을 설정할 수도 있습니다. Windows PE만 WIM 파일에서 부팅할 수 있습니다.
IMAGEX /SPLIT | 하나의 WIM 파일을 하나 이상의 더 작은 SWM 파일로 분할하여 여러 CD 또는 DVD에 저장할 수 있습니다.
캡처 명령은 비교적 명확합니다. WIM당 한 번만 캡처를 사용한다는 것만 기억하면 됩니다. WIM 파일은 그냥 파일 캡처이기 때문에 전체 볼륨(C:)이나 디렉터리(C:\Test)만도 캡처할 수 있습니다. 응용 프로그램도 마찬가지입니다. 이미지를 디렉터리에 적용할 수도 있고(전체 볼륨을 캡처한 경우도 마찬가지), 더 흔한 경우로 볼륨의 루트에도 적용할 수 있습니다. WIM에 이미 단일 볼륨 이미지가 존재하면 추가 명령을 사용하여 WIM에 추가하면 됩니다. 적용 명령도 비교적 명확하지만 여러 WIM 파일을 적용하는 경우에만 복잡해집니다. 삭제 명령은 특정 볼륨 이미지에 대한 참조를 제거할 경우 유용하지만 해당 이미지에서 데이터를 완벽하게 제거하려면 내보내기를 사용하여 데이터가 전혀 들어 있지 않은 새 WIM을 만들어야 합니다. 다시 말하면, 남아 있는 데이터를 제거하여 이미지 크기를 줄이려는 경우에는 내보내기를 사용해야 합니다. 내보내기는 하나의 볼륨 이미지를 하나 이상의 WIM 파일로 엮거나 그 자체로 완벽한 독립 실행형 WIM 파일로 내보내는 조합 또는 통합 도구라고 생각하면 쉽습니다. ImageX는 IMAGEX /MOUNT, IMAGEX /MOUNTRW, IMAGEX /UNMOUNT와 같은 이미지 편집 스위치도 제공합니다.
앞서 언급했듯이 제품 팀은 아주 초기 단계부터 편집 기능을 이미지 도구와 형식에 통합하였습니다. 편집이 가능하기 때문에 고객들은 형식과 도구를 사용하여 파일을 복사하거나, 서비스 팩을 적용하거나, 파일이나 독립 실행형 응용 프로그램을 추가/제거하거나, 또는 필요에 따라 이미지에서 다른 데이터를 추가/제거할 수 있습니다. 심지어 레지스트리 탑재 및 수정도 가능합니다. 이미지 서비스는 항상 중요한 문제였습니다.
이미지를 탑재하는 것은 WIM 파일을 가상 디렉터리로 로드하는 것이라고 생각하면 됩니다. 이 기능에 익숙하다면 좀 더 쉽게 유추해 볼 수 있는 예로 볼륨 탑재 지점을 들 수 있는데, 이는 전체 볼륨을 다른 볼륨에 존재하는 디렉터리에 탑재하는 것입니다. 이 경우, 예를 들면 F: 드라이브가 C:\DriveF로 보입니다. 비슷한 예로, Microsoft® Virtual CD 도구나 다른 ISO 탑재 도구를 사용하여 ISO(CD) 이미지를 로컬 드라이브로 탑재해 본 적이 있을 것입니다. 이와 동일한 방식으로 ImageX에서도 WIM 파일을 디렉터리 위에 탑재할 수 있습니다. 먼저 디렉터리를 만든 다음 탑재 명령을 사용하여 지정된 볼륨 이미지를 디렉터리에 적용하는 것처럼 디렉터리 위에 탑재합니다.
그러나 가상 CD 도구와 달리 WIM 이미지가 공유 네트워크에 있거나 이동식 미디어에 있을 때도 WIM 이미지를 탑재할 수 있습니다. 물론 이 경우 편집 기능이 제한될 수 있습니다. 한 예로, 옵티컬 미디어(CD 또는 DVD)의 WIM은 일반적으로 읽기 전용 모드에서 편집이 가능합니다. 또한 읽기/쓰기 모드에서 편집하는 경우 WIM의 볼륨 이미지는 한 번에 하나만 편집할 수 있습니다. 이는 이미지를 분리할 때 파일을 적절하게 잠그고 안전하게 업데이트하기 위해서입니다.
이미지는 읽기 전용(/mount) 또는 읽기/쓰기(/mountrw)로 탑재할 수 있습니다. 읽기/쓰기를 사용하면 이미지 수정 사항이 일시적으로 캐시되지만 다시 말해, 즉시 적용되지 않지만 /commit 옵션과 함께 /unmount 명령을 실행하면 이러한 변경 사항이 WIM에 영구적으로 보존됩니다. 이미지를 변경한 후 이를 보존하지 않으려면 이미지를 분리할 때 변경 사항을 커밋하지 않고 버리면 됩니다. 여기에는 타협의 여지가 없습니다. WIM 파일이 탑재된 동안 이미지에 작성한 모든 내용은 커밋되거나 버려집니다.
단, 여기에는 주의해야 할 사항이 있습니다. 삭제 명령과 마찬가지로, 읽기/쓰기 기능을 사용하여 WIM을 편집하면 WIM 파일 자체의 파일 데이터는 완전히 지워지거나 삭제되지 않습니다. 즉, 파일들은 WIM 파일 끝에 추가되고 볼륨 이미지에 있던 이전 참조는 업데이트된 데이터로 대체됩니다. 다시 말해서 5MB의 새 파일을 추가하여 기존의 5MB 파일을 대체하면 이미지는 압축된 후 5MB 파일 크기만큼 커집니다. 사용된 압축 유형에 따라 5MB 이하가 될 수도 있습니다. 이전 데이터를 WIM에서 제거하려면(이미지를 축소하려면) /export를 사용하여 완전히 새로운 WIM 파일로 볼륨 이미지를 내보내야 합니다.
TechNet Magazine 2006년 11월호에서 Windows PE 2.0에 대해 쓴 제 글을 읽었다면 Windows PE 2.0이 WIM 부팅을 지원한다는 사실을 기억할 것입니다. 이렇게 하려면 ImageX처럼 드라이버를 사용하여 WIM 파일을 읽어야 합니다. 하지만 ImageX 지원은 디자인 단계에서 사용되도록 설계되었으며, WIM 부팅 기능은 특히 읽기 전용으로 Windows PE에서만 작동하도록 설계되었습니다. 따라서 이 둘이 비슷하기는 하지만 드라이버와 구현 방식은 다릅니다.
Microsoft는 ImageX 도구 외에 공식적으로 문서화된 WIMGAPI라는 API도 제공합니다. WIMGAPI를 사용하면 WIM 파일을 캡처, 적용 또는 수정하기를 원하는 모든 이미징 도구를 완벽하게 지원할 수 있습니다. 따라서 이미징 지원을 추가하거나 기존의 이미징 인프라를 대체하려는 타사가 있으면 WIMGAPI를 사용하여 이를 구현할 수 있습니다. 이 API는 WAIK의 일부이므로 WAIK와 함께 배포됩니다.

Windows 이미지 기반 설치
이미징 형식을 자유롭게 제어할 수 있는 새로운 설치 엔진이 설계되었습니다. 그 핵심 내용은 과거의 미니 설치나 Windows 시작과 매우 비슷합니다. 즉, install.wim의 이미지를 Windows 설치 DVD에 설치하기 전에 디스크 구성을 처리하면서 시스템을 고유하게 설정하고 구성하는 데 필요한 기본적인 질문을 합니다. 새로운 설치 엔진의 주요 목적은 Windows 수동 설치를 가능하게 하는 것이었습니다. 그러면 많은 OEM과 기업 고객들이 실제 배포에 ImageX를 사용할 것이라는 게 우리의 생각이었습니다.

원격 설치 서비스
이쯤 되면 왜 RIS(원격 설치 서비스)에 대해서는 언급하지 않느냐고 물을 수도 있습니다. RIS는 제가 Windows 배포 팀에서 일하기 시작했을 때 인계받은 일이기도 합니다. 처음에는 Windows 2000과 함께 제공되었다가 나중에 Windows Server® 2003에서 다시 제공된 RIS는 PXE(Pre-boot Execution Environment)를 사용하여 초기 마법사가 완료될 수 있는 지점으로 컴퓨터를 네트워크 부팅합니다. 그러면 Windows 설치가 모든 네트워크에서 이루어질 수 있습니다.
RIS의 가장 큰 문제점은 너무나도 취약하다는 것이었습니다. 처음에는 Windows 2000 Professional에서만 지원되었던 RIS의 Windows Server 2003 릴리스에서는 Windows 서버 버전에 대한 지원을 확대했습니다. SATA(Serial ATA) 저장 컨트롤러와 GB 이상의 NIC가 엄청난 속도로 밀려드는 상황에서 RIS를 통해 드라이버를 최신 상태로 유지한다는 것은 너무나 위험천만한 일이 되었습니다. 또한 RIS는 Windows가 지원하는 로캘의 대다수를 지원하지 않습니다. 다시 말해, 지역화된 키보드를 사용하여 지역화된 Windows 버전을 설치한다는 것이 불가능하진 않지만 어려울 수 있습니다. WDS(Windows 배포 서비스)는 Windows 설치와 RIS를 혼합하는 방식으로 설계되었습니다. 즉, PXE를 통해 Windows PE 부팅을 시작하여 네트워크에 WIM 파일을 배포하는 것입니다.
WDS는 곧 출시될 "Longhorn"이라는 코드명의 Windows Server 버전에서 사용할 수 있을 뿐만 아니라 Windows Server 2003에 설치할 수 있는 업데이트로도 사용할 수 있도록 설계되었습니다. 이 말은 WDS를 통해 이전 버전의 Windows도 배포할 수 있고 이전 버전의 Windows Server에서도 Windows Vista를 배포할 수 있다는 의미입니다. 사실 WDS는 RIS와 함께 사용할 수 있긴 하지만 RIS를 설치해야 작동합니다. 이는 WDS가 RIS 인프라를 WDS와 호환되도록 업데이트하면서 동시에 새로운 WDS 인프라도 제공하는 방식으로 작동하기 때문입니다.
WDS는 RIS를 업그레이드하므로 고객에게 좋은 마이그레이션 경로가 될 뿐 아니라 이전 버전의 Windows를 계속 사용하면서 Windows Vista를 배포할 수 있게 하는 도구입니다. 또한 과거 RIS가 제공했던 것보다 훨씬 훌륭한 관리 도구를 제공하므로 새로운 이미지를 보다 쉽게 서버에 추가할 수 있습니다. WDS는 또한 플러그형 PXE 프레임워크를 제공합니다. 따라서 타사 PXE 서버를 통합하여 WDS 대신 특정 클라이언트의 PXE 요청에 응답하도록 지정할 수 있습니다. 이는 RIS와 관련하여 자주 요구되었지만 당시에는 제공할 수 없었던 기능이었습니다.
원래 RIS를 업데이트할 목적으로 Windows Server 2003에 설치하는 구성 요소로 제공되었던 WDS는 Windows Server "Longhorn" 제품의 통합 구성 요소로도 제공될 예정입니다. Microsoft는 또한 향후 SMS(System Center Configuration Manager로 알려질 예정임) 버전에도 WDS 기능을 포함시킬 계획입니다.
WDS는 Windows PE 2.0의 PXE 부팅 버전을 제공하여 작동합니다. 이 이미지는 WIM에 포함되어 있으며(이 경우 네트워크를 통해 전송되는 데이터가 감소됨) 네트워크를 통해 RAMDisk로 부팅됩니다. 그런 다음 과거에 RIS의 초기 OSChooser 응용 프로그램에서 제공되었던 기능을 가진 새로운 클라이언트 응용 프로그램을 사용하여 Windows PE에서 설치가 이루어집니다.
WDS가 Windows XP, Windows 2000 또는 Windows Server 2003의 RIS 이미지 자체를 지원하지는 않지만 이들의 Sysprep 이미지는 배포할 수 있습니다. WDS는 또한 과거의 RIS처럼 Active Directory®에 통합되지만 필요한 경우 Active Directory 없이도 PXE 서버를 실행할 수 있습니다. WDS는 심지어 CD, DVD, UFD(USB 플래시 드라이브) 등 PXE 이외의 미디어에서 부팅된 Windows PE에서도 시작할 수 있습니다. 이는 RIS는 제공하지 못했던 유용한 기능입니다.
WDS는 기존의 RIS 사용 방식에 따라 세 가지 모드로 작동할 수 있습니다.
레거시 WDS 바이너리가 설치되지만, OSChooser가 부팅 메커니즘입니다. RISetup 및 RIPrep, RIS의 스크립트 설치 도구 및 이미지 기반 설치 도구는 그대로 작동합니다.
혼합 모드 두 가지 부팅 메커니즘을 모두 사용할 수 있고 두 가지 이미지 도구와 두 가지 관리 도구가 모두 작동합니다.
네이티브 RIS 기능이 없고 WIM 기능, Windows PE 부팅 및 새로운 관리 도구만 사용할 수 있습니다. Windows Server "Longhorn"에서는 이 모드만 제공할 예정입니다. 여기에는 RIS 기능이 포함되지 않습니다.
WDS는 또한 사용자 지정 클라이언트-서버 통신 프로토콜을 구현하므로 결과적으로 OEM이나 기업 고객은 이론적으로 자체 배포 응용 프로그램도 만들 수 있습니다.
WIM 이미지를 WDS 서버로 캡처하는 프로세스는 앞서 설명했던 Sysprep 시나리오와 거의 동일합니다. 차이점이 있다면 마지막 단계에서 WDS 캡처 이미지로 부팅한다는 것입니다. WDS 캡처 이미지란 사용자가 클라이언트 시스템을 캡처하여 WDS 서버로 캡처하도록 지원하기 위해 존재하는 Windows PE 이미지입니다.
WDS의 핵심 구성 요소는 WDS Server Service, PXE Server, 이미지 저장소, Communication Protocol, Windows PE 이미지(부팅될 이미지)와의 파일 공유, WIM 이미지(설치될 이미지), 그 밖에 관련된 관리 파일입니다.
WDS는 비교적 간단히 사용할 수 있고 기존의 옵티컬 미디어 기반 Windows 설치보다 종종 빠르기도 하지만 거의 동일한 과정을 제공하도록 설계되었습니다. RIS의 업데이트로 WDS를 구현하면 번거로운 절차 없이 RIS를 단계적으로 교체할 수 있을 뿐 아니라 Windows Vista를 쉽게 조직 내에 배포할 수 있습니다. 또한 RIS가 이전 버전의 Windows에 제공하던 것보다 빠르고 사용하기 쉬운 방식으로 이러한 과정을 처리합니다.

Windows 시스템 이미지 관리자
그림 3 Windows 시스템 이미지 관리자 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 Windows 시스템 이미지 관리자
그림 3 Windows 시스템 이미지 관리자 (더 크게 보려면 이미지를 클릭하십시오.)
왼쪽 위에 있는 배포 공유는 SIM을 통해 추가한 드라이버 및 다른 패키지가 표시되는 창입니다. 기본적으로는 배포 공유가 표시되어 있지 않지만 쉽게 열거나 만들 수 있습니다.
배포 공유 밑에 있는 Windows 이미지 창에는 WIM에 포함된 특정 Windows 볼륨 이미지에 있는 구성 옵션(구성 요소 및 패키지)이 표시됩니다. Windows의 볼륨 이미지는 한 번에 하나만(Windows Vista DVD에 있는 하나의 SKU) 탑재해야 한다는 점을 유념하십시오.
중앙에 있는 응답 파일 창에는 새로운 또는 기존의 Windows Vista 무인 설치 파일의 구성 옵션과 탑재한 WIM 볼륨 이미지의 카탈로그(가능한 설정 및 구성)에 정의된 기본 설정이 표시됩니다.
오른쪽 위에 있는 속성 창은 응답 파일 창에 표시된 구성 요소의 각 속성을 편집할 수 있는 창입니다.
마지막으로 아래쪽에 있는 메시지 창에는 Windows Vista 무인 설치 파일(항상 XML 형식)에 포함된 원시 XML, 유효성 검사 결과, 현재 사용하고 있는 구성 집합과 관련된 메시지 등 보다 자세한 피드백이 표시됩니다. 구성 집합을 열어 둔 경우 구성 집합 탭에는 데이터만 포함되어 있습니다.
지금까지 보았듯이 WAIK는 Windows Vista를 배포하는 데 유용한 매우 강력한 도구입니다. Windows 배포 팀은 과거의 어떤 Windows 버전보다 쉽게 Windows Vista를 배포할 수 있도록 다양한 도구를 개발하는 훌륭한 성과를 이룩해 냈습니다.

Wes Miller는 텍사스 오스틴에 있는 Pluck(pluck.com)에 근무하는 개발 관리자입니다. 이전에는 Winternals Software와 Microsoft에서 Windows 프로그램 관리자 겸 제품 관리자로 근무했습니다. Wes는 이번 칼럼을 작성하는 데 도움을 준 Microsoft의 Scott Dickens와 John Macintyre에게 감사의 뜻을 전했습니다. 문의 사항이 있으신 분은 technet@getwired.com으로 연락하시기 바랍니다.


 Field Notes: 처가 식구들에 대한 기술 지원
Field Notes
처가 식구들에 대한 기술 지원
James Snell

필자는 작년에 결혼했고 사랑스러운 아내를 얻은 대가로 처가 식구들과 기술 지원 계약을 맺어야 했습니다. 얼마 전 장모님으로부터 "자네 컴퓨터에 대해 잘 알지?"라는 무서운 전화를 받았습니다. 그래서 처가에 갔더니 장모님의 Windows® XP 시스템은 엄청난 양의 스파이웨어, 애드웨어, 도구 모음으로 몸살을 앓고 있었습니다.
여러분이 IT 전문가라면 컴퓨터를 고치는 일이 익숙할 것입니다. 하지만 친척들의 컴퓨터를 고치는 일은 그렇게 쉽지 않습니다. 감염된 시스템을 가장 빨리 고칠 수 있는 방법은 하드 디스크를 포맷한 후 Windows를 다시 설치하는 것입니다. 하지만 불행히도 사람들은 데이터를 잃고 싶어하지 않기 때문에 이 방법을 싫어합니다. 이 경우 오랜 시간 지루한 정리 작업을 해야 하는 경우가 많습니다. 하지만 시스템에 들어갈 수조차 없다면, 혹은 인터넷을 사용할 수 없다면 어떨까요?
여러분이 해야 할 일은 바이러스 및 스파이웨어 차단 프로그램, 개인 방화벽 소프트웨어를 포함한 도구 키트를 512MB USB 키에 함께 모아 두는 것입니다. 그리고 이 도구 키트를 최신 상태로 유지하고 사용하기 편리한 곳에 보관하십시오.
또한 Windows XP 서비스 팩 2(SP2)를 USB 드라이브에 저장해 두는 것도 좋습니다. 지금은 Windows XP가 SP2와 함께 제공되지만 장모님의 버전은 그 이전 것입니다. Windows XP SP2는 www.microsoft.com/technet/prodtechnol/winxppro/maintain/winxpsp2.mspx(영문)에서 다운로드하여 설치할 수 있습니다. 여러 컴퓨터에서 쓸 수 있는 버전을 이용할 수 있습니다. 단일 컴퓨터 설치 버전은 Windows Update를 이용합니다. 266MB라 빨리 다운로드하기 어렵지만 한 번만 다운로드하면 됩니다.
이제, 오후 내내 시스템을 포맷하고 OS를 설치하거나 고생스럽게 바이러스와 스파이웨어를 일일이 제거한 후 Windows에 필요한 소프트웨어 업데이트와 방화벽을 설치하고 바이러스 차단 정의를 업데이트하는 등의 작업을 했다고 합시다. 이제 무엇을 해야 할까요? 분명 매 주말마다 이런 일을 하느라 시간을 보내고 싶지는 않을 것입니다. 이러한 상황이 발생할 가능성을 줄이기 위해 취할 수 있는 몇 가지 단계가 있습니다.

정크웨어 제거
장모님의 시스템에는 유용한 소프트웨어에서 쓸데없는 소프트웨어에 이르기까지 주로 친구들이 설치해 준 소프트웨어가 가득했습니다. 이러한 상황이 재발하지 않도록 관리 계정을 강력한 암호로 잠그고 장모님을 표준 사용자로 설정했습니다. 사실 장모님은 관리 계정을 그렇게 자주 사용하지 않아도 됩니다. 이제 누군가가 무엇인가를 설치하려고 하면 관리자로 로그인해야 하기 때문에 이 정도면 차단 장치로 충분합니다. 여기에, 사용자가 조금만 알면 정크웨어를 차단할 수 있습니다. Get Safe Online(www.getsafeonline.org)을 방문하면 PC를 안전하게 보호할 수 있는 유용한 팁을 볼 수 있습니다.
장모님의 보안 요구 사항은 암호 면에서 달랐습니다. 장모님이 사용하기 편하도록 사용자 계정에 암호를 설정하지 않았습니다. 누군가 나쁜 사람이 컴퓨터에 손댈 기회가 있다면 컴퓨터에서 데이터를 훔쳐가는 것보다는 컴퓨터 자체를 훔쳐가리라고 생각했기 때문입니다.
컴퓨터 앞의 문 안쪽에 스티커를 붙여 놓는 것이 어리석은 짓일 수도 있습니다. 하지만 장모님이 몰래 관리자 암호를 사용한다고 해도 걱정할 일은 아닙니다. 결국 그것은 장모님의 컴퓨터니까 말입니다. 기업에서는 이러한 조치들을 좋은 방법으로 보지 않겠지만 장모님이 기밀 데이터를 가지고 있는 것은 아니므로 다른 사람들이 장모님의 시스템을 사용해도 걱정할 일은 아닙니다. 여기서 목적은 장모님이 컴퓨터를 쉽게 사용할 수 있게 하는 것이고, 더 중요한 것은 장모님의 기술 지원 엔지니어로서의 제 삶을 편안하게 하는 것입니다!

침입자 추방!
다음 단계는 약간의 추가 보안을 설정하는 것이었습니다. 방화벽을 Windows에 통합해도 타사 방화벽이 그대로 존재한다는 것은 참 다행입니다. 어쨌든...... 하나의 방화벽만으로는 안심할 수 없습니다. 보안을 강화하기 위해 장모님은 이제 방화벽이 통합되어 있는 ADSL 라우터를 사용합니다. 물론 여기에는 추가 비용이 들어가고 구성 및 실행 작업도 필요하지만 보안 수준은 한층 높아집니다. 게다가 깜빡이는 표시등이 있으니 얼마나 좋습니까?
하지만 라우터의 초기 구성이 안전할 거라고 생각하지는 마십시오. 저는 웹과 텔넷 인터페이스가 공개적인 측면에서 기본적으로 활성화되어 있는 쌍을 선택했습니다. 잠시 시간을 내어 고급 옵션을 확인해 보십시오.
소프트웨어 방화벽은 네트워킹 구성 요소가 활성화되어야 로드할 수 있습니다. 기본 제공 Windows 방화벽은 부팅 초기 단계에서 제공되는 유일한 보호 장치입니다. 시스템을 인터넷에 연결하기 전에 Windows SP2를 설치해야 하는 이유가 여기에 있습니다. Windows 방화벽을 비활성화해도 선택한 방화벽이 시작될 때까지 방화벽의 보호를 계속 받을 수 있습니다. 또한 라우터 방화벽이 설정되어 있다면 방화벽이 별도의 장치라는 이유로 비활성화될까 걱정하지 않아도 됩니다. 방화벽이 활성화되어 있지 않으면 인터넷에 연결되지 않은 것입니다. 이것은 데이터를 이중으로 보호하는 것과 같습니다. 공격이 성공하려면 라우터와 소프트웨어 방화벽이 동시에 작동하지 않아야 하기 때문입니다. 이것이 불가능한 것은 아니지만 성공 가능성은 낮습니다.

귀찮은 참견과 보호
백업만 제대로 해도 전체 프로세스가 얼마나 쉬워지는지 생각해 보십시오. 가장 중요한 정보조차도 백업하지 못한다고 말하는 사람들을 보면 참을 수가 없습니다. DVD 레코더와 미디어가 끔찍할 만큼 비싼 것도 아니고 Windows에도 백업 소프트웨어가 포함되어 있습니다. 문제는 너무나 많은 사람들이 그것을 사용하지 않는다는 것입니다. 제 장모님에게 드린 해결책은 My Documents 폴더를 규칙적으로 백업하고 파일을 곧바로 CD 굽기 폴더(%userprofile%\Local Settings\Application Data\Microsoft\CD Burning)에 저장하는 것이었습니다. 이 방법이 효과를 거두려면 사용자가 로그온했을 때만 예정된 작업이 실행되도록 해야 합니다. 그러면 사용자가 빈 디스크를 넣을 때까지 CD 굽기 마법사가 빈 디스크를 삽입하라는 메시지를 귀찮을 정도로 표시합니다. 이게 제가 원하는 것이지요.

지속적인 관리
Windows Live™ Messenger를 설치하면 데스크톱 공유를 구성할 수 있습니다. 다시 말해, 집에 돌아왔는데 설치해야 할 것이 생각났다면 다시 방문하는 것이 좋긴 하지만 그렇게 하지 않고도 현재 진행되고 있는 상황을 알 수 있습니다. 사실 원격 시스템을 통제하고(물론 권한이 필요하지만) 마우스의 움직임까지 볼 수 있다는 것은 라우터의 반짝이는 표시등보다 훨씬 멋진 일이지요!

James Snell은 이전에 영국에서 Microsoft 기술 지원 엔지니어로 일했으며 Microsoft에서 일반 사용자 및 전 세계의 대형 고객을 지원하는 업무를 담당해 왔습니다. James는 현재 아버지가 되는 새로운 기술을 익히는 중입니다. 문의 사항이 있으면 James.Snell@lineone.net으로 연락해 주십시오.


 Windows Confidential: DLL 지옥 탈출
Windows Confidential
DLL 지옥 탈출
Raymond Chen

DLL 지옥 이것은 너무나 함정이 많아 붙은 별명입니다. 어떤 프로그램을 설치했는데 갑자기 관련이 없어 보이는 프로그램이 작동을 멈춘 것을 본 적이 있을 것입니다. 사람들은 잘 모르지만 이는 두 프로그램이 공유 DLL 파일을 통해 연결되었기 때문입니다. 이와 같은 두 프로그램에서 어떤 버전의 MSVCRT.DLL 파일이 시스템 디렉터리에 있어야 하는지에 대해 각기 다른 설정을 가지고 있을 수 있습니다. 또는 첫 번째 프로그램이 두 번째 프로그램이 사용하는 ActiveX® 컨트롤을 업그레이드하여 두 번째 프로그램이 호환되지 않을 수도 있습니다.
두 프로그램 모두 회사에서 업무를 처리하는 데 중요하다면 어느 프로그램에 잘못이 있는지는 중요하지 않습니다. 중요한 것은 프로그램을 어떻게든 실행해야 한다는 것입니다. "비용 손실이 발생하고 있습니다."와 "김영수 과장 때문에 비용 손실이 발생하고 있습니다." 사이에는 큰 차이가 없습니다. 어느 쪽이든 회사에 비용 손실이 발생하고 있으므로 즉시 문제를 해결해야 합니다.
과거에는 이와 같은 경우 어떤 프로그램을 살리고 어떤 프로그램을 포기할지 선택해야 했습니다. 그러나 Windows® 2000부터는 이러한 충돌을 해결하는 데 사용할 수 있는 응급 조치가 지원되었습니다. 하지만 이러한 조치는 좀 더 영구적인 해결책을 찾을 때까지 시스템을 가동시키기 위한 일시적인 솔루션일 뿐입니다.
Windows 2000에는 현재 Dynamic-Link Library Redirection이라는 멋진 이름을 가지고 있는 솔루션의 초기 버전이 구현되었습니다. DLL을 리디렉션하기 위해서는 리디렉션할 DLL 파일이 있는 프로그램과 같은 이름의 파일을 만들고 이름 뒤에 .local을 추가해야 합니다. 예를 들어 C:\Program Files\Litware Inc\Invoice.exe에 리디렉션을 적용하려면 C:\Program Files\Litware Inc\Invoice.exe.local이라는 파일을 만듭니다. 파일의 내용은 중요하지 않습니다. 중요한 것은 그 파일이 존재한다는 것입니다.
프로그램에 리디렉션을 활성화하면 이 프로그램에서 DLL 파일을 로드하려고 시도할 때마다 평상시의 검색 위치를 찾기 전에 프로그램이 위치한 디렉터리를 먼저 찾습니다. 따라서 MSVCRT.DLL 파일이 충돌하는 경우 각 프로그램마다 리디렉션을 활성화하고 MSVCRT.DLL 사본을 각 프로그램의 설치 디렉터리에 넣으면 됩니다. 그러면 각 프로그램은 자신의 MSVCRT.DLL 버전(프로그램을 테스트할 때 사용한 DLL 버전)을 사용하게 됩니다.
이 기법의 매력은 프로그램이 전체 경로를 사용하여 DLL을 로드할 때도 작동한다는 것입니다. 예를 들어 프로그램이 C:\Program Files\Common Files\Proseware Inc\taxplugin.dll을 로드하려고 한다고 가정해 보겠습니다. Proseware 2.0으로 업그레이드한 다음부터 세금 플러그인이 구매 프로그램과 호환되지 않습니다. 이 경우 이전 버전의 세금 플러그인을 C:\Program Files\Litware Inc\taxplugin.dll에 복사하면 됩니다. 프로그램이 전체 경로를 사용하여 세금 플러그인을 로드해도 DLL 리디렉션은 현재 디렉터리를 검색해서 Proseware Inc 디렉터리에 있는 버전 대신 .local 버전을 사용합니다.
Windows XP 및 Windows Vista™에서는 DLL 리디렉션 규칙이 약간 다르긴 하지만 기본적인 원리는 같습니다. .local 파일뿐만 아니라 .local 디렉터리도 만들 수 있습니다. 이 경우 프로그램의 설치 디렉터리가 아닌 .local 디렉터리가 검색됩니다. 따라서 같은 디렉터리 내의 여러 프로그램에 충돌 없이 리디렉션을 적용할 수 있습니다.
그러나 응용 프로그램 매니페스트가 포함된 프로그램에는 리디렉션을 적용할 수 없으며 소위 알려진 DLL도 리디렉션에서 제외됩니다. 자세한 내용은 "Dynamic-Link Library Redirection(영문)"을 참조하십시오.
DLL 리디렉션만으로 DLL 지옥에서 완전히 빠져나올 수 있는 것은 아니지만 최소한 문제를 알아내는 동안이라도 상처를 돌보는 응급 수단으로 사용할 수는 있을 것입니다.
그림 1
그림 1

Raymond Chen은 자신의 웹 사이트인 The Old New Thing(영문)과 같은 제목의 책(Addison-Wesley, 2006)에서 Windows의 역사와 Win32 프로그래밍에 대해 적고 있습니다. 하지만 그에게 The Old New Thing이라는 이름의 고양이는 없습니다.