 TechNet Magazine October 2007

TechNet Magazine October 2007

Green Computing: 그린 데이터 센터 구축

세계적으로 많은 기업들이 에너지와 비용 절감 방법을 고민하기 시작했지만 이를 위해 실천할 수 있는 지침은 거의 없는 실정입니다. 우선, 저희가 소개하는 조직에서의 그린 데이터 센터 계획, 설계 및 구현에 관한 설명을 참고하시기 바랍니다.

Dave Ohara Windows Administration: Active Directory 복제 가이드

Active Directory에서는 대규모 또는 분산된 환경을 지원하기 위한 풍부한 유연성을 제공하지만 데이터 무결성 유지 관리는 어려운 문제일 수 있습니다. Active Directory 복제는 환경 전체에서 업데이트를 주고받는 방법과 충돌을 해결하는 방법을 정의합니다. 여기에는 이런 문제를 해결하기 위해 알아야 할 내용이 나와 있습니다.

Laura E. Hunter System Center: 새로운 소프트웨어 업데이트 관리 도구

System Center Configuration Manager 2007은 각 클라이언트에서 규정 준수 및 정책 적용을 보다 효과적으로 보장할 수 있는 방식으로 업데이트 관리를 처리하는 완전히 새로운 메커니즘을 제공합니다. 이 향상된 기술이 컴퓨터를 최신으로 유지하는 데 효과적인 이유를 알아봅니다.

Steve Rachui Communications: Microsoft의 Exchange Edge 전송 서버

Microsoft에서는 자사 직원들에게 합법적인 메시지만 전달되도록 하고 악의적 콘텐츠가 조직의 메시징 환경에 침투하지 못하도록 하기 위해 어떠한 노력을 기울이고 있을까요? 한 가지 방법으로 Exchange Server 2007 Edge 전송 서버와 Forefront Security for Exchange Server를 배포하는 것이 있습니다. 이 기사를 통해 이러한 기술이 조직을 안전하게 보호하는 데 어떤 도움을 줄 수 있는지 알아보십시오.

Kay Unkroth SQL Server: SQL Server CPU 성능 최적화

데이터베이스 서버의 CPU 사용률을 적정 수준으로 유지하기 위해서는 CPU가 최적화되지 않은 코드나 느린 하드웨어에서 프로세서 주기를 낭비하는 대신 사용자가 원하는 작업을 처리하는 데 시간을 할애하도록 하는 것이 필수입니다. 여기에서는 SQL Server와 하드웨어를 최대한 활용하는 데 도움이 되는 몇 가지 팁을 제공합니다.

Zach Nichter From the Editor: 최고를 향한 끝없는 도전

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

Greg Steen SQL Q&A: 로그인 트리거, 데이터 파일 조각 모음 외

Edited by Nancy Michell Utility Spotlight: Virtual Machine Remote Control Plus

Matthijs ten Seldam The Business of IT: 정부 부문 IT 인프라 가치 평가

Acer Maamoun The Cable Guy: 인증된 인터넷 프로토콜

Joseph Davies Windows PowerShell: 스크립트가 필요 없는 작업

Don Jones Hey, Scripting Guy!: Silverlight가 있으라!

The Microsoft Scripting Guys Security Watch: BitLocker와 신뢰의 복잡성

Justin Troutman The Desktop Files: 고급 사용자를 위한 WIM 및 ImageX 가이드

Wes Miller Field Notes: PC 재활용

Jim Lynch Windows Confidential: Dr. Watson 호출

Raymond Chen


 Green Computing: 그린 데이터 센터 구축
Green Computing Dave Ohara

그린 데이터 센터 구축
한 눈에 보기:
  • 에너지 모니터링 시스템
  • 그린 데이터 센터의 기본적 특징
  • H.R. 5646의 영향
  • 시작을 위한 모범 지침

그린은 근래 상당히 많이 논의되고 있는 화제이며, 그 개념은 데이터 센터에 대한 사람들의 사고 방식에 영향을 미치고 있습니다. 세계의 여러 기업들이 새로운 하드웨어와 서비스의 구입을 통해 비용과 에너지를 절약하는 방법들을
발표하고 있습니다. 그러나 에너지 비용 절감을 위해 실천할 수 있는 지침은 거의 없습니다. 과거, 전력 비용은 공간 비용처럼 간접 비용으로 간주되었습니다. 그러나 전력 비용이 점점 늘어나고 안정성, 공급, 용량 등과 관련된 문제가 커짐에 따라 이제는 전력에 대한 독자적인 접근이 필요한 상황입니다.
비즈니스의 거의 모든 영역에서 성능 최적화 및 비용 절감과 관련된 프로젝트가 일반적인 모범 관례의 일부로 자리 잡았습니다. 그렇다면 에너지 비용도 같은 방식으로 취급해야 하지 않을까요?
우리 같은 IT 전문가들은 대부분 서버 구성 및 설정, 조직에서 구입하는 장비의 사양, 데이터 센터 증설 및 신설 요건 등과 관련된 의사 결정을 수행합니다. 응용 프로그램 개발 과정에서도 초기 설계 단계에 의견을 내기도 합니다. 이러한 프로젝트에 관한 한, 우리는 에너지 절약 원칙에 입각하여 모든 데이터 센터의 에너지 효율성에 영향을 미칠 수 있는 훌륭한 기회를 보유하고 있습니다.
이와 관련된 모든 전략의 첫 단계는 현재의 에너지 사용량을 파악하는 것입니다. 에너지가 어느 용도에, 그리고 어느 장비에 사용되는지 알아야 할 뿐만 아니라 데이터 센터 내에서 어떻게 사용하는 것이 효율적이며 어떤 경우에 에너지 낭비가 큰지 알아야 합니다. 안타깝게도 에너지 절약 조치의 결과까지 알 수 있는 수준으로 사용량을 자세히 분석할 수 있는 전력 소비 측정은 매우 드문 형편입니다. 대부분의 조직에서는 전체 사용량을 보여주는 월별 전기 요금 청구서만 살펴보는 것이 일반적입니다. 이러한 방식으로는 직원들 개인이 자신이 에너지 절약을 위해 판단해 수행한 조치의 결과를 확인할 수 없으므로 에너지 절약을 위한 동기를 제대로 부여할 수 없으며, 자신의 행동 변화가 실제로 에너지를 절약했는지 증명할 방법이 없습니다.
그린 데이터 센터 이니셔티브를 고려할 때 가장 먼저 떠오르는 문제 중 하나는 경영진의 지원 여부입니다. 이 기사에서는 경영진의 지원이 "아직은 없는 것"으로 간주하겠습니다. 경영진의 지원이란 그린 이니셔티브에 필요한 자원과 예산을 제공하겠다는 진지한 약속을 의미합니다. 그린 데이터 센터에 대한 논의는 상당히 많은 편이나 경영진 수준에서 진지한 지원이 이루어지는 경우는 여전히 드문 것이 현실입니다. 그리고 그와 같은 경영진의 지원을 받고 있는 경우라면 이미 그린 데이터 센터가 제대로 운영되고 있을 것입니다.
그러나 필요한 지원이 없다 하더라도 그린 데이터 센터 이니셔티브의 추진을 위해 할 수 있는 일은 아주 많습니다. 그러면, 어떤 행동이 그린 데이터 센터 목표 실현에 효과적인지 어떻게 알 수 있을까요? 다행히, 에너지 효율성은 새로운 개념이 아니므로 IT 전문가는 다른 업계에서 여러 가지 유용한 정보를 얻을 수 있습니다.

에너지 소비량 정리
이 주제로 기사를 작성하면서 가장 큰 어려움 중 하나는 여러 출처에서 제공된 수치들의 편차가 워낙 커서 그것을 어떻게 풀어나가야 할 것이냐 하는 문제였습니다. 어떤 조사에서는 데이터 센터가 미국에서 소비되는 전력의 1.2~2.0%를 소비하는 것으로 나타났습니다. 또 어떤 조사에서는 데이터 센터 그 자체를 하나의 업계로 볼 경우, 미국 데이터 센터의 에너지 사용량이 전체 업계 중 최상위 5개 업계에 근접하는 것으로 나타났습니다. 또한, 다른 조사에서는 미국 대기업 데이터 센터에서의 전력 요금이 전체 운영 비용의 15~20%를 차지할 수 있는 것으로 나타났습니다.
미국 에너지 효율 경제 위원회(American Council for an Energy-Efficient Economy, ACEEE)의 의뢰로 국립 로렌스 버클리 연구소(Lawrence Berkeley National Laboratories)에서 수행한 조사에서는 데이터 센터의 에너지 사용량이 일반 사무용 건물의 40배에 이를 수 있는 것으로 파악되었습니다. 이 조사는 설비의 관점에서 에너지 효율 증대를 위해 수행할 수 있는 조치에 대해 자세히 소개하고 있습니다(eetd.lbl.gov/emills/PUBS/PDF/ACEEE-datacenters.pdf). 우선, 이 조사에서 소개하는 모범 지침을 여러분의 데이터 센터에서 어느 정도 실천하고 있는지 알아보는 것도 좋은 출발점이 될 것입니다.
의심할 여지없이, 전력 소비량에 관해서는 수없이 다양한 의견과 조사, 수치 결과가 존재합니다. 그러나 한 가지 일관된 결론은 낭비의 폭이 매우 크다는 것입니다. 가용 재원으로 효과를 극대화하기 위해서 얼마나 많은 서버 구매가 이루어져 왔는지 생각해보십시오. 즉, 여러분은 예산을 넘지 않는 범위 내에서 CPU 파워, 메모리, 스토리지, 예비용 전원 공급 장치를 최대한 구입해왔습니다. 그런데 그러한 서버들의 사용률은 지난 3~5년간 평균 10~15%에 불과합니다. 사람들은 CPU에 주로 신경 쓰는 경우가 많지만 전력 소비량에서는 다른 구성 요소들도 큰 비중을 차지합니다. 메모리, 디스크, 네트워크 인터페이스 등은 각기 상당한 전력을 소비하며 이들의 소비량을 합산하면 CPU의 전력 소비량을 넘어섭니다.
프로세서에서부터 예비용 전력 공급 장치까지, 지나친 하드웨어 설비는 상당한 비용 낭비를 초래할 수 있습니다. 대부분 IT 부서의 안전 제일 주의 분위기를 감안할 때 초과 설비는 일반적입니다. 초과 하드웨어 설비가 재정적으로는 최선의 결정이 아닐지라도 가장 안전한 결정일 수 있습니다. 그러나 수명 주기 비용을 계산할 때 에너지는 매우 중요한 요소임에도 불구하고 간과되는 경우가 많습니다. 유감스럽게도, 의사 결정권자의 입장에서는 배포 후 비용상의 이점이 없으므로 에너지 효율적인 솔루션을 구입할 필요가 없기 때문입니다.
그러나 에너지 효율적인 솔루션으로 방향을 바꿔 나가는 것이 필요합니다. 경영진들이 데이터 센터의 실제 하드웨어 가동률이 얼마나 낮은지 깨닫고, 서버 통합을 비용 절감의 한 가지 방법으로 고려하게 되면 에너지 효율적인 솔루션을 적절히 구입하는 쪽으로 의견이 기울어지게 되어 있습니다. 이미 배포된 후에 서버를 통합하는 것보다는 미리 서버의 규모를 적절히 계산하는 것이 훨씬 쉽습니다.
IT 업계가 한 단계 발전하여 새로운 국면을 맞이하면서 비용 절감을 감안한 최적화가 중요한 과제로 떠오르고 있습니다. 에너지 소비량은 경영진에서 IT 하드웨어의 수명 주기를 감안하여 수행된 의사 결정의 효과를 가늠할 수 있는 하나의 지표입니다. AMD와 Intel을 비롯한 서버 및 구성 요소 OEM 업체들은 모두 자사 플랫폼의 전력(와트) 대비 성능 효율 수치를 참조용으로 발표하고 있습니다. 이 전력 대비 성능 효율 수치를 역으로, 즉 단위 성능 대비 전력량으로 환산하면 운영 비용을 계산할 수 있습니다. 설비, 응용 프로그램 개발, 설계, 운영, 사업부 등 IT 솔루션 개발 과정에 관여하는 여러 사람들은 전력 대비 성능이라는 개념을 통해 "자신이 수행하는 조치의 결과"를 확인하고 여러 솔루션의 에너지 효율성을 비교할 수 있습니다.
에너지 비용을 무시하고 의사 결정이 운영 비용과 설비 비용에 미치는 영향을 간과하는 관행이 왜 일반화된 것일까요? 전력 및 과열 방지 관련 제약으로 인해 처리 능력을 제대로 활용하지 못하는 데이터 센터가 얼마나 많습니까? 데이터 센터에 충분한 물리적 공간을 확보하는 것이 문제였던 시절이 있었습니다. 그러나 오늘날에는 모든 장비에 전력을 공급하고 냉각할 수 있는 충분한 용량이 있는지, 그리고 이러한 용량으로 언제까지 충분하게 사용할 수 있을 것인지가 문제입니다.

에너지 모니터링 시스템의 중요성
에너지 소비량의 정확한 측정은 쉽지 않은 문제가 될 수 있습니다. 앞서 언급했듯이 대부분의 기업에서는 에너지 비용을 총량적으로 합산해서 평가하지 특정 기기별 전력 소비량을 자세히 분석하지 않습니다. 이처럼 전력을 일반 간접 비용으로 간주하는 관행은 사업부에서는 에너지 비용을 통제할 수 없다는 인식을 낳습니다. 그러나 그것은 사실이 아닙니다.
데이터 센터의 1제곱미터당 전력 소비량은 일반 사무실의 10배에 이를 수 있으므로, 소폭의 효율성 향상으로도 상당한 비용을 절약할 수 있습니다. 데이터 센터에서 에너지 절약 프로그램을 구현하는 주된 이유는 물론 비용 절감입니다. 문제는 에너지 소비량에 대한 비용을 결정하는 데는 최저 비용 방식이 일반적으로 사용되고 데이터 센터 운영을 위한 월별 설비 비용은 합산된다는 점입니다. 그리고 각 그룹의 점유 공간 및 포트 연결에 따라 비용이 할당됩니다. 이 방법으로는 데이터 센터의 각 장비 운영에 필요한 자세한 비용 내역을 정확히 측정하기가 매우 어렵습니다.
데이터 센터의 각 장치별로 실제 전력 사용량을 측정할 수 있는 솔루션을 갖춘 조직은 거의 없습니다. 그 이유는 대체로 에너지 측정 및 보고 시스템을 갖추기 위해서는 상당한 초기 투자가 필요하기 때문입니다. 그러나 이러한 시스템에 투자하면 장기적으로 상당한 비용 절감 효과를 얻을 수 있습니다.
물론 전력 사용량 모니터링 시스템만으로는 충분하지 않으며, 수집된 데이터를 활용하여 에너지 소비량을 더욱 효과적으로 관리하고 궁극적으로 투자 수익을 실현할 수 있는 계획이 필요할 것입니다. 세계 최대의 신문 및 종이 제품 생산 기업인 캐나다의 Abitibi Consolidated의 사례를 보겠습니다. 2001년 온타리오 전력 시장의 규제가 완화되면서 Abitibi Consolidated는 불안정한 시장 가격 및 공급이라는 문제에 직면했습니다. 이 회사는 에너지 구매를 최적화하기 위해 모니터링 및 측정 시스템을 구현했습니다. 이 새로운 시스템은 단지 에너지를 더 효율적으로 구입하여 1%의 절약을 실현한 것만으로 불과 몇 개월 만에 제값을 해냈습니다.
여러분의 데이터 센터에서 에너지 모니터링 시스템 구축 비용의 재정적 근거를 확보하려면 어느 정도의 에너지 절감이 필요합니까? Microsoft에서 Windows Server® 2008 개발 작업을 총괄하고 있는 Bill Laing은 최근 인터뷰에서 새로운 Windows Server 버전을 사용하면 기본 설정된 에너지 절약 기능을 통해 에너지 소비량을 최대 20%까지 줄일 수 있다고 언급했습니다. 상당한 절감 폭이 아닐 수 없습니다. (그림 1에는 Windows Server 2008 베타 3의 Power Options(전원 옵션) 일부가 나와 있습니다.) 그러나 이러한 절감 폭은 실제 절약되는 전력 비용과는 다를 수 있음을 유의하십시오. 여기에는 새로운 데이터 센터 구축 비용과 현재 효율성이 떨어지는 구성을 지원하는 다른 시스템의 수 등 영향을 미치는 여러 가지 다른 요소들이 있습니다.
그림 1 Windows Server 2008 베타 3의 Power Options(전원 옵션)
그림 1 Windows Server 2008 베타 3의 Power Options(전원 옵션)
지금 당장으로서는 Windows Server 2003 SP1의 서버 조정 프로세서 전원 및 성능 옵션을 선택할 수 있습니다. 그러나 별도의 측정 시스템이 없다면 절감 폭 또는 이러한 변화의 수행 및 지원과 관련된 기타 요소들을 수치화할 수 없을 것입니다.
또한 대부분의 데이터 센터에서 24시간 동안 전력 소비량 변동 폭이 일반적으로 4%에 불과하다는 점도 주목할 만합니다. 이것은 전력 소비량이 작업 부하량과 큰 관련이 없다는 것을 의미합니다. 최근 하드웨어 공급업체들이 기술을 혁신하면서 새로운 장비에서는 이러한 결과가 바뀌어 작업 부하가 적을수록 전력 소비량도 감소합니다.

그린 데이터 센터의 정의
그린 데이터 센터의 특징과 기준을 나열하는 것만으로도 여러 페이지를 채울 수 있을 것입니다. 물론 분량상 이 기사에서 모든 내용을 다룰 수는 없으므로 그린 데이터 센터 구현을 진지하게 생각하고 있다면 반드시 기억해야 할 중요한 특징 몇 가지만 짚고 넘어가고자 합니다. 아직 계획 단계에 머물러 있다 하더라도 현재 여러분의 데이터 센터가 어느 정도 수준에 있는지 이 목록을 통해 측정할 수 있을 것입니다.
  1. 측정 도구를 사용하여 2U 서버, 4U 서버, 스위치, SAN, UPS 등 구성 요소 수준의 에너지 사용 내역을 측정하고 각 구성 요소에서 소비되는 전력을 어느 사업부에서 사용한 것인지 파악합니다.
  2. 에너지 사용 내역을 항상 모니터링하여 에너지 최대 요구량과 최소 요구량을 파악합니다.
  3. 전체 데이터 센터 수준에서 개별 회로 수준까지 에너지 용량을 모니터링하여 모든 회로가 수용 가능한 한계 안에서 작동하고 있는지 확인합니다.
  4. 에너지 절약 계획이 문서화되어 있으며 적절한 보상이 제공됩니다.
  5. 에너지 절약 계획을 정기적으로 검토하여 미비점이 있을 경우 시정 조치를 취합니다.
  6. 사업부별로 어느 정도의 비용이 유발되는지 파악하여 사업부들 사이에서의 에너지 절약 활동을 독려하는 분위기를 조성합니다. 이 사항은 경영진 수준에서 추진되어야 합니다.
  7. 서버에서 CPU 제한 기능을 사용하며 성능 실험실에서 다양한 작업 부하에 따른 전력 소비 범위를 측정합니다.
  8. 온도 관련 정보를 수집하여 과열 지점과 과냉 지점을 파악합니다.
  9. IT 성능 공학에 에너지 효율성 측정을 포함합니다.
  10. 실시간 데이터에 대한 피드백을 개별 조직에 제공하여 이들이 적절히 대응할 수 있도록 합니다. California ISO에서는 그림 2와 같이 자사 웹사이트에 실시간 데이터를 공개할 정도입니다.
그림 2 California ISO 웹사이트에서는 고객이 요구하는 현재 절약 수준과 현재 요구량 등이 포함된 정보를 실시간 스냅숏으로 제공하고 있습니다.
그림 2 California ISO 웹사이트에서는 고객이 요구하는 현재 절약 수준과 현재 요구량 등이 포함된 정보를 실시간 스냅숏으로 제공하고 있습니다.
충족하는 특징이 많을수록 수준 높은 에너지 모니터링 시스템을 운영하고 있다고 볼 수 있습니다. 현재 귀사의 데이터 센터 수준(기초, 중급, 고급)을 판단하는 데 유용한 8개의 질문을 담은 스코어카드(그림 3 참조)도 수록해 두었습니다.
Figure 3 귀사 데이터 센터의 그린(green) 수준은? (Close Figure 3)

수준 | 해당 행동
기초 | 매월 전기 요금 청구서를 검토하십니까?
전기 장비를 정기적으로 점검하여 용량 계획에 반영하십니까?
중간 | 전기 회로의 부하량과 전력 소비량을 자동 측정하여 보고하는 도구를 갖추고 있습니까?
장비 구입 시 에너지 효율성을 확인하십니까?
고급 | 랙, 장치, 회로별로 에너지 소비량을 모니터링하십니까?
시간별 데이터 모니터링 및 보고 결과를 분석하십니까?
부서별 에너지 사용량 실시간 보고 기능을 활용하여 변경 및 배포가 미치는 영향을 파악하고 있습니까?
데이터를 활용하여 전기 회사와 유리한 조건의 전기 요금제를 협의하고 있습니까?

문제 해결의 절반인 정보 수집
또 다른 문제는 조직 전체의 표준화를 이루는 것입니다. 이 기사에서 언급한 변화, 즉 에너지 측정 패러다임을 바꾸는 변화와 조직 전체 사업부의 참여와 관련된 변화를 위해서는 여러 데이터 센터에서 폭넓은 범위의 IT 그룹과 작업하는 설비 그룹 간의 조정이 필요합니다. 이러한 조직적 문제는 에너지 절약 프로그램이 제대로 작동하는 데 가장 큰 방해 요소입니다.
데이터 센터 전역의 전력 소비 상황 파악 업무를 1인 또는 1개 팀이 담당하도록 하는 것이 중요합니다. 전력 소비와 관련해서는 대부분의 기업이 이를 간과하고 있지만 이러한 정보를 한곳에서 관리하는 것이 필수적입니다. 다양한 설비의 데이터를 하나의 방식으로 수집하여 그 결과를 다시 각 사업부에 일관된 방식으로 보고하는 도구를 갖추는 것도 중요합니다. 그림 4에는 데이터 보고 대시보드의 샘플이 나와 있습니다.
그림 4 전역 데이터 모니터링 대시보드 샘플(OSIsoft의 승인 하에 수록)
그림 4 전역 데이터 모니터링 대시보드 샘플(OSIsoft의 승인 하에 수록)
올바른 기기와 계기 정보가 없으면 운영이 정말 효율적으로 이루어지고 있는지 알 수 없으며 개별 사업부 역시 자신들의 노력이 성과가 있는 것인지 알 수 없습니다. 사람들의 행동 방식을 바꾸고자 한다면 필요한 정보를 시간에 따른 데이터와 함께 실시간으로 제공하여 자기 행동의 결과를 시각적으로 파악할 수 있게 해야 합니다. 또한 각 사업부에서 각기 다른 시스템과 다른 도구를 사용하고 각기 다른 측정 방식을 통해 자신의 성과를 보고한다면 에너지 효율과 관련된 성과를 효과적으로 보상할 수 없습니다.

업계의 노력
그린 이니셔티브를 추진하는 것은 여러분 혼자가 아닙니다. Boeing, Toyota 등의 기업에서부터 캘리포니아 주정부와 같은 정부 기관까지 여러 시장의 선두 주자들이 조직 운영과 제품의 에너지 효율성을 높이기 위해 상당한 투자를 아끼지 않고 있습니다.
IT 분야의 경우, 2006년 미국 하원에서는 서버 및 데이터 센터의 에너지 비용과 전력 소비량 및 에너지 효율성이 높은 시스템으로의 전환에 따른 잠재적 효과에 대한 조사를 EPA(미환경보호국)에 요구하는 H.R. 5646 법안(현재 공법 109-431)을 통과시켰습니다. EPA 프로그램의 하나인 ENERGY STAR를 통해 수행된 조사에서는 미국 내 컴퓨터 서버와 데이터 센터의 단기적 에너지 사용량 증가를 예측하고, 컴퓨터 서버 및 데이터 센터 에너지 효율성 증대에 따른 잠재적 비용 및 에너지 절약 효과를 측정하고, 에너지 효율적인 컴퓨터 서버와 데이터 센터를 장려할 것으로 예상되는 인센티브와 무상 프로그램을 검토 평가한 바 있습니다. 이 조사의 최종 결과는 2007년 8월 미국 국회에 제출되었습니다. 자세한 내용은 energystar.gov를 참조하십시오.
그린 건물을 위한 새로운 건물 표준도 개발 중입니다. 이 표준에서는 용도와 에너지 소비량에 따라 회로의 전기 사용량을 매시간 계량할 수 있는 계량 능력, 에너지 소비 데이터를 계량기 데이터 관리 시스템으로 전달하는 건물 계량기, 그리고 데이터를 저장하고 연/월/일/시 단위로 계산되는 각 계량기별 에너지 소비량을 보여주는 보고서를 작성할 수 있는 계량기 데이터 관리 시스템 등을 필수 기준으로 요구하고 있습니다. 이러한 기준 가운데 다수는 수행한 변화가 효과가 있음을 입증해야 하는 에너지 절약 프로그램(예: 재생 에너지 크레디트, 탄소 크레디트, 에너지 절약 프로그램 등)에 가입한 경우 그것을 준수하는 시스템에 필수적으로 요구됩니다.
일부 사용자들은 사양 테스트를 요구해왔지만, 그 다양한 용도를 모두 반영하기는 어렵습니다. 테스트를 표준화하기 위한 노력들이 이루어지고 있지만, 다른 대부분의 성능 테스트와 마찬가지로 이러한 테스트들은 실제 사용 상황을 반영하지 않는 '표면적으로만 인식되는' 결과를 최적화하는 데 사용할 수 있습니다. 예를 들어 갤런당 마일 수(MPG)로 측정되는 연비 기준을 생각해봅시다. EPA 측정 방식에서는 MPG를 전형적인 운전자가 전형적인 도시와 도로 조건에서 얻을 수 있는 연비로 계산합니다. 그러나 대부분의 운전자와 주행 환경은 전형적이지 않으며 연료의 효율성에 영향을 미치는 요소들은 매우 다양할 수 있습니다. 이러한 한계는 데이터 센터의 에너지 절약에도 적용됩니다. 정확한 결과는 귀하 조직의 고유 환경에서 에너지 절약 효과를 측정함으로써만 얻을 수 있을 것입니다.

어디서 절약이 가능한가?
절약 효과를 파악할 때는 매우 많은 요소를 고려해야 합니다. 주어진 면적에 공급되는 전력량을 늘릴 경우 소요되는 비용을 알고 있습니까? 전력 제한을 최소화할 수 있는 전략을 갖고 있습니까? 전력 요금이 저렴한 곳에 데이터 센터를 배치함으로써 문제를 해결할 수 있습니까? 아니면 기존 시설의 운영을 개선하는 데 집중해야 할까요?
어떤 기업의 경우에는 전기 요금이 저렴한 지역으로 데이터 센터를 옮기는 것이 비용 절감을 위한 최선의 방법이 될 수도 있습니다. 서버 가상화는 에너지 소비량 절감을 위한 또 다른 방법을 제공합니다. 실제로 일부 전력 회사(일부 예로 PG&E, SoCal Edison, SDG&E 등을 들 수 있음)에서는 서버 장비 수를 줄일 수 있는 서버 가상화 프로젝트를 수행하는 고객에게 재정적 인센티브를 제공하고 있습니다.
그러나 좀 더 간단하고 온건한 방법도 있습니다. 대부분의 IT 부서에서는 시스템의 전력 소모량을 전혀 파악하지 못하고 있는데, 이것은 역으로 잠재적 절약 가능성이 매우 크다는 것을 의미합니다. 이러한 경우에는 우선적으로, 개별 장치의 에너지 소비량을 파악한 다음, 각각의 장치별로 어떤 변화를 줄 수 있는지 파악해 볼 수 있습니다. 작은 변화라도 많이 쌓이면 상당한 절감으로 이어질 수 있습니다.
비교를 위해 집안에서 사용하는 각 물건들이 어느 정도의 에너지를 사용하는지 전혀 모르고 사는 일반적인 가정을 생각해 볼 수 있습니다. 이들은 그저 매월 요금 총액을 지불할 뿐입니다. 이 경우, 각 기기의 에너지 소비량을 측정해주는 Kill A Watt와 같은 간단하고 저렴한 기기를 사용할 수 있습니다. 그러면 사용하지 않을 때에도 전자 레인지에 전원을 계속 공급하는 경우 얼마나 많은 비용이 낭비되고 있는지, 휴대폰 충전기를 그냥 꼽아둠으로써 소비되는 전력은 어느 정도인지를 알 수 있습니다. 이와 동일한 방식으로, 랙에 전기 계량기를 추가하여 다양한 기기로부터 전기 사용 데이터를 수집할 수 있습니다. 관리 도구를 사용하여 에너지 소비량 SNMP 트랩을 통해 일부 서버에서 직접 데이터를 수집할 수도 있습니다.

시작
그림 5에는 계획의 진척을 위해 적용해야 하는 모범 지침이 개략적으로 제시되어 있습니다. 이 단계에서 반드시 이해해야 할 중요한 사항은 두 가지 극단적인 방법 중 하나를 선택할 필요는 없다는 점입니다. 좀 더 균형 잡힌 방식을 택할 수 있으며, 그것이 더 현실적인 방안일 것입니다. 우선 풀뿌리 노력으로 사내에서 에너지 절약에 열정을 갖고 있는 직원들을 찾아내십시오. 사업부 내에서 사용되는 장치 중 가시적 정보를 제공할 수 있는 일부 장치부터 측정을 시작하십시오. 어느 정도 정보를 축적하여 수치로 설명할 수 있는 결과를 제시하면 그린 이니셔티브에 대한 회사의 투자를 확대하는 데 필요한 지지를 얻을 수 있을 것입니다.
Figure 5 에너지 절약 계획의 효과적 운용을 위한 주요 지침 (Close Figure 5)

시스템의 현재 상태를 파악할 수 있는 데이터를 직접 수집하고 장치 및 응용 프로그램별로 사용되는 전력량과 자세한 비용 내역을 파악하십시오.
변화가 가져다주는 효과를 측정할 수 있는 폐쇄형 루프 피드백 시스템을 마련하십시오.
장치, IT 조직, 사업부, 응용 프로그램 등을 기준으로 적절한 장소에서 적절한 수준으로 전력 사용량을 모니터링하도록 하십시오.
에너지 절약 프로젝트의 추진을 위한 자금을 마련하십시오.
조직 내에서 에너지 효율성 증진 사업의 추진을 도와줄 인물을 찾아내서 참여시키십시오.
귀사에서 에너지 효율성 향상을 추진할 인물은 어떤 사람일까요? 고위 경영진이나 중간 관리자일까요? 아니면 단지 귀사가 환경에 미치는 영향을 걱정하는 개인일까요? 모든 회사에는 열정을 가진 사람들이 있기 마련입니다. 풀뿌리 방식을 시도하여 이러한 사람들과 함께 처음부터 일을 추진할 것인지는 가장 먼저 내려야 할 결정 중 하나입니다.
어떤 방법을 선택하든, 데이터 센터의 에너지 효율성 증진 프로그램을 계획하기 위해서는 결국 여러 IT 그룹 사이의 협력이 필요합니다. 최근까지 일반적인 IT 솔루션 계획 방식에서는 설계 단계 초기에서부터 전력 비용을 무시했으며 솔루션을 구축하는 데 드는 인건비와 호스팅 비용 및 구매할 하드웨어와 소프트웨어 비용에만 집중했습니다. 전력 비용이 데이터 센터에서의 솔루션 운영을 위한 간접 비용에 포함되어 있는 한 에너지 효율성의 우선 순위는 낮아질 수밖에 없습니다. 솔루션에 소비되는 실제 전력을 명시적으로 드러내는 것은 귀하 조직의 행동 방식을 바꾸는 가장 중요한 첫 번째 단계입니다.

Dave Ohara는 26년간 Microsoft, Apple, Hewlett-Packard 등의 회사에서 일하며 기술적 경험을 쌓아왔습니다. 제품 개발, 마케팅, 기술 교육, 인프라 아키텍처, 공정 공학, 안정성 공학, 물류 유통 등 여러 분야에서 활동하고 있는 Dave는 현재 여러 회사들과 그린 이니셔티브 구현 사업을 벌이고 있습니다.
© 2007 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


 Windows Administration: Active Directory 복제 가이드
Windows Administration Laura E. Hunter

Active Directory 복제 가이드
한 눈에 보기:
  • Active Directory로 전환
  • 일관성 유지 관리
  • 충돌 해결 처리
  • Windows Server 2008의 변경 내용

Windows 2000 Server 및 Active Directory가 출시되기 전에는 많은 회사 환경에서 서버 인프라와 ID 및 액세스 관리를 위해 Windows NT를
사용했습니다. Windows NT® 4.0이 발표될 당시에는 NOS(네트워크 운영 체제) 분야에서 입지를 확보했지만 몇 가지 단점 때문에 대규모 엔터프라이즈에 배포하기에는 어려움이 있었습니다.
Windows NT에서는 단일 구조 네임스페이스를 사용하여 네트워크 리소스를 저장했습니다. 즉, 리소스를 더 작은 하위 집합으로 분리하거나 관리를 원하는 대로 세분화하여 구성할 좋은 방법이 없었습니다. 예를 들어 마케팅 부서의 리소스에 사용할 부서 컨테이너를 구성하거나 해당 부서 사용자의 암호만 재설정할 수 있는 권한이 있는 로컬 관리자를 구성할 수 없었습니다. 따라서 Windows NT 보안은 대개 '전체적으로 적용되거나 아니면 아예 적용되지 않는 방식(all-or-nothing)'이라 할 수 있습니다. 관리 작업을 데스크톱 지원 엔지니어에게 위임하려는 경우 필요한 것보다 훨씬 많은 사용 권한을 부여해야 하는 경우가 많았습니다.
또한 Windows NT에서는 모든 정보를 크기가 40MB로 제한된 SAM(Security Accounts Manager) 데이터베이스에 저장했습니다. SAM 데이터베이스가 이 권장 최대 크기를 초과하면(구성에 따라 다르지만 개체가 약 25,000-40,000개일 때 발생함) 환경을 여러 별도의 도메인으로 분리해야 하며 이 경우 네트워크를 관리하고 사용자에게 리소스 액세스를 제공하는 작업이 복잡해졌습니다. 각 NT 도메인에는 SAM 데이터베이스의 읽기/쓰기 사본만 포함하는 하나의 PDC(주 도메인 컨트롤러)가 있었으며 사용자가 내결함성을 위해 BDC(백업 도메인 컨트롤러)를 하나 이상 배포할 수 있었습니다. 하지만 이러한 BDC는 읽기 전용이며 사용자 암호 변경과 같이 쓰기 작업이 필요한 업데이트를 전혀 수행할 수 없었습니다.
마지막으로, Windows NT에서는 NetBIOS 이름 확인을 사용했는데, 이 방식은 브로드캐스트 기반 방식이며 사용자가 네트워크 리소스를 탐색하는 경우, 특히 느리거나 사용량이 많은 WAN 링크를 통해 탐색해야 하는 경우에는 매우 많은 트래픽이 생성되는 경우가 종종 있었습니다.

새로운 모델 소개
2000년 Microsoft에서는 이전 NOS 제품에서 완전히 새로워진 Windows® 2000을 출시했습니다. 새로운 NOS 서비스인 Active Directory®도 Windows NT와 달라졌습니다. Active Directory는 단일 구조 네임스페이스를 사용하는 대신 계층적 조직 구조를 작성하는 X.500 표준을 기반으로 합니다. 이제 리소스를 단일 도메인 내에서 여러 조직 구성 단위로 구성하고 작업 기반 수준에서 각 OU에 대한 관리를 위임할 수 있습니다.
또 다른 Windows NT와의 차이점은 새로운 다중 마스터 복제 모델입니다. Active Directory에서는 하나의 PDC만 쓸 수 있고 관련 BDC를 여러 개 두는 이전 기능이 사라지고, 각 도메인 컨트롤러에서 Active Directory 데이터베이스에 쓸 수 있게 되었습니다.
하지만 이로 인해 대규모 및 분산 환경을 지원하는 측면에서는 유연성이 대폭 향상되었지만 Active Directory의 무결성 유지 관리라는 새로운 과제가 대두되었습니다. John Smith와 Jane Dow가 한 나라의 각기 반대쪽 끝에 있는 사무실에서 동일한 개체를 변경할 때 해당 변경이 서로 충돌하면 어떻게 될까요? Active Directory 복제 모델에서는 환경 내 모든 도메인 컨트롤러를 통해 업데이트를 주고받는 방법과 실질적으로 어디에서나 변경이 가능한 이 다중 마스터를 사용하는 데 따라 발생하는 모든 충돌을 처리하는 방법을 정의합니다.

