SharePoint Server 디자인 샘플: 회사 포털 및 엑스트라넷 사이트

아티클
03/08/2023

적용 대상: yes-img-13 2013 yes-img-16 2016 yes-img-19 2019 yes-img-se Subscription Edition no-img-sop SharePoint in Microsoft 365

이 문서에서는 SharePoint 사이트의 기준 아키텍처로 사용할 수 있는 여러 디자인 예제에 대해 설명합니다. 이 문서에서 설명하는 디자인 예제는 회사나 조직 내에서 배포되는 가장 일반적인 유형의 SharePoint 사이트용 표준 아키텍처를 보여줍니다.

중요

이 문서의 정보는 SharePoint Foundation 2013 및 SharePoint Server에 적용됩니다. 그러나 이 문서에서는 SharePoint Foundation 2013에서는 사용할 수 없는 내 사이트 및 엔터프라이즈 검색과 같은 특정 기능에 대해서도 설명합니다.

디자인 예제 정보

이 문서에서는 다음과 같은 디자인 예제에 대해 설명합니다.

가상의 회사인 Fabrikam, Inc.의 사이트를 보여주는 이 문서의 디자인 예제는 거의 모든 논리 아키텍처 구성 요소에 적용되며, 이러한 구성 요소를 전체 디자인에 통합하는 방법을 보여줍니다. 이 문서에서는 예제의 디자인 목표는 물론 예제에 나와 있는 논리 아키텍처 구성 요소를 사용하여 이러한 목표를 달성하는 방법에 대해서도 설명합니다.

참고

이 모델의 제목에는 SharePoint 2013이 포함되어 있지만 SharePoint Server 2016에도 적용됩니다.

회사 포털 디자인 예제 - 2개 버전

SharePoint Server의 호스트 이름으로 된 사이트 모음은 단일 웹 응용 프로그램 내의 사이트 URL 관리 및 확장성 기능을 제공합니다. 회사 포털 디자인 예제의 2개 버전에서는 일반적인 경로 기반 사이트 모음 또는 호스트 이름으로 된 사이트 모음 사용을 기반으로 하는 구현을 보여줍니다. 이 두 디자인 예제에서는 모두 단일 영역에서 클레임 기반 인증을 사용합니다. 이 문서 뒷부분에서 이러한 예제에 대해 보다 자세하게 설명합니다.

대체 액세스 매핑을 사용하는 경로 기반 사이트가 요구 사항에 없는 경우 호스트 이름으로 된 사이트 모음을 기반으로 하는 디자인을 사용하는 것이 좋습니다(자세한 내용은 Host-named site collection architecture and deployment (SharePoint 2013) 참조). 이 디자인은 Microsoft 365 환경에서 사용하는 것과 동일한 아키텍처이므로 권장됩니다. 따라서 가장 많이 테스트된 구성입니다. 앱 모델 및 요청 관리를 비롯한 새 기능은 이 구성에 최적화되어 있으며 앞으로도 가장 안정적인 구성입니다.

인증 전용 영역을 포함하는 엑스트라넷

인증용 전용 영역이 있는 엑스트라넷 디자인 샘플에는 파트너 웹 사이트만 포함됩니다. 각 인증 방법에 전용 영역이 사용되는 파트너 협업을 위한 대체 구성을 제공합니다. 각 디자인 샘플은 웹 애플리케이션에 클레임 모드 인증을 사용합니다. 회사 포털 디자인 샘플과 엑스트라넷 디자인 샘플의 차이점은 영역을 구성하는 방법입니다. 인증용 전용 영역이 있는 엑스트라넷 디자인 샘플은 여러 영역을 사용하며 각 영역에 대해 하나의 인증 방법이 구성됩니다. 회사 포털 디자인 샘플은 하나의 영역을 사용하며 여러 인증 방법이 서로 다른 사용자 클래스에 대해 구성됩니다.

인증 전용 영역을 포함하는 엑스트라넷 디자인 예제에는 원격 직원 액세스를 위한 새로운 권장 사항인 Windows Server 2012를 통한 직접 액세스 기능도 적용되어 있습니다. 이 권장 사항 대신 VPN(가상 사설망)을 만들어도 됩니다. 원하는 경우에는 방화벽이나 게이트웨이 제품에서 양식 기반 인증을 사용하여 자격 증명을 수집 및 전달할 수도 있습니다.

디자인 예제에서 사이트 모음을 구현한 방식

이전 버전의 회사 포털 디자인 예제에서는 경로 기반 사이트 모음을 사용했던 반면, AAM(대체 액세스 매핑) 기능이 포함된 기존의 경로 기반 사이트 모음을 사용해야 한다는 요구 사항이 지정되어 있는 경우(이 문서 뒷부분에서 설명함)를 제외하면 새로운 호스트 이름으로 된 사이트 모음을 사용하는 것이 좋습니다. 이러한 내용은 다음과 같은 방식으로 디자인 예제에 반영되어 있습니다.

경로 기반 사이트 모음을 포함하는 회사 포털 - 이 예제에서는 사이트가 전용 웹 응용 프로그램으로 구성되며 웹 응용 프로그램당 최상위 사이트 모음이 하나 있는 기존 방식의 경로 기반 사이트 모음을 보여줍니다. 여러 웹 응용 프로그램을 각각 별도의 응용 프로그램 풀에서 사용함으로써 보안을 강화하려면 이 방식을 사용하세요.
호스트 이름으로 된 사이트 모음을 포함하는 회사 포털 - 이 예제에서는 팜의 단일 웹 응용 프로그램에서 모든 사이트가 배포되는 호스트 이름으로 된 사이트 모음을 사용하는 방식을 보여줍니다. 이 방법은 확장성이 뛰어나며 URL을 보다 유동적으로 관리할 수 있습니다.
인증 전용 영역이 있는 엑스트라넷 — 이 샘플에서는 최상위 사이트 모음 아래에 프로젝트 사이트를 구성하는 대신 각 프로젝트 사이트에 호스트 이름이 지정된 사이트를 사용하여 베니티 URL이 있는 많은 최상위 프로젝트 사이트를 보여 줍니다. 이러한 방식으로 호스트 이름이 지정된 사이트 모음을 사용하는 한 가지 이점은 파트너 공동 작업 솔루션에서 원할 수 있는 도메인 URL 간에 추가 격리를 만드는 것입니다. 그러나 이 방법의 단점은 SSL 인증서 관리를 포함하여 더 많은 수의 호스트 이름을 관리하는 추가 비용입니다. 또한 SAML 인증을 사용하는 경우 추가 구성이 필요합니다(이 문서의 뒷부분에 있는 "호스트 이름 사이트에서 SAML 인증 사용"참조).

