원문 소식, 쉽게 읽기
GitHub가 2026년 10월 16일 오픈소스 라이선스 준수 기능을 정식 제공한다고 발표했다. 대상은 데이터 레지던시를 사용하는 고객을 포함한 GitHub Enterprise Cloud이며, 적용 저장소에는 GitHub Code Security가 활성화돼 있어야 한다. 출처
서비스 개발에 가져다 쓰는 외부 소프트웨어를 의존성이라고 한다. 기업은 허용할 라이선스의 공통 정책을 정하고, 규칙 묶음인 ruleset으로 적용할 저장소를 지정한다. 코드 변경을 합쳐 달라는 요청인 풀 리퀘스트(PR)가 의존성 목록을 바꾸면 검사 대상이 된다. 설정에는 의존 관계를 기록하는 dependency graph 활성화와 기업 정책·ruleset 관리 권한도 필요하다. 출처
병합, 즉 변경사항을 기존 코드에 합치는 단계에서는 두 설정을 함께 봐야 한다.
- Active 모드에서 라이선스 검사 결과를 병합 조건으로 요구하면, 정책 위반 의존성이 포함된 PR은 위반이 해결될 때까지 차단된다.
- Evaluate 모드는 검사 결과를 PR 주석으로 남기며 자체적으로 병합을 막지 않는다.
- 별도의 브랜치 보호 규칙이 댓글 해결을 병합 조건으로 요구하면, Evaluate에서 나온 라이선스 주석에도 그 조건이 적용된다. 출처
주석이 표시된 뒤 개발자는 의존성을 교체하는 등의 수정을 할 수 있다. 계속 사용하려면 정보를 추가해 예외를 요청하고 Enterprise Open Source License Manager의 검토를 받는다. 주석 생성과 예외 요청 제출은 별도 단계다. 출처
이 담당자는 요청을 승인하거나 거절하며, 승인할 때 패키지·라이선스·패키지 패턴 중 적용 대상과 저장소·기업 중 적용 범위를 정한다. 승인으로 경고가 닫힌 뒤 병합하려면 다른 필수 검사도 모두 통과해야 한다. 라이선스 선택 화면의 위험 분류는 참고 정보이며, 정책의 법적 기준은 조직 법무팀의 안내를 따라야 한다. 출처
정식 제공에는 데이터 레지던시 환경의 라이선스 정보, 정책 변경 감사 기록, 정책 관리와 패키지의 정책 적합 여부 확인을 위한 API도 포함된다. API는 다른 프로그램에서 해당 기능에 접근하는 통로다. 출처
OYOPICK의 시선
도입을 맡은 제품 책임자라면 검사 항목보다 먼저 “이 저장소의 변경을 누가, 어느 범위까지 허용할 수 있나”를 정해두는 편이 유용하다. 같은 예외 승인도 한 저장소에 한정할지 기업 전체에 적용할지에 따라 이후 검토의 기준이 달라진다. 승인자의 이름뿐 아니라 예외 범위까지 설명할 수 있어야 팀이 다음 변경에서도 같은 기준을 이해할 수 있다.
Evaluate를 먼저 쓰는 팀에는 댓글 해결 규칙을 함께 점검할 이유가 생긴다. 화면의 모드 이름만 보고 배포 계획을 세우면 실제 병합 조건을 놓칠 수 있기 때문이다. 변경이 멈췄을 때 담당자가 적용 정책, 남은 주석, 예외 요청 상태를 같은 맥락에서 설명할 수 있는지가 이 기능의 운영 가치를 판단할 기준이 될 것이다.