GitHub 라이선스 컴플라이언스 정식 출시: 기업 정책·PR 병합 차단 설정 가이드

정식 출시: 무엇이 달라졌나

2026년 10월 16일 GitHub는 오픈소스 라이선스 컴플라이언스 기능의 정식 출시(GA)를 발표했다. 깃허브 오픈소스 라이선스 관리 업무를 중앙 정책과 저장소별 병합 규칙으로 연결하는 것이 핵심이다. 기존에 취약점 여부와 의존성 변화를 보던 개발팀이라면, 이제 새로운 패키지가 회사의 라이선스 정책에 맞는지 PR 단계에서 확인할 수 있다.

GitHub license compliance는 법률 자문이나 모든 라이선스 의무의 자동 준수를 보장하는 제품이 아니다. 기업이 허용한 라이선스와 새로 추가·변경한 의존성 정보를 비교하여 위반 후보를 보여 주고, 선택한 규칙에 따라 병합 전에 조치하도록 돕는 기능이다. 깃허브 라이선스 컴플라이언스 기능은 공개 저장소 전체에 기본 제공되는 것이 아니므로 다음의 이용 조건을 반드시 확인해야 한다.

도입 가능 조건: Enterprise Cloud와 Code Security

GitHub Enterprise Cloud 라이선스 정책을 운영하려면 엔터프라이즈가 관리하는 조직에 해당 저장소가 속해야 하고, 저장소에 GitHub Code Security 라이선스가 적용되어야 한다. 데이터 레지던시 환경의 GitHub Enterprise Cloud도 지원 대상으로 발표되었다. 의존성 그래프가 활성화되어 있어야 하고 기업 정책과 ruleset을 관리할 수 있는 적절한 권한도 필요하다.

GitHub 라이선스 정책 설정 방법: 실제 운영 순서

먼저 기업 차원에서 허용할 오픈소스 라이선스 목록을 정한다. GitHub Docs에 따르면 기본 제공 목록에서 선택하거나 해당 라이선스가 없으면 SPDX 식별자를 직접 입력할 수 있다. 법무·보안·개발조직이 검토한 목록을 중앙 정책으로 관리하고, 팀 또는 프로젝트 차원의 예외가 필요한지 별도로 결정한다.

다음으로 엔터프라이즈·조직·저장소 범위의 ruleset을 구성한다. 깃허브 ruleset 라이선스 검사는 브랜치 룰셋에서 Require license compliance results before merging 조건을 사용하는 방식이다. 이 이름은 실제 관리 UI에서 찾는 설정 조건을 식별하기 위한 것이며, 계정 권한과 GitHub UI 변경에 따라 메뉴 위치는 달라질 수 있다.

도입 초기에 영향 범위를 제한하려면 시험 저장소 또는 소규모 조직에서 Evaluate로 경고 결과를 살펴보고, 허용 목록과 예외 처리 프로세스를 조정한 다음 필요한 저장소에 Active를 적용하는 단계적 도입이 현실적이다. 먼저 실제 테스트 PR에서 의존성 manifest를 변경해 검사 동작을 확인한 뒤 전체 적용 범위를 확대하자.

Evaluate와 Active: 병합 차단 조건

GitHub 라이선스 Evaluate Active 차이는 병합 강제 여부에 있다. Evaluate 룰셋은 감지한 문제를 PR 주석으로 알려주지만 그 라이선스 규칙만으로는 병합을 막지 않는다. 반면 Active 룰셋은 비준수 의존성에 대한 문제가 해결될 때까지 관련 PR 병합을 차단할 수 있다.

PR 라이선스 위반 병합 차단은 해당 브랜치 룰셋이 대상 저장소와 브랜치에 적용되어 있는지를 먼저 확인해야 한다. 한 가지 중요한 예외가 있다. Evaluate 자체는 차단하지 않더라도 별도 branch protection의 댓글 해결 의무 규칙이 켜져 있으면 라이선스 검사 주석 때문에 병합이 지연되거나 차단될 수 있다. 따라서 모드 이름만으로 최종 병합 가능 여부를 단정하면 안 된다.

