Power BI 구현 계획: 콘텐츠 계획 및 디자인

참고 항목

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

이 문서는 콘텐츠 수명 주기 관리의 일부로 콘텐츠를 계획하고 디자인하는 데 도움이 됩니다. 주로 다음을 대상으로 합니다.

• COE(우수성 센터) 및 BI 팀: 조직에서 Power BI의 감독을 담당하는 팀으로, 이러한 팀에는 Power BI 콘텐츠의 수명 주기를 관리하는 방법을 결정하는 의사 결정자가 포함됩니다.
• 콘텐츠 작성자 및 콘텐츠 소유자: 다른 사용자와 공유하기 위해 Fabric 포털에 게시하려는 콘텐츠를 만드는 사용자입니다. 이러한 개인은 자신이 만드는 Power BI 콘텐츠의 수명 주기를 관리할 책임이 있습니다.

수명 주기 관리는 콘텐츠 만들기부터 최종 사용 중지까지 콘텐츠를 처리하는 데 사용하는 프로세스와 관행으로 구성됩니다. 이 시리즈의 첫 번째 문서에서 설명한 대로 비즈니스 사용자에게 콘텐츠를 안정적이고 일관되게 제공하려면 Power BI 콘텐츠 수명 주기를 관리하는 것이 중요합니다.

콘텐츠 수명 주기의 첫 번째 단계는 콘텐츠를 계획하고 디자인하는 것입니다. 일반적으로 BI 솔루션 계획을 수행하여 콘텐츠 수명 주기를 시작합니다. 요구 사항을 수집하여 솔루션이 해결해야 하는 문제를 이해하고 정의하고 솔루션 디자인에 도달합니다. 이 계획 및 디자인 단계에서는 이후 단계를 준비하기 위한 핵심 결정을 내립니다.

다음 이미지에서는 콘텐츠를 계획하고 디자인하는 1단계를 강조하여 Power BI 콘텐츠의 수명 주기를 보여 줍니다.

참고 항목

콘텐츠 수명 주기 관리에 대한 개요는 이 시리즈의 첫 번째 문서를 참조하세요.

팁

이 문서에서는 수명 주기 관리와 관련된 콘텐츠 계획 및 디자인에 대한 주요 고려 사항과 결정에 중점을 둡니다.

• Fabric 또는 Power BI 솔루션을 효과적으로 계획하고 디자인하는 방법에 대한 자세한 내용을 알아보려면 솔루션 계획 문서를 참조하세요.
• Power BI 마이그레이션을 효과적으로 계획하는 방법에 대한 자세한 내용은 Power BI 마이그레이션 시리즈를 참조하세요.

요구 사항을 수집할 때 수명 주기 관리에 대한 접근 방식에 영향을 미치는 콘텐츠에 대한 측면을 명확하게 설명해야 합니다. 이러한 측면을 솔루션 계획과 디자인의 일부로 문서화해야 합니다.

이 문서의 다음 섹션에서는 콘텐츠를 계획하고 디자인할 때 수명 주기 관리에 대한 접근 방식에 동기를 부여하는 솔루션의 주요 측면과 고려 사항에 대해 설명합니다.

콘텐츠 식별 및 설명

솔루션을 디자인할 때 콘텐츠가 무엇인지, 누가 콘텐츠를 만들 것인지, 누가 지원할 것인지, 콘텐츠가 조직에 얼마나 중요한지에 대해 설명해야 합니다. 솔루션 디자인의 일부로 요구 사항을 수집하는 동안 또는 수집을 마친 후에 이러한 요소를 해결해야 합니다.

참고 항목

요구 사항과 마찬가지로 이러한 질문에 대한 답변은 솔루션을 개발하면서 또는 솔루션의 수명 주기 후반에 변경될 수 있습니다. 이러한 질문에 답변한 후에는 콘텐츠를 변경하거나 서비스를 제공하는 사용자 수가 달라지는 경우에 주기적으로 재평가할 준비를 하세요.

콘텐츠에 대한 다음 질문에 답변하면 나중에 수명 주기 관리 결정을 내리는 데 도움이 됩니다.

콘텐츠의 형식은 무엇인가요?

콘텐츠의 유형, 범위, 복잡성에 따라 콘텐츠를 관리하는 방법에 대한 주요 결정이 달라집니다. 예를 들어 제한된 대상 그룹을 위한 단일 보고서에는 전체 조직과 여러 다운스트림 워크로드에서 사용될 의미 체계 모델과는 다른 수명 주기 관리 접근 방식이 필요합니다.