Active Directory 복제의 원리
이 예의 목적상 여기에서는 사이트 내 복제에 대해서만 설명하겠습니다. 기본적으로 사이트 내 복제는 변경 내용을 같은 사이트 내의 DC로 빠르게 복제하도록 설계되었으며 이는 변경 알림을 통해 수행됩니다. 사이트 내 복제에서 DC1은 복제가 필요한 변경이 있음을 DC2에게 알리고 DC2는 해당 변경 내용을 DC1에서 가져옵니다. 마찬가지로 DC2는 DC2에 변경이 있을 때 이를 DC1에 알리며 DC1은 해당 변경 내용을 DC2에서 가져옵니다. 여기서 볼 수 있듯이 모든 Active Directory 복제는 내보내기가 아닌 가져오기 방식으로 수행됩니다.
Active Directory는 수백, 수천 또는 수백만 개의 개체로 확장될 수 있으므로 Active Directory 데이터베이스를 명명 컨텍스트라고 하는 섹션으로 나누는 것이 필요합니다. 최소한 각 도메인 컨트롤러는 Active Directory 데이터베이스의 자체 로컬 사본에 세 개의 NC를 저장합니다.
스키마 NC 이 NC는 포리스트의 다른 모든 도메인 컨트롤러로 복제됩니다. 여기에는 Active Directory 스키마에 대한 정보가 포함되며, 이 스키마는 Active Directory 내의 여러 개체 클래스 및 특성을 정의합니다.
구성 NC 이 NC 또한 포리스트의 다른 모든 DC로 복제되며 여기에는 Active Directory의 물리적 레이아웃과 관련된 포리스트 전체 구성 정보뿐만 아니라 표시 지정자 및 포리스트 전체 Active Directory 할당량에 대한 정보가 포함됩니다.
도메인 NC 이 NC는 단일 Active Directory 도메인 내의 다른 모든 DC로 복제됩니다. 이 NC에는 가장 자주 액세스되는 Active Directory 데이터, 즉 실제 사용자, 그룹, 컴퓨터 및 특정 Active Directory 도메인 내에 있는 다른 개체가 포함됩니다.
복제 트래픽을 더욱 최적화하기 위해 각 명명 컨텍스트는 개별적으로 복제됩니다. 따라서 스키마 NC와 같이 자주 변경되지 않는 NC가 더 자주 변경되는 도메인 NC에 필요한 네트워크 대역폭을 사용하는 일이 없습니다.
디렉터리 변경은 모든 Active Directory DC에서 수행될 수 있기 때문에 Active Directory 복제가 추적해야 하는 쓰기 작업에는 두 가지 유형이 있습니다. 한 가지 유형은 특정 변경이 특정 DC에서 직접 수행된 때의 원래 쓰기 작업입니다. 예를 들어 DC1에 연결하여 사용자의 암호를 변경하면 이 변경 내용은 DC1의 원래 쓰기 작업으로 간주됩니다. Active Directory는 복제된 쓰기도 추적해야 합니다. 여기서 알 수 있듯이 특정 변경은 다른 도메인 컨트롤러로부터 복제됩니다. DC1에서 원래 쓰기 작업으로 간주된 변경은 해당 변경이 DC2, DC3 및 다른 모든 DC로 복제된 경우 복제된 쓰기 작업으로 간주됩니다.
Active Directory 도메인 컨트롤러에서는 복제 메타데이터를 사용하여 디렉터리 변경에 대한 전송을 관리합니다. 즉, Active Directory는 한 DC에서 다른 DC로 변경된 실제 데이터(John Smith의 설명이 'HR Director'로 변경됨)를 전달할 뿐만 아니라 도메인 컨트롤러가 복제를 가장 효과적으로 관리할 수 있도록 이 변경에 대한 추가 정보도 전송합니다. 이러한 정보로는 변경이 수행된 DC, 변경 시간, 기타 주요 정보 등이 있습니다.
여기서 설명할 복제 메타데이터의 첫 번째 항목은 USN(업데이트 시퀀스 번호)입니다. 각 도메인 컨트롤러는 해당 도메인 컨트롤러에 특정한 USN을 유지 관리합니다. 해당 DC에서 Active Directory를 변경할 때마다 USN이 1씩 증가됩니다. 따라서 오전 11:00에 DC의 USN이 1000이었고 오전 11:30에는 1005였다면 해당 DC에서 Active Directory 데이터베이스에 5번의 변경 작업이 수행되었음을 알 수 있습니다. USN과 관련해서는 이러한 변경이 정확히 무엇인지는 중요하지 않습니다. 5개의 개체를 수정했거나, 5개의 개체를 생성했거나, 5개의 개체를 삭제했거나, 이런 작업을 섞어 수행했을 수 있으며 이 모든 경우에 USN은 5가 증가됩니다. 또한 USN은 특정 도메인 컨트롤러에만 해당하는 요소로 다른 DC와 비교할 때는 아무런 관련이 없습니다. 즉, 특정 도메인의 한 DC가 오전 11:30에 변경 작업을 수행하는 경우 1051인 USN이 할당되고, 같은 도메인에서 다른 DC가 정확하게 동시에 변경 작업을 수행하는 경우 5084인 USN이 할당될 수 있습니다. 이 두 DC는 거의 동시에 수행된 변경에 대해 근본적으로 상이한 USN을 가지지만, 이 사실은 이러한 변경이 복제되는 방식과는 관계가 없습니다. 변경을 서로 비교할 때 한 DC의 업데이트 시퀀스 번호는 다른 모든 DC에 대해서는 어떠한 의미도 갖지 않습니다.
하지만 DC의 USN은 이외 다른 방법으로도 증가될 수 있습니다. 앞서 말했듯이 Active Directory 데이터베이스에 대한 변경은 원래 쓰기 작업 또는 복제된 쓰기 작업으로 구성될 수 있습니다. 도메인 컨트롤러의 업데이트 시퀀스 번호는 두 가지 유형 모두의 쓰기 작업을 통해 증가됩니다. 즉, 다른 DC에서 변경이 복제될 때마다 증가됩니다. 이제 각 DC에는 이미 복제된 변경을 추적할 방법이 있어야 합니다. 그렇지 않으면 각 DC는 복제할 때마다 쓰기 작업과 관련된 전체 Active Directory 데이터베이스를 보내야 합니다. 이를 방지하기 위해 각 Active Directory 도메인 컨트롤러는 복제하는 다른 도메인 컨트롤러에 대해 HWMV(High Watermark Vector)라는 값을 유지 관리합니다. 각 DC는 이 HWMV를 원격 DC의 GUID(Globally Unique Identifier)와 연결하여 원격 도메인 컨트롤러의 이름이 변경되거나 이 원격 도메인 컨트롤러가 디렉터리에서 제거될 때의 혼동을 방지합니다.
먼저 contoso.com 도메인에서 구성된 두 개의 도메인 컨트롤러인 dc1.contoso.com 및 dc2.contoso.com이 있는 간단한 예를 살펴보겠습니다. contoso.com 도메인에는 두 개의 DC만 있으므로 DC1과 DC2는 서로 간에만 복제합니다. 이 예는 Active Directory 복제 전체를 다루는 것이 아닌 단순화된 예입니다. 자세한 예는 이후 더 자세히 설명할 때 추가합니다.
이제 DC1의 현재 USN이 3000이고, DC2의 현재 USN이 4500이며 이 두 DC는 현재 서로 완전히 최신 상태에 있다고 가정해 보겠습니다.
1단계: DC1과 DC2가 서로 간에 최신 상태를 유지합니다. 그림 1에서 볼 수 있듯이 DC1의 D2에 대한 HWMV는 4500이며, DC2의 DC1에 대한 HWMV는 3000입니다.
그림 1 두 DC의 현재 상태
그림 1 두 DC의 현재 상태
2단계: 관리자가 DC1에서 새 개체를 만들고 그림 2에서와 같이 DC1의 USN이 3001로 증가됩니다. DC1은 대기 중인 변경 작업이 있음을 아직 DC2에 알리지 않았으므로 DC2에서 DC1의 HWMV는 변경되지 않았습니다.
그림 2 새 개체가 추가됨
그림 2 새 개체가 추가됨
3단계: DC1에서 사용 가능한 변경이 있음을 DC2에 알립니다. 그러면 DC2가 DC1과의 복제를 시작하여 사용 가능한 모든 업데이트를 요청합니다. 이 요청 과정에서 DC2는 그림 3에서와 같이 DC1에 대해 저장된 HWMV를 DC1에 전송합니다.
그림 3 변경 알림
그림 3 변경 알림
4단계: DC1이 USN 3001에 해당하는 변경(즉, 단계2에서 DC1에 작성된 개체)을 DC2에 보냅니다. DC2는 그림 4에서와 같이 자신의 USN을 4501로 업데이트하고 DC1에 대한 HWMV를 3001로 업데이트합니다.
그림 4 변경 및 업데이트
그림 4 변경 및 업데이트
지금까지는 별 문제가 없는 것 같죠? 하지만 여기에는 한 가지 문제가 있습니다. DC2에 복제가 필요한 변경이 있습니다. USN과 HWMV만 있다면 이 시점에 DC2는 DC1에 연결하여 DC1이 DC2로 복제한 것과 같은 변경을 다시 DC1로 복제하여 무한 복제 주기가 생성되고 결국 사용되는 대역폭이 점점 빠르게 증가할 것입니다. 이 문제를 해결하기 위해 몇 가지 대책이 더 필요하며 그 중 첫 번째가 UTDV(최신 벡터, UTD 벡터)입니다.
UTDV는 불필요한 전파 방지에 사용되는 또 다른 복제 메타데이터입니다. 즉, 동일한 변경이 네트워크를 통해 계속 복제되어 대역폭이 낭비되는 것을 방지하는 것이 목적입니다. 각 DC는 다른 모든 DC에 대해 최신 명명 컨텍스트의 복제본을 저장하는 UTDV 테이블을 유지 관리합니다. 도메인 NC의 경우 도메인의 각 DC는 도메인의 모든 DC에 대한 UTDV를 유지 관리합니다. 구성 및 스키마 NC의 경우에는 포리스트의 모든 DC에 대해 UTDV를 유지 관리합니다. UTDV는 각 DC가 복제 파트너로부터 수신한 가장 높은 USN뿐만 아니라 해당 NC를 복제하는 모든 DC에서 수신한 가장 높은 USN 값도 추적합니다. 이를 가능하게 하기 위해 각 복제된 변경에는 다음 정보도 포함됩니다.
  • 변경을 복제하는 DC의 GUID. 원래 쓰기 작업 또는 복제된 쓰기 작업으로 복제되는 변경일 수 있습니다.
  • 변경을 복제하는 DC의 USN. 원래 쓰기 작업 또는 복제된 쓰기 작업의 USN일 수 있습니다.
  • 변경이 시작된 DC의 GUID. 이 GUID가 변경을 복제하는 DC의 GUID와 같은 경우 이것은 원래 쓰기 작업입니다. 그렇지 않은 경우에는 UTDV 테이블이 작용합니다.
  • 변경이 시작된 DC의 USN. 이 USN이 변경을 복제하는 DC의 USN과 같은 경우 이것은 원래 쓰기 작업입니다. 그렇지 않은 경우에는 UTDV 테이블에서 제거됩니다.
이 프로세스의 이해를 돕기 위해 세 번째 도메인 컨트롤러인 DC3을 추가하여 예의 복잡성을 높여보겠습니다. 이 경우 DC1, DC2 및 DC3은 모두 서로 간의 복제 파트너입니다. DC1은 DC2 및 DC3과 복제되고, DC2는 DC1 및 DC3과 복제되고, DC3은 DC1 및 DC2와 복제됩니다.
1단계: DC1, DC2 및 DC3 모두 서로 간에 최신 상태를 유지합니다.
2단계: DC3이 jsmith 사용자 계정의 암호를 재설정하여 하나의 원래 쓰기 작업을 수행합니다. DC3에서 사용 가능한 변경이 있음을 DC1 및 DC2에 알립니다. 그림 5에서와 같이 DC1과 DC2는 DC3에서 원래 쓰기 작업을 가져온 다음 HWMV 및 UTDV 테이블을 DC3에 맞게 업데이트합니다.
그림 5 HWMV 및 UTDV 테이블 업데이트
그림 5 HWMV 및 UTDV 테이블 업데이트
3단계: 여기서 UTDV가 작동합니다. DC2에서 사용 가능한 변경이 있음을 DC1에 알립니다. 그러면 DC1은 DC2에 연결하고 DC2에 다음 정보를 보냄으로써 모든 새 변경을 요청합니다.
  • DC1의 DC2에 대한 가장 높은 HWMV(이 경우 4501)
  • DC3을 포함하여 모든 DC에서 수신한 가장 높은 원래 USN을 나타내는 DC1의 UTDV 테이블(그림 6)
Figure 6 UTDV 테이블 (Close Figure 6)

이 NC를 복제하는 모든 DC | UTDV
<DC2의 GUID> | 4501
<DC3의 GUID> | 7002
HWMV가 4501임을 참고하여 DC2에서 해당 변경이 DC1에 복제되지 않았음을 인식합니다(그림 7 참조).
Figure 7 복제해야 하는 변경 (Close Figure 7)

속성 | 값 | 로컬 DC의 GUID | 로컬 USN | 원래 DC의 GUID | 원래 USN
jsmith 암호 속성 | %#FH%2rfg2 | <DC2의 GUID> | 4501 | <DC3의 GUID> | 7002
하지만 복제가 시작되기 전에 DC1이 전송한 UTDV 테이블에 따라 DC2는 DC1이 이미 DC3에서 이 변경을 수신했기 때문에 DC1에 실제로 이 변경이 필요하지 않은 것으로 판단합니다. 그림 8에서와 같이 이 시점에서 DC1은 DC2에 대한 HWMV 항목을 업데이트하여 증가된 USN을 반영합니다. 하지만 대역폭을 절약하기 위해 실제 데이터는 네트워크를 통해 전송되지 않습니다.
그림 8 불필요한 전파 방지
그림 8 불필요한 전파 방지
4단계: DC2에서 DC3에 사용 가능한 변경이 있음을 알릴 때뿐만 아니라 DC1에서 유사한 방식으로 DC2와 DC3에 알릴 때에도 같은 불필요한 전파 방지가 적용됩니다. 이들 세 가지 DC는 모두 그림 8에서와 같이 복제 파트너에 대한 각 HWMV 항목을 업데이트하지만 실제 데이터는 단계2에서 각 DC로 이미 전송되었으므로 네트워크를 통해 다시 전송되지 않습니다.

다중 마스터 환경에서의 충돌 해결
지금까지의 예는 한 명의 관리자가 한 번에 하나의 DC를 변경하고, 이 작업을 수행하는 동안 다른 관리자는 아무런 작업도 하지 않는 이상적인 경우였습니다. 하지만 실제로는 이런 경우가 거의 없습니다. Active Directory 개체에 대한 업데이트는 도메인의 모든 도메인 컨트롤러에서 수행될 수 있기 때문입니다. 두 관리자가 두 도메인 컨트롤러에서 서로 충돌하는 업데이트를 수행하면 어떻게 될까요? Active Directory 환경에서는 세 가지 유형의 충돌이 발생할 수 있으며, 각 유형에 따라 서로 다른 충돌 해결 방법이 사용됩니다.
속성 변경 충돌 . 이 충돌은 두 관리자가 서로 충돌하는 방식으로 동일한 개체를 업데이트하는 경우에 발생합니다. 즉, 한 관리자가 사용자의 설명을 "Marketing"으로 설정할 때 다른 DC의 다른 관리자가 해당 사용자의 설명을 "Sales and Marketing"으로 설정하는 경우입니다.
새 개체 작성 충돌 . 두 관리자가 이름이 jsmith인 두 사용자와 같이 이름이 같은 개체를 동시에 만드는 경우에 이 충돌이 발생합니다.
개체를 삭제된 컨테이너로 이동 . 이러한 유형의 충돌은 꽤 드물게 발생하며, 한 관리자가 OU와 같은 컨테이너 내에서 개체를 만들거나 이동할 때 다른 DC의 다른 관리자가 동시에 이 컨테이너를 삭제하는 경우에 발생합니다.
처음 두 유형의 충돌을 해결하기 위해서는 충돌 해결에 주로 사용되는 두 개의 복제 메타데이터가 필요합니다. versionID 값은 개체의 개별적인 각 특성에 할당되며 개체가 처음 작성될 때 1부터 시작하여 DC에서 개별 특성이 수정될 때마다 1씩 증가합니다. 따라서 특정 사용자의 설명 특성이 기본값(공백 또는 <설정되지 않음>)에서 "Marketing Department"로 업데이트되면 설명 특성의 versionID는 2가 되고, 나중에 설명이 "Sales and Marketing Department"로 수정되면 설명 특성의 versionID는 3이 됩니다. 이 versionID는 앞서 설명한 다른 메타데이터와 함께 모든 복제 항목에 포함됩니다.
versionID는 복제 트래픽을 줄이는 용도로도 사용될 수 있습니다. 예를 들어 DC2의 관리자가 실수로 변경 내용을 여러 번 잘못 입력하여 하나의 특성을 여러 번 변경한 경우, 즉 DC2에 versionID 2, 3, 4, 5에 해당하는 원래 쓰기 작업이 있는 등의 경우에 DC2는 마지막 versionID인 5에 해당하는 쓰기 작업만 복제합니다. 이를 통해 이전 변경은 간단히 덮어써지므로 불필요한 대역폭 사용을 줄일 수 있습니다.
Active Directory에 대한 모든 변경에는 충돌 해결을 위한 두 번째 메타데이터인 타임스탬프도 포함됩니다. 타임스탬프는 수정 시간을 나타내는 복제 메타데이터의 일부입니다.
타임스탬프 특성은 Active Directory 복제 상태를 사전 측정하는 용도로도 사용됩니다. DC가 특정 DC에서 비교적 최근인 타임스탬프를 가진 변경을 찾지 못하면 해당 DC에 문제가 있을 수 있음을 알리는 오류 메시지가 생성됩니다.
그렇다면 이 두 특성이 충돌 해결에 어떻게 이용될까요? 각 충돌 유형을 하나씩 살펴보겠습니다.

속성 변경 충돌 해결
contoso.com 도메인의 jsmith 사용자 개체를 예로 들겠습니다. DC1의 관리자가 jsmith의 설명을 "Marketing"으로 변경합니다. 이와 거의 동시에 DC3의 관리자가 같은 사용자의 설명을 "Sales and Marketing"으로 변경합니다. 이 시점에서 그림 9와 같이 jsmith의 설명 특성에 대한 DC1 및 DC3의 정보를 비교합니다.
Figure 9 거의 동시에 수행되는 변경 (Close Figure 9)

서버 | 속성 | 값 | VersionID | 타임스탬프 | 로컬 DC의 GUID | 로컬 USN | 원래 DC의 GUID | 원래 USN
DC1 | jsmith 설명 속성 | "Marketing" | 2 | 2007-06-07 14:03:25 | <DC1의 GUID> | 3003 | <DC1의 GUID> | 3003
DC3 | jsmith 설명 속성 | "Sales and Marketing" | 2 | 2007-06-07 14:04:57 | <DC3의 GUID> | 7003 | <DC3의 GUID> | 7003
DC2가 이 두 변경을 동시에 수신한 경우 DC2는 둘 중 우선적인 변경을 결정해야 합니다. 충돌 해결을 위한 우선 순위는 다음과 같이 결정됩니다.
  1. versionID가 더 높은 수정 사항이 우선권을 가지며 다른 변경 사항은 덮어써집니다. 이 경우 두 레코드의 versionID가 모두 2이기 때문에 다음 결정 기준으로 넘어가야 합니다.
  2. 두 레코드의 versionID가 같은 경우에는 타임스탬프가 더 최신인 변경이 선택되고 다른 변경은 덮어써집니다. 이 경우 DC3의 원래 쓰기 작업의 타임스탬프가 더 최신이므로 jsmith의 설명은 "Sales and Marketing"으로 설정됩니다. 드문 경우지만 versionID와 타임스탬프가 모두 동일하면 세 번째 결정 기준이 필요합니다.
  3. 두 레코드의 versionID와 타임스탬프가 같은 경우에는 GUID가 낮은 DC에서 시작된 쓰기 작업이 선택되고 GUID가 높은 쓰기 작업은 덮어써집니다. 따라서 DC1의 GUID가 1234567890이고 DC3의 GUID가 2345678901인 경우, versionID와 타임스탬프가 모두 동일하면 DC1의 원래 쓰기 작업이 선택됩니다.
아마도 "타임스탬프를 첫 번째 결정 기준으로 사용하는 것이 적당하지 않을까?"라는 생각을 할 수도 있겠지만 생각처럼 단순하지 않습니다. 타임스탬프가 Active Directory 충돌 해결의 우선적인 결정 기준이라면 악의적 관리자가 특정 DC의 시계를 뒤로 돌려서 항상 선택되도록 하여 자신의 변경 내용을 전파할 가능성이 있습니다.

개체 작성 충돌 해결
두 개체가 같은 이름으로 작성된 경우 Active Directory는 이전 단원에서 설명한 것과 같은 세 가지 결정 기준을 사용하여 우선적으로 선택할 개체를 결정합니다. 하지만 이전 단원에서처럼 선택되지 않은 개체를 덮어쓰지는 않습니다. 대신 충돌 개체에 대한 문자 CNF와 콜론 및 선택되지 않은 개체의 GUID를 사용하여 선택되지 않은 개체의 이름을 변경합니다. 이를 통해 관리자는 보존할 개체와 삭제할 개체를 더 체계적으로 판단할 수 있습니다.

삭제된 컨테이너로의 개체 이동 문제 해결
앞서 설명했듯이 삭제된 컨테이너로 개체를 이동하는 충돌 문제는 두 시나리오 중 하나에서만 발생하는 매우 드문 충돌입니다. 첫 번째 시나리오는 한 DC의 관리자가 Training OU와 같은 특정 컨테이너 안에 개체를 만들었을 때 이와 동시에 다른 DC의 관리자가 Training OU를 삭제한 경우입니다. 두 번째 시나리오는 한 DC의 관리자가 개체를 컨테이너로 이동할 때 이와 동시에 다른 DC의 관리자가 해당 컨테이너를 삭제하는 경우입니다.
이 경우의 해결 방법은 비교적 간단합니다. Active Directory는 "고아" 개체를 이런 용도로 설계된 Active Directory 내의 특별한 컨테이너인 LostAndFound 컨테이너로 이동합니다. 이 컨테이너는 각 Active Directory 도메인의 루트에 존재합니다. contoso.com 도메인의 경우 LostAndFound 컨테이너는 LDAP 경로인 LDAP://cn=LostAndFound,dc=contoso,dc=com에서 찾을 수 있습니다. Active Directory 사용자 및 컴퓨터 스냅인을 열었을 때 LostAndFound 컨테이너가 표시되지 않으면 보기 | 고급 기능을 클릭하십시오.

USN 롤백으로부터 보호
Active Directory 환경에서 접할 수 있는 가장 난감한 상황 중 하나는 그 원인과 해결 방법을 알기만 하면 가장 간단하게 피할 수 있기도 합니다. USN 롤백은 네트워크에서의 복제 작업을 완전히 종료시킬 수 있는 오류 상태이며, 도메인 컨트롤러를 너무 오랫동안 오프라인 상태로 유지하고 다시 서비스를 시작하도록 허용하거나 지원되지 않는 방법으로 도메인 컨트롤러를 복원할 때 발생할 수 있습니다.
USN 롤백의 기본 원인 중 하나는 Active Directory 다중 마스터 환경에서 개체 삭제가 처리되는 방식과 관련이 있습니다. 개체는 DC에서 삭제될 때 완전히 제거되는 것이 아니라 삭제 표시됩니다. 삭제 표시된 개체는 다른 DC에 삭제를 통보하여 복제될 수 있습니다. 삭제 표시된 개체는 TRUE로 설정된 isDeleted 특성을 갖습니다. 삭제 표시된 개체의 크기를 줄이기 위해 설명, 개인 정보, 사용자 개체의 그룹 구성원 등과 같이 개체에 포함된 대부분의 값은 제거됩니다. 이 프로세스에 대한 자세한 내용은 technetmagazine.com/issues/2007/09에서 볼 수 있는 Gil Kirkpatrick의 기사 "Active Directory 삭제 표시 개체 다시 애니메이션"을 참조하십시오.
USN 롤백은 이러한 삭제 표시된 개체가 일정 시간이 지나면 제거되기 때문에 발생할 수 있습니다. 기본적으로 이런 개체는 60일 또는 180일(Active Directory 환경을 처음 만들 때 실행 중이던 Windows Server®의 버전에 따라 다름) 후 Active Directory 데이터베이스에서 완전히 삭제됩니다. 이 60일 또는 180일 기간을 삭제 표시 수명이라고 합니다. 모든 도메인 컨트롤러는 이 기간 동안 최소 한 번 복제할 수 있어야 하며 그렇지 않은 경우에는 USN 롤백이 발생할 수 있습니다. 기본적으로 USN 롤백은 도메인 컨트롤러가 너무 오래 업데이트되지 않아 하나 이상의 삭제 표시된 개체가 "누락"되어 있고 이로 인해 다른 DC에서 최신 상태인 Active Directory 데이터베이스의 로컬 복사본을 가져올 수 없는 경우에 발생합니다. 이 문제를 방지하려면 삭제 표시 수명보다 길게 오프라인 상태였던 모든 도메인 컨트롤러는 다시 서비스를 개시하지 않아야 합니다. 대신 Microsoft 기술 자료 문서 216498(support.microsoft.com/kb/216498)의 단계를 사용하여 Active Directory에서 오래된 DC의 메타데이터를 제거한 후 처음부터 다시 빌드해야 합니다.
USN 롤백이 발생하는 두 번째 이유는 도메인 컨트롤러가 지원되지 않는 방법(대부분 디스크 복제 또는 이미징 도구 사용)으로 복원된 경우입니다. 이 경우 복원 방법에서 Active Directory를 인식하지 않기 때문에 복원된 Active Directory 데이터베이스는 "기존 시점"으로 복원된 것임을 인식하지 못합니다. Windows 2000 및 Windows Server 2003의 초기 릴리스에서는 USN 롤백을 감지하기 어려웠지만 Windows Server 2003 SP1(그리고 곧 출시될 Windows Server 2008)에는 DC가 부적절하게 복원된 것을 감지하는 컨트롤이 기본 제공됩니다. 이러한 최신 OS 버전에서 DC는 디렉터리 서비스 이벤트 로그에 이벤트 ID 1115, 2095, 2103 및 2110을 기록합니다. 이러한 이벤트의 텍스트와 USN 롤백을 복구하는 데 수행해야 하는 단계는 Windows Server 2003에 대해 설명하는 기술 자료 문서 875495(support.microsoft.com/kb/875495)에서 볼 수 있습니다. Windows 2000에서 USN 롤백을 다루는 방법에 대해서는 기술 자료 문서 885875(support.microsoft.com/kb/885875)를 참조하십시오.

2008에서의 다중 마스터 모델 업데이트
Microsoft에서는 곧 출시될 Windows Server 2008에 RODC(읽기 전용 도메인 컨트롤러)를 도입하여 다중 마스터 모델을 약간 변경했습니다. RODC는 기본적으로 지점 배포를 위해 설계되었으며 특정 위치에 파견된 IT 전담 직원이 없으며 특정 DC의 무결성을 보장할 추가적인 단계가 필요한 시나리오를 위해서도 설계되었습니다. RODC의 기술 세부 사항을 모두 설명하는 전체 기사를 제공할 수도 있지만 여기서는 알아야 하는 핵심 사항만 검토하겠습니다.
그 이름에서 알 수 있듯이 RODC에 있는 Active Directory 데이터베이스의 사본은 읽기 전용입니다. RODC에 연결하여 필요한 거의 모든 정보를 읽을 수 있지만 RODC에서는 쓰기 작업을 수행할 수 없습니다.
두 번째로 RODC는 아웃바운드 복제를 수행하지 않습니다. 이는 지금까지 설명한 다중 마스터 복제 모델에서 근본적으로 변경된 내용입니다. RODC는 쓰기 가능한 다른 Windows Server 2008 DC에서 인바운드 복제를 수신하기는 하지만 다른 DC로 정보를 복제하지 않습니다. 이를 통해 악의적 사용자가 RODC에서 어떤 식으로든 Active Directory를 수정할 수는 있더라도 이 수정 내용이 환경의 다른 부분으로 전파되지 않으므로 추가적인 보안 계층이 형성됩니다.
또한 가장 흥미로운 기능일 수 있겠지만 RODC는 기본적으로 사용자 암호를 복제하지 않습니다. Active Directory 데이터베이스가 쓰기 가능한 DC에서 RODC로 인바운드 복제될 때 모든 사용자 개체는 사용자 암호 정보 없이 복제됩니다. 따라서 DC가 외부에 연결되더라도 DC의 하드 드라이브에 암호 정보가 없기 때문에 지점 환경에 추가적인 보안 계층을 제공합니다. 전체적으로 봤을 때 다중 마스터 Active Directory 복제는 원래 개념이 위에 설명한 것과 같이 변경됨으로써 지점 또는 기타 원격 위치에서의 도메인 컨트롤러 보안을 위한 더욱 향상된 모델로 재탄생했습니다.

