Power Platform을 대규모로 채택하기 위한 테넌트 환경 전략 개발
Microsoft Power Platform을 채택하기 위한 모든 조직의 여정은 고유합니다. 테넌트 환경 전략은 관리 가능하고 안전한 방식으로 사용을 가속화하는 데 도움이 되는 기반을 마련합니다.
이 백서에서는 Power Platform 테넌트 환경 전략을 제품 기능 및 비전에 맞추는 방법을 보여줍니다. 플랫폼의 최신 기능을 최대한 활용하여 Power Platform을 엔터프라이즈 규모로 채택할 수 있는 전략을 구현하는 방법을 알아보세요.
참고
브라우저에서 인쇄를 선택한 다음, PDF로 저장을 선택하여 이 백서를 저장하거나 인쇄할 수 있습니다.
소개
Power Platform은 조직이 빠른 혁신을 위한 로우코드 솔루션을 빌드할 수 있도록 지원합니다. 이러한 솔루션은 개인 및 소규모 팀의 생산성에 중점을 두거나 조직 전체에 적용할 수 있습니다. 또한 외부 고객 및 파트너를 포함한 비즈니스 프로세스로 확장될 수도 있습니다. 이러한 솔루션을 지원하는 것은 로우코드 리소스가 빌드, 테스트 및 사용되는 Power Platform 환경입니다. 조직에서 Power Platform의 채택을 늘림에 따라 환경 수가 증가함에 따라 관리 가능하고 안전하게 만들기 위해 좋은 테넌트 환경 전략을 구현하는 것이 필수적입니다.
귀하의 성공을 돕기 위해 이 문서에서는 첫 번째 환경 전략을 수립하거나 현재 계획을 발전시키는 데 사용할 수 있는 기능을 가장 잘 사용하는 방법을 안내합니다. 또한 이러한 기능이 함께 작동하는 방식과 Power Platform을 대규모로 관리하기 위해 어떻게 발전할 것인지에 대한 비전을 간략하게 설명합니다. 이 지침에서는 거버넌스, 보안 규칙 및 테넌트 환경 전략의 기타 중요한 측면을 일관되게 적용하기 위해 새로운 사용자를 환경 및 그룹 환경으로 적절하게 라우팅하는 방법을 설정합니다. 또한 환경 전략 구현의 중요한 첫 번째 단계인 기본 환경을 보호하기 위한 자세한 단계를 제공합니다.
Power Platform 환경을 관리하는 데 사용할 수 있는 많은 관점이 있지만 이 문서의 접근 방식은 Microsoft의 최신 제품 방향과 일치하며 현재 기능과 단기적으로 계획된 개선 사항을 사용합니다. 이 업데이트된 지침은 Microsoft가 규모에 맞게 환경을 관리하는 방식에 전략적으로 부합하는 환경 기능 및 옵션만 사용하도록 하는 데 도움이 될 수 있습니다.
Microsoft의 테넌트 환경 전략 비전
많은 조직에서는 기본 환경이라는 공유 중앙 환경에서 구축 및 실행되는 개인 생산성 앱과 자동화로 Power Platform 여정을 시작합니다. 이러한 리소스는 Microsoft 365에 포함된 기본 기능만 사용하고 Power Platform의 전체 기능을 사용하지 않는 경우가 많습니다. 이 초기 채택이 가속화됨에 따라 Microsoft는 조직에 전체 Power Platform 기능의 엔터프라이즈 규모 채택을 위한 환경 전략에 대한 진입로를 제공합니다. 이러한 프리미엄 거버넌스 기능은 사용자에게 프리미엄 Power Platform(Power Apps, Power Automate, Microsoft Copilot Studio 및 Dynamics 365) 라이선스가 있을 때 사용할 수 있습니다. Power Platform 채택 성숙도 모델은 조직이 환경 전략을 넘어 전사적 규모의 채택을 달성하기 위한 로드맵을 정의하는 데 도움이 되는 더 많은 인사이트를 제공할 수 있습니다. 이 접근 방식은 조직이 기본적인 개인 생산성에서 Power Platform의 엔터프라이즈 규모 채택으로 성숙하는 데 도움이 될 수 있습니다.
Power Platform 관리, 거버넌스 및 보안 기능을 통해 조직은 엔터프라이즈 생산성 및 엔터프라이즈 앱 사용을 위해 Power Platform을 대규모로 채택하고 관리할 수 있습니다. 관리형 환경을 사용하면 가시성과 제어력을 높이고 환경 관리 및 보안을 위한 수동 노력을 줄이는 일련의 프리미엄 기능이 활성화됩니다. 이러한 기능을 사용하면 거버넌스 및 보안 정책을 일관되게 적용할 수 있습니다. 관리자는 이러한 기능을 사용하여 엔터프라이즈 규모의 환경 전략으로 전환할 수 있습니다. 관리에 소요되는 시간과 노력을 줄이면 조직의 사용량이 늘어남에 따라 플랫폼의 전체 총 소유 비용(TCO)을 줄이는 데 도움이 됩니다.
기업 규모로의 전환의 핵심 요소는 제작자가 개인 개발 환경을 더 쉽게 사용할 수 있도록 함으로써 제작자를 위한 공유 중앙 환경 전략을 강화하는 것입니다. 공유 중앙 환경 전략에서 제작자는 기본 환경에서 앱을 구축, 사용 및 공유합니다. 이 전략은 고립성이 부족하고 제작자가 서로를 침해하는 결과를 가져올 수 있습니다. 회사의 모든 사람이 모든 문서를 하나의 OneDrive 폴더에 공유한다고 상상해 보세요. 대신, 환경 기능을 사용하여 제작자가 관리자를 위한 단순화된 거버넌스와 관련 없는 자산을 작업하는 제작자로부터 보호되는 앱을 안전하게 구축할 수 있는 자신만의 개인 환경으로 제작자를 안내할 수 있습니다. 동료를 이러한 환경에 더 많은 제작자로 추가하여 솔루션 구축에 협력할 수 있습니다.
그림: 공유된 중앙 환경(왼쪽)과 환경 라우팅 전략(오른쪽)의 그림입니다.
새로 생성된 제작자 환경은 환경에 일관된 거버넌스 및 보안 정책이 있는지 확인하기 위해 규칙을 적용하는 그룹에 자동으로 추가될 수 있습니다. 관리자는 제작자의 환경을 완화된 규칙이 있는 그룹으로 이동하여 예외를 처리할 수 있습니다.
제작자가 만든 로우코드 리소스는 리소스의 ALM(애플리케이션 수명 주기 관리) 여정의 초기 단계를 나타냅니다. 이 초기 단계의 일부로 리소스의 각 버전을 캡처하고 필요한 경우 이를 다시 생성할 수 있는 것이 중요합니다. 리소스를 공유할 준비가 되면 제작자는 개발자 환경에 연결된 지속적인 통합을 사용하여 이를 프로덕션 환경으로 승격할 수 있으며, 여기서 사용자는 지속적인 제작자 활동에서 격리된 리소스를 실행할 수 있습니다.
가능하면 자체 도구를 구축하는 대신 환경 관리를 위해 플랫폼에 내장된 기능을 우선 사용해야 합니다. 기본 제공 기능이 조직의 고유한 요구 사항을 충족하지 않는 경우 플랫폼 관리 도구를 사용하여 사용자 지정 도구를 만들 수 있습니다. 새로운 기능이 출시되면 이를 기준으로 사용자 지정 도구를 평가해야 합니다. Microsoft의 플랫폼 로드맵을 주시하고 자체 로드맵을 유지 관리하면 이 작업을 더 쉽게 수행할 수 있습니다.
조직의 고유한 요구 사항에 맞는 권장 환경 기능을 사용하여 환경 전략을 수립해야 합니다. 환경 전략을 일회성 활동으로 생각하지 마십시오. 새로운 환경 기능이 출시되면 이를 통합하기 위해 시간이 지남에 따라 발전해야 합니다.
엔터프라이즈 규모의 환경 전략을 지원하는 기능
환경은 Power Platform 관리, 거버넌스 및 보안을 위한 구성 요소입니다. 전체 기능 개요는 이 백서의 범위를 벗어납니다. 그러나 이 섹션에서는 기업 규모의 환경 전략 구현을 지원하는 기능을 강조합니다.
환경 유형은 전략의 일환으로 환경을 다양하게 사용하는 방법을 설명합니다.
관리형 환경은 환경을 대규모로 더 쉽게 관리할 수 있도록 하는 프리미엄 기능 집합을 제공합니다.
라이선스 자동 신청은 관리자가 라이선스가 필요한 사용자를 미리 식별하도록 요구하는 대신 사용자가 필요할 때 사용자당 Power Apps 라이선스를 청구할 수 있도록 하여 라이선스 할당을 간소화합니다.
환경 그룹 및 규칙에서는 환경을 그룹으로 관리하고 그룹에 규칙을 적용하여 일관된 거버넌스 정책을 자동화하는 방법을 설명합니다.
기본 환경 라우팅은 제작자가 기본 환경에서 리소스를 생성하는 것에서 벗어나 자신의 개인 환경으로 자동으로 이동합니다.
Microsoft Dataverse는 강화된 보안 및 ALM을 제공합니다.
선호하는 솔루션은 제작자가 구축하는 모든 자산이 Dataverse 솔루션에 있는지 확인하여 다른 환경으로 더 쉽게 승격할 수 있도록 도와줍니다.
Power Platform의 파이프라인은 개발에서 테스트 및 프로덕션 환경으로 자산을 승격하기 위한 간소화된 프로세스를 제공하여 모든 제작자가 CI/CD(지속적인 통합 및 배포)를 사용할 수 있도록 합니다.
Power Platform의 카탈로그를 통해 제작자는 앱 및 흐름과 같은 구성 요소와 템플릿과 같은 고급 시작점을 공유할 수 있습니다.
환경 유형
다음 표에서는 만들 수 있는 환경 유형, 해당 특성 및 용도에 대해 설명합니다.
| 유형 | 특성 및 용도 |
|---|---|
| Default | 모든 테넌트와 함께 제공되는 환경. 많은 Microsoft 365 환경에서 사용자 지정 및 자동화를 위해 이 환경을 사용합니다. 이 환경은 Microsoft 365 개인, 생산성 시나리오를 넘어서는 장기 또는 영구 작업을 위한 것이 아닙니다. |
| 생산 | 이 환경은 조직의 영구 작업에 사용됩니다. 프로덕션 환경은 7일에서 최대 28일까지 연장된 백업 보존을 지원합니다. |
| 샌드박스 | 이러한 개발 및 테스팅 환경은 복사 및 재설정과 같은 환경 작업을 지원합니다. 샌드박스는 테스트 및 ALM 빌드 환경에 가장 적합합니다. |
| 디벨로퍼 | 이러한 특수 환경은 사용자 및 다른 제작자로부터 로우코드 자산을 격리하는 제작자의 개인 개발 작업 공간으로 사용됩니다. 제작자는 최대 3개의 개발자 환경을 가질 수 있습니다. 테넌트 용량에 포함되지 않습니다. 90일 동안 사용되지 않은 개발자 환경은 자동으로 꺼지고 담당자가 알림에 응답하지 않으면 테넌트에서 제거됩니다. Dynamics 365 앱은 개발자 환경에서 사용할 수 없습니다. |
| 평가판 | 이러한 환경은 단기 테스트 및 개념 증명을 지원하기 위한 것입니다. 사용자당 하나로 제한됩니다. 평가판 환경은 짧은 시간이 지나면 테넌트에서 자동으로 제거됩니다. |
| Microsoft Dataverse for Teams | 이러한 환경은 Teams에서 앱을 만들거나 앱 카탈로그에서 앱을 설치할 때 자동으로 생성됩니다. 이러한 환경의 보안 모델은 연결된 팀과 일치합니다. |
| 지원 | 이는 엔지니어가 문제를 해결할 수 있도록 Microsoft 지원에서 만든 특수 환경입니다. 이러한 환경은 테넌트 용량에 포함되지 않습니다. |
전체 테넌트 환경 전략을 종합할 때 다양한 유형이 전략 권장 사항을 지원하는 데 관련됩니다.
관리형 환경
환경에는 환경 유형에 따라 기본 기능 및 특징 세트가 있습니다. 관리형 환경은 기본 기능을 확장하여 관리자가 더 많은 제어, 더 적은 노력, 더 많은 인사이트로 Power Platform을 대규모로 보다 쉽게 관리할 수 있는 프리미엄 기능 제품군을 제공합니다. 이러한 기능은 환경을 관리형으로 설정하면 잠금 해제됩니다.
다음 표에는 이 글을 쓰는 시점에 사용 가능한 관리형 환경의 기능이 나열되어 있습니다. 새로운 기능이 자주 추가되므로 최신 목록을 보려면 설명서를 확인하세요. 모든 기능이 환경 전략을 수립하는 데 도움이 될 수 있지만 기울임꼴로 표시된 기능은 이 문서에 설명된 전략과 더 관련이 있습니다.
| 가시성 향상 | 제어력 향상 | 적은 노력 |
|---|---|---|
| 사용량 인사이트 관리 다이제스트 라이선스 보고서 데이터 정책 보기 Azure Application Insights로 데이터 내보내기 모든 앱에 대한 AI 생성 설명 |
공유 제한 데스크탑 흐름에 대한 데이터 정책 솔루션 검사기 제작자 환영 콘텐츠 IP 방화벽 IP 쿠키 바인딩 고객 관리형 키 고객 Lockbox 확장된 백업 |
간편한 활성화 Power Platform 파이프라인 환경 라우팅 환경 그룹 및 규칙 Power Platform 어드바이저 |
라이선스 자동 신청
자동 신청 정책은은 특정 앱 또는 기능을 사용하기 위해 필요할 때 사용자에게 Power Apps 및 Power Automate 라이선스를 할당하는 작업을 자동화합니다. 자동화는 소비되는 라이선스 수를 줄이고 라이선스를 수동으로 할당하는 오버헤드를 방지하는 데 도움이 됩니다.
정책이 구성되면 개별 Power Apps 라이선스가 필요한 조직의 모든 사용자에게 다음 조건에 따라 자동으로 라이선스가 부여됩니다.
독립 실행형 Power Apps 라이선스가 없는 사용자가 프리미엄 라이선스를 요구하는 앱을 시작하는 경우 시스템은 사용자에게 사용자당 Power Apps 라이선스를 자동으로 할당합니다.
독립 실행형 Power Apps 라이선스가 없는 사용자가 관리형 환경에서 앱을 시작하는 경우 시스템은 사용자에게 사용자당 Power Apps 라이선스를 자동으로 할당합니다.
마찬가지로 정책이 구성되면 개별 Power Automate 라이선스가 필요한 조직의 모든 사용자에게 다음 조건에 따라 자동으로 라이선스가 부여됩니다.
사용자는 유인 RPA(로봇 프로세스 자동화)를 통해 프리미엄 클라우드 흐름을 트리거, 저장 또는 켭니다.
사용자가 Power Automate 프리미엄 라이선스를 요청합니다.
환경 전략에 관리형 환경이 포함된 경우 라이선스 자동 신청을 구성하는 것이 좋습니다. 앱 및 흐름 사용자는 라이선스 마찰이 가장 적게 발생하며, 앱을 적극적으로 실행하거나 Power Automate를 사용하는 사용자에 대해서만 라이선스를 사용합니다.
환경 그룹 및 규칙
테넌트의 Power Platform 채택이 증가함에 따라 관리 및 거버넌스가 필요한 환경의 수도 증가할 수 있습니다. 환경 수가 증가할수록 환경에 일관된 설정 및 거버넌스 정책을 적용했는지 확인하는 것이 더 어려워집니다. 환경 그룹 기능을 사용하면 이름이 지정된 그룹을 만들고 관련 문서를 파일 폴더에 배치하는 것과 같이 환경을 연결할 수 있으므로 이 작업이 더 쉬워집니다.
환경 그룹 사용에 대해 고려할 때 다음 고려 사항을 염두에 두십시오.
환경이 그룹에 포함되도록 관리되어야 합니다.
환경은 한 번에 하나의 그룹에만 있을 수 있습니다.
환경은 한 그룹에서 다른 그룹으로 이동할 수 있습니다.
그룹의 환경은 여러 지리적 지역에 있을 수 있습니다.
그룹에는 다른 그룹이 포함될 수 없습니다.
일관된 설정과 거버넌스를 적용하는 데 도움이 되도록 환경 그룹에서는 다음 규칙 중 하나 이상을 구성하고 켤 수 있습니다.
캔버스 앱용 컨트롤 공유
사용량 인사이트
제작자 환영 콘텐츠
솔루션 검사기 실행
백업 보존
AI 생성 설명
규칙은 게시되면 활성화됩니다. 활성 규칙은 그룹과 연결된 모든 환경에 적용됩니다.
그룹 규칙이 설정을 관리하는 경우 개별 환경 설정이 잠깁니다. 이를 변경하는 유일한 방법은 규칙을 수정하는 것입니다. 환경이 그룹에서 제거되면 그룹 설정이 유지되지만 이제 환경 관리자가 이를 변경할 수 있습니다. 이는 환경 관리자가 그룹에 대해 설정한 정책을 재정의할 수 없도록 보장하므로 환경 전략에 중요합니다.
환경 그룹을 사용하면 조직 구조, 제품 서비스 계층 구조 또는 나중에 살펴볼 기타 프레임워크와 유사한 논리적 방식으로 환경을 구성할 수 있습니다. 다음 다이어그램은 Contoso 조직이 환경 그룹 구성에 대해 생각할 수 있는 방법을 보여주는 개념적 예입니다.
그림: Contoso 테넌트에 대한 환경 전략 개념화.
구성할 규칙을 계획할 때 개념 계층의 각 수준에 무엇을 적용할 수 있는지 생각해 보세요. 아직 그룹 계층 구조를 구성할 수는 없지만 명명 규칙과 규칙 구성을 조합하여 개념적 설계를 구현할 수 있습니다. 예를 들어 앞서 표시된 Contoso 테넌트 개념을 고려할 때 다음 그림은 조직이 해당 디자인을 구현하는 데 사용할 수 있는 환경 그룹을 나타냅니다.
그림: 개념적 환경 그룹을 실제 테넌트에 구현한 예
이 문서의 뒷부분에서는 테넌트 환경 전략의 일부로 환경 그룹을 사용하는 더 많은 방법을 살펴봅니다.
기본 환경 라우팅
이 문서에서 설명하는 환경 전략의 핵심 부분은 제작자가 기본 환경에서 리소스를 생성하지 않도록 하는 것입니다. 환경 라우팅 기능은 제작자를 자신의 개인 개발 환경으로 리디렉션하고 필요에 따라 새로운 개발자 환경을 만듭니다.
그림: 제작자는 앱을 빌드할 때 기본 환경 대신 개인 개발자 환경으로 자동 리디렉션됩니다.
라우팅을 통해 생성된 개발자 환경은 기본적으로 관리됩니다. Developer Plan 라이선스가 있는 사용자는 환경에서 리소스를 생성하고 미리 보는 것으로 제한됩니다. 사용자로 리소스를 실행하려면 적절한 라이선스가 필요합니다.
환경 라우팅을 단독으로 사용할 수도 있지만 환경 그룹과 함께 사용하는 것이 권장됩니다. 이러한 방식으로 사용하면 생성된 모든 환경은 모든 새로운 개발자 환경을 포함하도록 지정하는 그룹과 연결되므로 거버넌스 정책이 즉시 적용됩니다.
제작자에게는 개발자 환경의 환경 관리자가 되는 보안 역할이 자동으로 할당됩니다. 환경이 환경 그룹의 일부인 경우 환경 관리자인 제작자는 환경 그룹 규칙에 따라 관리되기 때문에 환경 설정을 변경할 수 없습니다. 그룹 규칙을 수정할 수 있는 관리자만 변경할 수 있습니다.
두 가지 방법으로 더 많은 컨트롤을 적용할 수 있습니다. 첫째, 테넌트 설정에서 개발자 환경의 수동 생성을 허용하지 않을 수 있습니다. 이 옵션을 설정하면 제작자는 관리 포털에서 직접 환경을 만들 수 없습니다. 또한 라우팅 정책에 의해 자동으로 생성되는 항목도 얻지 못합니다. 둘째, 라우팅 정책에서 보안 그룹을 지정하여 환경을 자동으로 생성할 수 있는 사람을 제한할 수 있습니다.
처음에 환경 라우팅은 make.powerapps.com을 사용할 때 신규 및 기존 제작자를 기본 환경에서 벗어나 라우팅하는 것을 지원합니다. 시간이 지남에 따라 다른 Power Platform 서비스는 환경 라우팅 기능을 지원합니다.
Microsoft Dataverse
Dataverse는 애플리케이션에서 사용하는 데이터를 안전하게 저장하고 관리합니다. 환경 전략의 맥락에서 Dataverse 솔루션 기능은 한 환경에서 다른 환경으로 앱과 구성 요소를 전송하는 데 사용하는 것입니다. 제작자는 자신이 구축한 항목을 추적하는 컨테이너(솔루션)에 자산을 구축합니다. 솔루션은 다른 환경으로 쉽게 이동할 수 있습니다. 이 접근 방식을 사용하면 제작자가 리소스를 구축하는 개발자 환경과 리소스가 사용되는 프로덕션 환경을 분리할 수 있습니다. 제작자와 사용자 모두 이익을 얻습니다. 제작자는 계속해서 리소스를 발전시킬 수 있으며 사용자는 갑작스러운 변화에 놀라지 않습니다. 제작자는 변경 사항을 게시할 준비가 되면 업데이트된 리소스를 프로덕션 환경으로 승격하도록 요청할 수 있습니다.
Dataverse 솔루션은 Power Apps 및 Power Automate와 같은 Power Platform 제품에서 ALM을 구현하기 위한 메커니즘입니다. Power Platform의 파이프라인은 솔루션을 사용하여 제작자가 빌드하는 자산의 CI/CD를 자동화합니다. 솔루션은 Dataverse에서 내보내고 Azure DevOps 또는 GitHub와 같은 소스 제어 도구에 저장할 수 있습니다. 개발 환경을 다시 만들어야 하는 경우 소스 제어의 솔루션이 정보의 소스가 됩니다. 예를 들어, 제작자가 인기 있는 앱을 구축한 후 개발자 환경을 삭제한 경우 소스 제어에 저장된 내보낸 솔루션을 사용하여 실행 가능한 개발 환경을 다시 만들 수 있습니다.
Dataverse를 사용하여 환경을 만들 때 또 다른 중요한 고려 사항은 Dynamics 365 애플리케이션이 환경에 배포되는지 여부입니다. 가능성이 있는 경우 환경을 만들 때 Dynamics 365를 활성화해야 합니다. 그렇지 않으면 나중에 Dynamics 365 앱을 설치할 수 없습니다.
제작자가 다른 사용자와 공유할 자산을 만드는 모든 환경에서 Dataverse를 프로비저닝하는 것이 좋습니다. 이렇게 하면 자산을 ALM 준비하기가 더 쉬워집니다.
선호 솔루션
제작자가 Dataverse 환경에서 Dataverse 자산을 생성하고 사용자 지정 솔루션에서 시작하지 않는 경우 자산은 기본 솔루션 및 Common Data Service 기본 솔루션과 연결됩니다. 기본 솔루션은 해당 환경에서 자산을 생성하는 모든 제작자가 공유합니다. 어떤 제작자가 어떤 구성 요소를 만들었는지, 어떤 자산이 어떤 앱에 속하는지 쉽게 식별할 수 있는 방법은 없습니다. 이로 인해 인기 있는 앱을 더 큰 대상 그룹와 공유하기 위해 다른 환경으로 홍보하는 것이 어려울 수 있습니다. 이상적인 시나리오는 아니지만 기본 솔루션의 모든 자산을 승격해야 합니다.
환경 전략을 지원하고 더 쉽게 작업할 수 있도록 제작자는 개발 환경에서 맞춤형 솔루션을 생성한 다음 해당 환경에서 이를 선호 솔루션으로 설정해야 합니다. 제작자는 자신이 만든 자산이 어떤 솔루션과 연결되어야 하는지를 나타내기 위해 환경에서 선호하는 솔루션을 설정합니다. 선호하는 솔루션은 제작자가 파이프라인을 사용하여 리소스를 다른 환경으로 승격할 때 승격된 솔루션에 필요한 모든 자산이 포함되도록 보장하는 데 도움이 될 수 있습니다. 이를 ALM 준비 자산을 준비하는 것으로 생각하십시오.
Power Platform의 파이프라인
앞서 살펴보았듯이 좋은 환경 전략의 핵심 원칙은 자산이 구축되는 위치와 배포 및 사용되는 위치를 분리하는 것입니다. 이러한 분리를 통해 자산을 사용하려는 사용자는 제작자가 자산을 업데이트하므로 가동 중지 시간이 발생하지 않습니다. 그러나 자산을 사용하기 전에 프로덕션 환경(이상적으로는 Dataverse 솔루션의 일부로)으로 승격해야 합니다.
Dataverse 솔루션은 환경 간에 수동으로 전송할 수 있습니다. 하지만 파이프라인을 사용하면 프로세스를 자동화하고 적절한 변경 관리가 이루어지도록 정책을 마련할 수 있습니다. 솔루션 검사기에서 설정한 환경 규칙에 따라 파이프라인은 솔루션이 배포되기 전에 모든 규칙을 자동으로 적용하여 추가 배포 오류를 방지합니다. 다음 다이어그램은 파이프라인이 개발에서 프로덕션으로 자산 승격을 자동화하는 방법을 보여줍니다.
그림: 파이프라인은 소스 제어에 저장된 자산을 개발에서 테스트를 거쳐 프로덕션으로 승격하는 작업을 자동화합니다.
파이프라인에 포함되어야 하는 승인과 같은 환경 및 프로세스의 수를 구성할 수 있습니다.
파이프라인은 환경 그룹과 함께 작동합니다. 제작자가 자산을 다른 사용자와 공유하려고 할 때 프롬프트에 응답하여 프로모션 프로세스를 쉽게 시작할 수 있도록 개발 환경에 맞게 사전 구성될 수 있습니다. 파이프라인을 사용한 배포 요청의 일부로 제작자는 자산을 공유할 대상과 필요한 보안 역할을 제안할 수 있습니다. 파이프라인 관리자는 요청을 생성한 제작자에게 최소한의 권한을 보장하여 배포 전에 요청을 승인하거나 거부할 수 있습니다.
Power Platform의 파이프라인은 Microsoft가 기본적으로 관리하는 호스트 환경에 각 파이프라인의 정의를 저장합니다. 그러나 관리하는 테넌트에서 여러 호스트 환경을 정의하여 고유한 요구 사항을 처리할 수 있습니다.
Power Platform의 카탈로그
개발자와 제작자가 앱 및 흐름과 같은 구성 요소와 고급 시작점인 템플릿을 빌드하고 공유하는 조직은 Power Platform에서 더 많은 가치를 얻는 경향이 있습니다. Power Platform 카탈로그를 사용하면 제작자가 환경 간에 구성 요소와 템플릿을 보다 효과적으로 쉽게 공유할 수 있습니다.
카탈로그는 환경에 설치되며 동일한 환경에서 파이프라인 호스트와 함께 설치될 수 있습니다. 카탈로그가 설치된 여러 환경을 가짐으로써 고유한 리소스 분할 요구 사항을 처리하는 것도 가능합니다.
기능 로드맵
Microsoft가 거버넌스 및 관리를 지원하는 Power Platform의 기능을 계속 발전시키고 있으므로 릴리스 플래너를 팔로우할 수 있습니다. 계획된 사항, 향후 릴리스 웨이브의 내용, 지금 시도할 수 있는 사항에 대해 알아봅니다. 팔로우하려는 항목을 저장하여 자신만의 출시 계획을 만들 수도 있습니다.
전사적 환경 전략 수립
우리는 엔터프라이즈 규모의 테넌트 환경 전략에 대한 비전과 이를 지원하는 주요 환경 기능에 대해 논의했습니다. 이제 환경 전략의 일부로 이러한 기능을 함께 사용할 수 있는 방법을 살펴보겠습니다. 전략은 조직의 고유한 요구 사항을 기반으로 해야 하므로 요구 사항에 맞게 전략을 조정하는 방법을 알아보기 전에 기본적인 예부터 시작하겠습니다.
이 예에서 Contoso 경영진은 직원이 Power Platform을 활용할 수 있도록 권한을 부여하려고 하며 다음과 같은 높은 수준의 요구 사항을 식별했습니다.
직원은 Microsoft 365를 사용하여 자동화된 문서 승인 프로세스 및 기타 Power Platform 사용자 지정을 빌드할 수 있어야 합니다.
직원은 Power Apps 및 Power Automate 자동화를 빌드하여 개인 생산성을 향상시킬 수 있어야 합니다.
회사의 규정 준수 추적기 앱을 작업하는 제작자는 이를 개발하고 유지할 수 있어야 합니다.
이러한 요구 사항을 지원하기 위해 Contoso 관리 및 거버넌스 팀은 다음과 같은 환경 토폴로지를 고안했습니다.
그림: Contoso의 Power Platform 대규모 프로젝트에 대해 제안된 환경 토폴로지입니다.
이 환경 토폴로지 다이어그램을 자세히 살펴보겠습니다.
기본 환경은 Microsoft 365 생산성 사용자 지정을 빌드하는 데 사용됩니다. 데이터 손실 방지 정책 및 공유 제한은 다른 유형의 제작자 활동을 제한하고 제작자가 이 환경에서 구축할 수 있는 항목에 대한 가드레일을 배치합니다.
관리자만 평가판, 샌드박스 및 프로덕션 환경을 만들 수 있습니다. 제작자는 사용자 지정 Microsoft Form 또는 다른 프로세스를 사용하여 새로운 환경을 요청합니다. Microsoft Power Platform CoE(Center of Excellence) 스타터 키트에는 사용할 수 있는 환경 요청이 포함되어 있습니다.
개발, 공유 개발, UAT(사용자 승인 테스트) 및 프로덕션의 네 가지 환경 그룹이 생성됩니다.
개발 그룹에 대해 설정된 환경 라우팅 정책은 제작자를 기본 환경에서 자체 개발자 환경으로 라우팅합니다. 새로운 개발 환경이 생성되면 자동으로 개발 그룹과 연결되고 해당 규칙이 적용됩니다.
공유 개발 그룹은 여러 제작자가 참여하는 프로젝트가 포함된 환경을 지원합니다.
UAT 그룹에는 리소스가 프로덕션으로 승격되기 전에 테스트하는 데 사용되는 환경이 포함되어 있습니다.
프로덕션 그룹에는 프로덕션용 앱, 흐름 및 기타 아티팩트를 호스팅하는 환경이 포함되어 있습니다.
제안된 이 토폴로지에서 누락된 부분은 개발, 테스트 및 프로덕션 환경 간의 승격을 자동화하는 파이프라인입니다. 이제 추가해 보겠습니다.
그림: 파이프라인 호스트 환경을 개발, 테스트 및 프로덕션 환경에 연결하는 파이프라인이 있는 동일한 환경 토폴로지.
수정된 환경 토폴로지 다이어그램에는 파이프라인 호스트 환경과 두 개의 파이프라인이 추가되었습니다. 하나의 파이프라인은 리소스를 개발에서 테스트로 이동한 다음 프로덕션 환경으로 이동합니다. 개발 그룹의 파이프라인 규칙은 이 파이프라인을 사용하도록 수정됩니다. 다른 파이프라인은 공유 개발 환경에서 테스트로 리소스를 이동한 다음, 프로덕션으로 이동합니다. 공유 개발 그룹의 파이프라인 규칙은 이 파이프라인을 사용하도록 수정됩니다.
이 기본 환경 전략은 다음에 살펴볼 다른 사용 사례를 위해 구축할 수 있는 기반을 제공합니다.
특정 시나리오에 대한 환경 전략
기본 테넌트 환경 전략에 통합해야 할 수 있는 몇 가지 일반적인 사용 사례는 다음과 같습니다.
개발자 환경을 만들 수 있는 제작자 제어
기본적으로 Power Platform Premium 라이선스, Developer Plan 라이선스 또는 Power Platform 테넌트 관리자 역할이 있는 사람은 누구나 관리 포털에서 개발자 환경을 만들 수 있습니다.
기초 환경 전략에서 환경 라우팅은 제작자가 기본 환경에서 지정된 그룹에 생성된 새로운 개발자 환경으로 이동하도록 보장합니다. 그러나 제작자는 환경 그룹에 배치되지 않고 해당 규칙이 적용되지 않는 개발자 환경을 수동으로 생성할 수 있습니다.
환경 라우팅에 적합한 제작자를 세분화하려면 라우팅 구성에서 보안 그룹을 지정하세요. 보안 그룹이 구성되면 보안 그룹의 구성원만 라우팅됩니다. 다른 모든 항목은 기본 환경으로 돌아갑니다.
고급 제작자에 더 많은 유연성 제공
기초 환경 전략에서는 모든 새로운 제작자 환경이 지정된 개발자 환경 그룹으로 라우팅됩니다. 일반적으로 이 환경 그룹에는 상당히 제한적인 거버넌스 규칙 세트가 적용됩니다.
제작자가 더욱 발전할수록 더 많은 기능에 대한 액세스를 요청하도록 허용할 수 있습니다. 원래 환경 그룹에서 이를 제거하고 예외를 수동으로 관리하는 대신 다른 환경 그룹을 사용하여 이러한 고급 제작자를 추적할 수 있습니다.
그림: 거버넌스 규칙이 완화된 환경에 더 많은 유능한 제작자를 추가합니다.
지역 또는 사업부별로 개발자 환경 구성
현재 환경 라우팅 구현에서는 모든 새로운 개발자 환경이 단일 환경 그룹에 생성됩니다. 지역별, 사업부별 등 제작자의 개발자 환경을 정리하고 싶다면 어떻게 해야 할까요?
라우팅을 사용하여 제작자를 지정된 그룹에 생성된 새로운 개발자 환경으로 안내합니다. 그런 다음 지역, 조직 구성 단위 또는 기타 기준을 기반으로 하는 다른 그룹으로 이동하여 보다 세부적인 거버넌스 규칙을 적용할 수 있습니다.
그림: 환경 라우팅이 지정된 그룹에 개발자 환경을 만든 후 구조적으로 더 구체적인 그룹으로 이동합니다.
환경 이동은 현재 수동 작업이지만 Power Platform 관리 커넥터가 향후 업데이트에서 그룹 기능을 지원하면 자동화할 수 있습니다.
기업용 앱 개발
조직의 팀이 전사적으로 사용할 수 있는 앱을 개발 중일 수 있습니다. 팀은 IT 중심이거나 IT 및 비즈니스 사용자를 모두 포함할 수 있습니다(퓨전 팀이라고 함).
가장 단순한 환경 전략에서 프로젝트 팀은 샌드박스 또는 프로덕션 유형인 공유 환경에서 구축합니다. 개발자 환경 유형은 리소스에 대해 공동 작업하는 여러 제작자를 지원하는 최선의 방법이 아닙니다. 하지만 공유된 환경에서 충돌과 갈등이 생기지 않도록 제작자는 서로 소통해야 한다.
전용 테스트 및 프로덕션 환경은 필요하지 않습니다. 여러 애플리케이션을 호스팅하는 조직 전체의 테스트 및 프로덕션 환경에서 앱을 테스트하고 배포할 수 있습니다.
그림: 전용 환경에서 개발 중이며 다른 앱과 공유되는 환경에서 테스트 및 배포된 두 개의 엔터프라이즈 앱.
좀 더 발전된 변형에서는 각 제작자마다 개별 개발자 환경이 있습니다. 이는 제작자에게 더 큰 격리를 제공하는 이점이 있지만 통합 환경에서 개별 작업을 결합하는 것을 더 복잡하게 만들 수 있습니다. 독립적으로 작업하는 것은 규모가 크고 정교한 팀에게는 도움이 될 수 있지만, 공유 개발 환경에서 더 성공적으로 협업할 수 있는 소규모 팀에는 불필요한 오버헤드를 추가할 수 있습니다.
그림: 개별 개발자 환경에서 동일한 앱을 작업하는 두 제작자는 테스트 및 프로덕션으로 이동하기 전에 공유 통합 환경에서 작업을 결합해야 합니다.
이러한 변형은 일반적으로 소스 제어 전략을 통합하며, 각 개발 환경은 변경 사항을 승격할 준비가 되면 병합되는 소스 제어의 분기로 표시됩니다. 초기 릴리스 이후에 애플리케이션이 어떻게 유지 관리될 것인지를 고려하는 것이 중요합니다.
예를 들어 팀이 버전 2.0을 구축하는 동안 앱 버전 1.0이 프로덕션 단계에 있을 수 있습니다. 귀하의 환경 전략은 버전 2.0 개발이 진행되는 동안 버전 1.0의 문제 해결을 지원해야 합니다.
그림: 버전 2.0을 개발, 테스트 및 배포하는 동안 버전 1.0을 패치, 테스트 및 배포해야 합니다.
환경 그룹은 이 엔터프라이즈 앱 시나리오를 처리하기 위한 여러 가지 접근 방식을 제공합니다. 예를 들어 단일 앱 그룹일 수도 있고 각 개발 단계마다 별도의 그룹을 가질 수도 있습니다. 모범 사례 섹션에서는 옵션을 평가하는 방법을 살펴봅니다.
개발자 환경 사용 최소화
개별 개발자 환경은 제작자에게 로우코드 솔루션을 구축할 수 있는 작업 영역을 제공하는 데 권장되는 방법입니다. 이는 다른 제작자에 비해 최고 수준의 격리를 제공합니다. 그러나 조직에서 개발자 환경의 수를 최소화하려는 경우 제작자가 기본 환경에서 자산을 구축하도록 장려하는 것보다 여러 공유 환경이 더 좋습니다.
이 시나리오에서는 개발자 환경 생성을 제한하고 공유 프로덕션 유형 개발 환경을 생성합니다. 조직 구조, 지역 또는 기타 기준에 따라 이러한 공유 환경을 구성할 수 있습니다. 환경 그룹에는 일관된 거버넌스 규칙이 적용되도록 이를 포함할 수 있습니다. 제작자에게 할당된 환경에서 로우 코드 자산을 생성할 수 있는 권한을 부여합니다.
환경 전략의 일부인 보안
환경은 Power Platform을 안전하게 사용하기 위한 핵심 구성 요소입니다. 이는 앱과 데이터를 보호하는 데 도움이 되는 테넌트 내의 보안 경계를 나타냅니다. 환경 전략의 일환으로 보안 요구 사항이 테넌트 환경의 수와 목적에 어떻게 영향을 미치는지 고려해야 합니다.
환경을 사용하면 테넌트 내에 여러 보안 경계를 만들어 앱과 데이터를 보호할 수 있습니다. 환경에서 제공되는 보호는 구성 가능한 보안 기능 세트를 환경에 적용하여 필요한 보안 보호를 충족하도록 조정할 수 있습니다. 개별 환경 보안 기능에 대한 자세한 논의는 이 문서의 범위를 벗어납니다. 그러나 이 섹션에서는 보안을 테넌트 환경 전략의 일부로 생각하는 방법에 대한 권장 사항을 제공합니다.
테넌트 수준의 보안
환경에 영향을 미치는 대부분의 보안 설정은 각 환경에 대해 개별적으로 구성됩니다. 그러나 환경 전략을 지원하는 데 도움이 되도록 테넌트 수준에서 일부 변경을 수행할 수 있습니다.
- Power Platform에서 모든 사람과 공유 기능을 끄는 것을 고려해보세요. 관리자만이 자산을 모든 사람과 공유할 수 있습니다.
- Exchange와의 통합 보안을 고려하세요.
- 테넌트 간 격리를 적용하여 테넌트 간 데이터 반출 위험을 최소화하세요.
- 완전히 새로운 프로덕션 환경 생성을 관리자로 제한합니다. 환경 생성 제한은 일반적으로 제어를 유지하는 데 도움이됩니다. 설명되지 않은 용량 소비를 방지하고 관리할 환경 수를 줄이는 데 모두 유용합니다. 사용자가 중앙 IT에 환경을 요청해야 하는 경우 관리자가 게이트키퍼라면 사람들이 어떤 작업을 하고 있는지 더 쉽게 확인할 수 있습니다.
기본 환경 보안
기본 환경에는 Microsoft 365 생산성 사용자 지정을 지원하는 역할이 있습니다. 그러나 권장되는 환경 전략의 일환으로 사용을 최대한 최소화하는 것이 가장 좋습니다. 대신, 제작자는 자신만의 격리된 환경에서 구축해야 합니다. 기본 환경에 대한 접근을 차단할 수는 없지만, 기본 환경에서 수행할 수 있는 작업을 최소화할 수 있습니다.
첫째, 환경 라우팅을 사용하여 제작자를 자신의 작업 영역으로 안내하여 로우코드 자산을 구축합니다.
기본 환경에 대한 관리자 액세스 권한이 있는 사람을 검토하고 이를 필요한 역할로 제한합니다.
기본 환경의 이름을 "개인 생산성"과 같이 좀 더 설명적인 이름으로 바꾸는 것이 좋습니다.
새로운 커넥터를 차단하고 제작자가 차단할 수 없는 기본 커넥터만 사용하도록 제한하는 기본 환경에 대한 데이터 손실 방지(DLP) 정책을 설정합니다. 차단할 수 없는 모든 커넥터를 비즈니스 데이터 그룹으로 이동합니다. 차단 가능한 모든 커넥터를 차단된 데이터 그룹으로 이동합니다.
사용자 지정 커넥터에서 사용되는 모든 URL 패턴을 차단하는 규칙을 만듭니다.
기본 환경을 확보하는 것이 우선되어야 합니다. 환경 전략 구현의 첫 번째 단계의 일부로 테넌트 수준 보안과 함께 수행합니다. 이를 구현하지 않으면 제작자는 자산을 기본값으로 추가할 수 있는 더 많은 기회를 갖게 됩니다. 환경 라우팅과 함께 이를 적용하면 제작자는 자신의 환경을 사용하도록 권장됩니다.
다른 환경의 보안
조직이 대부분과 같은 경우 기본 환경 외에도 여러 환경이 있습니다. 각각에 필요한 보안 수준은 포함된 앱과 데이터에 따라 달라질 수 있습니다. 개발자 환경은 일반적으로 프로덕션 환경보다 더 완화된 규칙을 갖습니다. 일부 프로덕션 환경에서는 최대한의 보호가 필요합니다.
환경 전략 수립의 일환으로 다음 예와 같이 환경에 대한 일반적인 보안 수준과 각 수준을 보호하는 기능을 식별합니다.
그림: 환경 보안의 세 가지 계층과 각 계층의 환경에 적용되는 보안 기능의 예입니다.
식별한 보안 수준을 그룹 전략에 통합하고, 가능한 경우 규칙을 사용하여 환경에서 보안 기능을 활성화하십시오. 이 예에서 규칙은 일반 또는 중간 보안으로 지정된 모든 환경에서 공유를 제한합니다.
데이터 손실 방지 전략에 맞게 환경 조정
데이터 정책은 환경의 로우코드 리소스가 사용하는 서비스를 제어하기 위한 전반적인 거버넌스 노력의 또 다른 중요한 부분입니다. 환경 그룹에는 환경에 DLP 정책을 적용하는 규칙이 없습니다. 그러나 DLP 전략을 환경 그룹에 맞출 수 있습니다. 예를 들어 환경 그룹과 동일하거나 유사한 이름으로 DLP 정책을 생성하고 해당 그룹의 환경에 적용할 수 있습니다.
그림: 이 예에서 Personal Dev 그룹의 환경은 모든 타사 커넥터를 차단하는 DLP 정책을 따릅니다.
조직에 맞게 환경 전략 맞춤화
이전 섹션에서는 조직이 규모에 맞게 환경을 관리할 수 있는 방법에 대한 비전을 설명했습니다. 필수 기능, 해당 기능이 환경 전략에 어떻게 기여하는지, 그리고 이를 사용하는 기본 환경 토폴로지는 어떤 모습일지 살펴보았습니다. 일반적인 시나리오를 수용하기 위해 해당 기반을 구축하는 방법에 대한 예를 제공했습니다. 모든 조직은 고유하므로 다음 단계는 조직의 요구 사항을 충족하는 환경 전략을 맞춤화하는 것입니다.
현재 위치에서 시작
조직에서 Power Platform을 처음 사용하든 몇 년 동안 사용해 왔든 관계없이 첫 번째 단계는 상황을 평가하는 것입니다. 기본 환경에 무엇이 있는지, 다른 환경이 무엇인지, 어떤 용도로 사용되고 있는지 높은 수준에서 평가하세요. 환경 전략은 조직에서 Power Platform의 거버넌스를 설정하기 위한 전반적인 노력의 일환으로 수행되는 경우가 많습니다. 그렇다면 조직에 맞게 전략을 조정하는 데 필요한 거버넌스 비전 중 일부를 이미 설정했을 수 있습니다.
알아야 할 조직 정보는 다음과 같습니다.
조직에서 Power Platform을 사용하는 방법에 대한 비전은 무엇입니까?
조직에서 누가 로우코드 자산을 구축하게 될까요?
몇 가지 주요 결정을 내려야 합니다.
제작자는 어떻게 새로운 환경을 확보할 수 있을까요?
환경을 그룹화할 예정입니까? 그렇다면 어떻게 그룹화할 것입니까?
다양한 환경에 필요한 보안 수준은 무엇이며, 환경은 어떻게 분류됩니까?
앱, 자동화 또는 Copilot이 기존 환경을 사용할지 아니면 새 환경을 사용할지 어떻게 결정합니까?
플랫폼의 기본 기능과 사용자 지정 거버넌스 프로세스가 필요한 요구 사항 사이에 차이가 있습니까?
기본 환경에서 기존 자산을 어떻게 처리할 예정인가요?
테넌트 및 환경 DLP 정책 전략이 있습니까? 그렇다면 생성 중인 환경 전략과 어떻게 일치합니까?
Azure용 클라우드 채택 프레임워크의 일부인 클라우드 운영 모델에서도 영감을 얻을 수도 있습니다.
플랫폼을 사용하여 격차 해소
플랫폼의 기본 제공 기능이 충족하지 않는 요구 사항은 거의 항상 있습니다. 이러한 격차를 평가할 때 다음과 같은 평가 결과를 고려하세요.
해당 격차는 허용됩니다.
Power Platform Center of Excellence 스타터 키트를 사용하여 격차를 해소할 수 있습니다.
API, 커넥터, 사용자 지정 앱, 자동화 등 플랫폼의 기능을 사용하여 격차를 해소할 수 있습니다.
타사 도구나 앱을 사용하여 격차를 해소할 수 있습니다.
CoE 시작 키트
Power Platform Center of Excellence 스타터 키트는 조직이 Power Platform 사용을 채택하고 지원하는 데 도움이 되도록 설계된 구성 요소 및 도구 모음입니다. 스타터 키트의 주요 측면은 환경 전략을 개발하고 발전시킬 때 도움이 될 수 있는 환경 전체의 플랫폼 사용에 대한 데이터를 수집하는 기능입니다.
예를 들어 환경 Power BI 대시보드는 테넌트에 있는 환경, 환경을 만든 사람 및 포함된 자산을 이해하는 데 도움이 되는 개요를 제공합니다.
그림: Power BI의 환경 대시보드.
키트에는 제작자가 새로운 환경을 요청하고 해당 환경에 대한 DLP 정책을 변경하는 데 사용할 수 있는 프로세스와 같은 시작점이나 영감이 포함되어 있습니다.
그림: CoE 스타터 키트의 환경 관리 프로세스를 보여주는 흐름도.
플랫폼 프로그래밍 기능 및 확장성
로우코드 플랫폼의 가장 큰 장점 중 하나는 이를 사용하여 관리에 도움이 되는 앱, 자동화, 포털 및 Copilot을 구축할 수 있다는 것입니다. 또한 환경 전략 지원의 격차를 해소하는 데 사용할 수 있는 하위 수준 도구에 액세스할 수도 있습니다.
다음 커넥터를 사용하여 앱과 흐름을 구축할 수 있습니다.
Power Platform 명령줄 인터페이스(CLI)를 사용하여 환경 수명 주기 및 DevOps 사례와 관련된 기타 작업을 관리하는 데 도움이 되는 자동화를 개발할 수 있습니다.
Power Platform 작성자 및 관리자용 PowerShell cmdlet을 사용하면 다양한 모니터링 및 관리 작업을 자동화할 수 있습니다.
Power Platform DLP SDK는 테넌트 및 환경 데이터 손실 방지 정책을 관리하는 데 도움이 될 수 있습니다.
모범 사례 권장 사항
문서의 이 섹션에서는 기초 및 시나리오별 섹션의 권장 사항을 기반으로 합니다.
새 환경
전략 개발의 일환으로 워크로드를 지원하는 환경을 생성하는 시기를 고려하십시오. 평가는 환경이 제공하는 격리의 이점(예: 특정 환경을 다른 환경보다 더 많이 잠글 수 있음)과 격리가 앱 간에 데이터를 공유하려는 사용자에게 마찰을 발생시킨다는 단점 간의 균형을 맞춰야 합니다.
앱이나 자동화가 자체 환경에 속하는지 평가할 때 앱 수명 주기의 여러 단계를 개별적으로 평가하세요. 개발 중에는 다른 앱과의 격리가 중요합니다. 단일 환경에서 여러 앱이 개발되면 앱 간 종속성이 발생할 위험이 있습니다.
일반적인 권장 사항에 따르면 개발 환경은 단일 목적으로 사용하고 일회용이며 쉽게 다시 만들 수 있어야 합니다.
동일한 환경에서 여러 앱을 테스트하는 것은 프로덕션 환경에서 함께 실행되는 경우 의미가 있습니다. 실제로 프로덕션에서 실행될 앱으로 테스트하지 않으면 호환성 문제를 발견하지 못할 위험이 있습니다.
앱의 프로덕션 환경을 평가할 때 다음 사항을 염두에 두세요.
앱이 환경의 기존 앱과 호환되는가? 예를 들어 Dataverse 연락처 테이블을 서로 다른 목적으로 사용하는 두 앱은 호환되지 않을 수 있습니다. DLP 정책 관점에서 앱이 호환되는가?
데이터 분리에 대한 특별한 규정 준수 또는 규제 요구 사항이 있는가? 예를 들어, 데이터의 민감도를 격리해야 하는가? 데이터를 다른 데이터에 포함할 수 없다는 요구 사항이 있는가?
데이터가 매우 기밀이거나 민감한가? 유출로 인해 조직에 금전적 또는 평판 손상이 발생하는가? 별도의 환경에 격리하면 보안을 더 효과적으로 제어할 수 있습니다.
앱에 다른 앱의 데이터가 필요하고 해당 앱과 함께 배치되어야 하는가? 예를 들어 고객 테이블을 사용하는 두 개의 앱을 함께 호스팅해야 합니다. 이를 분리하면 중복된 데이터 복사본이 생성되고 데이터 유지 관리에 문제가 발생합니다.
데이터에 지역 데이터 보존이 필요한가? 일부 시나리오에서는 적절한 데이터 격리 및 보존을 보장하기 위해 동일한 앱 또는 자동화를 지역 환경에 배포할 수 있습니다.
대부분의 사용자가 환경과 동일한 지역에 있습니까? 환경이 EMEA에 있지만 대부분의 앱 사용자가 미국에 거주하는 경우 환경을 공유해도 최상의 성능을 제공하지 못할 수 있습니다.
새로운 관리자가 필요한가, 아니면 기존 관리자로 충분한가? 새 앱에 더 많은 관리자가 필요한 경우 모든 관리자가 환경의 모든 앱에 대한 관리자 권한을 가지므로 기존 관리자와 호환되는가?
앱의 기대 수명은 얼마나 되는가? 앱이나 자동화가 일시적이거나 수명이 짧은 경우 보다 영구적인 앱이 있는 환경에 설치하는 것은 좋지 않을 수 있습니다.
사용자가 다양한 앱에 대해 여러 환경을 사용해야 하는 데 어려움을 겪는가? 이는 모바일 디바이스에서 앱을 찾는 것부터 여러 환경에서 데이터를 가져와야 하는 셀프 서비스 보고에 이르기까지 모든 것에 영향을 미칠 수 있습니다.
수용 인원
평가판 및 개발자 환경을 제외한 각 환경은 초기 프로비전에 1GB를 사용합니다. 용량은 테넌트 전체에서 공유되므로 필요한 사람에게 할당해야 합니다.
다음을 통해 용량을 절약하십시오.
- 공유 테스트 및 프로덕션 환경 관리. 공유 개발 환경과 달리 테스트 및 프로덕션 환경의 권한은 테스트를 위한 사용자 액세스로 제한되어야 합니다.
- 임시 개발 환경 정리를 자동화하고 테스트 또는 개념 증명 작업을 위한 시험 환경 사용을 권장합니다.
환경 그룹
환경 그룹은 유연하며 조직 고유의 다양한 사용 사례를 수용할 수 있습니다. 환경 전략의 일부로 환경 그룹화를 고려할 수 있는 몇 가지 방법은 다음과 같습니다.
서비스 또는 구성 요소별 예: ServiceNow 서비스 트리
개발, 테스트 및 생산
부서, 비즈니스 그룹 또는 비용 센터
프로젝트별
위치별로, 한 위치에 있는 대부분의 환경에 유사한 거버넌스 요구 사항이 있는 경우 이는 또한 유사한 지역 규제 및 법률 준수를 충족하는 데 도움이 될 수 있습니다.
그림: 서로 다른 두 부서의 환경 그룹에는 서로 다른 규칙이 있습니다.
환경 및 그룹 이름 지정
전략의 일환으로 환경과 그룹의 이름을 지정하는 방법을 고려하세요.
환경 이름은 관리자, 제작자 및 사용자에게 표시됩니다. 일반적으로 관리자만 환경 그룹을 사용하지만 제작자는 환경을 생성할 수 있는 권한이 있는 경우 이 그룹을 사용할 수 있습니다.
자동으로 생성된 개발자 환경은 <사용자 이름>의 환경 패턴을 따릅니다. 예를 들어 "Avery Howard의 환경"입니다. 환경 그룹의 이름은 자동으로 지정되지 않습니다.
환경 및 환경 그룹 이름은 고유할 필요가 없습니다. 그러나 혼동을 피하기 위해 중복된 이름을 피하는 것이 가장 좋습니다.
이름은 100자로 제한됩니다. 이름이 짧을수록 사용하기가 더 쉽습니다.
일관된 명명 규칙을 설정합니다.
일관된 이름은 관리자가 그룹의 목적이 무엇인지, 그룹이 관리하는 환경을 파악하는 데 도움이 되며 자동화 및 보고를 더 쉽게 만들 수 있습니다.
일반적인 관행은 환경 이름에 수명 주기 단계를 포함하는 것입니다. 예를 들어 Contoso Dev, Contoso Test, Contoso Prod입니다. 목표는 콘텐츠는 동일하지만 목적이 다른 환경을 명확하게 분리하는 것입니다.
또 다른 일반적인 관행은 환경이 해당 사용자 그룹 전용일 때 이름에 부서나 사업부를 포함하는 것입니다.
예를 들어 모든 환경 또는 환경 그룹 이름이 <수명주기 단계>-<지역>-<사업부>-<목적>(Prod-US-Finance-Payroll) 패턴을 따라야 한다고 결정할 수 있습니다.
이름은 짧고, 의미 있고, 설명적이어야 합니다.
시간이 지남에 따라 그룹이 어떻게 발전하고 성장할지 생각해 보고 명명 규칙이 이러한 변화하는 요구 사항을 수용할 수 있는지 확인하세요.
이름에 기밀 정보를 포함하지 마십시오. 관리 센터에 액세스할 수 있는 모든 사람에게 표시될 수 있습니다.
기본 환경의 자산
환경 전략은 개인 개발 환경의 사용을 권장(또는 시행)하여 기본 환경에서 생성되는 환경을 줄여야 합니다. 하지만 제작자가 기본 환경에 이미 만들어 놓은 것이 무엇인지 살펴보고 각 사용 사례를 어떻게 처리할지 평가해야 합니다. 기본 환경을 그대로 두는 것이 적절한가, 아니면 다른 환경으로 마이그레이션해야 하는가?
이러한 위생 노력을 수행하는 핵심 부분은 조직에서 광범위하게 사용되며 프로덕션 환경과 별도로 보호되는 자체 개발 환경을 보유해야 하는 응용 프로그램을 식별하는 것입니다.
다음 표에는 사용 사례 및 마이그레이션 작업 예시가 나와 있습니다. 궁극적으로 조직은 자산을 기본 환경에 두는 것과 관련된 자체 사용 사례 및 위험 요소를 식별해야 합니다. 기본 환경에서 자산을 이동하는 경우에 대해 자세히 알아보기.
| 기본 환경 | 마이그레이션 작업 |
|---|---|
| Microsoft 365 개인 생산성 | 기본 환경을 유지합니다. |
| 최근에 사용되었으나 공유되지 않은 단일 제작자의 자산 | 담당자의 개인 개발자 환경으로 이동합니다. |
| 최근에 사용되어 공유된 단일 제작자의 자산 | 담당자의 개인 개발자 환경으로 이동하여 공유 프로덕션 환경에서 실행합니다. |
| 최근에 사용되어 공유된 여러 제작자의 자산 | 공유 개발자 환경으로 이동하고 공유 프로덕션 환경에서 실행합니다. |
| 최근에 사용되지 않은 자산 | 담당자에게 알리고 응답이 없으면 격리 장소로 이동합니다. |
Dataverse for Teams 환경의 자산
Microsoft Dataverse for Teams는 사용자가 Power Apps, Microsoft Copilot Studio 및 Power Automate를 사용하여 Microsoft Teams에서 사용자 지정 앱, 봇 및 흐름을 빌드할 수 있도록 합니다. 팀 담당자가 이 기능을 팀에 추가하면 Dataverse for Teams 데이터베이스가 있는 Microsoft Power Platform 환경이 생성되고 팀에 연결됩니다. Microsoft Dataverse for Teams 환경을 관리하기 위한 거버넌스 정책을 설정하는 방법을 알아봅니다..
Microsoft 내부 환경 전략
Microsoft는 내부적으로 Power Platform을 채택하여 직원 간의 자동화 및 효율성을 촉진하기 때문에 스스로를 "Customer Zero"로 간주합니다. 다음 숫자는 Microsoft 내부 테넌트 전체의 사용 규모에 대한 아이디어를 제공합니다.
매달 활성 제작자 50,000-60,000명
250,000개 이상의 애플리케이션과 300,000개 이상의 흐름
20,000개 이상의 환경
Microsoft는 이전 환경 전략에서 관리형 환경, 환경 그룹 및 규칙을 포함한 최신 Power Platform 거버넌스 기능을 사용하는 전략으로 전환하고 있습니다.
향상된 전략의 일환으로 Microsoft는 개발 유형, 조직 소유권 및 위험 수준을 기반으로 시나리오를 그룹화할 계획입니다. 회사 전체에 걸쳐 너무 많은 것이 구축되고 있기 때문에 가능한 모든 시나리오에 집중하고 각 사용 사례에 맞게 사용자 지정하는 것은 너무 어렵습니다. 너무 많은 일이 일어나고 있으므로 이를 자동화하고 가능한 한 많은 기본 컨트롤을 활용해야 합니다.
Microsoft는 Power Platform 환경을 다양한 수준의 위험 및 제어(개인 생산성, 팀 협업 및 엔터프라이즈 개발)를 반영하는 7가지 사용 사례를 다루는 세 가지 광범위한 범주로 구성하고 있습니다.
개인 생산성 – 스스로 앱이나 흐름을 구축하려는 사람을 위한 것입니다. 예를 들어, 그들은 다른 사람들과 협력하지 않습니다. 이러한 사용자는 잠겨 있는 개인 개발 환경으로 라우팅됩니다. 이러한 환경은 공유 제한을 포함하여 관리되는 환경 기능을 사용하고 환경에서 수행할 수 있는 다른 작업도 제어합니다. 이 환경 그룹에서는 사용 가능한 커넥터와 작업이 크게 제한됩니다. 이러한 환경은 위험이 가장 적습니다. 잠긴 개인 환경을 사용하면 사용자는 개인 생산성 앱과 흐름을 구축하기 위해 더 엄격한 규정 준수 프로세스를 피할 수 있습니다.
팀 협업 – 팀을 위한 도구, 자동화, 프로세스를 구축하는 사용자를 위한 것입니다. 이 시나리오의 경우 Microsoft는 Dataverse for Teams 환경을 사용할 것을 권장합니다. 수명 주기, 액세스 관리 및 데이터 레이블 지정은 Microsoft 365 그룹 수준에서 제어되므로 Power Platform 거버넌스 관점에서 이러한 사용자를 관리하는 데 시간을 할애할 필요가 없습니다. 이 사용 수준은 위험 스펙트럼의 다음 단계입니다.
모든 직원이 사용하는 엔터프라이즈 개발/프로덕션 수준 – 이는 회사 전체에서 보다 광범위하게 사용되는 인력 구축 도구 또는 솔루션입니다. 이러한 환경은 가장 중요한 데이터를 저장하고, 더 강력한 커넥터를 사용하며, 더 많은 거버넌스가 필요할 수 있습니다. 이는 가장 높은 위험으로 간주되며 거버넌스에 대부분의 노력이 소요됩니다. ALM이 필요하며, 사전 프로덕션 작업은 샌드박스 환경에서 이루어지며 프로덕션 환경에서는 관리형 솔루션만 허용됩니다. 이러한 환경은 반복적인 보안 및 개인 정보 보호 검토를 시행하는 ServiceTree에 연결되어야 합니다. 환경 그룹 규칙은 ServiceTree 메타데이터 및 신호를 기반으로 사용자 지정됩니다. 이러한 환경을 관리하고 제어하는 데는 많은 환경 그룹과 규칙이 사용됩니다.
Microsoft의 거버넌스 전략은 고정되어 있지 않습니다. 새로운 과제에 적응하고 새로운 Power Platform 기능을 통합하는 것은 유동적이고 변화합니다.
테넌트 환경 전략 발전
이 문서에서는 엔터프라이즈 규모의 테넌트 환경 전략을 수립하는 방법을 설명했습니다. 여정의 시작 위치에 관계없이 전략은 비즈니스와 함께 성장할 수 있습니다. 어떤 규모의 조직이라도 우리가 제시하는 전략의 혜택을 누릴 수 있습니다. 그러나 이미 규모가 더 큰 조직의 경우 이점이 더 큽니다.
테넌트 환경 전략 개발은 일회성 활동이 아닙니다. 여정입니다. 시간이 지남에 따라 요구 사항이 변화함에 따라 전략을 발전시켜야 합니다. 또한 플랫폼의 새로운 기능을 채택하고 새로운 과제를 해결하도록 전략을 조정해야 합니다.
모든 여정과 마찬가지로 다양한 조직이 도중에 서로 다른 지점에 합류하지만 모두 동일한 목적지를 염두에 두고 있습니다. 다음은 귀하의 조직이 현재 어디에 있는지를 나타내는 가능한 진입로입니다.
시작
조직은 Power Platform을 채택하기 위한 여정의 시작 단계에 있습니다. 이를 종종 그린필드라고 합니다. 기존 환경이나 조직의 사람들이 Power Platform을 사용하는 방식에 미칠 수 있는 새로운 정책에 대해 걱정할 필요가 없기 때문에 가장 좋은 위치에서 여정을 시작할 수 있습니다. 지금은 제품 기능 및 모범 사례에 부합하는 엔터프라이즈 규모 환경 전략을 구현하기에 가장 좋은 시기입니다.
이 문서에 설명된 주요 환경 기능과 전략을 살펴보세요. 요구 사항에 가장 적합한 테넌트 환경 전략을 설계하고 구현하는 데 필요한 주요 주제와 고려 사항 및 결정을 이해하는 데 시간을 투자하십시오.
정해진 전략 없이 시작할 경우 나중에 발생할 수 있는 통제 불능 상황을 피하기 위해서는 지금 탄탄한 기반을 구축하는 것이 필수적입니다. Power Platform의 사용을 빠르게 가속화할 계획을 세우되 필요하지 않은 복잡성을 추가하여 환경 전략을 과도하게 엔지니어링하려는 유혹을 피하십시오. 이는 하나의 여정이며 요구 사항이 변화함에 따라 전략을 계속해서 발전시킬 수 있다는 점을 기억하십시오.
정렬
조직은 새로운 Power Platform 기능 및 모범 사례에 맞게 수정해야 하는 환경 전략을 가지고 있으며 실행하고 있습니다. 이를 종종 브라운필드라고 합니다. 이제 막 시작한 조직과 달리 환경 전략 변경이 조직에 미치는 영향을 고려해야 합니다.
이 문서에 설명된 주요 환경 기능과 전략을 살펴보고 전략을 보다 일치하도록 발전시키는 데 필요한 것이 무엇인지 평가하세요. 일반적으로 필요한 것은 점진적인 조정뿐입니다. 가능하다면 사용자에게 미치는 영향을 최소화하기 위해 변경 사항 출시를 계획하세요.
다음 제안 사항은 구현할 수 있는 일반적인 증분 변경 사항입니다.
기존 환경에 영향을 주지 않고 정렬을 시작하려면 새로운 개발자 환경을 포함하는 환경 그룹을 만들고 이를 관리하는 방법에 대한 규칙을 설정하세요. 모든 새로운 개발자 환경이 지정된 그룹에 생성되도록 하려면 환경 라우팅을 켜십시오.
그룹화 전략을 평가하고 필요한 경우 기존 환경을 지원하는 그룹을 만듭니다. 기존 제한 사항 및 예외 사항에 부합하는 그룹에 대한 규칙을 설정하세요. 기존 환경을 해당 그룹으로 이동합니다.
기본 환경에서 구축되고 사용되는 널리 사용되는 애플리케이션을 식별합니다. 파이프라인을 사용하여 조직의 사용자가 실행할 수 있는 프로덕션 환경에 게시합니다. 그런 다음 해당 앱 개발을 개인 개발자 환경 또는 전용 개발 환경으로 마이그레이션하는 작업을 진행하세요.
기본 환경에서 사용되지 않는 자산을 식별, 격리, 제거하기 위한 계획을 수립하세요.
향상
실행 중인 환경 전략은 이미 최신 기능 및 모범 사례에 부합하지만 조직에서는 더 많은 제어 또는 기능을 추가하기를 원합니다.
조직에 환경 전략 전달
Power Platform 사용자가 달성하려는 것을 이해하고 일치하면 테넌트 환경 전략을 보다 성공적으로 구현할 수 있습니다. 아무런 의사소통 없이 단순히 전략을 활성화하는 경우 사용자는 변경 사항을 제한 사항으로 보고 이를 해결할 수 있는 방법을 찾습니다.
전략 개발 또는 발전의 일환으로 Power Platform 사용에 영향을 미치는 전략의 핵심 요소를 사용자에게 알리는 방법을 결정합니다. 전략의 모든 기술적 세부 사항이 필요하지 않으며 다음과 같이 생산성을 유지하는 데 도움이 되는 필수 요소만 필요합니다.
기본 환경의 목적
새로운 로우코드 자산을 빌드해야 하는 위치
개인 개발자 환경을 사용하는 방법
특정 사업부 또는 프로젝트에 대한 사용자 지정 환경을 요청하는 방법
일반 커넥터 사용 정책 및 해당 환경에 대한 추가 커넥터 권한을 요청하는 방법
자신이 만든 것을 다른 사람과 공유하는 방법
제작자의 책임: 예:
테넌트를 정리합니다. 더 이상 필요하지 않은 경우 환경, 앱 및 흐름을 삭제합니다. 실험하는 경우 테스트 환경을 사용합니다.
현명하게 공유합니다. 환경, 앱, 흐름 및 공유 연결의 과도한 공유에 주의합니다.
조직 데이터를 보호합니다. 매우 기밀 또는 기밀 데이터 소스에서 보호되지 않는 또는 외부 스토리지로 데이터를 이동하지 않습니다.
전략이 변경되면 변경 사항이 사용자에게 어떤 영향을 미치는지 공유하여 사용자가 무엇을 다르게 해야 할지 알 수 있도록 하세요.
좋은 시작은 새로운 제작자가 추가되는 환경 그룹에서 제작자 환영 콘텐츠를 켜는 것입니다.
그림: 환영 콘텐츠를 사용하여 새로운 제작자의 성공을 돕습니다.
사용자와 소통하는 또 다른 효과적인 방법은 내부 Power Platform 허브를 설정하는 것입니다. 허브는 사람들이 프로젝트에서 협업하고, 아이디어를 공유하고, 더 많은 것을 성취하기 위해 기술을 적용하는 새로운 방법을 발견하는 장소가 될 수 있습니다. 허브는 사용자와 관련된 환경 전략에 대한 더 자세한 정보를 공유하는 곳일 수 있습니다. 내부 Power Platform 허브를 만드는 방법 알아보기.
결론
이 문서에서는 조직이 엔터프라이즈 규모로 Power Platform 환경을 관리하고 테넌트 환경 전략에 통합하는 데 도움이 되도록 설계된 기능을 살펴보았습니다.
조직에서 Power Platform을 채택하고 사용량이 가속화됨에 따라 환경에 대한 요구가 빠르게 바뀔 수 있습니다. 환경 전략이 변화를 따라가고 조직의 진화하는 거버넌스 요구 사항을 지속적으로 충족하는 데 도움이 되는 민첩한 접근 방식이 필요합니다.
테넌트 환경 전략의 성공을 위한 핵심 요소는 제작자 및 사용자와 소통하고 그들의 지원을 얻는 것입니다. 로우코드 애플리케이션 및 자동화를 구축하는 사람들이 조직의 환경 전략을 따르는 방법과 로우코드 자산을 구축해야 하는 위치를 알고 있는지 확인하십시오.
Power Platform을 채택하기 위한 모든 조직의 여정은 고유합니다. 우리는 올바른 출발을 하는 데 도움이 되는 몇 가지 아이디어를 제시했습니다. Microsoft 계정 팀 또는 Power Platform 파트너는 조직에 대해 보다 맞춤화된 테넌트 환경 전략을 만드는 데 도움을 줄 수 있습니다.