SharePoint Server의 클레임 기반 인증

SharePoint Server에서 인증이 작동하는 방식은 이러한 디자인 예제로 표시되는 선택 항목 구현과 관련된 디자인 결정 사항에 영향을 줄 수 있습니다. 아래에 몇 가지 예가 나와 있습니다.

SharePoint Server에서는 클레임 기반 인증이 기본 모드이며 중앙 관리를 통해 사용 가능한 옵션 역시 클레임 기반 인증뿐입니다. 클래식 모드 인증은 PowerShell을 사용하여 구현할 수 있습니다.
SharePoint Server에서는 부하 분산 장치에 대해 SAML 클레임 인증을 사용하도록 서버 선호도를 구성할 필요가 없습니다. SharePoint Server에서는 선호도가 지정되지 않은 부하 분산도 완전하게 지원됩니다.

SharePoint Server에서 검색 크롤링 계정은 Windows 통합 인증(NTLM 또는 Kerberos)을 사용하여 기본 영역을 통해 콘텐츠에 액세스할 수 있어야 합니다. 클레임 인증을 사용하는 경우 단일 영역에서 여러 인증 유형이 허용되므로 이 요구 사항은 다른 인증 요구 사항에 영향을 주지 않습니다.

디자인 예제 기능 요약

다음 표에서는 이 문서에서 설명하는 세 가지 디자인 예제에 대해 간략하게 설명합니다.

표: 디자인 예제 요약

디자인 예제	포함 항목	주요 디자인 요소
경로 기반 사이트를 포함하는 회사 포털	조직 내에서 배포되는 가장 일반적인 유형의 사이트	경로 기반 사이트 모음 클레임 기반 인증 단일 영역에서 여러 인증 공급자 및 인증 유형이 구현됨
호스트 이름으로 된 사이트를 포함하는 회사 포털	조직 내에서 배포되는 가장 일반적인 유형의 사이트	호스트 이름으로 된 사이트 모음 클레임 기반 인증 단일 영역에서 여러 인증 공급자 및 인증 유형이 구현됨
인증 전용 영역을 포함하는 엑스트라넷	파트너 웹 사이트만 포함됨. 파트너 공동 작업을 위한 대체 구성을 제공합니다.	호스트 이름으로 된 사이트 모음 클레임 기반 인증 각 인증 방법에 대해 서로 다른 영역 사용

디자인 예제에 포함되는 사이트

이 섹션에서는 디자인 예제에 포함되는 최상위 사이트에 대해 설명합니다.

인트라넷 사이트

회사 포털에는 인트라넷에서 사용하기 위한 다음 사이트가 포함됩니다.

게시된 인트라넷 콘텐츠(예: HRweb)
공동 작업 팀 사이트
내 사이트

직원은 이러한 모든 콘텐츠 및 공동 작업 사이트를 매일 사용하게 됩니다. 이러한 개별 응용 프로그램은 서로 다른 콘텐츠 형식을 나타냅니다. 각 콘텐츠 형식의 속성은 다음과 같습니다.

SharePoint Server의 다른 기능을 강조해서 나타냅니다.
데이터 특징이 서로 다른 데이터를 호스트합니다.
서로 다른 사용 프로필에 종속됩니다.
서로 다른 사용 권한 관리 전략이 필요합니다.

따라서 이러한 각 응용 프로그램의 성능과 보안이 최적화되도록 각 응용 프로그램을 디자인해야 합니다.

서비스 응용 프로그램을 디자인하면 이러한 세 응용 프로그램을 통합하여 다음 기능을 제공할 수 있습니다.

엔터프라이즈 전체 검색
공유 프로필 데이터 및 엔터프라이즈 메타데이터

경로 기반 사이트 모음 디자인 예제의 회사 포털이 나와 있는 아래 그림에서는 회사 인트라넷을 구성하는 세 가지 사이트 유형을 보여줍니다.

회사 인트라넷을 구성하는 사이트 유형

인트라넷 사이트

파트너 웹 응용 프로그램

파트너 웹 응용 프로그램은 파트너 회사 및 개별 파트너와 안전하게 공동 작업할 수 있는 외부에서 사용 가능한 사이트를 호스트합니다. 직원은 이 응용 프로그램을 사용하여 보안이 유지되는 공동 작업 사이트를 손쉽게 만들 수 있습니다. 파트너는 서버 팜에서 호스트되는 다른 콘텐츠에 액세스할 수 없습니다. 영역 및 서비스 응용 프로그램 디자인에서는 이러한 목표를 다룹니다. 또한 개별 사이트 소유자는 공동 작업 시에 필요한 참가자만 초대함으로써 사이트의 사용 권한을 관리합니다.

엑스트라넷 디자인 예제에서 표시되는 사이트는 이 유형의 사이트뿐입니다.

전체 디자인 목표

이 디자인 예제에서는 여러 일반적인 유형의 사이트 내에 SharePoint Server의 기능을 실제로 구현합니다. 이 문서에서는 개별 응용 프로그램의 디자인 구현에 대해 설명합니다. 이 디자인 예제의 주요 디자인 목표는 다음과 같습니다.

확장 가능한 환경을 디자인하는 프레임워크를 만듭니다.