Laura E. Hunter는 Windows Server 네트워킹 분야에서 Microsoft MVP를 네 차례 수상했으며 IT 분야에서 10년 동안 일해 온 전문가입니다. Active Directory Cookbook, Second Edition(O'Reilly, 2006)을 포함하여 많은 서적, 기사 및 백서를 집필 또는 공동 집필했습니다.


 System Center: 새로운 소프트웨어 업데이트 관리 도구
System Center Steve Rachui

새로운 소프트웨어 업데이트 관리 도구
한 눈에 보기:
  • 이전 방식으로 업데이트 관리
  • SCMM 2007의 새로운 프로세스
  • 사용자 지정 구성 및 유연성
  • 세밀하게 조정된 업데이트 일정

소프트웨어 업데이트 관리라는 개념은 Systems Management Server(SMS) 2.0에서 보안 및 Office 업데이트 검색 도구를 통해 처음 소개되었습니다. 이후 이러한 도구는 여러 차례 수정되었습니다. 그 중 확장
보안 업데이트 인벤토리 도구는 추가 제품 검색 기능을 지원하도록 수정되었고, Inventory Tool for Microsoft® Updates의 경우 보안 도구와 Office 도구가 하나의 제품으로 결합되었으며, Inventory Tool for Dell Updates라는 도구도 추가되었습니다. 또한 타사 제품 패치 기능을 지원하는 사용자 지정 업데이트 게시 도구도 추가되었습니다. ITMU(Inventory Tool for Microsoft Updates) 자체는 세 번 수정되었습니다. 이러한 각각의 수정 버전은 자체 카탈로그, 검색 인프라 및 고유한 요구 사항과 특징을 가지고 있습니다. 시간이 지나 각 시스템의 카탈로그가 너무 커지면서 용량의 한계로 인해 새 업데이트를 게시하기 위해 이전 업데이트는 제거되었습니다.
다양한 옵션이 제공됨에 따라 이러한 도구를 사용하여 업데이트를 배포하기가 쉽지 않은 경우도 생겨나게 되고, 프로세스의 단순화가 절실히 요구되기에 이르렀습니다. SMS의 다음 버전으로 발표될 System Center Configuration Manager 2007(SCCM)은 이러한 측면에서 크게 발전되었습니다. SCCM의 소프트웨어 업데이트 메커니즘은 더 나은 결과를 보장하도록 작성되었습니다. 전혀 다른 업데이트 관리 방식을 사용하기 때문에 이전 카탈로그와 검색 엔진은 옛이야기가 되었습니다. 이전에는 하드웨어 인벤토리를 통해 보고되었던 업데이트 상태는 이제 각 클라이언트의 규정 준수 및 정책 적용 상태를 보다 효과적으로 확인할 수 있는 새로운 메커니즘(상태 메시지)을 사용합니다. 개인적으로 이러한 SCCM 2007의 새로운 업데이트 관리 방식은 중대한 개선 사항이라고 생각합니다.
SCCM 2007에는 두 가지 새로운 구성 요소가 추가되었습니다. 업데이트 관리 기능에 대해 설명하기 전에 이 두 구성 요소를 살펴보도록 하겠습니다.
SUP(소프트웨어 업데이트 지점) 앞서 말했듯이 SCCM에는 카탈로그가 없습니다. 대신 메타데이터 다운로드와 클라이언트 검색 기능을 제공하면서 SUP(소프트웨어 업데이트 지점) 역할을 하는 Windows Server® Update Services(WSUS) 전용 서버를 통해 직접 작업을 수행합니다. SCCM에서는 검색 프로세스에 중점을 두기 위해 WSUS의 업데이트 이진 데이터 전달 기능이 사용되지 않습니다. 이러한 조정의 결과로 WSUS가 전용 서버의 SUP별로 최대 25,000개까지 클라이언트 검색을 처리할 수 있도록 처리 범위가 확장되었습니다. 또한 SCCM에서는 NLB(네트워크 부하 분산) 클러스터를 통해 SUP를 구성하여 가용성과 확장성을 높이고 최대 4개까지 SUP를 사용함으로써 기본 사이트마다 100,000개의 클라이언트를 지원하도록 할 수 있습니다.
CI(구성 항목) 구성 항목은 SCCM에서 대상 시스템에 필요한 특정 구성을 정의하는 데 사용되는 새로운 방법입니다. SCCM 업데이트 관리에는 이제 이 인프라가 사용됩니다. 여전히 유사한 부분이 있기는 하지만 더 이상 업데이트를 일반 소프트웨어 배포와 동일한 것으로 생각해서는 안 됩니다. 업데이트는 관리 콘솔에서 고유한 노드에 위치하며 전혀 다른 CI 메커니즘을 사용합니다. 클라이언트 쪽에서는 업데이트가 선택적으로 다운로드되고 로컬에 저장됩니다.

업데이트 관리 구성
업데이트 관리를 구성하는 과정은 클라이언트 에이전트를 사용하도록 설정하고 SUP를 구성하고 업데이트 배포를 구성하는 세 가지 부분으로 이루어집니다.
그림 1에 나와 있는 SCCM 클라이언트 에이전트는 다른 에이전트와 유사하며 관리 콘솔의 동일한 노드에 구성되어 있습니다. 관리자는 소프트웨어 업데이트 클라이언트 에이전트 노드의 속성 페이지에서 이 에이전트를 사용하도록 설정하고 업데이트 설치 및 배포 다시 평가 설정을 구성합니다. 소프트웨어 업데이트 클라이언트 에이전트를 사용하는 설정은 사이트 수준에 적용되므로 이 기능을 설정한 사이트에 할당된 모든 SCCM 클라이언트에 이 역할이 사용됩니다. 환경에 이 기능을 사용해서는 안 되는 시스템이 있으면 로컬 정책을 다시 정의하는 설정을 사용하여 시스템별로 설정함으로써 사이트 수준 설정을 다시 정의할 수 있습니다.
그림 1 클라이언트 에이전트 속성
그림 1 클라이언트 에이전트 속성
관리자는 여기서 제공되는 설정을 사용하여 업데이트 기한 처리 방법을 지정할 수 있습니다. 예를 들어 설치가 보류된 업데이트가 4개 있고 그 중 하나(업데이트 A)의 기한이 다른 3개보다 하루 빠르다고 가정해 보십시오. 그러나 일부 업데이트가 기한에 도달하지 않더라도 4개의 업데이트를 모두 동시에 설치해야 합니다. 이 경우 이 탭에서 모든 필수 배포를 강제로 실행하는 옵션을 사용하면 원하는 방식으로 업데이트를 구성할 수 있습니다. 또한 이 탭의 설정을 사용하면 관리자가 업데이트 프로세스의 모든 알림 및 시각적 표시를 표시하지 않도록 지정할 수 있습니다. 이러한 옵션은 그림 1에 나와 있습니다.
Deployment Re-evaluation(배포 다시 평가) 탭의 설정을 통해 관리자는 배포를 다시 평가하는 일정을 설정할 수 있습니다. 이 일정에 따라 SCCM 클라이언트를 다시 평가하여 이전에 설치된 업데이트가 아직 필요한지 확인하고 해당 업데이트가 없으면 다시 설치합니다.

SUP 구성
앞서 설명했듯이 SUP는 일정에 따라 사용 가능한 업데이트 정보를 모두 다운로드하고 SCCM 클라이언트와 직접 상호 작용하여 업데이트의 데이터베이스를 기준으로 규정 준수 검색을 수행하는 역할을 담당합니다. SUP 프로세스는 SCCM에서 사용할 WSUS를 구성하기만 하고 WSUS를 실제로 설치하지는 않으므로 SUP를 구성하기 전에 WSUS 3.0 이상의 서버를 설치해야 합니다. 또한 사이트 서버에 WSUS 관리자 콘솔을 설치하여 WSUS 서버와 연결할 수 있도록 해야 합니다. SCCM이 SUP 역할에 WSUS 서버를 사용하기 시작하면 WSUS 서버가 SCCM에 전용으로 사용되고 SCCM 클라이언트에서만 사용할 수 있게 됩니다.
SUP는 SCCM의 새로운 사이트 시스템 역할입니다. 구성을 시작하려면 관리자 콘솔의 Site Systems(사이트 시스템) 노드로 이동하여 새 사이트 시스템을 추가합니다. 그리고 다음 단계로 소프트웨어 업데이트 지점을 선택하고 마법사를 진행하여 다음 정보를 수집합니다.
  • 프록시 구성
  • 포트 및 SSL 정보
  • 해당 SUP가 업데이트를 동기화하는 방법(Microsoft Update 사용, 업스트림 SUP 사용 또는 수동)
  • 동기화 일정
  • 중요 업데이트, 드라이버, 보안 업데이트, 업데이트 롤업 등의 업데이트 분류
  • Windows®, Exchange, SQL Server™ 등 사용 가능한 업데이트 제품(그림 2 참조)
  • 언어
그림 2 사이트 역할 마법사의 제품 설정
그림 2 사이트 역할 마법사의 제품 설정
마법사를 완료하면 SUP가 설치되고 SCCM 요구 사항을 지원하도록 내부 구성이 조정됩니다. 이때 SCCM이 설치된 로그 폴더에 있는 SUPSetup.log를 검토하여 성공적으로 설치되었는지 확인하는 것이 좋습니다.
SUP가 설치된 후에는 SUP가 업데이트를 검색하여 SUP 및 SCCM 데이터베이스에 저장하도록 동기화를 수행해야 합니다. 동기화는 수동으로 실행하거나 SUP 설치 마법사 실행 시에 구성한 일정에 따라 자동으로 실행할 수 있습니다. 수동 업데이트 동기화는 언제든지 초기화할 수 있으므로 SUP를 처음으로 설치한 후에는 항상 동기화를 실행하는 것이 좋습니다. 그림 3은 이 작업을 수행하는 방법을 보여 줍니다.
그림 3 수동 동기화 실행
그림 3 수동 동기화 실행
동기화 프로세스는 두 단계로 진행됩니다. 먼저 SCCM 설정과 일치하도록 SUP(WSUS) 서버가 구성되고 구성된 업데이트가 SUP(WSUS) 서버 자체와 동기화됩니다. 이 프로세스가 완료되면 SUP(WSUS)의 업데이트 정보가 SCCM 데이터베이스에 동기화되고 업데이트 배포에 사용할 수 있게 됩니다. 이 두 번째 단계에서 필수 CI가 SCCM 데이터베이스에 소프트웨어 업데이트마다 하나씩 생성되기 때문에 다소 시간이 걸릴 수 있습니다. 초기 동기화의 경우 보통 몇 시간 정도 걸립니다. 동기화 프로세스는 WSyncMgr 로그에서 검토할 수 있습니다. 이 로그의 일부가 그림 4와 5에 나와 있습니다. 특히 그림 4는 SUP(WSUS) 서버가 Microsoft Update로부터 해당 업데이트 목록을 업데이트하도록 요청하는 동기화 프로세스를 보여 줍니다. 그림 5의 경우 SUP 인벤토리를 SCCM 데이터베이스에 동기화하는 프로세스의 시작 부분을 보여 줍니다.
그림 4 업데이트 목록 동기화
그림 4 업데이트 목록 동기화
그림 5 업데이트를 SCCM 데이터베이스의 CI로 동기화
그림 5 업데이트를 SCCM 데이터베이스의 CI로 동기화
WSUS 서버를 SUP로 구성한 후에는 SCCM 관리 콘솔을 통해 필요한 모든 관리 작업을 수행할 수 있습니다. WSUS 서버에서 직접 구성을 변경하면 SCCM에 악영향을 미칠 수 있습니다. 게다가 이러한 구성은 1시간마다 SCCM이 SUP의 구성이 올바른지 확인할 때 다시 설정됩니다.
다계층 구조에서는 소프트웨어 업데이트를 배포할 각 기본 사이트마다 SUP가 하나 이상 필요합니다. 이러한 SUP는 계층 구조에서 모두 함께 작동하며 하나의 SUP(일반적으로 계층 구조의 최상위 SUP)만 Microsoft Updates와 동기화됩니다. 그리고 나머지 SUP는 구성된 업스트림 SUP 복제 파트너와 동기화됩니다.

업데이트 배포 구성
클라이언트 에이전트를 구성하고 SUP를 구성 및 동기화하고 나면 실질적인 배포를 수행할 수 있습니다. 먼저 SCCM 관리 UI의 다양한 노드를 살펴보도록 하겠습니다. 기본적으로 중요하게 살펴보아야 할 주요 노드는 Update Repository(업데이트 리포지토리), Update Lists(업데이트 목록), Deployment Templates(배포 템플릿), Deployment Management(배포 관리) 및 Deployment Packages(배포 패키지)의 다섯 가지입니다.
Update Repository(업데이트 리포지토리)는 모든 동기화된 업데이트가 저장되고 배포에 사용하도록 제공되는 노드입니다. 업데이트는 하나 이상의 업데이트를 선택하고 Deploy Software Updates(소프트웨어 업데이트 배포) 마법사를 실행하여 배포할 수 있습니다. 이 마법사는 배포 템플릿을 구성하거나 기존 템플릿을 선택하고 배포 자체를 구성하는 데 사용됩니다. 이 프로세스는 잠시 후에 설명하도록 하겠습니다. 업데이트 목록에 항목이 많은 경우에 SCCM 2007의 새 기능인 검색 폴더를 사용하면 심각도, 분류, 제품, 릴리스 날짜, 유효성 등의 28가지 업데이트 관련 조건에 따라 원하는 업데이트를 쉽게 찾을 수 있습니다.
관리자는 업데이트 목록을 통해 관리할 고정 업데이트 집합을 만들 수 있습니다. 그리고 이러한 업데이트 집합은 규정 준수 보고, 배포 생성 및 관리 위임에 사용할 수 있습니다. 작성된 업데이트 목록은 패키지나 알림처럼 하위 사이트에서 다시 사용할 수 있도록 계층 구조에서 하위 계층으로 복제됩니다. 그러나 업데이트 목록은 단순히 업데이트의 목록에 불과하며 복제될 때 특정 배포에 연결되지는 않습니다. 목록이 작성 및 복제된 후에는 목록을 선택하고 업데이트 배포 옵션을 선택하여 목록에 포함된 모든 업데이트를 하나의 단위로 배포할 수 있습니다.

배포 템플릿
배포 템플릿에는 소프트웨어 업데이트를 배포하는 동안 사용되는 일반 설정(예: 일정 및 대상 컬렉션 정보)이 포함되어 있으며 업데이트 배포와 관련한 관리 시간을 단축하기 위해 개발되었습니다. 동일 환경의 다양한 배포 사항에 맞게 여러 템플릿을 만든 후 배포 마법사에서 적절한 템플릿을 선택하여 손쉽게 사용할 수 있습니다. 이 경우 대상 컬렉션, 업데이트 기한(그림 6 참조), 다시 시작 설정, 유지 관리 시간대 등의 설정이 미리 입력됩니다. 배포할 업데이트 수가 많으면 각 업데이트의 기한이 동시에 도래할 경우 대상 시스템 성능에 영향을 미칠 수 있습니다. 게다가 템플릿의 설정은 배포가 생성될 때 배포에 적용됩니다. 그리고 배포에서 수동으로 설정을 수정하지 않는 한 배포에 계속 적용됩니다. 따라서 나중에 템플릿 설정 자체를 수정하더라도 수정된 템플릿을 사용하는 기존 배포에 변경된 설정이 적용되지는 않습니다.
그림 6 마법사의 설정 배포 일정
그림 6 마법사의 설정 배포 일정
그림 6의 옵션은 배포 템플릿 마법사나 소프트웨어 업데이트 배포 마법사(새 템플릿을 만드는 경우)를 실행할 때 구성할 수 있습니다. 이 화면의 기간은 0으로 설정되어 있지만 이 설정의 기본값은 2주입니다. 이 설정을 0 이외의 값으로 설정하면 클라이언트에서 해당 기간 동안 지연된 후 업데이트가 배포됩니다. 배포가 사용 가능하도록 준비되는 시점과 구성된 기한이 강제 적용되는 시점 사이에 최종 사용자는 예정된 기한 전의 사전 수동 설치를 수행할 수 있습니다. 기한 시간이 되면 업데이트가 강제로 적용 및 설치됩니다. 업데이트 배포가 지연되는 경우 이 설정이 필요에 맞게 올바르게 구성되어 있는지 확인하십시오.

배포 관리
소프트웨어 업데이트 배포를 구성한 후에는 Deployment Management(배포 관리) 노드를 통해 액세스할 수 있습니다. 구성된 소프트웨어 배포는 배포 패키지와는 다릅니다. 이 노드에서 배포에 포함된 업데이트와 배포 관련 설정은 확인하고 조작할 수 있지만 패키지 자체는 표시되지 않습니다. 여기에 표시되는 배포 설정은 소프트웨어 업데이트 마법사에서 구성하는 설정, 그리고 선택한 템플릿에서 상속되는 설정을 반영합니다.

배포 패키지
배포 패키지는 소스 디렉터리, 배포 지점 등의 업데이트 세부 사항을 정의한다는 점에서 표준 SMS 패키지와 유사합니다. 배포 패키지는 업데이트를 배포하는 데 사용되는 실제 배포와는 별개이며 업데이트의 기본 저장 위치가 됩니다. 배포에 필요한 업데이트가 둘 이상의 배포 패키지에 들어 있으면 SCCM 에이전트는 업데이트를 검색할 가장 적합한 위치를 결정하며, 이 경우 업데이트가 포함된 배포 패키지 중 아무 패키지라도 사용될 수 있습니다.
Deploy Software Updates(소프트웨어 업데이트 배포) 마법사는 SCCM에 업데이트를 배포하는 데 사용됩니다. 이 마법사는 개별 업데이트 또는 업데이트 목록과 함께 사용될 수 있습니다. 그림 7은 이 마법사를 시작하는 방법을 보여 줍니다.
그림 7 Deploy Software Updates(소프트웨어 업데이트 배포) 마법사 시작
그림 7 Deploy Software Updates(소프트웨어 업데이트 배포) 마법사 시작
이 마법사는 배포에 사용할 이름, 기존 템플릿 설정 또는 새 템플릿 설정 중 사용할 설정(새 템플릿을 선택한 경우 마법사가 앞서 설명한 템플릿 설정을 물음), 배포 패키지 설정(기존 설정 또는 새 설정), 배포 지점 설정, 다운로드 위치 옵션, 다운로드할 업데이트 언어, 배포 일정 정보 등을 묻는 단계로 진행됩니다.
구성이 완료되면 클라이언트에 대상 업데이트에 대해 알리기 위해 정책이 업데이트되고 업데이트가 클라이언트 시스템에 설치됩니다. 이러한 클라이언트 프로세스는 이전 릴리스와 크게 다르며 이 기사의 범위를 벗어나는 내용입니다. 주요한 차이점 중 하나를 간단히 소개하자면, 업데이트 검색이 더 이상 로컬로 수행되지 않고 SUP가 모든 검색 작업을 처리합니다. 하지만 업데이트 규정 준수에 대한 세부 정보는 이전 버전과 마찬가지로 로컬 WMI(Windows Management Instrumentation) 리포지토리에 저장됩니다.
그러나 이전 버전과는 달리 업데이트 상태를 사이트 서버로 보내는 데 하드웨어 인벤토리가 사용되지 않습니다. 대신 관리 지점을 통해 새로운 유형의 스트리밍된 상태 메시지가 사이트 서버로 전송됩니다. 상태 메시지는 규정 준수 검색과 배포 진행 상태 추적에 사용할 각각의 모든 관리 클라이언트에 대한 데이터를 제공합니다. SCCM에는 각 클라이언트에 배포된 모든 업데이트의 전반적인 컴퓨터별 규정 준수 상태, 클라이언트별 배포 강제 적용 상태, 검색 및 배포를 위해 해결해야 할 가장 큰 문제에 대한 등급이 매겨진 목록을 제공하는 클라이언트 오류 보고서 등 새로운 소프트웨어 업데이트 관리용 보고서가 많이 추가되었습니다.
SCCM에서는 추가 예약/필수 업데이트 배포 정의 기능뿐만 아니라 일정에 구성된 설치 기한 전에 승인된 업데이트를 설치할 수 있는 기능도 제공됩니다. 이 기능은 최신 자동 업데이트 도구와 매우 유사합니다. 이 유용한 추가 기능은 배포 기한 전에 호환 시스템 수를 늘릴 수 있는 다른 기능도 제공합니다.
SCCM에서는 사용자 지정 업데이트도 수행할 수 있습니다. SMS 2003 R2의 사용자 지정 업데이트 게시 도구는 System Center Updates Publisher로 SCCM 2007과 함께 사용하도록 수정되었습니다. 따라서 사용자 지정 업데이트도 여기서 설명하는 것과 같은 방법으로 배포할 수 있습니다.
SCCM에서는 업데이트 관리 방식이 크게 변경되었지만 관리 측면에서는 사용에 어려움이 없고 이전 버전에 비해 크게 향상되었다고 할 수 있습니다. SMS 2003에 익숙한 사용자의 경우 처음에는 일부 개념상의 변화가 다소 생소할 수 있지만 새로운 방식은 시간을 투자할 가치가 충분합니다. 자, 지금부터 배워보시기 바랍니다.

Steve Rachui는 Microsoft 기술 지원 서비스 그룹의 관리 효율성 지원 향상 엔지니어로, SMS 버전 1.2부터 SMS를 지원해 왔습니다. 문의 사항이 있으면 steverac@microsoft.com으로 연락하시면 됩니다.


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

Microsoft의 Exchange Edge 전송 서버
한 눈에 보기:
  • Exchange Edge 전송 서버 역할
  • 테스트 환경 설정
  • 전송 에이전트 및 이벤트
  • 에이전트 내부
이 기사의 코드 다운로드: ExchangeEdge2007_10.exe (354KB)

Microsoft에서는 업무일 기준으로 인터넷을 통해 하루 평균 약 1,300만 건의 메시지 전송 시도가 발생하고 있으며, 이 중에서 1,050만 건 이상의 합법적이지 않은 메시지가 차단됩니다.
인터넷에서 스팸 공격이 발생하거나 바이러스가 출현하는 등의 위험한 상황이 발생할 경우 합법적이지 않은 메시지의 수는 9,000만 건 이상으로 늘어날 수 있습니다. 물론 이 수치는 Microsoft를 기준으로 산출된 것이지만 온라인 사기, 스팸, 피싱, 전자 메일을 이용한 바이러스, 디렉터리 수집 공격, DDoS(분산 서비스 거부) 공격 등의 위협은 Microsoft만의 문제가 아닙니다. 이러한 상황에 직면할 경우 조직 내 사용자에게 합법적인 메시지는 모두 전달되도록 하면서 수많은 악의적이며 합법적이지 않은 콘텐츠가 조직의 메시징 환경에 침투하지 못하도록 하려면 어떻게 해야 할까요?
메시징 환경을 안정적으로 보호하는 한 가지 수단으로 인터넷과 조직의 프로덕션 환경 사이에 있는 경계 네트워크에 Exchange Server 2007 Edge 전송 서버와 Forefront Security for Exchange Server를 배포하는 방법이 있습니다. 이 경우 10개가 넘는 Edge 전송 에이전트가 경계 네트워크에 적절하게 배치되어 프로덕션 시스템과 사용자를 보호합니다. 불필요한 콘텐츠를 최대한 신속하게 차단할 때 얻게 되는 효과는 명백합니다. 위험한 상황이 발생할 경우 조직의 메시징 환경이 감당해야 하는 부하를 고려한다면 악의적인 콘텐츠가 서버로 유입되기 전에 이러한 보호 수단이 효력을 발휘하는 것이 가장 이상적입니다. 하지만 메시징 보호에는 단순히 메시지를 차단하는 것 이상의 많은 요소가 관련됩니다.
이 기사는 Exchange Server 2007과 Forefront Security for Exchange Server에서 사용할 수 있는 바이러스 및 스팸 방지 에이전트의 주요 기능과 아키텍처에 대해 다루는 2부 연재 기사 중 1부입니다. 실질적이고 실용적인 설명을 위해 1부 기사에서는 Microsoft가 자사의 프로덕션 환경에서 사용하는 메시징 보호 디자인이 반영되도록 테스트 환경을 설정하는 방법을 살펴본 다음, Exchange Server 2007의 Edge 전송 아키텍처에 대해 자세히 설명하겠습니다.
이 기사에서는 대부분의 중요 구성 작업을 자동화하기 위해 많은 스크립트와 배치 파일을 사용합니다. 이러한 파일에는 수행되는 개별 단계에 대해 설명하는 주석이 포함되어 있습니다. 스크립트는 TechNet Magazine 웹 사이트(technetmagazine.com/code07.aspx)에서 다운로드할 수 있습니다.

Edge 전송 토폴로지
그림 1에서는 Microsoft IT 팀이 회사 프로덕션 환경에 구현해 놓은 Edge 전송 디자인을 보여 줍니다. 여기에는 매우 흥미로운 디자인상의 몇 가지 특징이 있는데 먼저 이들에 대해 살펴본 다음 Edge 전송 아키텍처에 대해 설명하겠습니다. 구현 세부 사항에 대한 자세한 내용은 "Exchange 리소스" 추가 기사에 나오는 IT Showcase 백서를 참조하십시오.
그림 1 Microsoft의 Edge 전송 토폴로지
그림 1 Microsoft의 Edge 전송 토폴로지
그림 1을 자세히 보면 Microsoft의 Edge 전송 토폴로지가 완전하게 중복되어 단일 장애 지점이 발생할 수 있는 곳이 한 군데도 없음을 알 수 있습니다. 부하 분산을 위해 Microsoft IT 팀에서는 외부적으로는 DNS 라운드 로빈을 사용하고 내부적으로는 여러 개의 브리지헤드가 있는 메시징 커넥터를 사용합니다. 또한 허브 전송 및 Edge 전송을 비롯한 모든 전송 서버에서는 바이러스 검사를 위해 Forefront Security for Exchange Server를 실행하고 있다는 점도 눈여겨보십시오. 이를 통해 Microsoft IT 팀은 인바운드, 아웃바운드, 내부 메시지 등의 모든 메시지가 메시지 라우팅 토폴로지의 전송 서버에 도달하면 곧바로 이를 검사할 수 있습니다.
보안과 관련된 또 한 가지 중요한 특징은 Edge 전송 서버가 회사 Active Directory® 환경에 포함되지 않는다는 점입니다. 사실 어떠한 Active Directory 포리스트에도 Edge 전송 서버를 배포할 필요는 없습니다. 하지만 일관된 관리 프레임워크를 유지하고, 공통된 정책 집합을 적용하며, Single Sign-On을 지원하기 위해 Microsoft IT 팀에서는 프로덕션 환경과는 별도의 엑스트라넷 포리스트에 모든 Edge 전송 서버를 배포했습니다.
마지막으로, 인터넷을 통해 들어오는 모든 메시지는 북미 지역에 있는 Edge 전송 서버를 통해 Microsoft에 도달한다는 것을 알 수 있습니다. 더블린과 싱가포르에 있는 Edge 전송 서버는 아웃바운드 메시지만 처리합니다. 이렇게 모든 인바운드 트래픽을 북미에 있는 Edge 전송 서버에서 처리하도록 하면 보안 및 스팸 방지 작업을 중앙 집중화하는 동시에 아웃바운드 메시지가 지역별 주요 데이터 센터에서 내부 메시징 백본을 경유하여 전송되는 것을 방지하는 효과를 얻을 수 있습니다.
Microsoft의 Edge 전송 토폴로지는 Microsoft IT 팀의 시스템 엔지니어인 Omesh Desai가 디자인했습니다. Omesh에게 이 디자인의 가장 중요한 특징이 무엇인지 물었는데 이렇게 답했습니다. "이 Edge 전송 디자인에서는 메시징 보호를 위해 메시징 백본의 여러 계층에서 Exchange의 기본 스팸 방지 및 바이러스 백신 기능을 사용합니다. 메시징 경계의 보안을 최우선적으로 고려하였지만 단순한 관리 및 유지 모델 또한 매우 중요했습니다. Edge 전송 서버를 사용함으로써 방화벽을 보다 강력하게 구성하여 보안을 강화하는 동시에 IP 신뢰도 서비스, 콘텐츠 필터 자동 업데이트, Safelist Aggregation, 전자 메일 소인 유효성 검사 등을 통해 스팸을 보다 정확하게 필터링할 수 있게 되었습니다. 내부에서 이루어지는 모든 서버 간 통신은 기본적으로 암호화되며 가능한 경우에는 외부 대상과의 통신도 암호화됩니다.
Edge 전송 서버에는 두 개의 듀얼 코어 64비트 프로세서와 8GB의 메모리를 사용하고 있습니다. 이러한 서버 여섯 대를 두 곳의 데이터 센터에 설치하여 부하를 분산시킴으로써, 인터넷에서 바이러스가 출현하는 등의 위험한 상황이 발생할 경우 메시지 전송량이 급격히 증가하더라도 충분히 대응할 수 있게 되었습니다."

Edge 전송 테스트 환경
테스트 환경 설정
존재하지 않는 도메인 이름과 개인 IP 주소를 사용하는 것이 가장 좋으므로 여기에서는 AdventureWorks.com과 192.168.xxx.0-24 범위의 IP 주소를 사용하겠습니다. 지금은 부하 분산이나 내결함성을 테스트하는 것이 아니므로 중복 시스템이나 방화벽 배열은 사용하지 않겠습니다. 물론 Microsoft IT 팀에서 사용하는 실제 방화벽 시스템에 대해서는 보안상의 이유로 설명할 수도 없습니다. 어쨌든 이 테스트 환경에서는 이러한 세부적인 사항은 중요하지 않습니다.
이 테스트 환경에서는 Exchange Server 2007에 가장 일반적으로 사용되는 방화벽 시스템 중 하나인 ISA Server 2006을 사용합니다. 외부 및 내부 방화벽 모두에서 ISA Server 2006을 실행하면 테스트 환경의 복잡함을 적정 수준으로 유지할 수 있어서 좋지만 프로덕션 환경에서는 다양한 내부 및 외부 방화벽 시스템을 통해 보안을 강화하는 것이 좋습니다. IPsec(IP 보안) 정책을 배포하거나 TLS(전송 계층 보안) 환경을 준비하는 것은 이 기사의 범위를 벗어나는 것이므로 제외했습니다.
한편, 가상 컴퓨터와 32비트 평가용 소프트웨어를 사용했으며 이것은 Microsoft 웹 사이트에서 다운로드할 수 있습니다. Microsoft는 프로덕션 환경에서는 32비트 버전의 Exchange Server 2007을 지원하지 않지만 이것은 테스트 환경에서는 문제가 되지 않습니다.
이 테스트 환경에서는 가능하면 기본 설정을 사용합니다. Exchange Server 2007 설치 프로그램을 실행하고 Edge 전송 서버를 프로덕션 환경에 추가하기 전에 IP 구성, 방화벽 및 DNS 영역에만 세심한 주의를 기울이면 됩니다. IP 구성과 관련한 자세한 내용은 함께 다운로드할 수 있는 Test Lab—IP Configuration.xls 파일을 참조하십시오. 동일한 IP 주소 할당 방법을 사용하는 경우 ISA01 컴퓨터에서 직접 ISA01_Firewall_Policies.vbs 스크립트를 실행하여 외부 방화벽(ISA01)을 빠르게 구성할 수 있으며 내부 방화벽(ISA02)에는 ISA02_Firewall_Policies.vbs를 사용할 수 있습니다. 함께 다운로드할 수 있는 파일에는 DNS 서버를 구성하는 데 사용되는 배치 파일(INTERNET01_DNS_Config.bat, AD01_DNS_Config.bat 및 AD02_DNS_Config.bat)도 포함되어 있습니다. 이러한 배치 파일은 DNS 명령줄 도구(dnscmd.exe)를 사용하므로 Windows 지원 도구가 설치되어 있어야 하며, 설치되어 있지 않으면 DNS 콘솔을 사용하여 직접 DNS 레코드를 만들어야 합니다.
기존 환경으로부터의 간섭을 피하기 위해 이 테스트 환경은 인터넷에 연결되어 있지 않습니다. 인터넷으로부터 격리하는 것은 좋은 예방책입니다. 이로 인해 서명 업데이트, IP 신뢰도, 콘텐츠 필터 업데이트가 다운로드되지 않지만 테스트 환경에서는 이러한 업데이트가 중요하지 않으므로 상관없습니다. 오류 메시지가 나타나지 않도록 하려면 Forefront Server Security Administrator 콘솔의 검색 프로그램 업데이트로 이동하여 모든 검색 프로그램의 업데이트 빈도를 한 번으로 설정한 다음 날짜를 과거의 날짜로 지정하면 됩니다.

이러한 기능이 실제로 어떻게 작동하는지 살펴보려면 테스트 환경을 만드는 것이 좋습니다. 프로덕션 시스템을 직접 테스트에 사용하지 않아야 한다는 것은 상식이라고 할 수 있습니다. 최소 구성의 경우 사서함, 클라이언트 액세스, 허브 전송 서버 역할을 위해 Exchange Server 2007을 실행하는 한 대의 서버가 있어야 합니다. Edge 전송 서버 역할에는 또 다른 Exchange 서버가 필요합니다. 허브 전송 서버의 %ProgramFiles%\Microsoft\Exchange Server\Scripts 폴더에 있는 Install-AntispamAgents.ps1 스크립트를 실행하여 모든 전송 에이전트를 다중 역할 서버에 배포하는 경우에는 Edge 전송 서버 설치를 생략할 수 있습니다. 하지만 이 방법은 Microsoft IT 팀이 배포한 방법과는 유사한 점이 거의 없습니다. 테스트 환경을 좀 더 현실적으로 구성하려면 몇 대의 서버를 더 추가해야 합니다. 그림 2에서는 필자가 이 기사를 작성하는 데 사용한 테스트 환경을 보여 줍니다. 보다 자세한 그림은 함께 다운로드할 수 있는 파일에 포함되어 있습니다. 테스트 환경 설정에 대한 자세한 내용은 "테스트 환경 설정" 추가 기사를 참조하십시오.
그림 2 Edge 전송 테스트 환경
그림 2 Edge 전송 테스트 환경
Edge 전송 서버를 구독하고 관련 커넥터를 구성하는 동안 Microsoft IT 팀은 기본 커넥터를 모두 제거한 다음 각기 다른 종류의 SMTP(Simple Mail Transfer Protocol) 호스트 및 내부 허브 전송 서버와의 효율적인 통신을 위해 4개의 송신 커넥터를 만들었습니다. 첫 번째 송신 커넥터는 특정 주소 공간 정의와 일치하지 않는 모든 대상에 사용되는 일반 인터넷 커넥터입니다.
두 번째 송신 커넥터는 확장 SMTP를 지원하지 않는 알려진 대상(HELO 도메인)을 위한 세부 주소 공간 정의가 있는 인터넷 커넥터입니다. Microsoft IT 팀은 이 커넥터의 ForceHELO 매개 변수를 $true로 설정함으로써 SMTP 연결을 설정할 때는 불필요한 EHLO, 실패 응답 500, HELO 단계를 건너뜁니다.
세 번째 송신 커넥터는 암호화된 연결을 통한 보안 통신을 위해 TLS를 지원하는 파트너 및 다른 원격 도메인(TLS 도메인)을 위한 세부 주소 공간 정의가 있는 인터넷 커넥터입니다. 이 커넥터의 RequireTLS 매개 변수는 $true로 설정되어 있습니다.
네 번째 송신 커넥터는 수신한 인터넷 메시지를 회사 환경 내의 허브 전송 서버로 전송하기 위한 인바운드 커넥터입니다. Edge 전송 서버 구성에 대한 자세한 내용은 이 기사의 뒷부분에 있는 "Exchange 리소스" 추가 기사에 나오는 IT Showcase 백서를 참조하십시오.
Microsoft IT 팀에서 사용한 것과 비슷한 커넥터 토폴로지를 테스트 환경에 적용하기 위해 필자는 Omesh가 Microsoft IT 내부용으로 만든 스크립트에 바탕을 두는 절차를 따랐습니다. 보안상의 이유로 개별 명령들을 대폭 바꾸고 간소화했지만 결과적으로 만들어지는 커넥터 토폴로지는 Microsoft IT 토폴로지와 같습니다. 단계는 다음과 같습니다.
  1. 다중 역할 Exchange 서버(HUB-MBX-01)와 Edge 전송 서버(EDGE01)에서 기본 커넥터를 제거합니다.
  2. HUB-MBX-01에서 이 기사의 다운로드에 있는 HUB-MBX-01_recv_connector.ps1 스크립트를 실행하여 새 수신 커넥터를 만듭니다.
  3. EDGE01에서 EDGE01_recv_connector.ps1 스크립트를 실행하여 내부 및 외부 메시징 연결에 사용할 두 개의 새 수신 커넥터를 만듭니다.
  4. EDGE01에서 다음 명령을 실행하여 구독 파일을 만듭니다.
    New-EdgeSubscription -FileName
    "c:\subscriptionfile.xml"
그런 다음 만들어진 구독 파일을 허브 전송 서버의 루트 폴더(c:\subscriptionfile.xml)에 복사합니다.
5. HUB-MBX-01에서 구독 파일의 경로가 c:\subscriptionfile.xml인지 확인한 다음 HUB-MBX-01_complete_subscription.ps1 스크립트를 실행합니다. 이 스크립트는 송신 커넥터를 자동으로 만들지 않고 Edge 동기화를 위해 구독 파일을 가져오고, 인터넷 및 내부 연결에 사용할 송신 커넥터를 만들고, 결과적으로 생성되는 구성을 Edge 동기화를 통해 Edge 전송 서버에 복제합니다.
6. Contoso.User@contoso.com 및 Fabrikam.User@fabrikam.com을 보낸 사람으로 하여 인터넷 호스트에서 Administrator@adventureworks.com으로 테스트 메시지를 보낸 다음 받은 메시지에 대해 회신을 함으로써 인바운드 및 아웃바운드 메시지 전송이 작동하는지 확인합니다.
개별 스크립트 파일을 메모장에서 열어 이러한 스크립트가 구성 작업을 수행하는 데 사용하는 cmdlet와 매개 변수를 분석해 보는 것이 좋습니다. cmdlet 및 매개 변수에 대한 자세한 내용은 Exchange Server 2007 제품 설명서에서 온라인으로 확인할 수 있습니다.

Edge 전송 아키텍처
이제 Edge 전송 서버 역할을 설치한 이후 누군가가 HELO나 EHLO라고 말할 때까지 기다려 온 Edge 전송 에이전트에 대해 살펴보겠습니다. Edge 전송 서버에서 Get-TransportAgent cmdlet를 실행하면 그림 3에 나오는 11개의 항목이 표시됩니다. 모든 에이전트는 기본적으로 활성화되어 적절한 설정을 통해 메시징 보호 기능을 제공합니다.
Figure 3 전송 에이전트 (Close Figure 3)

SMTP 수신 에이전트
연결 필터 에이전트
주소 다시 쓰기 인바운드 에이전트
Edge 규칙 에이전트
콘텐츠 필터 에이전트
보낸 사람 ID 에이전트
보낸 사람 필터 에이전트
받는 사람 필터 에이전트
프로토콜 분석 에이전트
첨부 파일 필터링 에이전트
라우팅 에이전트
주소 다시 쓰기 아웃바운드 에이전트
FSE 라우팅 에이전트
Get-TransportAgent cmdlet와 그림 3에서는 에이전트를 우선 순위별로 보여 주지만 이 순서가 에이전트의 작업 수행 순서는 아닙니다. 작업 순서는 주로 SMTP 수신 이벤트 및 라우팅 이벤트에 대해 에이전트가 등록된 순서에 따라 달라집니다. 에이전트와 이벤트의 상호 작용 방법을 보려면 전송 에이전트가 Edge 전송 아키텍처에 통합되는 방법을 보여 주는 그림 4의 다이어그램을 참조하십시오.
그림 4 Edge 전송 아키텍처 내의 전송 에이전트
그림 4 Edge 전송 아키텍처 내의 전송 에이전트
전송 이벤트는 스팸 필터링, 바이러스 검사 및 기타 작업을 위한 추가 코드를 호출하기 위해 메시지 처리 중 여러 단계에서 발생합니다. 이렇게 느슨하게 연결되고 확장 가능한 디자인에서는 Edge 전송 프로세스(EdgeTransport.exe)가 이벤트 원본 역할을 합니다. 이벤트 처리기, 즉 전송 에이전트는 콜백 알림을 받기 위해 이벤트 원본에 등록하는 Microsoft® .NET Framework 2.0 기반의 관리되는 대리자 개체입니다.
그림 5에서는 Forefront Security와 함께 Edge 전송 서버에 설치된 모든 에이전트에 대한 이벤트 등록을 보여 줍니다. 등록된 에이전트 수가 많기 때문에 이를 분류하기는 다소 어렵지만 걱정할 필요는 없습니다. Edge 전송 서버에서 Get-TransportPipeline | Format-List 명령을 실행하면 개별 전송 이벤트에 대한 등록을 간편하게 분석할 수 있습니다. Microsoft Exchange Transport 서비스(MSExchangeTransport.exe)가 실행 중인지 확인하고 서비스를 마지막으로 다시 시작한 이후 Edge 전송 서버를 통해 한 개 이상의 메시지를 전송했는지 확인하면 됩니다. 출력에서 볼 수 있듯이 여러 에이전트가 동일한 이벤트 유형에 등록하거나 개별 에이전트가 여러 이벤트에 등록할 수 있습니다. 이벤트 등록은 해당 에이전트의 처리 요구 사항에 따라 다릅니다.
그림 5 전송 에이전트에 대한 이벤트 등록
그림 5 전송 에이전트에 대한 이벤트 등록
가장 중요한 이벤트 중 하나는 메시지가 전송 큐에 도착할 때 트리거되는 OnSubmittedMessage 라우팅 이벤트입니다. SMTP, 파일 시스템 또는 다른 어떤 메커니즘을 통해 들어오는 메시지도 모두 이 큐를 통과해야 합니다. 분류기는 받는 사람 확인, 메시지 분기 및 라우팅, DSN(배달 상태 알림) 생성을 담당하는 Exchange Server 전송 아키텍처의 핵심 구성 요소입니다. 따라서 OnSubmittedMessage 이벤트는 받은 메시지를 모두 처리해야 하는 에이전트를 위한 최적의 등록 옵션입니다. FSE 라우팅 에이전트는 받은 모든 메시지를 바이러스 검사 엔진에 전달하기 위해 OnSubmittedMessage 이벤트에 등록된 Forefront Security 구성 요소입니다. FSE 라우팅 에이전트는 OnSubmittedMessage 이벤트에 등록되어 있으므로 어떤 메시지도 바이러스 백신 솔루션을 우회할 수 없습니다.
그렇다면 모든 에이전트가 OnSubmittedMessage 이벤트에 등록하면 되는데 그렇게 하지 않는 이유는 무엇일까요? 이는 불필요한 메시지를 가능한 한 신속하게, 즉 서버에서 성공적 배달을 확인하기 전에 차단하기 위해서입니다. 가능한 한 신속하게 차단하지 못하는 경우 스팸 또는 바이러스 공격이 감행되는 동안 서버에서 9,000만 개의 불필요한 메시지를 처리해야 하고 9,000만 개의 NDR(배달 못 함 보고서)을 생성해야 할 수도 있는데 이는 순진한 방관자에게는 심각한 위협이 될 수 있습니다. 스팸 및 바이러스 공격은 항상 위조된 보낸 사람 정보를 사용합니다. 원래 메시지를 만들지 않은 받는 사람에게 수백만 개의 NDR을 보내는 경우 사용자 조직의 리소스와 함께 대상 조직의 리소스가 낭비될 뿐만 아니라 악의적 사용자에게 메일 폭탄 및 DDoS 공격을 실행할 빌미를 주게 됩니다. 자신의 조직은 물론 다른 사용자의 조직을 보호하기 위해서는 악의적인 보낸 사람의 행위를 도중에 차단하는 것이 중요합니다.
메시지를 효율적으로 차단하려면 서버에서 250 OK라는 상태 코드가 있는 데이터의 수신을 확인하기 전에 전송 에이전트가 원격 호스트와의 SMTP 대화를 중단시켜야 합니다. SMTP 축적 전송 원칙에 따라 서버에서는 메시지 배달이 확인되지 않은 경우 NDR을 생성하지 않고도 받은 데이터를 안전하게 삭제할 수 있습니다. SMTP 수신 에이전트가 이 작업을 수행할 수 있습니다. SMTP 수신 에이전트는 SMTP 세션과 상호 작용하는데 이는 원격 호스트가 서버에 연결할 때 전송 파이프라인이 SMTP 수신 이벤트를 기반으로 이러한 에이전트를 호출하고, SMTP 세션을 설정하고, SMTP 동사를 전송하고, 메시지를 전송하고, 연결을 종료하기 때문입니다. 각 단계와 관련된 SMTP 수신 이벤트는 그림 6에 나옵니다. 모든 Exchange Server 2007 스팸 방지 에이전트는 메시지가 배달되기 전에 메시지를 거부하고 원격 SMTP 호스트에서 연결을 끊을 수 있으므로 SMTP 수신 에이전트로 구현됩니다.
Figure 6 SMTP 세션 이벤트 (Close Figure 6)

작업 | 관련 이벤트
서버에 연결 | OnConnectEvent
SMTP 세션 설정 | OnHeloCommand, OnEhloCommand, OnAuthCommand, OnEndOfAuthentication
SMTP 동사 전송 | OnMailCommand, OnRcptCommand, OnDataCommand, OnNoopCommand, OnHelpCommand
메시지 전송 | OnEndOfHeaders, OnEndOfData
명령 또는 메시지 거부 | OnReject
연결 다시 설정 | OnRsetCommand
연결 종료 | OnDisconnect
처리 컨텍스트와 관련하여 SMTP 수신 에이전트와 라우팅 에이전트의 차이점을 올바르게 이해하는 것이 중요합니다. 라우팅 에이전트는 메시지 속성에 대한 모든 권한을 갖는 반면 SMTP 수신 에이전트는 SMTP 세션과 상호 작용하므로 컨텍스트와 보다 밀접하게 관련됩니다. 예를 들어 원격 호스트가 실제로 메시지를 전송하기 전까지는 메시지 속성에 대해 스팸 필터가 작동할 수 없습니다. 따라서 에이전트를 올바른 SMTP 수신 이벤트에 등록하는 것이 중요합니다. 자세한 내용은 "전송 에이전트 개발" 추가 기사를 참조하십시오.

Exchange 리소스
  • Microsoft Exchange Server 2007 Edge 전송 및 메시징 보호(Microsoft IT Showcase 기술 백서)
  • Windows PowerShell 스크립트 센터
  • Exchange Server 2007 TechCenter
  • Microsoft Exchange 팀 블로그 "You Had Me From EHLO"

계속
전송 아키텍처 및 테스트 시나리오에 대해서는 다음 기사에서 자세히 살펴보도록 하겠습니다. 이 기사에서는 Microsoft IT 팀에서 수행한 것과 유사한 방식의 Edge 전송 서버 배포부터 메시지 처리 중 전송 파이프라인에서 트리거되는 내부 이벤트에 이르는 다양한 부분에 대해 다루었습니다. 2부에서는 몇 가지 흥미로운 테스트 시나리오를 통해 Edge 전송 에이전트의 동작을 분석해보도록 하겠습니다.
90일 무료 평가판인 Microsoft Visual Studio 2005 Professional Edition(go.microsoft.com/fwlink/?LinkId=98043)을 다운로드한 다음 Steve의 설명에 따라 테스트 환경에 샘플 에이전트를 컴파일하고 설치해 보십시오. 개발자가 아니더라도 이러한 작업을 수행하는 것은 매우 간단합니다. Visual Studio 2005를 사용하여 Exchange Server 2007에서 이러한 구성 요소를 개발하는 것이 얼마나 편리한지 감안한다면 사용자 지정 에이전트에 의존하는 비즈니스 응용 프로그램의 수가 급증하고 있다는 것이 그다지 놀라운 일은 아닙니다.

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


 SQL Server: SQL Server CPU 성능 최적화
SQL Server Zach Nichter

SQL Server CPU 성능 최적화
한 눈에 보기:
  • 데이터베이스 성능 문제 해결
  • 하드웨어 원인 검토
  • PerfMon을 사용하여 데이터베이스 병목 상태 추적
  • 쿼리 성능 평가

데이터베이스 시스템의 성능 문제를 해결하는 작업은 매우 복잡할 수 있습니다. 문제가 어디에서 발생하는지 파악하는 것도 중요하지만 시스템이 특정 요청에 대해 현재와 같이 반응하는 이유를 알아내는 것이 더욱 중요합니다. SQL 문의 컴파일 및 재컴파일, 누락된 인덱스, 다중 스레드 작업, 디스크 병목 상태,
메모리 병목 상태, 일상적인 유지 관리 작업, ETL(추출, 변환, 로드) 작업을 비롯한 많은 요소가 데이터베이스 서버의 CPU 사용률에 영향을 줄 수 있습니다. CPU 사용률 자체가 나쁜 것은 아닙니다. 작업을 수행하는 것이야말로 CPU의 존재 이유니까요. 다시 말하지만 CPU 사용률을 적정 수준으로 유지하기 위해서는 CPU가 최적화되지 않은 코드나 느린 하드웨어에서 프로세서 주기를 낭비하는 대신 사용자가 원하는 작업을 처리하는 데 시간을 할애하도록 하는 것이 필수입니다.

서로 다르지만 목적은 같은 두 가지 방법
크게 봐서 CPU 성능 문제를 확인하는 방법은 두 가지입니다. 하나는 시스템 하드웨어의 성능을 검토하는 것입니다. 이 방법은 다음에 나오는 두 번째 방법에 따라 서버의 쿼리 효율성을 검토할 때 어느 부분을 조사해야 하는지 결정하는 데 도움이 됩니다. 일반적으로 두 번째 방법이 SQL Server™의 성능 문제를 파악하는 데 있어서 더 효과이지만, 쿼리 성능 문제의 원인이 어디에 있는지 정확히 알고 있는 경우가 아니면 시스템 성능부터 확인해 보는 것이 좋습니다. 대개는 두 가지 방법을 모두 사용하게 됩니다. 이제 이 두 가지 방법을 자세히 살펴보기 전에 기본적인 몇 가지 사항에 대해 알아보겠습니다.

기본 개념 형성
하이퍼 스레딩
하이퍼 스레딩은 SQL Server에 꽤 많은 영향을 주므로 이에 대해 자세히 설명할 필요가 있습니다. 하이퍼 스레딩은 각각의 물리적 프로세서에 대해 두 개의 논리적 프로세서를 OS에 제공합니다. 하이퍼 스레딩은 기본적으로 물리적 프로세서의 시간을 빌려 씀으로써 각 프로세서의 사용률을 높입니다. 하이퍼 스레딩의 작동 방법에 대한 자세한 설명은 Intel 웹 사이트(intel.com/technology/platform-technology/hyper-threading/index.htm)를 참조하십시오.
SQL Server 시스템의 경우 DBMS에서 고유의 매우 효율적인 큐 및 스레딩을 OS에 제공하므로 CPU 사용률이 이미 높은 시스템의 경우 하이퍼 스레딩은 시스템의 물리적 CPU를 오버로드하는 기능만 하게 됩니다. SQL Server가 여러 스케줄러에서 작업을 수행하기 위해 여러 개의 요청을 큐에 놓을 때 OS는 두 개의 논리적 프로세서가 동일한 물리적 프로세서에 있는 경우에도 계속해서 만들어지는 요청에 만족하도록 물리적 프로세서에서 스레드 컨텍스트를 실제로 전환해야 합니다. 물리적 프로세서당 Context Switches/sec가 5000 이상이면 시스템의 하이퍼 스레딩을 해제하고 성능을 다시 테스트해야 합니다.
드물기는 하지만 SQL Server에서 CPU 사용률이 높은 응용 프로그램이 하이퍼 스레딩을 효과적으로 사용할 수 있는 경우도 있습니다. 프로덕션 시스템에서 변경을 구현하려면 항상 먼저 하이퍼 스레딩을 각각 설정 및 해제한 상태로 SQL Server에서 응용 프로그램을 테스트해야 합니다.

최고급 듀얼 코어 프로세서의 경우 시스템의 RAM보다 성능이 뛰어나므로 결국 연결된 저장 장치보다 속도가 빨라지게 됩니다. 성능이 우수한 CPU의 처리량은 현재 최고급 DDR2 메모리보다 6배 가량 많고 최고급 DDR3 메모리보다는 2배 가량 많습니다. 일반적인 메모리 처리량은 가장 빠른 파이버 채널 드라이브의 10배 이상입니다. 다시 말해 하드 디스크는 IOPS(초당 입/출력 작업 수)만큼의 한정된 작업만 수행할 수 있으며 이 수치는 드라이브 한 개가 수행할 수 있는 초당 검색 수에 따라 결정됩니다. 공정하게 비교하자면, 엔터프라이즈 데이터베이스 시스템의 모든 저장소 요구 사항을 처리하기 위해 단 한 개의 저장소 드라이브만 사용되는 경우는 드뭅니다. 현재 사용되는 대부분의 설치 프로그램은 엔터프라이즈 데이터베이스 서버의 SAN(저장 영역 네트워크) 또는 디스크 I/O 프로세서 문제를 없애거나 최소화할 수 있는 대규모 RAID 그룹을 사용합니다. 가장 중요한 점은 설치 프로그램의 형태에 관계없이 디스크 및 메모리 병목 상태는 프로세서의 성능에 영향을 줄 수 있다는 것입니다.
I/O 속도의 차이로 인해 디스크에서 데이터를 검색하는 경우 메모리에서 데이터를 검색할 때보다 비용이 훨씬 많이 듭니다. SQL Server의 데이터 페이지 하나는 8KB이고 익스텐트 하나는 8KB 페이지 8개로 구성되어 있으므로 64KB입니다. 이 값을 정확히 알고 있어야 하는데 그 이유는 SQL Server가 디스크에서 특정 데이터 페이지를 요청할 경우 해당 데이터 페이지뿐 아니라 데이터 페이지가 있는 전체 익스텐트가 검색되기 때문입니다. SQL Server의 경우 이렇게 비용이 많이 드는 데에는 이 외에도 많은 이유가 있지만 여기에서는 이에 대해 자세히 설명하지 않겠습니다. 이미 캐시된 데이터 페이지를 버퍼 풀에서 가져오는 데 걸리는 시간은 0.5밀리초 미만이고(성능이 최적인 경우), 디스크에서 단일 익스텐트를 검색하는 데 걸리는 시간은 2~4밀리초입니다(최적 환경의 경우). 일반적으로 성능 및 상태가 좋은 디스크 하위 시스템에서 읽는 경우 4~10밀리초가 걸릴 것으로 예상됩니다. 그리고 메모리에서 데이터 페이지를 검색하는 속도는 디스크에서 데이터 페이지를 가져오는 속도보다 4~20배가 빠릅니다.
SQL Server는 데이터 페이지를 요청할 때 디스크 하위 시스템의 데이터 페이지를 검색하기 전에 먼저 메모리 내 버퍼 캐시를 확인합니다. 데이터 페이지가 버퍼 풀에 있으면 프로세서가 데이터를 검색한 다음 필요한 작업을 수행하는데 이를 소프트 페이지 폴트라고 합니다. 소프트 페이지 폴트는 SQL Server에 가장 이상적입니다. 이는 요청의 일부로 검색되는 데이터를 사용할 수 있으려면 데이터가 먼저 버퍼 캐시에 있어야 하기 때문입니다. 버퍼 캐시에 없는 데이터 페이지는 서버의 디스크 하위 시스템에서 검색해야 합니다. OS가 디스크에서 데이터 페이지를 검색해야 하는 경우 이를 하드 페이지 폴트라고 합니다.
메모리 성능, 디스크 성능, CPU 성능을 연관 지어 검토할 때 처리량을 공통 분모로 정하면 전체적인 사항을 파악하는 데 도움이 됩니다. 그다지 과학적이지 않은 이 처리량이라는 용어는 유한한 파이프 안에 넣을 수 있는 데이터의 양에 대한 측정치입니다.

방법 1: 시스템 성능
서버에 CPU 병목 상태가 있는지 확인하는 방법은 실제로는 몇 가지에 불과합니다. 또한 CPU 사용률을 높일 만한 원인도 그다지 많지 않습니다. 이러한 문제 중 몇 가지는 PerfMon이나 이와 비슷한 시스템 모니터링 도구를 사용하여 추적할 수 있고, 그 외 다른 문제는 SQL 프로파일러나 이와 비슷한 도구를 사용하여 추적할 수 있습니다. 쿼리 분석기나 SQL Server Management Studio(SSMS)를 통해 SQL 명령을 사용하는 방법도 있습니다.
시스템 성능을 평가할 때 필자는 광범위하게 시작해서 세부적으로 들어가는 방식을 취합니다. 분명한 건 문제가 있는 영역을 파악하기 전까지는 문제를 세부적으로 조사할 수 없다는 것입니다. 먼저 PerfMon 같은 도구를 사용하여 전반적인 CPU 사용률을 평가한 후 PerfMon에서 간단하고 이해하기 쉬운 몇 가지 성능 카운터를 살펴보는 것이 좋습니다.
가장 친숙한 성능 카운터 중 하나가 바로 % Processor Time입니다. 이 성능 카운터는 PerfMon에서 카운터 추가 창을 여는 경우 처음에 강조 표시되는 카운터입니다. % Processor Time은 프로세서가 작업을 실행하는 데 사용한 시간입니다. 최대 작동 시간 중 대부분의 시간 동안 이 값이 80% 이상일 경우 프로세서 사용률이 높은 것으로 간주됩니다. 서버가 사용률 80%에서 실행되고 있지 않을 때에도 수치가 100%에 이르는 때가 있는데 이는 일반적인 현상입니다.
PerfMon에서 System 성능 개체에 있는 Processor Queue Length 카운터도 검토해야 합니다. Processor Queue Length는 CPU에서 작업을 대기 중인 스레드 수를 보여 줍니다. SQL Server는 데이터베이스 엔진의 스케줄러를 통해 작업을 관리합니다. 즉, SQL Server는 데이터베이스 엔진을 통해 요청을 큐에 놓고 처리합니다. SQL Server는 작업을 자체적으로 관리하므로 각 논리적 프로세서에 대해 CPU 스레드를 하나만 사용합니다. 이는 SQL Server 전용 시스템의 경우 작업을 수행하기 위해 프로세서 큐에서 대기 중인 스레드 수가 최소한으로 유지되어야 함을 의미합니다. 일반적으로 SQL Server 전용 시스템에 있는 물리적 프로세서 수의 5배를 넘지 않아야 하지만 2배 이상만 되더라도 문제가 있는 것으로 생각할 수 있습니다. DBMS가 다른 응용 프로그램과 시스템을 공유하는 서버의 경우 이 카운터를 % Processor Time 및 Context Switches/sec 성능 카운터와 함께 검토하여 다른 응용 프로그램이나 DBMS를 다른 서버로 이동할 필요가 있는지 확인해야 합니다. 컨텍스트 전환에 대해서는 나중에 간단히 설명하겠습니다.
높은 CPU 사용률과 함께 프로세서가 큐에 대기 중인 것을 발견할 경우 필자는 SQL Server:SQL Statistics 성능 개체에 있는 Compilations/sec와 Re-Compilations/sec 카운터를 검토합니다(그림 1 참조). 쿼리 계획 컴파일 및 재컴파일은 시스템의 CPU 사용률을 높입니다. Re-Compilations 값은 0에 가까워야 하지만, 시스템의 추세를 주의 깊게 검토하여 서버의 일반적인 동작과 정상적인 컴파일 수를 판단하는 것이 좋습니다. 재컴파일을 피할 수 없는 경우도 있습니다. 하지만 재컴파일 횟수를 최소화하고 쿼리 계획을 다시 사용하도록 쿼리 및 저장 프로시저를 최적화하는 것은 가능합니다. SQL Server:SQL Statistics 성능 개체에 있는 Batch Requests/sec를 검토하여 이들 값과 시스템으로 들어오는 실제 SQL 문의 수를 비교해 보십시오. 초당 컴파일 및 재컴파일 횟수가 시스템으로 들어오는 일괄 요청에서 높은 비율을 차지하는 경우 이 부분을 자세히 검토해야 합니다. SQL 개발자는 자신의 코드가 이러한 유형의 시스템 리소스 문제와 왜, 그리고 어떤 식으로 관련되는지 쉽게 파악할 수 없는 경우도 있습니다. 이 기사의 뒷부분에 나오는 참조 자료를 보면 이러한 유형의 작업을 최소화하는 데 도움이 될 것입니다.
그림 1 모니터링할 카운터 선택
그림 1 모니터링할 카운터 선택
PerfMon에서 Context Switches/sec라는 성능 카운터를 확인하십시오(그림 2 참조). 이 카운터는 대기 중인 다른 스레드 대신 작업을 수행하기 위해 SQL 스케줄러가 아닌 OS 스케줄러에서 스레드가 전환된 횟수를 보여 줍니다. 컨텍스트 전환은 대개 IIS 또는 타 공급업체 응용 프로그램 서버 구성 요소와 같은 다른 응용 프로그램과 공유되는 데이터베이스 시스템에서 더 자주 발생합니다. 필자가 Context Switches/sec에 사용하는 임계값은 서버에 있는 프로세서 수의 5,000배 정도입니다. 하이퍼 스레딩이 설정되어 있으며 CPU 사용률이 적정 수준이거나 높은 시스템의 경우 이 값 또한 높을 수 있습니다. CPU 사용률과 컨텍트스 전환 횟수 모두 정기적으로 해당 임계값을 초과할 경우 CPU 병목 상태가 있음을 나타냅니다. 이러한 현상이 정기적으로 발생할 뿐 아니라 시스템이 노후되었다면 추가 CPU나 속도가 더 빠른 CPU 구입을 고려해야 합니다. 자세한 내용은 "하이퍼 스레딩" 추가 기사를 참조하십시오.
Figure 2 검토할 성능 카운터 (Close Figure 2)

성능 카운터 | 카운터 개체 | 임계값 | 설명
% Processor Time | Processor | > 80% | 가능한 원인으로는 메모리 부족, 낮은 쿼리 계획 재사용, 최적화되지 않은 쿼리 등이 있습니다.
Context Switches/sec | System | > 5000 x 프로세서 수 | 가능한 원인으로는 서버의 다른 응용 프로그램, 동일한 서버에서 실행되는 둘 이상의 SQL Server 인스턴스, 하이퍼 스레딩 설정 등이 있습니다.
Processor Queue Length | System | > 5 x 프로세서 수 | 가능한 원인으로는 서버의 다른 응용 프로그램, 높은 컴파일 또는 재컴파일 횟수, 동일한 서버에서 실행되는 둘 이상의 SQL Server 인스턴스 등이 있습니다.
Compilations/sec | SQLServer:SQL Statistics | 추세에 따라 결정 | Batch Requests/sec와 비교합니다.
Re-Compilations/sec | SQLServer:SQL Statistics | 추세에 따라 결정 | Batch Requests/sec와 비교합니다.
Batch Request/sec | SQLServer:SQL Statistics | 추세에 따라 결정 | 초당 컴파일 및 재컴파일 횟수와 비교합니다.
Page Life Expectancy | SQLServer:Buffer Manager | < 300 | 가능한 원인으로는 메모리 부족이 있습니다.
Lazy Writes/sec | SQLServer:Buffer Manager | 추세에 따라 결정 | 가능한 원인으로는 대량 데이터 캐시 플러시 또는 메모리 부족이 있습니다.
Checkpoints/sec | SQLServer:Buffer Manager | 추세에 따라 결정 | PLE 및 Lazy Writes/sec를 기준으로 검사점을 검토합니다.
Cache Hit Ratio: SQL Plans | SQLServer:Plan Cache | < 70% | 낮은 계획 재사용을 나타냅니다.
Buffer Cache Hit Ratio | SQLServer:Buffer Manager | < 97% | 가능한 원인으로는 메모리 부족이 있습니다.
CPU 사용률이 높을 경우 SQL Server 지연 기록기(SQL Server 2000) 또는 리소스 모니터(SQL Server 2005)라고 하는 영역도 모니터링해야 합니다. 버퍼 및 프로시저 캐시를 플러시하는 경우 리소스 모니터라고 하는 리소스 스레드를 통해 CPU 시간이 늘어날 수 있습니다. 리소스 모니터는 유지할 페이지와 버퍼 풀에서 디스크로 플러시해야 할 페이지를 결정하는 SQL Server 프로세스입니다. 버퍼 및 프로시저 캐시의 각 페이지에는 원래 해당 페이지가 캐시에 저장될 때 사용된 리소스를 나타내는 비용이 할당됩니다. 이 비용 값은 리소스 모니터가 값을 검사할 때마다 감소합니다. 요청에서 캐시 공간을 필요로 하는 경우 각 페이지와 관련된 비용을 기준으로 페이지가 메모리에서 플러시되며, 값이 가장 낮은 페이지가 가장 먼저 플러시됩니다. 리소스 모니터 작업은 PerfMon에서 SQL Server: Buffer Manager 개체에 있는 Lazy Writes/sec 성능 카운터를 통해 추적할 수 있습니다. 시스템의 일반적인 임계값을 확인하려면 이 값이 어떻게 변하는지 추적해야 합니다. 이 카운터는 메모리가 부족한지 여부를 확인하기 위해 일반적으로 Page Life Expectancy 및 Checkpoints/sec 카운터와 함께 검토합니다.
PLE(Page Life Expectancy) 카운터는 메모리가 부족한지 확인하는 데 유용합니다. PLE 카운터는 데이터 페이지가 버퍼 캐시에 머무르는 기간을 보여 줍니다. 이 카운터의 업계 허용 임계값은 300초입니다. 이 값이 일정 기간 동안 평균 300초 미만이면 데이터 페이지가 메모리에서 너무 자주 플러시되고 있다는 것을 나타냅니다. 이 경우 리소스 모니터의 작업량이 많아지고 이에 따라 프로세서가 감당해야 할 작업량도 늘어납니다. PLE 카운터는 Checkpoints Pages/sec 카운터와 함께 검토해야 합니다. 시스템에서 검사점이 발생하면 버퍼 캐시의 더티 데이터 페이지가 디스크로 플러시되고 이로 인해 PLE 값이 감소합니다. 리소스 모니터 프로세스는 실제로는 이러한 페이지를 디스크에 플러시하는 메커니즘입니다. 따라서 이러한 검사점 작업 중에는 Lazy Writes/sec 값이 증가하는 현상도 나타납니다. 검사점이 완료된 즉시 PLE 값이 증가하는 경우 일시적인 현상이므로 무시해도 됩니다. 하지만 PLE 값이 해당 임계값보다 낮은 현상이 정기적으로 발생할 경우에는 메모리를 추가하여 문제를 해결하는 동시에 CPU에서 사용할 수 있도록 일부 리소스를 해제하는 것이 좋습니다. 이들 카운터는 모두 SQL Server: Buffer Manager 성능 개체에 있습니다.

방법 2: 쿼리 성능
SP 추적
SQL Server 응용 프로그램을 추적하는 경우 추적에 사용되는 저장 프로시저에 친숙해지면 매우 유용합니다. 추적을 위해 GUI 인터페이스(SQL Server 프로파일러)를 사용할 경우 시스템 로드가 15~25% 정도 늘어날 수 있습니다. 추적에 저장 프로시저를 사용하면 이러한 시스템 로드를 절반으로 줄일 수 있습니다.
시스템의 특정 부분에서 병목 상태가 발생하고 있음을 알고 있고 서버에서 현재 이러한 문제를 일으키는 SQL 문이 어떤 것인지 확인하려는 경우 아래와 같은 쿼리를 실행해 보십시오. 이 쿼리를 실행하면 개별 문과 이러한 문이 현재 사용 중인 리소스는 물론 성능 향상을 위해 검토할 필요가 있는 문을 모두 함께 볼 수 있습니다. SQL Trace에 대한 자세한 내용은 msdn2.microsoft.com/ms191006.aspx를 참조하십시오.
SELECT
    substring(text,qs.statement_start_offset/2
        ,(CASE
            WHEN qs.statement_end_offset = -1 THEN len(convert(nvarchar(max), text)) * 2
            ELSE qs.statement_end_offset
        END - qs.statement_start_offset)/2)
    ,qs.plan_generation_num as recompiles
    ,qs.execution_count as execution_count
    ,qs.total_elapsed_time - qs.total_worker_time as total_wait_time
    ,qs.total_worker_time as cpu_time
    ,qs.total_logical_reads as reads
    ,qs.total_logical_writes as writes
FROM sys.dm_exec_query_stats qs
    CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
    LEFT JOIN sys.dm_exec_requests r
        ON qs.sql_handle = r.sql_handle
ORDER BY 3 DESC

SQL Server로 새 쿼리가 제출될 때 쿼리 계획이 평가, 최적화 및 컴파일되어 프로시저 캐시에 저장됩니다. 서버로 쿼리가 제출될 때마다 요청과 일치하는 쿼리 계획이 있는지 확인하기 위해 프로시저 캐시가 검토됩니다. 일치하는 쿼리 계획이 없으면 SQL Server에서 새 쿼리 계획을 만들게 되는데 이 경우 비용이 들 수 있습니다.
다음은 T-SQL CPU 최적화를 위해 고려해야 할 몇 가지 사항입니다.
  • 쿼리 계획 재사용
  • 컴파일 및 재컴파일 횟수 줄이기
  • 정렬 작업
  • 잘못된 조인
  • 누락된 인덱스
  • 테이블/인덱스 검사
  • SELECT 및 WHERE 절의 함수 사용
  • 다중 스레드 작업
이제 이러한 사항에 대해 간단히 살펴보겠습니다. SQL Server는 일반적으로 메모리와 디스크 모두에서 데이터를 가져옵니다. 또한 사용자가 단일 데이터 페이지로만 작업하는 경우는 거의 없습니다. 오히려 관련 데이터를 전체적으로 볼 수 있도록 여러 개의 작은 쿼리를 실행하거나 테이블을 조인하는 등 한 레코드에 대해 응용 프로그램의 여러 부분이 작동하는 경우가 많습니다. OLAP 환경에서는 지역별 판매 보고서를 작성하기 위해 데이터를 통합, 취합 및 요약할 수 있도록 응용 프로그램이 한두 개의 테이블에서 수백만 개의 행을 가져올 수도 있습니다. 이 경우 데이터가 메모리에 있으면 데이터 반환 속도를 밀리초 단위로 측정할 수 있지만, 동일한 데이터를 RAM이 아닌 디스크에서 검색하는 경우에는 밀리초가 분으로 바뀔 수 있습니다.
첫 번째 예는 트랜잭션 양이 많은 경우로 응용 프로그램에 따라 계획 재사용 여부가 달라집니다. 이 경우 낮은 계획 재사용으로 인해 SQL 문의 컴파일 횟수가 대폭 늘어나 결국 CPU 처리량이 엄청나게 많아질 수 있습니다. 두 번째 예의 경우 대량의 새 데이터 페이지를 위한 공간을 만들기 위해 기존 데이터가 버퍼 캐시에서 지속적으로 플러시되어야 하므로 시스템 리소스 사용률이 높아지고 이로 인해 시스템 CPU의 처리량이 많아질 수 있습니다.
배송 상자 정보를 검색하기 위해 아래와 같은 SQL 문이 15분 동안 2000번 실행되는, 트랜잭션 양이 매우 많은 시스템이 있다고 가정해 보십시오. 쿼리 계획을 다시 사용하지 않을 경우 문당 개별 실행 시간이 450밀리초 정도일 것입니다. 쿼리를 처음 실행한 후 다음부터는 동일한 쿼리 계획을 사용한다면 이후의 쿼리는 실행되는 데 2밀리초 정도가 소요되어 총 실행 시간이 5초 정도로 줄어듭니다.
USE SHIPPING_DIST01;
SELECT
    Container_ID
    ,Carton_ID
    ,Product_ID
    ,ProductCount
    ,ModifiedDate
FROM Container.Carton
WHERE Carton_ID = 982350144;
쿼리 계획 재사용은 트랜잭션 양이 많은 시스템에서 성능을 최적화하는 데 매우 중요한 요소이며 대부분의 경우 쿼리나 저장 프로시저를 매개 변수화함으로써 가능합니다. 다음은 쿼리 계획 재사용과 관련된 유용한 정보를 제공하는 리소스입니다.
  • SQL Server 2005의 일괄 컴파일, 재컴파일 및 캐싱 계획 문제(microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx)
  • SQL Server 저장 프로시저를 최적화하여 재컴파일 방지(sql-server-performance.com/rd_optimizing_sp_recompiles.asp)
  • SQL Server 2000의 쿼리 재컴파일(msdn2.microsoft.com/aa902682.aspx)
SQL Server 2005 DMV(동적 관리 뷰)도 많은 유용한 정보를 제공합니다. CPU 사용률이 높을 경우 CPU가 적절하게 사용되고 있는지 여부를 확인하는 데 사용할 수 있는 두 가지 DMV가 있습니다.
그 중 하나가 바로 데이터베이스 관리자가 SQL Server가 사용하는 각 리소스 유형 또는 함수를 확인하는 데 사용하는 sys.dm_os_wait_stats로, 이 DMV는 시스템이 해당 리소스로 인해 대기해야 하는 시간을 측정합니다. 이 DMV의 카운터는 누적됩니다. 따라서 미해결된 문제에 대한 데이터를 검토한 후에는 DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) 명령을 실행하여 모든 카운터를 다시 설정해야 시스템의 여러 영역에 영향을 주는 리소스가 무엇인지 정확하게 검토할 수 있습니다. sys.dm_os_wait_stats DMV는 SQL Server 2000의 데이터베이스 일관성 검사를 위한 DBCC SQLPERF(WAITSTATS) 명령과 기능이 같습니다. 다른 대기 유형에 대한 자세한 내용은 SQL Server 온라인 설명서(msdn2.microsoft.com/ ms179984.aspx)를 참조하십시오.
모든 것이 최적으로 실행될 때조차도 시스템에서 대기 상태가 발생하는 것은 일반적입니다. 하지만 이러한 대기 상태가 CPU 병목 상태로 인해 발생하는지 여부는 확인해야 합니다. 신호 대기 시간은 전반적인 대기 시간에 비해 가능한 한 낮아야 합니다. 특정 리소스가 프로세서 리소스를 대기하는 시간은 총 대기 시간에서 신호 대기 시간을 빼면 알 수 있으며 이 값은 총 대기 시간의 약 20%를 넘으면 안 됩니다.
sys.dm_exec_sessions DMV는 SQL Server에서 열려 있는 모든 세션을 보여 줍니다. 이 DMV는 각 세션의 성능과 각 세션이 시작된 이후 세션에서 수행된 모든 작업을 자세히 보여 줍니다. 여기에는 세션이 대기한 총 대기 시간, 총 CPU 사용량, 메모리 사용량, 읽기 및 쓰기 수가 포함됩니다. 이 DMV는 로그인, 로그인 시간, 호스트 컴퓨터, 세션에서 마지막으로 SQL Server 요청이 이루어진 시간도 보여 줍니다.
CPU 사용률이 높을 경우 가장 먼저 검토해야 할 항목 중 하나가 바로 sys.dm_exec_sessions인데 이는 이 DMV가 활성 세션에 대한 정보만 제공하기 때문입니다. CPU 사용률이 높은 세션부터 먼저 검토하십시오. 작업을 수행 중이었던 응용 프로그램과 사용자를 확인한 후 자세한 분석을 시작하는 것이 좋습니다. sys.dm_exec_sessions와 sys.dm_exec_requests DMV를 함께 사용하면 sp_who 및 sp_who2 저장 프로시저를 통해 얻을 수 있는 정보의 대부분을 볼 수 있습니다. sql_handle 열을 통해 이 데이터를 sys.exec_sql_text DMF(동적 관리 함수)와 조인하면 세션에서 현재 실행 중인 쿼리를 확인할 수 있습니다. 그림 3의 코드 조각은 이러한 데이터를 모두 가져와 서버의 현재 상황을 확인하는 방법을 보여 줍니다.
Figure 3 서버 작업 확인 (Close Figure 3)
SELECT es.session_id
    ,es.program_name
    ,es.login_name
    ,es.nt_user_name
    ,es.login_time
    ,es.host_name
    ,es.cpu_time
    ,es.total_scheduled_time
    ,es.total_elapsed_time
    ,es.memory_usage
    ,es.logical_reads
    ,es.reads
    ,es.writes
    ,st.text
