• 아티클

Inside SharepointSharePoint 인프라 구축

Pav Cherny

이 기사의 코드 다운로드: SharePoint2008_05.exe (412KB)

전자 메일 메시징이 비즈니스 커뮤니케이션에 변화를 준 것처럼 웹 기반 공동 작업은 사람들이 함께 작업하고 정보를 공유하는 방식을 변화시키고 있습니다. 이러한 변화에 대한 좋은 예로, SharePoint 기술이 제공하는 기능에 대해 살펴보겠습니다. Microsoft WSS(Windows SharePoint Services) 3.0 및 MOSS(Microsoft Office SharePoint Server)

2007을 사용하면 2007 Microsoft® Office 시스템 통합, XML 기반 양식, 워크플로, 모바일 지원 등은 물론 팀 사이트, 포털, 웹 콘텐츠 관리 솔루션, 문서 라이브러리 및 검색 센터를 만들 수 있습니다.

하지만 SharePoint®를 시작하는 것이 항상 간단하지는 않습니다. 용어가 혼동스러울 수 있으며 시스템 아키텍처가 복잡할 수 있습니다. 또한 SharePoint를 사용하려면 IIS, Microsoft .NET Framework 및 SQL Server®뿐만 아니라 Business Intelligence, InfoPath® Forms Services, RMS(Rights Management Services), Exchange Server, ForefrontTM Security 등과 같은 다양한 기술을 포함한 여러 구성 요소를 다루어야 합니다.

기본 제공 사용자 인터페이스 또는 프로그래밍 방식과 같이 SharePoint 솔루션을 만들기 위해 사용할 수 있는 접근 방법이 여러 개 제공되기 때문에 통합 및 사용자 지정 작업에 어려움을 겪을 수 있습니다. 또한 SharePoint 응용 프로그램이 작동하지 않는 경우 문제 해결이 복잡할 수 있습니다. 응용 프로그램 개발자의 관점에서 관련 구성 요소 및 이들 구성 요소의 상호 작용 방식을 이해해야 하는 경우도 많습니다. 이러한 어려움을 모두 고려했을 때 강력하며 확장 가능하고 관리가 쉬운 SharePoint 인프라를 구축하려면 어디서부터 시작해야 할까요?

이 칼럼에서는 먼저 아키텍처 개요에 대한 설명을 통해 기초를 마련한 다음 매우 기본적인 브랜딩 사용자 지정을 포함한 WSS 배포를 살펴봄으로써 SharePoint 인프라 구축을 시작하는 방법을 설명합니다. WSS 3.0의 셀프 서비스 사이트 관리 기능을 사용하여 SharePoint 인프라에 대한 중앙 집중식 관리 제어를 유지하면서 SharePoint 사이트를 만들고 관리하는 권한을 개별 사용자에게 위임하는 방법을 알아봅니다.

먼저 SharePoint 아키텍처를 이해하면 유연성 있고 확장 가능한 인프라를 구현하는 데 필요한 배포 및 구성 단계를 더 쉽게 이해할 수 있습니다. 따라서 종속성에 대해 잠깐 살펴본 다음 WSS 3.0의 배포를 설명하겠습니다. 자세한 배포 지침에 대해서는 첨부 자료를 참조하십시오. 이 자료는 TechNet Magazine 웹 사이트(technetmagazine.com)의 다운로드 섹션에서 구할 수 있습니다.

SharePoint 아키텍처

SharePoint를 사용할 때 시스템 설계자의 관점에서 해당 기술을 이해하면 도움이 됩니다. 주요 세부 사항을 모두 알 필요는 없지만 SharePoint 아키텍처에서 비롯된 전체적인 종속성에 대해 잘 알게 되면 구성해야 하는 대상 및 그 이유를 예측할 수 있기 때문에 더 빠르게 솔루션을 찾을 수 있습니다.

