Power BI 구현 계획: 테넌트 관리

참고 항목

이 문서는 Power BI 구현 계획 시리즈의 일부를 구성합니다. 이 시리즈는 주로 Microsoft Fabric 내의 Power BI 환경에 중점을 둡니다. 시리즈에 대한 소개는 Power BI 구현 계획을 참조하세요.

이 문서에서는 패브릭 테넌트를 관리하기 위한 주요 고려 사항을 소개합니다. 이 문서는 다음을 대상으로 합니다.

• 패브릭 관리자: 조직에서 패브릭을 감독할 책임이 있는 관리자입니다.
• IT 및 시스템 관리자: 패브릭 관리자와 협업하여 조직 내에서 시스템을 감독하고 통합하는 다른 관리자입니다.
• COE(우수성 센터) 및 BI 팀: Power BI를 감독하고 조직에서 Power BI 사용자를 지원하는 팀입니다. 이러한 팀은 중요한 결정을 내리고 패브릭 관리자와 공동 작업합니다.

Power BI 서비스 관리는 시스템 감독의 한 가지 주요 측면입니다. 자세한 내용은 시스템 감독을 참조하세요. 시스템 감독과 관련된 일상적인 활동을 일반적으로 시스템 관리라고 합니다. 시스템 관리 활동은 콘텐츠 소비자와 콘텐츠 작성자가 Power BI를 사용하여 지속적으로 좋은 경험을 할 수 있도록 하는 데 중요합니다.

패브릭 채택 성숙도 수준 문서에 설명된 대로 조직 채택은 엔터프라이즈 BI 및 관리형 셀프 서비스 BI를 지원하고 활성화하기 위한 거버넌스 및 데이터 관리 관행의 효율성을 나타냅니다. 따라서 분석 및 BI 플랫폼을 관리하는 관리자는 분석 채택 노력의 성공에 크고 직접적인 영향을 미칠 수 있습니다.

참고 항목

패브릭 용량(또는 프리미엄 용량)을 관리하고 Power BI 서비스를 관리하는 것은 서로 다른 개념입니다. 대부분의 조직에는 Power BI 테넌트가 하나뿐이지만 조직은 여러 워크로드 또는 사업부에 대해 여러 용량을 프로비전할 수 있습니다.

Important

때때로 이 문서는 Power BI Premium 또는 P SKU(프리미엄 용량 구독)를 언급합니다. Microsoft는 현재 구매 옵션을 통합하고 용량당 Power BI Premium SKU를 사용 중지하고 있습니다. 신규 및 기존 고객은 대신 F SKU(Fabric 용량 구독)로 구매를 고려해야 합니다.

자세한 내용은 Power BI Premium 라이선스 관련 중요 업데이트 및 Power BI Premium FAQ를 참조하세요.

책임 범위 정의

패브릭 관리자 역할에 대한 단일 정의는 없습니다. 즉, 패브릭 관리자의 역할과 일상적인 책임은 조직마다 다를 수 있습니다. 달라서는 안 되는 것은 조직의 우선 순위와 목표가 변경됨에 따라 시간이 지남에 따라 역할이 진화할 수 있고 변화해야 한다는 것입니다.

전략적 관점에서 패브릭 관리자는 다음 사항에 집중해야 합니다.

• 거버넌스: 엔터프라이즈 BI 및 관리형 셀프 서비스 BI를 지원하기 위한 거버넌스 지침 및 정책을 제정합니다.
• 사용자 역량 강화: 조직의 규정 및 요구 사항을 준수하면서 가능한 범위까지 내부 사용자 커뮤니티를 지원하는 내부 프로세스 및 시스템을 촉진하고 지원합니다.
• 채택: 효과적인 거버넌스 및 데이터 관리 방식으로 조직에서 더 광범위하게 Fabric이 채택되도록 합니다.

거버넌스, 사용자 권한 부여 및 채택 목표의 균형을 맞추려고 시도하면 기본적으로 경쟁 우선 순위가 발생합니다. 이상적으로, 그것은 우선 순위에 대한 생산적인 논쟁으로 이어집니다. 다양한 역할과 책임에 대한 기대치를 명확히 하고 전달하면 용납할 수 없는 수준의 마찰과 충돌을 방지하는 데 도움이 될 수 있습니다.

패브릭 관리자의 다음 세 가지 예를 고려합니다.

• 사용자 활성화에 집중: Riley는 관리형 셀프 서비스 BI에 상당한 투자를 한 대규모 글로벌 조직에서일하는 패브릭 관리자입니다. 조직 전체의 사용자에게 셀프 서비스 BI 기능을 사용하도록 설정하기 위해 Riley는 COE(우수 센터) 및 기타 관리자와 의사 결정 및 작업을 조정하는 데 많은 시간을 할애합니다. 필요한 경우 Riley는 기존 BI 솔루션을 지원하기 위한 단계를 수행합니다.
• 거버넌스 및 규정 준수에 집중: Parker는 규제가 높은 조직에서 일하는 패브릭 관리자입니다. 이 조직에서 대부분의 BI 개발은 중앙 집중식 엔터프라이즈 BI 팀 내의 BI 개발자가 처리합니다. Parker의 관리 책임은 주로 감사, 정보 보호 및 보안과 같은 영역에 중점을 줍니다.
• 콘텐츠 만들기에 대한 높은 참여: Morgan은 데이터 문화 구축을 시작한 소규모 조직에서 일하는 패브릭 관리자입니다. 현재 조직에는 소수의 콘텐츠 작성자만 있습니다. Morgan은 시스템 감독 책임 외에도 정기적으로 콘텐츠를 만들고 게시하는 BI 개발자입니다. 때때로 Morgan은 동료를 멘토링하는 공동 개발 프로젝트에 참여하여 조직에서 BI 전문 지식을 성장시키는 데 도움이 됩니다.

검사 목록 - 책임 범위를 계획할 때 주요 의사 결정 및 작업에는 다음이 포함됩니다.

• 전략적 포커스 결정: 패브릭 관리자의 전략적 포커스를 결정합니다. 의사 결정(및 절충안)을 내려야 할 때 사용할 목표와 우선 순위에 대한 명확성을 얻습니다.
• 특정 역할 및 책임 식별: 패브릭 관리자에 대한 특정 기대치를 결정합니다. 해당 역할과 책임을 명확하게 문서화하고 적절한 경우 인사 관리로 작업 설명을 업데이트합니다.

관리자 임명

패브릭 관리자의 조치는 사용자 경험, 데이터 문화 노력, 거버넌스 노력, 컨텐츠 소유 및 관리 사용자 및 조직 채택 노력에 상당한 영향을 미칩니다. 따라서 관리자 역할에 적합한 사람을 임명하는 것이 중요합니다.

관리자를 선택할 때 고려해야 할 몇 가지 주요 사항은 다음과 같습니다.

• 역할의 높은 특권적 성격을 의식합니다. 관리자 역할은 다양한 테넌트 설정, 작업 영역 액세스, 개인 작업 영역 액세스를 관리할 권한이 있으며 모든 테넌트 메타데이터를 볼 수 있으므로 높은 권한의 역할입니다. 자세한 내용은 Power BI 관리를 참조하세요.
• 관리자가 되기에 적합한 사용자를 신중하게 선택합니다. 관리자는 종종 사용자 및 COE와 공동 작업해야 합니다. 이러한 이유로 비즈니스 인텔리전스 개념과 사용자가 달성하려는 작업을 이해해야 합니다. 뛰어난 성격을 가지고 있거나 사용자가 수행할 수 있는 작업을 엄격하게 제한하는 경향이 있는 사람은 셀프 서비스 BI 플랫폼을 관리하는 데 적합하지 않을 수 있습니다.
• 관리자 2~4명을 선택합니다. 높은 권한의 역할이므로 소수의 관리자만 임명합니다. 적절한 균형 조정: 관리자가 너무 많으면 승인되지 않은 변경이 발생할 위험이 증가하지만 관리자가 너무 적으면 시스템이 충분히 지원되지 않을 위험이 증가합니다.
• 가끔 관리자를 허용합니다. 가끔 패브릭 관리자 권한이 필요한 사용자가 있는 경우 PIM(Privileged Identity Management)을 구현하는 것이 좋습니다. PIM을 사용하면 몇 시간 후에 만료되는 Just-In-Time 역할 권한을 할당할 수 있습니다. 이 프로세스는 위험(너무 많은 전임 관리자가 있는 경우)과 유용성(진행률 허용)의 균형을 맞추는 유용한 방법을 제공합니다. 특히 대규모의 탈중앙화 조직에서 그렇습니다. PIM을 사용하는 경우 관리자 역할의 위임이 기록되며 필요에 따라 권한 부여를 위한 승인 워크플로를 포함할 수 있습니다.
• 패브릭 관리를 우선 순위로 지정합니다. 종종 BI 플랫폼의 관리는 많은 책임 중 하나일 뿐입니다. 사용자가 잘 지원되고 시스템이 충분히 관리되도록 하는 방법을 고려합니다.
• 모든 관련 역할에 할당된 사용자를 정기적으로 검토합니다. Power BI 서비스를 관리할 수 있는 역할에는 패브릭 관리자와 Power Platform 관리자 등의 세 가지가 있습니다. 이러한 역할의 멤버 자격을 정기적으로 감사하는 것이 중요합니다.

자세한 내용은 Microsoft 365 관리 센터의 관리자 역할 정보를 참조하세요.

검사 목록 – 관리자를 임명할 때 주요 결정 및 작업에는 다음이 포함됩니다.

• 현재 패브릭 관리자 식별: 현재 패브릭 관리자 역할에 할당된 사용자를 검토합니다. 또한 이 검토에서 Power Platform 관리자 및 전역 관리자 역할을 고려합니다.
• 패브릭 관리자 임명: 위험을 줄이려면 패브릭 관리자 역할에 2~4명을 임명합니다. 현재 할당된 사용자가 4명 이상인 경우 패브릭 관리자 역할에 할당된 사용자 수를 줄입니다.
• 간헐적인 관리자를 위해 PIM 사용: 합법적으로, 하지만 경우에 따라 패브릭 관리자 권한이 필요한 사람이 있는지 여부를 식별합니다. PIM을 구현하여 몇 시간 후에 만료되는 Just-In-Time 역할 권한을 할당합니다. 승인 워크플로를 포함할 수 있는 프로세스의 작동 방식을 문서화하고 전달합니다.
• 백업 할당 및 교차 학습 수행: 패브릭 관리 책임을 처리하기 위해 마련된 교차 학습 및 설명서의 상태를 확인합니다. 우선 순위 사용자 요구 사항을 적시에 일관된 방식으로 충족할 수 있도록 백업 담당자가 학습되었는지 확인합니다.
• 정기적으로 관리자 감사: 패브릭 관리자 역할에 정기적으로 할당된 사용자를 확인합니다.

다른 관리자와 공동 작업

패브릭 관리자는 높은 권한의 역할이지만 패브릭 관리로 제한됩니다. 따라서 때때로 다른 관리자와 공동 작업해야 합니다.

다음은 패브릭 관리자가 다른 시스템 관리자와 공동 작업하는 몇 가지 일반적인 이유입니다.