개별 사이트 유형의 디자인 관련 사항을 결정할 때 다른 사이트 유형을 추가할 수 있게 해야 합니다. 예를 들어 초기 배포에는 공동 작업 팀 사이트만 포함되거나 인트라넷을 구성하는 3가지 사이트 유형(팀 사이트, 내 사이트 및 게시된 인트라넷 콘텐츠)만 포함될 수 있습니다. 비슷한 논리 아키텍처 디자인을 사용하면 초기 솔루션의 디자인에 영향을 주지 않고도 솔루션에 사이트를 추가할 수 있습니다. 즉, 환경을 사용하는 방법을 제한하는 요소는 디자인에 포함하지 않아야 합니다.
서로 다른 유형의 사이트 내에서 콘텐츠 보안을 그대로 유지하면서 여러 사용자 그룹에게 액세스 권한을 제공합니다.

서로 다른 인증 공급자를 사용하는 서로 다른 네트워크 영역(내부 및 외부)의 사용자가 공동 작업에 참여할 수 있습니다. 또한 사용자는 액세스하려는 콘텐츠에만 액세스할 수 있습니다. 비슷한 논리 아키텍처 디자인을 따르는 경우 여러 위치에 있고 목표가 다른 사용자에게 액세스를 제공할 수 있습니다. 예를 들어 초기 디자인은 내부 직원 액세스 전용일 수 있습니다. 그러나 비슷한 디자인을 사용하는 경우 원격 직원, 파트너 직원, 파트너 회사 및 고객에 대한 액세스를 사용하도록 설정할 수도 있습니다.
엑스트라넷 환경에서 해당 디자인을 사용할 수 있어야 합니다.

경계 네트워크에 솔루션을 안전하게 배포할 수 있도록 주의 깊게 디자인해야 합니다.

이 문서의 나머지 부분에서는 디자인 예제에 나타나는 각 논리적 구성 요소를 위쪽부터 아래쪽으로 설명하고 디자인 예제에 적용되는 디자인 선택 사항에 대해 논의합니다. 이런 식으로 설명하는 목적은 응용 프로그램에 따라 논리 아키텍처 구성 요소를 구성할 수 있는 다양한 방법을 보여주기 위한 것입니다.

서버 팜

이 섹션에서는 디자인 예제에 나와 있는 서버 팜의 토폴로지 및 단일 팜보다 크게 확장하는 방법에 대해 설명합니다.

서버 팜의 토폴로지

디자인 예제의 각 서버 팜은 다음과 같은 내결함성 토폴로지가 사용된 서버 6대로 구성되어 있습니다.

프런트 엔드 웹 서버 2대
응용 프로그램 서버 2대
SQL Server 클러스터링, 미러링 또는 Always On 지원하도록 SQL Server 설치되고 구성된 두 개의 데이터베이스 서버입니다. Always On 2012년 SQL Server 필요합니다.

프런트 엔드 및 애플리케이션 서버의 개념은 SharePoint Server 2016에서 다릅니다. SharePoint Server의 MinRole 서버 역할 개요를 참조하세요.

이 디자인 예제에서는 다음과 같은 SharePoint Server의 논리 아키텍처를 보여줍니다.

모든 사이트가 프런트 엔드 웹 서버 간에 미러링됩니다.
사용자가 직접 액세스할 수 없도록 중앙 관리 사이트가 응용 프로그램 서버에 설치됩니다.

실제 환경에서 서버 컴퓨터의 수와 서버 팜의 토폴로지는 용량과 성능을 높이려는 경우에만 중요합니다. 논리 아키텍처는 서버 팜 토폴로지에 관계없이 디자인할 수 있습니다. 성능 및 용량 계획을 세우면 성능 및 용량 목표에 맞게 서버 팜의 규모를 결정하는 데 도움이 됩니다. 자세한 내용은 SharePoint Server 2013에서 계획 하는 성능에 대 한 계획을 참조하세요.

사용자, 영역 및 인증

SharePoint Server의 기본 인증 모드는 클레임이며, 각 디자인 예제에는 클레임 기반 인증이 통합되어 있습니다. Windows PowerShell을 사용하여 클래식 모드 인증을 구현할 수 있지만, 클래식 모드에서는 일부 SharePoint Server 기능을 사용할 수 없습니다. 클래식 모드 인증이 통합되어 있는 디자인 예제에 대한 자세한 내용은 디자인 예제: 회사 배포(SharePoint Server 2010)를 참조하세요.

다음 표에는 회사 포털 디자인 예제 및 엑스트라넷 디자인 예제로 표시되는 두 가지 방식의 차이점이 나와 있습니다.

표: 디자인 예제의 영역 구성 방식 비교

방법	호스트 이름으로 된 사이트를 포함하는 회사 포털/경로 기반 사이트를 포함하는 회사 포털	인증 전용 영역을 포함하는 엑스트라넷
인증 모드	클레임	클레임
영역 구성	여러 인증 방법을 사용하는 단일 영역이 각 사용자 클래스에 대해 구성됩니다.	한 가지 인증 방법을 사용하는 여러 영역이 각 영역에 대해 구성됩니다.
URL	모든 사용자 클래스가 각 사이트에 대해 동일한 URL을 사용합니다. 직원은 회사 네트워크 내부에 있든 원격으로 작업하든 관계없이 같은 URL을 사용합니다.	각 사용자 클래스가 서로 다른 URL을 사용하여 사이트에 액세스합니다. 직원은 회사 네트워크 내부에 있는지 원격으로 작업하는지에 따라 다른 URL을 사용합니다.
내부 요청	회사 네트워크 내부에서 생성되는 요청은 네트워크 외부로 라우팅된 다음 게이트웨이 또는 프록시 서버를 통해 다시 네트워크 내부로 라우팅됩니다. SSL(Secure Sockets Layer) 프로토콜을 통해 이러한 요청을 보호합니다. 분할 DNS를 사용하여 요청을 서버의 내부 인터페이스로 직접 라우팅할 수도 있습니다.	회사 네트워크 내부에서 생성되는 요청은 네트워크 내부에서 유지됩니다.
사용자 환경	모든 사용자에게 로그인할 때 사용할 계정 유형을 선택하라는 메시지가 표시됩니다.	인증 방법은 미리 결정됩니다. 사용자는 로그온 페이지를 사용하여 계정 유형을 선택할 필요가 없습니다.