SharePoint는 웹 응용 프로그램 및 사이트를 준비하는 데 사용되는 기술입니다. SharePoint는 IIS 기반 웹 사이트 솔루션으로, ASP.NET을 통해 IIS와 통합되고 SQL Server 데이터베이스 백 엔드를 사용하여 구성 데이터와 콘텐츠를 저장합니다. 간단히 말해서, SharePoint의 핵심 아키텍처는 그림 1에서처럼 세 개의 서로 다른 아키텍처(IIS, .NET 및 SQL Server)의 결합으로 구성되어 있습니다.

그림 1 IIS 6.0 및 ASP.NET 3.0 기반의 WSS 3.0 아키텍처

그림 1** IIS 6.0 및 ASP.NET 3.0 기반의 WSS 3.0 아키텍처 **(더 크게 보려면 이미지를 클릭하십시오.)

다이어그램이 복잡하다고 걱정할 필요는 없습니다. 실제 구성 요소의 수를 고려하면 처음에는 아키텍처가 복잡해 보일 수 있지만, 이러한 구성 요소를 조직적으로 살펴보면 이 모든 구성 요소가 구성 요소 종속성을 자세히 분석할 수 있게 해주는 하나의 논리적 프레임워크로 결합된다는 것을 알 수 있습니다.

앞서 언급했듯이 SharePoint는 IIS 및 ASP.NET을 사용하여 HTTP 요청과 응답을 처리합니다. HTTP 커널 모드 드라이버(http.sys) 및 작업자 프로세스(w3wp.exe)와 같은 표준 IIS 구성 요소는 ASP.NET ISAPI 필터(aspnet_isapi.dll)에 도달할 때까지 초기에 요청을 큐에 대기시키고 라우팅합니다. .NET Framework를 설치할 때 설치 루틴은 다음과 같이 IIS 메타베이스(C:\Windows\System32\Inetsrv\metabase.xml)에 aspnet_isapi.dll을 등록합니다.

InProcessIsapiApps="C:\WINDOWS\system32\inetsrv\httpext.dll
C:\WINDOWS\system32\inetsrv\httpodbc.dll
C:\WINDOWS\system32\inetsrv\ssinc.dll
C:\WINDOWS\system32\msw3prt.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"

IIS에서 ASP.NET ISAPI 필터를 로드하면 웹 사이트에 대한 들어오는 모든 요청이 ASP.NET으로 전달될 수 있는데, 이 작업은 SharePoint가 ASP.NET을 통해 이 요청을 수신해야 하기 때문에 매우 중요합니다. 이 작업을 수행하기 위해 SharePoint는 파일 이름 확장명에 관계 없이 들어오는 모든 요청을 ASP.NET ISAPI 필터로 라우팅하는 와일드카드 응용 프로그램 맵을 추가하여 선택된 웹 사이트의 구성을 확장합니다.

이러한 확장은 기본 설치 옵션을 사용하여 WSS 3.0을 설치한 후 IIS 관리자에서 볼 수 있습니다. WSS 설치 루틴은 그림 2에서처럼 서버의 기존 기본 IIS 웹 사이트를 비활성화하고 ASP.NET 와일드카드 응용 프로그램 맵이 정의된 새 기본 웹 사이트를 포트 80에 만듭니다.

그림 2 ASP.NET ISAPI 필터에 대한 와일드카드 응용 프로그램 맵

그림 2** ASP.NET ISAPI 필터에 대한 와일드카드 응용 프로그램 맵 **(더 크게 보려면 이미지를 클릭하십시오.)

ASP.NET이 요청을 SharePoint로 전달하려면 SharePoint는 Microsoft.SharePoint 어셈블리에서 SPHttpApplication이라는 클래스를 사용하여 구현되는 사용자 지정 HttpApplication 개체를 통해 HTTP 요청 파이프라인도 확장해야 합니다. SharePoint는 이 사용자 지정 응용 프로그램 개체를 ASP.NET 응용 프로그램 파일(global.asax)에 정의합니다. 이 파일은 파일 시스템에서 SharePoint 확장 웹 사이트의 루트 폴더에 있습니다. 다음 코드는 global.asax 파일의 내용을 보여 줍니다.