• 디바이스 설정 및 설치: 사용자 디바이스를 설치, 업데이트 또는 관리 하려면 IT, 인프라 팀 또는 데스크톱 지원 팀과 협력해야 할 수 있습니다.
• 구독 및 라이선스 구매: 구독 및 구매 라이선스를 관리하려면 Microsoft 365의 청구 관리자 역할이 필요합니다. 청구 관리자는 비용 분석 및 관리를 담당할 수도 있습니다. 라이선스를 관리하는 중앙 집중식 및 탈중앙화(셀프 서비스) 방법에 대한 자세한 내용은 사용자 라이선스를 참조하세요.
• 라이선스 할당 및 사용자 관리: 특정 사용자에게 라이선스를 할당하려면 Microsoft 365의 라이선스 관리자 역할이 필요합니다. 사용자의 속성을 관리하려면 사용자 관리자 역할이 필요합니다. 사용자 속성(예: 자동 라이선스 할당 또는 자동 그룹 할당)을 기반으로 자동화를 구현하려는 경우 사용자 관리자와 함께 작업하는 것이 유용합니다. 자세한 내용은 일반적으로 사용되는 Microsoft 365 관리 센터 역할을 참조하세요.
• Microsoft Entra 관리자: Microsoft Entra 관리자와 함께 작업해야 하는 다양한 이유가 있습니다. 사용자, 그룹 및 서비스 주체를 설정하거나 관리해야 하는 경우가 종종 있습니다. 자세한 내용은 테넌트 수준 보안 계획을 참조하세요.
• 원본 데이터 액세스: 콘텐츠 작성자를 대신하여 데이터에 액세스하려면 시스템 관리자 또는 데이터베이스 관리자와 협력해야 할 수 있습니다. 경우에 따라 의미 체계 모델이 콘텐츠 소비자의 ID 에 따라 데이터 보안을 적용할 때 콘텐츠 소비자를 대신하여 액세스를 요청해야 할 수도 있습니다.
• 데이터 손실 방지 및 데이터 분류: 거버넌스 및 정보 보호를 위해 Microsoft Purview 관리자와 공동 작업해야 할 수 있습니다.
• Teams 통합: Power BI를 Microsoft Teams와 통합하는 경우 Teams관리자와 공동 작업해야 할 수 있습니다.
• OneDrive 및 SharePoint 통합: Power BI를 OneDrive 또는 SharePoint와 통합하는 경우 다른 관리자와 공동 작업해야 할 수 있습니다.
• 작업 영역 관리: 패브릭 작업 영역 관리자와 공동 작업하여 특정 작업 영역 내에서 콘텐츠를 계획, 구성 또는 보호해야 할 수 있습니다.
• 수명 주기 관리: 콘텐츠에 대한 변경 내용을 배포하고 관리할 때 배포 파이프라인 관리자 또는 Azure DevOps 관리자와 공동 작업해야 할 수 있습니다.
• 프리미엄 용량 관리: 프리미엄 용량을 관리할 때 용량 관리자와 공동 작업해야 할 수 있습니다.
• 데이터 게이트웨이 관리: 온-프레미스 데이터 게이트웨이를 관리하고 보호하기 위해 게이트웨이 관리자와 공동 작업해야 할 수 있습니다. 자세한 내용은 게이트웨이 관리를 참조하세요.
• Power Platform 관리: Power BI와 다른 Power Platform 앱(예: Power Automate 또는 Power Apps) 간에 솔루션을 통합해야 할 수 있습니다.
• Azure 관리: Azure 관리자와 협력하여 Power BI와 통합하려는 다른 Azure 서비스를 설정, 액세스 및 보호해야 할 수 있습니다.
• 보안 관리 및 감사: 조직에 특정 규정 준수, 보안 또는 개인 정보 요구 사항이 있을 수 있습니다. 이 경우 보안 팀과 협업하여 위험을 식별하고 완화해야 할 수 있습니다.
• 네트워킹: 다른 데이터 원본 및 시스템에 연결할 때 성능 및 보안상의 이유로 네트워크 관리자와 협력해야 할 수 있습니다.
• 모바일 디바이스 관리: 모바일 디바이스 정책 및 보안을 관리하기 위해 Intune 관리자와 공동 작업해야 할 수 있습니다.

Important

패브릭 관리자는 스스로 결정을 내리거나(예: 테넌트 설정 변경) 조치를 취해서는 안 됩니다. 모든 주요 의사 결정을 논의, 계획 및 문서화해야 합니다. 다른 관리자와 공동 작업하는 것 외에도 COE 및 BI 전략 작업 팀을 완전히 포함해야 합니다. 전략적 결정을 위해 경영진 스폰서를 참여시키는 것도 적절할 수 있습니다.

검사 목록 – 다른 관리자와 공동 작업할 때 주요 결정 및 작업에는 다음이 포함됩니다.

• 디바이스 설정 및 설치를 관리할 사용자 결정: 조직의 디바이스를 관리하는 사용자를 알고 있어야 합니다. 해당 프로세스 및 요구 사항을 숙지합니다. 필요할 때 함께 일할 준비를 합니다.
• 구독 및 라이선스를 관리할 사용자 식별: 조직의 구독 및 라이선스를 관리하는 사용자를 알고 있어야 합니다. 해당 프로세스 및 요구 사항을 숙지합니다. 필요할 때 함께 일할 준비를 합니다.
• 라이선스를 할당하고 사용자, 그룹 및 서비스 주체를 관리할 사용자 식별: 조직의 사용자, 그룹 및 서비스 주체를 관리하는 사용자를 알고 있는지 확인합니다. 해당 프로세스 및 요구 사항을 숙지합니다. 필요할 때 함께 일할 준비를 합니다.
• 참조할 다른 관리자를 결정: 구현 계획 프로세스를 진행할 때 다른 관련 관리자를 식별합니다. 관련 모임에 초대하고 관련 의사 결정 프로세스에 참여시킵니다. 필요에 따라 설명서 및 프로세스를 업데이트합니다.

Power BI 서비스 관리

Power BI 서비스 관리 및 관리는 패브릭 관리자의 주요 책임 중 하나입니다. 이 섹션에서는 Fabric 관리 포털에서 많은 일반적인 설정 및 기능을 관리하고 관리하는 방법을 설명합니다.

• 테넌트 설정
• 도메인:
• 작업 영역
• embed 태그
• 조직의 시각적 개체
• Azure 연결

테넌트 설정 관리

테넌트 설정은 사용하도록 설정된 Power BI 기능과 조직의 사용자를 제어하는 주요 방법입니다. 테넌트 설정 관리는 패브릭 관리자에게 가장 중요한 책임 중 하나입니다.

콘텐츠 작성자와 콘텐츠 소비자는 Power BI에서 사용 가능한 기능과 기능에 대해 쉽게 배울 수 있으므로(설명서에서) 예상한 작업을 수행할 수 없을 때 좌절이 발생할 수 있습니다. 또한 사용자 불만족과 덜 효과적인 조직 채택, 사용자 채택 및 솔루션 채택으로 이어질 수 있습니다.

다음은 혼란스럽고 좌절한 사용자가 묻는 몇 가지 일반적인 질문입니다.

• 작업 영역을 만들 수 없는 이유는 무엇인가요?
• 데이터를 내보낼 수 없는 이유는 무엇인가요?
• 사용자 지정 시각적 개체가 작동하지 않는 이유는 무엇인가요?
• 의미 체계 모델을 인증할 수 없는 이유는 무엇인가요?
• 민감도 레이블을 할당할 수 없는 이유는 무엇인가요?
• 특정 최종 사용자에게 앱을 푸시할 수 없는 이유는 무엇인가요?

Important

각 테넌트 설정은 조직의 거버넌스 지침 및 정책에 부합해야 합니다. 패브릭 관리자가 설정을 사용하거나 사용하지 않도록 설정하기로 결정한 경우 일반적으로 거버넌스 프로세스를 개선하고 구체화해야 한다는 명확한 지표입니다.

이 섹션의 나머지 부분에서는 테넌트 설정을 관리하는 다음 프로세스에 대해 설명합니다.

1. 테넌트 설정 검토
2. 테넌트 설정 결정
3. 테넌트 설정 업데이트
4. 문서 테넌트 설정
5. 테넌트 설정 관리
6. 테넌트 설정 감사

1단계: 테넌트 설정 검토

각 테넌트 설정을 검토하여 테넌트의 현재 상태를 명확하게 이해하는 것이 중요합니다. 모든 테넌트 설정을 검토해야 하지만 위험 평가에 따라 먼저 검토하도록 특정 중요 설정의 우선 순위를 지정할 수 있습니다.

다음은 검토 프로세스 중에 고려해야 할 몇 가지 요소입니다.

• 설정: 특정 테넌트 설정이 현재 활성화 또는 비활성화되어 있나요?
• 사용 권한: 특정 테넌트 설정을 전체 조직에 적용할 수 있나요? 아니면 특정 보안 그룹에서 사용할 수 있거나 거부되나요?

참고 항목

일부 테넌트 설정은 기본적으로 사용하도록 설정되지만 다른 테넌트 설정은 기본적으로 사용하지 않도록 설정됩니다.

두 가지 방법 중 하나로 테넌트 설정의 현재 상태를 컴파일할 수 있습니다.

• 관리 포털 내에서 테넌트 설정 상태를 봅니다.
• 테넌트 설정 가져오기 REST API를 사용하여 프로그래밍 방식으로 테넌트 설정 상태를 추출합니다.

다음 표에서는 테넌트 설정의 현재 상태를 기록하는 방법을 보여줍니다.

마지막으로 검토한 날짜	테넌트 설정	현재 값	허용된 보안 그룹	보안 그룹 허용 안 됨	다른 관리자에게 위임된 테넌트 설정
2023년 10월 15일	작업 영역 만들기	특정 보안 그룹에 대해 사용	Power BI 작업 영역 작성자, Power BI 관리자, Power BI COE, Power BI 지원	해당 없음	해당 없음
2023년 10월 15일	Excel로 내보내기	특정 보안 그룹을 제외한 전체 조직에 대해 사용	해당 없음	영업 팀-유럽	해당 없음
2023년 11월 1일	작업 영역 전체에서 의미 체계 모델 사용	전체 조직에 대해 사용	해당 없음	해당 없음	해당 없음
2023년 11월 1일	인증	특정 보안 그룹에 대해 사용	Power BI 인증 SME	해당 없음	도메인 관리자는 사용하거나 사용하지 않도록 설정할 수 있습니다.
2023년 11월 5일	특정 사용자가 외부 데이터 공유를 켤 수 있도록 허용	특정 보안 그룹에 대해 사용	Power BI 외부 데이터 공유	해당 없음	해당 없음

보안 그룹에 대한 다른 고려 사항은 Power BI 그룹 계획을 참조하세요.

허용 가능한 테넌트 설정 상태에 대한 자세한 내용은 테넌트 설정을 사용하는 방법을 참조하세요.

주의

경우에 따라 관리자가 테넌트를 모니터링할 때 이상적이지 않은 상황을 검색합니다. 예를 들어 사용자 활동 데이터에 너무 많은 데이터 내보내기가 표시될 수 있습니다. 이 경우 관리자는 관련 테넌트 설정을 사용하지 않도록 설정하려고 할 수 있습니다. 그러나 기능을 완전히 사용하지 않도록 설정하기 전에 먼저 사용자가 특정 기술에 의존하는 이유를 이해하는 것이 중요합니다. 기능을 금지하면 사용자 불만으로 인해 사용자가 해결 방법을 만들도록 유도할 수 있기 때문입니다. 대신 솔루션을 다시 디자인해야 하거나 추가 사용자 교육 및 교육을 통해 문제를 완화할 수 있다는 점을 고려하세요.

2단계: 테넌트 설정 결정

현재 테넌트 설정을 검토한 후에는 의사 결정 프로세스를 검토해야 합니다. 각 테넌트 설정에 대해 워크샵을 사용하여 허용하거나 허용하지 않아야 하는 기능과 사용자를 적극적으로 논의하고 결정합니다.

모든 테넌트 설정은 거버넌스 결정을 나타냅니다. 따라서 올바른 결정을 내리기 위해 다른 사용자와 공동 작업을 수행해야 합니다. 상황에 따라 의사 결정 프로세스에는 COE, 경영진 스폰서, 보안 팀, BI 팀 또는 기타(예: 이해 관계자 또는 챔피언)와의 공동 작업이 포함될 수 있습니다.