다음과 같은 질문에 답변하면 만들 콘텐츠의 형식을 결정하는 데 도움이 됩니다.

• 어떤 항목 유형을 각각 몇 개씩 만들 예정인가요? 예를 들어 데이터 흐름 또는 의미 체계 모델, 보고서 또는 대시보드와 같은 보고 항목 또는 둘 다의 조합과 같은 데이터 항목을 만드나요?
• 콘텐츠 소비자에게 콘텐츠는 어떻게 전달되나요? 예를 들어 소비자가 데이터 항목을 사용하여 자체 콘텐츠를 빌드하나요? 중앙 집중식 보고서만 보나요? 아니면 두 가지를 모두 사용하나요?
• 콘텐츠가 얼마나 복잡하나요? 예를 들어 콘텐츠가 작은 프로토타입인가요? 아니면 여러 비즈니스 프로세스를 포괄하는 대규모 의미 체계 모델인가요?
• 시간이 지남에 따라 콘텐츠의 규모, 범위, 복잡성이 증가할 것으로 예상되나요? 예를 들어 콘텐츠가 향후 다른 지역 또는 비즈니스 영역을 포함할 예정인가요?
• 비즈니스에 이 콘텐츠가 얼마나 오래 필요할 것으로 예상하나요? 예를 들어 이 콘텐츠가 타임라인이 유한한 비즈니스의 핵심 이니셔티브를 지원하나요?

팁

콘텐츠의 형식을 설명하는 아키텍처 다이어그램을 만드는 것이 좋습니다. 다양한 데이터 원본, 항목 유형,콘텐츠 소비자와 이러한 개별 구성 요소 간의 관계를 포함할 수 있습니다. 아키텍처 다이어그램은 콘텐츠와 그 복잡성을 간결하게 묘사하는 데 도움이 되며 수명 주기 관리를 계획하는 데도 유용합니다. Fabric 아이콘과 Azure 아이콘을 사용하여 외부 소프트웨어에서 이러한 다이어그램을 만들 수 있습니다. 또는 아이콘 및 그리기 도구와 함께 제공되는 Azure Diagram을 사용하여 이러한 다이어그램을 만들 수 있습니다.

이러한 다이어그램의 예는 Power BI 구현 계획 사용 시나리오 다이어그램을 참조하세요.

누가 콘텐츠를 만들고 지원하나요?

콘텐츠 작성자의 요구 사항, 기술, 워크플로는 다양합니다. 이러한 요소는 다양한 수명 주기 관리 접근 방식의 성공 여부에 영향을 미칩니다. 협업이 이루어지는 대규모 중앙 팀은 셀프 서비스 크리에이터로 구성된 소규모 팀보다 더 정교한 콘텐츠 수명 주기 관리가 필요한 경우가 많습니다.

다음과 같은 질문에 답변하면 콘텐츠를 만들거나 지원할 사람을 결정하는 데 도움이 됩니다.

• 몇 명이 이 콘텐츠를 만들 것으로 예상하나요? 여러 콘텐츠 작성자가 협업하나요? 아니면 한 명의 개인이 콘텐츠 작성을 담당하나요?
• 콘텐츠 작성자는 수명 주기 관리와 관련 개념(예: 버전 제어)에 익숙한가요? 콘텐츠 작성자는 수명 주기 관리의 이점을 이해하고 있나요?
• 솔루션을 개발하는 콘텐츠 작성자가 배포 후 솔루션을 지원하는 사람과 동일한 개인인가요?
• 콘텐츠 작성자 또는 해당 팀에 기존 솔루션을 지원하기 위한 기존 수명 주기 관리 관행이 있나요?
• 콘텐츠 작성자는 현재 Azure DevOps와 같은 수명 주기 관리 도구를 사용하나요?

Important

콘텐츠 작성 담당자와 프로덕션에 배포된 후 콘텐츠를 지원할 사람을 명확하게 문서화해야 합니다. 콘텐츠 수명 주기 관리 계획에 해당되는 모든 사람이 참여하도록 하세요.

콘텐츠의 중요성은 무엇인가요?

콘텐츠가 비즈니스에 얼마나 중요한지에 따라 콘텐츠를 관리하는 방식에 대해 다른 결정을 내릴 수 있습니다. 중요 비즈니스용 콘텐츠에는 품질을 보호하고 중단 가능성을 완화하기 위해 보다 강력한 콘텐츠 수명 주기 관리 접근 방식이 필요합니다.

다음과 같은 질문에 답변하면 콘텐츠가 중요한지 여부를 판단하는 데 도움이 됩니다.

