KO
English
Deutsch
Español
Français
Italiano
Português
Nederlands
Polski
Bahasa Indonesia
Русский
Українська
العربية
עברית
日本語Microsoft Fabric을 GitHub 및 Azure DevOps와 매끄럽게 통합하기
By Mirko Peters · · Updated
최신 데이터 및 분석 워크로드를 관리할 때는 견고한 버전 관리와 거버넌스를 확보하는 것이 선택이 아닌 필수입니다. 기술 리더로서 우리는 늘 개발자 속도와 엔터프라이즈급 규정 준수 사이에서 균형을 맞춰야 합니다. 그래서 Microsoft Fabric 작업 영역을 GitHub나 Azure DevOps 같은 외부 리포지토리에 연결하는 방식이 분석 엔지니어링에서 판도를 바꾸는 접근법으로 자리 잡았습니다. 이 글에서는 안정적인 통합을 구성하는 방법, 배포 소유권을 평가하는 방법, 그리고 각 플랫폼의 고유한 강점을 활용하는 방법을 살펴보겠습니다.
Automatically translated with AI from the original post. Read the English original
최신 데이터 및 분석 워크로드를 관리할 때는 견고한 버전 관리와 거버넌스를 확보하는 것이 선택이 아닌 필수입니다. 기술 리더로서 우리는 늘 개발자 속도와 엔터프라이즈급 규정 준수 사이에서 균형을 맞춰야 합니다. 그래서 Microsoft Fabric 작업 영역을 GitHub나 Azure DevOps 같은 외부 리포지토리에 연결하는 것이 분석 엔지니어링에서 판도를 바꾸는 방식으로 자리 잡았습니다. 이 글에서는 매끄러운 통합을 구성하는 방법, 배포 소유권을 평가하는 방법, 그리고 각 플랫폼의 고유한 강점을 활용하는 방법을 살펴보겠습니다.
이 주제를 더 깊이 다루고 두 생태계가 어떻게 상호작용하는지에 대한 전문가의 설명을 듣고 싶다면 함께 제공되는 팟캐스트 에피소드 GitHub vs Azure DevOps for Microsoft Fabric CI/CD를 꼭 들어 보시기 바랍니다.
GitHub vs Azure DevOps: 놀라운 사실 5가지
- 출발점은 다르지만 기능은 수렴합니다: 두 플랫폼 모두 CI/CD와 협업을 지향하지만, GitHub는 소셜 코딩 플랫폼으로 출발했고 Azure DevOps는 Microsoft의 엔터프라이즈 ALM 도구(Team Foundation Server)에서 발전했습니다. 그래서 워크플로와 엔터프라이즈 통합 방식이 크게 다릅니다.
- 파이프라인 이식성: Azure DevOps 파이프라인은 여러 플랫폼에서 YAML 기반 빌드를 실행할 수 있고, 클래식 파이프라인의 작업을 재사용할 수도 있습니다. 반면 GitHub Actions는 커뮤니티가 만든 액션을 담은 대규모 공개 마켓플레이스를 제공합니다. 따라서 이식성은 마켓플레이스 액션을 쓸 수 있는지, 아니면 내장된 Azure 작업 라이브러리를 쓸 수 있는지에 따라 달라지는 경우가 많습니다.
- Boards와 Issues의 철학 차이: Azure DevOps는 사용자 지정 프로세스 템플릿과 엔터프라이즈 계획 중심의 보고 기능을 갖춘 완전한 작업 항목 시스템(Boards)을 제공합니다. 반면 GitHub Issues는 더 단순하고 소셜한 성격입니다. "github vs azure devops" 비교에서 동일한 프로젝트 추적 기능을 기대한 팀에게는 놀라운 차이일 수 있습니다.
- 엔터프라이즈 규정 준수와 온프레미스 옵션: Azure DevOps Server는 규제가 엄격한 조직에서 흔히 요구하는 성숙한 온프레미스 호스팅과 규정 준수 통제 기능을 제공합니다. GitHub도 GitHub Enterprise Server를 제공하지만 역사적으로 클라우드 우선 워크플로에 더 중점을 두어 왔습니다. 그래서 규정 준수 요건이 많은 팀에게는 두 플랫폼이 뚜렷이 다른 선택지가 됩니다.
- 가격 및 사용자 모델의 차이: GitHub의 가격과 협업자 모델은 리포지토리와 조직을 중심으로 하며, 오픈 소스에 대해 넉넉한 무료 등급을 제공합니다. 반면 Azure DevOps는 일부 기능(Test Plans, Artifacts)에 사용자별 라이선스를 적용하며, 대규모 엔터프라이즈 라이선스 계약에서는 비용 예측이 더 용이할 수 있습니다. "github vs azure devops"를 비교할 때 뜻밖에 중요한 요소입니다.
배포 소유권 자세히 알아보기
배포 소유권이란
배포 소유권은 DevOps 프로세스의 모든 단계를 직접 통제할 수 있다는 뜻입니다. 코드가 개발에서 전달까지 이동하는 방식을 결정합니다. DevOps 도구에 누가 접근할 수 있는지, 변경 사항을 어떻게 추적하는지도 관리합니다. 자동화 규칙을 정하고, 팀이 그 규칙을 따르도록 보장합니다.
코드 및 아티팩트
소스 코드와 아티팩트는 DevOps 플랫폼에서 관리합니다. 이 구성 요소들은 전달 파이프라인의 기반을 이룹니다. 최신 DevOps 도구에서 배포 소유권을 구성하는 주요 항목은 다음과 같습니다.
- 소스 코드 추적
- 테스트
- 배포
- 인프라 관리
- 빌드 추적
- 비밀 관리
- 릴리스 관리
이러한 단계는 DevOps 도구로 자동화합니다. 자동화는 업데이트를 더 빠르게 전달하고 오류를 줄여 줍니다. 코드를 안전하게 보호하고, 아티팩트가 테스트된 버전과 일치하도록 확인합니다. 빌드와 릴리스를 추적하여 환경 전반의 일관성을 유지합니다.
접근 및 거버넌스
DevOps 도구에 대한 접근을 통제하고 거버넌스 정책을 설정합니다. 누가 코드를 보고, 편집하고, 배포할 수 있는지 결정합니다. 자동화를 활용해 규칙을 적용하고 활동을 모니터링합니다. 거버넌스는 개발과 전달 과정에서 팀이 표준을 따르도록 보장합니다. 소프트웨어 개발 프로세스를 보호하기 위해 작업을 기록하고 변경 사항을 검토합니다.
소유권이 중요한 이유
소유권은 DevOps 환경에 대한 통제력을 제공합니다. 전달 파이프라인을 위험으로부터 보호하고 개발 환경을 안전하게 유지합니다. 규제 요건을 준수하고 운영 통제를 뒷받침합니다.
DevOps 도구를 사용하면 강력한 거버넌스 프레임워크를 구축할 수 있습니다. 팀이 독립적으로 작업할 수 있도록 자율성을 확보하고, 위험을 관리하며, 배포 프로세스를 안정적으로 유지할 수 있습니다. 자동화는 개발과 배포를 더 효율적으로 만들어 이러한 목표를 뒷받침합니다.
팁: DevOps 파이프라인을 직접 소유하면 변화에 신속하게 대응하고 소프트웨어 개발을 계획대로 진행할 수 있습니다.
DevOps 도구에 대해 현명한 결정을 내리려면 배포 소유권을 이해해야 합니다. 이를 통해 배포 속도를 높이고, 코드를 보호하며, 개발 프로세스에 대한 통제권을 유지할 수 있습니다.
GitHub 소유권 모델
코드 및 아티팩트 저장소
GitHub를 소스 제어의 중심 공간으로 활용합니다. 코드를 github.com에 푸시하면 모든 변경 사항의 명확한 이력이 남습니다. 이를 통해 누가 언제 업데이트했는지 추적할 수 있습니다. 필요에 따라 공개 또는 비공개 리포지토리에 코드를 저장할 수 있습니다. GitHub Enterprise를 사용하면 고급 보안 및 규정 준수 도구와 같이 대규모 조직을 위한 추가 기능을 이용할 수 있습니다.
배포 아티팩트의 경우 GitHub는 GitHub Packages를 제공합니다. 이 서비스를 사용하면 빌드 결과물, 컨테이너 이미지 및 기타 파일을 코드와 함께 저장할 수 있습니다. 워크플로에서 이러한 아티팩트에 직접 액세스할 수 있습니다. 하지만 GitHub Packages는 생성 날짜와 다운로드 횟수와 같은 기본 메타데이터만 제공합니다. 아티팩트 관리를 위해 사용자 지정 속성을 추가하거나 고급 쿼리를 사용할 수는 없습니다. JFrog와 같은 다른 플랫폼은 메타데이터와 쿼리 측면에서 더 많은 옵션을 제공합니다.
액세스 및 권한
GitHub.com에서 누가 코드를 보고 변경할 수 있는지 통제합니다. 사용자와 팀에 역할을 할당하여 각 사용자가 필요한 액세스 권한만 갖도록 합니다. 이는 최소 권한 원칙을 따르는 방식입니다. 조직 내에서 팀을 만들고 팀마다 다른 권한을 설정할 수 있습니다. 예를 들어, 개발자에게는 쓰기 권한을 주되 관리자 권한은 신뢰할 수 있는 구성원으로 제한할 수 있습니다.
GitHub를 ID 및 액세스 관리(IAM) 시스템에 연결하여 액세스 관리를 자동화할 수 있습니다. 이렇게 하면 팀 구성이 바뀔 때 사용자를 쉽게 추가하거나 제거할 수 있습니다. 또한 명확한 액세스 제어 정책을 수립하고 정기적으로 검토해야 합니다. GitHub에서는 액세스 로그를 감사하여 비정상적인 활동을 찾아낼 수 있습니다.
- 리포지토리, 조직 또는 엔터프라이즈 수준에서 역할과 권한을 할당합니다.
- 중요한 코드 변경에 대해 검토를 필수로 하려면 코드 소유자를 사용합니다.
- 관리자 액세스를 제한하고 꼭 필요한 경우에만 사용합니다.
- 승인되지 않은 작업이 있는지 감사 로그를 정기적으로 확인합니다.
거버넌스 및 규정 준수
배포를 안전하고 규정을 준수하도록 유지하려면 강력한 거버넌스가 필요합니다. GitHub에는 이를 관리하기 위한 여러 도구가 있습니다. 프로젝트 간에 워크플로를 재사용할 수 있어 시간을 절약하고 일관성을 보장할 수 있습니다. GitHub Actions를 사용하면 배포를 자동화하고 환경별 규칙을 적용할 수 있습니다.
아티팩트 증명(artifact attestations)을 사용하면 배포 파일이 변경되지 않았음을 검증할 수 있습니다. GitHub는 클라우드 플랫폼에 안전하게 배포할 수 있도록 OpenID Connect(OIDC)를 지원합니다. 누가 언제 배포할 수 있는지에 대한 규칙을 설정하여 배포를 통제할 수 있습니다. GitHub에서는 배포 이력도 확인할 수 있으므로 감사와 규정 준수 점검에 도움이 됩니다.
참고: GitHub Actions는 Microsoft Fabric과 통합되므로 동일한 거버넌스 통제 아래에서 배포를 자동화하고 분석 솔루션을 관리할 수 있습니다.
보안 고려 사항
GitHub로 배포 파이프라인을 운영할 때는 보안에 각별히 주의해야 합니다. 워크플로의 여러 지점에서 보안 위협이 나타날 수 있습니다. 공격자는 소스 코드나 빌드 아티팩트에 악성 코드를 삽입하려 할 수 있습니다. 모범 사례를 따르지 않으면 액세스 키와 비밀번호 같은 민감한 데이터가 노출될 수 있습니다. 승인되지 않은 액세스는 공격자에게 파이프라인과 프로덕션 환경에 대한 통제권을 줄 수 있습니다. 오래된 종속성은 전체 시스템을 위협하는 취약점을 초래할 수 있습니다.
강력한 액세스 제어를 적용하여 GitHub 리포지토리를 보호해야 합니다. 모든 사용자에게 2단계 인증을 활성화해야 합니다. 자격 증명과 토큰을 안전하게 보관하려면 비밀 관리(secrets management)를 사용할 수 있습니다. 민감한 정보를 코드에 직접 저장하지 않도록 해야 합니다. 권한을 자주 검토하고 더 이상 필요하지 않은 사용자의 액세스 권한은 제거해야 합니다.
팁: GitHub의 내장 도구와 외부 솔루션을 함께 사용하면 보안 태세를 개선할 수 있습니다. 추가 보호를 위해 타사 스캐너를 사용하거나 클라우드 보안 플랫폼과 통합할 수 있습니다.
GitHub를 리포지토리로 시작하기 - 체크리스트(GitHub vs Azure DevOps)
GitHub를 코드 리포지토리로 사용하기 시작할 때 활용할 수 있는 실용적인 체크리스트입니다.
- GitHub 계정을 만들거나 로그인합니다
- 팀 소유를 위해 개인 계정과 조직 중 무엇을 사용할지 결정합니다
- 새 리포지토리(퍼블릭 또는 프라이빗)를 만들고 적절한 공개 범위를 선택합니다
- 명확한 리포지토리 이름을 정하고 설명이 담긴 README.md를 추가합니다
- 프로젝트 요구 사항에 맞는 LICENSE 파일을 추가합니다
- 사용하는 언어나 프레임워크에 맞는 .gitignore를 추가합니다
- 기본 브랜치(main)로 리포지토리를 초기화하고 브랜치 보호 규칙을 설정합니다
- CODEOWNERS와 기여 가이드라인(CONTRIBUTING.md)을 구성합니다
- 이슈 템플릿과 풀 리퀘스트 템플릿을 설정합니다
- 이슈 추적을 위해 레이블, 마일스톤, 프로젝트 보드를 구성합니다
- CI/CD용 GitHub Actions 워크플로를 설정하거나 기존 파이프라인과 통합합니다
- CI, 배포, 타사 서비스에 사용할 리포지토리 시크릿을 추가합니다
- 브랜치 보호 규칙을 구성합니다: 필수 리뷰, 상태 검사, 필요한 경우 서명된 커밋 필수 설정
- 종속성 업데이트와 보안 경고를 위해 Dependabot을 활성화합니다
- 보안 기능을 활성화합니다: 코드 검사, 비밀 검사, 취약점 경고
- CI, ChatOps 또는 외부 서비스용 웹후크나 통합을 설정합니다
- 공동 작업자나 팀원을 초대하고 리포지토리 권한을 설정합니다
- 기존 리포지토리와 이슈를 마이그레이션합니다(Azure DevOps에서 이전하는 경우 마이그레이션을 계획하고 작업 항목을 매핑합니다)
- 위키 또는 docs 폴더에 리포지토리 구조, 개발 워크플로, 릴리스 프로세스를 문서화합니다
- 릴리스, 배포, 주요 워크플로에 대한 모니터링과 알림을 구성합니다
- 워크플로와 대안을 검토하고 비교(GitHub 대 Azure DevOps)하여 CI/CD 및 프로젝트 관리 선택을 최적화합니다
- 리포지토리 액세스, 시크릿, 보안 설정을 정기적으로 감사합니다
Azure DevOps 소유 모델
리포지토리와 파이프라인
Azure DevOps를 사용하면 코드, 아티팩트, 배포 프로세스를 관리하는 통합 플랫폼을 얻을 수 있습니다. Azure DevOps 서비스는 코드 리포지토리, 작업 추적, 테스트 도구, 아티팩트 저장소를 한데 모읍니다. 이러한 통합을 통해 소프트웨어 제공 수명 주기의 모든 단계를 제어할 수 있습니다. 각 파이프라인 실행을 특정 커밋, 풀 리퀘스트, 작업 항목까지 추적할 수 있어 개발 프로세스를 명확하게 파악할 수 있습니다.
Azure DevOps 파이프라인은 리소스에 액세스할 때 ID를 사용합니다. 이러한 ID는 컬렉션 수준 또는 프로젝트 수준에서 설정할 수 있습니다. 프로젝트 수준 ID를 사용하면 각 프로젝트에 필요한 리소스로만 액세스를 제한할 수 있어 보안이 강화됩니다. 검사와 파이프라인 권한을 사용해 리포지토리 리소스에 보호 기능을 추가할 수도 있습니다. 이를 통해 코드와 배포 워크플로에 대한 소유권과 편집 권한을 관리할 수 있습니다.
Azure DevOps는 간소화된 CI/CD를 지원하므로 빌드, 테스트, 배포를 자동화할 수 있습니다. Azure Pipelines를 사용하면 지속적 통합과 지속적 제공을 얻을 수 있어 업데이트를 빠르고 안정적으로 제공하는 데 도움이 됩니다. Microsoft는 Azure DevOps가 클라우드 컴퓨팅과 잘 작동하도록 설계했으므로, 요구가 늘어나도 프로젝트를 쉽게 확장할 수 있습니다.
액세스 제어
역할 기반 액세스 제어(RBAC)를 사용해 Azure DevOps 서비스에 액세스할 수 있는 사용자를 관리합니다. 이 모델을 사용하면 역할에 따라 권한을 할당하므로 각 사용자는 필요한 액세스 권한만 갖게 됩니다. 사용자를 보안 그룹으로 구성하고 조직, 프로젝트, 개체 수준에서 권한을 할당할 수 있습니다. Microsoft는 최소 권한 원칙을 따르도록 권장합니다. 즉, 사용자에게 작업에 필요한 권한만 부여합니다.
- 정밀한 액세스 제어를 위해 사용자와 그룹에 역할을 할당합니다.
- 여러 수준에서 권한을 관리하려면 보안 그룹을 사용합니다.
- 예상치 못한 사용을 찾아내기 위해 권한을 정기적으로 검토하고 감사합니다.
거버넌스와 정책
안전하고 안정적인 배포를 위해서는 강력한 거버넌스가 필수입니다. Azure DevOps는 브랜치 정책, 액세스 제어, 사용자 지정 역할을 통해 거버넌스를 적용합니다. 브랜치 정책을 사용하면 코드를 병합하기 전에 검사와 요구 사항을 설정할 수 있으므로 품질이 검증된 코드만 프로덕션에 반영됩니다. 최소 권한 원칙에 따라 보안 주체를 역할에 할당할 수 있으며, 이를 통해 무단 액세스 위험을 줄일 수 있습니다.
- 병합 전에 코드 리뷰와 검사를 요구하도록 브랜치 정책을 설정합니다.
- 프로덕션에서 파괴적인 작업을 막기 위해 서비스 주체에 사용자 지정 역할을 할당합니다.
- 중요한 환경에 배포할 수 있는 사용자를 액세스 제어로 제한합니다.
팁: 배포를 안전하고 규정을 준수하는 상태로 유지하려면 Azure DevOps의 거버넌스 설정을 정기적으로 검토합니다.
보안 및 규정 준수
배포를 관리할 때는 강력한 보안 및 규정 준수 통제가 필요합니다. Azure DevOps는 코드, 데이터, 워크플로를 보호하는 데 도움이 되는 다양한 도구를 제공합니다. 내장 보안 기능을 활용하면 개발 프로세스를 안전하게 유지하고 업계 표준을 준수할 수 있습니다.
Azure DevOps는 역할 기반 액세스 제어(RBAC)를 사용하여 누가 리소스를 보거나 변경할 수 있는지 제한합니다. 사용자와 그룹에 권한을 할당하여 올바른 사람만 액세스할 수 있도록 합니다. 서비스 연결을 사용하면 파이프라인이 다른 Azure 서비스와 상호 작용하는 방식도 제어할 수 있습니다. 이를 통해 승인되지 않은 작업의 위험을 줄일 수 있습니다.
팁: Azure DevOps의 보안 설정을 자주 검토하십시오. 팀이 성장하거나 프로젝트가 변경될 때마다 정책과 권한을 업데이트하십시오.
Azure DevOps를 리포지토리로 시작하기 — 체크리스트(GitHub 대 Azure DevOps)
- Azure DevOps 조직을 만들거나 해당 조직에 로그인합니다
- 새 프로젝트를 만들고(공개 범위: 비공개/공개 선택) 버전 管理 시스템으로 Git을 선택합니다
- 첫 번째 리포지토리를 만들거나 기존 리포지토리를 가져옵니다(GitHub 또는 로컬에서)
- 설명이 담긴 README.md 파일과 라이선스 파일을 추가합니다
- 프로젝트의 언어/프레임워크에 맞는 .gitignore를 추가합니다
- 브랜치 전략과 명명 규칙(main, develop, feature/*, hotfix/*)을 정의합니다
- main 브랜치를 보호합니다. 브랜치 정책, 필수 검토자, 상태 검사를 사용하도록 설정합니다
- 끌어오기 요청(PR) 템플릿과 기여자 가이드라인을 만듭니다
- 리포지토리 권한과 그룹(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)이 필요하면 Artifacts 피드를 설정합니다
- 위키 또는 문서 사이트를 만들고, 적절한 경우 문서를 리포지토리에 보관합니다
- GitHub에서 마이그레이션하는 경우 마이그레이션 단계를 계획합니다. 리포지토리, 이슈, PR, CI/CD, 서비스 계정을 매핑하십시오
- 팀원을 초대하고 각자의 계정에서 액세스 권한을 확인합니다
- 초기 엔드 투 엔드 테스트를 실행합니다. 복제, 커밋, 푸시, PR 열기, 파이프라인 실행, 테스트 환경 배포 순으로 진행합니다
- 사용량과 파이프라인을 모니터링하고 정책과 자동화를 반복적으로 개선합니다
Microsoft Fabric 통합
Git 통합
Microsoft Fabric 워크스페이스를 GitHub 리포지토리에 직접 연결할 수 있습니다. 이 연결을 통해 분석 프로젝트에 대한 강력한 버전 관리를 적용할 수 있습니다. 워크스페이스를 GitHub의 develop 브랜치에 연결합니다. 이렇게 설정하면 모든 변경 사항을 추적하고 필요할 때 롤백할 수 있습니다. Microsoft Fabric의 배포 파이프라인을 사용하여 콘텐츠를 개발에서 테스트, 그리고 프로덕션으로 이동할 수 있습니다. 이 과정은 환경 간 동기화 문제를 방지하는 데 도움이 됩니다.
안정적인 기능을 릴리스하려면 릴리스 브랜치를 만듭니다. 배포 파이프라인을 사용하여 이러한 변경 사항을 프로덕션에 반영합니다. 긴급한 문제를 수정해야 하면 핫픽스 브랜치를 만듭니다. 이 브랜치를 main 브랜치에 병합한 후 배포합니다. 환경마다 별도의 데이터베이스를 사용해야 합니다. 이 방식은 테스트나 개발 중의 실수로 인해 프로덕션 데이터가 변경되는 것을 막아 줍니다.
Azure DevOps 및 GitHub를 활용한 CI/CD
Azure DevOps 또는 GitHub Actions를 사용하여 Microsoft Fabric에서 CI/CD 파이프라인을 설정할 수 있습니다. 이러한 도구를 사용하면 빌드, 테스트, 배포 단계를 자동화하는 데 도움이 됩니다. 배포 파이프라인에는 명확하고 설명적인 이름을 지정해야 합니다. 그래야 각 파이프라인의 목적을 쉽게 파악할 수 있습니다. 기존 워크스페이스를 사용하거나 개발, 테스트, 프로덕션 등 파이프라인 단계별로 새 워크스페이스를 만들어 사용할 수 있습니다.
단계 간에 콘텐츠를 자주 비교해야 합니다. 이 검사를 통해 모든 항목이 올바르게 배포되었는지 확인할 수 있습니다. 파이프라인 내 어떤 워크스페이스에서든 애플리케이션을 게시할 수 있습니다. 이 단계를 통해 최종 배포 전에 최종 사용자가 기능을 테스트할 수 있습니다. 개발자나 기능별로 별도의 브랜치를 유지해야 합니다. 이렇게 하면 병합 충돌을 방지하는 데 도움이 됩니다. Gitflow와 같이 체계적인 브랜치 전략을 사용하면 개발, 릴리스, 핫픽스를 효율적으로 관리할 수 있습니다.
데이터 거버넌스
Microsoft Fabric는 데이터 수명 주기의 모든 단계에 거버넌스를 내장합니다. 데이터 수집, 저장, 분석을 하나의 환경에서 관리할 수 있습니다. Microsoft Purview는 데이터를 카탈로그화하고 계보(lineage)를 추적합니다. OneLake는 중앙 집중식 스토리지를 제공하므로 거버넌스 정책을 쉽게 적용할 수 있습니다. Microsoft Entra ID는 역할 기반 액세스 제어를 제공하므로 누가 데이터를 보거나 변경할 수 있는지 직접 결정할 수 있습니다.
거버넌스 정책은 OneLake 수준에서 적용합니다. 이 규칙은 워크스페이스와 데이터 세트 전반에 걸쳐 데이터를 따라갑니다. 이런 방식은 데이터 처리의 일관성을 유지하고 속도도 높여 줍니다. 워크스페이스마다 별도의 규칙을 설정할 필요가 없습니다. 데이터가 늘어나더라도 Microsoft Fabric의 설계 덕분에 제어 수준을 유지하고 규정 준수 요건을 충족하기가 수월합니다.
보안 및 규정 준수
Microsoft Fabric에서 데이터와 배포를 관리할 때는 강력한 보안 및 규정 준수 제어가 필요합니다. 이 플랫폼은 중요한 정보를 보호하고 규제 요건을 충족하는 데 도움이 되는 고급 도구를 제공합니다. Data Factory 파이프라인에서 민감한 데이터를 분류하고 보호할 수 있습니다. 이를 통해 중요한 정보가 무단 액세스로부터 안전하게 보호됩니다.
Microsoft Fabric은 Microsoft Defender for Cloud Apps와 연동됩니다. 이 통합을 통해 운영 상황을 더 잘 파악하고 제어할 수 있습니다. 활동을 모니터링하고 위험한 동작에 대한 경고를 설정할 수 있습니다. 데이터 계보도 추적할 수 있습니다. 이 기능을 사용하면 시스템 내에서 데이터가 어떻게 이동하는지 확인할 수 있습니다. 이 정보를 활용해 규정 준수를 검증하고 민감한 데이터의 흐름을 파악할 수 있습니다.
팁: 보안 및 규정 준수 설정을 자주 점검하세요. 정기적인 점검은 새로운 위험에 앞서 대응하고 데이터를 안전하게 유지하는 데 도움이 됩니다.
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 보고서와 시맨틱 모델 같은 분석 아티팩트에 중점을 둡니다. 버전 관리를 위해 리포지토리와 연결되며, 환경 간 아티팩트 이동에는 배포 파이프라인을 사용합니다.
팁: 최소 권한 원칙을 사용하세요. 사용자에게 필요한 액세스 권한만 부여하세요. 이렇게 하면 위험이 줄고 보안을 유지하는 데 도움이 됩니다.
거버넌스 및 규정 준수
배포를 보호하고 업계 표준을 충족하려면 강력한 거버넌스와 규정 준수가 필요합니다. GitHub, Azure DevOps, Microsoft Fabric은 각각 이러한 요구를 충족하기 위한 서로 다른 도구와 접근 방식을 제공합니다.
GitHub는 유연한 거버넌스를 제공합니다. 브랜치 보호 규칙을 설정하고, 코드 검토를 요구하고, CODEOWNERS 파일을 사용할 수 있습니다. 이러한 기능으로 누가 코드를 변경할 수 있는지 제어할 수 있습니다. 감사 로그를 사용해 리포지토리에서 수행된 작업을 추적할 수도 있습니다.
Azure DevOps는 엔터프라이즈 거버넌스에 초점을 맞춥니다. 브랜치 정책, 승인 게이트, 사용자 지정 역할을 설정할 수 있습니다. 이러한 제어 기능으로 여러 프로젝트에 걸쳐 표준을 적용할 수 있습니다. Azure DevOps의 작업 항목 추적을 사용하면 코드 변경을 비즈니스 요구 사항과 연결할 수 있습니다.
Microsoft Fabric은 데이터 분석 워크플로에 거버넌스를 적용합니다. Microsoft Purview로 데이터를 카탈로그화하고 계보를 추적합니다. 모든 워크스페이스에 적용되는 정책을 OneLake 수준에서 설정합니다. 이처럼 통합된 방식 덕분에 데이터가 늘어나도 규정 준수를 쉽게 관리할 수 있습니다.
팁: 거버넌스 설정을 자주 검토하세요. 강력한 거버넌스는 규정 준수 요구 사항을 충족하고 배포를 안전하게 유지하는 데 도움이 됩니다.
보안 상태
코드, 데이터, 배포를 위협으로부터 보호해야 합니다. 플랫폼마다 서로 다른 보안 기능과 제어 항목을 제공합니다.
GitHub는 2단계 인증, 비밀 관리, 브랜치 보호로 리포지토리를 보호하는 데 도움이 됩니다. GitHub Actions를 사용하면 보안 검사와 취약성 점검을 자동화할 수 있습니다.
azure devops는 고급 보안 제어 기능을 제공합니다. 역할 기반 액세스를 사용하여 권한을 제한할 수 있습니다. azure devops는 비밀을 안전하게 저장하고 이를 파이프라인에 연결합니다.
Microsoft Fabric은 데이터 보안에 중점을 둡니다. Microsoft Defender for Cloud Apps를 사용해 활동을 모니터링하고 위험한 동작에 대한 알림을 설정할 수 있습니다. 파이프라인에서 민감한 데이터를 분류하고 보호할 수도 있습니다.
참고: 플랫폼의 보안 기능과 모범 사례를 함께 적용해야 합니다. 팀을 교육하고, 설정을 검토하며, 위협이 변화함에 따라 정책을 업데이트하세요.
실제 DevOps 시나리오
GitHub를 활용한 오픈 소스
오픈 소스 프로젝트를 진행할 때 github를 사용하면 배포 소유권을 간단하게 관리할 수 있습니다. 배포 프로세스를 자동화하고 코드가 변경될 때마다 프로젝트를 실제 서비스 상태로 유지할 수 있습니다. github를 사용하는 일반적인 오픈 소스 DevOps 워크플로에서 소유권이 어떻게 작동하는지 살펴보겠습니다:
- github의 공개 리포지토리에 코드를 푸시합니다.
- main 브랜치에 푸시할 때마다 자동 배포가 트리거됩니다.
- 배포하기 위해 승인을 요청하거나 기다릴 필요가 없습니다.
- 자체 AWS 계정이나 이와 유사한 서비스를 사용하여 클라우드 인프라를 직접 관리할 수 있습니다.
- 프로젝트는 항상 프로덕션 수준의 인프라에서 운영됩니다.
Azure DevOps를 활용한 엔터프라이즈
엔터프라이즈 환경에서는 복잡한 프로젝트를 관리하기 위해 azure devops를 자주 사용합니다. 속도, 보안, 규정 준수의 균형을 맞춰야 합니다. 이런 환경에서는 소유권 관리가 어려워질 수 있습니다. 팀의 역할과 책임을 명확히 정의해야 합니다. Azure devops는 권한을 할당하고 역할 기반 액세스 제어를 사용할 수 있도록 하여 이를 지원합니다.
Fabric을 활용한 데이터 분석
데이터 분석 프로젝트를 관리할 때 Microsoft Fabric을 사용하면 배포 소유권을 강력하게 관리할 수 있습니다. 워크스페이스의 각 항목을 누가 배포, 편집, 조회할 수 있는지 제어할 수 있습니다. 분석 자산을 명확하게 통제할 수 있습니다. 새 항목을 배포하면 해당 사용자가 소유자가 됩니다. 항목이 이미 존재하는 스테이지에 배포하면 소유권은 그대로 유지됩니다.
팁: Microsoft Fabric의 배포 파이프라인과 워크스페이스 권한을 사용하여 데이터를 안전하게 보호하고 팀의 생산성을 유지하세요.
하이브리드 배포
배포를 관리하는 데 두 개 이상의 플랫폼을 사용해야 하는 경우가 많습니다. 이는 대규모 조직이나 여러 도구의 장점을 결합하려는 경우에 흔히 볼 수 있습니다. 하이브리드 배포를 사용하면 소스 제어에는 GitHub, 파이프라인에는 Azure DevOps, 분석에는 Microsoft Fabric을 활용할 수 있습니다. 이러한 플랫폼을 연결하여 요구 사항에 맞는 워크플로를 구성할 수 있습니다.
팁: 각 플랫폼의 액세스 및 거버넌스 설정을 검토하세요. 올바른 사용자만 코드를 배포하거나 변경할 수 있도록 하세요. 이렇게 하면 워크플로를 안전하게 유지할 수 있습니다.
적합한 DevOps 플랫폼 선택하기
핵심 소유권 질문
DevOps 플랫폼을 선택하기 전에 올바른 질문을 던져야 합니다. 이 질문들은 각 도구가 소유권, 거버넌스, 통합을 어떻게 처리하는지 이해하는 데 도움이 됩니다. 다음 사항을 검토해 보세요:
- 코드와 아티팩트에 대한 액세스는 누가 제어합니까?
- 플랫폼은 거버넌스와 규정 준수를 어떻게 적용합니까?
- 배포에서 누락된 메타데이터에 대한 알림을 자동화할 수 있습니까?
- 플랫폼이 기존 도구와의 통합을 지원합니까?
- 플랫폼은 서비스 소유권과 메타데이터를 어떻게 처리합니까?
팁: 이 질문들을 초기에 던지세요. 혼동을 피하고 DevOps 워크플로의 견고한 기반을 마련할 수 있습니다.
플랫폼별 강점
각 DevOps 플랫폼은 고유한 강점을 제공합니다. 프로젝트 요구 사항에 맞는 강점을 선택해야 합니다. 빠른 도입과 간편한 통합을 원한다면 GitHub Actions를 사용할 수 있습니다. Azure DevOps는 복잡한 워크플로를 위한 고급 제어 기능을 제공합니다. Microsoft Fabric은 통합 분석과 거버넌스를 제공합니다. 버전 관리와 배포를 위해 워크스페이스를 GitHub 또는 Azure DevOps와 연결할 수 있습니다.
참고: 워크플로와 거버넌스 요구 사항에 맞는 플랫폼을 선택해야 합니다. 각 플랫폼은 DevOps 소유권에서 서로 다른 강점을 지원합니다.
GitHub, Azure DevOps, Microsoft Fabric가 코드, 아티팩트, 액세스, 거버넌스를 관리하는 방식을 이해하면 배포에 대한 명확한 책임 체계를 갖출 수 있습니다. 보안 및 규정 준수 요구 사항에 맞는 플랫폼을 선택하십시오. 엔드포인트 관리 정책을 정의하고, 팀 간 공동 책임 체계를 수립하며, 필수 보안 통제 항목을 식별하십시오. 위험보다 앞서 나가려면 플랫폼 기능을 자주 검토하십시오. 공정성, 안정성, 책임성을 포함한 책임 있는 AI 정책에 맞춰 플랫폼 선택을 조정하십시오. 이러한 접근 방식은 데이터를 보호하고 강력한 거버넌스를 유지하는 데 도움이 됩니다.
이 주제에 대해 더 깊이 배우고 싶으시다면 관련 에피소드를 직접 들어 보십시오: GitHub vs Azure DevOps for Microsoft Fabric CI/CD.
자주 묻는 질문
DevOps 플랫폼에서 배포 책임(deployment ownership)은 무엇을 의미합니까?
배포 책임은 코드, 아티팩트, 액세스, 거버넌스를 직접 통제한다는 뜻입니다. 누가 배포할 수 있는지 결정하고, 변경 사항을 추적하며, 규칙을 적용할 수 있습니다. 이러한 책임 체계는 프로젝트를 보호하고 규정 준수를 유지하는 데 도움이 됩니다.
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단계 인증, 비밀 관리(secrets management), 자동화된 보안 검사를 사용합니다. 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로 옮길 수 있습니다. 많은 팀이 Azure Repos에서 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에 연결하여 두 도구의 장점을 모두 활용합니다.
GitHub Copilot을 Azure DevOps 사용자도 이용할 수 있나요?
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에는 엔터프라이즈 관리 사용자와 Azure용 GitHub Advanced Security가 포함되어 있으며, 코드 검사, 비밀 검사, 종속성 관리 기능을 제공합니다. 선택은 조직의 요구 사항에 따라 달라집니다. Azure DevOps는 기존 Microsoft 도구와 더 잘 통합될 수 있고, GitHub는 오픈 소스 및 커뮤니티 기능과 고급 보안 옵션이 더 강력합니다.
Azure Pipelines와 GitHub Actions의 CI/CD 파이프라인은 어떻게 다른가요?
Azure Pipelines(azure boards and 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에는 이와 동일한 내장 테스트 계획 제품이 없습니다. 대신 테스트 프레임워크, 액션, 타사 테스트 관리 도구를 GitHub 리포지토리와 통합하여 유사한 테스트 자동화 및 보고 기능을 구현할 수 있습니다.
가격 정책과 호스팅은 GitHub 호스팅과 Microsoft Azure DevOps 호스팅 사이에서 어떻게 다른가요?
GitHub는 팀과 엔터프라이즈를 위한 등급별 요금제를 갖춘 호스팅 서비스(GitHub.com, GitHub Enterprise Cloud)를 제공하며, 공개 및 비공개 리포지토리와 커뮤니티 접근을 중시합니다. Microsoft Azure DevOps Services도 사용자 기준 요금제의 클라우드 호스팅 옵션과 온프레미스 버전(이전 명칭 TFS/Visual Studio Team Services)을 제공합니다. 비용을 판단할 때는 파이프라인 실행 시간, 아티팩트 저장소, 엔터프라이즈 관리 사용자 수, 온프레미스 호스팅 필요 여부를 고려해야 합니다.
팀이 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 리포지토리를 사용하는 하이브리드 모델을 채택할 수 있습니다.