팁

가장 큰 과제 중 하나는 기존 테넌트 설정과 목표 및 의도적인 결정 간에 불일치가 발생할 때 수행할 작업을 결정하는 것입니다. 충돌이 발생할 때 이러한 충돌을 해결할 준비를 합니다.

의사 결정 과정에서 고려해야 할 몇 가지 요소는 다음과 같습니다.

• 이미 존재하는 거버넌스 결정은 무엇인가요? 가능하면 사용자가 내린 기존 결정을 참조하세요. 항상 일관되고 효율적인 것을 목표로 합니다. 또한 내부 또는 외부 규정 준수 요구 사항을 알고 있어야 합니다. 해당하는 경우 테넌트 설정은 더 광범위한 거버넌스 정책과 일치해야 합니다. 예를 들어 조직 외부에서 데이터를 공유할 수 있는 시기, 사용자 및 방법을 지정하는 현재 거버넌스 정책이 있을 수 있습니다.
• 누가 새로운 거버넌스 결정을 내리나요? 테넌트 설정에 대한 결정을 내려야 하는 경우 대화의 모든 관련 당사자를 참여시킵니다. 일반적으로 패브릭 관리자만으로는 테넌트 설정에 대한 결정을 내릴 수 있는 최상의 위치에 있지 않습니다. 작업 팀을 구성하고 워크샵을 실행하는 방법에 대한 자세한 내용은 BI 전략 계획을 참조하세요.
• 결정은 일시적인가요? 경우에 따라 테넌트 설정이 짧은 기간 동안만 설정됩니다. 일반적으로 COE, BI 및 IT 팀이 조직 전체에서 더 광범위하게 릴리스되기 전에 새로운 기능에 익숙해질 수 있도록 하기 위해 수행됩니다. 이렇게 하면 거버넌스 지침에 부합되는지 확인할 수 있으며 사용자 커뮤니티가 잘 지원됩니다.
• 다른 사업부 또는 팀이 다르게 처리되나요? 대규모 조직에서는 단일 접근 방식이 거의 작동하지 않습니다. 서로 다른 팀의 요구 사항과 기술을 수용하기 위해 경우에 따라 다른 대상 그룹에 대해 테넌트 설정을 다르게 설정해야 할 수 있습니다. 항상 거버넌스 지침 내에서 지원 팀이 최대한 유연하게 운영할 수 있도록 하는 것을 목표로 합니다.
• 승인 프로세스가 있나요? 특정 주제에 따라 승인이 필요할 수 있습니다. 테넌트 설정이 보안 또는 규정 준수와 관련된 경우 특히 그렇습니다.
• 각 결정을 다시 검토할 일정은 무엇인가요? 각 테넌트 설정 결정에 대한 검토를 정기적으로 예약합니다. 이 목적을 위해 일년에 두 번 좋은 일정입니다.

다음 표에서는 결정을 기록하는 방법을 설명합니다.

의사 결정 날짜	의사 결정	관련된 의사 결정자	결정 승인자	영향을 받는 테넌트 설정	보류 중인 작업
2023년 10월 15일	COE는 작업 영역을 만들고 관리하기 위한 모범 사례에 대해 승인된 콘텐츠 작성자를 학습시킵니다. 승인된 작성자는 모든 사업부 소속일 수 있습니다.	COE 및 이해 관계자	엘리스 터너(총괄 스폰서)와 테일러 필립스(COE 리드)	작업 영역 만들기	Power BI 작업 영역 작성자 그룹의 기존 멤버 검토
2023년 10월 15일	Excel로 내보내기가 허용됩니다. COE는 활동 로그의 작업을 추적하고 이를 과도하게 사용하는 사용자에게 문의합니다. 현재 조사 중인 문제로 인해 영업 팀-유럽에 대한 일시적인 제한 사항이 있습니다.	COE 및 보안	엘리스 터너(총괄 스폰서)와 제시 어윈(최고 기술 책임자)	Excel로 내보내기	60일 만에 유럽 문제에 대한 후속 조치
2023년 11월 1일	공유 의미 체계 모델을 사용하여 데이터 재사용을 장려하고, 데이터 사일로를 최소화하고, 데이터 중복을 줄이는 것이 좋습니다.	COE	엘리스 터너(총괄 스폰서)	작업 영역 전체에서 의미 체계 모델 사용	해당 없음
2023년 11월 1일	COE는 보고서 및 데이터 자산을 인증하기 위한 프로세스 및 요구 사항에 대해 승인된 콘텐츠 작성자를 학습시킵니다. 승인된 작성자는 모든 사업부 소속일 수 있습니다.	COE 및 이해 관계자	엘리스 터너(총괄 스폰서)와 테일러 필립스(COE 리드)	인증	Power BI 인증 SEM 그룹의 기존 멤버 검토
2023년 11월 5일	조직의 데이터 공유 정책은 조직 외부에서 데이터를 공유하는 방법을 다룹니다. 모든 사용자는 매년 이 정책을 검토하고 승인해야 합니다. COE에서 학습하면 사용자가 Power BI에서 작업하는 동안 준수할 수 있습니다.	COE, 보안 및 규정 준수	제시 어윈(최고 기술 책임자)	특정 사용자가 외부 데이터 공유를 켤 수 있도록 허용	Power BI 외부 데이터 공유 그룹의 기존 멤버 검토

결정이 내려진 이유를 설명하는 다른 상황별 정보를 포함하는 것이 좋습니다. 또한 기존 관련 문서 또는 정책의 위치에 대한 링크를 포함합니다.

참고 항목

표에 제시된 예제는 의도적으로 사용자 권한 부여, 규정 준수 및 내부 요구 사항의 균형을 맞추는 방법을 보여 줍니다. 추가 고려 사항은 거버넌스를 참조하세요.

3단계: 테넌트 설정 업데이트

이제 기존 테넌트 설정 및 의도적인 결정을 사용할 수 있으므로 테넌트 설정을 업데이트할 준비가 되었습니다.

업데이트 프로세스 중 고려 사항은 다음과 같습니다.

• 업데이트는 누가 처리하나요? 여러 패브릭 관리자가 있는 경우 한두 명의 패브릭 관리자가 주로 테넌트 설정을 업데이트하는 역할을 하는 것이 좋습니다. 목표는 프로세스가 일관되고 잘 이해되며 잘 제어되도록 하는 것입니다.
• 어떤 테스트 프로세스가 진행중입니까? 테넌트 설정에 따라 변경될 때 다른 효과가 있을 수 있습니다. 광범위한 변경을 수행하기 전에 테스트를 수행합니다. 예를 들어 작업 영역에서 의미 체계 모델 사용 제어를 참조하세요.
• 변경 관리 프로세스가 있나요? 의사 결정, 설명서 및 결과 업데이트 간의 불일치를 방지하는 방법을 고려합니다. 팀 간 커뮤니케이션은 변경 관리의 주요 성공 요소입니다. 감사 요구 사항에 따라 내부 변경 로그를 유지하여 변경한 사람, 시기 및 이유를 추적하도록 선택할 수 있습니다(활동 로그에 캡처된 내용 이상의 세부 정보를 기록하기 위해).
• 사용자와의 커뮤니케이션은 어떻게 처리되나요? 사용자가 수행할 수 있는 일에 영향을 주는 변경을 수행할 때 변경 내용을 전달해야 합니다. 항상 사용자 불만 및 불필요한 지원 요청을 방지하는 것을 목표로 합니다.

4단계: 문서 테넌트 설정

이 시점에서 테넌트 설정 값을 문서화하기 위한 반복 가능한 메서드가 있는지 확인합니다. 간소화된 예제는 테넌트 설정을 검토하는 방법에 대한 위의 1단계 표를 참조하세요.

다음은 설명서에 고려해야 할 몇 가지 측면입니다.

• 스냅샷 데이터 추출: 테넌트 설정 값을 문서화할 때 정기적으로 새 지정 시간 스냅샷을 만드는 것이 좋습니다. 이를 위해 일주일에 한 번 스냅샷을 만드는 것이 좋은 빈도입니다. 테넌트 설정 가져오기 REST API를 사용하여 프로세스를 자동화합니다.
• 관리자에게 스냅샷 데이터에 대한 액세스 권한 제공: 관리자, COE 및 내부 감사자가 모든 스냅샷 데이터에 액세스할 수 있어야 합니다. 변경된 테넌트 설정을 식별하려면 두 스냅샷(예: 지난 주에 비해 이번 주)을 비교합니다. 활동 로그의 데이터는 스냅샷 데이터를 보완하여 변경된 내용, 시기 및 대상에 대한 완전한 이해를 제공합니다. 자세한 내용은 테넌트 설정 감사에 관한 아래 6단계를 참조하세요.
• 사용자에게 현재 설정 요약 제공: 테넌트 설정 값은 중앙 집중식 포털에서 사용자 커뮤니티에서 사용할 수 있는 설명서의 한 가지 유형입니다. 예를 들어 기능을 사용할 수 없는 이유를 이해하지 못하는 사용자에게 유용한 참조입니다. 또한 이 설명서는 사용자가 기능을 사용하려는 경우 가입을 요청할 보안 그룹을 파악하는 데 도움이 될 수 있습니다. 수동 작업 수준을 줄이기 위해 REST API의 최신 스냅샷 결과를 Power BI 보고서로 사용자에게 배포할 수 있습니다. 필요에 따라 데이터 스냅샷을 수동으로 유지 관리되는 다른 데이터와 병합해야 할 수 있습니다(예: 테넌트 설정에 대한 설명, 설정에 대한 근거, 추가 정보에 대한 링크 또는 액세스를 요청하는 양식에 대한 링크).

참고 항목

앞서 2단계에서 설명한 것처럼 의사 결정 프로세스와 관련된 설명서도 있습니다. 일반적으로 이러한 유형의 설명서는 모든 Power BI 사용자가 아닌 COE 및 관리자만 사용할 수 있습니다. 간소화된 예제는 2단계를 참조하세요.

5단계: 테넌트 설정 관리

테넌트 설정은 지속적으로 주의해야 합니다. 다음은 고려해야 할 몇 가지 측면입니다.

• 새 테넌트 설정: 새 테넌트 설정을 사용할 수 있는 시기를 어떻게 알 수 있나요? Fabric은 계속 발전하는 클라우드 서비스이므로 새 테넌트 설정이 정기적으로 도입될 것으로 예상할 수 있습니다. 새 테넌트 설정을 인식하는 한 가지 방법은 관리 포털의 테넌트 설정 페이지 맨 위에 발표된 메시지를 보는 것입니다. 또 다른 방법은 현재 스냅샷에서 추출한 데이터를 이전 스냅샷(이전에 4단계에서 설명)과 비교하는 것입니다.
• 기존 테넌트 설정 변경: 기존 테넌트 설정의 동작이 변경된 시기를 어떻게 알 수 있나요? 테넌트 설정 변경 내용은 일반적으로 Power BI 블로그 또는 패브릭 블로그에서 발표됩니다. 알림을 인식하려면 다음 블로그를 따라야 합니다.
• 진행 중인 사용자 요청: 사용자 요청을 어떻게 관리하나요? 예를 들어 콘텐츠를 인증하려는 사용자는 요청을 제출하여 허용하는 특정 보안 그룹의 구성원이 되는 것을 알고 있습니다. 이는 위의 4단계에서 설명한 대로 사용자가 참조할 테넌트 설정에 대한 설명서를 게시하여 사용할 수 있는 효과적인 워크플로입니다. 이러한 유형의 요청을 수집하기 위해 양식을 사용하도록 선택할 수 있습니다. 또는 지원팀을 통해 요청을 라우팅할 수 있습니다.
• 새 보안 그룹: 테넌트 설정을 특정 보안 그룹으로 제한해야 하는 경우 적합한 보안 그룹이 이미 있나요? 아니면 새 보안 그룹을 만들어야 할까요? 필요한 경우 새 보안 그룹을 만드는 방법을 조정하시겠습니까? 자세한 내용은 그룹 사용 전략을 참조하세요.

