 TechNet Magazine February 2008

TechNet Magazine February 2008

Sharepoint: 엔터프라이즈 환경에서의 효과적 데이터 수집 방법

기업에서 정보는 가장 중요한 자산 중 하나입니다. 하지만 전자 메일, 웹 기반 양식, 설문 조사 등 수많은 방법을 통해 수집되는 엄청난 분량의 데이터를 관리하기는 쉽지 않습니다. Microsoft Office system을 활용하여 시스템을 통합하고 데이터에 쉽게 액세스할 수 있는 환경을 구축함으로써 이러한 관리 부담을 더는 방법을 알아봅니다.

Keith Deshaies Sharepoint: 강력한 설문 조사 인프라 구축

데이터의 수집과 분석은 업무의 필수적 요소이지만, 개별 팀에서 필요한 데이터를 필요한 때에 수집할 수 있는 도구가 필요합니다. WSS 3.0, MOSS 2007, InfoPath 2007 등을 이용하여 엔터프라이즈 전역에서 활용할 수 있는 철저하고 융통성 있는 설문 조사 솔루션을 구축하는 방법을 확인해 보시기 바랍니다.

Jim Bradley Sharepoint: 사용자 지정 콘텐츠 형식을 이용한 데이터 관리의 표준화

대규모 조직 전체에 저장된 엄청난 수의 이질적 문서와 다른 콘텐츠 항목들은 문서 및 그와 관련된 메타데이터 그리고 그 동작을 중앙 집중적이고 재활용 가능한 방식으로 관리하기 어렵게 만듭니다. SharePoint 2007의 콘텐츠 형식을 어떻게 활용하면 기업 전체에 흩어진 콘텐츠를 간단히 관리할 수 있는지 살펴보시기 바랍니다.

Pav Cherny Office Communications Server: 현재 상태 정보로 더욱 향상된 OCS 2007

Office Communications Server 2007은 사용자 현재 상태 정보를 기반으로 음성 호출, 화상 회의, 전자 메일 메시지, IM 등의 통신 유형에 따라 가장 적절한 위치로 통신을 라우팅합니다. 이 문서를 통해 OCS 2007 시스템의 상태 정보를 사용한 끝점 연결 방법을 살펴보십시오.

Rajesh Ramanathan Office Communications Server: OCS 2007 음성 배포 계획

Office Communications Server 2007을 기존 PBX 시스템과 통합하는 작업은 매우 복잡할 수 있습니다. 이를 위해서는 통합 시나리오를 선택하고 전화 라우팅에 대해 이해하고 사용자 설정 구성 방법을 파악하고 번호 사용 계획 등을 다루어야 합니다. 염려하지 마십시오. 이 개요 문서에서는 통합에 필요한 모든 정보를 제공합니다.

Jochen Kunert and Rui Maximo High Performance Computing: Windows Compute Cluster Server 소개

고성능 컴퓨팅에서는 대규모의 전문화된 시스템에 의존하는 대신 작고 표준화된 시스템의 클러스터를 이용합니다. 이 방법으로 작업 부하를 분산시키면 복잡한 문제를 경제적으로 빨리 해결할 수 있습니다. 여기서는 Windows Compute Cluster Server 2003에서 제공하는 계산 클러스터 기능 및 지원에 대해 알아봅니다.

John Kelbley and Doug Lindsey Online Extra: 터미널 서비스를 사용한 2007 Office system 배포

2007 Microsoft Office system에는 시스템을 터미널 서비스 서버 팜에 배포하기 전에 알고 있어야 할 많은 디자인 변경이 포함되어 있습니다. 이 문서에서는 이러한 변경에 대해 간략히 살펴봅니다.

James D. Silliman From the Editor: 정보 과부하에 대한 대응

Joshua Hoffman Letters: 독자의 목소리

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

Greg Steen SQL Q&A: 비클러스터형 인덱스 및 사용 권한 유지

Saleem Hakani and Dan Carollo Utility Spotlight: ADMX Migrator

Windows Vista에서는 그룹 정책 템플릿의 형식이 XML 기반 구조로 변경되었습니다. ADMX Migrator 유틸리티를 사용하면 사용자 지정 ADMX 파일을 쉽게 만들 수 있으며 레거시 ADM 파일을 새 ADMX 형식으로 변환할 수 있습니다.

Lance Whitney The Cable Guy: IEEE 802.1X 유선 인증

IEEE 802.1X 인증은 인트라넷 액세스를 제한하는 추가적인 보안 장벽을 제공합니다. Windows Vista 및 Windows Server 2008에서 유선 네트워크의 IEEE 802.1X 인증을 얼마나 쉽게 구현할 수 있는지 알아보십시오.

Joseph Davies Windows PowerShell: 셸 사용 권한

Windows의 사용 권한은 태생적으로 복잡하지만 다행히 Windows PowerShell의 도움을 받을 수 있습니다. Windows에서 사용 권한이 작동하는 방식을 개괄적으로 살펴보고 사용 권한 관련 작업을 단순화하는 방법을 알아보겠습니다.

Don Jones Hey, Scripting Guy!: 2008 Scripting Games 소식과 XML 정보!

2008 Scripting Games에 대한 이야기로 신이 난 Microsoft Scripting Guys가 XML 문서를 만들고 추가 및 수정하는 방법도 알려 줍니다. 그런데 참, 2008 Scripting Games 소식 들으셨어요?

The Microsoft Scripting Guys Security Watch: 아일랜드 하핑: 원치 않는 종속성 처리

원치 않는 보안 종속성으로 인해 전체 네트워크가 공격에 노출될 수 있습니다. 시스템 환경의 종속성을 분석하고 잠재적 문제를 해결할 수 있도록 보안 종속성의 작동 방식을 살펴보겠습니다.

Jesper M. Johansson The Desktop Files: Windows XP와 Windows PE 2.0 이중 부팅

Windows와 동일한 파티션에서 Windows PE 2.0을 부팅하면 많은 장점이 있습니다. 같은 파티션에서 Windows XP와 Windows PE 2.0을 이중 부팅하는 방법을 배우고 이를 통해 해결할 수 있는 문제를 살펴보겠습니다.

Wes Miller Field Notes: PC 기증

오래된 하드웨어를 기증하거나 재활용하면 오래된 하드웨어의 매립을 막음으로써 환경 보존에 도움이 됩니다. 재활용 준비를 위해 낡은 컴퓨터 장비에서 개인 데이터를 효과적으로 삭제하는 요령을 알려드립니다.

Jim Lynch Windows Confidential: 스크랩의 퇴출

큰 인기를 끌지 못한 기능이 어떻게 사라져 가는지 살펴봅니다.

Raymond Chen


 Sharepoint: 엔터프라이즈 환경에서의 효과적 데이터 수집 방법
Sharepoint Keith Deshaies

엔터프라이즈 환경에서의 효과적 데이터 수집 방법
한 눈에 보기:
  • 데이터 수집 및 처리
  • 정보 관리 논리와 표시 논리 분리
  • Microsoft Office 2007 기술을 활용한 데이터 수집 솔루션 구축
이 기사의 코드 다운로드: DataGathering2008_02.exe (567KB)

기업에서는 다양한 방법으로 엄청난 양의 정보를 수집합니다. 데이터는 전자 메일, 설문 조사, 웹 양식 등의 데이터 수집 방법을 통해 들어옵니다. 일반적으로 데이터는 유용하다고
할 수 있습니다. 그러나 수많은 데이터 수집 도구와 각양 각색의 정보를 제대로 관리하기는 쉽지 않습니다. 데이터의 안정적인 통합과 안전한 공유는 IT 조직에게 피할 수 없는 과제가 됩니다. 관련 표준과 서비스 지향의 아키텍처가 발전을 거듭하면서 IT 전문가가 더욱 간편하고 안전하게 데이터에 액세스할 수 있게 되었지만 효율적인 엔터프라이즈 아키텍처를 구축하는 데 필요한 도구와 기술을 가지고 있더라도 각종 전용 인터페이스 때문에 어쩔 도리가 없는 경우가 너무 많습니다. 문제는 이로 인해 호환되지 않는 솔루션을 구축하게 된다는 점입니다.
Microsoft® Office system이 제공하는 기술을 예로 들어보겠습니다. Windows® SharePoint® Services 3.0을 사용하면 부서별 설문 조사를 간단히 만들 수 있지만 조직의 표준에 부합하지 않을 수 있습니다. 회사에서 웹 기반 공동 작업 및 데이터 통합을 위한 플랫폼으로 ASP.NET과 SharePoint를 사용한다면 이러한 설문 조사 방식이 표준 솔루션이 될 수 있습니다. 반면 필자의 직장과 같은 환경에서 SharePoint는 여러 가지 플랫폼 중 하나일 뿐입니다.
하지만 SharePoint가 IBM, HP, Siebel 등에서 제공하는 다양한 시스템과의 통합 옵션을 많이 제공하는 것은 사실입니다. 그리고 다양한 백 엔드 시스템으로 결과 데이터가 전달되도록 유지하면서 임시 솔루션을 만들려는 고급 사용자라면 이러한 옵션이 유용할 것입니다. 그러나 전문적인 솔루션 설계자에게는 InfoPath® 2007이 더 적합합니다.
2007 Office system에 포함된 InfoPath 2007을 사용하면 솔루션의 표시 논리를 서버에서 호스트되는 정보 관리 논리에서 분리할 수 있습니다. XML 기반 InfoPath 기술을 활용하여 기업용 데이터 수집 솔루션을 구축할 수도 있습니다. 뿐만 아니라 InfoPath 양식을 디자인할 때는 XML, 웹 서비스, 솔루션 아키텍처, ASP.NET 또는 SharePoint 개체 모델에 대한 세부 지식이 거의 필요하지 않습니다.
이 기사에서는 InfoPath 2007, Office SharePoint Server 2007 및 Forms Services로 유연한 데이터 수집 솔루션을 구축하는 방법에 대해 알아보겠습니다. 또한 XML로 다중 계층 엔터프라이즈 아키텍처에서 어떻게 표시 논리를 비즈니스 논리와 분리할 수 있는지 예를 통해 설명하겠습니다.
이 기사에서 "데이터 수집"은 사람들로부터 정보를 수집하는 프로세스를 말합니다. 물론 데이터 원본을 크롤링하는 등 데이터를 수집할 수 있는 다른 방법도 많지만, 이렇게 자동화된 방법은 이 기사에서 다루지 않습니다.

데이터 획득과 처리
데이터 획득과 관련한 요구 사항은 복잡할 수 있지만 그 프로세스에는 몇 가지 공통점이 있습니다. 이러한 공통 작업을 중앙 집중식 모듈에서 해결하고 고유한 요구 사항을 분산된 구성 요소에서 처리하면 중복 작업, 유지 관리 부담 및 총 소유 비용을 낮출 수 있습니다.
일례로, 공개 기업은 법률 규정의 제한을 받기 때문에 회사 차원의 정보 관리 정책으로 구현되는 비즈니스 요구 사항이 필요합니다. 이러한 정책은 부서 경계를 넘나드는 데이터 수집 솔루션에 영향을 미치고 개별 부서의 업무 중복을 야기하는 경우가 많습니다. 예를 들어 HR 부서(직원 정보 처리)와 고객 서비스 부서(고객 정보 처리)에서 개인 식별 정보를 수집할 때 적용되는 규칙이 있습니다. 개별 부서 간에서 서로 유사하지만 관련되어 있지는 않은 비즈니스 프로세스에도 정보 관리 솔루션을 통합할 기회는 있습니다.
그림 1에는 일반적인 비즈니스 프로세스의 예가 나와 있습니다. 자신에게 배정된 업무를 동료와 서로 바꾸려는 직원은 먼저 동료의 동의를 구하고 업무 일정을 관리하는 관리자나 조정자의 승인을 받은 후 감독자의 승인을 얻어야 합니다. 직원 간에 교대 근무 시간을 바꾸는 경우를 예로 들 수 있습니다. 이러한 업무 배정의 교환이 부서 간에 여러 가지 양식을 사용해 이루어지더라도 워크플로와 정보 관리 논리는 다양한 부서 솔루션에서 공유될 수 있습니다.
그림 1 부서 간에 공유할 수 있는 샘플 데이터 수집 프로세스
그림 1 부서 간에 공유할 수 있는 샘플 데이터 수집 프로세스
물론 중복되는 구성 요소를 통합하려면 상당한 양의 작업이 필요합니다. 회사 전체에 조직 변경 사항을 적용하기는 쉽지 않지만 Office system 기술을 활용한다면 이러한 변경을 간편하게 수행할 수 있는 견고한 기반을 구축할 수 있습니다. InfoPath 2007을 사용하면 개별 부서에서 중앙의 표준화된 정보 관리 시스템과 통합되는 양식 응용 프로그램을 만들 수 있습니다. 그리고 SharePoint 2007을 사용하면 IT 부서에서 사이트 모음, 사이트 및 문서 라이브러리에 대한 관리 권한을 개별 부서와 팀에 위임할 수 있습니다. 결과적으로 팀에서는 IT 부서의 지원을 최소한으로 받으면서 직접 솔루션을 구축해 배포할 수 있으며, IT 부서에서는 워크플로, 정보 관리 정책, 백업 절차와 같은 모든 공유 서비스 및 구성 요소를 계속 제어할 수 있습니다.

데이터 수집 작업의 중앙 집중화
기업에서는 개별적인 정보 관리 요구 사항을 해결할 수 있도록 팀에 전용 응용 프로그램 서버를 제공하는 경우가 많습니다. 이 경우 IT 부서는 하드웨어와 운영 체제가 제대로 실행되도록 유지하는 역할만 하고 솔루션의 전반적인 관리는 개별 부서에서 담당합니다. 이러한 환경에서는 부서 간에 조정되는 부분이 적고 정보 공유가 어렵습니다.
데이터 수집 작업을 중앙 집중화하는 데 있어서 기술적인 문제는 주로 공유 환경에서 호스트되는 사용자 지정 구성 요소의 보안, 성능, 유지 관리 및 지원과 관련이 있습니다. 예를 들어 부서별 응용 프로그램 서버에서 개별 솔루션을 호스트하는 경우 오작동하는 구성 요소에 따른 영향이 제한적이지만 공유 환경에서는 훨씬 광범위하게 비즈니스 프로세스에 영향을 미칠 수 있습니다. 결과적으로 IT 부서에서는 중앙 집중화된 시스템에서 사용자 지정 구성 요소를 배포 및 유지 관리하는 것과 관련하여 엄격한 정책을 설정할 수밖에 없습니다.
부서별 SharePoint 솔루션을 중앙 서버 팜에서 호스트하려면 부서별 솔루션의 모든 사용자 지정 구성 요소를 중앙 응용 프로그램 서버에 배포하고 유지 관리해야 합니다. 이 문제는 백 엔드 웹 서비스에서 채워지는 드롭다운 목록으로 솔루션의 UI를 확장하는 사용자 지정 필드 형식을 사용하여 해결할 수 있습니다. 사용자 지정 워크플로를 사용하는 방법도 있지만 동일한 용도로 웹 파트를 사용하는 방법도 있습니다. 이들은 모두 관리 코드로 작성되고 Microsoft .NET Framework 어셈블리로 배포됩니다.
비교적 적은 수의 SharePoint 솔루션만 중앙 응용 프로그램 서버 팜으로 옮기더라도 까다로운 구성 및 지원 문제가 발생할 수 있습니다. 어셈블리를 GAC(전역 어셈블리 캐시)에 배포해야 하는 경우 어셈블리를 완전 신뢰 상태로 실행해야 하므로 보안 문제가 발생합니다. 구성 요소를 잘못 프로그래밍하면 시스템이 SQL 삽입, 사이트 간 스크립트 또는 서비스 거부 공격에 노출될 수 있습니다. 구성 요소가 통상적인 작업 부하뿐만 아니라 최대 부하와 장기 실행 작업까지 감당할 수 있어야 합니다. 또한 구성 요소가 이벤트를 동기적으로 처리하면서 다른 프로세스를 차단하지 않아야 하고 입력 유효성 검사를 안정적으로 수행하여 사용자가 데이터베이스나 원격 웹 시스템을 업데이트하는 데 사용되는 열에 SQL 문 또는 스크립트를 삽입할 수 없도록 해야 합니다.
간단히 말해, 여기서 우리의 목표는 표준 제품 기능을 기반으로 안전하고 확장 가능한 서버 구성을 구현하는 것입니다. 다시 사용 가능하고 철저한 테스트를 거친 솔루션을 활용한다면 막대한 양의 사용자 지정 구성 요소를 작성해야 하는 어려움을 피할 수 있습니다. 이때 프런트 엔드는 분산하고 백 엔드는 중앙 집중화하는 것이 좋습니다. 구성 요소를 느슨하게 연결하는 방식으로 통합함으로써 기존 솔루션을 최대한 다시 사용하도록 하는 것이 핵심입니다.

비즈니스 논리 분리
자, 그렇다면 서버에 구성할 수 있는 유연한 데이터 수집 솔루션은 어떻게 구축해야 할까요? 그림 2와 같이 솔루션 아키텍처를 데이터 저장소, 비즈니스 논리 그리고 표시 논리 또는 UI의 개별 계층으로 분리하는 방법이 가장 좋습니다. 최근에 UI는 일반적으로 브라우저를 기반으로 하고 비즈니스 논리는 웹 응용 프로그램 서버에 위치합니다. 그리고 UI와 비즈니스 논리는 데이터베이스와 비관계형 데이터 리포지토리에 액세스합니다.
그림 2 3계층 아키텍처 기반의 일반적인 엔터프라이즈 솔루션
그림 2 3계층 아키텍처 기반의 일반적인 엔터프라이즈 솔루션
비즈니스 논리는 트랜잭션이 데이터베이스 관리 시스템 전반에 원자성으로 적용되도록 하는 트랜잭션 논리를 포함하는 경우가 많습니다. 또한 HTTP를 통한 여러 중간 계층 서비스, 메시지 큐, RPC 등이 비즈니스 논리에 통합될 수도 있습니다. 그러나 전반적인 솔루션 아키텍처는 본질적으로 3계층 모델입니다.
그림 2에는 엔터프라이즈 환경에 구현되는 비즈니스 논리의 복잡성이 나와 있지 않습니다. 그림에서는 응용 프로그램 서버가 브라우저 기반 양식을 표시하고 전송된 데이터를 처리하는 데만 주력하는 것처럼 보이지만, 이 그림에는 워크플로, 규정 준수 또는 정보 관리 요구 사항이 반영되지 않았습니다. 이러한 요구 사항을 해결하려면 비즈니스 논리를 표시 논리와 정보 관리 논리로 나누어야 합니다. 이렇게 비즈니스 논리를 나누면 각 솔루션마다 구성 요소를 새로 작성하지 않고도 중간 계층 구성 요소를 필요에 따라 다양하게 조합할 수 있습니다.
그림 3은 이러한 아키텍처를 보여 줍니다. 중심에는 콘텐츠 또는 데이터가 있고 그 주위에 수명 주기 전반에 걸쳐 콘텐츠를 관리하는 정보 관리 논리가 위치합니다. 표시 논리는 사용자 인터페이스를 통한 데이터 액세스 기능을 제공하기 위해 정보 관리 논리와 상호 작용합니다.
그림 3 정보 관리 논리와 표시 논리 분리
그림 3 정보 관리 논리와 표시 논리 분리

XML 수집 및 처리
SOA(서비스 지향 응용 프로그램) 환경에서는 데이터 구조와 데이터를 정의하고 구성 요소 간에 이를 공유하는 데 주로 XML이 표준으로 사용됩니다. 따라서 표시 구성 요소와 정보 관리 구성 요소 간의 인터페이스에도 XML을 사용하는 것이 좋습니다.
통신은 양방향으로 이루어져야 합니다. 즉, XML을 브라우저가 읽을 수 있는 문서로 변환해야 하며 양식에서 생성된 XML 문서도 변환해야 합니다. 최근까지 XML 기반 양식 응용 프로그램을 작성하기 위해서는 고도의 프로그래밍 기술이 필요했습니다. 결과로 만들어지는 XML 데이터가 조직 간의 정보 교환이 가능하도록 업계 스키마에 부합해야 하는 경우에는 특히 더 그랬습니다.
InfoPath 2007을 활용하면 XML 기반 양식 개발이 훨씬 쉬워집니다. XML에 대해 충분한 지식이 있다면 분명 도움이 되지만 양식 디자이너나 고급 사용자는 XML 전문가가 아니더라도 쉽게 XML 기반 양식 응용 프로그램을 작성할 수 있습니다. 양식 디자이너는 XML 문서나 XML 스키마를 InfoPath로 가져온 다음, 해당 데이터 원본에서 양식의 필드로 개별 특성과 요소 노드를 매핑하기만 하면 됩니다. 또한 웹 서비스 또는 SQL Server® 데이터베이스를 기반으로 양식 디자인을 시작하거나, 백그라운드에서 자동으로 기본 스키마와 데이터 바인딩을 생성하는 InfoPath의 기능을 활용해 빈 서식 파일에서 새로 양식을 작성할 수 있습니다.
InfoPath와 XML 스키마를 사용하여 양식을 표준화하면 몇 가지 이점을 얻을 수 있습니다. 잘 정의된 XML 스키마가 이미 있다면 워크플로 및 정보 관리 구성 요소의 개발자와 양식 디자이너가 동일한 데이터 구조를 대상으로 솔루션을 만들 수 있습니다. 양식 디자이너가 양식을 새로 만드는 경우 개발자는 양식이 완성될 때까지 기다려서 기본 데이터 구조에 어떤 영향을 미치는지 확인해야 합니다. 데이터 구조가 정의된 후에는 새 양식 서식 파일 등 이후에 새로 만드는 솔루션에 기반 데이터 구조가 동일한 기존 워크플로와 정보 관리 구성 요소를 다시 사용할 수 있습니다. 또한 이후에 새로 추가하는 워크플로와 정보 관리 구성 요소가 기존 양식 및 데이터와 함께 작동할 수 있습니다. 업계에서 확립된 스키마를 기반으로 데이터 수집 솔루션을 구축하면 더욱 유연한 솔루션을 얻을 수 있습니다. 이러한 솔루션은 다른 회사에서 동일한 스키마를 사용하여 만든 솔루션과 호환되기 때문입니다.
필자는 직원과 관리자를 연결하는 DirectReports라는 간단한 스키마를 만들었습니다. 관리자는 이 스키마로 만들어지는 양식을 통해 직속 부하 직원을 평가할 수 있습니다. 이 기사와 함께 제공되는 다운로드(technetmagazine.com/code08.aspx)의 Direct Reports 폴더에는 스키마와 양식, 그리고 양식을 다시 만드는 방법을 설명하는 readme.htm 파일이 들어 있습니다. 기본적인 수준의 양식이지만 일반적인 개념을 이해하는 데에는 충분하리라 생각합니다.
여기서 짚고 넘어가야 할 중요한 것이 있습니다. 필자는 InfoPath에 유효성 검사 논리를 만들지 않았지만 그래도 InfoPath는 사용자 ID와 전자 메일 주소를 정해진 형식(domain\account 및 recipient@domain.tld)으로 입력할 것을 요구합니다. 그렇지 않으면 만들어지는 XML 문서가 유효하지 않게 됩니다. 이는 XML 스키마가 이러한 형식을 정의하기 때문입니다. 그림 4에서 볼 수 있듯이 잘못된 데이터가 있는 양식을 저장할 수는 있지만 전송할 수는 없습니다. 실제로 다른 위치로 데이터를 전송하지 않고도 이를 테스트할 수 있도록 양식에 임시 전송 규칙을 추가했습니다. 이런 유형의 오류 없이 완벽하게 양식에 입력했는지는 InfoPath 2007 유효성 검사를 통해 자동으로 확인됩니다.
그림 4a 사용자가 양식을 전송하지 못하도록 하는 유효성 검사 오류
그림 4a 사용자가 양식을 전송하지 못하도록 하는 유효성 검사 오류
그림 4b 생성되는 오류 메시지
그림 4b 생성되는 오류 메시지
XML 스키마는 표시 논리와 정보 관리 논리 사이의 바인딩 계약 역할을 합니다. InfoPath는 양식 디자이너가 의도적으로 데이터 구조를 변경하지 못하도록 스키마를 잠급니다. 설정된 XML 스키마를 변경하면 새로운 양식 서식 파일과 함께 사용할 워크플로 모듈과 같은 기존 엔터프라이즈 솔루션이 손상될 수 있기 때문에 이 보호 기능은 매우 중요합니다.
InfoPath는 양식 응용 프로그램에 고급 표시 논리를 적용할 수 있는 다양한 기능을 제공합니다. XML 파일, 웹 서비스, SharePoint 라이브러리와 목록, 데이터베이스 등에 있는 데이터로부터 의미 있는 기본값을 얻을 수 있습니다. 규칙을 통해 사용자 선택을 기준으로 필드 값을 변경하고, 유효성 검사 논리를 추가하고, 높은 수준의 사용자 지정 요구 사항을 해결하기 위한 관리 코드를 추가하고, Forms Service를 사용하여 웹을 통해 액세스할 수 있는 양식 서식 파일을 만들 수 있습니다. 어떤 경우든 양식을 통해 수집되는 데이터는 결국 스키마 정의에 부합하는 XML 문서 형태로 정보 관리 논리에 전달됩니다.

XML 또는 메타데이터를 이용한 작업
이쯤에서 정보 관리 논리를 전송된 XML 문서에 직접 적용해야 하는지, 아니면 필요한 정보를 메타데이터로 추출하는 파서를 사용해야 하는지 궁금할 것입니다. SharePoint는 두 가지 방식을 모두 지원합니다. 개발자들은 XML 문서에서 직접 작업하는 방식에 익숙해져 있지만 메타데이터를 사용하면 보다 유연하게 작업을 수행할 수 있습니다.
메타데이터의 유연성을 설명하기 위해 그림 4의 Direct Reports 양식에서 전달된 XML 문서를 구문 분석하는 간단한 웹 서비스를 만들었습니다. 이 웹 서비스의 소스 코드, 설치 파일 및 단계별 지침이 포함된 readme.htm은 이 기사와 함께 제공되는 다운로드 파일의 XMLParsingWebService 폴더에 있습니다. 이 웹 서비스는 XML 문서에서 관리자의 사용자 ID를 읽고, 사용자 ID를 도메인 부분과 사용자 이름 부분으로 나누고, 나뉜 부분을 기준으로 메시지를 만든 다음, 반환할 일반 예외를 발생시키고, 처리된 정보를 InfoPath 양식에 의사 오류 메시지 형식으로 표시합니다. 이는 데이터가 전송된 후 InfoPath에 대화 상자를 표시하는 손쉬운 방법입니다. 이 웹 서비스는 훌륭하게 작동하지만 readme.htm 파일의 설명에 따라 DirectReports.xsd의 OrgPerson 요소 이름을 Manager로 바꾸고 InfoPath 양식을 새 스키마로 업데이트하는 경우와 같이 기본 데이터 원본을 변경하면 웹 서비스에서 오류가 발생합니다. XML 문서가 달라지고 user-id 요소에 액세스하기 위한 이전 XPath 식이 유효하지 않게 되므로 이는 당연한 결과입니다. OrgPerson 스키마와 Manager 스키마는 거의 동일하고 InfoPath 양식은 완전히 동일하며 원하는 처리 결과도 같지만 차이가 미미함에도 불구하고 중복된 웹 서비스를 배포하고 유지해야 합니다.
따라서 응용 프로그램 서버에서 사용자 지정 코드 사용을 최소화하려는 경우에는 이 방법이 적합하지 않습니다. 이와는 대조적으로 XML 노드를 메타데이터 필드에 매핑하고 메타데이터를 기준으로 처리 프로세스를 수행하면 XML 스키마가 달라도 유사한 데이터 구조에 동일한 워크플로와 정보 관리 논리를 사용할 수 있습니다. 하위 요소가 올바른 메타데이터 필드에 매핑되고 데이터 형식이 처리 요구 사항에 맞도록 하면 기존 코드를 다시 사용하는 데 문제가 없습니다.
XML 노드를 메타데이터 필드에 매핑하는 것은 그림 5와 같이 XML 노드를 InfoPath 양식의 UI 컨트롤에 바인딩하는 것과 비슷합니다. SharePoint에서 메타데이터 필드는 사이트 또는 목록 수준에서 정의되고 콘텐츠 형식 정의에서 참조되는 열에 해당합니다. 콘텐츠 형식은 메타데이터 필드, 워크플로, 양식과 같은 콘텐츠 항목의 특성을 정의합니다. SharePoint에서는 이러한 콘텐츠 형식의 메타데이터 필드를 연결된 XML 문서의 해당 노드와 동기화된 상태로 유지하기 위해 속성 승격과 강등을 수행하는 기본 제공 XML 파서가 사용됩니다. 속성을 승격할 때 이 XML 파서는 XML 문서의 노드 값을 문서 라이브러리의 해당 열에 추출하고, 속성을 강등할 때는 문서 라이브러리에서 열 값을 가져와서 다시 문서에 쓰는 정반대의 프로세스를 수행합니다. 여기서 가장 중요한 것은 XML 파서가 메타데이터 필드와 매핑된 XML 노드를 동기화된 상태로 유지한다는 점입니다.
그림 5 InfoPath와 SharePoint 간의 XML 스키마 매핑
그림 5 InfoPath와 SharePoint 간의 XML 스키마 매핑
SharePoint 개체 모델을 사용하는 경우 웹 파트, 워크플로 및 정보 관리 논리가 기본 XML 문서뿐만 아니라 메타데이터 필드와도 작동합니다. 즉, 매핑된 메타데이터 필드의 값을 변경하면 XML 문서의 노드 값이 변경되고 그 반대도 마찬가지입니다. 게다가 XML 문서에서 직접 작업하면 비즈니스 논리와 XML 스키마가 밀접하게 연관됩니다. 또한 매핑된 메타데이터 필드는 코드의 재사용성을 높입니다. 물론 환경에 적합한 방법을 선택해야 하겠지만 대개 메타데이터 필드를 사용하는 SharePoint 솔루션은 유연성이 높고 코드를 다시 사용할 기회를 더 많이 제공합니다.
SharePoint에서 XML 노드와 메타데이터 필드가 어떻게 연결되는지 살펴볼 수 있도록 이 기사와 함께 제공되는 자료에 사용자 지정 문서 라이브러리를 구축하는 SharePoint 기능을 포함했습니다. 다운로드의 OrgPersonLib 폴더에 있는 OrgPersonContentType.xml 파일을 살펴보시기 바랍니다. OrgPerson 콘텐츠 형식은 UserID, FullName, EMail, Direct_x0020_Reports라는 네 가지 필드를 참조합니다. FullName과 EMail은 기본 제공 필드이고 UserID와 Direct_x0020_Reports는 OrgPersonSiteColumns.xml에 정의된 사용자 지정 필드입니다.
필드 정의는 매우 간단합니다. 필드 정의에서 직접 XML 노드에 필드를 바인딩할 수도 있고 콘텐츠 형식에서 이 정보를 덮어쓸 수도 있습니다. 필자는 XML 문서와 관련없는 콘텐츠 형식뿐만 아니라 다른 XML 구조를 사용하는 콘텐츠 형식에 사용자 지정 필드를 사용할 수 있는 후자의 기법을 사용하기로 했습니다. OrgPerson 콘텐츠 형식은 앞서 설명한 OrgPerson 스키마의 해당 배열과 일치하는 XML 노드에 메타데이터 필드를 바인딩합니다. 동일한 메타데이터 필드를 다른 XML 노드에 바인딩하는 추가 콘텐츠 형식을 정의하는 AdditionalContentTypes.xml 파일도 있습니다. Node 특성의 XPath 식을 살펴보면 그 차이를 알 수 있습니다.
해당 라이브러리 열을 통해 노드 값이 노출되는 OrgPersonLib 형식의 문서 라이브러리에 다른 형식의 XML 문서를 저장할 수 있습니다. 이 단순한 매핑 기법에서는 네 가지 콘텐츠 형식(OrgPerson, Manager, Supervisor 및 User)이 공통의 메타데이터 필드 집합을 참조하기 때문에 워크플로와 정보 관리 논리를 다시 사용할 수 있습니다.
그림 6에는 Direct_x0020_Reports의 OrgPerson 콘텐츠 형식에 포함된 FieldRef 요소가 나와 있습니다. 이 요소는 /OrgPerson/direct-report/user-id라는 XPath 식에 따라 직속 부하 직원의 user-id 노드에 필드를 매핑합니다. XML 문서에는 직속 부하 직원 항목이 여러 개 포함될 수 있으므로 Aggregation 특성을 지정하는 것이 중요합니다. 이 특성은 XML 파서가 반환된 값 모음을 처리하는 방식을 정의합니다. 이 특성을 지정하지 않으면 XML 파서가 첫 번째 노드 값만 추출합니다. 지원되는 집계 값은 sum, count, average, min, max, merge, plain text, first, last입니다.
그림 6 XPath 식에 매핑된 메타데이터 필드
그림 6 XPath 식에 매핑된 메타데이터 필드
모든 샘플 콘텐츠 형식은 표준 upload.aspx 페이지를 DocumentTemplate으로 사용하므로 SharePoint UI에서 새로 만들기 단추를 클릭하면 문서 라이브러리에 XML 파일을 업로드할 수 있습니다. 확장명이 .xml인 파일을 업로드하면 SharePoint는 기본 제공 XML 파서를 자동으로 호출합니다. 단, WordProcessingML 파일의 경우에는 SharePoint가 WordProcessingML 파서를 호출합니다. XML 파서는 업로드된 .xml 파일을 조사하여 연결된 콘텐츠 형식을 확인합니다. 이는 필드 정의에 지정된 위치에서 노드 값을 추출하고 속성 승격을 수행하기 위한 것입니다. OrgPersonLib\XMLFiles 폴더에 있는 OrgPerson.xml 파일을 업로드할 때 이 프로세스를 직접 확인할 수 있습니다. 이 XML 문서의 구조는 OrgPerson 콘텐츠 형식 정의에 지정된 XPath 식과 일치합니다. 따라서 SharePoint는 .xml 파일에서 데이터를 추출하고, 해당 라이브러리 열에 데이터를 쓰고, 읽기 전용으로 지정되지 않은 문서 속성을 확인하고 업데이트할 수 있도록 EditForm.aspx 페이지에 데이터를 표시합니다. 그림 7에는 OrgPerson.xml에서 추출된 데이터가 표시된 EditForm.aspx 양식이 나와 있습니다.
그림 7 추출된 데이터가 포함된 EditForm.aspx 양식
그림 7 추출된 데이터가 포함된 EditForm.aspx 양식
EditForm.aspx에서 User ID(사용자 ID), Full Name(전체 이름) 또는 E-Mail(전자 메일) 값을 변경하면 SharePoint는 속성 강등을 통해 기본 XML 문서의 노드 값을 변경합니다. 그러나 이제 여러분이 직접 필요한 논리를 양식에 구현하지 않는 한 SharePoint가 XML 스키마 제한을 강제로 적용하지 않습니다.
SharePoint는 양식 응용 프로그램의 표시 논리도 실행하지 않습니다. 예를 들어 User ID(사용자 ID)를 변경할 때 SharePoint는 새 값이 NetBIOS 규칙에 맞는지 확인하거나 Full Name(전체 이름) 필드와 E-Mail(전자 메일) 필드를 새 선택 항목에 맞게 자동으로 업데이트하지 않습니다. 따라서 개별 필드를 변경했을 때 일관성 문제가 발생할 가능성이 있으면 콘텐츠 형식 정의의 해당 열을 읽기 전용으로 지정해야 합니다. 결과적으로 사용자는 InfoPath와 같은 양식 응용 프로그램을 사용하여 데이터를 업데이트할 수밖에 없습니다. 그리고 XML 파서는 XML 문서의 모든 변경 내용을 SharePoint의 해당 메타데이터 필드로 승격합니다.
OrgPersonLib 샘플에서 OrgPersonLib\XMLFiles 폴더의 어떤 .xml 파일이든 업로드할 수 있습니다. 이들 .xml 파일은 매우 상이한 데이터 구조를 사용하지만 SharePoint는 문제 없이 콘텐츠 형식을 인식하고 올바른 노드 값을 사이트 열로 승격합니다. 그 이유는 필자가 XML 문서를 해당 콘텐츠 형식과 연결하는 처리 명령을 XML 파일에 사용했기 때문입니다. OrgPerson.xml 파일에는 이러한 정보가 없지만 문제가 되지는 않습니다. 처리 명령이나 문서 서식 파일을 통해 XML 문서를 콘텐츠 형식과 연결하지 못할 경우 SharePoint는 기본 콘텐츠 형식을 사용합니다. OrgPersonLib 예에서는 OrgPerson 콘텐츠 형식이 사용되었으므로 XML 문서가 올바르게 구문 분석됩니다.
그림 8은 XML 문서를 특정 콘텐츠 형식에 명시적으로 연결하는 방법을 보여 줍니다. MicrosoftWindowsSharePointServices 처리 명령은 ContentTypeID를 0x010100668E393E4F0EFF4294DBD202D5D8321D로 정의하는데, 이것은 AdditionalContentTypes.xml에서 정의된 User 콘텐츠 형식의 ID입니다.
그림 8 User.xml 샘플 파일의 처리 명령과 XML 데이터
그림 8 User.xml 샘플 파일의 처리 명령과 XML 데이터
XML 파서는 MicrosoftWindowsSharePointServices 처리 명령을 처리하고 ContentTypeID 값을 ContentType 메타데이터 필드에 씁니다. 이 메타데이터 필드는 System 콘텐츠 형식의 루트 수준에서 정의되므로 모든 SharePoint 콘텐츠 형식이 이 메타데이터 필드를 공유하게 됩니다. SharePoint 서버에서 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields 폴더에 있는 fieldswss.xml 파일을 열고 MicrosoftWindowsSharePointServices를 검색하면 SharePoint에서 처리 명령과 ContentType 필드가 어떻게 연결되는지 살펴볼 수 있습니다. PITarget 특성은 처리 명령인 MicrosoftWindowsSharePointServices를 가리키고 PIAttribute는 User 콘텐츠 형식의 ID가 들어 있는 ContentTypeID를 가리킵니다.

InfoPath의 콘텐츠 형식 연결
XML 구문 분석과 콘텐츠 형식 연결과 관련된 기술은 많은 양식 디자이너들이 어려워하는 전문적인 분야지만 InfoPath 2007은 그 세부 과정을 자동으로 해결해 줍니다. OrgPersonLib 샘플과 함께 제공되는 readme.htm 파일에는 SharePoint의 Direct Reports 양식 서식 파일을 게시하고 동일한 메타데이터 필드(UserID, FullName, EMail, Direct_x0020_Reports)에 바인딩할 콘텐츠 형식을 만들기 위한 설명이 포함되어 있습니다. SharePoint UI의 OrgPersonLib 문서 라이브러리에 새 콘텐츠 형식을 쉽게 추가할 수 있습니다. 하지만 새 콘텐츠 형식도 InfoPath 양식 서식 파일을 기존 XML 문서를 업데이트할 때 양식 응용 프로그램을 호출할 문서 서식 파일로 가리킵니다. 그림 9는 InfoPath 게시 마법사를 통해 XML 노드 값과 SharePoint 사이트 열 간의 속성 매핑을 손쉽게 수행하는 과정을 보여 줍니다. 그리고 다시 한 번 강조하지만 노드 값을 기존 사이트 열과 연결하면 기존 SharePoint 구성 요소를 다시 사용할 수 있습니다.
그림 9 InfoPath 2007의 속성 매핑
그림 9 InfoPath 2007의 속성 매핑

결론
추가 온라인 리소스
  • InfoPath 2007 팀 블로그
  • W3C XML 스키마 사양 및 개발
  • XML 스키마 소개
  • Office SharePoint Server 2007의 워크플로
  • InfoPath 2007 Forms Services

Office에서 제공되는 기술을 활용하면 기업의 설계자들이 손쉬운 코드 다시 사용과 정보 교환이 가능한 데이터 수집 솔루션을 구축할 수 있습니다. 또한 InfoPath 2007을 사용하면 다양한 출처로부터 정보를 획득하여 SharePoint와 같은 여러 시스템에 해당 데이터를 전송하는 솔루션을 만들 수 있습니다. SharePoint는 개발자가 워크플로와 정보 관리 구성 요소를 작성할 수 있도록 웹 서비스와 인터페이스를 포괄적으로 제공합니다. 이러한 구성 요소를 중앙 집중화된 SharePoint 서버에 호스트하면 부서에서 개별 응용 프로그램을 작성하는 데 필요한 인프라가 구축됩니다.
또한 개별 부서에서는 필요한 데이터 수집 솔루션을 보다 신속하게 만들 수 있습니다. 그리고 규정 준수나 기타 회사 전체에 적용되는 비즈니스 요구 사항도 부서 간 차원에서 해결할 수 있으며 응용 프로그램 서버에 사용되는 사용자 지정 구성 요소의 수가 줄어 IT 환경의 관리 용이성과 안정성이 향상됩니다.

Keith Deshaies는 자유 기고 테크니컬 라이터이자 대규모 통신 회사의 IT 분석가로 일하고 있습니다. Microsoft Office와 SharePoint 기술을 전문으로 다루는 Keith는 Society for Technical Communications의 회원이기도 합니다.
© 2007 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


 Sharepoint: 강력한 설문 조사 인프라 구축
Sharepoint Jim Bradley

강력한 설문 조사 인프라 구축
한 눈에 보기:
  • 설문 조사 솔루션의 기획과 구현
  • SharePoint 라이브러리에서의 설문 조사 결과 수집 및 처리
  • 성능 및 보안 문제의 관리

정보가 없으면 올바른 결정을 내릴 수 없습니다. 비즈니스에 영향을 미칠 의사 결정을 직감에 의존한다는 것은 무모한 행동입니다.
팀 모임을 어디에서 주최할 것인지 결정할 때나, 신제품 출시를 위해 회사 자원의 50%를 재할당하는 문제를 계획할 때에도 충분하고 올바른 정보는 필수적입니다. 그러나 이러한 정보를 어떻게 얻을 수 있을까요?
설문 조사는 회사의 제품 구성에 대한 고객 만족도 파악에서부터 지난 팀 모임 때 먹었던 샌드위치를 직원들이 좋아했는지 아닌지에 대한 문제에 이르기까지 모든 사항에 대한 반응과 의견을 비용 대비 효과적으로 수집할 수 있는 방법의 하나입니다. 설문 조사는 향후 제품, 시스템 또는 프로세스 향상과 개발에 필요한 토대를 제공합니다. 문제는 정보를 의미 있게 활용할 수 있도록 데이터를 수집하고 저장하는 설문 조사 시스템을 IT 전문가인 여러분들이 어떻게 구현하는가 하는 것입니다.
아마도 여러분은 이미 이러한 종류의 데이터를 수집, 체계화하고 분석하는 데 필요한 도구를 하나 이상은 보유하고 있을 것입니다. 2007 Microsoft® Office system에서는 이러한 도구를 제공하며 매우 사용하기 쉽습니다. 사실 설문 조사 수행에 활용할 수 있는 방법은 수없이 많습니다. 관건은 각자의 구체적인 요건에 맞는 방식을 찾는 것입니다. 예를 들어 전자 메일을 이용한 설문 조사는 소수의 응답자를 대상으로 일반적인 데이터를 실시간으로 즉석에서 수집하고자 할 때 사용할 수 있는 좋은 방법입니다. 더 자세한 내용은 아래 추가 기사 "전자 메일을 이용한 신속한 설문 조사"를 참조하십시오. 반면, 데이터베이스를 이용한 설문 조사는 응답자 수가 많고 중요 업무 데이터를 수집하는 보다 복잡한 설문 조사에 더 적합한 방법입니다. 이 주제에 대한 자세한 내용은 아래의 추가 기사 "데이터베이스 기반 설문 조사 솔루션 구축"을 참조하시기 바랍니다.
이 글에서는 보다 포괄적이고 유연한 솔루션인 SharePoint® 기반 온라인 설문 조사에 대해 중점적으로 다루겠습니다. 이 방법은 복잡성에 관계없이 중요 업무 정보 조사나 일반적인 정보 조사에 모두 적합한 방법입니다. SharePoint 설문 조사는 웹을 기반으로 이루어지므로 웹 브라우저를 이용할 수 있다면 누구나 기입할 수 있으며 모바일 장치도 지원됩니다. SharePoint 설문 조사에서는 응답자를 기명 또는 익명으로 처리할 수 있으며 실시간 결과를 확보할 수 있고 분석 도구도 이용할 수 있습니다.
이 설문 조사 유형은 Windows® SharePoint Services 3.0(WSS)와 Forms Server 및 InfoPath®를 조합하거나 Microsoft Office SharePoint Server 2007(MOSS)과 Forms Services 및 InfoPath®를 조합하여 구현됩니다(이 기술에 대한 설명은 그림 1 참조). 두 가지 경우 기본적으로 모두 동일한 기능을 제공하므로 이 글에서는 후자의 조합을 중점적으로 설명하겠습니다. SharePoint 제품과 그 기능에 대한 포괄적인 비교는 Microsoft Office SharePoint Server 2007 제품 비교 다운로드office.microsoft.com/en-us/sharepointserver/HA101978031033.aspx를 참조하십시오.
Figure 1 SharePoint 설문 조사를 구현하는 Microsoft 기술 (Close Figure 1)

기술 | 설명
Microsoft Office InfoPath 2007 | Microsoft Office InfoPath 2007은 양식 만들기 및 정보 수집 도구입니다. 자세한 내용은 office.microsoft.com/infopath를 참조하십시오.
Windows SharePoint Services 3.0 | 이전의 SharePoint Team Services에서 명칭이 변경된 Windows SharePoint Services 3.0은 확장된 SharePoint 응용 프로그램을 만드는 기반이 됩니다. 자세한 내용은 microsoft.com/technet/windowsserver/sharepoint/techinfo/overview.mspx를 참조하십시오.
Microsoft Office SharePoint Server 2007 | Microsoft Office SharePoint Server 2007(이전의 SharePoint Portal Server 2003)은 Office 2007 클라이언트를 SharePoint 응용 프로그램용 콘텐츠의 작성자 및 이용자로 전환하는 서버 쪽 인프라를 제공합니다. 자세한 내용은 microsoft.com/sharepoint를 참조하십시오.
InfoPath Forms Services, Microsoft Office Forms Server 2007 | InfoPath Forms Services를 사용하면 InfoPath를 설치하지 않고도 웹 브라우저를 통해 InfoPath 양식을 작성할 수 있으므로 플랫폼 및 브라우저 간에 호환되는 설문 조사를 구현할 수 있습니다. Forms Services에서는 Windows SharePoint Services 3.0이 필요하지만 Microsoft Office Forms Server 2007이라는 독립 실행형 제품으로도 동일한 기능이 제공되고 있습니다. Forms Services에 대한 자세한 내용은 microsoft.com/ms540731을 참조하십시오. Forms Server에 대한 자세한 내용은 office.microsoft.com/en-us/formsserver/FX100490391033.aspx를 참조하십시오.

기획 및 구현
설문 조사를 작성할 때에는 우선적으로 몇 가지 요소를 고려해야 합니다. 이를 위해서는 사전 분석이 필요하므로 충분한 시간을 들여 면밀한 설문 계획을 구성해야 합니다. 초기 계획 단계에서는 문제 영역 및 얻고자 하는 데이터의 종류를 정의하고, 활용해야 할 기술을 결정하고, 예산 및 관리 요건을 파악합니다. 그리고 구현 단계로 넘어갑니다. 일반적인 워크플로는 설문 조사 양식을 작성한 다음 해당 양식을 게시하고, 응답을 수집 및 검증하고, 데이터를 집계 분석한 후 그 결과를 보고하는 순서로 진행됩니다.
설문 조사 구현 워크플로에는 최소한 설문 조사 작성자 한 명과 다수의 응답자, 그리고 분석자 한 명이 참여하는 것이 일반적입니다(그림 2 참조). 물론, 설문 조사 워크플로의 복잡도는 매우 다양할 수 있습니다. 예를 들어 회사 전체를 대상으로 하는 설문 조사는 몇 차례의 반복적인 설계 수정과 승인 과정을 거치기 마련입니다. 응답자를 위한 자동 알림 기능이 활용될 수 있고, 다양한 형태의 지원과 문제 해결, 그리고 관리자를 위한 실시간 결과 정보가 제공되며 최종 분석 결과를 파악하여 제공하는 명확한 프로세스가 수립될 것입니다. 이러한 종류의 복잡한 작업 흐름에는 워크플로와 보고 기능을 지원하는 웹 기반 시스템이 반드시 필요합니다.
그림 2 양식 디자인에서 데이터 분석에 이르는 설문 조사 워크플로
그림 2 양식 디자인에서 데이터 분석에 이르는 설문 조사 워크플로

포괄적인 솔루션의 필수 요건
포괄적인 설문 조사 솔루션이 충족해야 할 핵심 요건은 매우 많습니다. 개별 팀 또는 부서에서는 이러한 솔루션을 통해 설문을 만들고 배포하고 결과를 수집할 수 있어야 하며, IT 부서의 관여를 최소화해야 하고 프로그래밍 기술 없이도 해당 작업을 수행할 수 있어야 합니다. 양식 생성 도구에서는 파이핑, 분기, 조건 논리를 지원하는 다양한 기능과 사용하기 편리한 WYSIWYG 인터페이스를 제공해야 합니다. 물론 설문 조사 양식 생성 도구는 크기와 복잡도에 관계없이 모든 설문을 수용할 수 있어야 합니다.
또한 설문 조사는 웹 서버에서 실행되어야 하며 중앙에서 유지 관리되는 SQL Server® 데이터베이스와 통합되어야 합니다. 이렇게 하면 개별 부서에서 전용 SQL 데이터베이스를 유지 관리하지 않아도 됩니다. 인터넷 이용이 가능한 응답자는 모든 표준 호환 브라우저에서 설문 조사를 완료할 수 있어야 합니다.
설문 조사 프로세스는 워크플로와 쉽게 연결되어야 하며 보안에 영향을 미치지 않고 업무 요구 사항을 충족할 수 있어야 합니다. 또한 많은 조직의 경우 설문 조사 솔루션에서 다국어 지원을 제공해야 합니다.
MOSS 2007과 WSS 3.0, InfoPath 2007을 조합하면 이러한 모든 요건을 충족하는 하나의 통합 솔루션을 구성할 수 있습니다. 그림 3은 SharePoint 스택에서 다양한 구성 요소가 어떻게 결합되는지 보여 주고 있습니다. 그러나 이처럼 모든 요건을 완비한 설문 조사 솔루션에 대해 설명하기 전에, 먼저 WSS만으로 어떤 작업을 수행할 수 있는지 간략하게 살펴보겠습니다. 그런 다음 여기에 MOSS와 InfoPath를 추가했을 때 어떤 부가적인 이점을 기대할 수 있는지 설명하겠습니다.
그림 3 SharePoint 스택의 구성요소
그림 3 SharePoint 스택의 구성요소

WSS만을 이용한 작업
다른 구성 요소 없이 WSS만 사용하더라도 설문 조사를 만들고 구현할 수 있습니다. 실제로, WSS에는 설문 프로세스를 수월하게 만들어 주는 기본 제공 설문 조사 서식 파일이 포함되어 있습니다. 설문 조사를 만들려면 시작 | 모든 프로그램 | 관리 도구를 차례로 클릭하고 SharePoint 3.0 중앙 관리를 선택합니다. 드롭다운 목록이 표시되면 사이트 작업을 선택하고 만들기를 클릭합니다. 만들기 페이지가 나타나면서 라이브러리, 통신, 추적, 사용자 지정 목록, 웹 페이지의 제목이 표시됩니다. 각 제목 아래에는 서식 파일 옵션이 있습니다. 추적 아래의 설문 조사를 클릭합니다.
이 단계에서부터 WSS는 설문 조사 만들기 프로세스를 차례로 안내합니다. 공개 또는 비공개 질문을 만들 수 있으며 질문을 무응답 상태로 둘 수 있는지 지정할 수 있습니다. 응답 내용에 따라 각기 다른 경로로 분류되어 설문이 진행되는 분기 논리 설문 조사도 만들 수 있습니다. 설문 조사를 익명으로 설정할 수 있으며, 필요한 경우에는 응답자의 신원을 밝힐 수 있습니다. 또한 설문 조사에 워크플로를 할당할 수도 있습니다.
설문 조사는 브라우저를 기반으로 하므로 특별한 소프트웨어가 없어도 설문을 만들거나 응답할 수 있습니다. 설문 조사를 완료하려면 응답자는 SharePoint 사이트로 이동한 다음 해당 양식에 기입하기만 하면 됩니다. 액세스 권한은 상위 사이트에서 상속되지만 SharePoint의 작업 메뉴에서 직접 편집할 수도 있습니다. 설문 응답 내용은 SharePoint 설문 조사 사이트에 저장되며, 해당 결과를 목록 형식으로 표시하거나 그래픽 형태로 요약하거나 Excel®로 내보낼 수도 있습니다.
다시 말씀 드리지만, 이 솔루션(그림 4에 제시된 프로세스로 진행)은 추가 소프트웨어 없이 WSS만으로도 구성이 가능합니다. 잘 디자인된 SharePoint 사이트만 구축되어 있다면, 개별 부서에서는 IT 부서의 지원을 거의 또는 전혀 받지 않고도 설문 조사를 만들고 구현할 수 있습니다.
그림 4 Windows SharePoint Services 기반 설문 조사
그림 4 Windows SharePoint Services 기반 설문 조사
설문 조사에 사용자 지정이 필요하게 되면 WSS만으로 구성된 프로세스의 한계가 분명히 드러납니다. WSS는 다양한 기본 ASPX 페이지(AllItems.aspx, DispForm.aspx, EditForm.aspx, NewForm.aspx, overview.aspx, summary.aspx)를 이용하여 설문 조사 목록을 만듭니다. WSS에 기본적으로 내장된 매개 변수 이상의 페이지 사용자 지정이 가능하기는 하지만, 대부분의 기능은 쉽게 사용자 지정을 할 수 없는 웹 파트로부터 나옵니다. 더욱이, WSS만으로 구성된 솔루션은 회사의 ERP 시스템과 같은 외부 데이터 원본을 통합할 필요가 없는 설문 조사에 가장 적합합니다.
사용자 지정 UI를 포함하도록 설문 조사 솔루션을 확장하거나 추가 데이터 원본과 통합해야 할 필요가 있다면 MOSS, WSS, InfoPath를 조합한 솔루션을 진지하게 고려해야 합니다.

완벽한 설문 조사 솔루션
MOSS에는 WSS를 확장하는 많은 기능이 포함되어 있지만, 일단 여기서는 InfoPath Forms Services에 대해 중점적으로 설명하고자 합니다. InfoPath Forms Services를 이용하려면 설문 조사 작성자는 해당 컴퓨터에 InfoPath를 설치하기만 하면 됩니다. 다른 사람들은 웹 브라우저를 통해 설문 조사에 액세스할 수 있습니다.
InfoPath에서 설문 조사 작성자는 브라우저를 사용하여 설문 양식을 작성할 수 있는 옵션을 선택합니다. 이렇게 하면 InfoPath에서는 모든 표준 호환 웹 브라우저에서 볼 수 있는 양식을 만듭니다. 이 웹 기반 양식은 사용자 역할, 세로 텍스트, 대화 상자 작업, 고급 제어와 같은 InfoPath의 일부 고급 기능을 제외하고 기본적으로 InfoPath 양식과 동일한 방식의 기능을 수행합니다. 만들어진 양식은 SharePoint 라이브러리 또는 목록에 게시됩니다. 한편, 디자인 검사라는 InfoPath의 또 다른 기능을 통해 설문 양식이 InfoPath Forms Services와 호환될 수 있도록 합니다.
InfoPath 양식 라이브러리와 브라우저 사용 양식 라이브러리 간에는 아무런 차이가 없습니다. 두 경우 모두 양식 서식 파일은 .xsn 파일입니다. InfoPath Forms Services에서 브라우저에 양식을 표시하거나, 파일을 클라이언트에 다운로드해서 InfoPath에 직접 표시하거나 하는 차이만 있을 뿐입니다. 설문 조사 작성자는 SharePoint 사이트에 대해 최소한 참가자 자격만 갖고 있으면 SharePoint 문서 라이브러리를 사용하여 양식 서식 파일을 게시할 수 있습니다.
응답자는 표준 호환 브라우저를 통해 InfoPath Forms Services 설문 조사를 완료할 수 있으며 응답 내용은 SharePoint 서버로 완벽하게 반환됩니다. SharePoint에서는 Excel, SQL, 또는 네트워크에서 이용 가능한 기타 도구를 사용하여 데이터를 안전하게 저장하고, 구문 분석하고, 공유하고, 분석할 수 있습니다. IT 관리 부서의 지원을 최소화하고도 이러한 모든 작업과 절차를 완수할 수 있습니다.

포스트백과 성능 문제
그러나 성능 문제가 발생할 가능성이 있습니다. 예를 들어 브라우저 사용 양식은 SharePoint 서버의 시스템 계정에서 실행됩니다. 이는 곧 이 양식에 코드 또는 데이터 연결이 포함된 경우(그림 5 참조), 해당 코드나 데이터 연결이 클라이언트가 아니라 서버에서 실행된다는 것을 의미합니다. 그리고 복잡한 양식은 서버에 데이터를 자주 게시해야 하는데 그로 인해 서버의 작업 부하가 늘어나게 됩니다.
그림 5 데이터 연결이 추가된 InfoPath Forms Services 기반 설문 조사 솔루션
그림 5 데이터 연결이 추가된 InfoPath Forms Services 기반 설문 조사 솔루션
설문 조사에서 포스트백을 자주 사용할수록 프런트엔드 웹 서버의 작업 부하가 늘어납니다. 그러나 응답 분기를 구현하는 경우처럼 어쩔 수 없이 포스트백을 수행해야 할 때가 있습니다. 시스템에 미치는 잠재적 악영향을 최소화하려면 설문 조사 작성자가 포스트백 문제를 잘 알고 있어야 하며 포스트백이 불가피한 경우 설문 조사를 구현하는 최선의 방법이 무엇인지 이해하고 있어야 합니다. 예를 들어 설문 조사 작성자는 사용자가 다음 단추를 클릭했을 때 서버로 데이터를 다시 게시하는 마법사와 유사한 설문 조사를 사용해야 합니다. 이렇게 하면 포스트백 횟수를 줄이는 데 도움이 됩니다.
InfoPath Forms Services는 현재 서버에서 활성화된 각 양식의 상태를 유지해야 합니다. 기본 세션 시간 제한은 60분이며, 이는 곧 설문 조사가 복잡하여 응답 기입 시간이 60분 이상 소요되고 이 시간 중 포스트백이 발생하지 않을 경우 서버에서 해당 세션이 종료됨을 의미합니다. 데이터를 입력하더라도 제출하지 않으면 모두 손실되므로 이 경우 응답자는 설문 응답을 처음부터 다시 시작해야 합니다.
많은 응답자가 하나의 설문 조사 양식을 동시에 기입하거나, 설문 조사에 많은 양의 데이터 원본 또는 첨부 파일이 포함되어 있는 경우에는 이러한 문제가 더욱 심각해집니다. 자세한 내용은 "InfoPath 2007 양식의 성능 개선"(msdn2.microsoft.com/bb380251)을 참조하십시오.

보안 관련 고려 사항
보안 문제에 대한 심층적인 논의는 이 기사의 범위를 벗어나지만 몇 가지 보안 관련 고려 사항은 반드시 짚고 넘어갈 필요가 있습니다. 우선, SharePoint와 InfoPath 2007은 Microsoft가 2002년 초에 채택한 신뢰할 수 있는 컴퓨팅 이니셔티브를 준수하고 있습니다. InfoPath 양식에는 제한, 도메인, 완전 신뢰의 세 가지 보안 수준이 있습니다. 또한 기본적으로 InfoPath는 권장 보안 수준을 자동으로 파악하여 양식에 적용합니다.
디지털 서명 기능은 양식이 특정 사용자에 의해 만들어졌거나 그 내용이 작성되었으며 이와 같은 사항이 변경되지 않았음을 확인하는 데 유용합니다. 그리고 IRM(정보 권한 관리)은 서식 파일과 작성된 양식에 대한 액세스를 제한할 수 있습니다. 악의적인 사용자가 유해한 코드가 포함된 양식을 업로드하거나 SharePoint 플랫폼을 이용하여 데이터 연결을 통해 다른 시스템을 공격하는 것을 방지하기 위해 InfoPath는 사용자 배포 양식과 관리자 배포 양식을 구분합니다. 사용자는 사용자 지정 코드가 없는 양식을 업로드할 수 있으며 도메인 간 데이터 연결을 제한하는 도메인 보안 수준만 사용할 수 있습니다. 대다수 설문 조사 솔루션에서는 이 정도 매개 변수로 충분합니다.
리소스에 대한 무제한 액세스를 허용하기 위해 설문 작성 과정에 완전 신뢰 보안 수준이 필요한 경우, 양식을 게시하려면 IT 관리 부서의 승인이 필요합니다. 기본적으로 IT 관리 승인이 필요한 경우로는 양식에 관리 코드가 포함된 경우, 도메인 간 데이터 연결이 양식 서식 파일에 정의되어 있는 경우, 중앙에서 관리되는 데이터 연결 라이브러리에서 정의된 데이터 연결을 양식에서 사용하는 경우, 모바일 장치에서의 렌더링을 지원하는 옵션이 활성화되어 있는 경우를 들 수 있습니다.
완전 신뢰 보안 수준의 경우, 설문 조사 작성자는 InfoPath 양식을 만든 다음 해당 양식 서식 파일을 저장합니다. 이 서식 파일 또는 .xsn 파일은 전자 메일 첨부 파일 또는 네트워크 공유를 통해 SharePoint 관리자에게 전달됩니다. 그러면 IT 관리자는 프로덕션 환경에서 설문 조사를 이용할 수 있도록 하기 전에 해당 설문 조사의 기능과 그 안에 포함된 코드를 확인합니다. IT 관리자는 설문 조사 서식 파일을 사이트 모음에 업로드하고 활성화하여 배포 작업을 완료합니다. 두 절차 모두 WSS 중앙 관리 콘솔의 응용 프로그램 관리 페이지에서 완료됩니다. 결과적으로 IT 관리자는 양식 게시 권한을 개별 부서에 위임하면서도 양식이 기본 데이터 수집을 넘어서는 활동을 하는지 파악할 수 있도록 게시 프로세스를 지속적으로 감독, 관찰할 수 있게 됩니다.
양식에 기본 데이터가 입력되어야 하는 경우, 설문 조사 결과가 다수의 데이터 원본에 제출되어야 하는 경우와 같은 일부 일반적인 시나리오에서는 IT 관리자의 감독이 필요합니다. 기본적으로 도메인 신뢰 양식 서식 파일은 도메인 간 데이터 연결을 설정할 수 없지만 다음의 몇 가지 방법을 통해 이러한 제한 사항을 해결할 수 있습니다.
  • 양식에 완전 신뢰 권한을 부여합니다.
  • 데이터 연결 라이브러리에서 데이터 연결을 사용하여 도메인 신뢰를 만듭니다.
  • 중앙에서 관리되는 연결 라이브러리와 함께 도메인 신뢰를 사용합니다.
완전 신뢰와 중앙에서 관리되는 연결 라이브러리 옵션의 경우 양식을 게시하는 과정에서 관리자의 승인이 필요합니다. 그러나 DCL(데이터 연결 라이브러리)은 사이트 모음 수준으로 유지되는 DCL을 이용하여 사용자가 게시한 양식이 도메인 경계를 통과할 수 있도록 합니다. 이러한 DCL은 개별 부서의 제어 하에 있을 수 있습니다. 그러나 개별 부서에서 자체적으로 서버 기반 데이터 연결을 정의할 수 있도록 허용하는 것은 보안상 문제가 될 수 있다는 점을 알아두어야 합니다.
가장 안전한 방법은 중앙에서 관리되는 연결 라이브러리에서 데이터 연결을 정의한 다음, IT 관리자가 이 데이터 연결을 사용하는 고급 설문 조사 양식을 배포하도록 하는 것입니다. 중앙에서 관리되는 연결 라이브러리는 모든 사이트 모음과 전체 서버 팜에서 이용할 수 있다는 점이 유리합니다. 이로 인해 관리자는 로컬 SharePoint 서버에 없는 데이터 원본에 액세스할 수 있는 중앙 인증 설정을 정의할 수 있습니다. 자세한 내용은 온라인 사이트에서 "데이터 연결, 인증 및 대체 액세스 매핑"(msdn2.microsoft.com/ms771995) 문서를 참조하십시오.

결론
설문 조사는 업종과 규모를 불문하고 모든 기업에서 중요한 업무 정보 및 일반적인 정보를 매우 효과적으로 수집할 수 있는 방법입니다. 그러나 효과적인 설문 조사를 만들기 위해서는 올바른 도구와 철저한 계획, 그리고 기술과 지식이 균형 있게 배합되어야 합니다. 철저한 계획을 미리 수립해 두면 조직 내의 각 부서에서 설문 조사 데이터를 만들고, 보내고, 받고, 저장하고, 분석할 수 있게 해주는 솔루션을 구축하는 데 도움이 될 것입니다.
가장 효과적인 설문 조사는 적시에 알맞은 정보를 산출하는 설문 조사입니다. 필요한 때에 정보를 수집하려면 보안에 영향을 미치지 않고 해당 부서 수준에서 쉽게 설문을 만들고 관리할 수 있는 솔루션이 필요합니다. InfoPath는 별도의 교육을 받지 않고도 사용할 수 있는 직관적인 인터페이스로 되어 있으므로 정보 근로자는 양질의 설문 조사를 구성할 수 있습니다. 또한 InfoPath를 사용하면 IT 관리 부서의 많은 지원 없이도 우수한 설문 데이터를 수집할 수 있습니다.
InfoPath 2007은 WSS 및 MOSS와 완벽하게 연동되므로 플랫폼 간 및 브라우저 간 호환성을 갖춘 다양하고 복잡한 설문 조사 솔루션을 손쉽게 만들 수 있습니다. 따라서 기업에서는 가장 중요한 자산 중의 하나인 정보를 효과적으로 활용할 수 있게 됩니다.
전자 메일을 이용한 신속한 설문 조사
즉석 설문 조사는 소규모 응답자로부터 신속하게 데이터를 수집하기 위해 꼭 필요한 도구입니다. 전자 메일을 이용한 설문은 이러한 종류의 실시간 조사에 활용하기에 가장 좋은 방법입니다. 이러한 설문 조사는 신속하게 구성할 수 있으며 전용 서버나 IT 부서의 지원이 필요하지 않습니다. 가장 간단한 방법은 Microsoft® Outlook® 메시지에 내장된 응답 단추를 사용하는 것으로, 이 방법을 사용하면 1차원 설문 조사를 보내고, 받고, 표로 구성할 수 있습니다.
응답 단추 설문 조사를 실행하면 해당 수신자는 드롭다운 선택 목록이 표시되는 응답 띠가 포함된 전자 메일 메시지를 받게 됩니다. 수신자는 옵션 중 하나를 클릭하여 응답합니다. "답장 보내기: <선택 내용>"이라는 메시지가 팝업 창에 표시되며 답장을 보내거나 고칠 수 있습니다.
설문 작성자 또는 지정된 대리인은 전자 메일로 개별 답장을 받아 해당 결과를 수동으로 표로 작성합니다. 설문 조사의 응답자 수가 많은 경우에는 규칙 마법사를 사용하여 그림 A와 같이 전용 폴더에 답장을 자동으로 전달하는 규칙을 Outlook에서 만들어야 합니다.
그림 A 설문 조사 답장이 전용 폴더에 자동으로 전달됩니다.
그림 A 설문 조사 답장이 전용 폴더에 자동으로 전달됩니다.
그러나 응답 단추를 이용하는 방식에는 제한이 많습니다. 전자 메일 메시지에 설문 양식을 삽입하는 방식은 훨씬 더 많은 데이터를 수집할 수 있으나 이렇게 수집된 데이터를 수작업으로 불러와 표로 만드는 작업은 수습이 불가능할 수 있습니다. 보다 복잡한 방식의 전자 메일 기반 설문 조사로는 VBScript를 사용하여 Outlook 설문 조사를 사용자 지정하는 방법을 들 수 있습니다. 사용자 지정 양식을 이용하면 보다 복잡하고 많은 양의 데이터를 더 쉽게 수집하고 분석할 수 있습니다. Outlook 2007의 개발자 기능을 이용하려면 그림 B에서와 같이 개발자 탭을 먼저 표시해야 합니다.
그림 B Outlook 2007의 개발자 탭
그림 B Outlook 2007의 개발자 탭
사용자 지정 Outlook 양식을 만드는 것은 일반적인 Outlook 사용자의 능력 범위를 넘어서는 작업입니다. 그러나 InfoPath® 2007에서는 사용자 지정 양식을 쉽게 구현할 수 있는 새로운 기능을 제공합니다. 설문 조사 작성자는 특별한 전문 지식 없이도 다음의 세 가지 방법을 통해 InfoPath 양식과 서식 파일을 만들 수 있습니다.
  • 기존 Microsoft Word 문서 또는 Excel® 스프레드시트를 가져옵니다.
  • 미리 디자인된 InfoPath 서식 파일을 다운로드하여 구체적인 요건에 맞게 수정합니다.
  • InfoPath의 양식 디자인 기능을 이용하여 서식 파일을 완전히 새로 디자인합니다.
세 가지 방법 모두 서식 파일을 Outlook에 게시하여 전자 메일을 통해 배포할 수 있습니다. InfoPath 2007과 Outlook 2007을 사용하면, 일반적인 정보 근로자도 20문항의 설문 조사를 만들어 특정 그룹에 전자 메일로 발송하고, Outlook에서 설문 조사 결과를 받아 Excel 스프레드시트에서 해당 데이터를 분석하는 모든 작업을 IT 부서의 특별한 지원 없이 불과 몇 시간 내에 완료할 수 있습니다.
이 시나리오에서 실제로 필요한 사항은 모든 참가자의 컴퓨터에 InfoPath와 Outlook이 설치되어 있어야 한다는 것 뿐입니다. 그리고 InfoPath 2007은 Outlook 2007의 기능을 확장하므로, 수신자는 Outlook 인터페이스 내에서 설문 조사에 즉시 응답할 수 있습니다.
그러나 InfoPath는 단순한 전자 메일 설문 조사 이상의 기능을 지원합니다. 웹 서비스 및 SQL Server® 데이터베이스를 대상으로 데이터를 쿼리하고 제출하는 서식 파일을 만들거나 기존 XML 문서 또는 XML 스키마를 데이터 원본으로 활용할 수 있습니다. 다시 말해, 코드를 추가하지 않고 최소한의 교육만으로도 사용자가 XML의 강력한 기능과 유연성을 활용할 수 있게 되는 것입니다.
전자 메일은 설문 조사 솔루션으로서는 중요한 단점을 갖고 있습니다. 예를 들어 응답자의 전자 메일 주소가 제공되므로 설문 조사가 익명으로 진행되지 않습니다. 이 점은 응답 결과의 정직성을 떨어뜨릴 수 있습니다. 또한 피싱 공격과 같은 보안 문제도 있으므로 전자 메일 기반 설문 조사로 수집할 수 있는 정보의 유형과 깊이에는 한계가 있습니다.

데이터베이스 기반 설문 조사 솔루션 구축
전자 메일 기반 설문 조사는 응답자 수가 많은 복잡한 조사에는 적합하지 않습니다. Outlook®의 폴더 기능만으로 모든 데이터를 관리하고 분석하기란 어렵기 때문입니다. 보다 강력한 솔루션은 설문 조사의 응답을 데이터베이스에 전달하는 것입니다. 데이터베이스 이용을 통해 얻을 수 있는 개선된 수준의 저장, 인덱싱, 처리 및 보고 기능은 매우 유용하게 활용할 수 있습니다. 예를 들어 Microsoft® SQL Server® 2005에는 설문 조사 결과의 자동 처리에 활용할 수 있는 SQL Server Reporting Services가 포함되어 있습니다.
응답을 데이터베이스에 제출하는 InfoPath 양식 서식 파일을 만들려면 우선 네트워크 내부에 Access® 또는 SQL Server 데이터베이스를 만들어야 합니다. 그런 다음 InfoPath®에서 양식 서식 파일 디자인 마법사를 사용하여 서식 파일 작성 프로세스를 시작할 수 있습니다. 그러면 데이터 연결 마법사가 열리고 해당 양식을 데이터베이스에 연결하는 프로세스가 안내됩니다. InfoPath는 데이터베이스의 정보를 이용하여 데이터 원본 쿼리 및 데이터 필드를 만듭니다.
대부분의 작업자들은 별도의 지원이나 교육 없이 설문을 작성하고 제출할 수 있는 지식을 갖추게 될 것입니다. 그러나 데이터가 데이터베이스로 직접 전달되는 이 시나리오의 경우, 응답자의 컴퓨터에 InfoPath와 Outlook이 설치되어 있어야 하며 응답자는 회사 방화벽 내에 있거나 회사 네트워크에 대한 VPN 액세스가 가능해야 합니다.
InfoPath 데이터 연결 마법사는 Microsoft SQL Server 2000 이상 버전, 그리고 ADOXML을 기본적으로 사용하는 Access 데이터베이스와만 연결됩니다. 다른 데이터베이스의 경우 데이터를 직접 제출하는 기능이 지원되지 않습니다. InfoPath의 다른 제한 사항으로는 서식 있는 텍스트 컨트롤을 데이터베이스 필드에 바인딩할 수 없으며 큰 바이너리 데이터 형식이 지원되지 않는다는 점이 있습니다.
네트워크 토폴로지가 갈수록 방대해지고 복잡해지고 있으므로, 중간의 웹 서비스에 데이터를 제출하고 그 데이터를 다시 데이터베이스로 전달하는 방식의 유용성이 증가하고 있습니다. 웹 서비스를 통해 프런트 엔드의 설문 조사 양식과 백 엔드의 데이터베이스를 분리하게 되면 웹 서버에 비즈니스 논리를 구현하는 것도 용이해집니다. 그리고 웹 서비스는 HTTP 또는 HTTPS 연결을 통해 작동하므로 참가자는 그림 C와 같이 방화벽을 통해 데이터를 제출할 수 있습니다. 그러나 응답자의 컴퓨터에 InfoPath 2003 또는 2007이 설치되어 있어야 한다는 점은 동일합니다.
이 시나리오의 단점은 IT 부서의 지원을 통해 구현해야 한다는 점입니다. 이 프로세스를 자세히 설명하는 것은 이 글의 범위를 벗어나지만, 데이터베이스 솔루션을 처음부터 새로 구축하는 것은 상당히 어려운 작업이라는 점을 지적하고자 합니다. 이 작업에는 사전 계획, 올바른 설문 조사 작성, 웹 서비스의 프로그래밍, 데이터베이스 백 엔드의 설계와 같은 작업이 수반되어야 합니다. InfoPath 2007은 이 프로세스에서 양식 디자인 부분을 간편하게 처리하지만, 모든 요소와 범위를 아우르는 완벽한 솔루션을 구축하려면 프로그래밍 및 데이터베이스 설계에 관한 탄탄한 기술이 필요합니다. 그리고 워크플로 또는 다국어 지원 등의 고급 기능을 추가하게 되면 구현 비용이 훨씬 더 상승하게 될 것입니다.
그림 C 웹 서비스를 통한 InfoPath 데이터 흐름
그림 C 웹 서비스를 통한 InfoPath 데이터 흐름

Jim Bradley는 Microsoft 서버 제품용 사용자 지원 설명서를 전문으로 하는 기술 통신 기업 CoyoteTech LLC의 소유주입니다. 이 회사에서 수행한 설명서 프로젝트로는 "Microsoft Exchange Server 2007 Edge Transport and Messaging Protection", "Going 64-Bit with Microsoft Exchange Server 2007", "Microsoft Exchange 2003 Technical Reference Guide" 등이 있습니다.


 Sharepoint: 사용자 지정 콘텐츠 형식을 이용한 데이터 관리의 표준화
Sharepoint Pav Cherny

사용자 지정 콘텐츠 형식을 이용한 데이터 관리의 표준화
한 눈에 보기:
  • SharePoint를 이용한 콘텐츠 수명 주기 관리
  • 문서 정보 창 만들기
  • InfoPath를 통한 Office 및 SharePoint 문서 편집
이 기사의 코드 다운로드: ContentTypes2008_02.exe (779KB)

엔터프라이즈 환경에는 대개 문서와 다른 콘텐츠 항목이 엄청나게 많기 때문에 문서와 그 메타데이터 그리고 그 동작을 중앙 집중적이고 재활용 가능한 방식으로 관리하는 데 많은 기술적, 업무적 어려움이 따릅니다.
Microsoft® Office SharePoint® Server 2007은 한 조직 내의 다양한 팀이 웹 사이트와 문서 라이브러리, 목록 등에서 작업 영역을 공유할 수 있게 함으로써 전사적 공동 작업을 촉진합니다.
SharePoint 2007에서는 콘텐츠 형식을 통해 콘텐츠 및 수명 주기 특징의 여러 측면을 표준화할 수 있습니다. 사이트 콘텐츠 형식이란 특정 사이트 모음, 사이트, 목록 또는 문서 라이브러리에 독립적으로 설정할 수 있는 메타데이터 정의를 말합니다. 이를 통해 전사적인 속성, 워크플로, 정보 관리 정책 및 기타 요소를 일관되게 설정할 수 있으며, 개별 부서나 사이트 담당자는 특정 목적에 맞게 콘텐츠 형식을 사용자 지정할 수 있습니다.
이 문서에서는 Windows® SharePoint Services(WSS) 3.0과 Microsoft Office SharePoint Server(MOSS) 2007에서 도입된 새로운 SharePoint 콘텐츠 모델을 활용하여 일반적인 특성을 기반으로 엔터프라이즈 콘텐츠를 위한 계층 구조를 만드는 방법을 설명하겠습니다. 이러한 콘텐츠 계층 구조를 활용하면 메타데이터와 워크플로, 정보 관리 정책 등을 전역적 수준에서 일관되게 적용하면서, 그와 동시에 사이트 모음과 사이트, 문서 라이브러리, 목록 등의 수준에서 고유한 콘텐츠 관리 요구 사항을 수용할 수 있는 융통성을 확보할 수 있습니다.
SharePoint 콘텐츠 형식의 심층 구조를 일부 살펴볼 수 있도록, 필자는 첨부 자료에 몇 가지 사용자 지정 도구를 포함했으며 구체적인 요구 사항에 맞게 이 도구를 확장할 수 있도록 소스 코드도 포함했습니다. 다만, 이 도구는 철저히 테스트되지 않았으므로 프로덕션 시스템에 사용해서는 안 된다는 점을 기억하시기 바랍니다. 이 코드는 TechNet Magazine 웹 사이트(technetmagazine.com/code08.aspx)에서 다운로드할 수 있습니다.

콘텐츠 수명 주기와 콘텐츠 형식 정의
SharePoint 리소스
  • InfoPath 팀 블로그
  • Office SharePoint Server 2007의 워크플로
  • TechNet 웹캐스트: SharePoint Server 2007 검색 기능의 설치와 구성
  • InfoPath Forms Services

조직 내에서 문서 및 기타 콘텐츠를 관리할 때는 여러 가지 세부적인 사항을 고려해야 합니다. 무엇보다도 콘텐츠가 생성되어 게시되고 보관 및 폐기되는 과정에서 어떤 사람이 또는 어느 프로세스에서 무슨 작업을 수행해야 하는가를 정의해야 합니다. 또한 콘텐츠 생성을 위한 구체적 서식 파일을 개발하고 역할을 정의하여 사용자에게 책임과 액세스 권한을 할당하고, 버전 제어 기능을 제공하고 규정 준수 상태를 모니터링하고 콘텐츠를 저장 및 보관하고 메타데이터를 정의하는 등의 작업도 필요합니다.
수명 주기가 매우 복잡한 콘텐츠도 있지만, SharePoint 콘텐츠 모델은 개별 콘텐츠 항목의 처리 방법을 결정하는 일반적인 특성과 전형적인 단계가 있음을 인지합니다. 예를 들어 서식 파일과 입력 양식을 통해서는 콘텐츠 생성을 구조화하고 메타데이터를 통해서는 콘텐츠 표시와 검색 기능을 구조화할 수 있습니다. 또한 편집, 승인 또는 기타 워크플로 요구 사항, 보관 요구 사항, 만료 기간, 적용 가능한 정보 관리 정책 등을 이용하여 개별 콘텐츠를 구분할 수 있습니다. 일부 콘텐츠는 특별한 서식 파일이 필요 없거나 보관되지 않을 수도 있지만 그러한 특징조차 수명 주기 차원의 특성으로 다른 항목과 구분하는 데 사용됩니다.
SharePoint 콘텐츠 모델을 이용하면 개별 콘텐츠 형식을 정의하고 계층적 관계를 설정할 수 있습니다. 계층적 관계에서는 자식이 부모 콘텐츠 형식으로부터 일반적 특성을 상속받으며, 필요에 따라 특정한 특성이 추가됩니다.
이 점을 살펴보는 가장 좋은 방법은 SharePoint의 기본 제공 콘텐츠 형식을 검토하는 것입니다. WSS 3.0과 MOSS 2007에는 문서, 작업 등 문서 라이브러리 또는 목록에 저장할 수 있는 전형적인 항목을 위해 미리 정의된 콘텐츠 형식이 다수 포함되어 있습니다. SharePoint 서버의 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes 폴더에는 이러한 표준 콘텐츠 형식에 대한 정의가 들어 있습니다. 여기에는 feature.xml이라는 매니페스트 파일이 있습니다. 이 파일을 보면 SharePoint는 표준 콘텐츠 형식 정의를 숨겨진 기능(Hidden="TRUE")으로 사이트 모음 범위(Scope="Site")와 함께 구현하고 있으며 실제 콘텐츠 형식 요소가 들어 있는 Element 매니페스트 파일은 ctypeswss.xml(<ElementManifest Location="ctypeswss.xml" />)임을 알 수 있습니다.
SharePoint 기능에 관심이 있다면 MSDN® Magazine에 실린 Ted Pattison의 Office Space 칼럼 "SharePoint용 기능"(msdnmagazine.com/issues/07/05/OfficeSpace)을 추천합니다.
그러면 메모장에서 ctypeswss.xml 파일을 열고 SharePoint 사용자 인터페이스에서의 가시성에 관계 없이 표준 콘텐츠 형식을 검토해 보겠습니다. ctypeswss.xml을 수정해서는 안 됩니다. SharePoint 사용자가 새로운 콘텐츠 형식을 파생할 때 활용할 수 있도록 ctypeswss.xml 파일을 편집하여 표준 콘텐츠 형식에 새로운 필드를 추가하거나 숨겨진 콘텐츠 형식을 볼 수 있게 하려는 생각을 갖고 있다면, 그것이 불필요한 작업임을 기억하시기 바랍니다. 또한 이렇게 수정한 경우 해당 구성은 지원되지 않으므로 나중에 서비스 팩을 설치하면 사용자 지정 내용을 덮어써서 콘텐츠 관리 솔루션에 문제가 생길 수 있습니다.
그보다는 필요한 내용을 새로운 요소 매니페스트 파일에 복사해서 필요한 사용자 지정 설정을 추가한 다음 사이트 모음 내부의 모든 사이트에서 이용할 수 있도록 사이트 모음 범위와 함께 새로운 기능으로 사용자 지정 콘텐츠 형식을 배포하는 것이 훨씬 좋은 방법입니다.
ctypeswss.xml에 명시된 System 콘텐츠 형식의 CAML(Collaborative Application Markup Language) 기반 정의는 다음과 같습니다.
<ContentType ID="0x"
    Name=$Resources:System
    Group="Hidden"
    Sealed="True"
    Version="0">
   <FieldRefs>
      <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType"/>
   </FieldRefs>
</ContentType>
Group 및 Sealed 특성은 System 콘텐츠 형식이 숨겨지고 봉인되어 있으므로 SharePoint 사용자 인터페이스에서는 변경할 수 없다는 것을 보여 줍니다. System 콘텐츠 형식은 ContentType이라는 기본 제공 사이트 열을 참조하는 단 하나의 FieldRef 요소만 갖고 있습니다. 이것은 가장 높은 수준의 추상화입니다. 다른 모든 SharePoint 콘텐츠 형식은 System 콘텐츠 형식으로부터 이 속성을 상속 받습니다. 이러한 방식으로 SharePoint는 모든 문서 라이브러리 또는 목록에 저장된 모든 콘텐츠 항목이 공통적으로 이 속성을 갖도록 합니다.
그림 1에서는 이 문서의 첨부 자료에 포함되어 있으며 계층 구조를 더 직관적으로 보여 주는 ContentTypeHierarchy 웹 파트를 볼 수 있습니다. System 콘텐츠 형식은 다른 모든 콘텐츠 형식의 루트에 있으며 그 아래 Item이 있고, 그 아래 다른 형식이 계속 이어집니다. 예를 들어 Item 콘텐츠 형식은 다음 수준의 세부 사항을 규정합니다. ctypeswss.xml을 살펴보면 Item 형식은 Title이라는 사이트 열을 참조하는 단 하나의 메타데이터 필드를 정의하고 있음을 알 수 있습니다. 이러한 방식으로 그 아래 수준의 모든 기본 제공 콘텐츠 형식은 Title 속성을 갖게 되는 것입니다.
그림 1 WSS 3.0 기본 제공 콘텐츠 형식 계층 구조
그림 1 WSS 3.0 기본 제공 콘텐츠 형식 계층 구조
ctypeswss.xml의 Document 콘텐츠 형식 정의에서 볼 수 있듯이 상속된 필드를 제거하는 것도 가능합니다. Document 콘텐츠 형식에는 몇 가지 대응되는 RemoveFieldRef 요소가 포함되어 있지만, Title 필드는 사용자 지정 콘텐츠 형식 안에 유지하는 것이 좋을 것입니다. Title 열은 SharePoint 문서 라이브러리 및 목록 보기의 ECB(편집 컨트롤 상자) 드롭다운 메뉴에 대한 액세스를 지원하기 때문입니다.
상속된 필드의 이름을 바꾸는 방법을 잘 보여 주는 좋은 예는 ctypeswss.xml의 Far East Contact 콘텐츠 형식입니다. 대응되는 콘텐츠 형식 ID인 0x0116을 찾은 다음, Name="Title"이라는 특성을 가진 FieldRef 요소를 확인해 보면 DisplayName 특성을 이용하여 사용자 인터페이스의 필드 이름을 변경하는 방법을 알 수 있습니다. 이 예에서 DisplayName 특성은 사용자 인터페이스에 있는 Title 필드의 이름을 "$Resources:core,Last_Name;"에서 참조하는 지역화된 데이터 값으로 변경합니다.
그림 1을 자세히 살펴보면 해당 콘텐츠 형식을 고유하게 나타내는 ContentType 요소의 ID 특성을 통해 계층적 관계가 설정된다는 것을 알 수 있습니다. 부모 콘텐츠 형식의 ID로 시작하는 모든 ID에는 16진수 값이 추가됩니다. 표준 콘텐츠 형식에는 일반적으로 두 개의 16진수 값이 추가되어 자식 콘텐츠 형식의 새로운 고유 ID를 생성합니다. 또 다른 방법은 '00'과 16진수 GUID를 추가하는 것입니다. 예를 들어 Office 데이터 연결 파일 및 유니버설 데이터 연결 파일 콘텐츠 형식은 그와 같은 방법으로 Document 콘텐츠 형식으로부터 파생된 것입니다.
여기서 잊지 말아야 할 중요한 사항은 ContentType 요소의 ID 특성은 1,024자를 넘을 수 없다는 점입니다. 그런데 대규모 계층 관계에서 모든 콘텐츠 형식이 16진수 GUID 주소 지정 기법을 사용할 경우에는 문제가 발생할 수 있습니다. 그러나 처음부터 자릿수 제한이 짧은 방법을 사용하는 것은 ID의 고유성이 손상될 수 있으므로 좋은 생각이 아닙니다.
고유성을 확보하려면 GUID 기법을 이용하여 엔터프라이즈 콘텐츠 형식에 대한 전역 네임스페이스를 설정하고 그 네임스페이스 안에서 자릿수 제한이 짧은 방법으로 전환하는 것이 좋습니다. ID 특성과 콘텐츠 형식 정의의 여러 요소에 대한 자세한 정보는 WSS 3.0 SDK의 '콘텐츠 형식 정의 스키마' 항목을 참조하십시오.

콘텐츠 형식 종속성
그러면 SharePoint 콘텐츠 형식을 이용하여 콘텐츠 항목의 관리 구조를 설정하는 방법에 대해 논의해 보겠습니다. 문서 라이브러리와 목록, 콘텐츠 형식, 사이트 열, 필드 형식 간의 상호 종속성과 같은 몇 가지 종속성을 고려해야 합니다. 종속성을 자세히 살펴보면, 라이브러리와 목록은 콘텐츠 형식을 참조하고, 콘텐츠 형식은 사이트 열을 참조하고, 다시 사이트 열은 필드 형식(예: 텍스트, 메모, 선택, 숫자, 통화 등의 표준 WSS 필드 형식)을 참조하고, 필드 형식은 WSS 핵심 어셈블리인 Microsoft.SharePoint.dll과 같은 Microsoft .NET Framwork 어셈블리 안에 있습니다.
앞서 System 콘텐츠 형식 매니페스트 파일 항목의 CAML 정의에서 살펴본 System 콘텐츠 형식으로 돌아가 보겠습니다. 살펴보면 알 수 있듯이 이 콘텐츠 형식에는 ContentType이라는 사이트 열을 참조하는 FieldRef 요소가 있습니다. 이 콘텐츠 형식 정의는 실제 ContentType 사이트 열을 정의하지 않는다는 점에 유의하십시오. ContentType은 텍스트 필드로서 Elements 매니페스트 파일 fieldswss.xml(%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields 폴더)에 정의되어 있습니다. 그리고 텍스트 필드 형식은 fldtypes.xml에 정의되어 있으며 이 파일은 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\XML 폴더에 있습니다. 이 종속성 트리에서 반드시 기억해야 할 중요한 사항은 SharePoint 서버에서 모든 리소스를 이용할 수 있도록 해야 한다는 점입니다.
사용하고자 하는 콘텐츠 형식은 문서 라이브러리 및 목록의 사이트 수준 또는 그 이상의 사이트 계층 구조에서 생성되어야 합니다. 마찬가지로, 콘텐츠 형식의 메타데이터 필드는 반드시 기존 사이트 열을 참조해야 합니다. 표준 또는 사용자 지정 필드 형식을 기반으로 표준 또는 사용자 지정 사이트 열을 콘텐츠 형식에 추가할 수 있지만, 반드시 그 사이트 열이 로컬 사이트에 있어야 합니다. 더욱이 사용자 지정 필드 형식을 사용하려면 기반 .NET 어셈블리가 SharePoint 서버에 배포되어 있어야 합니다.
문서 서식 파일, 사용자 지정 이벤트 수신기, 워크플로 및 기타 구성 요소를 참조하는 콘텐츠 형식에 이와 유사한 종속성이 존재합니다. 예를 들어 이 콘텐츠 형식 정의에는 해당 콘텐츠 형식과 연결된 문서 서식 파일을 가리키는 DocumentTemplate 요소가 포함될 수 있습니다. 또한 XmlDocuments 요소 하나와 함께, 네임스페이스 정의, 문서 정보 창 정의 또는 사용자 지정 정보 등 콘텐츠 형식의 추가적 특성을 정의하는 하나 이상의 XmlDocument 자식 요소를 포함할 수도 있습니다.

전역 콘텐츠 형식 설정
제작 권한을 가진 사용자는 SharePoint 사용자 인터페이스에서 직접 새로운 콘텐츠 형식과 사이트 열을 만들 수 있지만, 만들어진 콘텐츠 형식은 사이트 계층 구조에서 해당 로컬 사이트와 그 아래 위치에서만 이용할 수 있습니다. 사용자 지정 사이트 열은 로컬 사이트에서만 이용할 수 있습니다. 따라서 전역 콘텐츠 형식을 설정하려면 이것으로는 충분치 않습니다. 전역 콘텐츠 형식은 시스템 환경의 모든 사이트 모음에서 이용할 수 있어야 합니다. 바로 이런 경우에 SharePoint 기능을 이용하면 매우 편리합니다. 여러 사이트 모음에 SharePoint 기능을 설치하고 활성화하면 모든 위치에 일관되게 해당 사이트 열과 콘텐츠 형식 정의를 적용할 수 있으므로 매우 간단합니다.
이 문서의 첨부 자료에는 전역 콘텐츠 형식을 설정하는 방법을 보여 주는 AdventureWorks라는 샘플 기능이 들어 있습니다. 이 기능은 제안서와 판매 자료 등 모든 유형의 고객용 자료를 생성하는 데 활용할 수 있는 Customer Documentation이라는 일반적인 콘텐츠 형식을 정의합니다. 이러한 유형의 문서는 모두 회사 이름, 연락처 세부 정보, 주소 등의 고객 정보와 연결되어야 한다고 가정하는 것이 일반적입니다. 필자는 특별히 콘텐츠 형식으로 Customer Name이라는 사용자 지정 필드를 만들고 Department와 Primary Phone과 같은 기본 제공 필드를 몇 개 추가했습니다. 콘텐츠 형식과 필드를 변경하려면 ContentTypes.xml 파일을 편집하고 필드 참조를 변경하려면 첨부 샘플의 SiteColumns.xml 파일을 편집해야 합니다.
readme.htm 파일의 설명대로 이 기능을 배포하면 여러 사이트 모음에서 일관되게 활성화할 수 있습니다. 그러면 Customer Documentation 콘텐츠 형식을 전역에서 사용할 수 있습니다. 이를 이용하면 개별 부서에서는 대상으로 지정된 문서 서식 파일과 연결되어 있는 파생된 콘텐츠 형식을 통해 특정 고객 문서 자료를 생성할 수 있습니다. 첨부 자료에는 영업 및 컨설팅에 활용할 수 있는 샘플 문서 서식 파일이 들어 있습니다. 그림 2에서는 그에 따라 생성되는 콘텐츠 형식을 볼 수 있습니다.
그림 2 Customer Documentation을 위한 부모 및 자식 콘텐츠 형식
그림 2 Customer Documentation을 위한 부모 및 자식 콘텐츠 형식
WSS 3.0과 MOSS 2007에서는 몇 가지 옵션을 선택하여 사용자 지정 사이트 열과 콘텐츠 형식을 위한 기능을 생성할 수 있습니다. WSS 3.0 SDK를 학습하면 XML 파일을 처음부터 새로 작성할 수 있습니다. 또한 SharePoint Designer를 사용하여 개인 웹 패키지로 목록을 내보내고, 그에 따라 생성되는 .fwp 파일의 이름을 .cab 파일로 변경하고, 이 cab 파일에서 manifest.xml 파일을 추출하여 추출된 파일에서 ContentType 정의를 검색할 수도 있습니다. 그러나 유감스럽게도 두 방법 모두 불편하고 오류 발생 가능성이 높습니다.
이와 대조적으로, SharePoint 사용자 인터페이스에서는 훨씬 쉽게 사용자 지정 사이트 열과 콘텐츠 형식을 생성할 수 있습니다. 그러나 이 인터페이스에서는 기능에 대한 XML 파일을 편집할 수 있는 옵션이 제공되지 않습니다. 기능은 SharePoint 리소스를 효율적으로 프로비전할 수 있는 방법이지만 일단 프로비전된 리소스는 콘텐츠 데이터베이스 안에만 존재합니다. 향후 출시되는 WSS 버전은 웹 파트를 내보내는 기능과 유사하게, SharePoint 사용자 인터페이스를 통해 XML 파일로 사이트 열과 콘텐츠 형식을 내보낼 수 있는 기능을 포함하게 될 것입니다. 그러나 지금은 현재 가지고 있는 기능을 활용해야 합니다.
첨부 자료에 포함된 ContentTypeSchema라는 웹 파트를 출발점으로 활용할 수 있을 것입니다. 이 웹 파트는 SharePoint 개체 모델을 이용하여 선택된 콘텐츠 형식으로부터 SchemaXML 속성을 추출합니다. XSLT(eXtensible Stylesheet Language Transformation) 기반 변환을 통해 이 웹 파트는 표시 단추를 클릭하기 전에 사용자 인터페이스에서 선택한 옵션에 따라 Field 정의 또는 ContentType 정의를 파생합니다.
그림 3에서는 이 웹 파트가 실제로 적용된 모습을 보여 줍니다. 여기에는 Customer Documentation 콘텐츠 형식을 기반으로 구성된 Active Directory® Documentation 콘텐츠 형식이 표시됩니다. Active Directory Documentation 콘텐츠 형식은 사용자 지정 Microsoft Word 서식 파일(Active Directory Template.dot)과 연결됩니다. 이 콘텐츠 형식에는 추가 필드가 없다는 점에 유의하십시오. 이 형식에서는 모든 필드가 부모 콘텐츠 형식으로부터 상속됩니다.
시스템 환경에서 이 ContentTypeSchema 웹 파트를 사용할 계획이라면, 이 웹 파트가 철저히 테스트되지 않았음을 유념하시기 바랍니다. 필자의 웹 파트는 비교적 복잡한 XSL 변환을 이용하여 현재 선택된 콘텐츠 형식의 SchemaXML 속성과 그 부모 콘텐츠 형식 사이에 델타 관계를 형성하고 있습니다. 그러나 XSLT 1.0은 아직 고급 XML 문서 변환에 맞게 제대로 설계되지 않았습니다. XML 노드를 비교할 수 있는 기본 제공 기능이 없으며 또한 CDATA 섹션과 XML 네임스페이스 역시 XSLT 1.0에서 효율적으로 처리할 수 없는 어려움을 드러냅니다.
SharePoint는 SharePoint 사용자 인터페이스 또는 SharePoint 개체 모델을 사용하여 만든 사이트 열 및 사이트 콘텐츠 형식의 정의를 콘텐츠 데이터베이스의 ContentTypes라는 테이블에 저장합니다. 그림 3에서는 필자가 만든 사용자 지정 콘텐츠 형식의 ID를 볼 수 있습니다. 다음 T-SQL 문은 그에 따라 정확한 결과를 산출합니다. SELECT Definition FROM ContentTypes WHERE ContentTypeId = <content type ID>
그림 3 ContentTypeSchema의 사용자 지정 콘텐츠 형식 정의 웹 파트
그림 3 ContentTypeSchema의 사용자 지정 콘텐츠 형식 정의 웹 파트
어떤 방식을 선택하든 일단 사이트 열 및 콘텐츠 형식 정의를 확보한 후에는 전사적 콘텐츠 형식을 위한 기능을 만드는 것은 매우 간단합니다. 부서 또는 회사의 모든 전역 사이트 열과 콘텐츠 형식에 한 가지 기능을 사용하는 것이 좋습니다. 그렇게 하면 어디에 새로운 사이트 열과 콘텐츠 형식 정의를 추가할 것인지 분명해집니다.

사용자 지정 메타데이터에 대한 전사적 검색
콘텐츠 형식 계층 구조가 제공하는 직접적인 이점의 하나는 모든 자식 콘텐츠 형식이 부모 콘텐츠 형식의 메타데이터 필드를 상속한다는 점입니다. 모든 콘텐츠 형식이 공통적으로 메타데이터 필드를 갖기 때문에 문서 라이브러리에서 사용자 지정 보기와 필터를 만들기가 매우 쉽습니다.
AdventureWorks 샘플 기능은 이 점을 매우 직관적으로 보여 줍니다. 컨설턴트 또는 영업 담당자가 어떤 콘텐츠를 만들든, 만들어진 Word 2007 문서를 문서 라이브러리에 저장하려면 고객 이름(Customer Name)을 반드시 지정해야 합니다. Customer Documentation 부모 콘텐츠 형식에서 이 메타데이터 필드를 필수 필드로 정의하기 때문입니다. 그림 4에서와 같이, 컨설턴트와 영업 팀 구성원은 문서 라이브러리 보기의 항목을 Customer Name에 따라 분류하거나 필터링함으로써 고객에 대한 모든 기존 문서를 신속하고 편리하게 찾을 수 있습니다.
그림 4 공통 메타데이터에 근거한 문서 라이브러리의 다양한 문서 분류
그림 4 공통 메타데이터에 근거한 문서 라이브러리의 다양한 문서 분류
또한 공통 메타데이터를 이용하면 WSS 3.0 및 MOSS 2007을 사용하여 여러 문서 라이브러리와 사이트의 콘텐츠를 찾는 작업도 간편해집니다. WSS는 단일 사이트 모음 안에서 라이브러리와 목록, 사이트 전체를 검색하는 기능을 지원합니다. MOSS 2007은 이러한 기본적인 기능에 그치지 않고, 전사적 '검색 센터'를 구현하고 SharePoint 3.0 중앙 관리 사용자 인터페이스에서 사용자 지정 메타데이터를 관리할 수 있도록 하고 있습니다. 이러한 이유로 이제부터는 MOSS 2007을 집중적으로 설명하겠습니다.
MOSS 2007에서 SSP(공유 서비스 공급자)를 구성하여 SharePoint 사이트를 크롤링하면 MOSS 2007은 콘텐츠 소스에서 사용되는 사용자 지정 메타데이터 필드를 자동으로 검색할 수 있습니다. 따라서 크롤링된 속성 목록에서 사용자 지정 메타데이터 필드를 찾을 수 있습니다.
SharePoint 기능에서 정의된 메타데이터 필드는 일반적으로 SharePoint 범주로 분류됩니다. SharePoint 중앙 관리에서 그 위치를 찾으려면 공유 서비스 관리 아래의 빠른 실행 메뉴에서 SSP로 연결되는 링크를 클릭하고 검색 설정, 메타데이터 속성 매핑을 클릭한 다음, 빠른 실행 메뉴에서 크롤링된 속성을 클릭하고 계속 진행하여 SharePoint 범주를 엽니다.
이에 대한 실제 사례를 설명하도록 하겠습니다. Customer Name이라는 메타데이터 필드는 ows_Customer_x0020_Name이라는 크롤링된 속성이 됩니다. SharePoint에서는 크롤링된 속성 앞에 "ows_"라는 접두사를 붙이며, "_x0020_"은 공백 하나를 코드 형태로 나타낸 것입니다. 이 크롤링된 속성의 세부 정보를 표시하면 사용자가 콘텐츠 검색을 수행할 때 이 크롤링된 속성의 값을 채택할 수 있도록 검색 인덱스에 기본적으로 포함되어 있음을 확인할 수 있습니다. 그러나 검색 정확도를 높이기 위해, 사용자들이 명시적으로 고객 이름으로 콘텐츠를 검색할 수 있도록 크롤링된 속성을 관리 속성에 매핑하는 것은 바라지 않을 것입니다.
크롤링된 속성을 관리 속성에 매핑할 때는 두 가지 옵션을 사용할 수 있습니다. 크롤링된 각 속성에 대해 새로운 관리 속성을 자동으로 생성하거나 크롤링된 속성을 관리 속성에 수작업으로 매핑할 수 있습니다. 첫 번째 옵션은 원하는 크롤링된 속성 범주의 설정을 표시할 때 사용할 수 있습니다. SharePoint 범주과 같은 특정 범주에서 크롤링된 속성을 표시할 때, 빠른 실행 링크의 범주 편집 옵션을 클릭합니다. 대량 크롤링 속성 설정에서 "이 범주에서 검색한 각 크롤링 속성에 대해 새 관리 속성을 자동으로 생성"이라는 확인란을 선택해야 합니다. 그러나 SharePoint는 자동으로 생성된 관리 속성에 "ows"라는 접두사를 붙이고 공백은 "x0020"으로 이스케이프합니다. 크롤링된 속성 ows_Customer_x0020_Name에 대한 관리 속성은 owsCustomerx0020Name이 됩니다. 그러나 이것은 사용자에게 친숙한 속성 이름이 아닙니다.
아마도 전사적 콘텐츠 형식을 배포한 후 크롤링된 속성을 관리 속성에 수작업으로 매핑하는 것이 더 나은 방법일 것입니다. 크롤링된 속성 하나를 하나 이상의 관리 속성에 매핑할 수 있습니다. 새로운 관리 속성을 만들려면 SharePoint 중앙 관리의 공유 서비스 관리 아래 빠른 실행 메뉴에서 SSP로 연결되는 링크를 클릭하고 검색 설정을 클릭한 다음, 메타데이터 속성 매핑이 진행되면 새 관리 속성을 클릭하여 필요한 정보를 지정하고 새로운 관리 속성을 원하는 크롤링된 속성과 연결합니다.
그러면 사용자는 '속성:' 구문의 관리 속성을 이용하거나 고급 검색을 활용하여 관련 콘텐츠 항목을 찾을 수 있습니다. 예를 들어 크롤링된 속성 ows_Customer_x0020_Name을 Customer라는 이름의 관리 속성에 매핑한 경우 사용자는 Customer: Contoso와 같이 Customer: <Customer Name> 형식의 이름을 표준 검색 상자에 지정하여 고객의 모든 문서를 검색할 수 있습니다.
콘텐츠 형식의 가장 중요한 메타데이터 필드에 대한 관리 속성을 고급 검색 페이지의 속성 목록에 포함하는 것도 좋은 생각입니다. 이 작업을 수행하려면 고급 검색 페이지를 표시한 다음 온사이트 작업을 클릭하고 페이지 편집 명령을 선택합니다. 이제 고급 검색 상자에서 편집을 클릭하면 공유 웹 파트 수정 옵션을 선택할 수 있습니다. 속성 범주를 펼치고 해당되는 텍스트 필드에 커서를 올려 놓으면, 속성 XML 문서 편집 단추를 클릭할 수 있습니다. <PropertyDef Name="Customer" DataType="text" DisplayName="Customer Name"/>과 같은 <PropertyDefs> 요소에 속성 정의를 추가해야 하며, <PropertyRef Name="Customer" />와 같은 ResultType 요소 아래에 이 속성 정의에 대한 참조도 추가해야 합니다(예: <ResultType DisplayName="All Results" Name="default"> 요소). 그림 5a는 그에 따른 고급 검색 사용자 인터페이스를 보여 줍니다. 그림 5b는 검색 결과 페이지입니다.
그림 5a 고객 이름을 사용한 IT 인프라 문서 자료 검색
그림 5a 고객 이름을 사용한 IT 인프라 문서 자료 검색
그림 5b 고객 이름 검색 결과
그림 5b 고객 이름 검색 결과

정보의 일관성 보장
지금까지 MOSS 2007을 기반으로 가장 중요한 메타데이터 필드와 콘텐츠 형식을 표준화하고 검색 기능을 엔터프라이즈의 사이트 모음 전체로 확장해 보았습니다. 이제는 사용자가 메타데이터 필드에 정확한 정보를 입력하도록 하는 것이 중요합니다.
그 방법에는 두 가지가 있습니다. 첫째, 목록 상자와 같이 사용자에게 미리 정의된 입력 옵션 선택 기능을 제공하는 사용자 지정된 InfoPath® 양식으로 문서 서식 파일의 표준 문서 정보 창을 대체할 수 있습니다. 둘째, 이벤트 수신기를 콘텐츠 형식에 바인딩한 다음, 사용자가 해당 콘텐츠 항목을 생성, 수정 또는 삭제할 때마다 메타데이터 및 기타 정보의 정확성을 확인할 수 있습니다.
두 방식은 서로를 보완합니다. InfoPath 양식은 주로 SharePoint 콘텐츠 형식의 속성을 보다 쉽게 편집할 수 있도록 하며, 이벤트 수신기는 사용자가 InfoPath 양식 밖에서 콘텐츠 형식 속성을 편집하는 경우에도 메타데이터의 유효성을 확보할 수 있게 해 줍니다. 이벤트 처리기를 특정 콘텐츠 형식에 바인딩할 수 있으며, 이렇게 하면 문서 라이브러리에 관계없이 모든 사이트 모음의 개별 콘텐츠 형식에 연결된 모든 문서에 대한 이벤트와 그에 대한 응답을 지정할 수 있습니다. 이벤트 처리기의 개발 및 배포 방법에 관한 자세한 설명은 msdn2.microsoft.com/ms453149를 참조하십시오.
콘텐츠 형식을 사용자 지정 문서 정보 창에 연결하는 가장 쉬운 방법은 콘텐츠 형식의 문서 정보 창 설정을 InfoPath 2007이 설치된 컴퓨터의 SharePoint 사용자 인터페이스에 표시하는 방법일 것입니다. 그러면 문서 정보 창 서식 파일의 새 사용자 지정 서식 파일 만들기 링크를 클릭하여 InfoPath 2007을 디자인 모드에서 시작할 수 있습니다. 그러나 명시적인 SourceID 특성이 없는 사이트 열이 사이트 콘텐츠 형식에 포함되어 있다면 InfoPath에서 문서 정보 창 양식에 맞는 유효한 XSD 스키마를 만들지 못할 수 있습니다. 예를 들어 이전에 도입된 Customer Documentation 콘텐츠 형식에는 그림 6에서 볼 수 있는 것처럼 Department, Office 및 전자 메일 등 이러한 문제를 야기할 수 있는 몇 가지 연락처 열이 포함되어 있습니다.
그림 6 InfoPath 2007의 XSD 스키마 비호환성
그림 6 InfoPath 2007의 XSD 스키마 비호환성
이러한 문제가 발생할 경우에 사용할 수 있는 두 가지 옵션이 있습니다. 즉, 명시적인 SourceID 특성이 없는 사이트 열에 대한 참조를 콘텐츠 형식 정의에서 제거하거나, 문제를 야기하는 기본 제공 사이트 열을 InfoPath 2007과 호환되는 사용자 지정 사이트 열로 대체할 수 있습니다. 단, 콘텐츠 데이터베이스에 프로비전된 후에는, 특히 자식 콘텐츠 형식을 이미 생성한 후에는 CAML 기반 콘텐츠 형식의 필드 참조를 변경할 수 없다는 점을 기억해야 합니다. Windows SharePoint Services에서는 부모 콘텐츠 형식 정의에 대한 변경을 추적하지 않기 때문에 더 이상은 간단히 CAML 기반 콘텐츠 형식 정의를 업데이트할 수 없으며 변경 사항이 자식 콘텐츠 형식에 자동으로 상속되지도 않습니다.
변경 사항이 자동으로 적용되게 하려면 SharePoint 사용자 인터페이스 또는 개체 모델을 통해 부모 콘텐츠 형식을 변경하거나 기존 콘텐츠 형식으로부터 파생된 새로운 콘텐츠 형식을 정의해야 합니다. 새로 콘텐츠 형식을 정의하는 방법을 사용하면 중요 필드를 제거하고 새로운 열을 추가할 수 있습니다. 그러면 새로운 콘텐츠 형식에서 다른 콘텐츠 형식이 파생될 수 있습니다. 사용자가 잘못된 콘텐츠 형식을 선택하는 것을 방지하려면 기존 콘텐츠 형식을 _Hidden 콘텐츠 형식 그룹에 추가하십시오.
앞서 언급했듯이, 배포 및 활성화를 수행한 후에는 CAML 기반 콘텐츠 형식을 업데이트할 수 없습니다. 따라서 배포 전에 전역 콘텐츠 형식을 테스트하는 것이 매우 중요합니다. 자세한 내용은 MSDN 문서 "콘텐츠 형식 업데이트"(msdn2.microsoft.com/aa543504)를 참조하십시오.
적절한 필드 참조를 사용하여 콘텐츠 형식을 만들었으면 InfoPath 2007에서 사용자 지정 문서 정보 창을 만들 수 있습니다. 가장 좋은 방법은 사이트 소유자가 자신의 자식 콘텐츠 형식에 맞는 사용자 지정 문서 정보 창을 만들도록 하는 것입니다. InfoPath 2007에서 제공하는 사용자 지정 문서 정보 창을 선택된 콘텐츠 형식에 직접 게시할 수 있도록 하는 옵션을 사용하면 배포가 간편해집니다. 그러나 InfoPath 양식을 문서 라이브러리와 같은 중앙 위치에 게시하고 콘텐츠 형식에 문서 정보 창에 대한 참조를 포함하는 것도 가능합니다. CAML 콘텐츠 형식과 함께 사용자 지정 문서 정보 창을 제공할 계획이라면 이것이 가장 좋은 방법입니다. 그림 7에서는 구현 아키텍처를 보여 줍니다.
그림 7 MOSS 2007의 중앙 위치에 XSN 파일 구현
그림 7 MOSS 2007의 중앙 위치에 XSN 파일 구현
이 문서와 함께 제공되는 다운로드 자료에는 InfoPath 2007과 호환되는 사이트 열을 추가함으로써 기존 AdventureWorks 기능을 확장하는 AdventureWorks_Update라는 기능이 포함되어 있습니다. AdventureWorks_Update 기능은 원래의 Customer Documentation 콘텐츠 형식을 숨김으로 표시하고 Customer Docs라는 새로운 콘텐츠 형식을 파생합니다. 이 콘텐츠 형식에서는 상속된 기본 제공 필드가 새로운 사이트 열로 교체되며 새로운 콘텐츠 형식은 사용자 지정 문서 정보 창과 연결됩니다.
새로운 Customer Docs 콘텐츠 형식 정의에는 문서 정보 창에 대한 정보를 제공하는 XmlDocument 요소가 있습니다. 구체적으로, xsnLocation 요소는 문서 정보 창을 구현하는 InfoPath 양식 http://companyresources/DIPs/customerDIP.xsn을 가리킵니다. AdventureWorks_Update 기능을 적용하는 방법에 대한 자세한 설명은 AdventureWorks_Update 폴더의 readme.htm 파일을 참조하십시오.

요약
SharePoint 콘텐츠 형식을 활용하면 메타데이터 정책을 만들어 엔터프라이즈 전역에서 콘텐츠 관리에 일관되게 활용할 수 있습니다. 콘텐츠 형식의 계층 구조는 전체 엔터프라이즈 환경에 관련된 특성을 표준화하고 상속을 통해 모든 사이트에 일률적으로 적용할 수 있게 해 줍니다.
다른 무엇보다도, 사용자가 특정 콘텐츠를 신속하고 편리하게 찾을 수 있도록 MOSS 2007의 기본 제공 검색 기능을 확장하는 것이 가능합니다. 또한 메타데이터와 관련하여 정보의 일관성을 강제하고 중앙 집중적인 정보 관리 정책을 설정할 수 있습니다. 가장 좋은 방법은 향후 변경의 필요성을 최소화할 수 있도록 가장 추상적인 메타데이터 특성을 기반으로 전역 콘텐츠 형식을 표준화하는 것입니다. SharePoint 콘텐츠 형식은 면밀히 설계된 콘텐츠 모델을 기반으로, 엔터프라이즈 전체의 콘텐츠 수명 주기 관리를 표준화하는 새로운 기능을 제공할 수 있습니다.

Pav Cherny는 Biblioso Corporation의 대표로, 공동 작업 및 통합된 커뮤니케이션을 위한 Microsoft 기술을 전문으로 하는 IT 전문가이자 저술가입니다. 출간 저서의 주된 주제는 IT 운영 및 시스템 관리입니다.


 Office Communications Server: 현재 상태 정보로 더욱 향상된 OCS 2007
Office Communications Server Rajesh Ramanathan

현재 상태 정보로 더욱 향상된 OCS 2007
한 눈에 보기:
  • 권한 부여 및 디렉터리 서비스
  • OCS 2007의 메시징 옵션
  • 현재 상태를 사용한 통신 라우팅

Microsoft Office Communication Server(OCS) 2007은 Live Communication Server(LCS) 2005 릴리스의 강력한 기능에 기반을 두고 만들어졌습니다. LCS 2005에서는 엔터프라이즈급 IM(인스턴트 메시징)과 현재 상태를
제공합니다. 또한 LCS 2005에는 RCC(원격 통화 제어)를 통한 기존 PBX 설비와의 전화 통신 통합이 도입되었습니다.
OCS 2007은 LCS 2005의 현재 상태 및 IM 기능을 한 단계 향상시켰으며 고급 미디어 및 전화 기능을 추가하여 Office Communicator 2007을 완전한 "소프트웨어 전화기(소프트폰)"로 만들었습니다. Microsoft는 기존의 PBX와 함께 또는 그 자체로 완전한 솔루션으로서 조직의 모든 통신 요구 사항을 만족하는 미디어용 에지 서버와 회의 서버를 개발했습니다.
Office Communicator 2007은 사용자가 선호하는 USB 장치를 선택할 수 있는 "소프트폰" 기능을 제공하며 대기 후 전송과 같은 일반적인 통화 제어 기능을 쉽게 찾아서 사용할 수 있는 기능이 풍부한 최종 사용자 환경을 제공합니다. 사용자는 더 이상 전화 번호를 기억하거나 다이얼패드를 사용할 필요가 없습니다. 대신 마우스 단추만 클릭하여 데스크톱 응용 프로그램에서 전화를 걸거나 사용자 또는 메일 그룹을 대화로 끌어서 놓기만 하여 전화 회의를 시작할 수 있습니다.
실제 사무용 전화가 필요한 사용자를 위해 Office Communicator Phone Edition(또는 Tanjay 전화)은 터치 스크린을 통한 상황에 맞는 메뉴와 Office Communicator의 친숙한 현재 상태 기능을 사용함으로써 또 다른 끝점 역할을 합니다.
OCS 시스템의 이러한 기능들은 사용자 현재 상태의 개념에 기반을 두고 있습니다. OCS 2007은 사용자 현재 상태, 통신 끝점 및 사용자 관계를 기반으로 특정 시점에 가장 적절한 통신 수단을 사용하여 사용자를 연결합니다. 또한 OCS에서는 음성, 전자 메일, IM 및 기타 통신 경로가 통합되어 가장 효율적인 방법으로 메시지를 라우팅할 수 있게 되었습니다.
이 문서에서는 OCS 2007 솔루션에 대해 간단히 살펴보고 솔루션의 다양한 부분이 어떤 식으로 연결되는지 알아보겠습니다. 또한 통합 통신 환경에서 현재 상태 정보가 중요한 요소로 작용하는 방법 및 이러한 현재 상태 정보를 사용하여 음성 호출을 보다 효과적으로 라우팅하는 방법을 알아보겠습니다.

권한 부여 및 디렉터리 서비스
기업의 음성 시스템은 호출을 하도록 허용된 사용자의 신원을 확인할 수 있어야 합니다. 또한, 호출 단위로 제한이나 정책을 적용할 수 있어야 합니다. VoIP(Voice over IP) 시스템의 경우 호출을 시작하려면 클라이언트가 서버에 대해 인증해야 합니다. 이는 회선에 대한 액세스만으로 신원을 확인하는 데 충분한 기존의 PBX 시스템과 비슷합니다.
그림 1에 나오는 OCS 2007 시스템에서는 인증 및 액세스 정책의 저장을 위해 Active Directory®를 사용하며 Active Directory 사용자에 대한 정책에 대해 호출의 유효성을 검사하여 호출에 권한을 부여합니다. OCS는 Exchange Server나 Microsoft® Outlook® 같은 다른 Microsoft 응용 프로그램에서 사용하는 것과 같은 Active Directory 정보를 사용하므로 사용자 속성 및 정책을 확장하고(Active Directory 스키마 확장 사용) 음성 또는 IM과 같은 실시간 응용 프로그램에 사용할 수 있는 통합 디렉터리를 제공하여 Active Directory의 기존 사용자에게 간단히 음성 기능을 추가로 제공할 수 있습니다.
그림 1 OCS 통합 통신 구성 요소
그림 1 OCS 통합 통신 구성 요소
Active Directory에서 통합 통신과 관련된 가장 중요한 속성은 SIP URI라고도 하는 SIP(Session Initiation Protocol) 주소이며 이는 기본적으로 사용자의 전자 메일 주소와 매우 비슷합니다. 예를 들어 전자 메일 주소가 someone@contoso.com인 Active Directory 사용자에게는 sip:someone@contoso.com이라는 SIP 주소가 할당됩니다. SIP 주소는 사용자 개체에 연결되기 때문에 사용자가 데스크톱 컴퓨터나 Exchange 서버 로그온 시 사용하는 자격 증명으로 OCS 서버에 로그인할 수 있는 경우에는 단일 ID를 제공할 수 있습니다.
또 다른 중요한 속성으로는 사용자의 전화 번호가 있습니다. OCS 서버는 내부적으로 전화 번호로 전송된 전화의 대상을 사용자의 SIP URI로 다시 지정하여 호출을 라우팅할 수 있도록 합니다.
OCS 2007은 조직 내의 디렉터리를 검색하는 데 사용할 수 있는 ABS(주소록 서비스) 인터페이스를 제공합니다. 주소록의 오프라인 버전인 ABS를 통해 클라이언트 측에서 검색 작업을 수행할 때마다 클라이언트 끝점이 Active Directory에 연결할 필요가 없습니다.
ABS 외에도 OCS 2007에서는 사용자가 Outlook에서 보는 메일 그룹을 Office Communicator에서도 보고 Communicator에서 메일 그룹을 확장할 수 있도록 지원하는 DLX(메일 그룹 확장) 서비스를 제공하므로 메일 그룹을 더욱 유용하게 사용할 수 있습니다. 사용자는 Office Communicator에서 직접 또는 그룹 IM 채팅을 시작하여 메일 그룹 구성원과의 전화 회의를 설정할 수 있습니다.

음성 및 메시징 서비스
추가 OCS 리소스
자세한 내용은 다음 리소스를 참조하십시오.
  • 통합 통신 이벤트 및 웹캐스트
  • Microsoft Office Communications Server 2007
  • TechNet Virtual Lab: 사용자 활성화 및 Office Communicator 2007 설치

기업의 음성 솔루션은 사용자에게 가장 친숙한 통화 제어 기능을 제공해야 합니다. 이를 염두에 두고 만들어진 OCS 2007은 통화 대기, 통화 전송, 문의 후 전송, 착신 전환, 동시 신호 울림, IM과 같은 비음성 모드 등의 일반적인 기능을 제공합니다.
OCS 2007은 아웃바운드 및 인바운드 호출 라우팅 기능을 제공함으로써 음성 호출 라우팅의 핵심 역할을 합니다. 아웃바운드 호출 라우팅에는 번호 변환, 사용자에게 관련 정책(예: 국제 통화 제한) 적용, 적절한 끝점 또는 외부의 PSTN(공중 전화망)으로 호출 라우팅 등의 작업이 포함됩니다. 인바운드 호출 라우팅 기능은 사용자가 선택한 착신 전환 또는 시간/현재 상태 기본 설정을 관리하고 들어오는 호출을 적절히 라우팅합니다.
OCS 자체에서는 들어오는 호출을 종료하지 않습니다. SIP 용어로 표현하면 OCS는 SIP 등록자 및 SIP 프록시의 기능을 합니다. 신호 및 미디어는 시스템의 클라이언트 끝점에 의해 완전히 지점 간 방식으로 제공됩니다. Office Communicator 2007과 같은 시스템의 끝점은 네트워크 상태에 맞게 알맞게 조정되는 광대역 오디오 코덱(RTAudio)을 제공합니다.
OCS 2007은 오디오/비디오, IM, 데이터 등 모든 통신 모드에 대해 회의 서버 역할을 사용하여 구내(on-premise) 웹 회의 기능을 제공합니다. OCS 기반 회의 서버를 통해 클라이언트 끝점은 피어 투 피어에서 여러 참석자로 참여하는 음소거, 참석자 퇴장, 잠금 등의 기능이 제공되는 다중 모달 통신으로 원활하게 전환할 수 있습니다. 예약된 회의의 경우 참석자를 수백 명으로 확장할 수 있고 임시 토론의 경우 참석자를 최대 백 명으로 확장할 수 있습니다. Outlook 추가 기능을 사용하거나 회의에 대한 전화 에스컬레이션을 만들어 회의를 예약할 수 있습니다. 전화 회의 솔루션은 파일 공유, 화이트보드, 녹음 등의 도구도 제공합니다.
물론 외부의 PSTN 망과 전화 번호, 페더레이션 조직 또는 조직 내의 기존 PBX 설비에 연결할 수 있어야 합니다. OCS 2007은 공용 게이트웨이 공급자가 제공하는 SIP-PSTN 간 게이트웨이와 통합되어 PSTN 또는 기존 PBX에 연결할 수 있도록 지원합니다. 코덱 및 신호 변환을 위해 중재 서버를 구성할 수 있습니다. 중재 서버는 Microsoft 코덱을 지원하지 않는 게이트웨이에 대해 선택적으로 구성할 수 있습니다.
Exchange Server 2007 통합 메시징은 OCS 2007을 위한 음성 메일 솔루션입니다. Exchange 통합 메시징은 인바운드 음성 및 팩스 호출에 대해 호출 응답을 제공하고 받은 메시지를 사용자의 Exchange 사서함에 가져다 놓습니다. 또한 Exchange 통합 메시징은 특정 개인이나 부서를 찾는 외부 호출자를 위해 자동 안내 기능을 제공합니다.
OCS는 음성의 대안으로 실시간 IM을 제공하며 사용자가 오디오, 비디오 및 IM이 동시에 포함된 다중 모달 대화에 참가할 수 있도록 지원합니다. 또한 Office Communicator 2007에서는 IM에서 서식 있는 텍스트를 사용하고 서식을 지정할 수 있습니다. 이 외에도 언제든지 IM 세션에 오디오와 비디오를 추가할 수 있어서 IM 대화를 음성 채팅으로 원활하게 전환할 수 있습니다.
기록, 로깅 및 문제 해결 등의 추가 구성 요소도 제공됩니다. 기록은 OCS 2007 통화 정보 기록이라는 서버 기능을 사용하여 제공됩니다. 시스템에서 발생한 모든 호출에 대해 호출이 들어온 시간이나 호출에 응답한 대상 또는 호출 전송 여부와 같은 다른 다양한 요소에 대한 기록이 만들어집니다. OCS는 준수 요구 사항을 충족하도록 IM 대화를 기록하는 보관 서버도 제공합니다. QoE(Quality of Experience) 모니터링 서버는 발생한 호출 품질에 대한 정보를 저장하므로 이를 통해 네트워크의 음성 품질 문제를 해결할 수 있습니다.

등록 및 초기화
OCS 시스템의 모든 클라이언트 끝점은 클라이언트 초기화의 첫 단계로 OCS에 등록하거나 로그온해야 합니다. 등록은 OCS 서버에 연결하는 프로세스로, 이 단계에서는 클라이언트의 존재를 서버에 알립니다. 등록 프로세스에는 서버에 대한 사용자 ID 인증이 포함되며 이를 통해 클라이언트 인스턴스와 서버 간의 보안 연결이 만들어집니다. 이 보안 연결은 클라이언트가 서버를 통해 수행하는 이후 호출에 사용되며 클라이언트 재등록을 통해 정기적으로 새로 고쳐집니다. 재등록 기간은 서버 토폴로지에 따라 다릅니다. 예를 들어 회사 외부에서 Microsoft AccessTM Edge 서버를 통해 등록된 클라이언트 끝점은 회사 방화벽 내부의 클라이언트보다 자주 등록을 새로 고칩니다.
등록은 음성 호출이나 현재 상태 변경 알림 같은 들어오는 알림을 받기 위해 OCS와의 지속적인 인증된 채널을 필요로 하는 클라이언트에만 필요합니다. Live Meeting과 같은 클라이언트 끝점은 모임 참가를 위해서만 OCS와의 연결이 필요하므로 OCS에 등록할 필요가 없습니다.
OCS 2007 내의 클라이언트 상호 작용에 대해 자세히 알아보려면 클라이언트 끝점의 관점에서 Office Communicator를 검토해 보십시오. Office Communicator와 관련된 대부분의 신호 흐름은 Office Communicator Phone Edition이나 Office Communicator Mobile과 같은 다른 클라이언트 끝점에 사용되는 것과 동일합니다. 등록이 끝나면 Office Communicator는 클라이언트 끝점의 실행에 중요한 구성 정보를 검색합니다. 이 정보에는 다음이 포함됩니다.
  • 대화 상대 카드, 전자 메일 주소, SIP URI, 대화명, 전화 번호 등의 신원 정보
  • 클라이언트 및 정책에 대해 활성화된 기능
  • AV Edge 서버 SIP 주소, 음성 메일 서버 주소 등의 서버 주소
  • 서버에 저장된 대화 상대의 친구 목록
  • 클라이언트 위치에 대한 숫자 서식 규칙
서버에 대한 기존 SIP 채널을 사용하여 모든 프로비저닝 정보를 검색하는 이 메커니즘을 대역 내 프로비저닝이라고 합니다. 이를 통해 클라이언트 끝점은 네트워크 또는 방화벽 외부에서 로그온할 때를 포함하여 클라이언트가 로그온할 때마다 구성을 자동 구성하고 새로 고칠 수 있습니다.
서버에 등록한 이후에는 초기화, 현재 상태 가져오기 및 설정, 준비 상태로 들어가는 등의 등록 시퀀스가 계속됩니다(그림 2 참조). OCS는 여러 클라이언트 끝점에서 동일 사용자 또는 SIP URI에 등록하는 것을 허용합니다. 등록 중 서버는 들어오는 모든 신호가 특정 클라이언트를 향하도록 클라이언트에 고유 SIP 주소를 반환합니다. 이 주소를 GRUU(Globally Routable User URI)라고도 합니다. OCS에 등록하는 각 클라이언트 끝점은 클라이언트 끝점을 고유하게 식별하는 별도의 GRUU 주소를 OCS로부터 할당받습니다.
그림 2 등록 절차
그림 2 등록 절차
등록을 제어하기 위해 서버에서는 한 사용자에 대해 활성 등록을 최대 8개까지만 허용합니다. 한 사용자에 대해 여러 클라이언트가 등록된 경우 이러한 구성을 MPOP(Multiple points of presence)라고 하고, 단일 클라이언트만 등록된 경우 이를 SPOP(Single point of presence)라고 합니다.
MPOP는 OCS 시스템의 핵심 개념입니다. 이를 통해 사용자는 모든 끝점에서 들어오는 호출이나 IM 알림을 받을 수 있으며 기본적으로 여러 전화나 IM 끝점을 사용할 수 있습니다. MPOP는 IM에 응답하거나 사용자의 현재 상태를 정확하게 설명하기 위한 원리를 제공합니다.
예를 들어 원격 사용자가 IM을 수신할 수 없는 Communicator Phone Edition의 IP 전화(SPOP 끝점)에 로그온되어 있다고 가정해 보십시오. 끝점의 이 기능은 현재 상태 정보와 함께 IP 전화에 의해 게시됩니다. 전화상에서 사용자의 현재 상태는 온라인입니다. 다른 사용자가 사용자의 현태 상태가 온라인인 것을 보고 Communicator를 사용하여 IM을 보내려고 시도합니다. 그러나 현재 상태에서 이미 이 장치 기능을 게시했기 때문에, 원격 사용자가 IM 가능 장치에 없으므로 메시지를 받지 못할 수도 있음을 알려 주는 알림이 표시됩니다.
다른 예로는 IM 자동 수락이 있습니다. 원격 사용자가 단일 Communicator 인스턴스(SPOP 끝점)에 있으면 IM 대화가 시작될 때마다 메시지가 즉시 자동 수락됩니다. 그러나 원격 사용자가 두 개의 Communicator 인스턴스(랩톱과 데스크톱)에 로그온되어 있으면 사용자가 한 장치에서 인스턴트 메시지를 수락할 수 있도록 10초의 지연 시간이 제공됩니다. 응답이 없으면 활성 상태인 Communicator 인스턴스에서 인스턴트 메시지가 자동 수락됩니다.

현재 상태
현재 상태는 통합 통신에서 중요한 역할을 합니다. 현재 상태를 통해 사용자는 원격 사용자가 지정된 모드에서 통신할 수 있는지 미리 알 수 있습니다. 따라서 "다른 용무 중 - 통화 중"과 같은 OCS 상태는 장치나 회선의 상태가 아니라 사용자의 상태와 연결됩니다. 또한 OCS 2007에서는 사용자가 위치, 작업 시간, 모임 시간과 같은 정보를 공유할 수 있도록 향상된 현재 상태 인프라를 제공합니다.
뿐만 아니라 사용자는 권한을 지정함으로써 각 사용자 그룹이 그룹의 액세스 수준에 따라 서로 다른 현재 상태 정보 집합에 액세스하도록 할 수 있습니다. 또한 "방해 금지"와 같은 사용자의 현재 상태와 일정 작업 시간 및 권한 수준도 발신자에게 제공되므로 발신자는 호출을 곧바로 상대방에게 보낼지 아니면 음성 메일로 보낼지에 대한 라우팅 결정을 내릴 수 있습니다.
Office Communicator의 클릭하여 전화 걸기에 표시되는 전화 번호는 세 위치에서 가져옵니다. 두 위치는 디렉터리(전체 주소 목록/주소록 서버 및 Outlook 연락처)에 기반을 두고 나머지 하나는 현태 상태를 통해 가져옵니다. 현재 상태를 사용함에 따라 사용자는 다른 사용자에게 표시할 전화 번호를 융통성 있게 게시할 수 있습니다.
현재 상태는 음성 라우팅 시나리오에서도 핵심적인 역할을 합니다. 예를 들어 원격 사용자의 현재 상태가 다른 용무 중이고 모임 참가 중이라는 텍스트가 표시되는 경우 사용자가 음성 호출에 응답할 가능성은 낮습니다. 이 경우 호출자는 IM이나 전자 메일을 사용할 수 있습니다. 마찬가지로, 원격 사용자의 현재 상태가 방해 금지이면 이는 원격 사용자가 다른 통신 방법을 선호하는 것임을 나타냅니다.
현재 상태는 사용자가 현재 참가 중인 모임의 제목 및 일정 위치에 대한 정보도 제공합니다. 이러한 정보는 팀 컨테이너의 사용자에게 게시됩니다. 현재 상태는 특정 기능에 대해 기본 설정된 끝점에 대한 정보를 제공하며 이 정보는 기본 동작을 수행할 끝점을 선택하는 데 사용됩니다. 예를 들어 일정 데이터 게시(모든 끝점에서 동일함)는 일정 기능에 대해 기본 설정된 끝점에서만 수행됩니다. OCS에는 기본 설정 끝점을 선택하는 논리가 포함되어 있습니다.
그림 3에서는 현재 상태가 OCS 시스템에 제공하는 다양한 기능을 보여 줍니다. 앞에서 설명했듯이 현재 상태는 사용자의 대화 가능 상태와 대화하고자 하는 의향이 조합된 것입니다. 온라인 상태는 사용자가 대화하고자 하는 의향이 있음을 나타내고 방해 금지는 사용자가 대화하고자 하는 의향이 없음을 나타냅니다. 직접 설정해야 하는 방해 금지를 제외한 다른 모든 상태는 사용자가 모임에 참가 중인지(다른 용무 중), 자리를 비웠는지(대화 불가능, 자리 비움) 등의 다양한 상태를 기반으로 자동으로 표현됩니다(그림 4 참조).
Figure 3 현재 상태 정보 설정 방법 (Close Figure 3)

기능 | 소스
대화 가능 상태 및 의향(온라인, 오프라인, 자리 비움, 다른 용무 중, 방해 금지) | 자동. 모임 상태, 전화 상태 등에 기반을 둠. 수동 설정도 가능합니다.
일정 상태(모임 참가 중, 모임 위치) | 자동. 사용자 기본 설정에 기반을 둡니다.
장치 기능(IM 허용) | 자동. MPOP 장치에 기반을 둡니다.
전화 번호 | 자동. 사용자 기본 설정에 기반을 둡니다.
가장 활성 상태인 끝점 | 자동. 사용자 작업에 기반을 둡니다.
알림 | 수동. 부재 중 알림이 우선합니다.
부재 중 알림 | 자동. 일정에 기반을 둡니다.
작업 시간 | 자동. 약속 있음/없음 데이터에 기반을 둡니다.
위치 | 수동. 사용자 선택에 기반을 둡니다.
그림 4 대화 가능 상태 및 대화하고자 하는 의향에 따른 현재 상태
그림 4 대화 가능 상태 및 대화하고자 하는 의향에 따른 현재 상태
대화 가능 상태는 사용자가 현재 로그온되어 있는 다양한 장치에서 가져올 수 있습니다. 한 사용자에 대해 여러 장치가 사용되고 각 장치는 장치의 현재 상태 정보와 사용자 데이터를 게시하므로 이러한 정보를 단일화된 보기로 표시하기 위한 집계 논리가 필요합니다. OCS에는 다양한 매개 변수, 장치 및 현재 상태 시스템에서 받은 입력을 기반으로 현재 상태를 계산하는 이러한 집계 논리가 포함되어 있습니다.
집계 논리에 대해 자세히 살펴보기 전에 먼저 집계된 정보가 사용자에게 게시되는 방법을 살펴보는 것도 좋습니다. OCS 2007에는 사회 집단과 연결된 액세스 수준과 비슷한 개념인 컨테이너라는 개념이 도입되었습니다. 컨테이너마다 각기 다른 양의 정보를 제공하며 특정 컨테이너에 추가된 사용자는 해당 컨테이너에서 사용할 수 있는 정보에만 액세스할 수 있습니다. 사용자의 버디 목록에 있는 모든 사용자는 사용 가능한 컨테이너 중 하나에 나타나야 합니다. 사용자는 관계 수준에 따라 다른 사용자를 컨테이너에 추가하거나 다른 컨테이너로 이동할 수 있습니다. Office Communicator에서는 지능적인 방법을 통해 그림 5에 나오는 기본 컨테이너를 자동으로 선택합니다.
Figure 5 현재 상태 컨테이너 (Close Figure 5)

컨테이너 | 용도
차단됨 | 현재 상태 정보를 차단합니다. 차단된 사용자로부터의 호출이 허용되지 않습니다. 그러나 차단된 사용자가 이름과 전자 메일 주소 정보는 볼 수 있습니다.
일반 | 이름, 직함, 회사, 전자 메일 주소, 제한된 현재 상태 정보를 제공합니다.
회사 | 업무상 대화 상대에 대한 정보, 기본 일정 및 현재 상태 정보를 제공합니다.
팀 | 회사 전화 번호와 휴대폰 번호, 일정 및 현재 상태 정보를 제공하며 사용자가 방해 금지 상태일 때도 대화를 요청할 수 있습니다.
개인 | 집 전화 번호 및 휴대폰 번호를 비롯하여 게시된 모든 대화 상대 정보를 볼 수 있습니다.
OCS의 현재 상태 집계 논리는 장치가 서버에 보고한 다양한 현재 상태를 기반으로 사용자의 올바른 현재 상태를 결정합니다. 그림 6에서는 다양한 소스에서 현재 상태가 집계되는 방법을 보여 줍니다. 현재 상태 및 사용자 작업과 같은 일부 정보는 먼저 OCS 현재 상태 집계 메커니즘을 통해 보내진 후 컨테이너에서 사용할 수 있게 되고, 대화 상대 정보 같은 다른 정보는 클라이언트 끝점에 의해 해당 컨테이너에 추가됩니다. 차단됨 컨테이너에는 구성원 정보 이외의 정보는 게시되지 않으므로 그림에서 생략되었습니다.
그림 6 현재 상태 집계 및 게시
그림 6 현재 상태 집계 및 게시
OCS 시스템에서 현재 상태 관계는 한 사용자가 다른 사용자를 대화 상대 목록(버디 목록)에 추가할 때 설정됩니다. 그러나 회사 디렉터리에 있는 사용자는 대화 상대 목록에 개별적으로 추가하지 않고도 현재 상태를 볼 수 있습니다.
다른 사용자의 현재 상태를 가져오는 가장 간단한 방법은 Office Communicator에서 해당 사용자를 검색하는 것입니다. 그러면 서버에서 단일 쿼리가 생성됩니다. 이 경우 원격 사용자의 현재 상태 변경에 대한 알림을 구독하지 않습니다. 그러나 사용자가 자신의 버디 목록에 다른 사용자를 추가하면 현재 상태 변경에 대한 알림을 구독하게 됩니다. 따라서 현재 상태가 변경될 때마다 OSC에서 자동으로 상태 변경 알림을 보냅니다.

IM 및 오디오
IM은 등록과 현재 상태를 모두 사용합니다. OCS 시스템에서 메시지는 피어 투 피어로 이동하며 OCS 서버는 Office Communicator 클라이언트 간에 메시지를 나르는 프록시 역할을 합니다.
사용자가 다른 사용자를 대상으로 시작하는 첫 번째 메시지가 중요합니다. 이 메시지는 SIP 용어로 표현하면 세션을 설정합니다. 등록된 클라이언트 중에서 적절한 MPOP 클라이언트를 찾는 작업이 세션을 설정하는 동안 수행됩니다. 이때 OCS는 프록시로서의 중요한 역할을 합니다. 사용자가 들어오는 IM 세션을 수락하거나 사용자의 MPOP 끝점 중 하나에서 세션을 자동 수락하면 이후부터는 OCS가 적절한 클라이언트를 찾지 않아도 메시지가 끝점 간에 원활하게 이동합니다.
사용자가 바탕 화면에 IM 대화 창을 열어 두는 경우가 있습니다. 10분 동안 아무런 작업이 없으면 IM 창은 계속 열려 있지만 Office Communicator 2007이 SIP 세션을 종료합니다. 어느 쪽에서든 IM 세션을 종료할 수 있습니다. IM 세션이 종료될 때마다 전체 대화가 기록된 기록 항목이 Outlook 대화 내용 폴더에 자동으로 저장됩니다. 대화 내용 폴더는 Office Communicator에 의해 Outlook에 만들어지는 특수 폴더입니다. 이 클라이언트 쪽 기록 기능은 선택적이며 기본적으로 꺼져 있습니다. 대화 내용은 같은 사용자와 대화를 다시 시작할 때 사용되며 이 기능을 사용하는 사용자는 IM 창을 닫은 후에도 IM 대화를 계속할 수 있습니다.
분기 및 MPOP를 보여 주는 그림의 IM 구조는 음성 시나리오에도 대부분 적용됩니다. 음성 시나리오에서는 IM 세션 설명이 포함된 초대장 대신 음성 기능을 나타내는 음성 세션 설명이 포함됩니다. OCS는 음성 호출에 대한 분기를 모든 끝점에 적용하며 이는 IM에 적용되는 것과 비슷합니다.
음성 신호는 대부분 IM의 개념에서 파생되지만 미디어 처리는 음성 시나리오에 고유한 부분입니다. 이에 대해서는 향후 문서에서 자세히 다루도록 하겠습니다.

Rajesh Ramanathan은 통신 분야에서 14년 동안 일했으며 현재는 Office Communicator 팀의 수석 프로그램 관리자고 근무하고 있습니다. 문의 사항이 있으면 rajeshra@microsoft.com으로 연락하시면 됩니다.


 Office Communications Server: OCS 2007 음성 배포 계획
Office Communications Server Jochen Kunert and Rui Maximo

OCS 2007 음성 배포 계획
한 눈에 보기:
  • 전화 통신 통합 시나리오
  • Office Communications Server 구성
  • 사용자, 번호 사용 계획 및 라우트

Microsoft Office Communications Server(OCS) 2007은 실시간 통신 미디어를 웹 회의(데이터, 오디오 및 비디오 공유),
인스턴트 메시징, 음성/화상 대화를 비롯한 사용자 현재 상태 인식 기능과 통합하는 엔터프라이즈 제품입니다. OCS 2007을 기존 PBX 시스템과 통합하는 작업은 매우 복잡할 수 있습니다. Office Communications Server 2007은 PBX로 설계되지 않았습니다. 오늘날의 정보 작업자는 일상적인 작업에서 전자 메일, 인스턴트 메시징, 전화, 음성 메일 등 다양한 미디어 통신을 사용하지만 PBX 시스템은 전화 호출 기능만 제공하기 때문입니다.
관리자가 보다 융통성 있게 개인이나 회사를 위한 최적의 전화 통신 통합 전략을 세울 수 있도록 Office Communications Server 2007에서는 기존 전화 통신 환경과의 통합에 사용할 수 있는 세 가지 구성 시나리오를 제공합니다. 이 세 가지 시나리오는 바로 원격 통화 제어, Enterprise Voice, Enterprise Voice와 PBX의 통합입니다.
이 문서에서는 OCS 2007 전화 통신을 기존 전화 통신 시스템과 통합하는 경우를 가정하고 OCS 2007 전화 통신 배포를 계획할 때 고려해야 할 사항에 중점을 두고 설명합니다. 이 정보는 특히 시스템 설계자와 IT 및 전화 통신 관리자에게 유용합니다. 다른 여러 시나리오에 대해서도 간단히 살펴보겠지만 이 문서에서는 주로 Office Communications Server 2007 Enterprise Voice를 다룰 것입니다.

원격 통화 제어
추가 OCS 리소스
  • Pro LCS: Live Communications Server Administration
  • 전화 통신과 Office Communications Server 2007 통합
  • Enterprise Voice 계획 및 배포 가이드

RCC(원격 통화 제어) 시나리오에서 사용자는 기존 PBX, IP-PBX 또는 TDM(Time-Division Multiplexing) 사무용 전화를 사용합니다. 사용자는 전화기의 번호를 누르거나 누르거나 송수화기를 들지 않고도 자신의 Office Communicator 2007 클라이언트에서 사무용 전화로 전화를 걸거나 받을 수 있습니다. 사무용 전화는 Office Communicator 2007을 사용하여 제어할 수 있지만 음성은 여전히 PBX 시스템에 의해 처리되며 VoIP(Voice-over-IP) 전화로 변환되지 않습니다. Office Communicator 2007로 사무용 전화를 제어할 수 있지만 Office Communicator 2007 실행 여부에 관계없이 이전처럼 PBX 전화로 전화를 걸거나 받을 수도 있습니다.
Office Communicator 2007 및 OCS 2007에서 RCC를 사용하려면 SIP(Session Initiation Protocol)/CSTA(Computer Supported Telephony Application) 게이트웨이를 배포해야 하고 RCC를 사용할 수 있도록 Office Communications Server 2007 환경을 설정해야 합니다. SIP/CSTA 게이트웨이는 PBX 시스템과 OCS 2007을 연결하는 기능을 하므로 사용 중인 PBX 시스템의 유형과 상호 운용되어야 하고 OCS 2007과 호환되어야 합니다. PBX 전화를 제어하기 위해 Office Communicator 2007은 CSTA 프로토콜을 사용합니다. 이 프로토콜은 ECMA(European Computer Manufacturers Association) 269 표준(www.ecma-international.org/publications/standards/Ecma-269.htm)에서 설명하는 것처럼 전화 스위치(PBX)와 연결하기 위한 XML 스키마를 정의합니다.
Office Communicator 2007은 PBX 전화를 제어하기 위해 SIP 페이로드 형태로 CSTA 명령을 보냅니다. 그러면 이 명령은 Office Communications Server 2007에 의해 SIP/CSTA 게이트웨이로 라우트됩니다. 따라서 Office Communications Server 2007에서는 CSTA를 인식할 필요가 없으며 CSTA를 라우트하는 방법만 알고 있으면 됩니다. 그런 다음에는 SIP/CSTA 게이트웨이가 PBX에서 사용하는 기본 프로토콜로 명령을 변환합니다. 그림 1에서는 이 프로세스를 보여 줍니다.
그림 1 RCC 통합 시나리오
그림 1 RCC 통합 시나리오
RCC를 사용하도록 설정하는 작업에는 다섯 단계가 포함됩니다. 첫 번째 단계는 PBX와 통신하도록 SIP/CSTA 게이트웨이를 구성하는 것입니다. 그런 다음에는 CSTA 요청을 SIP/CSTA 게이트웨이로 라우트하도록 OCS 2007을 구성합니다. 세 번째 단계는 RCC를 사용하도록 사용자를 구성하는 것입니다. 네 번째 단계는 Office Communicator 2007을 구성하는 것입니다. 다섯 번째 단계는 OCS 2007 정규화 규칙을 정의하는 것입니다. 정규화 규칙은 주소록 전화 번호 정규화에도 사용되는 것으로, Enterprise Voice와 함께 사용되는 전화 번호 정규화 규칙과는 다른 규칙입니다.

Enterprise Voice
Enterprise Voice를 사용하도록 사용자를 구성하면 PBX 전화 대신 Office Communicator 2007이나 Office Communicator Phone Edition이 사용자의 기본 전화로 설정됩니다. Office Communicator 2007에는 고유한 전화 번호가 할당됩니다. 테스트를 위해 기존 PBX 전화를 Office Communicator 2007에 할당된 새 내선 번호로 착신 전환할 수 있습니다. 이제 권장 USB 음성 장치와 결합된 Office Communicator 2007이 통화 제어(또는 신호)와 미디어(오디오 및 비디오)를 모두 처리하게 됩니다.
이 시나리오에서 Office Communications Server 2007은 전화를 IP 네트워크의 Office Communicator 2007 끝점 간에서 라우트하거나(IP-IP 전화), PSTN(공중 전화망)/PBX로 라우트합니다(IP-PSTN 전화). OCS 2007은 PSTN으로 라우트되는 모든 전화에 대해 전화 걸기 제한을 적용합니다.
Office Communications Server 2007 환경을 PBX 또는 PSTN에 연결하려면 SIP/PSTN 또는 IP/PSTN 게이트웨이라고 하는 미디어 게이트웨이를 배포해야 합니다. Office Communications Server 2007 환경에 연결하려면 그림 2에 표시된 것처럼 미디어 게이트웨이를 중재 서버와 연결해야 합니다. 중재 서버 및 중재 서버와 연결된 미디어 게이트웨이를 동일한 물리적 위치에 설치해야 합니다.
그림 2 Enterprise Voice와 PSTN 또는 기존 PBX 통합 시나리오
그림 2 Enterprise Voice와 PSTN 또는 기존 PBX 통합 시나리오
OCS 2007은 인증되고 암호화된 통신만 허용하기 때문에, 중재 서버를 사용하면 표준 SIP 구현(보안되지 않은 경우 포함)을 지원하는 미디어 게이트웨이를 Office Communications Server 2007에 연결할 수 있습니다. 중재 서버는 표준 코덱(G.711, G.723 등)과 Microsoft 실시간 오디오 코덱 간의 코덱 변환을 처리하는 작업도 수행합니다. Office Communications Server 2007에서 지원하는 미디어 게이트웨이 목록은 technet.microsoft.com/bb735838에서 전략적 하드웨어 파트너를 참조하십시오.
미디어 게이트웨이를 PSTN에 직접 연결하거나 기존 PBX의 PRI(Primary Rate Interface) 트렁크에 연결할 수 있습니다. 그림 2에서는 PSTN 및 기존 PBX을 사용하는 Enterprise Voice 시나리오에서 가능한 통합 시나리오를 보여 줍니다. Enterprise Voice 배포에 디렉터(일반적으로 Office Communications Server Standard Edition Server)가 반드시 필요한 것은 아니지만 사용하는 것이 좋습니다.
Enterprise Voice를 사용하도록 설정하는 작업에는 네 단계가 포함됩니다. 첫 번째 단계는 미디어 게이트웨이를 배포하고 구성하는 것입니다. 미디어 게이트웨이는 Microsoft 파트너 제품이며 미디어 게이트웨이마다 배포 단계가 다르므로 해당 공급업체의 설명서를 참조해야 합니다.
그런 다음에는 모든 미디어 게이트웨이에 대해 중재 서버를 배포해야 합니다. 이 단계에서는 중재 서버가 미디어 게이트웨이에서 트래픽을 주고 받는 데 사용할 네트워크 카드 하나와 Office Communications Server 2007(Enterprise Edition 배포의 경우 디렉터)에서 트래픽을 주고 받는 데 사용할 다른 네트워크 카드 하나를 구성해야 합니다. 고급 미디어 게이트웨이를 제외한 일반 미디어 게이트웨이가 OCS 2007 Enterprise Voice 인프라와 상호 운영되려면 OCS 2007 중재 서버 역할의 지원이 필요합니다.
세 번째 단계는 번호 사용 계획을 정의하는 것입니다. 여기에는 음성 정책, 전화 라우트, 위치 프로필을 정의하는 작업이 포함됩니다.
그런 다음에는 Enterprise Voice를 사용하도록 사용자를 구성합니다. Enterprise Voice를 사용하도록 사용자를 구성할 때 PBX 또는 PSTN으로도 전화를 걸고 받을 수 있도록 설정해야 합니다. 이를 위해서는 각 사용자에게 고유한 전화 번호를 할당해야 합니다.

Enterprise Voice와 PBX 통합
이 구성은 Enterprise Voice 구성을 확장한 것으로, 사용자의 PBX 전화가 사용자의 Office Communicator 클라이언트와 동기화된다는 점이 다릅니다. 이 구성은 그림 2의 PBX를 통해 PSTN에 연결하는 Enterprise Voice 시나리오와 비슷합니다. 그러나 Enterprise Voice와 PBX 통합 시나리오에서는 사용자의 PBX 전화를 Office Communicator 2007 클라이언트로 대체하는 대신 Office Communicator 2007과 기존 PBX 전화가 같은 전화 번호를 사용합니다.
발신자가 PBX 전화나 PSTN 전화에서 사용자의 내선 번호로 전화를 걸면 PBX 시스템은 전화를 사용자의 PBX 전화와 Office Communications Server 2007을 통해 Office Communicator 2007 클라이언트로 분기합니다. 전화가 걸려오면 사용자의 Office Communicator 2007 클라이언트와 PBX 전화에서 동시에 신호가 울립니다. 반대로 Office Communications Server는 OCS 2007에서 시작된 전화를 미디어 게이트웨이를 통해 PBX로 분기합니다. Office Communicator Phone Edition을 사용하는 경우에는 이 시나리오가 가능하지 않습니다. 이 구성을 사용하려면 PBX 음성 메일 시스템에서 음성 메일을 처리해야 합니다. 이 경우 Exchange Server 2007 통합 메시징을 음성 메일 솔루션으로 사용할 수 없습니다.
Enterprise Voice를 PBX와 통합하려면 Enterprise Voice 배포 시 수행하는 단계와 함께 세 가지 단계를 추가로 수행해야 합니다. 추가로 수행하는 첫 번째 단계에서는 미디어 게이트웨이를 PBX에 직접 연결해야 합니다. 그런 다음 이 시나리오를 지원하도록 PBX를 구성해야 합니다. 공급업체에 따라 PBX 소프트웨어를 업그레이드해야 할 수도 있습니다. 마지막으로, PBX 통합에 맞게 사용자를 설정해야 합니다.
Microsoft는 미디어 게이트웨이라는 중간 매체 없이 중재 서버를 직접 IP PBX에 연결할 수 있도록 지원하기 위해 많은 노력을 기울이고 있습니다. 이와 관련된 최신 정보는 technet.microsoft.com/bb735838을 참조하십시오.

Office Communications Server 구성
Enterprise Voice 기능은 Office Communications Server 2007 Enterprise Edition 및 Office Communications Server 2007 Standard Edition에서 실행되는 서비스에 의해 처리됩니다. 그림 3에서는 인바운드 및 아웃바운드 전화를 라우트하기 위해 Enterprise Voice 기능을 제공하는 서비스에 대해 설명합니다.
Figure 3 Enterprise Voice 서비스 (Close Figure 3)

서비스 | 설명
변환 서비스 | 위치 프로필 또는 전화 컨텍스트를 기반으로 정규화 규칙을 적용합니다.
사용자 서비스 | 대상 전화 번호에 대해 역방향 번호 조회를 수행합니다.
인바운드 라우팅 구성 요소 | 대상 사용자의 호출 기본 설정을 적용합니다.
Exchange 통합 메시징 | 필요에 따라 요청을 음성 메일로 전송합니다.
아웃바운드 라우팅 구성 요소 | URI 및 사용자 정책을 기반으로 최적의 라우트를 결정합니다.
그림 4에서는 걸려오는 전화가 PC 간 전화를 위해 OCS 2007에 의해 라우트될 때 이러한 각 구성 요소가 걸려오는 전화에 대해 수행하는 작업을 보여 줍니다. 걸려오는 전화는 Office Communicator 2007이나 Office Communicator Phone Edition과 같은 끝점 또는 PSTN/PBX에 연결된 중재 서버에서 시작될 수 있습니다(PSTN-SIP 전화). Office Communicator 2007과 같은 Office Communications Server 2007 클라이언트 끝점 중 하나에서 시작되는 거는 전화는 Standard Edition Server나 사용자 홈인 Enterprise 풀로 전송됩니다. 이를 사용자 홈 풀이라고 합니다.
그림 4 OCS의 Enterprise Voice 관련 서비스 간 상호 작용 프런트 엔드 서버
그림 4 OCS의 Enterprise Voice 관련 서비스 간 상호 작용 프런트 엔드 서버
이 시점에서 Office Communications Server 2007은 전화를 처리하여 어디로 라우트할지 결정합니다. 다음 홉은 수신자의 홈 풀, 중재 서버 또는 Microsoft® Exchange Server 2007 통합 메시징이 될 수 있습니다(그림 5 참조). 전화가 다른 홈 풀로 라우트되면 OCS 2007은 수신자의 모든 활성 끝점으로 전화를 보냅니다. 수신자의 Office Communicator 2007 또는 Office Communicator Phone Edition에서 신호가 울리고 팝업 창 알림이 장치에 나타납니다.
그림 5 전화 라우팅
그림 5 전화 라우팅
전화가 중재 서버로 라우트되면 특정 미디어 게이트웨이로 라우트하도록 서버가 구성되어 있는 것입니다. 미디어 게이트웨이가 PBX에 직접 연결되어 있으면 전화가 PBX에 의해 사무용 전화나 PSTN으로 라우트됩니다. 그러나 미디어 게이트웨이가 PBX에 직접 연결되어 있지 않으면 전화가 PSTN으로 라우트됩니다.
다음 홉이 Exchange Server 2007 통합 메시징이면 발신자가 메시지를 남길 수 있습니다. 음성 메일은 수신자가 Office Communications Server 2007에 로그인되어 있는지 여부에 관계없이 사용할 수 있습니다.
수신자가 음성 메일에 응답하면 발신자의 Office Communicator 2007 또는 Office Communicator Phone Edition에서 수신자의 Office Communicator 2007 또는 Office Communicator Phone Edition으로 직접 음성이 전송됩니다(IP-IP 전화의 경우). 발신자가 PBX 또는 PSTN 전화를 사용하는 경우 중재 서버는 음성 트래픽을 직접 수신자의 Office Communicator 2007 또는 Office Communicator Phone Edition으로 전송합니다(IP-PSTN 전화의 경우). OCS 2007은 전화 신호 울림만 처리합니다. 따라서 오디오와 비디오는 OCS 2007에서 처리하는 것이 아니라 끝점 간에 직접 이동합니다.

사용자 구성
Enterprise Voice를 사용하도록 설정된 사용자에게는 조직 내에서 고유한 전화 번호가 할당되어야 합니다. 이것은 Active Directory®에서 수행되는 구성으로, 전화에 전화 번호가 할당되는 대부분의 전화 통신 시스템과는 다른 구성입니다. 이 설계의 장점은 사용자가 Office Communicator 2007을 실행하는 아무 컴퓨터에서나 OCS 2007에 로그인하여 컴퓨터를 자신의 업무용 전화로 전환할 수 있다는 점입니다. 이 이식성 기능은 자택 근무자나 현장에서 근무하는 직원에게 특히 유용합니다.
사용자의 전화 번호는 Active Directory에서 E.164 형식으로 지정됩니다. E.164 형식은 전화 번호를 명확하고 고유하게 나타내기 위한 번호 지정 스키마인 국제 공용 전화 통신 번호 사용 계획을 정의합니다. E.164 형식은 전화 번호를 다음과 같은 형식으로 지정합니다.
+<country code><area code><phone number>
Enterprise Voice를 사용하도록 설정된 사용자는 전화 번호에 대해 SIP URI와 E.164 전화 번호라는 두 가지 고유한 표현을 사용합니다. 이 경우, 전화 번호로 전화를 걸면 Office Communications Server에서 전화 번호의 E.164 표현(+14255551212)을 사용자의 SIP URI(joe@contoso.com)로 변환합니다. 그런 다음 Office Communications Server 2007은 수신자의 SIP URI를 기준으로 전화를 라우트합니다. 전화 번호를 SIP URI로 변환할 수 없는 경우 OCS 2007은 중재 서버를 통해 전화를 PBX/PSTN으로 라우트합니다.
모든 Office Communications Server 사용자에게 고유한 전화 번호를 할당해야 하는 Enterprise Voice 배포를 계획하는 경우 기존의 전화 통신 시스템을 고려해야 합니다. 미디어 게이트웨이를 통해 직접 PSTN에 연결하는 경우 두 자리 또는 세 자리의 내선 번호로 구성된 일정 범위의 번호 블록인 DID(Direct-Inward-Dialing) 번호를 사용하여 OCS 2007 사용자에게 전화 번호를 할당할 수 있습니다. PBX를 통해 PSTN에 연결하는 경우 PBX에서 제공하는 DID 번호 블록을 OCS 2007 사용자에게 할당합니다.

번호 사용 계획
E.164 형식 전화 번호가 고유한 표현을 제공하기는 하지만 전화 걸기에 편리한 번호는 아닙니다. 또한 Office Communicator Phone Edition이나 표준 PBX/PSTN 전화에서 이 형식으로 번호를 입력할 수도 없습니다. 10개의 숫자로 된 다이얼패드에서 + 문자를 어떻게 지정할 수 있을까요? 사용자는 짧은 내선 번호로 전화를 거는 데 익숙해 있습니다. 하지만 내선 번호가 특정 위치에서는 고유하지만 회사 전체에서는 그렇지 않을 수도 있습니다. 따라서 내선 번호를 E.164 형식으로 변환하는 변환 규칙을 지정해야 합니다.
관리자는 이러한 번호 변환을 수행하는 정규화 규칙이 지정된 위치 프로필을 정의해야 합니다. 클라이언트(Office Communicator 2007 또는 Communicator Phone Edition)나 Office Communications Server 2007의 변환 서비스에 의해 전화 번호가 E.164 형식으로 변환되면 사용자 서비스가 역방향 번호 조회를 수행하여 E.164 번호에 해당하는 SIP URI를 찾을 수 있습니다. 위치 프로필에 정의된 정규화 규칙은 일치하는 항목을 찾은 경우 정규식을 사용하여 변환을 수행합니다. 예를 들어 1234에 전화를 걸면 정규화 규칙은 4자리 패턴과 일치하는 번호를 찾아서 이를 +142555{4자리}로 변환합니다. 즉, 1234를 +1425551234로 변환합니다. 이 위치 프로필을 통해 사용자는 이전부터 사용하던 전화 걸기 방법을 그대로 사용할 수 있습니다.
관리자는 다음과 같은 세 가지 방법으로 사용자에게 위치 프로필을 할당할 수 있습니다.
  • 그룹 정책을 통해 Office Communicator 2007 사용자에 대한 위치 프로필을 정의합니다.
  • 사용자가 Office Communicator Phone Edition에서 위치 프로필을 선택하도록 허용합니다.
  • 홈 풀에 위치 프로필을 할당합니다. 해당 풀이 홈인 사용자에게는 자동으로 해당 위치 프로필이 할당됩니다.
번호 사용 계획을 정의하는 작업에는 음성 정책, 전화 라우트, 정규화 규칙이 포함된 위치 프로필 등을 만드는 작업이 포함됩니다. 음성 정책은 사용자에게 허용되는 전화 액세스의 유형을 정의합니다. Office Communications Server 2007은 전화 라우트를 통해 전화를 PBX/PSTN으로 라우트하는 방법을 결정합니다. 전화 번호로 전화를 거는 방법은 다양하기 때문에 위치 프로필의 정규화 규칙은 수신 전화 번호를 E.164 형식으로 변환하는 방법을 정의함으로써 전화가 라우트될 수 있도록 합니다.
Enterprise Voice를 사용하도록 설정된 모든 사용자는 관리자에 의해 음성 정책에 연결됩니다. 음성 정책은 사용자에게 할당된 전화 권한을 정의합니다. 전화 권한은 사용자가 사용할 수 있는 라우트와 사용자가 전화를 걸 수 있는 번호를 결정합니다. 각 사용자는 단일 음성 정책에 연결되어야 합니다. 이러한 정책은 관리자가 만듭니다.
각 음성 정책에는 동시 신호 울림 및 순서가 지정된 전화 사용 목록을 사용자에게 허용하거나 허용하지 않는 설정이 포함되어 있습니다. 모임 정책과 비슷한 음성 정책은 Active Directory에 XML 문서로 정의되어 저장되는 논리적인 설정 컨테이너입니다. 이 설계는 향후 OCS 2007 버전에서 Active Directory 스키마를 확장하지 않고도 추가 정책 설정을 지원하도록 확장할 수 있다는 점에서 매우 유용합니다. 예를 들어 음성 정책에 전화 사용이 연결되어 있지 않으면 해당 정책이 할당된 사용자는 PBX/PSTN으로 아웃바운드 전화를 할 수 없도록 금지됩니다. 이러한 사용자는 IP-IP 전화만 할 수 있습니다.

전화 사용 및 라우트
전화 사용은 사용자에게 허용된 전화 라우팅 권한을 정의합니다. 전화 사용은 전화 라우트의 모음입니다. 전화 사용은 고유한 키워드로 된 문자열입니다. 즉, 다른 전화 사용에 같은 이름을 사용할 수 없습니다. 관리자는 전화 사용을 필요한 만큼 얼마든지 만들 수 있습니다.
전화 사용 대신 음성 정책에 라우트나 라우트 집합을 직접 연결할 수도 있지만 전화 사용 키워드는 정책과 라우트 간의 연결을 유지하기 위한 추상화된 개념입니다. 정책을 라우트에 직접 연결하는 경우 전화 사용의 개념이 필요하지 않지만 이 경우 관리자가 라우트 이름을 수정하면 해당 라우트와 연결된 모든 정책을 업데이트해야 합니다. 정책과 라우트 간 연결을 만드는 데 사용되며 정책과 라우트 둘 모두의 속성에 해당하는 전화 사용을 사용하면 라우트 이름이 변경될 경우에도 정책과 라우트 간의 연결이 유지됩니다.
라우트에는 전화 번호 패턴과 미디어 게이트웨이에 연결된 중재 서버 목록이 포함됩니다. 라우트에는 하나 이상의 전화 사용이 할당되어야 합니다. 패턴과 게이트웨이 간의 이 연결은 특정 패턴과 일치하는 전화 번호의 라우팅 방법을 지정합니다.
패턴은 일치하는 전화 번호 범위를 지정합니다. 패턴은 전화 번호를 포함하거나 제외할 수 있는 정규식으로 정의됩니다. 이러한 정규식을 보다 쉽게 만들 수 있도록 Enterprise Voice Route Helper 도구가 제공됩니다. 전화가 걸려온 전화 번호가 라우트의 정규식 패턴과 일치하면 라우트에 정의된 게이트웨이 중 하나로 전화가 라우트됩니다.
단일 라우트에 둘 이상의 중재 서버와 미디어 게이트웨이를 포함할 수 있습니다. Office Communications Server 2007은 게이트웨이 간의 고른 트래픽 분산을 위해 라운드 로빈 방식으로 전화를 중재 서버에 라우트합니다. 게이트웨이에서 오류가 발생하거나 유지 관리 작업으로 인해 서비스가 중단되는 경우 해당 중재 서버는 Office Communications Server 2007로 응답을 보내고 그러면 Office Communications Server 2007은 즉시 라우트 목록에 있는 다른 중재 서버와 다른 미디어 게이트웨이로 전화를 라우트합니다.
오류가 발생한 미디어 게이트웨이로 전화 라우트 시도를 10회 수행한 이후 Office Communications Server 2007은 해당 미디어 게이트웨이가 다시 응답을 할 때까지 해당 게이트웨이로 향하는 트래픽을 줄입니다. 추가 10회 시도 이후에도 미디어 게이트웨이에서 응답하지 않으면 Office Communications Server 2007은 미디어 게이트웨이가 다시 응답할 때까지 해당 미디어 게이트웨이로의 전화 라우팅을 중지합니다.
전화 라우트에 정의된 미디어 게이트웨이 목록은 게이트웨이의 정규화된 도메인 이름과 포트 번호로 표현됩니다. 전화 번호가 정규식 패턴과 일치하지 않으면 일치하는 패턴을 찾을 때까지 사용자에게 할당된 전화 사용과 연결된 다음 라우트가 확인됩니다. 일치하는 패턴이 없으면 전화를 라우트할 수 없으므로 전화가 해당 목적지에 도달하지 못합니다. 사용자는 전화를 완료할 수 없음을 알려주는 알림을 받습니다.

다음 단계
Office Communications Server 2007은 세 가지 수준의 전화 통신 통합을 제공합니다. 전화 통신 배포를 고려하는 경우 현재 및 미래의 전화 통신 비즈니스 요구 사항에 가장 적합한 수준을 결정해야 합니다. 수준을 결정하면 배포를 계획할 수 있습니다. 배포 계획 시 중요한 부분은 Office Communications Server Enterprise Voice 배포에 대한 번호 사용 계획을 정의하는 것입니다. 이 부분은 신중하게 검토해야 합니다.
Office Communications Server 2007 Enterprise Voice 및 관련 기술에 대한 자세한 내용은 "추가 OCS 리소스" 추가 기사를 참조하십시오.

Jochen Kunert는 전화 통신 업계에서 10년 간의 경력을 쌓은 바 있으며 현재는 Microsoft의 Office Communications Group에서 수석 프로그램 관리자로 근무하고 있습니다. Kunert는 곧 출판될 Microsoft Office Communications Server 2007 Resource Kit의 공동 저자이기도 합니다. 문의 사항이 있으면 jkunert@microsoft.com으로 연락하시면 됩니다.
Rui Maximo는 IT 업계에서 14년 간의 경력을 쌓은 전문가이며 Pro LCS: Live Communications Server Administration 및 Microsoft Office Communications Server 2007 Resource Kit의 공동 저자입니다. 문의 사항이 있으면 ruim@ruimaximo.com으로 연락하시면 됩니다.


 High Performance Computing: Windows Compute Cluster Server 소개
High Performance Computing John Kelbley and Doug Lindsey

Windows Compute Cluster Server 소개
한 눈에 보기:
  • 클러스터를 사용하여 복잡한 문제 해결
  • 계산 클러스터의 일반 요구 사항
  • Windows 기반 계산 클러스터 설치
  • 원격으로 명령 실행

HPC(고성능 컴퓨팅)는 계산 성능이 많이 요구되는 문제의 해결에 중점을 둔 응용 컴퓨팅의 한 분야를 말합니다. 수년 전만 해도 HPC는 "슈퍼컴퓨팅"이라 지칭되며
연구소에서 주로 사용되는 대규모의 전문화된 시스템이 주류를 이루었고 가격도 상당히 비쌌습니다. 하지만 소규모 시스템의 컴퓨팅 성능이 좋아지면서 가격 대비 성능 비율이 변하였고 계산 작업을 PC급 시스템에서 처리할 수 있게 되었습니다.
계산 성능이 많이 요구되는 문제 중에는 계산을 병렬로 수행함으로써 해결되는 것들이 많습니다. 즉, 다른 계산이나 프로세스의 출력 없이도 완료할 수 있는 계산이나 프로세스가 있습니다. 이러한 경우 계산 클러스터로 그룹화된 규모가 작은 시스템(노드)을 여러 개 활용하여 문제의 많은 부분을 해결할 수 있습니다. 계산 클러스터의 대표적인 활용 예는 다음과 같습니다.
  • 재무 모델—알고리즘 또는 수식을 입력만 달리하여 수천 회 실행
  • 엔지니어링—모델에 질감을 적용하여 개별 부품에 미치는 영향 시뮬레이트
  • 컴퓨터 애니메이션—동영상의 각 프레임에 질감 및 조명 효과 적용
계산 클러스터는 복잡한 문제를 짧은 시간 내에 효율적으로 해결할 수 있도록 해줍니다. 이 기사에서 살펴보겠지만 Microsoft는 Windows® Compute Cluster Server 2003을 통해 핵심적인 계산 클러스터 기능과 지원을 제공하고 있습니다.
계산 클러스터는 가용성(장애 조치) 클러스터와는 다릅니다. Exchange, SQL Server®의 가용성 클러스터나 Windows Server® 2003의 다른 응용 프로그램에 대해서는 잘 아시리라 생각합니다. 이러한 응용 프로그램은 공유 저장소를 활용하여 응용 프로그램 작동 시간을 최대한으로 유지합니다. 그러나 계산 클러스터는 다른 시스템의 작동이 중지되었을 때 작업을 다시 시작하기 위한 것이 아니라, 모든 노드를 작업에 균형 있게 사용하기 위한 것입니다.

계산 클러스터의 일반 요구 사항
HCP 리소스
  • Windows HPC 커뮤니티
  • Windows Compute Cluster Server 2003을 사용한 고성능 컴퓨팅
  • Microsoft 64비트 컴퓨팅 개요
  • Microsoft 서버 홈
  • Compute Cluster Server TechCenter
  • 고성능 계산 클러스터 배포 설치, 구성 및 조정에 대한 단계별 가이드

최신 HPC 시스템에는 그 종류에 관계없이 작업 처리 성능을 높이기 위한 몇 가지 핵심 요소가 공통적으로 적용됩니다. 먼저, 둘 이상의 시스템이 필요합니다. 또한 노드 간의 작업 할당량을 조정하는 스케줄러가 필요합니다. 스케줄러는 작업을 실제로 담당하는 노드(헤드 노드)에서 실행되며, 사용 가능한 리소스를 파악하고 작업을 할당 및 분배하고 전반적인 작업 상태를 추적합니다. 즉, 시스템 클러스터의 리소스 조정자이자, 사용자와 관리자가 처리할 작업을 전송하는 지점이 됩니다.
클러스터에는 노드 간의 통신 수단이 필요합니다. 작업의 유형에 따라 노드에는 서로 메시지를 전달하여 처리 과정을 조율하기 위해 지연율이 낮은 고속의 상호 연결망이 필요할 수 있습니다. 최소한 각 계산 노드와 헤드 노드는 공용 네트워크에 연결되어 있어야 합니다.
서로 연결된 여러 시스템이 함께 작동하면서 복잡한 문제를 해결하기 위해서는 상당한 수준의 주의와 관리가 필요합니다. 그리고 일관되고 안정적인 환경을 구축하려면 수십 개에서 수백, 수천 개에 이르는 시스템을 구축, 모니터링, 관리 및 유지 관리할 수 있도록 설계된 프로세스와 도구가 필요합니다.
마지막으로, 계산 클러스터의 병렬 처리 기능을 활용할 수 있는 응용 프로그램을 사용하는 것이 중요합니다. 여러 컴퓨터에서 처리할 수 있도록 작업을 분배하는 응용 프로그램이나 "병렬 디버거" 지원이 포함된 개발 도구가 없으면 클러스터는 컴퓨터실 온도만 높이는 무용지물에 불과합니다.

Windows Server 기반 클러스터링
2006년, Microsoft는 광범위한 HPC 응용 프로그램의 요구 사항을 만족시키기 위해 Windows Server 2003 Compute Cluster Edition(CCE)과 Windows Compute Cluster Server 2003(WCCS)을 발표했습니다. CCE와 WCCS는 모두 사용자들에게 익숙한 Windows Server 2003을 기반으로 합니다. CCE는 HPC 응용 프로그램과 함께 사용할 수 있도록 라이선스가 부여된 Windows Server 2003의 한 버전입니다. WCCS는 CCE와 동일하지만 Microsoft® Compute Cluster Pack(CCP)이 추가되었습니다. 이 기능 팩이 추가됨으로써 기존 Windows Server 2003 시스템 관리에 사용하는 것과 동일한 도구를 사용하여 Windows Server 기반 클러스터를 배포, 관리, 모니터링 및 유지 관리할 수 있게 되었습니다.
여기서 한 가지 중요한 점은 CCE와 WCCS가 x64 전용이라는 것입니다. 다시 말해 이들 제품에는 32비트(x86) 버전이 없습니다. WCCS를 비롯하여 CCE의 하드웨어 요구 사항은 Windows Server 2003 Standard x64 Edition의 하드웨어 요구 사항과 동일합니다. 이 제품은 고성능 하드웨어(64비트 아키텍처)는 물론, 고성능 상호 연결망(Gigabit 이더넷, InfiniBand, Myrinet 등)을 위한 RDMA(원격 직접 메모리 액세스)도 지원합니다.

Compute Cluster Pack
앞서 언급했듯이 계산 클러스터에는 몇 가지 기본적인 요구 사항이 있고, 이러한 요구 사항은 Compute Cluster Pack을 설치하면 충족됩니다. CCP는 다음이 포함된 독립 실행형 설치 패키지입니다.
  • 통합 작업 스케줄러
  • 산업 표준 MPICH2를 위한 MPI(Messaging Passing Interface) 지원
  • 클러스터 리소스 관리 및 사용자 도구
CCP는 CCE와 WCCS를 구분하는 가장 핵심적인 요소입니다. 계산 클러스터에 이러한 구성 요소가 필요하다면 왜 WCCS에만 있고 CCE에는 없는지 궁금할 수도 있을 겁니다. 그 이유는 HPC 솔루션에 따라 다른 작업 스케줄러 또는 전문화된 MPI가 사용되거나 MPI가 전혀 필요하지 않아 솔루션을 실행할 뛰어난 플랫폼(예: Windows Server 2003)만 필요할 수도 있기 때문입니다. 그리고 CCP는 독립 실행형 패키지이므로 다른 x64 버전의 Windows Server 2003(CCE, Standard, Standard R2, Enterprise 및 Enterprise R2)에 설치할 수도 있습니다.

작동 방식
WCCS는 Active Directory® 및 RIS(원격 설치 서비스)를 비롯한 핵심 Windows 기본 기술을 활용하여 Windows 기반 클러스터의 관리와 운영을 단순화합니다. Compute Cluster Server는 Active Directory를 사용하여 보안을 투명하게 관리합니다. Active Directory 덕분에 사용자는 단일 자격 증명 집합을 사용하여 헤드 노드에 작업을 전송하고 이 작업이 수많은 서버 노드에서 실행되도록 할 수 있습니다. 하나 이상의 계산 노드에서 작업이 실행되면 이 작업은 작업 전송 시에 제공된 사용자 자격 증명 컨텍스트에서 실행되고 이후에 안전하게 캐시됩니다. WCCS는 Active Directory를 사용하여 이러한 "단일 로그온 지점" 기능을 제공합니다. 환경에 Active Directory를 사용하는 데 따른 또 하나의 이점은 서버 및 구성 정책을 그룹 정책을 통해 중앙에서 관리할 수 있다는 점입니다.
IT 조직에 이미 Active Directory가 배포되어 있는 경우 기존 도메인에 클러스터를 구축하면 시간과 관리 부담을 크게 줄일 수 있습니다. 이것이 가장 이상적인 시나리오라고 할 수 있습니다.
Active Directory가 없는 환경에 계산 클러스터를 배포해야 할 때는 클러스터의 Active Directory를 호스팅하기 위한 전용 도메인 컨트롤러를 하나 이상 배포하는 것이 좋습니다. 모든 노드는 네트워크 토폴로지에 관계없이 시스템으로의 네트워크 연결이 가능하므로 헤드 노드를 Active Directory 도메인 컨트롤러로 만드는 경우가 종종 있습니다. 그러나 헤드 노드를 도메인 컨트롤러로 만들면 헤드 노드에 부하가 늘어나기 때문에 대규모 클러스터에는 바람직하지 않습니다. 이 경우에는 중복 도메인 컨트롤러를 설치하고 적절한 백업과 보안 솔루션을 구현하는 등 일반적인 Active Directory 배포 및 관리 관행을 따라야 합니다.

원격 설치 서비스
WCCS는 Microsoft 원격 설치 서비스 이미지 배포 플랫폼을 위한 통합된 프런트 엔드를 제공합니다. RIS는 헤드 노드에서 각 계산 노드로 운영 체제 이미지를 배포하는 데 사용됩니다. 즉, RIS를 사용하면 새 클러스터 노드를 빠르게 설치할 수 있습니다. RIS는 WCCS에 간편하게 통합되어 있기 때문에 반드시 이러한 방법으로 배포할 필요는 없습니다. Windows Server 2003 ADS(자동 배포 서비스)나 Windows Server 2003의 수동 설치와 같은 다른 일반적인 Windows Server 배포 기술도 사용될 수 있습니다.
RIS를 사용하려면 헤드 노드에 CCP를 설치하기 전에 논리 디스크가 두 개 이상 정의되어야 합니다. RIS에는 운영 체제 디스크와는 별도로 서버 이미지를 저장하는 데 사용할 디스크가 필요합니다. RIS 파티션에는 Windows Server 이미지의 전체 복사본을 하나 이상 저장하는 데 충분한 디스크 공간이 있어야 합니다.
최신 서버 하드웨어, 특히 네트워킹 및 저장 장치에는 기본 Window Server 2003 이미지에 들어 있지 않은 플러그 앤 플레이 드라이버가 필요할 수 있습니다. 이 경우 이미지에 해당 드라이버를 수동으로 추가해야 합니다. 이미지에 드라이버를 추가하는 절차는 온라인 문서 support.microsoft.com/kb/254078을 참조하십시오.

클러스터 설치
첫 번째 단계는 클러스터의 중추라고 할 수 있는 헤드 노드를 구성하는 것입니다. 먼저 앞서 설명한 Windows Server 2003의 x64 버전 중 하나를 설치합니다. 운영 체제를 설치하는 동안 서버의 기존 도메인 참가(권장) 여부나 서버에 Active Directory를 설치(대규모 클러스터에는 권장되지 않음)할지 여부를 선택합니다.
운영 체제를 설치한 후에는 Microsoft Update를 통해 모든 권장 픽스를 다운로드하여 설치합니다. 계산 노드 이미징에 RIS를 사용하려면 컴퓨터 관리 | 디스크 관리 관리 도구를 사용하여 논리 디스크가 두 개 이상 정의되어 있는지 확인해야 합니다. 지면 관계로 이 기사에서는 RIS 기반 설치에 대해 다루지 않습니다.
성공적으로 로그인하여 서버를 업데이트했으면 CCP 설치 프로그램을 실행합니다. CCP 설치 프로그램은 다음과 같은 필수 파일과 업데이트를 자동으로 설치하거나 다운로드하여 설치하는 과정을 안내합니다.
  • RIS 핫픽스(go.microsoft.com/fwlink/?linkid=55167 참조)
  • Microsoft Management Console(MMC) 3.0(go.microsoft.com/fwlink/?linkid=62400 참조)
  • SQL Server Desktop Edition(Compute Cluster Server 2003 헤드 노드 설치 프로세스의 일부로 설치됨)
  • Microsoft .NET Framework 2.0
CCP 설치 프로그램은 시스템의 설치 준비 상태도 효과적으로 평가해 줍니다. 그림 1에 표시된 대로 프로세스를 진행하는 동안 필수적으로 설치되는 구성 요소를 알려 주고 해당 구성 요소를 설치합니다.
그림 1 CCP 설치에 필요한 구성 요소
그림 1 CCP 설치에 필요한 구성 요소

To Do List(할 일 목록)
CCP 설치가 완료되면 To Do List(할 일 목록)에 포커스가 있는 상태로 관리자 콘솔이 실행됩니다. 그림 2에 표시된 대로 To Do List(할 일 목록)에는 각각 서로 다른 분야를 다루며 클러스터 구성을 완료하는 데 핵심이 되는 작업을 보여 주는 몇 개의 창이 있습니다.
그림 2 클러스터 구성에 필요한 작업을 보여 주는 To Do List(할 일 목록)
그림 2 클러스터 구성에 필요한 작업을 보여 주는 To Do List(할 일 목록)
To Do List(할 일 목록)를 사용하여 네트워크 토폴로지, 노드 설치 프로세스 및 사용자 관리 모델을 선택하고 구성하는 등 설계한 클러스터 아키텍처를 쉽게 구현할 수 있습니다. 각 창의 작업은 오른쪽에 나열되고 작업을 선택하면 마법사가 실행됩니다. 이 마법사를 사용하여 알려진 계산 노드 집합에 RIS 이미지를 배포할 준비가 되어 있고 정의된 사용자 집합이 관리 및 액세스할 수 있는 완벽하게 구성된 헤드 노드에 대해 각각의 작업을 순서대로 완료합니다.
네트워킹 토폴로지 WCCS는 HPC에 가장 많이 사용되는 다섯 가지 네트워크 토폴로지를 지원합니다. 최소한, 모든 계산 노드와 헤드 노드는 공용 네트워크를 공유해야 합니다. 토폴로지에는 노드 사이를 연결하는 각기 별도의 장점과 비용이 있는 여러 종류의 상호 연결망에 대한 지원이 포함되어 있습니다.
네트워크 토폴로지는 클러스터의 성능, 보안 및 배포 요구 사항에 따라 결정됩니다. 예를 들어 사용하는 응용 프로그램에 회사 네트워크에 노출하고 싶지 않은 메시지를 전달하기 위한 고속 상호 연결망이 필요할 수 있습니다. 또한 통합된 RIS 기반의 자동화된 배포 기능을 이용하거나 선택한 하드웨어가 단일 NIC만 지원하거나 헤드 노드에서 ICS(인터넷 연결 공유)를 실행하여 이름 확인과 계산 노드 주소 지정을 관리하기를 원할 수도 있습니다. To Do List(할 일 목록)에서 "Configure Cluster Network Topology(클러스터 네트워크 토폴로지 구성)" 마법사를 실행하면 대개 일반적인 HPC 구현에서 지원되는 다섯 가지 토폴로지가 표시되고, 헤드 노드와 계산 노드의 Windows 방화벽 구성을 비롯한 네트워크 연결 구성 과정이 안내됩니다. 그림 3은 지원되는 네트워크 토폴로지 중 하나를 보여 줍니다.
그림 3 지원되는 WCCS 네트워크 토폴로지 중 하나
그림 3 지원되는 WCCS 네트워크 토폴로지 중 하나
원격 설치 서비스 앞서 설명했듯이 RIS는 클러스터 노드를 자동으로 배포할 수 있도록 해줍니다.
노드 관리 이 클러스터에서 계산 노드로 구성할 서버의 컴퓨터 이름을 지정할 수 있습니다. 이때 노드에서 CCP를 실행하면 해당 노드가 참가하게 되는 클러스터의 헤드 노드를 지정합니다.
사용자 관리 여기서는 클러스터의 시스템 관리자 또는 사용자가 될 Active Directory 사용자 계정 또는 그룹을 지정할 수 있습니다.

노드 설치
RIS 관리 유틸리티나 기타 지원되는 배포 방법을 사용하면 계산 노드를 자동으로 배포할 수 있습니다. 헤드 노드와 마찬가지로 각 계산 노드에도 CCP를 설치해야 합니다. 그림 4에 표시된 대로 계산 노드의 CCP 설치 구성 옵션은 헤드 노드에 비해 훨씬 간단하며 다음과 같은 프로세스로 이루어집니다.
그림 4 Compute Cluster Pack 설치 프로그램
그림 4 Compute Cluster Pack 설치 프로그램
  • 서버를 헤드 노드가 아닌 계산 노드로 지정
  • 서버가 참가해야 하는 클러스터의 헤드 노드 이름 지정
  • 계산 노드에 관리 도구와 사용자 도구를 설치할지 여부 지정

관리자 콘솔
노드가 헤드 노드와 통신하게 되면 모든 시스템에 대한 대부분의 관리 작업이 그림 5와 같이 관리자 콘솔을 통해 이루어집니다. 관리자 콘솔을 통해 모든 관련 노드의 목록, 핵심 관리 작업에 대한 액세스, 기타 정보를 비롯한 전체 클러스터를 전반적으로 살펴볼 수 있습니다. 맨 왼쪽 창은 콘솔을 통한 상위 탐색 기능을 제공합니다. 그중 "클러스터 관리자"를 선택하면 클러스터 상태와 작업 통계를 보여 주는 요약 화면이 표시됩니다. 모든 원격 데스크톱 및 시스템 모니터링 세션도 여기서 액세스할 수 있지만 대부분의 클러스터 관리 작업은 "Node Management(노드 관리)"를 통해 실행됩니다.
그림 5 전체 클러스터에 대한 보기를 제공하는 관리자 콘솔
그림 5 전체 클러스터에 대한 보기를 제공하는 관리자 콘솔
Windows와 클러스터 노드를 중앙에서 관리하는 데 필요한 주요 도구와 기능은 모두 관리자 콘솔에서 액세스해야 하므로 직접 주의 깊게 살펴보시기 바랍니다. 위쪽 가운데 창에서 클러스터 노드를 한 번 클릭하면 다른 창이 몇 개 나타나고 노드별 기능을 탐색할 수 있게 됩니다.
오른쪽 클릭 메뉴에서 제공하는 기능을 사용하면 Node Management(노드 관리)에서 계산 노드를 중앙 집중식으로 손쉽게 관리할 수 있습니다. Node Management(노드 관리)는 노드를 일시 중지 및 다시 시작하거나 클러스터에서 노드를 승인 또는 제거하거나 원격 데스크톱, 시스템 모니터 또는 이벤트 뷰어를 시작하거나 CD 트레이를 꺼내는 데 사용할 수 있습니다. 특히 CD 트레이를 꺼내는 기능은 대규모 클러스터에서 특정 컴퓨터를 물리적으로 식별할 때 매우 유용합니다.

유용한 ClusRun
이 목록에서 가장 유용한 기능으로는 "실행 명령"을 들 수 있습니다. 마치 대상 컴퓨터의 명령 프롬프트를 사용하는 것처럼 임의의 명령을 원격으로 실행할 수 있습니다. WCCS에는 Clusrun.exe라는 실행 명령 기능의 명령줄 버전이 포함되어 있습니다. "ClusRun"은 GUI와 명령줄 버전을 함께 지칭합니다.
특히 대규모 클러스터에 있어서 ClusRun을 사용하는 데 따른 이점은 아무리 강조해도 지나치지 않습니다. 반복적인 명령줄 작업을 실행하는 데 소요되는 시간을 크게 줄여줄 뿐만 아니라 복잡한 관리 스크립트를 작성해야 하는 수고를 덜어 주기도 합니다.
이 기능을 사용하려면 명령을 실행할 대상 컴퓨터의 목록을 선택한 다음 해당 목록을 마우스 오른쪽 단추로 클릭하고 실행 명령을 선택합니다. 그러면 그림 6의 대화 상자가 표시됩니다. 이제 원하는 명령을 입력하고 실행을 클릭한 다음 결과 창에 출력이 표시되기를 기다립니다. ClusRun을 처음 사용할 때는 자격 증명 여부를 확인하지만 나중에 다시 사용할 때는 내용을 입력할 필요가 없도록 이 자격 증명을 캐시할 수 있습니다.
그림 6 여러 노드에 대해 명령 실행 가능
그림 6 여러 노드에 대해 명령 실행 가능
자동화된 설치 루틴을 포함하는 클러스터를 패치하거나 프로그램을 설치할 때는 해당 패치 또는 프로그램을 파일 공유에 넣고 ClusRun을 사용하여 강제로 모든 계산 노드에서 명령을 실행하도록 하는 방법이 많이 사용됩니다. 또한 다음과 같은 단일 명령을 통해 전체 클러스터의 모든 계산 노드를 다시 부팅할 수 있습니다.
CLUSRUN SHUTDOWN –R –F –T 0

도구 팩
HPC 팀에서는 2007월 5월에 Compute Cluster Pack 도구 팩을 발표했습니다. 이 도구 팩은 온라인(windowshpc.net/resources/Pages/default.aspx)에서 다운로드할 수 있습니다. 이 도구 팩에는 Windows PowerShellTM에 대한 지원 기능, 연결 상태 진단을 위한 MPIPingPong 도구 및 간단하지만 매우 유용한 그래픽 클러스터 모니터가 포함되어 있습니다.
그림 7에 표시된 대로 Simple Cluster Monitor(간단한 클러스터 모니터)를 통해 클러스터의 각 노드를 한 화면에 표시하고, 각 노드에 설치된 코어 개수, 각 CPU의 사용률(밝은 녹색), 메모리 사용률(노랑), 디스크 사용 시간 비율(빨강), 네트워크 대역폭 사용률(주황) 등을 확인할 수 있습니다. 관리자가 클러스터의 작동 상태를 확인하는 데 더할 나위 없이 유용한 요약 도구라 하겠습니다.
그림 7 Simple Cluster Monitor(간단한 클러스터 모니터)를 통해 다수의 노드 모니터링
그림 7 Simple Cluster Monitor(간단한 클러스터 모니터)를 통해 다수의 노드 모니터링
클러스터 모니터에는 "원격 실행이 가능한" 기능도 있습니다. 클러스터 모니터의 첫 번째 인스턴스는 헤드 노드에서 실행해야 하지만, 헤드 노드의 콘솔 세션에서 클러스터 모니터의 인스턴스를 실행하면 워크스테이션에서 클러스터 모니터의 인스턴스를 여러 개 실행하고 헤드 노드에서 해당 인스턴스를 가리킨 다음 동일한 화면을 표시할 수 있습니다.

마치며
이제 HPC와 Windows Server 2003 Compute Cluster Server에 대해 잘 이해하셨으리라 믿습니다. CCP 설치 방법에 대해서도 배웠고 모든 기능이 통합된 콘솔도 살펴보았으며 동료와 사용자를 사로잡을 만한 새롭고 유용한 명령과 그래픽 도구도 사용할 수 있게 되었습니다. "HPC 리소스" 추가 기사에는 고성능 컴퓨팅과 관련한 추가 정보를 얻을 수 있는 리소스도 나와 있습니다.

John Kelbley는 미국 북동부에 소재한 Microsoft의 Global Solutions Technology 팀에서 기술 제품 관리자로 일하고 있습니다. John에게 문의 사항이 있으면 Johnkel@microsoft.com으로 연락하십시오.
Doug Lindsey는 Microsoft HPC 팀의 프로그램 관리자로서, 2007년 11월 목록(www.top500.org)의 116번을 비롯한 계산 클러스터의 제작도 관리하고 있습니다. Doug에게 문의 사항이 있으면 Dougli@microsoft.com으로 연락하십시오.


 Online Extra: 터미널 서비스를 사용한 2007 Office system 배포
Online Extra James D. Silliman

터미널 서비스를 사용한 2007 Office system 배포
한 눈에 보기:
  • 2007 Office system용 배포
  • 사용자 설정 관리
  • 새로운 빠른 실행 도구 모음
  • 2007 Office system용 사용자 지정 도구

2007 Microsoft Office system 릴리스에서는 많은 디자인 변경이 이루어졌습니다. 터미널 서비스 서버 팜에 2007 Microsoft Office system을 배포하거나 이전 버전에서 업그레이드하려면 이러한 변경에 대해 파악하고 있어야 합니다. 기본 서식 파일, 빠른 실행 도구 모음,
그룹 정책용 .adm 파일 스냅인, OCT(Office 사용자 지정 도구)에 대해 잘 알고 있어야 합니다. 이러한 도구에 대한 사전 지식이 있으면 배포를 원활하게 마칠 수 있습니다. 지금부터 Microsoft® Word를 통해 이러한 디자인 변경에 대해 살펴보도록 하겠습니다.

Word 2007 배포
Word에는 항상 기본 서식 파일이 사용되며 2007 Office system에서는 이 파일을 normal.dotm이라고 합니다. 터미널 서비스 환경에서는 세 가지 방법으로 Word와 normal.dotm 파일을 배포할 수 있습니다. 먼저, Office가 설치된 모든 터미널 서비스 서버에 이 파일만 두어 사용자에게 표준 Word 기본 보기가 표시되도록 할 수 있습니다. 또는 각 터미널 서버에서 파일을 열고 사용자 지정 사항을 추가하는 방식으로 파일을 수정하여 사용자에게 Word의 기본 보기가 표시되지 않도록 할 수도 있습니다. 마지막으로, 파일 이름을 완전히 바꿔서 사용자에게 고유의 파일을 제공할 수도 있습니다. 이 파일은 사용자가 Word에서 설정을 변경하고 기본값을 클릭하면 수정됩니다.
어떤 방법을 선택하든 배포하기 전에 수행하는 것이 좋습니다. 관리자가 기본 설정을 전혀 변경하지 않을 경우 터미널 서비스 서버의 기본 서식 파일이 사용자의 개별 프로필에 있는 기본 서식 파일을 덮어쓰기 때문에 사용자는 자신의 기본 서식 파일에서 변경한 내용을 저장할 수 없습니다. 서식 파일을 열어서 수정하지 않으면 Word 2007에서는 기본 설정만 제공합니다.
필요한 경우 터미널 서비스 팜의 각 서버에서 파일을 수정할 수 있습니다. 이런 방법을 통해 모든 사용자에게 기본 글꼴 및 크기, 단락 간격, 레이아웃 등의 Word 설정을 동일하게 제공하려면 이 기본 서식 파일을 기본 경로 위치에 유지해야 합니다. 그런 다음 각 터미널 서비스 컴퓨터에서 기본 서식 파일을 열고 Word 2007 레이아웃을 원하는 대로 변경한 후(기본값 클릭) 변경 내용을 저장하여 기본 normal.dotm 파일에 기록함으로써 사용자 전체에게 배포할 설정을 수정할 수 있습니다.
기본 서식 파일을 변경하기 전에 먼저 백업해야 합니다. 그렇지 않으면 원래 파일을 가져오기 위해 Word 2007을 다시 설치해야 할 수도 있습니다. normal.dotm 파일을 수정하면서 빠른 실행 도구 모음을 변경한 경우 빠른 실행 도구 모음의 변경 내용은 기본 서식 파일에 저장되지 않습니다. 빠른 실행 도구 모음과 그 동작에 대해서는 잠시 후에 살펴보겠습니다.
사용자가 Word 내에서 자신의 기본 설정을 관리하도록 할 수 있을까요? 할 수 있습니다. 그러나 이렇게 하려면 팜의 모든 서버에서 normal.dotm 파일의 이름을 normal.dotm.old 등의 다른 이름으로 바꿔야 합니다. Word를 사용 중인 다른 응용 프로그램이 있는 경우 사용자가 Word를 닫으면 서식 파일 오류가 표시될 수 있기 때문에 이름을 바꾸는 것이 좋습니다.
이 파일의 이름을 바꾸면 Word 2007에서는 이를 전역 기본 설정 대신 사용자가 직접 고유의 기본 설정을 관리하도록 허용한다는 의사로 받아들이고, 사용자가 설정을 수정 및 저장하도록 허용합니다. Word 2007의 사용자 지정 normal.dotm 파일은 각 사용자의 프로필 경로에 저장됩니다. 로밍 프로필을 사용하는 경우(경로 설정 방법에 따라 다름) 이 서식 파일이 각 사용자의 프로필 폴더 위치인 \\domain\sharename\<username>\Application Data\Microsoft\Templates에 저장됩니다.
그러나 빠른 실행 도구 모음에 변경한 내용은 normal.dotm file 파일에 저장되지 않습니다. 이 도구 모음은 2007 Office system의 새로운 기능으로, 2007 Office system에 역시 새로 도입된 기본 리본 도구 모음과는 별개입니다. 빠른 실행 도구 모음은 2007 Office system에서 기본적으로 화면 왼쪽 위 모서리에 표시되는 미니 도구 모음입니다. 이 도구 모음은 2007 Office system의 응용 프로그램을 위한 것입니다(그림 1 참조). 자세한 내용은 support.microsoft.com/kb/926805를 참조하십시오.
Figure 1 빠른 실행 도구 모음 파일 (Close Figure 1)

Office 응용 프로그램 | 기능 영역 | 파일 이름
Access 2007 | 모두 | Access.qat
Excel 2007 | 모두 | Excel.qat
Outlook 2007 | 연락처 일정 메일 그룹 업무 일지 항목 메일 폴더에 게시 작업 | Olkaddritem.qat Olkapptitem.qat Olkdistitem.qat Olklogitem.qat Olkmailitem.qat Olkpostitem.qat Olktaskitem.qat
PowerPoint 2007 | 모두 | PowerPoint.qat
Word 2007 | 모두 | Word.qat
그림 1에서 볼 수 있듯이 빠른 실행 도구 모음은 확장명이 .qat인 파일에 사용자 지정 설정을 저장합니다. 이 파일은 팜의 각 터미널 서비스 서버에 있는 기본 파일 경로 위치인 C:\Documents and Settings\<username>\Local Setting\Application Data\Microsoft\Office(또는 Windows Vista®를 실행하는 컴퓨터의 경우 C:\Users\<username>\AppData\Local\Microsoft\Office)에 보관되며 로밍되지 않습니다.
이 경로를 자세히 살펴보면 .qat 파일이 터미널 서비스 사용자의 로컬에 캐시된 프로필에 대한 Local Settings 하위 폴더에 있음을 알 수 있습니다. Local Settings는 표준 로밍 프로필 경로 구조에 없기 때문에 이 하위 폴더는 로그오프 시 사용자의 로밍 프로필과 동기화되지 않습니다. 따라서 해당 GPO(그룹 정책 개체) 설정을 사용하여 터미널 서비스 서버의 로컬에 캐시된 프로필을 삭제하게 되면 사용자 지정 .qat 파일이 손실됩니다. 자세한 내용은 기술 자료 문서(support.microsoft.com/kb/274152)를 참조하십시오.
캐시된 프로필 삭제는 터미널 서비스 관리자가 사용자 로그오프 시 로컬 프로필을 정리하기 위해 일반적으로 수행하는 작업이지만 2007 Office system에서는 빠른 실행 도구 모음의 변경 내용이 로컬에 캐시된 프로필에 저장되도록 변경되었으므로 유의해야 합니다. 이 문제를 해결하는 한 가지 방법은 앞서 언급한 기술 자료 문서에서 설명하는 GPO 설정을 설정하지 않는 것입니다. 사용자 수가 많을 경우 로그오프 시 캐시된 프로필 삭제 설정을 사용하지 않으면 각 터미널 서비스 서버의 로컬 %systemroot% 드라이브의 하드 드라이브 공간 사용량이 많아져 하드 드라이브 공간이 부족해질 수 있으므로 이를 모니터링하기 위한 별도의 프로세스를 마련해야 합니다. 로컬 프로필은 크기가 금방 커질 수 있으므로 이 프로세스를 설정하는 것은 흔한 일입니다.
어떤 방법을 취하든 .qat 파일이 사라지거나 실수로 삭제될 경우 복구할 수 있도록 정기적으로 파일을 백업하는 루틴을 로그인 스크립트에 추가해야 합니다. 사용자 지정 파일의 백업을 보관하면 사용자가 로컬 지원 센터에 파일 복구를 요청하는 일을 방지할 수 있습니다.
대부분의 터미널 서비스 관리자는 로컬에 캐시된 프로필을 백업하지 않습니다. 대신 네트워크 로밍 프로필을 백업하는데 앞에서도 언급했듯이 이 프로필에는 .qat 파일의 복사본이 포함되지 않습니다. 또 다른 방법으로는 각 사용자에 대해 필수 프로필을 배포한 다음 각 사용자의 Local Settings 변경을 네트워크에 있는 별도의 폴더에 매핑하는 타사 제품을 사용할 수 있습니다.

그룹 정책 스냅인
이전의 Office 2003에서는 그룹 정책 .adm 파일을 사용하여 Office 정책 및 사용자 환경을 보다 강력하게 제어할 수 있었습니다. 2007 Office system에도 이와 마찬가지로 처음 실행 대화 상자를 비활성화하거나 자동 저장 설정 및 다른 기본 설정을 수정하는 등의 사용자 지정을 수행하는 데 사용할 수 있는 새로운 .adm 파일이 있습니다.
이전에 Office 2003 그룹 정책을 배포한 경우 2007 Office system으로 업그레이드하려면 먼저 기존 Office 2003 .adm 파일을 GPO에서 제거한 후 2007 Office system .adm 파일을 추가해야 합니다. 새 스냅인을 추가한 후 오류가 발생할 경우 이전 상태로 되돌릴 수 있도록 반드시 GPMC(그룹 정책 관리 콘솔) 인터페이스를 사용하여 GPO를 백업해야 합니다. 한 터미널 서비스 관리자에 따르면 Office 2003 스냅인을 제거한 다음 2007 Office system .adm 파일을 GPO에 추가한 후 고스트 정책 항목이 만들어졌다고 합니다.
필자는 2007년 5월호 기사인 "터미널 서비스 배포 가이드"(technetmagazine.com/issues/2007/05/TerminalServices)에서 Outlook® 자동 보관 같은 작업을 수행하거나 처음 실행 대화 상자 화면을 허용할지 등을 묻는 메시지가 터미널 서비스 사용자에게 표시되지 않도록 설정해야 한다고 설명한 바 있습니다. Outlook 2007을 처음 시작하면 기본적으로 두 개의 처음 실행 화면이 사용자에게 표시됩니다. 하나는 개인 정보 옵션에 대한 화면이고 다른 하나는 데스크톱 검색에 대한 화면입니다. 그림 2에 나오는 첫 번째 화면은 GPO 설정을 수정하거나(새 Outlook 2007 .adm 파일 사용) Office 사용자 지정 도구를 사용하거나 레지스트리를 수정하여 비활성화할 수 있습니다.
그림 2 2007 Office system의 개인 정보 옵션 대화 상자
그림 2 2007 Office system의 개인 정보 옵션 대화 상자
그림 3의 화면은 다른 모든 2007 Office system 응용 프로그램에서 개인 정보 옵션 화면 바로 다음에 나타납니다(비활성화하지 않은 경우).
그림 3 2007 Office system의 빠른 검색 기능 대화 상자
그림 3 2007 Office system의 빠른 검색 기능 대화 상자
Office 응용 프로그램에서 Windows® 검색을 설치할지 묻는 메시지를 표시하지 않으려면 go.microsoft.com/fwlink/?LinkId=78161에서 2007 Office system ADM 템플릿을 다운로드하십시오. 그룹 정책의 컴퓨터 구성 또는 사용자 구성의 스냅인 추가에서 Office Outlook 2007 템플릿(Outlk12.adm)을 로드해야 합니다. 그런 다음 사용자 구성\관리 템플릿\Microsoft Office Outlook 2007\도구 | 옵션\기본 설정\검색 옵션으로 이동하여 "Windows 데스크톱 검색 구성 요소가 없으면 설치 확인 안 함" 설정을 활성화해야 합니다.
2007 Office system에는 사용자 환경을 제어하는 데 사용할 수 있는 많은 그룹 정책 설정이 있습니다. 이러한 각 .adm 파일을 GPO에 추가해야 합니다. 즉 Word의 경우 Word12.adm을, Excel®의 경우 Excel12.adm을 GPO에 추가해야 합니다. 그림 4에서는 그룹 정책에 추가된 Outlook 2007 ADM 템플릿(Outlook12.adm)을 예로 보여 줍니다.
그림 4 그룹 정책의 Outlook 2007 ADM 템플릿
그림 4 그룹 정책의 Outlook 2007 ADM 템플릿

추가 변경 사항
Office 2003에서도 사용자 지정 설치 마법사를 다운로드하고 이를 사용하여 사용자 지정을 수행할 수 있습니다. 2007 Office system의 새 OCT는 별도로 다운로드할 필요가 없습니다. 새 OCT는 2007 Office system 미디어나 설치 원본을 가리키도록 설정되어 있으며 실행 명령에서 "Setup /admin"을 입력하면 시작됩니다. 설치 원본 파일에 대해 이 명령을 실행한 다음 원하는 대로 개별 설정을 변경하면 .msp 파일(Office 2003의 .mst 파일)이 만들어지므로 이후 배포 시 개별 설정을 포함하기 위해 명령줄 옵션을 별도로 지정할 필요가 없습니다. 사용자 지정 .msp 파일을 네트워크 설치 위치의 루트에 있는 Updates 폴더에 가져다 놓기만 하면 기본 설정과 함께 자동으로 배포됩니다.
Outlook 2007은 Exchange 2007 서버가 LAN 내에서 실행되는 경우 서버를 자동으로 찾고 SCP(서비스 연결 지점) 쿼리를 직접 Active Directory®로 보낸다는 점에 있어서 이전 버전에 비해 향상되었습니다. 이 쿼리를 통해 배포되어 있는 Exchange 2007 인프라에 쉽게 연결할 수 있습니다. 자세한 내용은 go.microsoft.com/fwlink/?linkid=76177을 참조하십시오.
Microsoft는 배포 도구를 단순화하고 새 .adm 파일 스냅인을 추가하고 인터페이스를 효율적으로 변경함으로써 2007 Office system이 터미널 서비스 환경에서 작동하는 방식에 있어서 디자인상의 중요한 몇 가지 변경을 구현했습니다. Office 응용 프로그램을 배포하거나 업그레이드하기 전에 이 문서에서 설명하는 개념에 대해 알아두면 업그레이드 과정을 보다 잘 파악하게 되어 중요한 디자인 결정을 미리 할 수 있습니다. 당장 업그레이드할 계획이 없다면 2007 Office system 호환 기능 팩을 로드해 보십시오. 이렇게 하면 2007 Office system으로 업그레이드한 사용자가 보낸 첨부 파일을 사용자가 열어볼 수 있습니다. 호환 기능 팩은 go.microsoft.com/fwlink?LinkID=77512에서 다운로드할 수 있습니다.
이 문서의 내용을 알고 있으면 언제든지 2007 Office system을 성공적으로 배포할 수 있습니다. 사용자 커뮤니티에 배포하기 전에 정책을 백업하고 테스트 환경에서 권장 설정을 모두 테스트하십시오.

James D. Silliman은 터미널 서비스 배포 분야의 전문 지식을 가진 Microsoft 기술 전문가로, 현재는 ASP를 위해 소규모 기업용 IT 솔루션을 만드는 일을 하고 있습니다. 문의 사항이 있으면 jsilliman@gmail.com으로 연락하시면 됩니다.


 From the Editor: 정보 과부하에 대한 대응
From the Editor
정보 과부하에 대한 대응
Joshua Hoffman

이번 달의 두 가지 중심 주제인 SharePoint와 Office Communications Server를 생각해보면 우리가 해당 서버를 연결할 때 종종 어려움을 겪는다는 사실이 그리 놀랍지 않습니다. 여러분이 이 글을 읽으실 때 쯤이면 이미 약 한 달 전의 이야기가 되겠지만, 이 글을 쓰고 있는 현재 뉴욕은 완연한 휴가 분위기에 휩싸여 있습니다. TechNet Magazine 본사는 휴가 분위기에 젖은 뉴욕의 심장부인 록펠러센터에 있습니다. 록펠러센터는 여러 면에서 뉴욕의 명소 중 하나이지만 매년 이맘때의 약 한 달 간은 마치 하나의 도전이라고 할 수 있을 것입니다. 쇼핑을 하거나 쇼를 감상하기 위해, 또는 장대한 마천루를 배경으로 스케이트를 타기 위해 미국 전역과 전 세계에서 몰려드는 사람들로 유동 인구는 평상시보다 더욱 늘어납니다. 이 시기에 많은 뉴요커들은 황급히 도시를 빠져나갑니다.
관광객들이 보도 한 가운데 서서 사진을 찍게 되면 뒤에 오던 사람들이 갑자기 멈춰 서거나 가로질러 지나가는 것이 짜증 때문이라는 분들도 계십니다. 하지만, 그렇지는 않습니다. 사실 저희는 여러분들이 이 도시에 오셔서 즐겁습니다. 이는 과부하 문제와도 같다고 볼 수 있습니다. 이미 평상시에도 붐비는 도시가 이 시점에 인파의 정점을 이루는데, 그것이 너무 과한 것이지요.
IT 업계에서도 이와 매우 유사한 동향이 발견됩니다. 조직은 계속해서 성장하고(아마도 그것이 우리가 바라는 것이겠지요), 그 결과 매일 더 많은 정보가 생성됩니다. 이에 따라 파일 공유 영역과 데이터베이스가 가득 차게 됩니다. 전자 메일이야 굳이 언급하지 않도록 하겠습니다. 1기가바이트가 대형 저장 용량으로 인식되던 시절이 그리 오래전의 일은 아니지만 오늘날에는 가정용 PC에서조차도 테라바이트 규모의 용량이 보편적으로 사용됩니다. 현재 데이터센터에서는 페타바이트 규모의 저장 용량을 계획 중인 경우도 많습니다. 정보가 아주 많다는 점에는 모든 분들이 동의하실 것입니다. 그러나 그 정보는 유용한 것일까요? 아니면 그저 걷잡을 수 없이 많은 것일 뿐일까요? 체계적으로 정리는 되어 있을까요? 분석하기는 쉬운가요? 쉽게 공유할 수 있나요?
이렇듯, 이토록 방대한 정보량에도 불구하고 서로 연결이 어렵다는 점은 그리 놀라운 일은 아닙니다. 그러나 지금보다 훨씬 더 쉬워질 수는 있습니다. 바로 이것이 이번 달 TechNet Magazine의 주제입니다. 이번 호에서는 SharePoint의 강력한 기능을 활용하여 기업에서 보다 쉽고 효과적으로 데이터를 수집 및 정리하는 방법, 빠르게 설문 조사를 구축하고 사용자 또는 고객으로부터 데이터를 수집하는 방법, 수집된 정보에 더 많은 의미성을 부여할 수 있도록 사용자 지정 콘텐츠 형식을 정의하는 방법 및 Office Communications Server를 이용하여 이토록 중요한 연결을 구축하는 방법 등이 소개됩니다. 함께 공유할 사람이 없다면 그 많은 데이터를 모두 갖고 있는 것이 대체 무슨 소용이겠습니까? —Joshua Hoffman

도움을 주신 Ed Banti, Susan Bradley, Byron Hynes, Michael Murgolo, Ken Oien, Jim Truher, Kay Unkroth를 비롯한 Microsoft 기술 전문가 분들께 감사 드립니다.


 Letters: 독자의 목소리
Letters
독자의 목소리

ActiveX Installer 서비스 이용 가능성
최근 2007년 7월호 기사 "Windows Vista의 ActiveX Installer 서비스"(technetmagazine.com/issues/2007/07/AxIS)를 읽었습니다. 이 서비스를 지금 이용할 수 있나요?
—Eugene Y.

예. ActiveX® Installer 서비스는 현재 제공되고 있습니다. Windows Vista®의 프로그램 및 기능 제어판에 있는 "Windows 기능 사용/사용 안 함" 옵션을 활성화하여 쉽게 이용하실 수 있습니다.
ActiveX Installer 서비스는 Windows Vista의 Ultimate, Enterprise 및 Business 버전에만 있는 옵션 구성 요소입니다. ActiveX Installer 서비스를 통해 ActiveX 설치를 허용하는 사이트 목록은 그룹 정책을 통해 관리됩니다. 이 목록은 그룹 정책 개체 편집기의 컴퓨터 구성 | 관리 서식 파일 | Windows 구성 요소 | ActiveX Installer 서비스 섹션에 저장되어 있습니다.

Active Directory 도구
"Active Directory 관리를 위한 11가지 필수 도구" 기사(2007년 9월)를 다루어 주셔서 감사합니다. 기사에서 설명한 dsrm 유틸리티로 다음의 명령줄을 이용하여 Active Directory®에서 사용자를 삭제하려 해봤습니다.
          dsquery user -samid <samid> | dsrm
그런데 "dsrm" 입력이 잘못된 양식으로 되어 있다는 오류 메시지를 받았습니다. 그런데 명령은 아무 문제없이 별도로 잘 수행이 됩니다. 어떻게 된 것인지요?
—Keith E.

보내주신 질문을 해당 기사를 작성한 Laura Hunter에게 전달했습니다. Laura에 따르면 dsquery 결과를 dsrm에 파이핑할 경우 dsrm에 -noprompt 스위치가 필요하다고 합니다. 따라서 다음과 같은 명령을 사용해야 할 것입니다.
dsquery user -samid <samid> | dsrm -noprompt
원래 기사에 이 정보가 누락되었던 점을 사과드리며 온라인 버전에서는 그 부분을 수정하도록 하겠습니다.

다른 퍼즐의 가능성
아마 지금쯤 알고 계실 것이고 이미 다른 많은 분들이 알려드렸을 것이라 생각됩니다만, Dr. Scripto의 Scripting Perplexer 퍼즐(2007년 11월)의 해결 방법에는 두 가지가 있습니다. 그 퍼즐은 첫째 줄과 둘째 줄에 표시되는 4자리 변수가 nnde이고 셋째 줄과 넷째 줄에 표시되는 5자리 변수가 iamex인 경우에도 올바로 해독됩니다.(물론 이러한 차이는 사소하며 기사에서 제시한 해결책에 사용된 이름들이 스크립트의 가독성을 훨씬 더 높여준다고 생각지만요.)
퍼즐을 제공해 주셔서 감사드립니다. 재미있었습니다.
—Stan A.

다른 해결책을 알려주셔서 감사합니다! 새 Scripting Guys 퍼즐이 재미 있으셨다니 기쁩니다. 그리고 그 퍼즐 시리즈가 TechNet Magazine의 정규 기사로 채택되어 더욱 기쁩니다.

Windows Vista 마이그레이션 권유
TechNet Magazine 2007년 11월 기사(technetmagazine.com/issues/2007/11/Offline) "Windows Vista의 오프라인 파일 변경 내용"은 오프라인 파일 분야에서의 Windows Vista의 장점을 매우 잘 보여주었습니다. Windows® XP Professional을 사용하면서 오프라인 파일과 관련된 여러 가지 문제를 겪었던 터라 해당 기사는 Windows Vista로 마이그레이션을 결정하는 데 큰 도움이 되었습니다.
—Daniel Z.

감사합니다! 해당 기사가 귀사에 도움이 되었다니 매우 기쁩니다.

누락 페이지
TechNet Magazine에서 유용하고 재미있는 정보를 얻고 있습니다. 그런데 제 2007년 12월호 인쇄본에 49-64페이지가 누락되어 있습니다. 저는 60페이지에 수록된 Tom Cloward와 Frank Simorjay의 컴퓨터 조사 관련 기사("기본 컴퓨터 범죄 조사 가이드")에 관해 읽고 싶습니다. TechNet Manazine의 인쇄 조사 팀에서 이 누락된 페이지와 데이터를 찾아 주실 수 있으신가요? 그 기사를 온라인에서 읽을 수 있다면 더 없이 좋겠는데요, 혹시 URL을 알려주실 수 있나요?
—Dave S.

유감스럽게도 2007년 12월호를 인쇄하던 중 문제가 발생하여 일부 독자님들께 49-64페이지가 누락된 호가 송부되었습니다. 인쇄 담당자와 TechNet Magazine 팀을 대신하여 불편을 드린 점에 깊이 사과드립니다.
언급하신 기사 및 나머지 12월호 기사들이 현재 온라인으로 제공되고 있습니다(technetmagazine.com/issues/2007/12).


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

파일 잠금 해제
Unlocker
ccollomb.free.fr/unlocker
자동화된 프로세스가 작업 도중 멈추고 이로 인해 파일이 쓰기 잠금 상태가 되어 파일을 복사, 이동, 쓰기 또는 삭제할 수 없기 때문에 다른 작업이 실패하는 상황을 경험해본 적 있을 것입니다. 파일을 잠근 사람이 누구인지는 모르지만 어떤 파일이 잠겼는지는 아는 경우가 있습니다. 이 경우에는 어떻게 해야 할까요?
이 상황을 해결하는 방법에는 여러 가지가 있지만 Cedrick Collomb가 작성한 무료 도구인 Unlocker에서는 파일 잠금 문제에 대한 쉽고 빠른 Windows® 탐색기 통합 솔루션을 제공합니다. 이 도구는 Windows 탐색기와 통합되기 때문에 잠긴 파일(또는 파일 집합)을 마우스 오른쪽 단추로 클릭하고 상황에 맞는 메뉴에서 Unlocker를 선택하기만 하면 파일을 잠근 프로세스를 찾아낼 수 있습니다. 잠긴 파일이 발견되면 문제의 프로세스 중단, 파일 잠금 해제(핸들 닫기), 파일 삭제, 파일 이동 또는 파일 이름 변경과 같은 다양한 옵션을 선택할 수 있습니다. 또한 잠긴 파일을 현재 상태로 다른 위치에 복사할 수도 있습니다.
Unlocker에서는 완전한 응용 프로그램 설치 관리자를 제공하므로 DLL을 수동으로 등록하거나 등록 해제할 필요가 없으며 시스템을 다시 부팅하지 않고도 도구를 시작할 수 있습니다. 또한 알림 메시지가 자주 수신되어도 괜찮다면 자동 업데이트 알림을 사용하여 항상 최신 버전으로 유지할 수도 있습니다.
Unlocker에서는 명령줄 실행도 지원하므로 자동화에 매우 적합합니다. 예를 들어 로그를 이동하려고 할 때 잠긴 .zip 파일이 발견된 경우 자동으로 압축 프로세스를 처리 및 중단하도록 로그 전달 프로세스를 구성할 수 있으므로 수동으로 문제를 해결하기 위해 새벽같이 일어날 필요가 없습니다.
이 유틸리티에는 Unlocker Assistant라는 시스템 트레이 도구도 있습니다. 이 도구를 사용하면 잠김 파일을 이동, 이름 변경 또는 삭제하려고 할 때 자동으로 Unlocker 인터페이스를 실행할 수 있으므로 파일을 찾고 오른쪽 단추를 클릭하면 나타나는 상황에 맞는 메뉴에서 Unlocker를 선택하는 불편을 줄일 수 있습니다. Unlocker는 Windows Vista®를 포함한 대부분의 Windows 버전과 호환됩니다.

가격: 무료
잠긴 파일을 신속하게 찾고 잠금 해제할 수 있는 Unlocker
잠긴 파일을 신속하게 찾고 잠금 해제할 수 있는 Unlocker

네트워크 트래픽 분석
Wireshark
wireshark.org
강력한 네트워크 프로토콜 분석기를 사용하면 해당 인프라의 네트워크 트래픽 기본 사항을 파악하여 상호 연결된 응용 프로그램의 모든 계층 아래의 실제 진행 상황을 확인할 수 있습니다. 가장 잘 알려진 공개 소스 분석기는 Wireshark로, 이 도구는 Windows용 공개 소스 WinPcap 패킷 캡처 라이브러리를 사용하며 여전히 Gerald Combs가 관여하고 있는 Ethereal에서 파생되었습니다.
Wireshark를 사용하면 네트워크 인터페이스를 가로지르는 트래픽을 손쉽게 캡처하여 사용하기 쉬운 그래픽 인터페이스에서 각 패킷의 세부 사항을 검사할 수 있습니다. 인터페이스를 선택하고 시작을 클릭하는 것만으로 새 패킷 캡처 세션을 시작할 수 있습니다. GUI에는 캡처된 패킷이 색상으로 구분되어 표시되고 여기에는 시간, 소스, 대상, 프로토콜 및 미리 지정된 이벤트 설명이 실시간으로 자세히 제공됩니다. 전송을 클릭하면 세부 사항이 강조 표시되고 패킷 데이터가 분석하기 쉬운 세부 사항 창으로 해석됩니다. 그 아래에는 원시 패킷이 16진수와 ASCII로 표시됩니다.
분석해야 하는 데이터 집합을 확보한 다음에는 나중에 분석할 수 있도록 세션을 저장하거나 내보낼 수 있습니다. Wireshark에서는 다양한 프로토콜을 디코딩할 수 있으며 문제 해결에 필요한 대부분의 항목이 제공됩니다.
네트워크에는 방대한 양의 데이터가 흐르며 이 응용 프로그램에서는 이러한 모든 데이터를 필터링할 수 있도록 강력한 식 기반 필터 기능을 제공합니다. 이 기능을 사용하면 프로토콜의 각 매개 변수에 따라 검색 대상을 좁힐 수 있습니다. 예를 들어 네트워크의 특정 IP에서 나가고 들어오는 BitTorrent에 관련된 트래픽을 제외한 모든 트래픽을 필터링할 수 있습니다. 또는 필터를 이용하면 많은 위조 브로드캐스트 메시지를 전송하여 네트워크에 문제를 일으키는 시스템을 쉽게 찾아낼 수 있습니다.
또한 인터페이스에서는 검토할 패킷에 쉽게 플래그를 지정하고 특정 전송을 캡처의 시간 참조로 설정할 수 있습니다. 필자가 즐겨 사용하는 Wireshark의 기능 중 하나는 TCP 패킷을 마우스 오른쪽 단추로 클릭하고 상황에 맞는 메뉴에서 해당 옵션을 선택하여 TCP 스트림을 따라가는 기능입니다. 이렇게 하면 TCP 스트림 내용이 색상 지정되고 서식 있는 텍스트로 표시되는 창이 열립니다. 이 창은 웹 응용 프로그램 오류, 잘못된 HTTP 헤더 또는 기타 TCP 통신 문제를 감지하는 데 매우 유용합니다. 또한 차후의 검사나 데모를 위해 창의 내용을 신속하게 인쇄하거나 저장할 수 있습니다.
지금까지 이 응용 프로그램의 여러 기능 중 극히 일부만 소개했습니다. Wireshark는 GPL 라이선스에 따라 릴리스되며 Windows에서 사용할 수 있을 뿐만 아니라 대부분의 Linux 및 FreeBSD 버전에서 사용할 수 있는 컴파일된 바이너리도 제공합니다.

가격: 무료
전체 네트워크 프로토콜을 분석할 수 있는 Wireshark
전체 네트워크 프로토콜을 분석할 수 있는 Wireshark

Windows PowerShell 강화
PowerShell Community Extensions
codeplex.com/PowerShellCX
Windows PowerShellTM 사용 경험이 있다면 cmdlet 또는 별칭의 사용이 적합한 반복되는 실행 패턴을 접했을 것입니다. 이런 이유로 공개 소스 커뮤니티의 Windows PowerShell 사용자 및 옹호자 그룹에서는 자주 요청되는 기능을 배포 가능한 cmdlet, 별칭, 공급자, 함수, 필터 및 스크립트 집합으로 묶은 PowerShell Community Extensions 프로젝트를 만들었습니다.
이 패키지에 포함된 cmdlet 중에는 클립보드 버퍼에서 데이터를 추가하거나 검색할 수 있는 Get-Clipboard 및 Write-Clipboard가 있습니다. Get-DomainController를 사용하면 현재 도메인에서 사용할 수 있는 도메인 컨트롤러 목록을 검색할 수 있으며, Write-GZip 및 Write-Zip을 사용하면 GZIP 및 ZIP 파일을 작성할 수 있습니다.
Windows Vista 또는 Windows Server® 2008에서 New-Symlink 및 New-Junction을 사용하여 새로운 심볼 링크 또는 연결을 만들 수 있습니다. Active Directory® 및 AssemblyCache와 같은 LDAP 서버에 대한 액세스를 제공하는 유용한 DirectoryServices 공급자가 있습니다. 이 공급자를 사용하면 Microsoft .NET Framework 전역 어셈블리 캐시와 그 내부의 어셈블리에 액세스할 수 있습니다.
또한 여러 개의 강력한 스크립트도 있습니다. Set-Writable 및 Set-ReadOnly 스크립트를 사용하면 파일의 읽기 전용 상태를 신속하게 변경할 수 있습니다. Get-Url은 WebRequest를 만들고 WebResponse를 문자열로 반환하며 Export-History는 명령 기록을 나중에 다시 사용할 수 있도록 .clixml 파일로 덤프합니다. Get-DiskUsage 스크립트로 디스크 사용 정보를 확인할 수 있으며 컴퓨터가 말을 하도록 할 수 있는 재미있는 Out-Speech 명령도 있습니다. 이외에도 패키지에는 명령줄 입력을 줄이는 Quote-List, 경로 집합을 지정된 환경에 추가할 수 있는 Add-PathVariable과 같은 다양한 기능이 포함되어 있습니다.
이 프로젝트는 표준 Windows PowerShell 환경에 매우 유용한 확장 기능 집합을 추가합니다. Windows PowerShell을 활용해야 하는 경우 이 프로젝트가 큰 도움이 될 것으로 확신합니다.

가격: 무료
많은 사용자가 요청한 기능을 제공하는 PowerShell Community Extensions
많은 사용자가 요청한 기능을 제공하는 PowerShell Community Extensions

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


 SQL Q&amp;A: 비클러스터형 인덱스 및 사용 권한 유지
SQL Q&A
비클러스터형 인덱스 및 사용 권한 유지
Saleem Hakani and Dan Carollo

비클러스터형 인덱스의 정의 및 사용법
Q: 비클러스터링 인덱스란 무엇이며 장점과 단점은 무엇입니까?
A: 비클러스터형 인덱스는 일반적으로 책의 뒷부분에 있는 색인과 비슷합니다. 책에 포함된 모든 정보가 색인에 주제별로 표시되며 책의 여러 부분에 있을 수 있는 관련 정보를 찾을 수 있도록 도와 주는 포인터가 페이지 번호 형식으로 기재됩니다. 또한 색인의 데이터는 책의 본문에 나타나는 순서와 동일한 순서로 나열되지 않습니다. 이 점이 비클러스터형 인덱스와 동일합니다. 테이블에 클러스터형 인덱스가 있는 경우에는 항목의 순서를 지정할 수 있습니다. 그렇지 않은 경우에는 순서를 확인할 방법이 없습니다.
비클러스터형 인덱스에는 두 가지 제한이 있습니다. 즉, 인덱스에는 16개의 열만 포함될 수 있으며 인덱스 키의 최대 크기는 900바이트를 초과할 수 없습니다. 이 사실은 무엇을 의미할까요? 샘플 MovieList 데이터베이스의 Movie 테이블에서 MovieTitle NVarchar(50), DirectorName NVarchar(50), ShortStory NVarchar(400) 열을 인덱싱하려고 할 때 어떤 작업이 수행되는지 살펴보겠습니다.
다음 문을 실행하여 테이블을 만든다고 가정하겠습니다.
Use MovieList;
CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName, ShortStory);
그러면 "경고! 최대 키 길이는 900바이트입니다. 인덱스 'Movie_IDX'의 최대 길이는 1000바이트입니다. 큰 값을 조합한 일부 경우에는 삽입/업데이트 작업을 수행할 수 없습니다."와 같은 오류 메시지가 나타납니다. "nvarchar" 데이터 형식은 각 문자에 대해 2바이트를 사용하므로 위의 세 열이 포함된 인덱스는 900바이트의 크기 제한을 초과합니다.
SQL Server® 2005가 출시된 지금은 INCLUDE 절에 열을 추가하는 방법으로 이 문제를 해결할 수 있습니다. 이것은 크기 제한과 열 제한을 모두 해결하려고 할 때 매우 유용한 기능입니다. 다음 문을 실행하면 제한을 해결할 수 있습니다.
CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName) INCLUDE (ShortStory);
인덱스 생성 도중 INCLUDE 절을 사용하면 데이터베이스 엔진에서 인덱스 키 열의 수 또는 인덱스 키 크기를 계산할 때 키가 아닌 열을 고려하지 않는다는 점을 유념하십시오.
비클러스터형 인덱스에 대한 자세한 내용을 보려면 "비클러스터형 인덱스"(msdn2.microsoft.com/aa174537)와 "비클러스터형 인덱스 사용"(msdn2.microsoft.com/aa933130)을 참조하십시오. 인덱스를 최적화하기 위한 팁에 대해서는 sql-server-performance.com/optimizing_indexes.asp를 참조하십시오.

사용 권한 데이터 보존
Q: 구독이 다시 초기화될 때 사용 권한이 손실되지 않도록 하려면 어떻게 해야 합니까? 저는 스냅숏이 다시 초기화될 때 부여된 사용 권한이 모두 손실되는 문제를 여러 번 경험했습니다.
A: 기본적으로 구독 데이터베이스의 모든 개체는 구독이 다시 초기화될 때마다 삭제되었다 다시 생성됩니다. 하지만 두 가지 방법으로 이 문제를 해결할 수 있습니다.
첫 번째로, 다시 초기화한 후 모든 사용 권한을 다시 적용할 수 있습니다. 사용 권한을 수동으로 설정할 때는 구독을 다시 초기화한 후 즉시 이를 사용할 수 있도록 개체/명령문 수준의 모든 사용 권한을 스크립트로 만들어 따로 저장하십시오.
두 번째로, 구독을 다시 초기화할 때마다 개체를 삭제하지 않도록 구독을 구성합니다. 이렇게 하려면 SP_CHANGEARTICLE 시스템 저장 프로시저를 사용하여 매개 변수 @PROPERTY에 대한 PRE_CREATION_CMD의 값과 매개 변수 @Value에 대한 NONE, DELETE 또는 TRUNCATE의 값을 구성할 수 있습니다.
또한 대상 개체 섹션의 아티클 속성 대화 상자에서 "기존 개체를 변경하지 않고 유지, 데이터를 삭제합니다. 아티클에 행 필터가 있으면 필터에 대응하는 데이터만 삭제합니다. 기존 개체의 모든 데이터를 잘라냅니다." 값을 선택합니다. 이 작업은 테스트 환경에서 수행해야 하며 도움이 필요한 경우 최신 버전의 SQL Server 온라인 설명서에서 최신 정보를 확인하십시오.

Saleem Hakani는 14년 이상의 데이터베이스 시스템 경력을 지닌 수석 데이터베이스 엔지니어 겸 선임 문제 해결 엔지니어이자 국제 Microsoft SQL Server 커뮤니티 운영자입니다. 현재 외부 SQL Server 커뮤니티 웹 사이트인 sqlcommunity.com을 운영하고 있으며 Saleem@sqlcommunity.com으로 연락할 수 있습니다.
Dan Carollo는 Microsoft의 Windows 맬웨어 방지 연구 및 대응 팀에서 근무하는 운영 엔지니어 겸 SQL Server DBA로 SQL Server MCT 자격증을 보유하고 있습니다.


 Utility Spotlight: ADMX Migrator
Utility Spotlight
ADMX Migrator
Lance Whitney
이 기사의 코드 다운로드: ADMX Migrator (2765KB)

그룹 정책 사용자라면 관리 템플릿을 사용하여 운영 체제와 응용 프로그램 설정을 구성하는 방법을 잘 알고 있을 것입니다. Windows®에 포함된 ADM 파일과 Microsoft® Office와 같은 주요 소프트웨어를 사용하면 대부분의 일반적인 데스크톱 구성을 처리할 수 있습니다. 하지만 사용자 지정 설정을 통합하기 위해 ADM 템플릿을 직접 만들어야 할 때도 있습니다. ADM을 처음부터 다시 설계하는 것은 번거로운 작업이 될 수 있습니다. 자체 고유 구문을 사용해야 하고 텍스트 편집기를 사용하여 작성해야 하기 때문입니다. 하지만 시간과 노력을 투자하여 ADM 파일 작성에 상당히 능숙해진 그룹 정책 전문가들도 많이 있습니다.
Windows Vista®에서 Microsoft는 그룹 정책 템플릿의 형식을 XML 기반 구조로 변경했습니다. ADMX라고 하는 이 새로운 형식에는 다국어 지원, 모든 템플릿을 관리할 수 있는 중앙 저장소 등 기존 레거시 ADM 파일에 비해 몇 가지 장점이 있습니다.
이러한 장점도 있지만 ADMX 파일을 직접 만들어야 하는데 XML에 익숙하지 않다면 어떻게 해야 할까요? 게다가 몇 년 동안 노력하여 만든 사용자 지정 ADM은 어떻게 될까요? 다행히도 ADMX Migrator 유틸리티를 사용한다면 이러한 문제를 해결할 수 있습니다. FullArmor Corporation에서 개발하여 Microsoft가 사용권을 획득한 이 무료 도구의 두 가지 주요 이점은 사용자 지정 ADMX 파일을 만들고 레거시 ADM 파일을 ADMX로 변환하는 기능입니다.
ADMX Migrator 그래픽 인터페이스
ADMX Migrator 그래픽 인터페이스
새 형식의 템플릿을 만들기 위해 ADMX Migrator에서는 그래픽 사용자 인터페이스를 지원하는 ADMX Editor를 제공합니다. 따라서 다른 텍스트 편집기가 필요하지 않습니다. 깔끔하고 단순한 인터페이스에서 드롭다운 메뉴와 목록을 사용하여 템플릿을 만듭니다(그림 참조). 시작하려면 먼저 New Template(새 템플릿) 명령을 선택하고 템플릿 파일 이름을 지정한 다음 파일을 분류할 범주를 입력합니다. 그런 다음 정책을 적용할 레지스트리 키, 레지스트리 값 이름, 대상 클래스(사용자, 시스템 또는 둘 모두)를 입력하여 실제 정책 설정을 만듭니다. 정책의 역할을 설명할 수도 있습니다.
작업이 끝나면 새 템플릿을 ADMX 형식으로 저장합니다. 새 템플릿은 ADMX 파일과 ADML 파일로 저장됩니다. ADMX 파일에는 실제 정책 설정이 저장되고 ADML 파일에는 정책에 대한 언어 관련 정보가 포함됩니다. 이제 두 파일을 도메인의 적절한 디렉터리로 복사하고 그룹 정책에 통합할 수 있습니다.
ADM 파일을 ADMX로 변환하여 새로운 형식의 이점을 활용할 수도 있습니다. ADMX Migrator에서는 편집기를 사용하는 방법과 명령줄 프로그램을 사용하는 방법의 두 가지 변환 방법을 제공합니다. ADMX Editor에서, ADM에서 ADMX를 생성하는 옵션을 선택합니다. ADM 파일을 찾아서 선택하면 해당 파일이 자동으로 신속하게 변환됩니다. 그런 다음 변환된 파일을 편집기에서 열고 값과 속성을 확인한 다음 필요한 경우 이를 수정합니다. ADMX Migrator 명령 창은 약간 더 복잡합니다. 이 창에서 변환을 수행하려면 명령 프롬프트에 긴 명령 문자열을 입력해야 합니다. 하지만 그래픽 편집기에서는 사용할 수 없는 몇 가지 옵션이 있고 유연성도 더 높습니다.
ADMX Migrator는 MMC(Microsoft Management Console) 스냅인이기 때문에 Microsoft .NET Framework 2.0과 MMC 3.0이 있어야 사용할 수 있습니다. ADMX Migrator는 Windows XP SP2, Windows Server® 2003 SP1 및 Windows Vista에서 실행됩니다. 이 소프트웨어는 go.microsoft.com/fwlink/?LinkId=77409에서 다운로드할 수 있습니다.

Lance Whitney는 IT 컨설턴트 겸 강사이자 테크니컬 라이터로, Windows 워크스테이션과 서버를 조정하는 데 많은 시간을 할애하고 있습니다. 원래 저널리스트였던 그는 15년 전 IT 업계에 뛰어들었습니다.


 The Cable Guy: IEEE 802.1X 유선 인증
The Cable Guy
IEEE 802.1X 유선 인증
Joseph Davies
이 문서는 Windows Server 2008의 시험판 버전을 기준으로 작성되었습니다. 이 문서에 수록된 모든 정보는 변경될 수 있습니다.

IEEE 802.11 무선 네트워크에 IEEE 802.1X 인증이 널리 사용되면서 네트워크 관리자들이 자신의 유선 네트워크 연결에도 이 표준 인증 방식을 사용하기를 원하게 되었습니다. 무선 클라이언트가 인트라넷에 무선 프레임을 전달하기 위해서는 자격 증명 집합을 전송하여 인증을 받아야 하는 것과 같이
IEEE 802.1X 유선 클라이언트도 스위치 포트를 사용하기 위해서는 먼저 인증을 수행해야 합니다. IEEE 802.1X 인증은 인트라넷에 추가적인 보안 장벽을 제공합니다. 따라서 인증에 실패한 게스트 컴퓨터, 악의적인 컴퓨터 또는 관리되지 않는 컴퓨터가 인트라넷에 연결하지 못하도록 차단할 수 있습니다.
대개 유선 스위치에서 이미 IEEE 802.1X 인증을 지원하므로 사용하도록 설정하고 구성하기만 하면 됩니다. 일반적으로 802.1X 지원 스위치는 유선 연결의 인증과 권한 부여를 위해 RADIUS(Remote Authentication Dial-In User Service) 프로토콜을 사용하여 Windows Server® 2008 기반 NPS(네트워크 정책 서버)나 Windows Server 2003 IAS(Internet Authentication Service) 서버 같은 RADIUS 서버에 연결 요청 정보를 보냅니다.
RADIUS에 사용할 스위치를 구성한 후 802.1X 인증을 사용하려면 먼저 유선으로 연결된 컴퓨터에서 802.1X 인증을 사용하도록 설정하고 구성해야 합니다. 유선 네트워크 연결에 대한 IEEE 802.1X 인증은 Windows XP부터 Microsoft® Windows®에서 지원되어 왔습니다. 그러나 Windows XP 및 Windows Server 2003을 실행하는 개별 유선 클라이언트에서는 네트워크 연결 폴더의 네트워크 연결 속성에 대한 인증 탭을 사용하여 802.1X 인증 설정을 수동으로 구성해야 합니다. 아쉽게도 이러한 이전 운영 체제의 경우에는 유선 802.1X 설정을 중앙 집중식으로 구성하거나 스크립트하는 방법이 없습니다.
그러나 Windows Vista®와 Windows Server 2008에서 그룹 정책에서 유선 설정이 지원되고 Netsh 도구를 사용한 스크립팅이 지원되면서 802.1X 유선 설정을 훨씬 간편하게 배포할 수 있게 되었습니다.

그룹 정책의 유선 네트워크 설정
유선 자동 구성 서비스 사용
Windows XP와 Windows Server 2003에서 유선 연결의 802.1X 동작은 Wireless Zero Configuration 서비스에 의해 제어됩니다. 이러한 운영 체제에서 이 서비스는 기본적으로 사용하도록 설정되어 있으며 유선 네트워크 연결은 인증을 시작하는 스위치를 기다리며 수동 수신 모드로 설정되어 있습니다.
반면 Windows Vista와 Windows Server 2008의 경우 유선 자동 구성 서비스가 유선 연결의 802.1X 동작을 제어하지만 기본적으로 사용하지 않도록 설정됩니다. 따라서 유선 자동 구성 서비스를 시작하지 않으면 네트워크 연결 속성의 인증 탭이 표시되지 않습니다.
서비스 스냅인을 사용하면 Windows Vista 또는 Windows Server 2008을 실행하는 개별 유선 클라이언트별로 유선 자동 구성 서비스를 시작하고 서비스가 자동으로 시작되도록 구성할 수 있습니다. 유선 자동 구성 서비스가 시작된 후에는 유선 네트워크 연결이 활성 수신 모드에서 작동합니다. 이 모드에서는 네트워크 연결이 스위치와 함께 인증을 시도합니다.
Active Directory 도메인의 경우 그룹 정책을 사용하여 유선 자동 구성 서비스가 자동으로 시작되도록 구성할 수 있습니다. 그룹 정책 관리 편집기 스냅인을 사용하여 컴퓨터 구성 | Windows 설정 | 보안 설정 | 시스템 서비스 | 유선 자동 구성 설정에서 자동 시작 모드를 구성합니다.

Windows Server 2008 및 Windows Server 2003 Active Directory® 도메인 서비스는 그룹 정책을 통한 유선 정책 설정을 지원하므로 유선 네트워크 설정을 자동화하고 중앙에서 구성할 수 있습니다. 이러한 유선 정책 설정을 통해 도메인 기반 그룹 정책 개체에 대한 컴퓨터 구성 그룹 정책의 일부로 유선 네트워크 설정을 구성할 수 있습니다.
이러한 유선 정책 설정에서는 Windows Server 2008 또는 Windows Vista를 실행하는 유선 클라이언트의 인증 방법과 기타 802.1X 설정을 지정할 수 있습니다. 이 두 운영 체제는 도메인에 참가할 때, 시작 시 또는 시작 후 주기적으로 자동으로 유선 그룹 정책 설정을 다운로드하여 적용합니다. 단 이러한 새 정책을 지원하려면 Windows Server 2003 Active Directory 도메인을 확장해야 합니다. Windows Server 2003 Active Directory 도메인을 확장하는 방법에 대한 자세한 내용은 technet.microsoft.com/bb727029를 참조하십시오.
유선 정책은 그룹 정책 관리 편집기 스냅인의 컴퓨터 구성 | Windows 설정 | 보안 설정 | 유선 네트워크(IEEE 802.3) 정책 노드에서 구성할 수 있습니다. 기본적으로는 유선 네트워크(IEEE 802.3) 정책이 없으므로 콘솔 트리에서 무선 네트워크(IEEE 802.3) 정책을 마우스 오른쪽 단추로 클릭하고 새 Windows Vista 정책 만들기를 클릭하여 새 정책을 만들어야 합니다.
Windows Vista 유선 정책의 속성 대화 상자는 일반 탭과 보안 탭으로 구성되어 있습니다. 그림 1에는 기본 일반 탭이 나와 있습니다. 일반 탭에서는 정책의 이름과 설명을 구성하고 유선 연결의 802.1X 동작을 제어하는 유선 자동 구성 서비스 사용 여부를 지정할 수 있습니다. 자세한 내용은 이 칼럼의 "유선 자동 구성 서비스 사용" 추가 기사를 참조하십시오.
그림 1 Windows Vista 유선 정책의 기본 일반 탭
그림 1 Windows Vista 유선 정책의 기본 일반 탭
그림 2에는 Windows Vista 유선 정책의 기본 보안 탭이 나와 있습니다. 보안 탭에서는 802.1X 인증을 사용하거나 사용하지 않도록 설정하고 EAP(확장할 수 있는 인증 프로토콜) 인증 방법을 선택 및 구성하고 인증 모드(사용자 재인증, 컴퓨터 인증, 사용자 인증 또는 게스트 인증)를 선택하고 인증을 중단하기까지 허용되는 인증 시도 횟수와 이후 연결을 위해 사용자 정보를 캐시할지 여부를 구성할 수 있습니다. 캐싱하지 않도록 설정하면 사용자가 로그오프할 때 Windows 레지스트리에서 사용자 자격 증명 데이터가 제거됩니다. 따라서 다음에 사용자가 로그온할 때 사용자 이름 및 암호와 같은 자격 증명을 묻는 메시지가 표시됩니다.
그림 2 Windows Vista 유선 정책의 기본 보안 탭
그림 2 Windows Vista 유선 정책의 기본 보안 탭
보안 탭에서 고급 단추를 클릭하면 802.1X와 Single Sign-On의 고급 설정을 구성할 수 있습니다. 그림 3에는 Windows Vista 유선 정책의 기본 고급 보안 설정 대화 상자가 나와 있습니다. 고급 보안 설정 대화 상자에서는 그림 4와 같은 802.1X 설정을 구성할 수 있습니다.
Figure 4 고급 보안 설정 대화 상자의 802.1X 설정 (Close Figure 4)

설정 | 설명
최대 EAPOL 시작 메시지 수 | 초기 EAPOL 시작 메시지에 대한 응답이 수신되지 않았을 때 전송될 연속적인 EAPOL(EAP over LAN) 시작 메시지의 수입니다.
대기 기간 | 이전에 전송한 EAPOL 시작 메시지에 대한 응답이 수신되지 않을 때 EAPOL 시작 메시지를 재전송하는 시간 간격입니다.
시작 기간 | 인증자로부터 인증 실패 알림을 수신한 후 인증을 받는 클라이언트에서 802.1X 인증 작업을 수행하지 않고 대기하는 기간입니다.
인증 기간 | 종단 간 802.1X 인증이 시작된 후 802.1X 요청을 재전송하기 전에 인증 클라이언트가 대기하는 기간입니다.
EAPOL 시작 메시지 | 유선 클라이언트에서 EAPOL 시작 메시지를 전송하는 시점입니다.
그림 3 Windows Vista 유선 정책의 기본 고급 보안 설정 대화 상자
그림 3 Windows Vista 유선 정책의 기본 고급 보안 설정 대화 상자
Windows Server 2008을 실행하는 유선 클라이언트는 유선 연결에 대해 Single Sign-On을 지원합니다. 이 기능은 앞으로 발표될 Windows Vista 서비스 팩 1에도 포함될 예정입니다. 자세한 내용은 온라인 문서 technetmagazine.com/issues/2007/11/CableGuy를 참조하십시오.
Single Sign-On 설정을 통해 사용자 로그온 프로세스 실행 전 또는 실행 후에 사용자 수준 802.1X 인증을 수행하거나, 일정 시간(초) 동안 사용자 수준 802.1X 인증이 완료될 때까지 기다린 후 사용자 로그온 프로세스를 시작하도록 구성할 수 있습니다. Windows 로그온 화면에 통합된 입력 필드 외에 사용자 수준 인증에 대하여 대화 상자를 별도로 표시할지 여부를 결정할 수 있습니다. 예를 들어 EAP 유형이 인증 과정에서 RADIUS 서버로부터 전송된 인증서를 사용자가 확인하도록 요구할 경우 EAP 유형은 해당 대화 상자를 표시할 수 있습니다.
또한 사용자 수준 인증을 수행한 이후 시스템이 유선 어댑터의 TCP/IP 구성에 대한 DHCP(동적 호스트 구성 프로토콜) 갱신을 시작하도록 지정할 수도 있습니다. 컴퓨터 수준 인증 및 사용자 수준 인증 유선 클라이언트에 대해 각기 별도의 VLAN(가상 LAN)이 있고 그 VLAN들이 서로 다른 IPv4 또는 IPv6 서브넷일 경우에 이 옵션을 선택하십시오.

Netsh 도구를 사용한 스크립팅 지원
Windows Server 2008과 Windows Vista는 유선 설정을 구성하거나, XML 형식의 명명된 유선 설정 집합인 유선 프로필을 내보내거나 가져올 수 있도록 Netsh 도구의 netsh lan 컨텍스트에서 명령을 지원합니다. 명령줄에서 유선 설정을 구성하는 기능을 사용하면 그룹 정책을 사용하지 않고도 자동화된 유선 설정 스크립트를 작성하여 유선 네트워크를 간편하게 배포할 수 있습니다. 유선 네트워크(IEEE 802.3) 정책 그룹 정책 설정은 Active Directory 도메인에서만 적용됩니다. 그룹 정책 인프라가 구축되지 않은 환경의 경우 유선 프로필을 사용하여 유선 연결 구성을 자동화하는 스크립트를 수동 또는 자동으로 실행하는 것은 물론, 로그온 스크립트의 일부로 포함할 수도 있습니다.
Windows Vista 또는 Windows Server 2008을 실행하는 유선 클라이언트를 명령줄에서 구성하려면 적절한 매개 변수를 사용하여 netsh lan 명령을 실행합니다. 예를 들어 다음은 "Local Area Connection"이라는 네트워크 연결에 대해 Single Sign-On을 사용하도록 설정하고 사용자 로그온 전 사용자 인증을 수행하도록 Single Sign-On을 구성하는 명령입니다.
netsh lan set profileparameter interface="Local Area Connection" ssomode=prelogon
netsh lan 명령 구문에 대한 자세한 내용은 technet.microsoft.com/aa905084를 참조하십시오.
Netsh 도구를 사용하면 Windows Server 2008 또는 Windows Vista 유선 클라이언트에서 유선 XML 프로필을 내보낸 후 Windows Server 2008 또는 Windows Vista 유선 클라이언트로 가져올 수 있습니다. 유선 프로필을 내보내려면 netsh lan export profile 명령을 사용하고 유선 프로필을 가져오려면 netsh lan add profile 명령을 사용합니다. 유용한 유선 프로필 예제는 msdn2.microsoft.com/aa816372를 참조하십시오.
명령줄과 XML 프로필 지원 기능을 사용하면 유선 클라이언트를 조직의 802.1X 인증 유선 네트워크에 부트스트랩할 수 있습니다. 도메인의 구성원이 아닌 유선 클라이언트 컴퓨터는 컴퓨터 자격 증명을 사용하여 유선 네트워크에 연결할 수 없습니다. 또한 유선 네트워크에 성공적으로 연결될 때까지 컴퓨터가 도메인에 참가할 수 없습니다. 그러나 명령줄과 XML 프로필 지원을 이용하면 유선 컴퓨터에서 사용자 자격 증명을 사용하여 조직의 유선 네트워크에 연결한 후 도메인에 참가할 수 있습니다. 자세한 내용은 technet.microsoft.com/bb727031을 참조하십시오.

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


 Windows PowerShell: 셸 사용 권한
Windows PowerShell
셸 사용 권한
Don Jones
이 기사의 코드 다운로드: PowerShell2008_02.exe (151KB)

Windows PowerShell에 대해 이야기하다 보면 사용 권한에 대해, 특히 셸을 통해 사용 권한 변경을 자동화할 수 있는지 여부와 그 방법에 대한 질문을 자주 받습니다. 파일 사용 권한에 대한 질문이 가장 많고 디렉터리와 레지스트리 사용 권한에 대한 질문도 꽤 많습니다. 사용 권한 그리고 거의 모든
명령줄 또는 스크립팅 인터페이스(Windows PowerShellTM과 VBScript 포함)에 대해 제가 드릴 수 있는 이야기에는 긍정적인 점도 있고 부정적인 점도 있습니다.
부정적인 점은 Windows®의 사용 권한은 태생적으로 복잡하며 Windows PowerShell에서 이를 해결할 수 있는 부분이 많지 않다는 점입니다. Windows 운영 체제에는 파일 시스템, Active Directory®, 레지스트리 및 거의 모든 부분에 사용 권한과 관련된 여러 개의 개체가 있다는 점에서 문제가 시작됩니다.
우선 디렉터리 개체, 파일 또는 폴더와 같은 리소스가 있습니다. 다음으로는 리소스에 연결되는 ACL(액세스 제어 목록) 개체가 있습니다. ACL은 하나 이상의 ACE(액세스 제어 항목) 개체로 구성됩니다. ACE는 기본적으로 보안 주체(또 다른 개체인 사용자 또는 그룹)를 사용 권한(예: 읽기 또는 모든 권한) 및 허용 또는 거부 상태와 연결합니다. 따라서 리소스, ACL, ACE, 주체 및 사용 권한 등 다섯 개의 개체가 있는 셈입니다.
또한 리소스 유형마다 사용 권한 유형이 다르다는 점 때문에 사용 권한은 더욱 복잡해집니다. 예를 들어 디렉터리 개체에는 개별 개체 특성에 대한 액세스를 제어하는 복잡한 사용 권한이 있습니다. 이에 비하면 파일 사용 권한은 비교적 덜 복잡합니다.
또한 기술적으로 볼 때 감사의 측면에서는 이러한 복잡함이 배가됩니다. 실제로 각 리소스에는 두 개의 ACL이 있습니다. 우선 리소스에 대한 액세스를 제어하는 DACL(임의 ACL)이 있습니다. 그리고 리소스에 대한 감사를 제어하는 SACL(보안 ACL)도 있습니다. 이러한 사용 권한을 다루려면 꽤 복잡해 보이는 여러 프로그래밍 개체를 다뤄야 하며 이 작업을 단순화할 수 있는 방법은 Windows PowerShell과 같은 셸을 이용하는 방법뿐입니다.

.NET Framework에 의한 제한
추가 정보
검색 가능한 cmdlet 라이브러리를 포함하여 Windows PowerShell에 대한 추가적인 리소스를 보고 Don Jones 및 다른 Windows PowerShell 전문가의 의견을 들어 보려면 www.PowerShellCommunity.org를 방문하십시오.

Windows PowerShell의 특성 때문에 상황은 조금 더 복잡해집니다. Microsoft® .NET Framework를 기반으로 하는 Windows PowerShell에서는 .NET Framework의 기본 클래스를 사용하여 사용 권한을 나타내고 관련 작업을 처리합니다. 이러한 기본 .NET Framework 클래스는 소프트웨어 개발자에게 세밀하고 정확한 사용 권한 제어 기능을 제공하도록 설계되었습니다. 물론 "세밀하고 정확한"이라는 말은 정보가 매우 많다는 것을 의미하며 "매우 복잡하다"는 의미가 되기도 합니다.
또한 .NET Framework에서 모든 Windows 리소스 유형의 사용 권한을 나타내는 클래스를 제공하는 것은 아닙니다. 예를 들어 .NET Framework에서는 파일 보안을 조작할 수 있는 클래스를 제공하지만 공유 폴더의 보안을 다룰 수 있는 클래스는 제공하지 않습니다. 따라서 Windows 리소스 유형의 사용 권한 중에는 Windows PowerShell에서 조작할 수 없는 것이 있습니다. 요약하자면 Windows PowerShell의 기능은 .NET Framework에서 제공하는 기능으로 제한됩니다.

셸의 사용 권한
Windows PowerShell에서의 사용 권한 관리는 Get-ACL 및 Set-ACL의 두 cmdlet에서 파생됩니다. Get-ACL은 리소스에서 ACL을 가져옵니다. 그런 다음에는 필요에 따라 ACL을 수정하고 Set-ACL을 사용하여 이를 다시 리소스에 쓸 수 있습니다. 두 cmdlet 모두 제네릭이며 PSDrive 공급자의 Windows PowerShell 시스템에 의존합니다. 따라서 해당 리소스 유형을 인식할 수 있고 해당 리소스 유형의 사용 권한을 수정할 수 있는 PSDrive 공급자가 있으면 이 두 ACL cmdlet은 이론적으로 모든 리소스 유형을 다룰 수 있습니다. Windows PowerShell에 포함된 FileSystem 및 Registry PSDrive 공급자는 두 ACL cmdlet을 통한 사용 권한 관리를 지원합니다. 다른 PSDrive 공급자는 이를 지원하지 않을 수 있습니다.
그림 1의 샘플 스크립트를 사용하여 시작 디렉터리, 보안 주체 및 사용 권한을 지정할 수 있습니다. 그런 다음 스크립트는 해당 주체에 대해 지정된 사용 권한을 지정된 디렉터리 내의 모든 파일과 폴더에 적용합니다. 스크립트는 하위 디렉터리에서도 같은 작업을 반복합니다.
Figure 1 디렉터리의 파일 및 폴더에 주체에 대한 사용 권한 적용 (Close Figure 1)
#ChangeACL.ps1
$Right="FullControl"

#The possible values for Rights are
# ListDirectory, ReadData, WriteData
# CreateFiles, CreateDirectories, AppendData
# ReadExtendedAttributes, WriteExtendedAttributes, Traverse
# ExecuteFile, DeleteSubdirectoriesAndFiles, ReadAttributes
# WriteAttributes, Write, Delete
# ReadPermissions, Read, ReadAndExecute
# Modify, ChangePermissions, TakeOwnership
# Synchronize, FullControl

$StartingDir=Read-Host "What directory do you want to start at?"
$Principal=Read-Host "What security principal do you want to grant" `
"$Right to? `n Use format domain\username or domain\group"

#define a new access rule.
#note that the $rule line has been artificially broken for print purposes.
#it needs to be one line. the online version of the script is properly
#formatted.
$rule=new-object System.Security.AccessControl.FileSystemAccessRule
($Principal,$Right,"Allow")

foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
  $acl=get-acl $file.FullName

  #Add this access rule to the ACL
  $acl.SetAccessRule($rule)

  #Write the changes to the object
  set-acl $File.Fullname $acl
  }
이 스크립트의 핵심은 변수 $rule에 새 액세스 규칙을 정의하는 데 있습니다. 이렇게 하기 위해 필자는 Windows PowerShell에서의 사용 권한 관리 중 가장 복잡한 부분 중 하나인 "원시" .NET Framework 클래스를 사용합니다. 그런 후 스크립트는 Get-ACL을 사용하여 각 파일과 폴더에서 차례로 ACL을 가져오고, ACL의 SetAccessRule 메서드를 사용하여 새 규칙을 적용하고, Set-ACL을 사용하여 수정된 ACL을 다시 리소스에 씁니다.
ACL에서 ACE를 제거하는 등의 더 복잡한 작업이 더 필요하기는 하지만 이 부분은 실제로 그렇게 복잡하지 않습니다. 필자 생각으로는 ACL을 가져오고, 규칙을 정의하고, ACL을 수정하고, ACL을 쓰는 등의 많은 단계가 수반된다는 점 때문에 복잡해 보이는 것 같습니다. 하나의 명령으로 한 번에 모든 작업을 깔끔하게 처리할 수는 없지요. 또한 여러 파일의 ACL을 수정하려고 하기 때문에 모든 파일과 폴더에 실제로 액세스하기 위한 Get-ChildItem을 사용하여 모든 단계를 foreach 루프에 래핑해야 했습니다.

가장 쉬운 방법
이달의 Cmdlet: Get-QADUser
Active Directory를 관리한다면 이 cmdlet이 반드시 필요합니다. 이 cmdlet은 Windows PowerShell에서 기본적으로 제공되지는 않지만 무료로 다운로드할 수 있는 Quest Software의 ActiveRoles Management Shell for Active Directory에 포함되어 있습니다(www.quest.com/activeroles-server/arms.aspx).
스냅인을 설치한 뒤에는 Get-QADUser를 사용하여 디렉터리에서 사용자 개체를 가져올 수 있습니다. 물론 cmdlet을 실행하기만 하면 모든 사용자가 반환되지만 이 기능은 대부분의 관리 작업에서 그다지 쓸모가 없습니다. 하지만 이 cmdlet을 사용할 때 필터링 조건을 지정할 수 있습니다. 이 조건은 도메인 컨트롤러에 적용되어 실제로 원하는 사용자만 Windows PowerShell에 반환되도록 합니다. 먼저 모든 사용자를 가져온 다음 이를 Where-Object cmdlet으로 필터링하는 방법보다 훨씬 빠른 방법입니다. 예를 들어 Get-QADUser -l Redmond를 지정하면 "l" 특성에 "Redmond"가 포함된 사용자만 반환됩니다. 여기서 "l" 특성은 위치(locality)를 의미하며 GUI에서 도시로 나열됩니다. 이렇게 한 다음 이 사용자들을 다른 cmdlet으로 파이핑하여 HTML 보고서를 생성하거나, 그룹에 배치하거나, 삭제할 수 있습니다.

필자는 이 예제가 복잡하지 않다고 생각하지만 대다수 관리자는 더 간단하게 사용 권한을 다룰 수 있는 방법을 선호한다는 점을 알고 있습니다. 아마도 폴더 집합에서 특정 사용자 그룹을 한 번에 제거하고 싶지만 그림 1에 보이는 다단계 스크립트를 작성하고 싶지 않을 것입니다.
다행히 Windows PowerShell에서는 사용 권한을 다룰 수 있는 좀 더 간단한 방법을 제공하며 이 방법에 이미 익숙한 사람도 많을 것입니다.
Windows PowerShell을 이용하면 시행 착오 때문에 지쳐서 포기할 일은 없습니다. 다양한 유형의 사용 권한을 더 간단하게 다루기 위한 방법을 제공하기 위해 설계된 Dsacls.exe, Cacls.exe 및 Xcacls.exe와 같은 명령줄 도구를 사용할 수 있습니다. 이러한 명령줄 유틸리티는 구문이 Windows PowerShell cmdlet에서 사용되는 표준화된 구문과 완전히 다르지만 더 이상 이전 cmd.exe 셸에서 사용할 때처럼 명령줄에서 특별한 방식으로 사용할 필요가 없습니다. 또한 Windows PowerShell을 사용하여 이들 유틸리티를 자동화할 수 있습니다.
Windows PowerShell 내에서 구식의 명령줄 유틸리티를 사용하는 것은 잘못되었다고 주장하는 사람들이 있습니다. 필자는 이들을 "순수주의자"라고 부르겠습니다. 필자는 이런 논리에 그다지 동의하지 않습니다. 필자에게는 원하는 작업을 수행하는 것이 중요하며 이를 할 수 있는 가장 쉬운 방법이 10년 된 명령줄 유틸리티를 사용하는 것이라면 기꺼이 사용하겠습니다. "더 순수"한 것처럼 보인다는 이유만으로 특정한 방법으로 작업하기 위해 시간을 더 투자하고 싶지는 않습니다. Microsoft Windows PowerShell 팀도 이와 비슷한 태도를 취합니다. 기존 도구가 작업에 적합하다면 Windows PowerShell의 셸 안에서 해당 도구를 사용할 수 있습니다. 이미 있는 도구를 활용하지 않을 이유가 없기 때문입니다.
그림 2의 스크립트는 필자의 책인 Windows PowerShell: TFM(SAPIEN Press, 2006)에서 발췌한 것으로 Windows PowerShell을 사용하여 Cacls.exe를 자동화합니다. 이 스크립트는 설명을 위해 보여 드리는 것이며, 실제 자동화 도구에 이용하려면 적절하게 조정을 해야 합니다. 하지만 이 스크립트는 Windows PowerShell 스크립트로 정보를 수집하고 이 정보를 사용하여 Cacls.exe를 "네이티브" Windows PowerShell 명령처럼 시작하는 방법을 보여 줍니다. 이 스크립트에서는 사용자에게 요청하여 정보를 수집하지만 파일이나 데이터베이스에서 매개 변수를 읽을 수도 있습니다.
Figure 2 Cacls.exe 자동화 (Close Figure 2)
#SetPermsWithCACLS.ps1
# CACLS rights are usually
# F = FullControl
# C = Change
# R = Readonly
# W = Write

$StartingDir=Read-Host "What directory do you want to start at?"
$Right=Read-Host "What CACLS right do you want to grant? Valid choices are F, C, R or W"
Switch ($Right) {
  "F" {$Null}
  "C" {$Null}
  "R" {$Null}
  "W" {$Null}
  default {
    Write-Host -foregroundcolor "Red" `
    `n $Right.ToUpper() " is an invalid choice. Please Try again."`n
    exit
  }
}

$Principal=Read-Host "What security principal do you want to grant?" `
"CACLS right"$Right.ToUpper()"to?" `n `
"Use format domain\username or domain\group"

$Verify=Read-Host `n "You are about to change permissions on all" `
"files starting at"$StartingDir.ToUpper() `n "for security"`
"principal"$Principal.ToUpper() `
"with new right of"$Right.ToUpper()"."`n `
"Do you want to continue? [Y,N]"

if ($Verify -eq "Y") {

 foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
  #display filename and old permissions
  write-Host -foregroundcolor Yellow $file.FullName
  #uncomment if you want to see old permissions
  #CACLS $file.FullName

  #ADD new permission with CACLS
  CACLS $file.FullName /E /P "${Principal}:${Right}" >$NULL

  #display new permissions
  Write-Host -foregroundcolor Green "New Permissions"
  CACLS $file.FullName
 }
}

성공적인 사용 권한 다루기
Windows PowerShell에서는 단순한 범용 사용 권한 관리 기능을 제공하는 네이티브 cmdlet을 제공하지 못하기 때문에 한계가 있다는 의견을 들은 적이 있습니다. 필자는 여기에 동의하지 않습니다. 우선 이것은 강력한 UNIX 환경을 사용하는 관리자의 의견인 경우가 많으며, Windows 사용 권한 시스템은 실제로 UNIX에서 사용하는 것보다 훨씬 복잡하다는 점 때문입니다. 이러한 시스템에서는 Windows PowerShell도 복잡해집니다. 하지만 이것은 Windows PowerShell의 문제가 아닙니다.
또한 Windows PowerShell에서는 앞서 언급한 것처럼 오래되었지만 우수한 명령줄 유틸리티의 형식으로 단순화된 도구를 사용할 수 있습니다. 물론 전체 Windows 플랫폼의 사용 권한 관리를 보다 완벽하게 처리하려면 .NET Framework에 어느 정도의 확장이 필요한 것도 사실입니다. 하지만 전체적으로 보면 Windows PowerShell은 단순화된 사용 권한 관리 기능과 세밀하고 정밀한 관리 도구를 모두 제공합니다.

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


 Hey, Scripting Guy!: 2008 Scripting Games 소식과 XML 정보!
Hey, Scripting Guy!
2008 Scripting Games 소식과 XML 정보!
Scripting Guys
이 기사의 코드 다운로드: HeyScriptingGuy2008_02.exe (151KB)

사람들이 스포츠계의 전설에 대해 이야기할 때는 항상 등장하는 몇몇 이름들이 있죠. 예를 들어 베이브 루스, 펠레, 무하마드 알리, 월터 페이튼, 스쿠터케이, 미스터랫, 조니 등...
아니 잠깐, 스쿠터케이(ScooterK)와 미스터랫(MrRat)이 누구냐고요? 설마, 농담이시죠? Winter Scripting Games(2월 15일부터 3월 3일까지 TechNet Script Center에서 개최, microsoft.com/technet/scriptcenter/funzone/games 참조)의 최신 소식을 놓친 분들께 알려드리지요. ScooterK와 MrRat은 2007 Winter Scripting Games에 참가하여 한 개 이상의 부문에서 만점을 기록한 진정한 전설입니다.
진짜 신나는 것은 바로 이거에요. 여러분은 펠레같이 전설적인 축구 선수가 될 수 있다고 생각하십니까? 아마도 힘들겠죠? 그러면 헤비급 세계 권투 챔피언은 어떨까요? 저희 Scripting Guys 중 몇명은 실제로 헤비급에 해당되기는 하지만, 권투 챔피언이 되기는 영 힘들 것 같네요. 그렇지만, 여러분은 ScooterK나 MrRat처럼 또 다른 전설이 될 수는 있습니다.
물론 뭐, 이론적으로는 여러분이 차세대 베이브 루스가 되지 말라는 법은 없겠죠. 다만, 하루 두 번 하는 경기 중간에 24개의 핫도그를 먹을 수 있다면 말입니다.
네네, 진정하시고요. 지금부터 ScooterK나 MrRat, 심지어 Bizzy나 H2Data와 같은 고수가 되는 방법을 알려드리겠습니다. 뭐 복잡한 것은 아니고, Script Center로 와서 Scripting Games에 참가하시면 됩니다. 2월 15일 저희는 10가지 이벤트(10개 스크립팅 과제)를 발표하고 여러분이 이중 하나라도, 아니면 혹시 전부 완수할 수 있는지 볼 것입니다. 주어진 문제를 해결하는 스크립트를 작성하여 전자 메일로 Scripting Guys에게 보내시면 됩니다. (자세한 내용은 Scripting Games 홈 페이지를 참조하십시오.) 그러면 저희는 여러분의 스크립트를 테스트하고 제대로 작동하면 점수를 드립니다. 10개 이벤트 모두를 성공적으로 완수해낸다면 여러분도 스포츠계의 전설이 되는 것입니다. 적어도 스크립팅 스포츠계에서는 전설이 되는 것이며, 이것도 대단한 영예라 할 수 있죠.
Scripting Games(2월 15일에서 3월 3일까지)는 도전과 재미로 가득한 이벤트입니다. 무엇보다도 모두에게 참여의 문이 열린 대회입니다. 시스템 관리 스크립팅이 다소 생소하다면 Beginners Division에 참여하여 VBScript, Windows PowerShellTM, Perl(올해 새로 추가) 등에서 초보자들을 위한 별도의 경합에 참여할 수 있습니다. Beginners Division은 너무 쉽다고요? 그렇다면 Advanced Division에서 동일한 VBScript, Windows PowerShell 및 Perl을 주제로 겨뤄보십시오.
이 대회(2월 15일부터 3월 3일까지라고 말했죠?)는 한 마디로 스크립팅 시즌 이벤트라고 할 수 있습니다. 이 기회를 절대 놓치지 마세요. 지금 바로 Script Center 홈 페이지에서 대회에 관한 여러 정보와 비결을 알아보고 대회가 공식적으로 시작되는 2월 15일에 홈 페이지를 다시 방문하십시오.
다시 한 번 강조하지만 대회 기간은 2월 15일부터 3월 3일까지입니다.
그런데 이번 달에는 Scripting Games 발표 소식에다가 새로운 Hey, Scripting Guy! 칼럼까지 작성하느라 숨 돌릴 틈이 없네요. 하지만 TechNet Magazine 독자 여러분의 행복을 위해 어쨌든 새 칼럼도 쓰기로 결심했답니다. 저희의 중요한 삶의 목표가 또 여러분의 행복 아니겠습니까?
정확히 일년 전(벌써 그렇게 됐나요?) 저희는 스크립트를 사용하여 XML 파일을 읽는 방법에 대해 칼럼을 게재했었습니다. 그때는 스크립트를 사용하여 XML 파일을 생성, 작성, 수정하는 방법은 다루지 않았었죠. 이번에는 모두 알려드리겠습니다. XML 파일을 생성할 수 있는 스크립트는 어떻게 작성하는지 궁금하시죠? 여러분의 이 갈증을 풀어드리는 데 1년이나 걸렸군요. 죄송합니다. 그림 1을 보시면 이 스크립트가 나와 있습니다. 꽤 복잡해 보이지만 지금부터 모두 차근차근 설명해 드리겠습니다.
Figure 1 XML 파일 만들기 (Close Figure 1)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

Set objRoot = _
  xmlDoc.createElement("ITChecklist")
xmlDoc.appendChild objRoot

Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord

Set objName = _
  xmlDoc.createElement("ComputerName")
objName.Text = "atl-ws-001"
objRecord.appendChild objName

Set objDate = _
  xmlDoc.createElement("AuditDate")
objDate.Text = Date
objRecord.appendChild objDate

Set objIntro = _
  xmlDoc.createProcessingInstruction _
  ("xml","version='1.0'")
xmlDoc.insertBefore _
  objIntro,xmlDoc.childNodes(0)

xmlDoc.Save "C:\Scripts\Audits.xml"
먼저 Microsoft.XMLDOM 개체의 인스턴스를 만듭니다. 짐작하셨겠지만 이것은 우리가 XML 파일을 사용하여 작업할 수 있게 해주는 개체입니다. 여기서 우리의 목표는 그림 2와 같이 간단한 XML 파일을 만드는 것입니다.
그림 2 목표: 간단한 XML 파일
그림 2 목표: 간단한 XML 파일
이런 XML 파일을 만들려면 우선 루트 노드(ITChecklist)를 생성해야 합니다. 어떻게 하냐고요? 다음과 같습니다.
Set objRoot = _
  xmlDoc.createElement("ITChecklist")
xmlDoc.appendChild objRoot
아주 간단하죠? 루트 노드에 지정할 이름을 createElement 메서드에 전달하고 호출한 다음 appendChild 메서드의 유일한 메서드 매개 변수에 새 요소(objRoot)에 대한 개체 참조를 지정하고 메서드를 호출하면 됩니다. 그러면 이제 루트 노드가 생성된 것입니다.
그러나 아직 끝난 것은 아니죠. 이제 ComputerAudit 노드를 생성해야 합니다. 이 노드는 ITChecklist 노드의 하위 노드로, 단일 컴퓨터의 정보를 표시합니다. 보시다시피 이 노드를 생성하는 코드는 루트 노드를 만드는 코드와 비슷합니다.
Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord
유일한 차이점은 루트 노드를 만들 때는 XML 문서 자체에서 appendChild를 호출했는데(개체 참조 xmlDoc 확인), 루트에 새 하위 노드를 추가할 때는 XML 문서가 아닌 루트 노드(objRoot)에서 appendChild를 호출한다는 것입니다. 너무 쉽죠?
ComputerName 노드와 AuditDate 노드를 ComputerAudit의 하위 노드로 추가하는 방법도 역시 간단합니다. 비슷한 절차를 거치는데요, createElement를 호출하여 새 노드를 만들고, appendChild를 호출하여 이 새 노드를 파일에 추가하면 됩니다.
(돌발 퀴즈: 이때 appendChild는 어디서 호출할까요? 그렇습니다. 방금 생성한 상위(ComputerAudit) 노드인 objRecord에서 호출합니다.)
그리고 ComputerName 노드와 AuditDate 노드는 값을 포함해야 하기 때문에 문서에 추가하기 직전 이들 각 노드의 Text 속성 값도 반드시 지정해야 합니다.
ComputerName 노드를 실제로 생성하는 아래 코드를 보시면 보다 명확히 이해할 수 있습니다.
Set objName = _
  xmlDoc.createElement("ComputerName")
objName.Text = "atl-ws-001"
objRecord.appendChild objName
예상하셨겠지만, AuditDate를 생성하는 코드 또한 거의 동일합니다. createElement를 호출할 때 노드 이름을 다르게 지정하고 Text 속성에 다른 값을 지정하면 되는 것입니다.
이거 너무 쉬운거 아닌가요?
첫 번째이자 이 예에서는 유일한 레코드의 노드를 생성했으면 아래의 간단한 코드 블록을 실행합니다.
Set objIntro = _
 xmlDoc.createProcessingInstruction _
  ("xml","version='1.0'")
xmlDoc.insertBefore _
  objIntro,xmlDoc.childNodes(0)
이 코드는 파일의 시작 부분에 <?xml version="1.0" ?> 태그를 삽입하여 정확한 형식의 XML 문서가 생성되도록 합니다.
이제 남은 일은 Save 메서드를 호출하고 새 파일을 C:\Scripts\Audits.xml로 저장하는 것입니다.
xmlDoc.Save "C:\Scripts\Audits.xml"
이렇게 간단히 새로운 XML 문서가 탄생했습니다.
이 정보는 사실상 매우 유용합니다. 이제 스크립트를 사용하여 새 XML 파일을 만들 수 있는 것입니다. 물론, 새 XML 파일을 만드는 것보다는 기존 파일에 단순히 새 데이터를 추가해야 하는 경우가 더 많기는 하죠. 따라서 Scripting Guys가 지금부터 기존 파일에 새 데이터를 추가하는 방법을 알려드리겠습니다.
원래 저희는 기존 XML 파일에 데이터를 추가하는 방법까지는 설명하지 않을 생각이었어요. 그렇지만 너무 마음이 여린 저희는 TechNet Magazine 독자들께 한 가지 제안을 해보기로 했습니다. 지금 이 매거진을 읽고 계신 여러분 모두 2008 Winter Scripting Games에 참여하신다면, 그 보답으로 저희는 스크립트를 사용하여 XML 파일에 데이터를 추가하는 방법을 보여드리는 것이죠. 자, 그럼 모두 Scripting Games에 참여하기로 약속하신겁니다?
저희는 끝까지 기다릴거예요. 거기 서울에 계신 분, 약속하시죠?
꼭 참여하시는 겁니다? Scripting Games에서 여러분 모두 좋은 시간 보내실 거예요. 그건 저희가 약속드리죠.
자, 그럼 약속은 약속이니까 이제 스크립트로 기존 XML 파일에 데이터를 추가하는 방법에 대해 설명하겠습니다. 그림 3을 한번 보세요.
Figure 3 XML 파일에 추가 (Close Figure 3)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set objRoot = xmlDoc.documentElement

Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord

Set objFieldValue = _
  xmlDoc.createElement("ComputerName")
objFieldValue.Text = "atl-ws-100"
objRecord.appendChild objFieldValue

Set objFieldValue = _
  xmlDoc.createElement("AuditDate")
objFieldValue.Text = Date
objRecord.appendChild objFieldValue

xmlDoc.Save "C:\Scripts\Audits.xml"
보다시피 XML 파일 생성 스크립트와 크게 다르지는 않습니다. 먼저 Microsoft.XMLDOM 개체의 인스턴스를 만든 다음, Async 속성을 False로 설정하여 문서를 비동기가 아닌 동기적으로 로드하도록 스크립트에 지시합니다. 이것에 어떤 차이가 있을까요? 문서를 비동기적으로 로드하면 문서가 완전히 로드되지 않았는데도 스크립트가 계속 실행될 수 있습니다. 아직 생성되지도 않은 문서에 작업을 수행하려 하면 당연히 문제가 발생하지요. 따라서 XML 파일이 반드시 동기적으로 로드되게 하여 파일이 완전히 로드된 후에 스크립트가 진행되도록 해야 하는 것입니다.
이제 Load 메서드를 호출하여 C:\Scripts\Audits.xml 파일을 엽니다. 파일이 열리면 아래의 코드 줄을 사용하여 documentElement 클래스의 인스턴스를 생성합니다. 이 인스턴스는 우리를 이 문서 루트에 묶어 두는 효과가 있습니다. 여기서는 물론 ITChecklist 노드가 되겠죠.
Set objRoot = xmlDoc.documentElement
이제부터는 일사천리로 진행됩니다. 새 노드를 파일에 추가하는 appendChild 메서드를 사용하여 ComputerAudit 노드의 새 인스턴스를 만듭니다. 그런 다음 ComputerName 노드와 AuditDate 노드에 대해 적절한 값(각각 atl-ws-100 및 현재 날짜)을 지정하여 두 노드의 새 인스턴스를 만듭니다. 생성된 이 두 항목을 조금 전에 만든 새 ComputerAudit 노드에 넣고 Save 메서드를 호출하여 파일을 저장하면 끝입니다. 이제 Scripting Games나 준비하러 가면 되는 거죠.
예, 그렇죠. 2월 15일부터 3월 3일까지 TechNet Script Center에서 열린다는 그 이벤트말입니다.
지금까지 아주 좋습니다. 이제 새 XML 파일을 만들고 이 파일에 새 레코드를 추가할 수도 있습니다. 그런데 이것이 전부는 아닙니다. 예를 들어 파일의 기존 레코드를 수정해야 할 때는 어떻게 하죠? 그림 4에는 파일의 기존 레코드를 수정하는 방법 중 하나가 나와 있습니다.
Figure 4 XML 수정 (Close Figure 4)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']/AuditDate")

For Each objNode in colNodes
   objNode.Text = Date
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
이 스크립트의 핵심 동작은 쿼리의 반환 레코드를 결정하는 selectNodes 메서드를 호출할 때 발생합니다. 그림과 같이 selectNodes를 호출할 때는 두 가지 조건을 주의해서 지정해야 합니다. 즉, 레코드의 ComputerName 특성이 atl-ws-100이어야 하고, AuditDate 특성만 반환되도록 해야 합니다.
왜 그런지 잘 모르겠다면 XML 파일 작업에 대한 Scripting Guys의 첫 번째 기사(technetmagazine.com/issues/2007/02/HeyScriptingGuy)를 읽어 보십시오. 여기에는 selectNodes 쿼리 구문에 대한 자세한 설명이 나와 있습니다.
이제 원하는 대로 selectNodes는 지정한 조건에 맞는 모든 XML 레코드의 컬렉션을 반환합니다. 이는 곧 AuditDate 특성(유일하게 요청한 특성)의 값을 업데이트할 수 있음을 의미합니다. 즉, 컬렉션의 모든 항목을 대상으로 반복하도록 For Each 루프를 설정하고 이 루프에서 AuditDate에 새 값을 지정하여 업데이트할 수 있습니다.
For Each objNode in colNodes
   objNode.Text = Date
Next
그런데 한 번에 두 개 이상의 특성을 수정할 수도 있을까요? 물론입니다. 그러나 이 내용은 다음 칼럼에서 다루도록 하겠습니다.
혹시 말이죠, 파일에서 모든 컴퓨터의 감사 날짜를 업데이트하는 방법도 알고 싶으세요? 간단합니다. 그림 5의 스크립트를 사용하면 됩니다.
Figure 5 감사 날짜 변경 (Close Figure 5)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit/AuditDate")

For Each objNode in colNodes
   objNode.Text = Date
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
이 스크립트와 앞서 살펴본 XML 수정 스크립트의 유일한 차이점이 무엇인지 아시겠어요? 이 스크립트에서는 ComputerName이 atl-ws-100인 레코드만 표시하도록 지정하지 않는다는 점이 다르죠. 이 조건을 지정하지 않기 때문에 기본적으로 모든 레코드가 반환됩니다.
마지막으로 스크립트를 하나만 더 살펴보겠습니다. atl-ws-100이라는 이 끈질긴 조건이 마지막 제 역할을 다한 후 저세상으로 떠났다고 가정해 봅시다.
여기서 잠깐, 컴퓨터는 죽으면 어디로 갈까요? 대개는 Scripting Guys 중 한 명에게 가는 것 같습니다. 실제로 본 칼럼을 쓰고 있는 이 Scripting Guy도 전에 "Microsoft를 위해 애써왔으니 랩톱 컴퓨터를 한 대 선사한다"면서 랩톱 컴퓨터를 받은 적이 있습니다. 고마운 일이었지만 컴퓨터가 고장나서 켜지지도 않는다는 것이 문제였죠. 그정도는 괜찮았을지도 모르는데, 알고보니 하드 디스크도 없더군요.
컴퓨터라는 거대한 실리콘 집합체의 수명을 완전히 끝내려면 XML 파일에서 atl-ws-100을 삭제해야 합니다. 구체적으로 어떻게요? 그림 6을 보십시오.
Figure 6 XML 파일에서 삭제 (Close Figure 6)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']")

For Each objNode in colNodes
  xmlDoc.documentElement.removeChild _
    (objNode)
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
보시다시피 이 스크립트는 AuditDate 속성을 수정하는 이전 스크립트와 비슷합니다. 다만 두 가지가 다릅니다. 첫째는 selectNodes 쿼리에 속성 값을 지정하지 않기 때문에 atl-ws-100에 대해 전체 XML 레코드가 반환된다는 것입니다.
Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']")
둘째는 For Each 루프에서 removeChild 메서드를 호출하여 ComputerName이 atl-ws-100인 레코드를 모두 삭제한다는 점입니다.
xmlDoc.documentElement.removeChild _
  (objNode)
이것으로 끝입니다. 이제 atl-ws-100은 우리에게서 완전히 떠나는 것이죠.
혹시 TechNet Magazine 편집자 중 아직 이번 달 칼럼을 읽고 있는 사람이 있나요? 아, 모두 이번 달 스크립팅 퀴즈를 풀러 갔다고요? 그거 다행이군요. 이제 우릴 감시하는 사람들이 없으니 한 가지 말씀드리죠. 지금 이 칼럼을 읽든 기타 무엇을 하든지 당장 그만두고 바로 Script Center를 방문하여 Scripting Games를 준비하세요. TechNet Magazine이야 오랫동안 게시되니 언제라도 읽을 수 있지 않습니까? 그렇지만 Scripting Games는 일년에 한 번만 일정 기간(구체적으로 말하면 2월 15일부터 3월 3일까지) 동안만 개최됩니다. 이 귀중한 기회를 놓쳐서는 안 되죠!
한 가지 말씀드리자면, TechNet Magazine을 그만 읽으라고 했지만, 사실상 칼럼 본문은 이미 다 읽은 셈입니다. 그렇죠? 희한한 일이죠.

Dr. Scripto의 Scripting Perplexer
매달 퍼즐 풀이 실력뿐만 아니라 스크립팅 기술까지 시험해 볼 수 있는 문제입니다.

2008년 2월: 불가사의한 기호
컴퓨터 키보드에는 이상한 모양의 문자들이 가득합니다. 게다가 이러한 문자는 대부분 VBScript나 Windows PowerShell과 같은 스크립팅 언어에서 특정한 용도로 사용됩니다. 각 기호가 스크립팅 시에 어떤 용도로 사용되는지 맞춰 보십시오. 예를 보여 주기 위해 첫 번째 기호는 이미 답이 적혀 있습니다.

Dr. Scripto의 Scripting Perplexer
답: 불가사의한 기호, 2008년 2월

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


 Security Watch: 아일랜드 하핑: 원치 않는 종속성 처리
Security Watch
아일랜드 하핑: 원치 않는 종속성 처리
Jesper M. Johansson

지난 달 Security Watch에서는 네트워크를 공격하기 위해 USB 플래시 드라이브를 사용하는 시작 단계에 대해 살펴보았습니다. 공격은 감염된 USB 플래시 드라이브를 컴퓨터에 연결하는 순간 시작됩니다. 연결하면 악성 코드가 자동으로 또는 사용자의 약간의 도움을 통해(간단한 사회 공학을 이용하여)
실행됩니다. 이 공격은 워크스테이션에 로컬로 존재하지만 맬웨어가 네트워크의 다른 부분으로 확산될 수 있다는 것은 확실합니다. 곧 출간될 필자의 저서 Windows Server 2008 Security Resource Kit(Microsoft Press®, 2008)에서는 이러한 형태의 네트워크 공격에 대해 자세히 설명합니다. 이 칼럼에도 이 책에 실린 내용 중 일부가 포함되어 있습니다.
가장 확실한 보호 방법 한 가지는 이동식 드라이브의 사용을 금지하는 것입니다. 하지만 좋은 방법처럼 보일지라도 이를 시행하려고 하면 사용자들의 불만이 만만치 않을 것이며 그러한 사용자에게 책임을 묻기도 어려울 수 있습니다. 극도로 중요한 환경이 아니라면 더 좋은 방법은 관련된 위험을 관리하고 노출을 억제하는 것입니다.
또한 이동식 드라이브만 클라이언트 컴퓨터에 보안 위험을 초래하는 것이 아닙니다. "10가지 불변의 보안 법칙"(microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx)을 상기해 보십시오. 여기서 "악의적 의도를 가진 누군가가 아무런 제한 없이 사용자의 컴퓨터에 물리적으로 액세스할 수 있다면 이 컴퓨터는 더 이상 사용자의 컴퓨터가 아니다."라는 세 번째 법칙은 여전히 유효합니다. 이 법칙을 고려할 때 공격자가 컴퓨터에 액세스할 수 있다면 그 컴퓨터의 보안은 침해된 것으로 간주해야 합니다. 공격자가 자신의 코드를 사용자 컴퓨터에서 실행할 수 있다면 원격에서도 이런 공격이 가능합니다. 이는 "악의적인 해커가 사용자의 컴퓨터에서 마음대로 자신이 만든 프로그램이 실행되도록 할 수 있다면 해당 컴퓨터는 더 이상 사용자의 것이 아니다."라는 첫 번째 법칙에 해당합니다.
이러한 불변의 법칙은 매우 잘 들어맞는 것으로 입증되었으며 컴퓨터의 작동 방식이 근본적으로 변경되기 전에는 크게 변경되지 않기 때문에 이 법칙을 지키는 것이 안전합니다. 따라서 설정된 시나리오에 이러한 법칙이 어떤 식으로 적용되는지 고려하여 이동식 드라이브 문제를 해결하는 것이 필수적입니다. 약간의 레지스트리 조작으로 이렇게 할 수 있습니다.
물론 다른 보호 대책도 마련해 두어야 합니다. 클라이언트 컴퓨터 중 많은 수에서 보안이 이미 침해되었거나 회사의 중요 보안 대책을 염두에 두지 않는 사용자가 사용할 수 있다고 가정하는 것이 타당합니다. 그리고 이로 인해 네트워크의 다른 부분에 영향이 미치지 않도록 해야 하며 이에 따라 보안 종속성의 파악, 분석 및 완화가 가지는 중요성이 더욱 커집니다.

보안 종속성의 정의
보안 종속성은 컴퓨터의 보안이 다른 컴퓨터의 보안에 종속될 때 발생합니다. "DC(도메인 컨트롤러)가 해킹되면 전체 네트워크가 해킹된 것이다."라는 이야기를 들은 적이 있을 것입니다. 이는 모든 도메인 구성원의 보안이 DC에 종속된다는 것을 가장 간단히 표현하는 말입니다. DC가 안전하지 않으면 구성원 컴퓨터가 안전할 수 없습니다. 공격자가 도메인의 보안 구성을 변경할 수 있으면 구성원 컴퓨터의 Administrators 그룹에 새 계정을 추가하는 등의 방법으로 도메인의 모든 컴퓨터에 대한 제어권을 확보할 수 있습니다. 관리자가 보안에 손상을 줄 수 있는 취약점만이 문제가 아닙니다. 관리자는 해당 관리자가 관리하는 모든 시스템에 대한 완전한 액세스 권한을 가집니다.
컴퓨터 시스템에서 종속성은 피할 수 없습니다. 사실 종속성은 매우 많은 곳에 사용되며 필요한 경우도 많습니다. 그렇다고 모든 종속성을 허용할 수 있다는 의미는 아닙니다. 이 칼럼에서는 적절한 종속성과 부적절한 종속성을 설명한 다음 종속성의 유형을 분석하고 이를 처리하는 방법을 설명합니다. Windows Server 2008 Security Resource Kit에서는 개별 종속성에 대해 자세히 소개하고 이를 관리하는 방법을 설명합니다.

적절한 종속성
대개의 경우 중요도가 낮은 시스템이 보안을 위해 중요도가 높은 시스템에 종속될 때는 종속성이 허용됩니다. 일반적으로 컴퓨터와 시스템은 중요도에 따라 분류할 수 있습니다. 특정 환경의 구체적인 등급은 지금 이야기하고 있는 주제와 크게 관련이 없으므로 기본적인 분류가 있다는 점만 이해하시기 바랍니다. 논의의 편의를 위해 여기서는 워크스테이션과 DC의 두 분류가 있다고 가정하겠습니다. 이 시나리오에서는 워크스테이션이 보안을 위해 DC에 종속되는 것이 허용됩니다. DC 등급은 워크스테이션보다 중요하므로 당연히 더 높은 수준으로 보호되어야 합니다.
사용자 계정에도 같은 논리를 적용할 수 있습니다. 관리자가 사용자 소유의 데이터를 조작하는 것은 허용됩니다. 관리자의 책임이 더 크며 컴퓨터와 해당 컴퓨터 안의 모든 데이터에 자유롭게(항상 직접적이거나 명확한 것은 아니지만) 액세스할 수 있기 때문입니다. 이 사실을 이해하고 적절하게 컴퓨터를 관리한다면 이 종속성에는 아무 문제가 없습니다.
소프트웨어도 이런 방식으로 분석할 수 있습니다. 웹 브라우저처럼 중요도가 낮은 소프트웨어가 운영 체제와 같은 중요도가 높은 소프트웨어에 보안을 위해 종속되는 것은 허용 가능합니다. OS에 버그가 있는 경우 웹 브라우저가 새로운 문제점에 취약해진다는 점은 놀라운 일이 아니며 즉각적인 조치 목록에서 우선 순위가 낮을 것입니다. OS와 기타 중요한 응용 프로그램 및 데이터가 주된 관심 대상이기 때문입니다. 이런 사실은 버그를 수정하는 방법 및 핫픽스 적용 대상과도 관련됩니다. 최대한 문제에 가깝게 접근하여 버그를 수정해야 합니다. 이렇게 해야 픽스로 인한 보호 효과가 최대화됩니다. 따라서 웹 브라우저에서 관련 문제를 해결하는 것보다는 OS 자체의 문제를 먼저 해결해야 합니다.
또는 디자인 변경을 통해 종속성을 제거할 수 있습니다. 예를 들어 웹 브라우저를 다시 작성하여 OS에 대한 종속성을 줄일 수 있습니다. 더 중요한 구성 요소(이 경우 OS)의 기능이 중요도가 낮은 구성 요소(웹 브라우저)가 해당 기능을 사용하는 방식으로 사용되도록 설계되지 않은 경우에 이 방식이 적합합니다.

부적절한 종속성
적절한 종속성에 대해 설명한 내용을 잘 생각해 보면 부적절한 종속성에 대한 정의가 명확해집니다. 기본적으로 더 중요한 시스템은 절대로 중요도가 낮은 시스템에 종속되어서는 안 됩니다.
워크스테이션의 보안 침해가 곧 DC의 보안 침해를 의미하는 상황이라면 심각한 보안 문제가 있는 것입니다. 전체 보안이 네트워크에 있는 개별 컴퓨터의 보안에 종속된다면 네트워크 보호는 불가능합니다.
이를 통계적으로 살펴보겠습니다. 네트워크의 모든 컴퓨터가 전체 시간 중 99.999퍼센트의 시간 동안 "안전"하다면 매우 안전한 네트워크를 갖추었다고 생각할 수 있습니다. 사실 이러한 비율은 아주 작은 네트워크가 아니라면 현실적인 수치와 상당히 차이가 있습니다. 그러면 이제 네트워크에 40,000대의 컴퓨터가 있고 각 컴퓨터가 전체 시간의 0.001퍼센트 동안 취약하다고 가정하겠습니다. 그러면 전체 네트워크는 전체 시간의 40퍼센트 동안 잠재적으로 안전하지 않은 것입니다.
또한 종속성을 관리하지 않으면 바로 그 0.001퍼센트의 시간에 있는 한 대의 컴퓨터로 인해 전체 네트워크의 보안이 침해될 수 있습니다. 이런 측면에서 보면 네트워크는 얼마나 안전한 것일까요? 분명히 말하지만, 더 중요한 시스템을 덜 중요한 시스템으로부터 보호하는 것이 무엇보다 중요합니다.
이 논리를 사용자 계정과 소프트웨어로 쉽게 확장할 수 있습니다. 예를 들어 Windows®의 새로운 터미널 서비스 클라이언트에서는 투명한 터미널 서비스 로그온을 위해 사용자 이름과 암호를 저장할 수 있습니다. 이 자격 증명은 자격 증명 관리자 API를 통해 저장되며 기본 로그온 세션에 사용되는 자격 증명으로 보호됩니다.
이 경우 보안 종속성이 생길 수 있습니다. 자신의 개인 워크스테이션에 로그인한 네트워크 관리자의 경우를 생각해 보겠습니다. 이 관리자는 전자 메일, 웹 탐색 및 정보 근로자가 일반적으로 수행하는 작업을 위해 이 워크스테이션을 사용합니다. 이때는 권한이 낮은 도메인 계정을 사용합니다.
그러던 중 이 관리자는 몇 가지 관리 작업을 수행하기 위해 DC 중 하나에 연결합니다. 이를 위해 터미널 서비스 클라이언트를 사용하고 나중에 더 쉽게 연결할 수 있도록 암호를 저장하도록 선택합니다. 이 경우 부적절한 보안 종속성이 최소 하나, 그리고 상황에 따라 두 개까지 생깁니다. 첫 번째는 이 관리자의 도메인 관리 계정 자격 증명은 권한이 낮은 정보 근로자 자격 증명으로 보호된다는 점입니다. 이 권한이 낮은 사용자 계정이 손상되면 도메인 관리 사용자 계정도 손상되어 결국 전체 도메인의 보안이 침해됩니다.
두 번째 종속성은 이 관리자가 도메인 컨트롤러가 아닌 시스템에서 도메인 관리 자격 증명을 입력한다는 사실 때문에 발생합니다. 개인 워크스테이션이 최소한 DC와 같은 수준으로 보호되는 경우가 아니라면(대개의 경우 이렇게 보호되지 않음) DC의 보안이 해당 사용자의 개인 워크스테이션에 설정된 보안에 종속되는 결과를 초래합니다. 예를 들어 회사에 불만을 품은 동료 직원이 네트워크 관리자의 워크스테이션에 키 입력 로거를 설치하면 도메인 관리 자격 증명이 캡처됩니다. 도메인 컨트롤러가 아닌 시스템에서 도메인 관리 자격 증명을 입력할 때마다 해당 시스템의 보안 결함이 전체 도메인에 노출됩니다.
이제 도메인 관리자가 현재 로그온해 있거나, 로그온한 적이 있거나, 앞으로 로그온할 컴퓨터에 공격자가 이동식 드라이브를 삽입한다고 가정해 보겠습니다. 그러면 이 도메인 관리자에게 보안 문제가 발생하며 더 나아가 전체 도메인의 보안이 침해됩니다. 이런 상황을 피할 수 있도록 이에 대한 내용을 충분히 파악해야 합니다. 물론 보안 응용 프로그램이 특정 작업을 수행할 때 보안 수준이 더 낮게 설정된 응용 프로그램의 기능에 의존하는 경우에도 동일한 상황이 발생할 수 있습니다.

공격에 대한 분석
앞에서 악의적 의도를 가지고 이동식 드라이브를 컴퓨터에 삽입한 경우에 발생할 수 있는 문제를 설명했습니다. 하지만 드라이브가 처음에 삽입된 컴퓨터의 경우에는 어떤 상황이 될지 분명합니다. 따라서 해당 컴퓨터가 그림 1에서처럼 도메인에 가입된 것으로 가정해 보겠습니다.
그림 1 이상적인 도메인 종속성
그림 1 이상적인 도메인 종속성
여기서 설명하는 시나리오는 이상적인 종속성을 나타냅니다. 화살표는 방향을 나타내며 종속성이 어디서 상속되는지를 가리킵니다. 예를 들어 워크스테이션의 보안은 DC의 보안에 종속되며 사용자의 보안은 워크스테이션의 보안에 종속됩니다. 공격자는 워크스테이션의 보안을 침해할 수 있으며 이 경우에는 사용자가 해당 워크스테이션에 저장한 모든 정보에서 보안 침해가 발생할 수 있지만 보안 침해는 이 단계에서 격리됩니다.
하지만 워크스테이션에 로그온하는 사용자가 서버에서 로컬 관리자 그룹의 구성원이라고 가정하겠습니다. 그리고 도메인 관리자가 서버에 자주 로그온한다고 가정해 보십시오. 그러면 종속성은 그림 2와 같아집니다.
그림 2 보안이 침해된 도메인 종속성
그림 2 보안이 침해된 도메인 종속성
문제의 컴퓨터에 로그온한 사람을 다르게 가정한 것만으로 네트워크 전체의 보안이 위험해졌습니다. 도메인 관리자가 서버에 로그온하기 때문에 DC와 전체 도메인의 보안이 해당 서버의 보안에 종속됩니다.
서버를 DC와 같은 수준의 보안으로 관리한다면 문제가 되지 않습니다. 하지만 이 경우 워크스테이션에 로그온하는 사용자는 서버 Administrators 그룹의 구성원입니다. 따라서 서버의 보안이 워크스테이션의 보안에 종속됩니다. 이는 전체 도메인의 보안이 워크스테이션의 보안에 종속된다는 의미입니다. 이 경우 이 워크스테이션에서 사용자 모르게 공격자의 도구가 실행되면 어떻게 될까요?
오늘날 정보 보안에 있어서 보안 종속성보다 중요하게 다루어야 할 개념은 거의 없습니다. 네트워크를 분석하고 종속성을 파악해 보면 틀림없이 부적절한 종속성을 발견하게 될 것입니다. 생각보다 많이 발견되는 최악의 시나리오는 전체 네트워크의 보안이 전체 네트워크에 종속되는 경우입니다. 즉, 모든 개별 컴퓨터의 보안이 다른 모든 컴퓨터의 보안에 종속되어 있을 수 있습니다. 이 경우 관계를 제어하는 것이 불가능하고 너무 복잡하기 때문에 이런 유형의 환경에서는 합리적이고 현실적인 위험 관리 전략을 개발하는 것이 불가능합니다. 해결 방법은 종속성을 분석하고 관리하는 것뿐입니다.
이 칼럼에서는 종속성의 의미와 이를 분석하고 해결하는 방법에 대해 개괄적으로 설명했습니다. 자세한 내용은 필자의 저서 Windows Server 2008 Security Resource Kit에서 보실 수 있습니다. 이 책에서는 장 전체를 할애하여 종속성을 분석하고 서버 및 도메인 격리 등의 고급 기술과 관리 계정 관리 등의 일반적인 기술을 모두 사용하여 이를 관리하는 방법에 대해 다룹니다.
이 칼럼의 집필을 위한 아이디어를 구상하는 데 도움을 준 David LeBlanc에게 감사의 뜻을 전합니다.

Jesper M. Johansson은 소프트웨어 보안 문제 분야의 보안 엔지니어이며 TechNet Magazine의 객원 편집자로서, MIS 분야 박사 학위를 취득했고 컴퓨터 보안 분야에서 20년 이상의 경력을 보유하고 있습니다.


 The Desktop Files: Windows XP와 Windows PE 2.0 이중 부팅
The Desktop Files
Windows XP와 Windows PE 2.0 이중 부팅
Wes Miller
이 기사의 코드 다운로드: Desktop2008_02.exe (151KB)

The Desktop Files의 이전 연재 기사에서 Windows PE가 복구용 도구가 되었음을 언급하고 두 번째 파티션에서 이 도구를 사용하는 방법을 설명한 바 있습니다.########## 그런데 최근 어떤 질문을 받은 것을 계기로 Windows PE 2.0과 Windows XP를 함께 사용하는 데 대해 새롭게 조명하는 기사를 써보면 괜찮겠다는 생각이 들었습니다.
대다수 사용자는 당분간은 Windows® XP를 사용할 것이며 Microsoft에서는 Windows PE 2.0을 지원하는 방향으로 나아갈 것입니다. 즉, Windows PE 1.x에 대한 업데이트는 더 이상 발표하지 않습니다.
Windows PE 1.x와 2.x의 중요한 차이점 중 하나는 Windows PE 2.x의 경우 Windows PE 1.x처럼 특별한 방법을 사용하는 것이 아니라 표준 부팅 인터페이스를 통해 부팅할 수 있다는 점입니다. Windows PE 1.x 또는 2.x를 별도의 파티션에서 부팅할 수도 있지만 운영 체제가 설치된 부팅 파티션에서 부팅하면 앞으로 살펴볼 내용과 같이 많은 면에서 매우 편리합니다.

Windows 이중 부팅
Windows NT®에서는 이중 부팅이 비교적 용이했습니다. 하지만 EFI(Extensible Firmware Interface) 기반 컴퓨터가 기존 IBM PC AT BIOS를 대체하기 시작함에 따라 Microsoft에서는 EFI에 최적화되어 작동하고 모든 아키텍처에 하나의 부팅 메커니즘이 공통적으로 사용되도록 Windows 부팅 메커니즘을 변경했습니다. Windows Vista®에서부터 도입된 새로운 Windows 부팅 메커니즘을 BCD(부팅 구성 데이터베이스)라고 합니다(microsoft.com/whdc/system/platform/firmware/bcd.mspx 참조). 하지만 기존의 boot.ini나 새로운 BCD 메커니즘 모두에서 Windows는 일반적으로 다른 운영 체제로 부팅할 수 있습니다. 물론 이 경우에는 부팅 프로세스의 제어 권한이 다른 부팅 로더로 넘어갑니다.
본격적인 설명을 시작하기에 앞서 Windows PE 2.0은 ACPI(고급 구성 및 전원 인터페이스)와 완전하게 호환되고 384MB의 RAM(이상적으로는 512MB)이 장착된 시스템에서만 작동한다는 점을 기억해야 합니다. 5월호 칼럼(technetmagazine.com/issues/2007/05/DesktopFiles)에서 언급했듯이 ACPI를 지원하지 않는 시스템에서는 Windows PE 2.0으로 부팅할 수 없으며 Windows PE 2.0은 RAMDisk로 부팅해야 하므로 RAMDisk, 스크래치 공간 및 모든 RAM 작업 집합을 수용하기에 충분한 RAM이 있어야 합니다. 시스템의 RAM이 384MB 미만인 경우에는 Windows PE 1.6을 사용하는 것이 좋습니다. 아무리 Windows PE 크기를 줄이더라도 256MB에서는 제대로 실행할 수 없습니다.

해결할 문제
이제 Windows XP와 동일한 파티션에서 Windows PE 2.0을 부팅하여 해결할 수 있는 문제에 대해 살펴보겠습니다.
전체 시스템 복구 전체 시스템 복구는 Windows XP 파티션에서 곧바로 Windows PE를 부팅할 때 수행 가능한 작업 중 하나입니다. 이전 버전인 Windows PE 1.6과 마찬가지로 Windows PE 2.0은 완전히 RAMDisk로 부팅할 수 있기 때문에 전체 디스크의 이미지를 다시 만들 수 있습니다. 또한 전체 파티션 이미지를 다시 만들 필요가 없기 때문에 ImageX를 사용하여 Windows XP 파일을 그 자체만으로 복원할 수 있습니다.
시작할 때 Windows PE로 부팅할 수 있기 때문에 사용자가 원격으로 작업할 때도 자신의 시스템을 복구할 수 있습니다. 보조 파티션, 네트워크 공유(모바일 사용자가 아닌 경우), 복구 DVD 또는 USB 하드 디스크의 이미지를 사용할 수 있으며, ImageX를 사용할 때는 복구 중인 파티션에 저장할 수도 있습니다. 이러한 디스크 복구는 물리적인 디스크 손상을 제외한 많은 문제점의 효과적인 해결 방안이 됩니다. 물론 데이터가 이미 보호되고 있고 복구 과정의 일부로 복원하는 경우가 아니면 사용자 데이터를 복원하는 데에는 큰 효과가 없습니다. 이러한 손실을 방지하려면 로밍 프로필을 사용하고 PC에서 데이터를 백업해야 한다는 것을 기억하십시오. 또한 사용자가 특별한 조치를 취하지 않더라도 EFS 암호화 키 재설정으로 인한 손실을 비롯한 잠재적인 데이터 손실의 위험을 줄일 수 있는 복구 메커니즘을 사용해야 합니다.
파일 복구 Windows PE에서는 Windows 기본 설치로 부팅하지 않더라도 시스템을 시동하고 실행할 수 있는 메커니즘도 제공합니다. 이 경우에는 부팅한 후 사용자 데이터를 다른 시스템으로 복구하거나(사용자가 웜 백업 시스템을 사용할 수 있는 경우) 다른 위치로 복구하여 사용자가 신속하게 작업을 계속하도록 할 수 있습니다.
시스템 복구 마지막으로, Windows XP에서 Windows PE를 부팅하면 문제 해결 스크립트 또는 간단한 복구 작업이나 복구 응용 프로그램을 실행하여 시스템을 복구할 수 있습니다. 복구 과정은 전체 시스템 복구와 비슷하지만 범위가 더 좁고 사용자 데이터에 위험이 없습니다.
지금까지 Windows XP 파티션에서 Windows PE를 부팅할 경우 가능한 작업에 대해 살펴보았으므로 이제 원하는 다른 솔루션에 프로세스를 적용할 수 있도록 이 프로세스의 작동 방식에 대해 알아보겠습니다.

Windows Vista 이전
Windows Vista가 출시되기 이전의 BIOS/MBR(마스터 부트 레코드) 기반 시스템은 다음과 같이 부팅되었습니다. BIOS가 부팅 장치를 가리킵니다. 하드 디스크의 경우에는 디스크의 MBR을 가리킵니다. MBR에서는 부팅할 파티션을 지정하는 코드를 실행합니다. 이 파티션은 활성 플래그가 설정된 첫 번째 파티션입니다. diskpart의 최초 버전에서는 파티션을 비활성화할 수 없었습니다. 즉, 활성 플래그를 제거할 수 없었습니다. 이 문제를 해결하기 위한 스위치가 diskpart에 추가되었는데, 이 스위치가 없다면 파티션 테이블 순서에서 활성 플래그가 설정된 파티션은 첫 번째 파티션일 것입니다. 파티션에는 다음으로 실행할 코드를 지시하는 부트 섹터가 들어 있습니다. Windows NT부터 Windows Server® 2003까지는 실행할 코드가 ntldr이라는 파일(확장명 없음)에 있습니다. 디스크를 포맷한 적이 없고 Windows를 설치하지 않은 상태에서 부팅하려고 하면 "NTLDR not found(NTLDR을 찾을 수 없음)"라는 오류 메시지가 나타납니다.
ntldr은 하위 버전과는 완벽하게 호환되지만 당연히 상위 버전과는 호환되지 않습니다. 즉, Windows XP ntldr에서는 Windows 2000을 부팅할 수 있지만 그 반대로는 부팅되지 않습니다. 이런 이유로 이중 부팅을 계획할 때는 가장 이전 버전의 운영 체제를 먼저 설치해야 합니다. 게다가 ntldr에는 버전 번호가 추가되어 있지 않으므로 이 방식을 지키는 것이 더욱 중요합니다.
ntldr은 NTDetect.com을 시작하는 리얼 모드(16비트) 응용 프로그램입니다. NTDetect.com은 기본 장치 검색을 수행하고 커널인 ntoskrnl.exe(여러 파일 중 하나이며 항상 ntoskrnl.exe로 이름이 변경됨)를 시작합니다. 커널은 Windows 부팅 프로세스의 핵심 구성 요소입니다.
이는 부팅 프로세스를 지극히 단순하게 설명한 것으로, Win32®의 초기화에 대한 내용은 이 칼럼에는 적절하지 않으므로 생략했습니다. 이에 대한 자세한 내용은 Mark Russinovich와 David Solomon의 Windows Internals, Fourth Edition(Microsoft Press®, 2004)을 참조하시기 바랍니다.
CD에서 부팅할 때는 Windows Setup 및 Windows PE에서 ntldr 대신 setupldr.bin을 실행한다는 점도 알아두어야 합니다. 이 파일에는 ntldr에서는 불가능한 CD 부팅을 가능하게 하는 약간 다른 부팅 코드가 들어 있습니다. 따라서 Windows PE 1.x를 부팅하려면 setupldr.bin의 이름을 ntldr로 변경하여 디스크에 넣어야 합니다. 또한 setupldr.bin은 CD 부팅만을 위해 설계되었기 때문에 boot.ini가 필요 없는 것으로 간주되었고 이로 인해 파일에서 boot.ini 파일을 로드할 수 없습니다.

Windows Vista 이상
Windows Vista에서는 이 프로세스의 많은 부분이 변경되었습니다. 나아가 Windows Server 2008에서는 지금까지 Itanium 기반 시스템 외에는 불가능했던 EFI에서의 IA32(32비트 지원) 부팅까지 가능하게 되었습니다. BIOS 기반 시스템의 경우에는 부팅 프로세스의 초기 단계가 대부분 변경되지 않았습니다. 중요한 차이점이라면 BOOTMGR이 부팅 로더로서 초기화되고 이후 단계를 수행한다는 정도입니다.
BOOTMGR은 부팅 디렉터리에서 실질적으로 자체 레지스트리 하이브인 BCD 파일을 찾습니다. BCD에는 부팅할 부팅 항목(기본값 포함)이 포함됩니다. 이미지 형식(실행 파일 형식)은 그림 1을 참조하고 실행하는 특정 응용 프로그램 종류는 그림 2를 참조하십시오. 이러한 항목 중 하나 이상은 ntldr에 대한 참조일 수 있습니다. 그중 ntldr 로드에 사용되는 잘 알려진 GUID를 실제로 참조하는 항목은 하나뿐입니다. 이에 대해서는 그림 3의 다섯 번째 줄을 참조하십시오. 그런 다음 bootmgr은 시스템이 부팅 중인지, 최대 절전 모드에 상태인지, 아니면 ntldr 또는 다른 부팅 관리자로 부팅하는지(이 경우 다른 부트 섹터를 가리키고 해당 로드를 실행함) 여부에 따라 다음으로 로드할 항목을 결정합니다. 이는 Windows가 아닌 운영 체제로 이중 부팅을 한 경우에 일반적으로 발생하는 상황입니다. 자세한 내용은 microsoft.com/whdc/system/platform/firmware/bcd.mspx를 참조하십시오.
Figure 3 표준 응용 프로그램 개체 (Close Figure 3)

설명 | BCDEdit ID | GUID
Windows 부팅 관리자 | {bootmgr} | 9dea862c-5cdd-4e70-acc1-f32b344d4795
펌웨어 부팅 관리자 | {fwbootmgr} | a5a30fa2-3d06-4e9f-b5f4-a01df9d1fcba
Windows 메모리 테스터 | {memdiag} | b2721d73-1db4-4c62-bf78-c548a880142d
Windows 다시 시작 응용 프로그램 | 별칭 없음 | 147aa509-0358-4473-b83b-d950dda00615
레거시 Windows 로더 | {ntldr} | 466f5a88-0af2-4f76-9038-095b170dc21c
현재 부팅 항목 | {current} | fa926493-6f1c-4193-a414-58f0b2456d1e
기본 부팅 항목 | {default} | 사전 정의된 GUID 없음
Figure 2 응용 프로그램 유형 (Close Figure 2)

설명 | 값 | 설명
펌웨어 부팅 관리자 | 0x1 | EFI 시스템에만 적용됩니다.
Windows 부팅 관리자 | 0x2 | 부팅 흐름을 제어합니다. 이중 부팅 시스템에서는 사용자에게 부팅 선택 메뉴를 표시합니다.
Windows 부팅 로더 | 0x3 | Windows의 특정 버전 또는 구성을 로드합니다.
Windows 다시 시작 응용 프로그램 | 0x4 | 컴퓨터가 최대 절전 모드에서 다시 시작될 때 Windows를 실행 상태로 복원합니다.
Windows 메모리 테스터 | 0x5 | 메모리 진단 응용 프로그램입니다.
Ntldr | 0x6 | PC/AT BIOS 시스템에만 적용됩니다. Windows Vista 이전 버전의 Windows를 로드합니다.
부팅 섹터 | 0x8 | 16비트 리얼 모드 응용 프로그램입니다. PC/AT BIOS 시스템에만 적용됩니다. 부팅 프로세스를 다시 시작하고 Windows가 아닌 운영 체제를 로드하는 데 사용할 수 있습니다.
Figure 1 이미지 형식 (Close Figure 1)

설명 | 값
펌웨어 응용 프로그램 | 0x1
부팅 응용 프로그램 | 0x2
Ntldr 기반 로더 개체 | 0x3
리얼 모드 응용 프로그램 | 0x4
Windows Vista의 부팅 인프라는 이전 버전보다 훨씬 체계적으로 수정되었습니다. 즉, bootmgr 외부에서는 모든 부팅 코드가 루트 수준 \boot 디렉터리 안에 존재하며 BCD에서 지정된 후 Windows별 바이너리로 전달됩니다.

Windows XP와 Windows PE 2.0 부팅
이제 통합된 복구 도구로서 Windows PE 2.0를 추가하는 동시에, Windows XP 또는 이전 버전의 Windows로 계속 부팅할 수 있게 해주는 매개체로 Windows PE가 어떻게 이용되는지 Windows Vista 부팅 관리자를 사용하면서 이해할 수 있을 것입니다.
물론 부팅 프로세스에 새로운 단계를 추가하게 되지만 이는 Microsoft의 의도적인 설계입니다. 새로운 bootmgr 인프라에서는 기존의 ntldr 및 다른 타사 부팅 관리자의 이전 버전과 호환되어야 한다는 점을 인지하고 이러한 솔루션을 지원하도록 bootmgr을 설계한 것입니다.
지금까지 Windows가 부팅되는 과정과 새로운 BCD의 작동 방식을 알아보았습니다. 그렇다면 이 둘을 결합하여 Windows PE 2.0를 기존 Windows XP 설치에 추가하려면 어떻게 해야 할까요? 시스템에 bootmgr을 시작하도록 지시하는 부팅 코드인 Windows Vista 부트 섹터는 두 가지 방법으로 작성할 수 있습니다. 그중 하나는 diskpart를 사용하여 Windows PE 2.0으로 새 파티션을 만들고 포맷하는 방법입니다. 하지만 이미 Windows XP가 설치되어 있으며 이를 손상하거나 이동해서는 안 되므로 여기서는 이 방법이 적합하지 않습니다. 대신 다음 프로세스를 사용합니다.
  1. Windows PE 2.0 부팅 CD에 bootsect.exe 및 bcdedit.exe 파일이 포함되도록 합니다. 이 두 파일은 Windows Vista 설치 DVD에 있습니다.
  2. Windows XP 시스템을 Windows PE 2.0 CD로 부팅합니다.
  3. 부팅되면 다음 명령을 실행합니다.
    bootsect.exe /NT60 ALL
그러면 부팅 섹터가 bootmgr을 시작할 수 있는 Windows Vista 호환 부팅 섹터로 설정됩니다.
4. 부팅 관리자를 하드 디스크에 복사합니다.
    xcopy BOOTMGR C:\BOOTMGR /I
5. 하드 디스크의 \BOOT 디렉터리에 boot.SDI 파일을 복사합니다. Windows PE를 실행하는 동안에는 잠겨서 복사할 수 없게 되므로 부팅하기 전에 이 파일의 복사본을 만들어야 합니다.
    xcopy BOOT.SDI C:\BOOT\
원본 경로를 적절하게 수정합니다.
6. 하드 디스크에 boot.WIM을 복사합니다. 실행 중인 동안에는 파일을 복사할 수 없으므로 SDI와 마찬가지로 여분의 복사본을 준비해야 합니다.
    xcopy BOOT.WIM C:\BOOT\BOOT.WIM
원본 경로를 적절하게 수정합니다.
7. 이제 BCD 저장소를 만듭니다.
    bcdedit /createstore
8. 다음으로 Windows PE를 로드할 BCD 항목을 만듭니다.
    bcdedit /create {ramdiskoptions} /d
    "Boot Windows PE"
    bcdedit /set {ramdiskoptions}
    ramdisksdidevice partition=c:
    bcdedit /set {ramdiskoptions}
    ramdisksdipath \boot\boot.sdi
    bcdedit /create /d "Windows PE" /
    application
    OSLOADER
9. 마지막 줄에서 GUID가 반환됩니다. {YOURGUID}를 반환된 실제 GUID로 바꿉니다. 이는 그림 4와 같이 하드 디스크에서 Windows PE를 부팅하는 RAMDisk에 추가할 항목입니다.
Figure 4 하드 디스크에서 Windows PE를 부팅하는 RAMDisk에 추가될 항목 (Close Figure 4)
bcdedit /set {YOURGUID} device ramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} path \windows\system32\winload.exe
bcdedit /{YOURGUID} osdeviceramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} systemroot \windows
bcdedit /set{YOURGUID} winpe yes
bcdedit /set {YOURGUID} detecthal yes
10. 부팅 관리자가 시작되도록 bootmgr 항목을 만듭니다.
    bcdedit /create {bootmgr} /d
    "Boot Manager"
    bcdedit /set {bootmgr} device boot
11. 마지막으로, 기존 Windows 설치에 대한 BCD 항목을 설정합니다. 여기에서 "Windows XP" 부분은 부팅 관리자 부팅 메뉴에 표시하고자 하는 텍스트로 변경합니다. 마지막 명령은 이 항목이 부팅 메뉴의 첫 번째(기본) 항목이 되도록 설정하는 명령입니다.
    bcdedit /create {ntldr} /d "Windows XP"
    bcdedit /set {ntldr} device partition=C:
    bcdedit /set {ntldr} path \ntldr
    bcdedit /displayorder {ntldr} /addfirst
12. 이제 시스템을 다시 시작하면 적절한 부팅 메뉴 항목을 선택하여 Windows의 이전 설치 또는 Windows PE 2.0을 시작할 수 있습니다. 그림 5에서 bcdedit /enum all의 샘플 출력을 볼 수 있습니다. 이 명령을 실행하면 항목이 추가된 후 BCD에 포함되어 있는 모든 항목이 나열됩니다. 이 명령은 Windows PE 1.6의 명령입니다.
샘플 입력
필자는 이 작업을 자동으로 수행할 수 있는 스크립트를 작성하고 있습니다. 현재 이 스크립트는 부팅 파일을 하드 디스크에 복사하고 BCD 항목을 설정하는 프로세스만 수행할 수 있고, Windows를 실행하는 동안 부팅 섹터를 새 Windows Server 2008 값으로 설정할 수는 없습니다. 이 설정 과정은 Windows PE에서 오프라인으로 수행해야 합니다. 이 스크립트는 TechNet Magazine 웹 사이트(technetmagazine.com)의 코드 다운로드 섹션에서 다운로드할 수 있습니다. 스크립트를 실행하려면 현재 실행 중인 VBScript와 같은 디렉터리에 다음 항목이 있어야 합니다.
  1. BCDEdit
  2. BOOTMGR
  3. Windows Vista 또는 Windows PE 2.0 미디어의 \BOOT\ 디렉터리
  4. 유효한 부팅 가능 Windows PE 2.0 BOOT.WIM 파일이 있는 \SOURCES\ 디렉터리
이 스크립트는 BCD를 만들고 적절한 부팅 파일을 복사합니다. Windows PE로 부팅하고 bootsect를 실행한 후에는 이중 부팅할 수 있습니다.

이중 부팅 취소
이중 부팅 취소는 이중 부팅을 사용하도록 설정하는 것보다 쉽습니다. 다음 명령을 실행하여 부팅 섹터를 Windows Vista 이전의 부팅 섹터로 복원하기만 하면 됩니다.
bootsect.exe /NT52 ALL
복원된 뒤 bootmgr과 \boot 디렉터리를 삭제할 수 있습니다. 다음에 다시 부팅할 때 부팅 섹터는 강제로 ntldr이 시작되도록 하고 Windows PE 2.0과 모든 Windows Vista 부팅 이진 파일을 부팅 흐름에서 완전히 제거합니다.

Wes Miller는 텍사스 오스틴 소재 Initiate Systems(InitiateSystems.com)에서 기술 제품 관리자로 근무하고 있습니다. 이전에는 Winternals Software에서 Microsoft 프로그램 관리자로 근무했습니다. 문의 사항이 있으신 분은 technet@getwired.com으로 연락하시기 바랍니다.


 Field Notes: PC 기증
Field Notes
PC 기증
Jim Lynch

컴퓨터를 폐기하는 가장 효율적인 방법으로서 여러 해 동안 통용되어 온 일반적인 상식들을 가장 잘 정리해 놓은 책은 The Gartner Group의 Frances O'Brien이 2003년 출간한 "PC Disposal: TCO's Last Surprise"입니다. 여러 PC 폐기 방법을 비교 분석한 이 책에서는 장비를 기증하는 것은 기증을 받을 의지가 있는 적절한 자선 기관을 찾는 데 너무 많은 시간이 걸리기 때문에 (6가지 폐기 방법 중) 가장 많은 비용이 소요되는 방법임을 밝혀냈습니다.
기증의 요령
TechSoup.org에서는 이 외에도 기증 요령을 추가로 제공하고 있으며 techsoup.org/recycle에서도 기증을 받고 있습니다. 기증하기 전에 고려해야 할 몇 가지 사항은 다음과 같습니다.
  • 새 하드웨어로 업그레이드한 후에는 기존 IT 장비를 처분하십시오. 컴퓨터 장비는 5년 후에는 재활용 가치를 잃게 됩니다. 마찬가지로, 휴대폰도 일반적으로 3년이 지나면 사용 수명이 끝납니다.
  • 5년이 안 된 IT 장비는 비영리 단체나 학교에 곧바로 기증하지 마시고 재생기관에 기증하십시오.
  • 장비는 물론, 장비와 함께 제공된 키보드, 마우스, 프린터, 모뎀, 소프트웨어 디스크, 사용 설명서 등 주변 기기를 함께 포장하십시오.
  • 기증 내용을 목록으로 기록하여 보관하고 영수증을 받으십시오. 비영리 재생기관에 기증하면 세금 감면을 받을 수 있습니다. 미국에서는 기업 기증자의 경우는 컴퓨터의 미상각 잔존 가치에 대해 과세를 면제받을 수 있으며, 개인 기증자의 경우는 컴퓨터의 현 시가에 대해 과세를 면제받을 수 있습니다. 컴퓨터의 적정 시가를 알아보려면 캐나다에서 무료로 운영되고 있는 Used Computer Evaluator(servlets.edeal.com/servlets/PcEval)를 참조하십시오.

오늘날에는 상황이 완전히 달라졌습니다. 미국 EPA에서는 최근 오래된 하드웨어의 재활용을 준비하는 방법을 사용자들에게 교육하고 관련 자료 목록을 제공하는 "Do the PC Thing"이라는 캠페인에 착수했습니다. 이 캠페인은 EPA의 전자제품 재활용 및 재사용 인식 증대 운동 사이트인 Plug-In To eCycling(epa.gov/plugin/)의 일환입니다. "Reuse It!" 링크를 클릭하면 소비자나 기업을 대상으로 하는 자료를 확인하실 수 있습니다.
이 사이트에서 하드웨어 기증 또는 재활용과 관련된 가장 중요한 쟁점은 바로 여러분 자신을 보호하는 것이라는 것을 깨닫게 되실 것입니다. "Do the PC Thing"의 문헌 자료들은 하드 드라이브 청소와 데이터 보안 및 기밀 유지 관련 법적 요건에 대한 기본적인 지침을 제공합니다. 컴퓨터 처분의 목적이 사용 수명 종료로 인한 재활용이든 재생을 통한 재사용이든, 암호, 문서, 신용카드 정보, 전자 메일 메시지, 웹 로그 등의 민감한 데이터는 반드시 삭제해야 합니다.
대부분의 전자제품 재활용업체, 재생기관 및 자산관리업체에서는 하드 드라이브를 파기하거나 데이터 복구가 불가능하도록 덮어쓰는 디스크 청소 소프트웨어 유틸리티를 사용함으로써 데이터 보안 서비스를 제공하고 있습니다. 컴퓨터에 재활용 마크가 붙어 있으면 컴퓨터 하드웨어를 그대로 보존하는 것이 좋습니다.
평판이 좋은 디스크 청소 소프트웨어의 경우는 미국방성의 5220.22-M 규격을 사용합니다. 이러한 유형의 소프트웨어 기반 데이터 청소 유틸리티는 하드 드라이브에서 주소를 지정할수 있는 모든 위치를 하나의 문자로 덮어쓰고 그 상태를 확인한 다음 주소를 지정할 수 있는 모든 위치를 여러 개의 임의의 문자로 다시 한번 덮어씁니다. 2004년 미국의 국가안보국(NSA Advisory LAA-006-2004)에서는 전자 파일을 복구 불가능하게 만드는 데에는 미국방성 표준 소프트웨어를 일회 사용하는 것으로 충분하다는 사실을 밝혀냈습니다.
그리고 현재는 개인 데이터 삭제에 활용해도 좋을 만큼 사용법이 쉬워졌습니다. Active@ Kill Disk Hard Drive Eraser(killdisk.com/eraser.htm)나 Darik's Boot and Nuke(dban.sourceforge.net) 등과 같이 평판이 좋은 무료 응용 프로그램도 있습니다. 데이터 삭제가 필요한 컴퓨터가 여러 대면 Blancco Data Cleaner(blancco.com)나 WipeDrive(whitecanyon.com) 등과 같이 좀 더 강력한 기능의 상용 응용 프로그램을 고려해 보십시오.
IT 장비가 5년이 넘었거나 심하게 파손되었으면 Gartner에서 제안하는 6가지 처분 방법 중 하나인 사용 수명 종료에 따른 전자제품 재활용 방법을 따르십시오. 현재 미국에는 관련 업무를 처리하는 기업이 900곳이 넘습니다. 오래된 IT 장비를 올바르게 재활용하려면 Electronic TakeBack Coalition에서 선정한 신뢰할 수 있는 재활용업체 목록(www.computertakeback.com/the_solutions/recyclers_map.cfm)을 참조하시기 바랍니다.

Jim Lynch는 San Francisco에 소재한 TechSoup.org라는 하이테크 비영리 단체에서 컴퓨터 재활용 및 재사용 부문 프로그램 관리자를 맡아 전 세계 자선 단체에 초저가 하드웨어, 소프트웨어 및 노하우를 제공하고 있습니다.


 Windows Confidential: 스크랩의 퇴출
Windows Confidential
스크랩의 퇴출
Raymond Chen

자주 있는 일은 아니지만 오래된 기능들은 종종 제품 팀의 박수를 받으며 사라지곤 합니다. 예를 들어 Windows® XP에서는 바탕 화면 무늬를 설정하기 위한 인터페이스가 제거되었습니다. 기본 기능은 여전히 제공되므로 SystemParametersInfo(SPI_SETDESKPATTERN)를 호출하는 프로그램을 작성할 수만 있다면 사용 가능하지만 이를 위한 인터페이스는 더 이상 기본으로 제공되지 않습니다. 그렇다면 왜 바탕 화면 무늬가 바탕 화면 제어판에서 사라졌을까요?
자체 조사에 따르면 바탕 화면 무늬는 실제로 아무도 사용하지 않는 것으로 나타났습니다. 이 기능은 메모리 가격이 비싸서 1MB 용량의 배경 무늬 비트맵에 시스템 메모리의 1/4이나 할애하는 것을 사용자들이 원하지 않았을 때 인기가 있었습니다. 8×8의 작은 단색 무늬를 화면에 반복하여 표시하면 훨씬 저렴한 비용으로 640×480 디스플레이에 어느 정도의 개성 있는 화면을 꾸밀 수 있었습니다.
하지만 시간이 지날수록 바탕 화면 무늬의 장점이 사라졌습니다. 그 첫 번째 이유는 1983년에 비해 컴퓨터에 장착되는 메모리의 양이 크게 늘어났다는 점입니다. 두 번째 이유는 당연하게도 모니터 해상도가 과거에 비해 훨씬 높아졌다는 점입니다. 8×8 크기의 작은 격자 무늬는 1600×1200 모니터에 표시하면 작은 회색 얼룩에 지나지 않습니다.
더 이상 사용되지 않는 오래된 기능은 이뿐만이 아닙니다. 또 다른 예가 스크랩입니다. Windows 95에 도입된 스크랩은 파일로 캡처된 문서 조각 형태입니다. 이 파일 조각은 실제로는 OLE 개체입니다. 스크랩의 기본 개념은 워드 프로세서에서 특정 텍스트를 강조 표시한 다음 이를 바탕 화면으로 끌어서 스크랩을 만든다는 것입니다. 나중에 이 스크랩을 다시 워드 프로세서나 다른 프로그램으로 끌어다 놓으면 스크랩을 만드는 데 사용되었던 텍스트가 새 문서에 삽입됩니다. 이 기능은 데이터가 클립보드에 임시로 저장되는 대신 파일에 저장된다는 점을 제외하면 복사하고 붙여 넣는 것과 비슷합니다.
이렇게 스크랩 파일을 만든 후 실제로 이 파일로 수행하는 유일한 작업은 스크랩을 다른 문서로 끌어서 놓는 것이었습니다. 마치 클립보드의 내용으로 실제 수행할 수 있는 유일한 작업이 해당 내용을 다른 곳에 붙여 넣는 작업뿐인 것과 마찬가지입니다. 그 후로, 스크랩 파일을 두 번 클릭하면 스크랩을 만들 때 사용했던 응용 프로그램에서 해당 스크랩이 열리도록 하는 기능이 추가되었습니다. 사실 내용에는 제한이 없었으므로 스크랩을 표시하는 유일한 방법은 해당 스크랩을 처음 만든 프로그램에서 표시하는 것이었습니다.
이 기능이 디버깅 도구로 추가되었는지, 아니면 사용자가 임시 문서를 만들고 이 문서에 스크랩을 끌어서 놓지 않고도 스크랩 내용을 볼 수 있도록 하기 위해 추가되었는지는 모릅니다. 의도가 어떻든 바이러스 작성자들은 이 기능을 통해 스크랩 파일을 만들고 그 안에 "원본 응용 프로그램은 cmd.exe이고 문서 조각은 이 배치 파일"이라고 지시하는 데이터를 채우는 것이 가능했기 때문에 "스크랩을 처음 만들었던 응용 프로그램을 여는" 기능을 좋아했습니다. 누군가가 특정 스크랩 파일의 내용을 보기 위해 파일을 두 번 클릭하면 스크랩 뷰어는 배치 파일을 명령 처리기에 전달하고 "이 파일을 열고 사용자에게 표시"하도록 지시합니다.
셸 팀에서는 Windows Vista®에서 이 기능을 제거했습니다. 이를 위해 셸 팀에서는 스크랩이 실제 사용 환경에서 얼마나 많이 사용되는지 조사해야 했습니다. 그래서 셸 팀에서는 스크랩과 관련된 질문을 한 사용자가 얼마나 많았는지 알아봐 달라고 제품 지원 그룹에 요청했습니다. 인기가 많은 기능은 지원 요청이 많고 인기가 없는 기능은 사용하는 사람이 없으므로 지원 요청이 없기 때문입니다. 스크랩이 "매우 직관적인" 기능 범주에 속하는 것은 아니므로 지원 요청 전화의 횟수가 적다는 것이 결코 "기능이 매우 간단해서 지원을 요청할 필요가 없음"을 의미하는 것은 아닐 것입니다.
제품 지원 그룹의 답변에 따르면 지난 몇 년 동안 제품 지원 그룹에서는 총 네 건의 지원 요청을 받았습니다. 그리고 그 질문은 모두 "이상한 파일이 만들어졌는데, 이 파일이 무엇이며 어떻게 없앨 수 있습니까?"라는 것이었습니다.

Raymond Chen은 The Old New Thing 웹 사이트와 동명의 저서(Addison-Wesley, 2007)에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있습니다. 이 기사를 통해 오랜만에 독자들에게 인사합니다.