• 이 콘텐츠가 비즈니스에 얼마나 중요한가요? 이 콘텐츠를 개발하라는 요청이 얼마나 시급한가요?
• 이 콘텐츠에서 제공하는 정보로 중요 비즈니스 의사 결정이나 조치를 내릴 예정인가요?
• 조직 전체에서 제한된 로컬 팀에 이르기까지 이 콘텐츠를 얼마나 광범위하게 배포할 예정인가요?
• 경영진 또는 기타 전략적 의사 결정자가 업무에 이 콘텐츠를 활용하나요?
• 이 콘텐츠가 미치는 영향은 무엇인가요? 예를 들어 콘텐츠를 갑자기 사용할 수 없게 되면 수익 손실 또는 비즈니스 프로세스 중단과 같이 비즈니스에 어떤 영향이 발생하나요?

작성할 콘텐츠를 충분히 식별하고 설명했으면 이제 콘텐츠 작성자가 어떻게 협업해야 하는지를 결정해야 합니다.

콘텐츠 작성자가 협업하는 방식 결정

솔루션의 범위와 복잡성이 증가함에 따라 여러 콘텐츠 작성자와 소유자의 협업이 필요할 수 있습니다. 복잡한 솔루션을 만드는 경우에는 협업을 구조화하고, 관리하고, 지원하는 데 도움이 되는 효과적인 도구를 사용하는 것이 좋습니다. Power BI 콘텐츠를 만들 때 협업하는 방식에는 Microsoft Teams 또는 Azure DevOps를 사용하는 등 여러 가지가 있습니다.

팁

콘텐츠 작성자가 독립적으로 작업하는 경우에도 Microsoft Teams 및 Azure DevOps와 같은 도구를 사용하여 작업을 계획하고 구성함으로써 이점을 얻을 수 있습니다.

Microsoft 팀

소규모 또는 간단한 프로젝트의 경우 콘텐츠 작성자는 Microsoft Teams를 사용하여 협업할 수 있습니다.

콘텐츠 작성자는 Microsoft Teams를 사용하여 팀과 채널에서 커뮤니케이션, 계획, 작업을 구성합니다. Microsoft Teams는 더 간단한 협업 시나리오에 적합한 경우가 많습니다. 예를 들어 제한된 대상 그룹에 대한 콘텐츠를 작성하는 탈중앙화된 팀은 파일과 버전 제어를 저장하기 위해 문서 라이브러리를 사용할 수 있습니다. 또한 다른 통합 도구와 서비스를 사용할 수도 있습니다.

팁

탈중앙화된 콘텐츠 제공을 통해 셀프 서비스 시나리오에서 효과적인 콘텐츠 수명 주기 관리를 지원하려면 Microsoft Teams를 사용하는 것이 좋습니다.

Microsoft Teams에서 협업하고 소통하려면 Power BI 콘텐츠의 수명 주기 동안 지원 서비스를 사용해야 합니다.

• Planner: 콘텐츠 소유자는 Planner를 사용하여 작업을 추적하고 콘텐츠 작업 범위를 지정하는 데 사용하는 계획을 수립할 수 있습니다. Tasks는 솔루션의 문제, 버그 또는 기능과 해당 관련자를 설명할 수 있습니다.
• SharePoint: 콘텐츠 작성자는 각 채널의 Microsoft Teams 문서 라이브러리 또는 연결된 사이트에서 파일을 저장하고 관리할 수 있습니다. SharePoint에 저장된 콘텐츠 파일은 버전 제어를 사용하여 콘텐츠 변경 내용을 추적하고 관리할 수 있습니다. SharePoint를 사용하여 변경 내용을 추적하고 관리하는 방법에 대한 자세한 내용은 2단계: 콘텐츠 개발 및 변경 내용 관리를 참조하세요.
• 승인: 콘텐츠 작성자와 소유자는 검토 후 콘텐츠 변경 내용 또는 릴리스를 승인하는 워크플로를 설정하고 사용할 수 있습니다.
• Fabric 및 Power BI: 콘텐츠 작성자와 소유자는 Microsoft Teams 내에서 Fabric 포털에 액세스할 수 있습니다. Fabric 포털에서 콘텐츠를 관리하거나 토론하고 유용한 보고서를 Teams 채널의 탭에 추가할 수 있습니다.
• 기타 통합: 콘텐츠 작성자는 선호하는 워크플로 및 요구 사항에 가장 적합하도록 Microsoft Teams와 통합되는 다른 Microsoft 또는 타사 서비스를 사용할 수 있습니다.

