GitHub vs. Azure DevOps: 엔터프라이즈 분석을 위한 올바른 CI/CD 플랫폼 선택

By Mirko Peters · 2026-08-12 · Updated 2026-08-29

Microsoft Fabric과 같은 최신 엔터프라이즈 분석 플랫폼을 구축할 때, 올바른 지속적 통합 및 지속적 배포(CI/CD) 기반을 선택하는 것은 핵심적인 아키텍처 결정입니다…

Automatically translated with AI from the original post. Read the English original

Microsoft Fabric과 같은 최신 엔터프라이즈 분석 플랫폼을 구축할 때, 올바른 지속적 통합 및 지속적 배포(CI/CD) 기반을 선택하는 것은 핵심적인 아키텍처 결정입니다. 많은 조직이 GitHub와 Azure DevOps 중에서 선택해야 하는 갈림길에 서게 됩니다. 두 플랫폼 모두 Microsoft의 방대한 개발자 도구 생태계에서 출발했지만, 서로 다른 역사적 워크플로, 거버넌스 패러다임, 커뮤니티 구조를 기반으로 합니다. 이러한 도구들이 거버넌스, 아티팩트 관리, 파이프라인 유연성을 어떻게 처리하는지 이해하면 배포 전략이 정해지고 전체 플랫폼의 성공 여부도 좌우됩니다.

이 아키텍처 문제를 더 깊이 살펴보고 이들 도구가 데이터 배포에 어떤 영향을 미치는지 전체적으로 알고 싶다면 관련 에피소드를 들어 보시기 바랍니다: GitHub vs Azure DevOps for Microsoft Fabric CI/CD.

배포 소유권 이해하기

배포 소유권이란 무엇인가

배포 소유권은 DevOps 프로세스의 모든 단계를 직접 통제할 수 있다는 뜻입니다. 코드가 개발에서 전달까지 어떻게 이동할지 결정합니다. DevOps 도구에 누가 접근할 수 있는지, 변경 사항을 어떻게 추적할지도 관리합니다. 자동화 규칙을 정하고 팀이 이를 따르도록 합니다.

코드와 아티팩트

DevOps 플랫폼에서는 소스 코드와 아티팩트를 직접 관리합니다. 이 구성 요소들은 배포 파이프라인의 기반을 이룹니다. 최신 DevOps 도구에서 배포 소유권을 구성하는 주요 요소는 다음과 같습니다:

• 소스 코드 추적
• 테스트
• 배포
• 인프라 관리
• 빌드 추적
• 비밀 관리
• 릴리스 관리

이러한 단계는 DevOps 도구로 자동화합니다. 자동화를 통해 업데이트를 더 빠르게 전달하고 오류를 줄일 수 있습니다. 코드를 안전하게 보호하고 아티팩트가 테스트된 버전과 일치하도록 합니다. 빌드와 릴리스를 추적하여 환경 전반의 일관성을 유지합니다.

접근 및 거버넌스

DevOps 도구에 대한 접근을 통제하고 거버넌스 정책을 설정합니다. 누가 코드를 보고, 편집하고, 배포할 수 있는지 결정합니다. 자동화를 사용하여 규칙을 적용하고 활동을 모니터링합니다. 거버넌스는 개발과 전달 과정에서 팀이 표준을 따르도록 보장합니다. 작업을 기록하고 변경 사항을 검토하여 소프트웨어 개발 프로세스를 보호합니다.

소유권이 중요한 이유

소유권은 DevOps 환경을 직접 통제할 수 있게 해 줍니다. 배포 파이프라인을 위험으로부터 보호하고 개발 환경을 안전하게 유지합니다. 또한 법규를 준수하고 운영 통제를 뒷받침합니다. 아래 표는 DevOps에서 배포 소유권이 중요한 이유를 보여 줍니다:

DevOps 도구를 활용해 견고한 거버넌스 프레임워크를 구축합니다. 팀이 독립적으로 일할 수 있는 자율성을 확보합니다. 위험을 관리하고 배포 프로세스를 안정적으로 유지합니다. 자동화는 개발과 배포를 더 효율적으로 만들어 이러한 목표를 뒷받침합니다.

팁: DevOps 파이프라인을 직접 소유하면 변화에 빠르게 대응하고 소프트웨어 개발을 궤도에서 벗어나지 않게 유지할 수 있습니다.

현명한 DevOps 도구 선택을 위해서는 배포 소유권을 이해해야 합니다. 이를 통해 배포 속도를 높이고, 코드를 보호하며, 개발 프로세스에 대한 통제력을 유지할 수 있습니다.

GitHub 소유권 모델

코드 및 아티팩트 저장소

GitHub는 소스 코드 관리를 위한 중앙 저장소로 사용할 수 있습니다. github.com에 코드를 푸시하면 모든 변경 사항의 이력이 명확하게 남습니다. 이를 통해 누가 언제 업데이트했는지 추적할 수 있습니다. 필요에 따라 코드를 공개 또는 비공개 리포지토리에 저장할 수 있습니다. GitHub Enterprise를 사용하면 고급 보안 및 규정 준수 도구처럼 대규모 조직을 위한 추가 기능을 이용할 수 있습니다.

배포 아티팩트의 경우 GitHub는 GitHub Packages를 제공합니다. 이 서비스를 사용하면 빌드 결과물, 컨테이너 이미지, 그 밖의 파일을 코드와 함께 저장할 수 있습니다. 워크플로에서 이러한 아티팩트에 직접 액세스할 수 있습니다. 다만 GitHub Packages는 생성 날짜와 다운로드 횟수 같은 기본 메타데이터만 제공합니다. 사용자 지정 속성을 추가하거나 아티팩트 관리를 위한 고급 쿼리를 사용할 수는 없습니다. JFrog 같은 다른 플랫폼은 메타데이터와 쿼리 측면에서 더 많은 옵션을 제공합니다.

간단한 비교는 다음과 같습니다.

GitHub는 소스 코드 관리와 기본적인 아티팩트 저장에 적합합니다. 보다 고급 아티팩트 관리가 필요하다면 다른 도구를 사용하거나 외부 서비스와 통합해야 할 수 있습니다.

액세스 및 권한

github.com에서 누가 코드를 보고 변경할 수 있는지는 사용자가 직접 관리합니다. 사용자와 팀에 역할을 할당하여 각 사용자가 필요한 액세스 권한만 갖도록 합니다. 이는 최소 권한 원칙을 따르는 방식입니다. 조직 내에서 팀을 만들고 팀마다 다른 권한을 설정할 수 있습니다. 예를 들어 개발자에게는 쓰기 권한을 주고, 관리자 권한은 신뢰할 수 있는 구성원에게만 제한할 수 있습니다.

GitHub를 ID 및 액세스 관리(IAM) 시스템과 연결하여 액세스 관리를 자동화할 수 있습니다. 이렇게 하면 팀 구성이 바뀔 때 사용자를 쉽게 추가하거나 제거할 수 있습니다. 또한 명확한 액세스 제어 정책을 설정하고 자주 검토하는 것이 좋습니다. GitHub에서는 감사 로그를 확인하여 비정상적인 활동을 찾아낼 수 있습니다.

• 리포지토리, 조직 또는 엔터프라이즈 수준에서 역할 및 권한을 할당합니다.
• 중요한 코드 변경에는 코드 소유자를 지정해 검토를 필수로 합니다.
• 관리자 액세스를 제한하고 꼭 필요할 때만 사용합니다.
• 승인되지 않은 작업이 있는지 감사 로그를 정기적으로 확인합니다.

GitHub Enterprise를 사용하면 대규모로 액세스를 관리하는 옵션이 더 늘어납니다. 여러 리포지토리에 걸쳐 정책을 설정하고 사용자 프로비저닝을 자동화할 수 있습니다.

거버넌스 및 규정 준수

배포를 안전하고 규정을 준수하는 상태로 유지하려면 강력한 거버넌스가 필요합니다. GitHub에는 이를 관리할 수 있는 여러 도구가 있습니다. 워크플로를 여러 프로젝트에서 재사용할 수 있어 시간을 절약하고 일관성을 확보할 수 있습니다. GitHub Actions를 사용하면 배포를 자동화하고 환경별 규칙을 적용할 수 있습니다.

아티팩트 증명(attestation)을 사용하면 배포 파일이 변경되지 않았는지 확인할 수 있습니다. GitHub는 클라우드 플랫폼에 안전하게 배포하기 위한 OpenID Connect(OIDC)를 지원합니다. 누가 언제 배포할 수 있는지 규칙을 설정하여 배포를 제어할 수 있습니다. GitHub에서는 배포 기록도 확인할 수 있어 감사 및 규정 준수 점검에 도움이 됩니다.