다음 섹션에서는 두 가지 다른 방식을 사용하여 인증을 통합하는 방법에 대해 구체적으로 설명합니다.

전용 영역을 포함하는 엑스트라넷 디자인 예제

엑스트라넷 디자인 샘플은 세 가지 다른 사용자 클래스를 보여 줍니다. 각 클래스는 다른 영역에 할당됩니다. 각 웹 애플리케이션 내에서 사용 가능한 영역 이름(기본값, 인트라넷, 인터넷, 사용자 지정 또는 엑스트라넷) 중 하나를 사용하여 최대 5개의 영역을 만들 수 있습니다. 검색 크롤링 계정에는 디자인 샘플에서 고려되는 NTLM(통합 Windows 인증 또는 Kerberos 프로토콜)을 사용하여 기본 영역에 액세스해야 합니다. 다음 표에서는 엑스트라넷 디자인 샘플에서 영역을 설정하는 방법을 보여 줍니다.

표: 엑스트라넷 디자인 예제에 설명된 영역, 사용자 및 인증 유형

영역	사용자	인증
인트라넷	내부 직원 및 원격 직원 검색 크롤링 계정	NTLM 또는 Kerberos 프로토콜 직접 액세스 또는 VPN을 사용하여 연결하는 원격 직원
기본	개별 파트너	옵션: 양식 기반 인증을 사용하는 LDAP 디렉터리 내부 포리스트에 대한 단방향 트러스트와 Windows 통합 인증을 사용하는 외부 연결 AD DS(Active Directory 도메인 서비스) 포리스트 SAML 인증을 사용하는 신뢰할 수 있는 ID 공급자
엑스트라넷	파트너 회사	SAML 인증을 사용하는 신뢰할 수 있는 파트너 ID 공급자

회사 포털 디자인 예제

클레임 기반 인증을 사용하면 동일한 영역에서 여러 인증 유형을 사용할 수 있습니다. 회사 포털 디자인 예제의 두 버전에서는 모든 인증 유형에 대해 기본 영역을 사용합니다.

다음 표에서는 디자인 예제에 설명된 영역, 사용자 및 인증 유형을 보여줍니다.

표: 회사 포털 디자인 예제에 설명된 영역, 사용자 및 인증 유형

영역	사용자	공급자 및 인증 유형
기본	내부 직원 및 원격 직원	AD DS(Active Directory 도메인 서비스) 또는 양식 기반 인증이나 SAML 인증을 사용하는 LDAP 저장소
기본	개별 파트너	SAML 인증을 사용하는 신뢰할 수 있는 ID 공급자 또는 양식 기반 인증을 사용하는 SQL Server 데이터베이스
기본	파트너 회사	SAML 인증을 사용하는 신뢰할 수 있는 파트너 ID 공급자
기본	검색 크롤링 계정	Windows NTLM 인증을 사용하는 AD DS

디자인 샘플에서 게시된 인트라넷 콘텐츠 사이트, 팀 사이트 및 내 사이트는 네트워크 내부 또는 외부에 있는 직원만 액세스할 수 있습니다. 디자인 샘플은 내부 및 외부에서 모두 사용할 수 있는 이러한 각 사이트에 대해 하나의 URL(SSL 사용)만 구현합니다. AD DS 계정이 사용됩니다. 필요한 경우 양식 기반 인증 또는 SAML은 추가 구성이 필요한 LDAP를 사용할 수 있습니다.

이 디자인 예제에서 파트너 웹 응용 프로그램은 파트너 직원 및 파트너 회사에서 액세스할 수 있는 엑스트라넷 사이트를 나타냅니다. 이 시나리오에서 클레임 기반 인증을 사용하려면 외부 ID 공급자 하나 이상과의 트러스트를 구성해야 합니다. 이 경우 다음과 같은 방식 중 하나를 사용할 수 있습니다.

파트너 디렉터리에 직접 인증하기 위해 파트너 회사에 있는 공급자 등의 외부 ID 공급자를 신뢰하도록 SharePoint 팜을 구성할 수 있습니다.
회사 환경 내의 ID 공급자가 외부 ID 공급자를 신뢰하도록 구성할 수 있습니다. 두 조직의 관리자가 이 관계를 명시적으로 설정해야 합니다. 이 시나리오에서 SharePoint 팜은 자체 회사 환경 내의 ID 공급자를 신뢰합니다. ID 공급자가 토큰을 보내면 팜은 트러스트 설정 시 지정된 토큰 서명 인증서를 사용하여 토큰 유효성을 확인합니다. 이 방식을 사용하는 것이 좋습니다.

클레임 기반 환경 대신 양식 기반 인증을 사용하여 파트너를 인증할 수 있습니다. 데이터베이스 등의 개별 저장소를 사용하여 이러한 계정을 관리합니다.

영역

영역을 디자인할 때는 성공적인 배포를 위해 몇 가지 주요 사항을 결정해야 합니다. 이러한 사항에는 다음 영역에 대한 디자인 및 구성 결정 사항이 포함됩니다.

기본 영역
외부 액세스용 영역

다음 섹션에서는 이 디자인 예제에 통합된 결정 사항에 대해 설명합니다.

기본 영역의 구성 요구 사항

가장 주의 깊게 고려해야 하는 영역은 기본 영역입니다. SharePoint Server에서는 기본 영역을 구성하는 방법에 다음과 같은 요구 사항을 적용합니다.

사용자 요청을 특정 영역에 연결할 수 없는 경우 기본 영역의 인증 및 정책이 적용됩니다. 따라서 기본 영역은 가장 보안이 강화된 영역이어야 합니다.
관리 메일 메시지는 기본 영역의 링크를 포함합니다. 여기에는 할당량 제한에 도달한 사이트 소유자에 대한 메시지가 포함됩니다. 따라서 이러한 종류의 메시지 및 알림을 받는 사용자는 기본 영역을 통해 링크에 액세스할 수 있어야 합니다. 이는 사이트 소유자에게 특히 중요합니다.

SharePoint Server에서는 모든 영역에서 호스트 이름으로 된 사이트 모음에 액세스할 수 있습니다.

엑스트라넷 환경에 대한 영역 구성