콘텐츠 작성자가 Microsoft Teams를 사용하여 협업하는 방법에 대한 구조화된 프로세스를 정의하는 것이 좋습니다. 다음을 확인합니다.

• 팀과 채널에 대한 액세스를 관리하는 방법.
• 팀 및 채널 관리를 담당하는 사람.
• 작업 범위를 지정하고 고유한 팀, 채널, 계획으로 구성하는 방법.
• 콘텐츠 작성자가 문서 라이브러리를 사용하여 파일을 구성하고 변경 내용을 추적하고 관리하는 방법. 예를 들어 문서 라이브러리를 구성하는 방법과 콘텐츠 작성자가 파일을 체크 인하고 체크 아웃해야 하는지 여부 등이 있습니다.
• 콘텐츠 작성자가 OneDrive 새로 고침을 사용하여 Power BI Desktop(.pbix) 파일을 자동으로 게시해야 하는지 여부.
• 파일 동기화 충돌을 해결하는 방법.
• 문서 라이브러리에서 더 이상 관련이 없는 파일을 보관하고 제거해야 하는 시기.

Azure DevOps

콘텐츠 작성자와 소유자는 Azure DevOps를 사용하여 중앙의 체계적인 허브에서 소통하고 협업합니다.

참고 항목

Azure DevOps는 Power BI 및 Fabric과 통합되어 콘텐츠 수명 주기 관리를 계획하고 오케스트레이션하는 데 도움이 되는 서비스 도구 모음입니다. 이러한 방식으로 Azure DevOps를 사용하는 경우 일반적으로 다음 서비스를 활용합니다.

• Azure Repos: 콘텐츠 변경 콘텐츠를 추적하고 관리하는 데 사용하는 원격 스토리지 위치인 원격 Git 리포지토리를 만들고 사용할 수 있습니다.
• Azure Pipelines: 원격 리포지토리의 콘텐츠를 작업 영역으로 처리, 테스트, 배포하는 자동화된 작업 집합을 만들고 사용할 수 있습니다.
• Azure Test Plans: Azure Pipelines와 함께 솔루션의 유효성을 검사하고 품질 제어를 자동화하는 테스트를 디자인할 수 있습니다.
• Azure Boards: Boards를 사용하여 작업과 계획을 작업 항목으로 추적하고 다른 Azure DevOps 서비스의 작업 항목을 연결하거나 참조할 수 있습니다.
• Azure Wiki: 팀과 정보를 공유하여 콘텐츠를 이해하고 콘텐츠에 기여할 수 있습니다.

콘텐츠 작성자는 Azure DevOps를 사용하여 프로젝트를 통해 커뮤니케이션, 계획, 작업을 구성합니다. 또한 콘텐츠 작성자는 원본 제어, 유효성 검사, 배포를 수행하여 Azure DevOps 내에서 콘텐츠 수명 주기 관리를 오케스트레이션할 수 있습니다. 원본 제어는 콘텐츠 코드와 메타데이터에 대한 보다 세부적인 변경 내용을 관리하는 프로세스입니다.

콘텐츠 만들기와 배포를 오케스트레이션하는 지원 서비스 및 옵션이 있으므로 Azure DevOps는 고급 협업 시나리오에 적합한 선택인 경우가 많습니다.

팁

중앙 집중식 콘텐츠 제공을 통해 엔터프라이즈 시나리오에서 효과적인 콘텐츠 수명 주기 관리를 지원하려면 Azure DevOps를 사용하는 것이 좋습니다. 규모가 크거나 복잡한 시나리오에서는 Microsoft Teams 또는 SharePoint를 사용하여 협업하는 것보다 Azure DevOps 또는 이와 유사한 도구를 사용하여 협업하는 것이 더 좋습니다. 더 강력한 협업과 자동화를 지원하는 데 사용할 수 있는 도구와 옵션이 더 많기 때문입니다.

콘텐츠 작성자가 Azure DevOps를 사용하여 협업하는 방법에 대한 구조화된 프로세스를 정의하는 것이 좋습니다. 다음을 확인합니다.

• 작업 범위와 콘텐츠 분기를 만들고 이름을 지정하고 사용하는 방법.
• 작성자가 변경 내용을 그룹화 및 커밋하고 커밋 메시지로 설명하는 방법.
• 끌어오기 요청을 사용하여 변경 내용을 검토하고 승인하는 담당자.
• 끌어오기 요청 병합 충돌이 해결되는 방법과 이를 해결하는 사람.
• 다른 분기에서 변경한 내용을 단일 분기로 병합하는 방법.
• 콘텐츠를 테스트하는 방법과 콘텐츠가 배포되기 전에 테스트를 수행하는 담당자.
• 변경 내용이 개발, 테스트, 프로덕션 작업 영역에 배포되는 방법 및 시기.
• 배포된 변경 내용 또는 솔루션 버전을 롤백할 수 있는 방법과 시기.