<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>

ASP.NET은 이 파일을 동적으로 구문 분석하고 컴파일하여 SharePoint 응용 프로그램 개체를 인스턴스화합니다.

수신된 각 요청에 대해 ASP.NET은 BeginRequest, AuthenticateRequest, ProcessRequest, EndRequest 등 웹 응용 프로그램이 처리할 수 있는 일련의 이벤트를 트리거합니다. 이벤트 처리에 대한 자세한 내용은 SharePoint 배포 및 관리의 범위를 벗어나지만, global.asax에 지정된 SPHttpApplication 이외에도 SharePoint는 사이트의 web.config 파일에 정의된 사용자 지정 HTTP 처리기와 모듈을 구현한다는 점을 알아두어야 합니다. 예를 들어 SharePoint는 표준 ASP.NET 모듈 이전에 첫 번째 HTTP 모듈로 등록된 SPRequestModule 클래스 기반 HTTP 모듈을 사용합니다. SPRequestModule은 SPVirtualPathProvider 구성 요소를 ASP.NET에 등록하는 방법 등으로 SharePoint 런타임 환경을 초기화합니다. SPRequestModule은 SharePoint가 내부적으로 사용하기 위한 것이지만 SharePoint 솔루션 개발자는 web.config 파일을 수정하여 사용자 지정 HTTP 처리기 및 모듈과 같은 추가 구성 요소를 등록할 수 있습니다. 사용자 지정 HTTP 모듈 및 표준 HTTP 모듈을 통해 SharePoint는 SharePoint 응용 프로그램에 대한 모든 요청을 강력하게 제어하면서 ASP.NET의 이점을 활용할 수 있습니다.

SharePoint 3.0 중앙 관리 사이트를 사용하여 웹 응용 프로그램을 만들 때 WSS는 선택된 IIS 웹 사이트에 ASP.NET 와일드카드 응용 프로그램 맵을 추가하고 웹 사이트의 루트 폴더에 global.asax 및 web.config 파일을 만듭니다. 각각의 웹 응용 프로그램에서는 자체 최상위 global.asax 및 web.config 파일 집합을 사용합니다.

요청을 처리하고 의미 있는 정보를 브라우저에 반환하기 위해 WSS 3.0과 MOSS 2007에서는 요청된 ASP.NET 페이지를 컴파일하거나 이 페이지를 컴파일 없음 모드에서 처리하는 표준 ASP.NET 페이지 파서를 사용합니다. 하지만 SharePoint가 ASP.NET 파서로 전달하는 ASP.NET 페이지는 반드시 예상 위치에 있지는 않습니다. 예를 들어 SharePoint 3.0 중앙 관리 사이트와 같은 SharePoint 확장 웹 사이트의 루트 폴더에서 default.aspx 파일을 찾지 못할 수 있지만 해당 웹 사이트의 홈 페이지를 표시할 경우 default.aspx를 열 수 있습니다. 이것은 로컬 파일 시스템 또는 SQL Server 콘텐츠 데이터베이스에서 페이지 콘텐츠를 로드한 다음 이 콘텐츠를 ASP.NET 페이지 파서에 가상 파일로 전달하여 환경을 가상화하는 SPVirtualPathProvider 구성 요소입니다. 중앙 관리 사이트의 경우 SharePoint는 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin 폴더에서 default.aspx 파일을 로드합니다.

홈 페이지 및 대부분의 다른 SharePoint 사이트 페이지는 메뉴 및 탐색 컨트롤의 공통 레이아웃을 구성하는 ASP.NET 마스터 페이지(default.master)와 연결되어 있습니다. Default.master는 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Global 폴더에 있으며, 로컬 파일 시스템이나 SQL Server 콘텐츠 데이터베이스에 있을 수도 있는 추가적인 콘텐츠 페이지를 위한 명명된 자리 표시자를 포함합니다. 여기서 중요한 점은 웹 브라우저에서 SharePoint 사이트를 열 때 실제로 콘텐츠 페이지 모음의 정보가 표시되는데, 이 콘텐츠 페이지는 로컬 웹 서버에 없을 수도 있고 마스터 페이지에 정의된 레이아웃에 따라 정렬된다는 것입니다.