엑스트라넷 환경에서는 다음과 같은 두 가지 이유로 인해 영역 디자인이 중요합니다.

서로 다른 여러 네트워크에서 사용자 요청이 시작될 수 있습니다. 이 디자인 예제에서는 사용자 요청이 내부 네트워크, 인터넷 및 파트너 회사에서 시작됩니다.
사용자가 여러 웹 응용 프로그램의 콘텐츠를 이용합니다. 이 디자인 예제에서 인트라넷은 3개 웹 응용 프로그램으로 구성되어 있습니다. 또한 내부 직원과 원격 직원은 파트너 웹 응용 프로그램에서 콘텐츠를 제공 및 관리할 수 있습니다.

엑스트라넷 환경에 영역이 둘 이상 포함되는 경우에는 다음과 같은 디자인 원칙을 따라야 합니다.

여러 웹 응용 프로그램에서 영역을 서로 동일하게 구성합니다. 인증 구성과 의도한 사용자가 같아야 합니다. 그러나 영역에 연결된 정책은 웹 응용 프로그램에 따라 다를 수 있습니다. 예를 들어 인트라넷 영역은 모든 웹 응용 프로그램에서 동일한 직원용으로 사용되어야 합니다. 즉, 인트라넷 영역을 특정 웹 응용 프로그램에서는 내부 직원용으로 구성하고 다른 웹 응용 프로그램에서는 원격 직원용으로 구성하면 안 됩니다.
경로 기반 사이트 모음을 사용하는 경우 각 영역과 각 리소스에 대해 대체 액세스 매핑을 적절하고 정확하게 구성합니다. 영역을 만들면 대체 액세스 매핑이 자동으로 만들어집니다. 그러나 SharePoint Server에서 파일 공유 등의 외부 리소스에 있는 콘텐츠를 크롤링하도록 구성할 수 있습니다. 대체 액세스 매핑을 사용하여 각 영역에 대해 이러한 외부 리소스로의 링크를 수동으로 만들어야 합니다.
호스트 이름으로 된 사이트 모음을 사용하는 경우에는 PowerShell에서 URL을 적절한 영역에 매핑합니다.

웹 응용 프로그램 간에 영역이 서로 다르고 외부 리소스에 대한 링크가 적절하지 않으면 다음과 같은 위험이 따를 수 있습니다.

서버 이름, DNS(Domain Name System) 이름 및 IP 주소가 내부 네트워크 바깥으로 노출될 수 있습니다.
사용자가 웹 사이트 및 기타 리소스에 액세스하지 못할 수 있습니다.

호스트 이름으로 된 사이트에서 SAML 인증 사용

호스트 이름으로 된 사이트에서 SAML 인증을 사용하는 디자인의 경우에는 각 베니티 URL에 다음 항목이 필요합니다.

SPTrustedIdentityTokenIssuer 의 새로운 영역
ID 공급자의 해당 신뢰 당사자

서비스

서비스 아키텍처는 디자인 예제에 따라 다릅니다. 호스트 이름으로 된 사이트를 포함하는 회사 포털 디자인 예제에는 서비스를 위한 가장 간단한 아키텍처가 포함되어 있습니다. 이 디자인 예제에서는 서비스 응용 프로그램 그룹(프록시 그룹이라고도 함)을 하나만 포함할 수 있는 웹 응용 프로그램 하나를 사용하기 때문입니다.

경로 기반 사이트를 포함하는 회사 포털 예제에서는 파트너 사이트에 대해 분할된 서비스를 사용하여 프로젝트 간에 데이터를 격리합니다. 이 디자인 예제에는 2개의 서비스 그룹(인트라넷 사이트용 그룹 하나, 파트너 공동 작업 사이트용 그룹 하나)이 통합되어 있습니다. Managed Metadata Service 및 Search Service의 개별 인스턴스가 파트너 사이트에 대해 배포되며, 이러한 서비스는 각각 분할됩니다. 분할된 서비스를 사용하려면 구독 설정 서비스가 필요한데, 이 서비스는 PowerShell을 통해서만 배포할 수 있습니다.

경로 기반 사이트를 포함하는 회사 포털용 서비스 아키텍처

서비스 아키텍처

분할된 서비스를 배포하면 아키텍처가 복잡해지며 나중에 사이트를 Microsoft 365로 마이그레이션하기가 어렵습니다. 파트너 사이트에 대해 사용할 수 있는 보다 간단한 옵션은 Managed Metadata Service 및 Search Service의 분할되지 않은 전용 인스턴스(이러한 서비스를 분리해야 하는 경우)를 배포하는 것입니다. 대부분의 조직은 Search Service의 전용 인스턴스를 배포하기보다는 Search Service의 보안 조정 기능을 사용합니다.

엑스트라넷 디자인 예제에는 프록시 그룹이 하나만 포함되지만, Managed Metadata Service 및 Search Service 응용 프로그램 둘 다에 대해 분할된 서비스도 사용됩니다.

서비스 응용 프로그램을 배포하기 위한 주요 디자인 결정 사항은 조직 분류를 배분하는 범위입니다. 서비스 아키텍처를 간소화하려면 모든 웹 응용 프로그램에서 Managed Metadata Service, User Profile Service 및 Search Service를 공유하고 보안 조정을 활용하여 콘텐츠에 대한 액세스를 관리합니다. 경로 기반 사이트를 포함하는 회사 포털 디자인 예제에서는 모든 사이트에서 Managed Metadata Service 인스턴스 하나를 공유합니다. 하지만 이 구성에서는 모든 사용자가 회사 분류에 액세스할 수 있습니다. 솔루션 설계자는 여러 개의 Managed Metadata Service 인스턴스를 구현할지 여부를 결정해야 합니다. 또한 사용자 프로필 데이터를 공유하는 범위도 결정해야 합니다.

경로 기반 사이트 모음을 포함하는 회사 포털 예제에서는 파트너 웹이 사용자 지정 서비스 그룹을 통해 전용 Search Service 및 Managed Metadata Service 응용 프로그램을 사용하도록 구성됩니다. 다른 서비스 응용 프로그램은 사용자 지정 그룹에 추가되며 기본 그룹과 공유됩니다. 파트너 사용자가 조직의 사용자 데이터를 검색할 수 없도록 하기 위해 이 디자인 예제에는 User Profile Service 응용 프로그램이 포함되어 있지 않습니다.