6단계: 테넌트 설정 감사

마지막으로 테넌트 설정을 정기적으로 감사하는 프로세스가 있어야 합니다. 다음은 테넌트 설정을 감사할 때 식별하는 몇 가지 작업입니다.

• 테넌트 설정이 변경됨: UpdatedAdminFeatureSwitch 작업을 사용하여 활동 로그에서 변경된 값을 찾습니다. 이 활동은 항목이 업데이트되었음을 나타냅니다(사용 또는 사용 안 함 또는 다른 보안 그룹이 할당되었는지 여부). 변경된 내용을 이해하려면 현재 스냅샷을 이전 스냅샷과 비교해야 합니다(이전에 4단계에서 설명).
• 새 테넌트 설정이 도입됨: 관리 포털에서 메시지를 찾거나 현재 스냅샷에서 추출한 데이터를 이전 스냅샷(4단계에서 설명)과 비교합니다.
• 그룹 멤버 자격이 변경됨: 경우에 따라 할당된 보안 그룹을 아는 것만으로는 충분하지 않을 수 있습니다. 개별 사용자 및 서비스 주체로 구성될 수 있는 보안 그룹 멤버 자격을 결정해야 할 수 있습니다. Microsoft Graph를 사용하여 그룹 멤버 자격 데이터를 원본으로 만들 수 있습니다. 자세한 내용은 사용자 및 그룹 데이터를 참조하세요.

또한 테넌트 설정이 업데이트될 때 경고 알림을 받을 수도 있습니다. 테넌트 설정이 변경된 경우, UpdatedAdminFeatureSwitch 감사 로그 이벤트를 사용하여 테넌트 설정이 변경된 시점과 변경한 사용자를 알 수 있도록 Microsoft 365 또는 클라우드 앱용 Microsoft Defender의 감사 로그 알림 기능을 사용할 수 있습니다. 경고를 사용하도록 설정하는 방법에 대한 자세한 내용은 테넌트 수준 감사를 참조하세요.

검사 목록 – 테넌트 설정을 계획하고 관리하는 경우 주요 의사 결정 및 작업에는 다음이 포함됩니다.

• 모든 현재 테넌트 설정을 검토: 모든 테넌트 설정을 검토하여 현재 상태를 확인합니다. 각 설정에 할당된 보안 그룹을 식별합니다.
• 기존 정책 및 의사 결정 식별: 기존 거버넌스 정책 또는 이전 결정을 쉽게 사용할 수 있도록 컴파일합니다.
• 토론 및 결정: 워크샵을 예약하여 허용되거나 허용되지 않아야 하는 항목과 사용자를 고려하고 결정합니다. 모든 의사 결정이 데이터 문화권 목표, 거버넌스 지침 및 내부 정책에 부합하는지 확인합니다. 각 토픽에 대한 모든 관련 의사 결정자 및 관련자를 참여해야 합니다. 적절한 경우 추가 승인을 받습니다.
• 결정을 다시 검토하는 일정 만들기: 정기적으로 의사 결정 및 테넌트 설정을 다시 검토하도록 일정을 설정합니다(예: 1년 2회).
• 업데이트 수행: 워크샵의 결정에 따라 테넌트 설정을 업데이트합니다.
• API를 사용하여 스냅샷 데이터 추출: 테넌트 설정 가져오기 REST API를 사용하여 프로세스를 보다 효율적으로 만들고 예약된 기준으로 스냅샷 생성을 자동화할 수 있습니다.
• 사용자에 대한 설명서 만들기: 사용자 커뮤니티에 대한 테넌트 설정 설명서를 만듭니다. 중앙 집중식 포털에 설명서를 게시합니다. 사용자가 기능 또는 기능에 액세스하기 위해 속해야 하는 보안 그룹을 포함합니다.
• 사용자 요청을 처리하는 프로세스 만들기: 사용자가 기능 또는 기능에 대한 액세스를 요청하는 방법에 대한 프로세스를 설정합니다.
• 테넌트 설정의 일상적인 관리를 위한 프로세스 설정: 가능한 한 빨리 새 테넌트 설정을 식별할 수 있도록 일정을 만듭니다.
• 감사 설정: 테넌트 설정이 변경된 시기와 대상을 추적할 수 있도록 감사 프로세스를 만듭니다.

도메인 관리

도메인은 패브릭에서 비슷한 특성을 가진 둘 이상의 작업 영역을 그룹화하기 위해 사용됩니다. 예를 들어 영업 작업 영역을 모두 하나로 그룹화한 도메인과 재무 작업 영역을 그룹화한 또 다른 도메인을 만들 수 있습니다. 도메인은 단일 관리 경계를 나타냅니다. 또한 도메인을 사용하면 조직 전체에 분산된 작업 영역 소유권 및 관리 책임을 용이하게 할 수 있습니다.

도메인을 계획하는 방법에 대한 자세한 내용은 작업 영역 도메인을 참조하세요.

팁

이 섹션에서 설명하는 패브릭 도메인은 Microsoft 365의 도메인과는 다른 개념입니다.

1단계: 도메인 검토

첫 번째 단계는 현재 상태를 이해할 수 있도록 기존 도메인 및 테넌트 환경을 검토하는 것입니다. 다음은 검토 프로세스 중에 고려해야 할 몇 가지 요소입니다.

• 도메인: 어떤 도메인(있는 경우)이 있나요? 각 도메인의 이름과 설명이 해당 목적을 명확하게 나타내나요?
• 사용 권한: 각 도메인의 도메인 관리자는 누구인가요? 각 도메인에 대한 도메인 기여자는 누구인가요? 할당된 모든 관리자 및 기여자가 도메인의 의도된 목적에 부합하나요?
• 할당된 작업 영역: 각 도메인에 할당된 작업 영역은 무엇인가요? 할당된 모든 작업 영역이 도메인의 의도된 목적과 일치하나요?
• 위임된 테넌트 설정: 기본 설정을 재정의할 수 있도록 도메인 관리자(또는 용량 관리자)에게 위임된 테넌트 설정은 무엇입니까?

2단계: 도메인 결정

도메인을 검토한 후에는 의사 결정 프로세스를 검토해야 합니다.

기존 작업 영역의 경우 그룹화하여 단일 관리 경계를 구성하는 방법을 고려합니다. 관련 작업 영역을 구성할 수 있는 자세한 내용과 방법은 작업 영역 도메인을 참조하세요.

의사 결정 과정에서 고려해야 할 몇 가지 요소는 다음과 같습니다.

• 이미 존재하는 거버넌스 결정은 무엇인가요? 가능하면 기존 결정을 참조하세요. 일관되고 효율적인 작업 영역 및 도메인 설정을 목표로 합니다.
• 콘텐츠의 소유권과 관리는 얼마나 분산되어 있나요? 현재 조직 전체에서 콘텐츠 소유권 및 관리가 어떻게 이루어지는지 고려합니다. 분산형 접근 방식을 분산형, 페더레이션 또는 데이터 메시 아키텍처라고도 합니다. 작업 영역을 도메인으로 구성하기 위한 요구 사항을 분석할 때 해당 정보를 고려합니다.
• 어떤 도메인 그룹화가 제대로 작동할까요? 여러 가지 방법으로 작업 영역을 단일 관리 경계로 그룹화할 수 있습니다. 예를 들어 주제 영역, 팀, 사업부 또는 프로젝트별로 도메인을 구성하도록 선택할 수 있습니다. 작업 영역은 하나의 도메인에만 할당할 수 있습니다. 자세한 내용은 작업 영역 도메인을 참조하세요.
• 각 도메인을 관리할 수 있는 사람은 누구인가요? 이상적으로 도메인 관리자는 도메인의 콘텐츠를 직접 소유하고 관리하는 사용자입니다. 또한 도메인 관리자는 해당 주제에 대한 내부, 지역 및 정부 규정을 잘 알고 있어야 합니다. 또한 모든 내부 거버넌스 및 보안 요구 사항을 잘 알고 있어야 합니다.
• 도메인에 작업 영역을 할당할 수 있는 사람은 누구인가요? 도메인 기여자 역할에는 도메인에 작업 영역을 할당할 수 있는 사용자가 포함됩니다. 또한 도메인 기여자는 작업 영역을 도메인에 할당하는 작업 영역 관리자여야 합니다. 조직의 셀프 서비스 사용자에게 위임할 제어량을 고려합니다.
• 다른 도메인이 다르게 처리되나요? 대규모 조직에서는 일부 도메인에 다른 정책이 있을 수 있습니다. 다양한 팀의 요구 사항과 기술에 따라 결정을 조정할 준비를 합니다. 자세한 내용은 테넌트 수준 설정 재정의를 참조하세요.

3단계: 도메인 업데이트

이 시점에서 기존 도메인 설정 및 의도적인 결정을 사용할 수 있습니다. 이제 도메인을 추가, 변경 또는 제거할 준비가 되었습니다(필요한 경우).

기존 변경 관리 사례를 따르고 변경 내용의 영향을 받는 모든 사용자에게 알려야 합니다.

4단계: 문서 도메인

도메인 수에 따라 관리 포털에서 사용할 수 있는 정보를 보강하는 설명서를 만들 수 있습니다. 설명서에는 다음이 포함될 수 있습니다.

• 도메인의 용도 및 별도의 도메인이 유용한 이유와 같은 더 많은 컨텍스트 또는 세부 정보입니다.
• 도메인을 승인한 사용자 및 시기.
• 도메인 소유자 또는 관리자가 누구인지(관리 포털에 설정된 도메인 관리자와 다른 경우)
• 도메인과 관련된 기타 규정 준수 또는 규정 요구 사항

5단계: 도메인 관리

도메인은 관리 포털에서 정기적으로 검토해야 합니다. 분기별 또는 일년에 두 번 이 목적을 위해 잘 작동해야 합니다.

또한 새 도메인을 만들거나, 기존 도메인을 변경하거나, 도메인에 작업 영역을 추가하려는 사용자의 요청을 관리하는 방법을 고려합니다.

6단계: 도메인 감사

도메인 및 해당 설정을 정기적으로 감사하는 프로세스가 있어야 합니다. 다음은 활동 로그를 사용하여 도메인을 감사할 때 식별하는 몇 가지 작업입니다.

• 새 도메인이 생성됨: InsertDataDomainAsAdmin 활동을 찾습니다.
• 기존 도메인이 변경됨: UpdateDataDomainAsAdmin 활동을 찾습니다.
• 작업 영역이 도메인에 할당된 경우: UpdateDataDomainFoldersRelationsAsAdmin 활동을 찾습니다.
• 도메인 관리자 또는 도메인 기여자가 변경됨: UpdateDataDomainAccessAsAdmin 활동을 찾습니다.

검사 목록 - 도메인을 계획하고 관리할 때 주요 의사 결정 및 작업에는 다음이 포함됩니다.

• 현재 도메인 검토: 관리 포털에서 모든 도메인을 검토하여 현재 상태를 확인합니다.
• 토론 및 결정: 요구 사항에 가장 적합한 도메인 그룹을 결정합니다. 도메인을 관리하는 방법을 고려할 때 관련 의사 결정자 및 관련자를 참여시킵니다.
• 승인이 필요한지 확인: 새 도메인을 만들 때 다른 사용자의 승인을 얻기 위해 프로세스가 있는지 여부를 확인합니다.
• 다시 검토할 일정 만들기: 정기적으로 도메인을 다시 검토하도록 일정을 설정합니다.
• 업데이트 수행: 새 요구 사항이 발생할 때 도메인을 업데이트합니다.
• 설명서 만들기: 다른 정보를 기록해야 하는 경우 도메인에 대한 설명서를 만듭니다.
• 사용자 요청을 처리하는 프로세스 만들기: 사용자가 새 도메인을 요청할 수 있는 방법에 대한 프로세스를 설정합니다.
• 감사 설정: 새 도메인이 생성되는 시기 또는 변경이 발생하는 시기를 추적할 수 있도록 감사 프로세스를 만듭니다.