일반적으로 수정되지 않은 페이지(또는 SharePoint 용어로 사용자 지정되지 않은 페이지)는 모든 SharePoint 서버의 로컬 파일 시스템에 페이지 템플릿으로 존재하며, 사용자 지정된 페이지는 콘텐츠 데이터베이스에 기록되므로 웹 팜의 모든 SharePoint 서버가 같은 페이지 집합에 액세스할 수 있습니다(그림 3 참조). 사용자 지정되지 않은 페이지는 웹 팜의 모든 서버와 사이트에서 동일한 것으로 간주합니다. 하지만 Office SharePoint Designer 2007 등을 사용하여 SharePoint 사이트의 마스터 페이지 또는 콘텐츠 페이지를 사용자 지정하면 SharePoint는 자동으로 사용자 지정된 페이지를 콘텐츠 데이터베이스에 저장합니다.

그림 3 SharePoint 응용 프로그램의 사용자 지정 및 사용자 지정되지 않은 ASP.NET 페이지

그림 3** SharePoint 응용 프로그램의 사용자 지정 및 사용자 지정되지 않은 ASP.NET 페이지 **(더 크게 보려면 이미지를 클릭하십시오.)

사용자 지정된 페이지 및 기타 웹 사이트 콘텐츠뿐 아니라 SharePoint는 구성 데이터도 SQL Server 데이터베이스에 저장합니다. 구성 데이터는 실제로 글로벌 데이터인 반면 콘텐츠는 각 개별 웹 응용 프로그램과 사이트 모음에 따라 서로 다르므로 SharePoint는 구성 데이터와 콘텐츠를 따로 보관합니다. 따라서 웹 팜에 구성 데이터베이스는 하나만 있을 수 있지만 콘텐츠 데이터베이스는 여러 개 있을 수 있습니다.

웹 팜의 모든 WSS 서버는 동일한 구성 데이터베이스를 사용하여 웹 팜에서 SharePoint에 의해 확장된 모든 단일 IIS 웹 사이트에 대한 메타데이터, 구성 설정 및 정보를 공유합니다. 반면, 개별 웹 응용 프로그램은 하나 이상의 콘텐츠 데이터베이스에 연결될 수 있습니다. 이 경우에도 각 콘텐츠 데이터베이스는 하나의 웹 응용 프로그램에만 연결될 수 있습니다.

IIS 웹 사이트, 웹 응용 프로그램, 사이트 모음, 사이트 및 콘텐츠 데이터베이스 간의 관계가 혼동될 수 있습니다. SharePoint 용어에서 웹 응용 프로그램이라는 용어는 SharePoint 확장 IIS 웹 사이트를 의미합니다. 웹 응용 프로그램에는 여러 사이트 모음이 포함될 수 있으며 각 사이트 모음에는 같은 구성 설정을 공유하는 최상위 사이트와 하위 사이트가 포함될 수 있습니다.

여러 사이트 모음을 만들면 사이트 모음 관리를 다양한 사용자와 그룹에 위임할 수 있습니다. 단일 사이트 모음은 여러 콘텐츠 데이터베이스에 걸쳐 사용될 수 없지만 웹 응용 프로그램은 여러 사이트 모음에 대해 여러 콘텐츠 데이터베이스를 사용할 수 있으므로 확장성을 향상시키고 다른 SharePoint 사이트에 많은 양의 데이터베이스 작업을 생성하는 대규모 사이트의 성능 영향을 완화할 수 있습니다. 하지만 사이트 간 기능이 제한되기 때문에 각각의 SharePoint 사이트를 자체 사이트 모음에 두는 것은 좋지 않습니다.