FROM sys.dm_exec_sessions es
    LEFT JOIN sys.dm_exec_connections ec
        ON es.session_id = ec.session_id
    LEFT JOIN sys.dm_exec_requests er
        ON es.session_id = er.session_id
    OUTER APPLY sys.dm_exec_sql_text (er.sql_handle) st
WHERE es.session_id > 50    -- < 50 system sessions
ORDER BY es.cpu_time DESC
이 문은 집중적으로 조사해야 할 응용 프로그램이 어떤 것인지 파악하는 데 도움이 됩니다. 필자의 경우 한 응용 프로그램 내의 모든 세션에 대한 CPU, 메모리, 읽기 수, 쓰기 수, 논리적 읽기 수를 비교한 결과 CPU 리소스가 다른 리소스보다 사용률이 훨씬 높다는 것을 알게 되었고 이때부터 해당 SQL 문을 집중적으로 분석하기 시작했습니다.
응용 프로그램에 대한 SQL 문을 과거부터 현재까지 시간별로 모두 추적하기 위해 필자는 SQL Server 추적을 사용했습니다. SQL Server 프로파일러 도구나 추적 시스템 저장 프로시저를 통해 SQL Server 추적에 액세스하면 시스템의 현 상황을 쉽게 평가할 수 있습니다. 이 항목에 대한 자세한 내용은 "SP 추적" 추가 기사를 참조하십시오. 프로파일러에서 CPU 사용률이 높고 해시 및 정렬 경고, 캐시 누락 및 기타 빨간색 플래그가 있는 문은 반드시 검토해야 합니다. 이런 식으로 특정 SQL 문이나 리소스 사용률이 높은 특정 시간대로 범위를 좁힐 수 있습니다. 프로파일러를 사용하면 SQL 문 텍스트, 실행 계획, CPU 사용량, 메모리 사용량, 논리적 읽기, 쓰기, 쿼리 계획 캐시, 재컴파일, 캐시에서의 쿼리 계획 제거, 캐시 누락, 테이블 및 인덱스 검사, 누락된 통계를 비롯한 다양한 이벤트를 추적할 수 있습니다.
필자의 경우 sp_trace 저장 프로시저나 SQL Server 프로파일러를 사용하여 데이터를 수집한 후에는 문제 발생 후의 추적 데이터로 채워지거나 데이터베이스에 쓰도록 추적을 설정하여 추적 데이터로 채워진 데이터베이스를 사용합니다. 문제 발생 후 데이터베이스를 채우는 작업은 SQL Server 시스템 함수 fn_trace_getinfo를 사용하여 수행할 수 있습니다. 이 방법을 사용할 경우 다양한 방법으로 데이터를 쿼리하고 정렬하여 CPU를 가장 많이 사용하거나 읽기 수가 가장 많은 SQL 문을 파악할 수 있을 뿐만 아니라 발생한 재컴파일 횟수를 계산하는 등의 많은 작업을 수행할 수 있습니다. 다음 예제에서는 이 함수를 사용하여 프로파일러 추적 파일이 있는 테이블을 로드하는 방법을 보여 줍니다. 기본적으로 해당 추적에 대한 모든 추적 파일이 생성된 순서대로 로드됩니다.
SELECT * INTO trc_20070401
FROM fn_trace_gettable('S:\Mountpoints\TRC_20070401_1.trc', default);
GO

결론
지금까지 살펴보았듯이 CPU 사용률이 높다고 해서 반드시 CPU 병목 상태가 있는 것은 아닙니다. 높은 CPU 사용률에만 치중하다 보면 다른 응용 프로그램이나 하드웨어에서 발생하는 수많은 병목 상태를 놓칠 수 있습니다. 다른 카운터가 정상인데 CPU 사용률만 높을 경우 먼저 시스템 내에서 원인을 알아본 다음 CPU를 추가로 구입하거나 SQL 코드를 최적화하는 등의 해결 방법을 찾는 것이 좋습니다. 어떤 방법을 취하든 포기하지 마십시오. 약간의 실천과 탐구심을 갖고 이 기사에서 제시하는 방법을 적절히 활용한다면 'SQL Server에서의 CPU 사용률 최적화'라는 실행 계획을 실현할 수 있을 것입니다.

Zach Nichter는 10년 넘게 SQL Server 관련 분야에 종사해 온 SQL Server 전문가로, DBA, 팀장, 관리자 및 컨설턴트를 비롯한 다양한 SQL Server 지원 업무를 수행해 왔습니다. 현재 Levi Strauss & Co.에서 DBA 설계자로 근무하고 있는 Zach는 주로 SQL Server 성능, 모니터링, 아키텍처 및 기타 전략적 이니셔티브에 관한 업무를 담당하고 있으며 www.sqlcatch.com에 게시된 동영상 블로그의 저자이기도 합니다.


 From the Editor: 최고를 향한 끝없는 도전
From the Editor
최고를 향한 끝없는 도전
Joshua Hoffman

믿지 못하실지도 모르지만 저는 오늘 저의 첫 번째 '편집자의 말'을 회상으로 시작하려 합니다. 물론 이런 종류의 문학적 장치를 너무 빨리 사용하는 것은 저에게는 그리 좋은 일은 아니겠지만 어쨌든 시작해보겠습니다.
2005년 여름, 2개의 TechNet Magazine 창간호는 큰 환영을 받았습니다. 그때는 제작 일정을 당겨 IT 전문가들에게 훌륭한 기술 내용을 정기적으로 제공하기 시작해야 할 시점이었습니다. 주필인 Joshua Trupin과 Stephen Toub(당시 자매지 MSDN Magazine의 기술 편집자)는 정규 업무가 따로 있었음에도 불구하고 전문가들을 배치하고 처음 몇 달 치를 기획하는 굉장한 작업을 해내고 있었습니다.
그리하여 저는 이들의 자신감과 당시까지 이들이 해낸 성과 앞에 겸허한 마음으로 새로운 기술 편집자로서 팀에 합류했습니다. 잡지 제작은 쉬운 일이 아닙니다. 저는 IT 전문가로서의 경력을 갖추고 있었고, 당시 4년간 Microsoft Consulting Services에서 근무한 터였습니다. 그래서 출판 업무에 관해서는 제대로 된 지식이 거의 없었던 편입니다. 읽어야 할 분량은 엄청났고, 즉시 기획을 시작해야 할 간행물이 3건이나 있었으며, 새로운 팀원과 작가, 기술 검토자, 비즈니스 파트너, 그리고 독자들을 파악하고 익혀야 했습니다. 그리고 무엇보다 마감일을 반드시 지켜야 했습니다. 쉽게 상상할 수 있겠지만 Microsoft에서 오랫동안 근무해온 사람들은 이 조건에 익숙해지기가 쉽지 않습니다.
그러나 팀원들은 저를 포용해 주었고, 인내하며 제 기분을 맞춰 주었습니다. 그리고 놀라울 만큼 제 업무를 잘 도와주었습니다. 작가와 검토자, 파트너, 그리고 독자 여러분들 덕분에 이 작업은 매혹적이고 도전적이고 큰 보람을 주는 작업이 되었으며 너무나 많은 새로운 지인들을 가질 수 있는 특권을 안겨 주었습니다. 저는 지난 2년간 이 팀이 이룬 성과를 자랑스럽게 생각합니다. 그러나 이제 저는 새로운 편집장으로서 앞으로 다가올 과제와 성과에 더욱 들떠 있습니다.
이 잡지의 유일한 존재 이유는 IT 전문가들이 Microsoft 제품과 기술을 통해 자기 업무를 성공적으로 수행하도록 하는 데 있습니다. (정말입니다. 바로 이를 위해 저희가 봉급을 받는 것이니까요.) 지금까지 여러분은 저희의 성과, 그리고 특히 개선해야 할 점에 대해 많은 의견을 제시해 주셨습니다. 저희는 모든 의견을 매우 진지하게 받아들입니다. 앞으로도 발전을 위한 노력을 멈추지 않고 새로운 작가와 새로운 칼럼을 추가하고, 새로운 내용과 새로운 매체로 온라인 플랫폼을 보강할 것이며, 특히 독자 여러분이 각자 자신에 가장 적합한 방식으로 내용을 익을 수 있도록 하고자 합니다. 그러나 여러분의 도움이 없다면 그 어떤 노력도 성공을 거두지 못할 것입니다. 어떤 것이 좋고 나쁜지를 알려 주시기 바랍니다. 저희가 어느 곳에 시간을 투자해야 할까요? 결정권은 여러분에게 있으니 그 권한을 충분히 활용하시기 바랍니다. tnmag@microsoft.com으로 의견을 보내 주십시오. —Joshua Hoffman

도움을 준 Omesh Desai, Raja Ganjikunta, Saleem Hakani, Justin Hall, Michael Murgolo, John Orefice, Jim Truher, Marc Umeno, Jeff Wettlaufer, Buck Woody, Minxiao Zhou를 비롯한 Microsoft 기술 전문가들에게 감사의 마음을 전합니다.


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

강력한 스크립팅
PowerShell Analyzer
www.pwershellanalyzer.com
Windows PowerShell™에 대한 의견들이 많이 나오는데 여기에는 나름의 이유가 있습니다. 지금까지 차세대 스크립팅 언어인 Windows PowerShell을 접할 기회가 없었다면 이제 한번 사용해 보십시오. 또한 Microsoft® Exchange 2007로 업그레이드한 사용자는 새로운 Exchange 관리 셸이 Windows PowerShell을 기반으로 만들어져 Exchange 관리 콘솔에서 수행할 수 있는 모든 작업을 명령줄에서 수행할 수 있게 되었으며 덕분에 반복되는 작업을 자동화하기가 매우 편해졌다는 사실을 잘 알고 있을 것입니다. 하지만 관련 구문과 의미에 대해 배우려면 많은 시간과 노력이 필요합니다. 이 문서에서는 ShellTools의 PowerShell Analyzer가 어떤 기능을 수행하는지 살펴보겠습니다.
이 응용 프로그램은 기본적으로 Windows PowerShell 스크립트를 작성하고 디버깅하기 위한 IDE입니다. 하지만 작성-컴파일-테스트 단계로 구성되는 기존의 주기와는 달리 이 응용 프로그램은 관리자가 키보드 입력을 통해 사용하므로 Windows PowerShell 실행 영역과 실시간으로 상호 작용할 수 있습니다. PowerShell Analyzer를 사용하면 명령을 줄 단위로 입력하거나 UI 아래쪽의 편집기를 사용하여 스크립트를 작성하고 편집하고 실행할 수 있습니다. 어떤 방법을 사용하든 기본 코드 완성 기능이 제공되므로 cmdlet의 다양한 매개 변수를 사용하는 데 많은 도움이 됩니다. Windows PowerShell에 대해 잘 모르십니까? 그렇다면 cmdlet은 작업 기반이며 매개 변수를 사용하는 추상 명령이라고 보면 됩니다.
또한 PowerShell Analyzer는 각 cmdlet에 대한 자세한 설명, 구문, 매개 변수에 대한 설명, cmdlet 예 등을 보여 주는 빠른 참조 탭도 제공합니다. 뿐만 아니라 Windows PowerShell 공급자, 사용할 수 있는 기본 제공 도움말 파일 및 간소한 cmdlet 별칭에 대한 참조를 제공합니다.
Windows PowerShell에서 명령을 실행하면 화면에 텍스트 결과가 표시되는 것이 아니라 실제로는 Microsoft .NET Framework 개체가 반환됩니다. PowerShell Analyzer를 사용하면 반환된 결과의 속성을 캡처하여 이를 다양한 "시각화 도우미"에 전달할 수 있습니다. 시각화 도우미를 사용하면 XML 데이터를 트리 구조로 제공하거나, 정렬 및 그룹화가 가능한 계층적 표 보기로 데이터를 제공하거나, 반환된 데이터 집합을 시각적으로 나타내기 위해 여러 가지 차트를 생성하는 등 다양한 방식으로 개체와 상호 작용할 수 있습니다. 물론 일부 명령이나 스크립트에는 이러한 옵션을 사용할 수 없습니다. 하지만 사용할 수 있는 경우에는 이러한 옵션을 통해 데이터를 세련된 방식으로 표현하고 다시 사용할 수 있도록 이를 저장하거나 내보낼 수 있습니다.
뿐만 아니라 PowerShell Analyzer에서는 여러 개의 실행 영역을 동시에 사용할 수 있으므로 작업 간 전환이 간편합니다. 또한 편집기 창에서는 코드 정리, 사용자 지정 가능한 코드 강조 표시 스타일 등을 제공하므로 스크립트를 읽기 쉽게 만들 수 있습니다.
Windows PowerShell을 사용할 계획이라면 PowerShell Analyzer와 같은 도구를 통해 무엇보다도 스크립트 작성, 편집, 디버깅 등의 작업과 데이터 시각화 작업을 훨씬 쉽게 수행할 수 있을 것입니다.