호스트 이름으로 된 사이트 모음을 포함하는 회사 포털의 단순화된 아키텍처(서비스 그룹 하나)에서는 파트너가 전체 회사 분류에 액세스하고 조직에서 사용자 데이터를 검색할 수 있습니다. 하지만 검색 결과는 파트너가 액세스할 수 있는 사이트 및 콘텐츠로 제한됩니다.

파트너 사이트에서 프로젝트 간에 콘텐츠를 격리해야 하는 경우에는 이 문서에서 설명하는 것처럼 전용 서비스 응용 프로그램을 배포하는 것이 좋습니다. 이렇게 하면 서비스 아키텍처가 더 복잡해지기는 하지만 파트너가 인트라넷 콘텐츠와 연결된 메타데이터 또는 파트너 웹 사이트 내의 다른 프로젝트에 액세스할 수 없게 됩니다. 또한 엑스트라넷 디자인 예제에서는 분할된 서비스를 사용합니다.

관리 사이트

디자인 샘플에서 애플리케이션 서버는 각 서버 팜에 대한 SharePoint 중앙 관리 웹 사이트를 호스트합니다. 이렇게 하면 사이트가 직접 사용자 연락처로부터 보호됩니다. 성능 병목 상태 또는 보안 손상이 프런트 엔드 웹 서버의 가용성에 영향을 주는 경우 SharePoint 중앙 관리 웹 사이트를 계속 사용할 수 있습니다.

디자인 예제 및 이 문서에서는 관리 사이트용 부하 분산된 URL에 대해서는 설명하지 않습니다. 다음과 같은 지침을 따르는 것이 좋습니다.

관리 URL이 포트 번호를 사용하는 경우 비표준 포트를 사용합니다. URL에는 기본적으로 포트 번호가 포함됩니다. 고객이 연결하는 URL은 대개 포트 번호를 포함하지 않지만, 관리 사이트에 포트 번호를 사용하면 사이트 액세스를 비표준 포트로만 제한함으로써 보안을 강화할 수 있습니다.
관리 사이트에 대한 별도의 DNS 항목을 만듭니다.

이러한 지침을 따르는 것 외에도 원하는 경우 여러 응용 프로그램 서버 간에 SharePoint 중앙 관리 웹 사이트의 부하를 분산하여 중복을 구현할 수 있습니다.

응용 프로그램 풀

일반적으로 서로 구분된 IIS(인터넷 정보 서비스) 응용 프로그램 풀을 구현하여 콘텐츠 간에 프로세스를 격리합니다. 응용 프로그램 풀을 통해 같은 서버 컴퓨터에서 여러 사이트를 실행하면서 자체 작업자 프로세스와 ID를 유지할 수 있습니다. 이렇게 하면 공격자가 한 사이트에서 코드를 주입해도 다른 사이트나 다른 서버에는 영향을 주지 않도록 할 수 있습니다.

호스트 이름으로 된 사이트 모음에서 단일 응용 프로그램 풀과 웹 응용 프로그램을 함께 사용하는 경우 도메인 URL은 스크립트 수준에서만 격리됩니다.

둘 이상의 응용 프로그램 풀을 구현하려는 경우 다음과 같은 각 시나리오에서 전용 응용 프로그램 풀을 사용할 수 있습니다.

익명 콘텐츠를 인증된 콘텐츠와 구분. 같은 팜에서 회사 인터넷 사이트를 호스트하는 경우 이 사이트를 전용 웹 응용 프로그램 및 응용 프로그램 풀에 배치합니다.
백 엔드 데이터 시스템에서 사용하도록 하고 이러한 시스템과 상호 작용하기 위한 암호를 저장하는 사이트 격리(이러한 용도로 보안 저장소 서비스를 대신 사용할 수도 있음)

호스트 이름으로 된 사이트를 포함하는 회사 포털 디자인 예제 및 인증 전용 영역을 포함하는 엑스트라넷 디자인 예제에서는 모든 콘텐츠에 대해 단일 응용 프로그램 풀 및 웹 응용 프로그램을 구현합니다. 서비스 응용 프로그램 및 SharePoint 중앙 관리 웹 사이트에는 별도의 응용 프로그램 풀이 필요합니다.

경로 기반 사이트를 포함하는 회사 포털 디자인 예제에서는 다음과 같은 방식으로 별도의 응용 프로그램 풀을 사용하여 콘텐츠 간의 프로세스 격리를 구현합니다.

관리 사이트가 전용 응용 프로그램 풀에서 호스트됩니다. 이는 SharePoint Server의 요구 사항입니다.
모든 서비스 응용 프로그램이 단일 응용 프로그램 풀로 배포됩니다. 서로 다른 응용 프로그램 풀로 서비스 응용 프로그램을 배포해야 하는 특별한 이유가 없으면 이 구성을 사용하는 것이 좋습니다. 모든 서비스 응용 프로그램에 대해 단일 응용 프로그램 풀을 사용하면 성능이 최적화되고 관리할 응용 프로그램 풀의 수가 줄어듭니다.
인트라넷 콘텐츠는 두 개의 서로 다른 애플리케이션 풀로 나뉩니다. 하나의 애플리케이션 풀은 공동 작업 콘텐츠(내 사이트 및 팀 사이트)를 호스트합니다. 별도의 애플리케이션 풀은 게시된 인트라넷 콘텐츠를 호스트합니다. 이 구성은 비즈니스 데이터 연결이 사용될 가능성이 더 높은 게시된 인트라넷 콘텐츠에 대한 프로세스 격리를 제공합니다.
전용 응용 프로그램 풀에서 파트너 웹 응용 프로그램을 호스트합니다.

웹 애플리케이션

웹 응용 프로그램은 SharePoint Server에서 만들고 사용하는 IIS 웹 사이트입니다. 각 웹 응용 프로그램은 IIS에서 서로 다른 웹 사이트로 나타납니다.