WSS 3.0에서는 여러 사이트 모음에 대한 콘텐츠 검색 기능을 지원하지 않습니다. 이러한 검색 기능을 사용하려면 MOSS 2007 또는 Microsoft Search Server 2008이 필요합니다. 예를 들어 http://contoso에 대한 웹 응용 프로그램 및 최상위 사이트를 만든 다음 사이트 모음 관리자가 SharePoint 사용자 인터페이스를 사용하여 http://contoso/info 및 http://contoso/events와 같은 하위 사이트를 만들 수 있습니다. 이러한 사이트는 모두 같은 사이트 모음에 속하므로 같은 콘텐츠 데이터베이스에 존재합니다.

팜 관리자는 /sites와 같은 관리되는 경로를 사용한 다음 SharePoint 3.0 중앙 관리에서 http://contoso/sites/IT 및 http://contoso/sites/HR과 같은 추가 사이트 모음을 정의할 수 있습니다. 이 세 개의 사이트 모음(http://contoso, http://contoso/sites/IT 및 http://contoso/sites/HR)은 서로 다른 사이트 모음 관리자, 구성 설정 및 콘텐츠 데이터베이스를 가질 수 있지만 여전히 동일한 IIS 웹 사이트(http://contoso)를 통해 액세스되며 웹 응용 프로그램의 동일한 응용 프로그램 풀 ID를 사용합니다.

물론 더 많은 세부 내용이 있지만 IIS, ASP.NET 및 SQL Server 간의 이러한 관계는 SharePoint에 익숙해지기 위해 이해해야 하는 특히 중요한 내용입니다. SharePoint 아키텍처에 대한 자세한 내용을 보려면 Ted Pattison의 MSDN® Magazine 기사 "Discover Significant Developer Improvements in SharePoint Services"(msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview)를 참조하십시오.

SharePoint 인프라 요소

지금까지 아키텍처에 대해 간략하게 살펴보았으므로 이제 유연한 SharePoint 인프라에 대해 설명하겠습니다. 이미 알고 있듯이 Windows Server®, IIS, .NET Framework 3.0(ASP.NET 및 Windows® Workflow Foundation에 필요), WSS 3.0 또는 MOSS 2007 및 SQL Server가 필요합니다. Windows Server 2008에서 IIS 7.0을 사용하기를 원할 수 있지만 Windows Server 2003에서의 IIS 6.0이 이 글을 쓰는 현재 가장 많이 배포된 버전이므로 이 버전을 사용하겠습니다. 또한 초기 SharePoint 파일럿에는 MOSS 2007 특정 기능이 필요하지 않으므로 WSS 3.0을 사용합니다.

가장 간단한 구성 방식으로, WSS 3.0과 모든 필수 구성 요소를 단일 컴퓨터에 설치할 수 있습니다(이 칼럼의 첨부 자료인 WSS 3.0 on a single computer.pdf 참조). 이 구성은 랩 서버나 소규모 작업 그룹 환경에 적합합니다. 하지만 SharePoint 인프라의 유연성에 중점을 둘 경우 프로덕션 환경에서 독립 실행형 배포로 시작하지 않아야 합니다. 향후의 확장성과 가용성을 위해 다중 계층 인프라로 시작하여 필요에 따라 서버를 추가하는 것이 좋습니다.

그림 4에서는 간단하면서도 유연한 시스템 구성을 원하는 경우에 권장되는 SharePoint 인프라를 보여 줍니다. 이 인프라에는 두 SharePoint 서버로 구성된 웹 팜과 SQL Server를 실행하는 별도의 컴퓨터가 포함됩니다. 이 구성을 사용하면 웹 서버에서 데이터베이스 처리 오버헤드가 제거될 뿐 아니라 가용성과 확장성이 높아지고 시스템을 쉽게 유지 관리할 수 있습니다. Active Directory®는 웹 팜 배포에서 WSS 3.0의 소프트웨어 요구 사항이므로 반드시 설치해야 합니다. 단계별 배포 지침을 보려면 첨부 자료의 Basic SharePoint Infrastructure.pdf 파일을 참조하십시오.