가격: 단일 라이선스당 129달러
PowerShell 그림

디스크 조각 모음
Auslogics Disk Defrag
www.auslogics.com/disk-defrag
하드 드라이브를 사용하는 기간이 늘어날수록 디스크의 파일도 더 많은 조각으로 나뉩니다. 파일을 만들거나 삭제하고, 응용 프로그램을 설치하거나 제거하고, 심지어는 임시 디스크 캐시와 파일을 만드는 것도 조각화의 원인이 됩니다. 뿐만 아니라 드라이브의 여유 공간이 제한된 경우, 대부분 채워져 있는 공간 중 사용 가능한 "빈 공간"에 드문드문 새 파일이 만들어지므로 조각화 속도가 급격히 빨라질 수 있습니다. 조각화는 결국 시스템의 성능 저하를 초래합니다.
Windows® 버전마다 조각화 도구가 기본적으로 포함되어 있다는 사실은 모두 알고 있습니다. 하지만 조각화를 위한 전용 옵션을 찾고 있거나 최근에 Windows Vista®로 업그레이드한 후 이전 버전 조각 모음 도구가 제공하던 컨트롤과 UI 환경이 그립다면 이를 대체할 만한 흥미로운 도구가 한 가지 있습니다. 그 도구는 바로 Auslogics의 Disk Defrag입니다.
Disk Defrag는 Windows XP, Windows 2000, Windows Server® 2003 및 Windows Vista에서 작동합니다. 또한 예상하는 바와 같이 FAT16, FAT32 및 NTFS 볼륨에 대해 조각 모음을 수행할 수 있습니다. 이 응용 프로그램은 매우 단순하며 마우스 단추만 몇 번 클릭하면 간단하게 설치할 수 있습니다.
응용 프로그램을 실행하는 것도 매우 쉽습니다. 조각 모음을 수행할 드라이브를 선택하고 Next를 클릭한 다음 지켜보기만 하면 됩니다. 실행이 완료되면 Disk Defrag는 총 파일 수, 디렉터리 수, 조각화된 파일 수, 조각 모음이 수행된 파일 수, 조각 모음을 건너 뛴 파일 수, 줄어든 조각 수에 대한 백분율 등 조각 모음을 수행한 후의 결과를 요약하여 보여 줍니다. 필요하면 Disk Defrag의 Display Report 단추를 클릭하여 HTML 버전의 조각 모음 보고서를 생성할 수도 있습니다. 이 보고서는 건너 뛴 파일 및 해당 파일의 위치 목록, 조각 수, 조각 모음 실행 후 경과된 시간, 디스크의 클러스터 정보 등 디스크와 관련된 몇 가지 추가 정보를 제공합니다.

가격: 무료
설치 및 사용이 간편한 Disk Defrag
설치 및 사용이 간편한 Disk Defrag

파일 전송
FileZilla
filezilla.sourceforge.net
성능이 우수한 SFTP 클라이언트만큼 작업을 편하게 만들어 주는 것도 없습니다. 특히 FileZilla 클라이언트처럼 견고하게 작성된 데다가 무료로 사용할 수 있는 클라이언트의 경우에는 더욱 그렇습니다. FileZilla는 지난 2001년에 Tim Kosse와 그의 몇몇 동료가 컴퓨터 공학 수업 프로젝트로 시작한 것으로, SourceForge.net에서 호스팅되는 공개 소스 프로젝트입니다. FileZilla는 Windows NT®4.0에서 Windows Vista에 이르는 모든 Windows 버전에서 실행됩니다. 이 프로젝트는 지난 6년간 그 규모가 꽤 커졌지만 프로젝트 팀장은 지금도 Kosse가 맡고 있습니다.
이 클라이언트는 표준 FTP 연결뿐 아니라 SFTP+SSH2(Secure Shell 버전 2), FTP over TLS, 암시적 및 명시적 암호화를 사용한 FTP over SSL 등을 통한 연결을 지원하므로 다양한 서버에 연결할 수 있습니다. FileZilla는 사용되는 로컬 포트를 제한하고 IPv4 및 IPv6용 비 패시브(non-passive) 전송을 위한 고유 IP 바인딩을 설정할 수 있도록 함으로써 로컬 방화벽도 수용할 수 있습니다. 또한 이 클라이언트는 SOCKS4/5, HTTP1.1 및 FTP 프록시를 비롯한 다양한 프록시 구성을 지원합니다.
FTP 연결에 대한 서버 인증의 측면에서 FileZilla는 익명, 일반 사용자 이름/암호, 계정 기반 구성을 지원합니다. Kerberos GSS(Generic Security Services) 지원을 사용하고 GSS를 사용하는 서버 목록을 만들 수도 있습니다. 이 경우 Windows용 Kerberos가 시스템에 설치되어 있어야 합니다. 물론 GSS가 작동하려면 유효한 Kerberos v5 티켓이 있어야 합니다. 클라이언트 식별 수단으로 Ident 서버가 필요한 경우 서버 연결을 위해 Ident 서버를 지원할 수도 있습니다.
FileZilla를 사용하면 많은 FTP 사이트 모음을 쉽게 관리할 수 있으며 트리 형식의 구조로 연결을 구성할 수 있습니다. 설정하는 각 연결에 대해 기본 로컬 및 원격 디렉터리를 설정하고, 연결할 포트를 지정하고, 구성된 프록시를 통과하도록 선택하고, 능동 또는 수동 전송 모드를 명시적으로 선택하고, 서버 표준 시간대 오프셋을 설정할 수도 있습니다. 저장된 연결 외에도 FileZilla에는 1회용 전송을 위한 빠른 접속 기능이 있으므로 주소, 사용자 이름, 암호 및 포트를 입력하고 단추만 한 번 클릭하면 곧바로 연결할 수 있습니다. 설정과 연결을 구성한 후에는 백업용으로 또는 다른 시스템에서 다시 사용할 수 있도록 이를 XML로 내보낼 수 있습니다.
Windows 탐색기 인터페이스와 비슷한 응용 프로그램 UI는 로컬 시스템과 원격 시스템 간의 파일 끌어서 놓기를 지원합니다. 파일 전송의 경우 기본 파일 덮어쓰기 설정과 함께 미리 정의된 규칙 집합 또는 상수 KB 속도 제한에 따라 다운로드 및 업로드 속도를 제한하는 옵션을 지정할 수 있습니다. FileZilla는 기본적으로 서버에서 MODE Z 압축 파일 전송을 사용하도록 구성되어 있지만(서버에서 지원되는 경우) 압축 수준을 조정하거나 이 기능을 끌 수 있습니다. 전송 대기열 기능도 클라이언트에 포함되어 있으므로 전송할 파일 집합을 대기열에 놓은 다음 다시 사용할 수 있도록 전송 목록을 가져오거나 내보낼 수 있습니다. 이 기능은 반복되는 시스템 관리 작업에 매우 유용합니다.

가격: 무료

실행 파일 편집
PE Explorer
www.heaventools.com
응용 프로그램의 본질적인 측면을 깊이 있게 탐구하고 싶다면 HeavenTools의 PE Explorer를 사용해 보십시오. 이 응용 프로그램을 사용하면 Windows 응용 프로그램용 실행 이진 파일로 사용되는 PE 파일(이식 가능 파일)의 내부 구조를 분석할 수 있습니다. 간단히 말해 PE Explorer는 이러한 실행 파일의 내용을 탐색하고 편집하는 데 사용할 수 있는 UI를 제공합니다. PE Explorer에서는 EXE 및 DLL과 같은 일반 형식에서 DPL 및 CPL 파일과 같은 흔하지 않은 형식에 이르는 다양한 파일을 열 수 있습니다.
PE Explorer에서 처음 실행 파일을 탐색하려고 선택하면 코드 섹션의 수, 이미지 크기, 응용 프로그램 하위 시스템, 스택 크기 정보 등 파일 헤더에 대한 정보가 표시됩니다. 다른 보기에는 실행 파일의 섹션 헤더에 대한 개요가 표시됩니다. 섹션 헤더를 두 번 클릭하면 각 섹션의 내용을 탐색할 수 있는 창이 나타납니다.
심지어는 로드한 PE의 섹션을 추출하고, 다시 계산하고, 삭제할 수도 있습니다. 이 응용 프로그램은 바이러스, 맬웨어 및 실행 파일에 포함된 기타 위험 요소를 검색하는 탁월한 도구입니다. 또한 응용 프로그램의 Digital Signature Viewer를 사용하면 로드한 실행 파일에 있는 Microsoft Authenticode 디지털 서명을 검토하고 그 유효성을 검사할 수 있습니다. 이것은 실행 파일의 무결성과 게시자를 확인할 수 있는 강력한 도구입니다.
PE Explorer에는 실행 파일의 어셈블리 코드를 보는 데 사용할 수 있는 빠른 속도의 디스어셈블러도 기본적으로 포함되어 있습니다. 이 디스어셈블러는 일반 Intel x86 명령 집합과 함께 MMX, 3D Now!, SSE/2/3 등의 확장 기능을 지원하며, PE의 데이터 부분에서 ASCII 텍스트 문자열을 추출합니다.
PE 파일이 정적으로 링크되는 모듈 및 지연 로드되는 모듈을 모두 검색한 다음 이들을 계층적 트리 구조에 표시함으로써 PE가 어디로 연결되는지 보여 주는 Dependency Scanner라는 기능도 포함되어 있습니다.
PE Explorer의 좀 더 흥미로운 기능 중 한 가지는 Resource Editor입니다. Resource Editor를 사용하면 지정한 실행 파일의 리소스를 보고, 추출하고, 바꾸고, 편집하고, 삭제할 수 있습니다. Resource Editor의 UI는 이미지, 소리, 대화 상자, 메뉴, XML 데이터, HTML 데이터, 도구 모음 등 실행 파일에 포함된 리소스를 디렉터리 구조로 보여 줍니다. 일부 리소스를 제외한 대부분의 리소스는 직접 바꾸거나 편집할 수 있습니다. 따라서 실제 소스 코드에 액세스하지 않고도 사용자 지정 상표를 응용 프로그램에 추가하거나 대화 상자 메시지를 변경하거나 도구 모음의 동작을 사용자 지정하는 등의 작업을 수행할 수 있습니다. PE Explorer는 실행 파일의 내부 구조를 탐색하고 싶은 사용자가 간편하게 사용할 수 있는 도구입니다. 하지만 Resource Editor 기능만 필요한 경우에는 훨씬 저렴한 Resource Tuner 응용 프로그램을 사용하는 것이 좋습니다.

가격: 개인용 라이선스당 129달러, 기업용 라이선스당 199달러
PE Explorer 그림
PE Explorer 그림

서평
Endpoint Security
www.awprofessional.com
내부 인프라에 견고한 기본 네트워크 경계를 추가하는 것은 자산을 보호하는 데 있어 매우 중요한 단계입니다. 하지만 이것으로 모든 문제가 해결되는 것은 아닙니다. 현재 출시되는 하드웨어와 소프트웨어에서 모바일 및 통신 기능이 증가함에 따라 이제 과거와 같은 경계라는 개념은 더 이상 조직의 인프라에 존재하지 않게 되었습니다. 그보다는 원격 종단점으로 인프라가 확장되고 있습니다. 사실 여러분은 자신을 외부의 공격으로부터 잘 보호한다고 생각하지만, 집에서 랩톱을 가져와 이를 통제 받지 않는 회사 네트워크에 연결하는 사용자로 인해 우연히 공격이 시작되는 경우가 많습니다.
네트워크 액세스를 제어하고 인프라의 종단점을 안전하게 보호하는 방법을 찾고 싶다면 Mark Kadrich의 Endpoint Security(Addison-Wesley Professional, 2007)를 읽어 보십시오. 이 책은 종단점에 대한 정의를 내리는 것으로 시작하여 Windows 클라이언트, Linux 클라이언트, 포함된 장치, 휴대폰, PDA 등 현재 존재하는 다양한 형태의 종단점을 보여 줍니다. 저자는 네트워크를 "제어하기 힘든 영역"(control problem)으로 봅니다. 이 책에서 저자는 몇 가지 기본적인 비교를 통해 복잡한 네트워크를 보여 주는 일반적인 방식에서 탈피하여 유용하며 관리 가능한 방식으로 시각화하고 표현할 수 있는 그 무엇으로 네트워크를 묘사하고 있습니다.
이 책에서는 NAC(네트워크 액세스 제어)의 기본 개념 및 기본 신뢰 수준을 설정하는 것에 대해 자세히 다룹니다. 소스 소프트웨어 및 빌드 환경에 보안을 설정하고 제어함으로써 종단점 시스템을 위한 보안 기반을 마련하는 방법에 대해서도 설명합니다. 종단점을 안정적이고 안전하게 유지하는 데 유용한 도구에 대해 간략하게 설명하는 부분에서는 방화벽 및 바이러스 백신 소프트웨어 사용과 같은 친숙한 방법에서 사전 예방적 패치 관리가 필요한 부분, 그리고 침입 감지 및 예방 시스템, 호스트 무결성 검사기, 암호화 등의 고급 도구에 이르는 다양한 보안 방법을 제시합니다.
책의 후반부에서는 Microsoft Windows, Apple OS X 및 Linux를 비롯한 다양한 유형의 클라이언트 운영 체제를 안전하게 보호하는 것에 대해 자세히 살펴봅니다. 이와 관련된 각 장에서는 종단점 시스템에 대해 초기 상태 검사(Initial Health Check)를 수행하는 방법을 간단하게 보여 줍니다. PDA, Smartphone 및 포함된 장치에 전체를 할애하는 장도 있습니다. 이 장에서는 이러한 장치가 어떤 식으로 인프라에 심각한 위협이 될 수 있는지에 대해 설명하고 장치에서 사용하는 다양한 종류의 통신에 보안을 설정하는 방법을 보여 줍니다.
마지막으로 저자는 네 가지 사례 연구를 통해 사례별로 종단점이 어떤 식으로 손상되었는지와, 이러한 상황을 극복하기 위해 어떤 방법들이 이용되었는지 보여 줍니다. Endpoint Security는 보안 전문가에게 유용한 정보로 꽉 차 있습니다. 이 책에서 저자는 종단점 경계라는 위치에서 네트워크를 안전하게 보호하는 데 있어 확실한 답은 없다는 입장을 견지하고 있습니다.

가격: 정가 54.99달러

Greg Steen은 IT 전문가의 개발 및 관련 작업을 지원하기 위해 끊임없이 새로운 도구와 참조 자료를 모색하는 기술 전문가이자 기업가입니다. 제안할 사항이 있으시면 tntools@microsoft.com으로 연락하시면 됩니다.


 SQL Q&amp;A: 로그인 트리거, 데이터 파일 조각 모음 외
SQL Q&A
로그인 트리거, 데이터 파일 조각 모음 외
편집자: Nancy Michell

서비스 계정 설정
팁: 보다 안전한 암호
SQL Server 2000 엔진은 각 SQL Server 로그인 암호의 복사본을 두 개씩 유지합니다. 하나는 사용자가 실제로 입력한 암호이고 나머지 하나는 모두 대문자로 된 암호입니다.
사용자는 대/소문자를 혼합하거나 대문자로만 암호를 입력하여 로그인하고 서버에 대한 액세스 권한을 얻을 수 있으므로 이 방식은 대/소문자를 구분하지 않는 암호 유효성 검사 시 도움이 됩니다. 그러나 이러한 편리함과 더불어 주의를 기울여야 할 부분도 있습니다. 즉, 암호를 모두 대문자로만 저장할 경우 사용 가능한 암호 수가 줄기 때문에 무차별 암호 대입 공격에 취약해질 수 있습니다.
SQL Server 2005에서는 암호의 원본만 저장합니다. 즉, 사용자가 입력한 암호가 서버에 저장된 암호와 일치해야 합니다. 암호가 일치하지 않으면 사용자는 로그인에 실패하고 서버에 대한 액세스가 거부됩니다. 암호의 대/소문자를 정확히 기억하지 못하는 경우에는 암호를 다시 설정해야 합니다.
사용자의 로그인 이름이 SQLCOMMUNITY라고 가정할 경우 다음 명령을 사용하여 사용자의 SQL Server 암호를 다시 설정할 수 있습니다.
Use Master;
ALTER LOGIN SQLCOMMUNITY WITH PASSWORD = 'k3t9h4s8wJF7t';
이 명령은 SQLCOMMUNITY SQL Server 로그인 암호를 "k3t9h4s8wJF7t"로 다시 설정합니다.

Q: SQL Server™ 2000에서는 관리 도구의 서비스 애플릿을 사용하여 SQL Server 엔진 및 에이전트의 서비스 계정을 설정했습니다. SQL Server 2005에서는 구성 관리자 도구를 사용한다고 들었습니다. 이전처럼 Windows 도구를 계속 사용할 수는 없나요?
A: SQL Server 2005는 이전 버전보다 보안이 더욱 강화되었습니다. 대부분의 경우 사용자는 SQL Server를 실행하기 위해 LocalSystem과 같은 내부 계정을 설정합니다. 하지만 Windows®에서 이러한 계정에는 대개 필요한 것보다 많거나 적은 권한이 부여됩니다. SQL Server 2005 엔진 및 에이전트 서비스를 실행하려면 상승된 권한이 없는 Windows 계정을 만들어야 합니다. 구성 관리자를 사용하여 이러한 계정을 선택하면 SQL Server와 운영 체제 모두에서 적절한 권한이 자동으로 해당 계정에 부여됩니다. Windows 도구를 사용하여 SQL Server 서비스를 관리하는 경우 적절한 권한을 부여하지 않거나 너무 많은 권한을 부여하게 될 수도 있습니다.
자세한 내용은 서비스 계정 변경 팁을 참조하십시오.

누가 내 서버에 로그온하고 있나요?
Q: 누가, 언제 내 서버에 로그온하는지 알고 싶습니다. 또한 특정 시간대에는 특정 사용자만 서버에 로그온하도록 제한하고 싶습니다. 그리고 추적 기능을 실행하여 사용자 작업을 추적할 수 있는지 알고 싶습니다. 이러한 작업이 가능한가요?
A: 가능합니다. 서비스 팩 2가 설치되어 있는 SQL Server 2005에서는 이러한 작업을 모두 수행할 수 있습니다.
SQL Server 2005에서는 LOGON 이벤트에 응답하여 T-SQL 또는 저장 프로시저를 실행하는 로그인 트리거를 만들 수 있습니다. 로그인 트리거를 사용하면 로그인 작업을 추적하고 SQL Server에 대한 로그인을 제한하거나 특정 로그인에 대한 세션 수를 제한하여 사용자를 감사하고 제어할 수 있습니다. 이벤트는 로그인이 성공적으로 인증된 후 사용자 세션이 실제로 설정되기 전에 실행된다는 점에 주의하십시오. 따라서 PRINT 문의 트리거(예: 메시지 또는 오류) 내부에서 시작되는 모든 메시지는 SQL Server 오류 로그로 보내집니다. 로그인에 대한 인증이 실패할 경우에는 Logon 트리거가 실행되지 않습니다.
다음 예에서는 로그인 트리거를 만들어 사용자가 로그인하면 곧바로 SQL Server 오류 로그로 메시지를 보내는 방법을 보여 줍니다.
ALTER TRIGGER Ops_Login
ON ALL SERVER
AFTER LOGIN
AS
PRINT SUSER_SNAME() + ' has just logged in to ' + LTRIM(@@ServerName) + ' SQL Server at '+LTRIM(getdate())
GO
서버 수준에서 설정된 트리거를 모두 보려면 다음 쿼리를 사용합니다.
SELECT * FROM sys.server_triggers;

유용한 조각 모음 방법
Q: SQL Server에서 데이터 파일 조각화를 해결하는 가장 좋은 방법은 무엇입니까? Windows의 조각 모음 도구를 사용하면 SQL 데이터 파일 전체가 하나로 간주되므로 세부적으로 조각 모음되지 않습니다.
A: 데이터베이스를 백업한 다음 복원하는 방법을 사용할 수 있습니다. 연속된 파일을 저장할 공간이 있는 경우에는 데이터베이스가 연속적으로 쓰여집니다. 일반적으로 실제 파일에 대해 조각 모음을 수행하기 위해 시스템 작동을 중단시킬 필요는 없습니다. 대개의 경우 외부 조각화는 그다지 많지 않습니다. 정기적으로 데이터에 대한 인덱스를 다시 작성하여 가급적 내부 조각화를 줄이는 것이 더 유용한 방법입니다. 이렇게 하면 미리 읽기의 효과가 극대화되고 더 많은 데이터를 버퍼링할 수 있습니다.
효율적인 디스크 I/O를 위한 가장 중요한 요소는 디스크 배열과 RAID 구성을 올바르게 설정하고 I/O 부하를 적절히 처리하도록 디스크 배열을 확장하고 로그, 데이터, TempDB 및 백업 파일의 레이아웃을 적절하게 유지 관리하는 것입니다. 데이터 파일의 크기 조정을 위한 기본적인 방법으로 자동 증가와 자동 축소를 사용하지 않으면 생성되는 볼륨 수준 파일 조각의 수가 줄어듭니다. 예를 들어 500MB에 대해 10번의 자동 증가를 수행하면 10개의 새로운 실제 파일 조각이 추가되지만 5GB를 수동으로 한 번 증가시키면 한 개의 파일 조각만 추가됩니다.

팁: 서비스 계정 변경
Windows NT® 계정을 사용하여 SQL Server 서비스 로그인 계정을 구성할 경우 SQL Server에서는 몇 가지 파일, 폴더 및 레지스트리 키에 Windows 사용자 권한 및 사용 권한을 설정한다는 사실을 알고 계십니까? 관리 도구 내의 서비스 콘솔을 사용하여 SQL Server 서비스 계정을 설정할 수도 있습니다. 하지만 서비스 콘솔을 통해 서비스 계정을 설정할 경우 앞서 언급한 SQL Server 및 Windows 항목에 대한 권한 및 사용 권한이 설정되지 않게 되고 그 결과 이러한 항목에 대한 적절한 보안 설정이 없어서 심각한 문제가 발생할 수도 있습니다.
따라서 SQL Server 또는 SQL Server 에이전트 서비스 계정을 변경할 때는 서비스 콘솔이 아니라 SQL Server 구성 관리자를 사용해야 합니다. 그러나 서비스 콘솔을 통해 계정을 이미 변경한 경우에도 문제를 해결할 수 있습니다.
1단계: 다음 레지스트리 키 및 하위 키에 모든 권한을 적용합니다.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<MSSQL.x>
2단계: 다음 NTFS 폴더에 MSSQLServer 서비스 및 SQLServerAgent 서비스의 시작 계정(로컬 Windows NT 계정 또는 도메인 Windows NT 계정)에 대한 모든 권한을 설정합니다.
Drive:\Program Files\Microsoft SQL Server\<MSSQL.1>\MSSQL
SQL Server/에이전트의 서비스 계정을 변경하는 작업은 수동으로 수행하는 것보다는 SQL Server 구성 관리자를 사용하여 수행하는 것이 좋습니다.

기술적 자문에 응해 주신 Microsoft IT 전문가: Cary Gottesman, Saleem Hakani, Trayce Jordan, Peter Kalbach, Al Noel, Uttam Parui, Amber Sitko, Buck Woody


 Utility Spotlight: Virtual Machine Remote Control Plus
Utility Spotlight
Virtual Machine Remote Control Plus
Matthijs ten Seldam
이 기사의 코드 다운로드: UtilitySpotlight2007_10.exe (10163KB)

요즘 가상화가 화두입니다. 많은 IT 전문가가 교육 및 테스트용으로 하드웨어 가상화를 사용하고 있습니다. 이러한 상황에 발맞춰 Microsoft는 한정된 수의 가상 컴퓨터를 대상으로 설치할 수 있는 소프트웨어 가상화 솔루션인 Virtual PC 2007을 선보였습니다. 이 신제품은 데이터센터의 가상화에 사용되는 Virtual Server
2005를 대체하지는 않습니다.
Microsoft® Virtual Server 2005를 사용하면 서버 작업을 많은 부분 가상화할 수 있지만 Virtual PC와는 달리 인터페이스가 웹 응용 프로그램입니다. 웹 기반 관리 방식에도 장점은 있지만 일상적인 관리 작업에는 Windows® 응용 프로그램처럼 작동하는 UI를 선호하는 사람이 더 많습니다.
Virtual Machine Remote Control Plus(또는 줄여서 VMRCplus)는 Virtual Server 2005용 대체 UI입니다. VMRCplus는 Windows Forms 응용 프로그램으로서 Virtual Server와 가상 컴퓨터를 손쉽게 관리할 수 있는 기능을 제공합니다. Virtual Server에는 가상 컴퓨터의 원격 제어에 사용되는 VMRC라는 도구가 포함되어 있습니다. 그러나 VMRCplus는 단일 응용 프로그램에서 Virtual Server의 구성 관리 기능과 가상 컴퓨터의 원격 관리 기능을 동시에 제공합니다.

가상 컴퓨터 관리자
그림 1에는 가상 컴퓨터 관리자라고 하는 VMRCplus의 기본 창이 나와 있습니다. 이 예에서 가상 컴퓨터 관리자는 저장 상태의 컴퓨터 두 대와 꺼진 상태의 컴퓨터 세 대가 있는 로컬 호스트에 연결되어 있습니다. 목록에서 선택된 여섯 번째 컴퓨터에 대해 게스트 운영 체제, CPU 부하, 디스크 및 네트워크 I/O 통계, 설치된 추가 버전 등의 정보가 표시되어 있습니다. 이 목록은 상태를 기준으로 정렬되어 있습니다.
그림 1 VMRCplus 가상 컴퓨터 관리자
그림 1 VMRCplus 가상 컴퓨터 관리자
가상 컴퓨터 관리자를 통해 가상 서버에 연결하고 가상 컴퓨터를 표시할 수 있습니다. 그리고 호스트의 탭을 선택하는 방법으로 호스트 간을 전환하고, 도구 모음의 드롭다운 목록에서 선택하거나 호스트 이름 또는 IP 주소를 입력하여 호스트에 연결할 수 있습니다. 호스트에 연결되면 VMRCplus는 목록에 해당 이름이나 IP 주소를 추가합니다.
CPU 및 메모리 정보와 같은 일부 가상 서버 호스트 속성은 창의 아래쪽에 표시됩니다. 그 중 메모리 측정기를 통해 가상 컴퓨터에 사용할 수 있는 여유 RAM 용량을 한눈에 파악할 수 있습니다.

가상 서버 관리
가상 컴퓨터 관리자는 단순히 정보를 표시하는 데 그치지 않고 설정을 구성하는 기능도 제공합니다. View(보기) 메뉴를 통해 VMRCplus에서 가상 컴퓨터 목록을 업데이트하는 새로 고침 간격을 설정할 수 있습니다. 현재 새로 고침 간격 설정은 그림 1과 같이 창의 오른쪽 아래에 표시됩니다.
Virtual Server 메뉴에서는 VMRC(가상 컴퓨터 원격 제어) 설정, 새 가상 컴퓨터의 기본 위치, 보안 설정, 서비스 속성 등을 비롯한 가상 서버 구성에 액세스할 수 있습니다. VMRC 설정 페이지에서는 모든 속성을 설정하거나 VMRC를 사용하지 않도록 설정하거나 가상 서버 기본 설정으로 되돌릴 수 있습니다.
보안 설정 페이지에서는 가상 서버 사용 권한을 지정할 수 있습니다. 기본적으로 로컬 관리자 그룹에게는 가상 서버에 대해 모든 권한이 부여됩니다. 이러한 사용 권한은 그룹 또는 사용자별로 지정할 수 있습니다. 로컬 관리자 그룹의 구성원이 아닌 경우 먼저 그룹이나 계정을 추가한 후 적절한 사용 권한을 설정해야 합니다. VMRCplus 자체를 관리자로 실행할 필요는 없으며, 일반 사용자 권한으로도 충분합니다.
그림 2에는 물리적 속성을 포함한 가상 서버 호스트의 속성이 나와 있습니다. 이 호스트는 프로세서 기능과 마찬가지로 하드웨어 기반 가상화를 지원합니다.
그림 2 가상 서버 속성
그림 2 가상 서버 속성

가상 디스크 및 네트워크 관리
VMRCplus에는 특정 가상 서버 기능을 대상으로 한 다른 관리자도 포함되어 있습니다. Virtual Disks Manager는 하드 디스크(동적 또는 고정 디스크), 플로피 디스크 등의 생성 가능한 가상 디스크의 종류별로 각각에 해당하는 탭 인터페이스를 제공합니다. 또한 이 관리자에서 가상 디스크를 조사할 수도 있습니다.
Virtual Networks Manager는 가상 네트워크 관리 기능을 제공합니다. VNC(가상 네트워크 구성) 파일에 있는 가상 네트워크를 추가하거나 새 가상 네트워크를 만들 수 있습니다. 가상 네트워크를 만들 때에는 호스트 네트워크 어댑터를 연결하거나 네트워크를 게스트 전용으로 지정할 수 있습니다. 또한 같은 창에서 가상 DHCP 서버를 사용하도록 설정하고 해당 설정을 열 수 있습니다.

가상 컴퓨터 관리
앞에서 소개한 관리자는 주로 가상 서버 관리에 사용됩니다. 그렇다면 가상 컴퓨터를 만들고 구성하는 것과 관련해서 VMRCplus에서 제공되는 기능은 없는 것일까요?
가상 컴퓨터는 쉽게 만들 수 있습니다. 즉, 메뉴에서 Virtual machine(가상 컴퓨터) | Create(만들기)를 선택하기만 하면 됩니다. 이 메뉴를 선택하면 표시되는 대화 상자는 가상 서버의 해당 설정과 동일한 몇 가지 기본 설정이 제공되지만 인터페이스에 기본적인 차이점이 있습니다. 예를 들어 VMRCplus는 항상 두 개의 가상 하드 디스크를 만들어 SCSI에 연결합니다. 또한 한 번에 여러 개의 가상 컴퓨터를 만들 수도 있습니다. "Create multiple virtual machines(여러 가상 컴퓨터 만들기)"를 선택하고 원하는 가상 컴퓨터 수를 선택하기만 하면 됩니다. 이때 사용자가 가상 컴퓨터 이름을 입력하면 하이픈과 시퀀스 번호가 자동으로 추가됩니다.
가장 강력한 기능으로는 부모 가상 컴퓨터를 기반으로 여러 가상 컴퓨터를 만드는 기능을 들 수 있습니다. 예를 들어 최신 추가 기능, 서비스 팩, 핫픽스 및 도구가 모두 적용된 가상 컴퓨터를 만든 경우 해당 가상 컴퓨터를 기반으로 다른 가상 컴퓨터를 만들 수 있습니다. 마지막 단계로 sysprep를 실행하고 부모 가상 컴퓨터를 종료한 후 여러 가상 컴퓨터를 만들면 새로 만든 모든 가상 컴퓨터에 부모의 속성이 상속됩니다.
몇 초만에 동일한 부모를 기반으로 여러 가상 컴퓨터를 만들어 동일한 참조로 신속하게 모든 새 가상 컴퓨터를 시작할 수 있습니다. 그리고 테스트 등 필요한 작업을 마친 후에는 가상 컴퓨터를 삭제하면 됩니다. 뿐만 아니라 목록에서 여러 가상 컴퓨터를 선택하거나 열을 정렬할 수도 있습니다. 따라서 가상 컴퓨터를 한 번에 여러 개 선택해 제거(이 경우 등록이 취소됨)하거나 가상 컴퓨터를 완전히 삭제(이 경우 파일도 삭제됨)할 수 있습니다.
여러 항목을 선택하여 시작하거나, 여러 항목을 선택하여 콘솔을 열거나, 여러 항목을 선택하여 상태를 저장하는 등 다른 다중 선택 명령도 사용할 수 있습니다. 이러한 모든 작업은 UI를 통해, 또는 바로 가기 키를 사용하여 수행합니다.
하드웨어 설정 페이지를 사용하면 가상 컴퓨터를 쉽게 구성할 수도 있습니다. 메모리 용량을 설정하고, SCSI 컨트롤러를 추가하고, 끌어서 놓는 방법으로 간단히 디스크 또는 이미지를 연결하고, 네트워크 어댑터를 사용하도록 설정하거나 구성할 수 있습니다. 고급 속성 창에서는 기타 고급 구성 항목을 설정할 수 있습니다. 대표적인 예로 특정 사용자 계정으로 가상 컴퓨터를 실행하여 Virtual Server 시작 시에 가상 컴퓨터가 자동으로 시작되도록 설정할 수 있습니다.

원격 제어
마지막으로 VMRCplus에서는 가상 컴퓨터에 대한 원격 제어 세션(VMRC 세션)이 포함된 Console Manager를 제공합니다. 이 콘솔은 실행 중인 가상 컴퓨터를 하나 이상 선택하고 속성 도구 모음에서 가상 컴퓨터 콘솔 단추를 클릭하는 방법으로 엽니다.
그림 3에 나와 있는 Console Manager 창에서는 원격 세션이 탭으로 구성되어 있습니다. 따라서 해당 탭을 선택하면 가상 컴퓨터 간을 전환할 수 있습니다. 또한 자주 사용하는 기능이 포함된 도구 모음도 제공됩니다.
그림 3 Console Manager
그림 3 Console Manager
그림에서 보듯이 Console Manager는 가상 플로피 이미지나 ISO 이미지를 연결하고, 호스트 드라이브를 탑재하고, 현재 추가 기능을 설치할 수 있는 상황에 맞는 메뉴도 제공합니다. 그리고 CD/DVD 및 플로피 미디어의 상태, 가상 컴퓨터의 현재 추가 기능 버전, 현재 활성화된 호스트 키, 동적 화면 크기 조정 설정 등을 표시하는 상태 표시줄도 있습니다. VMRCplus에서는 호스트 키를 설정할 수 있습니다. 또한 가상 컴퓨터 하드웨어 설정과 고급 속성에 액세스할 수도 있습니다.
VMRCplus는 다른 유용한 기능도 몇 가지 제공합니다. 예를 들어 가상 컴퓨터 설정을 스크린샷으로 찍어 .jpg 파일로 저장하면 문제를 해결할 때 유용하게 사용할 수 있습니다. 뿐만 아니라 가상 컴퓨터에 텍스트를 키 입력으로 보내는 "Send Text to Virtual Machine(가상 컴퓨터에 텍스트 보내기)" 기능도 제공됩니다. 이 기능을 클립보드 기능으로 사용할 수는 없지만 호스트에서 가상 컴퓨터로 제품 키를 복사해 붙여 넣어야 하는 등의 경우에 유용합니다.
VMRCplus는 원래 Paul Despe가 몇 가지 기본 기능을 처리하는 개발자 도구로 작성했으며, Virtual Server의 모든 기능을 지원하지는 못했습니다. 때문에 테스트용으로만 사용되었고 문제점도 많았습니다. 약 1년 후에 필자는 해당 코드를 다시 작성하여 개선하고 기능도 확장했습니다. 그때부터 Microsoft 내에서 Virtual Server 사용자들 사이에 선풍적인 인기를 끌기 시작했습니다. 그러나 VMRCplus는 공식적으로 지원되는 Microsoft 응용 프로그램이 아닙니다. 따라서 포함된 최종 사용자 사용권 계약 조건에 따라 있는 그대로만 제공됩니다.
VMRCplus는 Virtual Server 2005 서비스 팩 1용으로 개발되었으며, 이전 버전도 호환되지만 서비스 팩 1에서만 테스트되었습니다. 따라서 이 도구를 사용하기 전에 Virtual Server 호스트를 서비스 팩 1로 업데이트해야 합니다. VMRCplus는 TechNet Magazine 웹 사이트(technetmagazine.com/code07.aspx)에서 다운로드할 수 있습니다.

Matthijs ten Seldam은 Microsoft Consulting Services의 컨설팅 팀장으로, 보안, 배포, 자동화 등의 분야를 주로 다루며, 가상화 분야의 전문가이기도 합니다.


 The Business of IT: 정부 부문 IT 인프라 가치 평가
The Business of IT
정부 부문 IT 인프라 가치 평가
Acer Maamoun

정부 조직에서 하드웨어와 소프트웨어를 모두 포함한 IT 인프라 투자의 효과를 증명하는 것은 쉽지 않은 일입니다. 다른 대규모 조직에서와 마찬가지로 관리자들은 모든 추가 사항과 개선 사항의 사업적 근거를 담은 비즈니스 사례를 제시해야 하고, 그것은 다시 다른 모든 자금 지원 요청들과 견주어 우선 순위를 지정 받게 됩니다.
비즈니스 사례를 구성하는 방식은 매우 다양하므로 IT 관리자들은 해당 조직 문화에 가장 적합한 방식을 선택해야 합니다. 이 원칙은 일반 기업에서와 마찬가지로 정부 조직에도 해당합니다. 다른 사업적 우선 사항과 조화를 이루도록 IT의 요구 사항을 조정하는 것은 필수적입니다. 정부 부문에서 IT 조직은 프로젝트와 이니셔티브의 포트폴리오를 작성하는 과정에서 공공 가치라는 개념을 적용하여 비즈니스 사례를 성공적으로 구성해왔습니다.
인프라의 개선이 어떻게 생산성 향상이나 서비스 개선으로 이어지는지 명확히 보여주는 비즈니스 사례를 구성하는 것은 매우 어려운 작업입니다. 그러면 실제 정부 부분의 IT 조직에서 채택하고 있는 몇 가지 솔루션, 즉 IT 인프라 투자가 함축하고 있는 가치를 정의하고 측정하는 솔루션을 몇 가지 살펴보겠습니다.