둘 이상의 웹 응용 프로그램을 구현하려는 경우에는 다음과 같은 사용 사례를 고려하세요.

익명 콘텐츠를 인증된 콘텐츠와 구분

같은 팜에서 회사 인터넷 사이트를 호스트하는 경우 이 사이트를 전용 웹 응용 프로그램 및 응용 프로그램 풀에 배치합니다.
사용자 격리

이 디자인 예제에서는 파트너 웹 사이트가 전용 웹 응용 프로그램 및 응용 프로그램 풀에서 호스트되므로 파트너가 인트라넷 콘텐츠에 액세스할 수 없습니다.
사용 권한 적용

전용 웹 응용 프로그램을 사용하면 웹 응용 프로그램 내의 영역에 대해 정책을 구현해 사용 권한을 적용할 수 있습니다. 예를 들어 회사 인터넷 사이트에 대해 하나 이상의 사용자 그룹에 대한 쓰기 권한을 명시적으로 거부하는 정책을 만들 수 있습니다. 정책은 웹 응용 프로그램에서 개별 사이트나 문서에 대해 구성된 사용 권한에 관계없이 적용됩니다.
성능 최적화

유사한 데이터 특성의 다른 애플리케이션을 사용하여 웹 애플리케이션에 배치하면 애플리케이션의 성능이 향상됩니다. 예를 들어 내 사이트의 데이터 특성에는 크기가 작은 많은 사이트가 포함됩니다. 반면에 팀 사이트에는 대개 적은 수의 매우 큰 사이트가 포함됩니다. 이러한 두 가지 유형의 사이트를 별도의 웹 애플리케이션에 배치하면 결과 데이터베이스는 데이터베이스 성능을 최적화하는 유사한 특성을 가진 데이터로 구성됩니다. 디자인 샘플에서 내 사이트 및 팀 사이트에는 고유한 데이터 격리 요구 사항이 없으며 동일한 애플리케이션 풀을 공유합니다. 그럼에도 불구하고 내 사이트 및 팀 사이트는 성능을 최적화하기 위해 별도의 웹 애플리케이션에 배치됩니다.
관리 효율성 최적화

별도의 웹 응용 프로그램을 만들면 별도의 사이트 및 데이터베이스가 만들어지므로 서로 다른 사이트 제한(휴지통, 만료 및 크기)을 구현하고 서비스 수준 계약을 서로 다르게 조정할 수 있습니다. 예를 들어 조직 내에서 내 사이트 콘텐츠가 크게 중요하지 않은 경우 내 사이트 콘텐츠의 복원 시간을 더 길게 설정할 수 있습니다. 이렇게 하면 내 사이트 콘텐츠가 복원되기 전에 더 중요한 콘텐츠가 먼저 복원됩니다. 이 디자인 예제에서는 관리자가 다른 응용 프로그램보다 확장을 더 적극적으로 관리할 수 있도록 내 사이트를 별도의 웹 응용 프로그램에 배치합니다.

단일 웹 응용 프로그램을 포함하는 호스트 이름으로 된 사이트 모음을 구현하는 경우 각 최상위 사이트가 별도의 도메인이 되므로 서로 다른 사이트 제한을 구현하여 관리 효율성을 최적화하는 등 이러한 목표 중 일부를 달성할 수 있습니다.

사이트 모음

사이트 배포 시 권장되는 구성은 단일 웹 응용 프로그램 내에 있는 모든 사이트에 호스트 이름으로 된 사이트 모음을 사용하는 것입니다. 이 구성은 Microsoft 365 환경에서 사용하는 것과 동일한 아키텍처이므로 사이트를 배포하는 것이 좋습니다. 따라서 가장 철저하게 테스트된 환경입니다. 앱 모델 및 요청 관리를 비롯한 새 기능은 이 구성에 최적화되어 있으며 앞으로도 가장 안정적인 구성입니다.

대부분의 아키텍처에 호스트가 명명된 사이트 모음을 사용하는 것이 좋지만, 다음과 같은 조건에서는 기존의 경로 기반 사이트 모음 및 대체 액세스 매핑을 사용해야 합니다.

기본 SharePoint Server 2016 설치의 일부분인 셀프 서비스 사이트 만들기 기능을 사용해야 하는 경우

사용자 지정 셀프 서비스 사이트 만들기 솔루션은 해당되지 않습니다.
웹 응용 프로그램에서 고유 와일드카드 포함 또는 명시적 포함이 필요한 경우

호스트 이름으로 된 사이트 모음에 대한 포함은 팜 수준에서 만들며, 모든 호스트 이름으로 된 사이트에 대해 이러한 포함을 사용할 수 있습니다. 팜의 모든 호스트 이름으로 된 사이트 모음은 같은 포함을 공유하지만 반드시 포함을 사용할 필요는 없습니다. 반면 경로 기반 사이트 모음용으로 만든 포함은 단일 웹 응용 프로그램에만 적용됩니다.
SSL 종료를 사용해야 하는데, 필요한 사용자 지정 HTTP 헤더를 생성하도록 SSL 종료 장치를 구성할 수 없는 경우

SSL 종료를 반드시 사용해야 하는 경우가 아니면 이러한 장치에 대해 호스트 이름으로 된 사이트 모음과의 SSL 브리징을 사용할 수 있습니다.
다른 응용 프로그램 풀에서 제공하는 추가적인 보안 기능을 사용하려는 경우 또는 여러 프록시 그룹을 사용해야 하는 경우

경로 기반 사이트 모음과의 비교를 포함하여 호스트 이름으로 된 사이트 모음에 대한 자세한 내용은 호스트 이름이 지정된 사이트 모음 아키텍처 및 배포(SharePoint 2013)를 참조하세요.

사이트 모음의 디자인 목표

사이트 모음은 논리 아키텍처와 정보 아키텍처를 연결하는 역할을 합니다. 사이트 모음의 디자인 목표는 URL 디자인 요구 사항을 충족하고 콘텐츠를 논리적으로 구분하는 것입니다. 각 사이트 모음에 대해 관리 경로가 최상위 사이트 모음의 두 번째 계층을 통합합니다. URL 요구 사항 및 관리 경로를 사용하는 방법에 대한 자세한 내용은 이 문서의 뒷부분에 있는 영역 및 URL을 참조하세요. 사이트 모음의 두 번째 계층 이후에 있는 각 사이트는 하위 사이트입니다.