역할을 기준으로 권한을 부여하고, 관리자 액세스를 꼭 필요한 사용자로 제한할 수 있습니다. 민감한 코드에는 CODEOWNERS 파일을 사용해 검토를 필수로 지정하는 것이 좋습니다. 이러한 기능을 통해 거버넌스를 적용하고 배포 프로세스를 안전하게 유지할 수 있습니다.

참고: GitHub Actions는 Microsoft Fabric과 통합되므로, 동일한 거버넌스 컨트롤을 적용하면서 배포를 자동화하고 분석 솔루션을 관리할 수 있습니다.

보안 고려 사항

GitHub를 배포 파이프라인에 사용할 때는 보안에 각별히 주의해야 합니다. 보안 위협은 워크플로 곳곳에서 나타날 수 있습니다. 공격자는 소스 코드나 빌드 아티팩트에 악성코드를 주입하려고 시도할 수 있습니다. 모범 사례를 따르지 않으면 액세스 키나 암호 같은 민감한 데이터가 노출될 수 있습니다. 무단 액세스는 공격자가 파이프라인과 운영 환경을 장악하는 결과로 이어질 수 있습니다. 오래된 종속성은 전체 시스템을 위협하는 취약점을 유발할 수 있습니다.

GitHub 배포 파이프라인에 영향을 미치는 주요 보안 위협을 검토해야 합니다. 아래 표는 각 위험과 그에 따른 영향을 보여 줍니다.

강력한 액세스 제어를 적용하여 GitHub 저장소를 보호해야 합니다. 모든 사용자에 대해 2단계 인증을 사용하도록 설정하는 것이 좋습니다. 비밀 관리 기능을 사용하면 자격 증명과 토큰을 안전하게 보관할 수 있습니다. 민감한 정보를 코드에 직접 저장하지 않도록 해야 합니다. 권한을 자주 검토하고, 더 이상 필요하지 않은 사용자의 액세스 권한은 제거해야 합니다.

GitHub Actions를 사용하여 보안 작업을 자동화할 수 있습니다. 변경 내용을 푸시할 때마다 코드 분석과 취약점 검사를 실행하는 워크플로를 설정할 수 있습니다. 이러한 자동 검사를 통해 문제를 조기에 발견하고 운영 환경에 반영되기 전에 수정할 수 있습니다. 또한 GitHub Actions로 브랜치 보호 규칙을 적용하고 중요한 변경에 대해 검토를 필수로 지정할 수 있습니다.

종속성을 항상 최신 상태로 유지해야 합니다. GitHub의 Dependabot을 사용하면 프로젝트를 모니터링하고, 종속성에 알려진 취약점이 있을 때 알림을 받을 수 있습니다. 파이프라인 구성을 테스트하여 시스템이 위험에 노출되지 않는지 확인하는 것이 좋습니다. 이상 활동을 발견하려면 로그와 감사 추적을 정기적으로 검토해야 합니다.

팁: GitHub의 기본 제공 도구와 외부 솔루션을 함께 사용하면 보안 상태를 개선할 수 있습니다. 추가 보호가 필요하다면 타사 스캐너를 사용하거나 클라우드 보안 플랫폼과 통합할 수 있습니다.

보안은 지속적인 프로세스로 다루어야 합니다. 팀원들에게 안전한 방법을 교육하고 정기적인 검토를 장려해야 합니다. GitHub의 기능으로 많은 보안 작업을 자동화할 수 있지만, 항상 경계를 늦추지 않고 선제적으로 대응해야 합니다. 강력한 보안은 코드, 데이터, 그리고 평판을 보호하는 데 도움이 됩니다.

저장소로 GitHub 시작하기 - 체크리스트

GitHub를 코드 저장소로 사용하기 시작할 때 참고할 수 있는 실용적인 체크리스트입니다.

• GitHub 계정을 만들거나 로그인합니다.
• 팀 소유권을 위해 개인 계정과 조직 중 무엇을 사용할지 결정합니다.
• 새 저장소를 만들고(공개 또는 비공개) 적절한 공개 범위를 선택합니다.
• 명확한 저장소 이름과 설명이 담긴 README.md를 추가합니다.
• 프로젝트 요구 사항에 맞는 LICENSE 파일을 추가합니다.
• 사용 중인 언어나 프레임워크에 맞는 .gitignore를 추가합니다.
• 기본 브랜치(main)로 저장소를 초기화하고 브랜치 보호 규칙을 설정합니다.
• CODEOWNERS와 기여 가이드라인(CONTRIBUTING.md)을 구성합니다.
• 이슈 템플릿과 풀 요청 템플릿을 설정합니다.
• 이슈 추적을 위해 레이블, 마일스톤, 프로젝트 보드를 구성합니다.
• CI/CD용 GitHub Actions 워크플로를 설정하거나 기존 파이프라인과 통합합니다.
• CI, 배포, 타사 서비스에 사용할 저장소 비밀을 추가합니다.
• 필요한 경우 필수 검토, 상태 검사, 필수 서명 커밋 등 브랜치 보호 규칙을 구성합니다.
• 종속성 업데이트와 보안 알림을 위해 Dependabot을 사용하도록 설정합니다.
• 보안 기능인 코드 검사, 비밀 검사, 취약점 알림을 사용하도록 설정합니다.
• CI, 챗옵스(ChatOps), 외부 서비스와 연동하도록 웹후크(webhook) 또는 통합을 설정합니다
• 공동 작업자나 팀원을 초대하고 리포지토리 권한을 설정합니다
• 기존 리포지토리와 이슈를 마이그레이션합니다(Azure DevOps에서 이전하는 경우 마이그레이션을 계획하고 작업 항목을 매핑합니다)
• 위키 또는 docs 폴더에 리포지토리 구조, 개발 워크플로, 릴리스 프로세스를 문서화합니다
• 릴리스, 배포, 주요 워크플로에 대한 모니터링과 알림을 구성합니다
• 워크플로와 대안(GitHub 대 Azure DevOps)을 검토 및 비교하여 CI/CD와 프로젝트 관리 선택을 최적화합니다
• 리포지토리 액세스, 비밀(secret), 보안 설정을 정기적으로 감사합니다

Azure DevOps 소유권 모델

리포지토리와 파이프라인

Azure DevOps를 사용하면 코드, 아티팩트, 배포 프로세스를 관리할 수 있는 통합 플랫폼을 얻게 됩니다. Azure DevOps 서비스는 코드 리포지토리, 작업 추적, 테스트 도구와 아티팩트 스토리지를 하나로 묶어 줍니다. 이러한 통합을 통해 소프트웨어 제공 수명 주기의 모든 단계를 제어할 수 있습니다. 각 파이프라인 실행을 특정 커밋, 풀 리퀘스트 또는 작업 항목까지 추적할 수 있어 개발 프로세스를 명확하게 파악할 수 있습니다.

Azure DevOps 파이프라인은 리소스에 접근할 때 ID를 사용합니다. 이러한 ID는 컬렉션 수준 또는 프로젝트 수준에서 설정할 수 있습니다. 프로젝트 수준 ID를 사용하면 각 프로젝트에 필요한 리소스에만 액세스를 제한할 수 있어 보안이 강화됩니다. 또한 검사(check)와 파이프라인 권한을 사용하여 리포지토리 리소스를 보호할 수 있습니다. 이를 통해 코드와 배포 워크플로에 대한 소유권과 편집 권한을 관리할 수 있습니다.

Azure DevOps는 간소화된 CI/CD를 지원하므로 빌드, 테스트, 배포를 자동화할 수 있습니다. Azure Pipelines를 사용하면 지속적 통합과 지속적 제공을 구현할 수 있어 업데이트를 빠르고 안정적으로 제공하는 데 도움이 됩니다. Microsoft는 Azure DevOps가 클라우드 컴퓨팅과 잘 작동하도록 설계했으며, 필요에 따라 프로젝트 규모를 쉽게 확장할 수 있습니다.

액세스 제어

역할 기반 액세스 제어를 사용하여 Azure DevOps 서비스에 접근할 수 있는 사용자를 관리합니다. 이 모델을 사용하면 역할에 따라 권한을 할당하므로 각 사용자는 필요한 액세스 권한만 갖게 됩니다. 사용자를 보안 그룹으로 구성하고 조직, 프로젝트 또는 개체 수준에서 권한을 할당할 수 있습니다. Microsoft는 최소 권한 원칙을 따를 것을 권장합니다. 즉, 사용자에게 작업에 필요한 권한만 부여해야 합니다.