그림 4 확장 가능한 기본 SharePoint 인프라

그림 4** 확장 가능한 기본 SharePoint 인프라 **(더 크게 보려면 이미지를 클릭하십시오.)

이 구성에서 SharePoint를 배포하는 데 사용하는 도메인 계정에는 웹 서버에 대한 로컬 관리자 권한이 있어야 합니다. 또한 Basic SharePoint Infrastructure.pdf에서 볼 수 있는 것처럼 SQL Server 2005에서 이 계정을 master 데이터베이스에 대한 데이터베이스 역할 db_owner와 SQL Server 역할 dbcreator 및 securityadmin에 추가해야 합니다. 그러면 WSS 3.0 설치 중에 SharePoint 제품 및 기술 구성 마법사를 사용하여 SharePoint 3.0 중앙 관리 사이트의 콘텐츠 데이터베이스와 웹 서버 팜에 필요한 구성 데이터베이스를 만들 수 있습니다. 그렇지 않은 경우에는 SQL Server 관리자가 이 데이터베이스를 준비하고 WSS 시스템 계정을 db_owner 역할에 추가해야 합니다.

SharePoint를 설치하는 데 사용하는 사용자 계정은 SharePoint가 중앙 관리 사이트의 콘텐츠 데이터베이스 또는 구성 데이터베이스에 액세스하는 데 사용하는 계정과 달라야 합니다. 대신 SharePoint는 SharePoint 3.0 중앙 관리 사이트의 응용 프로그램 풀 ID로 구성된 시스템 계정을 사용합니다.

SharePoint 제품 및 기술 구성 마법사에서는 계정 정보를 묻는 메시지를 표시합니다. 이 경우 CONTOSO\WssConfigAdmin과 같은 전용 도메인 사용자 계정을 사용하는 것이 좋습니다. 필자의 경우에는 일반적으로 나중에 만드는 모든 추가적인 웹 응용 프로그램에 대해 개별적인 전용 사용자 계정을 사용했습니다. 각 웹 응용 프로그램마다 별도의 응용 프로그램 풀을 사용하면 프로세스를 격리할 수 있으며 각 응용 프로그램 풀마다 서로 다른 사용자 계정을 사용하면 보안 격리를 유지할 수 있습니다. 하지만 이것은 하나의 구성 방식일 뿐이며 자신의 환경과 비즈니스 요구 사항에 따라 관리의 편의성과 잠재적인 성능 영향을 평가해야 합니다.

도메인 관리자가 만들어야 하는 또 다른 중요한 시스템 계정은 검색 서비스 계정입니다. 중앙 관리 계정을 사용할 수도 있지만 추가 보안을 위해서는 관리 권한이 없고 콘텐츠를 수정할 수 없는 CONTOSO\WssSearch와 같은 전용 검색 계정을 사용하는 것이 좋습니다. 검색 서비스는 인덱싱을 위해 콘텐츠를 탐색하고 별도의 데이터베이스에 검색 데이터를 유지하기만 하면 되므로 콘텐츠 데이터베이스에 대한 쓰기 권한은 필요하지 않습니다.

서버 팜에서 웹 응용 프로그램을 만들 경우 해당 콘텐츠 데이터베이스를 검색 서버와 연결할 수 있습니다. 그러면 해당하는 검색 서비스 계정이 웹 응용 프로그램의 전체 읽기 정책에 암시적으로 추가됩니다. 검색 서버는 Windows SharePoint Services 검색 서비스를 실행하는 SharePoint 서버입니다. Basic SharePoint Infrastructure.pdf 파일의 단계별 지침을 수행하면 두 웹 서버를 모두 검색 서버로 구성하여 여러 콘텐츠 데이터베이스를 탐색하고 인덱싱하는 작업의 부하를 분산시킬 수 있습니다. 하지만 탐색 작업이 클라이언트 연결에 영향을 미치지 않도록 클라이언트 연결 및 네트워크 부하 분산에서 제외된 전용 검색 서버를 웹 팜에 구성할 수도 있습니다.