작업 영역 관리

작업 영역은 패브릭의 기본 개념입니다. 작업 영역은 콘텐츠를 저장하고 보호하기 위한 컨테이너 역할을 합니다. 주로 작업 영역은 콘텐츠 만들기, 공동 작업 및 콘텐츠 배포를 위해 설계되었습니다.

관리 포털의 작업 영역 페이지를 사용하면 패브릭 관리자가 테넌트에서 모든 작업 영역을 검토하고 관리할 수 있습니다.

다음은 패브릭 관리자가 작업 영역 관리에 참여할 수 있는 몇 가지 이유입니다.

• 표준 작업 영역에 대한 액세스를 가져옵니다. 패브릭 관리자는 콘텐츠의 기본 소유자가 휴가 중일 때와 같은 상황(예: 데이터 새로 고침 실패)을 지원해야 할 수 있습니다. 이 경우 작업 영역 역할에 자신을 할당해야 합니다.
• 개인 작업 영역에 대한 임시 액세스를 가져옵니다. 패브릭 관리자는 24시간 동안만 다른 사용자의 개인 작업 영역에 액세스할 수 있습니다. 개인 작업 영역에 대한 임시 액세스는 작업 영역 소유자가 조직을 떠나거나 휴가 중일 때 유용합니다.
• 작업 영역 역할을 관리합니다. 패브릭 관리자는 테넌트에 있는 모든 작업 영역에 대한 작업 영역 역할을 관리할 수 있는 권한이 있습니다. 이는 중앙 집중식 팀이 작업 영역 액세스를 관리하는 경우에 유용합니다. 또한 작업 영역이 분리된 상태(작업 영역 관리자가 없음을 나타낸)에 있는 경우에도 유용합니다. 이는 고용 종료 또는 이전의 결과로 발생할 수 있습니다.
• 작업 영역을 다시 할당합니다. 다른 기능의 잠금을 해제하려면 작업 영역에 대한 작업 영역 라이선스 모드 를 업데이트해야 하는 경우도 있습니다. 예를 들어 패브릭 관리자는 작업 영역을 Pro 또는 PPU(사용자 단위 Premium)에서 용량으로 변경할 수 있습니다.
• 작업 영역의 유형을 확인합니다. 패브릭 관리자는 작업 영역이 할당된 SKU 계층을 검토할 수 있습니다. 예를 들어 관리자는 현재 PPU에 할당된 테넌트에 4개의 작업 영역이 있는지 빠르게 확인할 수 있습니다.
• 삭제된 작업 영역을 찾거나 복구합니다. 작업 영역 상태는 작업 영역이 삭제되었음을 나타낼 수 있습니다. 잠시 동안 패브릭 관리자는 작업 영역이 오류로 삭제된 경우 복원할 수 있습니다. 또는 삭제된 개인 작업 영역을 표준 작업 영역으로 복원할 수 있습니다. 자세한 내용은 작업 영역 보존을 참조하세요.
• 작업 영역 이름을 업데이트합니다. 패브릭 관리자는 이름이 설정된 명명 규칙을 준수하지 않기 때문에 작업 영역의 이름을 바꿀 수 있습니다.

참고 항목

작업 영역 관리에 대한 참여 수준은 패브릭 관리자에게 할당된 역할 및 책임에 따라 달라집니다. 콘텐츠 소유권 및 관리에 대한 전략은 패브릭 관리자가 작업 영역 관리에 참여하는 정도에도 영향을 줄 수 있습니다.

1단계: 작업 영역 검토

첫 번째 단계는 현재 상태를 이해할 수 있도록 기존 작업 영역 및 테넌트 환경을 검토하는 것입니다. 다음은 검토 프로세스 중에 고려해야 할 몇 가지 요소입니다.

• 현재 작업 영역: 현재 존재하는 모든 작업 영역을 검토합니다. 또한 각 작업 영역의 역할 할당 및 설정을 검토하여 적절한지 확인해야 합니다.
• 현재 테넌트 설정: 작업 영역 만들기 테넌트 설정의 현재 설정을 검토합니다.

현재 작업 영역 목록을 컴파일하는 방법에는 두 가지가 있습니다.

• 관리 포털에서 작업 영역 목록을 봅니다. 목록을 CSV 파일로 내보낼 수 있습니다.
• 다음을 사용하여 관리자 API를 사용하여 테넌트 인벤토리를 프로그래밍 방식으로 추출합니다.
  • 메타데이터 스캔 API(스캐너 API라고도 함). 이 API 집합을 사용하면 변경된 작업 영역을 비동기적으로 찾을 수 있습니다. 증분 방식으로 변경된 작업 영역을 추출할 수 있으므로 작업 영역이 많은 대규모 조직에 가장 적합합니다. 자세한 내용은 메타데이터 검사 API를 참조하세요.
  • 관리자로 그룹 가져오기 REST API 또는 Get-PowerBIWorkspace PowerShell cmdlet. 이러한 메서드는 테넌트의 모든 작업 영역에 대한 데이터를 반환하므로 데이터 볼륨이 낮은 소규모 조직에 가장 적합합니다. 자세한 내용은 그룹 API 또는 작업 영역 cmdlet을 참조하세요.

2단계: 작업 영역 결정

작업 영역을 검토한 후에는 의사 결정 프로세스를 검토해야 합니다.

의사 결정 과정에서 고려해야 할 몇 가지 요소는 다음과 같습니다.

• 이미 존재하는 거버넌스 결정은 무엇인가요? 가능하면 기존 작업 영역 거버넌스 결정을 참조하세요. 작업 영역 설정이 일관되고 효율적이되도록 하는 것을 목표로 합니다.
• 작업 영역을 만들 수 있는 사람은 누구인가요? 작업 영역 만들기 권한은 데이터 문화권 및 거버넌스 결정이라는 점을 고려합니다.
• 작업 영역을 만들기 위한 특정 프로세스가 있어야 하나요? 사용자가 따라야 하는 간단하고 편리한 작업 영역 만들기 프로세스를 설정하는 것이 중요합니다.
• 작업 영역의 이름은 어떻게 지정해야 하나요? 작업 영역 명명 규칙이 조직에 도움이 되는지 여부를 결정합니다.
• 작업 영역은 어떻게 구성되나요? 주제 및 범위별로 작업 영역을 구성하는 것이 유용한 경우가 많습니다. 콘텐츠를 작업 영역으로 구성하는 방법은 부서마다 다를 수 있습니다.
• 개인 작업 영역에 포함된 콘텐츠의 양은 얼마나 되나요? 조직 내에서 개인 작업 영역의 적절한 용도를 고려합니다.
• 누가 작업 영역에 액세스할 수 있어야 하나요? 주로 콘텐츠를 만들고 관리하는 사용자에 대한 작업 영역 액세스를 제한해야 합니다. 자세한 내용은 콘텐츠 작성자 보안 계획을 참조하세요.

추가 고려 사항은 테넌트 수준 작업 영역 계획 및 작업 영역 수준 작업 영역 계획을 참조하세요.

3단계: 작업 영역 업데이트

이 시점에서 기존 작업 영역 및 의도적인 의사 결정을 사용할 수 있습니다. 작업 영역의 이름을 바꾸거나 다시 구성할 수 있는 경우 이제 필요한 조정을 수행할 준비가 되었습니다.

업데이트 프로세스 중 고려 사항은 다음과 같습니다.

• 업데이트는 누가 처리하나요? 여러 패브릭 관리자가 있는 경우 작업 영역이 한두 명의 특정 관리자에 의해 관리되는지 여부를 결정합니다. 프로세스가 일관되고 잘 이해되고 잘 제어되는지 확인합니다.
• 변경 관리 프로세스가 있나요? 의사 결정, 설명서 및 결과 업데이트 간의 불일치를 방지하는 방법을 고려합니다. 팀 간 커뮤니케이션은 변경 관리의 주요 성공 요소입니다. 감사 요구 사항에 따라 내부 변경 로그를 유지하여 변경한 사람, 시기 및 이유를 추적하도록 선택할 수 있습니다(활동 로그에 캡처된 내용 이상의 세부 정보를 기록하기 위해).
• 사용자와의 커뮤니케이션은 어떻게 처리되나요? 사용자가 수행할 수 있는 일에 영향을 주는 변경을 수행할 때 변경 내용을 전달해야 합니다. 항상 사용자 불만 및 불필요한 지원 요청을 방지하는 것을 목표로 합니다.

4단계: 문서 작업 영역

작업 영역 수에 따라 관리 포털 또는 REST API에서 사용할 수 있는 정보를 보강하는 설명서를 만들 수 있습니다. 이러한 유형의 설명서는 테넌트 인벤토리의 핵심 부분입니다. 설명서에는 다음이 포함될 수 있습니다.

• 작업 영역에 대한 의도된 목적과 같은 더 많은 컨텍스트 또는 세부 정보(작업 영역 설명에 아직 언급되지 않은 경우).
• 작업 영역을 승인한 사용자 및 시기.
• 소유자가 작업 영역 관리자와 다른 경우 작업 영역 소유자로 할당된 사용자입니다.
• 작업 영역에 저장된 콘텐츠와 관련된 규정 준수 또는 규정 요구 사항입니다.
• 작업 영역에 특히 중요한 정보가 포함되어 있는지 여부입니다.
• 작업 영역에 대한 거버넌스 요구 사항입니다.
• 작업 영역에 적용할 수 있는 수명 주기 관리 프로세스입니다.

5단계: 작업 영역 관리

작업 영역을 지속적으로 관리하는 데는 주로 다음이 포함됩니다.

• 새 작업 영역 만들기
• 작업 영역 메타데이터 업데이트(예: 이름 또는 설명).
• 작업 영역 역할을 업데이트합니다.
• 삭제된 작업 영역 복구.
• 작업 영역을 다시 할당합니다(예: Pro에서 PPU로).
• 작업 영역 만들기 테넌트 설정 관리.

역할 및 책임에 따라 보조 관리자 활동에는 다음이 포함될 수 있습니다.

• 작업 영역에 콘텐츠(예: 의미 체계 모델 또는 보고서)를 게시합니다.
• 기존 작업 영역 콘텐츠와 관련된 문제 해결

Important

패브릭 관리자 역할은 많은 상위 수준 기능을 수행할 수 있는 높은 권한 역할입니다. 특히 역할은 테넌트의 모든 데이터에 대한 액세스 권한을 자동으로 부여하지 않습니다. 그러나 관리자는 테넌트에서 작업 영역을 관리할 권한이 있으므로 자신을 포함한 다른 사용자에게 액세스 권한을 부여할 수 있습니다(작업 영역 역할을 통해).

6단계: 작업 영역 감사

작업 영역을 정기적으로 감사하는 프로세스가 있어야 합니다. 다음은 활동 로그를 사용하여 작업 영역을 감사할 때 식별하는 몇 가지 작업입니다.