• 정확한 액세스 제어를 위해 사용자와 그룹에 역할을 할당합니다.
• 보안 그룹을 사용하여 여러 수준에서 권한을 관리합니다.
• 예기치 않은 사용을 발견하기 위해 권한을 정기적으로 검토하고 감사합니다.

Azure DevOps를 사용하면 팀 구성이 바뀔 때마다 액세스를 쉽게 모니터링하고 조정할 수 있습니다. 각 리포지토리와 파이프라인에 누가 액세스할 수 있는지 추적할 수 있으므로 DevOps 환경을 계속 통제할 수 있습니다.

거버넌스와 정책

안전하고 안정적인 배포를 위해서는 강력한 거버넌스가 필수적입니다. Azure DevOps는 브랜치 정책, 액세스 제어, 사용자 지정 역할을 통해 거버넌스를 적용합니다. 브랜치 정책을 사용하면 코드를 병합하기 전에 검사와 요구 사항을 설정할 수 있으므로 품질이 검증된 코드만 프로덕션에 반영됩니다. 최소 권한 원칙에 따라 보안 주체를 역할에 할당하면 무단 액세스의 위험을 줄일 수 있습니다.

• 병합 전에 코드 검토와 검사를 요구하도록 브랜치 정책을 설정합니다.
• 프로덕션에서 파괴적인 작업을 방지하기 위해 서비스 주체에 사용자 지정 역할을 할당합니다.
• 중요한 환경에 배포할 수 있는 사용자를 제한하도록 액세스 제어를 사용합니다.

Microsoft는 Azure DevOps를 엔터프라이즈 거버넌스를 지원하도록 설계했습니다. Azure DevOps를 GitHub, Microsoft Fabric 같은 다른 Microsoft 도구와 통합하면 끊김 없는 DevOps 워크플로를 구성할 수 있습니다. 이러한 통합은 배포를 관리하고, 정책을 적용하며, 조직 전체의 규정 준수를 유지하는 데 도움이 됩니다.

팁: 배포를 안전하고 규정을 준수하는 상태로 유지하려면 Azure DevOps의 거버넌스 설정을 정기적으로 검토하세요.

보안 및 규정 준수

배포를 관리할 때는 강력한 보안 및 규정 준수 통제가 필요합니다. Azure DevOps는 코드, 데이터, 워크플로를 보호하는 데 사용할 수 있는 다양한 도구를 제공합니다. 기본 제공 보안 기능을 활용하면 개발 프로세스를 안전하게 유지하고 업계 표준을 준수할 수 있습니다.

Azure DevOps는 역할 기반 액세스 제어를 사용하여 리소스를 보거나 변경할 수 있는 사용자를 제한합니다. 사용자와 그룹에 권한을 할당하여 올바른 사람만 액세스할 수 있도록 합니다. 서비스 연결을 사용하면 파이프라인이 다른 Azure 서비스와 상호 작용하는 방식을 제어할 수도 있습니다. 이를 통해 승인되지 않은 작업의 위험을 줄일 수 있습니다.

Azure DevOps에서 분기 정책을 설정하면 변경 사항을 병합하기 전에 코드 검토와 검사를 요구할 수 있습니다. 이러한 정책은 문제를 조기에 발견하고 코드베이스를 안전하게 유지하는 데 도움이 됩니다. 파이프라인에 승인 게이트를 사용하면 테스트를 거쳐 승인된 코드만 프로덕션에 도달하도록 할 수 있습니다. 이 과정은 모든 단계에서 규칙을 적용하여 규정 준수를 뒷받침합니다.

Azure DevOps는 상세한 감사 로그를 제공합니다. 프로젝트에서 수행되는 모든 작업을 추적할 수 있습니다. 이를 통해 변경 사항을 쉽게 검토하고 비정상적인 활동을 찾아낼 수 있습니다. 이러한 로그는 규정 준수 감사를 지원하고 규제 요구 사항을 충족하는 데 활용할 수 있습니다.

Azure DevOps에 비밀과 자격 증명을 안전하게 저장할 수 있습니다. 이 플랫폼은 민감한 정보를 위해 보안 저장소를 사용합니다. 코드에 노출하지 않고 비밀을 파이프라인에 연결할 수 있습니다. 이를 통해 암호, 토큰, 키가 유출되지 않도록 보호할 수 있습니다.

Azure DevOps는 Azure 보안 도구와의 통합을 지원합니다. Microsoft Defender for Cloud를 사용하여 코드와 리소스에서 위협을 검사할 수 있습니다. 또한 Azure Policy에 연결하여 환경 전체에 규정 준수 규칙을 적용할 수 있습니다. 이러한 통합은 강력한 보안 태세를 구축하는 데 도움이 됩니다.

파이프라인에서 보안 검사를 자동화할 수 있습니다. 취약점을 검사하거나 규정 준수 문제를 확인하는 작업을 추가할 수 있습니다. 이러한 자동화는 문제가 프로덕션에 도달하기 전에 찾아 해결하는 데 도움이 됩니다. 또한 지속적 통합을 사용하면 코드를 푸시할 때마다 이러한 검사를 실행할 수 있습니다.

Azure DevOps를 믿고 보안 및 규정 준수를 관리할 수 있습니다. 코드를 보호하고, 액세스를 제어하고, 업계 표준을 충족하는 데 필요한 도구를 갖추게 됩니다. 배포를 안전하게 유지하면서 훌륭한 소프트웨어를 만드는 데 집중할 수 있습니다.

Azure DevOps를 리포지토리로 시작하기 — 체크리스트