참고 항목

이러한 서비스를 통합하는 다양한 방법이 있으므로 Microsoft Teams를 Azure DevOps와 함께 사용할 수도 있습니다. 예를 들어 Microsoft Teams 내에서 Azure Boards를 보고 관리하고 Azure Pipelines의 이벤트를 모니터링할 수 있습니다.

가장 중요한 것은 협업을 지원하고 팀의 요구 사항과 업무 방식에 가장 적합한 도구와 서비스를 사용하는 것입니다.

콘텐츠 작성자가 협업해야 하는지 여부와 방법을 결정한 후에는 파일을 저장할 위치를 결정해야 합니다. 이러한 파일의 대부분은 협업하도록 선택한 위치에 저장됩니다.

파일을 저장할 위치 결정

콘텐츠를 만들 때는 일반적으로 다양한 형식의 파일을 만듭니다. 파일을 효과적으로 관리하려면 이러한 파일을 저장할 위치를 결정하는 것이 중요합니다.

팁

여러 팀 구성원이 액세스할 수 있고 변경 내용을 쉽게 추적할 수 있는 곳에 파일을 저장하세요(버전 제어라고도 알려짐). 이러한 방법을 사용하면 팀 구성원의 이탈 또는 파일 분실로 인한 중단이 발생하지 않습니다.

저장해야 하는 파일 유형은 다음과 같습니다.

• 콘텐츠 파일: 콘텐츠 데이터 또는 메타데이터를 포함하는 파일입니다. .pbix 및 Power BI Project(.pbip) 파일과 같은 데이터가 포함된 콘텐츠 파일에는 중요한 정보가 포함되어 있습니다. 콘텐츠 파일에 액세스해야 하는 사람만 액세스할 수 있는 안전한 위치에 콘텐츠 파일을 저장하세요. 또한 콘텐츠 파일을 Microsoft Teams의 문서 라이브러리 또는 Azure DevOps의 Git 리포지토리와 같이 버전 제어를 지원하는 위치에 저장해야 합니다. 콘텐츠 파일의 예는 다음과 같습니다.
  • Power BI Desktop(.pbix) 파일
  • Power BI Project(.pbip) 파일
  • Power BI 페이지를 매긴 보고서(.rdl) 파일
  • 모델 메타데이터(.bim 또는 TMDL) 파일
  • 데이터 흐름 메타데이터(.json) 파일
• 데이터 원본 파일: 의미 체계 모델 또는 데이터 흐름과 같은 데이터 항목에서 사용되는 파일입니다. 콘텐츠는 데이터 원본 파일에 직접적으로 의존하므로 해당 파일을 제거하면 데이터 새로 고침에 실패할 수 있습니다. 따라서 저장 위치를 신중하게 고려하는 것이 중요합니다. 또한 이러한 파일은 중요한 정보를 포함할 수 있습니다. 따라서 데이터 원본 파일은 다른 사람의 접근이 제한되는 안전하고 신뢰할 수 있는 환경에 저장하세요. 데이터 원본 파일의 예는 다음과 같습니다.
  • 구조화된 데이터 원본(예: Excel 통합 문서, Parquet 또는 CSV 파일).
  • 반구조화된 데이터 원본(예: JSON 또는 XML 파일).
  • 구조화되지 않은 데이터 원본(예: 보고서로 가져오는 이미지).
• 지원 파일: 콘텐츠 만들기 또는 관리를 지원하지만 콘텐츠가 작동하는 데는 필요하지 않은 파일입니다. 지원 파일은 버전 제어를 지원하고 다른 도구 및 콘텐츠 작성자가 액세스할 수 있는 위치에 저장해야 합니다. 지원 파일의 예는 다음과 같습니다.
  • 모범 사례 분석기 규칙(.json) 파일.
  • Power BI 테마(.json) 파일.
  • 콘텐츠 및 쿼리에 대한 소스 코드 파일.
  • 사용자 지정 시각화(.pbiviz) 파일.
• 템플릿 및 문서: 셀프 서비스 콘텐츠를 만들거나 기존 콘텐츠에 대해 설명하는 데 도움이 되는 파일. 템플릿 및 문서는 이를 사용해야 하는 사용자가 쉽게 액세스할 수 있어야 합니다. 템플릿 및 문서의 예는 다음과 같습니다.
  • Power BI 템플릿(.pbit) 파일.
  • 시각화 템플릿 및 예제 보고서.
  • 솔루션 디자인 및 문서.
  • 솔루션 계획 및 로드맵.
  • 사용자 요청 및 솔루션 문제.

