GitHub 라이선스 검사, Action과 새 중앙 정책은 뭐가 다를까?

검사 항목보다 정책을 관리하고 승인하는 방식이 달라진다

이미 Dependency Review Action으로 새 패키지의 라이선스를 검사하고 있다면, GitHub의 새 기능을 도입해야만 검사가 가능해지는 것은 아니다. 기존 Action은 허용 라이선스 목록과 패키지별 검사 제외를 설정할 수 있고, 다른 저장소의 설정 파일도 참조할 수 있다.

10월 16일 정식 제공된 오픈소스 라이선스 준수 기능은 여기에 기업 단위 정책과 전용 예외 승인 절차를 더한다. 관리자가 공통 허용 기준을 정하고, 규칙 집합으로 적용할 저장소를 고르며, 담당자가 패키지 사용 예외를 심사하는 구조다.

Action의 deny-licenses는 10월 26일 현재 저장소 문서에서 향후 제거 가능성이 있는 사용 중단 예정 옵션으로 표시돼 있다. allow-licenses와 동시에 쓸 수도 없다. 기존 예제를 옮길 때는 현재 옵션 설명까지 확인해야 한다.

Enterprise Cloud와 대상 저장소의 Code Security가 필요하다

새 기능은 데이터 레지던시 구성을 포함한 GitHub Enterprise Cloud 고객에게 제공된다. 공식 기능 설명은 정책을 적용할 저장소에 GitHub Code Security 라이선스가 필요하다고 명시한다. 모든 저장소에 기본으로 생기는 무료 검사는 아니다.

설정 절차의 사전 조건에는 의존성 그래프 활성화와 기업 정책·규칙 집합을 관리할 권한도 들어간다. 관리자는 기업의 Policies → License compliance → Default policy에서 허용할 라이선스를 선택하거나 SPDX 식별자를 입력한다.

검사는 패키지 명세가 바뀐 PR의 기준 브랜치와 변경 브랜치를 비교한다. 의존성 그래프에서 파악한 간접 의존성도 평가에 포함된다. 저장소 자체의 LICENSE 파일을 하나 선택하는 작업과, 가져다 쓰는 패키지가 회사 정책에 맞는지 판단하는 작업은 대상이 다르다.

평가 모드에서도 기존 병합 규칙을 확인해야 한다

실제 차단 여부는 규칙 집합의 적용 모드와 조건에 달려 있다. Require license compliance results before merging을 사용한 활성 모드에서는 정책 위반을 해결할 때까지 PR 병합이 막힌다. 평가 모드는 검사를 실행하고 주석을 남기지만 그 규칙 자체로 병합을 차단하지 않는다.

여기에는 놓치기 쉬운 조건이 있다. GitHub 문서는 병합 전 주석 해결을 요구하는 브랜치 보호 규칙이 라이선스 검사 주석도 추적한다고 설명한다. 따라서 평가 모드를 켰다는 이유만으로 기존 PR 흐름에 아무 영향이 없다고 판단하면 안 된다.

여러 저장소에 나눠 적용하려면 저장소 사용자 지정 속성으로 적용 단계를 구분하고 평가용·활성용 규칙 집합의 대상을 정할 수 있다. 설정 후에는 실제로 의존성을 바꾸는 PR에서 검사 결과와 병합 가능 여부를 함께 확인해야 한다.

개발자는 패키지를 바꾸거나 사용 예외를 요청한다

정책에 맞지 않는 라이선스가 발견되면 해당 의존성을 제거·교체하거나, 허용 정책 변경 또는 예외 승인을 거쳐야 한다. 검사 주석이 생겼다고 예외 요청이 자동으로 제출되는 것은 아니다. 계속 그 패키지를 사용하려는 개발자가 필요한 정보를 제공해 요청한다.

Enterprise Open-Source License Manager는 요청을 심사하고 예외를 패키지·라이선스·패키지 패턴 중 어디에 적용할지, 저장소와 기업 중 어느 범위에 적용할지 정할 수 있다. 승인으로 해당 경고가 닫혀도 다른 필수 검사가 실패하고 있으면 PR은 여전히 병합되지 않는다.

워크플로 설정과 코드 리뷰로 허용 목록을 관리할 수 있다면 기존 Action도 선택지다. 여러 저장소에서 예외를 누가 승인했는지 남기고 기업 정책 변경을 감사해야 한다면 새 기능의 관리 체계가 더 직접적으로 맞는다. 도입 여부는 검사 유무보다 조직에 필요한 승인·운영 방식으로 판단하는 편이 정확하다.