위반 PR이 나오면 어떻게 처리하나

PR에서 정책상 허용하지 않은 의존성 라이선스가 발견되면 직접 또는 전이 의존성을 포함한 변경 내역을 확인하고, 문제가 된 패키지를 다른 것으로 교체하거나 제거할 수 있다. 기업이 정책을 변경할 타당한 근거가 있다면 허용 목록을 재검토하는 방법도 있다.

특정 패키지 사용이 불가피하다면 깃허브 라이선스 예외 승인 경로를 검토한다. GitHub가 제공하는 Enterprise Open Source License Manager 역할은 예외나 정책 변경 요청을 검토할 담당자에게 부여할 수 있다. 검토자는 엔터프라이즈 콘솔과 알림을 통해 대기 중인 요청을 확인하며, 요청했다고 해서 예외가 자동 승인되는 것은 아니다. 사유, 적용 범위, 검토 주체, 감사 기록을 남기는 운영 체계를 권장한다.

SBOM·API·기존 dependency review와 비교

GitHub SBOM 라이선스 정보는 데이터 레지던시 Enterprise Cloud에서도 제공되도록 확장됐다고 GitHub는 밝혔다. 이 데이터는 의존성 목록과 라이선스 정보를 파악하는 데 유용하지만, SBOM 파일이 있다는 이유만으로 라이선스 사용 의무를 모두 충족한 것으로 판단할 수 없다.

GitHub 라이선스 컴플라이언스 API는 기업 정책 조회·수정·교체 및 특정 패키지가 기업 정책에 부합하는지 확인하는 기능을 포함한다. 관리자는 정책 변경 감사 로그를 외부 기록 시스템과 연결하는 방안도 검토할 수 있다. 자동화 스크립트나 AI 코딩 에이전트가 패키지 추천 전에 정책상 허용 여부를 점검하는 데 활용 가능하지만, 실제 API 인증·요청 형식은 최신 공식 문서를 따라야 한다.

운영 전 점검표와 한계

운영팀은 적용할 저장소 목록, 사용 가능한 라이선스·요금 조건, 활성화된 dependency graph, 정책 담당자, Evaluate 파일럿 기간, Active 전환 조건, 긴급 예외 승인 절차를 먼저 문서화해야 한다. 도입 전후 PR에 실제 검사가 언제 실행됐는지도 확인한다.

공식 문서의 기본 라이선스 위험 등급은 참고용 분류이며 법률 의견이 아니다. 특정 라이선스의 배포·수정·고지 의무는 배포 방식과 계약 관계에 따라 달라질 수 있으므로 필요하면 전문가 검토를 받아야 한다. 또한 PR 변경분의 라이선스 검사 기능을 모든 기존 저장소·과거 의존성의 전수 감사로 오해해서는 안 된다.

자주 묻는 질문

무료 공개 저장소도 무조건 사용할 수 있나요?

아니요. 기업 계정 및 대상 저장소의 GitHub Code Security 조건 등을 충족해야 합니다.

Evaluate 설정만으로도 병합이 막히나요?

라이선스 Evaluate 규칙만으로는 직접 차단하지 않습니다. 그러나 별도의 댓글 해결 의무 등 다른 보호 규칙이 영향을 줄 수 있습니다.

어느 변경에서 라이선스를 검사하나요?

PR에서 패키지 매니페스트가 바뀔 때, 기본 브랜치와 PR 브랜치의 의존성 변경 사항을 평가합니다.

예외 승인을 누가 하나요?

기업이 지정한 Enterprise Open-Source License Manager 등 적절한 권한을 가진 담당자가 요청을 검토합니다.

공식 출처

• GitHub Changelog — Open source license compliance generally available
• GitHub Docs — About open source license compliance
• GitHub Docs — Configuring open source license policies
• GitHub Docs — REST API endpoints for license compliance
• GitHub Docs — Configuring the dependency review action

자료 기준: 2026-10-19. 본문은 GitHub 공식 문서 및 2026-10-16 발표를 기반으로 작성했으며, 계정별 사용 조건과 화면 위치는 달라질 수 있습니다.