주의

.pbix 및 .pbip 파일과 같은 일부 콘텐츠 파일에는 데이터 원본에서 가져온 중요한 데이터가 포함될 수 있습니다. 또한 TMDL 또는 .pbit 파일과 같은 메타데이터 파일에도 중요한 정보가 포함될 수도 있습니다. 이러한 파일을 안전한 위치에 저장하고 효과적인 데이터 손실 방지를 수행하기 위해 필요한 예방 조치를 취해야 합니다.

파일을 저장하는 데는 다양한 옵션이 있습니다. 파일 형식, 콘텐츠, 사용 방섹에 따라 적절한 위치를 선택해야 합니다.

SharePoint Online 또는 OneDrive

파일을 저장하는 일반적인 솔루션은 SharePoint 사이트를 사용하는 것입니다. SharePoint는 대부분의 사용자가 광범위하게 액세스할 수 있으며 Power BI 및 다른 Microsoft 365 애플리케이션(예: Microsoft Teams)과 고도로 통합되어 있습니다. 또한 버전 제어 기능이 기본 제공되어 대부분의 파일 형식을 저장하는 데 편리합니다. 버전 제어를 사용하면 저장된 파일의 여러 버전을 보고 관리할 수 있습니다.

SharePoint에 파일을 저장하는 경우 다음을 고려합니다.

• 조직: 특정 파일을 쉽게 찾을 수 있도록 일관되고 논리적인 구조를 유지해야 합니다. 적절한 명명 규칙을 사용하고, 폴더에 파일을 구성하고, 진행 중인 프로젝트와 더 이상 관련이 없는 파일을 보관합니다.
• OneDrive 새로 고침: 게시된 의미 체계 모델 또는 보고서를 SharePoint 또는 비즈니스용 OneDrive(회사 또는 학교용 OneDrive라고도 함) 사이트에 저장된 .pbix 파일에 연결할 수 있습니다. 이 방법을 사용하면 더 이상 변경 내용을 적용하기 위해 의미 체계 모델을 게시할 필요가 없습니다. 대신 매시간 자동으로 수행되는 OneDrive 새로 고침 후에 변경 내용을 볼 수 있습니다. 이 접근 방식은 편리하지만 몇 가지 주의 사항과 과제가 있다는 점에 유의하세요. 일단 작업이 진행되면 쉽게 되돌릴 수 없습니다.
• 보고서 미리 보기: SharePoint에서는 Power BI Desktop을 설치하거나 .pbix 파일을 로컬로 다운로드하지 않고도 Power BI 보고서를 볼 수 있습니다. 이러한 방식으로 보고서를 열면 보고서가 브라우저에 표시됩니다. 이 기능은 Fabric 포털에서 보고서를 보는 것보다 편리한 대안이 될 수 있습니다. Fabric 테넌트 설정에서 기본적으로 사용하도록 설정되어 있습니다.

팁

Microsoft Teams를 사용하여 협업하는 경우 채널 문서 라이브러리에 파일을 저장하는 것이 좋습니다. 이 접근 방식은 파일을 중앙 집중화하는 데 도움이 되고 협업을 지원됩니다.

SharePoint에 다음 파일 형식을 저장하는 것을 고려하세요.

• 템플릿 및 문서: 기존 스토리지 솔루션이 없는 경우 SharePoint에 템플릿과 문서를 저장합니다. SharePoint는 복잡한 설정이나 프로세스 없이 다른 사용자에게 액세스 권한을 부여하고 파일을 관리할 수 있으므로 이러한 파일에 적합합니다.
• 지원 파일: 기존 스토리지 솔루션이 없는 경우 지원 파일을 SharePoint에 저장합니다. 그러나 일부 지원 파일(예: 보고서를 위한 Power BI 테마 .json 파일)은 저장된 변경 내용을 보고 관리할 수 있는 버전 제어 시스템에 저장하는 것이 더 나을 수 있습니다.
• 콘텐츠 파일: 업무에 중요하지 않거나 Azure Repos와 같은 원격 리포지토리에 액세스할 수 없는 경우 SharePoint에 콘텐츠를 저장합니다.
• 데이터 원본: 데이터 원본의 크기가 작고 복잡하지 않은 경우에만 SharePoint에 저장합니다. SharePoint를 사용하여 데이터 소스 파일을 저장할 때는 자제력을 발휘하세요. OneLake와 같은 다른 가능한 대안을 고려합니다.