투자 근거 제시
IT 부서 내에서 공통된 불만 중 하나는 너무나 다양한 업무 부서에서 너무나 다양한 요구가 들어 온다는 점, 그리고 그 각각의 요구가 모두 상당히 긴급하다는 점입니다. 새로운 이니셔티브는 개별 부서의 규제 요건 또는 업무 우선 순위에 따라 배치되는 경향이 있습니다. 이러한 이니셔티브는 마구 모아놓은 것처럼 보일 수도 있지만 해당 부처에서 추구하는 공공의 가치와 긴밀한 연관을 맺고 있는 경우가 많습니다.
한편으로, 개별 부서의 운영에 사용되는 금액에 따라 경상 비용을 할당하는 방식에서는 전사적 기능 또는 공유 서비스의 비용 및 가치가 드러나지 않을 수 있습니다. 이러한 환경에서는 새로운 인프라에 대한 투자 또는 기존 인프라의 개선이 갖는 가치, 즉 전사적 차원에서 영향을 미치거나 개별 부서의 목표와 간접적으로 연결되는 가치를 적절히 평가하기가 지극히 어렵습니다.
따라서 IT 조직 전체적으로는 GSA Federal Enterprise Architecture Framework(whitehouse.gov/omb/egov/a-1-fea.html)에 언급된 것처럼 IT에 대한 전사적 관점을 지원하기 어려운 경우가 많습니다. 이러한 환경에서는 전사적 아키텍처에 대한 공동의 관점, 공통된 비즈니스 사례 개발 모델, 그리고 IT 투자 요구와 지출을 공평하게 배치할 수 있는 포트폴리오 관리 과정을 채택하려는 노력은 대부분 실현되기 어렵습니다. 더욱 효과적인 모델은 공공의 가치 이익을 효율적으로 극대화하는 IT 활동의 포트폴리오를 지원하는 것입니다. 이를 위해서는 공통된 공공의 가치 기준을 선택하여 비즈니스 사례 개발, 포트폴리오 관리, 이익 실현 및 평가 등의 과정 전반에 강제해야 합니다.

가치 측정
전사적 IT 투자에는 실질적인 문제가 몇 가지 있습니다. 이러한 투자는 공공의 가치 이익이라는 측면에서 그 효과가 비교적 간접적, 장기적으로 실현됩니다. 이러한 효과는 조직의 다양한 부분들 사이에서 불균등하게, 그리고 미리 파악하기 쉽지 않은 방식으로 발생하는 경우가 많습니다. 또한 공공의 가치는 쉽게 가시화되거나 계량화되지 않는 반면 이러한 투자와 관련된 위험과 비용은 비교적 쉽게 인지됩니다.
비즈니스 사례는 인프라 투자가 현재의 활동뿐만 아니라 미래의 투자에 미치는 영향까지 고려하여 구성해야 합니다. 이러한 가치를 평가하는 방법은 여러 가지가 있는데, 각기 고유의 장단점을 갖고 있으며 특정 조직의 문화와 성숙도에 따라 적합성도 각기 다릅니다.
수학적 방법 이것은 잠재적 효과를 수학적 모델로 구성하여 분석하는 방법입니다. 그 중 하나인 '실질 옵션 평가법'은 금융 이론에 근거한 효과적 방법입니다. 이 방법은 주어진 비용과 주어진 기간 안에 어떠한 행동을 취할 권리(즉, 실질 선택권)를 명시적으로 고려함으로써 미래의 변화와 융통성을 반영하는 방법입니다. 선택 가능한 옵션으로는 투자 연기/확장/준비/포기, 투입량 또는 산출량 변경, 파일럿 개발 등이 있습니다.
실질 옵션은 미래의 사건이 투자 결정에 영향을 미치는 경우에 특히 적합합니다. IT 인프라의 경우에는 규정 요건이나 사업적 요구, 또는 중대한 운영 장애와 같은 결정적 사건도 포함될 수 있습니다.
시뮬레이션 불확실성 분석은 몬테 카를로 시뮬레이션을 기반으로 합니다. 이 시뮬레이션에서는 자동화된 도구를 사용하여 가변적 변수의 선택과 프로세스의 반복을 바탕으로 여러 대안적 시나리오의 결과를 추산합니다. 이 시뮬레이션을 위해서는 각 변수의 확률 분포와 값의 범위(영향 받는 워크스테이션 또는 전자 채널 업테이크 등)를 파악해야 합니다. 시뮬레이션에서 산출되는 것은 가능한 결과의 범위이며, 이를 이용하면 비용과 위험뿐만 아니라 이익의 평균값을 파악할 수 있습니다. 값과 위험 변수를 신중히 선택하여 인프라 투자가 발휘할 수 있는 영향을 반영하면 그러한 투자의 수익을 가늠할 수 있습니다.
시나리오 수학적 모델 시뮬레이션 모델이 비현실적이거나 조직의 문화와 숙련도에 적당하지 않을 때는 시나리오에 입각한 기법이 대신 사용될 수 있습니다. 해당 기관의 업무 내용과 정치적 우선 순위, 환경적 추세(기술 포함)를 반영하여 향후 3~5년의 상황을 적당히 반영하는 제한된 수의 시나리오를 구성할 수 있습니다. 각 시나리오는 오로지 인프라 투자의 수익을 증명하는 데 초점을 맞추어야 합니다.
장기적인 계획 수립과 달리, 시나리오는 반드시 상호 배타적일 필요는 없으며 확률을 반영할 수 있습니다. 시나리오에는 미래의 선거, 정치적 논쟁의 결과, 그리고 기업 인수나 벤더 전략의 중대 변화 등 IT 시장에서 발생할 수 있는 사건을 반영할 수 있습니다.
최악의 시나리오 시나리오 기반 접근 방식의 한 변종으로서, 임박한 업무적 또는 사업적 과제에 대응하기 위해 또는 단지 현재의 서비스 수준을 유지하기 위해서라도 투자가 시급하다고 판단하는 경우에 적용됩니다. 즉, 인프라 문제를 방치할 경우, 더욱 악화되며 이를 시정하기 위해 필요한 노력이 그만큼 증가하고, 누가 변화를 추진하더라도 저항에 직면할 가능성이 높으며 노력을 인정 받을 가능성은 낮은 상황을 말합니다. 그러한 상황은 요청에 대한 응답 시간 및 수리 소요 시간 등 영향 받는 성과와 관련된 수치 및 측정 결과를 강력히 강조함으로써 부분적으로 개선될 수 있습니다. 사람들이 성과의 변화 가능성을 인지할 수 있도록 이러한 정보를 널리 보급해야 합니다.
최악 시나리오 방식은 투자를 행하지 않을 경우 발생하는 결과를 그 부정적 영향과 위험 증가에 초점을 맞춰 의도적으로 강조합니다. 이러한 접근은 대단한 주의를 요하며, 매우 예외적인 상황에서만 사용되어야 합니다. 이 방식을 자주 사용하게 되면 IT 조직이 기존에 확립된 투자 관리 프로세스를 뒤엎으려 한다는 인상을 주게 될 수 있으며, 지금까지 해결에 도움이 되어 왔던 바로 그 프로세스와 불필요한 충돌과 불일치를 야기할 수 있습니다.

계획 수립 방법론의 선택
그림 1에는 각 방법의 장단점과 적용 기준이 요약되어 있습니다. 한 가지 방법을 선택했으면 비교가 가능하도록 조직 전체에 일관되게 적용해야 합니다.
Figure 1 비즈니스 사례 구성 방법론 (Close Figure 1)

방법 장점 단점 적용 기준
실질 옵션(수학적 방법)
  • 정밀성
  • 탄탄한 이론적 토대
  • 복잡성
  • 무형적 가치가 우세할 경우에는 적절치 않음
  • 가치와 미래 가치를 대부분 계량화할 수 있음
  • 투자를 중시하는 분위기가 강함
  • 기술적 능력이 갖춰진 경우
시뮬레이션
  • 다양한 대안적 값과 변수 평가 가능
  • 대안을 쉽게 구성할 수 있음
  • 무형적 효과의 평가에는 평균치가 큰 의미 없음
  • 변수의 범위 선택이 매우 중요
  • 유형적 효과가 우세
  • 도구 지원 가능
시나리오
  • 무형적 유형적 효과의 다양한 조합이 가능
  • 다양한 기법을 조합하여 매우 다양한 시나리오를 검토할 수 있음
  • 시나리오의 비교가 가능하도록 집중하려면 강력한 규율이 필요함
  • 시간적 분포가 매우 다양할 수 있음
  • 무형적 가치가 우세하거나 효과의 실질적 성격이 불분명한 경우
  • 조직의 분위기가 다른 방식에 적대적일 경우
최악의 시나리오
  • 투자 불이행에 따르는 결과를 효과적으로 제시할 수 있음
  • 구성이 간단함
  • 우선 순위 결정에는 도움이 되지 않음
  • 남용될 수 있음
  • 투자가 절대적으로 필요하거나 시급한 경우
각 접근 방식의 효과는 다양한 요소에 의해 결정됩니다. 다음 질문에 대한 대답은 좋은 출발점이 될 것입니다. 이 방식은 필수적 프로세스(예산 및 자본 투입 계획)와 어느 정도로 통합되고 부합되는가? 선택한 비즈니스 사례 방법론은 적용이 용이하며 이해 관계자들에게 그 가치를 알리는 데 효과적인가?
조직은 특정 기관에 맞는 가치 지표 선택 과정에서의 융통성과 여러 기관 사이에 공통된 비교 기준을 확보하기 위한 지침 제공 사이에서 균형을 찾아야 합니다. 또한 주어진 가치 산정 방법을 비즈니스 사례에 포함된 시점뿐만 아니라 투자 전주기에 걸쳐 적용할 수 있는 능력이 결정적으로 중요합니다. 마찬가지로 계획은 다양한 종류의 투자에 효용성을 가져야 합니다.
따라서 가치 평가 방법은 해당 조직의 지배 구조에 참여하는 주체들과 함께 선택, 개발되어야 합니다. 또한 선택된 틀은 반드시 내부 및 외부의 이해 관계자들에게 그 가치를 효과적으로 알릴 수 있어야 합니다. 이 점은 대기업 경영진과 마찬가지로 민선 공무원이나 정부 기관 경영진에게도 적용되는 사실입니다.
추가 리소스
  • 웹 캐스트: 전략적 비즈니스 자산으로서의 IT
  • IT 관리자 커넥션 시리즈

Acer Maamoun은 Microsoft의 엔터프라이즈 전략 컨설턴트로서 IT 전략 및 사업 조정 부문에서 18년이 넘는 경력을 가지고 있습니다.


 The Cable Guy: 인증된 인터넷 프로토콜
The Cable Guy
인증된 인터넷 프로토콜
Joseph Davies
이 칼럼의 일부에서는 Windows Server 2008의 시험판 버전을 다룹니다. 이에 대한 자세한 내용은 변경될 수 있습니다.

Windows Vista 및 Windows Server 2008(현재 베타 테스트 중)에서는 AuthIP(인증된 인터넷 프로토콜) 및 IKE(인터넷 키 교환) 프로토콜의 향상된 버전을 모두 지원합니다. AuthIP와 IKE는 모두 키 자료를 확인하고 IPSec(인터넷 프로토콜 보안)을 사용하여 보호되는 통신을 위한 보안 매개 변수를 협상하는 데 사용되는
프로토콜입니다. AuthIP에서는 다양한 구성에서의 단순화된 IPsec 정책 구성 및 유지 관리 기능을 제공하며 IPsec 피어 인증을 위한 추가적인 유연성을 제공합니다. 이 기사에서는 AuthIP 프로토콜을 자세히 설명하고 AuthIP와 IKE를 모두 지원하거나 IKE만 지원하는 IPsec 피어 간의 공존 동작에 대해 설명합니다.

IKE 개요
협상 예
공존 동작의 이해를 돕기 위해 IPsec 보호 협상을 시도할 때 Windows Vista와 Windows XP 기반 IPsec 피어 간에 발생하는 동작을 살펴보겠습니다.

예 1: 요청 모드에 있는 두 Windows Vista 기반 IPsec 피어
이 예에서는 Windows Vista 기반 IPsec 피어(피어 1)가 초기자이며 응답자에서 Windows Vista(피어 2)가 실행 중입니다. 두 피어 모두 인바운드 및 아웃바운드 통신에 대해 요청 모드로 구성되어 있습니다. 요청 모드에서 IPsec 피어는 IPsec 보호를 요청하지만 이 기능을 필요로 하지는 않습니다. 교환되는 메시지는 다음과 같습니다.
  1. 피어 1이 일반 텍스트 TCP 동기화(SYN) 세그먼트를 보내 피어 2와의 TCP 연결을 초기화합니다.
  2. 피어 2가 TCP SYN-ACK(승인) 세그먼트를 보냅니다.
  3. 피어 1이 TCP ACK 세그먼트를 보냅니다.
  4. 피어 1이 AuthIP 기반 ISAKMP 메시지를 보내 AuthIP 주 모드 협상을 초기화합니다.
  5. 피어 1이 IKE 기반 ISAKMP 메시지를 보내 IKE 주 모드 협상을 초기화합니다.
  6. 피어 2가 AuthIP 기반 ISAKMP 메시지로 응답하여 AuthIP 주 모드 협상을 계속합니다.
  7. 피어 1과 2가 AuthIP 주 모드, 빠른 모드 및 확장 모드(선택 사항) 협상을 완료합니다.
  8. 이제 TCP 연결을 통해 전송되는 이후 세그먼트는 IPsec으로 보호됩니다.
메시지 1 - 5의 정확한 순서는 네트워크 지연에 따라 달라집니다. 이 기사에서 설명하는 예는 TCP 핸드셰이크(메시지 1 - 3)가 완료된 후에 피어 1에서 초기 ISAKMP 메시지(메시지 4 - 5)를 보낼 수 있는 지연이 매우 낮은 네트워크에 해당합니다. 지연이 높은 네트워크에서는 피어 1이 메시지 교환의 처음 세 메시지로 일반 텍스트 TCP SYN 세그먼트, AuthIP 기반 ISAKMP 메시지, IKE 기반 ISAKMP 메시지를 보내는 경우를 볼 수 있습니다.

예 2: 요청 모드의 Windows Vista 기반 IPsec 피어 및 요청 모드의 Windows XP 기반 IPsec 피어
이 예에서는 Windows Vista 기반 IPsec 피어(피어 1)가 초기자이며 응답자에서 Windows XP(피어 2)가 실행 중입니다. 두 피어 모두 인바운드 및 아웃바운드 통신에 대해 요청 모드로 구성되어 있습니다. 교환되는 메시지는 다음과 같습니다.
  1. 피어 1이 일반 텍스트 TCP SYN 세그먼트를 보내 피어 2와의 TCP 연결을 초기화합니다.
  2. 피어 2가 TCP SYN-ACK 세그먼트를 보냅니다.
  3. 피어 1이 TCP ACK 세그먼트를 보냅니다.
  4. 피어 1이 AuthIP 기반 ISAKMP 메시지를 보내 AuthIP 주 모드 협상을 초기화합니다.
  5. 피어 1이 IKE 기반 ISAKMP 메시지를 보내 IKE 주 모드 협상을 초기화합니다.
  6. 피어 2가 IKE 기반 ISAKMP 메시지로 응답하여 IKE 주 모드 협상을 계속합니다.
  7. 피어 1과 2가 IKE 주 모드 및 빠른 모드 협상을 완료합니다.
  8. 이제 TCP 연결을 통해 전송되는 이후 세그먼트는 IPsec으로 보호됩니다.

예 3: 요청 모드의 Windows Vista 기반 IPsec 피어 및 필요 모드의 Windows XP 기반 IPsec 피어
이 예에서는 Windows Vista 기반 IPsec 피어(피어 1)가 초기자이고 응답자에서 Windows XP(피어 2)가 실행 중입니다. 피어 1은 아웃바운드 통신에 대해 요청 모드로 구성되어 있으며 피어 2는 인바운드 통신에 대해 필요 모드로 구성되어 있습니다. 필요 모드에서 IPsec 피어는 IPsec 보호를 필요로 하며 보호되지 않은 패킷은 자동으로 버립니다. 교환되는 메시지는 다음과 같습니다.
  1. 피어 1이 일반 텍스트 TCP SYN 세그먼트를 보내 TCP 연결을 초기화하나 피어 2에서 이를 자동으로 버립니다.
  2. 피어 1이 AuthIP 기반 ISAKMP 메시지를 보내 AuthIP 주 모드 협상을 초기화하나 피어 2에서 이를 자동으로 버립니다.
  3. 피어 1이 IKE 기반 ISAKMP 메시지를 보내 IKE 주 모드 협상을 초기화합니다.
  4. 피어 2가 IKE 기반 ISAKMP 메시지로 응답하여 IKE 주 모드 협상을 계속합니다.
  5. 피어 1과 피어 2가 IKE 주 모드 및 빠른 모드 협상을 완료합니다.
  6. 피어 1이 TCP SYN 세그먼트(IPsec으로 보호됨)를 다시 전송합니다.
  7. 피어 2가 TCP SYN-ACK 세그먼트(IPsec으로 보호됨)를 보냅니다.
  8. 피어 1이 TCP ACK 세그먼트(IPsec으로 보호됨)를 보냅니다.

IKE는 IPsec SA(보안 연결)를 설정하기 위한 메커니즘을 정의하는 RFC 2409(ietf.org/rfc/rfc2409.txt)에 정의된 인터넷 표준입니다. SA는 보안 서비스를 정의하는 상호 협의 가능한 정책과 키 및 IPsec 피어 간의 통신을 보호하는 데 도움이 되는 메커니즘의 조합입니다. 특히, IKE는 RFC 2408의 ISAKMP(인터넷 보안 연결 및 키 관리 프로토콜)와 Oakley Key Determination Protocol(RFC 2412)의 조합하며 통신을 보호하기 위한 비밀 키 자료를 생성하는 데 Oakley Key Determination Protocol을 사용합니다.
IKE는 ISAKMP를 사용하여 SA를 협상합니다. ISAKMP에는 피어를 식별 및 인증하고, SA를 관리하고, 키 자료를 교환하는 기능이 있습니다. ISAKMP는 특정 키 교환 프로토콜, 암호화 및 무결성 알고리즘, 인증 방법과 독립적으로 보호된 통신을 협상하기 위한 프레임워크입니다.
IPsec 피어에서는 IKE를 사용하여 주 모드 및 빠른 모드 협상을 수행합니다. 주 모드 협상에서는 보안 협상을 보호하는 ISAKMP SA를 만듭니다. 주 모드 협상 도중 초기자와 응답자는 ISAKMP SA에 대한 암호화와 해싱 알고리즘을 협상하고, 키 확인 자료를 교환하고, 서로를 식별하고 인증하기 위해 일련의 ISAKMP 메시지를 교환합니다.
빠른 모드 협상 단계에서는 두 IPsec 피어 사이에서 전송되는 데이터를 보호하는 두 IPsec SA(인바운드 데이터를 위한 SA와 아웃바운드 데이터를 위한 SA)가 생성됩니다. 빠른 모드 협상 도중 초기자와 응답자는 일련의 암호화된 ISAKMP 메시지를 교환하여 인바운드 및 아웃바운드 IPsec SA 모두를 위한 암호화 및 해싱 알고리즘을 협상합니다.
IKE 기반 주 모드 및 빠른 모드 협상에 대한 자세한 내용은 microsoft.com/technet/community/columns/cableguy/cg0602.mspx의 "IPsec 보안 연결을 위한 IKE 협상"을 참조하십시오.

AuthIP 개요
AuthIP는 사용자 기반 인증, 여러 자격 증명을 사용한 인증, 향상된 인증 방법 협상 및 비대칭 인증을 지원함으로써 추가적인 유연성을 제공하는 향상된 버전의 IKE입니다. IKE와 마찬가지로 AuthIP는 주 모드 및 빠른 모드 협상을 지원합니다. 또한 AuthIP는 IPsec 피어 협상의 일부로 2차 인증을 수행할 수 있는 확장 모드를 지원합니다. 선택 사항인 확장 모드는 여러 인증에 사용할 수 있습니다. 예를 들어 확장 모드를 사용하면 별도의 컴퓨터 기반 및 사용자 기반 인증을 수행할 수 있습니다.
다중 인증 지원은 NAP(네트워크 액세스 보호) 플랫폼에 대한 IPsec 적용 작업의 일환입니다. 여기서 IPsec 피어는 컴퓨터 자격 증명을 사용하여 인증하며 상태 인증서를 사용하여 시스템 상태 요구 사항을 준수함을 입증합니다. 네트워크 액세스 보호에 대한 자세한 내용은 microsoft.com/nap를 참조하십시오. 또한 AuthIP의 기능에 대한 자세한 내용은 microsoft.com/technet/community/columns/cableguy/cg0806.mspx의 "Windows Vista의 AuthIP"를 참조하십시오.

AuthIP 메시지
IKE와 AuthIP 모두 ISAKMP를 키 교환 및 SA 협상 프로토콜로 사용합니다. ISAKMP 메시지는 UDP(User Datagram Protocol)를 통해 전송되며 ISAKMP 헤더와 하나 이상의 ISAKMP 페이로드로 구성됩니다. ISAKMP 헤더에는 메시지 유형을 포함한 메시지 관련 정보가 포함됩니다. 그림 1에는 ISAKMP 헤더의 형식이 나와 있습니다.
그림 1 ISAKMP 헤더의 형식
그림 1 ISAKMP 헤더의 형식
ISAKMP 헤더에서 초기자 쿠키 및 응답자 쿠키는 IPsec 피어가 선택한 0이 아닌 임의의 숫자로 설정됩니다. 다음 페이로드 필드는 ISAKMP 헤더 이외의 ISAKMP 메시지의 첫 번째 페이로드를 나타냅니다. RFC 2408에 다음 페이로드 필드의 정의된 값이 나열되어 있습니다. 페이로드 유형 128-255는 내부용으로 예약되어 있습니다. 주 버전 및 부 버전 필드는 ISAKMP 메시지를 전송하는 IPsec 피어의 ISAKMP 버전을 나타냅니다. IKE 및 AuthIP의 경우 주 버전은 1이고, 부 버전은 0입니다.
교환 유형 필드는 수행되는 ISAKMP 교환의 유형을 나타냅니다. 교환 유형에 따라 ISAKMP 페이로드의 구조와 순서가 결정됩니다. RFC 2408에 교환 유형 필드의 값이 정의되어 있습니다. 교환 유형 128-255는 내부용으로 예약되어 있습니다.
플래그 필드에는 RFC 2408에 정의된 세 개의 플래그가 있습니다. 순위가 낮은 비트(비트 0)는 ISAKMP 페이로드가 암호화되었는지(1로 설정된 경우) 또는 암호화되지 않았는지를(0으로 설정된 경우) 나타내는 암호화 비트입니다. 암호화는 ISAKMP SA에 대해 협상된 알고리즘을 사용하여 수행되며, 이러한 알고리즘은 초기자 쿠키 및 응답자 쿠키 필드의 조합으로 식별됩니다. 다음으로 순위가 낮은 비트(비트 1)는 커밋 비트로, 키 교환이 동기화되었는지(1로 설정된 경우) 또는 동기화되지 않았는지를(0으로 설정된 경우) 나타냅니다. 커밋 비트는 암호화된 데이터가 전송되기 전에 SA가 협상을 완료하도록 하는 데 사용됩니다. 다음으로 순위가 낮은 비트(비트 2)는 인증만 수행 비트로, 메시지에 정보 교환 유형의 전체 알림 페이지로드가 포함되었는지(1로 설정된 경우) 또는 포함되지 않았는지를(0으로 설정된 경우) 나타내고, 인증되었으나 암호화되지 않았음을 나타내는 데 사용됩니다.
메시지 ID 필드에는 메시지에 대한 고유 ID가 포함됩니다. 메시지 ID는 두 IPsec 피어가 동시에 IPsec SA를 설정하려고 할 때 충돌을 방지하는 데 사용됩니다. 길이 필드는 전체 ISAKMP 메시지의 길이를 나타냅니다.
IKE의 경우 ISAKMP 메시지에는 일련의 ISAKMP 페이로드가 포함됩니다. 첫 번째 페이로드는 ISAKMP 헤더의 다음 페이로드 필드로 나타냅니다. 각 ISAKMP 페이로드에는 다음 페이로드를 나타내는 자체 다음 페이로드 필드가 있습니다. 마지막 페이로드의 다음 페이로드 필드는 0으로 설정됩니다. 그림 2에는 IKE 메시지의 형식이 나와 있습니다.
그림 2 IKE 메시지의 형식
그림 2 IKE 메시지의 형식
AuthIP는 ISAKMP 헤더의 교환 유형 필드에서 교환 유형이 243(주 모드), 244(빠른 모드), 245(확장 모드) 및 246(알림)인 ISAKMP 메시지를 사용합니다. AuthIP 기반 ISAKMP 메시지의 중요한 차이점은 이 메시지에는 하나의 ISAKMP 페이로드(암호화 페이로드 또는 알림 페이로드)만 포함된다는 점입니다. 암호화 페이로드에는 주 모드, 빠른 모드 또는 확장 모드 협상에 사용되는 포함된 페이로드가 있습니다. 암호화 페이로드에는 ISAKMP 헤더의 플래그 필드에 지정된 암호화 비트에 따라 일반 텍스트 또는 암호화된 페이로드 집합이 포함될 수 있습니다. 그림 3에는 암호화 페이로드가 포함된 AuthIP 메시지의 형식이 나와 있습니다.
그림 3 암호화 페이로드가 포함된 AuthIP 메시지의 형식
그림 3 암호화 페이로드가 포함된 AuthIP 메시지의 형식

AuthIP 및 IKE 공존
Windows Vista® 및 Windows Server® 2008에서는 IKE와 AuthIP를 모두 지원합니다. 하지만 Windows® XP와 Windows Server 2003에서는 IKE만 지원합니다. AuthIP와 IKE를 모두 지원하며 AuthIP와 IKE를 모두 사용하는 연결 보안 정책이 있는 초기 IPsec 피어는 응답 IPsec 피어가 AuthIP 또는 IKE 중 무엇을 지원하는지 확인해야 합니다. 그런 다음 IPsec 보호 협상에 가장 적합한 프로토콜을 사용해야 하며 IKE보다 AuthIP를 사용하는 것이 좋습니다.
응답 IPsec 피어의 협상 프로토콜을 확인하기 위해 AuthIP와 IKE를 모두 사용하는 초기 IPsec 피어는 동시에 다음 메시지를 보냅니다.
  • 메시지 1—주 모드 협상을 초기화하는 AuthIP 메시지
  • 메시지 2—주 모드 협상을 초기화하는 IKE 메시지
응답 노드가 AuthIP를 지원하는 경우에는 메시지 1에 주 모드 협상을 계속하는 AuthIP 메시지로 응답하고 메시지 2는 자동으로 버립니다. AuthIP를 지원하지 않는 응답 노드의 경우 메시지 1에 포함된 교환 유형 필드에 지원하지 않는 값이 있기 때문에 이 메시지를 자동으로 버리고 메시지 2에 응답합니다.
메시지 1이 네트워크에서 버려지거나 메시지 2 다음에 도착하는 경우 Windows Vista 또는 Windows Server 2008이 실행 중인 두 IPsec 피어 간의 IKE 기반 협상이 수행되는 현상을 방지하기 위해 Windows Vista 또는 Windows Server 2008이 실행 중인 IPsec 피어에서는 메시지 2와 함께 AuthIP 지원 공급업체 ID ISAKMP 페이로드를 보냅니다. AuthIP 지원 공급업체 ID 페이로드는 IPsec 피어가 AuthIP를 지원함을 나타냅니다.
따라서 Windows Vista 또는 Windows Server 2008이 실행 중인 IPsec 피어가 AuthIP 지원 공급업체 ID 페이로드와 함께 메시지 2를 수신하면 초기 IPsec 피어가 메시지 1과 2를 다시 전송할 때까지 기다린 후 메시지 1에 응답합니다.
초기 IPsec 피어는 응답을 수신하거나 시간이 만료될 때까지 메시지 1과 2를 계속 다시 전송합니다. 초기자는 응답을 수신하면 응답의 ISAKMP 헤더에서 응답자가 지원하는 교환 유형을 확인합니다. 교환 유형이 243(AuthIP 기반 주 모드 협상에 대한 교환 유형)으로 설정된 경우 응답자는 AuthIP를 지원하며 교환 유형이 2(ID 보호 및 IKE 기반 주 모드 협상에 대한 교환 유형)로 설정된 경우 응답자는 IKE를 지원합니다.
초기자는 응답에 따라 AuthIP 주 모드 협상의 경우 다음 AuthIP 메시지 또는 IKE 주 모드 협상의 경우 다음 IKE 메시지로 응답합니다. IPsec 피어는 SA의 수명 동안 ISAKMP SA를 협상하는 데 사용된 것과 같은 프로토콜을 사용해야 합니다.

Joseph Davies는 Microsoft의 테크니컬 라이터이자 Microsoft.com/technet/community/columns/cableguy의 월간 온라인 TechNet Cable Guy 칼럼의 저자입니다.


 Windows PowerShell: 스크립트가 필요 없는 작업
Windows PowerShell
스크립트가 필요 없는 작업
Don Jones

회의, 공개 Windows PowerShell 뉴스 그룹 또는 필자의 사이트 등에서 Windows PowerShell에 대해 이야기할 때면 항상 Windows PowerShell을 곧 "배우려고 한다"는 관리자를 만나게 됩니다. 이유가 무엇일까요? 가장 흔한 이유는
"지금은 스크립트 방법을 배울 시간이 없기 때문"이라고 합니다.
공감이 가는 얘기입니다. 관리자는 바쁜 직업이며 새 기술을 배울 시간이 부족한 것이 사실입니다. 하지만 관리자는 관리자 작업에 중요한 기술의 발전을 따라잡기 위해 Windows Vista®, Windows Server® 2008 및 Exchange Server 2007과 같은 새 소프트웨어를 배워 항상 앞서 나가도록 노력해야 합니다. Windows PowerShell™은 이러한 기술의 큰 부분 중 하나입니다.
관리자들이 Windows PowerShell의 스크립트 배우기를 미루는 다른 이유는 "프로그래머가 되는 것에 대한 두려움" 때문입니다. 이 이유라면 필자가 도움을 드릴 수 있습니다. 약간의 코드도 작성하지 않고 Windows PowerShell을 사용하여 할 수 있는 일이 얼마나 강력한지 알게 되면 놀랄 것입니다.

파이프라인 준비
필자는 이전에 Windows PowerShell에서 사용되는 매우 유연하며 강력한 개체 지향적 파이프라인에 대해 설명한 적이 있습니다. "개체 지향적"이라는 단어 때문에 프로그래밍 분야로 들어가는 것이 아닌지 의심할 수 있겠지만 제 얘기를 계속 들어 보십시오. 파이프라인의 장점 중 하나는 대화식으로 사용할 수 있다는 점입니다. 즉각적인 결과를 제공하며 이 결과를 손쉽게 조정할 수 있기 때문에 원하는 것을 정확하게 얻을 수 있습니다. 예를 들어 몇몇 원격 컴퓨터의 빈 디스크 공간 인벤토리가 필요한 경우를 가정해 보겠습니다. 이러한 컴퓨터의 이름은 C:\Computers.txt라는 텍스트 파일에 나열되어 있습니다. 이 파일은 데이터베이스처럼 복잡한 것이 아니라 한 줄에 하나의 컴퓨터가 기록된 일반 텍스트 파일입니다.
우선 로컬 컴퓨터에서 이 정보를 검색할 수 있는지 알아봅니다. 한 컴퓨터에서 이 정보를 검색할 수 있다면 여러 컴퓨터에서 작업을 수행하는 것도 그다지 어렵지 않을 것입니다. 다시 말하지만 여기에는 스크립팅 작업이 필요 없습니다. 필자는 모든 작업을 셸에서 Enter 키를 누르면 곧바로 결과가 표시되는 대화식으로 작업할 것입니다.
이러한 유형의 작업에 대해 약간의 힌트를 드리자면 원격 컴퓨터에서 관리 정보를 관리하는 경우 대개 WMI(Windows® Management Instrumentation)를 사용합니다. 이제 이 예의 목적상 WMI를 사용해야 한다는 점 이외에는 아무것도 모른다고 가정하겠습니다. 따라서 Live Search로 이동하여 "windows wmi free disk space"를 검색어로 입력합니다. 발췌문에 "Win32_LogicalDisk"라는 문구가 나열된 몇몇 검색 결과가 표시됩니다. 이것은 WMI 클래스로 보이므로 이들 검색 결과를 클릭하여 확인해 보는 대신 "Win32_LogicalDisk"를 새 검색어로 입력합니다. 그러면 MSDN® 사이트의 Win32_LogicalDisk 문서 페이지(msdn2.microsoft.com/aa394173.aspx)가 결과 맨 위에 표시됩니다. 이 페이지로 이동하여 살펴보면 이 클래스의 속성 중 하나가 우리가 찾는 FreeSpace임을 알 수 있습니다.

Cmdlet 찾기
다음 단계로는 WMI 클래스의 속성을 검색할 cmdlet을 찾아야 합니다. Windows PowerShell의 주목할 만한 특징 중 하나는 멋진 자체 검색 기능을 기본적으로 갖추고 있다는 점입니다. 즉, 셸을 통해 자체 기능을 찾아낼 수 있습니다. 따라서 WMI 사용에 대한 셸 도움말을 보기 위해 Help *wmi*를 입력합니다. 그 결과(그림 1) Gwmi 별칭과 이것이 가리키는 cmdlet인 Get-WMIObject가 표시됩니다. 기본적으로 같은 기능에 두 가지 방법으로 액세스할 수 있는데 어떤 방법을 사용해도 무방합니다. 두 가지 모두 같은 작업을 수행하며 Gwmi가 입력하기가 더 간단하므로 이것을 사용하겠습니다.
그림 1 WMI 사용에 대한 셸 도움말
그림 1 WMI 사용에 대한 셸 도움말
PS C:\> gwmi win32_logicaldisk
관리자에게는 Shift 키를 누르는 시간도 아깝다는 것을 알고 있는 듯이 Windows PowerShell은 대/소문자를 구분하지 않습니다.
그림 2에 나와 있는 것처럼 이 명령의 결과에는 모두 다섯 개의 로컬 드라이브와 각 드라이브의 FreeSpace 속성(바이트 단위)이 표시됩니다. 또한 이들 드라이브 중 각각에 대한 DriveType 속성도 나열되며 필자의 컴퓨터에서는 2, 3 및 5 값이 표시됩니다.
그림 2 모든 로컬 드라이브와 각 드라이브의 FreeSpace 속성
그림 2 모든 로컬 드라이브와 각 드라이브의 FreeSpace 속성

이달의 Cmdlet
Get-Content를 사용하여 텍스트 파일의 내용을 읽어본 적이 있을 것입니다. 이 도구는 파일의 각 줄을 [문자열] 개체로 취급하며 해당 개체를 다른 cmdlet이 다룰 수 있도록 파이프라인으로 전달합니다. 하지만 Get-Content에는 이외에도 여러 옵션이 있으므로 유연하게 사용할 수 있습니다. 예를 들어 readCount 매개 변수를 사용하여 한 번에 파이프라인에 전달되는 [문자열] 개체의 수를 지정할 수 있습니다. 또한 totalCount 매개 변수를 통해 파일에서 읽어 오는 총 줄 수를 제어할 수도 있습니다. 이 두 가지 매개 변수 모두 성능 이유로 인해 한 번에 전체 파일을 처리하지 않는 것이 좋은 매우 큰 파일을 다룰 때 유용합니다.
다른 편리한 매개 변수로는 encoding 매개 변수가 있는데, 이를 사용하면 유니코드, ASCII, UTF7, UTF8 등을 포함하여 다양한 파일 인코딩 형식을 올바르게 읽을 수 있습니다. 지원되는 인코딩 형식의 전체 목록을 보려면 help gc(gc는 Get-Content의 별칭)를 실행하십시오.

데이터 구체화
이 단계에서는 두 가지 문제가 있습니다. 첫 번째로 여기에서는 FreeSpace 이외의 다른 속성은 필요 없습니다. 두 번째로 광 드라이브, 이동식 드라이브 또는 네트워크 드라이브의 빈 공간은 알 필요가 없으며 로컬 하드 디스크만 알면 됩니다. DriveType 속성을 사용하면 이를 구분하는 데 도움이 될 수 있습니다. 다시 웹 브라우저로 돌아가서 각 DriveType 값이 나타내는 드라이브를 설명하는 표가 있는 문서를 확인합니다. 드라이브가 로컬 하드 디스크임을 나타내는 DriveType이 3인 드라이브만 필요합니다. 이전에 해보지 않은 작업이기 때문에 Gwmi 명령이 필터링을 수행할 수 있는지 확인해 보겠습니다. Help Gwmi –full을 실행하면 몇 가지 예를 포함하여 명령이 작동하는 방식에 대한 자세한 설명을 볼 수 있습니다. -filter와 같이 유용한 것으로 보이는 매개 변수를 찾아서 이를 실행해 봅니다.
gwmi win32_logicaldisk -filter "drivetype = 3"
멋지게 작동합니다! 이제 드라이브 목록에 로컬 고정 디스크만 포함됩니다. 이로써 두 번째 문제가 해결되었습니다. 이제 첫 번째 문제를 해결해야 합니다. 즉, 불필요한 모든 속성을 제거합니다.
Get-Command를 실행하여 모든 Windows PowerShell cmdlet을 나열하여 Select-Object를 찾습니다. 설명을 통해 이것이 "개체 또는 개체 집합의 지정된 속성을 선택"한다는 것을 알 수 있습니다. 따라서 다음과 같이 합니다.
gwmi win32_logicaldisk -filter "drivetype = 3" | select freespace
Gwmi의 결과를 Select(Select-Object의 별칭)로 전달하여 원하는 속성만 얻을 수 있습니다. 하지만 우리에게 표시되는 것은 숫자 목록일 뿐이므로 결과가 적절하지 않습니다. 즉, 목록의 빈 공간이 어떤 드라이브에 해당하는지는 알 수 없습니다. 따라서 다시 문서를 보고 DeviceID 속성에 드라이브 문자가 포함된다는 것을 확인합니다. 그리고 명령을 다음과 같이 수정하여 다시 시도합니다.
gwmi win32_logicaldisk -filter "drivetype = 3" | select deviceid,freespace
완벽합니다! 두 속성만 나열되기 때문에 셸에서는 정보를 표 형태로 보기 좋게 표시할 수 있습니다. Windows PowerShell에서 목록과 표를 사용하도록 선택하는 시점에 대해서는 다음 달에 설명하겠습니다.