• 작업 영역 만들기 테넌트 설정이 변경됨: UpdatedAdminFeatureSwitch 작업을 사용하여 활동 로그에서 변경된 테넌트 설정 값을 찾습니다. 항목 이름은 CreateAppWorkspaces입니다.
• 패브릭 관리자가 사용자의 개인 작업 영역에 대한 액세스 권한을 얻음: AddAdminPersonalWorkspaceAccess 활동을 찾습니다. 작업 영역 이름은 PersonalWorkspace-NameOfUser 형식입니다. 시스템이 24시간 후에 발생하는 액세스를 자동으로 취소할 때 활동이 기록되지 않습니다.
• 새 작업 영역이 생성됨: CreateFolder 작업을 찾습니다.
• 기존 작업 영역이 변경됨: UpdateFolder 작업을 찾습니다.
• 작업 영역에 대한 액세스가 변경됨: UpdateWorkspaceAccess 작업 또는 UpdateFolderAccess 활동을 찾습니다.
• 작업 영역이 다시 할당됨: MigrateWorkspaceIntoCapacity 활동을 찾습니다.
• 작업 영역이 도메인에 할당된 경우: UpdateDataDomainFoldersRelationsAsAdmin 활동을 찾습니다.

팁

활동 로그를 사용하는 것 외에도 테넌트 인벤토리를 정기적으로 만드는 것이 좋습니다. 모든 작업 영역과 해당 콘텐츠(예: 의미 체계 모델 및 보고서)를 설명하는 특정 시점의 스냅샷입니다. 작업 영역 액세스에 대한 세부 정보를 캡처할 수도 있습니다. 자세한 내용은 테넌트 인벤토리 및 테넌트 인벤토리 데이터에 대한 액세스를 참조하세요.

검사 목록 - 작업 영역을 계획하고 관리하는 경우 주요 의사 결정 및 작업에는 다음이 포함됩니다.

• 현재 작업 영역 검토: 관리 포털에서 모든 작업 영역 및 관련 테넌트 설정을 검토하여 현재 상태를 확인합니다.
• 토론 및 결정: 작업 영역을 관리하고 관리하는 방법을 결정합니다. 작업 영역을 관리할 수 있는 사람을 결정할 때 관련 의사 결정자와 관련자를 참여시킵니다.
• 승인이 필요한지 확인: 새 작업 영역을 만들 때 다른 사용자의 승인을 얻기 위해 프로세스가 있는지 여부를 확인합니다.
• 다시 검토할 일정 만들기: 정기적으로 작업 영역을 다시 검토하도록 일정을 설정합니다.
• 업데이트 수행: 새 요구 사항이 발생할 때 역할 할당을 포함한 작업 영역을 업데이트합니다.
• 설명서 만들기: 추가 정보를 추적해야 하는 경우 작업 영역에 대한 설명서를 만듭니다.
• 사용자 요청을 처리하는 프로세스 만들기: 사용자가 새 작업 영역을 요청하는 방법에 대한 프로세스를 설정합니다.
• 감사 설정: 새 작업 영역이 만들어진 시기 또는 변경이 발생하는 시기를 추적할 수 있도록 감사 프로세스를 만듭니다.

embed 태그 관리

웹 에 게시 기능을 사용하면 Power BI에서 embed 태그를 생성합니다. embed 태그는 누구나 인터넷에서 사용할 수 있는 웹 페이지에 보고서를 포함하는 데 사용됩니다. 이 기능은 특정 용도로 사용할 수 있습니다. 이 기능은 주로 인증을 요구하지 않고 익명 대상 사용자가 볼 수 있는 공개 데이터가 포함된 데이터 저널리즘 또는 보고서를 위한 것입니다.

Embed 태그를 정기적으로 검토하고 관리하는 것은 패브릭 관리자의 주요 책임입니다. 인터넷에 공개적으로 게시된 보고서를 확인하는 작업이 포함되기 때문에 특히 중요한 책임입니다.

주의

일부 관리자는 내부 애플리케이션 또는 인트라넷 사이트가 웹에 게시 보고서를 포함하기에 안전한 위치라고 잘못 생각합니다. 웹에 게시를 통해 게시된 보고서는 포함 위치에 관계없이 검색 엔진에서 검색할 수 있으므로 이 방법을 사용하지 않는 것이 좋습니다. 내부 대상 그룹에 Power BI 콘텐츠를 포함하는 적절한 방법은 API 포함 기능을 사용하거나 코드 없는 포함 기술을 사용하는 것입니다. 자세한 내용은 조직 사용 시나리오에 대한 포함을 참조하세요.

1단계: embed 태그 검토

첫 번째 단계는 현재 상태를 이해할 수 있도록 기존 embed 태그 및 테넌트 환경을 검토하는 것입니다. 다음은 검토 프로세스 중에 고려해야 할 몇 가지 요소입니다.

• 현재 embed 태그: 관리 포털의 모든 작업 영역에서 각 embed 태그를 검토합니다. 각 embed 태그 상태(예: 활성 또는 차단됨)를 기록해 둡니다.
• 현재 테넌트 설정: 웹에 게시 테넌트 설정의 현재 설정을 검토합니다.

2단계: embed 태그 결정

embed 태그를 검토한 후에는 의사 결정 프로세스를 검토해야 합니다. 웹에 게시할 수 있는 콘텐츠(있는 경우)에 대한 논의에 관련 의사 결정자 및 관련자를 참여시킵니다.

또한 웹에 보고서를 게시할 수 있는 사용자를 결정합니다. 거버넌스 정책 또는 보안 정책이 있는 경우 가능하면 언제든지 참조하세요.

Important

매우 제한된 사용자 집합에 대해 웹에 게시 테넌트 설정을 사용하도록 설정하는 것이 좋습니다. 중요한 데이터가 포함된 보고서를 실수로 게시할 위험이 높기 때문에 콘텐츠 작성자가 웹에 게시하는 것을 허용하지 않거나 제한하는 것이 좋습니다.

3단계: embed 태그 업데이트

이 시점에서 기존 embed 태그 및 의도적인 결정을 사용할 수 있습니다. 이제 기존 embed 태그를 임시 또는 영구적으로 변경할 준비가 되었습니다.

필요한 업데이트를 확인하려면 몇 가지 추가 조사를 수행해야 할 수 있습니다.

• 활성 embed 태그가 있는 모든 보고서를 검토하여 웹에 게시되는 부적절한 정보가 없는지 확인합니다. 또한 기본 의미 체계 모델에 기밀 또는 독점 정보가 포함되어 있지 않은지 확인합니다.
• 보고서를 게시한 사용자에게 문의하여 목적을 명확히 합니다.
• 콘텐츠 소유자와 협력하여 필요한 경우 목적에 적합한 개인이 아닌 작업 영역으로 콘텐츠를 재배치합니다. 공개적으로 사용 가능한 콘텐츠가 포함되어 있음을 명확하게 나타내는 작업 영역을 사용하는 것이 좋습니다. 예를 들어 재무 보고 [공용] 작업 영역 이름은 해당 용도를 명확하게 나타냅니다.
• 콘텐츠에 할당된 민감도 레이블을 검토합니다. 민감도 레이블이 대상 대상이 공개 대상 그룹임을 나타내는지 확인합니다.

4단계: 문서 embed 태그

상황에 따라 관리 포털에서 사용할 수 있는 정보를 보완하는 몇 가지 설명서를 만들 수 있습니다. 설명서에는 다음이 포함될 수 있습니다.

• 목적, 의도된 대상 그룹 및 정당성과 같은 더 많은 컨텍스트와 세부 정보
• 콘텐츠를 공개적으로 게시하도록 승인한 사용자 및 시기
• 콘텐츠 소유자가 누구인지( 게시한 사용자와 다른 경우)

5단계: embed 태그 관리

embed 태그는 관리 포털에서 정기적으로 모니터링해야 합니다. 또한 보고서를 웹에 게시하려는 사용자의 요청을 관리하는 방법을 고려합니다.

참고 항목

모든 보고서가 웹에 게시와 함께 지원되는 것은 아닙니다. 사용자에게 기능 사용과 관련된 지원 질문이 있을 수 있습니다.

6단계: embed 태그 감사

embed 태그를 정기적으로 감사하는 프로세스가 있어야 합니다. 다음은 활동 로그를 사용하여 embed 태그를 감사할 때 식별하는 몇 가지 작업입니다.

• 새 embed 태그가 생성됨: PublishToWebReport 활동을 찾습니다.
• 웹 에 게시 테넌트 설정이 변경됨: UpdatedAdminFeatureSwitch 작업을 사용하여 활동 로그에서 변경된 테넌트 설정 값을 찾습니다. 항목 이름은 PublishToWeb입니다.

검사 목록 - embed 태그를 계획하고 관리하는 경우 주요 결정 및 작업에는 다음이 포함됩니다.

• 현재 embed 태그 검토: 관리 포털에서 모든 embed 태그를 검토하여 현재 상태를 확인합니다.
• 현재 테넌트 설정 검토: 웹에 게시 테넌트 설정의 설정을 검토합니다.
• 토론 및 결정: 공개적으로 게시할 수 있는 콘텐츠와 사용자가 게시할 수 있는 콘텐츠(있는 경우)를 결정합니다. 적절한 경우 관련 의사 결정자 및 이해 관계자를 참여시킵니다. 가능하면 기존 거버넌스 정책을 참조하세요.
• 승인이 필요한지 확인: 웹에 보고서를 게시할 때 다른 사람의 승인을 얻기 위해 프로세스가 있는지 여부를 확인합니다.
• 다시 검토할 일정 만들기: 정기적으로 embed 태그를 다시 검토하도록 일정을 설정합니다.
• 업데이트 수행: 필요에 따라 현재 embed 태그를 업데이트합니다. 결정된 사항에 따라 웹에 게시 테넌트 설정을 업데이트합니다(현재 게시된 내용과 다른 경우).
• 설명서 만들기: 추가 정보를 추적해야 하는 경우 embed 태그에 대한 설명서를 만듭니다.
• 사용자 요청을 처리하는 프로세스 만들기: 사용자가 자신의 보고서를 웹에 게시하도록 요청하거나 자신의 보고서를 웹에 게시할 수 있는 권한을 갖는 방법에 대한 프로세스를 설정합니다.
• 감사 설정: 새 embed 태그가 만들어진 시기와 웹에 게시 테넌트 설정이 변경된 시기를 추적할 수 있도록 감사 프로세스를 만듭니다.

조직의 시각적 개체 관리

Power BI 보고서 작성자는 Power BI 보고서 디자인에서 여러 유형의 시각적 개체를 사용할 수 있습니다.

• 코어 시각적 개체: Power BI Desktop 및 Power BI 서비스에 기본 제공되는 기본 시각적 개체입니다.
• AppSource의 인증되지 않은 사용자 지정 시각적 개체: 타사 소프트웨어 공급업체 또는 전 세계 Power BI 커뮤니티의 구성원이 개발한 사용자 지정 시각적 개체입니다.
• AppSource의 인증된 사용자 지정 시각적 개체: 타사 소프트웨어 공급업체 또는 전 세계 Power BI 커뮤니티의 구성원이 개발했으며 Microsoft에서 정의한 인증 프로세스를 통과한 사용자 지정 시각적 개체입니다.

조직은 허용되는 특정 시각적 개체(및 버전)를 등록하여 사용자 지정 시각적 개체(보고서가 Power BI 서비스에 게시된 경우)의 사용을 제한하도록 선택할 수 있습니다. 허용되는 시각적 개체를 조직의 시각적 개체라고 합니다.

패브릭 관리자는 관리 센터에서 조직의 시각적 개체를 등록하고 관리할 책임이 있습니다. 다음을 등록할 수 있습니다.

• AppSource의 인증된 시각적 개체와 인증되지 않은 시각적 개체 모두. 특정 시각적 개체를 등록하는 것은 인증되지 않은(또는 모든) 시각적 개체 차단 테넌트 설정을 사용하도록 설정했지만 특정 시각적 개체의 유효성을 검사하고 조직에서 사용하도록 승인된 경우에 특히 유용합니다.
• 내부적으로 개발된 독점 시각적 개체.
• 공급업체에서 직접 구매한 사용자 지정 시각적 개체입니다.

조직의 시각적 개체를 등록할 때는 여러 가지 이점이 있습니다.