주의

SharePoint는 적절한 데이터 아키텍처의 대안으로 사용하지 마세요. 일부 제한된 시나리오에서는 SharePoint에 데이터 원본 파일을 저장하는 것이 편리할 수 있지만, 더 크고 복잡한 데이터 원본이 있거나 데이터 지연 시간을 줄여야 하는 경우에는 이 접근 방식이 스케일링되지 않습니다.

Warning

개인 파일 시스템이나 개인 OneDrive 계정을 사용하여 파일을 저장하지 마세요. 소유자가 조직을 떠나면 이러한 파일은 더 이상 사용할 수 없습니다.

OneLake

Fabric 용량이 있는 경우 데이터 원본 파일을 저장하는 데 OneLake가 좋은 선택이 될 수 있습니다. OneLake 파일 탐색기를 사용하여 파일을 OneLake에 업로드하거나 동기화할 수 있으며 여기서 파일을 테이블로 변환하여 Power BI와 같은 다운스트림 워크로드에서 사용할 수 있습니다. 더 크거나 정기적으로 업데이트되는 데이터 원본의 경우 Fabric Data Factory나 ADLS(Azure Data Lake Storage) Gen2 API 또는 Azure Storage Python SDK를 사용하는 기타 애플리케이션을 사용하여 OneLake에 자동으로 파일을 로드할 수 있습니다.

주의

OneLake에서 파일을 업로드하거나 다운로드하는 등의 작업은 Fabric 용량 단위를 사용합니다. 용량 메트릭을 모니터링하고 대용량 파일의 불필요한 이동으로 인한 용량 부담을 방지하기 위한 조치를 취해야 합니다.

또한 OneLake 파일 탐색기를 사용하여 사용자가 액세스하는 파일은 실수로 인한 변경이나 손실에 취약합니다. 중요 비즈니스용 솔루션에는 OneLake 파일 탐색기를 사용하지 않는 것이 좋습니다.

Warning

OneLake 파일 탐색기에는 몇 가지 중요한 제한 사항과 고려 사항이 있습니다. 예를 들어 OneLake는 SharePoint 또는 OneDrive와 같은 파일에 대한 버전 제어를 지원하지 않습니다. 파일을 저장할 위치를 결정할 때 이러한 고려 사항과 제한 사항을 고려하세요.

팁

OneLake에 데이터를 저장할 때 BCDR(비즈니스 연속성 및 재해 복구)을 사용하도록 설정하여 데이터 손실 위험을 완화하는 것이 좋습니다. BCDR을 사용하도록 설정하면 Azure의 표준 지역 페어링에 따라 데이터가 복제되고 서로 다른 두 지역에 저장됩니다.

원격 리포지토리

콘텐츠 작성자는 개발 중에 정기적으로 로컬 시스템에서 Azure Repos Git 리포지토리와 같은 원격 리포지토리로 작업을 커밋하고 저장할 수 있습니다. 원격 리포지토리에는 솔루션의 최신 버전이 있으며 전체 개발 팀이 액세스할 수 있습니다. 일반적으로 원격 리포지토리는 Teams, SharePoint 또는 OneDrive를 사용하는 것보다 더 고급인 수명 주기 관리 방법을 지원합니다. 이는 원격 리포지토리를 사용하여 콘텐츠 작성자가 파일에서 협업하거나 파일 변경 내용을 추적하고 관리하는 보다 정교한 옵션을 활용할 수 있기 때문입니다. 예를 들어 콘텐츠 작성자는 원격 리포지토리의 자체 분기에서 작업하여 내용을 변경하고 준비가 되면 해당 변경 내용을 주 분기에 병합하도록 요청할 수 있습니다.

다음 파일 형식은 원격 리포지토리에 저장하는 것이 좋습니다.

• 템플릿 및 문서: Azure DevOps와 같은 관련 서비스로 프로젝트를 관리할 때 원격 리포지토리에 템플릿과 문서를 저장하세요.
• 지원 파일: 지원 파일을 원격 리포지토리에 저장하면 변경 내용을 쉽게 추적하고 관리할 수 있습니다.
• 콘텐츠 파일: 비즈니스에 중요한 콘텐츠인 경우 또는 동일한 콘텐츠에 대해 다른 개발자와 협업하려는 경우 콘텐츠를 원격 리포지토리에 저장합니다. 원격 리포지토리는 콘텐츠 변경 내용을 추적하고 협업을 지원하는 데 적합합니다.

팁