계산
이렇게 빈 공간에 대한 정보를 검색했지만 이 정보는 바이트 단위이므로 메가바이트 또는 기가바이트만큼 유용하지 않습니다. FreeSpace 속성 자체가 아니라 FreeSpace 속성에서 계산된 값이 필요합니다. 이 경우 ForEach-Object cmdlet(또는 % 등과 같은 해당 여러 별칭 중 하나)이 도움이 될 수 있습니다. 이 cmdlet을 사용하면 특수 변수 $_를 사용하여 현재 논리 디스크를 참조할 수 있으며 각 디스크의 속성에 개별적으로 액세스하여 특정 계산을 수행할 수 있습니다. 이제 명령을 다음과 같이 수정할 수 있습니다.
gwmi win32_logicaldisk -filter "drivetype = 3" | % { $_.deviceid; $_.freespace/1GB }
여기에서는 Select를 제거하고 이 자리에 ForEach-Object에 대한 별칭(%)을 추가하기만 했습니다. cmdlet에는 가져온 각 Win32_LogicalDisk에 대해 수행할 작업을 지정해야 하므로 DeviceID 속성을 가져와서 FreeSpace 속성을 기가바이트로 나누도록 지시했습니다. Windows PowerShell에서는 KB, MB 및 GB를 인식하므로 이렇게 하면 출력 결과가 기가바이트로 표시됩니다.

여러 컴퓨터
지금까지는 한 컴퓨터를 대상으로 작업했으므로 이제 여러 시스템을 대상으로 작업할 차례입니다. 텍스트 파일의 내용을 가져오는 방법은 알고 있습니다. MS-DOS® 시절에 사용하던 방법과 동일하게 Type 명령을 사용하면 됩니다. Windows PowerShell에서도 이 명령이 Get-Content의 별칭이기 때문입니다.
Type c:\computers.txt
이 컴퓨터들을 하나씩 가져와서 각 컴퓨터에 대해 앞서 수행한 WMI 명령을 수행해야 하는 경우 "각 컴퓨터"라는 문구에서 알 수 있듯이 이 작업에는 ForEach-Object라는 cmdlet을 사용하면 됩니다. 따라서 구구절절한 설명은 제쳐두고 최종 명령만 보자면 다음과 같습니다.
type c:\computers.txt | % { $_;
gwmi –computername $_ win32_logicaldisk -filter "drivetype=3" | % { $_.deviceid; $_.freespace/1GB} }
알아보기가 힘든가요? cmdlet 이름 대신 별칭을 사용했기 때문에 읽기가 다소 어렵습니다. 하지만 하나씩 살펴보면 쉽게 이해할 수 있습니다.
  • 먼저 텍스트 파일의 내용을 입력합니다.
  • 이 내용을 ForEach-Object로 전달합니다.
  • ForEach-Object에서 $_ 변수를 사용하여 현재 항목, 즉 현재 컴퓨터 이름을 출력합니다.
  • 그런 다음 ForEach-Object에서 다른 ForEach-Object 호출이 있는 WMI 명령을 실행합니다.
이러한 별칭 이름을 cmdlet 이름으로 풀어서 쓰면 도움이 될 수 있습니다. 다음은 이와 동일한 명령인데, 여기서는 각 부분을 조금 더 쉽게 알아볼 수 있도록 cmdlet을 정확하게 입력하고 명령을 각각의 줄로 나누었습니다.
Get-Content C:\Computers.txt |
ForEach-Object {
 $_; Get-WMIObject –computername $_
Win32_LogicalDisk -filter "DriveType=3" |
 ForEach-Object {
 $_.DeviceID; $_.FreeSpace/1GB
 }
}
이 명령의 결과는 그림 3에 나와 있습니다. 그다지 보기 좋지는 않지만 원하는 정보가 모두 포함되어 있습니다.
그림 3 최종 결과
그림 3 최종 결과

스크립팅이 필요 없음
이 연습의 핵심은 스크립팅을 수행하지 않고도 Windows PowerShell을 사용할 수 있다는 것을 보여주기 위한 것입니다. 또한 이와 같은 몇 가지 예와 함께 Windows PowerShell 자체를 조금만 살펴보면 수행하고자 하는 작업을 수행하는 데 필요한 여러 정보를 얻을 수 있습니다.
더 중요한 것은 Windows PowerShell은 언제든지 사용할 수 있다는 점입니다. 지금 바로 배워보십시오. 진작 사용하지 않았음을 후회하게 될 것이며 스크립팅이라는 단어가 더 이상 어렵게 느껴지지 않을 것입니다.

Don Jones는 SAPIEN Technologies의 수석 스크립팅 전문가이자 ScriptingTraining.com의 강사입니다. 문의 사항이 있으면 ScriptingAnswers.com을 통해 연락하십시오.


 Hey, Scripting Guy!: Silverlight가 있으라!
Hey, Scripting Guy!
Silverlight가 있으라!
Microsoft Scripting Guys
이 기사의 코드 다운로드: HeyScriptingGuy2007_10.exe (156KB)

지금까지 인류 역사는 적대적 세력 간의 충돌로 점철되어왔습니다. 로마인과 이방인 무리 간의 충돌, Hatfield 가문과 McCoy 가문의 충돌 등이 대표적인 사례겠지요. 이뿐만이 아닙니다. 지금 이 순간에도 시스템 관리 스크립팅에 관한 칼럼에서는 시스템 관리 스크립팅과 실질적인 관련이 있는 이야기를 해야지, 적대적 세력 간의 역사적 투쟁 따위에 관해서 떠들면 안 된다고 믿는 분들과 Scripting Guys 사이의 충돌이... [또는 이를테면, 퍽...! —편집자]
컴퓨터 분야 역시 그와 같은 적대적 세력 간의 충돌로부터 자유롭지 않습니다. 특히, 개발자와 시스템 관리자 간의 충돌이 떠오르는군요. 상황을 주시하던 Karl Marx가 말했듯이, "이 인간이 죽었거나, 아니면 내 시계가 죽었거나"의 문제죠.
아, 죄송합니다. 저 말을 한 사람은 Groucho Marx로군요. Karl Marx는 이렇게 말했군요. "예술은 언제 어느 곳에서나 비밀의 고백이며, 그와 동시에 그 시간의 영원한 운동이다." 사실, 이게 대체 무슨 소린지 저희는 전혀 모르겠습니다. 어쨌든 Groucho Marx가, 비록 그의 경구는 개발자와 시스템 관리자 사이의 충돌과는 그다지 관련이 없지만, Karl Marx보다는 확실히 재미있었습니다.
그럼에도 불구하고, Scripting Guys가 매일 아침 업무를 시작하기 전에 "시스템 관리자는 개발자가 아니다"라는 충성 서약을 암송하게 만든 것은 분명히 Karl Marx였습니다. 그리고 이는 전혀 틀린 말이 아닙니다. 시스템 관리자는 개발자와 다르다는 사실 말입니다. 개발자는 컴퓨터 프로그램을 짜는 사람들인 반면, 시스템 관리자는....음... 사실 Microsoft에 있는 사람들 중 시스템 관리자가 무슨 일을 하는지 정확히 아는 사람이 있는지 잘 모르겠습니다. 하지만 그게 무슨 일이든 간에, 적어도 컴퓨터 프로그램을 짜는 일이 아닌 것만은 분명합니다.
물론 Karl Marx는 "The Times, They Are A-Changing"이라는 노래도 만들었습니다. (최소한 우리에게는 그렇게 말했습니다.)
TechNet Script Center(microsoft.com/technet/scriptcenter)가 어느 정도 일조한 덕분에 시스템 관리자들이 점차 VBScript를 알게 되었고 스스로 유틸리티를 만들어 쓰기 시작했습니다. 비록 전형적인 컴퓨터 프로그램처럼 완전하고 포괄적인 것은 아니지만 그래도 유용한 관리 작업을 수행하는 유틸리티를 만들기 시작한 것입니다. 그리고 그런 유틸리티를 만들 때 시스템 관리자들은 개발자들이 사용하는 것과 매우 유사한 기술과 기법을 동원해야 했습니다.
그리고 그것은 시작에 불과했습니다. Windows PowerShell™ (microsoft.com/technet/scriptcenter/hubs/msh.mspx)의 등장은 Microsoft® .NET Framework가 시스템 관리자와 스크립트에 있어 더 이상 출입금지 영역이 아니라는 것을 뜻합니다. Windows Vista®는 가젯을 세상에 소개함으로써(microsoft.com/technet/scriptcenter/topics/vista/gadgets-pt1.mspx) 시스템 관리자를, 아니 최소한 스크립트를 작성하는 시스템 관리자를 개발자와 동등한 반열에 올려놓았습니다. 그리고 마침내—자, 드럼 사운드 효과 좀 부탁해요. 두두둥!—Microsoft Silverlight이 등장했습니다. "브라우저와 플랫폼을 가리지 않고 차세대 .NET Framework 기반 미디어 환경과 웹을 위한 풍부한 대화형 응용 프로그램을 제공하는 플러그인" 말입니다.
굉장하지 않습니까? 그런데 그게 우리 같은 시스템 관리 스크립트 작성자와 무슨 관계가 있냐고요? 솔직히 저희도 잘 모릅니다. 그러나 Silverlight가 매우 멋진 사용자 인터페이스와 멀티미디어를 아주 쉽게 만들도록 해주는 것은 사실입니다. 마케팅 자료에서는 예외 없이 Silverlight을 웹 응용 프로그램 제작 도구로 소개하지만 별로 알려지지 않은 사실 하나를 밝히자면, Silverlight가 HTML 응용 프로그램, 또는 스크립트 작성자들이 아주 좋아하는 매체인 HTA(microsoft.com/technet/scriptcenter/hubs/htas.mspx)에서도 똑같이 효과적으로 작동하는 것 같습니다. 그러니 잠시 살펴 볼 만한 가치는 있겠습니다.

본론을 시작하기 전에...
먼저 여기서 Silverlight의 수많은 기능과 용도를 자세히 다루지는 않을 것이라는 점을 말씀 드려야겠습니다. 이 글의 주된 목적은 Silverlight의 기술을 어렵지 않게 사용할 정도의 코드 조각을 소개하는 것입니다. Silverlight를 설치하려면(참, 무료입니다.) Silverlight 홈페이지microsoft.com/silverlight를 이용하시기 바랍니다. 또한 silverlight.net/GetStarted에서는 SDK, 샘플 프로젝트를 비롯한 여러 가지 유용한 자료를 찾아보실 수 있습니다.
여기서는 이미 Silverlight를 설치한 것으로 간주하겠습니다. 그리고 TechNet Magazine 웹사이트의 코드 다운로드 섹션(technetmagazine.com/code07.aspx)에서 그림 1에 제시된 파일들을 다운로드했다는 전제하에 설명합니다.
Figure 1 Silverlight 프로젝트 구성 요소 (Close Figure 1)

파일 | 설명
CreateSilverlight.js | 사용자 인터페이스와 그래픽 개체의 구성에 사용되는 XAML 파일 등을 비롯하여, 초기 Silverlight 시작 설정을 지정하는 데 사용되는 JScript 스크립트(Silverlight 초기 릴리스에서는 JScript 스크립트만 지원)입니다.
SampleProject.js | JScript 함수를 넣을 수 있는 빈 파일입니다.
Silverlight.js | Silverlight 컨트롤을 초기화할 때 사용되는 파일입니다.
SampleProject.html | 모든 효과가 이루어지는 곳입니다. SampleProject.html은 세 .js 파일에서 읽을 코드가 들어 있는 단순한 HTML 파일입니다. 또한 Silverlight 컨트롤을 인스턴스화하는 코드도 들어 있습니다.
SampleProject.xaml | 이 파일은 어디에 사용될까요? 알고 싶다면 이 칼럼을 다시 읽어 보십시오.
SampleProject.js는 꼭 필요하지 않습니다. 최소한 이번 달 칼럼대로 따라서 할 필요는 없는 거죠. Silverlight에서는 프로젝트의 개체와 이벤트에 스크립트를 첨부할 수 있는데, 이 스크립트는 HTML 파일에 하드코딩해서 넣거나 여기서 설명하듯이 외부의 "포함" 파일에서 읽어올 수 있습니다. 그리고 SampleProject.html을 HTA로 바꾸겠습니다. 그냥 이름만 SampleProject.hta로 바꾸면 됩니다. 너무 쉽지 않습니까?
이 파일들을 폴더 하나에 모두 저장합니다. 자, 이제 재미 있는 시간을 보낼 준비는 다 된 것 같군요.

XAML 파일
짐작하신 대로 이번 달 Hey, Scripting Guy!에서 흥미로운 부분은 모두 XAML 파일과 관련이 있습니다. (우연히도, XAML은 "zamel"과 발음이 비슷합니다. camel과 운율이 맞죠. 아니면 mammal이나 enamel하고도 비슷하네요.) XAML은 Extensible Application Markup Language의 약어입니다. 무엇보다 XAML은 XML 유사 언어를 이용하여 사용자 인터페이스를 제작할 수 있다는 데 의의가 있습니다. 특히 시스템 관리자의 경우에, 이를 이용하면 과연 사용자 인터페이스를 만드는 일이 쉬워질까요? 지금부터 이에 대해 알아보도록 하겠습니다.
이 과제에 대해 조사하려면 우선 메모장을 실행해서 SampleProject.xaml 파일을 열어야 합니다. 기존 코드가 있다면 아래의 코드로 바꿔 넣습니다.
<Canvas
 xmlns="http://schemas.microsoft.com/
    client/2007"
 xmlns:x="http://schemas.microsoft.com/
    winfx/2006/xaml">
</Canvas>
참고로, SampleProject.hta는 이미 SampleProject.xaml에서 정보를 가져오도록 구성되어 있습니다. 다른 XAML 파일을 사용하려면 CreateSilverlight.js 파일을 편집해야 합니다.
코드를 붙여 넣었으면 파일을 저장하고 SampleProject.hta를 두 번 클릭합니다. 무엇이 나타날까요? 그렇습니다. 터무니없이 큰 회색 상자가 나타나는군요.
그렇다고 벌써 실망하지는 마십시오. 지극히 정상적인 현상이니까요.
아직 아무 것도 한 게 없으니 아무 것도 안 나타나는 게 당연합니다. 그저 XAML 파일에 캔버스를 하나 펼쳐 놓았을 뿐이죠 하지만 이는 중요한 절차 중 하나입니다. 어쨌든 유화를 그리려면 캔버스부터 마련해야 하지 않겠습니까? Silverlight에서도 마찬가지입니다. 프로젝트에 요소를 추가하려면 먼저 "캔버스"부터 준비해야 합니다. 지금 그 준비를 한 것입니다.
그런데 우리는 왜 가로 300픽셀에 세로 300픽셀인 회색 상자를 준비한 것일까요? 대답은 간단합니다. CreateSilverlight.js에 기본 설정으로 구성된 규격이기 때문입니다. 이 기본값이 마음에 들지 않는다면 CreateSilverlight.js를 열어서 설정을 만져주면 됩니다. 가로 800픽셀에 세로 300픽셀인 흰색 캔버스를 원합니까? (이제부터 사용하려는 예에는 아마 그 편이 더 나을 것입니다.) 그러면 CreateSilverlight.js에 다음 세 행을 추가해야 합니다.
width:'800', // Width of rectangular region of
             // control in pixels.
height:'300', // Height of rectangular region
              // of control in pixels.
background:'white', // Background color of
                    // control.
참고로, 원래의 .js 파일에는 배경이 #D6D6D6로 설정되어 있습니다. 방금 이것을 흰색으로 바꾸었습니다. XAML 파일에서는 RGB 값을 이용하거나 색 이름을 이용해서 색을 나타낼 수 있습니다. 전체 색 값 및 색 이름 목록은 msdn2.microsoft.com/bb188314.aspx를 참조하십시오. Scripting Guys는 "저희 집이요? FFFFFACD 바탕에 FFCD5C5C 테두리로 되어있지요"와 같은 식으로 RGB 값으로 색을 지칭하기를 좋아하지만, 여기서는 색 이름을 사용하기로 했습니다.
보너스로 팁을 하나 알려 드리자면, 캔버스 배경에 단색만 사용할 수 있는 것은 아닙니다. 그림 2의 코드를 여러분의 XAML 파일에 붙여 넣고 그 결과를 한번 살펴보십시오.
Figure 2 예쁜 색 (Close Figure 2)
<Canvas
 xmlns="http://schemas.microsoft.com/client/2007"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Width="800"
 Height="300">

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

</Canvas>
해보셨나요? 멋있지 않습니까?
물론, 텅 빈 캔버스가 전부는 아닙니다. 그러면 계속해서 그 캔버스에 개체를 추가해보겠습니다. Silverlight에서는 타원형, 사각형, 선, 다각형 등 온갖 개체를 모두 추가할 수 있지만 여기서는 구식 텍스트 블록을 추가해보겠습니다. 어떻게 하냐고요? XAML 파일의 <Canvas> 태그와 </Canvas> 태그 사이에 다음 태그를 넣어주면 됩니다.
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">
</TextBlock>
보다시피, 이 XAML 작업은 그다지 까다롭지 않습니다. <TextBlock> 태그를 먼저 넣고 그 뒤에 다양한 TextBlock 매개 변수(Name, FontSize 등)를 넣습니다. 그리고 </TextBlock> 태그를 넣어서 TextBlock이 끝났다는 것을 표시하기만 하면 됩니다. 이게 뭐가 근사하냐고요? 어떤 개체든 이와 똑같은 방법으로 XAML 파일에 추가할 수 있다는 겁니다. 가로 300픽셀에 세로 100픽셀짜리 사각형을 추가하고 싶다면 다음 코드만 삽입하면 됩니다.
<Rectangle
 Height="300"
 Width="100"
 Fill="Blue">
</Rectangle>
그런데 사각형과 같은 어떤 도형을 캔버스에 추가할 때는 채우기 색 및/또는 스트로크 색을 지정해야 합니다. 그렇게 하지 않으면 Silverlight의 캔버스에 투명한 사각형이 추가됩니다. 그 사각형은 실제로 캔버스에 있지만 슈퍼맨 같은 x-레이 투시 능력이 없다면 볼 수 없겠죠?
채우기 색과 스트로크 색이란 일부 Silverlight 개체에 색을 칠하는 방법이라고 할 수 있습니다. 다른 개체의 경우에는 보너스 팁에서 소개한(그러나 설명하지는 않은) LinearGradientBrush와 같은 브러시를 사용해야 합니다. 개체를 단색으로 칠하고 싶다면 그에 딱 맞는 이름을 가진 SolidColorBrush를 사용하면 됩니다. 예를 들어 그림 3의 XAML 태그를 살펴보십시오. 이 태그는 텍스트를 빨간색으로 '칠'해 줍니다. 기술적으로는 TextBlock의 Foreground 속성에 색을 설정하는 것입니다.
Figure 3 텍스트 칠하기 (Close Figure 3)
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">

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

</TextBlock>
더 근사한 효과를 원한다면 텍스트에 그림을 채워 주는 ImageBrush 속성을 사용해보십시오.
<TextBlock.Foreground>
 <ImageBrush Name="test_brush" ImageSource="Sunset.jpg"/>
</TextBlock.Foreground>
그리고 팁을 하나 더 소개하자면, ImageBrush 속성을 사용하는 경우 FontSize 값을 높이는 것이 좋습니다. 텍스트가 클수록 효과가 더 잘 나타나기 때문입니다.
직접 결과를 확인하십시오. 꽤 인상적일 것입니다.

잠깐! 이 정도는 아무 것도 아닙니다.
이제 터놓고 말씀 드려야겠군요. 비장의 카드는 아직 꺼내지도 않았습니다. Silverlight에 텍스트를 표시하는 것도 좋은 기능이고, 사각형이나 타원형, 다각형을 그리는 것은 그보다도 더 근사한 기능이지만, 애니메이션 추가 기능에 비하면 아무 것도 아닙니다.
다시 한번 말하지만, 이 글에서는 Silverlight 애니메이션을 만드는 몇 가지 방법을 간단히 소개하기만 합니다. 더 이상 다룰 지면이 없답니다. (우리를 탓하지는 마십시오. TechNet Magazine을 Hey, Scripting Guy! Magazine으로 바꿔야 한다고 계속 제안하고 있는데도 그 메일이 아직 전달되지 않은 것 같습니다.)
자, 이제 각설하고, 텍스트가 서서히 그렇지만 분명하게 나타나는 근사한 페이드인 효과를 보여 드리겠습니다. 그림 4의 코드를 XAML 파일의 <TextBlock> 태그와 </TextBlock> 태그 사이에 추가하십시오.
Figure 4 TextBlock 트릭 (Close Figure 4)
<TextBlock.Triggers>
 <EventTrigger RoutedEvent=
     "TextBlock.Loaded">
 <BeginStoryboard>
 <Storyboard>
 <DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
 </Storyboard>
 </BeginStoryboard>
 </EventTrigger>
</TextBlock.Triggers>
상당히 잡다해 보인다는 점은 인정하겠습니다. 하지만 다행히 그 대부분은 상투적인 반복 태그에 불과합니다. 애니메이션을 그냥 XAML 파일에 추가하기만 해서는 안 됩니다. 애니메이션을 언제 재생할 것인지를 지정해야 합니다. 이를 위해서는 TextBlock에 일련의 트리거를 지정해야 합니다. 여기서는 언제든 TextBlock이 로드되면 애니메이션을 시작하는 트리거를 만들어보겠습니다.
<EventTrigger RoutedEvent="TextBlock.Loaded">
Silverlight에서 애니메이션은 반드시 스토리보드(영화 쪽에서 가져온 용어임)에 따라 구성되어야 합니다. 그래서 <BeginStoryboard> 태그와 <Storyboard> 태그를 사용하는 것입니다.
텍스트에 페이드인 효과를 적용하려면 Opacity 속성을 수정해야 합니다. 이 값을 0.0(투명)에서 1.0(단색)으로 점차 높여갑니다. Opacity는 Double 속성(배정밀도 숫자 값 기반 속성)이므로 DoubleAnimation 애니메이션을 사용합니다. 그러면 DoubleAnimation 애니메이션은 어떤 방식으로 사용할까요? 먼저 애니메이션 효과를 적용할 개체를 지정(이 경우에는 Test, 즉 TextBlock에 지정했던 이름)하고 대상 속성(Opacity)을 지정한 다음 애니메이션 범위(불투명도 0.0 ~ 1.0)와 애니메이션 지속 시간(5초)을 지정합니다. 즉, 다음과 같습니다.
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
참고로, 5초를 나타내려면 0:0:5(시, 분, 초) 형식의 구문을 사용해야 합니다. 그냥 5를 값으로 사용하면 그 자체로는 오류가 발생하지 않지만 애니메이션이 5일간 실행됩니다.
해보셨습니까? 다음으로, DoubleAnimation 태그 안의 AutoReverse 속성을 True로 설정해 보십시오.
AutoReverse="True"
서서히 나타났다가(페이드인) 서서히 사라지는(페이드아웃) 애니메이션 효과가 나타납니다.
RepeatBehavior 속성을 Forever로 설정하면 페이드인 효과와 페이드아웃 효과가 계속 반복됩니다. 예, 영원히 말입니다.
RepeatBehavior="Forever"
과하다고요? 그렇다면 RepeatBehavior를 3x와 같이 설정하십시오. 이 경우 애니메이션이 3번 반복된 후 사라집니다.
RepeatBehavior="3x"
꽤 근사하죠? 적어도 우리끼리는 그렇게 말할 수 있겠군요. 하지만 텍스트가 서서히 나타났다 서서히 사라지는 것이 별로 마음에 들지 않는다면? 그보다는 텍스트 색상이 서서히 바뀌는 편이 더 마음에 든다면 어떻게 해야 할까요? 이 경우 ColorAnimation 애니메이션을 사용해야 합니다.
<ColorAnimation
 Storyboard.TargetName="test_brush"
 Storyboard.TargetProperty="Color"
 From="Red" To="Blue" Duration="0:0:5" />
참고로, 이 경우에는 빨간색 텍스트로 시작해야 합니다. 텍스트를 빨간색으로 칠하는 방법은 이미 설명했습니다.
재미있지 않습니까? 그런데 약간 실망하는 기색이로군요. 아, 그렇다면 그건... ColorAnimation 자체는 훌륭하지만 진짜로 원하는 것은 화면에 무엇인가 날아다니는 효과라는 의미겠군요. 문제없습니다. Silverlight는 화면에 무엇인가 날아다니도록 하는 효과 정도는 당연히 구현할 수 있는 소프트웨어입니다. 다음과 같이 해보십시오.
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="(Canvas.Left)"
 To="150"
 Duration="0:0:5" />
보다시피, TextBlock이 그 출발점에서 캔버스 왼쪽 가장자리(Canvas.Left)로부터 150픽셀 떨어진 지점까지 천천히 움직이도록 했습니다. TextBlock을 위아래로 움직이게 하려면 Canvas.Top 속성을 사용하면 됩니다.
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="(Canvas.Top)"
 To="150"
 Duration="0:0:5" />
그러면 이 애니메이션 효과들을 결합하여 TextBlock을 좌우로, 그리고 위아래로 움직일 수는 없을까요? 자, 직접 해보십시오. 힌트는 드리겠습니다. 두 애니메이션을 XAML 파일에 연이어 붙여 넣고 어떻게 되는지 보십시오.
물론 처음부터 여러분이 이 정도 애니메이션쯤은 충분히 결합할 수 있으리라는 것을 알고 있었습니다. 사실 Silverlight 프로젝트 하나에 수많은 애니메이션을 추가할 수 있습니다. 다만 약간 까다로울 뿐이죠. 애니메이션 하나가 끝난 후에 다음 애니메이션이 시작되도록 하려면 추가 태그가 필요합니다. 그러나 XML과 유사한 태그를 몇 개 입력하는 것만으로도 꽤 근사한 애니메이션 효과를 구현할 수 있다는 것은 확인하셨을 것입니다.

아쉽게도 오늘의 쇼는 여기까지입니다.
예, 압니다. 우리도 아쉽습니다. 더구나 이제 막 진짜 유용한 부분으로 들어가는데 말이지요. 하지만 이것으로 영영 끝은 아닙니다. Silverlight를 좀 더 자세히 알고 싶다면 scripter@microsoft.com으로 연락 주시기 바랍니다. 관심을 보이는 분들이 많다면 이후에 다른 칼럼에서 고려해볼 수도 있을 것입니다. 그리고 TechNet Script Center(microsoft.com/technet/scriptcenter/resources/tnmag/archive.mspx)도 잊지 말고 들러 주시기 바랍니다. 전체 XAML 예(eXAML?)에 대한 링크를 게시해 두겠습니다. 그때까지는 Karl Marx와 Fredrich Engels가 브뤼셀 공산주의자통신위원회(Communist Correspondence Committee) 명의로 G. A. Kottgen에게 보낸 선언적 서한의 말미에서 말했듯이, "안녕히 가시고, 댁까지 안전 운전하세요."

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


 Security Watch: BitLocker와 신뢰의 복잡성
Security Watch
BitLocker와 신뢰의 복잡성
Justin Troutman

필자는 지금까지 기사에서 Windows Vista라는 두 단어를 언급한 적이 없습니다. 때문에 이 기사를 시작하는 지금 마치 백지수표를 들고 장난감 가게에 들어서는 5살 꼬마처럼 마음이 들뜹니다. 설명할 기능이나 다루고 싶은 부분이 너무 많고 이야기도 수많은 방향으로 풀어갈 수 있을 것 같습니다.
얼마 전 필자는 Bruce Schneier라는 보안 전문가의 블로그를 읽다가 당시 모르고 있었던 BitLocker™에 대해 처음으로 알게 되었습니다. 그리고 Windows Vista®에서 암호화 기능을 제공하기 위한 구성 요소라는 것을 곧바로 알 수 있었습니다. "Windows Vista가 암호화까지? 굉장한걸! 하지만 아무리 뛰어난 기능을 제공하더라도 어딘가에 백도어가 있을거야"라는 의심을 가지게 되었습니다.
지금까지는 그 진위 여부에 관계없이 사용자가 Windows®에서 기본 제공되는 보안 기능을 신뢰하지 않는 이유에 대해서 의견이 분분했습니다. 그러나 그것이 이 칼럼을 쓰게 된 동기는 아닙니다. 오히려 BitLocker가 유용할 수도 있는 타당한 이유가 무엇인지를 실증적으로 보여 주고 싶었습니다. 또한 암호화 소프트웨어와 하드웨어에 생명을 불어넣을 수 있는 이론에 대해서도 간단히 소개하고자 합니다.
그렇다고 BitLocker가 모든 보안 문제를 해결할 수 있는 만능 해결사라는 의미는 아닙니다. BitLocker는 말하자면 전체 보안 퍼즐을 이루는 한 조각이라고 할 수 있습니다. BitLocker는 특정 위협 모델에서 복원 기능을 제공하는 것을 주 목적으로 합니다.
BitLocker는 특히 분실 또는 도난된 랩톱에서 위력을 발휘하도록 개발되었습니다. 이동이 잦은 근로자는 갖가지 기밀 정보를 휴대한 채로 기차, 항공기, 식당, 호텔, 집, 지사 등 곳곳을 누비게 됩니다. 이러한 정보는 보통 신뢰할만한 보안 기능이 부족한 랩톱이나 기타 모바일 장치에 저장되어 있기 때문에 데이터가 매우 취약한 환경에 노출되기 쉽습니다. 사용자가 랩톱을 분실한다면 이러한 데이터는 어떻게 될까요?
부주의한 것은 인간의 본성이므로 어찌할 도리가 없지만, 다행히 그에 따른 문제는 어느 정도 방지할 수 있습니다. 회사에 있어서 기밀 데이터 유출에 따른 손실에 비하면 랩톱을 교체하는 비용은 아무것도 아닙니다. BitLocker는 이러한 점에 착안한 소프트웨어입니다.

전문가의 참여
여기서는 흥미로운 시각에서 BitLocker를 조명해 보도록 하겠습니다. 아직 본론을 시작하지도 않았지만 의구심을 가지는 독자도 있을 겁니다. BitLocker를 사용해 본 적도 없는 사람이 어떻게 BitLocker에 대해 의견을 가질 수 있으며, 더군다나 이 주제에 대해 기사까지 쓸 수 있느냐는 것이죠. 의구심을 접고 조금만 참아 주시기 바랍니다. 이 기사에서 정말로 다루고자 하는 것은 BitLocker에 대한 내용이 아니라 높은 수준의 암호화와 성공적인 솔루션을 개발하는 데 중요한 디자인 이론입니다.
이러한 생각은 Bruce Schneier의 블로그를 읽은 때부터 시작되었습니다. 보고 싶은 신작 영화가 있다고 가정해 보십시오. 예고편과 캐스팅된 주연 배우를 보고 영화가 어떨지 대충 짐작하게 됩니다. 주연 배우가 영화의 완성도를 보장해 주지는 않지만 영화에서 큰 비중을 차지하고 기대를 가지게 하는 것은 사실입니다. Chris Rock이나 Ben Stiller가 출연하는 영화, 아니면 Kate Winslet이나 Johnny Depp이 주연한 영화라는 사실만으로도 기대를 가지기에 충분하죠.
마찬가지로 국제적인 명성을 얻고 있는 보안 전문가가 개인 블로그에서 BitLocker에 대해 언급했다는 사실만으로도 필자는 몇 가지 기대를 가지게 되었습니다. 먼저 이 신기술이 전문가도 주목할 만큼 뛰어나거나, 공개적으로 언급해야 할 만큼 형편없거나, 두 가지 중 하나라는 사실을 알 수 있었습니다. 놀랍게도 Bruce Schneier의 최종 평가는 긍정적이었습니다.
그의 글에서 "경찰을 위한 백도어가 없다"는 문장이 제일 먼저 눈에 들어왔습니다. 이 짧은 문장이 많은 것을 말해 줍니다. 매우 자신 있는 어조였고 Microsoft® System Integrity 팀 블로그에 대한 링크까지 포함되어 있었습니다. 이 링크를 통해 Microsoft의 보안 전문 개발자인 Niels Ferguson의 게시물을 발견했는데, Microsoft에서 법적 용도로 BitLocker에 백도어를 일부러 포함했다는 소문을 강하게 부정하는 내용이었습니다. 이 글에서 Ferguson은 백도어를 받아들일 수 없으며 백도어를 지원하는 프로젝트에는 참여한 적이 없다고 솔직하게 밝히고 있습니다. 또한 Microsoft가 법 때문에 백도어를 추가해야 했다면 백도어가 포함된 사실을 공개하거나 BitLocker 기능을 완전히 빼버렸을 것이라고 설명했습니다.
이 게시물에 적힌 Niels Ferguson이라는 이름 만으로도 Schneier가 얼마나 자신감을 가지고 글을 적었는지 알 수 있었고, 그러한 자신감은 필자에게로 다시 이어졌습니다. Ferguson은 확실한 전문가일 뿐 아니라 그의 말을 무조건 믿어도 좋을 만큼 화려한 경력을 가지고 있기 때문입니다. Bruce Schneier와 Niels Ferguson은 Practical Cryptography(암호를 간단하고 정확하고 안전하게 적용하는 방법에 대한 입문서)를 공동으로 집필하고 Twofish라는 블록 암호화 기술을 함께 설계했습니다. Twofish는 AES(Advanced Encryption Standard) 선정 과정에서 최종 선정됨으로써 암호화 기술로서 명성을 얻은 128비트 Feistel 네트워크입니다.
물론 베테랑 암호 전문가가 프로젝트에 참여한다고 해서 최종 제품의 보안이 보장되는 것은 아닙니다. 암호화 기술의 대가라 해도 한두 가지 문제를 놓칠 수 있으니까요. 장기적으로 BitLocker가 어떻게 변화할지 모르지만 믿을 수 있는 디자인 전략을 바탕으로 개발된 것만은 확실합니다.
프로젝트에서 발생할 수 있는 문제로, 암호화에 대해서는 전혀 개의치 않고 제품 개발에만 열심히 몰두하는 개발자와 제품 출시에만 관심이 있는 사람들이 생겨날 수 있습니다. 그 의도에 관계없이 이러한 사람들은 모두 개발 과정에서부터 보안에 실패하는 결과를 초래합니다. 그러나 BitLocker의 경우 이러한 문제는 없었던 듯합니다. 적어도 유력한 보안 전문가가 한 명은 참여했고, 그를 지원하는 리소스도 충분했으니까요.

신뢰에 관해
얼마 전 필자는 PGP 암호화를 개발한 Phil Zimmerman으로부터 몇 가지 노하우를 전수 받았습니다. "개발자를 위한 보안 강령"이라는 책이 출판된다면 그의 조언이 가장 먼저 실려야 할 것입니다. 구체적으로 BitLocker를 지적해 말한 것은 아니지만 이 디자인 이론은 대부분의 암호화 솔루션에 적용될 수 있습니다. 아마 여러분도 이러한 사실은 쉽게 알 수 있을 것입니다. 하지만 오늘날 보안의 중요성을 감안한다면 한번 더 확실히 짚어볼 필요가 있습니다.
암호화 인프라를 설계할 때 개발자는 단순성, 정확성 및 안전성을 확보해야 합니다. 실수를 완벽하게 피할 수는 없다 하더라도 당연히 발생하는 것으로 받아들이거나 무시해서는 안 됩니다. 개발자는 다소 지나치다 싶을 만큼 완벽주의자가 되어야 합니다. "한 번 실수할 때마다 누군가의 목숨이 끊기는 것처럼 설계하라"는 Zimmerman의 말처럼 말입니다. 과장이 너무 심하다고요? 2005 Annual Computer Security Applications Conference에서 NSA의 암호 전문가 Brian Snow(이후 은퇴)는 "보안 장치는 반드시 제대로 작동해야 하고 그에 대한 보장이 필요합니다. 고객을 상대로 베타 테스트를 할 수는 없는 노릇이니까요. 제품에서 오류가 발생하면 누군가가 죽을 수도 있습니다"라고 말했습니다. 따라서 실수는 금전적인 비용 이상의 대가를 초래할 수 있다는 점을 명심하십시오.
사용자는 안전을 보장 받을 자격이 있습니다. 그리고 사용자의 신뢰를 얻고 유지하는 것은 매우 중요합니다. Zimmerman은 "사용자의 신뢰를 얻어야 합니다. 그리고 신뢰를 얻은 후에는 그 부담을 끝까지 짊어지고 가야 합니다"라는 말로 이를 명확히 하고 있습니다. 사용자의 신뢰를 얻고 유지함으로써 회사는 보안이 철저하다는 명성과 믿음을 얻을 수 있습니다. 이러한 명성은 한번 잃으면 회복하기가 어렵습니다.
Microsoft도 BitLocker(또는 다른 제품)를 설계할 때 이러한 점을 염두에 두었다고 생각합니다. 이와 관련해 Microsoft가 실제로 이 문제에 올바르게 접근하여 사용자들이 진지하게 고려해 볼만한 암호화 기술을 만들어냈다는 믿음의 근거를 밝혀 보겠습니다.