셀프 서비스 사이트 관리

기본 SharePoint 인프라가 갖춰지면 Active Directory, 웹 서버 팜 또는 SQL Server 데이터베이스에 대한 관리 제어 권한을 분산시키지 않고도 사이트 모음 및 사이트의 관리를 개별 부서 및 사용자에게 위임할 수 있습니다. 팜 관리자는 Active Directory 및 SQL Server 관리자와 공동 작업하여 웹 응용 프로그램의 응용 프로그램 풀 계정과 콘텐츠 데이터베이스를 준비합니다. 그런 다음 이 웹 응용 프로그램 내에 사이트 모음을 만들고 사이트 모음 관리자에게 하위 사이트를 만들 수 있는 권한을 지정할 수 있습니다. 이러한 방법으로 개별 부서 내의 사이트 모음 관리자는 그림 5에서처럼 IT 부서와 관련된 작업을 최소화하면서 자체 SharePoint 리소스를 관리할 수 있습니다.

그림 5 중앙 집중화된 SharePoint 인프라의 분산된 사이트 관리

그림 5** 중앙 집중화된 SharePoint 인프라의 분산된 사이트 관리 **(더 크게 보려면 이미지를 클릭하십시오.)

또한 관리되는 경로(예를 들어 /sites 경로 또는 SharePoint 3.0 중앙 관리에서 만드는 와일드카드가 포함된 기타 관리되는 경로) 아래에 사이트 모음을 만들 수 있는 권한을 사용자에게 부여할 수 있습니다. 웹 응용 프로그램 내에서 셀프 서비스 사이트 관리 기능을 사용할 수 있도록 설정하면 사용자는 자체 사이트 모음을 만들고 SharePoint 사용자 인터페이스 내에서 사이트 그룹과 권한을 관리할 수 있습니다. 하위 사이트와 달리 사이트 모음은 부모 사이트에서 권한을 상속하지 않습니다.

셀프 서비스 사이트 관리가 모든 SharePoint 환경에 적합한 것은 아니므로 기본적으로는 사용하지 않도록 설정되어 있습니다. 사용하도록 설정할 경우 콘텐츠 데이터베이스에 자주 사용되지 않는 사이트 모음이 여러 개 만들어질 수 있습니다. 하지만 이 기능은 SharePoint 관리에 뛰어난 유연성을 제공하므로 파일럿 배포에서 확인하는 것이 좋습니다. 또한 SharePoint에는 사용자 또는 관리자에게 비활성 사이트에 대해 알림으로써 필요한 경우 해당 사이트를 제거할 수 있도록 하는 옵션도 있습니다. 첨부 자료의 Enabling Self-Service Site Management.pdf 파일에 설명된 것처럼 웹 응용 프로그램에 대한 셀프 서비스 사이트 관리를 사용하도록 명시적으로 설정해야 합니다.

SharePoint 사용자 지정 및 브랜딩

Sharepoint 리소스

이 단계에서 SharePoint 사용자 인터페이스에 회사 로고, 이름 및 색상을 추가하고 싶을 것입니다. 하지만 이제 SharePoint 프로젝트를 ASP.NET 개발자 수준으로 만들 것이라는 점에 유의하십시오. 프로덕션 환경에 영향을 주지 않으면서 사용자 지정을 만들고 테스트할 수 있도록 최소한 Microsoft Office SharePoint Designer 2007이 설치된 독립 실행형 WSS 3.0 서버와 같은 개발 시스템이 필요합니다(첨부 자료의 SharePoint Designer Installation.pdf 참조). 또한 Windows SharePoint Services Developer Center(msdn2.microsoft.com/sharepoint)를 방문하여 SharePoint가 제공하는 다양한 사용자 지정 옵션을 자세히 살펴보아야 합니다.