원격 리포지토리를 사용하는 경우 Power BI 보고서 및 의미 체계 모델을 .pbix 파일 대신 Power BI Desktop 프로젝트(.pbip) 파일로 저장하는 것이 좋습니다. 저장된 변경 내용을 .pbix 파일에서 식별할 수 없기 때문입니다.

파일 없음: Fabric 포털에서 만든 콘텐츠

콘텐츠 작성자는 Fabric 포털에서 직접 콘텐츠를 작성할 수 있습니다. 이 시나리오에서는 일반적으로 콘텐츠 파일을 직접 사용하지 않습니다. 일반적으로 항목 유형을 다른 곳(예: 데이터 흐름, 대시보드 또는 성과 기록표)에서 만들 수 없는 경우에만 Fabric 포털에서 콘텐츠를 작성해야 합니다. Windows 컴퓨터에 액세스할 수 없어 Power BI Desktop을 사용할 수 없는 경우에는 Fabric 포털에서 보고서와 의미 체계 모델을 작성할 수도 있습니다. 자세한 내용은 사용자 도구 및 디바이스를 참조하세요.

주의

Fabric 포털에서 만들어진 일부 콘텐츠는 파일로 다운로드할 수 없습니다. 예를 들어 Fabric 포털에서 만든 보고서는 .pbix 파일로 다운로드할 수 없습니다.

Fabric 포털에서 컨텐츠를 작성하는 경우에는 대신 Fabric API 또는 Git 통합을 사용하여 컨텐츠 정의를 백업해야 합니다. 콘텐츠 정의를 백업하면 해당 콘텐츠가 실수로 삭제되거나 의도치 않게 변경되는 경우에 혼란을 줄일 수 있습니다. 콘텐츠가 실수로 삭제되거나 변경된 경우 백업을 사용하여 콘텐츠를 변경할 수 있습니다.

검사 목록 - 콘텐츠를 계획하고 디자인할 때 주요 결정 사항과 조치에는 다음이 포함됩니다.

• 솔루션 계획 수행: 비즈니스 요구 사항과 기술 요구 사항을 수집하여 콘텐츠가 해결할 문제를 충분히 이해하고 해당 콘텐츠가 문제를 해결하는 방법을 디자인합니다.
• 콘텐츠를 만들 사람을 파악: 개별 콘텐츠 작성자의 워크플로, 기술, 요구 사항에 따라 수명 주기 관리에 대한 다양한 접근 방식이 필요할 수 있습니다.
• 여러 콘텐츠 작성자가 협업해야 하는지 여부 확인: 협업하는 콘텐츠 작성자가 .pbip 파일과 같은 버전 제어를 지원하는 파일 형식을 사용하고 있는지 확인합니다.
• 콘텐츠 작성자의 협업 방법 결정: 얼마나 정교하게 협업을 진행할지 결정하세요. 또한 Microsoft Teams 또는 Azure DevOps를 사용하는 등 이러한 협업을 지원할 방법을 결정하세요.
• 협업 도구 설정: 솔루션이나 프로젝트에 필요한 최초 설정을 수행해야 합니다. 이러한 도구를 사용하여 협업을 관리하는 방법에 대한 주요 결정을 내립니다.
• 데이터 원본 파일을 SharePoint 또는 OneLake에 저장: 작고 간단한 데이터 원본 파일을 SharePoint에 저장합니다. 그렇지 않은 경우에는 OneLake 또는 ADLSGen2(사용 가능한 경우)를 대신 사용하세요.
• SharePoint 또는 원격 리포지토리에 콘텐츠와 지원 파일 저장: 더 간단하고 작은 프로젝트의 경우 대부분의 파일이 구성되어 있고 액세스 관리가 잘 되어 있다면 SharePoint를 사용하세요. 대규모 환경이거나 병행 협업이 필요한 경우에는 콘텐츠 변경 내용을 자세히 볼 수 있는 원격 리포지토리를 사용하는 것이 좋습니다.
• SharePoint에 템플릿 및 문서 저장: 다른 사람이 템플릿과 문서를 쉽게 찾고, 사용하고, 이해할 수 있도록 하세요.
• 개발 및 배포 계획: 이 첫 번째 단계를 완료하려면 주요 분야를 다루고 초기 설정을 수행하기 위한 구체적인 계획을 수행합니다. 예를 들어 도구를 설정하고 데이터 원본 연결을 테스트합니다.

관련 콘텐츠

이 시리즈의 다음 문서에서는 콘텐츠 수명 주기 관리의 일부로 콘텐츠를 개발하고 변경 내용을 관리하는 방법에 대해 알아보세요.