• 일부 또는 모든 사용자 지정 시각적 개체는 모든 보고서 작성자에 대한 시각화 창에서 자동으로 사용할 수 있습니다.
• 콘텐츠 작성자는 Power BI 시각적 개체(.pbiviz) 파일을 가져올 필요가 없습니다.
• 사용자 지정 시각적 개체의 버전은 모든 보고서에 대해 일관됩니다.
• 조직의 시각적 개체가 업데이트되면 보고서 및 대시보드가 자동으로 업데이트됩니다.
• 조직에서 널리 사용 가능해지기 전에 새 사용자 지정 시각적 개체와 변경된 사용자 지정 시각적 개체를 체계적으로 테스트하고 사전 승인할 수 있습니다.
• 기존 사용자 지정 시각적 개체가 더 이상 조직의 요구 사항을 충족하지 않는 경우 신속하게 사용하지 않도록 설정하거나 삭제할 수 있습니다.

사용자 디바이스에 사용자 지정 시각적 개체를 배포하는 방법에 대한 자세한 고려 사항(Power BI Desktop에서 사용)은 사용자 지정 시각적 개체를 참조하세요.

이 섹션의 나머지 부분에서는 조직의 시각적 개체 관리에 중점을 둡니다.

1단계: 조직의 시각적 개체 검토

첫 번째 단계는 현재 상태를 이해할 수 있도록 기존 조직의 시각적 개체 및 테넌트 환경을 검토하는 것입니다.

• 현재 조직의 시각적 개체: 조직의 시각적 개체 리포지토리에 추가된 사용자 지정 시각적 개체를 검토합니다.
• 현재 테넌트 설정: Power BI 시각적 개체 테넌트 설정의 설정을 검토합니다.

2단계: 조직의 시각적 개체 결정

조직의 시각적 개체를 검토한 후에는 의사 결정 프로세스를 검토해야 합니다. 사용자 지정 시각적 개체를 관리하는 방법에 대해 신중하게 결정할 준비가 되어 있어야 합니다.

의사 결정 과정에서 고려해야 할 몇 가지 질문은 다음과 같습니다.

• 조직에서 사용자 지정 시각적 개체를 허용하나요? 조직에서 사용자 지정 시각적 개체에 의존할 때 의도적으로 선택할 수 있는 몇 가지 이유가 있습니다.
  • 품질 및 안정성에 대한 기대는 사용자 지정 시각적 개체를 개발한 사람에 따라 달라집니다.
  • 자유롭게 사용할 수 있는 사용자 지정 시각적 개체에는 기술 지원이 없을 수 있습니다.
  • 중요한 데이터 개인 정보 보호 문제가 있거나 데이터 유출 문제에 매우 민감한 조직의 경우 사용자 지정 시각적 개체를 사용하는 것이 위험 프로필과 호환되지 않을 수 있습니다. 사용자 지정 시각적 개체가 의미 체계 모델에서 쿼리된 데이터에 액세스할 수 있기 때문입니다. 또한 사용자 지정 시각적 개체가 데이터를 웹 서비스로 다시 전송할 수 있습니다(API 호출 또는 AI 알고리즘 실행과 같은 합법적인 용도로 자주 사용됨).
• 사용자 지정 시각적 개체의 유효성을 검사하고 사용하도록 승인하려면 어떻게 할까요? 모든 사용자 지정 시각적 개체는 조직에서 사용하기 위해 테스트 및 사전 승인되어야 합니다. 이 유효성 검사 프로세스는 신뢰할 수 없는 시각적 개체가 사용되는 위험을 줄입니다. 또한 관리자가 테스트되고 사용하도록 승인된 버전을 지정할 수 있습니다.
• 사용자 지정 시각적 개체를 사용할 수 있는 사람은 누구인가요? Power BI SDK를 사용하여 만든 시각적 개체 허용 테넌트 설정은 사용자 지정 시각적 개체를 추가, 공유 또는 상호 작용할 수 있는 사용자를 제어합니다. 조직에서 AppSource 또는 가져온 .pbiviz 파일에서 이 기능을 제한하거나 제한하기로 결정한 경우 특정 사용자 지정 시각적 개체를 허용하는 방법으로 조직의 시각적 개체에 의존할 수 있습니다.
• 인증된 시각적 개체가 필요한가요? AppSource가 허용되는 경우 일부 조직에서는 인증된 시각적 개체로만 제한하는 것을 선호합니다. 이 작업은 인증된 시각적 개체만 추가 및 사용 테넌트 설정을 설정하여 수행됩니다. 이 경우 조직의 시각적 개체를 사용하여 조직에서 사용하도록 승인된 인증되지 않은 시각적 개체를 배포할 수 있습니다.
• 사용자 지정 시각적 개체를 중앙에서 관리해야 하나요? 개별 보고서 작성자가 AppSource에서 시각적 개체를 다운로드하는 경우 버전이 일치하지 않는 문제가 있을 수 있습니다. 조직의 시각적 개체 리포지토리를 사용하여 사용자 지정 시각적 개체를 중앙에서 관리하면 테넌트 내의 모든 Power BI 보고서 작성자가 동일한 승인된 버전을 사용할 수 있으므로 보고서 작성자가 프로세스를 더 간단하게 만들 수 있습니다. 그러나 패브릭 관리자가 참여해야 하므로 지연이 발생할 수 있습니다.
• 허용되는 원본은 무엇인가요? 조직의 시각적 개체는 AppSource 또는 .pbiviz 파일에서 올 수 있습니다. AppSource는 일반적으로 가장 좋은 소스이며, 특히 인증된 시각적 개체를 사용하려는 경우에 적합합니다. .pbiviz 파일은 시각적 개체가 공급업체에서 비공개로 가져온 경우 또는 내부적으로 개발된 경우에 적합합니다.
• 시각화 창에 사용자 지정 시각적 개체는 언제 표시되어야 하나요? 대부분의 경우 모든 보고서 작성자가 자동으로 사용할 수 있도록 사용자 지정 시각적 개체가 시각화 창에 표시되도록 하는 것이 적절합니다.

3단계: 조직의 시각적 개체 업데이트

이 시점에서 기존 조직의 시각적 개체와 의도적인 의사 결정을 사용할 수 있습니다. 이제 기존 조직의 시각적 개체를 임시 또는 영구적으로 변경할 준비가 되었습니다.

또한 사용자 지정 시각적 개체와 관련된 테넌트 설정을 수정해야 할 수도 있습니다(보고서 작성자가 조직의 시각적 개체 리포지토리에 없는 사용자 지정 시각적 개체를 다운로드하고 설치할 수 있는 경우).

참고 항목

사용자 지정 시각적 개체와 관련된 테넌트 설정은 Power BI Desktop의 보고서가 아닌 게시된 보고서에만 적용됩니다. 보고서 작성자가 Power BI 서비스와 Power BI Desktop 모두에서 일관된 사용자 지정 시각적 개체 옵션을 갖도록 하려면 그룹 정책을 사용하여 로컬 컴퓨터 사용자 지정 시각적 개체(Power BI Desktop용)를 관리해야 합니다. 자세한 내용은 사용자 도구 및 디바이스를 참조하세요.

4단계: 조직의 시각적 개체 문서화

상황에 따라 관리 포털에서 사용할 수 있는 정보를 보완하는 몇 가지 설명서를 만들 수 있습니다. 설명서에는 다음이 포함될 수 있습니다.

• 사용자 지정 시각적 개체가 수행하는 작업과 같은 더 많은 컨텍스트 및 세부 정보
• 사용자 지정 시각적 개체(예: 내부 개발자 또는 공급업체)를 만든 사용자 또는 자세한 내용을 보려면 연락할 사용자입니다.
• 시각적 개체를 업데이트할 때 반복할 수 있도록 시각적 개체의 유효성을 검사하기 위해 수행된 테스트입니다.
• 사용자 지정 시각적 개체의 사용을 승인한 사용자 및 시기

5단계: 조직의 시각적 개체 관리

조직의 시각적 개체는 관리 포털에서 정기적으로 모니터링해야 합니다. 또한 온라인에서 찾은 새 사용자 지정 시각적 개체를 사용하려는 사용자의 요청을 관리하는 방법을 고려합니다.

경우에 따라 각 사용자 지정 시각적 개체가 마지막으로 업데이트된 시점도 검토해야 합니다. 최신 버전을 사용할 수 있는지 여부를 조사합니다. 최신 버전을 사용할 수 있는 경우 테스트를 통과하면 조직의 시각적 개체를 업데이트할 수 있습니다.

6단계: 조직의 시각적 개체 감사

조직의 시각적 개체를 정기적으로 감사하는 프로세스가 있어야 합니다. 다음은 활동 로그를 사용하여 조직의 시각적 개체를 감사할 때 식별하는 몇 가지 작업입니다.

• 새 조직의 시각적 개체가 추가됨: InsertOrganizationalGalleryItem 활동을 찾습니다.
• 기존 조직의 시각적 개체가 업데이트됨: UpdateOrganizationalGalleryItem 활동을 찾습니다.
• Power BI SDK 테넌트 설정을 사용하여 만든 시각적 개체 허용이 변경됨: UpdatedAdminFeatureSwitch 작업을 사용하여 활동 로그에서 변경된 테넌트 설정 값을 찾습니다. 항목 이름은 CustomVisualsTenant입니다.
• 인증된 시각적 개체 추가 및 사용(인증되지 않은 차단) 테넌트 설정이 변경됨: UpdatedAdminFeatureSwitch 작업을 사용하여 활동 로그에서 변경된 테넌트 설정 값을 찾습니다. 항목 이름은 CertifiedCustomVisualsTenant입니다.

검사 목록 – 조직의 시각적 개체를 계획하고 관리하는 경우 주요 의사 결정 및 작업에는 다음이 포함됩니다.

• 현재 조직의 시각적 개체 검토: 관리 포털에서 모든 조직의 시각적 개체를 검토하여 현재 상태를 확인합니다.
• 현재 테넌트 설정 검토: 각 Power BI 시각적 개체 테넌트 설정을 검토합니다. 조직의 시각적 개체에 대한 의존도에 영향을 줄 수 있는 방법을 결정합니다.
• 토론 및 결정: 조직에서 사용자 지정 시각적 개체를 사용하는 방법과 사용자 지정 시각적 개체를 결정합니다. 조직의 시각적 개체, AppSource 및 .pbiviz 파일을 사용하는 방법을 고려할 때 관련 의사 결정자 및 관련자를 참여시킵니다.
• 다시 검토할 일정 만들기: 정기적으로 조직의 시각적 개체를 다시 검토하도록 일정을 설정합니다.
• 업데이트 수행: 필요에 따라 현재 조직의 시각적 개체를 업데이트합니다. 결정된 사항에 따라 Power BI 시각적 개체 테넌트 설정을 업데이트합니다(현재 게시된 내용과 다른 경우).
• 사용자 컴퓨터 관리: Power BI 서비스에서와 마찬가지로 Power BI Desktop에서도 사용자 지정 시각적 개체가 동일한 방식으로 관리되도록 그룹 정책을 설정합니다.
• 설명서 만들기: 추가 정보를 추적해야 하는 경우 조직의 시각적 개체에 대한 설명서를 만듭니다.
• 사용자 요청을 처리하는 프로세스 만들기: 사용자가 사용자 지정 시각적 개체의 사용을 요청하거나 특정 사용자 지정 시각적 개체에 대한 액세스를 요청하는 방법에 대한 프로세스를 설정합니다.
• 감사 설정: 새 사용자 지정 시각적 개체가 조직의 시각적 개체로 등록된 시기와 Power BI 시각적 개체 테넌트 설정이 변경된 시기를 추적할 수 있도록 감사 프로세스를 만듭니다.

Azure 연결 관리