• Azure DevOps 조직을 만들거나 해당 조직에 로그인합니다
• 새 프로젝트를 만들고(공개 범위: 비공개/공개 선택) 버전 관리로 Git을 선택합니다
• 첫 리포지토리를 만들거나 기존 리포지토리를 가져옵니다(GitHub 또는 로컬에서)
• 설명이 포함된 README.md와 라이선스 파일을 추가합니다
• 프로젝트의 언어 및 프레임워크에 맞는 .gitignore를 추가합니다
• 브랜치 전략과 명명 규칙(main, develop, feature/*, hotfix/*)을 정의합니다
• main 브랜치를 보호합니다. 분기 정책, 필수 검토자, 상태 검사를 사용하도록 설정합니다
• 풀 요청 템플릿과 기여자 가이드라인을 만듭니다
• 리포지토리 권한과 그룹(Readers, Contributors, Project Administrators)을 구성합니다
• 배포용 서비스 연결을 설정합니다(Azure, AWS, Docker 레지스트리, 외부 Git 공급자)
• CI 파이프라인(Azure Pipelines YAML 또는 클래식)을 만들고 PR에서 빌드를 검증합니다
• 환경(dev/stage/prod)별 CD 파이프라인 또는 릴리스 파이프라인과 승인 게이트를 만듭니다
• Boards와 통합합니다. 작업 항목을 만들고 커밋과 PR을 작업 항목에 연결합니다
• 외부 통합(Slack, Teams, Jenkins)을 위해 웹후크 또는 서비스 후크를 구성합니다
• 리포지토리 브랜치 보존 및 빌드 보존 정책을 구성합니다
• 감사를 사용하도록 설정하고 필요한 규정 준수/보안 통제를 구성합니다
• 코드 검사, 보안 분석, 종속성 검사를 설정합니다(GitHub에서 추가 도구를 제공할 수 있으니 필요에 맞게 비교해 보세요)
• 패키지 호스팅(NuGet, npm, Maven)이 필요하면 아티팩트 피드를 설정합니다
• Wiki 또는 문서 사이트를 만들고, 적절한 경우 문서를 리포지토리에 보관합니다
• GitHub에서 이전하는 경우 마이그레이션 단계를 계획합니다. 리포지토리, 이슈, PR, CI/CD, 서비스 계정을 매핑합니다
• 팀원을 초대하고 각자의 계정에서 액세스가 올바른지 확인합니다
• 첫 번째 엔드 투 엔드 테스트를 실행합니다. 저장소를 클론하고, 커밋하고, 푸시한 다음, PR을 열고, 파이프라인을 실행해 테스트 환경에 배포합니다.
• 사용량과 파이프라인을 모니터링하고, 정책과 자동화를 반복적으로 개선합니다.

Microsoft Fabric 통합

Git 통합

Microsoft Fabric 작업 영역을 GitHub 저장소에 직접 연결할 수 있습니다. 이 연결을 사용하면 분석 프로젝트에 강력한 버전 관리를 적용할 수 있습니다. 작업 영역을 GitHub의 develop 브랜치에 연결합니다. 이렇게 설정하면 모든 변경 사항을 추적하고 필요할 때 되돌릴 수 있습니다. Microsoft Fabric의 배포 파이프라인을 사용하면 콘텐츠를 개발 환경에서 테스트 환경으로, 그다음 프로덕션 환경으로 옮길 수 있습니다. 이 과정을 통해 환경 간 동기화 문제를 피할 수 있습니다.

안정적인 기능을 출시하려면 릴리스 브랜치를 만듭니다. 배포 파이프라인을 사용해 이러한 변경 사항을 프로덕션에 반영합니다. 긴급한 문제를 수정해야 하면 핫픽스 브랜치를 만듭니다. 이 브랜치를 기본 브랜치에 병합한 후 배포합니다. 환경마다 별도의 데이터베이스를 사용하는 것이 좋습니다. 이렇게 하면 테스트나 개발 중에 발생할 수 있는 실수로부터 프로덕션 데이터를 보호할 수 있습니다.

Azure DevOps 및 GitHub를 사용한 CI/CD

Azure DevOps 또는 GitHub Actions를 사용해 Microsoft Fabric에 CI/CD 파이프라인을 구성할 수 있습니다. 이러한 도구를 사용하면 빌드, 테스트, 배포 단계를 자동화할 수 있습니다. 배포 파이프라인에는 명확하고 설명이 잘 된 이름을 붙이는 것이 좋습니다. 그래야 각 파이프라인의 용도를 쉽게 파악할 수 있습니다. 개발, 테스트, 프로덕션 등 파이프라인 단계마다 기존 작업 영역을 사용하거나 새 작업 영역을 만들 수 있습니다.

단계 간 콘텐츠를 자주 비교하는 것이 좋습니다. 이 확인을 통해 모든 항목이 올바르게 배포되었는지 검증할 수 있습니다. 파이프라인의 모든 작업 영역에서 앱을 게시할 수 있습니다. 이 단계를 거치면 최종 배포 전에 최종 사용자가 기능을 테스트할 수 있습니다. 개발자나 기능별로 별도의 브랜치를 유지하는 것이 좋습니다. 이렇게 하면 병합 충돌을 피하는 데 도움이 됩니다. Gitflow와 같은 강력한 브랜치 전략을 사용하면 개발, 릴리스, 핫픽스를 효과적으로 관리할 수 있습니다.

변경 사항을 병합하기 전에 코드 검토를 필수로 적용해야 합니다. 이 규칙을 통해 다른 팀원이 업데이트를 확인하고 승인할 수 있습니다. Microsoft Fabric에서는 변경 사항을 배포하기 전에 원본 작업 영역과 대상 작업 영역의 콘텐츠를 비교할 수 있습니다. 이 기능은 실수를 조기에 발견하고 환경의 일관성을 유지하는 데 도움이 됩니다.

데이터 거버넌스

Microsoft Fabric은 데이터 수명 주기의 모든 단계에 거버넌스를 내장합니다. 하나의 환경에서 데이터 수집, 저장, 분석을 함께 관리할 수 있습니다. Microsoft Purview가 데이터를 카탈로그화하고 계보를 추적합니다. OneLake는 중앙 집중식 스토리지를 제공하므로 거버넌스 정책을 손쉽게 적용할 수 있습니다. Microsoft Entra ID는 역할 기반 액세스 제어를 제공하므로 누가 데이터를 보고 변경할 수 있는지 직접 결정할 수 있습니다.

거버넌스 정책은 OneLake 수준에서 적용합니다. 이러한 규칙은 작업 영역과 데이터 세트 전반에서 데이터를 따라갑니다. 이 방식은 데이터 처리의 일관성과 속도를 유지하는 데 도움이 됩니다. 작업 영역마다 별도의 규칙을 설정할 필요가 없습니다. Microsoft Fabric의 설계는 데이터가 늘어나도 제어 수준을 유지하고 규정 준수 요구 사항을 충족하는 데 도움이 됩니다.

보안 및 규정 준수

Microsoft Fabric에서 데이터와 배포를 관리할 때는 강력한 보안 및 규정 준수 통제가 필요합니다. 이 플랫폼은 정보를 보호하고 규제 요구 사항을 충족하기 위한 고급 도구를 제공합니다. Data Factory 파이프라인에서 민감한 데이터를 분류하고 보호할 수 있습니다. 이를 통해 중요한 정보가 권한 없이 접근되는 것을 막을 수 있습니다.

Microsoft Fabric은 Microsoft Defender for Cloud Apps와 연동됩니다. 이 통합을 통해 운영 현황을 더 명확하게 파악하고 제어할 수 있습니다. 활동을 모니터링하고 위험한 동작에 대한 알림을 설정할 수 있습니다. 데이터 계보(data lineage)도 추적할 수 있습니다. 이 기능을 사용하면 데이터가 시스템 내에서 어떻게 이동하는지 확인할 수 있습니다. 이 정보를 활용해 규정 준수를 검증하고 민감한 데이터의 흐름을 파악할 수 있습니다.

Microsoft Fabric에서 데이터 손실 방지(DLP) 정책을 설정할 수 있습니다. 이 정책은 민감한 정보가 승인되지 않은 상태로 공유되는 것을 막는 데 도움이 됩니다. 조직의 요구에 맞게 사용자 지정 규칙을 만들 수 있습니다. 예를 들어 사용자가 기밀 데이터를 회사 외부로 보내지 못하도록 차단할 수 있습니다. 보호된 정보를 공유하려는 시도가 발생하면 알림을 받을 수도 있습니다.

Microsoft Fabric은 데이터 현지화를 지원합니다. Multi-Geo 기능을 사용하면 데이터를 저장할 위치를 선택할 수 있습니다. 이를 통해 국가별 데이터 거주 법규를 준수할 수 있습니다. 현지 규정을 충족하도록 특정 지역에 데이터를 보관할 수 있습니다. 이 기능은 여러 지역에서 사업을 운영하는 조직에 특히 중요합니다.

Microsoft Fabric은 GDPR과 같은 법률에 따른 개인정보 보호 권리를 지원합니다. 플랫폼은 데이터 주체 요청(DSR)을 처리할 수 있는 도구를 제공합니다. Microsoft Purview를 사용해 특정 개인의 데이터를 검색할 수 있습니다. 이 데이터는 JSON 또는 CSV와 같은 형식으로 내보낼 수 있습니다. 오류가 발견되면 수정할 수 있습니다. 필요한 경우 사용자 ID를 삭제할 수도 있습니다. 이러한 단계를 통해 개인정보를 존중하고 법적 규정을 준수할 수 있습니다.

Microsoft Fabric의 개인정보 권리 관리 기능을 요약하면 다음과 같습니다.

1. 검색 및 탐색: Microsoft Purview로 데이터 주체 정보를 찾습니다.
2. 검색 결과 가져오기: 일반적인 형식으로 데이터를 내보냅니다.
3. 정정: 저장된 데이터의 오류를 수정합니다.
4. 삭제: 사용자 ID를 영구적으로 삭제합니다.

이러한 기능을 활용하면 안전하고 규정을 준수하는 데이터 플랫폼을 구축할 수 있습니다. Microsoft Fabric은 데이터를 보호하고, 액세스를 제어하며, 최신 규제의 요구 사항을 충족하는 데 도움이 됩니다. 배포 환경이 보안 및 규정 준수의 모범 사례를 따르고 있다는 점에서 안심할 수 있습니다.

팁: 보안 및 규정 준수 설정을 자주 검토하십시오. 정기적인 점검은 새로운 위험에 앞서 대응하고 데이터를 안전하게 유지하는 데 도움이 됩니다.

GitHub vs Azure DevOps vs Fabric: 소유권 비교

리포지토리 위치

코드가 어디에 저장되는지 알아야 합니다. GitHub vs Azure DevOps 논쟁에서 이 부분이 핵심입니다. GitHub는 리포지토리를 클라우드에 저장합니다. 공개 또는 비공개 옵션 중에서 선택할 수 있습니다. 많은 오픈 소스 프로젝트가 공유와 협업이 쉬운 GitHub를 사용합니다. Azure DevOps도 코드를 클라우드에 저장하지만, 비공개 엔터프라이즈급 프로젝트에 초점을 맞춥니다. 누가 코드를 보고 변경할 수 있는지에 대해 더 많은 제어권을 갖게 됩니다. Microsoft Fabric은 버전 관리를 위해 GitHub와 Azure DevOps 모두에 연결됩니다. Fabric에서 분석 프로젝트를 관리하지만, 실제 코드는 연결된 리포지토리에 있습니다.

간단한 비교는 다음과 같습니다.

필요에 맞는 플랫폼을 선택해야 합니다. 개방형 협업이 목표라면 GitHub가 적합합니다. 엄격한 제어가 필요하다면 Azure DevOps가 더 많은 옵션을 제공합니다. Microsoft Fabric에서는 둘 중 어느 것이든 사용할 수 있으므로 자신의 워크플로에 맞출 수 있습니다.

아티팩트 관리

아티팩트 관리는 프로젝트에서 생성하는 빌드 결과물, 패키지, 파일을 처리하는 방식입니다. GitHub vs Azure DevOps 비교에서는 큰 차이가 드러납니다. GitHub는 아티팩트 저장에 GitHub Packages를 사용합니다. 패키지 저장과 공유 같은 기본 기능을 제공합니다. Azure DevOps는 고급 제어 기능을 제공하는 Azure Artifacts를 제공합니다. 버전을 관리하고, 피드를 설정하고, 사용량을 추적할 수 있습니다. Microsoft Fabric은 Power BI 보고서와 시맨틱 모델 같은 분석 아티팩트에 초점을 맞춥니다. 버전 관리를 위해 리포지토리에 연결되며, 환경 간 아티팩트를 이동하는 데 배포 파이프라인을 사용합니다.

아티팩트 관리를 비교할 때 다음 사항을 살펴봐야 합니다.

• 인증: Azure DevOps는 Microsoft Entra 사용자 계정을 사용합니다. 덕분에 로그인이 간단하고 안전합니다. GitHub는 개인 액세스 토큰을 사용합니다. 특히 대규모 팀에서는 이 토큰을 관리하기가 더 까다로울 수 있습니다.
• 거버넌스: Azure DevOps에는 내장 거버넌스 기능이 있습니다. 규칙을 설정하고 변경 사항을 쉽게 추적할 수 있습니다. GitHub Enterprise는 표준 GitHub보다 나은 거버넌스를 제공하지만, 엔터프라이즈 요구 사항에서는 여전히 Azure DevOps가 앞서 있습니다.
• 통합: Microsoft Fabric은 아티팩트 관리를 위해 클라우드 기반 버전의 Azure DevOps와 GitHub만 지원합니다. Fabric을 사용한다면 클라우드 기반 워크플로를 준비해 두어야 합니다.

다음은 비교를 돕기 위한 표입니다.

강력한 아티팩트 관리와 거버넌스가 필요하다면 Azure DevOps를 선택하는 것이 좋습니다. 간단한 요구 사항이나 오픈 소스 프로젝트에는 GitHub가 适합니다. Microsoft Fabric은 분석 아티팩트를 통합적으로 관리할 수 있게 해 주지만, 저장은 연결된 리포지토리에 의존합니다.

액세스 및 권한

액세스와 권한은 누가 코드와 아티팩트를 보고, 편집하고, 배포할 수 있는지를 결정합니다. GitHub와 Azure DevOps를 비교하면 접근 방식이 서로 다르다는 것을 알 수 있습니다. GitHub에서는 리포지토리, 조직 또는 엔터프라이즈 수준에서 역할을 설정할 수 있습니다. 팀과 코드 소유자를 사용해 변경을 제어합니다. Azure DevOps는 역할 기반 액세스 제어(RBAC)를 사용합니다. 사용자를 보안 그룹에 할당하고, 프로젝트 또는 개체 수준에서 권한을 설정합니다. 이를 통해 세분화된 제어가 가능하며, 이는 대규모 조직에서 중요합니다.

Microsoft Fabric은 액세스 제어에 Microsoft Entra ID를 사용합니다. 분석 작업 영역에 대한 역할을 설정하고, 누가 분석 콘텐츠를 보고, 편집하고, 배포할 수 있는지 결정할 수 있습니다. Fabric을 GitHub 또는 Azure DevOps에 연결하면 코드와 아티팩트에는 해당 플랫폼의 액세스 제어가 적용됩니다. 즉, Microsoft의 강력한 ID 관리와 선택한 리포지토리의 유연한 제어를 함께 누릴 수 있습니다.

다음은 요약입니다.

• GitHub: 역할 및 팀, 코드 소유자, 감사 로그.
• Azure DevOps: 역할 기반 액세스, 보안 그룹, 프로젝트 수준 제어.
• Microsoft Fabric: Entra ID 역할, 작업 영역 권한, 연결된 리포지토리의 제어 상속.

액세스 설정을 자주 검토하세요. 올바른 사람에게만 권한이 있는지 확인해야 합니다. 이렇게 하면 프로젝트를 안전하게 보호하고 규정 준수도 지원할 수 있습니다.

팁: 최소 권한 원칙을 적용하세요. 사용자에게 필요한 액세스만 부여합니다. 이렇게 하면 위험이 줄고 보안을 유지하는 데 도움이 됩니다.

거버넌스 및 규정 준수

배포를 보호하고 업계 표준을 충족하려면 강력한 거버넌스 및 규정 준수 체계가 필요합니다. GitHub, Azure DevOps, Microsoft Fabric은 각각 이러한 요구를 충족하기 위해 서로 다른 도구와 접근 방식을 제공합니다.

GitHub는 유연한 거버넌스를 제공합니다. 브랜치 보호 규칙을 설정하고, 코드 리뷰를 필수로 지정하고, CODEOWNERS 파일을 사용할 수 있습니다. 이러한 기능으로 코드를 누가 변경할 수 있는지 제어할 수 있습니다. 감사 로그를 사용하면 리포지토리에서 수행된 작업을 추적할 수도 있습니다. 규정 준수를 위해 GitHub는 타사 도구와의 통합을 지원합니다. 정책 검사를 자동화하고 GitHub Actions로 규칙을 적용할 수 있습니다. GitHub Enterprise를 사용하면 SAML 单一 로그인과 전사 정책 관리 같은 고급 규정 준수 기능도 이용할 수 있습니다.

Azure DevOps는 엔터프라이즈 거버넌스에 중점을 둡니다. 브랜치 정책, 승인 게이트, 사용자 지정 역할을 설정할 수 있습니다. 이러한 제어를 통해 모든 프로젝트에 표준을 일관되게 적용할 수 있습니다. 작업 항목 추적을 사용하면 코드 변경을 비즈니스 요구 사항과 연결할 수 있습니다. 파이프라인에 규정 준수 검사를 설정할 수 있습니다. Azure DevOps는 감사 추적과 상세 로깅을 지원합니다. ISO, SOC, GDPR 같은 프레임워크에 대한 규정 준수를 보여 주는 보고서를 내보낼 수 있습니다. 또한 Azure DevOps는 Azure Policy 및 Microsoft Purview와 통합되어 통합 거버넌스를 제공합니다.

Microsoft Fabric은 데이터 분석 워크플로에 거버넌스를 더해 줍니다. Microsoft Purview로 데이터를 카탈로그화하고 계보를 추적할 수 있습니다. OneLake 수준에서 정책을 설정하면 모든 작업 영역에 적용됩니다. 이처럼 통합된 접근 방식 덕분에 데이터가 늘어나도 규정 준수를 쉽게 관리할 수 있습니다. Microsoft Fabric은 Microsoft Entra ID를 활용한 역할 기반 액세스를 지원합니다. 데이터 액세스와 배포에 대한 규칙을 설정할 수 있습니다. 또한 GDPR과 같은 개인정보 보호 법규를 위한 기본 제공 규정 준수 도구도 사용할 수 있습니다. 필요에 따라 사용자 데이터를 검색, 내보내기, 삭제할 수 있습니다.

거버넌스 및 규정 준수 기능을 비교하는 데 도움이 되도록 표를 준비했습니다.

팁: 거버넌스 설정을 자주 검토하십시오. 강력한 거버넌스는 규정 준수 요건을 충족하고 배포를 안전하게 유지하는 데 도움이 됩니다.

보안 상태

코드, 데이터, 배포를 위협으로부터 보호해야 합니다. 플랫폼마다 제공하는 보안 기능과 제어 수단이 다릅니다.

GitHub은 2단계 인증, 비밀 관리, 브랜치 보호로 리포지토리를 보호하는 데 도움이 됩니다. GitHub Actions를 사용하면 보안 검사와 취약점 점검을 자동화할 수 있습니다. Dependabot은 오래된 종속성이 있을 때 알려 줍니다. 감사 로그를 검토하여 비정상적인 활동을 찾아낼 수 있습니다. 클라우드 배포의 경우 GitHub은 안전한 인증을 위해 OpenID Connect를 지원합니다. 코드와 아티팩트를 안전하게 유지하려면 이러한 도구를 활용해야 합니다.

Azure DevOps는 고급 보안 제어 기능을 제공합니다. 역할 기반 액세스를 사용해 권한을 제한할 수 있습니다. Azure DevOps는 비밀을 안전하게 저장하고 이를 파이프라인에 연결합니다. 승인 게이트를 설정해 위험한 배포를 차단할 수 있습니다. Azure DevOps는 Microsoft Defender for Cloud와 통합되어 위협을 검사합니다. Azure Policy를 사용하면 환경 전체에 보안 규칙을 적용할 수 있습니다. 상세한 감사 로그를 통해 모든 작업을 추적할 수 있습니다. 파이프라인에서 보안 검사를 자동화하면 문제를 조기에 발견할 수 있습니다. Azure DevOps는 업계 표준 준수를 지원하며 보안 보고서를 내보내는 도구도 제공합니다.

Microsoft Fabric은 데이터 보안에 중점을 둡니다. Microsoft Defender for Cloud Apps를 사용해 활동을 모니터링하고 위험한 동작에 대한 알림을 설정할 수 있습니다. 파이프라인의 민감한 데이터를 분류하고 보호할 수 있습니다. Microsoft Fabric은 DLP(Data Loss Prevention) 정책을 지원합니다. 승인되지 않은 기밀 정보 공유를 차단할 수 있습니다. 또한 Multi-Geo로 데이터 현지화를 지원하므로 데이터를 저장할 위치를 선택할 수 있습니다. Microsoft Fabric은 개인정보 권리를 관리하고 정보 주체 요청(Data Subject Request)을 처리하는 데 도움이 됩니다. 법적 요건을 충족하기 위해 사용자 데이터를 검색, 내보내기, 삭제할 수 있습니다.

보안 기능 요약은 다음과 같습니다.

• GitHub: 2단계 인증, 비밀 관리, 자동 검사, 감사 로그
• Azure DevOps: 역할 기반 액세스, 안전한 비밀, 승인 게이트, Defender for Cloud, 정책 적용, 감사 추적
• Microsoft Fabric: Defender for Cloud Apps, DLP 정책, 데이터 분류, Multi-Geo, 개인정보 관리

참고: 플랫폼의 보안 기능을 모범 사례와 함께 사용해야 합니다. 팀을 교육하고, 설정을 검토하며, 위협이 변화함에 따라 정책을 업데이트하십시오.

적합한 도구를 사용하고 선제적으로 대응할 때 가장 강력한 보안 상태를 확보할 수 있습니다. GitHub, Azure DevOps, Microsoft Fabric 각각은 배포와 데이터를 보호하는 데 필요한 제어 수단을 제공합니다.

실제 DevOps 시나리오

GitHub를 활용한 오픈 소스

오픈 소스 프로젝트를 진행할 때 GitHub을 사용하면 배포 소유권을 간단하게 관리할 수 있습니다. 배포 프로세스를 자동화하고 코드가 변경될 때마다 프로젝트를 계속 운영 상태로 유지할 수 있습니다. 다음은 GitHub를 사용하는 일반적인 오픈 소스 DevOps 워크플로에서 소유권이 작동하는 방식입니다.

• 공개 GitHub 리포지토리에 코드를 푸시합니다.
• 기본 브랜치에 푸시할 때마다 자동 배포가 실행됩니다.
• 배포를 위해 별도로 적용하거나 승인을 기다릴 필요가 없습니다.
• 자체 AWS 계정이나 이와 유사한 서비스를 사용하여 클라우드 인프라에 대한 통제권을 유지합니다.
• 프로젝트는 항상 운영 수준의 인프라에서 계속 운영됩니다.

이 접근 방식을 사용하면 프로젝트의 구축과 개선에 집중할 수 있습니다. 수동 승인이나 지연을 걱정할 필요가 없습니다. 코드를 외부에 공개하더라도 배포 프로세스와 인프라는 여전히 직접 소유하고 관리합니다. GitHub에서는 GitHub Actions 같은 DevOps 도구를 사용해 테스트와 배포 단계를 자동화할 수도 있습니다.

Azure DevOps를 활용한 엔터프라이즈 환경

엔터프라이즈 환경에서는 복잡한 프로젝트를 관리하기 위해 Azure DevOps를 자주 사용합니다. 이때 속도, 보안, 규정 준수의 균형을 맞춰야 합니다. 이런 환경에서는 소유권이 까다로워질 수 있습니다. 아래 표는 직면할 수 있는 몇 가지 일반적인 과제를 보여 줍니다.

팀의 역할과 책임을 명확히 정해야 합니다. Azure DevOps에서는 권한을 할당하고 역할 기반 액세스 제어를 사용하여 이를 지원합니다. 모든 변경 사항을 추적하고 회사의 기준에 맞게 정책을 적용할 수 있습니다. Microsoft는 보안과 규정 준수를 위한 기본 제공 도구를 제공하므로 코드와 데이터를 보호할 수 있습니다. 또한 Azure DevOps를 다른 Microsoft 서비스와 통합해 일관된 DevOps 환경을 구성할 수도 있습니다.

Fabric으로 하는 데이터 분석

데이터 분석 프로젝트를 관리할 때 Microsoft Fabric은 강력한 배포 소유권을 제공합니다. 작업 영역의 각 항목을 누가 배포하고, 편집하고, 볼 수 있는지 제어할 수 있습니다. 아래 표는 Microsoft Fabric에서 항목별로 소유권이 어떻게 적용되는지 보여 줍니다.

분석 자산을 명확하게 제어할 수 있습니다. 새 항목을 배포하면 해당 항목의 소유자가 됩니다. 항목이 이미 존재하는 단계에 배포하면 소유권은 그대로 유지됩니다. Microsoft Fabric은 작업 영역 역할과 권한을 사용해 액세스를 관리하도록 도와줍니다. 버전 관리와 자동 배포를 위해 작업 영역을 GitHub나 Azure DevOps에 연결할 수 있습니다. 이 통합을 통해 데이터 분석 프로젝트에 일관된 DevOps 워크플로를 적용할 수 있습니다.

팁: Microsoft Fabric의 배포 파이프라인과 작업 영역 권한을 사용하면 데이터를 안전하게 보호하고 팀의 생산성을 유지할 수 있습니다.

하이브리드 배포

배포를 관리하는 데 여러 플랫폼을 함께 사용해야 하는 경우가 많습니다. 대규모 조직이거나 서로 다른 도구의 강점을 결합하려는 경우에 흔히 발생합니다. 하이브리드 배포에서는 소스 제어에 GitHub, 파이프라인에 Azure DevOps, 분석에 Microsoft Fabric을 사용할 수 있습니다. 이러한 플랫폼을 연결하면 필요에 맞는 워크플로를 만들 수 있습니다.

먼저 GitHub에 코드를 저장하는 것으로 시작할 수 있습니다. GitHub Actions를 사용해 테스트를 실행하고 애플리케이션을 빌드할 수 있습니다. 그다음 빌드 아티팩트를 Azure DevOps로 보낼 수 있습니다. Azure DevOps는 고급 파이프라인 제어와 아티팩트 관리 기능을 제공합니다. 승인 게이트를 설정하고 역할 기반 액세스를 사용해 프로덕션 배포 권한을 관리할 수 있습니다. 데이터 분석 작업이 필요하면 Microsoft Fabric을 리포지토리에 연결할 수 있습니다. 이렇게 하면 강력한 거버넌스 아래에서 분석 자산과 배포를 관리할 수 있습니다.

하이브리드 배포는 유연성을 제공합니다. 워크플로의 각 부분에 가장 적합한 도구를 선택할 수 있습니다. 팀이 성장하면 운영 규모도 확장할 수 있습니다. 다만 소유권은 신중하게 관리해야 합니다. 플랫폼마다 액세스, 거버넌스, 보안에 대한 고유한 규칙이 있으므로 이 규칙들이 함께 작동하도록 해야 합니다.

하이브리드 환경에서 배포 소유권을 관리하기 위한 모범 사례는 다음과 같습니다:

가능한 한 많은 작업을 자동화해야 합니다. 자동화는 실수를 줄이고 배포 속도를 높입니다. 또한 효과적인 배포 전략을 활용해야 합니다. 블루-그린 및 카나리 배포를 사용하면 모든 사용자에게 영향을 주지 않고 새 버전을 테스트할 수 있습니다. 이를 통해 문제를 조기에 발견할 수 있습니다.

여러 플랫폼에서 작동하는 관리 도구를 사용해야 합니다. 이러한 도구는 배포 현황을 추적하고 모든 팀이 동일한 규칙을 따르도록 하는 데 도움이 됩니다. 파이프라인을 모니터링하는 대시보드를 설정하고, 문제가 발생하면 알림을 받도록 구성할 수 있습니다.

팁: 각 플랫폼의 액세스 및 거버넌스 설정을 검토하십시오. 올바른 사용자만 코드를 배포하거나 변경할 수 있도록 해야 합니다. 이렇게 하면 워크플로가 안전하게 유지됩니다.

하이브리드 배포는 복잡해 보일 수 있지만, 적절한 방법을 적용하면 효과적으로 관리할 수 있습니다. 각 플랫폼의 장점을 누리면서도 배포에 대한 통제력을 유지할 수 있습니다. 모범 사례를 따르면 소프트웨어의 안정성과 보안을 확보할 수 있습니다.

적합한 DevOps 플랫폼 선택

핵심 소유권 질문

DevOps 플랫폼을 선택하기 전에 올바른 질문을 던져야 합니다. 이러한 질문은 각 도구가 소유권, 거버넌스, 통합을 어떻게 처리하는지 이해하는 데 도움이 됩니다. 다음 사항을 검토하십시오:

• 코드와 아티팩트에 대한 액세스는 누가 통제합니까?
• 플랫폼은 거버넌스와 규정 준수를 어떻게 적용합니까?
• 배포에서 누락된 메타데이터에 대한 알림을 자동화할 수 있습니까?
• 플랫폼이 기존 도구와의 통합을 지원합니까?
• 플랫폼은 서비스 소유권과 메타데이터를 어떻게 처리합니까?

서비스 소유권을 관리할 수 있는 DevOps 플랫폼을 찾아야 합니다. 개발자가 새 서비스를 생성할 때 서비스 메타데이터를 입력하도록 하십시오. 자동화를 활용하면 메타데이터를 정확하게 유지하는 데 도움이 됩니다. 배포 플랫폼을 Internal Developer Platform(IDP)으로 발전시키면 소유권을 중앙에서 관리하고 DevOps 프로세스를 효율화할 수 있습니다.

팁: 이러한 질문을 일찍 던지십시오. 혼선을 피하고 DevOps 워크플로의 탄탄한 기반을 마련할 수 있습니다.

플랫폼별 강점

각 DevOps 플랫폼에는 고유한 강점이 있습니다. 이러한 강점을 프로젝트 요구 사항에 맞춰야 합니다. 간략한 개요는 다음과 같습니다:

빠른 도입과 손쉬운 통합이 필요하다면 GitHub Actions를 사용할 수 있습니다. GitHub는 간단한 솔루션을 원하는 팀에 적합합니다. Azure DevOps는 복잡한 워크플로를 위한 고급 제어 기능을 제공합니다. 승인 게이트와 조건부 실행 전략 같은 기능을 사용할 수 있습니다. Azure Pipelines는 통합 중심 배포에 이상적입니다. Microsoft Fabric은 통합 분석과 거버넌스를 제공합니다. 버전 관리와 배포를 위해 워크스페이스를 GitHub 또는 Azure DevOps에 연결할 수 있습니다.

• GitHub Actions는 단순함과 빠른 구현에 중점을 둡니다.
• Azure DevOps는 지속적 통합 및 배포를 위한 성숙한 서비스를 제공합니다.
• Microsoft Fabric은 데이터 엔지니어링, 웨어하우징, 분석 도구를 통합합니다.

참고: 워크플로와 거버넌스 요구 사항에 맞는 플랫폼을 선택해야 합니다. 각 플랫폼은 DevOps 소유권 측면에서 서로 다른 강점을 제공합니다.

GitHub, Azure DevOps, Microsoft Fabric가 코드, 아티팩트, 접근 권한, 거버넌스를 어떻게 관리하는지 이해하면 배포 책임 소재를 명확하게 정할 수 있습니다. 보안 및 규정 준수 요구 사항에 맞는 플랫폼을 선택하십시오. 엔드포인트 관리 정책을 정의하고, 팀 간 공동 책임 체계를 수립하며, 필수 보안 통제 항목을 식별하십시오. 위험에 앞서 대응하려면 플랫폼 기능을 자주 검토하십시오. 플랫폼 선택은 공정성, 신뢰성, 책임성을 포함한 책임 있는 AI 정책과 맞춰야 합니다. 이렇게 하면 데이터를 보호하고 강력한 거버넌스를 유지할 수 있습니다.

이러한 선택이 배포 전략에 어떤 영향을 미치는지 요약하자면, 엔터프라이즈 의사 결정을 자세히 다루는 관련 팟캐스트 에피소드 GitHub vs Azure DevOps for Microsoft Fabric CI/CD를 꼭 확인하십시오.

자주 묻는 질문

DevOps 플랫폼에서 배포 책임 소재는 무엇을 의미합니까?

배포 책임 소재란 코드, 아티팩트, 접근 권한, 거버넌스를 직접 통제한다는 뜻입니다. 누가 배포할 수 있는지 결정하고, 변경 사항을 추적하며, 규칙을 적용할 수 있습니다. 이러한 책임 소재는 프로젝트를 보호하고 규정 준수를 유지하는 데 도움이 됩니다.

GitHub, Azure DevOps, Microsoft Fabric은 접근 제어를 어떻게 처리합니까?

각 플랫폼에서 역할과 권한을 설정합니다. GitHub는 팀과 코드 소유자(code owners)를 사용합니다. Azure DevOps는 보안 그룹과 역할 기반 액세스를 사용합니다. Microsoft Fabric은 작업 영역 권한에 Microsoft Entra ID를 활용합니다.

세 플랫폼 모두에서 배포를 자동화할 수 있습니까?

네, GitHub Actions, Azure Pipelines 또는 Microsoft Fabric 배포 파이프라인을 사용해 배포를 자동화할 수 있습니다. 자동화는 업데이트를 더 빠르게 제공하고 오류를 줄이는 데 도움이 됩니다.

Microsoft Fabric은 GitHub 및 Azure DevOps와 어떻게 통합됩니까?

Fabric 작업 영역을 GitHub 또는 Azure DevOps 리포지토리에 연결합니다. 이 통합을 통해 버전 관리, 자동화된 배포, 통합된 분석 거버넌스를 사용할 수 있습니다.

배포를 보호하는 보안 기능에는 무엇이 있습니까?

2단계 인증, 비밀 관리, 자동화된 보안 검사를 사용합니다. Azure DevOps는 승인 게이트와 Defender for Cloud를 추가로 제공합니다. Microsoft Fabric은 데이터 손실 방지(DLP)와 개인 정보 관리 도구를 제공합니다.

이러한 플랫폼에서 규정 준수는 어떻게 관리합니까?

브랜치 정책, 감사 로그, 거버넌스 규칙을 설정합니다. Azure DevOps와 Microsoft Fabric은 GDPR, ISO 같은 규정 준수 프레임워크를 지원합니다. GitHub Enterprise는 조직을 위한 고급 규정 준수 도구를 제공합니다.

Microsoft Fabric에 배포된 분석 자산의 소유자는 누구입니까?

새 항목을 배포하면 해당 사용자가 소유자가 됩니다. 기존 항목이 있는 단계로 배포하는 경우 소유권은 그대로 유지됩니다. 작업 영역 역할과 권한을 사용하면 액세스를 관리하는 데 도움이 됩니다.

Azure DevOps와 GitHub의 핵심 차이점은 무엇입니까?

Azure DevOps(ADO)는 Azure Boards, Pipelines, Repos, Test Plans, 아티팩트 관리를 제공하는 개발자 도구 모음으로, 엔터프라이즈 프로젝트 관리와 CI/CD에 중점을 둡니다. 반면 GitHub는 git 리포지토리, 풀 리퀘스트, 개발자 커뮤니티를 중심으로 하는 git 우선 플랫폼이며, GitHub Repos, GitHub Enterprise Cloud, GitHub Actions 같은 기능을 제공합니다. Azure DevOps는 통합된 작업 항목 추적과 Visual Studio Team Services(TFS) 계보로 선호되는 경우가 많고, GitHub는 대규모 오픈 소스 생태계와 최신 협업 기능을 제공합니다.

버전 관리에는 Azure Repos와 GitHub Repos 중 무엇을 사용해야 합니까?

두 서비스 모두 git 리포지토리와 버전 관리를 지원합니다. Azure Repos는 Azure Boards 및 Azure Pipelines와 긴밀하게 통합되어 Microsoft Azure DevOps 워크플로를 사용하는 팀에 적합합니다. GitHub Repos(GitHub에서 호스팅)는 공개 및 비공개 리포지토리, 오픈 소스 프로젝트 관리, 커뮤니티 기여, 풀 리퀘스트 워크플로 같은 기능에 강점이 있습니다. 통합된 Azure Boards를 선호하는지, 아니면 더 넓은 GitHub 플랫폼과 커뮤니티를 선호하는지에 따라 선택하십시오.

Azure Repos의 리포지토리를 GitHub로 마이그레이션할 수 있습니까?

네, Azure Repos의 리포지토리를 GitHub로 옮길 수 있습니다. 많은 팀이 ADO 리포지토리에서 git 리포지토리를 내보낸 뒤 GitHub 리포지토리로 가져오거나 마이그레이션 도구를 사용합니다. 마이그레이션에는 커밋 기록 보존, GitHub Enterprise Cloud의 Enterprise Managed Users 관리가 함께 필요한 경우가 많으며, 원한다면 Azure Pipelines에서 GitHub Actions로 CI/CD 통합도 업데이트해야 합니다.

애자일 프로젝트 관리 측면에서 Azure Boards와 GitHub 이슈는 어떻게 다른가요?

Azure Boards는 작업 항목, 백로그, 스프린트 등 체계적인 애자일 프로젝트 관리 기능을 제공하며, 파이프라인 및 Test Plans와 긴밀하게 통합되어 기업에 적합한 프로젝트 관리 도구입니다. GitHub 이슈(및 프로젝트 보드)는 더 단순하여 오픈 소스와 개발자 커뮤니티 워크플로에 적합합니다. GitHub도 프로젝트 계획 기능을 확장해 왔지만, 일부 팀은 GitHub 리포지토리를 Azure Boards에 연결해 두 도구의 장점을 함께 활용합니다.

Azure DevOps 사용자도 GitHub Copilot을 사용할 수 있나요?

GitHub Copilot은 Visual Studio Code, Visual Studio 같은 개발 도구와 주로 통합됩니다. 따라서 Azure DevOps를 사용하는 개발자도 IDE에서 Copilot을 계속 사용할 수 있습니다. GitHub Copilot과 이후 출시된 Copilot 워크스페이스 기능 덕분에 백엔드 CI/CD와 관계없이 개발자가 이를 활용할 수 있습니다. 다만 일부 엔터프라이즈 제어 기능과 라이선스는 GitHub Enterprise Cloud를 사용하는지, 아니면 Azure DevOps로 관리되는 환경을 선호하는지에 따라 달라집니다.

엔터프라이즈 관리 사용자와 보안 측면에서는 GitHub와 Azure DevOps 중 어느 플랫폼이 더 나은가요?

두 플랫폼 모두 엔터프라이즈 기능을 제공합니다. Microsoft Azure DevOps는 세분화된 액세스 제어, Azure AD 통합, 고급 규정 준수 기능을 제공합니다. GitHub Enterprise Cloud는 Enterprise Managed Users와 코드 검사, 비밀 검사, 종속성 관리 기능을 제공하는 Azure용 GitHub Advanced Security를 포함합니다. 선택은 조직의 요구 사항에 따라 달라집니다. 기존 Microsoft 도구와의 통합은 Azure DevOps가 더 잘 맞을 수 있고, 오픈 소스와 커뮤니티 기능 및 고급 보안 옵션은 GitHub가 더 강력합니다.

Azure Pipelines와 GitHub Actions의 CI/CD 파이프라인은 어떻게 다른가요?

Azure Pipelines(Azure Boards 및 Pipelines의 일부)는 Azure DevOps 및 Visual Studio와 강력하게 통합된 다중 플랫폼 CI/CD를 제공합니다. GitHub Actions는 GitHub 플랫폼과 긴밀하게 통합되어 리포지토리 이벤트로 트리거되는 유연한 워크플로와 끌어오기 요청 자동화를 제공합니다. 두 도구 모두 컨테이너, 클라우드 배포, 자체 호스팅 실행기를 지원합니다. 워크플로에 맞는 DevOps 도구를 선택하거나, 두 도구를 연결해 각각의 장점을 활용할 수 있습니다.

두 플랫폼 모두에서 Visual Studio와 VS Code를 사용할 수 있나요?

네, Visual Studio와 Visual Studio Code(VS Code) 모두 GitHub와 Azure DevOps를 지원합니다. Visual Studio는 Azure Repos 및 ADO와 기본 제공 통합 기능을 갖추고 있으며, VS Code는 GitHub 리포지토리, GitHub Copilot, 일반 git 리포지토리와 잘 작동합니다. 개발자는 이러한 도구를 여러 플랫폼에 걸쳐 사용하여 코드를 편집하고, 테스트를 실행하며, 끌어오기 요청이나 작업 항목과 상호 작용할 수 있습니다.

테스트 측면에서 GitHub에도 Azure Test Plans가 있나요?

Azure Test Plans는 Azure DevOps에 포함된 통합 테스트 솔루션으로, 수동 테스트와 탐색형 테스트 도구를 제공합니다. GitHub에는 이와 동일한 기본 제공 테스트 계획 제품이 없습니다. 대신 테스트 프레임워크, 작업(Actions), 타사 테스트 관리 도구를 GitHub 리포지토리와 통합하여 비슷한 테스트 자동화와 보고 기능을 구현할 수 있습니다.

가격 책정과 호스팅은 GitHub 호스팅과 Microsoft Azure DevOps 호스팅에서 어떻게 다른가요?

GitHub는 팀과 엔터프라이즈를 위한 등급별 요금제를 갖춘 호스팅 서비스(GitHub.com, GitHub Enterprise Cloud)를 제공하며, 공개 및 비공개 리포지토리와 커뮤니티 접근성을 강조합니다. Microsoft Azure DevOps Services도 사용자 기반 요금제의 호스팅 클라우드 옵션과 온-프레미스 버전(이전 명칭 TFS/Visual Studio Team Services)을 제공합니다. 비용을 결정할 때는 파이프라인 실행 시간(분), 아티팩트 스토리지, Enterprise Managed Users, 온-프레미스 호스팅 필요 여부를 고려해야 합니다.

팀이 GitHub와 Azure DevOps를 함께 사용할 수 있나요?

네, 많은 조직이 코드 호스팅과 커뮤니티 협업에는 GitHub를, 프로젝트 관리, 파이프라인, 테스트 계획에는 Azure DevOps를 함께 사용합니다. 이 방식은 리포지토리와 커뮤니티에 강한 GitHub 플랫폼의 장점과 Azure Boards 같은 Azure DevOps 기능의 장점을 함께 제공합니다. 통합 기능과 커넥터를 사용하면 Azure Repos의 리포지토리를 GitHub와 동기화하거나, GitHub 리포지토리 이벤트를 ADO 보드에 연결할 수 있습니다.

개발자 커뮤니티의 개발자들은 GitHub와 Azure DevOps 중 어떤 도구를 더 선호합니까?

오픈 소스 기여자와 많은 개인 개발자는 커뮤니티 형성, 공개 및 비공개 리포지토리, 통합 검토 워크플로를 중시하여 GitHub를 선호하는 반면, 엔터프라이즈 개발자와 포괄적인 프로젝트 관리가 필요한 팀은 Azure DevOps를 선호하는 경우가 많습니다. 이러한 선호도는 Visual Studio와 Microsoft Azure에 대한 기존 투자 현황, 그리고 GitHub Copilot이나 Azure용 GitHub Advanced Security 같은 기능을 우선시하는지 여부에 따라서도 달라집니다.

GitHub와 Azure DevOps 중 하나를 선택할 때 팀이 고려해야 할 사항은 무엇입니까?

버전 관리 요구 사항, Visual Studio 또는 VS Code와의 통합, 애자일 프로젝트 관리(Azure Boards) 필요성, 보안 및 규정 준수 요건, Azure Test Plans 필요 여부, 커뮤니티 및 오픈 소스 노출 범위, 그리고 GitHub Copilot이나 고급 보안 검사 같은 기능의 필요 여부를 검토합니다. 그런 다음 자신의 워크플로에 맞는 DevOps 도구를 평가하거나, Azure Repos의 리포지토리를 활용하거나 Azure Boards 및 파이프라인과 함께 GitHub 리포지토리를 사용하는 하이브리드 모델을 채택합니다.