SharePoint 개발은 이 칼럼의 범위를 벗어나지만 몇 가지 고려해야 할 사항을 짚고 넘어가겠습니다. SharePoint는 사용자 지정된 페이지를 해당 사이트 모음의 콘텐츠 데이터베이스에 저장합니다. 즉, SharePoint 사이트에서 사이트 페이지, 응용 프로그램 페이지, 마스터 페이지, 스타일시트 등에 적용하는 모든 사용자 지정은 사이트 모음 또는 사이트 수준에서만 적용됩니다. 이러한 특성은 SharePoint Designer 2007을 사용하여 사이트의 모양과 느낌을 조정하려는 개별 사이트 모음 관리자에게는 매우 유용하지만 웹 팜의 모든 웹 응용 프로그램, 사이트 모음 및 사이트에 회사 이미지를 적용하려는 팜 관리자에게는 그다지 유용하지 않습니다.

표준 SharePoint 테마 또는 사이트 정의의 복사본을 기반으로 사용자 지정 사이트 테마 또는 사용자 지정 사이트 정의를 만들 수 있습니다. 또한 사용자 지정 마스터 페이지를 만들어 마스터 페이지 갤러리에 추가할 수 있습니다. 하지만 셀프 서비스 사이트 관리 기능을 사용하도록 설정한 경우 사이트 모음이나 사이트를 만들 수 있는 권한을 가진 사용자가 회사 이미지를 나타내지 않는 표준 사이트 템플릿을 선택할 수 있기 때문에 이러한 옵션은 글로벌 브랜딩을 적용하지 않습니다.

글로벌 브랜딩을 적용하려면 사용자 지정 구성 요소가 대신 사용되도록 기본 SharePoint 구성 요소를 대체해야 합니다. 개발자는 원본 파일을 수정하지 않고 효과적으로 이 작업을 수행할 수 있습니다. 한 가지 방법은 IIS 관리자에서 가상 디렉터리의 구성을 변경하여 사용자 지정된 파일이 있는 새 폴더를 가리키도록 하는 것입니다. 또 다른 방법은 특정 기본 페이지에 대한 요청을 사용자 지정된 버전으로 리디렉션하도록 URL을 다시 생성하는 사용자 지정 HTTP 모듈이나 ISAPI 필터를 구현하는 것입니다.

결론

WSS 3.0으로 SharePoint 인프라를 구축하는 데 반드시 알아야 할 내용을 집중적으로 살펴보았습니다. 워크플로, 설문 조사, 메시징 통합, 바이러스 차단과 같은 기타 기능과 포털, 사이트 디렉터리, 비즈니스 데이터 카탈로그와 같은 MOSS 2007 특정 기능에 대해서는 다루지 않았습니다. 또한 사이트 관리 및 회사 브랜딩의 사용자 지정에 대해서도 SharePoint 내에서의 가능성 정도만 간략하게 다루었습니다. Visual Studio®에서 사용자 지정 응용 프로그램을 프로그래밍하면 WSS 3.0으로 더 강력한 사용자 지정을 구현할 수 있습니다.

웹 서버나 데이터베이스 서버를 더 추가할 경우에도 인프라는 이러한 확장을 충분히 처리할 수 있을 만큼 강력합니다. 또한 몇 가지 사용자 지정에 대한 파일럿 배포를 통해 사용자는 개별 사이트를 만들고 SharePoint에 익숙해질 수 있습니다. 이러한 방식으로 하드웨어 및 소프트웨어뿐만 아니라 사용자가 채택한 핵심 구성 요소를 구축함으로써 완전한 프로덕션 배포의 기본을 제공하고 변화에 충분히 대처할 수 있는 유연한 인프라를 구현할 수 있습니다.

Pav Cherny는 공동 작업 및 통합 커뮤니케이션을 위한 Microsoft 기술을 전문으로 하는 IT 전문가이자 저술가입니다. IT 운영과 시스템 관리를 주로 다루는 서적, 백서, 제품 설명서 등을 출간한 Pav는 Biblioso Corporation의 회장직을 맡고 있습니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..