가난한 사람의 인증과 Elephant 구성 요소
BitLocker의 핵심 기능은 Windows Vista(특히 Enterprise 및 Ultimate 버전)에서 모든 시스템 볼륨 데이터를 암호화하는 것입니다. 용도가 매우 단순한 것 같지만 제약 조건을 고려해 보십시오. BitLocker는 섹터 수준에서 데이터를 암호화하며 암호 텍스트가 일반 텍스트의 길이를 초과할 수 없기 때문에 임시 데이터(인증을 위해 한 번만 사용되는 번호 또는 문자열), IV(Initialization Vector), MAC(메시지 인증 코드) 등에 사용할 여유가 없습니다. 이러한 까다로운 제약 조건과 그에 따른 상황을 예상하기는 했지만 메시지 인증 문제가 어떤 방식으로든 해결되리라는 것도 알고 있었습니다.
BitLocker는 가난한 사람의 인증이라고 불리는 방식을 사용합니다. 이 절충안은 생각보다 보수적이지 않으며, 암호 텍스트를 조작하더라도 의미 있는 일반 텍스트를 얻을 수는 없다는 가정하에 작동합니다. 즉, 암호 텍스트가 조작되면 다른 기능을 수행할 수 있도록 허용하는 것이 아니라 시스템이 중단되어야 합니다.
BitLocker를 개발한 Microsoft 팀은 완전히 새로운 차단 암호를 개발하려면 분석에 시간이 너무 오래 걸리고, 기존 디자인의 경우에도 제대로 분석되지 않았거나 효율성이 떨어진다는 사실을 잘 알고 있었습니다. 때문에 암호화에 CBC(Cipher Block Chaining) 모드의 AES를 사용하기로 결정했습니다. 앞으로 이 방식은 AES-CBC라고 지칭하겠습니다. 이 모드는 특정 일반 텍스트 공격 모델(단축 IND-CPA)하에서 파악되지 않지만 무결성이 보장되지는 않습니다. 그리고 MAC를 사용할 수 없으며 CBC는 기밀성을 위한 모드이므로 무결성이 전혀 보장되지 않습니다. 여기서 바로 Elephant가 그 역할을 수행합니다.
새로운 Elephant 구성 요소는 평범한 AES-CBC보다 가난한 사람의 인증을 효과적으로 렌더링하는 두 가지 디퓨저를 제공합니다. 그러나 엄격한 표준 준수 정책을 따라야 하는 사용자의 경우 Elephant를 사용하지 않고 AES-CBC를 실행할 수도 있습니다. 항상 이상적이라고는 할 수 없지만 가난한 사람의 인증은 여기서 설명하는 상황에서 가장 적합한 솔루션이며 Elephant는 상황을 최대한 바람직하게 만드는 데 초점을 맞추고 있습니다. 그렇다면 이 구성 요소는 어떻게 작동하는 것일까요?
그림 1에서는 이해를 돕기 위해 작동의 흐름을 보여 줍니다. 암호화가 실행되면 XOR을 통해 일반 텍스트가 섹터 키와 결합됩니다. 이 텍스트는 키가 적용되지 않은 두 가지 디퓨저를 통과합니다. 이 두 디퓨저에서는 AES-CBC를 사용하여 텍스트를 암호화합니다. 섹터 키와 AES-CBC에는 키 자료가 필요하기 때문에 독립적으로 키가 적용됩니다. 이러한 방식은 AES-CBC 및 Elephant의 보안 구성을 AES-CBC의 보안 구성으로 축소할 수 있도록 보증의 표준화를 단순화합니다. Elephant는 새로운 기본 기술이며, 이러한 신기술은 보통 엄격히 분석되기 전까지는 꺼려지기 마련입니다. 그러나 BitLocker는 Elephant를 사용하는 AES-CBC는 AES-CBC만 사용할 때보다 공격하기 어렵다는 사실을 잘 보여 주므로 장단점이 있습니다.
그림 1 Elephant를 사용한 가난한 사람의 인증
그림 1 Elephant를 사용한 가난한 사람의 인증
섹터 키와 AES-CBC 구성 요소는 256비트의 키 자료를 받으므로 전체 키 길이는 512비트가 됩니다. 하지만 기본적으로 이 두 구성 요소는 각각 128비트의 키 자료밖에 사용하지 않으므로 키 자료 중 일부가 사용되지 않습니다. 이렇게 구현하는 이유는 키 길이가 달라질 때마다 키 관리 인프라를 변경하는 것보다 불필요한 비트를 버리는 것이 더 간단하기 때문입니다.
블록 길이는 512 ~ 8192바이트 사이의 2의 배수가 될 수 있습니다. 암호 텍스트를 변경하면 섹터의 모든 일반 텍스트가 무작위로 수정되도록 하기 위해 차단 암호는 다양한 블록 크기로 동작하도록 설계되었습니다. 게다가 Liskov, Rivest 및 Wagner가 설명한 것처럼 섹터별로 조금씩 다른 알고리즘을 통해 조작 가능한 차단 암호처럼 작동한다면 악의적인 사용자가 섹터의 암호 텍스트에서 다른 섹터로 쉽게 이동할 수 없습니다.

향후 전망
BitLocker의 암호화 보안에 대한 갖가지 예측에서는 전체적인 그림을 보지 못하고 있습니다. BitLocker의 경우 보안을 보장하는 것만으로는 제 역할을 수행할 수 없습니다. BitLocker는 홀로 사용되는 솔루션이 아니라 Windows Vista의 다양한 기능 중 하나이기 때문입니다. Microsoft에서는 BitLocker가 Windows Vista에 완전히 통합된 솔루션이라고 밝히고 있습니다. 그러나 OS와 완벽하게 통합되었다면 다른 구성 요소에서 오류가 발생할 경우 BitLocker에서도 오류가 발생하거나 공격을 당할 수도 있지 않을까요?
개인적으로 필자는 모듈화와 오류 격리가 효과적이라고 믿고 있습니다. 모듈화하지 않은 채로 완전히 통합할 경우 복잡한 결과가 발생합니다. Windows Vista와 BitLocker에서는 이러한 문제가 발생하지 않을 수도 있지만, 이는 시간이 지나고 충분한 분석이 이루어진 후에야 증명될 것입니다.
BitLocker에 대한 필자의 최종 평가는? 암호 전문가의 의무를 충실히 이행한 Microsoft System Integrity 팀에게 경의를 표하는 바입니다. 이 기능이 단순히 마케팅을 위한 수단으로서가 아니라 진정으로 암호화를 구현하도록 설계된 것만은 확실합니다. 따라서 필자는 BitLocker의 유용성에 큰 점수를 매기고 싶습니다. 단, 이 기능을 통한 보안 효과가 뛰어난지에 대한 평가는 별개의 문제입니다. 다시 한번 말하지만 그 효과에 대해서는 시간이 지나고 실질적인 평가가 이루어진 후에만 확실히 말할 수 있을 것입니다. 지금까지 수많은 암호화 기술과 프로토콜이 공격에 무너지고 말았습니다. 그러나 적어도 Microsoft System Integrity 팀은 더 효과적인 솔루션을 개발하는 데 필요한 이해와 기반을 제공했다고 할 수 있습니다.

Justin Troutman은 암호 전문가를 꿈꾸며 수학을 전공하고 있는 학생입니다. 대칭적 암호화에 관심이 많은 Justin은 암호화 연구와 컨설팅을 전문으로 하는 Extorque를 설립하기도 했습니다.


 The Desktop Files: 고급 사용자를 위한 WIM 및 ImageX 가이드
The Desktop Files
고급 사용자를 위한 WIM 및 ImageX 가이드
Wes Miller
이 칼럼은 WAIK(Windows Automated Installation Kit) 및 Windows Server 2008의 시험판 버전을 기준으로 작성되었습니다. 이 문서에 수록된 모든 정보는 변경될 수 있습니다.

필자는 몇 편의 이전 칼럼에서 ImageX 및 WIM(Windows Imaging) 형식에 대해 다루었습니다. 그런데 몇 개월 전 Tech•Ed에서 WDS(Windows Deployment Services), ImageX 및 WAIK(Windows Automated Installation Kit)를 사용하기 시작한 IT 전문가들로부터 몇 가지 의견과 질문을 들으면서
더 많은 사용자 가이드가 필요함을 깨달았습니다. 따라서 이번 달 칼럼에서는 ImageX와 WIM 형식을 집중적으로 설명하고 이를 최대한 활용하는 방법을 소개하려고 합니다. ImageX와 WIM을 사용하면 Windows Vista®와 Windows Server® 2008 뿐만 아니라 Windows® XP, Windows Server 2003, Windows 2000도 쉽게 배포할 수 있습니다.

WAIK의 변경 내용
곧 출시될 Windows Server 2008이 WAIK와 관련하여 어떤 의미를 갖는지 궁금할 것입니다. Microsoft에서는 Windows Server 2008이 출시될 때쯤 업데이트된 버전의 WAIK를 발표할 계획입니다. WIM 형식에는 큰 변화가 없으며(ImageX 도구와 형식도 변경되지 않음) Windows Server 2003의 WDS도 변경되지 않습니다. 소문과 달리 멀티캐스트는 Windows Server 2003 WDS에서 사용할 수 없습니다. Windows Server 2008을 실행하는 WDS 서버에만 WDS에 대한 새로운 멀티캐스트 배포 기능이 포함됩니다.
Windows PE 2.0 및 Windows 설치 프로그램은 다음을 지원하도록 수정됩니다.
  • Windows Server 2008 및 Windows Vista의 배포
  • Windows Server 2008 WDS 서버에서 WDS를 통한 멀티캐스트 배포
  • x86 Windows PE에서 Windows Vista 및 Windows Server 2008의 x64 버전과 x86 버전의 배포
우선 이런 변화는 Windows PE 2.0에서 Windows Server 2008을 Windows Vista에서처럼 배포할 수 있으며 동일한 도구와 프로세스를 두 운영 체제 간에 바꾸어 사용하더라도 같은 방식으로 작동함을 의미합니다. 두 번째로 Windows Server 2008에서 WDS 서버를 실행하고 있다면 WDS를 통해 멀티캐스트 배포를 이용할 수 있습니다. 그리고 마지막으로 x86 Windows PE 2.0 디스크에서 Windows의 x86 또는 x64 이미지를 배포할 수 있음을 의미합니다.
이에 대해서는 Tech•Ed의 x64 Windows 관련 세션에서 언급한 적이 있습니다. 하지만 블로그와 Windows 기술 커뮤니티에서 이에 대한 몇 가지 혼동이 있는데, Microsoft가 모든 Windows Vista 또는 Windows Server 2008 DVD에 x64 Windows 및 x86 Windows를 배포할 것임을 의미하지는 않습니다. 또한 가능하긴 하지만 Windows x64 및 Windows x86 이미지를 하나의 WIM 파일로 결합해야 한다는 것을 의미하지도 않습니다. 이렇게 하면 WIM를 하나의 파일로 제공할 수 있지만 단일 인스턴스 저장소로 저장되지는 않습니다.
몇 년 동안 x86 기반 배포 프로세스(그리고 사용자 지정 스크립트와 도구)를 개발해온 엔터프라이즈 고객과 OEM이 이제 32비트 설치를 사용하여 WIM 내에서 x86 또는 x64 Windows를 배포할 수 있게 되었음을 의미합니다. 이는 2005년 x64 Windows가 처음 선보인 이후 많은 엔터프라이즈 고객이 요구했던 기능입니다.

ImageX 사용
/mount, /mountrw 및 /delete 사용
다음은 ImageX에 /mount, /mountrw 및 /delete 스위치를 사용할 때의 몇 가지 중요한 팁입니다.
  • 편집하려는 경우 /mountrw를 사용하여 볼륨을 탑재합니다.
  • WIM은 빈 디렉터리에 탑재해야 합니다. 그래야 저장한 파일로 인한 혼동을 피하고 ImageX에서 불필요한 경고 메시지가 표시되는 것을 방지할 수 있습니다.
  • 변경 내용을 저장하려는 경우 읽기/쓰기 이미지에 /unmount /commit를 적용하는 것을 잊지 마십시오. 변경을 하고 이를 커밋하지 않아서 손실되는 경우를 많이 볼 수 있습니다.
  • /mountrw를 통해 파일을 삭제하고 /delete를 통해 볼륨 이미지를 삭제하더라도 공간이 다시 확보되지 않을 뿐만 아니라 오히려 더 많은 공간이 사용될 수 있습니다. 자세한 내용은 이 칼럼에서 /export에 대한 섹션을 참조하십시오.
  • 읽기/쓰기 액세스에 대해 한 번에 하나의 WIM 파일만 탑재할 수 있습니다. 두 사용자가 동시에 같은 WIM을 편집할 수 없으며 한 번에 두 개의 볼륨 이미지를 편집할 수도 없습니다.
  • 읽기 전용 모드(/mount)에서도 동시에 탑재하는 볼륨 이미지의 수를 제한해야 합니다. 탑재된 각 이미지에 대해 시스템에서 사용 가능한 Windows 비페이징 풀 메모리의 용량에 드라이버가 종속되기 때문입니다. 이로 인해 시스템마다(또는 시스템 아키텍처에 따라) 서로 다르게 이미지 수가 제한됩니다. 따라서 동시에 6개 이상의 이미지는 탑재를 시도하지 않는 것이 좋습니다.
  • 변경할 때 /mountrw를 통해 많은 양을 편집하더라도 거의 시간이 걸리지 않지만 /commit의 경우에는 모든 새 파일 데이터를 비교하고 저장해야 하므로 꽤 많은 시간이 걸립니다.
  • /delete 및 /mountrw는 주의하여 사용하십시오. 변경이 커밋되면 되돌릴 수 없습니다.
  • WIM 파일에 하나의 볼륨 이미지만 있는 경우에는 /delete를 실행할 수 없습니다. 전체 WIM 파일을 삭제하거나 다른 볼륨 이미지를 추가해야 합니다.
  • 볼륨 이미지 내용의 디렉터리 트리를 빠르게 가져오려면 /mount 대신 다음 명령을 사용하십시오.
ImageX /dir <path_to_wim_file> <image index>
  • 동시에 두 개의 WIM 파일을 편집하고 있을 때는 /unmount를 동시에 실행하지 않도록 하십시오. 서로 방해되지 않도록 mount/unmount 이벤트를 차례로 실행하십시오.

ImageX는 OEM과 엔터프라이즈 고객이 보내 준 도구 사용 방식에 대한 의견을 바탕으로 설계되었습니다. 그림 1에서는 이 프로세스를 보여 줍니다.
그림 1 ImageX 사용
그림 1 ImageX 사용
5단계는 매우 중요합니다. 이미지는 계속 변경되므로 이미지 캡처와 수정은 가능한 빠르고 쉽게 이루어져야 합니다.
이를 위해 이미 생성한 이미지에 /append 스위치를 사용하여 이미지를 추가하는 기능이 제공됩니다. 개발팀은 처음에는 이전 이미지에 SKU(Windows의 버전)를 추가하기를 원할 것으로 생각했지만 Windows Vista 개발 초기 단계에서 엔터프라이즈 고객과 작업을 하면서 X를 배포한 뒤에 2단계의 수정 내용 중 한 가지를 수행한 X1을 다시 캡처하는 것이 더 빠르다는 의견을 들었습니다. 이렇게 하면 일부 파일만 수정했기 때문에 이미지를 빠르게 다시 캡처할 수 있습니다.
팀에서는 이 의견을 듣고 원본 이미지를 보존하는 것이 모든 상황에 적합한 방식은 아님을 깨달았습니다. 이 칼럼의 뒷부분에서 이 시나리오와 다음에 나오는 시나리오로 인해 추가된 /export 스위치에 대해 소개합니다.

지속적인 변경
개발팀에서는 초기 단계부터 WIM 파일을 편집할 수 있어야 한다고 결정했습니다. 섹터 기반 이미징 형식이 적절하지 않다고 이미 결정했기 때문에(이에 대한 설명은 technetmagazine.com/issues/2006/12/DesktopFiles의 2006년 12월 칼럼 참조) 기본적으로 파일을 Windows 파일 시스템의 일부로 손쉽게 탑재하고 WIM 파일의 탑재된 볼륨 이미지를 변경할 수 있는 솔루션을 제공해야 했습니다. 말하자면 "이동하는 부분"이 몇 가지 더 필요하다는 것입니다. 섹터 기반 이미지를 탑재하는 것은 비교적 쉽지만 WIM과 같은 자체 보관 형식을 탑재하려면 전용 도구를 사용해야 합니다.
이 형식은 명령 프롬프트에 액세스할 수 있어야 하므로 ZIP과 CAB 파일을 처리하는 데 기본적으로 많이 사용되는 Windows 셸 확장은 사용할 수 없습니다. 불행히도 이러한 처리기는 개체에 대한 Windows 탐색기 추상 액세스만 허용합니다.
따라서 WIM 솔루션에는 드라이버를 실제로 로드하기 위한 방편 역할을 하고 WIM 탑재를 위한 인터페이스를 처리하는 ImageX와 드라이버(wimfltr.sys)가 사용됩니다. 드라이버는 그림 2에서처럼 Windows 파일 시스템에 추상화를 추가하는 역할을 합니다. 이와 같은 명령 중 하나를 실행하면 ImageX는 wimfltr.sys 드라이버를 로드하고 빈 디렉터리 탑재에서 첫 번째 볼륨 이미지(여기서 사용한 명령에서 1)를 오버레이합니다.
그림 2 WIM 볼륨 이미지 탑재
그림 2 WIM 볼륨 이미지 탑재
ImageX /mount iso\sources\boot.wim 1 mount
ImageX /mountrw iso\sources\boot.wim 1 mount
이는 WAIK의 기본 동작입니다. 따라서 탑재 디렉터리에서 디렉터리 목록을 탐색하거나 생성하는 경우에는 boot.wim에서 볼륨 이미지 1의 루트를 볼 수 있습니다. 물론 /mountrw 또는 /mount 중 무엇을 사용할지는 이 디렉터리가 읽기 전용인지 읽기/쓰기가 가능한 디렉터리인지에 따라 달라집니다. 자세한 내용은 추가 기사 "/mount, /mountrw 및 /delete 사용"을 참조하십시오.
/mountrw 기능은 원래 손쉽게 드라이버 또는 xcopy 가능 파일이나 콘텐츠 파일을 추가하거나, 응답 파일을 설정하거나, 탑재된 WIM 파일의 오프라인 레지스트리를 수정하여 필요에 따라 변경하기 위해 설계되었습니다(그림 3 참조). 이 기능은 전체 응용 프로그램을 추가하거나 제거하기 위해 설계된 것이 아닙니다(MSI 설치 응용 프로그램은 오프라인으로 설치할 수 없으므로).
그림 3 탑재된 WIM 파일 수정
그림 3 탑재된 WIM 파일 수정
탑재된 WIM 파일을 변경할 때는 실제 WIM 파일을 직접 변경하는 것이 아니라(최소한 즉시 변경하지는 않음) 실제로 오버레이와 변경 내용이 병합되는 WIM 파일의 캐시를 변경하는 것입니다. 추가 기사에서 언급하듯이 필자는 이로 인해 문제를 겪은 적이 있습니다. 끝난 뒤 /unmount 및 /commit 스위치를 사용해야 하며 이렇게 해야 변경 내용이 WIM 파일로 커밋됩니다. 그렇지 않으면 변경 내용이 완전히 손실됩니다.
변경 내용을 커밋하여 저장하는 것은 드라이버에 WIM 파일 자체를 변경하도록 지시하는 것과 같습니다. 그러면 드라이버가 추가 파일 데이터를 추가합니다. 따라서 많은 내용을 변경한 경우에는 WIM에 파일 데이터를 추가하기 때문에 /commit을 실행하는 데 시간이 많이 걸릴 수 있습니다.
또한 섹터 기반 이미징 형식과는 달리 볼륨 이미지에서 하나 이상의 파일을 변경했을 수 있습니다. 따라서 같은 파일이 이미 한 번 저장된 경우 이외에는 더 이상 단일 인스턴스가 아닐 뿐만 아니라 원본 파일 데이터가 손실됩니다. WIM은 NTFS 또는 FAT 볼륨과는 달리 파일에 삭제 표시를 하지 않습니다. 즉, 더 이상 참조하지는 않지만 지우지도 않습니다. 따라서 /mountrw를 통해 자주 편집을 하거나, /append를 사용하여 많은 이미지를 추가하거나, /delete를 사용하여 볼륨 이미지를 삭제하는 경우에는 WIM 파일에서 파일 데이터에 대한 참조만 제거되고 관련 파일 데이터가 함께 삭제되지 않습니다.
따라서 개발팀에서는 "WIM 조각 모음"라고도 하는 /export 스위치를 만들었습니다.

내보내기
/export에 대한 중요한 참고 사항
/export를 사용하여 새 WIM 파일을 만들 때는 현재 사용되는 기본 압축 유형을 그대로 사용하지 않고 사용할 압축 형식을 직접 지정할 수 있습니다. 현재 압축 유형을 변경할 때는 내보내기에 꽤 많은 시간이 걸릴 수 있습니다.
사실상 /append처럼 사용되는 경우(볼륨 이미지를 기존 WIM 파일에 추가)에는 /export로 WIM 파일의 /compression 속성을 수정할 수 없습니다.
완전히 새로운 Windows PE 2.0 볼륨 이미지를 내보내는 경우에는 /boot 스위치를 지정할 수 있습니다.

/export 스위치는 앞서 설명한 시나리오와 팀에서 발견한 다른 몇 가지 시나리오를 해결하기 위해 만들어졌습니다. 간단히 말하면 /export를 통해 기존 볼륨 이미지(두 개 또는 세 개)를 가져와서 내보낼 수 있습니다. 이는 위의 X 및 X1 WIM 파일을 가져와 X, X1로 각각 새 WTM 파일을 만들거나, 또 다른 WIM 파일을 내보내 X1과 Y1로 새 WIM 파일을 신속히 만들 수 있음을 의미합니다.
X를 수정하고 변경 내용을 X1로 추가(/append)하는 시나리오를 예로 들어보겠습니다. X를 이번 분기용 새 이미지로 바꿨기 때문에 X를 삭제하기로 했습니다. 이 경우 /delete 스위치를 사용할 수 있으며 그러면 ImageX는 X 이미지를 더 이상 인식하지 않습니다. 하지만 X에 관련된 모든 정보를 제거하여 공간을 절약하려면 다음 명령을 실행해야 합니다.
ImageX /export source.wim 2 destination.wim "New image for Q4CY07"
이렇게 하면 두 번째 볼륨 이미지가 새 WIM 파일에 새 이름으로 내보내져서 볼륨 이미지 1에서 이전 정보가 완전히 제거됩니다. 또한 분산된 WIM 이미지에서 내보내 하나의 WIM 파일로 재조합할 수도 있습니다(이 칼럼 뒷부분에서 설명). 분산된 이미지는 /mountrw를 사용하여 편집할 수 없습니다. ImageX에 /import 명령이 없는 것은 /export로 새 WIM 파일을 만들고 기존 파일에 추가하는 작업을 모두 할 수 있기 때문입니다. 이 주제에 대한 자세한 내용은 추가 기사 "/export에 대한 중요한 참고 사항"을 참조하십시오.
이는 peimg /prep를 실행할 때도 중요합니다. 이 명령은 사용될 Windows PE 이미지를 준비하지만 WIM에서 어떤 내용도 지우지 않습니다. 이상적으로는 Windows PE 릴리스 프로세스의 일부로 이미지를 준비한 다음 새 boot.wim 파일로 내보내야 합니다. 부트 프로세스는 \sources\boot.wim에서만 WIM 파일을 찾으므로 이름이 올바르며 부트 볼륨 이미지 표시되었는지 확인해야 합니다.
이전 볼륨 이미지를 문서화하거나 여러 개를 조합할 때는 /export를 실행하여 이미지를 최적화할 수 있습니다. 또는 /mountrw 또는 /delete를 통해 많은 편집을 수행한 경우에도 이런 작업이 필요할 수 있습니다. 그렇지 않은 경우에는 WIM 파일이 시간이 경과함에 따라 진단할 수 없는 방식으로 계속 증가합니다. /mountrw 또는 /delete를 정기적으로 사용하는 경우에는 완전히 최적화되었는지 확인하기 위해 워크플로에 /export를 추가하는 것을 고려하십시오.

확장
처음 노출된 다른 문제는 WIM 파일을 다양한 미디어에 맞도록 해야 한다는 점이었습니다. 우리는 Windows가 두 장 이상의 CD로(그리고 잠재적으로 DVD로 - 현재 방식) 제공될 것으로 예상했기 때문에 WIM과 ImageX에 분산 지원을 적용했습니다.
앞서 말했듯이 /split로 작성된 분산 이미지는 기본적으로 읽기 전용입니다. 따라서 새로 분산된 이미지에 직접 /capture를 실행할 수 없고, ImageX를 통해 탑재할 수 없으며, /append를 통해 추가할 수 없습니다. 결과적으로 표준 워크플로를 완료하고 릴리스할 준비가 되었을 때만 WIM 파일을 분할하는 것이 좋습니다. 즉, 모든 변경 작업은 일반 WIM 파일에 대해 수행하고 배포 시나리오를 위한 릴리스 프로세스의 일부로 분할을 하는 것을 고려하십시오.
이미지를 적용할 때는 분산된 이미지가 문제가 될 수 있습니다. 분산 이미지를 사용할 때는 설치 프로그램보다는 ImageX를 사용할 것을 권장합니다. 또한 이미지를 네트워크를 통해 적용하거나(적용하는 디스크를 이미지로 만들지 않고 성능을 최적화하기 위해) 드라이브로 직접 복사한 다음 적용하는 것이(적용할 때 디스크에서 디스크 자체를 읽고 쓰므로 디스크에 바인딩된다는 점을 유의) 좋습니다.

유효성 확인
ImageX를 사용할 때는 많은 데이터를 이동하며 대부분은 매우 중요한 데이터입니다. 올해 Tech•Ed에서 자주 접한 질문은 "이미지 유효성을 확인하는 방법"에 대한 것이었습니다. 유효성 확인이 매우 쉬운 것은 아니지만 그렇게 어렵지도 않습니다.
WIM에 대해 이해해야 할 중요한 사항은 대부분의 보관 형식과 마찬가지로 손상될 수 있다는 점입니다. 대개의 경우 WIM 파일이 네트워크를 통해 전송될 때 이런 손상이 발생합니다. Windows Vista 초기에는 특정 네트워크 카드에 특정한 문제가 있었습니다. 패키지를 폐기할 때 WIM 파일이 손상되었으며 이를 진단하기가 쉽지 않았습니다. 이런 상황은 몇 년 전 driver.cab 파일의 크기가 커질 때 무작위로 손상이 발생하는 문제와 비슷합니다. 일반적으로 잘못된 이미지나 설치 실패에 대한 보고를 받은 경우에는 보고서를 생성하는 시스템에 사용되는 NIC의 유형을 확인해볼 수 있습니다. ImageX 자체를 사용하거나 WDS를 실행하는 모든 경우에 적용됩니다.
그렇다면 이미지가 정상인지 확인하려면 어떻게 해야 할까요? 우선 /check 스위치를 사용할 수 있습니다. 이렇게 하면 WIM 파일에 추가적인 무결성 검사가 저장되고 적용 전에 WIM의 손상 여부가 검사됩니다. 적용 시에도 /check를 실행하여 이미지 유효성을 확인하십시오(시간이 걸릴 수 있음).
문제가 있거나 신중을 기하기 위해, 적용 후 캡처하기 전에 파일에 대해 해싱 유틸리티를 실행할 수 있습니다. 이미지를 탑재하고 다시 해싱하여 캡처 후에도 확인할 수 있으며 이는 이미지가 올바르게 탑재되었는지 확인하기 위한 한 가지 방법입니다.
이미지가 처음부터 올바르게 캡처되고 있는지 확인해야 할 때도 있습니다. /check 스위치와 형식 자체는 제대로 캡처되지 않은 이미지를 복구하기 위한 복구 도구가 아니라 검사점으로 설계되었습니다.

부팅 및 플래그
앞에서 /boot를 사용하여 Windows PE의 WIM 볼륨 이미지를 캡처하고 이를 부팅할 수 있다고 설명했습니다. 이것은 특정 볼륨 이미지의 부트 섹터처럼 생각해야 합니다. WIM당 하나의 볼륨 이미지에만 존재할 수 있으며 Windows PE 2.0에 대해서만 유효합니다. 즉, WIM로 Windows PE 1.x를 부팅할 수 없습니다.
Windows 볼륨 이미지에서 플래그에 대한 참조를 볼 수 있습니다. 플래그는 Windows 설치 프로그램에서만 사용됩니다. 볼륨 이미지의 플래그가 2이면 볼륨 이미지에 Windows PE와 설치 프로그램이 들어 있음을 의미합니다. 플래그 9는 Windows PE만 들어 있음을 의미합니다. 다른 플래그 또는 플래그가 없는 경우는 설치 프로그램에서 이미지를 사용할 수 없음을 의미합니다. 이미지를 수정하기 위해 ImageX를 사용하여 캡처한 뒤에만 이미지에 플래그를 설정할 수 있습니다. 플래그가 제대로 설정되므로 WAIK(그리고 선택적으로 Business Desktop Deployment Solution Accelerator)를 사용하여 Windows PE WIM 부트 이미지를 작성하는 것이 좋습니다.

HTA 사용자에 대한 참고 사항
최근 필자는 Windows PE 2.0에서 HTA 파일을 실행할 때 발생하는 몇 가지 문제를 보고 받았습니다. 불행히도 다량의 스크립팅이 포함된 HTA 파일에서는 문제가 발생하는 것으로 보입니다. 그림 4에서 필자가 작성한 샘플 파일의 스크린샷을 참조하고, 여기서 반환된 스크립팅 오류(정보가 없는)를 살펴보십시오. 몇몇 고객이 이 문제를 보고했으며 필자도 직접 경험했습니다.
그림 4 HTA 스크립팅 오류
그림 4 HTA 스크립팅 오류
하지만 이 문제는 비교적 쉽게 해결할 수 있습니다. 이미지를 준비할 때 HTA 지원과 XML 지원을 추가하십시오. 그러면 HTA 구성 요소의 누락된 종속성이 XML 추가 기능 모듈에 포함된 것처럼 나타나서 이 문제가 해결됩니다.
이 칼럼에 많은 도움을 주신 ImageX 개발자인 Bruce Green, Windows 개발 테스트 팀의 Minxiao Zhou, Raja Ganjikunta에게 감사 드립니다.

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


 Field Notes: PC 재활용
Field Notes
PC 재활용
Jim Lynch

Community MAR(Microsoft Authorized Refurbisher - Microsoft 공인 재활용) 프로그램(microsoft.com/mar)은 Microsoft UP(Unlimited Potential - 무한한 잠재력) 이니셔티브 중 비교적 알려지지 않은 매우 독특한 프로젝트입니다. Microsoft는 이 프로젝트를 통해 교육 환경을 개선하고, 일자리를 창출하고, 사회 저소득층을 위한 다양한 경제적 기회를 제공하기 위해 많은 프로젝트를 지원하고 있습니다. 2000년도에 영국에서 시작된 Community MAR 프로그램은 이제 전세계 50여 개국에서 800개 이상의 PC 재활용 센터를 운영하고 있습니다.
Community MAR 프로그램의 가장 경탄할 만한 점은 Windows® 2000과 Windows XP의 라이선스를 단 5달러(미화)에 제공할 수 있다는 것입니다. MAR은 1년에 20만 개 이상의 라이선스를 재활용 PC에 포함하여 비영리 단체, 학교, 도서관, 대학 등에 제공하고 있으며 미국 내에서는 저소득층이나 장애가 있는 개인을 위한 기술 교육 프로그램을 제공하고 있습니다. Community MAR은 이러한 방법을 통해 교육과 고용의 기회를 제공함으로써 정보 격차로 인해 정보의 혜택을 누리지 못하고 있는 사람들에게 한층 다가가기 위해 노력하고 있습니다.
혜택받지 못한 어린이를 위한 Community MAR의 노력은 전 세계로 확산되고 있습니다. 예를 들어 Operation Homelink는 미국의 저소득층 군인 가족에게 컴퓨터를 제공하고 있습니다. 또한 영국의 Computer Aid International은 아프리카에 컴퓨터를 제공하는 가장 큰 규모의 민간 단체이며, 캐나다의 Computers for Schools Canada 재활용 네트워크는 캐나다에 소재한 학교에 상당량의 컴퓨터를 제공하고 있습니다.
재사용의 효과
미국의 EPA(환경 보호국)는 최근 테네시 대학과의 협력을 통해 에너지, 원자재, CO2및 유해 물질 배출의 측면에서 전자 제품 재사용이 가져다 주는 효과를 보여 주었습니다. 이들이 개발한 EEBC(Electronics Environmental Benefits Calculator)(eerc.ra.utk.edu/ccpct/eebc/eebc.html)에 따르면 CRT 모니터가 장착된 컴퓨터 한 대를 다시 사용할 경우 다음과 같은 자원 절약 또는 환경 보호 효과를 볼 수 있습니다.
  • 폐수 14Kg
  • 고형 폐기물 34Kg
  • 원자재 34Kg
  • 67Kg의 수질 오염 방지
  • 32톤의 대기 오염 방지
  • 600Kg의 CO2 배출 방지
  • 7,719kW의 에너지

사실 Community MAR 프로그램은 전통적으로 기술에 대한 접근이 제한된 영국의 학교와 자선 단체에 공급되는 장비를 늘리기 위해 2000년경에 시작되었으며 2003년에는 미국과 오스트레일리아로, 그리고 2005년에는 전 세계로 확대되어 현재는 영리/비영리 단체, 정부 및 학교를 기반으로 하는 모든 유형의 재활용 업체에서 이용할 수 있게 되었습니다. 이 과정에서 컴퓨터 재사용 및 재활용 산업도 새롭게 탄생하게 되었습니다.
Community MAR 프로그램으로 인한 혜택 중 환경과 관련된 부분은 잘 알려져 있지 않습니다. 전자 제품의 수명을 연장하는 것은 제품의 우수한 기능을 그대로 유지할 뿐만 아니라 경제, 환경, 그리고 사회적 측면에서 최상의 효과를 가져다 주므로 가장 효율적인 형태의 재활용이라고 할 수 있습니다. 폐기된 제품의 재활용도 분명히 효과적이고 필요하지만 이 경우 어떤 제품이든 10-30%의 원자재와 에너지가 손실됩니다.
컴퓨터를 제조하는 데 엄청나게 많은 환경 비용이 들어간다는 것은 전혀 놀라운 일이 아닙니다. 애리조나 주립 대학교의 환경 과학자인 Eric D. Williams에 따르면 평균 24Kg의 데스크톱 컴퓨터와 모니터를 생산하는 데 화석 연료 240Kg, 화학 원료 22.7Kg 및 물 1,496Kg이 필요하다고 합니다. 컴퓨터의 수명을 2~3년 늘릴 경우 폐기된 컴퓨터를 재활용하는 것에 비해 5~20배나 많은 에너지를 절약할 수 있습니다. 자세한 수치는 "재사용의 효과" 추가 기사를 참조하십시오.
Microsoft는 MAR이라는 혁신적인 프로그램을 통해 필요한 사람에게 기술의 혜택을 제공함으로써 사회를 변화시키는 기회를 창출하는 데 일조하고 있습니다. Community MAR 프로그램이 가져온 또 한 가지 놀라운 성과는 바로 컴퓨터 재사용에 대한 대중의 인식과 지원을 이끌어냈다는 것입니다.

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


 Windows Confidential: Dr. Watson 호출
Windows Confidential
Dr. Watson 호출
Raymond Chen

Winlogon 프로세스의 메모리 덤프를 만들도록 Dr. Watson(drwtsn32.exe)에 요청하면 작업이 완료되자마자 Windows®가 종료되는 것을 경험한 독자도 있을 것입니다. 그리고 이때 "왜 디버거를 Winlogon에 연결하면 시스템이 종료되지?"라는 의문을 가졌던 사람도 있을 것입니다.
사실 정확히 말하면 이는 틀린 말입니다. 프로세스에 대해 Dr. Watson을 실행하는 것은 디버거를 프로세스에 연결하는 것과는 다르니까요. 디버거를 연결하려면 ntsd와 같은 도구를 사용해야 하며 필요한 권한이 있다면 충분히 가능합니다. 실제로 Windows 팀에서도 이러한 방법으로 Winlogon 문제를 디버그합니다. 따라서 "왜 디버거를 Winlogon에 연결하면 시스템이 종료되는가?"라는 질문에 대해 간단히 답한다면 "Winlogon이 시스템을 중단시키는 것이 아닙니다."라고 대답할 수 있습니다.
먼저 문제가 발생한 프로세스의 메모리 덤프를 만든 후 프로세스를 중단하는 Dr. Watson은 말하자면 일반 개업의가 아니라 검시관에 해당한다고 할 수 있습니다. 실질적으로 Dr. Watson은 문제 해결을 시도하지 않으므로 프로세스를 계속 실행하도록 허용하면 다시 중단될 뿐입니다. 그리고 Dr. Watson이 다시 호출되어 무한 루프에 빠지게 됩니다. 한마디로 Dr. Watson은 디버그를 수행하지 않는 디버거라고 할 수 있습니다. 어디에선가 좋은 의사가 나타나 주의 깊게 상황을 살피고 프로세스를 중단하는 것입니다. 그리고 메모리 덤프를 만든 후에 Winlogon을 중단함에 따라 시스템이 중단됩니다.
Winlogon을 중단하면 시스템이 다시 부팅됨
Winlogon을 중단하면 시스템이 다시 부팅됨
Winlogon는 "중대한 시스템 프로세스"이므로 중단될 경우 시스템이 다시 시작됩니다. 그렇다면 왜 Winlogon은 시스템 작동에 있어서 중요한 프로세스로 간주될까요? 첫째, Winlogon은 SAS(Secure Attention Sequence)인 Ctrl+Alt+Del의 처리를 담당합니다. Winlogon이 중단되면 SAS가 작동하지 않습니다. 이 자체만으로도 문제라고 할 수 있습니다. 그런데 더 나쁜 것은 SAS의 공식 담당자가 중단되면서 다른 프로그램이 사용자가 Ctrl+Alt+Del을 누를 때까지 기다렸다가 응답으로 가짜 암호 대화 상자를 표시할 수 있다는 점입니다. 이런 식으로 스푸핑될 수 있다면 Secure Attention Sequence라는 이름이 무색해집니다. 따라서 보안 차원에서 Windows는 더 큰 문제가 발생하기 전에 시스템을 종료합니다.
다음으로, 사용자가 작업 관리자를 실행하고 Winlogon과 같은 중대한 시스템 프로세스를 선택하고 프로세스 종료를 클릭한 후 종료하도록 확인하면 Winlogon이 중단되고 시스템이 다시 부팅됩니다. 물론 프로세스를 중단할 권한이 있는 높은 권한의 관리자로 시스템을 실행한 경우에 이것이 가능합니다.
이전 Windows 버전에서 작업 관리자는 사용자가 중대한 시스템 프로세스를 중지하지 못하도록 막았지만 중대한 프로세스인지를 확인하는 알고리즘은 그다지 지능적이지 못했습니다. 때문에 편법을 사용하면 작업 관리자를 속여 특정 프로그램을 중단 불가능한 것으로 간주되도록 할 수 있었습니다. 물론 이러한 프로그램도 작업 관리자 이외의 프로그램을 사용하면 중단할 수 있었습니다. 예를 들어 taskkill 프로그램을 사용할 수 있습니다.
이러한 편법을 방지하기 위해 더 이상 작업 관리자는 사용자가 중대한 시스템 프로세스를 중단하지 못하도록 방지하지 않습니다. 결국 아무 것도 하지 않으면 잘못될 일도 없다는 것이죠. 결론적으로 작업 관리자는 더 이상 사용자가 어떤 프로세스를 중단하는지 감시하지 않습니다. 그리고 건드려서는 안 될 프로세스를 중단하려 할 때에도 아무런 조치를 취하지 않습니다. 따라서 중대한 시스템 프로세스를 중단한다면 그에 따른 결과를 감내하는 수밖에 없습니다.

Raymond Chen은 The Old New Thing 웹 사이트와 동명의 저서(Addison-Wesley, 2007)에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있습니다. 현재 Chen은 운영과 관련된 업무는 다른 사람에게 넘겼습니다.