Power BI는 Azure 서비스와 통합되어 기능을 확장하고 다른 기능을 제공할 수 있습니다. Azure 연결을 사용하는 세 가지 주요 이유가 있습니다.

• 데이터 흐름에 대한 데이터 스토리지(Gen1). Azure에서 직접 Power BI 데이터 흐름(Gen1)의 데이터에 액세스할 수 있습니다. 작업 영역은 테넌트 수준에서 정의된 스토리지 계정 또는 작업 영역과 관련된 스토리지 계정에 연결할 수 있습니다. 이 기술을 BYOL(bring-your-own-lake)이라고도 합니다. BYOL 전략의 유연성은 다른 프로세스 또는 다른 사용자가 데이터를 보거나 액세스할 수 있도록 하여 Power BI 이외의 데이터 흐름 데이터를 다시 사용하려는 경우에 유용합니다. 자세한 내용은 Azure Data Lake Storage Gen2를 사용하도록 데이터 흐름 스토리지 구성 및 셀프 서비스 데이터 준비 사용 시나리오를 참조하세요.

• 의미 체계 모델 백업 및 복원. 재해 복구를 위해, 데이터 보존 요구 사항을 충족하거나, 데이터 모델을 마이그레이션하기 위해 의미 체계 모델을 백업 및 복원해야 할 수 있습니다. 자세한 내용은 Power BI Premium을 사용하여 의미 체계 모델 백업 및 복원을 참조하세요.

• Azure Log Analytics 통합. 의미 체계 모델 활동, 성능 및 추세를 분석할 수 있습니다. Log Analytics 통합을 사용하면 Analysis Services 엔진(Power BI 의미 체계 모델을 호스트하는)에서 생성된 진단 데이터를 검토할 수 있습니다. 자세한 내용은 의미 체계 모델 이벤트 로그를 참조하세요.

  참고 항목

  데이터 세트 이름 변경은 Power BI 서비스 설명서에서 롤아웃되었지만 이벤트 로그 작업 이름과 같은 일부 인스턴스가 있을 수 있지만 아직 변경이 발생하지 않았습니다.

Azure 연결을 사용하는 주요 사용 사례가 데이터 스토리지(위의 첫 번째 지점에서 설명한 BYOL)에 대한 경우 대신 데이터 흐름 Gen2 및 OneLake를 사용하는 것이 좋습니다. 둘 다 데이터 스토리지에 ADLS Gen2를 사용하지만 서로 다른 기능을 제공하고, 용도가 약간 다르며, 데이터가 기록되는 방식에 따라 다른 스토리지 옵션을 사용합니다. 예를 들어 OneLake는 테이블 형식 데이터 및 데이터 흐름 Gen2 데이터를 열린 델타 Parquet 형식으로 저장하는 반면 Power BI 데이터 흐름(Gen1)(Azure 연결 포함)의 출력은 공통 데이터 모델 형식으로 데이터를 저장합니다. 자세한 내용은 데이터 흐름 1세대에서 2세대로 가져오기를 참조하세요.

이 섹션의 나머지 부분에서는 관리 포털에서 Azure 연결을 관리하는 데 중점을 둡니다.

1단계: Azure 연결 검토

첫 번째 단계는 현재 상태를 이해할 수 있도록 기존 Azure 연결 및 테넌트 환경을 검토하는 것입니다. 검토할 두 가지 영역이 있습니다.

먼저 관리 포털에서 기존 설정을 검토합니다.

• 현재 테넌트 수준 스토리지 설정: 테넌트 수준 스토리지가 현재 설정되는 방식을 검토합니다. 작업 영역 관리자가 작업 영역 설정 내에서 연결하도록 선택할 수 있는 기본 Azure 연결을 제공합니다.
• 현재 작업 영역 수준 스토리지 권한: 작업 영역 수준 스토리지 사용 권한이 사용되는지 여부를 검토합니다. 사용하도록 설정하면 작업 영역 관리자가 작업 영역을 자신의 ADLS Gen2 계정에 연결할 수 있습니다.

둘째, 작업 영역 관리자를 위한 Azure Log Analytics 연결 테넌트 설정의 설정을 검토합니다. 사용하도록 설정하면 작업 영역 관리자가 의미 체계 모델에 대한 진단 데이터를 전송하기 위해 작업 영역을 ADLS Gen2 계정에 연결할 수 있습니다.

2단계: Azure 연결 결정

Azure 연결을 검토한 후에는 의사 결정 프로세스를 검토해야 합니다.

의사 결정 과정에서 고려해야 할 몇 가지 질문은 다음과 같습니다.

• Azure 연결 사용이 데이터 전략 및 사용자 요구에 부합하나요? Azure 연결이 데이터 흐름 스토리지(Gen1)에 유용한지 여부를 고려합니다. 의미 체계 모델 백업 및 복원 기능을 사용해야 하는 요구 사항이 있는지 확인합니다. Azure Log Analytics 통합에 대한 요구 사항이 있는지 여부를 고려합니다.
• 중앙화 데이터 스토리지와 탈중앙화 데이터 스토리지는 어떻게 다른가요? 분산된 팀의 요구 사항과 개인 또는 부서가 현재 자체 Azure Storage 계정을 유지 관리하는지 여부를 이해합니다. 작업 영역 관리자가 자신의 ADLS Gen2 계정에 연결할 수 있는지 또는 모든 작업 영역(테넌트 수준 스토리지)에 하나의 ADLS Gen2 계정을 사용할지 여부를 결정합니다.
• OneLake는 Azure 연결과 어떻게 사용되나요? OneLake가 도입되면서 BYOL(데이터 스토리지)에 OneLake를 사용하여 점진적으로 이동할지 여부를 고려합니다.

자세한 내용은 ADLS Gen2와 작업 영역 통합을 참조하세요.

자세한 내용은 Azure Log Analytics와 작업 영역 통합을 참조하세요.

3단계: Azure 연결 업데이트

이 시점에서 기존 Azure 연결을 사용할 수 있으며 데이터 레이크를 Power BI와 통합할 것인지에 대한 의도적인 결정을 내렸습니다. 이제 필요한 경우 결과에 따라 설정을 조정할 준비가 되었습니다.

4단계: Azure 연결 문서화

상황에 따라 관리 포털에서 사용할 수 있는 정보를 보완하는 몇 가지 설명서를 만들어야 합니다. 설명서에는 다음이 포함될 수 있습니다.

• 사용이 승인된 테넌트 수준 데이터 레이크 위치입니다. 데이터 레이크를 소유하고 관리하는 사용자와 자세한 내용을 보려면 연락할 사용자를 포함합니다.
• 작업 영역 수준 데이터 레이크를 통합할 수 있는지 여부입니다. 향후 참조를 위해 주요 결정 사항 및 이유와 같은 기타 정보를 문서화해야 합니다.

5단계: Azure 연결 관리

Azure 연결은 관리 포털에서 수시로 모니터링해야 합니다.

조직에서 여러 ADLS Gen2 계정을 지원하는 방법을 고려합니다(작업 영역 수준 Azure 연결이 허용되는 경우).

또한 작업 영역을 Azure Log Analytics에 연결하려는 사용자의 요청을 관리하는 방법을 고려합니다.

6단계: Azure 연결 감사

Azure 연결을 정기적으로 감사하는 프로세스가 있어야 합니다. 활동 로그를 사용하여 Azure 연결을 감사할 때 식별할 수 있는 몇 가지 작업이 있습니다.

• 작업 영역이 ADLS Gen2에 연결됨: AddLinkToExternalResource 활동을 찾습니다. ResourceType은 스토리지 계정인지 로그 분석인지를 나타냅니다.
• 작업 영역이 ADLS Gen2에서 연결이 끊어짐: DeleteLinkToExternalResource 활동을 찾습니다. ResourceType은 스토리지 계정인지 로그 분석인지를 나타냅니다.
• 테넌트 수준 스토리지를 사용하거나 사용하지 않도록 설정: AddExternalResource 또는 DeleteLinkToExternalResource 작업을 사용하여 활동 로그에서 변경된 값을 찾습니다.
• 작업 영역 수준 스토리지를 사용하거나 사용하지 않도록 설정: UpdatedAdminFeatureSwitch 작업을 사용하여 활동 로그에서 변경된 값을 찾습니다. 항목 이름은 storageAccountAttachForWorkspaceAdminsEnabled입니다. SwitchState는 true 또는 false입니다.
• 작업 영역 관리자를 위한 Azure Log Analytics 연결 테넌트 설정이 변경됨: 이 테넌트 설정을 사용하면 일부 또는 모든 작업 영역 관리자가 자신의 ADLS Gen2 계정을 통합할 수 있습니다. UpdatedAdminFeatureSwitch 작업을 사용하여 활동 로그에서 변경된 테넌트 설정 값을 찾습니다. 항목 이름은 LogAnalyticsAttachForWorkspaceAdmins입니다.

검사 목록 - Azure 연결을 계획하고 관리하는 경우 주요 의사 결정 및 작업에는 다음이 포함됩니다.

• 현재 Azure 연결 검토: 관리 포털에서 Azure 연결에 대한 테넌트 수준 및 작업 영역 수준 설정을 검토하여 현재 상태를 확인합니다. 또한 작업 영역 관리자를 위한 Azure Log Analytics 연결 테넌트 설정의 설정을 검토합니다.
• 토론 및 결정: Azure 연결을 Power BI와 통합할지 여부를 결정합니다. 앞으로 OneLake와 BYOL(데이터 스토리지)에 대한 Azure 연결에 가장 적합한 용도를 결정합니다.
• 승인이 필요한지 확인: 작업 영역 수준 스토리지 계정 사용에 대한 승인을 얻기 위해 프로세스가 있어야 하는지 여부를 결정합니다.
• 다시 검토할 일정 만들기: 정기적으로 Azure 연결을 다시 검토하도록 일정을 설정합니다.
• 업데이트 수행: 테넌트 수준 및 작업 영역 수준 스토리지 권한을 수정하기 위해 필요에 따라 현재 Azure 연결을 업데이트합니다. 또한 결정에 따라 작업 영역 관리자를 위한 Azure Log Analytics 연결 테넌트 설정을 업데이트합니다(현재 설정된 것과 다른 경우).
• 설명서 만들기: 추가 정보를 추적해야 하는 경우 Azure 연결에 대한 설명서를 만듭니다.
• 사용자 요청을 처리하는 프로세스 만들기: 사용자가 Azure 연결을 사용하도록 요청할 수 있는 방법에 대한 프로세스를 설정합니다.
• 감사 설정: 작업 영역에서 Azure 연결을 설정한 시기 또는 설정이 변경된 시기를 모니터링할 수 있도록 감사 프로세스를 만듭니다.

Power BI 사용 감사

테넌트 수준 감사 데이터를 사용하면 채택 노력을 분석하고, 사용 패턴을 이해하고, 사용자를 교육하고, 사용자를 지원하고, 위험을 완화하고, 규정 준수를 개선하고, 라이선스 비용을 관리하고, 성능을 모니터링할 수 있습니다. 현재 데이터를 분석할 준비가 되지 않았더라도 가능한 한 빨리 Power BI 감사 데이터를 추출하고 저장하는 것이 중요합니다.

Power BI의 사용자, 활동 및 솔루션 감사에 대한 자세한 내용은 테넌트 수준 감사를 참조하세요.

Power BI 서비스 모니터링

모니터링은 진행 중인 작업을 참조하여 진행 중인 작업을 알려줍니다. 모니터링은 일반적으로 경고 및 자동화를 포함하는 수동 작업이지만 때로는 적극적으로 수행됩니다.

Power BI 모니터링에 대한 자세한 내용은 테넌트 수준 모니터링을 참조하세요.

관련 콘텐츠

Power BI 구현 결정에 도움이 되는 더 많은 고려 사항, 작업, 의사 결정 기준 및 지침은 Power BI 구현 계획을 참조하세요.