다음 다이어그램에서는 팀 사이트의 사이트 계층 구조를 보여줍니다.

팀 사이트의 사이트 계층 구조

팀 사이트

경로 기반 사이트 모음 및 호스트 이름으로 된 모음 둘 다에 대해 정보 아키텍처는 사이트 모음의 두 번째 계층을 중심으로 합니다. 다음 섹션에서는 디자인 예제에서 사이트 특성을 기준으로 선택 사항을 통합하는 방법에 대해 설명합니다.

게시된 인트라넷 콘텐츠

게시된 인트라넷 콘텐츠 웹 응용 프로그램에서는 회사 내의 여러 부서에서 게시된 콘텐츠를 호스트한다고 가정합니다. 이 디자인 예제에서는 각 부서의 콘텐츠가 별도의 사이트 모음에서 호스트됩니다. 이 방법의 장점은 다음과 같습니다.

각 부서에서 독립적으로 콘텐츠와 사용 권한을 관리할 수 있습니다.
각 부서에서 콘텐츠를 전용 데이터베이스에 저장할 수 있습니다.

여러 사이트 모음을 사용하는 방법의 단점은 다음과 같습니다.

사이트 모음 간에 마스터 페이지, 페이지 레이아웃, 템플릿, 웹 파트 및 탐색을 공유할 수 없습니다.
사이트 모음 간에 사용자 지정 내용 및 탐색을 조정하려면 추가 작업을 수행해야 합니다.

인트라넷 사이트의 정보 아키텍처 및 디자인에 따라 게시된 콘텐츠가 사용자에게 원활한 환경으로 표시될 수 있습니다. 또는 각 사이트 모음이 별도의 웹 사이트로 표시될 수 있습니다.

내 사이트

내 사이트에는 독특한 특징이 있으며 내 사이트 배포와 관련된 지침은 단순합니다. 디자인 샘플에서 내 사이트 사이트 모음은 의 URL과 함께 최상위 사이트를 통합합니다. http://my. 작성된 첫 번째 최상위 사이트 모음에는 내 사이트 호스트 템플릿이 사용됩니다. 와일드카드 포함을 사용하여 관리 경로가 통합되므로 사용자가 만들 수 있는 사이트의 수에 제한이 없습니다. 관리 경로 아래의 모든 사이트는 개인 사이트 템플릿을 사용하는 독립적인 사이트 모음입니다. 사용자 이름은 URL에 http://my personal/ 사용자 이름 형식으로 추가됩니다. 다음 그림에서는 내 사이트를 보여줍니다.

내 사이트의 사이트 계층 구조

내 사이트

팀 사이트

다음 두 가지 방법 중 하나를 사용하여 팀 사이트 응용 프로그램에서 사이트 모음을 디자인할 수 있습니다.

팀에서 셀프 서비스 사이트 만들기를 통해 사이트 모음을 만들 수 있도록 허용합니다. 이 방법의 장점은 팀에서 필요에 따라 손쉽게 사이트를 만들 수 있으며 관리자의 도움이 필요하지 않다는 점입니다. 이 방법의 단점은 다음과 같습니다.
- 자세한 분류를 구현할 수 없습니다.
- 다른 방법을 사용하면 사이트 모음을 공유할 수도 있는 프로젝트나 팀 간에 템플릿 및 탐색을 공유할 수 없습니다.
조직이 운영되는 방식에 따라 조직에 일정한 수의 사이트 모음을 만듭니다. 이 방법에서 SharePoint 관리자는 사이트 모음을 만듭니다. 사이트 모음이 만들어지면 팀에서 사이트 모음 내에 사이트를 만들 수 있습니다. 이 방법을 사용하면 팀 사이트의 관리 및 확장 방식을 체계화하는 정교한 분류를 구현할 수 있습니다. 또한 사이트 모음을 공유하는 프로젝트 및 팀 간에 템플릿 및 탐색을 공유할 수 있는 기회가 더 많아집니다. 그러나 이 방식에는 다음과 같은 몇 가지 단점도 있습니다.

이 디자인 예제에서는 두 번째 방법이 사용되므로 팀 사이트와 게시된 인트라넷 콘텐츠에 대해 비슷한 사이트 모음 계층 구조가 생성됩니다. 정보 설계자는 조직에 적합한 방식으로 사이트 모음의 두 번째 계층을 만들어야 합니다. 다음 표에서는 다양한 조직 유형에 대해 권장되는 구조를 보여줍니다.

표: 권장되는 사이트 모음 분류

조직 유형	권장되는 사이트 모음 분류
제품 개발	개발 중인 각 제품에 대한 사이트 모음을 만듭니다. 참여하는 각 팀에서 사이트 모음 내에 사이트를 만들 수 있도록 허용합니다. 장기 개발 프로젝트의 경우 제품 개발에 참여하는 각 대규모 팀에 대해 사이트 모음을 만듭니다. 예를 들어 디자이너, 엔지니어 및 콘텐츠 개발자 팀에 대해 사이트 모음을 하나씩 만듭니다.
리서치	각 장기 리서치 프로젝트에 대해 사이트 모음을 하나씩 만듭니다. 리서치 프로젝트의 각 범주에 대해 사이트 모음을 하나씩 만듭니다.
고등 교육 기관	학과별로 사이트 모음을 하나씩 만듭니다.
정부 기관	정당별로 사이트 모음을 하나씩 만듭니다. 같은 정당에 속한 공무원들이 템플릿 및 탐색을 공유할 수 있습니다. 각 위원회에 대한 사이트 모음을 만듭니다. 또는 모든 위원회에 대해 하나의 사이트 모음을 만듭니다.
회사 법률 사무소	기업 고객별로 사이트 모음을 하나씩 만듭니다.
제조	제품 라인별로 사이트 모음을 하나씩 만듭니다.